Different process approaches
Jade Ambrose PublicSeen by 43Hi folks. At the moment, loomio doesn't really have any configurable settings per group that effect how the group makes decision. In many ways, that's quite sensible, and I do usually prefer opinionated software, rather than apps that trying and be everything for everyone.
However, I wonder if this has come at the expense of being able to experiment. If loomio features are all released for all organisations (or none), then it does create a lot of pressure to get them right.
What if there were internal plug-ins that could be enabled for certain groups only. That way, it'd be possible to try out fairly different decision making approaches without having to role them out to everyone. They might not be global settings, perhaps in some cases you simply turn them on from an admin panel in order to let certain groups trial things.
My general feeling is that the loomio roadmap as I currently understand it is too conservative. A lot of attention has been spent on producing a professional product with no bugs, but of all the interesting ways of discussing issues and making decisions that we first chatting about a year and a half ago, not a single one has been implemented.
Perhaps if these things things could be implemented in a way that would only effect certain guinea pig users (like Enspiral) then new features could be rushed out the door with less senior programmer oversight, and if they prove to be popular the could then be cleaned up a bit.
I like this idea a huge amount!
Obviously this is a bit easier said than done from a code perspective. I'm suggesting something a bit rough and ready initially at least.
A "plugin" has a record in the plugins table, which probably just has a name.
A join table connects groups to plugins.
A CRUD interface in the backend allows admins to add plugins to groups.
Initially, the code starts with just @group.has_plugin?(:some_name) conditionals wrapping calls to other bits of code. That's not fancy, it's not some big plugin API really. It could become a mess if one isn't careful.
Also, I'd suggest some ground rules.
- A plugin cannot cause any additional database queries (or visible difference) if an organisation without that plugin views their group or discussions.
- A plugin cannot cause any additional joins or other complexity to existing database queries for groups which don't use the plugin.
I don't think it's initially possible to create a simple plugin API, because one doesn't really know what a plugin might want to do.
Would love to hear what @jonlemmon and @robertguthrie are thinking on this?
This would be great!
@craigambrose that sounds totally manageable. Let's do it!
I'm all in too..
Oooooo
Happy to workshop ideas for how this might actually be done if it helps, but I'm about to to start working for chalkle, so as usual I have not enough time.
Yes