[Wikitech-l] Re: ORES To Lift Wing Migration
Hi Chris, On Mon, Aug 7, 2023 at 11:51 AM Chris Albon wrote: > Hi Tilman, > > Most of the work is still very experimental. We have hosted a few LLMs on > Lift Wing already (StarCoder for example) but they were just running on > CPU, far too slow for real use cases. But it proves that we can easily host > LLMs on Lift Wing. We have been pretty quiet about it while we focus on the > ORES migration, but it is our next big project. More soon hopefully! > Understood. Looking forward to learning more later! > Where we are now is that we have budget for a big GPU purchase (~10-20 > GPUs depending on cost), the question we will try to answer after the ORES > migration is complete is: what GPUs should we purchase? We are trying to > balance our strong preference to stay open source (i.e. AMD mROC) in a > world dominated by a single closed source vendor (i.e. Nvidia). In > addition, do we go for a few expensive GPUs better suited to LLMs (A1000, > H100, etc) or a mix of big and small? We will need to figure out all this. > I see. On that matter, what do you folks make of the recent announcements of AMD's partnerships with Hugging Face and Pytorch[5]? (which, I understand, came after the ML team had already launched the aforementioned new AMD explorations) "Open-source AI: AMD looks to Hugging Face and Meta spinoff PyTorch to take on Nvidia [...] Both partnerships involve AMD’s ROCm AI software stack, the company’s answer to Nvidia’s proprietary CUDA platform and application-programming interface. AMD called ROCm an open and portable AI system with out-of-the-box support that can port to existing AI models. [...B]oth AMD and Hugging Face are dedicating engineering resources to each other and sharing data to ensure that the constantly updated AI models from Hugging Face, which might not otherwise run well on AMD hardware, would be “guaranteed” to work on hardware like the MI300X. [...] AMD said PyTorch will fully upstream the ROCm software stack and “provide immediate ‘day zero’ support for PyTorch 2.0 with ROCm release 5.4.2 on all AMD Instinct accelerators,” which is meant to appeal to those customers looking to switch from Nvidia’s software ecosystem." In their own announcement, Hugging Face offered further details, including a pretty impressive list of models to be supported:[6] "We intend to support state-of-the-art transformer architectures for natural language processing, computer vision, and speech, such as BERT, DistilBERT, ROBERTA, Vision Transformer, CLIP, and Wav2Vec2. Of course, generative AI models will be available too (e.g., GPT2, GPT-NeoX, T5, OPT, LLaMA), including our own BLOOM and StarCoder models. Lastly, we will also support more traditional computer vision models, like ResNet and ResNext, and deep learning recommendation models, a first for us. [..] We'll do our best to test and validate these models for PyTorch, TensorFlow, and ONNX Runtime for the above platforms. [...] We will integrate the AMD ROCm SDK seamlessly in our open-source libraries, starting with the transformers library." Do you think this may promise too much, or could it point to a possible solution of the Foundation's conundrum? In any case, this seems to be an interesting moment where many in AI are trying to move away from Nvidia's proprietary CUDA platform. Most of them probably more for financial and availability reasons though, given the current GPU shortages[7] (which the ML team is undoubtedly aware of already; mentioning this as context for others on this list. See also Marketwatch's remarks about current margins[5]). Regards, Tilman [5] https://archive.ph/2023.06.15-173527/https://www.marketwatch.com/amp/story/open-source-ai-amd-looks-to-hugging-face-and-meta-spinoff-pytorch-to-take-on-nvidia-e4738f87 [6] https://huggingface.co/blog/huggingface-and-amd [7] See e.g. https://gpus.llm-utils.org/nvidia-h100-gpus-supply-and-demand/ (avoid playing the song though. Don't say I didn't warn you) > I wouldn't characterize WMF's Language Team using CPU as because of AMD, > rather at the time we didn't have the budget for GPUs so Lift Wing didn't > have any. Since then we have moved two GPUs onto Lift Wing for testing but > they are pretty old (2017ish). Once we make the big GPU purchase Lift Wing > will gain a lot of functionality for LLM and similar models. > > Chris > > On Sun, Aug 6, 2023 at 9:57 PM Tilman Bayer wrote: > >> On Thu, Aug 3, 2023 at 7:16 AM Chris Albon wrote: >> >>> Hi everybody, >>> >>> TL;DR We would like users of ORES models to migrate to our new open >>> source ML infrastructure, Lift Wing, within the next five months. We are >>> available to help you do that, from advice to making code commits. It is >>> important to note: All ML models currently accessible on ORES are also >>> currently accessible on Lift Wing. &
[Wikitech-l] Re: ORES To Lift Wing Migration
On Thu, Aug 3, 2023 at 7:16 AM Chris Albon wrote: > Hi everybody, > > TL;DR We would like users of ORES models to migrate to our new open source > ML infrastructure, Lift Wing, within the next five months. We are available > to help you do that, from advice to making code commits. It is important to > note: All ML models currently accessible on ORES are also currently > accessible on Lift Wing. > > As part of the Machine Learning Modernization Project ( > https://www.mediawiki.org/wiki/Machine_Learning/Modernization), the > Machine Learning team has deployed a Wikimedia’s new machine learning > inference infrastructure, called Lift Wing ( > https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing). Lift Wing > brings a lot of new features such as support for GPU-based models, open > source LLM hosting, auto-scaling, stability, and ability to host a larger > number of models. > This sounds quite exciting! What's the best place to read up on that planned support for GPU-based models and open source LLMs? (I also saw in the recent NYT article[1] that the team is "in the process of adapting A.I. models that are 'off the shelf; — essentially models that have been made available by researchers for anyone to freely customize — so that Wikipedia’s editors can use them for their work.") I'm aware of the history[2] of not being able to use NVIDIA GPUs due to their CUDA drivers being proprietary. It was mentioned recently in the Wikimedia AI Telegram group that this is still a serious limitation, despite some new explorations with AMD GPUs[3] - to the point that e.g. the WMF's Language team has resorted to using models without GPU support (CPU only).[4] It sounds like there is reasonable hope that this situation could change fairly soon? Would it also mean both at the same time, i.e. open source LLMs running with GPU support (considering that at least some well-known ones appear to require torch.cuda.is_available() == True for that)? Regards, Tilman [1] https://www.nytimes.com/2023/07/18/magazine/wikipedia-ai-chatgpt.html [2] https://techblog.wikimedia.org/2020/04/06/saying-no-to-proprietary-code-in-production-is-hard-work-the-gpu-chapter/ [3] https://phabricator.wikimedia.org/T334583 etc. [4] https://diff.wikimedia.org/2023/06/13/mint-supporting-underserved-languages-with-open-machine-translation/ or https://thottingal.in/blog/2023/07/21/wikiqa/ (experimental but, I understand, written to be deployable on WMF infrastructure) > > With the creation of Lift Wing, the team is turning its attention to > deprecating the current machine learning infrastructure, ORES. ORES served > us really well over the years, it was a successful project but it came > before radical changes in technology like Docker, Kubernetes and more > recently MLOps. The servers that run ORES are at the end of their planned > lifespan and so to save cost we are going to shut them down in early 2024. > > We have outlined a deprecation path on Wikitech ( > https://wikitech.wikimedia.org/wiki/ORES), please read the page if you > are a maintainer of a tool or code that uses the ORES endpoint > https://ores.wikimedia.org/). If you have any doubt or if you need > assistance in migrating to Lift Wing, feel free to contact the ML team via: > > - Email: m...@wikimedia.org > - Phabricator: #Machine-Learning-Team tag > - IRC (Libera): #wikimedia-ml > > The Machine Learning team is available to help projects migrate, from > offering advice to making code commits. We want to make this as easy as > possible for folks. > > High Level timeline: > > **By September 30th 2023: *Infrastructure powering the ORES API endpoint > will be migrated from ORES to Lift Wing. For users, the API endpoint will > remain the same, and most users won’t notice any change. Rather just the > backend services powering the endpoint will change. > > Details: We'd like to add a DNS CNAME that points ores.wikimedia.org to > ores-legacy.wikimedia.org, a new endpoint that offers a almost complete > replacement of the ORES API calling Lift Wing behind the scenes. In an > ideal world we'd migrate all tools to Lift Wing before decommissioning the > infrastructure behind ores.wikimedia.org, but it turned out to be really > challenging so to avoid disrupting users we chose to implement a transition > layer/API. > > To summarize, if you don't have time to migrate before September to Lift > Wing, your code/tool should work just fine on ores-legacy.wikimedia.org > and you'll not have to change a line in your code thanks to the DNS CNAME. > The ores-legacy endpoint is not a 100% replacement for ores, we removed > some very old and not used features, so we highly recommend at least test > the new endpoint for your use case to avoid surprises when we'll make the > switch. In case you find anything weird, please report it to us using the > aforementioned channels. > > **September to January: *We will be reaching out to every user of ORES we > can identify and working with them to make the
Re: [Wikitech-l] Dead Links
On Mon, Apr 2, 2018 at 7:52 AM, Chad <innocentkil...@gmail.com> wrote: > On Sun, Apr 1, 2018 at 4:43 PM <ad...@gunsense.xyz> wrote: > > > hi, is this list active? > > > > there appears to be a dead link on the group page pointing to this list: > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > dead link: > > "You can also use the gmane web interface for reading AND posting to the > > list. > > http://news.gmane.org/gmane.science.linguistics.wikipedia.technical/; > > > > > I removed most of the information about Gmane. > > https://meta.wikimedia.org/wiki/Mailing_lists/Overview also needs cleanup in this regard, but that should probably be a larger effort across many mailing lists. -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats 2.0 - Now with Maps!
The number of active editors for all projects is a core metric that WMF has tracked and reported on a regular basis since at least 2011 (with the definition having been revised in the last year or two). https://www.mediawiki.org/wiki/Wikimedia_Audiences#Contributors https://stats.wikimedia.org/reportcard/RC_2011_12_detailed.html https://meta.wikimedia.org/wiki/Research:Active_editor https://meta.wikimedia.org/wiki/Research:Defining_ monthly_active_editors,_2016 How is this new metric going to differ from that? Or are we talking about the same thing? On Mon, Feb 26, 2018 at 8:42 AM, Nuria Ruiz <nu...@wikimedia.org> wrote: > Created a ticket to compute "active editors for all wikis": > https://phabricator.wikimedia.org/T188265 > > On Sat, Feb 24, 2018 at 3:56 PM, Nuria Ruiz <nu...@wikimedia.org> wrote: > > > >By the way, is there somewhere where I could find total active editors > > of all wikisources? > > > > All projects agreggated? Not as far as I know. More than a matter of > > calculation I think is a matter of definition. I might be wrong though > and > > this might already have been discussed. > > > > Active editor metric is defined "per wiki" to my knowledge: https://meta > . > > wikimedia.org/wiki/Research:Wikistats_metrics/Editors > > > > For all projects you could add "all active editors for all projects" and > > that is doable. Now, in that case you will not count someone with 2 > edits > > in eswiki and (using same login) another 3 edits on dewiki if in order to > > become an "active editor" you need 5 edits in one wiki. > > > > Phab ticket filed: https://phabricator.wikimedia.org/T188194 > > > > > > > > > > > > > > On Thu, Feb 22, 2018 at 1:37 AM, mathieu stumpf guntz < > > psychosl...@culture-libre.org> wrote: > > > >> Hi Nuria, > >> > >> Thank you for the report, and congratulation to all people involved in > >> releasing this tool. It would be fine to also have map with editiors and > >> active editors. > >> > >> By the way, is there somewhere where I could find total active editors > of > >> all wikisources? Surely I could sum that through API (providing that it > >> exposes such a data for each language), but it would be fine that > everybody > >> could have a straight forward access to this kind of cross language > data. I > >> think there real are usecases for that, actually I'm looking for number > of > >> active wikisourcerer to evaluate number of attendees we might set for > the > >> next Wikisource conference. > >> > >> Cheers. > >> > >> Le 14/02/2018 à 23:15, Nuria Ruiz a écrit : > >> > >> Hello from Analytics team: > >> > >> Just a brief note to announce that Wikistats 2.0 includes data about > >> pageviews per project per country for the current month. > >> > >> Take a look, pageviews for Spanish Wikipedia this current month: > https://stats.wikimedia.org/v2/#/es.wikipedia.org/read > ing/pageviews-by-country > >> > >> Data is also available programatically vi APIs: > >> https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageviews# > Pageviews_split_by_country > >> > >> > >> We will be deploying small UI tweaks during this week but please explore > >> and let us know what you think. > >> > >> Thanks, > >> > >> Nuria > >> ___ > >> Wikitech-l mailing listWikitech-l@lists.wikimedia.orghttps:// > lists.wikimedia.org/mailman/listinfo/wikitech-l > >> > >> > >> > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sitelink removal in Wikidata
This looks great! Would it be possible to make a modified version that lists description edits in a particular language (instead of sitelink edits for a particular project)? This should be very useful for targeted patrolling too; it came up as a suggestion in the Wikidata project chat last week. Technically, it should be a relatively simple change, querying for "wbsetdescription" instead of "wbsetsitelink-remove". (More generally, there is https://phabricator.wikimedia.org/T141866 "Provide a way to filter Wikidata's recent changes for language-dependent content in specific languages", but that looks like a larger project.) On Tue, Apr 25, 2017 at 8:30 PM, Amir Ladsgroup <ladsgr...@gmail.com> wrote: > Hey, > One common form of vandalism in Wikidata is removing sitelinks (we already > have an abuse filter flagging them). > One of my friends in Persian Wikipedia (who is not a wikidata editor and > only cares about Persian Wikipedia) asked me to write a tool that lists all > Persian Wikipedia sitelink removals. So I wrote something small and fast > but it's usable for any wiki. For example English Wikipedia: > http://tools.wmflabs.org/dexbot/tools/deleted_sitelinks.php?wiki=enwiki > > It's slow due to nature of the database query but once it responds, you > might find good things to revert. > > Since this is the most useful for Wikipedia editors who don't want to > patrol Wikidata (in that case, this query > <https://www.wikidata.org/w/index.php?namespace=; > tagfilter=new+editor+removing+sitelink= > noaction=Special%3ARecentChanges> > is > the most useful) I'm reaching to wider audiences. Sorry for spamming. > > HTH > Best > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [BREAKING CHANGE] Internet Explorer 9 will be JavaScript-less starting April 2017
BTW, when looking at these stats, note also that the percentage for IE7 (2.9% recently) is likely inflated due to unidentified bot traffic: https://phabricator.wikimedia.org/T148461#3011175 https://phabricator.wikimedia.org/T157404 On Mon, Mar 20, 2017 at 11:07 AM, James Forrester <jforres...@wikimedia.org> wrote: > On Mon, 20 Mar 2017 at 07:19 Joaquin Oltra Hernandez < > jhernan...@wikimedia.org> wrote: > >> Great news! >> >> Have we considered dropping IE 10 to grade C given Microsoft ended support >> for it more than a year ago and it seems to be as low as IE 9 (only a 0.24% >> *[1]*)? >> > > Certainly, that would be the next step. I think that the additional burden > of IE10 over IE11 is relatively slight, so I'd probably recommend keeping > it in Grade A for at least a few months more, unless there's an urgent > need. As always, each non-core feature needs to decide for itself what > support level is provided for older browsers. > > (Last week, IE10 is down to 0.22%, BTW — lower than IE4, let alone IE6.) > > >> Also, a question. Does this mean we don't need to explicitly list the >> *es5-shim* any more? >> > > Yes, this will mean that. But not until the patch[*] is merged, at which > point depending on es5-shim will become a no-op with a deprecation notice > (and I'll do patches to fix up WMF-production extensions). > > [*] - https://gerrit.wikimedia.org/r/#/c/340893/ > -- > > James D. Forrester > Lead Product Manager, Editing > Wikimedia Foundation, Inc. > jforrester at wikimedia.org > <https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> | > @jdforrester > _______ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What happened to RobLa?
On Tue, Nov 1, 2016 at 3:54 AM, Federico Leva (Nemo) <nemow...@gmail.com> wrote: > As a reminder on goodbyes, WMF HR used to announce everyone's last day at > https://identi.ca/wikimediaatwork (can't take more than a couple > minutes); then the announcements became monthly, then quarterly; then we > lost this courtesy as well https://meta.wikimedia.org/wik > i/Talk:Wikimedia_Foundation_reports#Staff . As already noted higher up on that talk page, that's a misconception. Timely updates now happen on the WMF wiki instead, where RobLa's departure had already been recorded by HR before you sent this email: https://wikimediafoundation.org/w/index.php?title=Template:Staff_and_ contractors=history > -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phab blogs
(For the record, the aforementioned comments bug has now been resolved, thanks to the efforts of Paladox and others.) On Fri, Sep 2, 2016 at 12:08 PM, Mukunda Modell <mmod...@wikimedia.org> wrote: > > The phame blogs are simply a convenient way to get phabricator related > announcements posted on the from page of phabricator. Actually other teams have already begun using them for other topics besides Phabricator-related announcements, see https://phabricator.wikimedia.org/phame/blog/ . And more teams might follow. Which is a good reason to give the advantages and disadvantages of this new communication platform some more thought - before we get locked into it by accident and it might become another area where donor dollars have to be spent paying the upstream company to make sure Phabricator fulfills our needs (cf. below). > > The topics posted > their are also cross-posed to this list as the intended audience is mostly > the same. I can't find an equivalent of the following post in the archives of this list: https://phabricator.wikimedia.org/phame/post/view/9/sponsored_phabricator_improvements/ . That's despite its topic having been the subject of extensive discussion on the list not long before the post was published: http://www.gossamer-threads.com/lists/wiki/wikitech/710067 . (In any case, that was separate from the problem that Phame blogs didn't allow comments. Even if it had been true that all these announcements are cross-posted to this list, that would still not have helped someone who encountered them on Phabricator and did not have the insider knowledge that one can try to search the Wikitech list archives for a discussion of an announcement and sign up to the list for an opportunity to comment.) > > > On Wed, Aug 31, 2016 at 4:37 AM, Quim Gil <q...@wikimedia.org> wrote: > > > Hi, > > > > On Wed, Aug 31, 2016 at 8:03 AM, Tilman Bayer <tba...@wikimedia.org> > > wrote: > > > > > Apparently there hasn't been much discussion or deliberation about the > > > advantages and disadvantages of this new feature compared to other > > > communication channels. > > > > > > Excess of communication channels is a big problem in Wikimedia and a > > regular topic for complaints from new and experienced contributors > > (volunteers or paid, tech or non-tech). I think such discussion about > > advantages and disadvantages should happen before we invest too much > > content and attention in Phabricator blogs. > > +1. Back in 2014, before the launch of the Wikimedia Phabricator instance, the team did a great job in surveying needs and alternatives, reaching out to stakeholders, holding an RfC etc. Balkanization of communication venues was very much seen as a concern then. (For example, various teams at WMF were strongly encouraged to move their project management activities from Mingle, Trello etc. to Phabricator. Which is what happened.) The extension of Phabricator to some other areas since then (e.g. code review) has likewise been approached with a lot of diligence and inclusion. I'm not sure though this can said for all parts of the platform. -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phab blogs
Apparently there hasn't been much discussion or deliberation about the advantages and disadvantages of this new feature compared to other communication channels. An essential functionality that seems to be missing compared to standard blog software (and indeed the venues that we normally use in the Wikimedia movement for announcements of the kind that now appear in Phame) is a comment function - there is no backchannel to ask questions etc. Filed as https://phabricator.wikimedia.org/T144338 On Tue, May 17, 2016 at 10:39 PM, Amir E. Aharoni <amir.ahar...@mail.huji.ac.il> wrote: > Hi, > > I only now noticed that Phabricator has blogs: > https://phabricator.wikimedia.org/phame/blog/ > > I couldn't find a way to subscribe to them in RSS. Is it possible? > > -- > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי > http://aharoni.wordpress.com > “We're living in pieces, > I want to live in peace.” – T. Moore > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the timespan until July 31, 2016
pp’s
pageviews back in May, by around 20%. (Because of the app’s small share in
overall traffic, it did not affect the global pageviews discussed above in
a notable way.) After some investigation, it turned out this coincided with
the release of version 5.0.3 of the app, see the yellow slice on the right:
Josh and I are planning to look further into possible causes; at the moment
it’s still possible that this is either an artefact or due to real
improvements in the app.
For reference, the queries and source links used are listed below (access
is needed for each). Unless otherwise noted, all content of this report is
© Wikimedia Foundation and released under the CC BY-SA 3.0
<https://creativecommons.org/licenses/by-sa/3.0/> license. Most of the
above charts are available on Commons, too
<https://commons.wikimedia.org/w/index.php?title=Special:ListFiles=2015092301=Tbayer+%28WMF%29=1=4>;
together with PDF versions of this report.
SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews,
SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year>0 AND
agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day
LIMIT 1000;
SELECT LEFT(timestamp, 10) AS date, sum(IF(access_method <> 'desktop',
pageviews, null)) AS mobileviews, SUM(pageviews) AS allviews FROM
staging.pageviews05 WHERE is_spider = FALSE AND is_automata = FALSE GROUP
BY date;
SELECT access_method, SUM(view_count)/(7*14) FROM wmf.projectview_hourly
WHERE agent_type = 'user' AND
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2016-04-25"
AND "2016-07-31" GROUP BY access_method;
SELECT year, month, day,
CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS
all, SUM(IF (FIND_IN_SET(country_code,
'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US')
> 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly
WHERE year > 0 AND agent_type='user' GROUP BY year, month, day ORDER BY
year, month, day LIMIT 1000;
https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/
(“overview”)
https://www.appannie.com/dashboard/252257/item/324715238/downloads/ (select
“Total”)
SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1,
0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS
day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE
'%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE;
(with the retention rate calculated as day7_active divided by day0_active
from seven days earlier, of course)
SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE
platform = 'Android';
SELECT year, month, day,
CONCAT(year,'-',LPAD(month,2,'0'),'-',LPAD(day,2,'0')) AS date,
CONCAT(SPLIT(user_agent_map['wmf_app_version'], '\\.')[0],
COALESCE( CONCAT('.', SPLIT(user_agent_map['wmf_app_version'], '\\.')[1]),
''),
COALESCE( CONCAT('.', SPLIT(user_agent_map['wmf_app_version'], '\\.')[2]),
''))
AS app_version,
SUM(view_count) AS views
FROM wmf.pageview_hourly
WHERE year >0 AND access_method = 'mobile app'
AND user_agent_map['os_family'] = 'iOS' AND agent_type = 'user'
GROUP BY year, month, day, user_agent_map['wmf_app_version']
ORDER BY year, month, day, app_version LIMIT 2;
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] "Among mobile sites, Wikipedia reigns in terms of popularity"
New study (US only) by the Knight Foundation: https://medium.com/mobile-first-news-how-people-use-smartphones-to , summarized here: http://www.theatlantic.com/technology/archive/2016/05/people-love-wikipedia/482268/ "People spent more time on Wikipedia’s mobile site than any other news or information site in Knight’s analysis, about 13 minutes per month for the average visitor. CNN wasn’t too far behind, at 9 minutes 45 seconds per month. BuzzFeed clocked in third at 9 minutes 21 seconds per month. (BuzzFeed, however, slays both CNN and Wikipedia in time spent with the sites’ apps, compared with mobile websites. BuzzFeed users devote more than 2 hours per month to its apps, compared with about 46 minutes among CNN app users and 31 minutes among Wikipedia app loyalists.) Another way to look at Wikipedia’s influence: Wikipedia reaches almost one-third of the total mobile population each month, according to Knight’s analysis, which used data from the audience-tracking firm Nielsen." -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the timespan until April 24, 2016
, there is currently no valid data for this metric because of issues having to do with the app’s recent switch to the RESTBase-based Content Service, see T132965 <https://phabricator.wikimedia.org/T132965>. (I might still have included the usual 3-month chart showing the development up to that point, but as I’m writing this, Google Sheets doesn’t let you <https://productforums.google.com/forum/#!msg/docs/yB_xNk6mn8U/QjRDR4WtNAAJ> create timeline charts that include the month of February. True story; this report covers not one but two severe bugs in Google products ;) The linked bug contains a chart with a different timespan though - keep in mind that the decline visible from the beginning April is artificial.) iOS: N/A With the new 5.0 version that launched in March, only a small minority of devices continue to send the data that this metric is based on (T130432 <https://phabricator.wikimedia.org/T130432>), so it is no longer valid as a measure of the apps overall usage volume. Data sources For reference, the queries and source links used are listed below (access is needed for each). Unless otherwise noted, all content of this report is © Wikimedia Foundation and released under the CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0/> license. Most of the above charts are available on Commons, too <https://commons.wikimedia.org/w/index.php?title=Special:ListFiles=2015092301=Tbayer+%28WMF%29=1=4> . hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year>0 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/77 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2016-02-08" AND "2016-04-24" GROUP BY access_method; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year > 0 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/ (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE timestamp LIKE '2016%' AND userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tech Talk: New Readership Data: March 18th
The slides are up here BTW: https://commons.wikimedia.org/wiki/File:New_readership_data_(Wikimedia_Foundation_Tech_Talk).pdf Thanks to all who attended, or gave input on the presentation beforehand! On Mon, Mar 14, 2016 at 10:05 PM, Rachel Farrand <rfarr...@wikimedia.org> wrote: > Please join for the following tech talk: > > *Tech Talk**:* New readership data: Some things we've been learning > recently about how Wikipedia is read > *Presenter:* Tilman Bayer > *Date:* March 18th, 2016 > *Time: *18:00 UTC > <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+New+readership+data%3A+Some+things+we%27ve+been+learning+recently+about+how+Wikipedia+is+read=20160318T18=1440=1> > Link to live YouTube stream <http://www.youtube.com/watch?v=Qo4XIzCJZVs> > *IRC channel for questions/discussion:* #wikimedia-office > > *Summary: *This talk will highlight various recent insights and new sources > of data on how readers read Wikipedia, going beyond the familiar pageview > numbers (that tell us which topics are popular and how overall traffic is > developing, but not e.g. which parts of articles are being read). While we > are still only beginning to understand some of these aspects, we now know > more than a year or two ago. The presentation is centered around data > analysis done by the Reading team, but will also include findings by other > WMF teams and by external researchers. > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Readership metrics for the two months until February 7, 2016
Hi Orsolya, a PDF copy is at https://commons.wikimedia.org/wiki/File:Readership_metrics_for_the_two_months_until_February_7,_2016.pdf (previous reports and various charts are also available at https://commons.wikimedia.org/wiki/Category:Wikimedia_readership_metrics_reports ) And of course these mailing lists have public archives too, although they don't play very well with HTML attachments ( https://lists.wikimedia.org/pipermail/mobile-l/2016-February/010096.html ). On Fri, Feb 19, 2016 at 11:01 AM, Orsolya Gyenes < gyenes.orso...@wiki.media.hu> wrote: > Dear Tilman, > > Can you provide a link for this summary below? > > Thank you, > > *~Orsolya* > > 2016-02-18 23:37 GMT+01:00 Tilman Bayer <tba...@wikimedia.org>: > >> Hi all, >> >> this resumes the usual look at our most important readership metrics. >> Among other things, this time we observe the annual Christmas slump in >> pageviews, hail the advent of the mobile singularity (December saw the >> first ever day with >50% mobile pageviews), and resolve the mystery of the >> Android app’s installation drop since mid November. >> >> As laid out earlier >> <https://lists.wikimedia.org/pipermail/mobile-l/2015-September/009773.html>, >> the main purpose is to raise awareness about how these are developing, call >> out the impact of any unusual events in the preceding week, and facilitate >> thinking about core metrics in general. We are still iterating on the >> presentation; feedback and discussion welcome. >> >> After switching away from the weekly schedule (week-over-week and >> month-over-month changes are now being recorded on the Product page >> <https://www.mediawiki.org/wiki/Wikimedia_Product#Reading> at >> MediaWiki.org) we also skipped an issue and added one week, so this edition >> of the report covers a timespan of nine weeks. >> >> See also the slides from the Reading team’s quarter review meeting >> <https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Reading_and_Community_Tech,_January_2016> >> on January 20 for an in-depth look at various metrics. >> >> Now to the usual data. (All numbers below are averages for December 7, >> 2015 to February 7, 2016 unless otherwise noted.) >> >> Pageviews >> >> Total: 529 million/day >> >> Context (April 2015-February 2016): >> >> >> >> (see also the Vital Signs dashboard >> <https://vital-signs.wmflabs.org/#projects=all/metrics=Pageviews>) >> >> Total pageviews saw a sharp drop about a week before Christmas (almost >> entirely on desktop), coinciding with a drop >> <http://discovery.wmflabs.org/external/#traffic_by_engine> in Google >> referrals. But both recovered in early January, even rising above earlier >> levels, thanks to mobile (cf. below). Historical data from one and two >> years ago shows a very similar slump in total and desktop pageviews in the >> second half of December (with a lasting increase in mobile around >> Christmas, too), so I’m interpreting this as seasonal even though it >> preceded the actual holidays by a few days. In January 2014, traffic did >> not fully recover to the levels of November/early December. In January >> 2015, it rose slightly above them, similar to now. >> >> Desktop: 54.3% >> >> Mobile web: 44.4% >> >> Apps: 1.3% >> >> Context (April 2015-February 2016): >> >> >> December 20, 2015 will forever be engraved in Wikimedia history as the >> first day where mobile pageviews surpassed desktop pageviews (51% vs. 49%). >> It was a Sunday - as we have known for a long time, mobile usage is higher >> on weekends. In general, the mobile percentage over a whole week still >> remains well below 50%. But even as desktop pageviews recovered from the >> Christmas slump at the beginning of January, the mobile percentage remains >> roughly 2% higher than before mid-December - quite likely due to a lot of >> new phones entering usage as Christmas presents. >> >> Global North ratio: 78.3% of total pageviews >> >> Context (April 2015-February 2016): >> >> New app installations >> >> Android: 38.4k/day >> >> Daily installs per device, from Google Play >> >> Context (January 2015-February 2016): >> >> As reported earlier, the app was featured twice on Google Play in recent >> months, and we can now estimate how many additional installs each may have >> caused. November’s placement in the “new and updated” section appears to >> have brought in more than 200k installs, and from
[Wikitech-l] Readership metrics for the two months until February 7, 2016
tio of app installs opened again 7 days after installation, among all installed during the previous week. From iTunes Connect, opt-in only = ca. 20-30% of all users) As reported earlier, we encountered data quality issues with this metric. We eventually received an explanation from Apple last week, but it doesn’t look very satisfactory for our purposes. We are now working <https://phabricator.wikimedia.org/T126693> to measure retention ourselves via EventLogging, like we do on Android. Unique app users Android: 1.206 million / day Context (last four months): A clearly visible and lasting increase around Christmas, which again indicates that the retention rates for the install peak around that time were higher than during the install peaks caused by the Google Play promotions (even though they resulted in more installs initially). iOS: 303 k / day Context (last four months): Similar to Android, a clearly visible and lasting increase around Christmas. For reference, the queries and source links used are listed below (access is needed for each). Unless otherwise noted, all content of this report is © Wikimedia Foundation and released under the CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0/> license. Most of the above charts are available on Commons, too <https://commons.wikimedia.org/w/index.php?title=Special:ListFiles=2015092301=Tbayer+%28WMF%29=1=4> . hive (wmf)> SELECT SUM(view_count)/(700*9) AS avg_daily_views_millions FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year > 0 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/7 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year > 0 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdown=country=2015-12-07~2016-02-07_type=downloads=ALL (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia dumps
On Sun, Jan 10, 2016 at 4:05 PM, Bernardo Sulzbach < mafagafogiga...@gmail.com> wrote: > On Sun, Jan 10, 2016 at 9:55 PM, Neil Harris <n...@tonal.clara.co.uk> > wrote: > > Hello! I've noticed that no enwiki dump seems to have been generated so > far > > this month. Is this by design, or has there been some sort of dump > failure? > > Does anyone know when the next enwiki dump might happen? > > > > I would also be interested. > > -- > Bernardo Sulzbach > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > CCing the Xmldatadumps mailing list <https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l>, where someone has already posted <https://lists.wikimedia.org/pipermail/xmldatadumps-l/2016-January/001214.html> about what might be the same issue. -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the fortnight until December 6, 2015
;)) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/14 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23" AND "2015-12-06" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-23" AND "2015-12-06"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; SELECT country_code, changeratio, ROUND(milliondailyviewsthisweek,1) AS milliondailyviewsthisweek FROM (SELECT country_code, ROUND(100*SUM(IF(day>22 AND day<30, view_count, null))/SUM(IF(day>15 AND day < 23, view_count, null))-100,1) AS changeratio, SUM(IF(day>22 AND day<30, view_count, null))/700 AS milliondailyviewsthisweek FROM wmf.projectview_hourly WHERE year = 2015 AND month = 11 AND agent_type = "user" GROUP BY country_code) AS countrylist WHERE milliondailyviewsthisweek > 1 GROUP BY country_code, changeratio, milliondailyviewsthisweek ORDER BY ABS(changeratio) DESC LIMIT 10; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdown=country=2015-09-08~2015-12-06_type=downloads=ALL (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active seven days later divided by day0_active from the install date) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151123 AND 20151206; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the week until November 22, 2015
me, and watching its texture change over time, you will come to have ideas about it,” he said. “You will come to understand it in a new way, and you will contribute in a very small way to how society addresses this big problem.” [...] So it seemed as if a newsletter might be a good way to cover the issue. [...] “You can get a continuity of storyline,” Meyer said. “You can’t cover all of everything that’s happening every week in the climate, but you can watch certain parts develop, and hopefully bring people in over time.” He leads off the “Macro Trends” section of each issue with the molecules per million of carbon dioxide in the atmosphere: The atmosphere is filling with greenhouse gases. The Mauna Loa Observatory measured an average of 398.51 CO2 molecules per million in the atmosphere this week. A year ago, it measured 395.84 ppm. Ten years ago, it measured 376.93 ppm. “What we’re doing now won’t show up in that number for a decade or so,” he said. “But by reminding myself of it every week, and thinking about its contours and its direction, that’s a way to stay focused on what matters.” For reference, the queries and source links used are listed below (access is needed for each). Most of the above charts are available on Commons, too <https://commons.wikimedia.org/w/index.php?title=Special:ListFiles=2015092301=Tbayer+%28WMF%29=1=4> . hive (wmf)> SELECT SUM(view_count)/700 AS avg_daily_views_millions FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-16" AND "2015-11-22"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/7 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-16" AND "2015-11-22" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-16" AND "2015-11-22"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdown=country=2015-08-25~2015-11-22_type=downloads=ALL (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE timestamp LIKE '201511%' AND userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151116 AND 20151122; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the week until November 15, 2015
previous week) Context (last three months): No news here. For reference, the queries and source links used are listed below (access is needed for each). Most of the above charts are available on Commons, too <https://commons.wikimedia.org/w/index.php?title=Special:ListFiles=2015092301=Tbayer+%28WMF%29=1=4> . hive (wmf)> SELECT SUM(view_count)/700 AS avg_daily_views_millions FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-09" AND "2015-11-15"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/7 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-09" AND "2015-11-15" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-09" AND "2015-11-15"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdown=country=2015-08-11~2015-11-08_type=downloads=ALL (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE timestamp LIKE '201511%' AND userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151109 AND 20151115; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Readership metrics for the week until November 8, 2015
uot; AND "2015-11-08" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-11-02" AND "2015-11-08"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year = 2015 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_02812522755211381933/stats/installs/ (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdown=country=2015-08-11~2015-11-08_type=downloads=ALL (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE timestamp LIKE '201510%' AND userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT SUM(IF(platform = 'Android',unique_count,0))/7 AS avg_Android_DAU_last_week, SUM(IF(platform = 'iOS',unique_count,0))/7 AS avg_iOS_DAU_last_week FROM wmf.mobile_apps_uniques_daily WHERE CONCAT(year,LPAD(month,2,"0"),LPAD(day,2,"0")) BETWEEN 20151102 AND 20151108; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tech Talk: Nothing Left but Always Right: The Twisted Road to RTL Support: November 2
On Tue, Nov 3, 2015 at 3:04 PM, Andre Klapper <aklap...@wikimedia.org> wrote: .. > > I once uploaded a Hangout/Youtube video to Commons by following > https://commons.wikimedia.org/wiki/Commons:YouTube_files > and it felt cumbersome - in my humble opinion our tool chain is > currently very "manual" in this area. Would love to see something > similar to the Flickr import support in UploadWizard. > In my experience - I have transferred quite a few metrics meeting videos to Commons - it's actually quite painless once one has settled on a download solution from that page and discovered https://tools.wmflabs.org/videoconvert for the conversion and upload steps (the only downside is that the video conversion is relatively slow with that tool). -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fiscal Year Q2 Engineering goals
Hi Pine, I can't speak for the team that is responsible for Flow. But perhaps you overlooked that a plan for such an opt-in system was already included in the September reprioritization announcement <https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/082993.html> which some (present company excluded) had their drama-and-doom focused mindset let them misinterpret as "Flow is getting killed". On Sun, Nov 1, 2015 at 7:30 PM, Pine W <wiki.p...@gmail.com> wrote: > Thanks Toby. > > Some of the goals for Research and Design Research particularly interest > me. > > Can you (or someone in Product and Engineering) clarify what is happening > with Flow? I thought that development status had changed to maintenance > only, but then I heard otherwise off-list, and now I see that there is a > Flow-related goal to "Increase access to Flow by deploying and supporting > an opt-in system for it". Deploying it sounds different than putting it > into maintenace-only status. Having Flow be opt-in will probably please > Flow's supporters, and hopefully will be a nice incremental way to > identify problems with it on a manageable scale, and to allow wikimarkup > users to continue to use that more flexible option. Is the plan to continue > an opt-in rollout and continue to allocate development resources for Flow > beyond minimal maintenance support? Clarification would be appreciated. > > (Side note: there are ongoing discussions about Flow on Lila's talk page on > Meta.) > > Thanks, > Pine > On Nov 1, 2015 7:01 PM, "Toby Negrin" <tneg...@wikimedia.org> wrote: > > > Hi Everyone -- > > > > A bit late but I wanted to let you know that the Engineering goals for > the > > 2d quarter (October to December) of this current Fiscal year are posted > on > > Mediawiki.org. > > > > https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals > > > > We'll be more timely in the future. Please reach out to the respective > goal > > owner identified in the wiki page for more information. > > > > -Toby > > ___ > > 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 > -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Foundation quarterly reviews for July-September 2015
Greetings everyone, the Wikimedia Foundation's quarterly reviews of teams' work in the past quarter (July-September, Q1 of the 2015-16 fiscal year) took place last week. Minutes and slides for those meetings are now available: Community Engagement: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Community_Engagement,_October_2015 Discovery: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Discovery,_October_2015 Reading and Advancement (with Fundraising Tech): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Reading_and_Advancement,_October_2015 Editing (comprising the Collaboration, Language Engineering, Multimedia, Parsing, and VisualEditor teams): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing,_October_2015 Infrastructure (comprising the Analytics, Release Engineering, Services, TechOps, and Labs teams) and CTO (comprising the Design Research, Research & Data, Performance, and Security teams): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Infrastructure_and_CTO,_October_2015 Legal, Talent & Culture (HR), Communications, Finance & Administration & Office IT, and Team Practices: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Legal,_HR,_Finance,_Communications,_TPG,_October_2015 As usual, much of this information will also be available in consolidated form as part of the general WMF quarterly report for Q1, which is planned to be published on October 19. See https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews for some general background about the Foundation's quarterly review process. -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Try the free Wikipedia app" banners
On Tue, Sep 1, 2015 at 8:10 PM, Oliver Keyes <oke...@wikimedia.org> wrote: > > What was the publicising of the campaign prior to its launch? > > It should be pretty apparent to people with experience within the > movement that this would be both entirely novel and pretty > controversial. As mentioned on the Phabricator ticked, this is by no means the first banner campaign inviting installation of an app. In June/July last year, there was a global campaign announcing the launch of the new Android app (like now, shown on mobile web for Android devices only): https://en.m.wikipedia.org/w/index.php?title=Special:Random=Wpapp2014Androidmobile_1=en=1 https://en.m.wikipedia.org/w/index.php?title=Special:Random=Wpapp2014Androidmobile_2=en=1 (also ran in a few other languages besides English) I don't recall it being controversial back then. And in 2013, the late Commons app was promoted in a similar campaign on desktop and mobile: https://en.wikipedia.org/w/index.php?title=Special:Random=CommonsAppnonmobilewp=en=1 (on desktop Wikipedia) https://commons.wikimedia.org/w/index.php?title=Special:Random=CommonsAppnonmobilecommons=en=1 (on Commons) https://en.m.wikipedia.org/w/index.php?title=Special:Random=AndroidCommonsApp=en=1 (mobile Wikipedia on Android devices) > I'd expect some amount of transparency around it (a > phabricator ticket is not, in and of itself, transparency). For those not familiar with the existing processes around banners, WMF staff and community members who use this indeed highly prominent space have been coordinating for years on this page: https://meta.wikimedia.org/wiki/CentralNotice/Calendar Quite a lot of people who care about banner use are watching it for controversial or problematic uses (https://meta.wikimedia.org/w/index.php?title=CentralNotice/Calendar=info#mw-pageinfo-watchers ), discussion happens on the talk page there or is escalated to other venues. I see that the current banners were indeed listed there last week before the launch. > To > contrast, with search when we make /experimental/ modifications to the > user experience of a tiny sample (through A/B testing) we not only > list those changes in phabricator but also send explicit mailing list > announcements - and those effect a smaller chunk of our user base on a > platform. Perhaps you could post some advice at https://meta.wikimedia.org/wiki/Talk:CentralNotice about how people running banners could learn from the WMF Discovery team in that respect? On Tue, Sep 1, 2015 at 8:30 AM, Ori Livneh <o...@wikimedia.org> wrote: > We appear to be running a banner campaign on the mobile web site, driving > people to download the mobile app: > > https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_2 > https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_1 > The links don't work for me (maybe because I'm not in Finland right now); you can append "force=1" to make them show regardless of targeting: https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_2=1 https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_1=1 -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] "Try the free Wikipedia app" banners
On Wed, Sep 2, 2015 at 11:22 AM, Brandon Harris <bhar...@gaijin.com> wrote: > >> On Sep 2, 2015, at 11:17 AM, Gergo Tisza <gti...@wikimedia.org> wrote: >> >> On Wed, Sep 2, 2015 at 6:19 AM, Oliver Keyes <oke...@wikimedia.org> wrote: >> >>> For what it's worth, the line " For one thing, they can turn out >>> negative, in which case we will have been spared a philosophical >>> debate about openness." comes off as very snarky and also entirely the >>> wrong approach. >> >> >> Debates about the Wikimedia ethos tend to be highly subjective and thus >> costly both in terms of time and emotional resources. Measuring whether >> banners work is fairly simple and objective. It makes sense to perform the >> cheapest prerequisite checks first, to minimize total cost. > > Part of the cost of business in being transparent and actually _having_ an ethos is that these conversations need to be had, regardless of their cost. > > And I seriously doubt that there's any benefit to these banner ads at all. Converting a small number of people from using the web version to an app version is meaningless when operating at this scale. We're actually probably _reducing_ the number of readers overall because many will simply say "screw this if you're serving me interstitials". > Agree that that's a downside that needs to be considered, for any banner actually (be it an invitation to install an app, to donate, or to participate in a photo contest). On the other hand, we may very well also be losing many readers by inactivity here, because they would prefer to read Wikipedia in an app and are not aware of ours. See e.g. the recently posted results from the strategy consultation <https://blog.wikimedia.org/2015/08/27/strategy-potential-mobile-multimedia-translation/> : *"Mobile-related comments reveal an opportunity to improve our existing mobile offerings for both editors and readers and raise awareness about our native apps. Participants (mostly anonymous users) urged us to 'make an app,' when one is already available for iOS and Android devices."* (there's more detail in this slide <https://commons.wikimedia.org/w/index.php?title=File:2015_Strategy_Consultation_Report.pdf=44> ) BTW, since we are talking about the impact on Finnish Wikipedia users, the link to the community notification there: https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(uutiset)#Running_banner_to_promote_Wikipedia_app_downloads It doesn't show any discussion so far; has there been feedback from Finnish readers in other venues? -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to serve up subtitles
That has been discussed since 2012 at https://phabricator.wikimedia.org/T44790 Use language code subpages for subtitles to allow Translate extension usage. Enabling translation of subtitles via the Translate extension would be a huge boon. On Tue, Aug 18, 2015 at 2:18 AM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: Well we already have a namespace of course, and indeed I was already considering converting that to a ContentModel. The only thing that is somewhat problematic here is the multiple languages problem. Currently each language get it's own page and title. Do we switch the model to host all subtitles in the same 'page' ? That will require a lot of UI and flags etc. Current system: https://commons.wikimedia.org/wiki/File:Folgers.ogv https://commons.wikimedia.org/wiki/TimedText:Folgers.ogv https://commons.wikimedia.org/wiki/TimedText:Folgers.ogv.en.srt https://commons.wikimedia.org/wiki/TimedText:Folgers.ogv.de.srt DJ On Tue, Aug 18, 2015 at 9:04 AM, Ori Livneh o...@wikimedia.org wrote: On Mon, Aug 17, 2015 at 5:56 AM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: As part of Brion's and mine struggle for better A/V support on Wikipedia, I have concluded that our current support for subtitles is rather... improvised. Currently all our SRT files are referenced from HTML using action=raw. But then not actually used from action=raw, but instead served up as semi html using api.php. Which is ridiculous... If we want to move to more HTML5 compliancy, we also will want to switch from the SRT format to the VTT format. Ideally, I want to host multiple subtitle formats, and dynamically serve/convert them as either SRT or VTT. These can be directly referenced from a track element so that we are fully compatible. The question is now, how to best do this. The endpoint needs to be dynamic, cacheable, allow multiple content types etc. Ideas suggested have been: * Api.php * Restbase * New endpoint * ResourceLoader modules I'm listing the current problems, future requirements and discussing several ideas at: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/TimedTextRework?veaction=edit If you have any ideas or remarks, please contribute them ! I propose adding an additional associated namespace (like Talk:), except for subtitles. The namespace will be associated with File pages which represent videos, and it will be coupled to a ContentHandler class representing subtitle content. The ContentHandler class will be a natural place for validation logic and the specification of an alternate editing interface suitable for editing subtitles. ___ 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 -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tools for dealing with citations of withdrawn academic journal articles
Related discussion from 2012:
https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Medicine/Archive_26#Creating_a_bot_to_search_Wikipedia_for_retracted_papers
(afaics it resulted in the creation of the {{retracted}} template, but
no bot)
The Community Tech team has its own mailing list now btw
(https://groups.google.com/a/wikimedia.org/forum/#!forum/community-tech
).
On Tue, Aug 18, 2015 at 2:42 AM, Pine W wiki.p...@gmail.com wrote:
Is there any easy way to find all of citations of specified academic
articles on Wikipedias in all languages, and the text that is supported by
those references, so that the citations of questionable articles can be
removed and the article texts can be quickly reviewed for possible changes
or removal?
See
https://www.washingtonpost.com/news/morning-mix/wp/2015/08/18/outbreak-of-fake-peer-reviews-widens-as-major-publisher-retracts-64-scientific-papers/?tid=hp_mm
If we don't have easy ways to deal with this (and I believe that we don't),
I'd like to suggest that the Community Tech team work on tools to help when
these situations happen.
Thanks,
Pine
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tools for dealing with citations of withdrawn academic journal articles
On Tue, Aug 18, 2015 at 3:59 PM, Luis Villa lvi...@wikimedia.org wrote: On Tue, Aug 18, 2015 at 2:06 PM, Pine W wiki.p...@gmail.com wrote: Researching the possibility of migrating all mailing lists to a newer system sounds like a good project for Community Tech I've been pushing to keep the team focused on things that can show a direct impact on contribution/editing; this kind of sysadmin work really isn't that?[1] May be a worthwhile clarification to add to https://www.mediawiki.org/wiki/Community_Tech_team#Scope though. Luis [1] Though I do think that we should think about at least upgrading mailman, and potentially switching to Google Groups or (perhaps for some lists) to discourse.net. https://phabricator.wikimedia.org/T52864 is the task for the Mailman upgrade btw (Upgrading to Version 3 will come, but it won't be soon and very very likely won't be this year). -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Foundation quarterly reviews for April-June 2015
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: Community Engagement, Advancement (Fundraising and Fundraising Tech): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/CE_and_Advancement,_July_2015 Discovery (formerly Search Discovery): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Discovery,_July_2015 Reading (formerly mobile web and apps): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Reading,_July_2015 Editing (comprising the Collaboration/Flow, Language Engineering, Multimedia, Parsing, and VisualEditor teams): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing,_July_2015 Infrastructure (comprising the Analytics, Release Engineering, Services, TechOps, Labs, Performance, Research Data, Design Research, and Security teams): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Infrastructure,_July_2015 Legal, Finance Administration, Human Resources, Communications and Team Practices: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Legal,_HR,_Finance,_Communications,_TPG,_July_2015 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Foundation quarterly reviews
And here are the minutes and slides from the remaining two quarterly review meetings from this round: Legal, Finance, Talent Culture (HR), Communications: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Legal,_Finance,_HR,_Communications,_April_2015 Analytics, User Experience, Team Practices, Product Management https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Analytics,_UX,_Team_Practices_and_Product_Management,_April_2015 Much of the content of the slides will also (in somewhat more polished form) feature in the WMF quarterly report, which is planned to be published by May 15. On Tue, Apr 21, 2015 at 9:53 PM, Tilman Bayer tba...@wikimedia.org wrote: 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/Quarterly_reviews/Community_Engagement_and_Advancement/April_2015 Mobile Web, Mobile Apps, Wikipedia Zero: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Mobile_and_Wikipedia_Zero,_April_2015 Parsoid, Services, MediaWiki Core, Tech Ops, Release Engineering, Multimedia, Labs, Engineering Community: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Parsoid,_Services,_MW_Core,_Ops,_RelEng,_MM,_Labs_and_ECT,_April_2015 Editing (covering VisualEditor), Collaboration (covering Flow), Language Engineering: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing,_Collaboration_and_Language_Engineering,_April_2015 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 e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hi Risker, the researchers' conclusion in their own words (see section 4.1, Indentation Reliability) is: *Incorrect indentation (i.e., indentation that implies a reply-to relation with the wrong post) is quite common in longer discussions in the EWDC [the English Wikipedia Discussion Corpus].* Responding below to your concerns about their methodology, taking the opportunity to clear up some statistical misconceptions, which might be valuable for other contexts too. On Friday, March 20, 2015, Risker risker...@gmail.com wrote: On 20 March 2015 at 06:13, Tilman Bayer tba...@wikimedia.org wrote: On Friday, March 20, 2015, Tilman Bayer tba...@wikimedia.org javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org'); wrote: Just to throw this in here as one data point: 39% of talk page threads contain wrong indentations https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations PS: The result from that paper was actually even worse than that (somewhat sloppy) headline suggests: the researchers found that 29 of 74 total turns, or 39%±14pp of an average thread, had indentation that misidentified the turn to which they were a reply. I'm not sure you really read the underlying study, Tilman; the sample size is so absurdly small that there is no way it is statistically signifant. (550 discussions on 83 article talk pages, in case anyone was wondering; No, the sample size was actually stated right in the sentence I quoted above: 74 total turns (talk page comments responding to another one), together with a ±14pp confidence interval. And what exactly did you mean here by statistically significant? The term doesn't make mathematical sense when applied to such a measured percentage in isolation, i.e. without a hypothesis or comparison value. Rather, one can talk about confidence intervals - a smaller confidence interval means the estimate is likely to be more precise. The 550 discussions you quoted refer to a different sample within the same corpus. the equivalent of about 10 minutes' worth of discussions on enwiki, except that they are looking at talk pages that may have conversations dating back 10+ years.) This 10 minutes/10 years comparison and the absurdly small/no way rhetoric sound a lot like a common statistical fallacy, namely erroneously assuming that it is size of the sample as a fraction of the population that matters http://www.amstat.org/publications/jse/v12n2/smith.html (Unless the sample encompasses a substantial portion of the population, the standard error of an estimator depends on the size of the sample, but not the size of the population. This is a crucial statistical insight that students find very counterintuitive). Granted, if one draws a sample of 74 turns from all turns on all talk pages made in Wikipedia's history, then it's plausible that that overall population numbers hundreds of millions. But at such a large population size (or small sample/population ratio) it is is the absolute size of the sample that matters for the size of the confidence interval - not how large the sample is compared to the population. There may be accessible explanations elsewhere that include more of the math behind it, but perhaps this Khan Academy video https://www.youtube.com/watch?v=1JT9oODsClE helps, which walks one through a calculation showing how measuring a percentage of 38% in a sample of just 150 US households (out of 100+million) already allows one to reject the null hypothesis that the real percentage among the entire population of all households is less than 30%. It calls 150 a large sample in terms of the approximation regime used there - which I'm sure you must find extremely shocking as you earlier called a sample of 550 absurdly small. For a more thorough derivation, these online lectures http://www.stat.berkeley.edu/~stark/SticiGui/Text/confidenceIntervals.htm are quite useful (see e.g. the Conservative confidence intervals for percentages section. The finite population correction https://en.wikipedia.org/wiki/Finite_population_correction term there is close to 1 for small sample/population ratios and so the resulting formula for the confidence interval does no longer depend on N, the population size). Sure, in the present case the absolute size of the sample (74) wasn't very big either, and there are other things to consider such as the selection method (e.g. they actually selected from whole threads longer than 10 turns each only, so that's what the percentage relates to). But the authors did their due diligence and indicated the limitations resulting from the sample size by including that ±14% confidence interval. Yes, that's quite broad and for more precise estimations of the real overall percentage of wrong indentations (39% or 32% or 48%?...) one would need a larger sample. But it already makes it highly unlikely that this real percentage is only 1% or 2%, say. Hence I
[Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Friday, March 20, 2015, Tilman Bayer tba...@wikimedia.org javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org'); wrote: Just to throw this in here as one data point: 39% of talk page threads contain wrong indentations https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations PS: The result from that paper was actually even worse than that (somewhat sloppy) headline suggests: the researchers found that 29 of 74 total turns, or 39%±14pp of an average thread, had indentation that misidentified the turn to which they were a reply. -- Sent from Gmail Mobile ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 10:28 AM, Ryan Lane rlan...@gmail.com wrote: On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote: The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. From what I remember officewiki is pretty unused by most of the staff, so I'd doubt you'd get much usable feedback there. Actually, https://office.wikimedia.org/w/index.php?title=Special:RecentChangeslimit=250 currently goes back about 90 hours (i.e. more than 60 edits/day), with more than 30 different users active in that time. And like Jon, I'm surprised to hear about stories where staff are reverting to emails. Admittedly, WMF employees do indeed sometimes discuss topics per email instead exclusively using wiki talk pages, but in my recollection this happened even before the existence of Flow. And after all, this very thread is happening on Wikitech-l instead of mediawiki.org ;) As someone who's used mediawiki for 10+ years I can say that *anything* is better than wikitext for discussion. I have a certain bias towards LQT and such, but that's because I actually want to use discussion pages for discussion and wikitext is basically the worst user experience in the world in this regard. Just to throw this in here as one data point: 39% of talk page threads contain wrong indentations https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Quarterly review minutes and/or slides of the following teams have been posted in recent days: Multimedia: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Multimedia/January_2015 Legal Community Advocacy: https://commons.wikimedia.org/wiki/File:LCA_Q2_Slides.pdf (abridged slides only) Fundraising and Fundraising Tech: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Fundraising/January_2015 Communications: https://commons.wikimedia.org/wiki/File:Communications_WMF_Quarterly_Review,_Q2_2014-15.pdf (slides only, as a report - no actual meeting took place) With this, documentation from all 20 quarterly review meetings that took place about Q2 (October-December 2014) has been published. On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from four recent meetings have appeared under the following URLs: Analytics team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Analytics/January_2015 Parsoid and Services teams: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Services/January_2015 Mobile Web and Apps teams: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Mobile/January_2015 Product Process Improvements (update meeting): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Product/January_2015 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review of the Foundation's Editing (formerly VisualEditor) team await perusal at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing/January_2015 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video Uploads to Commons
On Tue, Feb 3, 2015 at 5:19 PM, Brian Wolff bawo...@gmail.com wrote: On Feb 3, 2015 8:43 PM, Nkansah Rexford seanmav...@gmail.com wrote: I couldn't find a tool to convert my videos from whatever format into .ogv outside my PC box before pushing to Commons. I guess there might exist something like that, but perhaps I can't find it. But I made one for myself. Maybe it might be useful to others too. I call it CommonsConvert. Upload any video format, enter username and password, and get the video converted into .ogv format plus pushed to Commons all in one shot. You upload the original video in whatever format, and get it on Commons in .ogv Some rough edges currently, such as can't/don't know/no available means to append license to uploaded video among other issues. Working on the ones I can asap. It uses mwclient module via Django based on Python. Django gives user info to Python, Python calls avconv in a subprocess, and the converted file is relayed to Commons via mwclient module via Media Wiki API. I think not everyone has means/technical know how/interest/time converting videos taken on their PC to an Ogg-Vorbis-whatever format before uploading to Commons. Doing the conversion on a server leaves room for user to focus on getting videos than processing them. I don't know if this is or will be of any interest that someone might wanna use, but I personally would enjoy having a server sitting somewhere convert my videos I want to save onto Commons, than using my local computer doing that boring task. In an email to this list a week or so ago, I 'ranted' about why commons wants a specific format (which if not for commons, I never come across that format anywhere), but has no provision for converting any videos thrown at it into that format of its choice. Well Tool can be found here: khophi.co http://khophi.co/commonsconvert/ http://khophi.co/commonsconvertcommonsconvert http://khophi.co/commonsconvert And this is sample video uploaded using the tool. https://commons.m.wikimedia.org/wiki/File:Testing_file_for_upload_last.ogv (will be deleted soon, likely) What I do not know or have not experimented yet is whether uploading using the api also has the 100mb upload restriction. Will appreciate feedback. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Cool. Thanks for working on this sort of thing. The uploading videos process certainly benefit from some love. May i suggest using webm (of the vorbis/vp8 variety) as the output format? Webm will give higher quality videos at lower file size, so is probably a better choice if converting from another format. For the 100mb thing - there are multiple ways to upload things with the api. The chunked method has a file size limit of 1gb. All the other methods have the 100mb limit. See https://commons.wikimedia.org/wiki/Commons:Chunked_uploads for more information. If you havent already, id encourage mentioning this on [[Commons:VP]]. Real users would probably be able to give much more specific feedback. Cheers, Bawolff P.s. im not sure, but i think user:Prolineserver might have been working on something similar, in case you are looking for collaborators. That's https://tools.wmflabs.org/videoconvert/ - seems to be down right now, but usually it works very well for converting to WebM, and can also upload the result directly to Commons using OAuth. It's just not very fast (can take several hours to generate a 200MB WebM). Results: https://commons.wikimedia.org/wiki/Category:Uploaded_with_videoconvert -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review meeting of the Foundation's Collaboration team (which was formerly called the Core features team and is working on the Flow project) have appeared here: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Collaboration/January_2015 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from three recent quarterly review meetings held last week are now available: Language Engineering team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Language_Engineering/January_2015 MediaWiki Core team https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/MediaWiki_Core/January_2015 Talent Culture team (slides only:) https://commons.wikimedia.org/wiki/File:WMF_Quarterly_Review-_2014-15_Q2_-_Talent_%26_Culture,_Redacted.pdf On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from four recent quarterly reviews are now available: Team Practices Group: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Team_Practices/January_2015 Engineering Commmunity Team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Engineering_Community/January_2015 Release Engineering and QA (Quality Assurance) team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Release_Engineering/January_2015 Mobile Partnerships (Wikipedia Zero) team: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Wikipedia_Zero/January_2015 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Digital currencies and donations for contributions
I'm not convinced of several of the assumptions here (e.g., that the ability to break a donation down into very small percentages has been a major blocker for such efforts, i.e. that Bitcoin would be a game-changer). But it's an interesting topic. In 2010 I wrote this summary of discussions on the German Wikipedia over two payment schemes (Flattr, a microdonation system and METIS, a disbursement system of collecting society VG Wort for authors of web pages) that have both been used for actual payments to Wikimedia contributors, albeit on a small scale: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2010-08-23/News_and_notes#German_Wikipedia_debates_payment_schemes In the dewiki community discussions back then, a large majority rejected the systematic introduction of each system, citing some of the concerns you mentioned, as well as others. On Fri, Oct 31, 2014 at 2:16 AM, Gilles Dubuc gil...@wikimedia.org wrote: A random thought, maybe it's been discussed before here or on another ML, but I couldn't find that discussion. I've heard the argument that a lot of people who donate money to the WMF don't necessarily understand that contributors aren't paid to write the content on the site, etc. and might be donating with the impression that they're directly rewarding the people who put the content together. Because most readers don't know how wiki projects function. Which is a reason why the proponents of sponsored/paid editing view this as a diversion of donations that should go to the contributors and so on. I don't have a particularly strong opinion on this, but it's something I hear on a regular basis from community members. I think there is a technological opportunity that changes the game regarding this question, though, which is digital currencies. Bitcoin, or whatever better shinier thing might take over its leadership position in that domain, open opportunities with micropayments that were not possible before. It's possible, right now, to build something that would allow a reader to donate an arbitrary amount of bitcoins for a specific article (that article or a portion of it helped me, here's some money for the people who wrote it), and the sum would be broken down into lots of smaller parts, given to all the contributors of this article. This ability to break things down into tiny fractions is something that isn't possible with regular money. I think this opens a lot of interesting questions: - How would the breakdown be calculated? Moving content around, adding citations, writing original content, etc. are tasks of very varied effort. I imagine the community would probably have to define the compensation rules here. - What would the effects be on the community? This opens the hornet's nest of mixing compensation and free knowledge. But in a way, the WMF is mixing those already. - Would it increase imbalance in article activity? It's easy to imagine that people would flock to highly popular articles trying to update them doing disguised null-edits just for the sake of joining the contributor pool for future readers donating to that article. A community-driven solution might be to decide that popular articles don't need this compensation system and are blacklisted. This is after all most useful for articles that require a lot of work with little reward. A whitelist approach of putting bounties on areas that need work might be more effective. In my opinion I think that as everything that has ever been built on this platform, it would be just a tool and the ways the community decides to use it might not be what we expect. It's a technical possibility that didn't exist before, though, so I think it needs to be studied, even if nothing ends up being done with it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Thursday's quarterly review meeting of the Foundation's Multimedia team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Multimedia/October_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from the recent quarterly review meeting of the Foundation's MediaWiki Core team can now be found at https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_October_2014/Notes . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from the recent quarterly review meeting of the Foundation's Parsoid, Services and OCG (Offline content generator) teams have appeared at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Parsoid/October_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review meeting of the MediaWiki Release Management team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/MediaWiki_Release/October_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review meeting of the Foundation's Core features (Flow) team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Core_features/October_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review meeting of the Foundation's Editing (formerly VisualEditor) team can now be found at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Editing/October_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review meeting of the Foundation's Analytics team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Analytics/September_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review meeting of the Foundation's Growth team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Growth/September_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from the recent quarterly review of the Foundation's Language Engineering team are available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Language_Engineering/September_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from the first ever quarterly review of the Foundation's Technical Operations team (held on August 28) are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/TechOps/August_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review of the Foundation's Release Engineering and QA team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Release_Engineering/September_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review of the Foundation's MediaWiki Core team are now available at https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_July_2014/Notes (agenda/overview page: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_July_2014 ) On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review of the Foundation's Core features team (focusing on the work on Flow) are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Core_features/July_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Monday's quarterly review of the Foundation's Analytics team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Analytics/June_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Meant to CC Wikitech-l too... -- Forwarded message -- From: Tilman Bayer tba...@wikimedia.org Date: Wed, Jun 25, 2014 at 8:37 AM Subject: Re: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org Minutes and slides from last Friday's quarterly review of the Foundation's Parsoid team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Parsoid/June_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last Thursday's quarterly review of the Foundation's Editing (formerly VisualEditor) team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Editing/June_2014 . (A separate but related quarterly review meeting of the Parsoid team took place on Friday, those minutes should be up tomorrow.) On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review meeting of the Foundation's Growth (formerly E3) team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Growth/June_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from last week's quarterly review of the Foundation's Mobile Contributions team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Mobile_contributions/May_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Minutes and slides from the Release Engineering and QA quarterly review
Minutes and slides from the quarterly review meeting with the Wikimedia Foundation's Release Engineering and QA team on April 30 have been posted here: https://www.mediawiki.org/wiki/Wikimedia_Release_and_QA_Team/Quarterly_review,_April_2014/Notes -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SSL Cert Change?
On Thu, Apr 10, 2014 at 12:48 PM, Derric Atzrott datzr...@alizeepathology.com wrote: I just had Certificate Patrol in Firefox let me know that the SSL cert for Wikimedia.org was changed? Does anyone know anything about that? Are multiple certificates in use? FYI, this has been widely covered in a lot of mainstream press. (but not necessarily well. Some call OpenSSL a protocol) http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075801.html https://xkcd.com/1353/ Ah. I'm still reading emails from Monday on the list. So I must have just missed out on the SSL cert change. I did hear about the Heartbleed issue (actually had a few users here at the office come to me very concerned about what they heard on the news). Glad to hear that the certs were reissued to take care of that. There is now a blog post with a timeline overview of the actions taken: https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/ -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Monday's quarterly review meeting of the Foundation's Analytics team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Analytics/March_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
The minutes and slides from Friday's quarterly review meeting of the Parsoid team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Parsoid/March_2014 . On Fri, Mar 28, 2014 at 9:09 PM, Tilman Bayer tba...@wikimedia.org wrote: Minutes and slides from Wednesday's quarterly review of the Foundation's VisualEditor team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/VisualEditor/March_2014 (A separate but related quarterly review meeting of the Parsoid team took place today, those minutes should be up on Monday.) On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review of the Foundation's VisualEditor team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/VisualEditor/March_2014 (A separate but related quarterly review meeting of the Parsoid team took place today, those minutes should be up on Monday.) On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC project: calculating the quality of editors and content (was Guidance for the Project Idea for GSOC 2014)
See also https://meta.wikimedia.org/wiki/Research:Content_persistence On Thu, Mar 6, 2014 at 7:32 PM, Benjamin Lees emufarm...@gmail.com wrote: Hi, Devander. Have you looked at WikiTrust[0]? It does roughly what you describe (though I don't think the live demo works anymore). [0] https://en.wikipedia.org/wiki/Wikipedia:WikiTrust ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Wednesday's quarterly review of the Foundation's Wikipedia Zero team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Wikipedia_Zero/March_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from Friday's quarterly review of the Foundation's Growth team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Growth/February_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from this week's quarterly review of the Foundation's Core features team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Core_features/February_2014 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@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_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jake requests enabling access and edit access to Wikipedia via TOR
On Mon, Dec 30, 2013 at 2:03 PM, Thomas Gries m...@tgries.de wrote: Am 30.12.2013 23:01, schrieb John: Editing via tor is possible on WMF wikis if the account / user is trusted Can you explain this briefly, or send me a pointer ? This single info can be a help for him and others. (Honestly, I do not know, what a trusted account/user is.) It seems he already knows that - he mentioned it in the 30C3 talk: https://www.youtube.com/watch?v=SscFfzD_his#t=36m55s (see also Roger Dingledine earlier in the same talk: https://www.youtube.com/watch?v=SscFfzD_his#t=34m18s ) This problem has been discussed many times before, also on this list: http://www.gossamer-threads.com/lists/wiki/wikitech/323006 There have been quite a few well-meaning but naive proposals to solve it; I understand Jacob's remarks as a welcome call to the TOR community to work more intensively with Wikipedians to understand the actual issues that motivated Wikipedia's TOR block. I am on #mediawiki now On Monday, December 30, 2013, Thomas Gries wrote: Hi, during the 30C3 Congress [1] in Hamburg - where neither Wikipedia Foundation nor MediaWiki were formally present this year (but should be next year)- Jacob Appelbaum [2] - core member of the TOR project - complained in one of his numerous talks that the (edit) access to Wikipedia via TOR is not possible. He requested that a way should be found to enable the TOR access including edit access to Wikipedia. I am just the messenger of this message. Regards, Tom [1] https://events.ccc.de/congress/2013/wiki/ [2] https://en.wikipedia.org/wiki/Jacob_Appelbaum ___ 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 https://lists.wikimedia.org/mailman/listinfo/wikitech-l --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Algorithm for assessing quality of articles
That's probably more a topic for Wiki-research-l than for Wikitech-l (in particular since they seem to have published formulas rather than code). BTW, we briefly reviewed this preprint in the Wikimedia Research Newsletter back when the first version came out: https://meta.wikimedia.org/wiki/Research:Newsletter/2012/June#Central_users_produce_higher_quality Also, there is quite a few other research out there about automatically assessing article quality - last year, there was even a small competition for such algorithms: http://www.webis.de/research/events/pan-12 On Thu, Oct 31, 2013 at 10:10 PM, Juliusz Gonera jgon...@wikimedia.org wrote: I haven't read the paper itself, but just in case someone has a moment and is interested: http://www.technologyreview.com/view/520946/can-automated-editorial-tools-help-wikipedias-declining-volunteer-workforce/ -- Juliusz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Engineering Community Team office hour, in one hour
FWIW, there is always the bot log of #wikimedia-office, in this case at http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20131015.txt On Tue, Oct 15, 2013 at 10:48 AM, Dan Garry dga...@wikimedia.org wrote: Seconding the request for log. Dan On 15 October 2013 18:44, Bartosz Dziewoński matma@gmail.com wrote: Can somebody provide a summary or a log? I was unable to attend, but I'm very interested in what was discussed :) -- Matma Rex __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Associate Product Manager for Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki's Login Security
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvib...@wikimedia.org wrote: On Fri, Aug 23, 2013 at 3:47 PM, Risker risker...@gmail.com wrote: Just for the record, anyone at administrator level or higher has IPBE built into their tools (I believe on all projects), so they can edit/administer/checkuser/etc using Tor. But given that over 95% of anything that comes through an unblocked Tor node onto English Wikipedia is either spam or vandalism, I can't support allowing unbridled Tor editing on at least that project. Well, we don't allow unbridled anything; our administrators litter the IP address universe and logged-in users alike with blocks constantly. :) I would strongly recommend a saner signup/account moderation system for less trusted network origins such as Tor nodes, though. The key is that you have to actually allow creating an account from a Tor node in the first place, or you're limited to people who live in free internet countries or have the money or clout to go abroad to create their accounts... -- brion Well yes, such a system would be nice to have, but as discussed previously on this list, it's a hard problem to solve (Can we help Tor users make legitimate edits?, http://www.gossamer-threads.com/lists/wiki/wikitech/323006 ). Basically, the problem is that all the existing proposals would at best provide a substitute for autoblocks, but not for Checkuser. Also, there is already https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_account_.26_Tor_won.27t_let_you_create_one.3F (although I don't know how frequently/successfully it's being used currently) -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You know, we really should shift to Windows
https://twitter.com/hassankhosseini/status/370212655996235776 - he says that this was produced in collaboration with Wikimedian John Vandenberg (CC'ed), who might be able to provide more information on how the numbers were generated. On Wed, Aug 21, 2013 at 9:02 AM, Randall Farmer rand...@wawd.com wrote: Sadly they're moderating comments. I tweeted at the author, with links to WMF Ganglia as backup, and he definitely doesn't believe me; maybe something from a WMFer would help, if anyone thinks it's worth correcting: https://twitter.com/hassankhosseini/status/370090365354655744 Going by the Ganglia pages, actual Wikipedia has at lesat 2x the *RAM* that their scenario has *disk*. Pretty fun. (If you're curious, Ganglia's front page says it's tracking 14,744 cores on 988 hosts and 40T of RAM. Their scenario has 20T disk. There may be additional capacity not in that Ganglia setup, though it seemed to cover the obvious stuff.) On Wed, Aug 21, 2013 at 8:23 AM, David Gerard dger...@gmail.com wrote: On 21 August 2013 16:12, hoo h...@online.de wrote: Am I wrong or did they actually calculate that for labs only (which would be rather funny)? At least they link to https://wikitech.wikimedia.org/wiki/Special:Ask/-5B-5BResource-20Type::instance-5D-5D/-3FInstance-20Name/-3FInstance-20Type/-3FProject/-3FImage-20Id/-3FFQDN/-3FLaunch-20Time/-3FPuppet-20Class/-3FModification-20date/-3FInstance-20Host/-3FNumber-20of-20CPUs/-3FRAM-20Size/-3FAmount-20of-20Storage/searchlabel%3Dinstances/offset%3D0([...] that run on up to 385 instances [...]) which AFAIK doesn't have any production servers. Heh. Please do post a comment of correction and post it here too, so it doesn't just vanish ;-) - d. ___ 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 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You know, we really should shift to Windows
Annother recent publication that similarly used Wikipedia as an example to simulate the alleged benefits of a different hosting model: http://www.researchgate.net/publication/236942031_Symbiotic_Coupling_of_P2P_and_Cloud_Systems_The_Wikipedia_Case/file/5046351d1d1c3f051c.pdf (covered in the July Wikimedia Research Newsletter) It's by two German computer scientists who conclude that the Wikimedia Foundation can reduce the traffic needed for article lookups in case of Wikipedia up to 72% by having participants in a P2P network storing and serving some articles from their machines, while still also serving them from a central installation (cloud). I seem to recall that this kind of proposal for Wikipedia was quite popular in like the mid 2000s (when P2P was more in fashion and WMF had less money), to the point that Brion or Tim or someone else involved with the actual hosting wrote a rebuttal, which I can't find any more. On Wed, Aug 21, 2013 at 7:44 AM, David Gerard dger...@gmail.com wrote: Analysts agree! http://www.rightscale.com/blog/cloud-cost-analysis/cloud-cost-analysis-how-much-could-wikipedia-save-cloud _ - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You know, we really should shift to Windows
On Wed, Aug 21, 2013 at 9:16 AM, Tilman Bayer tba...@wikimedia.org wrote: https://twitter.com/hassankhosseini/status/370212655996235776 - he says that this was produced in collaboration with Wikimedian John Vandenberg (CC'ed), who might be able to provide more information on how the numbers were generated. For some reason, that tweet seems to have been deleted within the last hour, but there is some earlier discussion from that collaboration at https://twitter.com/hassankhosseini/status/283944238473936897 , with other interesting comments (Running 450 servers for Wikipedia, 150 staff. On AWS you could run that with 2-4 sysadmins) -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS for logged in users on Wednesday August 21st
On Tue, Aug 20, 2013 at 3:57 PM, Tyler Romeo tylerro...@gmail.com wrote: The lack of secure login on WMF wikis is a *major security issue*, and AFAIK is the biggest publicly known security issue in the site. Indeed. For a Signpost article three years ago, I asked a security researcher (who had co-authored a comparative study of user password handling on 150 websites) about his recommendations for Wikipedia. Making encrypted transmission of the password the default was his foremost advice: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2010-08-02/Technology_report#Study_of_web_passwords_includes_Wikipedia It's excellent news that this issue is finally being resolved, even when there are exceptions and corner cases that need to be addressed. All you need is some random checkuser to be using Wikipedia at a Starbucks, and all of a sudden the privacy policy of every single registered user is violated. There's big talk all around about evading the NSA and attempting to protect the privacy of our users, but it is literally impossible to protect users' privacy if we can't even protect their security in the first place. To re-iterate, privacy depends on security, and right now we have neither of them. Furthermore, secure login is not a new idea. I've been fighting to get this feature enabled since October 2012 when the secure login functionality in MW core was finally fixed. Since then, HTTPS login has been deployed *twice*, but reverted once due to a bug with CentralAuth and once due the design team concerned about the login form. This will be the third attempt at deploying this in the past six months, so I don't know why this discussion had to start right now. -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Updates on VE data analysis
On Fri, Jul 26, 2013 at 5:52 PM, James Salsman jsals...@gmail.com wrote: For example, why are you not providing a daily version of the hourly graph at http://ee-dashboard.wmflabs.org/graphs/enwiki_ve_hourly_by_ui ? Note that if you are interested in VE edits per user type instead, http://ee-dashboard.wmflabs.org/graphs/enwiki_ve_hourly_perc_by_user_type already offers a smoothing option (click the spanner icon on the top left), which can be set to 24 hours or more. Everyone who previously cited (or relied on) information from draft versions of the analysis on Meta should read the updates that Dario has linked, because that information may have become obsolete. -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bot upload of files over 100MB
With the https://commons.wikimedia.org/wiki/Commons:Chunked_uploads enabled, users can currently upload files up to 500MB, when using a supported browser (e.g. a current Firefox or Chrome). I think Daniel's question was about how to make this method work for a bot too, i.e. via the API rather than in a browser. On Tue, Jun 25, 2013 at 2:52 PM, OQ overlo...@gmail.com wrote: I would assume given the previous reply that regardless of upload method, chunked or otherwise, there is still the hard limit of how big the resultant file can be. On Tue, Jun 25, 2013 at 5:49 PM, Jeremy Baron jer...@tuxmachine.com wrote: On Jun 25, 2013 5:44 PM, Daniel Mietchen daniel.mietc...@googlemail.com wrote: my bot[1] occasionally stumbles upon files that are above 100MB and thus does not upload them[2]. What do I have to do to get it set up for handling these files too? this looks like the relevant section: https://www.mediawiki.org/wiki/API:Upload#Chunked_uploading I don't know the current settings; you might need to enable chunked uploads in the MediaWiki prefs for the user you're uploading as. -Jeremy ___ 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 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Initial stab at responsive images for high-density displays
BTW, it seems that a certain mobile phone manufacturer wasn't quite ready for this ;) http://tech2.in.com/news/smartphones/samsung-galaxy-s3-browser-bug-inflates-data-usage-loading-times/875182 According to the researchers, the problem is caused by the srcset HTML attribute, which indicates the size and resolution of images a browser should pick based on the device’s screen size and magnification needed. ... The Galaxy S3’s browser, however, has a bug that makes it download all the images specified in the srcset HTML attribute instead of the ones it needs, resulting in long load times and lots of data usage. For instance, the researchers loaded a Wikipedia page that was only 600 KB when browsed using Internet Explorer, but the page’s size inflated to a whopping 2.1 MB on the Galaxy S3. “This bug significantly affects the Wikipedia performance on 3G were these massive number of requests for image downloads overwhelmed the network and ended up timing out rendering an incomplete page,” the research paper reads. On Thu, Sep 27, 2012 at 3:45 PM, Brion Vibber br...@pobox.com wrote: On Sun, Sep 23, 2012 at 7:59 PM, Brion Vibber br...@pobox.com wrote: I've updated the patch to use the 'srcset' attribute as defined in the current HTML 5 working group version, only using the density options and not the width/height options: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset Patch in gerrit: https://gerrit.wikimedia.org/r/#/c/24115/ (core) https://gerrit.wikimedia.org/r/#/c/24147/ (MobileFrontend) Patch has been updated to: * include QUnit tests for the srcset matching * match next-highest density if there's not an exact match available This latter fixes Opera Mobile on my Galaxy Nexus (where devicePixelRatio reports 2.25 rather than the expected 2) and BlackBerry 10 developer alpha device (where it reports slightly less than 2.25). Should help with some other funky configurations where a non-integral zoom is reported as well. Currently Firefox for Android doesn't report window.devicePixelRatio, I may add another special case, should be able to use media queries. Opera Mobile works, but Opera Mini does not -- at least because we don't serve it jQuery etc. :) You can see a live demo of this patch in action on these test articles: * http://leuksman.com/mw/index.php/San_Francisco * http://leuksman.com/mw/index.php/Lens_(optics) Mobile browsers won't automatically switch to mobile view on this wiki currently, so hit the 'mobile view' link manually to switch in. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Countdown to SSL for all sessions?
On Tue, Apr 30, 2013 at 12:59 PM, Matthew Walker mwal...@wikimedia.org wrote: We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia. Do we have numbers on what this did to the number of active editors during that time period? Esp. broken down on a per country basis? I think I want to agree with Petr -- we should not be forcing SSL always; we should be respecting what the user requested. In that way if it ever becomes enforced by a government that SSL is disallowed users may still contribute to the site. (Remember we block things like Tor so they can't even proxy around it.) I don't want to drag this thread into politics, but the comparison with blocking Tor is really not appropriate. Tor is blocked because it would disrupt the work of the editing community, not to satisfy the requirements of governments. And it would seem extremely weird to let the current policies of the Iranian regime alongside a past measure of the Belarusian one determine the default setup of Wikimedia sites. Perhaps we should just make it really obvious on the login page (e.g. big button to login via SSL, small button to not do so.) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Tue, Apr 30, 2013 at 12:21 PM, Chris Steipp cste...@wikimedia.orgwrote: On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis fai...@wikimedia.org wrote: That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current usage, but I don't have any numbers to back this up right now. Maybe Ryan has them. We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia. ___ 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 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Pushing Technical changes to Wikimedia projects
Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ 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 https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global user CSS and JS
On Mon, Mar 4, 2013 at 2:59 PM, Brian Wolff bawo...@gmail.com wrote: Somebody (pathoschild maybe) used to have a bot that copied over css files from meta. (Why people didnt just dynamically load things I don't know) https://meta.wikimedia.org/wiki/User:Pathoschild/Scripts/Synchbot On 2013-03-04 6:57 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: Has anyone looked at allowing a user to have global CSS and JS across all WMF wikis? I know you can hack it with a mw.loader.load on all the wikis you use, but it would be useful if CentralAuth had it built in. Is there a bug for this? Matt Flaschen ___ 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 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bringing OpenID as a provider to Wikimedia projects
On Fri, Feb 22, 2013 at 12:43 PM, Marc A. Pelletier m...@uberbox.org wrote: On 02/22/2013 03:17 PM, maiki wrote: Is this up for discussion, or are we at the point of planning deployment? The latter. I can elucidate a number of scenarios where that is beneficial, but the primary one from my perspective is that of authenticating for external tools (like bots and webservices) written by community developers. Each of them currently need their own mechanism, have to implement baroque processes to associate a Wiki[mp]edia account, and increase exposure of credentials for the users. OpenID neatly fixes all that in one, simple to implement, open and well known manner. -- Marc To add another possible use case: We recently ran a small survey for readers of blog.wikimedia.org. In one question, we asked the editors among them Would you be interested in being able to log into the blog with your Wikimedia account?, and 73% (of 137 respondents) said yes. -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update on Ashburn data center switchover / migration – target date is week of 1/22/13
Expect some public attention for this - already there is http://www.datacenterknowledge.com/archives/2013/01/14/its-official-equinix-ashburn-is-wikimedias-home/ On Fri, Jan 11, 2013 at 12:07 PM, Ct Woo ct...@wikimedia.org wrote: All, The Migration team is in the last lap on completing the remaining tasks to ready our software stack and Ashburn infrastructure for the big switchover day. Per my last update,http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063668.html with the Fundraising activity behind us now, the team has scheduled the *week of 22nd January*, 2013 to perform the switchover. We are going to block a 8-hour migration window on the *22nd, 23rd and 24**th*. During those periods, *17:00 UTC to 01:00 UTC hours (9am to 5pm PST*), there will be intermittent blackouts and they will be treated as 'planned' outages. You can follow the migration on irc.freenode.org in the #wikimedia-operations channel. The team is putting the finishing touches to the last few tasks and we will make the final Go/No decision on 18th Jan, 2013. An update will send out then. For those interested in tracking the progress, the meeting notes are captured on this wikitech pagehttp://wikitech.wikimedia.org/view/Eqiad_Migration_Planning#Improving_Switchover . *Please note that we will be restricting code deployment during that week, allowing only emergency and critical ones only.* Thanks. CT Woo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we help Tor users make legitimate edits?
that token to bypass the Tor blocks. (Tyler mentioned he saw this somewhere in a Bugzilla suggestion; I haven't found it.) 4) Allow more users the IP block exemption, possibly even automatically after a certain number of unreverted edits, but with some kind of FlaggedRevs integration; Tor users can edit but their changes have to be reviewed before going live. We could combine this with (3); Nymble administrators or token-issuers could pledge to review edits coming from Tor. But that latter idea sounds like a lot of social infrastructure to set up and maintain. Thoughts? Are any of you interested in working on this problem? #tor on the OFTC IRC server is full of people who'd be interested in talking about this. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Fwd: [Tech/Product] Engineering/Product org structure
On Wed, Nov 7, 2012 at 2:16 PM, Platonides platoni...@gmail.com wrote: On 07/11/12 22:21, Federico Leva (Nemo) wrote: Terry Chay, 07/11/2012 21:04: You aren't the only one. It turns out we use a lot of industry terminology, without realizing that we are poorly communicating what that means to most people. [...] First of all, this will help greatly to the others (you already read it): http://wikimediafoundation.org/wiki/Staff_and_contractors. Thanks for your explanation but personally I'm more confused than before about the difference between Engineering and Product, also because the terminology didn't appear internally consistent. :-) I feel like you, Nemo. I am glad by Terry explanation, but as I went on reading it, the less I felt I understood it. It would benefit from a more layman explanation. Maybe it's just complex to everybody. So, to keep it simple, that page has: 2 Engineering and Product Development 2.1 Platform 2.2 Features 2.3 Technical Operations 2.4 Mobile and Special Projects 2.5 Language 2.6 Product and as first approximation Product would be something like 2.2+2.6 and Engineering something like 2.1+2.3, with 2.4 and 2.5 aside? I thought that 2.4 (Mobile) would also be Product. [...] On the Engineering side, there exists an amalgam of specific focused groups with their own directors. The focused groups are: Language (formerly i18n and Experimentation, internationalization/localization/globalization is a cross-cutting concern), and Mobile (formerly, Mobile and Special Projects: the mobile web, the mobile app, also including Wikipedia Zero). The area focused ones are: Operations (keeping the lights on), Platform (keeping the code working) and Features (ostensibly new features). [...] What you call the Engineering side here, at a first glance, could seem product development, and in fact those two focused groups currently have some members which are under 2.6 (Product). Surely the same happens for the other areas you mentioned. You can see several teams in that page, with members from multiple sections. Which leads to the (naive?) question on what's the purpose of being splitted in those sections if then the work is done in teams with a completely different organization. After staring for a while to [[Staff and contractors]] and trying to match people with its work, my only conclusion is that I don't know what most employees do. It often (not always) helps to click through to the employee's user page and read the My work section there. Earlier this year, Gayle harassed us all a lot to put something informative there ;) -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedians are rightfully wary
On Thu, Aug 23, 2012 at 7:02 AM, Strainu strain...@gmail.com wrote: 2012/8/23 Tilman Bayer tba...@wikimedia.org: On Thu, Aug 23, 2012 at 4:27 AM, Strainu strain...@gmail.com wrote: ... You guys (and by that I mean anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being they're hundreds of them. ... It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2]. Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so. Can you please point me to the location of the slides (if available)? They're linked from the abstract: https://wikimania2012.wikimedia.org/wiki/Submissions/Movement_Broadcasting_-_%27Stop_Spamming%27_vs._%27Nobody_Told_Me%27 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedians are rightfully wary
On Thu, Aug 23, 2012 at 4:27 AM, Strainu strain...@gmail.com wrote: 2012/8/22 Sumana Harihareswara suma...@wikimedia.org: On 08/21/2012 06:29 PM, Ryan Lane wrote: When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people. We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner. Just a quick note that the wikitech-ambassadors list https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is helping with this, and is going to be helping more -- I'll wait for Guillaume to lead the conversation about this, hopefully in the next 2 weeks. You guys (and by that I mean anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being they're hundreds of them. Well, let me tell you in plain English with no regard to political correctness: your excuse sucks. It sucks mainly because automation was invented half a century ago - I've said this here before and I'm saying it again: it takes at the very most 2 days to write and test a script that can post a message to any number of pages. There could be thousands of projects, the effort from the poster would be the same. It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2]. Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so. Those who know and want to use those alternative methods are discouraged by the scarce organization of the information. Finally, it sucks because you basically expect people to look for your announcements and extract the information, when the whole idea of an announcement is to push the information from the originator to the receiver. Sumana, my understanding of the ambassador concept is someone that takes the information from you and puts it on their home wiki(s). That's great, except it's unlikely you will find users from all the 200+ languages and even if you do, people quit, go on vacations etc., leading to information loss. An automated English message on the pump, translated on the spot would be much better. Strainu https://meta.wikimedia.org/wiki/Global_message_delivery (a bot operated by MZMcBride) can do exactly that. It was used by the WMF engineering department to inform all of the projects about the IPv6 deployment in June (e.g. https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Juin_2012#Update_on_IPv6 ), and all non-Wikipedia projects about changes they needed to make to their main page in order for it being displayed properly on mobile devices (e.g. https://nl.wiktionary.org/wiki/WikiWoordenboek:De_Kroeg/archief19#Mobile_view_as_default_view_coming_soon ) This still relies on local Wikimedians translating that village pump message into their language, many are doing so with those announcements. And, as Ryan says, it is difficult to follow up on discussions in all those (ca. 600) village pumps, so those messages need to point back to a central venue for feedback. And, this is obviously a channel which can only be used for announcements of some degree of importance. One might be tempted to create a separate Wikitech ambassadors village pump and have the bot post there. But the new broadcasting functionality that is being developed as part of the Echo and Flow projects will offer a much better solution (basically, as user on a Wikimedia project you will be able to subscribe to receive notifications from information channels across projects, and I'm sure that one of these channels could offer such tech updates). -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailman archives broken?
On Fri, Aug 17, 2012 at 4:26 AM, MZMcBride z...@mzmcbride.com wrote: Guillaume Paumier wrote: I was told yesterday that the mailman/pipermail archives were broken, in that permalinks were no longer linking to the messages they used to link to (therefore not being permalinks at all). This is pretty devastating. It's difficult to overstate the importance of Mailman archives in documenting Wikimedia's history (or even history before Wikimedia was a concept). I've come across links such as the one at https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day that I can't even find anywhere in the Mailman archives any longer. :-( MZMcBride Many historical Signpost articles are affected as well: https://en.wikipedia.org/w/index.php?title=Special%3ASearchsearch=pipermail+wikitech+prefix%3AWikipedia%3AWikipedia+Signpost%2F2 BTW, here's Brion dreaming about a stable archiving system in 2007 ... http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/28993 In the same year, the lead developer of Mailman said that fixing this problem of breaking URLs was absolutely critical (http://mail.python.org/pipermail/mailman-developers/2007-July/019632.html ) and some ideas were thrown around (http://wiki.list.org/display/DEV/Stable+URLs ), but apparently this huge data integrity problem still hasn't been solved. -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IRC office hours with the Analytics team, Monday, July 30, 2012 at 19:00 UTC
Hi everyone, just a reminder that this is taking place three hours from now (http://www.timeanddate.com/worldclock/fixedtime.html?hour=19min=00sec=0day=30month=07year=2012 ) On Wed, Jul 25, 2012 at 7:46 PM, Tilman Bayer tba...@wikimedia.org wrote: Hi all, you are cordially invited to the first ever IRC office hours of the Foundation's recently formed Analytics team, taking place in #wikimedia-analytics on Freenode on Monday, July 30 at 19:00 UTC / noon PT (http://www.timeanddate.com/worldclock/fixedtime.html?hour=19day=30month=07year=2012 ). It is an opportunity to ask all your analytics and statistics related questions about Wikipedia and the other Wikimedia projects, in particular regarding the Wikimedia Report Card and the upcoming Kraken analytics platform. See also the blog post that the team just published: https://blog.wikimedia.org/2012/07/25/meet-the-analytics-team/ , as well as https://www.mediawiki.org/wiki/Analytics General information about IRC office hours is available at https://meta.wikimedia.org/wiki/IRC_office_hours . Regards, -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] IRC office hours with the Analytics team, Monday, July 30, 2012 at 19:00 UTC
Hi all, you are cordially invited to the first ever IRC office hours of the Foundation's recently formed Analytics team, taking place in #wikimedia-analytics on Freenode on Monday, July 30 at 19:00 UTC / noon PT (http://www.timeanddate.com/worldclock/fixedtime.html?hour=19day=30month=07year=2012 ). It is an opportunity to ask all your analytics and statistics related questions about Wikipedia and the other Wikimedia projects, in particular regarding the Wikimedia Report Card and the upcoming Kraken analytics platform. See also the blog post that the team just published: https://blog.wikimedia.org/2012/07/25/meet-the-analytics-team/ , as well as https://www.mediawiki.org/wiki/Analytics General information about IRC office hours is available at https://meta.wikimedia.org/wiki/IRC_office_hours . Regards, -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Article revision numbers
On Tue, Jul 17, 2012 at 4:32 AM, Derric Atzrott datzr...@alizeepathology.com wrote: Actually, the revision table allows for non-linear development (it stores from which version you edited the article). You could even make to win a version different than the one with the latest timestamp (by changing page_rev) one. You will need to change the way of viewing history, however, and add a system to keep track of heads and merges. There may be some assumtions accross the codebase about the latest revision being the active one, too. Cool! That's a nice solution because it's transparent to the end-user's system. However, if we use the current schema as you're describing, we would have to reconcile rev_id conflicts during the merge. This seems like a nasty problem if the merge is asynchronous, for example a batched changeset sent in email. -adam This is all a fantastic idea. Distributing Wikipedia in a fashion similar to git will make it a lot easier to use in areas where Internet connections are not so common. I have added this thread to https://en.wikipedia.org/wiki/User:HaeB/Timeline_of_distributed_Wikipedia_proposals . I wonder could this sort of feature be implemented in the existing Kiwix codebase? That would be ideal I think. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VIPS test
On Thu, Dec 22, 2011 at 12:32 AM, Tim Starling tstarl...@wikimedia.org wrote: On 22/12/11 10:19, Gregor Hagedorn wrote: Late addition, just tested VIPS with: https://test2.wikipedia.org/wiki/Special:VipsTest?file=Fern+Groombridge.JPGwidth=300sharpen=0.8 and found the non-bilinear VIPS version with its loss of detail rather disappointing. Bilinear scaling with sharpen 0.8 I find unacceptable, https://test2.wikipedia.org/wiki/Special:VipsTest?file=Fern+Groombridge.JPGwidth=300sharpen=0.8bilinear=1 closest results I had with 0.5: https://test2.wikipedia.org/wiki/Special:VipsTest?file=Fern+Groombridge.JPGwidth=300sharpen=0.6bilinear=1 ... but imagemagick is definitely still best. To me, both of those bilinear scaling results look broken. At this scaling ratio, it's effectively nearest-neighbour, not bilinear. I think a loss of detail on a single-pixel level is preferable to the extreme aliasing artifacts caused by nearest-neighbour downsampling. In this particular image, maybe you could mistake the result of nearest-neighbour interpolation for contrast enhancement. In images with more contrast in the fine detail, the breakage is unequivocal. Try today's featured picture: https://test2.wikipedia.org/wiki/Special:VipsTest?file=LaPaDu+Panorama+2010-10-03.jpgwidth=300sharpen=0.6bilinear=1 Is it possible to use VIPS only for oversized images? We'll probably only use it for TIFFs and large PNGs, not JPEGs. It looks like VIPS might also help to resolve https://bugzilla.wikimedia.org/show_bug.cgi?id=24854 (Black/striped thumbnails of CMYK JPEGs). See e.g. https://test2.wikipedia.org/wiki/Special:VipsTest?file=Coding_Shots_Annual_Plan_high_res-5_-_retouch_for_WMF_annual_report_2010-11.jpgwidth=640sharpen=0.8 / https://commons.wikimedia.org/wiki/File:Coding_Shots_Annual_Plan_high_res-5_-_retouch_for_WMF_annual_report_2010-11.jpg -- Tilman Bayer Movement Communications Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
