The Center for Open Science writes that:
An open exchange of ideas accelerates scientific progress towards solving humanity's most persistent problems. The challenges of disease, poverty, education, social justice, and the environment are too urgent to waste time on studies lacking rigor, outcomes that are never shared, and findings that are not reproducible.
In this spirit:
- We use open-source and reproducible tools so that that our peers can repeat, critique, and improve upon our work
- We communicate our findings and methods to our peers through open-access channels that facilitate intellectual progress
- We actively communicate findings of relevance to the public through a range of appropriate channels
This page describes our approach to open science at a high level -- see the toolkit page to learn about specific tools we use. And don't worry if you're not familiar with all these tools; we'll teach you what you need to know 😉!
Unless there are specific and compelling reasons (which should be documented and reviewed by peers), the necessary components of a scholarly work to provide reproducibility should be provided in a publicly accessible location and potentially as part of the scientific record. In the case of a simulation model, this would include:
- A specification of the computing environment
- The source code that ran the simulation
- The parameter file or definitions file, and if applicable initial conditions, that ran the simulation
- Analysis code that generated plots for the paper
Although our preference is to use fully open-source tools, we occasionally use tools that we have a license to use but to disseminate. In this case the exact version of the external software should be documented and instructions for how to install it identically should be made clear.
We use lots of tools to facilitate reproducible science. Before learning specific tools, read
Wilson, G., Bryan, J., Cranston, K., Kitzes, J., Nederbragt, L., & Teal, T. K. (2017). Good enough practices in scientific computing. PLOS Computational Biology, 13(6), e1005510. https://doi.org/10.1371/journal.pcbi.1005510
to understand why we use them and how each tool fits into our overall scientific workflow. Some default tools that we use to achieve these practices are listed in tools. Don't try to learn everything at once -- build your skillset incrementally. And if you believe another tool will get the job done faster or better, go for it!
Software and other research materials that we make available to the public must declare a license for re-use. All code generated in the lab should be open-source with a permissive (non-copyleft) license (MIT, BSD, or Apache). If contributions to upstream copyleft projects are made, those contributions can be licensed in accordance with the upstream project license.
Importantly, in the lab we should cultivate an atmosphere of respect for licensing terms and ensuring that we are at all times in compliance with those terms. For help choosing a license, see https://choosealicense.com/licenses/ or read
Stodden, V. (2009). The legal framework for reproducible scientific research: licensing and copyright. Computing in Science Engineering, 11(1), 35–40. https://doi.org/10.1109/MCSE.2009.19
Communication and outreach¶
From our core values,
We seek to make our research accessible to all levels of an inquiring society, amateur or professional.
This necessarily involves communicating methods and results to peers using scientific tools, and to the public through the channels.
We communicate findings to our peers in academia and the broader research community through formal and informal writing, presentations, and code. In keeping with our open science principles, we:
- publish in open-access journals where appropriate, and make post-prints freely available when not
- make preprints of work available on open-access servers at the time of submission (and update with later versions of the paper)
- summarize findings in technical blog posts
- publish conference slides and posters on permanent repositories like figshare and Zenodo
- make GitHub repositories for papers publicly available at the time of submission to a journal
- make software available through permissive licenses
- write and share clear and well-organized scientific code
Some of our work is of general public interest or has the potential to inform policy. It would be unethical to allow only the best-educated members of the public to have access to this research -- particularly since the effects of floods, unsafe water, and inadequate infrastructure disproportionately affect members of vulnerable and marginalized communities. To attempt to ensure that all members of the public have access to our research, we:
- summarize findings in non-technical blog posts
- translate papers and communications as appropriate
- use social media to share key findings
- write 2-page policy briefs
- develop communication plans with community organizations and stakeholders as part of initial research design
- cultivate long-lasting relationships in the communities where we work
as appropriate. It can be very challenging to write about complex technical topics in a manner that is readily understandable to the public. Too often, shoddy science communication either uses jargon and concepts that are alien to the public, or over-simplifies the limitations and subtleties of scientific research. To avoid making these mistakes, take advantage of resources like the Rice Engineering Communications Team (talk to James first).
Writing is one of the most difficult and most important scientific skills. It is worth revisiting a good style guide regularly, such as:
Strunk, W. (1999). Elements of style.
or, for a more in-depth approach,
McCloskey, D. N. (2000). Economical writing. Prospect Heights, IL: Waveland Press.
and for science writing in particular,
Schimel, J. (2012). Writing Science: How to Write Papers That Get Cited and Proposals That Get Funded. Oxford ; New York: Oxford University Press.
Digital copies of these books are available to group members.