Update lab manual: meetings, values and openness#109
Conversation
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
Co-authored-by: sbfnk-bot <242615673+sbfnk-bot@users.noreply.github.com>
seabbs
left a comment
seabbs
left a comment
There was a problem hiding this comment.
Looks good. Some minor points - perhaps better addressed as their own issues/discussion items.
| All our publications must comply with [Wellcome’s Open Access Policy](https://wellcome.org/grant-funding/guidance/open-access-guidance/open-access-policy). In particular, we will post preprints of any work, and subsequently submit them to a peer-reviewed journal for publication under a CC-BY licence. | ||
|
|
||
| We believe that the peer review and publication process should be open and transparent, and we particularly support journals that allow first submission in any format and have policies in line with our principles. We do not design our work to aim for “high-impact” but may choose to submit to them if we believe work we have done is of interest to the broadest readership. All that said, we are aware that in many instances career prospects of early career researchers may still be seen to depend on the impact factors and identities in journals in which they publish; whilst we do not think this is the case, we do not mandate any particular policy and accept if lab members feel the need to submit to particular journals. | ||
| We believe that peer review and publication should be open and transparent, and we particularly support journals that allow first submission in any format. We do not design our work to aim for "high-impact" journals but may submit to them if the work is of interest to the broadest readership. We do not mandate any particular policy on journal choice. |
There was a problem hiding this comment.
I don't agree with the assumption here that these venues have the broadest readership
There was a problem hiding this comment.
This paragraph also assumes that peer review is a good think we generally support which I am not totally convinced by. Happy to let that slide.
There was a problem hiding this comment.
Can we add something to the kinds of journals we support i.e. I much prefer non-profit or alternative profit journals. I also prefer ones with non-traditional approaches to peer review. Happy for these ideas to not make it in here but I think making this more concrete in general would be good.
|
|
||
| #### Structure | ||
|
|
||
| The meeting starts with the chair briefly sharing something non-work-related — a film, a book, a place visited, something they've been thinking about. The chair then follows up on any commitments from the previous meeting: offers to help, resources to share, introductions to make. |
There was a problem hiding this comment.
can we remove non-work-related from this? I think it should be optional personally? Usually the thing I want to share with people with similar research interests is something about research as I can share with others what I got up to last saturday. (I get this a group cohesion thing and makes it easy to share something so can probably ignore me).
There was a problem hiding this comment.
I vote for keeping non-work-related for this part, since three projects are already full of research topics and leads to a high turn-around for each individual. It's a good light warm-up time for everyone to easily speak out and be ready for commenting on later discussions. Also, even though the meeting is expected to finish 90 minutes, I like margin time for free discussions or talking about interesting ideas.
|
|
||
| Weekly group meetings are there to communicate and exchange useful ideas, not to update or impress. Participation in all group meetings is expected of all group members - if you can’t make it, send an advance notice. The meetings should be conducted in an informal, positive, and supportive environment where it is at least as interesting to present loose ideas, failures, negative results and dead ends. Feedback from group members should aim to be helpful and constructive. | ||
| - **10 minutes:** Presentation following the structure below | ||
| - **5 minutes:** Clarifying questions |
There was a problem hiding this comment.
Do you think the clarifying questions work? I find it a bit radio 4 sometimes (i.e. a question turns into a comment) and a bit hard to judge the line. Maybe we could do the feedback and then if there are commen clarifications needed we could discuss in the back 5 minutes (i.e. flip this)
There was a problem hiding this comment.
I think clarifying questions work particularly when I am missing aims or backgrounds of the research presented (but agree sometimes a question turns into a comment).
Also, 10 minutes presentation is very short and often I had a lot of questions for understanding in order to leave some feedbacks.
I think this could be adjusted by presenter's declaration of what kind of feedbacks they like (or questions they accept...?).
| #### Presentation structure | ||
|
|
||
| The group meeting starts once the chair is satisfied that people have arrived. As a first item, the chair will briefly talk about something that is not related to the work of the group - this could be a film they've seen, a book they're reading, a place they've visited, something they've been thinking about or anything else really. This is followed by the main presentation. | ||
| 1. **"Today I need help with..."** — 1-2 specific problems or questions, not "general feedback" |
There was a problem hiding this comment.
If being this prescriptive might be useful to make a slide deck template.
|
|
||
| A monthly walk to a coffee shop or similar, replacing a regular meeting. These encourage smaller 2-3 person conversations that don't happen easily in a full group. | ||
|
|
||
| ### Individual meetings with the PI (every 2 weeks, one hour) |
There was a problem hiding this comment.
Might want to add some structure in here i.e. career progression, mentoring, managing LSHTM requirements with research etc etc.
I don't think we really have a lot of this in our regular meetings but maybe this happens more in others.
There was a problem hiding this comment.
IMO I would also prefer guidance on async vs f2f communication as often reading and responding to something is a lot more useful than having a chat.
There was a problem hiding this comment.
(so for me I would go down to 30 minutes with first 30 being I will look at this time but that could be personal preference)
| We maintain a Google Doc (or similar) for ongoing notes — updated every meeting with a short summary of discussion and action points. | ||
|
|
||
| ### Subproject meetings (project-dependent frequency) | ||
|
|
There was a problem hiding this comment.
This framing makes it unclear how the PI interacts with subprojects i.e if there is an expectation they attend the meeting. How these project meetings then interact with one on one meetings etc.
There was a problem hiding this comment.
For both these meetings might want to add some expectations around sending and reading content. I often find with meetings in general that people either send stuff to late to look at so really a part of the meeting needs to be looking at it or that the person I am meeting with hasn't read what I am talking about so can't really be useful
|
|
||
| ### Onboarding | ||
|
|
||
| When someone new joins the group, they are given an overview of current projects and how they connect, and introduced to relevant tools and communication channels. The group's [projects page](https://epiforecasts.io/projects) provides an overview of current work with links to repositories. |
There was a problem hiding this comment.
who does this? What does it look like? One risk here is that group members work is shared and then picked up in a new project with the new member and the PI (not including the group member) what mitigates that risk?
There was a problem hiding this comment.
I think something in here about who "owns" and how that relates to in group communication would be useful. The curernt default seems to be the PI which I think is fairly standard but imo shuts down communication in some areas.
There was a problem hiding this comment.
I feel interested to see this comment. In my understanding, our group is committing to the open sceince, and every project is openly accessible in an early stage (as listed in the project page). Then, the risk of being picked up is always there, by not limited to our group members. I implicitly assume the benefit of openly sharing research outweights these risks so that if accepting the project to be public, what is a problem to share the current projects with new members...? Sorry just I am curious about the view on the open science.
| ### Presence | ||
|
|
||
| There are definite benefits to working together in the same building/office, particularly in facilitating informal communication. That said, the Covid-19 pandemic has shown that remote working can be managed successfully, and the same approach does not work for everyone. We are keen to find ways of working that are flexible enough for everyone to work in the way that they are most productive, whether on-site in London or remotely. | ||
| There are benefits to working together in the same building, particularly for informal communication. But the same approach does not work for everyone, and we are flexible about whether people work on-site in London or remotely. |
There was a problem hiding this comment.
Might want to keep some of the framing aroudn productivity.
|
Do we want to add something around expectations with code review in the group. Not so much if it happens but when it is being done expectations around it. i.e be nice, constructive, don't ask people to review LLM generated code you haven't reviewed etc etc Could be its own issue |
|
Maybe this is an issue but there is a statement in the aims that we are value and aim to develop software. There is then nothing in the output about valuing software alongside traditional academic goods (i.e there is just a publications section). I also couldn't see anything about code for a paper being as much a product of the paper as the manuscript and expectations around that. Also nothing about trying to expand/adapt existing software when doing new work vs rolling new models from scratch that I can see. |
|
On a related point there is nothing about contributing to lab software and how that works/expectations etc. |
|
And a related related point nothing about maintaince of those tools, ownership, decision making etc. |
3 participants
Summary