added english caption files for intro videos

Author: marshmallowrobot

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.
+