Welcome Tyler! Great to have you on board.
On Mon, Feb 9, 2015 at 5:35 PM, Emily Blanchard <eblanchard(a)wikimedia.org>
wrote:
> Welcome Tyler!
>
>
>
>
>
>
> Emily Blanchard
> Talent Acquisition Team
> Wikimedia Foundation
> eblanchard@wikimedia. <eblanchard(a)gmail.com>org
> Follow us on Twitter @wikimediaatwork
> http://wikimediafoundation.org/wiki/Home
> Become a Contributor: https://en.wikipedia.org/wiki/Wikipedia:Teahouse
> Join Us: http://wikimediafoundation.org/wiki/Work_with_us
> Developers Join the Fun: http://www.mediawiki.org/wiki/Communication
>
>
> *Imagine a world in which every single human being can freely share inthe
> sum of all knowledge. Help us make it a reality!*
>
> On Mon, Feb 9, 2015 at 1:39 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote:
>
>> Welcome, Tyler! I'm looking forward to working together.
>>
>> On Mon, Feb 9, 2015 at 1:28 PM, Greg Grossmeier <greg(a)wikimedia.org>
>> wrote:
>>
>>> Hello all,
>>>
>>> I’m delighted to announce that Tyler Cipriani[0] is joining the
>>> foundation as a Release Engineer (obviously joining the Release
>>> Engineering team).
>>>
>>> Tyler lives (and will continue to work remotely from) where you can see
>>> the Flatirons[1] in Colorado and comes to us from SparkFun[2] where he
>>> was a web developer and sysadmin.
>>>
>>> Along with the Wikimedia Foundation being a great fit professionally for
>>> Tyler (I’m biased maybe) he is also “thrilled to be working at an
>>> organization whose values seemingly so closely align with [his] own.”
>>>
>>> He’ll be at the San Francisco office the week of the 16th and is seeking
>>> any suggestions as to what he should do with his free afternoon on
>>> Presidents’ Day.
>>>
>>> Please join me in welcoming Tyler!
>>>
>>> Greg
>>>
>>>
>>> [0] https://tylercipriani.com/
>>> [1] https://en.wikipedia.org/wiki/Flatirons
>>> [2] https://www.sparkfun.com/
>>>
>>> --
>>> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
>>> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>>>
>>> _______________________________________________
>>> Engineering mailing list
>>> Engineering(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>>
>>>
>>
>>
>> --
>> Dan Duvall
>> Automation Engineer
>> Wikimedia Foundation <http://wikimediafoundation.org>
>>
>> _______________________________________________
>> Engineering mailing list
>> Engineering(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
Hello all,
I’m delighted to announce that Tyler Cipriani[0] is joining the
foundation as a Release Engineer (obviously joining the Release
Engineering team).
Tyler lives (and will continue to work remotely from) where you can see
the Flatirons[1] in Colorado and comes to us from SparkFun[2] where he
was a web developer and sysadmin.
Along with the Wikimedia Foundation being a great fit professionally for
Tyler (I’m biased maybe) he is also “thrilled to be working at an
organization whose values seemingly so closely align with [his] own.”
He’ll be at the San Francisco office the week of the 16th and is seeking
any suggestions as to what he should do with his free afternoon on
Presidents’ Day.
Please join me in welcoming Tyler!
Greg
[0] https://tylercipriani.com/
[1] https://en.wikipedia.org/wiki/Flatirons
[2] https://www.sparkfun.com/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi folks,
MediaWiki emits the hreflang attribute on language links, but only as part
of the links in the body, and not in the <head> as recommended by Google
[1]. The result of this is that Google (and possibly other search engines)
doesn't interpret the hreflang attribute for purposes of prioritizing
search results in the user's own language.
>From a contact at Google we asked about this: "we currently don't use those
annotations on the links, we need to see the hreflang link-elements in the
head in order to understand that connection. The important parts there are
the we need to have them in the "head", we need to have them confirmed from
the other versions (so DE needs to refer to EN, and EN to DE -- it can't be
one-sided), and it needs to be between the canonical URLs. (...) I imagine
if you just added the cross-links as you have them in the sidebar as
link-elements to the head then you'd be covered."
This of course would add some additional payload to pages with lots of
language links, but could help avoid results like [2] where the English
language version of an article is #1 and the Indonesian one makes no
appearance at all. Results vary greatly and it's hard to say how big a
problem this is, but even if boosts discoverability of content in the
user's language by only 10% or so, that would still be a pretty big win for
local content.
I'm curious if folks see any downside, other than the additional page
payload, in adding this information to the page header. Given the time it
takes for the index to be updated, we should be careful about any potential
negative consequences.
Thanks,
Erik
[1] https://support.google.com/webmasters/answer/189077?hl=en
[2] https://www.google.co.id/?gws_rd=ssl#q=edison
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
Hi!
As some of you may have noticed, I am currently promoting the
clarification of several extensions' licenses.
Specifically, every MediaWiki extension should register itself with one
of the SPDX-compliant license codes <http://spdx.org/licenses/> and
include a valid FOSS license as a file whose name matches the pattern
"^((COPYING)|(LICENSE))(\.txt)?$".
As part of this process, Gerrit change 187178
<https://gerrit.wikimedia.org/r/187178/> was merged causing license
files to be shown in raw format, and a request for bot flagging
<https://www.mediawiki.org/wiki/Project:Requests/User_rights/SamoaBot>
was filed to speed up the conversion of extension pages.
Then, more than 80 patches were filed against extension repos (mostly
with "license-name" as topic) and merged with help from maintainers.
This first batch of updates is almost complete, so I'd like to thank
Kunal Mehta, Siebrand Mazeland, Luis Felipe Schenone, Santhosh
Thottingal, Thiemo Mättig, Marius Hoch, Tony Thomas, Peter Coombe,
Antoine Musso, Max Semenik, Umherirrender, PleaseStand, He7d3r, Niklas
Laxström, Federico Leva, Bartosz Dziewoński, Gilles Dubuc, Thomas
Pellissier Tanon, Jon Robson, Florian Schmidt, Brad Jorsch and Timo
Tijhof (in no particular order) for their valuable support.
However, several repositories are still lacking license information
completely, or have inaccurate notices. I'd suggest to create a
Phabricator project/tracking task to manage licensing issues across the
codebase.
Damn, forwarding to wikitech-l, forget to click the answer all button :(
Von: Florian Schmidt [mailto:florian.schmidt.welzow@t-online.de]
Gesendet: Samstag, 7. Februar 2015 13:29
An: 'Thomas Mulhall'
Betreff: AW: AW: [Wikitech-l] jenkings merging
Ah, ok. Maybe a little bit background for this:
Git is a decentral version manageing tool (basically). Gerrit allows you to review changes before you commit it into your git repository. Now an example:
Developer A push a change for review to gerrit (based on the actual master).
Developer B push a change for review to gerrit, too (again based on actual master branch).
Say, Developer C reviews change from Developer B and +2 it (or set +2, Verified and submit the change). Jenkins will run gate and submit jobs and will trigger gerrit to merge the commit into the git repository. The change will, because it is directly based on master, just be merged and master fast forwarded to the new commit.
| master
| change from developer B
| old master
Now, Developer C reviews the change of Developer A and +2 it, too. Now we have a problem. The change based on an older version of the master branch, maybe this graphic helps you to understand it:
| master
| change from developer B
| | change from developer A
|/
| old master
So, the change from developer A (which is, in fact, a new branch in git) has to be merged into the actual master. In general, gerrit can do this alone (if there are no merge conflicts) which will result in the following history:
| new master
|\ “Merge change from developer B”
| | old master
| | change from developer B
| | change from developer A
|/
| old, old master
So, merging is only needed, if you submit a change, which is based on an older master. This will be, if you submit a change, which wasn’t rebased to the actual master and there were other changes submitted before it. In general, this will be in projects with more than one developer (because more developers: more commits and more submitted changes), or if you’re upload a change for review, working on other changes and submit them, and review your first change after it without rebasing. If you have a look at your project: all changes are based on the actual master and submitted without any other change submitted before it, so you have a nice linear git history :D
If a merge is needed sometimes, gerrit will do it without any new setup/configuration.
Hope that helps and excuse some little faults I maybe made somewhere in this mail :)
Kind regards,
Florian
Von: Thomas Mulhall [mailto:thomasmulhall410@yahoo.com]
Gesendet: Samstag, 7. Februar 2015 13:02
An: Florian Schmidt; 'Wikimedia developers'
Betreff: Re: AW: [Wikitech-l] jenkings merging
Like this <https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FCentralAuth/13e92…> https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FCentralAuth/13e92…
On Saturday, 7 February 2015, 12:01, Thomas Mulhall < <mailto:thomasmulhall410@yahoo.com> thomasmulhall410(a)yahoo.com> wrote:
Jenking does it as a commit of its own.
On Saturday, 7 February 2015, 12:01, Thomas Mulhall < <mailto:thomasmulhall410@yahoo.com> thomasmulhall410(a)yahoo.com> wrote:
Hi what I mean is on centralauth jenking says merged this branch. I would like to do that too please.
On Saturday, 7 February 2015, 11:53, Florian Schmidt < <mailto:florian.schmidt.welzow@t-online.de> florian.schmidt.welzow(a)t-online.de> wrote:
Hi Thomas,
what do you want to do? If you upload a new patchset to a change (or a new change), Jenkins will automatically merge this change with the master branch and runs tests against the resulting artifact :) That's what I know.
Kind regards
Florian
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org <mailto:wikitech-l-bounces@lists.wikimedia.org> [mailto:wikitech-l-bounces@lists.wikimedia.org <mailto:wikitech-l-bounces@lists.wikimedia.org> ] Im Auftrag von Thomas Mulhall
Gesendet: Samstag, 7. Februar 2015 01:56
An: Wikimedia developers
Betreff: [Wikitech-l] jenkings merging
Hi how do I get my skins and extensions to be merged automatically by jenkings like it does on centralauth projects are at https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook <https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook> and https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector <https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector>
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Feb 5, 2015 at 7:50 PM, MZMcBride <z(a)mzmcbride.com> wrote:
> Perhaps if Titan/Wikidata Query Service development is on hold, Nik could
> investigate this?
Not really on hold - just looking at alternatives to Titan. But this
is a pretty critical issue for all our dev workflows, so really would
appreciate help from our search gurus in resolving it.
Erik
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation
Hi everyone,
I've come up with a rough OOjs-UI-based rewrite of the long-standing
Reference Tooltips <https://www.mediawiki.org/wiki/Reference_Tooltips>
gadget.
I'd like to see it enabled on Wikimedia sites as a beta feature, to
ultimately replace the gadget, but I'm not sure it is worth an extension
on its own.
It could share some code with the Popups extension
<https://www.mediawiki.org/wiki/Extension:Popups> but, unlike the
latter, the former does not depend on neither TextExtracts nor PageImages.
The Cite extension <https://www.mediawiki.org/wiki/Extension:Cite> is
required for references to work, so the tooltips could just be an
additional feature. However, I don't feel comfortable with embedding
such an experiment into a cornerstone of ours like Cite.
VectorBeta <https://www.mediawiki.org/wiki/Extension:VectorBeta>
includes many features of this kind, but reference tooltips are really
not Vector-specific.
Which do you think is the most suitable repository?