Collaborative Technology User Group?

Great idea, @lynnfoster — so important that we ensure that the apps (etc.) developed under the OAE banner, perhaps coordinated by the CTA, actually answer the real needs of real users: ourselves, yes of course, but that's a small band, and it would be so helpful to receive input from many others. Naturally, we need to be discriminating: many users just use what's there, the dominant apps, because they are free and their mates use them. So I guess we could try to interest groups led by less technical motivators, like the transition movement; all the groups that one sees through resilience.org, Commons Transition and the P2P Foundation.

User are always important but before taking it any further, let's try to concentrate on creating something truly usable, a new kind of POIC : Proof of interoperable concept, with strong interaction between our technologies. Let's get them to talk to each other , create more intelligence than being in distributed silos. Maybe then, it would create a real reason to build a name and give further objectives.
I like to feel the first kiss before gettting married or simply choosing to stay unmarried but connected.
Let's get this core system running, something truly usable and scalable, interconnecting 2 or more systems, and then let's start dancing.

Don't you think all this structural talk is a bit prematured ?
Let's interoperate openAppely and go from there.
I think we all agree that the next big thing to do is to organize a great distributed beer festival celebrating around open methodologies, standards, protocols and data. but first let's get our pipes sorted. what do you think ? :-)

Nice idea Tibor @tiborkatelbach, of a "POIC", but I'm not clear what it would set out to "prove" and what would count as "proof". I like your analogy, too :smiley: but then I remember that a kiss isn't much to go on, and may be implicated in hasty and difficult marriages!

So, really, I don't think that all structural talk is premature here. Sure, it's always interesting and informative to do some practical prototypes, and I would certainly encourage that, provided that not so much is invested that the prototype builders are too firmly wedded to their own particular ways of doing things. On the other side, I might well agree with you, and I guess none of us are suggesting that all the "theory" can be worked out before things are built. I am suggesting a middle way: do try to get a decent grip on user requirements, and do get some initial sense of the vocabulary / ontology space, as these things may help collaboration.

So here's a challenge: how can you be sure to go ahead with prototyping an interoperable system like this, and remain open to the modifications that will inevitably emerge as needed if new groups of users are to be properly served? How can you best support collaboration between people working in this area? How can we help people avoid blind alleys and other wastage of effort? If you have a particular methodology that you think clarifies where good chances of that exist, I'd be interested to know more.

@tiborkatelbach sure! We need pipes before beer will flow

@lynnfoster I like this idea. I come from a "user needs" point of view, so see testing as essential and am always trying to think of the users' needs. I actually see the CTA as providing this functionality for its' members. Any group that is part of CTA could call on CTA members for testing.

So I agree - but see this as something that comes a little later

Thanks guys! @tiborkatelbach and @olisb I suspect you are right about any big structural effort around user groups being premature. On the other hand, if any specific effort we are making can be done for and in collaboration with one or more user groups, I think that dimension is extremely valuable. We have taken to calling it "participatory action research", a term we borrowed.

On the other hand, I'm not saying we shouldn't proceed with the work we have started here, I think it is awesome!

So here’s a challenge: how can you be sure to go ahead with prototyping an interoperable system like this, and remain open to the modifications that will inevitably emerge as needed if new groups of users are to be properly served? How can you best support collaboration between people working in this area? How can we help people avoid blind alleys and other wastage of effort? If you have a particular methodology that you think clarifies where good chances of that exist, I’d be interested to know more.

we build on use cases as it is often the case in the digital field : fail , keep what works, start again in a loop. Always based on real case request, and not being afraid to fail and redo the work. I find important to lock onto 1 or 2 scenarios with small groups that would take those scenarios to a functional version and move up. These types of collaborations and experimentation is the basis of our organisation.
Just like Mikorizal working with many groups, Communecter is made up of 4 open projects or digital, social, societal experiments that finally merged together because we had more in common than we had differences. And we just keep on going :-), slowly but surely untill the real change occurs.

Such a group might guide the OAE with requirements and ideas and testers, for example, but would not try to manage the software work, which should be managed by the software workers.

Sounds great to me. Here's a relevant bit of my Dec 2015 blog, during the busy early days of CTA in Hylo:

Collaborative software serves as an interface of social technology and information technology. It inevitably straddles both worlds with a dialogue between the desired and the currently possible. That dialogue can improve, and extend, indefinitely.

Communities don’t need designers to tell them what kind of social technology they want, or should want. Likewise, designers don’t need to unconditionally limit themselves to the desires of current communities.

To me it's all about dialogue and adaptation.

More specifically and practically: I think that communities and software developers should talk and work together to develop mutually useful specifications for components/modules in an Open App system.

(We could call those specifications "specs", "standards" or "protocols". All of those terms are potentially valid.)

I think the other benefit of such a CTUG is that it could include many different organizations who want to use various collaborative technologies (not just those being developed in OAE) and discuss what is working and not working and what they need that nobody is working on yet.

A couple further thoughts. One reason we started this thread was that it seems like there are several people here who are excited and want to make concrete contributions, but aren't devs. This kind of thing offers an opportunity to make use of other useful organizational skills in a way that directly pushes forward the OAE. So it is just an idea (among others) to get on the radar of such people for when it seems right. Or if it seems right, of course.

I also suspect that once something like this gets going, the user groups will want to mostly coordinate among themselves as peers, just like us, and won't need as much ongoing nurturing organizationally.