Development Template and Transitions

Transitions are new projects, design changes, and forks -

https://docs.google.com/a/opensourceecology.org/presentation/d/1iE-kXfVWHk39-Y4iDCpRJX8G-RWGnF5QoSjYGcf1V3E/edit#slide=id.g785bfa0e2_00

Discussion

Re Slide 2: I don't agree with the statement that a new module version should automatically trigger a new top-module/machine version.

According to the proposal in Naming and Identification and Master Index, a new module version simply creates a new entry in the version index. Or visually speaking, a new, unconnected node in the dependency graph. The top-module/machine version is still unaffected because the dependencies are unchanged so far. The documentation is still up-to-date.

Next, somebody analyzes the top-module of the updated part and decides that the new module version still "fits" into the top-module. Next, this person creates a new version of the top-module and updates its dependencies. Also, this person updates the documentation of the module inside Dozuki (preferrably inside a new category). Responsibility: If somebody updates a module version, they guarantee that all dependencies/submodules/versions "fit". This person is responsible for everything below in the dependency tree.

This process is repeated from bottom to top until the machine version is updated. Beacause everybody is responsible for everything below in the dependency tree, the last version update of the whole machine brings everything into an up-to-date, consistent state.

edit

On the other hand, I agree that forks should be treated like a new machine (with the difference that most info can be copied over from the original).

So far the theory proposal. How does this match the multi-people documentation approach? How to implement in dozuki vs. Wiki? Nathanael Wettstein (talk) 14:48, 10 February 2015 (CET)