search

FreedomCoop / valuenetwork

Fork coming from NRP-Sensorica to use and work for FREEDOM COOP
http://fair.coop
GNU Affero General Public License v3.0
31 stars 12 forks source link

General app questions and feedback #206

Open bhaugen opened 7 years ago

bhaugen commented 7 years ago

@bum2 I set up a new local dev environment to work with the General app in the project-planning branch, and got this error:

./manage.py test
ImportError: No module named mptt

Tried to install it, but got this error:

pip install mptt
  Could not find a version that satisfies the requirement mptt (from versions: )
No matching distribution found for mptt

Apparently mptt is not pip-installable? Or what? http://django-mptt.github.io/django-mptt/install.html#official-releases

bhaugen commented 7 years ago

Solved: should be

pip install django-mptt

Looked, it was in requirements.txt! I thought I had run that, but maybe before I switched to the branch.

@bum2 - sorry for the false alarm.

bhaugen commented 7 years ago

Tests now run and pass in the project-planning branch. More feedback to come. I will try to make it more accurate...

bum2 commented 7 years ago

Here are two docs, one about the General app itself and another about the actual integration process with Ocp...

GeneralApp_1.docx

OCP+General_1.docx

bum2 commented 7 years ago

also a first fast diagram of using Exchanges as an entry page for types... ocp-diagram1_vect_bum

...more diagrams pending will come when ready, more in deep with the models and classes interactions, etc...

bhaugen commented 7 years ago

@bum2 do you think this stuff will be ready for that hackathon in March? Or if not, what would it take to figure out what could be stabilized and ready by then?

XaviP commented 7 years ago

I've been taking a look at the @bum2 documents. It's seems to me a re-conceptualization of the already complex nrp concepts. A kind of interface over the ocp data structure. For me it's already complex to understand and manage nrp models, as it looks for wide configurations. This new interface adds more complexity to the system, I don't see how it helps in make it simpler. I think in this stage of development, we would need some very practical user histories, which de-complex the data structure closing the configuration to approach to the real world. Maybe I don't have understood how this simplicity is achieved in this app, but maybe this can be better explained by bottom-up examples, like a real people/group experience. Edit: Maybe this new concepts/models can be translated by an API from nrp ocp concepts/models for any external system that uses them.

XaviP commented 7 years ago

Another personal thought: I'm a developer, not an economist or a conceptual filosofer. When a concept comes to me, automatically I'm going to try to match it in a structure of data and its interaction shown easily to the user. The ultimate goal for me is to facilite the use to an absolute agnostic final user. In this way, I urgently need ocp simplification by understand user's needs. Edit: but this is a personal need, maybe I'm not able to manage so many complexity, so what I'm asking for is to re-orient the language towards simpler user histories. All this is not about valorate the app, but the language used.

bum2 commented 7 years ago

I'm trying to simplify the process for the user to create exchanges and for everyone to help create and maintain a common set of Types (needed for the exchanges). I know it adds some complexity at the code level (only new connector models) but now seems easier to set an exchange or find a type, and seems easier for all to show and maintain a common 'tree' of types (instead of a common 'list' of types)...

The actual names of the types branches is what can give 'philosophical' thoughts, but that's config, just let's choose the most clear and agnostic words and build a common tree!

For the GUI widgets to choose from a tree, i've placed two widgets in synch (search autocomplete dropdown + folding tree of radiobuttons, use any) for the resource-type and skill-type choosers, but we can find other widgets more 'screened' (like https://github.com/arschmitz/jquery-mobile-nestedlists/) to ease even more the UI.

The point for me was to get into the worst case where a user needs to choose from a 'non filtered' resource type list. In many other places the resource types are prefiltered either by the process, transfer, context, facetvalues, etc, but in the new exchange page i think it was one of this rare places where is needed the whole set of resource types (except the types not reached by the context scope).

bum2 commented 7 years ago

I think in this stage of development, we would need some very practical user histories, which de-complex the data structure closing the configuration to approach to the real world. Maybe I don't have understood how this simplicity is achieved in this app, but maybe this can be better explained by bottom-up examples, like a real people/group experience. Edit: Maybe this new concepts/models can be translated by an API from nrp ocp concepts/models for any external system that uses them.

Bottom-up use cases now are the decentrale renting spaces, the local node's needs (also trying to figure out how can it be an 'exchange office' in ocp), and now will come many usecases for projects related the 'cooperativist society', and other FC members projects waiting the tools...

You are true about an external structure to talk with via API, is a better approach, but that requires to take seriously the project of a General app or meta-structure of common data as a whole platform, and remember it has no GUI yet (only admin views)... Now i'm just duplicating type names in both structures and profiting the connector models (mainly one2one's) to manage other behaviours of the resource types branches, like when they are 'facetvalues' or even general 'facets'.

After this next release publication, I will like to focus in letting the 'resource types branches' (which are also facetvalues) behave like Tags to define an object (getting then full power of the facetvalue system), so i'll make multi-choice selectors to append Tags to define the object (say an exchange or a resource, etc), and inherit whatever is needed from any of it. Also a 'relation' with that tag-resourcetype will rule the inheritances and connections: for example 'included' parts, 'missing' components, 'pending' design, etc

Edit: For this release only single type choosers are ready

XaviP commented 7 years ago

Thanks for the answers,

Edit:

Bottom-up use cases now are the decentrale renting spaces, the local node

Can decentrale or local nodes test this new features?

bhaugen commented 7 years ago

Can decentrale or local nodes test this new features?

Chris Zumbrunn in Telegram seems like he is ready to some testing. I think a priority for OCP right now should be getting ready for this upcoming hackathon and new collective.

I'll do some testing, too, starting Monday and Tuesday.

One problem that came up in https://github.com/gopacifia/DEEP/issues/7 is that they want to separate inventories by context agent (e.g. project, collective, etc.). Unfortunately, that necessary feature (along with separating a bunch of other things by context agent) got bundled with the General app in a branch (I think). It would be good to separate that out and get the context agent features tested and deployed. As far as I know, the context agent features do not depend on the General app features.

fosterlynn commented 7 years ago

As far as I know, the context agent features do not depend on the General app features.

That is correct. We can implement the long range requirement of having both "private" types by context agent along with "public" types for the whole network, or for groups of context agents, with or without the General App. This applies to any shorter range piece of that requirement too.

fosterlynn commented 7 years ago

That is correct. We can implement the long range requirement of having both "private" types by context agent along with "public" types for the whole network, or for groups of context agents, with or without the General App. This applies to any shorter range piece of that requirement too.

Historical notes:

The OCP when first forked did not have any "privacy" of resource types or exchange types. It was designed for a different architecture where an instance of the software was one focused network or set of networks that basically used all the same types because they are in the same domain (like Sensorica or Guerrilla Translators). So it already worked for broad transparency and unification of types.

Freedom Coop has a different requirement because they are a much broader regional network of very different groups. So the original requirement in FC was to give some "privacy" to individual collectives and projects that joined FC, but already had their own needs.

When the General App was introduced to this requirement, it pushed it back towards unification of types, but as the GA ontology. (Not all the way, it has a way to eliminate Freedom Coop specific types like quarterly fees, etc. And @bum2 has since added some ways to give individual collectives more privacy, I understand but haven't seen.)

bum2 commented 7 years ago

The exchange types and resource types are shown depending on the context, filtered by the work app views and forms.

The name and branch of the custom types is also recorded indirectly in the main general.Type table (extended by general.Record_Type and the work.Ocp_Record_Type entries, for the exchange types branch, and extended by general.Artwork_Type and work.Ocp_Artwork_Type for the resource types), and the skills names (verb, description, etc) are recorded in the general.Job table (extended by work.Ocp_Skill_Type). That means, in this release, that the 'private' types data (small context) is in the same tables as the 'common' data (big context), at least the name+description part of the 'type'. The 'context' filtering is at the code level.

As you said, the context information is not related the GA (general app), only the core ocp models. It can work without GA (not good tested yet).

If we want one day to not just share the code repo but also some common Data, maybe we can separate types by context in different tables, in a way that we can freely share 'common data' tables between forks (without bothering other networks with our custom types, or having to filter them in the views and forms, etc). If the other forks use our same views and forms, the filters can be common. A nice ToDo can be to make this separation of context at the tables level.

The main point about GA is that i'm just now 'presenting' it to other forks, but without much time to talk about it. It is a 'experimental' structure we can use or not, but will be good to test and experiment possibilities to decide how much we want to use it (which data or types) or simply get some code bits and introduce them into the ocp structure. I've avoided this option and just did 'connector' models, to let the most possible 'untouched' the ocp code (which is soo complex itself). So, i've not added mptt trees or sub-classing models in the core.

The GA is kind of a core about data and types (no functionality), the Valueaccounting app can be the core about processes and accounting (REA), recipes, orders, tasks, etc, and the Work app can be the core for memberships functionality, communication and GUI.

The REA-GA mapping is easy: Resources = Artwork or Job, Event = Record (of type event), Agent = Human. Other models like Exchanges, Patterns, Processes, are also Records in GA, all them with their *_Type tree models (which inherit from Concept). In the GA also the Relations (inheriting from Art) are modeled in a flexible way to connect any object. I'm doing a doc table with all Valueaccounting models in the left side, and the correspondent General model in the right side, to have one day the complete map for merging structures if desired (i can share a first draft). That's far away in time and needs lot of testing, debate and consensus before taking such a decision.

bhaugen commented 7 years ago

The exchange types and resource types are shown depending on the context,

Why does my context agent exchange type not appear? See https://github.com/FreedomCoop/valuenetwork/issues/184#issuecomment-282616866

bhaugen commented 7 years ago

See also https://github.com/FreedomCoop/valuenetwork/issues/233

bhaugen commented 7 years ago

@bum2 @XaviP @fosterlynn

In the GA also the Relations (inheriting from Art) are modeled in a flexible way to connect any object. I'm doing a doc table with all Valueaccounting models in the left side, and the correspondent General model in the right side, to have one day the complete map for merging structures if desired (i can share a first draft). That's far away in time and needs lot of testing, debate and consensus before taking such a decision.

That would be a good table to have. We've been wondering if your goal was to merge ontologies or keep the General app as a UI taxonomy tree thing, or maybe replace the facets with the General app.

The problem that surfaced in https://github.com/FreedomCoop/valuenetwork/issues/233 was when a General app object (Ocp_Artwork_Type) appears in a frame slot (form field) where an REA object (EconomicResourceType) was intended.

All of the REA objects have both relationships and logic attached to them, and in most cases, neither the relationships nor the logic are optional if the system is going to work. The relationships are part of the ontology, and so is the logic. It's an operational ontology, not just a descriptive one. But it's also minimal (all the concepts you need for an economic network, but not much else), and so it's also extendable. Each of the REA objects could have a taxonomy "on top" of it, if you know what I mean. That might be a good use of the General app, as a descriptive taxonomy, but being careful not to disturb the operational logic.

This is an important issue for discussion and consensus. If this comment does not raise it sufficiently, I'll open a new issue.

bhaugen commented 7 years ago

P.S. we (me and @fosterlynn ) don't care if you replace the facets with the general taxonomy, although that might be an issue for the django-rea convergence project (like, making both of those, facets and general taxonomy, into pluggable options).