Development viability and practicallity

Would be great to hear from the product team about this: @jonlemmon @richarddbartlett @mixirving @robertguthrie

It's a great topic @rorytb - the core Loomio team would love to have a high functioning participatory design process with our user community, exactly like you describe. However, the reality is we're very short on time and resources and don't have any left over for setting this up properly. Supporting functional collaboration on the level you're talking about requires a lot of conscious work around documentation, facilitation, community building, upskilling new people, etc.

We're really really hoping that in a few months the huge pressure on our time and resources will ease up and we'll have a lot more to give to this very important part of our work - collaborating with all of you in the community.

Right now, the only things that are really possible are: specific feedback on features we're already developing or have already released, helping with the translations (a successful largely self-organizing aspect of the contributor community), and people who already have advanced skills with Ruby on Rails contributing to the open source codebase (although we haven't really had resources to support even this very much so far).

Hi @rorytb. At this stage the group of development contributors to Loomio is under 10, more like 5. And everyone who has time to contribute is working from our main product backlog.

The way I see it, Loomio is a bit young to support a distributed development team, and needs to develop a stable plugin api before that dream/mission can become a reality. We need to complete the core feature set for a plugin api to be possible, and that's our 2014 goal.

Great questions @rorytb!

There could definitely be a lot more visibility on this stuff. Our development resources right now:

• two senior/intermediate developers: @jonlemmon (design focus) and @robertguthrie (engineering focus)
• three junior/intermediate developers: @mixirving, @jessedoud and @hannahsalmon
• @simontegg who has been focussed on metrics/analytics and is about to become our mobile interface guru (right Simon?)
• @aaronthornton one day per week (+ weekends if we're lucky!) doing mostly front-end stuff
• me doing lots of coordination work and a little bit of coding

There are signs that we might be at the start of a tipping point, where we're about to become a mature open-source project with remote contributors. This will lead to a lot more resources being mobilised to speed up development, though that will also involve a lot of coordination work.

Right, I didn't realise the core was so small. I must say you guys have been doing a great job.

I get what you guys are saying. Out of curiosity, with what seems like quite a lot of ideas floating around, how do you prioritise the order in which you add features?

Also, is there a threshold of support that a proposition requites before it's confirmed as something that Loomio will go ahead with?

@rorytb none of our processes are super formalised so that isn't a simple question to answer.

Our principle of 'everyone affected by a decision has a say in it' applies here. That's fundamental to the whole project, but the details of how exactly to enact it are still being worked out!

At first I thought it would be relatively straightforward to just throw every decision out to the community and let democracy do its thing. As we've matured it's become obvious that this can only work if a) each decision is accompanied with sufficient context for the participants to be well informed and b) you're actually hearing from a representative sample of all the stakeholders, not just the confident speakers.

Providing that contextual information and creating that representative sample is incredibly expensive. A big part of last year's work for us was to figure out how to transition from that immature view of "just ask everyone everything" to a more effective and efficient methodology, without compromising on the values that motivated us in the first place!

To that end, we have been experimenting with Agile and adapting it to our needs. We have what's known as a 'product owner', whose job it is to listen to all the different stakeholders and synthesise a coherent list of priorities. The range of stakeholders is immense: everyone from the users in this group that are really engaged with the project, to the silent majority of users who have great insights but are not proactive with their opinions, to the large organisations that help to pay our bills, internal & external experts, and the staff that rely on the project for their livelihood.

I'm currently occupying the product owner role, but it rotates; before me was @benjaminknightloom, and I imagine in a couple of months it'll hand over to the next person. Check out this blog post for an idea of where our priorities are at the moment.

Thanks for raising this thread Rory. We are committed to being accountable to the community, so it is good to check in occasionally to make sure we're not turning into despotic overlords :-P

p.s. this general introduction to how we work might be relevant too.

@richarddbartlett cheers Richard. Not to worry, my questions were purely out of interest it was never meant to be criticism or a show of concern. I've had nothing but praise for the concept since I first saw it.

Thanks for the answers and the links!