2020-08-24 Core Developers Meeting notes

Date

Aug 24, 2020

Participants

  • @Jeffrey Wagner

  • @Matt Thompson

  • @Simon Boothroyd

  • @David Hahn

  • @David Dotson

Discussion topics

Notes

Notes

  • DH – Not much new. Took 1.5 days off last week. Worked on manuscript. Prepared new input files.

  • SB – Rewrote pAPRika integration. Looking at using WBO BCCs. Bits of writing.

  • MT – Trawled the issue tracker. Black and isort PRs merged. Partial review of vsites, mostly smaller things. Looked at a bit of DH’s code. Wardley mapping for system object. Worked on exception overhaul. Got stuff close to finish line and documented questions.

    • JW – Let’s just delay 0.8 to “the first Monday after vsites gets merged”

    • MT – Accessible 9 AM to 2 PM for synchronous chats. Unlikely to have internet before/after that.

  • DD – Worked with SB, DS, JS to get pAPRika and taproom updated. SB did a huge amount of work. Will review pAPRika PR today and tomorrow. JH is rpeparing disaccharide submission – few thousand conformers. TG has proposed more comprehensive standards (including version) for QCA dataset submission and infrastructure. I drafted “compute expansion policy”, where you add more compute (like, different basis sets/methods) to an existing dataset. I started preparing a new submission procedure document (“So you want to submit computations…”). Helped push 0.16.0 QCEngine release, which supports ANI2x. Will update docker compute to get PRP back online. Waiting to hear from JC about lilac issues.

  • JW – Time to reflect on division of labor? Vacation/outage planning? Gave up on CHARMM-GUI.

  • KCJ – Documentation part timer? Full time firefighter?

    • JW – Probably need a existing developer to have firefighter duty due to background knowledge requirement

    • KCJ – We should make sure that burden of firefighting is reflected accurately represented on roadmap

    • MT – Who should do firefighting? Should one person do it full time?

    • JW – Medium term, it’s probaby good for MT and I to hand off the hat every week or two.

    • SB – Can we make investments now to reduce firefighting in the future? We also have trouble prioritizing.

    • KCJ – Are we accurately identifying fires?

    • JW – It’s partially hard to identify when things are “urgent” or “easy” – Molecule class isn’t interoperable, scripts aren’t easy, bond WBOs aren’t high-priority relative to these thigns

    • KCJ – Industry people will understand prioritization. PIs may have unrealistic assumptions. Priority requires consensus.

    • SB – We should be more consistent with setting expectations. Pharma will expect stuff based on previous turnarounds. Can we have a more centralized place where feature requests are discussed and prioritized, so that this communication stays out of DMs?

    • KCJ – Lots of discussion happens in advisory board. I’ve tried to extract what they want in their workflows, but it’s general stuff like “conformer energies” and “free energy”. They’d also like conformer QUALITY metrics. Lots of requests are vague and interpreted by PIs. Few survey responses.

      • JW – Chemalot is a good roadmap for what to replace.

    • SB – Agree that pharma has trouble knowing/saying what they want. Can we ahve a place outside JW’s DMs where these discussions happen?

    • (General) – Feature requests/discussions should be pushed heavily to be public whenever possible

      • KCJ – JW should redirect these conversations to public channels, since we don’t know who will implement it.

      • JW – Agree

      • KCJ – This is a good case for discourse

      • SB – People can be hesitant to speak in public channels. We could have a semi-private channel for this sort of thing.

      • DD – In industry, there are client-facing roles for this sort of thing. Do we want to have a designated person on our team for this? KCJ?

      • (General) – Should have designated person to receive and triage these requests

      • DD – If I were a pharma partner, and I wanted to ask a sensitive question, I wouldn’t know who is going to be on which channel in the future. So my ignorance may be recorded for future users. So we could have a designated person to recieve these requests

      • KCJ – Agree

      • DH – Pharma partners may not know which channel to use.

      • JW – Do we want partners to get immediate responses?

        • KCJ – No. They shouldn’t have that expectation.

        • DD – “within one day” is pretty common practice. And saying “I don’t know” is fine

        • JW – Is there a category of topics where we would want a 5-minute turnaround?

        • KCJ – Not for people in different time zones.

        • SB – Also, documentation and examples will be preventative for this.

        • KCJ – This would be a good reason for a documentation person.

      • SB – More relevant examples will help a lot – Right now it’s a lot of “molecule in vacuum”, but we could find more popular use cases and make examples for those.

        • KCJ – We could have a week for this, and loop in pharma partners.

        • MT – Would be good to have deeper docs, “gotchas” page for various tools/workflows, might be a colminations of discussion from earlier in docs week.

        • KCJ – Docs person would be good – I have a former colleague who could be good for this.

        • JW – Docs person will require training/onboarding. We should make sure that we allocate core developer time to bring them on.

        • KCJ – Naive user will be good at seeing the important pitfalls and knowing what new users WON’T know.

        • SB – Agree. Will be valuable for devs as well.

        • JW – Agree that this is wanted, but I’m worried that this will become another “top priority”

        • (KCJ+SB) – We need to do internal refactoring and polishing before we make new features

        • SB – All infrastructure development should be initiated by a scientist being ready to run with it, with a minimum “notice required” like one month

        • KCJ – We’ve had trouble planning and sticking to milestones. But the first step to sticking to them is defining them.

        • MT – In a roadmap revision, we’d want to balance things more toward infrastructure. This would rein in tendency to overpromise on “compatibility with 10 ML frameworks”.

          • (General) – agree

        • MT – We have these vague clouds above our heads of “in the future, our FFs will do all these things”. But the roadmaps are ignored on a day-to-day basis. But if we want to have a “pharma feature request dropbox”, then we’ll want to have time budgeted on a big roadmap to take into account requests that pop up.

        • KCJ – I had hopes that roadmap would be a live document, where items are added/removed on the fly. But people are hesitant to put in the energy to do that. I’d like us to record what people are spending their time on. I’d love to have a time accounting on tasks so that we understand how to budget realistically in the future.

          • JW – Organizational issue – Academia has trouble saying “no”, easier to just not follow up on things

          • JW – Tried recording hours, it’s demoralizing, even when nobody looks

          • KCJ – We need to build toward a culture of saying no

          • DD – Can spread burden of saying no, feel free to call in backup.

        • DD – How do we give pharma partners what they need, PIs what they need, and the implementers what they need?

          • need thoughtful boundaries


          • need thoughtful flows for information, requests

  • KCJ – PIs are discussing how to better give (positive) feedback. Need to find a way to celebrate big milestones. Ideas?

    •  



Action items

Decisions