Marcin at 20:03, 13 April 2013

2013-04-13T20:03:11Z

← Older revision		Revision as of 20:03, 13 April 2013
Line 17:		Line 17:
	* Include planning for future work (after the event) as part of the process.		* Include planning for future work (after the event) as part of the process.

	* Distinguish between the actual source (design files) for hardware from documentation about open-source hardware practices and projects. The current site seems to use "documentation" for both, which gets confusing.		* '''Distinguish between the actual source (design files) for hardware from documentation about open-source hardware practices and projects. The current site seems to use "documentation" for both, which gets confusing.'''

	* Where possible, focus on best practices and examples rather than formal rules. For example, in trying to expand the scope of open-source hardware, I wouldn't try to write an explicit definition of what counts. Instead, give examples that show the diversity of what exists.		* Where possible, focus on best practices and examples rather than formal rules. For example, in trying to expand the scope of open-source hardware, I wouldn't try to write an explicit definition of what counts. Instead, give examples that show the diversity of what exists.

Marcin: Created page with "* The key technical challenge is making it easier to track, view, and merge changes to hardware designs. * Build on top of existing technology (e.g. git and github). * Encou..."

2013-04-13T19:36:00Z

Created page with "* The key technical challenge is making it easier to track, view, and merge changes to hardware designs. * Build on top of existing technology (e.g. git and github). * Encou..."

New page

* The key technical challenge is making it easier to track, view, and merge changes to hardware designs.

* Build on top of existing technology (e.g. git and github).

* Encourage text-based file formats. The XML file format in newer versions of Eagle is a good example; encouraging or creating text-based file formats for other software tools or types of hardware would be one good project to work on.

* Work on import / export between different tools (e.g. Eagle import / export in Kicad if there isn't one already).

* Use images (e.g. PNGs or PDFs) as a common format for viewing changes. GitHub, for example, provides good built-in tools for showing diffs between images (https://github.com/blog/817-behold-image-view-modes). Automatically generating some PNGs or PDFs on every commit of an Eagle file, for example, would make it much easier to see the changes.

* Collaborate with CERN on their open-hardware repository (http://www.ohwr.org). For example, OSHWA could help mediate in cases where it's not clear if something is open-source or not.

* Engage with other partners. For example, Hod Lipson is working on an effort to define a new interchange format for 3D designs (http://amf.wikispaces.com).

* Encourage participants to be clear about what they're trying to accomplish.

* Include planning for future work (after the event) as part of the process.

* Distinguish between the actual source (design files) for hardware from documentation about open-source hardware practices and projects. The current site seems to use "documentation" for both, which gets confusing.

* Where possible, focus on best practices and examples rather than formal rules. For example, in trying to expand the scope of open-source hardware, I wouldn't try to write an explicit definition of what counts. Instead, give examples that show the diversity of what exists.

* Embed taxonomies and standards in tools and platforms rather than trying to impose them externally. For example, it makes sense to have a taxonomy embedded in a repository of open-source hardware but it's not clear what value one would have on its own. Similarly for labels / fields: it makes sense to have a standard set of fields in a repository but I'm not sure it makes sense to suggest one that people would use on their own websites.

* Try not to get side-tracked by overly philosophical conversations (e.g. "what are the limits open-source hardware?", "how much of a project needs to be open?", etc).

David Mellis Suggestion - Revision history

Marcin at 20:03, 13 April 2013

Marcin: Created page with "* The key technical challenge is making it easier to track, view, and merge changes to hardware designs. * Build on top of existing technology (e.g. git and github). * Encou..."