programminghistorian / jekyll

Jekyll-based static site for The Programming Historian
http://programminghistorian.org
516 stars 229 forks source link

Problems (and solutions?) to open peer review #148

Closed acrymble closed 8 years ago

acrymble commented 8 years ago

I'd like to have an open conversation about the practice of open review we've adopted here, so I'd be grateful for ideas from a range of people. We've been doing open review for a few months now (reviewers openly post their comments with their names visible and authors respond).

There are a few changes between this and the traditional double blind review system used by most journals. In particular, I see the following possible matters that COULD become issues:

1) The role of the editor is diminished and the authors and reviewers might be tempted to negotiate between one another. This is fine if it is civil, but there is no opportunity for the editor to filter or otherwise mediate between two rapidly-responding individuals. There is also an inherent power relationship between the reviewer (a gate-keeper of sorts) and the author (trying to tick the boxes to get through the review process). If a reviewer exercises that power without the moderation of an editor, the lesson might actually get worse as the author seeks to tick the boxes and get 'done'. Is this a significant problem?

2) People who submit late reviews are clearly identifiable. Because reviews are dated when submitted to Github, it's really obvious who did a good thourough job in a reasonable amount of time, and who just didn't get around to it. That's frustrating for authors and editors, and it may also breed longer-term ill will between people. This was traditionally hidden by the editor who first collated responses. Is this a significant problem?

If you have opinions on these or other matters, please let us know, as it will inform our ongoing discussions.

fredgibbs commented 8 years ago

Thanks for bringing these up, Adam. I see both of these issues as distinct advantages of the open system rather than potential significant problems--provided, as you say, that people are nice to each other, which I presume will continue to be the case for our authors and editors. I know this is not always the case with other journals with more academic weight/prestige/gate-keeping behind them. But I'm proud that our community largely avoids these issues. I think the openness of our process actually encourages a more collegial and productive process than blind review (which can also be extremely useful; I don't mean to suggest it's always a bad experience).

1) I think reviewer and author negotiation is great! But at least as I see the editor's role, the reviewer isn't a gate keeper (that's explicitly stated on our review page), but more like a collaborator. As editors, I don't think we should ask anything to be reviewed that we don't think is pretty close to publishable. So lessons have already been accepted more or less and the review process makes them better through exposing more viewpoints and critical eyes to the lessons. This may need to change if we start getting more lessons than the editors can handle. I think the lessons that have been openly reviewed so far have gotten noticeably better, not worse, but we have a relatively small sample so far.

2) I can't think of a better way to encourage quality and timely reviews than by having the process be fully visible. But quick and thorough reviews won't always happen no matter what system is in place. But we also don't document the entire review process. We don't, for instance, note people who were asked to do a review but ultimately don't for whatever reason. So a review that takes a while get done isn't necessarily the fault of whomever ultimately submits the review. It might be, but there's no way of knowing how many people were asked beforehand or if the editor was slow, etc.

On Tue, Nov 3, 2015 at 2:53 AM, Adam Crymble notifications@github.com wrote:

I'd like to have an open conversation about the practice of open review we've adopted here, so I'd be grateful for ideas from a range of people. We've been doing open review for a few months now (reviewers openly post their comments with their names visible and authors respond).

There are a few changes between this and the traditional double blind review system used by most journals. In particular, I see the following possible matters that COULD become issues:

1) The role of the editor is diminished and the authors and reviewers might be tempted to negotiate between one another. This is fine if it is civil, but there is no opportunity for the editor to filter or otherwise mediate between two rapidly-responding individuals. There is also an inherent power relationship between the reviewer (a gate-keeper of sorts) and the author (trying to tick the boxes to get through the review process). If a reviewer exercises that power without the moderation of an editor, the lesson might actually get worse as the author seeks to tick the boxes and get 'done'. Is this a significant problem?

2) People who submit late reviews are clearly identifiable. Because reviews are dated when submitted to Github, it's really obvious who did a good thourough job in a reasonable amount of time, and who just didn't get around to it. That's frustrating for authors and editors, and it may also breed longer-term ill will between people. This was traditionally hidden by the editor who first collated responses. Is this a significant problem?

If you have opinions on these or other matters, please let us know, as it will inform our ongoing discussions.

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/148.

frederick w gibbs | assistant professor of history | univ. of new mexico fredgibbs.net | @fredgibbs http://www.twitter.com/fredgibbs

acrymble commented 8 years ago

Thanks for the response Fred.

1) I'm not opposed to the conversation between authors and reviewers. Instead, I'm a bit concerned we'll end up with a few reviews we might call 'unhelpful'. Not uncivil, but just not that useful or perhaps wrong (and maybe the author doesn't realise this or want to publicly tell someone they don't know what they're talking about). We've all had these in traditional peer review, and usually the editor says something like, 'You can probably ignore Reviewer number 3'. But because of the immediacy of the system, the author might notice and start to act upon Reviewer number 3 before the editor notices the advice was poor or grumpy.

My view of the role of an editor is to mediate between those suggestions and the actual changes an author has to make to improve the piece. Are there ways we can evolve our current system to avoid those types of problems? Editors explicitly summarising proposed changes and helping to facilitate the conversations? This process is foreign for most of our reviewers and authors, so increasing the editor's visibility is probably a good thing.

2) Related to that, you're right, sometimes we have trouble getting reviewers. But we can help grease those wheels if we as editors are using the tickets to keep everyone informed regularly. That could be through labels on Github (reviewers assigned, looking for reviewer, review overdue, etc). Or we could just post to the tickets: sorry a reviewer has had to pull out for unforseen circumstances, etc.

It looks like we've got the technical mechanisms in place, but maybe we need to consider the social elements.

Happy to hear from others, including authors and reviewers.

drjwbaker commented 8 years ago

To begin, I enjoy the open peer review, enjoy that it takes place here, and enjoy that the published articles and their development can sit side-by-side.

I too wonder about the role of the editor in it though. @acrymble suggests a model where editors are 'explicitly summarising proposed changes and helping to facilitate the conversations'. Introducing this seems a good step to me. On the open review I'm involved in https://github.com/programminghistorian/jekyll/pull/139#issuecomment-141272406 (which I note you've queried the editor of today) it strikes me that the author would benefit from an editorial summary of where to go next, not least because the comments of the two reviewers are both language/presentation/function related (which is easy to deal with) and substantive, questioning the scope of the lesson, how it is organised, the examples it uses, how it is pitched (which is harder to deal with). And as you as editors know better than your reviewers and authors how a lesson should be written with regards to fitting the overall tenor and purpose of PH, you are best placed - it seems to me - to filter the latter category of comment before the author takes action.

Of course introducing a process like this might mean more editors, with the associated risks of bulge, dilution of sense of 'ownership', and mission creep. So it then becomes a substantive issue for how PH functions going forward. Good luck!

ianmilligan1 commented 8 years ago

Thanks @acrymble for starting this conversation. I think you've raised some good issues that we need to both think about and come up with a documented way of dealing with them. While we haven't run into these issues yet, in terms of uncivil reviewers, you never know. I think @fredgibbs is bang on re: the quality we've seen so far, and in terms of the broader goals of what we want to see with Programming Historian - being the change we want to see in academia?

That said, some policy tweaks and discussion are probably in order..

I think @drjwbaker and I are on the same page: I think an editor should provide an overview of the two reviews, and suggest areas of improvement as well as diplomatically noting parts of the reviews that are potentially less useful.

The suggestion of an editor being more active in the review thread is also a good one: posting a quick update when reviews are solicited, noting timelines and keeping the author availed of any unforeseen delays. When I'm an author, the delay isn't the big tension point, it's feeling kept in the dark and wondering if any progress is being made.

The key to all of these above, though, is diplomacy and that's where I think we need to keep thinking about this. Do we feel comfortable with scenarios like:

All of these are things that we shouldn't see in academia, but we do. I think I'm comfortable with seeing this play out in public, and rely upon the goodwill of a generous, thoughtful, and caring community, but I suspect eventually these principles will be challenged by a contentious lesson.

acrymble commented 8 years ago

@ianmilligan1 I noticed you've already employed this strategy on Kim Pham's lesson that just came in. Should we work on some boilerplate text for this type of thing that we all agree to use at various thresholds, to make the process more transparent for everyone?

eg, I confirm the editor of this lesson will be X. I will be responsible for finding reviewers and clarifying required/suggested changes with the author. My role is to mediate between reviewers and authors, and th keep the process on track in a timely manner etc etc etc. If you would like to contact me outside of this forum, you can do so at myemail@email.com - though we encourage discussions to take place on the forum whenever possible.

and...

The reviews for this tutorial have now been received. Here is my summary of those suggestions that I would encourage you to address before publication...


A few set texts like that might just improve the communication from our end. What do we think?

ianmilligan1 commented 8 years ago

I like this, @acrymble, and decided to implement a version of it on Pull Request #149. I think templates for this sort of interaction are good, and set real milestones for us. Transparency is key.

fredgibbs commented 8 years ago

This is great. This weekend i will update our instructions for reviews page to make the expectations clear, and the instructions for editors page on the wiki. Transparency is key, but it also helps to have agreed on a set procedure--which i don't think we had fully worked out until relatively recently. Thanks, Ian, for implementing this so quickly--now there's precedent!

On Thu, Nov 5, 2015 at 5:36 AM, Ian Milligan notifications@github.com wrote:

I like this, @acrymble https://github.com/acrymble, and decided to implement a version of it on Pull Request #149 https://github.com/programminghistorian/jekyll/pull/149. I think templates for this sort of interaction are good, and set real milestones for us. Transparency is key.

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/148#issuecomment-154046741 .

frederick w gibbs | assistant professor of history | univ. of new mexico fredgibbs.net | @fredgibbs http://www.twitter.com/fredgibbs

miriamposner commented 8 years ago

Just now catching up on this, and this sounds really good. Ian, I really like your template! It's possible for me to imagine scenarios where authors might still feel some of the pressures Adam described (for example, if the editor and reviewer are friends and the author is new to the process), but this is a great step, I think.

If another member of the editorial team were willing to serve as "ombudsman" ("If you have concerns about the process, please email ...") it might serve as an additional layer of security in the unlikely scenario that an author feels ganged-up on. What do you think? I'd be very happy to serve in that role.

Miriam

On Thu, Nov 5, 2015 at 4:45 AM, fred gibbs notifications@github.com wrote:

This is great. This weekend i will update our instructions for reviews page to make the expectations clear, and the instructions for editors page on the wiki. Transparency is key, but it also helps to have agreed on a set procedure--which i don't think we had fully worked out until relatively recently. Thanks, Ian, for implementing this so quickly--now there's precedent!

On Thu, Nov 5, 2015 at 5:36 AM, Ian Milligan notifications@github.com wrote:

I like this, @acrymble https://github.com/acrymble, and decided to implement a version of it on Pull Request #149 https://github.com/programminghistorian/jekyll/pull/149. I think templates for this sort of interaction are good, and set real milestones for us. Transparency is key.

— Reply to this email directly or view it on GitHub < https://github.com/programminghistorian/jekyll/issues/148#issuecomment-154046741

.

frederick w gibbs | assistant professor of history | univ. of new mexico fredgibbs.net | @fredgibbs http://www.twitter.com/fredgibbs

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/148#issuecomment-154048883 .

ianmilligan1 commented 8 years ago

I think having an ombudsman around is a fantastic idea, @miriamposner, and I think you'd be great for it. I'd be happy to serve as a deputy ombudsman if you're unavailable or are good friends/direct colleagues with one of the parties at play.

miriamposner commented 8 years ago

Excellent!

On Thu, Nov 5, 2015 at 7:11 AM, Ian Milligan notifications@github.com wrote:

I think having an ombudsman around is a fantastic idea, @miriamposner https://github.com/miriamposner, and I think you'd be great for it. I'd be happy to serve as a deputy ombudsman if you're unavailable or are good friends/direct colleagues with one of the parties at play.

— Reply to this email directly or view it on GitHub https://github.com/programminghistorian/jekyll/issues/148#issuecomment-154087920 .

acrymble commented 8 years ago

Just to summarise this thread:

1) Miriam Posner and Ian Milligan will hence-forth be ombudspersons 2) We will come up with a set of boiler text for editors to use in pull requests, building upon what Ian has already said. This will be kept on the wiki.

acrymble commented 8 years ago

To manage this change, I've updated the index, reviewer instructions, and author instructions page. In each I have tried to clarify the role of the editor, to encourage people to ask questions about the process if they get confused, and to direct them to the ombudspersons if they feel the need to have a private discussion.

Please reopen if you feel I've not completed this, but I think that's a good start.