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.
Elixir 论坛 包含一些类别(例如“社区/开发者档案”、“您的库和项目”),其内容往往具有持久性,但也在不断演变。因此,这些类别若能对编辑超时限制实现更细粒度的控制,将会更加受益。
最近,AstonJ 在(仅限会员)的帖子 能否延长帖子编辑时间限制? 中发表了如下评论:
如果 Discourse 允许为某些版块设置选项,使主题发起者可以无限期地编辑自己发起的主题中的首帖,那就太好了。这对于库相关主题等场景也会非常有用:
我愿意尝试为此提交一个 PR,但首先我想确认这一总体构想是否可行。关于如何以及在哪里进行配置的任何建议,也欢迎提出。
-r
为什么?维基帖子已经实现了这一目标。
Wiki 帖子不允许原始发帖人控制后续编辑。
这只是在理论上存在问题,还是在实际中确实发生过?我发现这两者往往大相径庭。
此外,为什么不直接根据信任等级(TL2 及以上)将编辑超时时间延长到非常长的期限,比如两年呢?
我不明白为什么这里还需要另一个设置。
我今天刚好遇到了这个问题。大约一年前,我在 Elixir 论坛的“社区/开发者档案”板块发布了一篇文章。其中包含一个我打算弃用的 URL,因此我想将其替换为新的链接。虽然 AstonJ 很友善地帮我进行了编辑,但如果能自己操作会更方便。> 除此之外,为什么不根据信任等级(TL2+)将编辑超时时间延长到一个非常长的期限,比如两年呢?这对某些使用场景确实可行,但总体上似乎并不是个好主意。(如果一篇文章已经积累了回复,随后又被编辑,讨论的连贯性可能会变得混乱。)因此,只有特定类别的帖子才应适用这种机制。
也许最简单的方案是修改维基功能,使其也可以设置为仅允许发帖人编辑(这样在某种程度上就变成了个人维基)。
这样我们就可以利用维基现有的功能(即设置分类以自动将首帖设为维基),同时避免在类似情况下使用维基所带来的问题,即任何人都可能编辑本应属于某人个人的帖子或维基。
我认为该维基确实允许进行控制。
每进行一次编辑,帖子所有者都会收到通知。如果进行了不当编辑,他们可以将其回滚。如果引发争执,帖子可以被标记,由版主进行修正。
推动新功能的一个主要动力是,我们尝试过上述方法,但仍产生了大量无意义的工作。
现实中是否存在此类问题的实际案例?
添加一个脚注:“这是个人维基,请仅修正拼写错误”,是否可行?
我 somewhat 支持的一个有趣做法是:自动标记那些原所有者已不在场的维基帖子。在这种情况下,版主应要么取消维基化,要么重新分配所有权。
关于“缺失的 Wiki 创作者”的快速查询:
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