Grants talk:Project/DannyS712/Create a global watchlist extension

Input from WMF Community Tech and WMF Contributors?

Hi User:DannyS712,

Thank you for submitting this proposal! Reading "Rather than trying to create a new database table for a global watchlist, my script relies on querying the watchlist on each of the wikis a user has chosen via the api", I was wondering if you already had any conversations with people who have worked on the MediaWiki Watchlist (probably mw:Contributors and Community Tech)? Asking as Community Tech investigated cross-wiki watchlists in phab:T5525 and its subtasks (plus only for the records, there is phab:tag/mediawiki-crosswikiwatchlist/ which I'm not sure is really used by anyone). If so, can you share anything about those conversations? It would be great to see people involved with this software area engaging directly on this talkpage so we can hear their thoughts.

Thanks in advance for any feedback! --AKlapper (WMF) (talk) 23:22, 25 January 2020 (UTC)

I had some discussions over IRC, but can't post the logs. As far as I can tell, Community Tech abandoned this. I was hoping for some feedback from the teams here --DannyS712 (talk) 23:25, 25 January 2020 (UTC)

I second that. We had a discussion with a community tech software engineer User:MusikAnimal (WMF), it was apparently dropped due to performance reasons. Masum Reza^📞 08:22, 26 January 2020 (UTC)

Sorry, as I said on IRC, I'm not really the best contact for this. Community Tech dropped it due to performance reasons and simply that it was a massive project that our tiny team couldn't take on in a reasonable amount of time. Frankly, it seems we didn't really capture the challenges we faced very well, and for that I apologize :( Pinging @Ryan Kaldari (WMF): who might be able to shed more light on where we left off. MusikAnimal (WMF) (talk) 21:24, 28 January 2020 (UTC)

It's been a while since we looked at this (4 years?), but my recollection was that scalability was the main roadblock. We discussed some ideas with the database administrators, and came up with a basic plan for a prototype (which required creating some new global tables). Because Community Tech had so many other projects to tackle, we just never had the time to follow through on the project. If there weren't already scalability problems with the existing watchlist system, I think it would be fine to proceed with the plan proposed here. However, it sounds like this might be the straw that broke the camel's back, as our watchlist queries are already pushing things to the breaking point, from what I understand. Of course things could have changed since 2016, so I would defer to JCrespo on this. Ryan Kaldari (WMF) (talk) 22:42, 29 January 2020 (UTC)

I haven't reviewed the script yet, but for the cross-wiki notifications project we also made requests over the API to multiple wikis, and it worked rather well (I was surprised at how well it worked tbh). We kept a shared database table that indicated which wikis needed to be contacted over the API, something that shouldn't be too hard to implement performance wise if that approach is considered. Legoktm (talk) 19:56, 29 January 2020 (UTC)

I, on the other side, don't see this working to WMF wiki sizes (in the proposed manner). We already have large performance issues with wikis with high edit rate (like Wikidata) or users/bots with high edit count on a single Wiki- I don't see this working except on trivial cases of "querying 2 or 3 small wikis for a small contributor". Please note I am not saying doing this is not possible -both Sean and and me suggested the right way to scale this is to create a global watchlist table and query that, first as a replicated prototype, and later as a replacement of the local mechanism. Aggregating recentchanges and watchlists of all users is a relatively easy project that requires little functional code (just overloading replication), and just focus on UI and querying code.

However, I don't have a strong opposition (in fact, I would be happy to support) to a smaller scale, proof-of-concept of any method, including the suggested, where the UI would be reusable and as long as the scope was limited- rather than no one working on this. I just would like to set expectations for a "proper" scalable solution (bot with millions of edits over 300 wikis) taking way more than 250 person-hours when we already have watchlist scaling issues in the current state (requires refactoring). -- JCrespo (WMF) (talk) 20:49, 29 January 2020 (UTC)

I think it depends on the scale of cross-wiki (in my own personal use case, I only have 4 watchlists that I want to see at once), which leads to your point (that I agree with) about setting the proper expectations about whether this is supposed to be a small scale/PoC or cover literally everyone's use cases. Legoktm (talk) 23:04, 29 January 2020 (UTC)

Thanks, Legoktm, you understood my point. Seeing this working for "regular" (vs high edit rate) users on 4 wikis or consider it a PoC would be a more reasonable initial approach and/or starting working on UI and or backend configuration. Also with this approach, being very conservative and having into mind rate limits, parallelism and timeouts- last thing I want is a script doing 900 fully-parallel, 60-second queries to the api servers on every page load. --JCrespo (WMF) (talk) 11:55, 30 January 2020 (UTC)

If needed, I can introduce a limit (eg only query 10 wikis at most) and convert it to be in series, or in groups (eg only query up to 3 wikis at a time) --DannyS712 (talk) 16:25, 30 January 2020 (UTC)

That would be less risky from a scalability point of view. Ryan Kaldari (WMF) (talk) 20:40, 31 January 2020 (UTC)

Scope of project

To clarify, is the idea that this is basically going to port the existing JS to an extension, and make minimal changes (i.e. Translations using normal MW i18n, preferences be user prefs), or is the plan to do more extensive changes to the script to take advantage of being an extension? 250 hours kind of seems like a lot of hours if its just taking the existing extension and putting the JS into an extension with minimal changes to the JS (but reasonable if the porting process involves more extensive changes to the script). Personally I'd like to see the project goals broken down into smaller milestones so it has more of a timeline of when specific parts should be done by, so it is easier to tell if the project is on track as it progresses. (I say this about pretty much every single technical grant proposal I read, so that concern is not unique to this grant proposal. Bawolff (talk) 05:15, 1 February 2020 (UTC)

I gave some more info in the "Activities" section, but its not just running the js. In total, it'll include, at least:

• Storing user preferences as an option

• Adding a handler for the DeleteUnknownPreferences hook to ensure the preference isn't removed

• Consider replacing the addPortletLink with a handler for the PersonalUrls hook
• Migrating to proper translations
• Migrating to proper testing
• Replacing the secondary fake special page for settings with either a new FormSpecialPage or a global preferences option (not very familiar with global preferences, have a bit of experience creating special pages, so probably the former)
• Attempt to increase features available (eg size different, patrol marks, pending changes status)

This is going to be a lot more than just porting the javascript, since extensions have more possibilities than scripts. --DannyS712 (talk) 08:14, 2 February 2020 (UTC)

Writing the code for all of the above still takes significantly less than 250 hours (~1.5 man-month), IMO. That's not necessarily a problem, budgeting for more time than needed and paying the unused funds back at the end of the project is a lot better than the opposite; and there is always some level of uncertainty around code deployed in Wikimedia production (e.g. performance review might result in a need for significant changes). On that note, I think it would be nice to include a certain amount of post-deployment availability in the budget - if the extension is deployed and the project is considered done, but then two weeks later it turns out it is causing problems, it is good if the author is still available. --Tgr (talk) 01:06, 10 February 2020 (UTC)

I haven't written an extension from scratch before, so I'm not sure how long it will take, especially since in the end most of the work should be done in php rather than javascript, but it may take less than the allotted time. I will be available for post-deployment support. If there are extra funds at the end, I will of course return the leftover money. --DannyS712 (talk) 16:40, 7 April 2020 (UTC)

And yes, performance review may require some changes, per the discussion above about how currently an unlimited number of sites are queried in parallel, rather than in series / with a limit on the number of sites. --DannyS712 (talk) 16:42, 7 April 2020 (UTC)

Code review requires 2 people

I'm always excited to see grant proposals for MediaWiki development, and would like to see this one succeed. One thing that I noticed was that in general, MediaWiki wants peer code review, which requires at minimum 2 people (ideally more). One person to write the code (presumably you), and another person to review it. Do you have any commitments from a second person to review your code? Legoktm (talk) 23:06, 29 January 2020 (UTC)

@Legoktm: I believe he currently does not have such commitments from a second person. At least phab:T234507 says so. He is planning to submit it to w:en:Wikipedia:Code_review and/or ask mediawiki JS scripts creators personally. But not sure if we can find anyone since WP:Code review is not much active these days. But we could surely use some help of you, if you are interested. Masum Reza^📞 00:09, 30 January 2020 (UTC)

There is no current code review, but this is not currently an extension. The scope of this grant request is, at a minimum, to create a working extension. Extensions are hosted on gerrit, and +2 would be available to all developers that have +2 for mediawiki/*. Before the extension is deployed, there is no (as far as I am aware) requirement for review. I have no such commitments from any individual, but have a few in mind (eg Masumrezarock100, though not a developer per se (as far as I know), is quite familiar with the code in its current form). Thanks, --DannyS712 (talk) 00:26, 30 January 2020 (UTC)

Pre-deployment code review is not necessary (although a good practice). On the other hand, all that review will probably still have to happen during deployment, possibly as part of the security or performance review, so it might be worth to reach out to the teams who would be doing that. --Tgr (talk) 01:13, 10 February 2020 (UTC)

I definitely think having someone to do CR with you would reduce the risk for this project significantly. Having pre-deployment review from WMF staff at end is really risky, because if something is wrong and you have to go back and fix it, that might mean a lot of wasted work. Bawolff (talk) 07:37, 2 March 2020 (UTC)

I plan to request some review of the current javascript version once I rewrite some of it (including trying to address the issue you raised earlier). --DannyS712 (talk) 18:16, 2 March 2020 (UTC)

I looked into requesting a security review for the current javascript, but per mw:Security/SOP/Security Readiness Reviews "Any user-JavaScript or Gadgets which may run on various Wikimedia wikis" is not in the scope of security readiness reviews. @Bawolff: any chance you'd be willing to review the javascript separate from the standard security readiness review process? I addressed the security flaw you emailed me about a while ago --DannyS712 (talk) 16:50, 7 April 2020 (UTC)

Note, i don't work on the security team anymore. From what i remember, the main issue was substituting values into html-ready text instead of escaping text as the very last step. I don't remember their being other issues but its been a little while. Given the intention is to use this as a base for a mw extension, maybe the sec team can do a concept review or something (ping user:SBassett (WMF) or maybe User:JCross (WMF)). Especially if the grant is accepted and the expected end product is not a gadget but an extension, I would encourage you to have an early informal conversation with the security team just to see how they feel about the eventual review and if there is any early guidance they can give. Bawolff (talk) 06:27, 13 April 2020 (UTC) [to be extra clear, speaking only for myself, i am no longer affiliated with WMF]

@DannyS712: - The Security Team can perform a security readiness review for this, though it would likely be lower-priority. Feel free to submit the request form when you have code that is ready to go (i.e. there is a commit sha we can use as a stopping-point for the review, a working test environment of some variety even if just on-wiki, etc.) SBassett (WMF) (talk)

@SBassett (WMF): will the security team perform a review of the code while it is still just a javascript user script (as opposed to an extension)? --DannyS712 (talk) 21:07, 14 April 2020 (UTC)

@DannyS712: yes, at the very least we can perform a more lightweight review, e.g. something like phab:T227221 SBassett (WMF) (talk) 03:06, 15 April 2020 (UTC)

Okay. I'll finalized the next version and then submit a task soon --DannyS712 (talk) 03:09, 15 April 2020 (UTC)

Though I'm under the assumption, based upon above conversations, that an extension isn't likely to be developed/deployed for some time. If that's not the case, and the extension is likely to arrive much sooner, then it makes sense to just wait until that is completed and schedule a review. SBassett (WMF) (talk) 03:13, 15 April 2020 (UTC)

Its unknown how long it would take to develop the extension (or if the grant is even approved) so I would indeed like to have a javascript review. --DannyS712 (talk) 00:23, 16 April 2020 (UTC)

@SBassett (WMF): I've filed phab:T250640 --DannyS712 (talk) 00:56, 20 April 2020 (UTC)

Budget

Hi, thanks for sharing us your proposal. After read your proposal I have a question about the item Computer equipment needed in the budget section, Can you explain us about which elements are included in this item?. Kindly Superzerocool (talk) 14:18, 3 February 2020 (UTC)

My computer isn't powerful enough to write a new extension effectively; its too slow to be economical for such a large project --DannyS712 (talk) 16:16, 3 February 2020 (UTC)

Extension cs tool

Bawolff said on the grant page: Converting popular gadgets/user scripts into extensions is a direction I think we should support for a variety of reasons. I'm less convinced about that. Gadgets are a very restrictive framework and complex, popular gadgets should certainly be converted into something better; but converting them into a Toolforge tool means security and performance is easier to manage, which in turn means less review overhead and easier to find collaborators. On the other hand, the framework is less mature (e.g. I don't think we have a great i18n or API library) in discoverability is not very good, so I'm not sure if that's a good trade-off today, but in general it seems to me like the better long-term direction for power user tools. (FWIW, there is already a cross-wiki watchlist tool, Crosswatch; currently broken - see relevant wishlist entry). --Tgr (talk) 01:22, 10 February 2020 (UTC)

@DannyS712: you might want to comment. Masum Reza^📞 01:22, 15 February 2020 (UTC)

I'm afraid I don't particularly understand the comment above - are you saying that this should be a toolforge tool instead? I know almost nothing about how to create and develop a tool, while I have quite a bit of experience with the mediawiki codebase and its extensions. --DannyS712 (talk) 01:28, 15 February 2020 (UTC)

Since I've been asked on the grant endorsement page to explain my reasoning by User:TradeCrawlspaces, I guess here is as good a place as any. Toolforge tools have no quality of service or uptime expectations. They are in practice (albeit in theory not necessarily) usually maintained at the whim of a single maintainer. They are also definitionally external and require going off-site (A bad user experience for a core workflow imo). In many cases, there is no shared understanding how important various toolforge/cloud stuff is, confounded by the fact that Cloud services is a mix of trivially unimportant junk with what is in essence (but not name) production critical code for the Wikimedia projects, which in my mind is a very undervalued risk to the movement, but perhaps that is off-topic to this discussion. In any case, my personal belief is that things that make up common workflows, or workflows that are core to using a wiki, should be built into the MediaWiki paltform, either directly or as extensions and I think "watchlists" qualify as that. Bawolff (talk) 08:16, 17 February 2020 (UTC)

A few questions

I have several questions about the proposal:

1. What is the duration of the project?
2. Where will global watchlist be located? Will it be accessible from any wiki? Or one will need to go to a central wiki to use it?

Ruslik (talk) 20:46, 18 February 2020 (UTC)

It will be available at Special:GlobalWatchlist (eventually; for now its at Special:BlankPage/GlobalWatchlist) and will work from any SUL wiki. The duration of the project is around a year (250 hours in total). --DannyS712 (talk) 20:51, 18 February 2020 (UTC)

Eligibility confirmed, Round 1 2020

This Project Grants proposal is under review!

We've confirmed your proposal is eligible for Round 2 2020 review. Please feel free to ask questions and make changes to this proposal as discussions continue during the community comments period, through March 16, 2020.

The Project Grant committee's formal review for round 1 2020 will occur March 17 - April 8, 2020. We ask that you refrain from making changes to your proposal during the committee review period, so we can be sure that all committee members are seeing the same version of the proposal. Grantees will be announced Friday, May 15, 2020. Any changes to the review calendar will be posted on the Round 1 2020 schedule.

Questions? Contact us at projectgrants wikimedia  · org.

I JethroBT (WMF) (talk) 20:28, 5 March 2020 (UTC)

Question about the "problem you're trying to solve"

I am wondering if you can speak more about what problem exists that you hope this initiative will solve. I am not especially technical, but right now do not really understand what the problem is that requires this proposed solution, especially if there were efforts in this area previously that were abandoned. Thanks in advance. --FULBERT (talk) 21:18, 7 March 2020 (UTC)

Some users are active on more than one wiki and it's a hassle to have to check several watchlists at once. Jo-Jo Eumerus (talk, contributions) 08:43, 8 March 2020 (UTC)

Thank you for your reply Jo-Jo Eumerus. To make sure I understand, the problem is that it takes too much time in the current set of processes, or that it may be easy to miss things as there are many too many steps involved. Is this what you mean? Thanks again. Pinging DannyS712 as well. --- FULBERT (talk) 13:42, 8 March 2020 (UTC)

@FULBERT: In my experience if you're contributing on/following 1)enwiki, 2)commons, 3)meta, 4)mediawiki, 5)one or two non-English wikis, 6)last week you've helped out an admin on a language wiki you've never heard of before, the difficulties quickly arise: 1)have to navigate to each wiki (many bookmarks) 2)might easily miss one 3)the process is cumbersome and time-consuming. —AronM🍂 edits🌾 11:47, 6 April 2020 (UTC)

Sorry for missing this; yes, the problem is that its hard to keep track of all of the wikis one wants to watch. The previous efforts focused on a very different approach (a global watchlist serverside, as opposed to using the api clientside) --DannyS712 (talk) 05:52, 3 April 2020 (UTC)

Aggregated feedback from the committee for Create a global watchlist extension

Scoring rubric	Score
(A) Impact potential Does it have the potential to increase gender diversity in Wikimedia projects, either in terms of content, contributors, or both? Does it have the potential for online impact? Can it be sustained, scaled, or adapted elsewhere after the grant ends?	6.6
(B) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support?	6.2
(C) Ability to execute Can the scope be accomplished in the proposed timeframe? Is the budget realistic/efficient ? Do the participants have the necessary skills/experience?	6.6
(D) Measures of success Are there both quantitative and qualitative measures of success? Are they realistic? Can they be measured?	6.0
Additional comments from the Committee: This is a clear lost-function after CentralUser activation in all Wikimedia projects. This tool is not the most demanded feature for Wikimedia wikis, but it helps to everyone who edits in more than 1 project in Wikikimedia. If it works, it could be beneficial for everyone. In line with idea of contributing to multiple chapters of Wikimedia projects and will help to make them less vandalized (when used by SWMT) or more cared about. I have some concerns about sustainability due to the lack of other contributors or lack of interest from WMF tech team but I think having an extension will be more sustainable than having just a JS script like we do now. This is a long-standing idea that actually has been around for quite some years and Community Tech has been unable to tackle due to several reasons. Small size but active community members would benefit from this "addon". There are concerns about scalability in addition to large performance issues with wikis with high edit rates. Rather than working on all Wikimedia wikis, the grantee could consider working with 4 or 5 wikis for a start. Required a lot for people doing cross-patrolling. The grantee has an idea of thinking of schedule before starting but I still see some risks here as it will need to be integrated into the core of WMF-supported wikis. This project involves significant risks as it could lead to a non-feasible gadget and end up in just a prof of concept, for example because some operations would require high performance thus hurting the final deployment of the tool, also because grantee does not have a peer-review system set up in advance of developing the project. The grantee could consider working with 4 or 5 wikis for a start to minimize the risk that may be associated with performance issues on wikis with a high edit rate. The grantee has the sufficient capacity to end the project. The budget seems in the limits to be paid, but there is a few gray zones about the equipment. Here I have some concerns because it seems to me that it requires a support from WMF tech team. He is the author of the similar JS script and time allocated seems reasonable. I see some risks as grantee has no experience working with extension and lack of experienced reviewers to work with as WMF isn’t dedicated to this project. As this project has been already in study inside the WMF and seen as unfeasible for the moment this could be a hint that this project actually would require many more hours than stated. Also all the work-hours are considered the same and are not divided for important tasks other than code writing such as bug hunt, documentation, testing and so on. I think the grantee budgeted for more time than needed. The project has support from CVN and SWMT because the project is helping them to maintain the small wikis clean. I see support from the community. This project enjoys much support as it has been demanded by the community for a long time. However, if the tool ends up succeeding it would require further promotion inside communities other than the actual stated. There are supports from a handful of users but since the project targets all Wikimedia wikis, I think it should be announced on all Wikimedia wikis community portals/Village pump or other relevant notice board. There is a benefit and a prototype would be welcome. Concerning risks are present at the moment. I'd recommend funding for this project only if grantee agrees to do this project in a small scale. Maybe start with 4 or 5 Wikimedia Wikis for a start.

This proposal has been recommended for due diligence review.

The Project Grants Committee has conducted a preliminary assessment of your proposal and recommended it for due diligence review. This means that a majority of the committee reviewers favorably assessed this proposal and have requested further investigation by Wikimedia Foundation staff.

Next steps:

• Aggregated committee comments from the committee are posted above. Note that these comments may vary, or even contradict each other, since they reflect the conclusions of multiple individual committee members who independently reviewed this proposal.
• If you have had an interview with a Program Officer, you may have orally responded to some of the committee comments already. Your interview comments will be relayed to the committee during the deliberations call.
• You are welcome to respond to aggregated comments here on the talkpage to publicly share any feedback, clarifications or questions you have.
• Following due diligence review, a final funding decision will be announced on May 29, 2020.

If you have any questions, please contact us at projectgrants wikimedia  · org.

--Marti (WMF) (talk) 22:11, 13 May 2020 (UTC)

Some of the feedback was regarding limiting the number of sites at first. I'm afraid I don't exactly understand what the desire here is - limit the number of sites a user can include in their watchlist? Limit the specific sites that can be included to a select few? --DannyS712 (talk) 23:42, 13 May 2020 (UTC)

@DannyS712: Thanks for your request for clarification here. These comments reflects feedback from technical that staff that a global watchlist extension that permits users to include as many wikis as they choose is too resource intensive, and that such a limit is necessary in order for this proposed extension to be technically viable. As I understand it, the limit is more about the number of Wikimedia projects that a user can actively monitor in their global watchlist, not the total number they can potentially choose from. Does this address your question? I JethroBT (WMF) (talk) 21:56, 15 May 2020 (UTC)

Yes. The initial version can include a limit of 4 or 5 watchlists shown (though there is no such limit currently with the script version) - perhaps down the line we can consider switching it to 4 or 5 wikis fetched at a time, but more allowed in series. Thanks for explaining --DannyS712 (talk) 21:58, 15 May 2020 (UTC)

Performance concerns

It isn't well documented (sorry), but there is a "fast mode" that makes the watchlist a little more basic, with the benefit of improving performance: rather than querying with the wlallrev parameter, ensuring that information about all of the edits is shown, only the underlying list of pages with edits to them is retrieved, removing the processing of the entries, combining of edits to the same page, querying and rendering of tags, etc. Perhaps this should be renamed to "basic" mode and made available as a per-site option, so that for sites with higher edit rates (eg wikidata or enwiki) the performance impact is reduced. --DannyS712 (talk) 06:01, 18 May 2020 (UTC)

Round 1 2020 decision

Congratulations! Your proposal has been selected for a Project Grant.

The committee has recommended this proposal and WMF has approved funding for the full amount of your request, US$11,000

Comments regarding this decision:
The committee is pleased to support this widely desired tool to support multiple wiki watchlists. The committee’s award is contingent up on following the recommendations provided by Wikimedia Foundation software development staff, including the following:

• A technical advisor should be assigned to help throughout the life of the project (deployment, consideration of scalability, performance, etc.)
• The extension should only be deployed on a limited number of wikis (not all wikis). Ten wikis has been suggested as the limit, but this can be finalized through further consultation with Wikimedia Foundation staff.
• Extension must go through proper security and performance review, with expectation that review may result in a "no go" (plan for analysis of the work ahead of time to avoid this).
• Include tracking/metric count measuring how many people are using the script at some set time interval.

• Allow time for post-deployment support so bugs can be fixed to make sure extension is sustainable.

• Find a second person to assist with code review as a best practice.

• The extension should only be available on Meta.

• Wikis used should be all opt-in (eg. by default you would only see your Meta watchlist). The current userscript has 4 default wikis and that's too many.

Next steps:

1. You will be contacted to sign a grant agreement and setup a monthly check-in schedule.
2. Review the information for grantees.
3. Use the new buttons on your original proposal to create your project pages.
4. Start work on your project!

Upcoming changes to Wikimedia Foundation Grants

Over the last year, the Wikimedia Foundation has been undergoing a community consultation process to launch a new grants strategy. Our proposed programs are posted on Meta here: Grants Strategy Relaunch 2020-2021. If you have suggestions about how we can improve our programs in the future, you can find information about how to give feedback here: Get involved. We are also currently seeking candidates to serve on regional grants committees and we'd appreciate it if you could help us spread the word to strong candidates--you can find out more here. We will launch our new programs in July 2021. If you are interested in submitting future proposals for funding, stay tuned to learn more about our future programs.

@Mjohnson (WMF): just to clarify, regarding the conditions we discussion:

• Is the limit (10 suggested) intended to be the number of wikis the extension is deployed on, or the maximum number of wikis that can be included in a user's global watchlist at one time?
• The extension should only be available on meta - just the configuration part, or also viewing the watchlist? I.e. can I still use w:Special:BlankPage/GlobalWatchlist (or whatever the special page becomes), or is it only viewable on meta?

Thanks, --DannyS712 (talk) 04:21, 30 May 2020 (UTC)

@Mjohnson (WMF): @I JethroBT (WMF): just want to make sure you saw my questions --DannyS712 (talk) 01:44, 4 June 2020 (UTC)

@DannyS712: Yes, this is my understanding of that request, but please confirm this limit with an advisor or relevant technical staff once you have connected. I JethroBT (WMF) (talk) 14:35, 4 June 2020 (UTC)

@I JethroBT (WMF): "yes" to which part? --DannyS712 (talk) 14:54, 4 June 2020 (UTC)

@DannyS712: Apologies, I misread the questions here. Unfortunately, there is also ambiguity here for me reviewing these recommendations, and this will need to be clarified more directly with relevant technical staff. In my perspective, there is a conflict here if there are recommendations both to deploy to ten wikis or just to Meta. We will reach out to technical staff to clarify this with you when we are able. I JethroBT (WMF) (talk) 18:08, 4 June 2020 (UTC)

Per IRC discussion with Danny, I've agreed to help out with the code review on this. --Jack Phoenix _(Contact) 01:13, 12 June 2020 (UTC)

I believe this has already been cleared with the Grants program, for the public record, I am serving as secondary technical advisor for this project. MusikAnimal (WMF) (talk) 20:58, 23 September 2020 (UTC)

I am serving as a technical advisor for Danny on this project. Thanks. -- NKohli (WMF) (talk) 05:20, 30 September 2020 (UTC)

Meta extension vs userscript

@DannyS712: I just tried out the extension on Meta and I was wondering how different it is from your global watchlist userscript. Is there a list of differences somewhere? NMaia (talk) 02:21, 23 February 2021 (UTC)

@NMaia sorry for the delay, I just saw this. There is not a list of differences anywhere, it should be mostly the same for now though I will continue to develop the extension and not the script, so over time the two may diverge DannyS712 (talk) 00:35, 19 April 2021 (UTC)