Consider changing TSC membership structure. #146
Comments
|
/cc @nodejs/ctc @nodejs/tsc |
|
I wasn't involved in the project's governance when the TSC split (or perhaps more accurately, cloned) into TSC and CTC, so I may be lacking some context, but based on what I do know now, I am in favor of this too. The split seems artificial. Perhaps people who have stepped down from one entity but not the other might have insight as to benefits of the separation. I think that would be @piscisaureus and @misterdjules |
|
I think this makes sense. It is fine for a technical group to discuss non-technical questions occasionally, but to summon technical people only to discuss non-technical stuff is kind of a waste of time IMO. |
|
I'll play devil's advocate for two paragraphs: the reason for the split was to shorten meeting times (laudable!) and to split off the administrative minutiae for people that weren't interested in that (also laudable.) I think a secondary goal was to make room for people with a non-technical background but with an interest in the administrative side, which also seems laudable even if it blurs the T in TSC a little. I'm a member of both committees and I'm in favor of merging them again. I don't feel the benefits of having separate bodies really manifested; the goals were noble but it didn't really pan out. Like Rich says, the split seems fairly artificial by now. |
|
I think the current setup make sense if there are multiple projects within the Foundation that are loosely coupled: This setup helps each project stay autonomous and focused on their project. If a project is considering moving to the Node Foundation, it seems like it wouldn't be as attractive to be governed by a body that is very busy with the Core focus. However, we haven't done this to date (except kind of with the Inclusivity group). Maybe, with this, we would also be declaring that we do not accept loosely related projects? If so- yeah, lets merge them. ... BUT, also consider that the Board has the power to make additional TSCs. Those TSCs would only need to report to the Board. (For example, maybe pretend Microsoft decides the we are too focused on V8 and wants Node-Chakracore on its own?) That seems like it would be a mess! Especially if they share the GitHub org. I'd rather strive for a structure that avoids that happening. Next lets talk about the logistics of merging. How would that work (step-by-step)? To me it seems like both the TSC and CTC would need to vote- and both to agree. Would the TSC repo go away? Anyhow, if we decide to move forward with this, I want to strongly suggest these steps to completing it:
|
|
Agreed. On Friday, September 23, 2016, Ben Noordhuis notifications@github.com
|
Exactly, and the split was made at a time when we were evaluating what to bring in next - express, libuv, npm... Soon after we decided it best to focus on core, so the "new TSC" hasn't really had a lot to do.
There's been concern about that in previous threads, but it seems orthogonal to this discussion and something to save for another time. The board is aware of our concerns and if another top-level project/TSC is proposed there will be a long discussion. Who knows, perhaps it would make sense for some.
FWIW I promise that won't happen 😉 , but if it did the Board and TSC could and hopefully would oppose a separate TLP/TSC. |
|
I'm a bit concerned that we would be overloading a single body with too much work. At this time, both TSC and CTC meetings are full of agenda, and it has been difficult to get the majority of technical folks engaged in non-technical decisions. I remember how difficult it was to get simple administrative stuff passed through the old TSC and I don't see how it would be easier now that the group has doubled in size :( |
|
I don't think it's going to be any worse than it is now; not enough people show up at TSC meetings to get quorum anyway (and yes, I'm guilty of that too.) |
|
I think it is also worth mentioning that we have been seeing a decent amount of success in getting issues handles asynchronously via github, primarily under the guidance of @Trott. If we have individuals who take time to co-ordinate the voting process it is very possible that we could limit the amount of time we need to spend on issues in the call, thus opening it up to cover greater ground |
|
I think having the 2 different meetings has been useful as the TSC has focused on different topics than typically discussed at the CTC meetings. Having said that, we don't necessarily need the separation to have 2 meetings, however, the problem is being able to vote/pass items if we only have a subset of people at one of the meetings. |
|
That's a thought, you could merge the TSC/CTC and have a separate "administrative" meeting and eliminate any quorum rules since the purpose of the separate meeting is to give people the option of not attending. Another thought: one of the reasons for the separation was to try and bring a project wide perspective into the TSC rather than just being focused on Core. However, the CTC has actually done a better job of bringing in new members with a broader perspective than the TSC has and it may make more sense to merge them back together and continue the work of bringing in new members with a wider perspective. |
|
Also, quick point of fact, they would need to merge under the name "TSC" because that is embedded in the bylaws. |
|
Does this mean that Libuv would then technically be under the CTC? Same with Express which IIRC is technically under the CTC domain? Edit: (Changed names to clarify, although we'd be just called the TSC) |
|
@Fishrock123 yes, but in practice both are granted the same level of autonomy so it wouldn't make any practical difference. |
|
I would envision little to no actual impact to libuv or express. On Monday, September 26, 2016, Mikeal Rogers notifications@github.com
|
|
Added both tsc-agenda and ctc-agenda so we can involve more in the discussion. |
|
(assuming closing this was accidental?) |
|
yikes, sorry, I feel like tab order has changed on GitHub, I keep on clicking the wrong thing! |
|
+1, the reasoning for this is understandable. I don't have anything specific to add to what has already been mentioned above, though. |
|
Expressed my concerns in the last CTC meeting -- I don't think it will be productive unless the new "administrative team" has full sign-off authority for those issues, in which case having two TCs like we do today might make more sense. However, also as I expressed at the TSC meeting, I think we should invite to both TCs at the same time when we do invites -- that allows people to choose what they care about (or both). There would also have to be some process for adding members from one to the other in a not-expedited but always allowed fashion. |
Why would that not be the case? |
Reading between the lines, I suspect @Fishrock123 is referring to things that need to be voted on. Voting rules are spelled out pretty specifically in the charter, and an administrative team would most likely require rechartering the TSC, otherwise everyone on the CTC would need to regularly dive into financial and administrative issues to vote, which I doubt a lot of people want ;-) |
|
I see what you mean. Regarding this:
How often would that come up in practice? The TSC doesn't put things to the vote regularly. |
This would be incredibly useful in so many ways.
I would note that this approach would also add additional overhead to every WG in having someone represent them on the TSC. There's a lot of benefits to that, but I would keep in mind that the chairs of these groups already have a lot on their plate, and many of them also already represent these issues to the CTC, which isn't going away in this model either. While it's a great idea to bring in better communication with sub-groups I wouldn't "throw out the baby with the bath water." We have a few people now that have been willing to put in administrative work in the TSC and may even be willing to take on more. An alternative approach would be to task this group with proactively getting status and updates from all the WGs rather than asking the WGs to drive this themselves. If we want to get more information and coordination from these groups I think it's more likely to succeed if we have people standing up to take on that work, rather than trying to get already over-burdened groups to adopt more administrative overhead themselves. |
|
For me the key thing is not necessarily who communicates the status for the working groups, but in structuring the voting such that when an issue comes up, each WG has a vote. If we went with this structure, the Admin WG could be responsible for doing the proactive reaching out to the other WGs to collect status information, discuss pending issues, etc, so that the individual WGs themselves aren't burdened with those tasks. For the TSC meetings, WG's could add their status updates in a comment to the TSC meeting announcement issue if they do not intend to participate live in the actual call. For votes, however, we would need a representative of each WG to weigh in on behalf of the WG. |
|
@jasnell You're still asking for every one of these WG's to stay up to date and educated on the board activities enough to participate in elections. That's a large burden to add to groups mostly concerned with specific technical activity. I can't help but feel like the assumption underlying all of this is that there are people in these groups with a lot of flexibility to dedicate to the project. If we want to continue to attract casual contributors we can't burden the participants with so much responsibility. Contributors should be free to spin up a working group to tackle technical tasks without also having people that can dedicate themselves to keeping up with what the board and the rest of the project is doing. When there are people in these groups that want to take on these additional responsibility we should promote that they do so. We should do a lot more to help people from these groups participate in the TSC, but requiring them to do so is a huge barrier to creating working groups, which we need to do more of given the never-ending growth of the CTC. |
|
My initial reaction is that there is a lot about this approach that I really like. I do have one nagging thought though, maybe it's an issue, maybe it isn't. If we move to a one WG-one vote model, does that vote represent the consensus of the broader collaborator base, given that some WGs are a lot bigger than others, or does it give an outsized voice to some vs others? (Thinking of the Senate and House of representatives in the US Government and how that is a perhaps crude way of balancing these two things). |
|
Can we maybe unwind this from a specific solution statement to a set of problem statements? There seem to be a lot of concerns driving this solution that we can't parse out and it makes it harder to find any kind of alternative without understanding all the problems we're trying to solve. |
I would go a different direction ... Contributors should be free to spin up teams to tackle technical tasks, upgrading those to formal Working Groups only when the scope of the work grows to such a point that the additional overhead becomes a requirement.
Sure...
What else would folks add to this list? |
|
So, giving this a little more thought, it seems like the TSC is currently tasked with 3 distinct areas of work.
In several of these scenarios we split one or all of these areas off but I'm a little skeptical you can really untangle them. A lot of the context for Board representation should come from project coordination and administration. Administration is process heavy and tends to require some knowledge of how the groups are chartered, how the bylaws work, and also the needs of the rest of the project. I know that we like to break off areas of expertise into groups in order to deal with scale but I worry that in this case so much of the context for each of these tasks is shared that breaking them into groups would only increase the burden of each group. However, I don't think that anyone would argue that the TSC has done a good job of project wide coordination. I don't think anyone would argue that the TSC has done a good job of involving people from a wide range of the project. I don't think anyone would argue that the TSC has gone far enough to add value to the Working Groups. To me, that's the biggest problem to solve. Obviously I don't think that blowing up the whole charter is the best way to solve it, but I do think it's our biggest failure and needs to be addressed. I wouldn't necessarily frame this as a "representation" issue though, in the sense that I don't think the only way to solve it is to force each WG to appoint a rep to the TSC. I think that the TSC should work harder to bring in representatives from WGs and Core but I also think it should be pro-active, especially with the smaller WGs, in helping them provide regular status and representing their interests when they don't have someone who wants to do it on their end. |
|
Also note: These discussions of "representation" refer to WGs only... so, there is an assumption here that the WGs are well thought out, properly chartered, and still relevant. (LTS is NOT a WG for instance) |
|
@williamkapke good point, but this also brings up another side effect. If having a WG gets you a TSC seat then you might see groups pushing to be chartered primarily as a mean of representation. If the concerns @nebrius brought up around size of representation aren't addressed this could be even more problematic. |
|
Yes, but chartering does become a larger burden to justify and moving to a WG based representation model moves us away from an individual representation model where status on the WG is driven mostly by how much cred you happen to have built up (which also tends to be a function of how much time you have to devote to the project). The end result would likely be slower unbounded growth as it is far easier to say "We don't think there's enough justification to charter this WG" than it is to say "We don't think this individual has enough personal cred to be here". |
|
@jasnell ya, I get where you're coming from, it does solve that problem, but I'm still just wondering if we can't go with some kind of hybrid to keep the best of both worlds. We could guarantee a seat to each WG and still offer seats to those who take on the admin work and are voted in as a result. If a WG doesn't have someone who wants the seat we can even offer up one of those people doing admin work to sit in on their WG and help to represent them. |
|
That could be included in the charter of the Admin WG, yes? Specifically, the Admin WG would be a special entity such that it's members could serve as representatives for other WG's as necessary, and that each member of the Admin WG would have their own TSC vote as opposed to a single vote. It would take a bit of fiddling with the language to get right but I think it covers what you're looking for. |
|
Just so we can all stay on the same page, this is the current list of technical WGs.
|
|
@jasnell here's the problem, the administrative work can't be untangled from the board coordination. Looking into the future, we should have a lot more things happening similar to the Travel Fund (budget allocations tied to a specific process owned by the TSC). Someone needs to draft those processes and run them after the allocation, and they need to stay within the bound of what the board agreed to in the allocation. We need to turn that into a feedback loop the next time the project wants to do something with budget so we can continue to refine it. If you break off all of that into a sub-group then you've got a group of people responsible for 90% of the interaction with the board that get a single vote in the director election and the rest of the voters in that election have very little understanding of the responsibilities that the director will be taking on. Being the TSC Board Chair is a job and the people that elect the seat need to understand enough about that job to cast an educated vote, which they can't do if we've shielded them from 90% of what that job entails. You've brought up some very good concerns about the current criteria for people getting onto the TSC ("mostly by how much cred you happen to have built up") but the same will be true for the TSC election if the voters in that election are not also the people working with and dependent on that board representation. |
|
Yep... at this point I'm just wanting to talk through the options. I fully admit that I'm far from a workable solution but I think we definitely need to start iterating towards a more effective structure. |
|
Ya, I think underlying this discussion is a solid consensus that some big changes need to be made. |
|
Reopening since so much discussion has been had recently. |
mikeal
changed the title
|
I updated the title to better reflect the current discussion. |
|
I'll chime in that I think the TSC can contribute more to technical decision-making. That would reduce the need for WGs to report to both CTC and TSC. For example, should the decision to delay release of 8.0.0 have been made by the TSC? Should the decision to accept contributions like Inspector and N-API be made by the TSC in conjunction with WGs? |
FWIW I see much of this work being channelled through the CTC at the moment, so TSC members like myself go there to contribute to org-wide project management like integrating node-inspect, n-api, etc., and WG members (like myself from Diag WG perspective) go there to contribute to technical decision-making like Inspector and the module loader. Perhaps we should consider moving some of these decisions to the TSC? That could increase visibility and participation.
Perhaps we might add an intermediate goal of adding representation from the WGs and having a standup first (like the CTC) in each meeting? Standup could be written too so as not to require joining the meeting. |
How about "Roles and relationship of TSC and CTC"? |
|
I participate in many of the WG's and the kinds of discussions and interests in the WGs are quite different from what we cover in the TSC and I don't see linking participation in one leading to representation in the other making sense. Of course participating and contributing to WGs as contributions to the overall project should lead to being interested people being invited into the CTC or TSC just like other contributions to the project. I do agree that we can do much more in terms of project wide co-ordination and that trying to support the WGs make sense. In terms of "helping" them make decisions though, I think the goal was to let them make most of their own decisions when possible and only reverting back to the CTC (as many WGs do work that does end up affecting core) when necessary. I'll also add that I don't like one of the original suggestions of making people pick one that they care about either (TSC/CTC). If people are interested and willing to contribute/participate we should encourage that as opposed to discouraging them. I also support the discussion around making sure people are still actually active and contributing to maintain membership. Mikeal suggested that we start with the problem statement. I think that is the best way to figure out what we thinks needs or does not need to change. |
|
How many of the people in this thread will be in Berlin for Collab Summit? It might be useful to sit down and knock through some of the basics here and then follow up with some proposal drafts. |
I suggested that we encourage people to pick one or the other, not "making people pick". Maybe it would work better if I switched from a solution suggestion to a problem statement: The project is huge and the discussions in CTC and TSC are sprawling. Barring the relatively small number of folks who are paid to work on the project full time, it seems nearly impossible to stay on top of everything. Heck, keeping up with just this conversation is a not-insignificant investment of time. (You can't just skim quickly to get everything. There's a lot of stuff that needs to be read carefully and considered.)
In addition to "interested" and "willing", I would add "able". If someone is not able, then (going back to solutions), they should be encouraged to pick the one they care about more. |
|
By the way, maybe my concern can be addressed by pushing back harder on the tendency to escalate to CTC and TSC. We do OK with that, but we could definitely do better. |
raises hand. Agreed, meeting in person could be a good way to brainstorm and vet ideas quickly. |
|
It seems like perhaps this should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that. |
and others
@joshgav and @bnoordhuis brought this up in #142 (comment) and #142 (comment). Subsequently, @williamkapke asked for a new issue to discuss. FWIW, I'm also in favor of doing this.
The text was updated successfully, but these errors were encountered: