메타의 카테고리 구성 방식 업데이트

메타의 테마 및 구조 업데이트의 일환으로, 이곳의 카테고리 구성에 몇 가지 변경 사항을 도입할 계획입니다.

지금까지 몇 가지 다른 아이디어를 검토해 왔으며, 커뮤니티의 피드백을 받으면서 추가적인 수정이 이루어질 것으로 예상됩니다. 하지만 현재 우리가 기울이고 있는 방향은 아래에 제시된 바와 같습니다:

기본적인 아이디어는 관련 카테고리를 더 적은 수의 최상위 카테고리로 그룹화하는 것입니다. 각 최상위 카테고리는 기본적으로 새 사용자의 사이드바에 표시될 것입니다.

  • 뉴스 및 이벤트
  • 지원
  • 커뮤니티 성공
  • 기여
  • 커스터마이징
  • 문서
  • 커뮤니티 위키
  • 마켓플레이스

지원(Support) 카테고리가 여전히 가장 활발한 카테고리 중 하나가 될 것으로 예상되며, 다른 지원 관련 카테고리를 그 아래에 그룹화하면 선택의 어려움을 줄일 수 있다고 생각합니다. 여기서 더 정교하게 다듬을 부분이 더 있을 수 있습니다 (SSO는 카테고리가 되어야 할까요, 아니면 태그가 되어야 할까요? 설치(Installation)와 호스팅(Hosting)의 실제 차이는 무엇일까요? 이를 단일 ‘셀프 호스팅’ 하위 카테고리로 통합해야 할까요?) 이러한 질문들은 진행하면서 해결해 나갈 계획이지만, 전반적인 방향은 모든 지원 관련 주제를 한곳에 모으는 것입니다.

커뮤니티 성공(Community Success)은 우리가 더 많은 투자를 하고 싶은 카테고리입니다. 기존 커뮤니티 카테고리를 기반으로 구축할 예정입니다. 이는 기술적 지원이 아니라, 성공적인 커뮤니티를 구축하는 데 필요한 복잡하고 모호한 ‘소프트한’ 부분에서 성공적인 Discourse 커뮤니티를 운영하는 모든 사람들이 서로를 도울 수 있는 장소로 보고 있습니다. 여기의 기본 구조도 재구성할 가능성이 높지만, 우선 기존 커뮤니티 및 데이터와 리포팅(Data and Reporting) 카테고리가 여기의 주요 기둥이 될 것이라고 생각합니다.

기여(Contribute)는 제품 자체와 이 커뮤니티를 개선하는 방법에 대한 토론의 중심이 될 카테고리로 구상하고 있습니다.

커스터마이징(Customization)은 플러그인, 테마, 컴포넌트 및 기타 확장 기능을 통해 Discourse를 확장하는 것과 관련된 모든 주제를 찾을 수 있는 장소가 될 것입니다.

더 자세히 살펴보고 싶으시다면, 현재 이 구조가 적용된 스테이징 사이트에서 둘러보실 수 있습니다.

스테이징 사이트 접근 방법
  1. https://meta-redesign-2026.discourse.group/ 방문
  2. HTTP 기본 인증을 위해 다음 사용자 이름과 비밀번호 입력
    • 사용자: meta2026bsbx
    • 비밀번호: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
  3. 메타 사이트의 이메일/사용자 이름과 비밀번호 입력
    (스테이징 사이트는 다른 로그인 방법을 지원하지 않습니다.)

확인해 보신 후, 여기에 여러분의 생각을 알려주시기 바랍니다.

5개의 좋아요

self-hosting(셀프 호스팅) 같은 이름의 카테고리가 있다면, 어떤 내용을 올려야 하는지 더 명확해질 것 같습니다. 여전히 완벽한 이름은 아니지만, discourse가 한 번도 작동한 적이 없다는 인상을 주는 #installation보다는 낫습니다. 처음 제 게시물이 해당 카테고리로 이동했을 때 꽤 혼란스러웠거든요. "back-end(백엔드)"라고 하는 게 어떨까요?

셸(shell)에 접근해서 문제를 일으키거나 목격한 경우라면 해당 카테고리에 올립니다. discourse가 정상적으로 "작동"하고 있고, ux나 테마 등 다른 문제라면 support에 올리면 됩니다.

7개의 좋아요

동의합니다.

더 나아가, #installation과 #installation:hosting을 이 새로운 셀프 호스팅 카테고리에 통합해야 한다고 생각합니다.

나머지 구조가 어떻게 결정되든 상관없이 이 작업을 수행할 수 있다고 봅니다. 위에서 제가 개략적으로 제시한 방향으로 나아가면, 이 새로운 카테고리는 지원(Support)의 하위 카테고리가 됩니다.

현재의 평탄한 모델(flat model)을 유지한다면, 최상위 카테고리가 될 것입니다.

4개의 좋아요

다음과 같은 변경을 수행하여 최상위 Support > Self-hosting 카테고리를 새로 만들었습니다:

  • 이전에 Installation > Hosting에 있던 모든 주제를 hosting 태그로 지정했습니다.
  • Installation > Hosting의 모든 주제를 기존 Installation으로 병합했습니다.
  • Installation#support:self-hosting으로 이름 변경했습니다.

"Self-hosting"이 "Self-hosting support"보다 더 나은 이름일 수 있습니다(특히 Support 아래로 이동하는 경우). 하지만 첫 단계로 지금은 "support"라는 단어가 포함된, 조금 더 자세한 이름을 선택했습니다.

3개의 좋아요

참고로, 이전에는 '셀프 호스팅 지원’이라는 명칭을 피했습니다. 그 이름은 셀프 호스터들을 위한 전용 지원 영역인 것처럼 보였고, 그것이 첫인상이 되길 원하지 않았기 때문입니다.

또한 이 명칭은 문서(docs) 카테고리와 매우 유사하며, 단순화를 추구한다면 중복을 원하지 않을 것입니다. '설정(Configuration)'도 고려되었지만, 모든 기능/설정/플러그인 등이 '설정’이 필요하므로 설명력이 부족했습니다. '시스템 관리자(Sys-admin)'는 너무 기술적으로 느껴져서 (Discourse 사이트를 운영하는 데 필요한 기술 수준을 낮추어 보여주고 싶었기 때문에) 제외되었습니다.

설치(Installation)라는 명칭이 모호하다는 점에는 동의합니다. 다만 실제로는 그렇게 많은 혼란을 일으키지는 않았습니다. 더 좋은 이름은 분명 있을 겁니다… :slight_smile:

'호스팅(Hosting)'은 디지털 오션(Digital Ocean), 메일건(Mailgun) 등 기반 서비스를 논의하는 영역이었습니다. 서버 관리와 구분되는 독특한 분위기가 있었고, 500개 이상의 주제(topics)가 있으므로 대화 내용을 분리하는 것이 가능했을 것입니다(이미 존재하지 않는다면요 :slight_smile:).

8개의 좋아요

제 생각에는 이렇게 기대할 것 같습니다:

  • 호스팅: 호스트(서버)를 선택하고 관리하는 것
  • 설치: «디스코urses가 설치되어 있고, 관리자로 로그인해서 작업을 수행할 수 있는 상태»가 되는 것
  • 설정: 다양한 설정 사항에 대한 세세한 부분

처음 시작하는 사람에게는 코어와 «번들된 플러그인»의 구분이 매우 불분명하다고 생각합니다. 따라서 이들을 설정 항목에 포함하거나, 적어도 매우 명확한 안내를 제공해야 한다고 생각합니다.

4개의 좋아요

이 중 어떤 항목은 서로 다른 범주로, 어떤 항목은 서로 다른 태그로 기대하시나요?

그리고 이 항목들이 Support(지원) 범주와 어떻게 관련되어 있다고 기대하시나요?

2개의 좋아요

결국, 설치와 호스팅은 태그로 사용하는 데 문제가 없다고 생각합니다. 하지만 (제 커뮤니티를 위해서도) 특정 범주 안에서 주요 태그를 “고정”하거나 “앞으로 당겨서 강조”하는 방법이 있는지 궁금합니다. (우리가 “이야기를 전달한다”는 관점에서 생각한다면) 이것들도 범주가 될 수 있을 것입니다.

설정(Configuration): 셀프 호스터와 호스팅 관리자 사이에 이 부분이 매우 다를까요? 겹치는 부분이 많을 것 같은 인상을 받기 때문에, 셀프 호스팅(Self-hosting) 안에 고정시켜 두는 것은 아닌지 고민됩니다. (저라면 Self-hosting 지원보다 Self-hosting으로 이름을 바꿀 것 같습니다.) 어쩌면 #support는 “일반 지원(General support)”에 더 가깝지 않을까요? 메타(Meta)에 있는 거의 모든 것이 어떤 식으로든 지원과 관련이 있지 않나요?

참고로: #support:migration은 저에게 혼란을 줍니다. “사람 중심”적인 관점을 가진 사람으로서 즉시 “아, 전체적인 마이그레이션을 어떻게 관리해야 하지?”라고 생각하게 되는데, 해당 범주를 보면 전부 “기술적 마이그레이션”, 스크립트, 내보내기 같은 내용으로 가득 차 있습니다.

최근에 #facebook-migration에 대해 이야기를 나눴는데, 이는 전략, 사람, 그리고 구체적인 과제에 더 초점을 맞춘 것입니다. 일종의 측면에서 보면, #support:migration은 마이그레이션의 더 일반적인 측면이나 인간적인 측면에 관심이 있는 사람들을 위해 악마의 유혹(evil attractor)처럼 작용하는 것 같습니다. 제 의도를 이해하시나요?

2개의 좋아요

앱에서 이 기능을 더 잘 활용할 수 있는 방법을 탐구해볼 가치가 있을 수 있지만, 어떻게 작동해야 하는지는 확실하지 않습니다.

현재로서는 이것이 매우 유기적으로 이루어진다고 생각합니다. 특정 태그들이 주어진 카테고리에 일정량 이상 축적되면, 사람들이 그 패턴을 알아차리고 그것이 번성하도록 장려하기 시작합니다.

태그를 특정 카테고리로 제한하거나, 주어진 카테고리에서 특정 태그 그룹의 태그 수를 요구하는 내장 기능이 있지만, 이것이 때로는 지나치게 부담스러울 수 있다고 느낍니다.

:+1: 동의합니다. 설정은 "일반 지원"에 더 가깝다고 생각합니다(포트 경청과 같은 시스템 관리자 계층의 설정을 하는 경우를 제외하고).

네, 저도 처음에 그렇게 생각했습니다… 하루 정도 두고 보겠지만, 내일 이 세부 사항을 다시 검토하겠습니다.

그렇지만, 그 추가 단어가 얼마나 도움이 되는지 확실하지 않습니다. 그래도 무슨 말씀인지 이해합니다.

네, 여기에는 두 개의 카테고리가 숨어 있을 가능성이 있습니다. 제안된 중첩 구조의 관점에서 보면, support/migrationdev/migration처럼 나누는 것이 더 적합할 수도 있습니다.

여기서 먼저 작은 단계를 밟은 후, 시간이 지나면서 형태를 더 다듬어 나갈 수 있을 것 같습니다.

말씀하신 의도는 이해합니다. 다만 드롭다운에 숨겨져 있다는 사실 때문에, 눈에 띄게 표시할 수 있는 하위 카테고리보다 가시성이 훨씬 낮습니다.

이 부분은 나중에 다시 말씀드리겠습니다. 왜냐하면 저는 특정 카테고리에서 특정 태그 그룹의 태그를 최소 하나 이상 요구하는 기능을 꽤 광범위하게 사용할 계획이기 때문입니다. :sweat_smile: 이는 하위 카테고리의 증식을 피하기 위한 것입니다.

일부는 그렇다고 생각합니다만, 또 다른 부분은 "설치(installation)"의 연속, 즉 모든 설정 과정이라고 봅니다. 맞습니다, 이제 저는 Discourse를 설치했고, 놀라운 기능들이 있으며, 많은 것들을 제어할 수 있지만, 제 커뮤니티가 필요로 하는 형태로 이를 어떻게 "형성(mold)"하나요? 이 부분이 과거에 저를 매우 낙담하게 만들었습니다. 모든 설정과 항목들이 문서화되어 있었지만, a) 어디서부터 시작해야 할지 이해하는 것과 b) 제 커뮤니티에 대한 "비전"을 설정과 구성으로 어떻게 번역해야 할지 이해하는 데 어려움을 겪었기 때문입니다.

따라서 제가 생각하는 것은 초기 설정 여정을 둘러싼 추가적인 계층일 수 있습니다. 저는 #support를 ("일반 지원"으로 이름을 바꾸지는 않을 것입니다. 그렇게 말한 것은 제가 그것을 어떻게 지각했는지를 나타내기 위함이었습니다) "이미 운영 중이거나 해결해야 할 특정 문제가 있는 경우"에 더 적합하다고 생각하며, "상자에서 꺼낸 그대로의 설치 상태를 가지고 이제 어떤 준비를 해야 출시할 수 있는가"에 대한 것은 아닙니다.

결국, "설정(configuration)"이 관리자의 여정 일부로서 의미가 있다고 실제로 생각하며, 그것은 정확히 "지원(support)"과 동일하지 않다는 것입니다.

제 커뮤니티에 대한 비유를 들면 – 적절한 대화에서 그 관련 뉴스를 공유해야 한다는 것을 떠올리게 합니다 – 진단을 방금 받고 우리 커뮤니티에 가입한 당뇨병을 앓고 있는 고양이 주인을 고려해 볼 때, 우리는 카테고리를 어떻게 조직해야 할까요? 제가 현재 결정한 것은 매우 "멤버 중심(member centric)"으로 시작하는 것입니다. “방금 도착했어, 대체 무슨 일이야?”(더 정중한 프랑스어 equivalents), “필요한 장비를 구하고 있어”, “배우고 있어” – 그리고 그 후에 비로소 커뮤니티의 핵심인 적절한 "지원"이 준비됩니다.

Discourse에 대해 처음 접하는 저와 같은 입장에서 이러한 방향으로 생각해보면, 분명히 다음이 있습니다: 1) 셀프 호스팅을 할지 말지 결정하고 호스팅을 선택하는 것, 2) 실제 설치 과정을 거치는 것, 3) 제 커뮤니티를 설계하고 그것을 Discourse 구성으로 번역하는 것. 이 경우 a) 처음부터 구축하는 것과 b) 커뮤니티가 이미 존재하고 그것을 이전하려는 것 사이에 구분을 두어야 합니다. 제 facebook migration challenges 주제에서 논의했듯이, 설정 방식을 바꾸는 것이 정말 중요하다고 생각합니다.

이것은 우리를 이전(migration) 관련 내용을 어디에 두어야 하는지라는 문제로 데려다줍니다.

다시 말하지만, 우리가 어떤 이야기를 하고 싶은지에 따라 달라진다고 생각합니다. Discourse가 기존 커뮤니티의 이전을 장려하고 촉진하기를 원하는 것입니까, 아니면 Discourse로 처음부터 구축할 사람들에게 초점을 맞추고 있는 것입니까?

놀라운 일이 아니지만, 저는 이전할 고객들에게 초점을 맞추는 것이 합리적이라고 주장하겠습니다. 왜냐하면 거기에 아직 개발되지 않은 거대한 시장이 있다고 확신하기 때문입니다.

그 경우, "이전(Migration)"이 너무 깊게 묻히지 않기를 원합니다. 저는 개인적으로 이를 커뮤니티 관리(Community Management)의 한 측면으로 유지하고, 현재 커뮤니티 카테고리를 그렇게 이름 변경할 것입니다. "커뮤니티"만으로는 모호하여, 처음에는 "Discourse 커뮤니티를 위한 것"이 아니라 "커뮤니티를 설계/구축/관리하는 것에 관한 것"이라고 생각했기 때문입니다. 태그일까요, 하위 카테고리일까요? 적어도 하위 카테고리가 될 자격은 있습니다. 이전 스크립트와 이전 주위의 기술적 사항은 다른 최상위 카테고리에 들어가야 할까요?

아니면 이전(Migration) 자체가 카테고리가 될 수도 있으며, 이는 기존 커뮤니티의 측면을 Discourse로 어떻게 적응하고 번역하는지에 대한 논의, 실제 이전 과정(구현)에 접근하는 방법, 그리고 "데이터 이전"을 포함합니다.

1개의 좋아요

잠깐. #unsupported-install처럼 #standard-install로 주제를 태그하도록 사용자를 유도하는 방법이 있다면 어떨까요?

그 방법을 정확히 어떻게 만들어야 할지 잘 모르겠네요.

2개의 좋아요

현재 제안안에서는 "커뮤니티 성공(Community Success)"을 최상위 카테고리로, "커뮤니티 관리(Community Management)"를 그 하위 카테고리로 설정하는 것을 구상하고 있습니다. 이는 여기서 당신의 생각과 어떻게 일치하나요?


여정의 전형적인 단계가 어떻게 보일 수 있는지에 대한 우리의 이해를 바탕으로 몇 가지 안내(signposting)를 정의하는 아이디어는 마음에 듭니다…

1개의 좋아요

이 두 가지의 구분이 잘 이해가 되지 않습니다. 커뮤니티 관리에 포함되지 않는 커뮤니티 성공에 해당되는 내용은 무엇인가요? 지금까지 Community Building 채널에서 제가 올린 내용들을 생각해보면, 커뮤니티 관리에 넣어야 하나요, 성공에 넣어야 하나요?

내일이나 금요일에 다시 생각해봐야겠습니다. 오늘은 머리가 너무 지쳐서요. 죄송합니다!

1개의 좋아요

거기 있는 목업에서 볼 수 있는 하위 카테고리 외에도, 커뮤니티를 _관리_하는 것(설계 및 구축) 외에 두 가지 활동을 언급했습니다:

하지만 대부분의 사람들에게는 여전히 모든 것이 "관리"에 포함될 수 있습니다.

클릭하여 이동

자격 증명을 포함한 원 클릭 스테이징 사이트

→ 로봇이 그곳으로 가지 않도록 원치 않는 경우를 대비해 숨겨둡니다.

카테고리 재배치 제안입니다:

  • 뉴스 & 이벤트
    • 공지사항
    • 블로그
    • 요약
  • 커뮤니티
    • 아고라 (기존: 일반)
    • 사이트 피드백
    • 칭찬
    • 비교
    • 커뮤니티 관리
    • 마켓플레이스
    • 사용자 위키
    • 관리자 위키
    • 개발자 위키
    • 시스템 관리자 위키
  • 문서
    • Discourse 사용법
    • 사이트 관리
    • 통합
    • Discourse 호스팅 (기존: 호스팅 고객)
    • 셀프 호스팅
    • Discourse로 마이그레이션
    • 개발자 가이드
    • 기여하기
  • 도움말
    • 설치
    • 호스팅
    • 마이그레이션
  • 통합
    • WordPress
    • SSO
  • 기여
    • 버그
    • 기능 요청
    • 개발
    • 번역
    • UX
  • 커스터마이즈
    • 플러그인
    • 추가 기능
    • 테마
    • 테마 컴포넌트
    • 데이터 & 리포트

근거:

  • #community-building은 어디에서도 다루지 않는 주제에 대한 토론이 이루어지는 활기찬 공간이 될 것입니다. 위키, 일반 토론(#agora), 사이트 피드백, 칭찬 및 다른 소프트웨어와의 비교를 포함하여 더 큰 Discourse 커뮤니티를 하나로 모으고, 커뮤니티 관리와 마켓플레이스에 대한 토론도 이루어질 것입니다.
  • #news-events는 일반적인 CDCK 커뮤니케이션을 위해 사용됩니다.
  • #help는 지원을 받기 위해 사용됩니다.
  • #integrate는 특정 통합에 대해 토론하기 위해 사용됩니다.
  • #documentation은 공식 지식 베이스를 호스팅합니다.
  • #contribute는 모든 개발 프로세스를 호스팅합니다.
  • #customize는 각 Discourse 인스턴스를 특별한 커뮤니티로 만드는 모든 것, 데이터 리포팅과 탐색을 포함하여 호스팅합니다.

새로운 사용자가 오면 (공식) 문서로 가거나 커뮤니티 토론으로 갈 것입니다…

tl0에서 tl1로 넘어가거나 분위기와 영역을 파악하는 등 새로운 사용자를 쉽게 온보딩하고 탐색할 수 있도록, 몇 개의 소개 주제들을 가리키는 #welcome 태그를 제안합니다.

아마도 문서 시스템 태그인 tutorial, explanation, how-to, #reference로 문서를 두드러지게 시작해야 할 것입니다.

커뮤니티 관리(Community Management)를 커뮤니티 빌딩(Community Building)이라고 부를 수도 있습니다… 이유를 알 수 없지만 "Community Success"라는 표현은 마음에 들지 않습니다.

3개의 좋아요

네, 이전에 다른 커뮤니티에서 그렇게 해본 적이 있고, 카테고리 사용 외에도 온보딩 경로를 표시하는 데 유연하고 좋은 방법이라고 생각합니다. 다음과 같은 방식이죠.
image

4개의 좋아요

이러한 시도에 박수를 보내며, 이 과정에 우리를 포함해 주셔서 감사합니다.

@stephtara 님의 Discourse 여정을 지켜본 결과, 메타(Meta)에는 새로운 커뮤니티 빌더를 위한 전용 공간이 필요하다는 것이 분명합니다. 이름을 무엇으로 지을지는 모르겠지만, 처음 Discourse로 커뮤니티를 구축하는 사람들을 위한 따뜻하고 아늑한 공간이 있다면 설정 옵션 과부하로 인한 혼란을 줄이는 데 도움이 될 것입니다. 여기서 도움을 제공하는 분들은 이 영역에서 답변을 할 때 추가적인 노력과 인내가 필요할 수 있다는 점을 알아야 합니다.

아마도 제가 놓친 것일 수 있지만, 현재 관리자 영역을 반영하는 색인을 가진 ‘설정 옵션’ 문서 카테고리가 있다면 훌륭할 것입니다. Discourse는 항상 진화하고 있습니다. 문서도 그에 맞춰 발을 맞춰야 합니다.

이러한 카테고리/태그 개편과 함께 기존 주제의 '새로운 정리’가 뒤따라 주었으면 합니다. 메타에서 답변을 찾느라 보내는 대부분의 시간은 어떤 정보가 현재 Discourse 상태에 관련이 있고 어떤 것이 오래되어 적용되지 않는지 구별하는 데 쓰입니다. 고백하건대, 제 BBS(게시판)가 문제의 일부이지만, 많은 문서들이 구별하기 매우 어렵습니다. 직원들이 문서를 개선하기 위해 해왔고, 여전히 하고 있는 노력에 감사하지만, 많은 문서들이 개선이 필요한 것 같습니다.

이 목적을 위해, 문서로 보이는 대부분의 문서나 주제에 ‘리뷰 필요(Needs Review)’ 태그를 붙이는 것을 제안합니다. 네, 그것은 엄청난 양의 태그가 되겠지만, 리뷰 과정이 완료되면 사용자 경험이 크게 향상될 것입니다. 저를 포함한 다른 몇몇 사람들이 이 노력에 도움을 줄 의향이 있습니다. 편집 및 태그 지정 순서가 프로세스 관리를 도울 수 있습니다.

저는 한 사이트에서 이렇게 사용하고 있습니다:

요약

리뷰-필요 Needs-Text 인용-필요 작업-필요 게시-준비됨

아마도 ‘오래됨(Out of Date)’ 태그가 도움이 될 수 있을 것입니다.

@mcwumbly 님, 이 재조직화를 시작해 주시고 또한 이 과정에 우리를 포함해 주셔서 다시 한번 감사합니다. :clap:

6개의 좋아요

다음 단계에 대한 계획은 다음과 같습니다:

  • 2월 23일 주
    • 첫 번째 게시글의 구성과 일치하도록 여기의 카테고리 구조를 업데이트합니다. 지금까지의 피드백을 바탕으로 일부 유연한 조정을 가할 수도 있습니다.
    • 실제 사용감을 중심으로 더 많은 토론과 피드백이 이어질 것으로 예상됩니다.
    • 피드백을 바탕으로 일부 세부 조정을 진행합니다.
  • 3월 2일 주
    • 전반적으로 만족스러운 느낌을 준다면 계속 개선해 나갑니다. 또는
    • 기대와 많이 벗어나는 느낌이 든다면 되돌립니다.
5개의 좋아요

여기에 아이디어를 남겨둡니다:

아마도 이 주제에 별도의 토론 주제를 여는 것이 더 적절할 것 같지만, 일단 이 더 큰 재편의 일환으로 여기서 먼저 논의해 볼 수 있습니다.

3개의 좋아요

여러분이 함께 실제 사용감을 파악해 볼 수 있도록 먼저 1차 변경 사항을 적용해 두었습니다.

기본 사이드바 카테고리도 업데이트했지만, 아직 모든 사용자에게 적용하지는 않았습니다. 사이드바를 새로운 기본값으로 설정해 보고 싶으시다면 다음 단계를 따르세요:

  1. 사이드바의 “Categories” 옆에 있는 연필 아이콘을 클릭합니다.
  2. 모달 창 오른쪽 하단의 "Reset to defaults"를 선택합니다.
  3. 원하는 대로 조정합니다.
  4. :Save Changes"을 클릭합니다.

향후 약 1주일 동안 이곳에서 피드백을 공유해 주세요:

2개의 좋아요