Draft Node.js Foundation Technical Governance Documents #30
Conversation
|
|
||
| Multiple-candidate methods may be reduced to simple election by plurality when there are only two candidates for one position to be filled. No election is required if there is only one candidate and no objections to the candidates election. Elections shall be done within the Projects by the Collaborators active in the Project. | ||
|
|
||
| Each Core Project’s Collaborators shall elect one Maintainer from the Collaborators on the project to serve on the TSC. There may be only one Maintainer per Core Project that shall be nominated and elected by the Collaborators within the Core Project. |
There was a problem hiding this comment.
Given that the expected size of the TSC (as stated above) is 6-12, this implies that there will never be more than 12 core projects, correct? Or if that were to happen, would the TSC re-evaluate the project organizational structure as necessary?
There was a problem hiding this comment.
It would be up to the TSC to evaluate in the current model. It sets the goal/expectation, but leaves the TSC empowered to define the structure. 6-12 was chosen as a range of what would ensure diversity but also make it manageable to easily communicate and operate as a cohesive working team.
There was a problem hiding this comment.
It's also possible that a single person is involved in multiple core projects and chosen to represent more than one on the TSC, so the target of 12 doesn't necessarily mean a total of 12 core projects.
There was a problem hiding this comment.
Makes sense to me. Thanks for the clarification Mike and Mikeal.
| * Detailed documentation available documenting the code | ||
| * Core Review | ||
| * Core-state proposal posted for two weeks | ||
| * Project is shown to be viable, necessary or broadly useful module, subsystem or component of Node.js |
There was a problem hiding this comment.
This feels like one of the more important criteria for both Creation Review and Graduation Review. The following statement is in section 6 of the TSC charter:
...changes in the lifecycle of a Project, which will include consideration of the following criteria:
- ...
- Alignment with Node.js Foundation’s goals and priorities.
Would the "alignment" statement be useful to include in Creation Review to ensure that projects being incubated by the foundation / TSC are well within scope of the foundation's goals and priorities?
The only reason I ask this is that interpretation of something that is a "viable, necessary or broadly useful module, susbsystem or component of Node.js" could end up being very broad, and even extend to modules that may have historically been considered "user-land" modules. Unless that is the intent?
There was a problem hiding this comment.
It's possible that a user-land module is so fundamental to the platform that it deserves a TSC seat. IMO nan is already at that point.
|
@mkdolan I would suggest to give all the files a '.md' extension so github renders them properly. |
| * Meets Foundation’s policies (e.g. IP Policy) | ||
| * Proposal has been socialized with potentially interested or affected existing Projects | ||
| * Proposal email has been sent to the TSC mailing list | ||
| * Review by TSC: Confirm that the proposal is complete and the above listed requirements have been sufficiently met. |
There was a problem hiding this comment.
What qualifies as a "project"? Waiting two weeks to initally spin up a new working group for a repo (such as docker-iojs) would just be ludicrous.
There was a problem hiding this comment.
The way I interpret this is only for projects that want to be under the umbrella of the Node.js Foundation. Nothing should stop anyone from creating a repo for any project wherever they would like, but that projects under the auspices of the Node.js project should have a bit more rigor around their setup.
There was a problem hiding this comment.
Chris' response was exactly the intent.
There was a problem hiding this comment.
I'll just let future PR's resolve this. I.e. Totally impractical for research/test projects.
There was a problem hiding this comment.
@Fishrock123 how so? As I understand it, the projects can be created, and developed during that initial two weeks. What do you see as being a blocker for research/test projects?
|
So, do "Projects" replace io.js Working Groups? The rules here seem very restrictive for those. |
| * has a significant impact on the codebase, | ||
| * is inherently controversial; or | ||
| * has failed to reach consensus amongst the Collaborators who are actively participating in the discussion. | ||
| * The TC should serve as the final arbiter where required. |
There was a problem hiding this comment.
Good catch - it looks like a remnant of our copy/paste effort from the io.js documents.
|
@Fishrock123 the short answer is "yes," Projects should replace io.js working group definitions. That said, there's a lot of work to be done to reconcile this definition with the io.js working group definition, which I'll be working on soon. The LF has a pretty standard document for projects under a foundation which they have adapted as close as they can do our needs here. io.js Working Groups have been formed and a somewhat formal definition defined in an environment where we have no institutional or financial support. In contrast, this definition comes from the point of view of an institution which has certain liabilities (legal and financial) over any work that happens under its "umbrella." I'll be preparing a pull request to this document (after it is merged) which tries to reconcile the concerns of the foundation with the lessons learned in io.js about working groups which can be a charter that supports all the existing io.js working groups as well as future projects. |
|
|
||
| ## Section 3. Board’s Role in Setting Node.js Foundation’s Strategic Direction. | ||
|
|
||
| The Board will set the overall TSC Policy. The policy will describe the overarching scope of the Node.js Foundation initiative, Node.js Foundation’s technical vision and direction and project release expectations in the form of expected cadence and intent. The Board will use the TSC as a delegate body for governing technical implementation, individual project scope and direction while they remain within the scope and direction of the policies as described in the TSC Policy document and approved by the Board. |
There was a problem hiding this comment.
Shouldn't Technical Lead come before Business Lead, or is that not legally possible?
I suppose i.e. what good reason does the board have to be able to change the TSC policy?
There was a problem hiding this comment.
The Board is the legal fiduciary for running the independent legal entity that will be the Foundation. It's a corporate governance matter. We try to setup the TSC to run as independently as possible, but there are some things we just cannot avoid based on corporation requirements and responsibilities of a Board. "Non-profit organizations" are filed as (typically Delaware) corporations, then they seek IRS approval for 501(c)(3) or 501(c)(6) non-profit status. As a corporation, they need a Board that is responsible for the entity. By way of an extreme example, if the TSC decided to change the TSC Policy to focus the community on developing nuclear and biological weapons, the Board of the entity would ultimately be responsible for the outcome ;-)
There was a problem hiding this comment.
Perhaps it could be possible that the TSC / it's members hold the responsibility? That way maybe it could be laid out without requiring the board's potential ability to interfere.
Edit: discussion here in irc: http://logs.libuv.org/io.js/latest#19:57:12.833
There was a problem hiding this comment.
@Fishrock123 I talked with you a bit on IRC the other day about the required order of operations. But something else I should say: we need to create structures and policies which provide the right incentives and to do that we need to understand the motivations of the people involved.
The board doesn't actually want to make technical decisions. They want the project to run successfully in a way that doesn't hurt their business without needing to involve themselves directly. Those business interests vary from company to company and that's why it's actually quite nice to have a board of them so they can figure out what the commonalities are and share any concerns they might have with the TSC (who would be foolish to ignore input from the majority of businesses supporting the platform they are building). The concerns we had that lead to creating io.js are shared by many of those companies, otherwise the foundation wouldn't be trying to reconcile the projects. Those companies are now on a board or directors which is administering this foundation and if for some reason they ever did go crazy and try to make technical decisions they'd have to convince the other members of the board on those same technical decisions. Even more importantly, they would have to do all of this publicly.
These "what if" concerns are the same kinds of concerns you could have about anything, even io.js. What if more than 50% of the io.js TC decided to move the project to Java? It could happen if they all agreed to it but we all know it's so unlikely to happen that it's not worth even considering as a possibility and the reason it's so unlikely is that there are too many incentives for all the actors involved not to do it.
What you don't see in these documents are the legal, marketing, and public relations efforts. That is where these companies do want to be more involved. And being that all of those things cost money and they are the ones putting up that money I don't see why we shouldn't let them run it. Besides, they are actually quite a bit better at doing those things than a bunch of developers are. I'm sure there will end up being collaboration with the technical side on legal matters and evangelism on the marketing because there are incentives for everyone involved to collaborate together because we all bring something important to the table, we just need a place to facilitate that collaboration and that is what the foundation is meant to be.
We aren't going to all work together because we all have guns on the table pointed at each other. We're going to work together because one set of people have peanut butter, another jelly, and another some bread and a PB&J is far more delicious than any of those things individually :)
There was a problem hiding this comment.
@mikeal This is a wonderful explanation. I was concerned myself, but it seems the concerns about the Board being able to change the TSC policy come from the mental model of viewing the Board and TSC as adversaries. As you point out, that's a flawed way of looking at it; if we ever reach that point, it's likely a symptom of deeper issues.
Is it worth some thought about what happens if there is a disagreement between the TSC and Board? At least in my experience, business interests and technical interests don't always coincide; in your mind, how would such a conflict be resolved?
There was a problem hiding this comment.
@Morgul this is where the "wall" comes in handy between the TSC and the board. The TSC has autonomy, they have the final call on technical issues. If the board is unhappy with one they can't change it or veto it, all they can do is complain and if the TSC members care enough about that unhappiness it might influence them.
|
Certainly the tracing working group doesn't really fit well in the boundaries of a project. We're very research-oriented currently, and don't have a clearly-defined task beyond "make tracing better". The way "projects" are currently defined is not really conducive to research-oriented work or any forward-thinking effort, like NG that has no set "shipping" criteria. |
@mikeal does the document being pulled in have any significance to anything? I'd think those changes should be made here? |
|
@Fishrock123 my expectation is that this PR will be merged shortly and that there will be a period of time where we all make comments and alterations to those documents before they become official. That's why there are giant headings at the top of each document stating that they are drafts for public comment. As a practical matter it's easier to merge this and then discuss additional pull requests here than to send changes to a fork. |
|
I couldn't find one "open governance" once in this page. Did I screw up or did no one really mentioned it? |
|
I'd like to also see how the Board's governance will run, although I suppose that may come in a separate PR? |
|
@Fishrock123 I've seen the foundation membership agreements before, they were worked out before the announcement at Node Summit although I don't know if/where they are posted publicly. It's a pretty standard open source 501(c)6 where corporate membership is set at 3 levels, the top getting a board seat and the other 2 levels electing a certain number of board seats to represent them. |
|
@mrseth the TSC charter describes an open governance model, it probably doesn't say the words "open governance" because it would be redundant. |
|
@Qard yup, I'll be working on a big PR to revise the project life cycle so that it can work for our existing io.js working groups as well as future projects/wg's we can imagine wanting to house in the foundation. |
|
To the point about stating "open governance" explicitly, our projects at the LF normally assume that to be the case. We have in Section 1 what I have considered to be a statement of operating under an open governance model. I understand this community may be operating in a different political context at the moment, and while I personally think it's redundant given the terms in the document define the open governance model, we could insert the words explicitly in Section 1 if it's helpful to people. |
| * Confirmed acceptance and successful integration of contributions/code to partner/upstream projects. | ||
| * Testing/integration environment defined and mature, tests and integration run successfully | ||
| * Detailed documentation available documenting the code | ||
| * Core Review |
There was a problem hiding this comment.
It looks to me like the Core Review should be a level 3 heading rather than a bullet under Graduation Review:
Graduation Review
- Graduation proposal posted for two weeks:
- ...
Core Review
- Core-state proposal posted for two weeks
- ...
Termination Review
- Termination proposal posted for two weeks
- ...
There was a problem hiding this comment.
Yes, you're right. I just fixed that - thanks for the extra set of eyes on it :-)
There was a problem hiding this comment.
You're welcome! Its been fun to watch the project evolve and to be able to
make contributions—even if they're just nits :-)
On Mar 30, 2015 10:48 AM, "Mike Dolan" [email protected] wrote:
In governance-proposal/TSC-Project-Lifecycle.md
#30 (comment)
:
- * Proposal email has been sent to the TSC mailing list
+* Review by TSC: Confirm that the proposal is complete and the above listed requirements have been sufficiently met.
+
+### Graduation Review
+* Graduation proposal posted for two weeks:- * The Project demonstrates stable output (code base, documents, tests)
- * Active community working on the Project
- * History of successful, consistent releases in accordance with the release process
+* TSC review- * Working and stable code base exists
- * Active community exists
- * Project has demonstrated a history of releases following the release process and cadence
- * Confirmed acceptance and successful integration of contributions/code to partner/upstream projects.
- * Testing/integration environment defined and mature, tests and integration run successfully
- * Detailed documentation available documenting the code
+* Core ReviewYes, you're right. I just fixed that - thanks for the extra set of eyes on
it :-)—
Reply to this email directly or view it on GitHub
https://github.com/joyent/nodejs-advisory-board/pull/30/files#r27414126.
|
I've got a draft of a new Project Lifecycle off in a branch. I'd like to send it as a PR as soon as this is merged but until then: The biggest change is to the incubation and proposal phases. Basically, "Incubation" has two paths, either "bootstrapped" (inside the foundation) or a project matures outside the foundation to a significant point and then would like to join. In both cases incubation happens before a proposal or charter is defined. This allows us to experiment and create projects with less barriers but keep them at arms length (provisional status can be shut down at any time, no monetary or legal resources committed) and allow them to mature before we write the charter. In the io.js working groups we've found that it's best to remove barriers to people forming groups and getting work done and that it's much better to have groups write a proposal/charter after they've been doing work successfully. This change to the incubation phase actually reduced the number of levels and reviews, simplifying the process quite a bit. There are some other smaller edits and changes in the review processes that are trying to bring it more in line with the working groups we have in io.js which aren't strictly code projects with their own releases. |
|
What will happen to current Working Groups? |
Draft Node.js Foundation technical governance documents
|
@BenjaminProgram I'm working on a PR to this that brings the Project Lifecycle in-line with Working Groups enough that we could migrate them over under that structure. |
|
I've merged this PR so people can propose more updates as individual pull requests. |
|
These are starting to look good @mkdolan. Thank you for working with the various groups to help make this happen. I have a few questions; Is it possible for the bylaws to contain a provision that allows the TSCs board representative to veto any motion that is at odds with the Technical Community? Would it be possible for control of the brand and any copyrights to be held in such a way that if the TSC decided to leave the foundation they would remain in control of them. Requiring the Foundation to re-brand itself. Will the foundations bylaws be made public in the same way as the other draft documents for community feedback? |
|
I can't believe how bad this is looking for io.js. |
|
@mrseth care to explain your concern? |
|
@jasnell It restricts way too much the developers while offering nothing that io.js is lacking at the moment. People are promising funds, power, users but NONE of that made a difference for node.js. It doesnt matter how many money and users you have if you are being smothered by clueless C level executives like the node foundation is going to do. On the meanwhile 1.7 was just released, io.js keeps increasing the distance between it and node and shows no signs of slowing down. |
|
I agree with @mrseth. I also cannot fathom why is IBM given a board seat (don't tell me node-red or AIX)? Don't get me started on their release cycles. IO.js track record is impeccable. Versions are flying out, V8 is finally caught up with, new language features are here, working groups turned out to be so successful, that they are becoming a new model for large-scale modular software development ("one thing and one thing well"), @rvagg's "give ownership"-style package management is spreading, ... Given all that, IMHO, in order to buy into foundation the model would have stay exactly the same as it is (at IO.js). The board would have to be under TC, not the other way around, with only one goal: to serve and support TC. I don't care what those bodies are called or what Linux foundation's rules say, this is how it's supposed to be. Reconciliation terms are upside down. @mikeal, in my eyes you are the primary reason for IO.js success and the whole community has faith in you. Please don't let these corporate-style paperwork-bullying make you ease up on your principles. Don't back off one bit from the original requirements for going into foundation. Also, the way @tjfontaine is downplaying IO.js made me a bit uncomfortable. Like "We were going to do the foundation thing anyway". |
|
I'm working to ensure that the progress we've made in io.js is preserved in the Node.js Foundation were we to decide to move there. There's a lot of documents that define the policies for the foundation and for io.js so I've been working on a better summary that diffs the proposed policies of the foundation with those of io.js. As it stands I can't find a difference between them that is objectionable. In fact, this whole process has lead to a lot of existing io.js' practices being documented and more well defined. We've wanted a foundation and have been actively pursuing it for a year. In fact, we advocate for a foundation structure this way and bootstrapped with the help of the Linux Foundation. It exists now, and it has the node.js IP in it. Now what we need is the policies, practices and governance that allow us to run io.js successfully and, so far, that's what we've been getting. |
|
@mbonaci and @mrseth ... I'm not going to bother attempting to change either of your minds here... but, I would just point out that the IBM SDK for Node.js is simply IBM's straight port of Node.js onto Z and Power systems with a very small amount of additional debugging mechanism bolted in. It's currently on v0.10.38 (http://www.ibm.com/developerworks/web/nodesdk/). Our team has been working with V8 first to ensure that V8 will run on System Z and ppc systems. We use it directly within our BlueMix environment which is, of course, based on the OpenSource CloudFoundry and OpenStack projects. Perhaps a more productive question for the two of you (and others) would be: do you see anything particularly troubling in the draft documents themselves? Specifically, things that would be actively harmful or disruptive to the node.js/io.js community as a whole. So far the drafts have been reviewed by members of both project TC's but community review is absolutely helpful. |
|
|
||
| The TSC members shall consist of Maintainers from Core Projects as defined in the project lifecycle document and Section 7. | ||
|
|
||
| The TSC shall meet regularly using tools that enable participation by the community (e.g. weekly on a Google Hangout On Air, or through any other appropriate means selected by the TSC). The meeting shall be directed by the TSC Chairperson. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings. |
There was a problem hiding this comment.
I strongly approve of the openness being enforced here.
|
As long as the foundation's board has legal responsibility for the project, it has to be the final authority. That's just the way the legalities work. It's not feasible for the board to be legally responsible for something it has no authority over (i.e. the TSC). You could argue against the whole idea of a foundation, but I think that has been pretty well hashed out. I agree that strong community representation on the board is a good idea for many reasons, including counterbalancing specific corporate interests, and discussion on how exactly to ensure that needs to move forward. |
|
A recurring argument that I read is that io.js would be benefited, despite the compromises, by a reconciliation. |
|
@mrseth Your position seems rather clear; you feel the compromises being made are to the detriment of io.js, and see no value in the proposed benefits. Is that an accurate summary? While I personally disagree with your arguments against the benefits (your proposing the sisyphean task of changing a prevailing corporate culture; one I've never seen changed at any of the organizations I've worked for, despite numerous attempts to do so) that argument is actually besides the point. I'm more interested in engaging you on the position I summarized above. Can you elaborate more on what you feel the negative compromises are, and how they harm io.js? Please, be as specific as possible. A general "have it's wings clipped" won't help drive changes to the proposal; can you break out your concerns into a point by point list? (Even better if you have suggestions for how to improve or change those!) I'd love to understand your concerns more in depth. |
|
@Morgul I onced asked for a point by point list
I think that foundation proponents should bear that question, not the other way around. Then, and only if we're happy with that answer, should we ask "What do we lose by joining?". So, with good faith, let me start:
@mrseth as per the second bullet: I know, you're right, but this is the world we're living in. Anyone care to add a bullet or two? EDIT (2015-04-25): |
|
One of the best ideas to ever come out of the Node.js community was to aim for, and stop at, a tiny STDLIB. You might say recognize the compact, unique revolution that Github + npm + OSS + Javascript represents and stop creating new features ad nauseam. Does this foundation aim for a similar goal? I anticipate forking the new Node.js (again) whenever this boss becomes the same as the old boss. |
|
@sandro-pasquali this is addressed in the Development Policy https://github.com/jasnell/dev-policy#guiding-principles
|
This is Mike Dolan and Scott Nicholas from The Linux Foundation and we've been working with Bert Belder, James Snell, Mikeal Rogers and TJ Fontaine to create an initial draft of Node.js Foundation's technical governance documents. We used our standard Linux Foundation governance templates for foundations we've setup and inserted the io.js governance terms. The io.js governance terms were a good starting point to begin a discussion for moving forward. All members of the Node.js and io.js community and the advisory board are welcome and encouraged to post comments, questions and suggestions here. Our goal is to collaboratively develop a technical governance model that works to bridge the communities today and also set up a framework that will help guide future members of the community decades from now.
There are governance topics and details we often address in our projects that were not explicitly covered in any existing Node.js or io.js governance materials. Examples include whether/how to incubate new projects, connecting the technical committee with the Foundation's Board, and a few other areas you're likely to notice as you read through the materials I've posted. You may also notice gaps or details that have been addressed, but which are not reflected in our documents. We often set up a structure to capture the elements that a Board would approve in the formation and allow the TSC to determine the operational and logistic details through a development process that would be documented for the technical community. This is a long way of saying the technical documents I've shared are the essential elements to address to setup a TSC under a Foundation and leave details best determined by a TSC to the TSC.
There are three key documents that are used to build our typical technical governance framework.
A. TSC Charter.
The TSC Charter (which the Board approves) establishes a Technical Steering Committee under the Foundation. This is a formal document approved by the Board to set up the TSC and make it an official committee. The TSC will also be addressed in the Bylaws for the Foundation but at a very high level. This allows the TSC to be updated later without the scrutiny required of a change in the organization's Bylaws. The Charter sets up the committee, identifies who is eligible to participate in the committee and sets a framework for what the committee should do and how it will govern itself. The operational details and logistics are left to the TSC to determine in a development process.
B. TSC Policy
The TSC Policy (which the Board approves) sets the scope of the TSC and sets principles that the TSC should adhere to or abide by in the technical collaboration effort. This includes high level principles the community will be expected to adhere to and follow. The Policy is important to capture the high level principles, but should not be too detailed and become a burden or micro-manage how the TSC collaborates.
C. Project Lifecycle
This is perhaps a new concept as it relates to Node.js or io.js governance though it seems a few members of the community have been thinking about models for how projects enter a Foundation, mature and eventually become part of the core Node.js release. There may also be additional projects that will wish to participate under the Foundation. You'll see our project lifecycle terms enter the TSC Charter and TSC Policy documents in various sections to segment how projects of various maturity are treated and to differentiate between core subsystems/modules and other projects that may wish to participate under the foundation. A critical goal of the Project Lifecycle is to establish a mechanism to encourage new, innovative projects that need time to incubate and prove their value while establishing a roadmap and path for those projects to mature within the Foundation and within the release process of the project. It also attempts to create a home for additional related libraries, modules, etc that are looking for a “home” for their project.
As I mentioned above, the documents being committed are a starting point for the discussion and we encourage everyone interested in this subject to contribute your thoughts and suggestions for how we could improve them. If you like them as-is and would like to just voice general support for the direction they are going in, a +1 would be encouraged as well so we can gauge whether members of the community like the approach.