Versioned resources copyedits #178
Conversation
This "Viewing previous versions" guide seems worth being more prominent than managing an installation or contributing guides. I also think this is more of an explanatory document than how-to guide, which suggests it belongs under our "About" section instead, but I'll discuss that with the team first.
|
@jameshadfield Just a few small edits for consistency which I think are improvements. Overall the document you wrote is a great compact and punchy guide-by-example of the dated snapshots feature! |
|
Ah, I'll fix that CI warning tomorrow. |
There was a problem hiding this comment.
Thanks! Nice to have someone else's eyes on these things.
First three commits seem good to me.
I'm ambivalent about "snapshot" (yes I realise I used it in the overview paragraph) so it'd be good to get some other opinions from the team about what language is best used here. In the (internal facing) code I use "version" and don't want to change that.
The document already used the term "snapshot" a bit, and I think it's less ambiguous/overloaded than "version" so use it consistently. "Analyses" is already in use in other document and section titles, so use that term in those contexts. I didn't update the source document file names here, but maybe I should…
tsibley
force-pushed
the
trs/versioned-resources-copyedits
branch
from
7a470d6
to
528c9a3
Compare
Nod. Your usage of "snapshot" there is what made me think about the terminology here for user-facing docs. I think "snapshots" will be clearer than "versions" for typical users and not muddied with the unrelated topic of software versions. Definitely fine to keep using "version" internally. |
I've merged those (merge commit be6d3f5). Will wait for the remaining two. |
|
Conclusion at the biweekly all-hands discussion just now was "snapshot", so I've merged. |
See commit messages for details.
Related to #177.
Checklist