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.
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.
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.
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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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).
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.
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?
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
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.
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?
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?
sensanaty|1 year ago
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.
deckar01|1 year ago
adsteel_|1 year ago
christophilus|1 year ago
blharr|1 year ago
hamandcheese|1 year ago
alexpovel|1 year 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.
https://github.com/alexpovel/issuedigger
TeMPOraL|1 year ago
[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.
hnlmorg|1 year ago
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.
grajaganDev|1 year ago
ruraljuror|1 year ago
rukshn|1 year ago
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
anon7000|1 year ago
But you’re completely right, GH search is truly bad
Sytten|1 year ago
tommoor|1 year ago
unknown|1 year ago
[deleted]
eviks|1 year ago
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
maeil|1 year ago
antics|1 year ago
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.
btown|1 year ago
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.
motorest|1 year ago
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.
habosa|1 year ago
SOLAR_FIELDS|1 year ago
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.
whalesalad|1 year ago
eslaught|1 year ago
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.
Calzifer|1 year ago
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.
IshKebab|1 year ago
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.
StableAlkyne|1 year ago
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?
chrisandchris|1 year ago
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).
rbetts|1 year ago
sangeeth96|1 year ago
TeMPOraL|1 year ago
FridgeSeal|1 year ago
treyd|1 year ago
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.
bastardoperator|1 year ago
JensRantil|1 year ago
This is also what is happening with GH issues.
dmd|1 year ago
Compared to SN, Jira is a breath of fresh air.
sangeeth96|1 year ago
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.
acjohnson55|1 year ago
yakshaving_jgt|1 year ago
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.
saxonww|1 year ago
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.
madeofpalk|1 year ago
drcongo|1 year ago
jjayj|1 year ago
cyberax|1 year ago
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.
portaouflop|1 year ago
Wicher|1 year ago
decide1000|1 year ago
captn3m0|1 year ago
Slides 56 and 57 at https://speakerdeck.com/holman/how-github-uses-github-to-bui...
Gigachad|1 year ago
renegade-otter|1 year ago
jonpurdy|1 year ago
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.
dacryn|1 year ago
I guess it's Microsoft slowly making it cater to their enterprise clients
kkaatii|1 year ago
This create-a-subissue-when-needed way is more sensible.
WorldMaker|1 year ago
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?
trallnag|1 year ago
isodev|1 year ago
Nuzzerino|1 year ago
weinzierl|1 year ago
edflsafoiewq|1 year ago
javier2|1 year ago
shiomiru|1 year ago
Springtime|1 year ago
cloverich|1 year ago
[1]: https://github.com/microsoft/vscode/issues/237297
shpx|1 year ago
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.
bsmth|1 year ago
I share your frustration with this, and in my experience a lot of noise comes from these types of accounts.
paradox460|1 year ago
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
hamandcheese|1 year ago
donatj|1 year ago
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.
replete|1 year ago
politelemon|1 year ago
carwyn|1 year ago
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.
nmstoker|1 year ago
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.
nmstoker|1 year ago
andy_ppp|1 year ago
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.
akimbostrawman|1 year ago
requiring JS to simply view issues begs to differ....
FridgeSeal|1 year ago
prymitive|1 year ago
grajaganDev|1 year ago
Good that issue types can be user defined.
localghost3000|1 year ago
aklemm|1 year ago
breatheoften|1 year ago
whataguy|1 year ago
jerrygoyal|1 year ago
zb3|1 year ago
https://github.com/orgs/community/discussions/52932
mikeocool|1 year ago
edflsafoiewq|1 year ago
paulryanrogers|1 year ago
tehbeard|1 year ago
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.
jxi|1 year ago
paulryanrogers|1 year ago
ozim|1 year ago
riidom|1 year ago
maxcruer|1 year ago
bnewman85|1 year ago
atq2119|1 year ago
ttoinou|1 year ago
joshSzep|1 year ago
quesera|1 year ago
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.
mg74|1 year ago
landsman|1 year ago
stock_toaster|1 year ago
The Microsoftization/enshittification of Github continues apace.
vivzkestrel|1 year ago
the_duke|1 year ago
One big thing missing is resolution status for issues, like "cancelled", "complete", ...
paulryanrogers|1 year ago
cratermoon|1 year ago
polycaster|1 year ago
liontwist|1 year ago
xyst|1 year ago
Smh.
tw12312831|1 year ago
shamiln|1 year ago