Skip to content

Latest commit

 

History

History
112 lines (75 loc) · 4.58 KB

CONTRIBUTING.rst

File metadata and controls

112 lines (75 loc) · 4.58 KB

Contributing to TwitStat

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features
  • Becoming a maintainer

We Develop with Github

We use GitHub to track issues and feature requests, as well as accept pull requests.

We Use Github Flow, So All Code Changes Happen Through Pull Requests

Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests:

  1. Fork the repo, clone and create your branch from develop.
git clone [email protected]:<your-username>/twitstat.git
cd twitstat
git checkout -b develop remotes/origin/develop
git checkout -b "your_feature_branch"
  1. Make your changes
  2. Write clear meaningful git commit messages.
git add <changed_files>
git commit -m "Commit Header(limit to 72 chars)
>
> commit body (markdown supported)"
git push -u origin <your_feature_branch>
  1. Always create PR to develop branch.
  2. If you are solving any issue(s), link that to your PR.
  3. Make sure your code lints.
  4. Issue that pull request!

Bugs and Issues

Report bugs using Github's issues

We use GitHub issues to track public bugs. Report a bug by opening a new issue, it's that easy!

Conventions, we follow

  • Git Branches::
    • main branch is used for Production
    • develop branch is used for the development or staging
    • feature_branch branch should create PR to develop branch
    • Delete the feature_branch once merged
  • Project Board::
    • Frontend for the Frontend part of the Application
    • Backend for the backend part of the application
    • Bugs for reporting all the bugs, found on the application

Contribution Guidelines

  • Write clear meaningful git commit messages (Do read How to Write a Git Commit Message).
  • Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. (Check out Closing Issues via Pull Requests for more info)
  • When you make very very minor changes to a PR of yours (like for example fixing a text in button, minor changes requested by reviewers) make sure you squash your commits afterward so that you don't have an absurd number of commits for a very small fix. (Learn how to squash at Squash Commits with Git)
  • When you're submitting a PR for a UI-related issue, it would be really awesome if you add a screenshot of your change or a link to a deployment where it can be tested out along with your PR. It makes it very easy for the reviewers and you'll also get reviews quicker.
  • Please follow the PR Template to create the PR.
  • Always open PR to develop branch.
  • Please read our Code of Conduct.

Contributing to the Documentation

We use sphinx to generate documentation. Sphinx uses reStructuredText as its markup language.

  1. Move to the docs Directory
cd docs
  1. Install dependencies
python -m pip install -r requirements.txt
  1. Make Changes
  2. Running the docs locally
# inside docs directory
make html   # build html
open build/html/index.html  # Open/Refresh the index page to check the output

License

Any contributions you make will be under the MIT Software License

In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.

By contributing, you agree that your contributions will be licensed under its MIT License.