12:33:03 #startmeeting 12:33:03 Meeting started Mon Jun 3 12:33:03 2013 UTC. The chair is rebelsky. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:33:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:33:52 #topic 2.1 Examples of HFOSS in Education 12:34:33 For those not here, it's a rainy day in Philly 12:35:57 (whoops ... the stuff we left in the room was cleaned up. Greg will replace folders.) 12:37:08 Dinner tonight. Is anyone skipping? Right now, it looks like just one missing. 12:38:02 Last night we got the landscape of FOSS. Today we get a landscape of how this HFOSS thing fits into education. 12:38:23 Slide: Scope of Learning 12:38:46 You can study HFOSS in a variety of ways - Political, Business model, Community model, etc. 12:38:57 "You can start with as small as one assignment." 12:39:10 That is, you don't have to do the "senior design capstone" model. And you certainly don't have to start there. 12:39:20 Slide: Activity Structure 12:39:47 There are lots of ways for students to work. One particularly nice approach is to have interacting teams. 12:40:09 There are a huge number of possible deliverables. "The sky is the limit." It doesn't ahve to be code. 12:40:33 And there are lots of ways to evaluate results. Beyond the professor, you can rely on the HFOSS community. 12:41:07 "You can tell students to comment until you're blue in the face and they'll ignore you. But as soon as a peer reviewer on the HFOSS project says 'This can't be accepted until it is sufficiently commented', they comment." 12:41:12 #Slide: .... 12:41:17 #Slide: 50 Ways to be a FOSSer 12:41:33 #link http://xcitegroup.org/softhum/doku..php?id=f:50ways 12:41:57 About 15 high-level categories 12:42:07 Created by a team. 12:42:18 Slide: Example - FOSS Participants 12:42:35 These aren't assignments, they are assignment ideas. 12:42:58 Shadowing sounds like an interesting approach. 12:43:06 Slide: Example - HFOSS Project Overview 12:43:20 An opportunity to help students better understand what is involved in an HFOSS project. 12:43:27 Lots of approaches (all on the slide) 12:44:01 Slide: Eample - Communication 12:44:05 (Whoops "Example") 12:44:12 It's okay to lurk for awhile. 12:45:00 Reminder: Reminder: Pad is at http://openetherpad.org/p/posse2a (but it's down right now) 12:45:04 Slide: Example - Usability 12:45:06 One of you have the link handy to where these slides are? 12:45:48 toip of page 12:45:48 #link http://foss2serve.org/images/foss2serve/d/da/POSSE_Stage2Materials.zip 12:45:48 http://www.foss2serve.org/index.php/Stage_2_Activities 12:46:04 Slide: The Course - Software Engineering 12:46:30 Heidi's course. It's a senior-level software engineering course that all students have to take. 12:46:40 In many ways it's a traditional course. 12:47:00 She wants to add more real-world experience - the complexity of an on-going project. It's their last opportunity to do this before going off to the real world. 12:47:33 How did she start? 2006, she was at Trinity. In January, one of their graduates (also a lab support person) came back from Sri Lanka (which was having a major Tsunami). 12:47:46 He said "We have to get involved in this project called Sahana. It's really cool." 12:47:55 Heidi had trouble finding time (no surprise), but the student pushed. 12:48:15 So Heidi and Ralph Morelli found two independent students to help them learn about it. 12:48:23 More "Okay ... go figure this out." 12:48:27 Step one: Download and install. 12:48:31 Step two: Make a minor mod. 12:48:39 Discovered that the project was approachable by students. 12:48:54 And a relatively open teaching style: "Go figure it out and then come back and ask questions." 12:49:12 Those two students, plus a volunteer from Bard, spent the summer developing a volunteer management module. 12:49:45 By the end of the summer the Sahana group was so thrilled that they sent a student to a disaster simulation. Their code got used to register over 200 participants. 12:49:53 Impact was immediate. 12:49:59 And that's how Heidi got hooked. 12:50:07 Warning! That's not a typical experience. She got lucky. 12:50:17 Slide: The Project: Caribou 12:50:25 Fall 2009, if I get it right. 12:50:42 Caribou is an on-screen keyboard for people who have difficulty using a physical keyboard. 12:50:53 Slide: Caribou Development Environment 12:51:19 Students developed new keyboards. Surprise! Keyboards are JSON format. So, not a lot of traditional coding. 12:51:40 But Heidi wasn't worried about whether they can code. The big question is whether they can navigate in a large project. 12:52:07 It took students about four weeks to figure out the format and everything. 12:52:32 Slide: Student Enhancements (....) 12:52:38 Slide: Student Enhancements; Usability 12:52:58 She's not sure that they provided that one back. THe students decided upon it without seeing it on the buglist. 12:53:10 Slide: Student Enhancements: Programming Keyboard 12:53:35 #link http://titanpad.com/posse2a 12:54:08 Discussion of what gets accepted back to community. 12:54:20 In Gnome everything is "design driven". 12:55:08 Note! Start with the community. 12:55:27 It may seem cool if you come up with, but it's cooler when you are doing something the community wants and then gives positive feedback. 12:55:37 And FOSS communities are usually good about this. 12:55:57 Some of what students do will be successful and be accepted. Some of what students do won't be accepted. 12:56:23 Lots of reasons it's not accepted - Sometimes students forget to push (send pull request, whatever). Sometimes someone at the other end is "asleep at the wheel". 12:56:40 Question: How did you come up with this project? 12:57:11 Heidi: "Community first." Emailed Joanie. Gave outline of what she wanted. Asked for suggestions. Caribou came back as a suggestion. 12:57:29 Important thing: Heidi had developed a relationship. 12:58:17 But it's also possible to ask similar questions without having contacts. 12:58:42 As long as you approach the community and you're clear about your status, you're likely to get responses. 12:58:47 And the communities are used to newbies. 12:59:02 The whole idea is that you're not doing it by yourself. 12:59:48 E.g., when she was installing some software, she hopped on the IRC and said "I'm having trouble, I've googled, here's how far I got." And she got help. 13:00:02 Greg: Remember that you'll start small. And that there are always tasks that have to be done. 13:00:22 Question: What's the process when things get rejected? Is it an iterative process. 13:01:10 Heidi has a good example of some iteration. A student submits. "You have to fix A, B, and C". Student fixes. "You have to fix E, F, G." Four rounds. Then accepted. 13:01:16 But that was a responsive moderator. 13:01:39 The on ramp for any project we're likely to work with is bumpy. "Maybe there's a path you can see through the woods." 13:02:00 As a fresh set of eyes you can 'blog, take notes on, etc. all the hurdles along the way of getting started. 13:02:10 Could you then start to build a better "Getting started" page? 13:02:32 We're used to doing this. So it's an area we can really help out. 13:03:22 Two students in OpenMRS could not get it installed. The developers had spent too much time in the environment and hadn't realized the problems in getting started. Her students spent four weeks dealing with it and now their stuff is on the OpenMRS site. 13:03:31 [We will talk about communication methods soon.] 13:04:35 Karl's story about Eucalyptus. Their goal had been to go through the setup process and give feedback. But it took them half a semester to get the hardware done. 13:05:02 And there ended up being no good path for the documentation to get in to the main project. (It lives on a Wiki elsewhere.) 13:05:14 Remember! Students can learn from failure. 13:05:52 It appears that the project was not yet ready to have that many student contributors. (At the end of the semester they had added a Wiki, etc.) 13:06:10 That's why we do FOSS field trips. 13:06:47 Note: When you're building a project, you're out in the middle of the woods trying to build a city. And it's so cool when someone finds you. 13:07:11 (In case that wasn't clear, that's often the perspective of the community.) 13:08:07 Fixing even the smallest bug gets students used to the whole process. And the smallest bug can include a typo. 13:08:17 Slide: The Project: OpenMRS 13:08:30 Originally started to track aids patients in south africa. 13:08:38 It's a significantly different project. 13:08:54 "If there are twenty different ways to do something in OpenMRS, they've used all twenty different ways." 13:09:16 Slide: Student Enhancements: Developer Environment Instructions 13:09:33 Great student idea. After each step, they took a snapshot of the Virtual Box so that they could back up. 13:10:27 Slides: Untitled 13:10:59 Issue: Open MRS does not do good name mapping. Students worked on it but didn't solve. 13:11:17 High school opportunity: Come up with test cases. Give expected output, actual output, and time required. 13:11:25 (Whoops ... change required.) 13:11:46 Slide: Project; Epidemiological Modeling 13:11:58 Slide; Map of US showing the spread of a disease. 13:12:12 Slide: STEM Development Environment 13:12:42 Different communication style: Rather than IRC, they had a weekly conference call. (Perhaps b/c it started as a project at Stanford.) 13:12:47 Slide: Student Enhancements 13:12:54 Slide: UI 13:13:17 When you mouse over a location, it gives some info (county, area, population, etc.) 13:13:40 Community also wanted number of infected people and a timestamp. 13:13:55 But where do I start with 3/4 M lines of code? 13:14:03 The community pointed them to the right 5-10 files. 13:14:10 And Heidi didn't even have to look at the codebase. 13:14:22 On to Cam 13:14:31 Slide: UI of Ushahidi project. 13:14:51 Ushahidi came out of election violence in Kenya. Has grown to open-source mapping application. 13:15:02 The Ushahidi foundation keeps growing. 13:15:36 Cam got involved through Canadian undergraduate capstone project. 13:16:03 Some folks who work on a project swim in stuff so much that they don't realize the things that you need to know to get up and going. 13:16:26 And not everyone is good at providing reasonable tasks. Some can be three year projects. 13:16:42 Knowing what can be done takes some practice. 13:17:19 It's a growth experience. The first time Cam did this, projects were too large. This time, he's having them look through git issues and evaluate a bit. 13:18:24 Some technology: Reports come in. Someone verifies. 13:18:29 Then data can be visualized. 13:19:05 One student project - Seeing categories in their own color. 13:19:13 Sounds simple. Why is it a course project? 13:19:53 Students may need to learn PHP, the Model-View-Controller pattern, Javascript (which dynamically generates the dots) 13:20:01 The Javascript talks to the Web server through the API. 13:20:39 UI issue: If you combine dots and show numbers, what happens when they are in different colors (different categories) 13:21:32 Another issue that students work on ... how do you support verification. 13:21:43 Context: Mapping illegal garbage dumping in Italy. 13:22:07 Problem: Limiting what areas people can verify (or can't verify). 13:22:30 Student solution: Draw a polygon and only accept verification from within that polygon. 13:23:19 A second set of students came up with a different solution. 13:23:25 Which gave them a chance to compare solutions. 13:24:12 Heather, the Community Director from Ushahidi, serves as a contact and sometimes Skypes in to see student presentations. 13:24:54 Having the external person sets student presentations to another level. 13:25:07 Whoops! We're about ten minutes over. 13:25:52 Whoops! Technical difficulties with lecture system. 13:26:59 #topic 2.2 HFOSS in the Curriculum 13:27:40 (We may be behind schedule, but some of the things from this session got covered in the previous session.) 13:27:50 Ideas to help us think about where this fits in our department curricula. 13:28:17 A bit of intro, and then some discussions of typical places HFOSS appears in the curriculum. 13:28:22 Slide: Options for Getting Started 13:28:43 It's not realistic that most places can add a full HFUSS participation course. 13:28:55 Administratively, it probably wouldn't work. 13:28:57 And we need experience. 13:29:08 Most people have been successful starting with small steps. 13:29:30 Figure out what's reachable for you. 13:29:53 The start simple model seems to be how things happened at Drexel. 13:30:02 Adapting ideas from Trinity. 13:30:14 Slide: Getting Started - Examples 13:30:58 It's definitely been a learning journey for Greg, and he's not anywhere close to being done journeying. 13:31:29 Greg found it useful to use some of the professional master's degree students, but he's mostly used undergraduates. 13:31:52 Greg would like HFOSS as a feature of the entire curriculum. But that's a long process. 13:32:49 Karl got started by watching a presentation by Greg and Heidi. Started with senior capstone. 13:33:00 Working on a larger project seemed better than building an invented toy project. 13:33:09 Each semester he's used a different open source project. 13:33:18 (Each semester == Each spring) 13:33:35 Also taught a first-year seminar on the concept of Open. 13:34:15 Book: Shirkey's Cognitive Surplus http://www.amazon.com/Cognitive-Surplus-Technology-Consumers-Collaborators/dp/0143119583 13:34:26 Had students work on editing Wikipedia. 13:34:31 At least one students banned. 13:34:32 maybe we could all collect a list of relevant readings? 13:34:53 This student made totally inappropriate edits. 13:35:18 A plan for the nonmajors course (in Python) - Go look at what Python modules are out there that you can use. 13:35:53 #link http://xkcd.com/353/ 13:36:37 rebelsky: +1 for posting one of my favorite xkcd / Python cartoons 13:36:41 Teaching and learning group was looking at hyper-local news. 13:36:48 Put up OpenBlock server. 13:37:15 #link http://openblockproject.org/ 13:37:55 Next idea: Students are asking him to start git earlier. So he's trying to incorporate it in the earlier classes (first course)? 13:38:20 Needs to help them get a deeper understanding of what they're doing with git ... not just following a script. 13:38:24 He'll talk more in another session. 13:39:12 Note: There are all sorts of side learning that happens. Professional behavior, problem solving (Heidi's VBox example), etc. 13:39:33 They build very valuable professional skills. 13:39:49 Just because you're stuck, it doesn't mean that you can stop. Problem solving of how to go on. 13:40:11 How do you fit all of this into your curriculum. Need to find learning goals and have the opportunity for serendipitious learning. 13:40:29 Many things you learn from open source are things that you have difficulty teaching in the regular curriculum. 13:40:38 But it's difficult to be sure that you can get the same result every time. 13:40:51 Slide: Example: Single HFOSS Assignment 13:40:58 (Greg needs to speed up more. Scary.) 13:41:13 Easiest thing - I'm going to do something simple in course X. 13:41:25 But that's actually difficult in terms of getting them to participate in a community. 13:41:34 FOSS Field Trip is one kind of assignment that works with this. 13:41:59 It's hard to get much beyond that if you're only going to do one assignment. 13:42:24 Going beyond that? Perhaps more scaffolding (develpment on our part). 13:42:39 It may be possible to do bug fixing. But it sounds like it needs a lot of scaffolding. 13:42:55 Some of the scaffolding can come from the curriculum. (E.g., if they know git early ...) 13:43:49 Suggestion: Reading the mailing list archives and sending in a small question might be a more interactive component of the FOSS field trip. 13:44:02 But you don't want to overwhelm/annoy the community. 13:44:37 There has to be a balance between being visible and being good citizens. 13:44:40 Can this scale up? 13:45:16 Students will "kick the bees nest anyway". 13:46:36 There may be some communities that welcome this kind of interaction. 13:47:28 Introducing yourself and asking a question on an IRC is huge. 13:48:03 (Remember ... show that your brain is turned on before you engage the community.) 13:48:29 Often, students are at the ends of the spectrum ... scared to get on at one end, willing to go on and insult everyone at the other 13:49:31 Need to understand the size of the project to see how many students you can unleash on the community. 13:50:37 Sometimes trying it yourself first is a good idea. 13:50:42 Test the waters! 13:51:29 Also prepare the students to work with the community. The students don't necessarily understand that the person they are talking to may be the person who hires them. 13:52:41 How much does the faculty member have to be the gatekeeper between the students and the community? Some, but you don't want to cut off communication. 13:53:32 How big are the classes that you're doing this with? Most are doing 8-24 (or 30) 13:54:28 Slide: HFOSS in a Project Course 13:54:34 Most curricula have something like this. 13:55:03 Greg thinks that for sophomores and juniors our Stage 1 activities are more appropriate than real participation. 13:55:49 Really changes the model of the capstone course in which students have traditionally had a complete project with multiple stages. 13:55:53 Slide: HFOSS as a Course 13:56:32 Two major courses: One in which students participate in open source projects; Another in which students learn about "Open" 13:57:58 Slide: HFOSS as a Curriculum Thread 13:58:19 Greg has started to move things down the curriculum change. 13:58:37 He's fortunate in that there's a course early in the curriculum that introduces them to larger systems. 13:59:34 Slide: HFOSS Beyond the Curriculum 13:59:54 If you can't change your curriculum, you can look for other things to do. 14:00:45 #link http://www.rhok.org/‎ 14:01:07 #link http://hackforchange.org/ 14:02:11 Heidi's story about being at Gnome meeting. Mel Chua said "You should have a session." 14:02:27 (Okay, that' s "propose a session".) 14:02:40 And their session got forty people showing up. 14:03:55 We have some food for thought at lunchtime today. Michael Brennan will chat with us about random hacks of kindness. 14:04:41 (Now we're only five minutes over. Good job!) 14:05:41 #topic Break 14:07:21 howardf: Let us know if you have questions along the way ... 14:09:03 Anyone know about getting the resolution changed on the CS50 appliance? I've installed the Guest Additions and raised the simulated video memory, but I'm still stuck at 800x600 14:20:01 Etherpad is back up. 14:20:05 #link http://openetherpad.org/p/posse2a 14:28:19 Bleh. Even reinstalling the Guest Additions didn't solve the problem. 14:30:01 rebelsky: What environment is a CS50 appliance? 14:30:33 Hmm ... will break end soon? 14:30:41 yes soon :) 14:30:55 joanie: The CS50 appliance is the thing Cam distributed to us to play with Ushahidi. 14:31:11 I think CS50 is a Harvard Course. The CS50 appliance seems to be a relatively small Red Hat VM. 14:31:27 rebelsky: what I mean is, what desktop environment or OS or whatever 14:31:34 #topic 2.3 Understanding Open Source Communities 14:31:39 but oops I need to pay attention before I get called on. 14:31:51 Heidi started teaching with horseback riding. So she can be LOUD. 14:32:35 Slide: Overview 14:32:46 Heidi will talk, but Joanie and Ruth will jump in. 14:33:17 Slide: FOSSism: It's All About Community 14:33:33 You are not doing code. You are not working on an assignment. You are joining a community. 14:33:48 And if you don't understand the community, you won't understand where it's going and what it needs to survive and grow. 14:34:07 To be successful, you really need to have long-term participation in the community. 14:34:19 So ... get to know your community. 14:34:28 Slide: Get To Know Your Community - 1 14:34:49 While we say "Community, Community, Community", different people have their own rules, spoken and unspoken. 14:34:58 They expect you to adhere, but don't really think about it. 14:35:08 Try to avoid sticking out like a sore thumb. 14:35:20 Each community has its own mode of communication. 14:35:36 Some say "If it doesn't exist in a Bugzilla comment, it doesn't exist." 14:35:49 Slide: Get To Know Your Community - 2 14:36:18 There are processes. How do you find that out? (We're heading toward it.) 14:36:38 There are both written and (un)written rules 14:37:23 And you need to follow lots of rules. If you miss some of them, you may get ignored, even if you've done the rest. 14:37:33 Some are as simple as "you should never go beyond 80 characters". 14:37:57 Slide: Get To Know Your Community - 3 14:38:25 And communities have different subcommunities. The Gnome team is different than the Gnome accessiblity community is different than .... 14:39:02 And then you get down to the individual level. 14:39:55 And sometimes code goes by multiple communities with somewhat contrasting standards. 14:40:04 Get To Know Your Community - 4 14:40:20 "Hmmm ... the ORCA roadmap has not been updated in three or so years." 14:41:07 http://openetherpad.org/p/posse2a working again 14:41:49 The first semester is likely to be difficult. 14:42:00 So stay in the same community - the rules will stay the same. 14:42:03 And stay connected. 14:42:19 Eventually, the community will look out for you. 14:42:51 "We do want your students to be part of our community." 14:42:58 "We're just really busy." 14:43:17 "But it will all be awesome." 14:43:39 Reminder: Be careful not to use too many projects in one course. 14:44:44 Slide: Get to know your community 5 14:45:27 Remember: Learning the rules as you go is a good experience. You have to do it in any job. 14:45:40 So it's great for students to do it once as undergrads, before they get a job. 14:46:08 Open source leads to great "teachable moments" 14:48:56 Remember that the TeachingOpenSource community is a community, too. (A helpful community.) 14:49:09 As faculty members, it's hard to come off as ignorant. 14:50:02 (It's emotionally hard. We certainly have the ability to be ignorant.) 14:50:32 Outdated roadmaps are not as much of a negative sign as they seem to be. 14:50:45 Very few projects keep their roadmaps up to date ... they are very tricky. 14:51:12 git logs give you much more information about what's going on. 14:53:35 Note that some folks in one project can help you navigate other projects. 14:54:16 Also a goal of this POSSE - Building some small groups that can share local knowledge. 14:55:36 And a goal of the HFOSS directory on Foss2Serve. 14:55:49 And may incorporate their assessment rubric. 14:55:58 Slide: FOSSism: Be Productivel Lost 14:56:21 You don't have to understand the whole codebase to participate and be involved in the community. 14:56:30 You navigate by working within the community. 14:56:31 * joanie just pinged the GNOME Accessibility Project Lead telling him we need to prioritize updating our roadmap. Sorry about that!!! 14:56:53 Slide: FOSSism: Give Back 14:56:59 Remember: Fixing a typo is a huge giveback. 14:57:26 Once you get active on the listserve, you can start answering newbie questions. 14:57:45 Even verifying a bug is useful. 14:57:56 Slide: FOSSism: Opportunism reigns 14:58:30 When the right alignment of planets happens, they'll do it. That means that the plan you've made for the semester is likely to fall apart. (Well, may fall apart.) And we'll talk about how to handle that. 14:58:57 Faculty think three years out. FOSS people tend to think three weeks out, maybe three months out, maybe even four months out. 14:59:23 It's not that the community is trying to sabotage you. It's just how the community works. 14:59:44 Slide: FOSSism: If it isn't public, it didn't happen 15:00:06 Note that public means accountable. It makes students more careful about what they do and what they publish. 15:00:28 We'll talk about this more in the project. 15:00:51 Another violation of faculty norms - Get used to public communication. 15:01:49 Sam asks about FERPA. We'll talk about it later. 15:01:56 Slide; FOSSism: Radical Transparency 15:02:39 Students tend to be more comfortable with this than you are. But not all of them. Heidi has had some students reluctant to write a 'blog. 15:02:56 Some of it will feel foreign to you. 15:03:11 Everything is out there. Not just the products, but also the decision-making process. 15:03:32 Slide: FOSSism: Ask Forgiveness, Not Permission 15:03:56 If you're thinking you might want to try something. Try it and then ask about it. You'll almost always get a "yes", unless it doesn't follow the current trend. 15:04:05 "You're not screwing them up by branching." 15:04:11 Slide: FOSSism: Branches are Free 15:04:26 If you have something that's cool, share it back with the community. 15:04:32 Slide: FOSSism: Keep a Hisotry 15:04:56 Think about Joanie's note that "the git log provides a history." Don't commit without a MEANINGFUL comment. 15:05:04 Ideally, the comment links to the bug. 15:05:44 Remember that students come into a project and then leave the project. Having history that documents what they've done is necessary. 15:06:01 Question: How often do students stay on and continue contributing to the project? 15:06:07 [Red Hat wants to know that, too.] 15:06:29 We can cite cases of "this student or that student". But we don't have enough data to talk in general. 15:08:05 Some interesting research questions here. 15:08:43 For example, are students who do these things likely to be more comfortable incorporating open source as they move on to the corporate world. 15:09:31 Your github account is sometimes your calling card for your fist job. 15:09:34 (first job) 15:09:47 It's part of your portfolio. 15:10:22 Question about Radical Transparency: How much student resistance is there to the openness? 15:13:01 Importance of developing communication skills by writing and posting. 15:13:14 And students learn from commenting on each others' work (and from having their work commented on) 15:14:09 Changes the process too ... instead of "do the work and get the comments", it's "do the work, get the feedback, and then incorporate them" 15:14:28 Not all students are the same. So having alternatives and such are important. 15:14:52 Good developers make mistakes, too. That's why we have a review process. 15:15:46 A great 'blog story: Students were blogging and complaining about it. Then a leading researcher commented on one of the 'blogs and suddenly it was cool. 15:16:05 90% of folks in open source are really nice. 15:16:18 Slide: FOSSism: Begin with the Finishing Touches 15:16:26 "Pick something little." 15:16:39 Slide; FOSSism: It's Not What You Know, It's What You Want To Learn 15:17:03 Remember that everyone was once a newbie. FOSS projects are used to newbies coming in. 15:17:18 Join a community to learn. Not to make a big impact (at least not at first). 15:17:31 Slide: FOSSism: Release early, Release often 15:17:43 Release, get feedback, and such. 15:18:38 Slide: FOSSism: Push to Upstream 15:19:39 Slide: FOSSism: Show Me The Code 15:20:29 Slide: FOSSism: Shallow Bugs 15:20:34 An impact of radical transparency. 15:20:49 People can review and provide feedback and help you fix bugs. 15:21:15 Slide: FOSSism: Uncommunicated Work 15:21:39 With two weeks left in the term, you'll know what your students have and have not done. Make sure it gets communicated before they go off at the end of the semester. 15:21:47 What have they done? What haven't they done? What do you see as the next steps? 15:21:51 And try to get someone to take it on. 15:22:24 Because a contribution isn't complete until you've handed it off. 15:22:55 Should we perhaps plan a soft "pencils down" date about three weeks in advance of the end of the semester? 15:23:46 Sometimes students are invested enough that they get it committed. 15:24:50 Perhaps try to break the project down to smaller projects so that you can be clear how far you've gone. 15:25:20 Greg's story: Students were working on instructions for installing on a new OS. During break, someone picked up what they were working on and finished it. 15:26:56 #topic Getting Started 15:27:20 Question: GSoC students? 15:29:42 But reminder that public github accounts are one of the ways that students are doing GSoC 15:29:49 Getting started with version control. 15:29:51 #Link http://www.ericsink.com/vcbe/ 15:31:34 We need to understand how important version control is. 15:32:14 (Okay, that was a detour. Now we're starting on Getting Started.) 15:32:28 Now we're doing the explicit step-by-step how you get started. 15:32:40 Step 1: Getting Organized - 1 15:32:46 Assumes that you've done the initial project evaluation. 15:33:10 You should have done cursory examination for the major signposts. (We say cursory because not everything will be up to date.) 15:33:23 Heidi has students identify each of these so that it's right up front. 15:33:30 Step 2: Getting Orgainzed - 2 15:33:41 Make sure that the deliverables fit your course. 15:33:55 Opportunism: Don't identify the exact bugs, but look at the types of bugs that are filed. 15:34:05 And try to trace the process for fixing a bug. Can you step through the cycle? 15:34:21 Step 2: Lurking 15:34:27 (That earlier Step 2 was Step 1, part 2) 15:34:43 Lurk on the IRC. Find meeting times and try to lurk. 15:34:48 Step 3: Introduce Yourself 15:35:00 Once you have a base understanding. Who are you and why are you joining? 15:35:06 Do this *months* before the semester starts. 15:35:29 Greg notes that there are different levels of introducing yourself. 15:36:16 If you're watching on IRC, you may want a quick introduction saying "Hi, I'm a faculty member at X and I'm just lurking." 15:36:30 Step 3: Continued 15:36:46 Remember! The goal is to facilitate student entrance into the community, not find student work to do. 15:36:57 Step 4: Finding Things to Do 15:37:02 Remember! Be transparent. 15:37:23 It's important to accomplish the task and get it committed. 15:38:09 Question: What if I need the open source project for incorporating into something else. 15:38:20 Shop it with the community 15:38:47 If anyone has to use git and is totally unfamiliar with it, I'd be happy to do a lunch/evening/whatever useful git tricks session. 15:39:32 #topic The Pop Culture Guide to Open Source 15:39:39 Designed for people who don't know about software. 15:39:50 Presentation is from Maker Fair, but she's going to talk about how she's using. 15:39:57 There are lots of versions of the presentation on YouTube. 15:40:20 All of the open source principles are related. And they all come down to sharing. 15:40:43 Some time in the growing-up process we forget how to share. 15:41:17 The principles, rather than "Open Source". Because "Open Source" makes people think about code. 15:43:08 Open Source Hardware community isn't quite as tied to open. 15:43:22 MakerBot 2.0 is a big closed box because "folks were stealing my stuff" 15:44:15 What is open source hardware? Like open source software, but for physical things. 15:44:19