Design notes for the PyCon Talk Scheduler

UserStories

Project Source Repository

This is my (Ralph Green) proposal for our first project. I plan to start it and bring it to the next Saturday meeting where we can all work on it.

A PostgreSQL database will be created to contain the schedule information. It will have the following definition.

 CREATE TABLE pycon.schedule (
 id                 SERIAL   NOT NULL,
 title              TEXT     NOT NULL,
 description        TEXT     NOT NULL,
 track              TEXT     NOT NULL,
 presenter_list_id  INT      NOT NULL,
 room               TEXT,
 event_day          DATE     NOT NULL,
 start              TIME     NOT NULL,
 end                TIME     NOT NULL,
 resources          TEXT,
 contact_email      TEXT,
 contact_phone      TEXT,
 PRIMARY KEY(id)
);

 CREATE TABLE pycon.presenter (
 id             SERIAL   NOT NULL,
 name           TEXT     NOT NULL,
 email          TEXT,
 phone          TEXT,
 PRIMARY KEY(id)
);

 CREATE TABLE pycon.presenter_list (
 id             SERIAL   NOT NULL,
 presenter_id   INT      NOT NULL,
 PRIMARY KEY(id)
);

It was suggested by J that there should also be a table containing the room names and that schedule should just have an id from that table instead of the room name. That has the advantage of keeping a little of the same information from being entered in many rows of the table. For now, I am not doing this to keep it a little simpler. But, I may change my mind on that, since I do see some advantages.

I envision three kinds of reports that would be generated.

1. Attendee schedule - This is what would be passed out to all attendees. It would show all talks. It would probably have more than one view of the schedule. One view would be a grid for each day. One view would be a list of talks sorted by speaker.
2. Room schedule - This report would be posted outside of each room. It would show what talks were scheduled for that room for the current day.
3. Master schedule - This report would be used by the program committee. It would include all data fields. The resources field would show any thing special that is needed for that talk. This might include projector, special drinks, or whatever. The contact phone number and email would be used to keep track of the speaker or allow contact at the last moment if they did not seem to show up.