DocLoop-OER: Channelling Reader Feedback into Open Educational Resources Textbook production as a collaborative process

docLoop-OER is a web platform where readers can give feedback on stretches of a (text)book. This feedback is channelled into an issue tracker.


1
More than all other types of scientific publications, Open Educational Resources (OER) profit from liberal permissions to redistribute, reuse, and remix. For textbooks, adding an additional chapter for a particular course, dropping an irrelevant chapter, or even rewriting a confusing chapter becomes possible under liberal licenses. In this way, scientific publishing comes to resemble distributed software engineering, where collaborative creation of programs is commonplace. Different user groups can work on the tasks they know best, and they can adapt the code to their particular needs (e.g. create a mobile version). Users can file bug reports, request new features or can even propose improvements of their own via so-called pull requests. For this, issue trackers are used in software development.

Reader Feedback 2
Theoretically, one could simply take over the software developers' issue trackers for (text)book production. But, in the textbook world, the degree of computer literacy is a lot lower. While in software development, people are fine with interfaces like GitHub or Redmine, on the other hand in, say, a textbook on English grammar, we cannot assume that readers will be able to relate to a technical issue tracking interface. The readers might still be able to make an important contribution content-wise, but the current way of producing textbooks simply does not provide a good way of giving feedback. This means that smaller improvements, like adding or amending one exercise, or even fixing a typo, are often not realised since the readers are not familiar with the relevant tools. Teachers might tell their students every year a new "skip exercise 3.2, it is erroneous" but there is no easy way for them to either create the new book themselves, or even to record their finding somewhere.

3
Enter PaperHive. PaperHive allows readers to annotate scientific texts in their browser. This means that small amendments can easily be recorded and are anchored at their particular position in the text. No particular technical expertise is required on the commenter's side, and no conventions as to the well-formedness of bug reports have to be observed. You spot a mistake, you mark it up.

4
In this way, book authors can collect feedback from their readers easily and improve their presentation based on the readers' comments. But for authors, it is cumbersome to regularly peruse their textbook in a browser and take note of new comments and their merit. Paperhive has a "subscribe" function which notifies users about new comments via email, but this can easily jam the inbox, and it does not integrate with a nice work flow.

5
Thus, we have some issue tracking software on the author's side, and we have some commenting software on the reader's side, but the two are disconnected.

Connecting Reader Feedback and Author Tools 6
Enter DocLoop-OER. DocLoop-OER provides a bridge between comments on Paperhive and an issue tracker. Every time a reader leaves a comment on a document on PaperHive, it is transformed into an item on the author's todo list (e.g. on GitHub or Trello). The author can then address the comment as they see fit. DocLoop-OER thus closes the loop between author-oriented tools like GitHub issues, and reader-oriented tools like PaperHive, and allows readers to easily record requests for enhancements without having to delve into the details of book production. DocLoop-OER is open source software available on https://app.docloop.net/. It assumes that the textbook is available for commenting on a web platform (source), and that some kind of publicly available issue tracker exists (target). Everybody can now enter the source (e.g. https://paperhive.org/documents/YEkPZQhJDTew) and the target (e.g. https://github.com/langsci/177/issues) to connect the two. The person who requests the connect obviously has to have write access to the issue tracker. DocLoop-OER has a modular architecture with hooks. Currently, PaperHive and GitHub are provided as sample source and target, but other adapters could be added without too much trouble, like hypothes.is on the reader's side or Redmine on the author's side.

Empowerment 8
Who creates textbooks? Normally, tenured professors. Textbook contents will reflect the demographics of that particular group of creators. We can assume that the world views of the typical demographic features of this group (white, male, straight, wealthy) are well represented in textbooks, while the world views of other demographic groups will be less represented. Of course, authors have always been collecting feedback, e.g. from colleagues, and readers of textbooks might send an email to the author if they have spotted a mistake. In principle, this option was available to everybody. But, in fact, feedback is more often than not recruited from the very same demographic group the author comes from. Sending a personal email to a renowned professor represents an important threshold, and only people from within the professor's peer group might actually dare. Open feedback platforms like PaperHive allow less privileged groups to make themselves heard and influence the creation process of a textbook by lowering that threshold. This is all the more important since textbooks transport the essence of the field to future generations, and multiple perspectives should be included in them.

Non-textbooks 9
DocLoop-OER focuses on Open Educational Resources in general, and on textbooks in particular, because those text books: 10 In principle, the technology can be used as is for other text types which do not have these features. Obviously, some form of revised edition is required in order for DocLoop to be useful. If a book was to be seen as finalised (going against (a)), there would be little merit in collecting reader feedback. Also, if new revisions only iron out typos, the incentive is not very high to contribute (b). For works which present novel insights (c), there is by definition normally only one researcher who can contribute, since it is this particular insight or theory of theirs which they wish to convey. Hence, this type of text does not lend itself that easily to collaborative approaches, but of course, there are research teams who could want to integrate a feedback loop into their work flow. Finally, we think that textbooks are a sensitive text type (d), where a good and balanced representation is particularly important and special care must be taken to make everybody feel welcome in the field. This goal is of course also commendable for books targeting more advanced researchers.