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.
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.
Not open source right now but if people are interested I could clean up the code.
[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.
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.
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
But you’re completely right, GH search is truly bad
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
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.
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.
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.
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.
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.
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?
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).
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.
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.
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.
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.
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?
I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
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).
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.
This is also what is happening with GH issues.
Compared to SN, Jira is a breath of fresh air.
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.
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.
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.
> 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.
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.
You'd miss the infinite complexity of Jira workflow configuration, but that might be a good thing.
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.
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
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.
Microsoft is a juggernaut.
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.
I guess it's Microsoft slowly making it cater to their enterprise clients
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?
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.
I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.
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
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
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.
Wasn't that already possible with Tasklists? We did it using "- [ ] description", then clicking the covert-to-issue hover option.
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.
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.
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.
requiring JS to simply view issues begs to differ....
Good that issue types can be user defined.
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.
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.
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.
The Microsoftization/enshittification of Github continues apace.
One big thing missing is resolution status for issues, like "cancelled", "complete", ...
Smh.
