Wikimedia Bugzilla is closed!

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.

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.

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.

Try this:

Who should be able to see the placeholder:
[ All users | Admins and oversighters only | Oversighters only]

I would like to see this implemented. If this is implemented, we can completely phase out use of the "old" oversight.

When is this needed?

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.

Yes, but when is the lack of a placeholder needed? What situation?

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).

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.

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.

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.

FWIW, it would be sufficient to only use this 'hide placeholder' for old migrated revisions, and prevent it being used on new RevDel actions.

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.

(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.

(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.

(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.

(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.

(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.

(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. :-)

(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.

(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.

(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)

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.

(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.

(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.

(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.

(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).