Development Workflow - acl-services/paprika GitHub Wiki

Development on Paprika happens directly on GitHub and is open to outside contributors in addition to Galvanize developers and contractors. All contributors, including core members are required to follow the same pull request and code review process.

Outside contributors will need to request access before they will be able to push a branch to the GitHub repository.

Workflow

The typical development workflow will include:

  1. Follow the Getting Started Guide to setup the development environment.
  2. Create a feature branch.
    • For Galvanize developers: [jira-ticket]--[description-of-change-in-kebab-case] (ex. UX-555--new-hot-button).
    • For outside contributors: [OC]--[description-of-change-in-kebab-case] (ex. OC--new-hot-button).
  3. Write some code.
    • Become familiar with Paprika Coding Conventions.
    • Recommended: When describing your commits, adhere to standards for Conventional Commits.
    • Ensure there are no linter errors and that the code has been formatted by prettier before making a commit.
      • yarn lint / yarn lint:fix and yarn prettier / yarn prettier:format
      • Husky git hooks are triggered on git commit and git push and will block if errors are found by eslint, prettier or jest (unless the --no-verify flag is added).
    • Recommended: Setup your editor to use eslint and prettier plugins.
    • Add Storybook stories as needed (contributors are not required to follow standard practices or conventions in Storybook, but are encouraged to take inspiration from existing curated stories).
    • Please take accessibility considerations into account.
    • Please split large changes into smaller pull requests if possible (<500 lines ideally, but this is not a strict rule).
    • CI (Semaphore) will be triggered on git push.
  4. Run automation tests locally to verify there are no failures.
    • yarn test and yarn cypress:dev
    • Add tests where appropriate.
  5. Open a pull request.
    • The title of the PR should include the Jira ticket number (or OC) and a succinct description of the change.
    • Fill out the PR description template — replace all italicized placeholder text and remove sections if they are not relevant.
    • Important: describe changes according to Semver conventions for ALL modified packages.
    • Be sure to include the URL for the branch's Storybook on s3 (ex. storybooks.highbond-s3.com/paprika/UX-555--new-hot-button).
    • If the PR addresses or resolves one of the Paprika issues, be sure to include it in the description.
    • For Galvanize contributors:
      • Include instructions for how to manually test the changes in the Jira ticket description under a heading "How to Test".
      • Post the PR in Slack in the #paprika channel.
  6. Address comments, suggestions and requests from reviewers.
    • It is reasonable to defer to a later PR if the request expands the scope beyond the original purpose for the PR.
    • Please capture deferred requests or suggested improvements in a GitHub issue.
    • Defend your opinions and keep conversations productive and respectful.
  7. Merge.
    • Approval from a Paprika core member is required to merge a pull request. To be approved, the PR must:
    • Once approved, if there are no conflicts, go ahead and merge to master.
  8. Hooray! 🙌 You've contributed to Paprika! 👏 🙇‍♂️