추가 인력 채용에 대해 열린 입장이신가요? 바로 떠오르는 몇몇의 활발한 기여자들이 있습니다. 그들은 CDCK에서 훌륭한 직원이 될 수 있을 것입니다.
네, 채용 중입니다 – 하지만 이 메타 사이트의 모더레이터 직원은 아닙니다. 풀타임 CM(커뮤니티 매니저) 한 명이면 충분합니다. 그가 직무를 시작한 지 겨우 일주일밖에 되지 않았다는 점을 기억해 주세요. 모든 업무를 파악하는 데 시간이 좀 걸릴 것입니다.
우아한 제스처 몇 가지, 그 이상은 없습니다:
- 버그 신고나 기능 요청이 올라올 때마다 팀의 누군가가 반응합니다
- 적정한 시간, 예를 들어 최대 2주 정도가 지나면 팀의 누군가가 무슨 일이 일어나고 있는지 간단히 알리거나, 아무 일도 일어나지 않는 이유를 설명합니다
그게 전부입니다. 모든 요청을 충족시키려 할 필요는 없으며, 어떤 요청은 사실상 시간 낭비이거나 너무 어렵습니다. 하지만 일을 방치해 둘 수는 없습니다. 단순한 반응만으로도 팀이 경청하고 있고, 커뮤니티 쪽에서 무슨 일이 일어나는지에 관심을 두고 있다는 인상을 줄 수 있습니다.
그렇게 잘하고 계신다고 인정합니다. 하지만 여전히 해결되지 않은 건이 너무 많습니다. 일부는 작성자가 추가 세부 정보를 제공하지 않았거나 단순히 사라진 경우이지만, 일부는 팀이 아무 통보 없이 방치한 것입니다.
이것은 여러분의 정책과 연결되어야 합니다. 여러분이 어떻게 일하는지는 모르지만, 누군가에게 할당이 되면 그 사람이 몇 마디 말을 남깁니다. 제 뜻이 뭔지 아시죠? ![]()
그렇지 않으면… 아무도 모든 사람을 만족시킬 수는 없습니다. 하지만 여러분은 우리 일반 사용자보다 더 많은 주목을 받고 있습니다. 예를 들어, 제 쪽에서의 수동적 공격적 태도와 여러분 쪽에서의 태도는 다른 것입니다. 여러분은 저를 침묵시킬 수 있지만, 저는 메타(Meta)를 떠나는 것 외에는 여러분을 침묵시킬 수 없으니까요.
팀이 나쁜 말을 한다고 말하려는 것은 아닙니다
그것은 여러분이 신중해야 한다는 점을 보여주기 위한 예시에 불과합니다.
글쎄요, 이 주제에 대해 저는 여기서 마무리하겠습니다. 팀에게는 몇 가지의 마음과 몇 마디의 말로 해결할 수 있는(그리고 더 사용자 친화적인 작성기
진심으로 — Discourse는 더 미니멀한 작성기가 필요하지만, 그것은 완전히 다른 문제입니다, 죄송합니다…) 더 큰 문제는 없습니다.
—
우리 사용자들도 대상으로 삼아야 합니까? 솔직히 말하면, 여기의 사용자들은 팀보다 훨씬 더 문제가 많은 경우가 많습니다.
이 목록을 정리하는 데 시간을 조금은 쓰고 있습니다:
https://meta.discourse.org/c/feature/2/none?order=op_likes&status=open
여기서 숨겨진 문제가 무엇인지 궁금합니다. meta의 Contribute > Feature 카테고리에서 투표 플러그인을 실험해 보는 것이 어떨까 싶습니다. 이 카테고리에서는 내용이 묻히기 쉽기 때문에, 인기 있는 아이디어에 더 높은 가시성을 부여하면 도움이 될 수 있습니다. 그러면 커뮤니티가 더 좋은 아이디어를 끌어올리는 데(원래 게시물을 개선하거나, 더 많은 표를 주거나 하는 등) 도움을 줄 수 있고, "투표가 N개를 초과하는 주제에는 Discourse가 항상 공식적으로 응답한다"는 같은 규칙을 적용할 수 있습니다.
거대한 우물의 규모를 고려해 보면, 10표 이상인 모든 주제에 대해 어떤 식의 응답을 주는 것이 꽤 현실적이라고 생각합니다. 10표 이상인 주제 대부분에는 이미 스태프의 응답이 있는 것 같습니다. 그러면 10표 이상을 관리할 수 있게 되면 5표 이상으로, 그 아래로 순차적으로 내려갈 수 있을 것입니다.
또한 #contribute:ux는 #contribute:feature와 Contribute > Bug 사이에 어딘가에 위치해 있어 특히 까다롭다고 느낍니다. 이 카테고리가 도움이 되는지, 오히려 방해가 되는지 궁금합니다.
다만 #support는 매우 잘 돌아가고 있고, 제 생각에는 #contribute:bug도 잘 운영되고 있습니다.
이라는 태그가 있습니다.
죄송합니다, 유혹을 참지 못했습니다. 하지만 #contribute:ux는 고(高) 볼륨 카테고리는 아니라고 생각합니다(제 시각에서 보면 UX/UI는 좋은 기본 코드의 다음으로 가장 중요한 부분이므로 약간 이상하게 느껴지지만, 큰 문제는 아닙니다).
하지만 이것은 메타를 더 즐겁게 만드는 것보다는 구조나 조직의 문제입니다 — 쉽게 찾는 것은 아마도 어떤 면에서 즐거운 일이겠죠. 하지만 물론 일상적인 업무에 방해가 되는 경우가 아니라면, 여러분의 업무를 더 쉽게 만들어 줄 수 있고, 그렇게 될 것입니다…
정말 좋은 아이디어입니다.
다만, 지난 몇 주간 #install-support와 #update-support를 해당 카테고리의 하위 카테고리로 추가하는 것을 제안해 볼까 생각했습니다. 이 두 가지 주제가 카테고리를 조금 혼란스럽게 만들고 있어서, ‘기능적 지원’ 관련 주제들이 마땅히 누려야 할 만큼 눈에 잘 띄지 않게 되기 때문입니다.
Contribute > Bug 채널은 전혀 잘 작동하지 않습니다.
지금 우리는 @team 소속 아무도 #contribute:bug에서 게시물을
하지 못하는 터무니없는 상황에 처해 있습니다. 그 이유는 이 동작이 bug_reporter_badge SQL을 트리거하기 때문입니다.
해결책은 정말 간단합니다 -
- 배지를 부여하기 위해 @team의 작은 부분 집합 그룹을 명시적으로 생성합니다.
또는 … - 자체 그룹 내에서 'user’를 위장(impersonate)할 수 있는 특수 배지를 생성하면, 팀의 누구든 #contribute:bug에서 자유롭게
할 수 있습니다.
배지 SQL을 업데이트하여 쿼리에서team을 제거합니다.
저는 이 스레드에 현재 제 삶의 현실적인 상황을 설명하는 글을 작성하는 것을 고려하고 있습니다.
절망적인 시기에 Discourse Enthusiast’s Training에 참여하는 것이 최선의 선택이었다고 결정한 방식, 그리고 #contribute:bug에 몇 개의 게시물이 무시되는 것과 같이 바보 같은 일이 실제 삶에서 얼마나 큰 타격이 되는지, 그 이야기를 하려 합니다.
죄송하지만 이 의견에는 전혀 동의하지 않습니다. 버그가 들어오는 것은 반갑고, 배지는 그로 인한 바람직한 부수적 효과일 뿐입니다.
배지는 제가 버그에 좋아요를 누르는 것을 결코 막지 않습니다.
지난 30일간의 목록을 자유롭게 확인해 보세요: Bug - Discourse Meta
팀이 첫 번째 게시글에 좋아요를 누른 경우 10개와, 팀이 첫 번째 게시글에 좋아요를 누르지 않았지만 정말로 누렸어야 했었던 경우 10개를 찾아보세요.
다행히도 저는 여기서 '사용자’로 활동한 지 충분히 오래되어, 공동 소유자가 그렇게 열정적으로 주장할 때 그 시간을 낭비하지 않습니다.
대신 개를 산책시키러 나갑니다.
좋은 하루 보내세요.
이제 생산성이 없는 영역으로 진입하고 있으니, 이 주제를 30일간 보류하겠습니다.
모두가 기여해 주셔서 감사하지만, 불행히도 제 취향에는 너무 격해지고 초점이 흐려지고 있습니다.
이 주제는 26일 후 자동으로 열렸습니다.
정말 흥미로운 주제네요. ![]()
제 생각은, 메타(Meta)에 기여하는 것이 즐거우시지 않다면 그건 그냥 당신에게 맞지 않는다는 것입니다. 개인적으로 저는 메타에서 다른 분들이 해결책을 찾으시는 것을 돕는 것이 매우 보람 있는 일이라고 생각합니다. 이타적인 문제 해결이 제 DNA에 새겨져 있거든요. 저는 디스코르스(Discourse) 팀이 얼마나 바쁘게 일하고 있는지, 그리고 지원과 서비스를 제공하기 위해 얼마나 열심히 노력하고 있는지 firsthand로 잘 알고 있습니다. 이 사이트에 어느 정도 기간 동안 참여해 보셨다면, 그건 분명히 깨달으셨을 것입니다. ![]()
저는 모든 주제를 읽으려고 노력하고, 아직 읽지 않은 주제에는 이미 누군가가 반응하지 않았다면 좋아요나 댓글로라도 최소한 인지했음을 표시합니다. 하지만 저는 이 사이트에서 그렇게 오래 활동하지는 않았고, 사실 올해 초부터 본격적으로 시작했습니다. 솔직히 모든 주제를 읽는 것을 좋아하는데, 그건 학습의 경험이기 때문입니다. 사용자가 도움을 찾다가 부정적인 경험을 하는 것은 유감스러운 일이며, 저는 항상 그걸 개인적으로 받아들이고, 어떤 점이 개선되었어야 했거나 피할 수 있었을까를 생각해보려고 합니다. 하지만, 어떤 주제에서 수동적 공격적인 문구로 팀을 공격하는 것은, 어떤 공동 프로젝트나 팀의 지원에 참여하는 데 필요한 존중, 인내, 긍정적인 태도와는 정반대라고 생각합니다.
여기서 사용자들이 자신의 주제에 다시 게시물을 올려 도움을 받는 것을 본 적이 있는데, 그건 전혀 문제없습니다. 자신의 주제를 다시 올리는 것(bump)이나 다시 도움을 요청하는 것도 괜찮습니다. 제 포럼에서는 항상 사용자에게 즉시 도움을 드릴 수 있는 것은 아니며, 만약 제가 어떤 이유로든 사용자의 문제를 인지하지 못한다면 그들이 저를 재촉하거나 다시 물어봐도 전혀 문제없습니다. 제 게시물을 플래그(신고)해서 제 주의를 끌었던 사용자들도 있었는데, 그것도 괜찮습니다. lol
또한 @JammyDodger와 @Canapin은 제가 메타에 있는 동안 커뮤니티 모더레이터로서 뛰어난 역할을 해왔으며, 저의 학습과 즐거움에 있어 무가치했습니다. 감사합니다. ![]()
기록으로 남겨두자면, 이 주제는 제가 만들었습니다.
그래서 어떤 비판이나 피드백이든 제 초대로 이루어진 것입니다. ![]()
제가 직장에 온 지 사흘째 되는 날이었기 때문에 몇몇 사람들에게는 예상치 못한 일이었을 것 같습니다.
하지만 저는 그 대화가 실제로 매우 유용했다고 느꼈습니다. 좋았던 점도, 나빴던 점도요.
1년 후 되돌아보면 매우 흥미롭습니다. 특히, 이전에 팀 배지가 없었던 몇몇의 원초기 기여자들이 이제는 팀 배지
를 달고 있습니다.
(@Canapin @keegan @mcwumbly). 새로운 분들이 이 글을 읽을 때 이 부분이 인식을 왜곡시킬지는 모르겠지만, 혹시라도 그럴 수 있으니 이 점을 짚어두는 것이 좋을 것 같습니다.
하지만 본론으로 돌아가면, 지난 1년간 Meta를 기여하고 도움이 필요할 때 지원을 받을 수 있는 즐거운 곳으로 유지하기 위해 최선을 다해 노력했습니다.
할 일이 많고 따라가야 할 것도 많습니다(때로는 머리가 녹아내릴 정도로 쏟아지는 정보의 홍수
), 그리고 제가 완벽하지 않다는 것을 잘 알고 있습니다. 하지만 모든 것을 합산했을 때, 긍정적인 점수를 얻기를 바랍니다. ![]()
어쨌든, 저는这无疑을 승리로 기록해 두겠습니다.
![]()
어떻게 그걸 놓칠 수가 있었지
![]()
주제를 처음부터 끝까지 다시 읽지는 않았지만, 여기서 "기여(contributing)"는 원래 의도했던 것보다 더 넓은 의미로 해석될 수 있다고 생각합니다. 도움을 요청하는 것도 유효한 형태의 기여입니다. 따라서 원래의 질문은 여러 가지 변형으로 나눌 수 있습니다.
-
도움을 요청하는 것을 더 즐겁게 만드는 방법은?
-
다른 사람을 도우는 것을 더 즐겁게 만드는 방법은?
-
피드백을 주는 것을 더 즐겁게 만드는 방법은?
-
Discourse 관련 개발을 더 즐겁게 만드는 방법은?
그리고 그 외의 것들…
각 질문에 대한 답은 다를 수 있습니다 ![]()
정말 훌륭한 지적이네요. 이곳에 있는 동기와 이유, 그리고 상대적인 관점 역시 분명히 이곳에서의 경험에 영향을 미치는 요인이죠. 당연히 서버가 다운되고 사용자가 소리를 지르는 위기 상황에 있는 사람은 즉각적인 지원 필요, 기대치, 그리고 정신적 상태가, 예를 들어 사이드바 커스터마이징을 위한 코드 스니펫을 좀처럼 파악하지 못하는 사람(안녕, 나야)과는 훨씬 다를 수밖에 없으니까요.
긍정적인 변화를 추구해야 한다는 목표에는 동의합니다.
하지만…
저에게 두드러지게 다가오는 두 가지 부정적인 요소, 그리고 저는 이것이 OP(게시글 작성자)의 경험과도 일치한다고 생각하는 요소는 한쪽이 침묵이고 다른 한쪽이 적대감입니다. 항상 그런 것은 아니지만, 이런 것들을 목격하게 되면 동기 부여가 떨어지고 환영받지 못하는 기분이 듭니다.
유감스럽게도, 저는 적대감을 가장 자주 매우 시니어(고참) 계층의 사람들로부터 목격하는 것 같습니다. 이는 추가적인 부정적인 요인이 됩니다. 여기서 말하는 '적대감’에는 저에게 무시당하거나 위선적으로 느껴지는 행동들도 포함됩니다.
반드시 성격의 결함은 아닐 수 있는 몇 가지 가능한 원인을 떠올릴 수 있습니다:
- 화가 나 있거나 시간 압박을 받으면서 댓글을 남기는 경우
- 이미 여러 번 본 적 있는 것을 다시 보는 경우
- 해당 프로젝트를 자신의 영역으로 느끼고 그에 따라 반응하는 경우
- 간결하게 말을 하면서 그것이 무뚝뚝하거나 무례하게 읽힐 수 있다는 점을 인지하지 못하는 경우
한편으로는 침묵
게시글을 보고 작성할 때 신경 쓰이는 것 두 가지(조금만!)가 있습니다.
- Support 게시판에 글을 올렸는데 며칠 또는 몇 주 동안 답이 없는 것.
그것이 의도하신 뜻인가요?
이제 저는 답이 달리지 않은 게시글들을 검토하여 이 문제를 완화하려고 노력하고 있습니다.
제 경험을 살려 답변을 하거나, 제가 답을 알지 못하지만 의미 있는 방식으로 주제를 부드럽게 다시 띄우거나, 팀 중 누군가가 아이디어를 가지고 있는지 물어보는 방식으로요.
그러나 저는 더 자주 그렇게 해야 합니다.
네, 긴급 지원 관련 게시글에 답변이 없는 경우도 있었어요. 저도 한 번 겪어 봤거든요. 하지만 포럼을 둘러보면 답변이 없는 게시글이 꽤 많은 것 같아요. 여러분이 합류해서 그런 게시글들을 챙기겠다고 하시는 건 좋은 일이죠.