I can’t edit it anymore! but @erlend_sh did it for us.
if this is a giant post, how do you call that one you’ve linked?! 
I can’t edit it anymore! but @erlend_sh did it for us.
if this is a giant post, how do you call that one you’ve linked?! 
We’ve got two excellent use cases for this.
Personal journal outlining a member’s trading strategy (think stocks or options trading). Majority of members change their strategy often over the course of their trading lifecycle, and that definitely happens outside of our edit window of 10 days. We have members that are going on 5+ years membership, who still tweak their strategy and want to journal that for themselves or for the rest of the community.
Informational posts, where the first post is edited to reflect changes to say a list of companies that caters to our members. The company names changes, some stop catering to us, etc. We have a topic that’s been running for over 8 years. The first several posts are a running list, with company information. The remaining posts are the discussion about said companies.
The workaround has been the wiki post, but that doesn’t give the OP complete control over the post, and leaves us open to spammy actions.
We’re looking for a hybrid approach, give the OP indefinite edits on at least the first post, or allow the OP to set how many of the first several posts he can edit (as long as he’s the author of those posts, so something like the first 5 posts, for instance). All existing permissions/rules about the edit window would still apply, except for the OP.
vBulletin had/has this in a plugin.
Not really, since spammers are quite unlikely to reach trust level 1, and that is required to edit wikis.
We’ve experienced… committed spammers who’ve done that in the past. Not at any large scale, but it’s happened. We’re actually dealing with a web of such folks (a company) who purposefully created 10+ accounts to legitimately discuss the topics at hand while name dropping their most favorite broker (their company) every couple of weeks. We just uncovered this going back over a year on a handful of accounts. It’s very subtle, but upon further investigation, IPs are similar, locations are close, email address are created in the same style (name+number@domain.com), and the accounts exhibit the same posting behavior (times, frequency, categories they post to, who they like, who they reply to). It’s pretty crazy the lengths they go to.
Here on Meta there have been spam users who earned the wiki editor badge, but as wiki edits aren’t shown in activity I wasn’t able to revert whatever it was they changed before reporting them.
O Elixir Forum possui algumas categorias (por exemplo, “Comunidade / Perfis de Desenvolvedores”, “Suas Bibliotecas e Projetos”) cujo conteúdo tende a ser persistente, mas em constante evolução. Portanto, elas se beneficiariam de uma granularidade mais fina na limitação do tempo de edição.
Recentemente, AstonJ fez o seguinte comentário no tópico (apenas para membros) Você pode aumentar o limite de tempo para edição de posts?:
Seria ótimo se o Discourse permitisse que certas seções fossem configuradas para que o criador do tópico pudesse editar o primeiro post dos tópicos que criou indefinidamente. Isso também seria útil para coisas como tópicos de bibliotecas
Estou disposto a tentar criar um PR para isso, mas antes gostaria de saber se a ideia geral é aceitável. Sugestões sobre como e onde a configuração deve ser feita também seriam apreciadas.
-r
Por quê? As postagens da Wiki já atendem a esse objetivo.
Postagens de wiki não permitem que o autor original controle edições subsequentes.
Isso tem sido um problema na teoria ou na prática? Acho que os dois são frequentemente bem diferentes.
Além disso, por que não simplesmente estender o tempo limite de edição para níveis de confiança (TL2+) para algo realmente longo, como 2 anos?
Não sei por que precisamos de mais uma configuração aqui.
Tive esse problema hoje mesmo. Há cerca de um ano, publiquei uma entrada no fórum da Elixir, na seção “Community / Dev Profiles”. Ela continha uma URL que estou descontinuando, então queria substituí-la pela nova. Embora o AstonJ tenha sido gentil o suficiente para fazer a edição por mim, teria sido mais conveniente se eu mesmo pudesse fazê-lo.
Além disso, por que não estender o tempo limite de edição por nível de confiança (TL2+) para algo realmente longo, como 2 anos?
Isso funcionaria para alguns casos de uso, mas, em geral, não parece ser uma boa ideia. (Se um post tiver acumulado respostas e for editado, o fluxo da discussão pode ficar confuso.) Portanto, apenas certas categorias deveriam se comportar dessa maneira.
Talvez a opção mais fácil seja modificar as wikis para que também possam ser configuradas para permitir apenas que o criador da postagem as edite (assim, de certa forma, elas se tornariam uma wiki pessoal).
Isso nos permitiria usar o recurso existente das wikis (onde podemos definir categorias para tornar automaticamente a primeira postagem uma wiki), evitando ao mesmo tempo os problemas de usá-las em casos como este, onde qualquer pessoa poderia potencialmente editar o que, de outra forma, seria uma postagem/wiki pessoal de alguém.
Acho que a wiki permite controle.
O dono do post é notificado em cada edição. Se uma edição inadequada for feita, ele pode desfazê-la. Se surgir uma briga, o post pode ser sinalizado e os moderadores podem corrigir.
Um grande motivador para um novo recurso aqui seria o fato de que já tentamos o acima, mas ainda assim são criadas montanhas de trabalho inútil.
Existem exemplos do mundo real de problemas nessa situação?
Não funcionaria um rodapé dizendo: “esta é uma wiki pessoal, por favor, corrija apenas erros de digitação”?
Uma reviravolta interessante que eu de certa forma apoio é a sinalização automática de posts de wiki em que o dono do post não está mais por perto; nesses casos, os moderadores deveriam ou desativar o modo wiki ou reassinar a propriedade.
Consulta rápida para “Criadores de Wiki Ausentes”:
SELECT (current_timestamp - users.last_seen_at) idle_duration,
(current_timestamp - posts.created_at) post_made_ago,
posts.id post_id, users.id user_id
from posts
join users on posts.user_id = users.id
join topics on posts.topic_id = topics.id
where posts.wiki = true
and posts.deleted_at IS NULL
and topics.deleted_at IS NULL
and users.last_seen_at < CURRENT_TIMESTAMP - INTERVAL '90 days'
order by idle_duration desc