On 17 August 2014 20:25, Pete Forsyth peteforsyth@gmail.com wrote:
On Sun, Aug 17, 2014 at 5:12 PM, Risker risker.wp@gmail.com wrote:
Well, hold on here.
On 17 August 2014 19:55, Pete Forsyth peteforsyth@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