엘시, 안녕하세요! GitHub 플러그인에 대해 말씀하셨는데, 그건 코드 리뷰 플러그인이 아니므로 여기에서 새로운 Contribute > Feature 주제를 개설하시는 것이 좋을 것 같습니다.
매우 열정적인 것 같네요. Discourse Code Review 에 이슈 지원 추가는 PR이 환영되는 사항일 것 같지만, 확신은 없습니다. 혹시 여기에서 계획하신 내용을 좀 더 자세히 설명해 주시면, 커뮤니티에서 누군가가 이를 이어갈 수 있을지도 모릅니다. 예산이 있으시다면 Marketplace 에도 게시하실 수 있습니다.
Hi @tobiaseigen—답장 주셔서 감사합니다. 저는 어떤 Discourse 포럼에서도 관리자가 아니며, 제 제안은 다양한 프로젝트에서 사용자이자 때로는 기여자로 활동하며 반복적으로 겪은 경험에 주로 기반하고 있습니다.
Discourse Code Review를 언급한 이유는, 제가 알지 못하는 현재 유지 관리 중인 다른 프로젝트가 없는 한, 사실상 유일한 Discourse GitHub 통합 기능으로 보이기 때문입니다. 어쨌든, 이 주제를 조금 더 일반적인 내용으로 바꾸기 위해 제목을 변경할 예정입니다.
기본적으로 문제는 트리아지(triage)에 있습니다. Discourse 인스턴스와 공개된 GitHub 이슈 트래커를 모두 갖춘 프로젝트의 경우, 사용자들이 주로 Discourse 인스턴스에 집중하는 경향이 있습니다. 그런데 사용자의 주제가 실제로는 GitHub 이슈에 더 적합한 경우, 해당 주제를 처리할 책임 있는 사람들에게 전달되는 과정에서 마찰이 생길 수 있습니다.
이것을 다른 관점에서 보면, 마치 받은 편지함이나 바구니와 같습니다. 최종 사용자가 Discourse 인스턴스에서 더 활발하고 개발자가 GitHub 저장소에서 더 활발하다면, 기본적으로 개발자나 트리아지를 담당하는 사람이 사람들이 문제를 게시할 수 있는 여러 중복된 장소를 추적해야 하며, 필요할 때 이슈와 주제를 일관되게 이전하는 방법을 찾아야 합니다.
제가 상상하는 GitHub 이슈 동기화 기능은 Discourse WordPress 플러그인과 유사한 것으로, 이슈 트래커와 해당 Discourse 카테고리가 최종 사용자에게는 동일한 기본 대화 집합에 대한 서로 다른 뷰로 나타나는 것입니다.
다시 말씀드리지만, 저는 이 기능에 비용을 지출할 위치에 있지 않습니다. 저는 특정 프로젝트에서 어떤 종류의 피드백을 어디에 게시해야 하는지 불분명한 점과, 잘못 게시된 피드백이 손쉽게 무시되는 경향에 대한 제 경험과 좌절감 때문에 여기에 게시하고 있습니다.
이 문제를 바라보는 또 다른 관점은 이슈 트래커가 단순히 포럼(혹은 더 오래된 표현을 빌리면 “게시판 서비스”) 위에 애자일 프로젝트 관리라는 두꺼운 층이 덧씌워진 것이라 할 수 있다는 것입니다. 이상하게도, 이들은 메일링 리스트와도 유사합니다. 사용자가 이메일만으로 완전히 상호작용할 수 있기 때문이죠. Discourse는 겉보기에는 다르지만 많은 면에서 기능적으로 유사한 이러한 서비스들을 하나로 묶어 파편화를 줄이는 독특한 중심적인 위치에 있습니다.
이 모든 것을 설명해 주셔서 감사합니다. 솔직히 말씀드리면, Discourse를 사용하고 있는 기여 대상 프로젝트에 이 문제를 함께 해결해 달라고 요청하셔야 할 것 같습니다. 현재는 몇 개의 프로젝트가 Discourse Code Review를 활용하고 있는지, 그리고 그 결과가 어떤지 저에게조차 명확하지 않습니다. 구체적인 내용을 파악할 수 있도록 세부 사항을 DM으로 보내주시면 좋겠습니다.
그 플러그인은 다릅니다. 해당 플러그인에서는 토론이 Discourse에만 존재하며, WordPress 게시물 하단에 임베드되는 방식입니다. 동기화되지 않습니다.
안녕하세요! 저는 디스코러스 메타에 처음 온 사람입니다. 제가 특정 통합 기능이 필요한데, 제가 조사한 바로는 GitHub와 디스코러스 간 토론 동기화에 문제가 생겼기 때문에 해당 기능이 중단되었다고 합니다. 하지만 제가 필요한 것은 동기화가 아닙니다. 특정 게시글이나 답변을 GitHub의 이슈로 변환하는 기능입니다. 완전히 정적인 방식으로, 정보를 가져와서 이슈를 생성하고, 그 이슈는 GitHub에서 독립적으로 관리되며 디스코러스로 다시 동기화되지 않는 형태여야 합니다.
컨텍스트를 설명드리자면, 저는 몇몇 정부 솔루션의 비즈니스 팀에 속해 있습니다. 최근 책임 범위가 주(州)와 시(市) 단위로 확대되면서, 우리의 솔루션을 사용하는 공공기관이 매우 많아졌습니다. 따라서 커뮤니티 규모가 매우 크고, 이전에 GitHub로 관리해 보았지만 GitHub는 디스코러스만큼 사용자 친화적이지 않습니다. 디스코러스는 커뮤니티 관리에 정말 훌륭한 도구입니다. 제안, 오류 보고 등을 오가며 관리하는 것은 6명으로 구성된 팀의 몫인데, 커뮤니티 규모에 비해 인력이 부족합니다. 제가 필요한 것은 특정 게시글을 지정된 저장소(하나만 가능하거나 선택 가능해도 무방합니다)의 이슈로 변환할 수 있는 기능뿐입니다. 우리의 병목 현상은 GitHub로 이슈를 전달하는 과정이며, 이후로는 GitHub에서 관리하고 있습니다.
저는 기술 팀 소속이 아니므로,Ruby에 대한 지식이 전혀 없어 기술적으로 기여할 수 없습니다. 기술에 관심이 많고 호기심도 많지만, Ruby에 대해서는 아는 것이 전혀 없습니다. 누군가 도움을 주실 수 있다면 감사하겠습니다!
수정: 어디에 게시해야 할지 몰랐습니다. 이슈와 게시글 간의 관계에 대한 논의가 이미 존재하므로, 새로운 토픽을 열지 않았습니다.
Discourse와 GitLab 간의 정보 격리(siloing)가 문제가 되는 또 다른 사례를 발견했습니다:
요약하자면, F-Droid의 Discourse가 F-Droid GitLab과 분리되어 있어 Discourse 사용자들은 RFP나 MR에 편리하게 접근할 수 없습니다. 그 결과 사용자들은 GitLab MR에 대해 Discourse 토픽을 생성하는 경향이 있는데, 이는 스팸으로 인식됩니다.
Discourse와 GitLab 간의 양방향 동기화를 통해 F-Droid Discourse 사용자가 F-Droid GitLab에 스팸으로 인식되지 않으면서도 편리하게 접근할 수 있게 될 것입니다.
(지난 1~2시간 사이에 이 문제를 알게 되었고, 이전에 F-Droid Discourse를 사용한 적이 없어 GitHub 로그인 승인을 기다려야 합니다. 가능해지면 적절한 곳에 이 내용을 크로스포스팅하겠습니다.)