# Kalo - Maintenance Mode
The Kalo FMS is currently the thing which makes Kalo money, but as we look to the future we want to ensure that we don't spend all our time trying to support it.

So, how is this going to work?

## What?
Current tickets held in the the backlog are to be found at https://kalohq.atlassian.net/secure/RapidBoard.jspa?rapidView=29&projectKey=COMM&view=planning.nodetail

From an engineering perspective we consider maintenance mode to be the way in which we keep the FMS being a product that existing customers can continue using.

In general they fall into one of the following buckets:

* actual bugs/regressions on the platform (example - https://kalohq.atlassian.net/browse/COMM-988, team owners can add org owners)
* problems tied to a single, or very specific set of users (example - https://kalohq.atlassian.net/browse/COMM-1014, a user from the Virgin Isles is having problems registering via the HyperWallet API)
* fixing mistakes/mis-assumptions (example - https://kalohq.atlassian.net/browse/COMM-1041, DocuSign contracts lost when switched to EchoSign)
* data fixups (example - https://kalohq.atlassian.net/browse/COMM-668, incorrect URLs leading to incomplete signups)

### Questions

1. What's the main driving force behind maintenance mode? Customers or increased metrics?
2. Do we bring the concepts of PLG to maintenance mode, or are we working across a couple of models of product AND customer growth?
3. Are we presenting an "official/supported Kalo" with the majority of bells and whistles the existing customers get removed? Can these be our key transactions - https://hackmd.io/C4vaYqy5R1ifCkPRxzjOWA ?
4. How pro-active should we be - have have lots of visibility into application errors in Sentry, should we take these into account for stuff we work on?

## Who?
This is going to need both a product and technical owner (even if on a part time basis):

* product owner - ??
* technical owner - Lewis

The owners main role is to understand, scope and apply priority to requests when they come in.

## When?
Triage as required through out the week.

People needed for urgent/on-the-spot fixes.

Larger fixes need the whole team - dedicate a day every two weeks?

Breaks down to (with the potential for another 40 hrs spare - on assumption that a fortnight is 160 hrs eng time):

* Lewis - 40 hrs
* Parry - 40 hrs
* Lee, Tom, Darren, Olle, Morgan - 8 hrs

## How?
In order to understand the value in the work we do then we need some non-personalised form of ranking. Our initial effort to create this is: https://docs.google.com/spreadsheets/d/14gXsgfrHyZlPHSuKOzniIZi6j1ggBOQtvpIn4WvOCNs/edit?usp=sharing as maybe a starter?

### Potential reasons for changes

1. money? how much money?
2. reasons for churn (if indeed a thing)
3. what discussions have been made around alternatives
4. making the product simpler (removal of as many crufty or single usage features as possible)

## What does a maintenance mode fix look like?

This is an example which Simon defined - https://kalohq.atlassian.net/wiki/spaces/ENG/pages/676593699/Maintaining+the+FMS+Example+from+COMM-1016

* Updating dependencies
- [high severity] security fixes
- avoid extra features, new vendor libraries
- avoid API breaking changes

### Other Examples
- https://github.com/kalohq/hyperwallet-sdk/pull/3
- https://github.com/kalohq/frontend/pull/4023
- https://github.com/kalohq/frontend/pull/4024
- https://github.com/kalohq/lws/pull/5393
- https://github.com/kalohq/lws/pull/5372

[ getting faster feedback from CS - (NYC?) ]
[ fitting around existing workload? ]