User Tools

Site Tools


act2019ff:what-do-we-want

What do we want

A high-level view on what we want from our conferencing toolkit.

Please add your wished / amend existing ones. This should be a broad overview, not a detailed spec!

  • Showcase a modern, sane Perl application
  • Easy to hack on
    • run on my laptop
    • Docker?
    • Setup / Running instructions
    • What haj is using right now: act-starter-debian
  • Run stable and without constant babysitting
  • Create a new conference via a web interface
  • Provide an API to all / core data
  • Keep historical data from previous ACT conferences
    • This is highly suspicious in the light of GDPR. Neither the providers of the service, nor the organisers of Act conferences have ever obtained the permission to store these data. – haj
  • User Registration / User Self Service
    • After inspecting Act's features, and also some of the feature requests (see e.g. have a representation for “persons” by BooK below), I (haj) suggest we differentiate the term “User” according to his (implementation hint intended) roles at the conference. One person can have one or more of the following roles:
      • Act user - there are already several roles (“rights”) for these
      • Visitor - someone who's going to be at the venue
        • Speaker
        • Staff
      • Sponsor (questionable: Sponsors are usually *organizations* and probably better stored elsewhere)
  • Talk Submission
    • ..
  • Talk Management
    • ..
  • Schedule
    • Make it easy to set up a schedule (drag'n'drop?)
    • Personal schedule
  • Handling Sponsors
    • ..
  • Payments
    • Clear instructions on how to pay
    • Interfaces to payment gateway(s)
    • Invoice management
    • Pick various items to pay (conference, extra training, plus-one for dinner, ..)
  • L10n / I18n / A11y
  • Backend API & Javascript SPA? HTML Backend with some dynamic JS elements? Plain old HTML?
  • ..
  • .

What does BooK want

A data-driven, distributed, conference-management tool written in Perl. Three words summary: conference data service.

More details in a list:

  • All of the above, plus:
  • The backend should be a data store of conference information, that isolates the business logic (registration, data edition, etc) behind a clean API. Basically, completely separate the data+business logic from the layers that interact with users. Mapping a REST API on top should be a thin layer.
  • Access to actual data depends on the permissions of the agent: objects are always only partially fleshed, depending on the access rights.
  • All operations (from registration to conference creation) doable via the API (and therefore, web ui, CLI should be possible. always with feature-parity)
  • have a representation for “persons”, who may or may not have an actual user account: e.g. a keynote speaker might be invited, but won't interact with the site.
  • OAUTH: i.e. ability to do most attendee-level operations without explicit account creation
  • Work in a disconnected/distributed manner (e.g. the desk at the conference may not have network, but should be able to work with a local copy of the relevant subset of the database and be able to take new registrations, record the arrival or payment of an attended, and later sync these with the central data store)
  • Some possible API inspirations: GitLab API v4, Eventbrite API
  • Groups of related conferences (e.g. generate the next edition from the previous one)
  • Most objects attributes do not live in the object: the object has a unique indenty, but its actual attributes will depend on the context (most likely the current conference)
act2019ff/what-do-we-want.txt · Last modified: 2019/07/06 20:10 by haj