کوبرنتیز یک موتور orchestration کانتینر متن‌باز برای خودکارسازی استقرار، مقیاس‌پذیری و مدیریت برنامه‌های کانتینری است. این پروژه متن‌باز توسط Cloud Native Computing Foundation میزبانی می‌شود.
1.1 - مستندات نسخه‌های موجود
این وبگاه(website) شامل مستندات نسخه فعلی کوبرنتیز و چهار نسخه قبلی آن است.
وجود مستندات برای یک نسخه کوبرنتیز لزوماً به معنای پشتیبانی فعلی از آن انتشار نیست. برای آگاهی از اینکه کدام نسخه‌های کوبرنتیز به‌طور رسمی پشتیبانی می‌شوند و این پشتیبانی چه مدت ادامه دارد، دوره پشتیبانی را مطالعه کنید.
2 - (cluster)مدیریت خوشه
2.1 - اجرای kubelet در حالت مستقل
این آموزش به شما نشان می‌دهد که چگونه یک نمونه مستقل از kubelet را اجرا کنید
شما ممکن است انگیزه‌های مختلفی برای اجرای یک kubelet مستقل داشته باشید
این آموزش با هدف آشنایی شما با کوبرنتیز تهیه شده است، حتی اگر تجربه زیادی با آن نداشته باشید. می‌توانید این آموزش را دنبال کنید و در مورد راه‌اندازی گره، پادهای پایه (استاتیک) و نحوه مدیریت کانتینرها توسط کوبرنتیزاطلاعات کسب کنید
پس از دنبال کردن این آموزش، می‌توانید از خوشه ای که دارای control plane برای مدیریت پادها و گره‌ها و انواع دیگر اشیاء است، استفاده کنید. به عنوان مثال،
Hello, minikube
همچنین می‌توانید kubelet را در حالت مستقل اجرا کنید تا برای موارد استفاده در محیط عملیاتی مناسب باشد، مانند اجرای control plane برای یک خوشه (cluster) با قابلیت دسترسی بالا و استقرار انعطاف‌پذیر. این آموزش جزئیات مورد نیاز برای اجرای یک control plane انعطاف‌پذیر را پوشش نمی‌دهد
Objectives
cri-o و kubelet را روی یک سیستم لینوکس نصب کنید و آنها را به عنوان سرویس‌های systemd اجرا کنید.
یک پاد (Pod) با اجرای nginx راه‌اندازی کنید که به درخواست‌های روی پورت TCP 80 روی نشانی IP پاد گوش دهد.
یاد بگیرید که چگونه اجزای مختلف راه‌حل با یکدیگر تعامل دارند.
Caution:
پیکربندی kubelet که برای این آموزش استفاده شده است، از نظر طراحی ناامن است و نباید در محیط عملیاتی استفاده شود
Before you begin
دسترسی ادمین (root) به یک سیستم لینوکس که از systemd و iptables (یا nftables با شبیه‌سازی iptables) استفاده می‌کند
دسترسی به اینترنت برای دانلود اجزای مورد نیاز برای آموزش، مانند:
دسترسی به اینترنت برای دانلود اجزای مورد نیاز برای آموزش، مانند:
به طور پیش‌فرض، اگر حافظه swap روی یک گره شناسایی شود، kubelet شروع به کار نمی‌کند. این بدان معناست که swap باید غیرفعال شود یا توسط kubelet تحمل شود.
Note:
اگر kubelet را طوری پیکربندی کنید که swap را تحمل کند، kubelet همچنان Podها (و کانتینرهای موجود در آن Podها) را طوری پیکربندی می‌کند که از فضای swap استفاده نکنند. برای اینکه بفهمید Podها چگونه می‌توانند از swap موجود استفاده کنند، می‌توانید درباره مدیریت حافظه swap در گره‌های لینوکس بیشتر بخوانید
اگر حافظه swap را فعال کرده‌اید، آن را غیرفعال کنید یا عبارت failSwapOn: false را به پرونده پیکربندی kubelet اضافه کنید
برای بررسی فعال بودن swap:
sudo swapon --show
اگر هیچ خروجی از دستور وجود نداشته باشد، حافظه swap از قبل غیرفعال شده است
برای غیرفعال کردن موقت swap:
sudo swapoff -a
برای اینکه این تغییر در طول راه‌اندازی‌های مجدد پایدار بماند:
مطمئن شوید که swap بسته به نحوه پیکربندی آن در سیستم شما، در /etc/fstab یا systemd.swap غیرفعال باشد
فعال کردن ارسال بسته IPv4
برای بررسی اینکه آیا ارسال بسته IPv4 فعال است:
cat /proc/sys/net/ipv4/ip_forward
اگر خروجی «۱» باشد، از قبل فعال شده است. اگر خروجی «۰» باشد، مراحل بعدی را دنبال کنید
برای فعال کردن ارسال بسته IPv4، یک پرونده پیکربندی ایجاد کنید که پارامتر net.ipv4.ip_forward را روی 1 تنظیم کند:
sudo tee /etc/sysctl.d/k8s.conf <<EOF
net.ipv4.ip_forward = 1
EOF
Note: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the content guide before submitting a change. More information.
یک مجری کانتینر اجرا نصب کنید
آخرین نسخه‌های موجود از بسته‌های مورد نیاز را دانلود کنید (توصیه می‌شود).
بسته به توزیع لینوکس خاص شما، چندین [روش] برای نصب [https://github.com/cri o/cri o/blob/main/install.md] کانتینر CRI O در زمان اجرا وجود دارد. اگرچه CRI O استفاده از بسته‌های deb یا rpm را توصیه می‌کند، اما این آموزش از اسکریپت _static binary bundle_ پروژه CRI O Packaging (https://github.com/crio/packaging/blob/main/README.md) استفاده می‌کند، که هم برای ساده‌سازی فرآیند کلی و هم برای عدم وابستگی به توزیع مورد نظر است
این اسکریپت نرم‌افزارهای مورد نیاز اضافی، مانند cni-plugins برای شبکه‌سازی کانتینر، و crun و runc برای اجرای کانتینرها را نصب و پیکربندی می‌کند
این اسکریپت به طور خودکار معماری پردازنده سیستم شما (amd64 یا arm64) را تشخیص داده و آخرین نسخه‌های بسته‌های نرم‌افزاری را انتخاب و نصب می‌کند
مطمئن شوید که محدوده پیش‌فرض «زیرشبکه» (۱۰.۸۵.۰.۰/۱۶) با هیچ یک از شبکه‌های فعال شما همپوشانی ندارد. در صورت وجود همپوشانی، می‌توانید پرونده را ویرایش کرده و آن را مطابق با آن تغییر دهید. پس از تغییر، سرویس را مجدداً راه‌اندازی کنید
دانلود و نصب kubelet
آخرین نسخه پایدار آخرین نسخه از kubelet را دریافت کنید
sudo tee /etc/kubernetes/kubelet.yaml <<EOF
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
webhook:
enabled: false # Do NOT use in production clusters!
authorization:
mode: AlwaysAllow # Do NOT use in production clusters!
enableServer: false
logging:
format: text
address: 127.0.0.1 # Restrict access to localhost
readOnlyPort: 10255 # Do NOT use in production clusters!
staticPodPath: /etc/kubernetes/manifests
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock
EOF
Note:
از آنجا که شما در حال راه‌اندازی یک خوشه (cluster) عملیاتی نیستید، از HTTP ساده (readOnlyPort: 10255) برای کوئری‌های احراز هویت نشده به API kubelet استفاده می‌کنید
برای اهداف این آموزش، وب‌هوک احراز هویت غیرفعال است و حالت مجوز روی «همیشه مجاز» تنظیم شده است. می‌توانید برای پیکربندی صحیح kubelet در حالت مستقل در محیط خود، اطلاعات بیشتری در مورد حالت‌های مجوز و احراز هویت وب‌هوک کسب کنید.
برای آشنایی با پورت‌هایی که اجزای کوبرنتیز از آنها استفاده می‌کنند، به درگاه ها و پروتکل ها مراجعه کنید.
پارامتر خط فرمان --kubeconfig عمداً در پرونده پیکربندی سرویس حذف شده است. این پارامتر مسیر پرونده [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) را تعیین می‌کند که نحوه اتصال به سرور API را مشخص می‌کند و حالت سرور API را فعال می‌کند. حذف آن، حالت مستقل را فعال می‌کند.
در حالت مستقل، می‌توانید پادها را با استفاده از تنظیمات پاد اجرا کنید. تنظیمات می‌توانند یا در سیستم پرونده محلی باشند یا از طریق HTTP از یک منبع پیکربندی دریافت شوند.
ایجاد یک تنظیمات برای یک Pod:
cat <<EOF > static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
پرونده تنظیمات static-web.yaml را در پوشه /etc/kubernetes/manifests رونوشت کنید.
این صفحه جنبه‌های اساسی استقرار یک kubelet در حالت مستقل را پوشش داد. اکنون آماده استقرار پادها و آزمایش قابلیت‌های اضافی هستید.
توجه داشته باشید که در حالت مستقل، kubelet از دریافت پیکربندی‌های پاد از control plane پشتیبانی نمی‌کند (زیرا هیچ اتصالی به control plane وجود ندارد).
همچنین نمی‌توانید از ConfigMap یا Secret برای پیکربندی کانتینرها در یک پاد استاتیک استفاده کنید.
What's next
برای یادگیری نحوه‌ی اجرای کوبرنتیز با یک control plane، Hello, minikube را دنبال کنید. ابزار minikube به شما کمک می‌کند تا یک خوشه ی تمرینی روی رایانه‌ی خود راه‌اندازی کنید.
(cluster)سازوکاری برای ضمیمه کردن مجوز و سیاست به یک زیربخش از خوشه.
استفاده از چندین فضای نام اختیاری است.
این مثال نحوه استفاده از فضاهای نام کوبرنتیز برای تقسیم‌بندی خوشه (cluster) شما را نشان می‌دهد.
Before you begin
شما باید یک خوشه(Cluster) کوبرنتیز داشته باشید و ابزار خطِّ فرمان kubectl نیز برای برقراری ارتباط با خوشه شما پیکربندی شده باشد. توصیه می‌شود این آموزش را روی خوشه‌ای با دست‌کم دو گره(Node) که به‌عنوان میزبان‌های control plane عمل نمی‌کنند اجرا کنید.
اگر هنوز خوشه ندارید، می‌توانید با استفاده از
minikube
یکی بسازید یا از یکی از محیط‌های آزمایشی کوبرنتیز زیر بهره ببرید:
به طور پیش‌فرض، یک خوشه (cluster) کوبرنتیز هنگام آماده‌سازی خوشه (cluster)، یک فضای نام پیش‌فرض را نمونه‌سازی می‌کند تا مجموعه پیش‌فرض پادها، سرویس‌هاواستقرارها مورد استفاده توسط خوشه را در خود جای دهد.
با فرض اینکه یک خوشه (cluster) جدید دارید، می‌توانید با انجام موارد زیر، فضاهای نام موجود را بررسی کنید:
kubectl get namespaces
NAME STATUS AGE
default Active 13m
ایجاد فضاهای نام جدید
برای این تمرین، دو فضای نام کوبرنتیز اضافی برای نگهداری محتوای خودایجاد خواهیم کرد.
بیایید سناریویی را تصور کنیم که در آن یک سازمان از یک خوشه (cluster) مشترک کوبرنتیز برای موارد استفاده توسعه و تولید استفاده می‌کند.
تیم توسعه می‌خواهد فضایی را در خوشه (cluster) حفظ کند که در آن بتوانند فهرست پادها، سرویس‌هاواستقرارهایی را که برای ساخت و اجرای برنامه خود استفاده می‌کنند، مشاهده کنند. در این فضا، منابع کوبرنتیز می‌آیند و می‌روند و محدودیت‌های مربوط به اینکه چه کسی می‌تواند یا نمی‌تواند منابع را تغییر دهد، کاهش می‌یابد تا توسعه چابک امکان‌پذیر شود.
تیم عملیات مایل است فضایی را در خوشه (cluster) حفظ کند که در آن بتواند رویه‌های سختگیرانه‌ای را در مورد اینکه چه کسی می‌تواند یا نمی‌تواند مجموعه پادها، سرویس‌ها و استقرارهایی را که وبگاه عملیاتی را اداره می‌کنند، دستکاری کند، اعمال کند.
یکی از الگوهایی که این سازمان می‌تواند دنبال کند، تقسیم‌بندی خوشه (cluster) کوبرنتیز به دو فضای نام است: «توسعه» و «تولید».
بیایید دو فضای نام جدید برای نگهداری کارمان ایجاد کنیم.
از پرونده namespace-dev.yaml که یک فضای نام development را توصیف می‌کند، استفاده کنید:
به‌طور پیش‌فرض، دستورات بالا دو context را اضافه می‌کنند که در پرونده «.kube/config» ذخیره می‌شوند. اکنون می‌توانید contextها را مشاهده کنید و بسته به فضای نامی که می‌خواهید با آن کار کنید، متناوب با دو context درخواستی جدید جایگزین کنید.
ما یک استقرار با اندازه رونوشت ۲ عدد پاد ایجاد کرده‌ایم که پادی به نام snowflake را با یک کانتینر پایه که نام میزبان را ارائه می‌دهد، اجرا می‌کند.
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
snowflake 2/2 2 2 2m
kubectl get pods -l app=snowflake
NAME READY STATUS RESTARTS AGE
snowflake-3968820950-9dgr8 1/1 Running 0 2m
snowflake-3968820950-vgc4n 1/1 Running 0 2m
و این عالی است، توسعه‌دهندگان می‌توانند هر کاری که می‌خواهند انجام دهند و لازم نیست نگران تأثیرگذاری بر محتوا در فضای نام «تولید» باشند.
بیایید به فضای نام production برویم و نشان دهیم که چگونه منابع موجود در یک فضای نام از فضای نام دیگر پنهان می‌شوند.
kubectl config use-context prod
فضای نام production باید خالی باشد و دستورات زیر نباید چیزی را برگردانند.
kubectl get deployment
kubectl get pods
بخش تولید دوست دارد گاوها را اداره کند، پس بیایید چند گاوداری ایجاد کنیم.
kubectl create deployment cattle --image=registry.k8s.io/serve_hostname --replicas=5kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
cattle 5/5 5 5 10s
kubectl get pods -l app=cattle
NAME READY STATUS RESTARTS AGE
cattle-2263376956-41xy6 1/1 Running 0 34s
cattle-2263376956-kw466 1/1 Running 0 34s
cattle-2263376956-n4v97 1/1 Running 0 34s
cattle-2263376956-p5p3i 1/1 Running 0 34s
cattle-2263376956-sxpth 1/1 Running 0 34s
در این مرحله، باید مشخص شده باشد که منابعی که کاربران در یک فضای نام ایجاد می‌کنند، از فضای نام دیگر پنهان هستند.
با تکامل پشتیبانی از سیاست در کوبرنتیز، این سناریو را گسترش خواهیم داد تا نشان دهیم چگونه می‌توانید قوانین مجوز متفاوتی را برای هر فضای نام ارائه دهید.
3 - مرجع
این بخش از مستندات کوبرنتیز شامل ارجاعات است.
مرجع API
واژه‌نامه - فهرستی جامع و استاندارد از اصطلاحات کوبرنتیز
kubeadm - ابزار خط فرمانی برای راه‌اندازی آسان یک خوشه ایمن کوبرنتیز.
اجزا
kubelet - عامل اصلی‌ای که روی هر گره اجرا می‌شود. kubelet مجموعه‌ای از PodSpecها را می‌گیرد و اطمینان حاصل می‌کند کانتینرهای توصیف‌شده در حال اجرا و سالم هستند.
kube-apiserver - یک REST API که داده‌های اشیای API مانند پادها، سرویس‌ها و replication controllerها را اعتبارسنجی و پیکربندی می‌کند.
kube-controller-manager - یک Daemon ای که حلقه‌های کنترل اصلی همراه کوبرنتیز را در خود جای داده است.
kube-proxy - می‌تواند ارسال ساده جریان TCP/UDP یا ارسال TCP/UDP به‌صورت round-robin را بین مجموعه‌ای از بک‌اندها انجام دهد.
kube-scheduler - زمان‌بندی‌کننده‌ای که دسترس‌پذیری، عملکرد و ظرفیت را مدیریت می‌کند.
فهرست ports and protocols که باید روی گره‌های Control Plain و Worker باز باشند
پیکربندی APIها
این بخش میزبان مستندات APIهای «منتشر نشده» است که برای پیکربندی اجزا یا ابزارهای کوبرنتیز استفاده می‌شوند. اکثر این APIها توسط سرور API به روش RESTful در معرض نمایش قرار نمی‌گیرند، اگرچه برای کاربر یا اپراتور جهت استفاده یا مدیریت یک خوشه ضروری هستند.
راه‌های زیادی برای مشارکت در کوبرنتیز وجود دارد. می‌توانید روی طراحی قابلیت‌های جدید کار کنید،
کد موجود را مستند کنید یا برای وب نوشت‌های ما بنویسید.
بیش از اینها: می‌توانید آن قابلیت‌های جدید را پیاده‌سازی کرده یا باگ‌ها را رفع کنید.
می‌توانید به افراد برای پیوستن به جامعه مشارکت‌کنندگان کمک کنید یا از مشارکت‌کنندگان فعلی پشتیبانی کنید.
با وجود این همه روش برای تأثیرگذاری بر پروژه، ما – کوبرنتیز – یک تارنما اختصاصی ساخته‌ایم:
https://k8s.dev. می‌توانید به آنجا بروید تا بیشتر درباره
مشارکت در کوبرنتیز بدانید.
اگر به طور خاص می‌خواهید درباره مشارکت در مستندات یا بخش‌های دیگر این تارنما یاد بگیرید،
مشارکت در مستندات کوبرنتیز را مطالعه کنید.
اگر به طور خاص می‌خواهید در وب نوشت‌های رسمی کوبرنتیز کمک کنید،
مشارکت در وب نوشت‌های کوبرنتیز را بخوانید.
همچنین می‌توانید صفحه
مشارکت‌کنندگانCNCF
درباره مشارکت در کوبرنتیز را مطالعه کنید.
4.1 - مشارکت در مستندات کوبرنتیز
این وبسایت توسط Kubernetes SIG Docs نگهداری می‌شود.
پروژه کوبرنتیز از کمک همه مشارکت‌کنندگان، چه تازه‌کار و چه باتجربه، استقبال می‌کند!
مشارکت‌کنندگان مستندات کوبرنتیز:
بهبود محتوای موجود
ایجاد محتوای جدید
ترجمه مستندات
مدیریت و انتشار بخش‌های مستندات در چرخه انتشار کوبرنتیز
تیم وب نوشت، که بخشی از SIG Docs است، به مدیریت وب نوشت‌های رسمی کمک می‌کند. برای کسب اطلاعات بیشتر، مشارکت در وب نوشت‌های کوبرنتیز را بخوانید.
Note:
برای کسب اطلاعات بیشتر درباره مشارکت در کوبرنتیز به‌طور کلی، به وبسایت
مستندات مشارکت‌کنندگان مراجعه کنید.
شروع کنید
هر کسی می‌تواند برای مستندات یک مسئله باز کند یا تغییری را با یک
PR به
مخزن GitHub kubernetes/website ارائه کند.
برای کار مؤثر در جامعه کوبرنتیز لازم است با
git و
GitHub
آشنایی کافی داشته باشید.
flowchart TB
subgraph third[Open PR]
direction TB
U[ ] -.-
Q[Improve content] --- N[Create content]
N --- O[Translate docs]
O --- P[Manage/publish docs parts of K8s release cycle]
end
subgraph second[Review]
direction TB
T[ ] -.-
D[Look over the kubernetes/website repository] --- E[Check out the Hugo static site generator]
E --- F[Understand basic GitHub commands]
F --- G[Review open PR and change review processes]
end
subgraph first[Sign up]
direction TB
S[ ] -.-
B[Sign the CNCF Contributor License Agreement] --- C[Join sig-docs Slack channel]
C --- V[Join kubernetes-sig-docs mailing list]
V --- M[Attend weekly sig-docs calls or slack meetings]
end
A([fa:fa-user New Contributor]) --> first
A --> second
A --> third
A --> H[Ask Questions!!!]
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
class S,T,U spacewhite
class first,second,third white
قدم ۱. شروع به کار برای یک مشارکت‌کننده جدید.
قدم ۱ یک نقشه راه برای مشارکت‌کنندگان تازه‌وارد ترسیم می‌کند. می‌توانید برخی یا همه مراحل «ثبت‌نام» (Sign up) و «بازبینی» (Review) را دنبال کنید. اکنون آماده‌اید تا PRهایی را باز کنید که اهداف مشارکت شما را برآورده سازند؛ برخی از این اهداف در بخش «ایجاد PR» (Open PR) فهرست شده‌اند. باز هم، پرسش‌ها همیشه خوش‌آمدند!
برخی کارها به اعتماد و دسترسی بیشتری در سازمان کوبرنتیز نیاز دارند. برای جزئیات بیشتر درباره نقش‌ها و سطح دسترسی، مشارکت در SIG Docs را ببینید.
اولین مشارکت شما
شما می‌توانید با مرور چندین مرحله از قبل، برای اولین مشارکت خود آماده شوید.
قدم ۲ مراحل و جزئیات بعدی را شرح می‌دهد.
flowchart LR
subgraph second[First Contribution]
direction TB
S[ ] -.-
G[Review PRs from other K8s members] -->
A[Check kubernetes/website issues list for good first PRs] --> B[Open a PR!!]
end
subgraph first[Suggested Prep]
direction TB
T[ ] -.-
D[Read contribution overview] -->E[Read K8s content and style guides]
E --> F[Learn about Hugo page content types and shortcodes]
end
first ----> second
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,D,E,F,G grey
class S,T spacewhite
class first,second white
قدم ۲. آماده‌سازی برای نخستین مشارکت شما.
برای آشنایی با روش‌های گوناگون مشارکت، نمای کلی مشارکت را بخوانید.
فهرست مسائل kubernetes/website را بررسی کنید تا سرنخ‌های مناسبی برای شروع بیابید.
ارائه نخستین مشارکت می‌تواند دلهره‌آور باشد. سفیران مشارکت‌کنندگان جدید
برای همراهی شما در انجام چند مشارکت اول حضور دارند. می‌توانید از طریق Slack کوبرنتیز و ترجیحاً در کانال #sig-docs با آنها ارتباط بگیرید.
همچنین تماس آشنایی و خوشامدگویی به مشارکت‌کنندگان جدید
در اولین سه‌شنبه هر ماه برگزار می‌شود. در آنجا می‌توانید با سفیران مشارکت‌کنندگان جدید تعامل کرده
و پرسش‌های خود را مطرح کنید.
SIG Docs گروهی از مشارکت‌کنندگان است که مستندات کوبرنتیز و وبسایت آن را منتشر و نگهداری می‌کنند. درگیر شدن با SIG Docs راهی عالی برای مشارکت‌کنندگان کوبرنتیز (چه توسعه‌دهندگان قابلیت‌ها و چه سایر افراد) است تا تأثیر بزرگی بر پروژه کوبرنتیز بگذارند.
در هفته‌هایی که جلسه حضوری Zoom برگزار نمی‌شود، در جلسه ایستای غیرهمزمان (Async Stand-up) SIG Docs در Slack شرکت کنید. این جلسات نیز همیشه در #sig-docs اعلام می‌شوند. تا ۲۴ ساعت پس از اعلام جلسه می‌توانید در یکی از رشته‌ها مشارکت کنید.
راه‌های دیگر برای مشارکت کردن
به وبسایت جامعه کوبرنتیز سر بزنید. در توییتر یا Stack Overflow مشارکت کنید،
درباره گردهمایی‌ها و رویدادهای محلی کوبرنتیز و موارد دیگر مطلع شوید.
دو وب نوشت رسمی کوبرنتیز وجود دارد و CNCF نیز وب نوشت اختصاصی خودش را دارد که می‌توانید در آن نیز درباره کوبرنتیز بنویسید.
برای وب نوشت اصلی کوبرنتیز ما (پروژه کوبرنتیز) علاقه داریم مقالاتی با دیدگاه‌های گوناگون و تمرکزهای ویژه منتشر کنیم که به‌نوعی با کوبرنتیز در ارتباط باشند.
به‌جز چند استثنای خاص، ما فقط محتوایی را منتشر می‌کنیم که پیش‌تر در هیچ جای دیگری ارسال یا منتشر نشده باشد.
برای اطلاعات بیشتر در این باره، راهنمای وب نوشت را مطالعه کنید.
وب نوشت‌های رسمی کوبرنتیز
وب نوشت اصلی
وب نوشت اصلی کوبرنتیزتوسط پروژه برای اطلاع‌رسانی درباره قابلیت‌های جدید، گزارش‌های جامعه و هر خبر مرتبط با جامعه کوبرنتیز استفاده می‌شود. این جامعه شامل کاربران نهایی و توسعه‌دهندگان است. بیشتر محتوای وب نوشت درباره رویدادهایی است که در هسته پروژه رخ می‌دهد؛ با این حال، پروژه کوبرنتیز شما را تشویق می‌کند که درباره اتفاقات دیگر در بن‌سازه نیز مطلب ارسال کنید!
هر کسی می‌تواند یک مطلب وب نوشتی بنویسد و آن را برای انتشار ارسال کند. به‌جز چند استثنای خاص، ما فقط محتوایی را منتشر می‌کنیم که پیش‌تر در هیچ جای دیگری ارسال یا منتشر نشده باشد.
وب نوشت مشارکت‌کنندگان
وب نوشت مشارکت‌کنندگان کوبرنتیز برای مخاطبانی است که بیشتر بر روی کوبرنتیز کار می‌کنند تا افرادی که با کوبرنتیز کار می‌کنند.
پروژه کوبرنتیز عمداً برخی مقالات را در هر دو وبلاگ منتشر می‌کند.
هر کسی می‌تواند یک مطلب وب نوشتی بنویسد و آن را برای بازبینی ارسال کند.
به‌روزرسانی و نگهداری مقاله
پروژه کوبرنتیز مقالات قدیمی وب نوشت‌های خود را نگهداری نمی‌کند. این بدان معناست که هر
مقاله منتشرشده‌ای که بیش از یک سال از انتشارش گذشته باشد، معمولاً برای دریافت مسئله
یا درخواست ادغام جهت اعمال تغییرات واجد شرایط نیست. برای جلوگیری از ایجاد رویه، حتی
درخواست ادغام‌های فنی و درست هم به احتمال زیاد رد می‌شوند.
بااین‌حال، استثناهایی وجود دارند؛ مانند:
(به‌روزرسانی‌های) مقالاتی که به‌عنوان همیشه‌سبز علامت خورده‌اند
حذف یا اصلاح مقالاتی که اکنون توصیه‌های نادرست و خطرناک ارائه می‌دهند
رفع خطاها برای اطمینان از اینکه یک مقاله موجود هنوز به‌درستی نمایش داده می‌شود
برای هر مقاله‌ای که بیش از یک سال از انتشارش گذشته و به‌عنوان evergreen علامت نخورده
است، تارنما به‌طور خودکار پیامی را نمایش می‌دهد مبنی بر اینکه محتوا ممکن است قدیمی باشد.
مقالات همیشه سبز
می‌توانید با قرار دادن evergreen: true در مقدمه، یک مقاله را به‌عنوان همیشه‌سبز علامت‌گذاری کنید.
ما فقط زمانی مقالات وب نوشت را به‌عنوان نگه‌داری‌شده (evergreen: true در مقدمه) علامت می‌زنیم که پروژه کوبرنتیز بتواند متعهد شود آنها را برای همیشه نگهداری کند. برخی مقالات وب نوشت بدون تردید شایسته این هستند؛ برای نمونه، تیم ارتباطات انتشار همواره اعلان‌های رسمی را به‌عنوان همیشه‌سبز علامت می‌زند.
هرکسی می‌تواند یک Pull Request مربوط به مستندات را بازبینی (review) کند. برای دیدن Pull Requestهای باز، به بخش
pull requests در مخزن وبسایت کوبرنتیز بروید.
بازبینی Pull Requestهای مستندات راه بسیار خوبی برای معرفی خود به جامعه کوبرنتیز است؛
به شما کمک می‌کند با پایگاه کد آشنا شوید و اعتماد سایر مشارکت‌کنندگان را جلب کنید.
علاوه بر تغییرات، بر جنبه‌های مثبت PRها نیز نظر بگذارید.
همدل باشید و در نظر داشته باشید بازبینی شما چگونه دریافت می‌شود.
نیت خوب را فرض کنید و پرسش‌های روشن‌کننده بپرسید.
مشارکت‌کنندگان باتجربه، با مشارکت‌کنندگان تازه‌ای که کارشان نیاز به تغییرات گسترده دارد جفت شوید.
فرایند بازبینی
به‌طور کلی، Pull Requestها را از نظر محتوا و سبک به زبان انگلیسی بازبینی کنید.
شکل ۱ گام‌های فرایند بازبینی را نشان می‌دهد؛ جزئیات هر گام در ادامه آمده است.
flowchart LR
subgraph fourth[Start review]
direction TB
S[ ] -.-
M[add comments] --> N[review changes]
N --> O[new contributors should choose Comment]
end
subgraph third[Select PR]
direction TB
T[ ] -.-
J[read description and comments]--> K[preview changes in Netlify preview build]
end
A[Review open PR list]--> B[Filter open PRs by label]
B --> third --> fourth
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,J,K,M,N,O grey
class S,T spacewhite
class third,fourth white
Pull Requestهای باز را با استفاده از یک یا همه برچسب‌های زیر فیلتر کنید:
cncf-cla: yes (پیشنهاد می‌شود): PRهایی که نویسنده آنها CLA را امضا نکرده است نمی‌توانند ادغام شوند.
برای اطلاعات بیشتر بخش، CLA امضا را ببینید.
language/en (پیشنهاد می‌شود): فقط PRهای زبان انگلیسی را فیلتر می‌کند.
size/<size>: PRها را بر اساس اندازه فیلتر می‌کند. اگر تازه‌کار هستید، با PRهای کوچک‌تر شروع کنید.
همچنین مطمئن شوید PR با برچسب work in progress علامت‌گذاری نشده باشد؛
چنین PRهایی هنوز آماده بازبینی نیستند.
پس از انتخاب یک PR برای بازبینی، تغییرات را با انجام کارهای زیر درک کنید:
توضیحات PR را بخوانید تا تغییرات انجام‌شده را بفهمید و هر Issue پیوند‌شده را بررسی کنید.
نظرهای سایر بازبین‌ها را بخوانید.
روی تب Files changed کلیک کنید تا فایل (پرونده)ها و خطوط تغییر‌یافته را ببینید.
پیش‌نمایش تغییرات را در ساخت پیش‌نمایش Netlify مشاهده کنید. برای این کار، در تب Conversation به بخش بررسی ساخت Netlify که در پایین صفحه قرار دارد بروید.
(این تصویر مربوط به نسخه دسکتاپ GitHub است؛ اگر در تبلت یا تلفن همراه بازبینی می‌کنید، رابط کاربری GitHub کمی متفاوت است):
برای باز کردن پیش‌نمایش، روی پیوند Details در خط deploy/netlify در فهرست بررسی‌ها کلیک کنید.
به تب Files changed بروید تا بازبینی را آغاز کنید.
روی نماد + کنار خطی که می‌خواهید نظر بدهید کلیک کنید.
نظر خود را درباره آن خط بنویسید و روی Add single comment (اگر تنها یک نظر دارید) یا
Start a review (اگر چند نظر دارید) کلیک کنید.
پس از پایان، در بالای صفحه روی Review changes کلیک کنید. اینجا می‌توانید
خلاصه‌ای از بازبینی خود (و چند نظر مثبت برای مشارکت‌کننده!) بنویسید. لطفاً همیشه از دکمه "Comment" استفاده کنید.
هنگام پایان بازبینی، از کلیک روی دکمه "Request changes" پرهیز کنید.
اگر می‌خواهید پیش از اعمال تغییرات بیشتر مانع ادغام PR شوید، می‌توانید کامنت /hold بگذارید.
دلیل hold را ذکر کنید و در صورت تمایل شرایط برداشتن آن را مشخص کنید.
هنگام پایان بازبینی، از کلیک روی دکمه "Approve" پرهیز کنید.
بیشتر مواقع گذاشتن کامنت /approve توصیه می‌شود.
چک‌لیست بازبینی
هنگام بازبینی، از موارد زیر به‌عنوان نقطه شروع استفاده کنید.
زبان و دستور زبان
آیا خطاهای آشکاری در زبان یا دستور زبان وجود دارد؟ آیا راه بهتری برای بیان یک جمله هست؟
روی زبان و دستور زبان بخش‌هایی از صفحه که نویسنده تغییر داده تمرکز کنید.
مگر اینکه نویسنده آشکارا قصد به‌روزرسانی کل صفحه را داشته باشد، او الزام ندارد
همه اشکالات صفحه را برطرف کند.
وقتی یک PR صفحه‌ای موجود را به‌روزرسانی می‌کند، روی بخش‌های تغییر یافته صفحه بازبینی کنید.
آن محتوا باید از نظر فنی و ویرایشی درست باشد. اگر خطاهایی پیدا کردید که مستقیماً به هدف نویسنده مرتبط نیست،
آن را در یک Issue جداگانه مطرح کنید (البته ابتدا مطمئن شوید Issue مشابهی وجود ندارد).
مراقب Pull Requestهایی باشید که محتوا را جابه‌جا می‌کنند. اگر نویسنده صفحه‌ای را
تغییر نام می‌دهد یا دو صفحه را ادغام می‌کند، ما (SIG Docs کوبرنتیز) معمولاً از او نمی‌خواهیم
همه ایرادهای املایی یا دستور زبانی موجود در محتوای جابه‌جا شده را برطرف کند.
آیا واژه‌های پیچیده یا کهنه‌ای هست که بتوان آنها را با واژه‌ای ساده‌تر جایگزین کرد؟
آیا واژه، اصطلاح یا عبارتی هست که بتوان آن را با جایگزینی غیرتبعیض‌آمیز عوض کرد؟
آیا انتخاب واژه و حروف بزرگ/کوچک کردن آن با راهنمای سبک هماهنگ است؟
آیا جمله‌های طولانی وجود دارد که می‌تواند کوتاه‌تر یا ساده‌تر شود؟
آیا پاراگراف‌های طولانی وجود دارد که شاید به‌صورت فهرست یا جدول بهتر باشند؟
محتوا
آیا محتوای مشابهی در جای دیگری از سایت کوبرنتیز وجود دارد؟
آیا محتوا بیش از حد به مستندات خارج از وبسایت، مستندات متعلق به یک فروشنده ی خاص یا مستندات غیرمتن‌باز پیوند می‌دهد؟
مستندات
چند بررسی که باید در نظر گرفت:
آیا این PR عنوان، slug/alias یا پیوند لنگری (anchor link) صفحه‌ای را تغییر داده یا حذف کرده است؟ اگر بله، آیا در نتیجه این PR پیوندهای شکسته‌ای ایجاد شده است؟ آیا گزینه دیگری مثل تغییر عنوان صفحه بدون تغییر slug وجود دارد؟
آیا PR صفحه‌ای جدید اضافه می‌کند؟ اگر بله:
آیا صفحه از نوع محتوای صفحه مناسب و شورتکدهای مرتبط Hugo استفاده می‌کند؟
آیا صفحه در ناوبری جانبی آن بخش به‌درستی نمایش داده می‌شود (یا اصلاً نمایش داده می‌شود)؟
آیا تغییرات در پیش‌نمایش Netlify نمایش داده می‌شوند؟ درباره فهرست‌ها، بلاک‌های کد، جدول‌ها،
نکته‌ها و تصاویر دقیق باشید.
وب‌نوشت (blog)
بازخورد زودهنگام درباره پست‌های وب‌نوشت (blog) از طریق Google Doc یا HackMD استقبال می‌شود.
لطفاً درخواست خود را از کانال Slack #sig-docs-blog زودتر ارسال کنید.
همچنین درباره مقالات evergreen و نحوه تصمیم‌گیری درباره evergreen بودن مقاله اطلاعات داشته باشید.
مقالات وب‌نوشت (blog) ممکن است شامل نقل‌قول مستقیم و
گفتار غیرمستقیم باشند.
برای متنی که به فردی نسبت داده شده یا بخشی از گفت‌وگویی واقعی است، پیشنهاد بازنویسی ندهید—حتی اگر
دستور زبان گوینده اصلی درست نباشد. در این موارد همچنین سعی کنید علامات نگارشی پیشنهادی نویسنده را حفظ کنید مگر اینکه واضحاً اشتباه باشد.
به‌عنوان پروژه، فقط زمانی مقالات وب‌نوشت (blog) را با برچسب نگهداری (evergreen: true در front matter) علامت می‌کنیم
که پروژه Kubernetes متعهد باشد آنها را به‌طور نامحدود نگهداری کند.
برخی مقالات قطعاً ارزش این کار را دارند و ما همیشه اطلاعیه‌های انتشار را evergreen علامت می‌کنیم.
اگر درباره نحوه بازبینی این مورد مطمئن نیستید، با سایر مشارکت‌کنندگان مشورت کنید.
راهنمای محتوا بدون قید و شرط بر مقالات وب‌نوشت (blog)
و PRهایی که آنها را اضافه می‌کنند اعمال می‌شود. به یاد داشته باشید برخی محدودیت‌ها فقط
به مستندات مربوط‌اند و برای مقالات وب‌نوشت (blog) صدق نمی‌کنند.
بررسی کنید که منبع Markdown از نوع مناسب محتوای صفحه
و / یا layout مناسب استفاده می‌کند.
سایر
مراقب ویرایش‌های جزئی (Trivial Edits) باشید؛
اگر تغییری را ویرایش جزئی تشخیص می‌دهید، این سیاست را یادآور شوید
(اگر واقعاً بهبود است، قبول تغییر اشکالی ندارد).
نویسندگانی را که در حال انجام اصلاحات مربوط به فاصله‌گذاری (whitespace) هستند تشویق کنید که این کار را در اولین commit PR خود انجام دهند و سپس تغییرات دیگر را روی آن اضافه کنند. این کار هم ادغام (merge) و هم بازبینی‌ها را ساده‌تر می‌کند. به‌ویژه مراقب تغییرات جزئی باشید که همراه با مقدار زیادی اصلاح فاصله‌گذاری در یک commit واحد انجام شده‌اند (و اگر چنین موردی دیدید، نویسنده را تشویق کنید تا آن را اصلاح کند).
به‌عنوان بازبین، اگر مسائل کوچکی در PR یافتید که برای معنا حیاتی نیستند، مثل غلط‌های املایی
یا فاصله نادرست، نظر خود را با پیشوند nit: بنویسید.
این به نویسنده نشان می‌دهد این بخش از بازخورد شما غیر بحرانی است.
اگر در حال بررسی تأیید یک Pull Request هستید و تمام بازخوردهای باقی‌مانده با nit
علامت‌گذاری شده‌اند، می‌توانید PR را ادغام کنید. در این حالت، توصیه می‌شود برای
موارد nit باقی‌مانده یک issue جدید باز کنید. همچنین در نظر بگیرید که آیا می‌توانید
آن issue جدید را به‌عنوان Good First Issue علامت‌گذاری کنید یا خیر؛
اگر امکان‌پذیر باشد، این ها منابع خوبی (برای مشارکت‌کنندگان تازه‌وارد) خواهند بود.
4.3.2 - بازبینی برای تأییدکنندگان و بازبین‌ها
بازبین‌ها (Reviewers) و
تأییدکنندگان (Approvers) در SIG Docs
هنگام بازبینی یک تغییر چند کار اضافه نیز انجام می‌دهند.
هر هفته یکی از تأییدکنندگان مستندات (docs approver) داوطلب می‌شود تا Pull Requestها را تریاژ (triage) و بازبینی کند.
این فرد در آن هفته "PR Wrangler" است. برای اطلاعات بیشتر، به
زمان‌بندی PR Wrangler مراجعه کنید.
برای تبدیل شدن به PR Wrangler، در نشست هفتگی SIG Docs شرکت کنید و داوطلب شوید.
حتی اگر در برنامهٔ همین هفته نام شما نیست، هنوز هم می‌توانید Pull Requestهایی (PRها) را که در حال حاضر تحت بازبینی فعال نیستند، بررسی کنید.
علاوه بر چرخشی بودن، یک بات بازبین‌ها و تأییدکنندگان PR را بر اساس مالکیت فایل (پرونده)های تحت تأثیر تعیین می‌کند.
هر آنچه در بازبینی یک Pull Request آمده است صدق می‌کند،
اما بازبین‌ها و تأییدکنندگان باید کارهای زیر را نیز انجام دهند:
استفاده از دستور Prow /assign برای اختصاص دادن یک بازبین مشخص به یک Pull Request در صورت نیاز. این کار به‌ویژه زمانی اهمیت بیشتری دارد که نیاز به درخواست بازبینی فنی از مشارکت‌کنندگان کد باشد.
Note:
به فیلد reviewers در front-matter بالای فایل (پرونده) Markdown نگاه کنید تا ببینید چه کسی می‌تواند بازبینی فنی انجام دهد.
اطمینان از اینکه PR مطابق با راهنمای محتوا و راهنمای سبک است؛
اگر این‌طور نیست، نویسنده را به بخش مربوطه در راهنما(ها) ارجاع دهید.
استفاده از گزینه Request Changes در GitHub در صورت لزوم برای پیشنهاد تغییر به نویسنده PR.
تغییر وضعیت بازبینی خود در GitHub با استفاده از دستورات Prow /approve یا /lgtm
اگر پیشنهادهای شما اعمال شده‌اند.
commit در PR شخص دیگر
گذاشتن نظر در PR مفید است، اما گاهی ممکن است لازم باشد در Pull Request شخص دیگری commit کنید.
هرگز کار شخص دیگری را «به‌دست نگیرید» مگر اینکه خود او صراحتاً درخواست کرده باشد
یا قصد داشته باشید یک PR قدیمی و رهاشده را احیا کنید.
گرچه این کار ممکن است در کوتاه‌مدت سریع‌تر باشد، اما فرصت مشارکت را از آن فرد می‌گیرد.
روش کار بستگی دارد به اینکه آیا نیاز دارید فایلی (پرونده‌ای) را ویرایش کنید که در دامنهٔ PR است
یا فایلی (پرونده‌ای) را که هنوز در آن PR تغییری نکرده است.
شما نمی‌توانید در PR شخص دیگر commit کنید اگر یکی از شرایط زیر برقرار باشد:
اگر نویسنده PR شاخه (branch) خود را مستقیماً به مخزن
https://github.com/kubernetes/website/
پوش کرده باشد. تنها بازبینی‌کننده‌ای با دسترسی push می‌تواند در PR کاربر دیگر commit کند.
Note:
نویسنده را تشویق کنید دفعه بعد شاخه خود را در fork شخصی بسازد و سپس PR باز کند.
نویسنده PR به‌صراحت ویرایش توسط تأییدکنندگان را غیرفعال کرده باشد.
دستورات Prow برای بازبینی
Prow
سیستم CI/CD مبتنی بر کوبرنتیز است که روی Pull Requestها اجرا می‌شود.
Prow امکان استفاده از دستورات شبیه به چت‌بات را فراهم می‌کند تا کارهای GitHub مانند افزودن یا حذف برچسب‌ها، بستن Issueها و تعیین تاییدکنندگان را مدیریت کند.
دستورات Prow به‌صورت کامنت در GitHub و با فرمت /<command-name> نوشته می‌شوند.
رایج‌ترین دستورات Prow برای بازبین‌ها و تأییدکنندگان عبارتند از:
دستورات Prow برای بازبینی
دستور Prow
محدودیت نقش
توضیحات
/lgtm
اعضای سازمان
نشان می‌دهد بازبینی شما تمام شده و از تغییرات راضی هستید.
/approve
تایید کنندگان
PR را برای ادغام تأیید می‌کند.
/assign
همه
شخصی را برای بازبینی یا تأیید PR تعیین می‌کند.
/close
اعضای سازمان
یک Issue یا PR را می‌بندد.
/hold
همه
برچسب do-not-merge/hold را اضافه می‌کند و مانع ادغام خودکار PR می‌شود.
/hold cancel
همه
برچسب do-not-merge/hold را حذف می‌کند.
برای دیدن لیست کامل دستورات قابل استفاده در PR، به
Prow مرجع دستورات مراجعه کنید.
دسته‌بندی و اولویت‌بندی Issueها
به‌طور کلی، SIG Docs از فرآیند
تریاژ Issueها در کوبرنتیز
پیروی می‌کند و از همان برچسب‌ها استفاده می‌کند.
این فیلتر
در GitHub، فهرستی از issueها را پیدا می‌کند که ممکن است به تریاژ نیاز داشته باشند.
Triage یک Issue
اعتبارسنجی Issue
مطمئن شوید که Issue مربوط به مستندات وبسایت است. برخی Issueها با پاسخ سریع یا ارجاع بسته می‌شوند.
(به بخش درخواست‌های پشتیبانی یا گزارش باگ کد مراجعه کنید.)
بررسی کنید که Issue ارزش پیگیری دارد یا نه.
اگر Issue جزئیات کافی ندارد یا قالب به‌درستی پر نشده، برچسب triage/needs-information اضافه کنید.
اگر Issue هم lifecycle/stale و هم triage/needs-information دارد، آن را ببندید.
قابل تعویق نامحدود؛ هر زمان منابع در دسترس بود انجام دهید.
priority/awaiting-more-evidence
نگه‌دارنده یک Issue بالقوه خوب تا گم نشود.
help یا good first issue
مناسب برای کسی با تجربه بسیار کم در کوبرنتیز یا SIG Docs. برای اطلاعات بیشتر، Help Wanted و Good First Issue را ببینید.
در صورت صلاحدید، مالکیت یک Issue را بر عهده بگیرید و برای آن PR ارسال کنید
(به‌ویژه اگر سریع انجام می‌شود یا مرتبط با کاری است که همین حالا انجام می‌دهید).
در هر دو حالت، برچسب باید از قبل وجود داشته باشد. اگر تلاش کنید برچسبی که وجود ندارد را اضافه کنید، فرمان بدون پیام نادیده گرفته می‌شود.
لیست همه برچسب‌ها در بخش برچسب‌های مخزن وبسایت موجود است.
همه برچسب‌ها توسط SIG Docs استفاده نمی‌شوند.
برچسب‌های چرخه عمر Issue
Issueها معمولاً به‌سرعت باز و بسته می‌شوند. بااین‌حال، گاهی یک Issue پس از باز شدن غیرفعال می‌شود و گاهی لازم است بیش از ۹۰ روز باز بماند.
برچسب‌های چرخه عمر Issue
برچسب
توضیحات
lifecycle/stale
پس از ۹۰ روز بدون فعالیت، Issue به‌طور خودکار با این برچسب علامت‌گذاری می‌شود. اگر چرخه عمر به‌صورت دستی با فرمان /remove-lifecycle stale برگردانده نشود، Issue خودکار بسته خواهد شد.
lifecycle/frozen
Issue دارای این برچسب پس از ۹۰ روز غیرفعال شدن منقضی نمی‌شود. کاربر این برچسب را دستی برای Issueهایی اضافه می‌کند که باید مدت‌زمان بسیار طولانی‌تری باز بمانند، مانند آن‌هایی که برچسب priority/important-longterm دارند.
مدیریت انواع خاص Issueها
SIG Docs به‌اندازه‌ای با انواع زیر از Issue مواجه می‌شود که لازم است شیوه رسیدگی به آنها مستند شود.
Issueهای تکراری
اگر یک مشکل واحد بیش از یک Issue باز دارد، آنها را در یک Issue ادغام کنید.
تصمیم بگیرید کدام Issue باز بماند (یا یک Issue جدید باز کنید)، سپس تمام اطلاعات مرتبط را منتقل کرده و Issueهای مرتبط را پیوند کنید.
در نهایت، به همه Issueهای دیگر که همان مشکل را توصیف می‌کنند برچسب triage/duplicate بزنید و آنها را ببندید. داشتن یک Issue منفرد، سردرگمی را کاهش می‌دهد و از دوباره‌کاری جلوگیری می‌کند.
Issueهای مربوط به پیوندهای خراب
اگر Issue پیوند مرده در مستندات API یا kubectl است، تا زمانی که مشکل کاملاً درک شود به آن برچسب /priority critical-urgent بدهید.
به تمام Issueهای پیوند مرده دیگر برچسب /priority important-longterm بدهید، چون باید به‌صورت دستی رفع شوند.
Issueهای وب‌نوشت (blog)
انتظار می‌رود مطالب وب‌نوشت (blog) کوبرنتیز با گذر زمان قدیمی شوند؛ بنابراین فقط مطالب کمتر از یک‌سال را نگهداری می‌کنیم.
اگر Issue مربوط به مطلبی قدیمی‌تر از یک سال است، معمولاً باید Issue را بدون رفع ببندید.
در صورت وجود توجیه مناسب، ایجاد استثنا اشکالی ندارد.
درخواست های پشتیبانی یا گزارش باگ کد
برخی از Issueهای مربوط به مستندات در واقع به کد اصلی مربوط می‌شوند یا درخواست کمک هستند،
برای مثال زمانی که یک آموزش (tutorial) درست کار نمی‌کند.
برای Issueهایی که به مستندات مربوط نیستند، آنها را با برچسب kind/support ببندید
و در یک کامنت، درخواست‌کننده را به کانال‌های پشتیبانی دیگر (مانند Slack یا Stack Overflow) راهنمایی کنید.
اگر Issue مربوط به باگ در یک قابلیت باشد، درخواست‌کننده را به مخزن مرتبط هدایت کنید
(مخزن kubernetes/kubernetes نقطهٔ شروع مناسبی است).
نمونه پاسخ به درخواست پشتیبانی:
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](https://slack.k8s.io/). You can also search
resources like
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.
If this is a documentation issue, please re-open this issue.
نمونه پاسخ به گزارش باگ کد:
This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
squash کردن (Squashing)
به‌عنوان یک تأییدکننده، هنگام بازبینی Pull Requestها (PRها) ممکن است در شرایط مختلف یکی از کارهای زیر را انجام دهید:
به مشارکت‌کننده توصیه کنید commitهایش را squash کند.
commitها را به‌جای مشارکت‌کننده squash کنید.
به مشارکت‌کننده توصیه کنید هنوز squash نکند.
مانع از squash شدن شوید.
توصیه به مشارکت‌کنندگان برای squash: یک مشارکت‌کننده تازه‌وارد ممکن است نداند که باید commitهایش را در PR squash کند. در این صورت، او را راهنمایی کنید، پیوندهای مفید در اختیارش بگذارید و در صورت نیاز پیشنهاد کمک بدهید. چند پیوند مفید:
squash commit برای مشارکت‌کنندگان: اگر مشارکت‌کننده ممکن است در squash کردن مشکل داشته باشد یا فشار زمانی برای ادغام PR وجود دارد، می‌توانید squash را برای او انجام دهید:
در یک PR، اگر مشارکت‌کننده اجازهٔ مدیریت PR را به نگه‌دارندگان (maintainers) بدهد،
می‌توانید commitهای او را squash کنید و fork او را با نتیجهٔ نهایی به‌روزرسانی نمایید.
پیش از انجام squash، به او توصیه کنید آخرین تغییرات خود را ذخیره کرده و به PR پوش کند.
پس از squash نیز به او بگویید commit squash شده را به کلون محلی خود pull کند.
همچنین می‌توانید با استفاده از یک برچسب (label) کاری کنید که GitHub commitها را squash کند،
به‌طوری که Tide / GitHub این کار را انجام دهند؛
یا هنگام ادغام PR روی دکمهٔ Squash commits کلیک کنید.
توصیه برای پرهیز از squash
اگر یک commit تغییرات خراب‌کننده یا نادرستی انجام داده باشد و commit آخر برای بازگرداندن (revert) آن خطا باشد،
در این حالت commitها را squash نکنید.
حتی اگر در تب "Files changed" در PR در GitHub و در پیش‌نمایش Netlify همه‌چیز درست به‌نظر برسد،
ادغام چنین PRی می‌تواند برای دیگر مشارکت‌کنندگان باعث ایجاد conflict در rebase یا merge شود.
در چنین شرایطی، متناسب با صلاحدید خود مداخله کنید تا از ایجاد مشکل برای دیگر مشارکت‌کنندگان جلوگیری شود.
هرگز squash نکنید
اگر در حال راه‌اندازی یک بومی‌سازی (localization) یا انتشار مستندات برای یک نسخهٔ جدید هستید،
در این حالت شاخه‌ای را ادغام می‌کنید که از fork یک کاربر نیست؛
در چنین شرایطی هرگز commitها را squash نکنید.
عدم squash در اینجا ضروری است زیرا باید تاریخچهٔ کامل commitها برای آن فایل (پرونده)ها حفظ شود.
4.4 - بومی‌سازی مستندات کوبرنتیز
این صفحه به شما نشان می‌دهد که چگونه مستندات را برای زبان‌های مختلف بومی‌سازی کنید.
برای جزئیات بیشتر در مورد نحوه مشارکت در یک بومی‌سازی خاص، به دنبال نسخه بومی‌سازی‌شده این صفحه باشید.
کد دو حرفی زبان خود را پیدا کنید
ابتدا، برای یافتن کد دو حرفی زبان محلی‌سازی خود، به استاندارد ISO 639-1 مراجعه کنید. برای مثال، کد دو حرفی زبان کره‌ای «ko» است.
برخی از زبان‌ها از نسخه کوچک کد کشور که توسط ISO-3166 تعریف شده است، همراه با کدهای زبان خود استفاده می‌کنند. برای مثال، کد زبان پرتغالی برزیلی «pt-br» است.
git clone https://github.com/<username>/website
cd website
پوشه محتوای تارنما شامل زیرپوشه هایی برای هر زبان است. محلی‌سازی که می‌خواهید به آن کمک کنید، درون content/<two-letter-code> قرار دارد.
پیشنهاد تغییرات
صفحه بومی‌سازی‌شده‌ی انتخابی خود را بر اساس نسخه انگلیسی آن ایجاد یا به‌روزرسانی کنید. برای جزئیات بیشتر به بومی‌سازی محتوا مراجعه کنید.
اگر متوجه یک بی‌دقتی فنی یا مشکل دیگری در مستندات بالادستی (انگلیسی) شدید، ابتدا باید مستندات بالادستی را اصلاح کنید و سپس با به‌روزرسانی بومی‌سازی که روی آن کار می‌کنید، اصلاح معادل را تکرار کنید.
تغییرات در یک درخواست ادغام را به یک محلی‌سازی واحد محدود کنید. بررسی درخواست‌های ادغام که محتوا را در چندین محلی‌سازی تغییر می‌دهند، مشکل‌ساز است.
برای پیشنهاد تغییرات در آن بومی‌سازی، از پیشنهاد بهبود محتوا پیروی کنید. این فرآیند مشابه پیشنهاد تغییرات در محتوای بالادستی (انگلیسی) است.
شروع یک محلی‌سازی جدید
اگر می‌خواهید مستندات کوبرنتیز به یک زبان جدید بومی‌سازی شود، مراحل زیر را باید انجام دهید.
از آنجا که مشارکت‌کنندگان نمی‌توانند درخواست‌های ادغام خود را تأیید کنند، برای شروع بومی‌سازی حداقل به دو مشارکت‌کننده نیاز دارید.
همه تیم‌های محلی‌سازی باید خودکفا باشند. تارنما کوبرنتیز خوشحال است که میزبان کار شما باشد، اما ترجمه آن و به‌روز نگه داشتن محتوای محلی‌سازی شده موجود به عهده شماست.
شما باید کد دو حرفی زبان خود را بدانید. برای یافتن کد دو حرفی زبان محلی خود، به استاندارد ISO 639-1 مراجعه کنید. برای مثال، کد دو حرفی زبان کره‌ای «ko» است.
اگر زبانی که می‌خواهید بومی‌سازی آن را شروع کنید، در مکان‌های مختلفی صحبت می‌شود و تفاوت‌های قابل توجهی بین گونه‌های مختلف آن وجود دارد، ممکن است منطقی باشد که کد کشور ISO-3166 با حروف کوچک را با کد دو حرفی آن زبان ترکیب کنید. به عنوان مثال، پرتغالی برزیلی به صورت «pt-br» بومی‌سازی شده است.
وقتی محلی‌سازی جدیدی را شروع می‌کنید، باید قبل از اینکه پروژه کوبرنتیز بتواند تغییرات شما را در تارنما زنده منتشر کند، تمام حداقل محتوای مورد نیاز را محلی‌سازی کنید.
اسناد SIG می‌توانند به شما کمک کنند تا روی یک شاخه جداگانه کار کنید تا بتوانید به تدریج به سمت آن هدف حرکت کنید.
پیدا کردن جامعه
به کوبرنتیز SIG اسناد اطلاع دهید که به ایجاد محلی‌سازی علاقه‌مند هستید! به کانال SIG Docs در Slack و کانال SIG Docs Localizations در Slack بپیوندید. سایر تیم‌های محلی‌سازی خوشحال می‌شوند که در شروع کار به شما کمک کنند و به سوالات شما پاسخ دهند.
لطفاً شرکت در جلسه زیرگروه محلی‌سازی اسناد SIG را نیز در نظر بگیرید. ماموریت زیرگروه محلی‌سازی اسناد SIG، همکاری در تیم‌های محلی‌سازی اسناد SIG برای همکاری در تعریف و مستندسازی فرآیندهای ایجاد راهنماهای مشارکتی محلی‌سازی شده است. علاوه بر این، زیرگروه محلی‌سازی اسناد SIG به دنبال فرصت‌هایی برای ایجاد و اشتراک‌گذاری ابزارهای مشترک در بین تیم‌های محلی‌سازی و شناسایی الزامات جدید برای تیم رهبری اسناد SIG است. اگر در مورد این جلسه سؤالی دارید، لطفاً در کانال محلی‌سازی اسناد SIG سوال کنید.
همچنین می‌توانید یک کانال Slack برای محلی‌سازی خود در مخزن kubernetes/community ایجاد کنید. برای مثالی از اضافه کردن یک کانال Slack،به درخواست ادغام مربوط به اضافه کردن یک کانال برای زبان فارسی مراجعه کنید.
به سازمان گیت هاب کوبرنتیز بپیوندید
وقتی یک درخواست ادغام محلی‌سازی باز کردید، می‌توانید عضو سازمان گیت هاب کوبرنتیز شوید. هر فرد در تیم باید درخواست عضویت سازمان خود را (https://github.com/kubernetes/org/issues/new/choose) در مخزن kubernetes/org ایجاد کند.
تیم محلی‌سازی خود را در گیت‌هاب اضافه کنید
در مرحله بعد، تیم محلی‌سازی کوبرنتیز خود را به sig-docs/teams.yaml اضافه کنید. برای مثالی از اضافه کردن یک تیم محلی‌سازی، به درخواست ادغام برای اضافه کردن تیم محلی‌سازی اسپانیایی مراجعه کنید.
اعضای «@kubernetes/sig-docs--owners» می‌توانند درخواست ادغام هایی را تأیید کنند که محتوا را در پوشه محلی‌سازی شما (و فقط در داخل) تغییر می‌دهد: «/content//». برای هر محلی‌سازی، تیم @Kubernetes/sig-docs-**-reviews تکالیف بررسی درخواست های ادغام جدید را خودکار می‌کند. اعضای @kubernetes/website-maintainers می‌توانند شاخه‌های محلی‌سازی جدیدی برای هماهنگی تلاش‌های ترجمه ایجاد کنند. اعضای @kubernetes/website-milestone-maintainers می‌توانند از /milestoneدستور Prow برای اختصاص یک نقطه عطف به مسائل یا درخواست های ادغام استفاده کنند.
پیکربندی گردش کار
در مرحله بعد، یک برچسب GitHub برای محلی‌سازی خود در مخزن kubernetes/test-infra اضافه کنید. یک برچسب به شما امکان می‌دهد مشکلات را فیلتر کرده و درخواست‌ها را برای زبان خاص خود دریافت کنید.
تارنمای کوبرنتیز از Hugo به عنوان قالب وب خود استفاده می‌کند. پیکربندی Hugo این تارنما در پرونده hugo.toml قرار دارد. برای پشتیبانی از محلی‌سازی جدید، باید hugo.toml را تغییر دهید.
یک بلوک پیکربندی برای زبان جدید به hugo.toml زیر بلوک [languages] موجود اضافه کنید. برای مثال، بلوک زبان آلمانی به شکل زیر خواهد بود:
نوار انتخاب زبان، مقدار مربوط به languageName را فهرست می‌کند. "نام زبان به خط بومی و زبان (نام زبان انگلیسی به خط لاتین)" را به languageName اختصاص دهید. برای مثال، languageName = "한국어 (کره‌ای)" یا languageName = "Deutsch (آلمانی)".
می‌توان از languageNameLatinScript برای دسترسی به نام زبان به خط لاتین و استفاده از آن در قالب استفاده کرد. "نام زبان به خط لاتین" را به languageNameLatinScript اختصاص دهید. برای مثال، languageNameLatinScript ="Korean" یا languageNameLatinScript ="Deutsch".
پارامتر «وزن» ترتیب زبان‌ها را در نوار انتخاب زبان تعیین می‌کند. وزن کمتر اولویت دارد و در نتیجه زبان اول ظاهر می‌شود. هنگام اختصاص پارامتر «وزن»، بررسی بلوک زبان‌های موجود و تنظیم وزن آنها برای اطمینان از اینکه نسبت به همه زبان‌ها، از جمله هر زبان جدید اضافه شده، به ترتیب مرتب شده‌اند، مهم است.
برای اطلاعات بیشتر در مورد پشتیبانی چند زبانه Hugo، به "حالت چند زبانه" مراجعه کنید.
یک پوشه محلی‌سازی جدید اضافه کنید
یک زیرشاخه مختص به زبان مورد نظر را به پوشه content در مخزن اضافه کنید. برای مثال، کد دو حرفی برای زبان آلمانی de است:
mkdir content/de
شما همچنین باید یک پوشه در داخل «i18n» برای ایجاد کنید
رشته های محلی شده; برای مثال به محلی سازی های موجود نگاه کنید.
برای مثال، برای زبان آلمانی، رشته‌ها در i18n/de/de.toml قرار دارند.
بومی‌سازی ضوابط رفتاری جامعه
برای اضافه کردن اصول اخلاقی به زبان خودتان، یک درخواست ادغام در مخزن cncf/foundation باز کنید.
پرونده‌های مالکان را تنظیم کنید
برای تنظیم نقش‌های هر کاربر که در بومی‌سازی مشارکت دارند، یک پرونده OWNERS در زیرشاخه‌ی زبان مربوطه با کد زیر ایجاد کنید:
بازبین‌ها: فهرستی از تیم‌های کوبرنتیز با نقش‌های بازبین، در این مورد،
برچسب‌ها: فهرستی از برچسب‌های گیت‌هاب که به‌طور خودکار به یک درخواست ادغام اعمال می‌شوند، در این مورد، برچسب زبانی که در Configure the workflow ایجاد شده است.
اطلاعات بیشتر در مورد پرونده OWNERS را می‌توانید در go.k8s.io/owners بیابید.
# برای مشاهده اسناد مربوط به مالکین به نشانی https://go.k8s.io/owners مراجعه کنید.# این پروژه محلی‌سازی زبان اسپانیایی است.# تیم‌ها و اعضا در نشانی https://github.com/orgs/kubernetes/teams قابل مشاهده هستند.reviewers:- sig-docs-es-reviewsapprovers:- sig-docs-es-ownerslabels:- area/localization- language/es
پس از افزودن پرونده OWNERS مختص زبان، پرونده rootOWNERS_ALIASES را با تیم‌های جدید کوبرنتیز برای محلی‌سازی، sig-docs-**-owners و sig-docs-**-reviews به‌روزرسانی کنید.
برای مثالی از افزودن یک محلی‌سازی جدید، به درخواست ادغام برای فعال‌سازی مستندات به زبان فرانسوی مراجعه کنید.
یک پرونده README محلی اضافه کنید
برای راهنمایی سایر مشارکت‌کنندگان محلی‌سازی، یک پرونده جدید README-**.md به بالاترین سطح kubernetes/website اضافه کنید، که در آن ** کد دو حرفی زبان است. برای مثال، یک پرونده README آلمانی به صورت README-de.md خواهد بود.
مشارکت کنندگان بومی سازی را در پرونده «README-**.md» بومی سازی شده راهنمایی کنید. همان اطلاعات موجود در «README.md» و همچنین شامل موارد زیر باشد:
نقطه تماس برای پروژه بومی‌سازی
هرگونه اطلاعات خاص مربوط به محلی‌سازی
پس از ایجاد پرونده README محلی، پیوندی از پرونده اصلی انگلیسی README.md به پرونده اضافه کنید و اطلاعات تماس را به زبان انگلیسی در آن قرار دهید. می‌توانید شناسه گیت‌هاب، نشانی رایانامه، کانال Slack یا روش دیگری برای تماس ارائه دهید. همچنین باید پیوندی به آیین‌نامه رفتار انجمن محلی خود ارائه دهید.
محلی‌سازی جدید خود را راه‌اندازی کنید
وقتی محلی‌سازی الزامات گردش کار و حداقل خروجی را برآورده می‌کند، SIG اسناد موارد زیر را انجام می‌دهد:
اسناد ترجمه شده باید در زیرشاخه content/**/ خود قرار گیرند، اما در غیر این صورت، همان مسیر URL منبع انگلیسی را دنبال کنند. به عنوان مثال، برای تهیه آموزش Kubernetes Basics برای ترجمه به آلمانی، یک زیرشاخه در زیر شاخه content/de/ ایجاد کنید و منبع یا پوشه انگلیسی را رونوشت کنید:
ابزارهای ترجمه می‌توانند فرآیند ترجمه را سرعت بخشند. برای مثال، برخی از ویراستاران افزونه‌هایی را برای ترجمه سریع متن ارائه می‌دهند.
Caution:
ترجمه ماشینی به خودی خود کافی نیست. بومی‌سازی نیازمند بررسی گسترده انسانی است تا حداقل استانداردهای کیفیت را رعایت کند.
برای اطمینان از دقت دستور زبان و معنی، اعضای تیم محلی‌سازی شما باید قبل از انتشار، تمام ترجمه‌های تولید شده توسط ماشین را با دقت بررسی کنند.
بومی سازی تصاویر SVG
پروژه کوبرنتیز توصیه می‌کند در صورت امکان از تصاویر برداری (SVG) استفاده کنید، زیرا ویرایش این تصاویر برای تیم محلی‌سازی بسیار آسان‌تر است. اگر یک تصویر شطرنجی پیدا کردید که نیاز به بومی سازی دارد، ابتدا نسخه انگلیسی را به صورت تصویر برداری مجدد ترسیم کنید و سپس آن را بومی سازی کنید.
هنگام ترجمه متن درون تصاویر SVG (گرافیک برداری مقیاس‌پذیر)، پیروی از دستورالعمل‌های خاص برای اطمینان از دقت و حفظ سازگاری در نسخه‌های مختلف زبان ضروری است. تصاویر SVG معمولاً در مستندات کوبرنتیز برای نشان دادن مفاهیم، گردش‌های کاری و نمودارها استفاده می‌شوند.
شناسایی متن قابل ترجمه: با شناسایی عناصر متنی درون تصویر SVG که نیاز به ترجمه دارند، شروع کنید. این عناصر معمولاً شامل برچسب‌ها، زیرنویس‌ها، حاشیه‌نویسی‌ها یا هر متنی هستند که اطلاعات را منتقل می‌کند.
ویرایش پرونده‌های SVG: پرونده های SVG مبتنی بر XML هستند، به این معنی که می‌توان آنها را با استفاده از یک ویرایشگر متن ویرایش کرد. با این حال، توجه به این نکته مهم است که اکثر تصاویر مستندات در کوبرنتیز از قبل متن را به منحنی تبدیل می‌کنند تا از مشکلات سازگاری فونت جلوگیری شود. در چنین مواردی، توصیه می‌شود از نرم‌افزارهای تخصصی ویرایش SVG مانند Inkscape برای ویرایش استفاده کنید، پرونده SVG را باز کنید و عناصر متنی را که نیاز به ترجمه دارند، پیدا کنید.
ترجمه متن: متن اصلی را با نسخه ترجمه شده به زبان مورد نظر جایگزین کنید. مطمئن شوید که متن ترجمه شده به طور دقیق معنای مورد نظر را منتقل می‌کند و در فضای موجود در تصویر جای می‌گیرد. هنگام کار با زبان‌هایی که از الفبای لاتین استفاده می‌کنند، باید از خانواده فونت Open Sans استفاده شود. می‌توانید فونت Open Sans را از اینجا دریافت کنید: فونت Open Sans.
تبدیل متن به منحنی: همانطور که قبلاً ذکر شد، برای رفع مشکلات سازگاری فونت، توصیه می‌شود متن ترجمه شده را به منحنی یا مسیر تبدیل کنید. تبدیل متن به منحنی تضمین می‌کند که تصویر نهایی متن ترجمه شده را به درستی نمایش می‌دهد، حتی اگر سیستم کاربر فونت دقیق استفاده شده در SVG اصلی را نداشته باشد.
بررسی و آزمایش: پس از انجام ترجمه‌های لازم و تبدیل متن به منحنی، تصویر SVG به‌روزرسانی‌شده را ذخیره و بررسی کنید تا از نمایش و ترازبندی صحیح متن اطمینان حاصل شود. پیش‌نمایش تغییرات محلی را بررسی کنید.
پرونده های منبع
بومی‌سازی‌ها باید بر اساس پرونده های انگلیسی از یک نسخه خاص که توسط تیم بومی‌سازی هدف‌گذاری شده است، انجام شوند. هر تیم بومی‌سازی می‌تواند تصمیم بگیرد که کدام نسخه را هدف قرار دهد، که در زیر به آن نسخه هدف گفته می‌شود.
توضیحات بالای پرونده را متناسب با محلی‌سازی خود اصلاح کنید، سپس مقدار هر رشته را ترجمه کنید. برای مثال، این متن جایگزین به زبان آلمانی برای فرم جستجو است:
[ui_search]
other = "Suchen"
بومی‌سازی رشته‌های سایت به شما امکان می‌دهد متن و ویژگی‌های کل سایت را سفارشی کنید: برای مثال، متن حق نشر قانونی در پاورقی هر صفحه.
راهنمای محلی‌سازی مختص زبان
به عنوان یک تیم محلی‌سازی، می‌توانید با ایجاد یک راهنمای محلی‌سازی مختص هر زبان، بهترین شیوه‌هایی را که تیمتان دنبال می‌کند، رسمی کنید.
واژه‌نامه اصطلاحات بومی‌سازی‌شده و غیربومی‌سازی‌شده
قراردادهای نشانه‌گذاری
اصطلاحات شیء کوبرنتیز API
جلسات زوم مخصوص زبان‌های مختلف
اگر پروژه محلی‌سازی به زمان جلسه جداگانه‌ای نیاز دارد، با یکی از اعضای SIG اسناد یا سرپرست فنی تماس بگیرید تا یک جلسه زوم جدید و دعوتنامه تقویمی ایجاد کنید. این کار فقط زمانی لازم است که تیم به اندازه کافی بزرگ باشد که بتواند از پس آن برآید و به یک جلسه جداگانه نیاز داشته باشد.
طبق سیاست CNCF، تیم‌های محلی‌سازی باید جلسات خود را در لیست پخش یوتیوب SIG اسناد بارگذاری کنند. یکی از روسای مشترک یا سرپرست فنی SIG اسناد می‌تواند تا زمان خودکارسازی این فرآیند توسط SIG اسناد به آنها کمک کند.
راهبرد شاخه
از آنجا که پروژه‌های محلی‌سازی، تلاش‌هایی بسیار مشارکتی هستند، ما تیم‌ها را تشویق می‌کنیم که در شاخه‌های محلی‌سازی مشترک کار کنند - به خصوص هنگام شروع کار و زمانی که محلی‌سازی هنوز فعال نشده است.
برای مثال، یک تأییدکننده در یک تیم محلی‌سازی آلمانی، شاخه محلی‌سازی dev-1.12-de.1 را مستقیماً در مخزن kubernetes/website، بر اساس شاخه منبع برای کوبرنتیز نسخه ۱.۱۲، باز می‌کند.
مشارکت‌کنندگان انفرادی، شاخه‌های ویژگی را بر اساس شاخه محلی‌سازی باز می‌کنند.
برای مثال، یک مشارکت‌کننده آلمانی یک درخواست ادغام با تغییرات در kubernetes:dev-1.12-de.1 از username:local-branch-name باز می‌کند.
تأییدکنندگان، شاخه‌های ویژگی را بررسی و در شاخه محلی‌سازی ادغام می‌کنند.
به صورت دوره‌ای، یک تأییدکننده با باز کردن و تأیید یک درخواست ادغام جدید، شاخه محلی‌سازی را با شاخه منبع خود ادغام می‌کند. قبل از تأیید درخواست ادغام، حتماً commitها را squash کنید.
مراحل ۱ تا ۴ را در صورت نیاز تا زمان تکمیل بومی‌سازی تکرار کنید. برای مثال، شاخه‌های بومی‌سازی بعدی آلمانی عبارتند از: dev-1.12-de.2، dev-1.12-de.3 و غیره.
تیم‌ها باید محتوای بومی‌سازی‌شده را در همان شاخه‌ای که محتوا از آن تهیه شده است، ادغام کنند. برای مثال:
یک شاخه محلی‌سازی که از شاخه اصلی منبع‌گیری شده است، باید در شاخه اصلی ادغام شود.
یک شاخه محلی‌سازی که از release-1.32 منبع‌گیری شده است، باید در release-1.32 ادغام شود.
Note:
اگر شاخه محلی‌سازی شما از شاخه اصلی ایجاد شده باشد، اما قبل از ایجاد شاخه انتشار جدید release-1.33 با اصلی ادغام نشده باشد، آن را هم در اصلی و هم در شاخه انتشار جدید release-1.33 ادغام کنید. برای ادغام شاخه محلی‌سازی خود در شاخه انتشار جدید release-1.33، باید شاخه بالادستی شاخه محلی‌سازی خود را به release-1.33 تغییر دهید.
در ابتدای هر مرحله از مراحل پیشرفت تیم، باز کردن یک مسئله برای مقایسه تغییرات بالادستی بین شاخه محلی‌سازی قبلی و شاخه محلی‌سازی فعلی مفید است. دو اسکریپت برای مقایسه تغییرات بالادستی وجود دارد.
upstream_changes.py برای بررسی تغییرات اعمال شده در یک پرونده خاص مفید است. و
diff_l10n_branches.py برای ایجاد لیستی از پرونده های منسوخ شده برای یک شاخه محلی‌سازی خاص مفید است.
در حالی که فقط تأییدکنندگان می‌توانند یک شاخه محلی‌سازی جدید باز کنند و درخواست‌های ادغام را ادغام کنند، هر کسی می‌تواند یک درخواست ادغام برای یک شاخه محلی‌سازی جدید باز کند. هیچ مجوز خاصی لازم نیست.
برای اطلاعات بیشتر در مورد کار از طریق Forkها یا مستقیماً از مخزن، به "مخزن را fork و clone کنید" مراجعه کنید.
مشارکت‌های بالادستی
SIG اسناد از مشارکت‌ها و اصلاحات بالادستی در منبع انگلیسی استقبال می‌کند.
