Re: [Wikitech-l] People with knowledge of English swear words needed :o
On Thu, Sep 19, 2013 at 11:19 AM, C. Scott Ananian canan...@wikimedia.org wrote: Perhaps we could use some Math here? Can we grab a list of the last, say, 100,000 edits reverted for vandalism, look at the diff, and compute a frequency score based on that? --scott I did something like that in JavaScript: https://github.com/he7d3r/mw-gadget-WordFrequencyOnRevertedEdits/ Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: New in Platform Engineering: James Douglas and Stas Malyshev
Hey, Welcome to James and Stas! Much of our infrastructure isn't that specific, so you'll hear us talking a lot over the next year about moving toward Service Oriented Architecture, which basically means taking our general purpose software and breaking it up into more focused components. \o/ Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Mon, Nov 17, 2014 at 11:03 AM, James Forrester jforres...@wikimedia.org wrote: Moving to character-level rather than paragraph-level diffing might help here, potentially. I vaguely remember that we attempted that and abandoned it because it caused more issues than it solved back in ?2004, though. A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean, then, that you only get a conflict if they change the same character? That sounds a bit excessive. (Stupid example: if I change sixty-three to sixty-five and someone else changes it to seventy-three, that should probably be a conflict, but a character-level diff would happily merge them into seventy-five.) A sentence-level diff would make much more sentence, except breaking text to sentences is a less trivial task than breaking it to paragraphs (lines). It is a very fundamental step in natural language processing though, so I am sure mature algorithms and tools exist for it, we just would have to research them. Another low-hanging fruit would be to special-case the situation when editor A adds text to the end of a section but does not start a new section, while editor B adds a new section to the same place. This is currently a conflict as they both try to insert to the same slot between paragraphs, so a generic merge tool cannot figure out whether those additions conflict and what would be the right order if they don't; however, knowing the semantics of wikitext, inserting the text from A first and the one from B after that seems a pretty safe bet. This kind of conflict is very typical on talk pages where people almost always edit the end of a section, and the few hot topic sections get the majority of the edits. (Of course, using unstructured wikitext for talk pages is a bad thing in general, but that's a long-term problem, and this kind of edit conflict could be prevented quickly.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Mon, Nov 17, 2014 at 3:11 PM, Bartosz Dziewoński matma@gmail.com wrote: I've always thought that the reason for the current ordering is so that people don't blindly press Save again and undo others' changes. Instead they blindly press Save again and lose their own changes. Arguably less bad but still bad. Anyway, the proper solution for this problem is autosaving article drafts. IIRC the Drafts extension https://www.mediawiki.org/wiki/Extension:Drafts is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a user testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far WRT editing improvements for non-newbies. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC meeting wikignoming (Re: RFC meeting this week)
On Mon, Nov 17, 2014 at 10:20 PM, Tim Starling tstarl...@wikimedia.org wrote: In the next RFC meeting we would like to discuss the following RFC: * Text extraction https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PST: Wednesday 13:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 Please note that the time has changed. It is an hour earlier so that it will be easier for people in Europe to attend. We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ ...and hope that some glitch hasn't wiped out the logs, since I don't think there are any service level expectations for those logs. I send this mail not to beat up on the Architecture Committee, but in the hopes that we can find some wikignome volunteers to help out. To the extent that it's not realistic to duplicate mailing list announcements to mediawiki.org, we should probably just say join wikitech-l to receive announcements on meeting timing, and generally, if we need to teach people how to fish rather than serving them beautifully-plated caviar, let's actually say we're doing that rather than setting up the expectation that they'll be able to wait for someone to post something on the wiki. Anyone willing to chip in? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On 20 November 2014 09:30, Gergo Tisza gti...@wikimedia.org wrote: On Mon, Nov 17, 2014 at 11:03 AM, James Forrester jforres...@wikimedia.org wrote: Moving to character-level rather than paragraph-level diffing might help here, potentially. I vaguely remember that we attempted that and abandoned it because it caused more issues than it solved back in ?2004, though. A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean, then, that you only get a conflict if they change the same character? That sounds a bit excessive. (Stupid example: if I change sixty-three to sixty-five and someone else changes it to seventy-three, that should probably be a conflict, but a character-level diff would happily merge them into seventy-five.) Sure, but wikitext paragraphs are significantly more extensive and diverse than the NLP concept; to give an example: Original wikitext: There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm]]. My changes: There are six [[*Alpaca fiber|*alpaca]] shearers on [[Sunningdale Acr*e*s|the farm]]. Their changes: There are six [[alpaca]] shearers on [[Sunningdale Acers|the farm*stead* ]]. Merging these two changes requires character-level merging (or something that natively understand wikitext at a subtle level. The first change would go through as a word-level diff (but not at sentence-level); the second wouldn't go through even then. Of course, we could prompt people to review the diff after saving if we're auto-merging, but that might be something we should be doing even now? Another low-hanging fruit would be to special-case the situation when editor A adds text to the end of a section but does not start a new section, while editor B adds a new section to the same place. This is currently a conflict as they both try to insert to the same slot between paragraphs, so a generic merge tool cannot figure out whether those additions conflict and what would be the right order if they don't; however, knowing the semantics of wikitext, inserting the text from A first and the one from B after that seems a pretty safe bet. This kind of conflict is very typical on talk pages where people almost always edit the end of a section, and the few hot topic sections get the majority of the edits. That seems like a sensible idea. Filed: https://bugzilla.wikimedia.org/show_bug.cgi?id=73667 (Of course, using unstructured wikitext for talk pages is a bad thing in general, but that's a long-term problem, and this kind of edit conflict could be prevented quickly.) Indeed! J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On 20 November 2014 09:33, Gergo Tisza gti...@wikimedia.org wrote: Anyway, the proper solution for this problem is autosaving article drafts. IIRC the Drafts extension https://www.mediawiki.org/wiki/Extension:Drafts is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a user testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far WRT editing improvements for non-newbies. No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
My wiki (zeldawiki.org) used to have such an extension to inform people when someone else was already editing the page. However, it was not compatible with newer versions of MediaWiki and was subsequently removed. I would like to voice my support for such features being integrated either into the MediaWiki core or into natively packaged extensions. Justin Folvarcik On Thu, Nov 20, 2014 at 2:00 PM, James Forrester jforres...@wikimedia.org wrote: On 20 November 2014 09:33, Gergo Tisza gti...@wikimedia.org wrote: Anyway, the proper solution for this problem is autosaving article drafts. IIRC the Drafts extension https://www.mediawiki.org/wiki/Extension:Drafts is basically ready but needs usability improvements, and development has stalled because when this was found out the Foundation did not have a user testing team yet; maybe James can tell if any further work is planned on that. As far as I can see, it would be the lowest hanging fruit by far WRT editing improvements for non-newbies. No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ 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] [Wikitext-l] Google Code-In 2014: Become a mentor and add tasks!
Just randomly going through the list of all the CS1 citation templates I found 2 with no template data out of the first 3 on the list i.e. https://en.wikipedia.org/wiki/Template:Cite_AV_media_notes I may make use of some of those at some point so I could probably mentor them. There are certainly lots of templates out there with no template data; it's potentially a huge task. I can't see saying to someone pick a few out of this list... https://en.wikipedia.org/wiki/Category:Template_documentation_pages Is there a list somewhere of commonly used templates we should make sure have TD? I found this but it doesn't seem very mature... https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Accessibility/Most_widely_used_templates/Top_200 On Thu, Nov 13, 2014 at 1:41 PM, James Forrester jforres...@wikimedia.org wrote: [Redirecting conversation about TemplateData to wikitech-l; wikitext-l is for parser and Parsoid discussion.] On 6 November 2014 22:56, Andre Klapper aklap...@wikimedia.org wrote: Could there be any Template(Data) related tasks that could be worked on by Google Code-In students? For example something like Fix five Templates from the list at by doing ? I'm happy to help setting up such tasks if somebody volunteers to mentor (more than one mentor means less work for everybody) and if somebody could add some boilerplate text at https://www.mediawiki.org/wiki/Google_Code-in_2014#Common_instructions_for_tasks It's possible, though writing TemplateData needs a reasonably strong grasp of the local community's expectations about template usage and all of the complexities that goes with that. CC'ed to Elitre and WhatamIdoing in case they might be interested in mentoring. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ 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 meeting wikignoming (Re: RFC meeting this week)
On Thu, Nov 20, 2014 at 10:57 AM, Rob Lanphier ro...@wikimedia.org wrote: On Mon, Nov 17, 2014 at 10:20 PM, Tim Starling tstarl...@wikimedia.org wrote: In the next RFC meeting we would like to discuss the following RFC: * Text extraction https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PST: Wednesday 13:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 Please note that the time has changed. It is an hour earlier so that it will be easier for people in Europe to attend. We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ ...and hope that some glitch hasn't wiped out the logs, since I don't think there are any service level expectations for those logs. I send this mail not to beat up on the Architecture Committee, but in the hopes that we can find some wikignome volunteers to help out. To the extent that it's not realistic to duplicate mailing list announcements to mediawiki.org, we should probably just say join wikitech-l to receive announcements on meeting timing, and generally, if we need to teach people how to fish rather than serving them beautifully-plated caviar, let's actually say we're doing that rather than setting up the expectation that they'll be able to wait for someone to post something on the wiki. Anyone willing to chip in? Rob See a few more comments/explanations/questions at https://phabricator.wikimedia.org/T1107 (Document on-wiki the Architecture RfC meetings from July onwards) from a few weeks ago. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC meeting wikignoming (Re: RFC meeting this week)
I have been creating tasks in Phabricator for the RfCs announced for a future meeting, and updating them posting the logs and any resolution. For instance, just updated: RfC: Text extraction https://phabricator.wikimedia.org/T1319 For the rest of open RfCs with Phabricator tasks, see https://phabricator.wikimedia.org/tag/mw-rfcs/ (a project that you can watch) Not perfect either, but better than it was a few weeks go. Also, Tim just started creating and handling tasks there as well. On Thu, Nov 20, 2014 at 9:48 PM, Nick Wilson (Quiddity) nwil...@wikimedia.org wrote: On Thu, Nov 20, 2014 at 10:57 AM, Rob Lanphier ro...@wikimedia.org wrote: On Mon, Nov 17, 2014 at 10:20 PM, Tim Starling tstarl...@wikimedia.org wrote: In the next RFC meeting we would like to discuss the following RFC: * Text extraction https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org at the following time: * UTC: Wednesday 21:00 * US PST: Wednesday 13:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 Please note that the time has changed. It is an hour earlier so that it will be easier for people in Europe to attend. We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ ...and hope that some glitch hasn't wiped out the logs, since I don't think there are any service level expectations for those logs. I send this mail not to beat up on the Architecture Committee, but in the hopes that we can find some wikignome volunteers to help out. To the extent that it's not realistic to duplicate mailing list announcements to mediawiki.org, we should probably just say join wikitech-l to receive announcements on meeting timing, and generally, if we need to teach people how to fish rather than serving them beautifully-plated caviar, let's actually say we're doing that rather than setting up the expectation that they'll be able to wait for someone to post something on the wiki. Anyone willing to chip in? Rob See a few more comments/explanations/questions at https://phabricator.wikimedia.org/T1107 (Document on-wiki the Architecture RfC meetings from July onwards) from a few weeks ago. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- 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] RFC meeting wikignoming (Re: RFC meeting this week)
On Thu, Nov 20, 2014 at 10:57 AM, Rob Lanphier ro...@wikimedia.org wrote: We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are [not] something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ https://en.wikipedia.org/wiki/Wikipedia:Be_bold :-) Collective responsibility requires collective action. The logs definitely should end up on mediawiki.org; I strongly agree that relying on tools.wmflabs.org is a bad idea. It looks like MeetBot is already generating wiki output, so having a bot post to the wiki would probably be a small task. I'd suggest filing a task. For a record of meetings, it looks like we already have a decent on-wiki index of past meetings and we can always iteratively improve that. No big deal. (This is another area where MeetBot might be able to help.) In addition to needing to be subscribed to this list in order to receive announcements about upcoming meetings, you also have to remember to attend the meeting during the day and you have to do so using IRC. I find setting an alarm on my phone and using webchat.freenode.net mitigate these obstacles well enough for me. Is it perfect? No, but c'est la vie. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC meeting wikignoming (Re: RFC meeting this week)
What channel are the meetings held in? On Thursday, November 20, 2014, MZMcBride z...@mzmcbride.com wrote: On Thu, Nov 20, 2014 at 10:57 AM, Rob Lanphier ro...@wikimedia.org javascript:; wrote: We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are [not] something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ https://en.wikipedia.org/wiki/Wikipedia:Be_bold :-) Collective responsibility requires collective action. The logs definitely should end up on mediawiki.org; I strongly agree that relying on tools.wmflabs.org is a bad idea. It looks like MeetBot is already generating wiki output, so having a bot post to the wiki would probably be a small task. I'd suggest filing a task. For a record of meetings, it looks like we already have a decent on-wiki index of past meetings and we can always iteratively improve that. No big deal. (This is another area where MeetBot might be able to help.) In addition to needing to be subscribed to this list in order to receive announcements about upcoming meetings, you also have to remember to attend the meeting during the day and you have to do so using IRC. I find setting an alarm on my phone and using webchat.freenode.net mitigate these obstacles well enough for me. Is it perfect? No, but c'est la vie. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC meeting wikignoming (Re: RFC meeting this week)
https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079285.html The meeting will be on the IRC channel #wikimedia-office on irc.freenode.org [...] On Fri, 21 Nov 2014, at 09:53, John wrote: What channel are the meetings held in? On Thursday, November 20, 2014, MZMcBride z...@mzmcbride.com wrote: On Thu, Nov 20, 2014 at 10:57 AM, Rob Lanphier ro...@wikimedia.org javascript:; wrote: We (collectively) need to get a lot better about not merely signaling what is coming up, but what the results of these decisions are. If you look here: https://www.mediawiki.org/wiki/Architecture_meetings ...you could be forgiven for thinking the RFC meetings are [not] something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ https://en.wikipedia.org/wiki/Wikipedia:Be_bold :-) Collective responsibility requires collective action. The logs definitely should end up on mediawiki.org; I strongly agree that relying on tools.wmflabs.org is a bad idea. It looks like MeetBot is already generating wiki output, so having a bot post to the wiki would probably be a small task. I'd suggest filing a task. For a record of meetings, it looks like we already have a decent on-wiki index of past meetings and we can always iteratively improve that. No big deal. (This is another area where MeetBot might be able to help.) In addition to needing to be subscribed to this list in order to receive announcements about upcoming meetings, you also have to remember to attend the meeting during the day and you have to do so using IRC. I find setting an alarm on my phone and using webchat.freenode.net mitigate these obstacles well enough for me. Is it perfect? No, but c'est la vie. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC meeting wikignoming (Re: RFC meeting this week)
Le 20/11/2014 19:57, Rob Lanphier a écrit : ...you could be forgiven for thinking the RFC meetings are something we do anymore. Basically, you have to be subscribed to this mailing list, and then, if you miss the time, fish through the logs here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/ Since we are using meetbot, I guess at the end of the meeting the meeting leader can: * copy paste the .wiki file generated by meetbot on the wiki * reply to the announcement email with: - a short summary of the session - link to the new wiki page - the meetboot html summary and log pages Example: http://lists.openstack.org/pipermail/openstack-infra/2014-November/002117.html That will be a good improvement. I would love wikignomes to automate the process of uploading the .wiki page on the wiki and updating the summary page on [[RFC]]. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla-Phabricator migration: 21 Nov at 00:30 UTC
Alea Jacta Est. We are ready to start the migration at 00:30 UTC, in less than one hour. If you have precious information in Phabricator that you need during the weekend, save copies now. We will keep Bugzilla in read-only mode as long as this doesn't disturb the perforance of the migration. Remember, in case of emergency (a bug report that cannot wait until Monday), use #wikimedia-bug2phab on IRC and mediawiki.org's Support Desk. For the rest, check https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla On Wed, Nov 19, 2014 at 8:00 PM, Quim Gil q...@wikimedia.org wrote: We are polishing the last details before starting the Bugzilla migration to Phabricator on 21 November at 00:30 UTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141121T0030 You can find all the details of what will happen next in the timeline at https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla MIGRATION WEEKEND Basically, Bugzilla access will be restricted to read-only, Phabricator will be pulled, and we will start the migration. If all goes well, by Monday 24 Phabricator will be back with about 75k tasks, and Bugzilla will be archived in old-bugzilla.wikimedia.org. During this period, we will redirect users to a page asking them to postpone their bug reporting unless it is so urgent that it cannot wait until Monday. In that case, they can use #wikimedia-bug2phab on IRC and mediawiki.org's Support Desk. If you registered in https://phabricator.wikimedia.org before the migration, your Bugzilla activity will be probably assigned to you by the time you check the site. Otherwise, you will still be able to register and claim your activity, which will be assigned to you within a couple of hours or a couple of days, depending of the queue. KNOWN ISSUES We are confident about the stability of Phabricator and also about the reliability of the migration process. However, there are several known issues related with data and features that will be missing next Monday. We cannot assign to Phabricator tasks the same number as their Bugzilla equivalents. Instead, automatic redirects will link old Bugzilla URLs with their corresponding new Phabricator tasks. phabricator.wikimedia.org has already 1300 tasks with numbers taken. The migration needs to be done by batches of bugs instead of sequentially, which makes the mapping of numbers more complicated. Still, smaller numbers will correspond to older bugs, and we will do our best during the weekend to improve the sorting. Votes and saved searches cannot be migrated. Users willing to have their equivalent in Phabricator (tokens a new saved searches) will be able to access their accounts in old-bugzilla. A feature that we expect to be missed is suggestions for duplicates when creating a new task. Even if Phabricator's search is powered by Elasticsearch, we feel like it needs some fine-tuning to get to Bugzilla's efficiency. Advanced Bugzilla users will also find that some actions take more clicks (assigning blocker/blocking tasks, for instance). In general, most fluent Bugzilla users new to Phabricator will need a few days to get used to how things work in Phabricator. There is a complete list of known issues at https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Known_issues -- and we will keep working on them after next Monday. IMPROVEMENTS We expect that the improvements will make the change worth right after the migration, of course. A simpler and cleaner UI that works on mobile, Wikimedia SUL, bugs and features living together, ability to associate tasks to several projects, workboards, and many more features are waiting for you! :) -- 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
