Skip to content

Instantly share code, notes, and snippets.

@thlorenz

thlorenz/collaborating.md

Last active September 20, 2022 18:20
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save thlorenz/f7df0daf13c6f6c1fa84 to your computer and use it in GitHub Desktop.
Save thlorenz/f7df0daf13c6f6c1fa84 to your computer and use it in GitHub Desktop.
Download ZIP
A quick guideline to contributing to my open source projects
Raw
collaborating.md

Collaborator Guidelines

Now where you are a collaborator you have certain powers that you should use carefully, so I'm listing some guidelines here.

Contributing

Proposing a Change

Even though as a contributor you could push directly to master, please don't do that. Instead each bug fix or feature should be proposed via a pull request. You are free to create the branch for that in your own repo or in the main one by prefixing your name, i.e. in my case for feature foo I'd call that branch thlorenz/foo.

Please do not change the version of the package as part of your proposed change. The contributors with access to the npm package will decide what upgrade should be performed and do this in conjunction with adding the appropriate tags.

Merging a PR

Once enough other contributors (in most cases that'd be mainly me) agree with the proposal, it can be merged to master.

However please do not use the green button on github. It just creates noise via merge commits. Instead please only perform fast forward merges, via the --ff-only flag or by rebasing the branch onto the master branch first. Please find some quick notes about fast forward merges here and here.

Obviously this advice not only applies to your pull requests, but pull requests of others as well.

Tools to help with PRs

Issues

Closing

As a collaborator you have the ability to close/re-open issues. Please do so with respect to whoever is filing the issue. You should at least attempt to either get more information from whoever filed it or make clear to them why the issue is not valid, solved and/or cannot be handled.

However don't be afraid of going ahead and closing an issue. This helps me a ton as I don't have to go through each of them myself.

Labeling

At times it helps to label issues, i.e. if the issue is actually a question we should apply the Question label. Another important label I have started adding to my repos is Awaiting Response. This helps to see in which case I have responded to the issue and asked for more information, i.e. the ball is in the court of the issue filer and there is nothing we can do until he/she responds. After considerable time passes without a response that issue is subject to be closed.

Here is how we use this label in browserify-shim.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment