- User Since
- May 14 2019, 10:44 PM (211 w, 5 d)
- LDAP User
- MediaWiki User
- IFlorez (WMF) [ Global Accounts ]
Fri, Jun 2
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.
Wed, May 31
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?
Tue, May 30
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.
Wed, May 24
Quick update: there's no API envisioned for the CRM.
Tue, May 23
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).
Mon, May 22
@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.
Sun, May 21
@DNdubane_WMF confirms using the Mediawiki API to pull the data of the affiliates data portal on meta
Fri, May 19
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.
Thu, May 18
- 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.
Wed, May 17
@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.
Tue, May 16
Jotting down code needs previously discussed in meetings with @HXi-WMF and @Mayakp.wiki :
Fri, May 12
Thu, May 11
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.
Wed, May 10
FYI: March metrics report from Github report : https://jamboard.google.com/d/1-DN7KarpiH0VOm__8E1Ybh_L2wuRPLz421g9bxBCc3M/viewer?f=0
Apr 25 2023
- 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
- see about regional views and Grants feedback from Jessica
Apr 20 2023
Per @JAnstee_WMF the only country that remains unclassed is Antarctica.
Apr 19 2023
Thank you @kzimmerman
Apr 18 2023
All of the data needed is now on the API. Thank you.
Apr 17 2023
Thank you for prioritizing this.
UPDATE: NNC data updates completed
Apr 14 2023
Idea 1 - organizers will see the click wrap only one time over their organizing tenure?
Apr 13 2023
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."
Apr 12 2023
Apr 11 2023
Apr 10 2023
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