Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE]: Add TEMPLATE FEGA SOP file to this GH repository #40

Open
malloryfreeberg opened this issue Oct 19, 2022 · 5 comments
Open
Labels
feature New feature or request

Comments

@malloryfreeberg
Copy link
Contributor

Feature type(s)

Content modification, Content addition

Location

https://ega-archive.github.io/FEGA-onboarding/topics/technical-operational/#standard-operating-procedures-sops

Description of the change

  1. Add the template to develop SOPs for your own node document to this GH repository.
    1. It is intended that nodes will take a copy of this document and edit it to create their own internal SOPs.
    2. It is not clear whether it is better to add it to this repo as an uneditable document (e.g. PDF) or an editable document (e.g. .docx). Keep in mind that we should choose a format that is as open as possible.
  2. Change the link to this document on this page to point to the version that has been added to the repository.

Reason for the change

Currently, the SOP section of the website contains the text: "It is useful to establish SOPs for common node operational tasks to enable consistent service delivery and streamline internal processes. Use this template to develop SOPs for your own node." The link points to a Google document stored in Google Drive.

As part of working on ELIXIR CONVERGE deliverable D7.4, we want to point to this template. However, it is better to avoid linking to Google documents which can often change and are not stable, and instead link to something more stable, for example materials hosted in this GH repository (i.e. the FEGA Knowledge Base). Therefore, the request is to 1) add the template document (in what format?) to this GH repository, and 2) update the link (on this page) to point to the document in GH so that it is more stable.

@malloryfreeberg malloryfreeberg added the feature New feature or request label Oct 19, 2022
@malloryfreeberg
Copy link
Contributor Author

@ahornos or @M-casado or anyone - suggestions for the best format to add this document as?

@malloryfreeberg
Copy link
Contributor Author

Vote from Salva for a PDF version of the document to be added to GH. Maybe we can add a link to the editable Google document from the PDF file?

@M-casado
Copy link
Collaborator

@malloryfreeberg Some possibilities for the format:

  • Still a google document, but versioned. We could have the "main" file with all the versions and the version history. Whenever we want to produce a stable version, we make a copy in a "sable version folder" of some sort, and put the URL of the copy in the ReadTheDocs. This way its content is still copy-pasteable and we have all stable versions in google drive together (with customizable sharing options, comments...), and if we wanted to we could have a static URL of the "latest version" where we put everything.
    image
    image

  • PDFs to be stored within this repo. Will be static, and we can point to their static URLs within the documentation. The cons. are that there is still no static "latest version"; and we will still need to host a google document to edit the original and produce more PDFs.

@malloryfreeberg
Copy link
Contributor Author

@M-casado let's go with a combo option of having a copy of the latest "stable" version (as a PDF) in this repo (and linked from the ReadTheDocs page) as well as having the "living" version (as a Google doc) linked, as well. This means the Google doc version can be copied and edited by FEGA nodes, and we have a stable version to point to our deliverables.

@M-casado
Copy link
Collaborator

@ahornos and I discussed about the best approach to this and thought of having a google docs that would serve only for internal editing. And every time we released a version of it, we would create a versioned PDF that would be put in the repository. This "latest version" PDF would have a static name that would not change between versions, for the link to be static as well within our documentation.

Besides, we would have a directory with "all versions", for traceability. So every time a new version is released, the commit would have to include two files:

  • The latest version would be uploaded in the "All versions", with its version in the filename.
  • The same latest version would be uploaded as the latest version file.

The file versions needs to also appear explicitly within the file itself.

Example of directory structure:

  • all versions
    • file.v1...
    • file.v2...
  • latestversion.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants