Standardize preferred date/time format in docs guidelines

[eloquence]

We've used non-technical date and time formats (used to explain e.g. important dates admins need to be aware of) somewhat inconsistently in the docs (e.g., "30 April" vs. "April 30"). Let's standardize, and update the guidelines. AP style seems like a good fit for the English language docs as it's unambiguous and more user-friendly than ISO dates (2019-02-26) for this purpose.

(Edit 2020-10-20) Usage is now largely consistent, but we should still document it as part of the docs guidelines.

[ptrubatch]

I'd like to work on this, if it's still needed.

[rmol]

@ptrubatch Great! But I just searched the current docs and it looks like the date/time inconsistencies may have been fixed since this ticket was opened. @eloquence, could you check the occurrences you had in mind and see if that's right?

[ptrubatch]

@rmol I thought that might be the case! Thanks for the response. If so, I'll keep an eye out for other docs-related issues that might be good for a beginner. This seems like a great project, and I'd love to contribute.

[rmol]

@ptrubatch It is a great project 🙂 and we'd love you to contribute. Help with our documentation is really appreciated, and a beginner is more likely to catch us using jargon or assuming a reader has too much background. I looked through the open documentation issues and found a few that are just a little more involved than this one:

• freedomofpress/securedrop#4082 (linking SecureDrop-specific terms in our source and journalist guides to our glossary; requires creating links in reStructured Text)
• Define and standardize OSSEC Alert Key terminology #44 (being more consistent and precise in naming the GPG keys used to encrypt email alerts; should just be text changes, and we can help explain those keys and their usage before you start)
• Improve consistency of multi-factor auth terminology securedrop#2331 (using two-factor authentication terms more consistently; I think this one might involve changing strings in SecureDrop source code, not just docs, but don't let that put you off, as one of us will be happy to work with you)

If you'd like to work on one, just leave a comment on the issue and a maintainer will assign it to you. And of course these are just suggestions; if another issue interests you more, go for it.

In fact, thinking about what I said above, I also have another idea: if you'd like to take the time to read through our source guide, imagining you're trying to figure out how to safely share something with a news organization, and jotting down all your questions and concerns we don't address, I think that would be really valuable. You could share that feedback in a new issue, or less formally in our Gitter channel (feel free to contact us there with any questions you have about the project or contributing).

Thanks again for the interest!

[eloquence]

@eloquence, could you check the occurrences you had in mind and see if that's right?

I can also not spot any remaining inconsistencies. There were some in the old upgrade docs which were removed in 5041732. I think it would still be good to add a note about the preferred style (for dates per current practice, MonthName Day, Year, e.g., "December 3, 2018") to the docs guidelines to resolve this issue.

[ptrubatch]

@rmol Thanks so much for taking the time to share those suggestions! I really appreciate it. To start out, I like the idea of reading through the source guide, imagining I'm a potential user. I'll work on that these next few days before moving on to the existing open issues.

[eloquence]

(Retitled/edited for clarity of remaining scope.)

[eloquence]

@joaedwar Good candidate issue for you to work on, all we need to do to close this out is 1) double-check that we're indeed using a consistent date/time format for any remaining date/time references, 2) if so, document it in the documentation guidelines.