arsnova.click needs you! If you are interested in helping, here is a short guide.
- First, fork and clone our repository.
- Create a topic branch.
- Make your changes. Be sure to provide clean commits and to write expressive commit messages.
- Check your style: after pushing to your branch, read the jshint-comments in the build section.
- Stay up to date with our repository: Rebase to our
staging
branch usinggit rebase
. - Push the changes to your topic branch.
- Finally, submit a merge request.
If you don't feel like writing code, you could also update the documentation. And if you find any bugs, feel free to open a new issue.
To get your merge request accepted faster, you should follow our review process before submitting your request. Here is our list of dos and don'ts.
This is a no-brainer. Keep your branches up to date so that merges will never end up conflicting. Always test-merge your branches before submitting your pull requests. Ideally, your branches are fast-forwardable, but this is not a requirement.
Please check your code against our code guidelines defined with jshint.
We support the use of gulp, which checks against our jshint and jscs rules. Just install the node modules (npm install
) and run gulp
. If you want to watch the files use gulp watch
.
Since Meteor is supporting ES6 (ES2015) we use the import/export statements to modularize the application. Please take a look at our project file structure for the clients:
client/
layout/
global/
styles/
templates/
scripts/
region_XYZ/
view_XYZ/
styles/
templates/
scripts/
events.js
helpers.js
lib.js <= Use this file as a library for the view
onCreated.js
onDestroyed.js
onRendered.js
lib/ <= Here are global libraries defined, e.g. the access to the localStorage
plugins/ <= Here we have plugins for the application.
styles/
templates/
scripts/
events.js
helpers.js
lib.js
onCreated.js
onDestroyed.js
onRendered.js
The difference between a region and a view is that the region is named by the location (e.g. "header") and is nearly over the entire quiz-workflow visible where a view is rendered only to specific routes. Please note that global variables should be avoided. If you use the global Meteor variable, import it with ''' import { Meteor } from 'meteor/meteor' ''' (see the Meteor Doc at http://docs.meteor.com/#/full/)
Committing trailing white-spaces makes your merge request look sloppy. Most editors have a setting that remove trailing white-spaces, which you should activate. You can use git diff
to review changes since it highlights erroneous white-spaces.
In addition, do not accidentally remove white-spaces of unrelated lines.
Use git add -p
to selectively add changes. Skip those that have nothing to do with the commit you are preparing. Every commit should precisely contain only those changes that are important for the feature you are developing or the bug you are fixing.
In the screenshot above, the license header was accidentally changed, presumably by some editor misconfiguration. Reviewing your changes before committing allows you to spot such mistakes.
Is every file present that has seen some changes? Are there any files that appear in the list even if they were not changed? As mentioned previously, only necessary changes should appear in a commit. Review your changes using git diff --stat
.
Sadly, some editors still do not have UTF-8 as their default setting. Using the wrong encoding will destroy non-ASCII characters like french quotation marks or umlauts.
It all comes down to
- reviewing your own changes,
- keeping your commits clean and focused,
- and always staying up to date.
If you keep these things in mind, your merge requests will be accepted much faster. Happy coding!