From Fedora Project Wiki
m
Line 17: Line 17:
  
 
The Modularity WG has two "modes," one, a traditional WG which sets the direction of the project and reviews progress. Second, an active development team made up of all aspects of software engineering from architecture, to QE, to release engineering.  
 
The Modularity WG has two "modes," one, a traditional WG which sets the direction of the project and reviews progress. Second, an active development team made up of all aspects of software engineering from architecture, to QE, to release engineering.  
 +
 +
==== Modularity Strategy ====
  
 
The direction setting "mode" reflects that Fedora is a global project and will have regular IRC meetings. In general we will conduct business on the mailing list or announce either IRC meetings or Google+ hangout events in advance should they take place.
 
The direction setting "mode" reflects that Fedora is a global project and will have regular IRC meetings. In general we will conduct business on the mailing list or announce either IRC meetings or Google+ hangout events in advance should they take place.
Line 23: Line 25:
  
 
For bigger issues, where there may be disagreement within the Modularity Working Group itself where the necessary quorum is not reached (with 4 members being required for quorum,) or where there is long-term impact, or where an action may not easily be undone, we will schedule an IRC meeting during which a vote will be conducted. In the case where a voting member can not make a meeting, they can either pre-vote via the mailing list or abstain-by-default. Four positive votes will be required, regardless of the number of voting members present, for a proposal to be accepted.
 
For bigger issues, where there may be disagreement within the Modularity Working Group itself where the necessary quorum is not reached (with 4 members being required for quorum,) or where there is long-term impact, or where an action may not easily be undone, we will schedule an IRC meeting during which a vote will be conducted. In the case where a voting member can not make a meeting, they can either pre-vote via the mailing list or abstain-by-default. Four positive votes will be required, regardless of the number of voting members present, for a proposal to be accepted.
 +
 +
==== Modularity Development ====
  
 
=== Changing these Rules ===
 
=== Changing these Rules ===

Revision as of 12:37, 7 April 2016

Modularity WG Governance

This document describes the governing structure for the Modularity WG.

Membership

The Modularity Working Group has seven (7) voting members. However, we would like as many people to participate as possible.

Each voting member of the working group will confirm their continued membership every six months. In the event that a current voting member relinquishes their seat, the remaining voting working group members are responsible for appointing a new voting member to fill the seat from the active Fedora Server community via majority consensus.

Current Members

  • Langdon: Objective Lead and Council Member
  • 6 Open Seats

Making Decisions

The Modularity WG has two "modes," one, a traditional WG which sets the direction of the project and reviews progress. Second, an active development team made up of all aspects of software engineering from architecture, to QE, to release engineering.

Modularity Strategy

The direction setting "mode" reflects that Fedora is a global project and will have regular IRC meetings. In general we will conduct business on the mailing list or announce either IRC meetings or Google+ hangout events in advance should they take place.

The Modularity Working Group strives to work on consensus and only vote on things where it’s clear people aren’t going to be convinced to agree. Many of our decisions can be made through "lazy consensus." Under this model, an intended action is announced on the mailing list, discussed, and if there is no controversy or dissenting views with a few days, simply done.

For bigger issues, where there may be disagreement within the Modularity Working Group itself where the necessary quorum is not reached (with 4 members being required for quorum,) or where there is long-term impact, or where an action may not easily be undone, we will schedule an IRC meeting during which a vote will be conducted. In the case where a voting member can not make a meeting, they can either pre-vote via the mailing list or abstain-by-default. Four positive votes will be required, regardless of the number of voting members present, for a proposal to be accepted.

Modularity Development

Changing these Rules

This document will be approved by consensus of the initial Modularity Working Group members and approved by Council. After initial ratification, any substantive changes can be approved by majority vote and sent to Council for acceptance.