Loomio Roadmap

I figure I might as well take the initiative and kick off a discussion in this new group. Just wondering if the Loomio developers have a current roadmap document? I've found it increases my confidence as a user/ advocate in recommending free code software to other users, or an open source community to developers, if I can see a plan (however provisional) for future development through a few versions.

Once you have the skeleton of a roadmap, you can start to look at any given feature request and figure out where it fits in the community's priority list. Let's say you are using the tradition milestone[dot]release[dot]update (eg 1.1.2) versioning schema. User requests can be divided into:
a) low-hanging fruit: a quick bugfix, or minor modification that makes a noticable difference to users. This can go on the map for the next update (eg from 1.1.2 to 1.1.3)
b) top-of-the-tree fruit: a more complicated bugfix, or a significant code extension to add new functionality for users. This can go on the map for a future release (eg from 1.1.3 to 1.2)
c) next year's fruit: where some code refactoring or even a major rewrite is required to fix persistent structural bugs, or make the architecture sturdy enough to tack major new feature code onto it without breaking things. This would go on the list for the next milestone (eg from 1.2 to 2.0).

I'd say the current Loomio Feature Development Roadmap probably looks something like this:

1. Finish up implementing the features we highlighted as necessary for pre-release
2. Get ready to start scaling - implement features necessary to facilitate large groups decisions (e.g. comment sorting/filtering, vote delegation, etc.) & improve the performance of the app
3. Continue improving upon the basic features of the tool (e.g. implement concurrent proposals, multi-group discussions/decisions, etc.)
4. Implement a plug-in architecture so that anyone can build features into Loomio without needing to get approval from the community

How's this sound to everyone else? It it worth agreeing upon and writing down somewhere? I can just imagine it quickly going out of date... I wonder if this features group itself can become the roadmap. =)

I like that naming convention Strypey.

I guess my main question Jon is at which point do we start the plugin process? How do we figure out what features are "core functionality" and which ones should be plugins? If everything's going to be API-fied, does that mean the every feature is essentially a plugin? What does the backbone that everything is plugging into look like?

Can you tell that I don't really know what I'm talking about?

Ah I meant to mention that that list is not completely linear. Some of those items might be happening at the same time as others.

@Rich - in terms of how to decide which features are core functionality and which are plug-ins... I think we play it by ear for now. But basically, we can start out by keeping what we think of as the MVP as core-features, and anything else as plug-ins.

Eventually I think it could be cool to move even the discussion and decision features into plug-ins that could be swapped out for other ones, but all of this is stuff that I think is much better to address when the actual need arises.

I'm not entirely sure what the plug-in architecture will look like. We're going to have to ask around and do some research to see what other successful plug-in architectures look like.

I think it would be great to have a "future wish list" section where we can talk about all the really exciting big ideas we have for features we know are a long way off, but are pretty inspiring to think about.

Alanna is this group not just that. If we agree on a way to label or tag new feature discussions so each is easily recognizable from the groups page, we should have that list already in this sub group.

@ Alanna
I agree and that's really what I'm proposing when I talk about a "roadmap". The structure I described in my initial comment is one way of organising the wishlist, and prioritizing the wishes. This is useful both for users who want to see how far away their pet feature desire is from being realised, and for developers who are figuring out how they could contribute.

@Aaron
I like your idea, but I would see it as a reference tool for creating and updating the roadmap, not a substitute for it. What I'm talking about is a well-organised document that includes everything from imminent fixes to long term dreams (see my original comment). If it's done right, this can be used to generate documentation (changelogs etc) for each new version released.