Join the Node Foundation?

[mikeal]

All the documentation for the Node Foundation is ready:

• TSC Charter (Basic Governance)
• Development Policy
• Convergence Plan
• Project Lifecyle (Working Groups Definition)
• WG Merger (List of working groups and how they will be merged)

The gist of it is, the foundation's governance structure is nearly identical to io.js'. In fact, during the process of writing all this down we improved the documentation for most of these policies and made some improvements. The new "converged" node project will begin with io.js master and port changes from node.js in for its first release target.

I wrote an extensive piece on why I think we need a foundation, and why I think the structure the Linux Foundation has setup for the Node Foundation is ideal.

It's now time to make a real decision about moving io.js in to the foundation and, eventually, merging with node.js.

Once we've committed to this we would:

• Rename the GitHub org to "node" or "node-foundation" or whatever.
• Continue releasing io.js while the convergence work is happening.
• Move the TC calls to be TSC calls with the entirety of the TSC (we may have to switch to GoToMeeting because of the size)
• Move the node-convergence repo to the new org as "node"

There's obviously going to be a lot of technical work after that continuing to release io.js until a converged release is ready, targeting the new repo for additional automation, etc, but the immediate steps would be the ones I've outlined above.

For the Working Groups, they would continue to do things as io.js (although the org is renamed) until they have access to the appropriate node.js assets and they decide as a WG to shift their focus.

PS. As a point of process, Working Groups are autonomous, so if the TSC decides to move io.js to the Node Foundation but a WG, for whatever reason, declines they would have to be moved out of the foundation org after the move. This is just a limitation of having to move the org.

[KarbonDallas]

:+1: I am still reading through all of the details, but this looks very sensible and well thought out. Thank you for this.

I am in support.

[benjamingr]

If this is going to work it's going to be amazing. We want to make sure as few users as possible have their projects broken during the transition.

[voodootikigod]

Yes. This should be done.

[djensen47]

:+1:

[Qard]

:+1: from me. On May 8, 2015 5:30 PM, "Dave Jensen" notifications@github.com wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/iojs/io.js/issues/1664#issuecomment-100399319.

[LongLiveCHIEF]

+1

[aheckmann]

:+1:

[aredridel]

So far, big :+1:

[Planeshifter]

:+1:

[cjihrig]

:+1: I think this is best for everyone.

[luke-john]

Hey, so whilst the TSC Charter looks pretty good, the actual foundation charter/bylaws are still nowhere public that I've been able to find.

Shouldn't they be available to consider before people vote on joining this foundation?

[mscdex]

This may sound nit-picky, but IMHO it'd be best if we could stay with a live TSC meeting stream, even if it's not youtube. The live stream allows people to join IRC and ask questions during and at the end of the meeting. Even though there haven't been that many questions at the TC meetings yet, if we publicized this "feature" more, I think we might get more questions?

[KarbonDallas]

While I laud the effort to make things as transparent as possible, I think it's unnecessary (possibly harmful) to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

I believe maintaining minutes should be more than sufficient.

[mscdex]

@emilyrose AFAIK the GotoMeetings are already being recorded, just like the TC meetings are archived on Youtube. The difference however is that GotoMeeting can't do live streaming (too).

[Fishrock123]

to require that every TSC member be willing to be subject to a live stream every time there is a meeting to be had.

Usually we have a brief time before anyone wants to discuss anything not publicly, does that help?

[RnbWd]

:thumbsup:

[comprehendreality]

:+1:

[brucebentley]

👍🏻 from me as well. The docs & process look solid & I think it's probably about as appropriate a time as ever to make this happen.

Would be much less transparent of the two strayed further away from each other.

[akyoto]

:+1:

[carpii]

I don't want to see io and node completely diverge, but personally I cant help thinking joining a foundation seems a touch premature. Admittedly it seems I'm in the minority.

It felt to me like io had an opportunity to achieve so much more in the short term - free from the constraints of politics and a 'foundation' environment - even if this isn't sustainable long term Clearly a unified node and io platform is better for everyone ultimately, I just wish it wasn't happening quite so soon.

It does seem like Joyent have seen which way the wind is blowing, and decided to open up rather than be sidelined. Nothing wrong with that I suppose, I just hope the foundation finds the right blend of staff and skillsets (which I don't think node.js team quite managed)

[Qard]

@emilyrose I disagree. If anything, I think everyone involved should want their progress and discussion to be public.

It's because of this transparency that io.js has been able to so rapidly grow. People can follow along, learn what direction we are driving the project in, ask questions about things they don't understand and get positive responses to their questions. That feedback loop is what drove node, and now io.js, to be so popular in the first place.

I think we need to stay vigilant about involving the community in every part of the evolution of the project. We need to keep cycling new faces into the leadership positions, and that's going to be hard if people feel like they are just sitting on the sidelines and not actually getting involved themselves. I very strongly believe we need to do everything in our power to maximise transparency and community involvement.

[formula1]

@emilyrose tbh, the tc meetings made me feel like I knew the developers better. Its also pretty interesting the descrepency between timezones and not everyone shows up all the time. I get to peek for the first time in my life what its like to work on a team where everyone is an allstar and pushing for progress. Seeing people just brutally honest saying "I didn't do anything" makes it that much better. They are there for a reason and at times life and other things get in the way. I have thoroughly enjoyed hearing them and am trying to make it a regular thing at my workplace.

https://github.com/joyent/nodejs-advisory-board/blob/master/governance-proposal/WG-Merger.md

Streams and Tracing working group have broken links. Streams is probably one of the most important differences between the two projects since iojs went with Isaacs Readable stream if I recall correctly.

I'm actually quite suprised how much pull you guys have. The interesting part to me however was TSC charter

The Board will set the overall TSC Policy.

This can also mean that these docs/charters are temporary.

The Board may additionally make amendments to the TSC charter at any time, though the Board will not interfere with day-to-day discussions, votes or meetings of the TSC.

Technically major changes to the charter will allow the interference. Though that is a cute example, the implications are much bigger.

No more than one-fourth of the TSC members may be affiliated with the same employer.

Techinically Mozilla and Google are different companies. But many of us are fully aware of who pays some of mozillas bills. A more brutal example is something like Comcast/TWC merger where the two companies have no desire to compete but do so by law. So the employer restrictions still allows possible conflict of interest leading to a 50%. I would argue voting rights to employers should be based on how much they have contributed recently however cannot vote on what they are associated with. However your version is much more straight forward.

Outside of this its really incredible how much power you guys have. At the end of the day, the person who pays the bills ought to have the most say so I don't necessarilly question things too much. Though when it comes down to it, if things go down hill maybe we can see another fork. Doubtful though

Edit: +1

[rvagg]

re live streaming, there are a few things worth noting about how we've been conducting these in io.js that may alleviate any concerns:

1. as @Fishrock123 pointed out we usually have a private time beforehand if there are sensitive things to discuss, this time can be used to bring things up that members may not feel comfortable talking about in public although we do tend to push as much as possible into public broadcast to retain the integrity of the process
2. most meetings are just avatars talking to each other, there's no reason to show video, something I appreciate at 6am after I've rolled out of bed!
3. there is a chat channel in the hangouts that can be used as a side-channel, in the past we've had meetings where one party has audio difficulties and we've relayed communication via the chat channel into the public broadcast, there's no reason this couldn't be extended to people who may feel uncomfortable being broadcast.

I'm +1 on addressing any concerns that people may have about making this comfortable so we can include as many quality people as possible and not restrict it to just those who are brave enough to be broadcast. We could document some of these things to make it less intimidating. Alternatively when we're approaching new potential members we could make these things clear then--that process of asking people if they want to be involved is actually a great chance to address concerns and I've had the chance to do that already with new members we've invited in.

[yadakhov]

:+1:

[zeusdeux]

:+1: for convergence as well as live streaming (<- this, yes!)

[garthk]

Exciting. Go for it.

[sintaxi]

Thanks for putting this together and for everyones hard work coming up with a potential solution.

:+1: I am in favour of convergence.

[YurySolovyov]

I think it is possible to re-stream meetings to youtube from someone who is attending. +1 btw.

[Zolmeister]

+1

[neurosnap]

:+1:

[blakev]

Which side is caving to the other to conclude in a "foundation?"

It took all of a few months to branch out, do something great, then re-merge with the same people that made it bad in the first place. My involvement only goes as far as reading changelists and running the installer, but it seems like kind of a cop-out.

[rlidwka]

-1 for joining the foundation under these conditions before all nodejs changes are merged.

I don't like a policy "commit to joining first, resolve merge conflicts later" with a requirement that "all changes should be merged".

This approach could backfire. I don't follow node.js development closely this year, but I could easily imagine that they could've added features that would be rejected in io.js now. When/if that happens, io.js would already be committed to merge.

It's even worse: after io.js joins the foundation, node.js development team will have an opportunity to add any changes to node.js that will be merged into io.js later. And we can't back off on that.

I see only two acceptable ways to deal with a code base merge:

1. make a new repository to perform merge, and only after merge is complete, join the foundation
2. join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

[formula1]

@blakev that was something I was thinking about as well. However, they want market share and its easiest way to essentially become node rather than competing with no promises of ever being considered as first choice. Also there's something to be said for this being the plan in the first place. One of the first posts I read was from bert which basically said, "we are upset but want to merge again one day". This was the plan all along so only node is caving technically.

[mscdex]

I agree with @rlidwka, it does seem kind of backwards to have to join first and then work out (code) merge issues. Even though we may have a good general idea of what's unique to node.js and what's unique to io.js, there could be some changes (obvious or not) that end up causing issues during the merge. I think it's best to iron out any of those problems before joining the foundation.

[q2dg]

I agree with option 2 from @rlidwka

[mikeal]

@rlidwka @mscdex I don't agree. First of all, we're starting with io.js master. Then we're working towards a new release that takes in the new features from node.js and it makes sense to do that as a combined TSC.

Additionally, those changes to core will follow the same process they have already done in io.js, first the colloborators review and if controversial the change is elevated to the TSC, and in both of those groups people from io.js have a majority.

It doesn't make sense to have two governing bodies (io.js TC and node.js core) pick apart each of these diffs separately, the entire governance process we've designed is there to facilitate cooperation.

It's not a healthy to say "you go make all these changes to merge the project and we, without your input, will decide what we like and what we don't like." That isn't cooperation, and we're going to be cooperating for the foreseeable future.

[mikeal]

join a foundation with io.js code as is, and make all node.js changes as PRs to a new repo with no guarantee of merging (although those changes would be reviewed by a merged TSC)

This is essentially what we're doing but with a slightly varied ordering. We start with io.js master, merge the work from node.js over, then prior to the first release people can propose changes as PRs (including reversions). We talked about this on the last convergence call and backed off of the whole "just merge everything and release" strategy but we did agree that the removal of functionality priorly available in either io.js or node.js would need to be removed as a removal rather than as a challenge to the merge PRs.

[nodebotanist]

From a less technical perspective: we just had an interesting online discussion as a whole on diversity concerns. Will any of these be taken into account by this merge?

Frankly, I have less trust in the Node community caring about diversity in leadership than I do the IO.js community right now. And I guess a lot of that is because Node has a longer history to stare down, and IO has relatively little.

But, just to put my two cents in, what I'd really like to see from the Node foundation before I let myself get too excited is a plan-- a concrete, distinct, descriptive plan-- to make people feel safe and welcome contributing to Foundation projects, be that in code, writing, or community.

[mikeal]

@formula1 I'll try to bring some perspective and context to the language you're addressing.

So, the foundation as a legal entity is formed. It's a member driven organization so the members are added, they have a board meeting, and immediately pass a resolution to establish the TSC. That charter establishes autonomy for the TSC and anything the TSC produces but, for legal reasons, can't allow the TSC to change the charter the TSC is established under without board approval. The language pertaining to the board being able to alter the document is there because that's the only legal way we can ever get any change in to it. The board would never change the charter without TSC approval, it would be crazy to intervene with the contributors like that, they are an autonomous body that runs the project, if they were to fork again (as we've proven we're willing to do) it wouldn't be like the last fork because we'd literally take the entire project and every contributor with us, the board would never risk that happening. Instead, that language is there so that if the TSC wants to change the charter they can vote on it and send it to the board and then the board can change the charter. This is annoying, and because it is annoying we did everything we could to remove things from that charter. The TSC charter is much smaller that io.js' governance doc because everything we could move in to the development policy and out of the charter was done so that the TSC could alter it more easily.

I hope that gives some perspective.

[mikeal]

@nodebotanist on the technical side it's the same people with the same problems. Having this over frees me and a few other people up to focus on issues like diversity though. Additionally, open source foundations in general are getting very concerned about diversity. In particular, foundations are in a different position than projects without a legal entity because the foundation (and its members) can be held libel for any discrimination. When we got to the Code of Conduct I recall the foundation people saying that they would like to see a foundation wide (which will eventually be larger that just the projects we have now) CoC that is a baseline and a requirement of being in the Foundation, but also encourage projects to go a step further and produce and iterate on additional codes of conduct.

Also, for the first time we'll have money we can put to work on problems like this if it's something that money can help resolve (I don't know for sure that it is, but at least it's now an option).

[Zayelion]

I feel leadership in io.js is fine, and the project's goals where to merge back and that is being accomplished.

+1

@emilyrose I agree particially with this, but mostly disagree. I think that each member if possible should join the live stream, or be in the IRC at the time of the discussion if they are not showing their face, or using their voice, just physically there at their comfort level. People joining the tc become public figures to our community that type of leadership requires fighting some introverted habits. Speaking from experience.

[mikeal]

I'm just curious, how many people here regularly watch the live streams? I think our impression being in the meetings is that nobody is on because when we ask for any questions in IRC we don't see anything.

[mscdex]

@mikeal I think if we advertised the "ask a question in IRC" better, we would have a better turnout. Have we ever done that (in advance)? I'm not even sure if many people even know in advance when to watch for TC/TSC meetings (live streamed).

[Zayelion]

@mikeal They happen in the last hour of work for me so I usually watch them. You guys chitter chatter awkwardly for a while and drag things out. It's like a SCRUM master's nightmare. I end up turning it off and then when I get home I pick through the video. I haven't felt the need to join the IRC because my concerns are met.

[Fishrock123]

Frankly, I have less trust in the Node community caring about diversity in leadership than I do the IO.js community right now. And I guess a lot of that is because Node has a longer history to stare down, and IO has relatively little.

But, just to put my two cents in, what I'd really like to see from the Node foundation before I let myself get too excited is a plan-- a concrete, distinct, descriptive plan-- to make people feel safe and welcome contributing to Foundation projects, be that in code, writing, or community.

I feel it is about time I echo some part of this. I've been reserved in saying such, as the point of this isn't to have hostility between the projects.

Node could currently adopt a CoC, open it's governance more, and do much more to include it's users, even without a foundation, yet it has not.

That saddens me, and leaves me somewhat weary of the situation.

[Fishrock123]

make a new repository to perform merge, and only after merge is complete, join the foundation

@rlidwka Work has begun on that here: https://github.com/jasnell/node.js-convergence

live streams

I preferred these when I wasn't in the meetings yet, but I could be a more special case. I would however, prefer them to still be recorded. Subtleties don't always get noted perfectly in minutes.

[bnoordhuis]

@rlidwka's point is valid but I don't think we have that much to worry about. The only two contentious issues I can think of are:

1. i18n support. I personally don't mind if we merge that wholesale from joyent/node and then figure out how to make it better.
2. mdb_v8 support. Joyent is AFAIK the only user of that and they have a pretty terrible track record of keeping it up to date upstream. We should probably add an exemption in case they fail to step up because I don't think lack of effort on their side should hold up a release.

[Fishrock123]

Also, I have seen some concern here and there regarding IBM's involvement, and would like to address it.

Regardless of the company, their interactions with the project would still be within our governance. Also, the interactions I have had with the IBM folk, both through meetings or otherwise, has consistently been positive.

[Zayelion]

Subtleties don't always get noted perfectly in minutes.

I and others agree, emotional context is important. There is a sociological aspect to programming that reflects in the stability of the project let us not mute it. It being muted is what caused io.js in the first place.

[nodebotanist]

I entirely and completely back @emilyrose on the consent to being recorded: it's not just about transparency, it's about the safety of those involved making decisions. Meeting notes are fine, and transparency can be maintained by them.

If you're wondering why it's not a defacto "yes I am OK with being recorded at all times", maybe think about how recordings and images of folks have been used to harass them.