THIS DOCUMENT HAS NO STATUS. Contact Ian Jacobs with questions.

High level goals

Promote introduction and discussion of new ideas
Model a progression through:
- Very informal discussion
- Informal but focused community group
- Formal standards working group
- De jure standardization (via ISO)
@@Add a table comparing community group, incubator group, working group characteristics@@
The progression includes
- Increasing (patent licensing) commitments. @@The PSIG will help define the progression@@. For instance, disclosure, then individual, then organizational.
- Increasing stature by virtue of review and support by broader community, as well as imprimatur of recognized open standards process.
- Increasing awareness by others in the community of the work.
Make Transitions on the progression easy. For instance, from discussion to community group, and from community group to Working Group. It is expected that the proposal will make it easier to start a Working Group when one has been through a community group (than when one has not).
Infrastructure is important so that work and communications happen smoothly and easily. E.g., modern specification annotation tools, discussion fora, 1-step join processes, and simple interfaces for automatically creating group subsites.
Mentoring and story-telling become even more important Team roles: working with select people (e.g., community group chairs) to explain process, create better documentation on operational good practices, tutorials/videos on how to write a standard get through the process, etc.
Renew trust in W3C (including the staff) as an effective forum for work, and as stewards of Web technology.

Other Considerations

Revenue questions
- Balance value of increased participation with loss of some revenue. Increased participation increases likelihood of some new Members (after what amounts to a liberal trial-period)
- One idea was to distinguish the cost of participation from the cost of organizing a community group. Sponsorships?

Open Forum for Ideas

Open discussion venue (mailing list or better, e.g., peer reviewed discussions)
Very lightly moderated by staff (to avoid offensive material)
Submission process (karma required to publish?). Licenses?

Managing list behavior

Must be clear abot behavior expectations. Self-moderating?
Traffic may become so heave people want another list. Is that an option?
At some point can we stop discussion on a topic? What if they don't want to create a community group?

Community Group

Discussions reaching a certain karma level may move to a community group. Karma power varies (e.g., Team, AC Reps, Chairs have a lot).
- See alternative of "outposts trust" in the outposts proposal. The trust has non-team in it.
- So the question is whether to have a dedicated group keeping an eye on things, because otherwise we are broadening the approval process to the community in both cases.
It's easy to set up a group (push a button, get a wiki, mailing list)
Anyone may participate at zero cost, but must follow COI policy (for later work in getting organizational licensing commitments).
Licensing commitments (patent, copyright)
Relationship to IG? Relationship to just a mailing list?

Questions:

What defines the "existence" of a community group? Level of activity? (how is that measured)?
By extension, if defined by level of activity, presumably it closes when inactive. Can it be closed sooner (e.g., by karma)?
Is a chair necessary? Is it necessary to have a spokesperson for the group (e.g., to request early closure, or manage a transition)?
- Notes: It would be good to have some individual familiar with W3C process in the group (called "watcher" in the outposts proposal). But the group may not hold meetings, and they may make decisions in a way that doesn't require a chair.
- Could make certain privileges available when there is a chair (e.g., if there is a responsible person, then group can use phone bridge).
Is a charter necessary?
- Notes: Minimal description of intended scope probably useful, but may be as simple as mentioning a document people are working on).
reporting requirement?

Transition to WG

One transition path: community group hands off work, closes
Another transition path: community group asks for snapshot to be published, but continues
Another transition path: community group does not hand off work, just continues.

Working Group

Requires a charter, but the charter will be mostly boilerplate so easy to create ("standardize this spec")
Participants in the Community Group will be permitted to participate (as Member employees or invited experts). However, in order to ensure safe licensing around the specification, there may be some constraints. For instance (draft!!)
- You can't participate until your organization(s) make RF commitments, or
- The WG can't publish until all organization(s) associated with the Community Group have made RF commitments

Infrastructure

Communication

IRC, bots
- Will community groups have bridge access?
Mailing lists with public archives (spam-controlled)
blog, microblog?
feeds
discussion fora (with important threads emphasized, prioritized)

Publishing/Editing

public wiki
more than cvs (cvs, git, svn, ...)

Reviews/Comments/Tracking

spec annotation (e.g., send comments from area of spec, display status of comments, status of implementation or consensus, etc.)
tracker, bugzilla

Group decision-making

voting system
group membership management (dbwg)

Code development

sandpit?
test framework?
tools for code development (cf. hudson, maven, etc.)

Notes

community [relation to consensus, trust], quality [participation, review, testing, etc.], usability [infrastucture, simplicity of process, clarity of communications]

Goals
Table comparing characteristics (Forum, Community Group, XG, IG (list or more), WG), value proposition, barriers lowered
Transitions (part of table)?
Infrastructure
Template will reference proposal and answers to questions will be about specific parts of the proposal.
in messaging, where there are obligations, point out that community (notably staff) there to help you fulfill them.