[bug#72840] [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

[indieterminacy <indieterminacy@libre.brussels>]

It may be that Im lacking a little experience,
but Id assume that the categories outlined earlier probably require 
different timeframes:
https://issues.guix.gnu.org/72840#0-lineno49

A year feels a little arbitrary.

For example, Ive found it a little frustrating using randomly scoured 
Guix snippets -
only to then find that at the moment of utilization that I get a WARNING 
without much context.

Am I the only one who feels undermined and demotivated by information 
which hits me over the head with WARNINGS?

Ive had this using elogin-service (cited before):
https://issues.guix.gnu.org/72840#0-lineno155

Perhaps additionally there need to be pointers to real VCS repos,
pinpointing a commit providing the migration inside a living 
repo/infrastructure?

Such examples would be constructively showing how the change is 
achievable,
and could be empowering through assurance and learning.

And if such /Appreciations/ cannot be found in the wild and covering 
enough common adaptations, then perhaps a Depreciation is too soon?

Heck, a REASSURANCE printed following a reconfigure would be gravy!
Even better, Guix promising me a LIMERICK if I adapted off foobar within 
24 hours would work.

Additionally, its worth pointing out that Im slowly adapting my parsing 
approaches to be more commensurate with a form of modern hermeneutics.

I have been intrigued by how the language inside a setup like Guix 
adapts over time.
As such, the topic of how Guix grammars evolve would be worth 
documenting.

Practically, this could one day result in very old discourse from out of 
date mailinglist or Debugs conversations being transformed into more 
recent grammars to solve contemporary issues or suggest precedent when 
evaluating a patch.

Regards,


Jonathan