-
Notifications
You must be signed in to change notification settings - Fork 1
Developer Guidelines
This page serves as a general overview of the rules and guidelines that need to be followed when contributing to this project.
As a contributor, you will have the option to create and label issues. The labels used in this project were inspired from this site. Please read that link before creating an issue so you know how to properly label it.
Do not commit or push directly to the master branch.
All code contributions should be created,developed and tested in their own branch. Once the feature/update/etc.. is complete, as a contributor, you should create a pull request into the master branch from your branch. Once created, the pull request will be reviewed by one of the project leads who will then merge it into the master branch.
If these words/phrases didn't make sense to you (commit,push,branch,pull request) please read up on git. Our resources page has links to a few good tutorials on git.
The only IDE that should be used on this project is WebStorm. If you don't want to use WebStorm, then you should use a text editor such as Atom.
For people who are not already familiar with development on a text editor, WebStorm is the recommended development environment for this project. WebStorm has a lot of powerful tools that will make life easier, such as Git integration and code completion.
The reason why this project doesn't allow IDEs other than WebStorm relates to the .gitignore file. While text editors do not use additional files when creating a project, IDEs usually generate many metadata files which have no bearing on the project as a whole. When these files are pushed to the repository, they can clutter it up or even cause problems for other developers. This is where the .gitignore comes in. The .gitignore tells Git which files it should not upload to the repository. However, each IDE generates different metadata files, so the .gitignore has to be customized to match each IDE. Basically, the more IDEs being used by developers, the harder it is to manage the .gitignore properly.
Also, as most of the contributors are new to this development environment, the languages and the frameworks used on this project, it will be easier to provide assistance to each other if we are all on the same setup.