From Fedora Project Wiki
(Mark the proposal as outdated and link to issue #119)
(use updated proposal from issue #119)
Line 1: Line 1:
{{admon/note|Outdated|This proposal is outdated, an updated version is discussed in the Modularity Issue Tracker: https://pagure.io/modularity/issue/119}}
+
{{admon/note|Discussion|This proposal is discussed in the Modularity Issue Tracker: https://pagure.io/modularity/issue/119}}
  
== Modularity WG Governance ==
+
== Modularity Working Group Governance ==
  
This document describes the governing structure for the Modularity WG.
+
This document describes the governing structure for the Modularity Working Group.
  
 
=== Membership ===
 
=== Membership ===
  
The Modularity Working Group has seven (7) voting members. However, we would like as many people to participate as possible.
+
The Modularity Working Group consists of people who work on advancing the modularity effort in Fedora and participate in the regular meetings and conversations around this initiative. Membership is de facto, i.e. anybody who satisfies this description is considered a member.
 
 
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 Modularity community via majority consensus.
 
 
 
=== Auxiliary Seat ===
 
 
 
The next appointed position is an auxiliary seat. It is intended to have an impact on the project as a whole, but his or her votes in the consensus process are expected to be related to the scope of the respective role.
 
 
 
'''Fedora Program Manager'''
 
The [[Fedora Program Manager|FPgM]] helps to coordinate the planning and scheduling of releases with respect to milestones scheduled as part of [[Fedora_Release_Life_Cycle|Fedora release cycle]]. He or she also helps to track changes and features during the development and testing cycle, and also assists with the creation, maintenance, and execution of formal, repeatable processes.
 
 
 
=== Current Members ===
 
 
 
* [[User:langdon|Langdon]]:          Objective Lead and Council Member
 
* [[User:jkurik|Jan Kurik]]:        [[Fedora_Program_Manager|Fedora Program Manager]]
 
* [[User:mikedep333|Mike DePaulo]]
 
* [[User:tflink|Tim Flink]]
 
* [[User:Ausil|Dennis Gilmore]]
 
* [[User:harald|Harald Hoyer]]
 
* [[User:sct|Stephen Tweedie]]
 
* [[User:cydrobolt|Chaoyi Zha]]
 
  
 
=== Making Decisions ===
 
=== 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.
+
The Modularity Working Group strives to work on consensus and only votes on things where it’s unclear that a consensus exists/can be reached or where it's clear people aren’t going to be convinced to agree. In this case, a formal vote can be taken on a proposal as described here:
 
 
==== Modularity Strategy ====
 
{{admon/note|Links|Links to definitions, howtos, etc to come.}}
 
 
 
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.
 
 
 
In order to refine the Modularity Strategy, the Working Group will be presented, regularly, demos of what is being built so that they can comment or modify the direction of the development team. The strategy team and the development team both express their "changes" by "[[grooming]]" the taiga board to clarify, cleanup, add, etc [[user stories]] and [[epics]].
 
 
 
==== Modularity Development ====
 
{{admon/note|Links|Links to definitions, howtos, etc to come.}}
 
{{admon/note|Links|Content not quite complete.}}
 
 
 
  
The development team operates in a loose [[scrum]]/[[kanban]] agile development model using a 2 week [[sprint]] model. Before the beginning of every sprint, the team gets together and decides who will take on what. The team meets daily for a standup status. The team does bi-weekly sprint planning and retrospectives.
+
* Once a proposal is created as a ticket in the [https://pagure.io/modularity/issues Modularity project issue tracker], it must be voted on in the ticket within one week.
 +
* If at the end of one week there are at least 3 votes for the proposal and 0 votes against in the ticket, it has passed.
 +
* If there are any votes against, the proposal is added to the agenda of the next Working Group meeting, where a simple majority vote of members present will decide it. This decision will be recorded in the ticket.
 +
* If at the end of one week there are fewer than 3 votes for the proposal in the ticket, it is extended one further week and requires only a single affirmative vote to pass.
 +
* If at the end of two weeks there are still no votes for the proposal in the ticket, it fails automatically and the status quo is maintained.
  
 
=== Changing these Rules ===
 
=== Changing these Rules ===
  
This document will be approved by consensus of the initial Modularity Working Group members and approved by Council.  
+
This document was ratified by ... (fill in details once approved).
After initial ratification, any substantive changes can be approved by majority vote and sent to Council for acceptance.
+
After initial ratification, any substantive changes can be approved by a formal vote and sent to the Fedora Council for acceptance.

Revision as of 13:26, 12 December 2018

Note.png
Discussion
This proposal is discussed in the Modularity Issue Tracker: https://pagure.io/modularity/issue/119

Modularity Working Group Governance

This document describes the governing structure for the Modularity Working Group.

Membership

The Modularity Working Group consists of people who work on advancing the modularity effort in Fedora and participate in the regular meetings and conversations around this initiative. Membership is de facto, i.e. anybody who satisfies this description is considered a member.

Making Decisions

The Modularity Working Group strives to work on consensus and only votes on things where it’s unclear that a consensus exists/can be reached or where it's clear people aren’t going to be convinced to agree. In this case, a formal vote can be taken on a proposal as described here:

  • Once a proposal is created as a ticket in the Modularity project issue tracker, it must be voted on in the ticket within one week.
  • If at the end of one week there are at least 3 votes for the proposal and 0 votes against in the ticket, it has passed.
  • If there are any votes against, the proposal is added to the agenda of the next Working Group meeting, where a simple majority vote of members present will decide it. This decision will be recorded in the ticket.
  • If at the end of one week there are fewer than 3 votes for the proposal in the ticket, it is extended one further week and requires only a single affirmative vote to pass.
  • If at the end of two weeks there are still no votes for the proposal in the ticket, it fails automatically and the status quo is maintained.

Changing these Rules

This document was ratified by ... (fill in details once approved). After initial ratification, any substantive changes can be approved by a formal vote and sent to the Fedora Council for acceptance.