governance: Add new Collaborators #234
Comments
|
For those on the list, here's the Collaborator Guide I'm proposing be pulled in so you can get an idea of what this is all about: https://github.com/rvagg/io.js/blob/contributing/COLLABORATOR_GUIDE.md plus the Governance structure: https://github.com/rvagg/io.js/blob/contributing/GOVERNANCE.md |
|
+1
With the way GitHub orgs work now we should just be able to add them and they can choose to accept the org membership or not, it doesn't force it on them like it used to. |
|
Just out of curiosity, where I can find the code style guidelines? |
|
@a0viedo They are mostly the Google style guides for C++ and JS with some minor extensions. |
|
Is there a place anywhere in our contributing guide that references the Google style guides? |
|
@mikeal I think I read that on joyent/node guidelines but not in iojs. Also, is there any specific reason for not including a |
|
@a0viedo the project is currently configured to use the closure linter (via |
|
Apropos the list of collaborators: LGTM. We could argue all day about what constitutes a meaningful contribution but I agree with @rvagg, it's better to be liberal. Maybe we can add some kind of inactivity counter (e.g. 3 months and you're off the list again) to give people an incentive to keep contributing. |
|
To expand on my comment from the TC meeting: I am strongly in favor of getting to a point where we can rapidly add many new collaborators at once. Part of that, though, is making sure that we're spinning up new collaborators effectively: making sure that they understand the culture of the project, and feel comfortable with the extents of their new responsibilities. I bring this up because it was actually a bit of an impediment to me when I first got the commit bit on joyent/node: it was hard to get to a point where I felt comfortable closing an issue (especially issues that core team members had commented on), because I didn't have a good sense of what the expectations were for my new role. Eventually I got over it and started closing issues / commenting / taking more ownership, but I distinctly remember thinking to myself beforehand: "Well, I suppose I'll find out if I'm not supposed to be doing this when they take away my commit bit!" I'd like to avoid that step for new collaborators, if possible. A good way to do that might be to have an existing collaborator volunteer to shepherd a new collaborator into the project -- for a week or two, be the point of contact for any question the new collaborator might have, and keep an eye on what they're doing in the repo to make sure they're comfortable making changes, reviewing, commenting, closing issues, etc. Note that this is less about "protecting the project" than it is about making sure that we're creating an environment that actively encourages people to take ownership of the project. I'd be happy to take this on for 1-2 folks, if we decide to go this route. As we get an idea of how much time this takes, we can start increasing the number of folks we shepherd in at a time; or, as the pool of collaborators expands, we can rely on them shouldering some of that effort. |
|
Don't make me a collaborator just yet. Let me take a deep dive into this, and get really familiar/comfortable with project goals, priorities and conventions. I won't be comfortable with closing issues and making feature decisions at this point. |
|
FWIW, I completely agree with what was said during the TC meeting. I wouldn’t mind being added as a collaborator if only for the Punycode-related stuff (and possibly documentation) but don’t expect me to do any work on the C++ parts of io.js. |
|
@bnoordhuis has nominated @Fishrock123 and @Qard for being helpful in support and issue responsiveness, we should also discuss how non-code contributions feed into the decision to add people. |
|
+1 for adding them. If someone were to be brought on in a "docs only" fashion, we could just give them a commit bit and immediately revert anything else that were committed. |
|
One of my dreams for "OPEN Open Source" is to have a github bot that could outlaw pushes to master (especially including force pushes) without pull request by immediately reverting them. That would be ideal here and we wouldn't even need to care about the reasons we give someone commit access the visibility on changes goes right up. Just putting that out there in case someone gets inspired by the idea because I've never had the time to actually implement this. |
|
I think one aspect that hasn't been expanded on just yet (@chrisdickinson brought it up) is how important tooling is to make you feel "comfortable" committing, reviewing or working with a project in general. The more tools io.js can provide in terms of telling collaborators they're making the correct decision (be it linters, test suites, spell checkers, commit text reviewers or whatnot), the friendlier the environment will feel. It's pretty common among os distributions/package managers to have tools that for instance ensures that the package you are modifying will work with the packages that depends on it; or if the requirements that package have (be it tooling for building or installing into correct paths) looks good. If those weren't in place, the process would be considerably slower and would still be open to human error. A pretty common option here among open source projects is introducing bots that aids with this. I think a level up from that would be providing the same input through these tools so a person can make choices based on them -- for instance, administrating open issues. |
|
Something I want to note while I think of it: perhaps we should schedule an onboarding hangout with new collaborators when they are added to talk through any concerns they have and reinforce the important parts of being a collaborator: git stuff, how to handle issues, how to take responsibility, etc. The hangout could be hosted by a couple of existing collaborators, @chrisdickinson comes to mind as someone good for this. I'd like to see a path that new collaborators feel enough ownership to start hacking in to the issues and pull requests to trim the list and take action where the action is straightforward. |
|
We should just give out commit bits on an as-needed basis. Instead of handing out commit bits, I think it's much more desirable to give influence to contributors, in the form of a vote. |
|
@rvagg I would be happy to help with something like this for new collaborators – this is pretty much precisely what I want. I can put together a rough outline of what I'd like to go over for new folk at an onboarding like this. |
|
You could turn off issues for iojs/io.js and redirect to iojs/bugs, iojs/feature-requests, etc. Then you don't need to care so much about commit access to the repo. |
|
You could also break the project up into sub modules then make io.js the On Monday, January 19, 2015, Stephen Belanger [email protected]
Samuel G. Tobia |
Absolutely; this is important. I would suggest even going so far as to turn off issues for iojs/io.js and only allow pull requests. |
|
I'm -1 on turning Issues off. People that are new to the project instinctively look for Issues here. Giving people commit bits in order to help with Issues is not dangerous. This is git, even if they are blatantly malicious we can easily recover. |
|
It's not the blatantly malicious I'd worry about: it's two things -- the well-intentioned but misguided; and the transition back to a single combined node/iojs repository. A different approach: put in place a policy of pruning committers (you can always get the bit back again, right?) |
That's an interesting idea. My experience with the |
|
raises hand for issues help |
|
I'd be interested although I've not yet committed any code to IO.js yet, I did for Node.js. |
|
@bnoordhuis Thanks for the nomination for the Collaborators. I'm very glad to work in io.js. |
|
@shigeki please respond via https://doodle.com/ehq3u887fdvd4sss |
|
@rvagg Thanks. I missed "Cannot make it" button. |
|
@shigeki Cool – assuming all goes well, there should be another fairly shortly afterwards for those who can't make Friday. |
|
OK! Tomorrow I'll run two groups, one at 11AM PST and one at 1PM PST. For the 11AM group: For the 1PM group: I'll plan on having 15-20 minutes of content. If you could send questions to chris at neversaw dot us beforehand, I'd be happy to answer them (and we'll have time to cover other questions as well). After this batch is done, I'll collect feedback and I'll start a doodle for next week. Thanks very much, everyone! |
|
I appreciate the offer, but I think for the moment I'd rather send more patches before becoming an official contributor to the project. I'm glad y'all found the contributions useful, though. |
|
I'm interested also, but it will not be regular. It will be now and then when I have some extra time. English is not my first language so I'm more a reader than a writer when it come to discussions, but I will probably contributes to some issues. From time to time I probably can contribute some code also. I'm watching the repo, but when the backlog is getting to big, I'll click the read all button. It is better to see some of the issues than none. Also, I can't make it to any of the times tomorrow. But since @chrisdickinson already have set the groups, I'm probably not getting in in this batch anyway. |
|
@chrisdickinson Cool. Looking forward to it! :) |
|
@chrisdickinson these will be on hangouts on air right? do you need to be added to the youtube channel? |
|
@mikeal These are not hangouts on air, just currently doing ad-hoc hangouts. I thought about doing them on-air, but wanted to lean towards privacy to encourage question-asking. I'm open to other opinions on that, though! Re: the youtube channel, I don't think I'm added, but I could be wrong. Will check after this upcoming onboarding. |
|
@rvagg I'm interested, but missed the first doodle in my flood of iojs email. Will there be another onboarding? |
|
@sam-github absolutely, I think @chrisdickinson will be scheduling another onboarding this week or maybe early next week. There will likely be some discussion about the process at the next TC to refine it but we certainly just want to make the path to adding extra collaborators smooth. |
|
OK! Sorry this took me so long, but the doodle for the 2nd round of onboarding is up! If you've been recommended by @iojs/tc, please respond. If you missed the first time and can't make it this time either, let me know and I can figure out another time for you. Thanks all! |
|
can't make it this time, as i am organizing http://day.couchdb.org/ - we On Fri, Jan 30, 2015 at 10:55 PM, Chris Dickinson [email protected]
|
|
overflowed to #680 |
Full release notes: A few meaty bugfixes, and introducing `peerDependenciesMeta`. FEATURES * [`a12341088`](npm/cli@a123410) [nodejs#224](npm/cli#224) Implements peerDependenciesMeta ([@arcanis](https://github.com/arcanis)) * [`2f3b79bba`](npm/cli@2f3b79b) [nodejs#234](npm/cli#234) add new forbidden 403 error code ([@claudiahdz](https://github.com/claudiahdz)) BUGFIXES * [`24acc9fc8`](npm/cli@24acc9f) and [`45772af0d`](npm/cli@45772af) [nodejs#217](npm/cli#217) [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863) [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,) do not descend into directory deps' child modules, fix shrinkwrap files that inappropriately list child nodes of symlink packages ([@isaacs](https://github.com/isaacs) and [@salomvary](https://github.com/salomvary)) * [`50cfe113d`](npm/cli@50cfe11) [nodejs#229](npm/cli#229) fixed typo in semver doc ([@gall0ws](https://github.com/gall0ws)) * [`e8fb2a1bd`](npm/cli@e8fb2a1) [nodejs#231](npm/cli#231) Fix spelling mistakes in CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR)) * [`769d2e057`](npm/cli@769d2e0) [npm/uid-number#7](npm/uid-number#7) Better error on invalid `--user`/`--group` configs. This addresses the issue when people fail to install binary packages on Docker and other environments where there is no 'nobody' user. ([@isaacs](https://github.com/isaacs)) * [`8b43c9624`](npm/cli@8b43c96) [nodejs#28987](nodejs#28987) [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032) [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658) [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069) [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2) Fix the regression where random config values in a .npmrc file are not passed to lifecycle scripts, breaking build processes which rely on them. ([@isaacs](https://github.com/isaacs)) * [`8b85eaa47`](npm/cli@8b85eaa) save files with inferred ownership rather than relying on `SUDO_UID` and `SUDO_GID`. ([@isaacs](https://github.com/isaacs)) * [`b7f6e5f02`](npm/cli@b7f6e5f) Infer ownership of shrinkwrap files ([@isaacs](https://github.com/isaacs)) * [`54b095d77`](npm/cli@54b095d) [nodejs#235](npm/cli#235) Add spec to dist-tag remove function ([@theberbie](https://github.com/theberbie)) DEPENDENCIES * [`dc8f9e52f`](npm/cli@dc8f9e5) `[email protected]`: Infer the ownership of all unpacked files in `node_modules`, so that we never have user-owned files in root-owned folders, or root-owned files in user-owned folders. ([@isaacs](https://github.com/isaacs)) * [`bb33940c3`](npm/cli@bb33940) `[email protected]`: * [`9c93ac3`](npm/cmd-shim@9c93ac3) [#2](npm/cmd-shim#2) [npm#3380](npm/npm#3380) Handle environment variables properly ([@basbossink](https://github.com/basbossink)) * [`2d277f8`](npm/cmd-shim@2d277f8) [nodejs#25](npm/cmd-shim#25) [nodejs#36](npm/cmd-shim#36) [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case by always providing `$basedir` in shell script ([@igorklopov](https://github.com/igorklopov)) * [`adaf20b`](npm/cmd-shim@adaf20b) [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an error when arguments contain parentheses ([@satazor](https://github.com/satazor)) * [`49f0c13`](npm/cmd-shim@49f0c13) [nodejs#30](npm/cmd-shim#30) Fix paths for MSYS/MINGW bash ([@dscho](https://github.com/dscho)) * [`51a8af3`](npm/cmd-shim@51a8af3) [nodejs#34](npm/cmd-shim#34) Add proper support for PowerShell ([@ExE-Boss](https://github.com/ExE-Boss)) * [`4c37e04`](npm/cmd-shim@4c37e04) [#10](npm/cmd-shim#10) Work around quoted batch file names ([@isaacs](https://github.com/isaacs)) * [`a4e279544`](npm/cli@a4e2795) `[email protected]` ([@isaacs](https://github.com/isaacs)): * fail properly if `uid-number` raises an error * [`7086a1809`](npm/cli@7086a18) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`8845141f9`](npm/cli@8845141) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`51c028215`](npm/cli@51c0282) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`534a5548c`](npm/cli@534a554) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`3038f2fd5`](npm/cli@3038f2f) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`a609a1648`](npm/cli@a609a16) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`f0346f754`](npm/cli@f0346f7) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`ca9c615c8`](npm/cli@ca9c615) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`b417affbf`](npm/cli@b417aff) `[email protected]` ([@isaacs](https://github.com/isaacs)) TESTS * [`b6df0913c`](npm/cli@b6df091) [nodejs#228](npm/cli#228) Proper handing of /usr/bin/node lifecycle-path test ([@olivr70](https://github.com/olivr70)) * [`aaf98e88c`](npm/cli@aaf98e8) `[email protected]` ([@isaacs](https://github.com/isaacs))
Full changelog: 6.11.1 (2019-08-20): Fix a regression for windows command shim syntax. * [`37db29647`](npm/cli@37db296) `[email protected]` ([@isaacs](https://github.com/isaacs)) v6.11.0 (2019-08-20): A few meaty bugfixes, and introducing `peerDependenciesMeta`. FEATURES * [`a12341088`](npm/cli@a123410) [nodejs#224](npm/cli#224) Implements peerDependenciesMeta ([@arcanis](https://github.com/arcanis)) * [`2f3b79bba`](npm/cli@2f3b79b) [nodejs#234](npm/cli#234) add new forbidden 403 error code ([@claudiahdz](https://github.com/claudiahdz)) BUGFIXES * [`24acc9fc8`](npm/cli@24acc9f) and [`45772af0d`](npm/cli@45772af) [nodejs#217](npm/cli#217) [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863) [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,) do not descend into directory deps' child modules, fix shrinkwrap files that inappropriately list child nodes of symlink packages ([@isaacs](https://github.com/isaacs) and [@salomvary](https://github.com/salomvary)) * [`50cfe113d`](npm/cli@50cfe11) [nodejs#229](npm/cli#229) fixed typo in semver doc ([@gall0ws](https://github.com/gall0ws)) * [`e8fb2a1bd`](npm/cli@e8fb2a1) [nodejs#231](npm/cli#231) Fix spelling mistakes in CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR)) * [`769d2e057`](npm/cli@769d2e0) [npm/uid-number#7](npm/uid-number#7) Better error on invalid `--user`/`--group` configs. This addresses the issue when people fail to install binary packages on Docker and other environments where there is no 'nobody' user. ([@isaacs](https://github.com/isaacs)) * [`8b43c9624`](npm/cli@8b43c96) [nodejs#28987](nodejs#28987) [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032) [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658) [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069) [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2) Fix the regression where random config values in a .npmrc file are not passed to lifecycle scripts, breaking build processes which rely on them. ([@isaacs](https://github.com/isaacs)) * [`8b85eaa47`](npm/cli@8b85eaa) save files with inferred ownership rather than relying on `SUDO_UID` and `SUDO_GID`. ([@isaacs](https://github.com/isaacs)) * [`b7f6e5f02`](npm/cli@b7f6e5f) Infer ownership of shrinkwrap files ([@isaacs](https://github.com/isaacs)) * [`54b095d77`](npm/cli@54b095d) [nodejs#235](npm/cli#235) Add spec to dist-tag remove function ([@theberbie](https://github.com/theberbie)) DEPENDENCIES * [`dc8f9e52f`](npm/cli@dc8f9e5) `[email protected]`: Infer the ownership of all unpacked files in `node_modules`, so that we never have user-owned files in root-owned folders, or root-owned files in user-owned folders. ([@isaacs](https://github.com/isaacs)) * [`bb33940c3`](npm/cli@bb33940) `[email protected]`: * [`9c93ac3`](npm/cmd-shim@9c93ac3) [#2](npm/cmd-shim#2) [npm#3380](npm/npm#3380) Handle environment variables properly ([@basbossink](https://github.com/basbossink)) * [`2d277f8`](npm/cmd-shim@2d277f8) [nodejs#25](npm/cmd-shim#25) [nodejs#36](npm/cmd-shim#36) [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case by always providing `$basedir` in shell script ([@igorklopov](https://github.com/igorklopov)) * [`adaf20b`](npm/cmd-shim@adaf20b) [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an error when arguments contain parentheses ([@satazor](https://github.com/satazor)) * [`49f0c13`](npm/cmd-shim@49f0c13) [nodejs#30](npm/cmd-shim#30) Fix paths for MSYS/MINGW bash ([@dscho](https://github.com/dscho)) * [`51a8af3`](npm/cmd-shim@51a8af3) [nodejs#34](npm/cmd-shim#34) Add proper support for PowerShell ([@ExE-Boss](https://github.com/ExE-Boss)) * [`4c37e04`](npm/cmd-shim@4c37e04) [#10](npm/cmd-shim#10) Work around quoted batch file names ([@isaacs](https://github.com/isaacs)) * [`a4e279544`](npm/cli@a4e2795) `[email protected]` ([@isaacs](https://github.com/isaacs)): * fail properly if `uid-number` raises an error * [`7086a1809`](npm/cli@7086a18) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`8845141f9`](npm/cli@8845141) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`51c028215`](npm/cli@51c0282) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`534a5548c`](npm/cli@534a554) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`3038f2fd5`](npm/cli@3038f2f) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`a609a1648`](npm/cli@a609a16) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`f0346f754`](npm/cli@f0346f7) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`ca9c615c8`](npm/cli@ca9c615) `[email protected]` ([@isaacs](https://github.com/isaacs)) * [`b417affbf`](npm/cli@b417aff) `[email protected]` ([@isaacs](https://github.com/isaacs)) TESTS * [`b6df0913c`](npm/cli@b6df091) [nodejs#228](npm/cli#228) Proper handing of /usr/bin/node lifecycle-path test ([@olivr70](https://github.com/olivr70)) * [`aaf98e88c`](npm/cli@aaf98e8) `[email protected]` ([@isaacs](https://github.com/isaacs))
and others
I was going to do this as a comment in #230 but it got out of hand so it's probably best as a separate issue.
As mentioned in #233, we need to be more rigorous about adding collaborators to the project. So far there's just the TC + @cjihrig + @mikeal + @rvagg in the core team(s) (plus some additionals that were invited for historical reasons but haven't participated yet) and then there's other teams like Website and Build that have additional people.
After reviewing the closed io.js pull requests (node-forward/node is gone so I don't know if there was anything useful in there re PRs), I've come up with a very subjective list. I've eliminated PRs that were not merged and some trivial ones, mainly additions to documentation that I wouldn't count as "significant".
To get the ball rolling, I've come up with a significance rating, a number from 1 to 5, and assigned it to each of the PRs below. These are my subjective ratings and relate to the impact of the PR in terms of amount of code and also significance of the change. This is a very tricky thing to do and I'm sure others would come up with different numbers. The only 1's I've included here are ones where the contributor has made multiple PRs, to take into account their compound contribution.
It's up to the TC to approve the addition of people so at this next meeting I'd like to put this on the agenda:
So I'd ask TC members to have a browse through this list and have a think about how you would approach this. My personal opinion is the more the merrier in most cases so there should be a liberal attitude towards adding people, just not for trivial changes.
Additionally, we'll need approval from each of the above individuals that they actually want to be added, you can do that here with a simple comment if you like or someone can chase you up afterwards.
The text was updated successfully, but these errors were encountered: