GitHub and the working group – Part II

In an earlier post, I outlined my plans to try to teach and use GitHub for code related to our big Biodiversity Working Group. Feb 22-26, 20 members of the group met in Leipzig, Germany, and 6 more (including myself) participated remotely (#sChange on twitter). I felt this was a bit of an experiment, as our group is quite large, and I knew that the majority of participants would be novice git users. There is much yet to do now that the workshop is over, but after a week, I can definitely identify a few challenges and successes in using GitHub for our working group.

Challenges

1. More than half of our working group members had not used GitHub as a collaborative tool before, or had an only sort of heard of it, but didn’t actively use an account.
2. Deciding on the best organization that would work for everyone, while still taking advantages of the workflow and discussion opportunities GitHub offers, and avoiding overloading a single repository with too many large files or users with overwhelming complexities.
   • We generally stuck to the OrganizationTools guidelines that I outlined in my post a few weeks ago, with a few additions (list of working group members who could troubleshoot problems, details on folder organization, reminder to use `git pull` before `git push`, and a note about licenses).
   • A change in repo organization was to have a main working group repository for all developing code (since we weren’t sure yet how code would be broken out vs. shared among projects) instead of separate repositories organized around papers. Hopefully, this doesn’t become too confusing down the road.
   • Another change was to have 2 `code` folders in our main repository. One for code that is ready to be shared with the group, and one that contains “personal” folders for each contributor to work privately on code that they are not ready to share yet.
     • Although these folders aren’t “locked”, the honor system dictates that members should only access their own named folder within this directory, and respect the privacy of others.
     • A major benefit to GitHub is to code collaboratively, but after discussing with the larger group, the consensus was to have this protected “safe space” for writing embarrassing, messy code first, before sharing in the main collaborative `code` folder.
     • The benefit to this structure, especially for a large group where many might not have extensive experience in coding collaboratively, or might worry about being “judged” for imperfect code (although we have established a friendly, supportive environment, and urged people to be gently critical of each others code editing), is that it gets everyone in the door. The #1 challenged to GitHub and the working group is just getting people to try it out and contribute – so if personal folders help us do that, then I think its a big win! The #2 challenge will be to encourage and ensure that code makes it out of these folders and into the main collaborative folder in a timely and organized way in the upcoming months as projects take shape.
3. Making sure all working group members were successfully added to the repository, and that key players had extended privileges to allow them to help with adding members or acting as administrators for certain projects.
4. Keeping momentum and activity moving after the workshop.
   • As with any working group, keeping progress alive after everyone goes home is always a challenge. But I’m optimistic that using GitHub will help greatly with keeping everyone in the loop and avoiding mass emailing and confusion of things like code and analysis updates.

Successes

1. Although I was participating and co-organizing the workshop remotely (more on that later), I was able to request and set up a Private GitHub Organization ahead of time, and seed it with some starting repositories, README files, and organizational material. I think this really helped jump-start conversations on how we would use it for the working group, and to hit the ground running once coding began.
2. There were several working group members in Leipzig who use GitHub on a regular basis, and they did an amazing job of stepping up in my absence to help teach the tools to the group, make sure git installs were working on laptops, and encourage members to view and use the GitHub repositories.
   

   Isla Myers training the #sCHANGE #sDiv group to use our #github repo for collaboration on #biodiversity change pic.twitter.com/Oa29JeagyG

   — Andy Gonzalez (@bio_diverse) February 25, 2016

   @DanMcGlinn it was great team building, centered on coding, and a shared commitment to problem solving together #github #sCHANGE #sDiv

   — Andy Gonzalez (@bio_diverse) February 25, 2016

3. Having the code online and updated throughout the week really helped remote participants contribute or at least try to keep track of what was happening at the meeting. It’s great that we now have the technology to make remote participation “easy”, but it is a completely different beast than being in the same room as the rest of your colleagues.
4. At the end of the week, nearly all members were on Github (22/26) actively viewing, commenting, or editing code. Issues were being posted, discussed, and resolved!

 

At this point, I’d say that adding GitHub to our list of collaborative working group tools seems to be working out (our data, notes, and manuscripts are so far mostly on Dropbox and Google Drive), which is really exciting to me. There may still be some remaining challenges down the road, but for a big group with lots of ongoing projects, I really think that incorporating GitHub will help us much more than it will be an obstacle.

Here’s to hoping for continued progress and collaboration, and if we’re lucky, funding for more in-person meetings!

Going to miss working with the fab #sCHANGE group. Thx to @srsupp @maadornelas @mioconnor for their leadership #sdiv pic.twitter.com/cuZipxQmML

— Andy Gonzalez (@bio_diverse) February 25, 2016