meta.discourse.org에서 토픽을 ☑️ 해결됨, 완료됨 또는 수정됨으로 표시하는 방식이 일관되지 않음

이 멋진 온라인 포럼을 직접 개발한 제품으로 운영하고 정성껏 관리해 주시는 놀라운 Discourse 스태프 여러분께 인사드립니다.

Support 채널에서 ‘Solved’ 플러그인이 활성화되어 있는 것을 확인했습니다. 이러한 멋진 도그푸딩이 실제로 적용되고 있는 것을 보니 좋습니다! #fixed와 completed 태그 사용도 마찬가지입니다.

불행히도 Support, Contribute > Bug, Contribute > Feature, Contribute > UX 채널에는 이 태그들이 붙지 않은 주제(토픽)가 매우 많습니다. 이는 포럼 사용자들에게 상당한 혼란을 야기하고 기존 해결책을 효과적으로 검색하는 것을 방해합니다. 기본적으로 이러한 태그가 일관되게 사용되지 않을 것이라면, 아예 사용하지 않는 것이 낫습니다.

앞으로 이 문제가 우선순위로 다뤄지고, 누군가(인턴? AI?)가 과거의 게시물들을 올바르게 태그하도록 지시해 주실 수 있을까요?

10개의 좋아요

Thanks, Nathan! Appreciate you for bringing this up. :sunflower: We definitely want to be doing more in this department.

Looks like enabling solutions for the Support category has worked pretty well for that category. The fixed and completed tags are also quite helpful, which can be used in all categories.

3개의 좋아요

I don’t see the completed tag in Marketplace.

I believe that these are staff only.

Perhaps it would be helpful to expand this to trust_level_3? This might also help with Marketplace as per Jay’s point above.

2개의 좋아요

FWIW For Marketplace there’s delivered, which is not restricted to team.

4개의 좋아요

그 맥락을 공유해줘서 고마워요, 제임스! :hugs:

정리하자면, 현재 토픽이 그 역할을 다하고 마무리될 필요가 있다는 것을 표시하는 방법이 다섯 가지인 것 같습니다. 대략 이 정도를 담고 있나요?

항목 위치 담당자
:check_box_with_check: Discourse Solved Support #installation Development #data-reporting Support > SSO 토픽 소유자, @team, TL4
fixed Contribute > Bug Contribute > UX (모든 곳에서 작동) @team
completed Contribute > Feature Contribute > UX @team
delivered Marketplace 모든 멤버
:locked: 토픽 닫기 모든 곳 @team 및 자동 처리

저한테는 이 다양성이 너무 많은 것 같습니다. 태그들이 왜 다른지 모르겠어요. 아마도 사람들이 해당 태그 목록을 개별적으로 스크롤하며 볼 수 있는 것이 유용하거나 정보 전달에 도움이 될 수 있을 거예요. 하지만 이 태그들과 그 목적은 발견하기가 쉽지 않아요.

:check_box_with_check: solved(해결됨)은 쉽게 발견할 수 있고 지원 영역에서 꽤 잘 작동합니다. 해당 범주로 제한하는 것이 합리적이라고 생각합니다. 해당 범위에서 해결됨/미해결 토픽으로 필터링할 수 있다는 것이 도움이 되죠 - 저는 그 드롭다운을 자주 잊어버려서 UI에서 더 쉽게 발견할 수 있으면 좋겠다고 생각해요. :blush:

#fixed는 Contribute > Bug #contribute:ux에서만 사용되며, 버그나 UX 버그가 수정되었음을 의미합니다.

#completed는 Support Contribute > Feature #contribute:ux에서도 사용됩니다. #contribute:ux는 UX 토픽이 종종 기능 요청이기도 하기 때문이죠. 한 토픽, "Reader Mode" theme component feedback, 은 #contribute:site-feedback에 있었지만, 이제 컴포넌트가 출시되었으니 #customization:theme-component에 속하는 것이 맞다고 생각하여 그곳으로 이동시켰습니다.

#delivered는 #marketplace에서만 사용됩니다.

토픽이 :locked: 닫히는 이유는 다양합니다:

  • Support 토픽은 해결된 후 마지막 답변으로부터 한 달이 지나면 닫힙니다.
  • Marketplace 토픽은 delivered 상태와 무관하게 마지막 답변으로부터 한 달이 지나면 닫힙니다.
  • 모더레이터가 토픽을 닫습니다.
    • 해결되었을 때
    • 답변을 방지하기 위해 (예: 문서나 release-notes)
    • 생산성이 떨어지거나 그 역할을 다한 토픽의 논의를 끝내기 위한 모더레이션 전략으로

가능한 다음 단계들:

  • fixed completed delivered 태그에 우리가 어떻게 사용하는지 설명하는 설명을 추가하기
  • 위 표와 같은 결과를 제공하지만, 해결됨/미해결, 수정됨/미수정, 완료됨/미완료, 전달됨/미전달된 실제 최신 토픽 수를 나열하는 데이터 탐색기 쿼리 생성
  • 특정 기간 내에 닫히거나, 수정되거나, 완료되거나, 전달된 토픽을 나열하는 데이터 탐색기 쿼리 생성
  • 자동화를 사용하여 위 쿼리의 결과를 매주 공유하기 위해 #contribute:site-feedback에 토픽 생성
  • 토픽 마무리를 위한 간단한 가이드를 담은 토픽을 여기에 생성하고, 팀을 구성하여 시간 역순으로 목록을 처리하기 시작하기
4개의 좋아요

아래와 같이 설명을 추가했습니다. 마우스를 태그 위에 올리거나 태그 페이지로 이동할 때 표시되도록 했습니다. 제안 사항이 있으면 알려주세요. 짧고 간결하게 유지할지, 더 자세한 맥락을 제공할지 고민 중입니다. 카테고리 자체에도 더 자세한 설명이 있습니다.

fixed

Contribute > BugContribute > UX 카테고리에 보고된 소프트웨어 버그 수정을 우선시합니다. 버그가 수정되면 이 태그가 부여됩니다.

completed

Contribute > FeatureContribute > UX 카테고리에 제안된 기능이 구현되면 이 태그가 부여됩니다.

delivered

#marketplace의 토픽이 공급자 또는 수신자에 의해 전달 완료로 확인되면 이 태그가 부여됩니다.

3개의 좋아요

아, 그걸 그렇게 복잡하게 들리게 만들었군요. :slight_smile:

원칙적으로, 수정된 버그에는 fixed 태그를, 구현된 기능 요청에는 completed 태그를 붙입니다. [1] 이는 토픽을 정리하고 마감하는 과정의 일부이며(관련된 정보를 관심 있는 사람들에게 업데이트하기 위함) 처음에는 '좋은 일이 발생했다’는 시각적 표시를 제공하기 위해 도입되었습니다. 이는 닫힌 토픽의 잠금 아이콘과 대비되는 것이죠. 이러한 태그가 일관되게 적용되면 해당 카테고리의 토픽 목록을 아래로 스크롤할 때 멋진 초록빛 물결을 볼 수 있습니다.

(그리고 #delivered는 팀이 직접 관리하지 않아 #marketplace에서도 사용할 수 있었던 별개이지만 유사한 태그였습니다)

Solved의 경우, 일반적인 Support 카테고리 외에도 활성화되어 있는 카테고리가 꽤 많습니다. 대다수의 토픽이 해결 가능한 질문으로 구성되는 거의 모든 카테고리가 해당됩니다. Support, #installation, Development, #data-reporting, Support > SSO

이상적으로는, 토픽을 만든 사용자가(OP) 해결책을 표시하는 것이 최선이지만, 이것이 항상 일어나지 않음을 알고 있습니다(여러 가지 이유로 인해) 그래서 저는 보통 몇 주 정도 지난 후(토픽이 ‘방치된’ 것으로 판단될 때) 토픽 목록을 뒤로 스크롤하여 미처리된 것들을 정리하곤 했습니다.

참고로, 해당 토픽의 Customization > Theme component 주제는 Reader Mode 이므로, 실제로는 링크하신 그 feedback 토픽은 #customization:theme-component에 있어서는 안 됩니다(테마 컴포넌트 토픽이 아니기 때문이죠). 이제 더 많은此类 토픽들이 그곳에 존재하기 때문에 Contribute > Feature 또는 #contribute:ux에 있는 것이 더 적절할 것 같습니다.

(메타 사이트에서 실험이었던 것 같아서 #contribute:site-feedback에 있었다고 생각합니다)


  1. 그리고 #contribute:ux는 둘 사이의 중간 지점이라, 특정 토픽의 '성격’에 따라 둘 중 하나를 사용할 수 있습니다 ↩︎

8개의 좋아요

멋지네요! 거기서 몇 가지 공백을 채워주셔서 감사합니다. 위의 표를 업데이트했습니다.

당신이 떠난 이후로 체계적으로 그런 작업이 이루어지지 않아서, 이제 뒤처지지 않도록 시스템을 마련하고 상황을 정리해야 한다는 이야기를 나누는 이 토픽이 생긴 것입니다.

좋은 지적입니다! #contribute:feature로 이동했습니다.

1개의 좋아요

Yup, I guess that is what I was angling at with the OP. @JammyDodger - we miss you and your dedication to keeping Meta going so smoothly! Personally, I hope they make you an offer you can’t refuse…

6개의 좋아요

최근 #contribute:feature에서 completed 태그가 붙어야 한다고 생각했지만 실제로는 붙지 않은 토픽을 신고했다가 주의 조치를 받았기 때문에, 이 토픽에 다시 돌아왔습니다.

원래 제가 하고 싶었던 것은 단순히 그 태그를 직접 붙이는 것이었습니다. 하지만 해당 태그는 @staff만 사용할 수 있는 제한이 있어 제가 붙일 수 없었습니다. 제발, TL4 권한으로 잠재적으로 파괴적인 일들을 많이 할 수 있지만, 딱 이 일만 못 하네요. 심지어 Customization > Plugin 같은 일부 카테고리에서는 태그를 아예 수정할 수도 없습니다.

그렇다면 이런 사소한 문제들을 관리자에게 신고할 때, 귀찮은 존재가 되거나 나무람을 듣지 않고 어떻게 해야 할까요? 아니면 그냥 이 정도는 어수선하게 두는 걸로 계획이 잡혀 있는 건가요?

6개의 좋아요

I think its okay to flag the topic as something else and say you think it should be marked completed/fixed, at least for “old” topics (as in: has been completed/fixed 6 months ago but topic hasn’t been updated).

(Eventho others disagree with that)

For acute things: it would be good practice for our staff to make sure they followup on things they fix.

6개의 좋아요

I think that if we get flags to tag each completed feature from the last 13 years this forum has been active because people have OCD, it would be a big waste of time for everyone.

The tag itself is newish, never widely adopted, and we could simply close topics for completed features, allowing everyone to create new topics and quote old ones as necessary.

I’d rather remove the completed flag. It was applied 400 times and was only created as a way to help people write changelogs, who are dealt with differently nowadays.

6개의 좋아요

이것이 그 이유라고는 확신하지 못하겠습니다. 처음에는 완료된 기능 요청(feature requests)을 나머지 폐쇄된 주제들과 시각적으로 구분하기 위해 구현되었습니다. 검색을 하시면 저와 Sam, Dave 사이에 더 자세한 정보가 담긴 대화가 어딘가에 있을 것입니다. (어떤 속삭임(whispers) 섹션이었던 것 같은데, 정확히 어디였는지 기억이 나지 않습니다.)

개인적으로는 당시 그 작업을 꾸준히 관리하는 것이 특별히 부담스럽지 않았습니다. :person_shrugging: 다만 /latest 상단의 주제들이 더 일관되도록 유지하기 위해 ‘활성(active)’ 창에 더 집중하긴 했지만, 제 눈에 들어오는 다른 주제들(관련 주제 등)도 함께 관리했습니다. Contribute > Feature 카테고리의 전체 감사(audit)를 수행하는 것은 확실히 훨씬 더 큰 작업이 될 것입니다. :slight_smile: (몇 년간 놓친 것들을 정리/병합/폐쇄하는 데 유용할 수 있다는 뜻은 아니지만, 시간이 많이 소요될 것이며 우선순위 목록에서 어디에 위치하는지 신중하게 고려해야 한다는 뜻입니다.)

이는 발생할 수 있는 것에 대한 우려인가요, 아니면 실제로 이미 일어나고 있는 일인가요? 가끔 일어나는 것이라면 큰 문제가 되지 않을 것 같지만, 이것이 패턴이 된다면 플래그 시스템이 이를 위한 최선의 장소가 아니라고 동의합니다. 정보를 수집하는 덜 간섭적인 방식은 개인 메시지(PM)라고 생각합니다.

하지만 개발자와 디자이너 등이 메타(meta) 작업을 정리하는 데 너무 깊이 빠져들기를 원하지 않는다는 점도 이해합니다. 그들은 중요한 다른 업무를 해야 하니까요. :heart:

4개의 좋아요

Maybe stuff that requires a moderator, but is not urgent, could be reported via PMs to a separate group inbox. Then such tidy-up records would not flood the review queue, hiding topics where someone needs to act soon, but there would still be a place to collect those, so someone could take care of them if they have a few minutes.

This could work for all kinds of side notes, like a missing tag, a broken preview link in a theme component topic, or a feature topic that could be closed, so votes are returned to users.

6개의 좋아요

Oh! I am just realizing the moderators group has nobody in it! Now I understand why a PM I wrote to @moderators a couple weeks ago never got a response.. :sad_but_relieved_face:

I had created that as part of my idea to have a softer, gentler approach to moderation here. It’s important to have a single point of contact where you can reach a moderator and know you’re going to get a response. I hope the decision to remove that is reconsidered.

Also as part of trying to be kinder, gentler, I tried my best to avoid using “time wasting” as a reason for moderator decisions. I don’t think well intentioned community leaders who are trying to help keep discussions tidy should be made to feel bad about that.

Returning to the OP… I had a regular todo to review and clean up older topics, and it was a good manual task because there were often loose ends I was able to tie up along the way. Sometimes topics could just be deleted or they could be merged etc. But it is a gargantuan task and I only made it back a few years.

I’d be in favor of allowing trusted veterans like @nathank to add the tags rather than making them flag the topics for review by staff, especially right now when there is no community manager or devoted moderation team.

Edit: still have the links in my sidebar! This was to see topics that are open, unsolved, and over a week old. Still find these links helpful to see how well we are doing at getting topics resolved. Maybe more of us could help out with this if staff don’t have time to do it.

5개의 좋아요

We’re in a bit of a transition period here when it comes to moderations, so some of the decisions we make in this very moment may not be durable, but here are my 2 cents on this particular subject:

I think we should aim to get to a place where:

  • Flags are used for more important things
  • We have a way to handle other things that are more trivial, or for general gardening

If we want to use completed, then we should empower a group of folks to handle that without using flags. Perhaps:

  • Grant TL3 and TL4 the power to tag things as such
  • Create a “gardening” topic where people can make suggestions for any kind of content gardening
4개의 좋아요

I really appreciate that. Since you can only report a post once and never again, I was always reluctant to use flags for trivial problems, such as a preview link in a theme component topic that no longer works.

I suggested the inbox because I thought archiving handled requests might help keep track of what has already been resolved. This could be more difficult in a topic with lots of replies.

I am not sure how helpful it is to add the completed or fixed tag but not being able to close the topic. If someone else is still needed to close the topic, this doesn’t help much.

6개의 좋아요

We were looking at automations to close topics with those tags - not sure how hard it would be to bring those experiments across the finish line.

3개의 좋아요

Offering my views on this.

I read every post every day. Really. My last unseen post was in June 2024. As such, I have seen countless bug/ux reports being fixed or completed. Generally, I would just flag them to be closed. Less so do I see the need for the fixed or completed tags, but just a closing of the topic. IMO that alone signifies that thr topic has been resolved.

On the other hand, I also agree with this:

So if

was done, paired with

, I think that would be quite complete.

3개의 좋아요