The only thing I was thinking about was if the plan is to release the SortingAnalyzer before the conference it might make sense to try to do these before the release, no? That way we get a bunch of "breaking" api changes all at once again. Or would we prefer to do the deprecation style of so that we don't really break the api?

if old_arg is not None:
    warn(xxx)
    new_arg = old_arg

Thanks @alejoe91! Looks great, one additional aim I might add would be to identify parts of the API that developers are not happy with / think could be improved in future. Then if there is consensus these could all be changed at the same time. This would help limit the number of tweaks needed in future.

As a user, I noticed that the input arguments of run_sorter and run_sorter_by_property could be standardized

My colleagues and I have noticed API inconsistencies and think this proposal is a splendid idea. I would like to contribute to this project in Edinburgh.

-Nikhil Chandra

Adding some data point, the functions for settings the probe, we have set_probe, set_probes and set_probe_group. The first and the third use the second, mabye that one should be private?

Related:
SpikeInterface/spikeinterface#1989

We have get_channel_property which duplicates get_property and there is no get_unit_property. I think it should be one way or the other.

Potentially interested in contributing during the hackathon 🙂

That's awesome @jakeswann1. Welcome aboard!

• Visualize/Vizualise: IMO we should stick to american english!

Great point. I'll watch out for it!

has_scaled vs has_scaled_traces

copy instead of the current clone for both recording and sorting objects:

https://github.com/SpikeInterface/spikeinterface/blob/70ebe171ba311ddb2c34cd2992c9a65875eedf1a/src/spikeinterface/core/base.py#L526-L534

Maybe between calculate and compute from compute_quality_metrics and calculate_pc_metrics

@alejoe91 @samuelgarcia Related to this, I wonder your thoughts on trying and set a date to 'fix' as best possible the API. I've found that API changes are quite disruptive to user workflows and can make updating to new versions a frustratin g experience. Obviously, it is not possible to fully fix the API and never change it again, but at some stage would be nice to review the existing API, make any last changes where desired, and following this have API stability a key goal. If for certain modules it's not possible to fix at present, this could be staged (e.g. io, preprocesing, sorting have fixed API. Motionion correction, postprocessing is currently in development).

On this, it could be cool to have a kind of SpikeInterface 'roadmap', laying out what are the long-term aims of the package as well as kind of shorter-term plan. For example what are the goals for the package in the next 6 months, 1 year, 2 years? API stability could be a potential goal on this. In general a roadmap can also be useful for getting feedback on what is / isn't useful for the community. What do you think?

I would recommend we move this over to the main repo just so this doesn't get buried after the hackathon. I think making a roadmap is a great idea. I think your idea of a couple zoom sprints could also be very cool to try to push towards api stability at least at the outer level.

do you want to open the issue or you want me to copy this over for us?