Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Giuseppe Lavagetto]

On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac  wrote:
> On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling 
> wrote:
>
>> I don't really understand why you want it to be integrated with
>> RESTBase. As far as I can tell (it is hard to pin these things down),
>> RESTBase is a revision storage backend and possibly a public API for
>> that backend.
>
>
> Actually, RESTBase's logic applies to the Mobile Apps case quite naturally.
> When a page is fetched and transformed, it can be stored so that consequent
> requests can simply retrieve the transformed document form storage.
>
>

Ok, so in this vision RESTBase is a caching layer for revisions

>> I thought the idea of SOA was to separate concerns.
>> Wouldn't monitoring, caching and authorization would be best done as a
>> node.js library which RESTBase and other services use?
>>
>
> Good point. Ideally, what we would need to do is provide the right tools to
> developers to create services, which can then be placed "strategically"
> around DCs (in cooperation with Ops, ofc). For v1, however, we plan to
> provide only logical separation (to a certain extent) via modules which can
> be dynamically loaded/unloaded from RESTBase. In return, RESTBase will
> provide them with routing, monitoring, caching and authorisation out of the
> box. The good point here is that this 'modularisation' eases the transition
> to a more-decomposed orchestration SOA model. Going in that direction,
> however, requires some prerequisites to be fulfilled, such as [1].
>

So, now RESTBase has become a router and an auth provider as well?
(Gabriel already clarified me that "monitoring" means that RESTbase
will expose its own metrics for that specific service, so this is not
monitoring of the service at all, rather accounting).

I need some clarification at this point - what is RESTBase really
going to do? I'm asking because when I read "RESTBase will provide
them with routing, [...] and authorisation" I immediately think of a
request router and a general on-wiki auth provider. And we already
have both, and re-doing them in RESTBase would be plainly wrong.

Maybe you intend very specific things when you say "routing" and not
request routing, which is what everybody here will think of.
And when you say "auth" you mean that RESTBase implements an auth
schema for its clients, so that no client can access data from another
one. If this is the case, I have some further questions: is this going
to be RBAC? Which permissions models are you implementing? Are we sure
it is what we will need? And foremost: will this be exposable to
external consumers? will it be able to hook up to our traditional wiki
auth scheme?

Can you please expand a bit on those concepts? Or a lot of confusion,
uncertainty and doubt will spread amongst your fellow engineers,
resulting in an hostile view of what may be a perfectly well designed
software.

Cheers,

Giuseppe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Giuseppe Lavagetto]

On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac  wrote:
> On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling 
> wrote:
>
>> I don't really understand why you want it to be integrated with
>> RESTBase. As far as I can tell (it is hard to pin these things down),
>> RESTBase is a revision storage backend and possibly a public API for
>> that backend.
>
>
> Actually, RESTBase's logic applies to the Mobile Apps case quite naturally.
> When a page is fetched and transformed, it can be stored so that consequent
> requests can simply retrieve the transformed document form storage.
>
>

Ok, so in this vision RESTBase is a caching layer for revisions

>> I thought the idea of SOA was to separate concerns.
>> Wouldn't monitoring, caching and authorization would be best done as a
>> node.js library which RESTBase and other services use?
>>
>
> Good point. Ideally, what we would need to do is provide the right tools to
> developers to create services, which can then be placed "strategically"
> around DCs (in cooperation with Ops, ofc). For v1, however, we plan to
> provide only logical separation (to a certain extent) via modules which can
> be dynamically loaded/unloaded from RESTBase. In return, RESTBase will
> provide them with routing, monitoring, caching and authorisation out of the
> box. The good point here is that this 'modularisation' eases the transition
> to a more-decomposed orchestration SOA model. Going in that direction,
> however, requires some prerequisites to be fulfilled, such as [1].
>

So, now RESTBase has become a router and an auth provider as well?
(Gabriel already clarified me that "monitoring" means that RESTbase
will expose its own metrics for that specific service, so this is not
monitoring of the service at all, rather accounting).

I need some clarification at this point - what is RESTBase really
going to do? I'm asking because when I read "RESTBase will provide
them with routing, [...] and authorisation" I immediately think of a
request router and a general on-wiki auth provider. And we already
have both, and re-doing them in RESTBase would be plainly wrong.

Maybe you intend very specific things when you say "routing" and not
request routing, which is what everybody here will think of.
And when you say "auth" you mean that RESTBase implements an auth
schema for its clients, so that no client can access data from another
one. If this is the case, I have some further questions: is this going
to be RBAC? Which permissions models are you implementing? Are we sure
it is what we will need? And foremost: will this be exposable to
external consumers? will it be able to hook up to our traditional wiki
auth scheme?

Can you please expand a bit on those concepts? Or a lot of confusion,
uncertainty and doubt will spread amongst your fellow engineers,
resulting in an hostile view of what may be a perfectly well designed
software.

Cheers,

Giuseppe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives

[Tilman Bayer]

Minutes and slides from four recent meetings have appeared under the
following URLs:

Analytics team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Analytics/January_2015

Parsoid and Services teams:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Services/January_2015

Mobile Web and Apps teams:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Mobile/January_2015

Product Process Improvements (update meeting):
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Product/January_2015

On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller  wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> ___
> Wikimedia-l mailing list
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l



-- 
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Global user pages deployed to test wikis

[Legoktm]

Hello!

Earlier today the GlobalUserPage extension was deployed to
test.wikipedia.org, test2.wikipedia.org, and test.wikidata.org.
GlobalUserPage "transcludes" the contents of your userpage on other
public Wikimedia wikis if a local user page does not exist.

For example, my userpage on test.wikidata.org[1] is displaying the
content from test.wikipedia.org[2]. During the test phase,
test.wikipedia.org is the central wiki. When we deploy the extension to
all wikis, Meta will become the central wiki (and existing global user
pages on test.wikipedia.org will not be migrated).

Documentation about the various features can be found on
mediawiki.org[3]. Please test the extension and if you find any bugs or
issues, they can be reported in Phabricator[4]. You can also subscribe
to [5] to track the full deployment of GlobalUserPage.

[1] https://test.wikidata.org/wiki/User:Legoktm
[2] https://test.wikipedia.org/wiki/User:Legoktm
[3] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage
[4]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ-j536clyie42uptgjkft7
[5] https://phabricator.wikimedia.org/T72576

Thanks,
-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Bryan Davis]

On Thu, Feb 5, 2015 at 9:00 PM, Yuri Astrakhan  wrote:
> Lastly, semi related - my service will also need a node.js lib to access MW
> api. How should we manage common libs like that?

Libraries published on npm using semantic versioning and imported to
the individual services as needed.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator search

[Bryan Davis]

On Thu, Feb 5, 2015 at 8:50 PM, MZMcBride  wrote:
> Hi.
>
> Phabricator search is currently pretty bad:
> .
>
> We should already be wary of putting all our eggs in the Phabricator
> basket. Search is hugely important to an issue tracker and code
> repository, so if we're going to continue growing Phabricator, we need to
> figure out short-term and long-term solutions for Phabricator search.
>
> Perhaps if Titan/Wikidata Query Service development is on hold, Nik could
> investigate this? Or perhaps dropping Elasticsearch for now in favor of
> the built-in search would be better? Thoughts, suggestions, etc. welcome.

^d was looking into this a bit today based on some reports that came
in on irc. He's been working actively with the upstream to make their
Elasticsearch integration better already and is now assigned to the
Release Engineering team that helped bootstrap the Phabricator install
so I'd expect he will continue to be interested in improvements.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New "Reference Tooltips" beta feature

[Prateek Saxena]

On Tue, Feb 3, 2015 at 7:05 PM, Ricordisamoa
 wrote:
> How do you think a Popups renderer would integrate with OOjs UI?

I haven't thought about this yet. Currently Popups doesn't use any UI
elements (like buttons or inputs) so I didn't feel the need to use a
framework. We might want to use an OOjs UI Dialog but I don't have
enough experience with the framework to tell if it'll work under all
of Popup's positioning and sizing constraints. I am guessing it'll be
a pretty major shift to use both OOjs and OOjs UI, not something that
I'll have the time to do until March.



On Tue, Feb 3, 2015 at 7:05 PM, Ricordisamoa
 wrote:
> Why shouldn't ReferenceTooltips be put into Cite?

I am not sure. As James said, there is already something like this in
Cite but it wasn't enabled. I am not sure why that is. Nick or James
would know better.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator search

[Erik Moeller]

On Thu, Feb 5, 2015 at 7:50 PM, MZMcBride  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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Yuri Astrakhan]

Tim, I like Varnish's vcl flexibility, but not the debugging aspects.
Still, +1, but could you elaborate on how you see:

* Services communicate with each other - via varnish as well or directly?
* Do you see routing varnish layer as non-caching, only to forward request
to the second tear service-specific varnish instance that will actually
perform caching?
* Will there be any problems separating services into separate, non
mutually trusted clusters?
* service management - varnish would only indicate overall health of the
service. What about service-specific real time monitored values (if
needed), logs, controlling service instances. Any thoughts on generalizing
that infrastructure?

Lastly, semi related - my service will also need a node.js lib to access MW
api. How should we manage common libs like that?

Thanks!
On Feb 6, 2015 4:15 AM, "Tim Starling"  wrote:

> On 04/02/15 16:59, Marko Obrovac wrote:
> > For v1, however, we plan to
> > provide only logical separation (to a certain extent) via modules which
> can
> > be dynamically loaded/unloaded from RESTBase. In return, RESTBase will
> > provide them with routing, monitoring, caching and authorisation out of
> the
> > box.
>
> We already have routing, monitoring and caching in Varnish. That seems
> like a good place to implement further service routing to me.
>
> <
> https://git.wikimedia.org/blob/operations%2Fpuppet/4a7f5ce62d9cdd1ace20ca6c489cbdb538503750/templates%2Fvarnish%2Fmisc.inc.vcl.erb
> >
>
> It's simple to configure, has excellent performance and scalability,
> and monitoring and a distributed logging system are already implemented.
>
> It doesn't have authorisation, but I thought that was going to be in a
> separate service from RESTBase anyway.
>
> -- Tim Starling
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Phabricator search

[MZMcBride]

Hi.

Phabricator search is currently pretty bad:
.

We should already be wary of putting all our eggs in the Phabricator
basket. Search is hugely important to an issue tracker and code
repository, so if we're going to continue growing Phabricator, we need to
figure out short-term and long-term solutions for Phabricator search.

Perhaps if Titan/Wikidata Query Service development is on hold, Nik could
investigate this? Or perhaps dropping Elasticsearch for now in favor of
the built-in search would be better? Thoughts, suggestions, etc. welcome.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Tim Starling]

On 04/02/15 16:59, Marko Obrovac wrote:
> For v1, however, we plan to
> provide only logical separation (to a certain extent) via modules which can
> be dynamically loaded/unloaded from RESTBase. In return, RESTBase will
> provide them with routing, monitoring, caching and authorisation out of the
> box.

We already have routing, monitoring and caching in Varnish. That seems
like a good place to implement further service routing to me.



It's simple to configure, has excellent performance and scalability,
and monitoring and a distributed logging system are already implemented.

It doesn't have authorisation, but I thought that was going to be in a
separate service from RESTBase anyway.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[Brad Jorsch (Anomie)]

On Thu, Feb 5, 2015 at 6:53 PM, James Forrester 
wrote:

> I know for one ​that they're frequently used for analytical purposes to
> track behaviour and performance. The AF ones aren't, but AbuseFilter's use
> of tags is (numerically) niche.


I don't know that I'd call 3410388 out of 9051234 (37.68%) on enwiki
"numerically niche". And if we exclude the 2330952 HHVM tags from the
total, it's up to 50.57%. Other wikis, perhaps, have less AF use and more
VE.

But as long as whatever "analytical purpose" that added the tag continues
to respond to the ListDefinedTags hook, the tag can't be deleted by this
mechanism unless it's explicitly allowed by the ChangeTagCanDelete hook. So
excessive concern over those being deleted seems like it's just that,
excessive.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[Brad Jorsch (Anomie)]

On Thu, Feb 5, 2015 at 9:04 PM, Jackmcbarn  wrote:

> Well, technically the revision goes away, but the log entries contain
> enough information to determine exactly what was in it, sufficient to
> reconstruct it.
>

It'll tell you where it redirected to, but not whatever additional content
(if any) was on the page besides the redirect.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[Brad Jorsch (Anomie)]

On Thu, Feb 5, 2015 at 6:43 PM, This, that and the other <
at.li...@live.com.au> wrote:

> The exception to this is OAuth, which should really be fixed not to allow
> its tags to be deleted.
>

https://gerrit.wikimedia.org/r/#/c/187624/


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[Jackmcbarn]

On Thu, Feb 5, 2015 at 5:17 PM, Brad Jorsch (Anomie) 
wrote:

> Note the deletions aren't intended to be "irrevocable". Once phase 2 of
> this project is done someone could go through and re-add the tag to each
> thing it was removed from. Kind of like with Special:Nuke, someone could go
> through and undelete everything that was deleted.
>
> The one roadblock there is that it doesn't currently log every item that
> the tag got deleted from. Besides log flooding, though, there's no reason
> it *couldn't* do that.
>
If we could find a way to do this without a log flooding problem, I'd be
fine with deleting tags.

move-over-redirect is an irrevocable deletion ;)
>
Well, technically the revision goes away, but the log entries contain
enough information to determine exactly what was in it, sufficient to
reconstruct it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] All Hands On Deck!

[Pine W]

Hi Littlewmfbird,

Come perch on my branches, says this tree,
And tell me more about what thinketh thee.
Come, let us evaluate together
About how Wikimedia might do better.

Little bird, as you perch on my branches,
Tell me this.
As you survey the broad blue sky, I ask,
Think aloud, daydream with me for a minute:

How might Wikimedia transform
from what you criticized in your verses
Into the community that we
(at least you and I, and I suspect many more)
feel it should be?

This is not idle wishfullness;
I am quite serious.
Like you, I can throw stones too
But I ask myself,
If I want Wikimedia to be better
Then how can we help to make it so?
And that question, little bird, I hope you will ponder, lo.

You see, trees like me
We weather many storms.
We could give up and disappear,
As you can too.
But what, then, of the Wikimedia we love?
And what of us? Are we better if we leave?

I suppose we must all leave someday,
our edits and patches left for future generations,
our great unfinished symphony to be continued by others.

But little bird, it sounds like you intend to stay, at least for a little
bit,
Since you did not ragequit.

So while you are here, little bird, Let us talk.
Give this thought:
how can we become better than we are?

I am listening, as are others.

(If I am slow to respond, it is because I am pondering.)

Regards,

Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*

On Fri, Jan 23, 2015 at 9:11 AM,  wrote:

> Oh what a day! Which began when perforce
> a visitor from afar began to exhort
> us to look far afield, to travel and visit
> learn brand new things, uncover, elicit
> stories of users far from our homes!
> And so we set out, bravely to roam:
> perhaps ten full blocks! We found creatures strange!
> They all spoke English! The stories exchanged
> recalled those of family: Mom, Dad, and friends --
> it's true, then, we _are_ all the same in the end!
>
> Such relief not to grapple
> with projects baroque,
> languages strange, or
> features "they" wrote.
> In tune with this sentiment
> let's celebrate dominance!
> Hush the less pertinent --
> let's not mention "those" continents.
>
> "Hurray," we all cheer: "Our wiki is strong!"
> Our projects are weak, but shush, sing along:
> our rivals are fierce, but yet we prevailed;
> it must be because our PHP scaled!
> Ignore those naysayers who laugh at our UX
> And claims by our editors that it obstructs:
> separate pages for talk, no friends and no chat --
> no Serious Software has all of that!
>
> Well, enough -- we're not free
> to change even fonts
> without acres of missives
> to agony aunts:
> let's move next to strategy,
> where with speeches prolonged
> new hires will tell us
> what we got wrong.
>
> Three commands we were given:
> the first, to be punctual.
> By fiat we've banished
> the correct but eventual;
> from now on our code
> is timely _and_ functional.
> Our prior disasters are
> vanished by ritual.
>
> The second was novel:
> exhorted to innovate!
> Our change-fearing userbase
> I'm sure will reciprocate.
> Perhaps we can grow
> new crops of good editors.
> New users, new processes,
> throw off our fetters.
> Perhaps we need spaces
> where we can be bold --
> it's hard else to see
> how to do what we're told.
>
> The last was to integrate,
> engage with community;
> never mind our tall silos
> and product disunity:
> we can have orphaned features
> conflicted teams, clashing visions --
> "What's key is to synergize!"
> says our stratcom tactician.
> Community discourse
> will fix all that ails us:
> except for those times
> when instead they've assailed us.
>
> Lift a glass to the mission!
> We'll muddle through fine.
> We all love each other,
> but this day's been a grind.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Naming conventions for data centers

[Nkansah Rexford]

"... followed by closest major airport."

I guess that's supposed to give quick idea where the DC is located?
On Feb 6, 2015 12:54 AM, "Legoktm"  wrote:

> On 02/05/2015 04:51 PM, Pine W wrote:
> > What is the naming convention for these data centers?
>
> <
> https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Datacenter_Sites
> >
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Naming conventions for data centers

[Pine W]

That makes sense, although it would be nice if the names were pronouncable
("PMTPA"?). It would be nice to rethink this sometime.

Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*

On Thu, Feb 5, 2015 at 4:54 PM, Legoktm  wrote:

> On 02/05/2015 04:51 PM, Pine W wrote:
> > What is the naming convention for these data centers?
>
> <
> https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Datacenter_Sites
> >
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Naming conventions for data centers

[Legoktm]

On 02/05/2015 04:51 PM, Pine W wrote:
> What is the naming convention for these data centers?



-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Naming conventions for data centers

[Pine W]

What is the naming convention for these data centers? I think it might be
interesting to name them for people who have contributed significantly to
Wikimedia or MediaWiki in one way or another, such as Pacha (
https://blog.wikimedia.org/2014/05/12/the-story-of-jim-pacha/), Wadewitz (
https://en.wikipedia.org/wiki/Adrianne_Wadewitz), and Manske (
https://en.wikipedia.org/wiki/Magnus_Manske).

Just a thought.

Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Pine W]

I see, thanks.


Pine

*This is an Encyclopedia* 






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*

On Thu, Feb 5, 2015 at 4:42 PM, Greg Grossmeier  wrote:

> 
> > Interesting. I thought that WMF had full redundancy among at least two
> > physical sites for tech infrastructure, in case any location went
> > completely offline, such as if there is a fire or flood. Is this not the
> > case, and if so, is full redundancy capability planned?
>
> We only have one primary datacenter right now ("EQIAD" in Ashburn, VA),
> the others ("ULSFO" in SF, "ESAMS" in Amsterdam) are just cache centers.
>
> There is a new datacenter coming online which will be a full fledged DC
> along with EQIAD, this one is called CODFW (in Dallas, TX). That DC is
> not yet operational (machines are still being installed/etc) and after
> it is there will still be work to make MediaWiki the software fully
> multidatacenter aware.
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Greg Grossmeier]

> Interesting. I thought that WMF had full redundancy among at least two
> physical sites for tech infrastructure, in case any location went
> completely offline, such as if there is a fire or flood. Is this not the
> case, and if so, is full redundancy capability planned?

We only have one primary datacenter right now ("EQIAD" in Ashburn, VA),
the others ("ULSFO" in SF, "ESAMS" in Amsterdam) are just cache centers.

There is a new datacenter coming online which will be a full fledged DC
along with EQIAD, this one is called CODFW (in Dallas, TX). That DC is
not yet operational (machines are still being installed/etc) and after
it is there will still be work to make MediaWiki the software fully
multidatacenter aware.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Pine W]

Interesting. I thought that WMF had full redundancy among at least two
physical sites for tech infrastructure, in case any location went
completely offline, such as if there is a fire or flood. Is this not the
case, and if so, is full redundancy capability planned?

Pine

*This is an Encyclopedia* <https://www.wikipedia.org/>






*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*

*—Catherine Munro*

On Thu, Feb 5, 2015 at 12:23 PM, Andre Klapper 
wrote:

> On Thu, 2015-02-05 at 09:58 -0800, George Herbert wrote:
> > Any news on root cause?
>
> All work in progress: Documentation is linked from the desc in
> https://phabricator.wikimedia.org/tag/incident-20150205-siteoutage/
> and that project also lists potential followup actions as tasks.
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[James Forrester]

On 5 February 2015 at 15:43, This, that and the other 
wrote:

> I would suggest that the potential "danger" of such a right is mitigated
> by the following:
>
> * It is not possible to delete change tags defined by an extension unless
> the extension specifically allows it (which none currently do). That means
> that active AbuseFilter tags, tags like `visualeditor`, etc. cannot be
> deleted. The exception to this is OAuth, which should really be fixed not
> to allow its tags to be deleted.
>

​Fair.​



> * The feature is currently limited to deleting tags used by <= 5,000
> revisions. (This may change in the future.)


> On enwiki, this would allow old, inactive AbuseFilter tags to be cleaned
> up (like "michael jackson"). These tags are in most cases applied to old
> revisions, and seeing as the intention of tags is to help patrolling of
> recent edits,


​{{cn}}

I know for one ​that they're frequently used for analytical purposes to
track behaviour and performance. The AF ones aren't, but AbuseFilter's use
of tags is (numerically) niche. Maybe we should first have a conversation
about what we want tags to be, before rushing around making potentially
regrettable changes?

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[This, that and the other]

I would suggest that the potential "danger" of such a right is mitigated by 
the following:


* It is not possible to delete change tags defined by an extension unless 
the extension specifically allows it (which none currently do). That means 
that active AbuseFilter tags, tags like `visualeditor`, etc. cannot be 
deleted. The exception to this is OAuth, which should really be fixed not to 
allow its tags to be deleted.


* The feature is currently limited to deleting tags used by <= 5,000 
revisions. (This may change in the future.)


On enwiki, this would allow old, inactive AbuseFilter tags to be cleaned up 
(like "michael jackson"). These tags are in most cases applied to old 
revisions, and seeing as the intention of tags is to help patrolling of 
recent edits, I don't think this is a big enough deal to require logging 
every single revision to which the tag was (in many cases, probably 
erroneously) applied.


TTO

"Jackmcbarn"  wrote in message 
news:CAOx5P=+gAkH_-k3uUAFF4fCTy16BQH9ibihV57t56x=h4QB=b...@mail.gmail.com...


Gerrit change 181958[1] was recently merged, which allows (among other
things) the ability for sysops to irrecoverably delete change tags. Since
irrecoverable deletion of anything from on-wiki is rather unprecedented, I
think we should stop granting it to all sysops in DefaultSettings.php, so
that wikis have to "opt-in" for this feature to be enabled. Thoughts?

[1]https://gerrit.wikimedia.org/r/#/c/181958/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l 




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[Brad Jorsch (Anomie)]

Note the deletions aren't intended to be "irrevocable". Once phase 2 of
this project is done someone could go through and re-add the tag to each
thing it was removed from. Kind of like with Special:Nuke, someone could go
through and undelete everything that was deleted.

The one roadblock there is that it doesn't currently log every item that
the tag got deleted from. Besides log flooding, though, there's no reason
it *couldn't* do that.


On Thu, Feb 5, 2015 at 4:41 PM, James Forrester 
wrote:

> ​I would go further and suggest that this right is not granted on WMF
> wikis.


I don't think people would be all that happy if T20670 were closed as "we
fixed this, but you can't use it on WMF wikis". Let's fix things rather
than jump to non-solution solutions.


> We deliberately don't let anyone do irrevocable deletions.


move-over-redirect is an irrevocable deletion ;)


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation

On Thu, Feb 5, 2015 at 4:41 PM, James Forrester 
wrote:

> On 5 February 2015 at 13:13, Jackmcbarn  wrote:
>
> > Gerrit change 181958[1] was recently merged, which allows (among other
> > things) the ability for sysops to irrecoverably delete change tags. Since
> > irrecoverable deletion of anything from on-wiki is rather unprecedented,
> I
> > think we should stop granting it to all sysops in DefaultSettings.php, so
> > that wikis have to "opt-in" for this feature to be enabled. Thoughts?
> >
> > [1]https://gerrit.wikimedia.org/r/#/c/181958/
>
>
> ​I would go further and suggest that this right is not granted on WMF
> wikis. We deliberately don't let anyone do irrevocable deletions. This
> isn't MW 1.4 any more. :-)
>
> J.
> --
> James D. Forrester
> Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Permanently deleting change tags available by default

[James Forrester]

On 5 February 2015 at 13:13, Jackmcbarn  wrote:

> Gerrit change 181958[1] was recently merged, which allows (among other
> things) the ability for sysops to irrecoverably delete change tags. Since
> irrecoverable deletion of anything from on-wiki is rather unprecedented, I
> think we should stop granting it to all sysops in DefaultSettings.php, so
> that wikis have to "opt-in" for this feature to be enabled. Thoughts?
>
> [1]https://gerrit.wikimedia.org/r/#/c/181958/


​I would go further and suggest that this right is not granted on WMF
wikis. We deliberately don't let anyone do irrevocable deletions. This
isn't MW 1.4 any more. :-)

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Permanently deleting change tags available by default

[Jackmcbarn]

Gerrit change 181958[1] was recently merged, which allows (among other
things) the ability for sysops to irrecoverably delete change tags. Since
irrecoverable deletion of anything from on-wiki is rather unprecedented, I
think we should stop granting it to all sysops in DefaultSettings.php, so
that wikis have to "opt-in" for this feature to be enabled. Thoughts?

[1]https://gerrit.wikimedia.org/r/#/c/181958/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Mark Bergsma]

The incident report is now posted on wikitech:

https://wikitech.wikimedia.org/wiki/Incident_documentation/20150205-SiteOutage

On Thu, Feb 5, 2015 at 7:57 PM, Mark Bergsma  wrote:

> Hi all,
>
> We've indeed had a total site outage for roughly 30 minutes. We're still
> collecting all data, but we've tracked down the cause to multiple cascading
> issues including loss of power to a critical SPOF network switch and HHVM
> MediaWiki application servers getting blocked due to multiple unoptimal
> timeout settings. We'll post a full incident report soon, and work to
> correct the underlying issues as soon as possible.
>
> Our apologies,
>
> On Thu, Feb 5, 2015 at 7:03 PM, Guillaume Paumier 
> wrote:
>
>> Hi,
>>
>> Le jeudi 5 février 2015, 09:58:01 George Herbert a écrit :
>> > I saw a WMF tweet of a site outage (network?) around 9:30am Pacific
>> time, by
>> > the time I could check now things seem ok on en
>>
>> Sites are mostly back up but there are still issues with login, so the Ops
>> team hasn't had time to write a postmortem yet.
>>
>> --
>> Guillaume Paumier
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Mark Bergsma 
> Lead Operations Architect
> Director of Technical Operations
> Wikimedia Foundation
>



-- 
Mark Bergsma 
Lead Operations Architect
Director of Technical Operations
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Andre Klapper]

On Thu, 2015-02-05 at 09:58 -0800, George Herbert wrote:
> Any news on root cause?

All work in progress: Documentation is linked from the desc in
https://phabricator.wikimedia.org/tag/incident-20150205-siteoutage/
and that project also lists potential followup actions as tasks.

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Mark Bergsma]

Hi all,

We've indeed had a total site outage for roughly 30 minutes. We're still
collecting all data, but we've tracked down the cause to multiple cascading
issues including loss of power to a critical SPOF network switch and HHVM
MediaWiki application servers getting blocked due to multiple unoptimal
timeout settings. We'll post a full incident report soon, and work to
correct the underlying issues as soon as possible.

Our apologies,

On Thu, Feb 5, 2015 at 7:03 PM, Guillaume Paumier 
wrote:

> Hi,
>
> Le jeudi 5 février 2015, 09:58:01 George Herbert a écrit :
> > I saw a WMF tweet of a site outage (network?) around 9:30am Pacific
> time, by
> > the time I could check now things seem ok on en
>
> Sites are mostly back up but there are still issues with login, so the Ops
> team hasn't had time to write a postmortem yet.
>
> --
> Guillaume Paumier
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Mark Bergsma 
Lead Operations Architect
Director of Technical Operations
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tweet of site outage

[Guillaume Paumier]

Hi,

Le jeudi 5 février 2015, 09:58:01 George Herbert a écrit :
> I saw a WMF tweet of a site outage (network?) around 9:30am Pacific time, by
> the time I could check now things seem ok on en

Sites are mostly back up but there are still issues with login, so the Ops 
team hasn't had time to write a postmortem yet.

-- 
Guillaume Paumier

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tweet of site outage

[George Herbert]

I saw a WMF tweet of a site outage (network?) around 9:30am Pacific time, by 
the time I could check now things seem ok on en

Any news on root cause?

George William Herbert
Sent from my iPhone
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [gerrit] EUREKA!

[Brian Gerstle]

Very cool, Quim!  Can't wait until it's ready for early adoption ;-)

On Thu, Feb 5, 2015 at 4:59 AM, Federico Leva (Nemo) 
wrote:

> This issue is tracked at https://phabricator.wikimedia.org/T40100 . Cf.
> https://phabricator.wikimedia.org/T55958 , https://phabricator.wikimedia.
> org/T47267#1017438
>
> Nemo
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [gerrit] EUREKA!

[Federico Leva (Nemo)]

This issue is tracked at https://phabricator.wikimedia.org/T40100 . Cf. 
https://phabricator.wikimedia.org/T55958 , 
https://phabricator.wikimedia.org/T47267#1017438


Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [gerrit] EUREKA!

[Quim Gil]

Wikimedia Phabricator is getting there. Slowly, but we will get there.

On Wed, Feb 4, 2015 at 11:34 PM, Brian Gerstle 
wrote:

> Go to a change 


We don't have Phabricator Differential (code review) yet, but we have
Diffusion (repository browser) and...


> , click on the gitbit
> <
> https://git.wikimedia.org/commit/apps%2Fios%2Fwikipedia/6532021b4f4b1f09390b1ffc3f09d149b2a8d9d1
> >
>

https://phabricator.wikimedia.org/rAPIW08f0d835ba4441eab28ce691424088e2b4743270

link next to a patch set, then behold: MAGIC!!!
> <
> https://git.wikimedia.org/commitdiff/apps%2Fios%2Fwikipedia/712f033031c3c11fe8d521f7fdac4252986ee741
> >
> GitHub like diff viewer! No more "All Side-by-Side" w/ 1e6 tabs open.
>

https://phabricator.wikimedia.org/rAPIW712f033031c3c11fe8d521f7fdac4252986ee741

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia Hackathon 2015 in Phabricator

[Quim Gil]

On Thu, Feb 5, 2015 at 1:43 AM, Arthur Richards 
wrote:

> Is this also the appropriate place
> and is this the appropriate time to start proposing focus
> areas/projects/sessions/etc?


The details of the call for participation are being discussed at
https://phabricator.wikimedia.org/T88525

We need to confirm that we use Phabricator to propose tasks, as we did for
the MediaWiki Developer Summit. I think it is better than the former
wiki-based process, as it integrates better with related work, and it
allows for clearer ownership and status, granular subscriptions, and better
commenting.

There is no reason to stop anyone from proposing activities now. We still
need to decide whether we have main themes to be pushed beforehand,
though.Also, this is a hackathon, pre-filling the schedule is not a goal
per se.


Is there already a theme/scope defined for
> project ideas (eg I see a column on the workboard entitled 'New forms of
> editing hack ideas' - is that the general hackathon theme)?
>

No, and I edited the workboard to avoid confusion. The goals of the
hackathon (including main themes) need to be agreed at
https://phabricator.wikimedia.org/T88520

Needless to say, this is your hackathon. If you have a theme or an activity
you want to push, push for it now.



>
> On Wed, Feb 4, 2015 at 2:59 AM, Quim Gil  wrote:
>
> > Hi, just a note to say that the Phabricator project for the Wikimedia
> > Hackathon 2015 (Lyon, 23-25 May) has been created.
> >
> > https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/
> >
> > You are invited to ask questions, provide feedback, and get involved.
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l