Skip to content

Specs of the BOF application

Jump to bottom
Timotheus Pokorra edited this page Jan 29, 2018 · 26 revisions

General

BOF: Birds of a Feather flock together.

A BOF session is a meeting of a group of people during a conference, that are interested to discuss and share knowledge about a certain topic. Nobody comes prepared with a presentation, but it is spontaneous. One person is appointed to be directing the discussion, to make sure it does not wander off. This person is called the facilitator.

The idea of this software is to allow first the nomination of topics for BOF sessions, and after that the voting of BOF sessions. In the end there is a limited amount of available slots, some of them happening in parallel.

Charts

Mindmap by Jeff

flowchart by Jeff

User management

  • Users can register themselves, using a name and password. They should be told to use a name that is known to help the organisers to approach them.
  • Users can login with their name and password.
  • Users can log out.
  • We should properly hash the password, so that we don't need to say like in the past: Please use a weak password, because we can read them.
  • We need at least one admin user, that can login to the backend.

Backend

configuration:

  • The admin can configure the rooms for the BOF sessions: name of the room, maximum seats available
  • The admin can configure the number of time slots.
  • The admin can configure the amount of votes each attendee has: number of full votes, and number of quarter votes (or unlimited quarter votes)

The admin can enable the different stages:

  • A: nomination stage: with end date
  • B: moderation stage
  • C: voting stage: with end date
  • D: calculating the results
  • E: presenting the results

The admin can select the current stage from a drop down, and can define at which time the next stage is automatically enabled. if the time is empty, the stage can only be changed manually.

moderation stage:

  • The admin can modify the topics after the nomination stage, to merge obvious duplicates into one BOF topic, to avoid too many topics with little number of votes.
  • The admin can set a certain topic to not be part of voting: a slot is reserved for this anyway. eg. the EuroPrep BOF. would still be good to know who wants to attend, to better plan the schedule...

Finalising the results:

  • the admin selects which BOF happens in which room. Or automatically, if the rooms have assigned maximum numbers of people?
  • The algorithm must consider the rooms and the slots, and the votes. It also considers people that voted for one BOF cannot attend another BOF happening at the same time.
  • the admin must be able to alter the time slot and room for a BOF, even if it is initially calculated by the algorithm.
  • The admin can export the results in a format (CSV) that can easily be imported into Sched, for presentation on the screens during the conference

Frontend

see user management above:

  • Attendees can register themselves.
  • Attendees can login/logout.

Attendees should see which timeframes are assigned for Nominations, and Voting

Nomination stage:

  • attendees can create a new BOF topic. It contains a title and a description.
  • someone who has created a topic, is also allowed to edit or delete that topic.
  • attendees can see all the created new BOF topics in a list, so that they will hopefully not create duplicate topics.

Voting stage:

  • attendees can give 3 primary votes counting 1 point, and as many quarter votes as they want. (numbers defined by the admin)

  • They can only give one vote for one session

  • there should be a counter telling the attendee how many votes are still available

  • attendees can select if they are available to lead the discussion (volunteer to be the facilitator)

  • if they volunteer to be facilitator, they must give a full vote for that topic. perhaps make it a single radio button: facilitator (one vote), participate (one vote), alternative (quarter vote), no preference (no vote)

  • attendees can change their vote during this stage.

  • attendees can see how many votes have been cast for the sessions. The sessions should be put in the right order, using the same algorithm that is used when finalizing the results.

  • attendees should see the names of the volunteers for leading the discussion.

  • question: should attendees be able to click on a session and see who voted for it? Probably not. We won't do this in the initial version.

Final stage:

  • Voting is closed. Result can be seen, session per slot and per room

Target Platform

  • Server runs on Ubuntu 16.04 LTS, PHP 7
  • the application must be able to run on a defineable URL with prefix, eg. /iccmbof/
  • Clients: should test with Chrome, Firefox, Safari, and mobile devices

Theming

  • allow theming per conference. configure in the database, or in a configuration file. different colours/logo per conference, eg. ICCM Americas vs ICCM Europe vs ICCM Africa vs ...
Clone this wiki locally