Skip to content

Workflow

jmshapir edited this page Jul 20, 2023 · 19 revisions

Our workflow is based on Github flow and assumes you are familiar with the concepts described there.

  • Open an issue.
    • Summarize the goals in the title.
    • Describe the deliverables in the issue description.
      • Production deliverables include modifications to the production pipeline.
      • Ephemeral deliverables are confined to an issue subfolder defined as ./issue relative to the root of the repository.
    • Assign one or more assignees.
  • Work on the issue.
    • Open a linked issue branch
    • Comment whenever
      • you have a question (tagging the person to whom the question is addressed)
      • you have completed a discrete chunk of work
      • you have devoted at least one day of work to the issue since the last update
      • you have not worked on the issue for at least 5 business days since the last update
      • you have a substantive interaction about the issue outside of github (e.g., in a meeting)
  • Open a pull request when the goals of the issue are completed.
    • Assign one or more reviewers.
    • Assign one or more assignees.
      • These are usually the original assignees on the issue.
    • Reviewers review the deliverable.
      • Check for violations of our standards for code clarity and data integrity (production deliverables).
      • Check for clear errors or reasons reproducibility will fail (all deliverables.)
      • Reviewers approve the pull when all pull threads are resolved.
    • Assignees close the pull.
      • Squash-merge the issue branch back to the main branch (production deliverables).
      • Delete the issue branch (all deliverables).
      • Comment in the original issue summarizing what is accomplished and including permanent links to:
        • the latest version of the deliverable (all deliverables)
        • the issue subfolder (ephemeral deliverables)
        • the latest version of the issue branch prior to merging (all deliverables).
      • Link to the summary comment in the pull request.
  • Prioritize work in the order older pull requests > newer pull requests > older issues > newer issues.
    • Age is defined by github numbering.