OSE/Networked Commons Foundation - Revision history

Elifarley: Added intra-links to SKDB, CAD tools and Mercurial

2010-10-15T02:19:39Z

Added intra-links to SKDB, CAD tools and Mercurial

← Older revision		Revision as of 02:19, 15 October 2010
Line 10:		Line 10:
	That we start out with a phased system:		That we start out with a phased system:

	#Phase one: ask everyone to document on OSE wiki, but also to store their files in ~~mercurial~~ repository. All files for your project would just go into one folder, and that folder would have a mercurial repo. We then help everyone upload those repos on to the internet, and help then learn how to commit to the repo. We ask everyone to follow your work template. So, a user could export the template page, and combine that with all of their work, then upload that as a repository. This would allow others to clone the whole repository, make changes, and push back specific changes, which can then be merged in etc Unfortunately, you cannot do all of that with a wiki engine, or else I would not even bother suggesting this		#Phase one: ask everyone to document on OSE wiki, but also to store their files in [[Mercurial]] repository. All files for your project would just go into one folder, and that folder would have a mercurial repo. We then help everyone upload those repos on to the internet, and help then learn how to commit to the repo. We ask everyone to follow your work template. So, a user could export the template page, and combine that with all of their work, then upload that as a repository. This would allow others to clone the whole repository, make changes, and push back specific changes, which can then be merged in etc Unfortunately, you cannot do all of that with a wiki engine, or else I would not even bother suggesting this
	#Phase two: we start applying ~~skdb~~ scripts to files. We also make an interface for skdb for mapping out projects into dimensions and yaml files. We also finalize the interface that lets people document steps in a sequence, and this can be part of the data in each project repo. This could apply to any technical design (with some work and adjustment, probably)		#Phase two: we start applying [[SKDB]] scripts to files. We also make an interface for skdb for mapping out projects into dimensions and yaml files. We also finalize the interface that lets people document steps in a sequence, and this can be part of the data in each project repo. This could apply to any technical design (with some work and adjustment, probably)
	#Phase three: we develop a way for people to share these repositories online without needing to be programmers, and we develop ways for people to add to them very easily. They still use mercurial repository on the back end, but have easy to use interfaces on the front end.		#Phase three: we develop a way for people to share these repositories online without needing to be programmers, and we develop ways for people to add to them very easily. They still use mercurial repository on the back end, but have easy to use interfaces on the front end.
	#Phase 4: we select candidate open source CAD and other tools, and modify those programs to output meta data about changes so that people can collaborate on files, and have access to whole revision history (right now most of these programs flatten the file and export as a binary, so this leaves out the history of changes) We then create an Ubuntu release that supports these, or work with fabuntu to incorporate these extended applications		#Phase 4: we select candidate open source [[CAD tools]] and other tools, and modify those programs to output meta data about changes so that people can collaborate on files, and have access to whole revision history (right now most of these programs flatten the file and export as a binary, so this leaves out the history of changes) We then create an Ubuntu release that supports these, or work with fabuntu to incorporate these extended applications


	Does all of that make sense?		Does all of that make sense?

	I think that the scope could extend to all of your projects, including ag/permaculture, not just hardware design. Just that for each project, we want to make data shareable in a way that is useful, and not locked up by any platform (like a Content Management System or Wiki engine). And, make data available in a way that people can merge changes. And, make data avaialble in a way (this is where skdb comes in) that allows people to pull down dependencies, or related info (will eventually require an interface to construct those dependencies).		I think that the scope could extend to all of your projects, including ag/[[permaculture]], not just hardware design. Just that for each project, we want to make data shareable in a way that is useful, and not locked up by any platform (like a Content Management System or Wiki engine). And, make data available in a way that people can merge changes. And, make data avaialble in a way (this is where skdb comes in) that allows people to pull down dependencies, or related info (will eventually require an interface to construct those dependencies).


	[[Category:Open Engineering]]		[[Category:Open Engineering]]

WikiSysop at 01:25, 10 February 2009

2009-02-10T01:25:36Z

← Older revision		Revision as of 01:25, 10 February 2009
Line 19:		Line 19:

	I think that the scope could extend to all of your projects, including ag/permaculture, not just hardware design. Just that for each project, we want to make data shareable in a way that is useful, and not locked up by any platform (like a Content Management System or Wiki engine). And, make data available in a way that people can merge changes. And, make data avaialble in a way (this is where skdb comes in) that allows people to pull down dependencies, or related info (will eventually require an interface to construct those dependencies).		I think that the scope could extend to all of your projects, including ag/permaculture, not just hardware design. Just that for each project, we want to make data shareable in a way that is useful, and not locked up by any platform (like a Content Management System or Wiki engine). And, make data available in a way that people can merge changes. And, make data avaialble in a way (this is where skdb comes in) that allows people to pull down dependencies, or related info (will eventually require an interface to construct those dependencies).


			[[Category:Open Engineering]]

WikiSysop: New page: =On the Development Work Template and design repository= There is a way to integrate the two. scope in my case is at this point just a pilot project with you to prove that this can w...

2009-02-10T01:24:59Z

New page: =On the Development Work Template and design repository= There is a way to integrate the two. scope in my case is at this point just a pilot project with you to prove that this can w...

New page

=On the [[Development Work Template]] and design repository=

There is a way to integrate the two.

scope in my case is at this point just a pilot project with you to prove that this can work. Then, we could work together to build this up as an OSE/Networked Commons foundation project (Networked Commons Foundation is the foundation that I have started to sustain this software development)

Basically, what I am saying is this:

That we start out with a phased system:

#Phase one: ask everyone to document on OSE wiki, but also to store their files in mercurial repository. All files for your project would just go into one folder, and that folder would have a mercurial repo. We then help everyone upload those repos on to the internet, and help then learn how to commit to the repo. We ask everyone to follow your work template. So, a user could export the template page, and combine that with all of their work, then upload that as a repository. This would allow others to clone the whole repository, make changes, and push back specific changes, which can then be merged in etc Unfortunately, you cannot do all of that with a wiki engine, or else I would not even bother suggesting this
#Phase two: we start applying skdb scripts to files. We also make an interface for skdb for mapping out projects into dimensions and yaml files. We also finalize the interface that lets people document steps in a sequence, and this can be part of the data in each project repo. This could apply to any technical design (with some work and adjustment, probably)
#Phase three: we develop a way for people to share these repositories online without needing to be programmers, and we develop ways for people to add to them very easily. They still use mercurial repository on the back end, but have easy to use interfaces on the front end.
#Phase 4: we select candidate open source CAD and other tools, and modify those programs to output meta data about changes so that people can collaborate on files, and have access to whole revision history (right now most of these programs flatten the file and export as a binary, so this leaves out the history of changes) We then create an Ubuntu release that supports these, or work with fabuntu to incorporate these extended applications

Does all of that make sense?

I think that the scope could extend to all of your projects, including ag/permaculture, not just hardware design. Just that for each project, we want to make data shareable in a way that is useful, and not locked up by any platform (like a Content Management System or Wiki engine). And, make data available in a way that people can merge changes. And, make data avaialble in a way (this is where skdb comes in) that allows people to pull down dependencies, or related info (will eventually require an interface to construct those dependencies).