-
Notifications
You must be signed in to change notification settings - Fork 6
/
lab-manual.qmd
155 lines (90 loc) · 14.3 KB
/
lab-manual.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
---
title: "EpiForecasts manual"
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE)
```
## EpiForecasts manual
This document sets out the core aims, values and expectations of the EpiForecasts group. It was originally inspired by two articles on [lab manuals](https://www.nature.com/articles/d41586-018-06167-w) and [lab meetings](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008953), and a number of publicly available other lab manuals. It is supposed to serve as a point of reference for current and future team members. All team members are invited to contribute and suggest changes, based on what the environment looks like that they would like to work in. Nothing written here is set in stone, and ideally this will turn into a dynamic document maintained by the team as a whole.
Suggestions for editing this manual via GitHub Pull Requests are welcome from any group member at any time.
## Group aims
We develop, use and critically evaluate computational, statistical and mathematical techniques that aim to improve our understanding of infectious disease outbreaks in real time. We are broadly interested in analyses that can inform ongoing or future decision making during acute outbreaks. A recent focus has been on improving the performance of infectious disease forecasts whilst deriving general insights about both their utility and limitations.
We are particularly interested in analyses that are conducted in close collaboration with public-health decision makers, and in a way that maximises the utility for improving the evidence basis for relevant decisions. Whilst our work is usually motivated by the application at hand, we strongly believe that there is great value in developing general and re-usable tools, particularly software packages in widely used, freely and openly available languages (usually R), rather than single-use computer code. Ultimately, our goal is to develop, use and inform robust methodology that makes the most of available resources to provide insights useful for outbreak response, control and prevention, and to contribute to making such methodology available as tools to others.
## Group principles
We are aiming to maintain an inclusive environment where everyone feels valued and able to ask and answer questions and express new ideas. We recognise that each team member adds value to the group and that people have different skill sets, world views, and approaches to working. We believe that science should be open and collaborative. We treat each other, as well as our peers outside the group and their work with respect.
### Expectations from members
Everyone:
* Be passionate and proud about the work you are doing within the group. Do work that others will care about. If you feel as though your work does not meet these standards, we should discuss and try to address this.
* Support the work of other group members and offer help when you feel there is something you can help with.
* Contribute constructively to lab meetings, journal clubs, seminars and other group events.
* Tell someone if you are struggling or if there is a conflict within the group. We can’t thrive in an environment in which we aren’t comfortable.
* Spend your research time on projects related to the aims of the group - you are encouraged to collaborate with people outside the group on other projects, but if these are to take a substantial amount of time this should be discussed first, and as a general rule not cover more than 20% of day-to-day work.
* Take time off at regular intervals, and use the full holiday allowance; also take sick days off if/when needed. We do not glorify workaholic behaviour. There may be times that you have to work longer or harder to finish a time-critical piece of analysis, but this should be balanced out over time.
* Engage in ongoing learning and professional development.
PI: All of the above and
* Support you scientifically, emotionally and financially.
* Be available both in person and via electronic communication, including regular meetings to discuss your work and anything else you would like to discuss.
* Provide a broad perspective on your work within the context of the group and the general direction of science.
* Provide timely feedback on drafts of manuscripts, talks, grant proposals, etc.
* Help you identify the next step in your career, whether inside or outside academia, and support you towards it.
* Identify training opportunities and conferences and support you in making the most of them.
* Point out grant and fellowship opportunities to you and support you in applying to appropriate ones.
* Care for your mental and physical well-being, and prioritise it above anything else.
## Publications
### Choice of journal
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.
Examples of journals that we like are:
* [Wellcome Open Research](https://wellcomeopenresearch.org/)
* [F1000 Research](https://f1000research.com/)
* [PeerJ](https://peerj.com/about/author-instructions/)
* [Peer Community In](https://peercommunityin.org)
* [Journal of Statistical Software](https://www.jstatsoft.org/index)
* [Journal of Open Source Software](https://joss.theoj.org/)
* [PLoS Computational Biology](https://journals.plos.org/ploscompbiol/)
* [eLife](https://elifesciences.org/)
### Authorship
We broadly follow [University of Cambridge Guidelines on Authorship](https://www.research-integrity.admin.cam.ac.uk/research-integrity/guidance/guidelines-authorship). Specifically an author is an individual “judged to have made a substantial intellectual or practical contribution to a publication and who agrees to be accountable for that contribution”. This usually reflects:
1. Making a significant contribution to the conception or design of the project or the acquisition, analysis, or interpretation of data for the work; AND/OR
2. Drafting the work or reviewing/revising it critically for important intellectual content.
We err on the side of inclusion when not sure if someone’s contributions warrant authorship, but don’t award authorship based on friendship, reciprocity or seniority. While authorship does not require writing any of the paper, we will share drafts and submitted version with all coauthors and give opportunities for critical input. If in doubt, we give more time.
For any group publication, group authorship should be agreed based on the value and volume of each person’s contribution, with more supervisory roles towards the end. Where an order between co-authors cannot clearly be resolved we will randomise the order. Everyone should feel encouraged to raise any questions or misgivings they have about authorship on any particular paper.
### Collaborative writing
A paper starts with an outline (e.g., 1 sentence per paragraph) following broadly the structure suggested in [Writing for Impact: How to Prepare a Journal Article](https://static1.squarespace.com/static/5854aaa044024321a353bb0d/t/5a14af7271c10b644be97217/1511305075667/WritingForImpact.PDF), that is shared with key collaborators for feedback before engaging in the writing. If writing collaboratively, paragraphs can then be assigned to co-authors. Any finalised paper should be shared with all co-authors at least a week before preprint publication or submission to a journal.
### Code
We use GitHub extensively. Any on-going work should be in an open github repository, unless restrictions on data sharing prevent us from doing so. Collaboration on code should proceed via GitHub Issues or discussions and, upon agreement on the way forward to address the issue, Pull Request (with pushing to main branches directly discouraged unless for very minor commits), which in general should be reviewed by at least one other team member.
The group’s github repository is <https://github.com/epiforecasts>. Initial and exploratory work should be in personal repositories; maturing and collaborative group projects should be in the group repository. Projects that involve multiple repositories and/or include core developers from outside the group can live within separate organisations and mention the affiliation to the group in some other way.
Any publication should be accompanied by a github repository with a README file that allows full reproducibility of the results, reviewed by at least one other team member. Code may either be licensed to the group or licensed to the authors and contributors of that work. We suggest the use of the MIT licence as a default.
## Meetings
Our meeting structure involves:
### Group meetings (weekly, 1-2 hours)
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.
Every group meeting has a chair, a presenter and a note taker, and all of these roles rotate. It is the responsibility of the chair to conduct the meeting in an inclusive manner that gives everyone the chance to contribute. The note taker leads collaborative note taking and is encouraged to synthesise any learning points from the meeting in a tweet, blog post or similar. There is no expectation that presentations are polished or slides used, and presentation of in-progress or early-stage work is very much encouraged.
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.
Usually, the presenter is expected to either
1. Present some ongoing work, focusing on issues that they are stuck with, thinking about, and/or would like feedback on.
2. Present a new idea and analysis plan to solicit feedback.
3. Present a paper or suggest a broader topic, for example on scientific practice, for discussion, with some bullet points inspiration to kick-start the conversation.
At longer intervals we have meetings to
4. Formulate and review broad goals/aims/progress
5. Post-mortem rounds where we discuss what went good / wrong with past projects
6. Update this manual
We also use the meetings for
7. Practice talks (e.g., ahead of conferences). Everyone who presents work from the group should have the opportunity to present it to group members for feedback.
### Individual meetings with the PI (every 2 weeks, one hour)
These start within a summary of progress since the last meeting, followed by any points for discussion either of us finds worthy of raising.
We will maintain a Google Doc (or similar) for ongoing notes from these meetings - this is updated every meeting with a short summary of discussion and action points.
### Subproject meetings (project-dependent frequency)
Where people collaborate on subprojects they are encouraged to agree on a separate meeting schedule to coordinate and update each other on progress.
### Social meetings (whenever we feel like it)
Coffee meetings, occasional curry outings and others
## Practicalities
### Communication
We use Slack for most communication within the group. The @epiforecasts channel is used for general group communication, announcement of meeting topics, organising social events, reviewing coffee etc. Email is used for formal communication involving the broader community at LSHTM, and for communicating with people external to the group (except close collaborators, who are invited to Slack).
We acknowledge the potential impact of push notifications on productivity and mental health. Everybody is strongly encouraged to turn off all notifications outside of standard working hours (9am-5pm), and is welcome to regularly check into communication channels rather than being alerted by them when within these hours. Generally, the expectation is that team-internal questions put via Slack are answered within 24 hours. After that, it is not considered impolite to send a reminder.
### Web site
The group’s web site is at <https://epiforecasts.io/>. Content can be edited via the github page at <https://github.com/epiforecasts/epiforecasts.github.io> (choose a _.md_ file and edit, or clone the github repo and do it on your own computer). An interesting and up-to-date web site that showcases good work done in the group is of benefit to everyone, but should not take too much of everyone’s time. It is everyone’s responsibility to contribute to this.
### Working hours
One of the benefits of a career in academic research is that it is typically more flexible than other kinds of jobs. However, it is still a job. LSHTM employs people for 35 hours a week, typically expected to happen in 8 hours per weekday with a mandatory 1-hour break. Everybody is strongly encouraged to not work in excess of these hours.
### 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.