I’ve been having a difficult time getting organized and starting the big work on the next edition of the textbook. However, my recent calls for help have gained a fair amount of attention and multiple really good offers, so we are clearly underway again.

My goals in calling for this first sprint are to:

1. Start a writing rhythm for the team;
2. Take care of some administrivia (decide upon weekly work times, order of work, etc.)
3. Get some initial writing done that may still help the Teaching Open Source professors who are using parts of this textbook this school semester.

See you on IRC bright and early (for me) on Monday!  (This weekend is the end of daylight savings in most of North America.)

FSoC is a web-based tool for administering a student contributing program — handling proposals, commenting, automatic reminders, and so forth.

There is a running instance to look at, and we could get a similar instance running on a Fedora Infrastructure public test server.  We have a ways to go for it to be fully hosted by the Fedora Project, but why not try using it for the next session?

Please pass on the word. Anyone interested should join the mailing list to discuss it.  I’m available for direct questions.  Reach out, if you think you might be interested, I’d like the chance to talk with you.  Thanks.

One of the articles that comprise the book’s source is “Ten easy ways to attract women to your free software project“.  Actually, as Terry points out in the article introduction, nine of the ten ways are clearly useful for making your project more friendly for anyone and especially women.  That means implementing Terry’s ideas covers double — egalitarian attractiveness of the project while adding to the solution of the serious gender imbalance problem in free and open source software (FOSS).

There is a lot that makes this article great.  One part is the quality and quantity of research and supporting evidence.  I found the explanations of the different ways to support women instead of just men in a project to be very compelling.  I suppose some people might find it hard reading all of that, especially if it is the first time they have faced up to how easily a mono-culture arises when it is just men involved.

In reading over the points, I was very pleased that I see initiatives in the Fedora Project to address nearly all of the points there.  As the author points out, these ideas have been floating around.  I see projects such as Fedora have implemented them in a semi-haphazard fashion, partially because we haven’t had a guide.  I’m excited to have a chance to extrapolate these points in to The Open Source Way, as well as the Practical OSS Exploration textbook.

My only complaint about the article is the word “easy” in the title — I suspect that fell from the modern style of doing lists of how-to items as articles and blog posts.  I’m not sure that all of the items are easy, in fact I think changing an existing project to use a mailing list instead of a web forum would be a huge challenge.  My solution is to find ways to bring the forum up to the importance level of mailing lists, somehow.

But many people relish the opportunity to help someone solve a problem they didn’t even know they had, or did know but didn’t know who to turn to.  Or they have it solved, but in an unsatisfactory way.  That’s where the people who will knock on doors and explain things come in very handy.

We need help to find sponsors for the Fedora Students Contributing project.  (This has been called the Fedora Summer Coding project this past summer in the Northern Hemisphere.)

You get the opportunity to:

• Grow a coalition of organizations interested in the many opportunities a student contribution program brings everyone.  (Organizations such as corporations, K20+ schools, private- and public-interest non-profits, small government, etc.)
• Engage in a sales-like role, yet different criteria and stakes.
  • Stretch yourself!
  • Use skills you have already that aren’t exercised in FOSS projects!
• Take a significant role in growing a proven education program in a major FOSS project.

As existing resources:

• A five-year report that shows the value a student contribution program has had for Fedora, JBoss, and Red Hat.
• A first-run of the Fedora version of this program, with thirteen complete projects (eleven funded by sponsors.)  This includes the first student content contribution, the Fedora Musicians Guide.
• A generic presentation to quickly customize and use.  (Full notes available but incomplete, I’m in progress of finishing.  Will update this parenthetical aside when the notes are fully written in.)

Contact me directly or, even better, join the SIG mailing list and let us know your interest.

• 16 July our team loads up a mini-van and starts the 12+ hour drive to Portland, Oregon.  On the way we stop in Berkeley, CA to visit the wonderful folks at ZaReason.  Cathy and Earl, our proprieters, are loaning me one of their snappy new (and shiny red!) Terra HD almost-mini-notebook.  I’m giving it a full test run under Fedora for a number of reasons.  Personally, I want to see what life is like on a modern, small notebook; I’ve always been a “bigger is better” laptop selector (for myself.)  I also want to see how this system, loaded with stock Intel components, handles Fedora 13 and maybe rawhide (Fedora 14 to be.)  This also gives me a chance to help iron out any kinks in delivering Fedora on these systems, if any arise.  I’ve long been a fan of ZaReason’s approach to supplying systems to Linux users, they’ve clearly developed a following, and it’s great to see them reaching out to Fedora users with pre-installation and so forth.
  • The trip north is simply epic, with the Bay Area, Central Valley of California, Mt. Shasta, the Siskyous, and the Willamette Valley of Oregon.  Beautiful country, awe inspiring.  It is great to show it to some folks for their first time.
  • We arrive pretty late to Portland where we hook up with Robyn Bergeron, who I get to meet in person for the first time; she’s very cool.  The hotel is very nice right in the middle of downtown, and we settle in to be as fresh-as-possible for CLS the next day.
• 17 July we spend at CLS, participating to various degrees.  My take of the Community Leadership Summit (CLS) community is that there are a number of large groupings you can lump attendees in to.  Some are very experienced online community membesr and leaders.  Some have taken that community leadership to add a production of some sort to the necessary, core social need of being involved.  Common products are free and open  source software projects, but those aren’t the only ones in evidence.   Some are a subtle mix of social and something tangible that still can’t be held in your hand.  Within those groupings are people who are new, experienced, and everywhere in between.  I don’t think these differences are clear to everyone attending, and I think they create some potential disconnect in terms of how the people coming to CLS interact.  Just something to expect in a rather new community, and dinner conversation spurs Max to write a blog post at my prodding.   I attend a few sessions:  “Moving beyond the mailing list“; “You suck or conflict resolution in your communities” (where we hear the advice to, “Just remove them from your mailing list,” when a poisonous person problem in e.g. the Fedora Project is much more complex).  I meet up with lots of old and new friends, make new friends and contacts, have a great lunch downtown at the food carts, and do my best to do my best.  We end the day with sushi served by model railroad, which finally makes me happy.
  • There are two incidents that happen that day, one I observe that makes me feel very uncomfortable while it is happening, and the other I hear about a few days later.  Both happen in the morning plenary session, and both are disturbing instances of sexist behavior.  I think my blocking on writing about those has contributed to my not writing about the event overall.  I feel that my first real writing about this has to be to the CLS discussion list, because this is the community where the behavior happens and needs to be corrected.  At the moment, that is all that I’ve decided.  I’m still feeling that stunning and chilling effect that makes me want to go silent and pretend nothing is happening, all will be forgotten. Ick.
• Sunday 18 July starts out OK, although we are all a bit over-sleep-ish.  This morning I pitch a session to share about the community leadership handbook, The Open Source Way.  I give a good, thorough introduction, and try to illicit some feedback on what people need from such a book, as well as prodding them to use it as a canonical resource for the principles we are espousing all the time.  I also attend a few sessions, including  “You’re killing your community“, a wry look at why too much help can be harmful.  We end up having dinner at the top of Portland, at Portland City Grill overlooking everything, where happy hour yields us some nice food at a tasty price.  Late night Saturday and Sunday we pony up for some points-only poker, and I learn finally how Texas hold ‘em is really played.
• On Monday 19 July we head down to Oregon State University campus to meet with Drs. Tim Budd and Carlos Jensen.  The real and potential fall out from this trip are worthy of a separate blog post, and I think I’m going to write an article on it for opensource.com.  The summary is, I’m seeing an inverse mirroring relationship between the goals and methods of FOSS and academia.  It opens some really cool possibilities.
  • Also cool, for the rest of the week I get to meet multiple graduate students from OSU working on research that is useful and can make a difference: gender equality; enormous lack of joining and engagement; and so forth.
• Monday night is the Teaching Open Source education bird’s of a feather mini-session, and I get to meet even more interesting people.  Then I head back to Corvallis to …
• … spend Tuesday with a friend and his family.  I head back to Portland in time to help with booth setup, then back to the hotel where I’m surprised by the kids and Larry showing up earlier than I expected. Yay!  Food is sought, then bed.
• Early Wednesday I’m up to finish my part on the final slides Mel and I are using this morning at 10:40, “5 FOSS in Edu Projects That Changed the World“  All goes fine in our talk, it is actually pretty good, and the day is a bit more relaxing after that.  We work the booth and hang out in the expo hall, make trouble, and talk lots of stuff to lots of people, especially teaching open source (TOS) stuff and the open source way stuff.
  • Wednesday night I dip to an Android hands on, which includes my own Nexus One handset to start developing on and such.  Thanks Google, and thanks Tim Bray for organizing the session along with the awesome crew from Google.  My girls are going to be very jealous when I get back to the hotel room.
• Thursday we try to just improve on Wednesday, including getting one or two mini-talks going at the Fedora booth.  Lots more TOS talk, I have lunch with an old friend and colleague (downtown food carts for the win again.)  Now that I’m with the kids, I take it pretty easy at night, heading back in to the hotel early and getting wicked tasty pizza delivered by bicycle for dinner from Old Town Pizza.
• Friday I’m up early again, having a morning adventure walk and finishing updating my slides (source and all OSCON materials) for my talk today, “Being a Catalyst in Communities: The Science Behind the Open Source Way“.  Very smooth talk, I’m happy with the updated slides and after giving the talk a few times this year, I’ve got a good stride with it; also, I don’t go over time.  Then we pack everyone up, load the kids and Larry in the minivan, and head back south to Santa Cruz.  We arrive home about 3:30 Saturday morning, and here I am still.

We cooked up a poster and information packet you can read, use, and pass around.  It’s mainly about getting people to the main POSSE Cali page, then to apply.

Otherwise, we are looking for attendees.  If you know any educators or good networkers around education, please pass on the information.  We need to get more people, it makes it better for all involved.

We’re having the West Coast’s first POSSE this 5 to 9 July in Mountain View.  I’ll be there as an instructor, as well as Alolita Sharma from the OSI, and my colleague and POSSE co-founder Mel Chua.  If you come, you’ll learn about how to become productively lost, which is the key to navigating myriad free and open source software projects.

While you are thinking on that, think about these three reasons POSSE is attracting so much interest:

1. POSSE doesn’t solve all problems that academics face, but it works really well in a particular area.  If you plan to teach a class that includes open source development, or are even considering it, POSSE is the workshop for you.
2. The POSSE curriculum is very broad and applicable from the largest and most prestigious four-year research schools to two-year community colleges or even advanced science high schools.  This is because, like learning to ride a bike on city streets, we all need the same basic skills and experiences.
3. Being an alum of the class provides you hooks in to the POSSE community, which is at the crossroads that the Teaching Open Source project has been slowly occupying over the last few years.  This crossroads is where community leadership from the open source and academic communities are learning from each other and creating programs such as POSSE and the new textbook Practical Open Source Software Exploration: How to be Productively Lost, the Open Source Way.

Attendance is free, and you have to cover your own travel, meals, and lodging — one reason we do these regionally is to get a larger local draw so that more POSSE events can be held in the region as academics spread the word over time.

This week, Dr. Tim Budd at Oregon State University (and member of the Teaching Open Source community) began using the textbook for a class introducing FOSS programming and contributing.  We’re looking forward to getting feedback from the students.

Being a 0.8 release, it has a few bugs (formatting, mainly, but also some links in one chapter); I’m planning a 0.8.1 update over the next few days.  (The build broke while I was doing the final push out the door, so we had to ship what was published as 0.8 for students to start using.)  As a collaborative writing project, each of us focused on one or more chapters, and cross-edited for each other.  Greg DeKoenigsberg is lead writer and editor, and writing/editing was also done by Chris Tyler, Matt Jadud, Jeff Sheltren, Max Spevack, Mel Chua, and myself.  (I wrote/remixed the chapter on documentation, “Explaining the Code“, with source from Mel Chua and Lana Brindley. You can view the history of the wiki source/upstream for an idea of how it evolved.)  Jared Smith helped me with the wiki2xml conversion.  We used the ‘mw-render’ command from the ‘python-mwlib’ package, using the techniques we created for Fedora Project Docs Team.  (Thanks Paul for getting that package fixed in the nick of time.) It still needed manual clean-up for the final 0.8, but the automagic conversion does the heavy-lifting and gave something we could build with after only a little clean-up.  I converted all that to a Publican-based book, including creating a new branding package ‘publican-teachingopensource‘ using ‘publican create_brand’.  Working with Publican was a total pleasure.  It has matured nicely as a toolchain and is available for other Linux distros and other operating systems. I thank it for a good source package that I’ll be submitting as my first Fedora package.  (More on Publican in another post.)

Where Wikipedia is a useful information source and starting place for deeper exploration beyond it’s reference-focused world, there is so much more that can be done with it to help teach the open source way.

In fact, you can teach all of the basics of joining a collaborative free and open source software community without ever getting more technical than how to get an account and edit a wiki page.

Here’s the process I would follow, in a US-based classroom.  You can adopt to fit in your environment.  This is applicable to all age levels – I’d encourage six-year-olds to define a good Summary log message and click the Save page button.  A good reference is the Wikipedia article on creating your first article.

1. Use Wikipedia as a tool for learning the open source way by extending your use as a research tool.  In other words, let the work be topic driven and associated with your other lessons.  For this procedure, consider the example of a class studying their local watershed.  When researching with the students, use Wikipedia as a resource to understand the larger elements of the topic, such as what a drainage basin is, how topology affects the local watershed, what hydrology is, and what are the laws about protecting watersheds and wetlands.
2. The first thing you can simply draw attention to is that the page for “Watershed” on Wikipedia is a disambiguation page.  It’s purpose is to guide you to other pages because the term you were looking for is ambiguous in usage, that is, it has multiple meanings that each have a separate Wikipedia article about them.  You can point out that this is a collaboratively done page.  Both the history page and the discussion page are rich with information about who wrote the page, when it was done, and snippets of why it was done.  (This is where a good guide to Wikipedia for participants is useful, to help the teacher learn more about what history and discussion pages, for example, are for, how they work, why they matter, etc.)
3. As you proceed through research using Wikipedia, look for and explain these items to the students:
   1. Red links – these are pages that do not exist yet, meaning there is information to link outward to from the article you are reading, but that Wikipedia page doesn’t exist yet.
   2. Mistakes, such as typos, spelling, and grammatical errors.
   3. Unclear or overly complicated writing.
4. The first contribution from the class is likely to come from finding and fixing mistakes or helping improve writing:
   1. When a mistake is spotted, do something about it right away.  Login as your user (read more below), note for the class that you are logged in with different links in the upper right corner, and click [edit].  Make the fix to the page, and when saving include a short but detailed Summary such as:  “Fixed spelling of a few words and corrected punctuation mistakes, all spotted by students in my 2010 6th grade science class at Branciforte Middle School, Santa Cruz, CA.”  When you save this message, it is logged with the edit and that information, which is retained forever.  Twenty years from now, your students can look up the work you did together on Wikipedia long after they have discarded the work they brought home from class.
   2. For helping to improve writing, you want to defer the committing of changes to the live page to the people who write and maintain the page regularly.  This is one of the purposes of the discussion page that each article in Wikipedia has.  Use that link and edit the resulting page.  For example, to add a new section to the [[Talk:Hydrology]] page, click on new section and fill out the form.  Give it a sensible subject, such as “Fix for confusing paragraph in the history section.”  In the body of the form include an explanation of the problem (why it is confusing), a fix (your rewritten-with-the-students’-help draft), and your signature (four-tilde characters ~~~~ are used to sign and datestamp automatically.) Save this new section. Main writers of the page will return and read your new section, comment on it or make the fix, and so forth.  When they are done with it, they likely move it to an archive page.  Check back with our students to see progress on your discussion topic.
5. Once a class has witnessed the power of editing a wiki, and had the pleasure of showing the change to friends and family, they are ready for the next level, which is creating a new page.  This is where the red links come in, which are put there by other authors of Wikipedia partially as reminders, and partially as an invitation to write the page yourself.  For example, the [[Hydrology]] page has a prominent red link at the top to [[water chemistry]].  Following that link gives you an empty page ready to fill.
   1. A good first goal is to create a nice stub page with a basic definition of the article topic, and a reference to back-up the definition.
   2. To be safe and sane, you’re going to actually build the initial page in [[User:Yourusername/Water chemistry]], then rename it to [[Water chemsitry]] when is is ready.
   3. Start by copying the structure, categories, and so forth from the page source of the [[Hydrology]] page, viewable together by clicking edit for the whole page.  Empty the content, rename sections, and make it a template ready to fill with information about water chemistry.
   4. Find out the markup to put in the page that notes it is a stub page, a draft, and needs references.
   5. This is an opportunity to show research beyond Wikipedia, since the original information sources must be found to use for populating and referring on the new Wikipedia page.
6. Once a new page (article) has been created, and shown widely, the class is ready for considering several new ways to participate:
   1. Continue to watch and work on the articles the class created as article maintainers.
   2. Write up a new Wikipedia article (more than a stub).  For example, if there are unique properties to your local, named watershed and no corresponding Wikipedia article, you may think it is notable and should have an article.  Divide the class into small groups and have them research and write each section of the new page.  References are important, etc.  Essentially, this is a written report but the report becomes a Wikipedia article.
   3. Define and work on a set of articles.  For example, your local watershed may be part of a larger watershed system in your state.  An entire class semester could be spent researching and writing a series of articles to cover the larger watershed system and the individual components of it.

Teachers need a Wikipedia account, with a user profile at [[wiki/User:Username]].  You can make all the changes in Wikipedia on behalf of your students to provide anonymity to individuals and put the aggregate class work under a single copyight holder. The profile should keep track of the general information about the class(es) the teacher has contributed from, such as “Alan Parsons Project Middle School 6th Grade Science”.  This is part of showing other Wikipedia people who you are and what you intend to do so that you have their support as you continue using Wikipedia as a lesson in the open source way.  It also helps create the record of the class’ work, for example, when students are applying to schools later and want to show the work they did.

This is a very short guide to this idea, really just a starting point.  I could see this being a longer document, including step-by-step for the teachers on joining and learning about how to contribute to Wikipedia.  Let me know if it helps, how it could be improved, or if there is another free content work covering this content I could support instead.  Or should it be a Wikipedia article …?

• Use MediaWiki for writing long works and want to see how it is to convert to DocBook XML.
• Want to know more about using DocBook XML and the Publican publishing toolchain.
• Enjoy watching people edit XML like mad.

We’ll meet Friday 26 March starting at 1400 UTC in #teachingopensource on irc.freenode.net (or WebUI at http://webchat.freenode.net/?channels=teachingopensource) and continue through the weekend until done.  Full schedule and participation details are on the Teaching Open Source wiki.

As part of the work of giving college/university-level educators the experiences and tools they need to effectively teach participation in free/open source software projects, we’ve been working on a textbook.

http://teachingopensource.org/index.php/Textbook_Roadmap

The textbook, “Practical Open Source Software Engineering”, is releasing a first functional version, 0.8, this coming Monday 29 March.  The goal is to see it in use in at least one classroom this spring, which we’ve been discussing on the Teaching Open Source mailing list.