DevOpsDays Boston 2016 is currently accepting session, tutorial, and lightning talk proposals from interested speakers. Our programming is focused on three goals:

Diverse backgrounds

We’re eager to provide a platform to our speakers, so if devops hasn’t included people like you in the past, tell us about it in your proposal. We want to make a space for the perspectives of people that are underrepresented in or excluded from technology: people of color, women, LGBTQ people, people with disabilities, students, veterans, and many more. In the more specific context of this event, we want to hear about devops from a wide set of roles: QA testers, security teams, DBAs, network administrators, compliance experts, UX designers, government employees, scientists, and other technologists who face unique challenges.

New ideas

Sure, we know that Docker’s hot right now - but what’s going to be hot next year? What about in five years? Present the right idea at the right time, and you could help shape that! To help keep our content fresh, preference will also be given to talks that have never been presented at a conference, or even better, to speakers who aren’t regulars on the “conference circuit”.

Healthy discussion

Most session submissions focus on how to use a specific piece of technology - and most of those are not accepted. The most memorable conference talks question assumptions, make predictions, or draw conclusions. It’s even okay to (respectfully) tell someone that they’re wrong - we’d much rather have a disagreement than a room full of nodding heads! DevOpsDays are centered around open spaces, and a good session should act like fertilizer for them, giving people something to start talking about.

We’re also very interested in nominations. Did you see an awesome presentation at another conference? Is one of your friends hoping to break into the conference circuit? Let us know who to reach out to, or send an introductory email yourself!

Programming guidelines

In 2016, we are actively soliciting programming that addresses these topics:

• Software development practices for the devops world
• Velocity, sustainability, and technical debt
• Quantifying productivity, failure, and risk metrics
• Professional development, teaching, training, and mentorships
• Emotional labor and empathy
• Teaching junior engineers how to be senior engineers
• Mental health, stress, and burnout
• Learning lessons from other fields (manufacturing, military, etc.)

We will also accept submissions on perennially popular topics from previous DevOpsDays:

• Continuous deployment
• Automation
• Containerization
• Performance monitoring
• Configuration management
• Devops in the enterprise
• Microservices
• Development methodology
• Scaling out devops
• Hiring for devops

However, please consider that novelty is heavily encouraged as per our guidelines above. These topics are popular, but every year we receive more submissions about them than we can accept.

Please keep these guidelines in mind:

Absolutely no vendor pitches

If your talk is only interesting to someone paying money for your product, it’s a bad fit for DevOpsDays.

Follow the code of conduct

For example: no threats, no sexualized language or imagery, no insulting audience members

Explain why your proposal is interesting to the devops community

We’d rather have a lackluster abstract about a very interesting topic than a detailed outline of a topic that isn’t a good fit.

Your talk will go through a blind review process

That means that reviewers will receive a version of your talk edited to obscure all names, companies, and so on. Make sure that your proposal still makes sense without this information.

Avoid purely technical talks

We all love technology, but this isn’t a programming language conference or a Docker conference. Talk about tools in the context in which they’ll be used, and relate them to the problems that they solve.

Multiple proposals won’t all be accepted

If you send in five proposals, we’ll accept the one that is the best fit for the conference. It’s very rare that any speaker will speak more than once, because that would lead to very homogenous programming.