Grants:Project/Rapid/Chlod/Contributor copyright investigation tool/Report

Template:Rapid Grant report/Final/approved

Goals

Did you meet your goals? Are you happy with how the project went?

The overall goal I wanted to have for this project was to make it easier to deal with copyright cases and problems on Wikipedia. With the release of the tool, I'm very proud to report that I've met this goal. Overall, I'm happy about how the project turned out, and I'm even happier that I'll get to ease the workload of Wikipedia's copyright cleanup editors. Although it was met with slight delays (particularly due to interference from my personal life that was not accounted for in the original proposal), I was still able to complete the script as originally conceptualized, and with additional features that I'd thought up during development.

Outcome

Please report on your original project targets. Please be sure to review and provide metrics required for Rapid Grants.

Target outcome	Achieved outcome	Explanation
Have made long-lasting tool that aids editors in dealing with copyright violations on-wiki	Done	This is perhaps the target with the most weight on the project. After a few months of development, I'm proud to have developed a working (and maintainable) tool for dealing with copyright cleanup in general. It's been named Deputy, from the rank "deputy inspector/investigator". Returning to the original target outcomes broken down per task, the following have been achieved, partially achieved, or not done: ✅ Improve and develop my existing Parsoid document handling library for browsers ✅ Create the initial CCI case handling components of the tool (see phab:M324 for mockups) ❌ Add the ability to deal with uploaded images (both on local wikis and on Wikimedia Commons) This functionality has been set aside for now pending my further reading into related policies. Each wiki can deal with image tagging differently and it can take more than the grant's execution duration to identify a possible whole-of-system approach that encompasses all processes of local wikis. ✅ Integrate my existing CopiedTemplateEditor (for modifying {{copied}} on Wikipedia) and InfringementAssistant (for quickly filing entries to Wikipedia:Copyright problems) scripts into the new tool ✅ Expand the CopiedTemplateEditor module to graphically edit other attribution templates (e.g., {{translated page}}, {{merged-to}}, {{merged-from}}) ✅ Expand the InfringementAssistant module to allow for more fine-tuned control over which sections need to be hidden with the {{copyvio}} template ✅ Improve the state of copyright workflow templates on Wikipedia Notable mentions: Template:Split article and Template:Backwards copy were successfully converted into Lua modules and now track improper usages of parameters. ❌ Add the ability to search a user's talk page for any copyright-related warnings and determine when and who gave the warning This duplicates the existing functionality of a script I maintain, RedWarn, and no part of the normal workflow can lead to usage of the tool, so this has been set aside for now. It may be worked on in the future when I add functionality to investigate copyright problems that occur outside the confines of a CCI/CP case. ✅ Add the ability to fine-tune the script's features by adding customization options (as I think editors best perform when given a tool that suits them, not when suiting themselves for a tool) ✳️ Develop an interactive guided to handling copyright problems, akin with the enwiki ACC Wizard, albeit integrated with the script and accessible as a popup or dialog on all pages (to be expanded upon after the grant end date) In the interest of avoiding the Dunning–Kruger effect, I've stopped myself from integrating this for now. I've decided to await further feedback from existing copyright editors on what might and will cause newer editors to mess up, and based on that improve the tool before creating a dedicated tutorial for it. ✳️ Expand the tool further based on requested features from tool users This is perpetually ongoing as the tool remains maintained. As of writing, all requests have been addressed. ❌ Prepare image copyright modules for standalone use on Wikimedia Commons Not possible without the prerequisite task "Add the ability to deal with uploaded images" ✳️ Consult different communities and identify ways to expand the script and support other wikis with copyright problems Cross-wiki consultation will require proficiency and a dedicated channel for accepting the feedback they provide. As such, I've decided to move this back to not long after the grant period, when I'm able to dedicate more time to the tool. ✅ Provide localization and internationalization options for the tool Deputy is i18n-ready and almost l10n-ready. The Attribution Notice Template Editor component is too specialized for the English Wikipedia, and further work on abstraction may be required before it can be used by wikis of other languages. Only English exists for now. I plan to contact translatewiki.org soon to discuss support for Deputy. ✳️ Gather feedback from users and identify potential points of improvement, including parts that can be made faster, more efficient, and built upon This is perpetually ongoing as the tool remains maintained. As of writing, the tool is open to feedback and will be developed according to user input. This tallies up to 12 goals completed — 4 for implementation/further action — and 3 not done or deferred to a late date pending certain prerequisites. I find these as acceptable given that this script is the first of its kind, and that a lot of the functionality and features have been developed and conceptualized from scratch. As originally promised, this script will see continuous development much further than the grant period, so none of these tasks are truly 'cancelled', merely shelved for a later time.
Have made a modular tool which can allow users to only load specific parts of the tool if they so wish (to optimize loading times)	Done	This is more of an optimization goal rather than an actual project goal, as is customary of most of my works (which I aim to be efficient and optimized). Two modules of Deputy can be executed without the need to load the Deputy script as a whole: the module for modifying or adding content attribution notices and the module for tagging and reporting pages to a copyright noticeboard.
Have invited more editors to contribute in the copyright cleanup field	To be determined	The interface provided by Deputy. As can be seen, it is very similar to the conceptualized design, and a much better improvement to the plain rendered wikitext. This can't be determined immediately since this is more of a lasting effect of the tool. However, I can assure that the tool contributes to this by decreasing the learning curve required to process cases, apply templates, etc. I'm hoping that the cleaner interface provided by Deputy on CCI pages will be more inviting for users who wish to partake in cleanup efforts.
Have helped in decreasing the amount of open cases and bringing the backlog to a continuous net negative in case count	To be determined	Like above, this can't be determined immediately, but was considered in development and will hopefully be attained in the future, given enough time.

Learning

Projects do not always go according to plan. Sharing what you learned can help you and others plan similar projects in the future. Help the movement learn from your experience by answering the following questions:

• What worked well?

  Prior to actual work on the script, I put a lot of time in conceptualizing designs and interfaces, seeing which one would "feel" most comfortable to a user. This includes drafting using Figma mock-ups, notebook pages, and numerous sticky notes (of which have already been sacrificed to the garbage can). All this planning ended up to be extremely useful: I had a set look and goal that I wanted to work towards, and thus the path for development was rather straightforward.

  

  Despite some gaps in the development period, I was able to get back on track with development with minimal relearning thanks to these drafts and with code comments. So in this case my advice for future Wikimedians wishing to embark on similar projects: plan ahead and plan well, as this will streamline things much better. Whenever in doubt, consult others (be it other Wikimedians, friends, perhaps family) on strategies and steps. There's also no shame in leaving things undefined so that they can be determined later — that's the joy of software development.

• What did not work so well?

  My strictness in following the plan ended up not working well, as personal circumstances caused a roadblock in the project. Midway through the grant period, my school required students to attend face-to-face classes (which, in the Philippines on May 2022, was still very limited) in order to attend graduation rites, causing me to lose access to my usual workspace (and subsequently, internet speeds) and be preoccupied on school-related matters. In addition, I had to deal with moving from a rural area to Metro Manila in preparation for my first year of college (early August 2022) and mental stress from all of these happening at once and personal relationships. These two delays ended up increasing my workload on times that I spent on development work.

  My advice for developers following this path: there are times when the timetable can get tilted a bit. There are also times when an extinction meteor comes straight for it. In either event, it's best to remain calm, assess the damage, and realign your plans. In this case, redoing the timetable I had around early June showed that the time I had left was too small for the remaining window. Because of this, I requested (and was graciously granted) an extension, in which I was able to do the remaining work.

• What would you do differently next time?

  For this grant which entailed the development of a tool with an original concept, I'd definitely decrease the amount of work I initially expected to take on. I had assumed that I would be able to complete all the tasks I initially listed in the grant proposal within just two months which, retrospectively, was a bad miscalculation on my part that ended up exhausting me out a bit. Even for MediaWiki features implemented by Wikimedia Foundation employees, software development takes time to perfect, and I should have considered that when deciding on the duration of the grant. Nevertheless, this didn't end up causing too much trouble, as the tool was still developed and completed within three months.

  Perhaps another idea for the future: do projects like these in pairs or groups, with the other person acting as a consultant or additional developer. Second opinions are important, especially when creating software that is expected to see frequent use from a specific demographic.

Finances

Grant funds spent

Please describe how much grant money you spent for approved expenses, and tell us what you spent it on.

US$2,000 for three months of software development work.

Remaining funds

Do you have any remaining grant funds?

There are no remaining grant funds.

Anything else

Anything else you want to share about your project?

Deputy is a modern take on userscripts, and therefore deviates from traditional userscript development. It is developed primarily with TypeScript, which makes debugging and compile-time error checking much easier, and uses Puppeteer+Jest for unit and integration testing. In a sense, this is less of a "pet project" and more of a serious technical project big on maintainability — a must-have for projects that take on big tasks, such as carrying much of the copyright cleanup workflow.

Deputy is not a gadget as of now and instead runs as a userscript since it is compiled to ES6, which MediaWiki does not yet support. Nevertheless, I'm very proud in what I've made and proud of the work and effort I've put into making it. I'll be continuing development of Deputy far past this grant's execution period in my capacity as a volunteer software developer, ensuring the longevity of the script.