Realtime Cloud Collaborative Editing - Revision history

Marcin: /* Realtime Design and Merge Conflicts */

2020-10-18T23:51:29Z

Realtime Design and Merge Conflicts

← Older revision		Revision as of 23:51, 18 October 2020
Line 19:		Line 19:
	In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.		In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.

	Because of this, every build is a fork.		Because of this, [[Every Hardware Build is a Fork]]

			Every builder must be respected. Their fork is useful as long as they document their work for others to learn from.

			That every hardware build is a fork - is another way to consider that [[There is No Uniform Compiler in Hardware]] - by software analogy.

	=For Advanced Developers: Merge Reconciliation=		=For Advanced Developers: Merge Reconciliation=

Marcin: /* Realtime Design and Merge Conflicts */

2020-10-18T23:49:16Z

Realtime Design and Merge Conflicts

← Older revision		Revision as of 23:49, 18 October 2020
Line 18:		Line 18:

	In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.		In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.

			Because of this, every build is a fork.

	=For Advanced Developers: Merge Reconciliation=		=For Advanced Developers: Merge Reconciliation=

Marcin: /* Realtime Design and Merge Conflicts */

2020-10-18T23:47:31Z

Realtime Design and Merge Conflicts

← Older revision		Revision as of 23:47, 18 October 2020
Line 14:		Line 14:
	=Realtime Design and Merge Conflicts=		=Realtime Design and Merge Conflicts=
	Asynchronous design - people not working in realtime - is limited in its coordination aspect: people are not talking to one another. One advantage of realtime collaboration is that - by its nature - allows for higher coordination because people can talk to one another.		Asynchronous design - people not working in realtime - is limited in its coordination aspect: people are not talking to one another. One advantage of realtime collaboration is that - by its nature - allows for higher coordination because people can talk to one another.

			But version controls is still needed. And with people not working in realtime - merge conflicts are a definite issue to resolve. Whose version is accepted as the main branch?

			In hardware, ultimately the builder is the arbiter. That is because the person who builds becomes the strongest stakeholder: they invest in materials, which cost money - in addition to their time, elbow grease, and risks of bodily injury or even death.

	=For Advanced Developers: Merge Reconciliation=		=For Advanced Developers: Merge Reconciliation=

Marcin at 23:44, 18 October 2020

2020-10-18T23:44:48Z

← Older revision		Revision as of 23:44, 18 October 2020
Line 10:		Line 10:
	Currently, OSE uses [[Google Slides]] for collaborative design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. This works by collaborators downloading and uploading new versions, which are not treated as merges until a later point.		Currently, OSE uses [[Google Slides]] for collaborative design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. This works by collaborators downloading and uploading new versions, which are not treated as merges until a later point.

	In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of ~~202o~~ - but this is something that could be done relatively easily with a script.		In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 2020 - but this is something that could be done relatively easily with a script.

			=Realtime Design and Merge Conflicts=
			Asynchronous design - people not working in realtime - is limited in its coordination aspect: people are not talking to one another. One advantage of realtime collaboration is that - by its nature - allows for higher coordination because people can talk to one another.

	=For Advanced Developers: Merge Reconciliation=		=For Advanced Developers: Merge Reconciliation=

Marcin at 23:39, 18 October 2020

2020-10-18T23:39:46Z

← Older revision		Revision as of 23:39, 18 October 2020
Line 1:		Line 1:
			=Intro=
	Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.		Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.

Line 11:		Line 12:
	In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 202o - but this is something that could be done relatively easily with a script.		In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 202o - but this is something that could be done relatively easily with a script.

	==For Advanced Developers: Merge Reconciliation==		=For Advanced Developers: Merge Reconciliation=

	The reconciliated of merges in CAD follows [[Test-Driven Design]] and the [[Second Toyota Paradox]]. Parts are not merged officially until they are tested, which requires extensive prototyping. Full testing may not occur until long after a design is made. But this does not mean that design must stop until further testing - as this would waste potentially valuable contributions of developers.		The reconciliated of merges in CAD follows [[Test-Driven Design]] and the [[Second Toyota Paradox]]. Parts are not merged officially until they are tested, which requires extensive prototyping. Full testing may not occur until long after a design is made. But this does not mean that design must stop until further testing - as this would waste potentially valuable contributions of developers.

Marcin: /* For Advanced Developers: Merge Reconciliation */

2020-10-18T23:38:06Z

For Advanced Developers: Merge Reconciliation

← Older revision		Revision as of 23:38, 18 October 2020
Line 19:		Line 19:
	OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The product manager for a given product will make 'pull offers' rather than contributors making 'pull requests'. The distinction is that the 'pull offer' requires active intervention.		OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The product manager for a given product will make 'pull offers' rather than contributors making 'pull requests'. The distinction is that the 'pull offer' requires active intervention.

	In hardware, however - there may be multiple branches in concurrent development. In fact, that is the only way it can be, as ~~any build~~ is ~~treated as~~ a ~~fork~~.		In hardware, however - there may be multiple branches in concurrent development. In fact, that is the only way it can be, as [[Every Hardware Build is a Fork]].

	=Links=		=Links=
	*[[Remote Extreme Build Documentation]]		*[[Remote Extreme Build Documentation]]

Marcin: /* For Advanced Developers: Merge Reconciliation */

2020-10-18T23:37:00Z

For Advanced Developers: Merge Reconciliation

← Older revision		Revision as of 23:37, 18 October 2020
Line 17:		Line 17:
	In order to not lock down any design - and thereby allow for parallel contributions - official merges are performed as late in the process as possible. This is due to the effort and expense of 'unit testing' in hardware, where testing cannot be done uniformly or immediately like it can be done in software.		In order to not lock down any design - and thereby allow for parallel contributions - official merges are performed as late in the process as possible. This is due to the effort and expense of 'unit testing' in hardware, where testing cannot be done uniformly or immediately like it can be done in software.

	OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The ~~Mater Branch~~ is a fork ~~of the main branch~~.		OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The product manager for a given product will make 'pull offers' rather than contributors making 'pull requests'. The distinction is that the 'pull offer' requires active intervention.

			In hardware, however - there may be multiple branches in concurrent development. In fact, that is the only way it can be, as any build is treated as a fork.

	=Links=		=Links=
	*[[Remote Extreme Build Documentation]]		*[[Remote Extreme Build Documentation]]

Marcin at 23:32, 18 October 2020

2020-10-18T23:32:20Z

← Older revision		Revision as of 23:32, 18 October 2020
Line 7:		Line 7:
	''Collaborative'' means many people doing this together, and with ''realtime'' - at the same time.		''Collaborative'' means many people doing this together, and with ''realtime'' - at the same time.

	Currently, OSE uses [[Google Slides]] for collaborative design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. ~~In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a~~ new ~~file being loaded. With basic python programming~~, ~~this process can be automated such that the CAD models change in realtime. OSE has~~ not ~~implemented this explicit realtime updating of CAD documents~~ as ~~of 202o - but this is something that could be done relatively easily with~~ a ~~script~~.		Currently, OSE uses [[Google Slides]] for collaborative design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. This works by collaborators downloading and uploading new versions, which are not treated as merges until a later point.

			In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 202o - but this is something that could be done relatively easily with a script.

			==For Advanced Developers: Merge Reconciliation==

			The reconciliated of merges in CAD follows [[Test-Driven Design]] and the [[Second Toyota Paradox]]. Parts are not merged officially until they are tested, which requires extensive prototyping. Full testing may not occur until long after a design is made. But this does not mean that design must stop until further testing - as this would waste potentially valuable contributions of developers.

			In order to not lock down any design - and thereby allow for parallel contributions - official merges are performed as late in the process as possible. This is due to the effort and expense of 'unit testing' in hardware, where testing cannot be done uniformly or immediately like it can be done in software.

			OSE's process is to keep forks on individual contributors' work logs, or update the main branch. The Mater Branch is a fork of the main branch.
	=Links=		=Links=
	*[[Remote Extreme Build Documentation]]		*[[Remote Extreme Build Documentation]]

Marcin at 23:14, 18 October 2020

2020-10-18T23:14:40Z

← Older revision		Revision as of 23:14, 18 October 2020
Line 1:		Line 1:
	Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.		Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.

	Currently, OSE uses [[Google Slides]] for design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time.		''Cloud'' refers to the documents being on-line - accessible by anyone anywhere in the world.

			''Realtime'' means that many people can edit at the same time, and see others' changes at the same time as they are made.

			''Collaborative'' means many people doing this together, and with ''realtime'' - at the same time.

			Currently, OSE uses [[Google Slides]] for collaborative design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time. In the CAD workflow using FreeCAD - realtime changes are not seen - but they are seen only upon a new file being loaded. With basic python programming, this process can be automated such that the CAD models change in realtime. OSE has not implemented this explicit realtime updating of CAD documents as of 202o - but this is something that could be done relatively easily with a script.

	=Links=		=Links=
	*[[Remote Extreme Build Documentation]]		*[[Remote Extreme Build Documentation]]

Marcin at 23:10, 18 October 2020

2020-10-18T23:10:49Z

← Older revision		Revision as of 23:10, 18 October 2020
Line 1:		Line 1:
	Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.		Realtime cloud collaborative editing - is the editing of documents and creation of digital assets - done over the internet - where a large group of people can edit the same document or asset at the same time.

	Currently, OSE uses [[Google ~~Docs~~]] for design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time.		Currently, OSE uses [[Google Slides]] for design and build documentation. OSE also uses [[Part Libraries]] for realtime CAD development where many people work on individual modules which can then be assembled into a larger design (assembly) - all at the same time.

	=Links=		=Links=
	*[[Remote Extreme Build Documentation]]		*[[Remote Extreme Build Documentation]]