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" <willi...@willingconsulting.com
<mailto:willi...@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
_______________________________________________
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct:
https://www.python.org/psf/codeofconduct
