Skip to content

Latest commit

 

History

History
137 lines (100 loc) · 6.68 KB

GROUPS.md

File metadata and controls

137 lines (100 loc) · 6.68 KB
Raw

CDF Working Groups and SIGs

This document proposes a process for managing the lifecycle of working groups in the Continuous Delivery Foundation.

Working Groups

Definitions

A Working Group is defined as a temporary group of collaborators focused on completing a defined task. Examples of these could include:

  • Authoring and publishing a white paper on a specific topic.
  • Migrating a piece of legacy infrastructure to a new system.
  • Researching and defining cross-CDF project policies.
  • Planning and hosting an event.

Durations for a Working Groups should be <6 months, although extensions can be granted by the TOC for efforts that are making forward progress but need more time. Longer term efforts are out of scope for the working group system, and should be handled by the SIG system.

Creation

To propose a working group, create an issue with the following information:

  • A CDF TOC Sponsor willing to monitor progress against exit criteria.
  • A proposed timeline toward reaching this criteria.
  • Exit criteria, including details on the tasks or deliverables.
  • A list of initial members, and a chair. There should be at least 2 different companies represented.
  • Any resources needed from the CDF to accomplish the task. This can include funding, marketing, technical expertise or other resources. Note that some types of resources may require allocation from the Governing Board.

Approval of the Working Group is intended to be a lightweight process, requiring only a TOC Sponsor and one additional vote. A proposal should be submitted in the form of a GitHub issue, and approval comes with two LGTMs from TOC members.

Ongoing Process

The Sponsor must take an active role in understanding the exit criteria, monitoring the group against it and ensuring forward progress continues.

The WG is expected to send out updates to the TOC mailing list at least quarterly.

The Sponsor must escalate any issues quickly to the TOC for assistance. Potential issues include a lack of resources, lack of funding, decision making or other.

The Chair must escalate if the Sponsor is not able to meet these commitments while a Working Group is in session.

Interaction

Working Groups receive the following from the CDF:

  • GitHub organizations or repositories to track work.
  • Funding and other resources specified in the proposal and allocated by the relevant groups.
  • Email lists, chat groups or other communication channels. Groups.io naming convention for email lists e.g. [email protected]
  • CDF provides governance rules such as Code of Conduct.

The Working Group is disbanded under the following conditions:

  • Exit criteria are met.
  • The Sponsor decides the Working Group is no longer required or effective.
  • The initial timeline has expired, and no extension has been granted.

SIGs

Definitions

A Special Interest Group is defined as a long-term group of collaborators interested in a specific theme, within the scope of the CDF. Examples of these could include technical areas like:

  • Security
  • Compliance
  • Productivity
  • Or other areas related to running the foundation, like:
    • Event Planning
    • Project Infrastructure

SIGs should meet regularly, with no defined lifetime.

Creation

Recurring meetings, especially in a large foundation and across companies are expensive. Proportional care must be taken in establishing long-term recurring meetings to ensure they are scoped correctly and have the required interest to remain productive for everyone.

To propose a SIG, create an issue with the following information:

  • A brief (1-2 sentence) overview of the SIG charter.
  • A CDF TOC Sponsor willing to regularly monitor the SIG and ensure it remains useful and productive
  • A proposed meeting schedule, with a sample agenda
  • Details on any outcomes, or deliverables
  • A list of initial members, and a chair. There should be at least 3 different companies represented
  • Any resources needed from the CDF to accomplish the task. This can include funding, marketing, technical expertise or other resources. Note that some types of resources may require allocation from the Governing Board.

Approval of the SIG is intended to be a more heavyweight process, requiring a majority vote from the TOC. A proposal should be submitted in the form of a GitHub issue, and a vote is conducted following standard TOC procedure.

Ongoing process

The Sponsor must take an active role in understanding the desired outcomes of the SIG, and monitoring the recurring meetings and communications.

The SIG is expected to send out updates to the TOC mailing list at least quarterly.

The Sponsor must escalate any issues quickly to the TOC for assistance. Potential issues include a lack of resources, lack of attendance, or other.

The Chair must escalate if the Sponsor is not able to meet these commitments while a SIG is in session.

The SIG should rotate chairs at least bi-annually to ensure neutral leadership.

Interaction

SIGs receive the following from the CDF:

  • GitHub organizations or repositories to track work.
  • Email lists, chat groups or other communication channels. Groups.io naming convention for email lists e.g. [email protected]
  • Infrastructure for recurring meetings
  • CDF provides governance rules such as Code of Conduct.

SIGs can make regular requests for resources from the CDF TOC, including funding, marketing or technical expertise, and project or technical infrastructure.

The SIG is disbanded under the following conditions:

  • The SIG is no longer required or relevant. It has accomplished all desired goals.
  • The Sponsor decides the Working Group is no longer required or effective.
  • Attendance consistently drops below the requirement of 3 participating companies, as assessed by the sponsor or TOC.

SIG Onboarding Checklist

This is the checklist for new SIGs

  • Create GitHub repo
  • Create GitHub team for the sig (cochairs should manage the team)
  • Create slack channel (or rename existing channel to reflect sig name)
  • Create groups.io mailing list
  • SIG co-chairs to get access to CDF calendar to modify events
  • Create SIG playlist on Youtube
  • Announcement blog post/press release
  • Recommend scheduling a podcast: https://cd.foundation/podcast/

SIG Archival Checklist

  • Archival must be agreed upon by the TOC
  • Move the SIG markdown in this repo from sigs to sigs/archived
  • Move the SIG in the README.md from "current sigs" to "archived sigs"
  • Archive the GitHub repository (from the repository settings)
  • Archive the Slack channel
  • Archive mailing list
  • Remove access to the calendar for SIG co-chairs (unless they may keep because of other roles)