후속 내용으로, Discourse의 기본 제공 기능을 활용하여 여러분의 요구사항을 가장 잘 충족시킬 수 있는 방법에 대해 제가 구상한 내용을 공유합니다. 이것이 여러분이 정확히 염두에 두고 계신 방식과는 다소 다를 수 있지만, 논의의 출발점으로서 고려해 볼 가치가 있다고 생각합니다.
먼저, 몇 가지 가정(이전제가)을 세웠는데, 이것이 유효한지 아닌지는 확실하지 않습니다. 제가 틀린 부분이 있다면 알려 주십시오:
- 수많은 과정(코스)이 존재할 것입니다(수십 개, 어쩌면 수백 개).
- 과정 설정은 학기 시작 시점에(연 2~4회) 주기적으로, 상당한 규모로 일괄 처리될 것입니다.
- 과정에는 수명(종료 시점)이 있을 것입니다.
- 과정을 관리하는 사람들은 과정을 자체적으로 설정할 수 있는 일부 권한이 필요합니다.
- 과정을 관리하는 사람들은 Discourse 사이트 관리에 대한 경험 제한적이거나 전혀 없을 것입니다.
- 과정을 관리하는 사람들은 기본적으로 자신의 과정만 볼 필요가 있습니다. 예시로 다른 과정을 가끔 보고 싶을 수는 있지만, 그것에 지속적으로 참여할 필요는 없습니다.
- ^ 과정 수강생도 마찬가지입니다.
- 시스템을 전체적으로 관리하는 팀은 매우 소규모입니다.
- 과정에는 하위 카테고리(subcategory)가 실제로 필요하지 않으며, 과정 내부의 콘텐츠를 조직화하는 데는 태그를 사용하는 것으로 충분할 것입니다.
위 가정이 대략 맞다면, 우선 고수준(high level)에서 다음과 같이 제안합니다:
- 최상위 카테고리(top level categories)를 소수로 생성합니다: “현재 진행 중인 과정(Current Courses)”, “지난 과정(Past Courses)”, “예정된 과정(Upcoming Courses)”, 그리고 시스템 자체에 대한 더 일반적인 사항(예: 사이트 사용법)을 위한 하나 이상의 카테고리.
- 홈 페이지 스타일을 “카테고리가 있는 박스(boxes with categories)”로 설정하여 이 카테고리들이 눈에 띄게 표시되도록 합니다.
- 각 과정별로 하위 카테고리를 사용합니다.
- “예정된 과정” 카테고리 내에 과정을 생성합니다.
- 학기가 시작되면 “현재 진행 중인 과정”으로 이동시킵니다.
- 과정이 종료되면 “현재 진행 중인 과정”에서 “지난 과정”으로 이동시킵니다.
- 그룹(Groups)을 사용하여 과정 접근을 제어합니다(자세한 내용은 아래 참조).
접근 제어(Access control):
- 각 과정별로 다음과 같은 그룹 집합을 생성합니다. 예를 들어: foo_interested, foo_enrolled, foo_admin.
- 추가 그룹 두 개를 생성합니다: “browse_courses”와 “browse_past_courses”.
- “예정된 과정”과 “현재 진행 중인 과정”의 카테고리는 해당 특정 과정의 그룹에 속한 사람과 “browse_courses” 그룹에 속한 사람만 접근할 수 있도록 설정합니다.
- “지난 과정”의 카테고리는 해당 특정 과정의 그룹에 속한 사람과 “browse_past_courses” 그룹에 속한 사람만 접근할 수 있도록 설정합니다.
그룹과 과정에 대한 사용자 경험(User experience)
- “예정된 과정” 최상위 카테고리 내에 과정을 탐색하는 방법을 설명하는 고정된 주제(pinned topic)를 배치하고, “browse_courses” 그룹에 가입할 수 있는 쉬운 방법을 제공합니다.
- ^ “현재 진행 중인 과정”도 마찬가지입니다.
- ^ “지난 과정”도 마찬가지입니다.
개별 과정에 대해서는, 과정에 가입하는 방법을 설명하는 고정된 주제를 해당 카테고리에 배치합니다:
- “foo_interested” 및/또는 “foo_enrolled” 그룹에 가입합니다.
- 사이드바에 과정을 추가합니다.
관리(Administration)는 초기에 다소 노력이 필요할 것입니다. 새로운 과정마다 권한이 있는 누군가가 다음을 수행해야 하기 때문입니다:
- 카테고리 생성
- 그룹 생성
- 고정된 주제 생성
- 사람들을 _admins 그룹에 추가
- 자신의 과정을 관리하는 데 필요한 문서 제공
이 중 일부는 가벼운 도구를 통해 자동화할 수 있습니다. 주요 관리 팀이 누구인지에 따라, 처음에는 API를 호출하는 밴드아웃(out of band) 방식으로 시작하는 것이 합리적일 수 있습니다. 또는 Discourse에 테마 컴포넌트나 플러그인으로 내장된 UI 기반의 더 복잡한 도구가 필요할 수도 있습니다. 하지만 저는 여기서 가볍게 시작하고, 먼저 작동하는 프로세스를 정의하는 데 집중한 후, 그 프로세스에 맞춰 도구를 설계하는 것을 제안합니다.
카테고리 확장성(scaling)은 여기서 잠재적인 우려 사항입니다. Discourse는 카테고리 수가 너무 많아지면(수백 개에서 수천 개) 성능과 사용자 경험 측면에서 약간의 거친 부분이 있습니다. 더 많은 카테고리에 접근 권한이 있는 사용자는 이 영향을 더 크게 느끼지만, 접근 권한이 제한된 사용자는 그렇지 않습니다. 제가 개요에서 제시한 대로 카테고리 접근을 제한하는 것이 이 우려를 완화하기 위한 동기 중 하나입니다.
위 내용에 대한 여러분의 모든 피드백과 질문에 매우 관심이 있습니다.