Process

Based on the technical discussions going one, we're all pretty excited at the moment and exploring a bunch of technical areas.

This is a challenging project from a software project management point of view because of the need to define clear APIs between apps and the lack of certainty at present about what those will look like.

At Enspiral, we're always a fan of decentralised processes. However, we may need some central coordination here to pull this all off. This need not be the same as a power structure of course.

There are a few different structures we could take, but the obvious one is to nominate one person to facilitate the process in scrum-master style, and perhaps one person to play lead customer. In practice we'll have multiple customers at once, so someone needs to act as a filter an facilitate the balancing of those various needs.

I think also that it'd be good to all be aware of the various strengths on the team and make sure they are fully utilized. Additionally, on this project we would like to collaborate more fully with outside parties than we sometimes do on projects that are just Enspiral ones. We've had folks such as @ahdinosaur come in with lots of prior knowledge of this area and we do want such people to feel a sense of ownership of freedom to explore their ideas. We don't want to give the impression that we know everything and want to re-invent everyone else's wheels.

And finally, it has been suggested that awesome comms should probably be part of this entire process. What do people thing about doing this in the public square? That might include rolling cobudget into this comms process, and having someone focus on the comms and outreach stuff (Alanna maybe).

I'm in favour of getting some clear roles and accountabilities going in this team and would be keen to experiment with a holacracy inspired process for building it out.

Agree that folks from awesome comms should be present but I don't know if inviting the whole team in is the right solution, to me it feels more like we need people in awesome comms roles.

I like the idea of naming one or two key roles we need right now, give them some clear accountabilities and then start to fill out more roles as needed.

On a related note:

Vitaly and others from Camplight are keen to contribute to App ecosystem. From email:

"@Simon - Can you do a prioritization for the Enspiral Apps? Right now we're juggling from finding client work and working on Camplight improvements. We can do some code retreat and focus on one of the apps, if you wish to collaborate of course. Do you have wireframes that we can start coding or some product owner/team lead that has some domain knowledge and has done the conceptual part? We've strong competencies with Nodejs (mainly because of Boris - one of the founders of Camplight), front-end (without Angular || Famous :D), brand development (Deny from our team is excited of the possibility to work on something open source :)). We're planning a big revamp of our current website2.0. For version 3.0 (the version number is because we're entering our third year of existence) we plan to have something similar to identity.enspiral.app where we can list profiles of Camplight members. I'm looking forward discussing this topic with you :)"

How do we feel about opening this up and inviting Camplight folk in here?
@craigambrose's comment suggests yes. @ahdinosaur isn't really an outsider as I'm assuming this collaboration is under the auspices of becoming part of Crawftworks.

just put some ideas in the context about a vision for longer term network structure. I think having something like this would help people orient themselves in the ecosystem network.

i want to work full-time on the App Ecosystem and, as @simontegg says, hopefully as a part of Craftworks. i’m happy to fill whatever technical role the group wants me to fill. :)

@joshuavial, i like the proposed network structure. my only contribution is that i think there should be a 'sysadmins' / 'operators' primary role separate from 'completers' focused on just the deployment of apps.

@ahdinosaur good point - added a devops role

@joshuavial I didn't mean invite the awesome comms strategy group, I just meant that we should have awesome comms. :)

@simontegg I'm happy with an initial strategy of inviting everyone into the room who wants to be here, and then figuring stuff out.

Some personal thoughts from me.

• I think it'd be great if whoever was facilitating our process wasn't @joshuavial or myself. I think Josh is out of the question at the moment with EDA, and while I could probably afford the time, I'd really rather be involved at the code level. I think we should hunt out someone at Enspiral who could fill this role, even if that means looking outside of Craftworks. Random possibilities that come to mind include Corinna or Bekka.

• It feels like this area includes a huge amount of prior art that I'm not up to date on. I'm barely staying abreast of some of the technical conversations. However, I like the stuff I'm hearing from Mikey, Simon, Dr Craig and others. I'd probably like to dive in and work on something specific, although we may not be quite there yet.

My top pick would be @alanna - she would need budget though, but if we could pay only one person it should be her imho.

alanna's got heaps of job offers and pressures on her time, so unsure.

I get nervous about this conversation 'cos I can do both internal and external comms (that's what I'm mostly doing today) and that's what I mostly did at loomio.

So I could do this role, but not my passion. Splitting your brain between wide-angle lens (comms) and narrow focus (code) makes me less productive overall, And the appeal of Craftworks was "ah finally, mostly code" :)

Alanna did indicate that she might be available for one of our wacky projects if we gave her some warning and lead time and she were to disburse some of her foundation responsibilities. Overall that might be something that she's keen on, but I don't think we have reliable sources of funds at present (unlike the foundation), so we may not be in a position to make that offer.

Can we bring in to this thread some discussion about what the application (or applications) do? i.e. what are the functional requirements? The discussion description really just describes a data structure, but doesn't really describe what a system using that data structure might actually do in terms of functionality.

For example, each of the roles has a description of what they do, but what does the system do in support of those roles? As a "developer" I want to use the system to do "....".

Do the roles above have anything to do with the software requirements @craigtaubeschock? These aren't roles in the sense of user roles for apps. They are roles within the development team.

I agree on the need to have some real functional requirements based on real needs. I also think that the above process doesn't have enough of that. It puts it in the court of "relators" to understand the customers, but I'm not sure that's quite right.

@craigambrose Isn't the app ecosystem something that is supposed to support how enspiral works? If it is, then the roles of the people involved are directly related to software requirements.

My impression here is that we're trying to build a framework that will become the basis of future enspiral apps, and frameworks are by their very nature abstract. It's difficult to create good abstractions if we don't have something to abstract from, which means that we need a sense of who is going to use the system and what their requirements are going to be.

What often happens when people create frameworks is that they make too many assumptions about how that framework will be used, and that translates to a lot of work put in to a framework that doesn't really work or is really difficult to use.

I don't think we're building a framework to assist organisations build frameworks though. Enspiral is one customer, but it's more "enspiral as a network" and "democratic companies within enspiral" that are the customers, rather than the open-app team.

I thought that this was part of "open-sourcing enspiral", but I could be wrong on that. i.e. build software that supports enspiral's business processes, and then open-source that software as part of the broader plan.

So, the question I would like to answer before any questions about structure are considered is who are the users of this and what do they need it to do?

I think that we could probably identify a bunch of users within Enspiral alone.

1. Enspiral Services needs to run a company where people manage their own money within a shared structure. Accounts functionality (currently in my.enspiral) needs to talk to participatory budgeting, invoicing, etc. Enspiral Services also makes online decisions, needs groupware features etc.

2. Teams within Enspiral Services are semi-autonomous but need to be aggregated into a larger whole.

3. The enspiral network needs internal comms and distributed decision making.

4. Living economies needs to manage groups of people wanting savings pools.

5. Commonchange,org wants to facilitate groups of people who donate money into a central pool and then choose where to donate it.

There might be some confusion here because the structure is somewhat self-describing - fractal orgs and all.

Yeah... just ignore my brain far above. I was just confused.

Not sure why @craigtaubeschock thought he was confused. He was making a lot of sense to me. But maybe I'm confused?

I think I have at least skimmed everything I could find about the Open App Ecosystem (which is a great name).

Got some beginner questions. Not sure this is the place to ask, but if not, please suggest where?

In this Loomio discussion https://www.loomio.org/d/dikva3ZO/valnet-software @joshuavial suggested "lead routing" as a possible focus for some collaboration between valnet and Enspiral, and thus maybe between valnet software and the Open Apps Ecosystem (which we do not exactly fit into, but what the hey).

Turns out that one of our most recent deployments, http://tip.webfactional.com/ , is interested in a process flow that they call "onboarding new clients".

Could be the same thing? Something concrete to do together?

What do you all think? And where should I have asked this question?

My thoughts about Process / Roles:::

I think the conversation about structure is intrinsically tied to a conversation about the long term stewardship of the OAE (another thread), so I will focus on responding to roles here rather than structure.

I am skeptical about the primary and secondary roles idea- perhaps partly because I don’t see myself in the roles defined. At this point I’m doing wrangling, development, relations and eventually hope to contribute to design discussions. I also really dislike the idea of calling myself a “wrangler”, “designer” or “developer” specifically. In my view it goes against the craftworks mentality of pursuing mastership at your craft. I might say I consider my craft as “full-stack entrepreneurship”, which is broken here into a bunch of tasks that sound restricting. I want the roles/circles system to enable me to exercise my skillset across domains, roles and teams.

That being said, I think having defined responsibilities is essential to delivering high quality work. I would like to focus on making sure that responsibilities get covered- and perhaps use the “roles” system as a vocab for onboarders and for those who would like to limit/manage their responsibilities.

Another strategy could be to systematize our signaling- ie, having one place people can go to and look at what needs to get done. Then people can pick up tasks openly with clear deadlines and review processes outlined beforehand. See here for example:::http://edgeryders.eu/taskmanager

As for the questions about resourcing facilitation, I would be very open to facilitating to whatever degree folks are comfortable with :). I can be somewhat flexible- as I have some contracts (some OAE some not) just about ready to go, and could take as much or little time from OAE to make money to live in the meantime. My preference would be to work full time on OAE, balancing development, design, relations and facilitation.

From Craig Ambrose:::

we may need some central coordination here to pull this all off. This need not be the same as a power structure of course.

I think this is right on point. I think finding the balance between central coordination and signaling will help distribute the info / power, while still getting benefits of centralized facilitation.

Meant to put @joshuavial @craigambrose @ahdinosaur into the above :)

I'm looking at the roles and see that there's something missing around building "strategic relationships". You know... the role that Ben plays in Loomio. It's not the same as promoter, because he doesn't do any brand stuff or marketing. He just meets with influential people and gets their support on the project.

It's incredibly valuable, and I have a hunch that Joshua has already been doing a fair bit of this for Open App.

I feel like I could be doing a lot of work to add value in the strategic relationship area, if I had a more defined role in the project and the information flows were in place to make it possible to stay in the loop.

I've edited the context to talk about hats instead of primary roles. The idea a hat (need a better name) is that it is context independent and people take them with them no matter what circles they are in.

Roles on the other hand are context dependent and come associated with accountabilities and domains (authority).

@alanna and @jonlemmon I saw that sort of stuff being covered by the relator hat and have updated the description to cover clients and partners instead of just clients.

@derekrazo I find that entrepreneurship naturally spans disciplines and that while most people will wear multiple hats entrepreneurs particularly will. I picked verb based names for the hats to reflect that they were describing the actions people did in a group with the expectation that people would pick up multiple ones. I'm not too attached to any of it and happy for different ways of signalling people's capabilities to the group which is really the only reason to have hats.

on the flight to NZ i read about half of Producing Open Source Software and i do think it describes well what we are doing and gives some good insight on the standard process of open source projects. i highly recommend reading it if you haven't, i'd be happy to purchase paper copies for people but i believe the online version has the second edition updates which aren't ready for print.

@ahdinosaur I read that book a couple years ago when we first started building Loomio. It was a good read. Although, the author who wrote it is speaking from experience of building SVN, which is dev software which operates in the terminal, as opposed to consumer-facing web software.

So some of what he says seems a little bit out of date or not quite applicable, but then a lot of what he says is right on. Particularly about how to deal with frustrating people in OSS communities. :D

May be this is not the right place but reading the thread I can't resist to share:

At Camplight we are organizing development processes around initiatives. Every initiative on its own has a team, and every team member brings in his own hat. Initiatives vary in structure, members, roles/hats depending on the goals and the needs. The 'trick' is that one initiative usually forks others and this way we produce a good graph of connected but distributed teams all having the ability to operate in the best possible way towards achieving their initiative goals.

Actually we use the same technique for every action which the cooperative needs to organize and execute. For example outsourcing software development to a particular client is just one initiative. Joining Camplight member is second one and making a decision + executing it is third one.

So my point is that roles, hats and circles are all domain specific to the initiative/process been executed.