site map, user flow, site management (connecting the dots)

Hi, Scott and Julee.

tl/dr:  At a high level, our site (content) map, and our project
structure, have to handle user and volunteer training and
communications, and policies and practices, in sync and in parallel.
Whether provided by a single integrated content management (CM) and
project management (PM) system, or by a thin add-on layer that maps
our work onto separate CM and PM systems, this high-level
functionality is key to making the whole thing coherent and
manageable, with minimal user friction.  It also results in expanded
volunteer participation, and increased volunteer productivity.

I'll review Scott's notes on how to break up and redistribute this
across multiple groups and conversations, and process it along with my
other undifferentiated content to date.  Anyone who wants a sneak peek
can wade in, and otherwise wait for the properly wrapped pieces.

(engineer's notes:)

Julee points out a legacy intention for WPD:Proposals that we need to
preserve.  On first glance, it looks like we need to extend the
"logical" page model to include the notion of intent or role to be
fulfilled (so that we're not relying on oral history for the
before_delete intercession).  This is part of what is shared or
integrated or coordinated when content management and project
management systems are tied together.

If the WPD:Projects page is to go away, then where do we envision
putting the "map" to the various projects and task forces, for both
users and volunteers who want to see what we're up to and how to
engage?  I assume that would be the destination target for anything to
be preserved from the WPD:Projects page.

There is an implicit logical structure to how we are forming (and
morphing) the projects and task forces, and in most cases, there is
both a content node (or view) as well as a project (or node or view)
related to this logical structure, along with subsets of the core team
and volunteers who have some degree of interest in, and in some
contexts some say over, what goes on in those areas.

One thing that drives the integration of content and project
management is the fact that from the user's or volunteer's point of
view, they don't want to deal with redundant and/or fragmented
permissions or communications management.  This goes big-time for us,
because we expect every volunteer to be an eventual user, and we want
many if not most of the early users to do some level of volunteer
contribution.

This "logical map" has a subset that is essentially the map to how to
choose stuff to work on at a doc sprint, and our smooth user start-up
flow to some degree will walk them through those parts of the map.  In
the process of that initial tour, or at any point down the road,
anyone should be able to jump into or out of any project or milestone
or content section, in terms of following it, understanding the local
standards and rules of engagement, and being recognized and tied to
their comments and contributions.  It's also the structure for
managing focus, promotion, community engagement, and any related
gamification, both local and site-wide.

This "overlay" on the two aspects or systems (CM and PM), can and
perhaps even should be a separate layer.  This can be relatively
small, but it has to make sure that our simplified internal conceptual
view is navigable by all, and that it mostly makes our actual
implementation (whether one system, or two, or three) invisible and
irrelevant.  The integrated "project template" then naturally includes
the little blurbs that help people choose it as volunteers and/or
observers (and eventually users), as well as links to the
corresponding content nodes and policies, including the relevant
"how-to" pieces for vols (and eventually users), in addition to
linking in the project milestones and team and tasks and policies and
how-tos.  When I opt-in (or -out) on a project or node, both content
and project systems are updated in sync.  When I launch or close out a
sub-project, the dual aspects of the implementation are initially
generated from the single integrated template, and finally torn down
(archived) as a single logical transaction.

It sounds bigger than it really is, in terms of the work and training
involved, and the payback is huge (and even larger than it would
appear from this partial justification), in terms of what levels of
participation it enables vs. the volunteer and management effort
required to enable it.

DougM


On Wed, Mar 20, 2013 at 2:41 PM, Julee <julee@adobe.com> wrote:
> Hi, Scott:
>
> Yes, I will resolve the Beta_Requirements/WPD:Project_Status issue. I'm not
> sure we'll need a beta requirements page on docs.* going forward, because
> it'll be fully outlined with great visualization on project.*.
>
> As far as renaming WPD:Proposals to WPD:Projects: The original purpose of
> WPD:Proposals was to allow anyone to post a proposal within our namespace,
> and not have to go to github or google docs or wherever. It's like a
> sketching area. I don't think we'll need a WPD:Projects area, because as
> soon as a proposal is accepted, it, and all of it's related issues, can move
> to project.*
>
> Regarding bundling these meta pages: I agree. I will be working on the site
> map, so it'll be interesting to discover more pages!
>
> Makes sense?
>
> J
> ----------------------------
> julee@adobe.com
> @adobejulee
>
> From: Scott Rowe <scottrowe@google.com>
> Date: Wednesday, March 20, 2013 2:21 PM
> To: julee <julee@adobe.com>
> Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
> Subject: Re: Organizing projects in project.webplatform.org
>
> Hi Julee,
>
> There are two documents that relate to the overall status of the project:
>
> http://docs.webplatform.org/wiki/WPD:Proposals/Beta_Requirements
> http://docs.webplatform.org/wiki/WPD:Project_Status
>
> Could you resolve the differences between these and make one document?
>
> Also, I've been gathering various WPD: pages under either WPD:Community or
> WPD:Proposals in an attempt to put some sanity into the organization of
> these "meta pages." With a lack of navigation and search, it's awfully hard
> to keep track of these if they are just created anywhere.
>
> Could you put the "Project_Status/Beta_Requirements" page under
> WPD:Proposals?
>
> I was thinking of renaming WPD:Proposals to WPD:Projects; do you think
> that's a good idea, too?
>
> +Scott
>
>
>
>
>
> On Wed, Mar 20, 2013 at 1:02 PM, Julee <julee@adobe.com> wrote:
>>
>> Hi, everyone:
>>
>> To help get project.webplatform.org finished and to get our beta work
>> fully integrated[1], I've created a proposal for how we might set up
>> projects:
>>
>> http://docs.webplatform.org/wiki/WPD:Proposals/Organizing_projects
>>
>> I'll work with Garbee to see what we can actually do with The Bug Genie.
>>
>> Please let us know what you think.
>>
>> Regards.
>>
>> Julee
>>
>> [1] http://docs.webplatform.org/wiki/WPD:Project_Status
>>
>> ----------------------------
>> julee@adobe.com
>> @adobejulee
>
>

Received on Thursday, 21 March 2013 00:10:13 UTC