이 질문은 Discourse의 기능을 얼마나 커스터마이징할 수 있는지, 그리고 그 작업이 얼마나 큰 규모가 될 것인지를 묻는 것입니다.
저는 전문 SF 작가 단위의 기술 팀에 소속되어 있으며, 이 조직은 현재 설립자(이제 떠난 상태)가 작성한 포럼 소프트웨어를 중심으로 운영되고 있습니다. 이 시스템은 낡고 비명을 지르는 asp.net/SQL 서버 환경에서 구동되며, 우리는 다른 플랫폼으로의 마이그레이션에 관심이 많습니다.
이 소프트웨어의 가장 인기 있는 기능 중 하나는 이야기 비평(story critique) 기능입니다. 사용자는 제목과 단어 수를 포함하여 문서를 업로드할 수 있습니다. 현재 피드백을 기다리는 모든 이야기를 보여주는 전용 페이지가 있습니다. 소프트웨어에는 가벼운 게이미피케이션이 내장되어 있습니다: 이야기를 업로드하면 자동으로 토론 스레드가 시작되며, 750자 이상의 응답을 게시하는 사용자에게는 포인트가 부여됩니다. 사용자가 충분한 수의 응답을 받으면, 다른 사용자가 파일을 다운로드하는 것을 막을 수 있습니다.
이야기 다운로드 페이지에서는 각 사용자 이름 옆에 그들이 획득한 비평 포인트 수와 그들의 이야기가 받은 비평 수를 확인할 수 있습니다. 이 두 값은 대략적으로 균형을 유지하도록 설계되었지만, 모두 양심에 맡기는 시스템입니다. 제가 아는 한, 비평을 주지 않으면서 비평만 받은 사용자에게 경고가 내려진 적은 없습니다. 전체적으로 꽤 잘 작동하고 있습니다(위에서 언급한 낡고 오래된 기술 환경 제외).
장기 사용자 중 일부는 인상적인 크레딧 수를 쌓았으며, 우리는 모두의 고득점을 지우는 대신 이 데이터를 새로운 플랫폼으로 마이그레이션하는 데 매우 관심이 많습니다.
제 질문은 다음과 같습니다: 이러한 기능을 Discourse 포럼에 통합하는 것이 얼마나 간단한가요? 이는 맞춤형 플러그인의 범위 내에 있을 가능성이 높나요, 아니면 Discourse와 API를 통해 상호작용하는 별도의 앱이 필요할까요? 도움을 주실 수 있는 모든 조언을 감사히 받겠습니다.
750자 이상의 답변에는 포인트가 지급됩니다(비평 스레드에서 비평이 아닌 게시글을 작성할 수 있는데, 이를 위해 "This is not a critique post"라는 문구를 포함하면 되지만, 실제로 사용된 경우는 본 적이 없습니다). 만약 저자가 자신의 비평 스레드에서 750자 이상의 게시글을 작성한다면, 포인트가 생성되지 않아야 합니다.
이야기의 저자가 판단합니다. 자신의 이야기에 대해 충분한 피드백을 받았다고 판단하는 시점을 저자가 결정할 수 있습니다.
네, 파일은 이야기(Word 문서, RTF 파일 또는 기타 형식)를 의미합니다. 저자가 언제든 누를 수 있는 버튼이 있어 추가 다운로드를 비활성화할 수 있습니다. 공유에 대해 다시 생각하게 된 경우, 아무도 파일을 다운로드하기 전에 이 버튼을 누를 수도 있습니다.
요약하기보다는, 여기 SQL 문구를 제시하겠습니다:
CASE WHEN WordCount < 1001 THEN 0.5
WHEN WordCount BETWEEN 5000 AND 9999 THEN 1.5
ELSE Round([WordCount] / 10000, 0) + 1 END
Richard가 말했듯이, 플러그인에서는 무엇이든 가능합니다. 당신이 제안한 내용은 아마도 몇 시간의 작업이 될 것입니다. 예산에 맞출 수 있는 몇 가지 단축 방법이 있을 수 있습니다. 사용자 지정 배지도 도움이 될 수 있습니다. 새로운 플러그인을 작성한 후, 마이그레이션을 수행할 때 데이터를 가져오는 방식으로 진행하는 것도 확실히 가능합니다.
기존 시스템을 단순히 복제하는 것과 최고의 시스템을 만드는 것은 혼동하지 마세요.
해결됨(solved) 플러그인이나 태그를 사용하여 검토 시간을 끄는 방법을 사용할 수 있습니다.
전체 시스템이 맞춤 제작(bespoke)된 경우, 맞춤형 가져오기(importer)는 일반적으로 1,500달러 정도이며, 필요한 플러그인에는 그 정도 이상의 추가 비용이 들 가능성이 높습니다.
핵심은 커뮤니티에 기여하는 것입니다. 다른 사람들이 여러분의 글을 읽고 개선 방법에 대한 피드백을 준다면, 여러분도 다른 사람들의 글을 읽고 피드백을 제공해야 합니다. 이것이 내장된 Discourse 기능을 통해 모니터링될 수 있다면 좋겠지만, 어떻게 해야 하는지 모르겠습니다.
제 이해로는 좋아요는 게시물의 인기를 보여주는 수단이지만, 제가 이주하려는 시스템은 사용자가 최소한의 노력 기준을 충족했는지를 모니터링하는 방식입니다. 따라서 스토리 스레드에서 특정 글자 수 이상을 포함하고 스토리 작성자가 아닌 사람이 작성한 모든 게시물에 대해 자동으로 한 번만 좋아요가 눌릴 수 있다면, 이는 저희 시스템에 적합할 것입니다. 하지만 이는 좋아요의 작동 방식과 잘 맞지 않는 것 같습니다.