The technical editing occurs after the copy-editing is complete. The primary purpose of this role is to ensure consistency across the project and adherence to style guide, accessibility, and equity lens guidelines. The Technical Editor is responsible for finishing the process of publication, including sending the book back to the author for final review and coordinating the back-end publication process.

Author Choices

Standard Policy

The Technical Editor met with authors to discuss choices for stylization of the book. This would consist of:

• Theme choice
  • ROTEL identified Malala and Jacobs themes as being acceptable for our purposes
• Chapter title format and visibility
• Glossary usage (or not)
• Textbox titles and colors
• Automatic media attribution or hand-crafted media attribution
• The usage of details HTML tag

Rationale

Given the open nature of OER, it was considered important that each book reflect the author’s choices. This allows for the expression of each book to be unique and serve their own purposes.

Lessons Learned

Decision Paralysis: Authors most often had difficulty in making decisions for the design choices, especially toward the end of the process where they’ve completed working on the draft and have moved on to other priorities. For the first rounds of ROTEL, the Technical Editor attempted to have open-ended conversations, which typically led to decision paralysis by the author. This would happen even though we reduced the choices down to two to three options (for example: two Pressbooks themes to choose from). By the third cohort of authors, the PST developed a questionnaire that detailed the most common topics that needed discussion, narrowed down to the most important choices. This was given to round three’s authors early in their drafting process and proved to be a much more useful tool for that round.

Deadlines

Standard Policy

The ROTEL Grant had mapped out three cohorts of authors to work with, each group given a year for authorship. There was an expectation that books would be published rapidly after that time to allow access to students quickly.

Due to the iterative process ideology, the PST attempted to include the authors in the finalization process by mapping out several touchstones that required author input.

Rationale

In an attempt to keep authors on track and deadlines met as much as possible, the PST created touchstones for publication steps. Examples of these touchstones can be seen at the top of the page.

Lessons Learned

Moving Deadlines: Leaving the deadlines largely unenforced left many books taking longer than originally intended. This led to some of cohorts one and two’s books being published alongside cohort three’s books rather than during their own cohort. The PST discussed setting harder deadlines while maintaining the ideology of the iterative process. By the end of the grant, we started including dates for expectations on responses. In most cases, this led to authors getting work back to us sooner than our projected dates. The conclusion and advice we have going forward is to set dated deadlines (ex., “May 13”), as this seemed to work better for getting work completed.

Uploading Versions – Source

Standard Policy

The Technical Editor downloaded the Google document and created a Word version to copy and paste the text into Pressbooks.

Rationale

This process served three purposes:

• The Technical Editor could review the book while moving it to highlight any spaces of concern for revision or reformatting.
• Google documents are an open text format, and formatting choices (such as bold/italics and hyperlinks) does not transfer over. Moving text from Word to Pressbooks allows these formatting choices to be maintained.
• This process essentially “freezes” the version of the book for uploading.

Lessons Learned

Importing from Word: We discovered that at the time of our work on these projects, importing from Word would override many of the accessibility frameworks that Pressbooks has built in with Word’s HTML formatting. This led to accessibility issues during the quality assurance step.

Additionally, importing from Word meant that formatting issues inherent to the text (such as table formatting) would be overlooked as it wasn’t reviewed during the upload process. We determined that it was better to move these manually for the current versions of technology available.

Regular Editing: When the Technical Editor “freezes” the version by downloading it, it means that any adjustments made to the collaborative documents in the Google drive aren’t reflected in the uploaded version. The Technical Editor attempted to communicate this to authors, but it was difficult for authors to keep track of that step.

Recommendation: Actively duplicate/lock down the drafts in collaborative file drives to visually show authors that the version that they are working on is not the version that is being uploaded. This avoids frustration during the review process as it promotes communication for edits that need to go in before publication.