Hi everyone, I would like to propose that we endorse some SPECs: https://scientific-python.org/specs/ https://scientific-python.org/specs/ There are some confusion about SPECs and what endorsement means, so let me clarify its meaning. Endorsing only means that we think something is a good idea and we would try to have a version of that on our side. It is not a binding act which would force us to do things a certain way. E.g. SPEC 0 defines a policy around minimum supported version and gives a timeline for dropping support. NumPy has a different timeline with NEP29. This is perfectly fine and does not prevent them to endorse SPEC 0, which they do. The parallel I could give is the difference between EU Regulations and Directives. SPECs are more like Directives meaning that it’s up to the project to see how they would in practice do something. The SPEC is at most proposing a framework or template. Note that SPECs cannot see major changes in their writing without consulting first with the community, the core projects who endorsed them and the SPEC’s steering committee. From SciPy’s team, Stéfan, Ralf and myself are on the committee. https://european-union.europa.eu/institutions-law-budget/law/types-legislation_en Types of legislation | European Union european-union.europa.eu https://european-union.europa.eu/institutions-law-budget/law/types-legislati... Specifically, I would propose that we endorse the following: SPEC 0 - Minimal supported versions: NumPy already endorsed it and their implementation of it is NEP29; SPEC 1 - Lazy loading: the SPEC is explicitly showing how we added support in SciPy (we use the __getattr__ and __dir__ mechanism); SPEC 4 - Nightly wheels: we are effectively doing this and are even using the proposed community org on Anaconda. If we agree to move forward, I would open 3 different PRs on the SPEC’s repository to state our endorsement. I would add maintainers who express interest and +1 as co-authors of these PRs. Thank you all in advance. Cheers, Pamphile