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.
Das Elixir Forum verfügt über einige Kategorien (z. B. „Community / Entwickler-Profile“, „Deine Bibliotheken & Projekte“), deren Inhalte eher dauerhaft, aber dennoch im Wandel begriffen sind. Daher wären sie von einer feineren Granularität bei der Begrenzung der Bearbeitungszeit profitieren.
Kürzlich hat AstonJ in dem (nur für Mitglieder zugänglichen) Thread Könnt ihr das Zeitlimit für das Bearbeiten von Beiträgen erhöhen? folgenden Kommentar abgegeben:
Es wäre großartig, wenn Discourse bestimmte Bereiche so konfigurieren könnte, dass der Thread-Ersteller den ersten Beitrag in von ihm gestarteten Threads unbegrenzt bearbeiten kann. Das wäre auch für Themen wie Bibliotheks-Threads sehr praktisch
Ich würde gerne einen PR dafür erstellen, möchte aber zunächst herausfinden, ob die grundsätzliche Idee akzeptabel ist. Vorschläge dazu, wie und wo die Konfiguration vorgenommen werden sollte, wären ebenfalls willkommen.
-r
Warum? Wiki-Beiträge erfüllen dieses Ziel bereits.
Bei Wiki-Beiträgen kann der ursprüngliche Verfasser nachfolgende Bearbeitungen nicht steuern.
War das in der Theorie ein Problem oder in der Praxis? Ich finde, die beiden sind oft sehr unterschiedlich.
Abgesehen davon: Warum nicht einfach die Bearbeitungszeit für Vertrauensebene 2 (TL2+) auf etwas wirklich Langes wie 2 Jahre verlängern?
Ich bin mir nicht sicher, warum wir hier noch eine weitere Einstellung benötigen.
Ich hatte heute genau dieses Problem. Vor etwa einem Jahr habe ich im Elixir Forum in der Sektion „Community / Entwicklerprofile
Vielleicht wäre die einfachste Option, Wikis so anzupassen, dass sie auch so eingestellt werden können, dass nur der Ersteller des Beitrags sie bearbeiten darf (wodurch sie gewissermaßen zu einem persönlichen Wiki werden).
Dadurch könnten wir die bestehende Funktion von Wikis nutzen (bei der wir Kategorien so einstellen können, dass der erste Beitrag automatisch zu einem Wiki wird), und gleichzeitig die Fallstricke vermeiden, die entstehen, wenn man sie in Fällen wie diesen verwendet, in denen theoretisch jeder das bearbeiten könnte, was ansonsten ein persönlicher Beitrag/Wiki einer Person ist.
Ich denke, dass das Wiki eine Kontrolle ermöglicht.
Der Beitragseigentümer wird bei jeder Bearbeitung benachrichtigt. Wenn eine schlechte Bearbeitung vorgenommen wird, kann er/sie diese rückgängig machen. Sollte ein Streit entstehen, kann der Beitrag markiert werden, und die Moderatoren können eingreifen.
Ein großer Motivator für ein neues Feature wäre, dass wir das bereits versucht haben, aber dennoch Berge an sinnloser Arbeit entstehen.
Gibt es reale Beispiele für Probleme in diesem Zusammenhang?
Würde ein Fußnotenhinweis wie „Dies ist ein persönliches Wiki, bitte korrigieren Sie nur Tippfehler
Schnelle Abfrage für „Fehlende Wiki-Ersteller":
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