Add a Content Contribution section to the README

[Michael-F-Bryan]

Following on from @nasa42's comment on #1003, this adds a Contributing Content section to the README to help give us guidelines on how to review contributions.

---

Previous conversation from #1003 (comment):

Most of the PRs are about adding articles to "News & Blog Posts" section, and a review to determine if the article is worth including to newsletter or not would be quite helpful. Though I need to come up with some rough guidelines first to help determine that.

[Michael-F-Bryan]

@nasa42 I wasn't quite sure how you've been making these decisions in the past, so I've added a couple generic points under the Contributing section. They've probably never been explicitly stated before, so this PR can give us a place to explore things.

---

Thanks for the great work curating the newsletter every week, by the way! I enjoy seeing the TWiR subject line pop up in my inbox because it means I can open the links in a bunch of tabs and see what cool things the community has been up to over the last 7 days 😀

[nasa42]

Thanks for kickstarting this! I've some draft notes that I'll add to this PR.

[gterzian]

Ok so in the light of https://github.com/emberian/this-week-in-rust/issues/1145#issuecomment-585872605, we might want to include something about how articles are selected. Or discuss this in a separate issue because I would say the current PR looks good as it is and this might turn in to a larger discussion.

In terms of selection, I'm in favor of only filtering out the very bad, based on the stuff already in this PR, and not trying to "select the good". Instead, if for a given week there are more submissions then available spots, just make a lottery with a random number generator. If articles don't get a spot, they can re-apply for a later issue. If that becomes a huge bottleneck, then we will have to address it in some other way.

Now if one day we can put together an actual committee to review submissions based on "how good they are", then that could be interesting too. However I assume this is not necessary now, and no one has the time to do this kind of deeper review.

[Michael-F-Bryan]

Now if one day we can put together an actual committee to review submissions based on "how good they are", then that could be interesting too. However I assume this is not necessary now, and no one has the time to do this kind of deeper review.

I think this comment addresses the core of the issue. By its very nature, selecting what does and does not get added to TWiR is going to be a subjective process. We could create some sort of committee to help decide yea or nay, but that's just going to add another layer of bureaucracy, latency, and red tape with minimal benefits.

Having a lot of negative votes on reddit (or some other forum) could act as an indicator that an article might need further scrutiny from a human. While I wouldn't use popularity as the sole metric for quality, it can help with the triage process to weed out items which we may not want to promote in TWiR.

Instead, if for a given week there are more submissions then available spots, just make a lottery with a random number generator.

@nasa42 do you know if we have a rule of thumb for how many articles to publish in TWiR? We could something to the contributing section along the lines of "we try to keep the number of articles in each newsletter under about a dozen (or 5 or 10 or whatever), however this is managed on a case-by-case basis".

[gterzian]

Having a lot of negative votes on reddit (or some other forum) could act as an indicator that an article might need further scrutiny from a human.

I don't know about that. Completely ignorant comments can get a lot of upvotes, so does all sorts of thinly veiled trolling. Both a high and low vote count could be argued to be "an indicator that an article might need further scrutiny from a human". It's the internet after all...

Either you're being rigorous in some way, like a peer-reviewed journal(and I agree it's not practical at this stage), or it might be better not to try at all.

A more robust "quick check" could be simply googling the title of the article, and seeing if it shows up at all, meaning google sees it as some original content worthy of inclusion in search results(this will promote original titles, yeah!).

A look at someones Github profile, which is readily available since the author presumably is the one opening the PR, might also give some information about whether the posted article is some sort of spam or genuinely written by a member of the "Rust community".

Finally, if in doubt, it should be easy enough to just ask the person in the open PR to give a bit more background on themselves, the article and why it should be included. If someone writes a response that seems like in good faith, and there seems to be nothing wrong about the article in terms of community guidelines, I'd say publish it.

If readers have some feedback to give, or feel strongly about an article that was published, I'm sure you'll hear it, probably via an issue here. That will then help further refine the process.

[Manishearth]

I think the most lightweight check would be if something is controversial on reddit or whatever, post it in #community-team on Discord and see what people think.

If something is getting a lot of negative reactions because it's wrong or abrasive, just exclude it, but controversy should be fine.

[gterzian]

If something is getting a lot of negative reactions because it's wrong or abrasive, just exclude it, but controversy should be fine.

Sounds like a good process.

Controversy should be fine indeed...

[nasa42]

@nasa42 do you know if we have a rule of thumb for how many articles to publish in TWiR?

There is no such hard limit. My only concern is to not make the email long enough for Gmail to clip it. On average, we publish about 10-20 links in "News & Blog Posts" section and I'd say 25 is probably the number when it will start to get too crowded.

Also, to keep the focus on technical articles, as a rule of thumb, I usually try to avoid news/posts of following nature:

• Release or new crate announcements (as it would be difficult to mention all releases in a week).
• Introductory articles like "Getting started with Rust", as often times it is unlikely that there will be new information for regular readers.
• Opinionated articles like "Why I love/hate Rust", "My experience with Rust" etc.
• Weekly updates from others projects (for same reasons as for release announcements).

However I often end up making exceptions. And with a content contribution guidelines document, I wanted to quantify/rationalise those exceptions, however it has been hard for me to come up with points except "they're of good quality" or "they'll be helpful to the community" or "this is a major release of a popular crate" (which aren't really quantifiable and are quite subjective, e.g., what makes a crate popular?). (Also, in contrast, "they have more upvotes on reddit" is quantifiable).

I obviously failed to close this issue. I'll now let new maintainers decide content contribution guidelines (see #1167).

[pkrasam]

I have been thinking, we should consider a way to implement a decentralised voting mechanism for the community to voice their opinion on which of the articles will/should make its way into the TWiR newsletter.

[nasa42]

I have been thinking, we should consider a way to implement a decentralised voting mechanism for the community to voice their opinion on which of the articles will/should make its way into the TWiR newsletter.

That's basically reddit. :-)
(and TWiR sources its articles from reddit).

[matu3ba]

@nasa42 do you know if we have a rule of thumb for how many articles to publish in TWiR?

There is no such hard limit. My only concern is to not make the email long enough for Gmail to clip it. On average, we publish about 10-20 links in "News & Blog Posts" section and I'd say 25 is probably the number when it will start to get too crowded.

Labeling the items to have an exact overview would help there. See #1235

Also, to keep the focus on technical articles, as a rule of thumb, I usually try to avoid news/posts of following nature:

* Release or new crate announcements (as it would be difficult to mention all releases in a week).

* Introductory articles like "Getting started with Rust", as often times it is unlikely that there will be new information for regular readers.

* Opinionated articles like "Why I love/hate Rust", "My experience with Rust" etc.

* Weekly updates from others projects (for same reasons as for release announcements).

However I often end up making exceptions. And with a content contribution guidelines document, I wanted to quantify/rationalise those exceptions, however it has been hard for me to come up with points except "they're of good quality" or "they'll be helpful to the community" or "this is a major release of a popular crate" (which aren't really quantifiable and are quite subjective, e.g., what makes a crate popular?). (Also, in contrast, "they have more upvotes on reddit" is quantifiable).

I obviously failed to close this issue. I'll now let new maintainers decide content contribution guidelines (see #1167).

Basically #1235 is an attempt to fix this without having big noise overview. I am not exactly sure on the phone view of tables however. At least internally the table would however help.
Feel free to add your suggestions of label names and their abbreviations.

[nellshamrell]

Closing due to the age of this pull request

[Michael-F-Bryan]

@nellshamrell is it still worth having some sort of guideline for what is included in TWiR?

Even a paragraph or some dot points in the README explaining the intended audience or what sorts of articles are normally included would be useful. That way authors can decide what articles to submit, and it gives curators something to point when they need to say "sorry, but I don't think this article is a good fit for TWiR".

[nellshamrell]

That is a good point - and something that I will add into the README