การมีส่วนร่วมใน Design System

กระบวนการมีส่วนร่วม จากกลยุทธ์การแตกสาขาไปยังการอัปเดตเวอร์ชันและ pull requests

แบบแผนการตั้งชื่อสาขา

สาขาของเราปฏิบัติตามโครงสร้างนี้:

{ปี}/{ประเภท}/{ผู้แต่ง}/{คำอธิบาย}

ตัวอย่าง: 2025/FEATURE/JEF/NEW_COMPONENT_DOCS

รายละเอียด:

• ปี: ปีปัจจุบัน (เช่น 2025)
• ประเภท: ประเภทของการเปลี่ยนแปลง
  • FEATURE: ฟีเจอร์ใหม่
  • FIX: แก้ไขข้อผิดพลาด
  • CHORE: งานบำรุงรักษา
  • DOCS: อัปเดตเอกสารประกอบ
• ผู้แต่ง: ตัวระบุ/ชื่อของคุณ
• คำอธิบาย: คำอธิบายสั้นในรูปแบบ UPPERCASE ด้วยขีดล่าง หากมีหมายเลขตั๋ว Jira ให้ใช้เป็นคำอธิบาย (เช่น POLY-3)

การอัปเดตเวอร์ชัน

เราปฏิบัติตาม Semantic Versioning (SemVer):

MAJOR.MINOR.PATCH

ตัวอย่าง: 1.2.9

• MAJOR:
  • การเปลี่ยนแปลงที่ไม่เข้ากันได้
• MINOR:
  • ฟีเจอร์ใหม่
  • คอมโพเนนต์ใหม่
  • การอัปเดตสไตล์ขนาดใหญ่
  • การปรับปรุงฟังก์ชันการทำงานที่สำคัญ
• PATCH:
  • แก้ไขข้อผิดพลาด
  • การอัปเดตการออกแบบเล็กน้อย
  • การอัปเดตเอกสารประกอบ
  • การปรับปรุงเล็กน้อย

การอัปเดตเวอร์ชัน

หมายเหตุสำคัญ:

เมื่อใดก็ตามที่อัปเดตเวอร์ชัน minor หรือ major เวอร์ชัน patch หรือ minor จะรีเซ็ตเป็น 0

1. อัปเดต package.json:

{
  "name": "design-system-next",
  "version": "1.0.1" // เพิ่มหมายเลขที่เหมาะสม
  // ... package.json ที่เหลือ
}

2. เพิ่มรายการใน changelog.md:

## 2.12.2 (2025-01-01)

- Feat:
  - เพิ่มฟังก์ชันการทำงานคอมโพเนนต์ใหม่และการรองรับ API ที่ดีขึ้น ([#commit_hash](https://dev.azure.com/sproutphil/Sprout%20Design%20System/_git/Sprout%20Design%20System%20Next/commit/commit_hash?refName=refs/heads/branch_name) โดย @JefMari)
- Fix:
  - แก้ไขปัญหาการเรนเดอร์คอมโพเนนต์และปรับปรุงการจัดการข้อผิดพลาด
- Docs:
  - อัปเดตเอกสารประกอบด้วยตัวอย่างใหม่และแนวทางการใช้งาน

แนวทางการ Pull Request

รูปแบบชื่อเรื่อง

{ประเภท}: {คำอธิบาย}

ตัวอย่าง: docs: เพิ่มคู่มือการสร้างคอมโพเนนต์และการมีส่วนร่วม

ประเภท:

• feat: ฟีเจอร์หรือการปรับปรุงใหม่
• fix: แก้ไขข้อผิดพลาด
• docs: การเปลี่ยนแปลงเอกสารประกอบ
• chore: งานบำรุงรักษา
• refactor: การ refactor โค้ด
• style: การเปลี่ยนแปลงสไตล์โค้ด
• test: เพิ่มการทดสอบ
• enhancement: การปรับปรุงฟีเจอร์ที่มีอยู่

คำอธิบาย

• ชัดเจนและกระชับ
• เริ่มต้นด้วยคำกริยา (เพิ่ม, อัปเดต, แก้ไข, ลบ)
• ใช้ตัวพิมพ์เล็ก
• หากมีหมายเลขตั๋ว Jira ให้รวมไว้ในคำอธิบาย (เช่น POLY-3)

ข้อกำหนด

• การอนุมัติอย่างน้อยหนึ่งคน
• การตรวจสอบทั้งหมดผ่าน
• ไม่มีข้อขัดแย้งในการ merge
• อัปเดตเวอร์ชันและ changelog แล้ว

ตัวอย่าง Pull Request

ชื่อเรื่อง: feat: เพิ่มคอมโพเนนต์ dropdown ปุ่มและปรับปรุงฟังก์ชันการทำงานปุ่ม

คำอธิบาย:

## การเปลี่ยนแปลง

- เพิ่มคอมโพเนนต์ dropdown ปุ่มใหม่พร้อมตัวเลือกที่ปรับแต่งได้
- ปรับปรุงคอมโพเนนต์ปุ่มเพื่อรองรับการผสานรวม dropdown ใหม่
- อัปเดตคอมโพเนนต์ list เพื่อทำงานกับ dropdown ปุ่ม
- อัปเดตเอกสารประกอบด้วยตัวอย่างและแนวทางการใช้งาน
- เพิ่มการปรับปรุงการเข้าถึงสำหรับองค์ประกอบแบบอินเทอร์แอกทีฟ

## รายการตรวจสอบ

- [x] อัปเดตเวอร์ชันใน package.json (1.0.1)
- [x] เพิ่มรายการ changelog
- [x] อัปเดตเอกสารประกอบ
- [x] ทดสอบในเครื่อง
- [x] ไม่มีข้อผิดพลาด linting
- [x] พิจารณาการเข้าถึงแล้ว

กระบวนการเผยแพร่

1. สร้างสาขาฟีเจอร์

git checkout -b 2025/FEATURE/JEF/NEW_COMPONENT_DOCS

2. ทำการเปลี่ยนแปลงและ commit

git add .
git commit -m "docs: เพิ่มคู่มือการสร้างคอมโพเนนต์และการมีส่วนร่วม"

3. อัปเดตเวอร์ชันใน package.json

{
  "version": "1.0.0", 
  "version": "1.0.1"
}

4. เพิ่มรายการ changelog ใน changelog.md

## 1.0.1 (2025-01-01)

- Feat:
  - เพิ่มคอมโพเนนต์ dropdown ปุ่มใหม่พร้อมฟังก์ชันการทำงานที่ปรับปรุงแล้ว ([#commit_hash](https://dev.azure.com/sproutphil/Sprout%20Design%20System/_git/Sprout%20Design%20System%20Next/commit/commit_hash?refName=refs/heads/2025/FEATURE/JEF/BUTTON_DROPDOWN) โดย @JefMari)

- Fix:
  - แก้ไขปัญหา styling ในคอมโพเนนต์ dropdown
- Docs:
  - อัปเดตเอกสารประกอบด้วยตัวอย่างใหม่และแนวทางการใช้งาน

5. สร้าง pull request

• ชื่อเรื่อง: docs: เพิ่มคู่มือการสร้างคอมโพเนนต์และการมีส่วนร่วม
• ขอการตรวจสอบจากสมาชิกทีมอย่างน้อยหนึ่งคน
• รอการอนุมัติ
• รวมหลังได้รับการอนุมัติ

แนวทางปฏิบัติที่ดีที่สุด

1. Commits

   • ใช้ข้อความ commit แบบ conventional
   • ทำให้ commits มุ่งเน้นและเป็นอะตอม
   • อ้างอิงปัญหาในข้อความ commit
   • รวมหมายเลขตั๋ว Jira เมื่อเกี่ยวข้อง (เช่น POLY-120)

2. เอกสารประกอบ

   • อัปเดตเอกสารประกอบควบคู่ไปกับการเปลี่ยนแปลงโค้ด
   • รวมตัวอย่างพร้อม code snippets
   • เพิ่มแนวทางการใช้งานและเอกสาร prop
   • จัดทำเอกสารการเปลี่ยนแปลง API ของคอมโพเนนต์อย่างละเอียด
   • รวมภาพหรือไดอะแกรมเมื่อเป็นประโยชน์

3. คุณภาพโค้ด

   • ปฏิบัติตามสไตล์โค้ดที่มีอยู่
   • เพิ่ม/อัปเดตการทดสอบตามความจำเป็น
   • รัน linters ก่อน commit
   • พิจารณาผลกระทบต่อการเข้าถึง
   • ทดสอบบนเบราว์เซอร์และอุปกรณ์หลายตัวเมื่อเหมาะสม

4. กระบวนการตรวจสอบ

   • ตอบกลับความคิดเห็นการตรวจสอบอย่างรวดเร็ว
   • ทดสอบการเปลี่ยนแปลงอย่างละเอียด
   • อัปเดต PR ตามข้อเสนอแนะ
   • จัดทำเอกสารการเปลี่ยนแปลงที่สำคัญที่ทำระหว่างการตรวจสอบ

การขอความช่วยเหลือ

หากคุณต้องการความช่วยเหลือ:

1. ตรวจสอบเอกสารที่มีอยู่
2. ถามในช่องทีม
3. ติดต่อ maintainers

TIP

จำไว้ว่าจะรักษาการสื่อสารให้ชัดเจนและเป็นมืออาชีพ และเต็มใจที่จะช่วยเหลือผู้อื่นที่อาจมีคำถามเกี่ยวกับการมีส่วนร่วมของคุณเสมอ