Good things that keep us in Penta
=================================

- Keeps DebConf's unique, complicated workflow in a centralized place
- Handles lots of different information flows
  + But it ends up "leaking" to the wiki many important points
- We have six years worth of information in it!

Main points we are tired of with Penta
======================================

- Too low hackability
  + Logic is too twisted, defined in too many nonstandard places
  + Too complicated (impossible?) to install on a standard Debian system; 
    procedure to get involved requires an account in cletus (for testing) and
    one in skinner (production).
    * Testing system is almost useless, due to being very slow and having no
      real data to test against; would have to populate to do anything useful.
- We *intended* to keep syncable to new upstream releases (even though the code
  is now dead upstream), which led to a VERY ugly namespace load — Working with
  the DB requires LOOOOONG SQL queries with lots of JOINs. Too much pain for no
  gain.

Possible plans
==============

A. Stop bitching. Stay with penta. Love penta.
   - Prerequisite: Train a new penta-monkey, this one gives up.

B. Keep the current Penta instance alive, start with a fresh install

- How valuable is to keep the old information?
  + Can we just keep a static version, selected people with 
    access to the DB?
    * i.e. for rating future year's sponsorship requests
  + Frab *does* have a Pentabarf importer, but it does not
    deal with the debconf.* namespace

- DebConf-specific workflows implemented in Pentabarf
  + Videoteam
  + Assassins
  
  
  
* TO MIGRATE AWAY
  Moray: We could migrate out data table-level, so we don't have to support 
  a running penta instance forever
  
  via IRC from edrz: most relevant historical stuff to preserve is the talk schedule, talk data, links to videos, etc. which could be exported to a static site since it's never going to change again.


* Separate to one big system? To many smaller ones? (with single-sign-on?)
  - Might not be *so* simple, as there is nontrivial shared information (dkg)
  
* Gaudenz has a running frab instance \o/   But it's basically just a talk reception system
* Gaudenz suggest looking at the software used at UDS or LCA (linux.conf.au), or pycon (symposion)


fitoria points out symposion: https://github.com/pinax/symposion used by PyCon, also handles sponsorships already
AFAICS symposion is only to build conference websites. The sponsor part seems to be about companies that sponsor the conference
and want their logo on the website, not about sponsorship of participants

Jimmy: What other systems exist for the core conference management functionality in ways that can be extended in a maintainable way to meet our needs? A list to explore: http://feeding.cloud.geek.nz/2010/05/list-of-open-source-conference.html - OpenConferenceWare and Zookeepr probably are worth looking at from this list.


Potential hacking volunteers from the BoF (in entirely meaningless order): Rhonda, Gaudenz, Jimmy, Gunnar, fitoria, Didier, Eivar, Edgar, moray, edrz, .....

High priority in new system:
- Attendee data (new design already started by Moray and Richard)
- Talk submission workflow
- Submission rating
- Talk scheduling
- Talk slides
- Talk feedback
- Travel sponsorship requests and rating
- Videoteam workflow
- reports about various things (e.g. darst's scripts or equivalents)
- log of all changes (e.g. via PostgreSQL database triggers)
- Internationalization capability
- Front desk operation (currently only registration) aspect

Low priority (sorry):
- Assassins
- Events (during the conference) registration
- Payment for items (probably best to keep separate)
- Cheese and Wine party tracking (currently wiki)
- Individual language localizations