[core-workflow] [Sub_Issue: State Naming re: Decisions] Tracker workflow proposal

[Carol Willing]

Nick and Ezio,

Thanks! We're in sync. I appreciate your thoughtful responses regarding 
the state label "decision needed".

I'm +1 on transparency and clarity around consensus building and do not 
disagree with "final decision" authority rests with the module 
maintainer or core dev which is far better than languishing issues.

I believe it would be helpful for some of Nick and Ezio's thoughts 
making it into some documentation (dev guide?): "...an autocratic 
decision from a core developer or module maintainer is a last resort to 
get an issue moving again, rather than the preferred approach...decision 
making authority is essentially limited getting to define how rough 
"rough consensus" can be in any given situation, and even if a core dev 
or module maintainer is needed to make the final call, we're often in 
the situation of catching up on a discussion that may have been going on 
for a while."

Any of these names (Green light needed, consensus/decision needed, or 
decision needed) will work well when combined with greater community 
education (via docs and other communication mechanisms).

Hopefully, this upfront dialogue will help the workflow tracker enable 
more people to contribute most effectively and in turn will reward core 
devs with more "meaningful" work not just more work.

Regards,
Carol

P.S. Antoine, Point taken. If anyone is aware of a dynamic mailing list 
message "diff" organizer other than brute force, I would love to know. 
Cheers!

On 5/8/14, 3:07 PM, Nick Coghlan wrote:
>
>
> On 9 May 2014 04:32, "Carol Willing" <willingc at willingconsulting.com 
> <mailto:willingc at willingconsulting.com>> wrote:
> >
> >> and "decision needed" means someone higher up has to make a call on 
> a question.
> >
> > My apologies in advance if my ability to communicate in writing my 
> next point is below par. Before I say what I am feeling, I want to be 
> clear that I have strong respect for the core developers and 
> committers based on their dedication to and passion for Python. I also 
> have great respect for others that contribute in many different ways 
> and the talents that they bring to a team.
> >
> > I can't quite put my finger on why, but my gut reaction to "decision 
> needed" when coupled with words like "higher ups", "more experienced", 
> "control", "hierarchy", "proven" is unwelcoming and a little 
> patronizing. Oddly, simply stating "decision point" or "decision" as a 
> state does not invoke the same reaction. I think the word "needed" 
> subtly adds the implication that I am not trusted, capable enough, or 
> proven my intelligence to make a decision, and I must wait to get 
> permission from an "authority figure".
> >
> > Not a huge sticking point if consensus wants to keep it as "decision 
> needed". I have actually found folks to be helpful and collaborative. 
> I'm merely throwing my reaction out there because I trust you to 
> consider it.
>
> "Consensus/decision needed" may be a more accurate name for the state 
> - an autocratic decision from a core developer or module maintainer is 
> a last resort to get an issue moving again, rather than the preferred 
> approach. "Rough consensus and running code" (or "readable text" in 
> the docs case) is a much better option when it works, but that can 
> occasionally stall with no way to move forward (or, worse, descend 
> into bitter acrimony over a potentially trivial issue) in the absence 
> of an escalation procedure of some kind.
>
> So core devs (& particularly module maintainers) really do have 
> decision making authority. I don't think we'd be doing anyone any 
> favours by pretending that hierarchy doesn't exist instead of trying 
> to make it as transparent as possible - including the fact that 
> gaining more responsibility (for those that want it) is mostly a case 
> of "the reward for doing work well is being offered the chance to do 
> more work".
>
> On the other hand, Ezio's also right that our decision making 
> authority is essentially limited getting to define how rough "rough 
> consensus" can be in any given situation, and even if a core dev or 
> module maintainer is needed to make the final call, we're often in the 
> situation of catching up on a discussion that may have been going on 
> for a while (see the couple of paragraphs in 
> http://www.joelonsoftware.com/articles/fog0000000072.html that start 
> with "At Microsoft, management was extremely hands-off.")
>
> In those cases, *anyone* can take it upon themselves to:
>
> * write a comment on the issue tracker summarising the competing 
> perspectives and their pros and cons
> * escalating the issue to python-dev for broader discussion 
> (preferably with a summary like the one above)
> * for more radical/controversial notions, start a thread on 
> python-ideas to request help in building a compelling case for the 
> proposal
>
> Sometimes those acts will allow consensus to emerge without an 
> explicit decision being needed from anyone.
>
> Cheers,
> Nick.
>


-- 
Carol Willing
Developer
Willing Consulting

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140508/c788c1f4/attachment.html>