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]

👍 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]

👍

[Qard]

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

[image: 👍]

—
Reply to this email directly or view it on GitHub
#1664 (comment).

[LongLiveCHIEF]

+1

[aheckmann]

👍

[aredridel]

So far, big 👍

[Planeshifter]

👍

[cjihrig]

👍 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]

👍

[comprehendreality]

👍

[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]

👍

[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]

👍

[zeusdeux]

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

👍 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

[sindresorhus]

[xdartxvictor]

[ionmx]

👍

[alumowa]

🎉

[adamsrog]

Huzzah! 👍

[GastonRosso]

Nice, thank you!

[tjstebbing]

This is horrible 👎 ..

ok I just wanted to be contrary, woohoo ! 👍

[samuba]

[kingroryg]

Great (y) !

[selfrefactor]

So it is official: Node.js will rule as this big obstacle is over.

[ghost]

6 months before it is on the same pathetic state things were before the fork. You heard here first.

[APTy]

😎 👍 fantastic

[christianbundy]

👍

[Qard]

@mrseth Not going to happen. The community has control now.

[filipedeschamps]

Congratulations guys!!!

[andrewdeandrade]

What's the expected timeframe on the codebase convergence and getting to 3.0?

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

[nickleefly]

👍

[carloscheddar]

[TooBug]

Thanks for all your efforts!

[ericmdantas]

Great job, everyone!

[karlbright]

Oh no! This means that the logo thread will come to an end!

[Waterloo]

This is going to be awesome guys...

[izolate]

Started to prefer the name io.js. In my mind, we should have just continued down this forked road.

[Fishrock123]

Thanks all. I'm going to limit this discussion to collaborators, but anyone is free to either email me (fishrock123@rocketmail.com) if they have a comment they'd really like to have here, or comment in irc or some other place.

Basically all issues that could be brought up have been brought up, and I'm sure you'd be able to either find them by searching, or ask a collaborator / tc member. :)

[Fishrock123]

6 months before it is on the same pathetic state things were before the fork.

As said, the new master will continue as things have in io.js

Oh no! This means that the logo thread will come to an end!

Ah, sadly yes. But we can always make a new thread for community node / io.js logos. Maybe we'll be able to open the node logo up to wider community interpretation and use. :)

Started to prefer the name io.js.

Ah same (naturally, I did come up with it), but it will still live on as having a huge impact on node. :)

[Fishrock123]

@petergombos asked by email regarding #1664 (comment):

What's the expected timeframe on the codebase convergence and getting to 3.0?

It could either be either be shorter or longer (weeks, maybe 1-2 months?), depending on what happens with the finer details. The current working copy of the merge can be found at https://github.com/jasnell/node.js-convergence, it’s pretty nitty-gritty though, and the work is still getting warmed up so there’s not too much to see yet.

Also, the websites need to merge so that a new node website can form with the same internationalization abilities as iojs.org currently has. Progress for this can currently be tracked at nodejs/iojs.org#350, this may also include an updated node branding in the future.

So again, weeks, maybe a month or two. The current node.js and io.js release lines will continue releasing while we work on this.

I see @Fishrock123's pull request. Is there a todo list of what remains after that is merged in?

Assuming you mean nodejs/node-convergence-archive#7 ? Lots. These are only to update that repo to iojs/master. Still need to pull in the changes from node.

Lastly, what's the deal with migrating existing open issues from node.js/io.js to the new repo?

They will remain as is and we will continue to reference them as-is. io.js issue will remain relevant for sure, and I'll keep a tab on them as best as I can. :)

---

Again, anyone is free to email me (fishrock123@rocketmail.com), and I'll be happy to answer questions / respond to comments. :)

[jasnell]

We're still compiling the actual todo list on the actual merges. It's a fairly nontrivial task.

Regarding the issues tracker, the existing issues db's in joyent/node and iojs/io.js will remain as they are, with a new starting-from-scratch issue db in the converged repo. It'll require a bit of coordination but having a new issue tracker was decided to be the least painful option.