Jump to content

Admin Documentation For Managing Proposed Groups

From Community Council Community Group

This is documentation related to state management of proposed CGs/BGs. Service management (e.g., adding links to GitHub repos, etc.) is done through the UI for existing CGs/BGs.

Questions? Contact the team-community-process mailing list <team-community-process@w3.org> or sysreq.

Group States

A proposed group (CG or BG) exists in one of the following states. State transitions are announced on team-community-process.

Initial
A group has been entered into the database via the cg proposal form (one exists for BGs too). The database includes a name for the group, description, and shortname. This information is not publicly available.
Proposed
The group appears in the public list of proposed groups. When changing to this state, a blog item is posted in the main blog and appears on the cg/bg home page. People can now express support for the group via buttons in the UI.
Supported
The group has been supported by the minimum required to approve the group.
Created
The group appears in the public list of current groups. Changing to this state triggers the initial creation of group tools or "services. Once a group exists, a blog item is posted in the main blog and appears on the cg/bg home page. People can now join the group via buttons in the UI.
Rejected
The group was not yet created and was rejected. It is removed from the database.

Editing Group Description, Name, Shortname

  • If you create a group then change its name later, the name of the blog does not change automatically. You need to change it manually. Note that breadcrumbs are built from the WordPress blog name, for example.
  • Requests to modify a group should be sent to team-community-process.

FAQ

What do we do when a group starts in the New state?

  • Check to see if it is spam. If so:
    • Disable the account of the person who proposed it.
    • Move the group to the rejected state.
  • Check the description (and take the opportunity to make small editorial fixes).
    • Overlap. Does it obviously overlap another group in scope? If so, consider contacting the person who proposed the group and encourage that person to join an existing effort. However, if the person prefers to maintain the group, that's ok.
    • Usefulness. Is the description useful? If not, engage with the person who proposed it and suggest that we see groups experience more success when they have a more complete description, e.g., including the scope of work, deliverables, and intended audience.
  • Once satisfied, move to the proposed state.

What do we do when a group moves to the Supported state?

  • Does the group look like it will not be producing technical specifications? In this case, check with the person who proposed the group. If the group will not require patent commitments, then get permission to add the following sentence to the description: "This group will not produce specifications." Update the corresponding checkbox in the entry for the group in the existing CGs/BGs.
  • Check the description and follow the same instructions above regarding Overlap and Usefulness.
  • Once satisfied, either move to the created state.

How do I the description of a created group?

When should we close a group and how do we do so?

From time to time (e.g., before the AC meeting) the CG team reviews groups and closes some inactive ones. See Closing_a_Community_or_Business_Group and the Community Groups Activity Dashboard tool.

What if a person who proposed a group does not reply to suggestions?

After a reasonable amount of time (e.g., a month), move the group to the rejected state.

Can the Team create a group directly (without going through the public form)?

No; ask sysreq if necessary.

How do I delete a user (e.g., who has proposed a spam group)?

You should also "reject" the spammy group.

Retrieved from "https://www.w3.org/community/council/wiki/index.php?title=Admin_Documentation_For_Managing_Proposed_Groups&oldid=1006"