Bring files from the EGI repo template

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,95 @@
+# Code of Conduct
+
+This code of conduct applies to the maintainers and contributors alike.
+
+## Dealing with issues and support requests
+
+_We wish to add a specific section on dealing with issues opened against the
+repository here._
+
+This repository exists in the context of the EGI Federation. While that scope
+does not restrict the usage, it does inform the priority we assign to issues and
+the order we deal with them.
+
+We welcome issues reported by the public, and more specifically the community of
+people using this repository.
+
+The EGI team is small and cannot support all requests equally.
+
+While we undertake to do everything in our power to respond to issues in a
+timely manner, and to prioritise issues based on reasonable requests from
+submitters, the maintainers expect that the prioritisation of issues as decided
+by them is respected.
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of
+experience, nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+## Our Standards
+
+Examples of behaviour that contributes to creating a positive environment
+include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behaviour by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behaviour and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behaviour.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviours that they deem inappropriate, threatening,
+offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behaviour may be
+reported by contacting the EGI Foundation team at [email protected]. The team will
+review and investigate all complaints, and will respond in a way that it deems
+appropriate to the circumstances. The team is obligated to maintain
+confidentiality with regard to the reporter of an incident. Further details of
+specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,52 @@
+<!--
+Thank you for opening an issue in our repository.
+Please use the template below to construct the issue.
+
+Dealing with issues:
+- Issues opened here will be evaluated by the maintainers, and given priority
+  based on that evaluation.
+- Support is provided on a best-effort basis
+- See the CODE_OF_CONDUCT.md for a deeper description of how we deal with support
+  and issues.
+-->
+
+# Short Description of the issue
+
+<!--
+Please provide a plain-language description of what you would like to report.
+By using simple, concise language, you can help the maintainers understand the
+issue and context, and thereby help them prioritise it.
+-->
+
+## Environment
+
+<!--
+Provide details of the environment you used when this error occurred
+-->
+
+- Operating System:
+- Other related components versions:
+
+## Steps to reproduce
+
+<!--
+If this is a runtime or other error, please describe what you did to generate the
+error
+-->
+
+## Logs, stacktrace, or other symptoms
+
+<!--
+If you have logs or other supporting information like the stack trace from python,
+etc, paste it here.
+Use markdown formatting to put output in code blocks
+-->
+
+```shell
+output
+```
+
+<!-- the section below is optional - remove it if you don't know what to propose,
+but merely want to report an issue.  -->
+
+# Summary of proposed changes

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,17 @@
+<!--
+A good PR should describe what benefit this brings to the repository.
+Ideally, there is an existing issue which the PR address.
+
+Please check the Contributing guide CONTRIBUTING.md for style requirements and
+advice.
+-->
+
+# Summary
+
+<!-- Describe in plain English what this PR does -->
+
+---
+
+<!-- Add, if any, the related issue here, e.g. #6 -->
+
+**Related issue :**

.github/dependabot.yml

@@ -0,0 +1,16 @@
+---
+version: 2
+updates:
+  # Maintain dependencies for GitHub Actions, yarn and python
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "daily"
+  - package-ecosystem: "yarn"
+    directory: "/"
+    schedule:
+      interval: "daily"
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "daily"

.github/linters/mlc_config.json

@@ -0,0 +1,21 @@
+{
+  "httpHeaders": [
+    {
+      "urls": ["https://docs.github.com/"],
+      "headers": {
+        "Accept-Encoding": "zstd, br, gzip, deflate"
+      }
+    }
+  ],
+  "ignorePatterns": [
+    {
+      "pattern": "^http://localhost"
+    },
+    {
+      "pattern": "^https://example.com"
+    },
+    {
+      "pattern": "https://github.com/EGI-Federation/REPOSITORY/issues/new"
+    }
+  ]
+}

.github/workflows/check-links.yml

@@ -0,0 +1,30 @@
+---
+name: Check links
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  markdown-link-check:
+    name: Check links using markdown-link-check
+    runs-on: ubuntu-latest
+
+    steps:
+      # Checks out a copy of your repository on the ubuntu-latest machine
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          # Make sure the actual branch is checked out when running on PR
+          # ref: ${{ github.event.pull_request.head.sha }}
+          # Full git history needed to get proper list of changed files
+          fetch-depth: 0
+
+      - name: Check links on new changes
+        uses: gaurav-nelson/github-action-markdown-link-check@v1
+        with:
+          config-file: ".github/linters/mlc_config.json"
+          check-modified-files-only: "yes"
+          use-quiet-mode: "yes"
+          use-verbose-mode: "yes"
+          base-branch: "main"

.github/workflows/lint.yml

@@ -0,0 +1,33 @@
+---
+name: Lint
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  super-lint:
+    name: Lint with Super-Linter
+    runs-on: ubuntu-latest
+
+    steps:
+      # Checks out a copy of your repository on the ubuntu-latest machine
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          # Make sure the actual branch is checked out when running on PR
+          # ref: ${{ github.event.pull_request.head.sha }}
+          # Full git history needed to get proper list of changed files
+          fetch-depth: 0
+
+      # Runs the Super-Linter action
+      - name: Run Super-Linter on new changes
+        uses: docker://ghcr.io/github/super-linter:slim-v4
+        env:
+          DEFAULT_BRANCH: main
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          MARKDOWN_CONFIG_FILE: .markdownlint.json
+          # Only check new or edited files
+          VALIDATE_ALL_CODEBASE: false
+          # Fail on errors
+          DISABLE_ERRORS: false

CODEOWNERS

@@ -0,0 +1,10 @@
+# https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
+# https://github.blog/2017-07-06-introducing-code-owners/
+
+# Assign code owners that will automatically get asked to review Pull Requests
+# The last matching pattern takes the most precedence.
+
+# These owners will be the default owners for everything in the repo.
+# Unless a later match takes precedence, they will be requested for
+# review when someone opens a pull request.
+* @EGI-Federation/notebooks

CONTRIBUTING.md

@@ -0,0 +1,92 @@
+# Contributing
+
+Thank you for taking the time to contribute to this project. The maintainers
+greatly appreciate the interest of contributors and rely on continued engagement
+with the community to ensure that this project remains useful. We would like to
+take steps to put contributors in the best possible position to have their
+contributions accepted. Please take a few moments to read this short guide on
+how to contribute; bear in mind that contributions regarding how to best
+contribute are also welcome.
+
+## Feedback and Questions
+
+If you wish to discuss anything related to the project, please open a
+[GitHub issue](https://github.com/EGI-Federation/REPOSITORY/issues/new).
+
+## Contribution Process
+
+Before proposing a contribution via pull request (PR), ideally there is an open
+issue describing the need for your contribution (refer to this issue number when
+you submit the pull request). We have a 3 steps process for contributions.
+
+1. Fork the project if you have not, and commit changes to a git branch
+1. Create a GitHub Pull Request for your change, following the instructions in
+   the pull request template.
+1. Perform a [Code Review](#code-review-process) with the maintainers on the
+   pull request.
+
+### Pull Request Requirements
+
+1. **Explain your contribution in plain language.** To assist the maintainers in
+   understanding and appreciating your pull request, please use the template to
+   explain _why_ you are making this contribution, rather than just _what_ the
+   contribution entails.
+
+### Code Review Process
+
+Code review takes place in GitHub pull requests. See
+[this article](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
+if you're not familiar with GitHub Pull Requests.
+
+Once you open a pull request, maintainers will review your code using the
+built-in code review process in GitHub PRs. The process at this point is as
+follows:
+
+1. A maintainer will review your code and merge it if no changes are necessary.
+   Your change will be merged into the repository's `main` branch.
+1. If a maintainer has feedback or questions on your changes then they will set
+   `request changes` in the review and provide an explanation.
+
+## Using git
+
+For collaboration purposes, it is best if you create a GitHub account and fork
+the repository to your own account. Once you do this you will be able to push
+your changes to your GitHub repository for others to see and use, and it will be
+easier to send pull requests.
+
+### Branches and Commits
+
+You should submit your patch as a git branch named after the GitHub issue, such
+as `#3`\. This is called a _topic branch_ and allows users to associate a branch
+of code with the issue.
+
+It is a best practice to have your commit message have a _summary line_ that
+includes the issue number, followed by an empty line and then a brief
+description of the commit. This also helps other contributors understand the
+purpose of changes to the code.
+
+```text
+    #3 - platform_family and style
+
+    * use platform_family for platform checking
+    * update notifies syntax to "resource_type[resource_name]" instead of
+      resources() lookup
+    * GH-692 - delete config files dropped off by packages in conf.d
+    * dropped debian 4 support because all other platforms have the same
+      values, and it is older than "old stable" debian release
+```
+
+## Release cycle
+
+Main branch is always available. Tagged versions may be created as needed
+following [Semantic Versioning](https://semver.org/) as far as applicable.
+
+## Community
+
+EGI benefits from a strong community of developers and system administrators,
+and vice-versa. If you have any questions or if you would like to get involved
+in the wider EGI community you can check out:
+
+- [EGI site](https://www.egi.eu)
+
+**This file has been modified from the Chef Cookbook Contributing Guide**.