Technical Spike - refactor billable users calculations

Process:

  1. Write the spike summary and requirement and select Definition of Done (DoD) questions that apply
  2. DRI/s are assigned to the spike
  3. Before starting the spike, engineer should confirm:
  • Is the problem statement and description of the problem clear
  • Are the requirements of this spike clear
  • Are the Definition of done questions relevant/reasonable for this spike
  1. Engineer does an investigation to gather information and note any initial impressions and possible paths for implementation
  2. PM/EM/Collaborators + Engineer asks questions and start to narrow the scope to an appropriate solution/implementation
  3. DoD questions are answered
  4. DRI confirms next steps and the spike issue gets closed

Summary

Spike DRI/s: @tanuki

Over in Streamline billable users calculations (#338253 - closed) issue, our estimation raised concerns that the original issue may benefit from dedicated time to further investigate a technical solution and perhaps PoC of refactoring billable users calculations.

Briefly, we reference Billable Users in various pages in self-managed, but they use difference methods for calculation. These subtle difference in calculation both on update frequency and usage throughout the application cause confusion for customers and internal team members alike.

Goal

  • Determine if we can unify how we calculate billable users for SM in the codebase

Outcomes

  1. identify all the various places/methods in which we currently work with/calculate billable user counts
  2. identify reasons for differences and whether they can be unified
  3. review performance tradeoffs of one method vs the other (e.g. UserStatistics#billable sums 4 different queries, User.billable performs one query)
  4. create issues if appropriate (it maybe possible to do them all in one issue but depends on the outcome of 👆🏽)

Requirements / Ask

What problems should this feature solve?

  • Determine if we can unify how we calculate billable users for SM in the codebase
  • produce a proposal and issues if appropriate as artifacts of the spike see outcomes above.

Definition of done

What questions need to be answered in order for this spike to be completed - tick all those that apply:

  • Is the ask possible?
  • What are the possible implementations / approaches?
  • What are the possible iterations / how can this implementation be broken down into smaller features?
  • Is the work reasonable within time constraints?
  • What is the level of effort (t-shirt size estimate: S,M,L)?
  • What are the risks / trade-offs?
  • Where does complexity exist?
  • Are there any unknowns to be mindful of?
  • What is your confidence level in this implementation?
  • Is there technical debt to consider or being created?
  • Is there a skills gap? Have we used this approach before? Are there any documented reports of using this approach?
  • Is there a monitoring implication?
  • Is there an availability implication?
  • Is there a productivity implication?

Next steps

Select the next steps that apply:

  1. Close issue without further action = Spike conclusion is that feature won't be built
  2. Create follow up issue to start MVC iteration of feature
  3. Create MR for documentation update as a result of spike
Edited by Chase Southard