Skip to content
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

Merged
merged 31 commits into from
Jul 2, 2020
Merged
Changes from all commits
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
5be42b3
doc: initial draft of docs for chartering
mhdawson Apr 17, 2020
ca4b8b3
Update Governance.md
mhdawson Apr 17, 2020
0cdce7c
Update Charter.md
mhdawson Apr 21, 2020
f3246a7
Update Governance.md
mhdawson Apr 21, 2020
45f7844
Update Charter.md
mhdawson Apr 21, 2020
ee04245
Update Governance.md
mhdawson Apr 21, 2020
825f0c1
Update README.md
mhdawson Apr 21, 2020
d8e5487
Update Governance.md
mhdawson Apr 21, 2020
7e22760
squash: address comments
mhdawson Apr 21, 2020
3502fc0
Update Governance.md
mhdawson Apr 21, 2020
226edf3
Update Governance.md
mhdawson Apr 21, 2020
b1871e8
Update Governance.md
mhdawson Apr 21, 2020
2fb0ebd
Update Charter.md
mhdawson Apr 24, 2020
1ee6175
Update Governance.md
mhdawson Apr 24, 2020
5f1d5c4
Update Governance.md
mhdawson Apr 24, 2020
a9eef1e
Update Governance.md
mhdawson Apr 24, 2020
f01f8ba
Update Governance.md
mhdawson Apr 24, 2020
6007e78
Update Governance.md
mhdawson Apr 24, 2020
c79c3d4
Update Governance.md
mhdawson Apr 24, 2020
b373318
Update Charter.md
mhdawson Apr 24, 2020
14a9b0b
Update Governance.md
mhdawson Apr 24, 2020
a804e87
Update Governance.md
mhdawson Apr 24, 2020
638e9e9
Update Governance.md
mhdawson Apr 24, 2020
dc9a5b1
squash: address comments
mhdawson Apr 29, 2020
f856669
squash: address comments in last meeting.
mhdawson May 6, 2020
579292c
Update README.md
mhdawson May 25, 2020
0c9f597
Update Governance.md
mhdawson May 25, 2020
41fbdf6
Update Governance.md
mhdawson May 25, 2020
2cc9e3a
Update Governance.md
mhdawson May 25, 2020
a465ee1
Update Governance.md
mhdawson May 25, 2020
8530103
Update Governance.md
mhdawson May 25, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions Charter.md
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
Copy link
Member

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 under nodejs organization(s)"? Not sure if we need to mention the pkgjs org here again.

* 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
269 changes: 269 additions & 0 deletions Governance.md
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.
Copy link
Member

Choose a reason for hiding this comment

The 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 .github repo?

Copy link
Member Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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
23 changes: 20 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
@@ -36,10 +36,25 @@ in the issues within the repository.

## How to Join

If you'd like to be listed as a team member, open a PR adding yourself
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 this [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.

For more details refer to the WG Governance document.

## Logistics

### Meetings
@@ -65,15 +80,17 @@ to be accepted: it is a manual workflow, so it could take some days (we are work

## Pull Request Merging Policy

The package maintenance team policy on PR closure is for there to be
- At least 4 approvals
The package maintenance team policy on landing a PR in the nodejs/package-maintenance
repository is for there to be:
- At least 4 approvals from regular members
- No blocking reviews
- 7 day period from the 4th approval to merging

All PRs shall follow the [contributions policy](CONTRIBUTING.md)

## Current Project Team Members

[See the list of Administrative Members](./ADMINISTRATIVE-MEMBERS.md)
[See the list of Members](./MEMBERS.md)

## Emeritus Project Team Members