Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
work:semana_30_de_2021 [2021/07/28 02:48] – magsilva | work:semana_30_de_2021 [2021/07/28 21:53] – magsilva |
---|
* Reunião com [[Yuri Rafael Grajefe Feitosa]]: revisão do PDM. | * Reunião com [[Yuri Rafael Grajefe Feitosa]]: revisão do PDM. |
* Submissão de artigo do [[Bruno Henrique Pachulski Camara]] no SAST 2021. | * Submissão de artigo do [[Bruno Henrique Pachulski Camara]] no SAST 2021. |
* Leitura de artigos: | * Leitura de artigos sobre revisão de artigos: |
* "Pains and Gains of Peer-Reviewing in Software Engineering" (doi:10.1145/3375572.3375575). | * "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 (4)" (doi:10.1109/ICSE-C.2017.49) |
* "A community’s perspective on the status and future of peer review in software engineering" (doi:10.1016/j.infsof.2017.10.019). | * "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. | * "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. |
| * "Peer Review: Trust and Prejudice" (doi:10.1145/3417564.3417569). |
* Considerando a maratona de artigos acima, de nota temos o site de Empirical standards da ACM: https://acmsigsoft.github.io/EmpiricalStandards/. Será utilizado na disciplina de Tópicos em Engenharia de Software -- Revisão sistemática. | * Considerando a maratona de artigos acima, de nota temos o site de Empirical standards da ACM: https://acmsigsoft.github.io/EmpiricalStandards/. Será utilizado na disciplina de Tópicos em Engenharia de Software -- Revisão sistemática. |
* Disponibilização do Code Defenders em http://dacom.cm.utfpr.edu.br/codedefenders. | * Disponibilização do Code Defenders em http://dacom.cm.utfpr.edu.br/codedefenders. |
* Reunião com [[Vinicius Bosa Petris]]: configuração do Code Defenders. | * Reunião com [[Vinicius Bosa Petris]]: configuração do Code Defenders. |
| * Reunião com [[Rampim Soratto]]: apresentação dos resultados da análise de código e revisão da ferramenta. |
| * Leitura do artigo "An Interview with Laurie Williams - ACM Fellow 2020 (doi:10.1145/3468744.3468750). Entrevista com Laurie Williams, uma pesquisadora de destaque e muito ativa em Engenharia de Software, com um trabalho especialmente próximo da indústria. Um bom exemplo de profissional: completo, com ótima atuação tanto na pesquisa quanto no ensino. |
| |
===== Educação ===== | ===== Educação ===== |