▲ 한글 뉴스그룹 생성 토론요청(RFD)작성법

[Ahn Byong-Gil]

이 글은 news.groups 에 정기적으로 투고되는 "How to Format and Submit a
New Group Proposal" 를 저자의 허락을 얻어 한글 그룹에 맞게 번역한
것입니다. 이 문서와 han.answers에 정기적으로 투고되는 "한글 뉴스그룹
생성 절차", "▲ 설득력 있는 제안(RFD)을 작성하는 방법", "▲ 유즈넷
뉴스그룹 이름에 대한 지침" 을 같이 참고 하시기 바랍니다.

저 자: Russ Allbery <r...@stanford.edu>
번역자: 안병길 <sanc...@softhome.net>
버 전: 1.22A

*************************************
뉴스그룹 생성 토론요청(RFD)작성법
*************************************

이 문서는 한글 뉴스그룹 han.* 계층에서의 그룹 생성 또는 재구성을 위한
제안을 준비하는 사람들을 위해 작성되었다. 제안의 첫 번째 단계는
"han.announce" 와 "han.news.groups" 그룹에 토론요청(RFD)을 제출하는
것이다. 이 문서는 그 양식에 대해 설명한다.

이 표준 양식의 목적은 뉴스그룹 생성과정에서 많은 부분을 차지하는 RFD의
자동화를 이룩하고 그럼으로써 더 정확하고 더 효율적으로 그룹 생성 과정을
진행할 수 있으며 또한 제안자가 중요한 모든 정보를 빠뜨리지 않도록 하기
위한 것이다.

이 문서는 (1) RFD 양식 설명, (2) RFD Template, (3) 양식에대한 대부분을
설명하는 Sample RFD의 세 단원으로 구성되어있다. RFD Template부터 읽어도
쉽게 이해할 수 있을 것이다. 그러나 RFD Template부터 읽는 것이 어렵다고
느껴지거나 RFD Template의 설명을 더 잘 이해하기를 원한다면 나머지 두
단원이 도움이 될 것이다.

☞ 주(註): RFD Template부터 읽기를 권합니다.

----------------------------------------------------------------------
RFD 양식 설명
----------------------------------------------------------------------

han.news.groups에 투고될 기사는 헤더(header), 요약 그리고 본문 3부분으로
구성되어 있다:

I. 헤더

헤더는 유즈넷 기사에 대한 표준을 따른다. 제안의 제출자로서 당신에게
요구되는 것은 From:header, Subject: header, 그리고 Newsgroups: header를
제공하는 것이다. (실제 제안제출 과정에 관한 자세한 것은 아래를 참조하라)

일자: 일자는 기사가 투고된 시간과 날짜를 보여준다. 진행 과정에서의 시간
계산은 이것을 기준으로 한다. 제안에 대한 CFV(투표요청)은 첫번째 RFD가
투고된 날로부터 최소한 21일이 지나고 가장 최근의 RFD로 부터 10일이
지나기 전까지는 미리 제출할 수 없다.

가장 최근의 RFD가 제출된 이후로 2달 이상이 경과 됐으면 투표로 진행하기
전에 RFD를 다시 제출해야 한다.

Message-ID: Message-ID는 네트웍상의 기사에 대한 유일한 구분자이다;
Message-ID가 동일한 기사는 있을 수 없으므로 특정 기사를 가리키기
위해 Message-ID를 이용할 수 있다.

Followup-To: 댓글을 제한할 뉴스그룹(일반적으로 han.news.groups이지만
밀접하게 영향을 받는 그룹의 독자들이 원한다면 그 그룹에 교차투고 할 수
있다)

Approved: Approved 는 누가 그 기사를 han.announce에 중재 했는지를
보여준다. 만약 그 기사가 다른 중재그룹에 교차투고 되었다면 그 그룹
중재자들의 주소가 나열될지도 모른다.

☞ 주(註): 제안자는 뉴스리더(Outlook Express, Netscape등)에서
Followup-To(댓글 제한)을 하는 방법만 아시면 되고 헤더의 의미는 몰라도
관계없습니다.

II. 요약

RFD의 첫 부분은 요약이고 그것은 다음의 머릿글로 시작한다.

REQUEST FOR DISCUSSION (RFD)

머릿글 다음 라인에 제안 그룹 목록을 적는다. 첫 라인은 항상 위와 같은
머릿글로 시작해야 하며, 이는 개정된 RFD의 재 투고 일지라도 마찬가지이다.

그룹 목록은 중간 정렬 해야 하며 빈라인이 없어야 한다. 제안된 그룹은 다음
형식 중 어느 한가지 내에 속해야 한다.

unmoderated group foo.bar

foo.bar로 명명된 새로운 비 중재그룹 생성을 제안하는 것이다. 만약
생성하고자 하는 그룹이 중재그룹이라면 unmoderated 를 moderated로
대체하라.

unmoderated group foo.bar (renames foo.baz)

foo.baz 를 foo,bar로 이름을 변경하는 제안을 하는 것이다. 만약
변경된 그룹이 중재그룹이라면 unmoderated 를 moderated로
대체하라.

moderated group foo.bar (moderates existing group)

비 중재그룹에서 중재그룹으로 foo.bar의 관리상태를 변경하는
제안이다.

unmoderated group foo.bar (unmoderates existing group)

중재그룹에서 비중재 그룹으로 foo.bar의 관리상태를 변경하는
제안이다.

REMOVE foo.bar (renamed to foo.baz)

foo.bar의 삭제를 제안하는 것이다. 그룹 삭제는 삭제되는 그룹의
이름을 이미 존재하는 그룹의 이름으로 변경함으로써
이루어진다(이는 현재 삭제되는 그룹으로 투고되는 기사가 변경된
그룹으로 투고돼야한다는 것을 의미한다)

III. 본문

0. 일반적 형식에 대한 설명

문단은 왼쪽 정렬되어야 하며 라인은 70컬럼이어야한다. 줄바꿈을 60컬럼보다
적게 잡거나 70컬럼과 60컬럼을 혼합해서 사용하지 마라.

이 문서에 사용된 형식과 같이 문단은 들여쓰기해서는 안되고 빈줄에 의해
분리돼서도 안된다.

제안자 또는 중재자를 나열할 때와 같이 이메일 주소가 필요 할 경우 주소는
각 괄호(<>)로 들러 싸야 한다.

1. 반복되는 RFD에 대한 변경 사항 기술

이번 RFD가 같은 제안에 대한 두번째 이후의 RFD라면, "CHANGES from
previous RFD" 로 시작하는 부분이 여기에 기술 돼야 하고 이전 RFD에서
변경된 모든것을 나열해야 한다. RFD에 주목할만한 변경이 있거나 이전 RFD
이후로 두달 이상이 경과되었을 경우에만 새로운 RFD를 투고해야 한다.
주목할 만한 변경에는 제안된 그룹 이름의 변경, 관리상태의 변경 또는
헌장의 중요한 변경이 있다. 사소한 이유(rationale) 변경 또는 사소한 헌장
변경은 RFD를 다시 제출할 필요가 없다.

2. RFD의 정의에 대한 간단한 요약

이전에 RFD를 접해보지 못한 사람들을 위해 RFD가 무엇인가를 설명하는 짧은
문장을 이 부분에 기술하는 것이 좋다. 그런 문장의 예는 아래 RFD
Template을 참조하라.

3. 뉴스그룹에 대한 간단한 설명

RFD의 나머지 부분을 기술하기 전에 제안된 뉴스그룹의 뉴스그룹 라인을
기술해야 한다. 이 라인은 관련 그룹에 대한 한 줄의 간단한 설명이다. 즉,
다음과 같은 형식을 취한다.

Newsgroups line:
han.rec.games 전자오락과 컴퓨터게임 이야기.
han.rec.games Computer Games, Electronic Amusement.

☞ 주(註): 위와같이 han.*계층에서는 뉴스그룹에 대한 설명을 한글과 영어
두가지로 해주어야 한다.

나열해야 할 그룹이 한 개가 아니라면 "Newsgroups line:" 대신 "Newsgroups
lines:" 와 같이 복수형을 쓴다. 설명은 마침표로 끝내야 하고 제안된 그룹이
중재그룹이라면 설명 끝에(마침표 다음)에 (Moderated)을 덧붙여야 한다.

삭제되는 그룹을 제외하고는 제안되는 모든 그룹은 뉴스그룹 라인이 있어야
한다.

4. 제안이유(Rationale)

제안이유(rationale)은 왜 그룹이 생성돼야 하는지를 설명하는 부분이다.
설득력 있는 제안이유(rationale)를 작성하는 자세한 방법은 han.answers에
정기적으로 투고되는 "▲ 설득력 있는 제안(RFD)을 작성하는 방법" 을 참고
하라.

그룹 제안이유는 다음과 같은 헤더로 시작해야 한다.

RATIONALE: group.name

만약 제안한 그룹이 여러개이고 제안이유가 하나라면 다음과 같은 헤더를
사용하라.

RATIONALE: all groups

제안한 그룹이 여러개일 경우 모든 그룹에 공통적으로 해당하는 제안이유와
좀 더 설명이 필요한 특정 개별그룹에 대한 별도의 제안이유 이렇게 양쪽이
있을 수 있다. 그러나 제안된 그룹은 둘 중 적어도 한가지는 반드시 있어야
한다.

제안이유를 설명하는 부분이 끝났다는 표시를 하는 구분자는 없다.

5. 헌장(Charter)

삭제되는 그룹이 아니라면 제안된 모든 그룹은 새로 만들어지는 그룹이
아닐지라도 관련 헌장이 있어야 한다. 헌장은 그룹에서 논할 주제가 뭔지를
알려주는 간단한 설명이다. 헌장에 명시해야 할 사항에 대해서는
han.answers에 정기적으로 투고되는 "▲ 설득력 있는 제안(RFD)을 작성하는
방법"을 참고 하라.

헌장은 다음의 형식을 취한다.

CHARTER: group.name

내용

END CHARTER.

"CHARTER: group.name" 와 "END CHARTER" 라인은 전후에 빈 라인이 있어
야만한다. 각 그룹은 그 자신의 헌장이 있어야 한다. 제안된 그룹 모두에
해당하는 공통적인 사항이 있다면 다음과 같은 형식의 별도의 란을 취한다:

CHARTER: all groups

개별적인 각 그룹 헌장에 "CHARTER: all groups"와 그 설명이 부가될 수
있다. 그러나 "RATIONALE: all groups" 와는 달리 "CHARTER: all groups"는
개별그룹의 헌장을 대신할 수 없다.

6. 중재자 정보

중재자가 중재하는 그룹으로 제안된 그룹은 관련 중재자 정보를 기술하는
부분(section)이 있어야 한다. 그 부분은 다음과 같은 형식을 취한다.

MODERATOR INFO: group.name

내용

END MODERATOR INFO.

그리고 내용에 다음을 명시해야 한다.

Moderator: 중재자 이름 <som...@email.address>

헌장 구분자와 같이 "MODERATOR INFO: group.name" 와 "END MODERATOR INFO"
역시 라인의 앞뒤에 빈 라인이 있어야 한다. 중재자 정보란에는 그룹 중재를
위해 추천된 특정 중재자들에 대한 정보(예를 들면, 그들의 이름, 자격등)을
명시한다.

중재정책은 이란이 아닌 헌장란에 명시한다.

7. 절차(Procedure)

RFD를 이전에 접해보지 않은 사람들을 위해 정형화된 문구로 절차를 간단히
설명하는 란(section)을 두는 것이 RFD의 표준이다. 뉴스그룹 정책에 대해
상대적으로 간단한 소개를 이 란(section)에 한다. 이 란에 써야 할 정형화된
문구는 아래 RFD template에 기술되어 있다. 다른 문구를 사용하려 한다면,
그 새로운 문구가 과연 아래의 정형화된 문구보다 더 좋은지 심사숙고하라.

절차란은 "PROCEDURE:" 헤더로 시작한다.

8. 배포(Distribution)

최종적으로, RFD가 제출되는 모든 뉴스그룹과 메일링 리스트는
"DISTRIBUTION:" 헤더로 시작하는 란에 나열 돼야한다. 아래에 언급된 것과
같이, "Newsgroups: header" 의 총길이는 200문자로 제한된다. 제안이
배포될 메일링 리스트는 물론 RFD가 제출되었다는 것을 알려주는 글을
투고할 뉴스그룹을 추가할 경우 그것들을 이란에 나열하라.

RFD를 메일링 리스트에 보내려고 한다면, 리스트 메일주소만 명시할 것이
아니라 무엇에 관한 메일링 리스트인지를 알려주는 최대 한 줄 또는 두 줄의
간단한 설명과 새 가입자가 가입할 수 있도록 가입주소를 RFD내에 명시하는
것이 흥미를 보이는 잠재적 가입자들에게 더 도움이 될 것이다.

9. 제안 조언자 정보

당신의 서명이 포함되지 않았다면 또는 포함되었다 하더라도, 누가 제안을
발전시키고 있는지 그리고 어느 조언자(group-mentor)가 도와주었는지를
명시할 수 있다.

제안자들은 다음과 같이 나열되어야 한다.

Proponent: 제안자1 이름 <som...@email.address>
Proponent: 제안자2 이름 <som...@email.address>

조언자(mentor)는 다음과 같이 나열되어야 한다.

Mentor: 조언자 이름 <som...@email.address>

10. 서명

메일과 뉴스 프로그램에 의해 자동적으로 흔히 붙는 전통적인 서명란은
4라인을 넘으면 안된다.

서명은 네트웍에서의 전통적 방법에 따라 "-- "을 이용해 본문과 분리한다.

----------------------------------------------------------------------
RFD 제출하기
----------------------------------------------------------------------

RFD를 제출하는 가장 좋은 방법은, han-an...@usenet.or.kr 로 메일을
보내는 것이다. 메일로 보낼 경우 본문 시작부분에 다음을 명시하라.

Newsgroups:
투고할 뉴스그룹
(나열한 그룹 중 중재그룹이 있다면 그것을 명시하라. 당신이 다른
중재그룹의 중재자들과 연락을 하고 RFDs, CFVs 그리고 결과를 교차 투고하는
것에 대한 승인을 미리 얻는다면 진행을 더 빠르게하고 han.announce
중재자를 약간 편하게 할 것이다)

☞ 주(註): RFDs, CFVs는 각각 RFD 와 CFV의 복수임.

Followup-To: 댓글을 제한할 뉴스그룹(일반적으로 han.news.groups이지만
밀접하게 영향을 받는 그룹의 독자들이 원한다면 그 그룹에 교차 투고 할 수
있다)

메일로 보내지 않고 뉴스프로그램으로 직접 투고할 수도 있다.

☞ 주(註): han.announce와 같은 중재그룹(moderated group)에 교차투고할
경우 기사가 즉시 뉴스그룹에 올라가는 것이 아니라 중재자(moderator)의
승인이 이루어진 후 올라가므로 기사가 나타나지 않는다고 재투고 하지
마십시오.

메일로 보내지 않고 뉴스그룹으로 직접 투고하면 han.announce 중재자에게
제대로 전달되지 않을 수도 있다.

한 개의 그룹 제안이라면 제출하는 RFD의 Subject: header는 다음과 같은
형식을 취한다.

RFD: group.name

그 그룹이 중재그룹이라면 그룹 이름 뒤에 "moderated" 을 덧붙인다.

여러개의 그룹 제안이거나 또는 그룹 재구성을 위한 것이라면 "RFD:
group.name.* reorganization" 와 같은 형식을 취한다. 만약 첫번째 RFD가
아니라면 "2nd", "3rd", "4th" 등이 RFD앞에 붙어야 한다."RFD:"는 그것이
정식 제안의 제출임을 즉시 알아볼 수 있게 한다.

다음은 han.announce로 제출되는 제안의 본문 시작부분의 예이다.

Newsgroups:
han.announce,han.news.groups,han.comp.ai,han.comp.ai.edu,han.comp.ai.gen
etic, han.comp.ai.neural-nets,han.comp.ai.vision

han.comp.ai.vision는 중재그룹이다. 그 그룹의 중재자는 그의 메일주소
"vis...@ads.com"를 사용해 교차 투고하는 것을 승인하였다.

Followup-To: han.news.groups

han.announce 에 투고될 기사는 그 그룹에 기사가 나타나기 전에는
han.news.groups 또는 다른 그룹, 메일링 리스트등 어디에도 공개적으로
나타나서는 안된다. han.announce에 기사가 나타난 시간이 그룹 생성
과정에서 사용되는 공식 기준시간이다. 다른 곳에 RFD를 제출하지 않도록
하는 것은 야기될 수 있는 혼란을 방지하기위한 것이다.

RFD가 han.announce에 나타난 후, 투고를 요청했던 그룹외 다른 곳에 추가
배포를 원한다면 메일 복사본이 아닌 han.announce에 나타난 그대로 배포할
수 있고 다른 포럼에 가공하지 않은 원본 메시지 그대로 투고할 수 있다.
한층 더 좋은 방법은, 특정 주제에 관한 뉴스그룹의 생성 또는 변경을 위한
제안이 han.announce에 투고되었다는 것과 그 기사에 대한 링크 그리고
han.news.groups에서 토론이 개최되고 있다는 것을 알려주는 간단한 글을
투고하는 것이다. 예를 들면:

우표수집에 관한 뉴스그룹(han.rec.collecting.stamps)을 생성하고자 하는
정식 제안이 han.announce에 <news:855.9...@isc.org> 와 같이
투고되었습니다.

이 제안을 개선하기 위한 여러분의 의견을 환영합니다. han.news.groups에서
토론을 할 것이고 약 3주에서 4주후에 투표가 있을 예정입니다.

----------------------------------------------------------------------
RFD Template
----------------------------------------------------------------------

REQUEST FOR DISCUSSION (RFD)
unmoderated group group.name

이 글은 뉴스그룹 group.name 생성을 위한 공식 토론요청(RFD)입니다. 이는
투표요청이 아니므로 지금 투표할 수 없습니다. 자세한 사항은 아래를
읽어보시기 바랍니다.

CHANGES from previous RFD:

[ 이번 RFD가 두번째 이후라면 첫번째 RFD에서 변경된 부분을 여기에
기술하라. 변경된 부분이 없다면 이 부분을 삭제하라 ]

Newsgroup line:
group.name 그룹에 대한 간단한 설명(한글).
group.name 그룹에 대한 간단한 설명(영어).

RATIONALE: group.name

[ 그룹을 생성 또는 삭제하고자 하는 이유 ]

CHARTER: group.name

[ 그룹에서 논할 주제가 뭔지를 알려주는 간단한 설명을 이 부분에
기술하라 ]

END CHARTER.

MODERATOR INFO: group.name

Moderator: 중재자 이름 <som...@email.address>

[ 중재에 관한 사항을 이 부분에 기술하라. 제안한 그룹이 중재그룹이
아니라면 이 부분을 삭제하라 ]

END MODERATOR INFO.

PROCEDURE:

이 글은 토론요청이며 투표요청이 아닙니다. 지금 단계에서 제안된 그룹의
잠재적 문제가 드러나고 해결될 것입니다. 토론기간은 이 제안에 대한 첫번째
RFD가 han.news.groups에 투고된 시점으로부터 최소한 21일간 지속될
것입니다. 토론 결과 투표요청을 하는 것이 문제없다면 중립적 투표관리자에
의해 투표요청(CFV)이 투고될 것입니다. CFV가 투고되기전까지는 투표하려고
시도하지 마십시오.

이 제안에 대한 모든 토론은 han.news.groups에 투고돼야 합니다.

DISTRIBUTION:

[ RFD를 배포할 뉴스그룹과 메일링 리스트를 이 부분에 명시하라 ]

Proponent: 당신의 이름 <yo...@email.address>

----------------------------------------------------------------------
Sample RFD
----------------------------------------------------------------------

Newsgroups:
han.announce,han.news.groups,han.rec.travel.ered-luin,han.rec.travel.mor
dor,han.rec.travel.rivendell,han.rec.travel.numenor,han.rec.arts.books.t
olkien

Followup-To: han.news.groups

han.rec.travel.mordor는 중재그룹입니다. 그 그룹의 중재자는 그의 메일주소
"som...@email.address"을 사용해 교차 투고하는 것을 승인하였습니다.

REQUEST FOR DISCUSSION (RFD)
unmoderated group han.rec.travel.shire
moderated group han.rec.travel.valinor
unmoderated group han.rec.travel.blue-mountains (renames
han.rec.travel.ered-luin)
unmoderated group han.rec.travel.mordor (unmoderates existing group)
moderated group han.rec.travel.rivendell (moderates existing group)
REMOVE han.rec.travel.numenor (renamed to han.rec.scuba.locations)

이 글은 han.rec.travel.* 계층 그룹의 재구성을 위한 공식
토론요청(RFD)입니다. 이는 투표요청이 아니므로 지금 투표할 수 없습니다.
자세한 사항은 아래를 읽어보시기 바랍니다.

CHANGES from previous RFD:

[ 이번 RFD가 두번째 이후라면 첫번째 RFD에서 변경된 부분을 여기에
기술하라. 변경된 부분이 없다면 이 부분을 삭제하라 ]

Newsgroup lines:
han.rec.travel.shire Shire 와 주변지역의 여행에 관한 이야기.
han.rec.travel.valinor Valinor 여행에 관한 이야기. (Moderated)
han.rec.travel.blue-mountains Blue Mountains 여행에 관한 이야기.
han.rec.travel.mordor Mordor 여행에 관한 이야기.
han.rec.travel.rivendell Rivendell여행에 관한 이야기. (Moderated)

RATIONALE: han.rec.travel.shire

이 부분에 han.rec.travel.shire 생성 이유를 명시하라. 제안한 모든 그룹의
생성 이유가 동일하다면 이 부분을 생략하고 다음과 같은 하나의
생성이유만을 가질 수도 있다.

RATIONALE: all groups

이것으로 제안된 모든 그룹의 개별 제안이유(rationale)를 대신할 수 있다.
제안 이유를 특별히 별도로 명시해야 할 그룹이 있다면 이 두 가지를 조합할
수도 있다. 중요한 것은 제안된 그룹은 개별 그룹에 해당하는 rationale이든
모든 그룹에 공통적인 "all groups" rationale 이든 둘 중 적어도 하나는
반드시 있어야 한다.

CHARTER: han.rec.travel.shire

이 부분에 han.rec.travel.shire의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.valinor

이 부분에 han.rec.travel.valinor의 헌장을 기술한다.
han.rec.travel.valinor는 중재그룹으로 제안되었기 때문에 상대적으로 더
중요할 것이다. 그러므로 헌장 내에 다음과 같은 하위 부분을 취할 것이다.

Moderation policies:

이 부분에 중재자가 지켜야 할 중재 정책을 기술하라.

END CHARTER.

MODERATOR INFO: han.rec.travel.valinor

Moderator: 중재자 이름 <som...@email.address>

중재그룹은 위와 같이 "Moderator: line" 을 취하는 MODERATOR INFO 란이
있어야 한다. 추천된 중재자에 대한 사항을 기술하기 위해 부가적 설명을
덧붙일수 있다. 중재 정책은 이란이 아닌 그룹헌장내에 기술해야 한다.

END MODERATOR INFO.

CHARTER: han.rec.travel.blue-mountains

이 부분에 han.rec.travel.blue-mountains의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.mordor

이 부분에 han.rec.travel.mordor의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.rivendell

이 부분에 han.rec.travel.rivendell의 헌장을 기술한다. 제안된 모든 그룹은
관련 헌장이 있어야 하고 각 그룹은 그 자신의 헌장이 있어야 한다("all
groups" 로 이를 대체할 수 없다). 그룹이름 변경 또는 관리상태 변경 제안
역시 마찬가지이다.

END CHARTER.

MODERATOR INFO: han.rec.travel.rivendell

Moderator: 중재자 이름 <som...@email.address>

END MODERATOR INFO.

CHARTER: all groups

이 부분은 위의 모든 그룹에 공통적으로 적용되는 부가적 헌장란이다. 이
부분은 선택사항(optional)이며 이것으로 위의 헌장을 대신할 수 없다.그룹이
생성될 때 이 부분은 각 그룹 생성 기사안의 개별 헌장에 부가될 것이다.

END CHARTER.

PROCEDURE:

이 글은 토론요청이며 투표요청이 아닙니다. 지금 단계에서 제안된 그룹의
잠재적 문제가 드러나고 해결될 것입니다. 토론기간은 이 제안에 대한 첫번째
RFD가 han.news.groups에 투고된 시점으로부터 최소한 21일간 지속될
것입니다. 토론 결과 투표요청을 하는 것이 문제없다면 중립적 투표관리자에
의해 투표요청(CFV)이 투고될 것입니다. CFV가 투고되기 전까지는 투표하려고
시도하지 마십시오.

이 제안에 대한 모든 토론은 han.news.groups에 투고되어야 합니다.

DISTRIBUTION:

이 RFD는 다음 뉴스그룹에 투고되었습니다:

han.announce, han.news.groups,
han.rec.travel.ered-luin, han.rec.travel.mordor,
han.rec.travel.rivendell, han.rec.travel.numenor,
han.rec.arts.books.tolkien

다음 메일링 리스트에도 배포되었습니다:

tolk...@e-mail.address(톨키언의 언어학적 토론)
메일링 리스트 가입 주소: tolklang...@e-mail.address

Proponent: 제안자1 이름 <som...@email.address>
Proponent: 제안자2 이름 <som...@email.address>

☞ 주(註): 이 문서를 다 읽었음에도 제안을 하는데 어려움을 느끼신다면
han.news.groups에 도움을 요청하십시오.

참고:
(1) 이 문서에 사용된 "☞ 주(註):" 표시 다음의 설명은 독자의 이해를
돕기위해 역자가 추가한 내용입니다.
(2) 이 문서 시작부분의 버전번호는 역자가 문서를 수정할경우 올라갑니다.

------=_NextPart_000_0093_01C2B50A.81719440
Content-Type: message/rfc822;
name="=?euc-kr?B?oeMgvLO15rfCIMDWtMIgwaa+yChSRkQpwLsgwNu8usfPtMIguea5/S5ud3M=?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="=?euc-kr?B?oeMgvLO15rfCIMDWtMIgwaa+yChSRkQpwLsgwNu8usfPtMIguea5/S5ud3M=?="

From: "Ahn Byong-Gil" <sanc...@softhome.net>
Newsgroups: han.answers,han.news.groups,han.news.users
Followup-To: han.news.groups
References: <a0qrcl$gg7$2...@news1.kornet.net>
Subject: ▲ 설득력 있는 제안(RFD)을 작성하는 방법
Date: Sun, 5 Jan 2003 22:20:19 +0900
Lines: 195
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

이 글은 news.groups 에 정기적으로 투고되는 "How to Write a Good
Newsgroup Proposal" 를 저자의 동의를 얻어 번역한 것입니다.

저 자: Una Smith <una....@yale.edu>
번역자: 안병길<sanc...@softhome.net>
버 전: 1.13B

***********************************
설득력 있는 제안을 작성하는 방법
***********************************

새로운 뉴스그룹 생성을 제안하는데 있어 가장 중요한 것은 글을 읽는 이가
거부 반응을 일으키지 않고 제안된 그룹에 가입하도록 유인할 수 있는
간결하고 설득력 있는 토론요청(RFD)을 작성하는 것이다. 그러한 목적 달성을
돕기 위해, 뉴스그룹 생성과정에 참여하면서 쌓은 많은 경험과, 우리 자신의
많은 성공적 RFD제출 경험을 토대로 한 다음의 조언을 하는 바이다.

서투른 RFD는 RFD내에 속하지 않는 항목들을 포함하곤 한다. 바람직한 RFD는
그룹헌장, 제안이유, 중재그룹(moderated group)이라면 중재정책, 메일링
리스트와의
연계여부등만을 포함해야 한다. 그룹에서 논할 주제의 과거 역사(history)는
RFD 항목에 속하지 않는다; 별도 기사로 간단한 설명을 투고할 수는
있다(news.announce.newgroups에 투고해서는 안된다)

☞ 주(註): "주제의 과거 역사(history)"는 과거에 어떤 사람들이 그 주제로
토론을 했으며, 어떻게 결정 되었는지등의 과거에 이루어진 제반 사항을
의미합니다.

RATIONALE(제안이유):

제안이유(rationale)는 왜 그룹 생성이 필요한지를 간단하고 설득력있게
설명하는 부분이다. 다른 유즈넷 그룹 또는 유즈넷과 관련없는 주제 자체의
가치에 대한 설명은 피해야 한다. 제안된 그룹과 현재 존재하는 다른
그룹들과의 관계를 설명하는데 집중하라. 제안된 그룹이 이미 존재하는 다른
그룹과 충돌하거나 중복된다면, 왜 새로운 그룹이 필요한지 또는 가치가
있는지를 정당화하고 왜 다른 그룹이 목적에 부합하지 않은지를 설명하라.
다른 사람들을 불쾌하게 하거나 감정을 상하게 하지 않도록 주의하라; 만약
당신이 다른 그룹의 독자들을 불쾌하게 하거나 적으로 만든다면, 그들은 당신
제안에 반대표를 던지고 다른 투표자들이 반대표를 던지도록 유도함으로서
당신의 그룹생성을 최대한 방해할지 모른다. 그들이 정말로 그러길 원한다면
그들이 이길 가능성이 높다. 그러한 거부 반응을 일으킬 것이 확실한 설득력
약한 제안이유에는 다음과 같은 것들이 있다.

당신 이웃의 부정

X 그룹은 죽었다, 그러므로 나는 Y로 다시 시작하기를 원한다.
X 그룹은 Y보다 사회적 역할을 수행하는데 미흡하다.
X 그룹은 Y보다 가치가 적다.

정치적 정의에의 호소

Y 는 소수이다. 뉴스그룹이 생성되면 그들의 평등권이 향상될것이다.
Y 는 불합리한 생각이다. 뉴스그룹이 생성되면 정의가 실현될것이다.
Y 사람들은 특별하므로 그들의 장소가 필요하다.

명백한 게으름의 인정/도둑질

Y2 그룹은 부적절한 투고를 제어하기 위해 중재그룹이 되어야 한다.
그러나 그것은 노동이다. 따라서 그 대신 나는 Y를 원한다.
Y2 그룹은 내가 별로 중요하지 않다 생각하는 기사들로 가득차있다.
그러므로, 나는 좋은 기사들만을 Y로 추출해 내고 싶다.
Y2 메일링 리스트는 나에게는 너무 붐빈다. 그러나, 뉴스그룹과의
연계는 원치않는다. 그러므로 나는 Y그룹을 만들어서 메일링
리스트 독자들을 Y그룹으로 끌어오기를 원한다.
Y2 메일링 리스트는 죽었다. 그러므로 나는 독자들을 리스트와
분리된 또는 연계된 Y 그룹으로 끌어오기를 원한다.
a 메일링 리스트는 내가 운영하기에 너무나 고된 일이다.
a 메일링 리스트는 독자들이 발견하기가 너무 어렵다.

☞ 주(註): "도둑질"은 Y2 그룹의 기사나 메일링 리스트의 독자들을 빼오는
행위를 일컬음(역자)

당신의 동기가 위의 수치수러운 범주 내에 속할지 모른다. 또는 당신의
동기가 순수하고 고귀할지도 모른다. 좋지 않은 동기의 인정은 당신에 대한
거부감을 일으킬 것이다. 반면, 좋은 동기는 다른 사람이 당신의 의도를
이해할 수 있게 할 것이다. 하지만 이해할 수 있을 뿐 그 밖의 것을 기대할
수 없다.

당신의 동기는 무시하고 대신 당신이 제안한 그룹을 생성해야 할 강하고,
합리적 이유를 독자들에게 확신 시킨다면 우리는 당신의 동기가 무엇인지
개의치 않을 것이며 RFD를 읽는 독자들 역시 마찬가지 일 것이다. 유즈넷
또는 메일링 리스트에 많은 독자가 있다는 증거를 보이거나 또는 다른
추세로부터 합리적 추론을 하는 것이 설득력있는 설명이다.

Y 주제는 A, B, 그리고 C그룹에서 논의되므로 독자가 존재한다.
Y 에관한 그룹이 생성되면 아마도 그들은 그 그룹을 이용할 것이다.
Y 그룹은 너무 붐비므로 그 그룹의 독자들은 그룹을 나누기를
원한다.
Y 그룹의 기사는 같은 범주가 아닌 둘 또는 그 이상의 다른 타입의
기사들이다.
Y 메일링 리스트는 너무 붐비므로 연계된 뉴스그룹이 필요하다.
그렇지 않으면 독자들이 떠날 것이다.
Y 메일링 리스트는 너무 붐빈다. 독립적인 Y 그룹은 리스트의 붐빔을
완화 시킬 것이다.
Y 메일링 리스트에는 수천명의 구독자가 있다. 이는 같은 주제의
뉴스그룹이 생성되면 인기가 있을거라는 것을 암시한다.
Y 전문적인 집단/취미 그룹/공동체는 수천명의 회원을 가지고 있다.
그들 중 많은 사람들이 그 주제로 뉴스그룹이 생성되면
참여할 것이라고 말한다.

가능하다면, 그 주제를 직접적으로 다루는 메일링 리스트를 예시하고, 그
리스트의 가입자 수와 리스트의 대략적인 하루 메시지 수를 제시하라.이
자료는 종종 메일링 리스트 서버에서 자동적으로 이용가능하거나 리스트
운영자가 기꺼이 제공할지 모른다. 당신 제안과 대략적으로 같은 주제의
메일링 리스트가 존재한다면, 이러한 객관적 정보를 제시하는 것이 중요하다.
다시 말하지만, 메일링 리스트의 운용자 또는 구독자를 적으로 만들지 않도록
주의하라; 그들은 그 메일링 리스트에 대한 그들 자신의 계획을 가지고
있을지 모르고 당신의 RFD를 어떤 면에서 방해요인으로 간주할지 모른다.
메일링 리스트에 직접적으로 영향을 미치는 RFD를 시작하기 전에 메일링
리스트 운영자의 허가를 얻는 것이 좋은 태도이다.

일반적으로, 너무 붐비는 뉴스그룹은 하루에 200개 이상의 기사가 투고되며
유즈넷 뉴스그룹으로 확장되기에 충분히 성숙한 메일링 리스트는 하루에
50개이상의 기사를 가지고 있거나 1000명 이상의 구독자를 가지고 있다.
관련있는 뉴스그룹 또는 메일링 리스트의 사용현황에 대한 공정하고 정확한
자료를 제공하는 것은 당신 제안에 많은 도움이 될 것이다. 추측하지 마라.
정직하라. 만약 당신의 제안을 이와 같은 근거로 합리화 시킬 수 없다면,
당신의 제안이 관련 메일링 리스트의 구독자도 별로 없고 기사수도 많지
않음에도 불구하고 왜 장점을 가지고 있는지를 설명하라. 예를 들면, 현재는
유즈넷상에 독자가 존재하지 않지만 당신이 제안한 주제의 뉴스그룹을
생성하면, 유즈넷의 다른 추세와 더 큰 세계의 추세로 미루어 볼 때 많은
독자들이 생길 것이라는 것을 자신있게 주장할 수 있을지 모른다. 창조적이고
매우 정직해라. 좋은 아이디어를 위해 다른 제안들을 살펴봐라.

☞ 주(註): 위의 구체적 수치는 한글그룹 기준과 다를 수 있음(역자)

헌장

헌장 안에는 그룹의 일반적 주제에 대한 간단한 설명은 물론, 그룹에서
환영받을 기사의 유형을 언급하는 것이 좋다. 환영받을 것처럼 보이나 실은
부적절한 유형에 대해 언급하는 것 역시 좋을 수 있다.

예를 들면, 소프트웨어 드라이버의 디자인과 구조에 관해 토론할 그룹을
만들려고 하는 사람들은 염가판매로 구입한 이름없는 중고 컴퓨터의 특정
드라이버를 찾는 컴퓨터 소유자들의 막무가내식 요청기사는 환영하지 않을지
모른다. 그들은 그룹 헌장에 "드라이버 요청 사절" 이라고 구체적으로
명시할지 모른다.

그 주제가 얼마나 가치있는지 또는 그룹 생성이 왜 (유즈넷 세계가 아닌)실제
세계에서 사회적 또는 정치적 목적을 진보시키는지에 관한 가치적 언급을
헌장 내에 포함해서는 안된다. 헌장은 그룹의 예견된 상황과 목적에 대한
공식적 설명이며 제안자(당신)과 그 그룹의 미래의 독자와의 비공식 계약,
그리고 그룹에 대한 가장 중요한 참고 자료(그룹 FAQ보다 한층 중요한)이기
때문에, 지금 부터 10년이 지나도 여전히 같은 의미를 가질 수 있도록
명확하고 완전하게 씌어져야 한다.

헌장의 공통적인 문제는, 뉴스그룹은 일반적으로 범 세계적 흥미를 가질 수
있는 주제를 다루어야 한다는 것이다. 그러므로, 예를 들면, 특정 국가의
스포츠 팀에 관계되는 그룹의 제안은 "big 8"에 속하지 않는다. 아주 강력한
생성근거 조차도 이러한 유형의 제안을 정당화 시킬 수 없다. 그러나 두 가지
훌륭한 해결 방법이 있다: 그 주제를 포함 할 수 있도록 세계 어디에나
적용할 수 있는(일반 스포츠와 같이) 추상적 수준으로 헌장을 수정하거나
당신 나라 또는 지역 계층 내에서 뉴스그룹을 생성하는 방법을
조사하라.(예를 들면, 한국의 han.*, 미국의 us.*, 캐나다의 can.*,
독일어권의 de.*)

☞ 주(註): "한국의 han.*" 은 역자가 추가한 것임.

중재자(Moderator):

제안된 그룹이 중재그룹(moderated group)이어야 한다면, 이유를 간단히
설명해야 한다. 또한, 추천된 중재자의 이름과 이메일 주소를 적고, 자격과
관련 의무를 개략적으로 나열하라. 일반적으로 중재자의 의무는 헌장에
부합하지 않은 기사를 거절함으로서 그룹 헌장을 수호하는 것이다.

최종 조언:

명심하라, 당신의 목적은 (1) 가장 적절한 뉴스그룹을 제안하는 것이고, (2)
다른 사람들이 당신 제안을 지지하도록 그들을 설득하는 것이다. 그러므로
RFD를 쓰는 것은 많은 시간의 주의 깊은 사고와 연구를 필요로 한다. 그러나
많은 시간의 주의 깊은 사고와 연구를 했음에도 불구하고, 다른 사람들은
당신의 목적 달성 방법과 다른 생각을 가지고 있거나 그들 자신이 더 좋은
목적을 가지고 있다고 생각할지도 모른다. 그 비평은 종종 옳다. 그러므로
그들의 의견과 왜 그들이 그러한 의견을 냈는지를 시간을 두고 신중히
생각하라. 무엇보다도, 인내를 가지고 이성을 잃지 마라.

그룹 조언자들로부터 받게 될지도 모를 의견은 당신 제안을 방해하고자하는
의도가 아니고 news.groups에서 정밀한 공개 검증을 받기 전에 최대한
개선되었는지를 확실히 하고자 하는 것이다.우리로부터 받는 피드백에
방어적으로 대응하려 하지 마라: 그것은 도움을 주고자 하는 것이다. 이해가
안가거나 우리의 의견이 명백히 당신 제안 전체를 거절하는 것처럼 보인다면
자세한 설명을 요구하라. 우리는 당신 RFD내의 특정 주장을, 사실상 진실이
아니거나, 논리적 결함이 있거나, 당신 제안에 결코 이롭지 않은(정말, 이런
경우가 발생한다) 주장으로 간주함으로써 그 부분에 대해 거절할지는 모르나,
결코 당신 제안 자체를 거절하지는 않는다.

마지막으로, RFD의 내용, 구조, 명료성, 문법, 철자를 주의깊게 살펴봐라.

행운이 있기를...

참고:
이 문서 시작부분의 버전번호가 올라갔다면 이는 역자가 문서를
수정하였음을 의미합니다.

------=_NextPart_000_0093_01C2B50A.81719440
Content-Type: message/rfc822;
name="=?euc-kr?B?oeMgwK/B7rPdILS6vbqx17fsIMDMuKe/oSC068fRIMH2xKcubndz?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="=?euc-kr?B?oeMgwK/B7rPdILS6vbqx17fsIMDMuKe/oSC068fRIMH2xKcubndz?="

From: "Ahn Byong-Gil" <sanc...@softhome.net>
Newsgroups: han.answers,han.news.groups,han.news.users
Followup-To: han.news.groups
References: <a0qrcl$gg7$3...@news1.kornet.net>
Subject: ▲ 유즈넷 뉴스그룹 이름에 대한 지침
Date: Sun, 5 Jan 2003 22:19:14 +0900
Lines: 158
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

이 글은 news.announce.newusers 에 정기적으로 투고되는 "Guidelines on
Usenet Newsgroup Names"를 번역한 것입니다. 이 원칙은 한글그룹에도
적용되므로 RFD작성시 참고 하시기 바랍니다

저 자: David.W...@bnr.co.uk
번역자: 안병길 <sanc...@softhome.net>
버 전: 1.22C

Archive-name: usenet/creating-newsgroups/naming/part1
Last-change: 13 Jun 1995 by netan...@deshaw.com (Mark Moraes)
Changes-posted-to: news.misc

***********************************
유즈넷 뉴스그룹 이름에 대한 지침
***********************************

이 문서는 유즈넷 뉴스그룹 comp", "humanities", "misc", "news", "rec",
"sci", "soc" "talk" 계층에서 새로운 뉴스그룹을 생성하고자하는 사람들을
위한 기본지침서이다.

☞ 주(註): 각 계층에서 다루는 주제는 이 문서의 맨 아래를 참고 하시기
바랍니다.

유즈넷 뉴스그룹 이름은 조립적이고, 계층적이며, 분류적이나 제한적이지
않다. 이러한 속성은 유즈넷 이용자들이 원하는 그룹을 쉽게 찾고 뉴스서버
운영자가 그의 서버 이용자들을 위해 시스템을 관리하는 것을 돕기 위한
것이다. 이 용어들 각각에 대한 개념을 이해함으로써, 당신은 새로운
뉴스그룹에 적합한 이름을 선택하는 방법을 이해할 수 있을 것이다.

조립적

"rec.pets.dogs"와 같이 뉴스그룹 이름은 점에 의해 분리된 몇 개의
부분들로 구성되어 있다. 각 부분은 최대 14자까지 허용되며
순수하게 영문자만으로, 아니면 적어도 한 개의 영문자를 가진, 숫자
또는 "+" 와 "-"로 구성 되야 한다.

계층적

이름은 명확한 계층으로 구성 되야 한다 - 예를 들면, 컴퓨터 관련
모든 그룹은 comp.내 속한다. sci.physics 와 comp.sys.sun 에서와
같이 기본이름에 하위부분을 추가함으로서 두번째, 세번째 그리고 더
하위의 계층으로 확장된다. 첫번째부분(sci 또는 comp)이 가장 넓은
개념이며 하위로 갈수록 더 구체적이다. 마지막부분으로 실제
그룹이름을 완성한다. 각 부분은 레벨이 다른 것을 의미하므로, 같은
레벨의 단어들은 하이픈을 사용해서 한 부분에 포함된다 - 예를
들면, misc.invest.estate.real 대신 misc.invest.real-estate와
같이 구성해야 하며, 이것은 real이 estate의 한 종류라는 것을
의미한다.

분류적

분류학은 사물을 분류하는 학문이다 - 예를 들면, 생물학에서 종의
분류, 도서관에서 책의 분류와 같은 것을 말한다. 그룹 이름은
주제를 분야와 계층으로 분류한다. 이미 존재하는 그룹 이름과
조화를 이루어야 하고 앞으로의 성장 가능성을 고려해야 하므로
그룹이름을 옳게 분류하는 것은 쉽지 않다.

비 제한적

뉴스그룹 이름은 제한적이지 않고 포괄적이다. 즉, 투고하기에 더
적합한 이름의 그룹이 없다면 뉴스그룹 이름은 기사가 투고될 곳을
결정한다. 이름은 그룹의 정확한 한계를 결정하지 않으며 그룹 이름
개념에 정확하게 일치하지 않는 주제의 기사일지라도 이를 금지하지
않는다.

이용자 돕기
그룹이름은 이용자가 그룹의 기사를 읽어보지 않고 그룹의 성격을
파악할 수 있는 유일한 단서일 경우가 종종 있다. 현재 뉴스그룹은
1300개가 넘으며 alt 에서 zer까지 다른 뉴스계층들을 모두 포함하면
10,000개가 훨씬 넘는다. 흥미있는 그룹을 찾기 위해 모든 그룹의
기사를 읽는 것은 불가능하다. 비슷한 예로, 아주 인기있는
그룹일지라도 모든 유즈넷 이용자의 1%정도가 구독할 뿐이다.
그러므로 뉴스그룹 이름은 그룹을 읽지 않는 99%의 이용자에게
의미를 가질 수 있는 이름이어야한다. "이 그룹은 무엇에 관한
그룹이냐?" 와 같은 기사가 올라오지 않을 정도로 뉴스그룹 이름은
충분히 명확해야 하며 그룹의 주제에 관해 좀 더 알고 싶어하는
사람들이 그룹의 목적을 알고 기사를 읽기 시작하며 가입할 수
있도록 해야 한다. 또한, 유즈넷은 세계적이고, 유즈넷에는 서로
다른 다양한 문화권의 이용자들이 있다는 것과, 그들 중 많은
사람들이 영어를 모국어로 하지 않는다는 것을 명심하라.

그러한 이유로 다음 지침은 이름 선택에 있어 어느 정도 강력한
지침이다:

- 가능한한 유사한 주제들을 같은 계층만에 함께 그룹화하라. 그래야
관련 주제를 찾는 사람들에게 그것을 어디에서 찾을 수 있을 지에
대한 실마리를 제공할 것이다. 정확성을 이유로 많은 잠재적
구독자가 보지 않을 다소 모호한 곳에 그룹을 배치하는 것을
고집하기 보단 대략적으로 부합하는 곳에 위치시키는 것이 더 좋은
경우가 종종있다.

- 매우 구체적인 그룹을 생성하기 전에 일반적인 그룹을 먼저
생성하라.

- 이름을 단축하거나 모호한 이름을 사용하지 마라. 이름을 단축하면
다른 사람들은 전혀 다른 뜻으로 받아들 일수 있다. 특히 영어가
그들의 모국어가 아닐 경우에는 더욱 그러하다. 현재, 유즈넷
전송제한은 이름의 각 부분을 최대 14자로 한정한다. 이 제한 때문에
때때로 그룹 이름을 단축시켜야만 할 경우가 있다. 그와 같은
경우에는, 14자리 안에서 가능한한 의미있는 단축어를 만들어라.

- 그룹 이름에 영어 단어를 사용하라. 그룹의 기사는 그 그룹에
적합한 어떤 언어를 사용해도 좋으나 그룹 이름에는 영어를 사용해야
한다. 왜냐하면 영어는 거의 모든 유즈넷 이용자가 이해할 수 있는
유일한 언어이기 때문이다.

뉴스서버 운영자 돕기
현재 어떤 뉴스서버도 10,000개의 뉴스그룹을 받아서 모든 기사를
수주일 동안 보관할 수 있는 디스크 공간을 가지고 있지 않다.
그러므로 뉴스서버 운영자들은 어떤 그룹의 기사를 받고 언제까지 각
그룹의 기사를 보관할 지에 대해 신중해야만 한다. 그러나 아주 많은
그룹이 존재하기 때문에 그들은 각각의 그룹을 개별적으로 관리할 수
없다. 그러므로 그들은 뉴스그룹의 계층적 속성을 이용하며
계층 내에서 뉴스를 제어한다. 예를 들면, 어떤 운영자는 comp계층의
기사를 rec 계층의 기사보다 오래 보관할지 모른다. 또 어떤 이는
그의 서버 이용자 중 아무도 comp.sys.ibm.* 계층의 그룹을 이용하지
않기때문에 comp.sys.ibm.* 계층을 받지 않기로 결정할지 모른다.
이것은 계층화가 아주 중요하며 왜 새로운 그룹이 가능한한 현재의
계층과 조화를 이루어야 하는지에 대한 또 다른 이유이다. 일부
제안자는, 특정 그룹을 원하지 않는 뉴스서버 운영자가 그 그룹을
개별적으로 배제 할 수 있다고 가정하고 이 원칙을 지키지 않아도
된다고 생각한다. 그러나 그것은 틀린 생각이다. 이용자가 읽지 않는
그룹의 기사를 받는 것은 디스크 공간을 줄이며 그들이 정말로
필요로 하는 그룹의 기사 만기일을 단축시킨다.

다음은?
새로운 뉴스그룹의 이름을 짓기 전에 이 지침에 관해 생각하라.

유즈넷의 규모가 훨씬 작았던 과거 또는 현재 alt와 같은 통제되지
않는 다른 계층에서 일어난 잘못된 이름짓기는 더 이상 일어나서는
안된다는 것을 명심하라. 아니, 실수를 안하는 것에서 한발 더
나아가 지금은 과거의 실수를 수정할 때이다.

이 문서를 다 읽은 이 시점에서 여전히 조언이 필요하다면
<group-...@uunet.uu.net> 로 메일을 보내라.

☞ 주(註): 월드와이드 그룹인 Big8 의 각 계층에서 다루는 주제(역자)

comp(computer) : 컴퓨터 소프트웨어와 하드웨어에 관련된 주제.
humanities : 문학, 철학, 인문학에 관련된 주제.
misc(miscellaneous) : 다른 그룹에 속하지 않는 주제.
news : 뉴스그룹 자체에 관련된 주제.
rec(recreation) : 오락, 여가, 취미와 관련된 주제.
sci(science) : 과학이나 수학에 관련된 주제.
soc(society) : 사회과학 또는 종교, 문화, 역사, 사회와 관련된 주제.
talk : 정치, 종교 기타 활발한 논쟁을 야기하는 주제.

해당 계층의 유즈넷 이용자들이 토론을 통해 계층을 생성, 변경,
재구성하므로 계층의 개념이나 분류는 지역이나 나라마다 다를수 있습니다.
한글그룹 계층에 대해서는 han.answers 에 정기적으로 투고되는 "han
newsgroup hierarchy"를 참고 하시기 바랍니다.

참고:
이 문서 시작부분의 버전번호가 올라갔다면 이는 역자가 문서를
수정하였음을 의미합니다.

------=_NextPart_000_0093_01C2B50A.81719440
Content-Type: message/rfc822;
name="=?euc-kr?B?oeMgx9Gx2yC0ur26sde37CC7/by6IMXkt9C/5MO7KFJGRCnA27y6uf0ubndz?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="=?euc-kr?B?oeMgx9Gx2yC0ur26sde37CC7/by6IMXkt9C/5MO7KFJGRCnA27y6uf0ubndz?="

From: "Ahn Byong-Gil" <sanc...@softhome.net>
Newsgroups: han.answers,han.news.groups,han.news.users
Followup-To: han.news.groups
Subject: ▲ 한글 뉴스그룹 생성 토론요청(RFD)작성법
Date: Fri, 3 Jan 2003 21:38:29 +0900
Lines: 559
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

이 글은 news.groups 에 정기적으로 투고되는 "How to Format and Submit a
New Group Proposal" 를 저자의 허락을 얻어 한글 그룹에 맞게 번역한
것입니다. 이 문서와 han.answers에 정기적으로 투고되는 "한글 뉴스그룹
생성 절차", "▲ 설득력 있는 제안(RFD)을 작성하는 방법", "▲ 유즈넷
뉴스그룹 이름에 대한 지침" 을 같이 참고 하시기 바랍니다.

저 자: Russ Allbery <r...@stanford.edu>
번역자: 안병길 <sanc...@softhome.net>
버 전: 1.22A

*************************************
뉴스그룹 생성 토론요청(RFD)작성법
*************************************

이 문서는 한글 뉴스그룹 han.* 계층에서의 그룹 생성 또는 재구성을 위한
제안을 준비하는 사람들을 위해 작성되었다. 제안의 첫 번째 단계는
"han.announce" 와 "han.news.groups" 그룹에 토론요청(RFD)을 제출하는
것이다. 이 문서는 그 양식에 대해 설명한다.

이 표준 양식의 목적은 뉴스그룹 생성과정에서 많은 부분을 차지하는 RFD의
자동화를 이룩하고 그럼으로써 더 정확하고 더 효율적으로 그룹 생성 과정을
진행할 수 있으며 또한 제안자가 중요한 모든 정보를 빠뜨리지 않도록 하기
위한 것이다.

이 문서는 (1) RFD 양식 설명, (2) RFD Template, (3) 양식에대한 대부분을
설명하는 Sample RFD의 세 단원으로 구성되어있다. RFD Template부터 읽어도
쉽게 이해할 수 있을 것이다. 그러나 RFD Template부터 읽는 것이 어렵다고
느껴지거나 RFD Template의 설명을 더 잘 이해하기를 원한다면 나머지 두
단원이 도움이 될 것이다.

☞ 주(註): RFD Template부터 읽기를 권합니다.

----------------------------------------------------------------------
RFD 양식 설명
----------------------------------------------------------------------

han.news.groups에 투고될 기사는 헤더(header), 요약 그리고 본문 3부분으로
구성되어 있다:

I. 헤더

헤더는 유즈넷 기사에 대한 표준을 따른다. 제안의 제출자로서 당신에게
요구되는 것은 From:header, Subject: header, 그리고 Newsgroups: header를
제공하는 것이다. (실제 제안제출 과정에 관한 자세한 것은 아래를 참조하라)

일자: 일자는 기사가 투고된 시간과 날짜를 보여준다. 진행 과정에서의 시간
계산은 이것을 기준으로 한다. 제안에 대한 CFV(투표요청)은 첫번째 RFD가
투고된 날로부터 최소한 21일이 지나고 가장 최근의 RFD로 부터 10일이
지나기 전까지는 미리 제출할 수 없다.

가장 최근의 RFD가 제출된 이후로 2달 이상이 경과 됐으면 투표로 진행하기
전에 RFD를 다시 제출해야 한다.

Message-ID: Message-ID는 네트웍상의 기사에 대한 유일한 구분자이다;
Message-ID가 동일한 기사는 있을 수 없으므로 특정 기사를 가리키기
위해 Message-ID를 이용할 수 있다.

Followup-To: 댓글을 제한할 뉴스그룹(일반적으로 han.news.groups이지만
밀접하게 영향을 받는 그룹의 독자들이 원한다면 그 그룹에 교차투고 할 수
있다)

Approved: Approved 는 누가 그 기사를 han.announce에 중재 했는지를
보여준다. 만약 그 기사가 다른 중재그룹에 교차투고 되었다면 그 그룹
중재자들의 주소가 나열될지도 모른다.

☞ 주(註): 제안자는 뉴스리더(Outlook Express, Netscape등)에서
Followup-To(댓글 제한)을 하는 방법만 아시면 되고 헤더의 의미는 몰라도
관계없습니다.

II. 요약

RFD의 첫 부분은 요약이고 그것은 다음의 머릿글로 시작한다.

REQUEST FOR DISCUSSION (RFD)

머릿글 다음 라인에 제안 그룹 목록을 적는다. 첫 라인은 항상 위와 같은
머릿글로 시작해야 하며, 이는 개정된 RFD의 재 투고 일지라도 마찬가지이다.

그룹 목록은 중간 정렬 해야 하며 빈라인이 없어야 한다. 제안된 그룹은 다음
형식 중 어느 한가지 내에 속해야 한다.

unmoderated group foo.bar

foo.bar로 명명된 새로운 비 중재그룹 생성을 제안하는 것이다. 만약
생성하고자 하는 그룹이 중재그룹이라면 unmoderated 를 moderated로
대체하라.

unmoderated group foo.bar (renames foo.baz)

foo.baz 를 foo,bar로 이름을 변경하는 제안을 하는 것이다. 만약
변경된 그룹이 중재그룹이라면 unmoderated 를 moderated로
대체하라.

moderated group foo.bar (moderates existing group)

비 중재그룹에서 중재그룹으로 foo.bar의 관리상태를 변경하는
제안이다.

unmoderated group foo.bar (unmoderates existing group)

중재그룹에서 비중재 그룹으로 foo.bar의 관리상태를 변경하는
제안이다.

REMOVE foo.bar (renamed to foo.baz)

foo.bar의 삭제를 제안하는 것이다. 그룹 삭제는 삭제되는 그룹의
이름을 이미 존재하는 그룹의 이름으로 변경함으로써
이루어진다(이는 현재 삭제되는 그룹으로 투고되는 기사가 변경된
그룹으로 투고돼야한다는 것을 의미한다)

III. 본문

0. 일반적 형식에 대한 설명

문단은 왼쪽 정렬되어야 하며 라인은 70컬럼이어야한다. 줄바꿈을 60컬럼보다
적게 잡거나 70컬럼과 60컬럼을 혼합해서 사용하지 마라.

이 문서에 사용된 형식과 같이 문단은 들여쓰기해서는 안되고 빈줄에 의해
분리돼서도 안된다.

제안자 또는 중재자를 나열할 때와 같이 이메일 주소가 필요 할 경우 주소는
각 괄호(<>)로 들러 싸야 한다.

1. 반복되는 RFD에 대한 변경 사항 기술

이번 RFD가 같은 제안에 대한 두번째 이후의 RFD라면, "CHANGES from
previous RFD" 로 시작하는 부분이 여기에 기술 돼야 하고 이전 RFD에서
변경된 모든것을 나열해야 한다. RFD에 주목할만한 변경이 있거나 이전 RFD
이후로 두달 이상이 경과되었을 경우에만 새로운 RFD를 투고해야 한다.
주목할 만한 변경에는 제안된 그룹 이름의 변경, 관리상태의 변경 또는
헌장의 중요한 변경이 있다. 사소한 이유(rationale) 변경 또는 사소한 헌장
변경은 RFD를 다시 제출할 필요가 없다.

2. RFD의 정의에 대한 간단한 요약

이전에 RFD를 접해보지 못한 사람들을 위해 RFD가 무엇인가를 설명하는 짧은
문장을 이 부분에 기술하는 것이 좋다. 그런 문장의 예는 아래 RFD
Template을 참조하라.

3. 뉴스그룹에 대한 간단한 설명

RFD의 나머지 부분을 기술하기 전에 제안된 뉴스그룹의 뉴스그룹 라인을
기술해야 한다. 이 라인은 관련 그룹에 대한 한 줄의 간단한 설명이다. 즉,
다음과 같은 형식을 취한다.

Newsgroups line:
han.rec.games 전자오락과 컴퓨터게임 이야기.
han.rec.games Computer Games, Electronic Amusement.

☞ 주(註): 위와같이 han.*계층에서는 뉴스그룹에 대한 설명을 한글과 영어
두가지로 해주어야 한다.

나열해야 할 그룹이 한 개가 아니라면 "Newsgroups line:" 대신 "Newsgroups
lines:" 와 같이 복수형을 쓴다. 설명은 마침표로 끝내야 하고 제안된 그룹이
중재그룹이라면 설명 끝에(마침표 다음)에 (Moderated)을 덧붙여야 한다.

삭제되는 그룹을 제외하고는 제안되는 모든 그룹은 뉴스그룹 라인이 있어야
한다.

4. 제안이유(Rationale)

제안이유(rationale)은 왜 그룹이 생성돼야 하는지를 설명하는 부분이다.
설득력 있는 제안이유(rationale)를 작성하는 자세한 방법은 han.answers에
정기적으로 투고되는 "▲ 설득력 있는 제안(RFD)을 작성하는 방법" 을 참고
하라.

그룹 제안이유는 다음과 같은 헤더로 시작해야 한다.

RATIONALE: group.name

만약 제안한 그룹이 여러개이고 제안이유가 하나라면 다음과 같은 헤더를
사용하라.

RATIONALE: all groups

제안한 그룹이 여러개일 경우 모든 그룹에 공통적으로 해당하는 제안이유와
좀 더 설명이 필요한 특정 개별그룹에 대한 별도의 제안이유 이렇게 양쪽이
있을 수 있다. 그러나 제안된 그룹은 둘 중 적어도 한가지는 반드시 있어야
한다.

제안이유를 설명하는 부분이 끝났다는 표시를 하는 구분자는 없다.

5. 헌장(Charter)

삭제되는 그룹이 아니라면 제안된 모든 그룹은 새로 만들어지는 그룹이
아닐지라도 관련 헌장이 있어야 한다. 헌장은 그룹에서 논할 주제가 뭔지를
알려주는 간단한 설명이다. 헌장에 명시해야 할 사항에 대해서는
han.answers에 정기적으로 투고되는 "▲ 설득력 있는 제안(RFD)을 작성하는
방법"을 참고 하라.

헌장은 다음의 형식을 취한다.

CHARTER: group.name

내용

END CHARTER.

"CHARTER: group.name" 와 "END CHARTER" 라인은 전후에 빈 라인이 있어
야만한다. 각 그룹은 그 자신의 헌장이 있어야 한다. 제안된 그룹 모두에
해당하는 공통적인 사항이 있다면 다음과 같은 형식의 별도의 란을 취한다:

CHARTER: all groups

개별적인 각 그룹 헌장에 "CHARTER: all groups"와 그 설명이 부가될 수
있다. 그러나 "RATIONALE: all groups" 와는 달리 "CHARTER: all groups"는
개별그룹의 헌장을 대신할 수 없다.

6. 중재자 정보

중재자가 중재하는 그룹으로 제안된 그룹은 관련 중재자 정보를 기술하는
부분(section)이 있어야 한다. 그 부분은 다음과 같은 형식을 취한다.

MODERATOR INFO: group.name

내용

END MODERATOR INFO.

그리고 내용에 다음을 명시해야 한다.

Moderator: 중재자 이름 <som...@email.address>

헌장 구분자와 같이 "MODERATOR INFO: group.name" 와 "END MODERATOR INFO"
역시 라인의 앞뒤에 빈 라인이 있어야 한다. 중재자 정보란에는 그룹 중재를
위해 추천된 특정 중재자들에 대한 정보(예를 들면, 그들의 이름, 자격등)을
명시한다.

중재정책은 이란이 아닌 헌장란에 명시한다.

7. 절차(Procedure)

RFD를 이전에 접해보지 않은 사람들을 위해 정형화된 문구로 절차를 간단히
설명하는 란(section)을 두는 것이 RFD의 표준이다. 뉴스그룹 정책에 대해
상대적으로 간단한 소개를 이 란(section)에 한다. 이 란에 써야 할 정형화된
문구는 아래 RFD template에 기술되어 있다. 다른 문구를 사용하려 한다면,
그 새로운 문구가 과연 아래의 정형화된 문구보다 더 좋은지 심사숙고하라.

절차란은 "PROCEDURE:" 헤더로 시작한다.

8. 배포(Distribution)

최종적으로, RFD가 제출되는 모든 뉴스그룹과 메일링 리스트는
"DISTRIBUTION:" 헤더로 시작하는 란에 나열 돼야한다. 아래에 언급된 것과
같이, "Newsgroups: header" 의 총길이는 200문자로 제한된다. 제안이
배포될 메일링 리스트는 물론 RFD가 제출되었다는 것을 알려주는 글을
투고할 뉴스그룹을 추가할 경우 그것들을 이란에 나열하라.

RFD를 메일링 리스트에 보내려고 한다면, 리스트 메일주소만 명시할 것이
아니라 무엇에 관한 메일링 리스트인지를 알려주는 최대 한 줄 또는 두 줄의
간단한 설명과 새 가입자가 가입할 수 있도록 가입주소를 RFD내에 명시하는
것이 흥미를 보이는 잠재적 가입자들에게 더 도움이 될 것이다.

9. 제안 조언자 정보

당신의 서명이 포함되지 않았다면 또는 포함되었다 하더라도, 누가 제안을
발전시키고 있는지 그리고 어느 조언자(group-mentor)가 도와주었는지를
명시할 수 있다.

제안자들은 다음과 같이 나열되어야 한다.

Proponent: 제안자1 이름 <som...@email.address>
Proponent: 제안자2 이름 <som...@email.address>

조언자(mentor)는 다음과 같이 나열되어야 한다.

Mentor: 조언자 이름 <som...@email.address>

10. 서명

메일과 뉴스 프로그램에 의해 자동적으로 흔히 붙는 전통적인 서명란은
4라인을 넘으면 안된다.

서명은 네트웍에서의 전통적 방법에 따라 "-- "을 이용해 본문과 분리한다.

----------------------------------------------------------------------
RFD 제출하기
----------------------------------------------------------------------

RFD를 제출하는 가장 좋은 방법은, han-an...@usenet.or.kr 로 메일을
보내는 것이다. 메일로 보낼 경우 본문 시작부분에 다음을 명시하라.

Newsgroups:
투고할 뉴스그룹
(나열한 그룹 중 중재그룹이 있다면 그것을 명시하라. 당신이 다른
중재그룹의 중재자들과 연락을 하고 RFDs, CFVs 그리고 결과를 교차 투고하는
것에 대한 승인을 미리 얻는다면 진행을 더 빠르게하고 han.announce
중재자를 약간 편하게 할 것이다)

☞ 주(註): RFDs, CFVs는 각각 RFD 와 CFV의 복수임.

Followup-To: 댓글을 제한할 뉴스그룹(일반적으로 han.news.groups이지만
밀접하게 영향을 받는 그룹의 독자들이 원한다면 그 그룹에 교차 투고 할 수
있다)

메일로 보내지 않고 뉴스프로그램으로 직접 투고할 수도 있다.

☞ 주(註): han.announce와 같은 중재그룹(moderated group)에 교차투고할
경우 기사가 즉시 뉴스그룹에 올라가는 것이 아니라 중재자(moderator)의
승인이 이루어진 후 올라가므로 기사가 나타나지 않는다고 재투고 하지
마십시오.

메일로 보내지 않고 뉴스그룹으로 직접 투고하면 han.announce 중재자에게
제대로 전달되지 않을 수도 있다.

한 개의 그룹 제안이라면 제출하는 RFD의 Subject: header는 다음과 같은
형식을 취한다.

RFD: group.name

그 그룹이 중재그룹이라면 그룹 이름 뒤에 "moderated" 을 덧붙인다.

여러개의 그룹 제안이거나 또는 그룹 재구성을 위한 것이라면 "RFD:
group.name.* reorganization" 와 같은 형식을 취한다. 만약 첫번째 RFD가
아니라면 "2nd", "3rd", "4th" 등이 RFD앞에 붙어야 한다."RFD:"는 그것이
정식 제안의 제출임을 즉시 알아볼 수 있게 한다.

다음은 han.announce로 제출되는 제안의 본문 시작부분의 예이다.

Newsgroups:
han.announce,han.news.groups,han.comp.ai,han.comp.ai.edu,han.comp.ai.gen
etic, han.comp.ai.neural-nets,han.comp.ai.vision

han.comp.ai.vision는 중재그룹이다. 그 그룹의 중재자는 그의 메일주소
"vis...@ads.com"를 사용해 교차 투고하는 것을 승인하였다.

Followup-To: han.news.groups

han.announce 에 투고될 기사는 그 그룹에 기사가 나타나기 전에는
han.news.groups 또는 다른 그룹, 메일링 리스트등 어디에도 공개적으로
나타나서는 안된다. han.announce에 기사가 나타난 시간이 그룹 생성
과정에서 사용되는 공식 기준시간이다. 다른 곳에 RFD를 제출하지 않도록
하는 것은 야기될 수 있는 혼란을 방지하기위한 것이다.

RFD가 han.announce에 나타난 후, 투고를 요청했던 그룹외 다른 곳에 추가
배포를 원한다면 메일 복사본이 아닌 han.announce에 나타난 그대로 배포할
수 있고 다른 포럼에 가공하지 않은 원본 메시지 그대로 투고할 수 있다.
한층 더 좋은 방법은, 특정 주제에 관한 뉴스그룹의 생성 또는 변경을 위한
제안이 han.announce에 투고되었다는 것과 그 기사에 대한 링크 그리고
han.news.groups에서 토론이 개최되고 있다는 것을 알려주는 간단한 글을
투고하는 것이다. 예를 들면:

우표수집에 관한 뉴스그룹(han.rec.collecting.stamps)을 생성하고자 하는
정식 제안이 han.announce에 <news:855.9...@isc.org> 와 같이
투고되었습니다.

이 제안을 개선하기 위한 여러분의 의견을 환영합니다. han.news.groups에서
토론을 할 것이고 약 3주에서 4주후에 투표가 있을 예정입니다.

----------------------------------------------------------------------
RFD Template
----------------------------------------------------------------------

REQUEST FOR DISCUSSION (RFD)
unmoderated group group.name

이 글은 뉴스그룹 group.name 생성을 위한 공식 토론요청(RFD)입니다. 이는
투표요청이 아니므로 지금 투표할 수 없습니다. 자세한 사항은 아래를
읽어보시기 바랍니다.

CHANGES from previous RFD:

[ 이번 RFD가 두번째 이후라면 첫번째 RFD에서 변경된 부분을 여기에
기술하라. 변경된 부분이 없다면 이 부분을 삭제하라 ]

Newsgroup line:
group.name 그룹에 대한 간단한 설명(한글).
group.name 그룹에 대한 간단한 설명(영어).

RATIONALE: group.name

[ 그룹을 생성 또는 삭제하고자 하는 이유 ]

CHARTER: group.name

[ 그룹에서 논할 주제가 뭔지를 알려주는 간단한 설명을 이 부분에
기술하라 ]

END CHARTER.

MODERATOR INFO: group.name

Moderator: 중재자 이름 <som...@email.address>

[ 중재에 관한 사항을 이 부분에 기술하라. 제안한 그룹이 중재그룹이
아니라면 이 부분을 삭제하라 ]

END MODERATOR INFO.

PROCEDURE:

이 글은 토론요청이며 투표요청이 아닙니다. 지금 단계에서 제안된 그룹의
잠재적 문제가 드러나고 해결될 것입니다. 토론기간은 이 제안에 대한 첫번째
RFD가 han.news.groups에 투고된 시점으로부터 최소한 21일간 지속될
것입니다. 토론 결과 투표요청을 하는 것이 문제없다면 중립적 투표관리자에
의해 투표요청(CFV)이 투고될 것입니다. CFV가 투고되기전까지는 투표하려고
시도하지 마십시오.

이 제안에 대한 모든 토론은 han.news.groups에 투고돼야 합니다.

DISTRIBUTION:

[ RFD를 배포할 뉴스그룹과 메일링 리스트를 이 부분에 명시하라 ]

Proponent: 당신의 이름 <yo...@email.address>

----------------------------------------------------------------------
Sample RFD
----------------------------------------------------------------------

Newsgroups:
han.announce,han.news.groups,han.rec.travel.ered-luin,han.rec.travel.mor
dor,han.rec.travel.rivendell,han.rec.travel.numenor,han.rec.arts.books.t
olkien

Followup-To: han.news.groups

han.rec.travel.mordor는 중재그룹입니다. 그 그룹의 중재자는 그의 메일주소
"som...@email.address"을 사용해 교차 투고하는 것을 승인하였습니다.

REQUEST FOR DISCUSSION (RFD)
unmoderated group han.rec.travel.shire
moderated group han.rec.travel.valinor
unmoderated group han.rec.travel.blue-mountains (renames
han.rec.travel.ered-luin)
unmoderated group han.rec.travel.mordor (unmoderates existing group)
moderated group han.rec.travel.rivendell (moderates existing group)
REMOVE han.rec.travel.numenor (renamed to han.rec.scuba.locations)

이 글은 han.rec.travel.* 계층 그룹의 재구성을 위한 공식
토론요청(RFD)입니다. 이는 투표요청이 아니므로 지금 투표할 수 없습니다.
자세한 사항은 아래를 읽어보시기 바랍니다.

CHANGES from previous RFD:

[ 이번 RFD가 두번째 이후라면 첫번째 RFD에서 변경된 부분을 여기에
기술하라. 변경된 부분이 없다면 이 부분을 삭제하라 ]

Newsgroup lines:
han.rec.travel.shire Shire 와 주변지역의 여행에 관한 이야기.
han.rec.travel.valinor Valinor 여행에 관한 이야기. (Moderated)
han.rec.travel.blue-mountains Blue Mountains 여행에 관한 이야기.
han.rec.travel.mordor Mordor 여행에 관한 이야기.
han.rec.travel.rivendell Rivendell여행에 관한 이야기. (Moderated)

RATIONALE: han.rec.travel.shire

이 부분에 han.rec.travel.shire 생성 이유를 명시하라. 제안한 모든 그룹의
생성 이유가 동일하다면 이 부분을 생략하고 다음과 같은 하나의
생성이유만을 가질 수도 있다.

RATIONALE: all groups

이것으로 제안된 모든 그룹의 개별 제안이유(rationale)를 대신할 수 있다.
제안 이유를 특별히 별도로 명시해야 할 그룹이 있다면 이 두 가지를 조합할
수도 있다. 중요한 것은 제안된 그룹은 개별 그룹에 해당하는 rationale이든
모든 그룹에 공통적인 "all groups" rationale 이든 둘 중 적어도 하나는
반드시 있어야 한다.

CHARTER: han.rec.travel.shire

이 부분에 han.rec.travel.shire의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.valinor

이 부분에 han.rec.travel.valinor의 헌장을 기술한다.
han.rec.travel.valinor는 중재그룹으로 제안되었기 때문에 상대적으로 더
중요할 것이다. 그러므로 헌장 내에 다음과 같은 하위 부분을 취할 것이다.

Moderation policies:

이 부분에 중재자가 지켜야 할 중재 정책을 기술하라.

END CHARTER.

MODERATOR INFO: han.rec.travel.valinor

Moderator: 중재자 이름 <som...@email.address>

중재그룹은 위와 같이 "Moderator: line" 을 취하는 MODERATOR INFO 란이
있어야 한다. 추천된 중재자에 대한 사항을 기술하기 위해 부가적 설명을
덧붙일수 있다. 중재 정책은 이란이 아닌 그룹헌장내에 기술해야 한다.

END MODERATOR INFO.

CHARTER: han.rec.travel.blue-mountains

이 부분에 han.rec.travel.blue-mountains의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.mordor

이 부분에 han.rec.travel.mordor의 헌장을 기술한다.

END CHARTER.

CHARTER: han.rec.travel.rivendell

이 부분에 han.rec.travel.rivendell의 헌장을 기술한다. 제안된 모든 그룹은
관련 헌장이 있어야 하고 각 그룹은 그 자신의 헌장이 있어야 한다("all
groups" 로 이를 대체할 수 없다). 그룹이름 변경 또는 관리상태 변경 제안
역시 마찬가지이다.

END CHARTER.

MODERATOR INFO: han.rec.travel.rivendell

Moderator: 중재자 이름 <som...@email.address>

END MODERATOR INFO.

CHARTER: all groups

이 부분은 위의 모든 그룹에 공통적으로 적용되는 부가적 헌장란이다. 이
부분은 선택사항(optional)이며 이것으로 위의 헌장을 대신할 수 없다.그룹이
생성될 때 이 부분은 각 그룹 생성 기사안의 개별 헌장에 부가될 것이다.

END CHARTER.

PROCEDURE:

이 글은 토론요청이며 투표요청이 아닙니다. 지금 단계에서 제안된 그룹의
잠재적 문제가 드러나고 해결될 것입니다. 토론기간은 이 제안에 대한 첫번째
RFD가 han.news.groups에 투고된 시점으로부터 최소한 21일간 지속될
것입니다. 토론 결과 투표요청을 하는 것이 문제없다면 중립적 투표관리자에
의해 투표요청(CFV)이 투고될 것입니다. CFV가 투고되기 전까지는 투표하려고
시도하지 마십시오.

이 제안에 대한 모든 토론은 han.news.groups에 투고되어야 합니다.

DISTRIBUTION:

이 RFD는 다음 뉴스그룹에 투고되었습니다:

han.announce, han.news.groups,
han.rec.travel.ered-luin, han.rec.travel.mordor,
han.rec.travel.rivendell, han.rec.travel.numenor,
han.rec.arts.books.tolkien

다음 메일링 리스트에도 배포되었습니다:

tolk...@e-mail.address(톨키언의 언어학적 토론)
메일링 리스트 가입 주소: tolklang...@e-mail.address

Proponent: 제안자1 이름 <som...@email.address>
Proponent: 제안자2 이름 <som...@email.address>

☞ 주(註): 이 문서를 다 읽었음에도 제안을 하는데 어려움을 느끼신다면
han.news.groups에 도움을 요청하십시오.

참고:
(1) 이 문서에 사용된 "☞ 주(註):" 표시 다음의 설명은 독자의 이해를
돕기위해 역자가 추가한 내용입니다.
(2) 이 문서 시작부분의 버전번호는 역자가 문서를 수정할경우 올라갑니다.

------=_NextPart_000_0093_01C2B50A.81719440
Content-Type: message/rfc822;
name="=?euc-kr?B?oeMgvLO15rfCIMDWtMIgwaa+yChSRkQpwLsgwNu8usfPtMIguea5/S5ud3M=?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="=?euc-kr?B?oeMgvLO15rfCIMDWtMIgwaa+yChSRkQpwLsgwNu8usfPtMIguea5/S5ud3M=?="

From: "Ahn Byong-Gil" <sanc...@softhome.net>
Newsgroups: han.answers,han.news.groups,han.news.users
Followup-To: han.news.groups
Subject: ▲ 설득력 있는 제안(RFD)을 작성하는 방법
Date: Fri, 3 Jan 2003 21:37:31 +0900
Lines: 195
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

이 글은 news.groups 에 정기적으로 투고되는 "How to Write a Good
Newsgroup Proposal" 를 저자의 동의를 얻어 번역한 것입니다.

저 자: Una Smith <una....@yale.edu>
번역자: 안병길<sanc...@softhome.net>
버 전: 1.13B

***********************************
설득력 있는 제안을 작성하는 방법
***********************************

새로운 뉴스그룹 생성을 제안하는데 있어 가장 중요한 것은 글을 읽는 이가
거부 반응을 일으키지 않고 제안된 그룹에 가입하도록 유인할 수 있는
간결하고 설득력 있는 토론요청(RFD)을 작성하는 것이다. 그러한 목적 달성을
돕기 위해, 뉴스그룹 생성과정에 참여하면서 쌓은 많은 경험과, 우리 자신의
많은 성공적 RFD제출 경험을 토대로 한 다음의 조언을 하는 바이다.

서투른 RFD는 RFD내에 속하지 않는 항목들을 포함하곤 한다. 바람직한 RFD는
그룹헌장, 제안이유, 중재그룹(moderated group)이라면 중재정책, 메일링
리스트와의
연계여부등만을 포함해야 한다. 그룹에서 논할 주제의 과거 역사(history)는
RFD 항목에 속하지 않는다; 별도 기사로 간단한 설명을 투고할 수는
있다(news.announce.newgroups에 투고해서는 안된다)

☞ 주(註): "주제의 과거 역사(history)"는 과거에 어떤 사람들이 그 주제로
토론을 했으며, 어떻게 결정 되었는지등의 과거에 이루어진 제반 사항을
의미합니다.

RATIONALE(제안이유):

제안이유(rationale)는 왜 그룹 생성이 필요한지를 간단하고 설득력있게
설명하는 부분이다. 다른 유즈넷 그룹 또는 유즈넷과 관련없는 주제 자체의
가치에 대한 설명은 피해야 한다. 제안된 그룹과 현재 존재하는 다른
그룹들과의 관계를 설명하는데 집중하라. 제안된 그룹이 이미 존재하는 다른
그룹과 충돌하거나 중복된다면, 왜 새로운 그룹이 필요한지 또는 가치가
있는지를 정당화하고 왜 다른 그룹이 목적에 부합하지 않은지를 설명하라.
다른 사람들을 불쾌하게 하거나 감정을 상하게 하지 않도록 주의하라; 만약
당신이 다른 그룹의 독자들을 불쾌하게 하거나 적으로 만든다면, 그들은 당신
제안에 반대표를 던지고 다른 투표자들이 반대표를 던지도록 유도함으로서
당신의 그룹생성을 최대한 방해할지 모른다. 그들이 정말로 그러길 원한다면
그들이 이길 가능성이 높다. 그러한 거부 반응을 일으킬 것이 확실한 설득력
약한 제안이유에는 다음과 같은 것들이 있다.

당신 이웃의 부정

X 그룹은 죽었다, 그러므로 나는 Y로 다시 시작하기를 원한다.
X 그룹은 Y보다 사회적 역할을 수행하는데 미흡하다.
X 그룹은 Y보다 가치가 적다.

정치적 정의에의 호소

Y 는 소수이다. 뉴스그룹이 생성되면 그들의 평등권이 향상될것이다.
Y 는 불합리한 생각이다. 뉴스그룹이 생성되면 정의가 실현될것이다.
Y 사람들은 특별하므로 그들의 장소가 필요하다.

명백한 게으름의 인정/도둑질

Y2 그룹은 부적절한 투고를 제어하기 위해 중재그룹이 되어야 한다.
그러나 그것은 노동이다. 따라서 그 대신 나는 Y를 원한다.
Y2 그룹은 내가 별로 중요하지 않다 생각하는 기사들로 가득차있다.
그러므로, 나는 좋은 기사들만을 Y로 추출해 내고 싶다.
Y2 메일링 리스트는 나에게는 너무 붐빈다. 그러나, 뉴스그룹과의
연계는 원치않는다. 그러므로 나는 Y그룹을 만들어서 메일링
리스트 독자들을 Y그룹으로 끌어오기를 원한다.
Y2 메일링 리스트는 죽었다. 그러므로 나는 독자들을 리스트와
분리된 또는 연계된 Y 그룹으로 끌어오기를 원한다.
a 메일링 리스트는 내가 운영하기에 너무나 고된 일이다.
a 메일링 리스트는 독자들이 발견하기가 너무 어렵다.

☞ 주(註): "도둑질"은 Y2 그룹의 기사나 메일링 리스트의 독자들을 빼오는
행위를 일컬음(역자)

당신의 동기가 위의 수치수러운 범주 내에 속할지 모른다. 또는 당신의
동기가 순수하고 고귀할지도 모른다. 좋지 않은 동기의 인정은 당신에 대한
거부감을 일으킬 것이다. 반면, 좋은 동기는 다른 사람이 당신의 의도를
이해할 수 있게 할 것이다. 하지만 이해할 수 있을 뿐 그 밖의 것을 기대할
수 없다.

당신의 동기는 무시하고 대신 당신이 제안한 그룹을 생성해야 할 강하고,
합리적 이유를 독자들에게 확신 시킨다면 우리는 당신의 동기가 무엇인지
개의치 않을 것이며 RFD를 읽는 독자들 역시 마찬가지 일 것이다. 유즈넷
또는 메일링 리스트에 많은 독자가 있다는 증거를 보이거나 또는 다른
추세로부터 합리적 추론을 하는 것이 설득력있는 설명이다.

Y 주제는 A, B, 그리고 C그룹에서 논의되므로 독자가 존재한다.
Y 에관한 그룹이 생성되면 아마도 그들은 그 그룹을 이용할 것이다.
Y 그룹은 너무 붐비므로 그 그룹의 독자들은 그룹을 나누기를
원한다.
Y 그룹의 기사는 같은 범주가 아닌 둘 또는 그 이상의 다른 타입의
기사들이다.
Y 메일링 리스트는 너무 붐비므로 연계된 뉴스그룹이 필요하다.
그렇지 않으면 독자들이 떠날 것이다.
Y 메일링 리스트는 너무 붐빈다. 독립적인 Y 그룹은 리스트의 붐빔을
완화 시킬 것이다.
Y 메일링 리스트에는 수천명의 구독자가 있다. 이는 같은 주제의
뉴스그룹이 생성되면 인기가 있을거라는 것을 암시한다.
Y 전문적인 집단/취미 그룹/공동체는 수천명의 회원을 가지고 있다.
그들 중 많은 사람들이 그 주제로 뉴스그룹이 생성되면
참여할 것이라고 말한다.

가능하다면, 그 주제를 직접적으로 다루는 메일링 리스트를 예시하고, 그
리스트의 가입자 수와 리스트의 대략적인 하루 메시지 수를 제시하라.이
자료는 종종 메일링 리스트 서버에서 자동적으로 이용가능하거나 리스트
운영자가 기꺼이 제공할지 모른다. 당신 제안과 대략적으로 같은 주제의
메일링 리스트가 존재한다면, 이러한 객관적 정보를 제시하는 것이 중요하다.
다시 말하지만, 메일링 리스트의 운용자 또는 구독자를 적으로 만들지 않도록
주의하라; 그들은 그 메일링 리스트에 대한 그들 자신의 계획을 가지고
있을지 모르고 당신의 RFD를 어떤 면에서 방해요인으로 간주할지 모른다.
메일링 리스트에 직접적으로 영향을 미치는 RFD를 시작하기 전에 메일링
리스트 운영자의 허가를 얻는 것이 좋은 태도이다.

일반적으로, 너무 붐비는 뉴스그룹은 하루에 200개 이상의 기사가 투고되며
유즈넷 뉴스그룹으로 확장되기에 충분히 성숙한 메일링 리스트는 하루에
50개이상의 기사를 가지고 있거나 1000명 이상의 구독자를 가지고 있다.
관련있는 뉴스그룹 또는 메일링 리스트의 사용현황에 대한 공정하고 정확한
자료를 제공하는 것은 당신 제안에 많은 도움이 될 것이다. 추측하지 마라.
정직하라. 만약 당신의 제안을 이와 같은 근거로 합리화 시킬 수 없다면,
당신의 제안이 관련 메일링 리스트의 구독자도 별로 없고 기사수도 많지
않음에도 불구하고 왜 장점을 가지고 있는지를 설명하라. 예를 들면, 현재는
유즈넷상에 독자가 존재하지 않지만 당신이 제안한 주제의 뉴스그룹을
생성하면, 유즈넷의 다른 추세와 더 큰 세계의 추세로 미루어 볼 때 많은
독자들이 생길 것이라는 것을 자신있게 주장할 수 있을지 모른다. 창조적이고
매우 정직해라. 좋은 아이디어를 위해 다른 제안들을 살펴봐라.

☞ 주(註): 위의 구체적 수치는 한글그룹 기준과 다를 수 있음(역자)

헌장

헌장 안에는 그룹의 일반적 주제에 대한 간단한 설명은 물론, 그룹에서
환영받을 기사의 유형을 언급하는 것이 좋다. 환영받을 것처럼 보이나 실은
부적절한 유형에 대해 언급하는 것 역시 좋을 수 있다.

예를 들면, 소프트웨어 드라이버의 디자인과 구조에 관해 토론할 그룹을
만들려고 하는 사람들은 염가판매로 구입한 이름없는 중고 컴퓨터의 특정
드라이버를 찾는 컴퓨터 소유자들의 막무가내식 요청기사는 환영하지 않을지
모른다. 그들은 그룹 헌장에 "드라이버 요청 사절" 이라고 구체적으로
명시할지 모른다.

그 주제가 얼마나 가치있는지 또는 그룹 생성이 왜 (유즈넷 세계가 아닌)실제
세계에서 사회적 또는 정치적 목적을 진보시키는지에 관한 가치적 언급을
헌장 내에 포함해서는 안된다. 헌장은 그룹의 예견된 상황과 목적에 대한
공식적 설명이며 제안자(당신)과 그 그룹의 미래의 독자와의 비공식 계약,
그리고 그룹에 대한 가장 중요한 참고 자료(그룹 FAQ보다 한층 중요한)이기
때문에, 지금 부터 10년이 지나도 여전히 같은 의미를 가질 수 있도록
명확하고 완전하게 씌어져야 한다.

헌장의 공통적인 문제는, 뉴스그룹은 일반적으로 범 세계적 흥미를 가질 수
있는 주제를 다루어야 한다는 것이다. 그러므로, 예를 들면, 특정 국가의
스포츠 팀에 관계되는 그룹의 제안은 "big 8"에 속하지 않는다. 아주 강력한
생성근거 조차도 이러한 유형의 제안을 정당화 시킬 수 없다. 그러나 두 가지
훌륭한 해결 방법이 있다: 그 주제를 포함 할 수 있도록 세계 어디에나
적용할 수 있는(일반 스포츠와 같이) 추상적 수준으로 헌장을 수정하거나
당신 나라 또는 지역 계층 내에서 뉴스그룹을 생성하는 방법을
조사하라.(예를 들면, 한국의 han.*, 미국의 us.*, 캐나다의 can.*,
독일어권의 de.*)

☞ 주(註): "한국의 han.*" 은 역자가 추가한 것임.

중재자(Moderator):

제안된 그룹이 중재그룹(moderated group)이어야 한다면, 이유를 간단히
설명해야 한다. 또한, 추천된 중재자의 이름과 이메일 주소를 적고, 자격과
관련 의무를 개략적으로 나열하라. 일반적으로 중재자의 의무는 헌장에
부합하지 않은 기사를 거절함으로서 그룹 헌장을 수호하는 것이다.

최종 조언:

명심하라, 당신의 목적은 (1) 가장 적절한 뉴스그룹을 제안하는 것이고, (2)
다른 사람들이 당신 제안을 지지하도록 그들을 설득하는 것이다. 그러므로
RFD를 쓰는 것은 많은 시간의 주의 깊은 사고와 연구를 필요로 한다. 그러나
많은 시간의 주의 깊은 사고와 연구를 했음에도 불구하고, 다른 사람들은
당신의 목적 달성 방법과 다른 생각을 가지고 있거나 그들 자신이 더 좋은
목적을 가지고 있다고 생각할지도 모른다. 그 비평은 종종 옳다. 그러므로
그들의 의견과 왜 그들이 그러한 의견을 냈는지를 시간을 두고 신중히
생각하라. 무엇보다도, 인내를 가지고 이성을 잃지 마라.

그룹 조언자들로부터 받게 될지도 모를 의견은 당신 제안을 방해하고자하는
의도가 아니고 news.groups에서 정밀한 공개 검증을 받기 전에 최대한
개선되었는지를 확실히 하고자 하는 것이다.우리로부터 받는 피드백에
방어적으로 대응하려 하지 마라: 그것은 도움을 주고자 하는 것이다. 이해가
안가거나 우리의 의견이 명백히 당신 제안 전체를 거절하는 것처럼 보인다면
자세한 설명을 요구하라. 우리는 당신 RFD내의 특정 주장을, 사실상 진실이
아니거나, 논리적 결함이 있거나, 당신 제안에 결코 이롭지 않은(정말, 이런
경우가 발생한다) 주장으로 간주함으로써 그 부분에 대해 거절할지는 모르나,
결코 당신 제안 자체를 거절하지는 않는다.

마지막으로, RFD의 내용, 구조, 명료성, 문법, 철자를 주의깊게 살펴봐라.

행운이 있기를...

참고:
이 문서 시작부분의 버전번호가 올라갔다면 이는 역자가 문서를
수정하였음을 의미합니다.

------=_NextPart_000_0093_01C2B50A.81719440
Content-Type: message/rfc822;
name="=?euc-kr?B?oeMgwK/B7rPdILS6vbqx17fsIMDMuKe/oSC068fRIMH2xKcubndz?="
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="=?euc-kr?B?oeMgwK/B7rPdILS6vbqx17fsIMDMuKe/oSC068fRIMH2xKcubndz?="

From: "Ahn Byong-Gil" <sanc...@softhome.net>
Newsgroups: han.answers,han.news.groups,han.news.users
Followup-To: han.news.groups
Subject: ▲ 유즈넷 뉴스그룹 이름에 대한 지침
Date: Fri, 3 Jan 2003 21:36:42 +0900
Lines: 157
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

이 글은 news.announce.newusers 에 정기적으로 투고되는 "Guidelines on
Usenet Newsgroup Names"를 번역한 것입니다. 이 원칙은 한글그룹에도
적용되므로 RFD작성시 참고 하시기 바랍니다

저 자: David.W...@bnr.co.uk
번역자: 안병길 <sanc...@softhome.net>
버 전: 1.22C

Archive-name: usenet/creating-newsgroups/naming/part1
Last-change: 13 Jun 1995 by netan...@deshaw.com (Mark Moraes)
Changes-posted-to: news.misc

***********************************
유즈넷 뉴스그룹 이름에 대한 지침
***********************************

이 문서는 유즈넷 뉴스그룹 comp", "humanities", "misc", "news", "rec",
"sci", "soc" "talk" 계층에서 새로운 뉴스그룹을 생성하고자하는 사람들을
위한 기본지침서이다.

☞ 주(註): 각 계층에서 다루는 주제는 이 문서의 맨 아래를 참고 하시기
바랍니다.

유즈넷 뉴스그룹 이름은 조립적이고, 계층적이며, 분류적이나 제한적이지
않다. 이러한 속성은 유즈넷 이용자들이 원하는 그룹을 쉽게 찾고 뉴스서버
운영자가 그의 서버 이용자들을 위해 시스템을 관리하는 것을 돕기 위한
것이다. 이 용어들 각각에 대한 개념을 이해함으로써, 당신은 새로운
뉴스그룹에 적합한 이름을 선택하는 방법을 이해할 수 있을 것이다.

조립적

"rec.pets.dogs"와 같이 뉴스그룹 이름은 점에 의해 분리된 몇 개의
부분들로 구성되어 있다. 각 부분은 최대 14자까지 허용되며
순수하게 영문자만으로, 아니면 적어도 한 개의 영문자를 가진, 숫자
또는 "+" 와 "-"로 구성 되야 한다.

계층적

이름은 명확한 계층으로 구성 되야 한다 - 예를 들면, 컴퓨터 관련
모든 그룹은 comp.내 속한다. sci.physics 와 comp.sys.sun 에서와
같이 기본이름에 하위부분을 추가함으로서 두번째, 세번째 그리고 더
하위의 계층으로 확장된다. 첫번째부분(sci 또는 comp)이 가장 넓은
개념이며 하위로 갈수록 더 구체적이다. 마지막부분으로 실제
그룹이름을 완성한다. 각 부분은 레벨이 다른 것을 의미하므로, 같은
레벨의 단어들은 하이픈을 사용해서 한 부분에 포함된다 - 예를
들면, misc.invest.estate.real 대신 misc.invest.real-estate와
같이 구성해야 하며, 이것은 real이 estate의 한 종류라는 것을
의미한다.

분류적

분류학은 사물을 분류하는 학문이다 - 예를 들면, 생물학에서 종의
분류, 도서관에서 책의 분류와 같은 것을 말한다. 그룹 이름은
주제를 분야와 계층으로 분류한다. 이미 존재하는 그룹 이름과
조화를 이루어야 하고 앞으로의 성장 가능성을 고려해야 하므로
그룹이름을 옳게 분류하는 것은 쉽지 않다.

비 제한적

뉴스그룹 이름은 제한적이지 않고 포괄적이다. 즉, 투고하기에 더
적합한 이름의 그룹이 없다면 뉴스그룹 이름은 기사가 투고될 곳을
결정한다. 이름은 그룹의 정확한 한계를 결정하지 않으며 그룹 이름
개념에 정확하게 일치하지 않는 주제의 기사일지라도 이를 금지하지
않는다.

이용자 돕기
그룹이름은 이용자가 그룹의 기사를 읽어보지 않고 그룹의 성격을
파악할 수 있는 유일한 단서일 경우가 종종 있다. 현재 뉴스그룹은
1300개가 넘으며 alt 에서 zer까지 다른 뉴스계층들을 모두 포함하면
10,000개가 훨씬 넘는다. 흥미있는 그룹을 찾기 위해 모든 그룹의
기사를 읽는 것은 불가능하다. 비슷한 예로, 아주 인기있는
그룹일지라도 모든 유즈넷 이용자의 1%정도가 구독할 뿐이다.
그러므로 뉴스그룹 이름은 그룹을 읽지 않는 99%의 이용자에게
의미를 가질 수 있는 이름이어야한다. "이 그룹은 무엇에 관한
그룹이냐?" 와 같은 기사가 올라오지 않을 정도로 뉴스그룹 이름은
충분히 명확해야 하며 그룹의 주제에 관해 좀 더 알고 싶어하는
사람들이 그룹의 목적을 알고 기사를 읽기 시작하며 가입할 수
있도록 해야 한다. 또한, 유즈넷은 세계적이고, 유즈넷에는 서로
다른 다양한 문화권의 이용자들이 있다는 것과, 그들 중 많은
사람들이 영어를 모국어로 하지 않는다는 것을 명심하라.

그러한 이유로 다음 지침은 이름 선택에 있어 어느 정도 강력한
지침이다:

- 가능한한 유사한 주제들을 같은 계층만에 함께 그룹화하라. 그래야
관련 주제를 찾는 사람들에게 그것을 어디에서 찾을 수 있을 지에
대한 실마리를 제공할 것이다. 정확성을 이유로 많은 잠재적
구독자가 보지 않을 다소 모호한 곳에 그룹을 배치하는 것을
고집하기 보단 대략적으로 부합하는 곳에 위치시키는 것이 더 좋은
경우가 종종있다.

- 매우 구체적인 그룹을 생성하기 전에 일반적인 그룹을 먼저
생성하라.

- 이름을 단축하거나 모호한 이름을 사용하지 마라. 이름을 단축하면
다른 사람들은 전혀 다른 뜻으로 받아들 일수 있다. 특히 영어가
그들의 모국어가 아닐 경우에는 더욱 그러하다. 현재, 유즈넷
전송제한은 이름의 각 부분을 최대 14자로 한정한다. 이 제한 때문에
때때로 그룹 이름을 단축시켜야만 할 경우가 있다. 그와 같은
경우에는, 14자리 안에서 가능한한 의미있는 단축어를 만들어라.

- 그룹 이름에 영어 단어를 사용하라. 그룹의 기사는 그 그룹에
적합한 어떤 언어를 사용해도 좋으나 그룹 이름에는 영어를 사용해야
한다. 왜냐하면 영어는 거의 모든 유즈넷 이용자가 이해할 수 있는
유일한 언어이기 때문이다.

뉴스서버 운영자 돕기
현재 어떤 뉴스서버도 10,000개의 뉴스그룹을 받아서 모든 기사를
수주일 동안 보관할 수 있는 디스크 공간을 가지고 있지 않다.
그러므로 뉴스서버 운영자들은 어떤 그룹의 기사를 받고 언제까지 각
그룹의 기사를 보관할 지에 대해 신중해야만 한다. 그러나 아주 많은
그룹이 존재하기 때문에 그들은 각각의 그룹을 개별적으로 관리할 수
없다. 그러므로 그들은 뉴스그룹의 계층적 속성을 이용하며
계층 내에서 뉴스를 제어한다. 예를 들면, 어떤 운영자는 comp계층의
기사를 rec 계층의 기사보다 오래 보관할지 모른다. 또 어떤 이는
그의 서버 이용자 중 아무도 comp.sys.ibm.* 계층의 그룹을 이용하지
않기때문에 comp.sys.ibm.* 계층을 받지 않기로 결정할지 모른다.
이것은 계층화가 아주 중요하며 왜 새로운 그룹이 가능한한 현재의
계층과 조화를 이루어야 하는지에 대한 또 다른 이유이다. 일부
제안자는, 특정 그룹을 원하지 않는 뉴스서버 운영자가 그 그룹을
개별적으로 배제 할 수 있다고 가정하고 이 원칙을 지키지 않아도
된다고 생각한다. 그러나 그것은 틀린 생각이다. 이용자가 읽지 않는
그룹의 기사를 받는 것은 디스크 공간을 줄이며 그들이 정말로
필요로 하는 그룹의 기사 만기일을 단축시킨다.

다음은?
새로운 뉴스그룹의 이름을 짓기 전에 이 지침에 관해 생각하라.

유즈넷의 규모가 훨씬 작았던 과거 또는 현재 alt와 같은 통제되지
않는 다른 계층에서 일어난 잘못된 이름짓기는 더 이상 일어나서는
안된다는 것을 명심하라. 아니, 실수를 안하는 것에서 한발 더
나아가 지금은 과거의 실수를 수정할 때이다.

이 문서를 다 읽은 이 시점에서 여전히 조언이 필요하다면
<group-...@uunet.uu.net> 로 메일을 보내라.

☞ 주(註): 월드와이드 그룹인 Big8 의 각 계층에서 다루는 주제(역자)

comp(computer) : 컴퓨터 소프트웨어와 하드웨어에 관련된 주제.
humanities : 문학, 철학, 인문학에 관련된 주제.
misc(miscellaneous) : 다른 그룹에 속하지 않는 주제.
news : 뉴스그룹 자체에 관련된 주제.
rec(recreation) : 오락, 여가, 취미와 관련된 주제.
sci(science) : 과학이나 수학에 관련된 주제.
soc(society) : 사회과학 또는 종교, 문화, 역사, 사회와 관련된 주제.
talk : 정치, 종교 기타 활발한 논쟁을 야기하는 주제.

해당 계층의 유즈넷 이용자들이 토론을 통해 계층을 생성, 변경,
재구성하므로 계층의 개념이나 분류는 지역이나 나라마다 다를수 있습니다.
한글그룹 계층에 대해서는 han.answers 에 정기적으로 투고되는 "han
newsgroup hierarchy"를 참고 하시기 바랍니다.

참고:
이 문서 시작부분의 버전번호가 올라갔다면 이는 역자가 문서를
수정하였음을 의미합니다.