SWR баг — Issue бичих стандарт
Хамрах хүрээ: GitLab (git.techpartners.asia) ба GitHub-ийн бүх repo · Загварын эх сурвалж: kubernetes/kubernetes · Хэрэгсэл: glab / gh
1. Үндсэн зарчим
- Юу ажиллахаа больсныг эхэнд бич. Уншигч эхний хоёр өгүүлбэрт асуудлыг ойлгох ёстой. Кодын блокоор эхэлсэн issue-г хэн ч уншихгүй.
- Дахин гаргах заавар нь ажиллуулж болохуйц байна. Тайлбар биш, бодит команд, URL, тест бич. Уншигч түүнийг хуулж аваад ажиллуулахад алдаа давтагдах ёстой. Ажиллуулж чадахгүй бол issue нээхгүй (§4).
- Нэг issue = нэг асуудал. Хоёр алдааг нэг issue-д нийлүүлбэл нэг нь мартагдана.
- Гарчиг нь шинж тэмдгийг хэлнэ, засварыг биш (§2).
- Хүрээг шошгоор илэрхийлнэ, текстээр биш (§6).
- Issue нь хэлэлцүүлгийн талбар биш. Дизайны нарийн шийдэл нь холбогдох баримт бичигт байх бөгөөд issue түүн рүү холбоос өгнө.
Хэмжсэн үндэслэл:
kubernetes,vuejs/core,golang/go,facebook/react,rust-lang/rust,microsoft/vscodeзэрэг зургаан repo-гийн загварыг 2026 оны 09 дүгээр сарын 21-нд шалгасан. Дөрөв нь GitHub issue form ашигладаг бөгөөд талбар бүрийн нэрийг###гарчиг болгон гаргадаг. Зургаагийн аль нь ч checkbox жагсаалт, эмодзи гарчиг, чухалчлалын хүснэгт хэрэглэдэггүй.
2. Гарчиг
Хэлбэр: <дэд систем>: <шинж тэмдэг>
| Зөв | Буруу | Шалтгаан |
|---|---|---|
control: tunnel survives revoke | control | Зөвхөн хэсгийн нэр — юу болсныг хэлээгүй |
products: cart quotes the pre-discount price | Сагсны үнийг засах | Засварыг хэлсэн, асуудлыг биш |
dispense: progress bar freezes during drop | Алдаа гарлаа | Юу ч хэлээгүй |
Дэд систем нь модуль, сервис эсвэл дэлгэцийн нэр байна: control, web, cli, products, protocol, payment.
3. Алдааны (bug) issue-ийн бүтэц
Гарчгууд нь ### түвшинтэй, доорх дараалалтай, англи хэлээр яг эдгээр үгээр бичигдэнэ. Англи хэвээр үлдээх шалтгаан: repo хооронд хайлт хийх, автомат хэрэгсэлд танигдах боломжтой байх.
| Гарчиг | Юу бичих вэ |
|---|---|
### What happened? | Эхний 1–2 өгүүлбэрт шинж тэмдгийг бич: хэрэглэгчийн нүдээр юу ажиллахаа больсныг. Дараа нь механизмыг тайлбарла — аль файлын аль мөрөнд, яагаад ингэж байгааг |
### What did you expect to happen? | Юу болно гэж хүлээж байсныг бич, дараа нь бодит байдалд юу болсныг зэрэгцүүлж харуул |
### How can we reproduce it (as minimally and precisely as possible)? | Уншигч хуулж аваад шууд ажиллуулах боломжтой команд эсвэл тестийг бүтнээр нь бич. Вэб бол алдаа гарч буй URL, дараа нь хийх үйлдлүүдийг дарааллаар нь дугаарлаж бич (§4) |
### Anything else we need to know? | Засварын чиглэл, холбогдох код, түр шийдэл. Заавал биш |
### Version | Хувилбар шалгасан команд ба түүний гаралт |
Алдааны бүрэн гаралтыг <details> дотор хийж, issue-г богино байлгана.
### What happened?
Бараа гарч буй бүх хугацаанд явцыг харуулах `progress bar` хөдөлгөөнгүй зогсож байна.
`SaleDispenser.dispense()` нь `Progress.onWorking`-ийг тогтмол дуудаж байдаг thread
эхлүүлдэг. Гэвч энэ thread-ийг хэтэрхий эрт зогсоож байна: `actuate(drop)`-ийн
`finally` блокт зогсоож байгаа боловч (`SaleDispenser.java:232-241`) явцыг харуулах
ёстой хүлээлт болох `betweenDrops.settle()` нь түүнээс хойш ажилладаг
(`SaleDispenser.java:255`).
### What did you expect to happen?
`betweenDrops.settle()` ажиллаж дуустал `onWorking` дор хаяж нэг удаа дуудагдана гэж
хүлээсэн. Бодит байдалд огт дуудагдахгүй байна.
### How can we reproduce it (as minimally and precisely as possible)?
```console
$ ./gradlew :protocol:testDebugUnitTest --tests '*SaleDispenserTest*'
```
### Anything else we need to know?
Нэг мөрийн засвар: явцыг тооцох thread-ийг `betweenDrops.settle()` дууссаны дараа зогсоох.
<details><summary>Failure output</summary>
```
java.lang.AssertionError: onWorking must tick while the cabinet settles
```
</details>
### Version
```console
$ git rev-parse --short HEAD
089e027
```
4. Дахин гаргах заавар
Энэ бол бүх дүрмийн дотроос хамгийн чухал нь. vuejs/core болон facebook/react хоёр issue-г дахин гаргах зааваргүй ирвэл шууд хаадгаа загвартаа бичсэн байдаг.
Ажиллуулж болохуйц гэдэг нь:
| Төрөл | Хүлээн авах хэлбэр |
|---|---|
| Backend / API | curl эсвэл CLI команд, бүтэн parameter-тэйгээ |
| Web | Алдаа гарч буй URL, дараа нь хийх үйлдлүүд дугаарласан дарааллаар (1, 2, 3) |
| Library / SDK | Алдааг харуулсан тест эсвэл богино код |
| Android / төхөөрөмж | adb команд, эсвэл дамжсан дэлгэцүүд болон оруулсан өгөгдөл |
| Өгөгдлөөс хамаарсан алдаа | Repo дотор байгаа fixture файлын замыг зааж өгнө |
Дүрэм: заавраа өөрөө ажиллуулж, алдаа давтагдсаныг баталсны дараа л issue нээнэ. Ажиллуулж чадаагүй бол issue нээхгүй — эхлээд дахин гаргах аргаа олно.
Тест бичих боломжтой бол хамгийн сайн хэлбэр нь алдааг харуулж унадаг тест юм. Түүний гаралтыг
<details>дотор хавсаргана.
5. Шинэ боломж / сайжруулалтын issue-ийн бүтэц
Яг хоёр асуулт. Өөр хэсэг нэмэхгүй.
### What would you like to be added?
### Why is this needed?
Бизнес дүрмийг эхний асуултад бич. Дизайныг биш, зан төлөвийг: дүрэм хэзээ үйлчлэх, захын тохиолдолд юу болох, амжилтгүй болбол оператор юу харах — бодит утгатай жишээтэй. Эдгээр нь хүлээн авах шалгуур бөгөөд байхгүй бол хэрэгжүүлэгч өөрөө зохиох болно. Тийм issue нь triage::ready биш, triage::needs-decision төлөвтэй.
| Issue-д байх | Өөр газар байх |
|---|---|
| Хэрэглэгч урьд нь хийж чадахгүй байсан юуг хийх болох | Схем, сервисийн хуваарилалт, кодын бүтэц → тусдаа баримт бичигт |
| Дүрэм: хязгаар, үйлдлийн дараалал, зөрчилдвөл алийг нь баримтлах | Хэр их хугацаа, ямар дараалалтай → Jira |
| Захын тохиолдол ба тэдгээрт юу болох | Үүнийг хийх эсэх → Jira |
| Бодит утгатай жишээ |
Дизайны шийдэл, хувилбаруудын харьцуулалт, хэрэгжүүлэх төлөвлөгөө нь issue-д биш, тусдаа баримт бичигт байна. Issue түүн рүү холбоос өгнө.
kubernetes/kubernetes-ийнenhancement.yamlнь яг энэ хоёр асуулттай. Зургаан repo-гийн дөрөв нь ерөнхий feature загваргүй бөгөөдreact,vueхоёр нь feature хүсэлтийг issue-ээс өөр суваг руу чиглүүлдэг.
6. Шошго (labels)
Хүрээ, төрөл, шатыг текстээр бичихгүй — шошгоор илэрхийлнэ. Гурван scope байна: kind:: (юу вэ), triage:: (ямар шатанд вэ), area:: (хаана вэ). Scope тус бүрээс нэг л утга тавина.
Хэмжсэн үндэслэл (2026 оны 09 дүгээр сарын 21):
kubernetes/test-infra-гийнlabel_sync/labels.yaml(шошго бүр тайлбартай, машинаар синк хийгддэг),kubernetes/community-гийнissue-triage.mdбаhelp-wanted.md,golang/go,angular/angular,microsoft/TypeScript,NixOS/nixpkgs,microsoft/vscode,rust-lang/rust,elastic/elasticsearch-ийн амьд шошгын жагсаалтыг шалгасан. Нэр, тайлбарын ихэнх ньkubernetes-ийнх;::тусгаарлагч нь GitLab-ийн бичлэг бөгөөдarea::дээр аль хэдийн хэрэглэгдэж байсан.Анхаар:
git.techpartners.asiaнь GitLab CE (17.3.6) тул scoped label-ын харилцан хасах чанар (нэг scope-д хоёр дахь утга тавихад эхнийх нь автоматаар хасагдах) ажиллахгүй. Тэр нь Premium-ийн боломж. Эндээс: дүрмийг систем биш, хүн барина.
6.1. kind:: — энэ юу вэ
| Шошго | Утга |
|---|---|
kind::bug | Алдаа |
kind::feature | Шинэ боломж |
kind::cleanup | Код, процесс, техникийн өрийг цэвэрлэх |
kind::documentation | Баримт бичиг |
Нэр, тайлбар нь kubernetes-ийн kind/* шошгынх. Өмнө нь нэг санааг improvement, flow-enhancement, ux-enhancement гэж гурван янзаар бичдэг байсныг kind::feature болгон нэгтгэв.
6.2. triage:: — ямар шатанд явж байна
Issue бүр triage::needed-ээр эхэлнэ. Шалгасны дараа доорхийн аль нэг рүү шилжинэ.
| Шошго | Утга |
|---|---|
triage::needed | Шинэ issue. Хэн нэгэн шалгах ёстой |
triage::ready | Шалгасан, дахин гаргасан, шийдвэр гарсан — бичсэн чигээрээ хэрэгжүүлж болно |
triage::needs-information | Мэдээлэл дутуу. Issue нээсэн хүнээс хүлээж байна |
triage::needs-decision | Бодит асуудал мөн боловч шийдэх зүйл үлдсэн (аль аргаар засах, ямар зан төлөв зөв бэ) |
triage::not-reproducible | Шалгасан боловч дахин гаргаж чадсангүй (§7.1) |
triage::duplicate | Өөр issue-г давхардуулсан |
triage::unresolved | Засахгүй, эсвэл шийдэх боломжгүй |
triage::ready гэдэг нь хэрэгжүүлэхэд бэлэн гэсэн үг — хүн авсан ч, agent авсан ч ялгаагүй. Хэрэв ямар нэг ажлыг хүний хяналтгүйгээр хийлгэж болохгүй бол (төлбөр бичих, eBarimt, түлхүүр боловсруулах) үүнийг issue-ийн биед тодорхой бич; тусдаа шошго үүсгэхгүй.
triage::ready тавихаасаа өмнө kubernetes-ийн help wanted-ийн шалгуурыг хангасан эсэхийг шалга: даалгавар тодорхой, өндөр түвшний арга барил дээр санал нийлсэн, нэмэлт хэлэлцүүлэг шаардахгүй, мэдээлэл нь хуучраагүй.
6.3. area:: — хаана байна
Repo-гийн нэрийг бүү давт. vendingsystem/backend доторх issue дээр area::backend гэж бичих нь юу ч нэмэхгүй — аль хэдийн тэр repo дотор байна. Шошго нь тухайн repo доторх модуль эсвэл дэлгэцийг нэрлэнэ.
Хэлбэр: area::<модуль>, эсвэл олон хэсэгтэй repo дээр area::<хэсэг>::<модуль>.
Нэрийг кодоос ав. Модулийн нэр аль хэдийн кодод байдаг:
| Repo | Нэр хаанаас | Жишээ |
|---|---|---|
vendingsystem/backend | internal/ доторх сан | area::backend::sales, area::backend::promotions, area::backend::ebarimt, area::backend::machine, area::backend::catalog, area::backend::operations |
vendingsystem/admin | src/pages/ доторх сан | area::admin::finance, area::admin::marketing, area::admin::rbac, area::admin::monitor, area::admin::organization |
tether/control | crates/tether-control/src/ доторх модуль | area::control::auth, area::control::broker, area::control::store, area::control::oidc, area::control::logcat |
internal/ims | backend ба web-admin/ хоёр нэг repo-д | area::ims::oidc, area::ims::admin |
Хэрэв кодод нэр нь байхгүй бол тэр нь өөрөө шинж тэмдэг: хаана засах нь тодорхойгүй байна гэсэн үг. Эхлээд тэрийг тодруул.
Дүрэм:
- Нэг issue = нэг area. Хоёр модульд хамаарвал ихэвчлэн хоёр issue байх ёстой (§1). Үнэхээр хөндлөн огтлолцсон үед л хоёр дахийг нэм.
- Нэг удаа тавьж, өөрчлөхгүй — хаасны дараа ч хэвээр (§6-ийн дүрэм).
- Гарчгийн угтвар ба area хоёр таарна.
sales: cart quotes the pre-discount price→area::backend::sales. - Repo бүр жагсаалтаа нэг удаа кодынхоо бүтцээс гаргана. Шинийг зохиохын өмнө байгааг нь шалга:
$ glab api projects/<id>/labels
kubernetes (area/kubelet, area/apiserver), angular (area: router, area: forms), microsoft/vscode (editor-autocomplete, terminal-tabs) гурвуулаа ижил зарчимтай: шошго нь кодын модулийг нэрлэдэг, repo-г биш.
6.4. Өөрчлөлтийн ангилал
MR дээр Standard change / Normal change / Emergency change гурвын нэгийг заавал сонгоно. Энэ нь ISO 27001-ийн хяналт 8.32-ын шаардлага бөгөөд загварын сонголт биш.
6.5. Эрэмбэ (priority) — GitLab дээр биш
Энд эрэмбийн шошго байхгүй, зориуд. Төлөвлөсөн ажлын эрэмбэ нь Jira-гийн Master Board дээр байна (§7.3). Инженерийн өөрөө олсон алдааны хувьд эрэмбэлэх дараалал байхгүй: 2026 оны 09 дүгээр сарын 21-ний байдлаар нээлттэй triage::ready issue нь vendingsystem/backend дээр 1, бусад repo дээр 0 байна. Нэг issue-г эрэмбэлэх шаардлагагүй.
Яаралтай алдаа гарвал энэ нь шошгын асуудал биш — хүнтэй ярих асуудал.
kubernetes (priority/critical-urgent … priority/backlog), angular (P0–P5), elasticsearch (priority:critical|high|normal) гурав эрэмбийн шкалатай. Тэдэнд олон мянган оролцогчтой, нэг хүний харж барахааргүй backlog байдаг. Бидэнд тийм зүйл байхгүй.
Хэзээ эргэж харах вэ: нээлттэй triage::ready хэдэн долоо хоног дараалан 10-аас дээш байвал. Тэр үед эрэмбэлэх нь хэн нэгний ажил болсон гэсэн үг — angular-ын шалгуураар (түр шийдэл бий юу, хэдэн хэрэглэгчид нөлөөлж байна, мөнгө/өгөгдөл эрсдэж байна уу) гурван утгатай шкал нэмнэ.
6.6. Нэршлийн гарал үүсэл
| Шошго | Хаанаас |
|---|---|
kind::*, triage::needed, triage::needs-information, triage::not-reproducible, triage::duplicate, triage::unresolved | kubernetes — нэр ба тайлбарыг шууд авсан |
triage::ready | kubernetes-ийн triage/accepted ("ready to be actively worked on"). Утгыг нь ойлгомжтой болгож нэрлэсэн |
triage::needs-decision | golang/go-гийн NeedsDecision, angular-ын state: Needs Design |
:: тусгаарлагч | GitLab-ийн бичлэг; area:: дээр аль хэдийн хэрэглэгдэж байсан |
Өмнөх ready-for-agent / ready-for-human хос нь ажил хийх этгээдийг нэрлэдэг байв. Бодит утга нь "шийдэх зүйл үлдсэн үү, үгүй юу" байсан тул triage::ready ба triage::needs-decision болов. Шошго нь ажил хийгчийг биш, issue-ийн төлөвийг тодорхойлдог болсноор agent-аас хүн рүү дамжсан ч үнэн хэвээр үлдэнэ.
7. Jira-аас ирсэн хүсэлт
Хөгжүүлэгчийн оролт нь PM-ийн бичсэн Master Board дээрх Jira task (VM, TINO, UBC, CRG) байна. APEX, IT, TRE зэрэг service desk нь PM рүү ордог бөгөөд хөгжүүлэгчийн урсгалд хамаарахгүй — desk-ийн тасалбараас шууд ажиллахыг хориглоно.
Jira task нь хүсэлт. GitLab issue нь дахин гаргаж баталсан алдаа.
7.1. Шалгалтгүйгээр issue нээхгүй
Үйлчлүүлэгч "мөнгө авчихаад бараа өгсөнгүй" гэж бичсэн нь алдаа мөн гэсэн үг биш — ямар нэг зүйл буруу харагдсаныг мэдээлсэн хэрэг. Инженер лог, борлуулалтын бичлэг, машины самбарын төлөвийг шалгаж, дахин гаргах заавар бичиж чадах эсэхээ тогтооно.
| Шалгалтын үр дүн | Үйлдэл |
|---|---|
| Дахин гарахгүй — сүлжээний түр доголдол, нэг удаагийн тохиолдол | Олж мэдсэнээ Jira task дээр бичиж, PM рүү буцаана. GitLab issue нээхгүй. Аль хэдийн нээгдсэн бол triage::not-reproducible тавьж хаана |
| Бодит, гэхдээ хоёр өөр эвдрэл байсан | Хоёр GitLab issue |
| Бодит, нэг эвдрэл | Нэг GitLab issue |
Нэг тасалбараас тэг, нэг, эсвэл хэд хэдэн issue үүсч болно. §4-ийн "ажиллуулж болохуйц заавар"-ын шаардлага нь яг энэ шалгалтыг баталгаажуулна: заавраа бичиж чадаагүй бол шалгалт дуусаагүй, тиймээс бүртгэх зүйл алга. Энэ шалгалтгүйгээр баталгаажаагүй мэдээлэл инженерийн системд орох бөгөөд хэн ч арга хэмжээ авч чадахгүй тул хэзээ ч шийдэгдэхгүй үлдэнэ.
Jira task-ыг хөгжүүлэгч өөрөө хаахгүй — PM хаана. Тасалбар нь PM-ийнх бөгөөд хүсэлтийн цаашдын хувь заяаг тэр шийднэ. Олж мэдсэнээ болон яагаад дахин гаргаж чадаагүйгээ бичээд буцаана. Өөрөө хаавал PM-ийн шийдэх эрхийг үгүй болгож, үйлчлүүлэгчийн талаарх мэдээлэл алдагдана.
7.2. Агуулгыг давхардуулахгүй
Тал бүр өөрийн эзэмшдэг мэдээллээ хадгалж, хоорондоо нэг холбоосоор холбогдоно.
| Jira тасалбар | GitLab issue | |
|---|---|---|
| Агуулга | үйлчлүүлэгч, машин, буцаалт, нөхцөл байдал | шинж тэмдэг, механизм, дахин гаргах заавар, хувилбар |
| Бичигч | үйлчилгээ, борлуулалт, оператор | инженер, шалгасны дараа |
| Холбоос | GitLab issue рүү | issue-ийн тайлбарт Reported as VM-1234 |
7.3. Шинэ боломжийн хүсэлт — хугацааны үнэлгээ GitLab руу гарахгүй
Хэр их хугацаа зарцуулах, юуг эхэлж хийх, ямар дараалалтай явах нь бодит асуултууд боловч GitLab issue-д хамаарахгүй. Эдгээр нь Jira-гийн Master Board дээр (VM, TINO, UBC, CRG …) шийдэгдэнэ — тэнд backlog-ийн эрэмбэ, sprint, үнэлгээний талбар аль хэдийн бий.
| Асуулт | Хаана хариулагдах вэ |
|---|---|
| Үүнийг хийх үү? | Jira — бүтээгдэхүүний шийдвэр |
| Хэр их хугацаа зарцуулах вэ? | Jira — самбар дээрх үнэлгээ |
| Ямар дараалалтай вэ? | Jira — backlog эрэмбэ, sprint |
| Яг юу хийгдэх вэ? | Тусдаа баримт бичиг, хоёр талаас холбогдоно |
| Юу эвдэрсэн, яаж харах вэ? | GitLab issue |
Тиймээс шинэ боломжийн хүсэлт нь ихэвчлэн GitLab issue болохгүй. Эхлээд Jira дээр үнэлэгдэж, эрэмбэлэгдэж, тодорхой хэсгүүдэд задарсны дараа л хэсэг тус бүр GitLab issue болно — тэр үед аль хэдийн triage::ready эсвэл triage::needs-decision төлөвтэй байна.
Хугацааны үнэлгээг GitLab issue-д бичвэл хуваарийг хоёр систем зэрэг тодорхойлох болно. Тэр хоёр хоорондоо зөрөх бөгөөд уншигч аль нь зөв болохыг мэдэхгүй.
8. Хориотой зүйлс
- Дахин гаргах зааврыг эхэнд тавих. Уншигч юу эвдэрснийг мэдэхээсээ өмнө урт кодыг уншиж эхэлнэ.
**bold**гарчиг ба---тусгаарлагч.###гарчиг ашиглана — тэр нь холбоос үүсгэж, GitLab-ийн агуулгын жагсаалтад ордог. Дурдсан зургаан repo-гийн аль нь ч тусгаарлагч хэрэглэдэггүй.- Checkbox жагсаалт — "[ ] Байгаа issue-г хайсан", "[ ] Дүрэм уншсан" гэх мэт.
- Эмодзи гарчиг, чухалчлал/ноцтой байдлын хүснэгт.
- Гарчгаа давтсан нээлтийн догол мөр.
- Хоёр гурван догол мөр үргэлжилсэн өгүүлэмж, хүлээсэн ба бодит үр дүнг нэг өгүүлбэрт нийлүүлсэн.
- Нууц мэдээлэл —
token, нууц үг, API key, хувийн мэдээлэл. Лог хуулахаасаа өмнө цэвэрлэнэ (Logging стандартын §10-тай ижил дүрэм).
9. Repo-д загварыг суулгах
Загварын файлууд нь issue нээх бүрд маягтыг өөрөө гаргаж өгдөг.
| Платформ | Байрлал | Файл |
|---|---|---|
| GitLab | .gitlab/issue_templates/ | Bug.md, Feature.md |
| GitHub | .github/ISSUE_TEMPLATE/ | bug_report.yml, enhancement.yml |
GitLab-д issue form байдаггүй тул markdown загвар ашиглана — гарчгууд нь §3-ын жагсаалттай яг ижил байна.
Загварын эхэнд GitLab-ийн quick action-оор анхны шошгыг тавина — issue үүсэх үед автоматаар хэрэгжинэ:
/label ~"kind::bug" ~"triage::needed"
§6-гийн шошгын багцыг repo бүрт нэг удаа үүсгэнэ:
$ glab api --method POST "projects/<id>/labels" \
-f "name=triage::ready" -f "color=#0e8a16" \
-f "description=Шалгасан, шийдвэр гарсан — хэрэгжүүлж болно"
10. Шалгах жагсаалт
Хийх (Do)
- Шинж тэмдгийг эхэнд ·
###гарчиг · англи гарчгийн нэрийг яг хэвээр - Ажиллуулж болохуйц дахин гаргах заавар · өөрөө ажиллуулж баталсан байх
- Гарчиг
<дэд систем>: <шинж тэмдэг>·kind::,triage::,area::шошго - Урт гаралтыг
<details>дотор · хувилбарын команд ба гаралт - Байгаа issue-г эхлээд хайх (
glab issue list)
Бүү хий (Don't)
- Кодын блокоор эхлэх ·
**bold**гарчиг ·---тусгаарлагч - Checkbox жагсаалт · эмодзи гарчиг · чухалчлалын хүснэгт
- Нэг issue-д хоёр асуудал · засварыг гарчигт бичих
- Дахин гаргах зааваргүй issue нээх
- Дизайны бүрэн шийдлийг issue-д багтаах
11. Нэр томьёо
| Үг | Юу гэсэн үг вэ |
|---|---|
| triage (эрэмбэлэлт) | Шинэ issue-г үзээд аль төлөвт хамаарахыг шийдэх үйл явц. Эмнэлгийн нэр томьёоноос гаралтай: ирсэн өвчтөнүүдийг ноцтой байдлаар нь ялгаж, хэнд эхэлж тусламж үзүүлэхийг тогтоодог |
| repro / дахин гаргах заавар | Алдааг дахин гаргаж харуулах, ажиллуулж болохуйц команд, тест эсвэл URL (§4) |
scope (::) | Шошгын бүлэг. kind::bug гэдэг нь kind бүлгийн bug утга. Нэг бүлгээс нэг утга тавина (§6) |
| quick action | GitLab-ийн /label ~"..." мэт тушаал. Issue-ийн бичвэрт байвал үүсэх үед автоматаар хэрэгжинэ |
| MR (merge request) | GitLab дээрх нэгтгэх хүсэлт. GitHub дээр үүнийг PR (pull request) гэдэг |
| Master Board | PM-ийн эзэмшдэг Jira самбар (VM, TINO, UBC, CRG). Хөгжүүлэгчийн оролт эндээс ирнэ (§7) |
| service desk | Хэрэглэгч, операторын хүсэлт хүлээж авдаг Jira project (APEX, IT, TRE). PM рүү ордог, хөгжүүлэгч рүү шууд ордоггүй |
| agent | Кодын өөрчлөлтийг бие даан хийж чаддаг AI туслах. triage::ready issue-г хүн ч, agent ч авч болно |
| issue form | GitHub дээрх талбар бүхий маягт (.yml). GitLab дээр байдаггүй тул markdown загвар ашиглана (§9) |
| KEP | Kubernetes Enhancement Proposal — том өөрчлөлтийн дизайныг issue-ээс тусад нь бичдэг баримт бичиг |