[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