대학 프로그램 수업에 Discourse 사용

커뮤니티 구축
,
1

대학 프로그램을 위해 단일 Discourse 인스턴스를 운영하기를 원합니다. 여기서 최상위 카테고리들은 각각 다른 강좌에 해당하며, 액세스는 그룹을 통해 관리됩니다. 강좌의 교수자와 학습자가 강좌에 대해 일관된 인상을 가질 수 있도록, 저는 서로 다른 강좌들이 고립된 느낌을 주는 환경을 제공하고자 합니다. 따라서 제 인스턴스는 Teams/Slack/Mattermost와 유사한 내비게이션 경험을 제공해야 합니다. 이 플랫폼들에서는 상대적으로 고립된 팀들이 존재하며, 사용자는 팀 간에 전환해야 합니다. 제 인스턴스의 경우, 이는 UI가 현재 선택된 강좌와 관련된 데이터를 강조하는 것을 의미합니다. 예를 들어, 사용자는 주로 최상위 카테고리 중 하나에 머물며, 해당 카테고리를 선택하면 사용자가 쉽게 볼 수 있는 하위 카테고리 및 채팅 채널이 필터링됩니다.

비슷한 필요성은 서로 다른 카테고리가 다른 연구 그룹에 해당하는 인스턴스에서도 발생합니다(저는 이런 인스턴스도 하나 운영하기를 원합니다).

이러한 목표를 달성하는 데 도움이 되는 기존 도구는 무엇입니까?

4개의 좋아요
2

흥미로운 사용 사례네요! 해결 방법 중 하나는 관련이 없는 카테고리를 단순히 음소거(mute)해서 토픽 목록에 표시되지 않도록 하는 것입니다.

3

사실 나는 알림을 완전히 끄고 싶은 건 아닙니다. 학생은 여러 과목을 동시에 수강할 가능성이 높고, 모든 과목의 알림은 문제가 없거든요. 오히려 '지금 X 과목을 보고 있다’는 느낌을 더 명확하게 전달하고 싶은 겁니다.

1개의 좋아요
4

실제로는 이런 것이 필요할 것 같습니다

다만, "홈"을 선택할 수 있도록 해야 합니다.

5

플러그인의 의도는 주요 그룹이 선택된 홈과 같게 만드는 것인 것 같습니다. 사용자가 계정 설정 페이지에서 주요 그룹을 변경할 수 있도록 user_selected_primary_groups를 활성화해야 합니다.

2개의 좋아요
6

최적적으로는 더 일시적이고 공개적으로 덜 노출되는 기능이 좋겠습니다. 하지만 제목과 flair를 사용하지 않는다면, 주요 그룹을 전환하는 UI 구성 요소를 팀 선택기로 사용할 수 있을 것 같습니다.

몇 일 전 이곳에서 실험적으로 운영되던 추가 사이드바 선택기와 같은 기능이 있다면 좋을 것 같습니다.

7

그렇게 할 수도 있습니다. 또한 기본 그룹에 따라 사이트 로고를 변경하는 것도 가능합니다. 여러 대학이 인스턴스를 공유하는 사이트에서 이를 적용해 본 적이 있습니다. 상단 바에 드롭다운 메뉴를 갖춘 테마 컴포넌트를 만들어 기본 그룹을 선택할 수 있게 하는 방식도 고려해 볼 수 있습니다(그리고 “그룹” 대신 "클래스"라고 표시하는 것도 좋을 것 같습니다).

8

@Anton_Akhmerov 이 작업을 직접 하길 원하시나요, 아니면 다른 사람이 대신하도록 비용을 지불하시겠어요? 알려주세요!

직접 하길 원하신다면, 이 내용을 Development 채널로 옮기겠습니다. 거기서 작업을 진행한 후 커뮤니티에 결과를 보고하고 다른 멤버들의 의견을 들을 수 있을 거예요. 자, #dev로 옮기겠습니다.

다른 사람에게 의뢰하고 싶으시다면, Marketplace 채널로 옮기겠습니다.

9

Development 도와주세요 :folded_hands: :smiling_face_with_sunglasses:

또한 #dev에서 팁이나 조언을 주신다면 정말 좋겠습니다 :heart_eyes:

13

이 내용을 Community Building 채널로 옮기고, 사용 사례와 현재 요구 사항을 가장 잘 충족하는 방법에 대해 더 논의하며, 비슷한 요구 사항을 이미 해결한 다른 사람들을 위한 공간을 마련하는 것이 가장 좋다고 생각합니다.

그 후, 직접 구축하거나 옹호할 정도로 중요하다고 판단되는 구체적인 제품상의 결함이 식별된다면, 해당 아이디어를 위해 Contribute > Feature 및/또는 Development 채널에서 별도의 주제를 만들 수 있습니다.

이 방향이 여러분의 생각과 일치하나요? 아니면 이미 "결여된 부분을 직접 구축할 준비가 되었다"는 단계에 계신 건가요?

1개의 좋아요
14

Community Building 도 의미가 있습니다 :grin:. 이 기능은 다소 복잡해 보이지만, 이러한 요청들의 인기도를 고려할 때 커뮤니티의 필요성과 어느 정도 일치하는 것 같습니다

작업할 계획은 있지만, 아직까지는 계획이 다소 추상적입니다.

2개의 좋아요
15

후속 내용으로, Discourse의 기본 제공 기능을 활용하여 여러분의 요구사항을 가장 잘 충족시킬 수 있는 방법에 대해 제가 구상한 내용을 공유합니다. 이것이 여러분이 정확히 염두에 두고 계신 방식과는 다소 다를 수 있지만, 논의의 출발점으로서 고려해 볼 가치가 있다고 생각합니다.

먼저, 몇 가지 가정(이전제가)을 세웠는데, 이것이 유효한지 아닌지는 확실하지 않습니다. 제가 틀린 부분이 있다면 알려 주십시오:

  1. 수많은 과정(코스)이 존재할 것입니다(수십 개, 어쩌면 수백 개).
  2. 과정 설정은 학기 시작 시점에(연 2~4회) 주기적으로, 상당한 규모로 일괄 처리될 것입니다.
  3. 과정에는 수명(종료 시점)이 있을 것입니다.
  4. 과정을 관리하는 사람들은 과정을 자체적으로 설정할 수 있는 일부 권한이 필요합니다.
  5. 과정을 관리하는 사람들은 Discourse 사이트 관리에 대한 경험 제한적이거나 전혀 없을 것입니다.
  6. 과정을 관리하는 사람들은 기본적으로 자신의 과정만 볼 필요가 있습니다. 예시로 다른 과정을 가끔 보고 싶을 수는 있지만, 그것에 지속적으로 참여할 필요는 없습니다.
  7. ^ 과정 수강생도 마찬가지입니다.
  8. 시스템을 전체적으로 관리하는 팀은 매우 소규모입니다.
  9. 과정에는 하위 카테고리(subcategory)가 실제로 필요하지 않으며, 과정 내부의 콘텐츠를 조직화하는 데는 태그를 사용하는 것으로 충분할 것입니다.

위 가정이 대략 맞다면, 우선 고수준(high level)에서 다음과 같이 제안합니다:

  1. 최상위 카테고리(top level categories)를 소수로 생성합니다: “현재 진행 중인 과정(Current Courses)”, “지난 과정(Past Courses)”, “예정된 과정(Upcoming Courses)”, 그리고 시스템 자체에 대한 더 일반적인 사항(예: 사이트 사용법)을 위한 하나 이상의 카테고리.
  2. 홈 페이지 스타일을 “카테고리가 있는 박스(boxes with categories)”로 설정하여 이 카테고리들이 눈에 띄게 표시되도록 합니다.
  3. 각 과정별로 하위 카테고리를 사용합니다.
  4. “예정된 과정” 카테고리 내에 과정을 생성합니다.
  5. 학기가 시작되면 “현재 진행 중인 과정”으로 이동시킵니다.
  6. 과정이 종료되면 “현재 진행 중인 과정”에서 “지난 과정”으로 이동시킵니다.
  7. 그룹(Groups)을 사용하여 과정 접근을 제어합니다(자세한 내용은 아래 참조).

접근 제어(Access control):

  1. 각 과정별로 다음과 같은 그룹 집합을 생성합니다. 예를 들어: foo_interested, foo_enrolled, foo_admin.
  2. 추가 그룹 두 개를 생성합니다: “browse_courses”와 “browse_past_courses”.
  3. “예정된 과정”과 “현재 진행 중인 과정”의 카테고리는 해당 특정 과정의 그룹에 속한 사람과 “browse_courses” 그룹에 속한 사람만 접근할 수 있도록 설정합니다.
  4. “지난 과정”의 카테고리는 해당 특정 과정의 그룹에 속한 사람과 “browse_past_courses” 그룹에 속한 사람만 접근할 수 있도록 설정합니다.

그룹과 과정에 대한 사용자 경험(User experience)

  1. “예정된 과정” 최상위 카테고리 내에 과정을 탐색하는 방법을 설명하는 고정된 주제(pinned topic)를 배치하고, “browse_courses” 그룹에 가입할 수 있는 쉬운 방법을 제공합니다.
  2. ^ “현재 진행 중인 과정”도 마찬가지입니다.
  3. ^ “지난 과정”도 마찬가지입니다.

개별 과정에 대해서는, 과정에 가입하는 방법을 설명하는 고정된 주제를 해당 카테고리에 배치합니다:

  1. “foo_interested” 및/또는 “foo_enrolled” 그룹에 가입합니다.
  2. 사이드바에 과정을 추가합니다.

관리(Administration)는 초기에 다소 노력이 필요할 것입니다. 새로운 과정마다 권한이 있는 누군가가 다음을 수행해야 하기 때문입니다:

  1. 카테고리 생성
  2. 그룹 생성
  3. 고정된 주제 생성
  4. 사람들을 _admins 그룹에 추가
  5. 자신의 과정을 관리하는 데 필요한 문서 제공

이 중 일부는 가벼운 도구를 통해 자동화할 수 있습니다. 주요 관리 팀이 누구인지에 따라, 처음에는 API를 호출하는 밴드아웃(out of band) 방식으로 시작하는 것이 합리적일 수 있습니다. 또는 Discourse에 테마 컴포넌트나 플러그인으로 내장된 UI 기반의 더 복잡한 도구가 필요할 수도 있습니다. 하지만 저는 여기서 가볍게 시작하고, 먼저 작동하는 프로세스를 정의하는 데 집중한 후, 그 프로세스에 맞춰 도구를 설계하는 것을 제안합니다.

카테고리 확장성(scaling)은 여기서 잠재적인 우려 사항입니다. Discourse는 카테고리 수가 너무 많아지면(수백 개에서 수천 개) 성능과 사용자 경험 측면에서 약간의 거친 부분이 있습니다. 더 많은 카테고리에 접근 권한이 있는 사용자는 이 영향을 더 크게 느끼지만, 접근 권한이 제한된 사용자는 그렇지 않습니다. 제가 개요에서 제시한 대로 카테고리 접근을 제한하는 것이 이 우려를 완화하기 위한 동기 중 하나입니다.

위 내용에 대한 여러분의 모든 피드백과 질문에 매우 관심이 있습니다.

1개의 좋아요
16

Hey @mcwumbly, 상세하고 깊이 있는 설명에 감사드립니다.

말씀하신 내용은 제가 구상한 것과 매우 유사하며, 몇 가지 차이점이 있습니다.

약 5년간 단일 강의 인스턴스를 운영해 본 결과, 오래된 토론을 숨기거나 이동시키는 것이 강의 인스턴스를 처음부터 다시 만드는 것보다 훨씬 적은 노력을 요한다는 것을 깨달았습니다. 따라서 실제로는 강의용 discourse 공간은 고정되어 있지만, 대부분의 토픽에는 수명(종료 시점)이 있습니다.

저는 주로 강의 팀이 강의를 설정(set up)하는 것이 아니라 관리(manage)해야 할 것이라고 생각합니다.

저희 강의에는 약 200명의 학생과 TA를 포함하여 약 10명의 강의 팀이 있습니다. 이는 최소한 다음과 같은 여러 카테고리가 필요함을 의미합니다:

  • 콘텐츠 Q&A (학생이 게시하고, 강의 팀이 답변)
  • 강의 조직 (위와 동일하지만, 순수하게 조직적인 사항에 국한)
  • 공지사항 (강의 팀이 게시하고, 학생이 답글을 달 수 있음)
  • 채점 관련 질문 (학생이 게시하고, 강의 팀만 보고 답변할 수 있음).
    이 부분은 Private Topics Plugin 과 Assigning based on post content 을 사용하여 해결할 계획입니다.
  • 강의 팀 토론 (강의 팀만 볼 수 있음)

하위 카테고리를 사용하면 이 요구사항을 충족할 수 있다고 생각합니다.

위 항목들을 인스턴스 전체에 걸쳐 그룹화하여 말씀하신 것과 유사한 구조를 만들 수 있다는 점은 인지하고 있습니다. 하지만 그것들을 단일 카테고리에 두는 것이 더 합리적이라고 생각합니다.

종합하자면, 현재의 discourse 기능은 이 사용 사례에 잘 맞다고 생각합니다. 단, 강의 팀 멤버나 학생이 모든 강의를 한 번에 보는 것이 아니라 단일 강의를 보고 있다는 느낌을 제공해야 하는 순수 프론트엔드 기능에 대해서는 예외입니다.

문서 테마(documenation theme) 컴포넌트는 사용자가 카테고리에 "진입"할 수 있게 한다는 점에서 이와 유사하지만, 카테고리 "안"에 쉽게 “머물러” 있도록 허용하지는 않습니다.

1개의 좋아요
17

네, 대량의 주제를 이동하는 것은 다소 번거롭지만, 전체 카테고리를 “현재 진행 중인 코스”에서 “과거 코스”로 재부속(reparenting)하는 것은 꽤 쉬울 것 같습니다.

이렇게 하면 학기마다 처음부터 시작할 수 있다는 장점이 있습니다.

다만, 이전 학기의 콘텐츠가 가치 있는 것인지 해로운 것인지에 대한 관점과, 매 학기마다 새 카테고리를 만드는 데 팀이 얼마나 많은 노력을 기울이는지에 따라 단점이 될 수도 있습니다.

카테고리를 무기한 유지하는 것은 분명히 그 노력을 줄여줍니다. 작동이 가능하다면, 아주 좋은 방법입니다.

만약 오래된 콘텐츠가 영원히 남아 있는 것이 문제가 된다면, 그것은 “좋은 문제”일 수 있으며, 나중에 제가 제안한 모델로 전환하는 것이 그렇게 나쁘지 않을 것입니다.

여기서你们的 이론은 타당하다고 생각합니다.

각 코스 카테고리 내에서 해당 활동별로 서브카테고리를 두는 것은 합리적인 것 같습니다.

다시 한번, 추가적인 복잡성이 정당화되는지에 대한 자신감의 정도와, 그렇다면 그것이 올바른 형태인지에 따라 달라진다고 생각합니다.

대신 공지사항에 제한된 태그(restricted tag)를 사용할 수 있으며, 이는 몇 가지 이점이 있습니다.

마지막 두 항목은 카테고리 대신 그룹 PM(개인 메시지)을 통해 처리할 수 있습니다.

두 옵션 모두 고려해 볼 가치가 있다고 생각합니다. 두 옵션 사이에는 몇 가지 트레이드오프가 있습니다.

설정을 더 깊이 진행하면서 막히면 계속 질문해 주세요.

어떤 방향으로 시작하든, 진행 상황に関する 간헐적인 업데이트를 듣고 싶습니다!

2개의 좋아요
18

테마 컴포넌트는 예를 들어 아이콘을 변경하고, 전역 홈 페이지 대신 해당 강의의 홈 페이지로 이동하도록 설정할 수 있습니다.

저는 교육학 교수 시절, 교육 기술 관련 강의를 가르치기 위해 디스코르스를 사용하기 시작했습니다.

강의 자료에는 카테고리를 사용했고, 학생들은 공개된 카테고리에서 ‘답변을 연결된 주제로’ 기능을 이용해 과제를 제출하도록 했습니다. 학기 단위 주제에는 강의 계획표가 포함되었으며, 언제 무엇을 해야 하는지 표준 강의 자료에 대해 명시했습니다. 그다음, 어떤 주제가 채점 대상인지 표시하기 위해 태그를 설정했고, 제가 특정 주제에 '좋아요’를 눌렀는지를 확인하는 스크립트를 작성하여 과제 승인 여부를 나타내도록 했습니다.

또한 대학 LMS(학습 관리 시스템)의 CSV 파일을 업데이트하여 해당 시스템에 성적을 업로드하는 과정을 용이하게 하는 스크립트도 작성했습니다.

제가 가장 마음에 들었던 부분이자, 더 나은 학자였다면(그리고 그 직장을 그만두지 않았다면) 글을 썼을 법한 부분은, 다음 해에 개선점을 떠올리기를 기다리는 대신 강의 진행 중에도 불분명했던 부분을 바로 수정하여 과제를 업데이트했다는 점입니다. 모든 편집 내역은 히스토리에 남아 있으므로, 학생들은 원하는 버전의 과제(또는 제가 수정하기 전에 제출했던 버전)를 자유롭게 사용할 수 있었습니다. 여전히, 문제를 기억하기 위해 1년을 기다리는 대신 강의 진행 중에 바로 개선하는 것은 훌륭한 아이디어였다고 생각합니다.

4개의 좋아요