위 내용에 대해 간단한 질문이 있습니다. 해결책이 포함된 자동 닫힌 주제는 어떻게 처리되나요? 논리적으로는 해결책이 있으므로 이러한 주제가 표시되기를 원하지만, 제가 파악한 바로는 현재 이러한 주제는 자동으로 덜 눈에 띄게 표시됩니다.
15개의 좋아요
이것을 사이트 설정으로 토글할 수 있을까요? 어떤 경우에는 주제가 닫힘(Closed) 상태이면서 동시에 해결(Solved)된 상태일 수 있습니다. 반대로 일부 사용자는 이것이 결과에서 더 높은 순위로 나와야 한다고 기대할 수도 있습니다.
검색 기능이 관심을 받기 시작했다는 점을 매우 기쁘게 생각합니다. 카테고리를 지정하여 검색할 수 있다는 것만으로도 우리의 사용 사례에 큰 장점이 됩니다.
조금 더 개선되었으면 하는 한 가지는 오타 처리입니다. 일부 검색 엔진에 익숙해져서, 원본 단어와 아주 희미하게 닮은 문자 조합이 검색창에 입력될 때까지 게으르게 키를 두드리게 됩니다. 
이것이 정확히 매칭되길 기대하지는 않지만, 그 부분의 개선은 큰 전진이 될 것입니다.
9개의 좋아요
대담한 의견입니다! 저는 일관성을 유지하는 것이 더 낫다고 생각합니다(즉, 사이트별 옵션을 두지 않는 것). 그리고 다음과 같이 해야 한다고 생각합니다:
- 해결됨으로 표시된 닫힘 게시물의 우선순위를 높입니다(열려 있는 게시물보다 더 높은 수준으로).
- 자동으로 아카이브할 닫힘 게시물을 위한 타이머 옵션을 추가합니다(이상적으로는 카테고리별 및/또는 태그별 설정).
- 아카이브된 게시물 중에는 해결책이 있는 게시물을 우선시하되, 아카이브되지 않은 게시물보다 위에 표시되도록 너무 높게 설정하지는 않습니다.
면책 조항: 네, 제 사이트에도 그 자동 아카이브 기능이 필요하다고 말씀드릴 수 있습니다! 하지만 일반적으로도 합리적이라고 생각합니다. 답변은 있지만 더 이상 관련이 없을 가능성이 큰 내용은 치워져야 합니다. 그리고 원치 않는 경우(해결된 질문이 시의적절하게 유효한 경우) 아카이브 기능을 활성화하지 않으면 됩니다.
8개의 좋아요
왜 그런가요? 개발 측의 편의를 위해서인가요? 아니면 사용자가 여러 디스코urs(디스코)를 오갈 때 생활이 편해지기 때문인가요? 아니면 다른 이유가 있나요?
첫 번째 이유는 그다지 이유가 되지 않습니다. 작업량이 인간적으로 감당할 수 있고, 이 현실에서 작업이 가능한 한에서는요. 두 번째 이유는 MS나 Apple처럼 고객과 너무 많은 마찰을 원하지 않는 기업에는 좋은 이유가 될 수 있지만, 그 외의 경우에는 — 관리자이자 콘텐츠 제작자로서 저는 사용자에게 서비스를 제공해야지, 여기, 저기, 또는 다른 곳에서처럼 일관성을 유지하는 데 집중할 수는 없습니다 
그러므로 — 세 번째 옵션이 흥미로운 선택지입니다.
4개의 좋아요
둘 다입니다. 그리고 _관리자_의 복잡성을 줄여주기 때문이기도 합니다. 더 많은 옵션(그리고 원하는 설정을 찾아내기조차 못하는 기회)을 추가하는 대신, 한 발 물러나서 일반적인 패턴을 찾아내어 대부분의 경우에서 원하는 패턴이 _그냥 작동_하도록 만드는 것이 좋습니다.
7개의 좋아요
정말 강력한 주장이네요.
하지만, 또 다른 친숙한 해결책인 숨겨진 설정(hidden settings)을 사용할 수는 없을까요?
지금 두 가지 다른 전략을 보고 있습니다:
- 커뮤니티의 필요성은 플랫폼(즉, 코딩/개발 문제)에 의존하지 않고 다양하므로, 검색 결과와 같은 중요한 부분을 조정할 수 있도록 관리자에게 자유를 줘야 하는가?
- 아니면 관리자를 또 다른 사용자로 취급하여 UI를 깔끔하게 유지하고, 무엇이 어디에 왜 있는지를 CDCK가 결정하도록 해야 하는가?
#support를 양쪽 모두에서 살펴보면 각각 장단점이 있습니다. 하지만 여전히 첫 번째 방향은 오픈소스 세계의 특징에 더 가깝고, 후자는 애플의 방식입니다.
더 많은 옵션은 저처럼 숙련도가 높지 않은 관리자가 더 많은 질문과 문제를 만들게 합니다. 하지만 더 많은 옵션은 사용자와 방문자에게 더 나은 결과를 줄 수도 있습니다. 그래서 어떻게 하죠?
저에게는 이 질문이 매우 쉽습니다: 가능한 한 강력한 검색을 원합니다. 그리고 토픽을 닫으면 검색 결과에서 랭킹이 내려간다면, 저는 토픽을 더 이상 닫지 않거나 매우 드물게 닫게 될 것입니다. 쉬운 선택이지만, 그러면 저는 커뮤니티의 필요성이 아니라 소프트웨어의 한계 때문에 행동하게 됩니다.
그러므로 — 전략과 전술은 다른 것입니다.
4개의 좋아요
여기에는 다양한 설정 옵션(knobs)에 대한 선례가 많습니다. 모든 관리자가 설정할 수 있는 카테고리별 검색 우선순위가 이미 존재합니다.
저는 검색 결과에서 “아카이브됨/닫힘/해결됨” 상태가 어떻게 보너스(또는 페널티)를 받도록 할지에 대한 추가적인 설정 옵션에 대해 반대하지 않습니다.
이 주제는 약간 벗어난 이야기이므로, 어떤 설정이 합리적인지 명확한 제안과 함께 다른 토픽으로 분리하는 것을 권장합니다.
8개의 좋아요
지금까지 보여준 관심에 맞춰, 여기서 다음 단계가 무엇일지 고민해 보고 싶습니다.
현재 로직은 다음과 같습니다:
@sam의 언급:
여기서 엣지 케이스를 주목하세요!
메타 사이트에서는… #support::카테고리의 노이즈가 많기 때문에 이를 우선순위에서 밀어내려는 경향이 있습니다… 일단 우선순위가 낮아지면, 닫힌 상태 랭킹 보너스가 더 이상 적용되지 않습니다…
따라서 고려해야 할 또 다른 사항은 이것이 카테고리 가중치와 어떻게 상호작용하는지입니다.
반복적 접근 방식이 다음과 같을 수 있다고 생각합니다:
- 해결된 항목에 대한 케이스만 추가:
WHEN topics.solved then 1.1 - 아카이브, 닫힘, 해결 상태의 가중치를 **카테고리 가중치 및 서로의 곱셈 계수(multipliers)**로 변경.
- 아카이브, 닫힘, 해결 상태의 가중치 곱셈 계수를 사이트 설정을 통해 구성 가능하도록 함
이 모든 것을 한 번에 수행하는 것이 합리적일 수도 있습니다. 또는 (1)과 (2)를 먼저 수행한 후, 구성 가능하도록 만들기 전에 기다리는 것도 방법입니다. @sam, 어떻게 생각하시나요?
3개의 좋아요
승수(multiplier)를 사용하는 것은 일반적으로 좋은 접근 방식처럼 보이지만, 위에서 제안한 내용을 표현하기는 어렵다고 생각합니다.
closed not solved < open not solved < open solved < closed solved
닫힘(Closed) 상태는 해결된 게시물에 대해서는 우선순위 _상승_이 되어야 하지만, 해결되지 않은 게시물에 대해서는 _하락_이 되어야 합니다.
해결책 없이 닫힌 게시물은 거의 쓸모가 없습니다. 다른 사람이 같은 문제를 겪었지만, 여기에는 그 답이 없으며, 여러분도 답을 제공할 수 없기 때문입니다. 반면, 해결책이 있는 닫힌 게시물은 금과옥조와 같습니다. 단순히 해결된 것을 넘어, 명확하게 해결된 것이기 때문입니다.
4개의 좋아요
네, 그리고 아까 아카이브된 주제에 대해서도 언급하셨죠:
제가 제대로 이해했다면, 이렇게 순위를 매기길 원하시는 건가요?
(가장 높은 순위부터 낮은 순위까지)
- 닫힌 & 해결됨
- 열린 & 해결됨
- 열린 & 미해결
- 닫힌 & 미해결
- 아카이브 & 해결됨
- 아카이브 & 미해결
(그리고 카테고리별 순위라는 또 다른 복잡한 요인도 어떻게든 추가해야 합니다)
2개의 좋아요
네, 기본적으로 그렇습니다. 다만 아카이브된 게시물의 순서는 중요하지 않을 수 있습니다:
해결된 아카이브 게시물은 관련성이 낮을 수 있지만 역사적으로 흥미로울 수 있습니다. 해결되지 않은 아카이브 게시물도 기본적으로 마찬가지입니다 — 아카이브를 찾는다면 아마도 역사적 맥락 때문일 테니, 해결 여부는 정보이지만 그것이 중요하다면 쿼리에 명시적으로 포함해야 합니다.
2개의 좋아요
사용자님도 카테고리 가중치를 사용하고 계신가요? 그렇다면, 현재와 같은 상태 기반 가중치를 덮어쓰는 방식으로 적용해야 하는지, 아니면 곱셈 방식으로 적용해야 하는지에 대해 어떤 생각을 갖고 계신가요?
1개의 좋아요
특정 카테고리를 조회하는 스위치가 충분하다고 생각하며, 검색 시 그 가중치를 무시하는 것이 좋을 것 같습니다. (사람들은 카테고리가 아니라 솔루션을 검색하니까요.)
제 의견이지만, 여기서 하시는 작업에 전적으로 동의합니다 
2개의 좋아요
네, definitely 사용해야 합니다. 기본적으로 요청이 없으면 절대 등장하지 않아야 하는 “워크플로” 카테고리와, 더 중요도가 높은 공지 및 뉴스 카테고리가 있습니다.
이것은 제가 지금 바로 떠올린 아이디어이므로, 미래에 제 의견이 바뀌더라도 책임지지 않겠다는 권리를 주장합니다. 하지만 제 느낌으로는, 아카이브를 제외하고 카테고리 가중치가 모든 토픽 상태 가중치를 무시하도록 하는 것이 좋습니다. 여기서 뉴스 사례를 염두에 두고 있습니다. 뉴스는 신선할 때 검색 결과 상위에 표시되어야 하지만, 일정 시간이 지나면 전혀 표시되지 않아야 합니다. 그리고 게시물을 아카이브로 이동하는 것은 각 사이트가 그 "일정 시간"을 어떻게 정의할지 결정하는 방식이 될 수 있습니다.[1]
대안으로, 그리고 아마도 더 간단한 방법은: 카테고리 가중치가 우선하도록 하고, 카테고리별 옵션으로 "신선한 게시물 우선"을 도입하는 것입니다. 이 옵션이 체크되어 있으면, 시간이 지남에 따라 감소하는 곱셈 계수(예: 2배에서 0.5배로)를 적용하는 것입니다.
그리고 타이머 기반 자동 아카이브 기능 요청(RFE)도 여전히 남아 있지만, 세부 사항이죠! ↩︎
2개의 좋아요
좋아요, 제가 파악한 바로는 카테고리 가중치가 우선순위를 가져야 한다는 거네요.
해결됨/닫힘/아카이브 상태의 가중치는 여전히 해당 카테고리 _내부_에서 적용되어야 한다고 생각합니다.
아카이브 자동 타이머에 대한 말씀도 잘 들었습니다… 상호 보완적인 기능이지만, 그걸 쓰지 않고도 여기서 먼저 꽤 많은 성과를 낼 수 있다고 생각합니다.
1개의 좋아요
저는 이에 동의하지 않습니다. 주제에 좋은 답변이 있을 수 있지만, 작성자가 이를 해결책으로 표시하는 것을 게을리했거나, 오래된 주제라 해결책 표시 기능이 제공되지 않았을 수도 있기 때문입니다.
열려 있는 게시물은 뱀핑(bumping)할 수 있다는 장점이 있지만, 그 점을 지나치게 중시하진 말아야 한다고 생각합니다. 저는 키워드를 기준으로 더 관련성 높은 콘텐츠를 보고 싶습니다.
아카이브된 게시물에 대해서는 동의합니다. 저에게 이는 더 이상 관련성이 없는 콘텐츠이며, 가중치를 낮출 수 있습니다.
2개의 좋아요
그런 주제가 왜 닫히게 될까요? (그리고 선제적으로 말씀드리자면: "사이트 설정상 N일 후 주제가 닫히도록 되어 있다"는 주제가 닫힌 _방법_에 대한 답변이지, _이유_에 대한 답변은 아닙니다.)
3개의 좋아요
이 변경 사항을 관리 가능하게 유지하려면, 0단계는 자명(trivial)해야 합니다:
- 기본값이
true인 사이트 설정prioritize_solved_topics를 추가합니다. true로 설정되어 있을 때, 해결된(topics) 항목에 대해 무조건 1.1을 부여합니다.
이것은 여기의 모든 특이한 문제(quirks)를 해결하지는 않지만, 빠르게 상당한 진전을 가져다줄 것입니다.
문제는 확장성 관점에서 볼 때 이 변경 사항이 결코 쉽지 않다는 점입니다.
topics 테이블에는 “solved”(해결됨) 열이 없습니다. 우리가 여기서 할 수밖에 없는 일은 solved에서 topic custom fields로 어떤 종류의 join을 주입하는 것입니다… 이 의미는 이 SQL이 상당히 복잡한 방식으로 변환되어야 함을 뜻합니다:
아니면
-
solved 플러그인에
LEFT JOIN을 주입해야 합니다:LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
이 조건
CASE문장을 변환해야 합니다. 아마도 이는 플러그인을 사용하여 전체 CASE 문장을 구성 가능(composable)하게 만드는 것을 의미할 것입니다.
대안으로 CASE EXISTS(...) THEN 1.1과 같은 것으로 충분할 수 있으며, 이는 left join의 필요성을 제거하지만 자체적인 위험이 따릅니다.
이 문제에 대해 좀 더 생각해 보겠습니다. 여기서의 거대한 도전은 "core"가 해결된(topics)에 대해 아무것도 알지 못하는 상황에서 이 지원을 추가하면서 거대한 혼란(mess)을 만들지 않는 방법을 찾는 것입니다.
8개의 좋아요
@mcwumbly 실제로 작업을 하는 것이 작업을 스펙으로 정의하는 것보다 더 쉬운 경우 중 하나입니다.
다음과 같이 시도해 보았습니다:
7개의 좋아요
제 경우엔 거의 모든 작업이 그렇습니다! 코드가 제대로 작동한다고 확신할 수 있을 때까지 스펙을 제대로 파악하지 못하는 경우가 대부분입니다. 이는 (일부러) 내가 이해하지 못하는 스펙에 맞춰 코드를 작성하는 경우가 많기 때문이기도 합니다. 어른답게 스펙을 먼저 작성해 본 적도 몇 번 있지만, 그런 경우는 꽤 드뭅니다.
최소한 당신에게도 가끔 그런 일이 있다는 걸 알게 되어 기쁩니다. 
5개의 좋아요