Working in the Open

This thread aims to get a broad perspective on working in the open at the Participation team.

Of course, there is an article on the Wiki: Working open

Main questions / starting points / ideas:

  • What do people expect from working in the open?
  • What works, what doesn’t?

Definition of people:
This includes, and is not limited to, volunteer as well as staff Mozillians.

Let’s see where this goes. Please remember to treat each other respectfully. We are mindful people looking for meaningful conversations.


For me, if it’s about the Participation team specifically, this starts with - what are the current activities in the team, are there openly accessible meetings and meeting notes (for at least NDA Mozillians, staff and volunteers under NDA should never be treated differently in respect to access to those things, I think)?

Next is, how can people from all relevant areas help with Participation matters? How can we get topics into consideration of Participation activities that may not be on the agenda right now? Are all those paths readily visible and possible to go in an open fashion?

The harder parts will be: How are decisions on what to prioritize or even decline made and documented? Are those things open/public?

All in all, how do we make sure we make all people feel that they are taken seriously and communicated with on equal footing (“auf Augenhöhe” as we’d say in German)?

1 Like

Adding a few links which were sent to me in personal messages:

1 Like

For me working in the open is just learning out loud. I try to make
transparent my thinking and my struggles.

This is different for me as an individual versus an institution working

When I am working as a volunteer contributor I try to blog after each
community call, live blog during events, and make sure our team has decent
documentation of decision making and drafts.

I use a main blog for finished projects and then I may document my process
on another blog or across social media lessons.

1 Like

Another link I remembered …

Inspired by Clint’s blog that I created this workshop in Singapore called ‘Moving Open Forward’ , it looks at the ‘open wins’ in the story of Firefox, and asks people to think about how working open has played a role in their own successes.

Also - “Open Washing” link:

1 Like

What do people expect from working in the open?

Working in the open is a culture and way of thinking. It is exposing your work openly and not keeping it in a silo (at all). The general expectation that I have seen across many open source communities is that work, planning, meetings, and discussion are open to the public so anyone can observe the work being done.

What works, what doesn’t?

That is a difficult question because what works and what doesn’t is a personal questions and the answer is different for everyone. Some contributors and staff have different thresholds as to how open they are willing to work and for some the bar isn’t very high at all. Some individuals and entire teams neglect their obligation to work in the open.

Working in the open is binary: you are either open or not open. There is no half way and there is no giving it your best effort.

Just as an example: last year, myself and a number of other contributors and staff were advocating for IRC channels to be archived to increase openness and accountability. At the end of the day, there were people opposed to their conversations being logged and easily available to the entire world. IRC may be open but accessibility is an issue. By logging, more people would be able to observe much of the work teams do and in the end the decision was made to maintain silos.[1] Notably other open source projects log their IRC channels because they are aware how even IRC can be a silo and discussions had there are not entirely open (they do not meet that binary open or closed they are somewhere in-between).

So this is my two cents and there is no one individual or team to blame here but we could do much better as a project. In order to do that, there needs to be top level accountability and courage from the top down[2] to ensure that the project is really switching its work into that on (open) position.