Submitting A Pull Request

Use this page as a practical checklist for contributing to any AtlassianPS repository. If this is your first PR, you are in the right place.

Tip: Start small if you want to. A focused PR is often the fastest path to a successful review.

✅ Quick checklist

  1. Pick an issue (or open one first).
  2. Fork the target repository.
  3. Create a feature branch from master.
  4. Implement the change (code + tests + docs where needed).
  5. Run the repository validation steps.
  6. Declare the release and changelog intent.
  7. Open a Pull Request to AtlassianPS/<repo>:master.

No stress if you do not get everything perfect on the first try. Reviews are collaborative.

🧭 Project-specific contribution guides

JiraPS is our current gold standard for contribution guidance. Use that flow as your baseline, then apply repo-specific setup and validation details from each project’s current guide.

Project Guide
AtlassianPS.Configuration https://github.com/AtlassianPS/AtlassianPS.Configuration/blob/master/README.md
AtlassianPS.github.io This docs section (you are here)
ConfluencePS https://github.com/AtlassianPS/ConfluencePS/blob/master/README.md
JiraAgilePS https://github.com/AtlassianPS/JiraAgilePS/blob/master/README.md
JiraPS ⭐ https://github.com/AtlassianPS/JiraPS/blob/master/CONTRIBUTING.md

As other modules adopt the JiraPS standard, their README links above will be replaced with CONTRIBUTING.md. Legacy modules such as AtlassianPS, BitbucketPS, and HipChatPS are not active documentation targets on this website.

🧰 Setup

Required tools

  • Git
  • PowerShell
  • Repository-specific tooling described in each project guide above

Helpful tools

🌿 Forking and branching

git clone https://github.com/<YOUR USER NAME>/<NAME OF THE PROJECT>.git
cd <NAME OF THE PROJECT>
git checkout master
git checkout -b <SHORT-FEATURE-NAME>

Keep your branch focused on one change set. Small PRs are easier to review and merge.

🛠️ Implementation expectations

  • Follow Our Guidelines.
  • Update tests when behavior changes.
  • Update docs for user-facing changes.
  • Keep commits scoped and readable.

Declaring release intent

Every pull request must have exactly one release label:

  • release:none for internal work that should not independently publish a package;
  • release:patch for a backward-compatible fix;
  • release:minor for backward-compatible functionality; or
  • release:major for a breaking change.

A patch, minor, or major change also needs one changelog:* label. Use a .changelog/<pr-number>.<impact>.<type>.md fragment instead when the public release note needs wording that differs from the pull request title. The Release Intent check explains missing or conflicting labels directly on the pull request.

Additional references:

🧪 Validation

Run the validation commands defined by the target repository before opening a PR.

Important: Always run the repository’s validation commands before opening or updating your PR.

PowerShell module repositories normally use:

./Tools/setup.ps1
Invoke-Build -Task Build, Test

For AtlassianPS.github.io, run:

bundle exec jekyll build --baseurl ""

📬 Opening the Pull Request

Open a PR from your fork branch to the upstream master branch.

A strong PR description should include:

  • what changed
  • why it changed
  • how you validated it

🤝 What happens next

Maintainers and reviewers will review your PR and CI checks.

You may be asked to:

  • adjust implementation details
  • add or update tests
  • update docs/examples

Once approved, the PR is merged into master.

If you get stuck at any point, open an issue and ask for guidance.

On this page