Welcome

We're so happy that you want to contribute to PBS ProOpenPBS!  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 OpenPBS 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

OpenPBS

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 Professional guides; these are written for the commercial product, but they also cover open source PBS ProOpenPBS.

Working on PBS Pro on OpenPBS 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 OpenPBS Issues

Contributing Code to

OpenPBS

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 the OpenPBS 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

Detailed Instructions for Contributing