[core-workflow] Tracker workflow proposal

[R. David Murray]

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