Skip to content

Your First Contribution

Jump to bottom
James Spadafora edited this page Feb 1, 2026 · 1 revision

Your First Contribution to DNA

Welcome! 🎉
This guide walks you through making your first contribution to the DNA project—from setup and access, to testing, to submitting a clean Pull Request.

1. Choose a Good First Issue

Start with something that is:

  • Small and well-scoped (docs, minor bug fixes, small refactors).
  • Check the tags on the issues. There are some issues tagged as "Help Wanted" which are usually good.
  • Clearly described and reproducible.
  • Not blocked by unavailable production data (when possible).

If the issue touches production tracking systems, read the next section carefully.

2. Access You May Need (ShotGrid / Other Systems)

Many parts of DNA depend on production tracking data.

  • You will most likely need access to ShotGrid (or another production tracking system, depending on the issue).
  • If you do not already have access, contact the core development team to request it. You can contact the team on Slack. See the Get Involved page.

If you are unsure whether access is required, ask early.

3. Set Up the Repository Locally

  1. Fork the repository (or create a branch if you have direct access).
  2. Clone the repo locally.
  3. Follow the setup instructions in the README exactly.
  4. Verify that the project runs locally before making changes.

Do not skip this step—many issues are environment-related.

4. Create a Feature Branch

Create a branch for your work.

Keep your changes focused.
If you notice unrelated issues, open a separate issue instead of expanding scope.

5. Testing (Required)

All changes must be tested before submitting a Pull Request.

Before opening a PR:

  • Run the relevant test suites.
  • Use the test commands documented in the README.
  • If you modify shared or core functionality, run broader tests.

If your change requires manual validation (UI or integration work), document how you tested it in the PR description.

6. Pipelines and Code Quality

Pipelines ensure that:

  • Code quality is maintained
  • Bugs are not introduced
  • Style and formatting stay consistent

You should:

  • Run the same commands locally that the CI pipeline runs
  • Use the commands listed in the README (linting, formatting, type checks, tests)

If your PR fails CI, it is considered incomplete until fixed.

7. Submitting a Pull Request

Your Pull Request should include:

  • What changed – brief summary
  • Why it changed – context or issue link
  • How it was tested – commands run and/or manual steps
  • Screenshots or recordings – if UI behavior changed
  • Access notes – e.g. ShotGrid environment used

Keep commits clean and avoid mixing unrelated changes.

8. When You’re Unsure

If you are blocked or unclear:

  • Ask which behavior is expected
  • Ask which environment or dataset to use
  • Ask whether mocks or real data are preferred

Early questions save time for everyone.

9. Learn From Other Repositories

Before implementing something new, look at other related repositories to understand:

  • Code structure and conventions
  • Testing patterns
  • PR style and expectations
  • CI requirements

When possible, follow established patterns instead of inventing new ones.

Pull Request Readiness Checklist

  • Changes are scoped and easy to review
  • All relevant tests have been run
  • Pipelines pass locally where possible
  • PR clearly explains what, why, and how
  • Required system access is documented

Thanks for contributing to DNA 💚
We’re glad to have you here.

aswf_logo

Clone this wiki locally