Wikipédia:Esplanada/geral/Artigo informativo: Não se preocupe com desempenho (28out2014)
Artigo informativo: Não se preocupe com desempenho (28out2014)
Caros. Acabei de finalizar a tradução da página da Wikipédia anglófona en:Wikipedia:Don't worry about performance como Wikipédia:Não se preocupe com desempenho (atalho: WP:LENTO). Marquei ela como Ensaio, no entanto, gostaria do aval da comunidade para saber se o conteúdo é consensual e se poderia marcá-la como sendo um Artigo informativo com a predefinicão {{Informativo}}. --Diego Queiroz (discussão) 17h06min de 28 de outubro de 2014 (UTC)
- Concordo, mas por quê o Brion Vibber está gritando?Jo Loribd 18h13min de 28 de outubro de 2014 (UTC)
- Deve ser porque a lista é em formato texto, e o uso de maiúsculas é a forma usual de enfatizar trechos do que se está dizendo nessas situações. Na versão wiki, podemos fazer essa ênfase com a tag mais apropriada:
<em>...</em>
. Helder 19h36min de 28 de outubro de 2014 (UTC) - Que bom que alteraram as maiúsculas.Jo Loribd 19h45min de 28 de outubro de 2014 (UTC)
- Deve ser porque a lista é em formato texto, e o uso de maiúsculas é a forma usual de enfatizar trechos do que se está dizendo nessas situações. Na versão wiki, podemos fazer essa ênfase com a tag mais apropriada:
- Concordo Que bom. Poderei mexer no mediawiki com tranquilidade, editando aqueles comandos incompreensíveis.--OS2Warp msg 18h54min de 28 de outubro de 2014 (UTC)
- Não muita... Já que quem tem acesso ao domínio MediaWiki tem ferramentas mais poderosas do que os usuários comuns. Mas o pior que pode acontecer é errar tão feio que alguém da WMF precise revertê-lo. Helder 19h36min de 28 de outubro de 2014 (UTC)
- Concordo Que coincidência, estava recentemente lendo esse verbete na wiki.en. Espero que resulte numa tolerância maior com novatos que realizam salvamentos sucessivos. Lechatjaune msg 19h25min de 28 de outubro de 2014 (UTC)
- Salvamentos sucessivos prejudicam o nosso desempenho (ao acompanhar mudanças recentes e a lista de páginas que vigiamos), não o desempenho do site. E para mim isso é motivo o suficiente para incentivar menos edições, de mais qualidade. Helder 19h36min de 28 de outubro de 2014 (UTC)
- (Ficando fora de pauta) Se isso é verdade, também é verdade que avisos como {{mostrar previsão}} pioram a experiência de edição do novato e hão de reduzir a retenção de editores. Lechatjaune msg 19h44min de 28 de outubro de 2014 (UTC)
- (bem fora da pauta) @Lechatjaune: o que é bom, já que não devem continuar atrapalhando os demais... Em outras palavras, uma vez que tenham sido informados do quanto isso atrapalha outros editores, não devem continuar atrapalhando (se continuarem, novos avisos são apropriados, para que parem mesmo...). Helder 20h31min de 28 de outubro de 2014 (UTC)
- (dando asas à discussão fora de pauta): @He7d3r: Nesse caso eu estou com o Lechatjaune. Você sabe se já foi discutida a possibilidade de agrupar edições sucessivas de um mesmo usuário na visualização do histórico? Me parece mais eficiente do que regrar o modo como os usuários fazem suas edições. --Diego Queiroz (discussão) 20h48min de 28 de outubro de 2014 (UTC)
- bugzilla:33943. Helder 20h58min de 28 de outubro de 2014 (UTC)
- Para Mudanças Recentes e Páginas Vigiadas, há anos eu uso aquela opção de agrupar as edições de uma mesma página, então faz pouca diferença se tem uma edição ou 30, cada página ocupa apenas uma linha na minha tela. Se eu quiser ver quem editou, clico na seta ao lado do nome do verbete. A opção é ativada em "Preferências" -> "Mudanças Recentes" -> "Agrupar alterações por páginas nas mudanças recentes e nas páginas vigiadas". Para o histórico de um verbete, é só usar o "comparar edições" marcando a primeira edição do sujeito e a última. Realmente, não acho que as edições sucessivas sejam um problema real. Quem se preocupa com isso (porque monitora as edições) são um grupo pequeno e experiente, que pode aprender mais facilmente a mudar sua rotina do que um universo amplo e heterogêneo de novatos fazendo suas primeiras edições. Com o tempo, os editores naturalmente passam a fazer edições maiores, corrigindo várias coisas ao mesmo tempo, usando o "Mostrar previsão", etc. CasteloBrancomsg 13h46min de 2 de novembro de 2014 (UTC)
- @Castelobranco Não é prático patrulhar (uma por uma) 10 edições consecutivas do mesmo editor, e isso só aumenta o backlog de patrulhamento... Helder 15h40min de 3 de novembro de 2014 (UTC)
- Para Mudanças Recentes e Páginas Vigiadas, há anos eu uso aquela opção de agrupar as edições de uma mesma página, então faz pouca diferença se tem uma edição ou 30, cada página ocupa apenas uma linha na minha tela. Se eu quiser ver quem editou, clico na seta ao lado do nome do verbete. A opção é ativada em "Preferências" -> "Mudanças Recentes" -> "Agrupar alterações por páginas nas mudanças recentes e nas páginas vigiadas". Para o histórico de um verbete, é só usar o "comparar edições" marcando a primeira edição do sujeito e a última. Realmente, não acho que as edições sucessivas sejam um problema real. Quem se preocupa com isso (porque monitora as edições) são um grupo pequeno e experiente, que pode aprender mais facilmente a mudar sua rotina do que um universo amplo e heterogêneo de novatos fazendo suas primeiras edições. Com o tempo, os editores naturalmente passam a fazer edições maiores, corrigindo várias coisas ao mesmo tempo, usando o "Mostrar previsão", etc. CasteloBrancomsg 13h46min de 2 de novembro de 2014 (UTC)
- bugzilla:33943. Helder 20h58min de 28 de outubro de 2014 (UTC)
- (dando asas à discussão fora de pauta): @He7d3r: Nesse caso eu estou com o Lechatjaune. Você sabe se já foi discutida a possibilidade de agrupar edições sucessivas de um mesmo usuário na visualização do histórico? Me parece mais eficiente do que regrar o modo como os usuários fazem suas edições. --Diego Queiroz (discussão) 20h48min de 28 de outubro de 2014 (UTC)
- (bem fora da pauta) @Lechatjaune: o que é bom, já que não devem continuar atrapalhando os demais... Em outras palavras, uma vez que tenham sido informados do quanto isso atrapalha outros editores, não devem continuar atrapalhando (se continuarem, novos avisos são apropriados, para que parem mesmo...). Helder 20h31min de 28 de outubro de 2014 (UTC)
- (Ficando fora de pauta) Se isso é verdade, também é verdade que avisos como {{mostrar previsão}} pioram a experiência de edição do novato e hão de reduzir a retenção de editores. Lechatjaune msg 19h44min de 28 de outubro de 2014 (UTC)
- Salvamentos sucessivos prejudicam o nosso desempenho (ao acompanhar mudanças recentes e a lista de páginas que vigiamos), não o desempenho do site. E para mim isso é motivo o suficiente para incentivar menos edições, de mais qualidade. Helder 19h36min de 28 de outubro de 2014 (UTC)
Me pergunto se todo esse cuidado, toda essa prontidão realmente pode ser transferida para a Wikipédia em português. Não duvido que algum problema no servidor seja prontamente detectado e consertado na Wikipédia em inglês. A questão é se os mesmos olhos que olham para a anglófona olham para a lusófona e detectam com essa mesma eficácia e, além disso, estão dispostos a agir com tamanho interesse e rapidez a ponto de que a tradução da língua seja mesmo verossímil sem que precisemos de uma versão própria do ensaio. Realmente, não sei, mas já vejo com um pé atrás pelo simples fato de que nossos servidores não tão "potentes" quanto os de lá pra início de conversa (mesmo considerando as devidas proporções e diferentes demandas de cada projeto, somos mais lentos) e na realidade não há essa isonomia perfeita que eu também gostaria que houvesse.—Teles«fale comigo» 01h38min de 30 de outubro de 2014 (UTC)
- @Teles Por que diz que nossos servidores não são tão potentes quanto os de lá? Helder 01h41min de 30 de outubro de 2014 (UTC)
- Por que não são mesmo... me corrige se eu estiver enganado.
Mas veja, por exemplo, que o carregamento de uma página não é o mesmo. Usando o exemplo das mudanças recentes: pt, en. Eu sempre carrego com mais que o dobro de tempo e não sei se algum gadget poderia causar essa disparidade, mas uso gadgets lá também.—Teles«fale comigo» 01h56min de 30 de outubro de 2014 (UTC)- O valor da
wgBackendResponseTime
(digite isso no console do seu navegador) nas mudanças recentes da ptwiki (670) costuma ser menor do que na enwiki (1062). Não parece ser culpa dos servidores... Quanto a influência de gadgets, teste com JavaScript desativado, e depois teste com ele ativado mas sem estar logado. Helder 10h21min de 30 de outubro de 2014 (UTC)- @Teles, eu entendo sua preocupação: possivelmente qualquer problemas é resolvido mais rapidamente na wiki.en do que na wiki.pt, mas o ponto continua o mesmo: há pouco que possamos fazer como editores para melhorar o desempenho e mais vale a pena pautarmos nossas políticas com vistas a melhorar a experiência de edição e a relação comunitária do que tentanto otimizar o sistema. Lechatjaune msg 13h18min de 30 de outubro de 2014 (UTC)
- O valor da
- Por que não são mesmo... me corrige se eu estiver enganado.
Feito Como me parece ter havido consenso, fiz a alteração proposta. --Diego Queiroz (discussão) 14h16min de 23 de novembro de 2014 (UTC)