Xqt closed this task as "Declined".
Xqt added a comment.
A reason to migrate to compat for this feature request. Page.fullVersionHistory() is deprecated. We now can use Page.revisions() instead at core branch.
TASK DETAIL
https://phabricator.wikimedia.org/T57261
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Xqt
Cc: Xqt, Legoktm, jayvdb, Ricordisamoa, Anshoe, pywikipedia-bugs
Qgil added a comment.
I removed the GSoC project and brought this task back to the Need Discussion column. I'm concerned about this project not having community backing, as it has been reflected in the various threads started in wikimedia-l, wikitech-l, and the discussion here. Even if these discussions are silent, they didn't end up with agreement. I'm concerned about a scenario where this project idea moves forward without that problem resolved, then one or more students start preparing proposals, and as the process goes by the discussion comes back, catching students and mentors by surprise, not ending up well. We had a couple of situations like these before, and as org admin I will do my best preventing such risk. In my opinion, no GSoC project is better than GSoC candidates losing a full round because of Wikimedia community disputes.
TASK DETAIL
https://phabricator.wikimedia.org/T89416
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Qgil
Cc: Halfak, NiharikaKohli, Evanontario, jayvdb, Qgil, Bawolff, Aklapper, Jsalsman, pywikipedia-bugs
jayvdb added a comment.
I have reopened https://phabricator.wikimedia.org/T89763 (explained there) but removed it as a the dependency for this project, as it seems that using the mediawiki-utilities package, instead of pywikibot, may be a better approach.
It seems the mediawiki-utilities package provides more of the functionality that will be needed for this project, and expecting the applicant to use both frameworks together (never done before, as far as I know) would very likely result in an unmaintained tool, and would require the applicant to learn two quite different frameworks, unnecessarily, sucking up quite a bit of their time meaning they may not complete the project.
To put this another way:
1. if the new tool was dependent on the mediawiki-utilities package, it is very likely that the code wont be accepted (merged) into pywikibot.
2. I strongly suspect that @Halfak is not interested in accepting pywikibot-using code into mediawiki-utilities, and
3. if the tool depends on mediawiki-utilities **and** pywikibot, and lives in its own repository, it will not see sufficient maintenance support from either the mediawiki-utilities or pywikibot development team.
While I have zero experience with mediawiki-utilities package, it doesnt look difficult and I could be a co-mentor anyway, but I'm still evaluating and trying to refine the project so that I feel it is suitable for the applicant and a useful project to mentor.
TASK DETAIL
https://phabricator.wikimedia.org/T89416
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb
Cc: Halfak, NiharikaKohli, Evanontario, jayvdb, Qgil, Bawolff, Aklapper, Jsalsman, Imaculate, pywikipedia-bugs