Valueflows vs Git

2022/08/01 after meeting: Thoughts while working with Dyne on FabCity mapping from creating open hardware designs in a git repo. First thoughts in a diagram, noting that any of the processes could have other events, thinking mostly about work contributions and citations of other work like libraries, atm. This diagram also assumes we are basically talking about the remote repo as the resource, not the cloned copy on local PCs. That may turn out to be wrong.

Question: Do we basically want to create VF artifacts from git commands? I'm thinking there is a lot of variation even in each command, as well as teams have different workflows. Also, things can happen directly in the remote, such as creating a new repo. It seems quite a bit more complex than Adam's table, although I'm sure it is do-able.

Question: How many of the git commands are recorded in the remote repo? Certainly everything that is part of a merge will be there (commits for example). If someone clones a repo, does it know? And do we care actually, or do we care only about actual changes that go back into the remote repo?

Note: Sometimes it seems like a git command might create just an event. Sometimes it seems like it might create a process and an event (or two). What we want might depend on if the user wants to attach other events to a process.

Point of discussion: We talked about probably staying at the repo level for a VF resource, for now. One repo would hold the design and various docs for one "product" or "component". It will be interesting to see how this works out in practice, with many components going into one final product. When a component is made by one agent and sold to another agent, that component is a final product to the first agent. Etc. I still think it is a valid way to think about it though.

Note re. only remote repos being resources we care about: If we want to track all the ins and outs to everyone's local, we could figure out how to do that. I suspect it would involve making the branches into contained resources? There might be a lot of nitty-gritty involved, depends on what is wanted.

2022/08/03 More thoughts about the remote repos being the resources we care about. Git has a more flexible and complex workflow than VF atm. This is because git can merge. So git can look like this:

VF has assumed that accept-modify means even an electronic resource is not available to others during the process. I don't think it matters, except a flow UI is possibly more difficult to represent. Here is me trying some experiments. The last one isn't right because there are more known commit stages than VF is representing here (see git diagram above). So we would have to do it the first way.

In any case, it won't have the richness of the full git workflow. If we want to know in FCOS the more complex sequence of work on everyone's local, or want to understand in VF the commit sequence, then we will need to think about how to do that. Currently in VF when one identified resource goes through "stages" during its lifetime, we look at the previous process's process specification as the stage, and that is part of the logical identifier if that is needed. Like a hospital gown has to be in a clean stage to be used. Or a component has to be in a test stage (and pass state) to be assembled into something. All of that relies on processes. And I don't think we want every commit to be a process. If we do, we can make it so. But I am still thinking we want git to do what it does well, and VF to hold a summarized representation of that… TBD of course.