-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
- Loading branch information
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,15 +1,130 @@ | ||
--- | ||
title: 'Module 4: Principles of FAIR Scientific Publishing' | ||
title: 'Module 4: The Scientific Paper of The Future' | ||
description: | ||
"This module provides fundamental principles in scientific publishing to ensure that all artifacts of science are Findable, Reproducible, Interoperable, and Reusable (FAIR). [Link to full slide deck]" | ||
"This module provides fundamental principles in scientific publishing. Scientific publishing refers to the making all artifacts of research publically accessible (not only the paper but also the data, software and workflow) to ensure that all artifacts of science are Findable, Reproducible, Interoperable, and Reusable (FAIR). The following module will provide author checklist on publishing guidelines and test your understanding of the concepts." | ||
prev: /module3 | ||
next: null | ||
next: /module5 | ||
type: chapter | ||
id: 4 | ||
--- | ||
|
||
<exercise id="1" title="Why learning about Scientific Publishing?" type="slides"> | ||
<exercise id="1" title="The Scientific Paper of the Future"> | ||
|
||
<slides source="chapter4_01_whySPF"> | ||
This training contains best practices in sharing your science artifacts regardless of the platform, research area or target journal. The recommendations made in this training are mindful to the effort required to help your scientific community to achieve FAIR Science. | ||
|
||
As you go through this training, recommendations on specific platform are made so you apply the concepts; however, please note that many options are available to you. | ||
|
||
The training materials can be accessed [here](https://figshare.com/articles/presentation/The_Scientific_Paper_of_the_Future_v2024_Training_Materials/25754244). | ||
|
||
The next three chapters in this module provides an author checklist for publishing your data, software, and workflow. | ||
|
||
**Trivia Time!** | ||
|
||
Obtaining consistent computational results uing the same input data, computational steps, methods, code, and conditions of analysis is an example of: | ||
|
||
<choice id="04-01"> | ||
<opt text="Reproducibility", correct="true"> | ||
This is the definition of reproducibility | ||
</opt> | ||
<opt text="Replicability"> | ||
No, this is reproducibility | ||
</opt> | ||
</choice> | ||
|
||
Replicability is not always wanted. | ||
|
||
<choice id="04-02"> | ||
<opt text="True", correct="true"> | ||
Non-replicability of results doesn't mean that something is wrong. In fact, science advancement relies on getting more information with different data/methods and obtaining inconsistent answers. | ||
</opt> | ||
<opt text="False"> | ||
Non-replicability of results doesn't mean that something is wrong. In fact, science advancement relies on getting more information with different data/methods and obtaining inconsistent answers. | ||
</opt> | ||
</choice> | ||
|
||
Which of the following do not require a persistent unique identifier when writing a scientific paper of the future? | ||
|
||
<choice id="04-03"> | ||
<opt text="Data"> | ||
Data should be identified with a persistent unique identifier. You can usually get one through a data repository. | ||
</opt> | ||
<opt text="Software"> | ||
Software (and possible, each version of the software) should be identified with a unique, persistent identifier | ||
</opt> | ||
<opt text="Worflow"> | ||
Workflows should be identified with a unique, persistent identifier | ||
</opt> | ||
<opt text="Authors"> | ||
Authors should be identified with a unique, persistent identifier. Several publishers now required ORCID for submission. | ||
</opt> | ||
<opt text="None of the above", correct="true">All should have a unique persistent identifiers!</opt> | ||
</choice> | ||
|
||
</exercise> | ||
|
||
|
||
<exercise id="2" title="Publishing your data" type="slides"> | ||
<slides source="chapter4_01_data"> | ||
</exercise> | ||
|
||
<exercise id="3" title="Publishing your software" type="slides"> | ||
<slides source="chapter4_02_software"> | ||
</exercise> | ||
|
||
<exercise id="4" title="Publishing your workflow" type="slides"> | ||
<slides source="chapter4_03_workflow"> | ||
</exercise> | ||
|
||
<exercise id="5" title="Test your understanding"> | ||
|
||
You may put your data in your GitHub repository and get a single DOI for all products of your research. | ||
|
||
<choice id="04-04"> | ||
<opt text="True", correct="true"> | ||
This is certainly one way to go. The advantage is that the data is on the same repository as the code, making it easier to create containers. However, you will need to be explicit in what the repository covers in your citation. In addition, your data may not be as discoverable as if they were on a data repository, especially one in your domain. One approach is to have a copy in the GitHub repository for workflow execution, referring to the data repository and associated citation in the read me of the repo. | ||
</opt> | ||
<opt text="False"> | ||
It is more nuanced than saying never! Placing the data with the code makes it easier to create containers. However, you will need to be explicit in what the repository covers in your citation. In addition, your data may not be as discoverable as if they were on a data repository, especially one in your domain. One approach is to have a copy in the GitHub repository for workflow execution, referring to the data repository and associated citation in the read me of the repo. | ||
</opt> | ||
</choice> | ||
|
||
You should always use a permissive license. | ||
|
||
<choice id="04-05"> | ||
<opt text="True"> | ||
This is going to be highly dependent on your work! | ||
</opt> | ||
<opt text="False", correct="true"> | ||
The choice of license will depend on your source of funding. If using government funding, especially NSF, you have a duty to make all products of research available for reuse. When working with small businesses (SBIR and STTR grants), the requirements may be different. Your university may also carry their own licenses (for instance, you may have a look at USC's license here: https://postdocs.usc.edu/wp-content/uploads/sites/2/2018/05/Software-Distribution-exhibits-revised-05042018-1.pdf). | ||
</opt> | ||
</choice> | ||
|
||
Your workflow should always be in an electronic notebook. | ||
|
||
<choice id="04-06"> | ||
<opt text="True"> | ||
Although notebooks have become more popular, this is not a requirement (but highly desirable) | ||
</opt> | ||
<opt text="False", correct="true"> | ||
Notebooks are very popular to share workflows since they include the data, code, visualizations and text that allows another researcher to validate their results on your code. However, they are not the only way to share workflows. At the very least, you should include a flow diagram (this is also useful to include in a notebook for visualization of the approach). When using a series of scripts, make sure that your read me file includes the order in which they need to be executed, the input data for the script and the expected output. | ||
</opt> | ||
</choice> | ||
|
||
I am entirely responsible for making my data, software and workflow FAIR. | ||
|
||
<choice id="04-07"> | ||
<opt text="True"> | ||
No. The steps outlined in the scientific paper of the future helps you support a FAIR community but the responsibility is not squarely on your shoulders. Data/Software repositories play a critical role in ensuring that the data/code stored their meet FAIR criteria as well. Publishers are also responsible for ensuring FAIR research and access. | ||
</opt> | ||
<opt text="False", correct="true"> | ||
That is correct! The steps outlined in the scientific paper of the future helps you support a FAIR community but the responsibility is not squarely on your shoulders. Data/Software repositories play a critical role in ensuring that the data/code stored their meet FAIR criteria as well. Publishers are also responsible for ensuring FAIR research and access. | ||
</opt> | ||
</choice> | ||
</exercise> | ||
|
||
|
||
<exercise id="7" title="Other resources"> | ||
|
||
- [The Turing Way handbook to reproducible, ethical and collaborative data science.](https://the-turing-way.netlify.app/index.html) | ||
|
||
</exercise> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
--- | ||
title: 'Module 5: Using GitHub for your research' | ||
description: | ||
"This module provides fundamental information about using GitHub for your research." | ||
prev: /module4 | ||
next: null | ||
type: chapter | ||
id: 5 | ||
--- | ||
|
||
<exercise id="1" title="Introduction to GitHub"> | ||
|
||
This section from Project Pythia's tutorials will introduce GitHub, the de facto standard platform for collaboration and version control used by the open-source Python community. | ||
|
||
In the last exercise, you will configure your GitHub account for secure logins via ssh and/or https. | ||
|
||
[What is GitHub?](https://foundations.projectpythia.org/foundations/github/what-is-github.html) | ||
|
||
[What is a GitHub Repository?](https://foundations.projectpythia.org/foundations/github/github-repos.html) | ||
|
||
[Issues & Discussions](https://foundations.projectpythia.org/foundations/github/github-issues.html). Remember, when opening issues, always submit a minimum reproducible example. It doesn't have to use your own data, just something similar that you can simulate using a random generator or write manually. [Here](https://github.com/LinkedEarth/Pyleoclim_util/issues/469) is a great example of an issue with a minimum reproducible example. | ||
|
||
[Cloning & Forking a Repository](https://foundations.projectpythia.org/foundations/github/github-cloning-forking.html) | ||
|
||
[GitHub Setup](https://foundations.projectpythia.org/foundations/github/github-setup-advanced.html) | ||
|
||
</exercise> | ||
|
||
<exercise id="2" title="Intermediate Github"> | ||
|
||
Now that you set up your GitHub account, it is time to start collaborating. | ||
|
||
Learn about branches, pull requests, and version control systems. | ||
|
||
[Git Branches](https://foundations.projectpythia.org/foundations/github/git-branches.html) | ||
|
||
[Creating a Pull Request](https://foundations.projectpythia.org/foundations/github/github-pull-request.html) | ||
|
||
[Version Control with Git](https://foundations.projectpythia.org/foundations/github/basic-git.html) | ||
|
||
</exercise> | ||
|
||
<exercise id="3" title="GitHub for project planning"> | ||
|
||
In addition to the issue tracking and collaboration tools mentioned above, GitHub can be really useful for planning and tracking work on a project. | ||
|
||
[GitHub Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) allow to create task boards to priotorize issues to work on or tasks to be completed. Tasks do not have to be issues; you can use cards for free-style writing (e.g., set up DOI through Zenodo). [Several layouts](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/changing-the-layout-of-a-view) are available for optimum planning. | ||
|
||
[Milestones](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones) can be set to track progress on groups of issues in a repository. You can set deadlines for your milestones, which can help you keep on track for deliverables. | ||
|
||
|
||
</exercise> |
This file was deleted.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
This file was deleted.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
/*! | ||
Copyright (c) 2018 Jed Watson. | ||
Licensed under the MIT License (MIT), see | ||
http://jedwatson.github.io/classnames | ||
*/ |
Large diffs are not rendered by default.
This file was deleted.
This file was deleted.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
This file was deleted.
This file was deleted.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
{"polyfill":["/polyfill-7ced8295869eb983463c.js"],"app":["/app-9665833905ede66d943a.js"],"component---node-modules-gatsby-plugin-offline-app-shell-js":["/component---node-modules-gatsby-plugin-offline-app-shell-js-36dc033f967ae9fe9cda.js"],"component---src-pages-index-js":["/component---src-pages-index-js-45241bb2027dd95dc3da.js"],"component---src-templates-chapter-js":["/component---src-templates-chapter-js-e1f8b70a8ff979d25543.js"]} | ||
{"polyfill":["/polyfill-7efc751b3f47cab2dd61.js"],"app":["/app-4c5178681ec49dc3f862.js"],"component---node-modules-gatsby-plugin-offline-app-shell-js":["/component---node-modules-gatsby-plugin-offline-app-shell-js-44ceac2081f421b30e8f.js"],"component---src-pages-index-js":["/component---src-pages-index-js-cf07e5e92ca26298b76e.js"],"component---src-templates-chapter-js":["/component---src-templates-chapter-js-60ca0a4073220fd54e7a.js"]} |
This file was deleted.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.