기술 자료 워크플로우가 발전함에 따라, 커뮤니티 기여자에게 콘텐츠 요청을 할당할 수 있는 시점에 대한 명확한 경계를 만들고자 합니다. 저희는 여러분의 전문성을 매우 소중하게 생각합니다. 커뮤니티 내의 오랜 제품 지식은 매우 가치가 있습니다. 동시에, 제품 출시 및 여러 부서와의 협업과 관련된 콘텐츠 작업은 Mozilla의 전 세계 사용자 기반을 지원하기 위해 정확하고 유용한 콘텐츠를 시기적절하게 제공할 수 있도록 명확한 소유권, 예측 가능한 일정, 체계적인 조정을 필요로 합니다. 이러한 가드레일은 다음을 위해 설계되었습니다: * 출시 일정 보호 * 소유권 및 책임 명확화 * 건전한 협업 유지 * 불분명한 기대로 인한 마찰 방지 이러한 변경 사항은 직원과 기여자 간의 지속 가능한 협업을 만들기 위한 것입니다. __TOC__ =시작하기 전에= 진행하기 전에, 저희는 사소한 업데이트와 주요 업데이트에 대해 다른 워크플로우를 따른다는 점에 유의해 주십시오. *각 카테고리에 해당하는 것이 무엇인지 이해하려면 [[Minor vs major changes]]를 검토하고, 사소한 업데이트를 직접 제출하는 방법에 대한 지침은 [[Submit a minor update in a Knowledge Base article]]을 참조하십시오. *Bugzilla를 통한 주요 업데이트 요청 제출에 대해서는 [[How to submit a SUMO Knowledge Base content request]]를 검토하십시오. 이러한 가드레일은 '''지원 문서에 대한 새로운 콘텐츠 또는 주요 업데이트 요청'''에만 적용됩니다. 다른 문서 카테고리나 기술 자료에 직접 제출된 지원 문서의 사소한 수정에는 적용되지 않습니다. =새로운 콘텐츠 요청 및 주요 업데이트를 위한 콘텐츠 프로세스= 다음 프로세스는 Bugzilla를 통해 제출된 새로운 콘텐츠 요청 및 주요 업데이트에 적용됩니다. 이 제출 프로세스는 기여자뿐만 아니라 Mozilla 직원에게도 적용됩니다. ;[[Image:major workflow]] * 1단계: '''제출''' ;모든 주요 콘텐츠 업데이트는 Bugzilla 티켓을 통해 제출해야 합니다. * 2단계: '''분류 및 할당''' **'''분류:''' 모든 새로운 콘텐츠 요청은 우선순위와 할당을 결정하기 위해 분류 과정을 거칩니다. 요청이 아래 섹션에 설명된 할당 기준과 일치하는 경우 기여자의 참여를 권장합니다. 참여 의사를 밝히려면 Bugzilla 티켓에 직접 댓글을 달아주세요. **'''할당:''' CX 팀은 제품 소유권과 관계없이 전체 콘텐츠 요청 프로세스를 책임지며, 버그를 기여자/기술 작가에게 할당합니다. CX 직원이 할당을 확인할 때까지 초안 작성을 시작하지 마십시오. 할당이 완료되면 커뮤니티 관리자 또는 다른 CX 팀원이 프로세스를 안내해 드립니다. **'''예상 시간:''' 분류는 매주 수행되며, 기여자는 최초 요청 후 영업일 기준 5일 이내에 응답을 받을 수 있습니다. * 3단계: '''콘텐츠 제작''' **'''콘텐츠 초안:''' 티켓을 주의 깊게 검토하여 요청, 범위 및 예상 결과를 완전히 이해하십시오. 제품 팀에서 초안을 제공한 경우 이를 시작점으로 사용하십시오. 그렇지 않은 경우 Google Docs에서 콘텐츠 초안 작성을 시작할 수 있습니다. Google Docs를 사용할 수 없는 경우, 검토를 위해 초안을 Bugzilla 티켓에 직접 첨부할 수 있습니다. 초안 링크를 Bugzilla 티켓에 게시하고 이해 관계자가 댓글을 달 수 있도록 문서 권한을 설정해야 합니다. **'''콘텐츠 승인:''' 요청자 또는 제품 이해 관계자와 긴밀히 협력하여 문서가 완전하고 정확한지 확인하십시오. 작업을 완료하는 데 필요한 정보가 누락된 경우 Bugzilla의 "정보 요청..." 옵션을 사용하여 추가 세부 정보를 수집하십시오. **'''에스컬레이션:''' ***요청자로부터 필요한 정보를 얻을 수 없는 경우, CX 제품 지원 관리자 또는 커뮤니티 관리자에게 지원을 요청하십시오 (연락할 사람에 대한 참조는 [[Meet the Team|이 문서]]를 확인하십시오). ***요청자가 예상한 마감일을 맞출 수 없는 경우, Bugzilla 티켓을 업데이트하거나 CX 직원에게 직접 연락하여 가능한 한 빨리 CX 팀에 알려주십시오. * 4단계: '''콘텐츠 게시''' **'''콘텐츠 게시:''' 초안이 최종 확정되고 이해 관계자의 승인을 받으면, 실제 기술 자료 문서에 새 리비전으로 콘텐츠를 제출할 수 있습니다. 저희 KB는 사용자 지정 Wiki 구문을 사용하므로 Google Doc에서 콘텐츠를 복사하는 경우 콘텐츠 형식이 올바른지 확인하십시오. **'''콘텐츠 검토:''' 기여자는 게시하기 전에 문서 작성자가 아닌 다른 사람의 KB 검토를 기다려야 합니다. 직원 검토는 새 문서나 리비전 노트에 "직원 검토 필요"라고 표시된 리비전에만 필요합니다. 이 프로세스는 지원 문서가 게시되기 전에 정확성, 품질 및 적절한 마크업을 보장하는 데 도움이 됩니다. KB 문서 검토에 대한 자세한 내용은 [[Article review guidelines for KB reviewers]]를 참조하십시오. **'''티켓 마감:''' KB 문서가 게시되면 Bugzilla 티켓을 해결됨 → 수정됨으로 표시하여 마감할 수 있습니다. 관련된 기여자가 티켓을 마감할 수 있지만, 최종적으로는 Mozilla 직원이 티켓 마감을 책임집니다. {warning}'''중요: 기술 작가, 제품 지원, 제품 관리자, 콘텐츠 전략가 및 임원을 포함한 Mozilla 직원은 모든 Bugzilla 콘텐츠 해결에 대한 최종 의사 결정 권한을 가집니다.'''{/warning} ==콘텐츠 승인 대 콘텐츠 검토== ''콘텐츠 승인''의 주요 목표는 제품 이해 관계자와 함께 콘텐츠의 실체와 의도를 검증하는 것입니다. 여기에는 콘텐츠 초안이 다음과 같은지 확인하는 것이 포함됩니다: * 기술적으로 정확하고 의도된 제품 동작을 반영하는지 * 승인된 제품 용어 및 명명 규칙과 일치하는지 * Mozilla의 브랜드 목소리 및 메시지와 일치하는지 ''콘텐츠 검토''는 문서의 품질과 표현에 중점을 두어 승인을 보완합니다. 여기에는 다음이 포함됩니다: * 올바른 구문 및 서식 확인([[Markup chart|위키 마크업]] 포함) * 명확성, 가독성 및 구조 개선 * 편집 및 [[Writing guide for Knowledge Base articles|콘텐츠 가이드라인]]과의 일치 여부 확인 콘텐츠 승인과 검토는 함께 문서가 게시되기 전에 정확하고 사용자 친화적인지 확인합니다. ==기여자를 위한 추가 가이드라인== * '''할당의 공정성''' 제품 팀과 직접적인 관계가 있는 기여자는 공식적으로 제출되기 전에 예정된 요청을 인지할 수 있습니다. 그러나 콘텐츠 요청이 생성되고 분류되기 전에는 작업을 시작하거나 할당을 요청하지 마십시오. 이는 모든 기여자에게 기여할 기회가 개방적이고 공평하게 유지되도록 보장합니다. * '''분류 프로세스 존중''' CX 팀이 Bugzilla 티켓을 검토하고 할당할 수 있도록 영업일 기준 5일의 전체 분류 기간을 허용해 주십시오. 이 기간이 지나기 전에 할당 결정을 요청하거나 압력을 가하는 것을 피하십시오. * '''가용성 변경 사항 전달''' 예기치 않은 상황이 발생할 수 있음을 이해합니다. 약속한 마감일을 지킬 수 없는 경우, 저희가 그에 따라 조정할 수 있도록 가능한 한 빨리 CX 팀에 알려주십시오. * '''Bugzilla 티켓 재개 정책''' 원래 요청과 직접 관련이 없는 리비전의 검토를 요청하기 위해 해결된 Bugzilla 콘텐츠 요청 티켓을 다시 열지 마십시오. 관련 업데이트의 경우, 티켓을 다시 여는 대신 기존 티켓에 새 댓글을 추가하십시오. 댓글을 달 권한이 없는 경우, kb-reviewers 메일링 리스트(아래 참조)로 요청을 에스컬레이션하십시오. 이 기준을 충족하지 않고 티켓을 다시 열면 요청이 기각될 수 있습니다. 생산적이고 존중하는 협업을 유지하려면 [https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Bugzilla 에티켓]을 따르십시오. * '''신속한 검토 요청''' 긴급한 제품 변경, 진행 중인 사고 또는 중대한 부정확성과 같이 리비전에 더 빠른 처리가 필요한 경우, [mailto:kb-reviewers@mozilla.com kb-reviewers@mozilla.com]으로 이메일을 보내 신속한 검토를 요청할 수 있습니다. =수신 콘텐츠 요청을 찾는 곳= 기여자는 기밀이 아닌 콘텐츠 요청에 참여하도록 권장됩니다. 수신 콘텐츠 요청을 찾는 방법은 다음과 같습니다: * '''수동 모니터링''' 할당되지 않은 수신 요청을 [https://bugzilla.mozilla.org/buglist.cgi?product=support.mozilla.org&classification=Other&bug_status=UNCONFIRMED&bug_status=NEW&component=Knowledge%20Base%20Content&query_format=advanced&resolution=---&list_id=17743785 여기]에서 확인하여 새로운 콘텐츠 요청 버그를 주시하십시오. 관심 있는 버그를 찾으면, 버그에 직접 댓글을 달아 CX 팀에 요청을 돕고 싶다고 알리십시오. * '''최신 정보 유지''' 새로운 콘텐츠 요청에 대한 알림을 받고 싶다면, Bugzilla에서 Knowledge Base Content 구성 요소를 주시하는 것을 고려해 보십시오. 이렇게 하려면 Bugzilla 프로필 → ''프로필 및 기본 설정 편집'' → ''구성 요소 주시''로 이동하십시오. 제품 선택에서 '''support.mozilla.org'''를 선택하고 ''구성 요소'' 필드에서 ''Knowledge Base Content''를 선택하십시오. 그리고 변경 사항을 저장하려면 {button Add} 버튼을 클릭하는 것을 잊지 마십시오. =할당 기준= 콘텐츠 요청은 다음 조건을 충족할 때 기여자에게 할당될 수 있습니다: * 기밀 정보를 포함하지 않음 ;'''엠바고 정보 또는 민감한 콘텐츠'''를 포함하는 콘텐츠 요청은 직원이 소유합니다. * 긴밀한 내부 종속성을 포함하지 않음 ;'''메시징 민감성, 규정 준수 검토 또는 진화하는 사양'''을 포함하고 법률, 마케팅 및 커뮤니케이션, 보안 및 외부 파트너와의 적극적인 조정을 필요로 하는 요청도 직원에게 남아 있습니다. * 유료 제품과 관련 없음 ;'''구독 제품 및 유료 기능'''과 관련된 콘텐츠 요청은 법률, 규정 준수, 테스트 및 여러 부서와의 조정 요구 사항으로 인해 직원이 소유해야 합니다. 이러한 요청은 종종 중앙 집중식 책임을 요구하는 계약, 청구 또는 출시 민감 정보를 포함합니다. * 시간에 민감하지 않음 ;처리 시간이 '''5일 미만'''인 콘텐츠 요청은 시기적절한 전달과 출시 일정과의 조정을 보장하기 위해 직원에게 남아 있습니다. * 기여자 수용 능력 ;기여자는 한 번에 최대 '''3개의 활성 할당'''으로 제한됩니다. 이는 집중적인 실행을 보장하고 작업량 불균형을 방지하는 데 도움이 됩니다. 일부 요청은 기술적 종속성으로 인해 지연될 수 있음을 인지하고 있습니다. 요청이 제품 측 종속성으로 인해 '''2주''' 이상 차단된 상태로 유지되면 해당 티켓은 비활성(오래된)으로 간주되어 기여자 작업량 기대치에서 제외될 수 있습니다. 추가 설명: * 이는 Bugzilla를 통한 요청에만 적용되며 사소한 KB 리비전에는 적용되지 않습니다. * 이는 [[common forum responses]] 생성에는 적용되지 않습니다. * 직원은 게시된 콘텐츠에 대한 최종 책임을 집니다.

기술 자료 워크플로우가 발전함에 따라, 커뮤니티 기여자에게 콘텐츠 요청을 할당할 수 있는 시점에 대한 명확한 경계를 만들고자 합니다.

저희는 여러분의 전문성을 매우 소중하게 생각합니다. 커뮤니티 내의 오랜 제품 지식은 매우 가치가 있습니다. 동시에, 제품 출시 및 여러 부서와의 협업과 관련된 콘텐츠 작업은 Mozilla의 전 세계 사용자 기반을 지원하기 위해 정확하고 유용한 콘텐츠를 시기적절하게 제공할 수 있도록 명확한 소유권, 예측 가능한 일정, 체계적인 조정을 필요로 합니다.

이러한 가드레일은 다음을 위해 설계되었습니다:

• 출시 일정 보호
• 소유권 및 책임 명확화
• 건전한 협업 유지
• 불분명한 기대로 인한 마찰 방지

이러한 변경 사항은 직원과 기여자 간의 지속 가능한 협업을 만들기 위한 것입니다.

시작하기 전에

진행하기 전에, 저희는 사소한 업데이트와 주요 업데이트에 대해 다른 워크플로우를 따른다는 점에 유의해 주십시오.

• 각 카테고리에 해당하는 것이 무엇인지 이해하려면 Minor vs major changes를 검토하고, 사소한 업데이트를 직접 제출하는 방법에 대한 지침은 Submit a minor edit or update to a Knowledge Base article을 참조하십시오.
• Bugzilla를 통한 주요 업데이트 요청 제출에 대해서는 How to submit a SUMO Knowledge Base content request를 검토하십시오.

이러한 가드레일은 지원 문서에 대한 새로운 콘텐츠 또는 주요 업데이트 요청에만 적용됩니다. 다른 문서 카테고리나 기술 자료에 직접 제출된 지원 문서의 사소한 수정에는 적용되지 않습니다.

새로운 콘텐츠 요청 및 주요 업데이트를 위한 콘텐츠 프로세스

다음 프로세스는 Bugzilla를 통해 제출된 새로운 콘텐츠 요청 및 주요 업데이트에 적용됩니다. 이 제출 프로세스는 기여자뿐만 아니라 Mozilla 직원에게도 적용됩니다.

• 1단계: 제출

모든 주요 콘텐츠 업데이트는 Bugzilla 티켓을 통해 제출해야 합니다.

• 2단계: 분류 및 할당
  • 분류: 모든 새로운 콘텐츠 요청은 우선순위와 할당을 결정하기 위해 분류 과정을 거칩니다. 요청이 아래 섹션에 설명된 할당 기준과 일치하는 경우 기여자의 참여를 권장합니다. 참여 의사를 밝히려면 Bugzilla 티켓에 직접 댓글을 달아주세요.
  • 할당: CX 팀은 제품 소유권과 관계없이 전체 콘텐츠 요청 프로세스를 책임지며, 버그를 기여자/기술 작가에게 할당합니다. CX 직원이 할당을 확인할 때까지 초안 작성을 시작하지 마십시오. 할당이 완료되면 커뮤니티 관리자 또는 다른 CX 팀원이 프로세스를 안내해 드립니다.
  • 예상 시간: 분류는 매주 수행되며, 기여자는 최초 요청 후 영업일 기준 5일 이내에 응답을 받을 수 있습니다.
• 3단계: 콘텐츠 제작
  • 콘텐츠 초안: 티켓을 주의 깊게 검토하여 요청, 범위 및 예상 결과를 완전히 이해하십시오. 제품 팀에서 초안을 제공한 경우 이를 시작점으로 사용하십시오. 그렇지 않은 경우 Google Docs에서 콘텐츠 초안 작성을 시작할 수 있습니다. Google Docs를 사용할 수 없는 경우, 검토를 위해 초안을 Bugzilla 티켓에 직접 첨부할 수 있습니다. 초안 링크를 Bugzilla 티켓에 게시하고 이해 관계자가 댓글을 달 수 있도록 문서 권한을 설정해야 합니다.
  • 콘텐츠 승인: 요청자 또는 제품 이해 관계자와 긴밀히 협력하여 문서가 완전하고 정확한지 확인하십시오. 작업을 완료하는 데 필요한 정보가 누락된 경우 Bugzilla의 "정보 요청..." 옵션을 사용하여 추가 세부 정보를 수집하십시오.
  • 에스컬레이션:
    • 요청자로부터 필요한 정보를 얻을 수 없는 경우, CX 제품 지원 관리자 또는 커뮤니티 관리자에게 지원을 요청하십시오 (연락할 사람에 대한 참조는 이 문서를 확인하십시오).
    • 요청자가 예상한 마감일을 맞출 수 없는 경우, Bugzilla 티켓을 업데이트하거나 CX 직원에게 직접 연락하여 가능한 한 빨리 CX 팀에 알려주십시오.
• 4단계: 콘텐츠 게시
  • 콘텐츠 게시: 초안이 최종 확정되고 이해 관계자의 승인을 받으면, 실제 기술 자료 문서에 새 리비전으로 콘텐츠를 제출할 수 있습니다. 저희 KB는 사용자 지정 Wiki 구문을 사용하므로 Google Doc에서 콘텐츠를 복사하는 경우 콘텐츠 형식이 올바른지 확인하십시오.
  • 콘텐츠 검토: 기여자는 게시하기 전에 문서 작성자가 아닌 다른 사람의 KB 검토를 기다려야 합니다. 직원 검토는 새 문서나 리비전 노트에 "직원 검토 필요"라고 표시된 리비전에만 필요합니다. 이 프로세스는 지원 문서가 게시되기 전에 정확성, 품질 및 적절한 마크업을 보장하는 데 도움이 됩니다. KB 문서 검토에 대한 자세한 내용은 KB 검토자를 위한 문서 검토 가이드라인를 참조하십시오.
  • 티켓 마감: KB 문서가 게시되면 Bugzilla 티켓을 해결됨 → 수정됨으로 표시하여 마감할 수 있습니다. 관련된 기여자가 티켓을 마감할 수 있지만, 최종적으로는 Mozilla 직원이 티켓 마감을 책임집니다.

콘텐츠 승인 대 콘텐츠 검토

콘텐츠 승인의 주요 목표는 제품 이해 관계자와 함께 콘텐츠의 실체와 의도를 검증하는 것입니다. 여기에는 콘텐츠 초안이 다음과 같은지 확인하는 것이 포함됩니다:

• 기술적으로 정확하고 의도된 제품 동작을 반영하는지
• 승인된 제품 용어 및 명명 규칙과 일치하는지
• Mozilla의 브랜드 목소리 및 메시지와 일치하는지

콘텐츠 검토는 문서의 품질과 표현에 중점을 두어 승인을 보완합니다. 여기에는 다음이 포함됩니다:

• 올바른 구문 및 서식 확인(위키 마크업 포함)
• 명확성, 가독성 및 구조 개선
• 편집 및 콘텐츠 가이드라인과의 일치 여부 확인

콘텐츠 승인과 검토는 함께 문서가 게시되기 전에 정확하고 사용자 친화적인지 확인합니다.

기여자를 위한 추가 가이드라인

• 할당의 공정성

제품 팀과 직접적인 관계가 있는 기여자는 공식적으로 제출되기 전에 예정된 요청을 인지할 수 있습니다. 그러나 콘텐츠 요청이 생성되고 분류되기 전에는 작업을 시작하거나 할당을 요청하지 마십시오. 이는 모든 기여자에게 기여할 기회가 개방적이고 공평하게 유지되도록 보장합니다.

• 분류 프로세스 존중

CX 팀이 Bugzilla 티켓을 검토하고 할당할 수 있도록 영업일 기준 5일의 전체 분류 기간을 허용해 주십시오. 이 기간이 지나기 전에 할당 결정을 요청하거나 압력을 가하는 것을 피하십시오.

• 가용성 변경 사항 전달

예기치 않은 상황이 발생할 수 있음을 이해합니다. 약속한 마감일을 지킬 수 없는 경우, 저희가 그에 따라 조정할 수 있도록 가능한 한 빨리 CX 팀에 알려주십시오.

• Bugzilla 티켓 재개 정책

원래 요청과 직접 관련이 없는 리비전의 검토를 요청하기 위해 해결된 Bugzilla 콘텐츠 요청 티켓을 다시 열지 마십시오. 관련 업데이트의 경우, 티켓을 다시 여는 대신 기존 티켓에 새 댓글을 추가하십시오. 댓글을 달 권한이 없는 경우, kb-reviewers 메일링 리스트(아래 참조)로 요청을 에스컬레이션하십시오.

이 기준을 충족하지 않고 티켓을 다시 열면 요청이 기각될 수 있습니다. 생산적이고 존중하는 협업을 유지하려면 Bugzilla 에티켓을 따르십시오.

• 신속한 검토 요청

긴급한 제품 변경, 진행 중인 사고 또는 중대한 부정확성과 같이 리비전에 더 빠른 처리가 필요한 경우, kb-reviewers@mozilla.com으로 이메일을 보내 신속한 검토를 요청할 수 있습니다.

수신 콘텐츠 요청을 찾는 곳

기여자는 기밀이 아닌 콘텐츠 요청에 참여하도록 권장됩니다. 수신 콘텐츠 요청을 찾는 방법은 다음과 같습니다:

• 수동 모니터링

할당되지 않은 수신 요청을 여기에서 확인하여 새로운 콘텐츠 요청 버그를 주시하십시오. 관심 있는 버그를 찾으면, 버그에 직접 댓글을 달아 CX 팀에 요청을 돕고 싶다고 알리십시오.

• 최신 정보 유지

새로운 콘텐츠 요청에 대한 알림을 받고 싶다면, Bugzilla에서 Knowledge Base Content 구성 요소를 주시하는 것을 고려해 보십시오. 이렇게 하려면 Bugzilla 프로필 → 프로필 및 기본 설정 편집 → 구성 요소 주시로 이동하십시오. 제품 선택에서 support.mozilla.org를 선택하고 구성 요소 필드에서 Knowledge Base Content를 선택하십시오. 그리고 변경 사항을 저장하려면 Add 버튼을 클릭하는 것을 잊지 마십시오.

할당 기준

콘텐츠 요청은 다음 조건을 충족할 때 기여자에게 할당될 수 있습니다:

• 기밀 정보를 포함하지 않음

엠바고 정보 또는 민감한 콘텐츠를 포함하는 콘텐츠 요청은 직원이 소유합니다.

• 긴밀한 내부 종속성을 포함하지 않음

메시징 민감성, 규정 준수 검토 또는 진화하는 사양을 포함하고 법률, 마케팅 및 커뮤니케이션, 보안 및 외부 파트너와의 적극적인 조정을 필요로 하는 요청도 직원에게 남아 있습니다.

• 유료 제품과 관련 없음

구독 제품 및 유료 기능과 관련된 콘텐츠 요청은 법률, 규정 준수, 테스트 및 여러 부서와의 조정 요구 사항으로 인해 직원이 소유해야 합니다. 이러한 요청은 종종 중앙 집중식 책임을 요구하는 계약, 청구 또는 출시 민감 정보를 포함합니다.

• 시간에 민감하지 않음

처리 시간이 5일 미만인 콘텐츠 요청은 시기적절한 전달과 출시 일정과의 조정을 보장하기 위해 직원에게 남아 있습니다.

• 기여자 수용 능력

기여자는 한 번에 최대 3개의 활성 할당으로 제한됩니다. 이는 집중적인 실행을 보장하고 작업량 불균형을 방지하는 데 도움이 됩니다. 일부 요청은 기술적 종속성으로 인해 지연될 수 있음을 인지하고 있습니다. 요청이 제품 측 종속성으로 인해 2주 이상 차단된 상태로 유지되면 해당 티켓은 비활성(오래된)으로 간주되어 기여자 작업량 기대치에서 제외될 수 있습니다.

추가 설명:

• 이는 Bugzilla를 통한 요청에만 적용되며 사소한 KB 리비전에는 적용되지 않습니다.
• 이는 common forum responses 생성에는 적용되지 않습니다.
• 직원은 게시된 콘텐츠에 대한 최종 책임을 집니다.