= Coordinating with upstream =

There has been some pinging wrt upstreaming of changes.

Summit has been originally develop by Canonical as a system to manage UDSs.
It's a straight up django application, with a healthy upstream, so we should 
push our changes back up.

Upstream uses a {c,C}anonical bzr repository. The git repository used by DebConf
has actually been creating using whichever of bzr-git or git-bzr that works. 
This repo can be 1-1 converted to bzr and back, which will help pushing changes
back up.

We have an upstream integration branch, which can be pushed to launchpad for
upstream to merge.

vorlon plans to go through the DebConf delta, and start refactoring stuff that
can be pushed upstream.

Workflow : do the local work in git, test it and validate it, then when it's
ready, you can do "git bzr push" instead of "git push" to send it to launchpad.

= Generalizing the DebConf changes for several DebConf editions =

The concern is that for several DebConfs, the "business logic" can change, and
therefore we will need to get different fields.

Django can handle table inheritance, and we could use this to store
"year-specific" data in separate tables.

madduck: although we might be putting too much focus on backwards-compatibility,
when after a year or two, noone actually cares about the look or usability of
a previous site. We should snapshot the site and database post-conference
anyway.

= Requirements collection =
What's not working, what's missing, what's needed for next year.

* Videoteam stuff needs to be completed
 * Volunteer schedule: a way for volunteers to sign up for the 6 jobs
 * Review process: CarlFK has a separate django app (MIT licensed), that does a
   lot more than just help with review ("recording sheets"), and that we might
   be able to integrate with summit.
 * Maybe attendees registering interest in sessions covered to help the video
   team allocate limited resources according to popularity.
 * We might need to take a firm stance on what we can and will offer, and
   manage the expectations of attendees (incl. remote) because right now, some
   people expect streaming for everything and there is not enough manpower for
   this

* For ad-hoc scheduling (and other events), the videoteam would like two fields:
  * "this talk must not be recorded"
  ** This could be because having a microphone and/or being expected to
     interact over IRC changes a session fundamentally and may not be desired.
     We could explore conferencing options like WebRTC, but this should not
     hold back the conference.
  * "it would be nice to record this, but it's not required".

* A better way to plan agenda items: adding slots and agenda items that fit in
  there

* For ad-hoc events, a way to register events by the attendees in summit 
  directly, incl. scheduling them and possibly being able to create slots.
  Counter viewpoint: just having those scheduled on a whiteboard and 
  then entered somewhere (wiki or summit) for people attending remotely. But
  having a schedule post-conference with *all* events will be useful for fund-
  raising.

* Front-desk: allowing printouts for schedule pages

* Front-desk: being able to see locked out fields for users and admins (for
  instance when signups close)

* "What's up" needs to be integrated and/or adapted from the summit built-in view

* deeplinks need to keep working over the years
  madduck: Django surely has a controller plugin to redirect based on URL
  scheme

* SSO things haven't been handled very well and need some ironing out

Other ideas by madduck not discussed:
* roles wrt events, e.g. speaker, host, volunteer, attendee, remote
* roles not visible or limited visibility
* Assassins controller
* Independence of Google fonts and QRcodes
* Create a PDF for attendees with all info about getting there and registering

= debconf.org intregation in summit =

Knowing where the information is is hard (www.dc.o, summit, wiki).

= User Perspective =
- have a single machine and have that using a SSL certificate that is known to
  the SSL mafia
  (not neccessarily a single machine only, but a single namespace) actually two
  namespaces, media.dc.o being the second
- have the next upcoming debconf theme on the www.debconf.org website