Collaborator nominations

[Trott]

Feel free to nominate yourself or anyone else as long as a reasonable case can be made that the nominee has made significant and valuable contributions.

Ultimate decisions about Collaborator nominations are made by the CTC.

Factors that get reviewed include (but are not limited to):

• commits
• open pull requests and issues
• comments on issues and pull requests
• participation in workgroups, IRC, and elsewhere in the project and the community

If we're missing valuable contributors because there are factors we're not considering, we certainly want to know about it! Leave a comment!

At this time, we have the following nominee:

• Yuta Hiroto (@abouthiroppy)

[gibfahn]

I'd nominate @vsemozhetbyt , who's been pretty active on the documentation side (both in commits and Issues). I had assumed he was a collaborator until #11110 (comment).

@vsemozhetbyt let me/us know if you'd be interested!

[vsemozhetbyt]

@gibfahn Thank you. I was asked about this some months ago, and I've refused. I was — and am — afraid to get any potentially harmful rights and to seem competent collaborator, because of lack of knowledge and experience (I've messed up PRs sometimes as my git skills are pretty primitive).

But I can see that I need every now and then to nudge other competent collaborators for landing my rather simple PRs, and this worries me. So I would like to step up my responsibility for overall simplification and time economy. However, I would try to use my rights with big caution. And I would be happy with any community's decision)

[gibfahn]

@vsemozhetbyt I think worrying about the damage you could accidentally do as a collaborator is a good thing, if you weren't worried at all that would scare me!

The thing to remember is that you can take it at your own pace. Being a collaborator doesn't mean you have to land all your own PRs and do arcane git incantations on release branches, to start with you can do exactly what you're doing now, but now if you review doc PRs, your word will carry more weight (reflecting your experience). Then over time you can get used to things like landing commits.

Landing commits is something that has become a lot easier with things like @evanlucas's node-review and core-validate-commit. It's mostly a question of following the guide carefully each time so you don't miss anything.

The only dangerous thing is that you could accidentally push to nodejs/node and overwrite some branches (which some very experienced people have done). It's nearly always recoverable, but there's quite a lot you can do to avoid it (see below).

Either way, it's entirely up to you! If you ever need help with anything feel free to reach out on Github or Twitter (@gibfahn), or ask any other collaborator.

How to avoid accidentally pushing to `nodejs/node` (click me)

Once you become a collaborator you get push access to nodejs/node. This can be an issue, because you want a read-only nodejs/node most of the time for hacking. If you use ssh to push to GitHub then this is doable.

You need to make sure you've forked nodejs/node (so you have a gibfahn/node, replacing gibfahn with your username). Then set up ssh if you haven't already, GitHub has a pretty good guide here.

First make sure you haven't told git to remember your github username and password for https access by cloning your repo with https and trying to push to it (all instructions should work on Linux/macOS using the git command line).

GITHUBUSER=gibfahn # Replace with your GitHub username
git clone https://github.com/$GITHUBUSER/node.git && cd node
echo "Test" >test.sh 
git add test.sh 
git commit -m "This should not get pushed"
git push origin master

You should get a username and password prompt. If not you must have told git to remember your password, so tell it not to (ssh is usually easier to use anyway).

Then set up a repo for hacking and a repo for landing PRs (feel free to change the folder structure):

Hacking repo:

cd
mkdir dev
cd dev  # This creates ~/dev, feel free to use somewhere else
git clone https://github.com/nodejs/node.git && cd node
git remote rename origin upstream # So upstream refers to nodejs/node
git remote add fork git@github.com:$GITHUBUSER/node.git # So fork refers to your fork
git fetch --all # Update everything

Landing PRs repo:

cd ~/dev # Wherever you'd like it to go
mkdir DANGER # So you know not to go in there!
git clone git@github.com:nodejs/node.git && cd node
git remote rename origin DANGER # This is the remote that writes to node
git remote add fork git@github.com:$GITHUBUSER/node.git # Useful for merging your own PRs
git fetch --all

So after this, if you clone nodejs/node, make sure to use https (https://github.com/nodejs/node.git) not ssh (git@github.com:nodejs/node.git). Then, if you accidentally try to push to nodejs/node you'll get a Username and password prompt, which should alert you to what you're doing. If you're in the DANGER directory you should already know to be careful (and you only need to be in there for merging PRs).

The last thing I'd recommend is using a git alias to use --force-with-lease instead of --force for force pushing. You should (hopefully) never need to force push to nodejs/node, but in any case, --force-with-lease is just safer.

You can add an alias with git config --global alias.pf=push --force-with-lease, and then git pf will do git push --force-with-lease.

[jasnell]

I'd like to nominate @watilde for the fantastic work helping to improve the URL impl.

[watilde]

@jasnell Thanks for mentioning my name at here! I'd love to continue working for the core codes (also for npm/Intl as well), and it would be helpful to me if I can get a notification when someone does ping @nodejs/url ;)

[addaleax]

and it would be helpful to me if I can get a notification when someone does ping @nodejs/url ;)

Done! You don’t need to be a collaborator for that. :)

[sam-github]

@vsemozhetbyt being a collaborator isn't a heavy responsibility on your part, mostly it means that you can land you own commits rather than having someone else do it for you. Also, you can tag issues, and help out with general maintenance should you feel so inclined. And it doesn't imply you have to be an authority on everything, either, just that you are consistently involved, helpful and well intentioned, which you are.

[Trott]

Sorry for the delay on this @vsemozhetbyt and @watilde! We'll get to it soon! In the meantime, I think it's past the point that @richardlau should be nominated as well.

[addaleax]

@Trott Just in case our chat was ambiguous, @vsemozhetbyt’s onboarding is currently being scheduled (last I heard) and I’ll be onboarding @watilde in person on Friday if all goes well :)

[Trott]

@Trott Just in case our chat was ambigious, @vsemozhetbyt’s onboarding is currently being scheduled (last I heard) and I’ll be onboarding @watilde in person on Friday if all goes well :)

🔥 ✨ 🚀 🤘 🙌

Awesome, thanks!

[Trott]

Is someone scheduling @vsemozhetbyt's onboarding? If not, I can try to take that on. If so, then I'll maybe try to set something up for @richardlau. (EDIT: Assuming @richardlau is interested, of course!)

[addaleax]

@ChALkeR ping ^^^

If that doesn’t work out, I can be probably still be available, too

[richardlau]

Assuming @richardlau is interested, of course!

Count me in 😄

[bnoordhuis]

I can do Richard's onboarding (same timezone, same company, logical fit.)