Replies: 1 comment 2 replies
-
Good point. I like having hierarchies. The top buckets (type, status, and impact) all look reasonable to me. The second level labels need some work I think but in any case this is a good start. Do you want to turn this into an RFC PR so other folks can comment on/make suggestions more easily? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Story:
I was just asked a question: "What changes in Valkey 8 can/should drive Valkey clients changes?" (refactored it a bit 🙂 )
I do keep certain amount of Valkey8 changed in my head, but in order to help I also started to filter different PRs by labels.
First I used "breaking-change" label. This is good but will have high amount of false-positive (for example clusterbus and replication protocol breaking changes usually do not impact clients). Then I wanted to look for "new commands" or "API changes" and I did not find such label. actually I could not even locate we have a label for "new-feature".
at the end I just iterated on the list of changes which has the release-notes label and added them to the list of changes I fetched from memory. Some things like #477 (for example) have no special label but are introducing new interface for clients to connect so I think it is relevant here.
As this project is still rather new. maybe we should improve our labeling schema so it would be easier to track relevant changes specific type or subject?
This is the list of labels we currently have:
Label: breaking-change, Description: Indicates a possible backwards incompatible change
Label: bug, Description: Something isn't working
Label: cluster, Description:
Label: de-crapify, Description: Correct crap decisions made in the past
Label: documentation, Description: Improvements or additions to documentation
Label: duplicate, Description: This issue or pull request already exists
Label: enhancement, Description: New feature or request
Label: good first issue, Description: Good for newcomers
Label: help wanted, Description: External contributions would be appreciated
Label: invalid, Description: This doesn't seem right
Label: major-decision-approved, Description: Major decision approved by TSC team
Label: major-decision-pending, Description: Major decision pending by TSC team
Label: needs-doc-pr, Description: This change needs to update a documentation page. Remove label once doc PR is open.
Label: pending-missing-dco, Description: For PRs that are blocked because they are missing a dco
Label: pending-refinement, Description: This issue/request is still a high level idea that needs to be further refined
Label: performance, Description:
Label: polish, Description: typos, style, etc
Label: question, Description: Further information is requested
Label: rebranding, Description: Valkey is not Redis
Label: release-notes, Description: This issue should get a line item in the release notes
Label: test-failure, Description: An issue indicating a test failure
Label: to-be-closed, Description:
Label: to-be-merged, Description: Almost ready to merge
Label: wontfix, Description: This will not be worked on
I suggest we keep the following classes of labels:
type:* - to indicate the type of the issue/change. for example: type::documentation, type::new-feature, type::question, type::rebranding, type::test-failure, type::enhancement, type::bug etc..
status::* - different indications to the status of the change/issue. for example: status::wontfix, status::to-be-merged, status::help wanted, status::invalid etc...
impact::* - what type of impact this change/issue has? for example: impact::latency, impact::performance, impact::API, impact::connectivity, impact::cluster, impact::non-cluster etc...
This is just an initial suggestion and maybe not even a good one, but I would love to get some thoughts about it.
Beta Was this translation helpful? Give feedback.
All reactions