Open Source Bridge 2017

Sessions for this user

Apps and websites routinely expose user information in service of social and interactive goals. But what happens when your user has a stalker? Many of these services will compromise the safety of users who are already at risk. Making things worse, some developers resist making changes, with justifications such as "If someone's in that much danger, they shouldn't be doing anything online," and "It's basically impossible to defend against a state actor."
This overview will help developers take the risk factors into account, and make development decisions that puts control back into the hands of the users. There's no way to perfectly remove the risk of going online if you're in danger, but people will go online anyway. Many more users at risk are facing technically naive attackers than are facing highly skilled attackers such as state actors.

Open Source Bridge 2016

Sessions for this user

What goes into making a helpful bug report, if you're not even given access to the repository? Why should you, the user, report bugs? How do you navigate a series of gatekeepers who don't want to acknowledge your bugs? How do you maintain a good relationship with people in charge of a project that's screwing up your whole life?

Proposals for this user

It's possible to do Support work while knowing absolutely nothing about the underlying architecture. Support doesn't necessarily know why the product works, or even what language it's written in. It can be super tempting for an engineer to think that well, if these support people really had the competence and capacity to understand how the thing worked under the hood, then they'd be engineers and not mere support people, but that's a bad trap to fall into. Sometimes Support people are engineers in their own right, but a Support person with no computer science training can be an expert on the user interaction surfaces of the product and reproduce a result that has been baffling the engineers, even with no knowledge of the mechanism by which the bug is happening. It's helpful to give Support enough information about the architecture to have a better starting point for asking the user for details and trying approaches to replicate the problem.
It can be tempting for Support to think that any given member of Engineering understands the entire breadth, depth, complexity, and interconnectedness of the entire product simultaneously at any given time, but this is a trap! A good amount of time Engineering has no clue in the slightest about what is going on in another branch of the product, and in a sufficiently complex codebase, there can be millions of lines of code that a single particular engineer has never touched or even heard of. Or it's been long enough since they worked on that part of it that they would have to take several hours of very hard study in order to figure out what's going on. In particular, sometimes in a bug report, Engineering can say "Okay, I see what *part* of the code the user is causing to fire, but I haven't the FOGGIEST idea how the customer actually got that to happen." It's very important for Support to list out every single step (even the ones that seem obvious) that leads to the error occurring.

Open Source Bridge 2015

Sessions for this user

Even in an email list, moderation isn't limited to setting the entire email list to require approval before messages are posted. You can create rules which reflect the culture you'd like to see, and call attention to ways that the community differs from that culture. You can point out when a particular post doesn't fit with that culture -- publicly or privately, whichever you think will do the most good. You can point out when a particular post exemplifies something great about the culture. You can point out particular rules that everyone needs to keep abiding by, without calling out a specific post. If a specific person, or a specific handful of people, have trouble with the rules, you could put them in particular on moderated posting for some time. If someone keeps breaking the rules, that person is a good candidate for being removed entirely. There are limits to what the rest of the community and the moderators should have to deal with, even though your project may choose to keep that as a last resort.
Sometimes the problem can be solved by redirection. If the main email list is getting cluttered with off-topic posts, consider a just-for-fun or off-topic side list to divert threads to once they wander off code and into sports, kittens, beer, or knitting. It's easier to say "You shouldn't do that here" than "You shouldn't do that, period"; it's even easier to say "You shouldn't do that here, but it would be great right over there." And most of us could use a sports, kittens, beer, or knitting break every now and then.

Open Source Bridge 2014

Sessions for this user

During the height of interest to the project, there were often several new people arriving in the channel per day. That may not sound like a lot, but everyone had questions and would be interested in different things; it could take a twenty minute conversation or so with someone who knew a lot about the project in order to properly greet, inform, and orient new people. The founders didn't have a few spare hours around the clock to personally devote to making sure that each new arrival was welcomed, felt welcomed, had their questions answered, and had their willingness to contribute channeled into something which needed the help and suited their skills. There was a lot about this that we could have automated or dumped into a higher-latency format like email. The first time someone proposed automating the welcoming dance it was like they'd slapped me in the face. The personal touch bit was crucial, and automating it would have struck all the wrong notes. The project was supposed to be for people, by people, and showing that we're human and we're committed to keeping it small and personal was crucial to keeping the culture intact.