You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+40-11Lines changed: 40 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,31 @@
1
-
## Contribution Guidelines
1
+
# Contribution Guidelines
2
+
3
+
Development happens on GitHub.
4
+
Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list).
5
+
6
+
The content of this repository is licensed under the [Apache License, Version 2.0](LICENSE).
7
+
8
+
## Code of Conduct
9
+
10
+
Participation in the Open Container community is governed by [Open Container Code of Conduct][code-of-conduct].
11
+
12
+
## Meetings
13
+
14
+
The contributors and maintainers of all OCI projects have monthly meetings at 2:00 PM (USA Pacific) on the first Wednesday of every month.
15
+
There is an [iCalendar][rfc5545] format for the meetings [here][meeting.ics].
16
+
Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: +1 415 968 0849 (no PIN needed).
17
+
An initial agenda will be posted to the [mailing list](#mailing-list) in the week before each meeting, and everyone is welcome to propose additional topics or suggest other agenda alterations there.
18
+
Minutes from past meetings are archived [here][minutes].
19
+
20
+
## Mailing list
21
+
22
+
You can subscribe and browse the mailing list on [Google Groups][mailing-list].
23
+
24
+
## IRC
25
+
26
+
OCI discussion happens on #opencontainers on [Freenode][] ([logs][irc-logs]).
27
+
28
+
## Git
2
29
3
30
### Security issues
4
31
@@ -21,25 +48,19 @@ We're trying very hard to keep the project lean and focused. We don't want it
21
48
to do everything for everybody. This means that we might decide against
22
49
incorporating a new feature.
23
50
24
-
25
51
### Conventions
26
52
27
53
Fork the repo and make changes on your fork in a feature branch.
28
54
For larger bugs and enhancements, consider filing a leader issue or mailing-list thread for discussion that is independent of the implementation.
29
-
Small changes or changes that have been discussed on the project mailing list may be submitted without a leader issue.
55
+
Small changes or changes that have been discussed on the [project mailing list](#mailing-list) may be submitted without a leader issue.
30
56
31
57
If the project has a test suite, submit unit tests for your changes. Take a
32
58
look at existing tests for inspiration. Run the full test suite on your branch
33
59
before submitting a pull request.
34
60
35
61
Update the documentation when creating or modifying features. Test
36
62
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.
Copy file name to clipboardExpand all lines: GOVERNANCE.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ A maintainer SHOULD propose a motion on the [email protected] mailing list
14
14
15
15
Voting on a proposed motion SHOULD happen on the [email protected] mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT.
16
16
Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote).
17
-
Maintainers MAY post multiple times (e.g. as they revise their position based on feeback), but only their final post counts in the tally.
17
+
Maintainers MAY post multiple times (e.g. as they revise their position based on feedback), but only their final post counts in the tally.
18
18
A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release.
19
19
20
20
Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion.
Copy file name to clipboardExpand all lines: MAINTAINERS_GUIDE.md
+27-55Lines changed: 27 additions & 55 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,21 +18,18 @@ available to them.
18
18
This is a living document - if you see something out of date or missing,
19
19
speak up!
20
20
21
-
## What are a maintainer's responsibility?
21
+
## What are a maintainer's responsibilities?
22
22
23
23
It is every maintainer's responsibility to:
24
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.
25
+
* Expose a clear roadmap for improving their component.
26
+
* Deliver prompt feedback and decisions on pull requests.
27
+
* Be available to anyone with questions, bug reports, criticism etc. on their component.
28
+
This includes IRC and GitHub issues and pull requests.
29
+
* Make sure their component respects the philosophy, design and roadmap of the project.
31
30
32
31
## How are decisions made?
33
32
34
-
Short answer: with pull requests to the project repository.
35
-
36
33
This project is an open-source project with an open design philosophy. This
37
34
means that the repository is the source of truth for EVERY aspect of the
38
35
project, including its philosophy, design, roadmap and APIs. *If it's
@@ -44,14 +41,19 @@ repository. An implementation change is a change to the source code. An
44
41
API change is a change to the API specification. A philosophy change is
45
42
a change to the philosophy manifesto. And so on.
46
43
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.
44
+
All decisions affecting this project, big and small, follow the same procedure:
50
45
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?")
46
+
1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).
47
+
Anyone can do this.
48
+
2. Open a pull request.
49
+
Anyone can do this.
50
+
3. Discuss the pull request.
51
+
Anyone can do this.
52
+
4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.
53
+
The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
54
+
Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
55
+
5. Merge or close the pull request.
56
+
The relevant maintainers do this.
55
57
56
58
### I'm a maintainer, should I make pull requests too?
57
59
@@ -68,25 +70,10 @@ two LGTMs. In addition, if a maintainer has created a pull request, they cannot
68
70
count toward the two LGTM rule (to ensure equal amounts of review for every pull
69
71
request, no matter who wrote it).
70
72
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
-
73
+
Overall the maintainer system works because of mutual respect.
74
+
The maintainers trust one another to act in the best interests of the project.
75
+
Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people.
76
+
In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.
90
77
91
78
### How are maintainers added?
92
79
@@ -96,25 +83,10 @@ the long term success of the project. Contributors wanting to become
96
83
maintainers are expected to be deeply involved in contributing code,
97
84
pull request review, and triage of issues in the project for more than two months.
98
85
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?
86
+
Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on to act in the best interest of the project.
87
+
The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).
109
88
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.
89
+
### How are maintainers removed?
115
90
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.
91
+
When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
92
+
Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.
0 commit comments