Versioning - Revision history

Marcin: /* Versioning */

2024-04-19T16:19:41Z

Versioning

← Older revision		Revision as of 16:19, 19 April 2024
Line 14:		Line 14:
	Versioning practice at OSE follows the naming convention of ''naming the module under development followed by v for version and date''. Example:		Versioning practice at OSE follows the naming convention of ''naming the module under development followed by v for version and date''. Example:

	'''3D_Printer_v19.10'''		{{check}}{{check}}{{check}}{{check}}'''3D_Printer_v19.10'''

	This refers to the 3D Printer, the version whose start build date was October of 2019.		This refers to the 3D Printer, the version whose start build date was October of 2019.

Marcin: /* 2024 Integration */

2024-04-19T16:19:14Z

2024 Integration

← Older revision		Revision as of 16:19, 19 April 2024
Line 1:		Line 1:
	=2024 Integration=		=2024 Integration=
			Versioning applies to immortal evolution of product ecologies, and we thus take versioning seriously - consistent with lifetime design and lifelong learning for creating a democratic society.

	The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.		The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.
	*Main product dev follows the ''Main Convention'' as below		*Main product dev follows the ''Main Convention'' as below

Marcin: /* 2024 Integration */

2024-04-19T16:17:48Z

2024 Integration

← Older revision		Revision as of 16:17, 19 April 2024
Line 1:		Line 1:
	=2024 Integration=		=2024 Integration=
	The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.		The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.
	*Main product dev follows ~~convention~~ as below		*Main product dev follows the ''Main Convention'' as below
	*[[Critical Paths]] are a great study of past planning and progress, so that one can assess build time more realistically - gaining insight into actual production. To version critical paths - keep the same document		*[[Critical Paths]] are a great study of past planning and progress, so that one can assess build time more realistically - gaining insight into actual production. To version critical paths - keep the same Google Slides document, and make a copy as soon as you make any changes - to make slip readily transparent and thus a teaching moment.
			*[[Data Collection]] versioning - add data collection by product, according to the Main Convention. Keep adding to the specific project for your contribution. An embedded spreadsheet would work great as well.

	=Introduction=		=Introduction=

Marcin: /* 2024 Integration */

2024-04-19T16:13:27Z

2024 Integration

← Older revision		Revision as of 16:13, 19 April 2024
Line 2:		Line 2:
	The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.		The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.
	*Main product dev follows convention as below		*Main product dev follows convention as below
	*Critical Paths are a great study of past planning and progress, so that one can assess build time more realistically - gaining insight into actual production. To version critical paths - keep the same document		*[[Critical Paths]] are a great study of past planning and progress, so that one can assess build time more realistically - gaining insight into actual production. To version critical paths - keep the same document

	=Introduction=		=Introduction=

Marcin: /* 2024 Integration */

2024-04-19T16:13:08Z

2024 Integration

← Older revision		Revision as of 16:13, 19 April 2024
Line 1:		Line 1:
	=2024 Integration=		=2024 Integration=
			The intent is swarming at the 1000 person scale in 4 years, and 1M person scale in 5 years, for one week vacations. This would yield 60k hours and 60M hours of highly coordinated development. The value thus created would be $3M at an hourly rate and $5M at a weekly rate ($5k/week value generation) - and in the 1M case $3-5B - sufficient to solve significant problems such as opensourcing a significant fraction of the technosphere, solving regional resource conflicts, etc.
	*Main product dev follows convention as below		*Main product dev follows convention as below
	*Critical Paths are a great study		*Critical Paths are a great study of past planning and progress, so that one can assess build time more realistically - gaining insight into actual production. To version critical paths - keep the same document



	=Introduction=		=Introduction=

Marcin at 16:05, 19 April 2024

2024-04-19T16:05:51Z

← Older revision		Revision as of 16:05, 19 April 2024
Line 1:		Line 1:
			=2024 Integration=
			*Main product dev follows convention as below
			*Critical Paths are a great study



	=Introduction=		=Introduction=

Line 6:		Line 12:
	Versioning practice at OSE follows the naming convention of ''naming the module under development followed by v for version and date''. Example:		Versioning practice at OSE follows the naming convention of ''naming the module under development followed by v for version and date''. Example:

	3D_Printer_v19.10		'''3D_Printer_v19.10'''

	This refers to the 3D Printer, the version whose start build date was October of 2019.		This refers to the 3D Printer, the version whose start build date was October of 2019.

Marcin: /* Difficulty of Applying the Second Toyota Paradox - Practical Example of Seed Eco-Home 2, 3, and 4 */

2022-10-14T21:46:04Z

Difficulty of Applying the Second Toyota Paradox - Practical Example of Seed Eco-Home 2, 3, and 4

← Older revision		Revision as of 21:46, 14 October 2022
Line 31:		Line 31:
	In practice - the discipline required is to treat every single build as a fork. This goes back to the principle: [[Every Hardware Build is a Fork]]. Ie - to produce separate documentation for each build. As opposed to using folders that do not disambiguate between versions - even if versions are named correctly inside the folders. Or trying to document on the wiki without setting up a new instance of a Dev Template. We do not use such folders in OSE documentation - but instead create an indexical environment in the form of an instance of the Development Template. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype - but [[Seed Eco-Home 4]]. The discipline of documenting required clarity on where to put the documentation. The answer is simple, but it requires working explicitly on multiple documentation sets: putting the existing as-built documentation under version 2, and those things that would be built next under version 4 - which wasn't built yet - or adding more documentation with time to version 3. No shit, right? Except that when it comes down to practice, it takes context-switching ability to document in multiple versions. It's just harder.		In practice - the discipline required is to treat every single build as a fork. This goes back to the principle: [[Every Hardware Build is a Fork]]. Ie - to produce separate documentation for each build. As opposed to using folders that do not disambiguate between versions - even if versions are named correctly inside the folders. Or trying to document on the wiki without setting up a new instance of a Dev Template. We do not use such folders in OSE documentation - but instead create an indexical environment in the form of an instance of the Development Template. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype - but [[Seed Eco-Home 4]]. The discipline of documenting required clarity on where to put the documentation. The answer is simple, but it requires working explicitly on multiple documentation sets: putting the existing as-built documentation under version 2, and those things that would be built next under version 4 - which wasn't built yet - or adding more documentation with time to version 3. No shit, right? Except that when it comes down to practice, it takes context-switching ability to document in multiple versions. It's just harder.

	In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.		In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. It is not possible to work on one version - otherwise important documentation would be lost (the principle of [[Future Documentation Never Happens]]. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.

	=Semantic vs Intuitive Versioning Controversy - Theoretical=		=Semantic vs Intuitive Versioning Controversy - Theoretical=

Marcin: /* Controversy - Practical Example of Seed Eco-Home 2, 3, and 4 */

2022-10-14T21:44:55Z

Controversy - Practical Example of Seed Eco-Home 2, 3, and 4

← Older revision		Revision as of 21:44, 14 October 2022
Line 23:		Line 23:
	#If multiple versions are iterated in the same month, name the latter one with the DAY it was started, such as v19.10.22 (for starting on October 22)		#If multiple versions are iterated in the same month, name the latter one with the DAY it was started, such as v19.10.22 (for starting on October 22)

	=~~Controversy~~ - Practical Example of Seed Eco-Home 2, 3, and 4=		=Difficulty of Applying the Second Toyota Paradox - Practical Example of Seed Eco-Home 2, 3, and 4=

	The Theoretical Controversy ~~below~~ focuses on naming. But that's solved easily by making a decision one way or the other. The answer as in all complex systems is: both! And it is human integrity and value-add that provides meaning.		The Theoretical Controversy in the next section focuses on naming. But that's solved easily by making a decision one way or the other. The answer as in all complex systems is: both! And it is human integrity and value-add that provides meaning.

	But the really difficult part, from the practical perspective - is how to treat multiple versions of a product-in-development. The [[Second Toyota Paradox]] prevents simple selection of one branch as the 'main branch' - if multiple development paths are ongoing. A single development path is representative of a non-collaborative development effort: one goes into a corner with their branch - and comes back with results. In a collaborative approach, the developer entertains and tracks multiple development paths - in order to synthesize the best answer from a mashup of solutions~~. This goes back to the principle: [[Every Hardware Build is a Fork]]~~.		But the really difficult part, from the practical perspective - is how to treat multiple versions of a product-in-development. The [[Second Toyota Paradox]] prevents simple selection of one branch as the 'main branch' - if multiple development paths are ongoing. A single development path is representative of a non-collaborative development effort: one goes into a corner with their branch - and comes back with results. In a collaborative approach, the developer entertains and tracks multiple development paths - in order to synthesize the best answer from a mashup of solutions (because multiple solution paths are being entertained).

	In practice - the discipline required is to treat every single build as a fork. Ie - to produce separate documentation for each build. As opposed to using folders that do not disambiguate between versions - even if versions are named correctly inside the folders. We do not use such folders in OSE documentation - but instead create an indexical environment in the form of an instance of the Development Template. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype - but [[Seed Eco-Home 4]]. The discipline of documenting required clarity on where to put the documentation. The answer is simple, but it requires working explicitly on multiple documentation sets: putting the existing as-built documentation under version 2, and those things that would be built next under version 4 - which wasn't built yet - or adding more documentation with time to version 3. No shit, right? Except that when it comes down to practice, it takes context-switching ability to document in multiple versions. It's just harder.		In practice - the discipline required is to treat every single build as a fork. This goes back to the principle: [[Every Hardware Build is a Fork]]. Ie - to produce separate documentation for each build. As opposed to using folders that do not disambiguate between versions - even if versions are named correctly inside the folders. Or trying to document on the wiki without setting up a new instance of a Dev Template. We do not use such folders in OSE documentation - but instead create an indexical environment in the form of an instance of the Development Template. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype - but [[Seed Eco-Home 4]]. The discipline of documenting required clarity on where to put the documentation. The answer is simple, but it requires working explicitly on multiple documentation sets: putting the existing as-built documentation under version 2, and those things that would be built next under version 4 - which wasn't built yet - or adding more documentation with time to version 3. No shit, right? Except that when it comes down to practice, it takes context-switching ability to document in multiple versions. It's just harder.

	In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.		In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.

Marcin: /* Controversy - Theoretical */

2022-10-14T21:41:02Z

Controversy - Theoretical

← Older revision		Revision as of 21:41, 14 October 2022
Line 33:		Line 33:
	In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.		In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.

	=Controversy - Theoretical=		=Semantic vs Intuitive Versioning Controversy - Theoretical=
	Software people favor the dot number convention ([[Semantic Versioning]]) v1.0, v1.1, v1.1.1 etc. This can be used, but OSE favors the more transparent date-based notation - which includes a sense of project management for overall project completion according to the [[Critical Path]] and [[Product Ecology]] - involving the 2028 finish date. Knowing which versions are being worked at the same time provides immediate information (by virtue of version date in the name) on project activity for purposes of coordination with large parallel teams.		Software people favor the dot number convention ([[Semantic Versioning]]) v1.0, v1.1, v1.1.1 etc. This can be used, but OSE favors the more transparent date-based notation - which includes a sense of project management for overall project completion according to the [[Critical Path]] and [[Product Ecology]] - involving the 2028 finish date. Knowing which versions are being worked at the same time provides immediate information (by virtue of version date in the name) on project activity for purposes of coordination with large parallel teams.

Marcin: /* Controversy - Practical Example of Seed Eco-Home 2, 3, and 4 */

2022-10-14T21:40:42Z

Controversy - Practical Example of Seed Eco-Home 2, 3, and 4

← Older revision		Revision as of 21:40, 14 October 2022
Line 29:		Line 29:
	But the really difficult part, from the practical perspective - is how to treat multiple versions of a product-in-development. The [[Second Toyota Paradox]] prevents simple selection of one branch as the 'main branch' - if multiple development paths are ongoing. A single development path is representative of a non-collaborative development effort: one goes into a corner with their branch - and comes back with results. In a collaborative approach, the developer entertains and tracks multiple development paths - in order to synthesize the best answer from a mashup of solutions. This goes back to the principle: [[Every Hardware Build is a Fork]].		But the really difficult part, from the practical perspective - is how to treat multiple versions of a product-in-development. The [[Second Toyota Paradox]] prevents simple selection of one branch as the 'main branch' - if multiple development paths are ongoing. A single development path is representative of a non-collaborative development effort: one goes into a corner with their branch - and comes back with results. In a collaborative approach, the developer entertains and tracks multiple development paths - in order to synthesize the best answer from a mashup of solutions. This goes back to the principle: [[Every Hardware Build is a Fork]].

	In practice - the discipline required is to treat every single build as a fork. Ie - to produce separate documentation for each build. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype ~~along the lines of the Second Toyota Paradox~~ - but [[Seed Eco-Home 4]].		In practice - the discipline required is to treat every single build as a fork. Ie - to produce separate documentation for each build. As opposed to using folders that do not disambiguate between versions - even if versions are named correctly inside the folders. We do not use such folders in OSE documentation - but instead create an indexical environment in the form of an instance of the Development Template. The difficulty is: keeping awareness of which build is being worked on. For example, consider the partial build of [[Seed Eco-Home 2]] of 2021. As soon as 2022 rolled around, we already had a next iteration with substantive, build time-saving changes. So we immediately set up documentation (an instance of the [[Development Template]]) for the next iteration. Which turned out to be not [[Seed Eco-Home 3]] - another partial prototype - but [[Seed Eco-Home 4]]. The discipline of documenting required clarity on where to put the documentation. The answer is simple, but it requires working explicitly on multiple documentation sets: putting the existing as-built documentation under version 2, and those things that would be built next under version 4 - which wasn't built yet - or adding more documentation with time to version 3. No shit, right? Except that when it comes down to practice, it takes context-switching ability to document in multiple versions. It's just harder.

			In practice, I was doing CAD on v4, build documentation on v2, design docs on v2 or v4 - pictures under v2 and v3. This is all an example of documenting under the principle of the [[Second Toyota Paradox]]. This is while not even considering Intuitive vs Semantic versioning - discussed next.

	=Controversy - Theoretical=		=Controversy - Theoretical=