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.<p>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 <i>no</i> 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.
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.
> This means there are no new UI patterns to slow you down,<p>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
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.<p>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.<p>But it's been years now, and it's not an easy love. It's work! It's <i>so painful</i> 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.<p>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.
Great, a few more decades and it might become a usable bugtracker.<p>What's next on the list? Maybe priority/severity or status/resolution?<p>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'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?<p>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.
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).
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.<p>This create-a-subissue-when-needed way is more sensible.
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.<p>[1]: <a href="https://github.com/microsoft/vscode/issues/237297">https://github.com/microsoft/vscode/issues/237297</a>
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.<p>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<p>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
This seems... unneeded bloat? I guess there are some obsessive organizers out there, but a markdown checklist of steps - potentially with <i>links to other tickets</i> seems like all you need.<p>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.
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.<p>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).<p>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.<p>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.<p>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).<p>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.<p>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.
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.<p>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.)
Bring back sorting code search results by date!<p><a href="https://github.com/orgs/community/discussions/52932">https://github.com/orgs/community/discussions/52932</a>
Ah, thought something had changed.<p>Been rather use to the key combo for inverting filtering on issues (E.g. show all issues without a particular label)...<p>That seems to have been nuked.
Ah this really feels like they could have tackled <a href="https://github.com/orgs/community/discussions/4993">https://github.com/orgs/community/discussions/4993</a> 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?
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?
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.<p>The Microsoftization/enshittification of Github continues apace.
Slowly inching towards something usable for companies / large projects...<p>One big thing missing is resolution status for issues, like "cancelled", "complete", ...
GitHub was better before MSFT took over. MSFT introduces bureaucratic fluff, hierarchies and loads of unnecessary complexities. How about adding a registry?