Last modified: 2014-01-10 22:11:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22290, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20290 - Add "hide placeholder"
Add "hide placeholder"
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 18493 revdel SWMT
  Show dependency treegraph
 
Reported: 2009-08-17 16:33 UTC by Thatcher
Modified: 2014-01-10 22:11 UTC (History)
16 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Thatcher 2009-08-17 16:33:52 UTC
Currently, the main argument for not permanently disabling Extension:Oversight is that Oversight can do something that RevisionDelete can not, namely, hide all existence of an edit.  For example, suppose an editor signs a talk page when logged out, then logs in and resigns, and asks for oversight of the logged-out edit.  Oversight removes the edit completely, making it look like the editor's only edit was the logged in one.  RevDel can be used to hide the IP, or even fully delete the edit, but even when fully deleted and suppressed, there is a placeholder that indicates that "something" was removed.  

Therefore, add an option to RevisionDelete to "hide the placeholder" from editors who do not have oversight permission.  This will have the same net effect and appearance to most users as oversight, solving the objections of some people to turning oversight off completely.  However, it will be reviewable and reversible.
Comment 1 FT2 2009-08-17 16:50:21 UTC
I actually wouldn't object to a dropdown box similar to that used for page
protection: "show placeholder to [all users | administrators | oversighters]".

That (for me) would be better. Most times a placeholder is fine. The few times
it isn't, it's very likely to be sufficient if only admins (but not the vandal
or mass public) can see the placeholder. It also means if there is a dispute or
behavior comes up for discussion, admins can at least see the true record and
are not misled.

There are only very few cases where placeholders really do need to be
"oversighters only". I can't think of an example easily, and I would suggest
that a local policy might discourage it without very good cause. However for
completeness and because Oversight can be serious stuff, I'd still want it
there for completeness.

But in general, yes, agree with this request.
Comment 2 FT2 2009-08-17 16:52:46 UTC
One thought - placeholder hiding should only be an option if "suppress all aspects" is selected - username, edit summary, revision text and "admin lock". 

If some fields aren't suppressed, or admin-level revisionDelete chosen, then placeholder hiding is not applicable.
Comment 3 Thatcher 2009-08-17 17:04:17 UTC
Yes, hiding the placeholder should only be a live option if the edit is being
fully suppressed otherwise.  Allowing admins to see the placeholder is also a good idea.  This could be down with a drop down, or with
multiple checkboxes "[]Hide placeholder from editors" "[]Hide placeholder from
editors and admins."

There could also be an extra box "[]Fully suppress edit and hide placeholder"
that would do in one click that which would otherwise take 5 clicks.  It might be
too easily used when it shouldn't, although it could be reversed on review.  But  I
probably shouldn't be nitpicking about user interface design.
Comment 4 FT2 2009-08-18 09:44:04 UTC
Try this:

Who should be able to see the placeholder:
[ All users | Admins and oversighters only | Oversighters only]
Comment 5 Deskana 2009-08-18 21:10:04 UTC
I would like to see this implemented. If this is implemented, we can completely phase out use of the "old" oversight.
Comment 6 Aaron Schulz 2009-09-12 21:50:07 UTC
When is this needed?
Comment 7 Thatcher 2009-09-12 22:04:20 UTC
Adding this feature would remove the final objections to disabling the oversight extension.  Oversight is currently deprecated in favor of suppression because suppression is reversible and oversight is not; we would like to phase out oversight completely but some users feel the hide placeholder feature is necessary.
Comment 8 Aaron Schulz 2009-09-13 00:02:17 UTC
Yes, but when is the lack of a placeholder needed? What situation?
Comment 9 John Mark Vandenberg 2009-09-13 00:40:18 UTC
This is needed for times when the revision is not wanted in the history, irrespective of whether all elements of the edit are suppressed.

Usually it is sufficient to push the edit into the deleted history, which is currently achieved by poor mans oversight, often followed by suppression of the deleted revision(s).

The situations have been explained on oversight-l; we can revisit them on functionaries-en if you like, but not here.

Also, oversighted entries must not be converted to RevDel (see bug 18598) on English Wikipedia unless they are only known by oversighters (this situation discussed only on arbcom-l).
Comment 10 FT2 2009-09-13 02:04:56 UTC
It's been discussed numerous times.

A good indication of importance is that the Oversight log was originally public, and afterwards was amended and became non-public. That was a change to function, made specifically to remove the 2006 equivalent of placeholders from public view.

The log gave no more information then, than a placeholder would now. But it was still a problem.

In other words Oversight _originally_ worked as suppression does now - the revision details vanished but some kind of public reference (a log or placeholder) remained. That was later _removed_ for privacy reasons, leaving Oversight as it is now.
Comment 11 Alex Monk 2012-11-03 15:16:50 UTC
These explanations just aren't good enough for me, I see no legitimate use case for completely hiding the fact that a revision even existed.

(In reply to comment #9)
> The situations have been explained on oversight-l; we can revisit them on
> functionaries-en if you like, but not here.

These *MUST* be explained here.

RESOLVED WONTFIX.
Comment 12 John Mark Vandenberg 2014-01-10 00:05:18 UTC
Reopening.
The decision to disregard the risks needs to come from WMF management.
I have provided a bit more info in email to functionaries-en.
Comment 13 John Mark Vandenberg 2014-01-10 00:09:30 UTC
FWIW, it would be sufficient to only use this 'hide placeholder' for old migrated revisions, and prevent it being used on new RevDel actions.
Comment 14 Nathan Larson 2014-01-10 00:18:03 UTC
A request to implement the feature can be one bug report (viz. this one); a request to actually enable the implemented feature on a particular wiki can be another bug report. There is no need to WONTFIX implementing a feature that can be disabled on wikis where its use would be undesirable.

Either way, Bugzilla isn't where one debates whether to enable features on a wiki, unless there are technical issues involved; those policy decisions are made in other venues.
Comment 15 Alex Monk 2014-01-10 01:39:03 UTC
(In reply to comment #12)
> Reopening.
> The decision to disregard the risks needs to come from WMF management.
> I have provided a bit more info in email to functionaries-en.

This is going back to WONTFIX until you explain an adequate reason **here**. I suggest you do not revert it again.

In reply to your email, existence of a revision (with no associated deletion log, no visible author, no comment, or content) and a timestamp are not private information. Oversighters should not be promising anyone about future behaviour of software controlled by developers not under their control.

(In reply to comment #14)
> A request to implement the feature can be one bug report (viz. this one); a
> request to actually enable the implemented feature on a particular wiki can
> be
> another bug report. There is no need to WONTFIX implementing a feature that
> can
> be disabled on wikis where its use would be undesirable.

Implementing this feature to provide to any wiki is undesirable as far as I'm concerned.

(In reply to comment #14)
> Either way, Bugzilla isn't where one debates whether to enable features on a
wiki, unless there are technical issues involved; those policy decisions are
made in other venues.

Yes, however they will have to go through Bugzilla to get it actually implemented so they could enable it.
Comment 16 Nathan Larson 2014-01-10 01:54:59 UTC
(In reply to comment #15)
> Implementing this feature to provide to any wiki is undesirable as far as I'm
> concerned.

You may be right, but that's like saying that it's undesirable for anyone to use crack cocaine. It's still up to the individual to choose rather than for others to make the decision for him. Genes and memes that result in bad choices will be weeded out by natural selection, without the need for the state to intervene.

In the wikisphere, this phenomenon is manifested by wikis that enable harmful features losing users and readers to those wikis that make better decisions. If they persist in making such errors, they may become defunct entirely. So, it's a problem that solves itself.

The development community seems to have embraced the ideal of solving this kind of dispute by making the software modular and having lots of configuration settings in the core, so that volunteer developers can implement whatever features they want, and individual wikis can make their own decisions. It saves a lot of developer time that would otherwise be spent debating the merits of what are best practices. Those debates can be settled instead by editors and readers deciding what they like in a wiki, and deserting those wikis that don't conform to their expectations.
Comment 17 Alex Monk 2014-01-10 03:09:04 UTC
(In reply to comment #16)
> You may be right, but that's like saying that it's undesirable for anyone to
> use crack cocaine. It's still up to the individual to choose rather than for
> others to make the decision for him. Genes and memes that result in bad
> choices
> will be weeded out by natural selection, without the need for the state to
> intervene.

People could indeed patch it into their install, however I do not believe we should not allow such a 'feature' into the official MediaWiki repository unless the requesters are willing to be fully open about their use case.

As for your theory about losing/gaining readers, this is not a reader-facing issue at all. Most will never even see the history page let alone one that has a suppressed edit on it.
Comment 18 Kunal Mehta (Legoktm) 2014-01-10 03:14:00 UTC
(In reply to comment #12)
> Reopening.
> The decision to disregard the risks needs to come from WMF management.

WMF doesn't own MediaWiki, nor do they get the final say on whether something is implemented in core or not.

> I have provided a bit more info in email to functionaries-en.

Is there a reason your info can't be shared publicly? If this feature does end up going into core (or any extension for that matter), there has to be some public justification anyways.
Comment 19 John Mark Vandenberg 2014-01-10 03:24:59 UTC
(In reply to comment #18)
> (In reply to comment #12)
> > Reopening.
> > The decision to disregard the risks needs to come from WMF management.
> 
> WMF doesn't own MediaWiki, nor do they get the final say on whether something
> is implemented in core or not.

Sure. Im not saying the oversight migration feature cant be added without the feature described in this bug. Im saying this feature is needed for enwp migration. The blocking relationship between the bugs is broken now, which is fair enough.

> > I have provided a bit more info in email to functionaries-en.
> 
> Is there a reason your info can't be shared publicly? If this feature does
> end
> up going into core (or any extension for that matter), there has to be some
> public justification anyways.

This bug report contains sufficient justification. As I am not a functionary anymore, I dont think I am empowered to be more descriptive. If you want more info, I suggest asking a WMF staff member who is on functionaries-en.
Comment 20 MZMcBride 2014-01-10 03:49:34 UTC
(In reply to comment #19)
> If you want more info, I suggest asking a WMF staff member who is on
> functionaries-en.

Even if every subscriber to functionaries-en agreed, I'm not sure it would matter here. This is a MediaWiki core technical matter and it seems like a valid wontfix.

In any case, I'll copy Philippe and Maggie on this bug report to comment on the super-secret reasons that make you believe that we must have a feature of this nature in MediaWiki core. I believe both Philippe and Maggie are subscribed to functionaries-en and if not, they'll know a staff member or two who is. :-)
Comment 21 Risker 2014-01-10 04:22:48 UTC
(In reply to comment #18)
> (In reply to comment #12)
> > Reopening.
> > The decision to disregard the risks needs to come from WMF management.
> 
> WMF doesn't own MediaWiki, nor do they get the final say on whether something
> is implemented in core or not.
> 


Just for the record, I think the vast majority of Wikimedians would be surprised to hear that; I'm pretty sure they *do* think that MediaWiki is owned, or at least controlled by, the WMF. That's sort of irrelevant to this bug, though.


> > I have provided a bit more info in email to functionaries-en.
> 
> Is there a reason your info can't be shared publicly? If this feature does
> end
> up going into core (or any extension for that matter), there has to be some
> public justification anyways.

I believe what it comes down to is this:  the original Oversight extension, known to cause certain oddities in the revision table, was long known to be a hack. It was also long known to only be reversible by direct root sysadmin action.  It has not been in use for almost five years (and was disabled shortly after that time). The practices for its use are radically different than those that apply to revision deletion and suppression since 2009: it was almost impossible to get something oversighted unless there was a very, very serious problem with the edit(s) involved, and it was specifically advertised as *permanent*. Suppression, in use since 2009, is specifically advertised as *easily reversible*. Oversight was also specifically advertised as *complete removal including publicly viewable logs* while suppression has always been advertised as leaving the date/time of revision and all unsuppressed aspects of the revision in place and publicly accessible.  The vast majority of oversighted edits involved personal non-public information about users or BLP subjects; those whose information was affected were assured at the time that nobody except for the tiny number of oversighters would ever even know that the edit had been made.  

Thus, while this is a technical change, it is also a change in the social contract directly affecting both users and BLP subjects.  Perhaps that assurance should not have been made, but it was, and it was based on the best information available at the time. In fact, attempts to get certain oversighted revisions "un-oversighted" by developers were soundly rebuffed with the comment that once it was gone, it should be considered permanently gone.  

So...we're in a difficult situation here.
Comment 22 MZMcBride 2014-01-10 04:32:54 UTC
(In reply to comment #21)
> Oversight was also specifically advertised as *complete removal including
> publicly viewable logs* while suppression has always been advertised as
> leaving the date/time of revision and all unsuppressed aspects of
> the revision in place and publicly accessible.

Advertised by whom? If we take every Oversighted edit and set it to the maximum suppression level, what social contract is being violated? Can you explain _specific problems_ with taking this approach? Not abstract problems about vague promises made a half-decade ago, but actual problems (technical or otherwise) that will arise.

Is the issue really that today's oversighters will see previously inaccessible material?

Is a CIA operative in Guatemala going to lose his life because we've revealed the _timestamp_ of an edit from five years ago?

> Thus, while this is a technical change, it is also a change in the social
> contract directly affecting both users and BLP subjects.  Perhaps that
> assurance should not have been made, but it was, and it was based on the best
> information available at the time.

The "best information" at the time was that Oversight was a hack that would one day be replaced. I don't think anyone made a promise that edits that were Oversighted were permanently gone. In fact, quite the opposite: they _could_ still be retrieved, which everybody knew.

> So...we're in a difficult situation here.

I don't think this is a difficult situation. This feature almost certainly isn't going into MediaWiki core. The remaining question is what will happen to particular Oversighted edits on a single particular (and peculiar) wiki, which frankly is outside the scope of this bug report. You probably want bug 32628.
Comment 23 John Mark Vandenberg 2014-01-10 04:37:19 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > If you want more info, I suggest asking a WMF staff member who is on
> > functionaries-en.
> 
> Even if every subscriber to functionaries-en agreed, I'm not sure it would
> matter here. This is a MediaWiki core technical matter and it seems like a
> valid wontfix.
> 
> In any case, I'll copy Philippe and Maggie on this bug report to comment on
> the
> super-secret reasons that make you believe that we must have a feature of
> this
> nature in MediaWiki core. I believe both Philippe and Maggie are subscribed
> to
> functionaries-en and if not, they'll know a staff member or two who is. :-)

I am not advocating for Oversight edits on enwp to be mass-moved to RevDel.  They can stay in the existing data structure outside of core - no worries.  I would be happy if they are carefully moved to RevDel by oversighters.  But if the tech people want to mass move all oversight edits to RevDel, this feature is needed otherwise the tech people are overriding Oversight decisions.  If this feature is implemented, oversighters can then carefully unhide parts of edits as appropriate given the circumstances.

(Thanks Risker for providing a well written explanation)
Comment 24 Trijnstel 2014-01-10 16:15:28 UTC
I totally agree with MZMcBride. Oversighted edits will (as far as I know) moved to RevDel/suppression, thus it's not like they will suddenly be accessible to everyone or to all admins. Besides: all current oversighters have access to the old oversight log so the move won't change that either. And like MZMcBride said: "If we take every Oversighted edit and set it to the maximum suppression level, what social contract is being violated?" I even see a benefit: oversighters can then reverse previous oversight actions, which isn't possible right now.
Comment 25 Risker 2014-01-10 16:39:19 UTC
(In reply to comment #24)
> I totally agree with MZMcBride. Oversighted edits will (as far as I know)
> moved
to RevDel/suppression, thus it's not like they will suddenly be
> accessible to
everyone or to all admins. Besides: all current oversighters
> have access to the
old oversight log so the move won't change that either.
> And like MZMcBride
said: "If we take every Oversighted edit and set it to
> the maximum suppression
level, what social contract is being violated?" I
> even see a benefit:
oversighters can then reverse previous oversight
> actions, which isn't possible
right now.

If they are moved to revision deletion alone, without suppression, then yes there will be hundreds of people who suddenly have access.  As well, in certain cases it will be necessary to track down and suppress log entries.  There are also problems when the suppression was done on pages that were subsequently deleted, because it will recreate those pages, and we have no idea how they're going to come out.  In some cases, a lot of juggling went in to ensuring that no oversightable content existed  in the ultimately-deleted page.  

If this is done in a methodical way by oversighters, then it makes sense; creating a tool that allows oversighters to do this would be more reasonable than an automated, unmonitored process that will suddenly return large amounts of information to the publicly accessible revision table; on enwiki, we're looking at about 10,000 oversighted edits.
Comment 26 Alex Monk 2014-01-10 18:38:26 UTC
(In reply to comment #25)
> If they are moved to revision deletion alone, without suppression, then yes
> there will be hundreds of people who suddenly have access.  As well, in
> certain
> cases it will be necessary to track down and suppress log entries.  There are
> also problems when the suppression was done on pages that were subsequently
> deleted, because it will recreate those pages, and we have no idea how
> they're
> going to come out.  In some cases, a lot of juggling went in to ensuring that
> no oversightable content existed  in the ultimately-deleted page.  
> 
> If this is done in a methodical way by oversighters, then it makes sense;
> creating a tool that allows oversighters to do this would be more reasonable
> than an automated, unmonitored process that will suddenly return large
> amounts
> of information to the publicly accessible revision table; on enwiki, we're
> looking at about 10,000 oversighted edits.

You should go and read the commit before making such ridiculous (and 100% FALSE) speculations on what the script might do.
Comment 27 Risker 2014-01-10 21:24:16 UTC
(In reply to comment #26)
> (In reply to comment #25)
> If they are moved to revision deletion alone,
> without suppression, then yes
> there will be hundreds of people who
> suddenly have access.  As well, in
> certain
> cases it will be necessary to
> track down and suppress log entries.  There are
> also problems when the
> suppression was done on pages that were subsequently
> deleted, because it
> will recreate those pages, and we have no idea how
> they're
> going to come
> out.  In some cases, a lot of juggling went in to ensuring that
> no
> oversightable content existed  in the ultimately-deleted page.  
> 
> If
> this is done in a methodical way by oversighters, then it makes sense;
>
> creating a tool that allows oversighters to do this would be more reasonable
> > than an automated, unmonitored process that will suddenly return large
>
> amounts
> of information to the publicly accessible revision table; on
> enwiki, we're
> looking at about 10,000 oversighted edits.

You should go
> and read the commit before making such ridiculous (and 100%
FALSE)
> speculations on what the script might do.


Hold on, Alex. What commit are you talking about? I don't see any links to commits on this bug report. Even if I did, please keep in mind that we have different skillsets, and I am not a developer and cannot read code or really understand anything in Gerrit. I'm here as an oversighter, one of the handful of active oversighters who has worked with both the oversight extension and the revision-deletion/suppresion extension.  So tell me: how *does* the proposed script deal with oversighted revisions to now-deleted pages? The way the script is described here, it appears to be intending to reinstate all revisions, which logically would mean that it would have to recreate the previously-deleted pages.  And how would we track whether or not logs need changing? Remember that revdeletion/suppresion doesn't automatically result in revdel/suppression of all log entries.
Comment 28 Alex Monk 2014-01-10 22:11:19 UTC
(In reply to comment #27)
> Hold on, Alex. What commit are you talking about? I don't see any links to
> commits on this bug report. Even if I did, please keep in mind that we have
> different skillsets, and I am not a developer and cannot read code or really
> understand anything in Gerrit. I'm here as an oversighter, one of the handful
> of active oversighters who has worked with both the oversight extension and
> the
> revision-deletion/suppresion extension.  So tell me: how *does* the proposed
> script deal with oversighted revisions to now-deleted pages? The way the
> script
> is described here, it appears to be intending to reinstate all revisions,
> which
> logically would mean that it would have to recreate the previously-deleted
> pages.  And how would we track whether or not logs need changing? Remember
> that
> revdeletion/suppresion doesn't automatically result in revdel/suppression of
> all log entries.

The debate going on here is over whether this feature request (allowing suppression to completely hide the existence and timestamp of a revision - for old OS'd revisions anyway) should be solved before the commit on bug 18598 is approved. That bug is about making a script to automatically convert all revisions in Oversight's 'hidden' table to properly suppressed edits. And yes, I'm sorry, I will try to explain what was wrong:

(In reply to comment #25)
> If they are moved to revision deletion alone, without suppression, then yes
> there will be hundreds of people who suddenly have access.

* Suppression is a part of RevisionDelete. The current version of the conversion script applies suppression - full hiding from admins as well as unprivileged accounts.

(In reply to comment #25)
> There are
> also problems when the suppression was done on pages that were subsequently
> deleted, because it will recreate those pages

No, it can tell that a page no longer exists and will place the new revision in either 'revision' or 'archive' (the table where page-deleted revisions get moved to).
(This is based on the page's ID rather it's title, therefore I believe there shouldn't be any issues if that page title later has been recreated/restored - the new page will have a different ID and therefore the OS'd revision should go to the archive.)

(In reply to comment #25)
> creating a tool that allows oversighters to do this would be more reasonable
> than an automated, unmonitored process that will suddenly return large
> amounts
> of information to the publicly accessible revision table

The public views of the revision table do not allow access to suppressed information - the hidden fields just appear to be NULL. If they did that would be a huge security issue, but obviously not related to this script. I am unaware of any risk relating to storing suppressed/OS'd data in the revision table (it's definitely already being done).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links