A cool software history project, "Architecture of Open Source
Applications," asked MediaWiki for a short history of our software.
So we're collecting your historical knowledge, stories and opinions on
MediaWiki's architecture. Go to
http://www.mediawiki.org/wiki/MediaWiki_architecture_document
to find out more, and go to the orange "Add your piece." box to share
your thoughts. We have a few questions for you to answer. If you
have a few minutes to answer them, please do it by September 30th so
Guillaume Paumier and I have time to organize all the contributions
into one coherent narrative.
Thanks!
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Forwarding to wikitech-l. Private e-mail threads are not a transparent
way to discuss this.
-Chad
---------- Forwarded message ----------
From: Snotty Wong <snottywong.wiki(a)gmail.com>
Date: Tue, Sep 13, 2011 at 12:02 PM
Subject: Autoconfirmed article creation trial
To: Jimbo Wales <jwales(a)wikia.com>, Jimmy Wales
<jwales(a)wikia-inc.com>, sgardner(a)wikimedia.org, Philippe Beaudette
<pbeaudette(a)wikimedia.org>, brion(a)wikimedia.org,
bharris(a)wikimedia.org, rlane32(a)gmail.com, jalexander(a)wikimedia.org,
ariel(a)wikimedia.org, aschulz4587(a)gmail.com, robla(a)wikimedia.org,
swalling(a)wikimedia.org, innocentkiller(a)gmail.com,
tstarling(a)wikimedia.org, Mdennis(a)wikimedia.org
Cc: Kudpung <kudpung.wikipedia(a)gmail.com>, yanksinfinite(a)aol.com
Dear WMF staff and developers,
I'm User:Snottywong on en-wiki and I'm emailing you on behalf of
several other en-wiki users who have been helping to organize a trial.
The trial, which you may already be familiar with, is to temporarily
restrict new article creation to autoconfirmed users. If you're
unfamiliar with the details, you can catch up by reading the original
bugzilla thread I started in an attempt to implement the trial. (See
https://bugzilla.wikimedia.org/show_bug.cgi?id=30208)
The bugzilla thread has largely become stale, there has been no
activity for several weeks. It's clear that some developers are not
in favor of this trial, as they believe it will result in a reduction
in new editor retention. It would be an assumption of bad faith to
say that the developers are purposely ignoring the bugzilla thread in
the hopes that the volunteers who organized it will give up on trying
to implement it, but sadly it appears this may be happening. This
email is an attempt to reopen the lines of communication between the
volunteers who organized this trial and the developers, in the hopes
that this more private communication will facilitate coordination. I
can assure you that nothing you send me in an email will be publicly
posted.
The situation, from the perspective of the volunteer editors who
organized the trial, is this: We put together a proposal to restrict
article creation to autoconfirmed editors. We posted notices to the
proposal in the most public places on Wikipedia, the village pump,
WP:Centralized discussion, etc. Over 500 editors contributed their
opinions to the proposal over the course of 2 months. The proposal
was then closed by an uninvolved admin, with the view that the
proposal had been widely endorsed and there was consensus for the
change. The admin also noted that there was strong support for a
trial of the changes before they are made permanent, and that this is
the direction in which we should proceed.
Anyone familiar with Wikipedia knows that it is spectacularly amazing
for a proposal that was open for 2 months with 500+ editors
contribution to actually succeed.
So, we proposed the change, got strong support for it, and then we
asked you guys to make it happen. And we feel like the response we
got was "we don't think that's a good idea, so we're not going to do
it." This was a very disappointing response for us, partly because of
the hard work we had put in to organize the proposal and the trial,
and partly because it goes against the fundamental Wikipedia concept
of governing by consensus; one of the most important aspects of
Wikipedia which has gotten it where it is today.
After digesting this response for awhile and regrouping, we understand
your natural instinct to protect Wikipedia from a change that you
believe could hurt it. This is the perspective we're coming from as
well: we believe that the number of inappropriate and very poor
quality articles that are created every day by very new users is
hurting Wikipedia in a different way. We do our best to patrol these
new articles and we try to ensure that these inappropriate articles
don't make it past our defense mechanisms, but there are simply too
many to handle and plenty make it through. This is evident when you
click the "Random article" button a few times.
It's also understandable that it's easy to assume that this trial, on
the surface, will lead to less new editors and less new articles. On
the contrary, we believe that it will lead to more serious editors and
better quality articles. Quality over quantity. We believe that with
Wikipedia approaching 4 million articles, there is a natural decline
in the number of new things that can be written about; and that
instead of focusing on creating new articles, editors will begin to
focus on fixing the ones we already have.
But, we will never know what this change would bring unless we
actually try it. This is why we want to implement it only as a
temporary trial, and reserve judgment until after the trial. We need
your help to make this happen. Specifically, we need:
1. Your cooperation. Nothing will happen if you guys stonewall us and
refuse to act, and this would be a devastatingly disappointing outcome
for dozens of editors.
2. Your expertise. Changes to the MW software are required to
implement this trial. Some comments on the bugzilla thread imply that
these changes are relatively minor. We also need to collect copious
statistics about the effects of the trial. We can do much of this
work ourselves, but we need your help in both collecting the
statistics as well as determining which ones are important.
3. Your creativity. Obviously, preventing people from creating new
articles will produce some level of an annoyance factor for them. The
more positively we can communicate this restriction to new users, and
the more options we can give them to create new articles and become
autoconfirmed more quickly, the less annoyed the users will be. If we
can make them feel like they've earned the trust of other editors by
the time they become autoconfirmed, they will be that much more
invested in the whole concept of Wikipedia.
We have started some of this work at WP:ACTRIAL, but there is only so
much we can do as volunteer editors with limited time and no developer
access. We need your help. Please let us know if we can come
together to make this happen, and let's lay out a road map for
cooperatively and collaboratively implementing this trial.
Best regards,
Scott (User:Snottywong)
Brian Wolff suggested a new tag for Bugzilla and, since I thought it
was good idea, I created it. The new tag is "controversial" for issues
that probably need more discussion so that consensus is reached. He
writes:
It'd be useful to have a tag to mark bugs that would normally be
marked "easy" but are controversial - since we don't want the newbie
devs doing things that will get everyone yelling at them. Things
like change the "you have new messages" box to a different colour
and that sort of stuff. There's more then a couple bugs that are
"Easy" simple one lines, its just that we need to decide if they're
things we should do or things we should WONTFIX, and that's probably
not the best spot for a newbie to jump in.
Thanks for the suggestion, Brian!
Mark.
Hi everyone,
as one of the students working for MediaWiki under Google Summer of Code
2011, let me thank you for answering my odd questions, and bringing insight
in areas I might have overlooked.
Through the last three months, guided by my mentor Markus Krötzsch, and the
people at Semantic MediaWiki (especially Jeroen De Dauw), I've been trying
to build a newer way of constructing queries.
As part of that initiative, we've built an interface called QueryCreator,
which improves on it's predecessor, Special:Ask. QC's makes many tiny
improvements over Special:Ask, but mainly requires you to know less about
the query syntax. Some of the bigger improvements are:
1) A less cluttered interface
2) Auto-complete for properties and categories using the MW API.
3) An interesting javascript based Print-out builder, with associated modal
windows.
We have not completely eliminated the use the SMW query syntax in the
interface(that could be a good goal for the future), but we believe a new
user without any prior experience of SMW should be able to query your SMW
wiki, without poring over the help-files. We hope to put QueryCreator in the
upcoming release of SMW.
The other (but related) work we've done is to try and look for those
functionalities which need to be repeatedly implemented by a programmer
while making other Query interfaces. We know that a single query interface
may not always be suited to all kinds of users, nor to the many different
domains where SMW is implemented. So we've done some work building two
classes called QueryUI and QueryUIHelper, which encapsulate much of the core
behaviour as well as some commonly used interface elements, so that it may
be easier for you (developers) to build a query interface in the future.
You can have a look at my commits on the work at
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/devayon
If you have any comments about this work, please let me know. I have plans
to improve upon my work from these last few months, and look forward to your
insights.
On a related note, a big thank you to Sumana at Wikimedia Foundation for
making it so easy for all the GSoC 2011 participants (there were 8 of us in
the beginning) to contribute.
It's been a fun experience, and I hope to keep contributing code to SMW in
the future.
Cheers,
Devayon
Hi folks,
as a quick update, Alolita, Rob & I presented a tech talk at Google
Mountain View last Thursday. The slides are up at:
http://wikitech.wikimedia.org/view/File:Infrastructure_of_Collaboration.pdf
They're not terribly self-explanatory, so you'll want to see the video
to make sense of them -- should go up soon on
http://www.youtube.com/user/GoogleTechTalks
The intent of the talk was to give a quick all-round update across
Wikimedia's engineering projects, to help refresh the understanding of
Googlers and anyone else who might be watching.
It's good for us to do these once a year to keep folks up-to-date, and
get some of them excited about helping :-)
Cheers,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Thanks for showcasing projects done by GSoC students, this will definitely
go a long way in inspiring future participants
-Akshay Agarwal
GSoC-11 student
Thanks for showcasing projects done by GSoC students, this will definitely
go a long way in inspiring future participants
-Akshay Agarwal
GSoC-11 student