Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Tue, Oct 5, 2010 at 9:58 AM, Tai Lee  wrote:
> Hi Russ,
>
> On Oct 5, 11:48 am, Russell Keith-Magee 
> wrote:
>
>> > Perhaps we need another triage stage for these tickets, "Needs final
>> > review" or something?
>>
>> That's essentially what RFC is. This is an area where our documented
>> procedures have lagged behind in-practice procedures, but we've
>> essentially accepted that once a patch has been written by one person,
>> and reviewed by another and found to be ok, then it's RFC, which means
>> a core committer needs to take a look.
>
> I'm happy for RFC to indicate that a ticket is ready for final review
> by a core committer, after being reviewed by at least someone other
> than the patch author. But, I think there's still a problem of
> accepted tickets that have a patch with docs and tests and no feedback
> indicating that it needs improvement, being lost in the shuffle, as
> well as how and why we ever end up with tickets in this state and how
> can the patch author get someone to review their work.

You can get a list of tickets that meet that criterion very easily -
it's tickets in "accepted" with a "patch needs improvement" flag.

This doesn't solve the problem of people who review a ticket, but
don't flick the "patch needs improvement" flag or provide feedback on
what exactly is wrong... but no technological solution will fix those
problem. The best we can hope for here is for a second reviewer to
come along and clean up the ticket state.

> It could happen that a ticket is accepted on merit, then it gets a
> patch with docs and tests, and then sits there getting no attention
> because nobody knows it needs a review. The patch author could just
> move it to RFC themselves as it had previously been accepted and he or
> she subsequently added the required docs and tests, in order to get
> somebody to look at it. But I think this is generally frowned upon and
> might take up too much core committer attention before the ticket is
> really ready.
>
> It could also happen that a ticket is unreviewed and already has a
> patch with docs and tests, if it is reviewed by a core committer (or
> not) and "accepted" without feedback about any necessary improvements,
> shouldn't it have simply gone straight to RFC instead? What should the
> original patch author do when his or her patch with docs and tests is
> reviewed by someone else and moved to "accepted" like this? There's no
> feedback that they need to incorporate into the patch, and they can't
> move their own work to RFC, even though someone else has reviewed and
> "accepted" the patch?
>
> I'd like to see the ticket system work smoothly in and of itself, and
> for tickets to be reviewed without the patch authors having to ask
> around on IRC or django-developers for someone to take a look. I don't
> want to make the ticket system too complicated, but I think it is
> already a bit muddled by determining whether or not a ticket needs
> review by checking 5 or 6 different properties, instead of a single
> clear indicator set by the patch author that he or she would like
> somebody (not necessarily a core committer) to review the work. This
> could also help in eliminating another problem of not knowing if a
> ticket is still being worked on or if the patch author considers it
> finished.

The problems you describe here fall into a couple of categories:

 * People doing triage, but not setting flags or giving feedback
correctly. This is a social problem; no technology is going to fix it
-- especially not adding *more* flags to our Trac configuration.
Improved documentation of what we expect *might* improve things here;
suggestions (and patches!) are welcome.

 * Improving visibility of work that needs to be done. This is
somewhere that Trac gardening is needed -- the relevant queries aren't
hard to write; they just need to be made more prominent.

 * Determining which ticket out of hundreds require attention. Two
ways to slice this that aren't currently available to us are ordering
by last modification date, and ordering by "popularity" (as determined
by users voting on tickets). Right now, the biggest impediment is that
our Trac install is *really* old, so all the nice new plugins
implementing these features won't run. We're in the process of
upgrading Trac; once that is done, we'll be able to add some of these
new features.

The only edge case I can see that you've identified that we don't
cover is people who upload incomplete patches which they *don't* want
reviewed yet. I don't see this as a major problem -- in my experience,
people upload patches because they think they're ready. Patches may
not always be correct, but I haven't seen a lot of people using Trac
as a temporary storage area for incomplete work. If someone uploads a
patch, they're generally looking for *some* feedback, even if it's
just "am I on the right track?"

>> As a general principle, DDN isn't usually a situation where 

Re: ANN: Improving our decision-making and committer process

[Tai Lee]

Hi Russ,

On Oct 5, 11:48 am, Russell Keith-Magee 
wrote:

> There have been a couple of suggestions recently that the contributing
> guide should be distilled into a specific HOWTO for new users. I
> suppose the idea here would be for the contribution guide to be the
> letter of the law, and the HOWTO to be the spirit of the law -- a
> lightweight guide pointing people at some specific activities they
> could engage in as a new contributor.

I see. Sounds reasonable. I can see that it might be difficult to
extract the relevant information from the full contributing guide for
newbies, as well as for long time users wanting a quick reference.

> > Perhaps we need another triage stage for these tickets, "Needs final
> > review" or something?
>
> That's essentially what RFC is. This is an area where our documented
> procedures have lagged behind in-practice procedures, but we've
> essentially accepted that once a patch has been written by one person,
> and reviewed by another and found to be ok, then it's RFC, which means
> a core committer needs to take a look.

I'm happy for RFC to indicate that a ticket is ready for final review
by a core committer, after being reviewed by at least someone other
than the patch author. But, I think there's still a problem of
accepted tickets that have a patch with docs and tests and no feedback
indicating that it needs improvement, being lost in the shuffle, as
well as how and why we ever end up with tickets in this state and how
can the patch author get someone to review their work.

It could happen that a ticket is accepted on merit, then it gets a
patch with docs and tests, and then sits there getting no attention
because nobody knows it needs a review. The patch author could just
move it to RFC themselves as it had previously been accepted and he or
she subsequently added the required docs and tests, in order to get
somebody to look at it. But I think this is generally frowned upon and
might take up too much core committer attention before the ticket is
really ready.

It could also happen that a ticket is unreviewed and already has a
patch with docs and tests, if it is reviewed by a core committer (or
not) and "accepted" without feedback about any necessary improvements,
shouldn't it have simply gone straight to RFC instead? What should the
original patch author do when his or her patch with docs and tests is
reviewed by someone else and moved to "accepted" like this? There's no
feedback that they need to incorporate into the patch, and they can't
move their own work to RFC, even though someone else has reviewed and
"accepted" the patch?

I'd like to see the ticket system work smoothly in and of itself, and
for tickets to be reviewed without the patch authors having to ask
around on IRC or django-developers for someone to take a look. I don't
want to make the ticket system too complicated, but I think it is
already a bit muddled by determining whether or not a ticket needs
review by checking 5 or 6 different properties, instead of a single
clear indicator set by the patch author that he or she would like
somebody (not necessarily a core committer) to review the work. This
could also help in eliminating another problem of not knowing if a
ticket is still being worked on or if the patch author considers it
finished.

> As a general principle, DDN isn't usually a situation where more
> information is needed; it's usually just time that is lacking.
>
> Sprints definitely help push this sort of thing along. However, that's
> more because we have two core developers in a room at the same time,
> not because of the presence of the rest of the community (although the
> community got lots of other great work done). Malcolm and I spend a
> day at the recent sprints just doing DDN tickets, and we managed to
> clear out quite a few DDNs. We made vague plans to hook up on
> IRC/Skype as a semi-regular activity to try and clear out the backlog,
> but we haven't made that happen yet.

Are at least two core committers required for all DDN tickets? Can a a
single core committer make decisions on minor or trivial tickets, and
the reporter be given the option to request a vote or further
consideration if they feel the decision is wrong (possibly based on
lack of information)? Perhaps some of the people who are well known
and long standing in the community (but who don't have commit access)
could make some of these decisions?

Cheers.
Tai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Tue, Oct 5, 2010 at 8:16 AM, Tai Lee  wrote:
> Hi Jacob,
>
> Thanks for your feedback.
>
>> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
>> linked in the nav). If there's anything missing there, please feel
>> free to add it -- it's a wiki page. Let me know if you need help
>> figuring out the linked query syntax.
>
> I wasn't able to edit this page. Other wiki pages have an "Edit this
> page" and "Attach file" buttons at the bottom, but not the Reports
> page.

It looks like that page has been locked down to prevent bad edits.
I'll put some wiki gardening on my todo list.

>> Work on (2) began at some point over 
>> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
>> still, but once it gets better I'd love to link sections from the
>> ticket page and/or move it into the docs directly.
>
> This is good, but it looks like mostly copy and paste from the
> "Contributing to Django" docs (duplication of data, also the Wiki is
> not authoritative, especially when not authored by a core committer)
> for the descriptions of each triage stage and patch flag, with the
> addition of next steps. I'm also not sure if this Wiki page is linked
> to from anywhere (e.g. actual ticket pages)?
>
> Perhaps we'd be better off simply adding the next steps information to
> the "Contributing to Django" docs directly, and to also update the
> diagram there to include the various patch flags (has patch, needs
> docs, needs tests, patch needs improvement) between the Accepted and
> Ready for checkin triage stages?

There have been a couple of suggestions recently that the contributing
guide should be distilled into a specific HOWTO for new users. I
suppose the idea here would be for the contribution guide to be the
letter of the law, and the HOWTO to be the spirit of the law -- a
lightweight guide pointing people at some specific activities they
could engage in as a new contributor.

> Perhaps we need another triage stage for these tickets, "Needs final
> review" or something?

That's essentially what RFC is. This is an area where our documented
procedures have lagged behind in-practice procedures, but we've
essentially accepted that once a patch has been written by one person,
and reviewed by another and found to be ok, then it's RFC, which means
a core committer needs to take a look.

>> Ideally, I'd like each ticket page to have a "what's next?" box on it
>> indicating where the ticket is and how to move it along. Technically
>> this isn't hard -- we've got plenty of folks in our community who
>> could write a Trac plugin -- but getting the language right is
>> important. If we get that worked out to some extent I'll figure out
>> what the next steps are technically.
>
> Perhaps another boolean flag that simply says if the next step lies
> with the patch author / community, or with the core committers?
> Similar to regular support tickets which might say "waiting on
> customer" or "waiting on support staff". This could help avoid
> situations where the patch author thinks they've done everything they
> need to do, satisfied all the requirements (docs, tests, code style),
> and yet their ticket is never pushed up to Ready for checkin, which
> only makes them less likely to contribute again in future and more
> likely to simply fix or work around their problem locally instead and
> save writing docs and tests for Django that go unused.

I don't know if another boolean flag is what is needed -- that strikes
me as more Trac gardening that can be mistriaged. Plus, the
information needed to determine the 'next step' is already there, you
just need to know how to read it. However, reading it requires a
little expertise and familiarity with the system.

A combination of Trac queries that can pull out tickets that need
attention, and an autogenerated text summary that clearly describes
the action required sounds like a valuable addition (i.e., distill the
Trac flags into a text statement of "This ticket needs external
review" or "This ticket isn't complete -- it's missing tests and/or
docs").

> Are only critical tickets eligible for a vote? I think there are a lot
> of non-critical (even trivial) tickets that are stuck in DDN hell :)
> Maybe we could organise regular DDN and Ready for checkin triage
> sprints?
>
> Also as DDN tickets must be decided by core committers, the community
> and patch authors can't really do anything with these tickets and they
> are stick in limbo. Perhaps there needs to be another flag to indicate
> whether the core committers need more information or a proposal for
> why a ticket should be included before they can make their decision,
> or if it has been added to the queue of tickets to be decided on
> (maybe with a position in the queue), and make sure that the queue is
> worked through in order, and either sent back to the patch author for
> more information or put to a vote if a decision can't be made?

As a general principle, DDN 

Re: ANN: Improving our decision-making and committer process

[Tai Lee]

Hi Jacob,

Thanks for your feedback.

> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
> linked in the nav). If there's anything missing there, please feel
> free to add it -- it's a wiki page. Let me know if you need help
> figuring out the linked query syntax.

I wasn't able to edit this page. Other wiki pages have an "Edit this
page" and "Attach file" buttons at the bottom, but not the Reports
page.

I was just going to add a link to tickets that are Accepted with a
patch that doesn't need docs, tests or improvement as tickets that
just need a fresh pair of eyes to review and either bump up to Ready
for checkin or back down to Patch needs improvement (with feedback).

I also noticed that 3 of the 4 existing links under "Tickets needing
some work" are incorrect. They indicate that they are accepted
tickets, but only one of these links is filtering by triage stage.

> Work on (2) began at some point over 
> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
> still, but once it gets better I'd love to link sections from the
> ticket page and/or move it into the docs directly.

This is good, but it looks like mostly copy and paste from the
"Contributing to Django" docs (duplication of data, also the Wiki is
not authoritative, especially when not authored by a core committer)
for the descriptions of each triage stage and patch flag, with the
addition of next steps. I'm also not sure if this Wiki page is linked
to from anywhere (e.g. actual ticket pages)?

Perhaps we'd be better off simply adding the next steps information to
the "Contributing to Django" docs directly, and to also update the
diagram there to include the various patch flags (has patch, needs
docs, needs tests, patch needs improvement) between the Accepted and
Ready for checkin triage stages?

At the moment all the docs / diagram say is that tickets which have a
patch with docs and tests are moved to ready for checkin, but a quick
search on trac revealed 358 tickets with this combination of triage
stage and patch flags. These tickets should all be either "patch needs
improvement" with feedback, or ready for checkin, right?

Perhaps we need another triage stage for these tickets, "Needs final
review" or something?

This is where I personally feel one of the big problems is with
perceived responsiveness of the core committers. These tickets are
sitting there as Accepted, and don't appear to require any further
action from the community or patch author (don't need a patch, docs,
tests or improved patch), and they are ignored by people wanting to
contribute and core committers alike.

> Ideally, I'd like each ticket page to have a "what's next?" box on it
> indicating where the ticket is and how to move it along. Technically
> this isn't hard -- we've got plenty of folks in our community who
> could write a Trac plugin -- but getting the language right is
> important. If we get that worked out to some extent I'll figure out
> what the next steps are technically.

Perhaps another boolean flag that simply says if the next step lies
with the patch author / community, or with the core committers?
Similar to regular support tickets which might say "waiting on
customer" or "waiting on support staff". This could help avoid
situations where the patch author thinks they've done everything they
need to do, satisfied all the requirements (docs, tests, code style),
and yet their ticket is never pushed up to Ready for checkin, which
only makes them less likely to contribute again in future and more
likely to simply fix or work around their problem locally instead and
save writing docs and tests for Django that go unused.

> For (3), well, feel free to bring things up here or on IRC, I s'pose.
> I'd really appreciate it if we didn't get 'em all brought up at once,
> of course. But yes, if there are tickets marked DDN that you feel are
> critical, please feel free to ask for a yay/nay.

Are only critical tickets eligible for a vote? I think there are a lot
of non-critical (even trivial) tickets that are stuck in DDN hell :)
Maybe we could organise regular DDN and Ready for checkin triage
sprints?

Also as DDN tickets must be decided by core committers, the community
and patch authors can't really do anything with these tickets and they
are stick in limbo. Perhaps there needs to be another flag to indicate
whether the core committers need more information or a proposal for
why a ticket should be included before they can make their decision,
or if it has been added to the queue of tickets to be decided on
(maybe with a position in the queue), and make sure that the queue is
worked through in order, and either sent back to the patch author for
more information or put to a vote if a decision can't be made?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email 

Re: ANN: Improving our decision-making and committer process

[Jacob Kaplan-Moss]

On Fri, Oct 1, 2010 at 1:44 AM, Tai Lee  wrote:
> I'd like to suggest (1) easy to find and use pre-defined searches to
> find tickets at each stage of triage, (2) a clearer indication of the
> next steps and the person responsible for it whenever a ticket is
> reviewed, and (3) tickets that have been sitting on DDN for a while be
> put to a vote.

This is completely right-on; I agree entirely. Some work has already
been done in these areas:

For (1) check out http://code.djangoproject.com/wiki/Reports (it's
linked in the nav). If there's anything missing there, please feel
free to add it -- it's a wiki page. Let me know if you need help
figuring out the linked query syntax.

Work on (2) began at some point over at
http://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
still, but once it gets better I'd love to link sections from the
ticket page and/or move it into the docs directly.

Ideally, I'd like each ticket page to have a "what's next?" box on it
indicating where the ticket is and how to move it along. Technically
this isn't hard -- we've got plenty of folks in our community who
could write a Trac plugin -- but getting the language right is
important. If we get that worked out to some extent I'll figure out
what the next steps are technically.

For (3), well, feel free to bring things up here or on IRC, I s'pose.
I'd really appreciate it if we didn't get 'em all brought up at once,
of course. But yes, if there are tickets marked DDN that you feel are
critical, please feel free to ask for a yay/nay.

Hope this gives you and/or others who want to help improve process a
place to channel that desire!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Tai Lee]

On Sep 30, 7:22 pm, Russell Keith-Magee 
wrote:

> What is also needed is a whole lot more people volunteering. Any
> suggestions on how to get more people doing the entirely unglamorous,
> but completely necessary work will be gratefully accepted.

I'd like to suggest (1) easy to find and use pre-defined searches to
find tickets at each stage of triage, (2) a clearer indication of the
next steps and the person responsible for it whenever a ticket is
reviewed, and (3) tickets that have been sitting on DDN for a while be
put to a vote.

The "stage" is not just unreviewed, DDN, accepted, RFC, someday/maybe,
and fixed on a branch. The "accepted" stage itself is broken down into
has patch, needs docs, needs tests, patch needs improvement.

As an example, http://code.djangoproject.com/ticket/13291 and
http://code.djangoproject.com/ticket/12398 both have a patch with docs
and tests, and were marked as "accepted" by a core committer (not that
it matters who reviewed them), without providing any actual feedback
and without stating that they need a better patch. These tickets are
fairly trivial and have been in limbo for 6-8 months.

As the original reporter and developer, I assumed that since these
tickets were reviewed by a core committer and "accepted" without any
feedback about needing a better patch, that they would be committed
shortly, or at least be moved to RFC shortly. These tickets are ideal
candidates for anyone doing triage (not only core committers) to
review and move to RFC, but they've been forgotten about by the
reviewer, assumed no further action was required by the developer, and
ignored in the sea of "accepted" tickets by everyone else.

So for (1), I'd like to see the how to contribute documentation asking
for people to triage specific sets of tickets with specific goals. For
example, to review tickets that are almost RFC and just waiting on
review (with a link to tickets that are accepted, with a patch that
has docs and tests and doesn't need improvement), or to review tickets
that just need docs or test (with links to appropriate searches), etc.

And for (2), I'd like to see tickets remember who reviewed them (who
accepted it, or who decided it needed a better patch, etc.) and for
the system to ping both the original reporter (or recently active
developer) and the reviewer after a period of inactivity. This should
hopefully catch tickets which are initially "accepted" and then
forgotten about.

Lastly I also have several tickets that have been DDN for 1-2 years,
so for (3), the reporter and recently active developers could be
notified that the DDN ticket will be put to a vote in say 1 or 2 weeks
time and allow them time to prepare any arguments or improved patch
that may sway the decision, or try to reach a consensus on django-
developers prior to the vote.

I've been working with Django for several years now and I have tried
to contribute useful tickets with patches including docs and tests
when possible, and it has at times been extremely discouraging to see
this effort go unnoticed for literally years without review (beyond a
passing glance to "accept" a ticket, in an attempt to reduce the
"unreviewed" backlog).

I've also felt that at busy times, some tickets that had merit but
didn't have an immediately apparent and elegant solution were rejected
simply save time leading up to a release.

I was pleased to see the recent announcement from Jacob about the
changes to the decision making process, but I think we also need to
improve the triage process so that tickets requiring action (including
decisions) can be directed to or found by the people responsible for
making those next steps happen.

Cheers.
Tai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote:

So, let me be clear on what you're proposing: you acknowledge that the
triage process is backlogged. Your proposal is to put extra workload
onto the core team - the one group that is already a bottleneck in the
process.


Pretty much. I just don't put it the way you do.

Triage process is backlogged not because of some strange reason. People 
need motivation to do daunting work and I can't imagine what could 
motivate enough volunteers to triage other people bugs regularly. And no 
amount documentation will fix this. A committer on the other hand is not 
just a volunteer. Being a committer of a high-profile open-source is a 
nice ego boost and committers receive more moral compensation than 
casual contributors. They are higher in an implicit project hierarchy 
and it matters to people.


As for bottleneck, I propose this only in light of Jacob's decision to 
increase the number of committers. This is certainly a prerequisite. 
It's not a question that committers are overloaded and this why this 
conversation has started.


To put it *really* short: I'm not trying to find extra work for 
committers, I'm bluntly saying that no one else would ever do it. So we 
have to find ways to do it. And having more committers and a simpler 
decision process does help here.



If you estimate that it takes an hour to close a ticket


This is BTW another, purely technical, problem. It shouldn't take an 
hour to close a ticket if it has proper tests. I was testing patches 
during various sprints and one big thing that I learned is that our 
whole test suit needs a deep refactoring to be simpler and faster. But 
this is another story...


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thursday, September 30, 2010, Ivan Sagalaev
 wrote:
> On 09/30/2010 03:46 AM, Russell Keith-Magee wrote:
>
> Accepted tickets can be:
>
>   * Purely accepted, indicating that someone has verified that the
> problem exists, but not how to solve it
>
>   * Accepted with a patch that is wrong in some way (e.g., fixing the
> symptom, not the problem)
>
>   * Accepted with a patch that is missing documentation or tests
>
>   * Accepted with a valid patch, just awaiting review by someone else.
>
> A ticket in the first three conditions patently isn't ready for
> checkin. A ticket in the last condition *may* be ready for checkin; we
> ask for independent verification before it gets moved to RFC.
>
> So - IMHO "Accepted" plays a very important role in our triage system.
>
>
> To me this shows exactly the opposite: a status that has so many meanings 
> doesn't really mean anything useful :-). I'm not new in Django development 
> yet as you see I managed to misunderstand its meaning in my previous mail.

Accepted means exactly one thing - the issue has been verified as a
real problem (or acknowledged as a reasonable feature request), but
isn't yet ready for inclusion in trunk.

If viewed in combination with the other flags on a ticket, you can
work out why a ticket isn't ready for inclusion in trunk - it needs
documentation, it needs tests, it needs a patch, or the patch that
exists needs improvement.

As Waylan noted, this probably indicates that our documentation needs
to be improved.

> Anyway, what I'm saying is that we have this huge gap between someone writing 
> a good patch (with docs & tests) and the moment it gets into trunk. Current 
> mechanism of volunteer triagers who are supposed to move such tickets from 
> 'accepted' into 'ready for checkin' doesn't seem to work.

The officially documented practice is that the "triage team" moves
tickets to RFC. However, this hasn't been actual practice for some
time. The effective practice is that anyone other than the submitted
of a patch can m ove a ticket to RFC if they feel confident that it is
ready.

This is certainly an area where the documentation needs to be
improved, in order to reflect common practice.

What is also needed is a whole lot more people volunteering. Any
suggestions on how to get more people doing the entirely unglamorous,
but completely necessary work will be gratefully accepted.

> So let me mend my suggestion to better fit reality. Instead of removing 
> 'accepted' altogether (though I still think it's a good idea) I think each 
> committer has to do this routinely. I know that every programmer would rather 
> code instead of applying patches and running tests but the development 
> process simply won't scale otherwise.

So, let me be clear on what you're proposing: you acknowledge that the
triage process is backlogged. Your proposal is to put extra workload
onto the core team - the one group that is already a bottleneck in the
process.

During the 1.2 release cycle, I had to spend almost 2 weeks checking
tickets in the unreviewed state in order to check that no release
blocking bugs had been reported. This amounts to something like 50
hours of development effort - 50 hours that I didn't spend closing
bugs. If you estimate that it takes an hour to close a ticket, that
means 1.2 has 50 more bugs in it than it would have had if someone not
on the core team had performed the triage task.

As I write this, there are 215 tickets in the unreviewed state. There
is plenty of triage work to do, and absolutely no reason that the core
team has to be the group to do it.

> BTW, Bazaar guys use the approach with a "champion of the week". Every week a 
> person from core committers volunteers to actively do triaging and committing 
> new and old tickets in the tracker. May be such explicit approach would work 
> for Django too. Especially since we're about to have more committers than we 
> do now.

The core team volunteers the time that they have available. Some weeks
that means a lot of time; some weeks it means no time. Sometimes time
is spent closing tickets, and sometimes - when it's clear that there
is a backlog of unreviewed tickets blocking a release, for example -
the core team will do triage.

The core team isn't wanting for things to do. There a plenty of
tickets in RFC; there is lots of mailing list traffic that needs
attention; there are new features that need to be designed, built and
reviewed; and yes, there is triage. Forcing core developers to do
triage exclusively simply takes energy away from other, equally
important tasks that form part of the development process.

On top of that, I can't speak for anyone else in the core team, but I
fail to see see how a formal "this week is my week" arrangement will
increase the time I have available to volunteer to the project. If
anything, I see it decreasing the quantity of volunteered time,
because if I don't think I will be able to dedicate an entire week, I

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote:

Accepted tickets can be:

  * Purely accepted, indicating that someone has verified that the
problem exists, but not how to solve it

  * Accepted with a patch that is wrong in some way (e.g., fixing the
symptom, not the problem)

  * Accepted with a patch that is missing documentation or tests

  * Accepted with a valid patch, just awaiting review by someone else.

A ticket in the first three conditions patently isn't ready for
checkin. A ticket in the last condition *may* be ready for checkin; we
ask for independent verification before it gets moved to RFC.

So - IMHO "Accepted" plays a very important role in our triage system.


To me this shows exactly the opposite: a status that has so many 
meanings doesn't really mean anything useful :-). I'm not new in Django 
development yet as you see I managed to misunderstand its meaning in my 
previous mail.


Anyway, what I'm saying is that we have this huge gap between someone 
writing a good patch (with docs & tests) and the moment it gets into 
trunk. Current mechanism of volunteer triagers who are supposed to move 
such tickets from 'accepted' into 'ready for checkin' doesn't seem to work.


So let me mend my suggestion to better fit reality. Instead of removing 
'accepted' altogether (though I still think it's a good idea) I think 
each committer has to do this routinely. I know that every programmer 
would rather code instead of applying patches and running tests but the 
development process simply won't scale otherwise.


BTW, Bazaar guys use the approach with a "champion of the week". Every 
week a person from core committers volunteers to actively do triaging 
and committing new and old tickets in the tracker. May be such explicit 
approach would work for Django too. Especially since we're about to have 
more committers than we do now.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thu, Sep 30, 2010 at 9:14 AM, Waylan Limberg  wrote:
> On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee
>  wrote:
>> On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
>>> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>>>
 My suggestion is about this unfortunate ticket status -- 'Accepted'.
 This now works as a sort of a dusty shelf: when anyone of the core team
 looks at the patch and decides that there's nothing wrong with it he
 puts it on that shelf where the ticket has all the chances to lie for
 months or even years. And if the author of the patch tries from time to
 time pitching it to get it into trunk he can easily fall into all sorts
 of "not-a-good-times": conferences, feature freezes, hot discussions on
 other topics etc.

 My proposal is simple: 'Accepted' status shouldn't exist. If the patch
 is good it should be committed right away. If it's not there have to be
 an explanation why it needs improvement or why it's going to be
 wontfixed. Simple waiting doesn't really improve quality of the patch.

 What do you think?
>>>
>>> This doesn't account for these facts:
>>>
>>> 1) Accepted != Ready for checkin.
>>> 2) A lot of triage is done by people without commit access.
>>>
>>> Sometimes a ticket stays at 'Accepted' for a long time because it
>>> doesn't actually have anyone motivated enough to write even a patch, or
>>> tests etc, which means that it is de-facto low priority, and we
>>> shouldn't feel guilty about this kind.  The ones in the 'Ready for
>>> checkin' queue are the ones that deserve to be checked in, and it
>>> currently has only 35 in it, compared to 1226 in 'Accepted'.
>>
>> This is an important stat -- but it glosses over the fact that 1226
>> "accepted" tickets doesn't necessarily clarify how many of these have
>> viable patches -- or patches at all.
>>
>> Accepted tickets can be:
>>
>>  * Purely accepted, indicating that someone has verified that the
>> problem exists, but not how to solve it
>>
>>  * Accepted with a patch that is wrong in some way (e.g., fixing the
>> symptom, not the problem)
>>
>>  * Accepted with a patch that is missing documentation or tests
>>
>>  * Accepted with a valid patch, just awaiting review by someone else.
>>
>> A ticket in the first three conditions patently isn't ready for
>> checkin. A ticket in the last condition *may* be ready for checkin; we
>> ask for independent verification before it gets moved to RFC.
>
> So, in other words, accepted simply means that the ticket reports a
> valid bug or feature request that is considered worth fixing, but
> offers to indication as to the status of any patches for committing.
> Obviously, some seem to imply the later meaning into "Accepted" which
> could raise the question regarding whether it is named correctly (I
> say it is fine). But, more importantly, is there a place were each
> status is simply defined?
>
> Sure there is this:
> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage
>
> But that hardly makes clear exactly what "accepted" actually means.
> The text in that section is helpful to understanding the basic
> process, but if someone changes the status of my ticket, there's no
> definitive place to go and see exactly what that status means.
>
> In fact, in reading the list over the last few years, I have the
> impression that this is a problem that is repeated constantly. People
> don't understand what the various statuses mean and get frustrated
> when things do not happen as they expected. I think perhaps clearer
> documentation would help in this case.

A reasonable suggestion if ever I've heard one. I've opened a ticket
to track the idea:

http://code.djangoproject.com/ticket/14360

and I've put it on the 1.3 milestone; if anyone wants to take a swing
a clarifying the language before I (or someone else on the core team)
gets a chance to look at it, feel free.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Waylan Limberg]

On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee
 wrote:
> On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
>> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>>
>>> My suggestion is about this unfortunate ticket status -- 'Accepted'.
>>> This now works as a sort of a dusty shelf: when anyone of the core team
>>> looks at the patch and decides that there's nothing wrong with it he
>>> puts it on that shelf where the ticket has all the chances to lie for
>>> months or even years. And if the author of the patch tries from time to
>>> time pitching it to get it into trunk he can easily fall into all sorts
>>> of "not-a-good-times": conferences, feature freezes, hot discussions on
>>> other topics etc.
>>>
>>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch
>>> is good it should be committed right away. If it's not there have to be
>>> an explanation why it needs improvement or why it's going to be
>>> wontfixed. Simple waiting doesn't really improve quality of the patch.
>>>
>>> What do you think?
>>
>> This doesn't account for these facts:
>>
>> 1) Accepted != Ready for checkin.
>> 2) A lot of triage is done by people without commit access.
>>
>> Sometimes a ticket stays at 'Accepted' for a long time because it
>> doesn't actually have anyone motivated enough to write even a patch, or
>> tests etc, which means that it is de-facto low priority, and we
>> shouldn't feel guilty about this kind.  The ones in the 'Ready for
>> checkin' queue are the ones that deserve to be checked in, and it
>> currently has only 35 in it, compared to 1226 in 'Accepted'.
>
> This is an important stat -- but it glosses over the fact that 1226
> "accepted" tickets doesn't necessarily clarify how many of these have
> viable patches -- or patches at all.
>
> Accepted tickets can be:
>
>  * Purely accepted, indicating that someone has verified that the
> problem exists, but not how to solve it
>
>  * Accepted with a patch that is wrong in some way (e.g., fixing the
> symptom, not the problem)
>
>  * Accepted with a patch that is missing documentation or tests
>
>  * Accepted with a valid patch, just awaiting review by someone else.
>
> A ticket in the first three conditions patently isn't ready for
> checkin. A ticket in the last condition *may* be ready for checkin; we
> ask for independent verification before it gets moved to RFC.

So, in other words, accepted simply means that the ticket reports a
valid bug or feature request that is considered worth fixing, but
offers to indication as to the status of any patches for committing.
Obviously, some seem to imply the later meaning into "Accepted" which
could raise the question regarding whether it is named correctly (I
say it is fine). But, more importantly, is there a place were each
status is simply defined?

Sure there is this:
http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

But that hardly makes clear exactly what "accepted" actually means.
The text in that section is helpful to understanding the basic
process, but if someone changes the status of my ticket, there's no
definitive place to go and see exactly what that status means.

In fact, in reading the list over the last few years, I have the
impression that this is a problem that is repeated constantly. People
don't understand what the various statuses mean and get frustrated
when things do not happen as they expected. I think perhaps clearer
documentation would help in this case.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Russell Keith-Magee]

On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant  wrote:
> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:
>
>> My suggestion is about this unfortunate ticket status -- 'Accepted'.
>> This now works as a sort of a dusty shelf: when anyone of the core team
>> looks at the patch and decides that there's nothing wrong with it he
>> puts it on that shelf where the ticket has all the chances to lie for
>> months or even years. And if the author of the patch tries from time to
>> time pitching it to get it into trunk he can easily fall into all sorts
>> of "not-a-good-times": conferences, feature freezes, hot discussions on
>> other topics etc.
>>
>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch
>> is good it should be committed right away. If it's not there have to be
>> an explanation why it needs improvement or why it's going to be
>> wontfixed. Simple waiting doesn't really improve quality of the patch.
>>
>> What do you think?
>
> This doesn't account for these facts:
>
> 1) Accepted != Ready for checkin.
> 2) A lot of triage is done by people without commit access.
>
> Sometimes a ticket stays at 'Accepted' for a long time because it
> doesn't actually have anyone motivated enough to write even a patch, or
> tests etc, which means that it is de-facto low priority, and we
> shouldn't feel guilty about this kind.  The ones in the 'Ready for
> checkin' queue are the ones that deserve to be checked in, and it
> currently has only 35 in it, compared to 1226 in 'Accepted'.

This is an important stat -- but it glosses over the fact that 1226
"accepted" tickets doesn't necessarily clarify how many of these have
viable patches -- or patches at all.

Accepted tickets can be:

 * Purely accepted, indicating that someone has verified that the
problem exists, but not how to solve it

 * Accepted with a patch that is wrong in some way (e.g., fixing the
symptom, not the problem)

 * Accepted with a patch that is missing documentation or tests

 * Accepted with a valid patch, just awaiting review by someone else.

A ticket in the first three conditions patently isn't ready for
checkin. A ticket in the last condition *may* be ready for checkin; we
ask for independent verification before it gets moved to RFC.

So - IMHO "Accepted" plays a very important role in our triage system.
I don't think it can be eliminated without overloading a different
area of the ticket system.

> However, there are many 'Accepted' tickets which actually ought to be in
> 'Ready for checkin', or need some feedback to say what should be done to
> move them on.  This is not something that can only be done by
> committers, but how to get help with this massive task is still a big
> problem. It's quite possible for someone using Django to submit a
> completely valid bug report, with a good patch and tests etc., and for
> it not to get reviewed because no-one else in the community cares about
> that particular bug, and I for one don't know what to do about that.

There was some work done at DjangoCon to try and provide a voting
extension to Trac. The aim here would be to provide a way for people
to register "I've been bitten by this bug", so we can get a list of
issues ordered by how many people are being affected. This will
hopefully provide some direction to triage (and committer) activity so
that the "most important" tickets get addressed first.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Luke Plant]

On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote:

> My suggestion is about this unfortunate ticket status -- 'Accepted'. 
> This now works as a sort of a dusty shelf: when anyone of the core team 
> looks at the patch and decides that there's nothing wrong with it he 
> puts it on that shelf where the ticket has all the chances to lie for 
> months or even years. And if the author of the patch tries from time to 
> time pitching it to get it into trunk he can easily fall into all sorts 
> of "not-a-good-times": conferences, feature freezes, hot discussions on 
> other topics etc.
> 
> My proposal is simple: 'Accepted' status shouldn't exist. If the patch 
> is good it should be committed right away. If it's not there have to be 
> an explanation why it needs improvement or why it's going to be 
> wontfixed. Simple waiting doesn't really improve quality of the patch.
> 
> What do you think?

This doesn't account for these facts:

1) Accepted != Ready for checkin.
2) A lot of triage is done by people without commit access.

Sometimes a ticket stays at 'Accepted' for a long time because it
doesn't actually have anyone motivated enough to write even a patch, or
tests etc, which means that it is de-facto low priority, and we
shouldn't feel guilty about this kind.  The ones in the 'Ready for
checkin' queue are the ones that deserve to be checked in, and it
currently has only 35 in it, compared to 1226 in 'Accepted'.

However, there are many 'Accepted' tickets which actually ought to be in
'Ready for checkin', or need some feedback to say what should be done to
move them on.  This is not something that can only be done by
committers, but how to get help with this massive task is still a big
problem. It's quite possible for someone using Django to submit a
completely valid bug report, with a good patch and tests etc., and for
it not to get reviewed because no-one else in the community cares about
that particular bug, and I for one don't know what to do about that.

The core team do agree that the "it's not a good time" response has been
an unhelpful sticking point, and we probably need to make it easier for
people to discuss things at any point in time.

Luke

-- 
"Defeat: For every winner, there are dozens of losers.  Odds are 
you're one of them." (despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:40 AM, Chuck Harmston wrote:

In my world, the "accepted" status should only be used in one
circumstance: when a person is actively developing under or maintaining
a patch for the ticket. It's an indicator that someone has taken
ownership of a ticket, to prevent duplication of effort, etc. For
example, I accepted ticket #25 during the DjangoCon sprints to prevent
other developers at the sprints from attempting to develop against the
ticket.


I believe the field 'Assigned to' works just fine for this purpose, no?

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Chuck Harmston]

In my world, the "accepted" status should only be used in one circumstance:
when a person is actively developing under or maintaining a patch for the
ticket. It's an indicator that someone has taken ownership of a ticket, to
prevent duplication of effort, etc. For example, I accepted ticket #25
during the DjangoCon sprints to prevent other developers at the sprints from
attempting to develop against the ticket.

Then again, my world also has purple skies and orange grass, so take it with
a grain...errr, a bushel of salt. ;)

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com


On Wed, Sep 29, 2010 at 5:32 PM, Ivan Sagalaev
wrote:

> Hello Jacob and everyone.
>
>
> On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:
>
>> Starting today, we're going to be making some minor but significant
>> changes
>> to the way the Django core committer team "does business."
>>
>
> That's about time :-). Congratulations and thank you!
>
> I have a comment and a suggestion:
>
>
>  This new process allows a proposal to be carried if:
>>
>> * There are at least 3 "+1" votes from core committers.
>> * There are no "-1" votes from core committers.
>> * A BDFL hasn't issued a ruling on the issue.
>>
>
> This doesn't explain what's one is supposed to think in situation when a
> proposal is ignored by core devs, which may happen for all sorts of reasons.
> I suspect that "less than 3 +1 votes" means the same as any -1 vote but I
> think that an explicit clarification would be nice.
>
> ---
>
> My suggestion is about this unfortunate ticket status -- 'Accepted'. This
> now works as a sort of a dusty shelf: when anyone of the core team looks at
> the patch and decides that there's nothing wrong with it he puts it on that
> shelf where the ticket has all the chances to lie for months or even years.
> And if the author of the patch tries from time to time pitching it to get it
> into trunk he can easily fall into all sorts of "not-a-good-times":
> conferences, feature freezes, hot discussions on other topics etc.
>
> My proposal is simple: 'Accepted' status shouldn't exist. If the patch is
> good it should be committed right away. If it's not there have to be an
> explanation why it needs improvement or why it's going to be wontfixed.
> Simple waiting doesn't really improve quality of the patch.
>
> What do you think?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

Hello Jacob and everyone.

On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:

Starting today, we're going to be making some minor but significant changes
to the way the Django core committer team "does business."


That's about time :-). Congratulations and thank you!

I have a comment and a suggestion:


This new process allows a proposal to be carried if:

* There are at least 3 "+1" votes from core committers.
* There are no "-1" votes from core committers.
* A BDFL hasn't issued a ruling on the issue.


This doesn't explain what's one is supposed to think in situation when a 
proposal is ignored by core devs, which may happen for all sorts of 
reasons. I suspect that "less than 3 +1 votes" means the same as any -1 
vote but I think that an explicit clarification would be nice.


---

My suggestion is about this unfortunate ticket status -- 'Accepted'. 
This now works as a sort of a dusty shelf: when anyone of the core team 
looks at the patch and decides that there's nothing wrong with it he 
puts it on that shelf where the ticket has all the chances to lie for 
months or even years. And if the author of the patch tries from time to 
time pitching it to get it into trunk he can easily fall into all sorts 
of "not-a-good-times": conferences, feature freezes, hot discussions on 
other topics etc.


My proposal is simple: 'Accepted' status shouldn't exist. If the patch 
is good it should be committed right away. If it's not there have to be 
an explanation why it needs improvement or why it's going to be 
wontfixed. Simple waiting doesn't really improve quality of the patch.


What do you think?

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

ANN: Improving our decision-making and committer process

[Jacob Kaplan-Moss]

Hi folks --

Starting today, we're going to be making some minor but significant changes
to the way the Django core committer team "does business."

Put simply, we're changing the way we make decisions so that we can make
important policy and design calls more quickly and easily. In a nutshell:

* We're substantially reducing the number of decisions that Adrian and I
  need to make as BDFLs, thus removing us as a decision-making bottleneck.

* We're cutting back on our reliance on consensus for decision making,
  thus ensuring that decisions can be made in a timely manner.

* Finally -- and I think most importantly -- we're relaxing our policy on
  adding new core committers.

I've just made a couple of changes [1] to our "Contributing to Django"
guide [2] which explain these changes; read them if you want the short
explanation of the new rules.

[1] http://code.djangoproject.com/changeset/13962
[2] http://docs.djangoproject.com/en/dev/internals/contributing/

For those who've been following our development process closely -- and
calling for these kind of changes for quite some time -- I'll explain some
of the background and ramification in more detail below.

Some background
---

The discussion leading to these changes began with conversations Russ had
at DjangoCon. I wasn't there, but he reported that there was a repeated and
general dissatisfaction with the activity and responsiveness of the core
team. I don't think this came as a surprise to any of us. I, at least, have
felt like we've been lax in our responsibilities lately.

Now, I don't really care to examine the merits of individual complaints or
make excuses/explanations for the lack of time and attention the core
team's been paying. Any way you cut it, it's clear that the core team --
and Adrian and I in particular -- have some work to do to regain the
confidence and trust of the community.

It's clear this won't happen overnight, and I don't expect the changes
we're making today to magically grant us that confidence back. Instead, I
see these changes as the first step in a general process towards more
openness and inclusiveness in Django's development process.

Making decisions


One of the main reasons we've ended up in this situation is our decision
making process. When we first came up with Django's development process,
Django was a tiny project with a handful of developers and a
not-much-larger group of users. In that context, decision by consensus made
some sense, but it simply doesn't scale as the number of participants increases.

In particular, our reliance on consensus means that any developer can
accidentally execute a veto simply by not having time to participate in
discussions!

We've always had the "out" of appealing to Adrian or I for a BDFL decision.
However, that, too, did't scale as the number of decisions-to-be-made
increased (and our own spare time decreased).

So we've adopted a new, simple, streamlined voting process. This deals with
situations where we can't reach a quick consensus, and it cuts out the
requirement that Adrian and/or I rule on each and every decision.

This new process allows a proposal to be carried if:

* There are at least 3 "+1" votes from core committers.
* There are no "-1" votes from core committers.
* A BDFL hasn't issued a ruling on the issue.

Since this process allows any core committer to veto a proposal, any "-1"
votes (or BDFL vetos) should be accompanied by an explanation that explains
what it would take to convert that "-1" into at least a "+0".

More details are in the contributor doc, but in essence this means that we
can move forward without needing to wait for the entire core team to weigh
in. It does maintain our fairly skeptical attitude towards feature-creep by
allowing any one contributor to object if something rubs him/her the wrong
way, but it also forces that contributor to explain how she/he may be
overruled.

With luck, we'll see the pace of development speed up a bit as a result.

I should stress that this voting procedure DOES NOT replace community
discussion, nor does it remove entirely the desire for consensus. In other
words, this new process is a new way to "break ties" without having to ask
for a BDFL ruling. Whenever possible, we should continue to strive to reach
consensus on issues, and use the voting process only as a fallback where
consensus can't be reached for whatever reason. I, at least, plan to vote
"-1" if I see community discussion being skipped, or if I see no attempt at
consensus before a vote.

Committers
--

It's been clear for quite some time that there's a really right bottleneck
at the top of the project: we simply don't have enough committers. The
issue of adding new ones comes up fairly regularly, but has never come to
any conclusion.

We've deliberately set the bar for new contributors quite high: new
committers required unanimous approval of all existing committers. We've
resisted lowering that bar out of a fear