You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Process for selecting CPC members representing Node.js project #316
This issue was opened to gather information on who/how many people might be interested in being the Node.js voting representatives: #314). This came out of a discussion in a TSC meeting with the thought that we should understand how many people might want to run for those positions before figuring out the election process.
It was tagged for discussion in the Community Committee and on review of those self-nominating it was suggested we should proceed to discuss a selection process. I took the action to open an issue to get that started.
Some of the questions (please add more as you think of them) that we need to answer.
Who is eligible to run for each of the 2 positions, TSC members, CommComm members,
other?
Who can cast votes, TSC members, CommComm members, any Node.js project member,
other?
What voting process should be used.
As a point of reference, the closest equivalent was the board representation under the previous Node.js foundation were we had 2 representatives. For one position, eligible candidates are members of the community committee and the candidates are voted on by community committee members. For the second, eligible candidates are members of the TSC and the candidates are voted on by TSC members.
I'm currently +1 for the same process as the existing process for directorship.
Surfacing some discussion around this from the last CommComm session. There was also suggestion that CommComm and TSC members be able to vote for the overall pool of applicants, while still being able to place exactly one voting member per leadership committee.
if the capacity of the voting members in CPC and scope of subject being voted by the voting members are same / equal between the 2 voting members, then I would imagine the 2 members be voted by both the teams, rather than in isolation.
As a point of reference, the closest equivalent was the board representation under the previous Node.js foundation were we had 2 representatives. For one position, eligible candidates are members of the community committee and the candidates are voted on by community committee members. For the second, eligible candidates are members of the TSC and the candidates are voted on by TSC members.
if the capacity of the voting members in CPC and scope of subject being voted by the voting members are same / equal between the 2 voting members, then I would imagine the 2 members be voted by both the teams, rather than in isolation.
This can introduce certain complexities that I'm not sure we want to try to deal with this first time around (but maybe if we want to modify the process next year). For example, if TSC has 20 members and CommComm has 12, does that mean CommComm's opinions will be under-represented in the vote result? Additionally, it complicates the vote procedure. Does each person get to vote for just one candidate and the top two win? Or does each person get two votes? Or is there a ranked-choice system of some kind?
For these reasons, I'm inclined to favor the simplicity of Myles's proposal this first time around. We can adjust later if it is warranted.
@Trott - I agree that the election process may be more complex with my suggestion. However, my view is that definition of representation takes front seat than the means to implement that. To me, I see two issues with the first(popular) approach:
It mkes two teams (TSC and CommComm) look isolated teams with perhaps split priorities
Personally, it makes me feel awkward that I am represented by someone whose selection process I have not taken part of.
Having said that, these (split priorities and awakward feelings) are hypothetical at the moment, and may prove to be a NOOP.
The majority of the comments seems to suggest we should stick to the existing process (for board members) and potentially consider changes for next year mostly due to the complexities around how voting might work. I think that would be good so that we don't delay identifying who the Node.js representatives will be.
@nodejs/tsc, @nodejs/community-committee any objections to following the existing process which would be:
1 CPC rep elected by TSC members
1 CPC rep elected by commcomm members
using processes that are similar to what was done to elect the board representatives?
Reacted by Tierney Cyren, Adam Miller, Rich Trott, Ahmad Awais, Waleed Ashraf and Sagir Khan
Activity
mhdawson commentedon Mar 22, 2019
@nodejs/community-committee @nodejs/tsc
MylesBorins commentedon Mar 22, 2019
I think we should move forward with the exact same process we had for directors.
1 for TSC, 1 for commcomm
TSC votes for their rep, CommComm for theirs
Trott commentedon Mar 22, 2019
I do like the simplicity of this.
mcollina commentedon Mar 22, 2019
+1
keywordnew commentedon Mar 23, 2019
I'm currently +1 for the same process as the existing process for directorship.
Surfacing some discussion around this from the last CommComm session. There was also suggestion that CommComm and TSC members be able to vote for the overall pool of applicants, while still being able to place exactly one voting member per leadership committee.
mhdawson commentedon Mar 26, 2019
I'm +1 for the same process we had for directors.
Trott commentedon Mar 26, 2019
/ping @nodejs/tsc Would be great to get decisive consensus on this on the TSC side.
gabrielschulhof commentedon Mar 26, 2019
The existing process sounds good. +1
cjihrig commentedon Mar 26, 2019
+1 to using the existing process.
gireeshpunathil commentedon Mar 26, 2019
if the capacity of the voting members in CPC and scope of subject being voted by the voting members are same / equal between the 2 voting members, then I would imagine the 2 members be voted by both the teams, rather than in isolation.
So an alternate proposal is:
thefourtheye commentedon Mar 26, 2019
This sounds good. +1
danbev commentedon Mar 26, 2019
+1 to using the existing process.
WaleedAshraf commentedon Mar 26, 2019
+1 for existing process
apapirovski commentedon Mar 27, 2019
+1 to existing process
Trott commentedon Mar 27, 2019
This can introduce certain complexities that I'm not sure we want to try to deal with this first time around (but maybe if we want to modify the process next year). For example, if TSC has 20 members and CommComm has 12, does that mean CommComm's opinions will be under-represented in the vote result? Additionally, it complicates the vote procedure. Does each person get to vote for just one candidate and the top two win? Or does each person get two votes? Or is there a ranked-choice system of some kind?
For these reasons, I'm inclined to favor the simplicity of Myles's proposal this first time around. We can adjust later if it is warranted.
ChALkeR commentedon Mar 27, 2019
The existing process looks good, +1.
gireeshpunathil commentedon Mar 28, 2019
@Trott - I agree that the election process may be more complex with my suggestion. However, my view is that definition of
representationtakes front seat than the means to implement that. To me, I see two issues with the first(popular) approach:Having said that, these (split priorities and awakward feelings) are hypothetical at the moment, and may prove to be a NOOP.
mhdawson commentedon Apr 2, 2019
The majority of the comments seems to suggest we should stick to the existing process (for board members) and potentially consider changes for next year mostly due to the complexities around how voting might work. I think that would be good so that we don't delay identifying who the Node.js representatives will be.
@nodejs/tsc, @nodejs/community-committee any objections to following the existing process which would be:
1 CPC rep elected by TSC members
1 CPC rep elected by commcomm members
using processes that are similar to what was done to elect the board representatives?
bnb commentedon Apr 2, 2019
No objection.
ahmadawais commentedon Apr 2, 2019
Definitely +1 on moving with the current process.
sagirk commentedon Apr 8, 2019
No objection.
mhdawson commentedon Apr 8, 2019
Ok, I see only agreement with the last suggestion that we proceed with 1 rep for the TSC and one for commcomm as suggested above.
Trott commentedon Jul 5, 2019
Seems like this can be closed, but if I'm wrong, re-open, of course!