Remove outdated content

[bouweandela]

Much of the content of the guide is outdated and/or has been moved to The Turing Way. I will make a start with removing this content, as it reflects poorly on the center.

[egpbos]

When we are done with this issue, we may need to remove the sentence that may be added through #285 about the outdated sections ;)

[egpbos]

Things to remove:

• Checklist: remove completely.
• Version control: Policy -> Project Management Protocol (PMP), "we use GitHub" as well.
• Code quality
• Code reviews
• Licensing: "we use Apache v2" -> PMP. Rest is in Turing Way.
• Communication: already in PMP: output management.
• Testing
• Releases
• Documentation: update & move to Turing Way.
• Standards: not really stressed in the Turing Way. Make issue there? Connect to code quality, mention FAIR. There's something about data standards. In Code Quality there's style standards. Should be more stressed: interoperability & reusability by using standards.
• Teamwork
• NLeSC specific stuff:
  • Only keep chapter owners in chapters themselves
  • Projects
  • Checklists
  • E-infrastructure
• Intellectual property: -> PMP already in IP policy and Turing Way

Keep:

• UX
• Language guides: need update!

Add:

• Julia
• Rust
• Matlab?
• Go?
• Look into https://softwaresaved.github.io/international-survey-2022/country/world/#tools-and-programming-languages
• ML guide?

[LourensVeen]

I think IP already went to the Turing Way, and anyway we have our IP Policy. Does that leave anything for the PMP?

[egpbos]

Yes, you're right, thanks!

[egpbos]

One part of the e-infrastructure Guide that may be useful to keep is https://guide.esciencecenter.nl/#/nlesc_specific/e-infrastructure/e-infrastructure?id=security-and-convenience-when-committing-code-to-github-from-a-cluster, what do you think @bouweandela @c-martinez? Not sure where to put it, though.

For reference, the rest of it is duplicated here btw: https://nlesc.sharepoint.com/sites/home/SitePages/Access-to-Infrastructure.aspx

[bouweandela]

The github documentation also explains how to set this up: https://docs.github.com/en/authentication/connecting-to-github-with-ssh

[egpbos]

I will open a separate issue for this.

[egpbos]

See also #335

[PabRod]

In order to facilitate this task and make it more parallelizable, I suggest to redo the original task list following this structure:

For straightforward replacements

Most materials were just moved to the Turing Way, but yet we need to map them. Having a clear mapping list would greatly help contributors to execute the subtasks. I suggest entries like this:

• Material to be removed (linked) --> Link to replacement

For replacements spread among many links

Some materials have been split and moved to more than one destination (e.g.: part to the Turing way, part to the Project Management Protocol). In this case the mapping has more than one destinations. In this case, I suggests tasks items such as:

• Material to be removed (linked) --> Link one
• .................................................. --> Link two

For non-replacements

Any tasks including keep, add or update don't belong here, but in their own issues.

Afterwards

Removals always leave a trail of destruction. Let's clean after ourselves.

• Check for broken links

What do you think, @egpbos, @bouweandela?

[egpbos]

I will pick this up now.

[egpbos]

Straightforward replacements

Materials that were moved to the Turing Way that we want to map (using links to the Turing Way or RSQkit or other reputable sources) in the Best Practices chapter (see #321 and #360).

• Checklists
  • Add a section to Best Practices; the PR where it was removed contains links.
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Version control
  • Add a section to Best Practices.
    • NLeSC-internal note: refer to the PMP, "we preferably use GitHub".
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Code quality
  • Add a section to Best Practices.
  • Remove the chapter
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Code reviews
  • Add a section to Best Practices.
  • Remove the chapter
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Licensing
  • Add a section to Best Practices.
    • NLeSC-internal note: refer to the PMP, "we preferably use Apache v2".
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Communication
  • Add a section to Best Practices.
    • NLeSC-internal note: refer to the PMP, section "output management"
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Testing
  • Add a section to Best Practices.
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Releases
  • Add a section to Best Practices.
  • Remove the chapter
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Teamwork
  • Add a section to Best Practices.
  • Remove the chapter PR
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)
• Intellectual property
  • Add a section to Best Practices.
    • NLeSC-internal note: refer to the PMP, section "IP policy"
  • Remove the chapter: PR together with licensing
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)

A bit more work + replacements

Any tasks including keep, add or update don't belong here, but in their own issues.

• Documentation chapter

  • Update & move to Turing Way.
  • Add a section to Best Practices.
  • Remove the chapter
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)

• Standards chapter

  • Not really stressed in the Turing Way. Make issue there? Connect to code quality, mention FAIR. There's something about data standards. In Code Quality there's style standards. Should be more stressed: interoperability & reusability by using standards.
  • Add a section to Best Practices.
  • Remove the chapter
  • Afterwards: check for broken links (globally! the PR link checker only checks changed files...)

Add?

• Julia?
• Rust?
• Matlab?
• Go?
• Look into https://softwaresaved.github.io/international-survey-2022/country/world/#tools-and-programming-languages
• ML guide?

[egpbos]

Ok, I was hoping the above list would be auto-convertible to issues, but seems that doesn't work :(

[egpbos]

I will just manually make issues out of the above list then...

[egpbos]

Additions?

These addition issues are long term. They need not be tracked, so I will just make separate issues for them.

• Julia
• Rust
• Matlab
• Go
• Look into https://softwaresaved.github.io/international-survey-2022/country/world/#tools-and-programming-languages
• ML guide

[egpbos]

Done! Everything moved to other issues now. Closing this one.