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