# 사용자가 직접 Issue를 생성할 수 없는 이유

> Clean Markdown view of GeekNews topic #25523. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25523](https://news.hada.io/topic?id=25523)
- GeekNews Markdown: [https://news.hada.io/topic/25523.md](https://news.hada.io/topic/25523.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-03T09:41:13+09:00
- Updated: 2026-01-03T09:41:13+09:00
- Original source: [github.com/ghostty-org](https://github.com/ghostty-org/ghostty/issues/3558)
- Points: 12
- Comments: 3

## Summary

Ghostty 프로젝트는 **Issue 트래커를 실제 작업 가능한 항목만 담는 공간**으로 운영합니다. 사용자는 직접 Issue를 만들 수 없으며, 모든 제안과 버그 보고는 먼저 **GitHub Discussions**에서 논의됩니다. 관리자가 충분히 구체화된 내용을 확인한 뒤에만 Issue로 전환하기 때문에, 유지보수자는 불필요한 보고를 거르며 바로 처리 가능한 작업에 집중할 수 있습니다.

## Topic Body

- 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 전환 기준**이 명시되어 있음

## Comments



### Comment 48601

- Author: neo
- Created: 2026-01-03T09:41:13+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46460319) 
- 100% 동의함. 다른 사람의 프로젝트라면 **이슈 판단의 권한**은 전적으로 그 사람에게 있음  
  큰 프로젝트일수록 메시지를 안 읽는 사람, 이상한 요구를 하는 사람, 심지어 **AI로 CVE를 부풀리는** 경우까지 생김  
  - 에러 메시지를 안 읽는 사람들 정말 이해가 안 됨  
    사용자가 에러의 의미를 몰라도, 최소한 **무슨 에러가 떴는지**는 알려줘야 함  
    예전에 테스트할 때 “broken pipe error”를 명시했는데, 엔지니어가 “재현 불가”라며 닫고는 같은 에러를 이유로 재현이 안 된다고 했던 기억이 있음  
  - Github Issues는 **버그 트래커로서 한계**가 있음  
    대부분의 트래커는 “unconfirmed” 같은 상태로 분류가 가능한데, Github는 단순한 토론 시스템이라 관리가 어려움  
  - ChatGPT 출시 직후 CVE 리포트를 받은 적이 있었음  
    4시간 동안 코드와 근거를 제시하며 반박했는데, 돌아온 답변은 “shrugs AI”였음  
  - 많은 사용자가 도구의 **정확한 사용법을 익힐 시간 없이** 결과만 원함  
    “Facebookization”으로 클릭 몇 번이면 다 된다는 인식이 생겼고, 이제 “LLMization”으로 그게 더 심해질 것 같음  
    전문 소프트웨어에는 이런 접근이 맞지 않지만, 기대치는 이미 그렇게 형성되어 있음  
  - 좋은 이슈 트래커라면 이런 노이즈를 걸러주는 기능이 있어야 함  
    Ghostty가 토론을 통해 요청을 분류하는 건 독특하지만 유효한 접근임  

- 메모리 누수 조사가 여러 플랫폼에 흩어져 있음  
  [X 링크1](https://x.com/mitchellh/status/2004938171038277708), [X 링크2](https://x.com/alxfazio/status/2004841392645050601), [토론1](https://github.com/ghostty-org/ghostty/discussions/10114), [토론2](https://github.com/ghostty-org/ghostty/discussions/9962)  
  아직 공식 이슈로 승격되지 않음  
  - 메모리 누수 때문에 Ghostty 사용을 포기했음  
    8GB 시스템에서도 터미널이 몇 번만 실행돼도 메모리 부족이 발생했음  
    Foot은 기능은 덜하지만 훨씬 안정적이었음  
  - 첫 번째 링크에 따르면 작성자는 이 문제가 두 번만 보고됐다고 함  
    두 번째 링크는 단순한 논쟁 시도로 보임  
  - 나도 이 문제를 [토론](https://github.com/ghostty-org/ghostty/discussions/9786)에 보고했지만 반응이 없었음  
    Claude Code와 로그를 분석해 임시로 수정했는데, 지금은 10번 중 1번만 재현됨  
    누군가 추가로 조사할 때 도움이 되길 바람  
  - GPU 호환성도 까다로움  
    통합 GPU에서도 문제가 생기는데, 항상 GTK나 Nvidia 탓으로 돌림  
  - 기여자들이 아직 **명확한 재현 조건**이 부족하다고 판단해 이슈로 올리지 않은 듯함  

- “Issues”와 “Discussions”의 구분이 **비효율적**이라 생각함  
  중복 검색이 필요하고, 티켓 이동도 불가능함  
  이메일로 팔로업하면 알림이 끊겨버림  
  그래서 내 프로젝트에서는 Discussions를 꺼버렸음  
  - Discussions는 단순한 질문이나 설치 문제를 올릴 수 있는 공간으로 유용함  
    진짜 버그라면 그때 이슈로 전환하면 됨  
  - 이런 프로세스는 **라벨 시스템**으로도 구현 가능함  
    “bug” 라벨을 관리자가 붙이면 충분함  
  - 중복 검사는 필요 없음  
    논의가 정리되면 그때 이슈를 생성하면 되니까  
  - 사실 이슈와 토론은 서로 변환 가능함  
    알림도 유지됨  
  - Ghostty의 구조처럼 Discussions는 누구나 열 수 있고, Issues는 관리자가 관리하는 방식이 **합리적 분리**라 생각함  

- Python 커뮤니티의 일부 대형 프로젝트도 이런 방식을 씀  
  하지만 파워 유저 입장에서는 **버그 리포트 과정이 번거로움**  
  “우리 프로젝트는 완벽하다”는 듯한 태도가 오만하게 느껴짐  
  - 이런 불만은 이해하기 어렵음  
    대부분의 **드라이브바이 버그 리포트**는 쓸모가 없고, 오히려 노이즈임  
    진짜 기여를 원한다면 이미 정의된 버그를 고치는 게 더 나음  
  - 오만하다고? 오히려 그들은 **무료로 시간과 노력을 투자**하는 사람들임  
    리포트 방식에 제한을 두는 건 당연함  
  - 그렇게 자주 버그를 찾는다면 프로젝트에 직접 참여해보는 것도 좋을 듯함  
  - 반대로, 자신이 “이건 명백한 버그”라고 확신하는 것도 일종의 오만일 수 있음  
  - 토론을 여는 게 이슈 여는 것보다 더 번거로운가? 잘 모르겠음  

- “모든 이슈가 작업 준비 완료 상태여야 한다”는 주장에 대해,  
  “그럼 ‘ready-to-be-worked-on’ 태그 붙이면 되지 않나?”라는 질문이 나옴  
  - 하지만 Github은 기본 뷰를 “triage”로 설정할 수 없고, 대규모 프로젝트에서는 **이슈 관리가 비효율적**임  
    이 시스템이 훨씬 성공적이었음  
  - 태그 방식은 여러 번의 피드백 라운드가 필요해 세부 정보가 댓글에 흩어짐  
  - 누구나 댓글을 달 수 있게 하면 **불필요한 잡음**이 생김  
    그래서 개발자 전용 공간과 사용자 공간을 분리한 것임  
  - 잘못된 이슈는 닫아도 다시 열리기 때문에 결국 **이슈 목록이 감당 불가**해짐  
  - 남의 워크플로우에 “왜 내 방식이 더 낫다”고 강요할 필요는 없음  

- Issues는 **규모가 커지면 관리 불가**임  
  Discussions를 필터로 쓰는 게 효율적임  
  - 하지만 결국 유지자는 모든 글을 읽고 분류해야 하므로 **노동량은 비슷**함  
    Github의 두 기능은 거의 동일한 UI임  
    다만 Discussions에는 **업보트 기능**이 있음  
  - “그냥 모든 이슈를 2주 후 자동으로 닫으면 더 효율적이지 않나?”라는 냉소적 반응도 있었음  
  - Curl 같은 대형 프로젝트도 오픈 이슈가 5개뿐임  
    [curl/curl/issues](https://github.com/curl/curl/issues)  

- 이 방식이 기본 설정이 되어야 한다는 의견도 있음  
  커뮤니티는 토론을, 기여자는 이슈를 담당하는 구조가 이상적임  
  - 하지만 이건 단순히 **프로세스 재배치**일 뿐, 본질은 같음  
    GitHub의 라벨 시스템으로도 충분히 처리 가능함  
    [GitHub 라벨 관리 문서](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels)  
  - “기본값”을 정하기보다 각 프로젝트가 **자연스럽게 실험**하며 맞는 방식을 찾는 게 좋음  
    [Natural experiment](https://en.wikipedia.org/wiki/Natural_experiment)처럼 말임  

- 사용자 제출 정책에는 동의함  
  닫힌 토론을 보면 닫힌 이슈와 비슷하지만, 적어도 **이슈 탭의 노이즈는 줄어듦**  
  [Ghostty 닫힌 토론 목록](https://github.com/ghostty-org/ghostty/discussions?discussions_q=is:closed+)  
  - 모든 사용자 제보는 토론에서 시작하고, **실제 버그로 확인되면 이슈로 이동**함  
    많은 토론이 그 단계까지 가지 않지만, 사용자 문제는 해결됨  
    이 분리 구조는 꽤 **똑똑한 설계**라 생각함  

- 사실 “이슈를 열 수 없다”는 건 GitHub 기능이 아니라,  
  “새 이슈를 열지 말고 Discussions를 사용하라”는 **템플릿 안내문**일 뿐임  

- 다른 프로젝트에서도 이런 방식을 봤는데,  
  **토론을 출발점으로 삼는 구조**가 꽤 합리적으로 보임  
  다만 많은 프로젝트가 아직 GitHub Discussions를 활성화하지 않았음

### Comment 48615

- Author: iolothebard
- Created: 2026-01-03T15:29:40+09:00
- Points: 1
- Parent comment: 48601
- Depth: 1

그 디스커션이 이슈와 다른 점이 무엇일까요? 이슈는 “버그“가 아닙니다. 버그든, 기능 제안이든, PR이든… 논의할 꺼리가 있다면 이슈죠.  
논의할 가치가 없다면 닫으면 됩니다.

### Comment 48948

- Author: nemorize
- Created: 2026-01-09T15:28:41+09:00
- Points: 1
- Parent comment: 48615
- Depth: 2

디스커션과 이슈가 다른 점이 있어서가 아니라, 그냥 별도의 탭으로 나눠져 있는게 취향에 맞았던거겠죠.  
  
이슈 탭에 일종의 투두리스트와 디스커션 모두를 게시하고, 이를 태그로 관리하느냐  
vs  
이슈 탭은 투두리스트로만, 디스커션은 디스커션으로만 사용하느냐