[core-workflow] Tracker workflow proposal

[Ezio Melotti]

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