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.
_______________________________________________
Debconf-discuss mailing list
Debconf-discuss@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-discuss
