-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split difficulty/newcomer
label into difficulty/trivial
and newcomer
labels
#115
Comments
Besides modifying labels, following components rely on the
|
So how would the newcomer process change after this. |
No |
I do like the term 'trivial' as a difficulty level. 'newcomer'-friendly is orthogonal to difficulty levels, but we tend to not get difficulty levels right either. I dont think it makes sense to change our current system until we have a better methodology for choosing trivial, low, medium difficulty (at the moment is only slightly better than completely random for newcomer vs low), and describe what newcomer actually is, and when we would use it, if at all. I suspect that we can clearly define what is trivial and consistently apply that label, which will give 'low' some extra clarity. I doubt we'll be able to do that with 'newcomer', especially not while that term is tied to an onboarding process. So it might be easier to deprecate newcomer entirely, relabel most of them to new label trivial, and then go through the trivial issues and relabel some to |
Not necessarily, I (and some others) wanted to not mark documentation issues as newcomer-friendly as soon as writing new documentation is involved (even if it's trivial to just add 1-2 sentences).
Yeah this is always a problem. However I think we aren't doing it that bad :) Can still be improved though :D
So you want to align |
Just because an issue is trivial, it doesn't mean it's suited for newcomers.
The text was updated successfully, but these errors were encountered: