2020-11-12 All-hands meeting notes

Authorship

• Force field authorship – suggestions

• JW – As a software scientist, I do not want to be ahead of any project. It should probably be grad students and postdocs listed as authors 1, 2, 3.

• SB – Author lists of minor versions vs major versions of force fields. Minor release might not warrant first author publications, despite someone putting a lot effort into it.

• MT – Could direct people to cite both major and minor versions for the FF they used

• OM – You can ask people to cite in any way, but whether people will actually cite it is a different thing. For example, citing the last publication.

• SB – Agree. I generally just cite the latest available.

• DM – CrediT taxonomy is a nice aspiration, but the people who SHOULD read it frequently don’t. So we DO want to follow it, but also take into account the individual contributions and people’s career plans.

• JW – Minor vs major releases is a tough question. We get to pick how Github links to Zenodo records and we can make Zenodo authors match up to paper authors. It can also

• KCJ – Could ask people to cite two things: “Big” list, from something like the most recent formal publication, and “small” list, from most recent FF release.

• DM – CrediT Taxonomy might actually help here – We could use their categories to keep track of how long different contributors stay on publications.

• SB – I’m in favor of a large list. But at some level re do need to re-evaluate every time.

• JW – Could permanently keep anyone who was ever involved

• KCJ – Agree. Top authorship could go to major recent contributors, but everyone else could be listed after that.

• DM – If this goes on for 5+ years, our author list could be in the hundreds. Also, grant agencies will prevent you from reviewing anyone that you recently published with.

• JW – Option 1) I make a list of authors every time, which I don’t mind; 2) have an existing list of authors; 3) scrap Zenodo authors

• DM – Option 4: Everyone who’s ever been involved with an “opt-out” list or duration.

  • SB – Agree

  • JW – Agree

  • (General) – No objections

• KCJ – Parsley blog post should have instructions for “how to cite”

Confluence opening and restructure

@Karmen Condic-Jurkic

• Opening Confluence to general public

• JW – 1) There are a few successful OS projects who share their meeting notes and displays their struggle on some topics and that has changes my perspective. 2) The issues and other stuff we find and document on Confluence are more a feature than a bug.

• DM – Downside is that people may not upload/share things as readily if they’re concerned about scrutiny. This would impede coordination.

  • SB – Agree. When I post something publicly I generally ensure it’s of a high quality. I’m in favor of opening some spaces, but having many pages be private.

• KCJ – It’s not too difficult to move things between spaces Except blog posts.

• DM – Could have an OpenFF “Internal” space.

• KCJ – This would mix up our ability to find important documents.

• DM – I think these are the two choices: Either stay as we are, or accept some organizational cost to separate public/private info

• KCJ – We should prioritize getting people to document their work, so if this will reduce that, we shouldn’t do it

• MT – I think it’s worth having many things be public, with identified places for private documents. It will add some decision burden when taking/organizing notes.

• KCJ – Agree that it will add a decision burden or make people double-guess. Maybe we could restructure spaces (this needs to be done anyway) to better enable a public/private split.

• JW – I’d be happy to open up infrastructure space, which I think it’s pretty well baked and there’s nothing too horrible in it, but keep the other spaces for now. We can sit on this decision for a while and revisit again.

• MT – There are different levels of accessibility – People probably won’t know how to navigate confluence (or the way that WE specifically use confluence). Is the intent to make things passively accessible or actively distributed?

• JW – It’s a good question and I would put us in the first category (passively accessible). We have a perfectly good website to publish more polished content.

  • DM – Agree. This should be passively accessible info, and things that we want to actively distribute will go on the website/twitter/etc.

  •  

• KCJ – OpenFF confluence comes up in search results, but it’s very buried in the results. Would we advertise the link on the website? Would we send the link to people that want it?

• MT – Linked somewhere from the website, easy to find if you’re looking for it, but not heavily advertised.

  • JW – Agree

• JW - We can vote on opening Infrastructure, which I think

• KCJ – Keep Force Fields open?

  • DM – Could notify people that Force Fields is open and let them migrate sensitive info elsewhere

  •  

• Should whole spaces/project areas be open by default?

  • JW + DM – Yes

  • KCJ – I’m not sure. This will put additional burden on people doing everything (eg. drafting meeting agendas, sketching quick notes), and that will add up.

  • DM – Maybe we should step back and come up with more pointed options, and then vote on them.

  • KCJ – Agree that more fine-grained options would be good

  • MT – My experience has been that “optional” things that require any level of polish never actually get completes / are deprioritized

  • JM – Agree with DM + JW

  • DD – In working with partners on benchmarking, we had trouble with Confluence access (we started on Infrastructure, but had to move to Public). Now that they have access we’ve had positive feedback about it.

  • DC – Our main product is force fields, the codes that make them, and conversion machinery. I think it’s really important that FF parameter science, validation benchmarks be open. Beyond that, I’m not sure that there’s much value in having people see meeting notes. There is a lot of irrelevant information that would make the useful info hard to find. We’re well short of the line of being harmfully secret about our science, and more information might make the useful things hard to find. Beyond the artifacts that we already produce, I don’t think that we have a pressing need to make things more open.

• DM – We certainly don’t want to make everything public, I’m more concerned about community building and what Jeff mentioned about seeing the processes behind building a force field (or infrastructure). It might help some people who might get involved from tangential pathways. It’s easier if I could point interested folks to a collection of pages with useful information.

• JW – I would also make a timing argument, depending if we are on “everything is on fire” mode. At the moment, we have a calmness to make this decision whether to open Confluence or not. Being open is hard to measure and prioritize, but we make a policy that we don’t have to revisit and measure often, but sets up for success.

• KCJ – I think our next step is coming up witha more specific plan and put it up for a vote. I agree with DC that not everything that we’d release has value, and want to make sure we get feedback from the internal team about how their work would be affected by publicly releasing info.

• JW – Would I be within my rights to open up Infrastructure?

  • DM – Get agreement from everyone with content on there.

• (General) – Which spaces should be open?

  • KCJ – Mature projects could be open, exploratory projects would remain closed.

  • (General) – Personal spaces, Organization, and maybe things like Chemical PErception would remain closed.

  • JW – Would be good to open up Benchmarks, since public trust of our results is highly valuable.

•