Authoring the OER Handbook - Lessons Learned

Development of the OER mini-handbook for educators is an experiment in commons-based peer production, sensu (Benkler 2002, 2006). The project involves contributors from at least three continents so far.

What have we learned that might help others be more productive in such an endeavour?

Learning occurs on several levels including personal ergonomics, correct use of the technology (in this case MediaWiki and extensions in WikiEducator) and collaboration.

Lessons Learned

The following are learning points and tips from contributors to the handbook and others with related experience on other projects.

Personal Ergonomics

If you have a way of working which can be described by a "catchy" phrase, add it here. Wiki productivity patterns:

• Active pages in sight
• One browser

Project Planning

The larger the document, the harder it is to create a stable version. A Wikipedia article only has a few sub-sections, whereas the OER Handbook has multiple chapters and at least three subsections per chapter. Therefore, sweeping changes need to be discussed thoroughly before applying to the document.

Recommend using a the FLOSS model of development (Alpha, Beta, Version .5, Version 1.0). The document as a whole should be planned along these iterations. For example, the OER Handbook might change its organization and five other things for version 2.0. This system is not meant to preclude major revision or rewrites, but rather to steer these changes into a manageable timetable and process. Ideally, each stable version should be kept separately from the pages that are developing on an ongoing basis.

Organizing With Others in Mind

The OER Handbook was originally organized to make community contribution easy. Sections were broken down into short sections, to make the document more approachable to potential contributors. Production during January-March largely focused on getting as much content as possible on the wiki, so contributors would have something to edit, rather than expecting contributors to create content from scratch.

Soliciting Help

When soliciting help it is important to be as specific as possible regarding the purpose and scope of the project. It may be better to have some content prepared before asking for contributors. Doing research beforehand regarding who to solicit often pays off, because you can suggest specific areas for contribution. Personal e-mails are important, so potential contributors feel that they are valued.

Once someone has agreed to contribute, care should be taken with any contributions. Make sure the contributor feels that their contribution is worthwhile, even if it needs to be edited to fit the surrounding content better. Make sure they are thanked for their efforts.

Multiple Editors Coordination

The following might apply (affecting productivity): differences in writing style, terminology preferences, time zones, continuity issues, etc. In general, most issues may be solved by communicating with fellow contributors, and it can help to set up a few tools to structure this communication (e.g. central issue tracker and style guide below).

Time zone coordination requires some work. If the same contributors stay on long enough, a rhythm of editing will develop in which contributions can be anticipated and planned.

Continuity

Collaboratively writing books is not the same as collaboratively writing an encyclopedia (unless the book is an encyclopedia :-). One of the reasons for this is that it is easy to specify the general form of the encyclopedia and standards/conventions for articles. The articles are mostly relatively short and self-contained, and may be edited independently by different sub-communities of enthusiasts and experts on each topic, without having a significant effect on continuity.

For books, potentially with multiple volumes, parts, chapters and sections, it is important to have a selection of individuals responsible for continuity (within chapters, across volumes, etc.). Plan the work for the people assuming these roles, ensure they have the required overall perspective/ vision for the book, and have dedicated time to perform these roles.

Central Issue Tracker

Problem: many people editing different parts of the document - a proliferation of discussions.

Solution: a single space "issue tracker" for all issues which need to be resolved, and making good use of the "watch list".

For the "issue tracker" it helps to design a tidy format for tracking issues, and to have some conventions. e.g. Each issue as a sub-heading helps with navigation and editing.

Issues can be divided into two categories: "open" and "closed." "Open" issues, listed first, are ones that still require discussion and debate. "Closed" issues are ones in which the issue has been resolved and the solution implemented within the document (if applicable). Applicable solutions should be transferred to the style guide. An issue should not be closed until there is sufficient agreement among the community.

Issues can be clustered according to topic or relevance.

Avoid referring to entries in such an issue tracker by number in the auto-generated ToC - these numbers change!

Rather refer as (e.g.) [[OER_Handbook/educator/issue_tracker#Issue: Glossary check|Check the glossary]]

Style Guide

Problem: multiple editors from around the world with varying styles

Solution: style guide

It is wise to "discuss" style conventions before adding them to the Style Guide. By doing so, the style guide becomes an authoritative document and easy to use, as users do not have to sort through paragraphs of discussion to determine the agreed-upon style.

Cross references

Duplication

Problem: too many cross references to the same things from different chapters.

In general, separate concerns for a more modular OER. The more "standalone" a component the better for peer production (Benkler 2006). (Yes, but there becomes a point where the needs of the document outweigh the benefits of peer production --Sgurell 17:17, 21 July 2008 (UTC))

There is a tension/trade-off here: minimising duplication vs minimising cross-referencing. An OER component should be as self-contained as possible.

However, this may lead to a lot of duplication for OER of any significant size. In a web environment, hyperlinks mitigate this problem to a large extent. So, in general, one can be quite modular. (Agree to a point. I think hyperlinks can minimize duplication to a point. However, I think there's value in having an over-arching narrative that ties the whole document together. --Sgurell 16:42, 21 July 2008 (UTC))

Refer to broad sections/chapters/pages rather than specific subsections (which might change or disappear). (Agree, when possible, but sometimes you need to refer to a specific section --Sgurell 16:42, 21 July 2008 (UTC))

Look out for statements like "xyz as mentioned earlier" - avoid this, but if you must, be more specific and include an actual link for the benefit of learners, and in case the section being referred to is removed (easier to discover the broken link if there is one).

When editing pages, check that existing references and attributions still apply, or whether new ones need to be added.

Collaboration

Tools

In general, the Talk pages are sufficient to carry out the day-to-day process of editing the wiki. E-mail forms an important backchannel in which private or sensitive matters can be discussed efficiently; however, in keeping with the spirit of open collaboration, these communications should be limited to an "as-needed" basis. Skype can be useful for emergency or issues that seem to be too complex to cover over e-mail or wiki.

Differences of Opinion

A complex OER such as an entire course or handbook requires a significant investment of time to get into the style and tone.

Often there is a "culture" and a dynamic among the co-developers. This develops over time and can change as contributors come and go.

The more time people spend, the stronger the sense of ownership, and there can be disagreements and clashes of opinion.

A number of things can happen ... "edit wars" ... productive contributors leaving ... the community finds a way (e.g. define roles for people and a protocol for contributions).

Some projects may benefit from a "benevolent dictator," or a project leader. The project leader should be willing to listen to the community and look for ways to compromise with competing needs and viewpoints. However, the community should respect the project leader as the final arbiter. Strong disagreements may necessitate "forking," or separation into a different project.

Sometimes the best way to resolve a difference of opinion is to give both parties time to think over the issue before responding. Irrational or hasty responses can result in significant loss of productivity.

Difference in Urgency

In some cases, there might be a contributor with a particular objective and time line which is of less importance to other contributors. The approach and priorities will differ for the participants. For example, the one with the goal and deadline will emphasise "polishing" while others might emphasise longer term quality concerns.

One approach is for the less pressed core contributors to be considerate of the ones subject to the deadline.

Experiences from Beyond

If you have wiki productivity experience from elsewhere which you would like to share, please go ahead (below).

• Issue Tracker examples:
  • Issue Tracker
  • Social Entrepreneurship.

See Also

• Sections on Quality (compose and adapt) in the OER Mini-Handbook for Educators.