이것이 바로 디스코urs 문서화의 문제입니다.
일부 사용자들이 주제들을 찾아다니는 것이 “괜찮을” 수 있지만, 그것은 문서가 아닙니다. 사용자들이, 더 나쁜 것은 관리자/모더레이터들이 정보를 찾아다녀야 한다는 것입니다.
네, 그렇습니다. 그리고 이것은 과거에도, 그리고 현재에도 Discourse의 가장 큰 단점이었습니다. 제가 지금 너무 무례한 건지 모르겠지만, 여기서는 개발자 중심적인 태도가 너무 강합니다. 모른다면 항상 GitHub에서 소스를 읽을 수 있다고 생각하는 경향이 있죠. CDCK는 사용자를 위한 좋은 문서를 만들려는 동기가 별로 없습니다 — 물론 관리자들도 포함해서요 — 왜냐하면 그들의 목표는 호스팅되는 대기업들이기 때문입니다. 따라서 그들에게는 최소한의 수준과, 버그 헌팅과 UX 제안의 큰 부분을 담당하는 무임승차자(들)에 대한 커뮤니티의 도움이 충분했습니다. 다만, 그렇게 하려면 태그의 더 자유로운 사용이 필요했을 텐데요…
*충분했다(Was enough)*는 단순한 오타나 영어 실력 부족이 아니었습니다. CDCK/팀이 더 나은 문서를 구축하기 시작했고, 시간이 좀 지나면 이러한 부수적인 주제들은 과거의 잔향으로만 남을 것이라고 확신합니다.
4개의 좋아요
개발자/사용자 커뮤니티로서의 디스코스는 평균 이상입니다. 오류는 빠르게 수정되고, 기능 요청도 무시되지 않으며, 특히 합리적인 사용 사례가 있는 경우 더욱 그렇습니다. 온라인 스태프(유급인지 자원봉사자인지 구분이 잘 안 되지만)는 초보자인 우리를 지도하는 데 꽤 잘하고 상당히 인내심이 있습니다.
네, 문서가 좀 더 개선되어야 하지만, 좋은 문서를 작성하는 것은 비용이 많이 들고 시간이 걸립니다. 게다가 개발자들은 제품에 너무 가까이 있기 때문에 사용자가 보는 관점을 이해하지 못해 좋은 문서를 작성하지 못하는 경우가 많습니다. 코드에 너무 가까이 있는 것은 제품 테스트에도 문제가 되지만, 많은 오픈소스 프로젝트에서는 사용자 커뮤니티가 테스트를 잘 수행합니다.
5개의 좋아요
물론이죠. 좋은 코드를 작성하는 것도 마찬가지입니다. 고품질의 인간적 노동은 대체로 비싸기 마련이죠. 하지만 코드와 문서는 서로 밀접하게 연결되어 있으며, 아무도 문서를 작성하지 않을 때 비로소 그 비용이 치솟기 시작합니다. 그렇지 않다면 문서화는 코딩, 테스트, 디자인, UX/UI 등 제품에서 코딩만큼이나 필수적인 부분입니다. 하지만 개발자들은 문서를 작성하는 것을 싫어하는 경우가 많습니다. 그건 그저 하기 싫어서일 뿐 아니라, 그다지 매력적인 작업이 아니기도 하고, 실제로 문서를 잘 쓰지 못하는 경우도 많으니까요. 
하지만 회사 소유주나 다른 관리자들이 역시 개발자 출신인 경우가 많아서, 직원들이 하고 싶은 것만 고르면서 하고 싶지 않은 것은 하지 않는다는 사실을 별로 신경 쓰지 않습니다.
하지만 이제 너무 일반적인 이야기로 흘러가서 주제에서 많이 벗어난 것 같습니다. 그래서 이만 물러나고, 지금 활발하게 논의되고 있는 Documentation(문서화) 태그를 가리켜 둘게요.
1개의 좋아요
이 말에 전적으로 동의합니다. 저는 이미 20년 이상의 경력을 가진 개발자이며, 최근 몇 년간 플랫폼 엔지니어링으로 전환을 했지만 여전히 개발자의 시각을 유지하고 있습니다.
여기서 제안 사항을 요청했을 때, 개발자들(제 추측으로는, 그들의 직책이 디스커스(Disourse) 자체의 일원임을 알 수 있습니다)가 나타나서 '그렇지 않으며, 그렇게 될 수도 없다’며 '우리가 그렇게 결정했기 때문’이라고 말하는 모습을 보면 이 문제는 매우 명확해집니다.
여기서 잠시 벗어난 이야기(OT)를 하자면,
이미 언급했듯이, 기술 스택에 대해 의견이 있는 것과 제품에 대해 의견이 있는 것 사이에는 차이가 있습니다. 제품은 합리적인 범위 내에서 사용자의 사용 사례(use-cases)에 부응해야 하며, '이건 내 공이고 다른 사람들이 싫어하면 다른 곳으로 가라’는 식이어서는 안 됩니다.
저는 이미 5개의 새로운 프로젝트를 시작했고, 다행히 우리 커뮤니티에서 루비(Ruby)에 대해 약간 아는 분이 계셔서 앞으로 며칠간 디스커스의 기본 플로우를 우리에게 설명해 줄 예정입니다. 이를 통해 우리가 필요한 기능을 제공하는 플러그인 작성을 시작할 수 있을 것입니다. 그중에서도 가장 중요한 것은 카테고리 관리자를(Category Mods) 우스개로 만들지 않는 것입니다.
Users are receiving emails even when everything is set up to not send email notifications 지원 토픽이 조금 변형되어, 각각의 주제에 충분한 공간을 주기 위해 다른 카테고리에 두 개의 새로운 토픽으로 분리했습니다. 
2개의 좋아요
개발자들이 사용자들에게 더 편리한 기능을 제공하는 것보다는 자신들이 흥미를 느끼는 부분에 집중하는 경향이 있는 오픈소스 프로젝트를 하나 떠올릴 수 있습니다. 사용 사례는 항상 관점의 문제이며, 제품 사용자와 개발자는 사용 사례를 바라보는 시각이 다릅니다. 개발자들은 사용자가 수행하는 작업을 ‘그냥 더 많은 데이터’ 정도로 생각하며, 사소한 변경 하나가 사용성에 얼마나 큰 차이를 만들 수 있는지 인식하지 못하는 경우가 많습니다. (저도 시스템 개발을 꽤 해본 입장에서, 그런 태도를 가졌던 적이 있을 거라고 확신합니다.)
아직까지는 Discourse 개발에서 그런 태도를 보진 못했지만, 제가 이곳에 온 지 한 달밖에 되지 않았기 때문입니다.
제품에 너무 가까운 문제와 관련해서는, 요즘 Ruby 개발에 관한 책의 연습 문제를 풀고 있습니다. 간단한 ‘hello world’ 앱을 실행하는 데 어제 3시간이 걸렸는데, 대부분 책에서 AWS IDE(cloud9) 환경에 익숙한 것을 전제로 하고 있었기 때문이었습니다. 저는 아직 그 환경을 갖춰놓지 않아서 무언가를 클릭할 때마다 방금 10분간 입력했던 내용이 사라지는 일이 반복되었습니다.
그리고 작동하는 앱의 미리보기가 브라우저에 표시되지 않는 문제도 있었습니다. 이는 책이 마지막으로 업데이트된 이후 Firefox와 Chrome이 브라우저에 도입한 보안 제한 때문인 것으로 보입니다. 해결책을 웹에서 약 1시간 동안 검색한 끝에 노트북과 데스크톱의 IP 주소를 화이트리스트에 추가하니 해결되었지만, 미리보기를 표시하려면 여전히 추가적인 단계를 거쳐야 합니다.
1개의 좋아요