The inspiration for the Fluid community's governance process comes from the Apache Project. In the spirit of not wanting to reinvent the wheel, we have adopted Apache's voting process, refining it a bit along the way. We've tried to keep the process simple and clear, allowing the community to play a central role in the process of making decisions about the project. In the end, like any open source community, the overall direction of the project will be driven by the time and commitment of the contributors.

Voting Notation

From Apache:

The voting process in Apache may seem more than a little weird if you've never encountered it before. Votes are represented as numbers between -1 and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'

In the Fluid community, we tend to stick with straightforward integer votes expressing approval or disagreement:

Vote	Meaning
+1	I support this proposal and am willing to contribute where possible.
0	I don't feel strongly about the issue either way.
-1	I don't agree. Here's what I think we can do to change/improve/rework the idea. For formal votes, -1 vote is a veto.

In all cases, voting implies a responsibility. While no one is required to vote, community members are encouraged to contribute if a vote affects an area you have experience in.

Formal Voting

We vote formally on technical and design governance issues: major architectural or design changes, substantial changes to the code base, new committers, and so on.

Positive votes express support for a particular proposal, and may in some cases imply a willingness to contribute. A negative vote acts as an immediate veto, and comes with a set of associated responsibilities. If you vote -1, you need to also:

Explain the rationale for your negative vote.
Offer a viable alternative proposal, or describe the steps that need to be taken to change your vote to a +1

More specific information can be found about how we vote for new committers

Who Can Vote?

Everyone in the community can vote. Voting implies a commitment to get involved, so please refrain from weighing in on issues that aren't within your area of expertise, or more broadly, within your ability to contribute.

Day-to-Day Work

All of the day-to-day procedural issues we encounter as a community, such as release planning, design and development, and organizational issues are more informal. Lazy consensus and majority approval are in effect here.

From Apache:

Lazy Consensus: A decision-making policy which assumes general consent if no responses are posted within a defined period. For example, "I'm going to commit this by lazy consensus if no-one objects within the next three days."
Majority Approval refers to a vote... which has completed with at least three binding +1 votes and more +1 votes than -1 votes. (I.e., a simple majority with a minimum quorum of three positive votes.) Note that in votes requiring majority approval a -1 vote is simply a vote against, not a veto.

Put another way, our day to day activities tend not to require formal voting. In cases where opinions need to be solicited, they are assumed to be lazy unless otherwise stated. In cases where an issue is deemed more substantial than is appropriate for a day-to-day vote, a formal vote on the issue can be called, allowing time for more considered discussion and potential vetoes.

To succeed with lazy consensus-based governance our community needs to be both open and engaged. Community members need to be informed about the ongoing work of the project (the fluid-work mailing list and #fluid-work:matrix.org are typical venues for communication), and they need to remain aware of and engaged in activities that are relevant to their areas of interest and experience.

If significant disagreement is encountered during a vote, an issue can be escalated to the Fluid Project Steering Committee.

Browser not supported