Deprecating Outdated Issues on the GitHub Public Roadmap #1014
Replies: 17 comments 47 replies
-
|
#552 is unbelievably painful UX. Gitlab has this. Not being able to thread on top level comments makes it so hard to track conversations and results in all this quotation noise. Please reconsider adding this feature (is it really that hard?? you already have threaded comments on lines..) |
Beta Was this translation helpful? Give feedback.
-
|
I wonder how this is not aligned to GitHub's roadmap. |
Beta Was this translation helpful? Give feedback.
-
|
I also cannot understand how this would be no longer relevant. |
Beta Was this translation helpful? Give feedback.
-
|
On what planet is #552 outdated? |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I started a top level "Idea" discussion on #552 (threading for top level comments), see #1067 |
Beta Was this translation helpful? Give feedback.
-
|
We understand you're disappointed that #552 was removed from the roadmap. We've added more detail in a comment on the issue to provide additional context. Please stay tuned for additional updates to the roadmap in coming months and continue sharing your feedback on the roadmap over here in Community! |
Beta Was this translation helpful? Give feedback.
-
|
It's a little tone-deaf to call #281 "outdated" when it's a daily struggle to manually perform the workflow we want automated. Or to call #276 "outdated" when it's a daily struggle to sync labels and to work around milestones by using Linear in our org. I also agree with #552, a Twitter feed is unsuitable for pull request comments. They deserve their own replies. I mean, it's great that you guys finally commit on not making the user experience better, but calling your top pain points "outdated for several years" is bound to not be well-received. |
Beta Was this translation helpful? Give feedback.
-
|
"Outdated for several years" Ya'll left it sit for several years, lmfao. I don't understand this mentality of "we haven't acknowledged or addressed this issue for several years, therefore we're going to mark it as stale and close it" that most people have. |
Beta Was this translation helpful? Give feedback.
-
|
IMO #281 is better served by GitHub Actions. Implementing visual workflows would create an awkward situation where you can do things in two different ways, some features being available in the first but not in the second, and vice-versa. This would make it frustrating to migrate from one to the other when you stumble upon missing features as well as induce decision paralysis. It would also mean less transparency to non-owner contributors of repos about the underlying workflows and prevent them from fixing them/doing a PR as needed. |
Beta Was this translation helpful? Give feedback.
-
|
@devnoname120 That's probably something worth discussing in https://github.com/orgs/community/discussions/53973 GitHub actions definitely offer the most flexibility, but then comes the question of where should the code live for projects that are not tied to a specific repo. |
Beta Was this translation helpful? Give feedback.
-
|
@jeherve No it's something else. Compare the schema of GitHub Workflows with the schema of GitHub Composite Actions. You will find out that there is a bunch of non-sensical[1] minute differences that makes everything unexpectedly break when you try to remove code duplication by refactoring it into GitHub Composite Actions. [1] Non-sensical = there is absolutely no justification for the differences, they are arbitrary. For example in literally all the |
Beta Was this translation helpful? Give feedback.
-
|
We hear your feedback and understand you're disappointed to see #281, #276, and #552 removed from the roadmap. We have added more context in comments on each of those issues, and hope you'll continue sharing your feedback on the roadmap over here in Community. And yes, @jeherve, we love it when people upvote suggestions in the Community. :) |
Beta Was this translation helpful? Give feedback.
-
|
Myself and my organization were extremely interested in seeing #636 be implemented, as it would allow for a much tighter security posture around centralized reusable workflows. At the current moment, one must share secrets with the repository consuming the reusable workflow, which is a blatant security risk, as anyone with write access to the calling repository can then cut their own branch, modify the action file, and use the secrets however they desire. Are there any plans to implement this or similar functionality in the future? |
Beta Was this translation helpful? Give feedback.
-
Same here. |
Beta Was this translation helpful? Give feedback.
-
|
Same for our Team. It would save us a lot of time and make our centralized CICD framework more secure. |
Beta Was this translation helpful? Give feedback.
-
|
This would be an incredible security boost, as it will allow to tie secrets specifically to reusable workflows (as it now is using secrets from the calling repository). This means that if you want to reuse workflows on many repositories, you also need to make sure that secrets are available on all these repositories - and there is no way you can control how these secrets are being used. It will basically allow full freedom to use any secret in any way, whereas assigning it to a centrally controller repository, you can actually control how the secrets are being used. As an alternative, we are considering using OIDC with I would really like to see this feature in some form or another! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing this feedback. We have added more detail in a comment on #636 about the removal. Stay tuned for more updates to the roadmap in the coming months and continue to share your feedback in Community! |
Beta Was this translation helpful? Give feedback.
-
|
We use GitHub Enterprise server, and our organization really needs support for GitHub Actions: Artifacts v4 Is there a chance this will be done? The cloud version has supported Artifacts v4 for a long time. |
Beta Was this translation helpful? Give feedback.
-
|
GHES is cursed by not having Artifacts v4 yet and it (v3) is causing lot of noise in our developer community |
Beta Was this translation helpful? Give feedback.
-
|
v3 is one or two orders of magnitude slower at upload and download than necessary. I know because we have replaced it with Azure artifacts and Artifactory where possible (for intermediate artifacts). Still the majority of our build time is waiting until the final artifacts get uploaded… |
Beta Was this translation helpful? Give feedback.
-
|
It's ridiculous for GHES not to be kept on par with SaaS gitHub, making it harder to migrate from one to the other, and bad surprises popping up due to these inconsistencies. Differences/discrepancies between GitHub Workflows and GitHub Composite Actions are already direly painful, please don't make the situation worse by introducing additional footgun incongruences across GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
If this is really intentional I am honestly considering to stop using GitHub Actions or build an own solution for artifacts. We migrated to GHA in GHES beginning this year and it has a pain ever since. We have upload and download times of up to 20-30minutes (a single large zip) with Gigabit connections, this is a pain and implies a lot of cost and risks on every build. I really hope that it was "outdated" accidentally because they actually have no efforts internally for it and will enable usage in the next release. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this feedback regarding Artifacts v4 in GHES. We've added more detail in a comment on #930 and continue sharing your feedback on the roadmap over in the Community! |
Beta Was this translation helpful? Give feedback.
-
I agree with this too - quote-replies instead of threaded replies provide an awful experience. Example: This quote reply. |
Beta Was this translation helpful? Give feedback.
-
|
Btw, discussions have reply feature. |
Beta Was this translation helpful? Give feedback.
-
|
This is the reason issues and PRs garner 500 comments and are impossible to follow in this linear feed. GitHub massively collapsing hundreds of comments makes it even worse because you can't even search in this mess to find the information you're looking for. I've been starting to disable GitHub Issues entirely from my projects and shoehorn Discussions into a makeshift issue tracker. Very awkward. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for providing your feedback on #552 - we've added more detail in a comment on the issue. Please stay tuned for additional updates to the roadmap in coming months and continue sharing your feedback on the roadmap over here in Community! |
Beta Was this translation helpful? Give feedback.
-
|
Also #824 (More control over required status checks for pull requests using merge queue) has been abandoned. Sad. This is a common use case where certain PR checks should be skipped based on specific filters. In our monorepo, we have three main projects:
We use three PR action checks, each filtered by folder. As a safety measure, it’s crucial to block merging into the main branch if the relevant check hasn’t passed. However, without this feature, we’re forced to leave all checks optional, which compromises safety. |
Beta Was this translation helpful? Give feedback.
-
|
GitHub's merge queue is quite basic and it's meant to stay like that. They haven't invested much in it since its release last year. Did you have a look into advanced merge queues, like Mergify? Some of them have dedicated features for monorepos. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I'm looking into it! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing your feedback. We've added additional detail in a comment on #824 and and continue sharing your feedback on the roadmap over here in Community! |
Beta Was this translation helpful? Give feedback.
-
|
So your closing issue without discussion, reasoning, or explanation - all in the name of transparency? |
Beta Was this translation helpful? Give feedback.
-
|
Some of these were also locked without any discussion, reasoning, or explanation. |
Beta Was this translation helpful? Give feedback.
-
|
@hyperTwitch, which? |
Beta Was this translation helpful? Give feedback.
-
|
Every single ticket I can see in this list is locked and has zero discussion, at least that the public is able to see. Just a post saying that the ticket is now "outdated" and is being closed. As you can see from the discussion here, there are more than a couple tickets on this list which the community does not understand how the feature request is "outdated". |
Beta Was this translation helpful? Give feedback.
-
|
@hyperTwitch, there is #828 (comment)... but that's about it XD |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for flagging this and we understand your frustration. We have been working on adding details to the issues we've removed from the roadmap and regret not publishing that additional context to you sooner. Please check out the comments we're adding with more details on the issues you're interested in, and we're continuing to add more context and details through early December. We encourage you to continue sharing your feedback about the roadmap in this post, or feel free to open up a new thread on the Community with any specific questions or concerns you have! |
Beta Was this translation helpful? Give feedback.
-
|
It is very disrespectful of GitHub to kill the roadmap items without explaining what is wrong with supporting enterprise-wide environments and make you stupidly define environments in multiple repo. Especially with microservices implementation, someone should be out of mind to choose Github actions |
Beta Was this translation helpful? Give feedback.
-
|
I can only agree on this. It would have allowed us to easily enforce some rules on any new repository. That’s a shame. |
Beta Was this translation helpful? Give feedback.
-
|
We appreciate your feedback and acknowledge your disappointment with the removal of #988 from the roadmap. We've added an additional comment on the issue to provide context. Please stay tuned for additional updates to the roadmap in coming months! Join our community to continue the conversation. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this update, @ankneis. My team at the .gov registry has been really pleased with sub-issues, and I was hoping to see updates on the 3 issues below! Several of our repos feed into a single project, and being able to share cross-repo milestones and labels, track dependencies, and review our project history for errant changes would be so useful to our delivery.
Prioritization decisions are hard! If my team can ever be useful in your discovery and research efforts, we'd love to be. |
Beta Was this translation helpful? Give feedback.
-
|
Totaly agree with you Please wakeup @github-product-roadmap |
Beta Was this translation helpful? Give feedback.
-
|
We hear your feedback and understand you're disappointed to see #276, #956, and #816 removed from the roadmap. We have added more context in comments on each of those issues, and hope you'll continue sharing your feedback on the roadmap over here in Community. Stay tuned for another roadmap update in January! |
Beta Was this translation helpful? Give feedback.
-
|
I run up against #347 regularly, would love for Github to add it! One downside of getting rid of these issues is that there's now no easy way to be alerted when a feature I care about has been implemented |
Beta Was this translation helpful? Give feedback.
-
|
We hear your feedback around #347, @hauntsaninja. We've added more context on #347 and stay tuned for more roadmap updates in the coming months. Join our community to continue the conversation. |
Beta Was this translation helpful? Give feedback.
-
|
Please add this to your roadmap: Frankly, I don't understand why this hasn't been prioritized. Does GitHub not dogfood their own product? How are the GitHub engineers reviewing each other's code? |
Beta Was this translation helpful? Give feedback.
-
|
We have hundreds of users that are refusing to use GitHub pull request reviews because of this issue. We'll definitely be raising this with our account team. |
Beta Was this translation helpful? Give feedback.
-
|
A sad day for reviews 😞. |
Beta Was this translation helpful? Give feedback.
-
|
Graphite helps |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @styfle (and those replied) for sharing this feedback and we understand the disappointment around the removal of this item from the roadmap. We have added more detail in a comment on #347. Please stay tuned for more updates to the roadmap in the coming months and continue sharing your feedback on the roadmap over here in the Community! |
Beta Was this translation helpful? Give feedback.
-
|
Commenting unchanged lines is something I've run into relatively rarely, but when it has happened the workaround of "leave a comment on some random changed line and explain where it actually applies to" has been extremely frustrating whether as reviewer or as reviewee. The lack of threaded replies for top-level PR comments was always a baffling design decision, especially when they exist on other kinds of comment and in discussions. Very disappointed to see #347 and #552 off the roadmap, both would be major usability improvements. |
Beta Was this translation helpful? Give feedback.
-
|
We appreciate your feedback and understand you're disappointed to see #347 and #552 removed from the roadmap. We've added more detail to both of those issues and will continue to update our roadmap in the coming months. Feel free to continue the conversation here on the Community! |
Beta Was this translation helpful? Give feedback.
-
|
I am confused why #930 was removed from the roadmap. Dependabot is asking us to upgrade to v4 in GHES while it remains incompatible. Does the removal of the issue mean GHES will never see support for articat-upload/-download@v4 in GHES? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing your feedback. We've added additional detail in a comment on #930. Feel free to continue sharing your feedback on the roadmap over here in Community! |
Beta Was this translation helpful? Give feedback.
-
|
Thank God that you kept the Copilot features on the agenda, and stripped some of this outdated security and user experience stuff. I'm sure this will help me to rely more on your AI offerings, instead of getting work done myself. Glad you realigned with your current product vision. Having this transparently communicated really helps to see that vision unfold. |
Beta Was this translation helpful? Give feedback.
-
|
Packages: maven - granular permissions and easy organization sharing #578 Is a necessity if one want so use maven packages on a organization level. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing your feedback. We've added additional detail in a comment on #578. Jump into the community here to continue sharing your feedback on the roadmap. |
Beta Was this translation helpful? Give feedback.
-
|
To save someone time from clicking on all the “additional detail” comments: as far as I can see, they’re all basically “we don’t know when we’re going to do this” and in some cases “we don’t know whether we’re going to do this at all”. Example phrasing:
|
Beta Was this translation helpful? Give feedback.
-
|
We have made some updates to our Discussion post in an aim to provide additional context and clarity. We are adding more information and details to the removed issues linked above, some of which have new or related issues being added to the roadmap with up-to-date descriptions. We value your feedback on these changes and invite you to continue the conversation here in our community discussion, where we’ll also be posting updates about the new features we’re adding to the roadmap - it’s the best place to share your thoughts, ask questions, and connect with us and other users. |
Beta Was this translation helpful? Give feedback.
and others
-
Deprecating Outdated Issues on the GitHub Public Roadmap
At GitHub, transparency and clarity are at the heart of our relationship with the community. As part of our ongoing efforts to keep you informed about our product roadmap, we’ve already begun hosting quarterly roadmap webinars to share updates and engage with the community in real-time.
This week, we’re taking the next step in achieving our roadmap goals by refreshing the public roadmap project board.
After an in-depth review, we’ve identified a number of open issues that have become outdated over time—some for several years. To better align with our current product direction and to build trust with our users, we are deprecating these outdated issues and updating the board with new and accurate information.
This refresh will make it easier for you to follow our progress, ensure higher-quality updates, and provide a more accurate reflection of GitHub’s development priorities. Moving forward, we are also committing to regular updates, so you can rely on the roadmap as a trusted source of information about GitHub’s ongoing and upcoming features.
What’s Changing?
FAQ
Why are we deprecating these issues?
What can I expect from the refreshed roadmap?
Will the roadmap be updated regularly?
What should I do if an issue I care about is deprecated?
Deprecated Issues
As part of this update, the following issues will be deprecated. If you have questions on a specific issue/roadmap item, please reach out to your GitHub contact.
We appreciate your understanding as we make these changes. Our aim is to keep you better informed and involved in our development process. Thank you for being a valued member of the GitHub community!
📰 Update: Nov 26, 2024
Hi GitHub Community! 👋
We know some of you are disappointed to see certain items removed from our public roadmap, and we really appreciate your feedback. Your input means a lot to us, and these changes reflect some tough prioritization decisions we’ve had to make to focus on delivering the most impactful solutions for everyone.
We first want to apologize for a slightly misleading statement we made in our original post, that we hope to acknowledge and correct. We said that the closed issues no longer represent our product direction, however there are a number of reasons for removal, from the feature not being aligned with our strategic priorities, to our desire to actively acknowledge uncertainty on the timeline for a feature and remove it until we have more certainty.
In order to provide that missing clarity, we are adding more comments to the list of issues above with more details about why they were removed and whether there’s something similar on our refreshed roadmap. You’ll see those comments added over the next couple of weeks. While not everything will return to the roadmap, we’re dedicated to staying open, honest, and to regularly updating you. Look out for our next roadmap update in January—we’re excited to share the new possibilities we’re working on!
We invite you to keep the conversation going in our Community. It’s the best place to share your feedback, ask questions, and connect with our team and other users. Your thoughts play a big role in shaping what we do, and we’re here to listen and collaborate with you to make GitHub the best it can be.
Beta Was this translation helpful? Give feedback.
All reactions