Governanceď
The governance of the Nextstrain project is relatively informal. The structure and processes that do exist are briefly described below in the interests of transparency.
Organizational structureď
- Project Leadsď
The Project Leads are the two co-creators of Nextstrain:
The Project Leads have the authority to make all final decisions for the project. In practice, the Project Leads usually choose to defer that authority to the consensus of the Core Team.
- Core Teamď
Active and substantial contributors to Nextstrain including Project Leads who have enough context on the project and its components to contribute to decision-making.
See the Nextstrain team page for a full list of members.
- Scientific Advisory Boardď
The scientific advisory board provides guidance on future directions. See the Nextstrain team page for a full list of board members.
- Community Contributorsď
Occasional contributors including those from Bedford Lab, Neher Lab, alumni, or other external groups. Influences decision-making but does not directly participate in it.
Decision-makingď
Nextstrainâs decision-making process seeks to balance broad participation of stakeholders with agility. The following list of decision-making approaches is in order from most to least preferred.
- Seek consensus from the Core Team.
Alert the team about major changes (e.g., via Slack) or to request feedback (e.g., via Slack or GitHub reviewer requests).
Allow enough time for team members to review and register feedback before finalizing a decision.
Summarize the consensus decision publicly (e.g., on a GitHub PR or issue).
Alert the team that a consensus has been reached on major changes (e.g., via Slack or GitHub).
For critical, urgent, or stalled decisions, arrange a synchronous meeting to review available options and attempt to reach a decision during the meeting (e.g., biweekly Nextstrain meeting or a special topic meeting).
Minimally, seek consensus with at least one other Core Team member who is familiar with the context.
- Hold an informal vote to gauge opinion on difficult or subjective decisions (e.g., naming).
Hold votes publicly (e.g., vote with thumbs up or down on a GitHub comment).
Allow enough time for team members to vote.
Summarize the vote and ask for concerns (e.g., vetoes).
- Bypass consensus with a decision by a single Core Team member who has expertise in the matter at hand.
Use for uncontroversial decisions or decisions on matters where the Core Team lacks expertise or strong opinions.
Provide the Core Team an opportunity to register their lack of a strong opinion. Err on the side of âover-communicatingâ to the team (e.g., âthis will be merged on Tuesday if there are no objectionsâ).
Document the final decision publicly.
- Request tie-breaking or overruling vote from Project Leads.
Use as a last resort when consensus cannot be reached for critical and/or time-sensitive decisions.
Code reviewď
Our practice of code review (internal doc) often informally triggers a request for a decision from the Core Team. The informal nature of this process can result in a lack of feedback from the Core Team causing the corresponding Pull Request (PR) to stall on review without conclusion [1]. The stalling means the people involved in the PR (author and reviewers) have spent time on something thatâs now in an ambiguous state of âreviewed, needs more workâ and is effectively blocked indefinitely. Both PR authors and other team members can benefit from a more concrete decision of:
Yes, this should be pushed to finish soon while itâs fresh in our minds.
No, letâs close this and label it as âshelvedâ, reserving the option to re-open later.
We use the decision-making process described above to break a deadlock or move forward on a stalled PR.