[Wikitech-l] Fwd: Re: [Wikisource-l] Standardize ProofreadPage namespaces, again
Messaggio originale Oggetto:Re: [Wikisource-l] Standardize ProofreadPage namespaces, again Data: Mon, 20 Oct 2014 22:15:42 +1100 Mittente: Wiki Billinghurst billinghurstw...@gmail.com Rispondi-a: discussion list for Wikisource, the free library wikisourc...@lists.wikimedia.org A: discussion list for Wikisource, the free library wikisourc...@lists.wikimedia.org Fully agree with Thomas's points. Find the right person within WMF to whom we need to talk. Get the defaults determined by them, and plugged into their configs. Then work with them to move sites to the config, fix up filters, etc. Bite size. I would suggest that on this matter we would be best to approach someone like Rob Lanphier to get someone as a contact. Regards, Billinghurst On Mon, Oct 20, 2014 at 6:44 PM, Thomas Tanon thoma...@hotmail.fr wrote: Yes, it's a small detail for Wikisourcerors but not for tech people because it requires to update a lot of rows in the database. So, I think that the concertation should be done more with system administrators than with Wikisourcerors. As 250/252 are the default ids for Page/Index namespaces and are dedicated to ProofreadPage they should be used. About the other namespaces, they are not managed specifically by an extension so the context is not exactly the same. I believe that this point should be raised only after the changes for Page/Index are done. Thomas Le 20 oct. 2014 à 09:07, Nicolas VIGNERON vigneron.nico...@gmail.com a écrit : 2014-10-20 2:51 GMT+02:00 Ricordisamoa ricordisa...@openmailbox.org: About this RFC, John Vandenberg agreed to use the 250 / 252 pair for Page and Index namespaces, respectively. Is it wise to just go ahead and request changing one site at a time? What are your wikis' general opinions about this? Not sure but I think that this change is important for technichal people and in the same time, it's probably a small detail for the wikisorcerors. Isn't it ? If it is, we should go ahead. What about the other namespaces ? (like I asked in March) Cdlt, ~nicolas ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Expected behavior of templates when a parameter appears multiple time
Assume we have the following call of a template:
{{template
|key1=value1
|key2=value2
|key1=value3
}}
What is the expected value of {{{key1}}} when parsing the template?
From the docs I've read, I would expect it to be value3. If so, does
value1 appear anywhere?
Thanks,
Strainu
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator for code review (defining the plan)
On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff bawo...@gmail.com wrote: Well there are a lot of links to it first of all. For which a redirect is a much better solution than sending the reader to a dead site and leaving them to figure out it's dead. At least for direct bug references it should be easy to set up a rewrite rule forwarding them to a Phabricator search on the bugzilla ticket number. The main reason for keeping Bugzilla up as long as possible would be, IMO, the personal details which won't be migrated but help people keep track of their bugs of interest, often across many years - votes, saved searches, personal whiteboards and such. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Expected behavior of templates when a parameter appears multiple time
On Tue, Oct 21, 2014 at 4:01 AM, Strainu strain...@gmail.com wrote:
What is the expected value of {{{key1}}} when parsing the template?
From the docs I've read, I would expect it to be value3.
That does seem to be the case.
If so, does value1 appear anywhere?
No.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Expected behavior of templates when a parameter appears multiple time
On Tue, Oct 21, 2014 at 3:48 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Tue, Oct 21, 2014 at 4:01 AM, Strainu strain...@gmail.com wrote:
What is the expected value of {{{key1}}} when parsing the template?
From the docs I've read, I would expect it to be value3.
That does seem to be the case.
MediaWiki history trivia: this is how {{if}} and similar templates used to
be implemented before parser functions existed.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla after Phabricator (was Re: Phabricator for code review)
On Tue, Oct 21, 2014 at 4:34 AM, Gergo Tisza gti...@wikimedia.org wrote: On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff bawo...@gmail.com wrote: Well there are a lot of links to it first of all. For which a redirect is a much better solution than sending the reader to a dead site and leaving them to figure out it's dead. At least for direct bug references it should be easy to set up a rewrite rule forwarding them to a Phabricator search on the bugzilla ticket number. This is what will happen: https://phabricator.wikimedia.org/T40 The main reason for keeping Bugzilla up as long as possible would be, IMO, the personal details which won't be migrated but help people keep track of their bugs of interest, often across many years - votes, saved searches, personal whiteboards and such. We have committed to keep Bugzilla in read-only mode after the Phabricator launch, and we haven't decided on any date to decommission it. We don't need to rush to decide that date. Bugzilla will be there until the day that it doesn't make sense to keep it. Tracked in https://phabricator.wikimedia.org/T366 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tech Talk: Design Research in Product Development: Oct 22
Reminder that this Tech Talk will be taking place tomorrow. On Tue, Oct 7, 2014 at 3:40 PM, Rachel Farrand rfarr...@wikimedia.org wrote: Please join us for the following tech talk: *Tech Talk**:* Design Research in Product Development *Presenter:* Abbey Ripstra, Design Usability Research Analyst on The UX team at the Wikimedia Foundation *Date:* October 22 *Time:* 1900 UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Design+Research+in+Product+Developmentiso=20141022T19p1=1440ah=1 Link to live YouTube stream http://www.youtube.com/watch?v=jYMTzzosUIw *IRC channel for questions:* #wikimedia-office Google+ page https://plus.google.com/u/0/b/103470172168784626509/events/caiiagf75bvddr09nf4jbgccn30, another place for questions Talk description: The value of design research in product development is being recognized more frequently these days. This talk will quickly describe the innovation process, and how, when and why design research fits into the different parts of the innovation process. For most of the talk, Abbey will focus in on the product development part of innovation and describe how, when and why to best utilize the various methodologies of design research toward building intuitive, easy to use products that meet the needs of users. Abbey will also talk about, and want to collaborate on, the best ways to integrate design research, specifically, into product development at Wikimedia Foundation. ___ 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
[Wikitech-l] Now you can submit / claim Engineering Community tasks
Following the activity of the Engineering Community team has never been simple, not even for ourselves. Proposing Engineering Community tasks effectively was even more complex. Here is an attempt to change this: https://phabricator.wikimedia.org/tag/engineering-community/ Since the beginning of this month, we are using Phabricator to organize the Engineering Community team work. https://phabricator.wikimedia.org/tag/ect-october-2014/board/ You can watch, comment, and get involved. You can also submit and claim tasks. What should we be working on next month? How can we facilitate more tech community work done by more people? See you there. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
