- 1 Various Review Strategies
- 2 If you have suggestions, use our Review Form
- 3 Introduction and About
- 4 Past Workshops
- 5 OSE Review
- 6 Protocol for Formal Review
- 7 Scope of Review
- 8 Implementation
Various Review Strategies
- An obvious one is online forums. There are many subjects that forums and other online media, such as enterprise forums like Hacker News. A simple post may yield usable feedback. Such as plumbing design on a plumbing forum. Upvoting or discussion should then take place on the OSE Upvoting Site.
If you have suggestions, use our Review Form
This applies to technical review of machines, or organizational and process review.
Introduction and About
Kaizen in continuous quality improvement in a Learning Organization. One step to this is review. Review refers to any aspect of OSE's work. OSE's review process is open to the public, in that all review documents are published online. Review can also occur on other levels - such as organizational learning or development processes.
To enable technical review of product design in particular, we publish a Google Presentation that goes through conceptual design, CAD, or pictures of a machine - and requests feedback on certain specified items. Individuals can participate in a formal review meeting, or they can use the Review Form in an ad-hoc fashion below to submit comments and suggestions. Pull Requests can also be reviewed. Working Team members are usually given edit access to prepare review documents.
- Microhouse 3 (Faculty House) build - 7 out 11 positive reviews; 
Take the subject matter being reviewed and break it into components
- State what worked for each component
- State what needs improvement
- Take CAD images and mark them up
- If it's a product ready for production engineering work, state what production engineering points must be addressed
- Production engineering review - Draw up a production facility layout including workflow, materials logistics, supply chain delivery, tooling, quality control -
- Design Manufacturing Execution System for online order automation
Whether it's the build of a module, machine, house, or of a development process or enterprise concept - the formal review should take place in the form of a detailed point-by-point presentation with pictures, videos, and other supporting information. This should be a cloud editable document that can be marked up. Pictures should have arrows pointing to specific features. Small videos can be uploaded to discuss specific details via webcast. The second half of formal review is an audience:
Submission to the OSE Network using the Minds platform.
- Submission to OBI Advisors, OSE Advisors, and other Subject Matter Experts
- HR should engage in active recruiting of SMEs for review purposes
Protocol for Formal Review
(See discussion above)
- Before: Prepare a cloud editable Review Document.
- TOC should include main review questions
- Review Doc should have an Expository Page, a Summary of issues page - a summary of pre-suggesions
- Document is embedded in wiki and publicized on the Social Network.
- Call a meeting with 2 weeks advance notice to invite key stakeholders (builders themselves, SMEs, etc). Instruct reviewers on basics of Google Doc cloud editing so markup can occur right in the document, via comments, and via text box below slide
- During: questions and issues should be gone through point by point. The pre-suggestions are modified to make updated suggestions.
- After: Core team assesses all suggestions, and publishes a Review Results document, summarizing what worked, what didin't, and what decisions have been make for improving the next build. This document is then passed out to the community. Comments are requested on Minds.
Scope of Review
Review is desired within an open organization - on anything that can lead to organizational learning. The goals are:
- Providing general feedback
- Providing mid-course corrections as necessary
- Identifying key missing resources that prevent goals from being met
- Assessing proper allocation of resources and shifting resources around if necessary
Key Elements of a Review Submission
- Clear presentation of results - allow review to happen rapidly. Brevity and clarity are key, without which it is impossible to go through all of a person's materials.
- Verifiable - results are easily verifiable, increasing the likelihood that the feedback is useful
- Clarity - What is the mission of the company and what is its unique approach? How is that approach implemented? For OSE, it's the Developing an ethical, open source economy.
- Strategy - does the core work of the company adhere to its core mission?
- Coherence - is every piece of the company aligned with the core mission? What could be better?
- Resource allocation - are people matched to their skill set?
- Projects - are the projects priorities chosen in a way that helps the company grow, while considering constraints and opportinities?
- Learning - what mechanisms are built in so that the company is a learning organization?
Usually, OSE asks specific subject matter experts (SME) for feedback on specific design points. Formally, Review is an item in OSE's official Development Template.
- To engage in proper review, a Google Slides presentation should be created going through the build in a comprehensive manner. Use arrows to point to various things and to annotate build procedures. This could be fun when certain humane elements are pointed out in the build process.
- Each step should be graded for effectiveness, strong and weak points.
- Clear suggestions should be made for the next build
- The culmination of a proper review is deciding upon a specific list of changes committed for implementation in the next build. This document should be available for the subsequent development cycle, and should be made available to the general public for transparancy of the development process.
- For review, a more ambitious format than a slide presentation is taking existing pictures and videos, and doing a recorded video screencast going through all issues. Attention should be made to keep such a video tight, so dead spots should be edited out.
- Core contributors maintain a Work Log showing all results and progress.
- Staff maintains a Project Review framework consisting of a Critical Path Diagram and a spreadsheet of all supporting tasks
- Staff writes a monthly planning and review in their work log - 1. summary of accomplishments, 2. What worked. 3. What didn't. 4. Plan for next month.
- Staff meet with ED once a month for the Project Review