Skip to content
PaulWay edited this page Apr 5, 2012 · 2 revisions

This is horribly old and disgusting and needs a cleanup

  • authentication
  • polish existing CFP interface (3 days)
  • user + groups (3 days)
  • wiki integration for content (2 day)
  • read FISL spec (4 hours)
  • data model for papers (1 day with many)
  • papers
  • turn the FISL spec into a controller (4 days)
  • reviewer (6 days)
  • admin (4 days)
  • user (2 days)
  • data model for registration (2 day with many)
  • registration
  • invoicing + payment gateway (2 weeks)
  • user (1 week)
  • data model for timetable (3 days with many)
  • timetable
  • admin (4 weeks)
  • users (4 weeks)
  • documentation (4 weeks)
  • testing (progressive)
  • docstrings (2 days)
  • writing tests (progressive)
  • buildbot (2 weeks)
  • user interface (1 day)
  • css tweaks (1 day)
  • code structure (progressive)

Notes

  • the data model is the most difficult thing to implement
  • every feature should take between 2 hours to 2 weeks, depending on the complexity

!! Core

  • we need a basic authentication structure, consisting of:
  • users, groups
  • maybe rights and permissions, but groups will probably fit that ok
  • ACLs
  • dedicate a day to build a data model for
  • registration
  • papers
  • timetables

!! Papers

!!! Purpose

Papers is a module for doing paper reviewal.

Paper Reviewers will have access to a list of submitted papers of which they can review.

Paper Submitters will recieve status information about their submitted papers, and will be able to submit further papers or revoke existing submissions.

Conference Organisers will be able to create, update, and delete submissions, as well as list registration information.

!!! Functionality

  • Submitters
  • submit multiple papers
  • add co-speakers
  • see reviewer feedback once final decision is made
  • upload attachments related to their talks (videos, slides, paper)
  • select whether they want academic review
  • Reviewers
  • for each paper, using the FISL rating system, the reviewer will be able to
  • give the paper 3 scores (1 - 5, 0 for abstention)
  • comment on the paper
  • place the paper in a "suggested stream" bucket
  • print out papers for academic review
  • sort and list papers based on certain criteria
  • top rated, bottom rated
  • passed over papers
  • bars and graphs, statistics of individual talks + streams
  • Admin
  • c.r.u.d.
  • submissions
  • reviews (scores, comments, streams)
  • sort and list papers based on certain criteria
  • (see above) ...
  • accept papers into the conference, moves into timetable pool
  • send out acceptance notices
  • automatically generate email informing of acceptance, ask them to register

!! Registration

!!! Purpose

Registration handle conference registration for users. There are two ways to register for the conference.

If a user exists in the system, when the conference registration opens a widget appears on the user's MyLCA page asking them to register for the conference. For users without a MyLCA account, they will be directed to register for the conference from the main page. Users without MyLCA accounts will have an account created for them during registration.

Registrants will fill out core questions about their conference registration (name, email shirt). They will then select optional extras such as accommodation and partners programme. An invoice will be generated, and the user will pay through either the payment gateway or direct deposit.

A user can pass on selecting extras and add them later once logged into their MyLCA.

!!! Functionality

  • Invoicing
  • an invoice is built based on their registration selections (attendee type, dinner, accommodation, see below)
  • for direct deposit, we will need to manually confirm the payment and mark as paid
  • payment gateway will need to mark registration as paid
  • User
  • accommodation
  • asked during registration, updatable once registered
  • enter accommodation type (venue, beds)
  • allocate accommodation based on availability
  • query rooms on days ("X rooms on day Y")
  • partners programme
  • asked during registration, updatable once registered
  • how many tickets do you want?
  • sends out an email
  • extra information for speakers
  • demand phone number
  • accommodation information

!! Admin

!!! Purpose

Admin is a way for conference organisers to administer all aspects of MyLCA system. All components throughout the system should have administrative functionality built in. MyAdmin? exposes that functionality to conference organisers.

!!! Functionality

  • Admin
  • user management
  • c.r.u.d - basic functionality for user management
  • conference registration for users
  • detailed viewed + sorting by types (accommodation, registration type, payment status, speaker, user registration)

!! Timetable

!!! Purpose

MyTimetable? is a timetable organiser for Attendees, and an event planner for Conference Organisers.

Users will be able to select events from the conference programme to construct their personalised programme.

Organisers will be able to place accepted papers and events in slots, to construct the conference programme.

All timetable data should be exportable in multiple formats (iCal, RSS, CSV).

!!! Functionality

  • User
  • select event from the fixed (official) and flexible (user-defined) timetables
  • interactive user interface
  • when you select an event from a timeslot, other events in that timeslot are dimmed out
  • users need to be able to contruct their timetable from both the fixed and flexible timetables (click and drag on a big pasteboard?)
  • create and submit events to the flexible programme
  • export fixed and flexible programmes to iCal
  • place (public) comments, feedback on events
  • event links link to wiki page
  • Admin
  • define fixed timeslots (text file or db)
  • ability to maintain two timetables
  • official fixed
  • flexible, ad-hoc, user defined
  • fill in fixed timeslots with accepted submissions
  • select day, time, room dropdown
  • replace, mutually exclusive

! Overall

  • all components are developed as a core part of the application
  • each component has both the user and admin the functionality inbuilt
  • desktop widgets expose that functionality depending on groups
  • content is managed through a wiki backend (moin)