Posts that are fedora-ish
On the way from Boston to Raleigh this weekend, I stopped by Karl Fogel’s place for lunch (more accurately, a Mexican restaurant down the street from his place). We talked about life and a million other things, but one of our conversation topics was The Open Source Way.
The thesis we came up with over lunch is that the open source way, at its core, is two things that are really the same thing: (1) How to avoid being forked, and (2) how to fork a project properly.
The primary thing that makes a project ‘open’ is “is it forkable?” This goes into all the things the current book is already enumerating: is it licensed in a way that makes it permissible to fork? is the stuff that needs forking available so people can find it and fork it? and so on. The existing content in the book is, in a sense, “things you should do in order to ratchet up the number of points of your doing-it-right/no-fork! meter.” That last point was inspired by Spot’s failmeter, and the question of what the equivalent list is for non-software projects is still an open question.
For instance, public infrastructure… what does it mean to “fork,” say, a library? In the US, public libraries are commonplace and usually of high-enough quality that citizens are content enough not to fork it. In other countries, this system isn’t adequate, so private citizens have grouped together to make their own libraries and to share notes with each other on how best to “compile your own library,” so to speak. I think about Stian Haklev’s study of government-supported and independent reading gardens (libraries) in Indonesia as an interesting look at a system that has a lot of parallels to free software.
Or to take another example: homeschooling as a fork of the public education system. Karl pointed out that public schools take a variety of stances to this sort of “forking,” and that one of the friendliest things a public school could do is to make their offerings modular so that homeschooled students could, for instance, play on the sports team and take a pottery class but study math and Russian literature and history and so forth on their own. Modularity (and reusability) is also something we value in code in the FOSS world.
What other parallels can you think of? Does this framing of “how can a project in $discipline become more forkable” help think about doing things the open source way beyond the software realm?
Tuesday, August 31st, 2010 | fedora, teaching open source | 2 Comments »
Some of my Olin buddies (Sebastian Dziallas, Colin Zwiebel, Andy Pethan, and DJ Gallagher) are putting together their first Fedora event, a FAD focused on Etherpad deployment. Predictably, it’s called the Etherpad FAD. In preparation for this, Colin asked some questions about Fedora Infrastructure that I thought other newcomers might have, so I’m posting my responses here in the hopes that people can (1) correct me if I’m wrong, and (2) transfer this information somewhere else more useful (wiki?) if I’m right.
By the way, if you’re interested in Etherpad development or deployment and would like to participate in the event, get in touch with Colin Zwiebel and he’ll get you started. Packagers, js/scala/java developers, infrastructure folks, experienced Etherpad developers and deployers along with new folks who want to learn… we need all sorts of people! It’s in the Boston area, and some travel funding is likely to be available, or you can participate remotely (I’ll be pitching in remotely from Cape Town, South Africa). Again, get in touch with Colin and he’ll get you started.
Now for Colin’s questions…
How do things normally go up on Fedora Infastructure?
#fedora-admin. That’s why I was trying to point you there. :) Really, just catch me on IRC sometime and we’ll get your questions answered there in realtime.
Do you need someone to maintain the new installation?
Probably. :)
If so, what qualifications does that person need? How can we become/find that person?
How Fedora Infrastructure works in a nutshell: if you want something (say, Etherpad) deployed in production, it has to first move through publictest (“you’ve got root on this random box, experiment and break things and configure until you think you’ve got it right”) and staging (“now that you think you know what you’re doing, write us out detailed instructions on exactly how to replicate your setup, and we’ll see if your instructions can be automated”). Once it’s verified that you’ve got things in a state where they can be automatically and stably deployed, then you go into production, which is the “hurrah! it’s launched!” state that you’re looking for.
So the first step is getting access to publictest machines so you can play around. For this, you’ll want to get formally started with the Infrastructure team, as they are the ones who can grant access. http://fedoraproject.org/wiki/Infrastructure/GettingStarted is their getting-started page; you want to get sponsored, so you’ll want to read http://fedoraproject.org/wiki/Infrastructure/GettingSponsored, and the FIG (Fedora Infrastructure Group) you want is sysadmin-test, http://fedoraproject.org/wiki/Infrastructure/FIGs#sysadmin-test.
Once you get access to the sysadmin-test group, you should have root privileges on all of Fedora’s publictest machines; an admin in the #fedora-admin channel can tell you more about that. The next step after that is filling out an RFR (Request For Resources) as described in https://fedoraproject.org/wiki/Infrastructure/RFR and you’ll soon have root access to whatever sort of environment you need to set up things.
I think that’s it, but I’m going to blog this introduction to Planet Fedora to make sure I’m not steering you wrong, and also because the text may be useful for others getting started with the Infra team.
Tuesday, August 31st, 2010 | fedora, olin, teaching open source | 3 Comments »
From the latest Sugar on a Stick (SoaS) meeting minutes:
We spent most of our time on the next big urgent milestone: getting testable Sugar 0.90 images out the door for upstream Sugar QA. This isn’t an official SoaS release, but since SoaS is an easy way to get an instance of Sugar up and running, it’s great for testing, and since we’re going to include the 0.90 release of Sugar anyway, Simon has asked us to include it in our test builds by a certain date so it can be used to test the Sugar environment itself. By “certain date,” I mean that the 0.90 Beta release is this Wednesday; here’s what has to happen preferably before then. (For the Fedora folks in the audience, SoaS is a Fedora Spin.)
- Simon updates the sugar, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork, telepathy-gabble and telepathy-salut packages in Fedora to the correct code versions.
- Mel gets 3 people to test these packages and give them karma in Fedora’s system, which will put them in the stable repositories. I’ll be writing instructions on how to do this shortly.
- Simon or Peter or someone takes the next daily build and makes sure it boots, then announces the test image.
What this means for you, o reader: if you run Fedora (or can run Fedora in a VM, or can follow written instructions on how to do exactly this), you (yes, you!) can help us with 0.90 testing this week. We’re going to have instructions for this coming out once the code is ready to be tested; it should take less than 2 hours (hopefully less than 1) to do your setup and testing from start to finish, and you won’t need any prior experience. We’ll be using the same test setup for Sugar in the future, too.
The catch is that because we’re under intense time pressure to meet release deadlines, the time between when we can say “we’re ready! We need help!” and when we need the testing finished by is going to be VERY short. So this is a heads-up letting folks know this call is going to be coming.
Stay tuned for more QA news in Sugar land! (dun dun DUNN!)
This blog post written under more sleep deprivation than is probably good for me. I’m going to go to bed now so I’ll be more useful in the morning.
Monday, August 30th, 2010 | fedora, soas, sugar, testing | No Comments »
First of all, thank you to Kaio for translating my earlier blog post, and to everyone who’s responded – on the original post, the translation, IRC, and the Fedora Chinese mailing list – I’m about to fall asleep (jetlag) but will sit down and reply to everybody when I wake up tomorrow morning.
My schedule in China is starting to settle down a bit – I am in Beijing from today (Sunday) until Wednesday afternoon, and in Shanghai from Wednesday evening until Saturday morning when I fly back to the US. If you’re involved with or interested in Fedora or even FOSS in general, and you are in either of these two cities, I’d love to meet with you; propose times, dates, and locations and I’ll continue to blog here every day I’m in China.
Today I spent the afternoon with Gerard Braad and his wife Shan, who graciously helped with travel logistics (have you ever tried to book a hotel via a website in a language you don’t know?) showed me around Beijing and told me about their perspective on the situation. We have an overarching goal for this week: RAPTOR-PROOF FEDORA EFFORTS IN CHINA. What this means is that we need to spread and scale the knowledge here that we have about how to participate in the Fedora community so that if any one person is eaten by a raptor, the Chinese Fedora community is still ok. Right now, the burden lies on too few shoulders – so few that one person getting the flu could seriously bottleneck efforts the entire country. Clearly, this must change!
The major raptor-proofing problems we have identified, and potential solutions we’ll be working on
this week:
0. There is only one regional Ambassador mentor, so it is very difficult to grow Ambassador presence (and hence Fedora brand awareness) in China. Strong mentoring is particularly important here; Chinese culture is considerably from existing FOSS subcultures, so teaching new Ambassadors about upstream communication may take a lot of time and patience. Solution: identify and train multiple potential Ambassador mentors.
1. There are few materials (swag/media) in China. This includes things like t-shirts and LiveCDs, the latter being tremendously important in a country with slow download speeds, fickle connectivity, and firewalls. The price of manufacturing and distribution within China is very cheap, and the price (and difficulty) of importing them from elsewhere is very high, so it makes sense to make these things in-country, but it has been difficult for Chinese Ambassadors to get financial resources from Fedora. Solution: Get small quantities of physical media of all sorts (pens, stickers, CDs, etc) to China and have them duplicated; Chinese factories are fantastic at making copies, and it’s easier to hand someone an item to copy than to go back and forth with written specifications describing it. Also look into the state of the queue via which APAC Ambassadors are supposed to be requesting resources; who maintains it? Is it well-understood and publicized? Is there a clear process by which Ambassadors can find the status and expected response time of their requests?
2. The language barrier is a red herring. Yes, the Chinese-English language barrier makes things more difficult, and we should encourage and cultivate participation in (the various forms of) Chinese so people can work in their native tongue, and improve the cross-communications between the Chinese and English (and other-language) speaking parts of the Fedora community – BUT it’s not a blocker and we shouldn’t use it as an excuse. Solution: Set up opportunities to cross-collaborate between China and other regions, THEN use that existing collaboration to drive linguistic crossover, rather than always planning things the other way around. We’ll try to start with a MIPS FAD centered around Beijing; more on this later.
3. There are very few people in China with exposure to the open source way of doing things – there are many people with the technical ability to contribute, but few who know how to do that work in the context of a FOSS community and push their work upstream. Solution: See #2, with an emphasis on getting people to meet other strong contributors from outside their region. Can we bring some MIPS hackers from China out to January 2011’s Tempe FUDCon to present their work to NA contributors? Can we send EMEA Ambassadors to APAC events? Also, Ambassadors can focus on getting individual people started in the community; it’s easy to find, request, and use resources once you know it’s easy (people tend to have the ungrounded perception that it’s hard, because they don’t know what the process is).
Other topics on the table:
- Major dates for media availability in China: Software Freedom Day (September 2010) and F14 release day (November 2010). We’ll treat the first event as a test run for how to do media production in China, so the second one will be a simple “just do the same thing again” execution.
- Marketing and Ambassadors in China in general, and the relationship between the multiple groups and people involved in one or both.
- Fedora-zh community infrastructure hosting. Where can this be done? Right now, everything except the IRC channel (#fedora-zh) and mailing list is scattered in an undocumented manner across individual uncoordinated VPS accounts that cost a tremendous amount of money relative to the average Chinese salary, so it’s a fragile network that is in danger of disappearing with no backup.
- Getting introduced to existing Fedora contributors in the region, both online and in person, and trying to understand the network of contributors in China, and articulate the structure of that network and the culture it works within back out to the broader Fedora community, along with what work is being done here.
Thoughts? Other things we need to add to the agenda?
We’ll be in #fedora-zh (irc.freenode.net) all week if you want to talk or find out what’s happening in the region; I’m mchua and Gerard is gbraad, and there are plenty of others in the channel who can fill you in on what they’re doing as well. You don’t need to speak Chinese to hang out in #fedora-zh (I sure don’t!) There are many people there who understand English, and some of us also understand other languages as well, so please come on in and join us and lurk; we’ll be posting and logging conversations there throughout the week.
Sunday, August 1st, 2010 | fedora, fedora-zh | 7 Comments »
(If someone can translate and post this to the zh-language Fedora Planet, that would be awesome!)
I’m about to board a plane to Shanghai – I’ll be in China for a week devoting my time towards building up Fedora activities and presence in the region. If you’re in FZUG, in the area, or interested in the region, please let me know! I will be in #fedora-zh all week (I usually lurk there anyway) and trying to improve my (very basic) Mandarin skills, but will probably need a lot of translation help.
This trip was originally supposed to be a POSSE (more on that later) but that was unexpectedly canceled at the last moment – it’s actually a good thing, though, because we’ll have more of a chance to get to know what’s happening in the area.
One area I’m personally interested in is education, mostly at the college level – for instance, it would be great to see a POSSE (workshop for professors interested in getting their students involved as contributors to open source communities) in China sometime in the next two years, and I would love to talk with people about how we can make this happen.
However, my first priority on this trip are the Ambassadors and folks working on the ground for Fedora in the region. How can we do a better job of getting you resources, how can we get more publicity on Planet and Ambassadors-list regarding what is happening in the region? Do we have a lot of packagers, or translators, of $SKILLSET in the region that we should organize a FAD around? Who should we talk to? Where should we go? Do people want to meet up for dinner some evening?
In other words, what are Linux users in China passionate about, and how can Fedora help them? Blank slate.
Friday, July 30th, 2010 | fedora, fedora-zh | 6 Comments »
I promised Asheesh I’d write this post, though it’s coming a day late because I crashed through the 2nd day of CLS 2010.
What’s the balance between inclusiveness/accessibility and being able to use the best tools/formats available (in other words, not having to worry about whether everyone else is keeping up)? For instance, during the first day of CLS, I found myself zoning out a lot; as someone who can’t hear, it is extraordinarily hard for me to lipread multiple people in a conversation with background noise – should I have interrupted them and said “excuse me, I’m deaf… would you mind signaling when you’re about to start speaking so I know to lipread you?”
The issue is not that I should scratch my own itch, nor that it would not be an entirely unwelcome or unwarranted interruption and imposition on my part. I’ve been speaking up and making (and asking for) my own accommodations since I was a child. I fully admit that I’m frustrated and to some extent just venting/whining here, but my frustration is that there is that extra expectation that I must – and will – expend energy on rectifying this every time I’m at an event, and the incremental cost of doing so slowly chips away at my willingness to participate at all (because it “costs” me more than hearing participants to have the same level of participation). There is nothing I can do that will fix it permanently (if there were, I’d be more than willing to work my ass off for an extended period of time to make that happen) – things will always be this way, no matter what I do. And I am tired.
It’s like being told you need to pay a dollar every time you want to participate in a conversation. It makes you pause slightly about participating in that conversation at all, and even if the conversation isn’t that great, you’re more likely to reluctantly stick with it, because… well, you paid a dollar. Others will look at you and go “why don’t you just pay the dollar?” or “it’s only a dollar,” or “well, if you can’t even pay a dollar (you lazy bum) you shouldn’t be here” – and not recognize that it adds up. Say you have a dozen conversations each day, which is on the low side – you probably walk by many more in the space of an hour without realizing it (the questions on the bus? the chatter by the water cooler? the informal banter about the soccer game at lunch?) – that’s $4380 a year.
And you have to publicly put in your dollar. I have to stand up and tell people I can’t hear, and would they – graciously, please – accommodate me? Most folks are goodhearted and will gladly do so, but sometimes I don’t want to stand out. I don’t want to be labeled as deaf, because there are some associations that come with it that I find even more tiring. And offering to pay the dollar for me doesn’t really help, because you have to stand up and publicly say “hey everyone, I’m putting in a dollar for Mel!” which doesn’t help with the standing-out problem. So I just choose to opt out, and quietly slip out the back door and go away. Sometimes I come back. Sometimes I don’t.
I want to make this clear: I have no problem with paying the extra bill. I do so often. I stand up and ask often. I take a lot of extra, invisible effort to set up things (sitting in front so I can lipread, etc) so I don’t have to inconvenience others by asking whenever possible. But sometimes, when I’m tired, I wish there wasn’t that expectation. I wish I didn’t have to ask. I wish I could just be tired and not have to ask and have the world still work and have me be able to participate in it. I’ve expressed this kind of thing before. Multiple times.
Asheesh did a great thing yesterday: after we talked about this, we went to the next talk together and he started transcribing it in etherpad, in backchannel, in notes that everyone could see – including me. IRC transcriptions at the last FUDCon were a huge boon. One reason I’m so fluent in text-based communication channels is that it’s a part of the world where I never have to ask – I’m on equal footing by default. And I wish this could extend more to other parts of the world, even (especially) in tiny increments – my suitemates leaving captions and subtitles on in our lounge by default (I never asked for it, they never mentioned it) I am incredibly grateful for to this day. Small things like that – people understanding without you asking them to, and being able to participate in the tiny moments of life folks that people usually think “oh, this doesn’t matter” because they take it for granted.
I feel like I’m whining here, because I can’t propose a good solution – I’m just venting a frustration, and the frustration I’m venting is that I can’t think of a solution. But I promised Asheesh I’d give this voice, so here it is.
Thoughts?
I’m tired.
Monday, July 19th, 2010 | fedora, teaching open source | 4 Comments »
Are you or do you know a good Fedora contributor – an active, English-speaking member of any team, be it QA or Docs or Packaging – who’s interested in spending an all-expenses-paid week in Cape Town, South Africa getting university professors involved in the parts of Fedora they’re interested in?
Jan Wildeboer and I are teaching the first POSSE in EMEA from October 3-8, 2010 at the Cape Peninsula University of Technology, hosted by Michael Adeyeye of the IT department. POSSE is a one-week workshop for professors, usually in software engineering, CS, or a related discipline (technical writing, etc) who want to get their students involved as contributors in open source communities. They spend their POSSE week diving into the community as contributors themselves to give them a better idea of how to scaffold their students through the same learning experience.
The workshop is taught by 2 instructors who go over community dynamics and basic tools/skills (wiki editing, IRC, version control, etc) as well as considerations particular to educators (semester schedules, grading, picking appropriate student projects, etc). As the tech guru, you’ll be leading us in deep-dives into the work you do every day in Fedora, giving us a living example of how an experienced contributor thinks, ask questions, and improvises through the ever-changing FOSS world by being “productively lost.”
The fine print:
- We’d like a local contributor, so we’ll pay for your round-trip airfare within Africa. If you’re from outside the continent and you can get yourself in, we’ll take you the rest of the way.
- Your hotel and living expenses (food, taxi, etc) will all be covered.
- That’s it. Short fine print.
If you’re interested or know someone who might be, reply here or email posse at teachingopensource dot org with a description of why you’d like to come and your activities within Fedora, and we’ll get back to you shortly. And if you’re interested in seeing a POSSE for your FOSS project or at a school near you (or perhaps your alma mater), consider organizing a POSSE of your own!
Tuesday, July 13th, 2010 | fedora | 2 Comments »
I found this mailing list conversation snippet to be very insightful, and wanted to share it.
Scott: “Open to critique” isn’t quite the same as “responsive to critique”. From an outside perspective, it seems that frequently SugarLabs is just not listening to people who offer contrary opinions. This is better than flaming them, but maybe not as good as it could be. For an end-of-year report, I’d like to see instances enumerated where SugarLabs actually internalized some outside critique and responded in a positive way — some concrete change made to the UI, or Sugar, or to process. That would be more convincing that simply stating, “we are now open to critique”.
Bernie: We’re definitely intimidating to non-technical people. At least, this is what I sensed at the Realness Summit. OLE also seems to be doing a better job at connecting with educators. I’m not completely sure what corrective actions should be. We might need to do some work on the wiki, maybe add web forums, which non-geeks tend to prefer…
Scott: I suspect that the answer to this problem does not involve installing additional software.
Later in the day, Jeff and I were having this conversation on #teachingopensource.
Jeff: Is IRC really a barrier to entry? maybe I have simply been using it too long, but it seems immediately recognizable to me. I think one barrier might be the attitudes that crop up. Even with emoticons, sometimes it’s hard to discern intent. Hard enough in email, but sometimes devastating in real time.
Mel: Actually, yes. I had a really, really hard time figuring out IRC. First, figuring out that it existed and I had to use it. Then how to get it, how to set the software up. Then what the heck networks and channels and whatnot were – and why channels? my IM paradigm was “you have a buddy list and you ping people individually.” So “chatrooms are the default!” wasn’t hard to understand once I realized it, but it took a while to realize because I wasn’t looking for it.
And then “oh man, who are all these people? I am nervous about pinging them, will they yell at me?” And then all the /commands I had to remember. It was so bewildering and terrifying and new and it was being used as a way to present new information to me at the same time, sort of like… taking your first calculus class in… Mandarin, if you’ve also just started studying Mandarin as a foreign language. You can’t concentrate much on the calculus because you’re going “zomg it’s in CHINESE.”
It’s hard to remember how hard things can be, especially when you’re surrounded by a community of people who are the ones who self-selected and made it past that hardness. By definition, if you’ve gotten into FOSS, the current participation mechanisms worked for you… so why fix them?
Because we want others to join us.
Tuesday, July 13th, 2010 | fedora, olin, olpc, sugar, teaching open source | 9 Comments »
Notes I wrote up months ago that have since been found by others to be useful. Posting for posterity. Basically, these instructions are for how to set up an always-on logger for IRC (chat) – helpful for being able to hear the conversations others are having about the project you’re working on while you’re away. I am assuming a fair amount of background knowledge here, but the content is remixable, so feel free to yoink/improve/etc.
1. ssh into the box you have an account on – for instance, Sugar Labs folks can use sunjammer (aka people.sugarlabs.org) by requesting an account at http://wiki.sugarlabs.org/go/Sysadmin/Shell_account_request
.
2. Run these commands (comments in parentheses).
screen
(a dialog will pop up, hit return to kill it)
irssi
(you’ll get a mostly blank screen, with a stripe across the bottom with the
time and a number [1] in brackets – that’s the window list – and then a line
below that with [(status)] in it, which is the description of the window that
you’re in, and the place you type the rest of the commands.)
/connect irc.freenode.net
(and then, if you want, /msg nickserv identify <password> to sign in.)
/set autolog on
(it’ll start storing things in ~/irclogs in self-explanatory filenames)
/join #sugar
(and whatever other channels you may want to be in)
(You’ll notice that every channel you join opens up another window – the first
channel will be in window 2, the next in window 3, and so forth. Use ctrl-p
(previous) and ctrl-n (next) to switch between windows, or alt-NUMBER to jump
to the NUMBERth window.)
(You’ll also notice that the numbers for each window light up in different
colors when someone joins/leaves a channel (blue), talks in a channel (white),
or calls your name in a channel (pink).)
(All the normal IRC commands work as expected, and so does tab-completion.)
(a note on /whois: if you have a PM window open for that person, the whois
information will appear in the PM window. Otherwise, it will appear in window
1.)
3. When you want to stop, do
/away <away message>
and then detatch from screen, which is
CTRL-a, d
(ctrl-a followed by d)
which will dump you in your normal sunjammer shell outside of screen.
Or you can just kill the terminal by typing
~.
or whatever.
When you log in again, restart the screen session with
screen -raAd
…and you’ll be back. If you then type
/away
…you’ll see all the messages sent to your nick in the meantime in window 1,
and you’ll be set to not-away.
4. More docs at http://www.irssi.org/documentation/startup
and http://quadpoint.org/articles/irssi
.
I mostly find irssi useful for being always-on all the time and having backlogs
of conversations that have happened while I’m away. It also means that anywhere
I have ssh, I have IRC.
Wednesday, July 7th, 2010 | fedora, sugar, teaching open source | 2 Comments »
I’m at a curriculum development workshop at Olin working on the design of POSSE. It is… well, let’s just say I think I understand what POSSE participants feel like (this is also a week-long faculty workshop; I’m the only participant who’s not a professor) – it’s an experience that’s making me see a world (in this case, curriculum design at universities) in an entirely new light, and finally starting to gain the ability to learn at the level I’d like to learn at… I’m nowhere near there, but I think this week is bootstrapping me up to the point where I can learn much of the rest by doing (a lot, for a long time – now I need a lot more experience). This workshop is giving me cultural context. Whoa.
Awesomeness of the day (one moment of many): running into Sanjoy Mahajan, an MIT professor who was my advisor for my humanities capstone on open content engineering textbooks. Sanjoy is also a FOSS geek, and he’s a visiting professor at Olin this coming year. Back in the day, we talked about software for writing textbooks. Turns out he kept working on it, and now one of his students has made an open source textbook writing software called nb – the code is actually under an MIT license, I’m told, but there’s no (easily findable) public repo of it yet, etc… we’ll fix that soon.
A Guided Tour of NB from Sacha Zyto on Vimeo.
Basically, it’s heatmapped commenting on textbooks in pdf format, inspired by the comment workflow on the GPL v3 draft back when it was a draft a few years ago. This way you can see at a glance where folks have commented, and how much, so you know what areas of the text you need to work on. See Sanjoy’s book, Street Fighting Mathematics, for an example of an annotated text.
How would this work in practice?
- source code: TeX
- compiler: LaTeX
- submit a comment/patch: write an annotation on the book using nb
- accept/push a patch: revise the upstream TeX, “recompile” the pdf in LaTeX
- forking: get the TeX source and build your own
- etc.
I don’t know how well it would work, but I’ll be poking the maintainer over the weekend, trying to get an instance of nb up, and then throwing the latest instance of the TOS Textbook up on it to see how that goes, just as an experimental “let us try this tool!” branch. Hrm. When… do I have free time? That is the hard part. If this works out, it would be amazing to have students in classes (Heidi and Tim, I’m looking at you) comment on the textbook as they’re using it.
Wednesday, June 30th, 2010 | fedora, olin, teaching open source | 1 Comment »
