Criteria for a Successful, Collaborative OSE Project

When engaging in a development project with OSE, keep in mind these points when doing your development, design, and build work:

Open Process

1. Are you documenting? The key to open source work is building upon others' documentation. If your work is not documented openly in the cloud at a public site - it effectively does not exist from the standpoint of zero-barrier, global collaboration. Is your work on your Work Log? The Work Log on the wiki is OSE's most basic documentation venue for documenting one's work - such that other team members know where to find others' contributions over time - to promote collaboration. Wherever your work is located - have you communicated to the rest of the OSE community where your work can be found?
2. Working open source style. Are you publishing early and often (good)? Are you publishing 'as soon as you have a milestone reached' (not good). The key to working openly is that you disclose all of your work publicly as soon as it is generated - meaning that you work in the cloud - and allow others to help you make the road by walking. This allows for feedback and collaboration to happen immediately. When you publish a Google Doc, are you remembering to Share it immediately for anyone to view and comment? Are you opening Google Docs for edit to the world (good if you keep backups)? Does your work merit creating infographics via our Media Manager's assistance?
3. Past Work. Are you aware that past work has already been done on the topic? What measures have you taken to find, study, and build upon that work? Have you updated the documentation of the past work, and communicated how you are building upon it or moving beyond it?
4. Team Effort. How are you working with the rest of the OSE community?
5. Leadership. Have you thought about communicating to OSE leadership about your work? Who are the key OSE developers relevant to your work?
6. Organizing your documentation. After you began documenting your work openly, are you taking any measures to organize it on OSE's platforms so that it can be easier to find and build upon?
7. Feedback. What mechanism have you established for receiving feedback on your work? Have you considered an update on your status on the OSE Facebook page? Is your work newsworthy for OSE to write a press release?
8. Cost - have you considered the cost of a project, and do you have a rough estimate of materials, supplies, overhead, and labor costs?
9. Design for Fabrication - have you considered how the project can be built in the simplest way? Have you consulted with others who have more experience than you in builds to solicit feedback?

Technical

1. Product Ecology. - What measures are you taking to makes sure that your work fits within the GVCS Product Ecology? Are you familiar with the GVCS Product Ecology?
2. Construction Set - Are you designing your machine or component to function as a piece of a construction set, not as a part of a dedicated machine? What specific features allow your design to be a Construction Set? What features are missing that limit its features as a Construction Set?
3. Parts Library - are you contributing to the OSE parts library? Is your design robust and general enough to merit entry into the OSE parts library? Are you aware of the criteria that allow your design to enter the OSE parts library?
4. Test-Driven Design - Just like documentation should be published early and often - are you publishing your builds early and often? This means - are you doing quick prototypes for testing along the way that allow you to test various features of the complete design? Are you doing scale models, simulations, or CAD to help verify your work?
5. Modular Design - how are you building on existing OSE modules? Do you know which modules are currently accepted as generally sound in OSE's work?

Leadership and Organizational

1. Roadmap - do you have a roadmap and budget for where you are going? Is that road map consistent with OSE's roadmap?
2. Project Ownership - Are you clear about who is responsible for completing a project? Do you know that your responsibility as project owner is to collaborate with others and not make unilateral decisions? Do you know what your allowed budget is? Do you know who has the ultimate veto power if there is controversy?
3. Project Completion - When you start a project or get involved in something, do you know the definition of done? Are you clear about who the project owner is? If your work is part of a larger project, do you know who will follow up after you? Is there a transition plan? If you are blocked, are you continuing to pursue the project, or dropping it so it is not completed? Is there clarity on the timing within which a project should be completed?

Safety

1. Tool Authorization - have you been trained and authorized to use the tools required to do a build/make something happen? Is that validation documented?