As the lab grows, the importance of sharing technical skills, domain expertise and tips and tricks for working effectively grows with it. Lab meetings are a space for all members of the group to come together and learn from each other.
The meetings are held at the Turing Institute on Thursdays at 3pm. Remote participation will always be available and is strongly encouraged for lab members who are not physically located at the Institute that day. The Whitaker Lab calendar shows the times of the meetings, and when meetings are cancelled because they conflict with a relevant event that multiple lab members may wish to attend.
Every lab member is expected to participate in the lab meetings. This doesn't mean you have to attend every one, but it does mean that you are expected to complete the HackMD with your attendance or apologies, and to add something to share and a question to ask.
This document will talk you through the expectations for participation before, during and after lab meeting. There is also a long motivation section about why we've designed the meetings this way.
Lab meetings are very useful for me (Kirstie), but I hope they are valuable for you too. I am always interested to hear of any changes that you'd like to make.
In advance of each week's lab meeting, the chair will send an email with a link to a HackMD note.
HackMD is a realtime, multi-platform collaborative markdown note editor.
Everyone is able to edit the text in markdown when you click the the edit page, and HackMD renders the raw input as a nicely formatted website in the view rendering.
You can see the raw markdown and the rendered page side by side by clicking the both button.
You can read more about HackMD at https://hackmd.io/s/features.
The template for each lab meeting is below, and you can read more about why we have this format in the motivation section at the end of this page.
When you receive the HackMD link, please add your name under Attendees or Apologies. This lets the chair know that you've received the email and acknowledges that week's meeting. It also means the chair knows who to wait for at the start of the meeting.
In advance of the meeting, please also complete the sections on What do you want the lab members to know about? and What would you like lab members' opinion(s) on?
Each point should be on a bullet pointed line with your initials at the start of it (or you can use the HackMD magic of adding, for example, [name=Kirstie] at the start of the line to make this look really pretty).
For ideas about what to write (and most importantly, to make sure you know why we ask these questions) see the motivation section below, and previous lab meeting blog posts on the lab website.
You can put the 🤫 emoji next to your bullet point (or even after your name in the attendance list) if you would like that update to be excluded from the publicly available lab meeting blog post.
Please also read the Agenda section at the end of the HackMD in case there are particular requests for that week's discussion. By default the discussion is an "open agenda" as explained below.
# TEMPLATE: Whitaker Lab Meeting | `DATE`
Time: 3pm - 4pm
Room: `Room at Turing Institute` or `all remote`
Zoom: **REDACTED**
[TOC]
### Useful links
* Calendar with meeting times: https://calendar.google.com/calendar/embed?src=7nar31c6ni4esif8fn1881kgds%40group.calendar.google.com
* Check your local time: http://arewemeetingyet.com/London/`DATE`/`TIME`/Whitaker%20lab%20meeting
* EG: http://arewemeetingyet.com/London/2019-07-18/15:00/Whitaker%20lab%20GSOC%202019%20weekly%20meeting
* Kirstie's personal zoom link: **REDACTED**
### Attendees
> *Please add your name below*
> Add 🤫 if you don't want your name added to the GitHub record
> Add :rocket: if you're connecting remotely
> Add :information_desk_person: if you'll be there in person
*
*
*
*
*
*
### Apologies
> *Please add your name below if you are not able to attend the meeting.
> Don't forget to complete the sections below, even if you are not able to attend.*
> Add 🤫 if you don't want your name added to the GitHub record
*
*
*
### What do you want the lab members to know about?
> *Please add a bullet point with something you'd like the lab members to know about.
> You may respond to any of the points before or after the lab meeting, no need to wait until the 1 hour time slot!
> Please add your initials and use the* 🤫 *emoji if you would like the bullet point removed from the GitHub record.*
*
*
*
*
*
### What would you like lab members' opinion(s) on?
> *Please add a bullet point with something you'd like lab members' opinion on.
> You may respond to any of the points before or after the lab meeting, no need to wait until the 1 hour time slot!
> Please add your initials and use the* 🤫 *emoji if you would like the bullet point removed from the GitHub record.*
*
*
*
*
*
### Agenda & Notes
This meeting is an open agenda.
The discussion points will be curated from the "things you’d like lab members' opinions on" section above.
*
*
*
*
*
*
Lab meeting is one hour long. Please arrive on time, or 5 minutes before if you'd like to get a coffee etc before the start time.
While you do not strictly need your computer to participate in lab meeting, I recommend bringing it along. Having your computer open and connected to the wifi will allow you to comment and add to the shared notes during the discussion.
The chair will read through that week's HackMD, starting with the topics you've shared and then covering the questions and points you'd like the group's thoughts on. They will go quite fast through each of these points, but also encourage members of the lab to elaborate on their updates and questions if they would like to.
This part of lab meeting should take around 10-15 minutes. Everyone is encouraged to add links and resources as "sub-bullet points" (bullet points that are rendered as falling within the original point) before, during and after the meeting.
If the meeting has a specific agenda, the remaining time (approx 45 minutes) will be used for that discussion or presentation.
If the meeting is "open agenda" then the chair, in collaboration with all present lab members, will select key points from the review of the bullet points in the HackMD to discuss in more depth for the remaining 45 minutes.
After lab meeting the chair is asked to convert the content in the HackMD to a publicly available blog post.
The template for the blog post is available in the whitakerlab.github.io GitHub repository as _posts/blog/template_lab-meeting.md.
This blog post should be authored by the chair (make sure to change the author) part of the blog post header.
The blog post does not need to include every point in the HackMD. In fact, it is not likely to be a particularly readable post if that is the case. It should be a short and engaging summary of the key points of discussion.
Remember not to include any points that have the 🤫 emoji next to them. Use your best judgement when publicly sharing questions and comments that show particular vulnerability of the lab members participating in the conversation.
Ideally, this blog post will be written up by the following Monday morning, and a pull request opened for review.
Everyone who is mentioned by name in the blog post is expected to review the pull request and approve before the next lab meeting. Affiliated lab members and alumni who do not have review access to the repository are asked to review by commenting with a 👍 emoji (or similar).
Everyone is expected to chair lab meeting on a rotating schedule.
Your responsibilities as chair are to:
- Circulate the HackMD on the Monday before your lab meeting. This may include booking a meeting room, or communicating which room is already booked.
- Plan an agenda for the meeting (including, if you'd like, an open agenda).
- Facilitate the conversation during the meeting. This includes making sure that everyone has a chance to participate, and that everyone complies with the Whitaker Lab code of conduct.
- Write a blog post and submit it to the whitakerlab.github.io GitHub repository by the Monday after lab meeting.
The prospect of chairing lab meeting might feel really overwhelming! Being in charge of managing the time, coordinating everyone's participation and facilitating a productive conversation is a lot of responsibility 😬
It is also a really important skill that will serve you well in future collaborations and as you advance through your career (inside of academia and beyond).
The first few times that you chair lab meeting, please be in touch with Kirstie before, during and after that week so she can answer any questions and mentor you though the experience.
This last section outlines why I (Kirstie) have structured lab meeting in this way, particularly focusing on the reasoning behind having the questions in each week's HackMD note.
If you have any suggestions on additional points to cover or different phrasings, please let me know!
There is a great risk that the projects in the group are siloed and that Kirstie becomes a bottle neck for communication. This is a centralised network (A in the diagram below). In contrast, a decentralised network (B) shares information more effectively. Small world networks in particular are efficient and resilient.
Decentralization diagram uploaded to Wikimedia Commons by Adam Aladdin. Reused under a CC-BY license.
I would like this lab to be as decentralised as possible. I would like lab members to find the answers to their questions quickly and receive help and support from all other lab members in all dimensions.
One of the core goals of all Whitaker Lab is to improve collaboration (in academia and in the world!) And a core requirement of effective collaboration is trust. In fact, there was an article in the Harvard Business Review in 2011 that named trust as the "The One Thing That Makes Collaboration Work".
Building trust is a difficult and multi-dimensional, but by being vulnerable with each other is one core component. In her book Emergent Strategy (which I love love love), and in this blog post from 2013, adrienne maree brown describes the following principles:
- lao tzu says "if you don’t trust the people, they become untrustworthy." the first principle is a positive flip of this statement – if you trust the people, they become trustworthy. trust is a seed that grows with attention and space. the facilitator can be a gardener, or the sun, the water.
- there is a conversation in the room that wants and needs to be had. don't force it, don't deny it. let it come forth.
- the connection between the individuals is what makes the whole group/community strong.
(Note that brown self determines what she capitalises, which reminds me of - and is possibly inspired by - black feminist writer bell hooks who did not capitalise her name in order "to focus on the substance of her work, not who [she] is".)
If we want information to flow around a decentralised network, then we need to trust each other. I believe that building connections between individual people are the magic that will lead to the most exciting and innovative data science.
Two hours per week (one hour weekly meeting and one hour lab meeting) is not enough to effectively collaborate together. Especially when many of the projects the lab works on require quite different domain expertise.
In an early iteration of these lab meetings, participation was optional and attendance was very low. There two reasons I did not make joining lab meeting mandatory was 1) I hoped it would be a valuable use of folks' time, and an enjoyable hour in the week, and 2) that I was uncomfortable requiring time out of busy people's schedules.
On reflection, I think we were missing the trust that is fundamental for collaborative discussions to meet their true potential. So we were in a vicious cycle that meant the meetings were not useful and therefore fewer people came.
We also did not hold the meetings regularly. They were fitted in around my schedule and therefore very difficult to predict.
In this iteration of lab meetings, I expect lab meeting to be chaired in my absence. Lab meeting will only be cancelled if there is another event that multiple lab members are encouraged to attend.
I ask for regular attendance from current lab members.
Affiliated lab members and alumni are welcome to ask to attend, but they will not be added by default to the email list. They can opt-in to the emails, and - after a discussion with Kirstie - they will be removed from the threads if they do not participate for four meetings in a row.
Importantly, participation does not exclusively mean attending the meeting. Completing the HackMD in advance and sending apologies is sufficient to count as an active participant.
Participation by affiliated lab members is key to the success of the research group, but sporadic attendance is too difficult to predict and plan around. Not having them attend reduces the visibility and skill sharing opportunities of projects that Kirstie is involved in but which are not funded by grants to the lab. Members of these teams have great potential to enhance the conversations we share. I very much hope that affiliated lab members will participate, and I am confident that we can build to a position where this hour is helpful and enjoyable by all.
In this current iteration, I would like to focus my energy on lab members and collaborators who have capacity to build trust within the group. Graph theory tells me that a small, small-world network, will be more powerful than one with a single too-busy-to-reply-to-emails human in the centre.
Please add a bullet point with something you'd like the lab members to know about. You may respond to any of the points before or after the lab meeting, no need to wait until the 1 hour time slot! Please add your initials and use the 🤫 emoji if you would like the bullet point removed from the GitHub record.
If five people come to lab meeting, every week for four weeks, and each time they share something interesting, we'll curate 20 content recommendations in just one month. I'm willing to bet that at least 1 in those 20 will be useful for the lab. So the first reason to ask people to share some information is to do exactly that: share knowledge.
People are often uncomfortable celebrating their successes. And that is a limitation on the goal of sharing knowledge. Both imposter syndrome and the Dunning–Kruger effect can stop people from sharing skills and resources that they know. They may not recognise their strengths, or know how much they don't know and therefore keep quite while others speak much more. The second goal of sharing something every week is to have lab members build confidence in their expertise. Everyone has something to contribute.
And finally, it feels really good to celebrate others' achievements! Leaving a little 💖, 🙌 or 🚀 emoji, or maybe even a few words of congratulations makes you feel good. This third goals is to help us all see the progress along a career that is generally rewarded at the end of very long term timescales (a paper takes years to write, and a thesis even more so). Stopping once per week to recognise what we've all achieved will help us all along the long research road.
Please add a bullet point with something you'd like lab members' opinion on. You may respond to any of the points before or after the lab meeting, no need to wait until the 1 hour time slot! Please add your initials and use the 🤫 emoji if you would like the bullet point removed from the GitHub record.
Asking questions is the first step in finding the answers. If lab members do not ask for help in the first place, then the communities will not be able to support them. One goal of this section in the lab meeting HackMD is to unblock lab members so they can move forwards on with their work.
Responses to a question might be:
- To share a piece of code so they don't need to write it again.
- To share a relevant publication or blog post.
- To share a tutorial that explains how to use a software tool.
- To put the team member in touch with an expert in the field they're investigating.
- To share a similar experience and what went right (or wrong) that time.
Asking questions is also a learned skill. Analogous to a Minimal worked example it takes time and practice to distill your question from "It doesn't work" or "I don't know what to do" to a specific "I get this error message when I run this command", "I'm stuck on interpreting this figure", "How do I manage this particular challenging community interaction", or "Where should I store my data". In many cases, it is in creating the question in the first place that you figure out what you need to know.
So the secondary goal of this section is to help you ask good questions.
This illustration from her blog post on "How To Ask Good Questions" by Julia Evans is wonderful. (The blog post is great too!) Just don't let it trick you into thinking that the only good questions are related to technical expertise. The hardest and most important questions are about how we plan and design, undertake, and communicate our research rather than "just" the software tools and datasets they contain.
How to ask good questions by Julia Evans
Many of the projects that Kirstie is involved in are distributed around the world. Many of us are not co-located and so it is important to find ways to share expertise and build connections and trust from afar.
The HackMD and Zoom links allows lab members to contribute without being physically in the room.
The HackMD also allows lab members to contribute even if they are not able to join the meeting. That way, we can hear updates from them and get answers to our questions, even if our collaborators are not able to join the conversation in real time.
Finally, the HackMD lets everyone talk at once. You can find links and add comments as the conversation in the room is ongoing, which allows parallel participation rather than waiting to speak in a serial timeline 😉.
There are two goals to publishing the blog post on the lab website.
The first, and most important goal, is to show our commitment to working open.
From the Mozilla Open Leadership training series:
- When you are "working open" you use the power, knowledge, and skills of a diverse community of volunteers (called "contributors") to accomplish something that a single person or a small team couldn’t do alone.
- When your project is “open” you share knowledge and information generated by the project widely and freely, allow others to build on your project, and maximize its usefulness for everyone.
By sharing our resources, we democratise data science and make STEM research more accessible.
The second goal is to promote the work in the lab! Both to current readers so they're excited about what we're learning and thinking about together, and to future readers - for example future lab members - to be able to catch up on what we've done and where we're going.
I really appreciate your participation in the lab. We couldn't do the exciting work without you.