NextSoftware

DebConf next Software

Introduction

This site is about the yearly Debian Conference and the conference management software we use. There are multiple such systems out there, and we want to see if we switch away from the currently used Comas. To make that a good choice lets list what we expect from the Software, so we can, AFTER DebConf6 make a good decision for the future.

To select the criteria and their importance I created a scheme below. If you see or imagine a feature we are missing right now or that is important to have, even if already in the current system, add it to one of the options below. You need to decide how important it is, for example a system to enter talk proposals is of highest priority, where a system to enter the name of participants pets name may be nice, but not really important.

See also http://lists.debconf.org/lurker/message/20060321.102032.9860b9fe.en.html

List of known Conference Management Systems

System	Homepage	Language	Database	Short comment
Comas	[1]	Perl	Postgresql
Pentabarf	http://pentabarf.org/Main_Page	Ruby (Rails)	Postgresql
Commence	http://iaprcommence.sourceforge.net/	PHP	MySQL	Seems to aim at the paper submission/revision and proceedings only
Openconf	http://www.zakongroup.com/technology/openconf.shtml	PHP	MySQL	Seems to aim at the paper submission/revision and proceedings only
VSIS Conftool	http://vsis-www.informatik.uni-hamburg.de/information/conftool.en.html	PHP	MySQL	Seems to be non-free (free for non-commercial use)
Confmaster	http://www.confmaster.net/	PHP	MySQL	Seems to be a service provider, didn't find the download link

Note that this list doesnt mean that any of these programs fulfill our requirements (and many of them will most probably fail, DebConf is a bit special.)

HIGH (we cant live without this)

* It must be free software (DFSG, we dont want to base the biggest Debian Conference on something that couldnt be in Debian).
* It must run on our own server, ie. a system that shares one big machine for multiple conferences, like multiple vendors offer is a no-go! (why?) (Because otherwise it's highly unlikely that we can adapt it to our needs.)
* Have several committees with different priviliges (one to choose talks, one for sponsorship, ...)
* Possibility to massmail visitors / speakers / different subgroups

* Manage Participants
  * Name, Email, all usual personal details.
  * be easily extendible if we want more input fields, like arrival/departure time, GPG-keyid, etc.
  * Preference for room booking (ie who wants with whom in a room)
  * Voting for talks, so schedule can be made for that
  * Participants have different types, so they get different information on checkin (Information for speaker, Information for sponsored people, etc.)
  * There is a reconfirmation system with a deadline, which mails (on admin request) all registered participants to reconfirm they will attend.
  * When there is a change in the person entry they should get email about the change.

* Manage Speakers
  * Send in a proposal
  * Possible to attach multiple files to a talk (paper, pictures, whatever)
  * Get feedback from review committee via the same webinterface
  * Ask speaker question about his proposal
    * BCC to special mailinglist?  Reply-to that list?  / faked from? so that questions and answers get archivied
  * The reconfirmation system checks if all speaker reconfirmed their attendance, if not nags them again and informs the organizers about this.

* Review Committee
  * Look at all proposals, or maybe only at proposals of an assigned track (see below in Talks)
  * Rating of talks, including own opinions.
  * Able to download 

* Manage Talks
  * Talks have categories like "Technical", "Social", "political"
  * Talks have types like "BoF", "Talk", "Round table", "Workshop" with different length
    * types should be freely configurable
  * Assign timeslots by voting system of visitors, to reduce conflicting sessions

* Manage Rooms
  * Rooms have a attribute size, which is then used for half-automatically assigning a talk schedule.

MEDIUM (we could live without, but it would create much extra work)

* Have a test-suite, that (as far as possible) tests the installation of the system automagically. Which means filling in forms, changing values, asking for different views (speaker, room, talks, etc), ...
* syncing fields between the spreadsheet (openoffice) and the database (e.g. for ok'ed sponsorship)
* Have an easy way to delete anything anywhere in the system if needed. Having a "dependency" like system to prevent removals of needed stuff would help here. (Eg you cant remove a room when it has talks assigned).
* Manage Participants
  * autosubscribe visitors to an -announce mailing list
  * find registered participants who didn't reconfirmed
* Manage Speakers
  * autosubscribe speakers to -speaker mailing list
* Manage Talks
  * Easier to search for specific talks, nothing like "If you want to get a list of all accepted talks, first select 'accepted' then click ASAP on your browsers 'stop' button and choose 'talks'"
  * Material shows up where it belongs.  If there's a "Material: " field on the website, submitted material shows up there, not on the top of the website
* Manage rooms for participants, eg who wants to stay with who else in a room. Manage rooms so that most wishes are fulfilled, but having the best schedule for the minimum amount of rooms.

LOW (would be nice to have, but wouldnt create much extra work if not existing)

* Manage Talks
  * Talks can be set for a "track", like "Debian Day", "D-I", etc.
  * reporting a la munin.debconf.org

* Manage Rooms
  * Rooms can be scheduled for tracks, ie one room for D-I related talks. Then the scheduling will only assign matching talks to this room.
  * Print complete track for a specific room

* Manage speakers
  * Checks, if speaker confirmed their attendence and later checked in; tells $speaker_manager that speaker arrived

* Manage the budget, so we could get away with OOo in one more place and have all at the same location.

LOW (would be nice to have, but wouldnt create much extra work if not existing)

 * rating for talks / sessions for visitors, so we can determine a "best session at debconf" (with a small prize) and know which talks were so worse, so we might not want to accept their speakers for upcoming debconfs
 * Rating should have several categories (e.g. importance of topic, speaker, etc.)

BLACKLIST (We do NOT want this in the new system)

* Development on the production server. Next year we will have two installations (maybe syncing the database from production to development) and everyone who makes production unstable gets some punishment.
* Software that doesn't scale very well; it *must* work even if several people use it at the same time.  It's a clear no go, if we have up to several minutes idle time during a meeting, because the software is so slow