Process Patterns explanation + sentence structure ideas

[bhaugen]

Process Patterns are a complex part of the OCP configuration.

This slide deck shows a quick overview of all the configuration options. This tutorial has gory detail about how the data fits together, starting on slide 8.

If you have Freedom Coop admin access to testocp, you can see the process patterns here:
https://testocp.freedomcoop.eu/accounting/maintain-patterns/

Why Process Patterns exist

Sensorica created a bewildering array of Resource Types. You can see them here:
http://nrp.sensorica.co/accounting/resources/

So the first reason was to filter the list, as you can see on the right panel of that page.

However, the bigger problems came up when creating processes and logging process inputs, outputs, and work.

[Edit] Two Three main types of problems arose:

• Long selection lists of Resource Types for inputs, outputs and work. Basically every Resource Type in the system appeared on every selection list. But usually, for a particular process, only a small subset would be useful, and those would be all you wanted to see.
• But an even more difficult problem was knowing which Event Types applied to which Resource Types. For example, some Resource Types might represent work, some might be consumed in a process, and some might be created. The user would need to know not only what those Event Types meant, but also which of the long list of Resource Types might be consumed or created in this process (for example). [Edit] For example, you might add the Resource Type "Flour" to a process. What Event Types go with Flour? Either you need know that Flour could be produced or consumed but not used, or the system needs to know and present you with only those two selections, or a Pattern can tell you that Flour is produced in this Milling process but not consumed.
• Plus, Processes are organized by Event Type, so the Event Types need to be filtered, too. Not only is there a long list of Event Types (see below), but many of them are used only in special situations, and often do not communicate well to new users.

How Process Patterns work

Process Patterns are organized by Use Case: for example, Manufacturing Recipes/Logging
or Todos (called Simple Tasks in OCP).

Within a Pattern, Resource Types are added by Event Type: for example, Consume, Use, Resource Production. The Event Types selected for the Pattern determine which ones will appear in Processes that use that Pattern.

The Resource Types that match each Event Type are select by Facet Values. Here's Wikipedia on Faceted Classification.

The Pattern designer selects which Facet Values apply to which Event Types. The Resource Types are given Facet Values, and if the Facet Values for the Event Type match those on the Resource Type, that Resource Type will be appear in the selection list for the Event Type on a Process that uses that Process Pattern.

How well do Process Patterns work

They can do a pretty good job of limiting the selection lists for process creation and logging to the small subset that should appear, and they also make it easy for users to know which Resource Types go with with Event Type.

But we have found that people find them difficult to configure. And when a new network is getting started, because they are required for process creation and logging to work, we need to create a starter set of Patterns before any logging can be done.

In comments on this issue thread, we will discuss some possible system changes and tradeoffs about Patterns and Facets.

Existing Use Cases and Event Types

The existing Use Cases in OCP are created by a script. They can be added or changed, but doing so would require some fairly simple code changed. As of this writing, the valid ones are:

• These apply to Processes:
  • Manufacturing Recipes/Logging
  • Workflow Recipes/Logging
• These apply to other work logging:
  • Non-production Logging (called Extra Tasks in OCP)
  • Todos (Simple Tasks)
• These apply to various kinds of exchanges:
  • Customer Orders
  • Distribution
  • Value Equation
  • Payout
  • Make Available
  • Internal Exchange
  • Incoming Exchange
  • Outgoing Exchange

Certain event types apply to certain use cases. Here we'll just talk about the ones that relate to processes and other work logging.

• Manufacturing Recipes/Logging
  • Time Contribution (Task)
  • Citation (like a scientific citation, used for designs (for example), resource is not changed)
  • Resource Consumption (resources are gone from inventory, like eating the carrots)
  • Resource Production
  • Resource use (resource is used for some time but not gone, like equipment or a room)
• Workflow Recipes/Logging
  • Time Contribution (Task)
  • These three apply to "stream resources": those that are both inputs and outputs of the same process, being changed in some way by the process:
    • To Be Changed (resource accepted into the process)
    • Change (same resource changed in some way, coming out of the process)
    • Create Changeable (creating the initial resource that will be changed through a chain of processes)
  • Citation
  • Resource Consumption
  • Resource Production
  • Resource use
• Non-production Logging
  • Time Contribution
• Todos
  • Todo (same as a Time Contribution)

In NRP, we separated the manufacturing/assembly type recipes and the workflow/streaming type recipes, and thus the use cases became separate. (More about the possible problems with that in subsequent discussion in this issue.)

Manufacturing was first, and reflects the situation where input resources are processed into different resources, like you would see on a bill of material. We added on workflow because we needed to support situations where one resource goes through multiple stages as it is being produced, which we ran into with translations (translate, edit, proofread, etc.). It also applies to repair, for example. Here is more info about the differences, starting on slide 12.

[fosterlynn]

Adding some thoughts on top of the explanation of what exists now.

We have discussed changing OCP so that process patterns are not required. This is because of the conceptual difficulty configuring them, especially for a new group with no experience on logging their work and resources yet. And for groups with very few resource types, maybe process patterns are not needed at all.

Another side note is that @bum2 has been adding his General App to the OCP work app. Among other things on the exchange side, this would eventually replace the process pattern functionality. Right now he is using the existing facet-values to integrate the concepts, so there is no capability of using faceted classification without disrupting his facet-value data, which is mapped to the GA taxonomy, and thus is tree-like, not facet-like. There is an issue out there to separate out the tree functionality of the GA and the faceted classification functionality that exists now, so that both can be offered as a configurable option for resource type filtering. This would be in addition to making it so that neither is required.

In any case, we think the cleanest path right now for this work is to ignore both process patterns and GA, and work on the "neither is required" path.

Most (or maybe all?) of the code that requires process patterns we think is in the views, not the models. So that will become irrelevant in this work.

But, there are some additional things we will need to do to minimally filter resource types so they aren't just confusing.

One is to make use of the existing EconomicResourceType.behavior field. This is basically "work", various currency related things, and "other". So at least for Time Contributions and Todos, we can show only "work" resource types, and eliminate them from other event types. And we could do possibly show just "other" resource types for consuming, using, citing, and producing. And maybe there are other ideas along these lines.

Another thing @bhaugen and I discussed this morning was that the distinction between manufacturing type processes and workflow type processes may not be that valid. Right now we have as different use cases, meaning they show up in different places in the app. We already allow workflow processes to use any event types that a manufacturing process can use. But not vice versa. They were separate partly because of history - we added workflow recipes later and the code was already complicated. But without process patterns, either we need to make people make that choice up front when creating a process, or we need to just let them mingle and be one thing.

We think that the latter is probably best. We just need to minimize the confusion of seeing something like "Produce" and "Change" both as possible output types of a process. Maybe work with the wording, and/or get some help text in there.

[bhaugen]

One is to make use of the existing EconomicResourceType.behavior field.

Other possibilities:

• add to the behaviors but make them multiple-choice, or
• add combination behaviors, like "produced or consumed", or
• associate Resource Types with [edited] Event Types directly, not through faceted classification, or
• hierarchical classification a la General app, or
• something else I did not think of...

[fosterlynn]

But, there are some additional things we will need to do to minimally filter resource types so they aren't just confusing.

I guess these might go into models.py as methods. I can work on those if it makes sense, maybe as part of doing or helping with API work? It might be distracting for people doing the UI work.

[bhaugen]

One thing that everybody should be clear about: none of these patterns or filters or hierarchies are necessary for the internal functioning of the system. They are purely UI helpers. Some variation on these themes seems to be needed as UI helpers once things get to a state of complexity where the people trying to do their work start to have a hard time. But substituting one for the other, or making them all optional, will not stop the main functions from working.

[fosterlynn]

One thing that everybody should be clear about: none of these patterns or filters or hierarchies are necessary for the internal functioning of the system. They are purely UI helpers.

Very good point. Also, if we follow the suggestions we made above, there are no implication on the UI that @ivanminutillo has proposed for process planning, it will all happen below the UI. So people can decide to not dig into it right now if they wish. 😄

[ivanminutillo]

After reading here and on telegram, to me process patters seems the integration of 2 different concepts in one feature.
Maybe this was the reason why it was complex to integrate process patters inside the app untill now.
To me what you wrote about process patterns should divide into:

• sentence structure (or sintax) implementation
• process patterns

For syntax i refer to the wikipedia explanation: the set of rules, principles, and processes that govern the structure of sentences in a given language, specifically word order and punctuation.
And process pattern that would become one of the possible implementation upon the syntax.

I think that implementing syntax inside our app is foundamental and we should treat it as another epic, becouse we need to think if it involves only the frontend or we want to define syntax also on the backend, how to implement it ecc.
I think after implementing syntax correctly inside our app, process patterns implementation would be much more easy, and we can build also a lot of other awesome features: also bot would be really more powerfull with a clear and defined syntax.

[bhaugen]

@ivanminutillo

process patterns should divide into:

• sentence structure (or sintax) implementation
• process patterns

That's a really interesting idea, but I don't understand how it would work. Got any more details in mind?

[ivanminutillo]

What I mean is that process pattern creation is just one implementation upon a built-in syntax. Define a syntax could have implications on all over the system, becouse if we define a syntax, we wouldn't just use on the process creation phase but also on several other features.
So, when you wrote the paragraph: How Process Patterns work to me it was more something like How syntax works, becouse in that paragraph you were defining some rules about the structure of a sentence in Kamasi, let try to make a stupid example to extrapolate a rule based on what you wrote:

• When a user define an action, the sentence start with an event type (Consume, Use, Produce) and after one or more resource types, separated by comma.
  eg. I consume pie crusts, apples, sugar, flour, cinnamon, teaspoon salt, nutmeg, lemon juice.
  The way we will deal at a software level with this rule can be more than one, eg the one @bhaugen proposed: implementing the faceted classification and autocomplete input form:
  in this way when a user has to log or create a new process or a task inside a process he will select (or type, or check) an event type that automatically will be linked to an array of resource types (built thanks to the facet values selected on the process patter creation), and with the help of an autocomplete input, the user easily will find the right resource type.
  Maybe an implementation of that rule could be:
• When a user define an action, the sentence start with an event type (Consume, Use, Produce), and it could be followed by one or more resource types. Before each resource type it can be specified adverb or the specified quantity / quality of the resource type.
  eg. I consume 1 pie crusts , 6 apples, 3/4 sugar, 2 flour, 3/4 cinnamon, 1/4 teaspoon salt, 1/8 nutmeg, 1 lemon juice
  or:
• When a user define an action, the sentence start with an event type (Consume, Use, Produce), and it could be followed by one or more resource types. Before each resource type it can be specified adverb or the specified quantity / quality of the resource type. After the last resource type it can be specified the output event type to build a chain
  eg. I consume 1 pie crusts , 6 apples, 3/4 sugar, 2 flour, 3/4 cinnamon, 1/4 teaspoon salt, 1/8 nutmeg, 1 lemon juice to produce 1 apple pie.

I imagine that this structure could be also really useful for the exchanges modules we talked about to implement with social / mutual currency...

Does it make sense for you all this?

[bhaugen]

Does it make sense for you all this?

I think I am starting to get it. We have discussed sentence syntax a bit in Value Flows: for example, this issue. But haven't done much with it yet.

Any ideas how you would implement those structures?

[ivanminutillo]

Brainstorming mode on 👯
I think we should firstly define who are the actors of this dialog.
I imagine a scenario similar to this one:
Each time a user start to build a sentence on the interface ( by typing (bot mode) or by selecting action and resources on a form, ...) each section of a sentence would call an endpoint through the graphQl layer that would understand the request and return a JSON that would correspond to the following sections of the sentence...
eg. on the process page I type: I consume ==> first interaction with graphQl layer that return an array with the facet values defined in the process creation phase [sugar, flour]
I consume sugar ==> second integration with graphQl that return an array with the new possibilites to continue the sentence... [to produce, with, ...]
I consume sugar with @bhaugen
In this way where the syntax rules are defined ? I think that are specified on the model through a lot of facet classification rules ;)
if so, we should be able to create a custom general set of rules that could be customized time by time...

[ivanminutillo]

rereading....I was able to make the worst and more controversial example I could imagine bauhauhauauh

[bhaugen]

Might not need any patterns with that structure, although I think we would need associations of resource types with event types, which could be done directly (although would require a model change and database migration). Would be a many-to-many association between ResourceType and EventType. Would need to be specified when a ResourceType is created.

[bhaugen]

who are the actors of this dialog.

Think also of the actors in the surrounding context. One of the developments we've seen in every organization we've worked with is that the people in the organization learn over time how to do things better. Lynn and I have added features to the system that allow people to document that knowledge in ways that can be used to configure the next time somebody does something like that.

For example, Recipes (which contain Process Types, that are used to preconfigure every aspect of a Process, like a template that generates a process). Nobody has gotten into them in OCP yet, and we did not connect them to the current process creation form.

Process Patterns are also like that. Although they have proven to be difficult for some people to understand and configure, especially at first, they do work, and when applied, do configure the possible choices for a new process.

This sentence syntax would I think need at least the preconfiguring of ResourceType-EventType possibilities. So the EventType is the verb (consume, use, cite, produce, etc) and the ResourceType selection would be which objects can go with that verb.

[Edit] Work is a little awkward as a verb with an object, and maybe even as the name of an EventType with this sentence syntax idea. The object selections for Work as an EventType are types of work, called Skills in OCP. Can the same syntax work for Work? @ivanminutillo has already separated work requirements into a Tasks section, so they don't need to fit the syntax. Right?

[bhaugen]

We have two oddball EventTypes for resources that are changed in a process, where the same resource is both input and output as the same resource with some differences.

For example, translations are then edited, but the output of the editing process is the same translation, but improved (the editor hopes).

Or bike repair: the same bike is the output, but fixed, maybe with some new parts.

We have two EventTypes for changing resources: "To be changed" for the input EventType, and "Change" for the output EventType. ( "To be changed" seems like an awkward name, but we couldn't figure out anything better...)

Anyway, "To be changed" also seems like an awkward fit for this syntax. And those two EventTypes always go together. So I am thinking, if we go with this syntax idea, maybe we just use "Change" as the verb, and create the other planned event (class Commitment in the OCP models) in the pair automatically when saving the Change Commitment.

[fosterlynn]

rereading....I was able to make the worst and more controversial example I could imagine bauhauhauauh

Oh, I don't know, I can think of a few worse things you and Bob could consume..... haha

Might not need any patterns with that structure, although I think we would need associations of resource types with event types

I like where this is going. Like: sugar (consume, produce), pie tin (use, produce), hardware design (cite, produce). Or, a bike (use, produce, change). Then use that to give the next set of selections as you described @ivanminutillo .

We could either treat work in the same way, or use the existing resource type behavior for that. And the currency options might help too, they probably have no place in processes at all. Perhaps when creating resource types, if "other" behavior, then we pick event types?

If at all possible, I would like to create for this epic something where patterns are not used. I think this has a good chance of doing that.

[fosterlynn]

If we decide to do it this way, I'd like to structure it so it is one of several options, also including process patterns and the GA taxonomy. This choice could be configured maybe by context agent? Or maybe by installation?

[fosterlynn]

If we decide to do it this way, I'd like to structure it so it is one of several options, also including process patterns and the GA taxonomy.

Then we get into some practical dev related questions around how to do this on top of OCP first rather than the refactored app, which I still think we should aim for. The point of connection is creation and change of resource types, which we don't currently have in the epic. And not all creation of resource types is yet in the work app I believe, just work (skills).

Without getting into the whole long discussion of the General App, I think we do want to do this epic without encountering the GA, to minimize that large piece of coordination.

One solution that is much easier (although less complete) is to add some choices to the behavior field on resource type: Immaterial Item and Material Item. This I think would allow us to use that to separate off resource types that can be cited (immaterial items like documents or designs), and resource types that can be consumed or used (material items). Both immaterial and material items can be produced or changed, so this applies to separating out on the input side only.

It also might be possible to somehow separate out items that are used only, but this is less clear. People tend to use many things as tools for one thing, sometimes whatever is handy. And sometimes people build prototypes out of components that would normally be considered consumed, then take them apart. There are lots of gray scenarios between resource types that used and those that are consumed. Bob and I are still discussing this possibility.

So, basically I am changing my mind, and thinking we should do the non-option version for this epic, by adding some behavior choices to resource type. They won't hurt anything else, and can be done in the existing app without data migrations.

Ongoing discussion.....

[ivanminutillo]

@ivanminutillo has already separated work requirements into a Tasks section, so they don't need to fit the syntax. Right?

Yep but I also think that If we want to procede with this approach , I think we should extend the syntax to cover every scenario and section we have in our app, so it should work for the work requirement, for the finance management, the exchange, etc...

[fosterlynn]

Yep but I also think that If we want to procede with this approach , I think we should extend the syntax to cover every scenario and section we have in our app

👍

[bhaugen]

I think we should extend the syntax to cover every scenario and section we have in our app, so it should work for the work requirement, for the finance management, the exchange, etc...

I'm ok with that in theory, but:

1. I thought separating out Tasks was a good idea, given the way people talk about them, and work is different in a lot of ways (altho the syntax approach could still be used), and
2. We don't really need to tackle exchanges yet, and they have some peculiarities, too, so it might be one of those YAGNI's (You Are Not Gonna Need It), so don't do it until we need it.

[fosterlynn]

One solution that is much easier (although less complete) is to add some choices to the behavior field on resource type: Immaterial Item and Material Item.

It also might be possible to somehow separate out items that are used only, but this is less clear.

Bob suggested "citable", "usable", "consumable" for new resource type behaviors, making the connection more directly in people's minds. I'm good with that, and we can then see if we run into many situations where some resource type can be more than one of those.

[fosterlynn]

I imagine a scenario similar to this one:
Each time a user start to build a sentence on the interface ( by typing (bot mode) or by selecting action and resources on a form, ...) each section of a sentence would call an endpoint through the graphQl layer that would understand the request and return a JSON that would correspond to the following sections of the sentence...
eg. on the process page I type: I consume ==> first interaction with graphQl layer that return an array with the facet values defined in the process creation phase [sugar, flour]

So this can work for creating commitments or economic events I think. And I really like being able to do it for bot mode (define hash tags?) or selection mode with type-ahead.

Here is an idea of what might be needed:

Commitment:

• Pick action (get the possible resource taxonomy items)
• Pick resource taxonomy item (get unit and resources)
• Optional: pick an existing resource (this doesn't happen too often, but it can.... hmmmm, maybe should skip? @bhaugen ) (not applicable to work)
• Quantity (of unit)
• Due date
• Optional: provider (an agent, pick now only if this agent is committing to work, maybe only need to offer for work events - @bhaugen any reason to enter from_agent for other types of events?) (if work, show only Persons related to the context agent)
• Note

Commit to task (work only):

• Provider (default to logged on user)
• Quantity (they can change it)
• Due date (they can change it)

Event for an existing commitment:

• Provider (default to the logged on user if there is no provider on the commitment)
• Resource (can list the available resources and let them pick)
• Quantity (we know the unit)
• Start date (default to today)
• Note

Unplanned event:

• Pick action (get the possible resource taxonomy items)
• Pick resource taxonomy item (get unit and resources)
• Optional: Pick an existing resource (doesn't apply to work)
• Quantity (of unit)
• Start date (default to today)
• Provider (an agent - if work, show only Persons related to the context agent)
• Note

[bhaugen]

I'm following up on a Telegram chat where I promised to sketch out a spectrum of possibilities for planning and creating tasks in Kamasi, starting with the simplest, and adding complications one-by-one.

• I did some work.
  • Might be good to add some details like when, what type of work, for whom (person, collective, project, whatever), how long I worked, maybe a description, etc.
• I did some work and creating something, like baked a pie.
• I did some work and created something and used some other inputs, like baked a pie using apples and an oven.
• I did some work and somebody else helped on the same process. Like, somebody else made the piecrust. (In the previous examples, we didn't care very much about the process. In this case, the other person needs to say they worked on the same process of baking the pie.)
• I planned to do some work. (In all of the previous examples, there was no plan - in OCP, anyway.)
  • All of the previous examples could have been preceded by a plan, to create an apple pie, where they start with some apples and piecrust ingredients, and one person makes the crust and the other person bakes the pie, and the plan for the pie causes lots of people to gather around to eat it.
• I planned some work for somebody else to do. Depending on the rules, I can either assign somebody else to do it, or I can just post the need for some work to be done, and hope somebody will pick up on it.
  • All of the previous examples could have been planned without knowing who would do what, or that we had any apples and piecrust ingredients, or even an oven, figuring we could make it happen somehow.
• Somebody else commits to do the work.
  • That can also happen with the apples and piecrust ingredients and oven in the previous examples. Some kind person could offer all of the requirements.
• I am doing the work and ask somebody else to help. Like, I can bake the pie, but I don't know how to make a good piecrust.
• The whole plan for the pie is actually connected to a plan for a dinner party where the pie will be dessert, and lots of other dishes will also need to be prepared for the dinner, and some people will need to clean up afterwards.
• The plan for the pie is also connected to a previous plan to pick some apples from a nearby tree.
• The flour for the piecrust needed to be ground by a different collective that runs a flour mill.
  • And they get the grain from a different collective that has a farm.