Wikipédia:Esplanada/tudo

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
▼ Ir para o fim da página ▼
Bem-vindo(a) à Esplanada (todas as secções)!
Esta página agrupa todas as subseções da Esplanada numa só página.
  • Se quiser vigiar toda a Esplanada, deverá aceder às respectivas páginas (anúncios, propostas e geral) e clicar na aba "vigiar" em cada uma delas.
  • Para adicionar comentários não use a aba "editar" desta página. Para isso recorra às ligações disponíveis no inicío de cada secção.
  • Para ter certeza de que o conteúdo desta página está atualizado, clique em atualizar.
  • Atalhos para as secções desta página: ▼ Anúncios | ▼ Propostas | ▼ Geral
  • Veja também as mudanças recentes nas esplanadas.


Índice


Anúncios

Secção de anúncios da Esplanada ◄ Anúncios | ▼ Propostas | ▼ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta. Consulte também Wikipedia:Notícias, Jornal da Wikipédia e Wikizine.
clique aqui para adicionar um novo tópico na secção anúncios


Célio Costa Filho é Sturm?!

O texto que aqui estava foi movido para: Wikipédia:Esplanada/geral/Célio Costa Filho é Sturm?! (2jan2017)

AutoWikiBrowser para Fox de Quintal

O semi-robô AutoWikiBrowser para o Fox de Quintal usar na Wikipédia PT. - Fox de Quintal FQ (discussão) 17h37min de 23 de dezembro de 2016 (UTC)

Para refletir...

O texto que aqui estava foi movido para: Wikipédia:Esplanada/geral/Para refletir... (2jan2017)

O elefante

O texto que aqui estava foi movido para: Wikipédia:Esplanada/geral/O elefante (30dez2016).-- Leon Saudanha 14h58min de 30 de dezembro de 2016 (UTC)

Pedido de aprovação para Administrador do usuário Rgps

Comunico que o usuário Rgps abriu um pedido de aprovação para Administrador. A votação se encontra nessa página. Edilson Vinentefale comigo 13h20min de 6 de janeiro de 2017 (UTC)

Wikipédia:Burocratas/Pedidos de aprovação/Conde Dantes

Venho aqui anunciar que abri o pedido em pauta. Le Comte Edmond Dantès Listening to the wind of change 20h14min de 7 de janeiro de 2017 (UTC)

Relatório de comunicação - Julho - Dezembro de 2016

Wiki educacao logo.svg

Olá pessoal,

O relatório inclui repercussão de projetos desenvolvidos pelo grupo Wiki Educação Brasil no período e pautas geradas pelo nosso time para repercutir a Wikipédia e o movimento Wikimedia na mídia nacional, ampliando e melhorando nossa relação com jornalistas para que continuem nos apoiando na defesa e divulgação dos projetos Wikimedia e do conhecimento aberto.

O documento foi criado pela Fernanda Galvão, nossa colaboradora de comunicação. Feliz 2017 a todos e boas edições!

Rodrigo Padula (discussão) 18h40min de 9 de janeiro de 2017 (UTC)

Discussão sobre a cantora Rosana Fienngo

Peço que participem por favor desta discussão sobre a cantora citada, haja vista que novos dados foram adicionados ao caso. O caso pode ser melhor entendido com o contexto. Obrigado.—Teles«fale comigo» 17h42min de 17 de janeiro de 2017 (UTC)

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

Informo que o Joalpe D​ C​ E​ F abriu um pedido de aprovação para administrador. --Pap@ Christus msg 22h01min de 28 de janeiro de 2017 (UTC)

Campus Party e Edit-a-thon Rio de Museus

Wiki educacao logo.svg

Olá pessoal,

Como de costume, estaremos representando os projetos Wikimedia na Campus Party Brasil 2017 em São Paulo a convite da organização do evento.

Teremos uma palestra sobre a Wikipédia, apresentando números e projetos desenvolvidos pelo grupo Wiki Educação Brasil no dia 3 às 23:00.

Nesta semana também teremos a primeira palestra que dará início a um novo projeto no Rio de Janeiro, em parceria com a Prefeitura do Rio de Janeiro e COMCOL Brasil(Comitê Internacional do ICOM para o Desenvolvimento de Coleções).

Este projeto visa criar uma aproximação com os gestores e funcionários dos museus cariocas pra trazer mais conteúdo e acervos para os projetos Wikimedia. Esta parceria vem sendo desenhada desde 2016 e finalmente iniciaremos nossas atividades.

Objetivos:

  • Aumentar a quantidade e qualidade de informações sobre o patrimônio cultural brasileiro disponibilizadas sobre os museus cariocas e suas coleções em plataformas de acesso livre (tais como a Wikipedia);
  • Capacitar os museus participantes a inserirem novos conteúdos dali por diante, de forma autônoma e independente;
  • Disseminar o tema do acesso aberto junto aos profissionais de museus e patrimônio;
  • Disseminar as atividades e projetos da Wikimedia desenvolvidos no Brasil, especialmente com foco cultural e na preservação do patrimônio histórico.


Abraços Rodrigo Padula (discussão) 11h33min de 30 de janeiro de 2017 (UTC)

Wikipédia:CheckUser/Candidaturas/Marcelo Victor/2

Olá a todos,

Comunico que abri uma solicitação de renovação do meu estatuto verificador de contas e desde já agradeço pela participação de todos. obrigado Mvictor Fale 00h44min de 4 de fevereiro de 2017 (UTC)

O texto que aqui estava foi movido para: Wikipédia discussão:Política de bloqueio

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. Edilson Vinentefale comigo 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)

Filtro inteligente para mudanças recentes

O texto que aqui estava foi movido para: WP:Esplanada/propostas/Filtro inteligente para mudanças recentes (11fev2017). Helder 11h19min de 11 de fevereiro de 2017 (UTC)

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

WMBR UserGroup Logo v.svg
Editatona Neurociência e Matemática III.svg

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 MazucoMsg 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:

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)• Por favor, ajude nas traduções para o seu idiomaPeç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

WMBR UserGroup Logo v.svg
Palestra LiAnna Davis.pdf

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:

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 MazucoMsg 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)


Propostas

Secção de propostas da Esplanada ▲ Anúncios | ◄ Propostas | ▼ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta.
clique aqui para adicionar um novo tópico na secção propostas



Maior divulgação dos PDAs

Olá.

Proponho que todos os PDAs passem a receber a mesma divulgação dada a pedidos de verificador e supressor. Ou seja, que todos os usuários com direito ao voto recebam avisos da votação, se assim o quiserem.

Historicamente os pedidos de administração contam com uma participação menor da comunidade. Porém, este problema se agravou nos últimos meses. Tivemos PDAs de ex-administradores que terminaram com menos de 25 votos. Está cada vez mais raro ver um PDA com mais de 30 votos. Ter 40 editores participando ficou para a antiguidade.

Este é um problema extremamente grave por vários motivos. Ter administradores aprovados com baixa participação da comunidade faz com que eventualmente a qualidade destes piore, pois uma parte considerável de editores votam a favor de tudo e sempre. E, muitas vezes, tais editores são pouco criteriosos. Lembrando que um administrador é aprovado com apenas 10 votos.

A experiência que tivemos com as votações de verificadores e supressores significou uma evolução, pois não apenas a participação traduzida em votos aumentou, mas também a participação com perguntas e a qualidade da avaliação. Pelos arquivos é possível atestar que pedidos foram rejeitados por mais editores. Não significa que a qualidade dos candidatos piorou, mas que pedidos que fracassariam com 6 votos contrários passaram a ser rejeitados por mais de 20. É extremamente desmotivante quando se tem um pedido mal sucedido como resultado de poucos votos. Mas quando essa parcela é alta, o candidato tem a garantia de que parte significativa da comunidade o disse "melhore aqui, não faça mais isso". Sem falar que uma votação com mais votos reduz a possibilidade de fraudes.

Por último, considero esta apenas mais uma etapa para aprimorarmos a avaliação dos candidatos e posteriormente a qualidade dos administradores. Espero que reflitam sobre isso e, claro, opinem também. Érico (fale) 05h03min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo com a sugestão do Érico, quanto maior a participação mais representativa é a opinião da comunidade. Quem não quiser receber avisos retire o nome da lista como eu fiz. DARIO SEVERI (discussão) 06h30min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo com a proposta e acho que devia ser extensível a todas as votações gerais (não contando com PEs e EADs). Para mim mais grave que a falta de votantes (que existe, é um facto) é a questão da integridade das votações, que com poucos votantes fica claramente sob maior risco de fraude. Já que a restrição anti-sock do direito ao voto não passou ao menos pode aumentar-se o número de votantes e assim diminuir o impacto dos votos fraudulentos. Gonçalo Veiga (discussão) 07h24min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo com a proposta. PDAs precisam da participação de grande parte da comunidade. WikiFer msg 08h41min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo com a proposta do Érico, a ferramenta de administrador é muito poderosa e deve ter o maior foco possível juntamente com os pedidos de verificador, supervisor. Mais participação geralmente implica mais pergunta e análise, por conseguinte a comunidade pode fiscalizar e pronunciar-se devidamente. Gato Pretotrovai-me! 10h49min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo Tetraktys (discussão) 11h29min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo E além de mandar aviso (ao usuários que quiserem receber), colocar também em MediaWiki:Watchlist-details, para aparecer no topo das PVs. !Silent (discussão) 13h06min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo quanto mais participação da comunidade, melhor. Bia Alencar Mensagens 14h29min de 18 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo Eu mesmo já tinha um projecto desse em mente, mas era para os pedidos de desnomeação. Só uma pergunta Érico, isto também valerá para pedidos de desnomeação e opinião? Mr. Fulano! 🔔Fale Comigo📩 03h40min de 19 de dezembro de 2016 (UTC)

@Mr. Fulano: Não propus acima. Após ler seu comentário passei a considerar relevante incluir os pedidos de remoção. Seria bom se você entrasse em contato com todos os editores que comentaram aqui para que eles também avaliassem sua proposta. Érico (fale) 03h55min de 20 de dezembro de 2016 (UTC)
@DARIO SEVERI, WikiFer, Gonçalo Veiga, Gato Preto, Tetraktys, Bya97, Marcelo Victor, Fox de Quintal, e Zoldyick: Concordam com que eu propus acima, em se avisar também os pedidos de remoção? Mr. Fulano! 🔔Fale Comigo📩 12h27min de 20 de dezembro de 2016 (UTC)
Symbol support vote.svg Concordo também. Bia Alencar Mensagens 12h30min de 20 de dezembro de 2016 (UTC)
Symbol support vote.svg Concordo também, com os de aprovação, remoção e opinião. Gato Pretotrovai-me! 14h18min de 20 de dezembro de 2016 (UTC)
Symbol support vote.svg Concordo também, com os de aprovação, remoção e opinião (2). WikiFer msg 17h15min de 20 de dezembro de 2016 (UTC)
Symbol support vote.svg Concordo também, incluindo os pedidos de aprovação, opinião e remoção. Gonçalo Veiga (discussão) 02h19min de 21 de dezembro de 2016 (UTC)
Symbol support vote.svg Concordo também, incluindo os pedidos de aprovação, opinião e remoção.comentário não assinado de DARIO SEVERI (discussão • contrib) 04h36min de 21 de dezembro de 2016 (UTC).

Symbol support vote.svg Concordo com a proposta. Mvictor Fale 03h48min de 19 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo Já fizeram algo igual, só que é só para eleger verificador de contas e supervisores e esqueceram os administradores. Fox de Quintal FQ (discussão) 16h31min de 19 de dezembro de 2016 (UTC)

@Érico: Já fizeram isso para verificadores de contas e supervisores, tem uma lista de pessoas que recebem mensagens, eu acho melhor utilizar a mesma lista, pois se alguém quiser parar de receber mensagens, será muito inconveniente ter que tirar o nome de duas listas.comentário não assinado de Fox de Quintal (discussão • contrib) 19 de dezembro de 2016, 16 horas e 35 minutos (UTC)

@Fox de Quintal: Sim. Isso está escrito nos primeiros parágrafos desta proposta. Érico (fale) 00h42min de 20 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo --Zoldyick (Discussão) 16h36min de 19 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo incluindo também pedidos de remoção. Vanthorn® 04h00min de 20 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo Tetraktys (discussão) 13h09min de 20 de dezembro de 2016 (UTC)

Ainda não cheguei a uma conclusão se haveria, de fato, uma real vantagem em ampliar a visibilidade em tais situações. Os pedidos para CH e oversighter demandam um quórum mínimo, daí a necessidade da divulgação estendida. Quanto aos pedidos de remoção de administradores, preocupa-me a exposição do usuário, a despeito dos benefícios inerentes que já foram apontados na discussão acima, além de algumas questões de ordem ética, a depender do motivo da remoção. Contudo, ainda não tenho uma posição a respeito. RadiX 02h30min de 21 de dezembro de 2016 (UTC)

Não é benéfico termos PDAs sendo decididos com uma participação mínima da comunidade. Conforme disse acima, quando se tem uma parte da comunidade que vota a favor de tudo sempre, é bem provável que a qualidade dos administradores piore com o tempo, pois a avaliação que deveria ser rígida não foi feita. Quanto aos pedidos de remoção, não considero uma exposição indevida, pois esses pedidos são abertos para debater a atuação do administrador e não ele em si. Ademais, é mais humilhante quando se tem as ferramentas removidas como resultado de uma baixa participação comunitária ou sem ter havido violação das regras. Ainda sobre os pedidos de remoção, acho muito importante que o envio das mensagens só poderia ser feito com o aval dos burocratas, que avaliariam se aquele pedido cumpre com as regras. Desta forma, ninguém será exposto indevidamente. Érico (fale) 02h39min de 21 de dezembro de 2016 (UTC)
Não apontei malefícios no modelo de divulgação proposto. Talvez porque não existam. Ou, talvez, porque o único problema seria a vulgarização de um processo criado para situações que demandam maior exposição em determinado ínterim, contrastando com os pedidos de aprovação de administradores, que ocorrem com maior trivialidade. Talvez a melhor solução fosse alterar esse sistema baseado em votações para outro apoiado em decisão por consenso. Os pedidos de aprovação de administradores constituem uma exceção entre os demais, desconsiderando-se os pedidos para verificador e oversighter, os quais, obrigatoriamente, requerem contagem de votos. RadiX 02h36min de 27 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo em aumentar a visibilidade dos pedidos de aprovação, opinião e remoção. Percebo isso como um avanço que implica principalmente na qualidade de avaliação. --Pap@ Christus msg 15h26min de 22 de dezembro de 2016 (UTC)

Symbol support vote.svg Concordo Significa mais participação da comunidade--Agent010 (discussão) 03h40min de 8 de janeiro de 2017 (UTC)

Depois de mais de um mês de debate, está claro que houve consenso para a aprovação das mudanças propostas. Por eu ser o autor de uma das propostas, outro editor poderia implementar o consenso alcançado aqui? Obrigado. Érico (fale) 01h12min de 20 de janeiro de 2017 (UTC)

Como ninguém se manifestou, encerro esta proposta como aprovada por consenso unânime e aplicarei o resultado. Érico (fale) 02h01min de 26 de janeiro de 2017 (UTC)

Como isso vai ser implementado exatamente? Eu sugiro enviar uma mensagem única a todos informando sobre a possibilidade de inscrição numa determinada lista. Assim, os que quiserem vão se inscrevendo.—Teles«fale comigo» 16h46min de 26 de janeiro de 2017 (UTC)

Eu nem sabia da existência desta discussão de esplanada, que aparentemente, sem o meu conhecimento e sem qualquer explicação, decidiu usar uma lista na qual eu estava inscrito para outros propósitos. A isto habitualmente chama-se spam, e naturalmente que já removi o meu nome de lá, mas quero deixar claro que não considero o que aconteceu aqui, de todo, uma boa prática. No mínimo devia-se ter avisado quem está inscrito nessa lista que o propósito da mesma havia mudado, ou usar uma lista diferente em opt-in, como sugerido acima pelo Teles.-- Darwin Ahoy! 16h40min de 27 de janeiro de 2017 (UTC)
Essa página já existe e é usada há muito tempo para este mesmo propósito. Várias mensagens já foram encaminhadas contendo avisos sobre pedidos. Não gostar desses avisos é uma opção, da mesma forma que remover o nome da lista também é. Érico (fale) 17h10min de 27 de janeiro de 2017 (UTC)
Está escrito no cabeçalho dessa lista, de forma bem clara: "Esta lista contém o nome dos usuários que deverão ser notificados acerca das votações para a escolha de verificadores de contas e supervisores. Não deverá ser utilizada para outros fins." Hoje foi a primeira vez que essa lista foi usada para efeitos diversos do propósito com que foi criada, tanto quanto eu tenho conhecimento. Não considero o que você fez, Érico, uma atitude correcta, e desaprovo-a fortemente. Em todo o caso já me removi dessa bendita lista de spam, pelo que da minha parte o assunto está encerrado.-- Darwin Ahoy! 17h25min de 27 de janeiro de 2017 (UTC)
Está desatualizado. É só mudar. A comunidade decidiu, de forma unânime, que os PDAs merecem tanta visibilidade quanto os pedidos de verificador e supressor. Não há controvérsia aqui, só drama. Érico (fale) 17h27min de 27 de janeiro de 2017 (UTC)
A questão é que você ao implementar essa decisão daqui por sua conta usando essa lista, que não foi criada para esse efeito nem tampouco faz parte desta proposta, desvirtuou a decisão anterior sobre supressores e verificadores, de tal modo que quem, como eu, quer ser avisado sobre as eleições de supressores e verificadores, que são obviamente mais raras e mais importantes que as de administrador, agora tem que levar com esse spam dos PdAs. Não tem drama nenhum, só trapalhice e falta de visão da sua parte. Quando corrigirem isso, se alguma vez corrigirem, por favor me avisem para que volte a repor a minha inscrição na lista.-- Darwin Ahoy! 17h50min de 27 de janeiro de 2017 (UTC)
  • Para solucionar esse impasse, eu proponho que seja criada outra lista para os interessados em receber os avisos dos pedidos de administração. Algumas pessoas removeram seus nomes da lista hoje, após a divulgação do primeiro PDA nesses moldes, algo que não vinha ocorrendo nas últimas votações para verificador e supervisor. Se possível, o ideal seria perguntar aos inscritos na lista atual se desejam também ser notificados acerca dos pedidos de administração (opt-in) RadiX 18h04min de 27 de janeiro de 2017 (UTC)
  • Symbol support vote.svg Concordo, essa parece-me ser a solução ideal. Pode ser enviada uma mensagem única a todos os participantes da lista de notificação de eleições de supressores e verificadores sugerindo a inscrição nessa segunda lista. Assim o incómodo é minimizado, e a informação chega a quem a quer.-- Darwin Ahoy! 18h09min de 27 de janeiro de 2017 (UTC)
Discordo. Cria-se outra lista mantendo todos os nomes da atual. Quem quiser que remova seu nome. Foi assim que ocorreu com a primeira lista e fazer o contrário para a segunda significa dar menor importância aos PDAs, o que é errado e a própria comunidade assim decidiu com esta proposta. E definitivamente não é de hoje que as pessoas removem seus nomes daquela lista - e isso continuará ocorrendo, o que é normal. Érico (fale) 18h16min de 27 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo, pois além de propiciar uma maior participação da comunidade, na escolha de quem deve ajudar no desenvolvimento do projeto. D última vez que votei a favor em um candidato, me decepcionei. Infelizmente muitos se esquecem de que no informativo sobre administradores diz o seguinte: Citação: Os sysops não possuem "autoridade" em especial, sendo, portanto, iguais a todos os outros em termos de responsabilidade editorial. Alguns wikipedistas consideram os termos "operador de sistema" e "administrador" inadequados, uma vez que apenas indicam editores da Wikipédia a quem foram levantadas restrições de segurança e desempenho a umas quantas funções do software porque pareceram ser dignos de confiança. Isso acontece também com alguns reversores, que acham que as coisas tem que ser do jeito deles e ponto. Isso tem que acabar. Esse negócio de eleger qualquer um, sem capacidade de entender e sem capacidade de se manter imparcial é furada. Alguns querem favorecer seus apadrinhados e vice- versa. Alessandro SIL manda 10h22min de 28 de janeiro de 2017 (UTC-3).

  • Proponho então criarmos uma nova lista, a partir da lista atual, exclusivamente para os pedidos de administração e, em seguida, enviar uma mensagem a todos os "inscritos", informando-os acerca do procedimento aprovado e sobre a possibilidade de removerem o seu nome caso não queiram receber essas notificações. Será que teríamos um consenso dessa forma? RadiX 03h27min de 29 de janeiro de 2017 (UTC)
Também serão enviadas mensagens desse tipo aos inscritos da lista para pedidos de CU / OS? Isto é, pediremos se eles querem continuar recebendo as mensagens? Érico (fale) 13h04min de 29 de janeiro de 2017 (UTC)
O foco é a divulgação dos pedidos de administração por este método, que é algo novo. A maioria dos que não querem ser notificados sobre as votações para checkuser já removeu o seu nome da lista, mas não vejo problemas em consultá-los a respeito também. Eu, por exemplo, não quero ser notificado diretamente sobre os pedidos de administrador, mas quero receber avisos sobre os de checkuser/oversighter. RadiX 01h48min de 13 de fevereiro de 2017 (UTC)
A nova lista já foi criada e usada. Érico (fale) 01h54min de 13 de fevereiro de 2017 (UTC)

Moção de ficheiros para autorrevisores

Fui tentar seguir o guia de edição, que Citação: WP:MOVER escreveu: «Não é possível renomear uma imagem ou uma página de descrição de imagem. Em vez disso, carregue-a novamente sobrescrevendo o novo nome.», mas simplesmente não funciona mais assim (a frase está lá desde o original de 2004 104984]). Pedi então no Outros para realizar a moção que queria, e também para confirmar que a permissão existia por aqui. Permissão essa, amovefile, que foi estabelecida em 2011, como avisado pelo GoEThe em Renomeação de ficheiro (10mar2011), apenas aos administradores.

Os que passam de vez em quando pelo Commons devem estar familiarizados com os motivos pelos quais um ficheiro precisaria ser movido, mas resumem-se basicamente em:

  • Pedido do uploader,
  • Título ambíguo ou não descritivo ("Ficheiro:Cão" ou "Fdfad0f44628ca818c13821f2afeddf1" para "Ficheiro:Pastor alemão da Polícia Militar de Guarulhos"),
  • Erros óbvios ("Disdo de Maria Cahrey" para "Disco de Mariah Cahrey"),
  • Erros técnicos ("Imagem de exemplo.png.png");

e um extra importado da Wiki en, que é a situação onde arquivos internos possuam o mesmo título que um no Commons.

Quando da implementação desse direito, a Wikipédia anglófona realizou uma proposta análoga a essa presente, que resultou a criação de um estatuto especifico, o file mover. No entanto, considerando que seria absolutamente ridículo um estatuto novo apenas para mim e uns possíveis outros dois gatos pingados, acredito que seria muito mais simples apenas adicionar a mencionada permissão aos autorrevisores. Supõe-se que todos (com poucas exceções) autorrevisores possuam o direito de carregar imagens, e sendo este grupo Citação: WP:Autorrevisores escreveu: «familiarizado com as políticas e recomendações da Wikipédia», acredito que são competentes o bastante para renomear um ficheiro com cautela e cuidando das consequências da ação.

Assim, proponho a inclusão a esse grupo daquele direito. - Épico (disc)/(contrib) 19h08min de 8 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo !Silent (discussão) 19h14min de 8 de janeiro de 2017 (UTC)

Symbol question.svg Pergunta Quais são os papéis que possuem permissão para renomear/mover artigos? Mover um artigo não seria uma situação análoga a mover um ficheiro? Saudações. —Alan Moraes (discussão) 19h25min de 8 de janeiro de 2017 (UTC)

@Alan Moraes Usuários autoconfirmados podem mover artigos. !Silent (discussão) 19h36min de 8 de janeiro de 2017 (UTC)
@!Silent: Mas não precisa que outra pessoa com "estatuto maior" de fato mova o artigo? Obrigado. Alan Moraes (discussão) 19h42min de 8 de janeiro de 2017 (UTC)
@Alan Moraes Não, basta ser autoconfirmado. !Silent (discussão) 19h46min de 8 de janeiro de 2017 (UTC)
@!Silent: Ah! Não sabia que teria efeito imediato se um usuário autoconfirmado movesse uma página, pois imaginava que alguém com maior patente precisasse confirmar a moção. Grato! —Alan Moraes (discussão) 21h12min de 8 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo Gato Pretotrovai-me! 19h34min de 8 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo, é o mais lógico. Seria bom também transferir a documentação de en:Wikipedia:File mover#What files should be renamed? caso a wiki lusófona não tenha.--Luk3🔔📖 19h37min de 8 de janeiro de 2017 (UTC)

Sim, já planejava fazer isso, além de retirar a frase acima mencionada da página de ajuda e atualizar WP:AR. - Épico (disc)/(contrib) 04h06min de 9 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo --Pap@ Christus msg 20h06min de 8 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo} —Alan Moraes (discussão) 21h14min de 8 de janeiro de 2017 (UTC)

Qual a necessidade real, diária, semanal de movimentação de imagens? Penso que deve ser bastante pequena, de modo que chegamos até aqui sem a criação de um grupo de usuário específico para tal função. Sendo baixa, basta que as movimentações sejam solicitadas em Wikipédia:Pedidos/Outros, e processadas por um administrador, que possui o direito movefile em seu rol de permissões. Havendo uma necessidade maior, com o tempo, a solução ideal passaria pela criação de um grupo específico. Adicionar direitos que não têm relação com determinado estatuto vai na contramão da tendência da separação das permissões por grupos de usuário, além de que agregar um direito desconhecido ou sem utilidade à maioria dos autorrevisores, descaracterizando assim o estatuto. Portanto, pelo apresentado, no momento, Symbol declined.svg Discordo da proposta. RadiX 02h12min de 9 de janeiro de 2017 (UTC)

@RadiX: A necessidade é praticamente nula. O domínio Ficheiro em si só é editado esporadicamente, e, no presente momento, acredito que só haja eu interessado em cuidar dessa parte, até que pelo menos o MC volte (quiçá o Gunnex, poxa ele faz falta!). Esclareço que pretendo limpar a lista de imagens com mais de 500px (47671089]) além de recategorizar várias delas, como as que estão atualmente na Categoria:Walt Disney e Categoria:Star Wars. Já encontrei um punhado que precisavam ser renomeadas nas edições que fiz nesse domínio, embora até agora sempre achei que fosse impossível simplesmente movê-las. Duvido muitíssimo que a necessidade para a criação desse grupo de usuários um dia irá surgir.
Agora, sobre o direito movefile em si, ele é um de possibilidade de danos baixa, apenas ligeiramente maior do que o de moção de artigos. De fato, caso queira acompanhar a discussão original na anglo, verá que ele quase foi concedido aos autoconfirmados. Eu acredito que o ideal seja concede-lo aos autorrevisores (primeiramente, porque é o estatuto que eu tenho) porque são o grupo de editores com confiança da comunidade, e que provavelmente terão cabeça para, ao mover o ficheiro, mover seus afluentes também. Descaraterizar um grupo de usuários é uma coisa que eu nunca tinha ouvido e não sei se realmente entendi Radix. A característica do grupo autorrevisor, pelo que eu suponho, seria o autopatrol, mas a própria politica define-os como "usuários confiáveis", pelo que não consigo ver como seria prejudicial adicionar uma característica a mais. Sem contar os reversores, com seu rollback e block. - Épico (disc)/(contrib) 04h06min de 9 de janeiro de 2017 (UTC)
@Épico: Não tinha visto a sua resposta. A alteração no grupo reversor não foi ideal, mas visava atender a uma necessidade real, forte e comum a todos os reversores e demais usuários que se dedicam a combater vandalismo, ao contrário do presente caso; como você mesmo apontou, a necessidade é baixa e não é generalizada. RadiX 17h04min de 8 de fevereiro de 2017 (UTC)
@RadiX: Bloquear realmente é uma ação mais extrema, e entendo a necessidade (hoje, uma decisão muito acertada a meu ver) que levou a incorporação dessa permissão aos reversores. E é interessante que mesmo uma ação tão possivelmente danosa tenha registrado poucos casos de abuso. Dito isso, considerando a tão baixa necessidade, baixo risco de mal uso, e a existência de editores interessados em atuar nessa área, não vejo porquê manter o status quo. Se tem gente disposta a voluntariar-se a fazer a tarefa, deixe-os. - Épico (disc)/(contrib) 14h59min de 10 de fevereiro de 2017 (UTC)

Symbol support vote.svg Concordo com a atribuição da função movefile aos autorrevisores, são confiáveis nas suas edições logo também serão nas movimentações de ficheiros. Gonçalo Veiga (discussão) 10h59min de 9 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo. É mais prático isso do que ter que carregar um novo arquivo somente porque errou um caractere do nome. Ou nos casos em que editores não colocam um nome acessível nos ficheiros, como em alguns casos que já pude verificar. Jardel d 12h32min de 14 de janeiro de 2017 (UTC)

Já observei exemplos de nomes inacessíveis em capas de jogos eletrônicos. Imagens como Imagem:7c5b67e47aae82141b9244d9eb1a7d1d 85955468531274712746.jpg ou Imagem:Animorphs shattered reality frontcover large x5GjfDukeXx6IX2.jpg poderiam muito bem ser renomeadas para nomes mais claros sem a necessidade de fazer diversos pedidos em Pedidos/Outros. --Luk3🔔📖 16h33min de 14 de janeiro de 2017 (UTC)

Symbol support vote.svg Apoio a ideia. E não consegui resistir e movi os dois exemplos apresentados pelo Luk3 Hihi Pedro H. diz×fiz 16h48min de 14 de janeiro de 2017 (UTC)

Symbol support vote.svg Apoio Mr. Fulano! 🔔Fale Comigo📩 20h00min de 16 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo -- Darwin Ahoy! 15h45min de 28 de janeiro de 2017 (UTC)

@RadiX: Você possui algum outro ponto de discordância? Caso negativo, poderia você ou algum dos seus colegas burocratas aplicar o claro consenso? - Épico (disc)/(contrib) 14h29min de 8 de fevereiro de 2017 (UTC)

@Épico: Sim, há outro ponto a ser discutido. Se isto vier a ser implementado, a permissão deve ser incluída ao grupo dos eliminadores, pois os grupos de autorrevisor e eliminador são redundantes. RadiX 17h04min de 8 de fevereiro de 2017 (UTC)
Anotado. - Épico (disc)/(contrib) 14h59min de 10 de fevereiro de 2017 (UTC)
Bem visto. Gonçalo Veiga (discussão) 19h23min de 10 de fevereiro de 2017 (UTC)


Número de Primeiros Ministros de Portugal

Saudações, venho por este meio expor algo que, pessoalmente, estou a ver como um problema.

Existe uma série de artigos sobre as personalidades que já ocuparam o cargo de Primeiro-ministro de Portugal... e ao percorrer essas biografias, deparei-me com o seguinte problema:

Em cada um dos artigos, aparece na caixa Info/Político o seguinte:

Há PM's antigos que diz apenas que foram PM's, mais recentemente houve os PM's 112º e 113º, a seguir existiu o 14º (depois do centésimo décimo quarto), e depois desse, todos os mais recentes, também diz apenas que foram PM's...

Não deveria haver um critério para este tipo de identificação? Luís Angelo "Tuga1143 16h50min de 20 de janeiro de 2017 (UTC)

@Tuga1143: O padrão é colocar o ordinal antes do título, que está faltando em Francisco Pinto Balsemão, o 111.º, e inserir no ordinal a ligação para Lista de chefes de governo de Portugal. Segundo a lista, António Guterres foi o 114.º e José Manuel Durão Barroso, o 115.º. Alan Moraes (discussão) 18h28min de 20 de janeiro de 2017 (UTC)
Depende se se conta desde o primeiro chefe de governo, ou do primeiro primeiro-ministro. Antes de 1974 o chefe de governo era denominado presidente do conselho, não primeiro-ministro. Também depende se conta Freitas do Amaral ou não, uma vez que ele nunca foi designado oficialmente como primeiro-ministro. GoEThe (discussão) 08h58min de 23 de janeiro de 2017 (UTC)
Como em tudo, o melhor é arranjar boas fontes para uma numeração e segui-la. GoEThe (discussão) 09h02min de 23 de janeiro de 2017 (UTC)

Symbol comment vote.svg Comentário - Por todos os motivos acima, e para não confundir os leitores (tanto os entendidos na matéria como os leigos), a comunidade deveria decidir sobre isso... por isso gostaria de propor uma espécie de votação e um consenso sobre o assunto.

Numerar os PM's englobando todos os que já existiram

Symbol support vote.svg Apoio Luís Angelo "Tuga1143 14h13min de 23 de janeiro de 2017 (UTC)

Apesar de continuar a ser a favor de uma numeração, reconheço que existe o problema de que, por exemplo, nesta Fonte Mário Soares é referido como o 105º e 112º, e nesta Fonte António Costa é referido como o 13º... na eventualidade de não haver uma fonte fidedigna com uma numeração (ou até mesmo um conjunto de fontes consistente), serei a favor de não se numerar. Luís Angelo "Tuga1143 15h03min de 26 de janeiro de 2017 (UTC)

Symbol support vote.svg Apoio Gonçalo Veiga (discussão) 10h38min de 12 de fevereiro de 2017 (UTC) A Lista de chefes de governo de Portugal já tem a numeração de todos os primeiros-ministros desde o séc. XIX. Basta aplicar o que lá está.

Numerar os PM's contando apenas os que foram nomeados durante a 3ª República

Não numerar (pelo menos sem uma fonte fiável que defina a numeração)

  1. GoEThe (discussão) 10h37min de 25 de janeiro de 2017 (UTC)
  2. Melhor não criar problemas com a numeração. Thex Waxer (discussão) 01h52min de 26 de janeiro de 2017 (UTC)
  3. sem pesquisa inédita Chico Venancio (discussão) 14h25min de 26 de janeiro de 2017 (UTC)
  4. Tetraktys (discussão) 01h42min de 28 de janeiro de 2017 (UTC)
  5. E porque se haveriam de numerar apenas os PMs da República? Qual o motivo de excluir da numeração os anteriores Presidentes do Conselho de Ministros? Havendo controvérsia, é preferível não usar mesmo qualquer numeração. Quando muito, poder-se-á dizer que foi o 13º primeiro ministro da 3ª República, por exemplo, já que isso é objectivo e sem controvérsia.-- Darwin Ahoy! 15h39min de 28 de janeiro de 2017 (UTC)

Symbol comment vote.svg Comentário A Wiki-PT tem a Lista de chefes de governo de Portugal, tudo o que lá está tem fontes. Efectivamente deve-se aplicar (sem mais e por uma questão de padronização) nos artigos de cada chefe de governo a numeração que lá consta. Talvez no caso de António Guterres o lapso tenha sido somente um dígito: 14.º em vez do correcto 114.º Gonçalo Veiga (discussão) 10h31min de 12 de fevereiro de 2017 (UTC)

Chamando o colega @Gameiro:, nosso especialista em primeiros-ministros portugueses e principal editor da respectiva lista. Gonçalo Veiga (discussão) 10h38min de 12 de fevereiro de 2017 (UTC)

Galeria dinâmica

Olá pessoal, por esses dias eu importei uma predefinição da ca.wiki chamada {{Galeria dinâmica}}, que possibilita a inclusão de várias imagens em um artigo sem poluir o layout da página. Mas para o funcionamento da predefinição é necessário ter o gadget ativado em suas preferências. O Pedrohoneto e o !Silent já até tinham colocado o gadget como padrão, mas o He7d3r reverteu alegando que é necessário abrir uma discussão para o adoptar como padrão. Se quiserem saber como a predefinição funcionaria, é só ativar o gadget nas suas preferências e abrir o artigo Laramie Basin. Então gostaria de saber se estão de apoio de colocar o gadget como padrão, permitindo que qualquer usuário possa o ver e possibilitar seu uso em artigos. Mr. Fulano! 🔔Fale Comigo📩 18h47min de 6 de janeiro de 2017 (UTC)

Symbol support vote.svg Concordo !Silent (discussão) 18h50min de 6 de janeiro de 2017 (UTC)
Symbol declined.svg Discordo de qualquer implementação, exatamente pelo mesmo motivo pelo que o uso está interdito na wikipédia inglesa: não funciona com PDFs ou quando se imprime um artigo. A Wikipédia não é lida apenas online. Quintal 18h53min de 6 de janeiro de 2017 (UTC)
Não sabia desse problema. Então, Symbol declined.svg Discordo também. !Silent (discussão) 19h16min de 6 de janeiro de 2017 (UTC)
Exato. Helder 20h57min de 6 de janeiro de 2017 (UTC)
Symbol declined.svg Discordo. Se a intenção é mostrar várias fotos, melhor fazer uma ligação para o Commons ou mesmo criar uma página própria na Wikipédia para expor as fotos. Ademais, acho a Wikipédia lusófona "enfeitada" demais. Precisamos de mais um penduricalho? —Alan Moraes (discussão) 19h02min de 6 de janeiro de 2017 (UTC)
Symbol declined.svg Discordo de carregar (por padrão) o código de mais este gadget para todos os usuários (registrados ou não), pelos motivos documentados na Wikipédia em inglês. Helder 20h57min de 6 de janeiro de 2017 (UTC)
Symbol declined.svg Discordo pelos motivos já apresentados acima. Pedrohoneto Diz·Fiz 21h18min de 6 de janeiro de 2017 (UTC)
Symbol comment vote.svg Comentário Não seria possível adicionar algum código que na hora de exportar para PDF ou de imprimir, simplesmente iniba a predefinição? Mr. Fulano! 🔔Fale Comigo📩 23h15min de 6 de janeiro de 2017 (UTC)
É uma possibilidade, fazer com que o script não execute ao realizar a ação de imprimir uma página. Quanto ao PDF, não sei ao certo. !Silent (discussão) 13h29min de 7 de janeiro de 2017 (UTC)
Já perguntei ao um usuário da ca.wiki responsável pela predefinição, que lá é usada em artigos, sobre uma possível solução. Mr. Fulano! 🔔Fale Comigo📩 13h44min de 7 de janeiro de 2017 (UTC)
Se isso fosse implementado dessa forma, resolveria o problema dos PDFs/impressão, mas criaria outro problema ainda pior. Os artigos, pelo menos a partir de um certo nível de qualidade, são desenhados e estruturados para que a posição das imagens esteja de acordo com o texto e o layout seja equilibrado. Isto por si só já é difícil de conseguir mas, uma vez conseguido, o que funciona online também funciona impresso ou em PDF. O que é aqui proposto vai introduzir, na prática, dois layouts concorrentes: um online e um para impressão. Dessa forma, tornar-se-ia impossível trabalhar. Quintal 14h32min de 7 de janeiro de 2017 (UTC)
Eu até gosto da ideia mas perante os factos apresentados pelo Antero é preciso medir com cuidado os prós e os contras. Gato Pretotrovai-me! 10h01min de 8 de janeiro de 2017 (UTC)
Symbol neutral vote.svg Neutro Me parece trivialmente fácil corrigir os problemas com outras mídias. Basta inserir a regra display: none; num elemento <style media="all"> a ser cancelado por outra regra num elemento <style media="screen">. Att --Usien6 16h39min de 9 de janeiro de 2017 (UTC)

@!Silent, Antero de Quintal, He7d3r, Pedrohoneto, Alan Moraes, Gato Preto, e Usien6: Já fiz as modificações, agora, quando a página for impressa ou exportada para PDF, a única imagem a aparecer será a primeira. Como essa predefinição não é usada ainda, o editor poderá adaptá-la ao seu artigo e não terá problemas com a versão impressa. Mr. Fulano! 🔔Fale Comigo📩 14h47min de 28 de janeiro de 2017 (UTC)

Mas aí quando for imprimir ou exportar não aparecerá as outras imagens, ou seja, perderá uma parte do conteúdo. !Silent (discussão) 14h59min de 28 de janeiro de 2017 (UTC)
Symbol declined.svg Continuo discordando de ser habilitada por padrão. Quem quiser a funcionalidade pode acioná-la nas preferências. Alan Moraes (discussão) 15h01min de 28 de janeiro de 2017 (UTC)
(Conflito) @!Silent: A minha ideia é de que seja adicionadas apenas imagens complementares, tipo fotos de uma cidade, que não sejam tão necessárias, mas que seria uma boa adicioná-las. E se fosse necessário que todas as imagens apareçam, é só usar a predefinição {{Imagens múltiplas}}. Mr. Fulano! 🔔Fale Comigo📩 15h05min de 28 de janeiro de 2017 (UTC)
@Alan Moraes: A questão é, se não for habilitada como padrão a predefinição não poderá ser usada. Mr. Fulano! 🔔Fale Comigo📩 15h33min de 28 de janeiro de 2017 (UTC)
@Mr. Fulano: Então sinto muito, mas a predefinição não é necessária porque uma sequência de imagens vai piorar a acessibilidade da Wikipédia. Alan Moraes (discussão) 15h38min de 28 de janeiro de 2017 (UTC)
@Alan Moraes: A predefinição será bastante útil em artigos pequenos, que precisam imagens, mas não possui muito espaço. E essa predefinição ainda pode ser usada em páginas do projeto e de usuário. Mr. Fulano! 🔔Fale Comigo📩 15h47min de 28 de janeiro de 2017 (UTC)
@Mr. Fulano: E o que isso tem a ver com acessibilidade? Alan Moraes (discussão) 15h49min de 28 de janeiro de 2017 (UTC)
@Alan Moraes: Falando a respeito da acessibilidade, o que a predefinição vai atrapalhar. Segundo com que está escrito, as imagens precisam ter uma legenda, e se possível uma legenda alternativa (na qual posso adicionar se quiserem), então está cumprindo com o que está escrito lá. Mr. Fulano! 🔔Fale Comigo📩 15h57min de 28 de janeiro de 2017 (UTC)
@Mr. Fulano: Ter uma predefinição que vai jogar várias e várias imagens em um artigo em nada vai ajudar na leitura do artigo por um cego. Imagens devem ser usadas com parcimônia, pois isto é uma enciclopédia e não galeria de imagens. Se o caso é de haver várias imagens no Commons, faça um link para elas. Alan Moraes (discussão)
@Alan Moraes: Mas não são apenas deficientes visuais que irão ler os artigos. E sim, não se deve exagerar nas imagens, mas a exemplos práticos de quando essa predefinição poderá ser usada, que é em casos de artigos sobre espécies com características muito diferentes entre indivíduos, e nesses casos seria uma boa ideia ter várias imagens mostrando os tipos de indivíduos. Mr. Fulano! 🔔Fale Comigo📩 16h18min de 28 de janeiro de 2017 (UTC)
@Mr. Fulano: Não, o argumento correto é pessoas com deficiências usam a Wikipédia, inclusive cegos —pense nelas. Pior, o argumento que você usou vai justamente de encontro à proposta da predefinição. Se eu quero comparar várias espécies, o que eu não vou querer de jeito nenhum é olhar as imagens uma por uma e ficar correndo pra frente e para trás para comparar as imagens; muito melhor é ver todas as imagens de uma vez só para poder compará-las. Sua intenção foi boa, mas a proposta é ruim. Alan Moraes (discussão) 16h31min de 28 de janeiro de 2017 (UTC)

Citação: Já fiz as modificações, agora, quando a página for impressa ou exportada para PDF, a única imagem a aparecer será a primeira. Isso não é uma correção. Esse é precisamente o motivo pelo qual as pessoas discordaram. A impressão ou a criação de um PDF devem reunir todos os elementos do artigo. Quintal 17h45min de 28 de janeiro de 2017 (UTC)

Predefinição para partidos

Criei a predefinição {{Partidobr}} para simplificar e padronizar as cores dos partidos políticos brasileiros que possuam cadeiras parlamentares, facilitando a utilização de uma predefinição única que possa ser usada em diversos artigos que necessitem da contextualização das cores para o entendimento, como por exemplo o artigo Congresso Nacional do Brasil. O meu interesse em ter feito essa nova predefinição foi, principalmente, padronizar e organizar a Infobox {{Info/Parlamento}} dos artigos Senado Federal e Câmara dos Deputados, assim como as cores na imagem do Commons que representam a atual composição do Congresso Nacional.

Posteriormente, a predefinição foi proposta para eliminação rápida com as alegações de que "não foi discutida" a criação e que "duplica um tópico existente", citando o formato /meta/cor, uma série de predefinições separadas que não facilitavam seu uso nos artigos e nem eram amplamente utilizadas (1). Com isso venho propor a substituição das predefinições formato /meta/cor, dos partidos brasileiros, para esta nova predefinição que é mais simples e pode ser facilmente adicionada, basta escrever a sigla do partido, exemplo: {{Partidobr|SIGLA}}.

Como é possível observar no código-fonte das edições anteriores nas páginas do Senado (2) e da Câmara (3), as predefinições /meta/cor nem sequer são utilizadas e as cores usadas nos partidos são diferentes entre as duas páginas, não existindo qualquer padronização. Isso demonstra que os editores consideram mais fácil utilizar o próprio código de cor ao invés da extensa e complicada /meta/cor. A situação era ainda pior na página do Congresso (4), não havia nem mesmo os códigos de cores indicando os partidos representados na imagem, algo que poderia facilmente ser adicionado com a nova predefinição.

Em oposição as /meta/cor, a predefinição {{Partidobr}} também permite que todos os partidos fiquem reunidos em apenas uma página, o que possibilita uma documentação bastante detalhada sobre os códigos das cores utilizadas, facilitando a atualização das imagens do Senado e da Câmara no Commons através do ParliamentDiagram, bastando copiar e colar o código de cor na ferramenta.

Gostaria de saber a opinião da comunidade para que a nova predefinição possa ser implantada de forma consensual. Vinctus D 18h26min de 31 de janeiro de 2017 (UTC)

Symbol declined.svg Discordo totalmente Essa estapafúrdia proposta viola princípios elementares, tanto do enciclopedismo, quanto da tecnologia da informação. Pretende-se manter dados em duplicidade e finalizados num espaço geográfico e temporal extremamente finitos (Sexta República Brasileira). A troco de que ?? Preguiça de aplicar o modelo já existente ?? Ora! Nec pedes nec caput. Anote-se que o inexperiente propositor está tão alheio ao que propõe que sequer se deu conta de que certas siglas partidárias já foram utilizadas por mais do que um partido 47883732]47883743]47883749]47883758]47883760]47883772]47883775] nesse minúsculo espaço temporal que pretende privilegiar. Sem qualquer discussão, nem mesmo prenúncio, desatinou a alterar infocaixas em massa até que, quando confrontado, tentou inverter o ônus da prova contra quem resistia à transloucada mudança.47877528] Irritado, recusou contribuições positivas alegando que estariam "cheias de erros."47885936] Que erros, cara-pálida ?? O Brasil não é o único país do mundo, nem é o presente o único tempo da história. Vide recomendação Status quo e as "AEDE" análogas TEMPO e LUSO --Usien6 21h04min de 31 de janeiro de 2017 (UTC)

Symbol declined.svg Discordo pelos mesmos motivos apresentados pelo Usien6. Oxe (discussão) 01h23min de 7 de fevereiro de 2017 (UTC)

Symbol support vote.svg Apoio Achei interessante essa criação de predefinição, pois assim ajuda uma melhor compreensão. Vitor MazucoMsg 22h18min de 31 de janeiro de 2017 (UTC)

Symbol support vote.svg Apoio Muito interessante e vem para facilitar o trabalho. Igor G.Monteiro (discussão) 21h43min de 12 de fevereiro de 2017 (UTC)

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)

Symbol support vote.svg 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)

Symbol comment vote.svg 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)

Symbol comment vote.svg 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. Edilson Vinentefale comigo 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)

Symbol declined.svg 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)

Symbol comment vote.svg 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)

Symbol declined.svg 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)

Symbol comment vote.svg 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)

Symbol support vote.svg 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)

Symbol question.svg 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.—Teles«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.—Teles«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 Symbol declined.svg 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)

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: Symbol declined.svg 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 Symbol neutral vote.svg 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)

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)

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. Edilson Vinentefale comigo 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. Edilson Vinentefale comigo 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 Symbol support vote.svg 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. Symbol support vote.svg 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. Edilson Vinentefale comigo 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. Edilson Vinentefale comigo 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)

Symbol support vote.svg 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. Edilson Vinentefale comigo 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. Symbol support vote.svg 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)

Symbol declined.svg 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)
@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. Edilson Vinentefale comigo 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 Symbol support vote.svg Concordo com a proposta no geral, mas Symbol declined.svg 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. :) Edilson Vinentefale comigo 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". Edilson Vinentefale comigo 15h10min de 12 de fevereiro de 2017 (UTC)

Outras propostas

Symbol support vote.svg 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)

Symbol comment vote.svg 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.» Eca! 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. Edilson Vinentefale comigo 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. Edilson Vinentefale comigo 15h42min de 12 de fevereiro de 2017 (UTC)
Darwinius, Chicocvenancio, conseguem ter mais uma melhor visualização da proposta, caros colegas? Edilson Vinentefale comigo 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? Edilson Vinentefale comigo 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. Symbol support vote.svg 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. Edilson Vinentefale comigo 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 Symbol support vote.svg 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 Symbol support vote.svg Concordo com a proposta nesse formato. Chico Venancio (discussão) 17h21min de 12 de fevereiro de 2017 (UTC)
Eu acho pertinente e Symbol support vote.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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) 

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 é No sign.svg 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)

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: Symbol support vote.svg 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: Symbol support vote.svg Concordo
. . . . . . . . . . . -- Chê Rapidim (discussão) 07h50min de 11 de fevereiro de 2017 (UTC)
@Jonas AGX: Symbol support vote.svg 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
Symbol support vote.svg 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, Symbol support vote.svg 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)
Symbol support vote.svg Concordo, sem dúvidas. RadiX 01h42min de 13 de fevereiro de 2017 (UTC)
Symbol support vote.svg Concordo. !Silent (discussão) 11h30min de 13 de fevereiro de 2017 (UTC)
Symbol support vote.svg Concordo. Helder 12h06min de 13 de fevereiro de 2017 (UTC)
Symbol support vote.svg 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)
Symbol support vote.svg 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, Por favor, ajude nas traduções para o seu idioma!

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)

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)

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

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:

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 mil1570000 (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)
Symbol support vote.svg 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)
Symbol support vote.svg Apoio, padronização sempre é bem vinda. --Luk3🔔📖 21h56min de 13 de fevereiro de 2017 (UTC)
Symbol support vote.svg 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 15700001570000 (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 15700001 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)


Symbol support vote.svg 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)


Symbol comment vote.svg 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)

Symbol support vote.svg 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)

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)

Symbol support vote.svg 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: 2000 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol declined.svg 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)

Symbol comment vote.svg 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)

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)

Symbol support vote.svg 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)

Symbol support vote.svg 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 Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg Apoio com as cláusulas definidas acima. ♪ Alberto79 ♪ Msg-Contributions 21h25min de 19 de fevereiro de 2017 (UTC)

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

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

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

Symbol support vote.svg 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)

Symbol support vote.svg 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)

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. Edilson Vinentefale comigo 17h40min de 20 de fevereiro de 2017 (UTC)

Symbol support vote.svg 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. Edilson Vinentefale comigo 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 Edilson Vinentefale comigo 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. Edilson Vinentefale comigo 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)

Symbol support vote.svg 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)


Geral

Secção geral da Esplanada ▲ Anúncios | ▲ Propostas | ◄ Geral | início
Esta secção é utilizada para todo tipo de anúncios relacionados com a Wikipédia em português de forma direta ou indireta.
clique aqui para adicionar um novo tópico na secção geral


Gadget para automatizar a criação e o encerramento de candidaturas para artigo bom ou destaque

Três anos depois de iniciar a criação desse gadget, estou disponibilizando uma versão de testes (que já deveria ter postado a meses). Por enquanto, o gadget apenas cria candidaturas para artigo bom ou destaque (ou seja, lista e tópicos estão fora por enquanto), assim como ainda não está sendo possível encerrar candidaturas.
Peço que se possível, pro pessoal da área das EADs ativar o gadget e testá-lo. Em caso de bugs ou sugestões, reportar aqui ou na discussão do gadget
Pra ativar bastar ir em Especial:Preferências#mw-prefsection-gadgets na parte "Edição" (no final) e marcar ContentFeatured. !Silent (discussão) 23h47min de 10 de janeiro de 2017 (UTC)

@!Silent: parabéns pelo empenho. --Joalpe (discussão) 23h52min de 10 de janeiro de 2017 (UTC)
Legal! —Alan Moraes (discussão) 00h04min de 11 de janeiro de 2017 (UTC)
Parabéns! Fico feliz em ver que as mudanças por aqui são lentas mas são constantes, isso gerava muitas discussões antigamente. Thex Waxer (discussão) 18h26min de 22 de janeiro de 2017 (UTC)
!Silent parabéns por essa automação. Poderia também fazer automação de encerramento de eliminações, baseado na data. - Elilopes DEBATE 18h27min de 31 de janeiro de 2017 (UTC)
@Elilopes Mas já não existe o gadget para encerrar PEs? !Silent (discussão) 20h23min de 12 de fevereiro de 2017 (UTC)

Botão "Citar suas fontes"

Qual a finalidade do "Citar suas fontes: <ref></ref>" encontrado no editor?

(parte inferior ao lado de "Assinar em páginas de discussão: ~~~~")

Não segue a recomendação de citação de livro de estilos. Muitos usuários estão usando esse botão nos artigos novo, deixando as referencias incompletas. - Elilopes DEBATE 17h59min de 31 de janeiro de 2017 (UTC)

Este código está no MediaWiki:Edittools para que os interessados possam se poupar o trabalho de digitar estes caracteres manualmente.Helder 19h10min de 31 de janeiro de 2017 (UTC)
A extensão CharInsert tem o único propósito de inserir caracteres na área de texto. Não tem nada que ver com o Livro de estilo. Att --Usien6 21h14min de 31 de janeiro de 2017 (UTC)
O problema: A extensão CharInsert está sendo muito usada na criação de artigos novos, criando referências incompletas. - Elilopes DEBATE 16h52min de 1 de fevereiro de 2017 (UTC)
Mas é melhor que usem as tags <ref></ref> do que não usem nem isso, então me parece culpa do link, mas apenas desconhecimento do livro do estilo por parte dos usuários. Helder 17h48min de 1 de fevereiro de 2017 (UTC)
o problema não é com a predefinição usada, o problema é com o editor que as usa. a predef simples <ref></ref> permite inserir toda a informação necessária, usando qualquer estilo de citação que quiser. Tetraktys (discussão) 22h49min de 3 de fevereiro de 2017 (UTC)
Com o He7d3r e o Tetraktys. Ninguém é forçado a saber todas as subtilezas e sofisticações do nosso sistema de referenciação, que chega a ser extremamente complexo. A <ref></ref> permite a colocação de uma referência de modo rápido e em texto corrido, que pode mais tarde ser adaptada a um dos sistemas mais sofisticados que usamos aqui. Se a referência está sendo colocada de modo incompleto e sem conserto fácil (por exemplo, livros sem página, só com o título), o editor deve ser chamado à atenção. Mas esse atalho deve continuar aí, como está.-- Darwin Ahoy! 20h34min de 5 de fevereiro de 2017 (UTC)
Entendido Darwinius, mesmo assim farei uma sugestão. Substituir por uma janela modal (programação) com um pequeno guia sobre citação, por exemplo: "Para inserir uma citação básica use: <ref>{{citar web|url= |titulo= |autor= |publicado= }}</ref>. Para saber mais acesse Guia de citação avançada". Ensinando e também evitando repreender vários editores. - Elilopes DEBATE 17h39min de 7 de fevereiro de 2017 (UTC)
A extensao nao oferece essa possibilidade (nem mesmo temos como exibir um texto diferente do que será inserido ao clicar). Helder 19h57min de 7 de fevereiro de 2017 (UTC)
He7d3r a MediaWiki pode ter algum script de lightbox parecido com sandboxLink e slimboxThumbs. - Elilopes DEBATE 16h33min de 8 de fevereiro de 2017 (UTC)
Oi @He7d3r: @Usien6: @Tetraktys: @Darwinius: podia ser adicionado um popup com um exemplo/recomendação de referência básica (por exemplo a mais usada {{citar web}}). - Elilopes DEBATE 17h54min de 15 de fevereiro de 2017 (UTC)

Popup

O texto seguinte foi movido de: Wikipédia:Café dos programadores#Sugestão: popup com referência básica

No "editor visual"MediaWiki:Edittools podia substituir o botão "Citar suas fontes: <ref></ref>" por um popup com um exemplo de referência básica (mais usada {{citar web}}) para facilitar e ensinar os novos colaboradores.

O citar fontes apenas insere no texto <ref></ref>, formando referencias incompletas (não recomendadas). - Elilopes DEBATE 18h18min de 15 de fevereiro de 2017 (UTC)

@Elilopes: Peço desculpas, mas não encontrei em nenhum lugar, enquanto editava um artigo pelo Editor Visual, botão que sugira a inserção de fontes por <ref></ref>. Aqui, quando clico no botão VisualEditor - Toolbar - citoid citepong derivative.png Citar, aparece um prompt para que selecione entre os métodos de referência "Automática", "Manual" ou "Reutilizar". Pelo método "Manual" é possível selecionar uma dentre três predefinições, ou então adicioná-la em sua forma básica. --ArgonSim (discussão) 18h47min de 15 de fevereiro de 2017 (UTC)
Symbol comment vote.svg Comentário Imagino que esteja se referindo ao editor de código-fonte, na verdade, onde se lê Citação: Assinar em páginas de discussão: ~~~~ Citar suas fontes: <ref></ref> logo abaixo da janela de edição. --ArgonSim (discussão) 19h05min de 15 de fevereiro de 2017 (UTC)
@ArgonSim: eu que peço desculpa. Sim, é no "editor de código fonte" o botão "Citar suas fontes:...". - Elilopes DEBATE 19h16min de 15 de fevereiro de 2017 (UTC)


Errata: No "Editor de código fonte" (WikiEditor)MediaWiki:Edittools podiam substituir o botão "Citar suas fontes: <ref></ref>" por um popup com um exemplo de referência básica (mais usada {{citar web}}) para facilitar e ensinar os novos colaboradores.

O citar fontes apenas insere no texto <ref></ref>, formando referencias incompletas (não recomendadas). - Elilopes DEBATE 19h16min de 15 de fevereiro de 2017 (UTC)

Symbol support vote.svg Concordo que o editor de código-fonte seja enxugado, removendo funções duplicadas e melhorando as que forem mantidas. Minha dúvida é até que ponto o MediaWiki permite que mudanças desse gênero sejam feitas. Note como os gadgets Ferramentas de referências e ProveIt, desativados por padrão, são inegavelmente superiores e mais intuitivos que a simples adição de <ref></ref>. --ArgonSim (discussão) 19h32min de 15 de fevereiro de 2017 (UTC)
O texto acima foi movido de: Wikipédia:Café dos programadores#Sugestão: popup com referência básica
Como indiquei anteriormente, o botão não é parte do Editor Visual nem do WikiEditor, mas sim da lista que definimos em MediaWiki:Edittools.
Por outro lado, se encontrarem funções duplicadas no WikiEditor, devem reportar diretamente no Phabricator, onde poderá ser analisada pelos desenvolvedores da extensão. Helder 20h47min de 15 de fevereiro de 2017 (UTC)
@Elilopes: você está batendo em gato morto. já foi esclarecido que a predef simples permite a inclusão de toda a informação necessária. se o usuário deixar o trabalho pela metade não é culpa da formatação. insistir no contrário é WP:POV. aliás, o modelo citar web nem sempre é completado, já vi uma infinidade de casos em que mesmo usando essa predef a ref é deixada incompleta. Tetraktys (discussão) 21h29min de 15 de fevereiro de 2017 (UTC)
@Tetraktys: relaxa é apenas uma sugestão. - Elilopes DEBATE 14h37min de 20 de fevereiro de 2017 (UTC)
@He7d3r: entendi, farei essa sugestão no Phabricator. Obrigado pela dica. - Elilopes DEBATE 14h37min de 20 de fevereiro de 2017 (UTC)

Guia no editor

Outra sugestão sobre o tema referências: No wikinoticias, ao adicionar uma notícia o editor é aberto com um pequeno guia de edição, poderiam usar este método aqui na enciclopédia quanto a referências, infobox e categorias.

  • "<!-- Abaixo, escolha um dos dois exemplos para data e local. Após escolher, remova-as e a esse texto. -->"
  • "{{origem|data={{subst:#time:j}} de {{subst:lc:{{subst:#time:F}}}} de {{subst:#time:Y}}|local=}}"

- Elilopes DEBATE 14h37min de 20 de fevereiro de 2017 (UTC)

Já existe o WP:Artigos novos/Guia-Introdução, onde é utilizada a Predefinição:Artigos novos guia. No entanto, depois do feedback recebido em WP:Esplanada/geral/Páginas molde (22fev2016), criou-se um filtro para detectar casos em que é usado de forma inapropriada. Helder 16h40min de 21 de fevereiro de 2017 (UTC)
@He7d3r: ao abrir o editor para criar um novo artigo poderia ao menos exibir os aviso (semelhante oa wikinotícias):
  • "<!-- Esta criando um artigo novo. Para mais informações sobre formatação e qualidade do texto, acesse o [[WP:NOVO|Guia-Artigos Novos]]. -->"
  • "<!-- Adicione referências ao texto. Para mais informações sobre, acesse [[WP:CITE|Guia-Citação]]. -->". - Elilopes DEBATE 18h02min de 22 de fevereiro de 2017 (UTC)
Não vejo motivo para colocar na última etapa um link para a primeira página do guia, que foi a que levou o usuário até a janela de edição. Desde o começo do processo já fica claro que ele está criando um artigo novo. sendo informado sobre o fato de estar criando um novo artigo. E a janela já vem preenchida com um exemplo que contém referências, e que diz explicitamente "Todo artigo deve ter referências ou fontes para comprovar a informação". Helder 18h07min de 22 de fevereiro de 2017 (UTC)
@He7d3r: me enganei. acabei de ver que existe um mini guia no editor de novo artigo. Mas não tem sobre referências. - Elilopes DEBATE 12h46min de 24 de fevereiro de 2017 (UTC)

Script

Existe script para detectar referências sem título em artigos novos? - Elilopes DEBATE 12h46min de 24 de fevereiro de 2017 (UTC)

Teria exemplos do que procura? Provavelmente poderá encontrar pesquisando por algo como -insource:TÍTULO insource:/\<ref\>/. Helder 14h55min de 24 de fevereiro de 2017 (UTC)

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)

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)

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. Symbol support vote.svg 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)

Symbol oppose vote.svg 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 MazucoMsg 15h20min de 10 de fevereiro de 2017 (UTC)

Symbol comment vote.svg 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)

Symbol comment vote.svg Comentário @Luk3: pode ser, boa ideia! Vitor MazucoMsg 20h22min de 10 de fevereiro de 2017 (UTC)

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)

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

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)



Rodapé da Esplanada ▲ Anúncios | ▲ Propostas | ▲ Geral | início