Break your project into manageable pieces
You may find that you need to break a large contribution into smaller, workable pieces. The same guidelines apply to each separate piece.
Do you need a design doc?
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 design doc guidelines.
Announce and discuss your design
If you do need a design doc, create one in the project documentation space, and announce it on the developer forum. In your announcement, put a link to the design doc, with a brief description. Your initial draft only needs a title and an overview. Use the developer forum for all your design discussions.
Make your design useful and readable
Be kind to your readers: try to answer questions in your design doc so that other developers, admins, job submitters, testers, and publications people can get the info they need. Be concise, include diagrams and examples, and keep the design doc up to date. Put a concise, descriptive, unique title at the top. If the design is associated with an issue ID, include it. It's helpful to include a link to the discussion on the developer forum.
...
When you're designing, consider performance, scalability, resilience, security, maintainability, usability, and upgrades. Work to make the interface consistent with the rest of PBS.
Pull request title and commit message
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.
Acceptance
Before you code, get your design approved.
To get your pull request accepted:
...
...
...