Azure Lunatic's favorites

Open Source Bridge 2016

Favorite sessions for this user

* Accessible By Default

Making your website accessible for users with disabilities isn’t flashy, but it’s necessary. Websites built for universal access benefit all users, not just users with a disability. They’re also more SEO friendly, and are generally built to be more user friendly. From generating increased revenue, to providing better access to services, the benefits of developing accessible websites are real and measurable.
Practice
Kendra Skeene

* Behind Closed Doors: Managing Passwords in a Dangerous World

A modern application has a lot of passwords and keys floating around. Encryption keys, database passwords, and API credentials; often typed in to text files and forgotten. Fortunately a new wave of tools are emerging to help manage, update, and audit these secrets. Come learn how to avoid being the next TechCrunch headline.
Practice
Noah Kantrowitz

* Black Pipe Testing, or "@#$! Up Your App by Impersonating a Database"

A “black box” test sends input to your program and tests the output. But a networked application has I/O at two ends: the API and the network. A black box test can’t validate it, especially its error-handling. But a “black pipe” test can! Such a test talks to your code over the network at the same time as it tests the API. I’ll present a handy library for Black Pipe tests of MongoDB apps and advise you when to use it. I want you to write a library like it for your favorite DB, so we can all test our programs better!
Practice
A. Jesse Jiryu Davis

* Corporate Open Source Fail

What makes companies with good intentions fail so miserably at open source? How can we (as engineers and managers) influence our bosses to "do the right thing"?
Business
Sarah Sharp

* Exit Condition: when to ragequit, raise hell, or duck and cover

If you're caught in a job or a project where you simply can't convince your colleagues or organization to treat you with respect, it often feels like you're in a maze with no clear way out. (Un)fortunately, you're not alone. There's no universal solution to navigating a toxic or abusive workplace, but there's power in finding a theoretical context, sharing our stories, and learning from each other. Come learn about the options of voice, loyalty, and exit, and hear the stories of others who have had to make hard choices.
Culture
Frances Hocutt

* Hard Problems in Terms of Service Enforcement

When you run an online service, you always hope you won't have to deal with abuse. But it's inevitable, and many situations aren't clear-cut as you might wish. Some examples of abuse are obvious, but this talk explores the grey areas and messy questions: what content should you consider a violation of your Terms of Service, and how do you handle it when it's reported to you?
Culture
Denise Paolucci

* Hogwarts is a Terrible Learning Environment: Discuss

Like many young Muggles of the early 00's, I dreamed of receiving my Hogwarts letter. But re-reading the series with an eye toward learning lessons about creating a positive learning environment, it's clear that Hogwarts School of Witchcraft and Wizardry contains some unfortunate lessons in what NOT to do. When it comes to crafting an environment that encourages asking questions, fosters cooperation, and ensuring the success of its developers -- I mean, wizards -- we can learn a lot from the mistakes of the Hogwarts faculty. In this magical talk, you'll learn how to be a better mentor and help your workplace become a place where your junior developers can flourish.
Culture
Lacey Williams Henschel

* How NOT to run your organization into the ground: lessons from Wikimedia Philippines for open source

Running a tech non-profit, especially in open source, is a lot of work. So much work, in fact, that in my six years as part of Wikimedia Philippines, I will admit to one of my biggest secrets: I have run my organization into the ground. Luckily for us, however, we've been really fortunate to be able to rebuild the organization from the ground up. Here's some of the lessons we've learned over the course of that process, and how you can avoid making the mistakes we made as you either form or build your own organization.
Culture
Josh Lim

* Less Painful Legacy Code Replacement

Replacing legacy code is a challenge on every front, from managing stakeholder expectations to tackling the technical work. Thoughtful preparation and a pocket full of tools can make the experience a little less painful.
Practice
Jennifer Tu

* Librarians and Open Source: We Need Code, Too!

Getting people started is easy. Sustaining people through is not. Let's talk about the ways the Open Source community can help people beyond the beginning steps, in the context of public library programming and staff development.
Culture
Alex Byrne

* More Than Binary: Inclusive Gender Collection and You

Many people identify their gender in many ways. So why do we build systems to capture accurate gender information with a dropdown that only lists “male” and “female”? This talk covers why you might want to consider alternative ways of selecting gender for your users, a brief overview of the current best practices, the case study of the decisions I made when creating my open source project Gender Amender (a library you can help work on right now!), and why more work needs to be done. I'd also like to facilitate a short discussion during the time slot, so that we can share varied perspectives on how to improve the entire process of gender collection, and articulate the lenses through which we can and should view gender (e.g. “what are some other data structures we could use to capture gender identity information?”).
Practice
Anne DeCusatis

* Postcards from the Edge Case: When One Size Doesn't Fit All

For every average person that finds your product what they want, there is a person outside that average that wants to use your product. They might even be able to use your product, if there was a way to make it work for them. Outliers are useful for your design, if you harness them properly.
Culture
Alex Byrne

* The Folk Knowledge of Bugzilla

It's good to know if a bug is a regression, and if I want to mark a bug as a regression, there's a keyword for that. (searches on regression keyword.) But there's also a whiteboard tag for that (searches on whiteboard tags containing 'regression'.) Oh dear, and let me unique that out and there's how many ways to say "this is a regression." If you're a release manager, how do you find out what bugs may be regressions and that you want to follow up on with your engineering leads?
Practice
Emma Humphries

* Working Around a Project with Twenty Years of Precedents

How do you deal with a free software project that has been ongoing for many years? What happens when the original designers moved on long ago and even the elders don’t have all the answers? This session will examine how to work with existing precedents to drive evolution of the project.
Culture
Darrick Wong

* Yelling As A Service: Adventures in Unofficial QA

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?
Practice
Azure Lunatic

Favorite proposals for this user

* Exploring Privilege in Open Source Communities

In many open source communities, privilege is rarely discussed. While it is not an easy topic to talk about, it is an important subject to explore if we want to make sure open source is truly open to everyone. After exploring sources of privilege and learning strategies to deal with it, we can all be better equipped to take action to improve our open source communities for the long run.
Culture 2016-04-12 16:46:20 +0000
Taylor Barnett

* Fail Early, Fail Often, Fail Well

If failure is inevitable, why aren't we taught how to cope with it? In this talk I outline 10 types of failure to avoid and detail a framework for navigating recovery from failures large and small.
Business 2016-04-11 00:59:34 +0000
Josh Simmons

* How I Learned To Stop Worrying and Love the Engineers: cross cultural clashes between Support and Engineering (and some ways to fix them)

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.
Culture 2016-04-14 06:31:31 +0000
Azure Lunatic

* Lossless Emoji - Doing Emoji Right

Learn how difficult it can be to do emoji right and what you can do to preserve the message and emotions of your users. If you take user input, you owe it to the internet to attend this talk.
Practice 2016-04-13 07:21:09 +0000
Ryan Kennedy

* Machine Ethics and Emerging Technologies

An autonomous car is driving down a single-lane road carved out of a cliff. Unexpectedly, a child runs in front the car chasing a ball, and trips. The car cannot stop in time to avoid a fatal collision, but it can sacrifice itself and its passenger by driving off the cliff. Should it? And if so, would you buy such a car?
Theory 2016-04-14 07:32:44 +0000
Paul Fenwick

* Open Source Fan Service

What can you do when someone submits a bad patch to your project? To begin, we have to understand why people hunger to contribute code: they're fans. You hurt fans' feelings when you reject their patches, but you hurt your project if you accept them. You can get out of this bind! Give your fans other ways to be recognized. Showcase their plugins in your project’s wiki, or rewrite their patches while giving them credit, or feature their related projects on your site.
Culture 2016-03-26 21:59:46 +0000
A. Jesse Jiryu Davis

* Technical writing as public service: working on open source in government

What if U.S. federal agencies decided to reuse and contribute to open source software projects built by other agencies, since agencies often have similar technology problems to solve? And what if they hired technical writers with open source community experience to write documentation for these projects? That would be pretty cool. Also, that’s my work. I'm part of 18F, a digital services consulting team within and for the federal government, and all of our work is open source.
Practice 2016-04-06 00:21:15 +0000
Britta Gustafson

Open Source Bridge 2015

Favorite sessions for this user

* Community Moderation: you can't always halt a flamewar with one raised eyebrow (but it rarely hurts to try)

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.
Culture
Azure Lunatic

* How We Learned To Stop Worrying And Love (Or At Least Live With) GitHub

In the past few years, GitHub has become the most widely used platform for managing open source projects, thanks to the ease it provides for submitting and accepting pull requests. However, GitHub's issue tracker is not as full featured as more venerable bug trackers such as Bugzilla, and it is not as easy to use for organizations which have a large number of casual contributors. Come hear how one organization coped with the sudden loss of their Bugzilla database by restructuring their tracking workflow to use GitHub's built-in issue management features, as well as implementing API hooks to provide missing functionality.
Cooking
Jen Griffin, Athena Yao

Open Source Bridge 2014

Favorite sessions for this user

* "Why are these people following me?": Leadership for the introverted, uncertain, and astonished

So you've had an idea, or noticed a gap that needs filling, or wondered why no one's talking about an issue you care about. Like the motivated and competent person you are, you start working, or writing, or talking. People start noticing you, listening to you, even asking for your opinion about their own projects--and one day, you realize they're treating you just like you treat your own role models. You find this unsettling. Surely motivation and competence aren't that special, you think. You, a leader? Can't be. And if you actually are a leader, what do you do now?
Culture
Frances Hocutt

* A short examination on the intersection of security and usability (or How usable security could save us all)

This talk is geared for people with minimal experience with usability and some experience with security
Chemistry
Morgan Miller

* Build your own exobrain

Online services like "If This Then That" (IFTTT) are great for automating your life. However they provide limited ways for the end-user to add their own services, and often require credentials that one may normally wish to keep secret. The 'exobrain' project allows for service integration and extension on a machine *you* control.
Cooking
Paul Fenwick

* Civilizing IRC and forums: moderation strategies for mutual respect

As a project's public IRC channel or forum grows, it's hard to keep it friendly. People get frustrated with each other, people have "different" senses of humor, disagreements escalate...oh goodness, it can be a mess. This isn't great for retaining community members or welcoming new ones. I'll share my strategies for dealing with problems, learned at the scale of hundreds of forum threads, tens of thousands of forum visitors, and dozens of IRC chatters every day.
Culture
Britta Gustafson

* Data, Privacy, & Trust in Open Source: 10 Lessons from Wikipedia

Few people today are not concerned with the way data is used to enhance or subvert individual privacy. This is especially true on the Web, where open source technologies are behind much of what we interact with and use on a daily basis. As the most fundamental aspects of our lives become networked -- social relationships, work, finance, and even how we get our food -- how can we make sure that open source technologies foster a sense of trust with users, protect their privacy, and still give data scientists the tools they need to gain insight?
Culture
Steven Walling

* Explicit Invitations: Passion is Not Enough for True Diversity

Open Source suffers from a lack of diversity. Underrepresented populations, for systemic reasons, might never show up unless Open Source communities 'hack' themselves through explicit invitation & removing barriers to participation. Mozilla is funding two pilot studies designed to explicitly reach out to underrepresented groups in open source today. Seeking people who like to solve problems and then engaging them in a 6 week, full time accelerator program we hope to explore the question: Can we seed our communities by hacking the social/cultural/systemic issues in order to gain technical contributions from a more diverse set of minds and give to participants an experience in tech that might have long term benefits to them?
Hacks
Lukas Blakk

* Feminist Point of View: Lessons From Running the Geek Feminism Wiki

The Geek Feminism wiki is one of the central resources for feminist activism in geek communities ranging from open source software to science fiction fandom. Learn how the GF wiki started, how it's run, and what we've learned about doing activism the wiki way.
Culture
Alex Bayley

* Hacking In-Group Bias for Fun and Profit

Our lives and social interactions are governed by sociology and psychology. As geeks, we strive to understand how the technology around us works, and we strive to find ways to make it better. Society is basically one big, complex piece of technology, and, like all technology, it is hackable. This talk will explain how you can do that.
Culture
Kat Toomajian

* Internet Archive: More than the Wayback Machine

In this session we will: * Give you a tour of Internet Archive and its collections * Introduce you to the APIs and tools you can use to access and contribute to the Archive * Show examples of how other people and institutions are using the Archive
Chemistry
VM Brasseur, Alexis Rossi

* It's Dangerous to Go Alone: Battling the Invisible Monsters in Tech

It can be hard to focus on your love of coding when you are regularly battling invisible issues like insecurity, anxiety, and lack of confidence. This talk will identify invisible issues programmers struggle with, talk about their impact, discuss personal experiences dealing with them, and share some tools useful in fighting back.
Culture
Julie Pagano

* Keeping your culture afloat through a tidal wave of interest ~~\o/~~

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.
Culture
Azure Lunatic, Kat Toomajian

* Knitting for programmers

Yeah, you've seen us knitting during talks. I promise we're paying more attention than the people with their laptops open. Well, now learn how we do what we do... the programmer way. I'll start with the topology of individual stitches and go through geometry to design patterns, and by the end of it you'll know how to knit a sweater.
Hacks
Alex Bayley

* Slytherin 101: How To Win Friends and Influence People

Do you wish that you were better at getting people to do what you need them to do? Do you keep getting put in charge of things and then get stuck wondering how the heck you're supposed to get things done? Do you keep getting into conflicts with other people because of stuff you've said, and you aren't entirely sure why? Fortunately, Slytherin House has you covered. Come to this talk and learn the basics of how to hack human relationships, using the tools of cunning and ambition to achieve inter-House harmony. As long as you promise not to use these techniques to support the next Dark Lord, of course.
Culture
Denise Paolucci

* Unicorns Are People, Too: Re-Thinking Soft and Hard Skills

As developers, we tend to value hard skills that can be quantified or measured objectively. Job postings search for unicorns, but we are people first and foremost and being human isn't as easy as programming. While the code comes easily, the soft skills that make us human are complicated and difficult to get right. This talk will explore the danger of neglecting so-called "soft" skills, what we stand to lose by overvaluing technical skills, and alternatives to the hard and soft dichotomy.
Culture
Liz Abinante