Hi,
I've had a look at the current state of doc-rework.
I'll reply the specific point sajolida asked for in the dedicated
threads, so this email is rather for anything that does not fit in
there.
,----
| /download
`----
I wonder if we should s/Latest release/Latest stable release/. What do
others think?
I don't like that much the link to the ISO file because it adds one
more manual step to the release process.
About hash verification, again: shall we really update this page with
new hashes when we release new images?
More generally, this page seems to contain tons of stuff that should
be updated on every release, which annoys me a bit. But well, if you
feel like it makes downloading / explaining really easier, not the end
of the world, but contribute/release_process shall be updated
accordingly then. What worries me more is... what happens when PowerPC
images come back?
The "Using the command line" way links to the .sha256 file on mirrors.
For consistency with the above explanations (e.g. reliance on HTTPS)
and with the next method ("Using Firefox"), I believe it should link
to the same file hosted on *our* website instead. Am I misunderstood?
> Older computers might not be able to start from a USB stick.
I doubt such computers are able to run Tails at all => I'm in favor of
removing this sentence.
,----
| usb-install-for-linux
`----
GNOME Disk Utility might be an easier way to find the source /
destination disks path.
When cloning Tails USB->USB, if the destination stick is smaller than
the source one, an error is likely to be displayed. The user should be
explained this is not really a problem.
,----
| links to anchors
`----
The now doc pages make heavy use of links to anchors such as
doc/warning#index3h1. Since this relies on the titles numbering, I
think this is much too error-prone and likely to be quickly
outdated... I already found one such broken link just by browsing the
documentation, hence this remark. When we need to link to a specific
paragraph of a big page, I think a better way to go would be to split
the big page into sub-pages and have the big one built using
[[!inline]] from the sub-pages. (git grep'ing our wiki's source will
provide a few real-world examples of this technique)
=> we can link to the subpage we want and easily notice broken links.
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Do not be trapped by the need to achieve anything.
| This way, you achieve everything.
