From writing the extension template, I noticed some issues which we need to take decisions on.
Some parts of current architecture complicates the extension contract, or makes it unclear.
Discussion points:
bootstrap has boilerplate, such as test_size which requires every implementer to write repetitive code. I would suggest separating bootstrap and _bootstrap, like in sktime the fit/_fit.
in particular, I do not think that test_size should be an arg of _bootstrap.
get_n_bootstraps has an argument groups that I do not understand - it does not appear in bootstrap, so it feels superfluous, or inconsistent.
we should think about the tags we need and tags that might be convenient for lookup.
Some tags that might be useful are related to signatures, perhaps, about whether y is required, or whether return_index is available.
other tags are related to packaging, e.g., author and maintainer tag
similarly, what should happen if capability:multivariate is false? Should we broadcast, or should we raise error?
From writing the extension template, I noticed some issues which we need to take decisions on. Some parts of current architecture complicates the extension contract, or makes it unclear.
Discussion points:
bootstraphas boilerplate, such astest_sizewhich requires every implementer to write repetitive code. I would suggest separatingbootstrapand_bootstrap, like insktimethefit/_fit.test_sizeshould be an arg of_bootstrap.get_n_bootstrapshas an argumentgroupsthat I do not understand - it does not appear inbootstrap, so it feels superfluous, or inconsistent.yis required, or whetherreturn_indexis available.capability:multivariateis false? Should we broadcast, or should we raise error?