Skip to content

Latest commit

 

History

History
87 lines (62 loc) · 6.22 KB

CONTRIBUTING.md

File metadata and controls

87 lines (62 loc) · 6.22 KB
Raw

Contributing to Circuitverse

  • We expect contributors to abide by our underlying Code of Conduct . All discussions about this project must be respectful and harassment-free.
  • Remember that communication is the lifeblood of any Open Source project. We are all working on this together, and we are all benefiting from this software.
  • It's very easy to misunderstand one another in asynchronous, text-based conversations. When in doubt, assume everyone has the best intentions.
  • If you feel anyone has violated our Code of Conduct, you should anonymously contact the team with our abuse report form via Slack, necessary action will be taken by the team.

Issue label

Please note: If you wanted to work on an issue, let us know by leaving a comment on the issue. If someone is already assigned or working on the issue, do not try to start working without asking in a thread. Also let us know later if you are no longer working on it.

  • maintainers label are internal tasks that will be completed by a Circuitverse core team member.
  • good first issue labeled issues are meant for newer developers.
  • feature labeled issues are meant to propose new features.
  • bugs labeled issues are meant to have errors in existing code base.
  • documentation labeled issues are meant to have typo errors in documentation.
  • difficulty: easy issues are usually confined to isolated areas of existing code.
  • difficulty: medium issues sometimes entail new features and might affect a significant area of the codebase, but aren't overly complex.
  • difficulty: hard issues are typically far-reaching, and might need architecture decisions during implementation. This label might also denote highly complex issues.
  • duplicate labeled issues are meant to be already existing issue in the repository.
  • priority: less labeled issues are meant to have priority comparatavily lesser than other issues.
  • priority: medium labeled issues are meant to have priority comparatively intermediate than other issues.
  • priority: high labeled issues are meant to have the highest priority and need to fix as soon as possible.
  • help wanted labeled issues signify that the contributor requires help with something specific in the issue and your help is very much appreciated.

Creating an issue.

  • Check if the issue you are going to propose is not duplicate of another issue.
  • Open a new issue according to type i.e., if issue is a bug open a new issue by clicking on Get Started in the scope of Bug Report.
  • Give a precise and meaningful name of the issue.
  • Describe your issue as good as possible that may ease the process of issue-reviewing by a community member.

How to contribute

  1. Fork the project and clone it to your local machine. Follow the setup guideline.

  2. Always take a pull from the remote repository to your master branch to keep it at par with the main project(updated repository).

     git pull upstream main

  3. Create a branch. For example, if you are going to work on issue number #44 (which is, say, a new feature for ‘forgot password’ management):

     git checkout -b forgot-password#44

    This both creates and checks out that branch in one command.
    The feature name should provide a (short) description of the issue.

  4. Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.

  5. Commit your changes and push it to your fork of the repository.

  6. Create Pull Request (PR). Make sure to comment the issue that your PR is supposed to solve.

Create a pull request

  • Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
  • For work in progress pull requests, please use the Draft PR feature.
  • Make sure all tests pass and add additional tests for the code you submit.
  • Document your reasoning behind the changes. Explain why you wrote the code in the way you did. The code should explain what it does.
  • If there's an existing issue, reference to it by adding something like References/Closes/Fixes/Resolves #123, where 123 is the issue number.
  • Please fill out the PR Template when making a PR.

Please note: maintainers may close your PR if it has gone stale or if we don't plan to merge the code.

Pull request reviews

  • Requested changes must be resolved (with code or discussion) before merging.
  • If you make changes to a PR, be sure to re-request a review.
  • Don't repeadetely tag someone(may be it is not the right time to review your PR), be patient.
  • Do not 'resolve conversation' unnecessary raised by a community member or any workflow tools(codeclimate or hound) as they may have some purpose, try to resolve the request changes and if any help wanted tag a community member to give views about that.

PR Labels

  • under-review labeled PRs are under review by core team.
  • waiting for contributor labeled PRs are meant to waiting for contributor to respond.
  • waiting for design labeled PRs are meant to waiting for review from UI/UX core team.
  • no activity labeled PRs are meant to have no activity in the PR from since a while.
  • blocked labeled PRs are meant not to go ahead for review.
  • do not merge labeled PRs are meant not to merge the PR right now(may be later).
  • awaiting-approval labeled PRs are meant to be waiting for other communtiy members.

Code Contributors

This project exists because of all the people who have contributed.

The bottom line

We are all humans trying to work together to improve the community. Always be kind and appreciate the need for tradeoffs. ❤️