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. 
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:
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.
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.
Got to look at it and a bug
Thanks @maymay, I just spent a 2 minutes in vain trying to figure out what it does. Need more time.
Bug:
@Everyone: There is a bug when people make @Someone in the comment. Then the link in the ‘Edgeryders.you have been mentioned’ mail contains the link to the @Someone and not to the comment.
Great resource
@Nadia @maymay, Thanks for all the pings and sorry for the delay. This seems like an amazing tool. I think it could be helpful for us to create a larger community of resources. I’ll message you all privately to learn more about how we could apply it to the situation here. And also to plan a potential visit/event!
Software/Training collaboration
I feel like we could work well together on software dev. We are both open source but perhaps our team and your team could collaborate.
We have also developed a compassionate responder training curriculum that may work well for friends who want to be more prepared to respond to eachother in crisis.
Mm design sprint at workshop in NYC on 2/10
Hi @concrn @maymay and I will be at the OPENandChange workshop we’re organising at the @Woodbinehealth space in Queens on october 2: https://www.facebook.com/events/208119996269998 .
Ahead of that the 1 hr crowdconference on twitter later this month is a good opportunity to meet everyone, ask questions, draw in more people. So by the time we are in the room, we’re already made some progress etc: https://edgeryders.eu/en/agora/crowdconference-to-tweet-and-share-openandchange-20-sep-at-1700
There’s already people showing up with UI/UX skills. From a pm: “I was looking over that buoy app ux test video. Have y’all been using it? I’d like to talk to y’all more about visual design for it. I mostly do digital/visual design in the fashion space, but I think my ui/ux could be helpful for this. Have you seen signal? That’s friends of ours who developed and designed it; I think they did a really good job of user-accessibility though for a somewhat foreign concept of encryption, and have also been able to make a platform that can scale. Eitherway, we can talk more when you’re in town. Hyped to hear more about edgeryders.”Also a friend of mine working with infosec will be joining us.
Political economy of policing
I haven’t had time to go over all content here yet but I just came across this presentation that may be relevant for a number of reasons.
Policing in Post-Conflict Societies, pulled from the transscript and slightly edited:
service and his reply was cross and i
