Skip to content

Latest commit

 

History

History
204 lines (143 loc) · 9.5 KB

CONTRIBUTING.md

File metadata and controls

204 lines (143 loc) · 9.5 KB

Contributing to slurmrestd-operator

Do you have something that you wish to contribute to slurmrestd-operator? If so, here is how you can help!

Please take a moment to review this document so that the contribution process will be easy and effective for everyone involved. Also, please familiarise yourself with the Juju SDK documentation as it will help you better understand how slurmrestd-operator works and is developed.

Following these guidelines helps you communicate that you respect the developers managing and developing slurmrestd-operator. In return, they should reciprocate that respect while they are addressing your issue or assessing your submitted patches and features.

Have any questions? Feel free to ask them in the Ubuntu HPC Matrix space.

Table of Contents

Using the issue tracker

The issue tracker is the preferred way for tracking bug reports, feature requests, and submitted pull requests, but please follow these guidelines for the issue tracker:

  • Please do not use the issue tracker for personal issues and/or support requests. The Discussions page is a better place to get help for personal support requests.

  • Please do not derail or troll issues. Keep the discussion on track and have respect for the other users/contributors of slurmrestd-operator.

  • Please do not post comments consisting solely of "+1", ":thumbsup:", or something similar. Use GitHub's "reactions" feature instead.

    • The maintainers of slurmrestd-operator reserve the right to delete comments that violate this rule.
  • Please do not repost or reopen issues that have been closed. Please either submit a new issue or browser through previous issues.

    • The maintainers of slurmrestd-operator reserve the right to delete issues that violate this rule.

Issues and Labels

The slurmrestd-operator issue tracker uses a variety of labels to help organize and identify issues. Here is a list of some of these labels, and how the maintainers of slurmrestd-operator use them:

  • Type: Bug - Issues reported in the slurmrestd-operator source code that either produce errors or unexpected behavior.

  • Status: Confirmed - Issues marked Type: Bug that have be confirmed to be reproducible on a separate system.

  • Type: Documentation - Issues for improving or updating slurmrestd-operator's documentation. Can also be used for pull requests.

  • Type: Refactor - Issues that pertain to improving the existing slurmrestd-operator code base.

  • Type: Idea Bank - Issues that pertain to proposing potential improvement to slurmrestd-operator.

  • Type: Enchancement - Issues marked as an agreed upon enhancement to slurmrestd-operator. Can also be used for pull requests.

  • Statues: Help wanted - Issues where we need help from the greater slurmrestd-operator community to solve.

For a complete look at slurmrestd-operator's labels, see the project labels page.

Bug Reports

A bug is a demonstrable problem that is caused by slurmrestd-operator. Good bug reports make slurmrestd-operator more robust, so thank you for taking the time to report issues in the source code!

Guidelines for reporting bugs in slurmrestd-operator:

  1. Validate your testlet — ensure that your issue is not being caused by either a semantic or syntactic error in your testlet's code.

  2. Use the GitHub issue search — check if the issue you are encountering has already been reported by someone else.

  3. Check if the issue has already been fixed — try to reproduce your issue using the latest main in the slurmrestd-operator repository.

  4. Isolate the problem — the more pinpointed the issue is, the easier time the slurmrestd-operator developers will have fixing it.

A good bug report should not leave others needing to chase you for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What operating system are you experiencing the problem on? Have you had the same results on a different operating system? What would you expect to be the outcome? All these details will help the developers fix any potential bugs.

Feature Requests

All feature requests should be posted to GitHub Discussions and tagged as Type: Idea Bank. The maintainers of slurmrestd-operator already know the features they want to incorporate into slurmrestd-operator, but they are always open to new ideas and potential improvements. GitHub Discussions is the best place to post these types of requests because it allows for feedback from the entire community and does not bloat the issue tracker. Please note that not all feature requests will be incorporated into slurmrestd-operator. Also, feature requests posted on the issue tracker will be tagged as Type: Invalid and closed. Lastly, please note that spamming the maintainers to incorporate a feature you want into slurmrestd-operator will not improve its likelihood of being implemented; it may result in you receiving a temporary ban from the repository.

Pull Requests

Good pull requests — patches, improvements, new features — are a huge help. These pull requests should remain focused in scope and should not contain unrelated commits.

Ask first before embarking on any significant pull request (e.g. implementing new features, refactoring code, incorporating a new test environment provider, etc.), otherwise you risk spending a lot of time working on something that slurmrestd-operator's developers might not want to merge into the project! For trivial things, or things that do not require a lot of your time, you can go ahead and make a pull request.

Adhering to the following process is the best way to get your work included in the project:

  1. Fork the project, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
    git clone https://github.com/<your-username>/slurmrestd-operator.git
    # Navigate to the newly cloned directory
    cd slurmrestd-operator
    # Assign the original repo to a remote called "upstream"
    git remote add upstream https://github.com/omnivector-solutions/slurmrestd-operator.git
  2. If you cloned a while ago, pull the latest changes from the upstream slurmrestd-operator repository:

    git checkout main
    git pull upstream main
  3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:

    git checkout -b <topic-branch-name>
  4. Ensure that your changes pass all tests:

    tox run -e fmt
    tox run -e lint
    tox run -e unit
    tox run -e integration
  5. Commit your changes in logical chunks. Please adhere to these git commit message guidelines or your code is unlikely be merged into the main project. Use Git's interactive rebase feature to tidy up your commits before making them public.

  6. Locally merge (or rebase) the upstream development branch into your topic branch:

    git pull [--rebase] upstream main
  7. Push your topic branch up to your fork:

    git push origin <topic-branch-name>
  8. Open a Pull Request with a clear title and description against the main branch.

IMPORTANT: By submitting a patch, improvement, or new feature, you agree to allow the maintainers of slurmrestd-operator to license your contributions under the terms of the Apache Software License, version 2.0.

Discussions

GitHub's discussions are a great place to connect with other users of slurmrestd-operator as well as discuss potential features and resolve personal support questions. It is expected that the users of slurmrestd-operator remain respectful of each other. Discussion moderators reserve the right to suspend discussions and/or delete posts that do not follow this rule.

Code guidelines

The following guidelines must be adhered to if you are writing code to be merged into the main slurmrestd-operator code base:

Juju & Operators

Python

License

By contributing your code to slurmrestd-operator, you agree to license your contribution under the Apache Software License, version 2.0.