14:05:36 #startmeeting 14:05:36 Meeting started Tue May 4 14:05:36 2010 UTC. The chair is mchua. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:05:39 #chair ctyler 14:05:39 Current chairs: ctyler mchua 14:05:44 #meetingname POSSE RIT curriculum 14:05:44 The meeting name has been set to 'posse_rit_curriculum' 14:06:10 #info our tech guru is Luke "lewk/lmacken" Macken, Python ninja of TEH AWESUM 14:06:20 #link http://teachingopensource.org/index.php/POSSE_RIT#Topic_Schedule 14:06:51 #info We have 12 attendees confirmed, 2 more likely to come, for a total class size of 14; all are RIT profs except for 1. 14:07:00 mchua: what are our goals here? s/Mozilla/Sugar/ and leave in most of the Fedora bits? 14:07:08 #info We have a few non-technical professors, mostly from the publishing/journalism/writing-related side of things, and willing to dive in. 14:07:12 ctyler: Yes. 14:07:26 ctyler: Those are the demographics that I've got - I can send you more detailed info if you want but didn't want to hose you with reams of everybody's apps. 14:08:36 mchua: there's non-technical and non-technical :-) what level of non-technical are we talking about here? 14:08:55 Reason I ask is that ... 14:09:49 non-devs/non-admins can make packages, but you have to know your way around paths etc. 14:10:04 (as one example) 14:10:33 ctyler: We expect folks to be able to find their way around a Fedora desktop, they might just not know how to code, is my impression. 14:10:40 ok, perfect 14:10:50 They're folks with some exposure to free software (Drupal, etc) on the publishing end of things, just non-devs. 14:11:02 right. 14:11:12 ok, shall we go day-by-day through the schedule? 14:11:18 Worksforme. 14:11:21 #topic Monday 14:11:30 I think Monday is pretty much set, really. 14:11:33 * ctyler switches to larger screen 14:11:55 I mean, minus the "Mozilla" description. 14:12:03 * ctyler is back 14:12:22 * mchua would be comfy doing any part of Monday, though you may want to take the intro since you're coming from the "I am a prof, hooray!" perspective. 14:13:38 even there we should alternate probably 14:14:19 in the first bit, do you want to lead the timeline? 14:14:38 ctyler: Can do. 14:15:13 Actually, if I can recommend, let's lay out the topics, and we'll do the divvy-up later? 14:15:33 Sure. 14:15:41 Let's s/Mozilla/Sugar/ there, otherwise I think Monday is good 14:15:54 * mchua makes that edit now 14:15:58 ctyler: onwards to Tuesday? 14:16:14 Did the "physical wiki" status check thing have value in your opinion? (the migrating post-it notes) 14:16:34 ctyler: I liked it, personally. I do think it had value. 14:16:41 It's easy to set up, easy to ignore if it doesn't work this round. 14:16:52 Or should we do rose-thorn-bud or some other approach? 14:17:33 (not that they're mutually exclusive) 14:17:40 ctyler: I think that works for the wrap-up at the very end, but in terms of tracking skillset I like the 2D post-it axis. 14:17:54 and we'll have a lot more people to track this time, so I can see that being useful. 14:18:05 ok 14:18:34 #agreed repeat of 2D sticky note skillz tracker 14:18:41 #topic Tuesday 14:18:43 #agreed rose-thorn-bud wrap-up feedback on Friday 14:19:04 Right, so getting source. Source for what? 14:19:15 Also, I'd like to nix the packaging stuff this time, in favor of... something else. 14:19:24 wait a second, we should fork the day pages 14:19:38 ctyler: #action and I'll do it after the meeting 14:20:03 #action mchua to fork day pages 14:20:22 ctyler: so what we're doing for the Sugar POSSE with Walter and Sebastian the week before is to have 'em work on already-existing Activities 14:20:42 which works nicely for both tech and nontech people, since there is some Python-fu to be done, but also much documentation and whatnot to write. 14:21:09 Right, which is one way of Getting Source. I'd like them to see that in two other ways too: getting source in traditional tarball form, and getting source via the RPM tools 14:21:28 even docs folks have to grab tarballs sometimes :-) 14:21:32 ctyler: bonus is that RIT students have written Activities that are relatively close to what we need. 14:21:47 ctyler: yep :) +1 on multiple ways of Getting Source. 14:22:00 I also want everyone to learn *some* form of VCS. Git, likely. 14:22:16 I think that's often a barrier to entry -- "I wanted to help but they kept telling me about tar pits or something" 14:22:45 yes, let's go Git. according to some reports, it has a 60%+ market share 14:22:54 "everybody had a southern accent, they kept telling me to git" 14:22:59 #agreed our VCS of choice is git 14:23:06 and better to teach distributed vs central model, given the choice 14:23:08 Yes. 14:23:25 ctyler: We've got the textbook as a resource this time if we need it, btw. 14:23:31 right 14:23:42 #info Getting source: make sure to teach tarball, RPM, versions as well 14:23:50 #info remember: we have a textbook this time, if we want! 14:24:07 ctyler: my main question is, "are Sugar activities the codebase we want to have them work in for this time?" 14:24:14 so Morning A, let's do tarballs, RPMs, and fetching from a Git repo 14:24:18 because if not, we need to figure out what is 14:24:30 #info Tuesday morning: tarballs, RPMs, fetching from git repo (vcs 101) 14:25:10 mchua: that's my question too. On the one hand they're low-barrier-to-entry, on the other hand they're ... atypical 14:25:25 * mchua would like to teach the non-coders a build system, maybe, dunno, Publican? 14:25:54 ctyler: Agreed on both counts, I'm struggling to think of alternatives though. 14:26:29 +1 on publican, I think we should show that "build" is a part of most open source, whether you're building a doc or building a package of scripts or building an executable. 14:26:30 ctyler: for the Worcester POSSE we're trying to bridge that by working on the Sugar on a Stick spin, since that's a Fedora spin and thus gets all nicely packaged up in standard-ish ways in this part of the universe... code's still weird though. 14:26:45 #agreed Publican will be the build system we teach to non-developers 14:27:06 though I don't want to split into devs and non-devs! 14:27:09 ctyler: also, community is smaller/less-mature in some ways... although a small enough subset of Fedora code, and you're talking a small group too. 14:27:13 ctyler: Yeah, nor do I. Hm. 14:27:28 ctyler: I think we may have to in terms of having them work on separate parts of the same project at some point 14:27:51 i.e. someone is fixing liveusb-creator (...oh hey, Luke! We could do that, it's written in Python iirc) and someone is updating the publican docs for it 14:28:01 * mchua looks at liveusb-creator code 14:28:04 I think we can teach both. We did moz builds and Fedora packaging as two examples last year, this time we can do sugar activities and publican builds 14:28:53 mchua: I haven't been following the sugar packaging stuff, what was finally decided about how activities would be packaged? 14:29:07 are they RPMs or not-RPMs? 14:29:20 ctyler: hm, https://fedorahosted.org/liveusb-creator/report/1 and https://fedorahosted.org/liveusb-creator/browser looks pretty much ok, can ask Luke if he'd like to lead a deep-dive there... but that's a later day 14:29:22 * ctyler remembers that was a big debate at FUDcon MIT 2009 14:29:24 ctyler: RPM 14:29:29 ctyler: Well, for Sugar on a Stick, RPM 14:29:32 ctyler: we're a Fedora Spin 14:29:33 ok 14:29:52 ctyler: It makes a lot of things way easier, being a spin. Also, we know what spins/kickstarts/etc look like. 14:30:00 (and I now know how to update spin webpages, w00t) 14:30:00 right, but Moz extensions are installed on Fedora all the time, and they're not RPMs ;-) 14:30:06 * mchua grins 14:30:07 true 14:30:46 Well, ok - Tuesday morning they're learning how to grab source, use git 14:31:01 ok, I imagine they're pretty trivial to package. I'd like to keep a little bit of packaging in there to show how the build process gets standardized. 14:31:41 Tuesday afternoon we can have them yoink code for a Sugar Activity that you can walk through packaging for, and the publican stuff for the Creation Kit (SoaS documentation), and build both (in terms of "oh, I have the docs working locally on my system, and an Activity that's running"? 14:31:58 That works well, I think 14:32:08 * mchua nods, I think packaging overview is important if we're going to talk spins and remixes... I know Luke also wanted to do (or is doing already?) an RIT Remix 14:32:11 so that might fit nicely. 14:32:40 perfect 14:33:03 #info Tuesday afternoon: download code for a Sugar Activity, Chris talks about packaging (and spins/remixes: this is where lmacken brings up the RIT Remix if applicable), then download docbook xml for SoaS Creation Kit docs and Mel will walk through building them 14:33:46 ctyler: and then their homework Tuesday night can be "now test the docs you just built by using liveusb-creator, as specified, to burn yourself a SoaS stick, *and* get the image running in a VM on your machine" 14:34:10 (that should give us plenty of documentation/process bugs to fix the next morning...) 14:34:11 yes, but yikes 14:34:19 I expect everyone to make it through the first 14:34:24 and maybe half the people to make it through the second 14:34:53 mchua, you're setting a pretty steep curve for non-technical users here 14:35:02 even for technical ones 14:35:07 oh, hm. 14:35:20 build + spin + VM is quite a bit for overnight 14:35:25 how about just "get a working stick?" 14:35:56 the creation kit instructions are hypothetically written so that students can follow them, there's IRC for help 14:36:06 yeah 14:36:06 but mostly I'm concerned with having folks set up a dev environment 14:36:20 so maybe that's "install eclipse and either the python or the docbook plugin for it" 14:36:30 (oh wait, that should already be on the POSSE spin) 14:36:46 #action mchua make sure dev tools (eclipse, docbook/python plugins) part of POSSE remix 14:36:49 s/spin/remix 14:37:19 * ctyler has never taken to Eclipse. Loves what it does, likes the concept, can't bear using it. 14:37:35 * mchua is a minimalist text editor person herself 14:37:41 +1 14:37:42 ...ok, so maybe not so much Eclipse. 14:37:52 Still good to have on the remix! 14:37:53 But anyway. 14:37:56 indeed 14:38:08 ok, this page is going to take some editing, but I think we have a rough plan 14:38:15 ctyler: "make a working stick following the docs you just built, ask for help on IRC" == homework for Tuesday? 14:38:26 bonus: "Install the Activity you're thinking of working on, on the stick"? 14:38:26 sounds good 14:38:45 ok 14:38:56 let's step back for just a moment 14:38:56 #info Tuesday's homework: burn yourself a working SoaS stick; if you want to do more, install whatever Activity you want to work on 14:39:02 * mchua pauses! 14:39:09 I think that working in community is a big part of what we need to teach 14:39:28 including contributing back work instead of forking it, etc 14:39:37 So a couple of questions: 14:40:01 - how do we build this so that it's big enough that they need to lean on the community to get through it, 14:40:02 and 14:40:28 - how do we get them to plug their work into a review process so that they work with the community to get their stuff upstream 14:40:34 without killing them? 14:41:07 I bring this up now because I think it informs the design of the exercises 14:41:11 * mchua nods 14:41:25 so if we're having them update an activity 14:41:30 ctyler: So, the review process/community engagement that we're building for the Worcester POSSE is the Activity approval process for SoaS 14:41:31 they should send their patches upstream 14:41:33 * mchua nods 14:41:34 right 14:41:48 these are modifications, not new activities (probably), right? 14:41:55 Right, they're modifications. 14:42:04 so, for an Activity to get included in the next release (the F14-based one) of SoaS 14:42:07 it will have to fit some criteria 14:42:17 http://wiki.sugarlabs.org/go/SoaS_Activity_Criteria is the current draft, we'll solidify the criteria after May 18 14:42:23 so we should give the owners a heads-up that we'd appreciate their attentiveness during that week so that we can get quick review 14:42:27 * mchua nods 14:42:39 we're going to be preselecting a list of "good Activities to work on" based on responsiveness of maintainers 14:42:57 so thinking about that, make the changes Tuesday -> start review Wed -> chase review so changes can be incorporated by Friday? 14:43:03 and I am hoping that a few RIT teams who have made Activities will offer to be part of that (but only part, because they also need to learn about community engagement. ;) 14:43:10 * mchua nods. Review happens in two parts here, methinks. 14:43:34 there's review for each criteria - for instance, "get my python patch accepted by activity maintainer" 14:43:43 or "get this package review through Fedora" 14:43:52 and then there's the final "does this go into the SoaS kickstart file?" review 14:44:04 which is fast and can be done (just checking off criteria) anytime 14:44:12 and I (and pbrobinson and sdziallas) can all do that 14:44:25 ok 14:44:33 can we realistically do that in 2-3 days? 14:44:38 wed->fri 14:44:45 that was an issue last time 14:45:38 I think yes, though just 14:45:51 ctyler: well, each Activity will only need a subset of those things. 14:46:05 one might only need packaging and a wiki page created, for instance. 14:46:16 another might need some icons and a few bugfixes, then packaging. 14:47:21 Ok, so then I think the main deliverable on Tue should be having the mods ready for review for Wed AM 14:47:46 ctyler: wait, *Tuesday* night? 14:47:52 ctyler: they're still building their stick then 14:48:11 ctyler: maybe it's "look at the Activity you want to work on, and figure out what things remain to be done for it" 14:48:29 and doing those things on Wed? 14:48:40 ready for review Thu AM? 14:48:53 * ctyler notes that 1 week is *tight* 14:49:35 Yep. 14:49:50 ok 14:49:51 ctyler: it might be that we just get 1 or 2 Activities - as an entire team - through review, and that would be ok with me 14:50:06 if the end result is "one of the Activities that the RIT OLPC class did is going to ship on the next release of SoaS" 14:50:50 if 14 people get one activity through, then there's a large number of them that aren't doing anything 14:51:39 but I hear what you're saying 14:51:54 I wouldn't judge by results, I'd judge by process, though 14:53:05 meaning, I'd rather that 14 got engaged in the process even if they don't complete until later, than 4 got engaged and completed and 10 observed 14:53:20 * mchua nods 14:53:23 * mchua agrees 14:53:38 ctyler: all of this is "if it doesn't work out, it's ok" stuff 14:53:42 right 14:54:27 ctyler: so, I think we have Tuesday pretty much sketched out... getting code and building stuff is already a lot 14:54:29 so I think we're good on Tuesday? 14:54:31 right 14:54:48 #topic Wednesday 14:55:19 Bug/issue tracking, let's start with bz and zoom out from there (Trac etc) 14:56:14 ctyler: do you want to use package reviews as an example of bz then? 14:57:31 sure, I could do a few examples, e.g., code review in some projects, package review 14:58:15 ctyler: you do bugzilla, I'll do Trac (SL trac for an Activity)? 14:58:20 then Trac, because it's used for a number of docs projects and activities 14:58:22 right 14:59:24 for Morning B, I'm not sure what the parallel activity in Sugar space would be 14:59:39 Afternoon rather 15:00:02 perhaps... 15:00:33 I can take a look at a particular behavior in a SoaS spin and then drill down to find out where that behavior is coming from 15:00:41 ? 15:03:10 * mchua looking, thinking 15:03:48 ctyler: Yeah, I think we can figure out a simple UI patch - changing a string, if nothing else 15:04:02 * ctyler notes that navigating in a project is a fairly important skill, and one reason why we tend to take students into larger projects 15:04:10 ok, I'll work something up for that then 15:06:36 actually, Wed afternoon we should take them into doing their activity/doc mods 15:06:54 then the overnight would be completing that, and we'll get it into review on Thursday morning 15:07:24 #info Wednesday afternoon get into Activity/Doc mods, homework is to complete that, get into review on Thursday morning 15:07:37 #info Wednesday morning: Chris leads bz overview, Mel leads Trac overview 15:08:07 ctyler: another thought is to do a simple UI patch on liveusb-creator 15:08:31 which is more cross-platformy and perhaps easier to build/navigate than Sugar itself (which... jhbuild... painful... *wince*) 15:08:34 and Luke will be right there. 15:08:52 true 15:09:05 though how much time do we need to kickstart them on their mods? 15:10:31 ctyler: Depends on the mod - I think for the most part they will be fairly simple code/text edits, so as long as they know how to build and test, we can help with the rest over IRC. 15:10:51 ctyler: I would imagine patches to be stuff like "expand and clarify this section of the documentation" or "please fix this simple Python error" 15:12:21 ok, so let's do a liveusb-creator mod in the early afternoon, then get them started on their mods the last part of the afternoon 15:12:27 so they have a headstart on their overnight 15:12:41 which is to have their mods ready for review for Thu AM 15:13:04 #info Wednesday afternoon part 1: liveusb-creator mod 15:13:13 #action lmacken prepare for liveusb-creator mod exercise 15:13:29 (I think we can just say "Luke, that's your job this week" and he has if nothing else Monday and Tuesday to figure it out) 15:13:41 #info Wednesday afternoon part 2: get started on your Activity mods 15:13:50 #info Wednesday homework: finish your Activity mods 15:14:05 ctyler: do we need to teach them about patches on Wednesday too, or can we do that real quick start of Thurs? 15:14:13 "you have it working on your machine, yay! now get it working on others" 15:14:20 mchua: actually, we want someone !lmacken to do the liveusb-creator mod 15:14:23 ctyler: (I have to run in 15m, may need to hustle through thurs) 15:14:25 and patches belong on Wed 15:14:28 ctyler: ...you mean the walkthrough? 15:14:34 #info Wednesday: learn how to make a patch 15:15:16 he knows the code, we want to demo navigating a scary blob of code you've never seen before in your life 15:15:48 ctyler: I would be happy to be a confused hacker if you can poke scaffolding questions at me. :) 15:16:20 * mchua is actually a worse python hacker now than when she was a student and is easily confuzzled 15:16:53 mchua: you have to run, I should too soon. Let's make an action point of forking the pages and incorporating our changes so far, and do a follow-on to review that and work out Thu/Fri 15:17:19 ctyler: I can take that #action on at lunch today. 15:17:26 #action mchua fork pages and incorporate schedule changes so far 15:17:31 ctyler: when's good to come back to this? 15:17:42 * mchua is open tomorrow morning, booked most of the rest of tonight though 15:17:58 how about Thu afternoon ~1ish? 15:18:17 #info we want smoeone who isn't Luke to drive the liveusb-creator stuff, goal is "how do you navigate unfamiliar giant blob o' code?" 15:18:24 ctyler: worksforme 15:18:55 #action mchua send out "finishing RIT POSSE curriculum Thursday at 1pm in #teachingopensource" email 15:18:57 ok, sounds good :-) I have FPB at 12 but we should be done by 1 or just after 15:19:00 * mchua nods 15:19:02 I'll be here 15:19:08 ctyler: Weds a wrap? 15:19:15 ctyler: if so, anything else we need to do today? 15:19:23 * mchua *really* appreciates you taking the time during the end-of-term rush to figure this out! 15:19:31 Wed sounds good, but let me mull the afternoon a bit 15:20:09 #info begin Thursday's meeting with a review of Wednesday afternoon, think about Wednesday in the meantime 15:20:14 thanks for meeting, see you Thursday. 15:20:17 * mchua nods 15:20:18 thanks ctyler! 15:20:24 #endmeeting