Review of "Subgroup Lifecycle at Advisory Groups Policy"
[UPDATED June 23, 2021 during CAG meeting]
Here is a new draft, that incorporates some feedback, but probably not all. Please respond with comments and suggestions.
Subgroup Lifecycle at Advisory Groups Policy
1. Subgroups
Advisory Groups may establish subgroups to focus work on specific topics. This policy outlines requirements and best practices for healthy and sustainable subgroups.
Types of Subgroups:
- Project: formed to create a specific deliverable; limited term but can be extended
- Standing subgroup: needs an ongoing purpose
1.1 Forming subgroup
Before establishing a subgroup, an advisory group needs to ensure the need for a separate subgroup and the commitment from potential subgroup members.
- When more work is needed than can be done as part of the advisory group, start with informal meetings to advance the topic
- Have discussions about the topic for the subgroup within the advisory group
- Before forming a subgroup, the following conditions need to be met:
- 3+ volunteers engaged consistently in informal meetings and commit to continue engaging after subgroup is formed
- An elevator pitch was created that describes the goal of the subgroup
- In the process of creating the subgroup:
- A GitLab group is created for the work of the subgroup (TODO: we might want to create a template for a subgroup)
- A regular meeting schedule is established and calendar invites are sent out (TODO: currently we require a Leadingbit employee to open the room of a meeting and start the recording)
- A Mattermost channel is created for the subgroup
- A subgroup leader and co-leader are appointed
1.2 Maintaining subgroup
A subgroup should have sustained efforts to advance its topic.
- The lead and co-lead are responsible for:
- Facilitating regular meetings and saving meeting minutes
- Reporting to the advisory group on progress and blockers
- When regular attendance at meetings drops below 3 volunteers
- Lead and co-lead may consider how to get more engagement (e.g., encourage asynchronous engagement, reduce frequency of meetings, change time of meeting to accommodate volunteers who could make it at a different time; recruit new subgroup members)
- Lead and co-lead may consider taking a hiatus or disbanding the sugroup
- When lead or co-lead become inactive or unresponsive, they vacate their position
- A first approach is to try reaching the volunteers to understand why they are absent and whether they'd be coming back
- As long as either lead or co-lead are active, they can find a replacement for the vacant position
- When lead and co-lead are inactive or unresponsive, the subgroup is without leadership
- Other subgroup members may step up to assume leadership position
- The advisory group, that the subgroup belongs to, may appoint a new lead and co-lead
1.3 Taking a hiatus
Subgroup volunteers may decide to put the work of the subgroup on hold, for example during summer vacation time or Christmas and New Years celebrations.
- A Subgroup that goes on hiatus has to inform the advisory group about its "hiatus" status and when work is planned to resume
1.4 Disbanding subgroup
Subgroups may be disbanded for a variety of reasons, including:
- The subgroup, especially project, reached its original goal and is no longer needed
- Engagement in the subgroup is too low to sustain work and no further attempts are planned to revive the subgroup
Dispanding a subgroup involves:
- Informing the advisory group that the subgroup plans to disband and coordinating following steps
- Ideally, provide a report to the advisory group about the progress made by the subgroup and reason for disbanding it
- Delete or archiving its Mattermost channel
- Delete the standing calendar invite
- Archive the GitLab organization, add a notice on all READMEs