Defaulting to open.

One of the fundamental principles I think our community expects from Fedora is that we default to open wherever possible. In other words, unless carrying out a process in an open and transparent way would be impossible (legal reasons, for example), we should do it. And by and large, we really do.

The primary tool for that openness is communication. You can’t be open without talking with people — in advance, to encourage discussion, debate, and an informed decision; during the process, so everyone involved knows the status, tunes expectations properly, and has an opportunity to contribute; and after the work is done, so the community understands and appreciates it.

In any large organization, it’s easy to miss opportunities for better communication. The less open the organization is by nature, of course, the more often that happens. But it’s a reasonable expectation that a collaborative project like Fedora with the levels of openness and transparency we embrace shouldn’t suffer from this problem too often.

If your team is working on an issue that affects another team, by default your modus operandi should include communicating with that team. The best time to do that is when you’re trying to decide how to move forward. If you’ll indulge some business-speak, making your stakeholders’ or customers’ concerns part of your decision making process is important no matter what business you’re in — even if you’re not a business that defaults to open. In a business that does default to open, even though your list of stakeholders or customers may be a bigger list, it’s still an imperative.

Got a question about why a team works the way they do? Wondering why something happened the way it did? Ask them directly, or cc: their list. Mailing lists are tough animals with which to wrestle, especially if you add several to a thread. But that’s not a reason not to have the conversation. Set a followup or reply-to list, and let people know in the opening message where you expect the further discussion to happen.

Contemplating making a change that affects other teams? Get their thoughts early in the process, to avoid the appearance of throwing something over the wall. (Throwing things over walls is for closed or non-collaborative groups, not us!)

Sure, there’s a gray area between consulting enough people early, and trying to achieve unanimous consensus. Unanimity is great when you can achieve it, but it’s not strictly necessary for everything that needs to happen in a project, especially one that needs to move boldly forward as we like Fedora to do. But that gray area is a wide one, and there’s a good distance you can cover without overly inflicting stop energy on a good idea.

Speaking as a fellow contributor, I’d like to see every team in Fedora continuing to make a concerted effort to talk across team lines. That communication needs to start with your own team of course: minimizing private discussions wherever appropriate; keeping teammates engaged in daily and long-term work; and moving discussions where you need more input and discussion off of IRC and onto your mailing list, just to name a few examples. But just as importantly, when necessary let’s renew our efforts to communicate with our fellow teams, to make sure we’re making good decisions, and that overall we are having a positive effect on each other’s contributions in Fedora.

This post was prompted by a couple instances recently where I saw teams not reaching out for each other to ask questions or give information. I haven’t seen evidence of any widespread trends; in general, Fedora team members do a great job of communicating across teams. These instances were exceptions to the rule, but it would be fantastic if those exceptions never happened at all. (Zero may be an unattainable goal, but that doesn’t make it the wrong goal.) I’m not calling out specifics simply because they wouldn’t change the value of the ideas and practices discussed here.