-
-
Notifications
You must be signed in to change notification settings - Fork 353
Governance
HLS is primarily governed as a “do-ocracy”: voice and authority come from activity and contribution. This is a vague governance structure, in that there mostly do not exist formal decision procedures, lists of people with authority, or processes for acquiring authority. There are some partial codifications (see below) but the ground truth is vague.
HLS also has a light additional structure based around public meetings, and a few roles relating to organization and releases.
This document is an attempt to codify the current state of affairs, and the governance structure may evolve over time.
All contributors (defined below in ‘Roles’) to HLS have the right to speak at meetings, voice their opinion on issues, review pull requests, and generally be heard. However, in keeping with the “do-ocracy” attitude, more experienced and active contributors will be listened to more, and in some cases will have de-facto authority over parts of the codebase that they primarily maintain.
One way in which this manifests is that turning up is key to being heard. If you want to be heard, then attend the meeting, comment on the issue, review the pull request, etc.
Feedback is usually received either from active contributors who participate in the open forums that we have, or ultimately from users reporting back on their use of the software.
HLS operates under a consensus-seeking model. That is, decisions are typically made by consensus, with a fallback if consensus cannot be reached. At the moment the fallback is mediation until consensus is reached, but in future we may adopt some kind of voting procedure here instead.
Consensus is rough. Not everyone needs to agree, and in the spirit of do-ocracy, active and experienced contributors count for more. A new contributor can speak up, but will likely not block consensus.
Consensus can be lazy. Established contributors can assume they have a good sense of what consensus will want, and that can be objected to or corrected after the fact if necessary. Lazy consensus does not mean that contributors can do unpopular things: contributors should still aim to do things that they think consensus would approve of.
Consensus is sought through the following routes:
- Public discussions on GitHub
- Discussion in public meetings with previously circulated agenda
The following venues are useful for discussion, but will not be used for consensus:
- IRC/Matrix
- Mailing lists
The following decisions are special for one reason or another, and in particular require explicit (not lazy) consensus.
Spending money from the OpenCollective fund
A proposal to spend money (including in a recurring fashion) from the OpenCollective fund must have a comment period of a month before being authorized, and must (as usual) have consensus. After this, the HF can be asked to release the money when needed.
Giving someone repository administrator rights
A proposal to give someone repository administrator rights must (as usual) have consensus, and the HF (as our representatives of the administrators of the Haskell organization) must agree and enact this.
All information should be public unless there is good reason for it not to be. Meetings should be public and discoverable, meeting minutes likewise.
These roles relate to the day-to-day development process of HLS.
- User: A user of HLS. The reason why we work on the project. Should speak out on GitHub primarily. Should usually not attend meetings.
- Contributor: Anyone who contributes to HLS in any form: code, documentation, organization, or otherwise.
- Committer: Anyone who has commit rights to HLS.
- Repository administrator: Anyone who has administrator rights to the HLS repository.
These roles relate to the organizational aspects of HLS above and beyond the development of the software itself. These roles do not grant additional decision-making power or authority beyond what one would have as a contributor, except where explicitly noted.
Chair
There is one chair. Their purpose is procedural, to make sure what processes we do have happen effectively.
The chair:
- Schedules meetings
- Prepares agendas for meetings
- Advertises meetings and circulates the agenda
- Facilitates meetings
- Takes minutes and makes them available
If there is no chair, then meetings will probably not happen until there is a chair, making it harder to gain consensus or discuss issues (anyone volunteering to organize meetings is the chair).
Release manager
There should be one release manager per release but the role can be shared. The release manager is associated with a particular release, but the same individual can be release manager for several releases.
The release manager:
- Performs the release
- Decides when to cut the release
- Decides what changes go into the release, including backports if necessary
- Publices the release
- Has general decision-making authority over anything release-relevant
If there is no release manager then we cannot perform a release (anyone volunteering to do the release is the release manager).
Representative
Many other groups have relevant interests or information and they often send people to meetings.
A representative:
- Represents the interests of another group
- Facilitates information transfer between HLS and other groups
- Need not be a contributor, has a voice anyway
Often there will be representatives from:
- The HF
- The GHC team
The following parts of the governance structure are officially codified:
- Maintainers for particular parts of the codebase are listed in CODEOWNERS. However, this is not always up-to-date.
- The holders of the organizational roles are listed in the wiki.
Alan is a repository administrator and wants to give Beth commit rights, given that Beth has just contributed a major piece of work that is widely perceived to be high quality. Alan justifiably believes that nobody will object to this, so goes ahead and does it, but sends out a note on the mailing list in case anyone objects. (Lazy consensus)
A release is coming up and in a meeting Celia volunteers to be the release manager. Nobody objects, so Celia is listed in the minutes as the new release manager. Denise reads the minutes and objects that they were promised they could be the next release manager. If there is a dispute, another community member mediates until there is consensus about who the release manager should be. (Consensus-seeking)
Elizabeth wants to spend some money to pay a consultancy to update HLS for a new GHC version. They write a public proposal and discuss it at a meeting. If there are no objections, it is listed in the minutes and a month later if there have been no serious objections then the proposal is authorized. (Special decisions)
Frank is the primary maintainer of a complicated bit of code. A newer contributor reviews his PR and questions the desirability of what he is doing. Frank (politely) disagrees and merges the PR when it is ready. (Do-ocracy)