Maintain jQuery repos

gistfile1.md

How to be a maintainer

While its very unlikely to get write access on jQuery Core, the jQuery Foundation maintains a lot of other projects where its much more likely that you're getting write access. There's usually some rules specific to certain repositories, but there are also various rules that apply to all.

Reviewing Issues

• tbd

Dealing with Pull Requests

There are a few things you have to do to land a pull request.

• Figure out if the request is valid. Does it refer to a valid ticket? If not, does it provide a valid usecase? Or is it a trivial change, like fixing a typo? If this test doesn't pass, let the opener know. If its really bad, close the PR (he can still open a new one), though usually you can leave it open to wait for an update.
• Check if they signed the CLA (HOW?)
• Review the code: Does it conform to the style guide? Are there tests, if relevant? Does it only change what's necessary, no widespread whitespace changes? Also check against the repos CONTRIBUTING.md file.
• Get the code and test it!
  • If its a single commit, click the (i) icon at the end of the PR, copy the code on the second line, replace 'pull' with 'fetch', then do a git cherry-pick [commit], where you can get the commit hash from the list of commits in that PR (both on Discussion and Commits tabs). You can now run grunt, do some manual or browser testing and amend the commit to make changes. If you do that, you can also add Closes gh-[xxx] to the commit message, insert the number of the PR to have GitHub auto-close when pushing.
  • If there's multiple commits, add the contributor as a new remote and fetch that. If you install the git fork command as outlined in this blog post, you can just copy the username and type git fork [username]. If the remote already exists, do a git fetch [username]. Next create a local branch with their commits, usually with git checkout -b [number-of-the-pr] [username]/[their-branch-name]. You can use any branch name for the first argument, but referring to the PR is useful. They should be using a unique branch for the PR, but sometimes its just master. Once on that branch, test and decide what to do. If its all good, checkout master and merge that branch. If it needs cleanup, interactive rebase is your friend: git rebase master -i. Follow the instructions in your editor, squesh fixup commits, fix commit messages, the usual.
• Whatever your method of merging is, avoid merge commits. Cherry-picking and rebasing both give you that.
• When you do cleanup, let the contributor know about the changes. If there is too much to clean up, and there's hope for them to stick around, ask them to do it and point out the problems and reference nesseary style guides etc.