Cg 2012

Ian Jacobs is using this space to take notes about CG plans in 2012; see also notes from Survey 2012.

Goals

We have set expectations that after one year of experience we would make changes to the program.

• Determine the ways in which the program is and is not meeting community needs.
• Prioritize infrastructure improvements, especially to make the current system more usable, stable, and scalable.
• Review and renew resource allocation.
• Promote the program to new communities.

Objectives

• Simplify UI
  • Front end design upgrade (to improve usability)
  • Simplify join process (to improve scalability and usability, reduce staff intervention)
  • Simplify groups (to make it easier for people to find groups of interest or to check if a group exists before creating one).
• Enhance tools
  • Add user profiles
• Update policies based on experience (see below).
• Promote activity
  • Learn about transition to WG (and relation of work)
  • Reach out to stalled CGs to help them make progress
  • Develop tools to measure activity levels
• For Business Groups:
  • Deploy BG contract and billing system
  • Ensure we are carrying out BG features in a systematic way (e.g., chair connectivity)

Tactics

• Organize N Community Council meetings in 2012?
• Survey users mid-year
• Report to AC in May and November about progress of CGs
• Should we have a public campaign about experience of CGs? (e.g., after a survey)
• Press release for each BG?
• Continue to improve understanding when a community should create a WG, IG, CG, or BG.
• Blog interviews
• Quarterly requests to various groups (e.g., team, chairs, council) for target ideas
• Choose one community (e.g., designers) we really want to get involved via CGs.
• Make clear process for people to register issues and change requests (and our use of tracker).

Process

• Simplify process by removing forum, glossary. (Forum is just an operational plus). Flesh out BG process to stand alone.
• Define process for changing CG policies
  • Public+AC review
  • Need to determine clearly what changes in place v. what does not (e.g., licensing commitments).
• Chairing
  • Need more concrete chair selection algorithm; see work by Dom and Ian.
• Operational Agreements
  • There are some requirements (e.g., fairness) that currently seem like they only apply if a group writes down its operational agreements. Clarify in the policy whether these are meant to apply at all times, whether or not a group has documented operational agreements.
• Scope
  • Make a stronger suggestion for a charter scope because that makes it easier for some organizations to join.
• Business Groups
  • State clearly that the required visibility of participants + members+ team is a requirement for non-public BGs. (That is already what we do but it is not described as a requirement.)
  • Add to BG process that for BGs that operate in non-public space, people with minority objections have the right to publish them.
• Transitions to WG (see next section)
• From TPAC 2012 discussion: Greater distinction between CG and WG deliverables
  • Suggestion to rename "Final" something else
  • Suggestion for more stylistic distinction than current boilerplate.
• From Community Council discussion: drop "operational agreement" in favor of "charter".
  • Subsequent staff discussion concludes the distinction is useful.
• Wayne Carr suggestion to clarify amendments: Unless there is an operational agreement that specifies how it is amended by the group, the Chair determines the means by which the group adopts and modifies operational agreements.

Transitions to WG

• Timing
  • Do not recommend transition in order to overcome dissent within a CG over a report.
  • Helpful to inform the team on team-community-process of plans to transition
• Launching a new group based on CG work
  • Ensure CG is aware of expectations to create a WG; no surprises
  • Role of staff in drafting charter? Update template for CG transfer case?
  • Invited experts can continue to participate in WG for 6 months (per CG process)
• Taking up CG work in an existing Working Group
  • WG can take up material most easily if within existing charter scope; otherwise rechartering required.
• IPR transitions generally
  • Recommendation for securing FSA commitments from key contributors before transition
  • Team required to inform CG of any exclusion opportunities (per CLA and FSA).
• Social expectations
  • Prepare CG for comment expectations from larger community, and WG goal of consensus
  • In some cases may be more helpful to write down use cases and scenarios than concrete feature proposals.
  • Non-english language CGs and how do they relate

Starting a group

• Suggestions on w3c-ac-forum thread for a "vanilla" CG with a charter template and some optional template policies (CF Tobie Langel and support from David Singer.)
  • See Art Barstow survey suggestions (and ac-forum reminder) for what a "charter" should include to set expectations.
• Get early horizontal discussion going
• When Guide updated, point people to getting started resources
• Suggestion from Wayne Carr: Route proposals to create a new group (CG or BG) through AC Reps.
  • BGs require support from five organizations but the system does not reflect organizational support; it reflects only individual support. This would be more straightforward to verify in general if AC reps do the creation.
  • Another option is to just notify AC reps.

IPR Policies

• Groups that do not require patent licensing commitments.
  • Having tested a single type of group, Ian agrees we should allow a type that does not involve patent licensing commitments. This will make it easier to automate join requests by individuals. This choice could be made a the moment a group is proposed. However, what is the constraint that we place on such groups? That they not produce any implementable specification?
  • Note that there are two cases (1) groups that produce no specs (2) groups that produce specs that do not have new licensing commitments, such as coremob.
  • Suggest cc-by. Document clearly scenarios when this is the right option.
  • Shut down group if publishing things that require patent commitments.
  • Need to deal with group wanting to change policy mid-stream (require them to restart group)
• Group-specific IPR policies
  • Multi-licenses. We are updating the FAQ to indicate that in addition to the CLA, contributors may grant other permissions for their own contributions.
  • Allow additional sign-up agreements. For instance, one group wanted to have patent rights flow to the works of another organization (not just W3C Recs). Con: Complexity.
• Commitments by non-Member organizations
  • Make them more like Members in the following sense: as soon as a person joins a group on behalf of an org, that we treat all participants affiliated with the org as representing the org (and not as representing themselves as individuals). How do we "upgrade" the commitment for all people automatically (E.g., we need to change the sign-in so the person agrees to the upgrade later automatically) There would be a set of changes to the code (e.g, when org is in group, no more option to join as an individual if affiliated with that org).
• Disclosure obligation
  • Some people have indicated that lack of a disclosure obligation is a problem. In the past we have discussed having one but some people cite it as a high barrier to participation; they are concerned about their obligations (even if those are limited to personal knowledge).
• Contribution definition (editorial)
  • The CLA defines two states of a contribution, which I will call "potential" and "actual." A potential contribution only becomes an actual contribution when it appears in a specification within a certain time frame. Using labels to refer to the two states may help clarify somewhat.
  • Scott Peterson gives this a +1.
• FSF recognition of W3C CLA/FSA?
  • Regarding OSI recognition - these licenses are not software licenses and so there is no clear process for OSI certification of them.
• Create a per-group version of test suite contribution Grant II?
• Typo fix: issued/is sued/

Notes on actions related to inactivity

• If a group has no chair, write the list and ask them to choose one. Point them to the process requirement that there be a chair.
• If a group has no email or blog activity, send email asking if there are any obstacles to discussion.
• If a group was created more than 2 months ago AND has 3 or fewer participants AND no email discussion, then write them with a warning that we plan to close the group in 1 week unless we hear back from them.

Documentation ideas

• Create better "hello!" getting started documentation
• Give people a roadmap of how it all works. For the legal agreements, add some documentation about "what are my protections?" (e.g., contributions identified, specs identified, all the opt-outs, ...).