Cookiecutter maintainership
j-wags opened this issue · 12 comments
We at OpenFF have been huge fans of the cookiecutter -- It has standardized infrastructure and training in our field to a huge degree, and I'm optimistic that this will be seen as a major turning point towards reproducible, maintainable comp chem software.
I'd like to ask about the governance/maintainership of the cookiecutter going forward. While its consistency is a strength, occasional changes will be needed to keep it from falling out of date. I recognize that changes will require updates not just to the code, but also to the educational material and documentation to keep it current, and that there are several stakeholders that need to move in unison.
At this point, we are weighing a few changes to all of the OpenFF repos (CI and docs on GitHub Actions/Pages, a different default style for docs, etc), and are wondering whether it will be best for us moving forward to make a fork of this repo, or if we can contribute these changes into the MolSSI cookiecutter and play a role in guiding and maintaining changes in the future. Forking the repo seems like it could hinder the field by making divergent sets of "best practices", so I'd prefer to avoid that. However, as we will likely continue to propose changes in the future, it will help our planning to understand the process for including changes here.
I'd be interested in MolSSI's thoughts on this, namely:
- Are there already plans for major releases or smaller changes in the future?
- Is there a defined leadership structure that we should engage with when proposing changes?
- Would it be desirable to have non-MolSSI organizations involved in consulting or voting on changes?
I'm not MolSSI, but my guess would be that suggested changes through PRs or discussion issues would be welcome, and any changes (for new projects — updating old projects is a different kettle of fish) too specialized to OpenFF could be an option in the cookiecutter control, as conda|pypi is now.
Thanks for the feedback. We'll angle towards the "add as an option" strategy with our proposals then, and we're open to helping with maintenance if the proposals add complexity.
I get the sense that some "options" may get too complex. Adding GH Actions CI (#95) is complex enough that the maintainers suggested dropping Travis+Appveyor entirely. Likewise, I'd be interested to know whether supporting docs configurations for both RTD and GH Actions/Pages would be too complex, and if we should just target one. But per the approach above, once we have the specifics of our docs proposal ready, we'll start a new Issue for how to transition to- or add it.
Generally, I'm interested in input from the MolSSI folks on the questions above (since this is under the MolSSI org). Changes here mean a lot for them, since they'll require updates in the curriculum for the Fellows and the education/workshop material. So, if we can make the changes more predictable, we may encounter less friction in the long run.
Leaving the Travis/AppVeyor files there is no problem. The only thing it'd need configuration is the README badges, but that's not too hard. I am more concerned with the maintenance burden, if anything.
What to do with GH Actions/CI/RTD are somewhat sideline issues. The core piece that is really important here is what is the governance of this repo? Is someone at MolSSI benevolent dictator for life, is there a governing board, or is it freeform of ideas and people? I think we are currently in the last option which I don't think is very sustainable and the governance needs to be clearly laid out.
When we originally transitioned this repo from my lab to MolSSI, it was with the agreement that MolSSI would actively maintain this repository. If that is no longer going to be the case, I suggest we transition it to the Open Force Field Initiative, where we have an active group of software scientists that rely on and can sustain this repository for the community.
Following.
I don't see a reason this could not be maintained at MolSSI going forward. I can volunteer to be the main point of control for this, similar to a BDFL, but not that restrictive. We want to encourage changes and updates to this project, so we are happy to see propositions and PRs/Issues.
The curriculum isn't as hard to update on this mater as you might think since the whole point of the cookiecutter is to embed most of that away from the user anyways.
What sort of changes are you wanting to make @j-wags and what needs do you think are not being met right now by us here at MolSSI?
@Lnaden: Would you be the only maintainer at MolSSI, or are there additional software scientists that would be expected to also contribute significant effort?
Yes, I can be listed as a maintainer. MolSSI still has every intention of maintaining this repository, and I don't think we've ever said or indicated otherwise. As @loriab said, we are open to changes through discussion issues and PRs :)
For the GHA question, I believe we've reached a good conclusion on that. GHA will be an option, along with Travis-CI at first. We can later switch to GHA entirely.
Apologies for the delay. So I think this can be closed, with the following resolutions:
Are there already plans for major releases or smaller changes in the future?
No, but they will be made as-needed
Is there a defined leadership structure that we should engage with when proposing changes?
Levi is BDF(The foreseeable future)
Would it be desirable to have non-MolSSI organizations involved in consulting or voting on changes?
Anyone is free to propose and discuss changes. Levi has final say.
What sort of changes are you wanting to make @j-wags
The biggest planned change is GH Pages support for docs. We'll open up a separate issue for that once it's specced out.
what needs do you think are not being met right now by us here at MolSSI?
So far all of our needs are being met :-) This is more of a forward-looking discussion, since we realized that our progress in OpenFF is frequently hampered by not knowing who is responsible for making decisions, so hard things never get done (see: OFF's number of open issues and PRs). So, when we started discussing the best practices we want to use for the next year and how to get them supported in the cookiecutter (or whether to make a fork), we had no way to estimate how much effort/time it would take to integrate changes here. So now that we have a concrete process to consider, I think we're good.