Wikipédia:Esplanada/Arquivo/2017/Fevereiro

Arquivos da Esplanada

2004	2005	2006	2007	2008
Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro

2009	2010	2011	2012	2013
Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro

2014	2015	2016	2017	2018
Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro

2019	2020	2021	2022	2023
Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro

2024	2025	2026	2027	2028
Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro	Janeiro Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro

Anúncios

Wikimedia Foundation is hiring community members as strategy coordinators

Hello all! At the moment, the Wikimedia Foundation is hiring 20 contractors - 17 strategy coordinators for specialized languages and 3 Metawiki coordinators. I was am posting this on your noticeboard to reach out to any Portuguese Wiki community members who would be both interested in being a part time contractor with us for three months and a good fit for the movement strategy facilitation roles. Even if you are not personally interested in the position, we would appreciate your assistance in encouraging community members to apply, either individually or with local wiki announcements. You can find the Job Description for the position at this page. There is a less-formal description of the tasks they would be working on here on Meta. Kbrown (WMF) (discussão) 19h17min de 6 de fevereiro de 2017 (UTC)

Wikipédia:Administradores/Pedidos de aprovação/Hume42

Anuncio a todos que nomeei o editor Hume42 ao cargo de Administrador. Eta Carinae (discussão) 21h05min de 8 de fevereiro de 2017 (UTC)

Wikipédia:Votações/YouTube

Criei a página acima para futura votação sobre a presença do YouTube na Spam-blacklist. Discussão em Wikipédia Discussão:Votações/YouTube. GoEThe (discussão) 14h31min de 9 de fevereiro de 2017 (UTC)

Edit-a-thon Neurociência e Matemática III & Grupo de Usuários Wikimedia no Brasil

No dia 13 de março de 2017, teremos a III Maratona de Edição Neurociência e Matemática que busca integrar usuários experientes e iniciantes para editar a versão em português da Wikipédia no CEPID NeuroMat. A editatona será realizada no laboratório de computação do NeuroMat, localizado na Avenida Professor Luciano Gualberto, 1171, no campus da USP, prédio do NUMEC/IME, em São Paulo (SP). Para mais informações, entre em contato com o Grupo de Usuários Wikimedia no Brasil ou a equipe de comunicação do CEPID NeuroMat. Para você que queria se inscrever, visite a página do evento aqui!

• Proposta: Tópicos de neurociência e matemática, precedidos por um treinamento de curta duração para a utilização das plataformas abertas, especialmente a Wikipédia, em difusão científica.
• Organização e mobilização: NeuroMat (apoio FAPESP) / Grupo de Usuários Wikimedia no Brasil
• Data do edit-a-thon: 13 de março de 2017, às 14:00
• Local: NeuroMat - Avenida Professor Luciano Gualberto, 1171 - Cidade Universitária, USP - São Paulo 05508-090
• Material de apoio: Wikipédia de A a Z
• Página do evento: Aqui

Convidamos a todos a colaborarem com o edit-a-thon e a compartilharem os posts em suas redes sociais. Aqueles que moram em São Paulo serão muito bem-vindos!

Essa é mais uma ação do Grupo de Usuários Wikimedia no Brasil. Vitor Mazuco^Msg 12h44min de 11 de fevereiro de 2017 (UTC)

Revisão de atualizações iniciais no processo de estratégia do movimento Wikimedia

O movimento Wikimedia está começando uma discussão de estratégia com todo o movimento, um processo que ocorrerá durante 2017. Por 15 anos, Wikimedistas têm trabalhado juntos para construir o maior recurso de conhecimento livre da história humana. Durante esse período, temos crescido de um pequeno grupo de editores até uma rede diversa de editores, desenvolvedores, afiliados, leitores, doadores e parceiros. Hoje, somos mais do que um grupo de sites. Somos um movimento baseado em valores e uma poderosa visão: todo o conhecimento para todas as pessoas. Como movimento, temos uma oportunidade de decidir para onde vamos daqui.

Essa discussão sobre a estratégia do movimento será focada no futuro de nosso movimento: aonde queremos ir juntos e o que queremos atingir. Nós pretendemos desenhar um processo inclusivo que tenha espaço para todos: editores, líderes comunitários, afiliados, desenvolvedores, leitores, doadores, plataformas de tecnologia, parceiros institucionais e pessoas que ainda não atingimos. Haverá múltiplas maneiras de participar incluindo na wiki, em espaços privados e em reuniões face a face. Você está carinhosamente convidado para juntar-se ao processo e fazer a sua voz ser ouvida.

O objetivo imediato é ter uma direção estratégica até o Wikimania 2017 para ajudar a estruturar a discussão sobre como trabalhamos junto em direção a essa direção estratégica.

Atualizações periódicas estão sendo enviadas para a lista de e-mails Wikimedia-l e postadas na Meta-Wiki. Começando com essa mensagem, revisões mensais serão enviadas para essa página também. Registre-se para receber futuros anúncios e destaques mensais das atualizações estratégicas em sua página de usuário.

Aqui está uma revisão das atualizações que foram enviadas até agora:

• Atualização 1 no processo de estratégia do movimento Wikimedia (15 de dezembro de 2016)
  • Introdução ao processo e informação sobre a resolução de gasto do orçamento para apoiá-lo
• Atualização 2 no processo de estratégia do movimento (23 de dezembro de 2016)
  • Início da busca pelo arquiteto líder do processo de estratégia do movimento
• Atualização 3 no processo de estratégia do movimento Wikimedia (8 de janeiro de 2017)
  • Planos para sessões de estratégia na Conferência Wikimedia 2017
• Atualização 4 no processo de estratégia do movimento Wikimedia (11 de janeiro de 2017)
  • Apresentação da williamsworks
• Atualização 5 no processo de estratégia do movimento Wikimedia (2 de fevereiro de 2017)
  • O time central de estratégia do movimento, "trilhas" diferentes de times sendo desenvolvidas, introdução do Comitê de Direção do Processo Comunitário, discussões na conferência WikiIndaba 2017 e os diretores executivos dos movimentos Wikimedia afiliados se reunindo na Suíça.
• Atualização 6 no processo de estratégia do movimento Wikimedia (10 de fevereiro de 2017)
  • Protótipos dos processos para as "trilhas" A & B e trazendo comentários, atualizações no desenvolvimento das quatro trilhas

Mais informações sobre a estratégia do movimento está disponível no portal de estratégia do movimento Wikimedia 2017 na Meta-Wiki

Enviado pelo MediaWiki message delivery em nome da Wikimedia Foundation, 20:30, 15 de fevereiro de 2017 (UTC)• Ajude a traduzir para a sua língua, por favor • Peça ajuda

Fiz a tradução da mensagem, peço que alguém revise e depois trocamos a mensagem em inglês aqui pela tradução. Chico Venancio (discussão) 11h44min de 16 de fevereiro de 2017 (UTC)

Ainda não houve revisão completa, mas eu coloco a tradução que fiz e se houver alguma alteração na revisão modificamos aqui também. Chico Venancio (discussão) 13h32min de 18 de fevereiro de 2017 (UTC)

Palestra - O Uso da Wikipédia na Educação

Olá, a todos! No próximo dia 13 de março, a diretora de programas e vice-diretora da Fundação Wiki Education LiAnna Davis dará uma palestra na USP com o tema O Uso da Wikipédia na Educação. A palestra será seguida pela III Maratona de Edição Neurociência e Matemática, no CEPID NeuroMat, já anunciada anteriormente nessa página. Para mais informações, entre em contato com o Grupo de Usuários Wikimedia no Brasil ou a equipe de comunicação do CEPID NeuroMat. Para se inscrever, visite a página da Maratona de Edição aqui.

O USO DA WIKIPÉDIA NA EDUCAÇÃO

• Data da palestra: 13 de março de 2017, às 10:00
• Local: Auditório Professor Oswaldo Fadigas Fontes Torres, localizado na Travessa 3 da Av. Professor Luciano Gualberto, 71, Cidade Universitária - São Paulo, SP
• Página do evento: Aqui
• Organização: CEPID NeuroMat (apoio FAPESP) e Grupo de Usuários Wikimedia no Brasil.

Convidamos a todos a participarem da palestra e a compartilharem o evento em suas redes sociais.

Essa é mais uma ação do Grupo de Usuários Wikimedia no Brasil.

Wikipédia:Administradores/Pedidos de aprovação/Mr. Fulano

Venho dizer que abri um pedido a administrador. Mr. Fulano! ^{🔔Fale Comigo📩} 16h20min de 17 de fevereiro de 2017 (UTC)

Páginas mais editadas em 2016

Olá pessoal. Acabei de publicar os resultados das páginas mais editadas em 2016:

• Research:Top edited Portuguese Wikipedia articles in 2016.

Pretendo estender esse estudo em um novo estudo, com mais visões sobre a popularidade das páginas, mas já dá para considerar esse resultado inicial. Deixo o link aqui caso queiram visualizar os números. Boas contribuições, --Diego Queiroz (discussão) 23h31min de 17 de fevereiro de 2017 (UTC)

Excelente trabalho, há de se ponderar que os resultados são visivelmente diferentes da pesquisa sobre os artigos mais visitados do ano passado, porém os temas continuam semelhantes. Christian ^msg 02h59min de 18 de fevereiro de 2017 (UTC)

Parabéns pela iniciativa! Vitor Mazuco^Msg 12h31min de 18 de fevereiro de 2017 (UTC)

Informações sobre a pesquisa global da Fundação Wikimedia, a qual está acontecendo agora mesmo

Olá! Meu nome é Edward Galvez, e eu trabalho para a Fundação Wikimedia. Caso vocês ainda não saibam, a Fundação Wikimedia trabalha no software e nas tecnologias que mantêm nossos sites rápidos, seguros e acessíveis. A Fundação também trabalha em programas e iniciativas para apoiar e expandir o acesso ao conhecimento livre no mundo todo.

Como alguns de vocês podem ter visto nas suas páginas de discussão, a Fundação está atualmente realizando uma pesquisa global para saber mais sobre as experiências e os comentários dos usuários. Estou escrevendo este mensagem pois queria compartilhar com vocês um pouco mais sobre o nosso projeto. Essa pesquisa chama-se “Insights de Envolvimento com a Comunidade”, e será conduzida anualmente. Enviamos essa pesquisa para editores de todos os projetos da Wikimedia, bem como para afiliadas e desenvolvedores voluntários. Esta pesquisa será a nossa maneira de certificação de que seus comentários serão ouvidos. A pesquisa é nova, e planejamos melhorá-la com o passar dos anos, tanto nas perguntas quanto no design.

Vocês podem se cadastrar para receberem notificações sobre os resultados da pesquisa ou para saber mais sobre como ajudar no planejamento da pesquisa do ano que vem.

Caso algum de vocês tenha perguntas ou dúvidas sobre este projeto, envie-nas à minha página de discussão no Meta ou ao meu e-mail EGalvez (WMF) em qualquer idioma. Saibam mais sobre este projeto (em inglês) e leiam as perguntas frequentes (em inglês). Compartilhem seus comentários no Meta. Obrigado! --EGalvez (WMF) (talk) 16h20min de 19 de fevereiro de 2017 (UTC)

Aberta a votação sobre YouTube na Spam-blacklist

Caso tenham direito ao voto, manifestem-se em Wikipédia:Votações/YouTube. Obrigado, GoEThe (discussão) 09h10min de 20 de fevereiro de 2017 (UTC)

Início das atividades no projeto Arqueologia

Colegas, anúncio com entusiasmo que iniciamos as atividades no Projeto Arqueologia. Contamos com a participação de vocês para tornar esse projeto um sucesso. Boas escavações a todos! --Hume42 ✉ 17h34min de 21 de fevereiro de 2017 (UTC)

Embora aprecie o seu entusiasmo Hume42, vejo como inexorável o dia em que marcaremos {{Wikiprojeto inativo}} nessa página que acabou de criar. Você não estava aqui na época, não sei se chegou a ler essas discussões, mas houve um projeto em 2012, Wikiprojeto 2.0, que, ante ao lastimável estado em que esses se encontravam (e literalmente ainda estão), propunha simplesmente desativá-los e substituir por wikiprojetos gerais. Daí surgiram os atuais Wikipédia:Projetos/Geografia e Wikipédia:Projetos/Entretenimento. A ideia em si dos projetos, como explicitada em Wikipédia:WikiProjeto é uma daquelas besteiras inocentes da Wikipédia de 2007; simplesmente não funciona. Temos usuários de menos para a necessidade de um espaço centralizado de discussão e distribuição de tarefas. Dos próprios projetos pós-2.0, o único que funciona numa maior regularidade é o História e sociedade, o qual incluí a sua área de edição pretendida. Repito, aprecio o seu entusiasmo (e espero que gere bons frutos), mas sugiro que desista da ideia e dirija-se ao História e sociedade com qualquer dúvida ou pedido que tiver. - Épico (disc)/(contrib) 22h20min de 21 de fevereiro de 2017 (UTC)

@Épico: Olhe que eu não tenho a certeza que isso funcione assim. Eu, no meu caso, tenho muito interesse por Arqueologia, mas não tenho interesse nenhum em participar em algo tão geral como "História e Sociedade".-- Darwin ^Ahoy! 22h29min de 21 de fevereiro de 2017 (UTC)

@Épico: Obrigado pela informações, não conhecia o Wikiprojeto 2.0 e os problemas que os projetos fragmentados trazem, e igualmente pela sinceridade. Estou ciente de todos os desafios, e que a história wikipediana nos diz que a tendência é o fracasso. Porém estou na iniciativa do projeto arqueologia pois no meio desse turbilhão de insucessos, existe um projeto que se mantêm firme e forte: o de Aviação, e se um deu certo quem sabe os outros não dão? Sei que se muito não passaremos de uns 8 membros ativos, mas já consideraria um sucesso se tivesse mais uns dois membros engajados além de mim, e por enquanto temos o Darwin e o Luz28 que parecem estar animados. Mas se ficar apenas eu trabalhando, sem problemas, terei o prazer de fazer o desafio, e seria interessante ter uma "central" onde os artigos estão classificados e existe a lista do que fazer, ainda que estivesse sozinho. Como o Darwin, acho que generalizar os projetos não é tão motivador assim, prefiro especificar. Obrigado pela recomendação, mas inicialmente não irei desistir, ainda mais porque se as pessoas verem que existe algum movimento em um projeto, é possível elas se interessarem. Abandono gera abandono, iniciativa gera iniciativa. E já criei uma lista que espero dar bons frutos! --Hume42 ✉ 00h24min de 22 de fevereiro de 2017 (UTC)

@Hume42: como crítico que sou da estagnação em que se transformou a Wikipédia lusófona, quero parabenizar a sua iniciativa. Eu ia justamente comentar sobre o "Projeto Aviação", que me parece ser bem sucedido. Não sei porque ainda ainda não me inscrevi nele (sendo o meu metier) mas vou fazê-lo agora. Também quero fazer parte do "Arqueologia", mesmo não estando entre meus temas prediletos e pode contar comigo para o que precisar. Eu acho que em parte, esses projetos foram sendo abandonados pois vários editores bem ativos infelizmente faziam parte de esquemas de sock's, e outros foram desanimando, não tenho bem certeza. Mas fato é que havia projetos com excelentes propostas e vi alguns que foram bem longe antes de pararem. Ainda creio na perseverança de alguns para melhorar esta enciclopédia, que ultimamente parece ter se transformado em um simples QG de administradores que gastam seu tempo "caçando" vandalismos (realmente cada vez mais intensos) e às vezes um campo de batalha com discussões imensas e absolutamente inócuas, enquanto inúmeros artigos e regras estão "congelados", sem qualquer atualização, cheios de problemas, falta de padronização, etc. Comparo a WP lusófona (não sei das outras) a uma "colmeia com muitas abelhas rainhas e poucas obreiras". Isto não é crítica destrutiva nem nada que possa ser entendido como "difamação" ou coisas do tipo. É uma opinião sincera que quero externar, no intuito de "despertar" opiniões. Iniciativas como a sua me fazem ainda ter esperança de ter mais qualidade neste projeto. PauloMSimoes (discussão) 01h03min de 22 de fevereiro de 2017 (UTC)

Geral

[Ver]

Diretório de portais

Pra quê serve o Wikipédia:Portal/Diretório? Essa página está lincada no Portal comunitário, mas nunca entendi qual é a sua função aqui pois a própria página não é capaz de explicar. A seção "Portais existentes" faz o mesmo papel do Portal:Índice, cuja finalidade é listar os portais existentes na pt-wiki (muito embora este último esteja bastante incompleto). Já o restante da página tem a mesma função que o Wikipédia:Projetos/Portais (sugerir portais para criar, manutenção de portais, etc).

Também não entendo o que significa aquele quadro chamado "Voluntários/manutenção" da seção "Portais existentes" com nomes de usuários ao lado do portal listado. Isso parece passar a estranha impressão de que aqueles portais possuem um dono. O correto seria colocar o nome do Wikiprojeto relacionado ao portal. --Lord Mota^✠ 18h04min de 4 de fevereiro de 2017 (UTC)

Lord Mota também creio que há muitas páginas para uma mesma finalidade, isto mostra a necessidade de os usuários menos comprometidos com a criação de artigos e que gostem de realizar manutenções façam revisões destas páginas de conteúdo necessários para a organização da Wikipédia. Quanto aos nomes dos users estes são voluntários assim como eu que realizo manutenções nos portais, não são os donos das páginas sendo que há mais de um voluntário em alguns portais, a ideia de por o portal relacionado à algum projeto, não iria funcionar pois a maioria dos projetos do Wikipédia Lusófona estão inativos com poucas exceções como os projetos que eu participo (WP:Projetos/Aviação, WP:Projetos/Ferrovipédia, WP:Projetos/Ufologia e WP:Projetos/Naval). Rodrigo, Luz28 ^(MsG) 15h54min de 6 de fevereiro de 2017 (UTC).

Haveria alguma oposição se eu marcasse esse Wikipédia:Portal/Diretório como {{Arquivo histórico}}? --Lord Mota^✠ 18h37min de 11 de fevereiro de 2017 (UTC)

[Ver]

Ponto final na discussão

Boa noite, gostaria de colocar um ponto final na discussão iniciada em 2012: Wikipédia:Fusão/Central de fusões/Partições do escudo (heráldica); Partes do escudo (heráldica). Acredito que meus argumentos são os mais coerentes em toda a discussão. Partições do escudo (heráldica) é relatado ao artigo en:Division of the field, enquanto que o artigo Partes do escudo (heráldica) é relatado ao artigo en:Escutcheon (heraldry). Além disso, o nome mais apropriado para o artigo Partições do escudo deveria ser Partições do campo. Renan ASR (discussão) 03h55min de 7 de fevereiro de 2017 (UTC)

Tópico encerrado, ver em: Wikipédia:Fusão/Central de fusões/Partições do escudo (heráldica); Partes do escudo (heráldica) Renan ASR (discussão) 04h36min de 12 de fevereiro de 2017 (UTC)

[Ver]

Usuário sem estatuto de autorrevisor pode usar a userbox?

Por curiosidade acessei a Categoria:!Autorrevisores sem pedido e encontrei um usuário que estava lá, mas não tem o estatuto isto pode acontecer? O nome dele aparece por ele estar utilizando em sua PU a WP:Userbox/Autorrevisor. Rodrigo, Luz28 ^(MsG) 19h03min de 8 de fevereiro de 2017 (UTC).

Não. A userbox foi criada com fins de identificação e, portanto, não ter o estatuto mas mesmo assim usar a userbox confunde outros editores. A prática comum, nestes casos, é retirar a userbox, indicando no sumário os motivos. Érico (fale) 19h40min de 8 de fevereiro de 2017 (UTC)

Então Érico eu identifiquei 8 usuários que utilizam mas não possuem o estatuto!
Alberto79
Diosthenes Junior/Testes
JardelW
Neistron
Patricia CV
SamuelColaborador
WrFerreira
Yuregf
Rodrigo, Luz28 ^(MsG) 19h52min de 8 de fevereiro de 2017 (UTC).

Alberto79 era. Deve ter esquecido de remover.
JardelW é autorrevisor e reversor.
Os demais nunca foram. Érico (fale) 19h56min de 8 de fevereiro de 2017 (UTC)

Desculpe a minha ignorância Érico, mas no fastbuttons sobre a conta do JardelW não diz que ele é um Autorrevisor, diz somente que ele é Eliminador, Isento de bloqueio de IP e Reversor. Rodrigo, Luz28 ^(MsG) 20h04min de 8 de fevereiro de 2017 (UTC).

Luz28, não aparece porque o estatuto de eliminador já inclui o de autorrevisor. Eta Carinae (discussão) 20h11min de 8 de fevereiro de 2017 (UTC)

Ok EVinente! Obrigado aos dois por me esclarecer!  Curti Rodrigo, Luz28 ^(MsG) 20h13min de 8 de fevereiro de 2017 (UTC).

[Ver]

Acho que detectei um vandalismo muito antigo

Ao pesquisar "Lista de presidentes dos Estados Unidos" no Google para achar o artigo em português, a primeira coisa com que me deparo é isso: Lista de presidentes dos Estados Unidos no Universo DC. A existência desse artigo é um vandalismo que perdura por 7 anos, e seu conteúdo é totalmente nonsense. Já o marquei para eliminação rápida.

Aliás, já existe o artigo Lista de presidentes dos Estados Unidos, mas este não apareceu no topo da pesquisa do Google. Holy Goo (discussão) 13h57min de 9 de fevereiro de 2017 (UTC)

[Ver]

Uso do Daily Mail como fonte banido da en:wiki

Tropecei nessa reportagem por acaso enquanto fazia umas pesquisas. Penso que seria importante abrir uma discussão sobre o assunto por aqui também, uma vez que o Daily Mail é usado como fonte em 2397 artigos. O que acham?-- Leon Saudanha 22h07min de 9 de fevereiro de 2017 (UTC)

@Leon saudanha: Realmente parece não haver dúvidas na Wiki-en de que o periódico não é fonte fiável, chegando inclusivamente a fabricar notícias. Concordo que seja interditado como fonte aqui. Os artigos onde ele já é usado devem também ser revistos, na medida do possível, para eliminar essa referência de lá.-- Darwin ^Ahoy! 23h45min de 9 de fevereiro de 2017 (UTC)

Darwinius mas isso não vai parar ai, melhor esperarmos o desenrolar da história por lá.-- Leon Saudanha 00h09min de 10 de fevereiro de 2017 (UTC)

Vocês poderiam colocar o link da discussão da en-wiki onde se decidiu isso, por favor? --Lord Mota^✠ 00h26min de 10 de fevereiro de 2017 (UTC)

Lord Mota aqui.-- Leon Saudanha 00h36min de 10 de fevereiro de 2017 (UTC)

Muito interessante! A minha primeira reação foi concordar que deveríamos fazer o mesmo que na EN... Mas...... Quantos sites infinitamente mais manhosos é que teríamos que banir se quisermos ser coerentes? Quantos artigos há por aí que só têm fontes muito mais manhosas que o Daily Mail? Por exemplo, quantas biografias de "nobres", genealogia e afins é que, por isonomia, deveriam ser sumariamente passadas a ER por só usarem sites de fiabilidade mais que duvidosa? Ao que me lembro, por exemplo, a geneAll, continua por banir. --Stego (discussão) 01h18min de 10 de fevereiro de 2017 (UTC)

@Stego: O Geneall não foi banido? Há muito tempo que deixei de ver esses links nos artigos, e agora desde que o site passou a ser de acesso pago, já nem os colocam mais, graças a Deus. Nessa discussão da Wiki-en foi proposta a elaboração de uma espécie de Index que conteria uma lista de fontes de fiabilidade duvidosa, penso que isso seria interessante fazer aqui.

Para quem quiser ler, o artigo original no Guardian está aqui.-- Darwin ^Ahoy! 07h38min de 10 de fevereiro de 2017 (UTC)

O grande perigo nestes banimentos é que o pessoal corre a tirar as referências, mas deixa a informação ou com um {{carece de fontes}} ou mesmo sem nada. Isso ainda é pior do que ter uma fonte duvidosa. GoEThe (discussão) 10h06min de 10 de fevereiro de 2017 (UTC)

Sim, é bem pior. Por isso que eu sugeri a interdição do uso dessa fonte, mas não a sua remoção imediata dos artigos. E mesmo essa "interdição" seria apenas uma recomendação, já que o Daily Mail pode ser fonte fiável em algumas circunstâncias, especialmente relacionadas com o próprio jornal. O caso do Geneall é diferente - É um site comercial, de notoriedade duvidosa (pelo menos actualmente), e sem grande revisão de conteúdos. Tem alguma utilidade como ferramenta para quem faz genealogia, mas não pode em circunstância alguma ser usado como fonte.-- Darwin ^Ahoy! 10h40min de 10 de fevereiro de 2017 (UTC)

Também concordo que é preferível o Daily Mail a ausência de fonte. --Stego (discussão) 12h23min de 10 de fevereiro de 2017 (UTC)

Contra A colocação desse site na black-list, creio que isso é uma atitude bem extrema. Nenhum jornal ou site é de fato 100% confiável, todos eles tem o seus erros e falhas, uns mais outros menos, mas todos tem. E o Daily Mail não é diferente. Vitor Mazuco^Msg 15h20min de 10 de fevereiro de 2017 (UTC)

Comentário Mediante a estas preocupações, não seria melhor desencorajar o uso destas fontes ao invés de proibir, e recomendar a substituição de referências duvidosas ao invés da remoção (se possível)? Estou até pensando em dar uma olhada em alguns destes 2000+ artigos para ver que outras fontes poderiam se substituídas... --Luk3^{🔔• 📖} 20h04min de 10 de fevereiro de 2017 (UTC)

Comentário @Luk3: pode ser, boa ideia! Vitor Mazuco^Msg 20h22min de 10 de fevereiro de 2017 (UTC)

[Ver]

Alterar ordem da informação nas "Paginas vigiadas", "Mudanças Recentes" e eventualmente em outras idênticas

Proponho que a PT.WP use a ordem mais usada (pelo menos nas maiores Wikipedias e no Commons), i.e:

• (dif | his) . . !/N/m Título da página; HH:MM (+117) . . Usuario (discussão | contribs) (Resumo da edição) (Etiquetas: nnnnnn)

Não pretendo dizer que devemos copiar os outros, mas, não havendo razões pertinentes porque não seguir as normas da maioria? Facilitaria muito a vida a quem faz buscas frequentes em várias wikis --JotaCartas (discussão) 20h37min de 10 de fevereiro de 2017 (UTC)

@JotaCartas: Não percebi qual seria a mudança, pois a ordem proposta parece ser a mesma que vejo ao acesso Especial:Mudanças recentes.

Por acaso alterou alguma das preferências? Helder 11h31min de 11 de fevereiro de 2017 (UTC)

@Helder:Obrigado pela resposta. Segue um ex. da forma como vejo a página Especial:Mudanças recentes:

• 17h12min Usuário:André Koehne/teste‎ (dif | his) . . (+2 784)‎ . . André Koehne (discussão | contribs) (→‎Muñecaria: repositório aleatório)

Recentemente não alterei as minhas preferências, mas é possível que o tenha feito há já algum tempo. Vou fazer alguns testes a ver se descubro a razão da diferença, mas se entretanto alguém já passou pelo mesmo agradeço ajuda. Obrigado --JotaCartas (discussão) 17h24min de 11 de fevereiro de 2017 (UTC)

Done - Desmarquei o item: Preferências -> Mudanças Recentes -> ’’Agrupar alterações por página nas mudanças recentes e páginas vigiadas. --JotaCartas (discussão) 18h19min de 11 de fevereiro de 2017 (UTC)

[Ver]

Interpor um pedido de permissão para um Recomeço limpo!

Como interpor um pedido de Notificação e permissão para um recomeço limpo como está em WP:Recomeço limpo?

Lá diz o seguinte:

Se você não estiver sob sanções, não é necessário notificar ninguém de seu recomeço limpo. Entretanto, poderá ser útil notificar os verificadores e confirmar que não há problemas óbvios em seu processo de recomeço limpo. Isto reduzirá o risco de más-interpretações que poderiam resultar em investigações e discussões "por trás das cenas", e lhe ajudaria em recorrer de uma sanção ou bloqueio equívoco por criar uma conta alternativa. Se estiver sob sanções, é de fato necessário notificar os verificadores. Atente-se que ninguém pode dar-lhe permissão para um recomeço limpo. O termo "permissão" carrega o sentido de que você não será tido como culpado de suas ações. Se você tentar um recomeço limpo mas for reconhecido, você será responsável pelas ações de ambas as contas - a nova e a antiga. O fato de você ter notificado alguém da mudança não lhe aliviará de nenhuma consequência de suas ações, ou o protegerá de reconhecimento.

Como proceder? O usuário que foi bloqueado e deseja ter um recomeço limpo era o User:O andarilho, User:Detetive Zero. Rodrigo, Luz28 ^(MsG) 15h07min de 23 de fevereiro de 2017 (UTC).

Isso não é um recomeço limpo, pois as contas foram bloqueadas. Pode no entanto pedir uma WP:DB para poder voltar a editar, mas aconselhava que deixasse passar algum tempo, sem editar antes de abrir a discussão (isto quer dizer, sem criar novos fantoches). GoEThe (discussão) 15h35min de 23 de fevereiro de 2017 (UTC)

GoEThe obrigado por esclarecer. No caso o usuário criou outra conta e pensa em um recomeço mas está com medo de sofrer novas sanções! Rodrigo, Luz28 ^(MsG) 15h50min de 23 de fevereiro de 2017 (UTC).

Honestamente, se não cometer os mesmos erros que o levaram a ser bloqueado, cumprir ar regras e estiver aqui para construir uma enciclopédia, dificilmente sofrerá sanções, pois ninguém saberá quem ele é. Mas isso é raro acontecer, e mais cedo ou mais tarde há inevitavelmente deslizes e é bloqueado novamente. Diga ao usuário que pense bem o que pretende daqui. GoEThe (discussão) 09h34min de 24 de fevereiro de 2017 (UTC)

Apenas que os verificadores de conta estão atentos e contornos de bloqueio não são permitidos. Não conheço detalhes do seu caso, mas insistir em voltar logo após ter sido bloqueado é inútil. Como disse na primeira intervenção deixe passar algum tempo e depois abra uma DB. GoEThe (discussão) 12h41min de 24 de fevereiro de 2017 (UTC)

@GoEThe: Apenas para informar que removi comentários de um fantoche acima, fazendo com que sua última mensagem aqui fique um pouco descontextualizada. Érico (fale) 21h16min de 25 de fevereiro de 2017 (UTC)

@Luz28: O andarilho D​ C​ E​ F foi bloqueado por tempo indeterminado pela comunidade. Ele não pode, portanto, ter um recomeço limpo, já que isso seria contorno de bloqueio, proibido pela política. O único caminho, neste caso, é pedir que a comunidade reveja sua decisão. Eu pessoalmente acho que, neste momento, o bloqueio seria mantido, pois a decisão é muito recente e ele continua contornando bloqueio - inclusive nesta página. Há um claro caso de recusa da parte dele. Érico (fale) 21h19min de 25 de fevereiro de 2017 (UTC)

@Érico: entendo é que ele crê que foi perseguido por outros usuários por ter dito apenas uma frase por mera brincadeira e na realidade ele nunca fez os vandalismos apontados pelos seus acusadores, ele mesmo disse que no princípio quando ele criou a suposta conta fantoche ele era muito imaturo, mas agora ele já com 14 anos disse que quer contribuir com artigos sérios como é o caso de Yakusoku no Neverland criado por ele com uma revisão realizada por minha pessoa, outros artigos criados por ele Red Sprite, Bandai Visual, John Plagis, KonoSuba, Rewrite, Re:Zero Kara Hajimeru Isekai Seikatsu, Frank's Cock, 2016 WF9. Apesar de ele ter sido banido creio que as intenções dele são para com finalidades de contribuição voluntária assim como a maioria dos wikipedistas. Mas se for mesmo esta a decisão da comunidade de erradicar mais um voluntário (que aliás estamos precisando muito) eu deixo de retomar este assunto e peço desculpas por importunar a WP:Panelinha da Wikipédia. E para que eu também não sofra perseguições por tentar ajudar alguém que quer editar na Enciclopédia Livre que Todos podem editar eu não tocarei mais neste assunto e continuarei com as minhas contribuições. Agradeço aos comentários de todos, mas na minha opinião ficar banindo potenciais colaboradores sérios por serem novatos que dizem besteiras, não ajuda em nada no crescimento da Wikipédia em língua portuguesa. Se quiserem podem encerrar esta discussão pois eu não mais me pronunciarei. Rodrigo, Luz28 ^(MsG) 19h13min de 26 de fevereiro de 2017 (UTC).

@Luz28: eu peço desculpas por intrometer-me aqui, tentarei explicar o caso do usuário. O Andarilho (Detetive Zero) foi tema de vários debates, logo é falaciosa a argumentação dele de perseguição, outrora, ele utilizou esse argumento diversas vezes no projeto, até mesmo me parece que como desculpa... Infelizmente, não dá para suportar isso, três tópicos abertos para discutir o comportamento dele e a primeira discussão de bloqueio foi aberta como algo consensual, eu abri a DB não porque eu quis porque achava as edições erradas, muitos usuários recomendaram a DB no último tópico em WP:P/O, acredito que você concorda que, no meio de dezenas de administradores, você não vai falar em uma página pública que você tem fantoches e usa para vandalizar e vai esperar que todos os usuários que ver tal "afirmação" entende que é "brincadeira" e rir, após ser filtrado, ele continuo com o mesmo tipo de brincadeira, levou azar de sair um assunto de aliciamento off para vandalizar e foi bloqueado de forma unânime pelos administradores. Se ele queira voltar ao projeto, ele que me desculpa, mas vai ter que crescer e não cometer o mesmo erro; assim como as discussões de administradores com administradores prejudicam o projeto, as brincadeiras de um, ainda menino também. Edmond Dantès ^{d'un message?} 20h02min de 26 de fevereiro de 2017 (UTC)

Ok @Conde Edmond Dantès: vou me afastar dele então para que eu não seja prejudicado também. Obrigado! Rodrigo, Luz28 ^(MsG) 20h22min de 26 de fevereiro de 2017 (UTC).

@Luz28: eu não vejo motivo para que você seja prejudicado, até acho que pode ser benéfico se você passar algumas dicas para o usuário. Infelizmente, não creio que ele poderá convencer a comunidade que alterou o comportamento que levou a ser bloqueado em poucas semanas. Por hora, ele terá um trabalho árduo para mostrar que "mudou" sem ser descoberto, uma faca de dois gumes? Pode virar um fantocheiro ou editar com consciência, por isso ele tem que ter cautela para voltar a editar por aqui. Edmond Dantès ^{d'un message?} 20h29min de 26 de fevereiro de 2017 (UTC)

@Luz28: Os problemas que levaram ele a ser bloqueado por tempo indeterminado aconteceram há poucos meses. Logo, é cedo demais para debater novamente o assunto em uma discussão de bloqueio. E, esclarecendo, "Enciclopédia Livre" refere-se à licença que usamos e, sim, "todos podem editar", desde que cumpram com nossas regras e não transformem esta enciclopédia virtual em um playground. Saudações. Érico (fale) 00h47min de 27 de fevereiro de 2017 (UTC)

@Érico: Já entendi, e sei que aqui o que se preza é a seriedade dos artigos apresentados, mas reitero a minha posição da ótica de um usuário não registrado que acessa a Wikipédia em português e vê que o projeto já existe desde muito tempo, que mesmo após estes anos de existência não atingimos a marca de 1.000.000 de artigos sendo que há um desinteresse por parte dos lusófonos em contribuir. E que em outros idiomas (os mais falados pelo menos) já se ultrapassou a marca de 1.000.000 de artigos. Ele errou, sim, mas há agora um interesse por parte do acusado de realizar contribuições legitimas e dignas para o projeto como um todo. Bom vou fazer então a minha parte e deixar as decisões administrativas para usuários mais experientes e com ótica mas preservacionista, e assim continuar com as minhas contribuições sobre o que eu creio que ainda falta ser feito na Wikipédia. Rodrigo, Luz28 ^(MsG) 12h48min de 27 de fevereiro de 2017 (UTC).

[Ver]

Abreviações de anos nos títulos de artigos

Ver também: Wikipédia:Temas recorrentes/Convenção de nomenclatura

Tenho notado nos últimos tempos que muitos artigos da pt-wiki estão adotando um padrão de abreviações de anos nos títulos (onde o último ano é abreviado), similar as da en-wiki. Por exemplo: Bundesliga de 2016–17, La Liga de 2016–17, Euroliga de 2016–17, Perseguição aos Rohingya no Mianmar em 2016-17, etc.

Gostaria de saber se houve algum consenso sobre isso, pois não me aparece muito adequado usar essas abreviações em títulos. Já estive a alterar alguns títulos (como neste caso), mas acho melhor consultar a comunidade primeiro antes fazer várias mudanças em massa. --Lord Mota^✠ 15h14min de 25 de fevereiro de 2017 (UTC)

Aliás corrijam-me se estou errado, mas acho que essas abreviações contrariam WP:LDE/NQ. --Lord Mota^✠ 15h25min de 25 de fevereiro de 2017 (UTC)

Isso talvez tenha começado a aparecer por imitação, como tanta coisa por aqui. No entanto, pessoalmente não me agrada esse formato de títulos, parece-me mais próprio e mais claro usar Bundesliga 2016–2017.-- Darwin ^Ahoy! 15h34min de 25 de fevereiro de 2017 (UTC)

• Também não concordo com essas abreviações e não me recordo de haver consenso para seu uso. RadiX∞ 20h40min de 26 de fevereiro de 2017 (UTC)

Usar "en dash" (–) para representar-se intervalos e abreviar-se a parte do segundo número do intervalo é um padrão tipográfico bastante difundido. Oxe (discussão) 19h30min de 27 de fevereiro de 2017 (UTC)

@Oxe: Entre os gringos pode até estar bastante difundido, mas o uso disso é comum em português?-- Darwin ^Ahoy! 20h16min de 27 de fevereiro de 2017 (UTC)

Sim, exatamente. Eu gostaria de saber se é correto usar esse tipo abreviação na língua portuguesa, pois nunca vejo isso sendo usado no português formal. --Lord Mota^✠ 21h00min de 27 de fevereiro de 2017 (UTC)

@Darwinius e Lord Mota: Representar intervalos dessa forma é usual no meio acadêmico. Oxe (discussão) 21h02min de 27 de fevereiro de 2017 (UTC)

@Oxe: Tem como demonstrar isso? Eu leio muito material académico em português, corriqueiramente, e não tenho a noção de que esse sistema seja habitual.-- Darwin ^Ahoy! 21h09min de 27 de fevereiro de 2017 (UTC)

@Oxe: não me preocupa o intervalo, mas a essas abreviações nas datas como em Perseguição aos Rohingya no Mianmar em 2016-17 (onde colocam "17" ao invés de "2017").--Lord Mota^✠ 21h11min de 27 de fevereiro de 2017 (UTC)

@Oxe: Eu também estava a me referir a isso que o Lord Mota disse: Esses intervalos parecem estranhos, pelo menos em português, e não lhes vejo qualquer vantagem em relação ao sistema tradicional "2016-2017".-- Darwin ^Ahoy! 22h38min de 27 de fevereiro de 2017 (UTC)

@Darwinius: Você estava pensando em algo como "Em geral, a historiografia tem aceito, para o século XIX, a formulação de que, após o breve período regencial (1831-40), teria prevalecido um alto grau de centralização político-administrativa, que teria neutralizado a participação das elites regionais" em http://www.journals.usp.br/revusp/article/download/33853/36586 ou "Nos anos 1964-85 a ditadura militar, consciente ou inconscientemente, destroçou lideranças e organizações políticas comprometidas com o modelo de capitalismo nacional" em http://www.scielo.br/pdf/ea/v14n40/v14n40a06.pdf? É comum omitir-se a ordem de grandeza do fim do intervalo se o texto for sobre um intervalo dentro de um século. Em textos que versem sobre vários séculos, é mais rotineiro se escrever os anos completos para evitar confundir o leitor. No caso dos campeonatos, salvo melhor juízo, os próprios adotam essa nomenclatura para nomear suas temporadas. Oxe (discussão) 01h58min de 28 de fevereiro de 2017 (UTC)

@Oxe: Eu não digo que não exista, mas o uso dessa norma é claramente inferior ao ano completo nas fontes em português. Experimente pesquisar por segunda+guerra+"1939-1945", e fazer a mesma pesquisa com "1939-45", tanto no Google Académico como no Books, os resultados são idênticos, e cerca de 7 vezes superiores no caso dos anos completos. Outras pesquisas usando os mesmos sistemas retornam resultados semelhantes. Nós devemos tentar usar aqui a norma, o que causa menos surpresa, que neste caso é o sistema dos anos não abreviados.-- Darwin ^Ahoy! 02h20min de 28 de fevereiro de 2017 (UTC)

@Darwinius: Aqui a pesquisa "segunda guerra mundial"+"1939-45" no Google retorna 135 mil resultados, enquanto que "segunda guerra mundial"+"1939-1945" retorna 429 mil. A proporção 4:1 não faz a forma 1939-45 tão incomum assim, IMHO. Lembro-me de também ver intervalos representados com barra em vez de en dash, por exemplo, 1939/45 e 1939/1945 para o intervalo de 1939 a 1945. Eu acho que é mais questão de gosto pessoal, porque todas as formas são igualmente válidas. Oxe (discussão) 02h33min de 28 de fevereiro de 2017 (UTC)

@Oxe: Não pode fazer a pesquisa no "Google" no meio do lixo todo, tem que qualificar, para que sirva de alguma coisa. Faça no Google Books e no Google Académico, que a proporção é muito maior que essa que você achou.-- Darwin ^Ahoy! 02h43min de 28 de fevereiro de 2017 (UTC)

@Darwinius: mil vs. dez mil, isto é, 1:10, que também considero uso significante da forma abreviada. Apenas informei que a forma abreviada é comum porque parecia que o consulente não sabia que era bastante usada. Entretanto, pela padronização dos títulos, até preferiria que eles fossem sempre escritos sem abreviações , inclusive porque a forma contempla períodos que envolvem dois séculos, por exemplo, a Primeira República Brasileira (1889–1930). E, por questão de usabilidade, para cada título com en dash, deveria haver um redirecionamento substituindo-o por hífen porque tem digitação mais fácil. Saudações. Oxe (discussão) 03h01min de 28 de fevereiro de 2017 (UTC)

┌─────────────────────────┘ @Oxe: Eu próprio fiquei surpreendido, não sabia que essa forma abreviada era tão usada assim, embora o uso seja claramente menor, e os resultados tenham alguma contaminação do formato "1939/45" que é também relativamente comum, como você mesmo apontou.-- Darwin ^Ahoy! 03h06min de 28 de fevereiro de 2017 (UTC)

Pode até ser essa forma abreviada seja usada, mas ainda entendo que a mesma contrarie o livro de estilo principalmente na parte "Nomes completos em vez de abreviaturas" Citação: Evite sempre a utilização de abreviaturas, exceto quando o assunto for conhecido exclusivamente pelo seu acrônimo. e possivelmente em WP:LDE/NQ Citação: As datas devem sempre ser escritas desta forma 21 de maio de 1957 (br, norma brasileira) e (Acordo ortográfico de 1990) ou 21 de Maio de 1957 (pt, norma portuguesa) ainda em vigor, e nunca 21/05/1957, 21-5-1957 ou qualquer outra combinação.[...]. --Lord Mota^✠ 14h20min de 28 de fevereiro de 2017 (UTC)

Não concordo com essas abreviações e nem sequer vejo qualquer necessidade ou benefício. Vanthorn^® 22h02min de 27 de fevereiro de 2017 (UTC)

• Para competições desportivas ver Wikipédia:Convenção de nomenclatura/Desporto. Eric Duff ^disc 01h58min de 1 de março de 2017 (UTC)

O texto está meio longo, e não estou com tempo no momento para ler tudo, a dúvida é o uso do hífen/meia-risca/barra ou o uso diminuto do ano? tipo ao invés de 1990-1991 usar 1990-91? Eric Duff ^disc 02h01min de 1 de março de 2017 (UTC)

@Eric Duff:, a dúvida é com o uso diminuto do ano, o "1990-91" que você usou como exemplo. Agora vi que, no caso dos eventos desportivos, a convenção de nomenclatura sobre desporto permite a meia-risca (–), só que não menciona nada sobre a abreviação do ano. Por isso eu acredito, que esse diminuto do ano pode ser equivocado. --Lord Mota^✠ 02h30min de 1 de março de 2017 (UTC)

Eu passei a utilizar porque a maioria dos artigos esportivos utilizavam as forma abreviada, nos artigos sobre outras "coisas" eu mantive a mesma forma, tipo um artigo sobre um nobre com a desambiguação 1500-1520, eu mantive 1500–1520 trocando o hífen pela meia-risca. Eric Duff ^disc 02h57min de 1 de março de 2017 (UTC)

Compreendo. A meia-risca parece ser de uso geral (vejo sendo usado em artigos de eventos históricos, guerras, etc). Mas o interessante é que essa forma abreviada é largamente utilizada nos artigos esportivos, só que a convenção de nomenclatura sobre desporto não menciona nada sobre seu uso. Parece que resolveram simplesmente imitar a en-wiki. --Lord Mota^✠ 16h33min de 1 de março de 2017 (UTC)

@Lord Mota: Foi proposto em Wikipédia:Esplanada/propostas/Convenção_de_nomenclatura_sobre_campeonatos_de_futebol_(29jan2013) (procure pelo trecho "Podíamos também aplicar esta proposta às épocas") e depois foi votado em Wikipédia:Votações/Convenção de nomenclatura/Campeonatos desportivos. Oxe (discussão) 16h42min de 1 de março de 2017 (UTC)

@Oxe: Sim , trata-se da discussão e da votação que deram origem ao texto atual da Wikipédia:Convenção de nomenclatura/Desporto. Mas leia atentamente a página da convenção de nomenclatura: não menciona nada sobre o uso da forma abreviada. --Lord Mota^✠ 16h56min de 1 de março de 2017 (UTC)

┌─────────────────────────┘ @Lord Mota: Sim, o texto não é um primor, mas Wikipédia:Convenção de nomenclatura/Desporto faz referência a Wikipédia:Esplanada/propostas/Convenção de nomenclatura sobre campeonatos de futebol (29jan2013), portanto ficou implícito no texto e facilmente perceptível pela prática corrente de nomeação de artigos de temporadas. Porém esse padrão de abreviação gera coisas erradas como Primeira Liga de 1999–00, pois "00" não é 1900 mas sim 2000. Antes dos anos 2000, eu me lembro que era comum se escrever apenas os dois últimos dígitos para se referir a um ano, por exemplo 94 em vez de 1994, como pode ser visto no cartaz de Copa do Mundo FIFA de 1994. Talvez fosse costume antigo se escrever "La Liga de 70-71" em vez de "La Liga de 1970-1971", daí que se use atualmente por aqui "La Liga de 1970-71", sei lá. Eu até preferiria que fosse "La Liga de 1970-1971" por causa dos campeonatos de 1899-1900 e 1999-2000, mas existe uma razão para o padrão atual, que pode ser eventualmente questionado e alterado. Saudações. Oxe (discussão) 17h12min de 1 de março de 2017 (UTC)

"La Liga de 1970-71" pode ser "La Liga de 1970-1971" como "La Liga de 1970-2071" como até "La Liga de 1970-3371", etc.. Não há necessidade nenhuma de deixar dúvidas ao leitor mais incauto sobre espaços temporais na Wikipédia. Vanthorn^® 19h30min de 1 de março de 2017 (UTC)

Eu duvido muito que alguém que tenha digitado Serie A de 1970–71 no navegador, agora no ano de 2017, imagine que irá para o para o campeonato que iniciou em 1970 e terminará em 2071 (?) ou que iniciou em 1970 e terminará em 3371 (???). Ou que tenha lido a primeira frase "A Primeira Divisão do Campeonato Italiano de Futebol da temporada 1970-1971" e ainda consiga se confundir. A pergunta inicial foi "Gostaria de saber se houve algum consenso sobre isso [abreviações nos anos de títulos de artigos]" e a resposta é sim, houve consenso. Oxe (discussão) 19h39min de 1 de março de 2017 (UTC)

O tópico da discussão é "Abreviações de anos nos títulos de artigos". O futebol é só um exemplo que serve para outros. Vanthorn^® 19h53min de 1 de março de 2017 (UTC)

Mas estávamos em uma thread sobre competições desportivas e o seu exemplo foi sobre competições desportivas, logo eu estava me referindo apenas às competições desportivas, que eu nem concordo, diga-se mas respeito a decisão anterior. Nos outros casos, como em Perseguição aos Rohingya no Mianmar em 2016–2017, que foi citado no início, acho que a abreviação é inadequada. Oxe (discussão) 20h02min de 1 de março de 2017 (UTC)

Olha, sinceramente eu não acho que se pode dizer que houve consenso para o uso dessas abreviações, pois isso não foi debatido de forma clara naquela discussão e também não consta na convenção de nomenclatura. Na minha opinião isso é só uma prática adotada e copiada pelos usuários que editam sobre esportes. No mais concordo que devemos rever o padrão atual.--Lord Mota^✠ 22h45min de 1 de março de 2017 (UTC)

Foi aprovado em votação Wikipédia:Votações/Convenção de nomenclatura/Campeonatos desportivos. Oxe (discussão) 23h28min de 1 de março de 2017 (UTC)

Sim foi votado, mas o que eu estou querendo dizer é que em nenhum momento da discussão e nem na própria votação foi perguntado de forma aberta se era preferível o uso do padrão abreviado ou do padrão normal, tal como foi a questão do uso da meia-risca ao invés do hífen e da barra.--Lord Mota^✠ 00h57min de 2 de março de 2017 (UTC)

Foi também, embora tenha ficado espalhado na discussão. Procure por "época" em Wikipédia:Esplanada/propostas/Convenção de nomenclatura sobre campeonatos de futebol (29jan2013). Oxe (discussão) 04h37min de 2 de março de 2017 (UTC)

@Oxe: Com base nesta discussão que estamos tendo aqui, não daria para alterar essa convenção para que pelo menos fosse desincentivado o uso das abreviaturas?-- Darwin ^Ahoy! 20h46min de 1 de março de 2017 (UTC)

@Darwinius: Eu penso que sim. Não estava discordando disso, mas explicando de onde esse padrão surgiu. Oxe (discussão) 20h48min de 1 de março de 2017 (UTC)

Em minha opinião tanto faz a forma utilizada, no caso das competições esportivas que são para descrever uma temporada acho melhor do jeito que está, mas em se tratando de um período maior, sempre é mais conveniente manter os anos por inteiro, mas como disse, se acharem melhor não serei eu que irei me opor. Eu não sei se existe alguma convenção na wiki-en, mas eles próprios utilizam nas duas formas, vide en:Princess Alexandra of Hanover (1882–1963), en:Sophie of Mecklenburg (1481–1503) e en:Caroline of Stolberg-Gedern (1732–1796). Eric Duff ^disc 22h00min de 1 de março de 2017 (UTC)

@Lord Mota: Você está pensando em propor mudanças em Wikipédia:Convenção de nomenclatura/Desporto? Não sei se passaria via consenso, mas acho que, se houvesse, no pior caso de uma proposta de mudança, uma validação da votação anterior com um quórum maior, já seria proveitoso para o projeto. Saudações. Oxe (discussão) 01h04min de 8 de março de 2017 (UTC)

Estou pouco ativo. Não pretendo alterar a convenção de nomenclatura apenas abolir essa forma abreviada. Por esta discussão aqui é possível ver que todos os que comentaram são contrários a essas abreviações. Aliás, na pratica isso não significará nenhuma alteração pois a convenção de nomenclatura não menciona nada sobre o uso dessa forma abreviada e o próprio livro de estilo condena essa forma. --Lord Mota^✠ 00h04min de 18 de março de 2017 (UTC)

Propostas

[Ver]

Impor limite de edições a todos usuários

Caros. Tivemos recentemente um pequeno incidente em que um usuário utilizou um script JavaScript para fazer uma série de modificações em massa. As edições não foram lesivas, mas chamaram a minha atenção sobre uma pequena brecha no sistema que eu sempre soube. E é sobre isso que quero falar agora.

Apesar dos limites que nossas regras impõem sobre o volume de edições que um usuário pode fazer por meio de ferramentas (3 edições por minuto para usuários; 6 edições por minuto para robôs), todas as ferramentas que temos disponíveis (Huggle, AWB, etc.) não há NADA que impeça que alguém desenvolva um programa que simplesmente ignore esses limites. O único limitador são as regras. Se um usuário violar, estará sujeito às nossas sanções. Mas sempre será possível que ele viole os limites.

Para deixar claro, vou descrever algumas situações em que simplesmente sancionar o usuário NÃO seria suficiente para reparar o dano:

Caso provável 1: Usuário descontrolado

Como pode ser visto na ocorrência, por meio de um script um usuário conseguiu realizar, quase que instantaneamente, exatas 216 edições. E esse não é o máximo de edições que se pode fazer com um script: a questão é que foram editadas apenas 216 páginas. Mas poderiam ser milhares de páginas, todas editadas de uma só vez. Poderia, inclusive, serem feitas por diversas contas diferentes, o que tornaria o processo de reversão ainda mais complexo. Imagine ter de reverter as edições de um script rodando a 30 minutos? Com uma taxa de 5000/edições por minuto, teríamos 150 mil páginas para reverter, uma-a-uma.

Caso provável 2: Robô descontrolado

Pior do que um usuário descontrolado, pode ocorrer de um robô se descontrolar. O impacto das edições dele seria o mesmo que um usuário qualquer, a diferença é que seria mais difícil de rastrear as edições, dado que as edições feitas por robôs não aparecem nas 'Mudanças Recentes'. Esse robô somente seria identificado quando ele editasse uma página vigiada por outro usuário e esse usuário, por sua vez, se manifestasse. Mas se o robô editar apenas as Páginas não vigiadas, ele passaria completamente despercebido e poderia operar por horas (para não dizer dias) editando sem ser percebido.

Caso hipotético: Armageddon!

Um burocrata mal intencionado poderia criar um programa que registra contas através de máquinas diferentes e com nomes aleatórios e os torna burocratas/administradores em massa. Em questão de segundos teríamos milhares de administradores e burocratas bloqueando todos os administradores e burocratas da Wikipédia e fazendo edições aleatórias, de todo o tipo, em massa. Embora fosse possível reverter todas as edições e bloquear todos os usuários, os Stewards não teriam condições de remover os privilégios de tantos usuários de forma tão rápida e a única solução para esse problema seria uma intervenção direta do time de engenharia da Wikimedia Foundation. A solução provavelmente seria parar o servidor da Wikipédia e restaurar o último backup.

Claro que não queremos pensar na possibilidade de qualquer uma dessas coisas acontecerem. Mas o motivo disso não ter acontecido é simples: por sorte, escrever um script é uma tarefas que poucos usuários detém conhecimento e, felizmente, esses poucos usuários tem mais coisas para fazer do que ficar bagunçando a casa dos outros.

Imagino que seja do interesse da comunidade impedir que isso aconteça. Fiquei esses dias pensando como isso poderia ser evitado/minimizado, sem causar impacto nas colaborações. Cheguei na conclusão que devemos impor um limitador nas edições de TODOS os usuários. Minha proposta é que limitemos o número de edições de todos usuários para 60 edições a cada 10 minutos.

Esse é um limite bastante alto, visto que seria o número de edições de um Bot, segundo nossas regras vigentes (=6 edições por minuto). Com isso, ainda será possível que um usuário viole as regras (isto é, edite acima de 3 edições por minuto), mas o intuito não é limitar as colaborações: é impedir que a brecha de segurança que descrevo aqui seja explorada. Lembro que já existe um limitador global, que impede que usuários IP e não confirmados editem mais que 8 páginas em 1 minuto (em qualquer wiki).

Aspectos técnicos da proposta
Essa configuração é possível, através da inclusão do código abaixo no InitialiseSettings.php (arquivo de inicialização da Wikipédia), ou seja, seria preciso abrir um ticket no Phabricator: # wgRateLimits @{ 'wgRateLimits' => [ // ... '+ptwiki' => [ 'edit' => [ 'user' => [ 60, 600 ], ], ], // ... ], # @} end of wgRateLimits

O que acham da proposta? Chamo atenção para alguns membros com conhecimentos técnicos no software da Wiki: @Alchimista, Danilo.mac, He7d3r, !Silent e Chicocvenancio:. --Diego Queiroz (discussão) 15h00min de 7 de fevereiro de 2017 (UTC)

Concordo acho importante e necessário minimizar as vulnerabilidades existentes (para mim isso é uma vulnerabilidade).

Fiquei com uma questão na cabeça, porém, qual o limite usado por outros projetos? Chico Venancio (discussão) 15h07min de 7 de fevereiro de 2017 (UTC)

Comentário Como usuário assíduo do Huggle, existe uma chance (ainda que relativamente baixa) de eu ter que reverter, durante 10 minutos, mais de 30 vandalismos (considerando que o Huggle reverte e avisa o usuário ao mesmo tempo, logo 30 edições + 30 avisos atingiria a cota proposta), então a principio isso poderia ser limitador para mim. Acho a questão pertinente, contudo penso que esse limite deveria ser superior. --Hume42 ✉ 15h15min de 7 de fevereiro de 2017 (UTC)

Hume42 a regra já afirma que isso vai contra as regras. Há algum caso recente em que isso realmente se aplicou? Chico Venancio (discussão) 15h18min de 7 de fevereiro de 2017 (UTC)

@Chicocvenancio: Realmente não sei dizer, apenas estou considerando uma situação hipotética, pois 3 reversões por minuto (dando 6 edições com os avisos) me parece razoável de acontecer, ainda que uma constante de edições nesse ritmo por 10 minutos nem tanto. Sobre ser contra as regras, nunca fui repreendido e por isso não sabia, mas suponho que não atrapalho ninguém com minhas reversões. --Hume42 ✉ 15h28min de 7 de fevereiro de 2017 (UTC)

Assim como o Hume42 falou, às vezes é necessário realizar muitas reversões em um minuto, mesmo sem o Huggle, que não uso. Um exemplo seria num ataque de sock puppets, como os do Vhaslhv. Mr. Fulano! ^{🔔Fale Comigo📩} 15h31min de 7 de fevereiro de 2017 (UTC)

Isto fez-me lembrar en:Don't delete the main page. Como é que essa restrição iria jogar com ferramentas como Especial:Nuke (mw:Extension:Nuke)? GoEThe (discussão) 15h52min de 7 de fevereiro de 2017 (UTC) Estou a ficar velho, porque não consigo encontrar onde nas regras fala dos limites de número de edições por minuto para usuários comuns. GoEThe (discussão) 16h03min de 7 de fevereiro de 2017 (UTC)

@Chicocvenancio: Por incrível que pareça, essa vulnerabilidade é global. As únicas limitações nesse sentido (aplicadas em todas as wikis) é o número de edições por um mesmo IP ou por um usuário não-confirmado. De resto, não há restrição... Também não sei dizer se há outras discussões sobre o assunto em outras wikis. --Diego Queiroz (discussão) 16h26min de 7 de fevereiro de 2017 (UTC)

@GoEThe: O Nuke faz deleção de páginas. Alem disso, na configuração da wiki existe uma permissão especial para o uso do nuke (permissão 'nuke' e 'delete' são distintas). A limitação que proponho é para a edição de páginas somente, pois penso que é o caso mais provável e danoso. Portanto creio que essa alteração não vai afetar o funcionamento do Nuke. Acredito, inclusive, que podemos propor um limite para a eliminação de páginas e que isso também não vai afetar o nuke. (mas esse último caso é preciso confirmar) --Diego Queiroz (discussão) 16h26min de 7 de fevereiro de 2017 (UTC)

Comentário As razões para justificar o pedido parecem ser remotas demais (quiça improvável) de acontecer. Pelo que vi, o único problema nas edições foi porque o Luan configurou mal os scripts do robô. Mas não acho que temos editores com conhecimento técnico (deu até pra mencionar todos ali) e ferramentas o suficiente para fazer edições massivas em tão pouco tempo para se justificar o limite. Talvez uma abordagem menos rígida Diego Queiroz seja uma alternativa, mas a meu ver, isso é conservador demais. Eta Carinae (discussão) 16h59min de 7 de fevereiro de 2017 (UTC)

Conservador? Eu ri. --Diego Queiroz (discussão) 18h08min de 7 de fevereiro de 2017 (UTC)

Acho que não tem um termo mais adequado para descrever isso do que o utilizado pelo Chico: Vulnerabilidade. Por acaso, eu trabalho com tecnologia e presencio isso o tempo todo. Falhas de segurança são combatidas, jamais ignoradas ou logo você vê o resultado. O simples fato de eu estar expondo elas aqui (pois já sei dessa possibilidade faz tempo), já torna elas mais prováveis de ocorrerem. A Wikipédia é um dos sites mais visitados do mundo. Já viu quantos sites menos importantes já foram invadidos por aí só porque é divertido? Já ouviu falar em Defacement? Existem grupos especializados em fazer isso. E, particularmente falando, explorar essa falha na Wikipédia é bastante trivial. jQuery/Javascript você aprende em algumas horas seguindo tutorial na internet... --Diego Queiroz (discussão) 18h16min de 7 de fevereiro de 2017 (UTC)

Discordo Por vários motivos:

1. O limite proposto é assustadoramente baixo. 60 edições em 10 minutos são 6 edições por minuto. Isso é facilmente atingível, por exemplo, quando depois de se editar um artigo é necessário criar/alterar/corrigir categorias, afluentes ou criar ligações internas.
2. O limite iria impedir o uso de ferramentas de combate o vandalismo e às ações de socks, como o mass rollback.
3. Se a vulnerabilidade realmente existe e é plausível, então esta discussão deveria estar a acontecer a nível dos desenvolvedores do software media wiki ou de todas as wikipédias, e não apenas a nível local. Quintal ✁ 19h25min de 7 de fevereiro de 2017 (UTC)

Respostas:

1. Reversão é uma coisa, edição é outra. Não confunda.
2. Mesmo que 6 edições no minimo fosse "plausível" (na verdade, não é), pense em 60 edições em 10 minutos. Você teria que manter um ritmo frenético de edições por 10 minutos para atingir isso e, mesmo assim, estaria editando mais rápido que qualquer bot atualmente configurado. Acha mesmo que faz frequentemente esse tipo de façanha? Mesmo que isso insista que é um limite baixo, ok, podemos discutir um limite maior. O ruim é não ter limite algum.
3. A nível de desenvolvedores já existe essa preocupação, tanto que eu coloquei o link: mw:Manual:Edit throttling. Lá já se discute os efeitos desejáveis e indesejáveis dessa limitação. O recurso já foi implantado no software e já está configurado a nível global, e algumas wikis tem suas personalizações, como esta que eu proponho aqui.
4. Se discorda, então, no mínimo, dê uma alternativa para evitar 216 edições em um minuto. Eu adoraria ouvir uma alternativa.

--Diego Queiroz (discussão) 19h49min de 7 de fevereiro de 2017 (UTC)

Mais um ponto que eu esqueci: usuários que se sintam afetados podem solicitar a permissão 'noratelimit'. Podemos, inclusive, associar essa permissão com a de algum tipo de usuário. (Ex.: 'sysop' recebe automaticamente 'noratelimit', por exemplo). --Diego Queiroz (discussão) 19h54min de 7 de fevereiro de 2017 (UTC)

@Diego Queiroz: Que tal ao invés de bloquear, ao ultrapassar esse limite, seja exigido que o usuário passe por um CAPTCHA? Com isso, seria impossível manter edições automatizadas acima do limite. Mr. Fulano! ^{🔔Fale Comigo📩} 21h33min de 7 de fevereiro de 2017 (UTC)

Não acredite em Captchas, eles são fáceis de contornar para aqueles que desejam. Chico Venancio (discussão) 22h13min de 7 de fevereiro de 2017 (UTC)

• Citação: Reversão é uma coisa, edição é outra. Não confunda. Não percebi. Uma reversão não é uma edição?
• Citação: Mesmo que 6 edições no minimo fosse "plausível" (na verdade, não é), pense em 60 edições em 10 minutos. Você teria que manter um ritmo frenético de edições por 10 minutos para atingir isso e, mesmo assim, estaria editando mais rápido que qualquer bot atualmente configurado. Acha mesmo que faz frequentemente esse tipo de façanha? 6 edições por minuto é um "ritmo frenético" e "não é plausível"? Pergunte a qualquer pessoa que edite categorias ou que crie afluentes. Pergunte a qualquer pessoa que use o mass rollback para reverter edições de socks.
• Citação: O recurso já foi implantado no software e já está configurado a nível global, e algumas wikis tem suas personalizações, como esta que eu proponho aqui. Então o limite já existe a nível global e isto é apenas uma personalização local? Isso não está nada claro na proposta. Qual é o limite global? Quintal ✁ 21h49min de 7 de fevereiro de 2017 (UTC)

As formas que essa vulnerabilidade podem ser explorada não se limitam aos cenários que o Diego desenhou. Eu pensaria em um cenário com usuários inocentes sendo alvos de programação maliciosa. Há pouco tempo alguém acessou a conta de um administrador na Wikien e fez alguns estragos. É por isso que ganhamos o recurso de autenticação em dois fatores. Agora imagina alguém que queria atuar de maneira a causar um estrago mas não consegue descobrir a senha de algum admin/burocrata/supressor/steward , basta desenhar um script que efetue ações em massa e enviar como extensões maliciosas para os usuários que possuem esses estatutos. Scripts desses, hoje podem editar milhares de páginas em instantes. O usuário só iria perceber quando o estrago estivesse feito. Chico Venancio (discussão) 22h13min de 7 de fevereiro de 2017 (UTC) ps: após o primeiro admin infectado é possível colocar o script para todos os usuários da Wikipédia ao mesmo tempo. Quanto mais analiso essa vulnerabilidade mais eu penso que impossível explicar o potencial de um ataque de negação de serviço através dela. Chico Venancio (discussão) 22h14min de 7 de fevereiro de 2017 (UTC)

Continuo sem perceber porque é que isso está a ser discutido aqui, a nível local na pt.wiki. Se há essa vulnerabilidade, ela deve ser exposta e discutida com os desenvolvedores e tomadas medidas a nível global. Quintal ✁ 22h37min de 7 de fevereiro de 2017 (UTC)

Comentário Também não percebi se o limite se aplica ou não a reversões, ou somente a edições.-- Darwin ^Ahoy! 22h51min de 7 de fevereiro de 2017 (UTC)

Discordo. Os motivos são exatamente os descritos pelo usuário Antero de Quintal, acima. Chamo a atenção para a utilização mass rollback, que facilmente pode ultrapassar este limite proposto quando empregado no combate a vandalismos em massa de sockpuppets. No mais, essa vulnerabilidade deve ser discutida globalmente, e não em uma wiki local, não cabendo, portanto, a discussão aqui. RadiX∞ 00h30min de 8 de fevereiro de 2017 (UTC)

Caros @Antero de Quintal, Darwinius e RadiX:. Vamos lá, vou explicar uma coisa. Para reverter edições, não é necessário ser reversor? E qual é a mágica aí? Porque é uma ação diferente, logo, precisa de uma permissão diferente. Uma ação 'edit' ocorre quando você clica em editar uma página e salva. Na prática, você envia um fluxo de dados com o conteúdo da nova página e ele substitui o antigo. Já a ação 'rollback' é um simples comando, o software wiki que faz a coisa toda. Não sei se é suficiente para vocês entenderem, mas em resumo são comandos distintos a nível de software: 'edit' e 'rollback'. --Diego Queiroz (discussão) 09h04min de 8 de fevereiro de 2017 (UTC)

@Antero de Quintal: Sobre os limites globais atualmente definidos, eles são os seguintes:

Limites atuais

Todas as wikis IP Mover: N/A Editar: 8 páginas por minuto Errar o captcha: 15 vezes por minuto Enviar a senha por e-mail: 5 e-mails por hora Enviar e-mail para outros usuários: 5 e-mails por dia Atualizar página (purge): 30 atualizações por minuto Atualizar listagens (link purge): 30 atualizações por minuto Renderizar arquivos (ex. gerar miniaturas): 700 renderizações a cada 30 segundos Renderizar arquivos não padrão: 70 renderizações a cada 30 segundos API cxsave: 10 salvamentos a cada 30 segundos Novos usuários (não confirmados) Mover: 2 páginas a cada 2 minutos Editar: 8 páginas por minuto Errar o captcha: 15 vezes por minuto Enviar a senha por e-mail: N/A Enviar e-mail para outros usuários: 5 e-mails por dia Reverter: 5 reversões a cada 2 minutos Atualizar página (purge): N/A Atualizar listagens (link purge): N/A Renderizar arquivo (ex. gerar miniaturas): N/A Renderizar arquivos não padrão: N/A API cxsave: N/A Todos usuários Mover: 8 páginas por minuto Editar: Não há limite Errar o captcha: 30 vezes por minuto Enviar a senha por e-mail: N/A Enviar e-mail para outros usuários: 20 e-mails por dia Reverter: 10 reversões por minuto Atualizar página (purge): 30 atualizações por minuto Atualizar listagens (link purge): 30 atualizações por minuto Renderizar arquivo (ex. gerar miniaturas): 700 renderizações a cada 30 segundos Renderizar arquivos não padrão: 70 renderizações a cada 30 segundos API cxsave: 10 salvamentos a cada 30 segundos Reversor Reverter: 100 reversões por minuto enwiki Movedor de páginas (na enwiki existe um tipo de usuário chamado "Page mover") Mover: 16 páginas por minuto dewiki Editores (na dewiki existe um tipo de usuário chamado "Editor") Reverter: 100 reversões por minutos Commons Todos os usuários Enviar arquivo: 380 arquivos a cada 72 minutos Revisor de imagens Enviar arquivo: 999 arquivos por minuto Patrulhador Enviar arquivo: 999 arquivos por minuto Autopatrulhado Enviar arquivo: 999 arquivos por minuto

--Diego Queiroz (discussão) 09h04min de 8 de fevereiro de 2017 (UTC)

@Mr. Fulano: Sobre a ideia do Captcha, ela até seria uma boa ideia, mas é uma ideia que não faz sentido para o problema em questão. Scripts editam páginas por meio da API. O script não visita a página como usuários fazem para poder visualizar um captcha. --Diego Queiroz (discussão) 09h15min de 8 de fevereiro de 2017 (UTC)

@Diego Queiroz: É essa a ideia, isso daria um limite nas edições semiautomáticas, pois se o editor quiser continuar a editar, teria que fazer as edições manualmente. Mr. Fulano! ^{🔔Fale Comigo📩} 13h25min de 8 de fevereiro de 2017 (UTC)

Bom, para quem pediu alternativas à proposta de "60 edições a cada 10 minutos". Basta manter a proporção de 6 edições por minuto (o que é relativamente fácil de ser conseguido, mas nem tanto de ser sustentado por vários minutos sucessivos). Então, a proposta pode ser "90 edições a cada 15 minutos" ou "120 edições a cada 20 minutos". Deixo ainda uma sugestão de período de testes para a restrição para que a comunidade se adapte e confirme (em x tempo) que essa restrição deve perdurar, caso haja consenso aqui. E me parece válido o questionamento sobre isso dever ser uma restrição de segurança (a ser discutida) em todos os projetos da Wikimedia. Luan (discussão) 13h46min de 8 de fevereiro de 2017 (UTC)

Estou satisfeito com a explicação de que isso não limitaria a criação e eliminação de páginas, nem reversões, nem afectaria grupos de usuários com excepção a essa limitação (admins e eliminadores neste momento) mas concordo que provavelmente isso poderia/deveria ser discutido a nível global. Até porque pode até já ter sido discutido e descartado. GoEThe (discussão) 14h33min de 8 de fevereiro de 2017 (UTC)

Comentário O termo "reversão" pode ter dois sentidos: 1) o sentido restrito à ferramenta rollback, acessível apenas a reversores; 2) um sentido amplo, que indica qualquer edição que consista em desfazer uma ou várias edições. Quando se mencionou "reversão" mais em cima, deve-se entender no sentido amplo, e não apenas as reversões do rollback. Assim, o limite proposto pode até nem afectar a ferramenta rollback, mas afetaria as reversões manuais, inclusive as que são feitas com scripts como o "Reversão e avisos" e "Mass Rollback". Quintal ✁ 15h25min de 8 de fevereiro de 2017 (UTC)

Mesmo que afete, podemos dar limites maiores (ou não limitar) usuários que possuem acesso a essas ferramentas. Isso não é um inviabilizador. --Diego Queiroz (discussão) 16h35min de 8 de fevereiro de 2017 (UTC)

Concordo com o proposto. Os usuários que estão contestando a quantidade (60 em dez minutos) alegando ser muito restritivo, poderiam dar exemplos de casos em que vocês ultrapassaram esse limite? Falou-se das reversões aos vandalismos e as categorizações, porém eu queria ver o link direto nas contribuições de vocês comprovando isso, somente pra ter mais ou menos uma dimensão da coisa e um consequente aumento desse valor, se for o caso. !Silent (discussão) 20h48min de 12 de fevereiro de 2017 (UTC)

Talvez dê para fazer uma consulta SQL no toollabs:quarry para encontrar situações em que os usuários ultrapassaram o limite proposto? Helder 10h24min de 13 de fevereiro de 2017 (UTC)

Acredito que daria também, porém, tenho pouca familiaridade com SQL e com o Quarry. !Silent (discussão) 11h28min de 13 de fevereiro de 2017 (UTC)

Parece que o Quarry está offline. Vou dar uma olhada se ainda tenho acesso ao ToolServer/Wikimedia Labs e monto uma consulta (e se ainda lembro como usa, haha). --Diego Queiroz (discussão) 13h54min de 14 de fevereiro de 2017 (UTC)

Consegui montar a consulta (espero que esteja certa). Usei o Antero nessa primeira execução, mas depois eu rodo com outros usuários (rodar na Wiki toda seria um pouco insano). Ela ficou um pouco pesada, então preferi não deixar várias consultas rodando ao mesmo tempo. Assim que tiver um resultado eu posto aqui. --Diego Queiroz (discussão) 17h18min de 14 de fevereiro de 2017 (UTC)

Pergunta: Essa limitação é por uma questão de desempenho (evitar que isso comprometa o funcionamento da Wikipédia) ou por outros motivos? Pergunto isso, pois vejo centenas de edições feitas no Commons em um minuto por alguns scripts (eu e alguns usuários daqui já usamos) e não há qualquer prejuízo nesse sentido. Os servidores do Commons provavelmente são mais "potentes" que os daqui, mas me pergunto se essa limitação realmente existe.—T_ele^s«fale comigo» 20h55min de 14 de fevereiro de 2017 (UTC)

Eu uso corriqueiramente o cat-a-lot na categorização do Commons, que é uma das ferramentas que faz centenas de edições por minuto, e nunca tive qualquer tipo de problema. É muito frequente se fazer essa quantidade de edições por minuto quando se está a adicionar categorias de datação, por exemplo.-- Darwin ^Ahoy! 21h01min de 14 de fevereiro de 2017 (UTC)

Teles a questão não é exatamente de desempenho das máquinas, os servidores da Wikimedia são capazes de lidar com um número de edições muito superior a o que estamos falando aqui, a questão é do desempenho humano que pode ser necessário para desfazer algum problema causado por um erro pequeno de script. Digo, não é difícil pensar em um script que resolva fazer alterações sutis em artigos, se ele faz isso a 6 edições por minuto é um problema contornável, bloqueia-se o(s) usuário(s) e se desfaz as ações. Se isso é feito a 500 ou 5000 edições por minuto vai ser um pouco mais complexo. Imagine o pesadelo que seria se conseguem colocar isso no common.js Chico Venancio (discussão) 21h04min de 14 de fevereiro de 2017 (UTC)

@Teles: Existe uma preocupação com desempenho, mas eu estou colocando como uma questão de segurança. É uma vulnerabilidade e acho que é questão de tempo que algum grupo hacker se interesse a fazer um belo estrago na Wiki, por meio da exploração da nossa capacidade de ação e reversão. Tem noção que seria possível bloquear, em um instante, todos os administradores/burocratas e até mesmo stewards? Se a senha de qualquer sysop vazar, eu consigo até fazer com que A SUA CONTA faça tudo isso sem você saber (editando essa ou essa página). Os exemplos vão da imaginação do atacante. Pretendo fazer um Request for comment no Meta sobre o assunto, mas ando sem tempo (demoro 5 vezes mais tempo para escrever um texto em inglês). E, de fato, o script que deu origem a essa discussão foi um script migrado do Commons (o tal de Cat-a-lot), mas não edito muito lá... --Diego Queiroz (discussão) 21h15min de 14 de fevereiro de 2017 (UTC)

Acho que o argumento sobre desempenho não deveria ser usado. O resto pode ser algo com que tenhamos que nos preocupar.—T_ele^s«fale comigo» 02h14min de 15 de fevereiro de 2017 (UTC)

Na verdade eu acho esta discussão toda um bocado rebuscada. Mas conheço um bicharoco que é realmente capaz de criar o caos nesta enciclopédia, bastando para isso que alguém mal intencionado atinja o nível de eliminador (se isso ainda não foi alterado), o que é bastante fácil. Há editores e bots com milhares de artigos criados, um nuke nesses, mesmo que o restauro fosse feito por script, levaria um bom tempo a consertar. Mesmo que a ferramenta seja limitada a administrador, o risco ainda seria bastante significativo, dado o cortejo de criaturas hoje infames e banidas do projecto que têm passado por esse cargo. E para usar isso não precisa saber scripts, nem rodar bots, nem o escambau, é só mesmo preencher campos e apertar um botão. Eu pessoalmente não vejo grande utilidade nesta ferramenta, pelo menos não vejo qualquer utilidade que justifique o risco. E não imagino, pelo menos nesta realidade em que vivo, que função possa ter uma coisa que dinamita milhares de artigos ao mesmo tempo, coisa absolutamente impossível de se criar em tempo útil sem se ser antes detectado pela vigilância do projecto. Numa discussão sobre o assunto, você opôs-se à remoção ou desactivação dessa ferramenta, Diego Queiroz. Ainda pensa o mesmo?-- Darwin ^Ahoy! 21h28min de 14 de fevereiro de 2017 (UTC)

@Darwinius: Na época eu não fui totalmente contra, apenas sugeri que fosse acessível apenas aos Administradores. Mas hoje eu penso que podíamos criar novos estatutos: como "Eliminador em massa", por exemplo (e outros equivalentes). Esse estatuto poderia conferir apenas a permissão de executar o nuke (na época, acho que não sabia dessa possibilidade). Além disso, acho que essa permissão deveria ser temporária, ou seja, seria atribuída quando fosse necessário executar o nuke e, logo em seguida, fosse removida. No entanto, por questão de segurança, não sou contra remover a permissão completamente, fiz uma pesquisa e notei que apenas ptwiki, jawiki, enwikiversity e wikidata permitem nuke: ou seja, quase nenhuma wiki. --Diego Queiroz (discussão) 00h58min de 15 de fevereiro de 2017 (UTC)

@Diego: A propósito, pode se interessar por este recurso: phab:T12493. Helder 10h45min de 15 de fevereiro de 2017 (UTC)

@He7d3r: Realmente muito legal essa proposta. Isso seria muito útil por aqui. --Diego Queiroz (discussão) 12h30min de 16 de fevereiro de 2017 (UTC)

Após tudo o que tem sido escrito aqui, eu tendo a discordar da proposta. O perigo não parece óbvio, e os danos colaterais parecem bastante significativos. No caso do nuke, após ver a discussão da Wiki-en sobre o assunto, em 2008, quando implementaram a ferramenta, e perceber que é a mesma ferramenta que eu uso no Commons, já estou mais descansado também.-- Darwin ^Ahoy! 05h02min de 15 de fevereiro de 2017 (UTC)

Discordo per Quintal. --Usien6 02h49min de 28 de fevereiro de 2017 (UTC)

Resultados

Resultado disponível:

Usuário: Antero de Quintal
- 03/12/2015, às 12:56 -> 97 edições em 10 minutos
- 16/04/2016, às 11:23 -> 165 edições em 10 minutos
- 19/04/2016, às 18:10 -> 70 edições em 10 minutos
- 29/05/2016, às 11:43 -> 91 edições em 10 minutos

Usando o Antero como exemplo de usuário ativo, de fato, desde que ele se registrou na Wikipédia, houve 4 situações em que ele fez mais de 60 edições no minuto. Vi que uma delas foi feita com a ferramenta de Reversão e Avisos, mas não analisei todas. O que acham? --Diego Queiroz (discussão) 19h18min de 14 de fevereiro de 2017 (UTC)

Na minha opinião, editar a essa taxa por meio de JavaScripts é exatamente o que proponho impedir (para os leigos: Reversão e Avisos é um JavaScript). Creio que a ferramenta de Reversão e Avisos pode (e deve!) ser ajustada para não efetuar edições nessa velocidade (assim não limitamos a funcionalidade da ferramenta). --Diego Queiroz (discussão) 19h18min de 14 de fevereiro de 2017 (UTC)

Eu acho que a ideia do CAPTCHA seria uma boa, pois seria praticamente impossível abrir o CAPTCHA num script e tecnicamente impossível de burlar automaticamente. E com isso evitaria o uso excessivo de scripts num curto período de tempo. E outra coisa, seria muito abuso se pedisse para fazer uma análise das minhas contribuições? É só por curiosidade. Mr. Fulano! ^{🔔Fale Comigo📩} 19h25min de 14 de fevereiro de 2017 (UTC)

Também gostaria da minha se possível, já que levantei a questão das reversões efetuadas por mim lá em cima. --Hume42 ✉ 19h32min de 14 de fevereiro de 2017 (UTC)

Acredito que podem colar a consulta no Quarry e trocar o nome do usuário. Helder 19h36min de 14 de fevereiro de 2017 (UTC)

"tecnicamente impossível de burlar"{{carece de fontes}} Isso já não é verdade há anos (exemplo)... Helder 19h36min de 14 de fevereiro de 2017 (UTC)

E em relação aqueles CAPTCHAS (se é que podemos chamar assim) que é necessário dar apenas um clique para verificar que não é um robô? Percebo que esse está sendo o mais usado ultimamente. --Hume42 ✉ 20h11min de 14 de fevereiro de 2017 (UTC)

@Hume42: O serviço é hospedado fora dos servidores da Wikimedia, e o seu uso não estaria de acordo com a política de privacidade, além de criar uma dependência externa indesejável (ver phab:T38585#418770, phab:T129936#2120451). Helder 20h27min de 14 de fevereiro de 2017 (UTC)

Além das fraquezas do CAPTCHA específico, há serviços pagos (e alguns gratuitos) para resolver Captchas. Ele não é uma solução. Chico Venancio (discussão) 20h36min de 14 de fevereiro de 2017 (UTC)

@Chicocvenancio: Sinceramente, não vejo nenhum outro modo de se evitar esses problemas além do limitador de edições, apesar que este também pode ser facilmente burlado… Mr. Fulano! ^{🔔Fale Comigo📩} 20h44min de 14 de fevereiro de 2017 (UTC)

Mr. Fulano como o limitador pode ser burlado? Chico Venancio (discussão) 20h49min de 14 de fevereiro de 2017 (UTC)

┌─────────────────────────┘ Chicocvenancio Primeiro, esse limitador só bloqueia edições, então é possível mover, apagar, suprimir entre tantas outras funções. E como foi sugerido, talvez seja possível criar uma permissão de se poder ultrapassar o limite. Então os usuários com essa permissão poderia ter sua conta invadida e pode ser feita essas operações. Isso são só algumas hipóteses. Não digo outras pois pode dar ideia aos vândalos. Mr. Fulano! ^{🔔Fale Comigo📩} 21h02min de 14 de fevereiro de 2017 (UTC)

Há algumas questões aí, primeiramente, as outras ações são muito mais fáceis de desfazer automaticamente (verificar o log e desfazer tudo de tal a tal hora) do que edições, que teríamos que separar o joio do trigo.

Criar permissões para ultrapassar o limite seria um "buraco" que nós estaríamos criando no limite, podemos não criar e mesmo que criemos é muito mais fácil observar os usuários que estiverem nessas exceções do que todos. Chico Venancio (discussão) 21h07min de 14 de fevereiro de 2017 (UTC)

@He7d3r: pelo menos aqui esse quarry não parece estar a funcionar direito, não consigo abrir nenhuma new query lá.-- Darwin ^Ahoy! 20h05min de 14 de fevereiro de 2017 (UTC)

@Darwinius: Conseguiu fazer o login normalmente? Verifique se o SQL Quarry está listado entre os aplicativos que conectou à sua conta. Helder 20h10min de 14 de fevereiro de 2017 (UTC)

@He7d3r: Não, quando eu tento fazer login dá: "502 Bad Gateway". No botão de login da extrema direita superior também dá erro. :\ -- Darwin ^Ahoy! 20h14min de 14 de fevereiro de 2017 (UTC)

Mesma coisa aqui. --Hume42 ✉ 20h15min de 14 de fevereiro de 2017 (UTC)

O mesmo também. Mr. Fulano! ^{🔔Fale Comigo📩} 20h17min de 14 de fevereiro de 2017 (UTC)

O Quarry está offline. @Hume42:, deixei o servidor do ToolLabs rodando o seu relatório. --Diego Queiroz (discussão) 20h19min de 14 de fevereiro de 2017 (UTC)

Outro ponto é que essa consulta demorou 3 horas para ser processada. O Quarry não ia dar conta de rodar (ele não permite consultas muito demoradas). --Diego Queiroz (discussão) 20h21min de 14 de fevereiro de 2017 (UTC)

Aqui está normal. Helder 20h27min de 14 de fevereiro de 2017 (UTC)

@Diego Queiroz Não creio que o problema esteja necessariamente no Reversão e Avisos. Mas o que você sugeriria que fosse feito com ele? !Silent (discussão) 20h31min de 14 de fevereiro de 2017 (UTC)

@!Silent: Não acho que ele é o problema. O problema é a possibilidade de editar em massa. Quando um usuário executa uma edição em massa por meio de um script automatizador, ele está agindo mais rápido que um robô, sem ser um robô. Esses scripts permitem que usuários excedam todos os limites de edições. Por conta disso, minha ideia seria:

1. incluir um limitador no número de edições (isso automaticamente faria o reversão e avisos bugar, já que ele não limita o número de edições);
2. alterar o reversão e avisos (e similares) para aplicar um throttle nas edições, para editarem sempre abaixo do limite (assim como o Pywikibot e tantos outros já fazem, seria um sleep da vida no meio do código).

Claro que a falta do (1) não impede o (2). ;) --Diego Queiroz (discussão) 20h40min de 14 de fevereiro de 2017 (UTC)

E com isso só seria possível reverter três edições e avisar três vezes por minuto com o RA? Não sei se isso é um boa ideia... !Silent (discussão) 20h44min de 14 de fevereiro de 2017 (UTC)

É mais ou menos isso, mas aí eu diria que é assunto para outra conversa. A política de robôs não permite que robôs editem mais rápido do que 6 epm (até pode 12 epm, se for urgente) e, mesmo assim, precisa de autorização e o funcionamento é acompanhado e homologado por outros usuários. Usuários via AWB editam a 3 epm, e precisam de autorização para usar. Dado isso, porque usuários sem autorização nenhuma podem ter limites superiores? Não faz sentido algum. Podemos até aumentar esses limites, mas independente disso, eu vejo os JavaScripts (e qualquer outro meio de edição automatizada) como um meio de burlar essa política (e não estou falando só dos gadgets, qualquer usuário pode colocar um JavaScript para rodar aqui, seja pelo common.js pessoal ou via um plugin como o GreaseMonkey). Agora se acha que a possibilidade de editar a essa velocidade não deixa a Wikipédia vulnerável, ok, mas eu discordo. --Diego Queiroz (discussão) 20h58min de 14 de fevereiro de 2017 (UTC)

• A restrição ao limite de edições não tornaria, de fato, a Wikipédia menos "vulnerável". Um vândalo poderia facilmente contornar essa limitação utilizando várias contas de ataque, ou articulando um ataque coordenado. Por outro lado, isto acarretaria problemas ao uso de scripts como este (js), que permitem a reversão em massa e a marcação das reversões como edições de robô (para administradores). O script também é muito utilizado por quem não tem o direito rollback para combater vandalismo e também atingir os requisitos necessários para obter a flag de reversor global. Acredito que os supostos ganhos em segurança não compensariam os transtornos ocasionados. Tenho quase certeza de que esta proposta não passaria numa RfC. Portanto, mantenho a mesma posição desde o início da discussão: Discordo. RadiX∞ 00h58min de 15 de fevereiro de 2017 (UTC)

"(...) poderia facilmente contornar (...). Primeiro, acho que você deveria pesar o seu "facilmente", não é nada fácil. E mesmo que concorde que isso é possível, o atacante teria que criar novas contas: novas contas tem limites muito baixos definidos globalmente. Usuários IP, limites menores ainda. Até a criação de contas tem limitações altas: não se pode criar várias contas de um mesmo local. Além disso, o software Mediawiki já possui proteções contra o acesso por meio de proxies abertos e a partir de Tor Exit Nodes (Veja mw:Extension:TorBlock e meta:Steward requests/Global), o que dificultaria muito a vida do atacante. Com a limitação que estou propondo, o ataque ficaria praticamente inviável. --Diego Queiroz (discussão) 01h15min de 15 de fevereiro de 2017 (UTC)

Você incluiu ligações para mw:Extension:TorBlock e meta:Steward requests/Global, a página na qual mais atendo a pedidos no Meta-Wiki (bloqueios de faixas associadas a webhosting services, leaky colo, etc), como se eu não compreendesse do que se trata um HTTP proxy, web proxy, ou serviço de anonimização. Não, não dificultaria a vida do "atacante", nem tornaria o ataque "inviável", justamente pela natureza de atuação desses vândalos. Talvez se você conhecesse o modus operandi dos LTAs, ou mesmo acompanhasse os problemas que temos enfrentado apenas localmente, nesta wiki, certamente iria repensar o termo "praticamente inviável". LTAs engendram os ataques, criam e mantém diversos sleepers, justamente para burlar as editrates impostas pelo MediaWiki a usuários não-confirmados. A partir daí, com as contas criadas, tanto faz se o vândalo utilizar de proxies para editar. E tanto faz se você reduzir o limite de edições de 8 para 2 por minuto, sobretudo quando temos um ataque coordenado, no qual mais de dois ou três LTAs combinam as ações entre si, em tempo real, utilizando as contas dormentes (que não são criadas a partir do mesmo IP, nem no mesmo ínterim). A única coisa que "ficaria praticamente inviável" é o trabalho do vandal fighter. Inviável e desmerecido. RadiX∞ 01h56min de 15 de fevereiro de 2017 (UTC)

RadiX, a questão é que hoje não precisam de proxys para causar danos massivos. Uma conta que possa editar sem limite de edit rate tem um impacto potencial algumas ordens de grandeza acima de contas limitadas. A questão é que hoje quase todas as contas não possuem limite. Cada IP adicional que um vândalo tiver que adicionar, de fato cada aba a mais que ele tenha que abrir, diminui o impacto da vulnerabilidade e criar o limite de edição vai nesse sentido. Chico Venancio (discussão) 02h05min de 15 de fevereiro de 2017 (UTC)

@Chicocvenancio: Diminuiu muito pouco, na verdade. Prefiro não escrever aqui tudo o que eles podem fazer para burlar essas restrições. Mas pode ter certeza de que muitos deles sabem até mais do que eu ou você. ;) RadiX∞ 02h26min de 15 de fevereiro de 2017 (UTC)

Estou Neutro em relação a esta regulamentação. Porque isso vai muito do bom senso do editor. Se ele sabe que o uso não autorizado ou arriscado de uma ferramenta pode ativar a vulnerabilidade do sistema, a pessoa tem que ter o bom senso de procurar usar de maneira minuciosa ou até mesmo não usar. Outra coisa, basta olhar minhas contribuições em Janeiro e verão que eu já fiz de 4 a 5 edições por minuto. Existem reversores como eu e outros usuários que possuem alta velocidade no raciocínio e gostam de reverter vários vandalismos ao mesmo tempo para agilizar o trabalho, como é o meu caso. Além disso, acho esta medida meio intervencionista nas edições dos usuários, afinal, se as edições são benéficas para o projeto e se estamos numa Enciclopédia livre, é meio contraditório uma medida dessas.

Por outro lado, um certo "amigo" nosso sustentava aos seus socks por meio de edições em massa que consistiam em adições de categorias por meio do HotCat, de forma semelhante ao robô, mas para obter direito ao voto e manipular votações. Creio que uma regulamentação dessas edições, apesar de intervencionista, pode ser benéfica para dificultar a ação de redes de sock puppets e manipulação de votos. E eu tive uma experiência com muitos vândalos na Wikia que faziam edições em massa inúteis para ganhar medalhas e mérito, e acabaram banidos por tempo indeterminado.

Enfim, a proposta é boa para reduzir a ação de trolls sistemáticos, spambots e fantocheiros, mas por outro lado, pode atrapalhar as ações de editores de bem, de reversores, ou até mesmo atrapalhar projetos. Por isso minha opinião é neutra em relação a esse assunto.

(saindo um pouco do assunto, confesso que levei um susto na parte do "caso hipotético")

Armagedon2000 ^msg 02h12min de 15 de fevereiro de 2017 (UTC) Fiz esta query que mostra os que tiveram mais edições em um minuto nos últimos 30 dias. ^Danilo.mac_(discussão) 15h02min de 15 de fevereiro de 2017 (UTC)

Apesar da medida ser interessante para evitar uma avalanche de edições desenfreadas que abusam da quantidade de edições por minuto, existem muitos usuários que em algum momento acabam extrapolando esse limite, de forma não intencional, revertendo vandalismos por exemplo ou fazendo edições sistemáticas. Essa limitação poderia ser facilmente contornada por um vândalo, e a restrição não deixaria a wiki menos vulnerável, podendo prejudicar ainda outros editores. ♪ Alberto79 ♪ ^{Msg-Contributions} 16h50min de 16 de fevereiro de 2017 (UTC)

Request for comment

Caso alguém queira participar, eis a discussão iniciada no Meta: meta:Requests for comment/Throttle edits made by all users. --Diego Queiroz (discussão) 02h06min de 15 de fevereiro de 2017 (UTC)

[Ver]

Reestruturação das páginas de concursos fotográficos - Wiki Loves Earth e Wiki Loves Monuments

Olá pessoal, desde 2014 venho organizando os concursos Wiki Loves no Brasil.

Desde então criamos uma estrutura básica de páginas que são replicadas e atualizadas a cada ano, o que gera retrabalho e muitas páginas em desuso ao longo dos anos. Gostaria de propor a reestruturação dessas páginas, criando um espaço fixo para os concursos de forma que a cada ano possamos atualizar apenas as informações básicas de datas, premiação, vencedores, deixando a lista de monumentos/coisas a serem fotografadas de forma mais fixa como listas.

Vocês podem conferir o total de imagens carregadas no commons ao longo dos anos através dos links: Wiki Loves Monuments Wiki Loves the Olympics Wiki Loves Earth ao todo recebemos mais 35.000 imagens e em todas as edições que participamos, pelo menos 1 imagem ficou classificada entre as melhores do mundo na etapa internacional. Portanto nossa participação vem gerando impacto super positivo e boa repercussão na mídia nacional, por isso acho válido continuar com a realização de ambos os concursos por aqui.

Criamos apenas uma página informativa e de planejamento no commons e redirecionamos todo o fluxo para a pt.wiki, de forma que nossa comunidade possa receber os novos colaboradores e todo o fluxo de visitas.

A cada ano replicamos essa estrutura o que gera trabalho adicional e muitas páginas legadas. Gostaria de sugestões e apoio de vocês pois já estamos nos preparando para a realiação do Wiki Loves Earth 2017 e Wiki Loves Monuments 2017.

Atenciosamente

Rodrigo Padula (discussão) 12h13min de 8 de fevereiro de 2017 (UTC)

Seja audaz. Faça como o Conde Dantes e o Mr._Fulano fizeram no WikiJogos, crie um modelo fácil de copiar e colar e coloque-o na página principal. Depois de cada edição, arquive numa subpágina. - Épico (disc)/(contrib) 14h25min de 8 de fevereiro de 2017 (UTC)

Também: nunca superestime a inteligência humana e repita, negrite, destaque e repita claramente que ao enviar as fotos para o Commons o fotografo perde os direitos autorais sobre elas. Tivemos alguns casos em 2016 de pessoas querendo tirar as imagens após não terem ganhando o concurso. - Épico (disc)/(contrib) 14h40min de 8 de fevereiro de 2017 (UTC)

Épico, não se perdem direitos autorais ao licenciar a distribuição com creative commons. Não sei se é prática comum, mas há a página commons:Commons:Courtesy deletions. GoEThe (discussão) 15h20min de 8 de fevereiro de 2017 (UTC)

@Épico: queria definir isso em consenso com a comunidade para ver inclusive se vale criar algo fixo ou deixar da forma que está, replicando a cada ano todas as páginas, repensando as predefinições e etc. Sobre as informações para os participantes, colocamos nas informações gerais e em cada upload o commons pergunta o participante quanto aos direitos e atribuição de licenças, o problema é que ninguém lê a sério. Não sei se a licença CC permite "voltar atrás" e desaceitar o termo que foi aceito ao carregar as imagens. Muitos ainda colocam marca dágua com "todos os direitos reservados" e aceitam os termos do commons carregando sob CC-BY-SA. Realmente essa parte é meio impossível de resolver. @GoEThe: Administradores do commons têm removido as fotos mediante solicitação, mas são casos bem isolados perante os milhares de participantes e as mais de 35.000 imagens carregadas até hoje. Realmente precisamos de mais engajamento da comunidade nesses concursos, tenho contado muito com colaboradores externos ao movimento Wikimedia. Com certeza com mais sugestões e discussões como essas, poderemos melhorar os resultados finais dos concursos. Obrigado pela participação nessa proposta!Rodrigo Padula (discussão) 16h20min de 8 de fevereiro de 2017 (UTC)

Cheguei um pouco atrasado, mas acho que ainda vale a pena opinar. Você já pensou em algum tipo de estrutura para os leiautes ou só pensa em tornar o processo de criação de novas predefinições mais fáceis, Padula? Já pensou em algo? --Zoldyick (Discussão) 02h08min de 15 de fevereiro de 2017 (UTC)

Conversei com o Raphael, designer do nosso grupo, vamos criar uma página fixa para ser usada todos os anos seguintes em Wikipédia:Wiki_Loves_Earth_Brasil, ali dentro manteremos links para dados históricos e informações sobre as edições anteriores. Estou vendo como implementar o design em desenvolvimento pelo Raphael e em seguida postarei novidades por aqui Rodrigo Padula^{(Fale comigo)} 14h33min de 1 de março de 2017 (UTC)

[Ver]

Dispensa da DB para certos tipos de bloqueio

Prezados, atualmente a WP:PB prevê que para todos os bloqueios, o bloqueado pode abrir uma seção para defesa. No entanto, as DB tem que durar no mínimo 72 horas, e há pedidos de revisão de bloqueios que foram aplicados por 1 dia, ou são pedidos em casos simples, que não necessitam da ampla participação. Na en.wiki, como o Antero de Quintal mencionou certa vez, em uma discussão que me foge à memória, há um sistema em que o bloqueado pede, através de uma predefinição na própria PDU, então conversa com um, dois ou mais Sysops sobre o bloqueio. Por isso, minha proposta para ser incluída na PB pode ser a seguinte:

A dispensa da DB para bloqueios aplicados com duração não superior a 3 dias ou para bloqueios cuja decorrência não sejam de fatos que exijam análise mais completa de evidências por parte dos administradores. Ex.: bloqueios por verificadores, comportamento disruptivo persistente, proposição de ampliação de bloqueios por tempo indeterminado.Sendo que a discussão ocorrerá na PDU do usuário bloqueado.

Caso queiram propor mudanças ou retificações, fiquem à vontade caros colegas. Creio que essa mudança pode facilitar nessa área, além de evitar que DBs possam se tornar cansativas e repetitivas. Eta Carinae (discussão) 14h42min de 8 de fevereiro de 2017 (UTC)

Já foi proposto algo parecido em Wikipédia:Esplanada/propostas/Mudança nos processos de revisão de bloqueio (28out2014).
No geral me parece uma boa ideia a simplificação dos pedidos de revisão de bloqueio para os casos menos controversos. --Lord Mota^✠ 19h59min de 8 de fevereiro de 2017 (UTC)

Exatamente Lord Mota. As vezes são criadas discussões desnecessárias ou então que se tornam um amontoado de argumentos de bloqueado, que na maioria das vezes é apenas desconhecimento de políticas. Para isso, bastaria uma pequena discussão na própria PDU para esclarecer e, se for o caso, desbloquear ou manter. Casos mais simplistas, que não se enquadram nas situações acima poderiam ser feitas dessa forma. Eta Carinae (discussão) 20h16min de 8 de fevereiro de 2017 (UTC)

Vejo que a discussão anterior foi dominada, e de certo modo bloqueada, por elementos ligados ao mundo da fantocharia, alguns deles hoje banidos do projecto, de modo que me parece que está mais que na hora de rediscutir isso.

De modo geral, eu Concordo com a redução da burocracia, e em especial no caso de bloqueios com pouca probabilidade de controvérsia apoio esse tipo de solução. O que me parece importante é que seja fácil detectar a existência dos pedidos de revisão de bloqueio. Acharia muito interessante e eficaz que um bot comunicasse no Café dos Administradores (ou outro sítio que se ache apropriado) a existência desses pedidos - inclusive de IPs - sempre que sejam feitos, de modo a que um administrador possa facilmente dar-lhes seguimento.-- Darwin ^Ahoy! 05h21min de 9 de fevereiro de 2017 (UTC)

Acredito que bloqueios deveriam ser levados para uma discussão separada apenas quando esta chegasse a um nível elevado de discussão na PDU do usuário bloqueado. Concordo bastante com a ideia de usuários com bloqueios menores e menos controversos, caso queiram se justificar, adicionarem uma predefinição na própria PDU de modo a "conversar" com administradores por lá. Eu mesmo passei por um caso assim. Sofri um bloqueio de 3 dias em dezembro de 2016 por causa de uma fatalidade pessoal e acredito que a discussão teria sido mais ágil e menos burocrática se tivesse ocorrido na minha própria PDU. Miq, o Coelho ^olar 05h31min de 9 de fevereiro de 2017 (UTC)

Darwinius, creio que a partir de uma predefinição feita para a revisão do bloqueio na PDU possa ser feita essa notificação, assim como já há nas mudanças recentes. Eta Carinae (discussão) 10h44min de 9 de fevereiro de 2017 (UTC)

E ela avisa nas MRs e nos Vigiados que há bloqueios por rever?-- Darwin ^Ahoy! 11h16min de 9 de fevereiro de 2017 (UTC)

Darwinius, dependendo das edições para detectar automaticamente as PDUs onde há a predef para revisão de bloqueio, sim, pode ser feito um contador, que pode ser incluído nas mudanças recentes ou no café dos administradores. Eta Carinae (discussão) 11h19min de 9 de fevereiro de 2017 (UTC)

Então penso que isso deve ser feito, e da forma mais simples possível - um admin revê e avalia o bloqueio, e toma a decisão que lhe parecer mais cabível. O ideal é mesmo reportar nalguma página, tipo Café dos Administradores, para que fique um registo mais permanente dessas revisões, e avaliar o desempenho da coisa.-- Darwin ^Ahoy! 11h25min de 9 de fevereiro de 2017 (UTC)

Concordo Me parece muito boa a ideia de desburocratizar o processo, mas acho que precisamos definir duas coisas, uma é a visibilidade do processo, criar um robô que atualize uma página com uma lista dos processos em revisão é uma questão importante para que isso dê certo. Há tempos que não passeio pela Wikien, mas lá no começo de minha aventura nas Wikis fui bloqueado de forma errada por admin lá e foram meses antes de alguém se aperceber e registrar em minha PDU que isso havia sido errado, lembro bem que isso me desmotivou bastante e se não fosse o admin que resolveu "corrigir" a situação talvez não tivesse seguido o envolvimento. Além disso, lá há ArbCom para agir em casos em admins que bloquem erroneamente, aqui não. A outra questão é quais vão ser exatamente as mudanças na WP:PB que estão sendo propostas. Concordo plenamente com a ideia de transferir grande parte das discussões de bloqueio para PDUs dos bloqueados, mas aonde vai ficar a linha para se criar DB, quando o bloqueado tem "direito" a uma DB em separado e quais as condições para se considerar um bloqueio válido são questões muito importantes para se efetivar essa mudança. Chico Venancio (discussão) 14h01min de 9 de fevereiro de 2017 (UTC)

@Chicocvenancio: Eu penso que o bloqueado não deve ter à partida direito a pedir uma Discussão de Bloqueio, e que essa decisão deve partir do administrador ou administradores que avaliem o caso. Isso evitaria o abuso. E como a lista de pedidos de desbloqueio seria pública e bem visível, qualquer administrador (e possivelmente, qualquer editor? No nível de autorevisor?) pode por sua iniciativa abrir DBs nos casos que ache que se deve seguir esse procedimento.-- Darwin ^Ahoy! 15h22min de 9 de fevereiro de 2017 (UTC)

Chicocvenancio, como não entendo de scripts, acho que seria uma ajuda enorme. A princípio, seria uma coisa simples a meu ver, como um contador de pedidos no Café ou mesmo um bot atualizando uma página, ou mesmo as duas coisas. Para isso, creio que seria necessário uma predefinição específica, que poderia criar uma categoria automática, para que o bot possa identificar e atualizar. As mudanças podem ser feitas na PB seriam na seção sobre o canal de comunicação (detalhe, nem as regras atuais da DB estão claras lá), com a informação de que, em certos casos, a discussão irá ocorrer na PDU do bloqueado. Eta Carinae (discussão) 17h22min de 9 de fevereiro de 2017 (UTC)

O nível de burocracia nesta área é assustadora. Bloqueios claramente corretos e indefensáveis muitas vezes requerem a participação de dezenas de pessoas. Concordo com a proposta, mas faço uma observação relevante: para evitar guerras administrativas e conflitos prolongados, mesmo em casos menos controversos, se houver discordância entre administradores quanto a validade do bloqueio na PDU do bloqueado, deve-se levar o caso ao café dos administradores, onde, por um prazo a ser estabelecido, uma maioria simples decide. Érico (fale) 15h27min de 9 de fevereiro de 2017 (UTC)

Discordo da proposta acima, e oponho-me terminantemente a tudo o que sejam decisões por "maioria simples" entre administradores, que está bom de ver aonde levam. A isso se chama conseguir as coisas na marra, e é totalmente oposto ao espírito do projecto. Não há qualquer problema em que um administrador reveja a decisão de outro, isso ocorre a toda a hora aqui e em qualquer projecto Wikimedia, e não é nem nunca foi guerra administrativa. Guerra administrativa ocorre quando o primeiro administrador (ou um terceiro) intervém para repor a acção do primeiro sem qualquer discussão. E isso se evita muito facilmente, tendo um mínimo de responsabilidade naquilo que se faz.-- Darwin ^Ahoy! 15h32min de 9 de fevereiro de 2017 (UTC)

Discussão tangencial

Então você discorda da existência de discussões de bloqueio. E você está errado. Muitas vezes as pessoas discordam de todas as ações e comentários de outro administrador por birra e infantilidade - e isso "certas" pessoas deixam cada dia mais evidente. Érico (fale) 15h36min de 9 de fevereiro de 2017 (UTC)

@Érico: Admira-me muito que um editor tão experiente, e que tem conseguido acumular tantos cargos aqui, ainda desconheça a nossa política de bloqueio ao ponto de supor que as decisões em Discussões de Bloqueio são votações decididas por "maioria simples". A política é bem clara: "apoio justificado e embasado nas políticas e recomendações do projeto de pelo menos três administradores não-envolvidos, responsáveis pela análise e síntese cuidadosa dos argumentos". Pode arranjar 30 administradores que apoiem um bloqueio, se nenhum justificar esse apoio conta como zero e o editor é desbloqueado. Isso não é nenhuma votação para que possa ser decidida por "maioria simples". O que você propôs acima é que um grupelho de administradores possa efectivamente bloquear a abertura de uma Discussão de Bloqueio formal, bastando para isso uma votação por maioria simples num tópuico do Café dos Administradores. Isto, para mim, é inadmissível. Para decisões por maioria simples entre administradores não contem com o meu apoio. -- Darwin ^Ahoy! 15h44min de 9 de fevereiro de 2017 (UTC)

Que novidade, Darwinius! Descobriu o fogo! Lol, isso parece-me muito evidente no comentário que escrevi. As DBs são definidas por maioria simples de administradores. Minha opinião é de que o mesmo deve ocorrer no café dos administradores se houver divergência na PDU do bloqueado. Isto é, um administrador bloqueia, outro desbloqueia, outro discorda, outro concorda... mesmo em casos nada controversos, existem, como eu disse acima, administradores que perseguem seus colegas o quanto podem e muitas vezes isso acarreta a conflitos prolongados. Não acho que é este o objetivo dessa proposta. Érico (fale) 15h49min de 9 de fevereiro de 2017 (UTC)

Darwinius, não adianta reescrever sua resposta para parecer que quis dizer outra coisa. DBs são decididas por maioria simples e é tão óbvio que os argumentos precisam seguir a política que sequer citei. Esqueci que você gosta tudo nos mínimos detalhes. Ou, melhor, arranja qualquer detalhe menor para discordar apenas porque o comentário foi escrito por mim. Muito maduro de sua parte. Érico (fale) 16h22min de 9 de fevereiro de 2017 (UTC)

Eu não preciso de reescrever nada, você mesmo acabou de repetir novamente, e pela terceira ou quarta vez, que pensa que as Discussões de Bloqueio neste projecto são decididas por maioria simples, conceito que somente existe para votações. Mas não vamos tornar isto num diálogo, certo? Vamos ouvir mais opiniões, até porque eu tenho curiosidade em saber se essa sua proposta de minivotações entre panelinhas de administradores para decidir sobre a abertura de pedidos formais de revisão de bloqueio colhe realmente algum apoio entre a comunidade editorial deste projecto.-- Darwin ^Ahoy! 16h40min de 9 de fevereiro de 2017 (UTC)

Senhores, por favor, não se excedam. A proposta aqui é justamente para evitar DBs cansativas. Creio que, em caso de controvérsia sobre o bloqueio, o correto seria a RAA, afinal atitudes controversas dos administradores são tratadas lá. Eta Carinae (discussão) 17h22min de 9 de fevereiro de 2017 (UTC)

Darwinius, falso. O conceito que escreveu refere-se a discussões de bloqueios, também conhecidas simplesmente como DBs. Não propus algo novo. E, EVinente, lamento muito se existe determinadas pessoas que não conseguem tolerar minhas opiniões sem precisar fazer um barraco, mentir ou desvirtuar uma proposta inteira; o problema é delas, não meu. Érico (fale) 18h20min de 9 de fevereiro de 2017 (UTC)

┌─────────────────────────┘ @EVinente: Como escrevi acima, Discordo em absoluto do uso de minivotações entre panelinhas de administradores para autorizar ou não a abertura de uma revisão formal de bloqueio, seja no Café dos Administradores, seja via RAA, que é precisamente isso. E não percebo como quer evitar DBs cansativas - mas, ao menos, regidas pelas regras do projecto - trocando-as por esse purgatório absurdo das RAAs que funcionam por maioria simples numa votação entre administradores, ou seja, a mais completa panelagem. Algo tão fundamental como a revisão de bloqueios não pode estar refém de maiorias facilmente manipuláveis por grupelhos, mas sim das regras deste projecto. Isto aqui ainda não é a casa da Mãe Joana.-- Darwin ^Ahoy! 19h09min de 9 de fevereiro de 2017 (UTC)

Como podemos então melhorar a proposta Darwinius? Eu lembro que minha intenção seria justamente a discussão na PDU pois a revisão passaria a ser um pequeno debate e diálogo com o bloqueado. Eta Carinae (discussão) 19h38min de 9 de fevereiro de 2017 (UTC)

É muito cansativo ter que ficar fazendo fact-check logo após os comentários de Darwinius. Eu estava referindo-me a bloqueios NÃO CONTROVERSOS onde pode haver divergência por infantilidades. A propósito, esta proposta fala disso, porém penso que deveria haver alguma forma de evitar guerras administrativas nesses casos mais óbvios em que outros administradores "discordam por discordar". Érico (fale) 19h42min de 9 de fevereiro de 2017 (UTC)

@EVinente: Penso que a coisa deve ser feita do modo mais simples, e sem o tipo de devaneios ditatoriais que foram propostos acima. Vejamos:

1. Informado sobre essa possibilidade na predefinição de bloqueio, o bloqueado coloca a predefinição de desbloqueio, que já contém ela própria espaço para que sejam expostos os motivos porque pede a revisão do bloqueio;
2. Um processo automatizado (bot, por exemplo) coloca a informação de que há um pedido de revisão de bloqueio no Café dos Administradores ou outra página apropriada;
3. Um ou mais administradores avaliam o caso, e dá/dão seguimento conforme a sua avaliação: Nega a revisão, remove o bloqueio, negoceia um desbloqueio, ou envia para revisão formal numa Discussão de Bloqueio.
4. A partir deste ponto, qualquer acção administrativa sobre o bloqueio terá de ser discutida previamente no Café dos Administradores, ou directamente com quem fez a revisão, por forma a que não se incorra em Guerra Administrativa.

A abertura de uma Discussão de Bloqueio formal pode ser feita sempre em qualquer momento do processo por um administrador (ou editor de um determinado estatuto), uma vez que não só não se trata de acção administrativa, como reverte em benefício da justiça e do bloqueado, que é sempre o que se quer.

Creio que é mais ou menos assim que isto se passa em vários outros projectos, e parece-me um sistema bastante simples e eficaz.-- Darwin ^Ahoy! 19h56min de 9 de fevereiro de 2017 (UTC)

Uau, exatamente como escrevi! Chegamos a um consenso, então. Parabenizo pela forma madura e responsável como transformou uma opinião idêntica ao espetáculo de acima. Érico (fale) 20h03min de 9 de fevereiro de 2017 (UTC)

Olhe que você, muito francamente, anda um tanto revisionista. Isto é o que você escreveu: "mesmo em casos menos controversos, se houver discordância entre administradores quanto a validade do bloqueio na PDU do bloqueado, deve-se levar o caso ao café dos administradores, onde, por um prazo a ser estabelecido, uma maioria simples decide."

Isto implica que qualquer discordância, por mais injustificada ou pontual que seja, trava todo o processo até que tenha lugar a tal panelagem no Café dos Admins pelo tal prazo combinado, onde os conjurados votam por maioria simples sobre o destino a dar ao bloqueio. Isto efectivamente passa por cima do actual sistema de Discussão de Bloqueios e pode inclusive impedir que bloqueios absolutamente injustos e fora das regras do projecto sejam discutidos, porque uma maioria de administradores não quer.

Agora leia o que eu escrevi acima, e veja se é o mesmo. Mas se concorda com a minha proposta, ainda bem, é isso mesmo que se quer.-- Darwin ^Ahoy! 20h13min de 9 de fevereiro de 2017 (UTC)

Isso se encaixa mais a você, que espera outros responderem para mudar o teor de sua pergunta. Meu comentário, embora resumido, não implicaria nada do que você disse. Pelo contrário, tem um teor semelhante ao que você também acha. Érico (fale) 20h27min de 9 de fevereiro de 2017 (UTC)

@EVinente: Penso que a coisa deve ser feita do modo mais simples, e sem que as Discussões de Bloqueio corram o risco de ficar reféns de votações por "maioria simples", que hipoteticamente ocorreriam em locais vedados à comunidade, como o Café dos Administradores, e cuja participação seria limitada somente a administradores, como foi proposto acima, o que me parece bastante grave e de evitar. Vejamos:

1. Informado sobre essa possibilidade na predefinição de bloqueio, o bloqueado coloca a predefinição de desbloqueio, que já contém ela própria espaço para que sejam expostos os motivos porque pede a revisão do bloqueio;
2. Um processo automatizado (bot, por exemplo) coloca a informação de que há um pedido de revisão de bloqueio no Café dos Administradores ou outra página apropriada;
3. Um ou mais administradores avaliam o caso, e dá/dão seguimento conforme a sua avaliação: Nega a revisão, remove o bloqueio, negoceia um desbloqueio, ou envia para revisão formal numa Discussão de Bloqueio.
4. A partir deste ponto, qualquer acção administrativa sobre o bloqueio terá de ser discutida previamente no Café dos Administradores, ou directamente com quem fez a revisão, por forma a que não se incorra em Guerra Administrativa.

A abertura de uma Discussão de Bloqueio formal pode ser feita sempre em qualquer momento do processo por um administrador (ou editor de um determinado estatuto), uma vez que não só não se trata de acção administrativa, como reverte em benefício da justiça e do bloqueado, que é sempre o que se quer.

Creio que é mais ou menos assim que isto se passa em vários outros projectos, e parece-me um sistema bastante simples e eficaz.-- Darwin ^Ahoy! 23h07min de 9 de fevereiro de 2017 (UTC)

• Citação: A dispensa da DB para bloqueios aplicados com duração não superior a 3 dias ou para bloqueios cuja decorrência não sejam de fatos que exijam análise mais completa de evidências por parte dos administradores. Ex.: bloqueios por verificadores O bloqueio efetuado em decorrência de CheckUser só deve ser alterado ou removido mediante a revisão por um verificador. Nem sempre acompanho todas as discussões de bloqueio, mas se este princípio universal não foi respeitado, então algo errado está acontecendo. RadiX∞ 00h49min de 10 de fevereiro de 2017 (UTC)

@RadiX: Aí está, esse é um bom exemplo de caso em que discussões de bloqueio são desnecessárias, mas neste momento permite-se a sua abertura a pedido do usuário, mesmo os administradores não tendo nada para avaliar ali.-- Darwin ^Ahoy! 07h44min de 10 de fevereiro de 2017 (UTC)

Exatamente Darwinius, como por exemplo, esse aqui. Eta Carinae (discussão) 11h30min de 10 de fevereiro de 2017 (UTC)

Completamente fora da realidade aquela discussão. Obrigado apontá-la aqui, EVinente. Primeiro, pelo fato de se tratar de um bloqueio baseado em verificação: nesse caso, administradores sem acesso de checkuser pouco ou nada têm a avaliar. Segundo: a conta estava globalmente bloqueada, por abuso cross-wiki. Mesmo que na discussão se decidisse pelo desbloqueio, o efeito seria nulo. RadiX∞ 12h00min de 10 de fevereiro de 2017 (UTC)

Doutores, o que precisamos para seguir com essa proposta? Me parece que há um consenso para flexibilizar a exigência de DBs. Aparentemente ninguém se opôs ao texto da proposta do EVinente, mas foram colocados temas adicionais. Principalmente, coloca-se uma regra para qualquer administrador (ou outro estatuto, reversor ou autorrevissor) poder deslocar a discussão para o café ou para uma DB propriamente dita, elaborem nessa discussão abaixo. Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Estatuto necessário para criar DB

Houve alguma discussão sobre quem poderia criar uma DB para casos que não seria automático (mais de 3 dias de bloqueio, pedidos para expansão do bloqueio) sob essa nova regra. Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Eu penso que autorrevissor poderia ser suficiente para iniciar, se percebermos um problema com essa situação podemos ver como tratar (remover o estatuto ou alterar a regra). Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Vamos então começar a por os pingos nos iis. Eu Concordo com a proposta no geral, mas Discordo desta parte - "com duração não superior a 3 dias" - que não acrescenta nada e só confunde, pois um bloqueio longo ou permanente pode perfeitamente ser pacífico, e é, na maioria dos casos, mas nada garante que um bloqueio curto (até de meia hora) não seja controverso. Pelo contrário, um bloqueio de meia hora pode ser até especialmente controverso, pelo carácter vexatório que contém: isso consta das políticas do projecto, inclusive, em WP:PB. Na proposta não deve constar qualquer referência a tempos de bloqueio.

Quanto ao estatuto, eu concordo que seja ao nível de autorrevissor, não vejo necessidade de ser limitado a mais que isso.-- Darwin ^Ahoy! 14h59min de 12 de fevereiro de 2017 (UTC)

Darwinius, coloquei essa frase porque as DBs tem o prazo mínimo para arguição de 72 horas, mas enfim, pode ser retirado e substituído por uma frase mais objetiva e clara. :) Eta Carinae (discussão) 15h08min de 12 de fevereiro de 2017 (UTC)

EVinente Sim, é verdade que isso está lá, e deve continuar. Isso foi colocado porque, na época, acontecia DBs ficarem mofando com o coitado bloqueado tempos intermináveis porque quase nenhum administrador tinha paciência ou interesse em trabalhar nessa área, o que era profundamente injusto. Por isso que foi colocado o limite de 3 dias para argumentação, ao fim do qual, a argumentação não existindo nos moldes que consta nessa política, o bloqueio é levantado. Mas essa sua proposta, pelo que percebo, não é para substituir DBs, mas sim para restringi-las aos casos em que haja realmente alguma necessidade de discussão de um bloqueio, de modo que a referência a tempos é desnecessária. O bloqueado não pode ele próprio forçar a abertura de uma DB, mas esse é um direito de qualquer outro "cidadão" (e.g.: autorrevisor) do projecto.-- Darwin ^Ahoy! 15h17min de 12 de fevereiro de 2017 (UTC)

DBs sobre verificações

O RadiX colocou uma questão importante, na maioria dos casos de verificação não há nada que possa ser avaliado por administradores. Nesse caso acho que somente verificadores e administradores devem poder criar uma DB, e administradores somente no caso de relevante questão a ser discutida (sem ser automático). Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Não é necessário especificar essa situação, pois já consta da proposta no caso mais geral: "cuja decorrência não sejam de fatos que exijam análise mais completa de evidências por parte dos administradores". Ora, se os administradores não têm nada para avaliar, não pode haver Discussão de Bloqueio. Mas se se achar que ajuda, e provavelmente ajuda, pelo menos a evitar que abram esse tipo de DBs devido a interpretação deficiente da política, pode eventualmente ser colocado como exemplo o caso dos bloqueios por verificação.-- Darwin ^Ahoy! 15h02min de 12 de fevereiro de 2017 (UTC)

Talvez eu tenha sido um pouco extensivo Chicocvenancio e Darwinius. Geralmente os bloqueios por verificação quando controversos, tem uma ampla discussão no nosso espaço privado de verificação, em que todos os checkusers da pt.wiki analisam conjuntamente os dados apresentados pela ferramenta, diffs de edição. E como a própria política da WMF restringe a publicidade das informações dos processos, é fato que "quase não há nada para se analisar". Eta Carinae (discussão) 15h10min de 12 de fevereiro de 2017 (UTC)

Outras propostas

Concordo O ideal era ter um ArbCom que lidasse com as revisões de bloqueio, pois a comunidade não tem tempo/disponibilidade/vontade para participar em tanta DB, raro é o dia que não tem uma aberta. Até lá sempre é melhor restringir um pouco a abertura de DBs, não faz muito sentido todo e qualquer bloqueio poder ser questionado numa DB formal aberta a toda a comunidade. Por isso até 3 dias de bloqueio acho que a discussão pode decorrer sem problemas na PDU do editor e só se algum administrador discordar poderá então ser aberta uma DB, excepção feita claro a bloqueios que levem à perda de estatutos (burocratas, reversores). Gonçalo Veiga (discussão) 09h02min de 12 de fevereiro de 2017 (UTC)

Um ConArb que seja obrigado a revisar todos os bloqueios nunca irá funcionar. A escolha de casos do ConArb deve ser voluntária e autoelegida àqueles que realmente vão fazer uma diferença nas políticas do projeto. Os casos comuns devem ser lidados pelos administradores. Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Proposta adicional Outra alteração relevante seria restringir o poder de bloquear sysops somente às DBs e aos burocratas. Assim acabavam os intermináveis pedidos de bloqueios nos PAs que geralmente ficam desertos de atendimento pelos demais sysops mas cheios de abuso de espaço público entre os contendores. Gonçalo Veiga (discussão) 09h10min de 12 de fevereiro de 2017 (UTC)

Burocratas não foram escolhidos para isso, mas para lidar com a gestão de privilégios. Se não me engado Há burocrata sem ser administrador, inclusive, e ele não pode bloquear. Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

@Gonçalo Veiga: Privilegiar os administradores de modo a que não possam ser bloqueados pelo procedimento normal não me parece fazer nenhum sentido. Por um lado, um administrador não é nenhuma criatura excepcional que nunca comete erros, nem pode estar acima de toda a restante comunidade ao ponto de dispor até de foro próprio. Por outro lado, são mais que muitos os exemplos em que houve abuso por parte de administradores que justificasse um bloqueio imediato, sendo o caso mais óbvio e recorrente a violação de WP:R3R.-- Darwin ^Ahoy! 09h52min de 12 de fevereiro de 2017 (UTC)

@Darwinius: O número de sysops bloqueados é baixíssimo mas o número de pedidos é elevado e por vezes insistente. Deixar isso para os burocratas ou para as DBs (casos mais graves) evitaria pedidos recorrentes (esmagadoramente sem fundamento) e pedidos desertos (mesmo os com fundamento geralmente não são atendidos, talvez porque a maioria não se sente confortável para bloquear colegas), além de acabar com os abusos de espaço público na página dos pedidos de bloqueio (com longas e acesas trocas de argumentos que são pura perda de tempo). Não se trata de foro privilegiado mas somente de eficiência. Já se faz o mesmo hoje em dia com os pedidos de remoção de estatutos, quando não tem o mínimo de fundamento o burocrata arquiva logo o pedido sem análise da comunidade; deveria suceder o mesmo com os bloqueios. Gonçalo Veiga (discussão) 10h13min de 12 de fevereiro de 2017 (UTC)

@Gonçalo Veiga: Citação: Gonçalo Veiga escreveu: «acabar com os abusos de espaço público na página dos pedidos de bloqueio (com longas e acesas trocas de argumentos que são pura perda de tempo)» Realmente não sei do que está a falar, já que a nossa Política de Bloqueio já proíbe o diálogo na página de pedidos de bloqueio, e inclusive prevê bloqueio imediato e sem aviso a quem infringir isso, especialmente no caso de editores experientes como são, por definição, os administradores e burocratas. Se isso em algumas situações não está a ser cumprido, é passar a cumprir, pois a regra já existe e é bem clara.

É algo incontestável, lógico e do conhecimento geral aqui no projecto que pedidos de bloqueio complexos, envolvam administradores ou não, regra geral não são imediatamente atendidos, e em muitos casos nem são atendidos de todo, pelo que o assunto se resolve por si próprio: é um não problema. O que deve ser feito nesses casos é encaminhar para a Discussão de Bloqueio, que de resto é o que geralmente se faz.

Não aplicar aos administradores as regras gerais da política de bloqueio, atribuindo-lhes a especial prerrogativa de disporem sempre de uma discussão de bloqueio prévia, ou decisão por burocrata, é efectivamente dar-lhes foro próprio e privilegiado. Administradores não são nenhuma espécie de seres especiais, são editores sujeitos a erros, a crises emocionais, e até a toda a casta de patifarias, desde a criação de socks e contas de ataque até à falsificação consciente de conteúdos, tudo isso já aconteceu com contas que tinham o estatuto de administrador. Não vejo nenhuma razão para que tenham um tratamento diferenciado no que respeita a bloqueios.-- Darwin ^Ahoy! 10h32min de 12 de fevereiro de 2017 (UTC)

@Darwinius: Citação: Darwinius escreveu: «Realmente não sei do que está a falar, já que a nossa Política de Bloqueio já proíbe o diálogo na página de pedidos de bloqueio, e inclusive prevê bloqueio imediato e sem aviso a quem infringir isso, especialmente no caso de editores experientes como são, por definição, os administradores e burocratas. Se isso em algumas situações não está a ser cumprido, é passar a cumprir, pois a regra já existe e é bem clara.» O histórico é de livre consulta. Gonçalo Veiga (discussão) 11h14min de 12 de fevereiro de 2017 (UTC)

Não tem nenhum foro privilegiado, pois a Política de Bloqueio continua a aplicar-se aos administradores tal como aos demais, somente mudariam os apreciadores dos pedidos de bloqueio, para assim se poder acabar com os pedidos descabidos e conflitos conexos que inundam os PAs. Além de que faz algum sentido um sysop recém-eleito poder bloquear um sysop experiente ou um burocrata por exemplo?! Aquilo que o Onni fez ao Teles não deveria sequer ser possível pelas regras, um sysop júnior bloquear um steward, ridículo! Seria o mesmo que um juiz do Supremo Tribunal de um país poder ser julgado por um juiz da 1ª instância, seria ilógico. Gonçalo Veiga (discussão) 11h14min de 12 de fevereiro de 2017 (UTC)

@Gonçalo Veiga: Citação: Gonçalo Veiga escreveu: «Não tem nenhum foro privilegiado, pois a Política de Bloqueio continua a aplicar-se aos administradores tal como aos demais» Compreenda que há uma diferença entre foro (sítio onde se exerce a lei) e lei.

Citação: Gonçalo Veiga escreveu: «um sysop júnior bloquear um steward, ridículo! Seria o mesmo que um juiz do Supremo Tribunal de um país poder ser julgado por um juiz da 1ª instância, seria ilógico.» Administradores não são juízes, e erram como toda a gente. E tempo de casa ou cargos externos ao projecto nunca foram o mesmo que competência ou sequer experiência. Lembro-me bem, por exemplo, de um caso de um steward cuja experiência neste projecto era praticamente nula, levando a uma intervenção absolutamente desastrosa. "O histórico é de livre consulta".-- Darwin ^Ahoy! 11h31min de 12 de fevereiro de 2017 (UTC)

┌─────────────────────────┘ Peço que tentemos manter o foco aqui e desenvolvamos a proposta que parece ter um consenso para ser aplicada. Chico Venancio (discussão) 13h37min de 12 de fevereiro de 2017 (UTC)

Verdade Chicocvenancio, também discordo de uma ideia de transformar os burocratas e admins em uma espécie de Suprema Corte. Não somos melhores que ninguém nesse assunto. Eta Carinae (discussão) 15h11min de 12 de fevereiro de 2017 (UTC)

Esboço da proposta para discussão

A dispensa da DB para bloqueios aplicados cuja decorrência não sejam de fatos que exijam análise mais completa de evidências por parte dos administradores. Ex.: comportamento disruptivo persistente, proposição de ampliação de bloqueios por tempo indeterminado, forte controvérsia sobre a validade do bloqueio. Sendo que a discussão ocorrerá na PDU do usuário bloqueado.

Exemplos de ocasiões em que a discussão pode ser feita na PDU:

• Testes indevidos de usuários novatos;
• Criação de página repetidamente apagada;
• Bloqueios amplos de IPs dinâmicos;
• Violação, sem clara intenção, de direitos autorais;

• Modificações na notificação de bloqueio:

1-Está autorizado(a) a usar esta página para sua defesa. Enquanto durar o bloqueio, ela será destinada, exclusivamente, à argumentação, a fim de mostrar qualquer incorreção de acordo com a política do projeto. Você deve respeitar as normas de conduta e não fazer ataques pessoais. A violação dessas políticas poderá levar à suspensão deste direito, bem como ao aumento do bloqueio inicial. Lembre-se de solicitar a avaliação desse bloqueio por parte de um administrador colocando, abaixo dessa mensagem, o seguinte código: <Local para a predefinição criada para que um Bot possa atualizar um contador ou avise>

2-Se discorda do teor da discussão levantada aqui, e queira solicitar uma apreciação formal de seu bloqueio por mais administradores, inclua, logo abaixo desta mensagem, o seguinte código: {{subst:Revisão de bloqueio}}(Comentário: Essa predefinição atual pode ter que ser renomeada para não causar confusão) e grave a modificação. Depois, siga o link e apresente as devidas justificativas, de acordo com a política de bloqueio.

• Um bot (creio que o Alchimista possa ajudar)deve ser programado para atualizar um contador ou página, ou os dois, no café dos administradores sobre a existência de pedidos de revisão solicitados; A predefinição deve criar uma categoria específica para que o bot possa ler, sem erros. E o encerramento da discussão também deve remover a categoria automaticamente, para evitar leitura repetida de solicitações já atendidas. Eta Carinae (discussão) 15h42min de 12 de fevereiro de 2017 (UTC)

Darwinius, Chicocvenancio, conseguem ter mais uma melhor visualização da proposta, caros colegas? Eta Carinae (discussão) 15h42min de 12 de fevereiro de 2017 (UTC)

@EVinente: A segunda parte parece-me desnecessária... Ele faz o pedido de revisão, o pedido é colocado num sítio que quem quiser pode seguir, para ser notificado também, e depois a discussão faz-se de modo informal na PDU dele, estando aberta a todos, com as regras de conduta do costume. Se ele não ficar satisfeito, mas ninguém achar que deve ser aberta a Discussão de Bloqueio, penso que não é necessário fazer mais nada. É importante realçar que um administrador que eventualmente tome conta do caso não é dono do caso, e pode perfeitamente ser ultrapassado em qualquer altura do processo por qualquer membro da comunidade com o estatuto suficiente (e.g., autorrevisor) que ache ser mais proveitosa a abertura de uma discussão formal.-- Darwin ^Ahoy! 16h07min de 12 de fevereiro de 2017 (UTC)

Darwinius estás a se referir na notificação de bloqueio? O item 2? Eta Carinae (discussão) 16h10min de 12 de fevereiro de 2017 (UTC)

Sim, o item 2. Ele realmente não serve para nada, pois o bloqueado, mesmo que queira, não pode forçar a abertura de uma DB quando mais ninguém concorda com ele.-- Darwin ^Ahoy! 16h16min de 12 de fevereiro de 2017 (UTC)

Contraproposta

• Penso que deveríamos simplificar o máximo possível a proposta. Grande parte das discussões de bloqueio é desnecessária. Portanto, faço a seguinte proposta:

• Pedidos em WP:PA/DB, com a intenção de revisão de um bloqueio em vigor, só deverão ser iniciados se:
  • Após solicitação do bloqueado ou de terceiros, houver discordância do bloqueio por pelo menos um administrador, e não for apropriado remover o bloqueio por ação unilateral, em razão do contexto ou complexidade do caso.
  • Houver discordância de outros administradores, independentemente da existência de um pedido de desbloqueio.
• Para usuários bloqueados em decorrência de uma verificação, a abertura de uma revisão formal em WP:PA/DB dependerá do parecer favorável de pelo menos um verificador, no que tange a não-utilização ilícita de fantoches por período considerável, como condição para a abertura do pedido. O resultado final do processo deverá refletir o consenso entre os administradores ou verificadores participantes. Não havendo concordância sobre o desbloqueio ou outra medida alternativa, prevalecerá a decisão anterior.
• Propostas para a aplicação de bloqueios em WP:PA/DB podem ser abertas a qualquer tempo, independentemente da avaliação prévia de um administrador.

RadiX∞ 16h18min de 12 de fevereiro de 2017 (UTC)

Bem RadiX, destes uma bela polida no que eu gostaria de propor. Concordo. Se houver um consenso, a gente passa a discutir as questões técnicas sobre como esses pedidos ocorrerão e como serão atendidos. Eta Carinae (discussão) 16h28min de 12 de fevereiro de 2017 (UTC)

É um pouco diferente, e mais completo, que aquilo que estava sendo proposto e estavamos a discutir, mas realmente não tenho nenhuma discordância com essa proposta, e parece bastante simples de aplicar. Não permite que alguém que não seja administrador abra uma DB de desbloqueio, mas de facto, se não se achar nem um único administrador que concorde com o desbloqueio, há uma grande probabilidade da DB estar à partida condenada ao fracasso. Eu Concordo também, assim como está.-- Darwin ^Ahoy! 16h31min de 12 de fevereiro de 2017 (UTC)

Eu removeria "do bloqueado" e deixaria para qualquer um poder solicitar a revisão do bloqueio na PDU. Fora isso Concordo com a proposta nesse formato. Chico Venancio (discussão) 17h21min de 12 de fevereiro de 2017 (UTC)

Eu acho pertinente e Concordo com a observação do Chicocvenancio, não é incomum o bloqueado por qualquer motivo não conseguir aceder ao projecto (ter a PDU bloqueada, estar em viagem, por exemplo), e pedir a um terceiro com quem tem contacto off-wiki que faça o pedido por ele.-- Darwin ^Ahoy! 17h44min de 12 de fevereiro de 2017 (UTC)

Sim, muito muito lembrado. Já fiz a alteração que vocês indicaram. Obrigado. RadiX∞ 17h55min de 12 de fevereiro de 2017 (UTC)

Concordo com a proposta de Radix, bem como com a observação feita pelo Chico. É um avanço considerável. @RadiX: Quanto a parte relativa aos bloqueios por verificação, como isso funcionará? Consenso entre todos os verificadores? Se um concordar, como no caso dos administradores, é suficiente? Érico (fale) 17h56min de 12 de fevereiro de 2017 (UTC)

Érico, eu penso que deveria ser uma decisão consensual entre eles. Mas, se ao menos um deles for prontamente favorável à revisão, já poderia ser iniciado o pedido. RadiX∞ 18h33min de 12 de fevereiro de 2017 (UTC)

Conforme mais um apontamento, fiz esta alteração. E assim avançamos mais um passo. RadiX∞ 18h43min de 12 de fevereiro de 2017 (UTC)

Discordo da contraproposta, não tem a limitação até 3 dias de bloqueio como está na proposta inicial, não concordo que bloqueios longos aplicados por um único sysop sem consulta aos demais não possam ser apresentados à comunidade numa DB. E os verificadores não podem ter um poder absoluto nos bloqueios da sua competência: não só a análise comportamental pode ser avaliada por qualquer editor como mesmo nas verificações técnicas o tempo de bloqueio deve poder ser deliberado livremente pelos demais administradores. Gonçalo Veiga (discussão) 23h10min de 12 de fevereiro de 2017 (UTC)

Discordo da contraproposta. Os verificadores simplesmente verificam se determinadas contas são partilhadas e transmitem as suas conclusões aos administradores. O facto de os verificadores também bloquearem é porque também são administradores. No entanto, esses bloqueios são feitos no papel de administrador, não no papel de verificador. A ferramenta de bloqueio está no pacote de administrador, não no de verificador. A partir do momento em que se conhece o resultado de uma verificação, a autoridade para se pronunciar sobre o bloqueio é igual para todos os administradores. O que se está a propor aqui é dar um poder desmesurado para restringir a decisão sobre bloqueios a dois ou três administradores que acumulam o cargo com o de verificador.

E se um conjunto de administradores, mesmo reconhecendo o resultado positivo de uma verificação, pretender diminuir ou alargar um bloqueio? Não pode? Precisa da autorização de dois ou três administradores especiais para abrir uma discussão? Porquê?

Há efetivamente um problema, que é a existência de administradores que se recusam a reconhecer a validade de uma verificação, mesmo quando os verificadores apresentam resultados conclusivos. Mas aí o que tem que ser avaliado é a prestação desses administradores. Esta contraproposta não resolve nada disso. Só cria um superestatuto megaespecial sem nenhuma base. Quintal ✁ 00h00min de 13 de fevereiro de 2017 (UTC)

Essa discordância deve-se provavelmente a uma interpretação divergente do texto. Deixei a redação mais clara, para evitar dúvidas acerca do que foi proposto. A concordância de um verificador para abertura do pedido de revisão refere-se a atestar se o usuário tem ou não abusado de fantoches durante o bloqueio - esta deve ser a condição para a abertura do pedido, ou seja: a não utilização de fantoches ilícitos para evasão de bloqueio. Na última sentença, escrevi "verificadores" em lugar de "administradores", por engano. Creio que isto deve ter colaborado para o equívoco. RadiX∞ 00h51min de 13 de fevereiro de 2017 (UTC)

Não achei nada pouco claro. O que está a ser proposto é

1) que ninguém pode abrir uma discussão de bloqueio sem a "aprovação" de um verificador.

2) que essa aprovação implica uma pescaria.

3) que é necessário consenso para alterar o bloqueio.

Só reparei agora neste último ponto. As discussões de bloqueio na pt.wiki são por maioria de opinião entre administradores. Você está, de forma subtil e camuflada numa subproposta, a querer alterar todo o processo de decisão. Quintal ✁ 00h59min de 13 de fevereiro de 2017 (UTC)

Não estou propondo qualquer alteração no processo de decisão existente, muito menos de maneira "camuflada". Os bloqueios discutidos em uma revisão formal são decididos por consenso e não por votação. Isto está explícito na política de bloqueio. Citação: WP:PB escreveu: «Os pedidos formais de revisão terão duração de, a princípio, três dias. Se uma discussão maior se fizer necessária, ela poderá prosseguir até que os administradores cheguem a um consenso, não devendo a discussão, no entanto, ultrapassar (...)» Este não é o objetivo da proposta, e esta parte do texto da contraproposta pode mesmo ser omitida aqui, por ser redundante.

A proposta não tem relação alguma com pescaria. Um verificador sabe se o usuário tem contornado o bloqueio, com que frequência, se tem utilizado proxies etc. Outros administradores, não. O que se propõe é que, para usuários bloqueados em decorrência de uma verificação e "para os quais se pretenda a reintegração ao projeto" (texto da PB), um verificador deva avaliar a procedência do pedido, com base nas evasões de bloqueio. RadiX∞ 01h14min de 13 de fevereiro de 2017 (UTC)

Não. As decisões das DBs são em função daquilo que a maioria apoia. Citação: 6.2.2 se existir oposição de um número de administradores igual ou superior ao dos que emitiram pareceres favoráveis à manutenção do ato administrativo em causa, este também será cancelado por falta de consenso. Isso foi decido por unanimidade em 2010. Curioso que nessa discussão, em 2010, foram alegadas irregularidades numa edição sua da PB muito semelhantes ao que está a tentar fazer aqui. E verificar sem evidências é pescaria. Quintal ✁ 01h32min de 13 de fevereiro de 2017 (UTC) 

Consensos e divergências

Voltando a essa discussão, parece haver um consenso, senão unanimidade, que seria proveitoso que algumas revisões de bloqueio não necessitassem do processo formal de "discussão de bloqueio" e fossem analisadas diretamente na PDU do usuário bloqueado.

Parece também haver um consenso a respeito da necessidade de expor essas revisões em um local que possa ser vigiado (lista ou página específica, preferencialmente atualizada pro bot).

Quanto aos requisitos mínimos a cerca de quem e quando podem decidir "elevar" a discussão de revisão de bloqueio para uma "discussão de bloqueio" formal parece haver alguma divergência (apresentadas na última proposta pelo Gonçalo Veiga e pelo Antero de Quintal, anteriormente discutida pelo Darwinius).

Há também uma divergência sobre texto sobre bloqueios efetuados por verificadores. Me parece que essa divergência é exclusivamente sobre o texto e há consenso para a ideia que administradores e usuários não podem discutir as questões técnicas de bloqueios efetuados por verificação enquanto verificadores não possuem exclusividade para discutir as questões comportamentais e de aplicação de regras a bloqueios feitos por estes (uma separação entre fatos e "direito", semelhante a juri e juiz no common law).

Penso que esse é o tema que resta discutir aqui, proponho que discutamos sobre essa questão (baseados no texto da última proposta). Se houver alguma divergência que não percebi, peço que me apontem. Chico Venancio (discussão) 15h34min de 5 de março de 2017 (UTC)

Requisitos para criar uma "discussão de bloqueio" formal

Trecho da proposta relevante a essa questão

• Pedidos em WP:PA/DB, com a intenção de revisão de um bloqueio em vigor, só deverão ser iniciados se:
  • Após solicitação do bloqueado ou de terceiros, houver discordância do bloqueio por pelo menos um administrador, e não for apropriado remover o bloqueio por ação unilateral, em razão do contexto ou complexidade do caso.
  • Houver discordância de outros administradores, independentemente da existência de um pedido de desbloqueio.

Bloqueio superior a 3 dias

Na proposta original do EVinente essa restrição foi retirada após oposição do Darwin. Chico Venancio (discussão) 15h34min de 5 de março de 2017 (UTC)

A mim parece que ter um critério objetivo pode ser vantajoso, mas a simplificação trazida na última proposta pelo RadiX me parece mais apropriada. Havendo discordância de ao menos um administrador será possível levar para DB. Chico Venancio (discussão) 15h34min de 5 de março de 2017 (UTC)

Bloqueios efetuados em decorrência de verificação

Trecho da proposta relevante a essa questão

• Para usuários bloqueados em decorrência de uma verificação, a abertura de uma revisão formal em WP:PA/DB dependerá do parecer favorável de pelo menos um verificador, no que tange a não-utilização ilícita de fantoches por período considerável, como condição para a abertura do pedido. O resultado final do processo deverá refletir o consenso entre os administradores ou verificadores participantes. Não havendo concordância sobre o desbloqueio ou outra medida alternativa, prevalecerá a decisão anterior.

O Gonçalo e o Antero apresentaram oposição ao texto colocado pelo RadiX na última proposta. Chico Venancio (discussão) 15h34min de 5 de março de 2017 (UTC)

Eu não me oponho ao texto como está, mas penso que pode ser melhorado no sentido de apontar a distinção entre papéis de verificadores (técnico relativo a ligação entre contas) e administradores (aplicação da PB e outras políticas do projeto). Chico Venancio (discussão) 15h34min de 5 de março de 2017 (UTC)

[Ver]

Vendagens do Album na infocaixa

Oi gente, não sei bem como fazer isso, mas vim aqui tentar. Eu gosto muito de editar artigos sobre filmes e CDs. E pude perceber que na infocaixa dos filmes tem a receita que o filme levantou. Achei que seria legal se os CDS também tivessem a quantidade de discos que foram vendidos. O que acham? Luanderson Camilo (discussão) 04h30min de 11 de fevereiro de 2017 (UTC)

Acerca de discos, a única fonte realmente fiável sobre vendas de discos são das certificadoras de cada país (e existe uma prática péssima no projeto por parte de IPs em colocar números de vendas baseados em tiragens de álbuns ou sem qualquer fonte, somente para 'vangloriar' artistas). Sendo assim, creio que é Desnecessário na área de música. Sobre filmes, não tenho o que dizer. Não edito nessa área. Fronteira ^{diga - veja} 12h09min de 11 de fevereiro de 2017 (UTC)

[Ver]

Filtro inteligente para mudanças recentes

O texto seguinte foi movido de: WP:Esplanada/anúncios#Filtro inteligente para mudanças recentes

Oi pessoal!

Um grupo de desenvolvedores voluntários criou uma ferramenta, chamada meta:Research:Revision scoring as a service ORES, que usa aprendizado de máquina para classificar edições Wiki. É uma ferramenta madura e feita com apoio da Wikimedia Foundation. Essas classificação automática serve para definir as chances de uma edição ser: boa, problemática, ou de má fé. A lista de possibilidades é maior que essa e pode ser estudada nas páginas descritas abaixo, neste anúncio.

Foi criada uma extensão para MediaWiki capaz de filtrar edições recentes com base na classificação feita por essa ferramenta. É possível que a Wikipedia lusófona seja a primeira a adotar essa ferramenta no universo Wiki em grande escala. Mas pra isso aconteça é necessário que a comunidade concorde com essa implantação. Escrevo aqui para informar e perguntar se essa extensão é bem-vinda. No momento essa extensão está em estágio Beta, ou seja, podem haver alguns problemas desconhecidos que serão visíveis apenas com o uso pela comunidade.

Mais informações e exemplos podem ser encontrados em mw:Edit Review Improvements/Filters for Special:Recent Changes.

A adoção dessa extensão vai tornar o trabalho de revisão muito mais rápido pois parto do esforço de classificação não é feito por humanos mas por modelo estatísticos. Estou disponível para maiores esclarecimentos.

Obrigado,

--Jonas_agx (discussão) 01h11min de 11 de fevereiro de 2017 (UTC)

@Jonas AGX: Concordo Da minha parte, essa ferramenta é muito bem vinda. Tenho-a usado muito, sem qualquer problema, e com grande eficácia nas Mudanças Recentes, permitindo detectar rapidamente as edições mais daninhas.-- Darwin ^Ahoy! 01h53min de 11 de fevereiro de 2017 (UTC)

@Jonas AGX: Concordo

. . . . . . . . . . . -- Chê Rapidim (discussão) 07h50min de 11 de fevereiro de 2017 (UTC)

@Jonas AGX: Concordo Ferramenta mais do que bem vinda. --Hume42 ✉ 14h03min de 11 de fevereiro de 2017 (UTC)

O texto acima foi movido de: WP:Esplanada/anúncios#Filtro inteligente para mudanças recentes

Concordo, mas não me ficou claro se isso será um novo item beta nas preferências ou se vai ser ativado para todos que tem o ORES ativado. (eu concordo de qualquer uma das formas, mas acho que seria bom deixar a situação clara) Chico Venancio (discussão) 14h06min de 11 de fevereiro de 2017 (UTC)

Obrigado pela pergunta @Chicocvenancio:. Pelo que entendi vai ser ativado para todos que tem o ORES ativado. --Jonas_agx (discussão) 04h29min de 12 de fevereiro de 2017 (UTC)

Exato. A opção beta existente será atualizada com uma nova descrição/imagem (conforme a tarefa phab:T144457), e haverá uma mensagem introdutória nas mudanças recentes assim que entrar e funcionamento para os usuários que optarem por testar os recursos. Helder 17h04min de 12 de fevereiro de 2017 (UTC)

Jonas AGX eu não entendi exatamente. O ORES por si só já filtra edições tanto nas páginas vigiadas quanto nas mudanças recentes, classificando-as como possívelmente prejudiciais ou não. Então o que de "novo" essa extensão faz?-- Leon Saudanha 16h15min de 12 de fevereiro de 2017 (UTC)

Ela fornece uma nova interface para filtrar as edições, na qual também podem ser usadas outras classificações fornecidas pelo ORES. Confira o vídeo da página de documentação (que copiei acima para facilitar) ou interaja com um protótipo. Helder 16h38min de 12 de fevereiro de 2017 (UTC)

Obrigado por linkar para o protótipo, Helder. Quero agora! Chico Venancio (discussão) 17h32min de 12 de fevereiro de 2017 (UTC)

agora entendi, obrigado por explicar Helder, sendo assim, Concordo em implantar a extensão, vai ficar bem melhor que as atuais mudanças recentes.-- Leon Saudanha 18h30min de 12 de fevereiro de 2017 (UTC)

Concordo, sem dúvidas. RadiX∞ 01h42min de 13 de fevereiro de 2017 (UTC)

Concordo. !Silent (discussão) 11h30min de 13 de fevereiro de 2017 (UTC)

Concordo. Helder 12h06min de 13 de fevereiro de 2017 (UTC)

Concordo Sou um fã do projeto ORES e acredito que essa extensão tem potencial para facilitar muitas atividades por aquiǃ Crang115 (discussão) 15h54min de 13 de fevereiro de 2017 (UTC)

Concordo Ativei recentemente o ORES e posso dizer que é uma mão na roda. Essa nova interface vai ajudar ainda mais. Oxe (discussão) 13h04min de 24 de fevereiro de 2017 (UTC)

---

Sorry to use English, Ajude a traduzir para a sua língua, por favor!

First, thank you very much for your interest concerning the new filters for recent pages! We will be very happy to work with you on improving that new improvement. :) Two communities will try that new Beta feature: Polish Wikipedia and Lusophone Wikipedia.

What will happen next? At the moment, ORES for Recent Changes is a Beta feature on your wiki. ORES for Recent Changes will be turned as a by-default feature: everyone will have it. It will be possible to opt-out that feature in your preferences. I'll give you more details when that step will be ready to go. You can follow that change on Phabricator.

Then, every user who has enabled the ORES Beta feature for Recent Changes will have the new filters. We are just changing the Beta improvement for Recent Changes. Basically, if you have opted-in for ORES for Recent Changes Beta feature, you will have nothing to do.

Those new filters will give you a very different experience on Recent Changes. You may be confused for your first steps, which is perfectly normal. I'll be around to answer your questions and gather feedback on that page. We are paying a particular attention to search and find bugs, but we may have not seen every cases. We expect you to help us to find all and every bugs! :)

I'll keep you posted concerning the schedule for the next steps by next week. In the mean time, feel free to ping me if you have any question, in the language you prefer.

All the best, Trizek (WMF) (discussão) 14h52min de 17 de fevereiro de 2017 (UTC)

Trizek (WMF) Thanks for explanation.-- Leon Saudanha 14h43min de 22 de fevereiro de 2017 (UTC)

Hello!

A quick update: the new filters would be deployed on March 21.

Best, Trizek (WMF) (discussão) 09h42min de 27 de fevereiro de 2017 (UTC)

Hello!

If you want to discover the new feature, we have created a quick tour page. Other pages are still under construction, but they will be finished before Marc 21. Translations are also very welcome. :)

Best, Trizek (WMF) (discussão) 15h03min de 1 de março de 2017 (UTC)

Dear Lusophone Wikipedia community,

Due to some technical issues, we prefer to be cautious and delay the deployment to March 28. We hope this is fine for you.

Thanks, Trizek (WMF) (discussão) 10h06min de 15 de março de 2017 (UTC)

I've just left a message on Esplanada/anúncios concerning the deployment. Trizek (WMF) (discussão) 12h10min de 24 de março de 2017 (UTC)

Jonas, Trizek, e demais pessoas envolvidas neste tópico, por favor, deem uma olhada nesta proposta semelhante. Cumprimentos, Armagedon2000 ^msg 02h17min de 30 de março de 2017 (UTC)

Feedback

Ver também: mw:Talk:Edit Review Improvements/New filters for edit review

Já estou usando a nova ferramenta e encontrando os primeiros vandalismos (pobres vândalos! Hehehe). Gostaria de aproveitar para perguntar uma questão bem noob, mas que tenho dúvida até hoje: nas mudanças recentes é possível no máximo visualizar as últimas 500 edições. Existe uma maneira de ampliar esse número? --Hume42 ✉ 17h04min de 28 de março de 2017 (UTC)

You have the "Mostrar as últimas 50 | 100 | 250 | 500 mudanças nos últimos 1 | 3 | 7 | 14 | 30 dias; Mostrar Wikidata" option, which is the same as on the previous Recent Changes page. I keep your feedback in mind anyway! Trizek (WMF) (discussão) 18h03min de 28 de março de 2017 (UTC)

Especial:Preferências#mw-prefsection-rc, podes alterar para número maiores que passa a funcionar. Chico Venancio (discussão) 01h34min de 29 de março de 2017 (UTC)

Hoje tive acesso à ferramenta e gostei. É possível salvar as configurações de filtros para recuperá-las mais rapidamente depois? Oxe (discussão) 17h30min de 28 de março de 2017 (UTC)

Também me perguntei a mesma coisa... --Hume42 ✉ 17h35min de 28 de março de 2017 (UTC)

Oxe & Hume42 - Yes: copy the URL and paste it where you want. :) Trizek (WMF) (discussão) 18h03min de 28 de março de 2017 (UTC)

@Trizek (WMF): Thanks! Oxe (discussão) 18h05min de 28 de março de 2017 (UTC)

Comentário Por enquanto não encontrei nenhum problema com essa nova ferramenta, no começo achei um pouco diferente do que a gente estava acostumado a trabalhar, mas fui me adaptando e agora estou gostando de usá-la, tem muitas opções de filtragem. --Pap@ Christus ^msg 01h27min de 6 de abril de 2017 (UTC)

[Ver]

Inclusão do código da predefinição tl na predefinição tl

Olá a todos da comunidade! Venho propor a inclusão do código da predefinição recém criada por mim a {{Info/topo/imagem}} no corpo do código da predefinição principal {{Info}}. Depois de um debate aqui na Wikipédia:Tire suas dúvidas#Qual a utilidade da predefinição Info/topo sobre a utilidade da predefinição {{Info/topo}}, onde obtive auxilio do Mr. Fulano que sugeriu-me a criação desta proposta. O caso é que hoje não havia praticamente uma utilidade muito prática do uso da referida {{Info/topo}}, pelo motivo da não possibilidade de se escolher outras imagens para usar como topo da metapredefinição principal {{Info}} sem que fosse necessária uma solicitação para a inclusão do caminho da imagem no Commons na página MediaWiki:Common.css, por este motivo pesquisei a base da {{Info/topo}} que foi criada com a as características contidas na Wikipédia em francês (fr:Projet:Infobox/V2), e após umas pesquisas deste projeto da Wikipédia francófona descobri que havia outra predefinição alternativa para a mesma função de inclusão de imagens no topo da {{Info}}. Então eu adaptei o código contido nesta fr:Modèle:Infobox/Titre avec icône, e após os debates em Wikipédia:Tire suas dúvidas, Wikipédia:Café dos programadores#Alternativa à predefinição Info/topo e Wikipédia:Pedidos/Proteção#Predefinição:Info/topo/imagem. Eu peço para a comunidade avaliar o meu trabalho e com base nos testes realizados pelo Mr. Fulano (Usuário:Mr. Fulano/Testes4) faça-se a inclusão. E com isso não terá mais a necessidade de se incluir parâmetros na página do MediaWiki:Common.css.

O código a ser incluído na predefinição {{Info}} seria na seção Título e subtítulo da seguinte maneira:

Usando a recém criada {{Info/topo/imagem}}

<!----- Título e subtítulo ------>
! colspan="2" class="{{{título-classe|topo padrao}}}" style="{{{título-estilo|text-align:center; background-color:#B0C4DE}}}" {{!}} <span class="{{{hCard|}}}">{{{título|{{{titulo|{{PAGENAME}}}}}}}}{{Info/topo/imagem|pictograma={{{pictograma}}}|tamanho-pictograma={{{tamanho-pictograma}}}|pictograma-ligação={{{pictograma-ligação}}}|pictograma-caption={{{pictograma-legenda}}}|opacidade={{{opacidade}}}|margem-superior={{{margem-superior}}}}}</span>

Ou o código contido na {{Info/topo/imagem}}

<!----- Título e subtítulo ------>
! colspan="2" class="{{{título-classe|topo padrao}}}" style="{{{título-estilo|text-align:center; background-color:#B0C4DE}}}" {{!}} <span class="{{{hCard|}}}">{{{título|{{{titulo|{{PAGENAME}}}}}}}}<div style="position: relative; float:right; margin-top:{{#if:{{{margem-superior|}}}|{{{margem-superior|}}}|-10px}}; margin-right:14px; height: 1%;">

 <div style="position: relative; margin: 0 -1em; padding: 0; background-color: transparent; border: 1px none #ddd; height: 1%;">
  <div style="position: relative; margin: 0 auto; width: auto; border: transparent; height: 1%;">
     <div style="position: relative; overflow: hidden;  height: auto;"><!-- tamanho da imagem principal -->
    <div style="position: relative; overflow: hidden; z-index: 1; margin: 0; opacity:{{#if:{{{opacidade|}}}|{{{opacidade|}}}|0.4}};">[[Ficheiro:{{#if:{{{pictograma|}}}|{{{pictograma|}}}|PD-icon-info.svg}}|{{#if:{{{tamanho-pictograma|}}}|{{{tamanho-pictograma|}}}px|33x33px}}|link={{#if:{{{pictograma-ligação|}}}||http://pt.wikipedia.org/wiki/File:{{#if:{{{pictograma|}}}|{{{pictograma|}}}|PD-icon-info.svg}}}}|{{#if:{{{pictograma-caption|}}}|{{{pictograma-caption}}}}}]]</div>
   </div>

   <div style="position: absolute; top: 0; width: 100%; height: 100%;">
    <div style="margin: 1em; font-size: 100%;">

    </div>

</div></span>

Agradeço a todos desde já. Rodrigo, Luz28 ^(MsG) 12h54min de 13 de fevereiro de 2017 (UTC).

Concordo com a implementação da predefinição {{Info/topo/imagem}} em {{Info}}, depreciando a {{Info/topo}}. Mr. Fulano! ^{🔔Fale Comigo📩} 16h14min de 13 de fevereiro de 2017 (UTC)

Concordo com a mudança por razões de eficiência, já que não será necessário carregar as imagens em páginas que nem mesmo as utilizam. Dito isso, creio que não devemos exagerar e criar topos para toda e cada predefinição (e subpredefinição) existente. - Épico (disc)/(contrib) 20h04min de 13 de fevereiro de 2017 (UTC)

Feito Implementei a predefinição. @Luz28: Podes criar os parâmetros na documentação? Mr. Fulano! ^{🔔Fale Comigo📩} 23h35min de 27 de fevereiro de 2017 (UTC)

Ok sem problemas providenciarei os parâmetros na documentação . Rodrigo, Luz28 ^(MsG) 13h41min de 28 de fevereiro de 2017 (UTC)

@Mr. Fulano: Feita a documentação e algumas correções para que o novo implemento funcione corretamente. Rodrigo, Luz28 ^(MsG) 14h44min de 28 de fevereiro de 2017 (UTC).

[Ver]

Unificar título de todas as páginas acerca de numerais

Ver também: Wikipédia:Temas recorrentes/Convenção de nomenclatura

Olá a todos!

A partir dessa discussão, levantou-se a questão sobre os títulos atribuídos a páginas que se referem a números. Não existe uma unificação para tais títulos, como por exemplo:

• 4294967295 - Apenas o número;
• 17 (número) - O número seguido da partícula "(número)";
• Um milhão, quinhentos e setenta mil - O número por extenso;

Escrever apenas o número pode causar confusões com relação a números que também representem outras coisas, por exemplo, ano. Já escrever o número por extenso, além de poder ser demasiado grande, é de difícil procura, já que usuários em geral não irão procurar os números por extenso, além de haver o fator agravante da variante linguística, que obrigaria a criar redirecionamentos, como em Dezenove - Dezanove. Assim, o mais sensato seria utilizar x (número), alternativa a qual proponho utilizar. Como esta unificação traria uma grande quantidade de moção de artigos, trago este tópico para apreciação da comunidade. ♪ Alberto79 ♪ ^{Msg-Contributions} 17h39min de 13 de fevereiro de 2017 (UTC)

Olá! Minhas considerações iniciais sobre o assunto:

1. Eu acho que é seguro que números escritos por extenso sejam redirecionados para suas formas numérica mais o sufixo "(número)", por exemplo, Um milhão, quinhentos e setenta mil → 1570000 (número);
2. Também imagino que seja mais fácil começar a se padronizar que todo numeral sozinho indique um ano e que se aponte para uma página de desambiguação quando necessário.

Saudações. Oxe (discussão) 18h10min de 13 de fevereiro de 2017 (UTC)

Concordo: também prefiro que haja padronização, seguindo o formato "x (número)" que é utilizado na maioria das wikis. Helder 18h18min de 13 de fevereiro de 2017 (UTC)

Apoio, padronização sempre é bem vinda. --Luk3^{🔔• 📖} 21h56min de 13 de fevereiro de 2017 (UTC)

Concordo Numeral sozinho -> sempre um ano; e os números com o sufixo (número).-- Darwin ^Ahoy! 22h36min de 13 de fevereiro de 2017 (UTC)

Dificilmente haverá um artigo para o ano 1570000, e de acordo com a convenção de nomenclatura deve ser sempre preferido um título mais simples se ele tiver disponível. Então, o artigo do número (ou porventura uma desambiguação) deve ser 1570000. Já quando houver artigo para o ano e para o número, concordo que o ano fique com o título mais simples. GoEThe (discussão) 08h02min de 14 de fevereiro de 2017 (UTC)

Sim, parece-me bem, sempre que haja ano, leva a desambiguação (número) no final, quando não houver, vai o numeral directo.-- Darwin ^Ahoy! 08h38min de 14 de fevereiro de 2017 (UTC)

Em prol da padronização, eu faria 1570000 → 1570000 (número). Cumprimentos. Oxe (discussão) 13h39min de 14 de fevereiro de 2017 (UTC)

Não seria de considerar a hipótese de representar o número com espaços a separar de mil em mil 1570000 → 1 570 000 (número) e eventualmente {{DEFAULTSORT:00000000000001570000}} com um número de dígitos suficientes para atingir o maior numero representado (20?). Talvez já alguém o tenha pensado e tenha razões para não usar este formato, mas, sem ter elaborado muito sobre os prós e contras deste formato não quis deixar de referir desde já o assunto antes que se tome uma decisão definitiva. --JotaCartas (discussão) 17h07min de 14 de fevereiro de 2017 (UTC)

JotaCartas Acho que não porque 1 570 000 é apenas, como você mesmo disse, uma forma de apresentação do número 1570000, que também poderia ser apresentado como 1.570.000 (no Brasil) ou 1,570,000 (nos EUA). Sobre o DEFAULTSORT, acho que não seria necessário, visto que isso foi resolvido recentemente[1][2]. Saudações. Oxe (discussão) 18h32min de 14 de fevereiro de 2017 (UTC)

Ok, já aprendi alguma coisa (tenho andado fora da WP.pt ha já algum tempo hehe). Quanto ao formato que proponho é verdade que só seria verdadeiramente útil para números com 6 até 10 dígitos (que serão presentemente uma meia dúzia na categoria), mas evitava ter que andar com o rato a contar os dígitos para poder verbalizar (ainda que mentalmente) e perceber qual a dimensão do numero. Para números mais pequenos (até 5 dígitos) é efectivamente desnecessário, e para números maiores (como 43252003274489856000) também não é muito útil pois não conseguiria converter mentalmente em texto ainda que tivesse os espaços (hehe). Quanto a ser uma representação, é um facto, mas o Livro de estilo recomenda ... ... repartidos em grupos de três algarismos, separados por espaços ... , mas aceito os seus argumentos,tanto mais que o "meu" formato só seria útil numa vintena de items num universo actual de mais de duzentos na categoria. Saudações. --JotaCartas (discussão) 19h31min de 14 de fevereiro de 2017 (UTC)

@JotaCartas: Será que você não estaria confundindo o número como nome do artigo e como o número é formatação dentro dele? Acho que dentro do artigo o número deve ser apresentado da forma que você sugeriu, mas o nome do artigo não deveria ser assim. Por exemplo, o artigo 4294967295, que no futuro deverá redirecionar para 4294967295 (número), apresenta o número 4294967295 como 4 294 967 295. Saudações. Oxe (discussão) 19h54min de 14 de fevereiro de 2017 (UTC)

Concordo preferencialmente com: Numeral sozinho -> sempre um ano; e os números com o sufixo (número).--JotaCartas (discussão) 02h03min de 15 de fevereiro de 2017 (UTC)

Comentário caso a proposta seja aprovada, seria uma boa pedir para a coordenação robótica um robô para fazer essas alterações, visto a grande quantidade de páginas que sofrerão alteração de nome? ♪ Alberto79 ♪ ^{Msg-Contributions} 05h13min de 16 de fevereiro de 2017 (UTC)

Concordo Por favor padronizem isso, eu ia começar manualmente pelo menos para os números até 100 mas é um trabalho de chinês que não conlui. Não vejo motivo para usar número por extenso exceto se é o nome de algo como livro, filme etc. Na wikien também há páginas de desambiguação para os números, talvez seja o caso para os números (número), (ano), (filme), (personagem) etc .― Diana ^m 03h15min de 17 de fevereiro de 2017 (UTC)

@Dianakc: Se houver mais de um significado para um número, cria-se uma desambiguação, sendo que números sozinhos seriam padronizados para indicarem anos. Por exemplo, 2000 para o ano 2000 da era comum; 2000 (número) para o número natural que vem depois de 1999 e antes de 2001; e 2000 (desambiguação) para a desambiguação, apontando para outros significados envolvendo 2000. Poder-se-ia até criar 2000 (ano) como um redirecionamento para 2000, se acharem muito necessário. Oxe (discussão) 03h39min de 17 de fevereiro de 2017 (UTC)

@Dianankc:, podemos citar como exemplo 300 (filme). O número 300 provavelmente precisaria de uma página de desambiguação. E não podemos esquecer que os anos AC estão representados como 300 a.C.. ♪ Alberto79 ♪ ^{Msg-Contributions} 17h24min de 19 de fevereiro de 2017 (UTC)

---

Proposta de consenso. Olá! Acho que a proposta atingiu o seguinte consenso para títulos de artigos:

Convenções de nomenclatura para números (I)

As regras de nomenclatura para artigos sobre números são:

Anos da Era Comum

• Numeral sozinho. Exemplo: 300 é o artigo sobre o ano 300 da Era Comum;

Números

• Numeral mais o sufixo "(número)". Exemplo: 300 (número) é o artigo sobre o número 300.
• Número por extenso redireciona para o artigo do número, exceto em caso de número muito grande onde o bom senso recomendar que não haja o redirecionamento. Exemplos: Trezentos deve redirecionar para 300 (número) assim como Um milhão, quinhentos e setenta mil deve redirecionar para 1570000 (número), porém Um trilhão (10⁹) e Googol (10¹⁰⁰) não devem ser redirecionamentos.

Outros significados

• Numeral mais o sufixo adequado. Exemplo: 300 (filme) é o artigo sobre o filme baseado no livro de Frank Miller.

Enquanto não houver conteúdo sobre um determinado ano, o artigo que seria sobre ele poderá ser usado como desambiguação ou redirecionamento. Exemplos: 10000 desambigua 10000 (número), 10,000 Maniacs e 10000 metros, enquanto que 4294967295 redireciona para 4294967295 (número) em favor da padronização dos artigos sobre números.

— Proposta para WP:NOME § Números

Alberto79, parabéns pela iniciativa!

Saudações. Oxe (discussão) 21h58min de 28 de fevereiro de 2017 (UTC)

Concordo --Usien6 23h48min de 28 de fevereiro de 2017 (UTC)

@Usien6: Formalizei melhor a proposta. Por favor, poderia reafirmar se concorda com essa reescrita da proposta? Obrigado. Oxe (discussão) 06h06min de 4 de março de 2017 (UTC)

Quer dizer que vocês vão renomear artigos como Um vigintilião, Cem milhões e Googolplex também? Quero ver só de onde tiraram que sempre os títulos utilizando algarismos são de mais fácil busca. Discordo dessa proposta. Melhor realmente é aproximar a WP:NOME do que o WP:LE instrui.

Livro de estilo: números, datas e quantias

• Num texto enciclopédico, deve-se evitar representar alguns números com seus respectivos algarismos. Por exemplo:
  • Não Errado: "o Titanic passou mais de 1 ano sendo equipado..." ou "Quando tinha 8 anos de idade sua família...".
  • Sim Adequado: "o Titanic passou mais de um ano sendo equipado..." ou "Quando tinha oito anos de idade sua família...".
• Esta regra é aplicada para os números cujas formas por extenso limitam-se a uma só palavra (de um, dois, três, doze, quinze, trinta, setenta, mil). Obviamente, por uma razão de clareza, para números como 25, 337 ou 2586 usa-se sua anotação em algarismos. Alguns manuais de redação ou estilo aconselham que os números a partir de 11 (inclusive) sejam escritos em algarismos, à exceção de cem e mil.
• Em números fracionários, use-se sempre a notação por extenso: "um terço do parlamento" e não "1/3 do parlamento". Nunca deve ser colocado o número zero antes de números inteiros.
• Em números ordinais, a forma recomendável é escrever um algarismo arábico seguido de ponto (sinal de abreviatura) e as letras “o” ou “a” sobrescritas (desinências de gênero: primeiro, primeira, décimo, décima), como nos exemplos: 1.º, 2.ª, 5.º, 20.º, 500.º, 230.º.^[1]

— WP:LDE/NQ

A padronização não é benéfica nem possível nesse caso. Agora a criação de redirecionamentos é sempre possível, uma vez que os títulos alternativos propostos são possíveis, mas não preferíveis. --Luan (discussão) 15h08min de 1 de março de 2017 (UTC)

@Luan: Bons exemplos de exceções possíveis, mas eles não invalidam a proposta. Obviamente que Um vigintilião e Googolplex podem não precisar de outros títulos, mas Cem milhões poderia tranquilamente se tornar 100000000 (número) e, consequentemente, o redirecionamento Cem milhões → 100000000 (número) seria feito. Ademais, o trecho do livro de estilo que você citou versa sobre a escrita dentro dos artigos, enquanto que a proposta é para os títulos. Oxe (discussão) 15h25min de 1 de março de 2017 (UTC)

Qual é o número mágico que a comunidade da Wikipédia lusófona vai inventar para dizer que 'com tantos zeros usa-se algarismos' e 'mais que esse tanto, usa-se o nome por extenso'? De toda forma, está demonstrado que a padronização total e completa inicialmente pretendida não é possível, nem desejável como falei. Considero 100000000 (número) difícil de escrever e complicado de contar os zeros ainda mais sem os separadores a cada três algarismos. E o que falei, @Oxe:, foi justamente aplicar a mesma regra que se aplica no corpo dos artigos nos seus títulos também. Ou seja, números cujas formas por extenso limitam-se a uma só palavra (sem contar termos como "milhões", "mil", "bilhões" e similares) assim terão seus artigos assim intitulados. Luan (discussão) 18h56min de 1 de março de 2017 (UTC)

@Luan: Nenhum número mágico, use o bom senso. A proposta não impede que os redirecionamentos Mil → 1000 (número) e Milhão → 1000000 (número) existam, portanto a informação estará mais acessível. Se você quiser criar um título com o resultado de 10^10^100 mais o sufixo "(número)" —se é que é viável tecnicamente— fique à vontade pois também cabe dentro da proposta, porém o bom senso recomenda que não o faça. Os números muito grandes são poucas exceções que não invalidam a regra geral. Para cada Googolplex que você citar, haverá dezenas de Cento e vinte e três e Mil e cinquenta e oito que dão propósito à proposta. Oxe (discussão) 19h15min de 1 de março de 2017 (UTC)

@Oxe: estamos falando em números, vamos contar então? Por favor, releia meu comentário imediatamente anterior e conte quantas palavras há em "Cento e vinte e três" ou em "Mil e cinquenta e oito" (sem contabilizar "mil", "milhão" e afins). Feito isso, perceberá que há mais de uma palavra, logo, tal como o LE recomenda para o corpo do texto, o título deve ser também 123 (número) e 1058 (número) (com a especificidade do termo desambiguador, que é necessário para evitar confusão com os anos). Por outro lado, Mil e Milhão, ou Dois mil e Seis milhões têm somente uma palavra só ou então uma palavra só mais aquelas que falei para não contabilizar; assim, tal como diz o LE para o corpo do texto, o título fica por extenso (com os numerais cardinais). Luan (discussão) 18h29min de 2 de março de 2017 (UTC)

@Luan: Tenho certeza que você entende a diferença entre o conteúdo de um artigo e o seu título, e também percebe que a proposta aqui é sobre títulos. Só para ficar claro, caso ainda não esteja, seriam criados os redirecionamentos para os números citados, a saber Mil → 1000 (número), Milhão → 1000000 (número), Dois mil → 2000 (número) e Seis milhões → 6000000 (número), portanto nenhum artigo seria apagado. Obrigado pelas suas considerações. Oxe (discussão) 18h42min de 2 de março de 2017 (UTC)

@Oxe: você entendeu menos ainda. Não sei como explicar mais que isso. Assim, aos demais com melhor compreensão, resta-me dizer que mantenho discordância sobre realizar renomeações do tipo Milhão → 1000000 (número), pois não ajudam, nem é possível a padronização total que utilizada de argumento na proposta. Luan (discussão) 18h49min de 2 de março de 2017 (UTC)

@Luan: Não há problema em você discordar, porque consenso não é unanimidade e há quinze dias que o consenso acerca da proposta tem se formado; eu apenas formalizei melhor o resultado para ficar mais fácil de implementá-lo. Seria ideal se a unanimidade fosse sempre atingida, mas paciência se você está se apegando a algo distinto do objeto da discussão e a raras exceções da proposta, sendo injustificadamente intransigente. Oxe (discussão) 18h59min de 2 de março de 2017 (UTC)

@Oxe: não estou gostando da sua tentativa de excluir minha argumentação falando de "quinze dias de consenso", "consenso não é unanimidade" e "intransigência" por "apego a raras exceções" numa fuga ao tema. Não lembro de ter visto prazo de duração do debate. Tive acesso há pouco à discussão, que, ao que tudo indica, ainda está aberta e nada foi decidido. E o que você chama de "raras exceções", tentando desqualificar inutilmente minha argumentação, são os primeiros 20 números incluindo o zero, são os primeiros 10 múltiplos de 10, são os primeiros 10 múltiplos de 100, são os primeiros 20 múltiplos de mil, são os primeiros 10 múltiplos de 10 mil, são os primeiros 10 múltiplos de 100 mil, etc. Dos 253 itens atuais da Categoria:Inteiros, só esses que listei representam cerca de um terço dessa quantidade. E ainda tem mais os que não listei. Luan (discussão) 19h44min de 2 de março de 2017 (UTC)

Que bom que você entendeu que não importa quantas vezes se escreve Concordo ou Discordo. Já é um avanço. Salvo melhor juízo, todos os casos que você citou não são em nada parecidos com Googolplex e Um vigintilião (ou seria Um vigintilhão no Brasil? mais um motivo para se padronizar pela proposta) que você citou inicialmente, porque suas representações no formato numeral mais sufixo "(número)" são adequadas e possíveis. Oxe (discussão) 19h54min de 2 de março de 2017 (UTC)

┌──────────────────────┘ Você está citando outro fato que nem de longe é um impedimento. Se fosse, existiriam duas Wikipédias em português. E não há. O artigo sobre aquele veículo rodoviário de transporte urbano coletivo público é intitulado Ônibus apesar das variações regionais existentes. E os casos são vários. Então, sem grande lamúrias por isso. Uma boa introdução soluciona qualquer dúvida. Abaixo, trago um texto de proposta para convencionar-se especificamente sobre os números.

Convenções de nomenclatura para números (II)

As regras de nomenclatura para artigos sobre números se aproximam das normas recomendadas pelo Livro de estilo para números, datas e quantias, escritos no corpo dos artigos.

• Os títulos formados por algarismos devem ser reservados para as datas relativas a anos da Era Comum, com exceção dos números formados por cinco algarismos ou mais (cujos anos correspondentes dificilmente terão artigo próprio).
• Nos títulos dos artigos sobre números, deve-se evitar representar alguns números com seus respectivos algarismos. Esta regra é aplicada para os números cujas formas por extenso limitam-se a até duas palavras (um, dois, três, doze, quinhentos, quinze mil, setenta bilhões, um trilhão, googolplex). Obviamente, por uma razão de clareza, para números como 25, 337 ou 2586 usa-se sua anotação em algarismos e o termo desambiguador "número" para diferenciar dos anos, quando necessário for. Por exemplo:
  • Sim Adequado: Um (numeral), 1 (ano), 123 (número) (numeral), 123 (ano), Mil (numeral), 1000 (ano), Cem milhões (numeral), 4294967295 (numeral), Googolplex (numeral).

— Proposta para WP:NOME § Números

Luan (discussão) 20h18min de 2 de março de 2017 (UTC)

Discordo dessa proposta porque é demasiadamente complexa, dificultando a padronização e causando confusão desnecessária ao leitor ao ver que o artigo sobre 100 é Cem mas o artigo sobre 101 é 101 (número) e não Cento e um. Qual vai ser título escolhido para 17: Dezassete ou Dezessete? E para 1 000 000 000: Bilhão, Um bilhão ou Mil milhões? E para 1 000 000 000 000: Bilião, Um bilião, Trilhão ou Um trilhão? São vários problemas na proposta e ela causa mais problemas do que os resolve. Oxe (discussão) 20h42min de 2 de março de 2017 (UTC)

O redirecionamento mais antigo resolve tal impasse. Simples. E repito, uma introdução minimamente adequada esclarece qualquer dúvida sobre as diferenças por causa das Escalas curta e longa, ou das variações linguísticas. E preciso lembrar que o título proposto não será 1 000 000 000, mas sim 1000000000 (número) que pouco dá para diferenciar visualmente de 1000000000000 (número), por exemplo. Também lembro que redirecionamentos também podem ser criados com tal formato "x (número)" nos casos em que for o título por extenso. Também lembro que a referida "padronização" completa é indesejável como já demonstrei. Logo, melhor seguir as regras gramaticais e de estilo também nos títulos. Luan (discussão) 18h24min de 3 de março de 2017 (UTC)

O argumento do redirecionamento vale no sentido oposto, isto é, de Cem para 100 (número). Diferentemente do caso de ônibus citado por você, a forma "x (número)" é universalmente aceita em todas as variantes da língua portuguesa, evitando-se qualquer atrito entre os falantes da última flor do lácio ou adição de quaisquer critérios para resolução de conflitos. Logo, a proposta do Alberto79 faz muito mais sentido por ser mais simples. Oxe (discussão) 18h31min de 3 de março de 2017 (UTC)

Concordo com a proposta, mas acredito que seja necessário que todos os numerais sejam escritos computando seus dígitos. Tornar adequados nomes como Cem pode abrir precedentes para que futuros artigos possam ser criados com nomes por extenso por desinformação. A proposta ainda precisa ser refinada antes de ser levada a votação. ♪ Alberto79 ♪ ^{Msg-Contributions} 04h50min de 4 de março de 2017 (UTC)

Comentário claro que artigos como Um vigintilhão e Googolplex não poderão ter seus nomes alterados, devido a seu tamanho exorbitante. Poderiámos adicionar uma exceção à regra para números muito grandes. Por exemplo, para 1 Googol seria adequado o nome por extenso e não 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ♪ Alberto79 ♪ ^{Msg-Contributions} 04h55min de 4 de março de 2017 (UTC)

@Alberto79: Com base no falado por Luan, já havia formalizado a exceção para números muito grandes. Por favor, leia a "Convenções de nomenclatura para números (I)", mais ou menos no meio da página, e depois me diga se era isso o que você tinha pensado. Saudações. Oxe (discussão) 05h02min de 4 de março de 2017 (UTC)

@Alberto79: já existe o redirecionamento 10000­000000­000000000­000000000­000000000000000000000000000000000­000­000000000000000000000000000­000000000 (para Googol). Não sei quem errou, não contei os zeros, nem tenho tal pretensão. E Tornar adequados nomes como Cem pode abrir precedentes para que futuros artigos possam ser criados com nomes por extenso por desinformação não se sustenta, porque com a regra estabelecida, esta tem de ser cumprida e uma renomeação resolve o problema do descumprimento. Sem falar que considerável parte dos números que poderiam ser criados já foram.

@Oxe: defina "números muito grandes", por favor. O próprio artigo Números muito grandes apresenta várias definições segundo variadas perspectivas. Nesse mesmo artigo está escrito: Escrevendo-se 10⁹ em vez de nove zeros poupa os leitores do esforço e do risco de contar uma longa série de zeros para ver o quão grande é o número. É por isso que prefiro o título Cem milhões para o numeral cardinal do que ficar contando zeros pra saber que número é.

E caso não tenha ficado claro ainda, claro que prefiro o título 1570000 a Um milhão, quinhentos e setenta mil. Luan (discussão) 12h25min de 4 de março de 2017 (UTC)

@Luan: Os artigos Números muito grandes e Categoria:Inteiros muito grandes foram escritos em 2010 e talvez precisem de revisão e atualização. O que for consenso na comunidade matemática será usado, não vamos reinventar a roda. Saudações Oxe (discussão) 13h26min de 4 de março de 2017 (UTC)

@Oxe: agradeço se puder ser mais específico informar precisamente qual é esse "consenso na comunidade matemática" em que se baseia a tua proposta. Luan (discussão) 13h44min de 4 de março de 2017 (UTC)

@Luan: Precisamente o que a literatura apontar. Oxe (discussão) 16h17min de 4 de março de 2017 (UTC)

@Luan: Estava lendo sobre números grandes (números muito grandes foi um provável erro de tradução de large numbers e vou ajustar a proposta assim que confirmar isso) e fiquei com a impressão que um milhão (10⁶) já poderia ser considerado um número grande. Tenho quase certeza que um bilhão (10⁹) é. Isso ajudaria na sua concordância da proposta? Saudações. Oxe (discussão) 01h39min de 5 de março de 2017 (UTC)

@Luan e Oxe: a definição de "número muito grande" é extremamente vaga na comunidade matemática. Não lembro de ter visto nenhum artigo científico que define um critério objetivo para avaliar se um número é muito grande ou não. Sabemos que, pelo menos em meio científico, números da ordem de giga ou tera. Mas a escrita de números dessa grandeza pode ser demasiado confusa. Com $10^{1}2$, já temos 1000000000000, que a primeira vista pode confundir o leitor (para diferenciar por exemplo de 100000000000. ♪ Alberto79 ♪ ^{Msg-Contributions} 18h59min de 5 de março de 2017 (UTC)

Viva, Alberto79! É exatamente isso que queria que percebessem. Há casos em que usar só os algarismo complica a vida do leitor e do editor. E não há um consenso sobre o que seriam esses "números muito grandes", isso porque depende da amostra para se estabelecer a comparação. Luan (discussão) 18h14min de 7 de março de 2017 (UTC)

┌─────────────────┘ @Alberto79 e Luan: Enquanto não se discute com maior empreendimento a partir de quanto pode-se considerar que um número é grande, sugiro que definamos, temporariamente, que um milhão é o primeiro número natural grande, por uma questão histórico–etimológica. Podemos embasar essa definição por Davis, que cita a invenção da palavra milhão no século XIII (em uso há cerca de mil anos), enquanto que bilhão é mais recente, do século XVII (em uso há quase quinhentos anos e com aplicação consolidada na ciência e economia a partir deste século pelo menos); Bible Hub (seção Number and Arithmetic), que cita cita os maiores números grandes e todos são iguais ou maiores do que um milhão; e também porque milhão é a primeira das palavras que significam números grandes terminadas em -lhão (milhão, bilhão, trilhão, vigintilião, centilhão). Se a definição for modificada no futuro, para mais ou para menos, ajustaremos o que for preciso. O Alberto79 descobriu como exibir corretamente o título "100 000 (número)" para o artigo 100000 (número), que vai ajudar bastante nos artigos. Se você e Luan se pronunciarem favoravelmente e ninguém mais recusar a proposta, imagino que poderíamos concluir consenso sobre a proposta "Convenções de nomenclatura para números (I)". Saudações. Oxe (discussão) 18h22min de 7 de março de 2017 (UTC)

Referências

@Oxe: que bom que propôs especificamente uma definição para os números muito grandes! Concordo em colocá-los como um milhão ($10^{6}$) para cima. Entretanto, o artigo Um milhão, quinhentos e setenta mil pela proposta "Convenções de nomenclatura para números (I)" continuaria assim titulado, uma vez que ele é maior que 1 milhão. E manter o título "4294967295 (número)", ainda que "4294967295" esteja disponível, contraria WP:NOME § Seja preciso e claro (por falta de simplicidade na precisão) e também WP:DESAMBIG § Convenções (Quando o uso de parênteses pode ser evitado de uma maneira simples, prefere-se evitá-lo.), como GoEThe já bem lembrou em sua primeira mensagem nesta proposta. Adicionalmente, lembro que a exibição do título pode ser mudada com {{Título errado}}, mas o problema no estabelecimento da ligação perduraria. Luan (discussão) 19h06min de 7 de março de 2017 (UTC)

@Luan: A palavra de ordem é bom senso. Alterei novamente a proposta para contemplar mais uma reclamação sua, entretanto de nada adianta eu continuar modificando-a e ceder se você não estiver disposto a fazer o mesmo, como sua intransigência tem demonstrado. Não havia real necessidade de se definir agora o que seria um número muito grande para que esta proposta fosse aprovada porque essa discussão pode perfeitamente ficar para depois. Porém a fiz em prol de se tentar avançar em direção ao consenso, apesar d'eu, pessoalmente, considerar que seria a partir de um bilhão, mas não me importo se for definido como um milhão (número com sete ou mais dígitos) e com isso chegarmos a um bom termo. Agradeço e aceito sugestões que refinem e melhorem a escrita de "Convenções de nomenclatura para números (I)", mas a forma da proposta já está clara e definida. Oxe (discussão) 19h35min de 7 de março de 2017 (UTC)

┌────┘ @Oxe: Meus comentários são para aprimorar a proposta na medida em que eu vejo os furos, as falhas existentes. Não vejo a utilidade de uma aprovação rápida de uma regra falha, com lacunas, imprecisa. Pra dar brechas para ela não ser cumprida? Melhor não. E acho que não percebeu que cedi nos casos como 300 ser 300 (número) e não Trezentos. Creio que o texto abaixo é bastante abrangente, claro e preciso, não deixando espaço para brechas ao tratar de todas as situações aqui levantadas.

Convenções de nomenclatura para números (III)

As convenções de nomenclatura para artigos sobre números são:

• Anos da Era Comum: artigos sobre anos da Era Comum têm preferência para usar títulos somente compostos por algarismos indo-arábicos. Portanto, 300 trata do ano 300 da Era Comum, e não sobre o numeral cardinal 300 (trezentos).
• Numerais cardinais: artigos sobre numerais cardinais, com duas exceções, devem ser intitulados tal como "300 (número)" — que trata do número 300. Mas tais regras não excluem a possibilidade de criação de redirecionamentos com outros termos possíveis.
  • A primeira exceção para se utilizar o termo desambiguador "(número)" no título se refere aos números muito grandes. Para os números de sete algarismos ou mais (isto é, igual ou superiores a $10^{6}$), quando o nome por extenso for escrito com até duas palavras (inclusive), constitui-se uma exceção à regra anterior. Portanto, o título deve ser "Um trilhão" (para o artigo sobre o numeral cardinal $10^{9}$) e "Googol" (para o artigo sobre o numeral cardinal 10¹⁰⁰), por exemplo.
  • A segunda exceção está para quando não há o artigo do ano correspondente. Por razões de simplicidade e precisão, diante da disponibilidade do título, o uso do termo desambiguador é desnecessário. Portanto, por exemplo, o título deve ser "1570000" e "4294967295" — enquanto que "Um milhão, quinhentos e setenta mil" e "4294967295 (número)" são títulos em desacordo com esta convenção, mas são redirecionamentos possíveis e de criação recomendada.
• Outros significados: nos demais artigos em que o número apresente outros significados, aplicam-se as convenções já vigentes a fim da desambiguação. Assim, o título "300 (filme)" é para o artigo sobre o filme baseado no livro de Frank Miller.

— Proposta para WP:NOME § Números

Aguardo os comentários decorrentes. --Luan (discussão) 16h23min de 8 de março de 2017 (UTC)

@Luan: Você tem razão que seus comentários melhoraram a proposta I, eu, em nome da comunidade, acho que posso lhe agradecer por isso. Sobre a proposta III, penso que ela seja praticamente igual a proposta I, porém está escrita de forma mais verbosa e menos precisa e clara, ao contrário de sua intenção. A única discordância entre as propostas que vejo é sobre artigos para números como 1570000, que você prefere que seja 1570000, enquanto que eu proponho que seja 1570000 (número) e 1570000 redirecione àquele por uma questão de padronização. A forma 1570000 (número) é precisa e clara, pois não há ambiguidade se o título é sobre outra coisa além do número 1570000. Se fosse sem o sufixo, sendo todos os numerais sem sufixo designando anos, o leitor poderia pensar que é sobre algum ano muito distante em particular . Em outro momento você citou as convenções de desambiguação para evitar-se o uso do sufixo "(número)" com o argumento de simplicidade, mas a frase imediatamente antes a que você citou dá suporte a proposta de usá-los ("Existem exceções a estas regras") e existe um bom motivo para a proposta I ser uma exceção: padronização, pois todo número que o bom senso recomendar escrever na forma numeral mais o sufixo "(número)" será escrito assim. Usando os mesmos argumentos de precisão e simplicidade, Processo de impeachment de Fernando Collor e Processo de impeachment de Dilma Rousseff deveriam ser intitulados Impeachment de Collor e Impeachment de Dilma, mas os títulos atuais estão corretos e não devem ser alterados.

Sendo pragmático, fui olhar os artigos categorizados como inteiros para saber quantos artigos estariam causando a divergência. Percebi que você está discordando por causa de quatro números:

• 1 570 000, que mudaria de Um milhão, quinhentos e setenta mil para 1570000 (número) e teria os redirecionamentos 1570000 e Um milhão, quinhentos e setenta mil;
• 4 294 967 295, que mudaria de 4294967295 para 4294967295 (número) e teria o redirecionamento 4294967295;
• 18 446 744 073 709 552 000, que tem 18446744073709551615 redirecionando Sessa ibn Daher e teríamos 18446744073709551615 (número) também redirecionando para Sessa ibn Daher, porque não existe artigo sobre o número;
• 43 252 003 274 489 860 000, que tem 43252003274489856000 redirecionando para Cubo de Rubik e teríamos 43252003274489856000 (número) também redirecionando para Cubo de Rubik, pelo mesmo motivo anterior.

Ou seja, salvo melhor juízo, no fim das contas a discordância no momento é somente por causa de dois artigos. Cordialmente. Oxe (discussão) 17h03min de 8 de março de 2017 (UTC)

---

@He7d3r, Luk3, Darwinius, GoEThe, JotaCartas, Dianakc e Usien6: Olá! Quando vocês opinaram há alguns dias, parecia que havia um consenso, mas depois Luan tem oferecido oposição à proposta. Se possível, gostaria que vocês pudessem avaliar as propostas e argumentos que estão sendo postos:

• Convenções de nomenclatura para números (I), proposta por Alberto79 e formalizada assim por mim;
• Convenções de nomenclatura para números (II), proposta por Luan.

Agradeço antecipadamente. Oxe (discussão) 19h39min de 7 de março de 2017 (UTC)

Prefiro que o artigo sobre o número $10^{9}$ seja chamado de 1000000000, em vez de impor uma escolha entre "um bilhão" e "mil milhões" que o tornará ambíguo (à primeira vista), confundindo leitores de um dos países que não utilizem a escala (curta/longa) preferida para os títulos. O título em notação decimal não sofre deste problema, então deixaria mais claro do que o artigo deve falar. Analogamente, um título como "1000000000000" indica que o artigo falará sobre o número $10^{1}2$, enquanto que o nome "um trilhão" deixaria o leitor em dúvida se o artigo é sobre o $10^{1}2$ (chamado de "um trilhão" na escala curta) ou sobre o $10^{1}8$ (chamado de "um trilião" na escala longa). Helder 12h11min de 9 de março de 2017 (UTC)

[Ver]

Código de conduta para usuários com permissões avançadas de software ou editores experientes

Com o propósito de tratar apropriadamente os problemas que temos enfrentado há vários meses, elaborei a seguinte proposta, denominada: "Código de conduta para usuários com permissões avançadas de software ou editores experientes", especialmente voltada às ocorrências mais graves e sem solução prevista pelas políticas em vigor:

São considerados usuários com permissões avançadas aqueles incluídos nos seguintes grupos locais: eliminador, editor de interface, administrador, burocrata, checkuser e oversighter.

A presente política estabelece um código de conduta voltado a esses usuários, bem como a editores de reconhecida experiência na Wikipédia, com pelo menos um ano de registro e 2.000 edições no domínio principal. A quebra desse código de conduta pode resultar na remoção dos usuários do(s) respectivo(s) grupo(s), além de suscitar outras ações disciplinares cabíveis, descritas na última seção.

Segue, abaixo, a relação das violações mais graves que merecem atenção especial da comunidade, e que não são abrangidas por outras políticas.

Violações previstas

Guerra administrativa

Provocar um guerra administrativa, ao desfazer a reversão de outro usuário com estatuto equivalente ou superior, sem razoabilidade, esquivando-se ao diálogo, ou claramente em confronto com as políticas e recomendações pertinentes ao tema.

Assédio contumaz

Envidar esforços para descredibilizar, sem comprovação e de modo sistemático, as opiniões de determinado usuário, posicionando-se sempre no limiar das normas de conduta (ou excedendo-as) ao fazê-lo, em ação persecutória.

A interpretação distorcida das políticas e recomendações, em detrimento do "espírito da lei", como instrumento para assediar colaboradores, mesmo que de maneira subliminar, pode ser ser tomada como um agravante para o caso, além de uma falha ética grave a ser apurada.

Incorporação de problemas externos à Wikipédia

Trazer conflitos e problemas externos ao site para o âmago da Wikipédia, provocando a deterioração da qualidade das discussões e do ambiente de trabalho colaborativo.

Usuários experientes ou com ferramentas administrativas devem fazer a sua parte para amainar as animosidades, e não agregar novos conflitos ao meio e fomentar a crise.

Canvassing (solicitação indevida)

Utilizar canais privados ou externos à Wikipédia para recrutar editores e mobilizá-los sub-repticiamente, visando influenciar o resultado de votações, discussões ou propostas de seu interesse pessoal, seja em próprio benefício ou de terceiros.

Podem ser aceitos como provas os registros da comunicação privada, tais como e-mails ou histórico da conversação em comunicadores instantâneos, desde que não publicizados na Wikipédia:

• Apenas para a comprovação de autenticidade, os registros poderão ser encaminhados aos usuários com permissão para acessar informações privadas, como, por exemplo, os verificadores ou stewards (na ausência dos primeiros).
• A validação da denúncia estará sujeita à análise das informações recebidas, levando-se em consideração o contexto da ocorrência e os fatos relativos aos envolvidos.

A comunidade também poderá tomar como prova uma denúncia pública (on-wiki) de tentativa de aliciamento, na ocasião em que o suposto aliciador providencialmente não se manifesta, ou não é capaz de refutar as acusações.

• É mister enfatizar, mais uma vez, que dados privados não podem ser transcritos nas páginas do site.

Por outro lado, uma falsa denúncia, engendrada de má-fé, será igualmente considerada uma violação desta política, estando o seu autor sujeito às mesmas sanções.

As medidas gerais previstas no início da próxima seção deverão incidir sobre o autor do aliciamento, e não sobre os aliciados - a menos que também estejam envolvidos por via direta no recrutamento de outros editores.

Publicação de dados privados nas páginas da Wikipédia

Inserir, em qualquer página da Wikipédia, informações privadas que não tenham sido tornadas públicas pelo próprio indivíduo, nem estejam disponíveis em páginas de acesso irrestrito, com ou sem o uso de ferramentas administrativas.

Medidas disciplinares

Os usuários que incorrerem em quaisquer das violações descritas pela presente política estarão sujeitos tanto a bloqueio quanto a remoção de todos os seus estatutos. Essas decisões deverão ser tomadas a contento através de uma discussão de bloqueio, e por meio dos pedidos para remoção dos estatutos.

No que tange às solicitações indevidas, os votos do(s) aliciador(es) e do(s) aliciado(s) deverão ser anulados de chofre no contexto de uma votação, se confirmada a alegação. Uma anotação também poderá ser providenciada nas páginas de discussão e tentativas de consenso. O aliciador também ficará impedido de participar de votações e decisões na Wikipédia pelo período de seis meses, a contar da ciência do fato pela comunidade.

A inclusão de informações privadas nas páginas do site poderá ser punida independentemente de uma discussão prévia de bloqueio, embora não exclua a possibilidade de recurso ao processo.

Essas medidas são direcionadas principalmente aos usuários com permissões avançadas de software ou editores experientes, em virtude de as violações imbuírem-se de maior gravidade ao serem praticadas por ambos. No entanto, também podem ser estendidas aos demais membros da comunidade, pois a manutenção de um ambiente colaborativo saudável e harmônico é responsabilidade de todos os wikipedistas.

A proposta, se aprovada como política oficial, deverá ser incluída nas seguintes páginas, nos critérios para remoção (ou não-atribuição) do estatuto: Wikipédia:Política de administradores, Wikipédia:Política de burocratas, Wikipédia:Política de eliminadores, Wikipédia:Política de editores de interface, Wikipédia:CheckUser e Wikipédia:Oversight.

Também deverá ser incluída à Política de bloqueio, em cláusula própria, com tempo máximo de bloqueio indeterminado (os bloqueios são aplicados através de uma discussão de bloqueio, conforme proposta).

Atenciosamente, RadiX∞ 10h49min de 16 de fevereiro de 2017 (UTC)

Concordo com a proposta. Só não gostei muito da subjetividade que ficou em "A presente política estabelece um código de conduta voltado a esses usuários, bem como a editores de reconhecida experiência na Wikipédia" e em "No entanto, também podem ser estendidas aos demais membros da comunidade". Preferiria que se restringisse somente aos grupos citados na política, afim de evitar possíveis problemas decorrentes dessa subjetividade. Todavia, se mantiverem o texto do jeito que está eu não me oporei. !Silent (discussão) 11h47min de 16 de fevereiro de 2017 (UTC)

@!Silent: Obrigado por participar. Poderíamos substituir o grifo por um critério objetivo, como usuários com número determinado de edições e/ou tempo de registro. Por exemplo: 2.000 edições no domínio principal e um ano de registro (critério para pedidos de administração). RadiX∞ 11h51min de 16 de fevereiro de 2017 (UTC)

@RadiX Ficaria melhor, mais objetivo e sem eventuais problemas sobre o que considerar como "editores de reconhecida experiência na Wikipédia". !Silent (discussão) 11h55min de 16 de fevereiro de 2017 (UTC)

Feito. RadiX∞ 12h13min de 16 de fevereiro de 2017 (UTC)

Concordo, mas infelizmente penso que será muito difícil aprovar uma regra assim sem uma discussão detalhada sobre cada ponto. Este texto está misturando problemas distintos (todas relacionados a conduta) que já tiveram um grande histórico de discussão (como a solicitação). Para a devida aprovação, sugiro que se separe seções de discussão para cada "trecho" e chegamos a consensos individuais sobre a redação. Da forma que está a oposição a um dos temas citados pode comprometer toda a discussão. Chico Venancio (discussão) 12h07min de 16 de fevereiro de 2017 (UTC)

@Chicocvenancio: Acredito também que será bastante difícil alguém se opor a alguns dos pontos, defender uma imoralidade como solicitação ou assédio, ou mesmo a publicação de dados privados. Em todo o caso, vamos seguir com a discussão, e fazer os ajustes necessários que forem propostos. Obrigado! RadiX∞ 12h13min de 16 de fevereiro de 2017 (UTC)

Não tenho tanta certeza que essa comunidade se modificou tanto. Já tivemos ampla discussão sobre solicitação e uma votação falhou. Chico Venancio (discussão) 12h20min de 16 de fevereiro de 2017 (UTC)

Como o Chococvenancio, julgo problemático tentar aprovar um rol de coisas, que inclui items que foram discutidos por diversas vezes como solicitação indevida e evidências offwiki, sem consenso. Como digo há anos, a página WP:NC precisa de reforma. Apenas isso resolveria muitos problemas. GoEThe (discussão) 12h21min de 16 de fevereiro de 2017 (UTC)

(ce) Inclusive o ano passado propus que WP:Civilidade passasse a recomendação, quase sem participação. GoEThe (discussão) 12h25min de 16 de fevereiro de 2017 (UTC)

Acho que isto não deveria impedir o avanço da proposta, nem que seja necessário aprovar cada um dos itens em separado. Vamos olhar para frente, e não para o passado. Muitas propostas falharam pois tinham redação falha, não tiveram divulgação adequada, ou eram complexas demais, com textos extensos demais etc. Esta proposta é simples e objetiva, e vai direto ao ponto, sem enrolação. RadiX∞ 12h28min de 16 de fevereiro de 2017 (UTC)

Concordo plenamente. Não apenas pela minha experiência na situação (tanto aqui, quando eu consegui fazer o Efeld ser banido e ser alvo de uma conturbada DB em 2011, quanto na Wikia, onde vivenciei diversos conflitos ideológicos por decisão de regras ou desnomeações) serve pra evitar novas briguinhas, coações como no Esquema Quintinense e será um balde de água fria em usuários com temperamentos mais precipitados cujas discussões não acrescentam em nada a uma enciclopédia. A maioria desses conflitos que estão acontecendo hoje partiram de erros primários de editores experientes, que poderiam ter evitado tudo isso com o mínimo de bom senso. Mas ao invés de fazerem o procedimento correto (consenso), trouxeram conflitos externos para cá e se alfinetaram por meio de DBs, PBs e não duvido nada que o próximo passo será a criação de diversos pedidos de desnomeação em série. É tudo questão de bom senso. Essa regulamentação serve para evitar novos efeitos dominó assim como o que estamos vendo, uma pena que tenhamos que fazer isso para controlar esse tipo de situação, e uma pena que isso tudo tenha sido gerado por editores experientes e com ótima reputação na Wikipédia. Armagedon2000 ^msg 12h23min de 16 de fevereiro de 2017 (UTC)

Concordo com a proposta no geral, e acho útil a divisão em partes tanto para o consenso, como para uma eventual votação, como proposto pelo Chico e pelo Goethe. Assim, só irá a votação aquilo que não se puder resolver por consenso nesta discussão Também concordo com a alteração sugerida pelo !Silent, naquele caso que ele apontou parece-me que havia realmente vantagem em se ser objectivo, e não deixar um conceito vago de "editor experiente" no ar.-- Darwin ^Ahoy! 12h57min de 16 de fevereiro de 2017 (UTC)

Discordo Não percebi o propósito da proposta. Qual a lógica de existir um "código de conduta" específico para editores com estatutos ou editores muito experientes? As normas de conduta não são universais e aplicáveis a todos os editores? Uma coisa é ser mais tolerante e compreensivo com os novatos. Outra é ter regras de conduta diferentes conforme a antiguidade. Isso não existe em lado nenhum. De resto, a proposta apenas repete algumas banalidades de regras universais já existentes, com a diferença de as tornar ainda mais subjetivas e sujeitas a interpretações distorcidas. A grande novidade parece ser uma tentativa subtil da proibição de solicitação, o que já foi sucessivamente rejeitado pela comunidade. No entanto, o texto proposto é de tal forma amplo, vago e subjetivo que praticamente qualquer contacto entre dois editores pode ser interpretado e punido como "solicitação" e com bloqueio até seis meses. Isto é um absurdo completo.

Isto não é nenhum "código de conduta". Esse título é apenas um branqueamento da realidade para que as pessoas sejam mais receptivas a aprovar arbitrariedades por associação com coisas positivas. Na realidade, o texto é um conjunto de afirmações vagas e obtusas que abrem o campo a bloqueios totalmente arbitrários e subjetivos. Está escrita de tal forma que qualquer coisa pode ser interpretada por meia dúzia de pessoas como "violação de normas de conduta". Quintal ✁ 13h32min de 16 de fevereiro de 2017 (UTC)

Discordo também não vejo motivo para criar uma regulamentação diferenciada. isso começa a criar uma diferenciação indesejável entre os usuários, e daqui a pouco as miudezas se multiplicam. reconheço a boa intenção da proposta, mas para mim isso apenas vai aumentar a burocracia e criar confusão. as normas de conduta são para todos. Tetraktys (discussão) 14h17min de 16 de fevereiro de 2017 (UTC)

Discordo da existência de regras diferentes para qualquer grupo de editores. No mais, incluir, nesta proposta, a proibição de solicitações é um tanto quanto polêmico, no mínimo. A comunidade já debateu este assunto e sempre chegou a conclusão de que é difícil provar essas ocorrências, bem como punir adequadamente. Segundo, discordo fortemente de se encaminhar a stewards problemas internos da Wikipédia em Português, independente de se ter ou não verificadores locais. Os stewards, os quais a maioria não possui conhecimento em português, mais atrapalhariam do que ajudariam. Enfim, essa proposta não atacaria ou sequer inibiria os diversos grupos externos que fazem ações coordenadas por um simples motivo: quem faz parte destes grupos mantém-se em silêncio, sempre. Punir quem tenta combatê-los seria injusto. Érico (fale) 15h14min de 16 de fevereiro de 2017 (UTC)

Comentário Esta parte é particularmente grotesca: Citação: A comunidade também poderá tomar como prova uma denúncia pública (on-wiki) de tentativa de aliciamento, na ocasião em que o suposto aliciador providencialmente não se manifesta, ou não é capaz de refutar as acusações. Dito por outras palavras: qualquer um pode inventar que foi solicitado e depois a vítima é que tem que "provar" que não solicitou, caso contrário é bloqueada seis meses (!). Como é que se prova que uma coisa não aconteceu? Espetacular inversão dos mais básicos conceitos de direito e justiça. Estas "regras" parecem copiadas das normas de conduta da Coreia do Norte. Quintal ✁ 15h30min de 16 de fevereiro de 2017 (UTC)

1. Argumentar que a comunidade debateu extensivamente o tema e o refutou não é verídico. A única discussão expressiva ocorreu há cinco anos, com a proposição de um texto extenso, inespecífico, e numa época em que não tínhamos os problemas atuais. Cinco anos. É plenamente concebível reavaliar os problemas e ajustar a documentação após tamanho lapso temporal. A comunidade de hoje não é mais a mesma que ali estava representada; os desafios e as perspectivas são outros.
2. Um código de conduta mais rígido a editores detentores de estatutos advém da responsabilidade inerente a essas funções, e das consequências dos atos praticados por quem os detém. Um novato que ainda está conhecendo as regras não pode ser cobrado na mesma medida que aqueles que não só as conhecem, mas devem zelar pelo seu cumprimento!
3. A política será discutida e votada (se necessário) em tópicos, razão pela qual a proposta foi fatiada em cinco itens principais - para que discordâncias pontuais com uma norma não interfiram em outra.
4. O ônus da prova sobre a solicitação não está invertido! Isto não procede. Primeiro, os verificadores precisariam avaliar se as provas são verdadeiras. Segundo, se o material apresentado for verdadeiro, a comunidade deverá decidir, através de um pedido de remoção ou discussão de bloqueio, se realmente a denúncia pode ser rotulada como canvassing. Só então, com um resultado conclusivo, o aliciador poderia ser removido dos seus grupos de usuário e impedido de participar de discussões e votações pelo período de seis meses. Terceiro: se a denúncia for considerada falsa, quem sofrerá as consequências previstas é o acusador.
5. Todos os pontos da proposta podem ser ajustados e aprimorados de acordo com as sugestões recebidas, e críticas construtivas. RadiX∞ 16h14min de 16 de fevereiro de 2017 (UTC)

A votação sobre solicitação foi precedida por várias discussões. Mesmo que essa tenha sido a última votação, de lá para cá mudou alguma coisa? As vantagens e desvantagens apontadas nessa data são exatamente as mesmas que agora. A comunidade rejeitou por ser impossível controlar solicitação offwiki, o que só beneficiaria grupos ocultos. O que mudou? Nada. Pelo contrário, agora a solicitação até é institucionalizada com o uso do mass message para as eleições.

Todos os pontos são escritos de forma vaga e permitem os mais diversos abusos de interpretação, passando a ser possível bloquear por praticamente tudo. Afirmar que é "possível fatiar a discussão" não quer dizer rigorosamente nada. Quintal ✁ 16h40min de 16 de fevereiro de 2017 (UTC)

a necessidade de sermos tolerantes com os novatos já está prevista em nossas recomendações, vide Wikipédia:Não morda os novatos e Wikipédia:Presumir a boa-fé, e está implícita em Wikipédia:Civilidade ("Esta política descreve os padrões de comportamento esperado de usuários quando interagem, e modos apropriados de lidar com problemas que possam surgir"), Wikipédia:Subversão do sistema ("Em cada caso, a vontade clara e o conhecimento das próprias ações são importantes. O mau uso das políticas, recomendações ou práticas, se baseados num erro genuíno, não constituem subversão do sistema"), Wikipédia:Comportamento desestabilizador ("Um usuário poderá ter ou não ter conhecimento das regras que regem a Wikipedia. Se não o tiver, há sempre que tentar fazer ver a esse usuário porque o seu comportamento é censurável") e em outras recomendações e ensaios. por que seria necessário nos alongarmos sobre isso deixando a situação mais complexa e não mais clara e simples? sobre o canvassing, penso que é inútil pretendermos qualquer regulação efetiva. em casos de haver debates importantes, não vejo mal nenhum em chamar pessoas para participar, e como o Quintal lembrou, hoje isso está institucionalizado, mas nos casos em que há intenção disruptiva, muito dificilmente os envolvidos dariam as caras a tapa espontaneamente. como se poderia provar qualquer coisa? Tetraktys (discussão) 09h09min de 17 de fevereiro de 2017 (UTC)

@Antero de Quintal: Não distorça as coisas. O envio de mensagens em massa só por si não é nem nunca foi solicitação. Solicitação só ocorre quando os destinatários dessas mensagens são pré-escolhidos de forma a viciar o resultado da votação ou debate, e é disso que se está a falar aqui.-- Darwin ^Ahoy! 12h05min de 17 de fevereiro de 2017 (UTC)

Solicitação é solicitar a participação, que é o que as mensagens em massa fazem. O que está a descrever é troca de favores. Já se chegou à conclusão que isso é impossível de controlar, ainda para mais com o facebook e outras redes sociais. Quintal ✁ 14h56min de 17 de fevereiro de 2017 (UTC)

A proposta é sobre "Canvassing (solicitação indevida)". Está lá, a negrito. E não está em causa se é fácil ou não controlar isso, está em causa que é perfeitamente possível denunciar essa situação, bastando que quem é solicitado ou tem conhecimento e prova dessas solicitações, faça a denúncia, tal qual está explícito naquele texto. Você não concorda que isso é possível?-- Darwin ^Ahoy! 15h47min de 17 de fevereiro de 2017 (UTC)

Não, não acho que seja minimamente possível controlar todas as trocas de favores que são feitas às escondidas no facebook ou por email e a comunidade também não achou. Por isso é que rejeitou a proposta. Usar punições estapafúrdias (seis meses?) em um ou outro caso, enquanto a esmagadora maioria dos casos fica impune e nem sequer vem a público não é nenhuma "justiça". É apenas retaliação e criação de uma injustiça grotesca. O problema das trocas de favores resolve-se combatendo a raiz do problema: o excesso de recurso às votações na pt.wiki. As solicitações por via do mass message também garantem que eventuais trocas de favores e concluios offwiki são diluídos no total de votos. Quintal ✁ 16h07min de 17 de fevereiro de 2017 (UTC)

Favor não desviar o assunto, "troca de favores" não é o mesmo que "Canvassing (solicitação indevida)". Por favor, atenha-se ao que estamos discutindo aqui.-- Darwin ^Ahoy! 16h34min de 17 de fevereiro de 2017 (UTC)

Leve lá a bicicleta... Quintal ✁ 16h35min de 17 de fevereiro de 2017 (UTC)

[Ver]

Actualização dos termos de uso da ferramenta de reversor

Bom dia. Notei que as regras para o uso da ferramenta de reversor practicamente não são actualizadas desde 2009, quando foram traduzidas da wiki espanhola, num formato que já era confuso no próprio original. Um exemplo da falta de coerência no texto actual, é ler-se ali que a ferramenta só pode ser usada para reverter vandalismos, mas no próprio ponto e no ponto seguinte fala-se em Guerra de Edições e "edições legítimas". Adicionalmente, essas regras não só não reflectem o uso geral dessa ferramenta noutros projectos, a começar pela própria Wiki-en, como não reflectem também a prática geral neste projecto, em particular no que respeita à reversão de edições de socks e banidos.

A própria Wiki-es há anos que abandonou estas regras e as substituiu por uma tradução da Eiki-en.

Proponho, assim, que o conteúdo da secção Wikipédia:Reversor#Perda da ferramenta seja revisto e actualizado de acordo com o constante da wiki-en, com a seguinte redacção:

(início das alterações) A ferramenta de reversão é um método rápido de desfazer edições problemáticas, mas tem a desvantagem de gerar somente um sumário de edição genérico, sem qualquer explicação sobre a razão da mudança. Por este motivo, considera-se inapropriado o uso desta ferramenta em situações onde seja usual a colocação de um sumário de edição explicativo.

O uso da ferramenta é permitido nas seguintes situações:

1. Para reverter vandalismos óbvios e outras edições onde a razão da reversão seja perfeitamente clara;
2. Para reverter edições nas suas próprias páginas de usuário;
3. Para reverter as suas próprias edições (por exemplo, edições feitas de forma acidental);
4. Para reverter edições feitas por usuários bloqueados ou banidos, desafiando o seu bloqueio (mas esteja preparado para explicar este uso da ferramenta, caso lhe seja solicitado).
5. Para reverter edições em massa (por um editor equivocado ou por um robô defeituoso) que se julguem ser prejudiciais para a enciclopédia, assumindo que possa ser fornecida uma explicação no local apropriado, tal como numa página de discussão relevante.

O uso da ferramenta para outros propósitos, tais como a reversão de edições de boa fé com as quais não se concorda, tem toda a probabilidade de ser considerado abuso da ferramenta. Quando em dúvida, use outro método de reversão, e coloque um sumário de edição que explique os motivos da reversão.

Tal como acontece com outros métodos de reversão, quando utilizar a ferramenta de reversão para restaurar texto numa página assegure-se de que esse texto restaurado não viola regras da Wikipédia.

Os administradores podem remover o estatuto de reversor, ou mesmo bloquear um editor como resposta a uma incapacidade persistente de explicar reversões, independentemente de serem feitas com a ferramenta ou não. No entanto, deve ser garantida ao editor a oportunidade de se explicar sobre o modo como foi feita a reversão antes de ser tomada qualquer atitude. Poderão existir motivos dos quais um administrador não está a par, tais como as reversões de editores banidos. Do mesmo modo, editores que incorram em guerra de edição podem perder a ferramenta, independentemente dos meios usados para levar a cabo a guerra de edição.

Adicionalmente, considera-se abuso da ferramenta de bloqueio, no caso dos reversores: (fim das alterações)

1. Bloqueio de contas confirmadas, por um período superior a 24 horas, ou por outros motivos além de vandalismo leve ou destrutivo.
2. Bloqueio de usuário envolvido em um conflito editorial (guerra de edições, por exemplo).

A remoção da permissão pode ser realizada por qualquer dos administradores, sem qualquer empecilho no caso de abuso constatado. Mesmo assim, qualquer usuário pode reportar um possível abuso da ferramenta nos pedidos a administradores.

Ao usuário que teve seu acesso a ferramenta removido é reservado o direito de realizar uma nova solicitação tão logo o problema que resultou na perda da permissão tenha sido sanado.

O absenteísmo também é motivo legítimo para remoção do acesso a todos os reversores que se encontrem editorialmente inativos há, pelo menos, seis meses.

Por favor, digam o que acham: Se há alguma correcção a fazer, se há alguma objecção em fazer esta actualização. Obrigado, -- Darwin ^Ahoy! 18h12min de 19 de fevereiro de 2017 (UTC)

Concordo. Acredito que nem há o que comentar. É o texto atual da enwiki, que foi utilizado no commons e na eswiki, entre outros. Basta aplicar a atualização aqui também. RadiX∞ 19h06min de 19 de fevereiro de 2017 (UTC)

Apoio desde que sejam também incluídas as alterações a verde desta segunda caixa de destaque. O que está a verde faz parte da recomendação da en.wiki e não foi traduzido. Quintal ✁ 20h00min de 19 de fevereiro de 2017 (UTC)

Eu não traduzi essas duas frases, a primeira porque era uma decisão do ArbCom de lá, a segunda porque me pareceu desnecessária e redundante com a política geral. No entanto, vendo melhor, a segunda é de facto importante que seja incluída, e a primeira pode eventualmente ser útil, de modo que Concordo, e agradeço a observação. Pode até trocar a minha proposta pela sua, se quiser, para poupar espaço.-- Darwin ^Ahoy! 20h10min de 19 de fevereiro de 2017 (UTC)

Apoio, visto que a proposta documenta o que já é posto em prática atualmente. - Épico (disc)/(contrib) 21h10min de 19 de fevereiro de 2017 (UTC)

Apoio com as cláusulas definidas acima. ♪ Alberto79 ♪ ^{Msg-Contributions} 21h25min de 19 de fevereiro de 2017 (UTC)

Apoio as mudanças e pontos indexados pelo Quintal, formaliza o que já ocorre. --Hume42 ✉ 21h27min de 19 de fevereiro de 2017 (UTC)

Apoio com o que foi proposto para os termos de uso da ferramenta de reversor. --João Guilherme (discussão • contribs) 21h50min de 19 de fevereiro de 2017 (UTC)

Concordo com esta reformulação. Luís Angelo "Tuga1143 10h36min de 20 de fevereiro de 2017 (UTC)

Concordo com a atualização, creio que essas novas diretrizes ajudarão no uso correto da ferramenta e nos guiará na aplicação de boas práticas aqui na pt.wiki Rodrigo Padula^{(Fale comigo)} 15h30min de 20 de fevereiro de 2017 (UTC)

Apoio Já estava na hora da documentação do rollback passar por uma boa atualização. É uma ferramenta bastante importante e muita usada no projeto. --Pap@ Christus ^msg 15h48min de 21 de fevereiro de 2017 (UTC)

Apoio É importante atualizar a nova documentação sobre o uso da ferramenta de reversor. WikiFer ^msg 18h37min de 1 de março de 2017 (UTC)

Consenso obtido

A página foi aprovada como Cerca de duas semanas após a apresentação da proposta, não havendo qualquer oposição, foi obtido um consenso pela aprovação da actualização proposta, com as alterações sugeridas por Antero de Quintal. Obrigado a todos os que participaram e contribuíram para a obtenção deste consenso..

-- Darwin ^Ahoy! 03h17min de 5 de março de 2017 (UTC)

[Ver]

Mudanças no processo de eleição de Verificadores e Supervisores

Boa tarde comunidade,

Bem, como a maioria bem sabe, todos os anos ocorrem eleições para a renovação de mandatos de Checkuser (ver aqui) e Oversight (ver aqui), que de acordo com as respectivas políticas, duram 1 ano. Após as eleições, os burocratas, geralmente fazem pedidos no Meta-wiki para que, quando a confirmação da renovação de mandato ocorre aqui, os stewards "liguem e desliguem" as ferramentas, apenas para registro de que o mandato foi renovado (creio que por um motivo de transparência). Vocês podem ver os registros do Teles e do RadiX onde se consta essas mudanças. Pois bem, o que houve essa semana passada com o pedido de renovação do Marcelo Victor (podem ver aqui), foi que a steward MF-Warbug e outros, questionaram o porquê desses pedidos serem feitos no Meta, citando especificamente o que está escrito na página do Meta que Citação: Temporary CheckUser access is not permitted and temporary access is only used by stewards. e Citação: Note that temporary Oversight access is not permitted and temporary status is only used by stewards.. O que não deixa de fazer sentido, dado o caráter de que a ferramenta é disponibilizada "temporariamente" por 1 ano, sujeito à confirmação.

Apesar de que isso tenha sido uma situação que ocorreu pela primeira vez, não deixa de ser um reflexo de que algo é contrassenso aqui na pt.wiki, e que muito provavelmente isso possa acontecer de novo, já que também se aproximam as confirmações do Teles, do Érico e do RadiX. Então, minha proposta para adequarmos os processos de votação pode ser uma das sugeridas a seguir (ou outras que possam sugerir):

• Ajustamos as escolhas para a base de consenso, para uma avaliação do verificador ou do supervisor (creio que essas escolhas podem ser provocadas por editores, em um período de tempo hábil, ou pelo próprio detentor);
• Acabamos com a limitação de 1 ano de mandato, e vinculamos à apenas uma eleição única e/ou desnomeação que pode ser conjunta à do administrador ou separado;
• As votações continuam, apenas em caráter de confirmação, sem que os pedidos no Meta-wiki sejam feitos a não ser que seja que não seja confirmada a reeleição (e por conseguinte, sem registros de movimentação de privilégios).

Fiquem à vontade para debatermos e, por conseguinte, aprimorar nossos processos de escolha. Eta Carinae (discussão) 17h40min de 20 de fevereiro de 2017 (UTC)

Apoio a segunda proposta. !Silent (discussão) 17h53min de 20 de fevereiro de 2017 (UTC)

@EVinente: Não entendi a primeira proposta. Poderia explicá-la melhor? RadiX∞ 20h08min de 20 de fevereiro de 2017 (UTC)

RadiX No caso de um verificador ou supervisor, as escolhas passam a ser de votações para por consenso (como eliminador e ou burocrata). Sendo que elas podem acontecer em um tempo hábil (1 ano, 2 anos, ou outro período), sendo que um editor também pode provocá-la, como indicar um administrador, ou para reelegê-lo, se já for um verificador ou supervisor. Eta Carinae (discussão) 20h21min de 20 de fevereiro de 2017 (UTC)

Não me parece que nenhuma das opções seja necessária. Basta deixar de pedir no Meta que desliguem e voltem a ligar a flag. Se é confirmado, continua, se não é, então faz-se o pedido. Nada nos nossos procedimentos implica que estes pedidos tenham que ser feitos. GoEThe (discussão) 08h27min de 21 de fevereiro de 2017 (UTC)

GoEThe creio que esses pedidos eram apenas pra fins de registro mesmo. PS: Coloquei na última opção que não fazemos mais pedidos no Meta-wiki. rsrs Eta Carinae (discussão) 09h47min de 21 de fevereiro de 2017 (UTC)

Sim, eu reparei, mas isso não quer dizer que as confirmações passem apenas a ter apenas caráter de opinião. Serão na mesma vinculativas. GoEThe (discussão) 10h01min de 21 de fevereiro de 2017 (UTC)

GoEThe, alterei o texto, de acordo com o que você disse. Eta Carinae (discussão) 10h39min de 21 de fevereiro de 2017 (UTC)

OK. Concordo então com a proposta 3. GoEThe (discussão) 10h43min de 21 de fevereiro de 2017 (UTC)

Fiz um pequeno ajuste. GoEThe (discussão) 10h45min de 21 de fevereiro de 2017 (UTC)

Apoio a proposta 2. As confirmações anuais para verificadores e supressores são uma bizarrice exclusiva da Wikipédia em Português. Em nenhuma outra wiki é possível que um verificador ou supressor tenha seu estatuto removido sem motivos consistentes. Aqui votam contra por qualquer coisa, desde ter discordado em uma EAD até ter negado um pedido de bloqueio. Essas confirmações anuais perderam todo o caráter técnico que deveriam ter. Passaram a ser um teste de popularidade, o que considero inadmissível levando em conta a importância que essas ferramentas possuem. Se esta regra não for mudada, teremos cada vez menos gente disposta a atuar nessas áreas. Érico (fale) 14h07min de 21 de fevereiro de 2017 (UTC)

Cada comunidade tem direito às suas excentricidades :). No entanto, a proposta inicial do Evinente nada tem a ver com os motivos que fazem alguem votar contra ou a favor, mas com a "necessidade" de ir ao Meta pedir para desligar e ligar novamente as ferramentas após confirmação. Isso me parece uma discussão tangencial a esta. Dito isto, não me lembro de nenhum checkuser ter perdido ferramentas após votação, mas apenas após absentismo ou por não ter aberto pedido de confirmação. Os últimos verificadores a deixar expirar os mandatos foram Jbribeiro1 e Lord Mota. Talvez eles possam dizer melhor se tal se deveu a terem que passar por confirmação todos os anos. GoEThe (discussão) 14h43min de 21 de fevereiro de 2017 (UTC)

Evidentemente. Também senti que a proposta falhou em apresentar os motivos de não precisar mais de confirmações anuais. Atualmente, como disse pelo RadiX, os verificadores são extensivamente vigiados, pela OC e stewards, ambos possuindo acesso aos logs de verificação a qualquer momento. Neste cenário é impossível que um abuso passe em branco. Minha visão de que essas confirmações anuais são desnecessárias e perderam seu objetivo aumentou nos últimos tempos. Não acho que elas são benéficas para ninguém (verificadores e comunidade). Se elas continuarem, que pelo menos sejam via consenso. Érico (fale) 14h52min de 21 de fevereiro de 2017 (UTC)

Eu deixei o estatuto vencer por falta de tempo para me dedicar ao assunto (já não conseguia mais nem participar das discussões no fim do "mandato"). José Luiz ^disc 15h00min de 21 de fevereiro de 2017 (UTC)

Apoio a proposta 3, é a que me parece mais útil ao projecto neste momento. Não vejo nenhum motivo para mudar o que funciona bem.-- Darwin ^Ahoy! 21h05min de 21 de fevereiro de 2017 (UTC)

@GoEThe e Darwinius: Vocês não acham, então, que o modelo deveria ser mudado de votação para consenso? Pela lógica empregada aqui, as confirmações anuais são feitas para avaliar se determinado verificador / supressor cumpriu bem seu papel durante o último ano de "mandato". Entretanto, quando se vota contra sem apresentar nenhum argumento para tal, esse objetivo falha. Se fosse por consenso, como nos pedidos de burocratas e eliminadores, deveria ser obrigatoriamente apresentado argumentos que provassem que determinado usuário não possui mais a confiança ou exerceu mal suas funções. Seria basicamente como ocorre para stewards. Isto seria mais justo, tanto para com o propósito das confirmações como também ao usuário, que saberia onde errou, porque errou e o que deveria fazer para melhorar. Érico (fale) 21h40min de 21 de fevereiro de 2017 (UTC)

Concordo com a proposta 3. Já que alguns Stewards entendem ser desnecessário numa reeleição bem sucedida desligar e ligar a flag para registrar um novo ciclo de vigência, nesse caso é dispensável ir ao Meta para solicitar tal ação. --Pap@ Christus ^msg 22h12min de 21 de fevereiro de 2017 (UTC)

@Papa Christus: Olá. Faço, então, a mesma pergunta (acima) que fiz a Darwinius e GoEThe: consenso ou votação? Não acha que escolher via consenso cumpriria melhor o objetivo das confirmações anuais? Érico (fale) 22h22min de 21 de fevereiro de 2017 (UTC)

@Érico: Eu tenho ideia de que este tipo de decisão, pelas regras do meta, não pode ser por consenso. Talvez o RadiX possa esclarecer isso.-- Darwin ^Ahoy! 22h25min de 21 de fevereiro de 2017 (UTC)

@Érico: Saudações! Olha se alguma regra não proibir eu acho que poderia sim ser por consenso, no entanto, com a divulgação das confirmações por meio do MassMessage vejo que torna-se um pouco difícil aferir consenso em situações destoantes, pois são muitos editores. --Pap@ Christus ^msg 22h46min de 21 de fevereiro de 2017 (UTC)

• Em wikis da Wikimedia sem um Conselho de Arbitragem, os verificadores devem ser escolhidos por meio de votação, sendo aprovados aqueles que obtiverem ao menos 25 votos favoráveis e uma taxa de aprovação mínima de 70%. Já houve uma discussão interna entre os stewards acerca de outras formas de aprovação; no entanto, não houve aceitação, pois para a adoção de outros mecanismos de escolha (ex.: consenso) haveria a barreira linguística. Assim, a política permaneceu inalterada. Logo, no presente momento, não há como aprovar verificadores ou supressores, pela primeira vez, de outra maneira.
• Com relação à substituição das votações anuais para verificadores/supressores já aprovados por pedidos de confirmação, bem... não sei como isto poderia ser trabalhado. Teoricamente, em se tratando de usuários já aprovados, não haveria necessidade de que o processo de confirmação fosse uma votação. No entanto, caso fosse substituído por uma discussão ou pedido de opinião, teríamos outro impasse: como avaliar o resultado das discussões? Quem poderia verificar possíveis problemas e confirmar o resultado da discussão? (Não podemos esquecemos que essas permissões não são gerenciadas localmente, e tanto a atribuição quanto a remoção são atribuições dos stewards, que que verificam e aplicam o resultado de uma decisão local).
• Portanto, antes de propor mudanças, devemos averiguar com calma as possíveis consequências (e problemas) que estas acarretariam. RadiX∞ 03h01min de 22 de fevereiro de 2017 (UTC)

@RadiX: Sobre esta frase da política de CheckUser: "On a wiki without an Arbitration Committee that meets the criterion above, or in a project where there is a preference for independent elections, the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus. The CheckUser candidate status must request it within the local community and advertise this request properly (village pump, mailing list when available, special request page, etc.). The candidate must be familiar with the privacy policy. After gaining consensus (at least 70%–80% in pro/con voting or the highest number of votes in multiple choice elections) in the local community, and with at least 25–30 editors' approval, the successful candidate should request access at Steward requests/Permissions with a link to the page with the community's decision. If there are an insufficient number of votes for at least two CheckUsers on a wiki, there will be no CheckUsers on that wiki." Foi escrito "consenso" por qual motivo, já que está claro que trata-se de uma contagem de votos? Achei estranho. Érico (fale) 03h30min de 22 de fevereiro de 2017 (UTC)

Como o RadiX diz, neste caso em que os stewards (que não percebem português na maioria das vezes) têm que confirmar que os verificadores têm apoio consensual da comunidade é mais simples que o consenso seja aferido por meio de apoio/não apoio, do que com comentários, réplicas e tréplicas mais complexas. GoEThe (discussão) 09h01min de 22 de fevereiro de 2017 (UTC)

@GoEThe: Exato. Imagine uma discussão em coreano para aprovação de verificadores, na qual se deva avaliar e verificar o peso dos argumentos. E suponha, ainda, que tal discussão seja cometida por toda a sorte de confusões e acusações de violações de políticas locais etc. RadiX∞ 11h50min de 22 de fevereiro de 2017 (UTC)

@Érico: Tendo-se em vista que o consenso não implica em unanimidade, o termo provavelmente foi empregado para sinalizar a aprovação, concordância para a indicação do usuário, independentemente dos meios empregados para se chegar a esse resultado. RadiX∞ 11h50min de 22 de fevereiro de 2017 (UTC)

Então os testes de popularidade as confirmações anuais irão continuar... Érico (fale) 19h11min de 22 de fevereiro de 2017 (UTC)