This page covers in-group communication. If you wish to contact the group, please email Leo directly.


The source code used to generate this website is stored in a GitHub repository: compgeolab/website. Members are expected to post short news items when they do things of note (join the group, graduation, publication, conferences, awards, etc), as well as to update project and publication information. All updates are conducted via pull request.

When joining the group, please submit a pull request adding yourself to the website. If you are new to git, you will work through this with someone more experienced. You are not required to provide a photo and contact information (but you certainly may if you feel comfortable having this information public on the internet).

Social media

In general, social media can be freely used if in line with the University of Liverpool Social Media Policy. Lab members are encouraged to be respectful and kind while participating if they are representing themselves as lab members. Earlier comments about professionalism apply here when lab members are presenting themselves as representatives of the lab.


We use a few communication mechanisms that meet several different categories of need: ephemeral, archived, immediate, and asynchronous.

  • Slack: We have a slack team at You should receive an invitation when you join the group. This is the primary mode of communication for quick messages, announcements, reminders, and organizing meetings. Messages are ephemeral so you cannot count of being able to read messages older than 6 months! Use email if you need a record of the conversation.
  • Google Calendar: The group calendar is used by everyone to post their travel and out-of-office dates, interesting conferences, talks, meeting times, etc. Lab visitors will be listed there as well.
  • GitHub: Each project will be assigned a repository on our group GitHub account. Reviews of code, text, etc will be done through issues and pull requests.
  • Trello: We have a Trello board to organize projects and tasks that need to be done.
  • Group meetings: We will have monthly (or bi-weekly) group meetings for general discussion, announcements, interesting papers, and informal chat followed by quick (5 min) updates from each group member on what has been done in the previous period ( things you've worked on, things you've learned, struggles you're having, and so on).
  • Individual meetings: We aim to have weekly individual meetings to discuss each members status, goals, projects, and work through problems and ideas.
  • Note taking: We use Google Docs for group note taking, slides for group meetings, etc.

Group members are also strongly encouraged to have in-person meetings with each other or with Leo. Don't wait until problems build up to seek guidance.

Detail level during group meetings

During the group meetings, detail should be just enough and no more to communicate your work, unless probed by another group member. Longer discussions can happen after the meeting with the participation of whoever is interested. As the group grows larger, we need to ensure that everyone has an opportunity to share. Detailed updates can be sent through Slack, or during other chats or meetings.

For level of detail, it is fair to assume a passing familiarity with your project and problems, but it is important to first look online to find if there are common answers to issues you are encountering.

External software projects

Whenever possible, please contribute upstream to external open-source projects, participate in their mailing lists, and report issues as appropriate on their mailing lists, issue trackers, and so on. We strive to be good "citizens" of the open-source community. When engaging with other members of the community, be respectful, kind, and thoughtful in your communication.

Projects that are developed by lab members with external collaborators (for instance, Fatiando would fall under this distinction) should have their discussions held openly. For instance, while it is useful to have in-person meetings, if these are held in response to an online inquiry (i.e., "I'll come by your office to help you out") then a summary should be sent afterwards to ensure that the project members who cannot be in the office can still participate and understand. This can help discourage the notion that projects developed by lab members are not community projects, and will also help to continue engaging other collaborators.

For more discussion about this topic, see Matt Turk's paper Scaling a Code in the Human Dimension.

This manual is based on the excellent Lab Carpentry blueprints, with material adapted from the Data Intensive Biology Lab and the Data Exploration Lab.