process improvement ideas

[Martin Pool]

sprint discussion:

A lot more bugs are getting fixed.  We had a discussion this afternoon about
some topics of concern; here are some rough notes.  If anything piques your
interest, ask and we can say more.
*
*
*vila: patch piloting*

We're not reliably sending the summary at the end of the week; maybe the
next pilot should nudge them to do so. But what is the point of the
summaries? One thing is social: just showing people we did something and
didn't forget about them.  Gives examples to other people about "what is
patch piloting"?

Don't know how many merge requests have landed?  Good if they comment about
things they worked on but did not necessarily finish.

WIP and bugs-with-patches queues are almost never touched, because they're a
lower priority than mps.  (And should be.)

jam spent about a day to get from 60 to 30 inprogress bugs: lots already
fixed, some not actually started, some started but barely anything there
(therefore to patch-needs-help etc).

Launchpad's mp management could do with some love for "needs piloting" vs
"just in progress by the upstream contributor" vs "abandoned".  mp "work in
progress" is basically abandoned, and we track live work using bugs that are
inprogress.  So, mps in wip is not a big problem.

canonical-bazaar team using kanban to keep track of stuff that's in
progress, but that doesn't cover everything.

Piloting is most useful for helping people who've just proposed the patch,
and this isn't true for most bugs with old attachments.

Launchpad can give the impression a patch is being taken care of by someone
else on the active reviews page when this isn't true.  Can be clearer during
the review what is expected from the contributor before we have to act
again.  Some reviews are not clear enough what needs to be done - should
call it out when this is noticed.

Some important bugs don't get followed up on enough.  Non-ascii filenames on
mac would be a good example; patches are pretty simplistic and would have
broken other things in other areas.  In that case the bug needs a followup
saying what kind of thing is going to go wrong so people can see what else
they ought to fix to move the patch forward.

Should do reviews off https://code.launchpad.net/bazaar/+activereviews (the
project group) which includes other projects like plugins.  Some problems
that it includes projects we don't have permission to land to, or projects
that are very experimental or abandoned.

*plan:* can put mps into inprogress; we should review and push along the
inprogress bugs; if somebody puts a new patch on a bug we should quickly
create an mp and try to take it forward from there;

*action:* set up a kanban for the bazaar project group not for the team;


*vila: switching to sphinx for real:*
*
*
pqm chroot is upgraded to something where we should easily be able to get it
installed.

"keeping doc production in core?"  kind of require the toolchain to be
supported on all platforms.  we don't _have_ to build the docs on pqm or at
install time.  only reason we haven't switched to sphinx is that we were
using pqm to enforce that the docs build, and when it was running hardy it
couldn't do this.

proposals: drop build using docutils, so then we can use sphinx-only
features like referring to other documents independent of format, which is
required to get decent Texinfo support.  also will set a minimum sphinx
required version, to 1.0.

question: does docs.bazaar.canonical.com have sphinx 1.0?  currently running
a karmic chroot; probably needs to be upgraded to lucid.

statik points out <
http://read-the-docs.readthedocs.org/en/latest/getting_started.html#import-your-docs
>

proposal: where to test doc building, and does it matter? could look at the
web doc build, or run it in babune, or just manually test them.

action: vila to cut out docutils support and require sphinx in core; clean
up the makefiles

action: maxb/jr to backport python-sphinx to lucid; install that onto pqm
and escudero

*mgz: selftest output formats *
*
*
bug 408192 <http://pad.lv/408192> about doubled-up selftest failures.

agreed: by default show failures just once as soon they occur; as a follow
on have an option to show them either only, or also, at the end.

*jr: moan about apidocs*
*
*
used to other projects that require all parameters etc to be described, and
bzrlib doesn't cover that, especially not the returns and parameters.  class
members rarely documented.  partly the culture of python which is that it's
easier to just look at the source code.  (vila says, sphinx may make it
easier to include the api docs.)  syntax is a bit confusing because it's
ReST markup but using epytext fields. somewhat amusingly the documentation
tool is poorly documented.  not really a closed loop by which people look at
the output and see if it's valid.

but perhaps apidoc structured stuff is not the best, and it's better to work
on <http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html> and
<http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html>.

experiment: require docstrings in reviews.

action: spiv to add a makefile target to make apidocs;

action: spiv to put the pydoctor build output onto docs.b.c.c

action: make the developer guide and overview easier to find in the docs (by
tweaking the index pages.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110518/a9551595/attachment.html>