# Returning bumping after editing last post **URL:** https://meta.discourse.org/t/returning-bumping-after-editing-last-post/390033 **Category:** Feature **Created:** [December 1, 2025, 10:40am UTC](https://meta.discourse.org/t/returning-bumping-after-editing-last-post/390033 "2025-12-01T10:40:52Z") **Posts on this page:** 1 **Showing post:** 9
### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin) #### Post date: [January 24, 2026, 11:40pm UTC](https://meta.discourse.org/t/returning-bumping-after-editing-last-post/390033/9 "2026-01-24T23:40:27Z")
> [@mcwumbly](#): > > This is not at all motivated by surfacing spam. > > Wiki and docs posts are bumped based on the theory that edits to those posts are generally of interest. I think there’s a misunderstanding. My point wasn’t about why wiki posts in the first post are bumped. I was talking about the reasoning behind restricting the `no-bump` API parameter, as mentioned in the GitHub comment: > Should this be restricted to staff API keys? I don’t think we want regular users to be able to bypass bumping (it would allow them to inject spam into topics without bringing them to people’s attention). If spam was truly the concern, then this restriction should apply consistently, not just in the few remaining cases where bumping happens. That’s what surprised me: the reasoning cites spam as a problem here, but bumping isn’t meant as a spam-protection mechanism in, for example, wikis that are the last post in a topic. I do appreciate that wiki posts are bumped on updates (though the UX of being taken to the bottom of the topic while the bump reason is the first post is still [confusing](https://meta.discourse.org/t/wiki-topic-bump-indicator/388673)). My point is just highlighting this apparent inconsistency regarding spam. --- _[View the full topic](https://meta.discourse.org/t/returning-bumping-after-editing-last-post/390033)._