[edited per the discussion in the WG meeting of 2018-12-18]

On the last meeting of 2012-12-11 we decided on the mode of voting (see issue #118), but there's a fuller proposed charter lingering in the wiki which should be decided upon.

Below is how I propose to phrase the charter, based on the previous proposal in the wiki (which I've updated in agreement with Langdon) but with these changes:

• remove language around voting membership, replace with "de facto membership" language to reflect the recent decision
• remove distinction between strategy and development discussion/decisions
• remove exact mode of development (scrum/kanban, how long a sprint takes), this should be up to the people affected
• describe the mode of taking formal votes in tickets and WG meetings
• change language about asking permission from the Council to informing them

The document below will be approved by voting in this ticket and/or the following WG meeting where it is discussed, as per the voting process we decided in the meeting yesterday. Upon acceptance, it will be forwarded to the Council for approval.

/cc @langdon @psabata @asamalik @sgallagh

== 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 put to be voted on in 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 it's approved).
After initial ratification, any substantive changes can be approved by a formal vote, upon which the Fedora Council will be informed.