Working Group Setup Checklist

Note

Please note that the following checklist of working group setup steps is meant to serve as internal documentation only! Our team will be taking these steps on your behalf when you are funded so none of these steps are things you (a working member/PI) need to handle.

Feel free to contact us if you find these instructions useful and want to apply them to non-working group contexts!

When new working groups are funded, our team takes a number of setup steps to create some of the infrastructure that past groups have requested/found useful. This is mainly an attempt to help the group avoid spending their precious in-person meeting time doing relatively dry technical steps that we can easily accomplish early-on. Some of these steps also set a useful ‘tone’ in terms of facilitating groups’ adherence to reproducibility best practices.

1. Attend LTER Network Office ‘New Group Onboarding’ Meeting

Once the decision is made for which group(s) to fund, Marty Downs will schedule an onboarding meeting for group PIs to talk about NCEAS / LTER Network Office resources. A SciComp team member needs to be there to give a brief introduction and pitch for the kinds of support that our team can offer.

2. Create the Infrastructure for the Group

Rationale: Google Groups centralize all group members’ Google identities. This makes sharing access to a piece of the Google ecosystem with an entire team really simple.

Naming Convention:

  • “LTER-WG_<Abbreviated-Group-Name>”
  • “LTER-SPARC_<Abbreviated-Group-Name>”

Note that the group abbreviation should be title case (e.g., “Ecological-Synthesis”)

Rationale: A Shared Google Drive is a great place to store raw data as well as preserve documentation and script outputs. A true Shared Drive also distributes ownership in a way that makes it safe even when individual Google accounts get deactivated (as is the case when someone changes institutions).

Naming Convention: Same as the Google Group!

Other Notes: Add the Google Group as ‘maintainers’ and add Marty Downs and Thomas Hetmank as ‘administrators’. Also, move copies of the critical LTER template Google files into the top-level of the Shared Drive. Groups are not required to use these but they generally have been useful to groups in the past.

Rationale: GitHub is the way we recommend collaborating on code. This emphasis is made more particularly clear elsewhere so we’ll leave it at that here.

Naming Convention:

  • “lter / lterwg-<abbreviated-group-name>"
  • “lter / lter-sparc-<abbreviated-group-name>"

Note that the group abbreviation should be entirely lowercase.

Other Notes: Create the repository in the LTER GitHub organization and use the working group template repository as the starting point. Add any usernames that you have from the group to this repository.

Don’t do this unless it is needed! The server is another account/login/workflow group members have to keep in mind. If you make this part of the group’s intitial infrastructure, you risk overwhelming them for the really vital stuff when the server is not always necessary for all projects.

If it is needed, contact Thomas Hetmank or Nick Outin to get a ‘team’ set up on Aurora for the working group.

3. Offer SciComp-Specific Onboarding

After the group has done the LNO onboarding, schedule a time to do SciComp specific onboarding. You’ll discuss the types of support the SciComp team can offer as well as the workshops we’re currently capable of offering. You’ll share the infrastructure you’ve made with the group.

Critically, ask the group if they have any tasks on their collective mind already!

Finally, if this onboarding meeting is for a SPARC group, reiterate that they get one (1) year of SciComp support but they choose when to start that clock. Some groups use the entire year before their in-person meeting while others don’t ask for support until after that meeting.