Wikipédia:Esplanada/propostas

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
▼ Ir para o fim da página ▼
Boas-vindas à se(c)ção propostas da Esplanada!
Esta secção é utilizada para discutir novas ideias e propostas para saber a opinião da comunidade. Pode ser sobre a alteração ou criação de predefinições, páginas, políticas, etc. Tenha em mente que as decisões da comunidade são baseadas no método do consenso. Veja também as mudanças recentes nas esplanadas.


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)

Retomada dos WikiProjetos

Olá, pessoal.

Coloco nesse tópico, a proposta de criações de WikiProjetos, já que apenas 1 está ativo atualmente. Além da volta das atividades de WikiProjetos abandonados. Os WikiProjetos são muito importantes para o site, já que é uma força-tarefa (digamos assim) para ajudar em um certo tipo de artigos, e é bom para o crescimento da Wikipédia.

Além disso, os projetos são muito importantes para atualizar portais, através de votações dos membros do projeto relacionado ao portal. Porém, trago algumas propostas para vocês:

1- Se aprovada, a retomada será realizada com 5 projetos mais importantes (os que possuem grande quantidade de artigos na Wikipédia). E ao longo do tempo, outros serão retirados do arquivo.

2- Se aprovada, a retomada será realizada com a tirada do arquivo dos WikiProjetos, com a retomada também do conselho como regulamentador.

3- Se aprovada, a retomada será realizada com o acompanhamento de um grupo de trabalho temporário, que trabalhará em um método de retomar os projetos.

Agora, é com vocês, se aprovam ou não. JackCrazy5 Fale Comigo! 14h15min de 24 de março de 2017 (UTC)

Symbol support vote.svg Concordo É preciso reunir membros com afinidades com o mesmo assunto. Igor G.Monteiro (discussão) 16h36min de 24 de março de 2017 (UTC)
Symbol support vote.svg Concordo, mas a questão não é só "aprovar ou não", deve a ver uma colaboração por parte da comunidade... JackgbaCall 11h41min de 25 de março de 2017 (UTC)
Não acho necessário preciso votar para começar a fazer atividades que se encaixem no escopo de um determinado wikiprojeto. E quando houver atividades e participantes em número razoável, podem simplesmente marcar o projeto como ativo. Helder 12h01min de 26 de março de 2017 (UTC)
Symbol support vote.svg Concordo plenamente. Os wikiprojetos são ótimas formas de manejar o funcionamento de diversas páginas, organizando-se por temas. Além de aumentar o entrosamento entre editores. É lamentável que uma ótima ideia de gestão de páginas esteja passando por essa crise. Armagedon2000 msg 00h10min de 31 de março de 2017 (UTC)
Symbol declined.svg Discordo A proposta de criação de novos wikiprojetos vai na contramão dos recentes esforços para extinguir e fundir inativos. Att --Usien6 19h26min de 3 de abril de 2017 (UTC)
Quais seriam estes recentes esforços? A Wikipédia precisa sim da criação dos novos WikiProjetos. JackCrazy5 Fale Comigo! 22h02min de 13 de abril de 2017 (UTC)
@JackCrazy5: Alô. Queira ler a seguinte discussão de 2012: Wikiprojetos 2.0 (23nov2012), que estabeleceu as bases para o atual uso (e não uso) dos wikiprojetos. - Épico (disc)/(contrib) 03h39min de 17 de abril de 2017 (UTC)

Parar de definir período de inelegibilidade de pedidos de desnomeação de administração

Simplesmente, quando é iniciado um pedido de desnomeação é incluída uma secção onde se decide qual o período no qual um usuário não se pode voltar a candidatar a administrador. Invariavelmente, as posições aí são extremadas entre 3 meses e 3 anos. Parece-me inútil que tal seja definido, pois ninguém pode prever o futuro. As situações são diversas e é possível que baste um dia para que situações que levaram a um certo caso deixem de existir ou é possível que mesmo passado 30 anos isso não aconteça. Em resumo, tais períodos são inúteis e punitivos. Em 2009, foi decidido retirar o período de inelegibilidade para desnomeados por absentismo, e na verdade o que proponho agora também teve apoio na altura, mas não foi implementado. GoEThe (discussão) 14h26min de 3 de abril de 2017 (UTC)

Symbol support vote.svg Concordo. As situações são variáveis e um tempo definido por meio de uma regra não faz sentido. Fronteira diga - veja 14h39min de 3 de abril de 2017 (UTC)
Symbol support vote.svg Concordo em remover essas opções e fixar um período de trinta dias de inexibilidade. !Silent (discussão) 16h44min de 3 de abril de 2017 (UTC)
Symbol support vote.svg Concordo Como o propositor já bem observou, a votação de prazo, em regra, não passa duma mera repetição da votação principal. Att --Usien6 19h31min de 3 de abril de 2017 (UTC)
Symbol support vote.svg Concordo a comunidade e o próprio candidato desnomeado devem avaliar em cada caso quando é oportuno uma recandidatura. --Hume42 00h14min de 4 de abril de 2017 (UTC)
Symbol support vote.svg Concordo. Fóssil do tempo das "desnomeações". O usuário deve poder realizar um novo pedido assim que o problema que resultou na perda da permissão tenha sido sanado. Cabe à comunidade decidir, caso a caso, se o tempo transcorrido é apropriado. RadiX 00h45min de 4 de abril de 2017 (UTC)
Symbol support vote.svg Concordo a comunidade deve avaliar quando de uma recandidatura. Ricardo Ferreira de Oliveira Diga 11h14min de 4 de abril de 2017 (UTC)
Symbol support vote.svg Concordo Não é necessário um prazo pré determinado pois tudo muda. Igor G.Monteiro (discussão) 16h26min de 5 de abril de 2017 (UTC)
Symbol support vote.svg Concordo A comunidade que vai decidir se o usuário merece ser aprovado novamente num pedido de aprovação. WikiFer msg 22h51min de 5 de abril de 2017 (UTC)
Symbol support vote.svg Concordo Melhor deixar sem período definido, pois as razões que levaram a desnomeação podem ser resolvidas antes do tempo previsto. --Pap@ Christus msg 01h08min de 6 de abril de 2017 (UTC)
Symbol support vote.svg Concordo, requisito inútil e meramente punitivo. Já havia concordado com a sua abolição em 2009, e mantenho a minha posição.-- Darwin Ahoy! 07h08min de 8 de abril de 2017 (UTC)
Symbol declined.svg Discordo. Da mesma forma que um pedido malsucedido de torna um editor inelegível por três meses, penso que deva haver igual carência para editor que perdeu o estatuto poder recuperá-lo. Se não for assim, um editor que perdeu as ferramentas com resultado apertado poderia pedir novamente as ferramentas depois de uma semana, após fazer campanha para obter os votos que precisa. Oxe (discussão) 11h21min de 9 de abril de 2017 (UTC)
Isso não faz qualquer sentido. Se um editor perdeu as ferramentas com um resultado apertado (no máximo com 49% de aprovação) como é que na semana seguinte pode estar à espera de obter 75% de aprovação? Quintal 14h34min de 9 de abril de 2017 (UTC)
Solicitações e conluios off-wiki. Oxe (discussão) 20h49min de 9 de abril de 2017 (UTC)
Portanto, na semana da votação de desnomeação não conseguiria solicitar nem para chegar aos 50% de votos. Mas na semana seguinte conseguiria solicitar para chegar aos 75%!!! Totalmente lógico. Quintal 20h55min de 9 de abril de 2017 (UTC)
Porque é totalmente lógico permitir um editor, que acabou de perder o estatuto, solicitá-lo de volta uma semana depois. Oxe (discussão) 22h20min de 9 de abril de 2017 (UTC)
Symbol support vote.svg Concordo contudo penso deve ser estabelecido um prazo mínimo de inelegibilidade. Vanthorn® 01h22min de 12 de abril de 2017 (UTC)

O texto que aqui estava foi movido para: Wikipédia Discussão:Esplanada/propostas/Parar de definir período de inelegibilidade de pedidos de desnomeação de administração (3abr2017)

Mudança menor na política de administradores

A seção remoção automática por absenteísmo, da política de administradores, diz:

No entanto, como é possível notar, este trecho não estabelece qual é o procedimento que deve ser feito nestes casos. Lembro que a última reatribuição do estatuto de administrador, acionada em virtude desta cláusula, causou polêmica, a meu ver pela falta de clareza no processo. Mais recentemente, uma situação semelhante ocorreu no Commons, quando um burocrata reatribuiu o estatuto de administrador logo após o editor solicitar. Isso causou tamanha polêmica a ponto do burocrata responsável pela ação renunciar. Para evitar novas polêmicas do tipo, impedir ações unilaterais que possam ser contestadas, e deixar o processo mais claro, proponho a modificação deste trecho para:

Aguardo outras opiniões. Érico (fale) 03h33min de 8 de abril de 2017 (UTC)

Symbol support vote.svg Concordo, procedimento fácil de fazer e eficaz, e assegura a transparência do processo.-- Darwin Ahoy! 07h03min de 8 de abril de 2017 (UTC)

Symbol question.svg Pergunta Isto aplica-se também aos eliminadores?-- Darwin Ahoy! 07h03min de 8 de abril de 2017 (UTC)

@Darwinius: Aparentemente e, para a minha surpresa, não há nada na política de eliminadores que fala sobre isso (ou há?). Eu iniciei um tópico no café dos burocratas antes de propor alguma modificação / inclusão na política de eliminadores. Érico (fale) 07h06min de 8 de abril de 2017 (UTC)

Symbol support vote.svg Concordo esclarece o procedimento e deixa-o sem ambiguidades. Também concordo com a implementação do mesmo procedimento no caso dos eliminadores. Gato Pretotrovai-me! 09h06min de 8 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário. Deveria ser "em um período máximo de cinco dias" em vez de "em um período mínimo de cinco dias". Sobre o prazo, acho que deveria ser de sete dias, como é praxe da maioria dos processos aqui e porque também permite que o pedido seja contestado em qualquer dia da semana, uma vez que alguns editores só acessam a Wikipédia em determinados dias. Alterei a proposta para deixá-la mais clara e precisa:

O editor que teve o estatuto de administrador removido por inatividade poderá solicitá-lo novamente a qualquer momento. O editor deverá realizar o pedido em Wikipédia:Pedidos a burocratas e depois publicizá-lo em Wikipédia:Esplanada/anúncios. Caso o pedido não seja contestado em algum destes locais até sete dias depois de postado na Esplanada, o estatuto de administrador será devolvido ao editor. Caso seja contestado, a solicitação será cancelada e o editor deverá iniciar um novo pedido de aprovação.

Saudações. Oxe (discussão) 15h51min de 8 de abril de 2017 (UTC)

Discordo. Mudar para "um período máximo" trará tantos problemas como agora, pois permite que o burocrata conceda o estatuto a qualquer momento. É preciso ter um período mínimo. Mas não me oponho quanto aos sete dias. Érico (fale) 17h18min de 8 de abril de 2017 (UTC)

Symbol support vote.svg Concordo com a proposta e com as alterações feitas pelo Oxe, com algumas ressalvas.

Não deve ser obrigatório aguardar sempre pelos sete dias para devolver o estatuto ao usuário. Se houver contestação nesse ínterim (sete dias), por outro lado, o estatuto deve ser devolvido, e o interessado deve abrir um pedido de aprovação.

Contraproposta:

O editor que teve o estatuto de administrador removido por inatividade poderá solicitá-lo novamente a qualquer momento. O pedido deverá ser realizado em Wikipédia:Pedidos a burocratas e, na sequência, divulgado em Wikipédia:Esplanada/anúncios. Caso seja aprovado e houver contestação em algum destes locais em até sete dias a partir da reinclusão do usuário no grupo de administradores, o estatuto de administrador será removido do editor, e este poderá iniciar um novo pedido de aprovação.

Isto torna as coisas mais simples e menos burocráticas, tal como acontece na Wikipédia anglófona. Há casos em que obviamente não haverá questionamentos, pelo que não deverá ser necessário aguardar sempre pelos sete dias (embora este período deva ser assegurado na janela de contestação). RadiX 18h28min de 8 de abril de 2017 (UTC)

@RadiX: OK, mas a redação ficou um pouco confusa. O editor pode solicitar o estatuto de volta e um burocrata pode negá-lo? Com base em quê? É sempre bom deixar explícito quem faz o que, onde e quando. Por exemplo, na sua versão, quem vai divulgar o pedido na Esplanada? Fica subentendido que o interessado deverá fazê-lo, mas e se ele ficar esperando que o burocrata que lhe devolveu o estatuto o faça? Portanto é melhor deixar claro e não ambíguo a responsabilidade de cada um. Em outras palavras, como é o processo? Quando isso for definido, eu posso sugerir outra contraproposta. Saudações. Oxe (discussão) 03h11min de 9 de abril de 2017 (UTC)
  • Proponho que o mesmo seja adotado para editores de interface, eliminadores e burocratas. RadiX 18h31min de 8 de abril de 2017 (UTC)

Symbol question.svg Pergunta A contestação não tem de ser embasada nalguma política? Ou basta alguém dizer Symbol declined.svg Discordo sem mais nada?-- Darwin Ahoy! 19h47min de 8 de abril de 2017 (UTC)

Outro ponto nada claro... Érico (fale) 19h48min de 8 de abril de 2017 (UTC)
Acredito que a discordância deveria estar fundamentada nas políticas e recomendações para que seja aceita, e isto poderia ser incluído ao texto da proposta para maior clareza. RadiX 19h55min de 8 de abril de 2017 (UTC)
Se a contestação precisar estar embasada de acordo com as políticas, aí já vira caso de pedido de remoção de estatuto, não? Oxe (discussão) 01h37min de 9 de abril de 2017 (UTC)

Symbol support vote.svg Concordo com uma reforma neste parâmetro administrativo. Para não transformarmos este lugar numa casa da mãe Joana. Afinal, utilizamos procedimento semelhante na Wikia por uns tempos. Armagedon2000 msg 03h18min de 9 de abril de 2017 (UTC)

Symbol support vote.svg Concordo É um refinamento dessa parte da política, anunciar na esplanada e aguardar o tempo de uma semana (7 dias) para saber se há refutações torna o processo mais transparente e idôneo. Quanto a justificativa para a não atribuição da flag, acredito que qualquer uma que esteja pelo menos um pouco fundamentada na política ou que possua uma boa argumentação lógica seja considerada válida. Por exemplo: um usuário que passa 5 ou 10 anos afastado da Wiki sem praticamente exercer atividades na qual permitiriam ele ser avaliado e esse mesmo solicita o estatuto, nesse caso basta uma alegação falando sobre seu longo período de dormência sem apresentar registro de dados, é uma justificativa plausível e puramente lógica. --Pap@ Christus msg 07h17min de 9 de abril de 2017 (UTC)

@Papa Christus: Passar um ano afastado seria motivo suficiente? Oxe (discussão) 11h23min de 9 de abril de 2017 (UTC)
@Oxe: Entendo, pra mim, que um ano não seria um período muito longo de ausência, estaria nos limites do aceitável, muito possivelmente eu não seria contra a atribuição levando principalmente em consideração os motivos do afastamento do usuário, como dificuldade financeira, problemas de ordem familiar, faculdade e outros de cunho particular. Mas qualquer oposição se referindo ao seu tempo de ausência seria válida, pois há quem entenda que ano seja um tempo razoável para a perda de contanto com a comunidade e que a concessão do estatuto sem o pedido de aprovação não seja o caminho correto. De qualquer forma existem os casos óbvios de longo afastamento, no entanto há casos que não são unanimidades e que podem ser melhor averiguados. --Pap@ Christus msg 17h14min de 9 de abril de 2017 (UTC)
@Papa Christus: Entendo. Se for para ficar neste nível subjetivo, é melhor que o editor que perdeu o estatuto por absenteísmo faça um novo pedido para obtenção do estatuto do que haver conflitos desnecessários. Um bom ex-administrador não terá problemas para ser aprovado novamente, não é? Saudações. Oxe (discussão) 20h06min de 9 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Quanto menos subjetividade melhor. !Silent (discussão) 19h15min de 15 de abril de 2017 (UTC)

Eu não acho que uma eventual contestação necessariamente deverá basear-se nas regras, porque, do meu ponto de vista, o que acontece na restituição do cargo pós inatividade é que existe um consenso implícito que o ex-administrador ainda cumpre os requisitos e goza da confiança da comunidade. Qualquer oposição, por qualquer motivo, quebra então esse consenso implícito, e exigirá agora um novo consenso explícito. Eu acreditar que um hipotético retornante não domina os meandros da Wikipédia atual (as páginas de pedidos, por exemplo) não baseia-se em nenhuma regra, mas, na minha opinião, é um motivo válido ainda assim. Desse modo, Symbol support vote.svg Apoio a contraproposta do RadiX, sem mais alterações. - Épico (disc)/(contrib) 04h04min de 17 de abril de 2017 (UTC)

@Oxe: Você se referiu à redação confusa da proposta acima mencionada. Possui algum outro texto que esclarecesse os pontos que levantou? - Épico (disc)/(contrib) 04h04min de 17 de abril de 2017 (UTC)
@Épico: Olá! Farei sim um novo texto assim que forem esclarecidos os procedimentos para reatribuição e a contestação da reatribuição do estatuto. Depois disso irei trabalhar para deixar o texto mais objetivo e não ambíguo. A minha opinião pessoal é que toda atribuição do estatuto de administrador deva passar por um pedido, acabando assim com a devolução de estatuto depois da remoção por absenteísmo. Seria muito mais simples e menos controverso, porque um bom administrador não deve ter dificuldade de reaver o estatuto só porque se afastou por algum tempo do projeto. Mas como a proposta foi para esclarecer o que já existe, vou me esforçar para melhorá-la e vou deixar para propor aquilo num momento posterior. Saudações. Oxe (discussão) 04h20min de 17 de abril de 2017 (UTC)

Contraproposta. Apesar de ter reescrito o texto da proposta para deixá-lo mais claro e preciso (se for mudar no sentido original da proposta, que seja para um texto melhor), venho agora propor que toda atribuição (e devolução) de estatuto de confiança deva sempre passar por um pedido de aprovação, porque eu penso que quem teve um estatuto no passado e fez bom uso de suas ferramentas não terá nenhum problema de reavê-lo só porque se afastou momentaneamente do projeto. Desta forma, acaba-se com qualquer possibilidade de polêmica na devolução de um estatuto e, de quebra, elimina-se um processo do já complexo sistema de normas e procedimentos da Wikipédia. Saudações. Oxe (discussão) 14h08min de 18 de abril de 2017 (UTC)

Symbol support vote.svg Apoio o Oxe. Se um usuário é confiável e faz bom uso de suas ferramentas não tem problema nenhum em passar por outra avaliação. OSA, O Sem Autoridade [nota 1] [1] 14h18min de 18 de abril de 2017 (UTC)

Symbol declined.svg Discordo. Foge completamente do escopo desta proposta e do padrão em outras wikis. Se possui esta opinião, é recomendável que inicie outra proposta para que se debata melhor o assunto. Érico (fale) 17h39min de 19 de abril de 2017 (UTC)

Aqui é um local apropriado para esta discussão porque o objeto é o mesmo. Você propôs adicionar algo ao parágrafo e eu estou propondo que o parágrafo seja removido. Oxe (discussão) 17h49min de 19 de abril de 2017 (UTC)

Concordo em melhorar o texto na linha do Érico e do Radix (e discordo do Oxe), mas ainda não estou convencido que a redacção elimine todas as ambiguidades. Faço uma proposta abaixo:

GoEThe (discussão) 10h49min de 21 de abril de 2017 (UTC)

Este texto continua com problemas. Quando é feita a reatribuição? O que é uma contestação justificada? Com base em quê se justifica uma contestação? Quem avalia se a avaliação é justificada?
Gente, simplifiquem as coisas e eliminem processos desnecessários e controversos. Perdeu o estatuto mas o quer novamente? É simples, faça um novo pedido de obtenção de estatuto, que é um processo plenamente conhecido da comunidade. Oxe (discussão) 11h43min de 21 de abril de 2017 (UTC)
Mas é mesmo para simplificar que se tenta evitar a votação. Eu também penso que bastaria o pedido no café dos burocratas e o anúncio na Esplanada. Havendo contestação, desde que minimamente fundamentada, deve então passar por um processo de nomeação formal. Por contestação "minimamente fundamentada" entendo algo que não seja:
  • Symbol declined.svg Discordo;
  • Sem a menor condição;
  • Não tem minha confiança;
E coisas semelhantes. Quem discorda, realmente tem que dar algum tipo de justificação para isso. Por exemplo, colocando em causa a compreensão do projecto após longo tempo de ausência, que será certamente o motivo mais comum, dando oportunidade ao candidato para que possa esclarecer e sanar essas dúvidas, se for o caso, evitando a necessidade de se avançar para uma eventual votação.-- Darwin Ahoy! 14h21min de 21 de abril de 2017 (UTC)

Maior divulgação dos pedidos relacionados ao grupo dos burocratas

Discussões anteriores
  1. Wikipédia:Esplanada/propostas/Adendo em item dos critérios para eleição de novos supervisores e verificadores (22abr2016): proposta aprovada.
  2. Wikipédia:Esplanada/propostas/Maior divulgação dos PDAs (18dez2016): proposta aprovada.

Conforme pode ser visto nas ligações acima, a comunidade aprovou a utilização do recurso MassMessage e da página MediaWiki:Watchlist-details para divulgação mais ampla dos pedidos relacionados aos grupos de supressores, verificadores de contas e administradores.

Proponho também, através desta rápida consulta, que exatamente o mesmo procedimento seja adotado para os pedidos de aprovação e remoção de burocratas. RadiX 19h20min de 8 de abril de 2017 (UTC)

  • Symbol support vote.svg Concordo com a maior divulgação (isto é diferente de conluios). __ Observatoremsg 19h56min de 8 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Quanto maior a divulgação maior a participação da comunidade nesses pedidos, tornando o resultado da votação com uma qualidade melhor em razão da diversidade de ideias e convicções das centenas de editores. --Pap@ Christus msg 07h22min de 9 de abril de 2017 (UTC)

Symbol support vote.svg Concordo. Oxe (discussão) 12h35min de 10 de abril de 2017 (UTC)

Symbol support vote.svg Concordo. Vanthorn® 01h04min de 12 de abril de 2017 (UTC)

Symbol support vote.svg Concordo !Silent (discussão) 19h13min de 15 de abril de 2017 (UTC)

RadiX 18h12min de 26 de abril de 2017 (UTC)

Aplicar os eliminadores, editores de interface e burocratas a mesma regra de reinclusão no grupo existente para os administradores nos casos de remoção por inatividade

Na página Wikipédia:Política de administradores#Remoção automática por absenteísmo é estabelecido que:

O administrador que teve o seu estatuto removido por inatividade poderá, a qualquer momento, solicitá-lo novamente aos burocratas. Se qualquer editor contestar essa devolução, um novo pedido de aprovação deverá ser iniciado
 
WP:POLA.

.

Nesta outra seção da Esplanada foram propostas melhorias ao texto.

Proponho, através desta rápida consulta, que a mesma regra de reatribuição do estatuto nos casos de remoção por absenteísmo seja estendida aos burocratas, editores de interface e eliminadores - incluindo as melhorias que foram eventualmente aprovadas aqui. RadiX 19h41min de 8 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário Em princípio concordo, mas gostava de ver esclarecido primeiro se qualquer discordância serve, ou se tem de haver embasamento nalguma política do projecto.-- Darwin Ahoy! 19h49min de 8 de abril de 2017 (UTC)

Acredito que a discordância deveria estar fundamentada nas políticas e recomendações para que seja aceita, e isto poderia ser incluído ao texto da proposta para maior clareza. RadiX 19h56min de 8 de abril de 2017 (UTC)
@RadiX: Se for assim, é mais prudente remover a devolução automática para evitar confusão de uma pessoa contestar a devolução apontando políticas e depois alguém discordar da contestação, dizendo que nenhuma política apontada embasa a contestação, e reatribuir o estatuto assim mesmo. Como há juízo de valor ao se decidir se a contestação é baseada ou não em políticas, negativas de contestações são potenciais fontes de conflitos. Evitaria qualquer confusão neste sentido se o editor fizesse um novo pedido do estatuto que, acredito, não teria problema de ser aprovado se ele tiver feito bom uso das ferramentas. Saudações. Oxe (discussão) 12h40min de 10 de abril de 2017 (UTC)

Symbol question.svg Pergunta O que vai decidir se a discordância é "valida"? Se for necessário um embasamento nas políticas, quem vai avaliar o argumento e assim propondo outra votação? Burocrata? E quais seriam esses critérios? JackgbaDiga! 20h41min de 8 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Se vale para os administradores, não vejo problema essa regra está presente também nos outros estatutos. Acredito que as argumentações contrárias podem ser realizadas com pelo menos um pouco de fundamento na política ou até mesmo uma boa argumentação lógica pode ser considerada válida. --Pap@ Christus msg 07h33min de 9 de abril de 2017 (UTC)

Symbol support vote.svg Concordo !Silent (discussão) 19h12min de 15 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Até a parte relacionada ao "Se qualquer editor contestar essa devolução", creio que haja um consenso tácito da maioria, visto que é apenas lógico aplicar o mesmo procedimento aos demais estatutos. - Épico (disc)/(contrib) 03h48min de 17 de abril de 2017 (UTC)


Symbol support vote.svg Concordo Gato Pretotrovai-me! 08h05min de 17 de abril de 2017 (UTC)

Symbol declined.svg Discordo. Toda atribuição (e devolução) de estatuto de confiança deve sempre passar por um pedido de aprovação, porque eu penso que quem teve um estatuto no passado e fez bom uso de suas ferramentas não terá nenhum problema de reavê-lo só porque se afastou momentaneamente do projeto. Desta forma, acaba-se com qualquer possibilidade de polêmica na devolução de um estatuto e, de quebra, elimina-se um processo do já complexo sistema de normas e procedimentos da Wikipédia. Saudações. Oxe (discussão) 14h02min de 18 de abril de 2017 (UTC)

@Oxe: Então você acha que essa possibilidade também deve ser removida dos pedidos de administração? Atualmente a regra existe apenas aos administradores. Não tenho um posicionamento específico a respeito, mas, seja qual for a decisão, o processo deve ser normalizado. RadiX 14h07min de 18 de abril de 2017 (UTC)
@RadiX: Sim, para qualquer estatuto que demande confiança, inclusive o de administrador. Acabei de comentar sobre isso também em Wikipédia:Esplanada/propostas/Mudança_menor_na_política_de_administradores_(8abr2017). Saudações. Oxe (discussão) 14h10min de 18 de abril de 2017 (UTC)

Complementar Regras para remoção por votação na Política de Administradores

Caros, devido a alguns eventos recentes que deixaram aberto a interpretação como proceder nos pedidos de remoção do estatuto de Administrador, gostaria de sugerir a inclusão do seguinte texto em Política de administradores#Regras para remoção por votação.

A votação terá duração de sete dias e deverá respeitar um período mínimo de 48 horas (2 dias) entre o momento em que o administrador foi notificado em sua página de discussão (e por e-mail, se ativado) e a abertura efetiva da votação.

Passadas as 48 horas da notificação do(a) administrador(a) em sua página de discussão, a votação terá início imediatamente quando um dos seguintes eventos ocorrer:

  • O(a) administrador(a) indicado apresentar resposta formal sobre as alegações apresentadas no pedido de remoção.
  • O(a) administrador(a) indicado solicitar que a votação seja iniciada, abstendo-se do direito de resposta.
  • Transcorridas 96 horas (4 dias) da notificação do(a) administrador(a) em sua página de discussão, independente de haver um posicionamento formal.

A parte em vermelho é nova. O que acham? --Diego Queiroz (discussão) 01h19min de 11 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário Nada contra as duas primeiras, mas discordo da última. O que a última faz, na prática, é aumentar o prazo de 48 pata 96 horas. Aquilo que devia estar previsto nas regras de forma explícita é fazer com que o prazo para apresentar a defesa dependa do dia e da hora a que foi postada a última acusação. Por exemplo, estabelecer-se que a votação só se pode iniciar 48 horas após as últimas alegações da acusação. Se no fim do prazo a acusação apresenta uma enxurrada de novas evidências, a defesa precisa de tempo útil para ser escrita, pelo que o contador se deve reiniciar. Quintal 01h30min de 11 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário Apesar dos questionamentos levantados recentemente - em grande medida devido à frase "Seguir-se-á uma votação com as mesmas regras da votação para a obtenção do estatuto." não estar especificamente na secção que define as regras, embora faça parte da política de remoção - historicamente sempre se previu a prorrogação destas votações, exactamente do mesmo modo como são feitas as prorrogações das votações de aprovação. Porque agora remover isso da política? Há alguma razão válida para que essas votações não possam ser prorrogadas?-- Darwin Ahoy! 02h07min de 11 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário. Acho que ficou muito complicado. Penso que esta contraproposta fique mais simples:

A votação terá duração de sete dias e será iniciada 48 horas depois que o administrador for notificado em sua página de discussão (e por e-mail, se ativado) que fora postada a última acusação do requerente na abertura do pedido de remoção.

Em outras palavras, depois que o requerente do pedido postar todas as acusações, a votação inicia-se dois dias depois do administrador ser notificado, independentemente dele postar ou não a sua defesa antes do prazo de 48 horas, em prol da simplificação da aplicação do processo. Saudações. Oxe (discussão) 02h27min de 11 de abril de 2017 (UTC)

A votação terá duração de sete dias e será iniciada 48 horas após o administrador ser notificado em sua página de discussão (e por e-mail, se ativado) e à postagem da última acusação na justificativa do pedido de remoção, seja pelo requerente ou por terceiros.

Fiz alguns ajustes no texto, e incluí a permissão para que terceiros complementem a justificativa, se necessário.

Também proponho a repetição da frase "Se existir incerteza, ainda que na opinião de um só burocrata, então pelo menos um burocrata deve sugerir uma extensão de prazos para que fique claro que a votação representa a decisão da comunidade", que constava nesta documentação (em seção única), anteriormente à criação da política de administradores. RadiX 02h41min de 11 de abril de 2017 (UTC)

@RadiX: Eu ia colocar os endossos de terceiros, mas deixei de fora para não fugir ao escopo inicial da proposta. O que você quis dizer com esse "e à" que você adicionou? Citação: RadiX escreveu: «A votação terá duração de sete dias e será iniciada 48 horas após o administrador ser notificado em sua página de discussão (e por e-mail, se ativado) e à postagem da última acusação na justificativa do pedido de remoção.». Saudações. Oxe (discussão) 03h50min de 11 de abril de 2017 (UTC)
48 horas após à defesa e à última mudança da justificativa do pedido (caso ocorra após a defesa). RadiX 03h53min de 11 de abril de 2017 (UTC)
Não precisa disso, porque na minha redação as 48 horas começam a contar a partir do momento em que o administrador for avisado que a acusação terminou. Por exemplo, se um editor faz a acusação e notifica o administrador, este faz sua defesa mas, antes de 48 horas da notificação, aquele editor modifica sua acusação, então a votação só poderá começar depois de 48 horas de uma nova notificação ao administrador. Se o administrador não for notificado, a votação não começa. Desta forma, o começo da votação fica amarrado apenas à notificação ao administrador e evita-se qualquer confusão com o horário do término da acusação e da notificação. Oxe (discussão) 04h03min de 11 de abril de 2017 (UTC)
Não havia entendido. Concordo com o proposto. Mas também é preciso verificar a inclusão da frase sobre a prorrogação nos dois pedidos, como existia antigamente, para evitar futuros problemas. RadiX 04h15min de 11 de abril de 2017 (UTC)
Se não entendeu é porque o meu texto não estava bom o suficiente. Vou pensar como mantê-lo sucinto e torná-lo mais claro. Vou adicionar a sugestão da prorrogação da votação também. Oxe (discussão) 04h22min de 11 de abril de 2017 (UTC)

Discordo da possibilidade de um pedido de remoção ser prorrogado pela sugestão de apenas um burocrata, da mesma forma que discordo que isso ocorra em PDAs. Não acho que nenhum burocrata isoladamente deve ter o poder para prorrogar votações. Concordaria com a possibilidade de prorrogações em pedidos de remoção se for acrescentado algo como "Se existir incerteza, na opinião da maioria dos burocratas [...]". No mais, as sugestões de Diego quanto o início das votações são um avanço. Érico (fale) 04h26min de 11 de abril de 2017 (UTC)

Eu penso que é importante a possibilidade de prorrogação, em qualquer dos casos, seja para aprovação ou para remoção, como aliás sempre foi a norma aqui. Os requisitos para essa prorrogação podem eventualmente ser discutidos e melhorados.-- Darwin Ahoy! 11h45min de 11 de abril de 2017 (UTC)

Entre postada e postagem venha o Diabo e escolha. Vamos ter mais juízinho e usar publicar, sim? JohnR (discussão) 13h22min de 11 de abril de 2017 (UTC)

  1. Symbol declined.svg Discordo que seja permitido a terceiros editar/endossar/comentar apenas a acusação. Ou os terceiros são autorizados a editar tanto a acusação como a defesa, ou não são autorizados a editar nenhuma das duas. Coerência e igualdade de oportunidades, se faz favor. Era o que mais faltava permitir a vinte pessoas a bombardear acusações e obrigar uma única pessoa a ter que se defender delas todas.
  2. Symbol declined.svg Discordo do absurdo de dar a um único burocrata o poder de decidir unilateralmente prorrogar uma votação. Não é assim que a Wikipédia funciona. Uma coisa é dar a possibilidade ao burocrata de agir de forma audaz. Outra coisa é haver uma regra que impõe à comunidade a opinião de um único burocrata, mesmo que os outros seis ou sete discordem da sua posição.
  3. Dito isto, também me faz confusão a linguagem do texto proposto quanto às 48 horas. Qual é o problema de dizer simplesmente que a votação tem início, no mínimo, 48 horas após a última publicação da acusação? Quintal 14h14min de 11 de abril de 2017 (UTC)

Contraproposta. Após as considerações dos colegas, faço a seguinte contraproposta do que entendo como consensual até o momento:

A votação terá duração de sete dias e iniciará exatamente 48 horas após o administrador ser notificado que a última acusação do requerente fora publicada na justificativa do pedido de remoção. A notificação ao administrador deverá ser feita em sua página de discussão e por e-mail (se ativado).

O início da votação começa exatamente (nem antes nem depois) 48 horas após o administrador for notificado que a justificativa do pedido está concluída, independentemente dele respondê-la. Por outro lado, se ele não for notificado da conclusão da justificativa do pedido, a votação não será iniciada. Além disso, se a justificativa do pedido for alterada após a notificação, isso implica que ela não foi concluída, sendo necessária uma nova notificação ao administrador e reinício do contador das 48 horas a partir dela. Aproveitei para separar o prazo e início da votação do procedimento de notificação ao administrador porque são coisas diferentes e não devem ser misturadas. Saudações. Oxe (discussão) 14h57min de 11 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Eu estou bem mais inclinado para a opinião do Oxe. No entanto, após assistir o evento recente, vi que não funciona dessa maneira. Em um evento como esse, a comunidade se divide em dois lados e qualquer coisa vira motivo para "o outro lado" achar que está sendo desfavorecido de alguma maneira. Por isso, talvez seja importante dar esse espaço para "ciência e argumentação". Por outro lado, quanto a sugestão do Antero de Quintal de reiniciar o prazo de 48 horas sempre que um "novo argumento" for apresentado, eu Symbol declined.svg Discordo. Se a possibilidade disso ocorrer for algo preocupante, eu seria mais favorável a "não permitir que o pedido seja alterado ou endossado" do que permitir ficar prorrogando. --Diego Queiroz (discussão) 01h13min de 12 de abril de 2017 (UTC)
@Diego Queiroz: No geral concordo com sua argumentação. É preciso só ter cuidado para a questão de quando a justificativa do pedido está concluída. Tomando o caso mais recente de pedido de remoção de administrador, para mim o pedido inicial e a atualização posterior foram insatisfatórias, como ficou demonstrado pelos endossos de Darwinius e meu próprio. Então, em vez de reescrever apenas um parágrafo da seção Regras para remoção por votação, eu penso que a seção inteira deveria ser reescrita para descrever melhor todo o processo do pedido de remoção, porque está faltando, por exemplo, a impugnação da justificativa do pedido por insuficiência, senão pedidos fakes podem acontecer, como foi feito recentemente o caso de uma DB na qual a seção em que cabia "propor um bloqueio" foi usada para "defender o não bloqueio", distorcendo o propósito da coisa. Estes outros pontos vão além da sua proposta inicial de definir início e fim de votação, certo? Só para a gente não perder o foco do que já é consensual e do que ainda não é. Saudações. Oxe (discussão) 11h32min de 12 de abril de 2017 (UTC)
@Oxe: Concordo também que a seção pode ser completamente reescrita, de forma a não dar margem para interpretações diversas. É que, como disse abaixo, tinha mais interesse em propor uma alteração simples, que eu achei que fosse consensual, para depois emendar outros detalhes. Mas não me oponho a uma nova redação. Já sobre a possibilidade de "impugnar o pedido por insuficiência" eu sou a favor de observar esse lado com bastante cautela. O lado indicado sempre vai alegar que o que foi apresentado é insuficiente, e só a comunidade pode julgar isso. E mesmo que não fosse assim, deixaria uma brecha para poder cancelar votações de forma arbitrária. Na minha opinião, só consigo visualizar a possibilidade de impugnar um pedido de remoção nos seguintes casos:
  • Pedidos evidentemente fúteis (ex. "ele gosta de brócolis, então peço que perca o estatuto").
  • Pedidos feitos por usuários novatos (ex. sem direito ao voto).
  • Pedidos feitos pouco tempo depois de um pedido de remoção mal-sucedido (3 meses, por exemplo), sem que tenha ocorrido um evento novo e relevante que justifique um novo pedido.
Fora esses casos, entendo que não deve existir a possibilidade de impedir que um pedido de remoção siga o seu curso. --Diego Queiroz (discussão) 13h52min de 12 de abril de 2017 (UTC)
@Diego Queiroz: Eu acho que você fez bem em primeiramente alterar um ponto específico.
Não me expressei bem quando falei em impugnação. O acusado não pode pedir a impugnação, como você bem notou. O que quis dizer é que a justificativa inicial de um pedido de remoção pode ser decisiva para seu resultado. A minha fala foi no intuito de poder suspender (acho que é um termo melhor do que impugnar) e refazer um pedido de remoção intencionalmente mal feito por alguém próximo do acusado com a finalidade de influenciar o resultado do pedido de forma favorável ao acusado. Hipoteticamente, suponha que o administrador Fulano e o editor Beltrano são amigos e tudo indica que pedirão a destituição de Fulano. Aí Beltrano se adianta e faz o pedido de remoção de tal forma que ele sabe que será malsucedido para evitar que seja feito um pedido apropriado de remoção com maiores chances de lograr sucesso. Entendeu? Deixo claro que não estou sugerindo que isso aconteceu no último pedido de remoção, mas, pelo o que tenho visto, é plenamente plausível de acontecer pela forma que alguns aqui distorcem e manobram as regras do projeto. Oxe (discussão) 14h13min de 12 de abril de 2017 (UTC)
@Oxe: Hmmmm... Entendi. Bastante perspicaz sua colocação. Mas também é uma situação bastante complicada de evitar. Confesso que tenho que refletir um pouco sobre isso.  :P --Diego Queiroz (discussão) 14h20min de 12 de abril de 2017 (UTC)
Uma forma de se resolver isso seria através de complementações na justificativa do pedido, mas isso também é problemático, tanto pelo controle de quem poderia fazê-las quanto pelo alegado direito de também ser possível complementar a defesa. Saudações. Oxe (discussão) 14h24min de 12 de abril de 2017 (UTC)

@Darwinius, Érico, e RadiX: Sobre o ponto da prorrogação, eu concordo que isso precise ser discutido. Quando escrevi essa proposta, inclusive, isso estava incluso no texto. No entanto, acabei removendo para ser mais prático e contemplar a parte que achei que fosse mais consensual. Mas se fosse para sugerir algum texto sobre o tema, eu sugeriria:

  1. A prorrogação é indevida nas Remoção por Votação de Administradores., ou
  2. A prorrogação somente poderá ocorrer uma vez por igual período e somente será devida quando a diferença dos votos a favor e contra for igual ou inferior a 10%.

Meu intuito com essas sugestões à respeito da prorrogação é "não permitir" ou "se permitir, deixar bem claro as condições para que ocorra". Nenhum burocrata deve ser impelido a agir como árbitro e decidir sobre isso. --Diego Queiroz (discussão) 01h22min de 12 de abril de 2017 (UTC)

@Diego Queiroz: Concordo integralmente com sua opinião. Não é possível, a meu ver, um único burocrata poder prorrogar uma votação mesmo quando todos os outros discordam. Não é assim que as decisões são tomadas. Quanto aos dois itens que propôs, concordo com o segundo. Érico (fale) 01h33min de 12 de abril de 2017 (UTC)
  • Symbol declined.svg Discordo. Se houver discordância quanto à prorrogação, outros burocratas deverão manifestar-se, como é regra nos demais pedidos de permissões. A questão é definida por consenso entre eles, e não por maioria ou números mágicos baseados em porcentagens. É óbvio que sem consenso nenhum pedido pode ser prorrogado. RadiX 01h57min de 12 de abril de 2017 (UTC)
@RadiX: E quais os critérios os burocratas devem utilizar? Opinião pessoal? O poder discricionário dos burocratas é o de analisar o caso e tomar decisões baseando-se nas regras, não de avaliar o que eles acham. O que sugere é deixar, intencionalmente, um ponto indefinido nas regras, para permitir que os burocratas decidam à vontade, como se fossem dotados de um entendimento superior. Além disso, vale salientar que as regras para outros casos não se aplicam aqui. O pedido de remoção recente pedia a remoção do estatuto de Administrador de um Burocrata. São os estatutos mais privilegiados da Wikipédia, e é difícil exigir que os pares julguem uns aos outros ao mesmo tempo que são imparciais. Definir claramente como proceder em cada caso, ajuda a todos a entender que a decisão não foi arbitrada por um grupo de usuários, mas baseada em regras claras e bem definidas. E não são "números mágicos", são números discutidos e escolhidos pela comunidade. --Diego Queiroz (discussão) 03h23min de 12 de abril de 2017 (UTC)
O critério a ser utilizado é o consenso. Os burocratas devem ser capazes de julgar a existência de consenso, fornecer uma explicação para suas ações, e justificar suas decisões ou comentários em pedidos de privilégios com base nas políticas e recomendações vigentes, de acordo com a política vigente. Este é um princípio básico para inclusão no grupo. Não existe a possibilidade de uma discussão ou votação ser prorrogada sem que haja consenso para tal. Transformar essa discussão em uma outra votação dentro da votação para definir algo sobre a votação não faz sentido. E é irrelevante se o administrador para o qual se pede a remoção do estatuto é também um burocrata ou tem outras funções; os dois estatutos são desvinculados. RadiX 14h30min de 12 de abril de 2017 (UTC)
E se não houver consenso? Honestamente, sou contra manter regras que geram conflitos inúteis. Sei que não precisa ter regra sobre tudo, mas às vezes, é o melhor caminho para evitar conflitos longos e improdutivos. --Diego Queiroz (discussão) 14h38min de 12 de abril de 2017 (UTC)
Aí eu acho que não se prorroga a votação. Oxe (discussão) 14h47min de 12 de abril de 2017 (UTC)
Não vejo nenhum problema em transformar "essa discussão em uma outra votação dentro da votação". O mesmo ocorre em alguns procedimentos dos burocratas na Wikipédia em Inglês. O problema reside em dar a um único burocrata o poder para prorrogar votações, com argumentação própria, e ele usar este poder para perseguir pessoas. Érico (fale) 14h41min de 12 de abril de 2017 (UTC)
Não usaria a palavra "perseguir". Mas acho que é prudente o Burocrata ter ciência da própria humanidade. Um usuário experiente julgando outro usuário experiente raramente é imparcial. Avaliações de usuários sobre outros usuários tentem a ser carregadas de pré-julgamentos e podem tender para qualquer lado, dependendo do envolvimento do burocrata no caso. Supor que o burocrata é isento de praticar parcialidade, ou que o consenso estabelecido pelos burocratas tenha essa característica, é uma presunção incorreta na minha opinião. --Diego Queiroz (discussão) 23h00min de 12 de abril de 2017 (UTC)
Sem entrar no mérito de ser possível ou não prorrogar votação de remoção de estatuto de administrador, prorrogar uma votação não pode ser caracterizado como uma perseguição, porque o máximo que o burocrata pode fazer, depois de prorrogada uma votação, é votar se ainda não o fez antes. A decisão continua sendo da comunidade. A não ser que você imagine que o burocrata irá empreender uma campanha para convencer as pessoas a votarem de determinada forma e ache que isso seja infração de alguma política ou recomendação do projeto. Oxe (discussão) 13h21min de 13 de abril de 2017 (UTC)
"A não ser que você imagine que o burocrata irá empreender uma campanha para convencer as pessoas a votarem de determinada forma". Acertou. E isso é bastante possível nos dias de hoje. É exatamente por isso que sou contrário a possibilidade de que apenas a sugestão de um único burocrata possa prorrogar alguma votação. Érico (fale) 19h17min de 15 de abril de 2017 (UTC)
@Érico: Citação: Érico escreveu: «"A não ser que você imagine que o burocrata irá empreender uma campanha para convencer as pessoas a votarem de determinada forma". Acertou. E isso é bastante possível nos dias de hoje. É exatamente por isso que sou contrário a possibilidade de que apenas a sugestão de um único burocrata possa prorrogar alguma votação.». Isso foi sério ou foi uma brincadeira? Oxe (discussão) 19h24min de 15 de abril de 2017 (UTC)
Não é isso Oxe. É simplesmente por entender que, se a votação tem o prazo de 7 dias, é porque a comunidade decidiu assim. Se fossem necessários 14 dias, não seria mais fácil a comunidade decidir logo que a votação tivesse 14 dias? O problema em achar a prorrogação um inconveniente não está diretamente relacionada à possibilidade de manipulação do resultado, mas sim ao fato de um usuário poder, unilateralmente, retardar os efeitos de uma decisão da comunidade que tinha prazo certo para ocorrer. Retardar os efeitos de uma decisão desnecessariamente (seja ela qual for) é uma afronta à vontade da comunidade. E sou contra a ideia do Érico em não permitir um burocrata decidir sozinho sobre a prorrogação, mas permitir o grupo decidir. Para mim dá na mesma: de qualquer forma a decisão fica arbitrária. Isso sem falar que já houve momentos que tínhamos apenas um burocrata editando ativamente. E aí como faz? --Diego Queiroz (discussão) 12h26min de 16 de abril de 2017 (UTC)
@Diego Queiroz: Da forma como foi proposta acima, a frase dá a entender que a sugestão de apenas um burocrata deve ser seguida, mesmo que fosse minoritária. Atualmente, temos sete burocratas e uma decisão em grupo costuma diminuir alegações de parcialidade. Se deixarmos que apenas um burocrata prorrogue esses pedidos, sem a possibilidade de se debater o assunto antes, teremos um problema. Evidentemente que um burocrata individualmente pode prorrogar uma votação, mas, se houver discordância significativa, essa prorrogação deve ser desfeita. É isso que eu gostaria que a frase deixasse claro. E, para esclarecimento: votações de CU e OS não são de responsabilidade dos burocratas e simplesmente não há a possibilidade de prorrogação. Érico (fale) 22h17min de 16 de abril de 2017 (UTC)

@Diego Queiroz: "Afronta à comunidade" é querer bloquear a qualquer custo um processo decisório da comunidade, numa altura em que ele ainda está decorrendo plenamente, como aconteceu aqui. A prorrogação não é um "inconveniente", é um mecanismo saudável e desejável para que as decisões aqui sejam baseadas na vontade real da comunidade, e não em procedimentos obscuros e altamente questionáveis como esse daí.-- Darwin Ahoy! 12h42min de 16 de abril de 2017 (UTC)

Concordo 1000% com o argumento. Por isso que sou a favor de estabelecer critérios claros e bem definidos de "quando prorrogar" e "quando não prorrogar", não deixando a critério de ninguém decidir isso. O problema é que alguns estão achando que "sempre prorrogar" é uma boa (não sei se você se inclui nesse grupo). --Diego Queiroz (discussão) 17h03min de 16 de abril de 2017 (UTC)
@Diego Queiroz: Se fosse para prorrogar sempre, não era prorrogação, era prazo de duas semanas. A prorrogação deve ser feita sempre que haja incerteza razoável sobre o resultado na hora do primeiro fecho. Isso pode se dever tanto a um resultado apertado, como a algum acontecimento que esteja desestabilizando o processo eleitoral e cuja evolução potencialmente cause mudanças significativas no resultado. Nesse caso que eu apontei, até ocorreram as duas situações juntas, e mesmo assim aconteceu o que aconteceu. O modo como o processo deveria ser realizado, no meu ponto de vista, seria: Caso algum burocrata tenha duvida razoável sobre o resultado, e/ou ache que a votação deve ser prorrogada, faz a proposta no café dos burocratas. E dependendo da resposta ao tópico, faz-se ou não a prorrogação. Usar números mágicos pode eventualmente ajudar a decidir prorrogações de casos apertados, mas as outras situações devem obrigatoriamente ser por decisão reflectida e fundamentada.-- Darwin Ahoy! 21h16min de 16 de abril de 2017 (UTC)
@Darwinius: Existiria um limite de prorrogações permitidas? Oxe (discussão) 21h34min de 16 de abril de 2017 (UTC)
@Oxe: Antigamente não existia, a votação era prorrogada enquanto tinha de ser. E penso que esse é que é o procedimento correcto, não vejo qualquer vantagem em limitar a prorrogação. Desde que os burocratas vejam motivos para isso acontecer, pois que aconteça.-- Darwin Ahoy! 21h39min de 16 de abril de 2017 (UTC)
@Darwinius: Acho curioso o tanto de confiança que deposita na decisão conjunta dos burocratas. Eu, particularmente, não tenho toda essa fé. Não porque os burocratas sejam corruptos ou não sejam dignos de confiança, não é nada disso. Mas acho que não é assim que devia funcionar. Mas ok. Se a maioria acha assim, sou voto vencido. Burocratas decidem. --Diego Queiroz (discussão) 04h12min de 17 de abril de 2017 (UTC)
Então poderia ser assim?
  • Um burocrata pode prorrogar uma votação se ele julgar necessário;
  • Outro burocrata pode contestar a prorrogação, levando a prorrogação ao WP:Café dos burocratas para obtenção de consenso sobre ela. Enquanto o consenso entre os burocratas é estabelecido, a votação fica suspensa;
  • Se houver consenso pela pela prorrogação, a votação é prorrogada; senão a votação é encerrada seja por haver consenso neste sentido, seja por não ter havido consenso.
Não está claro para mim qual seria o prazo para um burocrata contestar a prorrogação de uma votação. Saudações. Oxe (discussão) 04h32min de 17 de abril de 2017 (UTC)

@Diego Queiroz: É bastante irónico, de facto, porque eu realmente não tenho muita confiança nisso- pelo contrário, e com boas razões, como já mostrei. Mas infelizmente não vejo outra alternativa melhor para esses casos em que não dá para fazer uma decisão automática.-- Darwin Ahoy! 11h09min de 17 de abril de 2017 (UTC)


@Darwinius, Diego Queiroz, Érico, RadiX, JohnR, e Antero de Quintal: Olá! Deixando a questão da prorrogação de lado por enquanto —não porque não seja importante, muito pelo contrário, pois é um demasiadamente importante e deve ser tratada de forma mais ampla em uma discussão dedicada apenas ao tópico— poderíamos fechar consenso sobre a melhoria da redação daquel parágrafo que Diego havia proposto inicialmente? Seguem o texto atual e a proposta com as diferenças coloridas.

Texto atual

A votação terá duração de sete dias e deverá respeitar um período mínimo de 48 horas (2 dias) entre o momento em que o administrador foi notificado em sua página de discussão (e por e-mail, se ativado) e a abertura efetiva da votação.

Texto proposto

A votação terá duração de sete dias e iniciará exatamente 48 horas após o administrador ser notificado que a última acusação do requerente foi publicada na justificativa do pedido de remoção. A notificação ao administrador deverá ser feita em sua página de discussão e por e-mail (se ativado).

Há consenso sobre esta mudança? Oxe (discussão) 13h47min de 18 de abril de 2017 (UTC)

Eu só comentei o pontapé na língua portuguesa. De resto, parece-me bem. A única hesitação que tenho é usar a "última acusação" como referência. Como não me parece que haja processo ou prazos para fazer a acusação, preciso evitar esse vazio legal. Portanto, como não gosto de Direito e sou um tipo simples prefiro:
A votação terá duração de sete dias e iniciará exatamente 48 horas após ser solicitada a remoção por votação. A notificação ao administrador deverá ser feita em sua página de discussão e por e-mail (se ativado).
Assim está implícito que a primeira acusação vem com a votação. Mas se estão a mudar as regras para incluir última acusação para incluir o impacto de novas provas e a natureza mutável da acusação, mas ao mesmo tempo fechar a porta a arbitrariedades... Não sei. A experiência diz-me que isso muda pouco, por isso não adianta dar-se a esse trabalho. Mas para ficar claro, não me oponho a nenhuma alteração. --JohnR (discussão) 14h12min de 18 de abril de 2017 (UTC)
@JohnR: O que motivou a mudança é justamente não estar claro em que momento se considera que foi "solicitada a remoção por votação". No último pedido de remoção, (1) o requerente fez o pedido, (2) um dia depois um editor complementou o pedido em forma de endosso, (3) mais um dia depois outro editor fez nova complementação também em forma de endosso, (4) e finalmente o requerente substituiu os endossos pelos seus resumos três dias após o início do processo. A minha proposta considera que a última acusação do requerente aconteceu após (4) e que só a partir daí é que se contariam as 48 horas para o início da votação. O texto se propõe a resolver o tipo de impasse que ocorreu ali, forçando que exista consenso sobre a justificativa do pedido antes do administrador visado ser notificado e, assim, ter até 48 horas para elaborar sua defesa antes do início da votação. Pelo texto que você propôs, deixa margem de interpretação para que a contagem das 48 horas inicie-se após (1). Saudações. Oxe (discussão) 14h35min de 18 de abril de 2017 (UTC)
@JohnR: Você acha que ficaria melhor se fosse mudado de "a votação (...) iniciará (...) após o administrador ser notificado que a última acusação do requerente foi publicada na justificativa do pedido de remoção" para "a votação (...) iniciará (...) após o administrador ser notificado que o requerente fez a última alteração na justificativa do pedido de remoção"? Saudações. Oxe (discussão) 14h53min de 18 de abril de 2017 (UTC)
Pode ficar como está. Não é necessário alterações. --JohnR (discussão) 14h58min de 18 de abril de 2017 (UTC)
Obrigado. Posso remover o destaque do seu texto para evitar alguma confusão entre as propostas? Oxe (discussão) 15h02min de 18 de abril de 2017 (UTC)
Força. Não sei qual é a formatação que devia ficar depois, se não o fazia. --JohnR (discussão) 15h11min de 18 de abril de 2017 (UTC)
Feito. Grato! Oxe (discussão) 16h25min de 18 de abril de 2017 (UTC)

Acabar com as listas de jogadores atuais

Tópico antecedente: Wikipédia:Esplanada/propostas/Acabar com o noticiário sobre futebol (18nov2012). Vejam a {{Elenco atual do Fortaleza Esporte Clube}}


Elenco atual

Soccerball current event.svg Atualizado em 17 de março de 2017.[1]

Legenda
  • Capitão: Capitão.
  • Suspenso.: Jogador suspenso.
  • Lesionado: Jogador contundido.
  • +: Jogador em fase final de recuperação.
  • +: Jogador sem condições físicas ou não regularizado junto à CBF.
  • Prata da casa: Prata da casa.


Goleiros
Jogador
1 Brasil Bélgica Marcelo Boeck
12 Brasil Matheus Inácio
23 Brasil Max Walef Prata da casa
36 Brasil Matheus Jesus Prata da casa
Defensores
Jogador Pos.
3 Brasil Del'Amore Z
4 Brasil Ligger Z
13 Brasil Gabriel Teixeira Z
14 Brasil Max Oliveira Prata da casa Z
28 Brasil Heitor Z
2 Brasil Felipe LD
22 Brasil Pablo LD
25 Brasil Eduardo LD
6 Brasil Allan Vieira LE
16 Brasil Bruno Melo Prata da casa LE
30 Brasil Bruninho LE
Meio-campistas
Jogador Pos.
5 Brasil Anderson Uchôa V
11 Brasil Jefferson V
19 Uruguai Gastón Filgueira V
28 Brasil Esdras Prata da casa V
31 Brasil William Schuster V
34 Brasil Iury Silva Prata da casa V
40 Brasil Rodrigo Mancha V
' Brasil Matheus Guimarães V
10 Brasil Rodrigo Andrade M
15 Brasil Esquerdinha M
20 Brasil Cássio Ortega M
27 Brasil Wesley Prata da casa M
29 Brasil Patuta M
33 Brasil Leandro Lima M
35 Brasil Erick Prata da casa M
52 Brasil Ronny M
77 Brasil Everton M
91 Brasil Renatinho M
Atacantes
Jogador
7 Brasil Juninho Potiguar
9 Brasil Lúcio Flávio
17 Brasil Gabriel Pereira
26 Brasil Vinícius Baiano
88 Brasil Zé Carlos
Comissão técnica
Nome Pos.
Brasil Marquinhos Santos T
Brasil Edison Borges AS
Brasil Celso Santos PF
Brasil Glydiston Ananias PF
Brasil Bosco TG
Brasil Guto Albuquerque TG
Brasil Glay Maranhão MD
Brasil Rafael Veras MD
Brasil Vinícius Castelo Branco MD
Brasil Albino Luciano FT
Brasil Egberto Oliveira FT
Brasil Fabio Gomes FT
Brasil Patrício Teixeira FT
Brasil Ranielson Xavier FT
Brasil José Wellington MA
Brasil Manuel Almeida MA
Brasil André Luis MA
Brasil Edson Palomares FG
Brasil Álvaro Augusto SV

Transferências[editar código-fonte]

Emprestado: Jogadores emprestados
Regresso após empréstimo: Jogadores que voltaram após serem emprestados
Final ou rescisão do contrato: Final, rescisão do contrato ou chegando sem custos


Vejam também os casos de Corinthians, Flamengo, Porto, Benfica, Barcelona, Real Madrid entre outros times (quase todos estão assim). Há nesses artigos uma lista de jogadores do "elenco atual", quase sempre sem fontes e com um "atualizado dia X". Isto a meu ver viola WP:JORNAL. Uma coisa seria termos uma lista de jogadores do time base de determinado clube, por ano, com eventuais reservas. Outra é colocar no artigo principal do clube a lista atual dos jogadores, atualizando sempre de acordo com a última partida (o que tende a tornar os artigos desatualizados), com o cúmulo de haver lista de contundidos e suspensos. Não é função de uma enciclopédia informar esse tipo de coisa. Se os elencos são relevantes, que estejam numa lista à parte, que seja permanente, de preferência sobre o elenco regular por temporada. Se não são relevantes, não devem estar nos artigos.

O melhor exemplo de como as coisas deveriam ser, penso eu, achei no vôlei, ao ver o artigo do Rio de Janeiro Vôlei Clube. Ainda acho que aquelas informações deveriam estar numa lista, mas pelo menos são listadas (com fontes) as informações de todas as temporadas, e o artigo não é atualizado jogo a jogo.

Minhas propostas portanto são:

  • 1) Mover as informações de elencos esportivos com fontes para listas de jogadores que atuaram pelo clube.
  • 2) Remover sumariamente as informações sem fontes sobre elencos.
  • 3) Remover informações, mesmo com fontes, sobre contusões, transferências e suspensões dessas listas. A Wikipédia não é o caderno de esportes, para fornecer este tipo de cobertura. -- Leon Saudanha 01h51min de 14 de abril de 2017 (UTC)

Referências

  1. «Elenco Fortaleza». Site Oficial 
  2. Fortaleza contrata o goleiro Marcelo Boeck
  3. Fortaleza anuncia a contratação do goleiro Matheus, ex-Ponte Preta
  4. Fortaleza anuncia a contratação do zagueiro Ligger Malaquias
  5. Fortaleza anuncia contratação do zagueiro Heitor, que estava em Israel
  6. Fortaleza anuncia contratação do zagueiro Gabriel Silva para temporada
  7. "Batizado" por Jadson, Del'Amore renova e se empolga com empréstimo
  8. Lateral Eduardo é o novo reforço do Leão
  9. Lateral Pablo é contratado pelo Leão
  10. Allan Vieira acerta com o Fortaleza e é mais um reforço para 2017
  11. Fortaleza contrata Gastón Filgueira
  12. Fortaleza acerta a contratação do volante Jefferson, ex-Figueirense
  13. Fortaleza acerta com o volante Vacaria e o atacante Gabriel Pereira
  14. Fortaleza oficializa a contratação do meia William Schuster, ex-Grêmio
  15. Fortaleza contrata Rodrigo Mancha
  16. Fortaleza contrata meia Cássio Ortega como reforço para a temporada 2017
  17. Empresário confirma reviravolta e diz que Éverton assinou contrato com o Fortaleza
  18. Fortaleza contrata Renatinho
  19. Ronny é o novo reforço do Fortaleza para a temporada
  20. Fortaleza anuncia contratação do atacante Juninho Potiguar
  21. Zé Carlos é o novo reforço do Leão
  22. Ex-Fortaleza, Edimar assina com o São Bernardo e quer fazer Paulistão 'inesquecível'
  23. Lima é mais um reforço do Ituano
  24. Leonardo Luiz acerta rescisão de contrato com o Fortaleza e deixa clube
  25. Willian Simões e Clebinho rescindem com o Fortaleza; sete jogadores já acertaram as contas com o clube
  26. Linense acerta contratação de Pio, que estava no Fortaleza
  27. Com término de contrato, Juliano encerra passagem pelo Fortaleza; clube tem interesse em novo vínculo
  28. Volante Corrêa anuncia que não fica no Fortaleza para 2017
  29. Fortaleza confirma saída do volante Vacaria
  30. Meia Daniel Sobralense é o 8º jogador a rescindir contrato com o Fortaleza
  31. Fortaleza anuncia a rescisão de contrato de mais quatro jogadores
  32. Rosinei, ex-Corinthians, é novo reforço de caçula do Campeonato Catarinense
  33. Com dois titulares na lista, Fortaleza confirma as primeiras rescisões no elenco
  34. Fortaleza acerta rescisão de contrato com atacante Ronaldo, nesta terça
  35. Reforços do Ceará: Náutico acerta com Ewerton Páscoa, Anselmo e Juninho
  36. Campinense anuncia contratação do atacante Maranhão para a temporada

Symbol declined.svg Discordo de acabar com o elenco atual das páginas de clubes de futebol. Existem problemas de excesso de informações, de informações sem fontes e de má formatação. Estes devem ser corrigidos para informações essenciais, somente informações com fontes e formatação mais simples. Compare o exemplo que você deu com o elenco do Real Madrid na enwiki: en:Real Madrid C.F.#Current squad. As páginas sobre clubes de futebol parecem árvores de Natal e será preciso muita energia para consertá-las; penso que uma nova predefinição sobre elencos seja um bom primeiro passo em vez de simplesmente acabar com os elencos. Saudações. Oxe (discussão) 03h00min de 14 de abril de 2017 (UTC)

Oxe uma enciclopédia por definição lista coisas que sempre serão relevantes, que farão de alguma forma parte da história do artigo. Se a informação vai sair tão logo a escalação mude, ela não é tão relevante assim para constar ali. Se o jogador atuou regularmente no clube por uma temporada, então ele pode constar numa lista, por exemplo Lista de futebolistas do Botafogo de Futebol e Regatas por ano. Ou o artigo das temporadas, como o Luan citou. Por que não? Pelo o menos é um lugar onde a informação vai ficar permanentemente, e não ser trocada a qualquer momento, é isso que a meu ver estimula o "jornal", essa constante necessidade de atualização. Que está sempre atualizada em times grandes, mas em times médios ou pequenos tende a ficar desatualizada. E mais, veja que essa lista do Botafogo está quase sem fontes, enquanto o artigo principal, a lista dos jogadores atuais está bem referenciada. A informação que está referenciada logo vai se perder no histórico, tão logo a escalação mude, e a informação que não está referenciada, na lista, vai ficar. Não deveríamos estimular que as pessoas editassem e referenciassem justamente a lista, onde as informações vão ficar pra sempre? -- Leon Saudanha 21h17min de 14 de abril de 2017 (UTC)
@Leon saudanha: Você tem razão em retirar a parte sobre as transferências na temporada (?), bem como informações sobre contusões e suspensões, porque o artigo torna-se WP:JORNAL. Porém o elenco atual é uma informação importante dos times de futebol e deve constar no corpo do texto do artigo. Reforço que a predefinição sobre o elenco deve ser simplificada, porque atualmente parece uma árvore de Natal. Aproveite e remova a parte da comissão técnica, porque ela não joga. Saudações. Oxe (discussão) 21h29min de 14 de abril de 2017 (UTC)

Symbol support vote.svg Concordo. Transferências e essas instabilidades não devem constar no artigo principal. Ao meu ver, o único lugar possível e cabível seria em artigos de temporadas, tal como em Temporada do Esporte Clube Vitória de 2017. --Luan (discussão) 14h18min de 14 de abril de 2017 (UTC)

Symbol declined.svg Discordo de acabar com o elenco actual, pois seria algo sem sentido abrir um artigo sobre um clube e não ter essa informação, desde que tenha fontes. Mas sou a favor de mover as transferências para uma lista a parte, já que todo ano são feitas inúmeras transferências, o que deixaria o artigo imenso. Mr. Fulano! 🔔Fale Comigo📩 17h24min de 14 de abril de 2017 (UTC)

Symbol comment vote.svg Comentário Essa é uma das áreas que contribuo bastante, com atualizações quando ocorre transferências. Como santista, primeiramente procuro cuidar de informações relacionadas ao clube, já coloquei muito sobre entrada e saída de jogadores do clube. A lista do clube é sempre bem cuidada, contando com pelo menos outros dois editores ativos, mas quando coloco a informação do jogador que saiu na lista do clube que ele foi encontro verdadeiras bagunças, não há um padrão entre as listas, cada uma tem as colunas tem um jeito, algumas com diversos jogadores sem referências, algumas em vez de lista a informação está contida no artigo do próprio clube.

1) Acredito que dá para existir as duas coisas, se não for possível separado pode ser até junto com um destaque para os atuais. Porém uma ressalva essas listas seriam gigantes porque há centenas de jogadores que já atuaram por certos clubes.

2) Tudo que está sem fonte não deveria existir.

3) Na Wiki inglesa, existem tabela de suspensão e transferência, bem como convocações que ficam no artigo das temporadas dos clubes como fatos da temporada. Por outro lado contusões e suspensões como fato corrente não deveria existir mesmo. Igor G.Monteiro (discussão) 17h55min de 14 de abril de 2017 (UTC)

Symbol declined.svg Discordo de acabar com elenco atual. Na minha opinião poderia ser mais bem feito, ocupar menos espaços e todas as informações adicionadas virem com fontes. Talvez a formatação de elenco atual dos times da NBA (este) e NFL, por exemplo, poderiam ser copiadas. Net Esportes alô! 15h55min de 18 de abril de 2017 (UTC)

Symbol support vote.svg Concordo O conteúdo editorial de uma enciclopédia deve-se, em regra geral, informar contexto histórico, ou seja, o que aconteceu de relevante ao assunto para que possa ser pesquisado no futuro. Fatos a serem atualizados constantemente como jogadores que são contratados e depois dispensados e não contribuíram para a história do clube, não são conteúdo enciclopédico. Esta listas não tem razão de existir numa enciclopédia. São listas para estarem em blogues, em sites esportivos, local que funcionam como material jornalistico. Tem muito editor que confunde jornal com enciclopédia virtual aberta. Não só lista de jogadores. Em artigos de cidades, tem dados como o número de estabelecimentos comerciais, como x farmácias, y mercados, z lojas, ou x quantidades de carros, y quantidade de ônibus, z quantidades de motocicletas; coisas totalmente inútil para uma enciclopédia. O "R" Aliado 18h33min de 18 de abril de 2017 (UTC)

Uma ideia para resolver essa situação e deixar os artigos mais parecidos com uma enciclopédia, é a criação do DOMÍNIO anuário (ou até um projeto irmão anuário), onde todo tipo de informação de possa ser atualizado constantemente seja relacionado e organizado por ano. Por exemplo, anuário Santos FC ano 2016 e neste domínio/local seja incluído todos os números, jogadores e informações referente aquele ano junto ao clube; cria-se uma seção anuário no verbete, com ligação direta para o domínio. Funcionario não só para clubes, como para cidades, ou tudo que deve ser atualizado constantemente. Essa informação passaria a existir na enciclopédia e seria conteúdo pesquisável. Quando digo pesquisável é porque 90% desta informação contida hoje, aqui na Wikipédia, funciona como como um jornal, que depois de lida, vira embrulho de peixe, lembrando que é uma porcentagem pequena dos jogadores de futebol que possuem artigos para manterem informações por clubes que passaram ou gols que fizeram numa temporada. O "R" Aliado 18h54min de 18 de abril de 2017 (UTC)
Existe algo parecido que são as temporadas por clube de futebol, inclusive essa que você citou Santos 2016, é criação minha: Temporada do Santos Futebol Clube de 2016. Acredito que o caminho é esse e poderia se estender a outras áreas. Igor G.Monteiro (discussão) 00h21min de 19 de abril de 2017 (UTC)

Minha ideia quanto a essas listas de jogadores é mover tudo para o Wikidata. Hoje ainda teríamos que fazer um trabalho inútil de listar jogador por jogador como propriedade. Mas quando(se?) o Wikidata passar a permitir listas no mediawiki a minha ideia seria fazer a pesquisa "jogadores do time tal que não possuem data de saída do time" e gerar as listas de elenco.

Também me incomodo muito com essas edições em tabelas e listas que são praticamente impossíveis de verificar e difíceis até de entender em um diff. A Wikipédia não foi feita para essas informações, mas passou a abrigá-las e nesse momento, sem uma alternativa viável para poder guardar e mantê-las é preciso manter a situação atual. Chico Venancio (discussão) 20h15min de 18 de abril de 2017 (UTC)

Exemplo de dados não enciclopédico este número foi atualizado. O número anterior virou "embrulho de papel". Este é um exemplo simples de conteúdo que se perde. Um pesquisador que desejar saber qual o n° de 2015, vai procurar outra fonte. Com um local existente num domínio específico por ano ou no Wikidata, seria uma informação agregada, que não se perderia. Trouxe um exemplo de um número que muda anualmente, ou seja, o n° atual fica preservado pelo menos um ano, mas listas de jogadores é muito mais complicado manter da maneira como é, pois a cada mês, entra e sai jogadores, nos clubes, com muito mais regularidade, portanto, informação desnecessária. O "R" Aliado 03h53min de 19 de abril de 2017 (UTC)

Criação de critérios para a inclusão de itens em artigos sobre datas

Olá. Nos últimos tempos, reparei que diversos artigos sobre datas estão dominados por informações irrevantes, como a data de nascimento de jogadores da quinta divisão e aniversário de cidades com pouca relevância do interior do Brasil. Alguns exemplos:

Data Item Ocupação / referente a Qualidade
7 de março Data de nascimento de Daniel Chitsulo Ex-jogador da quarta divisão alemã Tem uma frase. Nenhuma fonte
7 de abril Data de nascimento de Boquita Jogador do Brusque Futebol Clube Tem uma fonte
10 de maio Aniversário da cidade de Otacílio Costa Cidade de Santa Catarina que possui 16.000 habitantes Vários trechos sem fontes
6 de outubro Data de nascimento de Valdimir Ferraz Matias Nunes Ex-jogador do Sport Clube Freamunde Nenhuma fonte
2 de fevereiro Data de nascimento de Diego Salgado Costa de Menezes Jogador do Esporte Clube Santo André A maior parte do conteúdo não possui fontes

Enfim, os exemplos são inúmeros e a lista de artigos sobre datas com itens irrelevantes aumenta diariamente. Está cada vez mais desmotivante ler esses artigos. Dito isto, proponho que apenas artigos com importância 4 e qualidade 3 sejam incluídos em qualquer verbete referente a datas. Érico (fale) 16h29min de 26 de abril de 2017 (UTC)

Symbol support vote.svg Concordo Com urgência, deve ser incluídos critérios e ser verificadas as páginas das datas. Quanto ao jogador com artigo de uma frase é caso de eliminação. Igor G.Monteiro (discussão) 17h30min de 26 de abril de 2017 (UTC)

Symbol question.svg Pergunta Olá! Onde são feitas as avaliações de importância e qualidade? Já vi este tipo de informação em vários locais mas nunca encontro onde elas foram realizadas. Por exemplo, Sepultura (banda) foi avaliado com qualidade 4 em 27 de novembro de 2011. De onde veio esta avaliação? Qual é a avaliação na escala de importância de Sepultura (banda)? Saudações. Oxe (discussão) 17h34min de 26 de abril de 2017 (UTC)

Symbol support vote.svg Concordo parcialmente. É uma boa proposta, desde que haja uma formalização na importância e qualidade da página, já que a maioria esmagadora estão "por avaliar". JackgbaDiga! 18h49min de 26 de abril de 2017 (UTC)

Symbol declined.svg Discordo, resumidamente, pelos seguintes motivos:

  1. Artigos com problemas devem ser eliminados ou corrigidos. Se o estado deles é tão grave que uma ligação se mostra indesejada, então eles sequer deveriam existir, e aí temos nossos diversos métodos de eliminação.
  2. Uma metodologia similar é aplica nos artigos sobre anos. Mas com uma diferença: existem artigos temáticos para os anos (2017 no cinema, 2017 na música, 2017 no desporto, 2017 no Brasil, etc.) que "acolhem" os artigos que não têm qualidade o suficiente para constar nos principais e ajudam a desafogá-los.
  3. Como o Jackgba e o Oxe bem apontaram, temos uma quantidade obscena de artigos sem avaliação ou com avaliações discutíveis/desatualizadas. O que significa que os artigos sobre dias ficariam demasiadamente incompletos e/ou sujeitos a um sistema de avaliação um tanto obscuro e dependente de WikiProjetos que, em sua maioria, estão inativos, semi-ativos, ou não informam os critérios específicos de avaliação de importância (aparentemente, todos simplesmente seguem Predefinição:Escala de importância).
  4. Há um tempo, editei vários desses artigos e não me senti desmotivado; além disso, esses artigos funcionam praticamente como listas, são mais para consulta que para leitura corrida. Pelo menos na minha humilde opinião... Victão Lopes Diga! 20h06min de 26 de abril de 2017 (UTC)