-
Notifications
You must be signed in to change notification settings - Fork 7
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
Transferring this package to arviz-devs org #25
Comments
@sethaxen To clarify, is the goal of |
Yes, and no. Yes, ArviZ.jl will become pure Julia (maybe using Requires to connect to Python ArviZ for e.g. those who want to analyze PyMC3 traces in Julia). More specifically, it will become a small ecosystem of pure Julia packages that can be independently used irrespective of ArviZ.jl, and ArviZ.jl will be a one-stop-shop for using these packages together and serve as an integration test. But RE API, there's a balancing act. I'd like for ArviZ.jl's API to facilitate Python PPL users trying out Julia PPLs by being able to almost re-use their existing Python ArviZ analysis code. But ArviZ's API also feels very Pythonic, and we also want ArviZ.jl to be Julian. So there will definitely be cases where we depart from the Python ArviZ API, but consistency will definitely be one dimension considered in design. |
I'm open to transferring it to an organization. Actually, I would like to transfer it to TuringLang, both to make it "more official" and since I'm on parental leave until mid of next year and probably more people watch and help out in TuringLang packages than in packages in my user account (I still try to review PRs timely but I might not manage to work on time-consuming refactorings or additions myself). I think currently TuringLang makes most sense: The package was extracted from MCMCChains, a core package in the Turing ecosystem, and it is central to MCMCChains. In fact, only MCMCChains and ParetoSmooth depend on it directly: https://juliahub.com/ui/Packages/MCMCDiagnosticTools/pEXcT/0.1.1?page=2 I think it would be great to have a pure-Julia ArviZ.jl and to reuse components such as MCMCDiagnosticTools in the ecosystem. It's great if you have funding for improving ArviZ and I understand that you want to show progress to funders, but since there are no major contributions in this package from ArviZ devs yet and it's not integrated with ArviZ I don't think it should be transferred to arviz-devs currently. I'm open though to transferring the package if this situation changes 🙂 |
First, congrats! And wow, what a nice parental leave! 😃
ArviZ.jl doesn't use this package yet because #4, #10, and #22 have been finished. That's part of the planned work for this funding. I understand your reasoning, and those are all good reasons. As has been discussed in the linked issues, the arviz-devs org is devoted to PPL-agnostic diagnostics and visualizations and to first-class Julia support, so it is in a sense the ideal home for a package like this, and this was part of my motivation for suggesting this package (TuringLang/MCMCChains.jl#266).
Let's revisit this then after I have made the planned contributions. I am of course hoping it transfers to arviz-devs in the end. |
This is less of a priority now. Thanks to MultiDocumenter it is possible to seamlessly include MCMCDiagnosticTools in ArviZ docs, so it's clearer that contributions to this package are also contributions to the ArviZ project. Only, it might be nice to include a brief package description in the docs that could describe the scope of the package and mention that it is a collaboration between Turing and ArviZ devs. |
I have a grant in the new year to continue refactoring ArviZ.jl into an ecosystem of diagnostics packages (see arviz-devs/ArviZ.jl#129, arviz-devs/ArviZ.jl#130), and part of the planned work is adding to/expanding diagnostics in MCMCDiagnosticTools (e.g. #4 #10 #22).
It's easier to show progress to funders if the contributions are to packages in the arviz-devs org. We had discussed some time ago the possibility of transferring MCMCDiagnosticTools to the arviz-devs GitHub organization (of course retaining your admin privileges). Is this something you're open to doing?
The text was updated successfully, but these errors were encountered: