Randomise wording of release posts

[jamesmbaazam]

I think the release posts template stands a high chance of becoming monotonous in wording. I would suggest we randomize certain words in new posts to add a bit of dynamism in wording.

For example, in

epiverse-trace.github.io/_templates/release.qmd

Line 9 in 4421f49

We are very excited to announced the release of a new {{ pkgname }} version {{ v }}.

, we could sample synonyms for "excited" from a package like syn. For example

replicate(3, paste("We are", sample(as.vector(unlist((syn::syns("excited")))), 1), "to announce the release of a new"))
#> [1] "We are hopped up to announce the release of a new" 
#> [2] "We are breathless to announce the release of a new"
#> [3] "We are tickled to announce the release of a new"

Some of these are cringe but I'm sure we can find a way around this. This issue is just to sow a seed.

[Bisaloo]

Thanks, I like it!

I'd welcome a PR for this. One idea could be to look at how the tidyverse team is doing it. Ideally, we wouldn't use the exact same set of options but the framework might be re-usable.

[jamesmbaazam]

Good point. I'll take a look in the course of the week.

[chartgerink]

@jamesmbaazam is this still something you are planning to work on? Given that you assigned it to yourself, I have held off on working on it - so I thought I'd check in 😊

[jamesmbaazam]

Hey Chris, I forgot to provide an update on this. I realised that the tidyverse was doing it manually and I figured it was for a good reason; the release posts are independent of the randomisation of words so if we're to go by this, we'll have to couple them somehow. I have therefore held back on implementing this. A manual solution would be to have a list of words/phrases to use and then record which post was assigned.

Please feel free to close this issue or implement a solution that you deem fit.

[chartgerink]

Thanks @jamesmbaazam - I marked the issue as unplanned but will leave it open for others to work on if they wish. If this issue is not tackled over the next few months, we can close it at that point (for convenience: when the issue is a year old).

[Bisaloo]

Hey Chris, I forgot to provide an update on this. I realised that the tidyverse was doing it manually and I figured it was for a good reason; the release posts are independent of the randomisation of words so if we're to go by this, we'll have to couple them somehow. I have therefore held back on implementing this. A manual solution would be to have a list of words/phrases to use and then record which post was assigned.

Please feel free to close this issue or implement a solution that you deem fit.

If I understand correctly, you're highlighting the fact we don't want a new random word to be selected each time the post is re-rendered, is that correct?

If that's the issue, a solution could be to select the word in _scripts/create_release_post.R and add it to the .qmd document as part of the knitr::knit_expand() call. The phrasing would then be hardcoded in the .qmd document and not susceptible to further accidental change.

[jamesmbaazam]

If I understand correctly, you're highlighting the fact we don't want a new random word to be selected each time the post is re-rendered, is that correct?

No, but that is also a consideration that I had not thought about. Changes like typos, etc, should not lead to a new word/phrase being resampled in _templates/release.qmd.

Let me rephrase: At the time of composing a new release blog post, we want to use a random word/phrase that is not the same as the one used in previous posts OR previous release posts from the same package. However, the workflow that generates the new post does not know what word/phrase the previous post used. So, we will need a way to track this.

[Bisaloo]

Ok, got it!

I'm not too concerned about this. I have seen a handful of tidyverse posts using the same phrase and I don't think it's a big issue. I'd just go with a random phrase and overlook the potential for having the same phrase twice in a row. It'll still be on average less repetitive than the current solution.

(And if our readers are used to working with probabilities, they will no doubt excuse us for this 😁)