Discourse를 사용하여 RFC 상태 추적하기

기여 기능
1

기능 이름

Discourse의 상태(State of Discourse)

기능 목표

Discourse를 RFC(요청서) 형식의 포럼으로 만들기

기능 설명

  1. 의견 요청서(RFC)는 인터넷의 주요 기술 개발 및 표준 설정 기관, 특히 인터넷 엔지니어링 태스크 포스(IETF)에서 발행하는 일련의 문서입니다. RFC는 개인 또는 엔지니어 및 컴퓨터 과학자 그룹이 인터넷 및 인터넷 연결 시스템의 작동에 적용 가능한 방법, 동작, 연구 또는 혁신을 설명하는 메모 형태로 작성합니다. 이는 동료 심사를 위해 제출되거나, 새로운 개념, 정보, 또는 때로는 엔지니어링 유머를 전달하기 위해 사용됩니다. [1]
  2. Discourse의 상태는 RFC 형식 문서의 상태와 유사합니다. Discourse의 상태는 사용자 게시물을 더 잘 제어하는 데 사용됩니다. RFC 문서에는 다음 상태들이 있습니다:
  • 정보 제공(Informational)
  • 실험적(Experimental)
  • 최선 현재 관행(Best Current Practice)
  • 표준 트랙(Standards Track)
  • 제안(Proposed Standard)
  • 초안(Draft Standard)
  • 인터넷 표준(Internet Standard)
  • 역사(Historic)
  • 미확인(Unknown)

제 경우, 제 리소스에서는 게시물 유형에 따라 다음과 같은 상태가 됩니다:

Discourse의 상태 / 코드

  1. 초안(Draft Standard) | 1 - 초안(Draft Standard)
  2. 실험적(Experimental) | 2 - 실험적(Experimental)
  3. 제안 표준(Proposed Standard) | 3 - 제안(Proposed Standard)
  4. 표준 트랙(Standards Track) | 4 - 표준 트랙(Standards Track)
  5. 최선 현재 관행(Best Current Practice) | 5 - 최선 현재 관행(Best Current Practice)
  6. 역사(Historic) | 6 - 역사(Historic)
  7. 정보 제공(Informational) | 7 - 정보 제공(Informational)
  8. 표준(Standard) | 8 - 표준(Standard)
  9. 미확인(Unknown) | 9 - 미확인(Unknown)

Discourse의 상태 / 사례

  1. 사용자가 게시물을 생성하고 해당 게시물에 응답이 없는 경우. 이 게시물은 Discourse 상태로 초안(Draft Standard)이 됩니다. 사용자가 게시물을 생성하고 해당 게시물이 게시되지 않은 경우에도 이 게시물은 Discourse 상태로 초안(Draft Standard)이 됩니다.
  2. 사용자가 게시물을 생성하고 해당 게시물에 답글이 있는 경우. 이 게시물은 실험적 Discourse 상태가 됩니다. 응답이 더 많으면 이 게시물은 실험적(Experimental) Discourse 상태가 됩니다.
  3. 여러 사용자가 게시물을 좋아하고 이 게시물이 좋다고 진심으로 믿는 경우, 해당 게시물은 표준 트랙(Standards Track)으로 태그됩니다. 동일하거나 유사한 게시물이 더 많으면 기본 상태는 최선 현재 관행(Best Current Practice) Discourse 상태로 공지됩니다.
  4. 게시물에 대한 모든 수정 사항은 역사(Historic) Discourse 상태로 공지됩니다.
  5. 게시물이 모든 커뮤니티 멤버에 의해 수용되면, Discourse 상태는 정보 제공(Informational)이 됩니다.
  6. 게시물이 수정 또는 개선이 필요하면, 상태는 정보 제공(Informational) Discourse로 공지됩니다. 게시물이 수정되고 개선되면, 상태는 제안(Proposed Standard) Discourse로 공지됩니다.
  7. 게시물에 1주, 1일, 1개월 또는 1년간 답글이 없으면 - 상태는 미확인(Unknown) Discourse로 공지됩니다.

참고 사항

  • 이 상태는 자동으로 설정됩니다
  • 게시물 상태는 항상 홈페이지에 표시됩니다
  • 게시물 상태를 가질 수 있다는 멋진 점은 해당 게시물을 추적할 수 있다는 것입니다
  • 남용 방지, 스팸 방지, 순서 무너짐 게시물 방지를 위한 사용자 게시물에 대한 품질 관리
  • Discourse는 매력적이고 더욱 커뮤니티 지향적인 소프트웨어이며, 소프트웨어의 품질과 사용자 경험의 품질을 높이는 것보다 더 나은 것은 없습니다

아이디어

image
image1285×354 26.7 KB

설명 이미지

이미지에서 볼 수 있듯이, 동일한 게시물에 서로 다른 상태가 있을 수 있습니다. 사용자 상호작용에 따라 상태가 변경됩니다. 상태는 1, 2, 3, 4, 5, 6, 7, 8 또는 9일 수 있습니다. 이미지에서 무언가가 발생하여 게시물이 많은 댓글을 받고, 초안 상태에서 표준(Standard) 상태, 코드 8로 넘어가는 것을 볼 수 있습니다.

참고 문헌

1개의 좋아요
2

애드온 없이 이 작업을 수행하는 한 가지 방법은 각 레벨에 대해 하위 카테고리(또는 단순히 최상위 카테고리?)를 만들고, 게시물이 "승격"될 때 이를 해당 카테고리 간에 이동하는 것입니다.

플러그인을 사용하면 정의한 기준에 따라 게시물을 카테고리 간에 이동할 수 있거나, API를 사용하여 이를 수행하는 외부 스크립트를 사용할 수도 있습니다.

3개의 좋아요
3

그러니까 이 주제는 Discourse에 RFC 관련 기능을 추가하는 것에 대한 건가요? 그렇다면 이 토픽의 제목이 그렇게 되어야 하지 않을까요?

2개의 좋아요
4

저는 확실히 몇 가지 추측을 바탕으로 해석하고 있지만, Discourse에 “상태 추적” 기능을 추가하는 것에 관한 것 같고, RFC 추적이 그 예시일까요? 솔직히 "State of Discourse"가 일종의 농담으로 의도된 건지 확신은 없지만.. 어쨌든 꽤 혼란스럽고 다른 것으로 바뀌어야 한다고 생각합니다.

어쨌든…

저희는 현재 Fedora Linux의 Common Issues에 대해 훨씬 덜 복잡한 작업을 수행하고 있는데, 제가 생각하기에는 이것이 유사할 수 있습니다. 최상위 (Accepted) Common Issues 카테고리에 Proposed Common Issues와 Archived Common Issues 카테고리가 있습니다. 위에서 제안했듯이, 저는 외부 스크립트(지금으로서는 매우 엉성합니다 — 저는 실제로 프로그래머가 아니므로)를 사용하여 게시물을 처리하고 카테고리 간으로 이동시키고 있습니다.

2개의 좋아요
7

나는 몇 가지 추측을 바탕으로 해석하고 있지만, RFC 추적을 예로 들어 Discourse에 “상태 추적” 기능을 추가하는 것에 관한 것인 것 같습니다.

  • 네. 정확히 제가 생각했던 내용입니다. Discourse의 상태는 RFC에 기반합니다.
  1. RFC에 대해 언급한 이유는, 제가 속한 팀의 일부가 개발하는 기술 문서 중 일부가 비슷한 일을 하기 때문입니다.
  2. 문제는 이 과정이 매우 관료적이고 수동적이며, 때로는人為적 오류가 발생할 수 있다는 점입니다.
  3. 때로는 팀의 검토를 받아야 하는 기술 문서를 작성하는데, 팀의 해당 구성원이 매우 주의가 부족하거나 세세한 부분까지 살피는 사람이 아닌 경우, 제출된 문서가 잘못된 위치에 놓일 수 있습니다. 제 아이디어는 우리 소규모 팀에 Discourse를 구현하는 것입니다.
  4. 제 아이디어는 기술 문서로 작업하는 방식과 관련이 있으며, 사람들이 작성하는 게시글을 추적하는 것입니다. RFC를 기반으로 게시글을 추적하는 것입니다. 이는 우리가 많이 작업하는 분야이기 때문입니다.
  5. 하지만 Discourse나 기타 포럼형 소프트웨어에서 RFC 기반 게시글 상태와 같은 플러그인이나 유사한 자원을 찾지 못했습니다.
  6. 제 생각에 이 기능은 혁신적입니다. 레거시 소프트웨어를 사용하는 기술 문서 팀을 생각해보면 그렇습니다. 저는 이러한 레거시 및 구식 소프트웨어를 Discourse로 대체할 수 있다고 믿습니다. Discourse는 매우 흥미로운 소프트웨어이며, 제가 매우 좋아합니다. 기회가 될 때마다 친구와 지인들에게 추천합니다. 제 문제는 방금 설명한 RFC 기반 게시글 상태와 같은 플러그인이나 유사한 기능을 찾지 못했다는 것입니다.

우리는 현재 Fedora Linux의 일반 문제(Common Issues)에 대해 훨씬 덜 복잡한 무언가를 수행하고 있으며, 이는 위에서 제안한 것과 유사할 수 있다고 생각합니다. 최상위 (Accepted) Common Issues 카테고리에 Proposed Common Issues와 Archived Common Issues 카테고리가 있습니다. 저는 외부 스크립트(현재로서는 매우 어설프다 — 저는 실제로 프로그래머가 아닙니다)를 사용하여 게시글을 카테고리 간으로 처리하고 이동하고 있습니다.

  • 카테고리나 하위 카테고리를 계속 살펴보고 싶지 않습니다. 동적인 무언가를 원합니다.
  • 사용자가 상호작용하는 방식에 따라 새로운 상태가 생성될 수도 있고, 아닐 수도 있습니다.
  • 상태가 변경되지 않는 경우, 제가 계획하고 있는 것과 같은 작업을 수행해야 합니다. 즉, 게시글을 한 카테고리에서 다른 카테고리로 이동시키는 스크립트를 작성해야 합니다.
  • 저는 당신을 비판하는 것이 아닙니다. 이 아이디어는 좋다고 생각하며, 사실 저도 이와 같은 무언가를 해보고 싶다는 생각을 했지만, 같은 생각을 하는 사람을 알지 못했습니다. 제가 보는 유일한 문제는 제가 프로그래머가 아니라는 것 :frowning: 과 인터넷에서 이 작업을 수행하는 스크립트를 찾지 못했다는 것입니다.
1개의 좋아요
8

이 내용을 이해하지 못하겠습니다. "카테고리"란 단순히 라벨일 뿐이며, 계층형 뷰로 표현되는 메타데이터의 일종입니다. 이들을 모두 하위 카테고리로 설정한 후 최상위 카테고리의 “전체” 뷰를 보면 모든 게시물을 볼 수 있습니다.

이 상태를 어떤 식으로든 추적해야 합니다. 상당한 수준의 추가 작업이 수반되지 않는 한 다른 옵션은 태그를 사용하는 것일 수 있지만, 저는 여전히 카테고리가 더 적합하다고 생각합니다. 예를 들어, 카테고리를 사용하면 권한 수준을 다르게 설정할 수 있으며, “상위” 상태의 주제에 대한 검색 랭킹을 높이고 “하위” 상태의 것은 낮추어 공식 문서를 우선순위로 둘 수 있습니다.

2개의 좋아요
9

이 상태를 어떻게든 추적해야 합니다. 상당히 침입적인 추가 없이 다른 옵션이라면 태그를 사용하는 것이겠지만, 저는 정말로 카테고리가 더 적합하다고 생각합니다. 예를 들어, 카테고리를 사용하면 다른 권한 수준을 설정할 수 있고, “높은” 상태의 주제에 대해서는 검색 랭킹을 높이고 “낮은” 상태의 주제에 대해서는 낮추어 공식 문서가 우선적으로 표시되도록 할 수 있습니다.

  • 맞습니다. 많은 부분을 명확히 해 주셔서 감사합니다. 정말로 카테고리가 훨씬 더 좋습니다
1개의 좋아요