शैडोइंग अभ्यास: [REC] Key Meeting - Engineering (Public Stream) - वीडियो के साथ अंग्रेजी बोलना सीखें
अभ्यास मोड चुनें
हर मोड पूरी स्क्रीन का अभ्यास कक्ष खोलता है।
320 वाक्य
यदि वाक्य बहुत छोटे या लंबे हों, तो समायोजित करने के लिए Edit पर क्लिक करें।
1
Hi, this is Eric Johnson.
2
It's February 18th, 2021, and this is the engineering key review at GitLab.
3
So I've got number four in the agenda, which is a proposal to break up this meeting into four department key reviews.
4
So currently this is engineering,
5
development, quality, security, and UX infrastructure and support do their own key reviews already.
6
I have the reasons why increased visibility, able to go deeper, increase the objectivity with which my reports can manage their groups,
7
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.
8
But to avoid adding three net new meetings to stakeholders' calendars, I propose we do a sort of two-month rotation.
9
So month one, development quality go.
10
Month two, security and UX would go.
11
How do people feel about that proposal?
12
I think in the group conversations, it's working really well um so i'm i'm supportive
13
and uh this is the smallest thing maybe we need four
14
meetings a month like it's the biggest department it's super essential but you propose this i don't uh
15
i could see either way so let's stick with the proposal
16
cool we'll try it
17
and we'll uh we can be flexible i mean the development is larger maybe they go more frequently
18
or something like that but we'll see how it see how it goes all right
19
and then i've got number five um
20
which is uh we've got um r d overall mr rate
21
and we also have r d wider mr rate both as top level kpis for engineering
22
so the difference between them in the simplest sense is that R&D wider MR rate includes both community contributions and community MRs.
23
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,
24
which is- Wait, wait, wait, wait, sorry, sorry.
25
The wider MR rate should just be external, right?
26
Right.
27
And then overall should be narrow plus wider.
28
Oh, yeah.
29
Like we say the wider community.
30
Right, right, right.
31
Okay. So there's...
32
I have to check the taxonomy.
33
Lily, can you confirm SID's reasoning is my understanding as well?
34
Yeah, I believe water MR rate just captures community contributions.
35
Only and no internal.
36
Yeah, and the reason we measure that is
37
that like one of the most likely failure modes is that we lose the community.
38
Yeah.
39
So Eric, where it gets goofy is that when you look at a specific team within the company,
40
there could be contributions outside of that that aren't community contributions.
41
They would be viewed community contributions by that group, but effectively they're not from outside the company.
42
So that's why we use wider to kind of reflect that.
43
And narrow is very specific to the team.
44
Are you saying that if someone in plan contributes to verify, it's viewed as wider?
45
Not quite that.
46
Plan and verify are just fine.
47
It's when you look at like the development versus infrastructure infrastructure will oftentimes contribute to developments work
48
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.
49
I didn't have that in my sort of critique of this but that that doesn't necessarily make intuitive sense to me.
50
So then I think part of my critique of this can be thrown out
51
because it's not as duplicative as I thought
52
but I still think there's a problem with R&D wider MR rate
53
which is this thing doesn't really move in part
54
because it's a it's a rate
55
so it feels like the way to drive this up is
56
to specifically drive community authors to contribute more than one MR per month that's how this moves up
57
because it's a it's a productivity rate like we use internally
58
and that doesn't necessarily feel like the right thing
59
because there's scenarios in which this goes up we've actually got less contributions overall and less contributors overall.
60
Wait a second.
61
So you're saying that R&D wider MR rate is number MRs per external contributor?
62
Oh my goodness.
63
That should not be the thing.
64
It should be contributions per GitLab team member.
65
So the thing above the division is the external ones.
66
The thing below is the number of team members at GitLab.
67
Is that the case, Lily?
68
I'm checking right now.
69
I think so in our numerator.
70
It says for the marks merge per team member.
71
So unless we start calling people outside the company team member, then it shouldn't be done.
72
Yeah, just clarifying here.
73
So So our numerator is community contributions, and then our denominator is GitLab team members.
74
So it's not per external member.
75
So we- So what we're doing there,
76
Eric, is we're not trying to say how many MRs does someone send if they send something,
77
we're saying how many MRs from external do we get for the size of our organization
78
sorry i have a childhood emergency outside the door So maybe explain the context behind this.
79
The context is as we grow as a company, we should make sure we keep the community up.
80
Like the logical thing is for the community to flatline and the size of the org to grow.
81
And before you know it, you've kind of outgrown the wider community.
82
Yeah.
83
And what I'm seeing is we created this pre-sophisticated taxonomy with prefixes
84
and post fixes to talk about these things
85
but in reality we've only got two of them
86
and it's we keep forgetting and we have a hard time discussing this thing so i'd rather just name them simply
87
some two names for what they are rather than than using
88
that taxonomy but also like in f i have this proposal of like what
89
if we just tracked as a kpi the percentage of total mrs
90
that come from the community over time and we would see
91
that drop i love that i love that let's do that instead Okay.
92
But the thing why we have this complex thing is because you can game that.
93
You want to game that, you just produce fewer MRs with the engineers at GitLab.
94
So if you drive that really hard and say, this is your number one goal, it's very easy to achieve.
95
You just tell all your engineers to produce half.
96
Yeah.
97
So we have different metrics to prevent that from happening the same way
98
that like support SLA as an asset kind of buttress one another.
99
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 अभ्यासहर ध्वनि में महारत
शब्दावलीअपना शब्द भंडार बनाएँ
शब्द गेमखेलते हुए सीखें
उसी चैनल से
FOR YOU
अनुशंसित वीडियो
B2464
28 वाक्य
Weekly Team Meeting: Project Status Update
American AccentBusiness EnglishWorking Adults
C13
592 वाक्य
Supply Chain Business Meeting Conversations in 40 minutes | Business English Learning
Business EnglishWorking Adults
C11
25 वाक्य
One Person. One System. Your Entire Growth Team
Business EnglishWorking Adults
C115
35 वाक्य
TOEIC Speaking Express an Opinion (Question 11): Flexible Working Hours and Changing Jobs
American AccentBritish AccentTOEIC PrepBusiness EnglishWorking Adults
C11
583 वाक्य
Episode 531: Shallow feedback and my coworker is a huge sloperator
Business EnglishWorking Adults
B21
56 वाक्य
How To Effectively Leverage Skip Level 1 1s
Business EnglishWorking Adults
C11
70 वाक्य
Ricardo Vargas Shows How to Implement Governance During Project Execution
Business EnglishWorking Adults
C14
36 वाक्य
Overcoming Service Blueprinting Frustrations
Business EnglishWorking Adults
C14
206 वाक्य
New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets
British AccentBusiness EnglishUniversity StudentsWorking Adults
B22
122 वाक्य
How To Write Meeting Minutes In English
Business EnglishWorking Adults
B25
31 वाक्य
Daily Scrum in a Nutshell
Business EnglishWorking Adults
इस पाठ की शब्दावली और बोलने के सुझाव
यह C1 स्तर का स्पीकिंग पाठ वीडियो “[REC] Key Meeting - Engineering” पर आधारित है। इस वीडियो में शैडोइंग के लिए 320 वाक्य और 3676 शब्द हैं। बोला गया हिस्सा 24:08 लंबा है। वक्ता लगभग 152 शब्द प्रति मिनट की स्वाभाविक गति से बोलता है, जो रोज़मर्रा की बातचीत के करीब है। 83% शब्द अंग्रेज़ी के 3,000 सबसे आम शब्दों में से हैं; बाकी शब्द अभ्यास से पहले देख लेना अच्छा रहेगा।
इस वीडियो की मुख्य शब्दावली
वीडियो के 15 सबसे कठिन शब्द, उच्चारण और अर्थ के साथ:
| शब्द | उच्चारण | अर्थ |
|---|---|---|
| measurement संज्ञा | /ˈmɛʒ.ə.mənt/ | माप, नाप |
| taxonomy संज्ञा | /tækˈsɑnəmi/ | वर्गिकी |
| defect संज्ञा | /ˈdiːfɛkt/ | दोष, खोट |
| verify क्रिया | /ˈvɛɹɪfaɪ/ | परखना, जाँचना |
| critic संज्ञा | /ˈkɹɪt.ɪk/ | आलोचक, विवेचक |
| spike संज्ञा | /spaɪk/ | कीला |
| prefix संज्ञा | /ˈpɹiːfɪks/ | उपसर्ग |
| stakeholder संज्ञा | /ˈsteɪkˌhəʊl.də/ | निलंब एजेंट, इंटरप्लीडर |
| dependency संज्ञा | /dɪˈpɛndənsi/ | निर्भरता |
| duplicate क्रिया | /ˈd(j)uː.plɪˌkeɪt/ | अनुकृति करना, अनुकरण करना |
| trivial विशेषण | /ˈtɹɪv.i.əl/ | नगण्य, तुच्छ |
| internally क्रिया विशेषण | /ɪnˈtɜːnəli/ | आंतरिक |
| optimistic विशेषण | /ˌɒptɪˈmɪstɪk/ | आशावादी |
| balloon संज्ञा | /bəˈlun/ | ग़ुब्बारा, बेलून |
| tenth विशेषण | /tɛnθ/ | दसवाँ |
वीडियो में आने वाली फ़्रेज़ल वर्ब
| शब्द | उच्चारण | अर्थ |
|---|---|---|
| go ahead क्रिया | /ˌɡoʊ əˈhɛd/ | आगे बढ़ना |
दोहराने लायक वाक्य
वीडियो के छोटे, पूरे वाक्य जिन्हें आप रोज़ की बातचीत में इस्तेमाल कर सकते हैं:
- I think we're robust to that.
- I'm like, there's a problem with this.
- It's what all our investors ask about.
- Do we have the right attention to this?
- Do you have a sense of that?
इस वीडियो का व्याकरण
वक्ता जिन संरचनाओं का सबसे अधिक प्रयोग करता है, वीडियो के असली शब्दों के साथ:
| संरचना | वीडियो में |
|---|---|
| Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी है | haven't had · that's been · We've been |
| Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता है | would be viewed · won't be counted · can be thrown |
ध्यान देने योग्य उच्चारण
वक्ता 96 बार संक्षिप्त रूपों का प्रयोग करता है, जैसे I'm, we're, I'll। इन्हें वैसे ही छोटा बोलें जैसा आप सुनते हैं।
- “sh” और “zh” की ध्वनियाँ: replication /ɹɛplɪˈkeɪʃən/, measurement /ˈmɛʒ.ə.mənt/, iteration /ˌɪt.əˈɹeɪ.ʃən/, computational /ˌkɑmpjʊˈteɪʃənəl/, computationally /ˌkɑmpjʊˈteɪʃənəli/
- लंबे शब्द — बलाघात सही रखें: replication /ɹɛplɪˈkeɪʃən/, iteration /ˌɪt.əˈɹeɪ.ʃən/, taxonomy /tækˈsɑnəmi/, historically /hɪˈstɔɹɪkli/, numerator /ˈnuː.məɹˌeɪ̯.təɹ/
हिंदी भाषियों के लिए मुश्किल ध्वनियाँ:
- /v/ और /w/ का फ़र्क़ — /v/ में ऊपर के दाँत निचले होंठ को छूते हैं, /w/ में होंठ गोल होते हैं: query /ˈkwɪɹ.i/, severity /səˈvɛɹ.ə.ti/, verify /ˈvɛɹɪfaɪ/, supportive /səˈpɔɹtɪv/, duplicative /d(j)uˈplɪkətɪv/
- /z/ — इसे “ज” (/dʒ/) न बनाएँ: propose /pɹəˈpəʊz/, oftentimes /ˈɔf.ənˌtaɪmz/, prioritization /prʌɪˌɒrətʌɪˈzeɪʃ(ə)n/, prioritize /pɹaɪˈɒɹ.ə.taɪz/, visibility /ˌvɪz.əˈbɪl.ɪ.ti/
- शब्द की शुरुआत में s + व्यंजन — पहले “इ” न जोड़ें: spike /spaɪk/, stakeholder /ˈsteɪkˌhəʊl.də/, squeeze /skwiːz/
इस वीडियो से अभ्यास कैसे करें
- पहले बिना बोले पूरा वीडियो एक बार सुनें और जो शब्द नहीं आते उन्हें लिख लें।
- 0.75× गति से शुरू करें, एक-एक वाक्य की शैडोइंग करें, और सहज लगने पर सामान्य गति पर लौटें।
- अपनी आवाज़ रिकॉर्ड करें और मूल से तुलना करें, ख़ासकर measurement, taxonomy, defect जैसे शब्दों पर ध्यान दें।
शैडोइंग तकनीक क्या है?
शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।