Skip to main content

Development Workflow

Core Principles​

  1. No Work Without a Issue 🎟️

    • All tasks start with a Linear issue

  2. Linear is Our Hub 📌

    • Project discussions and decisions live here

  3. Consistent Process 🔄

    • Follow our issue-to-deploy workflow

TL;DR Version​

  1. Pick an issue from Linear
  2. Create a branch: ENG-[number]-description
  3. Code and commit
  4. Open a draft PR for early feedback (optional)
  5. Open a PR when ready for review
  6. Automated tests run via GitHub Actions
  7. Review, address feedback if any
  8. Merge and celebrate! 🎉

Want the full scoop? Keep Reading 👻​

Issue Lifecycle​

1. Issue Creation​

  • All work begins with a issue in Linear
  • Tickets can be created by any team member, but must be approved by a project lead before work begins

2. Issue Statuses​

Our workflow uses the following statuses:

  1. Backlog: Issues that are not yet prioritized or scheduled
  2. Todo: Prioritized issues ready to be worked on
  3. In Progress: Active development is happening
  4. PR Ready: Code is complete and a pull request is open
  5. In Review: Pull request is being reviewed
  6. Done: Issue is completed and merged
  7. Canceled: Issue is no longer relevant or has been abandoned
  8. Duplicate: Issue is a duplicate of another existing issue

3. Issue Labels​

We use two categories for labels:

  1. Scope (group):

    • Backend: Server-side and database work
    • Frontend: Client-side and UI work
    • Fullstack: Encompasses both frontend and backend

  2. Type:

    • Bug: Errors or unexpected behavior
    • Documentation: Improvements or additions to docs
    • Enhancement: Improvements to existing features
    • Feature: New functionality
    • High Priority: Urgent issues needing immediate attention
    • Tech Debt: Code improvements without changing functionality

Always add one Scope label and at least one Type label to your issue.

Development Process​

1. Starting Work​

  • You will either be assigned a issue or choose/create one yourself.
  • Move the issue to the "In Progress" column.
  • Create a new branch in GitHub following the naming convention:
ENG-[issue-number]-brief-description

2. During Development​

  • Make regular commits with clear, concise messages
  • If you need clarification, add comments to the Linear issue
  • Update the issue description with any relevant information discovered during development

3. Opening a Pull Request​

  • When your code is ready for review, open a pull request in GitHub
  • Name the PR: [ENG-issue-number] Brief description
  • Move the Linear issue to "PR Ready"
  • Assign reviewers in GitHub

4. Code Review​

  • Address any feedback from reviewers
  • Update the PR as necessary
  • Once approved, move the Linear issue to "In Review"

5. Merging and Deployment​

  • After final approval, merge the PR
  • The Linear issue will automatically move to "Done"
  • Delete the feature branch in GitHub

Linear-GitHub Integration​

  • Our Linear project is configured to recognize branch names and automatically link them to tickets
  • PR status is reflected in Linear, updating issue statuses automatically
  • Merged PRs automatically resolve linked Linear tickets

Best Practices​

  • Always check for existing tickets before creating new ones
  • Keep tickets focused and atomic – one issue per distinct piece of work
  • Use clear, descriptive titles for tickets and PRs
  • Regularly update issue status to reflect current progress
  • Include relevant details in issue descriptions (acceptance criteria, technical notes, etc.)
  • Link to relevant resources or discussions in issue comments

Continuous Improvement​

We're always looking to improve our processes. If you have suggestions or feedback about this workflow, please share them.