search

OpenDesign-WorkingGroup / Open-Design-Definition

Open Design Definition
Other
42 stars 8 forks source link

Thinking about the life cycle- instructions given to fix the artifact in the future #10

Closed nickbrambiz closed 11 years ago

nickbrambiz commented 12 years ago

You should know how an object works, how's made, how you could repair it

bujatt commented 12 years ago

On the top of this, we should also think about (future) extensibility of a product.

openp2pdesign commented 12 years ago

These are all information that should be included in the source code of the Open Design project, so having the blueprint will probably be not enough... We should probably address this with some sort of recommendation in the Open Design Definition...

openp2pdesign commented 11 years ago

We could say that these information are either: a) part of the source code b) a kind of Open Data attached to Open Design (but separated from the source code)

Which option do you prefer? With the current version of the definition I'm exploring option b, but we could change this quickly

PedroPineda commented 11 years ago

Option b Leaving a nice and clean sourcode, but giving the possibility to others to dig deeper if the need to.

On 14 April 2013 21:38, Massimo Menichinelli notifications@github.comwrote:

We could say that these information are either: a) part of the source code b) a kind of Open Data attached to Open Design (but separated from the source code)

Which option do you prefer? With the current version of the definition I'm exploring option b, but we could change this quickly

— Reply to this email directly or view it on GitHubhttps://github.com/OpenDesign-WorkingGroup/Open-Design-Definition/issues/10#issuecomment-16357837 .

note: I am in spain till middle June. You can reach me on 0034 692283080 Pedro Pineda http://about.me/pedropinedaballester EXPERIENCES DESIGNER Consulting for the practical experience of theory and concepts. Contact Phone: 0049 (0) 15784749363 (germany) 0034 656678764 (spain) Skype: simple-mente Twitter: @ https://twitter.com/pedropibapedropibahttps://twitter.com/pedropiba In person: Co working at betahaus http://betahaus.de/ (barcelona)

work MakerLab: A Nomadic space to share knowledge and create impact; www.makerlab.info EnableBerlin: A a place where people meet to solve challenges together, www.enableberlin.org Open Design City (Betahaus): A co-working space to make things; www.opendesigncity.de We Creative People: A proactive platform and creative consultancy. Applying our collective power to the realization of projects and initiatives; www.wecreativepeople.org

me About me http://about.me/pedropinedaballester

eldelacajita commented 11 years ago

If we are talking about "knowing" the design so we can repair or improve it later, I think we are fine with a properly defined source code (a)

But if we are talking about maintenance or correct use during lifecycle, I think that would be a different type of documentation. More like a user's guide than like a blueprint, even if it still can contain specifications. So in that case I'd go for a separate attachment (b)

Or we can think of both as related things: A "maintainer's guide" could be a simplified "source code", where you basically have shortcuts to those specifications that matter during use, maintenance and repair.

alex-kovac commented 11 years ago

I think that this question is already answered and applied in Open source software development and the answer is much like Massimo's option b). ...with this addition: whether this supplemental information is attached or not is entirely optional.

openp2pdesign commented 11 years ago

It seems now that we are currently solving this problem by adopting a range or Open Design Spectrum that explains the possible levels of Open Design Documentation (see and join the discussion on Issue 7. The first version of this range was introduced with commit bd7bfc42add5cd78d405a332449da6c57e5d5d2f