> Message: 9
> Date: Sat, 12 Nov 2011 09:11:08 -0500
> From: William Allen Simpson <william.allen.simpson(a)gmail.com>
> Subject: [Wikitech-l] Overzealous Commons deletionists
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Cc: Wikimedia Foundation Mailing List
> <foundation-l(a)lists.wikimedia.org>, info(a)wikimedia.org
> Message-ID: <4EBE7E7C.8070708(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I've noticed a problem with overzealous deletionists on Commons. While
> this may be something of a legal and political issue, it's also
> operational and affects multiple *[m,p]edias at the same time.
>
[snip]
>
> There are a number of obvious technical issues. YouTube and others
> have had to handle this, it's time for us.
>
> 1) DMCA doesn't require a takedown until there's been a complaint. We
> really shouldn't allow deletion until there's been an actual complaint.
> We need technical means for recording official notices and appeals.
> Informal opinions of ill-informed volunteers aren't helpful.
OTRS? This seems like a social (or potentially a legal) issue not a
technical one.
> 2) Fast scripting and insufficient notice lead to flapping of images,
> and confusion by the owners of the documents (and the editors of
> articles, as 2 days is much *much* too short for most of us). We need
> something to enforce review times.
Again a social issue
> 3) Folks in other industries aren't monitoring Talk pages and have no
> idea or sufficient notice that their photos are being deleted. The
> Talk mechanism is really not a good method for anybody other than very
> active wikipedians. We need better email and other social notices.
Enable enotif for talk page messages by default?
>
> 4) We really don't have a method to "prove" that a username is actually
> under control of the public figure. Hard to do. Needs discussion.
Again a social issue. No amount of technical magic will be able to
solve that issue.
> 5) We probably could use some kind of comparison utility to help
> confirm/deny a photo or article is derived from another source.
That could certainly be a technical challenge, and not a trivial one.
However at the end of the day we can just get a human to compare.
> If there's a better place to discuss this, please indicate.
Commons-l or the VP at commons since these are mostly complaints
against the social practises, not technical issues.
-bawolff
Yesterday a friend of mine discovered and filed a bug that highlights
a backwards incompatibility introduced by 1.18.
The bug is "Moved ArticleSave hook breaks backward compatibility"
(https://bugzilla.wikimedia.org/32318).
I found a number of public functions in the Article class that are not
directly supported in WikiPage.
To be clear, I don't know how widely those public functions are used.
They may be inconsequential. It may be only my friend who is likely to
run into a problem on upgrading.
So my question: is this problem worth holding back a 1.18 release while
we implement any missing functionality?
Mark.
Hey all,
I've run into some issues with storing revisioned configuration during the
creation of the Contest extension and the upload campaigns functionality in
the Upload Wizard, as well as in several other extensions. Since this issue
appears to be a quite common, this email is intended to outline the problem
and kick off discussion about how it can be resolved.
== Problem ==
Many extensions need some kind of admin UI in which non-user specific
configuration can be done, ie creating contests or upload campaigns. If
this configuration is just stored in some db tables created specially for
this purpose, you do not have the ability to revert changes, restore
deleted entities, simply compare changes, see who changes what and when,
ect. This is quite problematic on big wikis, since someone can accidentally
break a lot of functionality by deletion something, and then lack the
ability to restore this. Or worse, if access to an account with sufficient
privileges is obtained by a malicious person, he can modify configuration
without this being logged anywhere. So what we need is to have similar
versioning and logging for this kind of configuration as for wiki pages.
== Why wiki pages are not the answer ==
Historically, a few extensions have been storing simple configuration in
wiki pages, typically in the MediaWiki namespace. Unfortunately there are
several issues with this approach when it comes to more complex
configuration, such as a contest. Since the data to be stored is an object,
it needs to be serialized to fit into a wiki page. The general consensus
here seems to be to use JSON.
Problem 1: querying the data. Since it's not stored in relational form, how
are you going to get a list of active contests, or do any of the many other
queries that are needed by the extension? One could solve this by not only
serializing the data to a wiki page, but on every change, also update a
redundant relational copy in the db. This is less nice though, because of
the redundancy, and because you'd be looking at diffs of JSON instead of
the changes to the single value you care about. So even though it would be
a hack, you could go with this approach if not for problem 2.
Problem 2: no fine grained rights whatsoever. Contests should only be
viewable by contest admins and contest judges, and only editable by the
former. An approach that goes part of the way to providing this is putting
each type of object (ie contest, upload campaign) into it's own namespace,
and applying the needed rights restrictions on that. Since MediaWiki is not
designed to prevent read access, I'd not be to eager to put anything that
should not be accessible by non authorized people in there though. And this
approach does not work at all when you need more fine grained restrictions,
such as people with a certain right only being able to edit part of the
configuration object.
And in the end, storing config in wiki pages is a hack, they where not
designed to facilitate such usage.
== Request for Discussion ==
How would you go about creating a generic solution for storing revisioned
configuration?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hi folks,
Here's the list of release blockers for 1.18:
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&target_milestone=…
...with summaries below. Basically, we're down to two bugs. Could we
get some front end development love here?
==========================
WikiEditor scrolls the browser and does not insert on IE8 on Windows 7
https://bugzilla.wikimedia.org/32241
Reported November 7, but repro'd on three different machines. This
seems like a problem we should also be fixing in deployment.
==========================
Unable to add/remove buttons from (classic) toolbar from a gadget
after MW update
https://bugzilla.wikimedia.org/31511
It's actually not clear to me that this should be a 1.18 release
blocker. It's a problem that seems to have occurred in some form on
1.17, and as Roan says: "It seems the old toolbar's interface for
adding buttons depends on loading
order too much. The WikiEditor toolbar's interface is a bit better in
this regard, but not much. These interfaces should be redesigned such
that the loading order either doesn't matter or must be
toolbar-first-gadget-later (so the gadget can depend on the toolbar
and force the order to be that way), and such that adding, removing
and modifying buttons at any location in the toolbar is supported."
This seems like an architectural issue that isn't going to get solved
in the time that we'd like to get 1.18 finished off, so if others
agree, the simple fix may be "put it in the release notes". Let's
either agree on this, or agree on a plan for fixing this.
Thanks,
Rob
Just to remind you:
* India hackathon (18–20 November, Mumbai, India) — Alolita Sharma,
Siebrand Mazeland, Sumana Harihareswara and the local India team are
preparing for this event, which will focus on language, mobile and
offline support for MediaWiki content. You can register to request a
free invitation; approximately 100-125 attendees are expected.
https://www.mediawiki.org/wiki/India_Hackathon_2011
* Brighton hackathon (19–20 November, Brighton, England) — Free
registration is open for the general MediaWiki hackathon planned by
Lewis Cawte. You can register online. WMF engineers Antoine Musso, Roan
Kattouw, and Sam Reed plan to attend.
https://www.mediawiki.org/wiki/Brighton_Hackathon_2011
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Today I /successfully /integrated Etherpad-lite - one or several "pads"
- on MediaWiki pages.
I plan to publish this as an MediaWiki:Extension soon.
Tom
We've been throwing away contributors.
I appreciate everyone who has responded to patches and questions in
Bugzilla.[0] But sometimes someone offers us a patch and we don't
respond for months or years, and the contributor gets the impression
that we don't care, and leaves. We should prevent that.
In the last week, I've clarified keywords for 100+ MediaWiki bugs that
have patches attached. If a patch still needs review, the bug now has
the "patch" AND the "need-review" keywords. (We were using the latter
inconsistently.) If a patch has been reviewed, either with approval
(someone's committed it to SVN) or with criticism that requires a
response & rewrite, the bug has the "patch" and "reviewed" keywords.
So we have about 216 patches against MediaWiki, and at least 44 against
WMF-deployed extensions, awaiting review. Ugly BZ queries[1][2] are
linked at https://www.mediawiki.org/wiki/Code_review_guide#See_also .
If you respond to a patch, please thank the author for his or her patch,
even if it is obsolete or sucks. A patch is a gift.
The developer you encourage today might review your code in six months
and, in a year, seem indispensable. I've responded to some folks whose
patches were really obsolete and asked them to revise. Sometimes they
say yes. Sometimes they say, "Mediawiki took so long to review my
patches that I ended up making a private fork of the code... and I'm not
sure when/if I'll try to re-sync." Let's not lose these people.
[0] Special thanks to Santhosh, hexmode, Antoine, John du Hart,
Platonides, bawolff, Chad, Timo, and Bryan Tong Minh for their recent
help and responsiveness. If I left you out, I'm sorry!
[1] for MediaWiki:
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
[2] for WMF-deployed extensions:
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
mponent=PdfHandler&component=Poem&component=PoolCounter&component=Renameuser&component=RSS&component=SecurePoll&component=SiteMatrix&component=Spam%20Blacklist&component=SyntaxHighlight%20%28GeSHi%29&component=TitleBlacklist&component=TitleKey&component=TorBlock&component=Vector&component=WikiEditor&component=WikiHiero&component=WikiLove&keywords=patch%2C%20need-review%2C%20&keywords_type=allwords&product=MediaWiki%20extensions&query_format=advanced&resolution=---&query_based_on=MW%20extensions%20with%20patches%20that%20need%20review&columnlist=bug_severity%2Cpriority%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ckeywords%2Ccomponent&list_id=48929
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Sorry resend from a different email address
Hi Paul,
I strongly dispute the claim that non-profits are famous for having
terrible websites. See
http://www.soschildrensvillages.org.uk/charity-news/charity-editorials/anat…
as an example of a non-profit which is hugely successful online and
www.our-africa.org as
a cutting edge non-profit website
Andrew
> =======================================
>
> On Thu, Nov 10, 2011 at 1:34 PM, Paul Houle <paul(a)ontology2.com> wrote:
>> Here's a crazy question.
>>
>> Non-profit organizations are famous for having terrible web
>> sites. Generally they get a fixed budget and after they spend it, they
>> have a party and announced that they succeeded. Nobody ever tells the
>> users, or rather, the people who might have been the users if they
>> found out about it.
>>
>> For a long time I thought "non-profit" was a cause of failure, or
>> rather, that profit was a cause of success. Nobody at a library
>> benefits from making a digital library 5% easier to use, but if a
>> company like AMZN improves its site by 5%, that translates into happy
>> customers plus a pile of money that can go into bonuses, dividends, etc.
>>
>> That continuous improvement is missing in most non-profits. At
>> best they get a series of grants to do things and set goals for major
>> upgrades. Sometimes these upgrades fail, sometimes they really help,
>> often they end up spending a lot of money for 3 years to get something
>> that's about the same as what they had before.
>>
>> How does the Wikimedia foundation escape this trap?
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
Recording here that Diederik van Liere (diederik), a researcher who
works with dumps files, is moving from extensions-only access to core
access as well. Good luck, Diederik!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation