Merge pull request #527 from InnerSourceCommons/370-caption-positioning

370-caption-positioning

Author: marshmallowrobot

CONTRIBUTING.md

@@ -28,10 +28,77 @@ Here is [an example](https://github.com/InnerSourceCommons/InnerSourceLearningPa
 * Here is the [status of translation efforts](https://github.com/InnerSourceCommons/InnerSourceLearningPath/wiki/Translations).
 * Other mechanics of working on translations follow the guidelines below that apply to any file in the `InnerSourceLearningPath`.
 
-# Subtitles
+# Video Subtitles
+
+All videos may have subtitles in any language. See [this video](https://drive.google.com/file/d/1IaAH8Zmp2ggBtelexhaZUqia5yS8mUjE/view?usp=sharing) for a short intro on how to access them.
+
+## Adding Subtitles For the First Time
+
+YouTube will automatically generate subtitles to most videos in English.
+It is easiest to use that as a starting point to then manually clean up timings and correct misspellings.
+  1. In Creator Studio, select DUPLICATE AND EDIT on the automatic subtitles.
+  2. When you are satisfied with your changes in the subtitle editor, choose PUBLISH.
+
+## Changing Existing Subtitles
+
+Be aware that, at this time, Creator Studio does not support subtitle positioning natively.
+The subtitle editor only addresses content and timings.
+If your video needs positioning changes, the tags must be added or adjusted manually.
+
+Subtitle positioning will NOT be reflected in the video in the editor.
+All subtitles will appear at the bottom of the viewport while using the editor.
+It is also NOT currently possible to download a VTT file of a DRAFT subtitle set.
+Finally, making changes in the editor and publishing them will erase all pre-existing positioning tags.
+
+Therefore, the overall process for editing subtitles with positioning goes like this:
+  1. In Creator Studio, download a copy of the current VTT file (or look in source control for it).
+  This gives you a back up of the existing set in case you want to completely revert your changes.
+  2. Make your content and timing changes using the subtitle editor and PUBLISH them.
+    _This erases pre-existing positioning tags._
+  3. Download a copy of the new VTT file.
+  4. Using your favorite text editor, add positioning tags and save the file.
+  5. Go back to the subtitle editor, upload the new VTT file with positioning tags, and PUBLISH it to close the editor.
+  6. Add the updated VTT file with positioning tags to source control.
+
+If your video does not require positioning adjustments, you only need to do step #2.
+
+## Subtitle Style Guide
+
+  * Keep subtitle height to a single line. **Never display more than two lines in height**, to prevent content blocking.
+  * Keep subtitle width to the central 60% of the viewport. **Do not to let them extend to the full width of the viewport.**
+    Drawing eyeballs to the extreme edges of the screen distracts from the content.
+  * **Subtitles should be centered horizontally and shown at the bottom of the viewport**, unless this would obscure important visual information.
+    In these cases, use positioning tags to put the subtitle at the top of the viewport.
+    Revert to the bottom position when the scene allows.
+    No matter where the subtitle ends up being placed, try to avoid obscuring the mouths of speakers in shot.
+  * Try to display subtitles for at least 1.5 seconds before changing or disappearing them, to aid reading comprehension.
+    This isn't always possible, however,
+    **never display a subtitle for less than one second**.
+  * **Subtitles should be timed to the speaker's voice.**
+    They should appear when the speaker starts, and disappear when the speaker is finished and before a camera change, unless that causes the subtitle to be on screen for less than one second.
+  * **Display words as spoken**, not as you think the speaker intended to say them.
+    Do not censor or simplify the dialogue.
+    Strive for accuracy.
+    There are two exceptions:
+    - Omit stuttering
+    - Omit filler words like ("um")
+    - _This runs counter to most captioning guidelines.
+      However, we have had complaints in the past for subtitling these.
+      Given these exceptions, don't automatically omit words like "but" or "so".
+      These are filler words, but they are often essential for expressing meaning.
+      Similarly, conversational phrases like "you know", and "right" often add flavour and should be included when time allows._
+  * It is only necessary to identify a speaker when it is not obvious to the viewer.
+    This is rare, even in cases where there are two speakers in a scene, since they speak one-at-a-time.
+    But, it can happen, for example, when a diagram is being displayed and there are multiple speakers off screen.
+    **If we do need identification, use a label in all caps.**
+    Here are some examples:
+    - _(single speaker)_ DANESE: This diagram will help us understand how InnerSource works.
+    - _(two speakers)_ BOTH: Hope to see you there!
+    - _(three or more)_ ALL: Fa la la la la!
+
+
+
 
-* All videos may have subtitles in any language.
-* See [this video](https://drive.google.com/file/d/1IaAH8Zmp2ggBtelexhaZUqia5yS8mUjE/view?usp=sharing) for how to add them.
 
 # Files
 

introduction/02-problems-solved-captions-en.vtt

@@ -0,0 +1,256 @@
+WEBVTT
+Kind: captions
+Language: en
+
+00:00:04.620 --> 00:00:05.760
+In this video segment,
+
+00:00:05.760 --> 00:00:09.166
+we'll discuss the types of problems where InnerSource can help.
+
+00:00:09.920 --> 00:00:12.758
+We'll do this by presenting a hypothetical,
+
+00:00:12.758 --> 00:00:14.758
+yet believable collaboration scenario.
+
+00:00:15.400 --> 00:00:17.033
+We'll examine common approaches
+
+00:00:17.033 --> 00:00:19.900
+that teams take for this type of situation,
+
+00:00:19.900 --> 00:00:21.444
+and both the advantages,
+
+00:00:21.444 --> 00:00:23.639
+and the drawbacks, of each approach.
+
+00:00:24.240 --> 00:00:26.344
+This conversation will help us to draw
+
+00:00:26.344 --> 00:00:28.925
+conclusions and lessons about InnerSource.
+
+00:00:29.909 --> 00:00:31.576
+Well, imagine two teams,
+
+00:00:31.895 --> 00:00:35.382
+with one producing software that is consumed by another.
+
+00:00:35.960 --> 00:00:37.140 line:0%
+To make it concrete,
+
+00:00:37.352 --> 00:00:40.241 line:0%
+imagine a team producing an API Service
+
+00:00:40.800 --> 00:00:44.160 line:0%
+that a team producing a User Experience consumes.
+
+00:00:45.460 --> 00:00:49.628 line:100%
+At times, to deliver desired features, the Experience 
+
+00:00:49.922 --> 00:00:52.756
+may need to make a request for new functionality
+
+00:00:52.881 --> 00:00:54.051
+from the API.
+
+00:00:54.580 --> 00:00:57.081
+Oftentimes, the API will be able to deliver
+
+00:00:57.081 --> 00:00:58.909
+this requested functionality. 
+
+00:00:58.909 --> 00:00:59.938
+No problem.
+
+00:01:00.604 --> 00:01:03.311
+However, depending on schedules,
+
+00:01:03.630 --> 00:01:05.860
+or other prioritizing constraints,
+
+00:01:06.232 --> 00:01:08.634
+there may be times when that new functionality
+
+00:01:08.634 --> 00:01:10.136
+can't be delivered right away.
+
+00:01:11.140 --> 00:01:12.186
+In this scenario,
+
+00:01:12.469 --> 00:01:15.451
+the Experience has a few options they might take.
+
+00:01:16.447 --> 00:01:18.706
+The first we'll call "Wait It Out".
+
+00:01:19.671 --> 00:01:20.693 line:15%
+With this approach,
+
+00:01:20.693 --> 00:01:23.540 line:15%
+the Experience does nothing, and simply waits,
+
+00:01:23.540 --> 00:01:27.847 line:15%
+hoping that the API will eventually be able to fill their feature request.
+
+00:01:29.040 --> 00:01:32.126 line:0%
+Now, the advantage is that probably it requires
+
+00:01:32.126 --> 00:01:36.489 line:0%
+the least amount of extra work on the part of the Experience.
+
+00:01:37.360 --> 00:01:39.000 line:0%
+There's a clear drawback though,
+
+00:01:39.000 --> 00:01:42.606 line:0%
+in that, the Experience doesn't get their desired functionality.
+
+00:01:42.860 --> 00:01:43.960 line:0%
+At least, not right away.
+
+00:01:44.440 --> 00:01:48.960 line:0%
+And, depending on future prioritization on the part of the API,
+
+00:01:49.460 --> 00:01:51.880 line:100%
+that feature may not be delivered at all.
+
+00:01:53.300 --> 00:01:56.700
+Another approach we'll call "Workaround".
+
+00:01:57.694 --> 00:02:01.508
+With this approach, the Experience may do some extra work
+
+00:02:01.508 --> 00:02:05.412
+to compensate for the lack of the requested functionality.
+
+00:02:05.900 --> 00:02:09.740 line:15%
+This may be extra work in their own project,
+
+00:02:09.900 --> 00:02:11.550 line:15%
+or they may start up a new project
+
+00:02:11.550 --> 00:02:15.654 line:15%
+that gives them the functionality they were looking for via some other means.
+
+00:02:16.640 --> 00:02:20.060 line:0%
+The benefit here is that the Experience can get what they want,
+
+00:02:20.480 --> 00:02:23.080 line:0%
+when they want it, and by their own effort only.
+
+00:02:23.260 --> 00:02:25.320 line:0%
+No dependency on another team.
+
+00:02:25.980 --> 00:02:27.460 line:0%
+There's some real drawbacks though.
+
+00:02:28.240 --> 00:02:30.901 line:0%
+The Experience has inadvertently signed up
+
+00:02:30.901 --> 00:02:34.304 line:0%
+for the long term burden of maintenance of this new code.
+
+00:02:34.740 --> 00:02:39.740 line:0%
+It's code that oftentimes is not in the domain of their core team competency.
+
+00:02:41.000 --> 00:02:44.220 line:0%
+In addition, other teams of the company that have the same problem,
+
+00:02:44.460 --> 00:02:47.640 line:0%
+are unable to use this specialized, one-off solution.
+
+00:02:48.320 --> 00:02:52.780 line:0%
+And the company as a whole has acquired duplicate code and projects
+
+00:02:53.240 --> 00:02:57.940 line:0%
+in the same problem area that are being worked on in an uncoordinated manner.
+
+00:02:59.320 --> 00:03:02.180 line:100%
+Another approach we'll call "Escalate".
+
+00:03:03.240 --> 00:03:07.020 line:15%
+With "Escalate", the experience doesn't take no for an answer,
+
+00:03:07.020 --> 00:03:10.800 line:15%
+but attempts to influence the API to reconsider
+
+00:03:10.880 --> 00:03:13.700 line:15%
+and prioritize their requested functionality.
+
+00:03:14.840 --> 00:03:19.510 line:15%
+Oftentimes this appeal is made to somebody in the management hierarchy
+
+00:03:19.510 --> 00:03:20.878 line:15%
+of the API.
+
+00:03:21.280 --> 00:03:24.849 line:15%
+It's common for the request to come from someone in the management hierarchy
+
+00:03:24.849 --> 00:03:26.116 line:15%
+of the Experience.
+
+00:03:26.260 --> 00:03:29.080 line:15%
+Let's get the bosses together, have them talk it out.
+
+00:03:30.180 --> 00:03:34.240 line:0%
+The potential advantage is that the Experience can get what it wants,
+
+00:03:34.820 --> 00:03:35.760 line:0%
+when it wants it,
+
+00:03:36.320 --> 00:03:39.780 line:0%
+without needing to maintain the new code long term.
+
+00:03:40.800 --> 00:03:42.140 line:0%
+There are several disadvantages.
+
+00:03:42.880 --> 00:03:45.460 line:0%
+In practice, the process of escalation
+
+00:03:46.060 --> 00:03:50.220 line:0%
+tends to have high friction and take a large amount of time.
+
+00:03:50.940 --> 00:03:56.410 line:0%
+And this time is spent by competent engineers and engineering leaders
+
+00:03:56.420 --> 00:03:58.745 line:0%
+whose time is directed toward the non-productive
+
+00:03:58.745 --> 00:04:01.314 line:0%
+non-engineering task of escalation.
+
+00:04:03.360 --> 00:04:06.440 line:0%
+This process is so time intensive that it doesn't scale.
+
+00:04:06.620 --> 00:04:10.789 line:0%
+A team that attempts to continually advocate for what it needs
+
+00:04:10.820 --> 00:04:13.959 line:0%
+via escalation will simply run out of the time
+
+00:04:13.959 --> 00:04:16.294 line:0%
+and social credibility that it needs to do so.
+
+00:04:17.940 --> 00:04:20.440 line:100%
+This conversation teaches us about InnerSource.
+
+00:04:20.760 --> 00:04:25.460
+And that InnerSource is meant to apply to the same type of collaborative situation
+
+00:04:26.160 --> 00:04:31.080
+where a team producing software is unable to deliver functionality
+
+00:04:31.360 --> 00:04:33.140
+that a team that's consuming it needs.
+
+00:04:34.140 --> 00:04:38.760
+What InnerSource does is provide a way for the consuming team to get the benefits
+
+00:04:39.140 --> 00:04:42.000
+of "Wait it Out", "Workaround", and "Escalate"
+
+00:04:42.220 --> 00:04:44.240
+without those associated drawbacks.
+