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?
On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor Simetrical+wikilist@gmail.com 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 Wikitech-l@lists.wikimedia.org 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
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" innocentkiller@gmail.com wrote in message news:5924f50a1001190734m777e6799h4243eebe6e7ea0c9@mail.gmail.com...
On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor Simetrical+wikilist@gmail.com 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 Wikitech-l@lists.wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon happy-melon@live.com 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" innocentkiller@gmail.com wrote in message news:5924f50a1001190734m777e6799h4243eebe6e7ea0c9@mail.gmail.com...
On Tue, Jan 19, 2010 at 10:21 AM, Aryeh Gregor Simetrical+wikilist@gmail.com 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 Wikitech-l@lists.wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org 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
-------------------------------------------------- From: "Chad" innocentkiller@gmail.com Sent: Tuesday, January 19, 2010 4:18 PM To: "Happy-melon" happy-melon@live.com; "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Hiding Special:UnwatchedPages
On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon happy-melon@live.com 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
On Tue, Jan 19, 2010 at 11:26 AM, Happy-melon happy-melon@live.com wrote:
From: "Chad" innocentkiller@gmail.com Sent: Tuesday, January 19, 2010 4:18 PM To: "Happy-melon" happy-melon@live.com; "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Hiding Special:UnwatchedPages
On Tue, Jan 19, 2010 at 11:11 AM, Happy-melon happy-melon@live.com 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 Wikitech-l@lists.wikimedia.org 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
2010/1/19 Aryeh Gregor Simetrical+wikilist@gmail.com:
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.
"David Gerard" dgerard@gmail.com wrote in message news:fbad4e141001190803t74d27f6coeda1b2150788226@mail.gmail.com...
2010/1/19 Aryeh Gregor Simetrical+wikilist@gmail.com:
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
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.
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.
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
On Tue, Jan 19, 2010 at 11:03 AM, David Gerard dgerard@gmail.com 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 happy-melon@live.com 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 happy-melon@live.com 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.
"Aryeh Gregor" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e21001191147w16b95226g14a9f8844e0d74de@mail.gmail.com...
On Tue, Jan 19, 2010 at 11:03 AM, David Gerard dgerard@gmail.com wrote:
On Tue, Jan 19, 2010 at 11:26 AM, Happy-melon happy-melon@live.com 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
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.
On Tue, Jan 19, 2010 at 5:11 PM, Platonides Platonides@gmail.com 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 happy-melon@live.com 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.
On Tue, Jan 19, 2010 at 9:32 PM, Aryeh Gregor Simetrical+wikilist@gmail.com 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.
"Aryeh Gregor" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e21001191832g207d8f08ud4dc84f674d25e5d@mail.gmail.com...
On Tue, Jan 19, 2010 at 5:11 PM, Platonides Platonides@gmail.com 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 happy-melon@live.com 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
On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon happy-melon@live.com 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.
On Wed, Jan 20, 2010 at 3:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon happy-melon@live.com 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 Wikitech-l@lists.wikimedia.org 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
"Chad" innocentkiller@gmail.com wrote in message news:5924f50a1001201622p20e1a9adi905ce14cf3c5d1f8@mail.gmail.com...
On Wed, Jan 20, 2010 at 3:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon happy-melon@live.com 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 Wikitech-l@lists.wikimedia.org 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
On Wed, Jan 20, 2010 at 7:38 PM, Happy-melon happy-melon@live.com wrote:
"Chad" innocentkiller@gmail.com wrote in message news:5924f50a1001201622p20e1a9adi905ce14cf3c5d1f8@mail.gmail.com...
On Wed, Jan 20, 2010 at 3:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Jan 20, 2010 at 1:59 PM, Happy-melon happy-melon@live.com 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 Wikitech-l@lists.wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Whoops.
-Chad
wikitech-l@lists.wikimedia.org