I would like to remind those out there setting milestones on tickets to follow the following guidelines that Jacob put forth:
* Must-have feature bugs go in the "1.0 alpha" milestone. These basically should be all nfa-blocker tickets. Bugs in the must-have features are not to be part of this milestone; they can be fixed after the alpha and should be put in the "1.0" milestone.
* Any feature tickets related to the maybe list get put in the "1.0 beta" milestone.
* Any remaining bugs go in the "1.0" milestone.
See the roadmap for a list of the must-have and maybe features:
I would like to stress the point that features not on the list are not to be put in any 1.0 milestone. For those working on tickets for features or enhancements that are not on the list, please understand that these are lower priority than vetted features and *all* bugs. If you really want to work on features not on the list, then keep track of them with some sort of "1.0dreaming" keyword instead of assigning them to a 1.0 milestone.
With 1.0 looming, this isn't the time to see how many features we can try to pack in, but rather time to focus on squashing all bugs. I'm not here to tell you what you can and can't work on, but please keep the end goal in mind and help to focus efforts.
This e-mail was sparked by a couple ticket updates I noticed, namely #1061 and #3011. Even if these sorts of features have a patch and are "Ready for checkin," that does not mean they get a 1.0 milestone. They still take core developer time to review and commit, time that also needs to be focused on higher priority tickets.
> I would like to stress the point that features not on the list are not
> to be put in any 1.0 milestone. For those working on tickets for
> features or enhancements that are not on the list, please understand
> that these are lower priority than vetted features and *all* bugs. If
> you really want to work on features not on the list, then keep track of
> them with some sort of "1.0dreaming" keyword instead of assigning them
> to a 1.0 milestone.
Agreed.
> Even if these sorts of features have a patch and are "Ready for checkin,"
> that does not mean they get a 1.0 milestone. They still take core
> developer time to review and commit, time that also needs to be
> focused on higher priority tickets.
Just out of curiosity, could we fix that bottleneck by appointing more
developers to be core developers?
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <jan...@leidel.info> wrote: >> Even if these sorts of features have a patch and are "Ready for checkin," >> that does not mean they get a 1.0 milestone. They still take core >> developer time to review and commit, time that also needs to be >> focused on higher priority tickets.
> Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers?
I think that Just Happens once someone has been consistently making quality contributions over a long period. (Other than Whiskey-Media-era Jacob, I don't know how any of them do it; I think you need to take the super-Django-soldier serum first.) ^_^
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <jan...@leidel.info> wrote: > Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers?
These are people who have a long history of contributions to Django's codebase, a solid track record of being polite and helpful on the mailing lists, and a proven desire to dedicate serious time to Django's development.
The bar is very high for full commit access. It will only be granted by unanimous approval of all existing full committers, and the decision will err on the side of rejection.
[...]
To request commit access, please contact an existing committer privately. Public requests for commit access are potential flame-war starters, and will be ignored. """
That last bit -- emailing an existing committer asking for commit access -- is there deliberately. It helps with setting a high bar -- asking for commit access is *scary*, so the idea is that only those who deserve it will ask. We'll encourage the "right" people to ask when appropriate, of course, but if anyone reading here thinks they deserve commit access, email me. Hell, even if you just want to know what you'd personally need to do to get commit access, email me.
> To request commit access, please contact an existing committer > privately. Public requests for commit access are potential flame-war > starters, and will be ignored. > """
Eeek, sorry, a flame-war wasn't my intent. I better read the manual before, next time :)
> That last bit -- emailing an existing committer asking for commit > access -- is there deliberately. It helps with setting a high bar -- > asking for commit access is *scary*, so the idea is that only those > who deserve it will ask. We'll encourage the "right" people to ask > when appropriate, of course, but if anyone reading here thinks they > deserve commit access, email me. Hell, even if you just want to know > what you'd personally need to do to get commit access, email me.
