[RFC] Post Revisions

[drathbun]

I've made my opinion known. And earlier in this very topic I said:

On the permissions thing... I think the more options you can provide, the more flexible the feature will become, and the better it will be received.

I'm fairly certain that the design involves a second table to store post versions rather than storing them within the existing posts table. So searching would definitely be a separate process.

[Edit]
Earlier I suggested looking at some board statistics to see what sort of edit frequency there is. Here are stats from my phpBB2 board. Now these stats are not 100% effective since user edits on their post when the post is the last post in a topic were originally not recorded. Post edits were only counted when they were not the last post. Also moderator edits of other user posts were not tracked. I say "were" because some time back (several years ago?) I changed the edit process so that every edit was counted. I did this in order to gather information for building my own post revision tracking system. So, enough of the disclaimer. Here are the numbers:

Code: Select all

+-----------------+----------+
| post_edit_count | count(*) |
+-----------------+----------+
|               0 |   779246 |
|               1 |     6095 |
|               2 |      754 |
|               3 |      151 |
|               4 |       53 |
|               5 |       16 |
|               6 |       12 |
|               7 |        5 |
|               8 |        6 |
|              12 |        1 |
|              13 |        1 |
|              14 |        1 |
|              15 |        1 |
|              17 |        1 |
|              24 |        1 |
|              32 |        1 |
+-----------------+----------+

You may or may not recall that phpBB2 includes a field called post_edit_count that is incremented as use to display the "this post has been edited n times" message. The percentage of posts that have been edited and therefore would require revision tracking is insignificant. Out of over 780,000 posts, 99% of them have never been edited. If I total up the percentages for any post that has been edited at least once, it amounts to less than one percent. The total number of revisions (determined by the edit count times the number of times that count appears) is 8,630. This on a board with over 3/4 million posts.

If I extrapolate the same ratio to phpbb.com there would be less than 42,000 rows in the post revisions table.

My point is, the expected number of post revisions is extremely low. Providing the ability to prune revisions would seem to be superfluous. On smaller boards with 50,000 posts the projected number of post revisions is 500.

Suppose that my numbers are completely off because phpBB2 did not fully track post edits. Well, suppose that revision tracking doesn't kick in until there has been at least one reply to the post? That would exactly mimic the way phpBB2 originally worked, and the numbers above would be valid. BTW, the topics that have been edited the most times (32 in one case) are the FAQ topics, which are updated much more frequently than normal posts.

Anyway, I just wanted to put some numbers behind the discussion so it's a bit more practical than fully theoretical. If someone has access to phpbb.com database to pull the same numbers, that would prove to be very interesting I think.

[EXreaction]

I like those stats drathbun. I can only guess what the accurate edit count would be since that statistical flaw you mentioned, but I can't imagine it being greater than 10% of posts that are edited right away.

Assume that some user posts a spam or warez link in the Wiki post. Does it make sense to edit the post to remove the link, knowing that users can still see the link in the revisions? I think that it makes more sense to delete the revision.

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

Besides what Bliss said (which I completely agree with), if you view revisions as a true audit trail, then there should not be a Purge All Revisions feature or a depth limit (as you previously said). So how about a compromise -- have Can protect revisions and Can delete revisions Moderator permissions. Then people who like true audit trails can prohibit deleting revisions and people who aren't that hard-line can allow it.

I suppose that's the best solution, to add permissions.

Yes, a permission setting seems like the best option. The delete feature doesn't seem to me like it would take much work since you'll already have the backend to protect revisions (it's essentially the same thing, but with a different sql query), and some people seem to want it.

[imkingdavid]

Thanks for the statistics. I have added two new local moderator permissions, m_delete_revisions and m_protect_revisions, to regulate who can do those two tasks.

I'm fairly certain that the design involves a second table to store post versions rather than storing them within the existing posts table. So searching would definitely be a separate process.

Yes and no. In my original design, all version-able content was decoupled from the posts table and a new column was added to specify which revision of the post to display when querying the post. In that case, every single post would have at least one revision (that being the original content of the post, which is an exact duplication of the posts table). However, I was told to not decouple the information because that can lead to problems later on (I am not sure exactly what, but apparently it's significant enough of an issue that it is not ideal).

So how the current implementation is, the current revision of the post is always stored on the posts table. So, posts will not have a revision until they are edited. The first revision to be stored is marked automatically as protected. This way, the original post content is preserved and is not pruned via the cron tasks. Any time a post is edited or reverted to a different revision, the current post content is stored as a new revision, and the entry on the posts table is updated with the new content. Note that when reverting multiple times, this may cause the existence of duplicate revisions; this is unfortunate, as it creates clutter, but is also not easily remedied. Originally, when I had the revisions decoupled, all I had to do was update the revision ID on the post table, so no new revision had to be created, but now I have to juggle the data around.

[EXreaction]

I do not think the duplicate revisions when reverting multiple times is an issue. While there are more complicated ways that might save a Kb or two every time that is done, it shouldn't be too often to make an difference. It's better to just treat it like a new post so that the history is preserved than ignore it because it was a revert.

[Pony99CA]

I like those stats drathbun. I can only guess what the accurate edit count would be since that statistical flaw you mentioned, but I can't imagine it being greater than 10% of posts that are edited right away.

Yes, the stats are interesting, so thanks for those. However, that may change with Wiki posts, which I suspect will get edited much more than posts that only the user and moderators can edit.

Which reminds me -- will there be a new pre-defined role for the Wiki permissions? I can envision some forums where topics would basically be one Wiki post (possibly without the ability to reply). You could even start your own Wikipedia. It's not a huge deal as roles are easy to create, but I thought that I'd ask.

Steve

[imkingdavid]

I haven't really given permission roles a thought, but I'll consider it.

[EXreaction]

I'm not sure there need to be additional roles created for this, but maybe added to the default roles.

[Pony99CA]

I'm not sure there need to be additional roles created for this, but maybe added to the default roles.

You'll certainly need to decide on a default for the current roles. However, I don't see a lot of boards allowing every new user the ability to create and/or edit Wiki posts. They'll probably have a group that is allowed to do that, so having a role to easily select may be useful.

But, as I said, it's not high priority by any means. If it is decided to add a new role (or roles), the permissions for those roles should probably be discussed here, though.

Steve

[naderman]

I don't see why we shouldn't allow users to create wiki posts by default (i.e. through the standard access roles). What's the downside?

[Pony99CA]

I don't see why we shouldn't allow users to create wiki posts by default (i.e. through the standard access roles). What's the downside?

Maybe none. In fact, maybe new users should have Wiki posts set on by default. That way, if they spam, anybody can edit their posts without having to wait for a moderator to clean it up.

I'm more worried about allowing new users to edit Wiki posts. I don't want some untrusted new user having "fun" by wiping out posts. Sure, a moderator could revert those posts (preferably by deleting the revision ), but that could waste a lot of time.

Steve