Skip to content

Workflow ​

Notion ​

We use Notion to manage our tasks.
Each task will have an ID for easy reference later.

These are the statuses a task can have and a short description of their purposes:

Grooming Stage ​

  • New πŸ†•
  • Needs Clarification πŸ€”
  • Needs Scope πŸ“

Ready to Be Worked On ​

  • Task Created πŸ“‹
  • On Hold πŸ•‘

Working ​

  • In Progress πŸ‘¨β€πŸ’»
  • Ready For Review πŸ”

Testing ​

  • Ready QA Test β˜‘οΈ
  • Needs Improvement πŸͺ›

Shipping ​

  • Pending Deploy [DEV] ⏳
  • Pending Release [PROD] β˜‘οΈ

On Production ​

  • Done 🏁

GitHub ​

Here is the convention to create a branch:

{taskId}-{type}/{shortDescription}

Example: A task to implement Donation at the shopping cart flow.

TASK-999-feat/add-standalone-donation-to-cart-flow

Locally, this is a good example of a day-to-day flow:

  1. Understand the task scope
  2. Sync your local branch with development
  3. Create a new branch for the task
  4. Develop the task
  5. Build it locally
  6. Test to make sure everything is working as expected
  7. If it's a small task, take a screenshot of the result. If it's not, record a short Loom explaining the result.

When it's time to push the PR: ​

  1. Push the PR
  2. Fill in the template
    2.1. You can give the template and commit messages to ChatGPT to help fill it in. Review the result to ensure it's meaningful and correct.
    2.2. Don’t forget to upload your Loom or image to the results section.
    2.3. If the PR has anything specific to the feature, include it in the Release Notes. Also, if it depends on another repository’s PR (e.g., API), add a link to that PR in the Release Notes section.
  3. Add your reviewers
  4. Add the label Ready for review
    4.1. Because the GitHub status for this is not very visible
  5. Update the status on Notion

From here forward, it's up to the reviewer to keep the task status updated. If it returns for changes, the responsibility goes back to the PR creator.

βœ… Happy Path ​

  1. Reviewer finishes the review, approves it, adds the Ready QA Test β˜‘οΈ label, and updates the Notion status.
  2. QA tests it locally. If all is good:
  3. QA merges it, tests it on development, and adds the Pending Release [PROD] β˜‘οΈ label.
    3.1. There are usually multiple PRs, so QA repeats the flow for all of them.
  4. Once everything is good, QA creates a release PR from development to master. After a final code check, QA merges it.
  5. QA updates the Notion status to Done 🏁.

⚠️ Not-So-Happy Path ​

If changes are required or QA testing fails, these flags should be used:

  • Needs Improvement πŸͺ›

These flags should be reflected on Notion, where QA can leave a message detailing what needs to be fixed. The reviewer will also leave this feedback in the GitHub review.

When one of these flags is present, we should also add the blocked label to make the issue more visually clear.