Add Flux GOVERNANCE doc

[scottrigby]

Fixes #1
Closes #15

Intro

This is an initial draft PR for community feedback. @dholbach was kind enough to do an initial quick scan at https://hackmd.io/sBKKaeTgRmO4JYziwq4teQ?both but now it's time to discuss. Please preview at https://github.com/scottrigby/flux-community/blob/governance/GOVERNANCE.md and see what you think 🙂

Changes for Contributors

DCO

As soon as this PR is merged, Developer Certificate of Origin (DCO) commit signoff will be required for all new code contributions in the fluxcd GitHub org repos.

Note either DCO or CLA is required for CNCF projects. I proposed DCO, as it's easier for end users, and built into git.

For those unfamiliar with DCO, see git help commit:

-s, --signoff
    Add Signed-off-by line by the committer at the end of the commit log
    message. The meaning of a signoff depends on the project, but it typically
    certifies that committer has the rights to submit this work under the same
    license and agrees to a Developer Certificate of Origin (see
    http:https://developercertificate.org/ for more information).

Your DCO signoff is drawn from your gitconfig's name and email. If you choose to manually add a signoff line, it must be properly formatted and must match your commit information. For example, if you use a GitHub private email (like <username>@users.noreply.github.com) you must make sure to set your gitconfig's email accordingly.

For those who wish to ensure this is always done in your CLI, consider implementing something like this gist. I have successfully used this for several years.

Whenever commit messages are added in the GitHub UI, consider using the DCO GitHub UI browser plugin for Chrome or Firefox, which I also maintain, and is in use by a number of contributors to CNCF projects.

Timeline

• One week for initial comments on this PR (Thurs 15 Oct)
• One week for final thoughts after all initial comments have been addressed (Thurs 22 Oct)
• Update: as of Friday 23 Oct there are still details being ironed out. Stay tuned ⏳

Readiness to merge the PR will be decided by Lazy consensus. At which point:

• this GOVERNANCE doc PR will be committed
• we will email the flux-dev list letting contributors know about the DCO change above
• we will enable the DCO bot across all repos in the fluxcd GitHub org

We will also notify users and contributors of the above dates, in CNCF Slack #flux channels, and on the flux-dev mailing list.

Additional Context

Edit I removed earlier additional context. I tried to take a less is more approach with the doc itself, since by definition it needs to stand on its own. If interested, see description history for this PR ⏳

[hiddeco]

Thank you Scott 🌞

Did a quick round of review, and on a first read, it all seems reasonable and very much inline with other projects' governance.

[caniszczyk]

DCO or CLA is also required by CNCF IP policy, you get to choose

On Sun, Oct 4, 2020 at 10:26 AM Hidde Beydals ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In GOVERNANCE.md <#13 (comment)>: > + +Org team membership changes have additional considerations: + +- Members of any other team are eligible to be nominiated as an Org team member +- Org maintainers MUST remain current members of other non-archived teams. +If that status changes, they will also loose Org team membership. +- If an Org maintainer volunteraily steps down, in addition to the process above, within 7 calendar days the Flux dev list MUST be notified <https://lists.cncf.io/g/cncf-flux-community>. +This gives contributors reasonable time to be made aware of the change. +- When there is an opening for a new Org maintainer, any contributor to a repository in the `fluxcd` github org may nominate a suitable existing member of another team as a replacement. + - The nomination period will be three weeks starting the day after an Org team member opening becomes available. + - The nomination must be made as a reply to the notification topic in the Flux dev list. + +## Licenses + +- Apache 2.0 is required for all source code repositories +- Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions What’s the point of this anyway, without pgp anyone can impersonate another user by just signing off with that user’s email. It is not about impersonation, but about authorship vs copyright acknowledgement: https://stackoverflow.com/a/1962112 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSIMOXM53S2X646GQ6XLSJCH2NANCNFSM4SCAXW5Q> .

-- Cheers, Chris Aniszczyk http:https://aniszczyk.org +1 512 961 6719

[squaremo]

Some typo corrections, some comments. I'll batch the typos into a commit, to take them off the radar.

[dholbach]

CC @michaelbeaumont, @sarataha, @foot, @dinosk, @yiannistri as maintainers of fluxcd/go-git-providers

[dholbach]

CC @seaneagan as maintainer of fluxcd/helm-controller.

[phillebaba]

One small thing that I think may be missing is information regarding how a person becomes a maintainer. Is this only possible through invitation or is it something one has to apply to after a certain amount of contributions.

[scottrigby]

One small thing that I think may be missing is information regarding how a person becomes a maintainer. Is this only possible through invitation or is it something one has to apply to after a certain amount of contributions.

@phillebaba you're right there's currently only info about how voting takes place, in Membership Changes (for all teams, for an Org team seat, and for maintaining a technical sub-project).

The Values section also attempts to expresses that this is an open process, contributions of all kinds from anyone (ideally from a broader spectrum of organizations) may join the community at any level.

I agree there's almost definitely some shared expectations of prior contributions and commitment before nominating/adding a contributor to take on more responsibility within the project. But I didn't want to try adding specific criteria for this to the doc because it seemed better to leave up to the existing members voting process above. I'd like to hear the current maintainers points of view on whether we should detail this out more in the doc, and if so what should that be? I'm trying hard to leverage various CNCF project members experiences to keep this both useful and as simple as possible. Please let me know what you think.

[squaremo]

Overall comment: this seems like a lot of bureaucracy, while we have not many more maintainers than there are teams proposed. Other comments in line.

[squaremo]

this seems like a lot of bureaucracy

More constructively:

• The Org team has a purpose, as arbiters of last resort (without bothering CNCF, that is)

• I can see a purpose for the Security team and Community team, distinct from the others.

• The Dev team doesn't have a remit outside of the individual projects (here I mean the repos under fluxcd/). I think we should just mention the responsibilities of individual repo maintainers and forget about a Dev team.

• I think the desire for an Architecture team comes from recognising that there's at least one line of development that's spread over several repos (the gitops toolkit bits). But I don't think it would be effective to parachute maintainers into repos so they can be said to be represented, and I don't think it's desirable to have a small group of people deciding how everything works.

It would be better to rely on openness and transparency (i.e., the values) for making sure people get heard -- that should be happening anyway. If there's a bunch of repos that all go together, and a need to co-ordinate, then constitute a team for making decisions over a larger area, but restrict its scope to those repos.

[stefanprodan]

The Dev team doesn't have a remit outside of the individual projects (here I mean the repos under fluxcd/). I think we should just mention the responsibilities of individual repo maintainers and forget about a Dev team.

The Dev team would allow repo maintainers to display on their GitHub profile the fluxcd membership. I would keep the Dev team for this purpose only.

PS. Maybe a better name for this team would be "Maintainers team".

I think the desire for an Architecture team comes from recognising that there's at least one line of development that's spread over several repos (the gitops toolkit bits). But I don't think it would be effective to parachute maintainers into repos so they can be said to be represented, and I don't think it's desirable to have a small group of people deciding how everything works.

I agree, instead of an Architecture team, those that want to get involved into day-to-day decisions they could comment on API proposals and review PRs in each repo.

[scottrigby]

@squaremo My only change since last approvals was 5c23de5.

You can ignore the rest of the force-push. Looks like I had missed a DCO signoff in one of the UI commits from earlier on. Had to fix that now that the DCO bot has been added in #17 (thanks @hiddeco for that!). For future ref, DCO bot gives fix instructions on the checks tab when if fails. In this case it was:

git rebase HEAD~32 --signoff
git push --force-with-lease scottrigby governance