Call for Developers
We are planning to create a Digital Library Card Platform for The Wikipedia
Library. We are looking for a developer, or team, with a history of
successfully developing web applications in open development frameworks
(such as Drupal, Angular, Ember, CiviCRM, etc.). Efficient production,
clear communication, and well-structured and secure code are a must.
Additional consideration will go towards applicants who have worked in the
Library and Information Science field, on Open Source projects, or in the
Wikimedia/Mediawiki communities. Our budget currently allows for
$5000-$15,000 for development of a working version within 4- 6 months. We
expect to expand the platform in two later phases to add additional
functionality around standard library services.
The Wikipedia Library helps Wikipedia's top editors receive access to
donations from leading publishers and databases. Now that we have over 3
dozen publishing partners including Elsevier JSTOR, Oxford University
Press, and SAGE, AND nearly a dozen global branches with 2 dozen more
planned for the next year AND commitments to support other TWL programs
across the globe... we need to create a system that will facilitate our
expansion. In the past, manual and separate processes for delivering
access were appropriate, but this year's focus is on scaling and
growth. Developing
the Digital Library Card Platform tool is a top priority for us this year.
Qualified and interested applicants should read this project overview and
fill out the form linked on this page:
*https://docs.google.com/document/d/1S_Da5E4mKcpVASNCtZyVnzkdXcVUPKD49bAwqxfHoIY/edit?usp=sharing
<https://docs.google.com/document/d/1S_Da5E4mKcpVASNCtZyVnzkdXcVUPKD49bAwqxf…>*
Please feel free to share this email with friends or colleagues who may
also be interested.
Best,
*Jake Orlowitz*
<https://www.linkedin.com/profile/view?id=AAIAAAvHNLMBweA-KfaGsjpRk0P4hoI6Oo…>
*Head of The Wikipedia Library <https://meta.wikimedia.org/wiki/TWL>*
*Wikimedia Foundation*
Hello!
As part of our goal to reduce the zero results rate
<https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q1_Goals#Search>,
the Discovery Department is currently running an A/B test to try different
parameters for the search suggester. We're hoping that our new parameters
will give users more suggestions without decreasing their quality.
The reason we've chosen to tweak the suggestions is because of our recent
work <https://phabricator.wikimedia.org/T105202> to automatically run
queries for the user if they get zero results but have a suggestion. The
purpose of this A/B test is to determine whether this has significant
impact towards achieving our goal or not.
This is the first A/B test that the Discovery Department has run, so we're
still ironing out the process. We hope to run many more A/B tests in the
future.
For further information on this, please review the associated Phabricator
task <https://phabricator.wikimedia.org/T108103>.
If you have any questions, I'd be happy to answer them.
Thanks,
Dan
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
Hi, the Engineering Community team is starting to plan our goals for
October-December.
Your feedback at https://phabricator.wikimedia.org/T109829 is welcome. If
there is a task you want us to push in the next quarter, now is the right
time to discuss it.
Your involvement is also welcome. If there is a task related with
Engineering Community that you want to own, and you want to handle it as
part of our lightweight project management process, you can join us.
You can learn more about ECT's roadmap and future plans at
https://phabricator.wikimedia.org/T101099 and
https://phabricator.wikimedia.org/tag/engineering-community/
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
In the next RFC meeting, we will discuss the following RFC:
* Replace Tidy with HTML 5 parse/reserialize
<https://phabricator.wikimedia.org/T89331>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00
-- Tim Starling
Thanks for sharing this, Risker. If I were a casual contributor, I'm not
sure that I would attend either--not because I'd expect that Wikimedia
conferences/hackathons would necessarily be worse than other tech
conferences, but because I'd have no reason to expect them to be better.
Same with our online spaces: I was hesitant to apply to the internship that
started me contributing technically because I'd observed profoundly
unfriendly open source projects and had also been bitten on enwiki, and I
expected the technical spaces to be similar. I'm glad I did apply. Since
then, I've been able to work with some wonderful people here and I've made
contributions I'm proud of for a cause I support. I would like to be able
to point the next person with similar worries to a community-supported code
of conduct as a reassurance that the community as a whole will have their
back even if one or a few individuals treat them poorly.
-Frances
On Sat, Aug 22, 2015 at 6:04 PM, Risker <risker.wp(a)gmail.com> wrote:
> David, thanks for this find.
>
> THIS is why the Code of Conduct is needed. I recognized myself in this
> blog. I remembered avoiding any aspect of socialization at conferences I
> had to attend for work, and simply didn't even consider attending
> conferences for any other purpose. I remembered how readily "the guys"
> assumed that any woman there was there for more than just networking and
> learning. I remembered having my butt pinched, my breasts "accidentally
> touched", my questions ignored or laughed at. I remember how the buzz of
> background conversation is always much louder when the speaker is a woman
> than when the speaker is a man.
>
> It's changed for me. Not because there's any less of all of this going on.
> No, it's because my hair is grey and I'm now old enough to be the mom of
> half the people in the room at any male-dominated conferences I attend; and
> outside of Wikimedia events, the conferences I go to are usually full of
> conservative businesswomen, and alcohol is rarely involved.
>
> So yeah...you need a code of conduct. Because if I was even 15 years
> younger, I'd never go to a Wikimedia conference.
>
> Risker/Anne
>
> On 22 August 2015 at 20:03, David Gerard <dgerard(a)gmail.com> wrote:
>
> > I saw this today, I wonder if it's relevant to the thread:
> >
> >
> >
> http://www.perpendicularangel.com/2015/08/no-i-dont-trust-your-conference-w…
> >
> > Of course we're talking about stuff beyond conferences, but it still
> > applies I'd think.
> >
> >
> > - d.
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
We (Kevin Leduc, Megan Nestler and I) will be doing a second run of
lightning talks <https://en.wikipedia.org/wiki/Lightning_talk> on August
25. The first round had about 40 people viewing living bother remotely and
in SF as well as another 45 views after the talks.
~ More logistic details/signups found in the email below ~
These lightning talks are meant for anyone working on wikimedia tech and
are not limited to WMF engineers. If you would like to do a lightning talk
on any project you are working on please feel free to sign up. Make sure to
include contact information (or email it to me) so that we (the lightning
talk organizers) can coordinate with you. These lightning talks should be
relevant to something related to our movement and will mostly be focused on
tech related projects however it is not mandatory that they are related to
tech.
These talks will continue every month until there is no longer interest.
A youtube stream will be sent out to this list just before the talks start
so you can follow along, you can ask questions on IRC, and the talks will
also be recorded so that you can watch them whenever you like.
We will adapt this process as we go to make it as interesting and useful to
everyone as we can.
---------- Forwarded message ----------
From: Kevin Leduc <kevin(a)wikimedia.org>
Date: Tue, Aug 11, 2015 at 6:26 PM
Subject:
To: wmfall(a)lists.wikimedia.org, Engineering list <
engineering(a)lists.wikimedia.org>
Cc: Rachel Farrand <rfarrand(a)wikimedia.org>, Megan Neisler <
mneisler(a)wikimedia.org>
Hello!
The next round of Lightning Talks are in two weeks. This effort will not
work without your participation...
Lightning Talks are an opportunity for teams @ WMF & in the Community to
showcase a Quarterly Goal acheived, significant milestone, release, or
anything of significance to the rest of the foundation and the movement as
a whole. These talks will be open to our communities.
Each presentation will be 10 minutes or less, the formal part should be not
be longer than 5 minutes and the remainder can be used for questions.
Too many questions to answer in the allotted time? No worries, your
lightning talk will be a great candidate for a future Tech Talk.
Second Round of Lightning Talks:
When: Tuesday August 25, 1800 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lightning+Talks+-+…>,
11am PDT
Where: 5th Floor
Remotees: On-Air google hangout will be provided just before the meeting
IRC: #wikimedia-tech
Sign up for a 10 minute slot here:
https://www.mediawiki.org/wiki/Lightning_Talks
With interest, this meeting will become a monthly event.
Thanks!
Kevin Leduc, Rachel Farrand, Megan Neisler
Hi everybody,
one requirement for the Gerrit Cleanup Day planned for September 23rd
([1], I still need to send a proper announcement, sorry for that) is to
allow marking code repositories as inactive.
This requires agreeing on criteria what's "inactive", after which time
span, and on a process that allows people to mark projects as such.
There is a proposal in
https://phabricator.wikimedia.org/T102920
concentrating on what's feasible currently with our given tools.
It welcomes more feedback. If you're interested I kindly ask you to
take a look at the Phabricator task and add your comments there.
Thanks in advance!
andre
[1] https://phabricator.wikimedia.org/T88531
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi all,
as previously announced, we've been evaluating a "clustering solution"
for use as an alternative to GridEngine for toollabs
https://lists.wikimedia.org/pipermail/wikitech-l/2015-August/082853.html
Our goal is also to find a suitable, modern, stable tool to run not
only toollabs webservices, but also - on a longer term - to find a
modern, easier, more convenient way to run our microservices in
production: a clusterized environment that will allow us to enhance
single service availalbility and also to apply easier scaling of
applications, reducing further the friction surface and the direct ops
involvement in the day-to-day setup and deployment of services.
Our evaluation of the available solutions is ongoing, and while we're
mostly done filling up an "evaluation spreadsheet"
(https://docs.google.com/spreadsheets/d/1YkVsd8Y5wBn9fvwVQmp9Sf8K9DZCqmyJ-ew…),
we would welcome and we encourage further involvement/suggestions. You
can provide these easily on the tracking ticket for the evaluation,
https://phabricator.wikimedia.org/T106475
We received some interesting feedback already, and we look forward
incorporating more!
We are considering two solutions - mesospheres' Marathon (which is
based on Mesos) - https://mesosphere.github.io/marathon/ and Google's
Kubernetes https://kubernetes.io.
Now let us summarize a bit our findings so far:
MESOS/MARATHON:
Pros:
- Mesos is stable and battle tested, although Marathon is
quite young and mostly used in mesosphere's commercial offering
- Supports overcommitting resources (which is important in
toollabs, probably less so in production)
- Has a nice, clean API and is fully distributed with no potential SPOFs
- Chronos is another framework that can run on mesos and is a
great distributed cron
Cons:
- Multitenancy story is non-existent, it was not designed to
be a public PaaS offering. This is an issue even in production if we
want to grant independence to single teams.
- Container support seems experimental at best.(but getting
better in newer versions)
- Adoption of Marathon seems little and the community is not
very lively.
- Discovery/scaling logic is somewhat limited
KUBERNETES
Pros:
- The design seems to be very well thought out, based off of
experiences running Google's internal Borg system (see
http://research.google.com/pubs/pub43438.html for details of Google's
Borg clustering system).
- A pretty refined security model is already implemented, so
that single users/teams could be given access to individual namespaces
and act independently
- The community is very lively, and adoption is gaining
momentum: kubernetes is the default way to deploy apps on Google
Compute Engine, it's used by Red Hat for its own cloud solution (and
they contribute patches to it), it has a clear roadmap to overcome
most of its limitations
- Container support is native and it's tecnology-agnostic,
allowing (for now) Docker and Rkt containers to be used
- The API is quite nice
- Documentation is decently complete
- Google engineers are actively supporting us in evaluating its usage
Cons:
- The master node is not highly available, although our
cluster survived a pretty serious outage in labs that froze the master
and wiped out one worker
- No overcommitting allowed, it will be possible to mimic it
with QoS (coming in the next version)
- The ability to schedule one-off jobs is offered, but there
is no distributed cron facility
- In general it's a younger project with some outstanding bugs
As you can see there are pretty big pros/cons for both these
technologies, due to the fact they are still quite "not boring" -
although one could argue that mesos and chronos at least have entered
their "boring" stage. Our spreadsheet slightly favours Kubernetes at
the moment, but that might change drastically, if we evaluate that
some limitations are absolute showstoppers for us.
In the remainder of this week and the next few ones, we will keep
stress testing both our test installations to find out "surprises" and
bugs.
Let us know what you think - or reach out to us if you want to help in
this evaluation process. We will keep you posted!
Cheers,
Giuseppe & Yuvi