Hey everyone,
I'm writing with plans for the Wikimedia iOS engineering team to move its
workflow to GitHub with Travis CI, much like RESTbase.
The Wikimedia iOS engineers have been maintaining their own CI and build
server and using Gerrit for code review. The more time efficient and
commonplace approach for open source iOS software development leans heavily
on GitHub with Travis CI instead (e.g., WordPress[0][1] and Firefox[2][3]).
By using GitHub with Travis CI, the team believes it will work faster,
improve testing, grow developer confidence in making code changes, and,
most importantly, deploy fewer bugs to production.
For builds requiring sensitive information (e.g., prod certs), will
continue to run on WMF's Mac Mini. As is done for Android, when betas are
pushed, the team will notify mobile-l.
Feel free to reply or email me directly with any questions or comments.
Regards,
Brian
0: https://github.com/wordpress-mobile/WordPress-iOS
1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
2: https://github.com/mozilla/firefox-ios
3: https://travis-ci.org/mozilla/firefox-ios
--
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
Forwarding the link to the Reading team's quarterly review
documentation, as it just occurred to me that not everyone might have
caught it on the other lists.
---------- Forwarded message ----------
From: Tilman Bayer <tbayer(a)wikimedia.org>
Date: Thu, Jul 16, 2015 at 7:50 AM
Subject: Wikimedia Foundation quarterly reviews for April-June 2015
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi all,
the Wikimedia Foundation's quarterly reviews of teams' work in the
past quarter (April-June 2015) took place last week. Minutes and
slides for those meetings are now available:
...
Reading (formerly mobile web and apps):
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
...
As usual, much of this information will also be available in
consolidated form as part of the general WMF quarterly report for Q4,
which is planned to be published on July 30.
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Cross posting to mobile-l.
---------- Forwarded message ----------
From: Adam Baso <abaso(a)wikimedia.org>
Date: Mon, Jul 27, 2015 at 10:11 AM
Subject: Editing + Reading Meeting Notes
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Hi all,
James Forrester, Florian, and I met Wednesday, 22-July-2015 to discuss the
Editing roadmap, with the backdrop of editing modes available in mobile web
and apps but both the mobile web and apps teams now being in the Reading
department. Notes:
* FY 2015-2016: active Editing development for apps not planned
* General plan is to replace the current mobile web editing experiences
with new (replacement) VE and wikitext editor maintained by the VE team for
mobile web
* Q1: VE mobile prototyping (doesn't require Reading involvement)
* Q2: Editing for mobile web replacement *coding* starting, but rollout on
mobile web would begin in some future quarter _after_ Q2
* Feature submission practices for volunteers submitting editing related
stuff for the mobile web for the time being (feature submissions
discouraged for now as it will end up being replaced; mainline VisualEditor
/ next gen wikitext editing in collaboration with VE team would probably
make more sense) -
** Create task in reading-web Phabricator board and indicate the details of
what you were thinking to work on and roughly when. Add James Forrester and
Joaquin Hernandez to card.
** Reach out to James_F (Senior Product Manager, VisualEditor) and joakino
(Reading Web engineering product owner and tech lead) on #wikimedia-mobile
on Freenode to discuss the idea and to determine who would need to code
review and test
* Code review for bugfixes for the existing mobile editing code should be
done by Reading Web, and code review plus testing should be done by Editing
as well. Ping joakino and James_F on IRC to figure out who to add to
bugfixes.
* As the Editing team gets into the practice of submitting patches for
MobileFrontend to swap out the editor, as usual, tasks should be filed well
ahead of time in the reading-web Phabricator board so there's a heads up
about potential code review. Also, Editing and Reading should be tracking
Q2 and subsequent quarter planning together to ensure dependencies are
clearly defined and agreed upon.
I also spoke to Roan from Collaboration after the Scrum of Scrums the same
day. Roan indicated that there isn't an emphasis on rolling out Flow to
mobile Wikipedias en masse for FY 2015-2016. And generally, when Flow does
become slated for rollout on the mobile Wikipedias and sister projects in a
broader sense it shouldn't require work - or anything substantial, anyway -
from the Reading team.
-Adam
Moving discussion to mobile-l.
On Wednesday, July 22, 2015, Michael Holloway <mholloway(a)wikimedia.org>
wrote:
> OK by me.
>
> On Wed, Jul 22, 2015 at 10:53 AM, Adam Baso <abaso(a)wikimedia.org
> <javascript:_e(%7B%7D,'cvml','abaso(a)wikimedia.org');>> wrote:
>
>> Okay to move this discussion to mobile-l?
>>
>> I'm talking with Editing (includes VE and Flow) this morning about
>> engagement model and their short to medium term roadmap, which should be
>> helpful in your guys' examination of bridge/stopgap solutions for this
>> pretty fundamental stuff.
>>
>>
>> On Wednesday, July 22, 2015, Michael Holloway <mholloway(a)wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','mholloway(a)wikimedia.org');>> wrote:
>>
>>> Hey all,
>>>
>>> Last week at Wikimania I had some interesting conversations about the
>>> Android app. On the whole, people really like the new and improved app,
>>> but there are definitely frustrations with the editing experience -- from
>>> people thinking it's not possible to edit in the app, to uninstalling it so
>>> that Google links direct them to the mobile website, where they vastly
>>> prefer the editing experience. Editors are a small but important group and
>>> I don't think we're doing them justice at the moment. Although reading is
>>> our focus, I would suggest we devote some resources to improving the
>>> editing experience as well. (It turns out that Abbey Ripstra and the
>>> design research team are running a survey research study on mobile
>>> contribution experiences as I write, so I'll be interested to hear what
>>> insights they have to offer.)
>>>
>>> I also had a conversation with Asaf Bartov, who mentioned that it would
>>> be nice to be able to access talk pages in the mobile app. I'm sympathetic
>>> to this; most users may not care about talk pages, but they're very
>>> important to the editing experience, and even for savvy readers they offer
>>> useful commentary about what's on (or off) the page and why. So yesterday
>>> afternoon I hacked up a POC patch to add a toolbar button to flip back and
>>> forth between main articles and talk pages. Have a look and let me know
>>> what you think!
>>>
>>> https://gerrit.wikimedia.org/r/#/c/226297/
>>>
>>> Cheers,
>>> Michael
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "android" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to android+unsubscribe(a)wikimedia.org.
>>> To post to this group, send email to android(a)wikimedia.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/wikimedia.org/d/msgid/android/CAMEEL1-AxGuy%2BG…
>>> <https://groups.google.com/a/wikimedia.org/d/msgid/android/CAMEEL1-AxGuy%2BG…>
>>> .
>>>
>>
>
Hi Dan,
this is all right, and we had the same problems (and still have) in mobile web. Our workaround is, that we show the talk button (to open the talk page) only to users, that we think are "experienced" enough to handle this confusing type of content. So, only registered editors with an edit count greater than 5, or users which have the beta mode enabled, have the talk button, all others have to navigate through the search.
What do you think about doing this in the app, too? You could hide the button in the stable app, if the user isn't logged in or has not made 5 edits so far. The beta app could always show the talk page button.
Best,
Florian
Sent from my HTC
----- Reply message -----
From: "Dan Garry" <dgarry(a)wikimedia.org>
To: "Dmitry Brant" <dbrant(a)wikimedia.org>
Cc: "mobile-l" <mobile-l(a)lists.wikimedia.org>
Subject: [WikimediaMobile] In-app editing / talk pages support
Date: Sat, Jul 25, 2015 02:38
On 22 July 2015 at 10:52, Dmitry Brant <dbrant(a)wikimedia.org> wrote:
>
> Therefore, providing access to talk pages without providing the other
> fundamentals that are central to editing (moderation tools, watchlists,
> diffs, notifications, etc) may be putting the cart before the horse, and
> may lead to confusion.
>
I think you hit the nail on the head with this comment.
Experienced Wikipedians know the value of talk pages. For many of them,
talk pages actually comprise the majority of their usage of the site. But,
the majority of their navigation to those pages are through their
watchlist, so adding a talk page link doesn't serve them; they know the
talk page is there, and how to find it if they need it.
For newer users, talk pages are their entry point into the inner workings
of the wiki, and how they get sucked in. But, there are some pretty
fundamental <https://i.imgur.com/UOqtyoM.png> formatting issues with talk
pages in the app right now. If you're going to make it read only, how are
you going to explain to users why other users are leaving comments, but
they can't edit it? Suddenly, there are a lot of questions that will take a
lot of team bandwidth, designs, and discussions to answer. Can you commit
to answering all of these questions given the other work you have in the
pipeline?
For the reasons above, I was opposed (and still am) to adding links to talk
pages in the app. For experienced editors, they know where to find them and
don't need a button to get there. For readers (the primary user type that
the app supports), the talk page experience in the app is not good enough
to expose the users to it, and we never had the capacity to get the
experience to a place where it was good enough for them without
considerable work to build out the entire pipeline.
Dan
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
Hi,
I remember that when the Italian Wikipedia allowed mobile anonymous
editing, there were statistics that showed that it didn't increase
vandalism or bad edits.
Based on that it was enabled in other sites.
Are there published up-to-date statistics about this? Reverts of anonymous
mobile web edits, etc.?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Fwd, forgot to press answer all :(
Gesendet mit meinem HTC
----- Weitergeleitete Nachricht -----
Von: "Florian Schmidt" <florian.schmidt.welzow(a)t-online.de>
An: "Aaron Halfaker" <ahalfaker(a)wikimedia.org>
Betreff: AW: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile
Datum: Do., Apr. 30, 2015 16:26
Great to read this, thanks Aaron :)
Gesendet mit meinem HTC
----- Nachricht beantworten -----
Von: "Aaron Halfaker" <ahalfaker(a)wikimedia.org>
An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>, "mobile-l" <mobile-l(a)lists.wikimedia.org>
Betreff: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile
Datum: Do., Apr. 30, 2015 01:09
Hey folks,
As requested, I started a research project page to do some analysis around
this. See
https://meta.wikimedia.org/wiki/Research:Mobile_anonymous_apocalypse
It's just a stub now. I'll have to clear a few other projects off my plate
in order to pick this one up. You should expect to see updates there in
2-3 weeks.
-Aaron
On Wed, Apr 29, 2015 at 12:10 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> On Wed, Apr 29, 2015 at 8:19 AM, Robert Rohde <rarohde(a)gmail.com> wrote:
> >
> > On Tue, Apr 28, 2015 at 10:31 PM, Jon Robson <jrobson(a)wikimedia.org>
> wrote:
> >
> > > <snip>
> >
> > Any community members interested in helping out here? I'm very sad the
> > > increase in errors wasn't picked up sooner... :-/
> > >
> >
> > What does event_action = 'error' actually mean?
> >
> > If the action is stopped by the AbuseFilter is that counted as an
> "error"?
>
> It means at some point during the editing workflow the user hit an
> error that stopped them from finishing their edit.
> We do capture AbuseFilter hits in this process (but with some of these
> errors you can recover and complete the edit.
>
> We also store the error associated, although a quick scan shows this
> is currently not very helpful.
>
> In theory 'http' error should only happen when a user cannot get an
> edit token - I've updated the bug for those interested.
>
> >
> > -Robert
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojona
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi,
I'm still trying to figure out what's the best solution for mobile
subdomains combined with file caching.
I'm planning to copy the MediaWiki installation files for the mobile
version to a separate folder (m) and link the subdomain to that folder
while using the same database like the desktop version. Or is there a
better way?
Can it cause any problems if one database shares two installations?
My setup:
OpenBSD 5.7
nginx 1.7.10
MediaWiki 1.25.1
PHP 5.4.38 (fpm-fcgi)
MariaDB 10.0.16-MariaDB-log
LocalSettings.php:
# Memcached
$wgMainCacheType = CACHE_MEMCACHED;
$wgParserCacheType = CACHE_MEMCACHED; # optional
$wgMessageCacheType = CACHE_MEMCACHED; # optional
$wgMemCachedServers = array( "127.0.0.1:11211" );
$wgSessionsInMemcached = true; # optional
$wgUseGzip = true;
$wgEnableSidebarCache = true;
# File cache
$wgUseFileCache = true; /* default: false */
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
# Text cache
$wgCompressRevisions = true;
$wgRevisionCacheExpiry = 3*24*3600;
$wgParserCacheExpireTime = 14*24*3600;
# NO DB HITS!
$wgDisableCounters = true;
$wgMiserMode = true;
# MySQL performance tuning
$wgAntiLockFlags = ALF_NO_LINK_LOCK | ALF_NO_BLOCK_LOCK;
# Image performance tuning
$wgShowArchiveThumbnails = false;
# cron performance tuning
$wgJobRunRate = 0;
Thanks and cheers!
Till
