All data and models generated by the lab will be made available in both raw and processed forms under CC0 or CC-BY licenses. Except where constrained by external (i.e., "upstream") copyleft licensing, all software developed will be made available in source form under permissive, BSD-style licenses. Source code will be made publicly available on github.com (or similar), with additional backups possible. Every effort will be made to preserve integrity and accessibility of data.
Above text is based on doi.org/10.6084/m9.figshare.1293561 by Matthew Turk.
Projects that lab members bring with them do not automatically confer authorship rights to either Leo or other lab members. However, if work is conducted on them during the course of being present in the lab, acknowledgments would be appreciated; funding acknowledgments are necessary to describe the source of your funding.
Projects that are collaborated on between lab members do confer authorship, whether that collaboration takes the form of intellectual collaboration, technical collaboration or data sharing. For instance, writing code to support analysis or simulation would confer authorship. Sharing information during group meetings does not, although if material intellectual contributions (i.e., new directions, solutions to problems, specific and directed project ideas) are made by lab members, that would confer authorship.
Please keep Leo apprised of the broad outlines of your external and internal collaborations. Leo would very much like to be involved in the development of external projects, but this is not strictly necessary. It is certainly not necessary where lab members are providing supporting roles to external collaborations.
From a social, rather than a licensing or intellectual property perspective, when a project is developed in the lab primarily by a single participant, that participant is free to continue developing and assuming project leadership once they have departed the lab. In fact, developing projects that mature, grow, and may contribute to their future career is a key part of the process of scientific development.
For projects that are collaboratively developed with multiple roughly equal participants, leadership will be decided on a case-by-case basis, erring on the side of providing intellectual freedom and empowerment to earlier-stage researchers.
However, projects that are part of a strategic lab direction may continue to be developed within the lab following departure of a primary developer. In such a case, decisions about "forking" or bifurcating development will be held on a case-by-case basis.
Human resources guidelines take precedence over this section.
We intend to foster a collegial lab atmosphere, with opportunities for spontaneous discussions and creative opportunities. Lab members are not expected to sacrifice personal or leisure time in service of projects. Working long hours without interruption can lead to burnout, exhaustion, and overall impedes the type of atmosphere we are trying to develop.
Lab members should endeavor to be good University of Liverpool "citizens", participating in seminars, all-hands meetings, and other projects as they become available. This includes contributing to department projects, collaborating with individuals from other groups around campus and the center, and fostering new collaborations both internal and external. We strive to be a part of the intellectual community at the University of Liverpool.
Unless there is a very good reason (PII or other restrictions), work should be conducted in public repositories on publicly accessible servers such as GitHub. This includes software. Paper repositories may be held back as private until time of first submission, when they should be made public for review. Because it is expected that repositories will be made publicly accessible, including history of development, lab members are required to behave professionally in them (including commit messages, issues, pull requests, code comments, etc).
Many journals consider the content of referee reports to be de facto confidential. As such, unless the report is explicitly open, it should not be added to repositories as text, commit messages, or comments in papers.
Grant proposals developed internally with no external PIs or Co-PIs should be made available unless there is confidential information. Grant proposals developed in collaboration with external PIs or Co-PIs may be kept confidential at the external collaborators discretion, although our preference is for them to be open.
Lab members are expected to keep notes of their progress. This can be somewhat free-form, as the purpose is not to keep "tabs", but instead to ensure that work can be reconstructed and reproduced. These can be kept either in a centralized lab repository, next to specific projects in text files, or on Trello cards (preferred).
Unless strongly prohibited by external concerns, the necessary components to provide reproducibility of a scholarly work should be provided in a publicly accessible location and, potentially, as part of the scientific record. In the case of an method development paper, this would include:
The overall theme here is that of reproducibility; this is not the same as bitwise identical reproduction, which is often unavailable because of constraints such as order-of-arrival differences. The additional overhead of making work reproducible should not be onerous compared to the other expectations, and in many ways (i.e., plot generation, good note taking on data, etc) can reduce the overall effort of developing papers and workflows.
We will endeavor to respond to requests to reproduce our results by providing necessary technology and data, allowing for reasonable commitments of time and effort.
Note: this is distinct from the Code of Conduct, which applies both within and without the lab.
Our actions should be guided by the ethics of participating in the scientific community. This includes prioritizing our professional obligations over fear of being "scooped." For instance, it is completely unacceptable to interfere with the peer-review process for a paper out of concern of protecting one's own work (i.e., "sitting" on a review for it, making unreasonable requests to delay publication, and so on.)
When other researchers request assistance with software developed in the lab, we should attempt to make a best effort to assist them. It is not unreasonable to ask for authorship, particularly if the collaboration is extensive.
When authoring papers, we should be providing citations to all software that
assisted in the development of the scholarly work.
While in the extreme case this would extend to the operating system level, in general it
is acceptable to cite the layers of software in the analysis stack (e.g., NumPy,
Matplotlib, IPython/Jupyter, etc.)
It is preferred to directly cite the canonical papers (often described in
files) for software, but acknowledging them without citation may be sufficient.
Citations to data DOIs or publications should be made wherever possible, and where not
possible, should be included as footnotes.
When developing software, we must make a best effort to cite which pieces of
software and published methods contributed to the development.
Plagiarism is unacceptable in any form. This includes "first pass" text included in papers or proposals; when "first pass" text is included from an external source, it must be clearly marked as such to ensure it is not accidentally included in the final product.