---
tags: development process
---

# Process Proposal: Making no-FF feature work feel more like bugs

(Yes, that's a joke)

[Note: all links will be company-controlled and all efforts will be made to avoid proprietary information ... this platform was preferable for this discussion because of its support for dynamic graphing.]

## Thesis: no-FF feature work seeks increased agility while remaining risk-averse, but introducing a new process increases risk of confusion, stalling development.

## Support:
[overview](https://docs.google.com/presentation/d/1rBU70bMWjmBbA0EUVdo9ZIqSnvvmMZU-k1NCs7ROD0w/edit#slide=id.ga781441581_0_2) and [process refined](https://docs.google.com/document/d/1YqhqSYKOSCTR5UxpCJW17dO6MsARu_bLXhk7px7erAY) docs outline a process with significant differences to previous feature work, bugs work, and upstream contribution workflows.

While upstream and downstream work are always likely to differ due to the disparity in demands of their controlling organizations, the same shouldn't be true of downstream feature work versus bug resolution work. Under the new regime, feature work would be tested pre-merge with no supporting automation, and bug work would remain post-merge with pre- and post-merge automation support. Long-term we should standardize on pre-/post-merge.
With relatively small effort though there are some good low-hanging opportunities to reduce workflow friction.

In the diagram below, we model dev/qe interactions to obtain the necessary `qe-approve` label for merge. Lifecycle steps are numbered, team responsibility is demarcated as either 'DEV' or 'QE', and inflection points where flows differ are labeled A..Z. This last category is where we have good opportunity to improve things.
[Note: a similar approach may be derived in support of interactions with other groups, tracked today with `docs-approve` and `px-approve` labels.]

#### Process flow

%%{init: {'securityLevel': 'strict', 'theme':'forest'}}%%
graph TD
   todo -->|starts work| in-progress
   in-progress --> determine-testing
   determine-testing -->|NO: add jira no-qe label, PR qe-approved label| code-review
   determine-testing -->|YES: no special action| code-review
   code-review --> ci-complete-trigger
   ci-complete-trigger -->|YES: prow performs merge| merge
   ci-complete-trigger -->|NO: prow moves jira status to REVIEW, push notify QE| review
   review -->|QE-handoff|tests
   review-TC -->|DEV-handoff: QE adds qe-approved to PR| merge
   merge --> closed
   ci-complete-trigger:::decision
   determine-testing:::decision
   classDef decision fill:#c9f 
   tests:::qeclass
   write-TC:::qeclass
   review-TC:::qeclass
   classDef qeclass fill:#ccf
   subgraph DEV 
      todo[1. jira status := ToDo]
      in-progress[2. jira status := In Progress]
      code-review[3. jira status := Code Review]
      ci-complete-trigger{B: prow: <br/> gh label checks}
      determine-testing{A. QE needed <br/> fa:fa-question}
      review[4. jira status := Review]
      merge[5. PR merge]
      closed[6. jira status := Closed/Done]
   end
   subgraph QE
      tests[4.1 Testing] --> write-TC
      write-TC[4.2 Write Tests] -->|requests tc-approved| review-TC
      review-TC[4.3 Review Tests]
    end
    closed

### Proposed updates
#### A. `QE Needed`:
this is a manual step taken by the assignee to indicate if no QE testing is required for the feature work. (This is likely a remote edge case, but we can't ignore it.) It's possible that we could apply automation based on the `no-qe` label, at the risk of losing details of the individual justifications on the github side.

#### B. `prow label checks`:
current behavior is to test for presence of all necessary labels for merge. There are two potential automations we can consider here.

pre-review:
1. test if valid jira
2. test if no-qe label is present
3. if 1 and 2 are true, then apply the qe-approved label to the PR review

mid-review:
1. test if valid jira
2. test if approved, lgtm labels present
3. if 1 and 2 are true, then if qe-approved label isn't present
1. transition jira to REVIEW status
2. push notification to QE representative as identified in jira