Simple Mechanisms, Sane Processes

In recent years, becoming a free software contributor has become much easier. Take for example documentation. Many moons ago (well about five years ago), writing docs was hailed as the thing non-coders could do to contribute to free software. The reality of docs back then was that you needed an incredibly complicated toolchain set up with SGML / Docbook / LaTeX or some other such complexity. This was not how docs should work, particularly if writing docs was supposed to be a relatively non-technical contribution – we should have concentrated the mind on the writing and not the toolchain.

This was not unique to documentation. Many other areas of contribution involved complexity or a process not in-keeping with the spirit of that kind of contribution. Examples include making artists use bug tracking systems, complex translation systems and formats, complex UI testing and much more besides. There were too many things which seemed simple and non-technical to the naked eye but actually turned out to be non-technical things wrapped in complexity. Ugh.

Well, today things are getting easier. We are starting to see many of these processes rightly boiled down to their core parts, and some of the technical layers being removed. This is exactly what we need to do to encourage many and diverse contributors – we need the core contribution to be as quick to execute as possible without any bureaucratic and technical junk being thrown in there. Like say in herding cats – we need to understand each type of contribution within the context of its own culture and create processes around that contribution.

But, now to the point of this post. One of the risks of making simple processes for performing a contribution is that some may worry that the quality of such contributions is reduced due to such simple processes – surely simple processes make things too easy and lower the quality of the contributor pool? No, not at all. We should banish the concept of too easy from everyone’s vocabulary. There is no such thing as too easy – life should be easy – why make it difficult and complex? The problem is that easing the physical process of contributing focuses the spotlight on what is needed (and often missing) in every community – effective community processes and management.

Every community needs direction, processes and management. The solution to maintaining high quality contributions is certainly not to make it more complicated to contribute in the hope that you get a better breed of contributor – the real solution is to create effective structures and processes to ensure that people make great, high quality contributions. A great example is translations. You would think that translations are really easy to do, and something such as Rosetta makes them really easy to do. Well, yes Rosetta is simple, but quality translations is not. To create high quality translations there is a certain workflow, a mindset, a set of processes and a set of techniques that should be abided to maintain a level of quality. Good contributions demand simple methods of contributing and good, clear, flexible processes to ensure that the contributions are in a form and quality that is acceptable.

I think that if every team was to think of how it approaches these issues, we could ramp up the quality hit rate in each of our communities. The goal should be simple mechanisms, sane processes. Do let me know if you have seen any particularly good examples of such projects who subscribe to this philosophy. :)

  • http://users.sosdg.org/~stephanie/ Stephanie Daugherty

    Very well said. I’ve been very discouraged by the barriers to participation found in many open source projects. These barriers in both culture and process threaten rather than preserve the vitality of projects, by allowing the same intellectual stagnation and lack of innovation that hampers proprietary software. Quite simply, there is little or no benefit to open source without open community. –Steph

  • http://beza1e1.tuxen.de beza1e1
    1. Every technical problem can be solved by introducing a layer of indirection (cite?).
      1. Every people problem can be solved by removing a level of indirection.
  • Sebastian Heinlein

    Rosetta is a good example that lowering the barriers for beginners and one-time-contributors is not enough. It still lacks a quality assurance and guidance infrastructure. I hope that your blog post was a statement of Canonical to raise the priority of these features.