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

Join the Node Foundation? #1664

Closed
mikeal opened this issue May 8, 2015 · 202 comments
Closed

Join the Node Foundation? #1664

mikeal opened this issue May 8, 2015 · 202 comments

Comments

@mikeal
Copy link
Contributor

mikeal commented May 8, 2015

All the documentation for the Node Foundation is ready:

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
Copy link

👍 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
Copy link
Member

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
Copy link

Yes. This should be done.

@djensen47
Copy link

👍

@Qard
Copy link
Member

Qard commented May 9, 2015

👍 from me.
On May 8, 2015 5:30 PM, "Dave Jensen" [email protected] wrote:

[image: 👍]


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

@LongLiveCHIEF
Copy link

+1

1 similar comment
@aheckmann
Copy link
Contributor

👍

@aredridel
Copy link
Contributor

So far, big 👍

@Planeshifter
Copy link

👍

@cjihrig
Copy link
Contributor

cjihrig commented May 9, 2015

👍 I think this is best for everyone.

@luke-john
Copy link

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
Copy link
Contributor

mscdex commented May 9, 2015

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
Copy link

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
Copy link
Contributor

mscdex commented May 9, 2015

@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
Copy link
Contributor

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
Copy link

RnbWd commented May 9, 2015

👍

@comprehendreality
Copy link

👍

@brucebentley
Copy link

👍🏻 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
Copy link

akyoto commented May 9, 2015

👍

@carpii
Copy link

carpii commented May 9, 2015

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
Copy link
Member

Qard commented May 9, 2015

@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
Copy link

formula1 commented May 9, 2015

@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
Copy link
Member

rvagg commented May 9, 2015

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
Copy link

yadakhov commented May 9, 2015

👍

@zeusdeux
Copy link
Contributor

zeusdeux commented May 9, 2015

👍 for convergence as well as live streaming (<- this, yes!)

@garthk
Copy link

garthk commented May 9, 2015

Exciting. Go for it.

@sintaxi
Copy link

sintaxi commented May 9, 2015

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

👍 I am in favour of convergence.

@YurySolovyov
Copy link

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

@Zolmeister
Copy link

+1

@sindresorhus
Copy link

687474703a2f2f7777772e7265616374696f6e676966732e636f6d2f77702d636f6e74656e742f67616c6c6572792f64616e63652d70617274792f74756d626c725f6d306f73727268714d6b31717a6376376e6f345f3235302e676966

@xdartxvictor
Copy link

@ionmx
Copy link

ionmx commented May 13, 2015

👍

@alumowa
Copy link

alumowa commented May 13, 2015

🎉

@adamsrog
Copy link

Huzzah! 👍

@GastonRosso
Copy link

Nice, thank you!

@tjstebbing
Copy link

This is horrible 👎 ..

ok I just wanted to be contrary, woohoo ! 👍

@samuba
Copy link

samuba commented May 13, 2015

batman approves

@lprimeroo
Copy link

Great (y) !

@selfrefactor
Copy link

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

@ghost
Copy link

ghost commented May 14, 2015

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

@APTy
Copy link

APTy commented May 14, 2015

😎 👍 fantastic

@christianbundy
Copy link

👍

@Qard
Copy link
Member

Qard commented May 14, 2015

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

@filipedeschamps
Copy link

Congratulations guys!!!

@andrewdeandrade
Copy link

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
Copy link

👍

@carloscheddar
Copy link

@TooBug
Copy link

TooBug commented May 14, 2015

Thanks for all your efforts!

@ericmdantas
Copy link

Great job, everyone!

@karlbright
Copy link

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

@Waterloo
Copy link

This is going to be awesome guys...

@izolate
Copy link

izolate commented May 14, 2015

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

@nodejs nodejs locked and limited conversation to collaborators May 14, 2015
@Fishrock123
Copy link
Contributor

Thanks all. I'm going to limit this discussion to collaborators, but anyone is free to either email me ([email protected]) 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
Copy link
Contributor

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
Copy link
Contributor

@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 ([email protected]), and I'll be happy to answer questions / respond to comments. :)

@jasnell
Copy link
Member

jasnell commented May 14, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests