BIT 110125

=Build Instructor Training & Brainstorm, 1/25/11=

Check in & introductions
We are all now more awake and ready for the zombie apocalypse.

Fun facts/Y'all are awesome
The Build survey reveals that, overall, folks who feel somewhat uncomfortable with computer hardware feel very comfortable with it after going through the Build program. Hurray!

Teaching philosophy
Hand-out was passed around, will be put on the wiki for posterity.

http://wiki.freegeek.org/images/7/76/Teaching_Philosophy.odt

Discussion question
What are some ways to encourage peer-to-peer learning?
 * Introduce new builders to the more experienced builders around them
 * Get folks involved by gathering other people around
 * Have it be something that's introduced from the beginning as a potential resource, emphasize asking your neighbor.
 * "Just like in Pre-Build..."
 * Having more experienced Builders give new Builders a tour of the Build room and tours of the warehouse
 * Encourage more experienced Builders to help out new Builders.
 * Asking them to participate in the education process/mentoring of new Builders
 * Change verbiage from "Build class" to "Build shift" or "Build workshop"
 * Should we consider changing the title of "Build instructor"? Maybe to "Build master"?
 * Often it's not just showing some one how to do something, it's more confirming or facilitating that they're doing the process correctly -- and this is a great time to see people turn to their neighbors.
 * Having more advanced folks work together as special projects as a team.
 * Depends a lot on how the people work together
 * Use your best judgment about people's motivations and where they are in the program.
 * We don't want to interrupt the organic nature of the peer-to-peer learning process, but there's nothing wrong with knowing who your strong builders are and utilizing their skills
 * Build instructors should be more facilitators than founts of knowledge
 * Remind that we don't have answers, we have troubleshooting skills
 * Positive reinforcement!
 * Send other ideas to the Build Instructor list

Optical Drive Testing
Background: LCD testing ended up in Build because of an overall lack of space elsewhere in the building. It doesn't fit well with Build instructor tasks. Advanced Testing is going to take over LCD testing, and it will move to where Mac Eval is currently. To balance out the task load, Builders will be testing optical drives in-system.

Pros: Cons: Concerns: the end of the day.
 * This means drives won't have to be swapped as often
 * Builders will learn how to burn CDs in Build (a valuable skill!)
 * No more worrying about lost screws...
 * Software issues with k3b
 * Troubleshooting with newbies.
 * Known good drives from recycled systems could be saved for new/having a hard day Builders. The rest could be sent to the store at

Educational Materials
Brainstorming ways around signage overload
 * Link to the wiki on desktop as part of the distro
 * Remember the Build Tips wiki page:
 * Keep in mind that people have different learning styles; reading the wiki may not be the best way for everyone to absorb new information.
 * Printing pages from the wiki does not work well as of right now
 * Topic-based "Learn More" packets around the Build room, on topics like jumper settings
 * Offline/paper documentation is even harder to maintain than online documentation
 * Offline/paper documentation could be very simple nuts and bolts howto; use online for more in-depth information

Braille print-outs for blind volunteers?
 * Not all blind people read Braille, voice recordings would be more accessible, but also difficult to maintain
 * Utilize Orca screen reader in Ubuntu
 * One idea: keep a hard drive imaged with Vinux OS on it in the Build room
 * learning curve for blind volunteer unfamiliar with it

Translations?
 * Currently Build documentation has been translated into Spanish. We will hold off on translating it into other languages until there is a strong demand for it, due to lack of resources.

Brainstorm: What else needs documentation?'''
 * BIOS/Setup
 * Screenshots of major different brands
 * Common pitfalls in each
 * Jumper settings
 * On optical drives
 * Motherboard headers/pinouts
 * Motherboard jumpers
 * RAM: Command line hardware debugging commands
 * dmidecode
 * dmesg
 * lshw
 * /var/log/syslog
 * /var/log/messages
 * Meta-debugging techniques/troubleshooting best practices
 * "Does the motherboard beep without RAM?"
 * Refer to Ubuntu website: https://help.ubuntu.com/
 * Put troubleshooting topics into the checklist? On the wiki?

Tech Trainings
Paul is going to start having classes for Tech Support volunteers; Build instructors may also be interested.
 * Concept-related moreso than how-tos
 * Maybe once or twice a month for an hour, would start at 7
 * Tech Support volunteers would get priority, and then first-come first-serve after that.
 * There may also be interest from volunteers outside of Tech Support & Build instructors

RAM Policy

 * DDR: start with the slowest speed and work up until it boots
 * DDR2: start with the speed we have the most of (currently 533)

Troubleshooting methods
Common issues that Build instructors see a lot:
 * Can't print to the build printer
 * Computer isn't posting


 * Ask a question to figure out what they know
 * Simplify!
 * Don't forget about what they've done in Pre-Build, i.e., basic hardware knowledge
 * Check wiki or binder for flowchart
 * Check basic stuff like power cords and video cards
 * Undo recent changes, aka the scientific method
 * Let's make our environment better, i.e. by replacing annoying monitors rather than suffering...
 * We should have known good components to test with
 * burn CDRs regularly to have known good CDs
 * mark stuff that goes into the recycling box, so it doesn't resurface and swim upstream

Thank you everyone for coming and making this training so productive (and fun)!