ARTICLE

Hiding In Plain Sight: On Being More Transparent

by | Tue 28 Sep 2010

One of the most elemental components of Open Source and thriving community is transparency. We depend on and define transparency as a high priority so that the community feels engaged and informed as it grows, reacts, and nurtures new challenges.

Transparency though is not a single construct; you can’t look it up in the dictionary and get an actionable plan. It is highly dependent on the specific community, it’s size, and how it works.

We have a pretty well defined and transparent governance infrastructure in Ubuntu: our *Community Council* governs the community, our *Technical Board* reviews and approves technical processes and policy changes, and our many team councils (*Developer Membership Board, Regular Membership Boards, Forums/IRC/LoCo Councils* etc) do an excellent job in maintaining domain expertize and governing effectively.

Despite this, it is easy to accidentally latch into what I am referring to as *hiding in plain sight*, and I want to use myself as an example of *what not to do*.

At the last Ubuntu Developer Summit we had a few discussions about how we can better serve the needs of application developers who want to get their app in the Ubuntu Software Center. Today our Ubuntu upload and packager review processes are really designed for those who want to be full blown Ubuntu developers, as opposed to just packaging and uploading a single app that they care about. Over the last few years we have been wanting to better support application developers, and we have provided various technical facilities for this (such as PPAs and Daily Builds), but we have not yet evaluated the best way in which an app developer can get their app in the Ubuntu Software Center.

Thus, we had a discussion at UDS and broke the problem into two areas: the *technical implementation* which I openly vetoed myself having any view on as I believe I lack the technical expertize, and the *governance process* part, which I volunteered to craft a process for. Before the UDS session I produced a rough draft on the Ubuntu Wiki and presented it to the room in the session.

After the discussions at UDS I started work on refining the process. I created a public blueprint to track the work, and I continued to work on the process publicly on the Ubuntu Wiki. When it was looking fairly complete, I invited Matt Zimmerman (who has many years of experience in Ubuntu), Iain Lane (who had been vocally opposed to parts of the technical implementation), and Rick Spencer (who is heavily involved in empowering App Devs) to review the process. I then merged their feedback in. With this complete, I then contacted the Ubuntu Technical Board who then reviewed the process and gave it a +1 after I had made some changes based on their feedback.

After all this I posted the process to the `ubuntu-devel` mailing list and announced that we were looking for volunteers for the new App Review Board that the process outlined. Over the following few weeks was a minor shit storm. Some key members of the community had objections to the technical implementation and some objected the process was just presented to them and was presented too late. As I have said previously, I am deliberately not getting involved in the technical implementation considerations as I lack the technial prowess, but I openly apologized for the process element…I could have done better.

And here, my friends, is the lesson. One could argue that I crafted the process in a very open way, and I did; I drafted it publicly on the Ubuntu Wiki, a tracked the work on a public blueprint, I discussed the first iteration of the process in the UDS sessions, I gathered input from some key people, and I saught approval for the process from official Ubuntu Technical Board. While all of this was fine, there was one missing component: I should have had a conversation with the community on `ubuntu-devel` before taking it to the Ubuntu Technical Board. Once again, I apologize to the community for this mistake; there was no ill will or malice driving this accident, it was the fact that I, my friends, am an idiot at times.

I am a firm believer that mistakes should expect apologies and I wanted this post to not only act as that, but to also help it be a lesson to others. It is easy to assume that the amalgomation of transparent facilities (the wiki, blueprint, UDS sessions, governance) is enough in having a transparent execution on a new process or policy, but these don’t mean a bean if there is little visibility on those resources.

Now, just to be clear, I don’t believe this oversight invalidates the App Review process, and I do believe the goal is still a very valuable one for us to solve (we absolutely *have* to empower and energize app developers), but I do believe that improvements can be made, and I wanted this post to be a testiment to the fact I will endeavor to not make the same mistake again. Mind you, remember, I am an idiot, so I might get this right but then walk right into a lamppost or something. 🙂

An invitation-only accelerator that develops industry-leading community engagement and growth via personalized training, coaching, and accountability...all tailored to your company's needs.

Want to read some more?

Happy Holidays

Happy Holidays

Just a quick note to wish all of you a happy, restful, and peaceful holidays, however and whoever you spend it with. Take care, folks, and I look forward to seeing you in 2015!

The Impact of One Person

The Impact of One Person

I am 35 years old and *people* never cease to surprise me. My trip home from Los Angeles today was a good example of this. It was a tortuous affair that should have been a quick hop from LA to Oakland, popping on BArt, and then getting home for a cup of tea and an...

Feedback Requested: Great Examples of Community

Feedback Requested: Great Examples of Community

Folks, I need to ask for some help. Like many, I have some go-to examples of great communities. This includes Wikipedia, OpenStreetmap, Ubuntu, Debian, Linux, and others. Many of these are software related, many of them are Open Source. I would like to ask your...

Ubuntu Governance Reboot: Five Proposals

Ubuntu Governance Reboot: Five Proposals

Sorry, this is *long*, but hang in there. A little while back I wrote [a blog post](https://archivedblog.jonobacon.com/2014/11/14/ubuntu-governance-reboot/) that seemed to inspire some people and ruffle the feathers of some others. It was designed as a...

Ubuntu Governance: Reboot?

Ubuntu Governance: Reboot?

For many years Ubuntu has had a comprehensive governance structure. At the top of the tree are the Community Council (community policy) and the Technical Board (technical policy). Below those boards are sub-councils such as the IRC, Forum, and LoCo councils, and...

Dealing With Disrespect: The Video

Dealing With Disrespect: The Video

A while back I wrote and released a free e-book called [Dealing With Disrespect](https://www.dealingwithdisrespect.com/). It is a book that provides a short, simple to read, free guide for handling personalized, mean-spirited, disrespectful, and in some cases,...