{"action":"created","issue":{"url":"https://api.github.com/repos/iojs/io.js/issues/1416","labels_url":"https://api.github.com/repos/iojs/io.js/issues/1416/labels{/name}","comments_url":"https://api.github.com/repos/iojs/io.js/issues/1416/comments","events_url":"https://api.github.com/repos/iojs/io.js/issues/1416/events","html_url":"https://github.com/iojs/io.js/issues/1416","id":68255814,"number":1416,"title":"Diffing io.js and the Node.js Foundation","user":{"login":"mikeal","id":579,"avatar_url":"https://avatars.githubusercontent.com/u/579?v=3","gravatar_id":"","url":"https://api.github.com/users/mikeal","html_url":"https://github.com/mikeal","followers_url":"https://api.github.com/users/mikeal/followers","following_url":"https://api.github.com/users/mikeal/following{/other_user}","gists_url":"https://api.github.com/users/mikeal/gists{/gist_id}","starred_url":"https://api.github.com/users/mikeal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikeal/subscriptions","organizations_url":"https://api.github.com/users/mikeal/orgs","repos_url":"https://api.github.com/users/mikeal/repos","events_url":"https://api.github.com/users/mikeal/events{/privacy}","received_events_url":"https://api.github.com/users/mikeal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-04-14T03:59:33Z","updated_at":"2015-04-14T05:11:38Z","closed_at":null,"body":"The foundation policy drafts are here but the sheer size and volume of documentation is a little intimidating.\r\n\r\nIn order for the io.js community to evaluate what a merger looks like we need a better way for everyone to understand what could/would change.\r\n\r\nI'd like to use this issue to track any differences between io.js and the Node.js Foundation policies. I don't want to make any judgement calls about these differences I merely want to expose each difference so that everyone can objectively evaluate it themselves.\r\n\r\n# Summary\r\nI'll keep this summary up to date as people find more differences and post comments.\r\n\r\n## [TSC Charter](https://github.com/joyent/nodejs-advisory-board/blob/master/governance-proposal/TSC-Charter-Draft.md)\r\n\r\n* Charter states that no more than 1/4 of the TSC can be employed by the same company. io.js currently has this at a 1/3 rule.\r\n* Charter defines a \"TSC Chairperson.\"\r\n * Chairperson holds the responsibilities that io.js' current moderator holds.\r\n * Chairperson represents the TSC on the foundations Board of Directors\r\n * Chairperson is elected by TSC using Condorcet or Single Transferable Vote\r\n* 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. In io.js **all** decisions when brought to a vote are simple majority.\r\n\r\n## [Project Lifecycle](https://github.com/joyent/nodejs-advisory-board/pull/33)\r\n\r\n* Lifecycle Ladder\r\n * In io.js there are two WG states: chartered and un-chartered. Working groups begin informally and collaborate until they are mature enough to write a charter which is ratified by the TSC.\r\n * In the foundation, working groups are \"incubating\" when they are working either unchartered or completely outside the foundation. When they write a charter they are in the \"Proposal\" phase until accepted and then are considered \"Mature\" which is identical in state to io.js' \"chartered\" state.\r\n * A final state in the Lifecycle is \"Core\" which has no equivolent in io.js. Once a WG reaches the core state they get a TSC seat.\r\n* Multiple \"core\" projects.\r\n * 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.\r\n* In io.js working groups are chartered by the TSC at their discretion. While it is not done being drafted the review requirements for each state change will be documented in the lifecycle.\r\n\r\n## [Development Policy](https://github.com/jasnell/dev-policy)\r\n\r\n* [Guiding Principals](https://github.com/jasnell/dev-policy#guiding-principles) is a project vision that is lacking in both io.js and node.js as formal documentation and is really only understood culturally.\r\n* Collaborators\r\n * Describes the process: a new issue is created by a TSC member with recent contributors and the names can be challenged by other contributors the same way changes are reviewed to reach a consensus. This is the existing io.js policy but it is not formally document in io.js.\r\n * Explicitly states that TSC candidates be nominated from the pool of Collaborators. This has been the case in io.js but it is not explicitely stated.\r\n* Accepting Modifications\r\n * Wide and well documented definition of \"contribution.\" Similar if not identical to the io.js cultural definition but not formally documented yet.\r\n * All pull requests must be signed off by another collaborator. The io.js dev policy has an exception for  \"trivial changes\" but in practice contributors (even long time ones) have been chastised for not getting a sign off. Note: the 48 - 72 hour rule still has an exception for \"trivial changes.\"\r\n * Any PR that will bump the *major* version will be elevated to the `tsc-agenda`.\r\n * Exception to all processes for critical security vulnerabilities. Since the security policy responsibly discloses fixes they may need to be done outside of the regular public process.\r\n * \"All Pull Requests that either fix bugs or introduce new functionality require at least one test case\"\r\n* *master* is the current branch. This differs from io.js' current policy but matches @chrisdickinson's proposed improvements to it.\r\n* *release* branches (prior major releases) are owned by the LTS working group. io.js states that a future LTS WG will handle these kinds of *releases* but the branch ownership has not been addressed.\r\n* Issue Tagging is formally documented. The tags and strategy match the current io.js practice which is undocumented.\r\n* Release Branchs for LTS. This is totally new and has no equivalent in io.js at this time.\r\n* Release Versioning requirements are defined for *major*, *minor* and *patch*. io.js simply states that \"semver\" is the policy without a greater definition.\r\n* \"Releases should not contain too many code changes and if the rate of code changes is high then it should correspond to an increase in the rate of releases.\" This matches io.js in practice but cadence is not explicitly documented.\r\n* \"Master must pass a full CI test run prior to release.\"\r\n* Repository Reconciliation Plan\r\n * Obviously this has no equivalent in io.js because it addresses how io.js and node.js would be merged.\r\n * Versioning strategy would ensure that io.js and node.js do not have any version overlap.\r\n * A \"Convergence Working Group\" will define a more detailed proposal of how to merge the code and resources together.\r\n* LTS -- TODO (I'm not familiar with the state of the LTS discussions Rod has been leading)\r\n* Issue Workflow -- Still an open discussion, nothing concrete yet.\r\n* Stability Policy\r\n * Mostly similar to io.js Stability Policy.\r\n * Much more attention paid to ABI compatibility. \r\n  * Puts the ABI under the same semver major/minor/patch restrictions as the JS API\r\n  * \"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 Is *not* the current policy in io.js as it is currently documented but, in practice, the TC decided to float a small patch that broke ABI compatibility for a future major version release.\r\n* Implicit vs. Explicit API Stability\r\n * This section describes and area that is not very well understood or documented in either io.js or node.js. The existing policies in both projects have been subjective.\r\n * Basically, they are trying to define what is internal API vs. external API.\r\n * There is also a lot of effort spent on defining exactly how many type guarantees the API is offering implicitely vs. explicitely because types are rarely if ever documented formally.\r\n* Platform Stability -- In io.js we just sort of add platforms to CI and when they are green more often then not we start blocking releases on them. This section defines states the various platforms are in and what the stability guarantees are once they get a label.\r\n* Dependency Stability\r\n * \"Node.js will adopt new V8 releases as quickly as practically feasible. For LTS Releases, the version of V8 shipped must be fully functional with no regressions on all Primary Platforms.\" This is the io.js policy in practice but is not documented.\r\n* \"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.\r\n* \"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.\" This is a little bolder than we've gotten so far in io.js, we've never actually exposed any ES6 usage, only used it a little internally.\r\n\r\n## Other\r\n\r\n### Trademark\r\nRight now io.js has no trademark and as such it has no trademark policy. The foundation lawyers will be drafting a new trademark policy for node.js but it doesn't exist yet. Joyent's prior trademark policy will no longer exist.\r\n\r\n### Foundation Board of Directors\r\nio.js is not a legal entity. Property is owned haphazardly between several individuals and a handful of companies. Such as:\r\n* Domain name and DNS is owned by Fedor.\r\n* Twitter is registered by Fedor but login shared with about a dozen people.\r\n* Google Plus, Facebook, and Medium accounts by Mikeal.\r\n* GitHub org by Colin.\r\n* Build resources donated by various companies differing by architecture.\r\n* Signing keys are from NodeSource (I think?)\r\n\r\nA non-profit foundation is an actual legal entity and can own property. It is operated by the board of directors and elected executives. The board not only shares the task of administering the foundation but can, in some cases, be held legally and financially responsible for it.\r\n\r\nIn a foundation all the property is owned by the foundation (legal entity). 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.\r\n\r\nThat means that if someone wants to sue the project they would sue the foundation, rather than Fedor (good luck he's Russian), or me, or NodeSource."},"comment":{"url":"https://api.github.com/repos/iojs/io.js/issues/comments/92601724","html_url":"https://github.com/iojs/io.js/issues/1416#issuecomment-92601724","issue_url":"https://api.github.com/repos/iojs/io.js/issues/1416","id":92601724,"user":{"login":"mikeal","id":579,"avatar_url":"https://avatars.githubusercontent.com/u/579?v=3","gravatar_id":"","url":"https://api.github.com/users/mikeal","html_url":"https://github.com/mikeal","followers_url":"https://api.github.com/users/mikeal/followers","following_url":"https://api.github.com/users/mikeal/following{/other_user}","gists_url":"https://api.github.com/users/mikeal/gists{/gist_id}","starred_url":"https://api.github.com/users/mikeal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikeal/subscriptions","organizations_url":"https://api.github.com/users/mikeal/orgs","repos_url":"https://api.github.com/users/mikeal/repos","events_url":"https://api.github.com/users/mikeal/events{/privacy}","received_events_url":"https://api.github.com/users/mikeal/received_events","type":"User","site_admin":false},"created_at":"2015-04-14T05:11:38Z","updated_at":"2015-04-14T05:11:38Z","body":"@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."}}