DawoumWiki:Guidelines

수학(Mathematics, Math, Wikipedia)과 관련된 문서와 번역 문서 및 미디어 등은, 별도의 협의가 없는 한, 작성자가 전적인 권리를 가집니다. 이 문서나 미디어를 이용하기 위해서는, 작성자(작성자 그룹 등)의 허락을 반드시 받아야 합니다.

이 작성 지침은 다움 위키에서 컨텐츠를 추가, 편집 및 제거하기 위한 일련의 제안입니다. 위키 마크업을 이용한 서식 지정 텍스트(섹션 제목, 목록 등)와 새 지면 만드는 방법에 대한 더 많은 기본적인 정보를 다른 곳에서 찾을 수 있습니다.

위키 지면 작성에 대한 지침 (또는 스타일 지침)이 필요한 이유는 여러 가지가 있습니다.

무엇보다도 먼저, 위키에 있는 모든 기사의 일관된 모양과 느낌을 만들어, 이해하기 쉽고 보다 전문적인 지식 표현을 제공합니다. 위키 작성 지침은 모든 편집자가 동일한 지침과 스타일을 사용함으로 인해 기사 전반에 걸쳐 더 나은 공동작업을 가능하게 합니다.

다음으로, 지면 작성자가 변수 이름을 <code>에서 <tt>로 전환하는 등의 기사 레이아웃을 지속적으로 변경할 가능성을 줄입니다. 이러한 변경으로 인해 지면의 콘텐츠를 감시하려는 사람들(위키 주시 목록을 통해)이 너무 자주 트리거되어 체계적인 방식으로 변경 사항을 추적하기 어렵게 합니다. 또한 기사의 품질에 별다른 이득을 주지 않으면서 인프라에 불필요한 스트레스를 증가시킵니다.

마지막으로, 기여자가 쉽게 위키 지면 작성에 익숙해 지도록 도와줍니다. 작성 지침으로 인해 나쁜 편집을 하는 것에 대한 두려움을 낮추고 수용 가능한 편집에 대한 논의를 가능하게 합니다.

이 문서는, 편집자가 이 위키를 편집할 때 규칙과 지침을 이해하기가 너무 어려워지거나, 어렵다고 느낀 경우 기여도가 감소할 수 있기 때문에, 완전히 철저하지는 않습니다. 편집을 두려워하지 말고, (의도하지 않지만) 나쁜 편집에 대한 걱정할 필요가 없습니다. 왜냐하면 우리는 편집 지침의 표준까지 조정할 수 있는 많은 편집자를 보유하고 있습니다. 최고의 편집자조차도 나쁜 편집을 합니다. 기억하십시오: wiki는 공동 작업입니다!

Writing style

위키 기사의 글쓰기 스타일은 글 자체를 작성하는 방법을 설명합니다. 즉, 기사의 언어적인 측면을 다룹니다.

Avoid first person

위키는 커뮤니티 활동이며 콘텐츠 지면은 정보이므로 "나" 또는 "우리"에 대한 언급이 없어야 합니다. 기사는 제 3자의 입장에서 작성해야 하며: 사실을 근거로 작성해야 합니다.

제 3자의 입장과 수동적 목소리가 선호됩니다; 왜냐하면, 이런 입장이 더 전문적이고 객관적으로 들리기 때문입니다. 사용자는 적절한 경우 "여러분"("제 2자 작성"이라고 함)으로 언급될 수 있지만, 그렇게 하는 것은 바람직하지 않습니다. 예를 들어, "여러분은 지금 패키지를 설치해야 합니다"대신 "다음을 사용하여 패키지를 설치하십시오"를 사용하십시오. 마찬가지로 "여러분은 클라이언트 소프트웨어만 설치하도록 선택할 수 있습니다"라는 말은 "클라이언트 소프트웨어만 설치 가능합니다"라고 쓰는 것이 좋습니다.

Use lead-in sentences

어떤 작업을 하기 전에 리드-인 문장 또는 토픽 문장을 작성하십시오. 이것은 액션 지향적인 부분을 향한 텍스트의 좋은 흐름을 만듭니다.

예를 들어, 패키지를 설치하는 것에 대한 정보를 사용자들에게 알려주기 위해서 Apt 상자를 바로 사용하는 대신에 "시스템에 소프트웨어 설치:"와 같은 간단한 문장을 작성하십시오.

표준말 사용하기

한글은 각 지방마다 사용하는 어투가 다릅니다. 이로 인해 문장의 의미가 제대로 전달되지 못하는 경우가 발생하기 때문에 반드시 표준말을 이용해서 문장을 작성해 주시기 바랍니다. 또한, 기타 커뮤니티나 그룹에서 사용되는 어투도 사용하지 않아야 합니다. 커뮤니티나 그룹 어투는 전달하려는 내용이 커뮤니티의 성격을 반영한다고 오해할 소지가 있기 때문에 사용해서는 안됩니다.

Formatting

아래의 형식 원칙을 최대한 준수하도록 노력하십시오.

Inline layout elements

인-라인 레이아웃 요소는 문장 내의 글씨에 여러가지 효과를 렌더링됩니다. 다음 섹션에서 논의 할 블록-레벨 레이아웃 요소와 달리 텍스트의 흐름을 방해하지 않습니다. 이 표는 가장 일반적인 요소와 사용 사례를 보여줍니다.

입력	렌더링 출력	사용 목적	문장 내 예시
''italics''	italics	무언가를 강조하기 위한 것.	구성 항목의 순서는 변경 불가입니다.
'''bold'''	bold	독자가 알아야 할 것이 매우 중요할 때, 무엇인가를 강하게 강조하기 위한 것. (아래의 "Warning" 블록-수준 요소를 참조하십시오.)	하이픈을 사용하는 것이 절대적으로 필요합니다. 그렇지 않으면 시스템이 기동되지 않습니다.
<var>foo</var>	foo	in-paragraph 변수 이름에 사용됩니다 (예를 들어 USE, FEATURES, 또는 CFLAGS 등).	오디오 지원이 필요한 경우 USE 변수를 alsa로 설정하십시오.
<code>foo</code>	foo	다음의 경우에 사용하십시요: In-paragraph 변수 값 (예를 들어 -alsa, USE 변수에 설정할 값을 참조하는 경우). 인-라인(in-line)으로 표시되는 코드의 작은 부분. 명령에 대한 인수 또는 선택사항 (설명 단락 내부 - 만약 사용자가 실제로 입력하는 데 사용되는 경우에는 <kbd> ... </kbd>).	이제 USE 변수를 -alsa로 설정하여 ALSA 지원을 비활성화하십시오.
<kbd>user input</kbd>	user input	프롬프트에서 명령이나 답변에 대한 사용자 입력에 사용되지만, 다음과 같은 제약 조건이 있습니다: 입력이 키 누름 또는 키 조합일 때, {{Key}} 템플리트를 사용하십시오(다음에 설명). "Cmd" 또는 "RootCmd"와 같은 블록 레벨 요소를 사용하여 입력을 그림처럼 표현하고 싶을 때, {{c}} 템플릿을 사용하십시오. 기억해야 할 것은, <kbd> 태그는 고-대비 요소를 주기때문에 과도하게 사용하면 가독성을 저해할 수 있다는 점입니다.	gpg --fingerprint로 지문을 나열하십시요.
{{Key|Alt}}+{{Key|F1}}	Alt+F1	사용자가 입력해야 하는 키 조합으로, 대부분의 경우 프롬프트에 응답하거나 또는 응용 프로그램 환경에서 특수 키 조합을 상술할 때 사용됩니다. 이것은 {{Key}} 템플릿으로 구현되어 집니다.	Alt+F1를 사용하여 첫번째 터미널로 다시 이동하십시요.

Block-level layout elements

이 요소들은 모두 템플릿을 사용하여 구현되며 블록 수준에서 렌더링됩니다. 즉, 문장의 끝에서 줄 바꿈을 하고 "상자"안에 표시됩니다. 일반적으로 더 많은 콘텐츠가 필요하며 위에서 언급 한 인-라인 템플릿 요소를 사용하는 것보다 더 복잡한 형식으로 렌더링됩니다. 다음 표에는 이 위키에서 사용할 수 있는 일반적인 블록-수준 템플릿과 해당 사용 사례가 자세히 설명되어 있습니다.

템플릿 이름에 연결된 링크는 템플릿 사용에 대한 추가 정보를 얻을 수 있습니다. (Help:Templates 및 템플릿 전체 목록을 참고하십시오.)

템플릿	사용 목적	예시
{{MwNote}}	그 앞에 있는 문장 또는 블록 요소에서 분리해야 하는 (또는 절대로 포함할 수 없는) 추가적인 정보를 표시합니다.	multislot USE 플래그와 함께 Grub이 설치되었다면 Grub-install 대신에 Grub2-install을 사용하십시요.
{{MwCaution}}	특별한 주의를 기울일 만한 항목을 강조하기 위한 경우: 일반적인 inline 강조보다 독자에게 더 강한 신호를 줍니다.	ZFS는 이것을 하는 것이 확실한지 묻지 않을 것입니다.
{{MwWarning}}	독자가 정말로 특별한 주의를 기울일 필요가 있을 때에, 예를 들어 시스템을 손상할 수 있는 경우 등을 강하게 강조하십시오.	이 작업을 수행 할 때 발생할 수 있는 보안상의 영향을 고려하십시오!

Use of newlines

섹션 머리글 위와 아래에 빈 줄이 반드시 있어야 하며 모든 단락-끊기 (인라인 아님) 템플릿 주위에도 빈 줄이 있어야 합니다. 이렇게 하면 (위키 구문) 편집자가 쉽게 읽을 수 있고 커뮤니티에 의한 번역 작업을 단순화하는 효과가 있습니다.

문단을 짧게 유지하십시오; 일반적으로 1~5개의 문장으로 충분해야 합니다. 위의 문장에서 언급했듯이, 이것도 기사를 읽기 쉽게 만들고 커뮤니티에 의한 번역 작업을 단순화하는 효과가 있습니다.

Linking

대다수의 대형 인터넷 회사처럼 다움 위키도 HTTPS로 전환을 했습니다. 가능하다면, 외부 링크에 HTTP 대신에 HTTPS를 사용하십시오. 문서화도 가능한한 안전과 보안에 신경을 쓰야 합니다.

기사 작성자는 다른 기사 또는 리소스 (또는 큰 기사에서는 주요 섹션당 한 번)에 한 번만 링크해야 합니다. 자세한 내용은 스타일 설명서에 있는 Wikipedia의 반복 링크 섹션을 참고하십시오.

Avoid URL shortening

위키에서 URL 단축 링크를 사용하지 마십시오. 다음 2가지 이유로 피해야 합니다:

1. 사용자는 링크 대상이 무엇인지 확인할 수 없습니다. 부적절한 사이트이거나 방문하고 싶지 않은 다른 장소일 수 있습니다.
2. 해당 링크가 추적 목적으로 사용될 수 있습니다. 사용자가 실제로 대상 서버로 이동하기로 결정하지 않는 한 이런 일이 발생하지 않아야 합니다(요청을 가로챌 제 3자도 없어야 합니다).

Article structure

이 섹션에서는 어떤 유형과 목적에 따라 특정 기사의 구조를 설명합니다.

새로운 기사 작성을 돕기 위해 기사 청사진이 작성되었습니다. 이들은 다양한 유형의 기사에 대한 사전 정의된 구조를 제공합니다; 새로운 구조를 추가하는 것보다 구조를 제거하는 것이 더 쉽습니다. 또한 다움 위키 기사를 일관되게 유지하는데도 도움이 됩니다. 기사 청사진에 콘텐츠를 추가할 때 아래 규칙을 따르십시오.

Titles and section headings

기사의 제목은 짧고, 구체적이며 모호하지 않아야 합니다. 제목 전체를 대문자로 사용하는 것은 가능한한 피해야 합니다.

기사 내의 제목("섹션 제목"으로 불리우는)은 대문자로 시작해야 하지만 나머지 섹션 제목은 소문자를 사용해야 합니다(적절한 명사는 예외입니다). 이것은 문장의 경우라고 불리워 집니다.

섹션 제목은 레벨 2이상(3, 4, ...)이어야 합니다. 레벨 1 제목은 기사 자체의 제목에만 사용되며, 기사를 만들 때 자동으로 만들어집니다. 그러므로 레벨 1 표제는 위키 공헌자가 기사 본문에 정의할 이유가 없습니다.

섹션 제목에 링크 및 HTML 서식을 사용하면 안됩니다.

Start of an article

위키 기사는 제목이 없는 간단한 소개 단락으로 시작해야 합니다.

소개 또는 개요와 같은 제목은 사용하지 않는 것이 좋습니다. 운영적인 내용을 기술하기 전에 (예를 들어, 설치 지침, 구성 지침, 패키지 관리 작업 등) 개념적 지식이 필요한 기사의 경우에는 이 개념에 따라 섹션의 이름을 지정하십시오.

Documenting a package or software title

패키지 또는 소프트웨어 이름이 문서화될 때, 기사의 시작 부분에 InfoBox를 추가하십시오. 여기에는 로고, 스크린샷, 버전 정보, 프로젝트 홈페이지, 등을 요약됩니다:

{{Infobox software
| logo         =
| screenshot   =
| latest release version =
| latest release date =
| website =
}}

소프트웨어 이름이나 패키지에 대한 개념적 정보가 필요한 경우에는 기사의 첫 번째 섹션의 이름을 올바르게 지정해야 합니다(설명된 개념 뒤에 - 소개 또는 개념과 같은 일반적인 이름을 사용하지 마십시오).

다음으로, 소프트웨어 이름이나 패키지 설정에 관한 섹션을 추가해야 합니다. 이 섹션에는 USE 플래그(젠투인 경우), 설치 지침 등에 대한 정보가 포함해야 합니다.

다음으로, 소프트웨어 이름이나 패키지의 운영 측면에 대한 하나 이상의 섹션을 추가해야 합니다. 이 섹션에 사용-측면에서 구성하여, 전체 작업이 하위 섹션에 포함되도록 하십시오. "부트 항목 나열" 또는 "암호화 키 삭제"는 하위 섹션의 좋은 예이며, 주요 섹션은 "부트 항목 조작" 또는 "cryptsetup으로 볼륨 암호화"라고 부를 수 있습니다.

마지막으로, 소프트웨어 이름이나 패키지에 대한 더 자세한 자료를 첨부하십시오.

References and links

기사 끝에, 리소스를 추가하실 때에는, 다음의 항목들로 분류해서 추가하는 것이 좋습니다:

• "See also"는 위키의 기사, 안내, 하우투 및 컨셉 안내에 대한 링크로 사용됩니다.
• "External resources"는 다움 위키 외부의 정보와 안내를 위해 사용됩니다. 이것들은 독자가 주제에 대해 더 자세히 읽어야 할 것들입니다.
• "References"는 자료의 원천 참조에만 사용됩니다. 이 섹션은 위키가 기사에서 사용된 참조 목록을 자동으로 생성하도록 {{reflist}}만 포함시켜야 합니다.

See also 및 External resources 섹션의 경우에는, 사용자에게 이 리소스가 현재 흥미로운 이유 또는 현재 기사와 관련이 있는 이유를 사용자에게 알려주십시오.

References 섹션은 기사-내부 참조용으로만 사용됩니다. 기사가 외부 자원의 정보를 "사실" 또는 소스 정보로 사용하여 기사 내에서 추가 주장을 제기할 때마다 <ref> 태그를 사용해야 합니다. External resources 와 References에는 다음과 같은 미묘한 차이가 있습니다:

• external resource는 사용자가 기사 내에서 사용된 단일 소유권 주장을 넘어서는 주제에 대해 더 많은 정보를 찾을 수 있는 위치입니다
• reference는 사용자가 기사 내에서 만들어진 특정 주장이나 진술에 대해 더 많은 정보(또는 증명)를 찾을 수 있는 위치입니다

reference를 사용할 때, 다음에 주어진 순서대로 정보를 사용하십시오(그 정보가 알려져 있을 경우):

1. 소스의 저자
2. 소스의 제목 (하이퍼링크로 사용)
3. 소스의 주 기원, 메인 싸이트처럼 (하이퍼링크 사용)
4. 간행 날짜
5. 이 정보의 확인 날짜

다음은 예제입니다:

Users should replace <code>-march=native</code> with the various compiler flags that GCC finds for the native
system by using <kbd>gcc -march=native -x -c -</kbd><ref>Michał Górny.
[http://blogs.gentoo.org/mgorny/2014/06/23/inlining-marchnative-for-distcc/ Inlining -march=native for distcc],
[http://blogs.gentoo.org/mgorny/ Michał Górny blog], June 23rd, 2014. Retrieved on January 1st, 2015.</ref> and
use those flags in their <var>CFLAGS</var> and <var>CXXFLAGS</var> variables.