Re: [Wikitech-l] The future of UploadWizard

[Jon Katz]

Hey Folks,
I just wanted to flag that we heard the question and had circle up to get
you an informed answer as the answer spans several teams.  The most literal
answer to Ostrzyciel's email is:  "no, there are no plans or resources
allocated to doing anything other than fix breaking upload wizard bugs on
Commons".  The longer answer is that we know we have to improve the upload
wizard and it's a matter of resourcing and prioritization.  The caveat is
that it is unlikely that the WMF will work on an upload wizard that is
specific to the needs of 3rd party wikis, anytime soon.  For the Commons
use case, I think it's much more likely.

Many of us in product have been pushing for a team dedicated to multimedia
improvements for several years, but as I hope you can understand, other
priorities have taken precedence. You are free to disagree that project X
is more important than UW, as these are decisions for which there is plenty
of educated opinion, but no right answer.  Even on this year's community
wishlist
<https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Multimedia_and_Commons>,
upload Wizard improvements did not fit in the top 5 most-voted improvements
for multimedia. Again, we want to work on this, it's just that other work
has been prioritized above it and, believe it or not, at our size, we are
stretched pretty thinly.

I don't have the answer to the stewardship question, K Peachey.  I'm
copying Jean-Rene who chairs that group in case he has any insights.

Thanks,

Jon Katz
Director of Product

On Thu, Feb 4, 2021 at 7:09 AM Strainu  wrote:

> În joi, 4 feb. 2021 la 16:54, Bartosz Dziewoński  a
> scris:
> >
> > On 2021-02-03 23:33, Strainu wrote:
> > > One thing that puzzles me in that ticket is this phrase from Mark
> > > Traceur: "It might be better to look at something (slightly) more
> > > modern, like the upload dialog in core". Does anyone know what that
> > > dialog is? AFAIK the uploader in core (Special:Upload) hasn't changed
> in
> > > decades, except maybe for the look of the buttons. Its usability is
> > > rubbish compared to UW. Wikis used to (no, actually they still do)
> > > customize it using the uselang param,which messes with the user's
> > > settings. I can't really understand how that would be better...
> >
> > The upload dialog is this: https://www.mediawiki.org/wiki/Upload_dialog
> >
> > It's accessible from both the visual and wikitext editors (unless you
> > disabled the toolbar), though their dialogs to insert image thumbnails.
>
> Thanks to all who enlightened me. :)
>
> We're basically talking cross-wiki uploader here in the Wikimedia
> world (although I'm sure it can be used for other things). I agree
> with Ostrzyciel's assessment that it lets anyone upload anything -
> that's what prompted the request to disable cross-wiki uploads in the
> first place. The UW, in collaboration with campaigns, remains the most
> powerful web uploader the Wikimedia community currently has.
>
> Strainu
> >
> > --
> > Bartosz Dziewoński
> >
> > ___
> > 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] Language switching improvements on mobile web

[Jon Katz]

Hey Everyone,
A big shout out to the reading web team (and Adam B), who rolled out a
number of subtle, but important changes to the mobile web sites of all our
projects earlier this week.

Through a series of UX improvements, the team made it easier for people to
switch between languages in an article on mobile web.  To all you
monolinguists out there, this is a very common and vital ability for people
who speak more than one language.  In addition to being a big improvement
for our multi-lingual users, the development of this feature followed many
of the best practices we aspire to at the foundation:

   - language switching on mobile initially discovered as a problem to be
   solved through quantitative research
   - tied to reading team's early strategic objective of better serving
   global readers
   - development stages included:
  - community consultation
  

  - iteration based on results
  - a/b testing and analysis in beta
  - qualitative research with live users
  

  - iteration based on results
  - collaboration with the language team (they are simultaneously
  rolling out compact language links
  

out
  of beta on desktop)
  - iteration based on collaboration

Am I missing anything?  More on the project here

and
a screenshot of the new language switching button is below


Best,

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

Re: [Wikitech-l] [WikimediaMobile] The future of Related Pages feature

[Jon Katz]

This is great discussion and I would like others to benefit from it by
moving future conversation to the discussion page of the RFC.  For this
reason, I have double posted the below response there:
https://meta.wikimedia.org/wiki/Talk:Requests_for_comment/Related_Pages#overlap_with_see_also

---
Thanks, Vituzzu! This is all great feedback and exactly what we are looking
to get from the RFC. To be clearer to others who may have missed it, the
RFC is a request for comments about this test feature, not a proposal to
roll-out the feature.

I appreciate your concern around redundancy.  I think that is one of the
biggest, most legitimate concerns about the feature (the other being how to
deal with bad results) and, honestly, one of the most obvious outcomes we
might have avoided had we started with a consultation rather than by
building.  As Jon R mentioned, there is some active discussion around how
we can improve on this and many of your comments fit well within that
scope.  As to better images, this is also something we are working on,
primarily here:
https://phabricator.wikimedia.org/T91683

Despite not being perfect, we felt that related pages  add unique value on
top of the "see also section" because it offers the reader a limited
selection compared to see also and sits at the bottom of the page, where it
does not distract from the article, because a user reaching the bottom of
the page has finished reading the article and is theoretically looking for
more content.  Notably, we see that mobile users reach the bottom of the
article less frequently, but when they DO and they see related pages, they
are much happier to see it (as indicated by click-through).  It might be
that this feature is better suited to mobile.

As I wrote on the project page
,
I'd like to identify if the overlap with "See also" mean's you would rather
not have the feature or if we feel that there is still positive value.  We
are trying to identify the order of value here for our readers:

   - no related pages < related pages with no new features < related pages
   more customizable < related pages features better synchronized with/eaten
   by "see also"

(is the above order correct? I imagine that community members might want to
swap at least the first 2 with each other...but I don't know for sure)

Thoughts?

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

[Wikitech-l] Reading Team Q4 (April-Jun) Goals

[Jon Katz]

Hi Folks,
The Reading team's Q4 goals for 2015-16 are posted on Media Wiki:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q4_Goals#Reading.
We arrived at these goals by taking the results of the Q4 brainstorming
 and matching
them against our strategy, speed and strengths.

Below is a summary of what we aim to do in the April-June Quarter with more
context than what you see on our goals page.  You will notice a lot of
cross-platform migration.  That is no accident: we learn faster by
launching on one platform and then migrating the idea to others.  The goals
are broken out by team or strategic theme.

*Community Tech: Community Wishlist items*
Ship features and fixes related to three wishes in the Wishlist Survey top
10



*Infrastructure: two-factor authentication*The infrastructure team will
enable two-factor authentication
 via AuthManager
on the Wikimedia cluster.  The goal here is to add another layer of
security for accounts with important privileges.

*New Readers (was: "reach new users in the global south")*



*Web: decrease load time and cost for low-resource environments on mobile*This
will be accomplished through lazy loading
 of images, and cutting default
html size.  This is in beta mobile channel by the end of this quarter and
we plan to measure results and roll out to all users over the course of Q4.


*Make a better encyclopedia experience*


*Web: hovercards*Specifically, enable hovercards
 as default for
logged-out desktop users on more than one wiki (this one is dependent on
community approval). Hovercards represent a faster way of browsing
Wikipedia that most readers prefer (as indicated by this survey
).
It has been in beta for more than a year and the mobile version was
recently launched to all users on our Android app.  This is not as simple
as turning on a switch, there are several improvements that will have to be
made.  One reason we are launching this is to clean up our beta site before
picking up any new work. This is arguably "New Readers" as well, due to the
performance gains from loading fewer pages.

A community initiated proposal is being discussed to enable this on English
Wikipedia.  Please chime in!
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Proposal:_Enable_Hovercards_by_default


*Android: launch the feed*This quarter, the iOS team launched a feed on the
app home screen and it looks great and early results suggest users are
responding well to it. The goal is to drive user retention by giving
readers a reason to open up Wikipedia even if they don't have a specific
query in mind.  The Android team will also be implementing backend services
to support the feed across platforms.


*iOS: Universal links*"Universal Links" (aka deep links) provide convenient
re-entry to the app from links and OS search, but do not advertise or
promote the app.  This is something that is already live on Android and
partially supported on iOS.  It allows users who prefer the app to open it
from links or an OS query, since that is how most users get to Wikipedia.


*A Community of Readers (interactive Wikipedia)*

This is the third pillar that came out of our strategy process. No active
development work is planned here. Future direction for this part of our
strategy is currently being explored via a community consultation here:
https://www.mediawiki.org/wiki/User_Interaction_Consultation


Your feedback or questions are welcome.

Thanks,

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

Re: [Wikitech-l] [Reading] October updates

[Jon Katz]

On Tue, Nov 3, 2015 at 10:39 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> As linked in https://www.mediawiki.org/wiki/Reading/Web/projects/Read_more
> to the extension https://www.mediawiki.org/wiki/Extension:RelatedArticles,
> see first section how to use
>  that
> shows the wikitext tags that enables this.
>
> I'd say it's a good start.
>
Quick correction here.  I think the plan was to start with it being an
automated feed and enable the wikitext override if editors felt that the
automation was not a load of their shoulders, but instead something they
wanted to override.  This is an easy change to make, but I want to avoid
creating an option/complexity where we might not need one.  It is easy to
go in one direction, but not the other.
-J
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikidata descriptions to show on mobile web Wikipedias

[Jon Katz]

Hi Oliver,
Thanks for bringing this up--this is something the reading and discovery
teams can discuss off-list, I think.
Best,
J

On Wed, Oct 28, 2015 at 8:34 PM, Oliver Keyes <oke...@wikimedia.org> wrote:

> What was the involvement of the Discovery team, which runs innovation
> around our search systems, in this decision?
>
> On 28 October 2015 at 22:50, Jon Katz <jk...@wikimedia.org> wrote:
> > Hi All,
> >
> > TLDR: on the mobile web, Wikidata descriptions will appear under article
> > titles in search results, nearby and watchlist starting tomorrow
> afternoon
> > (Thu, Oct 29) across projects.  A 'kill switch' has been implemented so
> > that this feature can be turned off if necessary.
> >
> > Background:
> > In Q2 of last year, Wikidata descriptions were added to both our official
> > apps: iOS and Android and resulted in wonderful qualitative feedback (as
> > the discovery team knows, it is hard to define 'success' with search
> (fewer
> > searches, more searches?).  Though moving Wikidata descriptions to search
> > on mobile web was planned for Q3 of last year, it has been sitting in
> beta
> > for many months as there was some concern that at scale on the web, it
> > might prove to be an incentive to vandalize Wikidata (and article editors
> > would not have an obvious, wikipedia way to undo such edits).
> >
> > Ultimately, we think that anything showing up on Wikipedia should be
> > editable ON Wikipedia. Wikidata description editing is something we are
> > going to aim for. Given the success of descriptions in search results on
> > apps, we would rather move forward with the presentation and work
> towards a
> > goal of editing in-line than to hold up the entire thing based on a fear
> > that might not be warranted. In consultation with the Wikidata team, we
> > decided to move forward with pushing the feature to stable as long as we
> > had the ability to pull the feature back if there were any issues.
> >
> > We are relying on community feedback to let us know if you have any
> issues
> > or hear from anyone that this is causing problems. Our community liaison
> > team will be posting notices on village pumps shortly. Thanks!
> >
> > Best,
> >
> > Jon
> > WMF Reading Product Lead
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Oliver Keyes
> Count Logula
> 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] OAuth issue -- adding new consumer

[Jon Katz]

On Thu, Oct 15, 2015 at 12:48 PM, Jon Katz <jk...@wikimedia.org> wrote:

> haha, awesome.  I'll actually take a look :)


Scratch that last comment.  My wires got crossed.  I am not the person to
talk to about OAuth.  I am, however, a product manager on the reading team
interested in exploring similar issues: ways for readers to interact with
content and ask questions.

I played around with the site yesterday and would love to chat with you
guys about what you're doing and your goals.
-J
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth issue -- adding new consumer

[Jon Katz]

haha, awesome.  I'll actually take a look :)

On Thu, Oct 15, 2015 at 10:27 AM, Ivo Kruusamägi 
wrote:

> Hi!
>
> I'm working on a commenting platform for Wikipedia -- WikiComment -- and
> would need some help with getting OAuth working there. If someone has a bit
> of time to help me with that, then please let me know.
>
> http://wikicomment.ut.ee/
>
> With regards
> Ivo Kruusamägi
> ___
> 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] Help needed with reading strategy process

[Jon Katz]

Thanks for those thoughts, C. Scott.  I, for the most part agree, but want
to add some context and some thinking around this issue exactly as it has
come up a bit.  Though involved in the process, the thoughts below are my
own interpretation.

For expediency's sake, this process started with the reading team, with a
focus on what 'we' as a team should do (the trees).  But as we embarked on
the strategic process, we quickly uncovered that our primary strategic
problems (the forest) were probably not ones we could solve by ourselves. I
think artificially limiting ourselves to this footprint would have shut
down creative thinking quite a bit and I, at least, felt it was necessary
that we understand and have ideas around the larger issues impacting our
readers.  As a team, collectively identifying the forces that impact our
work, whether in our control or not, was incredibly powerful and
enlightening.

So, I think you're right that most meaningful strategies we would consider
would involve collaboration with (or even ownership by) other teams. For
this reason, and others, a very important part of this process is
communicating out our findings and our assumptions and then collaborating
with other team's as necessary.

For example, *if*, as part of our process, we suspected that the strategy
that would impact our readers the most would be to include more videos on
the site, *one* of the 'tests' of this strategy would be: is this something
we can solve or is this something we could have a meaningful impact on.  We
would welcome external input on how to answer this.  If the answer is 'no',
we would tell everyone "hey, this is not going to be 'Reading's' strategy,
but we think it is a killer strategy for readers that we would like to
support editing/community/etc. on..."

Let me know how that sits.  I'm going to be offline until Monday, so expect
a delayed response on my part.
-J

On Wed, Sep 23, 2015 at 9:35 AM, C. Scott Ananian 
wrote:

> Let's consider one of my pet bugbears: Chinese wikipedia.  Our
> readership numbers are way below what we'd like, and as I understand
> it, total # of editors and articles is low as well.  So obviously a
> problem for the reading team, right?
>
> However, a solution needs to grapple with the problem of creating
> content for zhwiki, which would involve language engineering and the
> editing team.  Handling language variants better for reading would be
> good, too, but (AFAIK) we don't have a single active member of zhwiki
> on staff (according to
> https://office.wikimedia.org/wiki/Community_engagement/Staff_involvement),
> and just a single engineer fluent in Mandarin (according to
> https://office.wikimedia.org/wiki/HR_Corner/Languages). [My numbers
> could be slightly off here, forgive me if so.  But clearly we don't
> have a *huge presence* from zhwiki on-staff, the way we do for, say,
> enwiki.]  So maybe we need to involve HR?
>
> There are politics involved, too: perhaps the solution would involve
> the Community Engagement team, to try to build up the local wikipedia
> community and navigate the politics?
>
> My point is that even a narrow focus on increasing page views fails to
> address the more fundamental issues responsible, which spill outside
> of the team silo.  So a strategy session isolated to the reading team
> risks either missing the forest for the trees (concentrating only on
> problems solvable locally), or else generating a lot of problems and
> discussion on issues which can't be addressed without involving the
> wider organization.  (I rather expected to see the former, but most of
> the issues currently on
> https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process seem
> to be the latter.)
>
> I think a strategy process probably needs a mix of both near- and
> far-sightedness.  Identifying issues which can be solved by the team
> itself  (better engagement with users, for example), but also having a
> process for escalating issues that require a more organizational
> response.  The latter seems especially important for a team composed
> mostly of remote workers, since there aren't the same informal
> watercooler-talk mechanisms available for building awareness of
> broader needs.
>  --scott
>
> --
> (http://cscott.net)
>
> ___
> 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] Blocking Resources from Google crawl

[Jon Katz]

Hi,
Wes noticed on Monday that, according to Google, they are unable to reach a
growing number of our resources.   If you remember, we had a similar issue
a couple weeks ago back when we were on http fixed by (
https://gerrit.wikimedia.org/r/#/c/214705/1).

The growth of this one starts the day that search traffic started heading
to https.  Anyone have ideas on what might be causing this?
-J

Screenshots below, followed by drill-down of specific resources.

Today on https://en.wikipedia.org

https://www.dropbox.com/s/skmdo1u1dh8jy0z/Screenshot%202015-07-01%2010.23.31.png?dl=0


Previous incident on http://en.wikipedia.org

https://www.dropbox.com/s/l7vrs4cvs6vga1j/Screenshot%202015-07-01%2010.24.31.png?dl=0


Digging into en.wikipedia further we see its mostly caused by blocks for
this resource:

on Meta.wikimedia.org http://meta.wikimedia.org/ most of the blocks are
for this resource:

https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js/file.jsaction=rawctype=text/javascript
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gather update

[Jon Katz]

Hi People Interested in Gather,


Given the reorg and the traffic being driven to beta, we need to revisit
Gather's Q4 goals:

TLDR: Continue working on gather to finish MVP features (end of the month,
max), not pushing to stable unless we see 2x the number of logged-in edits
on beta (or 10x current state).


Before the serious stuff:


Top 5 best collections since Monday:

https://en.m.wikipedia.org/wiki/Special:Gather/by/Johnrenfro

https://en.m.wikipedia.org/wiki/Special:Gather/id/3454/Philadelphia_watch

https://en.m.wikipedia.org/wiki/Special:Gather/id/3401/engineering

https://en.m.wikipedia.org/wiki/Special:Gather/id/3532/Mental_Health

https://en.m.wikipedia.org/wiki/Special:Gather/id/3132/Libertarianismo


Okay, now the goals. Please feel free to comment in email or in this google
doc
https://docs.google.com/a/wikimedia.org/document/d/1DK1pa3PEpIbiON0Bj6BrhGAnePqZcKSmqTW1z6sTKvU/edit?usp=sharing


Thanks,


Jon



Given the reorg and an improvement made to beta, we need to revisit
Gather's goals


Pushing to Stable

Given that we can now test Gather numbers in beta, the original goal of
launching on stable to test adoption is no longer valid.  It is expensive
in terms of future maintenance and commitments to launch features to
stable, so we only want to do so after we have proven success, if possible.



Target numbers

Originally, the benchmarks for success on stable that were agreed on were
low (10k creators a month on stable, and 1k shares).  Given the current
beta numbers, it looks like we will blow the first number out of the
water.  Share has been deprioritized given current usage patterns.
However, given that we now have 4 engineers in charge of the entire web,
the standards for what we work on have to be more rigorous.  We cannot
allocate multiple engineers to an experimental product unless it shows
promise of impacting greater numbers



   1. Goal
  1.

  New Goal:
  1.

 Round out Gather hypothesis (criteria below)
 2.

 By end of June know whether or not we want to push Gather to stable



   1. Next Eng+PM Steps (to round out hypothesis)
  1.

  Improve onboarding (a few tasks)
  2.

  Surface collections publicly (this is a big missing feature)
  3.

  Qualitative and quantitative research

  2. Criteria for passing to stable:

We don’t have a great way to measure success of Gather based on usage by a
proportion of users or logged in users.  However, we can compare to
something similar like edits.  In terms of pure value to WP, we can
consider a collection to be like a low-value edit.



   -

   There are 2x ‘good’ collections made as there are total logged-in
   edits/month
   -

  in May there were 2,180 edits by logged in users (2,694 logged out).
  -

  At current rates this suggests ~4,500 collections per month is our
  target.
  -

  ‘good’ here, means 1 collection--it’s not a perfect definition, but
  it’s a strong proxy.
  -

  Our current rate of ‘good’ collections is roughly 250 a month, so we
  will need to increase the number by almost 20x.
  -

  It might be worth exploring % of those 2,180 edits that are reverted
  and adjusting down accordingly

 OR



   -

   Views of collections or where collection is the referrer  .5% of total
   pageviews
   -

  Currently, the views of collections are minimal.
  -

  If very few people create collections, but they drive a significant
  boost in page views, say .5% of total PVs (not an end goal, but also not
  bad for an MVP introducing a new use case), then the feature is a success.




   1. What if we don’t pass to stable:

Lets burn that bridge when we get to it :) . Seriously though, until we get
some qualitative data back from our readers, we will not be able to make
important calls on the feature as is. There are a few great alternatives I
can think of right off the bat:

   -

   Keep code in beta and work on Gather opportunistically or as qualitative
   data dictates
   -

  One example might be to make collections private by default and
  launch as bookmarker for readers (primary current use-case)
  -

   Promote as beta feature on desktop
   -

   Use codebase as start of multiple watchlists (some good work started
   here by JRobson)
   -

   Codebase is fairly generic list table that has some basic and
   interesting features built in that could be used for a number of other ends




   1. Validation and why we choose this criteria:


Qualitative questions to answer:

Why aren't more people using Gather? (correctly)

Why aren't people returning to use Gather more


Success metric questions to answer (that we can’t already):

What % of logged in users use Gather

What % of users who visit  1 page use Gather




What is our denominator

Status

Measure logins and signup funnel directed from Gather, what is % success
rate?

This is not instrumented

Measure % of sessions 

Re: [Wikitech-l] [WikimediaMobile] [reading-wmf] Wikigrok code no longer being worked on

[Jon Katz]

I'm inclined to agree with Matt.  In fact (and to answer Oliver's
question), the team is already considering the next slew of
micro-contribution projects.

I think it is too early to say which projects will be next, but some ideas
include: choosing lead images, editing wikidata descriptions, and refining
categorization of topics.

Joaquin, I agree that lessons learned would be helpful.  As someone who
came to the project at the very end, I don't feel entitled to point out
things that should have been done differently.  As a member of the team
that made the decision to pause development, however, I would be happy to
help establish criteria that projects need to meet (as a minimum) in order
to see continued effort.  Given my limited bandwidth, this is not something
I can promise anytime soon and I encourage others to take a first stab.

-J


On Tue, Jun 2, 2015 at 6:23 PM, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 On 06/02/2015 06:00 AM, Joaquin Oltra Hernandez wrote:

 Now there's a lot of skepticism towards the idea in any of its forms :(


 I still think micro-contributions are an important future direction
 (whether or not WikiGrok is re-activated).

 Given how successful the metrics were from WikiGrok, it's hard to see why
 there should be skepticism about the idea of micro-contributions.

 Matt Flaschen



 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l

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

[Wikitech-l] Wikigrok code no longer being worked on

[Jon Katz]

Hi,

*TLDR:* Wikigrok proved that readers are interested in and capable of
making casual, mobile contributions to Wikipedia. We are putting continued
development of the 'Wikigrok' casual contribution feature on hold until we
have a plan for optimally harnessing this interest/capability.

*Background*
Given the growth of mobile traffic on wikipedia and the challenges inherent
to traditional editing on a mobile device, Wikigrok was proposed as a way
to test if regular wikipedia readers would be interested in making smaller,
more casual contributions to wikimedia projects while reading Wikipedia on
a mobile device.

*Results*
By early 2015, the results were in: readers were relatively interested in
engaging with the feature[1].  Some oft-quoted comparisons include:

   - 3x the number of unique responders as mobile editors during test
   period (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of
   articles  users
   - 1.5x better clickthrough than 2014 Fundraising full-screen mobile
   banner

(I actually do not have references for these, as they are borrowed quotes)
Furthermore, we found that the quality of responses was rather high [2,3].

*Future*
The original thought was to use these responses to fill in gaps in Wikidata
and our initial test results (2 weeks worth) were successfully ported over
in late April [4]. However, in order to production-ize the system, we would
have to:

   1. scale and develop queries against the new wikidata query service
   2. create an article parser to identify potential multiple choice
   answers for each question
   3. create a system for attributing aggregated results to the specific
   contributors (per Wikidata bot request discussion[5])

None of these are unsurpassable, but we have learned a great deal and, at
this stage, we believe that further effort should be devoted to evaluating
areas of need and fit before we commit additional efforts to specifically
porting information into Wikidata.

Please feel free to reach out if you have any questions or concerns about
this decision.
Best,

Jon

[1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
[2] Quality of responses, version A:
https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).pdf
[3] Quality of responses, version B:
https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).pdf
[4] *https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500*
[5]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Wikigrok code no longer being worked on

[Jon Katz]

Hi Oliver,
Thanks for sharing your disappointment.  I do not think you are alone in
wanting to see wikigrok continue and grow.  I would clarify that the
'success rates' you allude to were for  reader engagement and accuracy, not
in actually improving our projects by filling in important gaps in
wikidata.  A great deal of work would be required to build out in order for
this project to have a scalable impact on wikidata.

I am not saying that casual contributions are going away, simply that we
are going to recognize our resource limitations and evaluate opportunities
for them based on highest return-on-investment. We currently have 5
developers working on readership for the entire web (due to some temporary
leaves) and there might be smaller wins using casual contributions that
work towards our end goal, but don't require the heavy upfront investment.
This doesn't mean we don't take on big thorny problems, just that we take a
step back and see if there are ways to subdivide them into smaller projects
along the way.

Best,

Jon

[1]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok

On Mon, Jun 1, 2015 at 12:05 PM, Oliver Keyes oke...@wikimedia.org wrote:

 I'm personally incredibly disappointed; this was the most successful
 intervention I'd seen anyone try in a long while, if ever, and the
 results blow me away. My question would be what interventions with
 similarly high success rates are going to be worked on instead? - I
 assume that we're not working on them because we can achieve the same
 outcome through easier-to-implement interventions. I would be
 interested to hear what those interventions are.

 On 1 June 2015 at 14:57, Jon Katz jk...@wikimedia.org wrote:
  Hi,
 
  TLDR: Wikigrok proved that readers are interested in and capable of
 making
  casual, mobile contributions to Wikipedia. We are putting continued
  development of the 'Wikigrok' casual contribution feature on hold until
 we
  have a plan for optimally harnessing this interest/capability.
 
  Background
  Given the growth of mobile traffic on wikipedia and the challenges
 inherent
  to traditional editing on a mobile device, Wikigrok was proposed as a
 way to
  test if regular wikipedia readers would be interested in making smaller,
  more casual contributions to wikimedia projects while reading Wikipedia
 on a
  mobile device.
 
  Results
  By early 2015, the results were in: readers were relatively interested in
  engaging with the feature[1].  Some oft-quoted comparisons include:
 
  3x the number of unique responders as mobile editors during test period
  (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of articles 
  users
  1.5x better clickthrough than 2014 Fundraising full-screen mobile banner
 
  (I actually do not have references for these, as they are borrowed
 quotes)
  Furthermore, we found that the quality of responses was rather high
 [2,3].
 
  Future
  The original thought was to use these responses to fill in gaps in
 Wikidata
  and our initial test results (2 weeks worth) were successfully ported
 over
  in late April [4]. However, in order to production-ize the system, we
 would
  have to:
 
  scale and develop queries against the new wikidata query service
  create an article parser to identify potential multiple choice answers
 for
  each question
  create a system for attributing aggregated results to the specific
  contributors (per Wikidata bot request discussion[5])
 
  None of these are unsurpassable, but we have learned a great deal and, at
  this stage, we believe that further effort should be devoted to
 evaluating
  areas of need and fit before we commit additional efforts to specifically
  porting information into Wikidata.
 
  Please feel free to reach out if you have any questions or concerns about
  this decision.
  Best,
 
  Jon
 
  [1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
  [2] Quality of responses, version A:
 
 https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).pdf
  [3] Quality of responses, version B:
 
 https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).pdf
  [4]
 https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
  [5]
 
 https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
 
 
  ___
  Mobile-l mailing list
  mobil...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/mobile-l
 



 --
 Oliver Keyes
 Research Analyst
 Wikimedia Foundation

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

Re: [Wikitech-l] [reading-wmf] Fwd: Mobile Firendly

[Jon Katz]

+external mobile and wikitech

Shoot.  I meant to send this the external list.  For those of you just
joining us, we recently got an email from google letting us know that some
of our pages are now failing the mobile-friendly test, which has an adverse
impact on our search results.  It appears that most of our pages are also
blocking style info.

Google doesn't offer much insight into penalties, but if they're sending us
the email then it is or will have some impact.  I'd like to see if we can
better understand the other side of the equation- what is cost of fixing
it?  I think Jon's questions below are the ones to start with.

-J


On Fri, May 29, 2015 at 1:35 PM, Jon Robson jrob...@wikimedia.org wrote:

 It's all in the report. We block w/ in robots.txt always have.

 There have been a bunch of changes to improve performance of the site
 overall which might have led to that. Mailing this to the public mailing
 list wikitech would give you a better idea.

 Our site /is/ mobile friendly it's just we tell google not to load styles
 from w/load.php so no need to panic.

 The question is what is the penalty of us failing this tool? Does it
 impact our google search rankings?

 Fix is trivial.. Update robots.txt but first the question is why are we
 blocking scripts and styles on that url?
 On 29 May 2015 1:17 pm, Jon Katz jk...@wikimedia.org wrote:

 Hi Readership team and broader community,
 Any changes we might have recently made to cause this warning to appear
 about googlebot not being able to access our site?
 I consider this to be a very serious issue.
 The examples below are not mobile, but same issue applies when you try an
 en.m. version of the pages.

 Best,
 Jon


 -- Forwarded message --
 From: Wes Moran wmo...@wikimedia.org
 Date: Fri, May 29, 2015 at 12:47 PM
 Subject: Mobile Firendly
 To: Jon Katz jk...@wikimedia.org
 Cc: Adam Baso ab...@wikimedia.org


 Jon,

 Google notified us of the followin...

 We recently noticed that there was a change with how you embed CSS  JS
 which results in us not being able to use the CSS  JS to recognize what
 the page looks like. That's making some of your pages fail the
 mobile-friendly-test, for example. You used to load CSS  JS from
 bits.wikimedia.org, but now they're loaded through /w/load.php?...
 directly from the Wikipedia host, where that path is blocked by robots.txt.

 You can see how we render the pages with Fetch as Google in Webmaster
 Tools / Search Console, you can also see most of that with the test-page at:

 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBusot

 Some of the pages still pass the test there (example
 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZ%25C3%25BCrich),
 but the CSS is broken there too since it's blocked. 

 Any ideas what can be causing this?

 Regards,
 Wes


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


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

Re: [Wikitech-l] [reading-wmf] Fwd: Mobile Firendly

[Jon Katz]

Since Brandon's email a minute ago crossed mine in the ether and did not
make it to external lists, I am pasting it here:

On Fri, May 29, 2015 at 1:53 PM, Brandon Black bbl...@wikimedia.org wrote:
We've merged up https://gerrit.wikimedia.org/r/#/c/214705/1 to address
this, and I've purged the caches to ensure the update is fully live
already.  It should address the issue, assuming that the block on RL's
/w/load.php entry point was the only part of the problem.

On Fri, May 29, 2015 at 1:55 PM, Jon Katz jk...@wikimedia.org wrote:

 +external mobile and wikitech

 Shoot.  I meant to send this the external list.  For those of you just
 joining us, we recently got an email from google letting us know that some
 of our pages are now failing the mobile-friendly test, which has an adverse
 impact on our search results.  It appears that most of our pages are also
 blocking style info.

 Google doesn't offer much insight into penalties, but if they're sending
 us the email then it is or will have some impact.  I'd like to see if we
 can better understand the other side of the equation- what is cost of
 fixing it?  I think Jon's questions below are the ones to start with.

 -J


 On Fri, May 29, 2015 at 1:35 PM, Jon Robson jrob...@wikimedia.org wrote:

 It's all in the report. We block w/ in robots.txt always have.

 There have been a bunch of changes to improve performance of the site
 overall which might have led to that. Mailing this to the public mailing
 list wikitech would give you a better idea.

 Our site /is/ mobile friendly it's just we tell google not to load styles
 from w/load.php so no need to panic.

 The question is what is the penalty of us failing this tool? Does it
 impact our google search rankings?

 Fix is trivial.. Update robots.txt but first the question is why are we
 blocking scripts and styles on that url?
 On 29 May 2015 1:17 pm, Jon Katz jk...@wikimedia.org wrote:

 Hi Readership team and broader community,
 Any changes we might have recently made to cause this warning to appear
 about googlebot not being able to access our site?
 I consider this to be a very serious issue.
 The examples below are not mobile, but same issue applies when you try
 an en.m. version of the pages.

 Best,
 Jon


 -- Forwarded message --
 From: Wes Moran wmo...@wikimedia.org
 Date: Fri, May 29, 2015 at 12:47 PM
 Subject: Mobile Firendly
 To: Jon Katz jk...@wikimedia.org
 Cc: Adam Baso ab...@wikimedia.org


 Jon,

 Google notified us of the followin...

 We recently noticed that there was a change with how you embed CSS  JS
 which results in us not being able to use the CSS  JS to recognize what
 the page looks like. That's making some of your pages fail the
 mobile-friendly-test, for example. You used to load CSS  JS from
 bits.wikimedia.org, but now they're loaded through /w/load.php?...
 directly from the Wikipedia host, where that path is blocked by robots.txt.

 You can see how we render the pages with Fetch as Google in Webmaster
 Tools / Search Console, you can also see most of that with the test-page at:

 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBusot

 Some of the pages still pass the test there (example
 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZ%25C3%25BCrich),
 but the CSS is broken there too since it's blocked. 

 Any ideas what can be causing this?

 Regards,
 Wes


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf



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

[Wikitech-l] Collections--Project: Gather

[Jon Katz]

Hi Folks,
Thank you for your feedback around the collections project*.  One of the
strongest pieces of feedback was that the project name was easily confused
with the collections:extension.  Yes.

As a result, the collections project is now named project gather.  This
is effective immediately. The name of the product itself is yet to be
settled-on, but the lists themselves are still referred to as collections
in mocks etc.

There is now a project page up on media wiki:
https://www.mediawiki.org/wiki/Gather

Comments welcome!

Best,

J


* for context, see thread with subject: New feature in development:
collections
or first email from that thread repasted here:


Hi,
For those of you I haven't yet met, I am a new product manager in SF,
working with the mobile web team (I look forward to meeting you)!

I just wanted to let you all know about a new project we are starting for
Wikipedia's mobile website. The project has been dubbed Collections, and
our pilot will let users create and share collections of articles.  Here
are some ways that this project is exploring new ways to move our mission
forward:


   - *New ways to contribute: * through curation, wikipedia readers who are
  not interested in traditional editing can have meaningful, creative
  interactions with our content
  - *Personal:* gives users a way to make content more relevant
for them  Peter's
  list of most important Philosophers is not subject to consensus
or editing
  by others.  For the time being, a list will only be accessible via shared
  url.
  - *Shareable:  *this project will experiment with the ability to use
  Wikipedia to share ones' perspective with others and, in doing so,
  encourage new users to engage
  - *[Future] Browseable:* because each list is not exhaustive, there
  is a possibility of using popular lists to promote meaningful content.
  It's nice to know the full list of statisticians
  https://en.wikipedia.org/wiki/List_of_statisticians is there, but I
  might want to find a subset that have been picked out by a human for one
  reason or another.


Though the pilot is targeting and supporting readers, we think there are
also potential use cases for editors that we could explore in the future.
One can easily imagine lists for editors to track or share their
contributions, such as: Articles that I want to write/expand during 2015
or Articles I created in 2013.

A fair amount of thought has gone into why we are launching this particular
project and how we might approach it, but we have just started exploratory
development work last week.  Here is the team:

Jon Robson

Rob Moen

Joaquin Hernandez

Moiz Syed

[me]


*Ask:*
[I know that this project overlaps with several existing features in terms
of raw functionality, so if you have any relevant experience with either
the editing or technical support of lists, collections extension (books) or
watchlist and are interested in sharing your experience, please feel reach
out to me directly.  We very much want to learn from previous efforts]

Also, please reach out to me or anyone else on the team if you have any
questions or concerns about the feature, team, etc.

Best,

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

Re: [Wikitech-l] New feature in development: collections

[Jon Katz]

Hi Nemo,
Great idea.  I hope to have at least a bare bones media wiki hub for this
project up next week.
Best,

J

On Thu, Jan 22, 2015 at 3:12 AM, Federico Leva (Nemo) nemow...@gmail.com
wrote:

 From https://tools.wmflabs.org/meetbot/wikimedia-office/2015/
 wikimedia-office.2015-01-14-21.00.log.html :
 21:15:49 Emufarmers Is this collections thing the same as
 https://www.mediawiki.org/wiki/Mobile_web_projects/Collections_Backend
 (just came up during the research showcase)?

 They look related, so I commented on the talk page there. It seems there
 are parallel discussions in other unknown mailing lists, so it's useful to
 centralise on the wiki.


 Nemo

 ___
 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] New feature in development: collections

[Jon Katz]

Apologies for cross-listing this--I initially (and erroneously) only sent
it internally

--
Hi,
For those of you I haven't yet met, I am a new product manager in SF,
working with the mobile web team (I look forward to meeting you)!

I just wanted to let you all know about a new project we are starting for
Wikipedia's mobile website. The project has been dubbed Collections, and
our pilot will let users create and share collections of articles.  Here
are some ways that this project is exploring new ways to move our mission
forward:

   - *New ways to contribute: * through curation, wikipedia readers who are
   not interested in traditional editing can have meaningful, creative
   interactions with our content
   - *Personal:* gives users a way to make content more relevant for
them  Peter's
   list of most important Philosophers is not subject to consensus or editing
   by others.  For the time being, a list will only be accessible via shared
   url.
   - *Shareable:  *this project will experiment with the ability to use
   Wikipedia to share ones' perspective with others and, in doing so,
   encourage new users to engage
   - *[Future] Browseable:* because each list is not exhaustive, there is a
   possibility of using popular lists to promote meaningful content.  It's
   nice to know the full list of statisticians
   https://en.wikipedia.org/wiki/List_of_statisticians is there, but I
   might want to find a subset that have been picked out by a human for one
   reason or another.


Though the pilot is targeting and supporting readers, we think there are
also potential use cases for editors that we could explore in the future.
One can easily imagine lists for editors to track or share their
contributions, such as: Articles that I want to write/expand during 2015
or Articles I created in 2013.

A fair amount of thought has gone into why we are launching this particular
project and how we might approach it, but we have just started exploratory
development work last week.  Here is the team:

Jon Robson
Rob Moen
Joaquin Hernandez
Moiz Syed
[me]

*Ask:*
[I know that this project overlaps with several existing features in terms
of raw functionality, so if you have any relevant experience with either
the editing or technical support of lists, collections extension (books) or
watchlist and are interested in sharing your experience, please feel reach
out to me directly.  We very much want to learn from previous efforts]

Also, please reach out to me or anyone else on the team if you have any
questions or concerns about the feature, team, etc.

Best,

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