Skip to content

Dev process

github-actions edited this page Jun 5, 2024 · 2 revisions

The following outlines the dev process from creating to releasing features.

On this page:


πŸ”„οΈ Issue lifecycle

  1. Author creates new issue

    Assign to reviewer
    βž• Needs: Triage πŸ”

  2. Reviewer notes issue is a duplicate with #duplicate in a comment

    βž– Needs: Triage πŸ”
    βž• Resolution: Duplicate

    1. If no updates after 7d...

      Close issue

  3. Reviewer asks author for details with #needs-info in a comment

    Assign to author
    βž– Needs: Triage πŸ”
    βž• Needs: Information

    1. If no updates after 14d...

      βž• Needs: Attention πŸ‘‹

    2. If no updates after 28d...

      Close issue
      βž• Resolution: No activity

    3. If updated within 35d...

      Reopen issue
      βž– Needs: Information
      βž– Needs: Attention πŸ‘‹
      βž– Resolution: No activity
      βž• Needs: Triage πŸ”

  4. Author adds details in comment

    Assign to PM
    βž– Needs: Information
    βž• Needs: Triage πŸ”

  5. Reviewer approves with #approved in a comment

    Remove assignee
    βž– Needs: Triage πŸ”

  6. Reviewer assigned βž• Status: ✍️ Spec in progress
  7. Reviewer creates "Spec review:" PR

    βž– Status: ✍️ Spec in progress
    βž• Status: πŸ”­ Spec review

  8. "Spec review:" PR closes

    βž– Status: πŸ”­ Spec review
    βž• Status: ▢️ Ready

  9. Dev assigned

    βž– Status: ▢️ Ready
    βž• Status: πŸ”„οΈ In progress

  10. Dev creates PR

    βž– Status: πŸ”„οΈ In progress
    βž• Status: πŸ”¬ Code review

  11. PR closes linked issue

    βž– Status: πŸ”¬ Code review
    βž• Status: πŸ“¦ Pending release

  12. Issue included in a release

    βž– Status: πŸ“¦ Pending release
    βž• Status: βœ… Released


πŸ“‹ Triaging issues

The goal of triaging is to ensure issues in the backlog are valid and have the necessary details for someone to start working on them. The following rules apply for triaging all issues:

  • Each issue should only have one Type: * label. Do not assign a t ype for simple change requests.
  • Add applicable Area: * labels by leaving #ARM, #ADF, and/or #PBI comments.
  • Do not assign issues to anyone unless they are actively working on the issue.
  • Only assign milestones when proposing work for a near-term release.
    • Use the vNext milestone for stretch work.
  • If you do not have enough details to triage the issue, leave a #needs-info comment and message for the author.
  • Add the Good first issue label if it's a good task for someone new to the project.
    • Good first issues should only contain one small change that can be contributed independently.
    • If you feel an issue needs more details for a newcomer to pick it up, add the Needs: Information label and assign it to a dev to provide details.
  • After triaging, add an #approved comment and thank the author.
  • Don't be afraid to say no, or close issues. Just explain why and be polite.
  • Don't be afraid to be wrong. Just be flexible when new information appears.
  • Explicitly @mention relevant users when you think the issue needs their attention.

πŸ”„οΈ Pull request lifecycle

  1. Author creates new PR against main branch

    Assign to author
    Leave comment about no PRs to main policy
    βž• Status: β›” Blocked
    βž• Needs: Attention πŸ‘‹

    1. If no updates after 7d...

      Close issue

  2. Author creates new PR

    Assign to reviewer
    βž• Needs: Review πŸ‘€

  3. Reviewer requests changes

    Assign to author
    βž• Needs: Attention πŸ‘‹

    1. If no updates after 28d...

      Leave comment about needing to update
      βž• Resolution: No activity

    2. If no updates after 56d...

      Leave comment about closing due to no activity
      Close issue

    3. If updated within 70d...

      Reopen PR
      βž– Needs: Attention πŸ‘‹
      βž– Resolution: No activity

  4. Author responds with a comment or pushes changes to the PR
    • Can we check to see if there are pending comments?

      Remove author as assignee
      βž– Needs: Attention πŸ‘‹

    1. If no updates after 28d...

      Leave comment about needing to update
      βž• Needs: Attention πŸ‘‹
      βž• Resolution: No activity

    2. If no updates after 56d...

      Leave comment about closing due to no activity
      Close issue

    3. If updated within 70d...

      Reopen issue
      βž– Needs: Attention πŸ‘‹
      βž– Resolution: No activity

  5. Reviewer approves

    Assign to author
    βž• Status: ▢️ Ready
    βž– Needs: Attention πŸ‘‹

    1. If no updates after 28d...

      Leave comment about needing to update
      βž• Resolution: No activity

    2. If no updates after 56d...

      Leave comment about closing due to no activity
      Close issue

    3. If updated within 70d...

      Reopen issue
      βž– Needs: Attention πŸ‘‹
      βž– Resolution: No activity