On 17 August 2014 20:25, Pete Forsyth <peteforsyth(a)gmail.com> wrote:
On Sun, Aug 17, 2014 at 5:12 PM, Risker
<risker.wp(a)gmail.com> wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth <peteforsyth(a)gmail.com> wrote:
> I think it is also a problem to look at this in terms of "bugs." I
don't
think you
can retrofit good design into something that has a variety of
substantial problems, by merely "squashing bugs." You might say that is
the
wiki way, but it is widely known that some tasks
are better suited than
others to ad hoc collaborative processes.
Given the current use of bugzilla, which doesn't limit itself to bugs but
also feature requests and enhancements over the base functionality,
calling
everything reported using bugzilla a
"bug" is incorrect and
inappropriate.
While this is true, I have yet to see bugzilla used as a platform for a
design process for Media Viewer, and I don't think I would recommend it.
It's *possible* to use it as a platform for more than mere bugs, and it has
been done before; but I don't think tha'ts what's going on here, or should
go on here.
Perhaps you should get to know a bit more about bugzilla and its current
usage; of the 104 current reports on Multimedia Viewer, 16 are enhancements
and several others that are currently listed as "bugs" of varying
importance/urgency are "features" that don't appear to exist in the
"standard" format for viewing images or are so badly designed in the File
pages that they're almost impossible to call acceptable in that format,
either.
Someone who is better able to describe the developer functions could better
describe the planned changes from the use of Bugzilla to Phabricator, which
is a more flexible platform that (I understand) is intended to consolidate
several different design/development/improvement/bug reporting platforms
currently in use. But right now, bugzilla is at least in some cases used
as a platform for the design process of just about everything to do with
MediaWiki, its extensions, and all the other platforms that are in
use/developed by WMF.
Every single type of software used on Wikimedia project sites, as well as
software for other features provided by the WMF, has bugzilla reports.
There are thousands for MediaWiki, the core software of the project. We
haven't thrown in the towel on it just because it's got lots of bugzilla
reports.
In this
case, we have a broad range of issues:
* does it let the reader know they can help improve the page or upload
another photo
The Commons/File pages don't do that, why would you expect this software
to
do it?
The Commons/File page DOES do that, to the extent that readers have some
familiarity with MediaWiki software and how to find the "Edit" button. You
may not believe that is significant, but I encounter people on an almost
daily basis who are mystified by Wikipedia, but at least have a basic
understanding what the "edit" button does, or could allow them to do. It
may not be all readers or even a majority, but it is my very strong belief
-- rooted, perhaps not in rigorous scientific analysis, but in my very
active engagement with non-Wikipedias since 2006 -- that it's the pool of
people who tend to replenish our declining editor pool. A great many of the
100+ students who signed up for the 4 rounds of my online course on editing
Wikipedia, for instance, had accounts that were several years old, but only
had a dozen or so edits.
I'm sorry. How, exactly, do you envision a new editor or reader improving
file pages? There's not very much that can be edited there that isn't going
to cause more problems than it solves. Should they modify the author?
Change the license? Add (potentially non-existent) categories? When the
chances of reversion are nearly 100%, it's not necessarily a net positive
to make a big deal about the existence of an "edit" button. Media pages
are not really comparable to (written) content pages. I'd rank file pages
as possibly the worst place to suggest that new editors just jump in, with
the possible exception of templates.
<snip>
* does it adequately respect the privacy of the
subjects of photos
The mere fact of the image being used on an article anywhere on a
Wikimedia
project suggests that this problem is in the actual
usage, not in the
software being used to display more information and detail in the image.
If you believe that this is a serious issue, then it should be addressed
where 100% of readers can see it, not in a subpage viewed only by the
limited number of readers who click on the image. It's not a Media Viewer
problem, it's an image usage problem.
This point has a lot of nuance in it, and I'm happy to discuss it, but not
here and now. If you want to dig into it, I suggest
this as a venue:
https://commons.wikimedia.org/wiki/Template_talk:Consent -- if you leave a
note there, please {{ping|Peteforsyth}} so I can find it.
I am at a loss as to why a template on Commons has anything to do with the
privacy of subjects of photos. And yes, I read that entire page over
twice. Templates are simply a manner in which to facilitate the level of
adherence to certain policies (and in some cases legal requirements);
they're not the place to discuss over-arching philosophy.
* does it
reflect a "look and feel" that we feel OK about and is
consistent
with the rest of the software
etc. etc.
What problems are you seeing here? Spell it out, rather than making
vague
suggestions that there is an issue.
I don't personally have a big issue with this one; but it's something
others have brought up. I'm trying to capture the breadth of concerns about
the software here, rather than (as WMF staff keep inaccurately accusing me
and many of my colleagues of doing) saying merely "I DON'T LIKE IT."
Well, if you don't have a problem with it, why are you including it in your
list of problems? This is exactly how what might very well be a problem for
a very small number of users gets inflated to be considered a big issue for
a large number of users. For the record: I don't care one way or the
other; I can use file pages, I can use MMV, and since I don't do a lot of
file work either is fine for me. I didn't opt in before hand, but I haven't
opted out since it went live. It would be helpful for others to give
serious thought to why they've decided to opt in (before) or opt out (after
default deployment) and then report this so that realistic data can be
collected. I'm going to be honest, I've seen a lot of "I don't like
it",
but I've also seen some good reasons, for personal decisions either way.
I've not seen a lot of good arguments for disabling it for readers, though,
especially as it exists today.
>
> Fixing one "bug" may well lead to other bugs, or negatively impact
those
already
reported. What is needed, I believe, is a well-facilitated
process
to identify the problems and the best solutions.
This is not easy to do
and
takes time. But I think the WMF has (not for lack
of trying) managed to
do
> a very bad job of that with this software product, and with many
software
> products in the last few years. That does
not mean it is impossible to
do
it that
way, only that those specific efforts were insufficient.
Why is this a Media Viewer issue? This is a problem for all types of
software on all types of platforms, and is a challenge even for IT
departments hundreds of times the size of the WMF. I cannot think of any
software I have used in the last 20 years that has not had "bugs" or
unsatisfactory UI elements or seems to miss a functionality I'd like to
have. It is unreasonable to hold a comparatively very small organization
to a standard that can't even be met by IT giants.
It is absolutely a problem for all types of software on all types of
platforms. It is a Media Viewer issue because the design and deployment was
executed so badly that it caused a significant backlash on 3 major
projects.
And again -- the WMF has done this well in some cases, there's no need to
look at mega corporations to find good models. All I am suggesting is that
the WMF do a better job of learning from its own successes.
Your comparison in your initial post was to a policy discussion on the
Terms of Use, which you felt went well. And yet, this was a discussion on
a single site, Meta, where very few Wikimedians participate; there was no
particular outreach to projects except to meet the legal obligation of
making reasonable efforts to notify users of a change in the TOU. For MMV,
we have, at minimum:
- Beta features option in the user preferences for all users on all
projects. Unfortunately, an administrator unilaterally removed this
preference tab on dewiki, thus withdrawing the opportunity for any users on
that project to opt in and test and comment on this and other software
throughout the stages of development. I understand this has now been
restored, and look forward to seeing comments on many software changes from
our colleagues on that project. Or not - it's their choice.
- Posts on Village Pumps and other appropriate locations on hundreds of
project sites
- Information provided to site-specific information dissemination
functions (e.g., Signpost on 14 May 2014 and earlier)
- Active attempts to seek out user opinions through questionnaires.
(Yes, I know there was some perception of bias in the wording of some
questions. Nonetheless, this is an additional opportunity for gathering
information that was not used for the TOU.)
In other words, you thought a discussion on a single site went well, but
one that took place across hundreds of sites didn't do enough to inform
people and seek feedback. Do you see why I am perceiving a bias on your
part?
Commons has a very different use case for information about files and media
than any other project site in the Wikimedia family, and it seems to me
that the WMF listened when that community pointed out their differing
needs; again, despite lots of advance notice it seems that not a lot of
Commons users communicated these concerns before deployment. Both Enwiki
and Dewiki have had a troubled relationship with the WMF (and particularly
the Engineering & Product departments) in recent history. In the case of
enwiki, though, an RFC on this specific topic still could only draw 64
editors supporting opt-in for MMV (as opposed to opt-out or default
status). Dewiki had stronger support for moving away from default status,
although this was the project that had little opportunity to test in
advance because of the removal of the opt-in option in advance of its
deployment there. That was a shame, because our dewiki colleagues have
often provided very useful comments and recommendations for improvement of
other software in development.
In other words....everyone has something to learn here, but perhaps the
most important and valuable point is that changes are going to keep
happening across these sites - in fact, they're made every week, although
not always as major as this - and there is a huge need from all sides for
users to participate and identify concerns while software is being
developed so that problems that aren't necessarily obvious to developers
will be flushed out before largescale deployments. At the same time,
product managers and developers need to work with users to identify the
difference between minor concerns and concerns that should be considered
"blockers" as software is being developed/improved/modified/etc.
Risker/Anne