What kind of culture, and systems do we want in this loomio group?

Monthly reports would probably go a long way, and wouldn't be that hard to coordinate. Even a paragraph long report from each subgroup would be awesome.

@elfpavlik @bobhaugen @lynnfoster @tiborkatelbach @carolinesmalley @jonrichter would love to hear your thoughts.

@simontegg and all - Sorry for the silence, a bit heads down now, and sometimes not conscious enough of communication. Responses to the discussion so far:

I would also lean towards the more open end for this work, to make it feel more like players interacting as peers, rather than visitors to Enspiral. Not that visiting Enspiral is bad.... :)

Small sub-groups seem to be working well, from my corner of visibility into the process. @bobhaugen and @ahdinosaur and I have been working on pieces of open vocab, and making nice progress.

I agree monthly or more frequent reports would be really nice. I appreciated Simon's last report. That would help us not be too isolated, and people could jump in with concerns etc. without going through the pain of sitting through the nitty gritty detail.

I would be interested in what groups have formed in Open App and what each of their goals are.

Still thinking. As my thinking is based on slowness and long-term causality, I will present my views when time's ready. Patience is a virtue.

Thanks starting this discussion and for mention @simontegg!

I really appreciate your sensitivity to identity issues. I agree that many people may feel more comfortable to engage with Open App ecosystem than Enspiral organization.

I would also like to ask if people heavily engaged in Enspiral tend to gravitate mostly around discussions here or you also engage in various mailing lists, other forums (many projects host dedicated discourse instances), issues in github repositories etc. When we talk about decentralized systems I see a challenge that no one can position oneself in a center of such development :D

I must admit not knowing so much about organizational practices of Enspiral. I would like to learn more and compare to how groups like http://www.youcoop.org , http://engage.is etc. operate. Do you have some information about Similar Organizations or event some analysis of similarities and differences?

When it comes to group work, I'll try to reflect on my experiences with W3C, OKFN, OuiShare and some other networks and share some more feedback then!

@simontegg - hope you won't interpret my commenting silence for unhappiness. Everybody is saying a lot of good stuff, I'm just signifying with likes.

I agree with Elf , but to answer specifically Simon's question , The Group should be as open as our apps should be .
for any community that wishes to follow an open App dynamic.
Since it is quite hard to give structure to such a distributed initiative while everyone keeps their autonomy, I think glue that links us all is in our common goal and beliefs that working together, on identical and interoperable semantic technologies and open Apis is the way to build this common initiative.
I really beleive in frequent meetups with short term goals.

Hi friends. Just wanted to let you know I'm laying low at the moment. Had to say goodbye to 4-legged love of last 14 years Friday just passed. Time of transition.

That said, I am getting back into things. Focus is on the proposal I'm developing in relation to CM that's based on very similar intentions as expressed through this group. I'll endevour to share an exec summary with you sometime in next 4/5 days.
In appreciation, C

Sorry to hear that @carolinesmalley, look forward to your update.

thanks @simontegg .. much appreciate

I've been thinking about your question @elfpavlik. And l'll use it to talk about comms in enspiral in general.

Projects in enspiral will generally have a loomio group and a hipchat channel. Small-scale comms also happens through hangouts and and network-wide through a private g+ community.

Many projects are client-related and not open-source so having private channels (hipchat) makes sense for these. Hipchat is also user-friendly for non-devs and the main open free alternative (irc) is not. This makes less sense for open-source projects, unfortunately the network effects of everyone being on hipchat seem too great at this time to get people to switch :(. If its a code project then very specific stuff will occur on github comments with webhooks being routed back the group's hipchat stream.

Most things are do-ocracy based, in that the people doing the thing get to make, and are trusted to make, all the decisions about the thing. Occasionally, you won't know the answer to a highrer-level question, or you need team-wide buy-in, or you realise what you're doing has downstream impacts, or you need to make an announcement and want to ensure everyone will see it. For these things we start a loomio discussion. @bobhaugen's discussion on Corporate biases in LOD standards is a good example of this.

@joshuavial has made this repo: enspiral agreements for explaining some of the inner workings of enspiral.

Related: @ahdinosaur passed this on: async teams

I want to propose a bare-minimum about sticking to free/libre/open commons. Every single mention of the use of proprietary tools should come with an apology.

If you use GitHub or Google+ or Google Hangouts or any other proprietary tool, you should repeatedly and consistently feel obliged to say, "sorry about this proprietary tool…" and continually open the discussion to how to escape it or at least making everyone clear why the compromise was taken.

I understand and respect that we compromise often. So be it. But we should never have someone show up and just tell them, "oh go join this Google+ group". It should be at least, "oh, we use Google+ even though it's proprietary. It's not ideal, but it's how things are at the moment. Anyway, join us at …"

Similarly, it's not a bad thing (although less essential) to continually reference how nice it is when we use tools that are Free/Libre/Open (FLO) commons. We can say, "come join us at Loomio, a fully FLO platform!" As long as this issue is a major concern, we need to keep it front and center. Too many people avoid addressing it and stay oblivious.

Respectfully,
Aaron

To add further context re: FLO at enspiral.
Enspiral as a whole has no policy on the usage of FLO. Some ventures are based on proprietary software, (relatedly some Enspiral companies are traditionally structured companies). Loomio and Craftworks are probably the main centres of FLO culture within Enspiral and Aaron makes a good point for what those companies/teams could decide to do.

The dilemma for Enspiral is that comms platforms (and policies regarding them) are dictated by the the network as whole. So its debatable whether craftworks' people could introduce a pro-FLO policy network-wide.

The selfish dilemma for me personally is that if some of open-app comms shifts to an irc channel (which could be a good idea as much of the comms in the LOD thread is chat-like) it will be less connected to enspiral and I'll have to more effort into being 'the bridge' between the two.

Ignoring my selfish dilemma, what do people think about Aaron's bare-minimum policy? What comms platforms will work for OpenApp?

@simontegg my 2 cents in answer to your questions:

Re. FLO, I think all software recognized as part of Open Apps should be required to be open source, as well as all software used in the stack(s). People running any part of Open Apps should be able to use all FLO software. As a policy decision of the group.

Software used by Open Apps, such as for communications, I don't feel as strongly about. I agree we should make best efforts to use FLO options, and we at Mikorizal plug away at that as a sideline, but we don't let it become too much of a distraction. Even though our purpose is change of economic relations, our time seems more useful writing software, connecting with OA, etc.

I think loomio is a fine place to carry on discussions, I'd just as soon not be using different channels for related discussions. And I don't see any reason for @simontegg to spend useful time bridging the communications.

Agree that all the software in the open app ecosystem should be FLO and that we should have an aspirational target to migrate all supporting systems off proprietary providers.

I don't think being forced to apologise for using proprietary systems is the most productive way to go about migrating though. Instead documenting all the systems we depend on, identifying and monitoring alternatives and checking in on a quarterly basis feels like the way to go.

I also think it is reasonable to expect the FLO alternatives to be equivalent in terms of features and ease of use before we switch.

To clarify, I mean "apology" in the most literal sense. An apology is a formal justification. It doesn't have to be associated with self-shaming. The point is that people should accept the burden to pause whenever choosing to use proprietary tools, especially when it's a group thing where their use encourages others to use them. And we need all proprietary vs FLO tools to be always identified so that people acknowledge the issue.

Anyway, I do not agree that FLO options should have to meet complete equivalence. A FLO option that is truly feasible should be preferred over proprietary even if the proprietary option offers some non-essential benefits.

Loomio and Github are currently the only supporting software for the OA Ecosystem as whole. Loomio is FLO. Github is not. I suggest we park general FLO policy until this becomes more of a problem. Or someone can start a discussion on Github specifically.

It seems more pressing (to me) to have a better subgroup setup. I took the liberty of creating an 'Economics' subgroup as there's interest.

Another one would be a 'Open Vocab'.
I haven't been active in this area so I'm reluctant to 'meddle' in the processes of the people who have :). What say you people of open standards and deep interoperability :)?

@simontegg @ahdinosaur @lynnfoster and anybody else who is interested: I started a sub-discussion in the Economics subgroup to separate the idea of reciprocal value networks for software from the reciprocity license as a tactic to get there.

@simontegg I was going to start an Open Vocab subgroup, but when I actually looked at the whole structure, it was a bit of a happening. (Not a criticism, just the way things develop naturally.) For example, Linked Open Data and Open Vocab are related, Open Vocab could be a sub of Linked Open Data perhaps, or maybe they are just the same thing. But Linked Open Data is a discussion, not a sub-group. Unclear how to proceed. @ahdinosaur @bobhaugen @elfpavlik @tiborkatelbach and other LOD/vocab people, any thoughts? (Partly I'm just trying to learn about the loomio dynamic too.)

i've been thinking about subgroups like the Open Vocab group and am feeling there are at least two types of subgroups with the Open App Ecosystem:

1. groups focused on a single deliverable (valnet, craftodex, ipotables, etc.)
2. groups focused on a single dimension of intersection (Linked Open Data, Network Economics, Interface Design, etc.)

@lynnfoster as for specifically Open Vocab versus Linked Open Data, i see them as more or less the same. i started calling it Open Vocab because i got the openvocab GitHub org, but it's intended as a way for us to collaborate on the intersections of our Linked Open Data, in whatever way makes sense for the various teams involved.

@ahdinosaur said: as for specifically Open Vocab versus Linked Open Data, i see them as more or less the same

I'm completely good with that.

In terms of our process, does that mean that we should create a sub-group in loomio, which corresponds to our (somewhat disjointed yet) group working on LOD? And/or one for each working group, like network operations, agent/person/org, etc? Or some matrixed type thing per your 2 sets of groups?

@ahdinosaur @lynnfoster

I like Mikey's two subgroups, but have some questions:

A. Some deliverables will have significant intersections on the same dimension, e.g. ovn and ipotables in economic networks (not sure that is the same as Network Economics, but if it is, good). How do we deal with that?

(I do want to get valnet off the table, I don't want the ovn vocab to be about a single software project except where we can derive ideas from that project. I think other people are also working on OVN software, or situations that are roughly similar. Valnet is limiting.)

B. Are LOD, Network Economics and Interface Design similar enuf to be in the same dimension? Or is Network Econ a different dimension? (As in the concurrent discussions about various methods of funding.)

C. Where would you put the LOD issues that are not about vocab? Or are they so much the same that they can be combined? E.g. like the meta-discussion about corporate biases, or noobie questions like which domain do reciprocal relations live in, etc.

@bobhaugen

A. each team is independent and autonomous, they are free to do whatever feels right. some teams might want to focus more on delivering their "product", some teams might want to focus more on expanding the collective knowledge of the dimensions they are in, but both approaches are valuable and i think teams with different approaches will benefit from cross-pollination.

B. i think those are all different dimensions. i'd rather we have many narrow dimensions than a few really broad dimensions. for example, i'm starting to think the Technical subgroup is too broad, instead maybe it's more appropriate to have many groups for the various high-level protocols we interoperate with, such as Linked Open Data.

C. i think you should do what you feel is best, in my opinion these groups should be loose and flexible, not rigid and static.

@ahdinosaur - I'm good with that (A, B and C)