How should this package be structured?

[RaphaelS1]

Currently the way development is going I'm going to grow the package very quickly and then prune back, which may be sub-optimal. So instead I'm thinking about ways to more effectively grow. I'd love to hear feedback from the community about what would be most useful. One suggestion I have is the following:

• SurvivalAnalysis.jl - Base features including prediction objects, surv objects, transformations, plotting
• SurvivalMeasures.jl - Metrics for evaluation
• SurvivalModels.jl - Models for analysis (this could act as a unified interface for future PRs for any and all models)

I also planning on integrating the package with MLJ so some components will lie there. I'm also planning on adding a Bayesian interface which could either go in the main package (as it should be fairly agnostic to individual choice), or in the models package, or in it's own SurvivalBayes.jl.

[rikhuijzer]

Currently the way development is going I'm going to grow the package very quickly and then prune back, which may be sub-optimal.

I never thought about it like that and to me that sounds very good 👍 Also, in my experience, trying to get everything right immediately will most likely ensure that nothing gets done since it is too overwhelming and the fear of pushing breaking releases is too big. You can either please the few people that use the package already by not introducing breaking releases or please future users by making the API simple

I also planning on integrating the package with MLJ so some components will lie there.

You can add MLJModelInterface to this package. It is very lightweight so shouldn't add to much loading time to people who don't want to use it. For example, see LightGBM.jl or StableTrees.jl.

[RaphaelS1]

You can either please the few people that use the package already by not introducing breaking releases or please future users by making the API simple

Yes I think this is a good way to think about it. I got some good advice from a developer about their experience with over-growing packages, and basically just saying that they got overwhelmed themselves! Do you think one is better than the other? I can see an argument that it's better to please future users as it's more important for them to stick around.

You can add MLJModelInterface to this package. It is very lightweight so shouldn't add to much loading time to people who don't want to use it. For example, see LightGBM.jl or StableTrees.jl.

Amazing and thanks for the tip - this is definitely my plan for the future but will depend on developing a good user-base. I can't code all the survival models myself!! One day I'd like to have the full collection I've collated in the mlr3 universe

[rikhuijzer]

Do you think one is better than the other?

It depends probably. I was having overly conservative developers in mind which I think is likely to cause a continuous problems in the long run. Hard decisions; easy life. Easy decisions; hard life. Your idea of expanding rapidly and then pruning sounds really clever.

One day I'd like to have the full collection I've collated in the mlr3 universe

I love such big plans 🚀🚀