Contributing

How to get a change from your editor into main in any artpark-hub repo. This is the org-wide guide — it applies to every project unless that project adds its own CONTRIBUTING.md.

New here? Read How We Work first. That doc covers the bigger picture — issues, communication, meetings. This one is the narrower thing: the mechanics of making a change.

The short version

1. Find or open an issue.
2. Branch off the latest main.
3. Make the change in small, clear commits.
4. Open a pull request that links the issue.
5. Get one review, address comments, merge.

The rest of this doc is detail on each step.

1. Start from an issue

Every change starts with a GitHub issue — if it isn't in an issue, it doesn't exist.

• Pick up an existing issue, or open one with the right template (Task / Bug / Feature).
• Assign yourself so two people don't do the same work.
• If you're unsure about the approach, say so in a comment. Agreeing on direction before writing code is cheaper than reworking a finished PR.

2. Set up the repo

Setup steps are repo-specific — follow the README in the repo you're working on. If that README doesn't explain how to run the project locally, that's a bug: open an issue for it.

3. Create a branch

Never commit straight to main. Branch off the latest main:

git checkout main
git pull
git checkout -b <type>/<issue#>-<short-description>

Name branches <type>/<issue#>-<short-description>, where <type> is one of:

Type	For
feat	a new feature
fix	a bug fix
docs	documentation only
chore	tooling, dependencies, cleanup

Examples: feat/142-csv-export, fix/88-empty-filter-crash, docs/30-setup-steps.

Keep one branch to one issue. If you spot unrelated work along the way, open a separate issue and branch for it rather than widening this one.

4. Make the change

• Small commits with clear messages. Write the summary line in the imperative — Add CSV export to dashboard, not added csv export or stuff. Keep it under ~70 characters; add a body when the why isn't obvious.
• Push regularly. A pushed branch is a backup and lets others see your direction.
• Match the surrounding code. Follow the style, naming, and structure already in the file. Run the repo's formatter/linter if it has one.
• Add or update tests for behavior you change, wherever the repo has a test setup.
• Update docs in the same PR when you change how something works.

5. Open a pull request

• Push your branch and open a PR against main.
• Fill in the PR template — the "How to test" section is what reviewers rely on most.
• Link the issue with Closes #<issue#> so it auto-closes on merge.
• Open it as a draft if it isn't ready for review but you want early eyes.
• Keep PRs small — under ~400 lines of diff. Bigger PRs get worse reviews.
• Self-review your own diff first. You'll catch half the comments yourself.

6. Review and merge

• Request review from one specific person, not the whole team.
• As the author: address every comment — change the code, or reply with why not. Don't force-push over a review in progress without a heads-up.
• As a reviewer: respond within one working day, even if it's just "looking tomorrow." Be specific and kind — review the code, not the person.
• Merge once you have one approval and CI is green, then delete the branch.
• We don't merge to main without review. No exceptions.

Reporting bugs and proposing features

You don't need to write code to contribute. Open an issue:

• Bug — something is broken. Include steps to reproduce, what you expected, and what actually happened.
• Feature — an idea or proposal worth discussing before anyone builds it.

Use the issue templates; they prompt you for what reviewers need.

Questions

Ask in the project's Slack channel, or in #all-artpark-hub. Don't ask to ask — just ask the question, and say what you've already tried.

---

Project-specific rules, if any, live in that repo's own CONTRIBUTING.md and add to — not replace — this guide. Suggest edits here by opening a PR. Last updated: 2026-05-19.