Skip to content

Latest commit

 

History

History
226 lines (168 loc) · 15.4 KB

SERVICES-INVENTORY.md

File metadata and controls

226 lines (168 loc) · 15.4 KB

DWeb Camp 2019: Services Inventory

This list keeps track of the list of services we employ to organize DWeb Camp 2019.

Here are the Services Inventory of some other conferences and organizations for comparison:

At the bottom of this document, there is a section on learnings and recommendations for future iterations. Items on this list was originally tracked on dweb-camp-2019/organizing/issues/7 during planning phases.


  • Google Docs is used for most text documents from meeting notes to drafting public content
  • Google Sheets is used to organize lists from attendee information, survey results, logistics, budgets & finances, etc.
  • Google Forms is used to request for information from attendees, such as project submissions and surveys that are outside of the ticket purchase process (does not require Google account to response to a survey)
  • Google Drive is used to store all planning assets, many of which are images
  • Google Calendar is used to schedule internal and partner calls
  • 🔑 Access is generally granted to organizers and collaborators on a need-to-know basis, with special attention on lists that contain personal information of attendees
  • ⚠️ With many documents in the Drive, with access granted to different people, it is hard to keep track so a lot of core organizers have full access to everything
  • ⚠️ Google has a "Get sharable link" button where if you click it, the document becomes publicly viewable to anyone with the link, and there have been times when documents have been unintentionally put into that state
  • ⚠️ View and edit permission in Google Form has been mixed up and people responding ended up changing the Form
  • Occasionally used for meeting notes and other collaborative edit documents, which are subsequently transferred to more permanent storage, such as GitHub for Open Dialog Calls
  • 🔑 Open access
  • Email accounts:
    • Event email address: dwebcamp [at] archive.org
    • Group email addresses for specific working groups
    • Personal email addresses for some organizers
  • The DWeb Camp 2019 Collection for archiving event media assets
  • The Internet Archive Blog for posting some announcements
  • Real-time chat (bridged):
    • freenode/#dweb-camp-2019-mesh (:key: @benhylau has Admin access)
    • freenode/#dweb-camp-2019-apps (:key: @benhylau has Admin access)
  • 🔑 Open access, @benhylau has access to manage the Matrix-Slack-IRC bridges
  • Mailing list for pushing announcements to Decentralized Web community
  • 🔑 @whanamura
  • Blog posts for the Decentralized Web community, some of them mirrored onto Internet Archive Blog
  • 🔑 @whanamura and content writers who have been granted access as needed
  • DWeb Camp programming with mobile app that allows offline browsing of schedule
  • 🔑 @whanamura and organizers who have been granted access as needed, and personal accounts have applicable access (e.g. people hosting sessions can edit their session)
  • The Decentralized Web Slack is used for real-time chat (bridged)
  • Internet Archive has another Slack that is occasionally used by organizers to communicate internally
  • 🔑 @whanamura and Internet Archive has Admin access. @benhylau has access to manage the Matrix-Slack-IRC bridges
  • ⚠️ Occasionally there were confusion with which room and which Slack discussions are happening
  • ⚠️ There are many rooms for specific topics that carry from year to year, it is unclear which are active
  • Social media account used to announce events, build momentum with the many local DWeb organizations, and engage the larger Decentralized Web community
  • 🔑 @benhylau @whanamura @maisutton have personal accounts
  • ⚠️ There were interesting discussions happening in the ScuttleSphere but it has been difficult to share to the larger Decentralized Web community, so we ended up with fragmented conversations, sometimes manually "federated" onto GitHub Issues
  • Social media account used to announce events, build momentum with the many local DWeb organizations, and engage the larger Decentralized Web community
  • 🔑 @whanamura and other organizers of the Decentralized Web community
  • Source code: internetarchive/dwebsummit-site-2
  • Hosting: Internet Archive
  • 🔑 @jbuckner
  • ⚠️ We encountered several outages while initially the website was hosted with a cloud provider, but that has since moved to Internet Archive infrastructure
  • ⚠️ The custom CMS itself and the way we use it has introduced various friction points and restrictions (details discussed below)
  • Video chat for organizer private meetings using the Internet Archive account
  • 🔑 @whanamura

Recommendations for Future

This is a list of candidate areas to investigate for 2020 and future iterations of DWeb Camp.

Collaboration Tools & Document Management

Alternative to Google

We heavily rely on the Google ecosystem for coordination among organizers (e.g. Google Calendar) and storing shared documents (e.g. Google Docs and Drive). There has been a few incidents where permissions got mixed up due to unclear platform UI and lack of a shared practice around information sharing. However, we have not found good replacements for many of the features that the Google ecosystem offers, such as:

  • Synced calendars with user-friendly desktop and mobile apps
  • Collaborative editing of documents and spreadsheets with identity system
  • Extensive options, despite UI, for access control
  • Ecosystem integration (e.g. Form data directly populates spreadsheet)

The immediate recommendation is to discuss information sharing and access control early to establish a shared practice of how to use existing tools, then investigate modular alternatives, such as an alternative CalDAV service, or Nextcloud as a shared Drive.

Conference Management & Program Scheduling

Alternative to current process involving GitHub Issues, Google Forms, Spreadsheets, CMS, and Sched

Investigate self-hosted conference management and program scheduling software that we can browse and make changes in the local network, such as frab used at ToorCamp 2018 and CCC. We should compare this with Sched, which we used for Camp 2019 and Summit 2018.

Current process is quite labour intensive, the information flows through stages like this and someone has to manually be involved at each process, with some back and forth emailing in between:

  1. Pre-discussions on Matrix / GitHub / Emails / SSB (fragmented)
  2. Project leaders to submit Google Forms:
  3. Enter data from submitted Forms into website CMS (require presenter info collected from previous years or by manual email)
  4. Space-time spreadsheet (slot sessions into venue space, coordinate with Space Weavers)
  5. @whanamura + Space Weavers + Project Leaders to put data into Sched

We should have a discussion about this early and try to minimize the amount of manual labour involved.

Fellowship Payments

Alternative to current process

For money going out to support individuals (e.g. Global Fellowships), these are the information that Gatherings for Good Accounting needs to gather before sending money:

The name of the person
Their address as listed with their bank (for wires)
Their address (if a check is issued)
A W-9 form for US residents

Bank info:

  • Name of Bank
  • Branch name
  • Address of Branch
  • Swift code
  • IBAN account #

Invitation Letter for Travel Visa Applications

Alternative to manual process

We need the following information about each applicant in order to issue an invitation letter:

First name:
Surname:
Date of birth:
Passport number:
Expiry date:
Nationality:

Short description of why applicant is invited:
Short description of financial sponsor:
Short description of accommodation arrangement (if not at Internet Archive):
Is this for a travel visa application?

Personal information is provided over email exchange, occasionally requiring clarifications and corrections, and each time we change something we modify a word document and print as PDF with Internet Archive letterhead. We should fork the ournetworks/2019 travel visa generation tool and modify the letter template, and adopt more secure practice than email to exchange the personal information with guidelines on deletion.

Ticketing Sales

Alternative to Eventbrite

Attendees are paying a lot of 💸 for processing of ticket sales. There is a payment processing fee of 2.5% charged by payment processors, which sort of establishes a baseline cost, but $1 + %-based fee structure per ticket is not the best option for DWeb Camp given high ticket costs.

We should investigate solutions that offer fixed monthly costs, such as Event Smart where we pay a fixed charge of ~$100 per month while tickets are on sale, regardless of how many tickets are sold, and only the payment processing 2.5% is transferred to registrants.

More info about the difference in fee models. We need to check on other features such as email communication to registrants and how refunds work.

Website

Alternative to custom CMS

The organizers have had multiple discussions around a suitable website solution, and in the end decided to re-use the Summit 2018 content management system (CMS), internetarchive/dwebsummit-site-2, and database. Other possible solutions were discussed on dweb-camp-2019/organizing/issues/13, which are mostly static website generation without a database that would be easier to integrate into a automated deploy flow and published onto the Decentralized Web (e.g. Dat, IPFS). We chose not to pursue this in Camp 2019 because:

  • Capacity and timeline limitations
  • Reusing a familiar (CMS) is lower risk for content writers
  • Summit 2018 has a database of people and projects from the Decentralized Web community that we hope to build upon
  • Static site generators are mostly Markdown-based and a UI familiar to non-techies is not available (image upload is usually a pain) and we did not have time to trial solutions like jekyll/jekyll-admin

The solution we used had the following issues that organizers encountered:

  • Writing content with a shared CMS account had us overwriting each other's content
  • Some images uploaded couldn't be embedded through the UI, unclear why
  • The WYSIWYG content writing UI create formatting issues that sometimes we have to fallback to writing in HTML to resolve, which the WYSIWYG UI renders poorly
  • Susceptible to server outages due to having to host a database on a VM
  • Restricted set of templates and pages
  • Some content requires codebase changes and redeploy to alter
  • No automated deployment to Dat and IPFS which makes the versions fall out of sync with HTTP version

We should re-open this discussion and start early for future DWeb Camp iterations.