Last week’s build session went well. Four students assembled computers and got all the way to the Ubuntu installation section, while the rest were close.

Written instructions and checklists made a big difference. Students worked through the instructions independently, leaving us free to focus on helping students with troubleshooting. The instructions also helped us provide more detail than we might remember to mention, and they forced fewer synchronization points (“Okay, everyone, look here at this thing”).

It also helped to have a prepared environment. All the tools were at hand, such as CPU paste and a battery tester. Most of the computers we worked on had been properly evaluated, although there were a few that had been missed. Still, it was generally an enjoyable and not frustrating experience.

I’ve revised the instructions to clarify some other points that were missing before. Onward and upward! =)

Here are some ways we can make this even better:

• Revise checklist and instructions. Cross-reference them with identifiers and instructions to update the checklist (“Check box #5 and write down the amount of RAM.”) This will make the checklist easier to work with.
• Revise checklist to make sure the boxes use a font that’s available on multiple platforms, and check into other formatting issues. Consider using graphical icons if checkbox Wingdings continue to be problematic.
• Consolidate validation and evaluation checklists for now, because information is duplicated and evaluators are not using the template. Alternatively, consider adopting the template for the evaluation process. Tweak evaluation form as necessary.
• Time install process so that we can give students an idea of when to start installation and when to postpone installation to the next day.
• Adopt a strategy of low-hanging fruit: focus on building easy-to-build boxes so that we can get those ones out the door first. Minimize troubleshooting, because problematic boxes pile up on the “in progress” shelves. Focus on increasing build velocity.
• Clear undated boxes from “in progress” shelves. Re-evaluate boxes. Recycle boxes below minimum requirements. Prepare boxes that require no obvious troubleshooting for future build classes. Strip boxes with problematic components (no troubleshooting motherboards or power supplies).
• Downgrading Unity 3D requirement because finding an acceptable video card can be time-consuming. Reinstate Unity 3D recommendation only after we have inventory of video cards that support Unity 3D.
• Trim inventory so that floorspace is clear, obsolete parts Work with monthly recycling so that obsolete components are clearly segregated and ready to go. Reorganize outgoing area so that skids can be easily filled and maneouvered out.
• Find other volunteers who can help facilitate build classes. Maybe renaming build classes to build sessions will make it less intimidating for volunteers. Requirements: awareness of where parts are at Free Geek Toronto, ability to look things up, light troubleshooting
• Speed up installation by setting up a local network proxy. Not essential, though. Timing will help us see if this makes enough of a difference.
• Clear enough build space so that people can work on a second box while waiting for the install.

Goals:

• Help students become comfortable enough with building computers that they drop by and build computers (possibly with other people’s help) even outside build classes. (Measurement: return visits, # of computers completed)
• Improve build velocity and throughput (Measurement: # of computers built and tested)
• Create an organized and welcoming enviroment: clear floor space so that people can walk around, well-organized parts, inventory levels matched to need and incoming/outgoing rates