Skip to content

Latest commit

 

History

History
133 lines (83 loc) · 6.23 KB

CONTRIBUTING.md

File metadata and controls

133 lines (83 loc) · 6.23 KB

Contribution Guidelines

Welcome to the PotLock core repository! We appreciate your interest in contributing. Before you get started, please take a moment to review these guidelines to ensure a smooth and collaborative contribution process.

Table of Contents

Code of Conduct

Please review and adhere to our Code of Conduct in all your interactions regarding this project.

How to Contribute

Reporting Issues

If you encounter any bugs, problems, or have suggestions for improvements, please check the Issues section before creating a new one. If the issue is not yet reported, you can create a new issue following the provided template. Be sure to provide as much detail as possible to help us understand and address the problem.

Submitting Pull Requests

We welcome contributions through pull requests (PRs). To submit a PR, follow these steps:

  1. Fork the repository to your GitHub account.
  2. Create a new branch from the main branch. Please use a descriptive and concise name for your branch.
  3. Commit your changes to your branch. Be sure to include clear commit messages that explain the purpose of each change.
  4. Push your branch to your forked repository.
  5. Create a pull request against the main branch of the original repository.
  6. Ensure your PR description explains the changes you've made and why they are valuable.
  7. All PRs must pass the automated tests and adhere to the coding guidelines.

Coding Guidelines

Branching Strategy

We follow the Gitflow branching model:

  • main branch contains stable production-ready code.
  • develop branch contains the latest development code.
  • Feature branches should be created from develop and merged back into develop.

Coding Style

Please maintain a consistent coding style throughout the project. Follow the style guide for your programming language (e.g., PEP 8 for Python, Airbnb JavaScript Style Guide for JavaScript).

Documentation

  • Document your code using clear and concise comments.
  • Update the README if necessary to reflect new features or changes.
  • Provide relevant documentation in the docs directory.

Testing

  • Write unit tests for new code.
  • Ensure all tests pass before submitting a pull request.

Review Process

  • Pull requests will be reviewed by maintainers.
  • Constructive feedback will be provided; you may need to make changes before your PR is merged.
  • Once approved, your PR will be merged into the appropriate branch.

Sure, here's an added section for issue tracking in your contribution guidelines:

Issue Tracking

We use GitHub Issues to track and manage tasks, enhancements, and bugs for this project. This section outlines how to effectively work with issues:

Opening Issues

If you encounter a bug, have a feature request, or want to propose an enhancement, please follow these steps:

  1. Search: Before opening a new issue, search the existing issues to see if it has already been reported or discussed.

  2. Create a New Issue: If you couldn't find a similar issue, create a new one. Use the provided issue templates to structure your report or request effectively.

  3. Provide Details: When creating an issue, provide as much context and detail as possible. This helps contributors understand the problem and work towards a solution.

Issue Labels

We use labels to categorize and prioritize issues. These labels provide valuable information to contributors and maintainers. Here are some of the labels you might encounter:

  • Bug: Used for identifying bugs or unexpected behavior.
  • Feature Request: For suggesting new features or enhancements.
  • Documentation: Pertaining to documentation improvements or additions.
  • Help Wanted: Indicates that assistance from the community is requested.
  • Good First Issue: Suggested for newcomers as a starting point.
  • Priority: Indicates the urgency or importance of the issue.

Working on Issues

If you'd like to work on an existing issue:

  1. Assign Yourself: If you're planning to address an issue, assign it to yourself to let others know you're working on it.

  2. Ask for Clarification: If you're unsure about any aspect of the issue, feel free to ask for clarification in the issue thread.

  3. Create a Pull Request: After making changes, create a pull request that references the issue. This helps reviewers understand the context and purpose of your changes.

Closing Issues

An issue can be closed once its purpose has been fulfilled. This may include fixing a bug, implementing a feature, or determining that the issue is no longer relevant.

  • Closing by Contributors: Contributors should ensure that the issue's resolution is tested and verified before closing it.

  • Closing by Maintainers: Maintainers may close an issue if it's a duplicate, not actionable, or doesn't align with project goals. A brief explanation will be provided.

Remember, the issue tracker is a collaborative space, and open communication is key to successful collaboration.

Note: These guidelines are meant to streamline our issue tracking process. Always refer to the specific issue templates and labels in the repository for precise instructions.

Feel free to adapt and customize this section based on your project's specific issue tracking workflow and terminology.

Community and Communication

  • Join the Discussion board for general questions and discussions.
  • Use the Issues and Pull Requests for project-specific topics.
  • Respect other contributors and maintain a friendly and inclusive atmosphere.

Attribution

These contribution guidelines are adapted from Open Source Guides under the Creative Commons Attribution-ShareAlike license.