This is a surprising first guideline to me. It is missing an intro why someone would even care about editing system files and the guideline is probably also meant as: Content should now recommend/show (depending on how strong it is supposed to be) how to edid system files. Since this seems to be a very specific case, it should in my opinion not be the first item.

Who is allowed to suspect that non-FOSS software is popular enough to be mentioned? What should someone do before creating such content?

This seems to be very specific if someone needs virtualization.

AFAIK, also official packages are used "at your own risk". The Copr disclaimer should probably be aligned with the one on Fedoramagazine which is also an official channel mentioning Copr all the time:
https://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-from-october-2020/

In my opinion, a guideline should provide guidance about when it is necessary. Also, necessary implies that it is required to name them but then it does not need to be a guideline here.

This is good to mention :+1:

AFAIK, also official packages are used "at your own risk". The Copr disclaimer should probably be aligned with the one on Fedoramagazine which is also an official channel mentioning Copr all the time:

It's literally the same wording as the Magazine guidelines.

This is a surprising first guideline to me. It is missing an intro why someone would even care about editing system files and the guideline is probably also meant as: Content should now recommend/show (depending on how strong it is supposed to be) how to edid system files. Since this seems to be a very specific case, it should in my opinion not be the first item.

So, I read this as you're ok with the guidelone, but not puting it as the first thing?

Who is allowed to suspect that non-FOSS software is popular enough to be mentioned? What should someone do before creating such content?

Well, the marketing team is in charge of content here. If there is no agreement, Mindshare and at last resource the Council

AFAIK, also official packages are used "at your own risk". The Copr disclaimer should probably be aligned with the one on Fedoramagazine which is also an official channel mentioning Copr all the time:

Like it was mentioned, the wording is the same used by the magazine.

In my opinion, a guideline should provide guidance about when it is necessary. Also, necessary implies that it is required to name them but then it does not need to be a guideline here.

I think the title "Name the 3rd parties" do the trick here, but we can be more specific.

Thanks @till for take the time to read and comment this

AFAIK, also official packages are used "at your own risk". The Copr disclaimer should probably be aligned with the one on Fedoramagazine which is also an official channel mentioning Copr all the time:

It's literally the same wording as the Magazine guidelines.

Interesting. So there is some misalignment with the guidelines and the way it is done in practice. Personally, I would avoid guidelines that are not followed in practice. It might only be confusing for new members.

Thank you for highlighting these guidelines because I like their style a lot more, so maybe the youtube guidelines can follow them. I like in the magazine guidelines:

• They clearly state that they are tips not a policy
• The tips for content are called "Content tips" and not just "Content"
• There is a clear introduction about the intent of the rules: "These tips are about things to do — and avoid — in what you tell users to do." This gives a cleaner idea about the tip about packages files

This is a surprising first guideline to me. It is missing an intro why someone would even care about editing system files and the guideline is probably also meant as: Content should now recommend/show (depending on how strong it is supposed to be) how to edid system files. Since this seems to be a very specific case, it should in my opinion not be the first item.

So, I read this as you're ok with the guidelone, but not puting it as the first thing?

yes, sounds like a sane requirement for content that shows instructions.

Who is allowed to suspect that non-FOSS software is popular enough to be mentioned? What should someone do before creating such content?

Well, the marketing team is in charge of content here. If there is no agreement, Mindshare and at last resource the Council

This should be mentioned in the guidelines.

What exactly is the purpose of the document? Is it meant to help people create content for the Youtube channel? Then it should provide more guidance about how people can get started.

I left feedback in Fedora-Council/tickets#323.

Policy was directed to Mindshare. Closing this PR