-
Notifications
You must be signed in to change notification settings - Fork 145
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
Initial draft of docs for chartering #338
Changes from all commits
5be42b3
ca4b8b3
0cdce7c
f3246a7
45f7844
ee04245
825f0c1
d8e5487
7e22760
3502fc0
226edf3
b1871e8
2fb0ebd
1ee6175
5f1d5c4
a9eef1e
f01f8ba
6007e78
c79c3d4
b373318
14a9b0b
a804e87
638e9e9
dc9a5b1
f856669
579292c
0c9f597
41fbdf6
2cc9e3a
a465ee1
8530103
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
## Package Maintenance Working Group Charter | ||
|
||
The Node.js Package Maintenance Working Group is jointly governed by the members | ||
of that Working Group (WG). | ||
|
||
The WG responsibilities include: | ||
|
||
* Management of repositories within the [pkgjs](https://github.com/pkgjs) | ||
GitHub organization including but not limited to: | ||
* Managing the list of organization owners which supplement the standard | ||
Node.js organization owners as outlined in: | ||
[https://github.com/nodejs/admin/blob/master/GITHUB_ORG_MANAGEMENT_POLICY.md#owners](https://github.com/nodejs/admin/blob/master/GITHUB_ORG_MANAGEMENT_POLICY.md#owners) | ||
* Overseeing new repositories (creating, moving, removing) | ||
* Managing the maintainer teams for all of the repositories. | ||
* Contribution policy for repositories | ||
* Technical direction for the projects within | ||
the [pkgjs](https://github.com/pkgjs) organization | ||
* Project governance and process (including this policy) | ||
* Managing the maintainer teams and contribution policies for the | ||
following repositories | ||
* nodejs/ci-config-travis | ||
* nodejs/ci-config-github-actions | ||
* nodejs/package-maintenance repository. | ||
|
||
For the current list of WG members, see the project [README.md][]. | ||
|
||
[README.md]: ./README.md#current-project-team-members | ||
dominykas marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,269 @@ | ||
## Package Maintenance Working Group Governance | ||
|
||
### Collaborators | ||
|
||
### WG Membership | ||
|
||
The package-maintence team has two levels of membership. Administrative | ||
members and regular members. | ||
|
||
If you'd like to be listed as regular team member, open a PR adding yourself | ||
to [MEMBERS.md](MEMBERS.md) along with a few words on how you are planning | ||
to contribute to the team's efforts. | ||
|
||
Administrative members take on additional levels of responsibility with | ||
respect to managing the [pkgjs](https://github.com/pkgjs) organization | ||
and the other repositories managed by the working group. Administrative | ||
members should have a long standing involvement in the working group. | ||
|
||
Individuals who have made significant contributions and who wish to be | ||
considered as an Administrative member may create an issue or | ||
contact an Administrative WG member directly. It is not necessary | ||
to wait for an Administrative WG member to nominate the individual. | ||
|
||
There is no specific set of requirements or qualifications for WG | ||
membership beyond these rules. | ||
|
||
The WG may add additional Administrative members to the WG by | ||
consensus. If there are any objections to adding any individual | ||
member, an attempt should be made to resolve those objections | ||
following the WG's Consensus Seeking Process. | ||
|
||
A WG member may be removed from the WG by voluntary resignation, or by | ||
consensus of the Administrative WG members. | ||
|
||
Changes to Administrative WG membership should be posted in | ||
the agenda, and may be suggested as any other agenda | ||
item (see "WG Meetings" below). | ||
|
||
If an addition or removal is proposed, this should be raised in an | ||
issue, tagged for the next agenda, and concensus should be reached | ||
in the issue. This is to ensure | ||
that all Administrative members are given the opportunity to | ||
participate in all membership decisions. The addition or removal | ||
is considered approved once the issue has been open for 2 meetings | ||
or 14 days whichever is longer, and at least half the Administrative | ||
members are in favor. | ||
|
||
No more than 1/3 of the Administrative WG members may be | ||
affiliated with the same employer. If removal or resignation | ||
of a WG member, or a change of employment by a WG member, | ||
creates a situation where more than 1/3 of the WG membership | ||
shares an employer, then the situation must be immediately | ||
remedied by the resignation or removal of one or more | ||
Administrative WG members affiliated with the | ||
over-represented employer(s). | ||
|
||
For the current list of members, see the project [README.md][]. | ||
|
||
### WG Meetings | ||
|
||
The WG meets regularly as scheduled on the Node.js | ||
[calendar](https://nodejs.org/calendar). Each meeting should be | ||
published to YouTube. | ||
|
||
Items are added to the WG agenda that are considered contentious or | ||
are modifications of governance, contribution policy, WG membership, | ||
or release process. | ||
|
||
The intention of the agenda is not to approve or review all patches; | ||
that should happen continuously on GitHub. | ||
|
||
Any community member or contributor can ask that something be added to | ||
the next meeting's agenda by logging a GitHub Issue. Any Collaborator, | ||
WG member or the moderator can add the item to the agenda by adding | ||
the ***package-maintenance-agenda*** tag to the issue. | ||
|
||
Prior to each WG meeting the moderator will share the Agenda with | ||
members of the WG. WG members can add any items they like to the | ||
agenda at the beginning of each meeting. The moderator and the WG | ||
cannot veto or remove items. | ||
|
||
The moderator is responsible for summarizing the discussion of each | ||
agenda item and sends it as a pull request after the meeting. | ||
|
||
### Repository Management | ||
mhdawson marked this conversation as resolved.
Show resolved
Hide resolved
|
||
All repositories under the management of the package maintenance team must include: | ||
|
||
* LICENCE.md from the list approved by the OpenJS Foundation | ||
* CODE_OF_CONDUCT.md referencing the Node.js Code of conduct in the admin repo. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to adjust the wording to cover the fact that this will be in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was some discussion in the OpenJS Cross project council that at least for the CODE_OF_CONDUCT.md we may require a copy or link in the repo, otherwise it's not discoverable since you don't see it when looking in or cloning th erepo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would a link in the README suffice? That said, there's something comforting about that file just being present at the root of the repo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That was the sentiment, it's most easily discover-able and clear that there is one if the file is there at the root of the project. I think it could be a link to the shared one so that after it's committed it never needs an update. |
||
* CONTRIBUTING.md which includes the current version of the Developer Certificate of Origin (DCO) used by the Node.js Project | ||
* An PR template(s) used for all Pull requests which includes the current version of the DCO used by the Node.js Project. | ||
* A README.md which includes references to the GOVERNANCE.md in the package-maintenance repository as the authoritative governance which applies to the repository. | ||
|
||
#### nodejs/package-maintenance | ||
|
||
##### Maintainers | ||
|
||
Maintainers for the nodejs/package-maintenance repo are managed | ||
through the [package-maintenance](https://github.com/orgs/nodejs/teams/package-maintenance/) | ||
team. Administrative members are given the maintainer role for that team | ||
and can add/remove members as they join or leave the team. | ||
|
||
##### Landing PRs | ||
|
||
The package maintenance team policy on landing a PR in this repository | ||
is for there to be: | ||
- At least 4 approvals from regular members other than the author of the PR | ||
- No blocking reviews | ||
- 7 day period from the 4th approval to merging | ||
|
||
All PRs shall follow the [contributions policy](CONTRIBUTING.md) | ||
|
||
#### nodejs/ci-config-travis | ||
|
||
##### Maintainers | ||
|
||
Maintainers for this repository are managed | ||
through the [ci-config-travis-maintainers](https://github.com/orgs/nodejs/teams/ci-config-travis-maintainers/) | ||
team. Administrative members are given the maintainer role for that team | ||
and can add/remove members as appropriate. | ||
|
||
##### Landing PRs | ||
|
||
The package maintenance team policy on landing a PR in this repository | ||
is for there to be: | ||
- At least 2 approvals from package-maintenance members other than the author of the PR | ||
- No blocking reviews | ||
- 72 hours since the PR was openened | ||
|
||
#### nodejs/ci-config-github-actions | ||
|
||
##### Maintainers | ||
|
||
Maintainers for this repository are managed | ||
through the [ci-config-github-actions-maintainers](https://github.com/orgs/nodejs/teams/ci-config-github-actions-maintainers/) | ||
team. Administrative members are given the maintainer role for that team | ||
and can add/remove members as appropriate. | ||
|
||
##### Landing PRs | ||
|
||
The package maintenance team policy on landing a PR in this respositry | ||
is for there to be: | ||
- At least 2 approvals from package-maintenance members other than the author of the PR | ||
- No blocking reviews | ||
- 72 hours since the PR was openened | ||
|
||
#### pkgjs organization | ||
All members of the pkgjs organization will be required to have 2FA enabled, | ||
and the repository will be configured to enforce this requirement. | ||
|
||
mhdawson marked this conversation as resolved.
Show resolved
Hide resolved
|
||
##### Adding or removing repositories | ||
|
||
Any repository created under the Pkgjs GitHub Organization is considered to be | ||
a project under the ownership of the OpenJS Foundation, and thereby subject | ||
to the Intellectual Property and Governance policies of the Foundation. | ||
|
||
Any member may request the management of repositories within the | ||
Pkgjs GitHub Organization by opening an issue in the | ||
[package-maintenance repository][nodejs/package-maintenance]. | ||
The actions requested could be: | ||
|
||
- Creating a new repository | ||
- Deleting an existing repository | ||
- Archiving an existing repository | ||
- Transferring a repository into or out of the organization | ||
|
||
Provided there are no objections from any members raised in | ||
the issue, such requests are approved automatically after 72 hours. If any | ||
objection is made, the request may be moved to a vote | ||
of the Administrative members. | ||
|
||
In certain cases, OpenJS Cross Project Council and/or OpenJS Foundation Board | ||
of Directors approval may also be required. (Most likely in the case of | ||
transfeering a repository into or out of the organization). | ||
|
||
##### Maintainers | ||
|
||
Maintainers for the repositories in the Pkgjs repository are managed | ||
through a team created for each repository. They will be named as | ||
[REPO-maintainers](https://github.com/orgs/pkgjs/teams/REPO-maintainers/) | ||
where REPO is the name of the repository. Administrative members are given | ||
the maintainer role these team and can add/remove members as appropriate. | ||
In addition all maintainers for a given repository can add/remove | ||
maintainers are given the maintainer role for the teams for which they are | ||
added and can add/remove members as appropriate. | ||
|
||
##### Landing PRs | ||
|
||
The package maintenance team policy on landing a PR in the repositories within the Pkgjs | ||
repository is for there to be: | ||
- At least 1 approval from package-maintenance members other than the author of the PR, | ||
unless there is single maintainer for the repository. In that case the single maintainer | ||
can land their own PRs. | ||
- No blocking reviews | ||
- 72 hours since the PR was openened | ||
|
||
mhdawson marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Certain types of pull requests can be fast-tracked and may land after a shorter | ||
delay. For example: | ||
|
||
* Focused changes that affect only documentation and/or the test suite: | ||
* `code-and-learn` tasks often fall into this category. | ||
* `good-first-issue` pull requests may also be suitable. | ||
* Changes that fix regressions: | ||
* Regressions that break the workflow (red CI or broken compilation). | ||
* Regressions that happen right before a release, or reported soon after. | ||
|
||
To propose fast-tracking a pull request, apply the `fast-track` label. Then add | ||
a comment that Collaborators may upvote. | ||
|
||
If someone disagrees with the fast-tracking request, remove the label. Do not | ||
fast-track the pull request in that case. | ||
|
||
The pull request may be fast-tracked if two Collaborators approve the | ||
fast-tracking request. To land, the pull request itself still needs two | ||
Collaborator approvals and a passing CI. | ||
|
||
Collaborators may request fast-tracking of pull requests they did not author. | ||
In that case only, the request itself is also one fast-track approval. Upvote | ||
the comment anyway to avoid any doubt. | ||
|
||
### Consensus Seeking Process | ||
|
||
The WG follows a [Consensus Seeking][] decision-making model. | ||
|
||
When an agenda item has appeared to reach a consensus the moderator | ||
will ask "Does anyone object?" as a final call for dissent from the | ||
consensus. | ||
|
||
If an agenda item cannot reach a consensus a WG member can call for | ||
either a closing vote or a vote to table the issue to the next | ||
meeting. The call for a vote must be seconded by a majority of the WG | ||
or else the discussion will continue. Simple majority wins. | ||
|
||
Note that changes to administrative WG membership require | ||
consensus. If there are any objections to adding or removing | ||
individual members, an effort must be made to resolve | ||
those objections. If consensus cannot be reached, a | ||
vote may be called following the process above. Administrative | ||
members are responsible for voting in these cases. | ||
|
||
<a id="developers-certificate-of-origin"></a> | ||
## Developer's Certificate of Origin 1.1 | ||
|
||
By making a contribution to this project, I certify that: | ||
|
||
* (a) The contribution was created in whole or in part by me and I | ||
have the right to submit it under the open source license | ||
indicated in the file; or | ||
|
||
* (b) The contribution is based upon previous work that, to the best | ||
of my knowledge, is covered under an appropriate open source | ||
license and I have the right under that license to submit that | ||
work with modifications, whether created in whole or in part | ||
by me, under the same open source license (unless I am | ||
permitted to submit under a different license), as indicated | ||
in the file; or | ||
|
||
* (c) The contribution was provided directly to me by some other | ||
person who certified (a), (b) or (c) and I have not modified | ||
it. | ||
|
||
* (d) I understand and agree that this project and the contribution | ||
are public and that a record of the contribution (including all | ||
personal information I submit with it, including my sign-off) is | ||
maintained indefinitely and may be redistributed consistent with | ||
this project or the open source license(s) involved. | ||
|
||
[Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making | ||
[nodejs/package-maintenance]: https://github.com/nodejs/package-maintenance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a label and rephrase this as "Repositories with
pkgjs
label undernodejs
organization(s)"? Not sure if we need to mention thepkgjs
org here again.