Julia Longtin
Hacker and Libre
- Why Implicitcad - system programming -
Notes:
- Open Source Microfactory STEAM Camp - https://www.opensourceecology.org/steam-camp-january-2020/
- Microwave amplifier - https://www.digikey.com/products/en?keywords=BLC2425M10LS250
- Universal Axis
- Etherpad lite - https://etherpad.org/
- Summer of Extreme Design-Build - https://wiki.opensourceecology.org/wiki/Summer_of_Extreme_Design-Build_2020
(notes from luke: pyopenscad is a fork of SolidPython long before its name changed and it got totally rewritten)
Comments
Luke sez -
well this is fascinating. identifying that effectively because of our skillset we *disempower* others.
and that documentation is a key aspect of the inability to bridge the gap.
in the libre projects i manage, marcin, i spend considerable time in any given group doing, hilariously, what you have been doing: pointing people at the wiki, or bugtracker, or etc etc.
i do not know which page this should go on, please do advise.
there will be people who neeeed to do management like that. poke people to update docs.
julia regarding "you end up winning all the time" one possible way to solve that for the drill is to have clear "phases", where the first phase is simply "everyone do some design concepts" (hand drawn images, whatever) and drop them online.
actually, phase zero is people decide if they want act effectively as a "team" throughout or if they are happy to split up.
second phase, identify similar designs and get people to group together based on similarity.
here the wiki can be used, you "tag" a page and use "include". by asking people to put their name into the subpage name, there will be no wiki editor clashes. the "include" system will collate everybody's images and they can all be seen.
weird ideas like mine with the combined LRK TorqueMax Axial Motor which will be a "T" design with a spade style handle will stick out even visually at that early stage like a sore thumb.
from there once BOM and common practical details are done the next phase would be to analyse *those* parts and check commonality on *those*.
here you can check part Degeneracy.
- then* you move to actual part design, inviting people to join similar groups to do them.
at this phase what i would suggest is, use "pair programming" but by jitsi (make sure at least half team is in different locations), and have several people watch and help and switch over every 10 to 15 mins or so.
one of the team would idealy know FreeCAD already, if not they would call in onsite teacher.
once Degenerate parts done even basic first versions, some of the teams move to "integrating" those degenerate (common) parts, whilst others continue refining the (common) parts.
this will cause communication issues and that us very deliberate! you *want* people to talk to each other and subdividing the work by creating dependencies and critical paths and seeing how they react is exactly what you want them to experience!
finally we get to first prototypes, print them, assemble them, and try them out.
that's where it gets interesting because you have some successes, some mechanical failures, and so on.
that's when you introduce the concept of "iterative design". debugging " *why* did my drill fly apart under the torque load?"
some teams will just fall apart, some will be behind, some will have people leave, it will get chaotic and that is precisely what we want them to experience.
the one thing throughout all of this which i strongly suggest following is bob podolski's "octolog" pattern.
the key there is decisions must be UNANIMOUS, that group sizes should be between 7 and 8, and that they best work 50-50 men-women.
otherwise people get seriously discouraged (mob rule problem, minorities problem, dictator problem) and so on.
julia if you were helping as an advisor there i think you would be so busy that there would be no time to "dominate". people who are stuck *need* someone to come in, ask questions, and give new ideas and suggestions.
l.
