How to deliver software: Difference between revisions

Revision as of 20:45, 20 March 2024

split work feature by feature, not layer by layer
squash merge makes the history less useful for investigations or revert
- in particular, a story may result in a refactor commit followed by a feature commit. combining those throws away a ton of information and may make refactoring less attractive to developers. they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
merge your own pull requests, own that responsibility
keep your own tickets up to date. in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up

@@ Line 1: / Line 1: @@
+== Guidance ==
 * https://en.wikipedia.org/wiki/Principle_of_least_astonishment
 * https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
+== Process ==
+* split work feature by feature, not layer by layer
+* squash merge makes the history less useful for investigations or revert
+** in particular, a story may result in a refactor commit followed by a feature commit. combining those throws away a ton of information and may make refactoring less attractive to developers. they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
+* merge your own pull requests, own that responsibility
+* keep your own tickets up to date. in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up
 [[Category:Programming]]
 [[Category:Wisdom]]