Piazza, 유료 모델로 전환 — 논의의 기회

일반
1

교육 분야에 종사하시는 분들 중 다음 달부터 Piazza가 유료 모델로 전환된다는 소식을 보신 분들이 계실 것입니다.

교육자이자 Discourse의 열렬한 팬으로서, 개발자들이 이 상황을 Discourse가 교육 분야로 진출할 수 있는 큰 기회로 삼아주기를 바랍니다. 저는 이를 뒷받침할 수 있는 세 가지 방법을 떠올려 보았습니다:

  • 자체 호스팅(self-hosted) Discourse 인스턴스를 설정하려는 교수님이나 IT 담당자를 위한 훌륭한 안내 자료를 제공하는 것입니다. (자체 호스팅은 FERPA 관련 많은 문제를 해결해 줍니다.) 정말로 초보자도 쉽게 따라 할 수 있는 수준이어야 합니다. 기억하세요: 이분들은 평소 아무것도 설정해 본 경험이 없는 경우가 많으며, 바로 이것이 처음 Piazza를 선택한 이유이기도 합니다. 아마도 이러한 설치에 대한 원격 지원을 유료로 제공하는 방식도 가능할 것입니다.
  • 교육에 특화된 유료 패키지입니다. Piazza와 유사한 기능을 재현하여 전환을 용이하게 해줄 수 있는 공통 플러그인 세트가 있을 것입니다. FERPA 요건을 충족해야 합니다.
  • 한 학과가 여러 강좌를 지원하기 위해 하나의 Discourse 설치로 다중 사이트(multisite)를 구성하고 싶어 할 수 있으므로, 다중 사이트 지원을 개선해야 합니다.

또한 가격 모델을 검토해야 합니다. Piazza는 학과 단위 라이선스가 꽤 비싸고, 제 이해로는 해당 라이선스가 그 학과 소속 _학생들_만 커버하기 때문입니다. 따라서 해당 학과가 아닌 학생들이 학과 강좌를 수강하는 경우엔 포함되지 않습니다. 이는 다소 명백하고, 솔직히 꽤 서투른 수익화 시도라고 볼 수 있습니다. 많은 학과가 다양한 배경을 가진 학생들에게 수업을 가르치는데, 오직 자기 학과 학생들에게만 무료로 강좌 포럼을 제공한다는 것은 시각적으로도 매우 좋지 않은 인상입니다. 예를 들어, 최대 3,000명까지 지원하는 학과 단위 라이선스는 연간 12,000달러입니다. 반면, 적절하게 다중 사이트 구성을 한다면 동일한 규모의 사용자를 쉽게 지원할 수 있을 것으로 추정되는 Discourse 엔터프라이즈 플랜은 3,600달러입니다.

어쨌든 저는 이미 매우 만족스러운 Discourse 사용자이므로, Piazza의 이런 혼란스러운 상황은 그저 팝콘을 먹으며 구경하는 입장입니다 :slight_smile:. 하지만 Discourse가 이 분야에서 성과를 거두기를 응원하겠습니다. 전반적으로 포럼으로서 이미 Piazza보다 10년 앞서 있다고 생각하지만, 이제 수익원이 생겼으니 그들이 실제로 사이트를 업데이트하기 시작할 것으로 예상합니다.

그런데 다른 교수님들의 의견이 궁금합니다. 여러분 기관에서는 이 변화에 대해 어떤 논의가 이루어지고 있나요?

14개의 좋아요
2020: The Year in Review
Feature: endorse button to add single-click endorsements
2

교육 기관이 온라인 토론에 Discourse를 더 많이 활용하는 모습을 보면 좋겠습니다!

한 가지 주목할 점은, 저희 호스팅에서 비즈니스 플랜이 연간 3,600달러(월 300달러)라는 것입니다. 저희 가격 정책은 사이트의 사용자 수를 기준으로 하지 않습니다. 대신 페이지뷰, 저장 공간, 플러그인을 기준으로 합니다. 3,000명의 학생에게는 비즈니스 플랜이 충분할 가능성이 높습니다. 엔터프라이즈 호스팅은 이보다 비용이 더 비싸며, 가격은 사이트의 요구 사항에 따라 달라집니다. 호스팅 플랜에 대한 자세한 내용은 여기에서 확인하실 수 있습니다: Discourse pricing | Discourse - Civilized Discussion.

Discourse는 오픈 소스 소프트웨어이므로, 별도의 비용 없이 자체 서버에 설치할 수 있습니다.

11개의 좋아요
3

왜 이것이 필요할까요? Discourse에는 이제 카테고리별 модератор(중재자) 기능이 있습니다. 각 부서에 적절한 카테고리(들)를 할당하고, 해당 부서의 카테고리에서 교수님들에게 중재자 권한을 부여하면 됩니다…

8개의 좋아요
4

궁금한 건데, 기능적으로 Piazza가 Discourse보다 할 수 있는 것이 뭐가 있나요?

6개의 좋아요
5

저는 Discourse를 지원하며 생계를 유지하고 있으며, 과거 교육자이자 교사 교육자(교육대학 교수)였습니다. 많은 기업들이 학교에 어떤 것들을, 그리고 얼마나 많은 돈을 지불하게 하는지, 그리고 그 방식이 어떤지 볼 때마다 놀라움을 금치 못합니다. 제 판단으로는 이 회사들은 마케팅에 어마어마한 돈을 쓰는 것 같습니다. 왜냐하면 그들의 제품과 지원 서비스는 대체로 매우 좋지 않기 때문입니다.

그리고 FERPA(가족 교육권 및 비밀유지법)에 대해 말하자면, 제 아내가 "귀하의 자녀에 대해 <도서관 책, IEP(개별 교육 계획), 정학 등 FERPA 위반 사항 삽입>"라는 이메일을 얼마나 자주 받는지도 놀랍습니다. 어떤 기관들은 이메일 주소조차 없기 때문이죠.

멀티사이트는 필요하지 않습니다. 기존 인증 시스템과의 통합을 통해 그룹과 범주를 구성할 수 있는 수단이면 충분합니다. 특히 많은 학교 기술 담당자들이 이를 가능하게 하는 데 도움을 줄 수 없거나 원하지 않기 때문에, 해당 시스템과의 연결이 가장 어려운 부분입니다. 아마도 멀티사이트가 해결책이라고 생각하시는 이유는, 각 교사에게 자신의 사용자를 관리할 권한과 책임을 부여할 수 있기 때문일 것입니다. 만약 학교가 Google 인증을 사용한다면, 교사가 누가 가입하는지 승인만 하면 되므로 여전히 합리적인 해결책이 될 수 있습니다.

하지만 제가 너무 벗어난 것 같습니다.

그것들은 무엇인가요?

6개의 좋아요
6

교육 현장에서 이것이 얼마나 큰 장벽인지를 과소평가하지 마세요. 저는 1,000명의 학생이 있는 제 클래스를 위해 서버 몇 대를 확보하려고 뛰어다니고 주먹을 쾅쾅 두드리며 애를 썼습니다. 최상위권 CS 기관의 다른 교수님들과도 이야기해 보았는데, 많은 분들이 학부에서 AWS를 사용하도록 강제받거나, 혹은 중요한 강의 인프라를 사무실 근처 옷장 안에 있는 낡은 노트북으로 돌리는 경우가 많습니다. 이 고충은 실재합니다. 그래서 저는 Discourse를 돌릴 기계가 있다는 것만으로도 운이 좋은 편입니다!

몇 가지가 있습니다. 다만 (1) 저는 가능한 한 Piazza를 피하고 있고, (2) 최신 Discourse 기능과 플러그인 기능에 대해 100% 최신 정보를 가지고 있지 않다는 점을 염두에 두시기 바랍니다. 하지만 제 판단에 따르면 그 격차가 있는 부분은 다음과 같습니다.

Piazza는 다양한 유형의 익명성에 대한 지원이 더 좋습니다. 예를 들어, 교수님께는 보이고 다른 학생들에게만 익명으로 보이게 하는 것 등이죠. 또한 게시물별로 이를 설정할 수도 있습니다. 제 IT 담당자들은 비교했을 때 Discourse의 지원 방식을 어색하게 표현했습니다. 저도 동의합니다. 학생들이 사용하는 법을 깨닫는 데 오랜 시간이 걸리고, 깨닫게 되면 긴 기간 동안 익명 모드로 완전히 사라지는 경향이 있습니다. 예를 들어, 이번 학기에 정말 도움이 되었던 학생이 anonymous246이라는 이름으로 수백 개의 질문에 답변을 해 주었습니다. 저는 그에게 상을 주고 싶지만, 그가 누구인지 알지 못합니다. (네, 제가 알아낼 수 있다는 것은 알고 있습니다.) 하지만 더 유연한 익명성 기능이 있다면 큰 개선이 될 것이라고 생각합니다.

기억이 맞다면, 학생들에게는 모든 스태프에게 직접 게시되되 다른 학생들에게는 숨겨지는 방식도 있는 것 같습니다. 이는 다른 학생들과 공유해서는 안 되는 정보를 공개해야 하는 질문(예: 코드 스니펫)을 할 때 좋은 방법입니다. 저는 이전에 이 기능을 카테고리별 “게시 전용” 권한의 형태로 여기서 요청한 적이 있지만, 응답은 "이미 있습니다, 메시지 기능입니다"였습니다. 불행히도 메시지는 주제(Topics)와 동일한 방식으로 UI에 통합되지 않지만, 이것이 저만큼 다른 사람들에게도 문제가 될지는 모르겠습니다.

Piazza에는 교수와 학생이 “협업으로” 그룹 게시물을 편집하는 곳도 있습니다. 그 기능을 그리워한다는 사람은 한 번도 들어본 적이 없습니다. 하지만 일부는 원할 것이라고 가정합니다. 아마 Discourse에는 이미 이런 기능이 있을까요? 저는 이를 원하지 않아서 이전에 찾아본 적이 없습니다. 제 생각에는 이것은 Piazza의 기능이 아니라 버그입니다. 제 수업에서 정답이 있는 질문은 매우 적으며, 정답에 도달할 수도 있고 아닐 수도 있는 논의를 장려하고 싶습니다. 우리는 이를 위한 버전으로 Solved 플러그인을 사용하고 있으며 잘 작동합니다.

네, FERPA에 대한 공포(FERPAnoia)는 실재합니다. 제 기관에서는 꽤 만연해 있습니다. 자체 호스팅(Self-hosting)은 이를 우회하는 좋은 방법입니다. 그 이후에 외부 호스팅 옵션을 위해 무엇을 제공해야 하는지는 잘 모르겠습니다. 기관마다 FERPA를 해석하는 변호사 그룹이 다르며, FERPA에 대한 공포의 정도도 제각각인 것 같습니다.

카테고리별 관리자 시스템이 어떻게 작동하는지 제가 잘 모르는 것 같습니다.

네, 동의합니다. 하지만 이것이 반드시 필요한가요? 왜 Discourse의 내장 인증을 사용하지 않나요? 그것이 바로 Piazza 모델입니다.

제 기관에는 Google Apps 통합 기능이 있어 Shibboleth 대신 Google 로그인 플로우를 사용할 수 있습니다. 그렇다고 해도, 여기서 Shibboleth 플러그인이 광고되고 있는 것을 봤지만 아직 시도해 보지는 않았습니다.

5개의 좋아요
7

제가 마지막으로 일했던 기관에서는 어디에도 서버를 사용할 수 없게 했기 때문에, 결국 제 Discourse 인스턴스를 Digital Ocean(아니면 아마도 AWS 무료 티어)에 두게 되었습니다.

사람들이 언제 익명을 원하게 되는지 이해가 되지 않습니다. 또한 이는 책임 소재 문제에서도 큰 이슈인 것 같습니다.

완전히 다른 플로우로 만들어지는 것이 합리적이라고 생각합니다. 그래야 누가 대화에 참여하고 있는지 명확해지니까요. 익명으로 기여하는 사람이라는 당신의 예시는, 공개, 비공개, 익명인 것을 혼동하기 쉽게 만드는 것이 왜 좋지 않은지를 보여주는 예시인 것 같습니다.

위키 같은 거죠?

계정, 사용자 이름, 비밀번호를 또 하나 만들어야 하는 것은 귀찮기 때문입니다.

그렇게 하면 꽤 쉬워집니다. 저는 몇몇 기관에서 Shibboleth 설정을 도와준 적이 있습니다. 쉽지 않았지만, 한 번만 하면 되는 일입니다.

교육에 특화된 지원을 갖춘 서비스를 연 몇백 달러에 만들 수 있을 것 같은 상상은 해볼 수 있습니다. 하지만 Communiteq(구 DiscourseHosting)에서 월 $20에 호스팅을 받을 수 있습니다. 그리고 당신이 지적했듯이, CDCK에서의 호스팅은 Piazza가 청구하는 금액과 비교하면 bargain(매우 저렴한 가격)입니다.

1개의 좋아요
8

몇몇 학생들은 대규모 공개 포럼에서 질문하는 것에 대해 긴장합니다. 이는 실제 존재하는 문제입니다. 익명 게시는 이러한 긴장을 완화하는 데 도움이 됩니다. 또한, 같은 반 학생들에게는 익명으로 유지하되, 도움을 제공할 때 과목 담당 교직원은 신원을 확인할 수 있도록 하는 것입니다.

8개의 좋아요
9

궁금한 점이 있는데, 익명이란 정확히 무엇을 의미하나요?

예를 들어, 저는 사용자가 익명 사용자명을 사용하고 개인 식별 정보를 제공하지 않도록 장려하는 사이트를 하나 운영합니다.

즉, 동료 간 익명성을 구현하는 것은 기본 설정일까요 - 그냥 실명을 쓰지 않으면 되는 건가요?

물론 검증 가능한 이메일 주소를 제공해야 하지만, 이는 어떤 경우에도 다른 사용자에게 노출되지 않습니다.

아마도 Piazza가 하는 일은 개인의 선호도에 따라 앱 내에서 서로 다른 신뢰 수준에 대해 다양한 수준의 개인 식별 정보(PII)를 노출시키는 것일까요? 일단 플러그인의 영역에 해당하긴 합니다만 …

7개의 좋아요
10

네, 정말 멋진 아이디어네요.

실제 학교 계정과 연결된 신원 정보를 원합니다. 이는 Piazza가 요구하지는 않지만, FERPA(가족 교육권 및 비밀유지법)를 우회하는 방식이라고 생각합니다. 그렇지 않으면 Piazza가 수업 명단을 재구성할 수 있기 때문이죠. 이는 허용되지 않습니다. 따라서 대부분의 학생이 Piazza 가입 시 공식 학교 이메일과 신원 정보를 사용하는 것 같지만(아마도 익명 기능 때문일 것입니다), 제가 강의하는 곳에서는 버너 이메일(일회성 이메일)을 선택하여 사용할 수 있습니다.

신뢰 수준도 교육적 용도를 지원하려면 의도적인 설정이 필요한 또 다른 부분입니다. 자연스럽게 작동하는 방식은 학생들이 시간이 지남에 따라 더 고급 권한을 획득하게 되는데, 이로 인해 이상한 상황이 생길 수 있습니다. 일부 학생은 사이트에 많은 시간을 보내게 될 것이고, 방치하면 높은 신뢰 수준까지 올라갈 것입니다. 제 해결책은 (기억이 맞다면) 2단계와 3단계 사이에 단단한 신뢰 경계를 설정하고, 모든 스태프는 3단계에서 시작하도록 하는 것입니다.

3개의 좋아요
11

그건 말이 안 됩니다. 모든 LMS(학습 관리 시스템)는 수강생 명단을 알고 있습니다.

4개의 좋아요
12

많은 교육 기관이 Google Workspace를 사용하며, 온라인 토론을 위해 Google Currents를 활용하고 있습니다. 만약 Discourse가 어떤 방식으로든 이러한 교육 기관들의 전환을 이끌어낼 수 있다면 정말 훌륭할 것입니다!

Google Classroom은 Discourse가 직면해야 할 또 다른 장벽입니다. Discourse가 Google 서비스와의 통합을 어떻게든 재현할 수 있다면 더욱 좋을 것입니다. Discourse는 과제 생성, 배포, 채점 기능을 비롯해 학생들을 위한 통합 할 일 목록 등 다양한 기능을 갖추고 있어야 합니다.

그다음에는 Microsoft와 Apple의 동등한 도구들에도 동일한 통합을 적용하면 됩니다. :sweat_smile:

어쨌든, 저는 교육 기관을 위한 도구로서의 Discourse에 대한 확신을 가지고 있습니다. 이는 어색하지 않은 토론(고등학교 등 교육 현장의 중요한 부분)을 촉발하는 데 도움이 될 것입니다.

3개의 좋아요
13

제 생각에는 LMS가 보통 캠퍼스 내에 호스팅되는 경우가 많다는 거예요. 이건 큰 차이가 있죠. 아니면 모두 FERPA(가정교육권 및 프라이버시법)의 "인정"을 받은 건지, FERPA는 실제 존재하는 제도이지만 제가 잘 이해하지 못 하는 부분이거든요. (종류의 안수 기원? 향이 나는 오일? 궁금하네요…)

일화 하나를 들려드릴게요: 저는 각 저장소가 루트 디렉터리에 email.txt 파일을 통해 각 학생을 식별하는 GitHub Classroom을 사용했다는 이유로 동료들에게 공격을 받은 적이 있습니다. 왜냐하면, 아마도 GitHub가 개인 저장소 접근에 관한 모든 TOS(이용약관)를 위반한다면 수백 개의 저장소를 훑어보며 수강 명단을 복원할 수 있기 때문이겠죠. 진짜로요. (이번 학기에는 고유 ID로 전환했지만, 분명 다른 걱정거리를 찾을 거라고 확신합니다.) 교육 목적으로 명확히 의도된 제품(GitHub Classroom)이 전 세계 기관에서 활발하게 사용되고 있음에도 불구하고, FERPA가 해석의 여지가 너무 넓어 결국 (우리 변호사들에 의해) FERPA 리스크로 간주된다는 사실도 정말 이해가 안 됩니다. 한숨.

1개의 좋아요
14

제 생각에는 거의 캠퍼스에 호스팅되지 않는 것 같습니다.

제 아내가 다니는 대학은 학생들이 그 학교에 다니고 있다는 친밀한 세부 정보를 제 아내에게 보내는 곳이기도 한데, 같은 곳에서 그런 법규를 준수하기 위해 실제 업무를 수행하는 것을 막는 규칙도 갖추고 있을 것이라고 확신합니다.

아니, 제 아내의 대학은 모든 강의의 모든 자료가 장애 접근성 기준을 충족해야 한다고 결정했는데, 실제로는 그렇지 않은 경우가 많아서 제 아내는 영상은 물론이고 가능하면 이미지조차 사용하지 않습니다. X-ray를 해석할 수 있는지 확인하는 것이 이미지의 목적이었다는 점을 무시하고, 이미지에 대한 설명용 대체 텍스트(alt-tag)를 포함하지 않았다는 이유로 간호학과를 비난한 적도 있었습니다.

또한 남부의 한 대학에 취업한 변호사 친구가 있습니다. 그곳에서는 대학이 음료를 구매하는 것이 "불법"이라고 믿는 사람들이 많았는데, 그 결과 이를 우회하기 위한 복잡한 꼼수들이 횡행했습니다. 친구가 확인해 보니, 그것은 법이 아니라 한때 어떤 회계사가 만들어낸 것에 불과했습니다.

저는 수강 명단 관련 문제는 완전히 터무니없다고 말하고 싶습니다. 그리고 그것이 제가 더 이상 대학에서 일하지 않게 되어 다행이라고 느끼는 이유 중 하나입니다.

6개의 좋아요
15

네, 충분히 이해합니다. 실제 서버가 어디에 있는지도 모르겠고, FERPA가 제3자로 보는 것이 무엇인지도 잘 모르겠습니다.

저희 기관과 학과는 이 문제에 대해 꽤 우려하고 있습니다. 다른 많은 기관들은 그렇지 않을 겁니다. 하지만 예외 상황을 대비한 준비 차원입니다.

5개의 좋아요
16

여기에 큰 기회가 있다고 생각합니다. 다만 '멀티 코스(multi-course)'가 정확히 무엇을 의미하는지(여러 인스턴스, 카테고리, 아니면 다른 것?)를 먼저 고려해 봐야 할 것 같습니다.

Discourse의 ‘Solved’ 기능, Wiki 게시물, 기본값 조정을 활용하면 상당한 노력 없이도 Piazza와 유사한 환경을 충분히 구현할 수 있습니다. Discourse는 이미 SAML과 OAuth를 통한 SSO를 지원하여 대부분의 교육 기관 제공업체를 커버합니다. LMS 통합과 같은 경우 LTI 플러그인이 존재하지만, 아직 사용해 본 적은 없습니다.

법적 문제에 관해서는: 셀프 호스팅은 좋은 선택지입니다. 온프레미스든 퍼블릭 클라우드든 마찬가지입니다. 하지만 FERPA의 경우, 교육 기관과 계약을 체결할 의사가 있는 회사가 필요합니다. 학교가 계약을 체결하면 데이터가 앱으로 어떻게 흐를지 결정할 수 있게 되며, 대부분 계약이 PII(개인식별정보) 관련 절차를 단순화해 줍니다. 솔직히 말해, Discourse가 다른 수업 토론 도구보다 더 복잡하다고 보지는 않습니다.

4개의 좋아요
17

멀티 코스는 그냥 카테고리랑 그룹일 뿐이라고 생각해요. 그렇게 어렵지 않거든요.

무언가를 제공하긴 하고 싶지만, 어떻게 마케팅해야 할지 감이 전혀 안 잡혀요.

4개의 좋아요
18

그것은 하나의 모델이다. 하지만 전체 포럼을 오직 그 용도로만 사용하면서 완전한 제어를 원할 수 있는 코스들도 많이 있을 것이라고 생각한다. 그들은 또한 설정을 다르게 구성하거나, 다른 플러그인을 사용하거나, 모더레이션(운영 정책)에 관한 자체적인 정책을 갖고 싶어 할 수 있다.

또한 ‘코스를 카테고리로 보는’ 모델에서 검색 기능이 어떻게 작동할지我也不 확신하지 못한다. 수강 중인 코스가 아닌 다른 코스에서 검색 결과가 나오면 꽤 혼란스러울 것이다. 하지만 카테고리 권한이 적절하게 설정된다면 이 방식도 잘 작동할 것이다. 아마도 이를 위해 어떤 자동화 기능이 필요할 것이다.

여기서 빠져 있는 또 다른 기능이자, ‘코스를 카테고리로 보는’ 모델을 복잡하게 만들 수 있는 요소는 매 학기마다 포럼을 주기적으로 리부팅해야 하는 필요성이다. 이것은 아마도 일반적인 Discourse 포럼 사용 방식과는 다를 것이다. 하나의 접근 방식은 포럼 전체를 리부팅하고 처음부터 다시 시작하는 것이다. 그러나 연속성이 있는 것이 좋은 특정 영역들이 있다. 예를 들어, 우리는 코스 스태프 전용 비공개 카테고리가 있으며, 그곳의 과거 대화들을 잃고 싶지 않다. 하지만 학생들에게 지난 학기에 대한 게시글로 가득한 포럼을 보여주는 것도 보통 원하는 방식은 아니다.

우리는 매 학기마다 학기별로 구분된 완전히 새로운 카테고리 트리를 설정하고, 학생 계정들이 자신의 학기에 해당하는 내용만 볼 수 있도록 권한을 설정한다. 졸업생들은 자신의 학기 동안의 콘텐츠를 계속 볼 수 있고, 스태프는 스태프 전용 카테고리를 포함해 거의 모든 것을 볼 수 있다. 이것은 우리에게 잘 작동하지만, 코스 소속이 변경될 때(특히 학기 초에는 시간 단위로 변경이 발생한다) 모든 것을 동기화하기 위해 꽤 지저분한 cron job 스크립트가 필요하다.

4개의 좋아요
19

맞습니다. 그래서 저는 Discourse를 사용하기 시작했습니다. 교수진이 LMS를 직접 작성한 것은 아닙니다. 교수진 한 명이 이를 위해 학기당 얼마를 지불할 의향이 있다고 생각하시나요?

기관 차원에서 이를 적절히 해결하는 방법은 수강 등록을 관리하는 시스템이 수강 명단이 변경될 때 API 호출을 수행하도록 하는 것입니다. 하지만 이는 유능하고 지원이 가능한 기술 인력이 필요하기 때문에 많은 학교에서 실현하기 어렵습니다.

개별 강의 수준에서는 단순히 수동으로 처리하면 됩니다.

저는 "새 학기 문제"에 대한 해결책으로, 각 강의 섹션마다 새로운 카테고리과 그룹을 생성하는 방식을 사용하고 있습니다. 학기 간 공유되는 강의 콘텐츠에는 읽기 전용 카테고리를 사용했습니다. 대부분의 LMS는 이 부분을 매우 부실하게 처리합니다. 새 학기를 위해 강의를 준비하는 데는 막대한 노력이 듭니다.

말씀하신 대부분의 사항은 개별적인 해결책은 쉽게 찾을 수 있지만, 보편적인 해결책을 찾기 어려운 경우가 많습니다.

그리고 학교에서 사용하는 소프트웨어의 고객은 사용자인 교수나 학생이 아니라, 교수나 학생의 문제를 제대로 이해하지 못하는 경우가 많은 관리자들입니다.

5개의 좋아요
20

이상적으로는 아무것도 안 내는 게 좋죠 :slight_smile:. 하지만 월 몇 달러 정도라면 괜찮지 않을까요? 디스코르스(Discourse) 호스팅 요금제는 꽤 합리적인 편입니다.

여기서 하나의 문제는, 제 생각에는 많은 교수님들(저를 포함해서)이 독립적인 수업 기술 구매를 위한 예산이 사실상 없다는 점입니다. 저는 직원 인건비나 개인 기술(새 노트북 등)에는 돈을 쓸 수 있습니다. 하지만 제 수업만을 위한 기술 구매 예산은 없습니다. 이는 거의 말이 안 되지만, 반드시 드문 일은 아닙니다. 그래서 제가 월 5달러 정도인 무언가를 원한다고 해도, 그 비용은 수업 예산이 아니라 제 개인 자금에서 나가는 셈이 됩니다.

사실 더 나은 해결책은 디스코르스 SSO API를 사용하여 로그인 시 그룹을 할당하는 것일 수 있습니다. 적어도 여기서는 완전히 가능하며 꽤 깔끔할 것입니다.

디스코르스 API를 이렇게 사용하는 데 우리가 겪은 문제 중 하나는 동기화를 수행하기 위해 필요한 호출들이 느리다는 점입니다. 특히 1만 건의 호출을 수행할 때 그렇습니다. 이 프로세스가 내장된 한도에 도달하지 않으면서도 사용자가 500 에러를 받지 않도록 속도 제한을 걸면, 완전한 사용자 동기화에 약 1시간이 걸립니다. 제 수업만 위한 것이므로 괜찮지만, 이를 학과 전체 규모로 확장하기 시작하면 허용할 수 없을 정도로 느릴 것입니다. (참고로 제가 사용하지 않는 일괄 동기화 인터페이스가 있을 수도 있고, 동기화 클라이언트에서 이러한 호출 중 일부를 피하기 위해 올바르게 처리하지 못하고 있을 수도 있습니다.)

+1입니다.

5개의 좋아요