Re: Re-architecting the Community pages (smoother inflow for the next doc sprint)

tl/dr: DougM noticed the great new "getting started" page could provide a
smoother flow for noobs, and suggests a separate upgrade before the 4/3 doc
sprint, also touching on multiple task team agendas in the rambling process

Just looking over user:Scottrowe/test (upgraded "getting started") in more
detail.  For a doc sprint, as a new participant, I notice that I leave the
page in the first paragraph, for one immediate reason (get hooked up), and
one premature reason (to find out how to do the thing I'm going to pick
later, when I loop back through the "getting started" page).  For a sprint,
and maybe even for general new-user trickle-in or event-driven signups, I
think we need a short path through getting hooked up (with options if you
decide you really want to install your first IRC client).  We smooth out
the test page by adding something like "first, you'll go [here], to get
hooked up, and that will typically take you 15-45 minutes" (if they only
see that on the projector, they maybe don't even have wifi working yet),
and it would be good to invite new people to time it for us (like a simple
checklist they pick up at checkin).  "Then you'll come back here and pick
out what kinds of work you want to take on today, and then you'll go [here]
to get detailed instructions for your chosen task."   Probably better to
route people to instructions and help directly from the selection matrix,
rather than having to sync up their context manually.

Also good to point people toward the "getting hooked up" page in the reg
process, and have most of them arrive already hooked up, and possibly
already self-screened for their slots in the tech/skill/layer/stage matrix.
 It would certainly make prepping the backlog easier.

Can't tell where/how to draw the line on all this, but it seems like from
the moment volunteers arrive, they should have access to get going forward
from wherever they are -- "welcome; grab some coffee or breakfast; get your
wifi working; get hooked up if needed; start picking your targeted kind of
work for the day, or kick back and wait for intros and coaching".  No
waiting for the slide to come around again (but yes, put it on the
rotation), but an obstacle-free starting lane from the moment they arrive
(hardcopy signage, qr codes, and a really short and easy link, maybe
already on their nametags so they all have it).

I believe that community recognition, doc sprint dashboard, and possible
gamification, are on the agenda between now and 4/3, courtesy of the task
force(s), but I mention here that we want all that included in our thinking
from the confirmation through the checkin flows, so that people are aware
of what's up, and exposed to the progress display, and invited into
anything we're trying out or pushing (edit-review flow vols, anyone? think
checkboxes on the quickstart self-timer page).  A bit of forethought will
help the whole project come across as serious about large-scale volunteer
engagement (easy in, easy to make a serious difference, and we listen to
feedback and adjust).  Especially for the 4/3 post-h5devconf event, we
should have a pull list for unicorns, rock stars, etc., with a few of our
gnarliest wishes (a successful game has escalating challenges that don't
top out prematurely).  If we don't have a recruiting poster for the
template corps, we might miss our next volunteer of the year (fr0zenice is
ineligible, right, after winning last year?).

Sorry for the rambling brain dump -- this probably should have been sent in
smaller pieces targeting specific task forces, but I'm not clear on how we
prep for a doc sprint, so my brain is dumped for the picking, no matter who
meets when.

To connect the last dots, my recommendation on using the 4/3 sprint as an
early test of the TBG project management tools parallels this.  We can have
milestones and tasks related to several of the task forces, which helps us
make sure we 're not too fragmented or overwhelming the vols, and we make
the whole process way more transparent to everyone at the sprint.  That
makes it easier for them to provide targeted feedback (if we set a goal for
smoother intake, we have tasks on which we can get comments).  It also
feeds the wonder woman list, since whatever we target in prep and fail to
complete will be right there for someone to pick up at the event.  In fact,
I'd love to seed every task list with whatever we think would be next for
our area, just so we don't run out of track at the sprint.  The more
variety and relevance we offer the vols, the more likely they each find an
enthusiastic fit, and the movement grows and accelerates.  It also hints at
a roadmap, and helps them target their next engagement after the sprint.

It would be great if we got some new kinds of activity happening between
sprints, so maybe we target an area or group for each sprint, so we have a
pipeline (only try one new thing at a time, and apply the lessons learned
through each cycle as we ramp up one flow after another).  We'd
incrementally develop the templates and processes as we learn and tweak the
system.  What's most ready to go -- some kind of edit review?  Not sure we
start this 4/3, but we have to be getting close to that level of
infrastructure and momentum, so something to think about soon.

It would be cool to start lining up Design sponsors for some of the doc
sprints, and have little groups that just tackle look and feel on the site
itself, in each sprint.  Makes it more interesting to come back time after
time, and makes the progress more obvious than just a thermometer climbing.
 Is that covered by an existing task force?

DougM


>>> On Thu, Mar 14, 2013 at 2:34 PM, Julee <julee@adobe.com> wrote:
>>>
>>>> Hi, Scott:
>>>>
>>>> For task forces, we should figure out what we track on
>>>> project.webplatform.org vs. what we track on webplatform.org.
>>>>
>>>>