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.

Sign up for GitHub

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

Jump to bottom

Flatten project, scope TSC, big changes to structure. #59

Closed
wants to merge 3 commits into from
Closed

Flatten project, scope TSC, big changes to structure. #59

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e7151c3
Initial draft.
mikeal Mar 8, 2016
27f4138
Fixing typos and format.
mikeal Mar 8, 2016
ff6ac5c
Reducing number of WGs and projects and reducing process for teams.
mikeal Mar 15, 2016
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
85 changes: 41 additions & 44 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,62 +1,59 @@
# The Node.js Foundation TSC

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.
This is the primary communication and governance hub of the Node.js
Foundation's Technical Steering Committee. Its goals are:

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.
* Maintaining, releasing and improving a healthy Node.js Core project.
* Fostering and encouraging a healthy Node.js open source ecosystem.
Copy link
Contributor

Choose a reason for hiding this comment

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

healthy is out of place. Consider rewording.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you saying that healthy is out of place in both line 6 and 7, or just one of the lines? Can you explain why healthy is out of place? I think it's a good addition myself, especially on line 7, but I'd like to hear your reasoning.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ugh. I hate to dive in to such a nit-pick, sorry in advance to everyone....

Line 6 is the one that is a bit off. Adding health makes it the subject of the actions (which I believe is correct & important). You can maintain and improve health- but not release it. I believe release is intended to have Node.js Core (code) as the subject- which obviously you can release code. Careful guidance & oversight of the releases of Node.js Core releases will maintain and improve it. I'm sure everyone will 'get the idea' and probably just read past- so that's why I just said "consider rewording."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ya, this can be worded better.

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense, thanks @williamkapke, and yeah I agree now it should be reworded too.

Copy link
Member

Choose a reason for hiding this comment

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

My original wording for that point was simply "* Maintaining the health of the core Node.js project."


If your project is interested in joining the Node.js Foundation please read the [Project Lifecycle.md](./Project-Lifecycle.md) documentation.
# TSC
Copy link
Contributor

Choose a reason for hiding this comment

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

There is already a # The Node.js Foundation TSC above... this could probably be left out.


## TSC Members
The TSC has many working groups and projects. Each group and project
has a connection to the development of Node.js Core but their work and
responsibilities often extend far beyond Core and potentially even Node.js.
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe just:

...extend far beyond Core and potentially even Node.js.


TSC members are responsible for top level technical community concerns. The role is
mostly administrative and is responsible for admitting new Top Level Projects, Top Level
Working Groups, and advocating for any needs in the technical side of the foundation to
the Node.js Foundation Board of Directors.
The TSC also leads several efforts to improve the health and sustainability
of the ecosystem but it is not a long term host of ecosystem projects which are
not integrated into Core development.
Copy link
Contributor

Choose a reason for hiding this comment

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

... into Node.js Core development

or

... into Core's development

or..?

... into core development


TSC members can nominate new members at any time. Candidates for membership tend to be people
who have a competancy for community management and a high tolerance and patience for process
minutiae as the TSC delegates most of its responsibilities to other projects and working groups.
Each project and working group is autonomous. The scope of work and
autonomy is described in their charter. The TSC works to increase communication
and collaboration between all these parts.

Every Top Level Project not currently incubating can appoint someone to the TSC who they elect
at their own discretion.
Adding a new project or working group can be done through a pull request. Since
each group is autonomous any new group taking on responsibility from another
group would need that group's approval.

## Top-Level WGs and TLPs
Any project or working group can create teams at their discretion. Any org member
can create a new repo for organizing this kind of effort without a charter or other
process. Examples of Core teams are: Long Term Support, Cryto, Roadmap, Benchmark,
Streams, Testing.
Copy link
Contributor

Choose a reason for hiding this comment

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

needs some definite of what responsibility teams are allowed to take and when


* [Working Groups](WORKING_GROUPS.md)
* Mentors
## Projects
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the different between TLP and WG?


Project mentorship is not a technical role. In fact, mentors are
discouraged from giving technical advice 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.
* Core
* Website
* nan
Copy link
Member

Choose a reason for hiding this comment

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

NAN


* Mikeal Rogers (@mikeal)
* Top-Level Projects
* Core TLP
* Core WGs (streams, http, Intl)
## Working Groups

## Policy Change Proposal Process
* Inclusivity
Copy link
Member

Choose a reason for hiding this comment

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

It should be noted that the WG's below are chartered by the TC and not the TSC.

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'm proposing changing where they get chartered in the future so it would be confusing to separate them.

Copy link
Contributor

Choose a reason for hiding this comment

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

Will the other groups need to be rechartered and/or re-approved by the TSC, or will they be sort of "grandfathered" in? If it's the former, maybe we could denote with an asterisk here that they are pending rechartering?

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 don't see why they would need to be re-chartered unless we think their scope could be miss-interpreted as broader now that they are at a higher level. This would however need the approval of CTC.

Copy link
Contributor

Choose a reason for hiding this comment

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

I can think of a handful of reasons we might want to consider rechartering, including misinterpreting change of scope. Is this PR the best place to discuss that, or should we open a new issue and discuss there so we don't derail this PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good to me

Copy link
Member

Choose a reason for hiding this comment

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

hmmm... I'm not sure changing where those are chartered is a good thing. The core TC needs to be able to delegate responsibility on it's own independently of the TSC... unless you're suggesting flattening the TC and TSC back into one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the TC is delegating then the TC and TSC will approve the charter. See
the language regarding transfer of responsibilities. The point is that once
the TC delegates something to a subgroup the TSC will be following up to
make sure they communicate and document well, not the TC because we know
from experience they don't ;)

For a long time we basically relied on people who happened to be in all
these sub groups also being in the TC but that isn't scaling.

On Tuesday, March 8, 2016, James M Snell notifications@github.com wrote:

In README.md #59 (comment):

-## Policy Change Proposal Process
+* Inclusivity

hmmm... I'm not sure changing where those are chartered is a good thing.
The core TC needs to be able to delegate responsibility on it's own
independently of the TSC... unless you're suggesting flattening the TC and
TSC back into one?

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

Copy link
Member

Choose a reason for hiding this comment

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

Still not convinced. The TC for core ought to be able to spin out it's own WG's to focus on core stuff in a manner that is entirely independent of what is happening on the TSC side.

Just carrying this through a bit... would you imagine that any WG's spun up by the Express TC would also fall under the TSC using this plan? So hypothetically if we ended up with separate "Core LTS" and "Express LTS" WG's those would both exist under the TSC? Or is there something else that you had in mind that I'm just not groking from this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Express is a special snowflake because it's in the mentorship program with the goal of being its own fully contained project in the future, potentially hosted outside the TSC, so no this doesn't hold for Express.

You make a good point though that a subgroup should be allowed to delegate of its own will without approval from the TSC. My only thought was the the TSC would be responsible for keeping communication clear, so having a hand in making sure a charter is well defined would be important to them, but I don't see a need for the TSC to agree to every charter, just that they will probably want to be aware and possibly involved in the creation of any charters.

With regard to LTS needing to be under a TC, I'm not sure that entirely holds true. The LTS WG is actually still unchartered, it technically has no authority, but the TC defers to it often. The LTS WG also doesn't define its own release team, that's all integrated into Core, the WG is actually similar to the Streams WG in that it does work but the final decision about that work being merged/released falls under the control of the CTC -- it just so happens that LTS WG members are committers and CTC members so this is all very well integrated, but the CTC actually haven't officially delegated the committing and releasing to that WG.

* Build
* i18n
* Evangelism
* Documentation

The Node.js TSC is chartered to oversee the technical governance of all Top
Level Projects and Working Groups under the Node.js Foundation. The TSC
establishes the default governance, conduct, and licensing policies for all Top
Level Projects. Top Level Projects and Working Groups have broad powers of
self-governance.
## Mentorship Program

To propose a change or addition to policies or processes that are intended to
cover all Top Level Projects and Working Groups in the foundation, a PR should
be opened in the `nodejs/TSC` repository.
The TSC administers a mentorship program for critical projects in the ecosystem.
Projects are assigned mentors from the TSC to adapt modern best practices to the
specific needs of each project.

The pull request can be labeled `tsc-agenda` to request that it be put on the
agenda for the next TSC meeting.
* libuv
* Express

The Node.js Foundation Board of Directors retains certain rights (especially
legal considerations). If the TSC endorses a proposal, they will escalate to the
Node.js Foundation Board of Directors when required to do so.
## TSC Members

In some cases, existing individual groups have the right to refuse changes to
their charters. The TSC can not mandate existing working groups alter their
charters. If such a situation arises, the TSC may decide to revoke the group's
charter.
TSC members are responsible for administration and communitication. The role is
Copy link
Member

Choose a reason for hiding this comment

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

s/communitication/communication

mostly administrative and is responsible for admitting new projects, working groups
and representing them to Node.js Foundation Board of Directors.
Copy link
Contributor

Choose a reason for hiding this comment

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

Would/should a current list go here? This is what I would expect/hope to find here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should figure out any alterations before this is merged.

Copy link
Contributor

Choose a reason for hiding this comment

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

two spaces between to and Node.js