=head4 Introducing a feature
+When a use case prototype is completed in all details and cleaned up,
+the architect has to decide in when and in which form it will be introduced,
+to prevent experience rot (L<http://www.uie.com/articles/experience_rot/>).
+It will happen during one sprint and via a feature branch that will introduce
+all changes in program, libs, docs and tests as one commit. So even if the history
+of the branch will be preserved - the merge happens with a rebase. As a first
+step the libs with theirs tests will be expanded. After that the caller follow.
-Only completed features with their tests are acceptable to the main dev branch.
-You may preserve their history in the feature branch, that picked up the code
-from a use case prototype and brought it to insertable form.
-one rebased commit. Preserve history only in the branch if preferred - not in master.
-This means: at this point we use short lived feature branches,
-that pick the the code from a use case prototype and bring it into the program.
-Try to bring the programm with the merge into a state, where it could be shipped today.
-This not only means that the code is documented, commented and has test coverage.
-Also configs and other auxiliary data like icons should be included.
-If there is an config dialog or config files - all switches for the new function
-are there and do work. make sure you only rely on included libs or modules that
-are listed in the installer. Please mention also in the comments which prototypes
+If there is an config dialog or config files - all switches for the new function
+are there and do work. Make sure you only rely on included libs or modules that
+are listed in the installer. Please mention also in the comments, which prototypes
were the basis of this feature.
The rise of Extreme Programming (XP) gave also rise to Test Driven Development (TDD),