Re: Web Platform Doc Sprint San Francisco (April 3rd)

Great work on picking TBG and getting us so far along on the migration,
Garbee.

tl/dr:  DougM recommends we start immediately but slowly with the project
management side of the tool, and think about how our project and content
systems tie together as we prepare for the next doc sprint

I strongly endorse Doug(shepazu)'s comments on the extreme benefits of
having our content system and our project system tied together.  The first
piece of this that I'm not clear on is whether we were expecting to start
creating bug reports to flag documentation issues, or are we sticking to
the flags on mediawiki and managing it all with those great new reports
that Scott is doing?  The usefulness of TBG as a way to measure and track
progress will hinge on having the work to be done trackable from TBG, so
maybe there's some RESTful thinking to be done on how to best do that.
 Similarly, Doug's question on whether/how users can create bug reports
directly from the "commenting system" depends on which commenting system we
mean, and where the bugs are getting filed.

I know that Julee and Doug and others are already planning to look at how
to move forward on the project management side.  I recommend that a small
team work through one example project (for milestones, and probably more),
and gather notes as they/we go, and then look at a template (loose term)
for how to try the next few projects.  As Julee pointed out, it's intuitive
enough (as project tools go) that we should be able to get Garbee out of
the critical path for initial engagement, and we'll be able to pass along a
shortened path forward for the next willing team.  There's too big a gap
between the generic capabilities of the product and whatever limited use
makes sense for us, for Garbee to sort through a priori, when a few us can
hash out something as a reasonable first cut, and reduce any further
second-guess configuration work for him (and help drop his stress levels
back into the sustainable range).

I also recommend we try the next doc sprint 4/3 as a project planning
exercise, at a minimum, as well as possibly creating a backlog for
participants to pull from.  I would love to see us take a crack at drafting
a workflow for getting stuff worked on and reviewed during the event, so we
could at least test it on a few willing participants.  I assume we can
balance this with the rest of the efforts to make the event inviting and
productive for new and returning volunteers (getting set up with the sites
and access tools, identifying what they might do to make the biggest or
most enjoyable difference, and then moving the web forward, with some
intelligent noting of progress, status, and individual contributions, as
the work flows).  Treating the doc sprint as a PM exercise also gives us a
way to be smart about the many fronts on which we're trying to make
progress, and try to get that picture better tied together.  It'll also
make it easier for participants to direct and focus their feedback (what
works, and what doesn't, and what's still missing), and to jump in and help
(hint -- anything we wished we'd done as prep will be sitting there as a
pullable task the next morning, for the much larger team to tackle, or at
least vote it up for next time).

DougM