Wiki edit event collapsing

[daniel]

If the same user edits a page more than once within a short period of time (an hour or a day even maybe?), the timeline could show only a single event and the counted number of changes made.

Example: ​http://moinmoin.wikiwikiweb.de/RecentChanges

[daniel]

#62 is related to this.

[Christopher Lenz]

#566 has been marked as duplicate of this ticket.

[Christian Boos]

This enhancement would also provide an alternative for implementing the minor edit feature found on some wikis. See #1981.

[anonymous]

Writing pages

Writing and creating pages is simple. If you see a page that you wish to change, just press the "Edit" link. You will then receive a page where you can edit the information. When you subsequently press "Submit", having done your changes, the page is updated on the server.

Instead of using regular HTML code, all content is written as plain text which is formatted into HTML when viewed.

The following is true for all pages:

• The first line on any page will always become a header

• If you wish to link to other pages, you can write links like this: \[\[Pagename|Description]]. For example, to make a link to the main page (index), you can write: \[\[index|Main page]].

• To link to a specific revision of a document, such as version 1.31 of index page, use a link like \[\[index/1.31|index]]

• You can create *bold* or _underlined_ text by putting * or _ on both sides of a text.

• Unnumbered lists (like this) is written by putting *, in front of all rows.

• Numbered lists are written by putting a number (1, 2, 3…) in front of every row.

• Three dashes or more after each other produces a horizontal line across the page.

If someone creates a link to a page that doesn't exist yet, it will be shown by a small questionmark following the description. By pressing the questionmark, a blank page is received where one can create the page.

For a fuller description of the syntax, see the documention for the [[HTML::FromText]] perl module.

—-

Read AboutThisWiki, Nyetwork, and MiniWiki

[anonymous]

#2508 has been marked as dupe of this ticket.

[Christian Boos]

What about this:

• prefill the Comment about this change (optional): field with the minor edit (won't be shown in the timeline) value.
• Only show a wiki change entry in the Timeline if the change comment doesn't start with minor edit

That would be simple and effective.

[Christian Boos]

Implementation of the above idea is trivial:

trac/wiki/web_ui.py

@@ -137 +137 @@
                            "FROM wiki WHERE time>=%s AND time<=%s",
                            (start, stop))
             for t,name,comment,author in cursor:
+                if comment.startswith('minor edit'):
+                    continue
                 title = Markup('<em>%s</em> edited by %s', name, author)
                 if format == 'rss':
                     href = self.env.abs_href.wiki(name)
@@ -286 +288 @@
             page.readonly = req.args.has_key('readonly')
 
         author = req.args.get('author', get_reporter_id(req))
-        comment = req.args.get('comment', '')
+        comment = req.args.get('comment',
+                               "minor edit (won't appear in the timeline)")
         editrows = req.args.get('editrows')
         if editrows:
             pref = req.session.get('wiki_editrows', '20')

[Lutz <webkontakt@…>]

I don't like the "minor edit" idea at all. People are generally lazy with regard to such messages (at least in my project they are, besides me noone ever wrote a comment when editing a wiki page), and the result will be that now every edit will be a minor edit, and no wiki change will ever appear in the timeline or the RSS feed.

Furthermore, relevant changes must appear in the timeline, and it's not up to just one person to decide what is relevant. You can easily produce a bug with a change you consider minor, without giving anyone the chance to notice the change at all. That's not acceptable.

Please do not implement this behavior! (I still prefer the idea to collapse entries without a comment from the same user within a certain time period).

[Christian Boos]

Well, combined with #2646 (preview change comment at the top of the preview) this is less a problem, because people will clearly see when they'll mark a change as minor edit. So at least this will prevent most unintentional minor edit indications.

As for making all changes to wiki pages mandatorily visible, well, that's a matter of taste. Most major wikis have this feature (MediaWiki, MoinMoin, TWiki, … see the ​wiki matrix). You also have this in Trac for the Ticket changes: not every ticket change makes up in the Timeline by default.

As for the alternative way to collapse wiki events, it's certainly problematic too: if you don't want your edit to appear in the Timeline, you'd have to leave the change comment blank… Not very a very good practice, as you deplore above. With my solution, you could write comments like: minor edit: removing the dead links

[Christopher Lenz]

I basically agree with Lutz here. Marking a change as minor edit to make it not appear on the timeline would be great for spammers. At the very least we need wiki change notifications before we introduce minor edits.

Also, I don't really like the idea of putting the minor edit option as free text in the comment box. Seems rather dirty.

[Christopher Lenz]

… and I, too, prefer the original suggestion.

[Christian Boos]

Ok, I withdraw the "minor edit" proposal.

[Christian Boos]

… and I'll implement the Wiki event collapsing.

Note that there's also #3421, the same feature but for changesets.

One possibility would be to implement the merging at the generic level, in the Timeline module. There we could group together consecutive events of the same kind, which have the same author:

• The advantage with this approach would be that there would be no need to specify a date interval for grouping related changes. For example, we could display the start and end date of the grouped changes, and maybe other visual indication that the event is actually a group of changes.
• The disadvantage would be to loose the ability to provide a pertinent link for the event corresponding to the grouped changes.

At the opposite, if the grouping were to be done in each ITimelineProvider:

• The disadvantages would be the additional complexity spread over different modules, the need to specify a timespan for grouping changes
• The advantage would be the possibility to provide an useful href or (diff) link in the case of Wiki pages, covering the range of changes.

[Christian Boos]

#7590 was closed as duplicate (it's rather a duplicate of #1981, but that one is closed and redirects here).

To summarize the status of the discussion for this topic: instead of marking a change as minor edit (which might be used to hide important changes), in order to reduce the clutter in the timeline, many successive changes could be collapsed in a single multiple edits event (see sample in #2508).

(as for the milestone, feel free to move it back to 0.12 once there's a patch)

[Ryan J Ollos <ryano@…>]

As I described in #10020, it would still be useful to have a minor edit option, even if it is not used to collapse events in the timeline. After reading this ticket, I see that it could be implemented in one of 2 ways:

• 1.1 A minor edit checkbox that sets a boolean in the wiki database table.
• 1.2 A minor edit keyword(phrase) for the comment box.

I'd prefer (1), and would take a shot at implementing it if others like the idea and there is the possibility of having the patch accepted.

As for whether minor edits appear in the timeline, it seems there are 3 possibilities:

• 2.1 Ignore whether an edit is minor and just show all wiki changes in the timeline, displaying (minor edit) just to the right of the (diff) link.
• 2.2 Have a trac.ini config option that determines whether minor edits are shown in the timeline.
• 2.3 Allow minor edits to be filtered from the timeline, similar to what I proposed in #9098 (though comments in that ticket say the timeline filters would then have too many options).

I'd prefer (2.1), particularly since its not exclusive of (2.2) and (2.3).