meta: proposal for revised governance #263
Conversation
|
|
Great care should be taken in considering how this change is likely to impact areas like the moderation policy. The current moderation policy says:
That and other statements in the policy seem to be written with an assumption that the TSC is a relatively static body of individuals in whom there is considerable trust.
That assumes that the TSC at any given point consists of a group of known individuals but the change in this document would seem to change that. The TSC would consist instead of a group of seats representing WGs that may or may not have an individual that can be mapped to that seat at any point in time. And so on. If you start going through the moderation policy, there's a lot of this sort of thing. |
|
Answering my own comment above about moderation: I guess this is (or could be) dealt with by the fact that there is an Admin team that would appear to have identifiable members and who would be charged with dealing with things like moderation. |
|
re: @Trott's comments:
Indeed, the Core Working Group's area of responsibility is essentially any area not explicitly assigned to another chartered working group.
I would call these teams. There should be no reason these should go through the trouble and overhead of chartering, particularly due to their rather ad hoc nature.
It may not be a good fit at all. I would fully expect to iterate on it and definitely defer to those with more direct experience with each of the groups :-)
Indeed. What I would like to see is a Moderation team spun up in association with the Community Committee, potentially even with the CommComm taking responsibility for oversight. The Admin team could play a role there, as well. The key point for me on this is that I feel there are better ways to handle this than we currently are and that the current moderation policy, while good for what it has been, should evolve as the structure evolves. re: @cjihrig thumbsdown ... would you mind ellaborating on your thumbsdown? I appreciate the feedback but the single emoji does not provide enough useful context. |
There was a problem hiding this comment.
As noted in person, this gives people in the working groups more autonomy. However, people can be in working groups but not be core collaborators. I think anyone in any wg should be a core collaborator, or we need to shift a lot of our language from "core collaborator" to "wg member". This needs to happen before this is accepted.
Some more notes: the ctc looses too much power. There might be a lack of leadership. However, I might not know how to change this proposal to restore that.
|
Can you elaborate on "core collaborator"? Someone who has commits in core? Do documentation commits count? What about non-commit issue/PR participation? |
|
This proposal specifically tries to shift away from terms like "core collaborator" to "working group member", with the working groups each permitted to have it's own definition or process around membership. @mcollina: specifically what kind of power should the CTC retain? Let's start from there and see how it fits. |
We do maintain a big list of people in https://github.com/nodejs/node#collaborators. In this WG-focused proposal, what will be the role of those people?
Power is the wrong word, I meant balance. Currently the CTC is the expression of a huge list of collaborators. All those people will be granted one seat. However, people that are part of all the WGs will be granted a representation. While there are some overlap, most people falls under the first list, and not WGs. As an example, streams is very thin as a WG, and it has most members that are not actively involved in core (while some of them have the commit bit). |
I agree, combining the Build and Website working groups doesn't seem to make a lot of sense. The Build WG is already overtasked in terms of daily responsibilities and relies on people who are quite dedicated to staying on top of it all. In contrast, the Website WG gets a ton of things done through a large collection of casual collaborators. The workloads couldn't be more in contrast with each other. |
I think that administrating budget allocations and administering moderation escalations require incredibly different skillsets. I would caution against putting them both into the same subgroup. If the TSC has all the leads from the different WGs it should represent the project and is the best place we have for escalations. UPDATE: I'm recalling a suggestion we had back at the collab summit. We can task an admin group with the literal administration, giving them and only them owner access, but require that they only take actions the TSC asks them to take. |
Defining that would be the responsibility of the CTC / Core Working Group.
Really not sure if I'm following. The Core Working Group membership would generally include everyone with a commit bit to nodejs/node. What is currently the CTC is a subset of this membership. The Core WG would continued to be structured in such a way that this leadership subset would still exist and that within the realm of responsibilities assigned to the Core WG, that leadership subset would generally continue to operate how it does today. The difference under this new structure comes in only at the TSC level. |
They already are under the same subgroup currently. |
There's a big difference between the current TSC, which people ask to be admitted to after working in the project/community, and a subgroup the project would spin out tasked with administration. They may have the same responsibilities but this plan pretty drastically changes how people are admitted to it and what the final scope of responsibilities are. |
This particular discussion should maybe be spun into its own thread. There's likely to be a lot of different views on it and I wouldn't like to see it derail the rest of the discussion. |
|
TLDR; This moves top level governance from a body of elected individuals to one where working groups choose representatives who make up the top level governance bodies. Over the last few years we've tried a lot of different models for decision making and governance at smaller scales across the project. Each WG operates a little differently based on its needs. The largest success of all the changes we've made since io.js is the basic decision making structure. That vast majority of work in the project happens without escalation or top level "approval." This has been a critical component of the project's ability to scale from less than ten contributors to hundreds across the organization. In the rare cases that something needs to be escalated we rely on upper level governance structures. Most project participants never interact with these governance structures because their work is never contentious enough to be escalated. As the project has grown and needed to scale the decision making structures have dynamically adjusted, enabling new teams and working groups to be pulled into issues of importance dynamically. However, the upper level governance structures have not changed very much at all and are not dealing with the changes in scale nearly as well. Escalated issues seem to be taking more and more time to resolve. All upper level structures that have been around more than a year have had issues with members who have lost interest but have not resigned their position. The basis for this new structure seems to be simple: take the parts that are working (dynamic decision making groups) and directly represent those structures to fill out the upper level governance rather than electing individuals to fill it out as we have been doing so far. There's a lot of details to work out from that point on, but the premise is quite sound. I think it's also worth noting that while this drastically changes the "org chart" it actually DOES NOT impact more than 95% of the decision making process across the project which continues to work without any need for escalation. Also, I think it's about time we get input from @nodejs/ctc and @nodejs/collaborators on this as well. |
I want to emphasize this part. I know this sounds like it's a big change that adds a lot of overhead, but in reality it's quite small and doesn't change much. Aside from the question of who sits on the TSC, a lot of the other work is formalizing and codifying a lot of things we already do but haven't documented. One nice side effect of this change is that it should make it easier to figure out who to talk to when someone in a WG/team is not able to resolve issues, and to do it in a more efficient way. Let's say, as an example, that the build WG needs to add a machine to do something specific, and we can't get it donated (this is a hypothetical, bare with me). What does the build WG do? Currently, they have to escalate to the CTC, which escalates to the TSC, which escalates to the board. We can hope that someone from the build WG sits on the CTC and/or TSC to help smooth this along, but that's not currently guaranteed. In other words, this turns into a game of telephone where the request has to go through three intermediaries before the correct person is asked for funds. In this new structure, we remove up to two of those intermediaries. This will make the request faster, and make it more likely to succeed since the build WG can more directly advocate for itself higher in the org. |
|
My perspective on a few points:
|
|
So thinking about this: one of the reasons for this proposal is to fix issues in the TSC. I understand that the WGs are working well, and that the CTC is working well, but the TSC is not working well right now. A few structural issues aside regarding difficulties in getting votes passed aside, I often feel like the issues that are put to the TSC for consideration end up being far enough removed from the areas of expertise represented by the members of the TSC that we have difficulty making informed decisions. I feel like we have fairly often ended up deciding "this question is outside our expertise, let's kick it back to the WG." This process slows down the decision making process, and takes up the time of those of us on the TSC on things that we ultimately don't contribute to. The WGs may not feel like they need to be present for higher up conversations, but the TSC does need this input. One of the points this proposal addresses is a way to equalize this need (which currently only goes in one direction). I get that folks in the various WGs need to balance work/life, and that open source presents unique challenges to this. My opinion is that creating both a budgeting/admin WG and a moderation WG (preferably under CommComm) is necessary for this proposal to succeed, because it gets ride of most of the things that WG folks don't want to do at the TSC level. One way or another, we need to change something to fix the TSC. This is one possible approach to fixing, and may not be the best approach. Regardless, I caution everyone against thinking this is change for the sake of change, or that the only reasons for doing so are to benefit the WGs in ways they don't need. There are very clear advantages to those of us on the TSC. |
|
@nebrius I agree that the key issue is how the TSC should be structured to better support the overall work of the project. I worry that by trying to fit into the proposed model we'll exclude people who are willing and have time to contribute while pushing others to be involved in something that is not their first choice of how they want to contribute. Right now if people participate and contribute to the work of the TSC then they can be involved in the decisions. The larger problem may be that the work is not clearly enough defined or seen to be interesting enough to attract what we'd like in terms of participation. Just thinking off the top of my head, if the mission of the TSC was to define a strawman for the priorities/directions for the project, that might then allow us to pull contributors with the needed expertise (from working groups or else) into an effort that would be more focused and would last for a reasonable amount of time (as opposed to forever). For example, if the theme for a release was "performance" then we could pull in the people interested in performance and benchmarking for a more focused push on that front . From my perspective the problems at the TSC level are not that we have too many people involved or that anybody's complaining about specific decisions that are made, but instead that we need more focus along with people who have time to contribute to the focus areas. |
This effectively merges the TSC/CTC, so it doesn't actually move where the WGs are chartered.
WGs don't escalate issues, any issue that can't find an easy consensus is escalated. That won't change in this new system. What changes is how the escalation body is staffed. Right now escalations fall into a group of individuals who were promoted into the CTC at some time over the last 2 years. This would move to a model where current contributors from across the project can participate and votes are allocated to WGs. On thing that keeps getting lost in this is the fact that we're opening up the CTC/TSC meetings to participation from all contributors. The votes, in the rare case that votes are necessary, are being allocated to WGs instead of individuals.
That's not really something we would hear though. WGs have enough autonomy that the majority of their decisions are made without the CTC/TSC, and that wouldn't change. The real question is "when we need to make hard decisions do we want to make them as a group of individuals or as a body representative of the working groups that are getting all the work done."
So, I do think that we need to take steps to make sure that this is an additive experience for the working groups and not just a new set of work and expectations we are forcing on them. However, I don't think that we should assume anything about the inherent nature of individual contributors and their workloads. I think that the last few years have shown us that, given enough contributors, the incentives that the project structure implements can lead to the outcomes we want to see. |
|
@mikeal said:
This is a critical point. Also, under the current way that decisions are made, we really have no way of reconciling the decisions that are made to whatever the consensus opinion is of the people it would most affect. Take the promises discussion for instance... we all have opinions on that discussion but given the nature of how promises are defined, implemented and used, it is the diagnostics and post mortem working groups that have the greatest share of the concerns -- can we be certain that the decision the CTC made on that adequately covers the concerns of the members of that working group? I'm not so sure. It's not a case that I want to litigate again, by any stretch of the imagination, but the current model of discussing and deciding contentious matters potentially takes it completely out of the hands of the people who would likely be the most affected. Part of the goal here is to reverse that and pull those individuals into the conversation more. @mhdawson said:
We already exclude such people from the discussion and decision making when a contentious issue comes up. We hear consistently that Core is not taking the point of view of the ecosystem into consideration often enough when it comes to contentious issues. There is nothing (or should be nothing) about this proposed process that forces contributors to participate in a particular way. The overwhelming majority (@mikeal says 95%, I think it's more) of work that's being done would not change. @mhdawson also said:
This proposal does not move technical responsibility away from the CTC (or Core Working Group under this proposal). The CTC would retain technical oversight over anything that is not explicitly within a chartered working groups area of responsibility -- which is exactly as it is supposed to be today. The one change this does make with regards to the CTC is on the final decision of a contentious issue -- rather than the CTC being the sole deciding vote, the decision is shared among the chartered working groups, which likely have as much or more of a stake in the decisions made than the CTC.
This is not about flattening the escalation process to the board. That's not a problem that this proposal is looking to solve because, frankly, interaction with the board at the foundation level is not a problem.
The Inclusivity WG is a really good example of a case where it did break down -- for many reasons, of course, but the point is that it's not zero cases. (and just to cut it off now, I'll ask anyone reading to please not start a discussion about the incusivity wg issues in this thread. I mentioned it as an example, not because I have any desire to discuss it). It's worked out so far with the other WGs because we happen to have enough overlap between membership in the working groups and membership in the CTC and there's been a willingness (so far) on the part of CTC members to defer to whatever the WG recommends, but I'd rather not bet long term on serendipity. The CTC is growing, the number of contributors is growing, and it's not clear if the current processes are scalable. |
|
It seems to relegate the CTC to one vote, which doesn't seem to reflect scope of responsibility to me. Do I understand this correctly? The TSC was split from the CTC because, as I understand, some of the CTC didn't want to be involved in some of the non-technical discussion and decision making. I'd say that would apply even more strongly to the working group members, is there any evidence that the WGs want to put a member into TSC meetings, or have any opinions about the TSC agenda items? The suggestion that every WG would get a vote in the TSC sounds very democratic, but I don't see how it would work. If discussions had a pre-agenda "ballot" with set choices, a WG could agree (vote, consensus, however they choose) on each item, then send a rep to the TSC to vote. But actually... you wouldn't need a meeting at that stage, the votes could be async. The TSC/CTC has meetings because it attempts to achieve consensus, it discusses issues before voting on them, often coming up with a better idea during the process, and that discussion involves live interaction, but only one member of a WG would be involved in that live interaction, that's not good. Or perhaps the idea is that every single member of the WG would show up at the TSC meeting, but collectively they would decide on the spot how to cast their one vote, if it came to that? This just seems really confusing to me, I don't understand how it can work, or even what the problem is with the current process that needs to be fixed. I am only involved with 3 WGs, but I don't recall anyone, ever, expressing unhappines with the current the organization (though that doesn't mean individuals weren't privately unhappy, and it never came up in the WG meetings). I don't even recall a TSC agenda item being mentioned. AFAICT, things are ticking along nicely and I don't understand the problem that this proposal is attempting to solve. |
That is not my understanding, but this should be made clearer if this is a conclusion people are drawing. You have to first think of the TSC/CTC as "merged." And so, representation on the CTC is made of "votes" from WGs, as is the TSC. |
I mentioned this above, but I want to highlight it again. I think a key requirement in making this model work would be to a) spin off moderation to CommComm and b) create a budget and/or administration WG. This would remove most of the work that caused the initial CTC/TSC split, and would mean that WG representatives on the TSC wouldn't have to do this work. I actually think we should make this change regardless of whether or not we go with this model. If nothing else, this would pave the way for the TSC and CTC to remerge and resolve the reasons the two split in the first place.
I actually think this would be a big benefit :)
This proposal specifies only one member casts a vote, but also states that multiple people from each WG are encouraged to attend the meetings if there are relevant things to discuss.
For the most part they are ticking along nicely, but we have a couple of areas where they're not. See my previous comment above for one example. Also, @jasnell's example of the Inclusivity WG is another example of a WG that didn't work well under the current governance (I also don't want to re-litigate that case, just using it as an example). |
One thing we talked about at Collab Summit was how this process actually puts more weight behind the objections of trusted contributors. Right now, when a trusted contributor objects the other people in that area of expertise mostly stay silent, they figure this person has it and they trust them. When/if that issue gets escalated, it's hard to tell if this if this objection is held by this individual or the entire area of expertise. The WG voting system would put more weight behind that objection when the rest of the subject matter experts agreed or even just deferred to someone they trust. It would mean that rather than Fedor objecting to an escalated crypto issue, the "Crypto Team/WG" is objecting. And this all happens without a lot of additional process or voting because the chair can rally for objections in the issue already being presented. |
|
@sam-github said:
For the things that are within the CTC's scope of responsibility (which is everything that is not explicitly within the scope of another WG's responsibility) the CTC would still retain full control and decision making authority except on the rare occasion when an issue needs to be escalated -- which is exactly how it works today. The difference is that when escalation happens, rather than it being escalated to the handful of people who currently make up the TSC (who typically don't have the context and are generally the same people that are on the CTC), it would go to the working groups to decide. To me that feels like a much better fit. Note that such escalations are exceedingly rare today and they would still be exceedingly rare even if we put this model in place, which means that for the overwhelming majority of issues, nothing would actually change. Plus, if you think about it, the CTC and TSC membership overlap so much that having controversial CTC decisions escalate to the TSC for resolution makes absolutely zero sense. Escalating the issue for resolution by the working groups makes far more sense since it is in the working groups where the actual impact would be felt.
If those meetings are only about budget allocations and Code of Conduct changes, no, absolutely not. But that's not what is being proposed. The items that the TSC currently is charged with dealing with (the administrative minutia that very few have an appetite for) would be handled by the Admin team without there ever being any need whatsoever to bring that to the working groups through the TSC. Working groups can completely opt out of being involved in that process entirely if they so desire. The TSC meeting agenda would consist entirely of (a) escalated issues that actually require WG input and (b) a coordination standup by each WG to that the working groups know what the other WG's are working on. In fact, it would be an explicit goal for the vast majority of this to be done asynchronously so that if there are no pending agenda items the TSC meeting could potentially be skipped entirely! As @nebrius said:
This is actually a goal! The TSC should not be meeting if there are no items on the agenda that need to be resolved and we should be avoiding votes as much as absolutely possible.
More the latter, definitely not the former. The CTC and WG's would still have their own meetings, where they could discuss and decide things however they wanted. IF (and it actually is a big IF) a contentious issue comes up that ends up needing to be discussed and resolved at the TSC meeting, anyone who is a member of any of the chartered working groups could show up at the meeting to discuss the matter. There would be zero expectation that every single member of the WG would show up at the TSC meeting or that they would decide on the spot how to cast a vote. If consensus can be reached through discussion without requiring a vote, then awesome! That's what we want. A vote only comes in to play if we absolutely cannot get to consensus, in which case it falls on each working group to determine how it wants to use it's vote -- but that will be and should be a last resort. Hopefully the additional coordination that would be required would be enough of an encouragement to seek a solution through consensus rather than voting. If a matter could not be resolved through discussion and a vote absolutely needed to be called, then the voting would be done through an asynchronous process, giving the WG's time to discuss and come up with a decision on how they wanted to use their vote. It would mean that voting would take longer and would be a far more irritating process that, hopefully, folks would want to avoid.
Yet we consistently get questions about what the TSC is for, what it does, why it exists, what it's relationship is with regards to the rest of the project. Most of the working groups ignore it entirely because it simply has zero impact on their activity -- which is a huge red flag. IF the TSC as it currently exists has zero impact or usefulness for the project, then there's no justification for the TSC as it currently exists. Also, there have been people who have expressed unhappiness with the current organization (again, the inclusivity working group implosion is a great example).
The working groups have been ticking along nicely. The TSC has spent the vast majority of its time over the past two years trying to figure out what the TSC is for and what it does. We have also spent a great deal of time trying to figure out how to be more representative of the actual decision making structure in place across the project. Note that this proposal does not actually change how the working groups actually operate. It does not change how decisions are made day to day. It does not change the contribution policy or really how any of the individual contributors do anything they are doing on a day to day basis. All it changes is how the TSC is structured and how controversial decisions are escalated so that those processes more accurately reflect what is happening throughout the project. It is precisely because the working groups and collaborators have been so successful at keeping things moving along that restructuring the TSC is a good idea -- because the TSC has not been as successful. In other words, this proposal is explicitly not about trying to solve a problem that doesn't exist at the working group level. It is trying to solve a problem that exists at the TSC level. |
snark do you really want me deciding these things? (hint: the answer is no) endsnark. I'm the main person who's on the TSC and not on the CTC, and I bring the perspective of CommComm (previously Inclusivity WG). This is an important viewpoint, but I can't bring any additional input on technical decisions because I don't have the breadth or depth of knowledge that CTC members have. In other words, I'm not able to contribute in breaking a deadlock, which defeats the whole purpose of escalating to begin with. |
|
Since its been mentioned a number of times I think the example of the Inclusivity WG and likely similar cases that might arise have been addressed by the formation of the ComCom committee. I also see the issue of "scalabilty" being mentioned a number of times. Can you point to specific instances that illustrate this problem ? |
|
I'm going to a list a few problems with the current model. This proposal solves them, but I'd like to hear if people disagree that these are problems or if they prefer other solutions.
We've attempted to solve these problems in isolation, asking WGs to provide updates, asking people to step down when inactive, but none of them are working. The TSC has the most acute issues, sure, but we can also see issues with the CTC and many of them are similar. The reason I think these issues are systemic, and that we need a shift in structure in order to solve them, is because our attempts to intervene in these issues in isolation haven't worked. There aren't any incentives for people to take on some of these leadership responsibilities that the project needs some of them to happen in order to handle the scale of the project. We've spent a lot of time picking apart this proposal but we don't have any counter proposals to solve these issues either. Unless we just don't think this stuff is a problem we're going to need to see some alternatives to critique. We're dangerously close to the "death by a thousand paper cuts" situation with this proposal and we have no clear alternatives. |
I read this point in the opposite way that you've read it, so it probably needs to be severely clarified :) I read this as "decisions being made that aren't escalated to the CTC/TSC as working great. but, the body that handles escalations is not representative of the people doing the work and making the majority of the decisions that are not escalated." I agree 100% that we should not mess with the incredibly functional daily decision making process for all work and issues that are not escalated. I see this proposal as trying to bring what is working about that process into the upper level decision making structures. This may end up meaning that some developers are more engaged in the CTC than they otherwise would be but I wouldn't go as far as to say we are turning them into administrators (provided we move the budget administration into a working group) because they are still primarily participating in technical decision making, just in a slightly more structured way. |
|
I have updated and simplified the proposal based on the discussion and feedback. Please take another look. |
|
@mikeal ... based on the discussion and feedback, I think we should scale this back a bit to deal first with the disfunction of the TSC. Yes, I know we share concerns about whether the current model for the CTC is scalable, but there is obviously not broad consensus around those concerns and whether they are legitimate. What I think we can all agree on, however, is the point about the TSC not working as is. |
|
@jasnell does that take "merging" the TSC/CTC off the table? |
|
Not necessarily. The idea of "merging" the TSC/CTC would have to be defined. If it means just going back to a single body without any other changes, then I don't think we're actually solving the issues and may end up creating a few more. |
|
Thinking about this some more, perhaps it would be pragmatic to go ahead and create the admin working group and spin off moderation to CommComm first, and then see where we stand. Then we can come back to this proposal (or a similar proposal) armed with more concrete details about how much administration/non-technical duties are required of the TSC. It's entirely possible that merging the TSC and CTC would make obvious sense then (in practice this would be replacing the TSC with the CTC I would guess). But perhaps not, I'm not quite sure. Doing things in this order would give us some more solid data points to bring to this discussion. Thoughts? |
|
The TSC really only serves two purposes:
If we spin off the administrative stuff to an Admin team, backstopping escalated issues is not enough of a justification to maintain a standing body of individual voting members. That said, we would still need a mechanism in place for escalating / challenging CTC decisions, and we'd still need to have a process in place for electing the TSC Chair and TSC Director. |
|
@mikeal just made a problem statement now, after the proposal: #263 (comment) In the absence of a problem statement, its not surprising there were no other proposals, but now we have one proposal above: #263 (comment) To add to that:
|
|
@sam-github ... Several points
|
|
Just to be clear, I did not intend #263 (comment) to be a replacement for this proposal. I would phrase it as laying the groundwork for this (or possibly another) proposal, and is important, but I don't think it solves all of the issues that this proposal solves. |
proposals/revised-governance.md
Outdated
|
|
||
| ### It will take longer to get things done! | ||
|
|
||
| I disagree. I shouldn't take any longer than it does today. |
There was a problem hiding this comment.
Can we move this "agree/disagree" stuff out of the doc?
| ### One monthly TSC meeting in which anyone can participate sounds like chaos! | ||
|
|
||
| It will require better logistical planning, yes, but other groups (such as | ||
| TC-39 for instance) pull off such meetings with very little difficulty. It |
There was a problem hiding this comment.
TC-39's process also ends up with a significantly larger amount of backchanneling, which I'd really like to avoid.
There was a problem hiding this comment.
In our case, the "backchannel" occurs in public GitHub threads, which is where we want to drive the discussion anyway.
There was a problem hiding this comment.
I think the important part about this is that working groups will be encouraged to reach consensus before bringing an issue to the TSC. The TSC is a check point rather than a gauntlet.
There was a problem hiding this comment.
It is not guaranteed to however. An increased amount of politics from WGs could end up in increased off-github backchanneling. We just need to be aware of that this could happen.
| * Release and Support Working Group | ||
| * LTS Team | ||
| * Release Team | ||
| * Docker Team |
There was a problem hiding this comment.
The docker team (WG?) is not very related to the rest of the release process...
There was a problem hiding this comment.
Ok, it may make sense to keep that out...
There was a problem hiding this comment.
Docker might make more sense under build
| * Docker Team | ||
| * Streams API Working Group | ||
| * Intl API Working Group | ||
| * Node.js API Working Group |
| * Node.js API Working Group | ||
| * N-API Team | ||
| * NaN Team | ||
| * Diagnostics and Performance Working Group |
There was a problem hiding this comment.
The Diag group already has enough to discuss, I think generally the perf group as it stands today should probably be informal.
There was a problem hiding this comment.
Note that the work groups here are organized this way only for purposes of the vote, not in terms of what they actually do day to day. In other words, putting these together under the same chartered work group would not require them to work any differently than they currently do, it just means that on the rare occasion that a vote comes up, they would vote together as a single block. It still might not make any sense for them to vote as a block, of course.
There was a problem hiding this comment.
Hmmm, perhaps. I will need longer to think about that.
proposals/revised-governance.md
Outdated
| the matter decided, or by the next TSC meeting (whichever comes first). | ||
| Any votes not registered by the next TSC meeting would be considered to | ||
| be abstentions. | ||
| 5. New working groups would be chartered only through consensus or vote of all |
There was a problem hiding this comment.
I suppose it is already fairly difficult to charter a WG but this might make it even worse?
There was a problem hiding this comment.
I don't know if it would make it any worse. The steps are all pretty much the same as they are today. The only change is on who votes for the final charter.
To be clear, this proposal has been public to most of the Node project for ~3 days. I think this is a good proposal and I generally like it - however I'm not sure yet that it would be a good thing to be doing, perhaps especially all at once. My view has however shifted from where it was last fall and I definitely agree that we should merge the TSC and CTC and simply spin off the majority of the TSC's duties into an officially delegated Admin group. (And perhaps move moderation to the CommComm as part of the same move That could be a good first step and then we could re-evaluate how the CTC and WGs interact? |
|
Oh yeah, I do have one major concern and it is about proportional representation. Far more people currently occupy the "core group" and the core group also encompasses the majority of the work, which doesn't seem proportional to most of the other WGs? Also perhaps then this is moving in the direction of minimizing the core group to only fill in the gaps but I'm not certain at this point that this is a good idea. I think I would rather try this structure with a preserved hierarchy of WGs that are specifically about core's codebase in some way, e.g. Streams and Diag. |
|
The proportional representation point is certainly quite valid. Will have to give that one more thought. |
@jasnell My concern here is not that drafting the charter would be more difficult but rather that getting the voters to agree on officializing it might be. |
|
@Fishrock123 ... Ok, yeah, that's fair. What I would want is that even work group charters would be consensus driven... that is, if someone proposes a working group and there are no objections, it just happens. The only time we should need to go to a vote is if someone cared enough to block it. But perhaps since WG's get a voting seat we need to be more stringent on it. Will think about this more. |
|
+1 to @nebrius's suggestion of moving some/all of the admin parts over to the ComCom committee without waiting on this proposal, things like approving travel for collaborators to attend the summits seem pretty well related to community building to me. It would give a clearer picture of what's left in terms of scope. I also agree with @jasnell comment that focusing on one problem at time would help focus the discussion and potentially make it easier to reach consensus. |
There was a problem hiding this comment.
Haven't had a chance to read the thread yet but I did a once over on the proposal and really like it.
Some of the points that were most important for me was to be focusing on buckets of responsibility rather than thinking about groups of power.
This also focuses on scaling initiative rather than people.
While I can empathize with the concerns regarding representation, the purpose of the distributed votes is to distribute responsibility. Currently individuals want to ensure they can hold core responsible for decisions, they need to maintain their seat. This does not scale. A fantastic example of this would be the issues we had around zero filling buffers. While it was hard for core to reach a decision, individual stakeholders, including security and streams, would have been able to hold core accountable and help reach a faster conclusion on the matter. I want to stress again that many of these stakeholders would be the same people, but they are now representing working groups rather than their individual opinions.
The most important part is that individuals who at one point had been very active in the project would have the ability to completely walk away from it, and return at a later date with the same influence if they have the ear of a working group. This is not what our current structure encourages
The ultimate goal here is to empower people to focus on their area of responsibility I genuinely believe we will have a more healthy flow of people coming through based on the current needs of the project.
| up to each working group to decide on its own process for exercising that | ||
| vote. | ||
| 2. An Admin team would be created that would be charged with handling the | ||
| more mundane administrative tasks currently handled by the TSC (budget |
There was a problem hiding this comment.
Can you omit more mundane, it diminishes the work.
| more mundane administrative tasks currently handled by the TSC (budget | ||
| allocations, github org management, handling confidential information). | ||
| Tasks like administering the travel fund could be handed off to the | ||
| Community Committee. This admin team would not be a voting body. |
There was a problem hiding this comment.
Should this be the team that maintains ownership rights on github?
There was a problem hiding this comment.
Generally, yes. The members of the Admin team would have github org ownership rights.
| ### One monthly TSC meeting in which anyone can participate sounds like chaos! | ||
|
|
||
| It will require better logistical planning, yes, but other groups (such as | ||
| TC-39 for instance) pull off such meetings with very little difficulty. It |
There was a problem hiding this comment.
I think the important part about this is that working groups will be encouraged to reach consensus before bringing an issue to the TSC. The TSC is a check point rather than a gauntlet.
| * Release and Support Working Group | ||
| * LTS Team | ||
| * Release Team | ||
| * Docker Team |
There was a problem hiding this comment.
Docker might make more sense under build
| * Release Team | ||
| * Docker Team | ||
| * Streams API Working Group | ||
| * Intl API Working Group |
There was a problem hiding this comment.
INTL could be under build, or potentially rolled into Core
| * Diagnostics Team | ||
| * Post-Mortem Team | ||
| * Benchmarking Team | ||
|
|
There was a problem hiding this comment.
Wasn't sure where to put that.
| overwhelming majority of CTC members do not want to deal with the administrative | ||
| tasks delegated to the TSC, and I imagine that is still the case. We would still | ||
| need an Admin team to handle those tasks. | ||
|
|
There was a problem hiding this comment.
Moving the admin team to the ComCom team would seem to address this concern.
There was a problem hiding this comment.
very in favor of this!
There was a problem hiding this comment.
I don't believe that would work entirely because the Admin team would, in fact, also be handling matters that are specific to the Node.js project. For instance, adding or removing people from teams, repository management, team management, etc... generally any of the GitHub owner role tasks. Also, the Admin team would essentially serve as the go between for the Foundation and this new TSC. On the rare occasion confidential details needed to be shared with the project, for instance --- which has happened from time to time.
This is not to say that some responsibilities could not be shifted. For instance, administration of the travel fund could easily move over to CommComm, as could issues around Code of Conduct and moderation. (I would like to see the CommComm come up with a moderation policy before we switched that over entirely tho). The point, however, is that there will always be a certain amount of administrative overhead in Core itself that cannot be delegated.
There was a problem hiding this comment.
One distinct possibility is that the Admin team is actually shared across TSC and CommComm, and co-chaired by the TSC Director and CommComm Chair.
There was a problem hiding this comment.
There could always be two admin working groups, one for each committee.
| ability to escalate issues in the exremely rare case it becommes necessary. | ||
| But, rather than having a standing body of individuals decide the matter, it | ||
| goes to a consensus of the working groups instead. It should be exceedingly | ||
| rare for this to actually happen tho. |
There was a problem hiding this comment.
Has it ever happened were the TSC was asked to review and /or overrule the CTC ? I cant' remember this happening but may have overlooked something.
There was a problem hiding this comment.
Nope. And I wouldn't expect it to happen very frequently or at all. In this sense, the voting under this proposal is a backstop. Most likely, the only time the WG's would be likely to actually use their TSC vote would be for governance updates (e.g. a charter changes). I would expect the vast majority of issues to be resolved through discussion and consensus.
| who their members are. | ||
| * Several of the existing working groups *could* be restructured *solely for | ||
| the purpose of voting*. This restructuring *does not change* how the teams | ||
| actually get things done or how people participate in them: |
There was a problem hiding this comment.
If the members of the existing WG's continued to operate as they do today, with teams for each of the groups that are being merged, then additional meetings that span all of the sub-teams would likely be required for anything related to a vote. I don't see everybody from the build team wanting to be involved in all of the Website team discussions and vice versa.
There was a problem hiding this comment.
I think website might be under the prevue of comm comm
tbqh I think it might make sense to start from scratch when thinking about what the high level wgs might look like and then start pairing them up with current initiatives
There was a problem hiding this comment.
we really need to stop trying to organize these WGs into topic categories.
all of these WGs are made of people. in some cases these people have years of contributions and accomplishments in these working groups. in the case of the website there is also years of coordination with other WGs (Core, Build, i18n, foundation staff, evangelism).
i'm concerned that we're looking at this like some sort of executive decision that a top level group is going to make without the input of the people actually doing the work and invested in the working group.
if CommComm wants a WG to join they need to make that case to that WG and not to the TSC/CTC.
There was a problem hiding this comment.
To be quite honest, a strong case could be made that the Website should be it's own standalone top level project altogether in partnership with the Foundation marketing committee. It serves as a resource for the Foundation, for Core, and for CommComm.
There was a problem hiding this comment.
Agree with Mikeal. CommComm or the TSC can certainly ask a WG if they would like to move, but it is ultimately the WG's decision (and should be).
There was a problem hiding this comment.
So, I've proposed an addition to the README calling out a distinction that is not currently obvious. nodejs/nodejs.org#1231
The Website WG is primarily concerned with the code and structure of the website, not with the content of the website. Whenever possible, editorial control over the content is deferred to the relevant working groups.
I don't know if you could make a TLP out of this relationship because Evangelism and i18n are doing more than just website content. Also, Core and Release have final authority over content related to downloading versions and noting release lines, and I don't see them coming under a Website TLP ;)
|
@mikeal wrote (and one or two other people may or may not have echoed):
I don't think this is a problem. (And it will be a long time before it doubles. "Doubles again" is not correct, I think. It has not doubled a first time yet. When the CTC was spun off from the TSC, I believe it had 12 members. It now has exactly 20.) The CTC adds a few people at a time. It grows very slowly. If it gets unwieldy, the CTC is obligated to shed inactive folks etc. But the "can we really grow much bigger" question has been going on for as long as I've been on CTC and it just hasn't become an issue. Are we on the cusp of an infeasibly large CTC? Maybe. Maybe not. (TSC may be a different story. It's entirely probable that different subject matter, different internal dynamics, and/or different time/resource constraints make even 16 people too large.)
Not true of the CTC. All members are active, although it's certainly fair to say that some members are more active than others. And we've certainly had inactive members in the past. I think the CTC has evolved such that a few members with light activity doesn't cause widespread decision-making dysfunction or paralysis. This is an important feature of the group and I'd hate to see it broken inadvertently through these changes. (I'm not necessarily opposed to these changes, though. Just airing an area of concern.)
Not a problem for the CTC at the current time, although I'm not disagreeing exactly because it has been a problem in the past and is likely to be a problem again at some point in the future. The CTC needs to be prepared to deal with it when it happens.
Talking only about the CTC: I certainly agree that it would be helpful if people could more easily/quickly rotate on/off the CTC. Time again to fire up that CTC Emeritus proposal I floated a while ago and seemed to have general support... |
|
Closing. Will continue working on this. |
At the Collaborator Summit in Berlin, @MylesBorins and I led a discussion about potential governance changes that would better align the governance of the Node.js project with the actual way that decisions are made on a day-to-day basis, and to better align the project with activity within the working groups (not to mention giving working groups an actual reason to exist). Following that discussion, I took the todo to write up the proposal and get it posted to GitHub for further discussion.
So.. here it is. This is a work in process. Feedback welcome.