tickets and use of the 1.0 milestones

[Gary Wilson Jr.]

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:

http://code.djangoproject.com/wiki/VersionOneRoadmap

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.

Thanks,
Gary

[Jannis Leidel]

> 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?

Best,
Jannis

[Tom Tobin]

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.) ^_^

[Jacob Kaplan-Moss]

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?

As with many things, the process of becoming a committer is documented
in our contributing document
(http://www.djangoproject.com/documentation/contributing/#commit-access):

"""
Full committers

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.

Jacob

[Jannis Leidel]

> As with many things, the process of becoming a committer is documented
> in our contributing document
> (http://www.djangoproject.com/documentation/contributing/#commit-access
> ):
>

> [...]
>
> 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.

Good, let's hope someone is brave enough.

Best,
Jannis