WizardAmigo - Valueflows mapping

The basic graph structure seems the same, which already makes them mostly compatible (but not completely). Also, the people seem to fit in the same place, and the planning - doing seems to map well. Some base mapping:

WA Project (@todo) >> VF Plan
- WA @info >> VF Plan.note
WA Task >> VF Process
- I could be wrong if some of what WA calls Task are checkboxes without inputs and outputs? I would put the checkboxes without inputs/outputs as a list in Process.note.
WA @input and @output >> VF Commitment (inputs are mostly cite action, outputs are mostly produce action)
- I'm not sure when the resources get named, is that in the original task, or when the file/figma/etc. is actually first created? (Resource is like "TWM UI/UX specification")
WA done >> VF EconomicEvent
- includes time spent and @output reference to EconomicResource produced (in VF it would also fulfill the Commitment)

There are two issues afaict, which might be sort of the same issue, but with 2 effects and 2 solutions.

VF does not support multiple administrative/conceptual containers (could be thought of as super processes) of operational Process/Tasks (only Plan/Project); and VF does not support operational sub-Process/Tasks with their own inputs and outputs. (A VF Process is roughly defined as transforming inputs into outputs.)

First issue

VF assumes that the operational input-process-output graph can be modeled all at the same "level", i.e. can be one big flat graph if everything is connected. It does not support sub-processes, because it makes the graph not-really-traversable.

So, first of all, can WA's input-process-output graph be represented in this way? Possibly not now, but I think it could be with a few tweaks, which seem like they might be helpful anyhow (to me).

Let's take this as a example: https://github.com/wizardamigos/wizardamigos.github.io/issues/111, "Tiling Window Manager UI/UX concept & design". This has a series of processes, iterations of creating specification and a figma file. In the middle are a set of sub-component designs, which (I think) are put on the figma file. (True?)

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

…

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

Here is the first sub-task. It knows its larger parent project ("tracked by").

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

I drew out part of this example, enough to think about it. I expected to find inputs that came from a parent task and outputs that eventually went back to a parent task. But I didn't.

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

If this were in VF, we would want to know the input-process-output relationships between those two disconnected pieces, not just that there is a sub-process kind of relationship. So maybe all the outputs of sub-component designs get input to the figma file (maybe containedIn so there is also a relationship between parent and child resources?).

Would that make sense in WA?

Second issue

This issue is the groupings or process parents of tasks that are created to help organize the work.

Below is how I think those could be handled. (This model assumes a task is only in one group, it would need additions to make a task appear in multiple groups/parents.) The blue is not (yet) in VF. It (or the more complex version) could be added to VF, or could be added just in WA's software.

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

I think the WA Project is conceptually like the VF Plan, and it doesn't make sense to have smaller Plans in WA. So this suggests adding an optional but flexible set of parent-child ProcessGroups that do not have inputs and outputs themselves, but are there to help see the organization of the work. They in between Plan and Process.

If you built the UX starting at the bottom, there would be a big graph of input-process-outputs. If you built it from the top, it would be more like what WA has now, where included tasks can appear on different levels or issues. If it supported multiple groupings, people could find what they care about using the view that fits best (like project manager or designer). Or alternatively, those different views could be reports, based on the person doing the work, or the type of resource (like all components within a project, etc.).

Alexander Praetorius

2022/11/22 18:58:56

WA @info >> VF Plan.note *

there is no `@info` anymore in the latest version of our system it is now considered an initial `@input`. This will be reflected in the next release of our "video documentatin" of the system :-) (Edited)

2022/11/22 19:00:18

without

tasks always have at least one output, unless they are a "sub task group", in which they all feed into the same output of their parent task. tasks also might not look like they have an output if they are issues, because the output is described not next to the linked task, but is instead described or listed on that tasks issue itself, so you need to follow the link to see it (Edited)

2022/11/22 19:09:22

WA @input and @output >> VF Commitment (inputs are mostly `cite` action, outputs are mostly `produce` action)

is it? so far i perceived inputs and outputs as resources or resource specifications, where :question: emoji means its a planned resource specification recipe resource? and :package: means its the link to the actual existing input or output resource. action is maybe something explicit - i am thinking of inputs/outputs as nouns/things i am thinking of actions/verbs as tasks ...but maybe you know better and what you say here is correct :-) (Edited)

lynnfoster

2022/11/23 22:26:53

I think the inputs and outputs in VF as events with resources (or resource specifications). So both. The events relate to the processes (they are the inputs and outputs), and they say what happens to the resource. Like it gets consumed, used, produced. It's sort of in between the task/process and the resource.

2022/11/23 23:38:01

so technically we have that too. you see tasks and inputs/outputs But every time a change happens, we create a message that causes changes in regards to tasks or inputs or outputs. Those messages go into the channel associated with each task and/or channel associated with each resource (input or output)

2022/11/22 19:11:32

I'm not sure when the resources get named, is that in the original task, or when the file/figma/etc. is actually first created? (Resource is like "TWM UI/UX specification")

An input/output usually starts as status: planned then when all inputs exist their status is: package and when an output was created also it's status becomes :package: only when there is a sub task group which all feed into the output of their parent task and have seemingly no outputs of their own, then finishing the first task in a sub task group can put a "planned" output into a "work in progress" output using the :factory: emoji symbol and once the last sub task in the group is done and the (Edited)

2022/11/22 19:11:58

...output exists, the status is again updated to :package: :-)

2022/11/23 22:28:19

OK. Do you name any of the resources before they exist?

2022/11/23 23:39:41

yes, they start as "planned" (:question: emoji) inputs or outputs ...this is at the moment not associated with any "specification" The person doing the work and the task that has it as an output are meant to describe it well enough. if more information is needed, a specific specification document could be linked as just another input document into the task that produces the output

2022/11/22 19:20:21

includes time spent and @output reference to EconomicResource produced (in VF it would also fulfill the Commitment

every **CHANGE*, which means 1. making tasks 2. changing tasks or marking them as done 3. removing tasks 4. adding inputs or outputs 5. changing intputs/outputs or switching status 6. removing inputs/outputs are always triggered by **triggering message** e.g. a feedback comment e.g. a worklog comment e.g. any other changing "action" They all go into an accounting/audit log to clearly proof what was triggered by whom and when, etc... (Edited)

2022/11/23 22:30:23

Not sure I understand, but I'll look again. Also, removing the "WA Task" in what I wrote, that is just wrong.

2022/11/23 23:41:58

not sure what you mean with "removing WA Task" What i wanted to say above is, that the long list of comments below a github issue is theoretically supposed to add some sort of message (=comment) to reflect any change to the tasks/inputs/outputs in any way. In practice - if we edit the top level comment to change tasks, there is sometimes no entry in the long list of comments that contains that changeset that somebody applied to the top level comment and it's tasks ...github doesnt do that

2022/11/23 23:42:50

but an optimized software would do it and we have a convention that any change should ALWAYS have a comment that describes that change before it is applied - so it is just our lack of discipline that it is not always entirely the case sadly, but we are trying hard :-)

2022/11/22 19:22:40

lso fulfill the Commitment

every task is assigned at some point to a person and that assignement or invitation or a person applying for a task has to be **accepted** (yet another "triggering message" for the application or invitation) (yet another "triggering message" for the acceptance or rejection of that offer) ...they are all accounted for in the accounting/audit log(s) e.g. a fullfillment is therefor represented by e.g. the status of an output changing from :question: to :package: or a task going from open to done. (Edited)

2022/11/23 22:31:18

2022/11/22 19:25:50

To me or us, what matters is: 1. contractual consent (invite/application -> accept/reject) 2. outputs getting produced at some point, directly or indirectly 3. everything being transparently tracked (accounted for) so any "compensation" or "share/reputation/status" can be based on those "audit logs" everything else is a means towards that end... and we want it to be as flexible as possible and low overhead and no unnecessary complications. (Edited)

2022/11/23 22:34:14

2. and 3. are a good fit with VF. 1. I think that is when people accept a task? In VF that is a Commitment, so would be separate on each input and output. We'd have to work through what would be best fot that for WA.

2022/11/23 23:46:12

in our case the first message in a github issue where somebody gets invited or applies should always be that comment and then the invited person would respond with an "accept/reject" comment. alternatively if a comment was made by somebody to apply for the task, a feeback comment would "accept/reject" the terms and conditions ...before any work starts. At the moment we skip this because github mandates to invite somebody to a repository and if they ACCEPT they can then be assigned to an issue

2022/11/22 19:29:53

this is supported by our system too. in fact, looking at the raw input/output relations it is. but inputs and outputs do not reflect the process that caused them, which doesnt matter once the outputs exist, but it matters for planning and doing and it matters for accounting for compensation or status/reputation etc... and we feel most natural is to have a flexible system to allow people to structure their work in the way they really discuss, agree and do tasks so we can track effort (Edited)

2022/11/22 19:30:43

...track it in the exact way people thought and talked about it so the audit logs feel meaningful to them so they "justify" the compensation or the likes that might get derived from them later on

2022/11/23 22:35:09

ok, good

2022/11/22 19:31:04

yes the raw input/outputs can (Edited)

2022/11/22 19:39:38

yes kind of. our contrators or the tooling (github) is sadly not perfectly following the theory, but we are getting better at it. the app we are building will help us to be way more strict, because it won't allow to deviate from the formal structure (Edited)

2022/11/22 19:41:09

I expected to find inputs that came from a parent task

inputs can come from any task and do not have to come from an immediate parent or predecessor task. inputs can come from arbitrary tasks in the project. THOSE relations define the actual input->output ...chains or networks (Edited)

2022/11/23 22:36:53

got it! I think we're compatible then

2022/11/22 19:43:18

outputs that eventually went back to a parent task

outputs do not have to be used in parent tasks. it might be actually often the case, the way tasks and sub tasks are structured corresponds to that, but is absolutely not necessarily the case. We do not have a good visualization to show only the inputs->outputs->inputs->outputs networks, which are implicit in the task structures created based on how things are linked up (Edited)

2022/11/22 19:46:24

we would want to know the input-process-output relationships between those two disconnected pieces

yes. they are connected. the popOvers are an input to a higher level component. and so on. BUT, it is not yet expressed in the plan. As soon as we create the tasks or refine the task for the`tabs container component` which is itself a main component of the `tiling window manager` itself (next to the `tile component`) ...we will need to make `popOvers` an `@input` of the `design tabs container` task. that should have, but hasnt happened yet, which is why things are disconnected (Edited)

2022/11/22 19:47:55

Ideally, a project is planned from start to finish before we get started. sadly that: 1. takes A LOT OF TIME 2. when things are "further along" and the clear parts have been solved (the parts that are well understood), then that can help to specify the later parts of the project ... the longer we wait, the more information we have (Edited)

2022/11/22 19:48:56

...but yes, if we had better tooling support, we could sketch out the entire plan as we roughly know it already, which means popover would be an input to the tabs container task ... and then just modify it once we change our mind. This is extra effort and that is what i mean that the issues sadly do not fully live up to the theory yet, but we are getting better :-) (Edited)

2022/11/22 19:51:29

a task group is basically a list of tasks that feed into the parent output, not because this is reality, but it is not worth the effort of modelling it in more detail to capture intermediate changes seperately... (Edited)

2022/11/22 19:51:59

our system allows us to always increase resolution of tasks with more sub tasks if we need too, for example in case a task turns out to be more complex than thought of initially, but if a skilled person manages to do something quickly in one go we e.g. log one hour of work on something and call it a day instead of over modelling things more atomically, because there is no border all the way down to the molecules and atoms of the universe and their interactions...

2022/11/22 19:54:13

and it doesn't make sense to have smaller Plans in WA

in fact, a project which is independent and has no "super issues".... e.g. the entirety of WIZARDAMIGOS in which "tiling window manager" is a smallish sub project ....can become and actually already IS a sub project of a much larger project called "Play project" :-) Https://playproject.io ...which has it's own github issues and one of those has a portfolio issue where wizardamigos as an organisational project is listed. (Edited)

2022/11/22 19:55:08

again, playproject itself has many partners or enighbouring projects in it's ecosystem which we call (dat-ecosystem) where it has a seat in the dat-ecosystem consortium ...and many relations or links of intputs/outputs to other organisations can be drawn or made linking it into an interconnected task network of projects in the entire ecosystem and beyond

2022/11/22 19:56:06

SCOPE is arbitrary and mostly related to organisational boundaries or e.g. a datdot task, a playproject task, a wizardamigos task, a dat-ecosystem task .... or even in sub projects based on the people who lead it

2022/11/22 19:56:33

but tasks and inputs outputs and the way they are linked don't know these boundaries and can effortlessly link across those boundaries on other github organisations and projects

2022/11/22 19:58:23

If you built the UX starting at the bottom, there would be a big graph of input-process-outputs.

yes, but that is only inputs -> outputs. but at any point in time, a task can split into more tasks and an input->output can increase resolution and insert many intermediary inputs/outputs in between ...depends if you want to go all the way down to model interaction of atoms and molecules so to speak... (Edited)

2022/11/22 19:59:38

to task is ever reliably atomic, but only atomic at the moment for the resolution we chose to deal with ...and we have somebody finishing the task and book the time and call it a day or "an hour" :P ...summarizing a slice of reality in space and time and labeling it for the purpose of documenting history and deriving eventual compensation later on

2022/11/23 22:41:43

Yes! Granularity is an art sometimes, yes? All works for us, as long as output resources can be used as input resources.

2022/11/23 15:01:00

OK excellent. Then it looks like WA will want a graph where everything at least can be connected if it is connected. (Edited)

2022/11/23 22:37:57

I don't see any problem with adding to the plan as you are working on it though. It's hard with or without tools to plan everything exactly. (Edited)

2022/11/23 22:40:20

Got it. Makes sense that at some point they are organizations (bigger, longer term, more permanent team). (Edited)

2022/11/24 17:34:55

This is something we don't really have. Except as text in the EconomicEvent. Sometimes we have talked about something like that.... (Edited)

2022/11/24 17:36:08

I just took out the part that was wrong, so it is gone. Don't worry about it any more, I just thought I might have caused some confusion. (Edited)

2022/11/25 12:33:18

got it (Edited)

2022/11/25 12:38:08

Understand. When the REA playspace is in a little better shape, you can try it out if you want to, for fun. It's the first actual visualization tool we've seen for VF that does CRUD. (Edited)

WizardAmigo - Valueflows mapping

First issue

Second issue

Read more

Carbon Farm Network Software Plan 10/24

Offers/Needs Dashboard

Whole Economy Thoughts

VF map to Commitment Pool