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?! 
1 me gusta
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.
1 me gusta
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.
3 Me gusta
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.
1 me gusta
El Foro de Elixir tiene algunas categorías (por ejemplo, “Comunidad / Perfiles de desarrolladores”, “Tus bibliotecas y proyectos”) cuyo contenido tiende a ser persistente, aunque en evolución. Por lo tanto, se beneficiarían de una mayor granularidad en la limitación del tiempo de edición.
Recientemente, AstonJ hizo el siguiente comentario en el hilo (solo para miembros) ¿Pueden aumentar el límite de tiempo para editar publicaciones?:
Sería genial si Discourse permitiera configurar ciertas secciones de modo que el creador del hilo pudiera editar la primera publicación de los hilos que inicia de forma indefinida. Esto también sería útil para cosas como hilos sobre bibliotecas
Estaría dispuesto a intentar crear un PR para esto, pero primero me gustaría saber si la idea general es aceptable. También se agradecen sugerencias sobre cómo y dónde debería realizarse la configuración.
-r
1 me gusta
¿Por qué? Las publicaciones de Wiki ya cumplen ese objetivo.
Las publicaciones en el wiki no permiten que el autor original controle las ediciones posteriores.
¿Ha sido esto un problema en teoría o en la práctica real? Suelo encontrar que ambas cosas suelen ser muy diferentes.
Más allá de eso, ¿por qué no simplemente extender el tiempo límite para editar según el nivel de confianza (NC2+) a algo realmente largo, como 2 años?
No estoy seguro de por qué necesitamos otra configuración más aquí.
Hoy mismo tuve este problema. Hace aproximadamente un año, publiqué una entrada en la sección «Comunidad / Perfiles de desarrolladores» del foro de Elixir. Contenía una URL que estoy dejando de usar, por lo que quería sustituirla por la nueva. Aunque AstonJ fue tan amable de realizar la edición por mí, habría sido más conveniente que pudiera hacerlo yo mismo.
Más allá de eso, ¿por qué no simplemente extender el tiempo límite de edición según el nivel de confianza (TL2+) a algo realmente largo, como 2 años?
Eso funcionaría para algunos casos de uso, pero en general no parece una buena idea. (Si una publicación ha acumulado respuestas y luego se edita, el hilo de la discusión podría confundirse.) Por lo tanto, solo ciertas categorías deberían comportarse de esta manera.
3 Me gusta
Quizás la opción más sencilla sería modificar los wikis para que también se puedan configurar de modo que solo el creador del mensaje pueda editarlos (de modo que, en cierto sentido, se convertirían en un wiki personal).
Esto nos permitiría aprovechar la funcionalidad existente de los wikis (donde podemos configurar categorías para que el primer mensaje se convierta automáticamente en un wiki) evitando los problemas de usarlos en casos como este, donde cualquier persona podría editar potencialmente lo que, de otro modo, sería el mensaje o wiki personal de alguien.
1 me gusta
Creo que la wiki sí permite control.
El propietario del mensaje es notificado en cada edición. Si se realiza una edición incorrecta, pueden revertirla. Si surge una disputa, el mensaje puede ser marcado y los moderadores lo corregirán.
Un gran motivador para una nueva función aquí sería que ya probamos lo anterior, pero se genera una montaña de trabajo inútil.
¿Existen ejemplos del mundo real de problemas en este caso?
¿No funcionaría simplemente un pie de página que diga: “esta es una wiki personal, por favor corrige solo errores tipográficos”?
Un giro interesante que apoyo en cierta medida es la marcación automática de mensajes de wiki cuando el propietario ya no está disponible; en casos como este, los moderadores deberían o bien desactivar la función wiki o reasignar la propiedad.
4 Me gusta
Consulta rápida para “Creadores 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
4 Me gusta
