Discourse 권장 편집

sam · 3월 18, 2026, 3:54오전

커뮤니티 멤버가 게시물에 대한 편집을 제안할 수 있도록 하며, 검토자는 전체 편집 권한을 부여하지 않고도 어떤 변경 사항을 받아들일지 세밀하게 제어할 수 있습니다.

이 플러그인은 실험적 단계에 있으며, 현재 많은 변경 사항이 발생할 수 있으므로 아직 프로덕션 환경에서 사용하도록 권장되지 않습니다.

GitHub - discourse/discourse-suggested-edits: EXPERIMENTAL suggested edits plugin · GitHub

설치

다음 저장소 주소를 사용하여 표준 플러그인 설치 가이드를 따르세요:

https://github.com/discourse/discourse-suggested-edits.git

왜 '편집 제안(Suggested Edits)'인가?

많은 커뮤니티는 멤버들이 콘텐츠의 정확성을 유지하고 최신 상태로 관리하는 데 도움을 주기를 원하지만, 모든 사람에게 편집 권한을 부여하는 것은 항상 실용적이지 않습니다. '편집 제안’은 이러한 격차를 메워줍니다. 멤버들이 게시물 개선 사항을 제안하고, 신뢰할 수 있는 검토자가 무엇이 적용될지 결정합니다. 이는 위키백과 스타일의 기여 모델을 Discourse 커뮤니티에 가져오는 것과 같습니다.

이 기능은 특히 다음 경우에 유용합니다:

지식 베이스 및 문서 카테고리: 정확성이 중요하고 많은 시선이 도움이 되는 곳
신규 멤버가 많은 커뮤니티: 좋은 기여를 하지만 아직 전체 편집 신뢰를 얻지 못한 멤버들이 있는 곳
협업 콘텐츠: FAQ, 가이드, 또는 커뮤니티가 관리하는 참고 자료 등
자동 편집: 때때로 AI 시스템이 오타 및 발음 수정을 제안할 수 있으며, 이를 승인하기 위해 인간이 개입해야 하는 경우

작동 방식

편집 제안하기

설정된 제안 그룹의 멤버는 대상 게시물에 ‘편집 제안(Suggest Edit)’ 버튼을 볼 수 있습니다. 버튼을 클릭하면 게시물 내용이 미리 채워진 작성기가 열립니다. 사용자는 변경 사항을 만들고, 선택적으로 이유를 추가한 후 제출합니다.

제안 검토하기

검토자는 대기 중인 제안이 있는 게시물에 카운트 배지를 확인합니다. '검토(Review)'를 클릭하면 제안이 개별 변경 사항으로 나뉘어 모달 창이 열리며, 각 변경 사항은 주변 컨텍스트와 함께 하이라이트된 차이(diff)로 표시됩니다.

검토자는 다음을 수행할 수 있습니다:

각 변경 사항을 독립적으로 승인하거나 거부 — 전체를 수용하거나 모두 거부할 필요 없음
적용 전에 제안된 텍스트 편집 — 의도를 유지하면서 표현을 다듬음
인라인 및 나란히 보기(side-by-side) 차이 뷰 전환
여러 제안 사이 탐색 — 대기 중인 제안이 여러 개인 경우

변경 사항 적용

검토자가 '승인된 항목 적용(Apply Accepted)'을 클릭하면, 선택된 변경 사항이 제안자에게 귀속되는 수정본으로 게시물에 적용됩니다. 또한 누가 승인했는지 명시하는 편집 이유가 기록됩니다. 제안자 및 기타 영향받는 사용자에게 알림이 전송됩니다.

만료 처리

제안이 생성된 후 원본 게시물이 편집되면, 해당 제안은 자동으로 만료(stale) 상태로 표시되며 적용할 수 없습니다. 이는 충돌을 방지하고 제안이 항상 최신 콘텐츠에 기반하도록 보장합니다. 필요할 경우 재제출할 수 있도록 제안자에게 알림이 전송됩니다.

설정

플러그인을 활성화하고 관리자 > 설정에서 'suggested edits’를 검색하여 접근 권한을 설정합니다:

설정	설명
`suggested_edits_enabled`	플러그인 마스터 토글
`suggested_edits_suggest_groups`	편집을 제안할 수 있는 그룹
`suggested_edits_review_groups`	제안을 검토하고 적용할 수 있는 그룹. 게시물 작성자는 항상 자신의 게시물에 대한 제안을 검토할 수 있습니다.
`suggested_edits_included_categories`	편집 제안이 활성화된 카테고리
`suggested_edits_included_tags`	편집 제안이 활성화된 토픽의 태그
`suggested_edits_max_creates_per_minute`	제안 생성 제한 (기본값: 5)
`suggested_edits_max_revisions_per_minute`	제안 수정 제한 (기본값: 10)

일반적인 설정 방법

플러그인 활성화
제안 그룹을 편집을 제안할 수 있어야 하는 신뢰 수준 또는 그룹으로 설정 (예: trust_level_1)
검토 그룹을 관리자 또는 큐레이터로 설정 (예: staff)
이 기능을 활성화할 카테고리 또는 태그 선택 — 모든 곳에 활성화할 필요는 없습니다

게시물 작성자는 검토 그룹 설정과 관계없이 항상 자신의 게시물에 대한 제안을 검토할 수 있습니다.

범위 및 제한 사항

첫 번째 게시물에만 적용 — 편집 제안은 현재 토픽의 첫 번째 게시물(OP)에만 적용되며, 답변에는 적용되지 않습니다.
사용자당 게시물당 대기 중인 제안 1개 — 멤버는 같은 게시물에 다른 제안을 제출하기 전에 현재 대기 중인 제안이 해결될 때까지 기다려야 합니다.
제안은 텍스트 기반 — 차이는 게시물의 원본 마크다운 콘텐츠에서 계산됩니다.

검색

검토자는 with:suggested-edits 검색 필터를 사용하여 포럼 전체에서 대기 중인 제안이 있는 토픽을 찾을 수 있습니다.

Moin · 3월 24, 2026, 11:28오후

알림을 받지 못한 것 같습니다.

NateDhaliwal · 4월 5, 2026, 12:29오전

음… 게시글에 수정 제안이 있을 때, 해당 주제의 원글 작성자(OP)에게 알림이 가나요? 코드를 둘러봐도 그런 부분이 보이지 않네요.

sam · 4월 5, 2026, 10:26오후

아니요, 아직 구현되지 않았습니다. 추가할 예정입니다.

patrickemin · 4월 5, 2026, 10:51오후

안녕하세요, 좋은 생각입니다! 카테고리를 선택할 때 1단계 카테고리만 선택하면 하위 카테고리도 함께 선택되나요? 감사합니다.

Lilly · 5월 31, 2026, 1:53오후

참고로 이 플러그인이 오류를 발생시키고 있습니다:

plugin-api.gjs:234 [PLUGIN discourse-suggested-edits] Attempted to modify "service:composer", but it was already initialized earlier in the boot process (e.g. via a lookup()). Remove that lookup, or move the modifyClass call earlier in the boot process for changes to take effect. https://meta.discourse.org/t/262064
_resolveClass @ plugin-api.gjs:234

초기화자(initializer)가 api.customizeComposerText() 호출 직전에 api.modifyClass("service:composer", {...})를 호출하여 레이스 컨디션(race condition)이 발생하는 것으로 보입니다. 변경 사항이 적용되려면 api.modifyClass가 api.customizeComposerText보다 먼저 실행되도록 코드 순서를 재배열해야 한다고 생각합니다:

github.com/discourse/discourse-suggested-edits

assets/javascripts/discourse/initializers/suggested-edits-init.gjs

46dab2365


      
          api.customizeComposerText({
            actionTitle(model) {
              if (model.action === SUGGEST_EDIT_ACTION) {
                return i18n("discourse_suggested_edits.composer.action_title");
              }
            },
            saveLabel(model) {
              if (model.action === SUGGEST_EDIT_ACTION) {
                return "discourse_suggested_edits.composer.save_label";
              }
            },
          });
          
          api.modifyClass("service:composer", {
            pluginId: "discourse-suggested-edits",

여기서 PR을 열었습니다:

github.com/discourse/discourse-suggested-edits

Update initializer - re-order (#8)

main ← Lillinator:fix-initializer-error

closed 10:02PM - 09 Jun 26 UTC

Lillinator

+12 -13

Switches the order of `api.modifyClass("service:composer")` and `api.customizeCo…mposerText()` to avoid a race condition - see the console error: ``` plugin-api.gjs:234 [PLUGIN discourse-suggested-edits] Attempted to modify "service:composer", but it was already initialized earlier in the boot process (e.g. via a lookup()). Remove that lookup, or move the modifyClass call earlier in the boot process for changes to take effect. https://meta.discourse.org/t/262064 _resolveClass @ plugin-api.gjs:234 ``` `api.customizeComposerText()` performs a lookup of the composer service `(container.lookup("service:composer"))` in order to register the text customizations. Thus, `api.customizeComposerText()` should follow `api.modifyClass("service:composer")`

sam · 6월 1, 2026, 2:56오전

이 내용을 초기화 이전 단계로 이동해야 할 것 같네요… 한번 살펴보겠습니다. 시도해 주셔서 감사합니다 @Lilly

jesse_mba_commons · 8월 5, 2026, 10:04오전

안녕하세요. 저희는 커뮤니티가 관리하는 긴 가이드에서 ‘편집 제안’ 기능을 파일럿 테스트하고 있으며, 여러 가지 UX 문제를 발견했습니다.

제안자가 편집을 눌러 대기 중인 제안을 열면, 작성기가 올바른 위치로 이동하지만 무엇을 변경했는지에 대한 시각적 표시가 없습니다. 제안자용 diff 또는 검토 단계를 추가하면 대기 중인 제안을 이해하고 수정하는 것이 훨씬 쉬워질 것입니다.
한 테스트에서 단어를 하나만 변경했는데, 원본 마크다운에서 공백이나 줄바꿈 변경으로 보이는 추가적인 diff 마커가 많이 나타났습니다. diff가 생성되기 전에 미미한 공백이 정규화(normalize)될 수 있을까요?
작성기가 전체 화면으로 확장되면 이유 추가가 사라집니다. 이유 입력 필드가 두 가지 뷰 모두에서 사용 가능하도록 하는 것이 도움이 될 것입니다. 제출 전에 사용자가 이유를 추가하도록 장려하는 최종 검토 화면도 워크플로우를 개선하는 데 도움이 될 것입니다.
아이콘만 있는 편집 제안 작업은 놓치기 쉽습니다. 기본적으로 아이콘과 함께 텍스트 라벨이 표시될 수 있을까요?
제출된 제안과 그 상태(대기 중, 승인됨, 거절됨, 철회됨, 만료됨)를 보여주는 회원용 페이지가 계획되어 있나요?

스크린샷을 제공하거나 개선 사항을 테스트하는 데 도움을 드릴 수 있습니다.

글		댓글	조회수
Community Editing Feature	10	3281	7월 3, 2015
Ask a user to revise their post before approving it? Feature approval , completed	11	1556	2월 28, 2024
Require staff approval for wiki edits in selected categories Feature	41	2165	4월 30, 2026
Allow the ability to Edit post on rejection UX review-queue	21	527	5월 6, 2026
Suggest Edits Feature Feature	2	629	9월 13, 2022