-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
chore: add charter #14948
chore: add charter #14948
Conversation
✅ Deploy Preview for jestjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
LGTM, fwiw :-)
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.
LGTM! (Approving as fellow OpenJS CPC member)
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.
A few proposed suggestions. Overall, this looks good!
PROJECT_CHARTER.md
Outdated
|
||
- _Outside Contributors_: contribute code or other artifacts, but do not have the right to commit to the codebase. Contributors work with the project’s maintainers to have code committed to the code base. An Outside Contributor may be promoted to a Contributor or Maintainer by the Maintainers. Outside Contributors should rarely be encumbered by the Maintainers and never by the CPC or OpenJS Foundation Board. | ||
|
||
- _Contributors_: Contributors have triaging rights and commit access to the repository. | ||
|
||
- _Maintainers_: Contributors with any kind of decision-making authority in the project, and access to publishing and CI setup. | ||
|
||
[openjs foundation]: https://openjsf.org |
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.
I'd lighten this section a bit and avoid anything that feels like an implementation detail of the charter. For example, stating that contributors have commit access to the repository forces you to go through a CPC charter modification process the day you want change that.
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.
specifically the commit access, or triaging etc as well? I essentially wanted to capture the different accesses GH provides
But with merging "maintainer" and "admin". I guess just having triaging makes sense. And actually what I want in the future, as I wanna set up CI publishing, and that would mean push access is enough to trigger a release.
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.
I'd frame this outside of GH roles and would avoid the internal/external terminology for contributors (which tends to be tied to differentiating employee and non-employee contributors in corporate open source settings). You also don't really need to define non-core contributors. So you could go with something very light-weight, for example:
Maintainers: responsible for the technical direction of the project and for release management.
Core contributors: Maintainers delegate project responsibilities to core contributors, as documented in governance.md.
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.
@SimenB does adjusting this section to just be the following make sense?
Maintainers: responsible for the technical direction of the project and for release management.
Core contributors: Maintainers delegate project responsibilities to core contributors, as documented in governance.md.
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.
PROJECT_CHARTER.md
Outdated
|
||
### Section 4.2: Decision-making, Voting, and/or Elections | ||
|
||
Section Intentionally Left Blank |
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.
It would be nice to state who makes project decisions and how (is it by consensus, voting, etc.)
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.
Since I'm the only active maintainer, I don't know what to put here that's. I'd love for there to be more stakeholders/maintainers involved in the process (and in maintaining the project as a whole), but at the moment any voting/consensus would just be myself 😅
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.
I think you being candid about it and being a little aspirational here would make total sense, e.g.
When the project was onboarded, it only had one maintainer. The goal is to grow the pool of maintainers and to collectively define a consensus-driven governance model that will be defined in GOVERNANCE.md.
or:
The project will define a consensus-driven governance model in GOVERNANCE.md as need arises.
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.
I think Tobie's second suggestion will work well and provides future flexibility.
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.
Co-authored-by: Tobie Langel <[email protected]>
Lgtm |
Hey! The CPC was wondering if the various comments had been addressed and whether we could move forward with the review. |
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.
lgtm
@tobie @bensternthal sorry about the delay, I've had a bout of mini burnout in the last couple of months and have focused on other projects besides Jest 😅 Hopefully the tweaks I just pushed allows us to move this forward! |
LGTM! |
@SimenB feel free to merge \o/ |
Co-authored-by: Jordan Harband <[email protected]>
Thanks, folks 👍 |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
This text is like 95% pure copy from @ljharb's work in https://github.com/nvm-sh/nvm, so big thanks to him for authoring minimal versions I could base it off of 😀 Hopefully this amount of copying is fine, and I did 't miss anything
My main changes (beyond describing Jest rather than
nvm
😅) is to add an addition "layer" of contributors in between external contributors and admins. Hopefully that makes sense?Closes #14927
Test plan
Review by people who can approve the text within.