Patch Pilot report

[Martin Pool]

2009/11/30 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:
>
> <snip/>
>
>    martin> I think in practice we can get some more data by having different
>    martin> pilots do what variation they think best and then we can see what
>    martin> shakes out.
>
> +1 on having different pilots acting differently even if it sounds obvious,

It is worth saying.  If we each do what we think best and share the
data, and if we keep this project alive, I think it will make
contributing easier and more fun.

I've added the following text to <http://bazaar-vcs.org/PatchPilot> to
give some idea of what specifically is happening; I hope it
encompasses or alludes to all the variation we might want to try.

--
Tips for pilots:

 * When you're piloting, put some concentrated effort into helping
people have a good and satisfying experience contributing to Bazaar.
Just how you do that is up to you.

 * Send a brief mail before and/or after your stint, to say what
you're going to do or what you did, and how it worked out.  If you
have feedback on the review system or the process, speak up.

 * You're not obliged to deal with all the open patches.  We
appreciate what you do do.

 * You can prioritize whichever you think best achieves the goal of
helping people enjoy getting things done in Bazaar.  That might be the
newest ones, neglected patches, easy patches, or those from new
contributors.

 * You can also choose to pick up patches and get them in yourself, by
writing tests or fixing things up, or to teach/ask/encourage the
original submitter to do these things.  Do try to at least explain to
the contributor what you're going to do.

 * You can ask (cajole) others to do reviews.

 * You can keep working on patches you're involved with when your
stint ends, or you can let the next pilot pick them up.  Either way,
communicate.

 * If someone's already been asked to do particular changes to get a
patch landed, don't move the goalposts without a very good reason.

 * Check that the contributors have executed the
[[http://canonical.com/contributors|Canonical contributor agreement]].
 You can do this automatically using the {{scan-merge-proposals}}
script from [[https://launchpad.net/hydrazine|Hydrazine]] or just by
checking their membership of ~contributor-agreement-canonical through
the web ui.

 * It's good to get to a specific outcome, so that people know what to
do next, and to make this clear in both the text and formal status of
the merge proposal.  That might be: needs X specific fixes, needs Y
tests, needs another review, just needs to be merged.
--

> I agree with Robert that once you started helping on one patch
> you should keep responsibility for it.

I guess essentially I'm afraid that I'll be interrupted next week and
not finish off the patches I've touched this week.  I don't want them
going stale.  But I think commonsense will be enough, and I'm sure
you'll keep a good eye on them next week.

-- 
Martin <http://launchpad.net/~mbp/>