Guide for Contributing

Making Changes

Anytime you want to make a change or experiment make a branch off of master. The branch should be named according to what you are working on. For example, if I was fixing the hamburger menu I would name my branch landon_menuAutoClose. You don't have to include your name if you don't want to but just by looking at the branch name you can see who made the change and get an idea of what the change will do.

Committing

When making a commit make sure you only include the files that are relevant. DO NOT USE git commit -A. Make sure the commit message is in the present tense and it explains what the commit does not what you did. This can be a little confusing I know but here's an example of a good commit message fixes side to side wiggle on mobile rather than fixed mobile wiggle. Another example adds 'executives' mobile hamburger menu rather than extended mobile menu.

Your commit message should be under 84 characters on the first line, if you need to go into more detail leave a blank line and add one more piece of information on each additional line. This has to do with the way the messages are displayed and makes it much easier to look through a lot of commits at once.

here's an example of where you might want to add a bit more detail

fixes mobile hamburger menu autoclose

adds binding for 'touchstart' in devclubJS.js
adds comments to 'mousedown' binding 
fixes typo in readme

Ideally you want to make every major change a new commit but the last two lines are small enough to be lumped in with this commit. When you are looking at this commit in the browser you will see fixes mobile hamburger mene autoclose which gives you enough information but you'll also have the option to expand it and see the bottom 3 lines. This way of doing it is clean, standard, and can be very useful.

Making merge requests

Eventually we will set up some MR (or PR if you prefer) templates so you can just base your merge requests off of that but until then you will be responsible for formatting them yourself.

First thing, LINK TO YOUR ISSUE!!! By putting Resolves #(issue number) at the beginning of your merge request that issue will be automatically resolved when the merge request is accepted. This greatly reduces the amount of maintenance that needs to be done on the project repo and is just a clean way to do things.

From there you want to provide a brief description of the problem you are solving, the solution to that problem, your implementation of that solution, what you did to test the fix, and any reference images that may be needed.

I know that seems like a lot but considering each one of these sections can be anywhere from 1 sentence to a full paragraph depending on the type of change and it's complexity it's a good habit to get into even for the smallest changes. It also makes it much easier for people to review your MR if it's easy to read and presents all this information well.

Please see our PR template for a good PR starting point: Pull Request Template