charter: add TSC membership terms, mandatory mediation, and removal requirements #318
Conversation
|
I don't think term limits are necessary, although I won't object if everyone else thinks they're a good idea. I do however think that terms are a good idea regardless of whether we impose term limits. You should need to be re-approved by the rest of the TSC every year or so. It's good to remind people to consider whether they want to continue on the committee every so often, rather than leaving it up to them to figure out when to consider if they want to resign their appointment-for-life. As we've seen in practice, people sometimes wait a loooong time after becoming inactive before they decide to step down. |
|
I'm good either way. I prefer the term limits as it sends a stronger message that this is not a permanent standing body but a rotating one that should evolve as the project evolves. It also enforces a period of down time and helps reduce the pressure that exists from employers that their people remain in the role -- that is, the term is two years, regardless of what your employer may want, etc. |
|
I'm not sure about the term limits for the CTC tasks (and this would have an effect on CTC once CTC and TSC merge).
|
|
As I've said, I've no problem with relaxing the term limits. However, I want to find an approach that moves us away from this idea that TSC/CTC membership is a permanent status. I'll work up some wording. |
|
Please take a look |
|
The new wording regarding the terms looks good to me and resolves my concerns. |
TSC-Charter.md
Outdated
| ## Section 11. Escalation of Disputes and Code of Conduct Violations | ||
|
|
||
| Participation in the Node.js project is governed by a Code of Conduct policy | ||
| that is established by the TSC. Any accusations of Code of Conduct or policy |
There was a problem hiding this comment.
This seems like it could be subject to abuse if "any" accusation leads to third party mediation.
Perhaps `Code of Conduct violations that involve TSC members that cannot be solved via consensus will be referred to binding, independent third party mediation under the oversight of the Node.js Foundation Board.
There was a problem hiding this comment.
We end up in the same boat with the same hand wringing, delays and interpersonal issues. Going immediately to mediation is better. It doesn't have to be involved. This essentially just means that the Foundation picks someone to look at the issue and decide.
There was a problem hiding this comment.
Nit: Instead of accusations of Code of Conduct or policy violations, it may be less loaded to describe them as reports of Code of Conduct or policy violations or complaints rather than accusations.
There was a problem hiding this comment.
I've updated the language here.
TSC-Charter.md
Outdated
| to the TSC multiple times but at least one year must pass between terms. | ||
| TSC memberships are for one year terms that must be recertified by a simple | ||
| majority of TSC members every year. Recertified members will continue through | ||
| the next years term. Members failing recertification may return to the TSC |
There was a problem hiding this comment.
Nit: years -> year's
Question: What does "failing recertification" mean? Does that mean they forget to put in a motion to get recertified? Or does that mean the TSC opted not to renew their term? Whatever the answer, can we clarify the wording to that effect?
There was a problem hiding this comment.
What do you recommend here?
There was a problem hiding this comment.
@Trott, I've updated the language. Please let me know if I've Whacked-The-Mole adequately.
TSC-Charter.md
Outdated
| ## Section 11. Escalation of Disputes and Code of Conduct Violations | ||
|
|
||
| Participation in the Node.js project is governed by a Code of Conduct policy | ||
| that is established by the TSC. The TSC is required to established a policy |
There was a problem hiding this comment.
s/established/establish/
|
I would prefer if a separate appointed team not of the TSC/CTC/CommComm was in change of regular moderation and the "mandatory mediation" be reserved for conflicts internal to that team or perhaps with the committees (but I worry that would disempower the said moderation team). |
|
That being said, the "mandatory mediation" is certainly better than any process about that as it is today. |
|
All.. I have updated the proposal to include specific requirements for removal votes that I feel are critical moving forward. |
jasnell
changed the title
jasnell
changed the title
|
@Fishrock123 ... the updated Moderation policy proposal establishes a separate Moderation Team whose members are subject to approval by both the TSC and CommComm. The members must be Collaborators but are not limited to TSC/CommComm members. We should not have a requirement that Moderation Team members are not TSC/CommComm members because that limits our ability to nominate new members from that team to the TSC or CommComm, and I do not believe that is something we should do. The Moderation Team needs to be empowered to moderate both the TSC and CommComm. The policy, however, would state that disputes involving either would automatically go to arbitration, providing that higher bar that I believe you're looking for. |
So Core collaborators not org members right? |
|
Yes |
TSC-Charter.md
Outdated
| being asked to consider. The member in question shall be given no less than one | ||
| week before the vote to provide an answer or rebuttal to those issues. | ||
|
|
||
| Neither the member in question, nor the member or members raising the issue |
There was a problem hiding this comment.
I'm not sure I agree with this...it seems like that increases the likelihood of the member in question not being removed. Especially if more than one member raises the issue.
Example:
Say there are 10 members on the TSC. 4 members step forward and raise an issue to remove another member. This would mean that there are only 5 votes that can be cast. If 3 members vote against, and 2 members vote for, the vote would not pass, which to me seems....quite problematic?
There was a problem hiding this comment.
Potentially, but it also justifies referring the issue to arbitration, which can be requested either by those submitting the request, the person being considered for removal, or the TSC Chair. The decision can also be vacated by the Collaborator base or the Node.js Foundation Board, so there are contingencies and mitigations included.
The purpose of this clause is to avoid the possibility of railroading an individual off the committee and I believe it's necessary.
There was a problem hiding this comment.
Would an option be to allow both the raisers and the member in question. If its one raiser then they will balance out, otherwise more raisers end up with more weight ?
There was a problem hiding this comment.
No, I think that ends up creating an imbalance and does not avoid the possibility of railroading the decision.
There was a problem hiding this comment.
I believe that the way this is currently worded creates an imbalance. I'm not seeing this is a railroading of the decision either. If 4 people come forward with issues with another member, then those four people don't get to vote on whether or not to remove the individual. For any other matter, one can simply call a vote and their votes be counted. Why does it have to be different here? This would make it even more difficult to remove a toxic member from the project. To me, this enables one of the problems it is trying to solve even more.
There was a problem hiding this comment.
Ok, noted. I'll pull this back out.
|
|
||
| There is no maximum size of the TSC. The size is expected to vary in order to | ||
| ensure adequate coverage of important areas of expertise, balanced with the | ||
| ability to make decisions efficiently. The TSC must have at least three members. |
There was a problem hiding this comment.
I would suggest a higher number, at least 5, given the TSC’s responsibility 3 people is to few. I would also suggest to document what happens if the number falls below the minimum.
Another topic that might fit better into a follow up pull request is to require "active" members, and define what "active" means, to avoid a situation where people are voted into the board without fulfilling their responsibilities.
There was a problem hiding this comment.
-1 on making the minimum five. What happens if the number falls below this is the responsibility of the Node.js Foundation Board to determine.
There was a problem hiding this comment.
Regarding "active" members, the TSC recently passed modification to the TSC Charter that includes specific guidelines around TSC member activity. Specifically, there is a minimum participation requirement already covered by the charter.
There was a problem hiding this comment.
Another topic that might fit better into a follow up pull request is to require "active" members, and define what "active" means, to avoid a situation where people are voted into the board without fulfilling their responsibilities.
@gr2m FYI, this section of the charter includes these minimum requirements to stay active:
In the case where an individual TSC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in TSC discussions, and does not participate in TSC votes, the member shall be automatically removed from the TSC. The member may be invited to continue attending TSC meetings as an observer.
(Not saying there isn't room for improvement. Just pointing out what's already there.)
There was a problem hiding this comment.
As stated above, I will write some language regarding official steps for mediation, arbitration, and how/when these escalated steps should occur.
Should this be detailed in this document? or somewhere else such as the moderation-policy, which I believe should include every level of procedure for handling conflict.
|
@hackygolucky if you can share the language here, that might give us a better idea if it belongs in this PR or not. |
Adds language allowing for voluntary or involuntary suspension of TSC membership privileges Refines requirements around voting for removal
|
Ping @nodejs/tsc ... still looking for more input on this. I have updated some of the proposed language. |
|
This is a huge LGTM. |
| The size is expected to vary in order to ensure adequate coverage of important | ||
| areas of expertise, balanced with the ability to make decisions efficiently. | ||
| The TSC must have at least three members. | ||
| TSC memberships are for one year terms that must be recertified. Motions for |
There was a problem hiding this comment.
One year from... date of original addition / last recertification?
There was a problem hiding this comment.
The intention is all at once, once per year.
There was a problem hiding this comment.
The intention is all at once, once per year.
I'm not going to expend a lot of effort trying to change this, but I'll say that I'd prefer it be rolling so that there is a rhythm. "What two or three people need to be recertified this month? And who is up for recertification next month?" instead of "Oops, did we go two-and-a-half years without recertifying anyone again?" (Sort of what happened with the TSC Director/Chair position at last once, no?)
| Should a situation arise that considers the removal of a TSC member, an | ||
| attempt should first be made to resolve the issue without requiring a vote. | ||
| The TSC Chair may, at their discretion, request that the issue be referred | ||
| to a Foundation appointed third-party mediator for arbitration. |
There was a problem hiding this comment.
I believe this should be "for mediation and, potentially, arbitration."
| to a Foundation appointed third-party mediator for arbitration. | ||
|
|
||
| Failing all other possible resolutions, a simple majority vote of TSC members | ||
| is required to remove a member. Should such a vote to result in a tie (50%/50% |
There was a problem hiding this comment.
s/vote to result/vote result
There was a problem hiding this comment.
Should this be 66%/33% or do we like the potential almost 50% non-support?
|
|
||
| When it becomes necessary within the context of this charter to select a | ||
| third party mediator for arbitration, a qualified mediator shall be selected by | ||
| the Node.js Foundation Board of Directors (or an individual designated by the |
There was a problem hiding this comment.
We refer to the Node.js Foundation as providing the mediator, but here we state that the board is responsible for selection. Introducing the board into this statement may be unnecessary. I recommend reviewing this bit with Foundation Legal.
|
@jasnell I think I've seen you jump back into a few of these issues, do you still want me to take it over or can you update based on comments ? |
|
I'd prefer you to take this over. Feel free to push any further edits to my branch. |
|
Hey All, is this ready to bring to the board or does it require more work before we have consensus? |
|
Definitely requires more work. |
| @@ -176,10 +187,43 @@ discussion will continue. | |||
| For all votes, a simple majority of all TSC members for, or against, the issue | |||
| wins. A TSC member may choose to participate in any vote through abstention. | |||
|
|
|||
| While the results of all votes must be made public, the actual individual | |||
| ballots cast for most votes may be made public or confidential at the discretion | |||
| of the TSC Chair. However, individual ballots for recertification or removal of | |||
There was a problem hiding this comment.
I feel like one member wanting it to be confidential should be enough, not depending on the chair.
| of the TSC Chair. However, individual ballots for recertification or removal of | ||
| TSC members must remain confidential. The names of members voting or abstaining | ||
| in all votes must be made public with a clear indication given of whether the | ||
| individual voted or abstained. |
There was a problem hiding this comment.
Why is abstaining public? Not sure I like that.
| ## Section 11. Escalation of Disputes and Code of Conduct Violations | ||
|
|
||
| Participation in the Node.js project is governed by a Code of Conduct policy | ||
| that is established by the TSC. The TSC is required to establish a policy |
There was a problem hiding this comment.
Why is this not established by CommComm?
|
With other proposals like #382 I'm not sure if this PR is still applicable. |
|
+1 to closing this if @jasnell agrees |
|
I'm not working on this further. Close if you'd like |
|
Closing. Re-open if that's a mistake. |
MylesBorins
moved this from Proposed Charter Changes
to Done
in Items to discuss with the board
This PR proposes a change to the TSC Charter. It would need to be approved by the TSC and the Node.js Foundation Board.
Specifically, this introduces a couple of changes:
1 year terms for TSC members that must be recertified each year by a simple majority of the TSC peers.
Adds a requirement that TSC members must maintain participation in at least one chartered working group or team through their term
Adds mandatory independent, binding third-party mediation under the oversight of the Node.js Foundation Board should any TSC member be reported for a Code of Conduct or Policy violation.
@nodejs/tsc @nodejs/ctc @hackygolucky