Closing a Community or Business Group

From Community Council Community Group

< Community Council

Determining Which Groups To Close

Out experience suggests this approach for closing inactive groups.

Preparation

  • Create a plan with timeline (example)
  • Create a candidate list (using list-closure-candidates.js) and send to team-community-process.
    • Review previous candidate list and rationale for not closing a group, or notes about checking back on a group that we allowed to to remain open.
  • Create a spreadsheet to track feedback on the list (spreadsheet). In particular, track requests (from groups, team, or others) to stay open and explicit requests to close.

Communication

  • Request review of the list by Team (allow 1 week; see sample email to Team))
    • Is there a relationship between the work of a CG and Working Group(s)? Be sure to reach out to staff contacts of those Working Groups to understand the landscape.
    • Suggest to the CG that it organize a call for Final Specification commitments.
  • If (1) a group was inactive during the previous iteration and (2) the chairs (or others in the group) requested that we keep the group open and (3) our tool indicates that it is still inactive, reach back out to the chairs to indicate that the group appears to still be in active, and ask them for an update on activities. Allow a week for replies.
  • Notify candidate groups of the plan (allow 30 days; see email template for first-time candidates and email template for repeat candidates).
    • The JSON data in the candidate closure list includes the group name and home page link, which can be used to draft mail to the group. The group's mailing list can be derived from the group's home page URL (same public-shortname@w3.org). Ian uses mutt for merging data into a template and mass mailing.

List of Groups to close

  • Allow at least 30 days for discussion before closing groups.
  • Create a new candidate list (using list-closure-candidates.js). This new candidate list may differ from the original candidate list for several reasons: (1) some groups may have become active as a result of discussion, or (2) tooling has improved and therefore is detecting activity that previously went undetected.
  • Close these groups:
    • Groups where Chairs or others said it was ok to close.
    • Groups that did not response to outreach regarding closure and remained inactive.
    • Groups that responded to outreach but did not provide solid rationale for remaining open.
  • Don't close these groups:
    • Groups that became active as a result of outreach.
    • Groups that asked not to close at this time and provided solid rationale.
    • Groups that asked for a bit more time to make a decision (e.g., they have an upcoming meeting and will make a decision there).
    • Groups whose nature suggests we should not close them (e.g., Web History CG is long-lived; some CGs may be related to MoUs).
    • Groups that the tooling suggests have become inactive since the outreach over a month ago.
  • Send the the list of groups to close and not close to team-community-process (example), along with other data to support that computation (e.g., link to the spreadsheet with feedback, list of groups that requested to close, the newly computed candidate list).
  • After confirmation (e.g., Dom confirms Ian's computation), ask the Systems Team to close groups.

Example code

Using the candidate lists and feedback from discussion, create these files (each file is a series of lines of the form "Web Tech" where that is the name of a CG; no blank lines):

  • orig.txt: Initial candidate closure list.
  • updated.txt: Updated candidate closure list.
  • asked-to-close.txt: List of groups where the chairs requested or accepted closure.
  • agreed-to-keep-open.txt: List of groups after discussion where the staff has agreed to keep the group open.

Then generate the results as follows: 

comm -12 <(sort orig.txt|uniq) <(sort updated.txt|uniq) > tmp.txt
comm -23 <(sort tmp.txt|uniq) <(sort agreed-to-keep-open.txt|uniq) > tmp2.txt
cat asked-to-close.txt tmp2.txt | sort | uniq > to-close.txt

Implementation

  1. Look for the group in our DB:
    1. Start with the Community Group manager or Business Group manager
    2. search and query
    3. Search for and open the group (save for #4 and #5)
  2. Update the mailing lists archive headers:
    1. Use the mailing list customizer
    2. Syntax to customize a CG/BG mailing list: https://lists.w3.org/admin/customize?list=public-multi-pos
    3. todo for public-groupid, public-groupid-contrib and internal-groupid
    4. In "header of the archives" and "description of the archives":
      1. s/is/was/
      2. Remove "Anyone may read or write to this list." or "Only group participants may post to this list."
      3. Add: "Group closed YYYY-MM-DD."
    5. Update each.
  3. Close (deactivate) the Group's mailing lists (there is a daily cronjob that automatically deactivates the mailing lists for closed CG):
    1. Click the "services" link in the Community/Business Group State Manager
    2. Click "List Management" for each of the group's mailing lists
    3. todo for public-groupid, public-groupid-contrib and internal-groupid
    4. Click "deactivate this list" for each.
  4. If there is a repo is hosted in w3c or w3c-cg:
    1. If there is published web content (e.g. a CG report), mark it as discontinued
    2. Update the readme to indicate the CG has closed and the repo is archived
    3. Archive the repo
  5. If there is CG content hosted elsewhere, encourage the CG chairs to clarify status
  6. Close the Group:
    1. Use the group page in the admin
    2. Set the closed date field to the day of closing
    3. Click "Update"
Retrieved from "https://www.w3.org/community/council/wiki/index.php?title=Closing_a_Community_or_Business_Group&oldid=1010"