<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="/assets/atom.xsl" type="text/xsl"?><feed
	xmlns="http://www.w3.org/2005/Atom"
	xmlns:thr="http://purl.org/syndication/thread/1.0"
	xml:lang="en-US"
	><title>Sacha Chua - tag - volunteer</title>
	<subtitle>Emacs, sketches, and life</subtitle>
	<link rel="self" type="application/atom+xml" href="https://sachachua.com/blog/tag/volunteer/feed/atom/index.xml" />
  <link rel="alternate" type="text/html" href="https://sachachua.com/blog/tag/volunteer" />
  <id>https://sachachua.com/blog/tag/volunteer/feed/atom/index.xml</id>
  <generator uri="https://11ty.dev">11ty</generator>
	<updated>2011-09-14T12:00:00Z</updated>
<entry>
		<title type="html">Free Geek Toronto: Notes from the build session</title>
		<link rel="alternate" type="text/html" href="https://sachachua.com/blog/2011/09/free-geek-toronto-notes-from-the-build-session/"/>
		<author><name><![CDATA[Sacha Chua]]></name></author>
		<updated>2011-09-12T00:43:20Z</updated>
    <published>2011-09-14T12:00:00Z</published>
    <category term="geek" />
		<id>https://sachachua.com/blog/?p=22490</id>
		<content type="html"><![CDATA[<p>Last week&#8217;s build session went well. Four students assembled computers and got all the way to the Ubuntu installation section, while the rest were close.  </p>
<p> 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 (&#8220;Okay, everyone, look here at this thing&#8221;). </p>
<p> 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. </p>
<p> I&#8217;ve revised the instructions to clarify some other points that were missing before. Onward and upward! =) </p>
<p> Here are some ways we can make this even better: </p>
<ul>
<li>Revise checklist and instructions. Cross-reference them with   identifiers and instructions to update the checklist (&#8220;Check box #5   and write down the amount of RAM.&#8221;) This will make the checklist   easier to work with. </li>
<li>Revise checklist to make sure the boxes use a font that&#8217;s available   on multiple platforms, and check into other formatting issues.   Consider using graphical icons if checkbox Wingdings continue to be   problematic. </li>
<li>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. </li>
<li>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. </li>
<li>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 &#8220;in progress&#8221; shelves. Focus on increasing build velocity. </li>
<li>Clear undated boxes from &#8220;in progress&#8221; 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). </li>
<li>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. </li>
<li>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. </li>
<li>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 </li>
<li>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. </li>
<li>Clear enough build space so that people can work on a second box   while waiting for the install. </li>
</ul>
<p> Goals: </p>
<ul>
<li>Help students become comfortable enough with building computers that   they drop by and build computers (possibly with other people&#8217;s help)   even outside build classes. (Measurement: return visits, # of   computers completed) </li>
<li>Improve build velocity and throughput (Measurement: # of computers   built and tested) </li>
<li>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 </li>
</ul>
<p>You can <a href="mailto:sacha@sachachua.com?subject=Comment%20on%20https%3A%2F%2Fsachachua.com%2Fblog%2F2011%2F09%2Ffree-geek-toronto-notes-from-the-build-session%2F&body=Name%20you%20want%20to%20be%20credited%20by%20(if%20any)%3A%20%0AMessage%3A%20%0ACan%20I%20share%20your%20comment%20so%20other%20people%20can%20learn%20from%20it%3F%20Yes%2FNo%0A">e-mail me at sacha@sachachua.com</a>.</p>]]></content>
		</entry>
</feed>