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

Thank you for your comments, Doug.

Please be aware that the final design of the Getting Started page is far
from complete, and I suggest that you revisit it when I have something to
show the list. The only reason I mentioned it in an earlier thread was to
give fr0zenice and PaulR a point of reference for the use of their
user-defined query forms.

+Scott



On Thu, Mar 14, 2013 at 8:38 PM, Doug May <intuedge@gmail.com> wrote:

> 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.
>>>>>
>>>>>