Ajustes na gestão dos autoconfirmados estendidos (24set2021)
A seguinte discussão encontra-se encerrada. Por favor não a modifique. Comentários posteriores devem ser feitos numa nova secção.Segue-se um resumo das conclusões obtidas nesta discussão.
Primeiro, essa proposta não tem intenção de mudar o que foi aprovado na votação. Os requisitos, nível de proteção continuam iguais. Busco apenas um ajuste na gestão do grupo de usuários.
Problema: na Wikipédia sempre trabalhamos com a ideia dos "estatutos redundantes", ou seja, "todo administrador é automaticamente autorrevisor", "todo eliminador é automaticamente autorrevisor", "todo administrador é automaticamente eliminador", "todo burocrata é automaticamente autoconfirmado", e etc, porque se um usuário é administrador ele é também autorrevisor, não é preciso colocar o usuário X nos grupos de autorrevisor e administrador quando ele é eleito em um WP:PDA, sendo administrador ele já é autorrevisor também. Fazemos isso porque é muito mais fácil gerir privilégios de um usuário que é só "administrador" do que de um usuário que é "autoconfirmado, autorrevisor, reversor, eliminador e administrador". Essa é a ideia dos "estatutos redundantes".
Acontece que quando criamos os "autoconfirmados estendidos", eles (no termo técnico, o privilégio extendedconfirmed) só foi adicionado aos administradores e aos robôs, o que significa que todos os outros usuários que tenham algum estatuto que obviamente requer um nível de confiança acima de autoconfirmado estendido (autorrevisores, eliminadores e burocratas) precisam ser "autorrevisores e autoconfirmados estendidos" ao invés de só "autorrevisores", "eliminadores e autoconfirmados estendidos" ao invés de só "eliminadores", "burocratas e autoconfirmados estendidos" ao invés de só "burocratas". Isso gera problemas porque vai contra o princípio comum dos "estatutos redundantes", por exemplo, se não há razão para eliminadores serem autorrevisores, há para serem autoconfirmados estendidos? Além disso, causa logs de privilégios maiores e com informações desnecessárias e é mais vulnerável a erros na gestão de privilégios porque sempre é preciso lembrar de afirmar (configurar, selecionar) "autoconfirmado estendido", caso contrário pode-se privar um eliminador de editar páginas protegidas, por exemplo (como já aconteceu).
Soluções: eu vejo duas maneiras para solucionar esse problema e acabar (ou pelo menos reduzir) essa proliferação completamente desnecessária de "autoconfirmado estendido" em toda lista de privilégios, gestão de privilégios, logs:
1) Inserimos extendedconfirmed para autorrevisores, eliminadores e burocratas. Fazendo isso, adotamos esses estatutos como redundantes ao de autoconfirmado estendido e, toda vez que um usuário for promovido para um deles (ou administrador, que já é redundante), removemos o grupo "autoconfirmado estendido";
Pontos negativos:
Se todos os grupos de usuário forem removidos de um usuário, é preciso adicionar novamente "autoconfirmado estendido", caso contrário o usuário não poderá editar páginas protegidas nesse nível;
Embora os logs fiquem mais limpos, continuarão existindo os logs de "promoções automáticas" e o "autoconfirmado estendido" continuará aparecendo na lista de grupos de um usuário até ser removido manualmente quando ele for adicionado em outro grupo.
ou
2) Definimos "autoconfirmados estendidos" como um grupo de usuários implícito. Fazendo isso, eles serão tratados da mesma maneira que os autoconfirmados "normais", ou seja, não aparecem em logs, nem em Especial:Privilégios. Serão geridos totalmente de maneira automática e no plano de fundo, sem aparecer em listas ou logs;
Pontos negativos:
Não vai ser possível remover "autoconfirmado estendido" de um usuário que já o tenha recebido;
(Não exatamente negativo mas) Precisaremos criar um grupo de "confirmados estendidos", similar aos "confirmados", só para gerir situações excepcionais.
Eu, particularmente, prefiro a opção 2 porque: a) é a mesma configuração dos autoconfirmados "normais", se não precisamos ser pipocados com alertas como "usuário x foi promovido para autoconfirmado" não há razão para isso acontecer com autoconfirmados estendidos, é irrelevante e até mesmo irritante; b) os autoconfirmados estendidos foram criados única e exclusivamente para criar o novo nível de proteção, não há a menor razão para que essa pequena alteração tenha como efeito colateral que um grupo cujos logs de promoção são pouquíssimo relevantes e que muito raramente precisará ser gerido de maneira manual fique aparecendo em todo tipo de log ou página especial; c) por mais que a solução 1 já melhore a situação, ela ainda manterá resquícios dos autoconfirmados estendidos em vários lugares, já na solução 2 tudo ficará muito mais limpo e organizado.
Não sei vocês, mas para mim esse negócio de "autoconfirmado estendido" aparecendo em todo canto é um negócio que atrapalha e até irrita, e se há como resolver isso sem alterar a funcionalidade, sinceramente, não vejo razão para não fazer. E, de novo, os critérios e a proteção não são alterados em nada. Essa proposta é mais sobre a gerência do estatuto. Perdão pelo texto longo, como sempre. stanglavine msg17h25min de 24 de setembro de 2021 (UTC)[responder]
Concordo com a proposta 1. Primeiramente, agradeço por ter aberto esta discussão, já que havia uma necessidade de corrigir este problema técnico que atingia estatutos redundantes. Desde a época da votação que definiu a criação do autoconfirmado estendido, já deixei até bem claro que a ideia seria a flag permanecer na conta do usuário até que um administrador ou burocrata o remova quando o mesmo se tornar autorrevisor. Por que esta foi minha avaliação? Porque a flag teve o objetivo apenas de priorizar contas acima de 500 edições (não-autorrevisores) a editarem em artigos que sejam protegidos a nível superior a de autoconfirmado e inferior de autorrevisor. Portanto, não faria sentido que um usuário que já seja autorrevisor ou estatuto superior a este continue sendo autoconfirmado estendido. Devido essa tamanha redundância, a proposta 1 se encaixa perfeitamente no modelo que eu gostaria que fosse aplicado desde a criação do estatuto.
Em relação aos "pontos negativos", caso um usuário perca todos os estatutos superiores, realmente teria que voltar a colocá-lo como autoconfirmado estendido (já que a proposta permite que todos acima de 500 edições tenham essa flag). No entanto, caso um administrador/burocrata não coloque e esta conta voltar a fazer uma edição, o estatuto é adicionado automaticamente. Por que estou dizendo isso? Basta ver que inúmeras contas inativas antes da criação deste estatuto e com número superior a 500 edições já receberam a flag automaticamente ao fazer uma nova edição na atualidade. A proposta 1 tende a corrigir pontos que sequer foram discutidos na proposta original. WikiFermsg18h22min de 24 de setembro de 2021 (UTC)[responder]
@WikiFer: obrigado pelos comentários. Sobre a "reatribuição", na verdade não, de acordo com a documentação o estatuto não é reatribuído se ele foi removido no passado, isso precisaria ser feito manualmente. Mas lendo seu comentário eu percebo que a solução 2 também atende o que você procura, mas com a vantagem de ser muito mais simples porque os grupos implícitos são geridos automaticamente em plano de fundo e nunca precisam de qualquer ação (ou possibilidade de ação) de um humano, por isso são mais seguros, geram logs mais limpos, e consequentemente são mais práticos. É o próprio MediaWiki gerenciando completamente a permissão. Os grupos implíticos são usados justamente quando precisamos de um grupo de usuários para uma função muito específica, como é o caso dos autoconfirmados estendidos, cuja única função é o nível de proteção. É por essa razão, por exemplo, que os autoconfirmados "normais" (que até englobam mais permissões) são implícitos por padrão. stanglavine msg23h31min de 27 de setembro de 2021 (UTC)[responder]
@Stanglavine Neste caso, o estatuto sendo implícito, automaticamente todos os usuários que chegarem nas 500 edições, receberia a flag e estes poderão editar em artigos protegidos a nível de cadeado verde? Bom, se for nesta situação, eu concordo com a proposta 2. O que fez eu ficar na dúvida foi você ter dito que precisaria criar um grupo de "confirmados estendidos". Esta seria a nova nomenclatura para quem chegar nas 500 edições e ter os mesmos direitos que os autoconfirmados estendidos atuais possuem? WikiFermsg18h36min de 28 de setembro de 2021 (UTC)[responder]
@WikiFer: sobre a primeira pergunta, sim, nada muda sobre isso. Sobre a segunda, o grupo continuaria sendo "autoconfirmados estendidos", os confirmados extendidos (sem o "auto") serão só um grupo adicional (como os confirmados são para os autoconfirmados) que existirá apenas para resolver problemas temporários (caso precisarmos por alguma razão atribuir a permissão manualmente para alguma conta antes das 500 edições), o mesmo processo que fazemos quando atribuímos hoje "confirmado" para livrar algum usuário dos filtros, só que será "confirmado extendido" e servirá para livrar da proteção. stanglavine msg19h19min de 28 de setembro de 2021 (UTC)[responder]
@Stanglavine Agora tá explicado. A proposta 2 é melhor mesmo, até servirá para que sua atribuição aconteça em casos excepcionais. O exemplo dos filtros em relação a um usuário "confirmado" esclareceu bem a importância da proposta 2 no que diz respeito ao "confirmado estendido". Acredito que há um consenso. WikiFermsg20h39min de 28 de setembro de 2021 (UTC)[responder]
Comentário Excelente proposta, sinceramente eu também tinha a mesma opinião do WikiFer ou seja, imaginemos que um editor passava a autorrevisor retirava-se o autoconfirmado estendido, pois o mesmo pode editar nas páginas protegidas de autoconfirmado, autoconfirmado estendido e autorrevisor, logo sendo autorrevisor não vejo necessidade de estar no privilégios, que o mesmo também é autoconfirmado estendido, pois sendo autorrevisor englobaria. Como foi dito pelo proponente Stanglavine isso já acontece com os administradores, que não tem a flag de eliminador. Posto isso Concordo com ambas as propostas, pois creio que vá dar ao mesmo (peço que corrigem-me se estiver errado), pois a ideia é que ambas as propostas 1 e 2 vai dar ao mesmo que é (tirar as flags de autoconfirmado estendido aos editores que sejam já autorrevisores, administradores, eliminadores, burocratas, verificadores...). --Duke of Winterfell(Msg)13h10min de 25 de setembro de 2021 (UTC)[responder]
@Duke of Winterfell: Olá, só para clarificar sim, ambas ajudam a resolver o problema, mas a solução 2, que é a que eu defendo, é muito mais eficiente pois converte os autoconfirmados estendidos em um grupo implícito, o que torna mais seguro e prático gerenciar a permissão e também é mais simples do que ficar replicando permissões em vários outros grupos e lembrando de adicionar ou remover sempre que os estatutos de algum usuário mudarem. Se o estauto foi criado para ser automático, então que seja totalmente automático, não há razão para mantê-lo como um grupo normal como todos os outros que gerenciamos manualmente. Eu fiz a proposta 1 mais como backup para o caso de haver alguma limitação técnica para a implementação da 2, mas pelo que andei investigando a proposta 2 é viável e, se o for, não vejo razão para não ser preferida. stanglavine msg23h40min de 27 de setembro de 2021 (UTC)[responder]
Concordo com a proposta 2. O único aspecto negativo dela é a não remoção. Mas considero que apenas casos excepcionais de editores com mais de 500 edições poderiam ser problemática para a proteção em questão, nada que a administração não poderia demandar posteriormente a proteção a nível autorrevisor se necessária, portanto não há porque remover o estatuto. De bem verdade, é praticamente sem privilégios que não seja o sistema de proteção adicional de páginas, portanto, considero melhor a 2 que poupa a visualização constante da atribuição da flag nos logs das mudanças recentes sem necessidade.--Werewolfpois não?14h33min de 25 de setembro de 2021 (UTC)[responder]
Apoio a proposta 2, na escala de confiança da comunidade o estatuto de autoconfirmado extendido encontra-se abaixo de autorrevisor, é redundante então não tem como não estar incluído automaticamente aos autorrevisores, aplicando-se depois a todos os editores cujo estatuto de autorrevisor é redundante. Mas pode com toda a vantagem ser um estatuto implícito, como o autoconfirmado. DuxÆ22h22min de 2 de outubro de 2021 (UTC)[responder]
