사용자가 직접 Issue를 생성할 수 없는 이유
(github.com/ghostty-org)- Ghostty 저장소는 사용자가 직접 Issue를 생성할 수 없고, 먼저 GitHub Discussions에서 논의를 시작해야 함
- 프로젝트는 버그나 기능 요청 논의에 Issue 트래커를 사용하지 않으며, 모든 논의는 Discussions에서 진행됨
- 논의가 충분히 구체화되어 실행 가능한 항목으로 정리되면, 관리자가 이를 Issue로 변환함
- 이러한 방식은 유지보수자와 기여자가 실제 작업 가능한 이슈를 빠르게 찾도록 돕는 구조임
- 대부분의 보고가 사용자 환경 문제나 오해, 미구현 기능 요청이기 때문에, 이 절차는 프로젝트 품질 관리에 중요함
Issue 생성 제한 정책
- Ghostty 저장소에서는 사용자가 직접 Issue를 생성할 수 없음
- 대신 먼저 GitHub Discussions에서 문제나 제안을 공유해야 함
- 관리자가 논의를 검토해 명확히 재현 가능한 문제로 확인되면 Issue로 변환함
- 이 방식은 Issue 트래커를 실제 작업 가능한 항목만 포함하도록 유지하기 위한 구조임
- 모든 Issue가 이미 구체화된 상태이므로, 기여자들이 바로 작업을 시작할 수 있음
Issue 트래커 운영 원칙
- Ghostty는 Issue 트래커를 토론이나 기능 요청용으로 사용하지 않음
- 기능 요청이나 일반 질문은 Discussions에서 처리함
- Issue는 명확히 정의된 버그나 실행 가능한 작업 항목만 포함함
- 이 접근법은 오픈소스 프로젝트 유지 경험을 바탕으로 형성된 운영 원칙임
- 과거 경험상, 사용자 보고의 80~90%가 실제 버그가 아닌 오해나 환경 문제였음
- 나머지 대부분은 미구현 기능 요청으로, 추가 명세가 필요한 경우가 많았음
유지보수 효율성 향상
- Discussions 단계를 거치면 유지보수자가 검증된 문제만 Issue로 관리할 수 있음
- 불필요한 중복 보고나 잘못된 버그 리포트를 줄임
- Issue 목록이 즉시 작업 가능한 항목 중심으로 정리됨
- 사용자는 유효한 문제를 찾아도 추가 작업을 할 필요 없음
- 관리자가 직접 Issue로 변환해 처리함
참고 문서
- 자세한 절차와 기여 지침은 CONTRIBUTING.md 파일에서 확인 가능
- 해당 문서에는 Discussions 참여 방식과 Issue 전환 기준이 명시되어 있음
Hacker News 의견들
-
100% 동의함. 다른 사람의 프로젝트라면 이슈 판단의 권한은 전적으로 그 사람에게 있음
큰 프로젝트일수록 메시지를 안 읽는 사람, 이상한 요구를 하는 사람, 심지어 AI로 CVE를 부풀리는 경우까지 생김- 에러 메시지를 안 읽는 사람들 정말 이해가 안 됨
사용자가 에러의 의미를 몰라도, 최소한 무슨 에러가 떴는지는 알려줘야 함
예전에 테스트할 때 “broken pipe error”를 명시했는데, 엔지니어가 “재현 불가”라며 닫고는 같은 에러를 이유로 재현이 안 된다고 했던 기억이 있음 - Github Issues는 버그 트래커로서 한계가 있음
대부분의 트래커는 “unconfirmed” 같은 상태로 분류가 가능한데, Github는 단순한 토론 시스템이라 관리가 어려움 - ChatGPT 출시 직후 CVE 리포트를 받은 적이 있었음
4시간 동안 코드와 근거를 제시하며 반박했는데, 돌아온 답변은 “shrugs AI”였음 - 많은 사용자가 도구의 정확한 사용법을 익힐 시간 없이 결과만 원함
“Facebookization”으로 클릭 몇 번이면 다 된다는 인식이 생겼고, 이제 “LLMization”으로 그게 더 심해질 것 같음
전문 소프트웨어에는 이런 접근이 맞지 않지만, 기대치는 이미 그렇게 형성되어 있음 - 좋은 이슈 트래커라면 이런 노이즈를 걸러주는 기능이 있어야 함
Ghostty가 토론을 통해 요청을 분류하는 건 독특하지만 유효한 접근임
- 에러 메시지를 안 읽는 사람들 정말 이해가 안 됨
-
메모리 누수 조사가 여러 플랫폼에 흩어져 있음
X 링크1, X 링크2, 토론1, 토론2
아직 공식 이슈로 승격되지 않음- 메모리 누수 때문에 Ghostty 사용을 포기했음
8GB 시스템에서도 터미널이 몇 번만 실행돼도 메모리 부족이 발생했음
Foot은 기능은 덜하지만 훨씬 안정적이었음 - 첫 번째 링크에 따르면 작성자는 이 문제가 두 번만 보고됐다고 함
두 번째 링크는 단순한 논쟁 시도로 보임 - 나도 이 문제를 토론에 보고했지만 반응이 없었음
Claude Code와 로그를 분석해 임시로 수정했는데, 지금은 10번 중 1번만 재현됨
누군가 추가로 조사할 때 도움이 되길 바람 - GPU 호환성도 까다로움
통합 GPU에서도 문제가 생기는데, 항상 GTK나 Nvidia 탓으로 돌림 - 기여자들이 아직 명확한 재현 조건이 부족하다고 판단해 이슈로 올리지 않은 듯함
- 메모리 누수 때문에 Ghostty 사용을 포기했음
-
“Issues”와 “Discussions”의 구분이 비효율적이라 생각함
중복 검색이 필요하고, 티켓 이동도 불가능함
이메일로 팔로업하면 알림이 끊겨버림
그래서 내 프로젝트에서는 Discussions를 꺼버렸음- Discussions는 단순한 질문이나 설치 문제를 올릴 수 있는 공간으로 유용함
진짜 버그라면 그때 이슈로 전환하면 됨 - 이런 프로세스는 라벨 시스템으로도 구현 가능함
“bug” 라벨을 관리자가 붙이면 충분함 - 중복 검사는 필요 없음
논의가 정리되면 그때 이슈를 생성하면 되니까 - 사실 이슈와 토론은 서로 변환 가능함
알림도 유지됨 - Ghostty의 구조처럼 Discussions는 누구나 열 수 있고, Issues는 관리자가 관리하는 방식이 합리적 분리라 생각함
- Discussions는 단순한 질문이나 설치 문제를 올릴 수 있는 공간으로 유용함
-
Python 커뮤니티의 일부 대형 프로젝트도 이런 방식을 씀
하지만 파워 유저 입장에서는 버그 리포트 과정이 번거로움
“우리 프로젝트는 완벽하다”는 듯한 태도가 오만하게 느껴짐- 이런 불만은 이해하기 어렵음
대부분의 드라이브바이 버그 리포트는 쓸모가 없고, 오히려 노이즈임
진짜 기여를 원한다면 이미 정의된 버그를 고치는 게 더 나음 - 오만하다고? 오히려 그들은 무료로 시간과 노력을 투자하는 사람들임
리포트 방식에 제한을 두는 건 당연함 - 그렇게 자주 버그를 찾는다면 프로젝트에 직접 참여해보는 것도 좋을 듯함
- 반대로, 자신이 “이건 명백한 버그”라고 확신하는 것도 일종의 오만일 수 있음
- 토론을 여는 게 이슈 여는 것보다 더 번거로운가? 잘 모르겠음
- 이런 불만은 이해하기 어렵음
-
“모든 이슈가 작업 준비 완료 상태여야 한다”는 주장에 대해,
“그럼 ‘ready-to-be-worked-on’ 태그 붙이면 되지 않나?”라는 질문이 나옴- 하지만 Github은 기본 뷰를 “triage”로 설정할 수 없고, 대규모 프로젝트에서는 이슈 관리가 비효율적임
이 시스템이 훨씬 성공적이었음 - 태그 방식은 여러 번의 피드백 라운드가 필요해 세부 정보가 댓글에 흩어짐
- 누구나 댓글을 달 수 있게 하면 불필요한 잡음이 생김
그래서 개발자 전용 공간과 사용자 공간을 분리한 것임 - 잘못된 이슈는 닫아도 다시 열리기 때문에 결국 이슈 목록이 감당 불가해짐
- 남의 워크플로우에 “왜 내 방식이 더 낫다”고 강요할 필요는 없음
- 하지만 Github은 기본 뷰를 “triage”로 설정할 수 없고, 대규모 프로젝트에서는 이슈 관리가 비효율적임
-
Issues는 규모가 커지면 관리 불가임
Discussions를 필터로 쓰는 게 효율적임- 하지만 결국 유지자는 모든 글을 읽고 분류해야 하므로 노동량은 비슷함
Github의 두 기능은 거의 동일한 UI임
다만 Discussions에는 업보트 기능이 있음 - “그냥 모든 이슈를 2주 후 자동으로 닫으면 더 효율적이지 않나?”라는 냉소적 반응도 있었음
- Curl 같은 대형 프로젝트도 오픈 이슈가 5개뿐임
curl/curl/issues
- 하지만 결국 유지자는 모든 글을 읽고 분류해야 하므로 노동량은 비슷함
-
이 방식이 기본 설정이 되어야 한다는 의견도 있음
커뮤니티는 토론을, 기여자는 이슈를 담당하는 구조가 이상적임- 하지만 이건 단순히 프로세스 재배치일 뿐, 본질은 같음
GitHub의 라벨 시스템으로도 충분히 처리 가능함
GitHub 라벨 관리 문서 - “기본값”을 정하기보다 각 프로젝트가 자연스럽게 실험하며 맞는 방식을 찾는 게 좋음
Natural experiment처럼 말임
- 하지만 이건 단순히 프로세스 재배치일 뿐, 본질은 같음
-
사용자 제출 정책에는 동의함
닫힌 토론을 보면 닫힌 이슈와 비슷하지만, 적어도 이슈 탭의 노이즈는 줄어듦
Ghostty 닫힌 토론 목록- 모든 사용자 제보는 토론에서 시작하고, 실제 버그로 확인되면 이슈로 이동함
많은 토론이 그 단계까지 가지 않지만, 사용자 문제는 해결됨
이 분리 구조는 꽤 똑똑한 설계라 생각함
- 모든 사용자 제보는 토론에서 시작하고, 실제 버그로 확인되면 이슈로 이동함
-
사실 “이슈를 열 수 없다”는 건 GitHub 기능이 아니라,
“새 이슈를 열지 말고 Discussions를 사용하라”는 템플릿 안내문일 뿐임 -
다른 프로젝트에서도 이런 방식을 봤는데,
토론을 출발점으로 삼는 구조가 꽤 합리적으로 보임
다만 많은 프로젝트가 아직 GitHub Discussions를 활성화하지 않았음
그 디스커션이 이슈와 다른 점이 무엇일까요? 이슈는 “버그“가 아닙니다. 버그든, 기능 제안이든, PR이든… 논의할 꺼리가 있다면 이슈죠.
논의할 가치가 없다면 닫으면 됩니다.