Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider changing TSC membership structure. #146

Closed
cjihrig opened this issue Sep 22, 2016 · 74 comments
Closed

Consider changing TSC membership structure. #146

cjihrig opened this issue Sep 22, 2016 · 74 comments

Comments

@cjihrig
Copy link
Contributor

cjihrig commented Sep 22, 2016

@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.

@addaleax
Copy link
Member

/cc @nodejs/ctc @nodejs/tsc

@Trott
Copy link
Member

Trott commented Sep 22, 2016

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

@indutny
Copy link
Member

indutny commented Sep 22, 2016

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.

@bnoordhuis
Copy link
Member

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.

@williamkapke
Copy link
Contributor

williamkapke commented Sep 23, 2016

I think the current setup make sense if there are multiple projects within the Foundation that are loosely coupled:

TSC
├─ Core
│  └─ The many Core related things
├─ Project 1
│  └─ Maybe sub projects here?
└─ Project 2

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?
Would the CTC repo go away?
Would the TSC repo issues need to go to the Node repo? (oh please no!)
Would meeting notices go in the Node repo or the TSC repo or the CTC repo?

Anyhow, if we decide to move forward with this, I want to strongly suggest these steps to completing it:

  • Vote confirming the desire to merge.
  • PR(s) to the documentation (there will be a lot!)
  • Vote to accept the PR changes and then it is official.

@jasnell
Copy link
Member

jasnell commented Sep 23, 2016

Agreed.

On Friday, September 23, 2016, Ben Noordhuis notifications@github.com
wrote:

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.


You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#146 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2edbTDAr-MoRHBnL_dVuWCE7zpOkwks5qs4jDgaJpZM4KEcEq
.

@joshgav
Copy link
Contributor

joshgav commented Sep 23, 2016

@williamkapke

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.

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.

consider that the Board has the power to make additional TSCs...

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.

maybe pretend Microsoft decides that we are too focused on V8 and wants Node-ChakraCore on its own?

FWIW I promise that won't happen 😉 , but if it did the Board and TSC could and hopefully would oppose a separate TLP/TSC.

@mikeal
Copy link
Contributor

mikeal commented Sep 26, 2016

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 :(

@bnoordhuis
Copy link
Member

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.)

@MylesBorins
Copy link
Contributor

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

@mhdawson
Copy link
Member

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.

@mikeal
Copy link
Contributor

mikeal commented Sep 26, 2016

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.

@mikeal
Copy link
Contributor

mikeal commented Sep 26, 2016

Also, quick point of fact, they would need to merge under the name "TSC" because that is embedded in the bylaws.

@Fishrock123
Copy link
Contributor

Fishrock123 commented Sep 26, 2016

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)

@mikeal
Copy link
Contributor

mikeal commented Sep 26, 2016

@Fishrock123 yes, but in practice both are granted the same level of autonomy so it wouldn't make any practical difference.

@jasnell
Copy link
Member

jasnell commented Sep 26, 2016

I would envision little to no actual impact to libuv or express.

On Monday, September 26, 2016, Mikeal Rogers notifications@github.com
wrote:

@Fishrock123 https://github.com/Fishrock123 yes, but in practice both
are granted the same level of autonomy so it wouldn't make any practical
difference.


You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#146 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eRjbX8NOjDt5ZopTdd1WZTdEPBZIks5quDfMgaJpZM4KEcEq
.

@rvagg
Copy link
Member

rvagg commented Oct 6, 2016

Added both tsc-agenda and ctc-agenda so we can involve more in the discussion.

@rvagg rvagg closed this as completed Oct 6, 2016
@addaleax
Copy link
Member

addaleax commented Oct 6, 2016

(assuming closing this was accidental?)

@addaleax addaleax reopened this Oct 6, 2016
@rvagg
Copy link
Member

rvagg commented Oct 6, 2016

yikes, sorry, I feel like tab order has changed on GitHub, I keep on clicking the wrong thing!

@ChALkeR
Copy link
Member

ChALkeR commented Oct 12, 2016

+1, the reasoning for this is understandable.

I don't have anything specific to add to what has already been mentioned above, though.

@Fishrock123
Copy link
Contributor

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.

@bnoordhuis
Copy link
Member

I don't think it will be productive unless the new "administrative team" has full sign-off authority for those issues

Why would that not be the case?

@nebrius
Copy link
Contributor

nebrius commented Oct 12, 2016

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 ;-)

@bnoordhuis
Copy link
Member

I see what you mean. Regarding this:

otherwise everyone on the CTC would need to regularly dive into financial and administrative issues to vote

How often would that come up in practice? The TSC doesn't put things to the vote regularly.

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

The TSC meetings would then, essentially become a rollup meeting for each of chartered Working Groups.

This would be incredibly useful in so many ways.

Each Working Group would select it's representative to participate in the TSC meetings

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.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2017

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.

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

@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.

@nebrius
Copy link
Contributor

nebrius commented Apr 20, 2017

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).

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

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.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2017

Contributors should be free to spin up a working group to tackle technical tasks ...

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.

Can we maybe unwind this from a specific solution statement to a set of problem statements?

Sure...

  1. Currently, there is a significant representative disconnect between the Chartered Working Groups and the make up of both the TSC and CTC. Specifically, while Working Groups are granted autonomy and oversight over specific areas of the project, membership in the CTC/TSC is individual driven with potentially little or no overlap in the Working Groups. What this means is that any roll up from the WGs to the CTC/TSC tends to be incidental rather than systematic.

  2. Because TSC membership is individual-based, participation is driven by whomever has earned enough credibility in the project to be nominated, there is no clear membership policy, and there is no systematic connection to the overall operation of the project.

  3. The TSC needs to be enable the ability for Working Groups to focus as much as possible on the technical details and less on the administrative details.

What else would folks add to this list?

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

So, giving this a little more thought, it seems like the TSC is currently tasked with 3 distinct areas of work.

  • Project Coordination (which has been lacking)
  • Administration (which has been done consistently)
  • Board Representation and Coordination (which it must do per bylaws)

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.

@williamkapke
Copy link
Contributor

Also note:
We've gone down the path of making Teams rather than Working Groups. (a good idea IMO)

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)

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

@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.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2017

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".

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

@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.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2017

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.

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

Just so we can all stay on the same page, this is the current list of technical WGs.

  • Website
  • Streams
  • Build
  • Diagnostics
  • i18n
  • Evangelism
  • Docker
  • Addon API
  • Benchmarking
  • Post-mortem
  • Intl
  • Documentation
  • Testing

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

@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.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2017

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.

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

Ya, I think underlying this discussion is a solid consensus that some big changes need to be made.

@Fishrock123
Copy link
Contributor

Fishrock123 commented Apr 20, 2017

Reopening since so much discussion has been had recently.

@Fishrock123 Fishrock123 reopened this Apr 20, 2017
@mikeal mikeal changed the title Consider folding TSC into CTC Consider changing TSC membership structure. Apr 20, 2017
@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

I updated the title to better reflect the current discussion.

@joshgav
Copy link
Contributor

joshgav commented Apr 20, 2017

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?

@joshgav
Copy link
Contributor

joshgav commented Apr 20, 2017

@mikeal:

the TSC has [not] done a good job of project wide coordination.
the TSC has [not] done a good job of involving people from a wide range of the project.
the TSC has [not] gone far enough to add value to the Working Groups.

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.

@jasnell:

The TSC would then be made up of a single representative selected from each Working Group + the TSC Director and TSC Chair.

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.

@joshgav
Copy link
Contributor

joshgav commented Apr 20, 2017

@mikeal

I updated the title to better reflect the current discussion.

How about "Roles and relationship of TSC and CTC"?

@mhdawson
Copy link
Member

mhdawson commented Apr 20, 2017

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.

@mikeal
Copy link
Contributor

mikeal commented Apr 20, 2017

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.

@Trott
Copy link
Member

Trott commented Apr 20, 2017

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).

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.)

If people are interested and willing to contribute/participate we should encourage that as opposed to discouraging them.

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.

@Trott
Copy link
Member

Trott commented Apr 20, 2017

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.

@nebrius
Copy link
Contributor

nebrius commented Apr 20, 2017

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.

raises hand. Agreed, meeting in person could be a good way to brainstorm and vet ideas quickly.

@Trott
Copy link
Member

Trott commented Nov 5, 2017

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.

@Trott Trott closed this as completed Nov 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

16 participants