지난 3주 동안 사소한 버그 3건을 보고/확인했는데, 팀원이 게시물을 읽었다는 확인조차 전혀 없습니다…
그런데 내 장난기 어린 GIF는 아주 빨리 수정해 주더군요…
https://meta.discourse.org/t/discourse-support-training-program/194057/1 … 이 과정을 따르는 것을 생각하고 있었습니다. 샌드박스를 설정하고, 로컬에 설치도 시도해 보며, 질문을 하고, 도움을 주려고 노력했는데… 이 모든 것이 제 열정을 완전히 갉아먹었습니다.
이 내용을 별도의 Contribute > Site feedback 주제로 옮기겠습니다. 이렇게 하면 주제에서 벗어나는 걱정 없이 자유롭게 이야기할 수 있습니다. 
괜찮으시죠? 
아직 공식적으로 '팀’의 일원으로 포함되지는 않으셨을 수도 있지만, 저는 그 게시물을 읽었습니다. 
다만, 제가 읽었다는 것을 보여주는 좋아요나 확인 메시지를 남기는 데는 더 잘할 수 있었을 것 같습니다. 다른 팀 구성원들도 읽었을 것이라고 확신하지만, 그들이 읽었다는 작은 표시라도 남기지 않으면 아무도 듣고 있지 않는 것처럼 보일 수 있다는 점은 충분히 이해합니다.
이 글을 읽으니 정말 슬펐습니다. 저는 Discourse Experts 프로그램을 정말 좋아합니다. 이 프로그램이 제가 이 직장을 얻을 수 있었던 주요 이유 중 하나라고 생각하기 때문이죠. 관심이 있으시다면 강력히 추천하며, 궁금한 점이 있거나 질문이 있으시면 언제든 연락 주셔서 온보딩 버디 역할을 기꺼이 맡겠습니다. 
다른 분들도 도움을 주는데 매우 관대합니다 (제가 아는 것보다 훨씬 더 많이 알고 계시니 저로서는 운이 좋죠 )
저는 최근 메타 커뮤니티의 새로운 커뮤니티 모더레이터로 시작했기 때문에, 더 많은 사람들이 참여하고 기여하는 것이(Expert 프로그램에 속해 있든 아니든) 재미있고 보람 있는 경험으로 느껴지도록 하는 방법에 대해 정말 관심이 많습니다. 다른 사람들의 문제를 해결하고, 버그를 재현하는 데는 상당한 시간과 노력이 필요하며, 사람들이 자신의 기여가 가치 있다고 느끼는 것이 중요하다고 생각합니다.
이 점을 고려할 때, 더 즐거운 경험으로 만들기 위해 제가 다르게 할 수 있기를 바라는 것이 있으신가요?
팀에 합류한 것을 축하합니다.
이건 아마 당신이 시작하기 전의 일이었을 거예요.
'온보딩 버디’가 되어주겠다는 정말 넉넉한 제안에도 감사드립니다.
7년 후에도 지금처럼 친근하게 유지하세요 … 누군가 버그를 보고하거나 재현하거나 어떤 형태의 피드백을 남긴다면 … 최소한 
을 클릭하세요. 왜냐하면 …
거의 맞습니다 .. 실제로 아무도 듣지 않는 것처럼 보입니다.
저도 반드시 지금처럼 친근한 태도를 유지하겠습니다. 그리고 우리가 경청하고 있다는 것을 보여주기 위해 최소한의 '무언가’는 꼭 남기겠습니다. 다른 쪽에서 겪어본 경험으로, 공을 들여 무언가를 기여했는데 그것이 마치 허공으로 사라진 것 같은 느낌을 받는 것은 결코 좋은 일이 아니라는 점을 잘 이해합니다. 다만 팀은 모든 내용을 읽고 있다는 점을 약속드립니다(과장된 것처럼 들릴 수 있지만, 정말 과장이 아닙니다).
아닙니다. 그 제안을 받아주셨으면 좋겠습니다.
명확히 하자면, GIF 편집은 원격 사이트가 사라졌을 때 이미지를 잃지 않도록 원격 이미지를 로컬 저장소로 다운로드하는 자동화된 작업이며, 스태프가 수동으로 수행하는 작업이 아닙니다.
팔코님, 안녕하세요.
아니요, 그게 제 의도가 아닙니다. 그리고 그건 저도 알고 있거든요.
코딩호러 - 19시간 전 현재
제 게시물에서 GIF를 삭제/편집했습니다.
제발 'Loser’라고 생각하지 마세요 
완전히 수동으로 작업했습니다.
그 점만 분명히 하고 싶었습니다.
저는 디스코urses를 매우 좋아합니다. 이전 세 번의 마이그레이션을 수행했고, 메타를 둘러보며 #marketplace에서 여러 번 성공적인 작업을 해왔습니다.
게시물을 작성하고 둘러볼 때 조금(그저 조금일 뿐이지만!) 신경 쓰이는 두 가지가 있습니다.
#support에 게시물을 올렸는데 며칠 또는 몇 주 동안 답변이 없는 경우. 하지만 그것은 당연한 일입니다. 때로는 사람들이 해결책을 알지 못하거나, 시간이나 무료 도움을 줄 의지가 없을 수 있습니다. 본질적으로 다소 좌절스러운 부분이며, 디스코urses에 국한된 문제는 아닙니다. 
Contribute > UX 또는 #contribute:feature에 제안을 올리는데, 답글과/또는 좋아요로 어느 정도의 관심을 받는 주제임에도 불구하고 어떤 형태의 후속 조치도 없는 경우입니다. 특히 영향력 있는 멤버나 공식 디스코urses 개발자가 좋은 아이디어임을 인정하는 경우에도요. 그러면 이러한 아이디어/제안들이 어디로 가는 것인지 궁금해집니다.
개발 팀에는 “관심 있는” 아이디어를 기록하거나 북마크하여 미래에 더 깊이 생각해 보기 위해 aside해 두는 semacam 작업 문서가 있나요? 일부 아이디어는 저자에게 알리지 않고 단순히 쓰레기통에 버려지는 건가요? 아니면 일부는 낮은 우선순위로 유지되어 미래에 매우 잘 추가될 수 있지만, 현재 단계에서는 우리에게 단순히 알려주지 않는 건가요?
이러한 주제에 후속 조치가 없는 이유에 대해 많은 이유를 이해합니다. 하지만 그럼에도 불구하고 다소 좌절스럽습니다. 사람들이 제안을 게시하는 것은 (자주) 디스코urses에 관심을 가지고 가치를 더할 수 있다고 생각하기 때문입니다. 
조금이나마 위로가 되길 바랍니다. 저는 Discourse에서 일하고 있는데, 제가 스스로에게 할당해 두고 1년 이상 방치하고 있는 작업들이 있습니다. 현재 수천 명의 고객을 보유하고 있으며, 비즈니스를 계속 운영해 나가기 위해 고객의 버그/기능/요청을 우선순위별로 관리해야 합니다.
또한 10년 전에 처음 보고된 크롬과 사파리의 오픈 버그 리포트들도 아직 해결을 기다리고 있습니다… 그리고 이들은 우리보다 1,000배나 큰 회사들입니다. 영원한 백로그(backlog)가 존재하는 것이 소프트웨어 개발의 본질적인 특성이라고 할 수 있습니다.
Meta는 우리가 무료로 제공하는 제품에 대한 무료 지원이라는 점을 기억해 주세요. 만약 특정 사항이 당신에게 매우 중요하다면, 우리의 관심을 끌기 위한 최선의 방법은 유료 고객이 되거나, 해당 기능을 직접 구현하는 PR을 제출하는 것(또는 계약자를 고용하여 이를 수행하게 하는 것)입니다. 이해할 수 있는 이유로 그렇게 할 수 없는 경우도 있지만, 그런 경우에는 가장 가치 있는 것은 인내심입니다.
대부분의 경우 우리는 알지 못합니다. 한 달 안에 처리할 수도 있고, 어쩌면 1년이 걸릴 수도 있습니다! 우리는 몇 가지 큰 우선순위를 계획하고, 더 작은 기능/작업은 처리 가능한 시점에 선택하여 진행합니다. 어쩌면 아무도 흥미를 느끼지 못하여 역사 속으로 사라지는 것일 수도 있습니다.
우리는 Meta에서 더 많은 게시글에 응답하기를 원하며, @JammyDodger가 언급했듯이 그 이유 때문에 그를 이곳의 모더레이터로 고용했습니다… 특정 직원으로 Meta를 전담하게 한 것은 처음 있는 일입니다!
할 일은 그냥 을 클릭하는 것뿐입니다. 시간, 노력, 그리고 존재 자체를 인정하는 것이 제가 말하는 바로 그 것입니다.
하지만 저는 정말로 이 문제에 더 깊이 휘말리고 싶지 않습니다… 여기에서 부정적인 경험을 여러 번 겪었고, 이번 일로 인해 그 부정적인 경험이 더 쌓이는 것 같습니다.
그래도 팀의 방어력은 훌륭했습니다.
메타에 기여하는 것이 더 즐겁게 느껴지는 이유 중 하나는 우리가 배운 것을 되돌려주기 때문이라고 덧붙이고 싶습니다.
대부분의 사람은 처음에 질문이나 제안으로 이곳에 왔을 겁니다. 그리고 도움과 답변을 받았죠. 우리는 디스코스, 온라인 커뮤니티, 프로그래밍 등에 대해 배웠습니다.
자주 말하지만, 저는 코딩 마법사가 전혀 아닙니다. 하지만 그동안 많은 분들이 저를 도와주셨고, 저는 그 보답으로 Support 채널에서 제 능력껏 다른 사람들을 돕고 있습니다. 제 능력은 그다지 높지 않지만, 때로는 낮은 수준도 누군가를 도우기에 충분합니다.
UX 개선 제안, 새로운 기능 요청, 버그 보고 등도 커뮤니티가 우리에게 제공해 준 것을 되돌려주는 방법 중 하나입니다.
저는 정확히 그렇게 하고 있었지만… 일방적이었죠
저는 Discourse 팀의 일원은 아니지만, Discourse용 테마 컴포넌트/플러그인을 개발하고 있습니다.
버그 리포트와 이를 작성하는 데 시간을 내어주시는 분들을 진심으로 감사하게 생각합니다. 이러한 리포트는 매우 유용하기 때문입니다. 때로는 다른 업무에 압도되어 바로 답변을 드리지 못할 때가 있는데, 그럴 때는 보통 리마인더를 달아두었다가 시간이 될 때 다시 살펴보기 위해 해당 게시글을 북마크해 두는 습관이 있습니다.
사실, 제 복사하기( copy post ) 컴포넌트에 대한 여러분의 리포트 중 하나에 대해 북마크를 해두었네요
아마 북마크와 리마인더를 활용하는 기법을 더 많은 분들이 사용해도 좋을 것 같습니다.
다만, 리포트에 (하트)를 눌러주는 습관은 들여야겠습니다. 피드백 주셔서 감사합니다!
대부분의 사용자가 Discourse가 제공하는 모든 기능을 사용하지 않는다고 확신합니다. 이는 오히려 경험을 더 즐겁게 만들 수 있습니다.
북마크 기능은 알고 있습니다(아, 저는 Discobot 튜토리얼을 했거든요… 
). 정말 멋진 기능이지만, 솔직히 저는 그것을 사용할 생각을 한 번도 해본 적이 없습니다.
하지만 제가 약간 주제에서 벗어나고 있는 것 같은 느낌이 듭니다. 나쁜 습관인데, 죄송합니다…
제가 잘 이해했다면 @geoff777 님의 주제는 다른 사용자들 및/또는 스태프로부터의 인정/인식(acknowledgment/recognition)에 중점을 두고 있는 건가요? 해당 토픽이 분리(split)되었기 때문에, 정확히 어떤 내용인지 결정하지 못하셨을 수도 있습니다.
하지만 저는 님의 기분을 잘 이해하는 것 같습니다.
왜냐하면 제가 오래전에 (그리고 오랫동안) 일을 시작했을 때, 저는 프로젝트 관리자를 위해 일하는 계약자(컨트랙터)에 불과했거든요. 그 사람은 거의 유일하게 고객과 대화하는 사람이었고, 저는 기본적으로 가이드라인을 따르며 코드를 작성하는 역할만 했습니다.
피드백을 받는 경우는 작업이 기대만큼 좋지 않았거나 문제가 있을 때뿐이었습니다.
작업이 충분히 좋고 고객이 만족했다면, 저는 피드백을 전혀 받지 못했습니다.
며칠이 지나자, 제 좋은 작업이 인정받지 못한다는 사실이 슬펐고, 제가 잘 알고 지내던 고용주에게 조금 더 배려해 주었으면 좋겠다고, 그리고 제 작업이 제대로 이루어졌을 때 나쁜 피드백뿐만 아니라 좋은 피드백도 받고 싶다고 말씀드렸습니다. 그러면 제가 더 동기부여를 받을 수 있을 것 같았기 때문입니다.
그는 한동안 그렇게 하려 했지만, 결국 상황은 이전과 똑같이 남았습니다. 저는 침묵, 즉 피드백이 없다는 것은 제 작업이 좋았다는 뜻임을 받아들이는 법을 배웠습니다.
하지만 님의 문제는 여기서 다릅니다. 왜냐하면 저는 오늘날 ‘좋아요’ 버튼을 한 번 클릭하는 것이 확실히 긍정적인 피드백, 인정, 인식, 신뢰의 공유 등이라고 동의하기 때문입니다.
따라서, 여기서 근본적인 질문은 아마도 이것일 것입니다: 왜 님의 게시글이 님이 기대하는 대로 인정받지 못하고 있는 걸까요?
개인적으로, 개인적인 문제를 논의하는 것보다는 제목이 말하는 대로 "메타(커뮤니티)에 기여하는 것을 더 즐겁게 만드는 방법?"에 대해 일반적인 관점에서 논의하는 쪽에 더 관심이 있을 것 같습니다.
그리고 제가 이전에 올린 작은 사항들을 제외하고는, 저는 메타에 대해 실제 문제가 없으므로 더 많은 말을 하기는 어렵습니다.
사람들이 기능이나 UX에 대해 제안을 할 때, 그들은 자신의 아이디어가 최소한 매우 편리하고, 최대로는 초일급(super awesome)이라고 생각하는 경우가 많습니다. 마치 "도대체 그 전에 아무도 왜 그걸 생각하지 못했지?"라고 생각하듯이요. 우리는 편견이 있으며, 우리 모두는 자신이 지혜롭고, 다른 사람들의 필요를 더 잘 알며, 우리가 생각하는 것들이 구현하기가 그렇게 어렵지 않으며, 결국 모두가 박수를 칠 것이라고 생각하기를 원합니다… 그리고 저는 그점에 대해 매우 죄책감을 느끼고 있습니다(그리고 잘 알고 있습니다!).
처음에는 몇 개의 좋아요와 Osioke님의 매우 긍정적인 답변(예를 들어 여기)를 보는 것이 즐거웠습니다. 하지만 저는 결국 주목을 받지 못했다는 점에서 실망했습니다(제목이 "역사 속으로 사라졌다"고 표현했듯이, 토픽이 그렇게 된 것 같습니다). 과거에 이미지 검색 문제를 너무 많이 겪었기 때문에, 제 아이디어가 포럼이라는 맥락에서 최상급이고 독창적이라고 확신했기 때문입니다.
하지만 현실에서는 반드시 그렇게 작동하지는 않습니다. 포럼에서 특정 이미지를 찾는 것이 검색의 너무 니치한 용도일 수도 있습니다. 구현하기가 믿을 수 없을 정도로 어려울 수도 있습니다. Discourse에서 해야 할 더 중요한 일들이 산더미처럼 있을 수도 있습니다. 아마도 [트랙션이 부족한 이유 열 가지].
저는 또한 Discourse의 직접적인 경쟁 제품들(Flarum, nodeBB)을 확인해 보았지만, 유사한 기능이 있는지 확인해 보았을 때(그들은 없었습니다), 그리고 Discourse의 저장소를 살펴보고 결과 요약(excerpts)이 어떻게 이루어지는지 파악하려고 시도해 보았습니다(물론 거의 아무것도 이해하지 못했지만… 
).
이 관점에서 보면, 저는 제가 훌륭하다고 생각했던 기여에 대한 피드백 부재를 즐거워하지 않았습니다.
하지만 이 특정 토픽에 대해서는, 그것은 제 개인의 문제였지 일반적인 문제가 아니었습니다.
Canapin님, 안녕하세요.
경험을 공유해 주셔서 감사합니다.
말씀하신 고객 - 계약자 - 코더 간의 상황은 전형적인 경우로 보입니다.
계약자의 인력 관리가 부실했던 것이죠. 오랜 기간 동안 부정적인 피드백만 반복되면 관계에 해가 됩니다.
저는 여기의 사용자나 개인 누구에게도 문제가 없습니다.
오히려 반대입니다. 이곳에는 기여로 인해 존경하는 분들이 많습니다.
앞으로 제가 자주 방문하는 웹사이트 전반에 걸쳐 를 더 자주 누르도록 하겠습니다.
여기에는 사람들이 많은 시간을 들여 조사하고, 링크를 제공하고, 코드 스니펫을 공유하며, 심지어 사용자가 복사할 수 있는 사용자 맞춤형 코드를 생성하는 입력 필드가 포함된 게시글까지 올리는 훌륭한 기여들이 있습니다. 그들에게 를 보여주세요. 그들은 그만한 대우를 받을 자격이 있습니다.
팀 내에서 반응은 엇갈렸습니다.
일부는 지지해 주었지만,
다른 일부는 무시하는 것이 업계 표준이라고 했습니다… 때로는 수년간… 무료니까… 조용히 해라… 이미 최선을 다하고 있다… 유료 고객이 수천 명이나 된다… 그리고 DM으로… 여기엔 볼 것 없다… 모든 것이 완벽하다… 앞으로 기여하고 싶다면… 제자리로 돌아가서 얌전히 굴어라.
'좋아요’가 어디에 집중되었는지는 흥미로웠습니다.
JammyDodger가 한 달만 일찍 고용되었다면, 제 기여가 인정받았을지도 모릅니다.
아마도 문제가 해결되었을 것입니다.
정말 손가락을 꼬고 기도하고 있습니다.
@osioke님이 지원 엔thusiast 훈련을 위해 제공해 주신 링크들이 우선순위 목록에 어떤 요소들이 영향을 미치는지 파악하는 데 꽤 유용했습니다. 특히 'Rule of Three(3의 법칙)'는 그 존재를 알기 시작하면 꽤 자주 등장합니다.
디스커스 팀이 때로 좀 방어적으로 보일 수 있다는 데 동의합니다. 그리고 그런 태도는 대부분 불필요하다고도 생각합니다. 하지만 여기서 다른 피드백을 좀 덧붙이자면, 저는 메타가 전담 커뮤니티 매니저만 아니라서 운영되는 커뮤니티라는 점이 실제로 매우 마음에 듭니다. 개발과 의사결정에 참여하는 사람들이 거의 모두 실제 커뮤니티 활동가인 커뮤니티는 흔치 않은 것 같습니다. 이로 인해 모든 질문에 즉각 응답할 시간이 부족할 수 있다는 점은 자연스러운 일일 것입니다. 적어도 저의 경우, 가장 흔한 대안인 커뮤니티 매니저가 기여를 인정하고 지나치게 친절하게 대해주면서도 할 수 있는 말이 "담당 팀에 전달했다"는 것뿐인 상황보다는, 이런 상황을 감수하는 쪽이 훨씬 더 좋습니다.
물론 중간 지점이 있을 거라고 생각하고, 이곳 팀이 그 지점을 찾길 바랍니다. 팀 구성원이 누구인지, 그리고 그들이 커뮤니티에 어떻게 참여하는지 좀 더 명확하게 전달하면 어떨까요? 특히 Contribute > Bug 카테고리의 경우, 버그 리포터 배지 작동 방식을 변경하는 것도 방법일 수 있습니다. 그 카테고리에서 초기 좋아요를 아끼는 것은 팀으로서 책임 있는 태도라고 생각합니다
저는 기여를 전혀 하지 않으므로, 이 주제는 저와는 무관한 것 같습니다. 하지만 일반적으로, 여기 있는 대부분의 사용자는 이미 이 모든 것을 잘 알고 있습니다.
여기에는 강하게 계층화된 커뮤니티 문화가 존재하며, 이는 당연한 일입니다. 영국 사회와 비슷하다고 할까요. 어떤 이들은 개발자로서 강한 주체성을 가지고 있고, 어떤 이들은 더 많은 최종 사용자에 가깝지만, 이들은 토론의 장을 마련하기 위해 노력하고 있습니다.
이 두 집단은 토론 방식, 기능 구현, 그리고 일반적인 이해 방식에서 꽤 다른 모습을 보입니다.
메타(Meta)가 글로벌 커뮤니티로 운영되는 것이 더 쉽다는 것도 아닙니다. 저는 좀 특이한 성격에다 핀란드인이라서 미국식 화법이나 과장된 표현에는 관심이 없습니다. 저는 단순히 그 주제 자체에만 관심이 있을 뿐입니다. 다른 누군가는 직설적인 글쓰기를 모욕으로 받아들일 수도 있습니다.
그렇게 되면 본질적인 문제는 기본적으로 소실되고, 아무것도 앞으로 나아가지 못합니다. 양측이 해당 문제나 이슈에 대해 동의하더라도 말입니다.
언어 장벽 또한 강력한 장애물, 혹은 최소한 위험 요인이 됩니다. 저는 핀란드식 표현을 섞은 pidgin 영어로 글을 쓰며, 전치사의 기본조차 완벽히 다루지 못합니다. 다만 영어 독해는 유창하게 합니다. 오해가 생기기 쉽고, 동시에 다른 이들을 돕거나 토론에 참여하는 것 자체가 더 높은 장벽을 요구합니다. 이에 대한 해결책은 없지만, 이것이 모든 사람이 참여할 수 없는 이유를 설명해 줍니다.
모든 개발자 포럼을 괴롭히는 근본적인 문제가 하나 있습니다. 개발자들은 자신들을 위해 개발하기 때문에, 일반 사용자의 필요, 반응, 그리고 욕구를 이해하는 데 어려움을 겪습니다.
메타가 최악의 사례는 아니지만, 여기에서도 비슷한 분위기가 느껴집니다. 그렇다면 이에 대해 무엇을 할 수 있을까요? 아무것도 할 수 없다고 생각합니다. 이는 완전히 다른 세계에서 비롯된 것이기 때문입니다.
버그 리포트 등은 반드시 응답을 받아야 합니다. 대부분의 경우 사람들은 반응합니다. 하지만 어떤 요청이나 오류가 빠르게, 혹은 가까운 미래에 수정될 수 있는지, 아니면 비현실적인지 나중에 알려주는某种 후속 처리 시스템이 필요합니다. 기능 요청에 대해서도 마찬가지입니다.
사람들이 글을 읽는 방식이 다르듯, 글쓰기 스타일도 다릅니다. 메탄(Methane, 아마도 특정 사용자나 그룹을 지칭하는 것으로 보임)과 관련된 글 중에는 놀라울 정도로 밝은 글도 있습니다. 어떤 글은 짧고, 핀란드인 입장에서 때로는 지루하게 느껴지기도 합니다. 하지만 일반 사용자가 개발자의 의지에 복종하기를 거부할 때, 불필요하게 자주 명확한 수동적 공격성(passive-aggressiveness)을 목격합니다.
물론 사용자들에게도 문제가 있습니다. 그리고 기술적 문제에 대한 역량 차이도 상황을 더 쉽게 만들어 주지 않습니다. 게다가, 지원 요청 중 상당수가 명백한 FAQ 자료에 해당하며, 기본적인 설명조차 읽지 않았음이 evident합니다.
스태프가 대부분의 경우 도움을 줄 수 있도록 응답하는 점은 칭찬할 만합니다. 저는 스스로가 그렇게 인내심이 강하지 않을 수도 있습니다.
하지만 제가 하나 요청하는 것이 있습니다. 디스코스가 무료이기 때문에 어떤 일이 일어나지 않는다고 절대 말하지 마세요. 그것은 사실이 아니며, 커뮤니티에 대한 강한 비하를 의미합니다. 커뮤니티가 없다면 기업 고객에게 플랫폼을 신뢰할 수 있게 판매할 수도 없습니다. 무료 포럼을 유지하는 사람들은 지속적인 테스트를 통해 사용료를 지불하고 있습니다. 동시에, 충분한 기술적 역량과 필요한 언어 역량을 갖춘 일부 사용자는 회사에 속해야 할 많은 지원 활동을 수행하고 있습니다.
같은 맥락에서, 유료 고객은 우선적으로 그리고 그들의 요구에 따라 서비스를 받는다는 점을 상기시켜 줍니다. 물론, A급과 B급 사용자 간의 명확한 구분을 지적하고 싶다면, 그것은 실행 가능한 정책일 수 있습니다.
우리 각자는 경제적 현실이 무엇인지 잘 알고 있습니다. 하지만 그것을 마치 젖은 수건처럼 얼굴에 휘두르듯 행동해서는 안 됩니다. 다른 표현을 찾아보십시오. 자원의 부족, 바쁨 등이면 충분합니다.
죄송합니다. 제목에 대해 건설적으로 응답할 수 없습니다. 우리가 모두 서로의 필요를 이해하려는 시도를 하고, 어떤 중도적 지점을 찾으며, 디스코스의 비즈니스, 커뮤니티 활동, 그리고 메타의 콘텐츠를 결합하는 합의를 도출해 낸다면 도움이 될 수도 있을 것입니다.
불편한 말씀이지만, 이 주제에 대해 매우 강한 반감을 가지고 있습니다. 저는 편견 없이 글을 읽으며, 요청된 내용을 이해하려고 노력해 왔습니다. 무엇보다, 메타(Meta)에 며칠 이상 머무는 사람들은 기본적으로 이 공간의 분위기를 사랑하고, 즉 디스코스(Discourse)라는 제품 주변의 커뮤니티의 일원이 되고 싶어 하는 사람들입니다. 메타는 참여를 달콤하게 포장하기 위한 소셜 네트워크나 지원 그룹이 아닙니다.
때로는 제가 틀렸을 때, 같은 디스코스 사용자나 스태프에게 잘못된 가정이나 접근 방식에 대해 지적받기도 했습니다. 그런 피드백이 거칠게 들릴 수도 있지만, 모든 사람은 자신의 방식으로 대화를 나누며, 환영하는 느낌을 주기보다는 자신의 주장을 펼치려 한다는 점을 이해합니다. 그러나 저는 디스코스를 사용하는 것을 즐기고, 자발적으로 디스코스 커뮤니티를 돕고자 하므로, 그러한 태도가 메타에 참여하는 것을 저지시킨 적은 한 번도 없습니다.
사실, 메타가 아무리 부드럽게 운영된다 해도, 좋아요와 답글은 항상 메시지의 관련성을 나타내는 강력한 지표로 작용합니다. 때로는 지원 토픽의 최초 작성자(OP)가 제공된 도움말을 완전히 무시하고, 자신의 의견을 게시한 뒤(예: 위에서 언급했듯이 이렇게 하고 저렇게 하니 문제가 해결되었습니다) 자신의 답글을 해결책으로 표시합니다. 이 행동 자체만으로도 누군가 복잡한 감정을 느낄 수 있으며, 특히 사용자를 돕기 위해 답글을 쓴 사람은 더욱 그렇습니다. 사용자의 문제를 해결하기 위한 제안과 완전히 다른 방법을 실제로 시도한 경우도 있을 수 있다는 점은 충분히 이해합니다. 하지만 대부분의 경우, 사용자는 다른 사람의 조언을 따서 문제를 해결한 뒤에도 자신의 답글을 해결책으로 표시합니다. 이는 다른 사람의 도움을 인정하기에는 너무 고집이 센 것인가를 의미하는 것일까요?
제가 보는 또 다른 문제는, 때로는 토픽이 며칠 동안 방치된다는 점입니다. 만약 지원이 유료 옵션이라면 이는 큰 실망이 될 수 있지만, 디스코스 팀은 이미 우리의 목소리에 귀 기울이고 행동에 옮길 만큼 충분히 관대합니다. 메타에서 제공되는 지원은 완전히 무료입니다. 저는 자신의 버그 리포트나 기능 요청이 필사적으로 화제가 되어 좋아요나 댓글 수 기록을 세우기를 기대하지 않습니다. 요청이나 보고가 진정성 있다면, 시간이 허락할 때 포함될 것이며, 우리는 언제든지 유료 고객이 되어 팀의 관심을 더 높은 수준으로 받을 수 있는 선택지를 항상 가지고 있습니다.
결론적으로, 저는 포용적인 행동에 반대하지는 않지만 솔직히 말하자면, 메타의 모든 사용자가 새로운 기여를 격려하려 노력해도, 떠나야 할 사람은 떠나고, 여기 있는 것을 즐기는 사람은 남을 것입니다. 그렇다면 그 의미가 무엇일까요?
나도 그거 쓸 수 있었을 텐데, Jakke.
(네덜란드 사람이고 핀란드 사람이 아닌 건 빼고, 하지만 네덜란드 사람들도 최소한만큼이나 직설적이니까).
그리고 너는 확실히 기여하고 있어.
이 문제에 대한 내 의견은 이렇다:
그래, 때로는 피드백이 부족하면 좀 답답할 수도 있지. 하지만 반면에, 내가 버그를 발견하면 내 게시물에 좋아요가 붙었는지 확인하기도 전에 버그가 수정되고 머지되는 경우를 많이 봤어.
건강한 커뮤니티가 좋은 오픈소스 제품의 중요한 조건인 것은 맞지만, 궁극적인 목표는 아니야: 목표는 제품 그 자체야. 그리고 내가 다른 오픈소스 제품들과 비교해 보면, 이 커뮤니티는 아마도 가장 훌륭한 커뮤니티일 거라고 생각해. 대부분의 다른 오픈소스 제품들은 커뮤니티가 있더라도 훨씬 덜 활기차거나, 일관성이 떨어지거든.
그리고 그래, 때로는 '팀 방어(team defense)'라고 할 수 있는 것도 있지. 하지만 커뮤니티에 이렇게 잘 기여했기 때문에 이렇게 많은 사람을 고용한 다른 오픈소스 제품이 있나?
