# Scikit-learn Monthly Developer

Next major release (1.9) scheduled date: beginning of May 18th, 2026
Release managers: Jérémie
Backup release manager: Virgil

## March 30 2026 @ 4pm CET

### Updates

- [name=Guillaume] I'll push forward the scikit-learn sprint
- need to find room, etc
- date: June 8 - June 12

### Topics

- [name=Tim] Is a PyTorch CPU tensor "array-like"?
- Until recently documentation did not mention PyTorch CPU tensors
- In practice it (mostly) just works and people are using it
- we received bug reports when we broke something that worked
- https://github.com/scikit-learn/scikit-learn/issues/33342
- https://github.com/scikit-learn/scikit-learn/pull/32676 documented this behaviour
- Q: Should this behaviour be officially supported and documented?
- pro: it has worked, people are using it, ergo it is part of the official API
- con: it was never documented, users got lucky, no promises were ever made
- Deciding this is useful for "move array API out of experimental" because we want no regressions for users who do not use array API.
- your numpy only workflow should not change
- if torch CPU is considered officially supported we need to think about consequences
- Answers:
- [name=Olivier] we did mention anything supported by `numpy.asarray`: https://scikit-learn.org/1.1/glossary.html#term-array-like so to me that includes PyTorch tensor with CPU device.
- update the issue to refer to `np.asarray`, see if this settles things
- need to take this into account wrt behaviour change if we make array API default on

- [name=Olivier] I will soon open PR(s) to propose some scikit-learn.org website evolution w.r.t the objective of improving the long-term financial sustainability of the maintenance of the project. Here are the 3 planned changes that I will to subject to your review:
- more prominently advertise probabl and other entities that provide financial/institutational support on the website on the home page
- dedicated and updated page to document institutational support on the website (rather than a subsection of the about.rst page)
- link to probabl commercial support and services offering + info about the relationship between probabl and scikit-learn from the right hand side panel in the doc pages (below navigation)

- [name=Olivier] Any volunteer for a release manager for the May 18th release?
- [name=Jérémie] Yes, unless someone else wants to :)
- [name=Virgil] volunteer as RM assistant

### Needs attention/decision

- [name=Christian] (unable to make it to the meeting) [#28711](https://github.com/scikit-learn/scikit-learn/issues/28711) Replace penalty param `C` by `alpha` in `LogisticRegression`. 2 years old! Please look at the table in the issue and the reasons given in the [PR#32042](https://github.com/scikit-learn/scikit-learn/pull/32042). I would reeeeeeally like to move forward with this. It is the last deprecation I envision for LR.
- I am not aware of complaints in the past, e.g. `multi_class` or `use_legacy_attributes` ...
- [name=Olivier] the deprecation of the `penalty` attribute did cause drama on linkedin.
- If it helps, I take full responsibility and all the blame for this deprecation (because I am certain of the long term benefit)
- What problem are we trying to solve here?
- We might consider changing the default `alpha=1` to a much smaller value like 1e-4 or 1e-6, for all GLMs (because it is a better default).
- [name=Jérémie] suggests splitting the discussion for the two changes: 1/C -> alpha on one hand and scaling by n_samples on the otherhand
- we c/should have a vote for those changes because it will have a large user impact
- [name=Olivier] could be a scikit-learn 2.0 change if we do it
- array API out of experimental and enabled by default
- metadata routing enabled by default

- [name=Jérémie] vote for [SLEP 23: Callbacks](https://github.com/scikit-learn/enhancement_proposals/pull/103) is open until april 20.

## February 23 2026 @ 4pm CET

### Updates

- [name=Jérémie] Ongoing work and schedule for the callback API
- Goal: Have a minimal working implementation in v1.9 (mid May)
- Implies a call for a vote on the [SLEP 023](https://github.com/scikit-learn/enhancement_proposals/pull/90) 2nd half of March.
- https://github.com/scikit-learn/scikit-learn/pull/28760 has been merged in the `callbacks` feature branch. It includes the API and a callback for progress bars.
- In the coming weeks (before calling for the vote):
- progress tracked in https://github.com/scikit-learn/scikit-learn/issues/27676
- Add documentation for end users and third party devs
- Make sure that we don't break user code when they use functions and meta-estimators than don't support callbacks
- Implement a callback to monitor a given metric, on either the training set or the validation set, during fit.
- keep the slep up-to-date
- Discussion around priorities: meta data routing, array API and now callbacks, is it too much at the same time?
- Meta data routing: Almost finished. What is needed to make it the default?
- [name=Adrin] Meta data routing almost done, so no problems to push callbacks now.
- [name=Olivier] Basically just sample weight, then we could set it as default (otherwise it would be a usability regression for users that rely on sample weights).
- [name=Adrin] Would be fine to set meta data routing as dfault, even now.
- Decision: Let's do the sample weight default and then announce meta data routing the new default, i.e. you need to opt-out.

### Topics

- [name=Loïc] Add "Not open for contribution" or a better named label? Suggested by Lucy (all the latest callbacks issues have a manual comment mentioning "this issue is not open for contribution" ...). Longer-term we could think of a workflow based on labels (e.g. "Needs ..." or "Not open for contribution") updating the top comment with a warning similar to https://github.com/scikit-learn/scikit-learn/issues/32739.
- Adrin: no objection, feature request for GitHub for limiting interaction on a per-issue level?
- Anne: Guidelines for the "Needs triage" not read by contributors. AGENTS.md suggestion.
- Jérémie: like the idea of automatic comment based on label
- Tim: not adding a new label would be great. Perfect label would not need explaining. Can we have a better label name like "Not ready".
- Loïc: label are not necessarily super visible in the UI. Text inside comments are maybe more visible?
- Olivier: "Needs Triage" is useful when doing triage to look for issues that have not received a first look by a maintainer. Keep both.
- Christian: no more labels. People doing the triage should decide what works best.
- Adrin: AGENTS.md to guide agents usage is a potentially other thing to do.

- next step 1: implement workflow based on label to edit issue description and add a visible warning in https://github.com/scikit-learn/scikit-learn/issues/32739. This would be based on labels like "Needs Triage", "Needs Investigation" or "Not open for contribution" or "Not PR-ready" (if we end up creating it).

### Needs attention/decision

- [name=Loïc] Next step on control spmatrix vs sparray creation via config: https://github.com/scikit-learn/scikit-learn/pull/31177.
- Loïc will find the time to do another detailed review with potentially removing the testing/CI aspects for another PR. No objections on the approach from anyone.
- [name=Christian] SLEP 25:
- https://github.com/scikit-learn/enhancement_proposals/pull/98
- Next step? Insight: There is no good default score:
- Deprecate .score altogether?
- [name=Olivier] Keep `.score` but raise a warning pointing to the documentation to help using explicit set a value to silence the warning.
- [name=Olivier] Update all our examples to use more informative scoring (and possibly several of them).
- [name=Olivier] Make score return a structured evaluation object with the name of the metrics in it.
- [name=Jeremie] Stop allowing `scoring=None` in `cross_validate` and `GridSearchCV`.
-

- [name=Christian] [#33214](https://github.com/scikit-learn/scikit-learn/issues/33214) Change default of `scoring` in `LogisticRegressionCV` from `None` (accuracy) to `neg_log_loss`.
- [name=Olivier] maybe D2 Log loss?
- [name=Christian] [#33160](https://github.com/scikit-learn/scikit-learn/pull/33160) New L1/Enet Newton solvers for LogisticRegression (and other GLMs). Idea/Motivation behind it.
- [name=Olivier] Lucy's (cross-) blog post on array API developments in scikit-learn: https://github.com/scikit-learn/blog/issues/222
- [name=Olivier] Adding JAX support (as an extra array API library to test against):
- https://github.com/scikit-learn/scikit-learn/pull/29647
- pros:
- SciPy supports JAX more and more and wanted to check how much work would be needed for scikit-learn to follow SciPy's lead
- JAX has a powerful linear algebra JIT compiler that could potentially help improve (but I haven't tried to investigate this part yet)
- a JAX fork of scikit-learn shows very promising results: https://pypi.org/project/jax-sklearn/ (it does rely on the JIT compiler to get those perf numbers)
- JAX can support CPU, CUDA, TPU and maybe MPS (Apple GPU, but I have not tried yet).
- JAX is often faster than numpy on CPUs
- JAX has a powerful JIT compiler (but I haven't experimented with it yet)
- cons:
- new `xpx.at` idiom inplace of `__setitem__`: more invasive code change than what is needed for other array libraries.
- a bit of extra CI maintenance work
- unfortunately TPU acceleration does not work well (or even crash) on scikit-learn's use cases

- [name=Tim] should we start having infrastructure for AI agents?
- https://agents.md/#examples
- open an issue collecting `AGENTS.md` examples people already use
- can we maintain these files outside the main repo?

### Action items

### Archived meeting notes:

- https://github.com/scikit-learn/administrative/tree/master/monthly_meetings

### Next meeting

Automatically configured as a recurring event on the shared calendar:

- https://blog.scikit-learn.org/calendar/

## January 26, 2026 @ 4pm CET

### Updates

### Topics

- [name=Loïc] Shall we schedule 1.8.1? [Milestone 1.8.1](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20milestone%3A1.8.1) has 3 items (2 HTML repr fixes and a fix for a confusing warning in `LogisticRegression`). Other things on people's mind?
- Wait a bit to see if users report problems with pandas 3?

- [name=Olivier] Callbacks SLEP draft (will soon call for a vote):
- https://github.com/scikit-learn/enhancement_proposals/pull/90
- implementation of the infrastructure: https://github.com/scikit-learn/scikit-learn/pull/28760
- example: https://github.com/jeremiedbb/scikit-learn/pull/27

- [name=Stefanie] exchanging a few names of contributors who do a great job and whom we want to collectively grant more attention (review faster, ping for opinions and reviews, …)
- these are people who do high quality PRs (easy to interact with in reviewing process) --> goal is to lure them into the project and make them stay
- where do we collect these names
- maybe a private project board
- or just talk about it every month (maybe we remember to do this for some time)
- how to we update them?
- **Resolution**: we become better at listing great people on whose work we should focus more during the meetings
- names for this week:
- [leweex95](https://github.com/scikit-learn/scikit-learn/pulls/leweex95)
- [cakedev0](https://github.com/scikit-learn/scikit-learn/pulls/cakedev0)

- [name=tim] TIL about the way to link to a person's PRs!

### Needs attention/decision

- [name=Olivier] Logistic Regression array API support: class-based refactoring done: https://github.com/scikit-learn/scikit-learn/pull/32644

### Broader topics:

- [name=Gael] For information, I'm trying to finish the comms guideline, to recruite more people in comms team
- Current status https://github.com/scikit-learn/enhancement_proposals/pull/92
- Considering moving this out of a SLEP, to enable easier modifications by comms team in the future

- [name=Olivier] as the triage person I understand now better why semi-automated PRs are problematic: even when technically correct, they might be orthogonal to user needs
- can you post a link to some examples?
- https://github.com/scikit-learn/scikit-learn/issues/33029

- [name=Gael] For future thoughts: what signals do we have to understand users' needs?
- [name=Tim] EuroSciPy - are people going?

## December 15, 2025 @ 4pm CET

### Updates

- [name=Tim] Next major release in May 2026, congrats on 1.8 coming out!

### Topics

- [name=Loïc] 3-tier system for estimators to help resource allocation/priority setting?
- Tier1 would be what we should focus on, important estimators that we know are useful and used. I think there is a broad agreement on this amongst maintainers. For example `RandomForest*`, `HistGradientBoosting*`, `LogisticRegresion`, `Pipeline`, `ColumnTransformer`, etc ...
- Tier3 would be "no new feature", "no bug fix", however easy they are. We can use the website + maintainer agreement to decide.
- [name=Olivier]: I am not comfortable with "no bug fixes": I would rather say: expect that bug reports on those estimators will not actively be fixed by the core team and that reviews on bugfix PR are very likely to receive attention unless fixing a critical bug (e.g. a crash)
- Tier2 would be the rest, big list, maybe "no new feature, only bugfix" rule of thumb, except in special cases.
- [name=Gael] Do a wording somewhere that says that opens a path for people to investing time and become actors of the package, thus influencing the tier rating
- **General feeling** it's all about the wording, nothing wrong with the idea

[name=Christian] Some thoughts about a tier system:
- What about first the vision, then the mission, then the priorities? We had a shy start with the vision some time ago in https://hackmd.io/H_CrV5OvSYiJVI-kWEg8ow.
- [name=Gael] Maybe we should publish this
- What impact will a tier system have?
- Shouldn't we always accept bugfixes? Otherwise we could remove the functionality altogether, IMHO.
- [name=Gael] removing functionality will create huge negative press
- [name=Olivier] it will also be significant work on agreeing to remove

- [name=Christian] Announce paid work (like grants) for scikit-learn on the blog, always. Consider making it a requirement.
- **General feeling** Agreed. We should do a better work on this, both on the previously funded grants, and on new one

- [name=Stefanie] in [#32680](https://github.com/scikit-learn/scikit-learn/issues/32680) we had been discussing on exchanging a few names of contributors who do a great job and whom we could collectively spend more attention (review faster, ping for opinions, ...)
- some names I'd share would be @virchan @EmilyXinyi @glevv @Tialo
- [name=Loïc] @dkobak has been active in manifold and TSNE lately sometimes reviewing stuff
- maybe we can find a (easy to keep) format to regularily add and remove names (edited)
- ideally we would be able to see that on github
- it is possible to see who is a first time contributor on github and we could mark their pull requests; equally, maybe there is a way to see if the author of a PR is in a certain team
- https://github.com/jupyter/pr-triage-board-bot/tree/main
- project board: https://github.com/orgs/jupyterhub/projects/4
- [name=Olivier]: Virgil is already part of the contributors experience team.
- **General feeling** keep this in mind and explore the possible implementations, including low-tech ones. The goal is to help distributing attention well, and not instutitionalize status via a "badge"
- talk about this topic/list again at the January 2026 meeting

- [name=Christian] Array API for LBFGS solver in LogisticRegression [PR#32644](https://github.com/scikit-learn/scikit-learn/pull/32644)
Christian's concern: Huge maintainability impact (=duplication of `_loss` module). Options should be discussed first.
- [name=Olivier] other (future) estimators with similar anticipated Cython/array API duplication:
- KMeans
- pairwise distance based models (nearest neighbors, nystroem)
- maybe (H)DBSCAN
- [name=Tim]: collect the known cases and solutions we explored and other possible solutions.
- try to have a central place to discuss and catalogue options
- **General feeling**: probably some duplication is a cost to pay to support dedicated hardware. We need to document this (hence collecting the known cases) and be aware about or tradeoffs

- [name=Dea] should I close this PR? Jérémie and Olivier seem unimpressed :-) : [ENH Display Methods in HTML representation](https://github.com/scikit-learn/scikit-learn/pull/31698) ?
- [name=Gael] Can we, should we, do user testing (on the broad idea of displaying methods)?
- [name=Dea] I haven't implemented the latest feedback.
- Ready for feedback [ENH: Display the number of output features](https://github.com/scikit-learn/scikit-learn/pull/31937).
- In progress ~~Feedback needed~~ [ENH Display fitted attributes in HTML representation](https://github.com/scikit-learn/scikit-learn/pull/31442)
- This has 1 Approval already: PR corrects ColumnTransformer dotted-line. [FIX remainder parameter for column transformer visual block](https://github.com/scikit-learn/scikit-learn/pull/32713)
- Ready for feedback. [Remove CSS template substitution in estimators' HTML Display](https://github.com/scikit-learn/scikit-learn/pull/32839)

### Needs attention/decision

- [name=Christian] RFC make response / inverse link / activation function official[Issue#29169](https://github.com/scikit-learn/scikit-learn/issues/29169)
Is it still the consensus? Not that somebody gets frightened if a PR implementing it pops up.
- [name=Gael] I'm +1 on making the inverse link function public, but no change of public API / deprecating

- [name=Gael] Gathering user feedback / point of view on our API changes? (eg changes in linear model API which got bad rap on Linkedin, or moving away from accuracy)
- [name=Dea] Is this the post? https://www.linkedin.com/posts/carl-mcbride-ellis_datascience-machinelearning-activity-7404958491892875264-HEp9?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAdeyYBuYY8ZK4lVYO6GfBQ-Lb7_nfnLNw

### Broader discussions

- [name=Gael] Growing the comm's team

--------------------------------------------------------------------------

## November 24, 2025 @ 4pm CET

### Updates

- [name=betatim] Inclusion criteria now includes a "wikipedia rule"
- TL;DR: "don't propose work/algorithms that you (your friend, boss, partner) invented"
- https://github.com/scikit-learn/scikit-learn/pull/32663

- [name=Loïc] quick [dashboard](https://lesteve.github.io/scikit-learn-website-analytics/pyodide-build/dashboard.html) to make scikit-learn.org stats more easily available and usable. [repo](https://github.com/lesteve/scikit-learn-website-analytics) if you are curious.

- [name=Loïc] Update regarding the 1.8 release
- RC planned beginning of the week
- release planned begining of December to have a bit of leeway before Christmas break (just in case we need a quick bug-fix release)
- Discussion on better communication around the release
- consensus ended up being: add release manager and release date in the monthly meeting template (done at the top)

- [name=Dea] Kaggle docker-python developer commented [Bump scikit-learn version from 1.2.2 to 1.7.2](https://github.com/Kaggle/docker-python/pull/1513#issuecomment-3513173265)

### Topics

- Focus groups [name=betatim]
- can we announce the topic for focus group n+1 when focus group n starts?
- suggest your idea for a focus group topic here: X, Y, Z
- do the following board would help: https://github.com/orgs/scikit-learn/projects/24
- Currently active focus groups:
- array API (many active people): https://github.com/orgs/scikit-learn/projects/12
- Olivier / Antoine: [tree-based performance evaluation and comparison](https://github.com/orgs/scikit-learn/projects/26) with xgboost and co.
- EOSS topics:
- [Callback API](https://github.com/orgs/scikit-learn/projects/8): Francois, Jeremie
- [Improve Display]([Link](https://github.com/orgs/scikit-learn/projects/10/views/2)): Lucy, Jeremie, and Guillaume
- [Estimator UI](https://github.com/orgs/scikit-learn/projects/9): Dea, Guillaume

- [name=Loïc] Reluctance from a few maintainers to open a new issue because people jump on it with "can I work on it". What about having a "Not open for contribution" label on new issues? The maintainer on triage is supposed to remove the label when things have clarified and when we actually would welcome a contribution? This feels a bit sad but necessary ...
- "needs decision" label now triggers a bot that comments

- [name=Loïc] 3-tier system for estimators to help resource allocation/priority setting?
- Tier1 would be what we should focus on, important estimators that we know are useful and used. I think there is a broad agreement on this amongst maintainers. For example `RandomForest*`, `HistGradientBoosting*`, `LogisticRegresion`, `Pipeline`, `ColumnTransformer`, etc ...
- Tier3 would be "no new feature", "no bug fix", however easy they are. We can use the website + maintainer agreement to decide.
- Tier2 would be the rest, big list, maybe "no new feature, only bugfix" rule of thumb, except in special cases.

[name=Christian] Some thoughts about a tier system:
- What about first the vision, then the mission, then the priorities? We had a shy start with the vision some time ago in https://hackmd.io/H_CrV5OvSYiJVI-kWEg8ow.
- What impact will a tier system have?
- Shouldn't we always accept bugfixes? Otherwise we could remove the functionality altogether, IMHO.

- [name=Christian] Announce paid work (like grants) for scikit-learn on the blog, always. Consider making it a requirement.

- [name=Stefanie] in [#32680](https://github.com/scikit-learn/scikit-learn/issues/32680) we had been discussing on exchanging a few names of contributors who do a great job and whom we could collectively spend more attention (review faster, ping for opinions, ...)
- some names I'd share would be @virchan @EmilyXinyi @glevv @Tialo
- maybe we can find a (easy to keep) format to regularily add and remove names (edited)

- [name=Olivier] array API and Cython code duplication. Known examples:
- loss functions (`LogisticRegression`)
- k-means (not started)

### Needs attention/decision

- [name=Christian] Deprecation of `penalty` in `LogisticRegression` [PR#32659](https://github.com/scikit-learn/scikit-learn/pull/32659).
This includes change of default `l1_ratio=None` -> `l1_ratio=0`.
What about `l1_ratios` in `LogisticRegressionCV` (keep in mind the change with `use_legacy_attributes`)?:
1. Change default from `None` -> `(0,)`
- This also changes the shape of some attributes (adds a dimension of shape 1).
2. Change default from `None` -> "warn"
- This is then different to `LogisticRegression` for 2 releases.

Option 2 it is.

- [name=Christian] Array API for LBFGS solver in LogisticRegression [PR#32644](https://github.com/scikit-learn/scikit-learn/pull/32644)
Christian's concern: Huge maintainability impact (=duplication of `_loss` module). Options should be discussed first.

- [name=Christian] RFC make response / inverse link / activation function official[Issue#29169](https://github.com/scikit-learn/scikit-learn/issues/29169)
Is it still the consensus? Not that somebody gets frightened if a PR implementing it pops up.

### Action items

### Archived meeting notes:

- https://github.com/scikit-learn/administrative/tree/master/monthly_meetings

### Next meeting

Automatically configured as a recurring event on the shared calendar:

- https://blog.scikit-learn.org/calendar/

## October 27, 2025 @ 4pm CEST

### Updates

- [name=Guillaume] upcoming release 1.8 in November

### Topics

- [name=Olivier] Security hardening via isolated release workflow in NumPy (done) and SciPy (WIP):
- https://github.com/numpy/numpy-release
- https://github.com/scipy/scipy-release

- [name=Adrin] docs repo size
- it's been tricky, might require a non-shallow clone (100GB)
- might require deleting the `scikit-learn.github.io` repo and creating a new one / renaming one
- https://github.com/scikit-learn/scikit-learn/issues/32562

- [name=Olivier] Bi-weekly task force organization to advance stalled high priority roadmap items.
- First iteration: Antoine and Olivier focussing on comparing scikit-learn tree based models vs xgboost/lightgbm/catboost on different datasets with different shapes.
- [name=Tim] what is on the roadmap?
- plan which months will be focussed on several months in advance
- idea: announce every 2 months what the focus topic is for the next block and what the topic will be for the next-next block
- For example
- next: tree based models (Nov and Dec)
- next-next: linear models (Jan and Feb)

- [name=Tim] Update the version of scikit-learn in Kaggle
- does someone want to tackle this?
- https://github.com/Kaggle/docker-python

### Need attention/decision

### Action items

### Archived meeting notes:

- https://github.com/scikit-learn/administrative/tree/master/monthly_meetings

### Next meeting

Automatically configured as a recurring event on the shared calendar:

- https://blog.scikit-learn.org/calendar/