Fields for issues #149754
Replies: 4 comments 1 reply
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Hi @LeaVerou, thank you for leaving feedback! The team recently released Do you think that would be helpful for your case here? You can learn more about it and leave further feedback in this discussion! |
Beta Was this translation helpful? Give feedback.
-
|
I’m aware of issue types, but that’s only a specific type of field. The types of fields I want to track are things like priority, effort, difficulty, product area/topic, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to revive an old thread but I also would love to see something like this. A simplified use case is one that allows the Product team to manage a project board of issues of type "Feature" and the Engineering team to manage a project board for issues with type "Task". While the team can toggle between different project boards to see both, it sure would be nice if we could either a) configure a board based on not only its own custom fields but also custom fields from other boards that issues on the board also belong to -- or -- b) link/clone a read-only view from another project board so that users could see without needing to keep separate browser tabs open. This multiple board use case is primarily necessary due to limitations on issue activity history not showing changes to custom field values and workflows being too restrictive on the fields that can be observed or actioned upon. |
Beta Was this translation helpful? Give feedback.
-
|
One could use a |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Product Feedback
Feature Area
Issues
Body
I was so giddy to discover custom fields for projects that allow to assign priority, effort, etc to issues for a given project. I would literally not shut up about it to everyone who would listen 😁
However, my enthusiasm waned once I realized that these a project-specific: assigning a priority or effort level to an issue in one project, means this metadata will not be visible in any way on this issue outside of said project.
So we went back to our existing workaround of just using labels with colons. It can get quite messy, e.g. real example:
I guess a workaround might be to include ALL issues in a project, but that seems very hard to wrangle.
While being able to scope fields to the project is useful, I wonder if it's an edge case. E.g. how likely is an issue to be high effort for one project and low effort for another? Or high priority for one project and low priority for another?
It would be great to support the same fields infrastructure for issues as well, for fields that genuinely intrinsically belong to the issue itself, and not to the Issue-Project relation. The UI is already there, and works great, so hopefully this shouldn't need a ton of effort to do? Perhaps it could even implement the workaround I mentioned above behind the scenes until the infrastructure is there, then it just becomes largely a matter of doing the UI work to hide that.
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions