빈 게시글과 빈 주제 본문 허용

솔직히 저는 이해가 안 갑니다. 설명을 들어도 결국 내용이 없는 상태일 뿐이라는 점에서는 제 개인적인 의견일 뿐입니다. 만약 관리자가 그런 기능을 원하고 사용자들도 실제로 사용하고 있다면, 왜 설정에서 0을 승인하지 않는 걸까요?

여러 초안(multiple drafts)과 비슷한 구조적 문제로 인해 여러 번 요청되었음에도 아직 구현되지 않은 것과 같은 근본적인 이유가 있는 건지, 단순히 코드에서 값을 바꾸는 것보다 훨씬 복잡한 작업이 필요한 건지 묻고 싶습니다.

만약 막대한 작업량이 필요해서 사실상 불가능하다면, 그 상황은 더 납득할 수 있을 것 같습니다. 그리고 그 이후로 그런 포럼들이 도구 상자를 어지럽히거나 사용자가 작동하려면 트릭을 기억해야 하는 방법을 사용하기 시작할 수 있습니다. 이 두 경우 모두, 콘텐츠 자체에 손대지 않고 헤더만 쉽게 사용할 수 있다는 원래의 아이디어를 깨뜨립니다. 결국 이런 트릭들은 모두 임시방편일 뿐입니다.

하지만 그 이유가 정치적이나 전략적인 것이라면, 일부 포럼이 제목과 헤더를 이용해 대화를 진행한다고 해서 대형 기업들의 눈에서 Discourse가 ‘일회성 포럼 플랫폼’이라는 이미지에 대한 두려움이 정말로 위협이 되는 건지 묻고 싶습니다. 그렇다면 왜 위계(상징)나 GIF를 사용한 토론은 허용되는 걸까요? :smirking_face:

지금 상황은 그렇게 들립니다.

아, 좋은 지적이네요. 제 포럼에서 가끔 특정 문장이 어디서 왔는지 물어보는 경우가 있는데, 그러면 원본 게시글을 그대로 인용합니다. 그런데 Discourse가 최소 한 단어 이상을 추가해야 한다고 알려주면서 순수한 인용만으로는 게시할 수 없다고 하더라고요. 왜 그런지 정확히 이해가 안 됩니다.

3개의 좋아요

단순히 인용했다는 이유만으로 그 사람이 인용한 내용에 동의한다고 어떻게 알 수 있을까요? 이것이 일반적인 해석일 수는 있지만, 이런 식의 표현은 금방 오해되거나 아예 이해되지 않을 수 있습니다.

누군가가 아무런 코멘트 없이 메시지를 전달하고 싶을 때 이 기능 요청은 의미가 있을 수 있지만, 그것은 동의가 아니라 단순히 되풀이하는 것에 불과합니다.

2개의 좋아요

이것은 범위 밖의 문제라고 생각합니다. 이 기능 요청의 목적은 포럼 관리자가 자신의 포럼에서 길이 0인 게시글을 활성화할 수 있도록 자율성과 재량을 부여하는 것입니다.

추가로, 여기에 나열된 HTML 주석 방법을 사용해 보았지만, 모든 상황에서 항상 작동하지 않는 것 같습니다.

1개의 좋아요

어떤 식으로요? 언제 작동하지 않았나요? 제가 관리하는 포럼에서는 글자 수를 채우기 위해 가짜 HTML 블록을 자주 사용합니다. 보통 몇 글자만 부족할 때 사용하지만, 겉보기에는 비어 있는 것처럼 보이는 전체 게시글을 만든 적도 있습니다.

예를 들어, 제가 개인적으로 하는 방법
Some short post here

<e>
<Some filler content here>

위 코드의 결과는 다음과 같습니다:

내가 훨씬 더 쉽게 만들었어 :winking_face_with_tongue:

그 한도를 깨는 건 완전히 자명한 일이기 때문에, 그리고 핀란드어에서 '아니요’는 ei이기 때문에, 그리고 가끔은 완전히 유효한 답변(의미 없는 채우기용 쓸모없는 소소한 수다를 싫어하니까)이기 때문에, 두 글자 한도를 허용했어.

나는 바로 깨질 수 있는 규칙을 만드는 건 절대 의미가 없다고 생각해.

정말 멋지네요! 다만 개발자나 호스팅 제공업체는 조금 불안해할 것 같다는 생각이 듭니다. 기억이 맞다면, 사용자가 가능한 한 빠르게 게시글을 올림으로써 Discourse를 무너뜨리려는 게임을 진행했던 Discourse 사이트가 있었던 것 같습니다.

빈 주제 본문(empty topic bodies)을 허용해야 하는 또 다른 이유는 (아직 지원되지 않는) 문서화 주제에서 “빨간 링크(red link)” 또는 “요청 페이지 링크(wanted page links)” 개념을 도입할 수 있기 때문입니다. 예를 들어, [[this should be documented]]은 빈 주제 본문을 가진 https://forum.example.com/t/this-should-be-documented/{topic_id}로 링크될 수 있습니다.

이 둘은 모두 제 (비유적인) 할머니에게는 작동하지 않을 가능성이 높습니다. 메일링 리스트를 대체하는 디스코urses 카테고리에 접근하기 위해 제가 알려준 주소로 이메일을 보내는 작업은, IT 리터러시가 제한적인 사용자에게는 종종 꽤 어렵기 때문입니다. 그런 우회 방법은 갑자기 상황이 꽤 복잡해지고 (예: Incoming emails trimmed despite trimming disabled - #9 by sjjh), 사람들이 디스코urses 사용을 포기하고 "훨씬 더 쉽다"는 이유로 Facebook Messenger 같은 서비스로 돌아가게 만듭니다. 제 생각에는 이는 아쉬운 일입니다.

그리고 이것이 그렇지 않기를 희망/믿는 저로서는, 이 (관리자) 설정에 "0"을 포함하도록 허용하는 것에 대해 어떤 잠재적 해로움이 우려되는지 궁금합니다.

2개의 좋아요

(틀렸다면 지적해 주세요) 이것도 빈 메시지 전송이 안 되죠?

1개의 좋아요

솔직히 저는 개인적으로 사용하지 않아서 정확히 알지 못합니다. 하지만 Facebook Messenger는 Discourse보다 더 나쁜 대안에 대한 예시일 뿐입니다. 만약 이 예시가 맞지 않는다면, 다른 두 가지 예시를 제안해 보겠습니다.

  • Telegram, WhatsApp 또는 Discord로 대체 (짧은 문장, 즉 짧은 제목/주제 + 빈 본문/메시지를 허용)
  • TO와 CC 필드에 64개의 주소를 넣은 일반 이메일로 대체

또는 여러분이 원하는 것을 선택하셔도 됩니다. 제가 하고자 했던 메시지는 이렇습니다: 제안된 우회책은 문제를 해결하지 못합니다. 여기에는 Discourse에서 더 나쁜 대안으로 돌아가는 사용자들이 실제로 있습니다. 만약 이 (잘못된) 예시가 핵심 메시지에 대한 주의를 분산시켰다면 죄송합니다.

페이스북은 빈 게시글을 허용하지 않습니다. 하지만 텍스트일 필요는 없습니다. 미디어나 이모지 등을 사용해도 됩니다.

아마도 원인을 파악한 것 같습니다. 사실 HTML 주석에 대해 그렇게 익숙하지는 않았는데, 줄바꿈이 필요한 것 같습니다. 한 줄로 작성하면 작동하지 않는 것 같습니다.

하지만 여기 예시처럼 세 줄로 나누면 작동하는 것 같습니다. 줄바꿈이 중요하다는 점을 몰랐습니다.

즉, 이렇게 되어야 합니다;

<!-- 
foo
-->

이렇게 하면 안 됩니다

<!-- foo -->

전혀 빈 게시글의 의미를 전혀 모르겠어요. 화면 자원을 포함해 자원을 엄청나게 낭비하는 일이거든요. 활동적인 독자로 보이기 원하신다면, 그냥 반응(이모지)으로 참여를 표시하는 건 어떨까요?

다만, @David_Ghost님과 @Lhc_fl님의 의견에 동의합니다. 단순히 인용문만 게시할 수 있는 기능은 정말 좋은 아이디어라고 생각해요. 훨씬 더 합리적이죠! 누군가에게 특정 부분을 지적해 줄 때, admittedly 드물지만, 그런 상황에서 유용할 거예요.

7개의 좋아요

빈 주제 본문이 필요한 사용 사례 중 하나는 제목이 모든 정보를 전달하는 경우입니다. 예를 들어, 칸반 테마를 사용할 때 카드에 본문이 항상 필요하지는 않습니다.

2개의 좋아요

동의합니다. 우리도 이 기능이 필요합니다. 버튼이나 HTML 태그를 추가하는 것은 한 단계가 더 많아져 신규 사용자의 학습 곡선을 가팔라지게 합니다. 최소 글자 수를 1에서 0으로 변경하는 것이 더 나은 해결책이라고 생각합니다.

음, 이걸 달성하기 위한 또 다른 우회 방법은 "blank-topic"이나 “empty-post” 같은 감시 대상 문자열을 사용하고, 이를 &#32; (최소 글자 수에 따라 숫자를 조절)와 같은 주석이나 숨겨진 HTML 문자로 대체하는 것입니다. 예를 들어:

관리자-감시 대상 단어-대체:

감시 대상 문자열이 포함된 작성 화면:

최종적으로 생성된 주제 게시글:

2개의 좋아요

이것들이 셀프 호스팅된 환경이라면, could s 플러그인을 실행하여 빈 게시글을 허용하도록 오버라이드하고, 모든 카테고리에 적용할 수 있는 추가 옵션을 제공하는 것이 가능할지 궁금합니다. 이 옵션은 solved 플러그인과 유사하게 카테고리 설정에서 설정할 수 있기를 바랍니다.

이전 댓글 중에서는 이메일로 답글을 작성할 때, 기술에 익숙하지 않은 사용자(예: 할머니)가 게시글을 작성하는 상황을 언급하고 있습니다. 다만, 이는 수신 이메일로 생성되는 게시글이므로 추가적인 코드가 필요할지 확실하지는 않습니다.