So are io.js and Node.js going to merge? I would love to see that. I realize that io has had a lot more freedom and progression but we were just barely able to get "official" approval to use Node at my current company - slow moving, I know; Point is, the "node" name means a lot to the community and has trust and maturity behind it for managers and conservative leads; I'd love to see the innovation and contributors of io come back under the "node" umbrella to get the best of both worlds :)

Ok, huge update with what I could pull out of the dev policy before I passed out :)

So are io.js and Node.js going to merge?

That has not been decided. What we're trying to do here is figure out what that would actually look like and push it in a direction that is acceptable to everyone.

"When new features in the JavaScript language are introduced by V8, there will be a semver-minor version increase." io.js has never had to deal with this, and I doubt it will ever come up because when v8 ads language features it's in a major release anyway.

Why is it necessarily a major release? I feel like I might have missed something about V8 bumps and major versions and was under the impression that we were only bumping major (2.0) for the next V8 upgrade because it seemed like a good chance to throw some of the semver-major changes in. But, a V8 upgrade, even introducing language features, should generally only ever be a semver-minor unless they really screwed something up. I think we've created an exception around the C++ API and Chrome isn't very likely to break JavaScript-land stuff.

btw, thanks for this @mikeal, makes it so much easier to grok for those of us who are time-poor. Overall the list looks fairly manageable if this really is all there is to it.

@rvagg sorry, I'll try to state that better. What I meant is, I haven't seen v8 add language features in a release that didn't break ABI from its prior stable release. The policy as stated actually says that we're only going to increase the minor on a language addition but I'm pretty sure that in practice we'll end up eating a major version bump anyway for other reasons.

@rvagg said
this makes it so much easier to grok for those of us who are time-poor.

Agree, so I apologise in advance if below should live somewhere else.

@mikeal said
"Master must pass a full CI test run prior to release."

This needs to be improved:

• It limits when a release can be made since we're fighting longstanding test failures on some platforms. It additionally encourages hiding issues under the rug so a release can be made.
• It prohibits new platforms to be added to CI. We'd essentially avoid adding OpenBSD because it'd add 10 test failures that would in turn push a new release indefinitely.

Another small difference I've noted is that nodejs seems to prefer Reviewed-By as their first "meta" in the commit message while we prefer PR-URL. I would suggest changing the order in the document as well as stating order should follow the list (pr-url to reviewers to fixes).

Finally, I haven't seen anything about how different commits should land in different branches. For now, io.js handled it by PR'ed merge-commits but I doubt that'll scale. Labels could simplify the life of the person merging, but who decides what goes where and when?

It limits when a release can be made since we're fighting longstanding test failures on some platforms. It additionally encourages hiding issues under the rug so a release can be made.

Is this still true in io.js? I was under the impression that on primary platforms all the tests pass.

It prohibits new platforms to be added to CI. We'd essentially avoid adding OpenBSD because it'd add 10 test failures that would in turn push a new release indefinitely.

The "Platform Stability" section tries to address this. Basically, you can add OpenBSD to CI, and it'll run regularly, but it won't block a release.

Is this still true in io.js?

Yes and no. Jenkins tells us there's three failing slaves on the last run. Since some are only reproducible within a Jenkins environment it's arguably classified as heisenbugs. With language like that (even if platform stability addresses cases like new platforms) a critical bug fix release shouldn't go out even if the CI itself is to blame.

The bigger picture is great though. We're in better shape than ever and will soon be 100% green (jenkins-speak: blue) -- but I'd rather be slightly less strict than "break the rules" when we end up in that situation.

@jbergstroem interesting, can you log an issue on the dev-policy repo about that.

@mikeal ... heh, I just put a new PR that would update some of the dev-policy details (simplify based on feedback). It would likely reduce some of the deltas. Tomorrow I'll go through your list above in detail and see if I can call out the possible changes.

nodejs/dev-policy#59

The suggested edits in the PR simplify some of the platform stability issues by collapsing the notions of "primary" and "secondary" into just "supported". I think it's an improvement but I'm operating on little sleep so additional eyes on it would be appreciated.

• Multiple "core" projects.
  • Basically, this allows for another sizable project, like express or hapi, to join the foundation and get its own TSC at the same level as the Core TSC.

I'm curious if there is any movement to include running automated tests on such "sizable" projects prior to a major or minor release (probably not needed for "patch")? Obviously the representatives of these projects could run them on their own, but would there be benefit to the community in providing automated test running for those larger projects? It wouldn't necessarily have to be blocking, perhaps just reported and available to any/all who might be interested in that. (Again, I'm thinking prior to a release, not post-release... By that time the projects should already be pulling in the newest and testing, but it's too late at that point to alter the release.)

All-around it all sounds pretty good. I'm slightly concerned about only two points here:

• Voting rules and consensus seeking model are identical except that a 2/3 majority is required when changing the TSC Charter and when adding/removing members of the TSC. I hope this won't be a roadblock. Maybe break the charter into core and other?
• With a few notable exceptions, the Node.js Core Library API is largely built around ES5 Language features. While there are currently no plans to do so, it is possible for post-ES5 JavaScript language features to be introduced into the Core Library API in the future. I think this only feasible if Node.js and io.js either merge completely, (I don't know why they wouldn't) or if the at least maintain some kind of API compatibility.

The future seems to be good for for node and io.js

Ok, so if you go take a look at the updated dev-policy draft, I've refined and simplified the LTS language and took out the troublesome strawman LTS process. The overall document is much more straightforward. There are also edits to the Platform Stability and Build stability pieces.

@jakerella there is work underway to add automated ecosystem testing in.

@jbergstroem as @mikeal suggests, it would be helpful to have an issue filed in the dev-policy issue tracker. It sounds like we may need to make some allowances for some failing tests but we'll need to craft some language around it.

@nmn

I hope this won't be a roadblock. Maybe break the charter into core and other?

So, the io.js governance policy is intermingled with the dev policy and some other process definitions. In the foundation the TSC Charter is "as small as possible" because it's the only document that requires the board to approve changing it as a point of process. In a way, the charter is already "core" and everything else is in the dev policy (which is sizable) and can be changed more easily and under the normal majority voting rules.

In a foundation all the property is owned by the foundation (legal entity)

So all these "assets" will in the future be owned by the foundation:

• Domain name and DNS is owned by Fedor.
• Twitter is registered by Fedor but login shared with about a dozen people.
• Google Plus, Facebook, and Medium accounts by Mikeal.
• GitHub org by Colin.
• Build resources donated by various companies differing by architecture.
• Signing keys are from NodeSource (I think?)

In addition:

The TSC is given autonomy to run:

• the technical side of the project and do releases but
• the foundation sets the budget, administers funds, and handles all legal matters.

So not only will the foundation own the assets, the board of directors, which runs the foundation, will be able to change their mind in the future and lobby (using budget restrictions, their power through administration of funds) to disempower the TSC.

Cant the TSC be the board of directors and hire managers to do all the formal stuff with which the TSC doesnt want to be concerned? Also software to automate processes could be written so that makes the "boring administration" part as simple as possible.

Personally, by now I strongly prefer the name "iojs". A budget might have not been necessary in the past and in the future, efforts could be made to have a crowdsourcing (donation based) approach, where people can just donate for certain features or "github issues" to be solved.

Something, that doesnt formally empower people, but changes are being made because all sides agree.

@serapath ... one point that seems to be confusing for folks is this notion that the board will somehow be able to use it's management of the foundation budget to somehow control the TSC's decision making. It should be emphasized that the operation of the TSC is, in no way, dependent on the budget. The budget is intended to be used for things like paying for marketing, infrastructure, conferences, etc. One could argue, I suppose, that the board could refuse to pay for some bit of infrastructure needed by the project but then the board would very quickly end up with a revolt on their hands, which helps no one.

It should also be pointed out that the board does not get a say on who is on the TSC or who gets to become a Collaborator. Those decisions are solely in the hands of the TSC itself. The only way for a company to influence the projects direction is to roll up their sleeves and become active Collaborators just like everyone else.

Ok, to put it another way.
Way would you give some kind of board and funding EXCLUSIVE formal permission to decide whether they give funding to certain infrastructure or not? (Especially when the board or foundation will use their "exclusive access" to the TSC to lobby for the interest of companies or other particular interest?

I know, those "particular interest groups" will approach anyway, but it's not necessary to give them some special communication access.

Why not make the TSC and all its WGs something open, that anyone could approach in an indiegogo like approach or maybe pledgebank

The people actively engaged in open source development create something thats very beneficial to the community at large. Now some dudes surrounding joyent, the foundation and I dont know which particular interest, want an exclusive channel to have some power indirectly granted by all the open source developers that grant them this exclusive access.

It is nothing that I feel is compatible with the core values of iojs and things should be open, transparent and especially create an environment, in which everyone is equal, can contribute and try next to everyone else to succeed and create value.

We do not need certain people, many of them not even involved in creating open source code, to have exclusive access to those who are currently in "high demand" because of their exceptional skills and awesome contributions.

That's my opinion.

How does the board have "exclusive" access to the TSC? I'm not even certain
what that means. The TSC decides what tools and infrastructure it chooses
to use based on the technical needs of the project. They send the
requirements to the board if funding is required. The board could, I
suppose make suggestions but it's up to the TSC to decide what tools it
wants. And again, if the board ignores the TSCs request, they'd be facing a
revolt so what's the gain? Furthermore, there are conflict of interest
checks built into the governance process to help prevent mismanagement.

I'm not sure where you're coming up with this "special communication" idea.
On Apr 15, 2015 2:16 PM, "serapath" notifications@github.com wrote:

Ok, to put it another way.
Way would you give some kind of board and funding EXCLUSIVE formal
permission to decide whether they give funding to certain infrastructure or
not? (Especially when the board or foundation will use their "exclusive
access" to the TSC to lobby for the interest of companies or other
particular interest?

I know, those "particular interest groups" will approach anyway, but it's
not necessary to give them some special communication access.

Why not make the TSC and all its WGs something open, that anyone could
approach in an indiegogo http://www.indiegogo.com like approach or
maybe pledgebank http://pledgebank.com

The people actively engaged in open source development create something
thats very beneficial to the community at large. Now some dudes surrounding
joyent, the foundation and I dont know which particular interest, want an exclusive
channel to have some power indirectly granted by all the open source
developers that grant them this exclusive access.

It is nothing that I feel is compatible with the core values of iojs and
things should be open, transparent and especially create an environment, in
which everyone is equal, can contribute and try next to everyone else to
succeed and create value.

We do not need certain people, many of them not even involved in creating
open source code, to have exclusive access to those who are currently in
"high demand" because of their exceptional skills and awesome contributions.

That's my opinion.

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

@serapath

It's quite easy to theorize new models for funding projects and compare those idealistic models with any concrete proposal.

We are not the first open source project to have these kinds of needs. We talked to many projects about how they resolved similar problems a year ago and found a model that is working for several of them (we also found a lot of projects that didn't like their arrangement and steered clear of those).

The TC does not want to handle marketing, legal, etc directly. I've been involved more directly in this stuff than anyone and the idea of increasing our direct personal responsibility in these areas is not something I would be excited about or recommend. That is not to say that the TC does not want any influence or participation in these kinds of decisions, they just don't want to be responsible for the directly, and this foundation model is the most preferable.

The Node.js Foundation's offer is compelling because it doesn't alter our current processes and lets us continue running the project as we've found most effective and brings the node.js assets to the table. The Linux Foundation has a lot experience doing "the rest" of the foundation work and they've put together something pretty good that we need to seriously consider and we aren't going to compare that against an entirely unproven proposal that requires we do a ton of extra work that takes time away from working and releasing the platform.

It's beneficial to rely on the foundation's proven, and well funded, approach to tackling legal and PR so that we can continue to be bold and iterate on new models of project governance, collaboration models, and community building.

@serapath you may also be interested in a previous comment I made about board influence https://github.com/joyent/nodejs-advisory-board/pull/30/files#r27698737

I'm not convinced of the necessity of having a board, but I'm too far away to understand the details.
If you say it'll be beneficial, then I believe that for now.

It's a bit sad, that the TC does not want to be responsible and lead and build the tools to automate the decision and management processes, but maybe that might happen in the future and for now it's nice to have the freedom to experiment a bit more and have a hopefully responsible board in the meantime.

In the end, what will happen is what you and the other current members of the TC agree upon.
The rest of us will maybe comment or just silently observe. If it will work out it will work out, if not, things can be renegotiated and as long as it will continue to be possible to fork again, chances are everything will actually work out fine.

I'm not convinced of the necessity of having a board

A board is a legal requirement for having a non-profit.

that the TC does not want to be responsible and lead and build the tools to automate the decision and management processes

This isn't a technical problem. If it were then LegalZoom would have a way for us to setup and manage the non-profit. Non-profit accounting and administration is somewhat specialized and the information not entirely accessible to everyone. This comes up whenever someone says "just start a foundation." It's not that simple, it's the opposite of simple, because the government really doesn't want people starting them.

By comparison getting a company and handling the accounting is quite easy and straightforward, I have an LLC that I use to run the conferences under and it's a fair amount of work but was something I could figure out and find a lot of relevant documentation on. I clicked some buttons on LegalZoom and had a license in a few hours and a bank account a week later. That's because the government wants people to start businesses. Unfortunately having a for-profit entity owning project assets is what got us in this mess in the first place so this isn't an option.

I know, I meant I'm not convinced of having a non-profit, but I understand.
Instead of having a complex legal entity, each individual could be encapsulated in some standardized legal container and contracts could be used to have a more flexible composable way of structuring legal relations the way people want. There are many approaches towards "cryptocontracts", some are based on blockchains, (e.g. codius or ethereum, but it's easier to do the foundation now instead of figuring out how to do legal entities the node way and automate as much bureaucracy as possible.

What you are telling in regard to the LLC, I'm trying the same with an UK Ltd. right now, after deciding against the german "GmbH" (which is what people use where I'm from) - because of too many legal complications. I hope a Ltd. can be enough of a "standard vehicle" now, to start thinking about setting up an orchestrated network of contracts between them, accessible through APIs.

I don't understand the difference between "Non-Profit and For-Profit" anyway, feels to me like an accounting trick.

In UK there is quickfile and in the US you have waveapp. Both don't charge. Waveapp has plans to make an API but probably phantomjs could be used to get there in the meantime. Quickfile already has an API. After a lot of searching I found a couple of accountants in the UK that offered to take care of all the filing requirements for a flat rate of 20 GBP a month, but the accounting rules around certain common business models can be researched and open sourced and modules can be written to automate that too and connect to electronic government interfacces.

@jasnell

How does the board have "exclusive" access to the TSC? I'm not even certain
what that means.

That just means, that members of the board or in general members of the foundation or that are introduced through the foundation can talk to members of the TSC and WGs more easily than some "random" person or organisation who approaches the TSC directly, just because through means of the foundation they will have more contact in general.

The TSC decides what tools and infrastructure it chooses
to use based on the technical needs of the project. They send the
requirements to the board if funding is required.

So they will do that instead of publishing it to everyone to get some funding from everyone who is willing to support it.

The board could, I suppose make suggestions

Yes and that is the exclusiveness that I talk about, compared to every other interested person on the planet that would like to make "suggestions" :-)

"Any Modification to the ABI, dependencies or Native abstractions that require a developer to modify code and then recompile is considered a backwards incompatible change that must result in a semver-major version increase."

This could be a good advice in general, but I'm afraid such exact wording in the official documents will only give an excuse to ship out node.js with 2 year old V8 engine. We've been there before.

@rlidwka I'd agree, but as per yesterday's TC meeting, that is also the consensus for io.js, with the solution being, just do a major every v8, more or less.

@Fishrock123 , then it contradicts this clause:

"When new features in the JavaScript language are introduced by V8, there will be a semver-minor version increase."

If we do major every v8, all new JS features will be majors as well. You can't bring JS without updating v8.

I'm okay with switching to "browser versioning system". But updating v8 until it breaks ABI, then holding on that version several months/years until major release is really not cool.

Nothing much was discussed last week. Re-add the tc-agenda label when more info is available maybe.

Closing in favor of #1664 (progress yay!)