Interlibr (and related) projects are implemented by a collective of individual contributors each of whom add functionality to the solution on their own terms. Organizationally, features are desired and prioritized but each contributor chooses what they would like to contribute. Due to these factors, the development process exists to make each individual's contributions visible and apparent. We strive to give credit where credit is due.
Conversely, from an organizational perspective, we need to be able to trace the motiviation for any changes to the solution. The why of a change need to be readily apparent so that the core team can determine whether a change is suited to the solution (and thus approved a pull request). Of equal importance is the what of change. The core team needs to be able to identify the effect of a change.
To have a little more flexibility in editing or potentially moving the project, the collective maintains this documentation in revisioned markdown files rather than the Github wiki.
This documentation repository captures project procedures, governance and lifecycle for the Interlibr projects:
-
structure outlines the reasoning behind the layout of the top-level Interlibr project that encorporates several subprojects
-
releases documents the versioning scheme and release preparation for the Interlibr project
-
changes describes how changes are created, planned and integrated into a subproject and eventually into the Interlibr solution
-
journals is an archive of the thoughts, reasoning and decisions individual contributors have made while working on a change