Everyone,
I am pleased to announce that we have two contractors joining the Technology
team. Fabrice Florin will be joining us for the next six months as Product
Consultant, leading the development of the next version of the Article
Feedback Tool. Oliver Keyes (User: Ironholds on enwp) will be joining us as
a community liaison for the next three months. His role is to help ensure
that the community input is better incorporated into WMF’s product
development process.
Fabrice has extensive background in the fields of education and journalism.
He is founder and executive director of NewsTrust, a nonprofit social news
site devoted to good journalism -- as well as Truthsquad, a network
dedicated to fact-checking the political claims made during election
campaigns. His previous ventures include: Handtap, a wireless content
service for mobile phones; shockwave.com, a web entertainment site at
Macromedia; Apple Computer's Multimedia Lab, a new media R&D group; and a
variety of other roles in media and technology. Fabrice earned four patents
for his interactive TV work at Apple and was recently elected an Ashoka
Fellow for his work as social entrepreneur [1]. Read more in his online bio[2].
Oliver has been an editor since 2006 and is both an administrator and an
OTRS volunteer on the English Wikipedia. With strong experience in content
creation as well as administrative tasks, he has a broad base of knowledge
that will undoubtedly be helpful in coordinating community feedback,
organizing discussions, and making sure more voices are heard as part of the
product development process.
As many of you know, the Tech department continues to look for ways to
gather input from our experienced editors when designing new features.
Oliver’s job will be to act as a conduit between WMF’s development team and
members of the community, helping editors make suggestions on feature
development and helping ensure that the Foundation incorporates this input.
Fabrice may be reached at fflorin at wikimedia dot org, as well as his
userpages on the English Wikipedia and Mediawiki ([[User:Fabrice Florin]]).
Oliver will be on the projects as [[User:Ironholds]] and [[User:Okeyes
(WMF)]]; he can also be contacted directly via
http://en.wikipedia.org/wiki/Special:EmailUser/Okeyes_%28WMF%29.
We’re very excited to be working with Fabrice and Oliver. Please join me in
welcoming them!
Howie Fung
Senior Product Manager
Wikimedia Foundation
[1] http://www.ashoka.org/fellow/fabrice-florin
[2] http://newstrust.net/about/bio_florin
Hi everyone,
A belated (re-)welcome to Antoine Musso (a.k.a. "hashar" on IRC) as a
contractor working on continuous integration (e.g. beefing up our unit
tests, improving our Jenkins configuration, figuring out how to
integrate TestSwarm, etc). Antoine has been working in our community
for quite some time, going by the name "Ashar Voultoiz" on mailing
lists, and by "hashar" on IRC. Now that he's working as a
contractor for WMF, he's decided to let everyone know the Superman
behind the Clark Kent alter ego :)
You've probably already seen him be even more active (if that were
possible) in SVN and elsewhere since Monday, which is when he
officially started.
Welcome, Antoine!
Rob
* DJ Bauch (djbauch) -- extensions & tools access -- Microsoft SQL
Server support
* cryptocoryne -- extensions & tools access -- Extension:AutoProxyBlock
Welcome!
(We are not completely through the commit access queue at the moment,
but I hope to get down to zero this week.)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hi All,
Please join me in welcoming Gabriel Wicke as a Software Developer in
WMF’s Features Engineering team. Gabriel will be working on the
Visual Editor - Parser project, one of Wikimedia’s high priority
projects this year. He will be working closely with our guru Brion
Vibber on extending the parser to support WikiDom interactions with
the Visual Editor client being developed by lead engineer Trevor
Parscal, Wikia developer Inez Korczyński and front-end developer Neil
Kandalgaonkar.
As many of you may already know, Gabriel has been member of the
Wikipedia community for many years now. He discovered Wikipedia in
2003, when it was still running on two servers. Using his previous
experience with Squid caching, he got involved in technical
discussions and hacking. In 2004, Gabriel designed and implemented the
initial Squid caching layer, and later wrote the MonoBook skin.
After completing his Computer Science degree and doing research in
transactional distributed systems and Haskell, Gabriel is looking
forward to more practical challenges at Wikimedia.
Gabriel is an avid sportsman and professional sailor. When he’s not in
front of a computer coding away, he is often sailing on his own or
with friends. He was a member of the German national team in the
Olympic 49er class from 2001-2008, and is now racing an A-Class
catamaran. Pretty awesome!
Say hello to Gabriel online. He can be found on #mediawiki as gwicke.
Welcome back Gabriel! Great to have you on the Wikimedia Features team :-)
Alolita
--
Alolita Sharma
Director, Features Engineering
Wikimedia Foundation
Hi everyone,
For a long time, we've been talking about migrating from Subversion to
Git. It's time to start getting more serious about it.
First: the need to do this. There is pretty broad acceptance that we
should move to a distributed version control system (DVCS). Our
current Subversion-based version control system has served us well,
but we're in need of a more suitable version control system for our
development effort. Our community is very distributed, with many
parallel efforts and needs to integrate many different feature
efforts. While we've developed lots of coping mechanisms, we sure
could use a system that's well suited to more fluid branching and
merging.
There has been resistance to this in the past, and there still may be
some resistance. However, I think we've worn everyone down. :)
Next: the selection of Git over other DVCSs. Over the past couple of
years, other systems have been mentioned (Bzr, Hg), but there hasn't
been any evidence (at least on this mailing list) for anything other
than mild support for the alternatives. As you might have seen, our
Ops folks have already moved to Git[1], and while they're right in the
middle of the tough part of the learning curve, they seem to be
adjusting just fine. The complaints seem to be of the "I really need
to get used to that" variety rather than the "why are we doing this
again?" variety. So, given the momentum that Git has, the ample
discussion we've had on the subject, and the fact that Ops is already
planning to support Git, this seems to be a settled question.
So now, the questions shift from "if?" to "when?" and "how?".
When? After some amount of arm twisting by Erik and Brion (*hugz*),
I've agreed to float a plan that has us making the migration by the
end of the year. This is completely contingent on our ability to get
1.19 deployed in a rapid fashion (which, if we can get through the
code review queue at our current rate, could be done in November).
Until we have a more fleshed out plan, though, "end of the year"
purely a guess, and subject to change (partly based on any ensuing
conversation after this mail). However, assuming we can clear the
technical hurdles, there's not any procedural issues I can see getting
in the way of a rapid transition.
How? Lots of unsorted pieces. There are still decisions we need to make:
* Code review tool: barring unforeseen complications, we're planning
to use Gerrit. We need to make sure it'll be a suitable replacement
for our existing tool
* How do we break up the repository? One big repo? Extensions each
get their own? We need to sort all of that out.
A draft plan is available here:
http://www.mediawiki.org/wiki/Git_conversion
Rob
[1] ...or so I've read on Slashdot, so it must be true:
http://hardware.slashdot.org/story/11/09/21/0531246/wikimedia-foundation-re…
Hi folks,
we're attempting, later this week, an experiment in reaching out to
new potential developers (volunteers and paid developers alike) by
means of an online coding challenge. The general idea is that, by
posing interesting challenges, we'll be able to attract interesting
people :-). It's described a bit more here (some information is out of
date): https://www.mediawiki.org/wiki/Weekend_of_Code
For this purpose, Jeroen de Dauw has led implementation of the
"Contest" extension which can be used to manage different types of
contests and have a select group of judges evaluating submissions:
https://www.mediawiki.org/wiki/Extension:Contest
The overall project is being coordinated by Greg DeKoenigsberg,
formerly Senior Community Architect at Red Hat. If you'd like to be
involved as a judge, please let him know (greg.dekoenigsberg at gmail
dot com).
This is a first experiment and it may not work, in which case we may
never do it again. Greg will post a full announcement about it
shortly, but in the meantime, feel free to poke around the
https://www.mediawiki.org/wiki/Weekend_of_Code pages, make edits or
suggestions, etc.
We'll run a CentralNotice to advertise the coding challenges, for
about a week at most. During the time the banner is running and for a
week or two beyond that, we may see a few more newbies on IRC and the
listservs. We'll set up some alternative communications channels for
them if the flood becomes too much, but I hope that won't happen and
we'll see some promising developers pop up in our community. Thanks
for your hospitality. :-)
All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
i am lost in sites, when i upload a picture where it must go?
in *.wikipedia.org or in commons.wikimedia.org?
i didn't understand...
another thing is that to take the token the user must be logged,
and i have seen that every country has got different logins,
for examples:
my login of it.wikipedia.org is different than en.wikipedia.org...
so the user must choose first the domain where want to log
and after take the token to upload the contents...
Thank's for attenction,
Simo
I did two triages at the NOLA hackathon. Unfortunately, since these were
in the flesh and I didn't have a designated note taker, I don't have a
good set of notes. Compounding the problem is the time since these
triages.
Caveats aside, I would still like to publish some brief information from
the triages.
Since Sam Reedy and I were in the same room and he had asked for my help
in sorting out the shell bugs that he handles, we set up an Etherpad
(http://etherpad.wikimedia.org/ShellSort) and started plowing through
them to classify them into three different categories.
The other triage was an attempt to cover the regressions introduced in
1.18. We made some progress
(http://etherpad.wikimedia.org/118-Regression-Triage), but in the end
there were too many to cover in a single meeting. Hopefully, with the
improved PHPUnit tests (http://integration.mediawiki.org/ci/), and
additional js tests (http://toolserver.org/~krinkle/testswarm/) we'll
have fewer regressions in our 1.19 release.
I was also able to meet with a couple of developers who were interested
in working on the Selenium testing platform so I tagged a number of bugs
that I thought could benefit from Selenium testing (see
https://bugzilla.wikimedia.org/buglist.cgi?keywords=need-regression-test).
Thanks,
Mark.
Hello dear developer community,
today I would like to awake your attention and interest on a very old
bug with the number 189:
https://bugzilla.wikimedia.org/show_bug.cgi?id=189, and related to it
Bug 29630: https://bugzilla.wikimedia.org/show_bug.cgi?id=29630
It is about the possibility of different MediaWiki plug-ins that would
enable our projects, mostly WikiSource, but also Wikipedia, to input and
show music notes on an easy way. You can really have impact on our
projects by addressing this bug and make a lot of Wikisource community
members happy.
Any takers on this?
Greetings
Ting