Differences

This shows you the differences between two versions of the page.

--- work:2024-28 [2024/07/09 03:26] – [SBPC] magsilva
+++ work:2024-28 [2024/07/13 19:17] (current) – magsilva
@@ Line 1: / Line 1: @@
 ====== Semana 28 de 2024 ======
+===== Pesquisa =====
+  * Revisão pelos pares
+    * Na disciplina de Metodologia de pesquisa em computação, da graduação do BCC, e em minhas orientações de pesquisa (graduação e mestrado), sempre aponto a revisão pelos pares como parte essencial do método científico.
+    * No entanto, há de se reconhecer que temos alguns problemas sérios nas revisões: disponibilidade de revisores e qualidade das revisões.
+    * Após ser coordenador geral de programa do EduComp 2024, percebi a triste realidade da disponibilidade de revisores. Ao mesmo tempo que existem pessoas super dedicadas e disponíveis, temos (1) uma parcela maior de pessoas que não tem interesse em revisar artigos (embora desejem publicar), (2) que impõem restrições sobre sua capacidade de revisão e (3) que não cumprem compromissos assumidos.
+      * Quanto às pessoas que publicam, mas não revisam, é uma clara divergência do método científico. No ACM TOCE, a Amy Ko e colegas estão trabalhando em uma abordagem para exigir revisões para a submissão de trabalhos, como se fosse uma taxa. Parece um absurdo, mas não é. Não é raro encontrar autores que publicam frequentemente, mas que revisam pouco ou que apenas delegam revisões. Ora, são justamente os pesquisadores mais experientes que deveriam contribuir mais com as revisões, com perspectivas complexas e contribuições para a melhoria dos trabalhos! No entanto, a carência de revisores faz com que muitos revisores com pouca experiência atuem, o que traz um viés na qualidade e profundidade das revisões, e que o tempo disponível para cada revisão diminua (o que também afeta a qualidade das revisões).
+      * Outra coisa que nunca imaginei era quanto a restrições de revisão. Quando você aceita participar de um comitê de programa, existe a suposição de que você revisará uma certa quantidade de artigos, provavelmente maior que um e menor do que um certo máximo (4). Por exemplo, sempre tenho em média duas à cinco atribuições de revisões nos comitês em que participo. Eis então que fico surpreso em descobrir que muitas pessoas aceitam participar em comitês de programa, mas restringindo a quantidade de revisões a duas ou, pasmem, uma revisão! Será mesmo correto que, com apenas uma revisão, alguém participe do comitê de programa? Fica a reflexão.
+      * Não suficiente, outro ponto que me deixou consternado foi a quantidade de revisões aceitas, mas não realizadas. Nunca deixei de entregar uma revisão, com exceção de um evento em que tinha revisões pendentes durante minha licença-paternidade. Ainda, nesse caso, eu entrei em contato com o coordenador de programa, expliquei a situação (licença-paternidade, devido ao nascimento de meu filho em um parto de emergência) e tudo bem! Motivos de saúde são sempre compreensíveis. No entanto, tem alguns revisores que não enviam as revisões aceitas e sequer dão satisfação, inclusive ignoram emails enviados diretamente pelos coordenadores de trilha de eventos!
+    * Isso foi sobre a disponibilidade de revisores. Daí temos a outra questão: a qualidade das revisões.
+      * Sempre ensinei também que existe uma diferença entre os veículos de publicação. Um workshop é diferente de um simpósio. Qualquer evento é diferente de uma revista. Existem trilhas, cada qual com requisitos específicos. Infelizmente, muitos revisores esquecem disso e tratam tudo com o máximo rigor.
+      * Uma revisão de qualidade não é aquela que aponta todos os defeitos de um artigo. Todo artigo possui defeitos e limitações! Isso, embora óbvio, não é um consenso entre revisores e, digo, até mesmo para coordenadores de programas e trilhas! Não que um revisor não deva apontar problemas no artigo, mas ele também deve ser construtivo e indicar caminhos para tratá-lo, quando possível. Afinal, o revisor possui experiência e uma visão externa (e com menos viés) sobre o trabalho em tela.
+      * Uma revisão de qualidade também deve apontar os pontos positivos. Dificilmente um artigo possui apenas problemas ou possui mais problemas do que aspectos positivos. Por traz de um artigo, temos seres humanos que pesquisam e é necessário reconhecer os bons aspectos dos trabalhos.
+      * Toda revisão possui uma avaliação. Não obstante, não é raro (na verdade, é frequente!) encontrar revisões que avaliam bem um artigo em que são apenas descritos problemas pelo revisor e que avaliam mal um artigo em que são apresentados apenas aspectos positivos ou aspectos negativos de pouca relevância. Pessoal, é necessário ser coerente na revisão! Se tem um ponto com avaliação ruim, justifique-o adequadamente! Não se preocupe em alterar sua avaliação apenas para buscar consenso. É importante a discussão entre os pares, mas também é esperada a divergência, fundamentada, entre os revisores! Também é esperada, durante a discussão, o reconhecimento de erros ou más interpretações (afinal, revisor também é um ser humano!) e as devidas correções da revisão e avaliação. No entanto, não é requisito ter um consenso entre as avaliações dos revisores. Revisores, deixem a decisão sobre a aceitação ou rejeição de um artigo para os coordenadores de trilha e de programa, esse é o papel deles!
+    * Por que este texto todo? Hoje (10 e 11/07/2024), os pesquisadores de Engenharia de Software conversaram sobre isso no grupo do Whatsapp, em uma linha/fio puxado pela Tayana Conte e com contribuições do Leonardo Murta, Marcos Kalinowski, Sergio Soares, Edna Dias Canedo, Rafael Prikladnicki, Juliana Saraiva, Eduardo Guerra e Everton Cavalcante. Fico feliz em ver essas discussões e perceber o alinhamento quanto aos pontos que expus acima. Acredito, aqueles pontos não são unanimidade, inclusive com colegas de trabalho.
+  * UUID
+    * Há! Aprendi mais algo interessante sobre UUID: https://www.ntietz.com/blog/til-uses-for-the-different-uuid-versions/. Existem várias formas de identificadores desse tipo! Mais informações no RFC 9562, aprovado neste ano: https://www.rfc-editor.org/rfc/rfc9562
+    * Em especial, fiquei interessado no UUID7, que gera um identificador "único", mas ordenável pela data em que foi criado.
+    * Para Python, ainda não foi incluída a implementação do UUID7 na biblioteca padrão: https://discuss.python.org/t/add-uuid7-in-uuid-module-in-standard-library/44390/8, https://github.com/python/cpython/issues/89083. No entanto, existem implementações de terceiros que quebram o galho por enquanto: https://pypi.org/project/uuid7/
 ===== SBPC =====