Critical Collaborative Literacy - Revision history

Marcin: /* Critical Missing Links */

2021-10-21T13:47:23Z

Critical Missing Links

← Older revision		Revision as of 13:47, 21 October 2021
Line 22:		Line 22:
	*Understanding that the end goal of development is products. Products mean things beyond one's use, but with potential for meeting needs of many. This means revenue models, enterprises, and [[Distributive Enterprise]]		*Understanding that the end goal of development is products. Products mean things beyond one's use, but with potential for meeting needs of many. This means revenue models, enterprises, and [[Distributive Enterprise]]
	*Understanding of the concept of Distributive Enterprise and [[Distributed Market Substitution]]		*Understanding of the concept of Distributive Enterprise and [[Distributed Market Substitution]]
			*Understanding of the essential difference between vision and execution

Marcin: /* Critical Missing Links */

2021-10-21T13:41:00Z

Critical Missing Links

← Older revision		Revision as of 13:41, 21 October 2021
Line 16:		Line 16:

	=Critical Missing Links=		=Critical Missing Links=
			Things observed to be most troublesome for progressive peaople:
	*Profound understanding of [[Time Binding]] and one's capacity to engage in it		*Profound understanding of [[Time Binding]] and one's capacity to engage in it
	*Profound understanding of [[Economic Time Binding]] and one's capacity to engage in it		*Profound understanding of [[Economic Time Binding]] and one's capacity to engage in it
	*Possibility and opportunity to engage in collaborative development with clear economic results - through the rigor and difficulty that this process requires		*Possibility and opportunity to engage in collaborative development with clear economic results - through the rigor and difficulty that this process requires
			*Understanding that the end goal of development is products. Products mean things beyond one's use, but with potential for meeting needs of many. This means revenue models, enterprises, and [[Distributive Enterprise]]
			*Understanding of the concept of Distributive Enterprise and [[Distributed Market Substitution]]

Marcin: /* Critical Collaborative Literacy - Documentation and Dev Process */

2021-10-20T21:29:03Z

Critical Collaborative Literacy - Documentation and Dev Process

← Older revision		Revision as of 21:29, 20 October 2021
Line 14:		Line 14:
	=Critical Collaborative Literacy - Documentation and Dev Process=		=Critical Collaborative Literacy - Documentation and Dev Process=
	*See https://docs.google.com/presentation/d/1ZGXIOepjc6ap4YjvE6w6-sPQ34CcbYX_qG9zjYIs--c/edit#slide=id.gb328b2d63d_0_9		*See https://docs.google.com/presentation/d/1ZGXIOepjc6ap4YjvE6w6-sPQ34CcbYX_qG9zjYIs--c/edit#slide=id.gb328b2d63d_0_9

			=Critical Missing Links=
			*Profound understanding of [[Time Binding]] and one's capacity to engage in it
			*Profound understanding of [[Economic Time Binding]] and one's capacity to engage in it
			*Possibility and opportunity to engage in collaborative development with clear economic results - through the rigor and difficulty that this process requires

Marcin at 17:52, 11 October 2021

2021-10-11T17:52:41Z

← Older revision		Revision as of 17:52, 11 October 2021
Line 11:		Line 11:
	#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.		#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.
	#'''Log your work.''' At OSE, we use [[Work Log]]s with hyperlinks to work product. Do this and everyone else will be able to find any current work - either by going to known logs and going to [[Recent Wiki Changes]]		#'''Log your work.''' At OSE, we use [[Work Log]]s with hyperlinks to work product. Do this and everyone else will be able to find any current work - either by going to known logs and going to [[Recent Wiki Changes]]

			=Critical Collaborative Literacy - Documentation and Dev Process=
			*See https://docs.google.com/presentation/d/1ZGXIOepjc6ap4YjvE6w6-sPQ34CcbYX_qG9zjYIs--c/edit#slide=id.gb328b2d63d_0_9

Marcin at 19:07, 8 August 2021

2021-08-08T19:07:41Z

← Older revision		Revision as of 19:07, 8 August 2021
Line 10:		Line 10:
	#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.		#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.
	#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.		#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.
			#'''Log your work.''' At OSE, we use [[Work Log]]s with hyperlinks to work product. Do this and everyone else will be able to find any current work - either by going to known logs and going to [[Recent Wiki Changes]]

Marcin at 19:06, 8 August 2021

2021-08-08T19:06:35Z

← Older revision		Revision as of 19:06, 8 August 2021
Line 9:		Line 9:
	#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.		#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.
	#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.		#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.
			#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.

Marcin at 19:04, 8 August 2021

2021-08-08T19:04:14Z

← Older revision		Revision as of 19:04, 8 August 2021
Line 8:		Line 8:

	#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.		#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.
	#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source,		#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.

Marcin at 19:03, 8 August 2021

2021-08-08T19:03:25Z

← Older revision		Revision as of 19:03, 8 August 2021
Line 7:		Line 7:
	The principles are:		The principles are:

	#Use modularity of documentation. That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. W		#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.
			#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source,

Marcin at 19:00, 8 August 2021

2021-08-08T19:00:53Z

← Older revision		Revision as of 19:00, 8 August 2021
Line 4:		Line 4:

	The principles are simple and basic, but they require coordination according to principles that solo and proprietary work do not follow. Thus, this is a significant cultural barrier to 99% of the population.		The principles are simple and basic, but they require coordination according to principles that solo and proprietary work do not follow. Thus, this is a significant cultural barrier to 99% of the population.

			The principles are:

			#Use modularity of documentation. That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. W

Marcin: Created page with "These are principles of how to collaborate as large, open teams. This is a critical set of principles that enable a transition to the open source economy - an economy that opt..."

2021-08-08T18:59:39Z

Created page with "These are principles of how to collaborate as large, open teams. This is a critical set of principles that enable a transition to the open source economy - an economy that opt..."

New page

These are principles of how to collaborate as large, open teams. This is a critical set of principles that enable a transition to the open source economy - an economy that optimizes for both production - and distribution. This is consistent with [[Distributive Enterprise]].

What are open teams? Those are any teams that work on [[Open Source Product Development]] based on associated best practices of collaboration.

The principles are simple and basic, but they require coordination according to principles that solo and proprietary work do not follow. Thus, this is a significant cultural barrier to 99% of the population.