Context: it's currently a mess:, and at times contradictory

• There is policy involving those three, as can be seen from the shepherd mess.
• This policy is partially secret, as can be seen by some people treating some things as policy even if it's not in the manual.
  
• Some versions of the policy are based on archeology, e.g. see the 'snippets were introduced for this particular purpose, so don't use it for other things’ which is not documented in the manual as sole legitimate reason and asking contributors to read all past discussions seems too much for me.
• Sometimes, people refer to the manual (Snippets versus Phases) for how things (should) work, but what they say is not actually present in that section of the manual.
  
• Some variants of the policy are contradictory with each other (IIRC)
• Some of the policies are contradictory with current practice in other Guix packages.
  
• '(guix)Snippets versus Phases says Phases' states that it is elusive.
• The section name implies it's a ‘X versus Y’, which seems polarizing? (Maybe?)
  
• The section neglects the is/ought-distinction -- it just says what is typically used for what, not whether they should be used for them and whether they are allowed to be used for other things, so that section does not seem policy to me (except for the single 'should produce' and 'must not' line), only matters of fact.
  

I can't work with such a mess. As such, I've a proposal for a consistent, clear and non-elusive set of rules and guidelines, based on the following principles:

• It appears we cannot agree on what exactly the policy should be, but having a single policy everyone can use even if some would rather have the specifics be a tiny bit different, is much better than the mess of everyone having their own policy.
• There are no absolutes, except that the result of "guix build --source" must be free software;
• There can be more than one (acceptable) way to do things, but this doesn't make things elusive, this just means there are multiple acceptable options and you should probably go for the simplest.
  

More concretely, I propose the following new contents for (guix)Snippets versus Phases (the phrasing could use some work for smooth reading), which I believe to be sufficiently clear (except for some phrasing that could be tweaked, e.g. the phrases are currently rather long), covers a sufficient amount of cases (feel free to respond if you see a missing case), free of contradictions (likewise) and mostly in line with current practice:

[start]

@c: There is no opposition or such, so no versus, let's not start with polarisation.

20.4.5 Snippets, phases and patches

Snippets, phases and patches at times serve overlapping purposes. To decide between the three, there are several considerations to keep in mind:

• Patches must not be used to remove non-free files, because a patch by construction contains the non-free file itself so the patch would be non-free, which would not be acceptable to Guix. Likewise, patches should not be used to remove bundled libraries, to avoid large space usage, but this is not an absolute rule unlike as for non-free files.
  
• Snippets are often convenient for removing unwanted files such as bundled libraries, non-free sources and binaries. It is technically also possible to use phases for this, albeit slightly less convenient at times. However, phases must not be used to remove non-free sources, as then the output of "guix build --source" would still contain the non-free sources, which is incompatible with Guix' stance on free software. Likewise, phases should not be used to remove binaries; however, this is not strictly forbidden.
  
• Snippets must not embed store items in the source, as this is incompatible with cross-compilation and prevents effectively sharing the source code produced with "guix build --source" with people using non-Guix systems.
• In principle, you can apply a patch from a phase. However, this causes the result of "guix build --source" to not correspond to the actual source code anymore (i.e., it doesn't act as corresponding source anymore), so consider this a last resort for situations such as avoiding causing a world-rebuild for a patch fixing a target-specific bug by making the patching conditional upon target-foo?. If you apply a patch from a phase, make sure that the patch appears in the inputs or native-inputs, such that "guix build --source=all" will include the patch.
  
  @c this relaxes the old rule a little
  

• Ideally, the source derived from the origin should be usable for building on any system that the upstream package supports (even if Guix does not support that system), as a courtesy to the people that the source code is shared with. However, this is not an absolute rule, most important is that it is usable on Guix and it is allowed to neglect this recommendation when it is tricky to follow or a large amount of work. For example, if some Windows-specific source files are non-free, you can simply remove them without replacing them by a free implementation, even if that would reduce the set of systems the package can be built on.

Sometimes, there remains more than one acceptable way to accomplish the goal. In that case, choose whatever appears to be most convenient.

[end]

(Comments welcome, and required to go forward)

Greetings,
Maxime