[FEATURE REQUEST] Remove unnecessary design docs.

[erzetpe]

Is your feature request related to a problem? Please describe.
We have old design docs that can be misleading for someone using Epiphany.

Describe the solution you'd like
We want to review existing design docs and remove unnecessary ones.

Describe alternatives you've considered
None.

Additional context
None.

---

DoD checklist

• Changelog
  • updated
  • not needed
• COMPONENTS.md
  • updated
  • not needed
• Schema
  • updated
  • not needed
• Backport tasks
  • created
  • not needed
• Documentation
  • added
  • updated
  • not needed
• Feature has automated tests
• Automated tests passed (QA pipelines)
  • apply
  • upgrade
  • backup/restore
• Idempotency tested
• All conversations in PR resolved
• Solution meets requirements and is done according to design doc
• Usage compliant with license

[atsikham]

Example - https://github.com/epiphany-platform/epiphany/blob/develop/docs/design-docs/cicd-server/comparision_cicd.md

[rafzei]

@seriva , @atsikham , @to-bar, @plirglo, (and all others)

Please tell me, what do you think about the new approach for design-doc:

The design-doc we store should be related to the feature we are going to implement.
During the SPIKE, design-doc should be created.
After implementing the feature and release a new epicli version design-doc should be removed.

In the following approach, we would avoid a mess in this documentation.

If you agree, I will remove all .md's not related to the release 2.0 version (everything beside rook).

[seriva]

@seriva , @atsikham , @to-bar, @plirglo, (and all others)

Please tell me, what do you think about the new approach for design-doc:

The design-doc we store should be related to the feature we are going to implement.
During the SPIKE, design-doc should be created.
After implementing the feature and release a new epicli version design-doc should be removed.

In the following approach, we would avoid a mess in this documentation.

If you agree, I will remove all .md's not related to the release 2.0 version (everything beside rook).

Yeah I think this is a good idea.

[to-bar]

IMO if feature is present in source code then corresponding design-doc may be helpful for someone to get familiar with the feature (especially when the doc contains a diagram) or to find out why a decision was made.

For me standard docs are rather addressed to users (how to use, user guide) and design-docs are addressed to team members or advanced users (how it works or why that's way).

But I see one problem with keeping a design-doc as long as feature is present - it should be updated - keep in sync with implementation and later changes.