Hiding Special:UnwatchedPages

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Hiding Special:UnwatchedPages

Aryeh Gregor
Why do we hide Special:UnwatchedPages from regular users?  Unwatched
pages are something that people should know about so they can be sure
to watch them.  If no one is actively watching a page, it's more
likely that vandalism will stick around.  Yes, vandals and trolls
could abuse the info, but they could abuse all sorts of other features
too, and that's not a reason to deny them to legitimate users.  If
there is any such threat, then that will just encourage legitimate
users to watch the pages, thereby removing them from the list.

So I suggest we set $wgGroupPermissions['*']['unwatchedpages'] = true;
in DefaultSettings.php.  Or maybe 'user' instead of '*', if people
prefer.  Does anyone object?

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Chad
On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor
<[hidden email]> wrote:

> Why do we hide Special:UnwatchedPages from regular users?  Unwatched
> pages are something that people should know about so they can be sure
> to watch them.  If no one is actively watching a page, it's more
> likely that vandalism will stick around.  Yes, vandals and trolls
> could abuse the info, but they could abuse all sorts of other features
> too, and that's not a reason to deny them to legitimate users.  If
> there is any such threat, then that will just encourage legitimate
> users to watch the pages, thereby removing them from the list.
>
> So I suggest we set $wgGroupPermissions['*']['unwatchedpages'] = true;
> in DefaultSettings.php.  Or maybe 'user' instead of '*', if people
> prefer.  Does anyone object?
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Sounds reasonable to me. There's many more important metrics than
"does at least one account have this article on their watchlist." It's zero
indication that articles are being actively monitored by interested parties,
which is really what vandals would want to know.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

David Gerard-2
In reply to this post by Aryeh Gregor
2010/1/19 Aryeh Gregor <[hidden email]>:

> Why do we hide Special:UnwatchedPages from regular users?  Unwatched
> pages are something that people should know about so they can be sure
> to watch them.  If no one is actively watching a page, it's more
> likely that vandalism will stick around.  Yes, vandals and trolls
> could abuse the info, but they could abuse all sorts of other features
> too, and that's not a reason to deny them to legitimate users.  If
> there is any such threat, then that will just encourage legitimate
> users to watch the pages, thereby removing them from the list.


The reason was so that they wouldn't be an obvious vandal magnet.

As is, the list is generally empty, isn't it?

You may wish to do this per community, if you want to change it.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon
In reply to this post by Chad
I assume that you haven't been following the Drama Of The Week on enwiki?
In the latest episode, MZMcBride summons down the wrath of the gods by
giving a banned editor and prolific Wikipedia critic a list of 20 unwatched
biographies; the banned editor uses an army of socks to start a "breaching
experiment", vandalising the articles in interesting ways and monitoring how
long they remain unreverted; and MZMcBride resigns admin status *again* in
the face of a third ArbCom case over the whole issue.

I agree with a lot of MZ's reasoning ([1]) about the uselessness of "number
of watchers" as a metric for vandal risk.  But this is probably the worst
time in the past two years to be thinking about opening up
Special:UnwatchedPages.

--HM

[1] http://en.wikipedia.org/wiki/User_talk:MZMcBride#Full_e-mail_reply

"Chad" <[hidden email]> wrote in message
news:[hidden email]...

> On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor
> <[hidden email]> wrote:
>> Why do we hide Special:UnwatchedPages from regular users?  Unwatched
>> pages are something that people should know about so they can be sure
>> to watch them.  If no one is actively watching a page, it's more
>> likely that vandalism will stick around.  Yes, vandals and trolls
>> could abuse the info, but they could abuse all sorts of other features
>> too, and that's not a reason to deny them to legitimate users.  If
>> there is any such threat, then that will just encourage legitimate
>> users to watch the pages, thereby removing them from the list.
>>
>> So I suggest we set $wgGroupPermissions['*']['unwatchedpages'] = true;
>> in DefaultSettings.php.  Or maybe 'user' instead of '*', if people
>> prefer.  Does anyone object?
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> Sounds reasonable to me. There's many more important metrics than
> "does at least one account have this article on their watchlist." It's
> zero
> indication that articles are being actively monitored by interested
> parties,
> which is really what vandals would want to know.
>
> -Chad
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Chad
On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon <[hidden email]> wrote:

> I assume that you haven't been following the Drama Of The Week on enwiki?
> In the latest episode, MZMcBride summons down the wrath of the gods by
> giving a banned editor and prolific Wikipedia critic a list of 20 unwatched
> biographies; the banned editor uses an army of socks to start a "breaching
> experiment", vandalising the articles in interesting ways and monitoring how
> long they remain unreverted; and MZMcBride resigns admin status *again* in
> the face of a third ArbCom case over the whole issue.
>
> I agree with a lot of MZ's reasoning ([1]) about the uselessness of "number
> of watchers" as a metric for vandal risk.  But this is probably the worst
> time in the past two years to be thinking about opening up
> Special:UnwatchedPages.
>
> --HM
>
> [1] http://en.wikipedia.org/wiki/User_talk:MZMcBride#Full_e-mail_reply
>
> "Chad" <[hidden email]> wrote in message
> news:[hidden email]...
>> On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor
>> <[hidden email]> wrote:
>>> Why do we hide Special:UnwatchedPages from regular users?  Unwatched
>>> pages are something that people should know about so they can be sure
>>> to watch them.  If no one is actively watching a page, it's more
>>> likely that vandalism will stick around.  Yes, vandals and trolls
>>> could abuse the info, but they could abuse all sorts of other features
>>> too, and that's not a reason to deny them to legitimate users.  If
>>> there is any such threat, then that will just encourage legitimate
>>> users to watch the pages, thereby removing them from the list.
>>>
>>> So I suggest we set $wgGroupPermissions['*']['unwatchedpages'] = true;
>>> in DefaultSettings.php.  Or maybe 'user' instead of '*', if people
>>> prefer.  Does anyone object?
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>
>> Sounds reasonable to me. There's many more important metrics than
>> "does at least one account have this article on their watchlist." It's
>> zero
>> indication that articles are being actively monitored by interested
>> parties,
>> which is really what vandals would want to know.
>>
>> -Chad
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Last time I checked, we're a separate project from enwiki (thank god).
If we change the software default, we're certainly free to do so. Just
like enwiki is certainly free to request a config change to re-lock it;
which I'd expect they'd do.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon

--------------------------------------------------
From: "Chad" <[hidden email]>
Sent: Tuesday, January 19, 2010 4:18 PM
To: "Happy-melon" <[hidden email]>; "Wikimedia developers"
<[hidden email]>
Subject: Re: [Wikitech-l] Hiding Special:UnwatchedPages

> On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon <[hidden email]>
> wrote:
>> I assume that you haven't been following the Drama Of The Week on enwiki?
>> In the latest episode, MZMcBride summons down the wrath of the gods by
>> giving a banned editor and prolific Wikipedia critic a list of 20
>> unwatched
>> biographies; the banned editor uses an army of socks to start a
>> "breaching
>> experiment", vandalising the articles in interesting ways and monitoring
>> how
>> long they remain unreverted; and MZMcBride resigns admin status *again*
>> in
>> the face of a third ArbCom case over the whole issue.
>>
>> I agree with a lot of MZ's reasoning ([1]) about the uselessness of
>> "number
>> of watchers" as a metric for vandal risk.  But this is probably the worst
>> time in the past two years to be thinking about opening up
>> Special:UnwatchedPages.
>>
>> --HM
>>
>
> Last time I checked, we're a separate project from enwiki (thank god).
> If we change the software default, we're certainly free to do so. Just
> like enwiki is certainly free to request a config change to re-lock it;
> which I'd expect they'd do.
>
> -Chad
>

We are indeed, and we can do whatever we like to the software defaults.  But
changing config settings on WMF wikis is a whole different kettle of fish,
and that's what we're really talking about here.  Changing things on a whim
and then requiring communities to build a consensus **to change them back**
is not how we generally approach site configuration.

--HM

 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Chad
On Tue, Jan 19, 2010 at 11:26 AM, Happy-melon <[hidden email]> wrote:

>
> --------------------------------------------------
> From: "Chad" <[hidden email]>
> Sent: Tuesday, January 19, 2010 4:18 PM
> To: "Happy-melon" <[hidden email]>; "Wikimedia developers"
> <[hidden email]>
> Subject: Re: [Wikitech-l] Hiding Special:UnwatchedPages
>
>> On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon <[hidden email]>
>> wrote:
>>> I assume that you haven't been following the Drama Of The Week on enwiki?
>>> In the latest episode, MZMcBride summons down the wrath of the gods by
>>> giving a banned editor and prolific Wikipedia critic a list of 20
>>> unwatched
>>> biographies; the banned editor uses an army of socks to start a
>>> "breaching
>>> experiment", vandalising the articles in interesting ways and monitoring
>>> how
>>> long they remain unreverted; and MZMcBride resigns admin status *again*
>>> in
>>> the face of a third ArbCom case over the whole issue.
>>>
>>> I agree with a lot of MZ's reasoning ([1]) about the uselessness of
>>> "number
>>> of watchers" as a metric for vandal risk.  But this is probably the worst
>>> time in the past two years to be thinking about opening up
>>> Special:UnwatchedPages.
>>>
>>> --HM
>>>
>>
>> Last time I checked, we're a separate project from enwiki (thank god).
>> If we change the software default, we're certainly free to do so. Just
>> like enwiki is certainly free to request a config change to re-lock it;
>> which I'd expect they'd do.
>>
>> -Chad
>>
>
> We are indeed, and we can do whatever we like to the software defaults.  But
> changing config settings on WMF wikis is a whole different kettle of fish,
> and that's what we're really talking about here.  Changing things on a whim
> and then requiring communities to build a consensus **to change them back**
> is not how we generally approach site configuration.
>
> --HM
>
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Of course. And the WMF can of course set its own defaults apart from
the software defaults. My original point of agreeing with the new setting
was in view of MediaWiki as a whole, not what some communities might
want.

I would expect that if we changed this in core, WMF would set a default
on their end setting it to sysop-only, as it is now. The projects should
not see a change in config like that against their wishes, we agree on
that point :)

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon
In reply to this post by David Gerard-2
"David Gerard" <[hidden email]> wrote in message
news:[hidden email]...
> 2010/1/19 Aryeh Gregor <[hidden email]>:
>
> As is, the list is generally empty, isn't it?

There are 1,879,521 unwatched mainspace pages on enwiki.  It may be empty on
smaller projects, but it certainly isn't on the larger ones.

--HM



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Huji Lee
Just because some page is "watched" doesn't mean somebody is really caring
about it. A better feature could be to list pages which are not being
"actively" watched; an active watcher could be defined as someone who has
made a login/edit in the past X days.

Unwatched pages feature is useless when a page is on the watchlist of a user
who as abandoned the project.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Aryeh Gregor
In reply to this post by David Gerard-2
On Tue, Jan 19, 2010 at 11:03 AM, David Gerard <[hidden email]> wrote:
> The reason was so that they wouldn't be an obvious vandal magnet.

Right, but they should be an obvious list of pages to watch too.
Maybe we could highlight unwatched pages on RC, or
non-actively-watched pages, if it can be done without Domas stabbing
us.  :)

> You may wish to do this per community, if you want to change it.

I'm suggesting a change to the software defaults -- individual
communities can ask for it to be changed back, or a Wikimedia default
could be set (although I don't see why the latter would be necessary).

On Tue, Jan 19, 2010 at 11:26 AM, Happy-melon <[hidden email]> wrote:
> Changing things on a whim
> and then requiring communities to build a consensus **to change them back**
> is not how we generally approach site configuration.

It is how we do it in my experience.  We don't usually consult
communities for global feature changes.  The default was chosen by dev
fiat at some point in the past anyway, so dev fiat may as well be good
enough to change it.

On Tue, Jan 19, 2010 at 11:35 AM, Happy-melon <[hidden email]> wrote:
> There are 1,879,521 unwatched mainspace pages on enwiki.  It may be empty on
> smaller projects, but it certainly isn't on the larger ones.

In light of that, maybe it would be a better idea to only release this
if we can, e.g., highlight non-actively-watched pages on RC.  Maybe
add a page_last_watch column, and update it to the current timestamp
every time a user watching that page views their watchlist.  That
might be too much work, though.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Gergő Tisza
In reply to this post by Huji Lee
Huji <huji.huji <at> gmail.com> writes:
>
> Just because some page is "watched" doesn't mean somebody is really caring
> about it. A better feature could be to list pages which are not being
> "actively" watched; an active watcher could be defined as someone who has
> made a login/edit in the past X days.

This is already done in FlaggedRevs IIRC, so it shouldn't be hard to implement.
It would also be nice to see the magnutide of the number of watchers (or even
the exact number; doesn't seem to add much extra vulnerability compared to the
list of unwatched pages) and the list of pages (un)watched by a certain user
group (some wikis have a separate group for patrollers). The latter would be
especially useful for FlaggedRevs-enabled wikis since editors (the user group
with flagging rights) receive a warning if there are unreviewed changes on their
watchlists.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Platonides
Tisza Gero" wrote:

> Huji <huji.huji <at> gmail.com> writes:
>> Just because some page is "watched" doesn't mean somebody is really caring
>> about it. A better feature could be to list pages which are not being
>> "actively" watched; an active watcher could be defined as someone who has
>> made a login/edit in the past X days.
>
> This is already done in FlaggedRevs IIRC, so it shouldn't be hard to implement.
> It would also be nice to see the magnutide of the number of watchers (or even
> the exact number; doesn't seem to add much extra vulnerability compared to the
> list of unwatched pages) and the list of pages (un)watched by a certain user
> group (some wikis have a separate group for patrollers). The latter would be
> especially useful for FlaggedRevs-enabled wikis since editors (the user group
> with flagging rights) receive a warning if there are unreviewed changes on their
> watchlists.

It's available at the toolserver, but only if there are more than a
number of watchers (10?). This way, you can't know if a page has no
watchers or just a few ones.
http://toolserver.org/~mzmcbride/cgi-bin/watcher.py


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Platonides
In reply to this post by Aryeh Gregor
Aryeh Gregor wrote:
> Why do we hide Special:UnwatchedPages from regular users?  Unwatched
> pages are something that people should know about so they can be sure
> to watch them.  If no one is actively watching a page, it's more
> likely that vandalism will stick around.  Yes, vandals and trolls
> could abuse the info, but they could abuse all sorts of other features
> too, and that's not a reason to deny them to legitimate users.  If
> there is any such threat, then that will just encourage legitimate
> users to watch the pages, thereby removing them from the list.

If the admin wants to allow it, he can enable it or publish a list of
pages to watch on the Vilalge Pump.
Suppose you open it. Who is more likely to start using it? People with
too few watched pages or vandals?
I would expect it to be the entry point the next time Fooers angry for
having deleted the article about Foo decide "to take revenge".
On the contrary, I don't foresee getting loads of goodwill users to
watch those pages (unless it's slashdotted in a "how to vandal").



Chad wrote:
> I would expect that if we changed this in core, WMF would set a default
> on their end setting it to sysop-only, as it is now. The projects should
> not see a change in config like that against their wishes, we agree on
> that point

If you make a change on default configuration that forces users to
manually set it back to the previous one, you shouldn't have changed it.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon
In reply to this post by Aryeh Gregor

"Aryeh Gregor" <[hidden email]> wrote in message
news:[hidden email]...

> On Tue, Jan 19, 2010 at 11:03 AM, David Gerard <[hidden email]> wrote:
>
> On Tue, Jan 19, 2010 at 11:26 AM, Happy-melon <[hidden email]>
> wrote:
>> Changing things on a whim
>> and then requiring communities to build a consensus **to change them
>> back**
>> is not how we generally approach site configuration.
>
> It is how we do it in my experience.  We don't usually consult
> communities for global feature changes.  The default was chosen by dev
> fiat at some point in the past anyway, so dev fiat may as well be good
> enough to change it.

I'm sure I'm not the only one to see the monstrous hypocrisy in that
compared to the hoops we'd make the communities jump through if they wanted
to propose *exactly the same change* from their end.  Fiat *is* required
when a default is *first chosen*, that's certainly true, and talking to the
communities before introducing *new* features is indeed the exception rather
than the rule.  If Special:UnwatchedPages was a new feature we'd be
perfectly free to pick a target usergroup out of a hat.  But this is a
proposal to change an already existing feature, a configuration change that
would be happily LATER'd without a clear consensus from the community in
question if it came up the other direction.  So I totally disagree: for
feature **changes**, we most certainly do look to the communities to take
the lead.

--HM
 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Aryeh Gregor
In reply to this post by Platonides
On Tue, Jan 19, 2010 at 5:11 PM, Platonides <[hidden email]> wrote:
> If the admin wants to allow it, he can enable it or publish a list of
> pages to watch on the Vilalge Pump.
> Suppose you open it. Who is more likely to start using it? People with
> too few watched pages or vandals?

Since there's no effective way to watch a million pages, probably it's
not useful, no.  I didn't realize quite how many such pages there
were.  On the other hand, why do we make the page available at all if
it's useless to legitimate users?  It's an expensive query AFAICT, so
if it's useless then we probably shouldn't bother generating it.

> If you make a change on default configuration that forces users to
> manually set it back to the previous one, you shouldn't have changed it.

If most sites want to change the default, that's a hint that it might
be a bad default, yeah.

On Tue, Jan 19, 2010 at 7:49 PM, Happy-melon <[hidden email]> wrote:
> I'm sure I'm not the only one to see the monstrous hypocrisy in that
> compared to the hoops we'd make the communities jump through if they wanted
> to propose *exactly the same change* from their end.

What?  What hoops?  We require evidence of community agreement, that's
all.  enwiki happens to have a pathological and poorly-defined process
for making config change requests, but that's its requirement, not
ours.  As far as sysadmins are concerned, if a community decides that
a three-day majority vote is enough, they'll change it on that basis
AFAIK.  Small wikis might just have a sysop request it after a brief
discussion on the local village pump.

It might take a while for a shell user to get around to doing the
change, but that's a separate issue.

> Fiat *is* required
> when a default is *first chosen*, that's certainly true, and talking to the
> communities before introducing *new* features is indeed the exception rather
> than the rule.  If Special:UnwatchedPages was a new feature we'd be
> perfectly free to pick a target usergroup out of a hat.  But this is a
> proposal to change an already existing feature, a configuration change that
> would be happily LATER'd without a clear consensus from the community in
> question if it came up the other direction.  So I totally disagree: for
> feature **changes**, we most certainly do look to the communities to take
> the lead.

I don't follow at all.  Developers get to decide on defaults when we
introduce a new feature, but once a feature already exists then it's
locked in stone forever?  That's certainly not how things work in
practice.  We've made significant changes to existing features in the
past without asking communities first.  Ditching Makesysop/Makebot in
favor of better core userrights comes to mind, but I'm sure there are
better examples.

The model is always that the developers/sysadmins decide on global
defaults based on their knowledge and interpretation of our goals and
the projects' needs, and projects can later request changes for
themselves.  Both for new features, and existing features.  We don't
ever hold up global development/system administration decisions on
community consensus.  It would be impossible even if we wanted to --
how do we go about getting consensus from several hundred wikis?  Do
we have to have a poll on Meta?  Or is only enwiki supposed to count?
Why should changing an existing feature be any different from
introducing a new one?

There are good reasons to not allow all users to use UnwatchedPages
(and at this point they've convinced me), but the fact that we haven't
consulted the communities is not one of them.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Aryeh Gregor
On Tue, Jan 19, 2010 at 9:32 PM, Aryeh Gregor
<[hidden email]> wrote:
> I don't follow at all.  Developers get to decide on defaults when we
> introduce a new feature, but once a feature already exists then it's
> locked in stone forever?  That's certainly not how things work in
> practice.  We've made significant changes to existing features in the
> past without asking communities first.  Ditching Makesysop/Makebot in
> favor of better core userrights comes to mind, but I'm sure there are
> better examples.

Better example: recent discussion on whether to increase thumbnail
image size cross-project.
<https://bugzilla.wikimedia.org/show_bug.cgi?id=21117>  Software
permitting, probably we'll increase the default thumb width across all
projects.  We aren't holding a poll in Meta first or anything, but
this is a considerably more user-visible change than adjusting the
access rights to an obscure and largely useless special page.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon
In reply to this post by Aryeh Gregor

"Aryeh Gregor" <[hidden email]> wrote in message
news:[hidden email]...

> On Tue, Jan 19, 2010 at 5:11 PM, Platonides <[hidden email]> wrote:
>> If the admin wants to allow it, he can enable it or publish a list of
>> pages to watch on the Vilalge Pump.
>> Suppose you open it. Who is more likely to start using it? People with
>> too few watched pages or vandals?
>
> Since there's no effective way to watch a million pages, probably it's
> not useful, no.  I didn't realize quite how many such pages there
> were.  On the other hand, why do we make the page available at all if
> it's useless to legitimate users?  It's an expensive query AFAICT, so
> if it's useless then we probably shouldn't bother generating it.

The page is essentially useless on enwiki at least.  Despite a concerted
effort a while back, no one has ever even seen the 'B's...

>> If you make a change on default configuration that forces users to
>> manually set it back to the previous one, you shouldn't have changed it.
>
> If most sites want to change the default, that's a hint that it might
> be a bad default, yeah.

I'm not seeing any evidence that most, many, or even some sites want to
change this default.  I'm seeing a group of MW developers talking about
wanting to change it.

> On Tue, Jan 19, 2010 at 7:49 PM, Happy-melon <[hidden email]> wrote:
>> I'm sure I'm not the only one to see the monstrous hypocrisy in that
>> compared to the hoops we'd make the communities jump through if they
>> wanted
>> to propose *exactly the same change* from their end.
>
> What?  What hoops?  We require evidence of community agreement, that's
> all.  enwiki happens to have a pathological and poorly-defined process
> for making config change requests, but that's its requirement, not
> ours.  As far as sysadmins are concerned, if a community decides that
> a three-day majority vote is enough, they'll change it on that basis
> AFAIK.  Small wikis might just have a sysop request it after a brief
> discussion on the local village pump.
>
> It might take a while for a shell user to get around to doing the
> change, but that's a separate issue.

This is all true, and I think that's one of the most apt description of
enwiki's approach to the whole issue I've seen for a long while.  But that
doesn't change the fact that if I filed a bug asking to set
$wgGroupPermissions['*']['unwatchedpages']=true on xxwiki, pointing to a
discussion where three yywiki editors mused that it would be a good idea, it
would be *immediately* LATER'd asking for a demonstration of consensus
*within that community*.  Whatever the cause, there is hypocrisy there.

>> Fiat *is* required
>> when a default is *first chosen*, that's certainly true, and talking to
>> the
>> communities before introducing *new* features is indeed the exception
>> rather
>> than the rule.  If Special:UnwatchedPages was a new feature we'd be
>> perfectly free to pick a target usergroup out of a hat.  But this is a
>> proposal to change an already existing feature, a configuration change
>> that
>> would be happily LATER'd without a clear consensus from the community in
>> question if it came up the other direction.  So I totally disagree: for
>> feature **changes**, we most certainly do look to the communities to take
>> the lead.
>
> I don't follow at all.  Developers get to decide on defaults when we
> introduce a new feature, but once a feature already exists then it's
> locked in stone forever?  That's certainly not how things work in
> practice.  We've made significant changes to existing features in the
> past without asking communities first.  Ditching Makesysop/Makebot in
> favor of better core userrights comes to mind, but I'm sure there are
> better examples.

There are; Make(Bot|Sysop) were deprecated everywhere I've looked before
they were disabled.  In a very real sense, the sysadmins *did* consult the
people who would be affected by the change - the relatively small group of
WMF crats and stewards - before making the change.  In a similar vein would
be the deprecation of Oversight: new functionality was deployed by fiat in
the form of RevDeleted, but disabling Oversight itself, despite being a Very
Good Thing from the PoV of "interpretation of our goals and the projects'
needs", has been delayed because of consultation with those who actually use
the functionality and would be affected by changes in it.

> The model is always that the developers/sysadmins decide on global
> defaults based on their knowledge and interpretation of our goals and
> the projects' needs, and projects can later request changes for
> themselves.  Both for new features, and existing features.  We don't
> ever hold up global development/system administration decisions on
> community consensus.  It would be impossible even if we wanted to --
> how do we go about getting consensus from several hundred wikis?  Do
> we have to have a poll on Meta?  Or is only enwiki supposed to count?
> Why should changing an existing feature be any different from
> introducing a new one?

FlaggedRevs?  Rollback?  I guess the real position is neither black nor
white, and neither of our blanket statements are valid.  My original point
was that this is a particularly bad time to do this, because this is a point
of contention on enwiki in particular.  A better way of phrasing it would be
to say that the communities' opinions are relevant but not binding on
sysadmin actions; where the area is more contentious, the community's
thoughts should be given a greater prominence.  Raising this issue on enwiki
at the moment would be explosive, and making a change *without* raising the
issue equally so.

--HM
 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Aryeh Gregor
On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon <[hidden email]> wrote:
> This is all true, and I think that's one of the most apt description of
> enwiki's approach to the whole issue I've seen for a long while.  But that
> doesn't change the fact that if I filed a bug asking to set
> $wgGroupPermissions['*']['unwatchedpages']=true on xxwiki, pointing to a
> discussion where three yywiki editors mused that it would be a good idea, it
> would be *immediately* LATER'd asking for a demonstration of consensus
> *within that community*.  Whatever the cause, there is hypocrisy there.

It's not hypocrisy.  It's an acknowledgment that different groups get
to make different types of decisions.  If you want the default to be
changed for a specific wiki, that wiki needs to explicitly ask for it,
because it's presumed that wikis want the default until proven
otherwise.  That's why we made it default, after all.  If you want to
change the default for all wikis, on the other hand, you don't need
agreement from any one particular wiki, but you need to convince
devs/sysadmins that it's a better default for most wikis.  The devs
are the only logical group to make this kind of decision in general,
because we're the only ones who understand what most changes *do*.

> FlaggedRevs?  Rollback?  I guess the real position is neither black nor
> white, and neither of our blanket statements are valid.  My original point
> was that this is a particularly bad time to do this, because this is a point
> of contention on enwiki in particular.  A better way of phrasing it would be
> to say that the communities' opinions are relevant but not binding on
> sysadmin actions; where the area is more contentious, the community's
> thoughts should be given a greater prominence.

I'd put it differently: we don't have to *consult* the communities to
change the software, but we should set the defaults to what most of
them would *want* anyway, as far as we can tell (and subject to
Wikimedia's mission).  If we have reason to believe that some change
(whether adding, removing, or modifying a feature) would tick off a
particular community, that weighs against making the change, although
not conclusively.  So it might sometimes be reasonable to say "You
shouldn't do that because most communities wouldn't want it", but not
to say "You shouldn't do that because you haven't asked the
communities about it".  IMO.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Chad
On Wed, Jan 20, 2010 at 3:37 PM, Aryeh Gregor
<[hidden email]> wrote:

> On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon <[hidden email]> wrote:
>> This is all true, and I think that's one of the most apt description of
>> enwiki's approach to the whole issue I've seen for a long while.  But that
>> doesn't change the fact that if I filed a bug asking to set
>> $wgGroupPermissions['*']['unwatchedpages']=true on xxwiki, pointing to a
>> discussion where three yywiki editors mused that it would be a good idea, it
>> would be *immediately* LATER'd asking for a demonstration of consensus
>> *within that community*.  Whatever the cause, there is hypocrisy there.
>
> It's not hypocrisy.  It's an acknowledgment that different groups get
> to make different types of decisions.  If you want the default to be
> changed for a specific wiki, that wiki needs to explicitly ask for it,
> because it's presumed that wikis want the default until proven
> otherwise.  That's why we made it default, after all.  If you want to
> change the default for all wikis, on the other hand, you don't need
> agreement from any one particular wiki, but you need to convince
> devs/sysadmins that it's a better default for most wikis.  The devs
> are the only logical group to make this kind of decision in general,
> because we're the only ones who understand what most changes *do*.
>
>> FlaggedRevs?  Rollback?  I guess the real position is neither black nor
>> white, and neither of our blanket statements are valid.  My original point
>> was that this is a particularly bad time to do this, because this is a point
>> of contention on enwiki in particular.  A better way of phrasing it would be
>> to say that the communities' opinions are relevant but not binding on
>> sysadmin actions; where the area is more contentious, the community's
>> thoughts should be given a greater prominence.
>
> I'd put it differently: we don't have to *consult* the communities to
> change the software, but we should set the defaults to what most of
> them would *want* anyway, as far as we can tell (and subject to
> Wikimedia's mission).  If we have reason to believe that some change
> (whether adding, removing, or modifying a feature) would tick off a
> particular community, that weighs against making the change, although
> not conclusively.  So it might sometimes be reasonable to say "You
> shouldn't do that because most communities wouldn't want it", but not
> to say "You shouldn't do that because you haven't asked the
> communities about it".  IMO.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

At this point, all I see is a discussion between two technologies that are
about equally difficult to implement for MediaWiki, provide roughly the
same benefits, varying largely in the semantics of how it's presented. In
any case, I'm inclined to agree with Happy-Melon on this issue, and I think
we're going about it in the wrong way.

If we've got access to this metadata, then sure, it should be distributed in
as many formats as people show a desire to consume. This could be RDFa,
Microdata, or anything. Right now though, we do not have this metadata.
All we have is templates. Trying to extract this data from templates (or
by extension, parser/tag functions) is approaching the problem from the wrong
direction. It still relies on input of wikitext into the edit form. We need to
remember that wikitext is a markup language designed with presentation
in mind, not semantic data. This sort of page metadata (licenses, categories,
etc) needs to be kept out of the edit page entirely.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Hiding Special:UnwatchedPages

Happy-melon

"Chad" <[hidden email]> wrote in message
news:[hidden email]...

> On Wed, Jan 20, 2010 at 3:37 PM, Aryeh Gregor
> <[hidden email]> wrote:
>> On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon <[hidden email]>
>> wrote:
>>
>>> FlaggedRevs?  Rollback?  I guess the real position is neither black nor
>>> white, and neither of our blanket statements are valid.  My original
>>> point
>>> was that this is a particularly bad time to do this, because this is a
>>> point
>>> of contention on enwiki in particular.  A better way of phrasing it
>>> would be
>>> to say that the communities' opinions are relevant but not binding on
>>> sysadmin actions; where the area is more contentious, the community's
>>> thoughts should be given a greater prominence.
>>
>> I'd put it differently: we don't have to *consult* the communities to
>> change the software, but we should set the defaults to what most of
>> them would *want* anyway, as far as we can tell (and subject to
>> Wikimedia's mission).  If we have reason to believe that some change
>> (whether adding, removing, or modifying a feature) would tick off a
>> particular community, that weighs against making the change, although
>> not conclusively.  So it might sometimes be reasonable to say "You
>> shouldn't do that because most communities wouldn't want it", but not
>> to say "You shouldn't do that because you haven't asked the
>> communities about it".  IMO.
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> At this point, all I see is a discussion between two technologies that are
> about equally difficult to implement for MediaWiki, provide roughly the
> same benefits, varying largely in the semantics of how it's presented. In
> any case, I'm inclined to agree with Happy-Melon on this issue, and I
> think
> we're going about it in the wrong way.
>
> If we've got access to this metadata, then sure, it should be distributed
> in
> as many formats as people show a desire to consume. This could be RDFa,
> Microdata, or anything. Right now though, we do not have this metadata.
> All we have is templates. Trying to extract this data from templates (or
> by extension, parser/tag functions) is approaching the problem from the
> wrong
> direction. It still relies on input of wikitext into the edit form. We
> need to
> remember that wikitext is a markup language designed with presentation
> in mind, not semantic data. This sort of page metadata (licenses,
> categories,
> etc) needs to be kept out of the edit page entirely.
>
> -Chad
>

I think you got your threads in a twist... :-D

--HM
 



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12