Re: [Debconf-discuss] [penta] Evaluating new conference software: Comas (reloaded)

[Gunnar Wolf <gwolf@gwolf.org>]

Basic info
----------

Software name: Comas
	       Note that this is *not* the Comas we used in
	       2005-2006. The name was retained due to the author
	       being quite stupid ;-) But it does not share a line of
	       code with it, not even the database structure.
URL: https://github.com/gwolf/comas
License: GPL
Last sign of upstream activity: 2012-03-28 (although the activity is
	       *really* low lately
Programming language: Ruby
Supported database backends: PostgreSQL
Supported authentication backends: Internal only, although it should
	       		 	   not be too hard to add others

DebConf requirements:
---------------------

Ability to manage attendee data:

   This is one of the reasons I started the reimplementation of Comas:
   To make it as easy as possible to add extra information to the
   basic attendee and proposal (what in Penta we call person and
   event). Just add a field to the database, it will appear in all
   relevant screens. Add a linked table, it will display the
   catalog. It is *not* as flexible as I'd like, though, and there is
   some hacking for some things regarding attendee details over time
   (i.e. details are added to "person", not to "conference_person").

Talk submission workflow:

   Quite easy IMO... Not much to say about it.

Talk rating workflow:

   Not yet written.

Talk feedback workflow:

   Not even thought of yet.

Reporting ability:

   Not yet written besides very basic statistics

Internationalization capability:

   Gettext-based. There is a bug in Ruby's gettext that is quite
   annoying and I should look into, as it makes it mix languages at
   some points :(

Ability to extend in a maintainable way:

   As I already said, I think whatever we choose will be forked from
   upstream. I mainly use Comas for my work (and the not yet written
   parts are because my work does not need them), but if we chose
   this, I'm upstream.

Any other DebConf features already supported:

   

Have you ever successfully installed or hacked it? Was it hard?

   I wrote it. It was hard. And somewhat fun :)


Overall summary
---------------

Most important strengths:

   Flexible; I'm upstream (although that can easily become a
   weakness); quite standard Ruby on Rails. Works 100% with packages
   in Debian stable.

Most important weaknesses:

   I have not yet working on migrating it to Rails 3.0. It lacks
   important parts for our workflow

Would you recommend we use it, and why?

   Possibly, but you'd have to convince me.