[core-workflow] Tracker workflow proposal

[Carol Willing]

Ezio, Brett, Nick, and David,

Your thoughts and additional information added some helpful insights and 
improvements.

Some thoughts in-line below.

Here's a link to a document that helps on-board people and demonstrates 
the many aspects a tracker communicates information to others in the 
community: https://wiki.openstack.org/wiki/How_To_Contribute  [It 
illustrates fairly concretely that the tracker supports several 
different workflows and many different community members.]

I'm going to go out on a limb and say that we're in agreement on a macro 
level. FWIW, a few thoughts below on 'state' naming.

State
-----
"Initial State"                                   (aka No Selection, 
Triage needed) [I can't think of a great word for this state.
                                                        What comes to 
mind is Harry Potter's Sorting Hat to determine where the issue should go]
Information Please                          (aka Information needed)
Decision Point                                (aka decision needed)
Patch Development                        (aka Patch needed)
Patch Review
Commit Review
Resolved

> This is exactly the way I thought as well: the initial default state 
> is "triage needed"
IMHO, "triage" has somewhat different connotations to each of us. It's 
probably best not to use it in the tracker as a state. This would allow 
documentation to treat "triage" as a process that may differ on the type 
of task or who is doing the task. My apologies for suggesting it as a 
state, but it has been interesting seeing the diversity in perspectives 
of what "triage" means.
> 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.
> Can we simply name the "no selection" state have the text "triage needed"?
Naming the "no selection" state has merit. Perhaps it auto defaults to 
the "first step" unless overridden by submitter.
>
>     I would rather keep the list of stages short, i.e.:
>
Agree that simple is better than complex.
>
>     with the following meanings
>       - no selection -: issue hasn't been triaged/looked at yet
>
>       information needed: something needs to be confirmed clarified before
>     proceeding
>       decision needed: an agreement should be reached before taking action
>       patch needed: we know what to do, we need the code
>       review needed: we have the code, we need someone to review it
>       commit (review) needed: we have the code, we need a committer to
>     commit it
>       resolved: issue is now closed
>
I like these descriptions of the states.
>
>     To illustrate the possible evolution of an issue I made a couple
>     of flow charts:
>     http://imgur.com/a/UgJBJ
>
Thanks for the visuals. They help support understanding the workflow :-)
>
>     Also note that is possible to go from basically every state to
>     "resolved", however I omitted those arrows, since they would just
>     clutter the flow chart.
>
Excellent point.

Thanks!
Carol

P.S. Happy to pitch in with documentation or tracker work as you move 
forward :-)

-- 
Carol Willing
Developer
Willing Consulting

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