Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs.
Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.
Codeowners are added as a reviewer to every PR that touches a file under their (team) ownership. In a large codebase it can easily happen that a large % of PRs changes something you're a codeowner for.
Well I do (basically 99% of github emails are auto-purged from my email inbox), but the problem is that the github platform itself on the notifications page is unusable. It'd be nice if I could use it!
A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
We made a similar thing too for our community discord where you can add an Emoji on a message and it will look for similar issues with a simple RAG. That saves us so much time when a user asks if a feature is planned or not.
We also ask them to go upvote the issue or create one in the response.
Not open source right now but if people are interested I could clean up the code.
Oh yeah, that looks super similar. I remember the similarity score being tricky to get useful signal out of, for the underlying model I had used back then. Similar and dissimilar issues all hovered around the 0.80 mark. But surely not hard to improve on, with larger models and possibly higher-dimension vectors.
If only Microsoft was interested in finding actual useful use-cases for their machine learning tech instead of constantly selling everyone on their chat bot...
If we're talking issues (i.e. reports from external parties, like OSS users, and not internally defined tasks), then care is needed to avoid it working out like the Stack Overflow experience. What is it, you ask?
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
I refuse to work with projects with a stale bot. As if ignoring an issue will just magically resolve it. I also refuse to use products with a stale bot once I discover it is used; they are usually bug ridden due to uncovered issues being ignored.
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
GitHub doesn’t have ads and makes its money off of enterprise subscriptions (and Copilot), so I don’t think “engagement” is a very important metric for them.
Wait if it's not their core product, what is? GitHub is, at its core, a file/history browser + issue management system + merge request system built around Git. There's not that much to it other than issue management.
It's core product is git hosting, you use it to host your git repositories. You use features such as Pull Requests to power how you merge within your git repositories. If the issue system isn't working it's not a big deal, but if we can't use git it's a massive deal. It's all in the name GIThub
Most companies don't use GitHub's issue management system they use issue management tools such as JIRA, Trello, etc. Issue management, project management, CI/Actions, wiki, discussions, etc are all nice to haves and are probably more aimed at the open source projects that are used as a marketing tool.
Most open source projects (you know, the thing GitHub claims to exist for) do pretty much exclusively use GitHub issues for issue tracking though. GitHub makes it pretty difficult to be on GitHub and not accept GitHub issues.
> This means there are no new UI patterns to slow you down,
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.
I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great.
It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.
But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.
The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
I like GitHub precisely because it didn't try to capture the entire market of issue trackers and code search too aggressively.
If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.
Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.
Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.
Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.
> automatically consigned to worst-in-class experiences
You said it perfectly. This is why there are a lot of people willing to create better experiences on top of GitHub’s API.
I created CodeApprove (https://codeapprove.com) to improve GitHub’s code review and there’s also Graphite, CodePeer, Reviewable, and others doing a great job.
Any of them support dependencies between issues? Without it, it's still all worst-in-class experience for the purpose of managing work. Yes, this is distinct from issue tracking, which is an input, and usually external, but people seem to have this weird habit of trying to manage software projects using GitHub or GitLab issues.
> There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues).
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.
I feel like ticketing is something that has been pasted on for corporate reasons.
Keeping track of the work to be done doesn't require a ticketing system,
anyone remember using Story Cards? A whiteboard?
Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).
Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.
EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?
And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?
(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)
EDIT2:
> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"
I find its subtasks a little half baked and I feel like portions of Jira weren’t designed with sub-tasks in mind. We actually avoid them completely at my current work.
It’s understandable why a lot of systems don’t support sub-tasks. Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
> I feel like portions of Jira weren’t designed with sub-tasks in mind
That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.
Dependency releationships between tasks are more general and better overall. Unfortunately,
> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.
Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.
> I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks
In the agile world it's accepted that a task that today looks like it depends on another task may not have that dependency next week.
Planning involves scheduling what the stakeholders prioritize now that can be done,
and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
> Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.
Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.
In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).
While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.
Planning and scheduling/prioritizing are split into separate things by people who think less about shipping working code and more about counting beans.
Shipping working code is a means to an end, not end unto itself. Planning and scheduling/prioritizing are split into separate things by people who think about and then tell the people shipping working code what they should be writing and shipping.
I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.
Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.
Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)
Don’t forget code review. I created CodeApprove, but there are so many other good alternatives that could have been GitHub features (Graphite, CodePeer, Reviewable, etc).
FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision.
They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it.
But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
> FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right
That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.
Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?
Once you have sizing, the ability to make an issue dependent, estimated start / end, don’t you have everything needed to generate a PERT / Gantt chart?
You also need the proper dependency types[0] I mentioned, though I'd say you can get away with FS for dependencies and FF for subtasks.
Beyond merely generating a Gantt chart, when you have dependencies and estimated duration you can start estimating how long things will take and which ones can take longer or be delayed without impacting overall project time; add the ability to provide constraints on start and end time, and you can automatically schedule work (and re-schedule at it happens).
Most of these things are in every system in some form or other, but dependencies seem to be missing almost everywhere - and dependencies are the one key component that enable major benefits and turn the system into a proper project planning tool.
Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.
Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.
Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).
> I started programming right when they got started.
Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.
GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.
Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.
I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.
Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
> At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.
You jest, but I tested this and it turns out that it was JavaScript, not slow networking, that made Jira so slow for me. (I was trying to figure out how to locally cache assets to speed it up.)
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
I don't have practical experience with JIRA Cloud Operations, or JIRA on-prem operations, but if I compare on-prem vs SaaS of our own solutions, the answer is scale and focus.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)
My guess is that self-hosted versions have an infinitely simpler user experience when it comes to accounts and visibility. Jira Cloud is definitely angled towards always being behind some sort of an account system, which used a real, costly backend, but the self-hosted one can get by with the local hosted IdP or an LDAP server.
Totally off topic, but Tags can be moved too. ;)
It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Yeah I have no confidences in GH to become viable for issue management for large commercial projects.
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org. How do you do it and what are the common pain points? Do you couple it with other issue trackers/project management tools like Jira? If so—why?
I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.
We did at my previous employer (https://www.ourbranch.com/) in our data org. I can't totally remember, I'm pretty sure the engineering org did, too. It definitely is lacking in some of the advanced features you get with a Jira, but it was fine. I was surprised by how powerful GitHub Projects is. We also built out extra reporting for it in our data warehouse, using Fivetran for ELT.
1. Does the data org work in isolation from other orgs? I'm guessing not.
2. Does the data org consist of non-engineers? If yes, are they also onboarded into GitHub with their own GH accounts?
3. If (1) is no, what tool is used to track cross-org work? Does the company also use Jira or some other tool and is GH projects integrated with them or something? I'm really curious about this workflow if it is relevant to how you folks work.
1. No -- the project boards and issue tracker were visible to the whole company, which was helpful for being able to show people what we were doing and where their requests were scheduled. Our points of contact within departments we supported worked particularly closely with my team to co-manage the projects.
2. Most of the ICs didn't have an engineering background, and came from a more traditional data analyst background. When I arrived, the only thing actually version controlled in Git was LookML that wasn't actually used. Many learned Git and GitHub for the first time there.
We ditched Jira to go all-in on GH. It's nice having the project management in the same place as where the actual work happens. It's not perfect, but it's better than GH + Jira.
Probably the benefit I'm most happy with are that people are writing more, and in greater detail. I don't know why that is. For some reason, the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Interesting. Are you an all-dev org or did you also onboard non-devs into GH Projects?
> the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Huh, that's interesting to hear. I didn't personally find it harder to add detailed descriptions in Jira back when I used it couple of years back. Wonder if there's anything specific about the experience you can describe that makes you feel GH projects is more friendly for writing.
Roughly half the company are programmers, so we have non-devs working with GH Projects and collaborating on issues.
Colleagues who aren't developers have become more engaged in the process of writing bug reports or giving feedback on product development (or at least, the parts of it that concern them). Some of the non-programmers have admitted that they are surprised by how much they enjoy using GitHub.
We were interested in Issues and Projects, but the number of people at an organization who need access to those but not to code or CI is pretty large. GitHub does not have a different license option for BA/CX/PM types. We ended up going with Jira for tasking, which was substantially cheaper.
I was sad about this because issues/projects had all the stuff I personally cared about, and there was no need to work to set up integrations. I think there was some anxiety by the PMO that it wasn't mature enough for what they wanted, but I don't remember any specifics. Probably something about reporting.
That's how I feel as feel. It's costly given the things non-devs types won't need and it's not fleshed out enough to attract those types of folks to make the switch. GitHub is probably missing the boat tbh. Even the marketing page (https://github.com/features/issues) is targeted at developers.
We do at Grafana - it's mostly all public so you can go look at the mess of trying to run jira boards for however many teams out of one repo https://github.com/orgs/grafana/projects. It's a mixed bag, but Github's been building out Issues and Projects a lot in the last few years that's really improved things.
We do. We're an agency so there's probably 60 odd repos on GitHub each with a project attached, a lot of non-tech people (even clients) using the issues and boards. Nobody has complained, though every now and then I've looked around for something else, but for me the number one priority is that the code and issues are in perfect sync with each other - much harder with a 3rd party tracker.
Absolutely. They definitely can't expect to sell this to teams/orgs with non-devs without introducing separate pricing for folks who just want to read/write to projects but maybe read-only for some aspects of a repo.
We tried (dev-centric org) but the non-technical users weren’t able to use it well / didn’t like it - so now we don’t have issue tracking at all for non technical stuff -.-
Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago.
Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011).
That's not how it works. It is going the way of Jira. What you mean is if it keeps going that way it will be Jira.
Until we get to the point we can decide things are finished and move on to other problems, everything will turn into Jira eventually. It's like entropy. We have the power to stop it, but it wouldn't guarantee those sweet, sweet growth targets.
The problem is Microsoft has two products in this space but everyone hates Azure DevOps which is supposed to be a JIRA competitor and GitHub is where all the momentum is. They'd love to ditch having to maintain ADO and GitHub long term but that means crapifying GitHub so they can migrate their ADO customers. At the same time they're hoping to pull Atlassian customers that use JIRA and GitHub to ditch the latter and just entirely be on GitHub.
What well end up with is a service that sucks to use for all cases.
ADO almost made me want to use Jira instead.
Turned out that,
while the product it not great,
the pain I experienced using it had more to do with corporate processes than the software itself.
I really dislike the use of former and latter. It’s confusing, people get it wrong, and it can be interpreted at least two different ways to make it ambiguous.
Overall, the claim above, as written, is a rather generalized prediction, not an inevitability.
Enterprise buying power and expectations create various pressures, sure. But there are other pressures and factors that need to be accounted for such as demands from other types of customers and the company’s expertise with what has worked well so far (simpler is better, compared to Jira).
Entropy is a law of physics, sure, but the ways and degrees to which it manifests in software is far from obvious or inevitable.
We live in a world of possible future scenarios, not of narrative-based certainties.
I predict GitHub Issues will remain considerably simpler than Jira for the next five years at least. As code analysis tools improve (traditional static analysis as well as LLM-based), I think we will see a lot of experimentation in this space.
GitHub is free for most people, so they are only beholden to large organizations and their feature requests. This is how it seems now - a feature creep by committee. It's getting more and more bloated and unwieldy, sort of like what happened to AWS.
It is less simple, but nowhere Jira-level, and yet still more useful (for my team and I).
We've been using GH Projects at my current org and program for two years. The one feature I wish it had was nested issues.
In Jira, you had Epic > Task > Sub-task and that's it. With GH, you can just have issue > issue > issue (insert "it's turtles/issues all the day down meme"). So it's more powerful, but can be ignored by folks who don't want to do this.
This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
Feature parity is probably not required as long as the different teams are able to adapt their workflow to GitHub's approach. Anecdotally, every employee from Microsoft I've talk to about this point during the last two years keep telling me that ADO is over.
Feature parity is absolutely required. We are ADO customer because A) Inertia and B) GH Actions is nowhere close to features of ADO Pipelines.
Every conversation we have with Microsoft about our ADO -> GH migration is either get GH to feature party or if you force us to migrate, we will evaluate ALL our options.
People have been saying this for half a decade, and fearmongering everyone into moving elsewhere (sadly my team fell for it).
Azure Devops is such an underrated tool, it's a shame that it's being ignored by Microsoft. Not only that, but they're enshittifying it by turning into Github. I kid you not, it actually went backwards in terms of features. E.g. Instead of nifty UIs that was implemented for their pipelines, we now instead have to write shitty yaml files with absolutely no validation and guidance. This is the same company that (re)wrote Word, Excel and Powerpoint in the browser! The mental whiplash from witnessing this is very jarring.
The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy.
This create-a-subissue-when-needed way is more sensible.
I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.
I, for my part, would be happy if they could make basic search work for a start. Will the advanced search finally allow us to find the most basic things reliably?
It's neat there are more options for filtering though ime the new issues UI is less responsive, showing placeholder skeletons more frequently than I'd like. Perhaps less noticeable when a fast connection is always available but even just showing the total Open/Closed ticket counters can take a few seconds when it used to be instant.
I was excited to see this feature pop up in beta, specifically sub issues. VS code organizes their work with parent sprint issues ("iteration plan", see [1]). I started using this pattern on my own project and once i adapted, now prefer it. Now rather than using markdown bullet points, i can use first class sub issues which are slightly less awkward. Ultimately a minor feature addition, but if it pushes more people to use then pattern, i think it would be nice. Lighter weight than proper tools, and imho all you need for moderately complex projects if the suits dont have too many needs / influence.
Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam category, then I have to type "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report description requirement, then I have to solve a captcha. All this despite the fact that I've had a GitHub account for like a decade and I've filed like 30+ spam reports, none of which were frivolous.
I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.
Not bad, but I still have to say that zenhub does it better
Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig
Its one of those things that I will forever evangelize for, because the one time I was able to use it, I had my most productive year ever. My github activity graph for the 18 months I got to use zenhub looked like a beautiful green meadow.
I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful
This seems... unneeded bloat? I guess there are some obsessive organizers out there, but a markdown checklist of steps - potentially with links to other tickets seems like all you need.
If you're going to improve something improve code review! Let me comment on and suggest diffs to lines the author did not touch. Like half the time I am reviewing code it is "Hey, you refactored this but you missed a usage in this other file" and right now I have to manually give them file and line number manually and hope for the best.
A lot of this will seem trivial if you haven't used Github for an organization's management of issues. This also lets you start off with a markdown checklist, and convert items to sub-issues.
See, but I do. For almost a decade, we have used it as-is for tickets and bug tracking, and it's never been a problem. I just don't see the use case for sub issues.
The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields.
Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project).
An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway.
I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility.
The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status).
The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.
I wish they would build features to defend against those near-spam type comments where someone is lazy and appends their clearly unrelated issue onto an existing one that maybe shares a few keywords but nothing substantive.
It's not quite spam: there's often a real person behind it with a real issue but they need a (metaphorical) slap before they muddy the waters and disturb countless people already in the conversation.
This would be worthwhile for the individuals too - you often find a recurring pattern with all / most of their raised issues and with basic guidance they might up their game (or give up)
When you have issues in different repos but in the same board it seems very confusing that you can create them and then have to assign them to a repo for them to move out of being a Draft issue (well maybe it is not an issue yet rather a task). Maybe I'm using it wrong but I found this pretty strange. Most projects will have a backend and frontend repo certainly when building an app so I think not being able to manage issues against both projects made things a bit strange. Maybe I should use a different blank mono repo just for issues but then I imaging the integration with PRs and commit messages breaks.
Additionally I want to be able to have #PROJ-0002 style IDs for tasks, so for example I can add messages for tasks that affect both repos (e.g. "Imported types from GraphQL API into app (#BACKEND-1234, #FRONTEND-1234)") just having numbers is very limited and slightly confusing.
There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI.
But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.
A few jobs back I got “promoted” (honestly I didn’t want it but I digress) to an EM. First thing I did was ditch Jira for GH issues. I was hailed as a hero for it. Unfortunately it ended up being a disaster and we had to switch back a year or so later. These were some of the missing features so pretty exciting.
I just wish they'd improve the markdown autocomplete for issues and pull requests ... I'm not sure why it's so bad but even if i know two or three words in the issue title i almost never get the right issue to choose in the autocomplete list while typing in a markdown comment ...
They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)
Ah this really feels like they could have tackled https://github.com/orgs/community/discussions/4993 too, what a missed opportunity, I'd love to be notified about some repositories again, which I had to unwatch now because of daily autobuild spam.
Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?
In the same vein, better reviewability of series of commits. It's absolutely baffling to me that
GitHub still doesn't support the original workflow for Git.
this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?
We are loving it and we aren't even using it fully to its ability. For example we do almost no communication in the 'chat' that exists for each issue (in place of comments) since we are a very small team and still are talking mostly in slack about the issues, but I predict as we grow this will become a useful feature for us.
In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking.
This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.
From Copilot integration that you can’t disable if you accidentally clicked something once (you can only now as of a few days ago hide the UI, but you are still not able to disable it in settings), to this issues UI aglomeration.
The Microsoftization/enshittification of Github continues apace.
GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?
Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs.
Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.
Doesn’t unwatching a repo limit notifications to mentions and participated threads?
Codeowners are added as a reviewer to every PR that touches a file under their (team) ownership. In a large codebase it can easily happen that a large % of PRs changes something you're a codeowner for.
Have you been able to try trailer.app?
It’s fine for small projects. I clear mine daily, and it’s the sole place I do any communication management.
It's a workaround, but why not use email filters for this?
Well I do (basically 99% of github emails are auto-purged from my email inbox), but the problem is that the github platform itself on the notifications page is unusable. It'd be nice if I could use it!
A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.
Agree!
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
https://github.com/alexpovel/issuedigger
We made a similar thing too for our community discord where you can add an Emoji on a message and it will look for similar issues with a simple RAG. That saves us so much time when a user asks if a feature is planned or not. We also ask them to go upvote the issue or create one in the response.
Not open source right now but if people are interested I could clean up the code.
Microsoft seems to use a similar bot themselves, not sure how it is called or whether it is OSS: https://github.com/microsoft/winget-cli/issues/4765#issuecom...
Oh yeah, that looks super similar. I remember the similarity score being tricky to get useful signal out of, for the underlying model I had used back then. Similar and dissimilar issues all hovered around the 0.80 mark. But surely not hard to improve on, with larger models and possibly higher-dimension vectors.
If only Microsoft was interested in finding actual useful use-cases for their machine learning tech instead of constantly selling everyone on their chat bot...
If we're talking issues (i.e. reports from external parties, like OSS users, and not internally defined tasks), then care is needed to avoid it working out like the Stack Overflow experience. What is it, you ask?
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
I refuse to work with projects with a stale bot. As if ignoring an issue will just magically resolve it. I also refuse to use products with a stale bot once I discover it is used; they are usually bug ridden due to uncovered issues being ignored.
Completely agree with this suggestion.
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
GitHub doesn’t have ads and makes its money off of enterprise subscriptions (and Copilot), so I don’t think “engagement” is a very important metric for them.
To the company, no. But to people trying to get a promotion/bigger budgets by proving the features they work on are getting a lot of usage, plausible.
> To the company, no.
Why not? Companies love to boast about MAUs and similar metrics (even if completely bogus), it has good effect on stock prices.
Those are very general stats. They won't drop just because they disincentivize abuse of issues or pull requests.
I suspect it's more to do with issue management isn't their core product so doesn't get the same attention an issue management system would give it.
Wait if it's not their core product, what is? GitHub is, at its core, a file/history browser + issue management system + merge request system built around Git. There's not that much to it other than issue management.
It's core product is git hosting, you use it to host your git repositories. You use features such as Pull Requests to power how you merge within your git repositories. If the issue system isn't working it's not a big deal, but if we can't use git it's a massive deal. It's all in the name GIThub
Most companies don't use GitHub's issue management system they use issue management tools such as JIRA, Trello, etc. Issue management, project management, CI/Actions, wiki, discussions, etc are all nice to haves and are probably more aimed at the open source projects that are used as a marketing tool.
Most open source projects (you know, the thing GitHub claims to exist for) do pretty much exclusively use GitHub issues for issue tracking though. GitHub makes it pretty difficult to be on GitHub and not accept GitHub issues.
But open source projects are not what keeps GitHub in business that is just marketing. Companies paying for git hosting is.
You can easily disable issues.
Meta and Google have this in their internal systems.
Good suggestion! Sounds similar to what stack overflow does when asking a question.
I was also having some frustration in navigating GitHub issues.
So I wrote a simple app for fun to navigate and search GitHub issues like emails and even reply
Screen recoding https://x.com/justruky/status/1878507719520387347
It definitely had something like this at least in beta within the last couple years, or maybe just based on the title.
But you’re completely right, GH search is truly bad
Ideally there should even be an API for it so we can use it in other systems like slack/discord bots when people suggest improvements.
Linear (linear.app) does this FWIW build on vector search, we're actively working on making it more accurate too
> This means there are no new UI patterns to slow you down,
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.
I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great.
It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.
But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.
The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
I like GitHub precisely because it didn't try to capture the entire market of issue trackers and code search too aggressively.
If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.
Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.
Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.
Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.
> automatically consigned to worst-in-class experiences
You said it perfectly. This is why there are a lot of people willing to create better experiences on top of GitHub’s API.
I created CodeApprove (https://codeapprove.com) to improve GitHub’s code review and there’s also Graphite, CodePeer, Reviewable, and others doing a great job.
Any of them support dependencies between issues? Without it, it's still all worst-in-class experience for the purpose of managing work. Yes, this is distinct from issue tracking, which is an input, and usually external, but people seem to have this weird habit of trying to manage software projects using GitHub or GitLab issues.
> There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues).
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.
I feel like ticketing is something that has been pasted on for corporate reasons. Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Well, if they wanted to implement keeping track of work to be done, they'd have long ago implemented subissues, sub-subissues, and sub^n-issues, because obviously work does not break down into a list, or a one-level-deep tree - the natural data structure for breaking down work is a directed graph (and if you really must do an 80/20 on it, then a tree).
Sadly, to this day, out of popular software packages used in software companies, only Microsoft Project and maybe Jira get this right. Unfortunately, they have plethora of unrelated issues that are big enough that they drive the industry towards silliness of managing work in tools like Trello or Github/Gitlab issues.
EDIT: I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks, you can't really plan ahead much further than a sprint. So is the Agile cadence really about avoiding the Folly of the Waterfall, or is it just shitty tooling that makes it exponentially hard to think ahead for more than two weeks? Did we invent "epics" because we can't link together multiple tasks on a Kanban board?
And then, how many companies SCRUM the living hell out of their developers, while PMs secretly plan the whole thing ahead in MS Project to keep the project on track towards some goal, and then pray no one on the dev team spots a Gantt chart open on their screen?
(Personally, I worked under one once; they begrudgingly admitted to managing everything in MS Project once I started asking if I can get a license, because even Emacs Org Mode sucks at the job if the job is to break down month's worth of work on entire deliverable.)
EDIT2:
> Keeping track of the work to be done doesn't require a ticketing system, anyone remember using Story Cards? A whiteboard?
Anyone remembers a project plan? Work breakdown structure? I know PERT looks to people like a Borg Cube, but then the status quo in software dev looks like Pakled technology. "We are devs. We scrum. Trello make us go!"
I wouldn’t say Jira gets it right.
I find its subtasks a little half baked and I feel like portions of Jira weren’t designed with sub-tasks in mind. We actually avoid them completely at my current work.
It’s understandable why a lot of systems don’t support sub-tasks. Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
> I feel like portions of Jira weren’t designed with sub-tasks in mind
That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.
Dependency releationships between tasks are more general and better overall. Unfortunately,
> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.
Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.
Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.
> I sometimes wonder how much of how Agile implementations look is a consequence of simplistic tooling. When your team's work planner is fundamentally unable to represent the basic idea that tasks can depend on other tasks
In the agile world it's accepted that a task that today looks like it depends on another task may not have that dependency next week. Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
> Planning involves scheduling what the stakeholders prioritize now that can be done, and whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled.
Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.
Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.
In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).
While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.
Planning and scheduling/prioritizing are split into separate things by people who think less about shipping working code and more about counting beans.
Shipping working code is a means to an end, not end unto itself. Planning and scheduling/prioritizing are split into separate things by people who think about and then tell the people shipping working code what they should be writing and shipping.
I hate bureaucracy and will actively question the necessity of any imposition of bureaucracy, and resist its imposition if it doesn't seem justified.
Nonetheless, there is use to more than just sticky notes. It tends to come with scale, and trying to coordinate and align teams of teams of teams of teams, etc.
Additionally, sticky notes are impractical for remote teams (would there be some always-on webcam pointed at them?)
Don’t forget code review. I created CodeApprove, but there are so many other good alternatives that could have been GitHub features (Graphite, CodePeer, Reviewable, etc).
FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision.
They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it.
But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
> FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right
That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.
Useful search terms: PERT, Gantt charts, critical path, PMBOK.
Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?
Once you have sizing, the ability to make an issue dependent, estimated start / end, don’t you have everything needed to generate a PERT / Gantt chart?
You also need the proper dependency types[0] I mentioned, though I'd say you can get away with FS for dependencies and FF for subtasks.
Beyond merely generating a Gantt chart, when you have dependencies and estimated duration you can start estimating how long things will take and which ones can take longer or be delayed without impacting overall project time; add the ability to provide constraints on start and end time, and you can automatically schedule work (and re-schedule at it happens).
Most of these things are in every system in some form or other, but dependencies seem to be missing almost everywhere - and dependencies are the one key component that enable major benefits and turn the system into a proper project planning tool.
--
[0] - https://en.wikipedia.org/wiki/Dependency_(project_management...
Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.
GitHub is a hugely successful company. They make a shit load of money. Your idea of success is not in congruence with actual success.
Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.
Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).
> I started programming right when they got started.
Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.
GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.
Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.
I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.
Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
> well administrated Jira
Based on my experience that doesn't exist.
Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah.
A colleague joked that we need a "waiting for Jira" Jira task.
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
> At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.
You jest, but I tested this and it turns out that it was JavaScript, not slow networking, that made Jira so slow for me. (I was trying to figure out how to locally cache assets to speed it up.)
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
"Apple silicon has Jira coprocessor" time to retire to the country and raise chickens.
A well administered JIRA can be really fast. There's a reason Atlassian themselves don't use JIRA Cloud: https://jira.atlassian.com/browse
Huh that is much faster than Jira Cloud. How come though? Do they just hate their customers or something?
I don't have practical experience with JIRA Cloud Operations, or JIRA on-prem operations, but if I compare on-prem vs SaaS of our own solutions, the answer is scale and focus.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)
My guess is that self-hosted versions have an infinitely simpler user experience when it comes to accounts and visibility. Jira Cloud is definitely angled towards always being behind some sort of an account system, which used a real, costly backend, but the self-hosted one can get by with the local hosted IdP or an LDAP server.
Take a look at Redmine. It's a self-hosted Ruby project manager and I love it, especially for issue dependencies.
Nobody who uses Jira is really in a position to pick anything else.
Even years ago Jira was too complicated, to the point that we joked about replacing it with a physical notebook.
https://thedailywtf.com/images/200802/manualJira.jpg
Indeed, see https://ifuckinghatejira.com/
[dead]
> Maybe priority/severity or status/resolution?
That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags.
How do you envision this differing?
Are you thinking of labels?
I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
Sorting by priority?
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
Exactly this, they are so close!
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Jira is so abominably slow, that it should be laughed/shamed out of the room in any discussion of useful software.
Yeah I have no confidences in GH to become viable for issue management for large commercial projects.
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
They're called issue labels, go read up because your complaint isn't valid.
Jens's law: Every ticketing system will eventually become Jira.
This is also what is happening with GH issues.
It's worse than that. Every ticketing system will eventually become ServiceNow.
Compared to SN, Jira is a breath of fresh air.
One more field will solve it!
LOL.
I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org. How do you do it and what are the common pain points? Do you couple it with other issue trackers/project management tools like Jira? If so—why?
I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.
We did at my previous employer (https://www.ourbranch.com/) in our data org. I can't totally remember, I'm pretty sure the engineering org did, too. It definitely is lacking in some of the advanced features you get with a Jira, but it was fine. I was surprised by how powerful GitHub Projects is. We also built out extra reporting for it in our data warehouse, using Fivetran for ELT.
Oh cool! I have some questions:
1. Does the data org work in isolation from other orgs? I'm guessing not.
2. Does the data org consist of non-engineers? If yes, are they also onboarded into GitHub with their own GH accounts?
3. If (1) is no, what tool is used to track cross-org work? Does the company also use Jira or some other tool and is GH projects integrated with them or something? I'm really curious about this workflow if it is relevant to how you folks work.
1. No -- the project boards and issue tracker were visible to the whole company, which was helpful for being able to show people what we were doing and where their requests were scheduled. Our points of contact within departments we supported worked particularly closely with my team to co-manage the projects.
2. Most of the ICs didn't have an engineering background, and came from a more traditional data analyst background. When I arrived, the only thing actually version controlled in Git was LookML that wasn't actually used. Many learned Git and GitHub for the first time there.
We ditched Jira to go all-in on GH. It's nice having the project management in the same place as where the actual work happens. It's not perfect, but it's better than GH + Jira.
Probably the benefit I'm most happy with are that people are writing more, and in greater detail. I don't know why that is. For some reason, the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Interesting. Are you an all-dev org or did you also onboard non-devs into GH Projects?
> the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Huh, that's interesting to hear. I didn't personally find it harder to add detailed descriptions in Jira back when I used it couple of years back. Wonder if there's anything specific about the experience you can describe that makes you feel GH projects is more friendly for writing.
Roughly half the company are programmers, so we have non-devs working with GH Projects and collaborating on issues.
Colleagues who aren't developers have become more engaged in the process of writing bug reports or giving feedback on product development (or at least, the parts of it that concern them). Some of the non-programmers have admitted that they are surprised by how much they enjoy using GitHub.
That's really nice to hear. I'm glad things worked out for your org.
GitHub marketing folks probably should reach out to you :)
Nice job!
We were interested in Issues and Projects, but the number of people at an organization who need access to those but not to code or CI is pretty large. GitHub does not have a different license option for BA/CX/PM types. We ended up going with Jira for tasking, which was substantially cheaper.
I was sad about this because issues/projects had all the stuff I personally cared about, and there was no need to work to set up integrations. I think there was some anxiety by the PMO that it wasn't mature enough for what they wanted, but I don't remember any specifics. Probably something about reporting.
That's how I feel as feel. It's costly given the things non-devs types won't need and it's not fleshed out enough to attract those types of folks to make the switch. GitHub is probably missing the boat tbh. Even the marketing page (https://github.com/features/issues) is targeted at developers.
We do at Grafana - it's mostly all public so you can go look at the mess of trying to run jira boards for however many teams out of one repo https://github.com/orgs/grafana/projects. It's a mixed bag, but Github's been building out Issues and Projects a lot in the last few years that's really improved things.
We do. We're an agency so there's probably 60 odd repos on GitHub each with a project attached, a lot of non-tech people (even clients) using the issues and boards. Nobody has complained, though every now and then I've looked around for something else, but for me the number one priority is that the code and issues are in perfect sync with each other - much harder with a 3rd party tracker.
It would be a tough sell for my org to triple our license spend on GHEC just so we can teach a bunch of folks new software.
Absolutely. They definitely can't expect to sell this to teams/orgs with non-devs without introducing separate pricing for folks who just want to read/write to projects but maybe read-only for some aspects of a repo.
A FOSS plugin to mimic Service Desk on top of Github issues would be great.
You'd miss the infinite complexity of Jira workflow configuration, but that might be a good thing.
Not FOSS, but this is kind of what Zenhub was/is, right?
> I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org.
Yes, I'm an advisor for such a company. They are using Github Projects/Issues for all their internal development.
Their customer support uses a different ticketing system, though. Mostly because they need to interact with external users.
We tried (dev-centric org) but the non-technical users weren’t able to use it well / didn’t like it - so now we don’t have issue tracking at all for non technical stuff -.-
Oh my! That doesn't sound like a good place to be in. I hope y'all figure something out to get them onboard or migrate out.
We mostly use notion and google workspace for the non-technical stuff now and as far as I can tell both are pretty good.
Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago. Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
I am not sure if I am going to like this feature. I miss the simplicity. Guess those times re over.
I'm remembering the Redmine slide from Zach Holman's talk, where he makes fun of the overly complicated Redmine issue creation screen, compared to what the GitHub screen looked like (back in 2011).
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
I can handle these 3 changes but if they take it any further it's going the way of jira..
That's not how it works. It is going the way of Jira. What you mean is if it keeps going that way it will be Jira.
Until we get to the point we can decide things are finished and move on to other problems, everything will turn into Jira eventually. It's like entropy. We have the power to stop it, but it wouldn't guarantee those sweet, sweet growth targets.
The problem is Microsoft has two products in this space but everyone hates Azure DevOps which is supposed to be a JIRA competitor and GitHub is where all the momentum is. They'd love to ditch having to maintain ADO and GitHub long term but that means crapifying GitHub so they can migrate their ADO customers. At the same time they're hoping to pull Atlassian customers that use JIRA and GitHub to ditch the latter and just entirely be on GitHub.
What well end up with is a service that sucks to use for all cases.
ADO almost made me want to use Jira instead. Turned out that, while the product it not great, the pain I experienced using it had more to do with corporate processes than the software itself.
ditch the former?
I really dislike the use of former and latter. It’s confusing, people get it wrong, and it can be interpreted at least two different ways to make it ambiguous.
I agree that it tends to add cognitive overhead that could be avoided, but I don't see the ambiguity.
Lots of ideas above, rather speculative.
Overall, the claim above, as written, is a rather generalized prediction, not an inevitability.
Enterprise buying power and expectations create various pressures, sure. But there are other pressures and factors that need to be accounted for such as demands from other types of customers and the company’s expertise with what has worked well so far (simpler is better, compared to Jira).
Entropy is a law of physics, sure, but the ways and degrees to which it manifests in software is far from obvious or inevitable.
We live in a world of possible future scenarios, not of narrative-based certainties.
I predict GitHub Issues will remain considerably simpler than Jira for the next five years at least. As code analysis tools improve (traditional static analysis as well as LLM-based), I think we will see a lot of experimentation in this space.
GitHub is free for most people, so they are only beholden to large organizations and their feature requests. This is how it seems now - a feature creep by committee. It's getting more and more bloated and unwieldy, sort of like what happened to AWS.
This is just Conway’s Law.
Microsoft is a juggernaut.
It is less simple, but nowhere Jira-level, and yet still more useful (for my team and I).
We've been using GH Projects at my current org and program for two years. The one feature I wish it had was nested issues.
In Jira, you had Epic > Task > Sub-task and that's it. With GH, you can just have issue > issue > issue (insert "it's turtles/issues all the day down meme"). So it's more powerful, but can be ignored by folks who don't want to do this.
same here.
I guess it's Microsoft slowly making it cater to their enterprise clients
Microsoft is getting ready to replace Azure DevOps with GitHub.
This is fiction considering Microsoft is extensively using Azure DevOps internally and is still developing it. Moving projects away from it and to GitHub is impossible because they're incredibly far from having feature parity.
Feature parity is probably not required as long as the different teams are able to adapt their workflow to GitHub's approach. Anecdotally, every employee from Microsoft I've talk to about this point during the last two years keep telling me that ADO is over.
Feature parity is absolutely required. We are ADO customer because A) Inertia and B) GH Actions is nowhere close to features of ADO Pipelines.
Every conversation we have with Microsoft about our ADO -> GH migration is either get GH to feature party or if you force us to migrate, we will evaluate ALL our options.
People have been saying this for half a decade, and fearmongering everyone into moving elsewhere (sadly my team fell for it).
Azure Devops is such an underrated tool, it's a shame that it's being ignored by Microsoft. Not only that, but they're enshittifying it by turning into Github. I kid you not, it actually went backwards in terms of features. E.g. Instead of nifty UIs that was implemented for their pipelines, we now instead have to write shitty yaml files with absolutely no validation and guidance. This is the same company that (re)wrote Word, Excel and Powerpoint in the browser! The mental whiplash from witnessing this is very jarring.
The sub-issue structure seems much better than Jira's approach where everything has to fit into a hierarchy. Then it becomes hard to align on the definition of a certain level in the hierarchy.
This create-a-subissue-when-needed way is more sensible.
It's also not that different from what people have been using Task Lists for today: https://docs.github.com/en/get-started/writing-on-github/wor...
I think that's maybe my biggest question is what the interop looks like between Task Lists and Sub-Issues. Is there a "one-click upgrade" yet? What if I want to copy a list of Sub-Issues as Markdown Task List to copy into a Discussion or a Wiki somewhere?
You can use a single type of issue in Jira and just rely on linking them together
Yeah we ended up doing this. You should basically never use Epics or Subtasks in Jira because they have weird unnecessary restrictions that don't apply to normal tasks, especially around putting them in sprints.
Wow i didn't know that.
In other words, GitHub introduces "endless discussions if we're going to use subtasks or sub-issues in our WoW"
That's a leadership issue
And even then it affects us all and distracts us from the work we actually want to do.
I, for my part, would be happy if they could make basic search work for a start. Will the advanced search finally allow us to find the most basic things reliably?
What doesn't work?
If you search code for a string you know is there it is completely git or miss if it is found. Always has been like that.
Also see https://news.ycombinator.com/item?id=35144250
I assumed you were talking about issue search, since that's what the thread is about.
Oh yeah, where on the Internet does this work reliably?please don’t say gitlab
Sourcegraph.
grep -rli search_this some-repo # (or use rg if you prefer)
Holy shit what a good idea why doesn’t GitHub just let you use ripgrep?!?!?
Too expensive I assume.
Sorting code search results by date.
I would like it if Github could fix all the bugs with back button (broken browser history) first
So that's why they broke loading issue comments without JS. As if the (post-M$) UI hadn't been sluggish enough before...
It's neat there are more options for filtering though ime the new issues UI is less responsive, showing placeholder skeletons more frequently than I'd like. Perhaps less noticeable when a fast connection is always available but even just showing the total Open/Closed ticket counters can take a few seconds when it used to be instant.
I was excited to see this feature pop up in beta, specifically sub issues. VS code organizes their work with parent sprint issues ("iteration plan", see [1]). I started using this pattern on my own project and once i adapted, now prefer it. Now rather than using markdown bullet points, i can use first class sub issues which are slightly less awkward. Ultimately a minor feature addition, but if it pushes more people to use then pattern, i think it would be nice. Lighter weight than proper tools, and imho all you need for moderately complex projects if the suits dont have too many needs / influence.
[1]: https://github.com/microsoft/vscode/issues/237297
Instead of these features I want them to stop spam issues on my repos. All the issues I've gotten in the last year on my project are completely nonsensical. It's not even spam it's just like random URLs or complete nonsense from freshly created accounts that aren't trying to sell anything or just the issue template. And every time it costs me 2 clicks to click on "report" then I have to type "spam", click the spam category, then I have to type "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report description requirement, then I have to solve a captcha. All this despite the fact that I've had a GitHub account for like a decade and I've filed like 30+ spam reports, none of which were frivolous.
I opened GitHub after typing this comment and there it was, a notification from an obvious bot account opening an issues that's just 5 meaningless Korean letters with no description.
It might be worth trying the moderation tools that prevent interactions from accounts less than 24 hours old. Docs here https://docs.github.com/en/communities/moderating-comments-a...
I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.
Not bad, but I still have to say that zenhub does it better
Used that at an old job and it was the only project management software I didn't grow to hate. Fast, "built into" GitHub, and adds other value across the site, I miss it now at my current jira gig
Big +1, I used zenhub at one of my first jobs and I miss it to this day.
Its one of those things that I will forever evangelize for, because the one time I was able to use it, I had my most productive year ever. My github activity graph for the 18 months I got to use zenhub looked like a beautiful green meadow.
I've tried most other project management software. They all stink in one way or another. JIRA is a known problem, ClickUp, Monday, and friends aren't much better. I never liked pivotal, and its dead now, so doesn't really matter. And Github's projects feature is just too spartan to be useful
This seems... unneeded bloat? I guess there are some obsessive organizers out there, but a markdown checklist of steps - potentially with links to other tickets seems like all you need.
If you're going to improve something improve code review! Let me comment on and suggest diffs to lines the author did not touch. Like half the time I am reviewing code it is "Hey, you refactored this but you missed a usage in this other file" and right now I have to manually give them file and line number manually and hope for the best.
A lot of this will seem trivial if you haven't used Github for an organization's management of issues. This also lets you start off with a markdown checklist, and convert items to sub-issues.
> This also lets you start off with a markdown checklist, and convert items to sub-issues.
Wasn't that already possible with Tasklists? We did it using "- [ ] description", then clicking the covert-to-issue hover option.
See, but I do. For almost a decade, we have used it as-is for tickets and bug tracking, and it's never been a problem. I just don't see the use case for sub issues.
The issue types are similar to labels. I wonder why they didn't build on that.
The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields.
Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project).
An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway.
I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility.
The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status).
The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.
I wish they would build features to defend against those near-spam type comments where someone is lazy and appends their clearly unrelated issue onto an existing one that maybe shares a few keywords but nothing substantive.
It's not quite spam: there's often a real person behind it with a real issue but they need a (metaphorical) slap before they muddy the waters and disturb countless people already in the conversation.
This would be worthwhile for the individuals too - you often find a recurring pattern with all / most of their raised issues and with basic guidance they might up their game (or give up)
When you have issues in different repos but in the same board it seems very confusing that you can create them and then have to assign them to a repo for them to move out of being a Draft issue (well maybe it is not an issue yet rather a task). Maybe I'm using it wrong but I found this pretty strange. Most projects will have a backend and frontend repo certainly when building an app so I think not being able to manage issues against both projects made things a bit strange. Maybe I should use a different blank mono repo just for issues but then I imaging the integration with PRs and commit messages breaks.
Additionally I want to be able to have #PROJ-0002 style IDs for tasks, so for example I can add messages for tasks that affect both repos (e.g. "Imported types from GraphQL API into app (#BACKEND-1234, #FRONTEND-1234)") just having numbers is very limited and slightly confusing.
>This means there are no new UI patterns to slow you down,
requiring JS to simply view issues begs to differ....
I look forward to GitHub getting even slower and buggier than it is now.
There is a huge wall of placeholder being replaced with issues when the issues tab loads, which is pretty annoying when you got used to the old UI. But it’s nice to see M$ can still deliver features without Autocomplete Integration forced in it.
Nice additions - Buganizer has had these for years.
Good that issue types can be user defined.
A few jobs back I got “promoted” (honestly I didn’t want it but I digress) to an EM. First thing I did was ditch Jira for GH issues. I was hailed as a hero for it. Unfortunately it ended up being a disaster and we had to switch back a year or so later. These were some of the missing features so pretty exciting.
You should write Cliff's notes for the Odyssey. What an epic summary.
I just wish they'd improve the markdown autocomplete for issues and pull requests ... I'm not sure why it's so bad but even if i know two or three words in the issue title i almost never get the right issue to choose in the autocomplete list while typing in a markdown comment ...
They also changed the design of issue comments, but seemingly reverted it back to the old design in production? (If you check the first video on the blog you can see e.g. the profile picture inside of the comment, while the old and current version has it on the outside.)
I've almost stopped using GitHub as I switched over to vscode Github Pull Request Extension.
Bring back sorting code search results by date!
https://github.com/orgs/community/discussions/52932
Maybe they’ll add “Closed - won’t fix” and “Closed - stale” statuses next!
They already have "Closed as not planned (won't fix, can't repro, stale)". You can use labels for finer granularity if you want.
There is already close as unplanned, which can serve both if you're flexible
Ah, thought something had changed.
Been rather use to the key combo for inverting filtering on issues (E.g. show all issues without a particular label)...
That seems to have been nuked.
Strange that issue types is only available if your repository is part of an organization. Why is this not configurable at the repository level?
To upsell? To maintain consistency among repos? To facilitate use among GH Projects?
Next thing you know they just reimplement JIRA and everyone starts writing posts how much they hate it.
Ah this really feels like they could have tackled https://github.com/orgs/community/discussions/4993 too, what a missed opportunity, I'd love to be notified about some repositories again, which I had to unwatch now because of daily autobuild spam.
Behold: GitHub is becoming Jira!
Let us comment on the commit messages and create a better UI for editing messages for teams that take git history seriously, please. Are there no linux kernel devs at msft who can make this happen?
In the same vein, better reviewability of series of commits. It's absolutely baffling to me that GitHub still doesn't support the original workflow for Git.
Looks very good. I might switch from Gitlab Issues if I find a tool to convert issues
this happens after I've moved everything to height. downside is it was a lot of work. upside is height is amazing and I'm pleased with the choice. anyone else using it?
> anyone else using it?
We're looking for a new home, with Pivotal Tracker shutting down on April 30th (101 days left!). I had not heard of Height before.
On first glance, it looks like a genuinely modern project management service -- which is both interesting and unsettling.
We are loving it and we aren't even using it fully to its ability. For example we do almost no communication in the 'chat' that exists for each issue (in place of comments) since we are a very small team and still are talking mostly in slack about the issues, but I predict as we grow this will become a useful feature for us.
In the meantime we are loving the 'every issue can have sub-issues' and have customized the fields to our liking.
This is a tool with a lot of power. I can see a well-intentioned PM going crazy with it, but for our needs I was startled with how great it is.
what is height?
Maybe this? https://height.app/
I am looking forward to project management without Jira!
From Copilot integration that you can’t disable if you accidentally clicked something once (you can only now as of a few days ago hide the UI, but you are still not able to disable it in settings), to this issues UI aglomeration.
The Microsoftization/enshittification of Github continues apace.
also let people sort repositories by the ratio of open requests to closed requests, average amount of time to respond on an issue
Slowly inching towards something usable for companies / large projects...
One big thing missing is resolution status for issues, like "cancelled", "complete", ...
You can close as complete (default) or unplanned today. It's called the 'reason'.
The enjirafication of github continues.
I've been waiting so long for this. Finally, we can have Epics that are not a pain in the ass!
Corporate customers do pay the bills i suppose.
They have time to work on this micromanagement feature yet can't fix the broken conversation workflow when reviewing PRs.
Smh.
GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?
What type of registry? GitHub packages?
I would hazard a guess, more in the vein of the much-maligned "Windows Registry".
https://en.wikipedia.org/wiki/Windows_Registry