[HN Gopher] Deprecating outdated issues on the GitHub public roa...
___________________________________________________________________
Deprecating outdated issues on the GitHub public roadmap
Author : preya2k
Score : 100 points
Date : 2024-11-25 08:48 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| preya2k wrote:
| I assume none of their AI features were deprecated.
| shakna wrote:
| 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
| MortyWaves wrote:
| CodeQL has never worked anyway and I'm unsure why it's even a
| thing given it doesn't work
| jonathonlacher wrote:
| Could you expand on what doesn't work for you?
| red-iron-pine wrote:
| all of the important AI features, like building models from the
| code, were almost certainly pushed.
|
| customers don't care about those, though, and this is a good
| way to distract from any discussions about the implications.
| walterbell wrote:
| Could Github developer workflow metadata (e.g. issues) be
| exported/serialized into a git repo for decentralized replication
| and/or import into an alternative?
| nicman23 wrote:
| not to git but there are bots to export to ie gitlab
| simonw wrote:
| 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.
| walterbell wrote:
| Perfect, thanks!
| oldpersonintx wrote:
| Guess who turned GitHub into a SPOF?
|
| We did.
| littlestymaar wrote:
| Enshifittication at work.
| rgovostes wrote:
| 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.
| Brian_K_White wrote:
| It got shittier, but not in the way Cory Doctorow was talking
| about.
| azalemeth wrote:
| 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.
| Szpadel wrote:
| 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.
| Drakim wrote:
| 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.
| pitaj wrote:
| Can you link a specific (publicly accessible) example? I
| want to try reproducing.
| Pooge wrote:
| 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.
| kreetx wrote:
| 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.)
| kelvinjps10 wrote:
| No op, but videos/gif (used a lot for demos) don't work , you
| have to refresh the page
| Mashimo wrote:
| > and their tooling slowly pushes people away from FOSS and
| towards proprietary methods.
|
| Can you explain this one in a bit more detail?
| croemer wrote:
| They said they are pushed away from Linux and non-Chrome
| fergie wrote:
| 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.
| dandellion wrote:
| Yes, the last thing they need is more bloat. I wish they
| removed achievements as well.
| samiv wrote:
| 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.
| nixpulvis wrote:
| GitHub is primarily as issue tracker though... and code runner
| I guess.
| alganet wrote:
| I was writing about this. GitHub is essentially a bloated git
| plus keys plus email list.
|
| But then I remembered about search. I use and enjoy GitHub
| code search a lot, and it makes me a better developer.
| alganet wrote:
| Yes. And maybe this goes for features that are already
| implemented as well.
| simonw wrote:
| "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.
| riiii wrote:
| "Leave them until they're outdated" isn't a valid way to deal
| with issues in my book.
| simonw wrote:
| 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.
| rglullis wrote:
| 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.
| mst wrote:
| 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.
| Pikamander2 wrote:
| 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.
| not2b wrote:
| That's a big one. I need to deal with perforce which has
| plenty not to like, but I frequently attach comments on
| unchanged lines in code reviews saying something like "you'll
| need to change this too", and their code review tool supports
| this.
| brainwipe wrote:
| 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.
| dmazin wrote:
| 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.
| progbits wrote:
| 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"
| habosa wrote:
| Shameless plug but this is one of the many GitHub code review
| limitations I set out to fix when I created CodeApprove
| (https://codeapprove.com).
|
| 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.
| Deukhoofd wrote:
| 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?
| thiht wrote:
| This one doesn't make any sense, it HAS to be a mistake
| Kudos wrote:
| 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.
| simonw wrote:
| 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"
| croemer wrote:
| I've emailed @dang
| latexr wrote:
| 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.
| yxhuvud wrote:
| How on earth is threading comments on PRs advanced in any way?
| kreetx wrote:
| Maybe overcomplicated is the better term? Constantly adding
| "basic" features on top of each other might create us a Jira.
| dang wrote:
| We've reverted the title now. (Submitted title was "GitHub
| removes 42 "basic functionality" features from their roadmap")
|
| Submitters: " _Please use the original title, unless it is
| misleading or linkbait; don 't editorialize._" -
| https://news.ycombinator.com/newsguidelines.html
| mihaaly wrote:
| "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.
| bananapub wrote:
| 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.
| latexr wrote:
| 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.
| abofh wrote:
| 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.
| latexr wrote:
| 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.
| Brian_K_White wrote:
| But that was the whole point. You never had any visibility
| into their roadmap.
|
| 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.
| MereInterest wrote:
| By that same logic, if somebody tells me they will pick me
| up on the way to a movie, I should go there on my own
| because they aren't here already. I should walk to the
| movies, because my car is not currently running and whether
| or not it starts is in the future.
|
| There's such a thing as trust. Tools, people, and groups
| that have shown themselves to be trustworthy may continue
| to be trusted. It is also reasonable to point out these
| shifts, so that others know when announcements should no
| longer be trusted.
| Brian_K_White wrote:
| That is hyperbole not exprapolation.
| nixpulvis wrote:
| 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.
| latexr wrote:
| > 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.
| eviks wrote:
| If you consider anything such a big issue, then your suggestion
| solves nothing - people still complaint, and now they also
| complaint about no transparency (see Apple)
|
| > 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?
| latexr wrote:
| > 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.
| skybrian wrote:
| For a mature product, I think it makes sense to set an
| expectation of stability - what you see is what you get and if
| it's not good enough as-is, don't use it.
|
| 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.
| jtj606 wrote:
| As the post suggests - the GitHub community discussions are
| still the place to talk about these items. This is just
| closing the sometimes literally years old public roadmap
| posts.
|
| What's preferable, clarity on what's actively planned, or
| ambiguity with dozens of features languishing on the public
| roadmap without any updates?
| manicminer wrote:
| The inability to comment on any line in a PR is a real pain. I'm
| disappointed to see the plans for this abandoned.
| donatj wrote:
| 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.
| nixpulvis wrote:
| Death by committee or death by microsoft, take your pick.
| o_m wrote:
| 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.
| croemer wrote:
| Like issue search being not instant, it's impossible to find
| duplicates if it takes 5 seconds per search and not 500ms.
| donatj wrote:
| > 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
| lawgimenez wrote:
| I wish they put their focus more on GitHub Projects/Issues, it is
| just too slow.
| mst wrote:
| 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.
| shrikant wrote:
| I'm confused -- are they just closing the issues because they're
| outdated for various reasons, or are they yanking those features
| entirely where there's some attempt already made?
|
| 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..?
| jonasb wrote:
| Yeah, I hope it doesn't mean that they will remove Command
| Palette. Unfortunately, it's still an opt-in "feature preview",
| so who knows what this means. For me it's a key navigation tool
| in GitHub, but I can understand that it's more of a power user
| feature.
| joeyagreco wrote:
| no idea how [this](https://github.com/github/roadmap/issues/552)
| was closed as "outdated"
| MortyWaves wrote:
| What the fuck? A casual browse of that list and these are very
| real features that appear to already have had some development.
|
| 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.
| cloudking wrote:
| Translation: here's a bunch of useful features requests customers
| asked for, but we don't have engineering budget to build them and
| not enough customers asked for them, so we're not building them.
| Plus they don't say "AI" so our executive team said to axe them.
| eqvinox wrote:
| Is IPv6 reachability on some other issue tracker or why am I not
| finding it?
| brookman64k wrote:
| At my project we are forced to use Enterprise GitHub including
| Actions. Often 80% of the build time consists of up- or
| downloading intermediate or final build artifacts. This can take
| more than 40 minutes which is extremely painful. I was really
| looking forward to finally getting a speedup here. The promise:
|
| > 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. :-(
| jmainguy wrote:
| I believe the future is GitHub enterprise cloud.
| https://docs.github.com/en/enterprise-cloud@latest/admin/ove...
| all the benefits of GitHub enterprise, with none of the cons
| RadiozRadioz wrote:
| This was a bad way to announce closing these issues. With a big
| list like that, everyone's going to find something they're pissed
| off about not having. They should have closed the issues slowly
| and quietly in the background - individually they're small enough
| that people probably wouldn't notice. But like this, many more
| people see what's happening and get angry together. Not a good
| way to do PR.
|
| Maybe the idea was to rip the band-aid off and hope the outrage
| burns out quickly.
___________________________________________________________________
(page generated 2024-11-25 23:01 UTC)