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.
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 * does it reflect copyright holders' licenses accurately and effectively * does it adequately respect the privacy of the subjects of photos * does it reflect a "look and feel" that we feel OK about and is consistent with the rest of the software etc. etc.
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.
An example of a design process that DID work well, I believe, is the 2012 rewrite of the Terms of Use. The goals were clearly stated upfront, a deadline was stated *and then moved* when it was determined that it was too soon and good work was being done, the discussion was facilitated in a highly useful way (noting things that are off topic, closing issues as they are resolved, actively drawing in staff as needed, etc.)
-Pete [[User:Peteforsyth]]
On Sun, Aug 17, 2014 at 4:46 PM, Richard Farmbrough < richard@farmbrough.co.uk> wrote:
And that is a common community complaint, games communities, social communities, and content communities.
They all say "fix the bugs before working on new stuff." Developers prefer working on new stuff, managers prefer working on new stuff. Where's the kudos from making things bug-free? But that is what is needed.
On 17 August 2014 13:48, Comet styles cometstyles@gmail.com wrote:
yes but mediawiki is a software, not an "add-on" or as the kids say these days, an "App" which is what Media Viewer is. Enforcing something with more than a 100 bugs (and counting) is indeed not a very super idea..Fix the bugs or atleast half of them and maybe then try "enforcing them" (as WMF ignores community decisions)......
On 8/17/14, Chad Horohoe chorohoe@wikimedia.org wrote:
On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <
richard@farmbrough.co.uk>
wrote:
There are 105 bugs open for Media Viewer. To my mind that is not a
product
that is ready to be delivered to 500,000,000 users, delivering 52.5 billion bugs! (And that's just the ones we know about!)
MediaWiki itself has 4893 open bugs. Guess we need to start over so we
can
write bug-free software.
Except that's not how it works, absolute bug counts are a pretty
useless
metric.
-Chad _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Cometstyles
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- Landline (UK) 01780 757 250 Mobile (UK) 0798 1995 792 _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe