현재 zbXE의 경우 커미터분들도 늘어나고 사용자분들의 참여와 요청도 많아지고 있습니다.

다만 아직 미흡한 시스템과 매니저의 불량(흑;;)스러운 모습으로 인하여 프로젝트의 발전이 더딥니다.


이제 정식으로 zbXE의 개발 방향을 공유하고 목표를 잡기 위한 의견을 나누고 싶어서 개발 포럼에 글을 올립니다.

대략 다음과 같은 부분들이 있을 것 같고 각 부분들에 대한 의견 개진 및 추가 목표등에 대한 이야기를 하였으면 합니다.


커미터외에 어떤분이든 의견 나눔 가능합니다.


버그/ 아디이어 제안의 이슈화 및 티케팅

현재 zbXE의 사용자가 많아지고 다양한 자원들이 공개/공유되고 있어서 아이디어 및 버그 신고가 계속 쌓이고 있습니다.

실제 개발을 할 수 있는 커미터 대비 사용자의 수에서 큰 차이가 있기에 본업이 따로 있는 커미터가 해당 문제와 이슈들을 감당하기가 버거운 것이 사실입니다.

zbXE 프로젝트 관리 및 개발이 본업인 저 역시 최근 조직 이동등의 여러가지 이슈로 인하여 보다 발빠른 처리를 하지 못하고 있었구요.

초기 zbXE 프로젝트를 구상할때 리포터 - 커미터의 연결고리를 강화하고 리포터 - 커미터 그룹으로 각종 이슈들을 논의 - 진행할 수 있기를 바랬는데 현재 인원이 부족하고 또 활동하지 않는 혹은 못하는 분들로 인하여 각 그룹들의 이슈 관리 기능이 약해져 있습니다.

그리고 실제 리포터 지원을 하여 그룹에 속하였음에도 전혀 활동이 없는 이른바 관리 부실 현상도 있구요.

오픈 소스 프로젝트이다보니 강제성이 없고 또 저 역시 강제성은 절대 있을 수 없다고 생각하고 있기에 대안이 필요한 상태인 것 같습니다.

쉽게 해결할 수 있는 방안은 전문적인 지식보다 zbXE에 대한 관심과 애정으로 충분히 활동할 수 있는 리포터 그룹의 멤버 충원인거 같은데 이게 과연 차후 긍정적인 결과를 낼 수 있을지가 의문입니다.

이와 관련해서 의견 주시면 감사하겠습니다.


차후 마일스톤의 확립

zbXE 오픈 소스 프로젝트는 TRAC 시스템의 로드맵 - 티켓 기능으로 운영/ 유지되고 있습니다.

시스템 자체에 대한 문제는 없다고 판단되는데 역시 소프트웨어적인 목표 설정이 어려운 상태입니다.

현재 로드맵에는 제가 임의로 설정한 마일스톤들이 있고 이에 대한 개선과 목표의 재확립을 위한 논의가 필요합니다.

외국의 대형 프로젝트들은 여러 branch로 프로젝트를 운영하고 있습니다.

사소한 버그나 개선사항을 발전시키는 작은 버전 업그레이드가 있고 설계 변경등 구조적으로 큰 이슈가 있는 큰 업그레이드를 듀얼 혹은 여러개의 브랜치로 운영하고 있습니다.

zbXE 역시 초기의 설계를 변경하기 위한 개발 이슈들이 생겨나고 있고 또 불합리/ 불편한 배포판등의 이슈를 관리하기 위해서 크고 작은 마일스톤을 정립해야 할 상황입니다.

예를 들어 HNO3님이 제안하신 event/filtering을 위한 trigger의 구조 변경이라든지 PC브라우저외의 기기 지원등 초기 설계를 변경해야 하는 이슈들이 있습니다.

앞으로도 이런 이슈들은 늘 생길것이고 이에 대한 개발-사용자간의 이해를 높이기 위해서 마일스톤 생성시 필요한 규칙이 있어야 할 것 같습니다.

현재 zbXE의 버전체계는 a.b.c 3 단계이고 c class의 경우 사소한 버그나 기능 개선시 버전을 올리도록 되어 있습니다.

b class는 당연히 좀 더 중요한 이슈등에 대해서 관련이 되는 것이고 a class는 큰 변화가 있을시 버전 올림을 하는 구조입니다.

이 이슈는 위의 버그/아이디어 제안의 이슈화와 관련되어 있는데 제가 생각하는 마일스톤 생성은 다음과 규칙으로 하면 어떨까 싶습니다.

  1. c class의 버전 올림
    15일 혹은 1달 단위로 c class의 버전 올림 마일스톤을 자동으로 생성. 작은 이슈의 티켓을 등록
    단 홀수/짝수로 나누어서 홀수의 경우 새로운 이슈, 짝수의 경우 이전 홀수 버전의 이슈로 인해 발생한 문제를 안정화 시킴

  2. b class의 버전 올림
    2달 혹은 3달 단위로 b class의 버전 올림 마일스톤으로 자동으로 생성.
    다만 생성시 이미 등록된 큰 이슈들에 대한 정리를 통해 마일스톤의 코드명등을 지정하여 운영

  3. c class의 버전 올림
    아직 고민 없습니다.

현재도 위와 같이 운영을 하려고 하는 중인데 저 혼자만의 고민은 한계가 있어서 차후 마일스톤을 정립하는 것도 같이 의논하여 진행하였으면 합니다.

그리고 b class의 버전 올림의 경우 현재 sandbox로만 이루어지는 개발코드를 코드명등으로 branch를 나누고 dual로 개발하고 차후 merge하는 것이 맞을 것 같은데 merge 비용이 결코 적지 않을 것이라 고민이 되네요.

이에 대해 좋은 의견이나 지적할 부분이 있으면 글 주시면 감사하겠습니다.


이 외의 이슈

리포팅과 개발이라는 대명제 말고도 다른 의견등이 있으시면 편하게 의견 주시면 좋겠습니다.

제가 오픈소스 프로젝트를 시작하기는 하였지만 제 경험과 능력이 부족한 관계로 보다 많은 분들의 의견과 가르침이 필요합니다.

좋은 의견을 내주시고 능력이 좋으신분의 경우 프로젝트 매니저로서도 같이 해나갔으면 하는게 제 바램입니다.

많은 의견 부탁드립니다.
이 게시물을..