The Case for Using Wiki Version History - Revision history

Marcin: /* Discussion */

2021-02-09T23:03:03Z

Discussion

← Older revision		Revision as of 23:03, 9 February 2021
Line 4:		Line 4:

	=Discussion=		=Discussion=
	See more lengthy ~~hub-bub~~ at [[Talk:The Case for Using Wiki Version History]]		See more lengthy hubbub at [[Talk:The Case for Using Wiki Version History]]

Marcin at 23:02, 9 February 2021

2021-02-09T23:02:27Z

← Older revision		Revision as of 23:02, 9 February 2021
Line 2:		Line 2:

	Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a [[Visual Version History]]. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.		Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a [[Visual Version History]]. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.

			=Discussion=
			See more lengthy hub-bub at [[Talk:The Case for Using Wiki Version History]]

Marcin at 17:50, 6 February 2021

2021-02-06T17:50:35Z

← Older revision		Revision as of 17:50, 6 February 2021
Line 1:		Line 1:
	Using version history is not standard practice in Wikipedia for minor changes [https://commons.wikimedia.org/wiki/Commons:Overwriting_existing_files]. Yet it is critical for the OSE workflow.		Using version history is not standard practice in Wikipedia for minor changes [https://commons.wikimedia.org/wiki/Commons:Overwriting_existing_files]. Yet it is critical for the OSE workflow.

	Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a ~~visual version history~~. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.		Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a [[Visual Version History]]. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.

Marcin at 17:49, 6 February 2021

2021-02-06T17:49:51Z

← Older revision		Revision as of 17:49, 6 February 2021
Line 1:		Line 1:
	Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow.		Using version history is not standard practice in Wikipedia for minor changes [https://commons.wikimedia.org/wiki/Commons:Overwriting_existing_files]. Yet it is critical for the OSE workflow.

	Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a visual version history. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.		Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a visual version history. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.

Marcin at 17:49, 6 February 2021

2021-02-06T17:49:11Z

← Older revision		Revision as of 17:49, 6 February 2021
Line 1:		Line 1:
	Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow.		Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow.

	Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a visual version history. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the Second Toyota Paradox (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.		Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a visual version history. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the [[Second Toyota Paradox]] (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.

Marcin: Created page with "Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow. Because OSE is using the wiki as a repository. Yes, we..."

2021-02-06T17:48:58Z

Created page with "Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow. Because OSE is using the wiki as a repository. Yes, we..."

New page

Using version history is not standard practice in Wikipedia for minor changes. Yet it is critical for the OSE workflow.

Because OSE is using the wiki as a repository. Yes, we can use Gitlab etc, but then we don't control the data, nor do we have access to a visual version history. So there are many reasons why our workflow is like it is, the key being complete collaboration with thousands of people in coordinated CAD design work. Nobody does that in the world. For us there is no apparent advantage of saving as a new file, as then the overhead of managing files is excessive. Version history is critical for collaborative work with delayed final file reconciliation as in the Second Toyota Paradox (see wiki on that). Version history is more critical in hardware than software, as each hardware build is effectively a fork. That's a bunch of jargon here, but that's core to our dev method, which can scale to meaningful hardware prototyping with thousands of people.