Skip to content

Contributing

Jump to bottom
Adam Fraser-Kruck edited this page Nov 24, 2017 · 4 revisions

Small to medium contributions

These are recommendations for when you have a small change or bug fix.

  • Open an issue with appropriate label (see below) as it provides a great place for discussion and documenting why certain changes were made. It also helps coordinate our efforts (suggest which branch to work off of), avoid duplication of work and help ensure that your work is accepted into the project.
    • use label bug-reported for bugs. Project maintainers will add bug-confirmed label once reproduced/understood.
    • use label enhancement for ideas to make uncrap more awesome.
  • Fork this repo and checkout the branch you want to work on.
    • Main development takes place in the develop branch which probably is what you want. We will suggest where to branch from in your opening issue.
    • Note that the master branch will be used for latest stable releases. No pull requests against master will be accepted.
  • Then start a new branch for your change. Please avoid slashes in name for now.
  • Once your branch is tested and works, you should:
    1. update your fork and then MERGE develop into your branch to resolve any merge conflicts in your branch. This is important as it doesn't break develop and allows others to continue developing. For short lived branches, you probably won't have any merge conflicts. If you do have a conflict, please retest after resolving.
    2. Open a pull request into the develop branch.
  • After the pull request is merged, you should update your fork and then you can delete your branch on your forked repo. This is safe as the branch has already been merged so no commits are lost.

Pull requests

Please only address one problem in each pull request. Fixing a bug and adding a new feature should be done in two separate pull requests. Fixing two bugs should be done in two pull separate requests unless they are fixed by the same code...

Becoming a contributor

If you are going to be doing a good chunk of development (and have already had a few pull requests accepted), we can add you as a github contributor to make branching and merging easier (you don't need to work off of a fork). All merges into develop require a pull request anyway as it is a github protected branch.

When multiple people are working on the same feature (let's say a new parser), they should have their own branches like: new-parser--adam, new-parser--paul, and then merge into new-parser.

Once new-parser is ready, it should be merged into develop and deleted.

Branch naming

If you are working off a fork, name it whatever you want.

Use hyphens to separate words.

Please avoid slashes "/" in branch names for now as there can be many problems with them (tools not supporting them & other unintentional effects). It definitely makes it look nicer, but I'd rather avoid the headache for now.

commit messages

We are going to try out a simplified version of what angular.js uses see here for examples.

It looks like this:

git commit -m "fix(ui): correct formatting of downloaded files"
git commit -m "fix(c-parser): allow comments after opening braces"

The format is this: <type>( <scope> ): <message>

Types

  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies

Scopes

We don't have established scopes yet. Use your best judgement.

Suggestions:

  • ui: user interface related. Pretty much anything related to .html files.
  • c-parser: the C parser.
  • core: other core related things.

code style

We should try and follow current best practices (60k stars!): https://github.com/airbnb/javascript

The below are of primary interest:

Additional useful guides

Next steps

Clone this wiki locally