나는 게시 전에 비공개로 게시하고 싶은 정교한 게시글의 초안 버퍼로 나에게 보내는 메시지를 사용합니다. (주된 이유는 미리보기 창이 게시된 글/메시지와 항상 동일하게 렌더링되지 않기 때문에 최종 형태를 확인하려면 게시해야 한다는 점입니다. 비공개로 게시하면 게시글이나 주제가 처음 게시된 후 이메일이 발송되기 전의 “편집 창” 시간 제한도 피할 수 있습니다.)
메시지의 본문을 포럼 게시글에 붙여넣으려 했을 때, “같은 내용으로 모두에게 스팸하지 마세요” "본문이 최근에 게시한 내용과 너무 유사합니다"라는 메시지가 표시되었습니다. 사용자가 메시지를 삭제할 수 있는 점을 고려하면, 이는 불필요한 검사인 것 같습니다. 또한, 누군가에게 메시지를 보낸 후 이를 회신 게시글로 전환하고 싶을 수도 있습니다(예를 들어, 검수를 요청한 경우 등).
나는 메시지를 주제의 첫 번째 게시글로 전환하는 것에 대해 이야기하는 것이 아닙니다. 나는 메시지를 기존 주제에 추가하는 것에 대해 이야기하는 것입니다. 저는 Discourse DB 구조와 게시글과 메시지가 얼마나 다른지에 대해 전혀 알지 못합니다. 메시지에서 ‘메시지’ 특성을 제거하고 주제로 꾸밀 수 있으므로, 유사한 과정을 통해 회신으로 전환하는 것도 가능할 것 같습니다.
최소한, 메시지 본문을 게시글에 재사용할 수 있기를 바랍니다.
여기에 우회 방법에 대한 언급이 있을 수 있지만, OP의 과정을 명확하게 파악하여 알 수 있을 정도로 해석하지 못했습니다.
discuss.python.org로 돌아왔을 때 타이머가 이미 만료되어 마지막 “메시지” 초안의 본문 게시가 가능했습니다. 첫 번째 중복 게시에서 발이 묶이지 않았더라면 이곳에 게시하지 않았을 것입니다. (이것이 어떻게 보면 ‘자기 꼬리를 물는 뱀’ 밈을 떠올리게 합니다. )
이것은 버그로 간주할 수 없다고 생각합니다. …
네, 어느 정도 중간 지점에 해당한다고 보입니다. 이 질문은 왜 다른 플랫폼 객체 유형에서 첫 번째 중복이 처음부터 차단되는지에 대한 것입니다. 이는 하나의 문제를 해결하기 위해 다른 문제(비록 더 경미한 문제이긴 하지만, 이 동작의 ‘기능’ 측면은 귀찮은 게시와 메시징에 대한 가드로서 순이익입니다)를 대가로 삼는 경우로 보입니다. 그럼에도 불구하고, 게시 본문과 메시지 본문은 범위가 매우 다르므로 이 둘을 비교하는 것은 부조화스럽고 따라서 적용할 수 없어 보입니다.
…그것은 올바르게 작동하는 것으로 보이기 때문입니다.
'올바르게 작동한다’를 "의도한 대로"로 정의하고, 이것이 설계 결정이지 누락이나 의도하지 않은 동작(둘 다 버그의 한 유형입니다)이라면 동의합니다. 기능(Features) 게시판(또는 다른 곳)에서 게시되거나 논의된 것을 보지 못했고, 기존에 최적이지 않은 동작에 대해 보고하기에 적절한 장소라고 생각했습니다.
수정 방법을 모르는 모든 버그가 기본적으로 "기능"이 되는 것처럼, 방해가 되는 모든 "기능"은 버그로 간주될 수 있습니다. unique posts mins가 만료될 때까지 기다리는 것조차 일종의 우회책입니다.
메시지 텍스트를 게시하기 위해 특별히 오래 기다릴 필요는 없었지만, 플로우에 하드 스톱(강제 중단)을 유발합니다. 아마도 메시지 내용을 토픽 답변으로 옮기려 시도한 첫 번째 사용자가 아닐까 싶습니다.
‘pm-as-draft-message’ 방식에 큰 팬이고, 저도 이런 경고 메시지를 여러 번 받아봤습니다. 아마도 기존 방식을 너무 그대로 받아들이고 있었던 것 같습니다. 이 워크플로우가 얼마나 인기 있는지 모르겠지만, 소수일 수도 있지만 Contribute > Feature 요청으로 만들어 볼 수 있을까요?
대안으로, 더 최소한의 규모로 Contribute > UX 접근법을 적용한다면, 경고 메시지에 더 많은 정보를 포함하는 것도 방법입니다 (예: “본문이 최근에 게시한 내용과 너무 유사합니다. %{unique posts mins} 후에 다시 시도해 주세요.”). 이렇게 하면 시간 기반의 제한이며 일시적인 조치임을 강조할 수 있을 것입니다 (다만, 원래 의도와는 반대로 작용할 수도 있겠네요).
이것이 곧 릴리스에 포함될 예정인가요? 저는 discuss.python.org에서 이곳보다 더 긴 답변을 작성하는 경향이 있습니다. 또한 토론이 기술적인 세부 사항에 관한 것이며, 테스트되지 않은 코드를 게시할 때 잘못된 설명이나 오타로 인한 실수가 발생할 가능성이 많기 때문에, 더 철저하게 교정하고 수정합니다.
)
기능(Features) 게시판(또는 다른 곳)에서 게시되거나 논의된 것을 보지 못했고, 기존에 최적이지 않은 동작에 대해 보고하기에 적절한 장소라고 생각했습니다.
