Tres
Issues and PRs by labels #603
Replies: 8 comments 9 replies
-
|
@Tresjs/core please provide feedback to start this task |
Beta Was this translation helpful? Give feedback.
-
|
If not similar, we could apply the same exact label system. |
Beta Was this translation helpful? Give feedback.
-
|
I think this would be useful. I try to open issues when I come across them, but lots of them are non-breaking for most users and it'd be nice to signal that to the team in a systemic fashion. This system would allow me to do that. ProposalFor the purposes of clarity and alphabetical grouping of common themes, I'd prefer to see e.g.,
then eliminate the "bug" label. Same for "feature".
ReasoningThe Github labels are shown alphabetically in the contexts where I run into them. I rather be presented with:
... instead of ...
I think that will require less explanation for new contributors than the current Vite labels. And it'll make it easier for us to keep them separate. ContextThis seems to be how the Vite team is using labels in practice. There are currently zero "is:open label:bug" or "is:open label:feature" ... but there's a lot of "is:open label:p2-nice-to-have" https://github.com/vitejs/vite/labels/p2-nice-to-have I think it'd be more useful to label those as 'bug-p2-nice-to-have', so that it's clear to everyone. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @andretchen0 thanks for the feedback. Regarding adding the prefix, would that be necessary if the ticket already have the |
Beta Was this translation helpful? Give feedback.
-
|
I think the prefix will make it more difficult to add the labels. We type |
Beta Was this translation helpful? Give feedback.
-
|
Responding to @alvarosabu 's proposal as written above, as I understand it, I'd have to remember that:
It's my weak preference not to have to remember that or explain it to others. @patak-dev wrote:
Sure thing. To bridge the gap, it sounds like if the priorities are either ...
... then just using Typing @alvarosabu wrote:
It seems that the Vite folks are largely not using plain For example: |
Beta Was this translation helpful? Give feedback.
-
|
@andretchen0 mmm it's true that
Not quite, we would use this prio labels to categorize issues and PRs from the community, as a contributor, I would like to have some context of why my request is It also helps when 2 different context has the same level of prio, for example |
Beta Was this translation helpful? Give feedback.
-
|
Hey @alvarosabu Sure thing. I think the top-line proposal is an improvement. Go for it. |
Beta Was this translation helpful? Give feedback.
-
ProposalEliminate "enhancement". Use "feat-*" instead. Reasoning
|
Beta Was this translation helpful? Give feedback.
-
|
Totally agree |
Beta Was this translation helpful? Give feedback.
-
ProposalFormat labels using ReasoningConsistencyIn the top-line proposal, there's a mix of spaces and hyphens. E.g.,:
It'd be nice to have a single way of formatting labels. No escaping requiredDepending on the context, spaces and punctuation have to be escaped. "feat: runtime" can sometimes be escaped as ... ... but sometimes has to be escaped as ... No quoting requiredA label with spaces sometimes has to be quoted ... Meanwhile, kebab just worksKebab-case labels work as written, afaik ... |
Beta Was this translation helpful? Give feedback.
-
👍. Especially due the escaping, agree. |
Beta Was this translation helpful? Give feedback.
-
|
The only issue is, some of them are using by Github to bring new contributors:
We will need to maintain those |
Beta Was this translation helpful? Give feedback.
-
|
Haha, I finally figured out how to submit a PR correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Just my thoughts about the label/issue system. How do other projects let new or outside contributors of the core team know which issues they can pick up? Some issues or bugs which are edge cases for example can be perfect for a new contributor but if it salready worked on by a core team member then its wasted energy. Is it an idea to have a special label for that situation besides good first issue? On a side note: How to make this clear in the discord if desired? |
Beta Was this translation helpful? Give feedback.
-
|
Github has two default labels to promote tasks for new joiners, |
Beta Was this translation helpful? Give feedback.
-
|
That seems a great idea! The bot would have it pinned then or maybe a separate issues contribution channel where someone can assign themself to an issue in some way too |
Beta Was this translation helpful? Give feedback.
-
We are reaching a point where we need a proper prioritisation and categorisation workflow for new features and bugs across the ecosystem.
I got some advice from @patak-dev on how they label issues and PRs vitejs/vite#15857, I would like to apply something similar:
Feedback
experimental: Experimental featurePriorities
pending-triage: ticket is pending to be prioritizedp1-chore: Doesn't change end-user code behavior (Ex. new linter, internal playground stuff)Bugs
p2-edge-case: Bug, but has a workaround or limited in scopep3-minor-bug: An edge case that only affects very specific usagep4-important: Violate documented behavior or significantly improve performancep5-urgent: Fix build-breaking bugs affecting most users, should be released ASAPFeatures
p2-nice-to-have: Not breaking anything but nice to havep2-to-be-discussed: Enhancement under considerationp3-downstream-blocker: Blocking the downstream ecosystem to work properlyp3-significant: High-priority enhancementGeneral categories
featurebugenhancementdocs: Improvements or additions to documentationdxdevtoolstesttypesperformancecookbookFor Contributors
good first issue: Good for newcomershelp wanted: Extra attention is neededcontribution-welcomeneeds reproductionExtra info
breaking-changeregression: The issue only appears after a new releaseupstream: Bug in a dependency of Treshas-workaroundcannot-reproduce: The bug cannot be reproducedduplicate: This issue or pull request already existsinvalid: This doesn't seem rightwontfix: This will not be worked onon-hold: for whatever reasonPR meta
needs-testneeds-documentationneeds-translationsBeta Was this translation helpful? Give feedback.
All reactions