Page MenuHomePhabricator

individual revision tagging categorizing and sorting
Closed, ResolvedPublic

Description

Author: dogshed

Description:
I would like some way to tag individual revisions of an article with user
customizable tags or markers or something.
For example I and some other people could tag the dec 12 15:00 version of an
article with a no vandalism tag. If I see a change in my watchlist I can tag the
newer revision if needed.
A user could then limit his search to those revisions that at least three no
vandalism tags from three different people in the group vandal busters.
A group of religious conservatives could tag revisions as being free of foul
language.
Teachers could mark articles as suitable for children.
The tags should be first of course and then we find things to do with the later.


Version: unspecified
Severity: enhancement

Details

Reference
bz4288

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:59 PM
bzimport set Reference to bz4288.
bzimport added a subscriber: Unknown Object (MLST).

heidi.hysell wrote:

We currently use the wiki as a tutorial generator and when new versions of our
software come out and we have to update the tutorial we would like to be able to
tag the previous complete revision including the images/attachments that are
linked on the page. This need to be done not only on a page level, but also on
a "section" level so that we can tag a complete software product tutorial
section if possible.

patriotact wrote:

would be nice to tag individual sections of articles with different keywords then be able to
search the wikipedia for those tags.

so i could tag 'inventor' on two articles subsection about the inventor and then do a search
for inventor and find the two subsections, would be useful for compiling data from multiple
articles

  • Bug 5976 has been marked as a duplicate of this bug. ***

dogshed wrote:

"The tags should be first of course and then we find things to do with the later."
should be
"The tags should be first of course and then we find things to do with them later."

robin wrote:

This sounds like a good plan. Guess I'm looking for article version
functionality akin to branching in CVS, think it belongs here.

It would be nice to use a Wiki as a software manual, as software is released
pages may be updated and can be tagged as specific to that release. Ideally
navigation will be made by showing the page for the release being viewed. Say
that we're interested in V5.1, say there is no 'User interface' update for V5.1,
the previous version of that page should be shown as it clearly hasn't changed.
Perhaps this is a navigation feature?

As for branching: take a scenario where your manual is on V5.1, but you are also
supporting V4.5 of your software. Say there's a bugfix or other change to V4.5
of an API for example. Perhaps that API is superceeded in later versions of your
S/W. The V5.1 page would maybe state this and point to the successor. However,
one would like to update the V4.5 page to show any bugfix made.

dogshed wrote:

(In reply to comment #2)

would be nice to tag individual sections of articles with different keywords

then be able to

search the wikipedia for those tags.

so i could tag 'inventor' on two articles subsection about the inventor and

then do a search

for inventor and find the two subsections, would be useful for compiling data

from multiple

articles

I think your idea is really cool but you should make it a separate feature
request. Both will have
a better chance of being included. -Jeff

dogshed wrote:

(In reply to comment #5)

This sounds like a good plan. Guess I'm looking for article version
functionality akin to branching in CVS, think it belongs here.

It would be nice to use a Wiki as a software manual, as software is released
pages may be updated and can be tagged as specific to that release. Ideally
navigation will be made by showing the page for the release being viewed. Say
that we're interested in V5.1, say there is no 'User interface' update for V5.1,
the previous version of that page should be shown as it clearly hasn't changed.
Perhaps this is a navigation feature?

I think your idea is really cool but you should make it a separate feature
request. Both will have a better chance of being included. -Jeff

As for branching: take a scenario where your manual is on V5.1, but you are also
supporting V4.5 of your software. Say there's a bugfix or other change to V4.5
of an API for example. Perhaps that API is superceeded in later versions of your
S/W. The V5.1 page would maybe state this and point to the successor. However,
one would like to update the V4.5 page to show any bugfix made.

dogshed wrote:

We could probably use some kind of branching and I think that would be a good
feature
request. I'll do a search to see if it exists. In some cases one should simply
create
their own wiki.

  1. tags could belong to an individual or group.
  2. only group members could place a group owned tag on a revision.
  3. one could search and filter articles by person, group and tag.

If I, Jeff, place a spellcheck tag that belongs to me on a revision
that would be different from Jeff placing a spellcheck tag on a revision
that belongs to the spellmaster group.

dogshed wrote:

We could probably use some kind of branching and I think that would be a good
feature
request. I'll do a search to see if it exists. In some cases one should simply
create
their own wiki. I suppose part of the problem is that "version" can mean revision or
it can mean a variation intended for a different purpose or audience. I really mean
tagging different revisions.

  1. tags could belong to an individual or group.
  2. only group members could place a group owned tag on a revision.
  3. one could search and filter articles by person, group and tag.

If I, Jeff, place a spellcheck tag that belongs to me on a revision
that would be different from Jeff placing a spellcheck tag on a revision
that belongs to the spellmaster group.

dogshed wrote:

I have created bug 6898 for forking of articles. To use your software
documentation example, forking would allow you to create a fork for each version
of your software. The revisions of each fork could then have tags.

electrawn wrote:

We can't do this with metadata templates, such as {{persondata}} ?

-Electrawn

dogshed wrote:

(In reply to comment #11)

We can't do this with metadata templates, such as {{persondata}} ?

-Electrawn

If I mark a revision of an article as "graffiti free" and then someone puts some
graffiti on the article that new revision would also have the "graffiti free"
tag. I want a mechanism where someone in the group that owns the "graffiti free"
tag would have to approve the application of the tag to the new revision.

This kind of tag could be used for lots of things. The expert group could create
a tag "expert reviewed" then if someone like me who knows nothing about most
things puts something in the article the new revision I created would not get
the expert reviewed tag until someone from the "expert reviewed" group approved
my change.

dogshed wrote:

If someone filters their results to show revisions with certain tags then there
may be a question of which revision to edit.

dogshed wrote:

http://upload.wikimedia.org/wikipedia/wikimania2006/9/90/BV1_slides.pdf

It seems something similar is planned for testing on the German Wikipedia.

titoxd.wikimedia wrote:

This sounds like the FlaggedRevs extension
(http://www.mediawiki.org/wiki/Extension:FlaggedRevs), currently being developed.

dogshed wrote:

Sounds like it but I want something more general. I want a system so any person
or any group can create tags and use those tags to sort the articles.

  • This bug has been marked as a duplicate of bug 1189 ***

dogshed wrote:

This is not a duplicate of 1189. It's possible that the tagging described here
could be a way to solve the issue in 1189, but the description here is more
general and covers much more than just vandalism.

Re-duping. The summary on bug 1189 may specify an individual use-case, but they cover the same thing (tagging of edits).

  • This bug has been marked as a duplicate of bug 1189 ***