Talk:The Case for Using Wiki Version History - Revision history

Pizzooid: /* Continued Argumentation */

2021-02-17T20:42:51Z

Continued Argumentation

← Older revision		Revision as of 20:42, 17 February 2021
Line 29:		Line 29:
	#'''Versions have a hash Key''' - wiki has the equivalent functionality of a hash key.		#'''Versions have a hash Key''' - wiki has the equivalent functionality of a hash key.
	## I don't think that this is true. The problem with the wiki is that the latest version does not really have a hash, older versions can be linked to, but the newest version always has the same link, there is no permanent link. Or is there a way to address the current link for the future?		## I don't think that this is true. The problem with the wiki is that the latest version does not really have a hash, older versions can be linked to, but the newest version always has the same link, there is no permanent link. Or is there a way to address the current link for the future?
			### Ok, so the hash-key functionality is actually the permalink functionality, sadly it only links to the Wikipage of the file but not to the file itself.

	=Discussion=		=Discussion=

Pizzooid at 21:33, 13 February 2021

2021-02-13T21:33:19Z

← Older revision		Revision as of 21:33, 13 February 2021
Line 25:		Line 25:
	#'''Access control''' - The [[GVCS]] (creating a new infrastructure for civilization) is a broader project, therefor we allow everybody in without the need for a access control. The only question is spam, which we address by manual approval of new users.		#'''Access control''' - The [[GVCS]] (creating a new infrastructure for civilization) is a broader project, therefor we allow everybody in without the need for a access control. The only question is spam, which we address by manual approval of new users.
	#'''Accidental Overwrites'''- I'm not aware that this is an issue. If there is a submission conflict, that is clear to the submitter - their upload fails, and they upload a file again. If 100 people do this, they just try again and the upload should be reconciled in seconds. But there is never typically a large number of people working on a single file, as we normally coordinate so that if there are multiple people working, we work on different files, or break the file into smaller parts for multiple people to work on them. Further, we also encourage people to use their work log as a repo, and add to the main trunk at a later date. Accidental overwrite can be an issue for page edits - but not for file uploads. For page edits, we use embedded documents, which are crowd-collaborative-realtime-editable and never suffer from 'submit' conflicts.		#'''Accidental Overwrites'''- I'm not aware that this is an issue. If there is a submission conflict, that is clear to the submitter - their upload fails, and they upload a file again. If 100 people do this, they just try again and the upload should be reconciled in seconds. But there is never typically a large number of people working on a single file, as we normally coordinate so that if there are multiple people working, we work on different files, or break the file into smaller parts for multiple people to work on them. Further, we also encourage people to use their work log as a repo, and add to the main trunk at a later date. Accidental overwrite can be an issue for page edits - but not for file uploads. For page edits, we use embedded documents, which are crowd-collaborative-realtime-editable and never suffer from 'submit' conflicts.

			==Continued Argumentation==
			#'''Versions have a hash Key''' - wiki has the equivalent functionality of a hash key.
			## I don't think that this is true. The problem with the wiki is that the latest version does not really have a hash, older versions can be linked to, but the newest version always has the same link, there is no permanent link. Or is there a way to address the current link for the future?

	=Discussion=		=Discussion=

Marcin: /* Major Advantages */

2021-02-09T23:35:44Z

Major Advantages

← Older revision		Revision as of 23:35, 9 February 2021
Line 16:		Line 16:

	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

			==Counterarguments on Major Advantages==

	#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.

Marcin: /* Counterarguments on Major Advantages */

2021-02-09T23:35:35Z

Counterarguments on Major Advantages

← Older revision		Revision as of 23:35, 9 February 2021
Line 23:		Line 23:
	#'''Access control''' - The [[GVCS]] (creating a new infrastructure for civilization) is a broader project, therefor we allow everybody in without the need for a access control. The only question is spam, which we address by manual approval of new users.		#'''Access control''' - The [[GVCS]] (creating a new infrastructure for civilization) is a broader project, therefor we allow everybody in without the need for a access control. The only question is spam, which we address by manual approval of new users.
	#'''Accidental Overwrites'''- I'm not aware that this is an issue. If there is a submission conflict, that is clear to the submitter - their upload fails, and they upload a file again. If 100 people do this, they just try again and the upload should be reconciled in seconds. But there is never typically a large number of people working on a single file, as we normally coordinate so that if there are multiple people working, we work on different files, or break the file into smaller parts for multiple people to work on them. Further, we also encourage people to use their work log as a repo, and add to the main trunk at a later date. Accidental overwrite can be an issue for page edits - but not for file uploads. For page edits, we use embedded documents, which are crowd-collaborative-realtime-editable and never suffer from 'submit' conflicts.		#'''Accidental Overwrites'''- I'm not aware that this is an issue. If there is a submission conflict, that is clear to the submitter - their upload fails, and they upload a file again. If 100 people do this, they just try again and the upload should be reconciled in seconds. But there is never typically a large number of people working on a single file, as we normally coordinate so that if there are multiple people working, we work on different files, or break the file into smaller parts for multiple people to work on them. Further, we also encourage people to use their work log as a repo, and add to the main trunk at a later date. Accidental overwrite can be an issue for page edits - but not for file uploads. For page edits, we use embedded documents, which are crowd-collaborative-realtime-editable and never suffer from 'submit' conflicts.

	~~==Counterarguments on Major Advantages==~~
	*

	=Discussion=		=Discussion=

Marcin: /* Major Advantages */

2021-02-09T23:35:14Z

Major Advantages

← Older revision		Revision as of 23:35, 9 February 2021
Line 18:		Line 18:

	#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.

	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.
	#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.		#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.

Marcin: /* Major Advantages */

2021-02-09T23:35:07Z

Major Advantages

← Older revision		Revision as of 23:35, 9 February 2021
Line 17:		Line 17:
	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

	#''Support - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.

	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.
	#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.		#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.

Marcin: /* Major Advantages */

2021-02-09T23:34:52Z

Major Advantages

← Older revision		Revision as of 23:34, 9 February 2021
Line 17:		Line 17:
	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

	#''Support~~'''~~ - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#''Support - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.
	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.
	#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.		#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.

Marcin: /* Major Advantages */

2021-02-09T23:34:42Z

Major Advantages

← Older revision		Revision as of 23:34, 9 February 2021
Line 17:		Line 17:
	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

	# '''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.
	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.
	#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.		#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.

Marcin: /* Major Advantages */

2021-02-09T23:34:33Z

Major Advantages

← Older revision		Revision as of 23:34, 9 February 2021
Line 17:		Line 17:
	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

	#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		# '''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.
	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.
	#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.		#'''Data Replication''' - The same is effectively true for the wiki, because every collaborator has a copy of the files they are working on. I would argue that Data Replication is not possible for hardware - as for hardware, the whole project is terabytes (from videos and heavy assets such as large CAD assemblies). This is why a wiki-centric infrastructure is good. So this points to defining the problem statement clearly: Git is good for software, not for hardware. The initial qeustion is: why use wiki version history? The second question that we are asking, why use wiki for project management as opposed to git. Having specified the question, we can answer: we use wiki for overall development, we use git for software only, as a general best practice.

Marcin: /* Major Advantages */

2021-02-09T23:34:10Z

Major Advantages

← Older revision		Revision as of 23:34, 9 February 2021
Line 16:		Line 16:

	'''Is any one of the reasons important enough?'''		'''Is any one of the reasons important enough?'''

	#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.		#'''Support''' - Wikipedia has a version control system, so in that sense it ''supports'' file versioning. Our requirement is ''keep all files from all contributors easily accessible, time stamped, and downloadable at any time without risk of data loss and without merge conflicts - while requiring only widely-accessible skill levels for team coordination.''' I think mediawiki does a better job at this problem statement, because you can see all the people working on the issue readily in the history. Further, our use of [[Visual Version History]] and CAD Part Libraries allows for quick visual diffs, where ready visual diffs would be much more difficult as they would be sread throughout many developers' accounts until they are committed to master. Navigating version histories is readily accessible to novices, whereas Github is pretty much for power users.
	#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.		#'''Robustness''' - Counterargument: yes, robustness in software, but it is not robust for open hardware development. For example, it can't handle video. So in terms of robustness, Git is less robust for handling a more complex process of hardware dev, for an integrated process like OSE uses. But certainly it's more robust for software, and we should use Git for software.