Editorializing

A confluence of events this past week have inspired and challenged me to reflect on my time as a Code4Lib Journal editor, its positive effects in the field, and how its structural/organizational weaknesses undermine its potential.

First, some context: I joined the Code4Lib Journal (C4LJ) Editorial Committee (EC) back in 2015. My first issue was issue 29. I wrote two editorials, which I still consider some of my more meaningful work. I shepherded some exciting and some run-of-the-mill articles through publication (more on this process later). Because I had a lot of experience and decent skills with Wordpress, I also took over the role as technical administrator, maintaining the website from issues 30ish-51 (almost to 52).

I stepped back from editing around issue 40/41, but remained on the EC listserv and occasionally pitched in when help was needed. After another ten issues, I was ready to step back from maintenance as well. I handed off those duties two weeks ago, so I was already in a reflective mood when this article and the editorial justifying its publication came out.

This post isn’t about the article/editorial themselves, you can get that context from Becky’s Twitter thread, Peter’s response and post¹, and Dorothea’s response. Instead, I’m going to share an overview of how the editorial process works, some factors which contributed to my stepping back as an editor, and thoughts on what change might be needed in the future.

Editorial Process and Mission

The Editorial Committee and its processes are set up to foster the Code4Lib Journal’s mission²:

The Code4Lib Journal exists to foster community and share information among those interested in the intersection of libraries, technology, and the future.

The best parts of Code4Lib (as a whole) are collaborative and community-oriented. The close engagement of the Editor is an attempt to bring this element to the Journal. There are a lot of people who have got worthwhile ideas or done interesting work but are not skilled at expressing it. Maybe they’re just getting started. Maybe writing’s never been their forte. In a best-case scenario, an Editor who works alongside you (as described below) and is invested in your success in turning out a good article could be the difference between getting your expertise out into the world and never writing about it.

The second element of the mission statement, “share information” is left intentionally open. In a best-case scenario, this allows for a wide variety of articles. You can write about your new Drupal module for handling image rights without having to do a literature review or discuss methods. You can also present an analysis of user experience as a social justice issue without including a single line of code. Both kinds of information have the potential benefit the Code4Lib and broader library technology community.

Keep “foster community and share information” in your head as you read the publication process walkthrough.³

Process Walkthrough

Each quarter or so the EC puts out a call for proposals. The issue’s Coordinating Editor acknowledges receipt and enters the proposals into the working spreadsheet. Once the deadline for proposals has passed, all active editors review the proposals and vote yes/no/abstain. If an editor is particularly interested in an article, they’ll sign up as Editor or Second Reader (generally on a first-come, first-served) basis.

Once voting is complete, the Coordinating Editor determines which articles passed preliminary voting and then makes sure that every article has at least an Editor. If the EC voted in more article than editors, articles without editors will be rejected or postponed to the next issue. The Coordinating Editor also writes the Editorial, which ranges from a few reflections and an overview of the issue to an article-length opinion piece.

Each Editor works with their article’s author(s). Normally, the article hasn’t been written yet, so this includes sending a timeline for the first draft, answering any questions, etc. Once the first draft is in, the Editor reads and provides feedback on it, bringing in the Second Reader to read and give their comments as well. After revisions are complete, both Editor and Second Reader read the revised draft, work through any minor changes, input it into Wordpress, and notify the EC that the article ready for everyone to read and vote. All articles must be voted on a second time and get at least 2 more “yes” than “no” votes to be published (this might be just 2 more people reading/voting for it and 0 voting against).

The closest the Code4Lib Journal gets to a “revise and resubmit” is when an article might be held back to the next issue if it’s not deemed ready for publication. This means that the same Editor continues to work with that article in addition to or instead of another article. Occasionally, the EC as a whole decides against publishing it at all, but this is quite rare after the proposal phase.⁴

Implications

If you’re familiar with other journals and their submission/editorial policies, you’ve probably noticed some major differences between the Code4Lib Journal’s process and those of other journals. First, many proposals are just that—the proposal, not the finished article. This means that an Editor often chooses the article they’ll be supporting based on what’s in the proposal, without knowing the intended content and direction of the finished article.

Second, rather than send the finished article out to peer reviewers, the Editor acts as a “peer editor” throughout the process. This means that the Editor and Second Reader, as well as other editors who read/vote on the article, bring their perspectives and expertise to the process, as well as their own priorities and gaps. With reviews only coming from the EC, the perspectives/expertise/priorities/gaps are fairly limited, as would be the case on any journal which has only a small pool of peer reviewers.

The process gives the Editor (I speak from my experience here) an emotional stake in an article that editors in other journals may not have.⁵ This can be compounded by the “share information” part of the mission. Many imperfect articles share useful information. Add in the loss of capacity for the journal/repetition for the Editor and it is easy to see how one might prefer to publish something that one considers “good enough.”

My Experience and Unease

During my time with the EC, I acted as both Editor and Second Reader on some pieces I am really happy were published. I became invested in them. I tried to ask questions/request changes to help them reach their potential. There were others which were just fine, and that was ok too. I felt that they were good enough for the platform and useful audience, I didn’t find their content/assumptions/practices concerning, and I tried to make sure the article was as good as it could be.

I think my unease grew over time, as I was acting as a peer reviewer for other journals. I knew the process difference was intentional, but I started to ask myself what the Code4Lib Journal might be losing with this difference. This unease came to a head for me with a particular article.⁶ It wasn’t that I found fault with the code, language, or even generalized task handled by the authors’ work, all of which I would’ve felt more empowered to push back on if need be.

The reality was that there was no structure in place to ask questions like “does this underlying project the authors’ employer asked them to do subtly uphold neo-colonialism and how should we address that?” (a hypothetical derived from my conflation of the real article with another). I think questions like that are thorny for any journal editor, but the lack of peer reviewers and not having the framework to request peer review from someone with expertise/perspectives in that area left me feeling uncertain what to do next. The issue wasn’t straightforward enough (to me) to warrant a clear-cut response or to mean that the article’s content shouldn’t be published.

I continued as an editor for a few more issues but also reflected on the journal’s structures, mission, my other time commitments (I was just about to embark on the labor forum), and ultimately decided to step back from editing but stayed on in my role maintaining the journal’s website. I treated this as a personal decision, mostly because of my other commitments and energy levels. However, I also did not have the capacity or feel the call to propose significant structural changes a journal’s process. At the time, I wasn’t sure what those changes should even be.

Thoughts for the Future

I’m not writing this because I suddenly came up with a fix. But, as I said at the beginning, the journal’s structures and their implications have been on my mind lately. I hope that this post has helped others understand why the recent article didn’t get a “revise and resubmit” or why pushing an article to the next issue results in significant loss of editorial capacity. I’ll close with a few thoughts which I hope spark ideas in current and future editors and in the broader community.

Information Includes the Context and Subtext

What are the journal’s values in 2021?

When we think about “sharing information,” we must keep in mind that information is more than the core content. Information is the context. Information is the subtext. Publication is a form of endorsement. The kinds of projects described in the field’s literature contribute to the field’s norms.

It’s easy to reject the most egregious projects in the proposal phase, but what about the rest? Should the EC re-evaluate the journal’s mission (it has been 14 years after all) and incorporate our field’s ostensible values into it? Such a document would not only give editors a framework for feedback or rejection, it could be sent to authors to guide the writing process.

Peer Review Changes Capacity

How might C4LJ retain the support for newer authors while improving editorial capacity?

Once the Editor has committed to a piece, it’s easy for it to become a sunk cost. Delaying publication means one fewer article gets published in the current issue and the editor either supports two authors through the next publication or the EC has to reject an article they might’ve otherwise accepted. Having a topical specialist on call seemed like a promising solution to gaps in the EC’s expertise.⁷ Unfortunately, it wasn’t enough to halt the structures which prioritize publication.

While peer review adds the cat reviewer-herding element, it creates a layer which not everything is expected to pass through. The energy that editors bring might be distributed among more articles and reviewers, perhaps not lessening the workload but changing the degree of individual engagement.

Detachment Has Value

What processes might the EC consider to help editors feel supported in deciding that even if an article has useful elements, it doesn’t represent the values or norms the journal wants to see in the field?

People who work in libraries, myself included, tend to care and we tend to care hard. As I’ve described above, the processes by which an article goes through the publication process tend to lead to the editor caring hard about the article. While I’ve really enjoyed and been excited about some articles that I’ve peer-reviewed for other publications, I’ve never felt the same identification with or commitment to an article that I have with the Code4Lib Journal.

Conclusion

I’ve spent over a week reflecting on how I should conclude this post. As I’ve said, I don’t have a solution for all this. But what I do have are thoughts and questions, which I’ve turned into suggested steps for the Code4Lib Journal EC and the greater Code4Lib community:

1. Review and evaluate the Journal’s values in open collaboration with the Code4Lib community. Expand the mission statement to include these values. Share them with prospective authors.
2. Explore other methods of article evaluation and feedback. Ensure that external reviewers understand the priorities to support newer authors and focus on content vs. composition skill.

Considering the past 18 months, putting in the time to evaluate and change existing processes is a big ask. I’m not the only former EC member to step back because they felt too much strain from their workload. But in the long run, perhaps changing the processes will be good for both the Journal and the editors. The Journal has the potential to be better. Let’s see what can be done to get it there.

Notes