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

feat: create project charter #25

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

feat: create project charter #25

wants to merge 5 commits into from

Conversation

achrinza
Copy link
Member

closes: #22

Signed-off-by: Rifa Achrinza [email protected]

closes: #22

Signed-off-by: Rifa Achrinza <[email protected]>
Copy link
Member

@dhmlau dhmlau left a 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_
Copy link
Member

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?

Copy link
Member Author

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.


ex. [K8s SIG Architecture Charter](https://github.com/kubernetes/community/blob/HEAD/sig-architecture/charter.md#out-of-scope)

Section Intentionally Left Blank
Copy link
Member

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,
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@achrinza
Copy link
Member Author

@achrinza
Copy link
Member Author

achrinza commented Apr 26, 2022

We're limited in modifying the Project Charter in accordance with https://github.com/openjs-foundation/cross-project-council/blob/2b48ff7084f794056fb2a9147fe74561b832dab2/governance/GOVERNANCE.md:

Approving Project Charters

Per the [CPC charter section 5][], the voting CPC members are responsible for approving project
charters and changes to them.

Approval of the initial charter or changes to an existing charter will
be requested by opening an issue requesting approval in the cross-project-council
[repository][cpc repo].

The request is approved when:

  • There are no outstanding objections
  • There are two or more approvals by voting CPC members
  • The board has been consulted in the case of substantial changes
  • The issue has been open for at least 14 days

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.

Copy link
Member

@dhmlau dhmlau left a 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.

docs/project-charter.md Outdated Show resolved Hide resolved
docs/project-charter.md Outdated Show resolved Hide resolved
docs/project-charter.md Outdated Show resolved Hide resolved
docs/project-charter.md Outdated Show resolved Hide resolved
- Creating new releases
- Release quality standards
- Technical direction
- GitHub repository hosting
Copy link
Member Author

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):

Suggested change
- 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
Copy link
Member Author

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.

Suggested change
- 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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Comment on lines +108 to +110
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.
Copy link
Member Author

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.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a project charter
2 participants