정말 재미있는 아이디어입니다. 스레드가 일정 시간이 지나면 만료되는 텍스트보드나 이미지보드를 연상시킵니다. 다만 "채팅은 불씨, 스레드는 불"이라는 말은 사실이 아닙니다. 사람들은 오히려 주제를 더 깊이 파고들기 위해 채팅으로 분산되는 경우가 더 많습니다. 디스코urs 관리자들도 페이스북 그룹에서 사람들이 같은 행동을 한다는 점을 자주 지적하는데, 이는 거의 동일한 현상입니다. 사람들은 노이즈를 걸러내고 싶어 합니다.
SWI-Prolog 예시를 공유해 주셔서 감사합니다. 이는 디스코urs의 이상적인 활용 사례로 보입니다. 현재 제가 개발 중인 디스코urs 인스턴스는 학생과 학자를 모두 대상으로 하지만, 주로 다양한 네트워크의 연구자들을 위한 허브를 구축하는 데 초점을 맞추고 있습니다.
저희 중 일부는 가르침을 맡고 있으며, 특히 디스코urs가 그룹 멤버십 기반의 비공개 카테고리를 허용하므로 포럼을 교육 도구로 사용하는 것은 훌륭한 아이디어라고 생각합니다. 그룹별 관리 기능은 하위 카테고리(특히, 한 그룹만 독점적으로 사용하는 단일 비공개 하위 카테고리를 교사가 운영할 수 있도록 하는 목적)에 대한 제어권을 위임하는 데 완벽한 매칭으로 보입니다. 저는 확실히 학생과 학자를 하나의 공간에 수용하는 물류 문제를 해결하기 위해 깊이 고민하고 있습니다.
으로 리액션하세요"나 “이 번호로 리액션하면 이 대명사 역할을 받을 수 있습니다”, “이 색상의 원으로 리액션하면 이름 색상을 변경할 수 있습니다”, “이 기능의 업데이트 알림을 받거나, 이 이유로 핑을 받을 수 있도록 하려면 리액션하세요” 등입니다. 이 현상은 아주 오래전부터 지속되어 왔습니다. (제 생각에, 한 가지 부족한 기능은 누군가가 배정해 주지 않는 한 스스로 역할을 참여할 수 있는 내장 방식이 없다는 점입니다.)
많은 노트 작성, PKM, 생산성 SaaS 제품들이 디스코스 포럼을 가지고 있습니다. 예를 들어 Obsidian, Airtable, Figma, RemNote 등이 그렇습니다. 하지만 그중 많은 제품들이 동시에 매우 활발한 디스코드 서버도 가지고 있습니다. 만약 디스코드가 처음부터 포럼 기능을 제공했다면, 각 회사가 디스코스와 디스코드 커뮤니티를 만들었을 때를 상상해 보세요. 디스코스 또는 디스코드를 구현할지, 그리고 왜 둘 중 하나나 둘 다 사용할지에 대한 결정을 내려야 할 시점에, 디스코드가 내장된 포럼 기능을 가지고 있다면 그 결정에 영향을 미치지 않을까요?
).