Add initial TLP application for express #39
Conversation
| ### Organizational Tools | ||
|
|
||
| * Current source code management: [GitHub](https://github.com/strongloop/express) | ||
| * Issue tracking: [GitHub](https://github.com/stringloop/express/issues) |
There was a problem hiding this comment.
"stringloop" sounds like something that could be an example reminder app made with Express.
| ### Important Documents | ||
|
|
||
| * Code of Conduct: the existing Node.js Code of Conduct would apply. | ||
| * DCO: the existing Node.js DCO would apply. |
There was a problem hiding this comment.
what does DCO mean in this instance?
There was a problem hiding this comment.
Developer's Certificate of Origin - https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#developers-certificate-of-origin-10
There was a problem hiding this comment.
That makes sense. Should that be explicitly linked in the document?
There was a problem hiding this comment.
Yeah, I'll add it
... done!
|
Never heard of it. |
|
Since the expressjs.com website is the only source of documentation, it should be included in the foundation with this project. For example, how can a working group effectively release new features and changes without being over the only documentation for Express? |
| * Issue tracking: [GitHub](https://github.com/strongloop/express/issues) | ||
| * Releases: [GitHub](https://github.com/strongloop/express/releases) and [npm](https://npmjs.org/package/express) | ||
|
|
||
| ### Intellectual Property and Other Assets |
There was a problem hiding this comment.
What is the plan to complete this section?
There was a problem hiding this comment.
We have to identify what assets (if any) would need to transfer and what process is necessary. I'll be filling these details in but I don't have all the details yet.
There was a problem hiding this comment.
The expressjs.com domain name seems like a very critical asset to transfer, as it points to the only source of documentation, and is the main result in Google.
There was a problem hiding this comment.
Yes. I agree that the domain is very important here.
Express is extremely broad, and there are likely at least thousands of documents that link to that website.
It has been a large part of the express community for some time and represents the almost the entirety of express's documentation efforts.
(Edit: Beyond that, express has no IP I know of aside from the license, which is already MIT.)
There was a problem hiding this comment.
Also, I suppose "other assets" also includes the #expressjs IRC channel of freenode and the expressjs mailing list of Google Groups, both of which have various activity from new-to-Node.js users. This is in addition to the web site, which is one of the first places new users go and should absolutely be held in the Node.js foundation trust. strongloop/expressjs.com is the backing repository, which should be included in the move as well.
There was a problem hiding this comment.
Isn't #express the "official" channel? I already hold founder rights there so I think that is covered.
There was a problem hiding this comment.
As I said, I don't have all of the details on everything that would need to transfer over yet so I'm waiting to fill those details in once I do. It won't be today tho.
There was a problem hiding this comment.
Is there a trademark of any kind?
It's important to flush out in the application all the current assets, including any domain names, because it allows us to gauge how much legal work there might to get the assets transferred or licensed.
That said, projects enter the incubator before they have "passed IP" which means the IP is vetted and the legal work around assets is finished while incubating. One of the reasons we incubate projects is so that the foundation has plenty of time to do all that work and so that there is an open governance body to work with on it if there were any issues during the process.
|
In my view, it would be fine to move (or copy) the API docs into the express repo while everything else is being figured out. N.B. they are in English only (except for community translation into Portuguese). |
|
I fully support this move. It is the right thing for the express community, it's users, and maintainers. Express is a key toolkit for building web applications with node. In fact, most people think of it as part of the core ecosystem. I am not worried about any perceptions from the foundation hosting the project. The node framework space is pretty big and mature. Even if people take this as some kind of endorsement by the foundation, it is not really going to make anyone choose express over any other option for that alone. For the most part, most people have no clue who leads or maintains their modules. One thing to note when staffing this project is that Express has played a larger role than just a framework in the node community. It has a semi-monopoly on on-boarding new node users. New developers use Express far more than any other framework (and more than experienced node developers). It is crucial to make sure these newcomers continue to have a place to go to. |
|
/cc @jasisk |
|
Should we link to some page explaining what TC, TSC, WG and stuff like that are? |
|
@thefourtheye ... yeah, likely a good idea. I could also update the doc to avoid the use of the acronyms |
|
|
||
| ### Contribution and Governance Process | ||
|
|
||
| The contribution process would be the same lazy consensus model used by Node.js |
There was a problem hiding this comment.
lazy consensus model used by Node.js core.
Is there a link to define this process?
There was a problem hiding this comment.
A more accurate definition is "lazy consensus seeking model."
It basically works like this:
- All contributions go through review and try to move towards the obvious consensus.
- The default is for things to land given that nobody objects. There's no need for a vote or formal process around getting +1's for every change, you propose the change, make any changes you need to in the review process, and land the change if nobody is against it.
- When consensus can't be reached easily it escalates to a more formal process for discussion (usually a weekly call). This is commonly less than 5% of all contributions, most just get reviewed and land.
- If a consensus can't be reached then a vote is taken, majority wins. In reality, the fact that a vote could happen is enough incentive to work towards a consensus and for people to drop objections they have that don't have wider support. Node.js Core has never had to bring an issue to a formal vote but the fact that a vote is a possibility keeps anyone from holding up the process with their own objection without trying to widen their support to other contributors. In a "pure consensus" model that's a huge problem, everyone essentially has a veto and aren't incentivized to try and convince their peers, so we avoid that with a "consensus seeking" system.
|
(posting in comments so it doesn't get lost inline after edits)
https://github.com/nodejs/node/blob/master/GOVERNANCE.md But I think we could reflect actual practice better. The most important part of this is that core is consensus seeking above all. There's almost never a need to call a formal vote and count for majority as:
This can all make some decisions drawn out and often it doesn't look like a decision is even going to be taken. But this only happens in the case of contentious changes, and seeking to find compromise and middle-ground is generally the best way to deal with those anyway. Also, it's often the case that no action is actually the best course of action so this ends up the default where there is no clear agreement and nobody wants to push for a binding vote. A lot of this process is shaped by the individuals involved but it's also something that we have built a culture around so onboarding, both as a collaborator and as CTC member is about coming in to that culture. The incubator process would primarily be focused on trying to transfer, or transplant some of that culture in a way that works best for the project. |
Some stats, in downloads/month, top 150, from 2016-01-29. This is just informational: Edit: moved to a gist. |
|
@ChALkeR what's your point? |
|
@hueniverse, I was not trying to express anything — as I said, this is just informational. Also note that that was total download count/month, including the chained deps (that's what gives us 4.5kk). Another source of information (for explicit |
|
@ChALkeR how many downloads express has is completely irrelevant to this discussion. |
|
@hueniverse https://github.com/nodejs/TSC/pull/39/files#diff-61e0777d20b3b0e1ac5c9032f8ba3d58R12 I cited that when I replied, and provided some stats for the reference in a comment. I do not think that it was useless or completely irrelevant. |
|
I think moving express to the foundation is good for the node ecosystem. However, I am not sure this would solve its problem: lack of maintainers/contributors (no offense to the current team, they are awesome and delivered a great value). Developing and maintaining express is close to a full-time job for more than one people, and moving it to the foundation is not going to solve this. I would suggest that the express project is moved to its own org and adopt a node-like management before considering adopting it in the node foundation. The other issue is related to its dependencies and it might create some weird situation: the node foundation maintain express, and XYZ maintains a module that is used by express. I would prefer that the foundation adopts Express and most of its deps (also connect?), to give the future express TC all the means to improve express. Finally, I would really like express to be hosted under expressjs/express rather than nodejs/express, to keep it clear it is loosely related to core. Also, the expressjs org can be the umbrella of all the other dependencies. Plus, this org is already very crowded of repos, all tightly connected to core. |
FWIW, a TLP need not move to the nodejs org AFAIK. libuv also applied to be a TLP but it sits in its own organization. |
+1. It would be better, if express was in expressjs org |
|
While the projects under the expressjs github org and other repositories
|
|
@jasnell fair point. I was pointing out the best outcome from my point of view. Sorry for moving the discussion from the important stuff, these are details (but highly welcomed to be discussed later). Given that Express is not currently run on a model similar to core, how moving it into the Node Foundation umbrella can improve the current situation? Most of the changes can happen independently. IMHO what is missing from the proposal is why the Node.js Foundation is a good fit for Express? |
|
A key goal is to grow the base of contributors or at least make it easier The foundation is a good fit given that a) express is so important to the
|
|
@jasnell 👍! IMHO you should add that into the proposal, so it's on record. |
|
@mcollina .. yep, the likely next step on this is to get the "Express WG" proposal to be chartered by the TSC. It would essentially be just like any of the WG's here. I can write up an initial draft version of that using the nodejs/TSC templates. Assuming the TSC accepts the express proposal, I'll get the nodejs/express github team created and put out a call for participation to the the community. We can iterate on it from there! I'm excited to see the community support behind this! |
|
@mcollina ... I have opened a PR with the proposed WG governance (per the TSC guidelines) here: expressjs/express#2871 and have added a draft Express WG charter to this PR. Hopefully that provides the additional detail you were looking for :-) |
| * dougwilson/depd | ||
| * visionmedia/bytes.js | ||
| * crypto-utils/random-bytes | ||
| * crypto-utils/uid-safe |
There was a problem hiding this comment.
Still have questions about these and stream-utils -- besides I don't actually think we necessarily have the permission to propose these be moved in any authoritative way.
|
This was discussed at length in the TSC meeting today. There were no objections to merging once the last few comments have been addressed. The TSC assigned two mentors to work with project while incubating: @mikeal and @jasnell. We didn't assign @Fishrock123 as a mentor because he will likely end up being a member of the Express TC, but we're sure he'll continue to also be a good resource. The TSC would like the Express TC to pick someone not already on the TSC to represent them as an observer on TSC calls while they are incubating (once they graduate incubation they get a voting seat). |
|
@mikeal @nodejs/TSC ... application updated and squashed. PTAL |
|
LGTM |
| on the server. | ||
|
|
||
| Express has consistently been among the top packages installed via npm, with | ||
| nearly 4.5 million downloads in just the past month. |
There was a problem hiding this comment.
Suggestion: include the time of writing.
|
LGTM-ish. The section on intellectual property is still blank. |
|
Quick update on the IP section: currently there is no IP transfer indicated. The question over the expressjs.com domain name will need to be looked at again a bit later but it will not be included in this initial proposal. The express API documentation, however, will be contributed. That doesn't rule out the domain question completely, just doesn't include it in this initial step. |
|
|
||
| Many repositories in these organizations may be moved out or removed entirely | ||
| during incubation at the discretion of the Express TSC. Prior to graduating | ||
| from incubation a full list of repositories will need to be provided to the TSC. |
There was a problem hiding this comment.
TSC is appropriate here. Those repositories will be selected by the TC but need to be included in the charter that is reviewed by and approved by the TSC
There was a problem hiding this comment.
@jasnell oh, the live above isn't though
There was a problem hiding this comment.
ah! lol... completely overlooked that one. Ok, will fix before landing
|
LGTM minus nits |
|
@Fishrock123 @mikeal @bnoordhuis ... updated to address nits |
|
still LGTM. |
|
Barring any objections from @nodejs/tsc, I will land this tomorrow. |
|
LGTM with spelling nit. |
|
Updated to address nits. Landing now! |
Add initial TLP application for express
The express project is applying to become an incubating top level project.
/cc @nodejs/tsc @Fishrock123 @nodejs/collaborators