Teaching Eval II

From FreekiWiki
Revision as of 14:21, 14 March 2009 by Rfs (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The Free Geek process-practical aspect of Eval 2 is relatively simple: determining processor class and speed. The pedagogical aspects are easy to overlook, but also important to Free Geek's very mission.

Quick Guide

  1. Introduce yourself
  2. Explain the purpose of Eval2
  3. Point out where they'll be taking systems from and delivering them to
  4. Go over documentation
  5. Go over tools and resources
  6. Walk them throught their first system
  7. Ask if they want you to watch/help with their second system
  8. Check in periodically and be available for questions
  9. Doublecheck the cart; return and explain cart rejects
  10. Encourage them to keep the space workable
  11. Test out, if applicable

Detailed Instructions

Introduce yourself to volunteers in evaluation if you want to make yourself available for questions. You can also point out the Syseval teachers list so they know that there are certain people who know more about the area than others and they have names!

Describe the main goals of the task because people like to have an idea of their role in a system. In this case, they are getting processor information about systems that we are probably going to keep so that we don't recycle things we shouldn't and we don't waste space on things we won't need. We'll also pull parts from systems we're keeping so that we can test them.

Point out where they'll be taking systems from - they should know this from eval I - and delivering them to. The second part is more confusing for most people.

Common misconception: Many people think the cart is just for keepers or just for recyclers. Really, both go there. That's why the labels must be clear!

Now, go over the documentation. Here, again, they should be aware that the documentation will change and that it's more important to understand it then to know it.

  • The System Evaluation 2 Overview is the overall step-by-step of tasks for Eval II. Many of its steps refer to the other documents. Volunteers should learn to depart from this flowchart to other documents, and remember to come back to the overview. It's like home base.
  • Getting the Processor Information is used to figure out processor class and speed. This flowchart will take volunteers through lots of troubleshooting steps because many donated systems don't POST so easily. Troubleshooting is one of the most valuable skills that Eval II volunteers learn.
  • The System Evaluation 2 Triage flowchart will be used to determine if a system is really a keeper or not. The only thing they'll need to fill in, really, is the processor speed.
  • The Case Triage and Motherboard Sorting flowcharts are used on systems that have been determined to be recyclers. We may want to keep the case or motherboard, though. The Special mining instructions tell how to mine computers from which we want the case only.
  • Removing components from keeper systems tells what to do before closing a system that will be kept. You may want to remind them that they do not have to mine systems that will be recycled. That will be done by Eval I.
  • Labeling and tallysheets for keeper systems explains how to do the paperwork before putting a good system on the cart.

Go over tools and resources they'll be using, including the ps/2 and AT keyboards, spare video cards and RAM, and WAZZIT disk. Make sure they have a pen and screwdriver, too! Then walk them throught their first system with frequent references to the documentation. Involve other Eval2 people if you think either party would benefit from the explanation.

Check in periodically and be available for questions; this can be difficult to do if evaluation is full. If there is someone else available to help with questions, share the load. It's ok to put off an interrupter until after you've finished the first question.

Doublecheck the cart; return and explain cart rejects, if you find any. Be sure it's clear that you're instructing, not criticizing. Point out errors even if the person working isn't the one that made them, so they know some common errors.

Encourage them to keep the space workable by making sure they don't remove parts they're not supposed to or leave the workspace covered with screws. If you know when their shift is over, encourage them to start tidying up a few minutes before they leave.

If someone is confident that they are done, you can test them out of Eval II. This is done by having them walk through the process of Eval II with a representative system from the stack, explaining it as if you don't know anything. Look for appropriate references to the documentation, understanding of the documentation and technical aspects, and attention to detail (cover on correctly and screwed in). If you think they're good to go, initial their page in the builder status book and make sure they know to sign up for the command line class (if necessary) and a build workshop sometime soon after the command line class.

Congratulate them! And if they're nice and they're good at explaining things, try to recruit them!

Other stuff

  • Join the systemeval list (http://lists.freegeek.org/listinfo/systemeval/) if you want to teach this with any regularity or ever change the documentation. Introduce yourself to the list when you do so!
  • Before making changes in the documentation, confer with the other build trainers.
  • Initial your documentation changes and report them to the email list.