[core-workflow] Tracker workflow proposal

[Ezio Melotti]

On Thu, May 8, 2014 at 8:42 PM, Carol Willing
<willingc at willingconsulting.com> wrote:
> 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.
>

FWIW when I started contributing I didn't even know the meaning of the
word "triage" (not even in medical context), and I don't think there
is any corresponding word in my native language.

> 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".
>

Maybe we could use "agreement" or "consensus" (or something equivalent) instead.
For simple issues any core dev could take the decision directly
(especially if the issue is related to releases or other policies that
contributors might not be aware of), but otherwise taking the decision
is a group process where anyone can contribute (much like what we are
doing here).

> 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 wonder if only triagers/committers should have the stage field
visible while creating a new issue.
That would help making sure that, if the stage is different from "no
selection",  at least a triager looked at the issue.  If the field is
available to anyone, contributors might set it correctly, but leave
other important fields unset, and triagers might end up ignoring the
issues because it looks already triaged.

>>
>> 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
>