Development Workflow

Be sure to read general guidelines about issues and Git workflows.

Basics

  1. Start working on an issue you’re assigned to. If you’re not assigned to any issue, find the issue with the highest priority you can work on, by relevant label.
  2. If you need to schedule something or prioritize it, apply the appropriate labels contact the project lead.
  3. If you are working on an issue that touches on areas outside of your expertise, be sure to mention someone in the other group(s) as soon as you start working on it. This allows others to give you early feedback, which should save you time in the long run.
  4. You are responsible for the issues assigned to you. This means it has to ship with the milestone it’s associated with. If you are not able to do this, you have to communicate it early to your manager and other stakeholders (e.g. the product manager, other engineers working on dependent issues). In teams, the team is responsible for this
  5. You (and your team, if applicable) are responsible for:
    • ensuring that your changes apply cleanly against production
    • the testing of a new feature or fix, especially right after it has been merged and packaged.
    • shipping secure code, (see Security is everyone’s responsibility).
  6. Once a release candidate has been deployed to the staging environment, please verify that your changes work as intended. We have seen issues where bugs did not appear in development but showed in production (e.g. due to CE-EE merge issues).

Working in Teams

  1. Teams have a shared responsibility to ship the issue in the planned release.
    1. If the team suspects that they might not be able to ship something in time, the team should escalate / inform others as soon as possible. A good start is informing your manager.
    2. It’s generally preferable to ship a smaller iteration of an issue, than ship something a release later.
  2. Consider starting a Slack or Discord channel for a new team, but remember to write all relevant information in the related issue(s).
  3. If an issue entails frontend and backend work, consider separating the frontend and backend code into individual repositories or modules within a repository. They should be able to be merged independently without breaking production. This will ensure frontend/backend engineers can work and deliver independently.

Product Development Timeline

  • Teams (Product, UX, Engineering) continually work on issues according to their respective workflows. There is no specified process whereby a particular person should be working on a set of issues in a given time period. However, there are specific deadlines that should inform team workflows and prioritization.
logo