[Wikitech-l] development list for Wikidata
Heya folks :) We've created https://lists.wikimedia.org/mailman/listinfo/wikidata-tech to keep all the development discussions around Wikidata in one public place. Feel free to subscribe if you are interested. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. 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 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starter kit ?
Reading [1], I'm wondering if we couldn't have a wiki version of this page that could be updated along the road. For example the text talk about MySQL and but doesn't talk about the MariaDB migration. By the way the two The Architecture of Open Source Applications books may find there place on Wikisource, don't you think? But Wikisource isn't the place for books you want to update, may be Wikibooks may be a good place, what do you think? [1] http://www.aosabook.org/en/mediawiki.html Le 2013-04-15 20:09, Quim Gil a écrit : Hello Mathieu, welcome! These days we are getting many new potential contributors thanks to Google Summer of Code and Outreach Program for Women. We want to know what can we do better for you! On 04/13/2013 07:45 AM, Mathieu Stumpf wrote: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker https://www.mediawiki.org/wiki/How_to_contribute are two good places to begin. Thank you, it seems to be exactly what I need. :) This is very good to hear! Still, we welcome improvements to this Starter kit (well put). Just recently we have started a selection of essential resources for new contributors, see https://www.mediawiki.org/wiki/Category:New_contributors And we are discussing many other ideas at http://www.mediawiki.org/wiki/Project:New_contributors -- Association Culture-Libre http://www.culture-libre.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, May 6, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: MediaWiki Bugzilla Report for April 29, 2013 - May 06, 2013 Fresh charts[1] are available. Željko -- 1: https://www.mediawiki.org/wiki/Bugzilla_Weekly_Report ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Global watchlist and watchlist wishlist
Hi, A discussion has started on-wiki about a global watchlist, and other related improvements to the watchlist feature. A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. Improving a feature as used and central as the watchlist has the potential of drastically improving the users' experience, but is also likely to cause an outcry if proper research isn't done in advance, given that everyone has their own workflow. One comment that came up during the discussion was that people didn't want to spend time working on research, specifications prioritization of features unless they had some sort of guarantee that their work wouldn't just be ignored and rot in a corner because nobody's interested in actually implementing the changes. I think this is a fair and understandable request: nobody wants their hard work to go to waste. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. So, I have two questions: * Does this make sense? * Are you interested in improving the watchlist feature within, say, the next 6 months? More information: Discussion: https://www.mediawiki.org/wiki/Talk:Watchlist_wishlist Draft product page: https://www.mediawiki.org/wiki/Watchlist_wishlist -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starter kit ?
Hi, On Mon, May 6, 2013 at 2:28 PM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Reading [1], I'm wondering if we couldn't have a wiki version of this page that could be updated along the road. For example the text talk about MySQL and but doesn't talk about the MariaDB migration. [1] http://www.aosabook.org/en/mediawiki.html That chapter was actually written on mediawiki.org, as part of this project: https://www.mediawiki.org/wiki/MediaWiki_architecture_document The content of the chapter lives in 2 wiki pages: * https://www.mediawiki.org/wiki/MediaWiki_history * https://www.mediawiki.org/wiki/Manual:MediaWiki_architecture You're encouraged to update what needs updating :) By the way the two The Architecture of Open Source Applications books may find there place on Wikisource, don't you think? But Wikisource isn't the place for books you want to update, may be Wikibooks may be a good place, what do you think? Wikisource could host static versions of the books. Or Wikibooks could host live versions of the books. I'm not sure that we'd see many updates to the books outside of the MediaWiki chapter, so right now I'd rather encourage people to edit the content on mediawiki.org. -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: next steps
Hi, It seems to me that there are 15-20 distinct GSoC projects with interested mentors, depending on how you count it. Here's the list I compiled: Core MediaWiki: - Automatic category redirects - MediaWiki API 2.0 General extensions: - Book structures - Inline commenting - MediaWiki-Moodle Extension - Pronunciation Recording Extension - Refactoring of Proofread Page extension - UploadWizard improvements Technical, but not MediaWiki (I think): - Incremental data dumps - Language Coverage Matrix Dashboard Semantic MediaWiki: - Improvement of Lingo and Semantic Glossary - Section handling for Semantic Forms Translation: - Android app for translation - jQuery.IME VisualEditor: - VisualEditor i18n support - VisualEditor Math Equation Plugin - VisualEditor source code plugin Wikidata: - Entity suggester for Wikidata - Mobilize Wikidata - Wikidata language fallback and conversion That's 20, but some of the projects have overlapping mentors - the translation, VisualEditor and Wikidata projects all seem to have basically the same set of mentors across their proposals; which, if true, and assuming that can't be worked out somehow, could bring down the number of doable projects to 15. That's just my analysis, and it could be incorrect in places. -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starter kit ?
Le 2013-05-06 15:34, Guillaume Paumier a écrit : Hi, On Mon, May 6, 2013 at 2:28 PM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Reading [1], I'm wondering if we couldn't have a wiki version of this page that could be updated along the road. For example the text talk about MySQL and but doesn't talk about the MariaDB migration. [1] http://www.aosabook.org/en/mediawiki.html That chapter was actually written on mediawiki.org, as part of this project: https://www.mediawiki.org/wiki/MediaWiki_architecture_document The content of the chapter lives in 2 wiki pages: * https://www.mediawiki.org/wiki/MediaWiki_history * https://www.mediawiki.org/wiki/Manual:MediaWiki_architecture You're encouraged to update what needs updating :) Ok, thank you for the information. It may be interesting to add this link in [1], and maybe it would be more relevant to use this links on [2] instead of giving a link to [1], what do you think? [2] https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#MediaWiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Replacement for tagging in Gerrit
Hi, On Sun, Mar 10, 2013 at 2:11 AM, Rob Lanphier ro...@wikimedia.org wrote: Short version: This mail is fishing for feedback on proposed work on Gerrit-Bugzilla integration to replace code review tags. I was wondering: has a decision been made regarding this? I'm resuming work on (notably) identifying/marking noteworthy changes, and I'm interested to know if the tagging system is something that we could possibly take advantage of for this (and if so, what a rough timeline would be :). -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starter kit ?
Only to honor the subject and initial motivation of this thread: Recently we started drafting an actual Starter Kit, as Mathieu requested: https://www.mediawiki.org/wiki/Project:New_contributors/Starter_kit Edits and questions in the discussion page are welcome. In fact with a bit of focus from a few people during a few days we could get something pretty decent. Mathieu and other newcomers: your contribution is especially valuable since you still remember how it was when you landed here for the first time. -- Quim Gil Technical Contributor Coordinator @ 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] Global watchlist and watchlist wishlist
On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_projects might help as soon as there is a broad idea of what needs to be done. -- Quim Gil Technical Contributor Coordinator @ 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
[Wikitech-l] Fwd: Jared Zimmerman joins Wikimedia Foundation as Director of UX
FYI -- Forwarded message -- From: Erik Moeller e...@wikimedia.org Date: Mon, May 6, 2013 at 9:44 AM Subject: Jared Zimmerman joins Wikimedia Foundation as Director of UX To: wikimediaannounc...@lists.wikimedia.org Hi folks, It’s my great pleasure to announce that today, Jared Zimmerman will start as Wikimedia Foundation’s Director of User Experience. As UX Director, Jared will lead the design team and have a hands-on role on the team, contributing his own design work. It’s still a small team (Brandon, Vibha, May, and Pau), but we expect to hire an additional 3-4 designers in the coming 12-18 months. Prior to Wikimedia, Jared was Principal Interaction Designer at Autodesk, where he worked with engineers, visual artists, and user experience researchers to create new software solutions for architecture and design professionals with an emphasis on AutoCAD for Mac and soon to be released online design collaboration tools. Jared has led cross-disciplinary design teams in his roles at Autodesk, Ammunition Group, and iconmobile, including creative direction. At Autodesk, he was part of the transition to agile development and helped his design teams apply those principles to their work. During his time there he worked with design management to establish designers as product owners in the scrum process, to further integrate them into the development process from start to finish, as well as teaching his team best practices for use of agile design tools. Jared has degrees in Graphic Design (BGD) and Fine Art Photography (BFA) from the Rhode Island School of Design. His photography has been in featured in publications such as Travel + Leisure Magazine, ZonaRetiro, and Huffington Post. In addition to starting in his new job, Jared is also planning his wedding in July to his fiancée Shannon. [1] In his spare time Jared is wrapping up a remodel to their home, working on his first iPhone app, experimental cooking, photographing the bay area abroad [2], and answering questions on Quora. [3] I look forward to Jared’s leadership in helping elevate a delightful, consistent and efficient User Experience to becoming a key measure of success for our work. Please join me in welcoming Jared! :-) Erik [1] http://shannonbadiee.com/ [2] http://www.flickr.com/photos/spoinknet/ [3] https://www.quora.com/Jared-Zimmerman/answers -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starter kit ?
Le lundi 06 mai 2013 à 09:14 -0700, Quim Gil a écrit : Only to honor the subject and initial motivation of this thread: Recently we started drafting an actual Starter Kit, as Mathieu requested: https://www.mediawiki.org/wiki/Project:New_contributors/Starter_kit Edits and questions in the discussion page are welcome. In fact with a bit of focus from a few people during a few days we could get something pretty decent. Mathieu and other newcomers: your contribution is especially valuable since you still remember how it was when you landed here for the first time. Glad to hear that I could be useful there. I can't promess feedback before this week end though, I already have a full shedule. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global watchlist and watchlist wishlist
On 2013-05-06 1:31 PM, Quim Gil q...@wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_projectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global watchlist and watchlist wishlist
What happened to last years gsoc project in this area? Are there people working on getting it merged? Patchsets for watchlist are waiting for review for too long. The GSOC project: https://gerrit.wikimedia.org/r/#/c/16419/ other patchsets waiting for review: https://gerrit.wikimedia.org/r/#/c/38743/ https://gerrit.wikimedia.org/r/#/c/53964/ + https://gerrit.wikimedia.org/r/#/c/53968/ Is there anyone who is responsible for reviewing patches for watchlist? On Mon, May 6, 2013 at 9:11 PM, Brian Wolff bawo...@gmail.com wrote: On 2013-05-06 1:31 PM, Quim Gil q...@wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_projectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC mentors: selection process
Hi, long email but only for GSoC mentors and curious minds alike. WARNING: GSoC common sense requires absolute confidentiality about discussions or resolutions of candidates. You can't share any confidential information, no matter how evident it looks to you or how well you get along with a student or anybody without mentor / org admin access to Wikimedia GSoC. Google forbids explicitly any leakage of information before they publish officially the results on May 27. We can and we must discuss publicly our selection process, though. Ideally GSoC mentors would have a private call and discuss until deciding on a ranking of candidates. But with 38 people in different timezones, 47 proposals and ? slots this clearly won't work. Some organizations resolve this situation with votes, but I don't think this is a good solution in our context and the Wikimedia community favors consensus over voting anyway. Your distributed feedback on essential/desirable features has been very useful to make a first decision. Let's try a second round of distributed feedback to solve the clear cases: If you would be the only one deciding, how would you rank the proposals received (see the list below)? Please send me a PRIVATE email (not to this list!) with your ranking of features, ideally before the end of tomorrow Tuesday. * Read https://www.mediawiki.org/wiki/Mentorship_programs/Selection_process (just updated) and act accordingly. * Rank at least the projects you would prioritize before the one(s) you want to mentor. All the better if you rank more. Don't rank based on the title alone. All proposals have mentors feedback by now. * No need to decide on specific candidates for the features you are not mentoring. It is enough to rank Feature X, without you having to decide which of the students proposing Feature X should be selected. * But you do need to specify which student you select for the 1-2 projects you are co-mentoring. Agree the names with your co-mentors. You can't be in more than 2 projects, and ideally in just one. Mentors are free to skip the ranking game and go directly for the call. In that case their proposals will be ranked based on the feedback from the rest of us. I will consolidate sensibly all this feedback on Wednesday, in a private document shared with the mentors. Hopefully some proposals will be clear candidates to be accepted or declined. Then we will also know how many slots we are getting from Google, and we can focus the discussion in one call or more with the mentors of the unclear cases. Should work. We'll see. The list of projects to rank: * Android app for MediaWiki translation * Auto suggestion of categories * Automatic category redirects * Bayesan Spam Filter * Centralized Search Engine * Contribute to Wikimedia * Curriculum Wiki * Entity Suggester for Wikidata * Improve support for book structures * Improvement of glossary tools * Incremental data dumps * Incremental updates for Kiwix * Internationalization and Right-To-Left Support in VisualEditor * jQuery.IME extensions for Firefox and Chrome * jQuery.IME next big release improvements * Language Coverage Matrix Dashboard * MediaWiki API 2.0 * MediaWiki-Moodle extension * Mobilize Wikidata * Pronunciation Recording Extension * Prototyping inline comments * Refactoring of Proofread Page extension * Section handling in Semantic Forms * UploadWizard: Book upload customization * VisualEditor Math Equation Plugin * VisualEditor plugin for source code editing * VisualEditor plugins * Wikidata features * Wikidata language fallback and conversion * Wikipedia - My Encyclopedia -- Quim Gil Technical Contributor Coordinator @ 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
[Wikitech-l] Proposal: Let's move to a one-week deploy cycle
Hello all, Let's move our MediaWiki deploy cycle to weekly instead of 2-week. This will also reduce the number of standing deployment windows throughout the week by having those projects/teams simply ride the MediaWiki train. == Current situation == Right now, a new version of MediaWiki is rolled out to the WMF cluster over a two-week period. You can see the general flow of how it works on this page describing the deploy schedule for the 1.22 release: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_deployments == What are the drawbacks of two-weeks? == These are mostly known by everyone so I'll just simply state the most obvious one :-) It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis. == What would a one-week cycle look like? == This has been talked about a bit, including during the last In Town Week for WMF Engineering in late-February. I've coalesced on one proposal at: https://wikitech.wikimedia.org/wiki/Deployments/One_week This seems like a reasonable approach to me. Please respond here or on the talk page with comments/suggestions/etc. == Major benefit/goal with one-week cycle == Our current list of deployment windows during the week is pretty large, and it is not uncommon for a week to practically fill up with bug fix windows. If we moved to a weekly cycle then more of those bug-fixes could just roll out with the normal MediaWiki deploy. == Goal Timeline? == I would love to get us switched over to a one-week cycle by mid-June. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
Extrapolating from our experience from two-week deploy cycles and what bugs we find at each stage, would moving to a one-week deploy cycle substantially increase the number of users exposed to really bad bugs? For instance, if we're currently finding and fixing about 2 deployment blocker bugs per cycle after the mediawiki.org deploy but before the non-Wikipedias deploy, that data might imply that we should structure a 1-week cycle differently -- perhaps with three stages rather than two. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On Mon, 06 May 2013 21:04:39 +0200, Greg Grossmeier g...@wikimedia.org wrote: It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis. Four weeks, actually, if your change gets merged just after a branching point. (2 weeks until next branching + 2 weeks until it's deployed everywhere.) Needless to say I like this idea. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 3:04 PM, Greg Grossmeier g...@wikimedia.org wrote: Let's move our MediaWiki deploy cycle to weekly instead of 2-week. This will also reduce the number of standing deployment windows throughout the week by having those projects/teams simply ride the MediaWiki train. \o/ It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis. 3.5 weeks, actually. Consider if something was merged in the afternoon on April 29. It just missed getting into 1.22wmf3, so absent backporting it would have to wait for 1.22wmf4, which finishes being deployed everywhere on May 22. This has been talked about a bit, including during the last In Town Week for WMF Engineering in late-February. I've coalesced on one proposal at: https://wikitech.wikimedia.org/wiki/Deployments/One_week This seems like a reasonable approach to me. Please respond here or on the talk page with comments/suggestions/etc. One other plan that was discussed in February, if I recall, was something like this: week0, Thursday: Deploy wmf1 to test and mw.org week1, Monday: Deploy wmf1 to first-round wikis week1, Thursday: Deploy wmf1 to remaining wikis and wmf2 to test and mw.org. week2, Monday: Deploy wmf2 to first-round wikis week2, Thursday: Deploy wmf2 to remaining wikis and wmf3 to test and mw.org. etc. That has the advantage of preserving the separation of test+mw.org from the more user-focused wikis, as Sumana mentioned. -- Brad Jorsch Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
Le 06/05/13 21:04, Greg Grossmeier a écrit : Let's move our MediaWiki deploy cycle to weekly instead of 2-week. As long as we tend to the hour, I am fine :-] Weekly deploy is a bit of a challenge since we will have less time to figure out a solution for any blocking bug, but overall I think it will be a nice improvement to get less changes deployed. I am also wondering how many manual tasks we have to handle when doing and after the deployment. If we identify them and write tools for it, that would make it later possible to do two deployment per week :-] -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 12:20 PM, Sumana Harihareswara suma...@wikimedia.org wrote: Extrapolating from our experience from two-week deploy cycles and what bugs we find at each stage, would moving to a one-week deploy cycle substantially increase the number of users exposed to really bad bugs? For instance, if we're currently finding and fixing about 2 deployment blocker bugs per cycle after the mediawiki.org deploy but before the non-Wikipedias deploy, that data might imply that we should structure a 1-week cycle differently -- perhaps with three stages rather than two. I don't know what the stats are, but my intuition is that it's not generally that high. However, the ones we find are kinda big, so it still makes me nervous to go that route. I've edited the page, called Greg's proposal Alternative A, and added Alternative B which provides a little bit of time for catching issues on mw.org: https://wikitech.wikimedia.org/wiki/Deployments/One_week Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
quote name=Brad Jorsch date=2013-05-06 time=15:32:19 -0400 One other plan that was discussed in February, if I recall, was something like this: week0, Thursday: Deploy wmf1 to test and mw.org week1, Monday: Deploy wmf1 to first-round wikis week1, Thursday: Deploy wmf1 to remaining wikis and wmf2 to test and mw.org. week2, Monday: Deploy wmf2 to first-round wikis week2, Thursday: Deploy wmf2 to remaining wikis and wmf3 to test and mw.org. etc. That has the advantage of preserving the separation of test+mw.org from the more user-focused wikis, as Sumana mentioned. Yep, Robla's creating that sample calendar now. My reasoning for removing that initial separation that may be faulty: We're running automated and non-automated tests against betalabs, and that has started producing results (bugs reported and fixed before it was ever included in a wmfXX branch). Also, the majority of bugs that are in the Highest/Immediate priority level (from my gut assessment, I don't have the data here) are found after a deploy to non-WP projects. Thus, in a way, the non-WP projects really are our betatesters in all practicalities. That's my opinion at least. I'll work with Andre to get some numbers on this, if we can (date blocker bugs reported against our historic deploy calendar). I'm pretty sure this email will have a mid-air collision with Robla and his writeup of the proposal you outlined, Brad. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 12:52 PM, Greg Grossmeier g...@wikimedia.org wrote: Yep, Robla's creating that sample calendar now. My reasoning for removing that initial separation that may be faulty: We're running automated and non-automated tests against betalabs, and that has started producing results (bugs reported and fixed before it was ever included in a wmfXX branch). Also, the majority of bugs that are in the Highest/Immediate priority level (from my gut assessment, I don't have the data here) are found after a deploy to non-WP projects. Thus, in a way, the non-WP projects really are our betatesters in all practicalities. That's my opinion at least. I'll work with Andre to get some numbers on this, if we can (date blocker bugs reported against our historic deploy calendar). I'm pretty sure this email will have a mid-air collision with Robla and his writeup of the proposal you outlined, Brad. I'm all for a move to a one-week cycle. I think it's a good sign that even discussing moving to a one-week cycle brings up a review of how and where we're catching critical bugs, ala the above comments from Greg, Sumana, etc. Weekly deployments pushing us all to be more diligent about this stuff sounds like a good thing, even if it may feel intense pre/post the switch in the short term. -- Steven Walling https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 3:52 PM, Greg Grossmeier g...@wikimedia.org wrote: I'm pretty sure this email will have a mid-air collision with Robla and his writeup of the proposal you outlined, Brad. I think Robla was the one who suggested it in February, actually. I was just repeating it here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Proposal: Let's move to a one-week deploy cycle
quote name=Brad Jorsch date=2013-05-06 time=16:15:33 -0400 On Mon, May 6, 2013 at 3:52 PM, Greg Grossmeier g...@wikimedia.org wrote: I'm pretty sure this email will have a mid-air collision with Robla and his writeup of the proposal you outlined, Brad. I think Robla was the one who suggested it in February, actually. I was just repeating it here. Right, didn't mean to suggest otherwise. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC mentors: selection process
Hi Siebrand, moving your feedback about process to the list. On 05/06/2013 01:12 PM, Siebrand Mazeland (WMF) wrote: Here is my ranking (snip, thank you!) I would like to provide some feedback, too: The whole process of GSoC was very confusing to me. Students communicated on melange, mediawiki.org http://mediawiki.org, and mailing lists. Some also emailed me and others privately. This scattered communication made me feel I was not able to properly inform myself of the feedback cycles a proposal went through. Melange not having any capabilities to show differences between versions of proposals, does not help - that's unfortunately not something we can directly information. I hope that the number of communication platforms for GSoC communication and documentation can be reduced in the next iteration, to make the process easier to follow to those that are supposed to comment on, evaluate and rank the proposals. Yes, I agree. If it was confusing for you we can imagine how confusing it has been for many students. In the next iteration we will still have the same community channels + imperfect Google Melange, but we can do better at focusing the discussion I was very able and willing to follow all of your instructions from the below email and the ones on linked page, until I truly understood what following them would mean for me time wise. If I understand your request well, you are basically asking us to read all proposals, take 15 criteria and all comments into account, and then rate all *subjects*, not the individual proposals. I estimate this is about a day of work to do well. I'm sorry, but this is too much effort for me with this short notice. I've done the best I can with the time available to me. Mmm well, no. And I'm glad you invested maybe 1 hour instead of one day. Saying the project I mentor should go first! is easy. I'm asking mentors to tell what proposals they think should be considered before the ones they are willing to mentor. We have a pool of 38 smart people directly involved in Wikimdia GSoC mentoring and I believe your personal rankings will answer directly most of the questions. Of course you could spend a whole day assessing each proposal in detail. I believe you can go through the list pretty fast through, double-checking a few proposals that sound interesting but you are not familiar with. This quicker method has more room for personal mistakes, but if there are 37 other people playing the game I bet the consolidated list cannot go too wrong. Thank you for the participation and the feedback! We are trying many things here as we go. -- Quim Gil Technical Contributor Coordinator @ 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] Global watchlist and watchlist wishlist
Brian Wolff bawolff at gmail.com writes: On 2013-05-06 1:31 PM, Quim Gil qgil at wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_proj ectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Folks, Last year, I worked on making improvements to the watchlist feature as my project for GSoC. The changes I made are still available as an unmerged change in Gerrit. [1] I'm glad to see that the project is starting to gain momentum. A major limitation of my efforts last year was that, under GSoC rules, I was the only developer who was allowed to code for the project. Now that other developers are looking to work on the project, I think that a project of this size has a much better chance of succeeding. Watchlist improvements as a project is extremely susceptible to feature creep, and unless there is a well-defined plan from the start, it risks getting shelved entirely. A blog of my progress last summer is available for ideas. [2] I'd recommend fixing feature request bugs as a large coordinated overhaul of the watchlist, rather than a piecemeal approach that may result in duplicative code or work that gets scrapped soon after it is finished. I may be unavailable intermittently for the next 6 weeks, but I should be able to help out from the middle of June until early September. -Aaron [1] https://gerrit.wikimedia.org/r/#/c/16419/ [2] http://mw-watchlist.tumblr.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extension:OpenID new version 3.30 20130505
tl;dr New OpenID extension version 3.30 20130505 https://www.mediawiki.org/wiki/Extension:OpenID A new version 3.30 20130505 has been published today. It's a security fix and fixes some CSRF and XSS vulnerabilities. The new version is strongly recommended. Has been tested and works with latest MediaWiki including 1.22alpha and also PHP versions including the 5.5.0beta versions. If you find bugs, please file them directly in our bug tracker https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=OpenID Thomas signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global watchlist and watchlist wishlist
On 05/06/2013 05:26 PM, Aaron Pramana wrote: Brian Wolff bawolff at gmail.com writes: On 2013-05-06 1:31 PM, Quim Gil qgil at wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_proj ectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Folks, Last year, I worked on making improvements to the watchlist feature as my project for GSoC. The changes I made are still available as an unmerged change in Gerrit. [1] I'm glad to see that the project is starting to gain momentum. A major limitation of my efforts last year was that, under GSoC rules, I was the only developer who was allowed to code for the project. Aaron, can you point me to that rule? I am nearly certain that you are wrong. Now that other developers are looking to work on the project, I think that a project of this size has a much better chance of succeeding. Watchlist improvements as a project is extremely susceptible to feature creep, and unless there is a well-defined plan from the start, it risks getting shelved entirely. A blog of my progress last summer is available for ideas. [2] I'd recommend fixing feature request bugs as a large coordinated overhaul of the watchlist, rather than a piecemeal approach that may result in duplicative code or work that gets scrapped soon after it is finished. I may be unavailable intermittently for the next 6 weeks, but I should be able to help out from the middle of June until early September. -Aaron [1] https://gerrit.wikimedia.org/r/#/c/16419/ [2] http://mw-watchlist.tumblr.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global watchlist and watchlist wishlist
+1 Such a rule would seem rather misguided... -bawolff On 2013-05-06 6:58 PM, Sumana Harihareswara suma...@wikimedia.org wrote: On 05/06/2013 05:26 PM, Aaron Pramana wrote: Brian Wolff bawolff at gmail.com writes: On 2013-05-06 1:31 PM, Quim Gil qgil at wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_proj ectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Folks, Last year, I worked on making improvements to the watchlist feature as my project for GSoC. The changes I made are still available as an unmerged change in Gerrit. [1] I'm glad to see that the project is starting to gain momentum. A major limitation of my efforts last year was that, under GSoC rules, I was the only developer who was allowed to code for the project. Aaron, can you point me to that rule? I am nearly certain that you are wrong. Now that other developers are looking to work on the project, I think that a project of this size has a much better chance of succeeding. Watchlist improvements as a project is extremely susceptible to feature creep, and unless there is a well-defined plan from the start, it risks getting shelved entirely. A blog of my progress last summer is available for ideas. [2] I'd recommend fixing feature request bugs as a large coordinated overhaul of the watchlist, rather than a piecemeal approach that may result in duplicative code or work that gets scrapped soon after it is finished. I may be unavailable intermittently for the next 6 weeks, but I should be able to help out from the middle of June until early September. -Aaron [1] https://gerrit.wikimedia.org/r/#/c/16419/ [2] http://mw-watchlist.tumblr.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Global watchlist and watchlist wishlist
We figured it out. Aaron had been reading a rule wrong, and I've written Google to ask them to clarify it in the future to prevent future misreadings. :( So we can get back to the thread topic - watchlist improvements! -Sumana On 05/06/2013 06:33 PM, Brian Wolff wrote: +1 Such a rule would seem rather misguided... -bawolff On 2013-05-06 6:58 PM, Sumana Harihareswara suma...@wikimedia.org wrote: On 05/06/2013 05:26 PM, Aaron Pramana wrote: Brian Wolff bawolff at gmail.com writes: On 2013-05-06 1:31 PM, Quim Gil qgil at wikimedia.org wrote: On 05/06/2013 05:41 AM, Guillaume Paumier wrote: A few people have started to organize the various bug reports about watchlists, but there is still much to do before we have a clear prioritized vision of what the watchlist feature should become. fwiw I had already suggested a Bug Day focusing on the Watchlist feature. If this is considered useful Andre could schedule it whenever appropriate. Therefore, if a few developers could declare their interest in tackling the watchlist issue in the foreseeable future, it would help arouse interest and enthusiasm from users, and motivate them to organize user research in order to design a better watchlist feature. I don't think we need a formal pledge or commitment; a simple declaration of interest would imho be enough to get started. The specifics can be ironed out later. Sounds like an entry to http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Raw_proj ectsmight help as soon as there is a broad idea of what needs to be done. What happened to last years gsoc project in this area? Are there people working on getting it merged? -bawolff ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Folks, Last year, I worked on making improvements to the watchlist feature as my project for GSoC. The changes I made are still available as an unmerged change in Gerrit. [1] I'm glad to see that the project is starting to gain momentum. A major limitation of my efforts last year was that, under GSoC rules, I was the only developer who was allowed to code for the project. Aaron, can you point me to that rule? I am nearly certain that you are wrong. Now that other developers are looking to work on the project, I think that a project of this size has a much better chance of succeeding. Watchlist improvements as a project is extremely susceptible to feature creep, and unless there is a well-defined plan from the start, it risks getting shelved entirely. A blog of my progress last summer is available for ideas. [2] I'd recommend fixing feature request bugs as a large coordinated overhaul of the watchlist, rather than a piecemeal approach that may result in duplicative code or work that gets scrapped soon after it is finished. I may be unavailable intermittently for the next 6 weeks, but I should be able to help out from the middle of June until early September. -Aaron [1] https://gerrit.wikimedia.org/r/#/c/16419/ [2] http://mw-watchlist.tumblr.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC: New approach to release notes
On May 3, 2013, at 9:33 PM, Anomie wrote: On Fri, May 3, 2013 at 1:02 PM, Krinkle wrote: First of all, I think a lot of our commit subjects are poorly written, even for a commit message. Having said that, a good commit subject is also a good release note (that is, if the change itself is notable for release notes). I don't think that these extensive paragraphs of text we are known for in release notes are a good habit. In my opinion, a good commit summary and a good release note are not necessarily the same thing at all, otherwise we could just dump the git log as the release notes and be done with it. Release notes *should* go into sufficient detail to tell the reader what it is they should be noting. I believe that a (filtered) list of good summaries is indeed sufficient for the release notes. The projects I referenced as example already proof this fact. I don't think it is realistic to think that we need a different type of message for the release notes for each change. There are some changes (by far not the majority) that require special attention, for example when: * the site admin needs to make changes to their configuration prior or during upgrading * the site admin needs to update specific extensions at the same time due to breaking compatibility * an extension maintainer should make changes soon due to deprecation of a feature * an extension maintainer needs to ensure changes are made due to removal of a feature * etc. However in such case an entry in the list of changes in the release notes that is more elaborate than the others doesn't really stand out. In such case, as I believe we have in most cases already, the text in question needs to be written in a paragraph in the Compatibility, Upgrading or similar sections. We already have a 62-char limit for the commit subject. That seems to be going well. Assuming that we properly summarise changes that way already, why would one need more room in the release notes? It is the same event. Taking a recent example[1], please tell me how to compress the following into 62 characters: (in the New features section) * (bug 45535) introduced the new 'LanguageLinks' hook for manipulating the language links associated with a page before display. (in the API section) * BREAKING CHANGE: action=parse no longer returns all langlinks for the page with prop=langlinks by default. The new effectivelanglinks parameter will request that the LanguageLinks hook be called to determine the effective language links. * BREAKING CHANGE: list=allpages, list=langbacklinks, and prop=langlinks do not apply the new LanguageLinks hook, and thus only consider language links stored in the database. I don't think Add LanguageLinks hook with breaking changes to 4 API modules is detailed enough for release notes. And before you try to cheat and split it into multiple commits, note that the new hook and what it means for how langlinks are stored in the database is what is the breaking change in those API modules; the actual changes to the API modules are just mitigating or noting it. The summary actually used for that revision, BTW, was (bug 45535) Hook for changing language links. [1]: https://gerrit.wikimedia.org/r/#/c/59997/ Though this is not a typical type of change and I think you already know the answer, I'll give you my take on this one. As commit subject (and thus release notes change log entry) I'd use: Add hook LanguageLinks for changing langlinks before display Regarding the change itself: 1) I think this hook should be renamed as it ambiguous. It could be a hook for changing langlinks when parsing/saving a page (input) or a hook to implement a custom source of langlinks when requesting them (output). 2) I'm not sure why you'd make ApiParse not call the hook by default. An option to get the raw langlinks may be useful (I'd be curious as to the use cases, but I can imagine), but doing so by default seems odd. Regarding the release notes: This change is a typical case where extra-awareness notes are in order. I personally wouldn't consider these breaking changes, but anyway, they are certainly important. So these are are the kind of changes for which you'd include notes in a separate section. Which brings me to another point. No doubt these are breaking changes, but in a way almost every change is potentially a breaking change for something for someone, somewhere. The kind of changes that break things we previously supported should be noted in those separate sections. Thus resulting in a situation where the change log is skimmable for the curious and only containing summaries of notable changes. And anything that requires attention is clearly separate and to be read first for all eyes (breaking changes for site admins or extension maintainers and configuration changes). -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
Greg Grossmeier wrote: == What are the drawbacks of two-weeks? == These are mostly known by everyone so I'll just simply state the most obvious one :-) It takes up to 2 weeks for new features/bug fixes to be rolled out to the various Wikimedia wikis. This is not a bad thing, though. Two weeks is a helluva lot better than it could be (or has been). :-) These conversations get a little murky when we're discussing deployments. I feel like there's a distinction between MediaWiki core and extension general fixes and upgrades versus new features and functionality being deployed to Wikimedia wikis. I think everyone agrees that the faster we can get bug fixes in, the better. But when it comes to triaging and prioritizing features and enabling certain features by default... does such a distinction exist outside my mind? The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 7:20 PM, MZMcBride z...@mzmcbride.com wrote: The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions. A lot of this could potentially be addressed in a consistent manner across wikis if we applied the alpha-beta-prod (or just beta-prod for starters) channel model that's used on the Wikimedia mobile sites. Then features (whether in core or extensions) could be flagged for alpha or beta readiness, and users would only get them if they've decided to opt into either of those channels. We could still flip the switch from beta-prod, but that decision could be decoupled from the weekly deployment cycle. This would likely be done for features changes which have significant user-facing impact, and where segregation into on and off modes is possible (not always the case). We may want to consider at least putting some such scaffolding for beta-prod desktop modes into place before shifting to weekly deployments, although if that holds up this change significantly, I'd be in favor of making the shift first and then iterating. Right now we have lots of individual experimental prefs, some dark launch URL parameters (useNew=1 for the account creation forms etc.), some changes that are announced widely but then rolled out immediately (section edit link change), etc. What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. And we'd need to consider more carefully if/when to make the beta/prod switch -- not necessarily a bad thing. ;-) Have there been any negative experiences with this model on the mobile sites? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [Language Engineering] Office hour on May 8, 2013 at 1700 UTC/1000 PDT
Hello, The Wikimedia Language Engineering team [1] invites everyone to join the team’s monthly office hour on May 8, 2013 (Wednesday) at 1700 UTC/1000 PDT on #wikimedia-office. During this session we would be talking about some our recent activities and updates from the ongoing projects. Event details and the general agenda is mentioned below. See you all at the IRC office hour! Thanks Runa Event Details: === # Date: May 8, 2013 # Time: 1700-1800 UTC, 1000-1100 PDT #IRC channel: #wikimedia-office on irc.freenode.net Agenda: # Introductions # Universal Language Selector - Development updates, Deployment schedule # MediaWiki Language Extension Bundle (MLEB) Release # Maven program - upcoming events # GSoC update - we are participating in GSoC # Q/A - We shall be taking questions during the session. Questions can also be sent to runa at wikimedia dot org before the event and can be addressed during the office-hour. [1] http://wikimediafoundation.org/wiki/Language_Engineering_team -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
No negative experiences at all Erik. The only real problems we've run into are people complaining they weren't aware of editing features that we pushed to mobile that users were not aware of due to not using mobile. I reckon this would be less of an issue in desktop. I would ___ love ___ to see a stable, beta, alpha model on desktop ... After reading a lot of the Echo feedback today I feel a lot of the problems, complaints about not hearing about it could have been addressed by being in a beta mode. It has also made innovation, experimentation, testing and transparency much easier than it would have been had we just pushed new features directly to large audiences. Please help make this happen. I'm happy to talk more in detail with anyone who wants to implement this. On 6 May 2013 19:43, Erik Moeller e...@wikimedia.org wrote: On Mon, May 6, 2013 at 7:20 PM, MZMcBride z...@mzmcbride.com wrote: The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions. A lot of this could potentially be addressed in a consistent manner across wikis if we applied the alpha-beta-prod (or just beta-prod for starters) channel model that's used on the Wikimedia mobile sites. Then features (whether in core or extensions) could be flagged for alpha or beta readiness, and users would only get them if they've decided to opt into either of those channels. We could still flip the switch from beta-prod, but that decision could be decoupled from the weekly deployment cycle. This would likely be done for features changes which have significant user-facing impact, and where segregation into on and off modes is possible (not always the case). We may want to consider at least putting some such scaffolding for beta-prod desktop modes into place before shifting to weekly deployments, although if that holds up this change significantly, I'd be in favor of making the shift first and then iterating. Right now we have lots of individual experimental prefs, some dark launch URL parameters (useNew=1 for the account creation forms etc.), some changes that are announced widely but then rolled out immediately (section edit link change), etc. What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. And we'd need to consider more carefully if/when to make the beta/prod switch -- not necessarily a bad thing. ;-) Have there been any negative experiences with this model on the mobile sites? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
