Collaboration and Contribution Process Review #864
Comments
|
I think we're overdue to move whatever is of value in |
|
It's going to be easiest to start with a list of issues that may need to be addressed, otherwise it's going to be way too open ended. |
|
@bnb would you like to faciltiate this? I think having an approach from outside the folks with Node.js commit access would be very interesting. |
|
(also collaborators who would contribute more often, if not for the process. 🙂) |
|
@mcollina sure. Is this something you'd want me to do inside of the TSC repo, inside of the Admin repo, or somewhere else? (I am also OOO this week so may be slow to respond, just wanted to check on this to see if I was blocking at all) |
|
I think opening issues here is ok. Having a fresh perspective on https://github.com/nodejs/node/blob/master/CONTRIBUTING.md and how we could simplify things. |
Since most of us who are frequent contributors to the project also never look at that file, it's possible there's some pretty low-hanging fruit in there. My immediate suggestions:
|
Building on the discussion that has been started in #864, I'd like to propose that we take a queue from other significant open source projects and conduct our own Contributor Survey -- with the intent of helping us to determine where we can continue to make improvements to our contribution process. Using the 2019 Kubernetes Contributor Survey as an initial starting point, I've put together an initial set of questions that can allow us to start structuring something. This is a draft. The intent here is to build / refine the list of questions we'd like to see on a survey should we decide to do one. Please do not yet merge this PR. It is still a work in progress
Building on the discussion that has been started in #864, I'd like to propose that we take a queue from other significant open source projects and conduct our own Contributor Survey -- with the intent of helping us to determine where we can continue to make improvements to our contribution process. Using the 2019 Kubernetes Contributor Survey as an initial starting point, I've put together an initial set of questions that can allow us to start structuring something.
|
@bnb are you still planning to move this forward ? |
|
@mhdawson good timing on this question 😅 I'd completely not remembers that I created it nor that I committed to it. After next week I'm planning on pretty aggressively focusing on open-source work for a bit, and I can prioritize this in that time. |
|
That's something I've been thinking a lot about lately (especially in the context of https://github.com/nodejs/node/blob/master/CONTRIBUTING.md), and I'm eager to bounce off ideas with anyone who's also interested in this conversation :D |
|
@bnb @mmarchini great to hear :) |
|
@bnb, @mmarchini anything to report on this front? |
|
Haven't done anything on this front lately. |
Remove "How to Contribute in Issues". This is not Node.js-specific and is likely to cause many readers to tune out. If we want to include this kind of how-all-issue-trackers-are-intended-to-work information, let's link to an external source. But I think it's OK to simply remove it. Refs: nodejs/TSC#864 (comment) PR-URL: nodejs#36891 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This section isn't particularly useful in this context and contributes to making the document longer and less effective. This is part of a larger effort to make the contributing docs brief, informative, and friendly. Refs: nodejs/TSC#864 (comment) PR-URL: nodejs#36905 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Refs: nodejs/TSC#864 (comment) PR-URL: #36960 Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Remove "How to Contribute in Issues". This is not Node.js-specific and is likely to cause many readers to tune out. If we want to include this kind of how-all-issue-trackers-are-intended-to-work information, let's link to an external source. But I think it's OK to simply remove it. Refs: nodejs/TSC#864 (comment) PR-URL: #36891 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This section isn't particularly useful in this context and contributes to making the document longer and less effective. This is part of a larger effort to make the contributing docs brief, informative, and friendly. Refs: nodejs/TSC#864 (comment) PR-URL: #36905 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Refs: nodejs/TSC#864 (comment) PR-URL: #36960 Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
|
I've not gotten a chance to work on this. Perhaps taking a slightly different approach - would anyone be interested in sitting down and pairing on it? If not, that's fine ❤️ |
|
I wonder if it might fit into - nodejs/next-10#16. We could target one of the upcoming Next-10 meetings to discuss? That would be a slightly larger pairing :) |
Refs: nodejs/TSC#864 (comment) PR-URL: #36960 Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
This comment has been minimized.
This comment has been minimized.
Remove "How to Contribute in Issues". This is not Node.js-specific and is likely to cause many readers to tune out. If we want to include this kind of how-all-issue-trackers-are-intended-to-work information, let's link to an external source. But I think it's OK to simply remove it. Refs: nodejs/TSC#864 (comment) PR-URL: #36891 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This section isn't particularly useful in this context and contributes to making the document longer and less effective. This is part of a larger effort to make the contributing docs brief, informative, and friendly. Refs: nodejs/TSC#864 (comment) PR-URL: #36905 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Refs: nodejs/TSC#864 (comment) PR-URL: #36960 Reviewed-By: Daijiro Wachi <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
|
The last comment on this was more than a year ago, while it would be great to make progress that's not happened for quite some time. @bnb any objections to be closing this issue? |
|
I still think we should do this but happy to close. |
I briefly reached out to @mcollina about this who suggested I open an issue on the TSC repo:
I'm not sure if we've ever done a full review/reflective pass on our collaboration and contribution documents within the project (for example, the TSC Charter and Working Groups doc,).
It may perhaps be beneficial to collectively take a look at these processes (and any others!) and see both which parts may or may not be reflective of how we currently operate and which parts could be improved to allow us both as a project to work better and for the community to contribute effectively and meaningfully.
The text was updated successfully, but these errors were encountered: