“Pains and Gains of Peer-Reviewing in Software Engineering” (doi:10.1145/3375572.3375575).

“Pains and Gains of Peer-Reviewing in Software Engineering (4)” (doi:10.1109/ICSE-C.2017.49)

“Pains and Gains of Peer-Reviewing in Software Engineering (5)” (doi:10.1145/3468744.3468747).

“Pains and Gains of Peer Reviewing in Software Engineering: A Journal-Centric Perspective” (doi:10.1145/3468744.3468748).

“The ACM SIGSOFT Paper and Peer Review Quality Initiative: Status Report” (doi:3385678.3385681).

“Double-Blind is Good but Open Would Be Better Perceptions of Peer Review in the SE Community” (doi:10.1145/3402127.3402133).

“A community’s perspective on the status and future of peer review in software engineering” (doi:10.1016/j.infsof.2017.10.019).

“Peer Reviewing in Software Engineering: Perspectives from STVR Co-Editors-in-Chief” (doi:10.1145/3417564.3417568). Este artigo trouxe uma ideia simples, mas efetiva para um problema abordado no Congresso da SBC: pesquisadores com quantidades muito elevadas de artigos. Por exemplo, é normal que um pesquisador publique 50 ou 100 artigos em um ano? Um argumento levantado naquela seção (CAPES/CNPq) foi que não existe um parâmetro definido pelas agências de fomento e que isso deveria partir da comunidade. O artigo menciona algo que passa desapercebido: o processo de revisão por pares deve ser autosustentável. Em outras palavras, se você tem 100 artigos publicados, você deve ter prestado o serviço de revisão de uma quantidade compatível de seus pares (3 a 4 vezes a quantidade de artigos _submetidos_). Ou seja, na melhor das hipóteses, alguém que tenha publicado 100 artigos teria de ter revisado 300 artigos (considerando taxa de aceitação de 100%). Assim fica fácil perceber que isso é humanamente impossível. No entanto, mecanismos públicos para registrar as revisões realizadas ainda são escassos. Talvez com a ampla adoção de soluções como o Publons ou o RQC (ReviewQualityCollector), isso poderá se tornar uma realidade.