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. 🙂