From rdmurray at bitdance.com  Wed Apr 16 18:23:53 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Apr 2014 12:23:53 -0400
Subject: [core-workflow] start up
Message-ID: <20140416162354.09AF1250029@webabinitio.net>

I've subscribed Nick, Brett, and Jessica to this list to start out.

Jessica: Nick and Brett and I (as well as some other people) had
a conversation at the sprints about where it would be appropriate to
conduct the conversation about improving the workflow and workflow
infrastructure, and we decided we really needed a new list for it.
Tracker-discuss was the obvious candidate, but that lists gets all of
the tickets and ticket traffic posted on the meta-tracker, and this
discussion doesn't need to be interrupted by those, nor will
our discussion be limited to topics concerning the tracker.

Thus this list.

All: Take a look at the list description, and let me know if you think
that covers it, and any tweaks you think we should make to that
mission statement.

First question: should the list be public/open subscription?  I don't see
any reason it should be closed, but I'm open to opinions :) Assuming
it is open subscription, I propose I make an announcement on the
python-committers, python-dev, tracker-discuss, and python-mentorship
mailing lists inviting interested parties to sign up.

--David

From bcannon at gmail.com  Wed Apr 16 19:08:24 2014
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 16 Apr 2014 13:08:24 -0400
Subject: [core-workflow] start up
In-Reply-To: <20140416162354.09AF1250029@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
Message-ID: <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>

I would add that the list is under the PSF CoC and infractions will result
in banishment. And I'm not sure if you mailed Nick and I the password for
the list -- on the train -- but don't forget that; done that myself. :)
I've subscribed Nick, Brett, and Jessica to this list to start out.

Jessica: Nick and Brett and I (as well as some other people) had
a conversation at the sprints about where it would be appropriate to
conduct the conversation about improving the workflow and workflow
infrastructure, and we decided we really needed a new list for it.
Tracker-discuss was the obvious candidate, but that lists gets all of
the tickets and ticket traffic posted on the meta-tracker, and this
discussion doesn't need to be interrupted by those, nor will
our discussion be limited to topics concerning the tracker.

Thus this list.

All: Take a look at the list description, and let me know if you think
that covers it, and any tweaks you think we should make to that
mission statement.

First question: should the list be public/open subscription?  I don't see
any reason it should be closed, but I'm open to opinions :) Assuming
it is open subscription, I propose I make an announcement on the
python-committers, python-dev, tracker-discuss, and python-mentorship
mailing lists inviting interested parties to sign up.

--David
_______________________________________________
core-workflow mailing list
core-workflow at python.org
https://mail.python.org/mailman/listinfo/core-workflow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140416/bbdf62f7/attachment.html>

From ncoghlan at gmail.com  Wed Apr 16 19:10:35 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Apr 2014 13:10:35 -0400
Subject: [core-workflow] start up
In-Reply-To: <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
Message-ID: <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>

On 16 Apr 2014 13:08, "Brett Cannon" <bcannon at gmail.com> wrote:
>
> I would add that the list is under the PSF CoC and infractions will
result in banishment.

Sustained infractions, anyway. Also handy to link to the CoC from the
footer.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140416/fbe24ee7/attachment.html>

From rdmurray at bitdance.com  Wed Apr 16 19:35:11 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 16 Apr 2014 13:35:11 -0400
Subject: [core-workflow] start up
In-Reply-To: <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
Message-ID: <20140416173511.E0927250D09@webabinitio.net>

On Wed, 16 Apr 2014 13:10:35 -0400, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 16 Apr 2014 13:08, "Brett Cannon" <bcannon at gmail.com> wrote:
> >
> > I would add that the list is under the PSF CoC and infractions will
> result in banishment.
> 
> Sustained infractions, anyway. Also handy to link to the CoC from the
> footer.

Done.

--David

From rdmurray at bitdance.com  Sat Apr 19 04:59:41 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 18 Apr 2014 22:59:41 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140416173511.E0927250D09@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
Message-ID: <20140419025942.141DF250029@webabinitio.net>

I had a fair amount of time to think during my drive home from PyCon.
I have some preliminary thoughts about ticket workflow and ways we
can improve it.  I'll try to write it up this weekend to act as a
conversation starter.

In the meantime, I'd like to put forth a small proposal with regards
to one specific thing in the current tracker interface.  Currently
for resolution we have:

    duplicate
    fixed
    not a bug
    later
    out of date
    postponed
    rejected
    remind
    wont fix
    works for me
    3rd party

I would like to collapse and reorder this list as follows:

    duplicate
    not a bug
    works for me
    fixed
    postponed
    won't fix
    3rd party

You may or may not recall that we used to have a resolution 'accepted',
where 'accepted' was "supposed" to be for enhancements that were
committed.  It tended to be an attractive nuisance, though, since people
would set it when they thought the bug *should* be fixed rather than when
an enhancement was committed.  (There is a sense in which it is indeed
valuable to be able to say that, but I'll suggest a way to deal with that
in my larger brain dump; it doesn't belong in the 'resolution' field :).

'rejected' isn't really an attractive nuisance, but it doesn't get applied
only to enhancements.  Sometimes it is applied to proposed "bug" fixes.
So, the distinction between "won't fix" and "rejected" is not clear,
and thus has little utility.  Now, we *could* go through and "fix" the
metadata if we actually wanted to use that distinction for something,
but I doubt that we do.  If you are analyzing tracker data, you can
always check if the issue was an enhancement or not.  So I propose that
we drop 'rejected' and just close rejected enhancements as "won't fix".
(After all, we often only half-jokingly say that enhancement requests are
"API bugs".)

For the other deletions, I think think it should be obvious that we
only need one resolution that says "maybe someday this will get
reopened", rather than three of them.

The ordering is currently mostly-alphabetical, I picked an ordering
that feels "logical" to me, but I'm not really attached to the ordering.

--David

From nad at acm.org  Sat Apr 19 06:22:45 2014
From: nad at acm.org (Ned Deily)
Date: Fri, 18 Apr 2014 21:22:45 -0700
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140419025942.141DF250029@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
Message-ID: <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>

On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray at bitdance.com> wrote:

> [...]

> For the other deletions, I think think it should be obvious that we
> only need one resolution that says "maybe someday this will get
> reopened", rather than three of them.

Presumably you mean collapsing "later" and "remind" into "postpone".  Fine with me.

That seems to leave "out of date" unaccounted for.  If we're in a collapsing mood, I guess that could be covered by "fixed". Further down the minimalist route, perhaps "works for me" could be collapsed into "not a bug" as well.  That distinction seems hazy enough to make it difficult to apply the two consistently.

While part of me likes the idea of having more fine-grained statuses as we do today, in practice it is difficult to make use of them so I'm OK with consolidation.

BTW, what about the fields for existing (open and closed) issues?  Would they get mapped to the new values?

--
  Ned Deily
  nad at acm.org -- []



From antoine at python.org  Sat Apr 19 12:02:02 2014
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 19 Apr 2014 12:02:02 +0200
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140419025942.141DF250029@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
Message-ID: <1397901722.2345.1.camel@fsol>

On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
> I would like to collapse and reorder this list as follows:
> 
>     duplicate
>     not a bug
>     works for me
>     fixed
>     postponed
>     won't fix
>     3rd party

Is "3rd party" a different thing from "not a bug". Often it's "not a
bug" because it's a bug somewhere else (perhaps not identified :-)).

Regardless, +1.

Regards

Antoine.



From ezio.melotti at gmail.com  Sat Apr 19 13:20:31 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 19 Apr 2014 14:20:31 +0300
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140419025942.141DF250029@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
Message-ID: <CACBhJdF14Oo_ucHQWPuge8bgS+DFmqnA3jrq-+GF8zi65aJJFw@mail.gmail.com>

Hi,

On Apr 19, 2014 5:59 AM, "R. David Murray" <rdmurray at bitdance.com> wrote:
>
> I had a fair amount of time to think during my drive home from PyCon.
> I have some preliminary thoughts about ticket workflow and ways we
> can improve it.  I'll try to write it up this weekend to act as a
> conversation starter.
>
> In the meantime, I'd like to put forth a small proposal with regards
> to one specific thing in the current tracker interface.  Currently
> for resolution we have:
>
>     duplicate
>     fixed
>     not a bug
>     later
>     out of date
>     postponed
>     rejected
>     remind
>     wont fix
>     works for me
>     3rd party
>
> I would like to collapse and reorder this list as follows:
>
>     duplicate
>     not a bug
>     works for me
>     fixed
>     postponed
>     won't fix
>     3rd party
>

IIUC this is what you are doing:

duplicate = duplicate
not a bug = not a bug + rejected
works for me = works for me (+ out of date?)
fixed = fixed
postponed = later + remind + postponed (+ out of date?)
won't fix = wont fix
3rd party = 3rd party

This seems a reasonable request to me.
I've been trying to simplify the interface of the tracker and remove
non-essential elements, and this would be a good step in that
direction.  The next step could be "merging" this with the "closed"
status so that you select the resolution once while you mark the issue
as closed (or possible pending).

> You may or may not recall that we used to have a resolution 'accepted',
> where 'accepted' was "supposed" to be for enhancements that were
> committed.  It tended to be an attractive nuisance, though, since people
> would set it when they thought the bug *should* be fixed rather than when
> an enhancement was committed.  (There is a sense in which it is indeed
> valuable to be able to say that, but I'll suggest a way to deal with that
> in my larger brain dump; it doesn't belong in the 'resolution' field :).
>
> 'rejected' isn't really an attractive nuisance, but it doesn't get applied
> only to enhancements.  Sometimes it is applied to proposed "bug" fixes.
> So, the distinction between "won't fix" and "rejected" is not clear,
> and thus has little utility.  Now, we *could* go through and "fix" the
> metadata if we actually wanted to use that distinction for something,
> but I doubt that we do.  If you are analyzing tracker data, you can
> always check if the issue was an enhancement or not.  So I propose that
> we drop 'rejected' and just close rejected enhancements as "won't fix".
> (After all, we often only half-jokingly say that enhancement requests are
> "API bugs".)
>
> For the other deletions, I think think it should be obvious that we
> only need one resolution that says "maybe someday this will get
> reopened", rather than three of them.
>

While doing these changes we should keep in mind what are all those
fields useful for.  I can think of two main use cases:
1) searching/filtering issues (both for finding specific issues or for
analyzing tracker data);
2) informing users about the current situation of the issue;

In general I don't think anyone needs such a fine-grained filtering
(have you ever looked for "postponed" issues or wanted to know how
many "later" issues there are?), and the rationale for closing the
issue could be detailed in the message, so I'm +1 on the change you
suggest.

> The ordering is currently mostly-alphabetical, I picked an ordering
> that feels "logical" to me, but I'm not really attached to the ordering.
>

Remember that there is also
https://wiki.python.org/moin/DesiredTrackerFeatures which contain
discussions and ideas about possible improvements to the interface.

Best Regards,
Ezio Melotti

> --David
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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

From ncoghlan at gmail.com  Sat Apr 19 15:43:51 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Apr 2014 09:43:51 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <1397901722.2345.1.camel@fsol>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
 <1397901722.2345.1.camel@fsol>
Message-ID: <CADiSq7ekjg_3V7iiBBkZU3_M=+1gj=yFZmb-T6PvM=+jGRR0dQ@mail.gmail.com>

On 19 Apr 2014 06:04, "Antoine Pitrou" <antoine at python.org> wrote:
>
> On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
> > I would like to collapse and reorder this list as follows:
> >
> >     duplicate
> >     not a bug
> >     works for me
> >     fixed
> >     postponed
> >     won't fix
> >     3rd party
>
> Is "3rd party" a different thing from "not a bug". Often it's "not a
> bug" because it's a bug somewhere else (perhaps not identified :-)).

That would be the resolution used for things like bugs in pip, or errors in
a patched distro version. Ideally it would require a URL that referenced
the bug in the other projects issue tracker, but that can go in a comment
easily enough.

Cheers,
Nick.

>
> Regardless, +1.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140419/588cc11b/attachment.html>

From ncoghlan at gmail.com  Sat Apr 19 15:49:30 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Apr 2014 09:49:30 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
 <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>
Message-ID: <CADiSq7f0eXHpZH2y7mgOog-8XAAJC4VHv2vwRKMuE_nLayuZPw@mail.gmail.com>

On 19 Apr 2014 00:47, "Ned Deily" <nad at acm.org> wrote:
>
> On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray at bitdance.com> wrote:
>
> > [...]
>
> > For the other deletions, I think think it should be obvious that we
> > only need one resolution that says "maybe someday this will get
> > reopened", rather than three of them.
>
> Presumably you mean collapsing "later" and "remind" into "postpone".
 Fine with me.
>
> That seems to leave "out of date" unaccounted for.  If we're in a
collapsing mood, I guess that could be covered by "fixed".

+1

>Further down the minimalist route, perhaps "works for me" could be
collapsed into "not a bug" as well.  That distinction seems hazy enough to
make it difficult to apply the two consistently.

To my mind, "works for me" is closer to "can't fix". The closest resolution
we use in Red Hat Bugzilla would likely be "INSUFFICIENT DATA" - the bug
report is too incomplete for us to reproduce the error or otherwise
identify the actual problem (if any).

Cheers,
Nick.

>
> While part of me likes the idea of having more fine-grained statuses as
we do today, in practice it is difficult to make use of them so I'm OK with
consolidation.
>
> BTW, what about the fields for existing (open and closed) issues?  Would
they get mapped to the new values?
>
> --
>   Ned Deily
>   nad at acm.org -- []
>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140419/4e2827ba/attachment.html>

From rdmurray at bitdance.com  Sat Apr 19 16:27:51 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 10:27:51 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
 <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>
Message-ID: <20140419142752.5AFD8250D09@webabinitio.net>

On Fri, 18 Apr 2014 21:22:45 -0700, Ned Deily <nad at acm.org> wrote:
> On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray at bitdance.com> wrote:
> 
> > [...]
> 
> > For the other deletions, I think think it should be obvious that we
> > only need one resolution that says "maybe someday this will get
> > reopened", rather than three of them.
> 
> Presumably you mean collapsing "later" and "remind" into "postpone".  Fine with me.
> 
> That seems to leave "out of date" unaccounted for.  If we're in a

Yes, you are right, I forgot that one.  I suppose that one should be kept,
although I suspect it gets used only infrequently.

> collapsing mood, I guess that could be covered by "fixed". Further
> down the minimalist route, perhaps "works for me" could be collapsed
> into "not a bug" as well.  That distinction seems hazy enough to make
> it difficult to apply the two consistently.

I'd be fine with eliminating "works for me" in favor of "not a bug".
Especially since "works for me" is really ambiguous when faced with
possible cross-platform issues.

> While part of me likes the idea of having more fine-grained statuses
> as we do today, in practice it is difficult to make use of them so I'm
> OK with consolidation.

As far as I can see the current use case for resolution is to inform
viewers of the bug, and most importantly the original reporter,
what the "disposition" of the bug was.  For that purpose "works for me"
and "not a bug" are essentially equivalent.

> BTW, what about the fields for existing (open and closed) issues?
> Would they get mapped to the new values?

They will continue to show the resolution they were closed with.  We
*could* go back and change the resolution of closed issues, but unless
we are using resolution in a way that such a cleanup would actually
benefit, I don't think it is worth spending time on.

--David

PS: Thanks for updating the devguide, but the way, I'd forgotten
about that.

From ezio.melotti at gmail.com  Sat Apr 19 16:42:42 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 19 Apr 2014 17:42:42 +0300
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140419025942.141DF250029@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
Message-ID: <CACBhJdH8Lt+LJWs+V3YTayCz7dUeiV3rFV4ykNDHzaEyQsnxuA@mail.gmail.com>

Just for the record, I checked how many issues use each different resolution:

13129 fixed
3041 not a bug
1937 duplicate
1626 wont fix
1545 rejected
1423 out of date
726 works for me
108 later
60 postponed
16 remind
9 3rd party

(Note that 3rd party has been added recently, hence the low number of
issues that use it)

From rdmurray at bitdance.com  Sat Apr 19 16:53:25 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 10:53:25 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <1397901722.2345.1.camel@fsol>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net> <1397901722.2345.1.camel@fsol>
Message-ID: <20140419145326.55A50250D09@webabinitio.net>

On Sat, 19 Apr 2014 12:02:02 +0200, Antoine Pitrou <antoine at python.org> wrote:
> On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
> > I would like to collapse and reorder this list as follows:
> > 
> >     duplicate
> >     not a bug
> >     works for me
> >     fixed
> >     postponed
> >     won't fix
> >     3rd party
> 
> Is "3rd party" a different thing from "not a bug". Often it's "not a
> bug" because it's a bug somewhere else (perhaps not identified :-)).
> 
> Regardless, +1.

Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug"
to the person who reported the issue, so I think 3rd party is worthwhile.
Also, the number of 3rd party issues that we end up responding to could
be a useful metric to have.

That said, I won't cry if we decide to drop it :)

--David

From antoine at python.org  Sat Apr 19 16:58:47 2014
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 19 Apr 2014 16:58:47 +0200
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <20140419145326.55A50250D09@webabinitio.net>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net> <1397901722.2345.1.camel@fsol>
 <20140419145326.55A50250D09@webabinitio.net>
Message-ID: <1397919527.2345.13.camel@fsol>

On sam., 2014-04-19 at 10:53 -0400, R. David Murray wrote:
> On Sat, 19 Apr 2014 12:02:02 +0200, Antoine Pitrou <antoine at python.org> wrote:
> > On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
> > > I would like to collapse and reorder this list as follows:
> > > 
> > >     duplicate
> > >     not a bug
> > >     works for me
> > >     fixed
> > >     postponed
> > >     won't fix
> > >     3rd party
> > 
> > Is "3rd party" a different thing from "not a bug". Often it's "not a
> > bug" because it's a bug somewhere else (perhaps not identified :-)).
> > 
> > Regardless, +1.
> 
> Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug"
> to the person who reported the issue, so I think 3rd party is worthwhile.
> Also, the number of 3rd party issues that we end up responding to could
> be a useful metric to have.

That's not a problem to me.
(OTOH, it "3rd party" was spelled "third party", I think I would like it
better :-) for some reason, the leading digit looks wrong :-D)

Regards

Antoine.



From rdmurray at bitdance.com  Sat Apr 19 17:04:58 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 11:04:58 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <CACBhJdF14Oo_ucHQWPuge8bgS+DFmqnA3jrq-+GF8zi65aJJFw@mail.gmail.com>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
 <CACBhJdF14Oo_ucHQWPuge8bgS+DFmqnA3jrq-+GF8zi65aJJFw@mail.gmail.com>
Message-ID: <20140419150459.48FB4250D09@webabinitio.net>

On Sat, 19 Apr 2014 14:20:31 +0300, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> IIUC this is what you are doing:
> 
> duplicate = duplicate
> not a bug = not a bug + rejected
> works for me = works for me (+ out of date?)
> fixed = fixed
> postponed = later + remind + postponed (+ out of date?)
> won't fix = wont fix
> 3rd party = 3rd party
> 
> This seems a reasonable request to me.

Yes.  It seems despite what I said in a previous message about keeping
it that people are OK with dropping "out of date" in favor of "fixed",
which is also fine with me.

> I've been trying to simplify the interface of the tracker and remove
> non-essential elements, and this would be a good step in that
> direction.  The next step could be "merging" this with the "closed"
> status so that you select the resolution once while you mark the issue
> as closed (or possible pending).

Yeah, simplifying that is what my proposal is about.  I need to finish
writing it ;)

> While doing these changes we should keep in mind what are all those
> fields useful for.  I can think of two main use cases:

Exactly.  The only fields we should have are those that are *useful*:
things that turn into something operationally.  Not just busy work :)

> 1) searching/filtering issues (both for finding specific issues or for
> analyzing tracker data);
> 2) informing users about the current situation of the issue;

Right.

> In general I don't think anyone needs such a fine-grained filtering
> (have you ever looked for "postponed" issues or wanted to know how
> many "later" issues there are?), and the rationale for closing the
> issue could be detailed in the message, so I'm +1 on the change you
> suggest.
> 
> > The ordering is currently mostly-alphabetical, I picked an ordering
> > that feels "logical" to me, but I'm not really attached to the ordering.
> >
> 
> Remember that there is also
> https://wiki.python.org/moin/DesiredTrackerFeatures which contain
> discussions and ideas about possible improvements to the interface.

Good point, I need to review that before finishing my for-discussion
proposal.

--David

From rdmurray at bitdance.com  Sat Apr 19 17:10:21 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 11:10:21 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <CADiSq7ekjg_3V7iiBBkZU3_M=+1gj=yFZmb-T6PvM=+jGRR0dQ@mail.gmail.com>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net> <1397901722.2345.1.camel@fsol>
 <CADiSq7ekjg_3V7iiBBkZU3_M=+1gj=yFZmb-T6PvM=+jGRR0dQ@mail.gmail.com>
Message-ID: <20140419151022.2B526250D09@webabinitio.net>

On Sat, 19 Apr 2014 09:43:51 -0400, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 19 Apr 2014 06:04, "Antoine Pitrou" <antoine at python.org> wrote:
> >
> > On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
> > > I would like to collapse and reorder this list as follows:
> > >
> > >     duplicate
> > >     not a bug
> > >     works for me
> > >     fixed
> > >     postponed
> > >     won't fix
> > >     3rd party
> >
> > Is "3rd party" a different thing from "not a bug". Often it's "not a
> > bug" because it's a bug somewhere else (perhaps not identified :-)).
> 
> That would be the resolution used for things like bugs in pip, or errors in
> a patched distro version. Ideally it would require a URL that referenced
> the bug in the other projects issue tracker, but that can go in a comment
> easily enough.

At some point I think it would be great to add tooling to support that (a
list of 3rd party bug tracker URLs that can autocomplete like nosy does).
For now just putting it in the comment works fine.

--David

From rdmurray at bitdance.com  Sat Apr 19 17:15:18 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 11:15:18 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <CADiSq7f0eXHpZH2y7mgOog-8XAAJC4VHv2vwRKMuE_nLayuZPw@mail.gmail.com>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net>
 <75058D60-ADEE-458B-B5A7-9B5B96F60BDF@acm.org>
 <CADiSq7f0eXHpZH2y7mgOog-8XAAJC4VHv2vwRKMuE_nLayuZPw@mail.gmail.com>
Message-ID: <20140419151519.0AA05250D09@webabinitio.net>

On Sat, 19 Apr 2014 09:49:30 -0400, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 19 Apr 2014 00:47, "Ned Deily" <nad at acm.org> wrote:
> >Further down the minimalist route, perhaps "works for me" could be
> >collapsed into "not a bug" as well.  That distinction seems hazy
> >enough to make it difficult to apply the two consistently.
> 
> To my mind, "works for me" is closer to "can't fix". The closest resolution
> we use in Red Hat Bugzilla would likely be "INSUFFICIENT DATA" - the bug
> report is too incomplete for us to reproduce the error or otherwise
> identify the actual problem (if any).

Yeah, I thought about that, but I didn't want to suggest *adding*
resolutions at this point.  We may want something like 'insufficient
data' later, though.  Or I suppose we could rename "works for me" to be
that, if other people think it is accurate enough.

--David

From rdmurray at bitdance.com  Sat Apr 19 17:29:35 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Apr 2014 11:29:35 -0400
Subject: [core-workflow] tracker 'resolution'
In-Reply-To: <1397919527.2345.13.camel@fsol>
References: <20140416162354.09AF1250029@webabinitio.net>
 <CAP1=2W6JC5sFb+k3YP49MP9yPz1w5QFq+A-2oVczmQAvF6mLUg@mail.gmail.com>
 <CADiSq7fuAANN8+bcLVOFAxGfvL0eLfbR8hpvbS8NhOpu3PY8Yw@mail.gmail.com>
 <20140416173511.E0927250D09@webabinitio.net>
 <20140419025942.141DF250029@webabinitio.net> <1397901722.2345.1.camel@fsol>
 <20140419145326.55A50250D09@webabinitio.net> <1397919527.2345.13.camel@fsol>
Message-ID: <20140419152936.3ABE6250D09@webabinitio.net>

On Sat, 19 Apr 2014 16:58:47 +0200, Antoine Pitrou <antoine at python.org> wrote:
> On sam., 2014-04-19 at 10:53 -0400, R. David Murray wrote:
> > Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug"
> > to the person who reported the issue, so I think 3rd party is worthwhile.
> > Also, the number of 3rd party issues that we end up responding to could
> > be a useful metric to have.
> 
> That's not a problem to me.
> (OTOH, it "3rd party" was spelled "third party", I think I would like it
> better :-) for some reason, the leading digit looks wrong :-D)

Good idea.  I just copied the original 'versions' text without thinking
about it.

Consider it done (because it is).  If anyone objects, it is easy enough
to change it back :)

--David

From rdmurray at bitdance.com  Mon Apr 21 18:04:33 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Apr 2014 12:04:33 -0400
Subject: [core-workflow] Tracker workflow proposal
Message-ID: <20140421160435.35094250CAE@webabinitio.net>


OK, wall of text time.  Sorry about this :)



CPython Tracker Workflow
========================



Framing the Discussion
----------------------

This document is intended as a starting point for discussion.  I won't
be offended if we throw it out and start over.  Even if you like the
general idea, I'm sure I've made some mistakes and have not managed to
correctly think through all the issues.

I also realize that what I'm talking about here is a non-trivial amount
of work.  But if we want to have a 'best in class' workflow infrastructure
(and as Nick has said, we *need* one), we are looking at a non-trivial
amount of work no mater how we achieve it.  Discussions of alternate
ways to achieve the same effect are welcome, but I'm betting that in
the long run we really do want to tailor this stuff to *our* workflow,
rather than try to shoehorn ourselves into someone else's workflow.
Which doesn't mean we shouldn't leverage existing tools (like Roundup :),
but does mean there's a lot of tailoring to do to get this right.

That said, feedback from people who have actual experience with tools
that support similar workflows is valuable.  The ones I've worked with
were not like what I'm trying to create here, they were either like
what we have now (bug report systems with little to no workflow support)
or pure peer-review systems (that is, there were no non-committers).

I'm volunteering to be the coordinator for the work, and I'm also
volunteering to do as much of it as necessary.  That is, I'm planning
to make this the focus of most of the "python time" I have available.

I think that there is a way to implement this workflow or whatever
workflow we decide on as a "new interface" while keeping the existing
interface available, allowing us to test and refine (like, maybe do some
usability testing? :).  Roundup has a way to dynamically specify which
page template is used to render a particular page type, and I think we
can leverage that to have two parallel UIs.  I could be wrong, though,
in which case we'd need to set up a test tracker instead, which I can do.
(Assuming it does work, there might need to be a bit of glue code to
keep things in sync.  And there would need to be some changes in the
data values available in the current UI, but I don't think that would
be a bad idea anyway.)

The scope of this discussion is the workflow for an "issue", which
currently means an entry created by someone in the bug tracker at
bugs.python.org, and goes from the creation of the issue to the resolution
of the issue, which can but does not necessarily include committing
something.  I won't be discussing the tooling for Zuul-like patch gating
at this stage, I'll just assume we can figure out how to implement that.

It would also be possible to build a patch gating system without
initially integrating it with our other tools, and if we decide that's
more important than the tracker workflow at this stage, we should switch
our conversation to what that would look like.  Or perhaps we can work
on the two in parallel.

My own feeling is that in order to get maximum benefit out of patch
gating, we need more clarity and utility in our *tracker* workflow first,
but I do realize that how long it currently takes to commit a patch is
a significant pain point, and it might be better to address that first.



Goals
-----

In suggesting improvements to the existing workflow support, I'm
starting from the fundamental idea that anything we do in the issue
tracker and/or patch gating system should have either *operational*
implications or *important* informational implications.  The former
should be more heavily weighted than the latter, in my opinion.

What I mean by this is that there should be no "busy work" setting
of attributes in our workflow: when you change the state of an issue,
it should mean that something new is *going* to happen to that issue.
Any purely informational attribute setting should be in support of that
new action, and wherever possible that information should *mean* something
to some part of our tooling, not *just* to the humans looking at the issue.

In general I want there to be as few clicks as practical involved in
updating an issue.  However, I'm not addressing the actual UI design here
(although I have ideas); I assume we are going to iterate on it for a
bit until we have something we really like.

NB: This proposal includes a number of ideas from the "desired tracker
features" (http://wiki.python.org/moin/DesiredTrackerFeatures), but
by no means all of them.  Some of the others are worth implementing,
but in this document I'm focusing on primary workflow, which I think
should happen first.



Roles
-----


Conceptual Roles
~~~~~~~~~~~~~~~~

In thinking about our workflow, I identify the following roles:

    original reporter
    commenter
    triager
    patch-producer
    reviewer
    core reviewer
    committer

These are in the order that the role is involved in the issue (roughly;
variations are possible depending on the issue), and obviously a single
person can take on multiple roles during the lifetime of a patch.

I originally thought this list would have operational implications,
but it turned out to be only an aid in thinking about the problem.
I'm leaving it in here for exactly that purpose...it helps when thinking
about the states and state transitions.

I'd also like to add something that we currently only have informally,
but which has been requested as a feature more than once: at every stage,
I'd like there to be the possibility of there being a 'responsible party'.
This is sort of like 'assigned to', except that it could be anyone with
a tracker account, and the assignment would have a limited lifetime:
either until the issue's state changes, or until the issue has been
without update for some number of days (off the cuff I'd suggest 14,
but it might also vary by state depending on what states it actually
got used in).

The idea behind this is that we have eager contributors who either
wind up stepping on each other's toes, or rush to create and submit a
patch before someone else does, and as a consequence of rushing, do not
produce as good a patch as they are capable of, which actually slows
down the issue resolution.  The ability to "take" a task and know it is
"yours" is an important part of the new contributor process, and having a
"responsible party" field would support that.


Tracker Roles
~~~~~~~~~~~~~

The tracker roles important to the workflow are:

    User
    Triager ('Developer')
    Committer

Although the tracker calls the Triager role 'Developer', I'm going
to refer to it as Triager throughout this document, for clarity as to
its intent.

The tracker does not currently have a role equivalent to 'committer', but
we may not need to add one explicitly, since the account of a committer
is marked as such.

The important thing to understand about these roles in the context of
this document is that anything a user can do, a triager or committer
can do, and anything a triager can do, a committer can do.



Information Fields
------------------

An issue has an issue number and a title, and those wouldn't change.
It also has a state, which is the subject of the second half of this
document, and would likely be a new field in order to be able
to have both UIs available (this field is where the glue code
would be needed).

Beyond those fields, I suggest several changes to the issue metadata;
I will cover each one separately.


Versions
~~~~~~~~

Currently our versions field does double duty: we set it to the versions
we want to fix the bug in, and then deselect versions as we fix them.
However, I noticed when doing the "What's New" document that this
makes things really confusing if you *do* look at the ticket later.
You can't tell which versions got the fix without reading through the
entire issue.  So I'd like to split this into two fields:

    should be fixed in: [list of versions]
    has been fixed in: [list of versions]

I'd also like patch set links to be displayed next to the versions for
'has been fixed'.  When a commit references an issue, it should appear
next to the appropriate version, but it should *not* automatically
change the version state to fixed.  That should require separate action,
since we sometimes apply patches that are relevant to the issue but
do not fix it.  When an issue is transitioned to closed, there should
be an easy way to say "mark all versions with changesets as fixed".
It would probably be appropriate for that to be the default.

These fields have direct operational meaning: they indicate a task
to be performed or signal the completion of a task.


Type
~~~~
    documentation
    python bug
    interpreter crash
    security
    enhancement request

I add 'documentation' here based on PyCon feedback from Jessica McKeller
and Selena Deckelmann.  None of the existing types makes sense to a
beginner for a documentation bug, and the resulting confusion can lead
someone to abandon the effort to contribute.  It also has operational
implications (see below).

I rename 'behavior' to 'python bug' for a similar reason, but I don't
have any usability data to back that feeling, so I'm not strongly
advocating that change.

I rename 'crash' to 'interpreter crash' in an attempt to reduce the
chances that someone will report a python traceback as a crash, something
that otherwise happens very regularly.  I'm sure we'll never completely
eliminate those.

I drop 'compiler error', 'resource usage' and 'performance'.  All of
these are bugs in the minds of the reporters, and classifying them
separately in the 'type' field does not, as far as I can see, lead to
any operational difference in the way the issue is treated.

What I mean by that: most bugs are either 'documentation' or 'python bug'
or 'enhancement request'.  Differentiating these is important, as doc
bugs are handled very differently from python bugs (documentation fixes
do not get NEWS entries, for example), and bug vs enhancement determines
which versions we fix things in.  'compiler error', 'resource usage', and
'performance', on the other hand, are all handled with the same workflow
that applies to bugs.  You might think that there is a difference for
resource usage and performance, in that we don't in general backport
those fixes.  The key there, though, is "in general".  The decision as to
which versions to apply the fix is made based on the magnitude of the bug,
and there really are only two cases: we mostly don't backport, as is the
case for enhancements, but we sometimes do backport, just like we would
a bug fix.  The same applies in reverse to compile bugs: we mostly fix
those in all versions, but we don't always.  So the only *operational*
effect of having these as distinct types would be to confuse things,
since we couldn't tell from the type whether or not this was something
that should be applied to all versions or only default.  Instead we
should set (or, more likely, triage) them as either 'python bug' or
'enhancement', which have the correct operational implications.

There *is* an operational reason for having security and interpreter
crash as separate types.  In both of these cases the versions we fix
it in is always the same (all active for crashers, all active + all
security-only for security bugs), and the issue priority should default
to either high or release blocker.  In addition, security bugs should
be automatically reported to the PSRT, and arguably the report should
be be hidden from all but the PSRT and the original reporter.


Priority
~~~~~~~~

    low
    normal
    high
    deferred blocker
    release blocker

The only change here is to eliminate 'critical'.  I'm not wedded to
that, but if we have both 'critical' and 'high' priorities, 'high'
ends up getting treated as pretty much equivalent to either 'normal' or
'critical', depending on the person.  I would argue that anything that
is severe enough to be marked 'critical' should in fact be a release
blocker, and anything that is not a release blocker is effectively only
'high' priority.

The priority is currently operational only in that one can sort issues by
priority.  I propose that we make them much more operational, by posting
a count and/or list of the bugs with more than normal priority somewhere
public on a regular basis, such as python-dev, python-committers,
and/or #python-dev.  (Well, definitely #python-dev.)

I'd like to see us strive keep those queues clear, so that promoting a
bug to high or release blocker means it *will* get acted on reasonably
promptly.  (This raises the issue of what to do about bugs we currently
mark as "release blocker" as a *reminder* to the release manager.  I don't
have a proposal for that at the current time, as release management is
out of scope for this document, but we'll need an answer if we are going
to implement this.)


Component
~~~~~~~~~

I propose that we completely change the nature of this item.  I think we
should make it a text field that is filled in by autocomplete like the
nosy field can be, and that the value be any of the components listed
in the experts file.  This would further respect how the experts have
listed themselves in that file by autonosying those that are willing
for that to happen.  The field should still be a multilink (that is,
can contain more than one value).

This change would mean that it would be possible to search for issues
based on module, which is an often-requested feature.


Patch Status
~~~~~~~~~~~~

This is a new set of fields that records information about the patch:

    unit test               
    fix
    documentation changes
    news entry
    what's new entry
    commit message

For each of these, the value could be 'needs work', 'complete', or
'not applicable'.  For issues of type 'documentation', all lines
except 'documentation changes' and 'commit message' would be set to
NA by default, otherwise they will be set to 'needs work' initially,
except for "what's new", which will be set to NA for anything except
type enhancement.

Note that the inclusion of 'news entry' and 'commit message' assume two
things: that we retool the NEWS file so that NEWS entries can be added
automatically without conflicts, and that we change our patch workflow
to use mercurial's capability to accept 'hg export' patches and/or some
other sort of pull request.  This part is one place we get into
non-roundup territory, so that may be a phase two addition.

Mercurial's 'evolve' feature, which we saw demoed at PyCon and which I
understand is currently available as a plugin, makes this capability much
more useful.  When the non-core committer syncs the master repository
after their patch has been committed, the right thing happens to the
history in their repository to make their local commit disappear in
favor of the commit made to master.  The contributor will also be able
to essentially *edit* the patch in their local repository based on the
review feedback, without ending up with a chain of commits in their
local repo that they have to deal with.  Evolve should also facilitate
DVCS-based collaboration between core and non-core developers, as well as
between non-core developers.  (I'm assuming all this works with exported
changesets, since in the demo they talked about starting with a patch
received via email, which is their normal workflow.  But we should double
check this.)

These fields allow us to represent all the parts that a patch must have
to be complete, and they act as a checklist for making sure the parts
are all there.  This is similar in intent to patchcheck, but since which
pieces are needed is ultimately determined by a human, it is more accurate
than that part of patchcheck and therefore more useful.


Stage
~~~~~

This goes away, subsumed into state.


Status
~~~~~~

This either holds the state information, or goes away in favor of a new
'state' field.


Keywords
~~~~~~~~

    buildbot
    easy
    stuck

buildbot and easy are the only two existing, non-redundant tags that I can
see a way to make operational.

'easy' of course has to be set manually.  The system for listing easy
issues should list the issues only when there is an action that someone
could take on the issue (clarify issue, write patch, review patch).
(NB: it might be possible to come up with a better name for this tag.)

For buildbot, those issues should be displayed in a report or dashboard,
and we should try to keep this queue empty.  This becomes even more
important when we have a patch gating system online.

All of the other values are informational-only, and in some cases
redundant.  If we want informational keywords, IMO we should do a full
user-accessible tagging system.  That would be a separate proposal,
though.

Note: I claim the regression tags are redundant because I think
regression issues should be release blockers.  (They are also ambiguous:
is '3.3regression' a bug in 3.3 that is a regression relative to 3.2,
or a 3.3.x bug relative to 3.3.x-1, or a 3.4 bug that is a regression
relative to 3.3?  Better to just explain exactly what is going on in
the issue comments, IMO.)

The purpose of the 'stuck' tag is to label issues that we agree are
real issues that we don't want to close as "won't fix", but that we
can't for one reason or another currently move forward.  Operationally,
stuck issues are either not displayed in work queues (see below) or are
displayed at the end of the queue.

I think the keywords should be settable by anyone, if they aren't already.



Issue States and State Transitions
----------------------------------

Here are the states that I think an issue can be in:

    new
    needs information
    needs decision
    needs decision from committer
    needs patch
    needs review
    needs patch update
    needs commit review
    closed/fixed
    closed/wont fix
    closed/duplicate
    closed/insufficient information
    closed/postponed
    closed/not a bug
    closed/third party

I discuss each of these, and the possible state transitions, below.

All legal state transitions should be displayed in a particular
area in the UI, and each transition should be a single radio button.
Which possible transitions will be displayed will depend on the user's
roundup role, and occasionally other state in the issue.

The default transition is "no change".

Note that the names of these states are, unlike most of the other names
I've used so far, not the ones I necessarily expect us to use in the UI.
They are descriptive of the state from the workflow POV, not necessarily
the labels that should be used for the state *transitions*.


New
~~~

The issue has been created by the original reporter.  The information
collected at this stage should be as simple as possible while gathering
the information we need.  I propose, based on conversations at PyCon
with people who work with new users, that the only information we *need*
is the title and first comment.  The rest would ideally be hidden/revealed
via javascript, with a per-user or browser-sticky setting that defaults to
'collapsed' for new users.

The 'advanced' section would allow the setting of type, component,
and nosy.

One could argue that it might be useful to collect 'found in version'
and perhaps other information such as os/version, but in my own use of
trackers I find that this is more often confusing than it is helpful,
and generally more detailed questions about the user's environment are
required in any case, making the up front collection attempt of dubious
utility.

A new issue can transition to:

    needs information                   user
    needs decision                      user
    needs patch                         triage
    needs decision from committer       triage
    closed                              triage, original reporter
    needs review                        triage, if there is already a patch
    needs commit review                 committer, if there is already a patch

That is, any user can indicate that more information is needed or
request that triage decide whether to accept or reject the issue,
but only triage can accept the issue as one that should be worked on
(needs patch), or close it, or request a committer to make that decision.

Operationally, new bugs get sent to the 'new bugs' list, and appear on the
weekly report in the new bugs section.  We also have 'new bugs without
response' in the weekly report.

The list of bugs in this state constitute a "work queue", and should be
available as a standard search query and/or as a dashboard feature.
Triagers are primarily responsible for draining this queue, but anyone
can help.


needs information
~~~~~~~~~~~~~~~~~

We are waiting for more information from the original reporter, or
from anyone else who manages to reproduce the problem.  If there is no
additional activity for some period of time (one month?)  the issue is
automatically moved to "closed/insufficient information".  A report
of autoclosed issues will be sent to appropriate places (python-dev?
new-bugs-announce?  Anyone with triage privileges?  Accessible from the
dashboard UI?).

The possible transitions are:

    needs decision                      user
    needs patch                         triage
    needs decision from committer       triage
    closed                              triage, original reporter, autoclose
    needs review                        triage, if there is already a patch
    needs commit review                 committer, if there is already a patch

Bugs in this state are *not* a work queue.


needs decision
~~~~~~~~~~~~~~

A user has expressed their opinion about what should be done with the
bug, and confirmation is needed from triage.  Note that an experienced
user can submit a bug and immediately move it to 'needs decision'.
There is nothing wrong with that, but it isn't necessary, since triage
will review bugs in new status just as soon (or sooner) than they will
review bugs in 'needs decision' status.

The possible transitions are:

    needs information                   user
    needs patch                         triage
    needs decision from committer       triage
    closed                              triage, original reporter
    needs review                        triage, if there is already a patch
    needs commit review                 committer, if there is already a patch

This is a work queue and it is triage's responsibility to drain it.
We should strive to keep this queue empty.  Issues where we can't
make a decision should marked stuck.


needs patch
~~~~~~~~~~~

The issue has been accepted as something we would like to fix.  Now
a patch implementing the change is needed.

The possible transitions are:

    needs review                        user
    needs information                   user
    needs decision                      user
    needs decision from committer       triage
    needs commit review                 triage
    closed                              triage, original reporter

This is a work queue, and it is something that everyone can help with.
It is the responsibility of the *community* to drain this queue, and
triager's or committers who write patches are doing so as part of the
general community, not in their specific empowered roles.

This is the primary place where someone might want to set themselves
as 'responsible party'.


needs review
~~~~~~~~~~~~

There is a patch, and it is ready to be reviewed.

The possible transitions are:

    needs information                   user
    needs decision                      user
    needs patch update                  user
    needs commit review                 triage
    needs decision from committer       triage
    closed                              triage, original reporter

An issue cannot transition to commit review if any of the patch status
items is set to 'needs work'.  Setting these can be done by any user.

It is always possible to upload a patch, regardless of state.  It is
always possible to adjust the patch checkboxes regardless of state.
Anyone can do these things.  So, a patch can get all the way to being
*ready* for commit review without getting beyond 'needs decision' state
(that is, without a triage person taking action), but it cannot get into
a commit review state without triage getting involved.  The theory behind
this is that patch work is not *blocked* by triage/committer non-action,
but by the same token a patch can't get into the commit review queue
without one of those two actively deciding it should be.

Like patch generation, this queue is also a community work queue.


needs patch update
~~~~~~~~~~~~~~~~~~

The patch isn't perfect yet, but has had at least one review.

It might be nice for the reviewer to be able to easily restore the
'responsible party' to point to the patch submitter when moving the
issue to this state, or perhaps even for that to happen automatically.

The possible transitions are:

    needs information                   user
    needs decision                      user
    needs review                        user
    needs commit review                 triage
    needs decision from committer       triage
    closed                              triage, original reporter

This is a community work queue.  It is distinct from "needs patch" so
that contributors who want to find a new problem to work on can look at
the 'needs patch' queue.


needs decision from committer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A question has come up that triage doesn't feel qualified to make the
call on.  I envision this mostly as a training mechanism for triage:
the committer who responds should explain *why* they make the decision
they do.  A triager who continues to reach for this button instead of
starting to make the calls themselves isn't a good candidate for further
responsibility.

Note that if committers are already nosy on an issue, there is normally
little reason to use this state, but it does move the issue into a queue
the committers are directly responsible for, so it can occasionally
be appropriate.

There is another use for this state: asking for a decision from the
maintainer of the module when there is an active maintainer.

The possible transitions are:

    needs information                   user
    needs review                        user
    needs patch update                  user, if there is a patch
    needs patch                         triage
    needs commit review                 triage
    closed                              triage, original reporter

This is a committer work queue.  Note that the issue can be transitioned
out of 'needs decision from committer' by anyone, so that if someone
with more experience comes along it doesn't have to stay in the committer
work queue if that isn't in fact necessary.


needs commit review
~~~~~~~~~~~~~~~~~~~

Triage agrees that the patch is ready to be committed.  This issue now
appears in a search/dashboard display for committers.  Ideally this
queue should be kept close to empty, but in reality it probably won't
be until we've gotten the bug list reduced and more committers online.

This state represents the transition to the patch gating system.  Until an
automated system is on-line, it would be the current manual system, and
patches could easily sit in this state for a while.  Once we've figured
out the automated patch gating system, either the issue transitions
to that system until it is committed, at which point the state in the
tracker transitions to closed/fixed, or we will be adding additional
states and controls to roundup to implement control flow between the
tracker and the gating system.

The possible transitions are:

    needs information                   user
    needs decision                      user
    needs patch update                  user
    needs decision from committer       triage
    closed                              triage, original reporter

If any of the patch status checkboxes are changed to 'needs work', the
'needs patch update' next-state should automatically be checked.

This is a committer work queue.


Closed
~~~~~~

An issue can make a transition to any of the closed states from any other
state (even fixed...there are times an issue is 'fixed' by another issue,
and so an issue can be closed as fixed even without a patch having been
committed).  You can also view the state as "closed-with-reason", with
the reason being the 'resolution' as currently managed by the tracker.
However, I think the UI for this should indicate both the close and
the reason with the same "gesture", instead of having to manipulate two
different dropdowns the way we do now.  (And it's currently two only if
you ignore stage.)

Triage or higher role is required to close an issue, except that the
original reporter can also close an issue (as they can now).

A closed issue can transition to:

    needs decision                      user
    needs information                   triage
    needs patch                         triage
    needs decision from committer       triage
    needs review                        triage, if there is already a patch
    needs commit review                 committer, if there is already a patch

I'm not sure if allowing any user to move a closed issue to 'needs
decision' is a good idea or not; currently closed issues can only be
opened by the original reporter or triage.  But that has worked fine
for the most part, and the overhead of dealing with the people who have
abused it hasn't been much higher than those people generate anyway.
I'm sure those folks will be able to find some other part of this
design to abuse if we don't allow 'needs decision' here.


Dashboard
---------

The dashboard would be a new feature, a new landing page and linked from
the left hand menu bar.  It would list the first N (adjustable) items in
each queue relevant to the user for which they are the responsible party,
followed by those on which the user is nosy, followed by those on which
they are not nosy.

A general user would see the 'new', 'needs patch', 'needs patch update',
and, 'needs review' queues.

A triager would see, above the preceding, the 'needs decision' queue.

A committer would see, above the preceding, the 'needs decision from
committer' and 'needs commit review' queues.

In all queues, issues would be sorted in priority order followed by most
recent activity, with color coding for the priority.  'stuck' issues
would appear last, and there should be something to visually differentiate
issues on which the user is responsible, just nosy, or not nosy.

As with everything else, this is of course subject to discussion.
It would also be lovely if the user could configure their dashboard,
but that would probably fall into the category of advanced features we
come back to later.



Big Picture
-----------

My goal here is to facilitate the involvement of the wider community
in our workflow as much as possible.  The structure above is designed
to allow the community to do as much work as possible, and the "trusted
individuals" to act as gatekeepers to insure quality.  It is theoretically
possible for a patch to get all the way to 'needs commit review' without
any more higher level involvement than a triage person moving the issue
to 'patch needed'.  Of course in reality much more involvement from core
will be needed, since we need to transfer knowledge to the community,
and especially the newcomers, about our standards and procedures,
Not to mention the code.  And committers are going to *want* to do
general commentary and triage level activities on issues anyway.  But,
for those committers who have less time, I'd like to think that this
system would allow them to focus their time on just the stuff only they
can do, and thus perhaps draw more contributions from some of our less
active or currently-inactive committers.

The key to this is that instead of issues getting lost, core can watch
certain key queues: 'needs decision', 'needs committer decision', and
'needs commit review'.  When issues get to those stages, the people with
the experience to do something know that it is *their* responsibility to
do it: the issues are to a point where the general community can't help
without core input.  If we can keep those queues to a manageable size,
I think we can increase the amount of energy coming our way.

The other important goal is that via these explicit state transitions,
especially the 'needs decision' and 'needs commit review' transitions,
we get a much clearer picture of who in the community *has* absorbed the
core standards and procedures and is ready to be "promoted" to the next
level of responsibility.  And the more people we get moved up, the more we
can get done.  (Note: making that information *easily* accessible requires
additional tooling, but it should be possible and should be done.)

Note also that I tried to engineer this so that the structure does not
handicap us or add bureaucracy: even though the basic structure is that
you get triage signoff first and then committer signoff, if the person
doing the triage is a committer, they can just move the issue to wherever
it needs to be.  So the only time two levels of signoff will be *required*
is when the committers are too busy to drain the queues.  And work on
an issue should never be *blocked* by the system, the purpose of the
queues is to draw attention to issues that are "ready" for decision.
Thus the two levels help us manage the load when we need the help,
and don't get in our way otherwise.

That's my intent, anyway.  You tell me if you think I'm headed in the
right direction.

From antoine at python.org  Mon Apr 21 18:53:41 2014
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 21 Apr 2014 18:53:41 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <1398099221.2312.20.camel@fsol>


Hi,

On lun., 2014-04-21 at 12:04 -0400, R. David Murray wrote:
> I drop 'compiler error', 'resource usage' and 'performance'.  All of
> these are bugs in the minds of the reporters, and classifying them
> separately in the 'type' field does not, as far as I can see, lead to
> any operational difference in the way the issue is treated.

But they are easily searchable that way, which is a big advantage (at
least for "resource usage" and "performance").

As for "compiler error", I find it interesting to categorize build-time
problems separately from runtime problems.

Note that these could become "components".

> I propose that we completely change the nature of this item.  I think we
> should make it a text field that is filled in by autocomplete like the
> nosy field can be, and that the value be any of the components listed
> in the experts file.  This would further respect how the experts have
> listed themselves in that file by autonosying those that are willing
> for that to happen.  The field should still be a multilink (that is,
> can contain more than one value).

Note that the UI then becomes less accessible to beginners (the current
list is readily displayed, having to start typing something is
intimidating when you don't know what to type).

> Patch Status
> ~~~~~~~~~~~~
> 
> This is a new set of fields that records information about the patch:
> 
>     unit test               
>     fix
>     documentation changes
>     news entry
>     what's new entry
>     commit message

Hmm, in principle I'd rather avoid us adding new fields (i.e.:
interaction is already complex enough).

> These fields allow us to represent all the parts that a patch must have
> to be complete, and they act as a checklist for making sure the parts
> are all there.  This is similar in intent to patchcheck, but since which
> pieces are needed is ultimately determined by a human, it is more accurate
> than that part of patchcheck and therefore more useful.

But is it *really* useful? You said you wanted additions to be
operational, not informational :-)

> The purpose of the 'stuck' tag is to label issues that we agree are
> real issues that we don't want to close as "won't fix", but that we
> can't for one reason or another currently move forward.  Operationally,
> stuck issues are either not displayed in work queues (see below) or are
> displayed at the end of the queue.

Is it a tag or a specific issue status, then?

>     new
>     needs information
>     needs decision
>     needs decision from committer
>     needs patch
>     needs review
>     needs patch update
>     needs commit review
>     closed/fixed
>     closed/wont fix
>     closed/duplicate
>     closed/insufficient information
>     closed/postponed
>     closed/not a bug
>     closed/third party

Up front, this looks like too much formalization (IMHO).

> A new issue can transition to:
> 
>     needs information                   user
>     needs decision                      user
>     needs patch                         triage
>     needs decision from committer       triage
>     closed                              triage, original reporter
>     needs review                        triage, if there is already a patch
>     needs commit review                 committer, if there is already a patch
> 
> That is, any user can indicate that more information is needed or
> request that triage decide whether to accept or reject the issue,
> but only triage can accept the issue as one that should be worked on
> (needs patch), or close it, or request a committer to make that decision.

Is there any reason to restrict actions by role like this? I don't think
we've had any significant amount of tracker abuse in the past.

(also, I'll remind you that we don't really have any official triagers,
instead letting everyone act as would-be triagers :-))

> We are waiting for more information from the original reporter, or
> from anyone else who manages to reproduce the problem.  If there is no
> additional activity for some period of time (one month?)  the issue is
> automatically moved to "closed/insufficient information".

I have never felt automatic closing was a good idea. A bug is a bug,
even if noone was able/willing to give more precise information. Also,
keeping a bug open can help other people find it later and bring
confirmation or information.

Regards

Antoine.



From rdmurray at bitdance.com  Mon Apr 21 19:49:34 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Apr 2014 13:49:34 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <1398099221.2312.20.camel@fsol>
References: <20140421160435.35094250CAE@webabinitio.net>
 <1398099221.2312.20.camel@fsol>
Message-ID: <20140421174935.11DD6250CAE@webabinitio.net>

On Mon, 21 Apr 2014 18:53:41 +0200, Antoine Pitrou <antoine at python.org> wrote:
> On lun., 2014-04-21 at 12:04 -0400, R. David Murray wrote:
> > I drop 'compiler error', 'resource usage' and 'performance'.  All of
> > these are bugs in the minds of the reporters, and classifying them
> > separately in the 'type' field does not, as far as I can see, lead to
> > any operational difference in the way the issue is treated.
> 
> But they are easily searchable that way, which is a big advantage (at
> least for "resource usage" and "performance").
> 
> As for "compiler error", I find it interesting to categorize build-time
> problems separately from runtime problems.
> 
> Note that these could become "components".

Yes, I think that would be good and desireable.

> > I propose that we completely change the nature of this item.  I think we
> > should make it a text field that is filled in by autocomplete like the
> > nosy field can be, and that the value be any of the components listed
> > in the experts file.  This would further respect how the experts have
> > listed themselves in that file by autonosying those that are willing
> > for that to happen.  The field should still be a multilink (that is,
> > can contain more than one value).
> 
> Note that the UI then becomes less accessible to beginners (the current
> list is readily displayed, having to start typing something is
> intimidating when you don't know what to type).

Well, the beginners wouldn't be setting it, someone more experienced
would be setting.  When the beginner knows what to do with that field,
they become one of the people who uses the 'uncollapsed' version of
the UI and sets it.

> > Patch Status
> > ~~~~~~~~~~~~
> > 
> > This is a new set of fields that records information about the patch:
> > 
> >     unit test               
> >     fix
> >     documentation changes
> >     news entry
> >     what's new entry
> >     commit message
> 
> Hmm, in principle I'd rather avoid us adding new fields (i.e.:
> interaction is already complex enough).

> > These fields allow us to represent all the parts that a patch must have
> > to be complete, and they act as a checklist for making sure the parts
> > are all there.  This is similar in intent to patchcheck, but since which
> > pieces are needed is ultimately determined by a human, it is more accurate
> > than that part of patchcheck and therefore more useful.
> 
> But is it *really* useful? You said you wanted additions to be
> operational, not informational :-)

It would not break my heart to drop this :).  What it provides is a
way to see at a glance what is missing, which in principle makes it
possible for a new contributor to, say, add documentation to an otherwise
complete patch.

But that may well not be enough of an advantage to be worth it.

Probably my main motivation for adding it, actually, was to make sure
we get NEWS items and What's New items when appropriate, something we
miss on a fairly regular basis.

> > The purpose of the 'stuck' tag is to label issues that we agree are
> > real issues that we don't want to close as "won't fix", but that we
> > can't for one reason or another currently move forward.  Operationally,
> > stuck issues are either not displayed in work queues (see below) or are
> > displayed at the end of the queue.
> 
> Is it a tag or a specific issue status, then?

A tag.  An issue can get stuck in any status in principle, though in
practice I think it is most likely to happen in either 'needs patch'
(ie: we don't know *how* to fix it) or one of the 'needs decision' states
(we can't *decide* how to fix it).

> >     new
> >     needs information
> >     needs decision
> >     needs decision from committer
> >     needs patch
> >     needs review
> >     needs patch update
> >     needs commit review
> >     closed/fixed
> >     closed/wont fix
> >     closed/duplicate
> >     closed/insufficient information
> >     closed/postponed
> >     closed/not a bug
> >     closed/third party
> 
> Up front, this looks like too much formalization (IMHO).

It's not about formalization, though.  It's about making the list of
bugs *manageable*.  The structure above is what provides the actionable
work queues.  *That* is the point of the exercise, and not control :)

> > A new issue can transition to:
> > 
> >     needs information                   user
> >     needs decision                      user
> >     needs patch                         triage
> >     needs decision from committer       triage
> >     closed                              triage, original reporter
> >     needs review                        triage, if there is already a patch
> >     needs commit review                 committer, if there is already a patch
> > 
> > That is, any user can indicate that more information is needed or
> > request that triage decide whether to accept or reject the issue,
> > but only triage can accept the issue as one that should be worked on
> > (needs patch), or close it, or request a committer to make that decision.
> 
> Is there any reason to restrict actions by role like this? I don't think
> we've had any significant amount of tracker abuse in the past.

Well, at this stage probably not.  I can imagine us needing it if people
(probably newcommers to the community) start pushing for 'needs patch'
or 'commit review' before a bug is confirmed as a bug or before a
patch is really ready, but we could change the permissions if and when
that happened.  The permissions I proposed is mostly about scaleability,
and while we are growing rapidly you are probably right that we aren't
there yet.

> (also, I'll remind you that we don't really have any official triagers,
> instead letting everyone act as would-be triagers :-))

Yes, except that many would-be triagers *can't* adjust the fields.  We do
have a few (ex: I've given Developer privs to Berker Peksag and Jessica
McKeller, to name two who are currently exercising the triage role only.
Both of whom I hope will be committers before long :)

Still, I don't myself have any objection to letting anybody do such
updates and see how it goes (it will probably go just fine).

> > We are waiting for more information from the original reporter, or
> > from anyone else who manages to reproduce the problem.  If there is no
> > additional activity for some period of time (one month?)  the issue is
> > automatically moved to "closed/insufficient information".
> 
> I have never felt automatic closing was a good idea. A bug is a bug,
> even if noone was able/willing to give more precise information. Also,
> keeping a bug open can help other people find it later and bring
> confirmation or information.

What if we made that another work queue in the triage dashboard,
but issues would only appear there if they were more than N days old?
In other words, someone would be prompted to make a decision to close
the bug.

I don't think keeping bugs we can't reproduce open serves anyone.
Our default search searches both open and closed bugs for a reason.
Given the ability for anyone to reopen a bug, someone finding a closed
"insufficient information" bug and reactivating it is easy.  However, if
people feel strongly that they should be left open, it's not a big deal;
we'd just leave 'needs information' as not being a work queue, and those
open issues would get ignored (except in our total open issue count).

--David

From antoine at python.org  Mon Apr 21 19:54:59 2014
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 21 Apr 2014 19:54:59 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421174935.11DD6250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
 <1398099221.2312.20.camel@fsol>
 <20140421174935.11DD6250CAE@webabinitio.net>
Message-ID: <1398102899.2312.22.camel@fsol>

On lun., 2014-04-21 at 13:49 -0400, R. David Murray wrote:
> I don't think keeping bugs we can't reproduce open serves anyone.
> Our default search searches both open and closed bugs for a reason.

Hmm, usually the first thing I do when searching for bugs is change the
radio box from "all" to "open" :-)
Open but lingering bugs are really a different status from closed bugs.
I don't have any hard feelings about it but I think the current setup is
more useful.

Regards

Antoine.



From rdmurray at bitdance.com  Mon Apr 21 20:13:13 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Apr 2014 14:13:13 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <1398102899.2312.22.camel@fsol>
References: <20140421160435.35094250CAE@webabinitio.net>
 <1398099221.2312.20.camel@fsol> <20140421174935.11DD6250CAE@webabinitio.net>
 <1398102899.2312.22.camel@fsol>
Message-ID: <20140421181313.754D3250D27@webabinitio.net>

On Mon, 21 Apr 2014 19:54:59 +0200, Antoine Pitrou <antoine at python.org> wrote:
> On lun., 2014-04-21 at 13:49 -0400, R. David Murray wrote:
> > I don't think keeping bugs we can't reproduce open serves anyone.
> > Our default search searches both open and closed bugs for a reason.
> 
> Hmm, usually the first thing I do when searching for bugs is change the
> radio box from "all" to "open" :-)

Well, but we don't want newcommers to do that.  Often they are reporting
a bug that has already been fixed, so we want them to see the closed
bugs as well.

> Open but lingering bugs are really a different status from closed bugs.
> I don't have any hard feelings about it but I think the current setup is
> more useful.

OK, this is a good point.  I'm focusing on bugs where we don't have
enough information to know if it is a bug (IMO, those should get closed).
But the way I structured it, 'needs information' could get used for other
things, like asking the submitter to try the proposed fix.  In *those*
cases, the issue should indeed stay open.

So I'd propose that we make 'needs information' a work queue as I
proposed, and have whoever checks it at the N day mark either closes it
(we don't even know if it is a bug) or tags it as stuck (we need a response
and haven't gotten one).  That way once we've taken an action on a stale
'needs information' bug it is either gone or has moved to the bottom of
the work queue and is labeled as stuck, so we know we can ignore it.

--David

From barry at python.org  Mon Apr 21 20:35:48 2014
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Apr 2014 14:35:48 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <20140421143548.37d3f614@anarchist.wooz.org>

On Apr 21, 2014, at 12:04 PM, R. David Murray wrote:

>Priority
>~~~~~~~~
>
>    low
>    normal
>    high
>    deferred blocker
>    release blocker
>
>I'd like to see us strive keep those queues clear, so that promoting a
>bug to high or release blocker means it *will* get acted on reasonably
>promptly.  (This raises the issue of what to do about bugs we currently
>mark as "release blocker" as a *reminder* to the release manager.  I don't
>have a proposal for that at the current time, as release management is
>out of scope for this document, but we'll need an answer if we are going
>to implement this.)

This is definitely an area of friction that I think needs addressing.  The
problem is that a release blocker for one version may not be a release blocker
for another.  Worse, it's the responsibility of the release managers - which
may be different per release - to manage these.

Generalizing, it may be in fact that different active versions of Python might
assign different priorities to the same bug.  I'd like to at least keep on the
table the option to assign a priority per active Python version.

Cheers,
-Barry

From barry at python.org  Mon Apr 21 20:43:30 2014
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Apr 2014 14:43:30 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <20140421144330.527f6acf@anarchist.wooz.org>

On Apr 21, 2014, at 12:04 PM, R. David Murray wrote:

>All of the other values are informational-only, and in some cases
>redundant.  If we want informational keywords, IMO we should do a full
>user-accessible tagging system.  That would be a separate proposal,
>though.

Launchpad has a nice approach here.   Tags are free-form and anybody can enter
whatever they want, but a particular project[*] can define "official" tags
that show up boldfaced when autocompleted.  It allows a project to assert that
certain tags have meaning to them, while preserving the freedom for more
global searches based on free-form tags.  Often, tags have a direct effect on
workflow process and tooling, e.g. duplicate-check-needed, fix-verified,
ci-passes, etc.

(And of course, any tag can be promoted to or demoted from being official.)

[*] I'm not sure the concept of per-project tags makes sense when we have a
tracker essentially devoted to a single project, but a global
official/unofficial designation on tags could still make sense.

Cheers,
-Barry

From barry at python.org  Mon Apr 21 21:00:27 2014
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Apr 2014 15:00:27 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421143548.37d3f614@anarchist.wooz.org>
References: <20140421160435.35094250CAE@webabinitio.net>
 <20140421143548.37d3f614@anarchist.wooz.org>
Message-ID: <20140421150027.7b970eef@anarchist.wooz.org>

On Apr 21, 2014, at 02:35 PM, Barry Warsaw wrote:

>Generalizing, it may be in fact that different active versions of Python might
>assign different priorities to the same bug.  I'd like to at least keep on the
>table the option to assign a priority per active Python version.

Although it's used somewhat differently in Launchpad (which can track bugs
that affect multiple projects, multiple versions of those projects, and
multiple Ubuntu releases those versions appear in), the concept of a "bug
task" may be informative here.

Bug tasks are a way of providing optional finer grained "applicability" to a
single issue.  Let's say you find a bug in project "foo".  Generally you just
submit the bug and this creates a single issue.

Now you realize that the bug also affects project "bar".  You can open a
second bug task that tracks the status, priority, assignment, and a few other
things, of that bug as it relates to bar.  So let's say Alice fixes the bug in
foo; she would only close the foo bug task.  A little later, Bob fixes the bug
in bar, at which time the second bug task would be closed.

It's important to note that both bug tasks share the same issue number, and in
fact are part of the same issue.  Of course, bug tasks can be added and
deleted as necessary.  (E.g. Bob decides that the bug actually doesn't affect
bar.)

In our case, we generally have just one project, but bug tasks may still be an
interesting idea to handle a bug that affects multiple versions of Python.
There could be a bug task for issue 12345 in Python 3.3 assigned to Alice, and
another bug tasks for issue 12345 in Python 3.5 assigned to Bob.  This may
also be a way to handle different values of release blocker for different
versions of Python.

Another interesting twist that Launchpad adds is the notion of fix-committed
vs. fix-released.  Let's say you walk up to bug 12345 and you see that it is
fix-committed in Python 3.3, but fix-released in Python 3.4.  This means that
the bug will not be present in the latest download of the Python 3.4 release
tarball, but it *will* still be present in latest download of the Python 3.3
release tarball.  Of course in both cases, the bug will have been fixed in
both hg branches.

Cheers,
-Barry

From thomas at python.org  Mon Apr 21 21:57:54 2014
From: thomas at python.org (Thomas Wouters)
Date: Mon, 21 Apr 2014 15:57:54 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <CAPdQG2q2MJCLGkLz-DNVBXuJaW5rCG9EM28n1iZGFBNagoHBvw@mail.gmail.com>

On Mon, Apr 21, 2014 at 12:04 PM, R. David Murray <rdmurray at bitdance.com>wrote:

>     interpreter crash
>

I think this would attract a higher proportion of 'correct' classifications
if this was named "internal error". I'm not sure if it's worth keeping this
separate, though, despite the apparent inherent higher priority.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140421/4707bf27/attachment.html>

From rdmurray at bitdance.com  Mon Apr 21 22:25:43 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Apr 2014 16:25:43 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421143548.37d3f614@anarchist.wooz.org>
References: <20140421160435.35094250CAE@webabinitio.net>
 <20140421143548.37d3f614@anarchist.wooz.org>
Message-ID: <20140421202543.8E3B8250CAE@webabinitio.net>

On Mon, 21 Apr 2014 14:35:48 -0400, Barry Warsaw <barry at python.org> wrote:
> On Apr 21, 2014, at 12:04 PM, R. David Murray wrote:
> 
> >Priority
> >~~~~~~~~
> >
> >    low
> >    normal
> >    high
> >    deferred blocker
> >    release blocker
> >
> >I'd like to see us strive keep those queues clear, so that promoting a
> >bug to high or release blocker means it *will* get acted on reasonably
> >promptly.  (This raises the issue of what to do about bugs we currently
> >mark as "release blocker" as a *reminder* to the release manager.  I don't
> >have a proposal for that at the current time, as release management is
> >out of scope for this document, but we'll need an answer if we are going
> >to implement this.)
> 
> This is definitely an area of friction that I think needs addressing.  The
> problem is that a release blocker for one version may not be a release blocker
> for another.  Worse, it's the responsibility of the release managers - which
> may be different per release - to manage these.
> 
> Generalizing, it may be in fact that different active versions of Python might
> assign different priorities to the same bug.  I'd like to at least keep on the
> table the option to assign a priority per active Python version.

Well, one way to approach this might be via the 'fixed in version'
field, which is more-or-less how we handle it now.  To make this work,
we need another role, the release manager, who gets a new work queue
for each release for which they are responsible, and it only shows bugs
that are priority 'release blocker' or 'deferred blocker' and have *not*
been fixed in the version the queue is for.

Another possibility would be to remove the blocker priorities, and make
them version-specific tags (release-blocker-3.4, deferred-blocker-3.4,
etc).  This approach would also allow those tags to be used for the
'reminder' function.  It makes for a lot of tags, though.  Which
wouldn't be bad if we had a full tag system such as Barry mentions
in a later message.

I have a feeling that per-release priorities only apply to release
management.  Would blocker/deferred be enough priority distinction
to serve?

--David

From rdmurray at bitdance.com  Mon Apr 21 22:29:14 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 21 Apr 2014 16:29:14 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421150027.7b970eef@anarchist.wooz.org>
References: <20140421160435.35094250CAE@webabinitio.net>
 <20140421143548.37d3f614@anarchist.wooz.org>
 <20140421150027.7b970eef@anarchist.wooz.org>
Message-ID: <20140421202914.CD885250CAE@webabinitio.net>

On Mon, 21 Apr 2014 15:00:27 -0400, Barry Warsaw <barry at python.org> wrote:
> On Apr 21, 2014, at 02:35 PM, Barry Warsaw wrote:
> 
> >Generalizing, it may be in fact that different active versions of Python might
> >assign different priorities to the same bug.  I'd like to at least keep on the
> >table the option to assign a priority per active Python version.
> 
> Although it's used somewhat differently in Launchpad (which can track bugs
> that affect multiple projects, multiple versions of those projects, and
> multiple Ubuntu releases those versions appear in), the concept of a "bug
> task" may be informative here.
> 
> Bug tasks are a way of providing optional finer grained "applicability" to a
> single issue.  Let's say you find a bug in project "foo".  Generally you just
> submit the bug and this creates a single issue.
> 
> Now you realize that the bug also affects project "bar".  You can open a
> second bug task that tracks the status, priority, assignment, and a few other
> things, of that bug as it relates to bar.  So let's say Alice fixes the bug in
> foo; she would only close the foo bug task.  A little later, Bob fixes the bug
> in bar, at which time the second bug task would be closed.
> 
> It's important to note that both bug tasks share the same issue number, and in
> fact are part of the same issue.  Of course, bug tasks can be added and
> deleted as necessary.  (E.g. Bob decides that the bug actually doesn't affect
> bar.)

I have to say that as an outsider looking in, this was *totally*
confusing.  I signed up to see 'python' bugs, and most of the traffic
on the tickets seemed to be about changes to things that looked like
other tickets but I guess were bug tasks.

Our case would be more straightforward...but I'm still not sure that
the extra complexity would be worth it.

--David

From barry at python.org  Mon Apr 21 22:42:16 2014
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 Apr 2014 16:42:16 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421202914.CD885250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
 <20140421143548.37d3f614@anarchist.wooz.org>
 <20140421150027.7b970eef@anarchist.wooz.org>
 <20140421202914.CD885250CAE@webabinitio.net>
Message-ID: <20140421164216.64496e96@anarchist.wooz.org>

On Apr 21, 2014, at 04:29 PM, R. David Murray wrote:

>I have to say that as an outsider looking in, this was *totally*
>confusing.  I signed up to see 'python' bugs, and most of the traffic
>on the tickets seemed to be about changes to things that looked like
>other tickets but I guess were bug tasks.
>
>Our case would be more straightforward...but I'm still not sure that
>the extra complexity would be worth it.

Right.  It makes a lot more sense when you're working on multiple packages
across the distro instead of primarily on a single package.

It may not make sense for the Python tracker, where you're essentially working
on a single project, although I wonder if adding alternative implementations,
or subprojects (e.g. idle) might make it more relevant.  Anyway, I was mostly
just throwing that out there to think about.

-Barry

P.S. I'll mostly leave the blocker/deferred discussion to active RMs, since
they're most affected by it.  But I think it probably does make sense to have
a release-manager role with certain additional privileges.

From zachary.ware+pydev at gmail.com  Mon Apr 21 22:42:23 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 21 Apr 2014 15:42:23 -0500
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>

On Mon, Apr 21, 2014 at 11:04 AM, R. David Murray <rdmurray at bitdance.com> wrote:
>
> OK, wall of text time.  Sorry about this :)

You weren't kidding :P

> Tracker Roles
> ~~~~~~~~~~~~~
>
> The tracker roles important to the workflow are:
>
>     User
>     Triager ('Developer')
>     Committer
>
> Although the tracker calls the Triager role 'Developer', I'm going
> to refer to it as Triager throughout this document, for clarity as to
> its intent.
>
> The tracker does not currently have a role equivalent to 'committer', but
> we may not need to add one explicitly, since the account of a committer
> is marked as such.
>
> The important thing to understand about these roles in the context of
> this document is that anything a user can do, a triager or committer
> can do, and anything a triager can do, a committer can do.

I think it may be worthwhile to actually implement these roles as
named, and promote people to Triager a lot earlier in their Python
career than we currently promote to committer.  I think it would be
worthwhile and help with retention to "reward" (with more work) people
who have made a couple of non-trivial contributions and seem
interested in doing more; people like, for example, Vajrasky Kok,
Nikolaus Rath, and Todd Rovito who if I'm not mistaken only have the
User role currently.

> Versions
> ~~~~~~~~
>
> Currently our versions field does double duty: we set it to the versions
> we want to fix the bug in, and then deselect versions as we fix them.
> However, I noticed when doing the "What's New" document that this
> makes things really confusing if you *do* look at the ticket later.
> You can't tell which versions got the fix without reading through the
> entire issue.  So I'd like to split this into two fields:
>
>     should be fixed in: [list of versions]
>     has been fixed in: [list of versions]
>
> I'd also like patch set links to be displayed next to the versions for
> 'has been fixed'.  When a commit references an issue, it should appear
> next to the appropriate version, but it should *not* automatically
> change the version state to fixed.  That should require separate action,
> since we sometimes apply patches that are relevant to the issue but
> do not fix it.  When an issue is transitioned to closed, there should
> be an easy way to say "mark all versions with changesets as fixed".
> It would probably be appropriate for that to be the default.
>
> These fields have direct operational meaning: they indicate a task
> to be performed or signal the completion of a task.

As may become apparent as this message goes on, I'm a fan of
checkboxes.  I don't much like the current method for selecting
multiple versions or components, which requires both keyboard and
mouse to make the selections in most cases.  Since it's not an
extremely common form element on the modern web, some users (not
necessarily just Users) may not even be familiar with how to pick and
choose specific ones--I suspect this may be part of why we have so
many issues created with every version selected, the user attempted to
choose 2.7 and 3.current but didn't know how to only select the two.
So, my suggestion here (also colored by Barry's thoughts on release
blocking) is to have a series of checkboxes for each version,
"affected", "blocks release", and "fixed".  Or even just "affected"
and "fixed", with a priority box per version.

> Type
> ~~~~
>     documentation
>     python bug
>     interpreter crash
>     security
>     enhancement request
>
> I add 'documentation' here based on PyCon feedback from Jessica McKeller
> and Selena Deckelmann.  None of the existing types makes sense to a
> beginner for a documentation bug, and the resulting confusion can lead
> someone to abandon the effort to contribute.  It also has operational
> implications (see below).
>
> I rename 'behavior' to 'python bug' for a similar reason, but I don't
> have any usability data to back that feeling, so I'm not strongly
> advocating that change.
>
> I rename 'crash' to 'interpreter crash' in an attempt to reduce the
> chances that someone will report a python traceback as a crash, something
> that otherwise happens very regularly.  I'm sure we'll never completely
> eliminate those.

Perhaps it could be made even clearer by naming them "python bug or
traceback" and "interpreter crash (segfault)", or even just calling
"interpreter crash" "segfault/abort".

> I drop 'compiler error', 'resource usage' and 'performance'.  All of
> these are bugs in the minds of the reporters, and classifying them
> separately in the 'type' field does not, as far as I can see, lead to
> any operational difference in the way the issue is treated.

I think it would be good to keep these as "components", as Antoine suggested.

> Component
> ~~~~~~~~~
>
> I propose that we completely change the nature of this item.  I think we
> should make it a text field that is filled in by autocomplete like the
> nosy field can be, and that the value be any of the components listed
> in the experts file.  This would further respect how the experts have
> listed themselves in that file by autonosying those that are willing
> for that to happen.  The field should still be a multilink (that is,
> can contain more than one value).
>
> This change would mean that it would be possible to search for issues
> based on module, which is an often-requested feature.

I like this idea quite a bit, especially changing the type of input widget.

> Patch Status
> ~~~~~~~~~~~~
>
> This is a new set of fields that records information about the patch:
>
>     unit test
>     fix
>     documentation changes
>     news entry
>     what's new entry
>     commit message
>
> For each of these, the value could be 'needs work', 'complete', or
> 'not applicable'.  For issues of type 'documentation', all lines
> except 'documentation changes' and 'commit message' would be set to
> NA by default, otherwise they will be set to 'needs work' initially,
> except for "what's new", which will be set to NA for anything except
> type enhancement.

Instead of having 3 textual options for each field, I'd prefer
checkboxes (or perhaps a series of checkboxes).  For each field, have
three checkboxes, "needed", "present" and "ready".  "needed" would be
visible only to Triager+; unchecked fields are not needed for a
complete patch and that field is hidden entirely from Users.  In the
majority of cases, "present" could be set by sniffing through a patch
when it is attached; if a patch contains "^diff.+Lib/.*test.*\.py$",
chances are very good that it has a unit test.  The "present" checkbox
should probably just be a graphic for Users, but available to Triager+
to clean things up where automation fails.  "ready" would be checked
by a reviewer who approves that particular part of a patch.

> Keywords
> ~~~~~~~~
<snip>
> I think the keywords should be settable by anyone, if they aren't already.

They're not, unless it's changed since November.

> Issue States and State Transitions
> ----------------------------------
>
> Here are the states that I think an issue can be in:
>
>     new
>     needs information
>     needs decision
>     needs decision from committer
>     needs patch
>     needs review
>     needs patch update
>     needs commit review
>     closed/fixed
>     closed/wont fix
>     closed/duplicate
>     closed/insufficient information
>     closed/postponed
>     closed/not a bug
>     closed/third party
>
> I discuss each of these, and the possible state transitions, below.
>
> All legal state transitions should be displayed in a particular
> area in the UI, and each transition should be a single radio button.
> Which possible transitions will be displayed will depend on the user's
> roundup role, and occasionally other state in the issue.
>
> The default transition is "no change".
>
> Note that the names of these states are, unlike most of the other names
> I've used so far, not the ones I necessarily expect us to use in the UI.
> They are descriptive of the state from the workflow POV, not necessarily
> the labels that should be used for the state *transitions*.

I like this scheme, and I think the split of abilities between roles
is reasonable, as long as we promote people to Triager a lot faster
than we currently do.

> Dashboard
> ---------
<snip>

I like this too, it's a vastly superior extension to a few saved
queries that I use.

> Big Picture
> -----------
<snip>
> That's my intent, anyway.  You tell me if you think I'm headed in the
> right direction.

Looks like a good general direction to me.

-- 
Zach

From guido at python.org  Mon Apr 21 22:45:21 2014
From: guido at python.org (Guido van Rossum)
Date: Mon, 21 Apr 2014 13:45:21 -0700
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421164216.64496e96@anarchist.wooz.org>
References: <20140421160435.35094250CAE@webabinitio.net>
 <20140421143548.37d3f614@anarchist.wooz.org>
 <20140421150027.7b970eef@anarchist.wooz.org>
 <20140421202914.CD885250CAE@webabinitio.net>
 <20140421164216.64496e96@anarchist.wooz.org>
Message-ID: <CAP7+vJL-YsSmJi8sNL8pTnZokztK4yd8m-TiX8NYw9s7-Q152Q@mail.gmail.com>

If there is considerable work in porting something between branches you
might have a task per branch. (This might also provide clarity about which
branches are being targeted.) Or sometimes you might have separate tasks
for code, tests, docs.

Then again, it does sound pretty marginal, and I'm not saying that our
current process is broken where these specific flows are concerned.


On Mon, Apr 21, 2014 at 1:42 PM, Barry Warsaw <barry at python.org> wrote:

> On Apr 21, 2014, at 04:29 PM, R. David Murray wrote:
>
> >I have to say that as an outsider looking in, this was *totally*
> >confusing.  I signed up to see 'python' bugs, and most of the traffic
> >on the tickets seemed to be about changes to things that looked like
> >other tickets but I guess were bug tasks.
> >
> >Our case would be more straightforward...but I'm still not sure that
> >the extra complexity would be worth it.
>
> Right.  It makes a lot more sense when you're working on multiple packages
> across the distro instead of primarily on a single package.
>
> It may not make sense for the Python tracker, where you're essentially
> working
> on a single project, although I wonder if adding alternative
> implementations,
> or subprojects (e.g. idle) might make it more relevant.  Anyway, I was
> mostly
> just throwing that out there to think about.
>
> -Barry
>
> P.S. I'll mostly leave the blocker/deferred discussion to active RMs, since
> they're most affected by it.  But I think it probably does make sense to
> have
> a release-manager role with certain additional privileges.
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140421/427c3285/attachment.html>

From nad at acm.org  Mon Apr 21 22:54:22 2014
From: nad at acm.org (Ned Deily)
Date: Mon, 21 Apr 2014 13:54:22 -0700
Subject: [core-workflow] FYI - gmane mirror is now in place
Message-ID: <nad-AC1EC9.13542221042014@news.gmane.org>

http://dir.gmane.org/gmane.comp.python.devel.core-workflow

-- 
 Ned Deily,
 nad at acm.org


From jessica.mckellar at gmail.com  Tue Apr 22 05:53:43 2014
From: jessica.mckellar at gmail.com (Jessica McKellar)
Date: Mon, 21 Apr 2014 20:53:43 -0700
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <CAKDZRcgOHHtin4A1y3NyPhgJYE0hejU4j1Te3nHZg+PXS7nGxw@mail.gmail.com>

Hi David,

Thanks for taking the time to write this up.

Aside from some small concerns, for example around auto-closing
tickets, which others have already voiced, I just wanted to say that
I'm enthusiastic about this outline. In particular, I'm enthusiastic
about making it clearer what tasks are available for new contributors,
triagers, and committers. I think this will have a big impact on
getting and retaining contributors.

> 'easy' of course has to be set manually.  The system for listing easy
> issues should list the issues only when there is an action that someone
> could take on the issue (clarify issue, write patch, review patch).
> (NB: it might be possible to come up with a better name for this tag.)

Some folks get discouraged by "easy" tickets not seeming that easy. A
common alternative tag is "bitesized".

Straying off topic to talk about workflow documentation:

The easy tag is often not set consistently by projects (or it's
forgotten until a dash to comb through tickets before sprints to add
it). Making the easy tag a triage checklist item could help with that.

I think new contributors would also appreciate the clarity of a patch
submission checklist.

I am in general a big fan of checklists. :) I also volunteer myself to
help update the devguide as the workflow gets updated.

-Jessica

From ezio.melotti at gmail.com  Tue Apr 22 06:06:53 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 22 Apr 2014 07:06:53 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>

Hi,

On Mon, Apr 21, 2014 at 7:04 PM, R. David Murray <rdmurray at bitdance.com> wrote:
>
> I'm volunteering to be the coordinator for the work, and I'm also
> volunteering to do as much of it as necessary.  That is, I'm planning
> to make this the focus of most of the "python time" I have available.
>

My Python time lately is very limited (it might get better
during/after the summer), but as one of the main maintainer of the
tracker I'll try to follow and give my input wherever is possible.  If
someone wants to work on the tracker I can also provide guidance/help
(you can ping me on IRC).

> I think that there is a way to implement this workflow or whatever
> workflow we decide on as a "new interface" while keeping the existing
> interface available, allowing us to test and refine (like, maybe do some
> usability testing? :).  Roundup has a way to dynamically specify which
> page template is used to render a particular page type, and I think we
> can leverage that to have two parallel UIs.  I could be wrong, though,
> in which case we'd need to set up a test tracker instead, which I can do.
> (Assuming it does work, there might need to be a bit of glue code to
> keep things in sync.  And there would need to be some changes in the
> data values available in the current UI, but I don't think that would
> be a bad idea anyway.)
>

This should be doable.  We can have a separate page with a completely
different template and layout (and things like js
folding/autocomplete/etc), and as long as the values (for e.g. status,
resolution, etc.) are the same everything should work fine.  If you
want to change the values then it gets a bit more tricky.
Roundup also supports Jinja templates now, so we could use them if it
makes things easier (the alternative is TAL).
Matching the www.python.org style (and update to html5) can also be
done, but that's a different issue.

> The scope of this discussion is the workflow for an "issue", which
> currently means an entry created by someone in the bug tracker at
> bugs.python.org, and goes from the creation of the issue to the resolution
> of the issue, which can but does not necessarily include committing
> something.  I won't be discussing the tooling for Zuul-like patch gating
> at this stage, I'll just assume we can figure out how to implement that.
>
> It would also be possible to build a patch gating system without
> initially integrating it with our other tools, and if we decide that's
> more important than the tracker workflow at this stage, we should switch
> our conversation to what that would look like.  Or perhaps we can work
> on the two in parallel.
>
> My own feeling is that in order to get maximum benefit out of patch
> gating, we need more clarity and utility in our *tracker* workflow first,

Having better integration between roundup and rietveld would be a good
step in that direction.
Having Roundup be more aware of patches (if they are patches or other
attachments, what files they touch, on what branches they apply
cleanly) would be another good step. I did some work on this
(especially on analyzing patches) that would be good to be integrated
with the tracker.

> but I do realize that how long it currently takes to commit a patch is
> a significant pain point, and it might be better to address that first.
>
>
>
> Goals
> -----
>
> In suggesting improvements to the existing workflow support, I'm
> starting from the fundamental idea that anything we do in the issue
> tracker and/or patch gating system should have either *operational*
> implications or *important* informational implications.  The former
> should be more heavily weighted than the latter, in my opinion.
>
> What I mean by this is that there should be no "busy work" setting
> of attributes in our workflow: when you change the state of an issue,
> it should mean that something new is *going* to happen to that issue.
> Any purely informational attribute setting should be in support of that
> new action, and wherever possible that information should *mean* something
> to some part of our tooling, not *just* to the humans looking at the issue.
>
> In general I want there to be as few clicks as practical involved in
> updating an issue.  However, I'm not addressing the actual UI design here
> (although I have ideas); I assume we are going to iterate on it for a
> bit until we have something we really like.
>
> NB: This proposal includes a number of ideas from the "desired tracker
> features" (http://wiki.python.org/moin/DesiredTrackerFeatures), but
> by no means all of them.  Some of the others are worth implementing,
> but in this document I'm focusing on primary workflow, which I think
> should happen first.
>
>
>
> Roles
> -----
>
>
> Conceptual Roles
> ~~~~~~~~~~~~~~~~
>
> In thinking about our workflow, I identify the following roles:
>
>     original reporter
>     commenter
>     triager
>     patch-producer
>     reviewer
>     core reviewer
>     committer
>
> These are in the order that the role is involved in the issue (roughly;
> variations are possible depending on the issue), and obviously a single
> person can take on multiple roles during the lifetime of a patch.
>
> I originally thought this list would have operational implications,
> but it turned out to be only an aid in thinking about the problem.
> I'm leaving it in here for exactly that purpose...it helps when thinking
> about the states and state transitions.
>
> I'd also like to add something that we currently only have informally,
> but which has been requested as a feature more than once: at every stage,
> I'd like there to be the possibility of there being a 'responsible party'.
> This is sort of like 'assigned to', except that it could be anyone with
> a tracker account, and the assignment would have a limited lifetime:
> either until the issue's state changes, or until the issue has been
> without update for some number of days (off the cuff I'd suggest 14,
> but it might also vary by state depending on what states it actually
> got used in).
>

I believe twisted uses a similar workflow, after a review the reviewer
assigns the issue to whoever made the patch, and when the patch is
updated the issue is re-assigned to the reviewer.  This also applies
if e.g. more information are needed.
The ideas is that the "assigned to" field should always point to the
person responsible for the next step that will move the issue forward.

> The idea behind this is that we have eager contributors who either
> wind up stepping on each other's toes, or rush to create and submit a
> patch before someone else does, and as a consequence of rushing, do not
> produce as good a patch as they are capable of, which actually slows
> down the issue resolution.  The ability to "take" a task and know it is
> "yours" is an important part of the new contributor process, and having a
> "responsible party" field would support that.
>

Is stepping on each other's toes a common issue?
Note that "taking" a task might have the opposite effect (it's not
difficult to find weeks/months-old messages that state "they will work
on a patch soon").  Having two patches might be better than having
zero.

>
> Tracker Roles
> ~~~~~~~~~~~~~
>
> The tracker roles important to the workflow are:
>
>     User
>     Triager ('Developer')
>     Committer
>
> Although the tracker calls the Triager role 'Developer', I'm going
> to refer to it as Triager throughout this document, for clarity as to
> its intent.
>
> The tracker does not currently have a role equivalent to 'committer', but
> we may not need to add one explicitly, since the account of a committer
> is marked as such.
>
> The important thing to understand about these roles in the context of
> this document is that anything a user can do, a triager or committer
> can do, and anything a triager can do, a committer can do.
>
>
>
> Information Fields
> ------------------
>
> An issue has an issue number and a title, and those wouldn't change.
> It also has a state, which is the subject of the second half of this
> document, and would likely be a new field in order to be able
> to have both UIs available (this field is where the glue code
> would be needed).
>
> Beyond those fields, I suggest several changes to the issue metadata;
> I will cover each one separately.
>
>
> Versions
> ~~~~~~~~
>
> Currently our versions field does double duty: we set it to the versions
> we want to fix the bug in, and then deselect versions as we fix them.

Most of the issues are fixed on all branches at the same time, so
deselecting is IME a rare occurence.

> However, I noticed when doing the "What's New" document that this
> makes things really confusing if you *do* look at the ticket later.
> You can't tell which versions got the fix without reading through the
> entire issue.  So I'd like to split this into two fields:
>
>     should be fixed in: [list of versions]
>     has been fixed in: [list of versions]
>

FWIW while triaging is sometimes select versions that are /likely/ to
be affected by a bug, without actually checking, so "should be fixed
in" might not always be accurate (unless we decide that it should be
and leave version unselected until we have verified that they are
affected).

> I'd also like patch set links to be displayed next to the versions for
> 'has been fixed'.  When a commit references an issue, it should appear
> next to the appropriate version, but it should *not* automatically
> change the version state to fixed.

It could also work the other way around: after (or before) the list of
patches, we can have a list of related changesets that is updated
automatically by the hg hook (or detected from the python-dev
messages).  Next to the changeset we could put the version, and
possibly a checkbox to indicate that the changeset fixed the issue --
however I don't think this is necessary.
If the issue has some related changesets and it's open, then more work
is required (either because not all the versions are fixed, or because
it was a preliminary set of changes that will be followed by another
set).  If it's closed, the listed changesets fixed the issue.
This is to say, I'm not sure that separating versions in two different
lists is a good idea, since it adds more fields and more work for the
triagers/committers.

>  That should require separate action,
> since we sometimes apply patches that are relevant to the issue but
> do not fix it.  When an issue is transitioned to closed, there should
> be an easy way to say "mark all versions with changesets as fixed".
> It would probably be appropriate for that to be the default.
>

This could be a solution to the "more work for triagers/committers".
We could also have a single list of versions and transition from
affected to fixed.

> These fields have direct operational meaning: they indicate a task
> to be performed or signal the completion of a task.
>
>
> Type
> ~~~~
>     documentation
>     python bug
>     interpreter crash
>     security
>     enhancement request
>
> I add 'documentation' here based on PyCon feedback from Jessica McKeller
> and Selena Deckelmann.  None of the existing types makes sense to a
> beginner for a documentation bug, and the resulting confusion can lead
> someone to abandon the effort to contribute.  It also has operational
> implications (see below).
>

This seems reasonable to me.

> I rename 'behavior' to 'python bug' for a similar reason, but I don't
> have any usability data to back that feeling, so I'm not strongly
> advocating that change.
>

Why not just bug?

> I rename 'crash' to 'interpreter crash' in an attempt to reduce the
> chances that someone will report a python traceback as a crash, something
> that otherwise happens very regularly.  I'm sure we'll never completely
> eliminate those.
>
> I drop 'compiler error', 'resource usage' and 'performance'.  All of
> these are bugs in the minds of the reporters, and classifying them
> separately in the 'type' field does not, as far as I can see, lead to
> any operational difference in the way the issue is treated.
>
> What I mean by that: most bugs are either 'documentation' or 'python bug'
> or 'enhancement request'.

Just floating an idea: what if we only keep these 3 (or maybe just
bug/enhancements) and use tags for things like performance, security,
crash, documentation, etc?
We could have a crash that can turn in a security issue, or resource
usage that causes bad performances and with tags this could be
described easily (and we could use them instead of components too).
This is quite a big change, but other bug tracking systems use them
quite successfully (to the point of having tags (possibly divided in
categories and using different color codes) tracking versions, types,
priority, etc.).

> Differentiating these is important, as doc
> bugs are handled very differently from python bugs (documentation fixes
> do not get NEWS entries, for example), and bug vs enhancement determines
> which versions we fix things in.  'compiler error', 'resource usage', and
> 'performance', on the other hand, are all handled with the same workflow
> that applies to bugs.  You might think that there is a difference for
> resource usage and performance, in that we don't in general backport
> those fixes.  The key there, though, is "in general".  The decision as to
> which versions to apply the fix is made based on the magnitude of the bug,
> and there really are only two cases: we mostly don't backport, as is the
> case for enhancements, but we sometimes do backport, just like we would
> a bug fix.  The same applies in reverse to compile bugs: we mostly fix
> those in all versions, but we don't always.  So the only *operational*
> effect of having these as distinct types would be to confuse things,
> since we couldn't tell from the type whether or not this was something
> that should be applied to all versions or only default.  Instead we
> should set (or, more likely, triage) them as either 'python bug' or
> 'enhancement', which have the correct operational implications.
>
> There *is* an operational reason for having security and interpreter
> crash as separate types.  In both of these cases the versions we fix
> it in is always the same (all active for crashers, all active + all
> security-only for security bugs), and the issue priority should default
> to either high or release blocker.  In addition, security bugs should
> be automatically reported to the PSRT, and arguably the report should
> be be hidden from all but the PSRT and the original reporter.
>

See http://psf.upfronthosting.co.za/roundup/meta/issue393 and
http://psf.upfronthosting.co.za/roundup/meta/file275/issue393.png )
for a meta-tracker patch that warns about the PSRT while reporting
security issues.

>
> Priority
> ~~~~~~~~
>
>     low
>     normal
>     high
>     deferred blocker
>     release blocker
>
> The only change here is to eliminate 'critical'.  I'm not wedded to
> that, but if we have both 'critical' and 'high' priorities, 'high'
> ends up getting treated as pretty much equivalent to either 'normal' or
> 'critical', depending on the person.  I would argue that anything that
> is severe enough to be marked 'critical' should in fact be a release
> blocker, and anything that is not a release blocker is effectively only
> 'high' priority.
>

SGTM.

> The priority is currently operational only in that one can sort issues by
> priority.  I propose that we make them much more operational, by posting
> a count and/or list of the bugs with more than normal priority somewhere
> public on a regular basis, such as python-dev, python-committers,
> and/or #python-dev.  (Well, definitely #python-dev.)
>
> I'd like to see us strive keep those queues clear, so that promoting a
> bug to high or release blocker means it *will* get acted on reasonably
> promptly.  (This raises the issue of what to do about bugs we currently
> mark as "release blocker" as a *reminder* to the release manager.  I don't
> have a proposal for that at the current time, as release management is
> out of scope for this document, but we'll need an answer if we are going
> to implement this.)
>

The release managers of the affected versions are already
automatically added to the nosy list of the issue if the priority is
set to release blocker (I think the script should be updated for 3.5).

>
> Component
> ~~~~~~~~~
>
> I propose that we completely change the nature of this item.  I think we
> should make it a text field that is filled in by autocomplete like the
> nosy field can be, and that the value be any of the components listed
> in the experts file.  This would further respect how the experts have
> listed themselves in that file by autonosying those that are willing
> for that to happen.  The field should still be a multilink (that is,
> can contain more than one value).
>

This sounds similar to the tag system I mentioned above.

> This change would mean that it would be possible to search for issues
> based on module, which is an often-requested feature.
>

I'm still not sure having a "tag" for each module would be a good
idea.  Taking them from the experts index would at least solve the
problem of modules that are not available on specific versions or that
have been renamed.
One thing I would like to do is getting the affected module from the
patch (see http://wolfprojects.altervista.org/issues.html ), but that
only work when a patch is there.  If we add per-module tags, we could
add them automatically when a patch is submitted.

>
> Patch Status
> ~~~~~~~~~~~~
>
> This is a new set of fields that records information about the patch:
>
>     unit test
>     fix
>     documentation changes
>     news entry
>     what's new entry
>     commit message
>
> For each of these, the value could be 'needs work', 'complete', or
> 'not applicable'.  For issues of type 'documentation', all lines
> except 'documentation changes' and 'commit message' would be set to
> NA by default, otherwise they will be set to 'needs work' initially,
> except for "what's new", which will be set to NA for anything except
> type enhancement.
>

This sounds like a lot of new field / UI clutter / work for the
triagers, even though this could be automated somehow by looking at
the files touched by the patch.

> Note that the inclusion of 'news entry' and 'commit message' assume two
> things: that we retool the NEWS file so that NEWS entries can be added
> automatically without conflicts, and that we change our patch workflow
> to use mercurial's capability to accept 'hg export' patches and/or some
> other sort of pull request.  This part is one place we get into
> non-roundup territory, so that may be a phase two addition.
>
> Mercurial's 'evolve' feature, which we saw demoed at PyCon and which I
> understand is currently available as a plugin, makes this capability much
> more useful.  When the non-core committer syncs the master repository
> after their patch has been committed, the right thing happens to the
> history in their repository to make their local commit disappear in
> favor of the commit made to master.  The contributor will also be able
> to essentially *edit* the patch in their local repository based on the
> review feedback, without ending up with a chain of commits in their
> local repo that they have to deal with.  Evolve should also facilitate
> DVCS-based collaboration between core and non-core developers, as well as
> between non-core developers.  (I'm assuming all this works with exported
> changesets, since in the demo they talked about starting with a patch
> received via email, which is their normal workflow.  But we should double
> check this.)
>
> These fields allow us to represent all the parts that a patch must have
> to be complete, and they act as a checklist for making sure the parts
> are all there.  This is similar in intent to patchcheck, but since which
> pieces are needed is ultimately determined by a human, it is more accurate
> than that part of patchcheck and therefore more useful.
>

Maybe this could be implemented in the patch list, as a series of ?
added automatically:
File name   |fix|tst|doc|nws|
------------+---+---+---+---+
patch1.diff | ? |   |   |   |
patch2.diff | ? | ? |   |   |
patch3.diff | ? | ? | ? | ? |

>
> Stage
> ~~~~~
>
> This goes away, subsumed into state.
>
>
> Status
> ~~~~~~
>
> This either holds the state information, or goes away in favor of a new
> 'state' field.
>
>
> Keywords
> ~~~~~~~~
>
>     buildbot
>     easy
>     stuck
>
> buildbot and easy are the only two existing, non-redundant tags that I can
> see a way to make operational.
>
> 'easy' of course has to be set manually.  The system for listing easy
> issues should list the issues only when there is an action that someone
> could take on the issue (clarify issue, write patch, review patch).
> (NB: it might be possible to come up with a better name for this tag.)
>

Having an icon for issues with patches in the issue list (similar to
the attachment icon in the mail list) would easily show what issues
still don't have a patch.

> For buildbot, those issues should be displayed in a report or dashboard,
> and we should try to keep this queue empty.  This becomes even more
> important when we have a patch gating system online.
>

First we should turn all the buildbot green and  have email
notification to python-checkins whenever a stable buildbot turns red.

> All of the other values are informational-only, and in some cases
> redundant.  If we want informational keywords, IMO we should do a full
> user-accessible tagging system.  That would be a separate proposal,
> though.
>

Do you mean that users can create their own tags on the fly?  I would
rather define a fixed set of available tags if we go down this route.

> Note: I claim the regression tags are redundant because I think
> regression issues should be release blockers.  (They are also ambiguous:
> is '3.3regression' a bug in 3.3 that is a regression relative to 3.2,
> or a 3.3.x bug relative to 3.3.x-1, or a 3.4 bug that is a regression
> relative to 3.3?  Better to just explain exactly what is going on in
> the issue comments, IMO.)
>
> The purpose of the 'stuck' tag is to label issues that we agree are
> real issues that we don't want to close as "won't fix", but that we
> can't for one reason or another currently move forward.  Operationally,
> stuck issues are either not displayed in work queues (see below) or are
> displayed at the end of the queue.
>

Is this a replacement for languishing?

> I think the keywords should be settable by anyone, if they aren't already.
>

They should be, I think only the stage is not settable by everyone
(and it should be IMHO).

>
>
> Issue States and State Transitions
> ----------------------------------
>
> Here are the states that I think an issue can be in:
>
>     new
>     needs information
>     needs decision
>     needs decision from committer
>     needs patch
>     needs review
>     needs patch update
>     needs commit review
>     closed/fixed
>     closed/wont fix
>     closed/duplicate
>     closed/insufficient information
>     closed/postponed
>     closed/not a bug
>     closed/third party
>
> I discuss each of these, and the possible state transitions, below.
>

These are a lot of values to add, and the workflow you suggest seems
quite complex.
OTOH it seems to have operational advantages, so it might be worth
giving it a chance, especially if it has a good UI,

> All legal state transitions should be displayed in a particular
> area in the UI, and each transition should be a single radio button.
>

A radio button is not a good UI :)
Maybe something like "This issue | needs information |?|.", with the
dropdown showing all the possible states that can follow "needs
informations".

> [... list of all the states ...]
>
> Dashboard
> ---------
>
> The dashboard would be a new feature, a new landing page and linked from
> the left hand menu bar.  It would list the first N (adjustable) items in
> each queue relevant to the user for which they are the responsible party,
> followed by those on which the user is nosy, followed by those on which
> they are not nosy.
>
> A general user would see the 'new', 'needs patch', 'needs patch update',
> and, 'needs review' queues.
>
> A triager would see, above the preceding, the 'needs decision' queue.
>
> A committer would see, above the preceding, the 'needs decision from
> committer' and 'needs commit review' queues.
>
> In all queues, issues would be sorted in priority order followed by most
> recent activity, with color coding for the priority.  'stuck' issues
> would appear last, and there should be something to visually differentiate
> issues on which the user is responsible, just nosy, or not nosy.
>
> As with everything else, this is of course subject to discussion.
> It would also be lovely if the user could configure their dashboard,
> but that would probably fall into the category of advanced features we
> come back to later.
>

What happens to the other pages?

>
>
> Big Picture
> -----------
>
> My goal here is to facilitate the involvement of the wider community
> in our workflow as much as possible.  The structure above is designed
> to allow the community to do as much work as possible, and the "trusted
> individuals" to act as gatekeepers to insure quality.  It is theoretically
> possible for a patch to get all the way to 'needs commit review' without
> any more higher level involvement than a triage person moving the issue
> to 'patch needed'.  Of course in reality much more involvement from core
> will be needed, since we need to transfer knowledge to the community,
> and especially the newcomers, about our standards and procedures,
> Not to mention the code.  And committers are going to *want* to do
> general commentary and triage level activities on issues anyway.  But,
> for those committers who have less time, I'd like to think that this
> system would allow them to focus their time on just the stuff only they
> can do, and thus perhaps draw more contributions from some of our less
> active or currently-inactive committers.
>
> The key to this is that instead of issues getting lost, core can watch
> certain key queues: 'needs decision', 'needs committer decision', and
> 'needs commit review'.  When issues get to those stages, the people with
> the experience to do something know that it is *their* responsibility to
> do it: the issues are to a point where the general community can't help
> without core input.  If we can keep those queues to a manageable size,
> I think we can increase the amount of energy coming our way.
>

What if we can't keep them manageable?
There's a fine line between managing to handle all the incoming issues
and having issues start leaking in and giving up on the goal of
keeping the queues empty.  When your queue has 3 issues, well, you
could just take a look now and make it empty, but you don't quite have
time right now for looking at 5 issues... Maybe later (or tomorrow, or
during the weekend) you will have more time.  I think many of you had
something similar happening with your mail inbox (or new year
resolutions, or similar things).

I'll also suggest another related (and "controversial") idea.  People
like to reach goals: if they address the 3 issues in their queue they
have reached the "empty queue" goal.  Addressing 3 of the 5 issues
isn't quite the same thing.
I've seen this concept being exploited in three main ways:
  1) badges/trophies/achievements;
  2) competitions;
  3) streaks;
The first means that the user can get a badge because they closed
their 10th issues, or triaged their 50th, or submitted 5 patches,
being the first to reply on an issue for the 10th time, or whatever.
Even if fixing 3 out of 5 issues won't make you reach the "empty
queue" goal, maybe you can reach the "10 closed issues".  An example
of this are StackOverflow badges (e.g.
http://stackoverflow.com/users/95810/alex-martelli?tab=badges ).
The second includes "leaderboards" or "awards" for being above
average.  Examples of this are Twisted high score
(http://twistedmatrix.com/highscores/) or charts like
http://www.ohloh.net/p/python/contributors (at some point I was the
most active contributor and was trying to keep my contributions going,
but then Serhiy became a contributor... :).  Something similar could
be done by mentioning "exceptional" results in the weekly summary
report (e.g. people who fixed/contributed to the most issues).
The third is about perseverance.  Every day/week you have a goal to
meet, if you reach it you streak counter increases, if you miss it the
counter starts again from zero.  Once you start building up a high
count, you really don't want to miss your goal and start everything
from scratch.  Here the goal might be close 3 issues per week, or
something similar, and could have associate badges ("contribute every
day for a month", "close 3 issues per week for 3 weeks in a row", etc)

While I understand that probably most of the core devs would be
against similar things, this might motivate new users and make them
"addicted" to the tracker, while making their experience more
enjoyable, and the example I linked show that similar things exist
even in these environments (and not only on the micro-transaction
based smartphone games :).  People who don't care about this
(different people are more or less competitive) could just ignore it.
OTOH this might have a negative side-effect if users start closing
issues randomly just to get the "100 closed issues" badge, but this is
not difficult to avoid.

> The other important goal is that via these explicit state transitions,
> especially the 'needs decision' and 'needs commit review' transitions,
> we get a much clearer picture of who in the community *has* absorbed the
> core standards and procedures and is ready to be "promoted" to the next
> level of responsibility.  And the more people we get moved up, the more we
> can get done.  (Note: making that information *easily* accessible requires
> additional tooling, but it should be possible and should be done.)
>
> Note also that I tried to engineer this so that the structure does not
> handicap us or add bureaucracy: even though the basic structure is that
> you get triage signoff first and then committer signoff, if the person
> doing the triage is a committer, they can just move the issue to wherever
> it needs to be.  So the only time two levels of signoff will be *required*
> is when the committers are too busy to drain the queues.  And work on
> an issue should never be *blocked* by the system, the purpose of the
> queues is to draw attention to issues that are "ready" for decision.
> Thus the two levels help us manage the load when we need the help,
> and don't get in our way otherwise.
>
> That's my intent, anyway.  You tell me if you think I'm headed in the
> right direction.

I would like to see a summary/mock-up of what the end result would be
after all these fields are added/removed.
This will give a better idea about the complexity of the new workflow,
but there are definitely good suggestions in there (even though it's a
lot of work).

Best Regards,
Ezio Melotti

From ezio.melotti at gmail.com  Tue Apr 22 06:46:42 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 22 Apr 2014 07:46:42 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421174935.11DD6250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
 <1398099221.2312.20.camel@fsol>
 <20140421174935.11DD6250CAE@webabinitio.net>
Message-ID: <CACBhJdFJtxpGPz85F5Rgc1Q2EARRyw9h+bSCd0L-WBJeQmQ_-g@mail.gmail.com>

On Apr 21, 2014 8:49 PM, "R. David Murray" <rdmurray at bitdance.com> wrote:
>
> On Mon, 21 Apr 2014 18:53:41 +0200, Antoine Pitrou <antoine at python.org>
wrote:
> > On lun., 2014-04-21 at 12:04 -0400, R. David Murray wrote:
> > > I drop 'compiler error', 'resource usage' and 'performance'.  All of
> > > these are bugs in the minds of the reporters, and classifying them
> > > separately in the 'type' field does not, as far as I can see, lead to
> > > any operational difference in the way the issue is treated.
> >
> > But they are easily searchable that way, which is a big advantage (at
> > least for "resource usage" and "performance").
> >
> > As for "compiler error", I find it interesting to categorize build-time
> > problems separately from runtime problems.
> >
> > Note that these could become "components".
>
> Yes, I think that would be good and desireable.
>

I think components are/were mostly used to indicate different dirs/packages
(e.g. Doc/, Modules/, Lib/, Liberty/test/, Lib/json/), but now also contain
Unicode, Windows, and even cross-build.

> > > I propose that we completely change the nature of this item.  I think
we
> > > should make it a text field that is filled in by autocomplete like the
> > > nosy field can be, and that the value be any of the components listed
> > > in the experts file.  This would further respect how the experts have
> > > listed themselves in that file by autonosying those that are willing
> > > for that to happen.  The field should still be a multilink (that is,
> > > can contain more than one value).
> >
> > Note that the UI then becomes less accessible to beginners (the current
> > list is readily displayed, having to start typing something is
> > intimidating when you don't know what to type).
>
> Well, the beginners wouldn't be setting it, someone more experienced
> would be setting.  When the beginner knows what to do with that field,
> they become one of the people who uses the 'uncollapsed' version of
> the UI and sets it.
>
> > > Patch Status
> > > ~~~~~~~~~~~~
> > >
> > > This is a new set of fields that records information about the patch:
> > >
> > >     unit test
> > >     fix
> > >     documentation changes
> > >     news entry
> > >     what's new entry
> > >     commit message
> >
> > Hmm, in principle I'd rather avoid us adding new fields (i.e.:
> > interaction is already complex enough).
>
> > > These fields allow us to represent all the parts that a patch must
have
> > > to be complete, and they act as a checklist for making sure the parts
> > > are all there.  This is similar in intent to patchcheck, but since
which
> > > pieces are needed is ultimately determined by a human, it is more
accurate
> > > than that part of patchcheck and therefore more useful.
> >
> > But is it *really* useful? You said you wanted additions to be
> > operational, not informational :-)
>
> It would not break my heart to drop this :).  What it provides is a
> way to see at a glance what is missing, which in principle makes it
> possible for a new contributor to, say, add documentation to an otherwise
> complete patch.
>
> But that may well not be enough of an advantage to be worth it.
>
> Probably my main motivation for adding it, actually, was to make sure
> we get NEWS items and What's New items when appropriate, something we
> miss on a fairly regular basis.
>
> > > The purpose of the 'stuck' tag is to label issues that we agree are
> > > real issues that we don't want to close as "won't fix", but that we
> > > can't for one reason or another currently move forward.
 Operationally,
> > > stuck issues are either not displayed in work queues (see below) or
are
> > > displayed at the end of the queue.
> >
> > Is it a tag or a specific issue status, then?
>
> A tag.  An issue can get stuck in any status in principle, though in
> practice I think it is most likely to happen in either 'needs patch'
> (ie: we don't know *how* to fix it) or one of the 'needs decision' states
> (we can't *decide* how to fix it).
>
> > >     new
> > >     needs information
> > >     needs decision
> > >     needs decision from committer
> > >     needs patch
> > >     needs review
> > >     needs patch update
> > >     needs commit review
> > >     closed/fixed
> > >     closed/wont fix
> > >     closed/duplicate
> > >     closed/insufficient information
> > >     closed/postponed
> > >     closed/not a bug
> > >     closed/third party
> >
> > Up front, this looks like too much formalization (IMHO).
>
> It's not about formalization, though.  It's about making the list of
> bugs *manageable*.  The structure above is what provides the actionable
> work queues.  *That* is the point of the exercise, and not control :)
>
> > > A new issue can transition to:
> > >
> > >     needs information                   user
> > >     needs decision                      user
> > >     needs patch                         triage
> > >     needs decision from committer       triage
> > >     closed                              triage, original reporter
> > >     needs review                        triage, if there is already a
patch
> > >     needs commit review                 committer, if there is
already a patch
> > >
> > > That is, any user can indicate that more information is needed or
> > > request that triage decide whether to accept or reject the issue,
> > > but only triage can accept the issue as one that should be worked on
> > > (needs patch), or close it, or request a committer to make that
decision.
> >
> > Is there any reason to restrict actions by role like this? I don't think
> > we've had any significant amount of tracker abuse in the past.
>
> Well, at this stage probably not.  I can imagine us needing it if people
> (probably newcommers to the community) start pushing for 'needs patch'
> or 'commit review' before a bug is confirmed as a bug or before a
> patch is really ready, but we could change the permissions if and when
> that happened.  The permissions I proposed is mostly about scaleability,
> and while we are growing rapidly you are probably right that we aren't
> there yet.
>
> > (also, I'll remind you that we don't really have any official triagers,
> > instead letting everyone act as would-be triagers :-))
>
> Yes, except that many would-be triagers *can't* adjust the fields.  We do
> have a few (ex: I've given Developer privs to Berker Peksag and Jessica
> McKeller, to name two who are currently exercising the triage role only.
> Both of whom I hope will be committers before long :)
>
> Still, I don't myself have any objection to letting anybody do such
> updates and see how it goes (it will probably go just fine).
>
> > > We are waiting for more information from the original reporter, or
> > > from anyone else who manages to reproduce the problem.  If there is no
> > > additional activity for some period of time (one month?)  the issue is
> > > automatically moved to "closed/insufficient information".
> >
> > I have never felt automatic closing was a good idea. A bug is a bug,
> > even if noone was able/willing to give more precise information. Also,
> > keeping a bug open can help other people find it later and bring
> > confirmation or information.
>
> What if we made that another work queue in the triage dashboard,
> but issues would only appear there if they were more than N days old?
> In other words, someone would be prompted to make a decision to close
> the bug.
>

I usually set these as pending while asking for more info, so that they are
easy to find later. Closing them automatically could be OK. Of course we
won't close automatically issues with patches or some kind of progress,
even if slow.

> I don't think keeping bugs we can't reproduce open serves anyone.
> Our default search searches both open and closed bugs for a reason.
> Given the ability for anyone to reopen a bug, someone finding a closed
> "insufficient information" bug and reactivating it is easy.  However, if
> people feel strongly that they should be left open, it's not a big deal;
> we'd just leave 'needs information' as not being a work queue, and those
> open issues would get ignored (except in our total open issue count).
>
> --David
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140422/85a01e9f/attachment.html>

From berker.peksag at gmail.com  Tue Apr 22 11:24:56 2014
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Tue, 22 Apr 2014 12:24:56 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140421160435.35094250CAE@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
Message-ID: <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>

On Mon, Apr 21, 2014 at 7:04 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> Priority
> ~~~~~~~~
>
>     low
>     normal
>     high
>     deferred blocker
>     release blocker
>
> The only change here is to eliminate 'critical'.  I'm not wedded to
> that, but if we have both 'critical' and 'high' priorities, 'high'
> ends up getting treated as pretty much equivalent to either 'normal' or
> 'critical', depending on the person.  I would argue that anything that
> is severe enough to be marked 'critical' should in fact be a release
> blocker, and anything that is not a release blocker is effectively only
> 'high' priority.
>
> The priority is currently operational only in that one can sort issues by
> priority.  I propose that we make them much more operational, by posting
> a count and/or list of the bugs with more than normal priority somewhere
> public on a regular basis, such as python-dev, python-committers,
> and/or #python-dev.  (Well, definitely #python-dev.)

The Django project uses a development dashboard to display numbers
like "release blockers", "patches needing review", etc:
https://dashboard.djangoproject.com/ It would be good if there is a
dashboard like that for CPython (by using Roundup's XML-RPC API:
http://roundup.sourceforge.net/docs/xmlrpc.html#client-api )

--Berker

From ezio.melotti at gmail.com  Tue Apr 22 15:27:28 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 22 Apr 2014 16:27:28 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
Message-ID: <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>

On Mon, Apr 21, 2014 at 11:42 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> On Mon, Apr 21, 2014 at 11:04 AM, R. David Murray <rdmurray at bitdance.com> wrote:
>>
>> OK, wall of text time.  Sorry about this :)
>
> You weren't kidding :P
>
>> Tracker Roles
>> ~~~~~~~~~~~~~
>>
>> The tracker roles important to the workflow are:
>>
>>     User
>>     Triager ('Developer')
>>     Committer
>>
>> Although the tracker calls the Triager role 'Developer', I'm going
>> to refer to it as Triager throughout this document, for clarity as to
>> its intent.
>>
>> The tracker does not currently have a role equivalent to 'committer', but
>> we may not need to add one explicitly, since the account of a committer
>> is marked as such.
>>
>> The important thing to understand about these roles in the context of
>> this document is that anything a user can do, a triager or committer
>> can do, and anything a triager can do, a committer can do.
>
> I think it may be worthwhile to actually implement these roles as
> named, and promote people to Triager a lot earlier in their Python
> career than we currently promote to committer.  I think it would be
> worthwhile and help with retention to "reward" (with more work) people
> who have made a couple of non-trivial contributions and seem
> interested in doing more; people like, for example, Vajrasky Kok,
> Nikolaus Rath, and Todd Rovito who if I'm not mistaken only have the
> User role currently.
>

I think we are quite liberal in giving away the "Developer" role on the tracker.
The main issue that it might take a core dev notices that someone has
been actively contributing for a while and decide to check if they are
Developers or not.  If people request it on IRC they can generally get
it sooner.

>> Versions
>> ~~~~~~~~
>>
>> Currently our versions field does double duty: we set it to the versions
>> we want to fix the bug in, and then deselect versions as we fix them.
>> However, I noticed when doing the "What's New" document that this
>> makes things really confusing if you *do* look at the ticket later.
>> You can't tell which versions got the fix without reading through the
>> entire issue.  So I'd like to split this into two fields:
>>
>>     should be fixed in: [list of versions]
>>     has been fixed in: [list of versions]
>>
>> I'd also like patch set links to be displayed next to the versions for
>> 'has been fixed'.  When a commit references an issue, it should appear
>> next to the appropriate version, but it should *not* automatically
>> change the version state to fixed.  That should require separate action,
>> since we sometimes apply patches that are relevant to the issue but
>> do not fix it.  When an issue is transitioned to closed, there should
>> be an easy way to say "mark all versions with changesets as fixed".
>> It would probably be appropriate for that to be the default.
>>
>> These fields have direct operational meaning: they indicate a task
>> to be performed or signal the completion of a task.
>
> As may become apparent as this message goes on, I'm a fan of
> checkboxes.

Note that we shouldn't limited ourself to basic form elements.
In theory we could use any fancy js-powered widget (e.g. jqueryui, the
one I used for the nosy autocomplete), as long as it improves
usability and that the page is still usable when js is not available.
This is an example I found googling:
http://www.erichynds.com/examples/jquery-ui-multiselect-widget/demos/

>  I don't much like the current method for selecting
> multiple versions or components, which requires both keyboard and
> mouse to make the selections in most cases.  Since it's not an
> extremely common form element on the modern web, some users (not
> necessarily just Users) may not even be familiar with how to pick and
> choose specific ones--I suspect this may be part of why we have so
> many issues created with every version selected, the user attempted to
> choose 2.7 and 3.current but didn't know how to only select the two.
> So, my suggestion here (also colored by Barry's thoughts on release
> blocking) is to have a series of checkboxes for each version,
> "affected", "blocks release", and "fixed".  Or even just "affected"
> and "fixed", with a priority box per version.
>
>> Type
>> ~~~~
>>     documentation
>>     python bug
>>     interpreter crash
>>     security
>>     enhancement request
>>
>> I add 'documentation' here based on PyCon feedback from Jessica McKeller
>> and Selena Deckelmann.  None of the existing types makes sense to a
>> beginner for a documentation bug, and the resulting confusion can lead
>> someone to abandon the effort to contribute.  It also has operational
>> implications (see below).
>>
>> I rename 'behavior' to 'python bug' for a similar reason, but I don't
>> have any usability data to back that feeling, so I'm not strongly
>> advocating that change.
>>
>> I rename 'crash' to 'interpreter crash' in an attempt to reduce the
>> chances that someone will report a python traceback as a crash, something
>> that otherwise happens very regularly.  I'm sure we'll never completely
>> eliminate those.
>
> Perhaps it could be made even clearer by naming them "python bug or
> traceback" and "interpreter crash (segfault)", or even just calling
> "interpreter crash" "segfault/abort".
>
>> I drop 'compiler error', 'resource usage' and 'performance'.  All of
>> these are bugs in the minds of the reporters, and classifying them
>> separately in the 'type' field does not, as far as I can see, lead to
>> any operational difference in the way the issue is treated.
>
> I think it would be good to keep these as "components", as Antoine suggested.
>
>> Component
>> ~~~~~~~~~
>>
>> I propose that we completely change the nature of this item.  I think we
>> should make it a text field that is filled in by autocomplete like the
>> nosy field can be, and that the value be any of the components listed
>> in the experts file.  This would further respect how the experts have
>> listed themselves in that file by autonosying those that are willing
>> for that to happen.  The field should still be a multilink (that is,
>> can contain more than one value).
>>
>> This change would mean that it would be possible to search for issues
>> based on module, which is an often-requested feature.
>
> I like this idea quite a bit, especially changing the type of input widget.
>
>> Patch Status
>> ~~~~~~~~~~~~
>>
>> This is a new set of fields that records information about the patch:
>>
>>     unit test
>>     fix
>>     documentation changes
>>     news entry
>>     what's new entry
>>     commit message
>>
>> For each of these, the value could be 'needs work', 'complete', or
>> 'not applicable'.  For issues of type 'documentation', all lines
>> except 'documentation changes' and 'commit message' would be set to
>> NA by default, otherwise they will be set to 'needs work' initially,
>> except for "what's new", which will be set to NA for anything except
>> type enhancement.
>
> Instead of having 3 textual options for each field, I'd prefer
> checkboxes (or perhaps a series of checkboxes).  For each field, have
> three checkboxes, "needed", "present" and "ready".  "needed" would be
> visible only to Triager+; unchecked fields are not needed for a
> complete patch and that field is hidden entirely from Users.  In the
> majority of cases, "present" could be set by sniffing through a patch
> when it is attached; if a patch contains "^diff.+Lib/.*test.*\.py$",
> chances are very good that it has a unit test.

This can be done, but I would prefer a better approach where the exact
file names are extracted and normalized from each patch like I did for
http://wolfprojects.altervista.org/issues.html

>  The "present" checkbox
> should probably just be a graphic for Users, but available to Triager+
> to clean things up where automation fails.  "ready" would be checked
> by a reviewer who approves that particular part of a patch.
>
>> Keywords
>> ~~~~~~~~
> <snip>
>> I think the keywords should be settable by anyone, if they aren't already.
>
> They're not, unless it's changed since November.
>
>> Issue States and State Transitions
>> ----------------------------------
>>
>> Here are the states that I think an issue can be in:
>>
>>     new
>>     needs information
>>     needs decision
>>     needs decision from committer
>>     needs patch
>>     needs review
>>     needs patch update
>>     needs commit review
>>     closed/fixed
>>     closed/wont fix
>>     closed/duplicate
>>     closed/insufficient information
>>     closed/postponed
>>     closed/not a bug
>>     closed/third party
>>
>> I discuss each of these, and the possible state transitions, below.
>>
>> All legal state transitions should be displayed in a particular
>> area in the UI, and each transition should be a single radio button.
>> Which possible transitions will be displayed will depend on the user's
>> roundup role, and occasionally other state in the issue.
>>
>> The default transition is "no change".
>>
>> Note that the names of these states are, unlike most of the other names
>> I've used so far, not the ones I necessarily expect us to use in the UI.
>> They are descriptive of the state from the workflow POV, not necessarily
>> the labels that should be used for the state *transitions*.
>
> I like this scheme, and I think the split of abilities between roles
> is reasonable, as long as we promote people to Triager a lot faster
> than we currently do.
>

As I mentioned above, we aren't slow because we don't want to promote
people, but just because the promotion only happens when a core dev
happens to notice that someone deserving that role still doesn't have
it (and knows how to upgrade the role).  Maybe showing the role more
clearly (with an icon like the committer one) would make it easier to
notice when someone is not a Triager yet.

Best Regards,
Ezio Melotti

>> Dashboard
>> ---------
> <snip>
>
> I like this too, it's a vastly superior extension to a few saved
> queries that I use.
>
>> Big Picture
>> -----------
> <snip>
>> That's my intent, anyway.  You tell me if you think I'm headed in the
>> right direction.
>
> Looks like a good general direction to me.
>
> --
> Zach

From ncoghlan at gmail.com  Tue Apr 22 17:13:08 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Apr 2014 11:13:08 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
Message-ID: <CADiSq7e2YJ+n4fumMnYujOh9yzwtPsNGsPFRhQk2YMHGjwUFaA@mail.gmail.com>

On 22 Apr 2014 00:06, "Ezio Melotti" <ezio.melotti at gmail.com> wrote:
> What if we can't keep them manageable?
> There's a fine line between managing to handle all the incoming issues
> and having issues start leaking in and giving up on the goal of
> keeping the queues empty.  When your queue has 3 issues, well, you
> could just take a look now and make it empty, but you don't quite have
> time right now for looking at 5 issues... Maybe later (or tomorrow, or
> during the weekend) you will have more time.  I think many of you had
> something similar happening with your mail inbox (or new year
> resolutions, or similar things).

Then that becomes data folks like me, Toshio Kuratomi, Jesse Noller and Van
Lindberg can take to our respective management chains to say "Hey, we have
this critical upstream dependency that needs more developer time to keep up
with its workload, can we have a hiring req, please".

That's the other advantage of setting up core development as clearly being
a service role for the rest of the community - it's a way to bring full or
part time paid development into the picture without generating resentment
amongst volunteer contributors, by specifically tasking the paid developers
with ensuring that roadblocks are cleared out of the paths of volunteers.

Where Tim Peters used to say "we read Knuth so you don't have to", the
ideal of paid open source development for me is "paid staff do the
boring-but-necessary bits so volunteers don't have to". (I think payment is
also appropriate for essentially "on call" roles like the security response
team)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140422/883b9af7/attachment.html>

From zachary.ware+pydev at gmail.com  Tue Apr 22 17:26:31 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 22 Apr 2014 10:26:31 -0500
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
 <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
Message-ID: <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>

On Tue, Apr 22, 2014 at 8:27 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> As I mentioned above, we aren't slow because we don't want to promote
> people, but just because the promotion only happens when a core dev
> happens to notice that someone deserving that role still doesn't have
> it (and knows how to upgrade the role).  Maybe showing the role more
> clearly (with an icon like the committer one) would make it easier to
> notice when someone is not a Triager yet.

Sorry, I didn't mean to imply that we don't want to promote people (or
that we do it slower than we should).  The only real data I have
behind my view is my own experience, where I went straight from a
plain User on the tracker to a full-blown committer with nothing
in-between and basically assumed it's pretty much the same for most.
I think I may have benefited from having the Developer role earlier
on, but I didn't want to ask for it (for fear of seeming greedy or
something) and didn't really know who should be asked, anyway.  I
think an icon showing what role people have would be a good thing; I
for one don't know how to tell who has what role (and don't know how
to upgrade someone's role, either).

-- 
Zach

From ezio.melotti at gmail.com  Tue Apr 22 18:44:49 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 22 Apr 2014 19:44:49 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
 <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
 <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>
Message-ID: <CACBhJdHyGSNNM6xegD-C3PYnpf77pxf==Dn=3visTTONU6m8hw@mail.gmail.com>

On Apr 22, 2014 6:27 PM, "Zachary Ware" <zachary.ware+pydev at gmail.com>
wrote:
>
> On Tue, Apr 22, 2014 at 8:27 AM, Ezio Melotti <ezio.melotti at gmail.com>
wrote:
> > As I mentioned above, we aren't slow because we don't want to promote
> > people, but just because the promotion only happens when a core dev
> > happens to notice that someone deserving that role still doesn't have
> > it (and knows how to upgrade the role).  Maybe showing the role more
> > clearly (with an icon like the committer one) would make it easier to
> > notice when someone is not a Triager yet.
>
> Sorry, I didn't mean to imply that we don't want to promote people (or
> that we do it slower than we should).

No need to apology, I was just pointing out why we don't promote people
more actively.

> The only real data I have
> behind my view is my own experience, where I went straight from a
> plain User on the tracker to a full-blown committer with nothing
> in-between and basically assumed it's pretty much the same for most.

Usually this should happen before, but it's easy to miss it. It's also
likely that at some point people assumed you must have been a triager
already since you were very active and didn't bother double-checking.  I
was added to Misc/ACKS after becoming a committer because everyone thought
I was there already :)

> I think I may have benefited from having the Developer role earlier
> on, but I didn't want to ask for it (for fear of seeming greedy or
> something) and didn't really know who should be asked, anyway.

IRC is good for this.

> I think an icon showing what role people have would be a good thing; I
> for one don't know how to tell who has what role (and don't know how
> to upgrade someone's role, either).
>

It can be seen from the user page, but it might require some privileges to
change it.

Best Regards,
Ezio Melotti

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

From zachary.ware+pydev at gmail.com  Tue Apr 22 19:05:25 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 22 Apr 2014 12:05:25 -0500
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdHyGSNNM6xegD-C3PYnpf77pxf==Dn=3visTTONU6m8hw@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
 <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
 <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>
 <CACBhJdHyGSNNM6xegD-C3PYnpf77pxf==Dn=3visTTONU6m8hw@mail.gmail.com>
Message-ID: <CAKJDb-NvWnNB=ZB_m6ybQoyFUmYct_vX1GGDe9gtifBj4P7O6g@mail.gmail.com>

On Tue, Apr 22, 2014 at 11:44 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Apr 22, 2014 6:27 PM, "Zachary Ware" <zachary.ware+pydev at gmail.com>
> wrote:
>> I think an icon showing what role people have would be a good thing; I
>> for one don't know how to tell who has what role (and don't know how
>> to upgrade someone's role, either).
>>
>
> It can be seen from the user page, but it might require some privileges to
> change it.

Hmmm, I'm not seeing it.  Looking at your user page, I see fields for
Name, Login Name, Organisation, Timezone, Homepage, Contributor Form
Received, Is Committer, E-mail address, Alternate E-mail, and
Associate OpenID, but nothing about Roles.  On my own page, the only
additions are password fields, though I can see in the History section
(which is only visible on my own page) "2013-11-02 10:24:29
brett.cannon set roles: User -> User,Developer".  Other non-privileged
users' pages look the same as yours to me, though if they have an
associated OpenID I have a "Drop this OpenID" button.

-- 
Zach

From ezio.melotti at gmail.com  Tue Apr 22 19:22:44 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 22 Apr 2014 20:22:44 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CAKJDb-NvWnNB=ZB_m6ybQoyFUmYct_vX1GGDe9gtifBj4P7O6g@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
 <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
 <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>
 <CACBhJdHyGSNNM6xegD-C3PYnpf77pxf==Dn=3visTTONU6m8hw@mail.gmail.com>
 <CAKJDb-NvWnNB=ZB_m6ybQoyFUmYct_vX1GGDe9gtifBj4P7O6g@mail.gmail.com>
Message-ID: <CACBhJdF7bPqTBwVx6QCuy9h7Lit56a+CZ0RmMydLEHo=4Po76w@mail.gmail.com>

On Tue, Apr 22, 2014 at 8:05 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> On Tue, Apr 22, 2014 at 11:44 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> On Apr 22, 2014 6:27 PM, "Zachary Ware" <zachary.ware+pydev at gmail.com>
>> wrote:
>>> I think an icon showing what role people have would be a good thing; I
>>> for one don't know how to tell who has what role (and don't know how
>>> to upgrade someone's role, either).
>>>
>>
>> It can be seen from the user page, but it might require some privileges to
>> change it.
>
> Hmmm, I'm not seeing it.  Looking at your user page, I see fields for
> Name, Login Name, Organisation, Timezone, Homepage, Contributor Form
> Received, Is Committer, E-mail address, Alternate E-mail, and
> Associate OpenID, but nothing about Roles.  On my own page, the only
> additions are password fields, though I can see in the History section
> (which is only visible on my own page) "2013-11-02 10:24:29
> brett.cannon set roles: User -> User,Developer".  Other non-privileged
> users' pages look the same as yours to me, though if they have an
> associated OpenID I have a "Drop this OpenID" button.
>

Apparenlty only Coordinators can see/edit it (there are a few core
devs that are also coordinators).  I don't think there are any
problems to make the roles visible to everyone, however I don't know
if there are problems to make the roles editable (if we make it
editable for developers maybe they could make themselves coordinators
by changing their role?).  Either way we could investigate it and fix
it if we need to.

Best Regards,
Ezio Melotti

> --
> Zach

From zachary.ware+pydev at gmail.com  Tue Apr 22 19:39:11 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 22 Apr 2014 12:39:11 -0500
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdF7bPqTBwVx6QCuy9h7Lit56a+CZ0RmMydLEHo=4Po76w@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAKJDb-OYsTtjKZBj=mw-4NP=bBGobb=WAB0L0F+AbEBa2_QxDA@mail.gmail.com>
 <CACBhJdHUZ1m8RNwFA9srmAsC+i7+8sOTCp2jwY4+C7yba2mBnw@mail.gmail.com>
 <CAKJDb-Oc9KESPENMgpD3JMwP8HgDvjqOgMy1KaZ7vgxrNsckqA@mail.gmail.com>
 <CACBhJdHyGSNNM6xegD-C3PYnpf77pxf==Dn=3visTTONU6m8hw@mail.gmail.com>
 <CAKJDb-NvWnNB=ZB_m6ybQoyFUmYct_vX1GGDe9gtifBj4P7O6g@mail.gmail.com>
 <CACBhJdF7bPqTBwVx6QCuy9h7Lit56a+CZ0RmMydLEHo=4Po76w@mail.gmail.com>
Message-ID: <CAKJDb-NfyBQMEXtUS6_cvFQpLh7UcgojCU6EwSjN=oS923g0Rw@mail.gmail.com>

On Tue, Apr 22, 2014 at 12:22 PM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> Apparenlty only Coordinators can see/edit it (there are a few core
> devs that are also coordinators).  I don't think there are any
> problems to make the roles visible to everyone, however I don't know
> if there are problems to make the roles editable (if we make it
> editable for developers maybe they could make themselves coordinators
> by changing their role?).  Either way we could investigate it and fix
> it if we need to.

I definitely think making roles visible to all (like the Committer
icon, not just buried in the user page) would be a good thing.  I
agree that allowing Developers to change roles has the potential for
causing more trouble than it is worth.

-- 
Zach

From ezio.melotti at gmail.com  Wed Apr 23 01:38:40 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 23 Apr 2014 02:38:40 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
Message-ID: <CACBhJdEvFRs0DQHHukmEedyscv2-=T_GbXby0c-yJzqaPMpDaQ@mail.gmail.com>

On Tue, Apr 22, 2014 at 7:06 AM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>
> I'll also suggest another related (and "controversial") idea.  People
> like to reach goals: if they address the 3 issues in their queue they
> have reached the "empty queue" goal.  Addressing 3 of the 5 issues
> isn't quite the same thing.
> I've seen this concept being exploited in three main ways:
>   1) badges/trophies/achievements;
>   2) competitions;
>   3) streaks;
> The first means that the user can get a badge because they closed
> their 10th issues, or triaged their 50th, or submitted 5 patches,
> being the first to reply on an issue for the 10th time, or whatever.
> Even if fixing 3 out of 5 issues won't make you reach the "empty
> queue" goal, maybe you can reach the "10 closed issues".  An example
> of this are StackOverflow badges (e.g.
> http://stackoverflow.com/users/95810/alex-martelli?tab=badges ).
> The second includes "leaderboards" or "awards" for being above
> average.  Examples of this are Twisted high score
> (http://twistedmatrix.com/highscores/) or charts like
> http://www.ohloh.net/p/python/contributors (at some point I was the
> most active contributor and was trying to keep my contributions going,
> but then Serhiy became a contributor... :).  Something similar could
> be done by mentioning "exceptional" results in the weekly summary
> report (e.g. people who fixed/contributed to the most issues).
> The third is about perseverance.  Every day/week you have a goal to
> meet, if you reach it you streak counter increases, if you miss it the
> counter starts again from zero.  Once you start building up a high
> count, you really don't want to miss your goal and start everything
> from scratch.  Here the goal might be close 3 issues per week, or
> something similar, and could have associate badges ("contribute every
> day for a month", "close 3 issues per week for 3 weeks in a row", etc)
>
> While I understand that probably most of the core devs would be
> against similar things, this might motivate new users and make them
> "addicted" to the tracker, while making their experience more
> enjoyable, and the example I linked show that similar things exist
> even in these environments (and not only on the micro-transaction
> based smartphone games :).  People who don't care about this
> (different people are more or less competitive) could just ignore it.
> OTOH this might have a negative side-effect if users start closing
> issues randomly just to get the "100 closed issues" badge, but this is
> not difficult to avoid.
>

See also the "Gamification" section of
https://en.wikipedia.org/wiki/Overjustification_effect#Applications .

From solipsis at pitrou.net  Wed Apr 23 01:51:23 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 23 Apr 2014 01:51:23 +0200
Subject: [core-workflow] Tracker workflow proposal
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
Message-ID: <20140423015123.5538095e@fsol>

On Tue, 22 Apr 2014 07:06:53 +0300
Ezio Melotti <ezio.melotti at gmail.com>
wrote:
> 
> I'll also suggest another related (and "controversial") idea.  People
> like to reach goals: if they address the 3 issues in their queue they
> have reached the "empty queue" goal.  Addressing 3 of the 5 issues
> isn't quite the same thing.
> I've seen this concept being exploited in three main ways:
>   1) badges/trophies/achievements;
>   2) competitions;
>   3) streaks;
[...]
> 
> While I understand that probably most of the core devs would be
> against similar things, this might motivate new users and make them
> "addicted" to the tracker, while making their experience more
> enjoyable, and the example I linked show that similar things exist
> even in these environments (and not only on the micro-transaction
> based smartphone games :).  People who don't care about this
> (different people are more or less competitive) could just ignore it.
> OTOH this might have a negative side-effect if users start closing
> issues randomly just to get the "100 closed issues" badge, but this is
> not difficult to avoid.

Not difficult how? In any gamification system, people will work towards
getting new rewards / awards, not towards making meaningful
contributions.
I think something like the Twisted high scores is acceptable (since it's
quite un-serious), but starting displaying awards will really bias how
people contribute (with a definite emphasis on quantity over quality,
IMO).

(it's the same reason I'm rather ambiguous on the whole idea of
sprints)

I think trying to ensure we actually *thank* people goes a long way
towards achieving the same goal, but without the bias.

Regards

Antoine.



From ncoghlan at gmail.com  Wed Apr 23 04:17:22 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Apr 2014 22:17:22 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140423015123.5538095e@fsol>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
Message-ID: <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>

On 22 April 2014 19:51, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 22 Apr 2014 07:06:53 +0300
> Ezio Melotti <ezio.melotti at gmail.com>
> wrote:
> Not difficult how? In any gamification system, people will work towards
> getting new rewards / awards, not towards making meaningful
> contributions.
> I think something like the Twisted high scores is acceptable (since it's
> quite un-serious), but starting displaying awards will really bias how
> people contribute (with a definite emphasis on quantity over quality,
> IMO).

While I think gamification done right is actually a good way to build
community, I also think we have a lot more fundamental issues just
smoothing the path for the people that *already* want to contribute.
For example, different people have different expectations regarding
the cycle times where their efforts will have an impact - whether they
want to make a difference in a few weeks, in a few months or in a few
years. We're actually in a position to start channelling people more
appropriately on that front, since we do different things on all those
time scales (weeks: documentation, infrastructure & core workflow
tools; months: CPython bug fixes, alternative interpreter development
and packaging & distribution tools; years: Python language design and
new feature development). Yet we don't currently make it clear that if
people "want to help improve Python", there are actually several
different ways to go about it according to their skills and
inclinations.

It's an ever-evolving process, just as the language and standard
library will continue to evolve in response to the changes in the
world around us.

> (it's the same reason I'm rather ambiguous on the whole idea of
> sprints)

For me, sprints are mostly useful from the perspective of having high
bandwidth feedback opportunities, as well as personalising the
experience of contribution in a way that isn't easy over IRC, email or
the issue tracker.

> I think trying to ensure we actually *thank* people goes a long way
> towards achieving the same goal, but without the bias.

Good metrics are actually a useful way to know who to thank, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From antoine at python.org  Wed Apr 23 11:38:58 2014
From: antoine at python.org (Antoine Pitrou)
Date: Wed, 23 Apr 2014 11:38:58 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
 <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>
Message-ID: <1398245938.2295.1.camel@fsol>

On mar., 2014-04-22 at 22:17 -0400, Nick Coghlan wrote:
> > I think trying to ensure we actually *thank* people goes a long way
> > towards achieving the same goal, but without the bias.
> 
> Good metrics are actually a useful way to know who to thank, though.

I'm talking about spontaneous thanks by a committer when someone makes a
welcome contribution, not institutional / bureaucratic thanks ? la PSF
awards. One of the strong points of our community is that it's still
rather human, despite its growth.

Regards

Antoine.



From ezio.melotti at gmail.com  Wed Apr 23 14:27:04 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 23 Apr 2014 15:27:04 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140423015123.5538095e@fsol>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
Message-ID: <CACBhJdHMV3KtkYksPJ8dqzsaD9KtvYXH+Hk395y9V=Dpe=+uZg@mail.gmail.com>

On Wed, Apr 23, 2014 at 2:51 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 22 Apr 2014 07:06:53 +0300
> Ezio Melotti <ezio.melotti at gmail.com>
> wrote:
>>
>> I'll also suggest another related (and "controversial") idea.  People
>> like to reach goals: if they address the 3 issues in their queue they
>> have reached the "empty queue" goal.  Addressing 3 of the 5 issues
>> isn't quite the same thing.
>> I've seen this concept being exploited in three main ways:
>>   1) badges/trophies/achievements;
>>   2) competitions;
>>   3) streaks;
> [...]
>>
>> While I understand that probably most of the core devs would be
>> against similar things, this might motivate new users and make them
>> "addicted" to the tracker, while making their experience more
>> enjoyable, and the example I linked show that similar things exist
>> even in these environments (and not only on the micro-transaction
>> based smartphone games :).  People who don't care about this
>> (different people are more or less competitive) could just ignore it.
>> OTOH this might have a negative side-effect if users start closing
>> issues randomly just to get the "100 closed issues" badge, but this is
>> not difficult to avoid.
>
> Not difficult how? In any gamification system, people will work towards
> getting new rewards / awards, not towards making meaningful
> contributions.

By having badges/trophies that are not easily abused.
For example having "Submit 10 patches in one day" is unrealistic and
will likely push whoever wants to get this to either hold off his
patches and submit them at once or to produce 10 poor-quality patches.
Having "Triage 100 issues" is less prone to abusing IMHO, because even
if someone is doing some extra work to try to reach the goal, I don't
think this will affect the quality of the work.

> I think something like the Twisted high scores is acceptable (since it's
> quite un-serious), but starting displaying awards will really bias how
> people contribute (with a definite emphasis on quantity over quality,
> IMO).
>

Note that I'm not suggesting this to be a pervasive thing.  On the
tracker, badges should be relegated to a specific page and won't be
visible elsewhere.  Users will be able to check their badges and the
badges of other devs and there might be a leaderboard page showing who
has the most badges or something similar.  We can also include a
section in the weekly report that says something like "Congratulations
to: John Smith for contributed his 100th patch, Jane Smith who triaged
50 issues, etc.", but that's pretty much it.

If you want to make it less game-like, we could turn this into a more
"serious" user stats page (and a global stats for the "leaderboard"
page) showing user activity, number of issues they
opened/closed/triaged/commented on/assigned to, patches contributed,
patches accepted.  Adding graphs and deltas with the previous
week/month/year, or with the average/best contributor might add
motivation and replace to some extent the need for badges, but it's
also less appealing (at least for some people).  Ohloh has similar
stats/graphs (that we could maybe embed).

> (it's the same reason I'm rather ambiguous on the whole idea of
> sprints)
>
> I think trying to ensure we actually *thank* people goes a long way
> towards achieving the same goal, but without the bias.
>

The two are not mutually exclusive :)

> Regards
>
> Antoine.
>

From antoine at python.org  Wed Apr 23 14:42:37 2014
From: antoine at python.org (Antoine Pitrou)
Date: Wed, 23 Apr 2014 14:42:37 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdHMV3KtkYksPJ8dqzsaD9KtvYXH+Hk395y9V=Dpe=+uZg@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
 <CACBhJdHMV3KtkYksPJ8dqzsaD9KtvYXH+Hk395y9V=Dpe=+uZg@mail.gmail.com>
Message-ID: <1398256957.2295.10.camel@fsol>

On mer., 2014-04-23 at 15:27 +0300, Ezio Melotti wrote:
> By having badges/trophies that are not easily abused.
> For example having "Submit 10 patches in one day" is unrealistic and
> will likely push whoever wants to get this to either hold off his
> patches and submit them at once or to produce 10 poor-quality patches.
> Having "Triage 100 issues" is less prone to abusing IMHO, because even
> if someone is doing some extra work to try to reach the goal, I don't
> think this will affect the quality of the work.

Why don't you think so?
We actually all know how easy it is to be extremely dumb at triaging,
since there has been a well-known example on the tracker (I won't
mention his name out of charity, but he thought he was being very
productive).

You should read this before you think awards (badges, trophies...) don't
have any negative effects:
http://www.joelonsoftware.com/articles/fog0000000070.html

(well, of course, the author, Joel Spolsky, is also the co-founder of
Stack Overflow... the other co-founder shortly explains his take on
gamification here: http://blog.codinghorror.com/the-gamification/ ; as
that article shows, he was solving a different problem than ours,
though: namely, that web forums usually have a poor S/N ratio)

Regards

Antoine.



From ezio.melotti at gmail.com  Wed Apr 23 14:53:39 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 23 Apr 2014 15:53:39 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
 <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>
Message-ID: <CACBhJdH=8v173MRndMY+PYKk+V9GULJBsC4X984UHKdgqTOBLw@mail.gmail.com>

On Wed, Apr 23, 2014 at 5:17 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 22 April 2014 19:51, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Tue, 22 Apr 2014 07:06:53 +0300
>> Ezio Melotti <ezio.melotti at gmail.com>
>> wrote:
>> Not difficult how? In any gamification system, people will work towards
>> getting new rewards / awards, not towards making meaningful
>> contributions.
>> I think something like the Twisted high scores is acceptable (since it's
>> quite un-serious), but starting displaying awards will really bias how
>> people contribute (with a definite emphasis on quantity over quality,
>> IMO).
>
> While I think gamification done right is actually a good way to build
> community, I also think we have a lot more fundamental issues just
> smoothing the path for the people that *already* want to contribute.

Sure, I'm just floating an idea, and this is clearly low-priority
compared to many of changes David suggested.
It's also quite a bit of work to implement it.

> For example, different people have different expectations regarding
> the cycle times where their efforts will have an impact - whether they
> want to make a difference in a few weeks, in a few months or in a few
> years. We're actually in a position to start channelling people more
> appropriately on that front, since we do different things on all those
> time scales

I never thought about it as "I want to do something that will improve
Python within a week/month/year", and I'm not sure other do.  People
work on the documentation or in the infrastructure because they can
and know how to improve them, not because their efforts will be
rewarded sooner.
The two point of confusions about timescale I see most often are: 1)
features can only go on "default", but some people expect them to be
available for the next 2.7 release too (and sometime this kills their
motivation);  2) docs are not updated in real time, so some
contributors ask "why I still see the old docs even if the fix has
just been committed?".

> (weeks: documentation, infrastructure & core workflow
> tools; months: CPython bug fixes, alternative interpreter development
> and packaging & distribution tools; years: Python language design and
> new feature development). Yet we don't currently make it clear that if
> people "want to help improve Python", there are actually several
> different ways to go about it according to their skills and
> inclinations.
>

This is very true.  I'm sure there's plenty of talented web developers
that could help out with the bug tracker.  Same goes for many other
parts of the infrastructure.  Unfortunately most of these things
happen behind the scenes and are hidden even to core-developers. (For
a long time I wanted to improve things on the (old) website, but the
fact that I didn't know where the code was, that there was no public
bug tracker for it, and that almost none of the core devs were
involved in it, prevented me to do so.  With the new website things
are better, but IMHO it would be even easier if the repo was in
hg.python.org with the others -- I understand this has other
implications though, and anyway it's getting off-topic.)

> It's an ever-evolving process, just as the language and standard
> library will continue to evolve in response to the changes in the
> world around us.
>
>> (it's the same reason I'm rather ambiguous on the whole idea of
>> sprints)
>
> For me, sprints are mostly useful from the perspective of having high
> bandwidth feedback opportunities, as well as personalising the
> experience of contribution in a way that isn't easy over IRC, email or
> the issue tracker.
>

I agree, but there is usually an expectation that as many issues as
possible should be closed during the sprint.
I think most uninformed people would consider it a failure if only,
say, 8 issues were closed during the PyCon sprints.
What they don't consider is that during the sprint people were able to
discuss better solutions, work on patches and proof of concepts, find
out how to finally get around a showstopper, and that this will
(hopefully) lead to a number of issue being closed in the following
days/weeks.  Rushing the commits to make the number higher might work
from a marketing point of view ("the sprint was successful, we closed
83 issues!") , but it has other negative side-effects.

>> I think trying to ensure we actually *thank* people goes a long way
>> towards achieving the same goal, but without the bias.
>
> Good metrics are actually a useful way to know who to thank, though.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ezio.melotti at gmail.com  Wed Apr 23 19:57:09 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 23 Apr 2014 20:57:09 +0300
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <1398256957.2295.10.camel@fsol>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
 <CACBhJdHMV3KtkYksPJ8dqzsaD9KtvYXH+Hk395y9V=Dpe=+uZg@mail.gmail.com>
 <1398256957.2295.10.camel@fsol>
Message-ID: <CACBhJdH0ZMmYH9_AV373wSS+M9Wcu6p-YKQGZCoXNjSNkVAb7w@mail.gmail.com>

On Wed, Apr 23, 2014 at 3:42 PM, Antoine Pitrou <antoine at python.org> wrote:
> On mer., 2014-04-23 at 15:27 +0300, Ezio Melotti wrote:
>> By having badges/trophies that are not easily abused.
>> For example having "Submit 10 patches in one day" is unrealistic and
>> will likely push whoever wants to get this to either hold off his
>> patches and submit them at once or to produce 10 poor-quality patches.
>> Having "Triage 100 issues" is less prone to abusing IMHO, because even
>> if someone is doing some extra work to try to reach the goal, I don't
>> think this will affect the quality of the work.
>
> Why don't you think so?
> We actually all know how easy it is to be extremely dumb at triaging,
> since there has been a well-known example on the tracker (I won't
> mention his name out of charity, but he thought he was being very
> productive).
>

There might be exceptions, but I think most of the contributors
(especially the ones promoted to triagers) would be reasonable and
won't "cheat" just to obtain a badge.
If they do, we can just tell them and/or remove their triager
privileges (or award them the "bad triager" badge :).

> You should read this before you think awards (badges, trophies...) don't
> have any negative effects:

I am myself somewhat skeptical that badges are a good way to appeal to
more contributors (see also my link about overjustification), but, as
Nick says, if we decide to do it and we do it right, it might work.
Asking new contributors if they think this would motivate them might
also give us an idea.

> http://www.joelonsoftware.com/articles/fog0000000070.html
>
> (well, of course, the author, Joel Spolsky, is also the co-founder of
> Stack Overflow... the other co-founder shortly explains his take on
> gamification here: http://blog.codinghorror.com/the-gamification/ ; as
> that article shows, he was solving a different problem than ours,
> though: namely, that web forums usually have a poor S/N ratio)
>

Thanks for the links!  The goal is indeed somewhat different, namely
appealing to new (and possibly younger) developers and having them
sticking around.  I know some core-devs that already have a
"self-imposed" goal of fixing at least N bugs per week -- badges would
propose a similar challenge to everyone and provide an easy way to
track it and a "reward" for completing it successfully.

> Regards
>
> Antoine.
>

From rdmurray at bitdance.com  Wed Apr 23 20:49:59 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 23 Apr 2014 14:49:59 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CACBhJdH=8v173MRndMY+PYKk+V9GULJBsC4X984UHKdgqTOBLw@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CACBhJdGg5Bu_N40wJ96aGE3P9WuPyBrkpe2Th7T3JF9qs_B0Qw@mail.gmail.com>
 <20140423015123.5538095e@fsol>
 <CADiSq7fzAkwM1vsOH_=kDRWrRpWMVqT1_YXU+M5KKwhasfdJTQ@mail.gmail.com>
 <CACBhJdH=8v173MRndMY+PYKk+V9GULJBsC4X984UHKdgqTOBLw@mail.gmail.com>
Message-ID: <20140423185000.18094250D5C@webabinitio.net>

On Wed, 23 Apr 2014 15:53:39 +0300, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 5:17 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 22 April 2014 19:51, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >> (it's the same reason I'm rather ambiguous on the whole idea of
> >> sprints)
> >
> > For me, sprints are mostly useful from the perspective of having high
> > bandwidth feedback opportunities, as well as personalising the
> > experience of contribution in a way that isn't easy over IRC, email or
> > the issue tracker.
> 
> I agree, but there is usually an expectation that as many issues as
> possible should be closed during the sprint.
> I think most uninformed people would consider it a failure if only,
> say, 8 issues were closed during the PyCon sprints.
> What they don't consider is that during the sprint people were able to
> discuss better solutions, work on patches and proof of concepts, find
> out how to finally get around a showstopper, and that this will
> (hopefully) lead to a number of issue being closed in the following
> days/weeks.  Rushing the commits to make the number higher might work
> from a marketing point of view ("the sprint was successful, we closed
> 83 issues!") , but it has other negative side-effects.

You might notice that I haven't issued an "N bugs closed" report for the
PyCon sprint, nor (as far as I know) was there any rushing of commits
to make the closed count higher.  There may have been some commits that
happened faster than normal, but mostly that was because there were
multiple people to review right there in one place.  We may have lost
the benefit of some "think time" letting an issue sit might have had,
but I'm willing to accept that tradeoff.

I expect many of the other issues we worked on to get closed, but to
me the significant part of that is the individual contributors seeing
their issues get closed, not the absolute count.

I may generate a report after I've gone over the whole list of bugs
looking for things to commit, but that will take a while.  Anyone
who wants to help, the list is here:

    http://bit.ly/bitesized-python-tickets

> >> I think trying to ensure we actually *thank* people goes a long way
> >> towards achieving the same goal, but without the bias.
> >
> > Good metrics are actually a useful way to know who to thank, though.

I'd like us to have good metrics, that was one of my sub-goals in the
proposal.  But as others have pointed out, we need to be careful what
we measure, because what (and how) we measure will affect what outcomes
we get.

Speaking of which, I'll see if I can go over all of the discussion and
post a summary this weekend.  But it feels like we have a reasonable
degree of agreement.

--David

From francismb at email.de  Thu Apr 24 14:16:48 2014
From: francismb at email.de (francis)
Date: Thu, 24 Apr 2014 14:16:48 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>
Message-ID: <535900B0.1070504@email.de>


> The Django project uses a development dashboard to display numbers
> like "release blockers", "patches needing review", etc:
> https://dashboard.djangoproject.com/ It would be good if there is a
> dashboard like that for CPython (by using Roundup's XML-RPC API:
> http://roundup.sourceforge.net/docs/xmlrpc.html#client-api )
>

Nice Dashboard:

+1 for this :-)


BTW. from a Non-Dev point of view:

I just would like to be able to know how far or ready is a patch for
manually review and then commit.

The precondition for the review should IMHO be that it passes all tests, 
pep8, bot-integration-tests, and that the patch still applies
without rework on the 2.7, 3.X tip(s)... (some of those step are
already doable now, but checks automation would be nice to have).


Regards,
francis



From rdmurray at bitdance.com  Thu Apr 24 18:54:10 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 24 Apr 2014 12:54:10 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <535900B0.1070504@email.de>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>
 <535900B0.1070504@email.de>
Message-ID: <20140424165411.42116250D5C@webabinitio.net>

On Thu, 24 Apr 2014 14:16:48 +0200, francis <francismb at email.de> wrote:
> > The Django project uses a development dashboard to display numbers
> > like "release blockers", "patches needing review", etc:
> > https://dashboard.djangoproject.com/ It would be good if there is a
> > dashboard like that for CPython (by using Roundup's XML-RPC API:
> > http://roundup.sourceforge.net/docs/xmlrpc.html#client-api )
> >
> 
> Nice Dashboard:
> 
> +1 for this :-)

We should definitely experiment with some formats for dashboards.
Maybe we can have more than one :)

> BTW. from a Non-Dev point of view:
> 
> I just would like to be able to know how far or ready is a patch for
> manually review and then commit.

Yes, that's part of the goal of my making the state of an issue
more fine grained.

> The precondition for the review should IMHO be that it passes all tests, 
> pep8, bot-integration-tests, and that the patch still applies
> without rework on the 2.7, 3.X tip(s)... (some of those step are
> already doable now, but checks automation would be nice to have).

Still applies is an interesting one...currently rietveld applies against
the parent revision if it knows it, and default if it doesn't, so we'd
need to add some tooling to check it periodically (or on request) against
the tip of the branches it is supposed to be applied to (2.7 and current
maintenance for bugs, default for enhancements) and report the results.

For tests, the patch has to be approved for testing by a committer even
with a patch gating system, and yes, we will want additional feedback
into the tracker about the results of the tests runs.  The interfaces
are all there, I think, to figure that out, but we'll need a bunch of
code to tie it all together.

--David

From francismb at email.de  Thu Apr 24 23:06:41 2014
From: francismb at email.de (francis)
Date: Thu, 24 Apr 2014 23:06:41 +0200
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <20140424165411.42116250D5C@webabinitio.net>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>
 <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net>
Message-ID: <53597CE1.8070406@email.de>

>
>> BTW. from a Non-Dev point of view:
>>
>> I just would like to be able to know how far or ready is a patch for
>> manually review and then commit.
>
> Yes, that's part of the goal of my making the state of an issue
> more fine grained.
>
IMHO it would also help to define what kind of work is "external" or
"internal" (from the core-dev-commiter point view). Then that external
steps should be, as far as possible, done (e.g. "ready for review",
"ready for commit") before the core-dev looks at it (she/he should just
do "internals": review, commit or reject :-)).


> [...]   The interfaces
> are all there, I think, to figure that out, but we'll need a bunch of
> code to tie it all together.
>
and python is perfect for that ;-)

Regards,
francis


From rdmurray at bitdance.com  Thu Apr 24 23:23:04 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 24 Apr 2014 17:23:04 -0400
Subject: [core-workflow] Tracker workflow proposal
In-Reply-To: <53597CE1.8070406@email.de>
References: <20140421160435.35094250CAE@webabinitio.net>
 <CAF4280KrQRw=RGT_s2BJU0n0gx22B+08UCvvnBzvb_7OSGYB9A@mail.gmail.com>
 <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net>
 <53597CE1.8070406@email.de>
Message-ID: <20140424212305.1C557250D5D@webabinitio.net>

On Thu, 24 Apr 2014 23:06:41 +0200, francis <francismb at email.de> wrote:
> >
> >> BTW. from a Non-Dev point of view:
> >>
> >> I just would like to be able to know how far or ready is a patch for
> >> manually review and then commit.
> >
> > Yes, that's part of the goal of my making the state of an issue
> > more fine grained.
> >
> IMHO it would also help to define what kind of work is "external" or
> "internal" (from the core-dev-commiter point view). Then that external
> steps should be, as far as possible, done (e.g. "ready for review",
> "ready for commit") before the core-dev looks at it (she/he should just
> do "internals": review, commit or reject :-)).

Yep, if you read it, that's what my stage structure is designed
to do.  There are only two gating points: will we fix this, and is
this committable.  Everything else non-committers can decide (though
core will no doubt chime in as we do now), and even the first of those
can be triage[*].

--David

[*] Or, as Antoine has advocated, anyone...though I worry that that will
leave people feeling like they did work for nothing if a veto on commit
comes from core later.

From techtonik at gmail.com  Tue Apr 29 13:33:09 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 29 Apr 2014 14:33:09 +0300
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid (process)
Message-ID: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>

##

When people say about workflow, they can mean
algorithm, instruction or a checklist for specific
action (level 0), set of connected actions (level 1)
or a way to organize actions (level 2).

level 0 and level 1 are rigid workflows, which is
typical for business processes of big corps, where
people are meant to replaceable.

level 2 is related to agile workflows, where actions
are not static, but dependent on many conditions
that are influencing each other and hard to
formalize. Agile workflows often take into account
personalities, habits and environment of people
involved in a process. Such workflows can be
extremely efficient, but often extremely fragile,
because they depend on specific people, time,
events and context.

##

Agile models are popular and business likes to
buzz about it, but most major corporations failed to
adopt it, because it makes projects personalized,
requires them to be open. While being open
harms profits, the biggest problem is loss of control.
That's not an issue for open source projects,
where fun is already dependent on specific people
and there are no profits, even though the process is
not always open for other reasons.

I hope that these hints may inspire people who never
tried to design a collaboration process to explore
new models of useful and entertaining environment
that are not based on known enterprise practices.
Just think about why different people don't feel fun
contributing to Python overall, who are those people,
why Python community needs them, and how you
can help them by removing obstacles.

##

Some agile workflows don't give you any instructions
at all - they just give you a set of tools that you need
to combine to get a specific task done. Tools can be
communication and collaboration tools - not only a
hammer or a piece of software. "sprint" is a tool,
"open space" is a tool. People are neither tools,
nor resources. They are lazy animals, wired on
emotions, who enjoy playing games, having fun and
excited by technology that makes things for them.
You and I is one of these species, so instead of
thinking that you're not the animal, just think about
what you'd enjoy personally, without trying to define
rules and regulations for the rest. If I like your idea of
having fun - one day I will come up to join it too.

-- 
anatoly t.

From francismb at email.de  Tue Apr 29 18:27:58 2014
From: francismb at email.de (francis)
Date: Tue, 29 Apr 2014 18:27:58 +0200
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid
	(process)
In-Reply-To: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
References: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
Message-ID: <535FD30E.5080109@email.de>

Hi Anatoly,

just curiosity about:

On 04/29/2014 01:33 PM, anatoly techtonik wrote:
> Agile models [...]
> adopt it, because it makes projects personalized,
> requires them to be open.While being open
> harms profits, the biggest problem is loss of control.

Could you please elaborate on why projects (A) get personalized,
(B) need to be open and (C) there is a loss of control?

PS: I'm just asking because from my experience cannot extrapolate
that points (it may be that my experience here is too small :-))

Thanks in advance!
francis




From ncoghlan at gmail.com  Tue Apr 29 20:39:36 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 29 Apr 2014 14:39:36 -0400
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid
	(process)
In-Reply-To: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
References: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
Message-ID: <CADiSq7cJfYXYzWJQuFWag3SQYN=+YSaG-vUpa6PdmrpnwZV+tg@mail.gmail.com>

Anatoly, if you try to be part of this project, I will leave it. Your
complete lack of empathy for the point of view of others is not acceptable
in environments I am attempting to work in.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140429/795c18ec/attachment.html>

From techtonik at gmail.com  Wed Apr 30 14:38:23 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 30 Apr 2014 15:38:23 +0300
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid
	(process)
In-Reply-To: <535FD30E.5080109@email.de>
References: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
 <535FD30E.5080109@email.de>
Message-ID: <CAPkN8xLYBpopZhwYKKZWqMQQhB-R8KrjK6F4ggdekr62tU5zzQ@mail.gmail.com>

On Tue, Apr 29, 2014 at 7:27 PM, francis <francismb at email.de> wrote:
> On 04/29/2014 01:33 PM, anatoly techtonik wrote:
>>
>> Agile models [...]
>>
>> adopt it, because it makes projects personalized,
>> requires them to be open.While being open
>> harms profits, the biggest problem is loss of control.
>
> Could you please elaborate on why projects (A) get personalized,
> (B) need to be open and (C) there is a loss of control?

(A) project get personalized, because the driving force
behind achievements is personal and even emotional,
highly dependent on people involved in the process, how
these people feel outside and inside of their working space,
and if they are able to effectively communicate

(B) openness is required to earn trust, in human systems
trust is the main asset for healthy environment. you can not
demand trust (or empathy), and being closed needs a very
good arguments to be trusted. openness is important, because
people want to act independently, and if people are not
aware of the processes that happen in other parts of the
company, they won't have confidence in what are they doing
and won't be able to optimize and seek advice when their
competence is not sufficient. closed systems often lead to
situation where people need to receive permissions too often,
and will lose the gumption soon

(C) loss of control means that stakeholders become dependent
on people.  patents, NDAs, contract obligation and CLAs -
these things exist to protect business from conflicts and
human factor. they create environment that is independent of
humans. this is the opposite of trusting people. loss of control
means that there is no central authority (person or a
committee) who is giving green light - the decision and
responsibility is taken by people who make the solution. these
makes it much more easier to do things. it is only important to
keep team to be cross-disciplinary and practicing (no pure
theorists).

> PS: I'm just asking because from my experience cannot extrapolate
> that points (it may be that my experience here is too small :-))

This is my experience of working with cross-disciplinary teams.
There is a high probability that it is highly dependent on age,
social status, region and mentality, but this is why agile workflows
were born.

From techtonik at gmail.com  Wed Apr 30 15:31:14 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 30 Apr 2014 16:31:14 +0300
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid
	(process)
In-Reply-To: <CADiSq7cJfYXYzWJQuFWag3SQYN=+YSaG-vUpa6PdmrpnwZV+tg@mail.gmail.com>
References: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
 <CADiSq7cJfYXYzWJQuFWag3SQYN=+YSaG-vUpa6PdmrpnwZV+tg@mail.gmail.com>
Message-ID: <CAPkN8xJ5puDamgStY=Y-eP2=6r+ocFcuLHH7_B4902sZ-5zWKQ@mail.gmail.com>

Hi Nick,

On Tue, Apr 29, 2014 at 9:39 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Anatoly, if you try to be part of this project, I will leave it. Your
> complete lack of empathy for the point of view of others is not acceptable
> in environments I am attempting to work in.

I don't know how to react to that considering that it is a public email.

  em?pa?thy: the ability to understand and share the feelings of another.

I don't think that you can understand and share feelings of people who are
living in a world without perspective. Note I am not saying that I am such
person, but empathy might be the last thing that these people need. If you're
not ready to contact with such people - that's ok, but requiring to erase them
from the open space that is also interesting to them is a little bit too much.

I need tools that speed up development of technology, and started with
user experience of collaborative Python support process since the day
I landed my first related edit to the Python wiki. I believe it was
several years
ago. Since then I changed few jobs, but still couldn't find one that allowed
me to dedicate more time and energy to the cause.

My braincells are not loaded with knowledge how to earn a lot of money, but
details of various core Python tools, Roundup tracker architecture, and
observations on the processes that are enough to construct a vision. The only
problem that to become a useful approach it needs more data, experiments
and a little bit different environment. I am trying to send a signal to the
subscribers of this list - don't try to solve the problem yourself - create an
environment where people will be happy to solve that problem for you. You
need more feedback from outside than you probably imagine.


> Anatoly, if you try to be part of this project, I will leave it.

There is no need for you to leave. I am already banned or moderated from
the most of Python things that were kind of important to me, and passive
aggressive style of my writing won't hold me there for long. And I also don't
want to be an annoyance if anything good is going to happen.

If you need my expertise or feedback - I am open for collaboration, or ask
Ezio - he is a good communicator and has a unique ability to filter emotions
from rationale.

From bcannon at gmail.com  Wed Apr 30 19:32:41 2014
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 30 Apr 2014 17:32:41 +0000
Subject: [core-workflow] workflow types: agile (gameplay) vs rigid
	(process)
References: <CAPkN8x+_OZ-S2fov6jg9eznB_b7z=y_ghemOb0HWs5Yc-j+13g@mail.gmail.com>
 <CADiSq7cJfYXYzWJQuFWag3SQYN=+YSaG-vUpa6PdmrpnwZV+tg@mail.gmail.com>
Message-ID: <CAP1=2W7wWdTnaZ7XtaYZFHEtT+bsCdQ1U1AHVHzBR3kJMnQ5ow@mail.gmail.com>

To give a little perspective to people who don't understand why Nick said
this: there is a history here that spans years and multiple mailing lists
that led to Nick's reaction.

I'll also reiterate the fact that this list is run under the PSF Code of
Conduct (see the footer of any email from this mailing list for the link).
 People can always email core-workflow-owner@ if they have questions.

On Tue Apr 29 2014 at 2:39:41 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Anatoly, if you try to be part of this project, I will leave it. Your
> complete lack of empathy for the point of view of others is not acceptable
> in environments I am attempting to work in.
>
> Regards,
> Nick.
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140430/4a9bc489/attachment.html>