-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Get rid of Milestones, add Priority labels instead, and close ideas we'll unlikely work on #2643
Comments
I like this. And while explicit is better than implicit, is priority-normal even necessary? No priority label = regular boring weekday nothing-special priority. |
I think "no priority" means "untriaged" or "unsure". Anyway, I've closed all milestones and mapped their issues as follows:
Now, you may want to go over the priorities and let me know whether you agree with the specific priority set -- priorities are not set in stone or anything, but they indicate that we've triaged an issue. Apart from most of the Questions I've not actually closed issues yet for the stated reason, but I'll close this issue to indicate that the milestones are gone and the priority labels created. (Got any suggestions for better colors though?) |
Done. Can you also suggest colors for the sizes? |
So here's a first-world problem: I would like the priorities appear in their natural order when alphabetized. I don't care whether low or high comes first, but I want normal to be in the middle. Any suggestion for three words that convey the right idea and sort correctly? (I don't want to go with P0, P1, P2 since "0 is high" is a bit counter-intuitive. |
We aren't using Milestones effectively, and their presence sets incorrect expectations. We are going to use priority labels instead. I only want three priorities:
Having too many choices just encourages bickering about exact priorities -- in practice that's not worth it. Also, for truly "pants on fire" issues we shouldn't use a label but just contact the responsible party directly.
Finally, I also propose to just close (with a friendly "thank you") those issues that suggest a nice idea that we just don't expect to be working on. Closed issues are still searchable, and if somebody wants to work on such an idea they are welcome -- closing an issue is meant to send the signal that it's unlikely to be implemented by the core mypy team, not that we are against it (if we are against an idea we'll make it clear when we close the issue).
The text was updated successfully, but these errors were encountered: