This is why you don’t announce future changes until they’re essentially ready to go out the door. Apple used to understand this better than most. Until you build the feature, you’ll have people asking you constantly when it’ll be done. After you build it, you’ll have people complaining that it doesn’t work exactly like they imagined it in their head. If you end up not building it and say so, you’ll get attacked for it, even by people who never knew about the plans before the cancellation.
Keep quiet about internal plans only you can affect. Let features requests come to you, monitor interest in those, and reply if they’re interesting or not feasible, so you can discuss and figure out what would work best for your users. Engage but don’t commit unless you’re certain something will happen.
I’m surprised the conversation hasn’t devolved to a bigger mess yet (maybe it’s being well moderated). It’s a shame they’re having to preemptively lock issues, but I completely get it. It’s exhausting having to deal with abuse on public forums when you’re on the receiving end and always have to keep your conposure.
I think I agree with you for discrete product releases, but for ongoing SaaS and moreso PaaS, it's helpful for integrations to have some visibility on your roadmap. I'm might just write a hack workaround for some issue if I have a belief that in 2024 you'll solve X -- I've got bigger fish to fry. But if I know you've removed it from your roadmap and it was planned by me, I can put it on mine to resolve. Surprising me with features means more often than I care to admit I write something to solve a problem, use it for a few months, and then vendor comes out with a solution to it that's close enough and better supported so I toss out code -- with a roadmap I could have avoided overlapping efforts.
But I'm more on the operational side - so I care more than most about the integrations with lots of vendors, different PoV's may of course differ.
I feel you. You seem to be reasonable and empathetic and understand that sometimes priorities change and that an imperfect roadmap can still bring benefits over a hidden one. On the other hand, there are a lot of people who feel entitled to get anything you ever mentioned, even (especially) if they’re getting it for free, and managing those people when they complain is time consuming and drains your sanity. Both of which take your time and energy away from improving the product to all the reasonable people.
There was a time when the dream of open source was healthy and strong. GitHub was a big part of the movement. So it shouldn't be surprising that they did more of their planning in the open than a company like Apple.
There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.
I'm tempted to agree with you anyways, since I've been in the situation before where we wanted to change things we were making while we were making them. You don't want to give off the impression that you don't know what you're doing.
Honestly, this kinda goes back to agile vs. waterfall too. It's all about defining requirements and meeting them.
> There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.
To clarify, I’m not advocating for active secrecy as goal, especially not inside the company. I’m more arguing for not actively sharing with the outside what you don’t have to because they don’t have the same context you do and will judge your decision out of their own biased feelings. Which then leads to you having to waste an inordinate amount of time explaining yourself.
The only one that directly annoys me is not being able to have threaded comments at the PR level. https://github.com/github/roadmap/issues/552 You can do it with "quoting", which is fine if there are two of you but turns into a mess if there's more than that.
They've said that they're watching the discussions for feedback, so I hope they listen and implement that one.
Happy that they are being transparent (rather than letting the issues rot), annoyed that they appear to be prioritising marginally useful AI stuff for basic UX.
That is surprising to me. I am so tired of commenting on random lines with the usual "commenting on a random line for the sake of threading" apology.
Also commenting on random irrelevant changed line because you can't comment on unchanged ones (but they might need changes due to rest of the PR).
Github code review is horrible and I think it's actually worse than not having anything at all because now it's hard to convince people we should switch to something better. "Oh I don't want to learn another tool, github is good enough"
Going to stick my neck out here.
A lot of these "improvements" fall into the following 3 categories:
1) More complexity around issue tracking
2) More complexity around permissions
3) IDE-ness and general visual-studioification of the web interface.
Since many of the issues make GitHub bloated and more difficult to use for general use cases, they _should_ be removed.
I agree, also the source code viewer (not sure what it's called) has regressed tremendously. A few years back it was simple, quite snappy and just worked. Now it has become slow and bloated and barely works for me on the desktop and the mobile version is full of rendering bugs rendering the whole thing rather useless. (Using firefox both on mobile and on the PC)
All they had to do, literally, was to do nothing but no, can't have that. MUST ADD BLOAT.
GitHub is primarily as issue tracker though... and code runner I guess.
Yes, the last thing they need is more bloat. I wish they removed achievements as well.
Ever since GitHub was bought by Microsoft things have got worse for me as an end user -- browser compatibility is worse and I run into bugs frequently when on not-chrome; their academic programme now requires an insanely invasive localisation check that instantly fails for me on Linux and their support couldn't advance the process as I hadn't submitted an application yet; and their tooling slowly pushes people away from FOSS and towards proprietary methods. I wish they'd figure out how to make it a hacker friendly place again.
out of curiosity what browser do you have in mind?
I use Firefox on Linux and I didn't have any issues annoying enough to stick in my memory.
I use Firefox on Windows (on multiple machines), and when somebody has an image embedded in an issue or comment in Github, and I click it to see the original sized image it will not load, and simply shows a blank page instead. It's been like this for two years or so.
Same here.
(I think I've ever seen one minor bug: for any repo in the clone dropdown, the "SSH" tab was hidden for me a while ago. Unfortunately I don't remember if this was browser related.)
Using Librewolf 131.0.3-1. Going to the GitHub homepage makes the tab freeze and I have to go to /login or a repository page directly.
No op, but videos/gif (used a lot for demos) don't work , you have to refresh the page
> and their tooling slowly pushes people away from FOSS and towards proprietary methods.
Can you explain this one in a bit more detail?
They said they are pushed away from Linux and non-Chrome
"After an in-depth review, we’ve identified a number of open issues that have become outdated over time—some for several years."
Sounds fair enough to me.
If they were all truly outdated, then sure. But as the comments have pointed out, Github also closed at least half a dozen still-relevant issues like "Commenting on unchanged lines in a pull request" that would be significant UX improvements.
"Leave them until they're outdated" isn't a valid way to deal with issues in my book.
Clutter accumulates in any bug tracker.
Ideally they'd've been cleaning it out more regularly and these feature requests would've been marked "not currently on the roadmap" and closed much sooner.
But I don't think I've ever seen a team do a perfect job of that, and I'm probably worse at it than they are.
Plenty of large projects need to go through and do a bit of a sweep of old issues every few years. If your projects have the discipline to never need that I congratulate you.
But "Don't sweat over any little issue, especially if they have gone multiple years without major complaints from a sizeable part of your user base" is.
[dead]
Where did the "basic functionality" quote come from? I haven't looked at all 42 in detail, but it largely seems like _advanced_ functionality to me.
This is exactly why HN discourages editorialising titles. This one was clearly modified to spark outrage. People click on it with a predisposition to be mad instead of being given the chance to reflect first.
Yeah I don't see the term "basic functionality" anywhere on the linked page, having that in quotes in the post title here feels misleading to me.
Renaming this post to match the original title would be appropriate: "Deprecating Outdated Issues on the GitHub Public Roadmap"
I've emailed @dang
How on earth is threading comments on PRs advanced in any way?
Maybe overcomplicated is the better term? Constantly adding "basic" features on top of each other might create us a Jira.
"At GitHub, transparency and clarity are at the heart of our relationship with the community."
When these kind of carefully crafted prety slogans has to be a prime statement before anything is told then my suspicious mind gets very alert. Probably even overcompensate. Do people take these kind of forefront self evaluations as facts or have suspicion when this has to be announced and highlighted, stated (instead of being obvious). I do not know why (of course I do!) but these kind of self admirative statements have the opposite effect on me. Even when they are true.
I mean, it was clearly phrased by the marketing team, but it's on a post where they actively close a lot of bugs and clarify they won't be doing them, instead of doing what most companies do and just ignoring them for years.
[deleted]
There's some weird stuff there.
> GitHub Actions: Artifacts v4 available in GitHub Enterprise Server
So they're deprecating Artifacts V3 next week, and now announced they won't upgrade Enterprise Server to v4?
This one doesn’t make any sense, it HAS to be a mistake
The trouble with bug tracking / project management software is that everybody wants Just One More Feature.
But if you implement them all, it will become an overcomplicated mess, somebody will replace it with a simpler version, and the cycle will repeat.
Would I like some of the features they've decided not to implement? Yes.
Would I hate the results if they implemented everything on this list? Also yes.
And making everything configurable so you can pick the exact subset you want is (a) an incredible amount of work to make the resulting combinatorial explosion of possible choices all work nicely (b) tends to inevitably lead to something like JIRA.
I do appreciate people being annoyed about specific features they'd really like getting removed from the roadmap, but so it goes.
I assume none of their AI features were deprecated.
Whilst I'd still take it with a grain of salt, two have been. Mostly their code scanning AI stuff though (or pieces of them), which... Has had a lot of issues, compared to more traditional approaches.
+ Code scanning: AI-powered autofixes for CodeQL alerts integrated into VS Code
+ Secret scanning push protection for gists
I am going to call it, Microsoft has not been particularly good stewards of GitHub.
They have over complicated so much of it to please corporate customers that it has really lost what made it great to begin with.
It used to make everything seem simple and manageable. Changes were slow, sure, but they felt like they were at least thought through. The docs used to be simple and easy to navigate. Everything is about 10x more complex now.
I wish they put their focus more on GitHub Projects/Issues, it is just too slow.
Could Github developer workflow metadata (e.g. issues) be exported/serialized into a git repo for decentralized replication and/or import into an alternative?
I have it running in one of my repos using a GitHub Action that's triggered when an issue is created or updated - it commits a JSON export of that issue back to the repo.
Then I can git clone the repo and get all of the issues data.
Perfect, thanks!
not to git but there are bots to export to ie gitlab
I wish they would put more effort in Github Issues (the project management product). They are so close to have something that just exactly what I need. But it seems like they haven't touched it in a couple of years. There are still many rough edges that has been there since the beta.
Like issue search being not instant, it's impossible to find duplicates if it takes 5 seconds per search and not 500ms.
And so it begins. It was good whilst it lasted.
The inability to comment on any line in a PR is a real pain. I’m disappointed to see the plans for this abandoned.
Death by committee or death by microsoft, take your pick.
> Commenting on unchanged lines in a pull request
This is infuriating that it's missing. Not being able to just say "Hey, missed updating this line" is just an insane oversight
Guess who turned GitHub into a SPOF?
We did.
[dead]
Enshifittication at work.
I disagree. Etymologically, "enshittification" is the ongoing transformation of something into shit. But here, GitHub is declining to make certain changes; it is expressly resisting transformation. At best you could argue it was already shit due to the lack of these specific enhancements that would deshittify it.
Doctorow, who first studied enshittification, identified three distinct phases of the process: "First, platforms are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die." I don't see how this applies to the specific set of declined enhancements.
This is why you don’t announce future changes until they’re essentially ready to go out the door. Apple used to understand this better than most. Until you build the feature, you’ll have people asking you constantly when it’ll be done. After you build it, you’ll have people complaining that it doesn’t work exactly like they imagined it in their head. If you end up not building it and say so, you’ll get attacked for it, even by people who never knew about the plans before the cancellation.
Keep quiet about internal plans only you can affect. Let features requests come to you, monitor interest in those, and reply if they’re interesting or not feasible, so you can discuss and figure out what would work best for your users. Engage but don’t commit unless you’re certain something will happen.
I’m surprised the conversation hasn’t devolved to a bigger mess yet (maybe it’s being well moderated). It’s a shame they’re having to preemptively lock issues, but I completely get it. It’s exhausting having to deal with abuse on public forums when you’re on the receiving end and always have to keep your conposure.
I think I agree with you for discrete product releases, but for ongoing SaaS and moreso PaaS, it's helpful for integrations to have some visibility on your roadmap. I'm might just write a hack workaround for some issue if I have a belief that in 2024 you'll solve X -- I've got bigger fish to fry. But if I know you've removed it from your roadmap and it was planned by me, I can put it on mine to resolve. Surprising me with features means more often than I care to admit I write something to solve a problem, use it for a few months, and then vendor comes out with a solution to it that's close enough and better supported so I toss out code -- with a roadmap I could have avoided overlapping efforts.
But I'm more on the operational side - so I care more than most about the integrations with lots of vendors, different PoV's may of course differ.
I feel you. You seem to be reasonable and empathetic and understand that sometimes priorities change and that an imperfect roadmap can still bring benefits over a hidden one. On the other hand, there are a lot of people who feel entitled to get anything you ever mentioned, even (especially) if they’re getting it for free, and managing those people when they complain is time consuming and drains your sanity. Both of which take your time and energy away from improving the product to all the reasonable people.
There was a time when the dream of open source was healthy and strong. GitHub was a big part of the movement. So it shouldn't be surprising that they did more of their planning in the open than a company like Apple.
There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.
I'm tempted to agree with you anyways, since I've been in the situation before where we wanted to change things we were making while we were making them. You don't want to give off the impression that you don't know what you're doing.
Honestly, this kinda goes back to agile vs. waterfall too. It's all about defining requirements and meeting them.
> There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.
To clarify, I’m not advocating for active secrecy as goal, especially not inside the company. I’m more arguing for not actively sharing with the outside what you don’t have to because they don’t have the same context you do and will judge your decision out of their own biased feelings. Which then leads to you having to waste an inordinate amount of time explaining yourself.
The only one that directly annoys me is not being able to have threaded comments at the PR level. https://github.com/github/roadmap/issues/552 You can do it with "quoting", which is fine if there are two of you but turns into a mess if there's more than that.
They've said that they're watching the discussions for feedback, so I hope they listen and implement that one.
Happy that they are being transparent (rather than letting the issues rot), annoyed that they appear to be prioritising marginally useful AI stuff for basic UX.
That is surprising to me. I am so tired of commenting on random lines with the usual "commenting on a random line for the sake of threading" apology.
Also commenting on random irrelevant changed line because you can't comment on unchanged ones (but they might need changes due to rest of the PR).
Github code review is horrible and I think it's actually worse than not having anything at all because now it's hard to convince people we should switch to something better. "Oh I don't want to learn another tool, github is good enough"
Going to stick my neck out here.
A lot of these "improvements" fall into the following 3 categories:
1) More complexity around issue tracking
2) More complexity around permissions
3) IDE-ness and general visual-studioification of the web interface.
Since many of the issues make GitHub bloated and more difficult to use for general use cases, they _should_ be removed.
I agree, also the source code viewer (not sure what it's called) has regressed tremendously. A few years back it was simple, quite snappy and just worked. Now it has become slow and bloated and barely works for me on the desktop and the mobile version is full of rendering bugs rendering the whole thing rather useless. (Using firefox both on mobile and on the PC)
All they had to do, literally, was to do nothing but no, can't have that. MUST ADD BLOAT.
GitHub is primarily as issue tracker though... and code runner I guess.
Yes, the last thing they need is more bloat. I wish they removed achievements as well.
Ever since GitHub was bought by Microsoft things have got worse for me as an end user -- browser compatibility is worse and I run into bugs frequently when on not-chrome; their academic programme now requires an insanely invasive localisation check that instantly fails for me on Linux and their support couldn't advance the process as I hadn't submitted an application yet; and their tooling slowly pushes people away from FOSS and towards proprietary methods. I wish they'd figure out how to make it a hacker friendly place again.
out of curiosity what browser do you have in mind?
I use Firefox on Linux and I didn't have any issues annoying enough to stick in my memory.
I use Firefox on Windows (on multiple machines), and when somebody has an image embedded in an issue or comment in Github, and I click it to see the original sized image it will not load, and simply shows a blank page instead. It's been like this for two years or so.
Same here.
(I think I've ever seen one minor bug: for any repo in the clone dropdown, the "SSH" tab was hidden for me a while ago. Unfortunately I don't remember if this was browser related.)
Using Librewolf 131.0.3-1. Going to the GitHub homepage makes the tab freeze and I have to go to /login or a repository page directly.
No op, but videos/gif (used a lot for demos) don't work , you have to refresh the page
> and their tooling slowly pushes people away from FOSS and towards proprietary methods.
Can you explain this one in a bit more detail?
They said they are pushed away from Linux and non-Chrome
"After an in-depth review, we’ve identified a number of open issues that have become outdated over time—some for several years."
Sounds fair enough to me.
If they were all truly outdated, then sure. But as the comments have pointed out, Github also closed at least half a dozen still-relevant issues like "Commenting on unchanged lines in a pull request" that would be significant UX improvements.
"Leave them until they're outdated" isn't a valid way to deal with issues in my book.
Clutter accumulates in any bug tracker.
Ideally they'd've been cleaning it out more regularly and these feature requests would've been marked "not currently on the roadmap" and closed much sooner.
But I don't think I've ever seen a team do a perfect job of that, and I'm probably worse at it than they are.
Plenty of large projects need to go through and do a bit of a sweep of old issues every few years. If your projects have the discipline to never need that I congratulate you.
But "Don't sweat over any little issue, especially if they have gone multiple years without major complaints from a sizeable part of your user base" is.
[dead]
Where did the "basic functionality" quote come from? I haven't looked at all 42 in detail, but it largely seems like _advanced_ functionality to me.
This is exactly why HN discourages editorialising titles. This one was clearly modified to spark outrage. People click on it with a predisposition to be mad instead of being given the chance to reflect first.
Yeah I don't see the term "basic functionality" anywhere on the linked page, having that in quotes in the post title here feels misleading to me.
Renaming this post to match the original title would be appropriate: "Deprecating Outdated Issues on the GitHub Public Roadmap"
I've emailed @dang
How on earth is threading comments on PRs advanced in any way?
Maybe overcomplicated is the better term? Constantly adding "basic" features on top of each other might create us a Jira.
"At GitHub, transparency and clarity are at the heart of our relationship with the community."
When these kind of carefully crafted prety slogans has to be a prime statement before anything is told then my suspicious mind gets very alert. Probably even overcompensate. Do people take these kind of forefront self evaluations as facts or have suspicion when this has to be announced and highlighted, stated (instead of being obvious). I do not know why (of course I do!) but these kind of self admirative statements have the opposite effect on me. Even when they are true.
I mean, it was clearly phrased by the marketing team, but it's on a post where they actively close a lot of bugs and clarify they won't be doing them, instead of doing what most companies do and just ignoring them for years.
There's some weird stuff there.
> GitHub Actions: Artifacts v4 available in GitHub Enterprise Server
So they're deprecating Artifacts V3 next week, and now announced they won't upgrade Enterprise Server to v4?
This one doesn’t make any sense, it HAS to be a mistake
The trouble with bug tracking / project management software is that everybody wants Just One More Feature.
But if you implement them all, it will become an overcomplicated mess, somebody will replace it with a simpler version, and the cycle will repeat.
Would I like some of the features they've decided not to implement? Yes.
Would I hate the results if they implemented everything on this list? Also yes.
And making everything configurable so you can pick the exact subset you want is (a) an incredible amount of work to make the resulting combinatorial explosion of possible choices all work nicely (b) tends to inevitably lead to something like JIRA.
I do appreciate people being annoyed about specific features they'd really like getting removed from the roadmap, but so it goes.
I assume none of their AI features were deprecated.
Whilst I'd still take it with a grain of salt, two have been. Mostly their code scanning AI stuff though (or pieces of them), which... Has had a lot of issues, compared to more traditional approaches.
+ Code scanning: AI-powered autofixes for CodeQL alerts integrated into VS Code
+ Secret scanning push protection for gists
I am going to call it, Microsoft has not been particularly good stewards of GitHub.
They have over complicated so much of it to please corporate customers that it has really lost what made it great to begin with.
It used to make everything seem simple and manageable. Changes were slow, sure, but they felt like they were at least thought through. The docs used to be simple and easy to navigate. Everything is about 10x more complex now.
I wish they put their focus more on GitHub Projects/Issues, it is just too slow.
Could Github developer workflow metadata (e.g. issues) be exported/serialized into a git repo for decentralized replication and/or import into an alternative?
Yes. I built a tool for that a few months ago: https://github.com/simonw/fetch-github-issues
I have it running in one of my repos using a GitHub Action that's triggered when an issue is created or updated - it commits a JSON export of that issue back to the repo.
Then I can git clone the repo and get all of the issues data.
Perfect, thanks!
not to git but there are bots to export to ie gitlab
I wish they would put more effort in Github Issues (the project management product). They are so close to have something that just exactly what I need. But it seems like they haven't touched it in a couple of years. There are still many rough edges that has been there since the beta.
Like issue search being not instant, it's impossible to find duplicates if it takes 5 seconds per search and not 500ms.
And so it begins. It was good whilst it lasted.
The inability to comment on any line in a PR is a real pain. I’m disappointed to see the plans for this abandoned.
Death by committee or death by microsoft, take your pick.
> Commenting on unchanged lines in a pull request
This is infuriating that it's missing. Not being able to just say "Hey, missed updating this line" is just an insane oversight
Guess who turned GitHub into a SPOF?
We did.
[dead]
Enshifittication at work.
I disagree. Etymologically, "enshittification" is the ongoing transformation of something into shit. But here, GitHub is declining to make certain changes; it is expressly resisting transformation. At best you could argue it was already shit due to the lack of these specific enhancements that would deshittify it.
Doctorow, who first studied enshittification, identified three distinct phases of the process: "First, platforms are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die." I don't see how this applies to the specific set of declined enhancements.