Wafer

If you are looking to add a talk to the Wafer instance for DC17 (e.g., to propose an ad-hoc talk), then you simply want to Visit the DC17 page, login, and "Submit a proposal". Rest of the notes below are for those who would like to help develop Wafer:

You should follow instructions from the upstream documentation if you want to install Wafer: https://wafer.readthedocs.io/en/latest/install.html

Wafer is being developed at Github.

The following document describes the wafer "data model", that is the way wafer objects are conceived and their associated Django models. Everything related to rendering and the eventual web page you see is discussed under /UI.

Fiddling with wafer

After you've installed wafer, whenever you want to work with wafer, please make sure you've activated the virtualenv:

cd dc16.dc.o
. ./ve-dc16/bin/activate
# now "(ve-dc16)" should be prefixed to yor $PS1

Hint: as I am using a dedicated user for this, I added the above to ~/.zshrc such I am ready to roll right after logging in.

To get an interactive Python shell (apt-get install ipython for an improved experience…) with a wafer+DC16 context, run ./manage.py shell:

./manage.py shell
import django.utils.version
django.utils.version.get_version()

This is a good way to play around, but don't hold off too long writing scripts. Everything (and more) you can do via the web, you can also do from scripts.

To access the web interface, fire up a development webserver (not intended to be run on a public interface or *gasp* in production):

./manage.py runserver    # pass 0.0.0.0:8000 if you want to e.g. access the server on a vhost from your laptop

and then head over to e.g. http://localhost:8000/ with your web browser. At the top right you'll find the user menu, including a link to the admin interface (http://localhost:8000/admin/), which is auto-generated by Django and allows you to create and update model instances through the web.

Populating the database with DebConf data

Speaking of scripts, there's a simple management helper that can be used to populate your database with DebConf-like test data (feel free to expand…), where the data don't exist yet (it is idempotent). Run it via the manage.py interface:

./manage.py dc16_populate_db

The command is idempotent, so you can run it as many times as you want and it won't recreate existing objects. Should you still want to flush all data from the database, you can so so with the following command:

./manage.py flush
./manage.py migrate

Wafer terminology and DebConf

Let's try to bring you a little bit closer to understanding wafer, especially as it shall fit into the Debian context.

Note: I tried to provide links into the code wherever relevant, but as the source changes, the line numbers will need updates. Please exercise diligence.

Sites, pages, files

Django brings the concept of "sites" to the table, allowing multiple different web sites served from a single database. Since our intended use for wafer is to run a per-conference instance (with static archiving post-conference), we'll be using only a single site. The record in the django_site table to use is defined with SITE_ID in settings.py. Possibly among other things, the Site record influences the name displayed at the top left, if the domain matches the one in the HTTP request.

Everything in wafer that is not a special object (e.g. a person) is a page. This includes events (see further down).

Pages can be descendents of "container pages" to create hierarchies, e.g. for the menus. See the upstream documentation for more information.

A page is generally stored as Markdown text in the database and rendered on access (and cached in the database…). We are thinking about ways of integrating Git here, but for now there's no interplay. See https://github.com/CTPUG/wafer/issues/150.

A change was made for DC17 for storing pages as files in the git repository. pages are stored as files in pages/ with a .md extension. To load local pages, one needs to run manage.py load_pages. This'll need to be pushed upstream at some point.

Pages can be associated with people (n:m), and included in the schedule (see below). Distinct from talks (also below), this allows e.g. tea breaks and such logistics to be added to the schedule, along with the responsible people.

Pages can also have files associated with them (n:m), essentially attachments that are stored on the filesystemi (MEDIA_ROOT/pages_files), but indexed in the database.

We'll discuss site organisation and menus further down.

Open questions

1. How do sites and pages relate?
2. Can pages be rendered differently in different contexts? For instance, a track might be represented by a page, but all tracks should probably have a common template listing e.g. the events, people, rooms, etc.
3. How does one access the list of people associated with a page from within Markdown?
4. How does one access associated files from within Markdown?

Users, groups, profiles, registrations

Users and profiles are centred around the Django authentication system, which is similar to how Summit worked. The following models are in use:

Users (auth_user)

Username and password are stored here and used for authentication, along with first/last name, and e-mail address.

Groups (auth_group)

Flexible n:m mapping without predefined meanings, i.e. we can use this any way we want, specifically as it relates to permissions (e.g. content team can approve events…).

User profiles (users_userprofile)

Stores contact number, biography, homapage, Twitter handle, Github login, and gets autocreated through a post_save signal. The model also offers access to user-submitted talks, and the avatar (handled by libravatar).

Registration profiles (registration_registrationprofile)

Handles e-mailing an activation key to the user and associated verification of the e-mail address.

Apart from the Twitter & Github links, this is all nice and clean. Hopefully, instead of overloading the database with all the fields we need, we can make use of a flexible key-value store (ideally to be implemented upstream). On the other hand, there is a certain set of fields we know we need, so maybe those should go live in a "DebConfAttendee" model.

Open questions

1. Shouldn't we switch to the HMAC-based activation for registration profiles.
2. Can we get upstream to remove Twitter/Github links? If not, how do we hide them, if that is what we want? See https://github.com/CTPUG/wafer/issues/148.
3. How does SSO tie in with this?
4. Core authentication stores first/lastname, but we know this won't work. Do we provide an optional override "display name" somewhere in another model? See https://github.com/CTPUG/wafer/issues/149.
5. A requirement we should address is to allow multiple registrations per authentication user. This would pretty much require us to go the "DebConfAttendee" model way and require data there, rather than in the fields provided by the User and UserProfile models. See https://github.com/CTPUG/wafer/issues/146.

Tickets and ticket types

Wafer is designed for attendees purchasing tickets, which isn't really how DebConf has traditionally worked, but which is something we could look into.

There are two models:

Ticket types (tickets_tickettype)

These map to our registration classes standard/professional/corporate.

Tickets (tickets_ticket)

These are actually instances of tickets purchased. The idea is that a third-party provider sells a ticket, informs wafer about the ticket creation and issues a "barcode" to the user. The user then enters this barcode to associate his/her account with the ticket in the database.

This relationship is recorded in the user_id column of the ticket_tickets table. Once a relation exists, the user is considered registered and the "Register" button no longer shows up in the user's settings page.

Whether we'll be using a third-party service or not is up in the air. madduck has reached out to a couple of them asking for quotes (2015-11-27): tix.com, eventbrite.com, eventim.de, ticketmaster.com, quicket.co.za (used by PyConZA and already supported by Wafer), tito.io, and pretix.eu (which is interesting as it evolved out of CCC events and is just starting with the goal to offer the full service spectrum).

Talks/events

We already know that pages can be assigned to slots in the conference schedule. Talks provide an alternative model geared more towards presentations and the likes. Upstream provided (sparse) documentation for those.

Talk types (talks_talktype)

Classes of "talks", such as presentations, BoFs, plenaries, etc.

Talks (talks_talk)

A Talk object encapsulates an event submission and collects such data as type of talk, title, abstract, notes, and authors (one of whom is the corresponding, "responsible" author. Programme committee workflow is represented in the three-state status field (pending, accepted, rejected).

Talk URLs

A 1:n relationship associating URLs (e.g. homepage, slides, video recordings) with talks.

Note that talks can be associated with multiple authors (and require one main, "corresponding author". This also means that talk submitters have access to the list of registered users, which might not be desirable. On the other hand, we'd want people to be able to manage this themselves so as to lower the workload on staff. See https://github.com/CTPUG/wafer/issues/169.

Open questions

• Strategy for additional workflow stages (e.g. moreinfo, second-choice, ad-hoc)?
• Limiting list of other registered users (#169)

Scheduling

The upstream documentation describes the four models used for modeling:

Day (schedule_day)

A day (date) of the conference, which is a container for slots.

Slot (schedule_slot)

Defines a period of time on a day, which can either be chained onto the previous slot (implicit start time), or given an explicit start time.

Venue (schedule_venue)

Conflicting DebConf parlance, a venue in Wafer refers to a talk room. Rooms need to be made available on conference days.

Schedule item (schedule_schedule_item)

An item in the schedule links a talk or page to a venue (room) and one or more slots.

It's notable that slots extend across rooms, so granularity is the same all across, rather than each room having its own set of slots for each day. The latter would bring a lot more flexibility, but also spell a lot more work setting up the slots. In the end, we'll probably have 5 or 10 or 15 minute slots, depending on how crammed the schedule becomes, but this also means that the schedule will have a lot of rows — or that we'll just have to simplify scheduling.

Also notable: one slot's end time is the next slot's start time, which means the schedule will show items back-to-back without a 5 minute pause allowing people to change rooms. See https://github.com/CTPUG/wafer/issues/151.

The idea of allowing pages to be linked into the schedule has a lot of potential. Sprints don't really need a talk submission anymore if there's a page for them, and a page describing lunch logistics can be included at lunchtime, etc..

Open questions

• How can we improve validation? I created an item with both talk and page associated, which caused the entire schedule to disappear.
• How to handle post-session breaks?
• Good way of displaying scheduled time in the talk details page? See https://github.com/CTPUG/wafer/issues/154.

Sponsors

Please refer to the upstream documentation.

There exist two models (well, and Files that can be uploaded):

SponsorPackages

Individually purchasable, these come with a price and a description.

Sponsors

Basically a record of who bought which packages. A sponsor can buy more than one package.

Since we do not offer package granularity (but rather sponsors buy in at a single level), and all the fundraising happens externally for now anyway, all we need is a Page listing the sponsors, and a sidebar of sorts.