On Wed, Apr 14, 2010 at 2:00 PM, Matthew Jadud <[email protected]> wrote: > Hi Mel, > > On Wed, Apr 14, 2010 at 08:58, Mel Chua <[email protected]> wrote: >> I'm not quite sure what to do with this sort of thing. Here's a >> conversation log explaining a concept covered in the textbook (in this >> case, version control) to a student asking questions about it. >> >> http://teachingopensource.com/index.php/Talk:Getting_the_Code >> >> Participants: >> Annie Morino (morinoa) >> David Nalley (ke4qqq) >> Robyn Bergeron (rbergeron) >> >> Is there a way we can use these sorts of questions and explanations to >> improve our explanations in the text? Might it be helpful for students >> to read these kinds of logs and see what sorts of questions others ask? > > Possibly -- except my impression was that that particular conversation was > > 1. Poorly timed, and perhaps > 2. Inappropriate given for what the contributor was trying to do. > > That is, I think it serves more as a learning tool for the community > than for the participant. Specifically, we are currently working with > contributors who have zero background in any of the technologies of > the community: they've just learned IRC and wiki editing, and just > joined the mailing list. Then, several community members dive into > telling them about an alphabet soup of git, DVCS, and a host of other > terms that have absolutely zero meaning or context for the nascent > contributor. > > At the end of the day, we're trying to help students engage > successfully in a stepwise manner. Complex, technical information that > isn't useful at the wrong time is a deterrent to successful capturing > of future contributors. (Claim.) > > I've replied in more depth on the talk page: > > http://teachingopensource.com/index.php/Talk:Getting_the_Code > > Specifically, I've gone through the conversation and pointed out > exactly where I think it did well and where it fell short. My goal was > to provide some concrete reflection that we can respond and react to. > If we were to remove all of the names in the conversation, I would > have the exact same comments: the community did poorly in this case in > supporting the newcomer, and I, as a member of the faculty, had to > step in on this end and say "none of this matters to you now, and it > might not matter to you at all -- unless you want it to." And, > regardless of educational context or not, I think my answer was the > right one. (Debate!) > > Please, though, read the analysis before responding. I'm buried in the > actual execution of the experiment you're blogging on in real-time, so > for me stopping and spending an hour writing this up has a real cost. > That, if you like, is another problem with the firehose -- I struggle, > as a member of the faculty, to keep up in the radically transparent > way that the community expects. > > Cheers, > Matt > _______________________________________________ > tos mailing list > [email protected] > http://teachingopensource.org/mailman/listinfo/tos >
Hi Matt I largely agree with your analysis of the conversation from the talk page. Looking back, I have seen this exact conversation occur previously (and similarly disastrously (and I don't have any qualms saying that as 1. I was part of the problem in the referenced incident and 2. I was the one charged with shepherding the students through the entire 'get involved with the community' phase in the earlier instance I am aware of, and actively watched that train wreck occur)) I also state - that there was active discussion from the community side in IRC (#fedora-mktg) that we thought this was an impending disaster before we started this discussion with the students. One of the participants stated when he (a high school student I might add) saw the task come across the design list he thought it was going to require more than could be absorbed.) There was actually much scurrying the day this happened, because the conversation that occurred during class was - we'll help you edit a wiki page - let me look at the deliverables, and then our reaction to the wiki page was: ohhhh wow this isn't wiki stuff at all - you're 'driving the creation if(sic) this webpage' and goes on to say 'point you towards the HTML template for spins websites so you'll have something to customize' The list of tasks is here: https://fedoraproject.org/wiki/Allegheny_Activism:_Team_Assignments#Design_Suite_Spin_Webpage which links you to: https://fedoraproject.org/wiki/Design_Suite#Spins_Page whence I pulled the two above quotes. Our immediate reaction later in the evening after sussing out some of the details (where templates were stored, how you got access to them, etc) was something along the lines of - the spins site took weeks of time to bring up by people who already knew what they were doing - including at least one person paid full time as a designer to work on it. They are expected to be able to learn all of the necessary foundational technologies, then do the work? Wow this is bad. We even told the students that this was 'painful' and 'ugly'. So we proceeded to try and make the best of it by pushing as much of the 'hard content' that was going to take the longest time to absorb as possible. One of the oddities of open source development is that you don't need permission. We may reject the final work product, but you're pretty much free to do whatever you want. Moreover there are people who will actively help you in your pursuits, as in this case, misguided though they may be. Our response was flawed for dealing with students (and treating them like regular contributors). Instead we should have pushed back after realizing the scope of the task at hand and said you need to rethink this task and only do a portion of it, or ditch it completely because the ramp-up time is so great. This has been a repeated problem, as it was with the junior and senior technical writing students who decided that they wanted to tackle rewriting Fedora's Installation Guide a year or two back. Learning DocBook, git, and coupled with the fact they were almost all brand new to Linux was a bad idea - and we shouldn't have let them do it. You made an astute observation in "FLOSS contributors are so deeply expert in their tools and technologies -- or, perhaps, expert at functioning with partial knowledge -- that they forget that many people do not operate this way on a daily basis." That is a significant problem. It's a more significant problem when the true end goal isn't to learn DocBook, or how to package, and involves receiving help from people whose goal is/was to learn those items. It's also a problem to have students responsible for work and to do it with the community, and then not want to use the tools the community uses to do that work. My only disagreement with your analysis is this paragraph: 'They need help writing copy, not committing to a repos. It might matter to them if they become permanent fixtures of the team, but at this point, they're a willing contributor who is capable of doing interviews and writing text. It is absolutely true that this student could learn these tools -- I am not challenging that notion -- but that they would need git in the next two weeks leading up to release is, quite simply, silly. ' Despite writing quite a bit for publication and within open source projects, I can't help your students learn how to write. I can offer pointers, and correct grammar, and edit for style but I suspect they do that decently to begin with. (perhaps a bad assumption, I know) But when you set out asking for help to: 1) figure out content and design and 2) create the webpage itself And it involves suggestions like looking at templates, and designing/creating this collaboratively, with both their classmates, and the community, and the code/templates they are supposed to be looking at is in version control - and that repository is over 100MB in size, and under constant flux particularly at this point in the release cycle, there's no way to sanely get, much less work with that source outside of using the revision control tools. What is silly is that we didn't put a stop to the task period. I think your questions are apropos: * What is it you're trying to achieve? * Why are you asking that question now? * Is that really what you want to be working on and why? Instead of seeing the task as - 'Must shoot self in foot' and saying - ohhhh ok - 'lets help you learn how to aim properly and excercise proper trigger control' we should have said - 'wow that's gonna hurt and you really shouldn't do that' which is very out of character for open source projects. Failure is ok in open source, and even part of the process I think. For instance my first package submission was a kernel module for iSCSI (back when fedora permitted non-mainline tree modules) and no one told me it was a bad idea. In reality it was a horrendous idea (and remains so today), yet core Fedora people (including some RHT employees) were encouraging me to do so. It was a great learning experience, as I learned (eventually) that I had no idea of the complexity or what I was doing and that I should start with something a LOT easier. Of course at the time it seemed easy - I could compile my own kernel modules - surely that was enough, right? We really need to be asking those questions at each step along the way. I am really interested in how to solve the 'compress "productively lost" into something that lasts hours and days, not weeks' problem. If we figure that out, I think we benefit more than just educators teaching open source. Sadly some things are hard - like the above task, and there's just no getting around that, there may be a subset of tasks that can be done, but the tasks listed aren't an 'entry path', and one of the reasons that Design/Art has typically tried not to mentor. (That's my understanding, at least, from several conversations with the design team) Right now I don't know how to compress the productively-lost-learning down without really diving in so deep that you have no choice but to acknowledge that fact. David _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
