19:31:13 <mchua> #startmeeting
19:31:13 <zodbot> Meeting started Wed Feb 29 19:31:13 2012 UTC.  The chair is mchua. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:31:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:33:29 <rebelsky> #topic Barriers to Faculty Involvement, plus FERPA and NDAs and IP
19:33:55 <mchua> #chair suehle rebelsky
19:33:55 <zodbot> Current chairs: mchua rebelsky suehle
19:34:01 <mchua> #chair heidie
19:34:01 <zodbot> Current chairs: heidie mchua rebelsky suehle
19:34:21 <rebelsky> Georgia Tech short story: Legal counsel took a draconian view of FERPA.  "You can't post anything from any student on the Web."  No Wikis.  No coweb.  Nothing created for a class.  Also done very fast.
19:34:38 <rebelsky> Done instantaneously, so important stuff was effectively lost.
19:34:44 <kwurst> Sesion on "How to Choose a Project" is happening in #teachingopensource2
19:35:25 <rebelsky> IP issue: If students develop stuff, who owns it?
19:35:42 <rebelsky> Alyce: Currently a discussion on the AP listserve.
19:36:04 <rebelsky> Alyce: HS issue: What about minors and parents.
19:36:34 <rebelsky> Places like Stanford or Research Triangle places have a long history of startups coming out of student work.
19:36:54 <rebelsky> FERPA: Student academic record is private.  That includes enrollment in particular courses.
19:37:31 <rebelsky> FERPA: Need explicit releases from students indicating who it is being released to.
19:38:13 <rebelsky> Mel: Please make a list of important barriers.
19:38:50 <rebelsky> If you have projects that require open source you run into FERPA and IP issues.
19:39:17 <rebelsky> They may not want their code to be public.  They may not want their code to be open source.
19:39:47 <rebelsky> Problem: Different institutions have different policies about the IP developed using their resources.
19:40:05 <rebelsky> Problem: Can you essentially require someone to volunteer?  (Service learning asks the same questions.)
19:41:05 <rebelsky> Problem: Students who have something they want to make into a project.  Give them an options to keep it private.
19:41:31 <rebelsky> Suehle: Tell them "Red Hat's a multi-million dollar project."
19:41:46 <rebelsky> [Whoops.  Company.  And that's probably billion.]
19:41:46 <suehle> rebelsky: Billion-dollar. :)
19:42:03 <rebelsky> Mel: They are adults.  Give them some reasonable options: You can be anonymous.
19:42:05 <suehle> Today's the last day of the fiscal year that makes it officially a billion-dollar company, so it's on the brain.
19:42:15 <rebelsky> Bonnie: If we're having them do different things, it becomes a management nightmare.
19:42:39 <rebelsky> Bonnie: One out: Marking the class as Academic Service Learning.
19:43:14 <rebelsky> Greg: It hasn't really been an issue.
19:43:31 <rebelsky> Bonnie: People haven't been thinking about it.  But the GATech issue is getting them thinking about it.
19:44:14 <rebelsky> Alyce: "Most of us don't think about the issue until it comes up.  And then we're stuck.  You should have an out planned in advance."
19:44:56 <rebelsky> Alyce: Given my student body, it's probably not an issue.  Students wouldn't be concerned about privacy and IP issues.  But ... the planned course is a requirement for the major.
19:45:21 <rebelsky> Mel: "Agh, it's legal stuff" is not a good approach.
19:45:43 <rebelsky> Alyce: Pseudonym useful for privacy issues.
19:46:07 <rebelsky> Mihaela: Their tradition is to give students the choice.  But the students don't care.
19:46:21 <rebelsky> Mihaela: But all you need is one situation in which a student is looking for someone to blame.
19:46:54 <rebelsky> Alyce: Make it explicit.
19:47:39 <rebelsky> Sam: Can you build a portfolio with pseudonyms?
19:48:12 <rebelsky> Mel: The open source world has lots of experience with dealing with pseudonyms.  Story about someone coming out as "I'm now fourteen, so I can give you my name."
19:49:39 <rebelsky> General: It's probably worth talking with someone who knows about this.  (The terror of the general counsel, the Dean, ....)
19:50:10 <rebelsky> #topic Other Kinds of Overhead
19:50:24 <rebelsky> Faculty discomfort with being lost / lack of control.
19:50:42 <rebelsky> Overhead relative to teaching a stock/planned class.
19:50:52 <rebelsky> "It's like you're teaching a new course every time."
19:51:05 <rebelsky> Bonnie: We do some of that every time, but this is worse.
19:51:19 <rebelsky> IT support: Not only are you unlikely to get it, they may be actively against you.
19:51:37 <rebelsky> Requires new skills acquisition.
19:51:40 <rebelsky> Generally: Time.
19:51:57 <rebelsky> Question of rewards.  Does it count in merit portfolio?
19:53:10 <rebelsky> Heidi: Does professional development include learning curve for tools?
19:53:30 <rebelsky> Mihaela: It's important, but not the most important thing.
19:54:13 <rebelsky> What if few of your faculty have software engineering background?  Or even programming background?  Not used to using libraries or version control or ...?
19:54:50 <rebelsky> Showing stuff that's imperfect/in process is against our culture.
19:55:23 <rebelsky> Alyce: Something has to be ready to stand up for peer review before we put it out there.
19:55:31 <rebelsky> Mel is experiencing "counter culture" shock?
19:55:43 <rebelsky> "Why do I have to submit this a year in advance?"
19:57:30 <rebelsky> How do you know if something is worth submitting as open source?
19:57:34 <rebelsky> Mel: "The answer is *yes*."
19:59:11 <rebelsky> Mel: There is a space between private and massively available.  E.g., 'blog postings that you can show to friends and such.
19:59:18 <rebelsky> Technical reports are somewhere along the continuum.
20:00:25 <rebelsky> Note: The schools where the large majority of students are educated are probably in the "the faculty don't have a lot of software development experience and may not know what FOSS is" situation.
20:01:11 <rebelsky> Mel: "Software Carpentry"
20:01:32 <rebelsky> #link http://software-carpentry.org/
20:02:00 <rebelsky> Kristina: The problem is not the tools.  Learning the tools doesn't take that much time.  The cultural issues are much more difficult to overcome.
20:02:45 <rebelsky> Kristina: Following the bugs and staying in the culture takes too much time.
20:03:10 <rebelsky> Heidi: Also requirement of time to check on how the students are participating.  And that's usually just a high-level overview.
20:03:47 <rebelsky> Alyce: "I stayed away from IRC.  I fell into the Usenet whole.  Getting out of it took a lot of time.  Do I really want to let myself get sucked into something."
20:04:42 <rebelsky> Mel notes that "Information overload" is a big issue.
20:04:48 <rebelsky> Bonnie: Why do people use this 80's technology?
20:06:07 <rebelsky> Mel: IRC gives more people access.
20:06:24 <rebelsky> [And that's the cultural reason to do it.]
20:07:08 <rebelsky> Ruth: And you can do IRC on really crappy conference connections.
20:07:28 <rebelsky> Mel: Lowest common denominator.  You can involve even someone with limited technology.
20:08:43 <rebelsky> Alyce is worried about getting sucked in.  But she might be able to deal with IRC "meetings".  You only have to be there once in a while.
20:09:28 <rebelsky> Heidi: IRC is a nice intermediate between phone (requires context switch) and email.  You can be in a channel a period time for certain work hours.
20:10:25 <rebelsky> Mel: Manage information overload by ignoring 99.5% of what you get.
20:11:02 <rebelsky> Ruth: Merging of email and forums (fora).  You can choose how you get it.
20:11:37 <rebelsky> Ruth: "Ideally you use an open-source Wiki to teach students about open source."
20:11:44 <rebelsky> Alyce: We are trained not to ignore information.
20:14:07 <rebelsky> Bonnie: Comfortable posting question on SIGCSE.  Mel: How do we transfer this ability?
20:14:55 <rebelsky> Bonnie: Time is a serious issue.  She knows tools, but it takes time to learn the project.  She can't let her students get "productively lost", so she needs to be very involved with what they are doing.
20:15:36 <rebelsky> Bonnie: A lot of open-source projects are really badly documented.
20:16:02 <rebelsky> Mel: Documenting the projects will take a boatload of time, but will be really valuable.
20:16:35 <rebelsky> Heidi: Other barriers: What do I grade?  What are the rubrics?
20:16:47 <rebelsky> Alyce: Of course, "How do I grade it?" is a barrier to a lot of things?
20:16:59 <rebelsky> Mel: You can do non-graded open-source activities.
20:17:55 <rebelsky> Kristina: Expectations in a club are very different.
20:19:05 <rebelsky> Mel: We need to accept that some classes won't work with open source.  Should we have some sort of list?
20:19:45 <rebelsky> Alyce: Better to see positive examples.  For example, the CS0 github example shows that you can do this in CS0.  One benefit of SIGCSE: Good examples are very powerful.
20:20:10 <rebelsky> Alyce: Student-friendly projects could be helpful, too.
20:21:14 <rebelsky> Alyce and Bonnie: Mentoring is very important.
20:22:24 <rebelsky> Even getting software installed is a time sink.  Mentoring is important for that.
20:23:33 <rebelsky> Mel: A list of friendly projects is impossible.  Projects change.  And what's accessible to one person is not necessarily accessible to another.
20:23:44 <rebelsky> Mel: An alternative: A process for assessing a project.
20:24:10 <rebelsky> #idea: Friday's paper will discuss this.
20:24:43 <rebelsky> Heidi: Coordinating academic and FOSS schedules.
20:25:13 <rebelsky> Ruth: Can OpenHatch have a tag for student-friendly?  Consensus: OpenHatch probably provides enough info.
20:25:45 <rebelsky> Heidi: Another barrier: How do you handle sense of ongoing commitment?
20:26:53 <rebelsky> Mel: They can remember that they need to provide support for their successors.
20:27:37 <rebelsky> Mel: "I am now at the point that I can get up to speed on a project quickly.  Should we figure out my process?"
20:28:20 <rebelsky> Heidi: Her student, Justin, became part of three open-source projects.  She's asked him to write about how he successfully became involved.
20:30:42 <rebelsky> Alyce: I don't ask questions.  I don't want to waste people's time asking questions that have been asked.  I don't want to impose.
20:31:53 <rebelsky> Heidi: There's this balance.  Google is your friend.  It gives you high-level big-picture answers.  Then search list and forums.  But when you hit day two (or ...), you should stop now and ask the community.
20:34:32 <rebelsky> Mel: "Pick an open source project.  I am limited to four hours per week.  I will be on Google+.  You can come along for the ride.  (Anonymous, so people don't react based on her name.)."
20:34:51 <rebelsky> Kristina: We know how it works theoretically.  We need the hands-on time.
20:35:07 <rebelsky> Kristina: Support groups might help.
20:35:37 <rebelsky> Alyce: Or a book club.  The "learn an open source project" club.
20:35:48 <rebelsky> Kristina: We schedule a regular meeting.
20:37:17 <rebelsky> Mel: There's scaffolding/coaching that's possible.
20:38:11 <rebelsky> Mel: Will provide us with guiding questions.
20:39:24 <rebelsky> Mel: Start in the summer?  Sure, we'll abuse Mel's enthusiasm.
20:40:18 <rebelsky> Bonnie: The problem is not asking questions, it's dealing with replies.  They aren't always helpful.  They are often terse.
20:41:02 <rebelsky> Heidi: Worried about Mel's time.
20:41:16 <rebelsky> Mel: As long as I have the four hours picked, I'll be fine.
20:42:03 <rebelsky> Heidi: Mel gives us the questions.  Then the rest of us get together.  And we make it transparent on TOS.  And folks will provide us with more feedback than we can use.
20:42:26 <rebelsky> #action Mel creates her four-hour block.
20:42:40 <rebelsky> #action Some of us (Kristina, Alyce, etc.) form corresponding support group.
20:42:47 <rebelsky> #endmeeting