Concerning "Can we think about making this work without wikiprojects but use categories instead? (Suggested in the proposal discussion)", really what the bot needs is a list of page, in any format. We [current system] do it based on

Via WikiProject banners on talk page (standard subscription) [https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:WikiProject_Video_games -> Convert results to non-talk namespace]
Via infoboxes [https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Infobox_video_game -> Convert results to non-talk namespace]
Via category: [[Category:All Computing articles]]
Via deletion sorting [this is en-specific, involves the AFD being listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Deletion_sorting/Africa for example

This can be genericized to subscriptions based on WhatLinksHere [or any similar bot-friendly list], or to subscriptions based on Categories. The enwiki Wikiproject framework isn't required to make such topical list. You could set up a "physical science" list in without a Wikiproject framework by doing something like

Category-based articles
*[[Category:Physics]] [depth = 5] (or any other depth)
*[[Category:Chemistry]] [depth = 5] (or any other depth)

Category-based template transclusions [would likely include stuff only physics-related, but it's a very efficient way of casting a wide net]
*[[Category:Physics templates]] [depth = 1]
*[[Category:Chemistry templates]] [depth = 1]
-->WhatLinksHere for every template in category.

Direct template transclusion [would allow for a more finely-tuned list of template, if the above method is found to include too much crap]
*[[Template:Computational physics]]
*[[Template:General physics]]
*[[Template:General chemistry]]
*[[Template:Wolf Prize in Physics]]
...

API limits may be tricky here, as some categories/whatlinkshere results can be truly massive. But the general idea applies.

Look at the source code provided by Hellknowz. (see email) Look at how workflows are implemented in the existing bot. (Note that the code is in C#)
Looked.

Determine if there are current workflows that are standard across several wikis. How many can be described?
There are several levels to it. For example, basically every wiki has 2 principal types of deletion: speedy and discussion-based. Other than when they don't like enwiki's proposed deletion. Beyond that, you will struggle to find a 1:1 correspondence. Wikis categorize their deletions differently (not a problem if the bot is made properly configurable), use different ways of populating lists (this is more problematic, you might have to write code to handle each workflow's quirks), and determining the state of workflow (very problematic, might require lots of both custom coding and maintenance efforts as things change). You're looking at carefully configuring and maintaining every workflow on every wiki and likely having to write code for at least 1-2 workflows per wiki.

Take a look at PageAssessments extension which maintains a database table for pages associated with wikiprojects and their quality assessments. Could the extension possibly be useful here (with or without changes)? Should we deploy it to more wikis (this requires community interaction for editing templates)?
Yes, it could be useful for retrieving projects an article belongs to. There's currently no such functionality in PA but the data is already available, so an API module doing what we need would be fairly easy to develop.

Could this be an extension instead of a bot?
Extensions are harder to develop and possess higher maintenance cost than bots, so I'd rather not commit to it.

Can we think about making this work without wikiprojects but use categories instead?
Yes, see the reply by Headbomb, however maintenance would probably be harder as category tree can easily get more complex than WikiProject hierarchy.

Determine which wikis want this and would benefit (use WikiProjects or something equivalent)?
"Want" is something we should ask them, but here's some statistics to help understand the scope of this:

• Judging by interwikis here, 88 wikipedias have the concept of WikiProject.
• 15 wikipedias tag their articles by importance.
• 27 tag by quality.
• Wikipedias with at least *some* tagging by WikiProject: ar, el, en, fa, fr, ko, id, it, hu, ja, pt, ro, ru, sq, tg, tr, vi, zh.
• Wikipedias with at least some categorizing by topic: ba, nv.
• th tags by portal.
• Tagging can be extremely spotty. Random sampling on ruwiki: 5 articles tagged out of 20, frwiki: 11/20, rowiki: 12/20, viwiki: 18/20, tgwiki: 6/20.
  • Therefore, this bot wouldn't be useful for a wiki with most articles untagged.

Conclusion
This is the most problematic wish this year. Doing it for a single wiki isn't hard. Scaling it to many wikis (as requested) would require lots of effort and will extract serious maintenance toll after the project is completed. I recommend a serious assessment of cost to benefit ratio and our team's ability to maintain it in the long run before committing to it.

This is why I framed the proposed solution the way I did. "Have the WMF / larger Wikimedia community create a more solid and scalable framework for Article Alerts that can also be deployed to all languages." Framework is the important word here. It leaves the implementation details to the wikis.

The Core

Get rid of the specifics, forget WikiProjects, importance, quality, portals. The core idea is this
a) You have "topics" --> The framework need ways understand what consists a topics
b) You have "workflows" --> The framework needs ways of understanding how workflows are setup
c) You compare pages belonging to topics, against pages belonging to workflows
d) You report when a topic enters a workflow, and when it exits a workflow
e) Everything else is fluffy extra features and you can worry about that later once the basic framework is setup.

Part 1 - Topics

This should be rather simple and customizable on a per topic basis. I've explained how topics are declared on enwiki here: https://phabricator.wikimedia.org/T184304#3963914

You put the following [machine-readable] template on a page. It doesn't have to be a template, but templates can produce visible outputs, which is always something nice.

{{AALERTS-Subscription
 |topic=Video games
 |template1=Template:WikiProject Video games
 |template2=Template:Infobox Video game
 |category1=Category:Video games
 |category1-depth=3
 |category2=Category:WikiProject Video games articles
 |category2-depth=2
 |delivery=Wikipedia:WikiProject Videogames/Article alerts
}}

Then AABot reads that, and understands that you're telling it that everything that transcludes Template:WikiProject Video games and Template:Infobox video games is of interest to the topic. Likewise it understands everything in Category:Video games (depth 3) and Category:WikiProject Video games articles (depth 2) is also of interest to the topic.

The bot then produces a report, and uploads it on a page somewhere. This could be done in two ways. The old way we did it in enwiki was that the bot created a report on the same page the template was put on. So you create a [[Foobar/Article alerts]] page, put the subscription template there, and the bot uploads the report below the template. However we found that it's best to centralize things so screw ups are seen by others who can help with things. So the current way we do it is you put the subscription template on a master list instead (https://en.wikipedia.org/wiki/Wikipedia:Article_alerts/Subscription_list). This allows a per-topic customization, and we leave it to projects to decide what's of interest to them.

This is completely independent of how collaborations are structured on local wikis. Build the framework, document it, and let local wikis worry about how they organize topics.

Part 2 - Workflows

This is something that, unlike topics, should be declared once per wiki. This part is harder to distill, because there's a lot that is workflow specific. However, from what I can tell, these are the main ways discussions are structured.

A page enters/leaves a category [easy]
A template is placed/removed on a page [easy]

For instance, in the same template-like language as before

{{AALERTS-Workflow
 |workflow=Wikipedia:Articles for deletion
 |workflow-shortname=AfD
 |category=Category:Articles for deletion
}}

and check if pages belonging to a topic is present in the category (or not).

I don't currently have an example of something purely template-based, but you could easily have something like

{{AALERTS-Workflow
 |workflow=Wikipedia:Generic for discussion
 |workflow-shortname=GfD
 |template=Template:GfD
}}

and check if the template is transcluded on a page of interest (or not).

Part 3 - The Fluff

The fluff is stuff that is nice, but not critical to the idea. For instance pointing to discussions directly [e.g. Foobar is at [[WP:AFD/2018-02-12/Foobar (2nd nomination|AfD]]) rather than simply say "Foobar is at AfD" is nice, and while desirable this is not a core feature. Counting participation is nice, but again, not a core feature. Figuring out who nominated is nice, but not a core feature.

Maybe you can add further things in the {{AALERTS-Workflow}} template to declare more details about how these workflows are setup, but that really shouldn't be the focus here I feel. If it can be done great! But you could get into something over-engineered really quick.

In T184304#3991703, @MaxSem wrote:

Conclusion
This is the most problematic wish this year. Doing it for a single wiki isn't hard. Scaling it to many wikis (as requested) would require lots of effort and will extract serious maintenance toll after the project is completed. I recommend a serious assessment of cost to benefit ratio and our team's ability to maintain it in the long run before committing to it.

and

In T184304#3994104, @Headbomb wrote:

This is why I framed the proposed solution the way I did. "Have the WMF / larger Wikimedia community create a more solid and scalable framework for Article Alerts that can also be deployed to all languages." Framework is the important word here. It leaves the implementation details to the wikis.

I would agree with Max that it's not tenable to productize each workflow for every wiki (or even a subset) but I also agree with Headbomb that there is room for us to build a framework/scaffolding and documentation so other wikis can create and customize their own bots. I like the idea of a simple ITTT system — "if a template/category is added to an article with another template/category (or it's talk page), then post an update _______"

We can also think about creating a cross-wiki group on meta/mediawiki.org/elsewhere to help customize and manage the bots for wikis without technically savvy users.

I'm doing some thinking about this. I understand @Headbomb's proposal and it's a good one but it's also going to take a lot of time and effort to build properly. More than that, it would need consensus across projects - after all they have to agree to adopt it before we build it. That's no small feat.

At the heart of Article alerts, what we have is:
A list of articles ---> A template/category applied or removed ---> A notification sent out at $designatedPlace.

I think we can build something that can do something like this without having the need to build additional frameworks.
Step 1: Have a page (something like the Article alerts subscription list) where each person X can add a link to a list of articles (or a category with a specific depth), post a list of templates, a list of categories and $designatedPlace.
Step 2: A bot picks off the lists, figures out if those templates or categories were added/removed from the list of articles linked to and if so, posts on $designatedPlace. The bot runs once an hour/daily/something.

This offers the following advantages:

1. WikiProjects are no longer in the picture. Anyone can create a list and get the alerts wherever they want. (Of course we'll have filters to make sure the notifications go on talk pages only etc.)
2. We've separated the workflows from the project. This will work on all wikis.
3. Much simpler to build.

Disadvantages:

1. There'd be a cap on how many articles can be added to lists.
2. People might find lists confusing or annoying. They'd have to be manually updated (unlike what was being done with wikiprojects - fetching pages with embedded wikiproject template).

I think the tradeoffs are worth it. We can still end up with something simple, maintainable and usable.

'Lists of articles' are in theory workable. I've omitted it from the subscription methods simply because would be a real pain to maintain, and (at least on enwiki), it would simply duplicate the Wikiproject structure/functionality.

But there's nothing that would prevent this conceptually. As for an article cap, I don't really see why there would be one. Add something like

|list1=Wikipedia:Foobar/List of Foobar articles 1
|list2=Wikipedia:Foobar/List of Foobar articles 2
|list3=Wikipedia:Foobar/List of Foobar articles 3

for structured lists of page in a specific format, or alternatively

|links-on-page1=Template:Particles
|links-on-page2=Template:Neutrino_detectors
|links-on-page3=Template:CERN
|links-on-page4=User:AlexNewArtBot/PhysicsSearchResult

for any links appearing on those pages

Also, as a side note, it doesn't really require consensus in the usual sense, save perhaps on enwiki if you want to replace the existing system. For every other wiki, no such thing exists. Build the framework. If they want it, they can use it. If they don't want it, they can just not use it/ignore it.

A simplified setup for smaller / less active wikis could simply be a subscription for all articles on the wiki. Or namespace-based suscriptions.

We discussed this yesterday in our team meeting and before we decide on any technical direction we are first going to identify which wikis want this functionality, have user bases that would benefit from this functionality, and are structured in a way where their workflows can be understood by a bot.

In T184304#3996917, @TBolliger wrote:

We discussed this yesterday in our team meeting and before we decide on any technical direction we are first going to identify which wikis want this functionality, have user bases that would benefit from this functionality, and are structured in a way where their workflows can be understood by a bot.

I'm gonna push back on this a little (not just a reply to Trevor, of course). This is a project which can potentially help develop wikis which don't have structured workflows. It's mostly the smaller/medium sized projects which are still struggling to figure out what workflows work for them. We shouldn't build something that only helps the already developed, bigger projects. This is an opportunity to give those smaller project editors a nice tool to help them do their job better.

I'd love for what we build to work on any wiki that wants it, but if we spend a lot of time building for wikis that don't actually want this, then we've wasted our time. I still think this needs to be our first step.

Community Tech has a lot of other simultaneous project in progress so I cannot commit any product management time on this for some time. I've created T188135: Determine which wikis would benefit from Article Alerts to track this work.

The options, as I see it, are:

1. Build something that is highly customized to a few wikis which have well defined workflows.
2. Build something that is very generic (watered down) and configurable and can be used by nearly every wiki.

I am pushing for #2 and I think it'll actually take less time to build compared to #1. That is a discussion to be had with @kaldari though.

From my experience with workflows and such, #2 seems by far the easiest-to-code, most scalable option.

Fluff is nice, but fluff is also very time consuming to code and maintain, and very badly scales. I think if individual wikis want something that is extremely customized to their own wiki, they are better off creating a fork they can adapt to the peculiarities of their local wiki.

It might be worth thinking about some low-hanging fruit customization, if they can be found. For instance, implementing customized workflows for a specific 'topic' similar to https://en.wikipedia.org/wiki/Wikipedia:Article_alerts/Subscribing#Choosing_workflows shouldn't be too hard to do.

Niharika and I have different opinions about this project and are meeting on Thursday to discuss what's next.

Since I can't be there to discuss this, I'll just say that as proposer, i believe the community supported something more in line with #2 (make a framework that individual wikis can customize), rather than have the WMF do all the customization work.

I think writing any custom workflow code for a particular wiki is going to lead to a maintenance nightmare (assuming that CommTech is in charge of maintaining it). I would rather that we write something that is simple and generic, as suggested by Niharika. Of course the big risk is that it will be so simple and generic that no one will use it. My suggestion would be that we find one smallish wiki that would greatly benefit from an Article Alert system (even a very simple one) and wants to work with us. Then we build a completely generic workflow alert system with that wiki in mind and help them get started using it (but we keep it 100% generic). That way, we can be sure that our work won't be a total waste (it will be used on at least 1 wiki) and we'll have a nice example set up for other wikis to learn from. The only workflows it would support would be the ones listed by Niharika: a category or template is added or removed from a page. If people want something more complicated, they would have to folk their own version. Thoughts?

@kaldari Don't forget enwiki might want to transition to this system in the future, either because the new system is better, or because the bus factor (https://en.wikipedia.org/wiki/Bus_factor) kicks in.

I for one would be very interested in trying to recreate as much of the system on enwiki. There are some workflows (like merges) that we don't track currently like that might be possible to track with this, so the new system might get used in parallel to the current one. At the very least, enwiki would be a very very good testing/development platform.

I agree that workflows via categories/templates should be the only things supported for now. But if other (easy) ways can be found it might be worth to investigate those as well. The only other way I can imagine for now would be a page being listed on another page. So you could have something like

{{AALERTS-Workflow
 |workflow=Main page
 |workflow-shortname=MP
 |is-linked-on=Main_Page
}}

{{AALERTS-Workflow
 |workflow=Generic Workflow
 |workflow-shortname=GW
 |is-linked-on=Wikipedia:Generic Workflow/List of pages
}}

Short of the main page, I don't know of any workflows set up like this. But this might be different on non-enwiki wikipedias.

I fully support finding non-enwikis to test things with as well however.

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu