I've noticed something a little strange about the "editable" key that the
mobileview API returns. It seems it's either "true" or the empty string if
the page is editable, or either "false" or absent from the response if the
page is not editable. Whether it goes for the empty string/absent or
true/false approach seems to vary from wiki to wiki.
Examples (make sure you're not logged in on an admin account when you click
these, because admin accounts can edit almost all pages):
- Foo @ testwiki
<https://test.wikipedia.org/w/api.php?action=mobileview&page=Foo&prop=editab…>
-
response is the empty string on an editable page
- Protected page @ testwiki
<https://test.wikipedia.org/w/api.php?action=mobileview&page=Protected_page&…>
-
response is absent on a protected page
- Manchester @ enwiki
<https://en.wikipedia.org/w/api.php?action=mobileview&page=Manchester&prop=e…>
-
response is true on an editable page
- Barack Obama @ enwiki
<https://en.wikipedia.org/w/api.php?action=mobileview&page=Barack%20Obama&pr…>
-
response is false on a protected page
Does anyone know why this is? It'd be nice if this could be changed,
because it's a pain to deal with things like this in a strongly-typed
language like Java.
Thanks,
Dan
--
Dan Garry
Product Manager, Search and Discovery
Wikimedia Foundation
The team responsible for the Gather extension [0] kicked off their new
sprint yesterday. sprint `Greatest Hits` [1] after finishing sprint
`Forward` completing 33.5 story points (3.5 more than we planned).
As well as the usual polish, this sprint we will be doing lots of
thinking around the topics of flagging [2] and subscribing [3] for the
backend for the Gather feature. These will help steer our architecture
in the right direction. Please join the conversation.
In addition to this we are planning to make some changes to target
some of our users and encourage them to opt into our beta site to grow
our audience there for beta testing so we can reach more users than we
have historically been able to [2].
[0] https://www.mediawiki.org/wiki/Extension:Gather
[1] https://phabricator.wikimedia.org/tag/gather_sprint_greatest_hits/
[2] https://phabricator.wikimedia.org/T96282
[3] https://phabricator.wikimedia.org/T94243
[4] https://phabricator.wikimedia.org/T96286
Cross posting to mobile-l.
---------- Forwarded message ----------
From: Gerard Meijssen <gerard.meijssen(a)gmail.com>
Date: Sun, Apr 26, 2015 at 11:54 PM
Subject: Re: [Wikimedia-l] Google rankings and mobile phone support`
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Cc: WikiData-l <wikidata-l(a)lists.wikimedia.org>
Hoi Pine,
Thanks for the link to the test tool. <grin> I find that the one project
dearest to my heart is doing poorly </grin>. It seems that our projects
themselves are fairing much better than what the news led me to believe..
The point of it all is that mobile phones need to be well supported. It is
good that we are working strongly on improving our mobile presence and the
software and the group of readers they represent are becoming main-stream
as time progresses.
Thanks,
GerardM
On 27 April 2015 at 08:41, Pine W <wiki.pine(a)gmail.com> wrote:
> Hi Gerard,
>
> Yes, I saw this news as well.
>
> Check out these results:
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikipedia.…
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=en.wikipedia.o…
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=commons.wikime…
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimediaf…
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimedia.…
>
>
>
https://www.google.com/webmasters/tools/mobile-friendly/?url=blog.wikimedia…
>
> It looks like most but not all Wikimedia sites pass Google's test.
>
> Personally I hope we invest heavily in Mobile Web in the next annual plan.
> I would like to see growth in mobile readership and growth in mobile
> contributions, and year-over-year growth in combined desktop and mobile
> readership and contributions.
>
> Thanks,
>
> Pine
>
> *This is an Encyclopedia* <https://www.wikipedia.org/>
>
>
>
>
>
>
> *One gateway to the wide garden of knowledge, where lies The deep rock of
> our past, in which we must delve The well of our future,The clear water we
> must leave untainted for those who come after us,The fertile earth, in
> which truth may grow in bright places, tended by many hands,And the broad
> fall of sunshine, warming our first steps toward knowing how much we do
not
> know.*
>
> *—Catherine Munro*
>
> On Sun, Apr 26, 2015 at 11:24 PM, Gerard Meijssen <
> gerard.meijssen(a)gmail.com
> > wrote:
>
> > Hoi,
> >
> > It is all over the news. Google will push mobile phone support by
> changing
> > its ranking algorithm. A website that does not support mobiles well will
> > suffer the consequences. Several sources like /. indicate that Wikipedia
> > has a problem.
> >
> > I am anxious to learn what we are going to do.
> >
> > From my perspective this is not a time of endless deliberations; we have
> > done that, we have been there. Mobile is where we grow. It seems to me a
> no
> > brainer that we will move lock stock and barrel to a more mobile
friendly
> > environment.
> >
> > Thanks.
> > GerardM
> >
> >
> >
>
http://ultimategerardm.blogspot.nl/2015/04/google-thank-you-for-pushing-mob…
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
<https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.w…>
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
FYI. If your software interacts with the API, good list to join.
---------- Forwarded message ----------
From: <mediawiki-api-announce-request(a)lists.wikimedia.org>
Date: Sunday, April 26, 2015
Subject: Mediawiki-api-announce Digest, Vol
Today's Topics:
Date: Sat, 25 Apr 2015 08:30:32 -0400
From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org <javascript:;>>
To: mediawiki-api-announce(a)lists.wikimedia.org <javascript:;>
Subject: [Mediawiki-api-announce] Change in ordering of revisions from
prop=revisions
prop=revisions has long ordered revisions by rev_id rather than timestamp
when returning results for a single page. In most cases this doesn't make a
difference, but for old pages imported from earlier versions of Wikipedia,
for revisions imported from Special:Import, and so on these orderings don't
always match.
prop=revisions has now been updated[1] to order by timestamp rather than
id. While this is technically a breaking change, it seems unlikely that any
clients will actually be broken by this.
This should be deployed to WMF wikis with 1.26wmf4, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule.
[1]: https://gerrit.wikimedia.org/r/#/c/188843/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Dear Android app friends,
Around an hour ago I pushed out a new release for the beta app, so it
should be available fairly soon. Unless there are major issues/blockers
discovered, we're going to push this code base to production next week.
Changes for 2.0-beta-2015-04-23 include:
* Detect network connectivity, and display server status code & message in
case of error instead of assuming that network is down
* Avoid IP edits when user is logged in
* Don't display "read more" suggestions outside main namespace
* Slightly decrease minimum text size on Share a Fact cards
* Prevent action bar from reverting to black on new page load if lead image
is available
Crash fixes:
* Fix possible crash on screen rotation
* Disable pulling of ToC before page has finished loading
Enjoy,
Bernd
On Wed, Apr 15, 2015 at 11:16 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> > I'm just troubled by some of the language used here, and elsewhere, which
> > describes a "fear" of more users. I can't help but wonder how many
> companies
> > or services would readily welcome a "massive influx of users." How will
> > Wikipedia or Commons succeed if we're afraid growth?
>
> +1. How we change this culture is the holy grail of Wikimedia's
> future. Unless we change this, our project will die imo. I was really
> saddened to see mobile uploads disappear from web - we had a lot of
> spam yes but we also had people posting never before available photos
> of diseases [1]. Our communities reaction seems to be to push back on
> influxes of new edits which makes me feel we should be spending more
> time on moderation tools - but so far I don't see any hint that this
> will become a focus. This is a bigger problem than web and apps but so
> far we see this more than most... I think this is something we'd have
> to convince Lila is a good use of our time...
Lila is convinced it is a good use of time; that's why tools for community
needs was in the Call To Action. And that's why we announced the creation
of a Community Tech team yesterday (see wikimedia-l). Details and
prioritization are still to be fleshed out (they can't tackle everything at
once!) but moderation tools are definitely one of the things the team could
tackle.
Luis
--
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
In beta on enwiki, there were 400 clicks on watchlist compared to 587
on collections since we launched it. It will be interesting how it
holds out, as I suspect it is "new feature curiosity" but it adds more
value to the idea that people use the watchlist for things other than
editing. It's even more popular than nearby at current time.
That said It still fails to compete with our most popular 'features'
home, random and settings.
Result of SQL Query [1]:
Home Random Nearby Watchlist Uploads Settings Profile Logout Login Collections
1308 851 500 400 0 1188 258 99 373 587
[1] SELECT
sum(if(event_name = 'home', 1, 0)) as Home,
sum(if(event_name = 'random', 1, 0)) as Random,
sum(if(event_name = 'nearby', 1, 0)) as Nearby,
sum(if(event_name = 'watchlist', 1, 0)) as Watchlist,
sum(if(event_name = 'uploads', 1, 0)) as Uploads,
sum(if(event_name = 'settings', 1, 0)) as Settings,
sum(if(event_name = 'profile', 1, 0)) as Profile,
sum(if(event_name = 'logout', 1, 0)) as Logout,
sum(if(event_name = 'login', 1, 0)) as Login,
sum(if(event_name = 'collections', 1, 0)) as Collections
FROM
MobileWebMainMenuClickTracking_11568715
WHERE
event_mobileMode = 'beta'
and wiki = 'enwiki'
Hey folks,
One of the tasks that the Readership* team committed to this sprint was
running the WikiGrok bot [0] to aggregate and push all previously recorded
claims to Wikidata [1]. We agreed that for this first run, the bot should
use a conservative threshold to judge what qualifies as a pushable claim:
there must be at least 10 responses to the WikiGrok question and 80% of
those responses must be for the claim.
120 claims qualified as pushable and, eventually, 78 were pushed to
Wikidata [2].
–Sam
* We're going to have to come up with a new name again, aren't we?
[0] https://github.com/phuedx/wikigrok-aggregation-test
[1] https://phabricator.wikimedia.org/T96096
[2]
https://www.wikidata.org/w/index.php?title=Special:Contributions/WikiGrok&o…
Hi all,
the quarterly reviews for the past quarter (January-March 2015) took
place last week. Minutes and slides are now available for the
following meetings:
Community Engagement, Advancement (Fundraising and Fundraising Tech):
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Mobile Web, Mobile Apps, Wikipedia Zero:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Parsoid, Services, MediaWiki Core, Tech Ops, Release Engineering,
Multimedia, Labs, Engineering Community:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Editing (covering VisualEditor), Collaboration (covering Flow),
Language Engineering:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
As mentioned in February [1], the quarterly review process has been
extended to basically all groups in the Foundation since Lila took the
helm last year, and it was further refined this quarter, reducing the
number of meetings to six overall, each combining several areas.
Minutes and slides from the remaining two meetings should come out
soon, too. (And naturally, all the engineering team names above refer
to the structure before the reorganization that has just been
announced.)
[1] https://lists.wikimedia.org/pipermail/wikimedia-l/2015-February/076835.html
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
>
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB