Skip to content

Latest commit

 

History

History
83 lines (62 loc) · 5.17 KB

CONTRIBUTING.md

File metadata and controls

83 lines (62 loc) · 5.17 KB
Raw

Back to README

Contributing To The Repository

We encourage you to contribute! Inland Empire Software Development is always pushing members to contribute to open source software. If you're looking for a way to contribute, ask for an admin on our Slack and we will be more than happy to help you with your first contribution.

We highly encourage you to join our Slack, as that is our main venue for collaboration.

Content

Git Branch

THIS IS IMPORTANT when contributing to GitHub repositories. Branches allow contributors to work on the same repository without constantly running into conflicting code.

Please have a look at this link on Git Branches before you proceed to contribute.

Git Pull

Before pushing your changes to the repository make sure to use

$ git pull

before. This retrieves the most up to date changes and merges it with your files.

To read more about git pull/git merge/git fetch visit this link

Learning how to push changes to the repository

To learn how to add the files you have changed to this repository, go to one of the links below.

Bugs and enhancement issues

We use GitHub issues for bug tracking. Below are the main categories of labels that are used to organize our issues. Issues may have multiple labels. There are many more labels, but these are the main labels that are used to keep issues organized.

  • minor bug - Minor bugs are problems that are not breaking issues, but would be great to address. These bugs are not prioritized.

  • bug - These bugs should be fixed, but may not require immediate attention. They may significantly affect some aspect of the project, but is not prioritized.

  • priority - These can be serious problems or enhancements that require immediate attention. These should be worked on as soon as possible.

Possible improvements that may not be bugs. These can be improvements to user experience, such as new features, or they can be improvements to the code, such as code quality.

  • enhancement - Enhancements can be improvements that improve user experience. These can also be suggestions in which the community can discuss whether to implement or not.

  • code quality - Improvements to the code base to help other coders.

If you're a new developer, we highly recommend trying one of the bugs tagged as good first issue

  • good first issue - These tend to range from simple to moderately difficult. We try to keep these open for new developers that are trying to get involved in free open source software. If you're experienced, we recommend that you leave these open for newer developers to try and tackle.

Pull request format

  • Title your pull request to indicate its purpose. (This will be similar to the title of the issue it addresses.)
  • Include a reference to the issue(s).
  • If it's a work-in-progress, include [WIP] in the title. Remove this once the PR is complete and ready for review.
  • If possible, it would be helpful if you include before-and-after screenshots for user interface changes.

After opening a pull request

  • If the PR fails the review:
    • Fix whatever caused it to fail if you can and then push changes to the branch.
    • Ask for help if you can't fix it. If a PR fails to pass the review, but you haven't asked for help, we will assume that you are working on it.
  • If you don't get reviewer feedback within a day or two, or you're waiting for a followup, please ping someone or ask on Slack.

Code style

We are currently working on implementing a code style to the project.

Tests

We are currently working on implementing tests into our project.