Fedora-Council / council-docs

Clone
Source Code
GIT

#92 Add the YouTube policy drafted by @x3mboy
Closed 3 years ago by bcotton. Opened 3 years ago by bcotton.
youtube_proposal  into  main

file modified
+1 
@@ -9,6 +9,7 @@ 
 

  ** xref:policy/community-publishing-platforms.adoc[Community Publishing Platforms]
 

  ** xref:policy/guiding-policy.adoc[Guiding Policy]
 

  ** xref:policy/policy-change-policy.adoc[Policy Change Policy]
 

+ ** xref:policy/youtube.adoc[Policy/process for adding video content to YouTube channel]
 

  ** xref:policies.adoc[Additional Policies]
 

  * Council Procedures
 

  ** xref:procedures/infra_priorities_board.adoc[Infrastructure Priorities Board]

file added
+52 
@@ -0,0 +1,52 @@ 
 

+ = Policy/process for adding video content to YouTube channel
 

+ 

+ == Content
 

+ 

+ Content posted to the https://youtube.com/fedora[official Fedora YouTube channel] should follow the following guidelines:
 

+ 

+ * **Do not edit system files:**
till commented 3 years ago

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.

 
+ Processes should not involve editing files under system folders like `/usr` or `/lib*`. Edit `/etc` or a user-specific configuration in the home directory.
 

+ * **Prefer free software and officially packaged software:**
 

+ Content in the YouTube channel can still cover non-FOSS software to be used on Fedora, where we know or suspect that software is very popular and useful to Fedora users (Google Chrome is a good example).
till commented 3 years ago

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

+ * **Use libvirt/KVM in tips**
till commented 3 years ago

This seems to be very specific if someone needs virtualization.

 
+ The KVM hypervisor and libvirt in Fedora are FOSS and part of the platform.
 

+ * **Use Fedora family distributions:**
 

+ The Fedora YouTube channel promotes Fedora.
 

+ Unless the point of your article is to specifically explain a cross-distribution mechanism, use installations, containers, or distributions within its family (Fedora, CentOS, RHEL).
 

+ If you're going to cover installation of packages, please use a clean fresh installed VM (or only with updates).
 

+ * **Copr software must be accompanied by a caveat:**
 

+ The Copr build system is not managed by the Fedora release team and does not provide official software builds.
 

+ If you cover some software from Copr, ensure there’s no official build.
 

+ If not, include a statement like this: COPR is not officially supported by Fedora infrastructure. Use packages at your own risk.
till commented 3 years ago

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/

 
+ * **Avoid exclusionary or problematic language:** These are examples of terminology to avoid wherever possible in videos:
till commented 3 years ago

This is good to mention :+1:

 
+ ** _blacklist_/_whitelist_: Use allowlist/denylist instead, which is more directly descriptive of the purpose.
 

+ ** _master_/_slave_: Use primary/secondary, primary/replica, active/passive, active/standby, or another similar construct.
 

+ * **Test your process:**
 

+ If possible, use a fresh guest VM, or at least a brand-new user account.
 

+ Run your process from beginning to end to ensure it works.
 

+ * **Name the third parties:**
 

+ In Fedora we respect the works of everyone, so please name people and companies when necessary, and do it with respect.
till commented 3 years ago

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.

 
+ * **Do not use copyrighted material:**
 

+ If you want to include any media, video, images, audio and specially music, please use sources with free licences.
 

+ * **Create your description and title:**
 

+ Part of the process of creating content includes video description that can include links to Fedora sites, other content or blogs.
 

+ Videos without titles and descriptions won't be uploaded.
 

+ * **License:**
 

+ The license will be always Creative Commons Attribution (CC BY) or one more open, since that will be the license we will use to publish the video in the channel.
 

+ 

+ == Format
 

+ 

+ Video is special in terms of quality.
 

+ In the case of YouTube, you need to use the https://support.google.com/youtube/troubleshooter/2888402?visit_id=637370920066052092-3674751603&hl=en&rd=1[supported formats].
 

+ There are also some https://support.google.com/youtube/answer/1722171[recommendations about containers, codecs, bitrate and more].
 

+ We recommend to upload HDR videos only, and an aspect ratio of 16:9 with a 720p resolution or higher.
 

+ 

+ == Process
 

+ 

+ The video that will be upload should be reviewed by the Marketing team, to check content and format via a issue in the https://pagure.io/fedora-marketing/issues[Marketing issue tracker].
 

+ 

+ Once the video is approved, it will be shared with the social media team and/or with the people that have access to upload videos in the channel
 

+ Please take into consideration the fact the video will be shared with the CC BY License on YouTube, and by sharing the video with the Fedora Marketing Team the video will be used with that license.
 

+ 

+ If content is considered controversial or video is rejected, a ticket with Mindshare can be filed to discuss the content.
 

+ Mindshare will have the final decision about if the video should be upload.

no initial comment

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.

Policy was directed to Mindshare. Closing this PR

Pull-Request has been closed by bcotton
3 years ago
Metadata
None
No Tags
Changes Summary 2
+1 -0
file changed
council/modules/ROOT/nav.adoc
+52
file added
council/modules/ROOT/pages/policy/youtube.adoc
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.