Pinax Symposion

Pinax Symposion is an open-source Django project for conference websites.

It came out of development done by Eldarion for DjangoCon US and US PyCon but has been independently used for a number of other conferences.

We are in the process of cleaning things up and making them more generic.

The project homepage is http://eldarion.com/symposion/

Apps:

Conference App

The overall conference settings are managed via the conference app.

Conferences and their sections are added and configured via the Django admin.

Models

Each conference needs an instance of a Conference model. In most cases you will only need one of these but Symposion does support multiple conferences sharing a database. Similar to the Django Sites framework, the conference your project is for is selected by the CONFERENCE_ID setting which defaults to 1 but can be changed to the pk of another conference if you have more than one.

The conference model has an optional start_date and end_date indicating when the conference will run. These are optional so you can begin to configure your conference even if you don’t know the exact dates.

The conference model also has a timezone field which you should set to the timezone your conference will be in.

There is also a Section model. This is useful if your conference has different parts to it that run of different days with a different management, review or scheduling process. Example of distinct sections might be “Tutorials”, “Talks”, “Workshops”, “Sprints”, “Expo”. Many aspects of Symposion can be configured on a per-section basis.

Each section has an optional start_date and end_date similar to the overall conference.

Helper Functions

A conference.models.current_conference() function exists to retrieve the Conference selected by CONFERENCE_ID.

Sponsorship App

Sponsorship is managed via the sponsorship app.

Sponsorship levels and sponsors are added via the Django admin.

Models

Each sponsor level has a name (e.g. “Gold”, “Silver”) and an order field which is an integer that is used to sort levels (lowest first). Each level also has a description which is not currently exposed anywhere but can be used for private annotation.

Each sponsor has a name, external_url (i.e. link to the sponsor’s website), contact_name and contact_email, logo, and level.

A sponsor may also have a private annotation that can be used by organizers to take notes about the sponsor.

A sponsor will not appear on the site until the active flag is set true.

Template Snippets

The easiest way to include sponsor logos, grouped by level, is to either:

{% include "sponsorship/_vertical_by_level.html" %}

or:

{% include "sponsorship/_horizontal_by_level.html" %}

You can get a wall of sponsors (without level designation) with:

{% include "sponsorship/_wall.html" %}

You can always tweak these templates or use them as the basis for your own. This is often all you’ll need to do to display sponsors on your site.

If you want to display a specific sponsor logo you can use:

{% include "sponsorship/_sponsor_link.html" with sponsor=sponsor %}

or:

{% include "sponsorship/_sponsor_link.html" with sponsor=sponsor dimensions="100x100" %}

if you want different dimensions than the default 150 x 150.

Template Tags

If you want to retrieve the sponsors and traverse them yourself, you can use the provided template tags:

{% load sponsorship_tags %}

{% sponsors as all_sponsors %}

or:

{% load sponsorship_tags %}

{% sponsors "Gold" as gold_sponsors %}

if you want to just get a specific level.

You can get the levels with:

{% load sponsorship_tags %}

{% sponsor_levels as levels %}

and you can always iterate over those levels, calling level.sponsors to get the sponsors at that level.

Speaker App

The speaker app allows speakers to set up their profile, prior to or as part of the proposal submission phase. The dashboard is the means through which speakers manage their own profiles.

We are planning to make the Speaker model more pluggable so, if you have particular fields you’d like your speakers to fill out, you’ll be able to customize things more easily.

Additional Speakers

Because symposion supports additional speakers being attached to a proposal or actual presentation, it has the notion of a Speaker that is not yet a User on the site. For this reason, a Speaker may have a NULL user field (hopefully temporarily) as well as an invite_email and invite_token field for the invitation sent to the additional speaker to join.

Proposals App

Models

ProposalSection

Recall that a symposion instance consists of one or more ``Conference``s each made up of one or more ``Section``s.

Different sections can have different open / close dates for proposals. This is managed through a ProposalSection which is a one-to-one with Section where you can define a start date, an end date and/or simply toggle proposals for the section closed.

A section is available for proposals iff:
  • it is after the start (if there is one) and
  • it is before the end (if there is one) and
  • closed is NULL or False

In other words, closed can be used as an override, regardless of start and end and, if you want, you can just manually use closed rather than setting dates.

This model is currently managed by conference staff via the Django admin although given it’s part of “conference setup”, it may often just be a fixture that’s loaded.

ProposalKind

A conference, even within a section, may have different kinds of presentations, e.g. talks, panels, tutorials, posters.

If these have different requirements for what fields should be in the proposal form, they should be modeled as different ``ProposalKind``s. For example, you may want talk proposals to include an intended audience level but not require that for poster submissions.

Note that if you have different deadlines, reviews, etc. you’ll want to distinguish the section as well as the kind.

This model is currently managed by conference staff via the Django admin although given it’s part of “conference setup”, it may often just be a fixture that’s loaded.

ProposalBase

Each proposal kind should have a subclass of ProposalBase defining the fields for proposals of that kind. We discuss below how that association is made.

ProposalBase provides fields for a title, a single-paragraph plain-text description and an abstract which can contain markup.

There is also an additional_notes field which can be used for speakers to communicate additional information about their proposal to reviewers that is not intended to be shared with others.

This base model supports each proposal having multiple speakers (although the submitting speaker is always treated differently) and also supports the attachments of supporting documents for reviewers that are, like the additional_notes not intended to be shared with others.

A cancelled boolean field is also provided to indicate that a proposal has been cancelled or withdrawn.

AdditionalSpeaker

Used for modeling the additional speakers on a proposal in additional to the submitting speaker. The status of an additional speaker may be Pending, Accepted or Declined.

SupportingDocument

Used for modeling the supporting documents that can be attached to a proposal.

How to Add Custom Proposal Kinds

For each kind:

  • create a ProposalKind instance
  • subclass ProposalBase and add the fields you want
  • define a Django ModelForm for proposals of that kind
  • make sure your settings file has a PROPOSAL_FORMS dictionary that maps the slug of your ProposalKind to the fully-qualified name of your ModelForm.

For example:

PROPOSAL_FORMS = {
    "tutorial": "pycon.forms.PyConTutorialProposalForm",
    "talk": "pycon.forms.PyConTalkProposalForm",
    "poster": "pycon.forms.PyConPosterProposalForm",
}

Schedule App

The schedule app allows staff members to create the schedule for the conference’s presentations, breaks, lunches, etc.

The `schedule` app has a number of models that facilitate building the structured schedule:

  • Schedule: A high level container that maps to each Conference Section.
  • Day: A Day associated with a Schedule.
  • Room: A Room associated with a Schedule.
  • Slot Kind: A type of Slot associated with a Schedule.
  • Slot: A discrete time period for a Schedule.
  • Slot Room: A mapping of a Room and Slot for a given Schedule.
  • Presentation: A mapping of a Slot to an approved Proposal from the `proposals` app.

Schedule Builder Form

It can be cumbersome to generate a schedule through the admin. With that in mind, a generic schedule builder is available via a Schedule’s edit view. For instance, if a Conference site has a Talks Section and Schedule, the form would be available for Staff at:

/schedule/talks/edit

The form consumes a structured CSV file, from which it will build the schedule. Sample CSV data is included below:

"date","time_start","time_end","kind"," room "
"12/12/2013","10:00 AM","11:00 AM","plenary","Room2"
"12/12/2013","10:00 AM","11:00 AM","plenary","Room1"
"12/12/2013","11:00 AM","12:00 PM","talk","Room1"
"12/12/2013","11:00 AM","12:00 PM","talk","Room2"
"12/12/2013","12:00 PM","12:45 PM","plenary","Room1"
"12/12/2013","12:00 PM","12:45 PM","plenary","Room2"
"12/13/2013","10:00 AM","11:00 AM","plenary","Room2"
"12/13/2013","10:00 AM","11:00 AM","plenary","Room1"
"12/13/2013","11:00 AM","12:00 PM","talk","Room1"
"12/13/2013","11:00 AM","12:00 PM","talk","Room2"
"12/13/2013","12:00 PM","12:45 PM","plenary","Room1"
"12/13/2013","12:00 PM","12:45 PM","plenary","Room2"

It is worth noting that this generates the structure of the schedule. It does not create Presentation objects. This will need to be done manually.

One can also delete an existing schedule via the delete action. This is irreversible (save for a database restore).

Indices and tables