Community topics workflow
Overview
This document describes the Ansible community topics workflow to provide guidance on successful resolving topics in the asynchronous way.
The workflow is a set of actions that need to be completed in order within the corresponding time frames.
Note
The following section outlines a generic scenario for a workflow. Workflows can vary depending on a topic’s complexity and other nuances; for example, when there is a mass agreement from the beginning.
Creating a topic
Any person can create a community topic.
Preparation stage
- A Committee person checks the topic’s content and asks the author/other persons to provide additional information as needed. 
Discussion stage
- By default, the discussion happens asynchronously in the topic. - A steering committee member can tag the forum post with - community-wg-nextmtgto put it on the synchronous meeting agenda.
 
Voting stage
The Committee person:
- Formulates vote options based on the prior discussion and gives participants up to one week to propose changes to the options. This step takes place one to two weeks after the discussion was opened, depending on the complexity of the topic. 
- Summarizes the options in a comment and establishes a date for the vote to begin if there are no objections to the options. 
- Starts the vote on the beginning date and establishes an end date, which is $CURRENT_DATE plus: - 7 days: simple cases 
- 14 days: maximum vote length 
- 21 days: only used in exceptional cases such as holiday seasons when the majority of the Committee are not able to participate in the vote 
 
- Labels the topic with the - active-votetag.
- Adds - [Vote ends on $YYYY-MM-DD]to the beginning of the topic’s description.
The vote always consists of two polls: one for the Steering Committee, one for everyone else. To create a vote in a topic:
Create a new post in the topic.
Click the
gearbutton in the composer and selectBuild Poll.
Click the
gearin thePoll Builderfor advanced mode.
Set up the options (generally this will be
Single Choicebut other poll types can be used).
Title it “Steering Committee vote” and
Limit votingto the@SteeringCommittee.
Do NOT set the close date because this cannot be changed later.
Results should be
Always Visibleunless there is a good reason for the SC votes not to be public.
Submit the poll (the BBcode will appear in the post):
Repeat the above steps for the second poll:
Title should be “Community vote”.
No group limitation.
Voting result stage
On the vote end date, the Committee person:
- Closes the polls if the quorum is reached, otherwise prolongs the polls. 
- Removes the - active-votetag.
- Adds a comment that the vote has ended. 
- Changes the beginning of the topic’s description to - [Vote ended].
- Creates a summary comment declaring the vote result. 
- Announces the vote result and the final decision in the Bullhorn. 
Implementation stage
No further action required
The Committee person:
- Merges an associated pull request if exists. 
- Adds the - resolvedtag.
Further actions required
The Committee person:
- Assigns a person responsible for performing the actions by mentioning them in a comment. 
- Adds the - being-implementedtag to the topic.
After the actions are done, the assignee:
- Comments on the topic that the work is done. 
- Removes the - being-implementedtag.
- Adds the - implementedand- resolvedtags.
Tools
There are a few scripts that can be used to create Ansible community announcements on the Bullhorn and similar locations.
See also
- steering committee
- Ansible Community Steering Committee 
