Kiera Manion-Fischer's favorites

Favorite sessions for this user

* Accidental Developer Evangelism

Learn how to organize community events and share your ideas with the open-source community AFK!
Katherine Fellows

* API Design Through the Lens of Photography

To be successful in photography and API design, you must first understand the constraints of the medium, both technical and non-technical. Learning how to work within constraints and finding your own style are critical to being a successful photographer and API designer.
Bryan Hughes

* 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.
Noah Kantrowitz

* Building a Life with WordPress

If you're dying to stick it to the man, or just looking to make extra money on the side, this talk is for you. We'll explore ways you can leverage the most popular CMS on the planet to start or grow an online business.
Kronda Adair

* 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"?
Sarah Sharp

* Creating a Third Wave of Free/Open Source Software

The free/open source software movement is over thirty years old, and has gone through a number of changes in that time, spawning projects large and small (including OpenConferenceWare, which runs this site!). If Free Software is the first generation, and Open Source is the second, current efforts toward creating an inclusive and sustainable world make up a third generation that we can start to form into a broader plan.
Audrey Eschright

* 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.
Frances Hocutt

* Hardware Hula Hoops and Flow

In psychology flow is the honed in energized focus you get when performing tasks that are challenging that can be experienced in hula hooping and programming.
Lindsey Bieda

* 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.
Lacey Williams Henschel

* Introduction to Clojure

Move fast and break things in this 100-minute, introductory-level Clojure workshop!
Katherine Fellows

* 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?
Emma Humphries

* Unraveling the Masculinization of Technology

Have you ever wondered where the perception that technology is a masculine pursuit comes from? Or why we have to explain that, "no really, women are interested in computers too"?
Audrey Eschright

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

Favorite proposals for this user

* Community > Documentation > Code: a Guide to Successful Open Source

Many people create projects with amazing technical prowess, only to see it fail to gain traction. We wonder "I thought this was clearly the best solution, why aren't people using it? Did I miss some bugs? Is it too slow? What went wrong?" The answer usually isn't technical, it's documentation or community related. This talk will teach you all the non-technical things your project needs to gain traction.
Culture 2016-04-16 02:12:52 +0000
Bryan Hughes

* Even Cowboy Coders Get the Site Reliability Blues

The principles behind building reliable distributed systems and gracefully managing changes in them turn out to look a lot like the principles behind building psychologically safe communities. In this talk, I'll explain some of the basic principles behind site reliability engineering and how they relate to feminist and social justice ideas. This talk assumes no prior knowledge of site reliability engineering.
Culture 2016-04-19 22:32:28 +0000
Tim Chevalier

* Hackers & Hearthstone & Humanity

Sometimes the tech community can feel like it is without soul so Hackers & Hearthstone was created to focus on the cool things people are doing within the technology world.
Culture 2016-03-30 15:24:46 +0000
Lindsey Bieda

* 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

* In the Trenches of Open Source Culture: The Node.js Inclusivity Working Group

The goal of this working group strikes deep at the heart of problems in open source software. We hear the stories of contentious and dramatic flare-ups, but not the day to day work people do to make things better. Come learn what it's like and what it takes to make a difference in OSS culture.
Culture 2016-04-16 02:04:52 +0000
Bryan Hughes

* 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