How should category archiving work?

We have a request from a customer that I’ve been expecting for a while:

We want to remove the beta and alpha categories, and all topics in those categories

Meaning, there are a whole lot of posts in those alpha and beta categories that represent the state of their software at a much older point in time, such that all the topics there are basically irrelevant, forever. (This is also video game software, where after 3 years a game is forgotten forever and never played again, so old beta/alphas of games are especially irrelevant in the world of software.)

The intent of the “archive” action on a topic is to prepare it for eventual archiving. Now that may mean deleting it. Or it could mean moving it to some kind of historical long term offline archives. At any rate, an archive is something that is

  • not of practical current interest
  • might be useful very rarely to someone digging through long term history for obscure reasons
  • helpful to remove from the current active instance to make room for newer, more relevant current content

I believe archiving should be triggered either by:

  • archiving out all topics with a state of archived
  • archiving out all topics in a particular category

I’m not sure we can physically remove the posts and topics from the database without extreme trauma to our codebase, so perhaps the only alternatives are to

  1. delete (all our deletes are soft deletes) every topic in the category
  2. mark the category as archived, and have special handling for topics in archived categories

Then, produce an export file of the archived topics.

This also implies there is a way to selectively bring back a set of archived posts, or an archived category, which is probably way too hard.

I guess the simple thing to do, for now, is

  • just mark every topic in the category (or all archived topics) as deleted for now.
  • make sure we have an ‘archived’ category state (perhaps a date of archive) to look at later.

Any thoughts here?

6 个赞

There is another option that can work quite well, make the category a staff only category.

This effectively “removes” all the posts in one very quick go. Its clean, has simple undo and very minimal side effects that are “staff only”.

That is the way they have it now (I actually checked for that earlier), and it is not what they want.

It is just unnecessary clutter for them at this point, a bunch of obsolete content.

maybe you could provider an admin setting for “archived categories” or some such - add category names there that you want to disappear forever.

nice aspect of that would be that it really removes all the posts in one go, and is reversible, and even the admins won’t be able to see the posts.

Should there not be some way for normal users who are not forum admins to access the archives somehow? Or would that be part of the “special handling”.

Perhaps if we made sure that the archive file was sanitized of secret information, then they could be put up for download. Even if we don’t want it to be searchable.

If the posts get actually removed from the database, we could eventually get a screen like this:

This topic has been archived.

If you want to view it, click below and give us a minute to dig it up.

[ View Archived Topic ] Download archive of Alpha (2013-2014) (0.5GB)

If the removal of the content is the point, then a soft delete like you mention (assuming hard deletes are a problem) should be applied on all of the content, and all of these topics & posts should be excluded from the default backup. Instead, when you do the archiving, they should be put in a separate “Archives” backup of their own.

If you just don’t want your searches getting polluted & slowed down with deprecated posts, and you don’t want archived categories cluttering up your category list, then a “do not search” flag on archived post and a special category that doesn’t show even in staff lists (but retrievable through admin panel somehow) would suffice. Essentially making all topics Unlisted, plus special treatment of the category visibility.

We’ve talked about similar things before:

3 个赞

There may also be some mapping here for moving a category to a different Discourse instance, which we have at least one paying customer wanting to do

What we need:

  • Copy one category
  • Copy all of its sub-categories (10)
  • Copy all posts in these categories (<50)
  • Copy all members that belong to the custom group; keep current usernames, email and passwords of these users on the new forum

Same basic area of work, IMO. Splitting one Discourse into another is a logical thing to do, only difference I can see in this case is that instead of transferring the entire category to /dev/null we are copying it to another Discourse instance…

Anyway keep that in mind as we work on this @neil!

4 个赞

Moving category spec is here:

3 个赞

我知道这已经有些过时了,但随着 Ask Fedora 讨论区网站本身也已运营数年,我开始思考这个问题。该论坛主要用于终端用户故障排查,虽然_某些_话题具有长期价值(深入查阅过往内容往往_在一定程度上_有助于判断某个问题是新出现的,甚至了解其背后的历史原因),但最早的话题还停留在 Fedora Linux 29 时代。我们即将发布 Fedora Linux 36,而_其间已发生了诸多变化_。

我希望那些来自非常旧版本(在我们快速迭代的节奏下,即超过三年前发布)的话题能够:

  • 除非用户主动搜索,否则不显示在站内搜索结果中
    • _绝对_不要作为相似话题被推荐!
  • 或许从 Google 搜索结果中隐藏?这点我还不确定。
  • 禁止新的回复,但…
  • 提供更显眼的“新建话题”链接,以便发现这些话题并有话可说的人能够轻松引用

(实际上,嗯,最后一点对于已关闭的帖子似乎也很适用!)

1 个赞

Discourse 的管理员在删除关闭的帖子和无用内容方面相当严厉。我有时会因为找不到想找的内容而感到遗憾,但这种情况并不常见。我认为采取积极的 moderated 管理方式,比依赖会自动犯下严重错误的自动化系统要好。

2 个赞