NEP Style Proposal System for SMIRNOFF Spec

[SimonBoothroyd]

Is your feature request related to a problem? Please describe.

Currently there does not seem to be a clear way to propose changes to, or track the history and discussions behind changes to, the SMIRNOFF spec. This can obfuscate in circumstances why parts of the spec are the way they are - whether by explicit design due to constraints of particular use cases, or simply by an oversight when implementing parts of the spec.

Describe the solution you'd like

One way to overcome this, making changes to the spec more clear in the future and enabling more robust feedback on planned changes and proposals, may be to mirror the approach taken by the 'NumPy Enhancement Proposal' (NEP) system.

A complete overview of how the NEP system works can be found here, however a SMIRNOFF Enhancement Proposal would likely constitute:

• submitting a draft SEP via a GitHub pull request (PR) to the relevant doc/seps directory based on a template similar to the NumPy one.
• discussion of the proposed SEP on the PR.
• creation of a reference implementation of the SEP to go alongside the SEP if the proposal looks promising.
• a review by relevant stakeholders + a vote on whether to accept / reject.

These PRs could be tracked within this repo, or a separate repo dedicated to the spec.

[mattwthompson]

Seems in general like a good idea to me, provided we hammer out some more of the details. It may also set a standard for better practices with our specs outside of SMIRNOFF, in order to avoid situations like a single developer independently and opaquely changing specs (i.e. something that I could find myself doing with the System object if left to my own devices).

I'd support this being in a separate repo as some other orgs have done with similar projects

• https://github.com/dask/community
• https://github.com/conda-forge/cfep
• https://github.com/numpy/neps

[j-wags]

I'm in favor of both the proposed process, and for making a separate repo for the spec. Tying spec version to the toolkit git tree made sense initially, but now it's weird that publication spec updates are tied in with our package release process.

[mattwthompson]

Follow-ups

1. Should we move the SMIRNOFF spec itself there?
2. Should we have one repo for tracking all specs/EPs/etc. across the organization, or split each of them off into a separate repo? This may seem trivial now but we're moving to have more specs than just SMIRNOFF in the near future (a System spec right now, likely others before too long). I would be in favor of housing them in a single location.

We seem to be nearing a consensus; if this is the case, I'll write up a rough template for SEPs by the end of the day.

[SimonBoothroyd]

We seem to be nearing a consensus; if this is the case, I'll write up a rough template for SEPs by the end of the day.

Before actioning this we would need to solicit feedback from a broader range of people as this will affect the consortium as a whole and there are several different stakeholders that this will affect.

For the template we should likely just base it off of the NEP, CFEP or PEP so probably no need to mock a template as of yet.

As this was my proposal I'm happy to take ownership of it.

[j-wags]

That sounds good, Simon. I'd be happy for you to take ownership of this! Some good stakeholders would be the PIs, Yutong, and maybe representatives from OpenEye/Cresset since they're integrating our code/reimplementing our spec.

[karmencj]

It's a really good idea to start defining and capturing these decision making processes and I'm happy to help set up a "technical committee" for this purpose, if help is needed!

[j-wags]

It seems that we're unsure how to move forward on this/who has the authority to make this happen. How about the following as a starting point for bootstrapping:

• There is now a SMIRNOFF steering committee. It is comprised of @SimonBoothroyd @davidlmobley @jchodera and @j-wags.
• Changes to the SMIRNOFF spec can only be made by way of a successful steering committee vote
• A successful "vote" currently requires unanimous consent of the steering committee.
• The steering committee structure/mechanisms/membership/voting procedure can be changed by a successful vote.

[davidlmobley]

That sounds perfect, @j-wags .

[jchodera]

+1 happy to a part of this

[SimonBoothroyd]

Closed by openforcefield/standards#1