14:05:36 <mchua> #startmeeting 14:05:36 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:05:39 <mchua> #chair ctyler 14:05:39 <zodbot> Current chairs: ctyler mchua 14:05:44 <mchua> #meetingname POSSE RIT curriculum 14:05:44 <zodbot> The meeting name has been set to 'posse_rit_curriculum' 14:06:10 <mchua> #info our tech guru is Luke "lewk/lmacken" Macken, Python ninja of TEH AWESUM 14:06:20 <mchua> #link http://teachingopensource.org/index.php/POSSE_RIT#Topic_Schedule 14:06:51 <mchua> #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 <ctyler> mchua: what are our goals here? s/Mozilla/Sugar/ and leave in most of the Fedora bits? 14:07:08 <mchua> #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 <mchua> ctyler: Yes. 14:07:26 <mchua> 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 <ctyler> mchua: there's non-technical and non-technical :-) what level of non-technical are we talking about here? 14:08:55 <ctyler> Reason I ask is that ... 14:09:49 <ctyler> non-devs/non-admins can make packages, but you have to know your way around paths etc. 14:10:04 <ctyler> (as one example) 14:10:33 <mchua> 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 <ctyler> ok, perfect 14:10:50 <mchua> They're folks with some exposure to free software (Drupal, etc) on the publishing end of things, just non-devs. 14:11:02 <ctyler> right. 14:11:12 <ctyler> ok, shall we go day-by-day through the schedule? 14:11:18 <mchua> Worksforme. 14:11:21 <mchua> #topic Monday 14:11:30 <mchua> I think Monday is pretty much set, really. 14:11:33 * ctyler switches to larger screen 14:11:55 <mchua> 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 <ctyler> even there we should alternate probably 14:14:19 <ctyler> in the first bit, do you want to lead the timeline? 14:14:38 <mchua> ctyler: Can do. 14:15:13 <ctyler> Actually, if I can recommend, let's lay out the topics, and we'll do the divvy-up later? 14:15:33 <mchua> Sure. 14:15:41 <ctyler> Let's s/Mozilla/Sugar/ there, otherwise I think Monday is good 14:15:54 * mchua makes that edit now 14:15:58 <mchua> ctyler: onwards to Tuesday? 14:16:14 <ctyler> Did the "physical wiki" status check thing have value in your opinion? (the migrating post-it notes) 14:16:34 <mchua> ctyler: I liked it, personally. I do think it had value. 14:16:41 <mchua> It's easy to set up, easy to ignore if it doesn't work this round. 14:16:52 <ctyler> Or should we do rose-thorn-bud or some other approach? 14:17:33 <ctyler> (not that they're mutually exclusive) 14:17:40 <mchua> 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 <mchua> and we'll have a lot more people to track this time, so I can see that being useful. 14:18:05 <ctyler> ok 14:18:34 <mchua> #agreed repeat of 2D sticky note skillz tracker 14:18:41 <ctyler> #topic Tuesday 14:18:43 <mchua> #agreed rose-thorn-bud wrap-up feedback on Friday 14:19:04 <mchua> Right, so getting source. Source for what? 14:19:15 <mchua> Also, I'd like to nix the packaging stuff this time, in favor of... something else. 14:19:24 <ctyler> wait a second, we should fork the day pages 14:19:38 <mchua> ctyler: #action and I'll do it after the meeting 14:20:03 <ctyler> #action mchua to fork day pages 14:20:22 <mchua> 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 <mchua> 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 <ctyler> 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 <ctyler> even docs folks have to grab tarballs sometimes :-) 14:21:32 <mchua> ctyler: bonus is that RIT students have written Activities that are relatively close to what we need. 14:21:47 <mchua> ctyler: yep :) +1 on multiple ways of Getting Source. 14:22:00 <mchua> I also want everyone to learn *some* form of VCS. Git, likely. 14:22:16 <ctyler> 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 <ctyler> yes, let's go Git. according to some reports, it has a 60%+ market share 14:22:54 <mchua> "everybody had a southern accent, they kept telling me to git" 14:22:59 <mchua> #agreed our VCS of choice is git 14:23:06 <ctyler> and better to teach distributed vs central model, given the choice 14:23:08 <mchua> Yes. 14:23:25 <mchua> ctyler: We've got the textbook as a resource this time if we need it, btw. 14:23:31 <ctyler> right 14:23:42 <mchua> #info Getting source: make sure to teach tarball, RPM, versions as well 14:23:50 <mchua> #info remember: we have a textbook this time, if we want! 14:24:07 <mchua> ctyler: my main question is, "are Sugar activities the codebase we want to have them work in for this time?" 14:24:14 <ctyler> so Morning A, let's do tarballs, RPMs, and fetching from a Git repo 14:24:18 <mchua> because if not, we need to figure out what is 14:24:30 <mchua> #info Tuesday morning: tarballs, RPMs, fetching from git repo (vcs 101) 14:25:10 <ctyler> 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 <mchua> ctyler: Agreed on both counts, I'm struggling to think of alternatives though. 14:26:29 <ctyler> +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 <mchua> 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 <mchua> #agreed Publican will be the build system we teach to non-developers 14:27:06 <ctyler> though I don't want to split into devs and non-devs! 14:27:09 <mchua> 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 <mchua> ctyler: Yeah, nor do I. Hm. 14:27:28 <mchua> 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 <mchua> 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 <ctyler> 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 <ctyler> mchua: I haven't been following the sugar packaging stuff, what was finally decided about how activities would be packaged? 14:29:07 <ctyler> are they RPMs or not-RPMs? 14:29:20 <mchua> 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 <mchua> ctyler: RPM 14:29:29 <mchua> ctyler: Well, for Sugar on a Stick, RPM 14:29:32 <mchua> ctyler: we're a Fedora Spin 14:29:33 <ctyler> ok 14:29:52 <mchua> ctyler: It makes a lot of things way easier, being a spin. Also, we know what spins/kickstarts/etc look like. 14:30:00 <mchua> (and I now know how to update spin webpages, w00t) 14:30:00 <ctyler> right, but Moz extensions are installed on Fedora all the time, and they're not RPMs ;-) 14:30:06 * mchua grins 14:30:07 <mchua> true 14:30:46 <mchua> Well, ok - Tuesday morning they're learning how to grab source, use git 14:31:01 <ctyler> 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 <mchua> 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 <ctyler> 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 <mchua> so that might fit nicely. 14:32:40 <ctyler> perfect 14:33:03 <mchua> #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 <mchua> 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 <mchua> (that should give us plenty of documentation/process bugs to fix the next morning...) 14:34:11 <ctyler> yes, but yikes 14:34:19 <mchua> I expect everyone to make it through the first 14:34:24 <mchua> and maybe half the people to make it through the second 14:34:53 <ctyler> mchua, you're setting a pretty steep curve for non-technical users here 14:35:02 <ctyler> even for technical ones 14:35:07 <mchua> oh, hm. 14:35:20 <ctyler> build + spin + VM is quite a bit for overnight 14:35:25 <mchua> how about just "get a working stick?" 14:35:56 <mchua> the creation kit instructions are hypothetically written so that students can follow them, there's IRC for help 14:36:06 <ctyler> yeah 14:36:06 <mchua> but mostly I'm concerned with having folks set up a dev environment 14:36:20 <mchua> so maybe that's "install eclipse and either the python or the docbook plugin for it" 14:36:30 <mchua> (oh wait, that should already be on the POSSE spin) 14:36:46 <mchua> #action mchua make sure dev tools (eclipse, docbook/python plugins) part of POSSE remix 14:36:49 <mchua> 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 <ctyler> +1 14:37:42 <mchua> ...ok, so maybe not so much Eclipse. 14:37:52 <mchua> Still good to have on the remix! 14:37:53 <mchua> But anyway. 14:37:56 <ctyler> indeed 14:38:08 <ctyler> ok, this page is going to take some editing, but I think we have a rough plan 14:38:15 <mchua> ctyler: "make a working stick following the docs you just built, ask for help on IRC" == homework for Tuesday? 14:38:26 <mchua> bonus: "Install the Activity you're thinking of working on, on the stick"? 14:38:26 <ctyler> sounds good 14:38:45 <ctyler> ok 14:38:56 <ctyler> let's step back for just a moment 14:38:56 <mchua> #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 <ctyler> I think that working in community is a big part of what we need to teach 14:39:28 <ctyler> including contributing back work instead of forking it, etc 14:39:37 <ctyler> So a couple of questions: 14:40:01 <ctyler> - 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 <ctyler> and 14:40:28 <ctyler> - 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 <ctyler> without killing them? 14:41:07 <ctyler> I bring this up now because I think it informs the design of the exercises 14:41:11 * mchua nods 14:41:25 <ctyler> so if we're having them update an activity 14:41:30 <mchua> 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 <ctyler> they should send their patches upstream 14:41:33 * mchua nods 14:41:34 <mchua> right 14:41:48 <ctyler> these are modifications, not new activities (probably), right? 14:41:55 <mchua> Right, they're modifications. 14:42:04 <mchua> so, for an Activity to get included in the next release (the F14-based one) of SoaS 14:42:07 <mchua> it will have to fit some criteria 14:42:17 <mchua> http://wiki.sugarlabs.org/go/SoaS_Activity_Criteria is the current draft, we'll solidify the criteria after May 18 14:42:23 <ctyler> 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 <mchua> we're going to be preselecting a list of "good Activities to work on" based on responsiveness of maintainers 14:42:57 <ctyler> so thinking about that, make the changes Tuesday -> start review Wed -> chase review so changes can be incorporated by Friday? 14:43:03 <mchua> 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 <mchua> there's review for each criteria - for instance, "get my python patch accepted by activity maintainer" 14:43:43 <mchua> or "get this package review through Fedora" 14:43:52 <mchua> and then there's the final "does this go into the SoaS kickstart file?" review 14:44:04 <mchua> which is fast and can be done (just checking off criteria) anytime 14:44:12 <mchua> and I (and pbrobinson and sdziallas) can all do that 14:44:25 <ctyler> ok 14:44:33 <ctyler> can we realistically do that in 2-3 days? 14:44:38 <ctyler> wed->fri 14:44:45 <ctyler> that was an issue last time 14:45:38 <ctyler> I think yes, though just 14:45:51 <mchua> ctyler: well, each Activity will only need a subset of those things. 14:46:05 <mchua> one might only need packaging and a wiki page created, for instance. 14:46:16 <mchua> another might need some icons and a few bugfixes, then packaging. 14:47:21 <ctyler> Ok, so then I think the main deliverable on Tue should be having the mods ready for review for Wed AM 14:47:46 <mchua> ctyler: wait, *Tuesday* night? 14:47:52 <mchua> ctyler: they're still building their stick then 14:48:11 <mchua> 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 <ctyler> and doing those things on Wed? 14:48:40 <ctyler> ready for review Thu AM? 14:48:53 * ctyler notes that 1 week is *tight* 14:49:35 <mchua> Yep. 14:49:50 <ctyler> ok 14:49:51 <mchua> 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 <mchua> 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 <ctyler> if 14 people get one activity through, then there's a large number of them that aren't doing anything 14:51:39 <ctyler> but I hear what you're saying 14:51:54 <ctyler> I wouldn't judge by results, I'd judge by process, though 14:53:05 <ctyler> 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 <mchua> ctyler: all of this is "if it doesn't work out, it's ok" stuff 14:53:42 <ctyler> right 14:54:27 <mchua> ctyler: so, I think we have Tuesday pretty much sketched out... getting code and building stuff is already a lot 14:54:29 <ctyler> so I think we're good on Tuesday? 14:54:31 <ctyler> right 14:54:48 <ctyler> #topic Wednesday 14:55:19 <ctyler> Bug/issue tracking, let's start with bz and zoom out from there (Trac etc) 14:56:14 <mchua> ctyler: do you want to use package reviews as an example of bz then? 14:57:31 <ctyler> sure, I could do a few examples, e.g., code review in some projects, package review 14:58:15 <mchua> ctyler: you do bugzilla, I'll do Trac (SL trac for an Activity)? 14:58:20 <ctyler> then Trac, because it's used for a number of docs projects and activities 14:58:22 <ctyler> right 14:59:24 <ctyler> for Morning B, I'm not sure what the parallel activity in Sugar space would be 14:59:39 <ctyler> Afternoon rather 15:00:02 <ctyler> perhaps... 15:00:33 <ctyler> 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 <ctyler> ? 15:03:10 * mchua looking, thinking 15:03:48 <mchua> 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 <ctyler> ok, I'll work something up for that then 15:06:36 <ctyler> actually, Wed afternoon we should take them into doing their activity/doc mods 15:06:54 <ctyler> then the overnight would be completing that, and we'll get it into review on Thursday morning 15:07:24 <mchua> #info Wednesday afternoon get into Activity/Doc mods, homework is to complete that, get into review on Thursday morning 15:07:37 <mchua> #info Wednesday morning: Chris leads bz overview, Mel leads Trac overview 15:08:07 <mchua> ctyler: another thought is to do a simple UI patch on liveusb-creator 15:08:31 <mchua> which is more cross-platformy and perhaps easier to build/navigate than Sugar itself (which... jhbuild... painful... *wince*) 15:08:34 <mchua> and Luke will be right there. 15:08:52 <ctyler> true 15:09:05 <ctyler> though how much time do we need to kickstart them on their mods? 15:10:31 <mchua> 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 <mchua> 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 <ctyler> 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 <ctyler> so they have a headstart on their overnight 15:12:41 <ctyler> which is to have their mods ready for review for Thu AM 15:13:04 <mchua> #info Wednesday afternoon part 1: liveusb-creator mod 15:13:13 <mchua> #action lmacken prepare for liveusb-creator mod exercise 15:13:29 <mchua> (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 <mchua> #info Wednesday afternoon part 2: get started on your Activity mods 15:13:50 <mchua> #info Wednesday homework: finish your Activity mods 15:14:05 <mchua> 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 <mchua> "you have it working on your machine, yay! now get it working on others" 15:14:20 <ctyler> mchua: actually, we want someone !lmacken to do the liveusb-creator mod 15:14:23 <mchua> ctyler: (I have to run in 15m, may need to hustle through thurs) 15:14:25 <ctyler> and patches belong on Wed 15:14:28 <mchua> ctyler: ...you mean the walkthrough? 15:14:34 <mchua> #info Wednesday: learn how to make a patch 15:15:16 <ctyler> 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 <mchua> 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 <ctyler> 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 <mchua> ctyler: I can take that #action on at lunch today. 15:17:26 <mchua> #action mchua fork pages and incorporate schedule changes so far 15:17:31 <mchua> 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 <ctyler> how about Thu afternoon ~1ish? 15:18:17 <mchua> #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 <mchua> ctyler: worksforme 15:18:55 <mchua> #action mchua send out "finishing RIT POSSE curriculum Thursday at 1pm in #teachingopensource" email 15:18:57 <ctyler> 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 <mchua> I'll be here 15:19:08 <mchua> ctyler: Weds a wrap? 15:19:15 <mchua> 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 <ctyler> Wed sounds good, but let me mull the afternoon a bit 15:20:09 <mchua> #info begin Thursday's meeting with a review of Wednesday afternoon, think about Wednesday in the meantime 15:20:14 <ctyler> thanks for meeting, see you Thursday. 15:20:17 * mchua nods 15:20:18 <mchua> thanks ctyler! 15:20:24 <mchua> #endmeeting