[Wikitech-l] Re: Reflecting on my listening tour

[Dan Garry (Deskana)]

Despite agreeing wholeheartedly that technical debt, product debt,
ownership, and maintenance are persistent problems, here's a story about
when this *didn't* happen, which maybe we can learn from.

Disclaimer: this is from my memory of 2014! Warning, potential inaccuracy
and rose-tinted glasses!

We had a global login system (single user login, or SUL) but it was in a
bit of disarray. There were many local accounts disconnected from global
ones because they were made before the global login system, many username
conflicts that went unaddressed. Users were given some tools to resolve
these conflicts, but not enough to actually finalise the whole thing. We
all agreed it needed solving. We all new the end state we wanted. But,
there were multiple technical and product solutions to get there, and no
actual concerted effort to do it. Many of the username conflicts were
between long-time community members, so we were sure to get some dedicated
volutneers angry no matter how we did it. So it sat in limbo, annoying
everyone, and never happening. Sound familiar?

Around then, WMF leadership introduced a new prioritisation framework: "top
5 priorities". This was a ranked list of projects that were considered to
be more important than others for that quarter. It was intended as a first
attempt to combat the "if everything's important, nothing's important"
syndrome. You can't argue with a ranked list! And, number one on the list
for the first quarter, not something new and shiny, but an old one: the SUL
finalisation ! Sort it all
out, once and for all.

Erik Möller (the then VP of Product and Engineering, de facto CPO and CTO
really, reflecting on it) asked me to be the product manager. I was very
inexperienced as a PM but had been an editor for eight years, so I
understood the problem well. Still, I wondered how we were possibly going
to achieve anything, the project had been "in progress" for years with
almost no progress. Erik asked me what I needed to make it happen. I got
some advice, and said I need a systems designer, a systems architect, an
engineer that knows the community well, and a community liaison. Erik went
and had the hard conversations with the people that currently needed said
people ("It's top priority this quarter, the other stuff has to wait.") and
went and got those people. We figured it all out, and we did it, once and
for all (timeline reduced, it did still take multiple quarters, but we knew
that going in). Everyone now has a fully global account!

Now, times were simpler back then. This exact technique wouldn't work now,
for multiple reasons. But, I wonder what we can learn from this as an
organisation. What would it take to repeat this achievement?

Dan

P.S. Some of that team I worked with are still on this list. Hello! Thank
you for the growth as a PM that I got out of that project, and for beating
my inexperienced head around a bit until it got more experienced.
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator

[Dan Garry (Deskana)]

On Fri, 24 Feb 2023 at 11:20, Andre Klapper  wrote:

>  * Personally I also assume Lowest priority is sometimes used instead
>of honestly declining a task (means: "this is not a good idea"[5]).
>But of course that is rather hard to prove.
>

This is anecodal, but when I was a product manager at the WMF, I did this
sometimes. As is true in any company or project, there will always be
tickets that contain valid bugs or requests, but the reward per unit effort
makes them not worth fixing. I often tried to close these as declined to
reflect that reality, but not infrequently someone outside the team would
reopen the ticket. The path of least resistance to stop team workboards
being filled with tickets that would never be actioned was to mark them as
lowest priority, and then use a filter to remove those tickets from our
views of the board.

I don't particularly have a view one way or the other on removal of the
"lowest" priority. The workflow I described above wouldn't really change;
"low" could just become the new "lowest", but people wouldn't find it
demoralising, I suppose?

Dan
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Discussing two feature requests?

[Dan Garry (Deskana)]

Hi Siegfried,

You are welcome to send emails to this mailing list in German, if you would
prefer. Most people on this list write in English because it is understood
by the most people and it has the largest audience, but this is a
multilingual community and posts in any language are allowed.

Of course, you are also welcome to email privately in German if you would
prefer to do that.

Dan

On Sun, 26 Jun 2022 at 07:22, Siegfried Schmitt 
wrote:

> Hello Everyone,
>
> I would like to propose two - probably new - features for MediaWiki.
> Since my native language is German, I would like to discuss these
> features with some developers from Germany, Austria, or Switzerland.
> My Englisch is really bad and therefore, I would prefer to discuss in
> German language. Please feel free to contact me via e-mail.
>
> Best regards,
>
> Siegfried
>
> --
> siegfried.schm...@web.de
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Why does the train start on Tuesday?

[Dan Garry (Deskana)]

On Tue, 22 Jun 2021 at 23:10, Jon Robson  wrote:

> Apologies if I didn't make myself clear, but it seems I didn't given both
> Amir's comments. I am very happy that we have these, and my question was *not
> *why do we have them, but rather* why do we only have 2*. I want more of
> them and every time I've asked why we don't have more, I've been told it's
> a community decision and that seems odd to me.
>

It's a community decision in the sense that it wasn't something the WMF
decided for them, it was those communities decided it for themselves.
They're open to it probably as a result of being generally less
conservative when it comes to changes, and more willing to try things out
early. But, it's not a community decision in the sense that you, as staff,
can't get involved and try to recruit more wikis!

So, if other wikis are asked if they want to be in group 1, understand the
advantages and disadvantages of that, and they said yes, I doubt anyone
would raise any objections. Having more wikis in that group to test things
on early would definitely be a benefit.

Amir's suggestion to contact wikis that have been open to Growth features,
like Czech and Korean (I think?), sounds like a great one, especially if
there are community ambassadors that could help explain what it means to be
in group 1.

Dan
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] 1st CfP: SEMANTiCS 2021 EU || Sep 6 - 9, 2021 || Amsterdam, The Netherlands

[Dan Garry (Deskana)]

I agree with Max. This conference is pretty much irrelevant for this list,
as it has almost nothing to do with the topic of wikis generally. The only
connection this conference has to this list is the existence of the
Semantic MediaWiki extension; this list could quickly be overrun with
conference emails if they were allowed on the basis of the existence of a
MediaWiki extension related to the topic area.

Sebastian, there are a few Semantic MediaWiki email lists
,
why don't you try posting this there? You might get a lot more interest, as
the audience there will be very interested in the Semantic Web. :-)

Dan

On Fri, 25 Dec 2020 at 16:18, Andreas Papacharalampous 
wrote:

> i don't mind a crosspost, but probably not a good idea to vent your
> frustration against a crosspost on a public list IMO.
>
> --andreas
> he/him
>
>
>
> On Fri, Dec 25, 2020 at 10:53 AM Andrew Krizhanovsky <
> andrew.krizhanov...@gmail.com> wrote:
>
>> Sorry Max, but this information was interesting for me :)
>>
>> Best regards,
>> Andrew Krizhanovsky.
>>
>>
>> On Fri, 25 Dec 2020 at 13:32, Max Semenik  wrote:
>>
>>> On Fri, Dec 25, 2020 at 1:21 PM Sebastian Hellmann <
>>> pr-a...@informatik.uni-leipzig.de> wrote:
>>>
 Apologies for cross-posting
>>>
>>>
>>> Apologies not accepted. Don't know about others on this list, but I'm
>>> tired of your spam of conferences very remotely related to MediaWiki
>>> development. MediaWiki is not Semantic MediaWiki, 99% of people here don't
>>> care about your stuff. Please stop.
>>>
>>> --
>>> Best regards,
>>> Max Semenik
>>> ___
>>> 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 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] Backport and Config changes window (name change)

[Dan Garry (Deskana)]

On Mon, 8 Jun 2020 at 17:58, Greg Grossmeier  wrote:

> Until today if you wanted to get a backport or config change deployed to
> production you used what was termed the "SWAT" window.
>
> As of today that window of time is now called the "Backport and Config"
> window. This solves a few problems. First, the overly militarized and
> violence-implying name is no longer something we want in our community.
> Second, this now accurately and clearly describes what the purpose of the
> window is.
>

A good change. Thanks!

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

Re: [Wikitech-l] Gerrit outage

[Dan Garry (Deskana)]

On Tue, 19 Mar 2019 at 10:50, Lewis Cawte via Wikitech-l <
wikitech-l@lists.wikimedia.org> wrote:

> Not everyone is aware that the process of cleaning up the vandalism/fixing
> Gerrit includes Gerrit being down temporarily.
>
> Do I need to include a reminder link to WP:AGF / WP:DICK?
>

That would not be helpful. By assuming that the other person simply missed
the other thread on this mailing list, and by pointing the person to said
thread, Andre *is* assuming good faith.

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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Dan Garry (Deskana)]

Strainu,

I, too, am glad for the discussion!

On Sat, 9 Mar 2019 at 22:31, Strainu  wrote:

> Let me start with a simple question, to put the references to wmf into
> context. You keep talking below about volunteer developers and how they can
> take over any project.


I'm confused by this. I didn't mention volunteer teams taking over projects
at all, and I don't think that'd work except in very rare and limited
circumstances. I was talking about people helping with bug triage on
Phabricator.


> While that's true, how many fully-volunteer teams
> are there?  How does that number compare to the number of wmf teams? Am I
> right to assume the ratio is hugely in favor of wmf teams?  Note: teams,
> not developers, since decisions on project management are usually done at
> team level.
>

See above; this wasn't what I meant.


> In my experience in b2b contracts they don't keep it a secret, they usually
> have SLAs they respect, but ok, let's leave it at that.
>

Yes, I have more to say about this, but this would be tangential to this
discussion. :-)


> Responsibility for what? Developing and hosting  MediaWiki? Helping
> communities concentrate on creating and attracting content without having
> to work around bugs? I'm sorry, but that's precisely one of the
> responsibilities of the wmf and this is what's discussed here.
>

Well, in your earlier emails in this thread, you mentioned the bug backlog
steadily increasing, so that was what I was talking about. Is that not what
you were talking about in your subsequent emails?


> This is one thing that we agree on: nobody committed on anything. Ever.
> That's why I asked above: what does it take to have someone (anyone) at the
> WMF act upon these discussions?
>
> My role in the Wikimedia tech community is tech ambassador above all else,
> so I'm caught in the middle here: I have to explain new features and
> technical decisions to people who don't care about php, js or server
> performance , but I also feel obligated to relay their requirements, as I
> see them, to the development team. This second process does not happen as
> smoothly as it should.
>
> It's not healthy to ignore discussion after discussion and claim it's a
> community issue. It's not. It's a governance issue and it's growing every
> day.
>

I agree. It's not a community issue, it's a movement-wide one. I don't know
how to solve it.


> The projects belong to the community at large, not just the technical
> subcommunity. They are the ones affected by the  bugs and also they are the
> ones that need our support. So why should they be ignored in taking this
> decision?
>

I'm confused by this too. I wasn't talking about ownership of the Wikimedia
projects, I was again talking about the bug backlog, which anyone is
welcome to get involved in simply by registering an account.


> My proposal is to begin the discussion here: how can we better relay issues
> that are more important to communities than new features? How can we have a
> "community whishlist for bugs"?
>

The community wishlist explicitly accepts requests to fix bugs, as well
requests for new features. So, is what you're asking for some process to
supplement that?

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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Dan Garry (Deskana)]

On Sat, 9 Mar 2019 at 11:26, Strainu  wrote:

> How many successful commercial projects leave customer issues unresolved
> for years because they're working on something else now?
>

Almost all of them, they just keep it secret. Companies pay millions of
dollars each year for support packages, even after having paid for software
in the first place, specifically because otherwise their support issues may
not be answered in a timely fashion, or even answered at all. I don't think
comparing us to commercial products makes much sense in this context.


> There were a
> number of proposals on how to track such issues so that reporters have a
> clear image of the status of the bugs. Have any of them been tried by at
> least one of the teams at wmf? If so, is there a way to share the results
> with other teams? If not, how can we convince the wmf to give them a
> chance?
>

I don't agree with shifting responsibility onto the Wikimedia Foundation.
There's an anti-pattern here: we all have a big mailing list discussion,
agree there's a problem, agree that the Foundation should solve the
problem, then ask again in a year what they did even though they didn't
actually say they'd do anything about it. That's not a healthy dynamic.

The technical space is owned by all of us, so if we, as a technical
community, decide this is important to us, then we can look at the problem
and try to tackle it, and then figure out how the Wikimedia Foundation
could catalyse that.

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

Re: [Wikitech-l] PHP 7 is now a beta feature

[Dan Garry (Deskana)]

Cool! Thanks for developing this beta feature, it makes it easy to test.

Is there anything in particular that you might expect to behave
differently, or break, that you'd like us to test? Are you just looking for
more general feedback?

Thanks!

Dan

On Mon, 28 Jan 2019 at 14:31, Giuseppe Lavagetto 
wrote:

> Hi all,
>
> as some of you might know, HHVM has decided some time ago to drop support
> for PHP, choosing to only support Hack (Facebook's own PHP-derivative
> language)[1].
>
> This forced us to consider alternatives. In particular the last major
> upgrade to PHP, PHP 7, was supposed to have greatly improved the
> performance of the runtime, guaranteeing performance on par with HHVM.
>
> Given that early tests[2] showed promising performance, we decided to work
> on PHP7 support and on its rollout in production.
>
> I'm happy to announce that PHP 7 is now available as a beta feature on all
> wikis, and I encourage everyone to try it out and report bugs using the
> #php7.2-support tag.
>
> After this period of beta testing, we will proceed with a progressive
> rollout to a growing percentage of users, and hopefully we'll complete the
> transition in the next four months.
>
> A huge thank you to all the people who worked hard to reach this goal!
>
> Thanks,
>
> Giuseppe
> [1] https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
> [2]
> https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088854.html
> --
> Giuseppe Lavagetto
> Principal Site Reliability Engineer, Wikimedia Foundation
> ___
> 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] [Engineering] Gerrit now automatically adds reviewers

[Dan Garry (Deskana)]

Something new was tried in the hopes it'd be good, it turned out not to be
good, it was reverted, and now there's some discussion about how to make it
better. That's a successful process, not an unsuccessful one.

Given that this exact method of doing things is not only well-established
on the English Wikipedia but is also a recommended pattern (
bold-revert-discuss ), I'm not
sure why you think this would be unacceptable there.

Dan

On Fri, 18 Jan 2019 at 22:13, Pine W  wrote:

> I'm glad that this problematic change to communications was reverted.
>
> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment. Involving TechCom might also be appropriate. It appears that
> none of those happened here. In terms of process this situation looks to me
> like it's inexcusable.
>
> In the English Wikipedia community, doing something like this would have a
> reasonable likelihood of costing an administrator their tools, and I hope
> that a similar degree of accountability is enforced in the engineering
> community. In particular, I expect engineering supervisors to follow
> established technical processes for changes that impact others' workflows,
> and if they decide to skip those processes without a compelling reason
> (such as a site stability problem) then I hope that they will be held
> accountable. Again, from my perspective, the failure to follow process here
> is inexcusable.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> 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] 2019-01-09 Scrum of Scrums meeting notes

[Dan Garry (Deskana)]

On Wed, 9 Jan 2019 at 20:25, Pine W  wrote:

> I would like to request that every Audiences and Technology team submit
> highlights of recent and upcoming activities for inclusion in every set of
> SoS notes, even if no one personally attends the SoS meeting from a
> particular team, so that readers of these notes can keep better track of
> what is happening in the Audiences and Technology departments and so that
> readers can make adjustments to our own plans as needed.


Scrum of scrums meetings are intended to be a venue for development teams
to surface upcoming blockers and dependencies on other teams, so that teams
can better work together and not block each other. Scrum of scrums meetings
are not intended to be a forum for general announcements about activities
by end-users. These are very different use cases with different target
audiences.

I understand your concerns about visibility of the actions inside the
Wikimedia Foundation. It's certainly difficult to see things from the
outside. That said, taking a meeting with a well-defined purpose and
objective, and expanding that objective to add an additional, quite
different use case, is not good practice; doing so may cause people to
disengage or lose focus, thereby meaning the original objective of the
meeting is no longer met.

Some reading you might find useful:

   - https://www.agilealliance.org/glossary/scrum-of-scrums/
   - https://www.scruminc.com/scrum-of-scrums/

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

Re: [Wikitech-l] non-obvious uses of in your language

[Dan Garry]

On Thu, 4 Oct 2018 at 23:29, John Erling Blad  wrote:

> Usually it comes from user errors while using VE. This kind of errors are
> quite common, and I asked (several years ago) whether it could be fixed in
> VE, but was told "no".
>

I'd really appreciate it if you could give me more information on this.
Could you link to the task for this request? There is T128060
<https://phabricator.wikimedia.org/T128060> from early 2016 ("VisualEditor
makes it easy to create partially linked words, when the user expects a
fully linked one") but I don't see you on there, and I want to make sure I
understand your request.

Here's how the linking feature works right now for adding links to words
which presently have no links:

   - If you put your cursor inside a word without highlighting anything,
   and add a link, the link is added to the entire word.
   - If you highlight some text, and add a link, the link is added to the
   highlighted text.

How would you propose this feature be changed?

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Dan Garry]

On 8 August 2018 at 14:29, Alex Monk  wrote:

> Are you trying to ban people discussing CoC committee decisions publicly?
> Not that it even looks like he wrote grievances.


Hardly. I have absolutely nothing to do with the administration of this
list, nor the authority to set what is discussed on this list, nor any
involvement in the Code of Conduct, all of which you are well aware.

Dan

-- 
Dan Garry
Lead Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Dan Garry]

On 8 August 2018 at 13:53, MZMcBride  wrote:
>
> Ah, I found the e-mail: […]
>

This mailing list is not an appropriate forum for airing your grievances
with the way the Code of Conduct Committee has handled this matter.

Dan

-- 
Dan Garry
Lead Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The target revision does not exist

[Dan Garry]

Hey Bináris,

There's a help page on mediawiki.org
<https://www.mediawiki.org/wiki/How_to_report_a_bug#Reporting_a_new_bug_or_feature_request>
about
how to file a task in Phabricator. Please provide as much detail as you can
about how to reproduce the problem. And remember, it's always better to
have duplicate bugs than unreported bugs, so if you're in any doubt then
you should file a task. :-)

Anyway, it seems to be working fine for me now. I can see the change but
not the edit summary. Not being able to reproduce the problem may make it
harder to diagnose, but maybe you can provide details that explain.

Hope that helps!

Dan

On 4 September 2017 at 21:12, Bináris <wikipo...@gmail.com> wrote:

> We have Flagged Revs in huwiki. This edit was made by an anon, and an admin
> hid the inappropriate summary.
> https://hu.wikipedia.org/w/index.php?title=S%C3%BClys%C3%
> A1p=45101=19117621=19117618
> After this we couldn't review the version. The message was:
> Unable to review this revision. The target revision does not exist.
> (Source fo English text:
> https://en.wikipedia.org/wiki/MediaWiki:Revreview-failed and
> https://en.wikipedia.org/wiki/MediaWiki:Review_bad_oldid)
>
> In fact the revision did exist, only the edit summary was hidden. Is this a
> bug or a feature? :-) I am not very familiar with Phabricator, so is there
> a ticket for this feature already?
>
> --
> Bináris
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Senior Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Dan Garry]

On 1 September 2017 at 01:58, Gergo Tisza <gti...@wikimedia.org> wrote:
>
> We could send them to something like https://whatbrowser.org/ or
> https://browsehappy.com/


whatbrowser.org is definitely a nice experience, but it does require JS to
work; it fails to load both your current browser and suggestions for others
without JS. A lot of older browsers do have Javascript support, so that
might not be a problem, but perhaps it could be for some browsers.

Speaking of neutrality, it's important to note that whatbrowser.org is
owned and run by Google. I don't think that's a problem, since the site is
fairly neutral in its assessment and recommendations.

Dan

-- 
Dan Garry
Senior Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Log of nulledits

[Dan Garry]

By definition, a null edit does not perform any change at all, and is
therefore not recorded publicly since there's technically nothing to
record. I suspect the only way you could find this kind of information is
in the server logs, and access to those is very tightly restricted for
privacy reasons.

Dan

On 25 July 2017 at 12:55, Bináris <wikipo...@gmail.com> wrote:

> Hi,
>
> given a bot that only makes nulledits, for example with touch.py (ie.
> saving pages without modifying), these edits won't appear either in recent
> changes or the page history.
>
> How can I follow these edits? (I am admin and checkuser, but it may be
> interesting without higher user rights.)
> Even with good faith these nulledits load the server, but they can be used
> for an overload attack, too.
>
> --
> Bináris
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [discovery] Search update: sister project snippets are now in production!

[Dan Garry]

Yay! Nice work. :-)

Dan

On 16 June 2017 at 01:06, Deborah Tankersley <dtankers...@wikimedia.org>
wrote:

> Hello,
>
> We're happy to announce that the latest update to the search results page
> is now in production!
>
> We've added snippets from the Wikimedia sister projects into a sidebar
> display on the search results page to further discovery into even more
> knowledge using your search query. You can test this new functionality out
> using your favorite wiki and here are a few quick sample URLs to get you
> started:
>
>- German: https://de.wikipedia.org/w/index.php?search=Wiener+
>Schnitzel~=Special:Search
>
> <https://de.wikipedia.org/w/index.php?search=Wiener+Schnitzel~=Special:Search>
>- Italian: https://it.wikipedia.org/wiki/Special:Search?search=Ricerca;
>fulltext=1
>- Basque: https://eu.wikipedia.org/w/index.php?search=barruti~;
>title=Berezi:Bilatu=Joan
>- English: https://en.wikipedia.org/w/index.php?search=the+night+is+
>nigh=Special:Search
>
> We had sent an email earlier in the year, in which we described the
> overall search work that the Discovery team has been doing, if you'd like a
> refresher on our project.[1]
>
>
> Cheers from the Discovery Search team!
>
> [1] https://lists.wikimedia.org/pipermail/discovery/2017-April/001487.html
>
>
> --
> deb tankersley
> irc: debt
> Product Manager, Discovery
> Wikimedia Foundation
>
> _______
> discovery mailing list
> discov...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/discovery
>
>


-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Group 2 deployment regression: Watchlist breaking change

[Dan Garry]

On 14 June 2017 at 21:37, יגאל חיטרון <khit...@gmail.com> wrote:

> Really? Last time the problem was solved in an hour, without any ticket. I
> added the description, thank you.
> Igal


Yes, really. :-)

Problems sometimes get solved fast without tickets, but it depends on a lot
of different factors. As James said, filing an "Unbreak Now!" ticket is the
fastest and most reliable way to get attention; engineers doing deployments
actively watch for these.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] @author annotations in files in the mediawiki codebase

[Dan Garry]

I am inclined to agree with Subbu, but of course there are legal
implications. Zhou said it would be fine to move all these tags to a
centralised CREDITS file and point to that file, and that doing so wouldn't
breach the licence. He is a lawyer and is therefore qualified to make such
determinations.

Whether moving CREDITS to a centralised file actually solves the problem,
rather than just shifting it around, is debatable.

Dan

On 13 June 2017 at 06:11, Subramanya Sastry <ssas...@wikimedia.org> wrote:

> I noticed that core files have @author annotations.
>
> My take on this is as follows: Any active codebase (such as mediawiki)
> sees constant change and code is refactored, rewritten, renamed, files
> moved around, split up, etc. that the only meaningful interperation of
> "@author" would be someone who first created that file / function, no
> matter how small that piece of code was. At that level, it is not that
> meaningful, especially in the face of refactoring and restructuring. git
> log --follow might provide a better picture for an individual file. I think
> all @author annotations should be removed. When editing a piece of code, I
> imagine some developers might find it a little annoying ... and confusing
> especially during refactoring ... whether to retain it or not.
>
> I find these annotations misleading and wonder why they exist and what
> purpose they serve. Would appreciate a discussion on this. Alternatively, I
> would appreciate if someone can point me to a wiki page / phab task / essay
> that explains the rationale for why these annotations should exist and be
> preserved.
>
> Thanks,
>
> Subbu.
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Dan Garry]

On 16 March 2017 at 13:21, Brad Jorsch (Anomie) <bjor...@wikimedia.org>
wrote:
>
> Doesn't etherpad (https://etherpad.wikimedia.org/) fit that need without
> being proprietary?
>

Possibly. There are features that Google Docs has that Etherpad doesn't,
but I don't know whether they're relevant since I'm not involved with the
Architecture Committee. Hopefully they can answer.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Dan Garry]

On 16 March 2017 at 05:00, Legoktm <legoktm.wikipe...@gmail.com> wrote:
>
> As requested earlier, will these documents be moved to mediawiki.org or
> is it now required to use Google's proprietary software to discuss the
> architecture of MediaWiki?
>

If there's nothing private in there, which one can only assume there is not
since the document is world-readable, I would encourage you to Be Bold and
transfer it to mediawiki.org. That document was edited by staff, and staff
agree to release their work as CC BY-SA in their contracts, so copying it
over should be fully compliant with the licence if you link to the doc for
the history in your comment. Further edits can then be made to the page on
mediawiki.org.

Google Docs is easier to spin up in the moment and edit collaboratively
than MediaWiki. Using proprietary software tools if they're a better fit
for the intended purpose is entirely consistent with the Foundation's
guiding principles
<https://wikimediafoundation.org/wiki/Resolution:Wikimedia_Foundation_Guiding_Principles#Freedom_and_open_source>,
so their choice to use Google Docs makes sense to me. That said,
transferring the notes out of the doc to mediawiki.org after the moment has
passed does seem like a good idea in general.

NB: I have nothing to do with Architecture Committee, I'm just an
interested observer.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator monthly statistics - 2017-02

[Dan Garry]

17226 days ago was 1st January 1970
<https://en.wikipedia.org/wiki/Unix_time>, naturally. :-)

Dan

On 1 March 2017 at 00:12, Gergo Tisza <gti...@wikimedia.org> wrote:

> On Tue, Feb 28, 2017 at 4:03 PM, Pine W <wiki.p...@gmail.com> wrote:
>
> > Argh, I misread that. Median number of days, not number of bugs. Still
> > seems kind of high.
> >
>
> Probably a bug? We don't have any open UBN tasks right now.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Secondary search results (e.g. language detection) now available over API

[Dan Garry]

Hello!

*tl;dr: add srenablerewrites=yes to your API search queries to enable
search results from different language projects*

The Search Team
<https://www.mediawiki.org/wiki/Wikimedia_Discovery#Search:_Backend> is
thrilled to announce that secondary search results are now available over
the API. This means that automated language detection (provided by TextCat
<https://www.mediawiki.org/wiki/TextCat>) and query forwarding can now be
used by API consumers.

Here's the explanation. The Search Team's analysis of common search queries
<https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Survey_of_Zero-Results_Queries#Foreign_languages>
showed that there are quite a few search queries that aren't in the
language of the wiki the user is on. To help alleviate this problem, and
give users useful results, we added language detection and query
forwarding; for example, Луковичная глава
<https://en.wikipedia.org/w/index.php?title=Special:Search=default=Луковичная+глава=Search>
now
gives the user results from the Russian Wikipedia. This is the
functionality that's now available over the API, as you can see if you perform
the same search over the API
<https://en.wikipedia.org/w/api.php?action=query=search=%D0%9B%D1%83%D0%BA%D0%BE%D0%B2%D0%B8%D1%87%D0%BD%D0%B0%D1%8F+%D0%B3%D0%BB%D0%B0%D0%B2%D0%B0=yes>
with the srenablerewrites parameter enabled.

The secondary results functionality was added to MediaWiki core
<https://gerrit.wikimedia.org/r/#/c/324652/> and is extendable so that, in
the future, if we (or someone else!) provide secondary results from other
sources, then this functionality can be used for that. For backwards
compatibility, don't add the srenablerewrites parameter and you'll continue
getting the same results in the same format as before this change.

Happy querying!

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Offering internationalized programming facilities within WM enviroment

[Dan Garry]

On 21 December 2016 at 16:42, Gergo Tisza <gti...@wikimedia.org> wrote:

> I sympathize with the goal but accessibility benefits would be far
> outweighed by maintaince costs.


I agree. This is an example of an absolutely excellent idea with a clearly
defined goal that, when you work out the details of what would be needed to
make it work, quickly becomes infeasible.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Dan Garry]

On 10 December 2016 at 01:25, Pine W <wiki.p...@gmail.com> wrote:

> Surprise UI changes could, for example, result in thousands of dollars'
> worth of instructional videos becoming instantly out of sync with the
> real-world user experience.


Given the incredibly minor nature of this change (as you can see from Amir's
thread on the village pump
<https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Reopening_discussion_about_aligning_colors_with_Wikimedia_color_palette>),
your example is absurd. Small changes such as these would not even come
close to invalidating instructional videos. If the changes were larger,
then I am sure there would've been significantly more advance notice.
Amir's actions seem perfectly appropriate to me in this case; if anything,
I would say an announcement wasn't even required and that he went above and
beyond in doing so. Let's not punish him for that.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [reading-wmf] Upcoming changes to PageImages

[Dan Garry]

Hey Olga,

I am very glad to hear about these changes! Thanks to your team for working
on them.

Dan

On 28 November 2016 at 11:20, Olga Vasileva <ovasil...@wikimedia.org> wrote:

> Hello everyone!
>
> In preparation for getting hovercards ready for release, the reading-web
> team has been working on some changes to the PageImages extension
> <https://www.mediawiki.org/wiki/Extension:PageImages> to account for a
> number of bug reports on incorrect images or images that may appear out of
> context.  We are working on the following changes:
>
> 1. Allowing Non-free images to appear (when allowed)
> 2. Allowing PageImages to select images only from the lead section or
> infobox of an article
> 3. Allowing editors to set the PageImage for a page
>
> From these, we will be applying 1 and 2 within this quarter (and most
> likely by the end of this sprint).  More details on the changes, including
> corresponding tasks can be found here - https://www.mediawiki.org/
> wiki/Reading/Web/Projects/PageImagesChanges
>
> Thanks and let us know if there’s any questions!
>
> Cheers,
>
> - Olga
>
> --
> Olga Vasileva // Product Manager // Reading Web Team
> https://wikimediafoundation.org/
>
> ___
> reading-wmf mailing list
> reading-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>


-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

On 24 May 2016 at 23:00, Niklas Laxström <niklas.laxst...@gmail.com> wrote:
>
> Localising a few static strings is not difficult and I (and others)
> have already met with your team to share information how to do this.
> In my opinion deprioritizing this work would be against our mission
> and values. I am available for help if you run into any issues during
> the process.
>

Thanks for your offer, Niklas! I know the team is now talking to you about
this, and your help is much appreciated. :-)

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

On 24 May 2016 at 22:20, Comet styles <cometsty...@gmail.com> wrote:

> Can everything on the right side of the footer be moved to the left
> and the "Wikipedia is hosted by the.." part moved to the right side of
> the footer? ..it seems odd the other way around..i feel like i'm
> reading arabic..


Thanks for the suggestion. I filed T136344
<https://phabricator.wikimedia.org/T136344> for this to be discussed.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

On 24 May 2016 at 22:33, MZMcBride <z...@mzmcbride.com> wrote:
>
> Regarding portals other than www.wikipedia.org, perhaps you can respond at
> <https://phabricator.wikimedia.org/T135929>?


Sure, I can take a look at that task.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [discovery] [Translators-l] update: wikipedia.org portal

[Dan Garry]

Nemo,

As with MZMcBride, the way that you have communicated here is very
unconstructive and inappropriate. Your choice of language (e.g. "small WMF
clique", "contradict and impoverish the Wikimedia mission") is not
conducive to a good working environment. Constructive feedback is welcomed,
but much of what you said here was not that. If you are unable to be more
constructive moving forward, my team will not respond to your comments.

Dan

On 21 May 2016 at 09:58, Federico Leva (Nemo) <nemow...@gmail.com> wrote:
>
> Adding English-only text to the Wikipedia portal is unacceptable. Special
> powers on a Wikimedia domain must not be used to contradict and impoverish
> the Wikimedia mission. The portal seize by a small WMF clique has shown its
> failure and should immediately be reversed, as the Meta-Wiki administrators
> have proven to be more competent.


-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

Hey Purodha,

On 21 May 2016 at 05:13, Purodha Blissenbach <puro...@blissenbach.org>
wrote:

> On the long run, I think, these portals and their texts should
> be translatable. Browser settings determining the target language.
> Looking forward to have them on translatewiki.net !
>

I agree that localising these strings would be helpful and in-line with our
practices. That's definitely something that we're interested in doing, and
we're going to be doing an investigation on that soon. We're hoping it'll
be fairly straightforward to get this done... but if it's not, we may need
to deprioritise the work. We'll see.

Thanks!

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

Hey DJ,

Thanks for the feedback! Responses in-line.

On 21 May 2016 at 04:52, Derk-Jan Hartman <d.j.hartman+wmf...@gmail.com>
wrote:

> I like the addition of the descriptive subtitles. But I would suggest
> taking them to meta to settle on what they should be exactly, and also then
> documenting them (including arguments) to make sure that they can be used
> consistently throughout the projects.
>

I agree that some standardisation of the phrases used here would be useful.
I'll pass that feedback on to Communications, who I believe handles most of
these kinds of situations. In the mean time, I think Discovery can take a
quick pass on the phrases that are being used on the portal to make them a
bit more consistent.


> I was wondering about the colors. Have we considered the MediaWiki/OOjs UI
> color theme already. In my opinion the portal feels more cologneblue than
> Vector right now..
>

I can see what you mean. A lot of the styles of the new elements have been
made to fit the old style of the page. I'm not a designer, so I don't know
specifically what to recommend to the team here, but I think they can keep
this in mind for the future.

Also, I do wonder a bit about the consistency of the portals and the lack
> of options for reuse of these improvements by other portals, and I
> personally think it would be great to start expanding parts of the
> development to other portals now.
> I think it would be wonderful if we could create a pipeline of reusable
> elements among the portals, that allows for some consistency, but trying to
> avoid blandness and uniformity. Simple things like a library of Less
> variables usable by all portal pages can mean a lot for these kinds of
> efforts and I'd love to see some attention devoted to that, so that other
> portal pages can benefit.
>

As explained in T110070#1653320
<https://phabricator.wikimedia.org/T110070#1653320>, Discovery is not
actively maintaining the other portals. That said, I agree that trying to
get our code to a state where it's easily re-useable for other portals so
that interested people can migrate it over to the other portals would be
good to do. I filed T136151 <https://phabricator.wikimedia.org/T136151> to
track that work.


> For community participation, I also have some ideas:
> 1: There is no README.md
>

Good point. I saw you filed T135902
<https://phabricator.wikimedia.org/T135902> and T135903
<https://phabricator.wikimedia.org/T135903> for this. Thanks! The licensing
question is somewhat complicated given the history of the portals; we will
need to consult with Legal on this to make sure we get it right.


> 2: Make sure that it's easy to test the master version.

The great thing about github for instance is that you can do tricks like:
>
> https://cdn.rawgit.com/wikimedia/portals/master/prod/wikipedia.org/index.html
> That's powerful to be able to preview straight from a git repo. If you
> have links like that to the readme/meta page.
>

I'll pass this feedback on to the engineers working on the project.


> 3: Update https://meta.wikimedia.org/wiki/Project_portals <
> https://meta.wikimedia.org/wiki/Project_portals>
>

I wasn't aware of this page. I'll pass it on to Chris Koerner, Discovery's
community liaison, so he can look at updating it.

Thanks!

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] update: wikipedia.org portal

[Dan Garry]

MZMcBride,

The way that you have addressed Deb here is very unconstructive and
inappropriate. Your choice of language (e.g. "hijacked", "wrongfully
seized") is not conducive to a good working environment. Constructive
feedback is welcomed, but much of what you said here was not that. If you
are unable to be more constructive moving forward, my team will not respond
to your comments.

Regarding the descriptive text, the current situation on sister portals and
in other places was evaluated beforehand, which included looking at a relevant
template on Meta-Wiki
<https://meta.wikimedia.org/wiki/Template:Main_Page/Sisterprojects/en>. As
you mentioned, the text there isn't great and many of the descriptions used
in different places are incredibly inconsistent with each other; therefore,
there was no golden standard to use. I agree that the descriptive text on
wikipedia.org for the sister projects could be changed further to improve
its consistency. The team will look into that.

Regarding the move of the portal to a git-based system, as I explained in
great detail in my 18 comments on T110070
<https://phabricator.wikimedia.org/T110070>, this move was done in
partnership with Mxn, the primary maintainer of the portal in its previous
system. Mxn and I spoke in person about the portal at Wikimania 2015, which
was what really kicked this project off; I also mentioned that in my very
comment <https://phabricator.wikimedia.org/T110070#1568488> on that
T110070. I was also very clear in my comments on the task
<https://phabricator.wikimedia.org/T110070#1653320> that we were
specifically trying to improve only wikipedia.org to keep our work
manageable and maintain cost effectiveness for our efforts.

There are some things that Discovery has done really well at since (and
because of) the migration, such as improving the performance of the page by
minifying <https://en.wikipedia.org/wiki/Minification_(programming)> the
JavaScript used on the page, and significantly increasing the clickthrough
rate
<https://commons.wikimedia.org/wiki/File:Initial_Assessment_of_New_Wikipedia_Portal%27s_Search_Box_Deployment.pdf>
on the portal by improving the user experience of the box. There are some
things that we could've done better, like keeping the statistics on the
portal up-to-date. As mentioned above, constructive feedback is welcomed.

Dan

On 20 May 2016 at 16:07, MZMcBride <z...@mzmcbride.com> wrote:

> Deborah Tankersley wrote:
> >The Discovery Team recently added descriptive text to the Wikipedia.org
> >page footer in order to give visitors a better idea of what the sister
> >wiki projects are really all about. Check it out at www.wikipedia.org
> >[...]
>
> Hi Deb,
>
> The descriptive texts don't seem great. Some are inconsistent and at least
> one is potentially misleading. Some notes:
>
> * "Free Dictionary" instead of "Free dictionary" for Wiktionary.
> * Starting with "Free" for eight of the projects, but then using a
>   different pattern for the others (e.g., "The free library").
> * Meta-Wiki is "Our community site"? Huh? What does that suggest about the
>   other projects? Are they not community sites?
> * The descriptive texts are only available in English.
>
> The Wikimedia (Foundation) logo is bizarrely in black and white. Why?
>
> It's frustrating and annoying that your happy team hijacked this portal,
> and only this portal, from the Meta-Wiki community that maintained it for
> many years. Your actions have resulted in other portals such as
> www.wiktionary.org falling out of sync with www.wikipedia.org. I wonder
> how much community involvement and collaboration there is now that your
> team has wrongfully seized ownership of this page.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Wikipedia.org portal page update!

[Dan Garry]

On 11 March 2016 at 16:09, Samuel Klein <meta...@gmail.com> wrote:
>
> Perhaps you could do this w two queries, one to a composite index that is
> only updated weekly.
>

Indeed, there are mechanisms that can make cross-wiki searching more
feasible. In fact, one mechanism we are in the very early stages of
exploring is merging all the projects in a given language into a single
index, so that one could search *all* projects in a language, rather than
just a single project in a given language. I have no timeline here; as I
said, we're in the very early stages, and of course we have other work on
the go at the same time.


> > Additionally, it would likely return you a bunch of really irrelevant
> results,
>
> Make this opt-in, add a different background color for results from the
> all-language index, & divide their search-relevance by a
> language-prominence factor...
>

I plan to worry more about the user experience implications that I
mentioned once we're a bit closer to solving the technical feasibility
questions. As you've shown, these are definitely solvable problems, but I
don't want to put the cart before the horse, as it were. :-)

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Wikipedia.org portal page update!

[Dan Garry]

On 11 March 2016 at 10:52, ViswaPrabha (വിശ്വപ്രഭ) <vp2...@gmail.com> wrote:
>
> Failed my dream :(
>
> Any string in any language in any wikipedia project. How far is my dream?
>

I share your dream! :-)

Unfortunately, the dream is quite far away from reality. Querying every
search index would put a big performance strain on the search servers.
Additionally, it would likely return you a bunch of really irrelevant
results, so there's a lot of user experience implications that would need
to be figured out as well. Discovery is not actively working on this at
present.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] New [[Main Page]] for Wikitech

[Dan Garry]

On 28 January 2016 at 21:55, Bryan Davis <bd...@wikimedia.org> wrote:

> I've been working on a little redesign project for the Main Page on
> wikitech [0] and three key sub pages it points to since 2016-01-01 in
> my User space. Tonight I decided that although it is far from perfect
> it is better enough. I hope that some of you like it better than the
> old page and that none of you hate it with a fiery passion that
> compels you to revert it rather than helping me make it better.
>

Thank you! The new page is a clear improvement over the old one
<https://wikitech.wikimedia.org/w/index.php?title=Main_Page=203274>.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Dan Garry]

On 27 January 2016 at 22:51, Ori Livneh <o...@wikimedia.org> wrote:
>
> Ok, understood. Keeping it around costs little. Dan, in case you were
> volunteering, please go ahead and document the purpose of test2 on its main
> page and/or wikitech -- I think it is a good idea.
>

I would be happy to!

I made some changes
<https://test2.wikipedia.org/w/index.php?title=Main_Page=revision=166672=166350>
to the main page of test2. I also made some changes
<https://wikitech.wikimedia.org/w/index.php?title=Test2.wikipedia.org=revision=277482=158407>
to the test2 page on wikitech. Feel free to review and improve.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Dan Garry]

On 27 January 2016 at 17:16, Legoktm <legoktm.wikipe...@gmail.com> wrote:

> Especially when debugging and testing cross-wiki features, it is
> extremely useful to have two test wikis to use. MassMessage,
> GlobalCssJs, GlobalUserPage, and now cross-wiki notifications were all
> initially deployed using testwiki as the "central" wiki, and test2wiki
> as a "client" wiki.
>

That sounds like a good reason to keep it, especially since global
notifications is an active, ongoing work. Perhaps, as an alternative to
shutting it down, we should just make it clearer that test2.wikipedia.org
is primarily intended for that purpose on that wiki's main page (or
anywhere else thought appropriate). If there's some specific overhead to
keeping test2 alive that might outweigh that benefit, now would seem to be
the time to make it clear. :-)

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New Beta Feature: completion suggester

[Dan Garry]

Hey all,

In the continued quest to make the search bar a better tool, the Wikimedia
Foundation's Discovery Department
<https://www.mediawiki.org/wiki/Wikimedia_Discovery> has put a completion
suggester into Beta Features. The tool functions with search-as-you-type,
with a small tolerance for typos and spacing in finding results. Possible
matches are then displayed as you type in a drop down menu, hopefully
eliminating the need to perform a fulltext search with landing page and
all. You can read more details at mediawiki.org
<https://www.mediawiki.org/wiki/Extension:CirrusSearch/CompletionSuggester>
and use the talk page for now for feedback.

The tool is now available and will only be enabled for the article
namespace for now, and will progress into full production at some point
hopefully in early 2016, depending on feedback. It's going to be important
to get feedback from regular contributors who use search to make sure that
any of the basic feature requests for searching the main space can at least
be addressed while in Beta Features.

Thanks!

Dan

--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Improving CAPTCHA friendliness for humans, and increasing CAPTCHA difficulty for bots

[Dan Garry]

Hey Pine,

Responses in-line.

On 9 December 2015 at 22:14, Pine W <wiki.p...@gmail.com> wrote:

> Hi, just checking to see if CAPTCHA improvements are likely anytime in the
> near future. I notice that
> https://phabricator.wikimedia.org/project/board/225/ shows nothing under
> "Awaiting code review". Is anyone working on this?


To the best of my knowledge, nobody is working on the CAPTCHA system right
now.


> If not, what kind of
> nudge would be necessary to get some resources devoted to CAPTCHA
> improvements?
>

The truthful but (presumably) unsatisfying answer is that you'd have to
convince someone responsible for planning their team's work that working on
the CAPTCHA is more important than what they had planned. That does not
seem likely to happen right now.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Appreciation thread, 2015

[Dan Garry]

On 7 December 2015 at 11:17, Oliver Keyes <oke...@wikimedia.org> wrote:

> Thenk you to Dan and Wes and Tomasz for making the Discovery team a
> good team to be in


<333

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Developer Relations Weekly Summary

[Dan Garry]

On 27 November 2015 at 11:32, Oliver Keyes <oke...@wikimedia.org> wrote:

> This is a very long list of individual links. Could you quickly
> summarise in text what the team has been working on and what they will
> be next?


I agree with this. The weekly update email, as currently structured, is
pretty much unreadable for me. A short summary would work better for me.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2015-10-07 Scrum of Scrums meeting notes

[Dan Garry]

I agree, I also find the email useful.

Considering different lists, this could perhaps be sent to the WMF
Engineering list (engineering@). But, that list is private, and for general
transparency reasons I think it's better to be open about this and continue
to send it to this list.

Dan
On 9 Oct 2015 3:42 pm, "Kevin Smith"  wrote:

> I find the email useful. Each week, I can click on a link and see what
> happened at the meeting. I don't know if this is the best list to send this
> email to, but I do hope to keep receiving it.
>
> Is there a way to "subscribe" to the contents which are posted onwiki? I
> wouldn't expect a subscription on the SoS page[1] to be triggered by a new
> sub-page being added, but if it will be, that's a workaround for me.
>
> Including the entire minutes in email would be convenient for some people,
> but irritating for others. The content cannot really be summarized, so
> including a summary of the minutes probably isn't really possible. Should
> the message body contain a constant sentence describing what SoS is, to
> help people know whether or not they are likely to want to click on the
> link to find out more?
>
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Fri, Oct 9, 2015 at 11:45 AM, Yongmin Hong  wrote:
>
> > After few weeks of reading "link only" email with same title with
> different
> > date, and after much hestitation, I'm finally writing this.
> > Can you please consider putting some summary or such on the mail along
> the
> > link in the mail text, or just publishing it onwiki and NOT sending a
> > one-line recurring email? Just a link sent to list gives no value on the
> > discussion in any kind. See for example, wikimedi...@lists.wm.o's
> Signpost
> > (they provide title for their recurring entries) and wikid...@lists.wm.o
> 's
> > Weekly updates (They send whole volume to list along to the on-wiki
> > newsletter).
> >
> > Thank you for considering.
> >
> > PS. I've just set the filter to automatically 'mark as read' for "Scrum
> of
> > Scrums" in the title, right before sending this email.
> >
> > --
> > revi
> > https://revi.me
> > -- Sent from Android --
> > 2015. 10. 8. 오전 3:28에 "Grace Gellerman" 님이 작성:
> >
> > > https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-10-07
> > > ___
> > > 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 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] What is the status of Cirrus Search development?

[Dan Garry]

Billinghurst,

Thanks for the email. I'd like to address two points in my reply.

Firstly, I'm sure you'll be pleased to hear that development of our search
systems is going strong. In the reorganisation of the Engineering and
Product Development department in April, search definitely gained a bigger
focus. Of the thirteen people in the Discovery Department
<https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery>,
nine of those spend a significant portion of their time on search; the
breakdown by focus being four backend engineers, one frontend engineer (who
joined the team three days ago), one designer, one product manager, and two
data analysts. It's pretty safe to say there's more resources assigned to
search now than there ever has been in the past.

Secondly, I'm a little confused by your assertion that there's been
silence. In fact, on this very list, I've made a number of posts to this
list over the course of the past few months regarding search. Examples: [1]
<https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083008.html>
[2]
<https://lists.wikimedia.org/pipermail/wikitech-l/2015-August/082651.html>
[3]
<https://lists.wikimedia.org/pipermail/wikitech-l/2015-August/082692.html>
[4] <https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/082012.html>.
I've not written a post on this list for all of our work, merely the most
worth announcing. A big communication obstacle has been that we've been
missing a community liaison for a long time, and we're hiring one
<https://boards.greenhouse.io/wikimedia/jobs/99533?t=1hkepi#.VhG8fflVhBc> to
rectify that. I've also talked about search at the monthly metrics meeting
twice, at Wikimania last year, and in several other talks which are
available on the WMF channel on YouTube. Perhaps this was a terminology
issue; were you were expecting me to add "CirrusSearch" to all my
communications? So, I guess I'll respond to your query with my own query:
what do you think we (meaning both the Discovery Department *and* interested
users such as yourself) could've done differently so that you did not have
this perception that there has been silence? One idea that I have had
having posed this question is the availability of a central resource where
all such communications like talks, presentations and relevant emails could
be collated, so that I could answer queries such as yours with a link to
this list. Would that be helpful?

Thanks,
Dan

On 3 October 2015 at 21:28, billinghurst <billinghurstw...@gmail.com> wrote:

> For a while Cirrus Search was the "bee's knees"[1] around here, and we were
> got to the stage that all wikis were moved onto this search functionality.
>
> Then silence.  Complete and utter silence.
>
> Presumably there has been stuff happening out of the public eye, and I am
> not wanting to dig into personal areas, however, the silence on what was a
> key development is very disappointing.  Can we please have an update.
> Thanks.
>
> Regards, Billinghurst
> [1] https://en.wiktionary.org/wiki/bee's_knees
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mentors and projects needed for Outreachy round 11

[Dan Garry]

On 28 September 2015 at 12:02, Brian Wolff <bawo...@gmail.com> wrote:

> WMF is made up of individuals. If there's something that you think
> should be done, why not figure out which team it would normally fall
> under, and politely suggest it to the people on the team that they
> should make it a priority (If it doesn't fall under any team - lets be
> realistic, it probably won't be done)


This is exactly on point.

If someone wants to reach out about a project and doesn't know who to
contact, feel free to contact me and I will try to point you to the right
person if such a person exists.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [reading-wmf] Reading web dashboard

[Dan Garry]

That's awesome. Nice work.

Dan

On 23 September 2015 at 12:55, Jon Robson <jrob...@wikimedia.org> wrote:

> The reading web dashboard -
> https://phabricator.wikimedia.org/dashboard/manage/125/ - has been
> updated to have panels allowing you to easily find easy patches to
> work on (in priority order) and code to review.
>
> I'm using the code to review column as part of Gerrit cleanup day
> since it seems to be a more reliable mechanism to identify what needs
> reviewing.
>
> Please add it to your bookmarks so we are all on the same page. I'm
> going to be encouraging the Wikimedia reading web team to use this
> frequently in our standups.
>
> Happy coding reviewing/submitting! :)
>
> ___
> reading-wmf mailing list
> reading-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>



-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The "other" developers at the Wikimedia Developer Summit

[Dan Garry]

On 15 September 2015 at 06:19, Brian Wolff <bawo...@gmail.com> wrote:
>
> I suppose I'm kind of confused by the scope. We want template creators
> to propose RFCs for architecture changes in MediaWiki?
>

In some senses, template creators are developers just like the rest of us.
They're writing code that affects our sites. They're just doing it in a
different place from most others; on-wiki, rather than in Gerrit. That
divide is, essentially, artificial.

However, you're right that one would not expect such people to propose
architecture changes in MediaWiki; that's not really their domain. However,
to me that does not seem necessary in order to attend the developer summit.
Their perspectives as people involved in the development of MediaWiki and
Wikimedia projects would be welcome.

I think what should be done here is to define exactly what it is we're
hoping to get from the participation of template creators, and what we hope
they get from attending the summit. Perhaps several sessions around
templates should be organised.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] +2 in mediawiki/* for Florian

[Dan Garry]

Well deserved. Florian is an extremely productive developer with a broad
range of interests, so I'm very glad to see this happen.

Thanks,
Dan

On 8 September 2015 at 13:48, Legoktm <legoktm.wikipe...@gmail.com> wrote:

> Hi,
>
> Per [1], I gave Florian +2 powers in mediawiki/* repos. Congratulations!
>
> [1] https://phabricator.wikimedia.org/T105612
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Announcing the release of the Wikidata Query Service

[Dan Garry]

Apologies for cross-posting from wikidata-l, but this may be of relevance
to readers of this list.

-- Forwarded message --
From: Dan Garry <dga...@wikimedia.org>
Date: 7 September 2015 at 15:29
Subject: Announcing the release of the Wikidata Query Service
To: wikidat...@lists.wikimedia.org


The Discovery Department at the Wikimedia Foundation is pleased to announce
the release of the Wikidata Query Service
<https://www.mediawiki.org/wiki/Wikidata_query_service>! You can find the
interface for the service at https://query.wikidata.org.

The Wikidata Query Service is designed to let users run queries on the data
contained in Wikidata. The service uses SPARQL
<https://en.wikipedia.org/wiki/SPARQL> as the query language. You can see
some example queries in the user manual
<https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual>.

Right now, the service is still in beta. This means that our goal
<https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals#Wikidata_Query_Service>
is
to monitor of the service usage and collect feedback about what people
think should be next. To do that, we've created the Wikidata Query Service
dashboard <https://searchdata.wmflabs.org/wdqs/> to track usage of the
service, and we're in the process
<https://phabricator.wikimedia.org/T111403> of setting up a feedback
mechanism for users of the service. Once we've got monitored the usage of
the service for a while and got user feedback, we'll decide on what's next
for development of the service.

If you have any feedback, suggestions, or comments, please do send an email
to the Discovery Department's public mailing list,
wikimedia-sea...@lists.wikimedia.org.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Dan Garry]

On 1 September 2015 at 23:21, Federico Leva (Nemo) <nemow...@gmail.com>
wrote:

> Thanks. So now we'll have two unmaintained extensions, LQT and Flow.


To quote Danny's email directly, "Flow will be maintained and supported".
Your supposition that the extension will be unmaintained is not correct.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery Department A/B testing an alternative to prefix search next week

[Dan Garry]

Hi everyone,

*tl;dr: Discovery Department to run A/B test
<https://phabricator.wikimedia.org/T111078> comparing new search suggester
to prefix search, to see if it can reduce zero results rate.*

As I'm sure you're all aware, the search box at the top right of every page
on desktop uses prefix search to generate its results. The main reason for
this is that prefix search is incredibly fast and performant; that search
box sees a lot of traffic, and it's important to keep it scalable.

However, we know that there are numerous problems with prefix search.
Prefix searches are prone to give you no results; if you make even a slight
typo, then you won't get the result you want. And thus a complex system of
manually curated redirects were born to try to alleviate this navigation
issue. Wouldn't it be nice if we could work towards a solution that doesn't
require the manual curation of redirects, thus freeing up Wikimedians to do
other more meaningful tasks? And make search a bit better in the process,
too? That's a long term goal of mine... emphasis on the long. ;-)

The Q1 2015-17 (Jul - Aug 2015) goal of the Search Team in the Discovery
Department is to reduce the zero results rate
<https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q1_Goals#Search>.
Amongst other things, we've been working to build an alternative to prefix
search <https://phabricator.wikimedia.org/T105746>. Documentation on the
API is pretty light right now because we're scrambling to get it up and
running (but there's a task for that!
<https://phabricator.wikimedia.org/T39>).

An initial version of the suggestion API is now in production on enwiki and
dewiki [1], but is currently not being used for anything. Our initial tests
<https://phabricator.wikimedia.org/T109729> of the API show that it's
incredibly promising for reducing the zero results rate. But we need more
data!

We're planning on running an A/B test on whether this API is better at
reducing zero results. We're targeting beginning on Tuesday 8th September,
for two weeks. This is documented in T111078
<https://phabricator.wikimedia.org/T111078>.

A very important note here is that we currently have no way of
quantitatively measuring result relevance (although we're working on it
<https://phabricator.wikimedia.org/T109482>), so this test will be highly
limited in scope, only measuring the zero results rate. Given the limits of
this, even seeing massive success in this test is not enough to deploy this
API as a full replacement of prefix search; we'd need additional data. But,
that's not stopping us from gathering initial data from this test.

As always, if you have any questions, let me know.

Thanks,
Dan

[1]: The API is actually live on all wikis, but we only built the search
indices for enwiki and dewiki since they're our biggest content wikis and
this is an early test. Attempting to use the API on any other wiki will get
you a cirrus backend error.

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Discovery Department running A/B tests for search suggestions

[Dan Garry]

The results of the A/B test have now been published:
https://meta.wikimedia.org/wiki/Research:Reducing_Zero_Result_Searches_Through_Confidence_Changes

In summary, there was a statistically significant difference, with the
original configuration being better than the new configuration we tried.
However, practically speaking, that change was so small as to be basically
irrelevant, so we intend to stick with the original configuration.

Thanks,
Dan

On 7 August 2015 at 13:32, Pine W wiki.p...@gmail.com wrote:

 Can we call you Discovery Dan? ;)

 Thanks for working on improving search results.

 Pine


 On Fri, Aug 7, 2015 at 1:19 PM, Dan Garry dga...@wikimedia.org wrote:

  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
  ___
  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




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Improving CAPTCHA friendliness for humans, and increasing CAPTCHA difficulty for bots

[Dan Garry]

On 19 August 2015 at 23:06, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 I agree this is an important issue.  It just isn't resourced right now by
 the WMF, as far as I know.


Indeed. There have been numerous discussions about the captcha on this
mailing list over the past few years, but no progress because this issue
just isn't being worked on by anyone.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki user survey and un-reachable users

[Dan Garry]

Mark,

Thanks for organising this survey! I saw that you posted results of the
survey https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey#Results;
thanks for that! I was wondering if you could summarise and share what
you've learned about MediaWiki users from the survey.

Thanks!

Dan

On 18 July 2015 at 08:41, Mark A. Hershberger m...@nichework.com wrote:

 bawolff bawolff...@gmail.com writes:

  Can we add a link to the survey to the top of
  https://www.mediawiki.org/wiki/Download until the end of July?
 
 
  Sounds reasonable. I added a link to the top of that page.

 Thanks!  You did a better job than I would have.

 Mark.

 --
 Mark A. Hershberger
 NicheWork LLC
 717-271-1084


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




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maximum search query length coming soon

[Dan Garry]

A follow-up patch https://gerrit.wikimedia.org/r/#/c/231437/ which
increases the limit to 2,500 was merged; this means the character limit
will be 2,500 characters instead of 300 characters when it goes into
production next week. I expect that this limit will be reset back to 300
within a few weeks. Please see the associated Phabricator task
https://phabricator.wikimedia.org/T107947 for more information.

Dan

On 11 August 2015 at 12:54, Dan Garry dga...@wikimedia.org wrote:

 The patch implementing this functionality
 https://gerrit.wikimedia.org/r/#/c/230646/ was just merged. We
 therefore expect that this will therefore go out to production next week
 with the normal MediaWiki deployment train.

 Dan

 On 10 August 2015 at 14:36, Dan Garry dga...@wikimedia.org wrote:

 Hello!

 The Search Team in the Discovery Department is implementing a maximum
 search query length https://phabricator.wikimedia.org/T107947. There
 are two main reasons to do this:

1. Extremely long queries are almost always gibberish from things
like malfunctioning scrapers. These queries skew our statistics about the
usefulness of our search. Implementing a limit will reduce the magnitude 
 of
skew.
2. Extremely long queries have a disproportionate impact on
performance. On its own this isn't enough, but considering point 1 above,
limiting them is unlikely to impact any actual users. Implementing a limit
will improve performance.

 We've chosen a hard limit of 300 characters. If your query exceeds this,
 you will be told that your query exceeds the maximum length. Based on our
 analysis of typical query lengths
 https://phabricator.wikimedia.org/T107947#1515387, this change should
 impact almost nobody. If you think you'll be adversely affected, please
 reach out to us and we'll work with you to figure something out.

 Thanks!

 Dan

 --
 Dan Garry
 Lead Product Manager, Discovery
 Wikimedia Foundation




 --
 Dan Garry
 Lead Product Manager, Discovery
 Wikimedia Foundation




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maximum search query length coming soon

[Dan Garry]

The patch implementing this functionality
https://gerrit.wikimedia.org/r/#/c/230646/ was just merged. We therefore
expect that this will therefore go out to production next week with the
normal MediaWiki deployment train.

Dan

On 10 August 2015 at 14:36, Dan Garry dga...@wikimedia.org wrote:

 Hello!

 The Search Team in the Discovery Department is implementing a maximum
 search query length https://phabricator.wikimedia.org/T107947. There
 are two main reasons to do this:

1. Extremely long queries are almost always gibberish from things like
malfunctioning scrapers. These queries skew our statistics about the
usefulness of our search. Implementing a limit will reduce the magnitude of
skew.
2. Extremely long queries have a disproportionate impact on
performance. On its own this isn't enough, but considering point 1 above,
limiting them is unlikely to impact any actual users. Implementing a limit
will improve performance.

 We've chosen a hard limit of 300 characters. If your query exceeds this,
 you will be told that your query exceeds the maximum length. Based on our
 analysis of typical query lengths
 https://phabricator.wikimedia.org/T107947#1515387, this change should
 impact almost nobody. If you think you'll be adversely affected, please
 reach out to us and we'll work with you to figure something out.

 Thanks!

 Dan

 --
 Dan Garry
 Lead Product Manager, Discovery
 Wikimedia Foundation




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Where to store OAuth application information?

[Dan Garry]

As many OAuth tools are semi-automated, they're prime candidates for being
interesting ways to help our most active users make contributions on mobile
devices while they're on the go. The OAuth workflow is pretty poorly
designed for this at the moment, but it has a lot of potential.

Generally, mobile experiences are easier to create if the data backing them
is structured data that can be interpreted onto a mobile screen in a way
that's mobile friendly. Putting the information into wikipages, practically
speaking, makes that much harder. Given the other advantages to this also
detailed in this thread, I'd prefer to see us take the more structured
approach. A wikipage could be used if necessary as a fallback for more
information.

Dan

On 10 August 2015 at 18:23, Gergo Tisza gti...@wikimedia.org wrote:

 tl;dr should OAuth [1] (the system by which external tools can register to
 be Wikimedia applications and users can grant them the right to act in
 their name) rely on community-maintained description pages or profile forms
 filled by application authors?

 ---

 Hi all,

 I would like to request wider input to decide which way Extension:OAuth
 should go. An OAuth application needs to provide various pieces of
 information (a description; a privacy policy; a link to the author; a link
 to the application; links to the source code, developer documentation and
 bug tracker; and icons and screenshots). There are two fundamentally
 different approaches to do this: either maintain the information as
 editable wiki pages and have the software extract it from there; or make
 the developer of the application provide the information via some web form
 on a Special:* page and store it in the database. Extension description
 pages are an example of the first approach; profile pages in pretty much
 any non-MediaWiki software are an example of the second one.

 Some of the benefits and drawbacks of using wiki pages:
 * they require very little development;
 * it's a workflow we have a lot of experience with, and have high-quality
 tools to support it (templates, editing tools, automated updates etc.);
 * the information schema can be extended without the need to update
 software / change DB schemas;
 * easier to open up editing to anyone since there are mature change
 tracking / anti-abuse tools in MediaWiki (but even so, open editing would
 be somewhat scary - some fields might have legal strings attached or become
 attack vectors);
 * limited access control (MediaWiki namespace pages could be used, as they
 are e.g. for gadgets, to limit editing of certain information to admins,
 but something like owner can edit own application + OAuth admins can edit
 all aplications is not possible);
 * hard to access from the software in a structured way - one could rely on
 naming conventions (e.g. the icon is always at File:OAuth-application
 name-icon.png) or use Wikidata somehow, but both of those sound awkward;
 * design/usability/interface options are limited.

 Some previous discussion on the issue can be found in T58946 [2] and T60193
 [3].

 Right now OAuth application descriptions are stored in the database, but in
 a very rough form (there is just a name and a plaintext description), so
 switching to wiki pages would not be that hard. Once we have a well-refined
 system, though, transitiong from one option to the other would be more
 painful, so I'd rather have a discussion about it now than a year from now.
 Which approach would you prefer?


 [1] https://www.mediawiki.org/wiki/Extension:OAuth
 [2] https://phabricator.wikimedia.org/T58946
 [3] https://phabricator.wikimedia.org/T60193
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maximum search query length coming soon

[Dan Garry]

Hello!

The Search Team in the Discovery Department is implementing a maximum
search query length https://phabricator.wikimedia.org/T107947. There are
two main reasons to do this:

   1. Extremely long queries are almost always gibberish from things like
   malfunctioning scrapers. These queries skew our statistics about the
   usefulness of our search. Implementing a limit will reduce the magnitude of
   skew.
   2. Extremely long queries have a disproportionate impact on performance.
   On its own this isn't enough, but considering point 1 above, limiting them
   is unlikely to impact any actual users. Implementing a limit will improve
   performance.

We've chosen a hard limit of 300 characters. If your query exceeds this,
you will be told that your query exceeds the maximum length. Based on our
analysis of typical query lengths
https://phabricator.wikimedia.org/T107947#1515387, this change should
impact almost nobody. If you think you'll be adversely affected, please
reach out to us and we'll work with you to figure something out.

Thanks!

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Code of conduct

[Dan Garry]

On 6 August 2015 at 17:17, Matthew Flaschen mflasc...@wikimedia.org wrote:

 We're in the process of developing a code of conduct for technical
 spaces.  This will be binding, and apply to all Wikimedia-related technical
 spaces (including but not limited to MediaWiki.org, Phabricator, Gerrit,
 technical IRC channels, and Etherpad).


The problem you're trying to solve is a difficult one. Thank you for your
efforts.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery Department running A/B tests for search suggestions

[Dan Garry]

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2015-07-29 Scrum of Scrums notes

[Dan Garry]

I saw that a talk done by Discovery was mentioned in these notes. If this
was a reference to the talk that Moiz and I gave, we are fortunate that
Andrew Lih recorded it, and made it publicly available:
https://archive.org/details/videoeditserver-102

Dan

On 29 July 2015 at 11:20, Grace Gellerman ggeller...@wikimedia.org wrote:

 https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-07-29
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Provide a well-performing API to rotate an image

[Dan Garry]

Hi Steinsplitter,

On 16 July 2015 at 09:00, Steinsplitter Wiki steinsplitter-w...@live.com
wrote:

  Out of curiosity what is the problem with the bot that prevents it from
  working?
 It is very old and bad written and needs a complete rewrite.


That doesn't really answer Brion's question. What would prevent it from
continuing to run while it is being rewritten?

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Search engine indexing of userspace - has something changed?

[Dan Garry]

Hello!

In this thread
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Userpage_drafts_shown_in_search_engines,
there was a discussion about indexing of user space by search engines. In a
nutshell, user space pages are not subject to content policies so that
users can write drafts freely, and having those pages indexed by search
engines like Google is viewed as problematic since those pages can seem
fairly official.

I seem to recall that it was not the default in the past that user pages
were indexed by search engines. I'm trying to figure out if there's some
other cause for this that's happened recently, because I'd prefer to avoid
piling hacks on and not address the root issue.

Does anyone know of anything that's changed recently that might've changed
the way that search engines index user space?

Thanks,
Dan

-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Yandex?

[Dan Garry]

On 2 July 2015 at 12:55, Legoktm legoktm.wikipe...@gmail.com wrote:

 I am also interested in the answer to Nemo's question about whether this
 is the first piece of proprietary software ever entering use in the
 Wikimedia projects land?


The iOS app uses system libraries provided by the iOS SDK for a variety of
essential functions, and obviously both the devices and the technology
stack are proprietary. That's just the price we pay for wanting to be part
of that ecosystem. The app and all the non-system third party libraries it
uses (i.e. anything we reasonably have control over) are open source.

The Android app is the same as the iOS app, except the Android operating
system is open source and published under the Apache licence. That said,
Android devices typically ship with proprietary software installed on them
which the app does use, such as Google Play which is used for delivery of
the application to most users.

Dan

-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Lightning Talks June 23

[Dan Garry]

Never mind. I followed the link to join and it guided me through the
download process.

Dan

On 23 June 2015 at 10:57, Dan Garry dga...@wikimedia.org wrote:

 On 23 June 2015 at 10:46, Rachel Farrand rfarr...@wikimedia.org wrote:

 Instructions to install BlueJeans: http://bluejeans
 .
 force.com/KnowledgeSearch/articles/Knowledge_Base/Joining-a-meeting-from-the-Browser-on-your-laptop


 This link is a redirect, which takes you to a page that seems to not tell
 you how to install BlueJeans. What's the correct link?

 Thanks,
 Dan

 --
 Dan Garry
 Product Manager, Discovery
 Wikimedia Foundation




-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Lightning Talks June 23

[Dan Garry]

On 23 June 2015 at 10:46, Rachel Farrand rfarr...@wikimedia.org wrote:

 Instructions to install BlueJeans: http://bluejeans
 .
 force.com/KnowledgeSearch/articles/Knowledge_Base/Joining-a-meeting-from-the-Browser-on-your-laptop


This link is a redirect, which takes you to a page that seems to not tell
you how to install BlueJeans. What's the correct link?

Thanks,
Dan

-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Modernizing our content platform: Kick-off meeting on Tuesday

[Dan Garry]

: Tuesday, June 23rd, 13:00 - 14:30 PT [3]*
 *Where: *A *hangout* link will be posted here before the meeting;
 room 37 in the office.

 If you can't attend, then please have a look at our current notes and
 let us know what you think [2].

 Gabriel Wicke, Daniel Kinzler, Brion Vibber, Tim Starling, Roan
 Kattouw, Ori Livneh


 [1]: https://phabricator.wikimedia.org/T96903
 [2]: https://phabricator.wikimedia.org/T99088
 [3]:
 http://www.timeanddate.com/worldclock/fixedtime.html?msg=MediaWiki+content+platform+kick-offiso=20150623T13p1=224ah=1am=30




 --
 Gabriel Wicke
 Principal Engineer, Wikimedia Foundation

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering



 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering





 --
 Gabriel Wicke
 Principal Engineer, Wikimedia Foundation

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Feedback requested on our search APIs

[Dan Garry]

Do you use our search API? If so, I'd like to hear from you!

The Discovery Department
https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery at
the Wikimedia Foundation is tasked with building a path of discovery to
relevant and trusted knowledge. In line with that, one of our primary
responsibilities is to ensure that our search APIs are stable, fast, and
easy to use. We'd love to hear from the people that are using our APIs, so
we can learn what you love about them, what frustrates you, and what we can
do to improve them for you.

I'd prefer that you keep the comments about the API itself rather than the
relevance of the results it returns; I plan to start a separate thread
about the result relevance, since they're separate topics.

If you have some feedback, please reply in this thread or reach out to me
privately.

Thanks!

Dan

-- 
Dan Garry
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [editing-department] Read the VisualEditor process review

[Dan Garry]

And, as a person that is not involved in the development of VisualEditor in
any way but knows many of the VisualEditor Team quite well, I also found
this very interesting. Thanks for putting it together!

Dan

On 6 June 2015 at 21:18, Risker risker...@gmail.com wrote:

 As a non-technical volunteer, I've drifted in and out of the VE discussion,
 and have participated at wildly variable levels over the past few years.

 I found this to be a very interesting and informative read - especially as
 it came from people new to the entire history. It's good to have fresh eyes
 on a situation.  Thank you for your work on this, it was quite
 enlightening.

 Risker/Anne

 On 7 June 2015 at 00:09, Neil P. Quinn nqu...@wikimedia.org wrote:

  Hey Greg!
 
  Yes, this is meant to be a one-time process. We've been spending a
  significant proportion of our time on it ever since we joined in
 mid-April
  (I'd say about 30% for me, and probably more for Joel)—too much to make
 it
  a regular thing. And hopefully, if we manage to address these problems,
 we
  won't find them replaced by new ones the very next quarter :)
 
  Thanks for the question—it feels great to know that someone is out there
  reading our child of the mind!
  —
  Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF,
  product analyst
  Wikimedia Foundation
  +1 (202) 656 3457
 
  On Sat, Jun 6, 2015 at 3:34 PM, Greg Grossmeier g...@wikimedia.org
  wrote:
 
   quote name=Neil P. Quinn date=2015-06-05 time=16:56:07 -0700
Hello everybody!
   
For the past couple months, Joel Aufrecht and I have been working on
 a
project to document and improve the VisualEditor team's processes; we
just published a draft of our report
https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on
mediawiki.org. If you're interested, please read it over and, of
course, shout at us on the talk page if we wrote anything stupid.
  
  
   Neil et al, this is great! Thanks for the very informative read, even
 as
   someone who works closely with the VE team on a semi-daily basis (at
   least!). I think it is great that the time and energy was devoted to
   developing this report.
  
   The plan at [0] suggests that this is a one-time process with a
   conclusion (which is good), thus it isn't tied in, explicitly, with the
   quarterly goal planning process, correct?
  
  
   Best,
  
   Greg
  
   [0] 
  
 
 https://www.mediawiki.org/wiki/VisualEditor/2015_Team_Process_Review#Plans
   
  
   --
   | 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




-- 
Dan Garry
Product Manager, Search and Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Simplifying the WMF deployment cadence

[Dan Garry]

Awesome! This will make many teams very happy since they'll be moving
faster.

What's the criteria by which you will evaluate the success of this?

Thanks,
Dan
On 27 May 2015 10:19 pm, Greg Grossmeier g...@wikimedia.org wrote:

 Hi all,

 Starting the week of June 8th we'll be transitioning our MediaWiki +
 Extensions deployment cadence to a shorter/simpler one. This will begin
 with 1.26wmf9.

 New cadence:
 Tuesday: New branch cut, deployed to test wikis
 Wednesday: deployed to non-wikipedias
 Thursday: deployed to Wikipedias

 This is not only a lot simpler to understand (wait, we deploy twice on
 Wednesday?) but it also shortens the time to get code to everyone (2 or
 3 days from branch cut, depending on how you count).

 == Transition ==
 Transitions from one cadence to another are hard. Here's how we'll be
 doing this transition:

 Week of June 1st (next week):
 * We'll complete the wmf8 rollout on June 3rd
 * However, we won't be cutting wmf9 on June 3rd

 Week of June 8th (in two weeks):
 * We'll begin the new cadence with wmf9 on Tuesday June 9th


 I hope this helps our users and developers get great new features and
 fixes faster.

 Greg

 endnotes:
 * The task: https://phabricator.wikimedia.org/T97553
 * I'll be updating the relevant documentation before the transition

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

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering

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

Re: [Wikitech-l] Welcome Michael Holloway to the Mobile App Team

[Dan Garry]

Glad that you're joining us, Michael! Looking forward to working with you.
:-)

Dan

On 30 March 2015 at 15:53, Tomasz Finc tf...@wikimedia.org wrote:

 I’m pleased to announce that Michael Holloway joins Wikimedia today as
 a Software Engineer for the Mobile App Team. Michael is based in Ann
 Arbor, Michigan, and will be working with us remotely. He'll join
 Dmitry  Bernd to push our native Android development forward [1].

 Michael has longstanding interests in the technical and social aspects
 of information technology, and turned to software development
 professionally after several years in the legal field. He believes
 passionately in the revolutionary potential of free and open access to
 information, and in Wikimedia’s vision of a world in which all can
 share freely in the sum of human knowledge. Michael looks forward to
 delighting users of the Android app, and to helping grow and diversify
 Wikimedia’s user base.

 When he’s not behind a keyboard, Michael spends his time bicycling,
 cooking curries, and sampling craft brews.

 Please welcome Michael!

 --tomasz

 [1] - https://play.google.com/store/apps/details?id=org.wikipedia

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Needs Volunteer priority field value in Phabricator

[Dan Garry]

As the famous poet Monte Hurd once said... SHIP IT!

Dan


On Wednesday, February 25, 2015, Brion Vibber bvib...@wikimedia.org wrote:

 Patch to change 'Needs Volunteer' back to 'Lowest' 
 https://gerrit.wikimedia.org/r/#/c/192205/ has six +1s but nobody's +2'd
 it. (I would but I don't have +2 in that repo.)

 Do we have enough consensus to continue on with this change or are we still
 collecting feedback on https://phabricator.wikimedia.org/T78617?

 -- brion

 On Fri, Feb 13, 2015 at 9:42 AM, Andre Klapper aklap...@wikimedia.org
 javascript:;
 wrote:

  Apparently the idea to rename the Priority field value from Lowest in
  Bugzilla to Needs Volunteer in Phabricator created more confusion than
  expected. I am sorry for that - wasn't intended.
 
  To fix that, there are two questions that welcome input in
  https://phabricator.wikimedia.org/T78617 :
 
 
  1) Our Phabricator currently offers six levels of prioritization. See
 
 
 https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels
  Do project maintainers / devs really feel a need for planning to
  differentiate between low priority and one level below that?
  Or could we reduce our six levels with five levels?
 
  2) If there is a need for a level below low: Let's rename Needs
  Volunteer back to Lowest (Looking at the proposed names in T78617,
  Lowest seems to be the least confusing term / smallest evil.)
 
 
  If you feel like helping make a decision by adding some *additional*
  arguments based on your experience, please raise your voice in T78617
  after reading the existing comments and arguments in that task.
 
  Thank you for your help!
  andre
  --
  Andre Klapper | Wikimedia Bugwrangler
  http://blogs.gnome.org/aklapper/
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcing service-runner, a startup module / supervisor for node services

[Dan Garry]

On 23 February 2015 at 16:46, S Page sp...@wikimedia.org wrote:

 I'm so excitoid


S, you just made my day!

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] E-mail login to wiki - needs feedback

[Dan Garry]

On 20 February 2015 at 08:52, devunt dev...@gmail.com wrote:

 We should consider some edge cases like:


I disagree.

This is not an easy problem. We know that. The reason there's been so much
talk and so little action on this because we insist on repeating all the
reasons why this is hard every time this point is raised, and everyone gets
put off.

Build something that works for some subset of the use cases first, then we
can worry about edge cases and scaling.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] E-mail login to wiki - needs feedback

[Dan Garry]

On Thursday, February 19, 2015, Tony Thomas 01tonytho...@gmail.com wrote:

 I personally think its a must-have for MediaWiki, as e-mail
 address is easy to remember than a complex username.


It's also important because users of mobile devices are very used to this
design pattern for logging in to apps, and having it in the mobile apps is
blocked by not having it in MediaWiki.


 Currently multiple
 users can sign-up with the same e-mail id - which would possibly be a
 blocker, and can be fixed.


I wouldn't even try to tackle that problem for a first pass at this.

If we can get login with username working for the case where there is a
one-to-one match between email and password, that's a *huge* step forwards.
The many-to-one case can follow afterwards.

Dan


-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google thinks the Anonymous entry on enwp is hacked

[Dan Garry]

When I logged into the webmaster tools and followed their instructions to
resolve the issue it said that en.wikipedia.org had no security issues.

I guess whatever happened has been fixed and we just need to wait for it to
resolve.

Dan

On 13 February 2015 at 20:57, John Mark Vandenberg jay...@gmail.com wrote:

 Google is showing their This site may be hacked. note when showing
 the enwp article about Anonymous, with a link to
 https://support.google.com/websearch?p=ws_hacked

 https://www.google.com/search?q=Anonymous+group

 Found via

 http://thestack.com/anonymous-this-site-may-be-hacked-wikipedia-120215

 --
 John Vandenberg

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Scrum of Scrums notes 2015-02-11

[Dan Garry]

Both pages you linked have a table of contents for me.

Dan

On 11 February 2015 at 11:01, Dan Andreescu dandree...@wikimedia.org
wrote:

 https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-11

 If anyone with better wiki kung fu than me could take a look and figure
 out why the table of contents is not rendering on that page like it does on
 all the other [1] ones, I would appreciate it.

 [1] https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-04

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




-- 
Dan Garry
Associate Product Manager, Mobile Apps
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

[Dan Garry]

On 4 February 2015 at 08:40, Bryan Davis bd...@wikimedia.org wrote:

 +1 This sort of major design change is exactly the sort of thing that
 I think the RfC process is good at helping with. Start with a straw
 man proposal, get feedback from other engineers and iterate before
 investing in code changes. The sometime frustrating part is that
 feedback doesn't always come as fast as Product and/or the team would
 like but we can try to accelerate that by promoting the topic more
 often.


Our plan is to have a spike to experiment to determine whether there are
any early roadblocks in the proposed solution. We're not going to consider
commiting to the RESTBase/Node.js path until after that. It seems quite
reasonable to me to also have an RfC alongside our experimentation to try
to think up alternative solutions, and invest in experimenting with those
solutions too, because we're definitely open to anything that helps us move
forwards at this stage.

We'll start writing up an RfC and see where it takes us.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
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

[Dan Garry]

On 4 February 2015 at 15:00, Brion Vibber bvib...@wikimedia.org wrote:

 In general I'm in favor of more ad-hoc project-specific teams rather than
 completely siloing every service to the Services group, or every mobile UI
 to the Mobile group.


Agreed. This also ensures that the service exactly meets the functional
requirements, no more and no less.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
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

[Dan Garry]

Hey Kunal,

Responses in-line.

On 3 February 2015 at 21:09, Legoktm legoktm.wikipe...@gmail.com wrote:

 Is there a bug for this and the other issues? I'm subscribed to [1], but
 I don't see anything like the issues you've mentioned on it.


There's this, which documents some of them, but it's more descriptive of a
specific proposed solution: https://phabricator.wikimedia.org/T87824

I welcome any other ideas that anyone has for solving our problems. We're
not tied to a specific solution.


 What are read more recommendations?


When you scroll to the end of an article, we give three suggestions as to
what you could read next. The suggestions are generated quite naively by
running a full text search using the current page's title as a query. Our
metrics have shown a lot of positive engagement with the feature so far.

Here's a screenshot on [[Bern]]: http://i.imgur.com/qnHcsdT.png


 Is there an actual instance where an API change has broken an app or is
 this merely a hypothetical concern? Speaking as an API developer, we
 occasionally have to make breaking changes, and if we broke something
 too fast, it would be nice to have feedback if that was the case so we
 can improve in the future.


I'm referring to a possible upcoming breaking change in MobileFrontend,
which is the API we depend on for our content. A certain API parameter may
be removed. Since the apps were made under the assumption that that value
would always be in the API response, the app doesn't handle this issue
well. It leaves users unable to see file pages.

This issue is particularly prominent on apps since if the user never
updates the app then they'll never get the fix.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Dan Garry]

*tl;dr: Mobile Apps will, in partnership with the Services, investigate
building a content service for the Mobile Apps.*

The Mobile Apps Team currently has quite a few pain points with the way we
fetch article content currently:

   - We have to make a lot of API requests to load an article: article
   HTML, lead image, read more recommendations, and more
   - We send the user HTML that we then discard, needlessly increasing data
   usage
   - We do transforms to the HTML in JavaScript on the client side, which
   causes code duplication across the apps and degrades user-perceived
   performance
   - Trivial changes to the API (e.g. renaming a parameter) can break the
   app which is problematic since apps can't be hotfixed easily

To address these challenges, we are considering performing some or all of
these tasks in a service developed by the Mobile Apps Team with help from
Services. This service will hit the APIs we currently hit on the client,
aggregate the content we need on the server side, perform transforms we're
currently doing on the client on the server instead, and serve the full
response to the user via RESTBase. In addition to providing a public API
end point, RESTBase would help with common tasks like monitoring, caching
and authorisation.

So the Mobile Apps Team is going to spend a bit of time investigating
whether using RESTBase with Node.js is an option for building a content
service for the Wikipedia app to replace our current method of retrieving
article content. Our initial scope for this is feature parity with our
current content retrieval method.

Our action items are as follows:

   - Wait for RESTBase to be deployed.
   - Timescale: Weeks
  - Owner: All of us :-)
   - Figure out what information the service should serve for the first
   iteration (i.e. for feature parity) and what APIs it needs to hit to do that
   - Timescale: Wed 4th Feb
  - Owner: Dan Garry
   - Start implementing the service and see whether it meets our needs
   - Timescale: Planning a spike for next apps sprint (16th Feb - 27th Feb)
  to perform initial investigation
  - Owner: Currently undecided engineer from Mobile Apps, with Services
  engineers serving as consultants

As always, feel free to ask if there are any questions.

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

Re: [Wikitech-l] Brion's role change within WMF

[Dan Garry]

On 20 January 2015 at 08:43, Siebrand Mazeland siebr...@kitano.nl wrote:

 This is fantastic news, although I fear Mobile may miss you at times.


We absolutely will.

However, we are excited that Brion is placing himself somewhere where he
can continue to be our ally and push forward the infrastructure that
Mobile, like many of us, are dependent on to succeed.

Enjoy yourself, Brion!

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Corey Floyd as Software Developer to the Apps Team

[Dan Garry]

Welcome to the team!

Dan

On 12 January 2015 at 10:25, Tomasz Finc tf...@wikimedia.org wrote:

 I am pleased to announce that Corey Floyd joins WMF this week as a
 Software Engineer for the Mobile App Team.

 Corey is based in Philadelphia where he will be working remotely. He
 previously worked as a mobile consultant, during which he developed
 iOS apps for organizations like the Human Rights Campaign, Vimeo, and
 Johnson  Johnson. Before joining Wikimedia, Corey spent the last year
 helping to stand up the new mobile team at Urban Outfitters.

 Corey is passionate about creating great user experiences and building
 software that people love to use.

 Prior to being an engineer, Corey was a meteorologist in the Air Force
 and spent most days forecasting rain in Western Europe.

 When not working, he reads way too much Apple news, plays a little
 guitar, watches Scrubs on Netflix, and is learning to box. Both he and
 his wife love to travel.

 Corey is excited to join the Mobile Team as they take the Wikipedia
 apps to the next level.

 Please Welcome Corey

 --tomasz

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Welcome Brian Gerstle as Software Developer to the Apps Team

[Dan Garry]

Welcome to the team!

Dan

On 12 January 2015 at 10:25, Tomasz Finc tf...@wikimedia.org wrote:

 I am pleased to announce that Brian Gerstle joins WMF this week as a
 Software Engineer for the Mobile App Team.

 Brian comes to us from Spotify, where he worked as an iOS
 developer—with a brief stint as a Quality Engineer.  He's really
 excited to join the team and contribute to the WMF mission by
 polishing and innovating on the Wikipedia iOS experience for both
 readers and contributors.  He's also looking forward to working on an
 open-source project and hopes to get more involved in the FOSS
 community.

 Brian lives in Miami, Florida with his wife and 2 dogs.  Among his
 many interests are: music (especially jazz), audio (was a recording
 studio technician in a former life), science, health, and
 sci-fi/fantasy (just started reading Name of the Wind).

 Please Welcome Brian

 --tomasz

 ___
 Wmfall mailing list
 wmf...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wmfall




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stance on Social Media

[Dan Garry]

On 9 January 2015 at 15:26, Jared Zimmerman jared.zimmer...@wikimedia.org
wrote:

 I'd be really interested knowing how our inbound referral traffic from
 social sites differs from that from inbound traffic to social and news
 sites from social referral traffic. When we talk about reader decline, we
 rarely talk about how much a small increase in social referrals could
 offset that.


Tweet a Fact functionality may be able to answer some of these questions;
there is a ?source=app appended to the URL so we can see what kind of
traffic these shares are driving.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stance on Social Media

[Dan Garry]

If you're interested, the Wikipedia app has functionality which lets you
share interesting snippets of articles to the social medium of your choice.
We have special Tweet a Fact functionality in alpha on Android; when you
highlight text in the app, and you tap the little chat bubble in the menu,
it creates a bitmap and posts it to the social medium of your choice.

Here's an example of what it's like if you do it on the Bern article:
https://twitter.com/danjgarry/status/553689032455360512

The Android and iOS SDKs include a lot of functionality for this kind of
social sharing since it's an established user workflow for mobile apps.
It's relatively easy for us to build this out.

You can test the Android alpha by going to http://android-builds.wmflabs.org on
your Android device and downloading the APK.

Dan

On 9 January 2015 at 11:24, Rob Moen rm...@wikimedia.org wrote:

 Currently our approach on social media is that Social media websites
 aren't useful for spreading news and reaching out to potential users and
 contributors. [1] I challenge this though.  Is it really true?   Twitter
 has 254 million active monthly users, with 500 million tweets sent per day
 [2], Facebook has 1.35 billion active monthly users users. [3]


 I know there are many active Wikipedians who frequent both of these sites.
 Should we be more actively encouraging people to share?


 The history of the Social Media page indicates this was added as an
 ‘initial
 dump’ back in November of 2011. [4]  But I wonder if it might be worth
 revisiting or refreshing this decision in light of the current world we
 live in.


 What do others think?   What would the reaction be to a sharethis.com type
 service where any site could engage ?   Would this be more valuable on
 mobile than than desktop?



 1: https://www.mediawiki.org/wiki/Social_media

 2: https://about.twitter.com/company

 3: http://newsroom.fb.com/company-info

 4:

 https://www.mediawiki.org/w/index.php?title=Social_mediadiff=1318877oldid=458857
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visibility of action in API for deleted log entries

[Dan Garry]

Speaking from my experience as an oversighter, I find it a bit strange that
when you oversight something, information that is hidden in the UI is not
hidden in the API. That notwithstanding, there is nothing particularly
private about the information that is shown in the API only (i.e. the type
of the action), but I found it strange.

I also find it strange that the fact that this information is still
available via the API is not mentioned in the interface. I've been an
oversighter for many, many years, and I never knew that this information
could be retrieved via the API.

Personally, I prefer the way things are after Chris's change. It makes the
UI and API more consistent with each other.

That said, given that there is no particularly private information given
out in the API response, I don't think it's worth complaining about Brad's
patch. It's not the way I'd prefer it to be, but it doesn't personally
strike me as overtly incorrect or as causing any real problems.

Dan

On 1 December 2014 at 17:30, Chris Steipp cste...@wikimedia.org wrote:

 Hi list,

 I wanted to get some feedback about
 https://phabricator.wikimedia.org/T74222.
 In the last security release, I changed the return of the api to remove the
 action for log entries that had been revdeleted with Hide action and
 target. However, ever since 2009 / r46917, we've assumed that Hide action
 and target didn't mean the actual action field in the db, but rather the
 target and the text of the message about the action, which might include
 other parameters. So the message about what's being hidden and the intended
 protection of that option could have slightly different interpretations.

 I'd like to hear if anyone has intended for the actual log action to be
 deleted / suppressed. If not, I'm happy to revert the recent patch, and
 we'll just update the wording in the deletion UI to be more clear about
 what is being removed.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Dan Garry]

On 6 November 2014 21:06, Tim Starling tstarl...@wikimedia.org wrote:

 I think it would be best if we just removed the captcha, rather than
 deploying a new engine.


I'd absolutely love that.

On the mobile app, almost everyone who tries to create an account is shown
a captcha. Of those people, 31% of them get the captcha wrong on their
first try, and 17% of those people give up trying to create an account. The
success rate for account creation is less than 50%, in no small part due to
the captcha.

I'd love to eliminate giving our users that headache.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Dan Garry]

On 6 November 2014 22:39, Pine W wiki.p...@gmail.com wrote:

 I'm interested both in improving our user stats and stamping out spambots.
 Dan, how do we know that those 17 percent were predominantly humans?


We don't know for certain that they're human. That said, why would a
spambot try to use the Wikipedia app? You're only creating extra hurdles
for yourself by doing so. I've seen no evidence so far that anyone except
humans use the Wikipedia app. Well, and Googlebot, but it reports itself to
us using a special user agent and also only reads articles. :-)

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Marielle Volz joins Wikimedia as Software Developer

[Dan Garry]

On 27 October 2014 11:48, Tomasz Finc tf...@wikimedia.org wrote:

 During a brief period of insanity (i.e. all of her undergraduate and
 graduate education) she considered becoming a Scientist, before
 realizing it's actually more fun to sit inside on a computer all day
 editing Wikipedia articles about Science rather than Doing Science and
 actually going outside, which, with the advent of vitamin D
 supplementation, is wholly unnecessary, and perhaps one could even
 say, *inadvisable*.


No kidding. I've had the same revelation myself. ;-)

Welcome Marielle.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Looking for project status updates

[Dan Garry]

Pine,

Do you read the monthly engineering reports? They're useful to give you a
high-level insight into the engineering efforts going on at the Wikimedia
Foundation. For example, the September report is currently being written
here:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/September

Thanks,
Dan

On 22 October 2014 23:56, Pine W wiki.p...@gmail.com wrote:

 Hi Terry (or anyone who knows the answers),

 It's been awhile since I've noticed a status update from the Growth that
 team through the EE list or this list. The Meta page implies that the
 Growth team disbanded on October 3. Is that true, and if so, does WMF still
 have a single person leading tech-based growth initiatives?

 Also, who is PMming Winter?

 It would be helpful to have a unified high-level overview of the status,
 relationships, plans, strategic goals, and contacts for projects like:

 VE
 Winter
 Flow
 Citoid
 MV
 SUL
 Growth
 HHVM
 Mobile web
 Mobile apps
 etc.

 Thanks (:

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] {{TemplatesThatWorkOnMobile}}

[Dan Garry]

Jon,

Regarding editing specific templates, I'll echo Brion here. If a template
is causing difficulties for your work and you feel like you know enough to
fix it, then fix it! That's the wiki way. If you don't have the rights to
edit the template (e.g. because it's protected), then speak to Tomasz and
he will try to get you the rights that you need.

Regarding the broader issue of the fact that there are thousands of these
kinds of templates, I will also echo Brion! We need to make mobile testing
more visible to those who are creating those templates.

Dan

On 7 October 2014 15:14, Brion Vibber bvib...@wikimedia.org wrote:

 On Tue, Oct 7, 2014 at 3:02 PM, Jon Robson jrob...@wikimedia.org wrote:

  On mobile we continuously get bugs related to inline styles in
  templates. For example:
  https://bugzilla.wikimedia.org/show_bug.cgi?id=68001
 
  When these happen we usually spend time investigating, discover it is
  because of a troublesome inline style in the template and then we
  communicate this on the template talk page [1]
 
  However, rarely do these get replies and rarely does anything get fixed.
 
  Am I doing something wrong? Should I be posting these problems
  elsewhere? It seems like a lot of templates do not have active
  maintainers.
 

 The wiki way is not to ask and wait for someone else to act, but to act
 directly in good faith and communicate what you did and why so that if
 there is disagreement it can be resolved afterwards.

 Ultimately if we're unwilling to help edit and maintain the content and
 style of the wikis, we're going to be stuck working around bad styles
 forever.


  There has been an RFC [2] open for ages that when solved I hope will
  lead to lots of discussions between developers and template
  maintainers but right now it seems even without the tools we are
  failing.
 
  How can we get better at making our template styles more mobile friendly?
 
  [2]
 
 https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates
 

 I'd like to revitalize this one; I'll do some testing this weekend and put
 it on the agenda for next week's RfC.

 I'm also interested in some kind of easy preview how this page will look
 on mobile in the editor, which would probably be a separate thing...

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] {{TemplatesThatWorkOnMobile}}

[Dan Garry]

As members of the Mobile Team, it's our job to make the mobile platform the
best it can be. If we have to edit templates to do that because they're
causing significant display issues that are disrupting the platform, so be
it. For example, let's say pie charts are completely broken on mobile and
display incorrectly. Should we not fix it because it's only aesthetic?

Jon is very capable and his restraint in this matter demonstrates that. I
trust him, like I would trust any administrator, to know when directly
editing is appropriate (e.g. templates protected simply to fend off
vandalism), and when making an edit request is more appropriate (e.g.
particularly complex templates which need review of changes).

Dan


On Tuesday, October 7, 2014, Brian Wolff bawo...@gmail.com wrote:

 On Oct 7, 2014 10:03 PM, Dan Garry dga...@wikimedia.org javascript:;
 wrote:
 
  Jon,
 
  Regarding editing specific templates, I'll echo Brion here. If a template
  is causing difficulties for your work and you feel like you know enough
 to
  fix it, then fix it! That's the wiki way. If you don't have the rights to
  edit the template (e.g. because it's protected), then speak to Tomasz and
  he will try to get you the rights that you need.

 Umm, is that really a good idea? Protected templates are protected for a
 reason usually (at least on projects that ive worked on. Can't speak for
 enwiki). {{Editprotected}} seems like a better option for those, even if
 simply for political reasons, and if you find yourself making a lot of such
 requests  why not ask the community how it feels about giving out advanced
 rights.

 Imho, wmf granted advanced rights should be reserved for more serious
 issues than purely asethetic ones.

 I agree with the setiment of just being bold for unprotected templates.

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



-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Registration Open: MediaWiki Developer Summit 2015

[Dan Garry]

Do staff have to register this, or are we assumed to be attending?

Thanks,
Dan

On 18 September 2014 14:39, Rachel Farrand rfarr...@wikimedia.org wrote:

 Hello!

 We are happy to announce the MediaWiki Developer Summit 2015, which will be
 taking place on January 26th and January 27th in San Francisco, California,
 USA.

 Registration is now open.

 Details about the MediaWiki Developer Summit 2015 and a link to the
 registration form can be found here:

 https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015

 Hope to see you in San Francisco!

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia engineering report, July 2014

[Dan Garry]

Me too.

Dan


On Tuesday, 26 August 2014, Chad innocentkil...@gmail.com wrote:

 On Tue, Aug 26, 2014 at 10:04 AM, Jeremy Baron jer...@tuxmachine.com
 javascript:;
 wrote:

  On Tue, Aug 26, 2014 at 4:55 PM, Arthur Richards
  aricha...@wikimedia.org javascript:; wrote:
   Not sure what the problem is but the report on mw.o is borked. See
   screenshot:
   https://www.mediawiki.org/wiki/File:Aug2014-monthlyreport-busted.png
 
  Transient error on fetching CSS asset from bits?
 
  Works for me. (but i've seen something like that before on other pages. I
  think)
 
 
 I'm definitely getting the same as Arthur.

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



-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia engineering report, July 2014

[Dan Garry]

Looks good to me. Thanks Guillaume. :-)

Dan


On 26 August 2014 11:05, Guillaume Paumier gpaum...@wikimedia.org wrote:

 On Tue, Aug 26, 2014 at 6:55 PM, Arthur Richards
 aricha...@wikimedia.org wrote:
  Not sure what the problem is but the report on mw.o is borked. See
  screenshot:

 This should now be fixed; Thank you for the bug report, and my
 apologies for the inconvenience :)

 --
 Guillaume Paumier

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




-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] User rating for beta features (was Re: Help in modifying Template:Extension to support user ratings)

[Dan Garry]

On 20 August 2014 09:16, Quim Gil q...@wikimedia.org wrote:

 I'm not sure how related is this, but Article Feedback allowed user rating
 + comment, and it was deployed in Wikimedia servers. Editors didn't find it
 that useful for regular articles (too much extra work processing too little
 value feedback on top of Talk pages), but maybe this could (with small or
 not so small adaptation, I don't know) in the very specific context of a
 beta feature page.


Speaking as someone who's been the product owner of a beta feature, I know
I'd find a star rating for a beta feature totally useless. Star ratings
don't tell you anything about *why* a user likes or dislikes a feature, so
I have no information to go off.

In terms of getting feedback from comments, you're right that that's
useful. But I can get that right now by going to the discussion page of the
beta feature. Bear in mind that the Hovercards talk page on mediawiki.org
was, for a while, the most active Flow page *across the entire cluster.*

So, I'm left a little unclear what the proposed improvement actually is.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] need for an app? (was: Future platforms, devices, and consumers)

[Dan Garry]

On 16 August 2014 00:29, svetlana svetl...@fastmail.com.au wrote:

 We don't need apps.


Read this to find out why you're wrong:
http://gigaom.com/2014/08/01/wikipedias-new-apps-are-good-for-you-but-theyre-even-better-for-the-developing-world/

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l