What does “working in the open” mean? How do we do it at Mozilla — and where do we need to adapt, adjust and improve?
Those are some of the questions we want to explore in the Mozilla Summit’s “Practicing Open” session. The goal: start with a lively discussion around the key issues and themes — including some new ideas Mitchell has been sharing around open. Then work together on something more lasting and concrete: a new FAQ guide on “How to work open at Mozilla.”
Creating an FAQ together
We’re definitely not going to come up with all the answers on this complex topic in two short hours together. But we can brainstorm some great questions and common issues, then follow up on answers together after the summit.
Of course, many smart Mozillians have already done a lot of thinking, writing and sharing around this topic in the past. We’ve been trying to gather some of those links and resources here — please add your own favorite resources and readings under line 115. (Huge thanks to David Boswell for all his help here.)
But an FAQ specifically on working open at Mozilla doesn’t already exist, and it could help put some of our existing resources into helpful context — plus identify gaps we need to update as we move forward.
- Join the “Practicing Open” session at the Summit. Saturday from 1:30 to 3:30pm.
- Contribute ideas. Share ideas, resources, questions you’ve got, or hack on the session’s agenda.
- Submit a question for the new “Working Open FAQ”. What’s hard about working open? Please add your questions to the FAQ wiki page.
- Get in touch with the session facilitators. We’ve been gathering input from Mitchell, Dave Boswell, Gerv and many others — we’d love to hear from you.
Why does working open matter to Mozilla?
Part of what makes Mozilla special is a unique *way of working.* Mozilla is committed to open not only at the level of technology, but also in terms of how we work — for decision-making, discussion, working on specific tasks and bugs, communications and community. It’s a defining part of our culture and history.
That culture and way of working faces new challenges and opportunities. Mozilla has grown enormously in size. The scope and complexity of our products has increased. Specific product requirements can sometimes clash with the goal of transparency. Some documentation and systems may now be out of date.
How should Mozilla practice open in this new landscape? Where are we succeeding? Where are we failing? Do we need a new understanding of when, how and why to practice open? How do we strike the ideal mix of pragmatism and idealism that define “working open” at its best? And how do we make all that practical — answering questions you may have in your everyday work?