Some notes:

• I also considered writing everything to happen inside a Rawhide Toolbox,
  so that there would be no need to specify --enablerepo=rawhide and so on.
  Perhaps that can be added later, for now I left it out to keep this part focused.

• For the checks, I opted to use dnf repoquery instead of the lower level rpm -q
  so that the amount of tools invoked stays as low as possible.
  dnf is used anyway, and it can do all the needed checks.
  if so desired, it is easy to rewrite this to use rpm where possible.

Depending on the package, this may pull in lots of dependencies, so do we want people installing it on their systems? I worry that newcomers may end up polluting their systems and then not know how to undo it all.

Options:

• only do a dry run of the installation
• if doing the installation, use dnf history undo to remove the package and deps after testing
• make them build a package for the release they are on to test its function that way?

"so they require you to have administrator access, and should be run using sudo"? (or should we add sudo in the commands already?

"runtime dependencies"? (to differentiate from BRs, which can also be checked, albeit may not be needed here)

should we add "(what capabilities the package provides)"?

Thank you for the review.
I have addressed the sudo, runtime dependency and capability issues.

For installing, you are right,
the current instructions leave a package behind in the user's installation
and also mixed Rawhide with the user's (presumably) non-Rawhide installation.

I would like to keep the "run the program" part,
so that it is very concrete that the package works.

I think the correct way would be one of there:

• Use a Rawhide Toolbox, so that Rawhide can still be used.
  That is the closest to actual packaging workflow,
  which almost always starts by doing the work in Rawhide.
  Also, the worry about package pollution is solved,
  because the Toolbox is for this purpose only.
  (Personally, I have toolboxes rawhide-packaging, f35-packaging, etc.
  where I do all the test installations and so on,
  and it has worked quite well.)

• Modify everything to use the current release,
  then ask to uninstall in the end.
  It also works, but is a bit different from the real packaging workflow.

If I understand correcty, you have been excercising there instructions
with peole who actually are new to Fedora packaging.
What do you think would work best?

I think for the newcomers I ask them to build for their release and test the package, because I don't want to introduce the concept of toolbx yet---that means knowing a little about containers etc., and that just makes the learning curve a little steeper than it already is.

Do toolboxes work with GUI applications, by the way? (I thought they are just containers and so don't support GUI at the moment, but I haven't checked up on all of this recently)

I guess a probably simpler option would be to ask them to set up a quick vm, install the package, test, and destroy the vm. New folks are more aware of virtual machines (vmware/virtualbox) than they are of containers/toolbx.

We could document the different ways, and say "this is suggested for new comers", "this one is if you are comfortable with containers" and so on?

Yes, you can start a graphical application from inside a Toolbx.
I was using a virtual machine based workflow for graphical applications before,
then I accidentally discovered that Toolbx works for them too,
and switched everything over to use that.
I have never looked back.
Toolbox takes less space, is faster, and integrates better with the host system.
I was using Gnome Boxes for the vms though,
maybe the other tools you mention are better.

I would very much like to come up with a single method that this tutorial uses,
and make that experience great.
Perhaps a separate page for the alternative approach can be added,
which can reference back to the tutorial for the common parts.
I am fine with using virtual machines,
if somebody can come up with a well working system.
Unfortunately, what I managed to create with Gnome Boxes was not that.

So it is like this:

• I can modify the tutorial to use Toolbox,
  but as you mention, perhaps the time of not ripe for that yet.
  I can write a separate article about such workflow at some point
  — actually, maybe there is already something in the Fedora Magazine,
  I have some vague recollection.

• I can modify the tutorial to build for the user's own Fedora release,
  that is a good approach also.

• I am also ok with using virtual machines,
  but I do not want to introduce my clumsy workflow.
  Maybe you or somebody else could help with that?

To keep things simple,
maybe for now defaulting to user's release is the simplest solution?

And, lastly, we could keep the Rawhide approach
and just remove the installation part for now.
I can be added later when somebody takes the time to solve that problem.

Maybe let's leave the user's release for the time being, and note that this is especially useful if folks are also planning to push the new package to the current releases (but that there will time to test the bodhi updates also)?

The toolbx system of testing can perhaps be added to the normal, non-beginner, packager docs as a tip?

Ok, we have a plan.
I will rework this pull request when I find a bit of time.
Stay tuned.

Awesome, thanks very much :)

Done, please check again.
On my part, this is ready to be merged.

LGTM, merging!