Skip to content

Commit f7cdcb3

Browse files
committed
Init Persian localization - Part 27
1 parent c17e741 commit f7cdcb3

File tree

8 files changed

+1055
-0
lines changed

8 files changed

+1055
-0
lines changed
Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
title: کمک به‌عنوان همراه نگارش وبلاگ
3+
slug: writing-buddy
4+
content_type: concept
5+
weight: 70
6+
---
7+
8+
<!-- overview -->
9+
10+
دو وبلاگ رسمی Kubernetes وجود دارد و بنیاد CNCF نیز وبلاگ خودش را دارد که در آن می‌توانید دربارهٔ Kubernetes بنویسید. برای آشنایی با این دو وبلاگ، [مشارکت در وبلاگ‌های Kubernetes](/docs/contribute/blog/) را بخوانید.
11+
12+
وقتی افراد به‌عنوان نویسنده در هر یک از این وبلاگ‌ها مشارکت می‌کنند، پروژهٔ Kubernetes نویسندگان را به‌عنوان _همراه نگارش_ جفت می‌کند. این صفحه توضیح می‌دهد که چگونه این نقش را انجام دهید.
13+
14+
قبل از ادامهٔ مطالعهٔ این صفحه، اطمینان حاصل کنید که دست‌کم خلاصهٔ [ارسال مقاله](/docs/contribute/blog/submission/) را خوانده‌اید.
15+
16+
<!-- body -->
17+
18+
## مسئولیت‌های همراه نگارش
19+
20+
به‌عنوان یک همراه نگارش، شما:
21+
22+
* به تیم وبلاگ کمک می‌کنید تا مقالات آمادهٔ ادغام و انتشار شوند
23+
* از همراه خود پشتیبانی می‌کنید تا محتوایی قابل ادغام تولید کند
24+
* یک بازبینی بر مقاله‌ای که همراه‌تان نوشته است ارائه می‌دهید
25+
26+
وقتی تیم شما را با نویسندهٔ دیگری جفت می‌کند، ایده این است که هر دو با بازبینی پیش‌نویس مقالهٔ یکدیگر از هم پشتیبانی کنید. بیشتر خوانندگان وبلاگ Kubernetes متخصص نیستند؛ محتوا باید برای آن مخاطب قابل درک باشد، یا دست‌کم از خوانندگان غیرمتخصص به‌درستی پشتیبانی کند.
27+
28+
تیم وبلاگ نیز در مسیر پیش‌نویس تا انتشار به هر دوی شما کمک می‌کند. آن‌ها یا مستقیماً می‌توانند مقالهٔ شما را برای انتشار تأیید کنند، یا ترتیبی می‌دهند تا تأیید انجام شود.
29+
30+
## پشتیبانی از تیم وبلاگ
31+
32+
مسئولیت اصلی شما این است که دربارهٔ ظرفیت، در دسترس بودن و پیشرفت خود در یک بازهٔ زمانی معقول اطلاع‌رسانی کنید. اگر هفته‌ها بگذرد و همراه شما خبری از شما نداشته باشد، کل کار زمان بیشتری می‌برد.
33+
34+
## پشتیبانی از همراه خود
35+
36+
این فرایند دو بخش دارد
37+
38+
{{< tabs name="buddy_support" >}}
39+
{{% tab name="ویرایش مشارکتی" %}}
40+
**(این گزینهٔ پیشنهادی است)**
41+
42+
تیم وبلاگ پیشنهاد می‌کند که نویسندهٔ اصلی برای مقاله، ویرایش مشارکتی را با استفاده از Google Doc یا HackMD (به انتخاب خودش) راه‌اندازی کند. سپس نویسندهٔ اصلی آن سند را با افراد زیر به‌اشتراک می‌گذارد:
43+
44+
* هر نویسندهٔ همکار
45+
* شما (همراه نگارش)
46+
* ترجیحاً یک نفر از تیم وبلاگ
47+
48+
به‌عنوان همراه نگارش، پیش‌نویس متن را می‌خوانید و یا مستقیماً پیشنهاد اعمال می‌کنید یا به شیوهٔ دیگری بازخورد می‌دهید. نویسندهٔ وبلاگ معمولاً **همراه نگارش شما** نیز هست، بنابراین آن‌ها همان نوع بازخورد را بر پیش‌نویس مقالهٔ وبلاگ شما ارائه می‌دهند.
49+
50+
نقش شما این است که کمترین مجموعهٔ تغییرات لازم را پیشنهاد دهید تا مقاله برای انتشار خوب به‌نظر برسد. اگر نموداری واقعاً نامفهوم است یا متن واقعاً نامشخص است: بازخورد بدهید. اگر فقط اختلاف جزئی دربارهٔ واژه‌گزینی یا نقطه‌گذاری دارید، از آن صرف‌نظر کنید. بگذارید نویسنده(ها) در سبک خودشان بنویسند، به شرطی که با [راهنمای وبلاگ](/docs/contribute/blog/guidelines/) هم‌خوان باشند.
51+
52+
پس از آماده شدن پیش‌نویس، نویسندهٔ اصلی یک Pull Request باز می‌کند و مقاله را با Markdown ارسال می‌نماید. سپس شما یک [بازبینی](#pull-request-review) ارائه می‌دهید.
53+
{{% /tab %}}
54+
{{% tab name="ویرایش Markdown / Git" %}}
55+
برخی نویسندگان ترجیح می‌دهند با
56+
[ویرایش مشارکتی](#buddy-support-0) شروع کنند؛ برخی دیگر دوست دارند مستقیم وارد GitHub شوند.
57+
58+
هر مسیری که انتخاب کنند، نقش شما ارائهٔ بازخوردی است که به تیم وبلاگ اجازه دهد تأیید ساده‌ای انجام دهد و مقاله به‌عنوان پیش‌نویس ادغام شود. آنچه نویسندگان باید انجام دهند را در
59+
[ارسال مقاله به وبلاگ‌های Kubernetes](/docs/contribute/blog/submission/) ببینید.
60+
61+
برای اشاره به تغییرات لازم، از پیشنهادهای GitHub استفاده کنید.
62+
63+
وقتی Markdown و سایر محتوا (مانند تصاویر) درست به‌نظر می‌رسد، یک
64+
[بازبینی](#pull-request-review) رسمی ارائه می‌دهید.
65+
{{% /tab %}}
66+
{{< /tabs >}}
67+
68+
## بازبینی Pull Request
69+
70+
بخش [وبلاگ](/docs/contribute/review/reviewing-prs/#blog) از _بازبینی Pull Requestها_ را دنبال کنید.
71+
72+
وقتی فکر می‌کنید Pull Request وبلاگ باز شده به‌اندازهٔ کافی خوب است که ادغام شود، نظر `/lgtm` را در Pull Request اضافه کنید.
73+
74+
این فرمان به ابزار اتوماسیون مخزن (Prow) نشان می‌دهد که محتوا «از نظر من خوب به‌نظر می‌رسد». Prow کارها را پیش می‌برد. دستور `/lgtm` به شما اجازه می‌دهد صرف‌نظر از این‌که رسماً عضو پروژهٔ Kubernetes هستید یا نه، نظر خود را ثبت کنید.
75+
76+
یا شما یا نویسنده(ها) باید به تیم وبلاگ اطلاع دهید که مقاله‌ای برای تأیید نهایی آماده است. همان‌گونه که در راهنمای ارسال توضیح داده شده، باید از قبل در front matter با `draft: true` علامت‌گذاری شده باشد.
77+
78+
## مراحل بعدی
79+
80+
برای شما به‌عنوان همراه نگارش، **مرحلهٔ چهارمی وجود ندارد**. وقتی Pull Request آمادهٔ ادغام بود، تیم وبلاگ (یا برای سایت Contributors، تیم ارتباطات مشارکت‌کنندگان) از آنجا به بعد را مدیریت می‌کند. ممکن است لازم باشد بر اساس بازخورد به مرحلهٔ قبلی برگردید، اما معمولاً می‌توانید انتظار داشته باشید که کار شما به‌عنوان همراه نگارش تمام شده است.

0 commit comments

Comments
 (0)