- From: Doug May <intuedge@gmail.com>
- Date: Wed, 20 Mar 2013 17:09:45 -0700
- To: Scott Rowe <scottrowe@google.com>, Julee <julee@adobe.com>
- Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>
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