シャドーイング練習: [REC] Key Meeting - Engineering (Public Stream) - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

320 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

Hi, this is Eric Johnson.

It's February 18th, 2021, and this is the engineering key review at GitLab.

So I've got number four in the agenda, which is a proposal to break up this meeting into four department key reviews.

So currently this is engineering,

development, quality, security, and UX infrastructure and support do their own key reviews already.

I have the reasons why increased visibility, able to go deeper, increase the objectivity with which my reports can manage their groups,

allow me more time to focus on new markets, and allow me to shift into more of a question asker mode than generating content and answering questions in these meetings.

But to avoid adding three net new meetings to stakeholders' calendars, I propose we do a sort of two-month rotation.

So month one, development quality go.

Month two, security and UX would go.

How do people feel about that proposal?

I think in the group conversations, it's working really well um so i'm i'm supportive

and uh this is the smallest thing maybe we need four

meetings a month like it's the biggest department it's super essential but you propose this i don't uh

i could see either way so let's stick with the proposal

cool we'll try it

and we'll uh we can be flexible i mean the development is larger maybe they go more frequently

or something like that but we'll see how it see how it goes all right

and then i've got number five um

which is uh we've got um r d overall mr rate

and we also have r d wider mr rate both as top level kpis for engineering

so the difference between them in the simplest sense is that R&D wider MR rate includes both community contributions and community MRs.

The problems I see with this are that one, the wider MR rate, the one that includes internal and external MRs, it duplicates the overall MR rate,

which is- Wait, wait, wait, wait, sorry, sorry.

The wider MR rate should just be external, right?

Right.

And then overall should be narrow plus wider.

Oh, yeah.

Like we say the wider community.

Right, right, right.

Okay. So there's...

I have to check the taxonomy.

Lily, can you confirm SID's reasoning is my understanding as well?

Yeah, I believe water MR rate just captures community contributions.

Only and no internal.

Yeah, and the reason we measure that is

that like one of the most likely failure modes is that we lose the community.

Yeah.

So Eric, where it gets goofy is that when you look at a specific team within the company,

there could be contributions outside of that that aren't community contributions.

They would be viewed community contributions by that group, but effectively they're not from outside the company.

So that's why we use wider to kind of reflect that.

And narrow is very specific to the team.

Are you saying that if someone in plan contributes to verify, it's viewed as wider?

Not quite that.

Plan and verify are just fine.

It's when you look at like the development versus infrastructure infrastructure will oftentimes contribute to developments work

but it won't be counted as MRs. Okay that's a that's a potential bit of funkiness that we should talk about separately.

I didn't have that in my sort of critique of this but that that doesn't necessarily make intuitive sense to me.

So then I think part of my critique of this can be thrown out

because it's not as duplicative as I thought

but I still think there's a problem with R&D wider MR rate

which is this thing doesn't really move in part

because it's a it's a rate

so it feels like the way to drive this up is

to specifically drive community authors to contribute more than one MR per month that's how this moves up

because it's a it's a productivity rate like we use internally

and that doesn't necessarily feel like the right thing

because there's scenarios in which this goes up we've actually got less contributions overall and less contributors overall.

Wait a second.

So you're saying that R&D wider MR rate is number MRs per external contributor?

Oh my goodness.

That should not be the thing.

It should be contributions per GitLab team member.

So the thing above the division is the external ones.

The thing below is the number of team members at GitLab.

Is that the case, Lily?

I'm checking right now.

I think so in our numerator.

It says for the marks merge per team member.

So unless we start calling people outside the company team member, then it shouldn't be done.

Yeah, just clarifying here.

So So our numerator is community contributions, and then our denominator is GitLab team members.

So it's not per external member.

So we- So what we're doing there,

Eric, is we're not trying to say how many MRs does someone send if they send something,

we're saying how many MRs from external do we get for the size of our organization

sorry i have a childhood emergency outside the door So maybe explain the context behind this.

The context is as we grow as a company, we should make sure we keep the community up.

Like the logical thing is for the community to flatline and the size of the org to grow.

And before you know it, you've kind of outgrown the wider community.

Yeah.

And what I'm seeing is we created this pre-sophisticated taxonomy with prefixes

and post fixes to talk about these things

but in reality we've only got two of them

and it's we keep forgetting and we have a hard time discussing this thing so i'd rather just name them simply

some two names for what they are rather than than using

that taxonomy but also like in f i have this proposal of like what

if we just tracked as a kpi the percentage of total mrs

that come from the community over time and we would see

that drop i love that i love that let's do that instead Okay.

But the thing why we have this complex thing is because you can game that.

You want to game that, you just produce fewer MRs with the engineers at GitLab.

So if you drive that really hard and say, this is your number one goal, it's very easy to achieve.

You just tell all your engineers to produce half.

Yeah.

So we have different metrics to prevent that from happening the same way

that like support SLA as an asset kind of buttress one another.

I think we're robust to that.

100

But simplifying this would make these conversations go much easier.

101

If you, as our CTO, don't even understand them, we went overboard.

102

So I'm supportive.

103

You don't understand them.

104

And I forgot.

105

And I was agreeing to stuff this morning.

106

I'm like, there's a problem with this.

107

And then you just remind me of the context.

108

So yeah, if I can't hold it in my head.

109

Percentage that come from the community.

110

I love that.

111

It's what all our investors ask about.

112

Let's do that.

113

Okay, cool.

114

So Lily, if you can work with Max to make that transition, that would be great.

115

And I'll bold the one that we're talking about.

116

That's Roman Rimmel 3.

117

Thanks.

118

I'm on the call.

119

Sorry, it was a bit late.

120

Timeline, we do have PIs on the raw number of community MRs, and we can make the shift.

121

And wider confirming from the definition, I think wider only counts for community, and that's what the definition is.

122

Cool.

123

All right, so number six then, Christopher.

124

Sorry, I was looking up to see if I had the percentage graph, because I think we played around with this at one point and had a draft of that probably about five months back,

125

if I can remember, Lily.

126

Just an FYI, the month of February, if you were looking at any particular metrics, particularly in development and MR rate,

127

we haven't had updates in four days there's apparently a lag

128

issue that's been problematic for the data team to basically get updated metrics and they're working on that.

129

I'm sorry, Mech, you got the next one.

130

So yeah, there's some color there on mitigation, the lag later on.

131

On to 7, and we continue as an FYI in addition to the KPI status.

132

I'm sorry, I want to just touch on the Postgres replication issue there real quick.

133

I'm trying to get my arms wrapped around it.

134

Do we have the right attention to this?

135

This is kind of, Eric, I don't know

136

if you were commenting on hinting towards this in the last meeting around some of the infrastructure improvements on the product side.

137

I'm just not quite sure whose responsibility it is to focus

138

on getting a handle on some of the constraints we have in replication.

139

Yeah, what I was mentioning in the product key review about an hour ago is I think is sort of like unrelated.

140

And so I think the DRI needs to be your kind of data engineering team.

141

But of course, there's a dependency on infrastructure because that's where the data is being piped from.

142

They do own that data source.

143

Yeah, I'll say for the replication lag on that slave host where, I'm sorry, not the, on the,

144

the secondary host where the data is being pulled from, like the infrastructure would be the DRI for that.

145

And so any escalations, but I'll, I'll own those.

146

And I know we have an action plan for

147

that as far as creating another dedicated host just for the data team to pull from.

148

Okay.

149

I did actually, I saw that issue

150

and I did talk to Craig Gomes a little bit as well on the database side, just to see if there's some database improvements.

151

And I'm still trying to figure out, you know, if it's truly just a dedicated computational sort of resource,

152

a server, or if there's actually some database tuning that needs to occur.

153

Do you have a sense of that?

154

There's, so I'd say it's three different things.

155

It's having a dedicated host that doesn't have conflicting query traffic coming from other workloads.

156

There are some tuning performance or tuning improvements to be made.

157

And then there's also improvements in, and this is where it does maybe relate a little bit

158

to what the topic was in the last review basically the overall demand on the database layer from .com activities and improving those.

159

So it's definitely not just one of those things, but one of the most specific actions we're going to take,

160

though, is separating out and having a dedicated host so

161

that we're just dealing with the profile of the data engineering traffic on there

162

and not having conflicting queries affect the ability to update the replication.

163

Steve, I definitely want to partner with you on this one

164

because I think the demand on those databases is only going to increase.

165

It's not going down.

166

And I think we need to get, I'm still unclear on where to focus in to get the biggest bang for the buck.

167

I think if the computational resource dedication, that's going to be a good thing, but we're probably going to squeeze the balloon and then the next area will unearth itself.

168

Okay.

169

And I'll tell you what, I'll put into the infr-key review for next week.

170

Okay.

171

It's going to be an update on this issue.

172

Thank you, Steve.

173

So then back to Mechon 7 or yes.

174

Thank you.

175

And Rob was in the assassin's incident this morning as well.

176

So Brian, we have the attention there.

177

Number seven, just to provide an update on previous conversations, we're continuing to improve defect tracking and against SLOs.

178

There is a first iteration PI that we are experimenting to show a percentage of defects meeting the SLOs.

179

Key findings, S1s are hovering at 80%, S2 at 60%.

180

We've been focused mostly on S1 and S2 at this point, hence why S3 and S4 are lower.

181

This will likely be the case.

182

We are also in point B are working on the measurement for average open bugs age.

183

This would give us a whole picture of what's left.

184

If the age goes up or down, if we are cleaning the backlog, the average age should go down as well.

185

There's no PI yet, but I just want to update and show that beyond this.

186

It's not off track.

187

number C, Craig, on S2?

188

Yeah, I just was looking through the charts and I noted that there was a spike in the meantime to close.

189

And just wanted to see if you had any insight into that.

190

This is the S2, the S1 looked fine.

191

Yeah, this is where the point B on H, supplemental charts in the backend helps.

192

So I haven't seen a dip in H nor the count overall.

193

I think it's the latter.

194

We need to dig in a bit deeper in that.

195

And also the data lag, I would like to reevaluate once we have the whole picture, once everything is synced in as well.

196

Christy, you have some insights.

197

Yeah, I'm just wondering if part of this could be the fact

198

that we changed the severity across the board for MRs to S2.

199

And so we may have some older bugs in there that hadn't been addressed because they were at a lower severity.

200

Now we've moved them to S2 and maybe that caused a little spike.

201

That could be the case if we did it in a limited fashion, it won't be a huge volume.

202

We also iterated after that to pin on priority since product owns prioritization.

203

So I wouldn't account it entirely to that.

204

I mean, this isn't the infra key review, but I know that they've gotten backed up on those issues.

205

So if some good portion of those are in for created or related, then that may be lifting it as well.

206

I can take the deeper dig in and then provide an update next time.

207

I think we need extra debug slicing the data here.

208

So do you like to go to 0.8?

209

Yeah, we are now measuring S1, S2, SLO achievement with closed bugs.

210

But if you then look at the number of bugs, it's exponential growth.

211

And then it would be trivial to achieve 100% SLO achievement.

212

If you just look at closed bugs, even though there would be a major problem in the company, 99% of all bugs are overdue.

213

As long as I only close ones that are still within the SLO, I'll have great achievement.

214

So I think we shouldn't be looking at the closed bugs.

215

I think we should be looking at open bugs, the entire population, or percentage of those is within the SLO time.

216

I think we're doing it the wrong way.

217

Thanks for the feedback, Sid.

218

Hence why we wanted to have the average age, average age to measure what's outside in the open.

219

We can make this iteration to also measure, focus on the age of all opened, including open bugs.

220

This is all something we have discussed with Christopher in the next iteration as well, and we're happy to adjust.

221

So the key...

222

Yes, go ahead.

223

So average age would get closer to it.

224

It's not what I'm proposing.

225

I'm proposing is of the open bugs what percentage is outside of SLO

226

so display it as a percentage you do now just do

227

it about the open bugs not the closed one got it okay the exceeding SLO for open bugs yeah

228

or open bugs that are within SLO so you have a chart

229

that should go up

230

and to the right like everything else sounds great we can take it to the the next data metrics to deliver this.

231

Cool.

232

Thanks.

233

It's a pretty good.

234

A little tricky Mac you'll have to figure out how to.

235

Cause we like to be able to have charts

236

that we can historically reconstruct if we need to so

237

when tickets close out you need to go through their history to figure out at this time

238

when it was open did it breach the slo

239

or not that's a good point this might be much harder computationally

240

and so I totally respect if we can do it for

241

that reason uh cool nine craig yeah i just wanted to

242

ask the team like i went through all the the key meeting metrics everything looked in line with prior periods

243

and look good is there anything the team wants to call out especially that we should be watching Yeah, I'll call out Sus.

244

So the good news is in Q4, we had our smallest decline over several quarters.

245

So we only went down by a tenth of a point.

246

The quarter previous was 0.6 or six tenths of a point and the quarter before that was a full point.

247

So So we see this as an improvement, even though it was still a decline, but it's still a decline.

248

Obviously, we want this actually tracking in an upward direction.

249

We also don't have enough data to know whether or not this is an actual real trend up.

250

So I'm optimistic.

251

I think this is a good thing.

252

We have had a much keener focus on SUS over the past several quarters.

253

So that's why I think, okay, the work that we've done, I think actually is catching up and getting noticed in SUS, but we got to keep an eye on it.

254

We can't assume that that's the case.

255

Yeah, and the bug discussion above just kind of points out

256

that we have an underlying problem right now in our metrics measurement.

257

So if we change the measurements to reflect that, then hopefully we're in good shape.

258

If we don't and we flatline and address it so that we flatline open S1s and S2s,

259

you will see a temporary jump in above SLOs as we clear out that backlog over that period of time.

260

And I have point C, which is similar to infrastructure.

261

We need to get more security work prioritized.

262

We're hearing that from the team.

263

But neither that problem nor that activity is sort of currently reflected in our security metrics.

264

So we have some work to do long term to make sure we see things like

265

that in the metrics and the measurements that we're making.

266

So back to you, Sid, 10.

267

Yeah, the narrow MR rate seems significantly below target.

268

And maybe I hope that it would bounce back from December.

269

I think it bounced back, but not back on target.

270

Any context there?

271

What's going on?

272

Yeah, so with family and friends days,

273

we actually had some heavier vacation days in January than we historically have.

274

One thing to note is that we were actually at a higher MR rate.

275

If you go back the last 18 months, we're actually at a higher and narrow MR rate than we were back in each month this year.

276

So if you compare October to October, November to November and January, I'm sorry, October, November, December,

277

and January, comparatively to last year, what you'll find is we're between a half point

278

and a 1.5 MR rate above where we were in the month of previous year.

279

That's great context.

280

Thank you, Christopher.

281

Good work.

282

Yeah, so the expectation is that February is a short month.

283

We are at, I think, 16 work days with friends and family day and other things.

284

Obviously, us having carriages in Texas doesn't help things either for the folks who are working in Texas.

285

But hopefully the rest of the team is being effective.

286

I was hoping to see a better result right now, but with four or five days, particularly around release week, that's usually when we do see a little bit higher activity.

287

So that's not accounted for yet.

288

but you know march is march is

289

when i'm expecting kind of see a real rebound much like

290

we did last year awesome thanks the other context i'll give is we now do time series targets

291

so when we change the target you'll see that reflected in the line

292

so if we were to look back historically here the goal here is actually lower

293

and christopher was ambitious and we kept raising and we kept meeting

294

that so it should stair step here and we could go back and reconstruct that if we really wanted to.

295

And then ignoring the sort of the seasonal dip here, we raised it to, I think, 11.

296

And then we realized we're kind of hitting that point of diminishing returns and the right thing to do business-wise, and this is in our FY22 direction, is hold the line at productivity,

297

but start to raise other things related to quality, security, availability, and whatnot.

298

So that's kind of why you're seeing this bump is we raised it and we realized, okay, that's not the, we shouldn't raise it anymore.

299

And we brought it back down to 10.

300

So 10 will be the target going forward.

301

I'm going to try to get better.

302

A lot of other things while preventing this from dipping.

303

Cool.

304

And I just want to call out

305

that it's not necessarily like higher MR rates should also help to address security

306

and quality and other things because you're more productive.

307

So you can fix more things.

308

So it's not necessarily opposite,

309

but I, I agree with let's hold the line 10 is a great number and focus on other indicators to improve.

310

That makes a ton of sense.

311

Cool.

312

Well said.

313

All right.

314

That's it for the agenda.

315

Anyone want to vocalize anything else?

316

Great.

317

Well, thanks, everybody.

318

And I'm going to go check on my four-year-old and see if she got whatever she needed.

319

So cheers and talk soon.

320

Thanks, Eric.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

この動画が英語スピーキング練習に最適な理由

ビジネス会議の実況を捉えたこの動画は、自然な英語表現とリアルなコミュニケーションの流れが凝縮されています。特に「提案を議論し、柔軟に調整する」という場面は、日常的なビジネス英語に欠かせない技能を養うのに最適です。YouTubeで英語学習をする際、こうした実践的なコンテンツはシャドーイング（shadowing）の効果を最大化します。

自然な表現を分解して学ぶ

「How do people feel about that proposal?」：提案に対する意見を聞く際の柔らかい表現。「What do you think?」よりもビジネスシーンでよく使われ、相手の意見を尊重する印象を与えます。
「We can be flexible」：柔軟性を示すフレーズ。会議で合意形成を進める際、「条件を変更できる」という意思を明確に伝えつつ、協調的な雰囲気を保ちます。
「That's a potential bit of funkiness」：「奇妙な点」を口語的に表現する例。フォーマルな場面でも適度なくだけた表現は、コミュニケーションを円滑にします。

効果的なシャドーイング練習法

shadowspeaksやshadow speakの技術を使って、以下のルーティンを実践しましょう。まず動画を10秒程度再生し、すぐに止めて自分の声で同じ内容を繰り返します。このとき、発音だけでなくイントネーションやポーズも真似ます。録音して自分の発音と原音を比較し、「自然なリズム」を体感します。1日10分、1週間続けると、ビジネス英語の流暢さが格段に向上します。shadowing siteを利用しても、同様の練習が可能です。

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	haven't had · that's been · We've been
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	would be viewed · won't be counted · can be thrown

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: [REC] Key Meeting - Engineering (Public Stream) - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Sec Growth DataScience staff meeting Sep 14 2022

2022-07-25 Analytics Section Meeting

Product Marketing Meeting (weekly) 2021-06-28

おすすめ動画

Weekly Team Meeting: Project Status Update

Supply Chain Business Meeting Conversations in 40 minutes | Business English Learning

One Person. One System. Your Entire Growth Team

Episode 531: Shallow feedback and my coworker is a huge sloperator

How To Effectively Leverage Skip Level 1 1s

TOEIC Speaking Express an Opinion (Question 11): Flexible Working Hours and Changing Jobs

Ricardo Vargas Shows How to Implement Governance During Project Execution

Overcoming Service Blueprinting Frustrations

New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

How To Write Meeting Minutes In English

Daily Scrum in a Nutshell

この動画が英語スピーキング練習に最適な理由

自然な表現を分解して学ぶ

効果的なシャドーイング練習法

この動画の文法

シャドーイングとは？英語上達に効果的な理由