I recommend moving forward with a single model.
The link-based model has worked well in my experience and it is noted as useful for both analytics and features cases. Thus, I recommend moving forward with the link-based model.

These ideas including those that came up during our knowledge transfer of high level metrics calculation with Connie may be useful to work on in the future:

Could this be a good opportunity to improve upon our naming conventions?

Issue: There are two major ways for calculating edits....those using a) MediaWiki Cu_changes table calculations and those using b) MediaWiki History table calculations. These two methods are slightly different, and output slightly different numbers. See T189044 Mediawiki History moves are counted twice in Revision: "there are many ways we can label these edits and many ways we can include/exclude them from different metrics. But without a clear definition of what we're counting and why, there's no "problem" in the technical sense. Just ambiguity."

I added two comments in the Splitting wmf Hive database sheet on the categorization. Thank you for this work. This direction will be helpful for table discoverability.

Quick update: there's no API envisioned for the CRM.

Chris Andreen from the MacArthur foundation says:

Fluxx's Dane Robinson says:
It is possible. However, we don't have any documentation on that specific ask. In our documentation, you would need to leverage the Cross Card Filter section to accomplish this.
API Cross Card filters (and API filtering in general) can be difficult, so I made a video on how to create API Cross Card filters (this also applies to regular filtering on most tables).

@DSaroyan_WMF shares: Hallowelt was our partner to develop a tool which used the Fluxx API to publish grant applications on Meta. I think the code of the tool may be useful for you to understand how to call the API. https://gitlab.wikimedia.org/toolforge-repos/cr-grants-team-metasync

Logging in to community.fluxx.io I see a special API group, a forum of sorts akin to one of our Slack channels. This may be the best place to post specific questions.
Grant ID is possible to pull using the API. I posted a question on the documentation thread in that channel, asking for documentation references specific to that sort of pull.

@DNdubane_WMF confirms using the Mediawiki API to pull the data of the affiliates data portal on meta

@DAlangi_WMF notes:
Humans can query for always updated names of affiliates via the advance mode on the search form here: https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal.
(1) visit that URL (https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal)
(2) hit the search affiliate data button
(3) toggle to the “Advance mode”
(4) fill in the fields (step 1 - 5) top down with the below values. For dates, you can just put from 2000 - today (present) and you should have an updated list.

@cmelo It sounds like you could use json output from Quarry's quasi API setup (the json out put link). In that case, a functional quarry query could work. Unfortunately, I cannot recommend an easy serve solution here as I don't have a working query yet.

In T322332#8678239, @Astinson wrote:

We may want to include "which languages do you plan to contribute in?" in that its both technically easy to do (use the language lists from the projects) and will improve the signals that Irene and the P&E dashboard can create in terms of metrics (one of the problems right now is that most of the tracking tools in the movement require prior knowledge of the language someone plans to contribute in). This is unlikely to be common in small events, but international writing contests this is key for tracking.

We may want to change a couple of the professions: Software engineer -> Technology professional, Mass media professional -> Communications or Media Professional and Librarian -- Library professional -- to be consistent and provide the widest possible buckets. Librarian or library worker is the more common scope of these kinds of things globally (because librarian typically implies having a degree in library work and a lot of library workers are not degreed, software engineer is hyper specific and doesn't capture the broader technologist buckets).

Also, as a note, you may run into technical complexity with the youngest bucket in the age groups -- in that it might require us to not collect additional information (working with minors and collecting data about minors is incredibly complicated when working in as many contexts as we do -- in some contexts its illegal to keep collecting data once you know there age).

Questions:

• Do you want to exclude bots? (user_is_bot_by)

Recommendation based on conversations with Rebecca Maung:
Use the new_editors table to track all three metrics to reduce the scope of the task.
Using this table for all three metrics means that RMaung will be taking into account a 2 month delay in reporting.
We approached querying by considering two metrics: new editor retention and new editors. Once the query is finalized for NER and NE, the query can be duplicated and adapted for new active editors.
To test the data we started with querying for CM data only.

The long term stewardship of this sort of work may reside with the movement insights team. However, planning is underway and currently the focus will be contributors with advanced permissions. That focus would inform work prioritization.

@cmelo the closest thing to an API output is JSON query results from Quarry.
Quarry is a web SQL client for queries to the https://wikitech.wikimedia.org/wiki/Wiki_Replicas sanitized clones of the production MediaWiki metadata tables.

Jotting down code needs previously discussed in meetings with @HXi-WMF and @Mayakp.wiki :

Thank you @JStephenson and @Sadads for your feedback.

Thank you @JStephenson and @Sadads for walking through this with me. I've updated https://phabricator.wikimedia.org/T329382#8806349 with our discussion highlights.

FYI: https://jamboard.google.com/d/1oSPFniI2O-l0DcLvlmYjKz8yhKSPyqxGbbPVQIRi9U8/viewer?f=0
FYI: March metrics report from Github report : https://jamboard.google.com/d/1-DN7KarpiH0VOm__8E1Ybh_L2wuRPLz421g9bxBCc3M/viewer?f=0

1. New campaign global user A newly registered campaigns user is a previously unregistered user creating a username for the first time on a Wikimedia project through campaign event pages or registration extension.

A next ticket should include:

• • discuss potential solutions with PA team given options and tradeoffs POSTPONED
  • adapt for all wikis, adapt for templating on time each month
  • sync with Gregory -- demo reporting outputs
• adapt setup given input
  • query SSAC for new event editors > postponed while we define new campaign editors T329382
• see about regional views and Grants feedback from Jessica

Per @JAnstee_WMF the only country that remains unclassed is Antarctica.

Thank you @kzimmerman

All of the data needed is now on the API. Thank you.

@JArguello-WMF
Thank you for prioritizing this.
UPDATE: NNC data updates completed

Idea 1 - organizers will see the click wrap only one time over their organizing tenure?

how does adding additional organizers impact data storage?
Are we adding additional columns to the table or changing the data type of organizer_username so that we can store the organizer names as a tuple or ?

Can you take a look at the last comment and provide your feedback?
Given what's here so far, it looks like I can close this ticket out within the next 7 days. If you disagree, please share more.

Note: returnTo "Indicates the wiki page the user was on when initiating Create account."

1. PII MVP Decision-making document
2. Privacy review - Campaign Registration System

CODE REVIEW

CODE REVIEW - EDITORS DAILY NUMBERS
Is the Editor's Daily query only returning those editors that have made 5+ namespace_zero edits in at least one day? Instead of returning the names of all editors with 5+ edits over the month (when each editors edits are summed )? No. See the results from this query:

editors_daily_aggregated_per_M = spark.run("""
WITH edit_data AS

In brief, the issue is that the two categories of methods for calculating don’t match up:
Method's derived from MediaWiki's history table are calculating bigger comparatively
Method's derived from MediaWiki cu_changes table are calculating smaller comparatively