Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• DebConf6OrgSoftware

<<< DebConf6

As there seem to be some requirements that had not been fulfilled by the software that has been used to support the organisation of DebConf5, and I (HenningSprang) saw people talking about what other tools could be used, I have proposed to go for a structured approach; First analyze requirements for the software, then see what products meet them, or which ones come as close as possible and can easily enhanced with the missing features.

For DebConf6 we used the Comas conference management system. As one of the organizers is (luckily!) upstream for it, after each of the items where it is relevant, I will include its support level in Comas (or a short explanation on why it's not Comas' business ) in monospace font.

Requirements for DebConf6

features needed / use cases that need to be solved

things that can be done by comas, with some additional work

• Registration (The following proccesses need to be supported and all steps should have timestamps on them) - Lacking the timestamps, which have proved to be '''very''' important

  • Online registration, (all their relevant info is recorded e.g. name, contact info, food-preference, etc.) - Done

  • Determine if a formal invitation is needed for a visa

  • Confirmation round a few weeks before the conference starts (during this round people will need to enter when they are arriving and leaving and confirm their registration) - Done. No timestamping yet, though

  • Upgrading of the registration data (e.g. increasing the number of meals, requesting a place to sleep etc... basicly everything that could cause us additional discompfort or costs.)

  • Check-in when arriving at the conference. (The steps below describe the process used during ?DC5) - Not implemented, but easy to do - See comments on some subitems

    • Check identification
    • Mark him as checked-in and record his arrival date if its different then what he indicated earlier
    • Which room is he assigned to?

    • Hand out a key (if a deposit is needed, it should be indicated if the person left the deposit and how much) - Deposit should be tracked by hand, IMHO, as it involves physical objects (i.e. money, a key, a computer). The system should track if he had requested such items, though

    • Did he request a laptop?
    • Handout laptop if requested and take a deposit in return (it needs to be recorded what the deposit was, and a small contract on use of the laptop is signed)
    • Handout the conference bag

  • Check-out when leaving the conference - Same comments as for checking in

    • Receive the key
    • Give back the key-deposit if that person left it previously (record this happened)
    • Receive the laptop when it was borrowed and give back the deposit (record this happened)
    • Mark the person has signed out and indicate day of departure if it differs from the one given previously

  • Late registrants - Should be handled just as normal registrants, only that the system should warn us they registered after the deadline and should not get some stuff

    • Have them fill a form with all appropriate info
    • Print their badge and hand it out
• Talks management

  • Clear moment when voting starts (all talks are know and decided on) - Human-based process - But should be enforced by Comas

  • Clear deadline when voting closes - Human-based process - But should be enforced by Comas

  • Automatic conflict resolution for talks with a lot of votes - Done

  • Generating the most optimal talsk/bofs schedule - Done - Although "optimal" is not a synonim for "perfect" - Making a schedule will always involve humans

  • Lunches and other such moment need to be accounted for - Done - Just keep this in mind when scheduling timeslots :)

  • Not all rooms might be available at all times - Done

  • Type of talk (technical, social, bof, etc.) - Done

  • Online conference calendar - Quite kludgy to produce right now, but we have done it. For simple conferences like Debconf (this means, with less than ~30 talks and not too much overlap), it should be quasi-trivial

  • A place to upload/link slides and info about talk. - Done

• Communication before the event with registrants and other people - Should add a spamming module to Comas, yes. Not too hard.

  • Information is mostly static (e.g. how to travel to the conference, where it is location, etc.)
  • Announcements of major milestones (e.g. registration is open/closed)
  • Press releases
  • Other news

• Communication during the event with registrants and other people - Via mailing lists, but can use spamming module as well

  • Latest news and announcements
  • Up to date information about various issues (e.g. food, network, talks, etc.)

• Volunteer management - A basic version is implemented. Part of what is described here is just information that needs to be static

  • which roles do we need
  • What skills are needed for certain roles
  • What skills can be trained in time
  • When are volunteers scheduled to do their work or training
  • Which volunteers are available
  • What skills do the volunteers have
  • Contact info (email, phone, etc.)
  • Short description of the person
  • Small photo of the person

• Financial management - Hmmm... Although we have an "expenses" table since the original Comas design, we have never implemented it... Does not seem too hard, though

  • Keep track of sponsors
  • Keep track of overall budget
  • Keep track of expenses
  • Overview of available funds

stuff that need and should be done by additional applications but comas

• Organisation oriented communication - Should be made by a mixture of a groupware system and a wiki

  • Regular meetings
  • Recording of decisions and minutes of meetings
  • Planning
  • Other thoughts and stuff to share

• Issue tracking - This should be done by a groupware system instead

  • Keep track of assigned tasks
  • Remind people of assigned tasks
  • Produces an overview of outstanding tasks

• Planner / Calendar - This should be done by a groupware system instead

  • Overview of upcoming milestones or other important moment like meetings
  • Send out periodic reminders of upcoming calendar entries

• Communication after the event - Via mailing lists

  • Photos from participants
  • Final report

additional information/issues

• we should look at ?DebConf5WhatToImprove what we can get from there as requirements for the next debconf software ( especially the sections website and conference management)

• those links also provide information about the requirements of the conference management:

  • http://gborg.postgresql.org/pipermail/comas-devel/2004-November/000040.html

  • ?DebConf5TodoConferenceManagementSystem

  • ?DebConf5COMASTalkScheduling

soft requirements (e.g. how specific things should behave)

• Any web-based software should be available through the debconf.org domain.
• everything should be easily usable

• any data should be easily exportable, because we could need it suddenly in a specific format that's not provided by the system, so we need some generic output that we can adjust to our needs (XML/CSV) - And this will also allow just about anybody to come up with the most creative reports

• anything must work in at least english language, having other additional languages is a plus.
• flexibility: the system should be easily adaptable to specific needs, that might occur on a short notice, and that should be possible to do from as many people as possible, while anything less than two persons is not acceptable

open questions

• can we fulfil all use cases / tasks with a web based interface?

  • GunnarWolf says: I think that most of what has been asked for in this page can be done quite easily. One of the big problems in having any other interfaces (i.e. a GUI thing) is that we need a permanent, reliable connection to the database... A web application will just not be available in case of an outage - A GUI might give us many additional complications. But then again, I am no GUI fan

• of the things that comas can generally do, but need additional work, there often just is said "is easy to do", "is not too hard to add" -maybe we need more detailed information about that like:
  • how much work is needed for them in hours/days?
  • what type of help in coding and testing and designing is needed?
• how will we handle data exchange between comas and other systems needed to do some things?
• which part of the volunteer management can be seen as static (there is a remark saying that)?

Software/Tools that has been used for organising DebConf5

• OpenOffice

  • spreadsheets (budget, etc.)
  • Various letters and documents (invoices, invitations, etc.)
• mailinglists
• dupral
• vim
• Subversion repositories

• List-server - hosted by Lars Wirzenius - lists are available under the DebConf domain

Registration

• Comas

Communication before and after the event

• Mailinglist (debconf5@lists.debconf.org)

• Website (http://debconf.org/debconf5)

• Press releases

Communication during conference

• Information sheets in Conference bags
• Proceedings
• Posters with the schedule
• irc-channel (#debconf on both irc.debian.org and irc.oftc.net)
• Announcements on blackboard in presentation-halls
• Announcements at the reception
• Reception open for any question

Team communication

• Mailinglists (debconf5-team, debconf5-speakers, ...)
• wikis
  • Planning
  • Todo lists
  • Volunteer-management
  • Minutes of meetings

• irc-channel (#debconf-team on both irc.debian.org and irc.oftc.net why on both? one is enough. we should use irc.debian.org A.S.)

• Files in subversion repository to keep track of various issues (reimbursements, invitations status, etc.)

CategoryDebConf