쉐도잉 연습: [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

실제 시나리오: 기업 회의에서의 의견 교환

이 비디오는 기업 엔지니어링 팀의 회의 장면을 담고 있습니다. 에릭 존슨이 회의 구조 개선 제안을 하고 팀원들과 논의하며, KPI 측정 방식에 대한 혼동을 해결하는 과정을 보여줍니다. 직장에서의 영어 회화 연습에 매우 실용적인 내용으로, 회의에서의 제안, 동의, 질문 등 일상적인 커뮤니케이션 패턴을 배울 수 있습니다.

유용한 표현과 콜로케이션

"proposal to break up": ~를 분할하는 제안. "break up"은 그룹이나 활동을 나누는 의미로 자주 사용됩니다.
"increase visibility": 가시성을 높이다. 프로젝트나 팀 활동에서 중요한 성과를 강조할 때 유용합니다.
"shift into more of a question asker mode": 질문자 모드로 전환하다. 회의에서 발표자에서 듣는 자로 역할을 바꿀 때 사용할 수 있습니다.
"be flexible": 유연하게 대처하다. 계획을 조정할 때 자주 쓰이는 표현입니다.
"potential bit of funkiness": 잠재적인 혼란스러운 점. 복잡한 문제를 설명할 때 가벼운 어조로 사용됩니다.

당신의 쉐도잉 챌린지

영어 쉐도잉은 발음과 리듬을 연습하는 좋은 방법입니다. 이 비디오의 대화를 3번 반복해서 듣고, 즉시 따라 말해보세요. 특히 "How do people feel about that proposal?"나 "We can be flexible" 같은 문장의 intonation을 주의깊게 살펴보세요. 영어 발음 교정에 도움이 될 뿐만 아니라, 자연스러운 회화 흐름을 익힐 수 있습니다. shadowing site에서 유사한 기업 회의 영상을 찾아 연습하면 더 좋습니다. shadow speech를 통해 실제 회의에서 사용되는 표현을 익히고, 영어 회화 연습의 효과를 높여보세요!

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
현재완료 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

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

How To Effectively Leverage Skip Level 1 1s

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

실제 시나리오: 기업 회의에서의 의견 교환

유용한 표현과 콜로케이션

당신의 쉐도잉 챌린지

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법