doc: update CPC membership and responsibilities#65
Conversation
Update based on discuss in most recent bootstrap meeting to reflect voting and regular members along with responsibilities.
|
|
||
| =========== | ||
|
|
||
| The CPC is in inclusive group with 2 types of members: |
There was a problem hiding this comment.
The CPC is an inclusive
Update: add as suggestion
| The CPC is in inclusive group with 2 types of members: | |
| The CPC is an inclusive group with 2 types of members: |
| **Regular members** Regular members have the roles and responsibilities | ||
| as outlined below. In any case where it is not specified that a role | ||
| or responsibility applies to a Voting member, then a Regular member is | ||
| implied. Any member of one of the projects under the foundation may request to |
There was a problem hiding this comment.
What does it mean to be a "member of one of the projects under the foundation" and is that a restriction to becoming a regular member of the CPC?
There was a problem hiding this comment.
In the case of Node.js with would be anybody who is in the "members" org. I think each project would be able to define what they considered their "members" to be. As written is was intended that it be a restriction to becoming a regular member of the CPC.
| employment by a Voting CPC member, creates a situation where more than | ||
| one-fourth of the Voting CPC membership shares an employer, then the situation | ||
| must be immediately remedied by the resignation or removal of one or more | ||
| PC |
There was a problem hiding this comment.
Considering that CPC voting members are elected by projects, should we give projects the chance to elect another member before resignation? I would like to avoid the situation where a project has both his voting members out because of this.
There was a problem hiding this comment.
I'm not sure we can stop somebody from resigning other than asking them to provide some time for a new election.
There was a problem hiding this comment.
I think a top level project should always have 2 voting members. Up until somebody new is elected by the project, the previous member is still voting.
|
Based on this proposal, how many Board members the CPC could elect? |
|
@mcollina as written it is 1, which is captured in "Section 7. Elections". What is written there is 1 Chairperson and 1 Board rep. |
With a 2 committees proposal, we had 2 board seats. How many Boards seats are planned for project representation? |
|
@mcollina I just wrote the 1 as I was borrowing some text from what we used in Node.js. If we believe the CPC needs more board representation we can write in the number we think is needed. What do you think we should ask for? |
I do not have an answer, maybe we should put int the README as one of the things that needs to be discussed and validated. |
|
@mcollina added to the README.md as suggested. |
|
+1 |
|
@joesepi I think I addressed all of your comments. |
boneskull
left a comment
boneskull
left a comment
There was a problem hiding this comment.
sorry about my grammar policing 👮
I like what I'm reading here, but would love some clarification on a few things. Thanks for writing this up.
| nominated these members must be ratified by the board before | ||
| becoming a Voting member. | ||
|
|
||
| Voting members are expected to make a time commitment that |
There was a problem hiding this comment.
What happens if a voting member is flaky?
Voting members might not be able to participate in "all voting matters". I don't really know what that means, but if it means "attend meetings in which voting takes place and vote or abstain" maybe that should be spelled out.
There was a problem hiding this comment.
If a member does not meet the expectations then it would be up to the rest of the CPC to ask that they step down as per
Voting members serve for a term of 1 year and must be re-nominated
and ratified by the board each year. In addition, a Voting CPC member
can be removed by by voluntary resignation, by a standard CPC motion,
or in accordance to the participation rules described for Regular
members.
In terms of participating in "all voting matters" I add the clarification that means vote or abstain. I'd like to leave that as the expectation with the understanding that in reality, all members will not necessarily be able to vote (holidays etc.) but that they will make all efforts to do so.
| of their choosing. Once nominated the member must be ratified by the | ||
| board before becoming a Voting member. | ||
|
|
||
| * 2 Voting members may be nominated by the non top-level projects. |
There was a problem hiding this comment.
I'm not sure how we're going to get a bunch of non-top-level projects to organically collaborate on this. we might want to impose some sort of Process here.
There was a problem hiding this comment.
I'd agree. I don't think we need to codify the process in the charter, but I will add that it will be based on a process set by the CPC.
|
|
||
| * Each top level project may nominate 2 member through a process | ||
| of their choosing. Once nominated the member must be ratified by the | ||
| board before becoming a Voting member. |
There was a problem hiding this comment.
why does the member need to be approved by the board? what would cause a member not to be approved?
There was a problem hiding this comment.
Part of this comes from the discussion of Board representatives. The Board has to work with them directly and therefore would like some input. Similarly, the Board works with and depends on the CPC voting members and would like some input. Realistically I think it would be an exceptional situation where the Board would not be ratified. Having said that we could discuss if we need to keep that.
There was a problem hiding this comment.
s/by the board/by the CPC
IMHO the board shouldn't have oversight about this. The CPC, as chartered, is given the responsibility of handling this. It is my impression that the board will not have the time to manage something like this and it will end up becoming a blocker.
|
|
||
| * 2 Voting members may be nominated by the non top-level projects. | ||
| If a vote is required among candidates nominated by different projects, | ||
| each of the non-top level projects will have 2 votes (one for each position). |
There was a problem hiding this comment.
I don't understand this... are we talking about voting for voting membership? I'm confused.
There was a problem hiding this comment.
What I meant it to say was that if there are candidates from multiple projects and consensus on the 2 selections cannot be reached then a vote will be held and each project will have 2 votes, one for each position. Given that we have added that the process will be set by the CPC , I'll just remove this detail.
|
@boneskull thanks for the review, I think I've asked your questions and made the requested fixes. |
MylesBorins
left a comment
MylesBorins
left a comment
There was a problem hiding this comment.
A bunch of comments inline
- I think it should be more explicit early on that various responsibilities can be delegated.
- There is a hard balance here between allowing projects to have autonomy while also enforcing shared expectations for Top-Level projects. I think the language we have right now is not quite there to support this
- I'd like to see more language around the CPC being a body to manage interpersonal conflict escalation as well as technical conflict escalation
Thanks for all the hard work Michael, this is a great first iteration
| * Regular members | ||
| * Voting members | ||
|
|
||
| ### Regular members |
There was a problem hiding this comment.
I still think that we don't need this membership class. Much less friction to just make the meetings open and have explicit voting members
There was a problem hiding this comment.
I think the meetings can still be open. I think there is a difference between people who simply want to observe/attend versus those who are going to participate actively. It is much easier to word things as a responsibility of the CPC when there are Regular members. It's harder to say X is a responsibility of whoever just happens to show up at meetings. At the same time we want it to be inclusive so we don't want to say X is a responsibility of the CPC where that implies just the subset that would be the voting members in what is outlined here.
I'd be happy to add wording that makes it clear that meetings will be open and that anybody can participate, but I think having the concept of regular members does add value. We could possibly introduce "observers" who are free to attend but who don't necessarily have any responsibilities.
There was a problem hiding this comment.
I've updated with 5a6138e. to add the concept of an observer.
To test out how it would be without regular members, just drop out "Voting Members" from the types of participants and references to "Voting members". I think it would the read like the smaller CPC (what was just the Voting members") is responsible for all of that as opposed the larger group of people we'd like to be involved. I really do think there should be a difference between people who just want to observers versus actively participate in an ongoing manner.
There was a problem hiding this comment.
We should discuss the balance between autonomy/enforcement in the next meeting as well as the interpersonal conflict side of things. I think that is needed before I'd be comfortable in adding too much on that front.
|
|
||
| * Each top level project may nominate 2 member through a process | ||
| of their choosing. Once nominated the member must be ratified by the | ||
| board before becoming a Voting member. |
There was a problem hiding this comment.
s/by the board/by the CPC
IMHO the board shouldn't have oversight about this. The CPC, as chartered, is given the responsibility of handling this. It is my impression that the board will not have the time to manage something like this and it will end up becoming a blocker.
| * two Voting members may be nominated by the non top-level projects based | ||
| on a process set by the CPC. | ||
|
|
||
| * two Voting members may be nominated by the Regular members. Once |
There was a problem hiding this comment.
As I don't think we need regular members I think this section should be removed. Even if we kept the regular members this seems excessive
There was a problem hiding this comment.
In what sense is it excessive. My thinking is that we will have people who are active in the projects and therefore represent the projects on the CPC. At the same time we may have people who are very active at the CPC level but less so at the project level. I think we should have some ability to get those people into the Voting group.
I w
There was a problem hiding this comment.
I will update to change ratification to be by the CPC as a first step.
| board and Foundation staff and to generally help keep things moving. | ||
|
|
||
| Voting members serve for a term of 1 year and must be re-nominated | ||
| and ratified by the board each year. In addition, a Voting CPC member |
There was a problem hiding this comment.
s/by the board/by the cpc
| removal of one or more voting CPC members. | ||
|
|
||
| The CPC may, at its discretion, invite any number of non-voting observers to | ||
| participate in the public portion of CPC discussions and meetings. |
There was a problem hiding this comment.
All contributors of all projects should be invited to participate in all public sessions. It should be part of the charter for the CPC to encourage active participation
| 1. Guiding projects into appropriate Foundation paths. | ||
| 1. Shared resources, tooling and funding for projects and Commons.js (Events | ||
| Collaborator Summit, Travel fund). | ||
| 1. Code of Conduct incident response support. |
There was a problem hiding this comment.
This might be escalation... but the current way it is worded sounds like CPC would manage all COC incidents... which is not exactly scalable or appropriate
There was a problem hiding this comment.
Perhaps we should have explicit language around "ensuring projects properly enforce code of conduct violations" and how to escalate when appropriate.
Language to be split between charter + policy
There was a problem hiding this comment.
I think that came from what was brainstormed for the C3. I think going beyond "support" needs some consensus building. We need to agree as a group if the Foundation/CPC will require a minimal CoC from the projects at that point then it makes sense to include that.
There was a problem hiding this comment.
I've changed to Supporting projects in their enforcement of Code of Conduct violations and escalation. for now.
| such as new project acceptance into the mentorship program, project graduation | ||
| from the mentorship program, Project issues and conflicts, opportunities | ||
| for collaboration between Projects, opportunities for the Foundation in the | ||
| greater JavaScript community, etc. |
There was a problem hiding this comment.
this seems to have been implied above, is there a need for this?
| from the mentorship program, Project issues and conflicts, opportunities | ||
| for collaboration between Projects, opportunities for the Foundation in the | ||
| greater JavaScript community, etc. | ||
| 1. When needed, members of the CPC will be expected to create subcommittees |
There was a problem hiding this comment.
This should be the first point imho... a bunch of my prior notes may be resolved by this
There was a problem hiding this comment.
Will move, makes sense to me
| these groups to make decisions. | ||
|
|
||
|
|
||
| ## Section 6. Non-Responsibilities of the CPC |
There was a problem hiding this comment.
Some of these conflict.. specifically project governance (re: coc), github repository hosting (do people have to host on github), conduct guidelines (re: coc again / leadership guidelines), process / coding standards (likely a gate for top level projects), Mediating technical conflicts between Collaborators (based on current above charter
There was a problem hiding this comment.
I think we should talk through that at the next meeting as a number of these were requested as part of the earlier discussion so I don't think we have consensus that the CPC should be mandating some of these to the projects.
| @@ -242,15 +211,6 @@ the same person. The CPC shall hold annual elections to select a CPC | |||
| Chairperson and Director; there are no limits on the number of terms a | |||
| CPC Chairperson or Director may serve. | |||
There was a problem hiding this comment.
The TC39 has recently implemented a Chair Group, which we are hoping will be quite effective. Based on the scale of this role in the larger foundation we may want to consider this... it would also help distribute the responsibility across projects... also helping with growth of more junior individuals who may not feel comfortable taking on the entire role.
There was a problem hiding this comment.
Do you have a reference/link with more info on that approach?
|
@MylesBorins thanks for the comments. I think I've updated or responded to all of your comments. I think we need to discuss the following in the next meeting to close on some of the comments:
In terms of interpersonal conflict if you can provide a paragraph or a few lines that reflect what you are thinking I can see how they fit in. |
|
Landed as discussed in today's meeting. I'll be opening a follow up PR to expand on specifics |
6 participants
Update based on discuss in most recent bootstrap meeting
to reflect voting and regular members along with
responsibilities.