Re: [Wikitech-l] [Engineering] Parsoid announcement: Main roundtrip quality target achieved
On Thu, Jun 25, 2015 at 6:22 PM, Subramanya Sastry ssas...@wikimedia.org wrote: * Pare down rendering differences between the two systems so that we can start thinking about using Parsoid HTML instead of MWParser HTML for read views. ( https://phabricator.wikimedia.org/T55784 ) Any hope of adding the Parsoid metadata to the MWParser HTML so various fancy things can be done in core MediaWiki for smaller installations instead of having to run a separate service? Or does that fall under Make Parsoid redundant in its current complex avatar? -- 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] Parsoid announcement: Main roundtrip quality target achieved
On Fri, Jun 26, 2015 at 11:52 AM, Subramanya Sastry ssas...@wikimedia.org wrote: On 06/25/2015 06:29 PM, David Gerard wrote: On 25 June 2015 at 23:22, Subramanya Sastry ssas...@wikimedia.org wrote: On behalf of the parsing team, here is an update about Parsoid, the bidirectional wikitext - HTML parser that supports Visual Editor, Flow, and Content Translation. xcellent. How close are we to binning the PHP parser? (I realise that's a way off, but grant me my dreams.) The PHP parser used in production has 3 components: the preprocessor, the core parser, Tidy. Parsoid relies on the PHP preprocessor (access via the mediawiki API), so that part of the PHP parser will continue to be in operation. As noted in my update, we are working towards read views served by Parsoid HTML which requires several ducks to be lined up in a row. When that happens everywhere, the core PHP parser and Tidy will no longer be used. Do we have plans for avoiding code rot in unused the PHP parser code that would affect smaller third-party sites that don't using Parsoid? -- 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] Parsoid announcement: Main roundtrip quality target achieved
On 06/29/2015 09:20 AM, Brad Jorsch (Anomie) wrote: On Fri, Jun 26, 2015 at 11:52 AM, Subramanya Sastry ssas...@wikimedia.org wrote: The PHP parser used in production has 3 components: the preprocessor, the core parser, Tidy. Parsoid relies on the PHP preprocessor (access via the mediawiki API), so that part of the PHP parser will continue to be in operation. As noted in my update, we are working towards read views served by Parsoid HTML which requires several ducks to be lined up in a row. When that happens everywhere, the core PHP parser and Tidy will no longer be used. Do we have plans for avoiding code rot in unused the PHP parser code that would affect smaller third-party sites that don't using Parsoid? My response to your other email covers quite a bit of this. As far as I have observed, the PHP parser code has been quite stable for a while. And, small third-party sites are unlikely to have complex requirements and are less likely to hit serious bugs. In any case, we'll do a good-faith effort to keep the PHP parser maintained and we'll fix critical and really high priority bugs. But, simply by virtue of us being a small team with multple reponsibilities, we will prioritize reducing complexity in Parsoid over keeping the PHP parser maintained. In the long run, I think that is a better path to bringing the two systems together. Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Parsoid announcement: Main roundtrip quality target achieved
On 06/29/2015 09:19 AM, Brad Jorsch (Anomie) wrote: On Thu, Jun 25, 2015 at 6:22 PM, Subramanya Sastry ssas...@wikimedia.org mailto:ssas...@wikimedia.org wrote: * Pare down rendering differences between the two systems so that we can start thinking about using Parsoid HTML instead of MWParser HTML for read views. ( https://phabricator.wikimedia.org/T55784 ) Any hope of adding the Parsoid metadata to the MWParser HTML so various fancy things can be done in core MediaWiki for smaller installations instead of having to run a separate service? Or does that fall under Make Parsoid redundant in its current complex avatar? Short answer: the latter. Long answer: read on. Our immediate focus in the coming months would be to bring PHP parser and Parsoid output closer. Some of that work would be to tweak Parsoid output / CSS where required, but also to bring PHP parser output closer to Parsoid output. https://gerrit.wikimedia.org/r/#/c/196532/ is one step along those lines, for example. Scott has said he will review that closely with this goal in mind. Another step is to get rid of Tidy and use a HTML5 compliant tree builder similar to what Parsoid uses. Beyond these initial steps, bringing the two together (both in terms of output and functionality) will require bridging the computation models ... string-based vs. DOM-based. For example, we cannot really add Parsoid-style metadata for templates to the PHP parser output without being able to analyze the DOM -- that requires us to access the DOM after Tidy (or the Tidy-replacement ideally) has a go at it. It requires us to implement all the dirty tricks we implement to identify template boundaries in the presence of unclosed tags, misnested tags, fostered content from tables, and dom restructuring the HTML tree builder does to comply with HTML5 semantics. Besides that, if you want to also serialize this back to wikitext without introducing dirty diffs (there is really no reason to do all this extra work if you cannot also serialize it back to wikitext), you also need to be able to either (a) maintain a lot of extra state in the DOM beyond what Parsoid maintains, or (b) do all the additional work that Parsoid does to maintain an extremely precise mapping between wikitext strings and DOM trees. Once again, the only reason (b) is complicated is because of unclosed tags, misnested tags, fostered content, DOM restructuring because of HTML5 semantics. There is a fair amount of complexity hidden there in those 2 steps, and it really does not make sense to reimplement all of that in the PHP parser. If you do, at that point, you've effectively reimplemented Parsoid in PHP -- the PHP parser in its current form is unlikely to stay as is. So, the only real way out here is to move the wikitext computational model closer to a DOM model. This is not a done deal really, but we have talked about several ideas over the last couple years to move this forward in increments. I don't want to go into a lot of detail in this email since this is already getting lengthy, but I am happy to talk more about it if there is interest. To summarize, here are the steps as we see it: * Bring PHP parser and Parsoid output as close as we can (replace Tidy, fix PHP parser output wherever possible to be closer to Parsoid output). * Incrementally move wikitext computational model to be DOM based using Parsoid as the bridge that preserves compatibility. This is easier if we have removed Tidy from the equation. * Smoothen out the harder edge cases which simplifies the problem and eliminates the complexity * At this point, Parsoid current complexity will be unnecessary (specifics dependent on previous steps) = you could have this functionality back in PHP if it is so desired. But, by then, hopefully, there will also be better clarity about mediawiki packaging that will also influence this. Or, some small wikis might decide to be HTML-only wikis. Subbu. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
I run GrantsBot, which is listed here. I've updated all GrantsBot API requests to use rawcontinue=1. But as I read through this thread, it's not clear to me that that's the problem. I can't find a single instance in my code where I'm actually continuing a query. Does this breaking change only apply be an issue if you were using querycontinue in the first place? I'm sure this has been covered elsewhere or I'm missing something obvious, but I'd be grateful for specific confirmation :) Best, Jonathan On Wed, Jun 10, 2015 at 12:01 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Jun 3, 2015 at 12:43 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Jun 3, 2015 at 7:29 AM, John Mark Vandenberg jay...@gmail.com wrote: If possible, could you compile a list of bots affected at a lower threshold - maybe 1,000. That will give us a better idea of the scale of bots operators that will be affected when this lands - currently in one months time. I already have the list of *accounts* affected: there are 510 with between 1000 and 1 hits. Of those, 454 do not contain bot (case insensitively), so they might be human users with user scripts, or AWB if that's not fixed (someone please check!), or the like. For comparison, in the over-1 group there were 30 such that I filtered out. I'll want to check with Legal to make sure the additional release of account names is still compliant with the privacy policy (I'm almost but not entirely sure it would be ok). Legal recommended we only post the list of bots, not the human accounts. These are: AHbot AsuraBot Autobot BattyBot Bibcode_Bot Bottuzzu ChenzwBot Cydebot DickensBot DrTrigonBot DSisyphBot DumbBOT DYKHousekeepingBot DYKUpdateBot FBot GiftBot GrantsBot HangsnaBot HangsnaBot2 ImageRemovalBot InceptionBot JackBot JBot Jimmy-bot Kenrick95Bot KrBot KrinkleBot LivingBot MalafayaBot MaraBot MauroBot MBHbot Mr.Z-bot NowCommons-Sichtbot Olafbot PereBot PseudoBot QianBot Rainbot Reports_bot RFF-Bot Salebot Sanjeev_bot SemperBlottoBot SergoBot SHBot Steenthbot TurkászBot UWCTransferBot VlsergeyBot VriuBot YiFeiBot Yobot ZacheBot Zlobot Note this list is still from May 23–29; a bot appearing in this list may have been updated since then. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
Jonathan, in theory, if you never use query continuation, you don't need to do anything with your code - you just need to tell the community that the bot is ok to use the new continuation system. This way noone will block the bot just in case. It is much better than to use rawcontinue, because that flag will keep telling us someone needs the old system. On Mon, Jun 29, 2015 at 8:01 PM, Jonathan Morgan jmor...@wikimedia.org wrote: I run GrantsBot, which is listed here. I've updated all GrantsBot API requests to use rawcontinue=1. But as I read through this thread, it's not clear to me that that's the problem. I can't find a single instance in my code where I'm actually continuing a query. Does this breaking change only apply be an issue if you were using querycontinue in the first place? I'm sure this has been covered elsewhere or I'm missing something obvious, but I'd be grateful for specific confirmation :) Best, Jonathan On Wed, Jun 10, 2015 at 12:01 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Jun 3, 2015 at 12:43 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Jun 3, 2015 at 7:29 AM, John Mark Vandenberg jay...@gmail.com wrote: If possible, could you compile a list of bots affected at a lower threshold - maybe 1,000. That will give us a better idea of the scale of bots operators that will be affected when this lands - currently in one months time. I already have the list of *accounts* affected: there are 510 with between 1000 and 1 hits. Of those, 454 do not contain bot (case insensitively), so they might be human users with user scripts, or AWB if that's not fixed (someone please check!), or the like. For comparison, in the over-1 group there were 30 such that I filtered out. I'll want to check with Legal to make sure the additional release of account names is still compliant with the privacy policy (I'm almost but not entirely sure it would be ok). Legal recommended we only post the list of bots, not the human accounts. These are: AHbot AsuraBot Autobot BattyBot Bibcode_Bot Bottuzzu ChenzwBot Cydebot DickensBot DrTrigonBot DSisyphBot DumbBOT DYKHousekeepingBot DYKUpdateBot FBot GiftBot GrantsBot HangsnaBot HangsnaBot2 ImageRemovalBot InceptionBot JackBot JBot Jimmy-bot Kenrick95Bot KrBot KrinkleBot LivingBot MalafayaBot MaraBot MauroBot MBHbot Mr.Z-bot NowCommons-Sichtbot Olafbot PereBot PseudoBot QianBot Rainbot Reports_bot RFF-Bot Salebot Sanjeev_bot SemperBlottoBot SergoBot SHBot Steenthbot TurkászBot UWCTransferBot VlsergeyBot VriuBot YiFeiBot Yobot ZacheBot Zlobot Note this list is still from May 23–29; a bot appearing in this list may have been updated since then. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF) ___ 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] Upcoming SyntaxHighlight_GeSHi changes
Il 29/06/2015 20:01, Brad Jorsch (Anomie) ha scritto: On Mon, Jun 22, 2015 at 8:48 PM, Ori Livneh o...@wikimedia.org wrote: Over the course of the next two days, a major update to the SyntaxHighlight_GeSHi extension will be rolled out to Wikimedia wikis. The change swaps geshi, the unmaintained PHP library which performs the lexical analysis and output formatting of code, for another library, called Pygments. ... Please tell me we're not really going to have the final state here be an extension named SyntaxHighlight_GeSHi that doesn't use GeSHi anymore. Here we are. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile
On Mon, Jun 29, 2015 at 10:31 AM, Jon Robson jrob...@wikimedia.org wrote: Hi Jacob I've cc'ed wikitech to get an update on bug https://phabricator.wikimedia.org/T483 The last update here was in February 2015. I personally think this is one of our most urgent bugs to fix, but it's not clear who is responsible for this, and who has the expertise to help resolve it. The fundamental issue this privacy policy hits, is many our editors are also hitting - that there is no way to style wikitext content differently on a mobile screen. This has been a recurring problem for some time now. https://phabricator.wikimedia.org/T483 The only way to make any progress here currently is the following: * Add the nomobile class to an element to hide it * Add a reset rule to MediaWiki:Common.css to reset problematic styles e.g. https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.css I'm near positive these very same issues were discussed over a year go for the privacy policy on English Wikipedia and I think the conclusion was there was little that could be done in current form (if anyone can remember where that conversation happened). Note: For wikimediafoundation.org it might be acceptable to move all inline style rules into https://m.wikimediafoundation.org/w/index.php?title=MediaWiki:Mobile.css and use media queries to style content differently. Any capable web developer should be able to help you with that (I'm not sure who is building the privacy policy for you). Jon On Thu, Jun 25, 2015 at 2:33 PM, Adam Baso ab...@wikimedia.org wrote: Moving to mobile-l. Discuss. -Adam On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson jrob...@wikimedia.org wrote: cc. reading-list. You'll get more feedback there :) Short reply: There are lots of bugs and larger problems here that need to be solved. On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers jrog...@wikimedia.org wrote: Hi Jon, James A suggested you might be the right person to talk with about improving the readability of the WMF privacy policy on mobile devices. Currently, it's pretty difficult to look at. It starts with the massive language list, the disclaimer renders 1-2 words a line, and the blue boxes also render in hard to read lines as well as pushing the main section to scroll off the screen. If you are the right person, what I'm hoping we can do is make the language list into an expandable menu, get rid of the blue boxes on the sides if necessary, and possibly make the examples into an expandable view rather than have everything shown by default. If you're not the right person to this, could you forward me on to someone that might be able to help? Many thanks, Jacob -- Jacob Rogers Legal Counsel Wikimedia Foundation NOTICE: This message might have confidential or legally privileged information in it. If you have received this message by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity. For more on what this means, please see our legal disclaimer. ___ reading-wmf mailing list reading-...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Upcoming SyntaxHighlight_GeSHi changes
On Mon, Jun 22, 2015 at 8:48 PM, Ori Livneh o...@wikimedia.org wrote: Over the course of the next two days, a major update to the SyntaxHighlight_GeSHi extension will be rolled out to Wikimedia wikis. The change swaps geshi, the unmaintained PHP library which performs the lexical analysis and output formatting of code, for another library, called Pygments. ... Please tell me we're not really going to have the final state here be an extension named SyntaxHighlight_GeSHi that doesn't use GeSHi anymore. -- 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] Upcoming SyntaxHighlight_GeSHi changes
On Mon, 29 Jun 2015 20:01:08 +0200, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: ... Please tell me we're not really going to have the final state here be an extension named SyntaxHighlight_GeSHi that doesn't use GeSHi anymore. Yeah, that would suck somewhat. https://phabricator.wikimedia.org/T103614 -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
Thanks Yuri and Brad! On Mon, Jun 29, 2015 at 11:10 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Mon, Jun 29, 2015 at 1:53 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: It is much better than to use rawcontinue, because that flag will keep telling us someone needs the old system. I doubt we'll ever get rid of rawcontinue. There's practically no code to maintain there (it's just a one-line function[1] and a trivial if-block to call it[2]) so it's highly unlikely to be worth even minimal effort. [1]: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/26288853/includes%2Fapi%2FApiContinuationManager.php#L163 [2]: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/26288853/includes%2Fapi%2FApiQuery.php#L295 -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
On Mon, Jun 29, 2015 at 1:53 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: It is much better than to use rawcontinue, because that flag will keep telling us someone needs the old system. I doubt we'll ever get rid of rawcontinue. There's practically no code to maintain there (it's just a one-line function[1] and a trivial if-block to call it[2]) so it's highly unlikely to be worth even minimal effort. [1]: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/26288853/includes%2Fapi%2FApiContinuationManager.php#L163 [2]: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/26288853/includes%2Fapi%2FApiQuery.php#L295 -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Plan for a Developer Relations team
Hi, the Engineering Community team is working on a plan to evolve onto a Developer Relations team. This is not just a change of name. See *https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team* Your feedback is welcome, in the wiki page or here. Related task: https://phabricator.wikimedia.org/T97283 -- 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] Plan for a Developer Relations team
On Jun 29, 2015 3:01 PM, Quim Gil q...@wikimedia.org wrote: Hi, the Engineering Community team is working on a plan to evolve onto a Developer Relations team. This is not just a change of name. See * https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team * Your feedback is welcome, in the wiki page or here. Related task: https://phabricator.wikimedia.org/T97283 -- 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 Interesting. I like a lot of this. I think perhaps you should define your target groups more clearly. You are using the phrase developer and third party developer to refer to different groups of people than I usually refer to with those words. Which is fine, i understood what you meant, but if there is the potential for different people to interpret those words differently, perhaps they should have stated definitions to avoid confusion. The types of developers section kind of confuses me. Is it saying that the wmf focus of mw api users has been labs users only? Because i think wmf has focused on a much broader section of api users than that. I think it might be a useful idea to expand this section into an enumeration of all the different type of tech people into broad classes, and document the sorts of things they work on, so we know who the target audiance of this project is. If there are tech people who are explicitly out of scope, i think it should be explicitly documented who is definitely not a target or who is tangently a target as time permits but id largely out of scope. Modern, simple-to-use, well-documented APIs are a prerequisite for success. Therefore, if we want to be successful at partnerships, distribution and user acquisition, we too must have multiple APIs that are modern and well-documented. I disagree with this statement. The key to success is apis that provide the required information in as easy to access way as possible. Modern is mostly in the eye of the beholder, and chasing after whatever is the most recent fad is not always best for our users (but sure, we dont want to be using some forgotten design paradigm from the 90s either). The number of apis is also fairly irrelevent, all that matters is if they fulfil the need properly. Simple to use is great, but depending on what the api is trying to achieve, sometimes flexibility and power is more important. We should be considering our apis like any other piece of software: who are the stakeholders, and what are they trying to achieve. From there all other considerations should flow. -- Bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Plan for a Developer Relations team
On Tue, Jun 30, 2015 at 1:25 AM, Pine W wiki.p...@gmail.com wrote: Hi Quim, A scope expansion for your team makes sense to me. I have two questions. 1. Does your team currently have the capacity for this scope expansion, with only existing staff, while continuing to support the existing Community Engineering mission? The Engineering Community team can do less of what has been doing if we collaborate better with other colleagues: Community Liaisons, Team Practices, Release Engineering, product owners, lead developers, the upcoming Community Tech team, WMDE's young TCB-Team... https://phabricator.wikimedia.org/T101116 And of course we can do less if we collaborate better with the developer community (example: GSoC / Outreachy / Google Code-in are running better every year, a main factor being the increasing quantity and quality of volunteer involvement). Then some tasks can take the change without much impact in total amount of work. For instance, organizing a developer summit in San Francisco including a track for web APIs targeted to developers from the SF Bay Area. So yes, we believe we have capacity to start this move and make some progress. How much, how quick, and how well will depend on several factors. We will do our best showing results with the resources we have, and only then requesting more resourcing via alignment of goals with other teams or growing our own capacity. 2. Will the team continue to have goals related to code review? More than ever, check the following quarters in our roadmap. https://phabricator.wikimedia.org/T101099 Without a proper code review process, this team is likely to fail in one of its measurements of success: Number of volunteer and third party developers contributing to our open source projects, and volume of their merged code contributions. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Plan for a Developer Relations team
Hi Quim, A scope expansion for your team makes sense to me. I have two questions. 1. Does your team currently have the capacity for this scope expansion, with only existing staff, while continuing to support the existing Community Engineering mission? 2. Will the team continue to have goals related to code review? Pine On Jun 29, 2015 2:01 PM, Quim Gil q...@wikimedia.org wrote: Hi, the Engineering Community team is working on a plan to evolve onto a Developer Relations team. This is not just a change of name. See * https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relations_team * Your feedback is welcome, in the wiki page or here. Related task: https://phabricator.wikimedia.org/T97283 -- 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
