Productive Discussion

Productive Discussions for Decision Makers

At Mozilla, people make decisions, ranging from big, public-facing policy choices to smaller code-level changes. Because we work in the open, it is often wise for decision makers to consult within some subset of the Mozilla community. There are good ways and bad ways to do this. This document exists to help people start, continue and finish community discussions well.

The aim is not to produce some large "Discussion Policy: Required Steps" and make everything heavyweight, but to document best practice which people can apply where relevant to their situation.

Before Discussion

Construct Question

You need to work out what you are going to ask people. It helps to keep the question as simple as possible. The topics discussed may well change, and more questions can be added later, but focusing on a single, simple question will keep the discussion on-topic and lead to a conclusion that fits the problem. Multiple questions increase the likelihood of the discussion focussing on one particular minor point. If you do ask multiple questions, you should define how they fit together.

When forming your question, make sure the question does not sound like a decision has already been made (e.g. "We're going to fix the problem like this, do you agree?").

Provide Context

A question is not asked in isolation. Here are some ideas for additional information it may be wise to provide. This and "construct question" may happen together.

Context: what situation led to the need for a decision, and where the decision fits in relation to the rest of what Mozilla is doing. When starting a discussion, it is important to be clear about why a decision needs to be made. For example, if the decision is about fixing a problem, it is helpful for people to know what the problem is, and why it needs fixing.

Off-Topic: what should be avoided during discussions. If there are particular things you do not want to discuss, mention them explicitly.

Impact: how much people or things (like features, code libraries, products) will be affected by a decision. When setting the scope of a discussion, make sure you think about the impact of the decision both by numbers of people and by size (e.g. will this completely alter something, or is it a small change?)

Timeframe: how long a discussion should take. Some decisions need to be made before a deadline, and others can take their time to get right. In any case, before you start a discussion, try to suggest a finishing time. This can be changed later if it needs to be.

List People

You should consider who definitely needs to be involved in the discussion.

When thinking about this, it can be helpful to look at the categories defined by the "RACI" model:

• Responsible: people who need to implement the decision
• Accountable: people who need to take responsibility for a decision
• Consulted: people who should join the discussion
• Informed: people who should be informed about progress and about the final decision

If you are leading the discussion, it is likely that you are Responsible, Accountable, or both. If you are neither, consider whether one of those people might be a better discussion leader. Otherwise, to find which Mozillian is accountable for a decision, the best place to look is the module owner system.

For consulted people, make sure to consider the following groups, who are common consultees:

• Addons team
• Press team
• Documentation team
• Privacy team
• Security team
• UX team
• Legal team
• Partners

Mozillians who should be informed are those who are directly affected by a decision.

Some discussions might need a moderator, that is, someone who can help lead the discussion and keep it on track. The moderator can be you, or it can be another person. If the topic is a controversial one and you have a strong opinion, it may be wise to invite someone else to moderate for you.

Go/No Go

After considering all of the above factors, you need to decide whether consultation is actually warranted or not. For decisions which turn out to be small, you may not need to start a discussion. Asking yourself the following questions may help:

How many people will the decision affect?

For example, if the decision affects 200 people, you need to consult.

How distant are the people being affected from the decision maker?

For example, if those most affected are part of different teams, you are likely to need to consult them.

Choose Venue(s)

If you have decided to go ahead, you need somewhere to put the written proposal and supporting information (if it is anything more than trivial), and somewhere to have the discussion. These two places will not be the same. This is because proposals for change will usually need to be updated during or after the discussion, and therefore it is unwise to define their canonical location as somewhere where this is not possible - such as the first post in a discussion thread.

Written Proposal: Best practice for written proposals is to put them on the Mozilla wiki. Etherpad does not have sufficient formatting capability to make it a good home for proposals. It also doesn't keep clear change-based history with named editors, whereas the wiki does. Using Google Docs often leads to one of two permissions issues - either people who want to edit can't, or people can, but without leaving details of who they are. A blog post is possible if you want editorial control and are willing to update a post at a later date, but decisions and policies can be long-lived and it might be wise to move it to the wiki for posterity after it's done anyway.

Discussion Venue: Where you decide to have this discussion depends on whether it's possible to make a short list of all the concerned parties or not. If it is not, you should have the actual discussion in an appropriate Mozilla discussion forum. They are topic-based and archived, and their asynchronous nature widens participation. If you do have a short list of concerned parties, there are some other options. Bugzilla is mostly about implementation rather than decision on policy, although the edges are fuzzy. IRC (in a logged channel) is OK if you can be sure everyone can be available at the same time. Unless someone is taking good notes, you should avoid taking significant decisions on teleconferences, Vidyo, or in meetings.

Gather Data

Many decisions require data to inform discussion. For example, you might need to know how many people currently use a feature.

You should have your question and the scope of the decision sorted out before you start gathering data. That way, you are getting the right information to support the discussion.

The best way to gather data is to ask for help from these teams:

• Metrics
• User research
• Market insights

Start Discussion

Kick off your discussion by writing your proposal, and then posting a pointer to it (and perhaps a copy of it) in the medium you have chosen. Introduce the moderator (if needed).

Evangelize Discussion

After the discussion has begun, you should invite people to join and tell people that it is happening, using whatever means you feel appropriate. Include all the people or groups from the list you made above. Keep a note of where you advertise it, so you can post the outcome of a discussion in the same places. Try and funnel discussion to the chosen location rather than engaging in the debate in e.g. blog comments.

Hold Discussion

There are a few things you should keep in mind when holding your discussion:

Expect Disagreement

Mozilla is a wide and diverse community, and people will definitely have different ideas from yours. It is not personal to disagree, even strongly, so try not to take it that way. If a discussion becomes uncontrollable or upsetting, it might be a good idea to invite in a moderator.

It is OK to ask someone to leave a discussion if they are causing problems, but it is not OK to ask someone to leave because they disagree.

Stay On Topic

You've set a scope, and posed your question, so you have a good idea about what should be discussed. Now it is important to stay focused on the decision. If a discussion gets too far off track, it is a good idea to summarize the points made, and ask how they relate to the question you've posed. This is also something a moderator can help with.

Not every point needs to be discussed at length.

Revise Question

Very often, discussions throw up new things which you didn't know when starting out. It is often a very good idea to re-think the question posed, and change it.

Finish Discussion

A discussion is usually finished when a decision is made. Some discussions lead to no decision, and should be stopped because of time, or because they have found that a decision requires a different discussion.

The fact that people still disagree is not a reason to keep the discussion open. If the person responsible for the decision feels all viewpoints have been sufficiently aired, they are entirely permitted to end things there. Unanimity is not a requirement.

Draw the discussion to a close by summarizing the points made, and letting people know that it is finishing.

Make sure to inform people by telling them what the decision was, and summarize the discussion to tell them why. Because the discussion has happened in an archived medium, you can also include a link to the discussion. You should do this any place you announced or publicized the discussion.

In some cases, it may be appropriate for discussion of related issues to continue. In that case, once you have made and clearly communicated your decision, you should make it clear how much more time, if any, you are willing to give to the subject. If the venue is no longer appropriate for continued discussion, you should ask people to move elsewhere, perhaps giving a suggestion.