Skip to content
Merged
Show file tree
Hide file tree
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions Applications/Core TLP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
## Introduction

Currently the Node.js Foundation directly oversees the development of the core platform and associated working groups. The addition of Top Level Projects will predictably increase the workload on the TSC and so it makes sense to transfer these responsibilities to a Top Level Project concerned solely with the development of the platform.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is going to become redundant as soon as this is adopted. Perhaps this belongs under "History" or "Context" or something


## History & Metrics

Created by Ryan Dahl, now the largest programming ecosystem in the world.

## Scope

The Core TLP will have sole responsibility and discretion over the node.js project in the following areas:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Node.js

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, @mikeal insists on node.js while the rest of us try hard to be consistent with Node.js!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original draft was written before we went "Universal Capitalization," fixing.


* Setting release dates
* Release quality standards
* Technical direction
* Governance process and practices.
* Contribution process and practices.
* Maintaining the list of additional Collaborators.
* Development process and any coding standards.
* Mediating technical conflicts between Collaborators and Working Groups.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is why we have collaboration WG, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the collaboration wg is there to share knowledge about how to best collaborate and to build tools that help us do so, the TC or WG responsible for each repo is ultimately the arbiter of conflicts. this line delegates that responsibility from the TSC (where it current resides because of the TSC Charter passed by the foundation's board of directors) to the Core TLD for the "node.js" project.

* Node.js build and CI infrastructure.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Some list items end with periods and some don't. Doesn't really matter either way but should probably be consistent.


## Governance

https://github.com/nodejs/node/blob/master/GOVERNANCE.md

## Contributions

https://github.com/nodejs/node/blob/master/CONTRIBUTING.md

## Tools

* GitHub `nodejs` org.
* Uberconference & Soundcloud
* Google Hangouts & Youtube
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the website and CI?


## IP

All relevant IP is already managed by the Node.js Foundation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"is already managed" suggests that this is about process rather than status, should it just be "is managed"


## TC Members
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TSC?

Edit: oh we call this as TC only. Fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, it was going to get way too confusing to call all the TLD governing bodies TSC :)


* **Ben Noordhuis** <[email protected]> ([@bnoordhuis](https://github.com/bnoordhuis))
* **Bert Belder** <[email protected]> ([@piscisaureus](https://github.com/piscisaureus))
* **Fedor Indutny** <[email protected]> ([@indutny](https://github.com/indutny))
* **Trevor Norris** <[email protected]> ([@trevnorris](https://github.com/trevnorris))
* **Chris Dickinson** <[email protected]> ([@chrisdickinson](https://github.com/chrisdickinson))
* **Rod Vagg** <[email protected]> ([@rvagg](https://github.com/rvagg))
* **Jeremiah Senkpiel** <[email protected]> ([@fishrock123](https://github.com/fishrock123))
* **Colin Ihrig** <[email protected]> ([@cjihrig](https://github.com/cjihrig))
* **Alexis Campailla** <[email protected]> ([@orangemocha](https://github.com/orangemocha))
* **Julien Gilli** <[email protected]> ([@misterdjules](https://github.com/misterdjules))
* **James M Snell** <[email protected]> ([@jasnell](https://github.com/jasnell))
* **Shigeki Ohtsu** <[email protected]> ([@shigeki](https://github.com/shigeki))
* **Brian White** <[email protected]> ([@mscdex](https://github.com/mscdex))

## Working Groups

* [Website](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#website)
* [Streams](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#streams)
* [Build](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#build)
* [Tracing](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#tracing)
* [Roadmap](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#roadmap)
* [Docker](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#docker)
* [Addon API](https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md#addon-api)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Intl is missing, but it's missing from the WORKING_GROUPS.md document. Oops.
  • i18n groups (named or unrenamed) aren't included.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i18n groups are much wider than core so the plan is to keep them as a top level WG. This makes it a bit easier to engage with them about localization and other opportunities related to other TLPs.

## Provisional

The membership is already well under the 1/4 representation limit and the project has been well established for quite a while. It should skip the incubation phase.
19 changes: 19 additions & 0 deletions Applications/Evangelism WG.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
## Introduction

## History & Metrics

## Scope

## Governance

## Contributions

## Tools

## IP

## TC Members

## Working Groups

## Provisional
26 changes: 26 additions & 0 deletions Applications/NodeConf Collective TLP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
## Introduction

## History & Metrics

## Scope

## Governance

## Contribution Process

## Tools

* GitHub `nodeconf` org.
* Uberconference & Soundcloud

## IP

* NodeConf Trademark, owned by TenConf LLC (@mikeal's LLC)

## TC Members

## Working Groups

## Requirements

* Link to DCO, LICENSE, and CoC.
19 changes: 19 additions & 0 deletions Applications/i18n WG.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
## Introduction
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe mention naming conventions - nodejs-<iso 639 language>[-<ISO 3066 TERRITORY CODE>] or something


## History & Metrics

## Scope

## Governance

## Contributions

## Tools

## IP

## TC Members

## Working Groups

## Provisional
94 changes: 94 additions & 0 deletions Project Lifecycle.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
# Node.js Foundation Project Lifecycle

## Project Definition

The Node.js Foundation hosts several "Top Level Projects." These projects are autonomous from each other and governed by their own TC (Technical Committee) and chartered by the Node.js Foundation TSC.

Projects are free to create "Working Groups" which are autonomous groups collaborating to fulfill a set of responsibilities. Working Groups are eventually chartered by the TC. The TSC also charters its own Working Groups.

```
TSC
|
|-- Project A TC (Chartered By TSC)
| |-- Working Group (Chartered By Project TC)
|
|-- Project B TC (Chartered By TSC)
| |-- Working Group (Chartered By Project TC)
|
|-- Working Group A (Chartered by TSC)
|-- Working Group B (Chartered by TSC)
```

Both TLPs and TSC WGs may elect a representative to the TSC. TLPs and WGs with *incubation* status are not granted voting privileges on the TSC.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how I feel about this. Maybe this should be like, variable somehow? "up to two"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you want two reps per project?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh shoot, we still have the old way of having TSC members too. Bleh, confusing. This is fine then I guess.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is a little confusing. We have a bootstrapping problem with the TSC anyway though, so it's probably good that we have some members already there. Essentially what will happen is that members who just want to be involved in core can resign from the TSC (they will instead just be members of the Core TLP TC) as they will be quite bored :) This document describes how we admit new members from new TLPs which at some point in the future will probably represent all membership on the TSC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it's appropriate for the Core TLP to have >1 rep written into the structure because by a process of attrition the logical state is to end up with only 1 yet Core is why we're doing this and I don't imagine that changing in the future even if this ends up looking something like Apache or Eclipse, which both have recognisable core projects that are fairly central to their activities.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rvagg we can always change this later, this is a living document. As it stands we'll have several reps from the Core TLP, if that changes we can design a fitting representation policy.


## Incubation

The purpose of incubation is to support and mentor projects entering the foundation. The goal is for projects to be:

* Participatory
* Transparent
* Effective

While certain processes are strongly recommended because of the TSC's experience the goal of incubation is not to enforce a specific set of processes but to ensure that the processes adopted and accepted by a project achieve these goals. Therefor, the requirements for graduating from incubation are based on metrics that demonstrate success in terms of these values. These metrics are:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Therefore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just read this whole thing about therefore vs therefor and I'm still confused as to which one we should use https://www.translegal.com/legal-english-lessons/therefore-vs-therefor

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely therefore in this case. Unless you are a lawyer or trying to imitate writing from the 1800s, you will probably never use therefor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never seen therefor before, my browser's spell-checker is even looking at me funny for having typed it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a localization issue, like color vs. colour :P


* TC is 5 members or greater.
* No more than 1/4 of the TC is affiliated with the same employer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may need an easing in of this like we did with the io.js TC. Perhaps 1/3rd until the TC is 8, at which point it becomes 1/4?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the scale for leaving incubation. When entering incubation it's expected that the project is not in-line with this. Do we want to alter this as a consideration for leaving incubation?

* Members of the TC live in at least 4 different timezones and representing no fewer than three countries.
* The decision making and release process is documented and publicly accessible.

A project may apply to graduate from incubation at any time by calling for a vote in the TSC.

While a project is incubating it is assigned at least 3 [mentors](https://github.com/nodejs/TSC/blob/master/README.md#mentors) who are responsible for working with the project to adopt policies and gain the health and contributorship it will need in order to graduate from incubation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link suggests mentors come from the TSC group? Is this appropriate? Perhaps we could be a little more lax on this and just allow the TSC to assign 3 mentors with no mention of what groups those 3 may belong to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, now I see this PR includes the readme, still seems strange to explicitly list them, how does that list get modified?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the whole purpose of the mentor list being separate from the TSC is so that it can be much larger than the TSC. I'll clean up the language to make this more explicit.


## Lifecycle

The Foundation shall encourage new Projects and innovation in the community. New Projects enter the Node.js Foundation through a [Proposal](#Proposal).

The project should be considered mature and have a history of releases before applying to enter the foundation.

## Top Level Project and Working Group Requirements

All TLPs and WGs are expected to operate in a transparent manor. Decisions must be made publicly through a documented public process managed by each TLP TC or WG.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a glass house? Or did you mean 'manner'?


All TLPs and WGs must use a participatory decision making process. All TLP TCs must ensure they are accurately representing the WGs in their TLP.

### Security

All projects in the foundation share the same base security policy. The foundation's security team triages issues sent to [email protected]. Top Level Projects, whether in the incubator or not, are expected to maintain a private security repository where the security team can bring project specific issues.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: inconsistent word wrap. also, other places.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"project-specific"


## Top Level Projects

All Top Level Project TCs must follow a [Consensus Seeking](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) process and are responsible for documenting and keeping up to date their current processes and practices.

Each TLP TC must elect a representative to the Node.js Foundation TSC or vote to abstain from representation on the TSC.

## Applying to join

A proposal to join the Node.js Foundation as a Top Level Project or Working Group must include:

* Introduction and project description.
* Project history.
* Any available metrics or even estimates about the user base, ecosystem and community.
* Project scope.
* Current governance process.
* Current contribution process.
* List of current tools in use by the project (forums, issue trackers, GitHub orgs, etc).
* Existing IP Policy and relevant intellectual property (trademarks, domain names, etc).
* List of initial TC members.
* List of initial Working Groups.
* Prior to being admitted the project:
* Must include [DCO](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#developers-certificate-of-origin-10).
* Must include approved license (MIT, Apache2, etc).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vague, do we need the foundation legal committee to come up with a list? perhaps we can enumerate the basic ones and say "licenses beyond this list must be approved by the TSC" (or foundation legal committee?)

* Must include a [Code of Conduct](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#code-of-conduct).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think all existing projects have a CoC so it's arguably something of a double standard to require new projects to have one. That maybe applies to the DCO as well, not sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what context do you mean “all existing projects?”

Do you mean all within the foundation or all projects that we’d consider for the incubator?

The intention here is to require that they add it before being admitted, pretty much exactly the same expectation we have with the DCO.

-Mikeal

On Oct 14, 2015, at 1:55PM, Ben Noordhuis [email protected] wrote:

all existing projects

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Existing foundation projects, like nan and node-gyp. Neither has a CoC or DCO as far as I'm aware.

EDIT: Correction: nan has a DCO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PRs sent to nan and node-gyp. We need to be more careful about this in the future.

On Oct 14, 2015, at 2:06PM, Ben Noordhuis [email protected] wrote:

In Project Lifecycle.md #2 (comment):

+A proposal to join the Node.js Foundation as a Top Level Project or Working Group must include:
+
+* Introduction and project description.
+* Project history.
+* Any available metrics or even estimates about the user base, ecosystem and community.
+* Project scope.
+* Current governance process.
+* Current contribution process.
+* List of current tools in use by the project (forums, issue trackers, GitHub orgs, etc).
+* Existing IP Policy and relevant intellectual property (trademarks, domain names, etc).
+* List of initial TC members.
+* List of initial Working Groups.
+* Prior to being admitted the project:

  • * Must include DCO.
  • * Must include approved license (MIT, Apache2, etc).
  • * Must include a Code of Conduct.
    Existing foundation projects, like nan and node-gyp. Neither has a CoC or a DCO as far as I'm aware.


Reply to this email directly or view it on GitHub https://github.com/nodejs/TSC/pull/2/files#r42053137.


Each proposal should be sent as a pull request to this repository in the Applications directory. Proposals do not have to be complete to be submitted, the TSC can work with the authors and their respective communities in each Pull Request.

### Approved Licenses

At this time the foundation is only accepting projects which use an MIT, BSD, ISC or Apache2 license.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

derp, just saw this, above mention of approved license should say "see below" instead of enumerating a partial list.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, which BSD License? there's a whole family of them ..


### Admittance

The Node.js Foundation is quite new and currently has a limited number of resources available to mentor new projects. As such, projects are chosen for admission in groups as mentors become available.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"has limited resources"


You can apply at any time and the TSC and available mentors will help improve your application while awaiting the next available approval phase.
18 changes: 17 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,5 +2,21 @@

The Node.js Foundation Technical Steering Committee is the technical governing body of the Node.js Foundation. It admits and oversees all Top Level Projects in the Node.js Foundation. It also elects a representative to the Node.js Foundation Board of Directors.

For more information read the [TSC Charter](https://github.com/nodejs/TSC/blob/master/TSC-Charter.md).
For more details read the [TSC Charter](https://github.com/nodejs/TSC/blob/master/TSC-Charter.md) adopted by the Node.js Foundation Board of Directors on June 17th 2015.

If your project is interested in joining the Node.js Foundation please read the [Project Lifecyle.md](./Project Lifecycle.md) documentation.

## TSC Members

## Top Level WG and TLPs

* Working Groups
* Mentors
* Top Level Projects
* Core TLP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent error? Or are "Mentors" and "Core TLP" subcategories?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The “Core TLP” is pretty much the whole “project” as it stands today, so it is its own category and will have its own WGs. I’m sending a small change to make that clearer.

On Oct 14, 2015, at 1:57PM, Ben Noordhuis [email protected] wrote:

In README.md #2 (comment):

+If your project is interested in joining the Node.js Foundation please read the [Project Lifecyle.md](./Project Lifecycle.md) documentation.
+
+## TSC Members
+
+## Top Level WG and TLPs
+
+* Working Groups

  • * Mentors
    +* Top Level Projects
  • * Core TLP
    Indent error? Or is "Core TLP" a subcategory?


Reply to this email directly or view it on GitHub https://github.com/nodejs/TSC/pull/2/files#r42051998.


## Mentors

Project mentorship is not a technical role. In fact, mentors are discouraged from giving technical advise to projects. Instead, the purpose of mentorship is to encourage and improve a projects ability to be participatory, transparent, and effective. Mentors are there to help projects adopt and iterate on policies and processes that achieve these goals and eventually allow them to graduate the incubation phase.

* Mikeal Rogers (@mikeal)