Volunteer notes: Free Geek Toronto

From Saturday: We’ve just come back from volunteering at Free Geek Toronto, where we’ve been helping people refurbish donated PCs. It’s a good idea: help people develop computer skills while reducing waste. Unusable components are separated and bundled for recycling.

Working with computer components as old as the ones they get there can be challenging. People need to identify and isolate problems, replace parts that don’t work, and set up Ubuntu Linux.

W- and I started volunteering there after J- did a short stint with them during her school’s community volunteering week. Free Geek Toronto needed a lot of help, so we wanted to see what we could do to get them to the next level. They hadn’t had build classes in a while, so we volunteered to lead Saturday sessions. We’ve also been working with other volunteers to document the process and make it easier for other people to pick up. My goals for this part are to write things down, go through a couple of iterations of build classes, and encourage at least one other person to lead build classes, so that we can then free up the time to work on other things.

The build sessions have been going well. It helps that we have a mix of experience levels. Today, one of the volunteers worked on a computer with chassis intrusion detection. A small switch detected when the cover was off and set a flag in CMOS, which caused the computer to halt while booting. He and another volunteer figured out how to reset the alarm and how to disable it. I’m learning a lot by osmosis, too, and will probably be writing more about hardware on this blog.

Future build classes might have more people who have little experience with computers. We need to make it easier for them to get started. Here are some things we and other people can work on:

  • Update the checklist so that it matches the new process.
  • Update the build process summary.
  • Write a fleshed-out version of the guide with step-by-step instructions and basic troubleshooting.
  • Go through all the video cards to confirm which ones support Unity, Ubuntu’s new interface.
  • Sort the IDE cables so that people can easily grab the one they need.
  • Clear out old equipment so that there’s less confusion and better equipment turnover.
  • Clarify the workflow/next steps: how volunteers can qualify for the course, where to put work in progress or finished materials, what’s the next step after the build class
  • Possibly split the installation from the building part, so that we can quickly get computers up and running using images.

The organization also needs to sort out waitlists and communication, but that involves interpersonal stuff and we’re not deep enough in the organization yet to be able to understand or nudge the dynamics. Sometime!

What could wild success look like?

Build classes run regularly. They have clear goals: each student will successfully assemble a computer, practising troubleshooting skills along the way. They’ve got a checklist, a short summary guide, and detailed step-by-step instructions, as well as a troubleshooting guide. There are a lot of parts, but some have been pre-tested. The class also helps students get to know other experienced volunteers, so that people feel comfortable coming and volunteering on their own. After the classes, the students feel confident about building computers with the help of other experienced people, and they come regularly. The build class facilitators sign up in three-week chunks; they do it for fun and for good. Several people volunteer to run these ongoing build sessions, and other experienced volunteers hang out to work on their own interests.

Maybe we somehow track the progress of a box, so we can contact volunteers when a box they built has been sold or donated, and we tell them the story of the difference they helped make. Maybe this encourages them to come back and build another one. Maybe there’s some kind of build volunteer tracking, so we can tell when a build box hasn’t been worked on for a while, and invite people back or release it for the next build class.

Might be interesting. =)

You know what I’m curious about? Well, on one level, there’s getting better at working with computers. And then there’s the really fascinating level of tweaking an organization and its processes. We’ll see. =) I’m sure I’ll learn tons along the way!

Free Geek Toronto: Notes from the build session

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