Versions Compared

Old Version 4

changes.mady.by.user Matt Thompson

Saved on

compared with

New Version Current

changes.mady.by.user Jeffrey Wagner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

\uD83D\uDC65 Participants

...

\uD83D\uDDE3 Discussion topics

...

ItemPresenter

Notes

10 minutes

MT – vdW methods and periodicity:

Github link macro
linkhttps://github.com/openforcefield/standards/issues/51
extendedfalse

  • MT – The straightforward solution is to do something like what we’d done with electrostatics. and split periodic and nonperiodic potentials.

  • JW – What would the vdW keywords change to?

    • MT – potential would stay, method would split into periodic_method and nonperiodic_method This should make us ready to switch to LJPME when the day comes.

    • (MT taking notes in a comment on that issue)

  • JW –

  • MT

15-30 minutes

  • – I’m

  • JW – Is there a case where users will get totally stopped in trying to do something like a vacuum simulation in AMBER by specifying this?

    • …

    • (General) – If that happens, there will probably be a workaround that experts would use anyway. So we should go ahead and draft

  • Pre-EP summary comment:

    Github link macro
    linkhttps://github.com/openforcefield/standards/issues/51#issuecomment-1659340028

Committee composition?

  • DM + LW – Change rules to majority?

  • JW – Have reviewer “pools” - like “technical” and “scientific”, requiring approvals from both?

  • MT – I’d like to make sure that we have organizational capacity to get changes through to the finish line. I think it’s too easy to let things lose momentum on GitHub. I like the idea of monthly meetings, which are cancelled ahead of time if there’s no agenda.

    • DM – Yeah, we’d need JC for that discussion.

JW/DM – Committee tempo/ procedures

JW + DM

  • Recap issues discussed previously in /wiki/spaces/MEET/pages/2590736396

    • Brief summary: Current process owned too much by infrastructure team, including:

      • (possibly) Define spec change

      • Review change, discuss spec change, answer questions, defend spec change, carefully consider all aspects

      • Get all stakeholders to agree/iterate to convergence

      • Implement

    • Creates perverse/adverse incentives: Requires a huge amount of work to define the work that needs to be done.

    • Possible new procedure:

      • The infrastructure team is only involved in review, final approval, and implementation; there needs to be another driver

        • Driver has the right to limit scope, e.g. “This is a good thing to consider but falls outside scope of current proposal; suggester can create new proposal and be driver on that”

      • Relevant committee commits to meet at some predictable frequency to make synchronous decisions

        • Meet monthly on recurring schedule and change voting?

        • Or meet one-off each month?

      • Batching small changes so a variety go into a spec update

        • e.g. Q4-2023 branch which will have several different EPs merged into it that will eventually go into next point release of section spec, e.g. 0.5, when quarter’s changes wrap up.

        • Proposed goal: Release once a quarter, but changes are approved and can be implemented once EPs merged.

    • Suggested monthly meeting

      • Should we change committee composition and/or requirements to make a recurring meeting? Or schedule one-off each month?


✅ Action items

  •  

⤴ Decisions

...