Skip to content

Commit e24cf63

Browse files
committed
fix: some markdown style
1 parent 6a427aa commit e24cf63

File tree

3 files changed

+7
-7
lines changed

3 files changed

+7
-7
lines changed

src/community/join.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88

99
### 行動規範
1010

11-
私達の[行動規範は](/coc)は、私達と参加する技術コミュニティ全体を豊かにするためのガイドです。
11+
私達の[行動規範](/coc)は、私達と参加する技術コミュニティ全体を豊かにするためのガイドです。
1212

1313
### サポートを得る
1414

src/guide/contributing/doc-style-guide.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
## アラート
66

7-
VuePress は、アラートボックスを作成するためのカスタムコンテナプラグインを提供します。 4 つのタイプがあります:
7+
VuePress は、アラートボックスを作成するためのカスタムコンテナプラグインを提供します。4 つのタイプがあります:
88

99
- **Info**: 中立的な情報を提供する
1010
- **Tip**: ポジティブで奨励する情報を提供する

src/guide/contributing/writing-guide.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,13 +5,13 @@
55
## 原則
66

77
- **機能は十分に文書化されていないと存在しません。**
8-
- **ユーザの認知能力(例えば、頭脳)を尊重する。**ユーザが読書を始めるときには、ある程度の限られた頭脳で始めます、そして彼らがそれを使い果たした時、学ぶのをやめます、
8+
- **ユーザの認知能力(例えば、頭脳)を尊重する。** ユーザが読書を始めるときには、ある程度の限られた頭脳で始めます、そして彼らがそれを使い果たした時、学ぶのをやめます、
99
- 認知能力は、複雑な文章、一度に複数の概念を学ばなければならないこと、そしてユーザの仕事に直接関係のない抽象的な例によって、**より早く枯渇します**
1010
- 認知能力は、ユーザが一貫して賢く、力強く、好奇心旺盛であると感じさせるように支援すると、**よりゆっくりと枯渇していきます**。物事を消化しやすい断片に分解し、文書の流れに注意を払うことは、この状態を維持するのに役立ちます。
11-
- **常にユーザの立場に立って見ることを心がけましょう。**私たちは何かを徹底的に理解すると、それが当たり前になってきます。これは _知識の呪い__the curse of knowledge_)と呼ばれています。良いドキュメントを書くためには、「この概念を学ぶときに最初に何を知る必要があったか?」を思い出すよう努力しましょう。どんな専門用語を学ぶ必要がありましたか?何を誤解していたでしょうか?理解するのに時間がかかったものは何ですか?優れたドキュメントは、ユーザが読んでいる部分で概念を理解することができます。事前にその概念を実際に人に説明する練習をしておくと良いでしょう、
12-
- **最初に _問題_ を説明し、次に解決策を説明します。**機能がどのように動作するかを示す前に、なぜその機能が存在するのかを説明することが重要です。そうしないと、その情報がユーザにとって重要なものなのか(自分が経験した問題なのか)、あるいは、それをどのような予備知識、経験と結びつけるのかを知るためのコンテキストを把握することができません。
13-
- **書いている間は、質問することを恐れないようにしましょう。**相手が "間抜け" であるかもしれないと怖がっている場合は特に、弱みがあるのは辛いことですが、質問することが説明する必要があることを完璧に理解するための唯一方法です、
14-
- **機能の議論に参加しましょう。**最高の API は、後で説明する方法を考えようとするのではなく、説明しやすい機能を構築するという、ドキュメントドリブンの開発から生まれます。質問(特に、「間抜けな」質問)を早い段階ですることで、互換性のない修正を行う必要が出てくる前に、混乱や矛盾、問題のある動作を明らかにすることができます。
11+
- **常にユーザの立場に立って見ることを心がけましょう。** 私たちは何かを徹底的に理解すると、それが当たり前になってきます。これは _知識の呪い__the curse of knowledge_)と呼ばれています。良いドキュメントを書くためには、「この概念を学ぶときに最初に何を知る必要があったか?」を思い出すよう努力しましょう。どんな専門用語を学ぶ必要がありましたか?何を誤解していたでしょうか?理解するのに時間がかかったものは何ですか?優れたドキュメントは、ユーザが読んでいる部分で概念を理解することができます。事前にその概念を実際に人に説明する練習をしておくと良いでしょう、
12+
- **最初に _問題_ を説明し、次に解決策を説明します。** 機能がどのように動作するかを示す前に、なぜその機能が存在するのかを説明することが重要です。そうしないと、その情報がユーザにとって重要なものなのか(自分が経験した問題なのか)、あるいは、それをどのような予備知識、経験と結びつけるのかを知るためのコンテキストを把握することができません。
13+
- **書いている間は、質問することを恐れないようにしましょう。** 相手が "間抜け" であるかもしれないと怖がっている場合は特に、弱みがあるのは辛いことですが、質問することが説明する必要があることを完璧に理解するための唯一方法です、
14+
- **機能の議論に参加しましょう。** 最高の API は、後で説明する方法を考えようとするのではなく、説明しやすい機能を構築するという、ドキュメントドリブンの開発から生まれます。質問(特に、「間抜けな」質問)を早い段階ですることで、互換性のない修正を行う必要が出てくる前に、混乱や矛盾、問題のある動作を明らかにすることができます。
1515

1616
## ドキュメントの構成
1717

0 commit comments

Comments
 (0)