Skip to content

Commit b5b3f3c

Browse files
runcomruncom
committed
Merge remote-tracking branch 'pt/master'
* pt/master: (32 commits) GOVERNANCE.md: fix typo GOVERNANCE and RELEASES: split the files project-governance: Make voting more generic proposals: release approval process explain security@ email proposal: fix a typo proposals: release-approval-process fix a grammar thing release-approval: Add non-spec unanimous quorum reduction release-approval: Shuffle to make more DRY proposals: release-approval-process: fixup additional typos proposals: release approval process: improve REJECT feedback proposals: release approval process: add information to projects proposals: release approval process: add language about mailing list proposals: release approval process: add quorum language proposals: release-approval-process: add voting members language proposals: release approval process: clarify utility of GitHub proposals: release approval process: use consistent language for rejects proposals: release approval process: one month pre-releases proposals: release approval process 3 rcs required proposals: release approval process to one week for apps proposal: release-approval-process add some motivation ...
2 parents 02e1ecd + d81a903 commit b5b3f3c

File tree

2 files changed

+239
-0
lines changed

2 files changed

+239
-0
lines changed

‎CONTRIBUTING.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
## Contribution Guidelines
2+
3+
### Pull requests are always welcome
4+
5+
We are always thrilled to receive pull requests, and do our best to
6+
process them as fast as possible. Not sure if that typo is worth a pull
7+
request? Do it! We will appreciate it.
8+
9+
If your pull request is not accepted on the first try, don't be
10+
discouraged! If there's a problem with the implementation, hopefully you
11+
received feedback on what to improve.
12+
13+
We're trying very hard to keep the project lean and focused. We don't want it
14+
to do everything for everybody. This means that we might decide against
15+
incorporating a new feature.
16+
17+
18+
### Conventions
19+
20+
Fork the repo and make changes on your fork in a feature branch:
21+
22+
- If it's a bugfix branch, name it XXX-something where XXX is the number of the
23+
issue
24+
- If it's a feature branch, create an enhancement issue to announce your
25+
intentions, and name it XXX-something where XXX is the number of the issue.
26+
27+
Small changes or changes that have been discussed on the project mailing list
28+
may be submitted without a leader issue, in which case you are free to name
29+
your branch however you like.
30+
31+
If the project has a test suite, submit unit tests for your changes. Take a
32+
look at existing tests for inspiration. Run the full test suite on your branch
33+
before submitting a pull request.
34+
35+
Update the documentation when creating or modifying features. Test
36+
your documentation changes for clarity, concision, and correctness, as
37+
well as a clean documentation build. See ``docs/README.md`` for more
38+
information on building the docs and how docs get released.
39+
40+
Write clean code. Universally formatted code promotes ease of writing, reading,
41+
and maintenance. Always run `gofmt -s -w file.go` on each changed file before
42+
committing your changes. Most editors have plugins that do this automatically.
43+
44+
Pull requests descriptions should be as clear as possible and include a
45+
reference to all the issues that they address.
46+
47+
Commit messages must start with a capitalized and short summary
48+
written in the imperative, followed by an optional, more detailed
49+
explanatory text which is separated from the summary by an empty line.
50+
51+
Code review comments may be added to your pull request. Discuss, then make the
52+
suggested modifications and push additional commits to your feature branch. Be
53+
sure to post a comment after pushing. The new commits will show up in the pull
54+
request automatically, but the reviewers will not be notified unless you
55+
comment.
56+
57+
Before the pull request is merged, make sure that you squash your commits into
58+
logical units of work using `git rebase -i` and `git push -f`. After every
59+
commit the test suite (if any) should be passing. Include documentation changes
60+
in the same commit so that a revert would remove all traces of the feature or
61+
fix.
62+
63+
Commits that fix or close an issue should include a reference like `Closes #XXX`
64+
or `Fixes #XXX`, which will automatically close the issue when merged.
65+
66+
### Sign your work
67+
68+
The sign-off is a simple line at the end of the explanation for the
69+
patch, which certifies that you wrote it or otherwise have the right to
70+
pass it on as an open-source patch. The rules are pretty simple: if you
71+
can certify the below (from
72+
[developercertificate.org](http://developercertificate.org/)):
73+
74+
```
75+
Developer Certificate of Origin
76+
Version 1.1
77+
78+
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
79+
660 York Street, Suite 102,
80+
San Francisco, CA 94110 USA
81+
82+
Everyone is permitted to copy and distribute verbatim copies of this
83+
license document, but changing it is not allowed.
84+
85+
86+
Developer's Certificate of Origin 1.1
87+
88+
By making a contribution to this project, I certify that:
89+
90+
(a) The contribution was created in whole or in part by me and I
91+
have the right to submit it under the open source license
92+
indicated in the file; or
93+
94+
(b) The contribution is based upon previous work that, to the best
95+
of my knowledge, is covered under an appropriate open source
96+
license and I have the right under that license to submit that
97+
work with modifications, whether created in whole or in part
98+
by me, under the same open source license (unless I am
99+
permitted to submit under a different license), as indicated
100+
in the file; or
101+
102+
(c) The contribution was provided directly to me by some other
103+
person who certified (a), (b) or (c) and I have not modified
104+
it.
105+
106+
(d) I understand and agree that this project and the contribution
107+
are public and that a record of the contribution (including all
108+
personal information I submit with it, including my sign-off) is
109+
maintained indefinitely and may be redistributed consistent with
110+
this project or the open source license(s) involved.
111+
```
112+
113+
then you just add a line to every git commit message:
114+
115+
Signed-off-by: Joe Smith <[email protected]>
116+
117+
using your real name (sorry, no pseudonyms or anonymous contributions.)
118+
119+
You can add the sign off when creating the git commit via `git commit -s`.

‎MAINTAINERS_GUIDE.md‎

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
## Introduction
2+
3+
Dear maintainer. Thank you for investing the time and energy to help
4+
make this project as useful as possible. Maintaining a project is difficult,
5+
sometimes unrewarding work. Sure, you will get to contribute cool
6+
features to the project. But most of your time will be spent reviewing,
7+
cleaning up, documenting, answering questions, justifying design
8+
decisions - while everyone has all the fun! But remember - the quality
9+
of the maintainers work is what distinguishes the good projects from the
10+
great. So please be proud of your work, even the unglamourous parts,
11+
and encourage a culture of appreciation and respect for *every* aspect
12+
of improving the project - not just the hot new features.
13+
14+
This document is a manual for maintainers old and new. It explains what
15+
is expected of maintainers, how they should work, and what tools are
16+
available to them.
17+
18+
This is a living document - if you see something out of date or missing,
19+
speak up!
20+
21+
## What are a maintainer's responsibility?
22+
23+
It is every maintainer's responsibility to:
24+
25+
* 1) Expose a clear roadmap for improving their component.
26+
* 2) Deliver prompt feedback and decisions on pull requests.
27+
* 3) Be available to anyone with questions, bug reports, criticism etc.
28+
on their component. This includes IRC and GitHub issues and pull requests.
29+
* 4) Make sure their component respects the philosophy, design and
30+
roadmap of the project.
31+
32+
## How are decisions made?
33+
34+
Short answer: with pull requests to the project repository.
35+
36+
This project is an open-source project with an open design philosophy. This
37+
means that the repository is the source of truth for EVERY aspect of the
38+
project, including its philosophy, design, roadmap and APIs. *If it's
39+
part of the project, it's in the repo. It's in the repo, it's part of
40+
the project.*
41+
42+
As a result, all decisions can be expressed as changes to the
43+
repository. An implementation change is a change to the source code. An
44+
API change is a change to the API specification. A philosophy change is
45+
a change to the philosophy manifesto. And so on.
46+
47+
All decisions affecting this project, big and small, follow the same 3 steps:
48+
49+
* Step 1: Open a pull request. Anyone can do this.
50+
51+
* Step 2: Discuss the pull request. Anyone can do this.
52+
53+
* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
54+
this (see below "Who decides what?")
55+
56+
### I'm a maintainer, should I make pull requests too?
57+
58+
Yes. Nobody should ever push to master directly. All changes should be
59+
made through a pull request.
60+
61+
## Who decides what?
62+
63+
All decisions are pull requests, and the relevant maintainers make
64+
decisions by accepting or refusing the pull request. Review and acceptance
65+
by anyone is denoted by adding a comment in the pull request: `LGTM`.
66+
However, only currently listed `MAINTAINERS` are counted towards the required
67+
two LGTMs. In addition, if a maintainer has created a pull request, they cannot
68+
count toward the two LGTM rule (to ensure equal amounts of review for every pull
69+
request, no matter who wrote it).
70+
71+
Overall the maintainer system works because of mutual respect across the
72+
maintainers of the project. The maintainers trust one another to make decisions
73+
in the best interests of the project. Sometimes maintainers can disagree and
74+
this is part of a healthy project to represent the point of views of various people.
75+
In the case where maintainers cannot find agreement on a specific change the
76+
role of a Chief Maintainer comes into play.
77+
78+
The Chief Maintainer for the project is responsible for overall architecture
79+
of the project to maintain conceptual integrity. Large decisions and
80+
architecture changes should be reviewed by the chief maintainer.
81+
The current chief maintainer for the project is the first person listed
82+
in the MAINTAINERS file.
83+
84+
Even though the maintainer system is built on trust, if there is a conflict
85+
with the chief maintainer on a decision, their decision can be challenged
86+
and brought to the technical oversight board if two-thirds of the
87+
maintainers vote for an appeal. It is expected that this would be a
88+
very exceptional event.
89+
90+
91+
### How are maintainers added?
92+
93+
The best maintainers have a vested interest in the project. Maintainers
94+
are first and foremost contributors that have shown they are committed to
95+
the long term success of the project. Contributors wanting to become
96+
maintainers are expected to be deeply involved in contributing code,
97+
pull request review, and triage of issues in the project for more than two months.
98+
99+
Just contributing does not make you a maintainer, it is about building trust
100+
with the current maintainers of the project and being a person that they can
101+
depend on and trust to make decisions in the best interest of the project. The
102+
final vote to add a new maintainer should be approved by over 66% of the current
103+
maintainers with the chief maintainer having veto power. In case of a veto,
104+
conflict resolution rules expressed above apply. The voting period is
105+
five business days on the Pull Request to add the new maintainer.
106+
107+
108+
### What is expected of maintainers?
109+
110+
Part of a healthy project is to have active maintainers to support the community
111+
in contributions and perform tasks to keep the project running. Maintainers are
112+
expected to be able to respond in a timely manner if their help is required on specific
113+
issues where they are pinged. Being a maintainer is a time consuming commitment and should
114+
not be taken lightly.
115+
116+
When a maintainer is unable to perform the required duties they can be removed with
117+
a vote by 66% of the current maintainers with the chief maintainer having veto power.
118+
The voting period is ten business days. Issues related to a maintainer's performance should
119+
be discussed with them among the other maintainers so that they are not surprised by
120+
a pull request removing them.

0 commit comments

Comments
 (0)