전적으로 이해합니다.[1] 저는 Discourse를 정말 좋아합니다 이 글을 쓴 이유는 Discourse가 지속적인 성공을 거두기를 원하기 때문입니다.
제가 배운 것은 커뮤니티가 변화를 좋아하지는 않지만, 그들이 주도권을 가졌다고 느끼면 변화에 훨씬 더 개방적이라는 점입니다. 사람들에게 주도권을 부여하는 방법은 무궁무진합니다. 예를 들어, 튜토리얼을 위키 게시물로 전환하면 저 같은 사람들이 이를 업데이트할 수 있습니다. ESR 계획을 구현하는 것도 도움이 되는데, 이는 사람들이 즉시 변경 사항을 적용하지 않을 선택지를 주기 때문입니다.[2] 제 경험을 작성하여 오픈소스 프로젝트를 관리하는 사람들에게 보여줄 수 있는 것도 도움이 됩니다. 특히 제가 불평했던 문제들이 하룻밤 사이에 수정되었기 때문입니다. 
"사용자 청취가 해롭다고 생각되나요?"라는 글에서[3] 캐시 시에라(Kathy Sierra)는 이렇게 썼습니다:
우리 대부분은 포커스 그룹이 많은 측면에서 notoriously 비효율적이라는 것을 인식하지만, 여전히 실제 사용자로부터의 실제 피드백을 청취하는 것이 새로운 제품과 서비스를 주도하고 기존 것을 개선하는 최선의 방법이라고 가정합니다. 그러나 여기에는 큰 문제가 있습니다 – 사람들은 자신이 상상해 본 적이 없는 것을 어떻게 요청해야 하는지 반드시 알지 못합니다! 대부분의 사람들은 점진적인 개선에 기반하여 제안을 합니다. 존재하는 것을 보고 그것이 어떻게 더 나아질 수 있을지 생각해보는 것이죠. 하지만 그것은 근본적으로 새로운 무언가에 대한 비전을 가지는 것과 매우 다릅니다.
진정한 혁신은 사용자가 직접 말하는 것에서 거의 나오지 않습니다.
말했듯이, 저는 프론트엔드 개발자가 아닙니다. 왜 이러한 변경 사항이 이루어졌는지 또는 그것이 저에게 어떤 이점을 줄지 정확히 이해하지 못합니다.[4] 그리고 그것이 궁극적으로 Discourse를 더 좋게 만든다면 괜찮습니다.
그래도, 비전을 조금 더 명확하게 볼 수 있다면 저 같은 사람들이 적응하는 데 도움이 될 수 있습니다. 이 변경 사항에 대한 제안은 다음과 같습니다:
- 훨씬 더 나은 개발 경험
- 향후 버전의 Discourse에서 대규모 성능 향상을 가능하게 함
좋아 보이긴 하죠? 저는 #1과 #2가 많은 것을 의미할 수 있다는 것을 특별히 인지하지 못했습니다. 저에게 더 효과적인 것은 다음과 같은 것일 것입니다(전적으로 제가 지어낸 것입니다):
- 공식 Discourse 플러그인을 변환할 때 코드 라인 수를 X% 줄인 것을 발견했습니다. 템플릿을 JavaScript와 동일한 파일에 두면 코드를 이해하고 나중에 수정하기가 더 쉬워집니다.
- Handlebars를 완전히 제거하는 것을 테스트하는 브랜치를 설정했는데, 그 변경 사항으로 페이지 로딩이 X% 빨라지는 것을 발견했습니다. 뿐만 아니라, [사용자들이 제기한 일부 문제]를 제거할 수 있는 잠재적 최적화도 발견했습니다.
비전문가를 교육하는 데 초점을 맞춘 조금 더 자세한 설명은 신뢰를 유지하는 데 큰 도움이 됩니다. 저는 변경 사항을 좋아하지 않을 수 있지만, 다른 사용자가 직면한 실제 문제를 수정하는 것과 어떻게 논쟁할 수 있겠습니까?
OpenSSL도 비슷한 동력을 가지고 있습니다. 지원 계약을 판매하는 법인(약 15명)과 비상업적 이익을 관리하는 재단(저를 포함하여 10명)이 있습니다. 우리의 문서도 뒤처져 있습니다. 원본 글을 작성하면서 지난월에 제거된 기능에 대한 참조가 여전히 남아있다는 것을 발견했습니다. 이를 위한 PR을 작성하고 있습니다. 또한 하류 프로젝트들이 매우 비판적으로 평가한 몇 가지 변경 사항을 수행했습니다. ↩︎
최신 기능을 선호하는 커뮤니티를 지원하려는 플러그인 개발자에게는 도움이 되지 않습니다. 하지만 제 플러그인을 사용하는 유일한 사람이라고 생각하므로 저에게는 매우 좋습니다. ↩︎
큰 그림에서 제가 그렇게 중요하지는 않다는 것을 알면서도요. 저는 Discourse에 의존하는 다른 사람들을 대변하는 제 자신에 대해 이야기하고 있습니다. 결국, 대부분의 사람들보다 제 자신을 더 잘 알고 있으니까요! ↩︎