기진곰님 올리시는 글 항상 잘 읽고 도움 많이 받아갑니다. 좋은 하루 되세요.

문제의 core 원인이 뭔지 인식에 있어서 기진님 글에 절대 공감합니다. 그리고 이 문제를 해결하는 방법에 있어서 GG 님 의견에 공감이 갑니다.다만 빠듯하다는 XE 팀 환경에 전문 운영자를 따로 둘수 있는 환경을 네이버가 조성해줬으면 하네요. 비꼬는게 아니라 개발자가 개발을 하는데 시간을 소비해야 하는데.... 말이죠. 사이트 운영하랴, 오프라인으로 찾아오는 사람 응대해주랴... 등등등.... 

ps. 그나저나 공홈 운영자분들 네이버를 통해 월급 받고 일하는 네이버 직원들 맞죠? 

좋은글 잘 읽었습니다 :)

개인적인 관점이지만.. XE가 이전부터 문제 노출을 꺼려하고 있습니다. (외국에서는 반대지만..)

특히 타 솔루션이랑 비교하는 글 xe비판글은 거의 '맘대로' 처리합니다.

Xe관련 논쟁이나 문제점 취약점을 드러내지 않기 위해

게시판도 점점 축소하고 이제 커뮤니티 조짜 차단 예정이고요.

뭐 축소할때마다 사실 비판글이 많이 달려옵니다. (이전부터)

말이야 xe 위한 토론 공간이지만.. 일반인을 배제하고자 하는것도 은근 있지요.

(이럼 컴플레인이 훨씬 사라지겠죠)

뭐.. 개인 생각이고.. xe운영자 측 이해 못하는것도 아니고.. ㅎㅎ..

전적으로 기진곰님의 의견에 찬성합니다.
사이트에 커뮤니티 기능이 없어서 불만이 있는것이 아니라, 소통의 부재 이거든요.
개발팀의 구성원이 바뀌고 전체적으로 변화 하면서 소통 부분에 변화가 있을것처럼 보였습니다.
하지만 별로 변한건 없더라구요. 앞으로 별로 기대 안하려고 합니다.
예전부터 개발팀과 사용자간의 소통이 거의 이뤄지지 않았고, 이전 개발팀은 지금보다 더했었죠.
사람은 이렇게 익숙해져 가나 봅니다.
 

쌓여있는 이슈와 일주일이 지났는데도 분류 처리조차 되지 않고있는 PR을 보면서 느낀 느낌이 현재 XE의 소통에 대한 단편적인 모습같아 보이네요... XE3로 달려가고 있는것처럼 보이지만 가시적으로 보이는 것이 없으니 사용자들은 답답해할 것같고, XE3에 대한 기대감과 XE1.8 버전에 대한 불안감이 동시에 겹쳐있는 것 같으며, 현 상태를 그냥 방관하다가는 더 큰 사단이 날것으로 보입니다. 또한 XE라는 아이디 이름을 걸고 사용자에게 공격적인 언행을 쏟아놓는 모습에 참... 말리고 싶을 지경이었습니다. 뭔가 과도기적인 갈등으로 보이는 부분이 있는데 소통으로 차근차근 해결해나가길 기대합니다.

저는 정말 이해가 안되서 글 남긴 것이었거든요.

xe 포럼이라서 xe프로그램과 관계된 글이 아닌 사이트에 관한 내용은 이동되거나 삭제의 대상인 것으로 알고 있는데 이 글도 해당하는 것 아닌가요..? 아니면 관용차원에서 묵인되고 있는 것인지 정말 헷갈려요 진심으로.

공지글 적으신 것 보면 제가 자꾸 친목이 필요하다 이런 쪽으로 이해를 하고 계시는데, 그게 아니라 대체 포럼게시판에 이런 성격의 글은 올리면 안되는건지. 분명 그 xe변천사 글정도도 게시물 이동될 정도면 이 글도 남기면 안될것 같은데, 정말 고통스럽거든요.

필요이상 통제하는 것이 불만이었고 그래서 댓글 달았습니다. 그걸 또 자유게시판이랑은 친목허용 의도로 해석하는 분들은 정말 답답했고요. xe가 좋아서 xe의 옛날 이야기를 올린 사람의 글이 왜 아무도 안 볼 것 같은 공간으로 위배당해야 하나. 이런 가치는 xe가 추구하는 가치가 아닌 것으로 보였고 실망감이 컸습니다.

어떤 부분은 공감은 가지만, 어떤 부분은 이해할 수 없는 부분이 있습니다.

먼저 인터넷에서 클릭하게 하는 낚는 연예 기사처럼, 운영자가 얘기한 하나의 댓글만을 잘라서 확대 해석하는 것은 좋지 않은 것 같습니다.
이럴수록 더욱 더 얘기하는 것이 너무 조심스러워지고, 실수가 두려워 운영자는 아무런 답변이 없게되고 악순환이 됩니다.
운영자도 사람이고 실수도 하는데 이해해 주시기 바랍니다.

하지만 온라인과 오프라인 부분은 이해하기 어렵습니다. 온라인으로 하는 것은 투명하고 오프라인으로 하는 것은 비공개다. 라고 정의하는 것은 한편으로는 개인 성향으로 볼 수도 있습니다. XE3 관련해서 XECon에서 발표하겠다라고 한 것이 문제라고 보기에는 어렵습니다. 이때 항상 비교로 나오는 것은 해외개발자가 "참여하면?" 라고 문제를 제기 하지만, 이전에 구분해야할 것은 XE라는 오픈소스 CMS 프로덕트와 XE의 그 부수적인 부분입니다. 

XE라는 프로덕트는 다른 여타 오픈소스와 마찬가지로 오프라인 행사와 그 결과를 온라인에 공유하는 형태를 띠고 있습니다.
이 부분에 대한 온라인과 오프라인 지적이라면 이해하기 어렵고, 모든 창구를 통해 버그, 이슈, 개선 내역을 받고 토론하고 있습니다. 또한 릴리즈, 행사공지 등 이곳 공식사이트를 통해 신속하게 전하고 있습니다.
언급하신 node.js 의 소통은 개발적인 부분에 대한 소통입니다. 또 node.js에 얘기하는 커뮤니티와 지금 얘기하는 XE의 커뮤니티는 그 정의와 참여자 조차 다르다고 보여지며, XE 프로덕트에 대한 소통은 잘되고 있다고 보여집니다.

그러나 XE 또는 XE 오픈소스 프로젝트 이외 XE 공식사이트와 같은 부분은 다른 이슈입니다. 생각하신 것처럼 리소스가 부족하며, 별도 담당자가 있는 것은 아닙니다. 그렇다고 리소스를 요구하는건 조금 선을 넘어선 것이 아닌지 생각됩니다. 비유가 적절할지는 모르겠지만, 음식점에서 종업원이 부족하다고 손님이 매니져를 불러다 알바나 직원을 더 쓰세요. 라고 요구하는 선이라 생각됩니다. 오픈소스라고 대단한 위치에 있는 것도 아니며, 항상 공공성을 갖여야 하는 것은 아닙니다. 그리고 항상 오픈해야한다 라는 것도 아닙니다. 또 이부분은 오픈소스를 넘어선 다른 부분으로 보여집니다.

XE공모전의 경우, 문제가 되는 부분은 관련 대상자가 학생이라 되도록이면 피하려고 했습니다. 아무리 얘기를 하더라도 본문처럼 와전되어, 문제만 커지는 경향이 있습니다. 때문에 예전의 XE팀은 온라인이든 오프라인이든 커뮤니케이션 하지 않았었습니다. 다시 한번 말씀 드리면 오프라인에서 이야기 하는 것은 명확하게 전달함으로서 리소스를 줄이는 목적이지 다른 목적은 없음을 말씀드립니다.
하지만 이러한 불씨를 제공한 것은 잘못이라 생각됩니다.

그리고 이번 제이엔지님의 게시물 건은, 그 전에 안부의 글이 먼저 작성이 되었고, 요청하셔서 당사자가 직접 삭제할 수 있도록 댓글로 포럼에 맞지 않다고 하였으며, 이후 문제가 되는 작성된 글과 댓글에서는 XE가 아닌 공식사이트 자유게시판의 회상과 안부의 글이 대다수였습니다. 이 글이 XE에 대한 논의하는 글은 아니라고 판단됩니다. 삭제 또는 이동 등과 같은 처리시에 제이엔지님께 쪽지 또는 미리 말씀 드렸습니다.

제이엔지님께는 이렇게 자꾸 언급하게 되어 죄송하다고 말씀드리고 싶습니다,
더 많은 말을 하고 싶지만, 접겠습니다.

PR이 올라가면 그것이 개선인지 버그인지 그리고, 마일스톤은 무엇인지 따박따박 분류가 되어야 하는게 정상이죠. 몇주가 지나갔는데 분류조차 안되고 있으면 그게 제대로 돌아가는 프로젝트라고 할 수 있나요?

커미터 권한이 있는 사람이라곤 bnu님밖에 안보이니 업무가 한사람에게 치우쳐서 그런다고 쳐봅시다. 깃허브가 왜있고 분산 관리가 왜 만들어졌나요. 실수를 하더라도 그것이 최소화 되는 방향으로 만들어진것입니다. 깃허브를 잘 활용하려면 이 경우 커미터/관리자를 뽑아주면 됩니다. 적어도 이슈에 대해서 초반에 걸러지고 헛고생 하지 않도록 해줄것입니다.

커미터를 추천받고 추가할 용의가 있으시다면 현재 커미터가 아니면서 왕성한 활동을 하고 계시는 misol님과 기진곰님을 추천합니다.

XE 마크를 달고 글을 쓴다면 유저들이 
XE 개발자가 적은 글로 읽을지 XE 사이트 운영자가 적은 글로 읽을지 생각 해보셨으면 합니다. 

본인이 어떤 (네이버 정도 되는) 회사의 사장이고 산하 부서 중 한 커뮤니티의 운영자가 
이런식으로 유저들과 소통하고 있다면 어떻게 하셨을지도 한번 생각해보시길 추천 드립니다. 

프로젝트가 오픈소스의 힘에 의존 한다고 해도

공홈을 운영하시는 분들이 한 기업체의 녹을 먹고 사는 사람들이라면 감히 말씀 드리지만 이런 식의 소통은 정답이 아닌것 같습니다. 

무조건 자세를 낮추라는게 아니라 소위 말해 개발자가 아닌 운영자라면 오너 mind 도 한번 생각해보셨으면...

만약 제가 이 커뮤니티의 의사결정에 권한이 있는 오너라면 당장 오해에 대한 사과와 무엇이 되었든 운영자로서 정리된 입장/협조 요청 글을 올리게 지시할 겁니다. 

PS. 아무튼 어떻게서든 힘을 합치게 해서 XE를 키워나가셔야 Naver 안에서 입지가 커지는게 아닌가요? 돈이 넘쳐서 흐르는 상황이 아닌 이상에야 사실 인원 이나 비용 투자를 먼저 하는 조직은 잘 없잖아요. 아무쪼록 잘 정리 하셨으면 좋겠네요.

지금 논의되는 내용은 소통보다는 대화라는 용어가 걸 맞는것 같아서 그렇게 사용하겠습니다.

대화가 이루어지지 않는 것은, 쌍방 모두의 문제입니다. 모두의 책임이구요.

A라는 쪽과 B쪽의 대화가 이루어 지지 않는다면, A나 B나 서로에 대한 이해가 불충분 하다는 것입니다. 그외의 다른 것을 의미하지 않습니다.

대화는 쌍방의 노력이 있어야 합니다. 하지만, 이것은 쌍방이 동일한 노력을 해야 한다는 것도 아니고, 어떤 쪽이 다른 쪽에 비해서 더 노력해야만 하는 것도 아닙니다.

여튼 대화가 이루어지지 않는 것은, 양쪽다 문제를 가지고 있는 것입니다. 그리고 대화 문제에 있어서 어느 한측의 잘 잘못을 가리려는 시도는 무의미 합니다. 대화가 부족한 문제를 해결 하기 위해서는 서로의 잘잘못을 따지고, 시시비비를 가리는게 아니라 상대편의 입장을 더 이해하려는 정보의 교환 과정이 필요한것입니다.

- 지금 XE 공홈을 운영할 때, 고객에게 서비스 하는 곳이라는 마인드까지 요구하는 것은 무리라고 봅니다.
- 커밋에 답글을 남길 시, 스스로가 생각하기에 무의미한 내용인데도 답변을 남기는 것은 낭비입니다. 그리고 그건 소통도 아니고, 소통의 장애물이 될거구요.
- 지금 너무 많은 리퀘스트가 쌓여있고, 그것에 대한 압박감을 가지고 계신 것 같습니다. 그런데 이미 많은걸 뭐 어쩌겠어요. 압박감을 의식하지 않으려는 방법이 필요한 것 같습니다.

• 제안의 수행안. (이건, 밀린 일이 많을때 정리하는 방법들을 토대로하는 작성한 안입니다)
  • 방법1: 이전까지 리퀘스트를 무시합니다. 그리고 지금 들어오는 것 부터 천천히 실행합니다.
  • 방법2: 이전 리퀘스트를 무시하지 않습니다. 하지만 몇가지 조건에 따라서 시스템을 운영합니다.
    • (1) 리퀘스트 정책(예를 들면 지금 이렇게 제안 드리는 리퀘스트 정리 정책)이 시행되는 시기를 정합니다.
    • (2) (1)에서 정한 시기 이후에 보고되는 리퀘스트들의 우선순위를 설정하고, 처리해 나갑니다.
    • (3) (2)에서 처리되는 리퀘스트와 관련된 과거의 리퀘스트들이 있으면 반영합니다.
    • (4) (1) 에서 정한 시기를 바탕으로, 이전에 있던 리퀘스트 군을 R 군으로 둡니다., 그 시기 이후 들어올 신규 리퀘스트 군을  B군으로 둡니다.
    • (5) (4)에서 설정한 R 군과 B군의 리퀘스트 검토 비율을 설정합니다. R군에 대한 설정 비율은 최소한으로 잡아 놓습니니다.
      (즉, B 군의 리퀘스트를 보다 많이 처리하는 방향으로 설정합니다.)
      * 비율의 예를 들자면 R: B = 2:8 이런 식입니다.

그리고 XE코어 팀 내부의 커뮤니케이션 과정에 대해 한가지 더 제안을 해보자면...

- 현재 구조 그러니까, 어떤 특정 분야의 팀을 중심으로 많은 것이 꾸려지고 있는 상황이라면, 어느정도 집단간의 정보격차, 정보의 폐쇄적인 논의 과정은 피할 수 없는 이야기라고 생각합니다. 그것이 적합하면서 실용적인 방법이기도 합니다.
- 하지만, 결국에는 깃헙을 바탕으로 많은 대화가 이루어지는 환경이 조성되어야 합니다. 따라서, 깃헙 운영 방식이나, 커밋에 대한 운영 방식에 대한 프로세스가 정해질 필요가 있습니다.

• 대화 과정에 대한 방안
  • 1) XE코어 내부의 토론과 정리가 이루어 지면, 이때 논의된 내용들을 문서화 해서 내부에서 검토를 거치고 외부에 공유합니다.
  • 2) 그 외부 문서는 외부의 커미터들, 코어이외의 참여자들이 읽어볼 수 있도록 공유합니다.
  • 3) 외부 참여자들은 공개된 문서를 보고, 의견을 개진합니다.
  • 4) 다양한 이슈가 발생할 수 있습니다. 이때는, 온라인을 바탕으로 논의를 진행합니다.
  • 5) 4)에서 다양한 이슈가 발생하는 경우, 일단 이슈 목록을 작성합니다. 겹치는 부분이 없고, 이슈로 지적된 내용들 중 빠지는 부분이 없도록 작성합니다.
  • 6) 5)에서 이슈 목록이 작성된후에는 이슈에 대한 논의로 들어갑니다.
    • 논의의 과정에서 논리적인 흐름상 먼저 진행되어야 할 논의라고 판단이 된다면, 다른 논의 부터 순차적으로 진행합니다. 한번에 여러 논의를 진행 하지 않습니다.
    • 한 논의가 정리 되었다면 일단 닫아 놓습니다. 이것에 대한 추가 문제제기와 논의는 4주후 이루어집니다. 
      (4주라는 기한은 단지 예로써 적어 보았습니다. 이 기간을 설정하는 기준은, 다른 이슈들에 대한 논의가 이루어진 이후, 그리고 다른 여타 기반을 고려해서 여유가 발생하는 기간을 짐작하여 고정된 기한을 확정해야 합니다. 물론 추후 논의를 통해 이것을 변경할 수 있습니다.)

그리고 오프라인 발표를 위주로 하는 것은, 큰 문제는 없다고 생각합니다. 대화의 문제를 온오프로 나누어 생각할 수 있다고 생각하지는 않습니다. 무슨 앰바고가 걸린것도 아니고, 오프라인에서 나누어지는 정보를 통제하거나 그런 것도 아니구요. 오프에 참관한 분들이 나누어주셔도 되겠죠.
(그리고 여지껏 오프에서 밝히게 되는 내용들이면, 그 밝힌 이후 공지로 내용이 전달되었던 것으로 파악하고 있습니다.)

XE에 대한 운영을 주제로 이야기를 할 때에는, 네이버 이야기는 할 필요는 없을 것 같습니다. 네이버와 관련되어서 확실한 정보들을 그리 쉽게 접할 수 있는 것도 아닙니다. 그리고 네이버에게 추가로 지원을 요구하는 것도 불필요한 언급입니다. 물론 그런 바램을 내비치는 것도 피해야할 내용입니다.

XE운영에 대한 이슈가 발생한다면, XE만을 고려해서 논의를 진행해야 합니다. 관련된 내용들을 통해서 논의를 하고, 운영해야 XE라는 프로젝트가 힘을 받게 되고, 사용자들이 원하는 혹은 XE를 좋아하는 사람들 모두가 바라는, 더 많은 지원이 이루어질 것입니다.(물론 필요해야 이루어지겠지만요)

그리고 아마 대화에 많은 시간을 쏟게 되면, 커밋 속도는 약해질 거고 개발 진행도 느려질 것입니다. 하지만, 피할 수 없는 일인것 같습니다. 따라서, 이런 것을 선택하기로 했다면 코어 바깥의 분들도 이런것에 대한 인지를 하고, 수용을 해야 합니다. 재촉하고 싶어도 재촉하면 안됩니다.재촉한다고 일이 해결되지 않습니다.

그리고 어떤 제안을 드릴때, 그 행동 방안을 함께 제안해 주시는게 좋을것 같습니다. 또 XE팀에서는 여러 제약 조건도 있는 상황이니, 그 일에 직접적인 참여해주시는 것을 기다리고 있으신것 같습니다.

문제가 있다면
논리적으로 A 라서 B 라는 문제가 있다. 나는 C라는 근거를 가지고 D의 해결 방식을 제안한다. 그리고 이 일련의 과정에 대한  이 프로세스는 (필요하다면)~~와 같다라는 방식으로 제안할 수 있으면 더 좋을것 같습니다.