DisCO - Possible initial directions

(discussion)

Some initial assumptions and notes:

We can put off configuration until later, and just load config data manually, as long as the data structures are there in Bonfire.
We potentially can dogfood in parallel in disco.coop and/or GMC, if we can convert data - but that may or may not be that easy.
The following all include 2 steps, but could be done as just the first step.
If we do a demo app with very simplified UI/UX, then some of the following comments will not apply.
I've left off all the various exchanges, as lower priority. Also the accounting reports.

Planning would be from scratch, not yet from recipe.
Not all of planning is done in Bonfire, but I think all of doing is done.
Planning is a harder UX, but interesting. (See Recipes below.) Planning would need to be an adequate replacement for Trello, which has all kinds of fancy UX. Our planning would be a huge improvement over Trello though, as it will need to include dependencies.
Doing could either involve a timer (like clockify) or entering directly.
For DisCO, we can start with just work inputs, plus whatever needed to get dependencies working.

Calc credits has a lot of work done in Bonfire, but it needs a couple fixes and is not well tested (that was done for DLT4EU proof of concept).
On the other hand, calc credits is relatively easy vs a lot of benefit, especially if we include reporting.
The input is work done, converted or entered in bulk by temporary means. If the latter, besides graphiql, we could implement a very simple Do, just for work events. Or possibly use Bonfire UI, would need to check.
Distribute income needs more analysis or at least documentation on the VF side, and is not in Bonfire at all.
Distribute income is generally not simple, especially as they would probably need some kind of "sandbox" to try it out
Distribute income is a big step forward for DisCO, they have huge headaches now in spreadsheets. It is something not available in any existing software.
Both of these features are basically batch jobs, push a button. But both need a lot of reporting in association with that.

Recipes are not in Bonfire, but maybe they are in process of adding them, need to check.
Recipes are an interesting UX, give an opportunity to try out building a recipe in conjunction with painting the network view, which can be a useful VF visualization in several features. (Planning can be done that way too, above in Plan-Do.)
VF needs an addition to recipes, to identify recipes and give option to fork, and possibly version (or not). This addition is not required for recipes to work, but it would be a good opportunity to add it to VF while trying it out.
Planning is not all in Bonfire.
Plan from recipe would be also backend logic, somewhat complex (and maybe fun).
Doing plan from recipe means we also need to have a way to tweak the plans, unclear if that would basically require full planning functionality, but it might. If so, maybe this is not best to do first.

This is needed for all other features. It includes people, organizations, agent relationships, along with the role definitions.
This needs to include authentication too, and possibly authorization, but maybe authorization can be put off for now.
Bonfire has put this off, and implemented a different structure. So we'd have to coordinate with them a time to do this properly. It involves some thought. And there are other efforts around to do some kind of more universal treatment of this area, which would be good to coordinate with.
We can for now just use Bonfire itself, including the UI to set up people and groups using their current structure. Needs a little thought to see if this would cause problems later to convert.