It is a challenge to successfully develop a project by a commitee;
yet it is done by the Free Software community on a large scale and with
many successful examples. The success of this method is built on a set
of loose standards that have evolved over the years. These standards
help streamline collaboration, save time and avoid duplicated efforts;
some of them have direct corrolaries in the world of academic research,
and should not be hard to adapt to. In this page we describe some of
those practices that the Tracer project adopts.
A version control system is a software that keeps track of changes to the code, and can provide information on differences between versions of the code, authors of different changes, and so on. Tracer's code is tracked by a VCS called Git. The Git community website provides information on its usage: getting someone else's code, commiting changes, publishing those, etc.
It is the nature of Git that many versions (so-called "forks") of
the code can exist in the wild, owned by different developers. The
reference version, to be used for incorporating the community's favored
changes, for making releasses, and for starting new development lines,
is Yosef Meller's original tree, hosted on GitHub.
The standard way in Open-Source world to describe changes you have made to a program is the patch.
Experienced collaborators on open source software can use a patch to
review changes without having to look for them first; if they are
familiar with the code, they usually don't have to look beyond the
patch in order to understand it.
Furthermore, patches can be automatically incorporated into source
code, and can also be automatically produced by various software,
including Git (using the format-patch command).
When submitting a change to Tracer's code, please do so by sending a patch to the mailing list, describing in your e-mail the nature of the change, the main places in the code that it touches, and the rationale for making the change.
A patch is not always accepted in its first version. Be prepared to respond to review of other Tracer developers and make changes as deemed necessary - just as you would when submiting a paperto be published in a peer-reviewed journal.
You are encouraged to submit even imperfect code for discussion; however, for a code to finally be accepted, it needs to have:
It is usually beneficial to start a feature implementation by
talking about it in the mailing list. Bug fixes and code changes -
likewise. The direction that the project takes and the state of its
code are everyone's interest. Each party that takes part in Tracer's
development does it for its own reasons, and collaborates with a
project that fits its needs. It is important to see that developers see
eye to eye on important issues.
For this to happen, we request that discussions regarding Tracer are carried on publicly over the mailing list.