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(a)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(a)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(a)wikimedia.org> wrote:
> On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <
richard(a)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(a)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(a)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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>