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