Governance and Membership Requirements #8
Comments
|
I vote for consensus based decision making? Seems to be working well elsewhere so far. |
|
What should happen if consensus cannot be reached? |
|
And, pardon my ignorance, how do we know consensus is reached?
…On Wed, Feb 7, 2018 at 3:54 PM Michaël Zasso ***@***.***> wrote:
What should happen if consensus cannot be reached?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAYnRLLWn61y6w9bMuAEPp7ffdynmGhzks5tSarngaJpZM4R58Zv>
.
|
|
@giltayar As long as there are no objections (within a reasonable amount of time), we usually consider there is consensus. |
|
@giltayar sorry, I forgot some of us aren't collaborators (yet!) - generally the same way Node does decision making in core.
In practice, most people agree on most issues consensus seeking has worked in the past. Everyone can voice their concerns and are working towards the same goal. I know modules has been painful for some participants in the past - but I believe the consensus seeking model can work here. See also https://github.com/nodejs/TSC/blob/master/TSC-Charter.md#section-8-voting for what node does. |
AFAIK consensus is different from unanimity, this should be clear to every contributor (or we gonna have hard time doing any change at all).
I'd explicitly write it in the second way:
If explicit, we can point at it. If it's a sub-clause, it's harder to reason about it. Again, in favour of consensus but with those points clarified and easy to point at in every discussion whenever if needed. I hope this is reasonable. |
|
@benjamingr @targos - I must admit, from the little I've seen in these discussions already, sometimes it's not totally clear what we are consensual about, as things keep shifting during the discussion. I keep wanting to say, "OK, but can someone please summarize what the consensus is right now?" :-) But I admit I'm a junior in these things and will learn as I go along... |
|
So one thing that has been thrown around is the idea of membership requirements. I would like to propose that we move anyone who has not filled out the meeting doodle by the end of next week to an observer status. I will email the entire group to ensure that people who miss github notifications get a chance. Does this seem like a fair first expectation for participation? We can discuss this in the meeting. |
People often won't speak up, even in a self selected group like this one, unless directly addressed. I would be much more comfortable with explicitly polling for "Approve/Disapprove/Tacitly Approve" from every member. (With some mechanism for trimming back membership based on ability to participate.) Tacit approval refers to saying that you won't block this, even if it's not your first choice (or you don't have an opinion). Not using a system like this often ends up with decisions being made that some members find unacceptable that they just were unaware of. (TC-39 is still processing some fallout from this problem, re, the semicolons statement.) |
MylesBorins
added
modules-agenda
|
@iarna in the past the project had worked with trying to get explicit approval for most decisions. The result of this was that decisions often stalled while we waiting to reach a consensus of at least 50%. TBH my personal experience with explicit polling results in every decision becoming a vote.. and that in turn begins to create partisan lines, even if unintentionally. The project has been making an active effort to make sure conversations are discussed and concerns are addressed before moving forward, and I've generally found that when we can reach consensus without needing explicit polling people are generally happier with the results. That being said, any explicit change do need sign off. If we are to land documents that in turn reflect a road map or intention for implementation the explicit approval becomes the
While this does end becoming the case with consensus seeking, the alternative is that things stll until you reach quorum. If people are actively involved and reviewing issues they have the opportunity to engage in all three methods of response as mentioned above. The primary difference being that the landing of changes doesn't become blocked based on inactivity. In all cases an issue can be blocked / stalled by any individual in the group. For example we have seen PRs on the core side be stalled for a number of weeks while a key stakeholder is on vacation. FWIW, I don't think our process is perfect, and there is room for improvement and iteration and I think this group could be a great place to do it. It seems that the key difference between our approaches is ensuring everyone has a chance to voice their opinion, perhaps discussing that particular point is a good place to start? |
Sounds reasonable to me as long as everyone gets notified about it - cc @nodejs/modules so people have a chance to respond and realize it's a different poll from the first one. |
|
Hey, this is a final ping to @nodejs/modules members to fill out the doodle in #8 (comment) - |
|
I won't be able to make this week's meeting since I'll be on the road. I'll try to hop in if I've made it to the hotel. |
|
@tbjers note that the doodle is for the bi-weekly meetups and not just the coming one |
|
@benjamingr that's what I figured, just wanted to make sure people knew. I picked the days that work best for me. |
As was discussed in the last meeting all members that did not fill out the availability doodle have been moved to observer status. Observers are not counted toward quorum and do not get to vote Refs: #8 (comment) Refs: #26
|
Copying my response to @mcollina's comment on #31 per suggestion from @weswigham
There were at least 5 pings about this - and Myles reached out to everyone who hasn't filled out the doodle by email (I think). That said, I think the idea was mainly to not have people who didn't have time to participate in the team given the voting process and consensus model. I'm personally fine with a rule like "observers who participate in two straight meetings and in issues are moved back to member status" and "members who don't participate in two meetings or the issue tracker are moved to observer status". |
|
I have not received any direct emails about this. I will recuse myself from any further discussions about modules. You have ostracized somebody from this group, congratulations! I will be sure to review any PRs that go to Node.js core, as my duty as a tsc member. |
|
@mcollina hold on, I understand that you are upset but I think that the situation can be easily resolved from the modules team side. The rationale for the above process was to move members who were not participating to observer mode so that consensus can be reached and discussions won't stall - and so that there are no inactive members. If you follow the discussion during the recorded meeting and look at the notes - I hope you see that is the case. The intention was not to exclude you (or anybody) who was willing to participate and of the members moved to observer status you are the first one to even reach out about it. Also note that moving to observer status has no impact on your ability to participate other than voting - and we can sort this out during the next meeting. |
|
I thought the doodle was an old doode, and didn’t feel the new one. I do not have to be part of this group to provide my feedback, and it’s very clear that I’m not necessarily on board with the governance of this group. |
|
@MylesBorins can you point out to the right doodle that we had to fill? Because I might be in the same situation as @mcollina. I've filled a doodle but now I don't know which one was required. FYI, this is the one I've filled: https://doodle.com/poll/vdb8cgz48q3zzt2t |
The governance model and membership requirements are both still under discussion (please note that the PRs are still open and we're currently seeking final consensus on PRs during meetings, in lieu of any as-yet-undocumented process). Are you sure you didn't want to be part of that?
If I understand the governance model correctly, if a working group is chartered (as is the goal of this group once set up), the only recourse the tsc has for regaining control over the area charted is revoking the charter. Unless you were already planning on rejecting the charter unconditionally? Or were OK only giving feedback in an advisory role instead of a required one? I'm wary of having a tsc member dissatisfied by the group's very existence; it'd be a shaky start, at the very least. |
|
I plan on -1 the chartering after this incident, and this confirmed some thoughts I have been brewing for a bit. I do not like the direction this is going, but the whole TSC can still approve it. |
|
This WG had a call for members open for less than a week and garnered around 40 members - double the size of the next largest WG. I hope you at least take the logistics of that into account in your decision (and I don't think anyone here has been inflexible or unreasonable) - I do think that stating an intent to reject a charter before any of the charter's scope, the WG's members, or its full governance is finalized is a bit premature; it makes it seem like you're against the idea of a WG in the technical vicinity of the WG's proposed topic. |
|
I have been a promoting this with Myles. And I still think we need a wg. I’m recusing myself from the discussion, and I plan to -1 the chartering if the wg still thinks that removing people after 1 week of non-partecipation is a good idea. This can easily lead to bad decision were the most prominent and active members are the only one involved. Do we have a governance PR where this is stated? I couldn’t find it. |
|
@mcollina we haven't decided on anything yet, notably we've not imposed any actual activity requirements on membership during our first meeting, and, as I said, we'll definitely have to talk about it during the next meeting. It is a good thing(tm) to have people talk out why they think they'd be a bad idea, and what a good membership criterion should be. Though, I'll be honest, having a tsc member drop by and wave around a big red -1 to everything flag before engaging in meaningful discussion is not confidence inspiring. |
I'm strongly -1 on this proposal. There is no reason to draw lines about who is in and who is out while bootstrapping a brand new working group, especially one that has such far reaching implications as this one. Before the group is actually chartered, please allow the membership to grow organically. Allow the work mode to evolve without artificially imposed constraints. |
|
@jasnell do you have any proposal on limiting the side of the working group? Over 40 people makes it very challenging to make progress |
|
If it follows any typical pattern, that size will drop in its own and a more limited and more invested core group will emerge. We've had one meeting and no significant discussions within this group yet. There hasn't been time for that core group to coalesce. My recommendation would be to give it more time. |
|
@jasnell people have proposed that decisions require a 50% majority vote in meetings - as membership will "drop on its own" we'd still need a process for converting voting members to observer status in order to not stall. What would you say a good rule would be for accomplishing that? |
|
I'm -1 on the 50% vote requirement also. Right now I'd keep it as a looser If-there-are-no-objections-within-a-reasonable-period-of-time model. |
The objection to that model which @iarna has brought up is that people are less likely to speak up in larger groups because of peer pressure and a vote allows people to speak up if they otherwise wouldn't have. I have a different suggestion - we still do voting, but the voting doesn't require 50% participation of all team members and the voting is done anonymously for 240h (so 10 days) to help alleviate the peer pressure concerned brought up. I realize you'd prefer not to participate at this stage but would 10 days be sufficient for voting in your opinion @mcollina ? As for membership - I think that missing two consecutive meetings and not participating in the issue tracker should be grounds for removal. Conversely, requesting to participate (as an observer) in 2 meetings and participating in the tracker should be grounds for nomination (which will be voted on) for membership. I'm just bouncing these ideas around to solicit feedback at this point. |
|
In general I feel that this is prematurely trying to solve a problem that does not yet exist. I won't say anything further about it tho as I'm far more interested in the technical decisions that need to be made than the governance choices. |
What do you mean? You don't believe we should have a vote on decisions or issues? |
|
I believe that we're prematurely imposing too much process around decision making. |
|
The main reason for the decision to have consensus reached in meetings was to ensure that everyone got a chance to see things before they were finalized due to signal vs. noise. Based on the discussion in the last meeting, even that decision is up for discussion as nothing has landed in the repo. If someone would like to open an alternative proposal we can definitely discuss both on their own merits at the next meeting. Seeing that we have had quite a misunderstanding / disagreement around the decision regarding membership requirements it seems like waiting for the next meeting to land that change was in fact prudent, as it gives us the ability to discuss it one more time and potentially decide not to move forward with that original decision. |
The whole thing was super short term and slightly confusing. I filled out the first doodle as well and only participated in the 2nd one on a hunch. Because at first I thought the 2nd was supposed to get additional people and not replace the 1st doodle. The first meeting was set up before the doodle was even over and while multiple people were at the diagnostics WG meeting / traveling home w/o a lot of spare time to engage with this. I think it would be valuable for this group to be very clear and honest about the fact that this went over a bit chaotic and the decision made (e.g. who to move to observer) should be reconsidered. I'm all for moving fast and I can empathize that there's a lot of people to herd here. But the decision making process here was a bit off-putting. P.S.: As I implied by "on a hunch" - I don't think there were emails. Maybe there were individual or batch pings on the issue..? |
|
In addition, the meeting where this was decided was scheduled and held before either doodle was closed - meaning, not enough time had passed to even be able to determine when a good meeting time would be. |
|
It wasn't decided, it was proposed and the PR opened, with the final decision to accept or reject it placed at the following meeting (two plus weeks later). At least that's what I'd gathered. Which is a fair amount of time for input and discussion, which I'm glad we're now having instead of recusing ourselves from any discussion. I do agree that this could have been communicated better, but the group has literally formed in the last two weeks and I'm not above believing that there'd be some missed communication in the flurry of activity with a group this large. (Most of this is probably buried in the meeting notes) |
|
@weswigham before updating the PR I did remove people from the members group as was discussed in the meeting, but I feel as though I acted prematurely on that and perhaps we should have landed the PR first. I attempted to contact everyone involved by personal email, but am realizing now that @mcollina was missed in that communication. Considering how many people are saying that the communication on this was confusing I think we should consider reversing the decision. I'll comment as such in the Pull Request. My apologies to anyone who has been upset or hurt by the way that this was handled. The resulting outcome is not at all in line with the intent of this. I take personal responsibility for this ending up the way it did. |
|
Following up from todays meeting we have landed basic guidelines around governance. I'm going to close this and open another issue to focus specifically on membership requirements |
If this team plans to become a chartered working group we will need to determine a governance model as well as membership requirements. I'll use this original post to track the discussion. Currently listing the high level things that need to be determined
Governance Model
Membership Requirements
The text was updated successfully, but these errors were encountered: