docs: Update templates

[aarnq]

Warning

This is a public repository, ensure not to disclose:

• personal data beyond what is necessary for interacting with this pull request, nor
• business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• kind/feature
• kind/improvement
• kind/deprecation
• kind/documentation
• kind/clean-up
• kind/bug
• kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

• kind/admin-change
• kind/dev-change
• kind/security
• kind/adr

What does this PR do / why do we need this PR?

Updates issue templates, removes the release template, and updates the linting based on changes done in the docs repo.

Information to reviewers

The wildest change is to rename all go-templates bases and stacks, but that will be come a requirement in helmfile (once they decide to release v1), and we already use that for our values templates.
And it fits more naturally, because they aren't yaml.

And as it touches a bit of everything, I believe everyone is a reviewer, sorry bout that 😅

Checklist

• Proper commit message prefix on all commits
• Change checks:
  • The change is transparent
  • The change is disruptive
  • The change requires no migration steps
  • The change requires migration steps
  • The change upgrades CRDs
  • The change updates the config and the schema
• Documentation checks:
  • The public documentation required no updates
  • The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • The metrics are still exposed and present in Grafana after the change
  • The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • The logs do not show any errors after the change
• Pod Security Policy checks:
  • Any changed pod is covered by Pod Security Admission
  • Any changed pod is covered by Gatekeeper Pod Security Policies
  • The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • Any changed pod is covered by Network Policies
  • The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • The change does not cause any unnecessary Kubernetes audit events
  • The change requires changes to Kubernetes audit policy
• Falco checks:
  • The change does not cause any alerts to be generated by Falco
• Bug checks:
  • The bug fix is covered by regression tests

[AlbinB97]

This looks great, amazing work!

[anders-elastisys]

LGTM, just had one comment

[cristiklein]

I need to understand the reason why the QA checklist is made private. We really like to show this and it's even linked to from our public docs.

[aarnq]

I need to understand the reason why the QA checklist is made private. We really like to show this and it's even linked to from our public docs.

Because the process simply hasn't worked well after the split, so the checklist that we need for our process must be together with the internal one.

I do also want to expose it in some way to make the actual QA part public, but I haven't figured out a good way to do it yet. My thinking is a document in each artefact repository, as then it will also serve as a reference for contributors for what we expect to be tested.
However it would be formatted essentially as "this is what we test, and what we expect to be tested" document, rather than the unwieldy checklist itself.

[aarnq]

I need to understand the reason why the QA checklist is made private. We really like to show this and it's even linked to from our public docs.

Because the process simply hasn't worked well after the split, so the checklist that we need for our process must be together with the internal one.

I do also want to expose it in some way to make the actual QA part public, but I haven't figured out a good way to do it yet. My thinking is a document in each artefact repository, as then it will also serve as a reference for contributors for what we expect to be tested. However it would be formatted essentially as "this is what we test, and what we expect to be tested" document, rather than the unwieldy checklist itself.

Restored and updated it with the current changes, along with an alert that it is going to be replaced.

[viktor-f]

A lot of nice cleanup, well done.

[viktor-f]

Nice work with these updates, I think it looks good.

One small nit for future PRs: I think that these changes could actually have been a few different commits (possibly different PRs), since it to me feels like there are several different things happening here that does not necessarily belong together. E.g. it could have been split to one for updating templates, one for lint changes, one for renaming the stacks files. Another alternative would be to have a longer commit message that makes it more clear the different things that were included, or something that just makes it clear that there are several different things in it without specifying exactly what.
I do not think that it is worth reworking this now and I do not see it as important. But if you agree with my reasoning, then keep it in mind for future PRs. 🙂

[aarnq]

Nice work with these updates, I think it looks good.

One small nit for future PRs: I think that these changes could actually have been a few different commits (possibly different PRs), since it to me feels like there are several different things happening here that does not necessarily belong together. E.g. it could have been split to one for updating templates, one for lint changes, one for renaming the stacks files. Another alternative would be to have a longer commit message that makes it more clear the different things that were included, or something that just makes it clear that there are several different things in it without specifying exactly what. I do not think that it is worth reworking this now and I do not see it as important. But if you agree with my reasoning, then keep it in mind for future PRs. 🙂

Thanks, I'll think about that!

The problem is that the "templates" that I'm producing consist of pre-commit hooks and configs, workflows, issue and pull request templates, even some scripts. 😅
But I will definitely split some of them up onto separate commits so it is clearer from the start what originates from where.

[cristiklein]

Thanks for keeping our quality high! Let's discuss how to make the quality checklist public once this PR is merged and the linkchecker on elastisys.io complains. 😄