-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: create project charter #25
base: master
Are you sure you want to change the base?
Conversation
closes: #22 Signed-off-by: Rifa Achrinza <[email protected]>
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.
@achrinza, thanks for raising this PR! Please see my comments.
I'd like to do some more research on my side on what other OpenJS foundation projects have and give more review comments.
@@ -0,0 +1,196 @@ | |||
# LoopBack Charter | |||
|
|||
_note: the purpose of a project charter is to provide a brief introduction_ |
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 assume the text in italic (i.e. note, directions, ex) will be removed eventually and it's there now just to help 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.
Yes, these would be removed before landing the PR. I've left them there to make it easier to review.
docs/project-charter.md
Outdated
|
||
ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#out-of-scope) | ||
|
||
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.
I also looked at the one from fastify. Might be good to use it as a reference: https://github.com/fastify/fastify/blob/main/PROJECT_CHARTER.md#12-out-of-scope.
particulary:
- Support versions of Node.js at EOL (end of life) stage
- Contributions that violates the Code of Conduct
|
||
ex. [Node.js TSC Charter](https://github.com/nodejs/TSC/blob/HEAD/TSC-Charter.md#section-6-elections) | ||
|
||
Unless stated otherwise, the LoopBack TSC adopts a lazy consensus voting system, |
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.
For voting, I wonder if we want to have at least another "for" vote (or half of TSC agree) and no objections, before going forward.
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'm open to getting at least one more explicit "for" vote. Getting half of the TSC to vote (3 votes) may be a bit difficult as we don't have any provisions to enforce participation of TSC members.
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.
make sense. "at least one for vote" works for me.
For more important matters such as the nomination of new TSC members, a lazy | ||
consensus for a stipulated period of no less than 1 week is used instead. | ||
|
||
These votes must be done through a process that's accessible to the general |
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.
For voting to approve/reject a contributor to maintainer, the votes are not public in the current process.
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 the TSC voting process be private as well?
We may also want to state the criteria of being TSC nominee, such as:
- An existing LoopBack Maintainer for at least 1 year
- Has actively contributed to the Project in the past 90 days
- Is willing to actively partake in governance-related matters
We may also want to draft a standard "nomination form" and process similar to becoming a Maintainer.
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 the TSC voting process be private as well?
sounds good as it falls under the category, IMHO.
We're limited in modifying the Project Charter in accordance with https://github.com/openjs-foundation/cross-project-council/blob/2b48ff7084f794056fb2a9147fe74561b832dab2/governance/GOVERNANCE.md:
We may want to consider separating "operational processes" such as voting, consensus, workflows, etc. into a dedicated GOVERNANCE document, which would, AFAIK, not require OpenJSF approval for modification unlike the Project Charter. TSC approval process of Project Charter hasn't been formally ratified, but is documented at https://github.com/openjs-foundation/cross-project-council/blob/2b48ff7084f794056fb2a9147fe74561b832dab2/proposals/incubating/CHARTER_REVIEW/README.md It's also briefly mentioned in https://github.com/openjs-foundation/cross-project-council/blob/4e801af388d03edaf370e734fb9e6e6a633ade7e/CPC-CHARTER.md#section-5-responsibilities-and-expectations-of-the-cpc Point 7. |
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.
@achrinza, sorry about the delay. Looking up the Node.js and Fastify project charter as reference, here are my comments. To me, it's generally good to go. Thanks.
Co-authored-by: Diana Lau <[email protected]>
Co-authored-by: Diana Lau <[email protected]>
Co-authored-by: Diana Lau <[email protected]>
Co-authored-by: Diana Lau <[email protected]>
- Creating new releases | ||
- Release quality standards | ||
- Technical direction | ||
- GitHub repository hosting |
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 like to expand this to encompass alternate hosting (i.e. mirroring):
- GitHub repository hosting | |
- GitHub repository hosting | |
- Repository mirror hosting |
- Conduct guidelines and enforcement | ||
- Maintaing the list of LoopBack Maintainers | ||
- Mediating technical conflicts between Collaborators or Foundation projects | ||
- Hosting and publishing the monthy LoopBack Maintainers Call |
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.
Likewise, I think it's good to have a catch-all so that we don't have to amend this charter as frequently.
Also, typo.
- Hosting and publishing the monthy LoopBack Maintainers Call | |
- Hosting and publishing the monthly LoopBack Maintainers Call and other meetings |
|
||
Technical leadership for the projects within the OpenJS Foundation is delegated | ||
to the projects through their project charters by the OpenJS Foundation Cross | ||
Project Council (CPC). In the case of LoopBack, it is delegated to the LoopBack |
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 Council (CPC). In the case of LoopBack, it is delegated to the LoopBack | |
Project Council ("CPC"). In the case of LoopBack, it is delegated to the LoopBack |
must have at least four members. Although there are no hard requirements, the | ||
composition of the TSC should aim for geographic and employer diversity in the | ||
spirit of a distributed maintenance model. |
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 we already meet the requirements, could we further restrict the TSC composition requirements to align with the OpenJS Foundation Growth Project requirements? Specifically, this part:
Governing body of >= 5 members of which no more than 1/3 is affiliated with the same employer.
Likewise, this means we need to document our employer affiliation - AFAIK, the governance structure from our project application form is still correct.
We'll also need to document the expectation that the TSC members keep this documentation up-to-date.
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.
IIUC, the Growth project requirements are for the projects wanting to be "impact" stage. I wouldn't worry about it for now.
closes: #22
Signed-off-by: Rifa Achrinza [email protected]