https://bugzilla.wikimedia.org/show_bug.cgi?id=57512
--- Comment #11 from Bawolff (Brian Wolff) <bawolff...@gmail.com> ---
[mid-air collision]
>Well, Flow isn't how a wiki works ;) There's never been a structured discussion
>system like this before on any Wikimedia project; it's fundamentally different
>by design. The "but this isn't how we've always done it!" argument could
>certainly be valid in instances when there's legitimate user confusion and/or
>broken workflows -- however, the only way we'll know if this is the case is
>when actual users begin to use Flow. That's why we're deploying to a few pages
>where people can test it out and tell us if this is important to fix asap.
different things are going to be different or they wouldn't be a different
thing is a fair point. I do believe the social intertia around this would be
significant enough as to cause backlash, however when it comes right down to
it, that's just my opinion. I do think people expect flow to behave in the
wiki-way in a wide variety of situations, even though it is different from a
wiki in many ways.
>But vandalism works the other way around, too. Take the Meepsheep vandal of..
>2011, I think? The guy who found a bunch of unprotected transcluded templates
>that were used on thousands of really high-visibility articles and inserted
>pictures of swastikas and dead babies in them. I'd argue that's a much more
>common and much more serious form of vandalism that the current mediawiki setup
>does not adequately address.
Indeed it does, the difference is that its very easy to undo that type of
vandalism, just revert the edits. There's even a nice list of all edits to
revert. In the flow situation the vandalism would be hard to undo, with reverts
being ineffectual. There is not even a list of affected pages. Thus while the
number of shock images would be much less, they would last much longer. I
believe it is significantly better to have all the templates be replaced with
bad images for 30 seconds (yeah yeah, job queue delay makes that probably a bit
longer), than it would be for a couple template instances to be replaced for 6
months without anybody realizing the presence of hidden vandalism until someone
stumbles upon it.
>Do we want to live in a world where we have to consult with every single user
>(many probably no longer active) before we make changes to widely-used
>templates, because otherwise we'll break someone's workflow? I'm not sure, but
>I'd like to propose we try a different way and see if that works better.
Same thing could be said about code deprecations, etc. When it comes down to
it, changing the semantics of public symbols usually causes problems, and
there's no way around that, but sometimes it is necessary. I don't think
{{opentasks}} is a good example to use here, since without instant updating,
that template is entirely useless once the tasks become closed. If people
really wanted non-changing templates, they would probably use the already
existing subst: keyword. So it all comes down to user expectations, and well I
have a guess what these expectations are, I don't have a crystal ball that
would tell me If I'm right.
>I'd like to see some stats on how often this actually happens in talk
>namespaces. I can see how this would be an issue in articles even if it was
>extremely rare, but in discussion?
Ask and you shall receive. There's been 456 such image changes that have been
used on any talk namespace since Jan 1, 2014 (So in 27 days). If you limit that
to just things in the main talk namespace (i.e. namespace 1), it falls to 189
image changes. If you further limit that to main talk, and enwiki only, then
you have 86 such image changes:
MariaDB [commonswiki_p]> select count( distinct img_name) from image inner join
oldimage on oi_name = img_name inner join globalimagelinks on gil_to = img_name
and (gil_page_namespace_id & 1) where (oi_width != img_width or oi_height !=
img_height) and img_timestamp > '20140101000000' and oi_archive_name like
'2014%';
+---------------------------+
| count( distinct img_name) |
+---------------------------+
| 456 |
+---------------------------+
1 row in set (2.26 sec)
MariaDB [commonswiki_p]> select count( distinct img_name) from image inner join
oldimage on oi_name = img_name inner join globalimagelinks on gil_to = img_name
and gil_page_namespace_id = 1 where (oi_width != img_width or oi_height !=
img_height) and img_timestamp > '20140101000000' and oi_archive_name like
'2014%';
+---------------------------+
| count( distinct img_name) |
+---------------------------+
| 189 |
+---------------------------+
1 row in set (31.37 sec)
Limiting to enwiki:
MariaDB [commonswiki_p]> select count( distinct img_name) from image inner join
oldimage on oi_name = img_name inner join globalimagelinks on gil_to = img_name
and gil_page_namespace_id = 1 and gil_wiki = 'enwiki' where (oi_width !=
img_width or oi_height != img_height) and img_timestamp > '20140101000000' and
oi_archive_name like '2014%';
+---------------------------+
| count( distinct img_name) |
+---------------------------+
| 86 |
+---------------------------+
1 row in set (2.57 sec)
>That's a good point; I'm not sure how important it will be in talk namespaces,
>though (see also the comment below).
In modern wikipedia, it seems like red links are primarily used on talk
namespaces and less commonly on article namespace.
-----
Additional issue I failed to mention: Not working with globalusage means that
commons admins will not know the image is in use, which means that if there's a
problem with the image its much more likely to get deleted. In the ages before
globalusage, this sort of thing caused a lot of tension between commons and
sister projects.
>Sure, there's probably other things I haven't thought of, too :) The point is
>that this is one of many instances where we're not entirely sure what the
>"right" solution is, and it would help tremendously to have the end-users of
>our software test it out and give us a better sense of what we should do.
Yes of course, the future is unknowable, but that doesn't mean we shouldn't
address the issues we do know about first.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
