path: root/docs/confreg/configuring.md

# Configuring a conference

This documentation page covers how to configure an existing
conference. For information about how a superuser can create a
completely new conference, see the [separate page](super_conference#new).

### Base configuring

There are a few base configuration steps to always perform.

Set the maximum number of attendees before the [waitlist](waitlist)
activates. This should always be set to a few below venue capacity, to
make sure a multireg doesn't "break the bank".

Configure the automatic cancellation of invoices that are old past a
certain time. As the conference approaches, this number should be
decreased. The risk of keeping it too high is that people create an
invoice, which then "blocks" a seat at the conference, without paying
it. During that time, it's unknown if they will actually attend, so
seats cannot be given to others.

Once the autocancel time is decreased below a certain threshold, some
payment methods that don't complete immediately (notably things like
IBAN bank transfers) will automatically become unavailable to the attendees.


Decide if you want a welcome email to be sent to all attendees when
their registration is fully completed (payment confirmed), which is
normally recommended. If you do, of course also set the text of that
email. The email will be sent from the address configured as the
contact address by the [superuser](super_conference).

If needed, add a text added as a prefix before the
[additional options](registrations) listing on the registration form.

### Registration fields

Configure which additional fields should be included on the
registration form, such as Twitter name or Dietary needs (see
[below](#conferenceform) for reference). This should always be done
before the first registration is allowed, to make sure the same data
exists on all attendees.

### Workflow steps

You can separately enable each of the different user workflow steps
for [registration](registrations), [call for papers](callforpapers),
[call for sponsors](sponsors), [schedule](schedule) and
[feedback](feedback). Make sure you don't enable any steps until the
organisation is ready for it.

### Call for papers

Decide if you want skill level prompts in the
[call for papers](callforpapers) and visible in the
[schedule](schedule), and set the intro text used on the
[call for papers](callforpapers).

You can also decide if you want talkvoters to be able to see how others
voted and the overall average vote.  Usually this would be off until
everyone has finished voting.

There are two methods for calculating the average score of a
proposal:

- Average — This is the standard average of all the scores.
- Olympic average — This method removes one instance each of the
  maximum and minimum of the scores before averaging. This helps
  prevent both favoritism and also sabotage.

### Roles

There are four types of roles that can be configured at the level of
conference.

Testers are users that can bypass the restrictions on which parts of
the workflow are open, e.g. they can perform a registration even if
registrations are closed. The idea is that this can be used for
example to test skinning functions, and to validate the setup of
things like [registration types](registrations).

Talkvoters are users that can vote on talks in the
[call for papers](callforpapers).

Staff are users who are allowed to [register](registrations) with a
registration that requires staff (basically intended for free or
discounted registrations). This is assigned to users *before* they
register, to gain access to this registration type.

Volunteers are *registered* users who can participate in the
[volunteer schedule](volunteers). Note that this requires the users to
actually be registered for the conference in order to be
selected. This is a separate flag instead of a registration type so
that it's easy to for example have attendees who are both speakers and
on the volunteer schedule. If volunteers should get free entry as
well, that is typically handled either with a
[registration type](registrations) that requires manual validation, or
with a custom [voucher or discount code](vouchers).

The final role that exists in a conference is an administrator. This
can only be assigned by a [superuser](super_conference).

## Reference

### Conference details <a name="conferenceform"></a>

The form to edit a conference has the following fields:

Attendees before waitlist
: Number of confirmed attendees before the [waitlist](waitlist) is
activated. This should be below the venue maximum *with some margin*,
as the number of attendees can "jump" with either multi-registrations
or parallel registration processes by multiple users.

Autocancel invoices
: Invoices are automatically canceled if not paid after this many
hours. Should always be set to ensure there are no "dangling invoices"
from people who are not completing their registration, making it
impossible to know if they will use their seat or not. Typically
starts out as a high value that is decreased as either the conference
draws closer or it starts approaching sold out.

Transfer cost
:  If set to a value it will become possible to create invoices for
transferring registrations. The cost will be per-registration and
independent of registration type.

Notify about registrations
: Send an email to the notification address every time somebody
registers or has their registration canceled.

Send welcome mail
: Should an email be sent to the attendee confirming that they have
completed their registration. For this to be enabled, jinja templating
needs to be enabled, and the contents of the email to be sent should
be stored in `templates/confreg/mail/welcomemail.txt`.

Use tickets
: Enable [tickets](tickets) and check-in. If this is enabled, then for
each user a ticket is generated and attached to the welcome
email. This ticket is built from the `ticket.json` file in the
template directory. Enabling tickets also enables the check-in
tracking system.

Queue partitioning
:  Enable queue partitioning. This will generate information for each
attendee about which queue t stand in based on either first or last
name (pick which one). Information about this partitioning will be
written on the tickets (if included in the templates), so should
normally not be changed after the first tickets have been issued.

Initial common countries
: Initial list of countries to show under *common countries* on the registration
form. Each o these countries will count as one when the list of most
common countries is populated. Once registrations start arriving, they
will get replaced by actual countries used as they show up.

Promotion active
: Should this conference be listed in promotional parts of the website.
Without this, the only way to access the conference information is to
know the URL for it.

Promotion text
: Short text (supports markdown) with information about the conference,
which is use din promotional pages on the main website.

URL to promo picture
: An URL pointing to a picture promoting this event, which will be
used on the main website. If left blank a default (or random)
picture will be used. Picture must have an aspect ratio of 2.3, but
will otherwise be reasonably sized to fit the screen of the visitors.

Don't post tweet before/after
: A timestamp (00:00 - 24:00) indicating during which period automated
tweets can be posted. If an automated tweet is queued outside this
window, it will be posted once the window is entered. Manual tweets
can be queued for any time.

Posting policy
: Set the policy fo rusing the [mobile](integrations#mobilesite)
  posting interface.

Field pronouns
:  Should the field asking for preferred pronouns be displayed
on the registration form. Typically used to be printed on the
badges if given.

Field t-shirt
: Should the field asking for t-shirt size be displayed on the
registration form. Only used if t-shirts are given out.

Field dietary
: Should the field asking for dietary needs be displayed on the
registration form. Only used if catering is provided.

Field nick
: Should the field asking for nickname be displayed on the
registration form.

Field twitter name
: Should the field asking for twitter name be displayed on the
registration form.

Field badge scanning
: Should the field asking to allow sponsors to scan the attendees
badge be displayed on the registration form.

Field share email
: Should the field asking to share email address with sponsors be
displayed on the registration form.

Field photo consent
: Should the field asking the attendee to give (or not) consent to
have their photograph taken at the event.

Dynamic properties
:  List of [dynamic properties](reports#dynamic) that can be added
   to each registration. These fields are used for custom reporting
   and similar functions, and are not visible to the end user.

Scanning properties
:  List of dynamic properties that can be used as part of the scanning
   system. For [check-in processors](tickets#scanningfields) this allows
   them to perform secondary scanning of badges to mark other items.
   The list here must be a subset of the *Dynamic properties* above, or
   empty.

Registration open
: If regular registration is open.

Registration open between
: Timestamp to open and close the registration. If these fields are
left empty, the registration is opened and closed based on the checkbox.
If they are specified, the registration will be closed before and
after this range even if the checkbox for open is enabled. Both fields
need ot be satisfied for the registration to be open.

Allow editing registrations
: If a user is allowed to edit an existing registration. Only some
limited fields can be edited, things like t-shirt size and dietary
needs. This is typically turned off once the final list of such
information has to be locked in with a venue, or when badges are
printed (in case some of this information is used on the badges).

Call for papers open
: If the call for papers is open

Call for papers open between
: Timestamp to open and close the call for papers. If these fields are
left empty, call for papers is opened and closed based on the checkbox.
If they are specified, the call for papers will be closed before and
after this range even if the checkbox for open is enabled. Both fields
need ot be satisfied for the call for papers to be open.

Call for sponsors open
: If the call for sponsors is open

Call for sponsors open between
: Timestamp to open and close the call for sponsors. If these fields are
left empty, call for sponsors is opened and closed based on the checkbox.
If they are specified, the call for sponsors will be closed before and
after this range even if the checkbox for open is enabled. Both fields
need ot be satisfied for the call for sponsors to be open.

Schedule publishing active
: If the schedule is published, including times, and rooms.

TBD sessions in schedule
: If sessions in [state](callforpapers) *Pending* should be included
  on the schedule. If they are, their title is replaced with *TBD*,
  and the speaker information is not included.

Session list publishing active
: If the session publishing is active, which just lists the sessions
and their details, typically used before the schedule is done but
talks are being approved. Only tracks which have the "In session list"
flag activated are shown. Change this in "Tracks" for each track.

Cards active
: If the card publishing is active *and* the session publishing is
active, then [cards](skinning#cards) (small adapted images in SVG and
PNG format) will be published for sessions and speakers.

Check-in active
: If the [check-in](tickets) system is active and attendees can be
checked in.

Conference feedback open
: If registered attendees of the conference can leave
[feedback](feedback) on the full conference.

Session feedback open
: If registered attendees of the conference can leave
[feedback](feedback) on individual sessions.

Max submissions
: Maximum number of submissions allowed per speaker, or 0 if
unlimited. Note that this controls how many submissions can be made
into the system, not how many can be accepted! It also only affects
the call for papers form - an administrator can still add more speakers
and sessions in the backend.

Skill levels
: Should the [call for papers](callforpapers) ask for skill levels on
all sessions, and should they be displayed on the schedule and session
lists.

Use tags
: Should the [call for papers](callforpapers) ask for tags on all sessions.

Ask for recording consent:
: Should the [call for papers](callforpapers) ask for recording consent
on all sessions.

Testers
: List of users who are assigned as testers of the conference. These
users can bypass the restrictions above and make registrations and
submissions even when they are closed, etc. This can be both
registered users and not registered users.

Talkvoters
: List of users who can vote in the
[call for papers](callforpapers). This can be both registered users
and not registered users.

Staff
: List of users who can register as staff using the special
[registration type](registrations). This is typically users who have
not registered when they are added, since they will later use the
staff registration to become registered.

Volunteers
: List of registered users who participate in the
[volunteer schedule](volunteers). This must be registered users.

Check-in processors
: List of registered users who work with [checking in users](tickets)
on arrival. This must be registered users.

Jinja templates enabled
: Indicate if jinja templating is active for this conference. This can only
  be enabled if the *jinja directory* setting is enabled in the
  [superuser settings](super_conference), but can then be independently
  turned on and off by a non-superuser.

Video link providers
: List of providers that can be used to link to videos (e..g "youtube"
  and "vimeo"). Must be lowercase. Each entry here will create a field
  on the conference sessions (backend only) where information about
  video links can be stored, and later used within the templates.

Width of HTML schedule
: Width in pixels of the built-in HTML schedule. This only controls
the "old style" HTML schedule, which is normally overridden by the
conference templates in which case this has no effect.

Vertical pixels per minute
: Number of pixels to assign to each minute on the Y axis when
generating the "old style" HTML schedule.