adding pip install and code documentation

YouSchnabel · Oct 29, 2024 · 3443df3 · 3443df3
1 parent e77d964
commit 3443df3
Show file tree

Hide file tree

Showing 26 changed files with 3,676 additions and 66 deletions.
diff --git a/.github/workflows/build_docs.yml b/.github/workflows/build_docs.yml
@@ -0,0 +1,51 @@
+# Sample workflow for building and deploying a Jekyll site to GitHub Pages
+name: Deploy Jekyll with GitHub Pages dependencies preinstalled
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches: ["main"]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Build job
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Setup Pages
+        uses: actions/configure-pages@v5
+      - name: Build with Jekyll
+        uses: actions/jekyll-build-pages@v1
+        with:
+          source: ./
+          destination: ./_site
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
diff --git a/README.md b/README.md
@@ -1,3 +1,5 @@
+[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/YouSchnabel/EVERSE-landscape/HEAD)
+
 # EVERSE-landscape
 
 This repository serves to evaluate the outcomes of the landscaping survey from WP2 of the EVERSE project.

diff --git a/codemeta.js b/codemeta.js
@@ -0,0 +1,43 @@
+{
+    "@context": "https://doi.org/10.5063/schema/codemeta-2.0",
+    "@type": "SoftwareSourceCode",
+    "license": "https://spdx.org/licenses/BSD-3-Clause",
+    "codeRepository": "https://github.com/YouSchnabel/EVERSE-landscape",
+    "dateCreated": "2024-10-29",
+    "datePublished": "2024-10-30",
+    "name": "EVERSE landscaping survey",
+    "version": "0.1",
+    "description": "Outcome and analysis of the EVERSE software quality survey.",
+    "readme": "https://github.com/YouSchnabel/EVERSE-landscape/blob/main/README.md",
+    "softwareVersion": "0.1",
+    "author": [
+        {
+            "@type": "Organization",
+            "givenName": "Jutta",
+            "familyName": "Schnabel",
+            "email": "[email protected]"
+        },
+        {
+            "@type": "Person",
+            "givenName": "Jutta",
+            "familyName": "Schnabel",
+            "email": "[email protected]",
+            "affiliation": {
+                "@type": "Organization",
+                "name": "FAU Erlangen, ECAP"
+            }
+        }
+    ],
+    "maintainer": [
+        {
+            "@type": "Person",
+            "givenName": "Jutta",
+            "familyName": "Schnabel",
+            "email": "[email protected]",
+            "affiliation": {
+                "@type": "Organization",
+                "name": "FAU Erlangen, ECAP"
+            }
+        }
+    ]
+}
diff --git a/data/README.md b/data/README.md
@@ -1,52 +1,5 @@
 # Survey data
 
-## Goal of the survey
-
-The overall goal of the EVERSE project is to evaluate and improve the quality of research software. This can be facilitated by collecting best practices on the one hand, and providing and sharing experiences especially in those areas where quality guidance and support is needed.
-
-To this end, the goal of the survey should lay the ground to
-
-* Identify communities and resources providing and well applying best practices (lighthouse practices)
-* Identify commonalities throughout the research clusters (common practices)
-* Identify gaps and deficits in software research practices (areas of improvement)
-
-## Questionnaire setup
-
-### Respondents 
-
-For the initial landscaping, the research areas and practices should be covered as widely as possible to be able to identify the areas of improvements. This will, due to limited responses, increase the inaccuracy of the survey. On the other hand, allowing more specific responses from experts in the fields would help to identify lighthouse practices. 
-
-Therefore, the respondents are asked to distinguish between two answering modes:
-
-1. Reporting on their own practices, or their group and institution's practices (single view),
-2. Assuming a general view on the research field they represent and estimating from best knowledge how the practices in the research field are established (representative view).
-
-While everyone can answer the survey from a single view, a dedicated list of respondents is requested to fill the survey from a representative view, as well as specific experts. This information is captured in the first part (P).
-
-### Software levels
-
-In order to differentiate practices at different levels of software applicability, three software levels are introduced (analysis code, prototype tools, research software infrastructure). Participants are asked to exemplify these software levels for their area and give descriptions (D) and evaluate practices then according to these levels (L1-L3).
-
-### Sections
-Elements of the survey are annotated according to the section and functionality:
-
-* Personal information: used to categorize the answers and evaluate the profile of the survey participant
-* Software level evaluation: evaluation of the applicability of software levels
-* Software levels: categorization per software level (L1 - L3)
-* Software description: description of the software per level
-* Guidelines: Guidelines and financing of quality practices
-* Technical software quality practices: elements of technical software practices
-* Management practices: aspects of software project management and incentivisation
-
-### Question types
-
-* Free text
-* References
-* Choice
-* Selection
-* Rating
-* Ranking
-
 ## Export from EU survey
 
 The export from the EU survey ("Results"-tab) should include to "Show Assigned Values" in the Settings, and be performed to the xls format.

diff --git a/docs/_config.yml b/docs/_config.yml
@@ -1 +1,6 @@
-theme: minima
+theme: minima
+
+include:
+    - about
+    - pages
+    - pydocs
diff --git a/docs/about/.ipynb_checkpoints/thesurvey-checkpoint.md b/docs/about/.ipynb_checkpoints/thesurvey-checkpoint.md
@@ -0,0 +1,37 @@
+## Goal of the survey
+
+The overall goal of the EVERSE project is to evaluate and improve the quality of research software. This can be facilitated by collecting best practices on the one hand, and providing and sharing experiences especially in those areas where quality guidance and support is needed.
+
+To this end, the goal of the survey should lay the ground to
+
+* Identify communities and resources providing and well applying best practices (lighthouse practices)
+* Identify commonalities throughout the research clusters (common practices)
+* Identify gaps and deficits in software research practices (areas of improvement)
+
+## Questionnaire setup
+
+### Respondents 
+
+For the initial landscaping, the research areas and practices should be covered as widely as possible to be able to identify the areas of improvements. This will, due to limited responses, increase the inaccuracy of the survey. On the other hand, allowing more specific responses from experts in the fields would help to identify lighthouse practices. 
+
+Therefore, the respondents are asked to distinguish between two answering modes:
+
+1. Reporting on their own practices, or their group and institution's practices (single view),
+2. Assuming a general view on the research field they represent and estimating from best knowledge how the practices in the research field are established (representative view).
+
+While everyone can answer the survey from a single view, a dedicated list of respondents is requested to fill the survey from a representative view, as well as specific experts. This information is captured in the first part (P).
+
+### Software levels
+
+In order to differentiate practices at different levels of software applicability, three software levels are introduced (analysis code, prototype tools, research software infrastructure). Participants are asked to exemplify these software levels for their area and give descriptions (D) and evaluate practices then according to these levels (L1-L3).
+
+### Sections
+Elements of the survey are structured according to the section and functionality:
+
+* Personal information: used to categorize the answers and evaluate the profile of the survey participant
+* Software level evaluation: evaluation of the applicability of software levels
+* Software levels: categorization per software level (L1 - L3)
+* Software description: description of the software per level
+* Guidelines: Guidelines and financing of quality practices
+* Technical software quality practices: elements of technical software practices
+* Management practices: aspects of software project management and incentivisation
diff --git a/docs/about/analysis.md b/docs/about/analysis.md
diff --git a/docs/about/thesurvey.md b/docs/about/thesurvey.md
@@ -0,0 +1,38 @@
+# Survey setup
+## Goal of the survey
+
+The overall goal of the EVERSE project is to evaluate and improve the quality of research software. This can be facilitated by collecting best practices on the one hand, and providing and sharing experiences especially in those areas where quality guidance and support is needed.
+
+To this end, the goal of the survey should lay the ground to
+
+* Identify communities and resources providing and well applying best practices (lighthouse practices)
+* Identify commonalities throughout the research clusters (common practices)
+* Identify gaps and deficits in software research practices (areas of improvement)
+
+## Questionnaire setup
+
+### Respondents 
+
+For the initial landscaping, the research areas and practices should be covered as widely as possible to be able to identify the areas of improvements. This will, due to limited responses, increase the inaccuracy of the survey. On the other hand, allowing more specific responses from experts in the fields would help to identify lighthouse practices. 
+
+Therefore, the respondents are asked to distinguish between two answering modes:
+
+1. Reporting on their own practices, or their group and institution's practices (single view),
+2. Assuming a general view on the research field they represent and estimating from best knowledge how the practices in the research field are established (representative view).
+
+While everyone can answer the survey from a single view, a dedicated list of respondents is requested to fill the survey from a representative view, as well as specific experts. This information is captured in the first part (P).
+
+### Software levels
+
+In order to differentiate practices at different levels of software applicability, three software levels are introduced (analysis code, prototype tools, research software infrastructure). Participants are asked to exemplify these software levels for their area and give descriptions (D) and evaluate practices then according to these levels (L1-L3).
+
+### Sections
+Elements of the survey are structured according to the section and functionality:
+
+* Personal information: used to categorize the answers and evaluate the profile of the survey participant
+* Software level evaluation: evaluation of the applicability of software levels
+* Software levels: categorization per software level (L1 - L3)
+* Software description: description of the software per level
+* Guidelines: Guidelines and financing of quality practices
+* Technical software quality practices: elements of technical software practices
+* Management practices: aspects of software project management and incentivisation
diff --git a/docs/pages/.ipynb_checkpoints/chap_finance-checkpoint.md b/docs/pages/.ipynb_checkpoints/chap_finance-checkpoint.md
@@ -0,0 +1,21 @@
+## Financial support
+
+### Sources of financing
+|    | Type                                                                       | Lifecycle stage   |
+|---:|:---------------------------------------------------------------------------|:------------------|
+|  6 | Many projects are also EU funded                                           | project funding   |
+| 10 | another national example: the funding via the Netherlands eScience Centre: | project funding   |
+|    | https://www.esciencecenter.nl                                              |                   |
+|    | Type                                                                                                                                                       | Lifecycle stage   |
+|---:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------|
+| 10 | recently, the EU OSCARS project https://oscars-project.eu had funding opportunities for research including software - this is an example for side funding: | side funding      |
+|    | Description                      | Lifecycle stage                                                                                                                                                                                                                                                               |
+|---:|:---------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|  6 | nan                              | Increase the recognition of research software engineering work and research software engineers (it's probably close to reputation but different in the sense that funders and high level management need to recognize the importance of this part of a scientific experiment) |
+|  9 | nan                              | Pride, vanity                                                                                                                                                                                                                                                                 |
+| 10 | Planning; Development; Archiving | Sharing of code with others                                                                                                                                                                                                                                                   |
+| 11 | nan                              | Gamification (Badges etc.)                                                                                                                                                                                                                                                    |
+| 12 | nan                              | no                                                                                                                                                                                                                                                                            |
+| 21 | nan                              | Get experience in using best practices for professional development                                                                                                                                                                                                           |
+| 25 | nan                              | Because the RSE is actually genuinely interested in the result/science                                                                                                                                                                                                        |
+| 27 | nan                              | Increase user base, consider options for technology transfer                                                                                                                                                                                                                  |