Create/See and Create Permissions (again)

@John_Lehmann 이 기능을 정확히 구현한 플러그인을 방금 추가했습니다.

@Hooksmith 이 플러그인이 유용할 수 있습니다. 다만 플러그인은 작성자가 자신의 주제에 답변할 수 있도록 허용합니다(예: 후속 질문에 응답하기 위해).

6개의 좋아요

@david 정말 훌륭합니다, 깊이 감사드립니다. 이 기능을 완벽하게 만들 나머지 한 가지 요소는 모더레이터가 다른 사용자를 대화에 추가할 수 있는 능력입니다. 저희의 경우, 원글 작성자(OP)가 양방향 거래에 대한 평가나 분쟁을 게시하게 됩니다. 우리는 상대방이 이를 인지하고 발언에 참여할 수 있기를 원합니다. 이것이 가능한 방법은 있을까요?

현재로서는 답글이 제한되지 않은 그룹에 해당 사람들을 추가하는 것만이 가능한 방법입니다. 주제별로 추가 사람들을 초대하려면 플러그인에 일부 확장 기능이 필요합니다.

4개의 좋아요

@david 설명해 주셔서 감사합니다.

이 플러그인을 확장해서 임의의 사용자(ad hoc users)를 스레드별로 추가할 수 있게 만들려면 난이도가 어느 정도일까요? 꽤 복잡해 보이긴 하는데, 제가 판단할 입장은 아닌 것 같습니다.

혹시 이 작업을 진행해 주실 분이 있을까요? 감사합니다!

극도로 어렵습니다. 실현 가능성이 매우 낮습니다. Discourse는 주제별 권한을 제공하지 않으며, 앞으로도 제공하지 않을 것입니다. 해당 기능이 필요하시다면 그룹 DM을 구축하세요.

2개의 좋아요

답변해 주셔서 감사합니다. 제가 잘 몰라서 죄송한데, '그룹 PM을 빌드한다’는 게 무슨 뜻인지 설명해 주실 수 있나요? 다른 종류의 플러그인을 만들라는 말씀인지, 아니면 Discourse 대신 다른 소프트웨어를 사용하라는 말씀인지 궁금합니다.

토픽별 권한이 필요하시면 개인 메시지를 작성하고 수신자를 포함해 주세요.

다른 아이디어를 얻으려면 사용 사례를 설명해 주실 수 있습니다. 토픽별 권한이 정말 필요하고 직접/개인 메시지 사용이 적합하지 않다면, discourse가 여러분에게 적합하지 않을 수 있습니다.

수정:

아! 제가 약간 잘못 알고 있었네요.

2개의 좋아요

해당 플러그인과 동일한 패턴을 따르고 단순히 답글 권한만 수정한다면 상대적으로 간단합니다. Discourse 프로그래밍에 익숙한 사람이라면 1~2일 정도 소요될 것으로 보입니다. Q&A 스타일의 사이트에서 유용할 수 있을 것 같습니다.

Jeff가 말했듯이, 주제별로 보기 권한을 수정하는 것은 매우 어렵고, 앞으로도 가능성이 낮습니다. 이는 주제 목록, 추천 주제, 알림 등 애플리케이션 전반에 걸친 광범위한 변경이 필요하기 때문입니다. 주제별 보기 권한 수정이 필요하시다면 DM(개인 메시지)을 사용하세요.

3개의 좋아요

개인을 추가하는 것 대신, 특정 그룹을 선택하여 해당 그룹의 사용자들에게만 개인 메시지를 보낼 수 있습니다. 단, 실수로 그룹 전체에 스팸 메시지를 보내지 않도록 주의하세요:

  • 햄버거 메뉴로 이동하세요 - 기본 위치는 화면 오른쪽 상단입니다.

  • 그룹을 선택하여 모든 그룹을 표시하세요.

  • 그룹 PM을 보내고 싶은 그룹을 선택하세요.

  • 올바른 권한(예: 포럼에서 PM 사용 가능)이 있으면 메시지 버튼이 표시됩니다.

  • 메시지 버튼을 선택하여 그룹 PM을 작성하세요

  • …

2개의 좋아요

안녕하세요, 정보 주셔서 감사합니다. 맥락을 말씀드리자면, 현재 제 마켓플레이스 웹사이트의 동반 사이트로써 약 6개월 동안 안정적으로 운영 중인 Discourse 사이트를 하나 보유하고 있습니다. 지금까지 이 메타 사이트의 활동량과 비교했을 때 우리 사이트는 그 절반 정도 수준인 것 같습니다. Discourse에 매우 만족하고 있으며, 문제가 없이 잘 작동하고 있어 변경할 의향은 없습니다.

하지만, 분쟁에 대한 공개 중재를 진행할 수 있는 특별한 카테고리를 추가하고 싶습니다. 예를 들어, 구매자가 상황이 어떻게 흘러갔는지에 대해 불만을 느끼는 경우, 원포스터(OP)로 하여금 불만을 제기하게 하고, 그 후 신뢰할 수 있는 TLX 사용자들이 답변을 통해 더 많은 정보를 수집하고 중재할 수 있도록 하는 방식입니다.

위에서 언급할 때 빠뜨린 세부 사항은 이 플러그인을 적용해도 여전히 부족한 단 하나의 부분입니다. 즉, 해당 토픽에 관여 중인 상대방에게도 쉽게 답변 권한을 부여할 수 있어야 한다는 점입니다.

  • 생성: 모든 사용자
  • 답변: OP, X 그룹, 상대방(중재자에 의해 추가?)
  • 보기: 모든 사용자

이러한 토론을 공개적으로 진행하는 가치는, 성숙한 커뮤니티가 이러한 복잡한 상황에서 실제로 무슨 일이 있었는지와 누가 잘못했는지를 명확히 밝혀낼 수 있다는 데 있습니다. 이러한 스레드의 기록은 긍정적인 평판과 부정적인 평판을 구축하는 데 매우 유익합니다. 사실 우리 사이트에는 평점 시스템이 있지만, 이러한 2인 이상 간의 대화처럼 세부적인 내용을 다루지는 못합니다.

상상하실 수 있듯이, 이런 종류의 "카테고리"는 매우 혼란스러울 수 있습니다. 하지만 이러한 구성이 가능하다면, 이전의 어떤 시도보다 우리 커뮤니티의 이 요구를 더 잘 충족시킬 수 있다고 생각합니다. 이전에도 여러 시도가 있었고, 최근까지 괜찮게 유지되던 시도는 페이스북에서 삭제되어 수년간의 기록이 사라졌습니다. 하지만 이러한 다른 포맷들이 무지한 제3자의 의견이 난무하는 혼란을 허용하기 때문에 이상적이었던 적이 없습니다.

이 플러그인을 개발하기 위해 며칠간의 개발 비용을 지원할 의향이 있습니다.

2개의 좋아요

방금 언급한 기능을 지원하도록 이 플러그인을 확장하는 작업을 후원할 가능성이 높습니다. 제안 사항이 있으시다면, 아래에 제안한 접근 방식을 공유합니다:

주제(Topic)에 대해 추가 사용자에게 “임시(ad hoc)” 답변 권한을 부여하기 위해, 플러그인은 OP(첫 번째 게시물)에서 언급된 모든 사용자를 스캔할 것입니다. 이렇게 하면 처음부터 사용자를 언급할 수 있거나, 관리자가 해당 게시물을 편집하여 사용자를 추가할 수도 있습니다.

이 방식은 자연스러운 워크플로우 측면에서 좋은 접근법이라고 생각하며, 구현 측면에서도 (예: UI 불필요) 더 간단할 것으로 보입니다.

4개의 좋아요

카테고리에 ‘승인 필요’ 설정을 사용하는 건 어떨까요? 각 게시글마다 модератор의 승인이 필요하므로 처리 속도는 느려지겠지만, 논란이 많은 주제라면 오히려 좋은 방법일 수 있습니다.

3개의 좋아요

원래 게시물에서 명시된 대로 “Create” 권한에 대한 late-breaking(마지막 순간) 지원을 제안하고 싶습니다.

우리는 Discourse를 Piazza보다 훨씬 우수한 대안으로 강의용 포럼으로 사용하고 있습니다. 학생들이 특정 카테고리에서 게시물을 작성하긴 하지만 다른 사용자의 게시물을 볼 수 없도록 해야 하는 두 가지 사용 사례를 떠올렸습니다:

  • 질문에 코드를 포함해야 할 때 도움을 요청하는 경우. 이 경우 다른 학생들이 올린 부분적인 해결책을 학생들이 보지 못하게 하고 싶습니다.
  • 장기 프로그래밍 프로젝트의 진행 상황을 기록하는 학기 단위 작업 로그를 유지하는 경우. 마찬가지로 여기에도 코드가 포함되길 원하지만, 학생들이 서로의 작업 로그를 엿보지 못하게 하고 싶습니다.

이 두 경우 모두 카테고리 수준의 기능과 강의 스태프에 대한 접근 권한이 매우 중요합니다.

참고로, 우리는 지난 3개 학기(2018년 가을학기부터) 동안 위 첫 번째 사용 사례를 위해 메시지 시스템을 사용해 왔습니다. 솔직히 말하면, 이 방식은 전혀 잘 작동하지 않았습니다. 제 강의에는 수백 명의 학생(가을학기 800명, 봄학기 600명)과 수백 명의 강의 스태프가 있습니다. 적어도 저에게는, 과제 도움 요청으로 인한 수백 개의 메시지가 도움 메시지 그룹으로 쏟아져 들어오면서 스태프와 학생들로부터 오는 더 중요한 다이렉트 메시지가 묻혀 버리고, 결과적으로 전체 PM(개인 메시지) 기능이 훨씬 덜 유용해졌습니다.

그 결과, 이번 학기에는 Discourse가 원래 훨씬 더 적합한 플랫폼임에도 불구하고, 두 번째 사용 사례를 위해 Google Docs를 사용하기로 제안합니다. 하지만 추가적인 메시지 트래픽과 그로 인한 혼란을 감당하기는 정말 어렵습니다.

위에서 설명한 플러그인이 이 기능에 얼마나 근접할 수 있을지는 모르겠지만, 만약 도달할 수 있다면 개발에 도움을 줄 수 있을 것입니다. 참고로, 우리의 경우 답글 작성 권한을 통제하는 것뿐만 아니라 주제(topic)의 가시성을 통제하는 것이 매우 중요합니다.

그룹 메시지는 스팸 문제를 해결해 줍니다. 그룹을 추적만 하면 “부드러운” 알림을 선택할 수 있고, 그룹을 음소거하거나 일반 상태로 설정하면 알림을 완전히 끄 수도 있습니다.

메시지 시스템을 사용한다고 하셨을 때, 그룹 메시지를 사용하시는 건가요? (예를 들어 computing101-staff라는 그룹 통화를 설정하고, 해당 그룹에 메시지를 보내면 그 그룹의 멤버들이 알림 강도 수준을 선택할 수 있습니다.)

2개의 좋아요

저는 우리가 이 방식을 실제로 시도해 보지 않았거나, 매우 적극적으로 시도해 보지 않았다는 점을 지적하기 위해 제 게시물을 수정하고 있었습니다. 카테고리 내 모든 항목에 대해 알림을 받지 않으면서도, 내가 참여한 메시지에 대한 답장만 알림을 받을 수 있는, 더 일반적인 주제 접근 방식과 동일한 기능이 있을까요?

그 점을 넘어, 저는 이러한 상호작용이 포럼의 다른 부분으로 분리되는 것에 대해 불평할 수밖에 없는 것 같습니다. 저는 그것들이 다른 주제들과 함께 카테고리에 있는 것을 선호합니다. 하지만 아마도 그것은 더 사소한 불만일 수 있고—UI를 통해 완전히 해결할 수 있는 문제일지도 모릅니다. 메시지 그룹을 카테고리 목록에 표시되도록 할 수 있는 방법이 있을까요?

물론입니다. 익숙했던 모든 컨트롤이 그대로 유지되어 있습니다.

2개의 좋아요

이렇게 하면 어떨까요? :slight_smile:

(그리고 최신 게시글 보기에서도.)

1개의 좋아요

그것은 불가능합니다. 매우 다른 버킷이기 때문입니다. 하지만 시도해 보기 전에 완전히 무시하지 마시고, 몇개월 동안 사용해 본 후 결과를 알려 주시기 바랍니다.

우리는 메시지 방식을 1년 넘게 사용해 왔다는 점을 고려해 주세요. 볼륨(음량) 설정을 조정하면 도움이 될 것이라고 생각하지만, 그렇게 하면 메시지가 더 자주 무시당할까 봐 우려됩니다. 그래도 메시지 그룹의 볼륨 설정을 조정할 수 있다는 점을 직원들에게 다시 한번 상기시켜 드리겠습니다. 그 점에 대해 알려주셔서 감사합니다.

결국, 우리 경우를 보면 코드가 포함된 도움 요청 주제와 코드가 포함되지 않은 도움 요청 주제를 UI 레벨에서 분리할 만한 좋은 이유가 실제로는 없습니다. (사실, 코드가 포함된 주제도 계속 응답하면서 외부 가시성을 주제별로 조정할 수 있다면 좋겠습니다.) 그리고 메시징 시스템을 통해 이러한 내용을 강제하면, 글쎄요, 메시징으로서의 유용성이 오히려 떨어지는 경험이었습니다. :slight_smile: 어쨌든, 우리가 다소 니치한 사용 사례에 해당한다는 점은 이해합니다. 하지만 우리는 더 많은 사람들이 Discourse를 교육용 도구로 사용하도록 설득하기 시작했으며, 이러한 기능을 더 원활하게 지원한다면 그 주장을 뒷받침하는 데 도움이 될 것이라고 생각합니다.

여기서 제가 우려하는 것은, 만약 여기서 기름과 물을 섞기 시작한다면 UX에서 왜 아예 별도의 섹션에 "메시지"를 두는 것이냐는 것입니다. 그냥 모든 메시지와 주제를 홈 페이지에 있는 모든 사람을 위한 하나의 긴 목록으로 합치는 게 어떨까요?

카테고리에서 생성은 할 수 있지만 일부만 볼 수 있는 구조는 근본적으로 특정 사람들에게만 보내는 사적인 메시지입니다.

3개의 좋아요