New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find maintainers and reviewers #213
Comments
Apparently there was already #112 😅 |
I think there's a bit of confusion regarding this package and it's focus/structure. I'll try to clarify. As to your suggestions: It's better to create a new Thus I see no benefit to fragment the current situation. E.g.: |
OK so that clarifies it, sorry, there seemed to be confusion in opinion. I'll close this issue |
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? |
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. |
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. |
@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 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) |
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. |
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. |
I've invited @dlfivefifty to be an owner in this org, and also updated @musm to owner. |
An argument for creating a separate package OpenSpecFun.jl is that it can probably be a 1.0 package that isn't changed, whereas SpecialFunctions.jl may have many tags if new Julia implementations are added. |
I think so long as people using SpecialFunctions do not have their codes break, it would be fine to do that. |
I'd like to help developing this repo any further. Who should I talk to? What's the preferred way of communication? |
The preferred way of communication is with issues and PRs. If you want to become a maintainer, that generally only happens after you have non-trivial PRs accepted. |
Not sure if we have something actionable here - since the discussion has run its course. |
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
The text was updated successfully, but these errors were encountered: