Fetching contributors…
Cannot retrieve contributors at this time
167 lines (101 sloc) 9.85 KB

Node.js Foundation Bootstrap Team Meeting 2018-11-19



  • Myles Borins (@mylesborins)
  • Jory Burson (@jorydotcom)
  • Sam Ruby (@rubys)
  • Sarah Novotny (@sarahnovotny)
  • Joe Sepi (@joesepi)
  • Mike Dolan (@mkdolan)
  • Adam Miller (@amiller-gh)
  • Ben Michel (@obensource)
  • Stefan Thomas (@justmoon)
  • Manil Chowdhury (@chowdhurian)
  • Christian Bromann (@bromann)
  • Steven Ayr (@stevenayr)
  • Todd Moore (@tmmoore_1)
  • Andy Updegrove (@aupdegrove)
  • Russ Schlossbach
  • Tracy Hinds(@hackygolucky)
  • Michael Dawson (@mhdawson)


Extracted from bootstrap-late-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

Stage Advancement (5 minute timebox)

  • doc: move governance to stage 2 #36
    • 5 minute timebox
    • possible to move to stage 3 / adopt
  • Myles provided an overview & requested advancement to stage 3.
  • No objections - approval to stage 2 & Myles will issue a PR moving to stage 3/ adopted

Update on progress (10 minute timebox)

  • Adam provided overview - closed this PR and broke out two new PRs to update README. Fleshes out and adds jargon definition (#40). Also PR #42 - adds vision, mission and values recommendations to the foundation recs document in #41.
  • Give another week to get content locked down: Goal to have it landed next week.
  • Formerly PR #6. Tracy Hinds provides overview of PR opened yesterday. Includes what was discussed last week and in former PR. Updated expectations documents. Now is 2 sections: Expectations that affect the bylaws, and Expectations/Requirements that we have has projects that we know are important. Things may still move and there may be some redundancy. These things have been communicated to the board even if they don’t affect the bylaws.
  • Adam’s PR #42 also references this.
  • Point from Mike Dolan: Expectations docs don’t usually go in the Bylaws, and want to make sure people understand not all of these ideas will go into the bylaws themselves. Tracy: Understood
  • How are the 3 community seats allocated? That’s been started as other issues and we are building up to a proposal. (Tierney + Tracy) Ref: (How is representation defined for CPC/C3?)
  • OK to close PR #6.

Discussion (40 minute timebox)

  • How often / when do we meet? #21
    • 5 minute timebox
  • 2 p.m. EST / 9 a.m. EST alternating with the hope of getting more people on the call. We have more participation at 2 p.m. but there are participants who are only really able to make the 9 a.m. EST call.
  • James suggested filling out a spreadsheet with availability. 7 people have filled that out. Goal: make it a bit more scientific.
  • MDawson: I think we still need to figure out if there are people who can’t come who want to. We could say the people who filled out the spreadsheet are the ones who are interested but can’t make it because the times don’t work.
  • Myles: does the second time improve people’s ability to attend? No response.
  • Myles: I think we should kick it back to the issue. Let’s run the 9 a.m. time one more time. -MDawson: We haven’t covered the case if neither of those times work for anyone

Mike Dolan provides overview again for the Google Slide deck. Reviews again because not everyone was able to see it last week. This has been iterated on a few times in order to put together the structural elements. There are different things in terms of project stages, top level committees, etc. Discussed at a high level the purpose of some of those groups/stages.

  • MDawson: in talking with the ComCom it;s not the comcom itself, this is a new group that may be modeled after the Node ComCom.

Myles: Based on the structure we’re talking about - how do we rectify this for an organization like this where both the TSC and ComCom Charter?

Tierney: we created those issues () based exactly on those questions.

Myles: So would every project be required to have a ComCom?

Dan: Question about Sandbox/Common JS: speaking to people in the community they are concerned about where the little projects live that are ongoing but won’t be incubated projects but are key utility projects? To me Sandbox is somewhere where you play, etc. Or is your intention that those kinds of projects would be commons projects?

Todd: That term was borrowed for CNCF and they can be placeholders.

Myles: If we ignore the names I was imagining this would just be a frame for how people might want to engage with the foundation. There are a lot of important projects that need support from the foundation without having to join the foundation (fully)

Tracy: What do we do with this? We should bikeshed names etc in issues

Mike: This needs to be worked through in an agreement/proposal process.

Jory: This question/issue was raised to me by one of our member projects this morning: the question was essentially “will my project continue to be a TLP” and what is that definition. I proposed that we develop a proposal based on the CNCF work so we have something concrete to be working on & I just started working on a branch for that about an hour ago.

Tracy: I would love to help with that - what happens to representation for the TSC/ ComCom with node. Compared to other projects how would this work out. We need to write this in a way where it's clear the projects have agency.

MDawson: Agree with putting that together.

Basically it’s up to the projects to be able to choose and we need to codify that the projects can send a rep but not dictate how they decide that

Joe: Currently the TSC/ComCom are top level committees in the project, how does that move forward?

Adam: We shouldn’t dictate the project governance structure to the projects.

Tracy: What does a TLC for Node mean? Under this new structure, the board rep is from the CPC & C3. Sounds like the Node TSC and ComCom context does change a bit. Does this get fleshed out in the representation issue or does it mean we flesh it out in a discussion about what it means to be a TLC.

MDawson: I think this will get fleshed out in the rep issue?

Mike Dolan: Individual projects do have a charter that describe governance, structure, IP in the CNCF. It’s a little different because it is all under the LF. It might be more challenging.

Todd: could we have a standard template that we could use and then when people deviate we could approve.

Mike: Let me share a template that might be helpful for people to see.

Sarah: at CNCF TLP’s are required to have a document along with some other docs. Where it would intersect is what we need to have a tighter definition if we have board seats for each Top Level Project.

Adam: SOmeone brought up the concept of a constellation project instead of having Board seats per each TLP.

Sarah: At CNCF we have 2 dev board seats that are voted on across the CNCF. It was agreed that Kubernetes would put up one of these positions and the whole community would vote the other.

MDawson: how are the votes done?

Sarah: The Steering committee from Kubernetes put up one seat. The other was done via nomination and voted on by the ?? (sarah please clarify)

Myles: DO we need a separate CPC and C3. How are these two top level groups different? We may need to have clearer definitions of what these are.

MDawson: the challenge may be that we are looking at these groups as voting groups but that may be misplaced. As I understand it is the CPC is about moving projects through the process. Does the governance group need to be two groups or can the other group be split up by interests? Like community outreach, infrastructure, etc.

Myles: What are the membership requirements? Why do we have them?

Tierney: are you talking about the need for representation at the board level?

MDawson: No it’s more like if you are interested in doing this, where do you fit into the picture?

Adam: We have programs you can participate in where you don’t have to be a member of the project

MDawson: That’s where I’m coming from because we don’t have a box for any of them.

Adam: in my mind that’s where the commons js box comes in. It’s not well captured who they serve, what their mandate is. Etc.

Adam: I PR’d a list of program ideas for what we’d like to provide for member projects ( - we need to flesh these out enough to be able to fit it under the right TLC.

MDawson: It’s worth keeping in mind that in Node there’s a clear separation .. as we go through these I don’t know if it will be as clear that we need two groups.

Adam: Agree, at this high a level it may not be needed. We’ll start to see this better I think as we flesh out these programs

Ben: I think it would be beneficial whether we need to create two TLCs, because we could easily have sub groups within a TLC,

Myles: Two minute warning.

Joe: I propose what we flesh out what these look like (CPC, C3) and see if we need those

Myles: We could use GitHub projects to organize some of this separation Myles: We are at time: apologies for the abrupt ending.