Clarify ways that GitHub issues get prioritised #8120
Conversation
README.md
Outdated
| @@ -73,6 +73,10 @@ We work with quarterly roadmaps in autonomous product teams. | |||
| - [Gitpod Architecture](https://www.notion.so/gitpod/Architecture-0e39e570b10f4e8ba7b259629ee3cb74) | |||
| - [Product Roadmap](https://github.com/orgs/gitpod-io/projects/27) | |||
|
|
|||
| ### How do GitHub Issues get prioritised? | |||
|
|
|||
| Most GitHub issues (except smaller or more urgent issues) relate to our [current product roadmap items](https://github.com/orgs/gitpod-io/projects/27). Gitpod teams work against these roadmap items. Each Gitpod team has [it's own project board](https://github.com/orgs/gitpod-io/projects) that follows a similar structure. You can find these project boards attached to [the GitHub organisation](https://github.com/gitpod-io). Each team board has a "GroundWork" tab which shows current GitHub issues in progress. Each team project board also has an "inbox" where issues are sent for review by the team (and should be responded to within 48 hours). "Upvoting" by [reacting](https://docs.github.com/en/rest/reference/reactions) to GitHub issues helps signal to Gitpod that issues are important to you. If you are unsure of the status of an issue, please comment and a Gitpodder should respond to you shortly. For any other questions, please utilise the [Gitpod community](https://www.gitpod.io/community). | |||
There was a problem hiding this comment.
One aspect missing here is the relation to the priority labels 🏷.
@csweichel or @gtsiolis (as you are marked as owners of the internal labels document [1]) - are you able to make a suggested wording update to clarify the use of the priority labels?
I would suggest here that we note that labels are used as a way to flag an issue, but not necessarily dictate when the issue might get completed, as that's the documented groundwork / roadmap process already mentioned?
There was a problem hiding this comment.
Thank you for that update!
I'm not sure we'd want to specifically add priority labels here because
- we'd want to prioritise issues ourselves, and not externalise that. The labels might not be described well enough to be used by members of the community - and I'm not sure we'd want to encourage folks outside of Gitpod to apply priority labels.
- we'd do well to describe our labels entirely, not just priority labels. To that end, we could make the Notion page public and link it here.
There was a problem hiding this comment.
Just realized that labels have a description. I think we should just make good use of them.
There was a problem hiding this comment.
I'm not sure we'd want to specifically add priority labels here - @csweichel
Yeah, I was originally thinking to note here to "ignore" them in this context e.g. "Please ignore labels for the purpose of prioritisation" but wasn't sure if that would be an accurate reflection of their use. Things certainly get fuzzy when we mix the inbox / groundwork / roadmap processes with labels 😬 Maybe it'd be worth considering to re-word the "priority" labelling to avoid confusion (but let's discuss that separately if we can!).
we'd do well to describe our labels entirely, not just priority labels - @csweichel
Just realized that labels have a description. I think we should just make good use of them. - @svenefftinge
Agree 🙏 We can look into clarifying labels in future then and update in a subsequent PR 🙏
roboquat
added
release-note-none
and removed
do-not-merge/release-note-label-needed
labels
|
/werft run 👍 started the job as gitpod-build-update-readme-with-dev-process-2.0.1 |
loujaybee
force-pushed
the
update-readme-with-dev-process-2.0
branch
from
87ad432 to
3c75ab3
Compare
Codecov Report
@@ Coverage Diff @@
## main #8120 +/- ##
==========================================
- Coverage 11.98% 10.82% -1.16%
==========================================
Files 20 18 -2
Lines 1193 1025 -168
==========================================
- Hits 143 111 -32
+ Misses 1046 912 -134
+ Partials 4 2 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Description
Given that we now have a newly structured roadmap [1], that links more closely to the team boards [1], this PR attempts to clarify to externals the current roadmap process.
Related Issue(s)
Closes #7575
Release Notes