[wplug-plan] Loomio review
Justin Smith
justin at js-wordsmith.com
Wed Dec 12 11:34:31 EST 2012
Pat put together a fantastic review of Loomio that summarizes our
experience with it over the last couple of days:
So, I've spent a little time looking at Loomio over the last couple
of days. It's a nice system, for what it does.
Before I start to describe my experience, I want to make it clear
that (unless otherwise indicated), things I point out as issues with
Loomio in no way means that the Loomio system is "bad" or broken,
and in fact it does what it's designed to do (building consensus
online) fairly well. Issues I point out are just things that an
organization like WPLUG would need to consider before attempting to
use this tool (or any tool of this nature). I'll also point out
that the Loomio system is evolving and is in active development -
things that don't work today could very well work tomorrow. On the
other hand, things that work today could be broken tomorrow, in that
people are actively touching the code in many areas.
It turns out that the system really does require PostgreSQL (I don't
know if it'll work with MySQL, I didn't try - but it definitely
doesn't work with sqlite3, it mostly came up but then the app fell
on it's face as soon as I tried to create a group). It also really
does require ImageMagick, presumably for drawing it's pie chart
graphs. As this is a Ruby on Rails application, it of course also
requires a properly functioning Rails environment. It is actually a
fairly sizable app (it pulls in a *lot* of Ruby gems), which is
somewhat surprising given the limited functionality it offers at the
moment. In my experiment, I ran the system both using the
standalone server (invoked as "rails server"), and deployed under
"passenger" with it's embedded ngnix web server . The passenger
setup was significantly faster (which is not surprising). I didn't
attempt to run it as a Rails app integrated into Apache.
Loomio's model is very simple - it supports creation of groups
(online communities), and subgroups within those groups. Groups may
be open (anyone can join), or closed (a group administrator must add
people to the group manually); only those who are members of a given
group may participate in that group's discussions and voting. Within
each group or subgroup, it allows discussions to be conducted, and
allows proposals that result from those discussions to be voted on.
It is essentially a very simple discussion board with integrated
voting.
Proposals that are put up for voting can really only be of the form
"Should this proposed thing be done?", in that each proposal can
only have four specific answers, which are hardwired into the
system: "Yes" (indicating agreement with the proposal), "No"
(indicating disagreement with the proposal, but a willingness to
live with it if it's what the group wants), "Block" (indicating
strenuous disagreement with the proposal and an unwillingness to
support it even if the group wants it), or "Abstain" (indicating no
vote one way or the other). All proposals can have only these four
specific responses - no other responses may be added, and none of
these potential responses may be removed.
Given the proposal model, it is not possible to conduct a vote on a
proposal of the form "Of the following alternatives, which should we
choose?" In other words, if you wanted to get votes on "When should
we meet next week - Tuesday, Wednesday, or Thursday?", you can't do
that with Loomio as it's currently implemented.
In the Loomio system, all votes are public. It is possible to see
how any group member voted on a proposal, and it is possible to see
which group members have not voted at all. Group members may attach
a comment to their votes, that presumably may be used to provide
some explanation for why they voted the way they did. Votes may be
changed at any time up until the proposal closes. These features
encourage discussion and negotiation on proposals. Unfortunately,
this means it is not possible to conduct any kind of secret ballot
with Loomio. Even if secret balloting were supported (in terms of
how the voting results are presented in the app), the way Loomio
stores voting records would allow anyone with administrative access
to the underlying database to determine how any group member voted,
or even modify anyone's vote; this could be seen as undesirable,
especially if the people managing the app are the same people who
would be bound by the results of the voting. Some organizations
might be comfortable using a system implemented like this only if it
were hosted by a third party with no interest in the voting results.
Technologically, the app is fairly clean from the user perspective,
but there is no administrator interface to speak of at the moment.
Administrative operations (such as adding users, and changing
passwords) have to be done either by starting a "rails console"
session and typing the appropriate Ruby method invocations directly
at the app, or using "pgsql" to operate directly on the underlying
database's tables. One user-visible administrative issue is that it
is currently not possible for a user to change his/her own
password. It also appears that, at least at the moment, login is
done over an unencrypted connection, which (of course) is bad. I
would expect all of these problems to be addressed as the system
evolves.
In conclusion, Loomio is nice for what it does, and shows some
promise, especially in view of the fact that the system is still
evolving. But at the moment, it really doesn't provide anything
that you couldn't get by, for instance, using a phpBB message board
and implementing voting on threads (in fact, that is actually more
flexible, as things stand right now).
He and I have started looking for alternatives that are more polished.
If you know of one, let us know. Keep in mind that we don't necessarily
have to stick to software that's 100% complete; if it's just missing a
few odds and ends, it might be fun to set aside a few "coding days" to
work on it as a group. Wouldn't it be cool if WPLUG used FOSS that it's
helping to develop? It's an interesting idea even to me as a
non-programmer. I'd be willing to help with documentation.
--
*Justin S. Smith*
Electronic Communication Specialist
724-612-2837
http://www.js-wordsmith.com ? My résumé and references
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wplug.org/pipermail/wplug-plan/attachments/20121212/14dd1f47/attachment.html
More information about the wplug-plan
mailing list