Can we effectively define a "project"

[mikeal]

This has been troubling me lately.

We've been creating scopes of work as individual "projects." For a few scopes this is simple and effective, but for many it's very inadequate.

Currently, we have 2 groups at the "top level."

• Node.js Core (managed by the CTC)
• Inclusivity Working Group

We then have two other projects that are in the Incubator and could come to the top level at some future point in time.

• Express
• libuv

The scope of the Inclusivity WG is pretty understandable. There's certainly work that they will take on in the future that they aren't doing yet but what would be in or out of that group is pretty easily understood. Similarly, libuv has very well defined scope and a single GitHub org.

Where things get tricky is Node.js Core and Express. Here's a quick breakdown

Node.js Core

• Single GitHub org w/ ~100 repos.
• 85 teams, about half of which are localization groups.
• Sub-projects which are depended on outside of Node.js Core like readable-stream.
• Several "Foundation Level" resources like the website, several micro-sites, help repo, and moderation are actually in the "Core Project."
• nan which does not ship with Core and is in-fact depended on solely by external projects.

The connection to "Node.js Core" is not always clear. While nan is considered "part of the platform" as it's our preferred native abstraction it is effectively independent.

Several resources in the core project are potentially scoped to the entire ecosystem and not just core. The Documentation WG is working on resources far beyond core and the website has a global event map, etc.

Express is similarly large in scope. It's 3 GitHub organizations worth of repositories, many of which are depended on by other web frameworks as well as Express.

We've been hesitant to change a lot of this structure because, well, it's working. But now that we're considering admitting other projects this complicates matters a bit. For instance, would a framework like Sails or Kraken get its own "project" or would it be put under Express?

As a thought experiment, imagine how these projects would fit into this structure:

• serial-port
• Nodebots
• npm
• request

Now think about the issue of representation to the TSC. If the TSC is made from reps from each project then the TSC ends up being a pretty poor representation of what is going on in the foundation because of the huge disparities in size and scope. It also means that there's no way to break some scope off a top level project into another top level project without it growing the size of the TSC -- which I think we all agree would become problematic.

From the beginning we've worked to guarantee autonomy for individual groups. This has helped to raise incentives for participation by letting contributors own their processes and governance, but another part of its success is that the groups get to have their own identity. If you have to say something like "serial-port would be a sub-group in the NodeBots project" it has an effect on the identity of that project.

In reality, we have a tangled web of autonomous projects that have complicated relationships and dependencies on each other and we're trying to shove them into a hierarchy under terminology that was established in an era when one project was almost always one repository and committer group.

I don't know what the solution here is, but I think it's going to involve unwinding some of the structure we have in place and better defining the relationships between units and coming up with an effective way for each unit to communicate what it's doing to the rest of the organization. Perhaps what we need to do is define what competencies exist in each group and give them a scope based not on some notion of a project but based on what their core competencies are.

[mikeal]

Closing in favor of #59 for further discussion.