Alex Vazhatharayil Discussion

From Open Source Ecology
Jump to: navigation, search


Workflows for hardware products. How to review your work, etc.

Alex J Vazhatharayil: - closed source software. Free hardware workflows for open source workflows.


1. Documentation is PRACTICALLY unavailable - even if it doesn't exist.

2. Modularization for reuse is the solution

3. Design choices, bug reports, testing data, customer feedback. Manufacturing constraints, design rationale. Production data.

4. It is difficult to pick up from before - because much information is lost in transition. On Makeystreet - that is Insights section. Ie, can I quickly dump data in so we do this. That is put on GIT - they make a layer on top of GIT to make it practical.

5. Each file can be tagged with a manufacturing process. BOM + # multiples needed + files + quality control points. Fabrication Diagram-like function.

6. Amount of value provided by GIT is immense. So definitely use it. If you don't use git, you lose lots of data and do rework.

7. Insights is the critical way to track new versions. Submodules can iterate quickly. V3 of machine can have v10 of a version.

8. Every new build is a Fork. Pull request means that if you modify a file - sends a pull request to the original source manager - please take my code and include in your repo bc we think it adds value to your repo. If request is denied, it lives as a separate fork.

9. Nobody cares about what you built, just

  1. Solve assembly problem first. Solve main workflow to allow people to build upon others's - that means simple, granular, modules - so you can pick out pieces relevant to you.
  2. Then solve taxonomy.

Approach: define problem, and work together on a solution.