2020 Node.js Contributors Survey Results #882
Conversation
|
That was some interesting reading. Seems to me like there are a lot of mentions of the contribution & review process. I'm rather new to the organization so I wonder these results usually are used? i.e. do they lead directly to any actionable items and/or issues or are they used more as reference for ongoing and future discussions? EDIT: I found the answer #865 |
|
So … yup, this is definitely very interesting. What’s a good place to discuss the results? Here, in this PR? One thing that comes up quite a bit is being annoyed with C++, which is more than understandable. That was obviously my main motivation behind adding |
I've got around 14 years of experience with C++ from working on https://github.com/CasparCG/server (Windows). However, I have not touched C++ in NodeJS core at all. Not sure if/how I can be of help but if you need someone to experiment with in how to make the C++ parts more approachable I'd be happy to contribute. |
I think |
|
Regarding C++: I'm old enough that I grow up with C and later C++. During the last years I worked with quite some younger people - mostly fresh from university. They did great work JavaScript/Java/... and associated toolings but once I confronted them with tasks in C++ area there were lost. So I fear the issue is more the language C++ itself not how it is used by node. What I miss is some more description about the interworking between JS/C++ which are not that obvious. For example the various places where AliasedBuffer/... are used. It's not that easy to track down all cases where C++ influences JS as you can't just follow a call tree. |
|
Ultra-minor nit on formatting:
Seems like those two items should be only one:
|
|
@mmarchini ... I split those intentionally so the second point wouldn't get lost as it's an important point on it's own. |
|
Going to merge this but I don't want to discourage further discussion and review |
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
|
In the future, perhaps this could live in nodejs/admin ❤️ |
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
The [Contributor's Survey results](nodejs/TSC#882) highlight the fact that it is often not easy for contributors to know who the right people are to talk to about a proposed change or who to ask for reviews of a given subsystem. We briefly toyed around with codeowners before when GitHub introduced it but just as quickly disabled it because the structure of our repository made it exceedingly difficult to get right. Rather than start with a codeowners for the entire project, I propose that we start with a small experiment focused on specific subsystems. Specifically, codeowners for modules, streams, net/tls, http/http2, and quic (once that lands). We can expand out from there as we see how things go with the minimal starter set. Initially this just enables codeowners for the `quic` subsystem. A couple of points: 1. A codeowner should always be a team, never an individual person 2. Each codeowner team should contain at least one TSC member (to provide coverage for signing off on semver-major changes) 3. PRs touching any code with a codeowner must be signed off by at least one person on the codeowner team PR-URL: #33895 Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
As the [2020 Node.js Contributors Survey][] has shown, the waiting time for pull requests is a non-trivial obstacle to meaningfully contributing to Node.js. To reduce that friction, this PR: - Drops the 48-hour/7-day waiting times as strict rules. - Drops the `fast-track` label, which is now the implied default. - Adds a `wait-for-feedback` label that collaborators can add if they think that a pull request *should* remain open for at least 48 hours. - Reduces the strict requirement for merging something to 1 approval, and keep 2 approvals as a strong suggestion. - Allows immediate reverting of pull requests that have been fast-tracked, if deemed necessary. [2020 Node.js Contributors Survey]: nodejs/TSC#882 Refs: nodejs/TSC#882 Fixes: nodejs#33627
@nodejs/tsc @nodejs/collaborators ... the compiled results of the 2020 Contributor's Survey.