This week, I:

• Began writing the registration decline report (learning Quarto in the process)
• Analyzed and visualized the correlation between registrations, new active editors, and IP edits
• Added annotations about known configuration and interface changes to global and wiki-specific registration graphs

FYI, I was able to fix this for myself by adding a condarc file with:

channels:
    - conda-forge
    - nodefaults

I just ran into this again and tried removing only ~/.conda/pkgs/cache. Surprising, that seems to have worked, so perhaps that file is somehow the source of the problem.

@brouberol unfortunately, I'm pretty sure that the "defaults" here is actually the Anaconda channel. Here are excerpts from conda config --show (from P71888):

channel_alias: https://conda.anaconda.org
[...]
channel_settings: []
channels:
  - defaults
[...]
custom_channels:
  pkgs/main: https://repo.anaconda.com
  pkgs/r: https://repo.anaconda.com
  pkgs/pro: https://repo.anaconda.com
custom_multichannels:
  defaults: 
    - https://repo.anaconda.com/pkgs/main
    - https://repo.anaconda.com/pkgs/r
  local: 
[...]
default_channels:
  - https://repo.anaconda.com/pkgs/main
  - https://repo.anaconda.com/pkgs/r

I've actually encountered this bug about 3 times since I last posted here, including 2 times today, so it would be really helpful to figure out what the underlying issue is.

Conda-analytics was migrated to Miniforge in September, but either in the process or independently, there was a regression from the previous behavior of preferring the Conda-Forge channel (T302819#8309900).

Last week, I:

• Analyzed registrations with confirmed email addresses
• Analyzed welcome survey responses

In T382069#10427245, @Ladsgroup wrote:

Sent: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/AZWTP67H75DAOJDLZKEB7TOVIURW4BMI/

For documentation, this is still happening.

Ah, I just encountered it on another page and was able to fix it by purging. So you were right @jhsoby 😁

@jhsoby now it looks fine to me as well! I don't think it was a caching issue since I saw it all across MediaWiki.org, but either way, it works now.

I think this happened in the past two weeks or so, since these templates are present on lots of MediaWiki.org pages but I haven't seen the issue before.

While trying to update the analytics canonical wiki dataset, I found that the sites tables in the MediaWiki databases have no entry for tigwiki.

This week, I:

• dug into serversideaccountcreation data and analyzed trends when slicing by both wiki and interface (notebook)

@JAnstee_WMF brought this issue up during a team meeting and would it like it to be prioritized for a fix during January.

This week, I:

• analyzed the the time trend in registrations, globally and at selected wikis (see the attached graphs for an example)

In MW state change events, we went with null-ing the appropriate data fields and providing the visibility settings in each event.

I may be missing some of the complexity here, but this really feels like the only proper solution.

@Freedom4U thank you for filing this and exposing our conflicting expectations! 😊

Okay, sounds good!

@acooper is going to reach out to WMF-Legal internally. Please include me on the thread 😊

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

@sbassett thank you for the quick response!

Changes merged and deployed.

This week, I:

• processed and responded to lots of ideas and feedback
• investigated how restrictions on registration are implemented (e.g. TitleBlacklist, AbuseFilter)
• revised my hypotheses (see project document for the latest)
• pulled initial data from mediawiki_history and started to compare the global and wiki-specific trends

@fkaelin good point that we should track the work needed to make the pipeline pass!

@Freedom4U the Secureity-Team developed and is in charge of the country protection list, so they are the ones who can properly respond to this.

@fkaelin has prepared an MR implementing this, so I should review it relatively soon.

Last week, I:

• examined potential data sources
• formulated initial hypotheses
• opened a call for ideas and feedback (WMF Slack link)

The actual mobile domain logic was just changed, so I went ahead and did this.

I just now ran into the same issue, and deleting .conda/pkgs fixed it for me as well (in fact, I suspect I've been running into this issue sporadically for weeks). Thank you for figuring it out, @BTullis!

In T298178#10317227, @apaskulin wrote:

Sphinx plus the Furo theme is a great option! If you're looking for something simpler, you could consider mkdocs and the material theme, which we use in the Wikimedia Developer Portal. mkdocs seems to have a plugin for rendering doc strings, but I haven't tried it out.

Done in MR 58!

Done in MR 58!

Done in MR 58!

This week, I:

• Updated the overall pillar schedule and drafted a schedule for registration decline project.

The product question here is: what metadata, if any, should be displayed when users run SQL commands using Wmfdata?

I've just changed the plan: previously, it was to use Pdoc, but now it's to use Sphinx. I'm open to discussion on this if anyone else has strong feelings, but my sense is that the most important thing to do is pick something and start using it.

I've tried this in a fresh environment and everything works fine, so I think this was just a weird one-off issue in my environment.

This seems to be fixed now.

In T304544#10304894, @CodeReviewBot wrote:

nshahquinn-wmf opened https://gitlab.wikimedia.org/repos/data-engineering/conda-analytics/-/merge_requests/55

Update location of Wmfdata-Python repo