OFF-EP 0000

[SimonBoothroyd]

Description

This PR tracks the initial draft of this repositories contents. I opted to include the main documents in this PR rather than the main initial commit so as to avoid putting very WIP standards and procedures front and center from the start.

See openforcefield/openff-toolkit#741 for more details for the rationale behind this repo + PR.

cc @j-wags @mattwthompson @Yoshanuikabundi

Status

• Ready to go

[mattwthompson]

I've fleshed out a few more sections and tinkered with some details (in ways that may be personal preference and not consensus).

A major outstanding question from my perspective is how to constitute technical committees

• One overarching OpenFF committee OR one for each relevant domain (SMIRNOFF, molecule representations, etc.) OR a mixture of the two? It's tempting to think about elaborate administrative structures but the most efficient would probably be just to have one that covers the entire organization, akin to a steering committee.
• Should these committees be limited to "internal" people, i.e. OpenFF PIs, engineers, and scientists? I would think it's the responsibility of direct stakeholders to also consider external stakeholders, and therefore we would not need to directly involve many people in the process, but appropriately consider their needs while still holding the final approval power.
• What is the role of advisory boards in these decisions? I don't have a good sense of this but my guess is the answer to this question is similar to the answer above.

[j-wags]

One overarching OpenFF committee OR one for each relevant domain

Let's initially just assign the OpenFF governing board as the uber-committee, and let them decide the number/content of the subcommittees.

[j-wags]

I thought about this for a while and typed up a lot, but I think this is all too abstract until we start actually iterating. Because everyone's so busy, one thing I would change is to make it unambiguous who is required for a vote, at least until we reach our stride and can form subcommittees.

[davidlmobley]

In general looks good to me; I'm supportive pending minor edits.

[davidlmobley]

That is indeed tricky. No real suggestions if it's a community thing; maybe we can give some guidance about how long the feedback period needs to be or something?

[mattwthompson]

@davidlmobley - I've come around @j-wags's suggestion of starting with simple criteria, but doing so with the understanding that they may change once we try them out in practice. If you were confused about murky criteria for accepting EPs, you're not alone - the lack of concretely documented processes for PEPs becoming accepted seem to be intentional, and there's sometimes confusion from the community about who has the "final say" in any. (I'm not sure about the analogs for NumPy and conda-forge EPs.) So I think it's fair to not set our goals too lofty here but instead be flexible for future changes.

I think the path forward here to get approvalfrom the 4 current SMIRNOFF committee members (@j-wags, @davidlmobley , @SimonBoothroyd , @jchodera from openforcefield/openff-toolkit#741 (comment)) that this document is a workable starting point and this PR should be merged. From there, we can clarify as needed some of the remaining details (the roles of the governing board and other other committees, processes for OFF-EPs being approved, etc.) as changes to this EP or new EPs. This would also let us act on updates to the SMIRNOFF spec, which was discussed several months ago as the rationale for all of this. This is somewhat timely as we want clearly-documented spec updates to help with some corner cases that have been plaguing the toolkit lately (openforcefield/openff-toolkit#716, openforcefield/openff-toolkit#882, openforcefield/openff-toolkit#734, probably more coming down the pipeline with other infrastructure work and some users doing experiments with non-bonded functional forms) and better ways of incorporating feedback in general.

[mattwthompson]

Tracking approval here:

• @davidlmobley
• @jchodera
• @j-wags
• @SimonBoothroyd
• @karmencj

[SimonBoothroyd]

Because OFF-EPs may also track procedural or community based changes I've added @karmencj to the approvers list and modified the acceptance criteria to a simple majority. The main rationale is that not all of the approvers will need to be involved in all OFF-EPs (e.g. I'm sure @davidlmobley and @karmencj will not be particularly interested in certain software specific OFF-EPs.)