Change Details

Some of the possible action items I can see us working on during the #WMDE-QWERTY-X-Mas-Sprint-2018-12-18: [] The wikitext cleanup is currently done in ApiDetailRetriever::getImportDetails(). It's heavily misplaced there. The feature either needs to be split off to a separate service, and run later, **outside** of the "retriever". We might need to change the generic approach represented by the DetailRetriever interface to be able to do that, or introduce a new interface for a "cleanup" step that does nothing by default. Another idea is to simply **rename** the existing classes and methods to reflect what they actually do. [] While the average test coverage is superb (>80%, see https://doc.wikimedia.org/cover-extensions/FileImporter/), some of the most essential code is uncovered. * Most notably ApiDetailRetriever, see https://doc.wikimedia.org/cover-extensions/FileImporter/Remote/MediaWiki/ApiDetailRetriever.php.html. * More at https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html [] It might be worth copying the SpecialPageHtmlFragment class from #two-column-edit-conflict-merge, and apply it to most, if not all of the classes in the FileImporter\Html namespace that implement a getHtml method. [] … Please extend as needed.

Some of the possible action items I can see us working on during the #WMDE-QWERTY-X-Mas-Sprint-2018-12-18: [] The wikitext cleanup is currently done in ApiDetailRetriever::getImportDetails(). It's heavily misplaced there. The feature either needs to be split off to a separate service, and run later, **outside** of the "retriever". We might need to change the generic approach represented by the DetailRetriever interface to be able to do that, or introduce a new interface for a "cleanup" step that does nothing by default. Another idea is to simply **rename** the existing classes and methods to reflect what they actually do. [] While the average test coverage is superb (>80%, see https://doc.wikimedia.org/cover-extensions/FileImporter/), some of the most essential code is uncovered. * Most notably ApiDetailRetriever, see https://doc.wikimedia.org/cover-extensions/FileImporter/Remote/MediaWiki/ApiDetailRetriever.php.html. * More at https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html [x] It might be worth copying the SpecialPageHtmlFragment class from #two-column-edit-conflict-merge, and apply it to most, if not all of the classes in the FileImporter\Html namespace that implement a getHtml method. [] … Please extend as needed.

Some of the possible action items I can see us working on during the #WMDE-QWERTY-X-Mas-Sprint-2018-12-18: [] The wikitext cleanup is currently done in ApiDetailRetriever::getImportDetails(). It's heavily misplaced there. The feature either needs to be split off to a separate service, and run later, **outside** of the "retriever". We might need to change the generic approach represented by the DetailRetriever interface to be able to do that, or introduce a new interface for a "cleanup" step that does nothing by default. Another idea is to simply **rename** the existing classes and methods to reflect what they actually do. [] While the average test coverage is superb (>80%, see https://doc.wikimedia.org/cover-extensions/FileImporter/), some of the most essential code is uncovered. * Most notably ApiDetailRetriever, see https://doc.wikimedia.org/cover-extensions/FileImporter/Remote/MediaWiki/ApiDetailRetriever.php.html. * More at https://doc.wikimedia.org/cover-extensions/FileImporter/dashboard.html [x] It might be worth copying the SpecialPageHtmlFragment class from #two-column-edit-conflict-merge, and apply it to most, if not all of the classes in the FileImporter\Html namespace that implement a getHtml method. [] … Please extend as needed.