[Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

[glyph at divmod.com]

On 02:39 am, guido at python.org wrote:
>I'm disappointed in the process -- it's as if nobody really reviewed
>the API until it was released with rc1, and this despite there being a
>significant discussion about its inclusion and alternatives months
>ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me
>in the behind, and I can honestly say that I don't know whether /8
>means to look only at the first 8 bits or whether it means to mask off
>the last 8 bits.)
>
>I hope we can learn from this.

As he pointed out to Martin, Jean-Paul voiced objections several months 
ago which are similar to the ones which are now being discussed.  To be 
fair, he didn't unambiguously say "... and therefore don't include this 
library"; he simply suggested that netaddr was superior in some ways and 
that perhaps some documentation could illuminate why ipaddr was better.

I've been frustrated with similar aspects of Python's development 
process in the past.  The biggest problem I can see is that it's too 
hard to follow the discussion, and catch oneself up on the discussion 
thus far.

It's also difficult to refer back to posts much earlier in the history 
of an email discussion, and that frequently needs to be done when 
someone jumps into the middle of a discussion.

The way Twisted dealt with this particular issue was to move *all* 
discussions relevant to a particular feature into the ticket for that 
feature.  If discussion starts up on the mailing list, within a few 
messages of it starting, someone on the dev team will pipe up and say 
"Hey, here's the ticket for this, could you add a link to this 
discussion and a summary".

Once on a ticket, the phraseology and typesetting used by our core team 
has reached a very precise consensus.  Like the feature?  "Merge this 
patch" or "Land this branch".  Don't like it?  "Thanks for your patch, 
but:", followed by a list of enumerated feedback.  The required 
reactions to such feedback are equally well understood.  Even if a 
comment isn't a full, formal code review, it still follows a similar 
style.

This system is possibly too simplistic for the more wide-ranging 
development of Python; although Twisted has its share of enthusiastic 
discussions, there is rarely the level of controversy I see here on 
python-dev, so I can't recommend it as such.  I can say that keeping 
ticket discussions on tickets is generally a good idea, though, 
especially in a system like roundup or trac where it's easy to say "see 
message 7" rather than repeating yourself.

It seems that there is a habit of occasionally using ASF-style 
+1/+0/-0/-1 markers, but it's inconsistently applied.  More importantly, 
nobody ever actually adds them up, so it's not entirely clear when they 
should be used.

To go back to JP's original comments though: what was the right thing 
for him to do, back in January, when he had these concerns?  Should he 
have said "I am therefore -1 on this inclusion"?  Should he have been 
discussing this on the mailing list rather than the tracker?  Should he 
have kept coming back to the ticket and answering every single message 
reinforcing his original conclusions?  I honestly don't think it's very 
clear what one is "officially" supposed to do.  Without a clear 
expectation that one should say "No" to features that are problematic, 
it seems gratuitously mean to do so; so, it's nicer to just say "here's 
what I found" with the hopes that someone will evaluate that feedback.

Unfortunately it seems like the winning strategy here is just to keep 
flogging a dead horse until it's a dead horse hamburger; reply and reply 
and reply until everybody gets sick of talking about it.  Repeat your 
original points in every post so that nobody will miss them.  I think 
everyone is ill-served by this discussion format.  Certainly when I 
voice my own objections or support for something, I'd like to just stop 
by, add a note for the committers to take into account when considering 
the issue, and then go away.

So, here are my recommendations:

  1. Use the tracker for discussing tickets, so that it's easy to refer 
back to a previous point in the discussion, and so that people working 
on those tickets can easily find your commentary.
  2. Use the mailing list for drawing attention to these discussions if 
they are of general interest, especially if the discussion is time- 
critical.  In this case, an announcement "You have six weeks to review 
ipaddr now until its inclusion is permanent, anyone interested please 
look at issue 3959."
  3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at 
the top of your message, so that it's easy for newcomers to the 
discussion to get a general feel.

Of course, this won't prevent all meandering discussions, or discussions 
that are too late to the party, but I do think it will help.

However, I think before everyone just starts doing this, even *more* 
important is my meta-suggestion: let's agree on how and when feedback is 
useful, and when it will be considered, so that it's not just a contest 
to overflow Guido's inbox.  The opinion of the committers who will be 
considering feedback is much more important than mine :).