[zeromq-dev] Git workflow proposal

[Pieter Hintjens]

On Mon, Aug 16, 2010 at 1:50 AM, Martin Sustrik <sustrik at moloch.sk> wrote:

> Yes, documenting post facto is the only meaningful way to do it for
> experimental work.
>
> Not so with bug fixes!

It's the "lone inventor" view of software development vs.
collaborative development.

Experimental work does not need to be tied to real pragmatic needs, of
course.  It can be 100% disconnected from the pragmatic needs of real
users.  I've enjoyed doing that for years and seen the results die.
GSL would be a good example.  Whereas products that were closely
driven by user needs, like Xitami, refused to die even when I tried to
kill them.

However if experimental work is based on the pragmatic needs of real
users, those needs can be documented and discussed.  And if they are,
that allows wider collection of knowledge about those needs.  By
definition, almost, the lone inventor's view of a problem is skewed
and incomplete.  Documenting the solution afterwards means it will
need to be changed after the fact to take into account the knowledge
that was not allowed to enter the process earlier.  Or it will be
partly broken.

In practice what this means is tracking experimental work is of course
pointless since much of it is never completed.  However, tracking the
use cases, problems, and knowledge of what is broken (hence the basis
for those experiments) appears to let us work more accurately with
less effort.

There is a classic anti-pattern: people documenting and discussing
solutions when they should document and discuss problems.  This is
probably where your issue tracking chaos came from.  Also from not
separating different urgencies of problem into different spaces.
There are many ways to document and discuss, not equivalent.  IRC is
not email is not Jira is not a wiki is not a PDF.

In fact we did often document knowledge of problems, via whitepapers,
and many of those remain useful and relevant today.

Look at a discussion like the blog thread on reliability and you see
this process working well.  How different than an expert in
reliability going off and writing something in 0MQ, then discussing
it.

-Pieter