Find maintainers and reviewers

[dlfivefifty]

It would be nice for SpecialFunctions.jl to be a general home for Julia implementations of special functions. So I would propose renaming the current version of this package as OpenSpecFun.jl to emphasise its meant to focus on being a wrapper, and creating a new SpecialFunctions.jl that can incorporate OpenSpecFun.jl, Julia specific implementations, and perhaps other packages (HypergeometricFunctions.jl)

See discussion #175 (comment) and #196

[giordano]

Apparently there was already #112 😅

[musm]

I think there's a bit of confusion regarding this package and it's focus/structure.

I'll try to clarify.
The primary purpose of this package is to hold special functions to be available to the whole community, full stop. Ideally these would be in pure Julia, and in fact some of the implemented functions are, but other are not. This is not because we don't want pure Julia implementations, but rather it takes time to do the ports and verify their accuracy and speed (this is a slow process in general).

As to your suggestions: It's better to create a new OpenSpecFun.jl which would be a pure wrapper for OpenSpecFun. This would allow those who prefer that library to use it with confidence.

Thus I see no benefit to fragment the current situation.
The way I see it: leave the current package as is. It already holds a variety of code. Some of the functions are wrappers over OpenSpecFun, other's are in pure Julia. As mentioned, we welcome PRs to transition to Julia and new additions. I agree it's unfortunate that some PRs haven't received the care and attentions they deserve, but this is simply due to a lack of resources and time from maintainers.

E.g.:
#196 (just needs a rebase)

[dlfivefifty]

OK so that clarifies it, sorry, there seemed to be confusion in opinion. I'll close this issue

[ViralBShah]

My main concern arose out of current maintainers not having time for this package. I think the right thing here is to use this issue to identify new maintainers who are qualified to review the PRs and keep things going.

@dlfivefifty Perhaps we can leave this issue open with it being a call for additional maintainers?

[ViralBShah]

I think separating out the current functions into OpenSpecfun.jl would mean it will break people's codes. So perhaps that is not a good idea - unless the new SpecialFunctions.jl maintains backwards compatibility by importing all of OpenSpecfun.jl and re-exporting it. I don't think it would be terribly useful.

So the more I think of it, the real issue is to find new maintainers who can help move this package forward.

[musm]

Another thing to keep in mind. Some PRs are not ready to be merged and still require the author to make changes before merge. We've seen this in several PRs. We've also seen PRs that are not at the standard required before merging into the code base.

@ViralBShah Also consider, it's not like this package is crumbling and bit-rot. We currently have a relatively small number of issues and PRs that need some finalization. The package on the whole, has been working well for quite some time, so I don't think we should jump to too broad conclusion.

[ViralBShah]

@musm Thank you. It is good to learn so - and perhaps also good to have this issue for future contributors. I also know that people sometimes make a PR, and are requested to update it, but do not get around to it for a long time.

[dlfivefifty]

Yes I agree with @musm that there are some questions on the quality of some of the PRs. Though if you look at #175 which would be useful for many it is stuck on "Awaiting Reviews" stage.

Perhaps "Find reviewers" is a more appropriate name? I can review that PR as OPs fall under my expertise.

[musm]

@dlfivefifty Thank you very much. I agree with that PR, it's quite good already, just needs another set of eyes. Please if you have the time, we would love that. You have very strong expertise in this area so your contributions in any front would be very helpful.

The two PRs we can merge soon: are indeed #175 (after your review)
and #196.

[giordano]

As I already said in #196, I agree with @musm that I think this package should provide special functions to Julia packages, no matter how they're implemented, but of course a generic Julia implementation would be the ideal option. I also agree that this package seems to be stalling because of lack of time/resources, so I don't see how splitting into another project would solve this issue.

[dlfivefifty]

OK I made some request for changes, that PR still needs some work. Let's see what happens.

Let me ask NIST (the people behind DLMF) if they have anyone interested in Julia who'd like to contribute.