Page Comparison

Shirts lab onboarding

• MS – Dotson charge number approved. Little more onboarding needed

• MS – Thompson is basically standard lab member with different responsibilities. May be good to prioritize health insurance that serves broader network if we’re not sure when move to colorado will happen.

• MT – Sounds good. I have private insurance for the moment in Iowa.

• JW – Lab wiki/resources/OE license? Check ins?

  • MS – For MT, I will send link for research computing, wiki

  • MS – For Dtoson, I will ask about this.

• JW – I will manage infrastructure team work, but for admin stuff, it would be good to have a regular meeting between each of them and MS.

  • MS – I will be the administrative contact for both MT and DD. I’ll also be acting as a mentor for MT.

• (General) – Progress reporting?

  • JW – I want minimal structure on this initially, but we’ll have regular developer check-ins

  • MS – I don’t like hovering over everyone’s shoulder, but it would be nice to have some report

  • MT – I’d like to report 3-5 bullet points each day

  • DD – I do digital standups, basically report in a channel on daily progress

Made #check-ins

• Jeffrey Wagner Look into whether we can make howdy that populates #check-ins

MT – What’s best way to get in contact with MS

• MS – On lab calendar, I have blocks for “Michael available for individual research meetings”, feel free to add yourself 24 hours in advance if needed. I’m also responsive on email and slack.

MS – DD, you might be interested in dashboards for data. Look under #benchmarks channel

General onboarding

DD – Personal page and to-do list

DD – Github org

Technical onboarding

Added DD to Slack

• DD: starting with a schedule of 6:30-10:30 AM Arizona time for focused work, some availability outside of that

Confluence

• DD already made personal page, JW helped set up task list macro

• Something to look into sometime: how to add dates and priority to task list

Zoom

• DD might get one through Colorado, might need to find another way

JW: Goal for managing admin overhead with 3 software scientists is to distribute responsibilities

JW: Keeping DD out of most subgroup meetings for now, MT might join some. Inviting DD to property estimator call, MT and DD to openKim call

Added DD to GitHub org

There has been some friction/ambiguity about software quality in research code. Some students/postdocs are excited about software quality, others want to move quickly into the science. I’d like us to move toward a “Throw it over the wall” philosophy wrt scientific software developement – Apply minimum quality standard to postdoc/grad student code, but give them a lot of freedom outside of that. Once code is mature, they “throw” it to us, and we consider performing a major refactor in light of how it will be involved in project.

Dev docs plans and holdups

Draft documentation –

OE license decryption on master

•  

  Github link macro
  link https://github.com/openforcefield/openforcefield/issues/549

Making a development build

conda create -n off-dev2 -c conda-forge -c omnia -c openeye openforcefield openeye-toolkits
conda activate off-dev2
conda remove --force openforcefield
pip install -e .

Should we just provide instructions to install from environment.yaml in devtools?

Should we do install --no-deps?

Should we remove before pip install?

•  Matt Thompson may look into alternative (simpler or more reliable) dev build options, and add to dev docs branch

Do a PR live

We won’t actually do this – JW may have a patch ready to do this on tomorrow

Big picture – When assigned, try to review within 48 hours, and say immediately if that’s not possible so that another reviewer can be tagged.

Default to one reviewer, unless you know that the changes overlap several domains

Software scientists and Chodera should be the only people approving toolkit PRs

Convention – You can merge your own PR WITHOUT review if it’s just a cosmetic/typo fix. Otherwise always have one passing review. The SUBMITTER ALWAYS pushes the merge button, NEVER the reviewer.

• DD – We could schedule PRs merges based on release milesones, so that it’s clear when different features should be added.

• MT – We could separate dev and master branches

• DD + MT – This is what MDAnalysis does. We should look more closely at precisely how this works.

• Matt Thompson David Dotson Jeffrey Wagner will discuss git model for development/releases at a future meeting – Read https://nvie.com/posts/a-successful-git-branching-model/

JRW is release manager for OFFTK. MT will become release manager for System object.

Review guidelines:

OpenFF software

Status page – https://openforcefield.org/consortium/software/

Draft connectivity diagram – Not aspirational, but rather first draft of laying out FF optimization operation as of last June

• David Dotson Jeffrey Wagner Matt Thompson will produce a draft of an up-to-date infrastructure diagram

End of day 1

Software “health” in each area

Omnia recipes repo –

Important repo parade

• openforcefield (toolkit)

• openforcefieldS (FFs)

• smirnoff99Frosst (where we hammered on getting atom types right)

• Release-1-benchmarking

• Openforcefield-forcebalance (releases here can be used to reproduce FF fit -- Might consider rerunning -- This is in serious need of automation)

• Evaluator

• Nistdataselection

• Qca-dataset-submission

• openforcefield.org

QCFractal compute situation