@@ -204,34 +204,78 @@ For guidance on using comment templates, please refer to our [Comment Templates
## Technical exploration ("Spike") guidelines
Occasionally, the team will be asked to dedicate time to exploring or "spiking" a technical solution to a problem or opporunity area deemed a priority by Growth PM. Technical spikes are fundamentally different than our typical work items as the result is more commonly a recommendation on a technical direction or solution (in the form of additional epics and/or issues) rather than code, yet they still require dedicated developer focus and should be accounted for in our development workflows. As such, we've determined the following guidelines and responsibilities for individual Growth Engineers to follow when addressing a techincal spike in our workflow:
Note: As of Q2 FY25, technical spikes will follow the same workflow process as code-based issues - they will enter `~workflow::refinement`, then be scheduled and prioritized for pick up in `~workflow::ready for development`. Active technical spike work will be represented in `~workflow::in dev`. Once outputs are completed, the technical spike issue will be closed and moved to `~workflow::complete`.
Occasionally, the team will be asked to dedicate time to exploring or "spiking" a technical solution to a problem or
opportunity area deemed a priority by Growth PM. Technical spikes are fundamentally different than our typical work items
as the result is more commonly a recommendation on a technical direction or solution rather than code, yet they still
require dedicated developer focus and should be accounted for in our development workflows. As such, we've determined
the following guidelines and responsibilities for individual Growth Engineers to follow when addressing a technical
spike in our workflow:
Note: Technical spikes will serve as the single source of truth for implementation and will have one of three outcomes:
conversion into a development implementation issue, promotion to an epic with additional implementation issues, or
I -->|Not Feasible| J[Close Issue with Explanation]
I -->|Feasible| K{Scope Size?}
K -->|Small Scope| L[Convert to Implementation Issue]
K -->|Large Scope| M[Promote to Epic & Create Implementation Issues]
L --> N[Move to workflow::solution validation]
M --> O[Epic enters workflow process]
```
**Inputs**
As a technical spike is prioritized and available for pickup in `~workflow::ready for development`, complete the following steps:
- Assign yourself to the technical spike along with the current milestone
- If not already added, add the ~spike label to the issue.
- Connect with the responsible PM to align on a reasonable due date for the technical spike. Duration will be dependent on the subject matter and Growth's familiarity with the topic.
- Once determined, assign a due date.
- Review the contents of the technical spike issue body. Add a comment to clarify outstanding questions with the responsible PM. This is a great time to highlight potential needs for cross-collaboration with other teams or code or Product subject matter experts, or other inputs you feel will be important to the technical spike.
- If possible, add a comment with a proposed plan for how you intend to address the spike and whether any PM checkpoints, etc. would be desired.
- Assign yourself, apply ~spike label, set the milestone and set the workflow label to `~workflow::in dev`
- Connect with the responsible PM to align on a reasonable due date for the technical spike and assign it accordingly.
Duration will be dependent on the subject matter and Growth's familiarity with the topic.
- Review the contents of the technical spike issue body.
Add any comments to clarify outstanding questions with the responsible PM.
Identify potential needs for cross-team collaboration, subject matter expertise, or other important inputs for the
technical spike.
- Add with your proposed approach and note any desired PM checkpoints.
**During the technical spike investigation period**
- Communicate any relevant learnings or discoveries that could impact duration or scope needed for the spike with the responsible PM
- If you are nearing the assigned due date and will be in need of more time for the investigation, reach out to the responsible PM to align on next steps
- Document your progress with detailed notes to support our async collaboration model and maintain an inclusive environment.
- Share any discoveries that might impact the spike's duration or scope with the responsible PM.
- If approaching the due date and needing more time, proactively discuss next steps with the responsible PM.
**Outputs**
As the technical spike work comes to a completion, complete the following steps to close out the spike process:
- Provide a summary comment with detailed learnings of your investigation and recommended path(s) for the solution in the spike issue. Include an outline of the recommended next step issues and/or epics to be created for the next phase of work.
- Provide a summary comment with detailed learnings of your investigation and recommended path(s) for the solution in the
spike issue.
Include an outline of the recommended next step issues and/or epics to be created for the next phase of work.
- Tag in the responsible PM, EM, and Growth Engineering team (`@gitlab-org/growth/engineering` team) for review.
- Confirm with the responsible PM that the spike requirements have been met within the alotted duration time.
- Move the technical spike issue to `~workflow::complete`.
- Close the technical spike issue.
- Confirm with the responsible PM that the spike requirements have been met within the allotted duration time.
Based on your findings, proceed with one of these three outcomes:
1.**For technically infeasible solutions:**
Close the issue with a clear explanation of the technical limitations discovered.
2.**For single-issue implementations:**
Refine the technical details in the current issue and move it back into `~workflow::solution validation` for PM guidance.
3.**For multi-issue implementations:**
Promote the spike to an epic and create the necessary implementation issues to break down the work.
As the engineer who performed the spike, you are responsible for creating these implementation issues.
For outcomes 2 and 3, ensure technical details are sufficiently documented to support implementation once it re-enters later
