Welcome
We're so happy that you want to contribute to PBS Pro! All contributions are welcome.
The first part is easy: sign up for whichever forums interest you: we have one for users & system administrators, and one for developers.
The codebase is open to all contributors. Anyone can create their own fork of the PBS Pro repository.
Please be sure that you respect our code of conduct when you are participating in our community.
If we've missed something or gotten it wrong, please let us know.
Contents
Learning About PBS Pro
You can ask questions on the forums; we have one for users & system administrators, and one for developers.
Please remember that everyone is doing their best, and treat others in a gentle and respectful fashion. We want to keep it helpful and fun.
You can download the PBS Pro guides; these are written for the commercial product, but they also cover open source PBS Pro.
Working on PBS Pro is similar to other open source projects:
- We keep our source on GitHub.
- We file our issues for bugs and RFEs in GitHub.
- We post our designs on Confluence.
- We discuss our designs on our developer forum.
Reporting PBS Pro Issues
The PBS issue tracker is at https://github.com/pbspro/pbspro/issues. But it might exist there already... see if you can find it. In a few words, how does it affect the software user? What are the steps to reproduce the problem? If the issue is intermittent and not easily reproducible, what triggers it? It's helpful to add the platform where the bug is observed, for example CentOS 7.2 Make it easy to understand and reproduce the problem that the user sees. You can include short illustrative excerpts from log files or terminal sessions. Do not include large sections of log files or terminal sessions. Output of the $PBS_EXEC/sbin/pbs_snapshot command, or the $PBS_EXEC/unsupported/pbs_diag command Log excerpts, core files, or terminal sessions to help the developers to analyze the bug more easily Describe the new feature. How does it make the world a better place? The new feature may already be in the works. You can look through the project documentation pages to find out.Issues are Tracked in GitHub
Filing a Bug or Feature Request (RFE)
Bug?
Useful Attachments
RFE?
Thanks!
Contributing Code to PBS Pro
Get involved! We're thrilled when people fix bugs or add features.
Getting Started
You'll need to get a GitHub account and learn to use git. Set up your Git environment.
Designing and Discussing
First, check whether someone else is already working on it. Look through the outstanding pull requests and the design docs.
For simple changes, you can just open a pull request and describe what you're doing in the PR. For more complex changes, you can create a design doc. If you do, please take note of our guidelines for design docs.
Before you start coding, post your idea on the developer forum. This way you can avoid duplicating someone else's work, and you can get helpful feedback. Use the developer forum for all of your project discussions.
Coding
Please follow our coding conventions. For C:
- Use tabs for indentation
- Function definitions have return values
- Put function definition and braces on separate lines
- Put braces on the same line as the statement
- No whitespace at the end of a line
- Put spaces between
if
,for
,while
,switch
etc. and their opening parenthesis. Examples:if (x) ...
,for (...
- Put spaces on both sides of operators
- Use C style comments, no ‘//’. Multiline comments start with ‘/*’ where subsequent lines have ‘*’ on the left-hand side, and end with ‘*/’ on a newline
- Use doxygen-style function headers
For Python:
- We follow the PEP8 standard. You can check whether your python code adheres to PEP8 by running the pycodestyle program on your .py file.
Testing
We use a set of Python modules we call PTL to test PBS. Write tests for your code.
Pull request
For your commit message, summarize the issue or change, as it affects an admin or job submitter.
Use the title of your commit message as the title of your pull request.
In your PR, add links to the forum discussion and the design doc (if it exists).
Approval
If you have a design doc, get your design approved before you code. Get approval for your code and tests from at least one maintainer and one other contributor. Our maintainers show that they accept it with "LGTM" (Looks Good To Me). The first time you submit a pull request to have your code merged into the PBS Pro golden repository, you'll have to sign the contributors' license agreement. To get your pull request accepted:
- The code should adhere to the design doc, if there is one
- The changes should not destabilize PBS
- The code has to be reviewed and approved by the community
- The code has to pass the CI tests
Quick Summary for Contributing
If you are familiar with Git and PBS or are experienced with contributing to open source:
Detailed Instructions for Contributing
If you are new to Git, PBS Pro, and contributing to open source projects, we can walk you through the exact steps to contribute to PBS Pro in these step-by-step instructions for fixing a bug or developing a feature.
Be Part of the PBS Pro Community
We welcome you to the PBS Pro open source community. Please read our code of conduct and our acceptable use policy. We want to maintain a community where everyone can enjoy and benefit from participating, and where our impact is always positive. Be friendly, patient, courteous, and respectful to everyone. Remember that not everyone can express themselves the way they would like; give them the benefit of the doubt. Make every participant feel welcome. And make sure you don't make us unwelcome in any way: nothing rude, illegal, or icky. Thank you for contributing to PBS Pro.
Resources
Site map with all of our open source PBS Pro pages