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
FYI!
---------- Forwarded message ----------
From: Yuvi Panda <yuvipanda(a)wikimedia.org>
Date: Tue, Aug 25, 2015 at 12:59 AM
Subject: PuppetSWAT, coming to a patch near you!
To: Development and Operations Engineers <engineering(a)lists.wikimedia.org>
Hello!
MediaWiki SWAT deploys(
https://wikitech.wikimedia.org/wiki/SWAT_deploys) are a very popular
way to get config changes deployed. In an effort to trim down the ops
review queue and encourage more non-opsen to write puppet patches,
we're experimenting with a similar setup for Puppet patches,
creatively called - PuppetSWAT!
https://wikitech.wikimedia.org/wiki/PuppetSWAT has more preliminary
details.
The tl;dr is that if you have patches to operations/puppet.git, you
can now put them in the Deployment Calendar
(https://wikitech.wikimedia.org/wiki/Deployments) and get them looked
at / merged. Just like SWAT, not all patches are suitable for Puppet
SWAT - see https://wikitech.wikimedia.org/wiki/PuppetSWAT#What_kind_of_patches_can_go_…
for guidelines and examples.
This is an experiment that'll go on for a few weeks, in an attempt to
encourage non opsen to write operations/puppet patches. There will be
two Puppet SWATs every week - one on Tuesday and one on Thursday,
right after Morning SWAT - so 16:00 - 17:00 UTC. See the Deployments
page for time in your local timezone! After a month of this (all of
September), we'll re-evaluate and commit to doing this as a team if
there's enough gains from this.
So write your simple patches and put them up for SWAT!
Thanks.
--
Yuvi Panda T
http://yuvi.in/blog
As part of Brion's and mine struggle for better A/V support on Wikipedia, I
have concluded that our current support for subtitles is rather...
improvised.
Currently all our SRT files are referenced from HTML using action=raw. But
then not actually used from action=raw, but instead served up as semi html
using api.php. Which is ridiculous...
If we want to move to more HTML5 compliancy, we also will want to switch
from the SRT format to the VTT format.
Ideally, I want to host multiple subtitle formats, and dynamically
serve/convert them as either SRT or VTT. These can be directly referenced
from a <track> element so that we are fully compatible.
The question is now, how to best do this. The endpoint needs to be dynamic,
cacheable, allow multiple content types etc.
Ideas suggested have been:
* Api.php
* Restbase
* New endpoint
* ResourceLoader modules
I'm listing the current problems, future requirements and discussing
several ideas at:
https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/TimedTextRework?…
If you have any ideas or remarks, please contribute them !
DJ
Please join for the following tech talk:
*Tech Talk**:* Let's talk about web performance
*Presenter:* Peter Hedenskog
*Date:* August 18, 2015
*Time: *19:30 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Let%2…>
Link to live YouTube stream <http://www.youtube.com/watch?v=acZ3SwbhsaM>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/c8dmvqt3n4mjn3f7…>,
another
place for questions
*Summary: *
We want our pages to be fast but how do we know they are? Today I’ll go
through the latest trends about what makes pages really super fast for the
user and ways of measuring and really knowing they are. I'll talk about
these things:
- How the browser render and show the page for the user
- What makes a web page fast and what tricks do people use?
- Measuring: why, when and how?