Design Process : Distributed Development Framework

Create our own toolset to track issues, tasks, bugs in a distributed manner.

Made this ‘final’, this proposal got accepted and is already in use without much discussion

🌑 ​ 🌒 ​ 🌓 ​ 🌔 ​ 🌕 ​ 🌖 ​ 🌗 ​ 🌘 ​ 🌑

Historical remark: This was ultimately the first conceptual (not process-related) RfC published in this Design-Process (note the date!). Thus, in hindsight, the question arises what this RfC was meant to propose;
During the following months, an ambitious side-project named »uWiki« was started, with the goal to provide a wiki-like web frontend based on completely self-contained storage in a Git repository, without requiring any kind of data base. This project, however — in spite of some compelling prototype implementations — was abandoned; it became clear that such a system can not be bootstrapped from a lightweight, minimalist setup and would require a significant amount of web development rather — a task no one was willing to take on.

Yet the Lumiera project succeeded in building a web presence based on Asciidoc sources checked into Git, with a lightweight commit-hook script to automatically publish any changes on git-push — a scheme which comes close to the gist of this RfC.

After reconsidering this RfC, many years later, it seems prudent to mark it as `Dropped'. The reasons for this decision are manifold. For one, the project never fully embraced this working style, it was a vision from the early days rather. Parts of that vision became a practical reality, like the use of a shared master repository, or the use of Git and Asciidoc to generate and publish our website directly from a hook-script.

But we did not “create our own toolset to track issues, tasks, bugs in a distributed manner”. This idea might seem enticing for a new experimental project, and, when taken further, it leads to a development style where most questions of coordination, and notably the preparation of releases and the delivery and roll-out of published code are handled by an automated production line. Developers can do what they like most: “code cool things” — while all that “nasty other stuff” is dealt with by an »Invisible Hand«.

I do not consider such a setup healthy on the long run, nor can I see how it would be adequate for a project with liabilities to care for: we should not consider the coordination of a release cycle as something extraneous, to be “automated away” — it requires the full attention of the developers rather, to provide a longtime stable version and not to interfere with the work of creative people, using the software in novel ways, not foreseeable by the developers. For this reason, I moved into the opposite direction and have now switched to the Git-flow branching model.

Back to Lumiera Design Process overview