Hi all,
I am trying to profile the JavaScript bit of an extension I maintain. Is there any recommended method similar to wfProfileIn/Out in MediaWiki? How do you do profiling on ResourceLoader?
Cheers, Markus
2012/1/6 Platonides <platonides(a)gmail.com>:
>
> Integrating this into ConfirmEdit extension shouldn't be hard. It's the
> extra features what makes this tricky. This system is interesting for
> gathering translations, but doesn't work for verifying that the answer
> is right. How would you verify that?
> The approach that comes to my mkind is to show both the current captcha
> plus another, optional, captcha, with a note about how filling that
> second captcha helps wikisource, and that the answer will be logged with
> their username/ip.
ReCAPTCHA already works in a way similar to this. Two words are
presented but only one is known and actually serves to filtrate
accesses. They then collect answers for both words and if the test on
the first is passed (which indicates a human) then the answer for the
second is recorded. When a certain number of people agree on the
transcription of a previously unknown word then that transcription is
taken as good and used in future as a filter word.
We could say that we accept a transcription as "valid" after N people
agrees on a given word and put back on Wikisource only the validated
words (and also use them as filters, too) . This seems both a reliable
and easy-to-implement system to me.
Anyway, at the beginning we could use the system you describe using
the current captcha and words from books.
I believe the trickiest part is creating a system to put results back
in Wikisource in a semi-automated way, but having "captcha reviewers"
may help.
We could also decorate our captcha with "this captcha helps
transcribing <BOOK TITLE> + link".
And this leads me to what I think is the real point: once we have a
basically-working system we can think to whatever useful feature and
implement it, in principle we can have a modular system which can be
refined /at libitum/.
Cristian
Please take time to check out the bugs that we've tagged as blocking the
1.19 deployment and see if you can fix them: http://hexm.de/ee
I'm especially hopeful for #33989 (https://bugzilla.wikimedia.org/33989)
which hasn't yet been assigned.
We would like to have 1.19 ready for deployment in by the end of next
week.
Thanks!
Mark.
Hi, I have installed the Mobile Frontend extension in my pet project
at http://espiral.org
I only get to the mobile view manually, through the link at the
footer. Autodetection of mobile browsers doesn't seem to work or I
have done / missed something in my installation. I have got feedback
from a bunch of users with a bunch of devices, nobody got the mobile
view by default and all of them get it when visiting
http://en.wikipedia.org
Something that looks different in my installation compared to
Wikipedia's is the lack of a redirect to a ".m." URL. I'm actually a
bit confused about this. It is mentioned briefly at
http://www.mediawiki.org/wiki/Extension:MobileFrontend but it is not
clear to me whether this is something supposed to work automagically
when installing the extension or whether there is something I need to
do with the WURFL database, the LocalSettings.php, the web server...
Other than this the extension works great presenting the mobile view
of pages. Thank you very much for your work!
--
Quim
I'm using more and more #switch into templates, it's surprising how many
issues it can solve, and how much large arrays it can manage. My questions
are:
1. Is there a reasonable upper limit for the number of #switch options?
2. Is there a difference in server load between a long list of #switch
options and a "tree" of options t.i. something as a nested #switch?
3. Is there any drawback into a large use of #swtch-based templates?
I presume that my questions are far from original, please give me a link to
previous talks or help/doc pages if any.
Alex
Hi.
Is there a list of (current) impediments to forking a Wikimedia wiki? Image
access, available dumps, replicating parser, replicating user table, etc.
MZMcBride
Hi folks,
I requested a configuration file for squid weeks ago, but it seems to be a
bit complicated to remove confidential data from it. I suppose we should
split it to multiple files, having some public and private, and keep the
public files with no server specific lines in puppet, so that we can simply
push the updates from labs to production. Would it be possible? This would
enable us to keep the config of labs and production synchronized.
Hello all,
It’s with great pleasure that I announce the promotion of Howie Fung
to the position of Director of Product Development at the Wikimedia
Foundation, effective February 1.
Howie joined us in October 2009 as a consultant for usability
projects, and became a permanent staff member in May 2010. Prior to
Wikimedia, Howie was Senior Product Manager at Rhapsody, where he
helped grow the music site's traffic five-fold within the the first
year on the basis of extensive customer research, including web
analytics, focus groups, user testing, and customer surveys. Prior to
that, Howie was Product Manager at eBay, prioritizing features based
on business objectives, usability studies, and economic impact. He
has an MBA from The Anderson School at UCLA and a Bachelor of Science
in Chemical Engineering from Stanford University.
I’m really proud of all the work Howie’s done for Wikimedia since he’s
joined, calmly and rationally introducing method where there was
madness, always challenging us to increase our understanding of our
communities and to use our limited resources for the projects that are
likely to have the highest impact. In addition to the work he’s done
on the Usability Initiative, he’s worked on a variety of projects,
including the Editor Trends Study, the Former Contributors Survey, the
Article Feedback Tool, Moodbar, and the Feedback Dashboard. We’re
very lucky to have him in this new role.
This announcement also means that we’re formally establishing a
Product Development department at Wikimedia, which is part of the
larger Engineering department. Product, in our context, means really
digging into what we want our projects to look like in a year, in two
years, in three years, and working together with software developers
and architects, as well as across Wikimedia, to make that vision a
reality. Our work will be organized along the following product
areas: Editor Engagement, Mobile, Analytics, and
Internationalization/Localization.
The following staff and contractors will be part of the Product group,
going forward: Phil Chang, Brandon Harris, Fabrice Florin, Diederik
van Liere, Siebrand Mazeland, Dario Taraborelli, Oliver Keyes, and the
new Interaction Designer, when hired.
The Mobile team, which works on both mobile apps (such as the
Wikipedia Android app) and the mobile web experience, is a good
example of how this works in practice. It has Phil as a product owner
(reporting to Howie), Tomasz as a scrum master and engineering
director, and Patrick, Arthur, Max, and Yuvi as engineers (reporting
to Tomasz). The team itself is the most important unit here: it drives
the success of any given initiative. The connection into the Product
Development group helps to ensure we follow a consistent strategy and
coordinate efforts across the board. [1]
This is an important step in our organizational development and will
help us parallelize and coordinate product and engineering work more
effectively.
Please join me in congratulating Howie, and WMF. :-)
All best,
Erik
[1] In case you’d like to learn more about agile product development
and software engineering, this presentation is a good intro to scrum,
a specific methodology we've started to use on a couple of teams:
http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi, as some of you may already noticed, I've resurrected Trevor's
creation of old - ArticleEmblems that allows to add icons to the right
of the area below article title. All the architectural problems that
caused its demise before were resolved, so I'd like to invite more
people to participate. First of all, the way these templates are
outputted is flaky - but I think it's not a problem to fix.
--
Best regards,
Max Semenik ([[User:MaxSem]])