즉, DB 등 인스턴스 배포에 대한 이야기는 아닙니다.
카테고리, 태그, 정책 등을 선언적 형식으로 관리하기 위한 패턴이 있을까요? 기술적인 사용자들이 토픽 스레드나 수동 처리 대신 PR을 통해 변경 사항을 제안할 수 있으면 좋겠다고 생각했는데, Discourse의 조직 구성에 초점을 맞춘 플러그인이나 기타 “as code” 도구를 찾지 못했습니다.
5개의 좋아요
사이트들이 이를 위해 사전에 설정된 Contribute > Site feedback 카테고리를 사용할 것으로 기대하고 있습니다. 해당 카테고리의 설명은 다음과 같습니다: “이 사이트, 그 조직 구조, 작동 방식 및 개선 방안에 대한 토론.”
흥미로운 아이디어입니다. 일반 토픽에서 사용자가 변경 사항을 제안하는 것보다 어떤 이점이 있을까요? 목표가 사이트 설정에 대해 시간이 지남에 따라 이루어진 변경 사항을 추적하는 방법을 마련하는 것인가요?
사이트 설정, 카테고리, 태그, 정책 등은 Discourse API를 통해 설정할 수 있습니다. git 저장소에서 API를 통해 사이트 구성을 관리하는 스크립트를 사용하는 것이 가능할 수 있습니다. 저장소의 PR이 수락될 때 이 스크립트를 실행할 수 있습니다. 제 관점에서 보면, 이는 UI를 통해 사이트 구성을 수동으로 변경하는 것보다 더 어려울 것입니다.
2개의 좋아요
카테고리에 대해 10-4(확인)입니다. 일단 기존 패턴을 기반으로 크라우드소싱을 조금 진행해 보고 있습니다. 제 입장에서는 GitOps 스타일의 커뮤니티 참여를 이끌어내는 것이 핵심이라 이 방향으로 결정했지만, 도움이 된다면 다른 방향으로 전환할 수도 있습니다.
그리고 네, 우리는 많은 부분에 대해 설정을 코드(config as code)로 다루고 있어서 깔끔한 버전 관리, 결정론적 롤백, 명확한 변경 사항 검토 등의 이점을 얻고 있습니다. GUI 기반의 변경도 나쁘지 않고(현재 커뮤니티 피드백 루프를 통해 이렇게 하고 있으며) 하지만 이는 수동 작업이므로 의사결정 맥락이 시간이 지남에 따라 사라질 수 있습니다. 또한 조직 구조는 인프라와 실제 대화 사이에 존재하므로 배포나 리하이드레이션(데이터 복원)의 문제가 아닙니다.
그리고 네, PR 기반 트리거(또는 Issue)를 통해 제안된 변경 사항을 파악하고 작업을 수행하는 런북을 실행할 수 있습니다. Diff 분석과 린팅은 어려울 수 있어서 아직 누군가가 시도해 봤는지 알아보기 위해 살펴보고 있었습니다. 이 요구사항은 분명히 ‘있으면 좋은(nice to have)’ 범주에 속하며, 특정 인구 집단에 한해서만 공감을 얻을 수 있을 것입니다.
2개의 좋아요
저는 (그리고 우리 프로그래밍 언어 커뮤니티도) 이 기능이 정말로 필요할 것 같습니다. 특히, GitHub 저장소에서 테마, 컴포넌트, 사이트 텍스트를 관리하고, 사람들이 쉽게 풀 리퀘스트를 제출할 수 있으면 좋겠습니다. 일반적인 사이트 설정도 좋겠지만, 웹 UI에서 유지보수가 가장 어려운 것은 이 세 가지입니다.
만약 현재 이것이 불가능하다면 — 유료/호스팅 인스턴스의 경우 불가능하다고 생각합니다 — 이를 기능 요청으로 재분류할 수 있을까요? 특히, 테마와 컴포넌트가 git 저장소를 가리킬 수 있다면 정말 훌륭할 것입니다.
또는, 대안으로, 위에서 제안한 GitHub 트리거 통합을 구현한 사람이 있을까요?
1개의 좋아요
그 말을 작성한 직후 UI를 다시 확인해 보았습니다. git 저장소에서 테마를 생성/가져오는 것은 가능한 것 같습니다! 그렇다면 업데이트는 어떻게 작동하나요? 새로운 커밋을 가져올 수 있을까요? Installing a theme from a private Git repository 를 찾았지만, 이 글에는 업데이트에 대한 언급이 없습니다.
기존 테마나 컴포넌트를 git 저장소를 추적하도록 변환할 수 있나요?
테마를 내보내고 저장소에 업로드한 뒤 설치할 수 있습니다.
모든 원격 테마의 상단에는 Discourse 업데이트 시 자동으로 업데이트할지 여부를 결정할 수 있는 섹션이 있습니다. 또한, 더 최신 버전이 있는지 확인하는 백그라운드 작업이 있으며, 수동으로 새 업데이트를 확인할 수도 있습니다. 새 버전이 사용 가능한 경우, 버튼에서 해당 구성 요소를 업데이트하도록 제안합니다.
해당 정보는 Installing a theme or theme component 의 가이드에서도 확인할 수 있습니다.
아직 찾지 못했다면, 테마 개발에 대한 튜토리얼도 있습니다.
3개의 좋아요
정말 좋습니다, @Moin 감사합니다! 우리 사이트 커스터마이징의 두 가지 큰 요소를 잘 다루고 있네요.
**사이트 텍스트(Site Texts)**를 git으로 관리하고 싶습니다. 가이드라인이나 FAQ와 같은 많은 텍스트가 길고 복잡하며, 오픈소스로 공개하여 커뮤니티의 피드백과 검토를 받을 수 있기 때문입니다.
나머지 사이트 설정도 있으면 좋겠지만, 그보다는 덜 중요합니다.
이들은 보통 스태프 카테고리 내의 주제에 기반을 둡니다. 다른 카테고리로 이동시키고 게시물을 위키로 만들 수 있습니다. 그러면 회원들이 이를 편집할 수 있습니다.
또한 FAQ URL, 개인정보처리방침 URL, 이용약관 URL 사이트 설정을 사용하여 이들을 다른 곳에 호스팅할 수도 있습니다
1개의 좋아요
네, 하지만 FAQ URL 설정은 불행히도 다른 동작을 가지고 있어 이 목적에 사용하면 오히려 역효과를 냅니다.
소스 컨트롤에서 콘텐츠를 관리할 수 있다는 것이 이미 명확하다는 점을 지적하고 싶습니다. 이 주제를 참고해 보세요. GitHub에서 유지 관리되고 있습니다:
하단에:
다만 이 기능이 이미 출시되었거나 발표되었는지(또는 그렇게 예정되어 있는지)는 확실하지 않습니다.
1개의 좋아요
관리자 패널의 site_texts 섹션에 업데이트를 API를 통해 제출하는 GitHub 액션을 만드느라 조립해 보고 있습니다. 현재는 아직 매우 기초적인 수준이며(어떤 이유인지 모르겠지만 값이 클 때 422 오류가 발생하여 실패하곤 합니다), 그래도 가능성은 있어 보입니다.
아직 더 많은 작업이 필요합니다.
1개의 좋아요
현재 재사용 가능한 도구로 출시할 계획은 없습니다. 하지만 저희 동기화 코드는 여기에서 확인하실 수 있습니다. 데이터 탐색기 쿼리(상세 내용은 여기)를 포함하여 일반적인 Discourse REST API에 모두 의존합니다.
2개의 좋아요
지난해 여기에 언급했던 작업을 계속 발전하는 로봇의 도움으로 되살렸습니다:
물론 Julia로 작성되어 있지만, Discourse의 (대부분) 직관적인 관리자 API 덕분에 실제로는 코드가 거의 없습니다. 몇 가지 엔드포인트를 호출하는 두 개의 GitHub 액션으로 다음을 지원합니다:
- 사이트 텍스트 사용자 정의
- 주제 첫 게시물 편집 (지침, 서비스 약관 및 개인정보 처리 방침을 대상으로 하며 확장 가능합니다)
- 모더레이션 플래그
목표는 오픈소스 커뮤니티가 익숙한 오픈소스 도구와 합의 과정을 활용하여 우리의 집단적 규범을 정의하는 데 도움을 주는 것입니다.
물론 관리자 API 키를 잘 관리해야 합니다. 또한 main에 병합하면서 실수로 새로운 엔드포인트를 활성화하여 첫 번째 동기화 시 민감한 설정이 노출되지 않도록 주의해야 합니다.
1개의 좋아요