Vancouver Hack Space

This is an old revision of the document!

“I” is actions from or for Jon G. “We” refers to the participants in the build workshop. “VHS should” are my recommendations for what the membership of the space can do to help and improve future workshops.

Final Numbers: (including the prototype):

21 kits
18 advance signups, 1 late signup, 1 prototype, 1 kit held as spares (and dipped into)
2 build days, running about 6-7 hours, Jan 5th and 18th, 2014
signup ran for two weeks.
3 people built their kits outside of the workshops
Builds were successful, workshop feedback was positive.

Cost was originally CAD$250, but I ended up requesting an additional CAD$25/kit to cover larger than anticipated shipping and currency conversion costs ~everyone did cover this.

We had only one significant component failure - one of the radios had serious hardware issues and had to be replaced. This was done out of the extra kit, and I hope to be able to repair the final radio.

Instructions posted to http://learn.marginallyclever.com , as I didn’t have vhs wiki access when I wrote them. They’ve been mirrored to the vhs wiki (here), but I still need to upload pictures. VHS should encourage using the wiki for workshop instructions when possible - it made it easy to update and correct errors.

Participation was a mix of members and non members - it’s my understanding that VHS did pick up several members through the workshops, and exposed more people to the space.

There was sufficient interest after signups closed and as the workshop run- I expect to run another workshop round in the next six months.

Commentary and Thoughts

We took signups by having people paypall us the money. this worked reasonably well, having an in person signup & payment method (ex: Square) may have helped. I don’t feel that skipping eventbrite was a mistake, given the additional cost. We did not have a method to limit registration, as we had a great deal of flexibility for group size. Date choice was run as a doodle, with a second doodle with capped attendance used for attendees to select which they would attend, while capping numbers.
Providing updates via a running email thread to attendees worked, but it would have helped to have a form to collect non-paypal email addresses, and other contact info with the payment.
Having a full prototype kit gave us an opportunity to troubleshoot issues before the workshop. For the most part this wasn’t visible to the participants, but a few issues took several hours to debug before hand.
As a time guideline, what took us 1 hour to assemble once we had done it once took the workshop roughly 3 hours. Writing the documentation took around 6 hours (see below for recommendations - I'd suggest spending MORE time on documentation).
Running the workshops as “here’s the instructions, I’ll be wandering around to check and help, ask if you have any questions” worked well, as long as the instructions were reasonably well prepared.
‘voluntelling’ participants to help one another out with steps that they had completed was also effective.
Having experienced help around was invaluable for the bigger build day -
Progress speed during the workshop will likely vary wildly, especially for participants with kids along. Trying to encourage ‘buddying’ them up with a member you know to be technically adept will help keep progress in the same band.
Limiting attendance at a day to 10 ± 1 was a good level for a kit of this size, in the bunkers amount of space. Increased attendance would have required pushing people to the perimeter tables, and made it harder to keep track of.
Shipping times and parcel tracking drove my stress rates up, ultimately for no reason. A spreadsheet tracking what was in each shipment, what had arrived, and what was remaining was very helpful, and I didn't make any ordering errors.

Lessons learned and recommendations for future workshops:

Shipping costs were dramatically over estimates, blowing through the cost buffer, and requiring an after the fact price increase. Customs could have driven this higher.
- This is a tricky point - I intended to keep participant costs as low as possible, which did not leave a great deal of buffer amount. Some potential approaches would be to communicate that I would be over-collecting up front, and refunding the delta, or from the beginning communicating that I would take the approximate cost of the parts, and collect all shipping costs at workshop time. other idea: overcollect, use the extra for pizza or food to keep people energized during the build?

Instructions were not complete for first workshop, lacking configuration information
- This was due to difficulties with access to a prototype kit. If running a workshop with multiple organizers, need to arrange consistent access for preparing instructions. It would help for all the organizers to purchase prototypes, or if there’s a singular one for it to be stored at the space or other convenient location.

only one organizer understood the fine tuning of a critical step. This was a bottleneck in the process.
- Sometimes can't be avoided, but needs to be scheduled around.

Wood selection differed between prototype and kit frames, causing performance variation. This was only noticed after the kit frames where cut.
- Be detailed in specifying materials, and cautious in variation.

A design weak-point (legs too easily broken) became apparent only at the workshop.
- This was not discovered in testing, primarily due to differences in flying skill. Bringing in a beta tester of closer experience to the participants would have helped. there’s no such thing as too much testing. That said, there’s no way to catch every bug ahead of time.

Instructions were accompanied primarily by photos, and not all photos where sufficiently clear.
- Judicious use of diagrams, _especially for wiring_, would have been beneficial. A picture may be worth 1000 words, but a clear diagram can save a few hundred more in explanations.

Workshop material only presented what was needed to assemble and fly, leaving theoretical explanations fairly ad-hoc.
- This should have been prepared on a wiki page ahead of time, including links to other sources. I believe it was the correct course not to include it in the instructions, as it would have over complicated the build, but the material still should have been available.

The first workshop discovered issues with the instructions (not unexpected). The second workshop ran smoother for these discoveries. The first workshop was also double the size of the second.
- If the workshop is at a size to benefit from multiple days, and attendance size will differ, use participant limits to make the first day a smaller crowd. It’s not unexpected to run into into changes that need to be made to clarify the instructions, keep things easier by having a smaller group be the first to discover them.