OSE Development Guidelines

1. Understand first that our work is open source, OSHWA and OSI compliant. We develop both open source hardware blueprints, and open source enterprise blueprints that we believe are the foundation for an open source, collaborative economy. We believe that collaborative design for a tranparent and inclusive economy of abundance (see Vision) is not an ideal - but rather a prerequisite to a democratic society.
2. Publish early and often - leave a paper trail of all that you do so future generations of developers can build upon it - in the short term and in the long term. Document on your Work Log
3. Understand that anything that you do - you are not working on it alone. This means that you are building on past work. This means that others will build upon it if it is docucemented. That means even if it looks like you are working on something alone - you really aren't if you document it - so remember to document everything, and behave like you are working as part of a group. We are building a group of thousands of developers who are intended to collaborate actively on large-scale projects.
4. The wiki is our mass collaboration platform. The wiki accepts html embeds of any content whatsoever, including multimedia and manipulable 3D graphics.
5. Understand that anything that you work on in the framework of the GVCS is important and should be documented. If you think that something that you are doing is not sufficiently important to be documented - then you should probably not be doing it in the first place because it is not important. Summary: when working with OSE - work on important work.
6. Find out who the points of contact are for each project.
7. Coordinate people on a project using a Kanban board embedded on a given project development page.
8. Communicate actively with the points of contact when prototyping as things can change rapidly, and you may be using outdated information.
9. Know how to track progress on any given project: see the Development Template and Development Page for that project.
10. When getting involved, it is useful to ask existng developers regarding your xyz topic: "Where is existing information about xyz topic published?" Then, it is a good practice to document further information on that page - or if existing knowledge is not published or is incorrect, that information should be documented or corrected.

• Do not be surprised if you find this response to your information request: "All information on that topic is found at the xyz page on the wiki. If your question is not answered, please start an FAQ on that page asking your question, and a mber of our team will respond to that publically on that wiki page."

Integrated Framework

• See Collaboration Architecture.