Deprecating Outdated Issues on the GitHub Public Roadmap #1014
Replies: 13 comments 18 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.
-
|
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.
-
It is a bit frustrating indeed. However, we are invited to continue the discussions in GitHub discussions if we're still interested in seeing some of those deprecated issues happen. With that in mind, if you are as interested as I am to see custom workflows in Projects, I think those 3 discussions could be upvoted: |
Beta Was this translation helpful? Give feedback.
-
|
I am too really disappointed #276 was depreciated, I recently set-up a new Project and that was exactly what I missed and had to duplicate a lot of manual work. |
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.
-
|
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.
-
|
I cannot believe supporting v4 is marked outdated while v3 will be deprecated by November 30, 2024. |
Beta Was this translation helpful? Give feedback.
-
|
yeah. I recently ran into the following after running in circles for a while:
Made me want to run into a wall head first and I was really looking forward to getting v4 support for GHES |
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.
-
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.
-
|
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.
-
|
So your closing issue without discussion, reasoning, or explanation - all in the name of transparency? |
Beta Was this translation helpful? Give feedback.
-
|
@mbrevda, all but one were already locked. |
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
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!
Beta Was this translation helpful? Give feedback.
All reactions