Hi all,
We're having a little problem to manage the jury tool app and I was
wondering if someone else besides David Narvaez have the know-how to help
us?
This problem is not related with WLM, we're working with another contest.
Kind Regards,
--
Oscar Costero
(+58) 0412-9161792
Presidente | Wikimedia Venezuela
J-40129321-2
http://wikimedia.org.ve
<http://wikimedia.org.ve/index.php/P%C3%A1gina_principal> | @wikimedia_ve
<http://twitter.com/wikimedia_ve>
cc'ing wikitech-l for your questions to get answers direct from the
source instead of me playing telephone :)
<quote name="billinghurst" date="2014-09-16" time="00:53:18 +1000">
> Thanks Greg. There was nothing mentioned in today's Tech news, so I have
> just appended some information to enWS. At the WSes we load some big
> transcluded pages and I have set a little challenge for users to make some
> comparisons. Are you going to be running data comparisons? Is this
> something that user (anecdotal) semi-quantitative data is of value? If
> yes, to the last point, what sort of direct data comparison might be of
> value?
>
> Regards, Billinghurst
>
> On Fri, 12 Sep 2014 17:42:14 -0700, Greg Grossmeier <greg(a)wikimedia.org>
> wrote:
> > <quote name="billinghurst" date="2014-09-13" time="09:38:47 +1000">
> >> > * There will be a method to opt-in to using the new HHVM-powered
> >> > backend
> >> > for all WMF wikis. It'll be implemented via a BetaFeature to make
> it
> >> > as easy as possible for people to participate. There should be no
> >> > noticeable negative impact and hopefully only positive impacts.
> >> >
> >> Greg,
> >>
> >> The last dot point. Is it there against Thursday 18th? Is it to mark it
> >> against another point? The HHVM component sits against next month on
> the
> >> deployment page, so the uncertainty.
> >
> > To answer all of your questions I'll try to rephrase things in a
> > different manner and add some more details. It might be a little too
> > detailed at first, I'll try to tl;dr at the end:
> >
> > HHVM is a virtual machine for PHP which improves the performance of the
> > servers by... a lot. We're a little shy of sharing predictions of how
> > improved the performance will be, but it'll be worth the effort.
> >
> > Thus far HHVM has been deployed to the Beta Cluster, which is our
> > testing environment based in WMF Labs. It has been running there for
> > about a month so far.
> >
> > Along side that we have a few servers in the production cluster that
> > have been migrated to HHVM. These servers are only sent user traffic if
> > and only if the user sets a cookie in their browser.
> >
> > In addition to that there are safe-guards in place where if a request to
> > an HHVM server fails, our Varnish layer will take note of that and
> > resend requests to a normal (non-HHVM) server.
> >
> > The confusion you have regarding HHVM being in the "Next Month" section
> > is because this work is on-going. There were more bullets in that list
> > initially and we will work through them as we get closer to the full
> > rollout/completion.
> >
> > What is happening next week is this: There will be a new Beta Feature
> > available to all users that will allow them to opt-in to using the HHVM
> > servers by default (the Beta Feature simply sets the cookie I mentioned
> > above). That will happen on Thursday after the normal MediaWiki deploy.
> >
> > If things go well, users who opt-in will have a better experience: pages
> > should load faster and edits should save faster, for example.
> >
> > If things don't go well, users who opt-in shouldn't see anything worse
> > than normal (given that safe-guard I mentioned above in the Varnish
> > layer).
> >
> > tl;dr:
> >
> > HHVM, an improved (faster) php server, is in the process of being tested
> > at scale and rolled out. We are still at the beginning stages but we
> > feel comfortable enough with the stability we've gained in the Beta
> > Cluster to open it up to more users through a Beta Feature. This Beta
> > Feature will be available for all users on Thursday afternoon (Pacific
> > timezone). Users who opt-in should have a faster wiki experience and in
> > the worst case will not see anything different than normal.
> >
> > I hope that helps. If you have any more questions please don't hesitate
> > to reply and cc wikitech-l, where the experts on the matter can answer
> > more questions.
> >
> > Best,
> >
> > Greg
>
> _______________________________________________
> Wikitech-ambassadors mailing list
> Wikitech-ambassadors(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
You should probably pair program more often. Here's why.
1) learning
Every single time I've pair programmed with someone, one of us has learned
stuff. About our tools, about a new way to look at a problem, about a
language feature, or something. Sometimes I've paired explicitly as a
teaching or learning technique, sometimes on more equal footing ("I'm the
domain expert for the problem but you're better at $framework than I am"),
or just to brainstorm or troubleshoot. At least one of us always comes out
smarter.
2) the tools are better than ever
https://lists.wikimedia.org/pipermail/teampractices/2014-July/thread.html
has some resources; don't dismiss pair programming just because you don't
live near other programmers.
3) pairing makes better code
"Pair Programming" by Laurie Williams (Ch. 17 in _Making Software: What
Really Works, and Why We Believe It_, ed. Andy Oram & Greg Wilson, O'Reilly
2011) reviews recent studies and finds that pair programming leads to
higher-quality code, and "reduced product risk due to improved knowledge
management". Some teams even tried pair programming as a replacement for
code review.
4) it's more egalitarian
As this list of status play behaviors points out
https://web.archive.org/web/20070216200742/http://greenlightwiki.com/improv…
, judging someone else's work -- even favorably! -- is a move that raises
your status and lowers theirs. This is one reason I have encouraged
EVERYONE who writes MediaWiki code to try their hand at code review, so
everyone can take turns -- everyone can be a teacher and critic.[0] If you
have found that code review feels adversarial or hierarchical, try
switching it up by asking to pair with a more experienced programmer,
getting your code review while you work together.
People who want to pair program more often on Wikimedia-related code: want
to use this thread to raise your hand? If people like the idea, we could
start doing something like http://www.pairprogramwith.me/ or
http://pear.growstuff.org/ to connect people up.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
[0] By the way, this great blog post
http://www.wordyard.com/2014/08/10/doing-is-knowing-sweet-jane-and-the-web/
makes a very strong point about how trying out an activity - like writing,
music, or coding - gives you more expertise, empathy, and ability to
define yourself, and to judge the work of other people who do that
activity. I would argue this applies to code review as well.
Hi, our metrics are reflecting a sudden growth of unreviewed changes in
Gerrit. Your attention and interpretations are welcome.
http://korma.wmflabs.org/browser/gerrit_review_queue.html
Look at the green line in the first graph, "Volume of open changesets". It
shows the number of open changesets waiting for a review (WIP and -1 are
excluded). In the last months, the number of changesets waiting for review
has gone from 311 (June) to 529 (July) and 790 (August).
The increase is so high that first I thought the problem was in the metric,
but Alvaro has reviewed the raw data and says that the metric is legit.
https://bugzilla.wikimedia.org/show_bug.cgi?id=70278
Trying to find an explanation, I went to the MediaWiki Core repository, and
there are some inusual curves there as well:
http://korma.wmflabs.org/browser/repository.html?repository=gerrit.wikimedi…
However, not even these numbers alone would explain the increase.
Has there been an unusual activity (or lack of reviews) in Gerrit or are we
missing an important detail in the metrics?
(pause)
In any case, in the past weeks I have been chasing old open reviews and in
general I get the impression that developers/maintainers are too busy to
review so many contributions. The tricky part is that many (most?) of those
contributions come from the same developers/maintainers...
Simplifying a lot the picture, it looks as if we can't review code because
we are busy writing code that won't be reviewed because we are busy writing
code that won't be reviewed because... I'm sure this representation is
unfair, but you get the point.
In many cases, unreviewed patches rotting mean real resources put into
waste -- right? Maybe teams should prioritize the attention to open
changesets at the expense of writing new code themselves? It's a real
question and I won't pretend to have an answer. Different teams and
repositories probably have different answers.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_15th>
A quick list of notable items...
== Monday ==
* Revert Wikidata to a known-good version due to issues that were found
on Thursday's deploy
* Update CentralNotice to remove dependency on jquery.json
** <https://gerrit.wikimedia.org/r/158103>
* Japanese Wikipedia to get Cirrus Search as the primary search
experience
== Tuesday ==
* Commons to will get the new CirrusSearch as the primary search engine
* MediaWiki deploy
** group1 to 1.24wmf21: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf21>
== Wednesday ==
* Russian Wikipedia to get Cirrus Search as the primary search
experience
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf21 (all Wikipedias)
** group0 to 1.24wmf22 (test/test2/testwikidata/mediawiki)
* There will be a method to opt-in to using the new HHVM-powered backend
for all WMF wikis. It'll be implemented via a BetaFeature to make it
as easy as possible for people to participate. There should be no
noticeable negative impact and hopefully only positive impacts.
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
FOSS Outreach Program for Women round 9 will be announced officially today
by the GNOME Foundation. Wikimedia will participate again, and our landing
page is located at
https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9
If you have a project proposal with two mentors and community consensus,
then you can add it under "Featured project ideas" here:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Featur…
Transclusion magic will do the rest.
On the other hand, if you proposed one of the projects featured in the
previous OPW and GSoC round and for some reason you don't want to push it
now, please remove it. You can either move it under the Raw section (if you
want to bring it back next year) or remove it completely from the page.
Questions? Just ask.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
I am forwarding this email to this list because I think this is a
place where I may be able to find somebody interested with the
required skills, sorry if this is not the case and/or this is not the
right place.
I would like to hear your fefedback (but please consider to use the
discussion page on meta for that).
Thanks,
Cristian
---------- Forwarded message ----------
From: Cristian Consonni <kikkocristian(a)gmail.com>
Date: 2014-09-12 11:41 GMT+02:00
Subject: OSMdata: a Wikidata-like editor for OpenStreetMap
To: OSM <talk(a)openstreetmap.org>
Hi all
The (long) discussion about importing Wikidata tags in OSM has
prompted this idea into my mind:
https://wiki.openstreetmap.org/wiki/OSMdata
I have also describe here in the IdeaLab on meta-wiki:
https://meta.wikimedia.org/wiki/Grants:IdeaLab/OSMdata:_a_Wikidata-like_edi…
Here's a quick summary:
== What ==
* using a MediaWiki + Wikibase - let's call it OSMdata[*] - install to
host an item about every single object in OSM (following this schema
Nxxx for nodes, Wxxx for ways, Rxxx for relations).
* claims in a OSMdata page about an item map exactly to key, values
pairs for the same object in OSM.
* OSMdata is synchronized and kept up-to-date with the OSM database (read)
* users can login in OSMdata with their OSM account and contribute,
adding new claims this are saved back automatically in the OSM
database (write)
== Rationale ==
* it seems awesome (!)
* the OSM community gains a new editor for OpenStreetMap, an editor which
use a well known interface and which can get all the benefits of
MediaWiki+Wikibase software development
* Wikibase is tested at 60x its current scale
* Wikibase is used in another big project
Let me stress again that I see OSMdata as being an editor, not a
repository for OSM, in fact I image in it to be a specialized editor
to be used for editing tags.
In my view the idea is to provide a well known interface to edit OSM
(both manually and automatically with bots, using the same bot
frameworks already available for editing Wikidata).
I have described this idea in the talk-it malling list (in Italian)
and a (at least conceptual) similarity has been pointed out towards
the textual editor Level0[2].
I would like to know your opinion, and I would also like to set up
some prototype with a small subset of the data. I tried to set up this
myself but, unfortunately, I am blocked on the first obstacle, i.e.:
how can I tell Wikibase to let me create items with names Nxxx, Wxxx
and Rxxx instead of Qxxx? I do not know enough PHP (nor MediaWiki or
Wikibase) to do this myself. Any help in this direction would be much
appreciated.
Ciao,
Cristian
[*] any reference to Wikidata is purely intentional
[1] https://lists.openstreetmap.org/pipermail/talk-it/2014-September/044540.html