Evolving change
Entities on CommonOutcomes are bound to evolve, reflecting both the iterative process of co-modelling and the changing the nature of the world itself. This entry lays out the ways in which the evolution of changes and their relations are made possible on the platform.
Status
If we imagine a simple linear process from inception to (un)realisation, we can outline several broad phases in a change's progression:
- draft: the wording or connectivity of the change still need more work.
- live: the change is ready for fuller consideration and eventual evaluation.
- realised: the change was realised.1
- unrealised: the change was not realised and is not considered anymore.2
These different steps constitute the different values possible for the status property required for each change.
Version history
Keeping a version history of each change and implication is essential for co-modellers to ensure transparency of edits to all co-modellers. This makes the iterative nature of the editing process visible to co-modellers who can easily compare different versions in time.
Merging and branching out
Allowing to branch out from a change would enable the creation of new changes from old ones, whether to create alternatives to the original or simply new changes stemming from old ones.
Conversely, various changes may have been developed independently while referring to the same thing. In that case, they could benefit from being merged for clarity and efficiency.