Discussion, labels and project within milestones #176896
Replies: 2 comments
-
|
Milestones are extremely useful for grouping tickets within a release—for example, “Release 2025.4.2.” Currently, milestones mainly track issues, but communication around them is limited. It would be very helpful to enable collaboration at the milestone level, such as: Assigning someone as responsible for a milestone. Allowing QA teams to attach testing reports or chat updates directly to a milestone. Including milestones as items in a project board to get a high-level view of releases. Adding labels or custom fields for deployment requirements and other release notes. Our current workaround involves creating a separate repository called “releases”, where we create an issue for every milestone. Each issue links to the corresponding milestone in the development repository. These release issues are added to a dedicated project board, assigned a state like In Development, QA, or Released, and used for communication and coordination. We also use labels like “new env needed!” to flag infrastructure updates. While this approach works, it requires double mapping and extra clicks. Having native milestone-level collaboration features would significantly streamline our workflow and reduce overhead. Guidelines: I confirm this feedback is relevant to the GitHub feature areas Issues and Projects. |
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
Milestones are a great way to group tickets within a release. We usually create milestones like “Release 2025.4.2” and attach issues to them.
What would be wonderful is to enable communication at the milestone level. Since a milestone represents a release, you could assign someone as responsible for it, allow the QA team to add their testing reports via chat, include the milestone as an item in a project to see a list of releases, and more.
Our current workaround is to create a separate repository called “releases”, where we create an issue for every milestone in our development repositories. Each issue contains a link to its corresponding GitHub milestone in description (which is easier than listing all related issues manually). We then add these release issues to a dedicated project, assign them a state such as In Development, QA, or Released, and use that space for communication. We also use labels like “new env needed!” to remind us of any required infrastructure changes when deploying a release.
This workaround serves us well, but it involves double mapping and quite a lot of clicking.
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions