Skip to content

contributing.md

Latest commit

 

History

History
80 lines (58 loc) · 4.45 KB

contributing.md

File metadata and controls

80 lines (58 loc) · 4.45 KB
Raw

Contributing Guide

Branch Naming Convention

Branch names must start with a prefix that describes the type of change. When a pull request is opened, a GitHub Action automatically applies a label based on the branch prefix. PRs targeting development are required to have at least one label before merging.

Branch prefix Label applied Description
feature/ feat/ enhancement/ enhancement New functionality being added
bug/ fix/ bug Fixes a bug or broken behavior
hotfix/ hotfix Urgent fix for a critical production issue
refactor/ refactor Code restructuring without changing behavior
chore/ chore Maintenance tasks (deps, config changes)
docs/ documentation/ documentation Changes to documentation only
test/ test Adding or updating tests
style/ style Formatting, linting, or cosmetic changes
perf/ performance/ performance Performance improvements
build/ build Changes to build system or CI/CD pipeline
revert/ revert Reverts a previous commit or PR

Examples:

  • feature/taxa-search → labeled enhancement
  • fix/date-picker-timezone → labeled bug
  • docs/update-readme → labeled documentation

Pull Request Workflow

1. Open a PR

When you open a PR targeting development, two things happen automatically:

  • Auto-labeling: The workflow reads your branch prefix and applies the matching GitHub label.
  • Label check: A second job verifies at least one label is present. If your branch doesn't match any prefix, you must add a label manually or the check will fail.

2. Fill in the PR template

The PR template includes a Release Notes section. Write a short, user-facing summary describing how this change affects users of the metadata entry form. This text is used when generating release notes.

Good examples:

  • "Users can now search for taxa using the GBIF taxonomy database"
  • "Fixed an issue where the date picker would lose timezone information"

For internal changes, write "Internal change".

3. Review and merge

Once the label check passes and the PR is approved, it can be merged.

Release Notes

Release notes are auto-generated by GitHub when a new release is created. The configuration in .github/release.yml groups PRs into categories based on their labels:

Category Labels Shown in release notes
New Features enhancement Yes
UX Improvements UX Improvement Yes
Bug Fixes bug, hotfix Yes
Refactoring refactor Yes
Other Changes everything else Yes

The following are excluded from release notes automatically:

  • PRs labeled build, style, test, dependencies
  • PRs authored by dependabot

Creating a release

  1. Go to the GitHub Releases page
  2. Click Draft a new release
  3. Choose or create a tag (e.g., v1.2.0)
  4. Click Generate release notes — PRs will be grouped into the categories above
  5. Edit the generated notes to use the user-facing summaries from each PR's "Release Notes" section
  6. Publish the release

CI/CD Workflows

Workflow File Trigger Purpose
Auto-label and Require Label require-label.yml PR opened/labeled/unlabeled on development Auto-labels PRs by branch prefix, blocks merge without a label
Deploy to Firebase Hosting firebase-hosting-pull-request.yml PR opened, push to development Builds and deploys preview site to Firebase Hosting
Delete Firebase Channel firebase-hosting-delete-channel.yml PR closed Cleans up Firebase preview channel