Rapid Response online ticketing systems to support social justice organizations

From DevSummit
Revision as of 19:09, 30 November 2021 by Evelyn (talk | contribs) (Created page with "=Rapid Response online ticketing systems to support social justice organizations - S & K= ==intros== * K, any pronouns, Oakland Ohlone territory with Vision Change Win * I,...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Rapid Response online ticketing systems to support social justice organizations - S & K

intros

  • K, any pronouns, Oakland Ohlone territory with Vision Change Win
  • I, he/him, Porland OR, prison abolitionist groups, community info shops
  • L, she/they, stolen Ohlone land (Oakland), involved with VCW project
  • R, they/them, Wiyot land, northern CA, Portland BLM dispatch
  • N, he/him, Mashpea Wampanoag land of people of the first light, guardian project - mobile first privacy centric things
  • S, she/her, community safety directory at VCW
  • B, she/her, Berlin Germany, has ticketing system
  • J, he/him/ours, May First Movement Technology, Zapotec/Mixtec territory (Oaxaca), we provide web & email hosting, we want a better ticketing system
  • O, he/they, stolen Kumeyaay land, work with We All We Got SD mutual aid last summer with Trello & Airtable
  • a, he/they, comms & rapid response experience, new to ticketing system, built Signal Boost, Bethlehem PA

Ticketing and Rapid Response

History

We recognize the lineage of Black Panthers and Young Lords community defense & mentorship, Audre Lorde Project and many others based in Lenape land (NYC). There can be more of an oral tradition around cultures of safety. We asked for permission from these knowledge-holders around whether/what/how to share these practices; we now have a larger toolkit & skills.

https://www.visionchangewin.com/wp-content/uploads/2020/07/VCW-Safety-Toolkit-Final.pdf

In this political moment after the COVID-19 pandemic and uprisings, we asked how to shift and adapt into a structure for rapid community response.

One staff person was personally receiving lots of requests, with complex questions coming in, sometimes able to answer directly and sometimes delegating to others all over the place on various platforms. Eventually categories and types of responses emerged.

We worked on choosing and configuring the technology for this. With more time, we could have better understood some trade-offs. One of us had run a million help desks, we made a quick decision to go with OS Ticket https://osticket.com/, an open source project with a hosted version called "Support System". We went with the hosted version but will move to a Palante-hosted full install in the coming year.

Questions

We used the simplest configuration choices we could to keep it simple, and managed security (other than self-hosting), we minimized the amount of data 'written down', and keeping all communication with people receiving support in encrypted / non-surveillable formats/channels.

There are minimal integrations. Tickets move over into Signal chats. The only things that go out from the system are internal notifications of new tickets, assignments etc with priority. It's very small for now. Scaling would be difficult.

We can't go into too much depth with who is here today about the other software options we considered.

In Help Desks, sometimes you come up with templates or knowledge bases, but that can be a privacy concern. It can be built out instead over a network, our rapid response design team. This is just one of our tools, it's not *the* rapid response, it's a tool for our rapid response.

When requests come in, we have a number of providers who may be best to respond, and documenting resources is one way that we do it -- we make that list of resources available to our providers.

A trade-off we've struggled with is ease of use vs privacy. For example, email is easy to use but often insecure. What were the biggest trade-offs? Signal is harder to use but more secure. Zoom is also relatively accessible/ubiquitous and supports encryption, but it can be difficult to request everyone install Zoom as a first step before having a conversation. The initial incident report might come in on Signal or Zoom. We want to handle requests within 3 calls. Pick up, help, follow up.

Where we were, every single night was declared by police to be a riot. We used signal groups for coordination, and used Signal Boost alot. Inbound support requests often came from instagram -- Announcements happened on Instagram mostly, sometimes Twitter. We heard frequent reports that people were arrested and would disband signal groups that include people who had been arrested. We were concerned about conspiracy charges.

Suggestions from N:


  • Some of us are curious about the direction of the Signal company and its relationship to community needs! Will we need to get off of Signal and find another way to securely message each other?
  • Moxie's focus on a certain kind of end-user in mind, and so integrating with Signal raises questions about long term support. Other tools like Telegram, WhatsApp etc are easier to integrate with. It's baffling because Signal used to be in the same building that many of us worked, so to see these changes is hard.
  • Yes to user-centred and case-based approach. Tailored to needs and access of client, and priority of the request
  • We built something to combat sexual assault and predation called circle of six, based on the principles of affinity groups. We made it open source and got funding from Open Technology Fund OTF, now called Circulo, launching soon, it's encrypted and built on the Matrix system (same as Signal, but not Signal). https://beta.encirculo.org/
  • Help Desk & Rapid Response can be different tasks/tools/purposes. For people requesting, there are a lot of unknowns, justified safety concerns sharing information.
  • Some have encouraged requests use aliases or non-identifiable (i.e. other's) contact information. Mostly used WhatsApp due to it's popularity, and we delete information periodically.
  • Vetting requests and also vetting situations, and assessing possible threats or infiltration that might come in as requests. We soft-launched a help desk.
  • There is some degree of tension between the necessity of vetting or techniques like using aliases and the 'Rapid' part of the response, but we are trying to respond as reasonably as possible, verifying sources and looking for as credible information as possible.
  • In case folks don’t know it already: a great mailing lists for rapid responders, where such a conversation could keep going and with even more trusted folks involved Rapid Response Network https://www.rarenet.org/
  • We are using our ticketing system RT which has some metadata, as a clunky CRM. But mostly we use human beings, and the circle of trust.
Retrieved from "https://devsummit.aspirationtech.org/index.php?title=Rapid_Response_online_ticketing_systems_to_support_social_justice_organizations&oldid=3044"