Working Group Setup Checklist
When new working groups are funded, our team takes a number of setup steps to to help new groups 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.
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 yourself, 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 them 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.
Rationale: GitHub Teams centralize all group members’ GitHub identities. This makes granting an entire group access to multiple repositories really simple. It also only requires a single invite rather than one per repository as is the case with per-repo invites.
Naming Convention:
- “lter / lter-wg_<abbreviated-group-name>"
- “lter / lter-sparc_<abbreviated-group-name>"
Note that the group abbreviation should be entirely lowercase.
Other Notes: Make the group’s team as a “sub-team” of the “working-groups” team (it’ll keep the top-level “Teams” view nice and tidy). Add the group’s repository to that team and grant the team “Maintain” access. Offer “Admin” to the PIs but emphasize it will grant them destructive setting power as well. If PIs want admin power, direct add them to the repo and grant them specifically admin power; if you grant admin power to the team, you’re giving it to a lot of people who don’t need/want it.
If the group is going to do a lot of very computationally-intense work, consider getting them an account on Aurora. For most groups, this is not necessary! If it is needed, contact Thomas Hetmank or Nick Outin to get a “team” set up on Aurora for the working group. Note your Aurora user should also be added to all working group Aurora teams.
Attend LTER Onboarding Meetings
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.
You’ll introduce the group to all of the infrastructure you created so be sure to do that before this meeting! Give the attending group members “homework” to collect Google Drive-enabled emails and GitHub usernames and send them to you so you can add them to the Google Group and GitHub Team respectively.
This is also the start of your working relationship with the group so it’s important to put your best foot forward! Try not to get too technical as there is a dedicated tech onboarding you’ll schedule with groups.
When in doubt, consult with Marty Downs about how in-depth to go in this meeting!
After the group has done the Network Office onboarding, schedule a time to do SciComp specific onboarding. Ask PIs to extend the invite to any particularly tech-savvy members and/or people likely to have a significant amount of input in tech decisions.
At this meeting, you should do the following during this meeting:
- Review the types of support our team offers
- Re-share the infrastructure you made for this group
- Ask if they have any known trouble spots where you can be of service
- Ask if they have any trainings they want
- To your comfort and capacity, you can offer to create new trainings for groups, but the existing ones (especially the Collaborative Coding with GitHub are ready to go and are really well-received/useful)
- Leave the majority of the time for this meeting to discuss the group’s needs, wants, and questions.
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.
Lay Your Documentation Foundations
In our GitHub Project create an issue for supporting this group and open a sub-issue with the “Group Onboarding Template”. That issue template includes most of what is explained above and will be a strong start for your support of this group!
From here on out, whenever they ask for something that is more difficult than a chain of emails, open an issue as a sub-issue of that group’s primary issue and document your entire process for solving that issue. This stuff is difficult to create after the fact and only a little time-consuming to do when you first receive a task from a group.