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.
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.
You only evet had visibility into a daydream that changed. What good is, no scratch that, there is no good in knowing something that you only think you know. It's negative value. It's worse than knowing nothing at all. It doesn't matter how much you want to know, and how good it feels to have that want pacified.
Similarly, this is also why even if someone does publish a road map, you should ignore it and only deal with whatever exists as it exists right now. Make all decisions, including looking ahead, based on nothing but the current state.
I don’t think closing off all internal discussion of future improvements necessarily the way to go, though? Sharing things like draft standards and programming languages enhancement proposals seems to work out pretty well.
Issue trackers, not so much. I think part of the problem is that the reply box is right there, inviting drive-by opinions, and makes it hard to keep things in perspective.
What’s preferable, clarity on what’s actively planned, or ambiguity with dozens of features languishing on the public roadmap without any updates?
> 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.
What's so exhausting about ignoring like all of these corporates do?
Maybe have some empathy for the people who have to interact with individual customers. There’s not an amorphous blob of “corporates” who deals with everything, there are real people with an life just as rich as yours on the other side.
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.
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.
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.
You can comment on any line, a whole file, or a whole PR and all comments are threaded and tracked to resolution. They are never hidden because they’re outdated or because the discussion is too long.
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"
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.
All they had to do, literally, was to do nothing but no, can't have that. MUST ADD BLOAT.
But then I remembered about search. I use and enjoy GitHub code search a lot, and it makes me a better developer.
I use Firefox on Linux and I didn't have any issues annoying enough to stick in my memory.
(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.)
> GitHub Actions: Artifacts v4 available in GitHub Enterprise Server #930 … We will be extending support for v4 of the actions to upload and download artifacts to GitHub Enterprise Server (GHES). This new version improves artifact upload and download speeds by up to 98%.
I don‘t understand at all how this is not a priority anymore. :-(
To some organizations, having to use a cloud SaaS instead of hosting the application on-prem is a con.
At our self-hosted GHE instance, we use either (self-hosted) Artifactory, or raw S3. Fast, and easy to work with.
Sounds fair enough to me.
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.
Submitters: "Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html
Renaming this post to match the original title would be appropriate: "Deprecating Outdated Issues on the GitHub Public Roadmap"
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.
> 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?
Personally I'm not a fan of "we haven't got round to it in ages, let's close it"
Issues at the bottom of your backlog:
a) Cost you basically nothing
b) Document previous demand
c) Can be useful tasks for new joiners who are skilling up on the project
d) Can be bumped if demand re-awakens
e) Documents known feature gaps
+ Code scanning: AI-powered autofixes for CodeQL alerts integrated into VS Code
+ Secret scanning push protection for gists
customers don't care about those, though, and this is a good way to distract from any discussions about the implications.
Maybe the idea was to rip the band-aid off and hope the outrage burns out quickly.
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.
For example, the top one in that list is the "Command Palette" -- but it's already live and working fine! And I'm pretty sure "Precise code navigation" also already exists for TypeScript.
So are these features that are already GA going to be removed..?
We had conflated JS and TS support into a single release issue. JS support never landed, but TS did: https://github.blog/changelog/2024-03-14-precise-code-naviga...
When we first created the release issue, the thinking was that we wanted to launch support for those two languages at the same time, and for that support to be compatible with each other. (So we could correctly follow e.g. a TS library referencing a definition in an upstream JS library.)
Unfortunately we never got JS support to the point where we could GA it. Largely for scaling reasons — there is a HUGE amount of JS on GitHub, and JS is a dynamic enough language that we have to do more per-file processing on it than for TS or Python. We decided not to wait for JS to be GA-ready before releasing TS, but then never corrected the release issue to account for that.
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.
No command palette? JS and TS precise code navigation being cancelled? SSH connections to GitHub Actions?
What on earth is this new “roadmap” then? More AI garbage slop and less focus on developer tooling and source control?
This is a very dark day.
This is infuriating that it's missing. Not being able to just say "Hey, missed updating this line" is just an insane oversight
We did.
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.
