Buoy: Coordinated Crisis Response and Community-based Mutual Aid, without a State

+1 to different ways of explaining what you do

Hi and needless to say seeing the super response you’re getting already, you guys rock.

Just to agree that finding a common language might go a long way with groups that may not be as radical/ adamant in their approaches to not cooperate with state led operations, but rather expose them as irrelevant. I find this quite strong and while some edgeryders will resonate immediately, the rest of us may not know just how to engage even if they resonate with the premises (and keep a different view on the ways, for example me, I got the most out of the FLOSS vanilla interview).

Another group with which you guys could click immediately is the Tbilisi activists led by @Nick_Davitashvili, who broke new ground in their own way of enabling flood relief efforts or stopping the construction in their largest city park. There could be potential for new tech  - they had to make up a process for coordination, so they enabled coordination through an emergency twitter account texting to dumbphones and worked exceptionally well, as Nick’s explained in his tedx. But this wasn’t p2p, only for broadcasting as far as I understood…

Impressed

More power to you, @maymay . This is a very well-thought through service. What I love most is your response team concept: it works even at the level of, say, 10 friends that live in a 2 km radius from each other. Then, like the best networks, it can be scale-free: suppose I am using Buoy here in Brussels, I have my little response team etc. Next up, I visit my friend in Milano; suddenly I am detached from my response team, but if my friend is also using Buoy, she and I can be on each other’s response team. Also, she can ask her own response team to opt in in my own, and viceversa I will be part of theirs. Voilà: everyone in my friend’s response team now has skeletal Buoy coverage should they ever come to Brussels – and of course I can ask my response team to add them, too. The scale-freedom there is that my friend and I become hubs, stringing together my local network in Brussels and hers in Milano. I can’t emphasize how powerful this is: Buoy is viable at a small scale.

I am definitely intrigued by the idea of trying it out when we next deploy in a geographically defined space: this could be Galway, actually. I see in your FAQs that you have already thought of Buoy as a suicide prevention tool. This meets a pressing need in Galway and the West of Ireland in general. Ping @Thom_Stewart and @Finbar247 – I think Bernard McGlinchey is also on Edgeryders, but I cannot find his handle.

I would never presume to undermine your militant stance. Whatever your reasons, they led you this far, and this is more than good enough as far as I am concerned.

Scale was a consideration from very early on, and indeed the current state of Buoy’s implementation reflects a rejection of the typical technocapitalist approach of creating a single, highly-scalable centralized service endpoint for all interaction. It’s really encouraging to me that you seem to have immediately understood the importance of smaller-scale yet socially-proximous user connections. Most people with a tech background instantly reject this design, because it does not match what they are used to seeing Google, Facebook, Twitter, and other large corporate networks do. Of course, those networks are not interested in user empowerment, but rather control over users (user domination), so the model is clearly different.

With regards to trying Buoy out with Edgeryder’s community and its possible use cases, two things come to mind.

First, yes, Buoy as a suicide prevention tool was one of the use cases we designed for early on. You can have a look at some more use cases along with preliminary Personas we had started to document on our wiki. These are two areas where people who do not want or do not know how to write program code can really help the project out by contributing their own ideas in a manner that will be useful to fellow developers.

Second, I noticed that Edgeryders.eu is built on the Drupal CMS. Right now, the only implementation of Buoy is as a WordPress plugin, but I have been wanting to create a Drupal module for it, too. I am not as familiar with Drupal as I am with WordPress, but I have wanted a reason to get back into Drupal development for a while. Also, in my experience, Drupal is the second most popular Web-based platform for the kinds of small- to medium-sized organizations and community groups that Buoy is meant to serve (second only to WordPress). Implementing the existing Buoy functionality as a Drupal module could be really help broaden the reach of the project to more groups, as well as offer an opportunity to rework (“refactor”) some of the Buoy code itself.

I don’t really want to embark on this myself since it’s a pretty big task, but if there’s interest from other developers in doing such a thing, I would be happy to collaborate on that work with someone (or a group of people) from the Edgeryders community. To anyone reading this, the best and easier way to express an interest in this is to hop into our public chat room and ping me there. (I’m @meitar)

Keep an eye out for opportunities

With a bit of luck we might be doing stuff in Ireland in 2017. This might be a chance to scrape off some resources for a Buoy prototype, with would probably include a Drupal module. Let’s stay alert.

Drupal to buoy, maybe the other way around?

I know someone in the community produced a wordpress plugin from Edgesense, a piece of software which was only available as a drupal module. So they must have looked into the drupal-wordpress differences. @Alberto you know who this is, can you remember the handle?

It would be wonderful to have someone else’s experience to lean on, but if not, I am confident that I can build a version of Buoy for Drupal within a few months, much as I did for WordPress. All it will take is having reliable shelter and food for the duration. That’s the much harder part. Writing code is easy for me, by comparison. Unfortunately, my current situation does not include reliable housing.

Nevertheless, in whatever moments I do have the wherewithal to do so, I think it’d be helpful for me to refamiliarize myself with Drupal and update my understand of its internals using tasks that are smaller than porting Buoy from one platform to another. To that end, I’ve been looking at the tasks in the Edgeryders Dev and Testing and will hopefully start contributing some smaller pieces of work to Edgeryder’s own infrastructure. I see this as a way to create a win-win-win situation.

ok thinking about the shelter bit

I have a couple of ideas, will get back to you after fleshing them out a bit more.

“Map of emergence”

I do remember. The person in question is @MoE aka Stefano.

The social contract, self care etc

Am checking out the links you shared above for where and how to contribute to buoy. Code is not possible for me. But I can try to keep a lookout for use cases and useful information/articles etc. Maybe also do some advocacy for it by including it in public presentations (do you want me to mention your name when I do btw? Didn’t at re:publica - @Mike_Gogulski had just pinged me about it ).

So two things.

  1. I had a chat with the Woodbine crew about setting up an event at Woodbine around autonomy, health and interdependency. A convening, but not just for talking. A combination of showcasing/discovering some relevant OS tools, aggregating information resources and working out some social contract/model for supporting work on their further development. I am up for putting time into making it happen.

  2. I came across an article which you/me/others may find useful. One of the comments had a link to an information resource that @Woodbinehealth might want to include in their resource centre:  “a page called ThereIsHelp with pointers and resources for people worldwide dealing with suicidal feelings or a variety of other complicated mental health issues”. I also found it useful for unpacking questions relebant to Boy and community driven care in general…In Wikipedia is not therapy,  the author decribes the emergency response system the Wikipedia foundation has put in place for dealing with signals of distress amongst editors:

"This emergency response system was established in 2010 by Philippe Beaudette, the former director of community advocacy who recently left the Foundation to work at Reddit. On his LinkedIn profile, Beaudette notes that during his seven years overseeing the various Wikimedia communities, he and his team responded to almost 500 threats of suicide and other imminent harm to people and property. A recent report from the Foundation’s talent and culture team noted that, in one quarter, they handled five suicide cases that were escalated through the emergency email address.

“It’s a stressful thing, for sure,” Earley says. “My blood pressure goes up. It can catch me at any hour of the day. I do feel the weight of dealing with that. But it’s definitely something that feels like it’s important to do. We have the technical infrastructure in place to make it as painless as possible on our end.”

How do we effectively deal with the additional preassure, or emotional stress, that this kind of commitment brings into our lives?

do you want me to mention your name when I do btw?

I believe that memesis is more important than attribution. A more thorough explanation can be found on the Rolequeer Theory and Practice wiki, for those curious, but the takeaway point is that I hope your priority will effectively conveying the message and purpose of the tool. Attribution is nice and can often even be beneficial, but not always, and when that’s not so, mentioning names should be a very distant second priority.

I can try to keep a lookout for use cases and useful information/articles etc. Maybe also do some advocacy for it by including it in public presentations

That’s cool. Thanks. You can also join up in the public developer’s chat on Gitter. You don’t have to stay there all time, important announcements will get emailed to you. Just having more people in there makes it at least look like the project is growing. :slight_smile:

I had a chat with the Woodbine crew about setting up an event at Woodbine around autonomy, health and interdependency. A convening, but not just for talking.

That sounds fun. If by “at Woodbine” you mean in NYC, then with enough advance warning I might be able to attend personally. Keep me in the loop about this?

Signed up and yes re NYC

Let me know if/when you will be heading there and we can try to work around that. I think I’ll be in the US around last two weeks of september. Might be later though.

I’ll let you know my travel plans over a private channel. :slight_smile: Thanks, again.

Oh, @Nadia I should also mention that the developer’s chat room is also helpful because I often ask for specific kinds of testing help (that often does not include writing code) in that channel. Most recently was this ask for people to send test txt messages to a certain recipient so I could see the output from different telco providers’ gateways. So even if you don’t fancy yourself a “developer” the developer’s chat is still a good place to be if you have any free cycles an wanna use them to help Buoy development along. shrug

Thank you for this story, @maymay - I’d like to ask you about the ways in which you decide on what functionalities to add to the service? Both on receiving the feedback and requests from the users, but also what criteria do you apply when you pick some of these and make work?

And if you ever want a couch somewhere in Europe, I’d be happy to provide you with one;) I constantly move, but usually there is space for guests where I live.

Thanks, Natalia. :slight_smile: I appreciate offers for shelter very much.

You asked how I decide on what functionalities to add to Buoy. The answer is that there is no formal decision making process. What usually happens is someone with a need expresses that need to me in some manner, we converse about it over some communication medium, and then I add some functionality that hopefully meets that need. It’s very do-ocratic. An example will help clarify this.

Three weeks ago someone came to me in person and expressed concern that Celly, a SMS/txt messaging service that saw its popularity skyrocket thanks to its use by the Occupy Wall Street protest groups, was no longer suitable for their small group of activists. Two reasons were given: first, the service discontinued offering their free tier product line, and second, Celly began requiring users to install a smartphone app in order to send SMS messages. This causes two big problems for the activist who approached me. First, they have no money to afford to pay for Celly. Second, a significant percentage of their membership does not own smartphones, but rather flip-phones. These two issues are of course related: the local activists are all poor, working-class people.

I asked them some questions about what they had been using Celly for. This conversation lead to a better understanding of their use cases. Effectively, they had been using Celly as a kind of SMS/txt broadcast channel for the group, so that one member of their collective to send a single txt message and that txt would be received by everyone else in the collective. The collective is small (less than 20 people).

Over the next week (two weeks ago, now), I wrote a feature called the Team SMS/txt broadcast channel into the functionality offered by Buoy Teams. It meets the criteria the activist collective needs, including the ability to use it forever with no additional financial cost. One week ago, groups using Buoy alreay saw an update in their dashboards and could download and install the new feature with one click.

That’s the usual process.

Of course, I have created more “formal” channels for receiving feedback. These include the GitHub issue tracker, intended mostly for coordination amongst developers (and I include people who conduct user testing, writing documentation, and other non-code tasks to be “developers”), the WordPress plugin support forum, intended mostly for end-user-to-end-user volunteer support, our public Gitter chat room, intended as a way to get live support if someone is available to offer it, and our dedicated project email address available with PGP encryption, intended for those who need more assurance privacy but still need a support channel.

In practice, however, I am the only developer and have written virtually every line of Buoy’s code myself, so GitHub is mostly just me talking to myself, the WordPress plugin support forum has seen some use but is mostly me answering questions by end-users instead of users helping one another out, the public Gitter chat room is primarily me making announcements about my own work to people who are lurking and watching me do so, and the dedicated email address is dormant and receives no mail.

I would love for all of these channels to get more use, but the reality is that basically no one pays any attention to what I’ve done beyond nodding and smiling and expressing how good an idea they think this is to me when they hear of it. :\

To wit, that story of the SMS broadcast channel feature that now exists in Buoy? After I discussed the use case with the person who approached me about needing such a feature that could replace Celly, I have not heard from that person on the matter again, despite repeateded attempts to communicate about it over the two weeks since the feature has been implemented. I say this not to disparage this person themselves, but rather to point out a pattern relating to your question, about how I receive feedback. The pattern is: I receive feedback through a variety of means, and am generally able to very rapidly translate such feedback into working features that could be used immediately by the people who approach me. In practice, although the people I’ve communicated with are eager to express to me what they need, once I actually implement it, I never hear from them about it again.

This makes iterative improvement difficult for somewhat obvious reasons.

Oh, and regarding “what criteria” I apply, I’m sorry, I forgot to answer:

also what criteria do you apply when you pick some of these and make work?

The answer to this is also informal. There are only two criteria:

  1. Do I have the resources necessary actually produce an implementation, and
  2. Does the suggested feature empower end-users and vulnerable populations more than it empowers service providers or large institutions?

With respect to number 1, if I do not have the resources (knowledge, time, money, shelter, mental well-being, etc.) necessary to actually produce an implementation then I create an enahncement/feature request ticket on the GitHub issue tracker. You can see all of these tickets (which effectively represent a to-do list) on GitHub here. If, on the other hand, I do have the required resources to implement a given feature, then I apply the second criteria.

With respect to number 2, I make a personal judgement call about what I believe the impact of creating the feature will be. As part of this, I consider who is asking for the feature. If the feature is being suggested by a white man who works at a tech company and does not engage in much activist practice themselves, then I am bluntly far less likely to give that suggestion the benefit of the doubt. For example, almost all of the suggestions to “integrate 911 and let people call the police” have come from people matching this description. In contrast, when the suggestion comes from someone who I know as part of a local activist collective, as the example I gave in my previous reply about the Celly replacement, then I may not even bother to create a GitHub ticket because I simply immediately begin working on the feature.

Another part of this number 2 criteria relates to how the implementation actually works. For example, the SMS/txt broadcast channel uses IMAP behind the scenes specifically so that non-Google/non-Microsoft email services can be used. While I expect most people will still use a GMail account or similar to enable this feature for their own teams, it’s important to me that features built into Buoy do not force end-users towards proprietary, and thus obviously predatory, services. In other words, feature suggestions that necessitate the use of proprietary/predatory services over the use of technologies that can be self-owned and self-operated are more likely to find themselves unimplemented, because I will reject them philosophically.

Ethical coding

This is good sense ethical coding. Well played, @maymay .

Triage, clinical database and networking

Forgive me for skimming and missing info already there but I have a question

For providing good opencare  (check the post No Humane ghost in the machine) focus should be on shifting administrative tasks from healthcare professionals (called facilitators/mentors in our case), so maybe an App (Buoy?) could let the participant (the patient) check in, filling e.g. private data (address etc), restricted data (pathology, symptoms etc) and public data (satisfaction data, achievements etc.) as well as allocating time slots. What’s the state of the art of software for that (@Eireann Leverett, @Alberto,@maymay,@Nadia ) ?

To clarify, Buoy is not software for health clinics. It is software for coordinating group action in the field. It does things like displays people’s positions on a map, sends group SMS/txt messages, and offers a safer place to store recorded multimedia files than one’s phone. It does not schedule appointments or automate clinic paperwork.

I do think there could be places where some of what Buoy does could integrate well with those needs, particularly around dispersing knowledge of who can do what (has what skills), as discussed above. But these needs are tangential to the main issues Buoy was written to address.

I do rather enjoy automating busywork, so I’m generally very happy to work on systems to “shift admin tasks” away from secretaries/interns/paper-pushers and onto computers. I do a lot of that for friends with bullshit jobs, actually. But that’s not really what Buoy is for.

You might want to take a moment to read or skim through the Buoy User’s Guide and take a look at some of the screenshots on the various pages there to get a better feel for what Buoy is intended to do.

I’m not sure what the current “state of the art” for such scheduling software is, but I know pretty much any mature calendaring application tends to have the capabilities one needs to automate such a process. Outlook is probably the most well-known application for this, though it is of course proprietary and expensive.

Also, @Rune , if you don’t know about it, you might find GNU Health an interesting and useful tool for supporting clinic workers.