Two thoughts from class
Today in class we were taking the skills and knowledge of the past few weeks and applying them. The students have learned how to build Mozilla, how to work with the code, how to make changes and get those changes compiled back into the application, how to work with revision control and make patches, what bugs are, how reviews work, etc. Now it was time to have them all fix a simple bug together, and reflect on the process. Many of them have already fixed bugs, or are in the process of doing so as part of their project work. However, this was the first time we all worked on the same task.
So I came to class ready to dive in and get them started, hoping that most would be able to finish in the 2 hours we had together. And then the network went down. Or more specifically, MXR went down. Went down again. It's been down every single time I've tried to show it to the students this term. I'm talking about 5-nines of downtime. It's uncanny.
Since we're talking about bugs in class, I thought I'd use this as a learning experience (note: that's what you call it when your lesson plan explodes on you and you're left to ad lib). I started by asking on irc if anyone had noticed this same issue. Many people had. Next I asked if anyone had filed a bug already. Silence. This silence speaks volumes, and what it says is, "No, but could you do it?" So I filed a bug. Within an hour and a half, it was fixed. When we spoke in class earlier about how a bug is more than just a problem in your software, and can represent just about any task that has to get completed and tracked, this is the sort of example I had in mind.
The second follow-up from class today is a bit of source code. Since we couldn't do the lab, I had to quickly switch gears, and decided to instead work on a bug I had to fix myself. I took the students through the code and showed them what was going wrong. Next I explained, at a high level, what the code did, and where I thought the bug might live. Then I asked them for strategies to debug and isolate the problem, leading them toward a solution that would make it possible for QA and beta testers (who are able to reproduce the bug, while I can't) to get me the info I need to fix it.
Very quickly the students had the idea of using the Error Console as a way of logging debug info. The code where we were working was all C++ instead of JavaScript (all examples on how to use the Error Console from code are in JavaScript), so we had to start by understanding how to use it from native code. Doing this without the help of MXR makes the work more painful, since you can't go and look for examples in the code. However, we worked slowly, and by the end of the class had 80% of the solution done. All that remained was to figure out some tricky bits of the string API.
After class was over I finished off the code and created a patch. I was finally able to do it because MXR came back up (thanks to this other bug), and I could search for what I needed: nsTextFormatter::ssprintf(). This allowed me to format the string the way I needed and then dump it to the console. Once the patch was up, I got some help to create 2 public builds with the code that others could test with. Within 30 mins I had a response back from one of the testers with the data I needed.
When you're trying to teach your students how open source works, what a bug is, etc. there is no better way than to just dive in and work on real things. You can tell people about how amazing the community is in theory, but its much better when you can show it happening. Same goes for trying to demonstrate what a bug is, and what their life cycle is like. You can make up examples, but why go to all that trouble? There's no shortage of real-world examples you can use if you take the time to look.