When faced with writing this introduction, I wondered how many people read introductory editorials in journals, but since you are here, some must. Then I wondered what to write about. It eventually occurred to me that some of you might be interested in something of what goes on behind the scenes of the journal.

I joined The Code4Lib Journal Editorial Committee (EC) in 2009 with some trepidation. However, any fears I had were quickly alleviated when the other editors welcomed me and proved glad to answer any questions that I had. My orientation to the work of the EC was aided by the extensive documentation on our wiki (http://wiki.code4lib.org/Category:Code4Lib_Journal), which remains a valuable reference. In many ways, the EC is a microcosm of the Code4Lib community. It is a leaderless group composed of dedicated volunteers. The EC members take turns serving as the coordinating editor who shepherds a specific issue. The journey to each issue may be chaotic and take many twists and turns, but somehow it always comes together in the end.

Members of the EC participate in discussions on the EC’s closed list. The practices and policies of the journal are continually evolving. Anyone can suggest a change. Potential changes generate respectful discussion (and sometimes sharp disagreement). New editors often bring new perspectives and ideas. For example, one new editor felt strongly that a professional journal should have a set style guide for references for consistency and to make it easier to ensure proper citations. Other members of the EC felt a set style imposed an unnecessary burden on authors and that the only requirement for citations should be that they are consistently formulated in a given article and findable. In this case, a compromise was reached and we adopted a recommended style.

Some questions reflect ongoing tensions. Every time we issue a call for new editors, there are those who advocate for accepting a higher number of new editors so that we can publish more articles. We receive many high-quality proposals and the EC is often stretched very thin trying to publish as many as possible. More new editors would bring more enthusiasm and new ideas. Others call for a smaller number to keep the EC more cohesive and focused, while also combating the diffusion of responsibility and temptation of social loafing that comes with a larger group. At some point, too many editors and articles would make the work of the coordinating editor unmanageable under the current model. There is a parallel discussion about how high to make the bar for acceptance and how much work it is reasonable to ask an editor to put into an article to get it to the point where it meets our standards for publication.

The publishing cycle begins with a call for proposals on various email lists. The incoming proposals are put on a spreadsheet for voting and are discussed on our closed email list. We have adjusted the voting protocol over time, but seem to have settled on a satisfactory algorithm. We used to vote on article proposals in a rolling fashion, but recently changed to using a set deadline. The set deadline makes it easier to rank articles when we have too many and helps with matching editors to articles. A disadvantage is that many authors end up with a shorter time period between acceptance and the due date for a first draft. In most cases, voting gives a clear consensus. Then there are those that we tussle over. There are disagreements over such questions as whether a proposal is in scope, is at the appropriate technical level or has a broad appeal for our audience. In some cases, editors see potential in a borderline proposal and want to work with authors to improve it. Others say this has rarely worked out well and argue that it’s better to just reject such proposals up front.

Individual editors sign up to be the editor or second reader for articles that they are interested in and have the appropriate background for. Editors contact the authors of their chosen articles and serve as the primary contact for those authors throughout the publishing process. Articles go through two drafts. When each draft is submitted, it is reviewed by the editor and the second reader and by other members of the EC if they choose. They then provide feedback to authors on the drafts. A final draft is input into WordPress for review by the authors and the EC. The EC votes again on the articles and any final editorial changes are made. When the time comes, the coordinating editor takes a deep breath and hits the publish button. The first time I did this, it didn’t lead to the result I was trying to get. I was very grateful for the instructions on the wiki for backing out and republishing! The coordinating editor also uploads the issue to the Directory of Open Access Journals (http://doaj.org/). When the new issue is live, the EC begins publicizing it and the whole process starts again.

Having been on both the author side and the editorial side of journals using traditional blind peer review, as well as the peer-edited process used by The Code4Lib Journal, I have found that for me the primary benefit of peer-editing is the interaction between editor and author. The articles I have written for The Code4Lib Journal have been much improved by the iterative feedback from the editors. From the editorial side, I have seen many articles become clearer and more coherent as a result of the revision process. Depending on the article, the revision process may involve a significant reworking of the article and a substantial time investment by both the editor and the author. In contrast, blind peer review is not so much a conversation as a one-way broadcast. My experience is that the feedback tends to be much briefer and it is not easy for either side to ask for clarification.

Of course, there are some dangers attached to an open process. Despite our best intentions, the EC may be influenced by factors external to the content of the article. It also becomes harder to reject an article after having worked so closely with the author. Articles do fail the final vote, but in the past, we have ended up publishing a few articles about which many of the EC had serious reservations.

Publishing in The Code4Lib Journal may not be right for you if you are facing a tenure or promotion review by a conservative committee. However, if your goal is to communicate with a broad audience and make an impact on your peers and the field, The Code4Lib Journal is the perfect vehicle. For a long time, I wasn’t sure if anyone had read my first article in a gated journal. I had no doubts that people were reading my first article in The Code4Lib Journal as soon as it was published.

The journal continues to explore new spaces. For issue 28 we are planning our first themed issue, on diversity and library technology.

Being a member of The Code4Lib Journal Editorial Committee has been a lot of hard work, and the process of working with the other members of the EC and with authors has been both challenging and enjoyable. The reward for all this work is the knowledge that I am contributing to something that makes a significant and positive impact on our field.

In this issue, we again have a slate of articles that have valuable things to say to our community. We have two articles related to the challenges of web-scale archiving. Archiving the Web: A Case Study from the University of Victoria provides an overview of the tools for and challenges of archiving websites in the context of the University of Victoria’s experience. Technical Challenges in Developing Software to Collect Twitter Data explains how George Washington University handled the technical challenges of turning its application for collecting social media data from Twitter from a research prototype into something that is sustainable and useful for a wider audience.

We also have two articles focused on using AngularJS. Exposing Library Services with AngularJS provides an introduction to the JavaScript framework AngularJS and introduces some AngularJS modules for accessing library services. Hacking Summon 2.0 The Elegant Way shows how to reverse-engineer the AngularJS-based Summon 2.0 interface and explains how to use this knowledge to customize the interface.

Parsing and Matching Dates in VIAF describes the challenges of interpreting the numerous ways of expressing dates found in authority records from various sources so they can be standardized and compared. Mdmap: A Tool for Metadata Collection and Matching looks at a novel way of generating metadata to describe digitized books by evaluating and merging existing metadata that is gathered from many sources.

Using Zapier with Trello for Electronic Resources Troubleshooting Workflow shows how these free tools have been used to create a more efficient and effective process for tracking and responding to e-resource access problems. Finally, Developing Applications in the Era of Cloud-based SaaS Library Systems uses Ex Libris’ Developer Network as an example of how vendors are addressing issues such as security, multi-tenancy, latency, and analytics in the cloud environment.