New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Governance rules for Fn Project #1094

Merged
merged 1 commit into from Jul 26, 2018

Conversation

Projects
None yet
5 participants
@tteggel
Member

tteggel commented Jun 26, 2018

Introducing some lightweight governance rules for the Fn Project.

This is based on the Prometheus governance as it's lightweight and works well.

Closes #1093

image

@tteggel tteggel added the ossxp label Jun 26, 2018

@tteggel tteggel self-assigned this Jun 26, 2018

@tteggel tteggel requested review from carimura and rdallman Jun 26, 2018

@@ -0,0 +1,131 @@
# Fn Project Governance
This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Prometheus community. Common terminology used in this governance document are listed below:

This comment has been minimized.

@carimura

carimura Jun 26, 2018

Member

and the Fn community. ;)

This comment has been minimized.

@tteggel

tteggel Jun 26, 2018

Member

damn missed it!

This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Prometheus community. Common terminology used in this governance document are listed below:
* Team members: members of the [Fn Team group on forums.fnproject.io](https://forums.fnproject.io/groups/FnTeam).
* Maintainers: Maintainers lead an individual project or parts thereof.
* Projects: A single repository in the [Fn Project GitHub organization](https://github.com/fnproject) is referred to as a project.

This comment has been minimized.

@carimura

carimura Jun 26, 2018

Member

"is referred to as a project" is implied. unnecessary.

This comment has been minimized.

@tteggel
* Team members are added to the list of team members in this document.
* New team members are announced on the Fn Project forums by an existing team member.
Team members may retire at any time by posting to the Fn Project forums and removing themselves from the [FnTeam group](https://forums.fnproject.io/groups/FnTeam).

This comment has been minimized.

@carimura

carimura Jun 26, 2018

Member

Fn Team (space needed)

This comment has been minimized.

@tteggel
For public discussions, anyone interested is encouraged to participate. Formal power to object or vote is limited to [team members](#team-members).
### Lazy consensus
The default decision making mechanism for the Prometheus project is [lazy consensus](https://couchdb.apache.org/bylaws.html#lazy). This means that any decision on technical issues is considered supported by the [team](https://forums.fnproject.io/groups/FnTeam) as long as nobody objects.

This comment has been minimized.

@carimura

carimura Jun 26, 2018

Member

Fn Project

This comment has been minimized.

@tteggel
If there are multiple alternatives, members may vote for one or more alternatives, or vote "no" to object to all alternatives. It is not possible to cast an "abstain" vote. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from more than half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
### Supermajority vote
Supermajority votes must be called explicitly as a new topic in the appropriate category in the [Fn Project forums](https://forums.fnproject.io). The topic must be tagged with the 'vote' tag. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.

This comment has been minimized.

@carimura

carimura Jun 26, 2018

Member

different tag for supermajority vote?

This comment has been minimized.

@tteggel

tteggel Jun 26, 2018

Member

Good call

This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Fn Project community. Common terminology used in this governance document are listed below:
* Team members: members of the [Fn Team group on forums.fnproject.io](https://forums.fnproject.io/groups/FnTeam).
* Maintainers: Maintainers lead an individual project or parts thereof.
* Projects: A single repository in the [Fn Project GitHub organization](https://github.com/fnproject).

This comment has been minimized.

@hhexo

hhexo Jun 26, 2018

Member

If "Projects" is plural, the description should probably be "The individual repositories in..." - alternatively, make it "Project".

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

It makes most sense to me for the definitions to define a single thing: member, maintainer, project.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

Agreed. Done.

Upon death of a member, their team membership ends automatically.
The current team members are:

This comment has been minimized.

@hhexo

hhexo Jun 26, 2018

Member

This list would need continuous updating. Isn't it sufficient to link to a GitHub team or the Fn Team group on the forums?

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

Agree. There should be a single canonical source for that list.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

I've removed this section.

@mjg123

Good start - no major disagreements from me but a couple of requests for clarification.

## Projects
Each project must have a `MAINTAINERS.md` file with at least one maintainer. Where a project has a release process, access and documentation should be such that more than one person can perform a release. Releases should be announced in the [Release category in forums.fnproject.io](https://forums.fnproject.io/c/release) . Any new projects should be first proposed in the [Fn Project forums](https://forums.fnproject.io/) following the voting procedures listed below. When a project is no longer relevant it should be moved to the fnproject-junkyard GitHub organization.
## Decision

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

Not sure what this heading is doing here. Don't Projects, Team Members and Maintainers all exist at the same level in other places in this doc.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

Removed.

This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Fn Project community. Common terminology used in this governance document are listed below:
* Team members: members of the [Fn Team group on forums.fnproject.io](https://forums.fnproject.io/groups/FnTeam).
* Maintainers: Maintainers lead an individual project or parts thereof.
* Projects: A single repository in the [Fn Project GitHub organization](https://github.com/fnproject).

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

It makes most sense to me for the definitions to define a single thing: member, maintainer, project.

* The Fn Project: The sum of all activities performed under this governance, concerning one or more repositories or the community.
## Values
The Fn Project exists to serve the CNCF ecosystem. Thus developers and community are expected to follow the values defined in the [CNCF Charter](https://www.cncf.io/about/charter/), including the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). Furthermore, the Fn Project community strives for kindness, giving feedback effectively, and building a welcoming environment. The Fn Project developers generally decide by consensus and only resort to conflict resolution by a majority vote if consensus cannot be reached.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

The Fn Project exists to serve the CNCF ecosystem.

Is this true? That seems a rather narrower scope than I thought. e.g. the project exists in a big way to be the basis for a hosted service on OCI. I absolutely agree with the comments about the charter and CoC and the rest of the paragraph.

This comment has been minimized.

@rdallman

rdallman Jun 27, 2018

Member

'among other ecosystems' at least and not just solely, I agree it's a bit pigeon-holey even if we were at present a CNCF member project.

additionally:

  • nobody is going to read the CNCF charter, it's too long and doesn't seem like a valuable inclusion at this point in time, including but not limited to imposing rules that we aren't aware we're imposing and making it hard to discern what our actual process is in the fn project (the scope of CNCF is much larger) -- even if read literally here, readers are only expected to extract the 'values' outlined within, however the scope of that document is much larger and if any of those values are... valuable (forgive me)... perhaps we should simply inline them here.
  • the CNCF code of conduct looks mostly reasonable and handles a class of issues very effectively, though I don't like how conveniently left open to interpretation some of its finer points are they can be used rather 'conveniently' against people (e.g. historically speaking, defining Other unethical or unprofessional conduct. is not so easy and is a too-convenient 'catch all' imo). Since we are not a member at present, I doubt the CNCF would be an arbiter on our behalf for CoC disputes, and we should likely make our own document derivative of http://contributor-covenant.org/version/1/2/0/ with our own point of contact to handle dispute resolution as opposed to linking to the CNCF one. I agree with the overall premise of having a code of conduct as it strives for higher inclusivity, thanks for adding it.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

I agree with both your comments @rdallman. For now I've created a CODE_OF_CONDUCT.md from the contributors covenant and removed reference to CNCF.

Upon death of a member, their team membership ends automatically.
The current team members are:

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

Agree. There should be a single canonical source for that list.

New members may be proposed by any existing member by posting to the Fn Project forums. It is highly desirable to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal [supermajority vote](#supermajority-vote).
If the new member proposal is accepted, the proposed team member should be contacted privately via email to confirm or deny their acceptance of team membership. This will also be posted to the Fn Project forums for record-keeping purposes.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

deny => decline?

This comment has been minimized.

@tteggel
In all cases, all and only [team members](#team-members) are eligible to vote, with the sole exception of the forced removal of a team member, in which said member is not eligible to vote.
Discussion and votes on personnel matters (including but not limited to team membership and maintainership) are held in private in the [private Fn Team category in the Fn Project forums](https://forums.fnproject.io/c/fn-team). All other discussion and votes are held in public in the [Fn Project forums](https://forums.fnproject.io/).

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

still confused by "personnel" here.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

s/personnel/personal/

### Lazy consensus
The default decision making mechanism for the Fn Project is [lazy consensus](https://couchdb.apache.org/bylaws.html#lazy). This means that any decision on technical issues is considered supported by the [team](https://forums.fnproject.io/groups/FnTeam) as long as nobody objects.
Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision in the [Fn Project forums](https://forums.fnproject.io/) at any time and by anyone.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

I don't follow the meaning of "put of for decision in the forums" here.

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

s/decision/discussion/

Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision in the [Fn Project forums](https://forums.fnproject.io/) at any time and by anyone.
Consensus decisions can never override or go against the spirit of an earlier explicit vote.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

This is Lazy consensus decisions, right? I mean, as written this seems to make it impossible to have a re-vote on something (voting being a kind of consensus decision).

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

Yup, good clarification. Fixed.

This section is informational. In case of disagreement, the rules above overrule any FAQ.
### How do I propose a decision?
Propose it in the [Fn Project forums](https://forums.fnproject.io/). If there is no objection within a reasonable amount of time, consider the decision made. If there are objections and no consensus can be found, a vote may be called by a team member.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

"reasonable" is pretty subjective

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

Would a concrete timeframe make more sense? 7 days?

This comment has been minimized.

@rdallman

rdallman Jun 30, 2018

Member

yes, 7 days seems reasonable and it seems reasonable to spell that out (say, somebody takes a friday off and something objectionable slides in the 36h they didn't check their email! world ends!)

This comment has been minimized.

@tteggel
### How do I archive or remove a project?
Start a new topic in the [Fn Project forums](https://forums.fnproject.io/) proposing the retirement of a project. If nobody objects, move it to the fnproject-junkyard GitHub organization.

This comment has been minimized.

@mjg123

mjg123 Jun 26, 2018

Member

This seems a rather important decision to be left to lazy consensus IMO

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

I think it's OK but maybe set an explicit timeframe that the consensus decision must be left open for?

This comment has been minimized.

@rdallman

This comment has been minimized.

@tteggel
The Fn Project exists to serve the CNCF ecosystem. Thus developers and community are expected to follow the values defined in the [CNCF Charter](https://www.cncf.io/about/charter/), including the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). Furthermore, the Fn Project community strives for kindness, giving feedback effectively, and building a welcoming environment. The Fn Project developers generally decide by consensus and only resort to conflict resolution by a majority vote if consensus cannot be reached.
## Projects
Each project must have a `MAINTAINERS.md` file with at least one maintainer. Where a project has a release process, access and documentation should be such that more than one person can perform a release. Releases should be announced in the [Release category in forums.fnproject.io](https://forums.fnproject.io/c/release) . Any new projects should be first proposed in the [Fn Project forums](https://forums.fnproject.io/) following the voting procedures listed below. When a project is no longer relevant it should be moved to the fnproject-junkyard GitHub organization.

This comment has been minimized.

@rdallman

rdallman Jun 27, 2018

Member

might we say 'major' or 'major/minor' release? slight technicality that every commit is a release at the moment (which is ok). don't mean to open the release can of worms here, necessarily

This comment has been minimized.

@tteggel

tteggel Jun 29, 2018

Member

Added 'Major'.

Team members can be removed by [supermajority vote](#supermajority-vote) in the [private Fn Team category in the Fn Project forums](https://forums.fnproject.io/c/fn-team). For this vote, the member in question is not eligible to vote and does not count towards the quorum.
Upon death of a member, their team membership ends automatically.

This comment has been minimized.

@rdallman

rdallman Jun 30, 2018

Member

s/their team membership ends automatically/You will ride eternal, shiny and chrome!/ :)

This comment has been minimized.

@tteggel
### How do I remove an inactive maintainer?
A maintainer may resign by notifying the [Fn Team group on the Fn Project forums](https://forums.fnproject.io/groups/FnTeam). A maintainer with no project activity for a year will be treated as if they had resigned. If there is an urgent need to replace a maintainer, discuss this in the [private Fn Team category in the Fn Project forums](https://forums.fnproject.io/c/fn-team) or by messaging the [Fn Team group](https://forums.fnproject.io/groups/FnTeam).
### How do I remove a team member?

This comment has been minimized.

@rdallman

rdallman Jun 30, 2018

Member

this seems somewhat in conflict with the prior answer of proposing a supermajority vote https://github.com/fnproject/fn/pull/1094/files#diff-9e8744ec73212c1966bb19fa22fc3e0aR29 -- we should pick one and just put it there instead of having to diff 2 sections I think

This comment has been minimized.

@tteggel

tteggel Jul 9, 2018

Member

agree. removed this section

Start a new topic in the [Fn Project forums](https://forums.fnproject.io/) proposing the retirement of a project. If nobody objects, move it to the fnproject-junkyard GitHub organization.
### How do I remove an inactive maintainer?

This comment has been minimized.

@rdallman

rdallman Jun 30, 2018

Member

this is also largely duplicated from above, could diverge / confuse and requires a mental diff. the shorter we keep this doc the better!

This comment has been minimized.

@tteggel

tteggel Jul 9, 2018

Member

removed this section.

@rdallman

This comment has been minimized.

Member

rdallman commented Jun 30, 2018

few tiny comments, this is basically ready to green button to me -- thanks, this is great.

fwiw, the only thing this doc didn't make crystal clear to me after reading it pretending to be a user that knows nothing is that in general this document applies to a relatively rare set of circumstances, mostly wrt governance itself (e.g. add a repo, add a member, remove a member, change consensus rules), and most things in general should be opened as issues on a particular repo to discuss / slack and explicitly not as things to discuss in the forum in the manner outlined here. again, just wasn't perfectly clear, even though it is clearly stated that that is the case it's buried in the 'Technical Decisions' section and imo would do well to be clearly stated at the beginning. but that's just, like, my opinion, man.

edit bonus: while the supermajority section outlines that everything should be tagged as 'supermajority' if that's what they want, it seems wise to require a tag in general along the lines of 'governance' for these kinds of things in general, as the forum may contain other kinds of things too (bug reports, off topic discussions of tea infusions, idk).

edit bonus bonus: maybe this is supposed to apply to a wider set of things and I misinterpreted? I am typing this at 8pm on a Friday clearly I am not a good example of a human and should not be trusted with opinions.

@rdallman

let's :shipit:

@rdallman rdallman dismissed stale reviews from mjg123 and carimura Jul 26, 2018

addressed

@rdallman rdallman merged commit 91ae248 into master Jul 26, 2018

2 checks passed

ci/circleci Your tests passed on CircleCI!
Details
cla_bot All committers have signed the CLA.
Details

@rdallman rdallman deleted the governance branch Jul 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment