Feature Proposal: Improved System for User Contributions

Motivation

A better system (i.e. more integrated) system for listing all edits of a particular user is needed. Collaboration projects in the sciences and humanities need this system for giving proper credit to contributors.

Description and Documentation

We use TWiki as a collaboration platform for an international and interdisciplinary research project (see http://www.scribeproject.org). For many of our scholars and developers it is crucial to get full credit for their contributions to the project. It is therefore important for us to have a system that lists all the edits of a particular contributor for all topics. Ideally this functionality should be incorporated into the user sites. We would love to see something along the lines of Wikipedia's "user contributions" functionality (see for instance http://en.wikipedia.org/wiki/Special:Contributions/Matthias_R%C3%B6der).

This issue has come up at HowToGenerateListOfUserEdits and CrawfordCurrie has suggested to make it a feature request.

I am not a developer myself but I would be happy to help wherever possible to make this feature available to TWiki users soon.

Examples

http://en.wikipedia.org/wiki/Special:Contributions/Matthias_R%C3%B6der

Impact

Having this feature would make TWiki much more attractive for research groups in the sciences and humanities where giving proper credit is of great importance.

Implementation

-- Contributors: MatthiasRoeder - 19 Jul 2007

Discussion

I like this proposed feature. I have often wanted to do the same thing when cleaning up spam on my public TWiki.

-- JasonHill - 19 Jul 2007

Sounds fantastic!

-- KeithHelfrich - 19 Jul 2007

That's a super idea! Much easier in 4.2, in the light of the changes I made that make traversing the list of changes much easier.

Another approach (rather than a brute-force processing of all changes) would be to cache a list of changes made by each user, and use that list to generate the history. I suspect it's the way wikipedia works (because of the speed). That could easily be done in a plugin, though I'm not sure how you would characterise the changes - wikipedia has the luxury of a limited selection of possible "change natures" - e.g. "spelling correction", "disambiguation", "flame". Perhaps a comment made at the time of the save?

Anyway, all a plugin would need to do is to provide a beforeSaveHandler to maintain a record of the changes made by the user in the plugins work area. The only core change that would be required would be some way to get a user comment into the history; something that has been wanted for a long time now.

Am I going to work on it? Sorry, no, too many other irons in the fire.

-- CrawfordCurrie - 20 Jul 2007

What should this plugin do? I mean, what should the output look like: exactly the same as the wikipedia one, or something more "complex"?

-- RafaelAlvarez - 20 Jul 2007

The output if the wikipedia function is great. So, I guess it should be a list of that user's edits with links to the topics and links to the history page of those topics. On the history page one could see the difference between the old version and the edit of that user. (Just like on wikipedia) Here is an exmaple for that: http://en.wikipedia.org/w/index.php?title=Music_history&diff=prev&oldid=142655219

-- MatthiasRoeder - 20 Jul 2007

One more thing that comes to my mind: on a lot of pages we are using the CommentPlugin (like on this discussion thread). Will those changes also be listed on the user pages if we implement the system as a plugin? I think it is important that all changes show up, no matter how they were done (i.e. by editing the topic or by typing a comment in a comment box).

-- MatthiasRoeder - 20 Jul 2007

Yes

-- CrawfordCurrie - 21 Jul 2007

Thanks Jason, Keith, Rafael and Crawford for your support with this change proposal! It's great to see that there are others who are interested in this functionality. I was wodering about a couple of things:

• Have we agreed that this functionality should be implemented as a plugin? To me as a non-programmer it seems that this functionality should be part of every future TWiki release. It's the kind of basic function that I would expect to be a core function. But then I again I am not sure what it means if a feature is implemented to the core. What are the pros and cons of the plugin approach?

• List of contributions could be generate everywhere on the TWiki site. Just like the Comment Plugin is evoked. (Is that actually true?)
• ...

• Functionality does not come as a default. Needs to be installed seperately.
• ...

• Is anyone of you interested in actually programming this? I know that Crawford doesn't have the time at the moment, but what about the others? Is there anything I can do to publicize this change proposal amongst other developers?

• What else is there that I (as a non-computer guy) can do at the moment? Write more detailed specs?

-- MatthiasRoeder - 21 Jul 2007

TWiki already have several functionalities that implemented as Plugins (SpreadSheetPlugin, TablePlugin, EditTablePlugin). These "Core Plugins" are shipped with the main TWiki distribution and enabled by default. There are two advantages to this approach:

• Admins can easily choose to disable any functionality that is not required.
• The functionality can continue evolving independently of the Core code. This means that enhancements can be installed and tested right away without waiting for the next TWiki release.
• Because of the previous point, the feature can be tested continually, almost guaranteing that it will be mostly bugfree at the time of the next TWiki release.

-- RafaelAlvarez - 23 Jul 2007

Excellent! So a plugin seems to be the perfect choice then! What's next? Would you like to program such a plugin? If not, how do I find contributors? Many thanks for everyone's help!

-- MatthiasRoeder - 27 Jul 2007

This would be a much easier implementation if TWiki had a relational database backend. As CrawfordCurrie mentioned, we could cache a list of changes per user, but that just creates another slow flat file to trudge through. Including something like SQLite in the requirements for TWiki might help make features like this more robust instead of contributing to slowing things down.

-- MarkKeisler - 02 Aug 2007

see DatabaseStore ?

-- SvenDowideit - 02 Aug 2007

I like this feature because I've been using Twiki as a course website for distance learning classes and the CommentPlugin for a basic discussion / blog feature. The feature under discussion would make it easier for me to grade students on their contributions.

-- StephenGilbert - 10 Aug 2007

Note that a list of changes already exist, the log files. looking for changes by a user is thus a simple grep in these files. I have used this method to code a simple shell script to provide a global view of last changes (bin/ks_lastchanges.sh in the Koala Skin. See a demo at http://wikix.ilog.fr/wiki/bin/ks_lastchanges.sh/31 )

-- ColasNahaboo - 10 Aug 2007

Hmm, I'd like to have this feature as well. If I could only code:-(

-- CarloSchulz - 01 Apr 2008

This feature isn't that hard to implement as a plugin.

-- MichaelDaum - 01 Apr 2008

and really could be combined as a further developent of ContributorsPlugin which does the inverse - listing all contributors to a topic.

-- SvenDowideit - 02 Apr 2008

That plugin just reads revision information of one topic. The proposal is about logging and displaying all recent save actions of each user all over the wiki ... a different beast.

-- MichaelDaum - 02 Apr 2008

does the inverse even?

-- SvenDowideit - 02 Apr 2008

SearchEnginePluceneAddOn solves this problem - just try name:UserName in search query

-- SopanShewale - 09 Apr 2008

Not really: a name:UserName will only display those topics that nobody else changed in the meantime. Once someone else changes the topic, and becomes the most recent topic author, the plucene will take you out of the index for that topic.

-- MichaelDaum - 09 Apr 2008

Oh yes...that is correct Michael

-- SopanShewale - 14 Apr 2008

although I understand the feature requested above calls for "all the edits of a particular contributor for all topics" the search I use on my TravisBarker page fills a similar need. It simply lists all topics which contain "TravisBarker" and presents them in a table. Not exactly what your looking for but it might be "good enough" as a temporary solution until this plugin can be developed.

in the code below replace "TravisBarker" with the name in question and paste it into your topic:

---++ Topics I have contributed to.
%TABLE{sort="on" initsort="2" initdirection="up"}%
|* Topic *|* Last Modified *|* Last Editor *|
%SEARCH{"TravisBarker" nosearch="on" nototal="on" web="all" format="|$web.$topic|$date|$username|" }%

-- TravisBarker - 14 Apr 2008

Only works on TWiki.org. Caution: this will take you server down, please use some sort of caching for a page like that, e.g. using VarCachePlugin.

-- MichaelDaum - 14 Apr 2008

Michael makes it sound like I'm actually trying to break something with the idea above:

Actually, the Caution is a bit... off, the search i gave has worked on every TWiki I've ever installed. including this working example. Saying it will take your server down is a bit harsh. Maybe better to say it could cause slower responses if overused by people with high page counts or on TWikis with high page counts. So here is my caution. Over use of the SEARCH feature in general is cpu intense and usually not a good idea.

-- TravisBarker - 14 Apr 2008

The problem with %SEARCH{"TravisBarker" besides from the cpu impact is that it only works in an environment where people mark each of their contributions with their signature. If you have contributed to a topic but decided for what ever reason to delete your name from that topic %SEARCH{"TravisBarker" won't find it.

-- CarloSchulz - 15 Apr 2008

Travis, sorry for being harsh. IMHO, there's no need to recompute the list of a user's contributions everytime. TWiki already knows when which topic has been editted by whom. Its in the logs. Just get it out of there.

-- MichaelDaum - 15 Apr 2008

MichaelDaum no offense taken, and for the record I'm all for this FeatureRequest as well.

-- TravisBarker - 16 Apr 2008

I think that the solution to this is to implement a plugin that parse the logs and presents the result.

I do not see a new core feature here. This proposal screams to be implemented as a plugin and I do not even think it is particularly difficult to make.

-- KennethLavrsen - 11 Jun 2008

Hi Kenneth! Thanks for your input! Would you be interested in working on the plugin? Unfortunately I am not a programmer, so I wouldn't know what to do. Cheers,

-- MatthiasRoeder - 12 Jun 2008