위키백과:주석/부분 블록 요청

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

필요한 경우 후속 RfC를 개최하여 차단 정책이 이미 블록에 부과하고 있는 블록 이외의 부분 블록 사용에 제한을 가해야 하는지 여부를 결정할 수 있다.

지원

1. 정책 개발을 위한 Follow up Rfollow up RfC.부분 블록은 툴박스에 추가하는 데 유용한 도구가 될 것 같아.아래에 가능한 사용 사례 몇 가지를 #사용 가능한 사용 사례에 나열해 놓았다.나는 가장 효과적인 사용 사례는 편집 전쟁에 대항하는 것이라고 생각한다.현재 전쟁 중인 관리자의 편집을 중지하려면 편집자를 완전히 차단하거나 모든 편집으로부터 해당 기사를 완전히 보호할 수 있다.이 두 가지 모두 차단으로 인해 편집자가 토론에 참여할 수 없고(편집과 전쟁으로 인해 우리가 권장하고 싶은 것임) 페이지 보호가 기사의 모든 개발을 완전히 중단하기 때문에 실무적으로 구현하기 어렵다.부분 블록은 WP가 적을 것이다.편집자들이 대화 페이지에서 그 변화를 논의하도록 강요하는 것과 같은 예방적 목표를 달성하는 물티와 가혹한 제재.
   나는 또한 다른 가능한 사용 사례들이 장점이 있다고 생각한다.과거에도 특정 IP 주소나 IP 범위를 부분적으로 차단할 수 있었으면 좋겠다는 생각이 들었던 경우가 몇 번 있었는데, 공공 기물 파손에 대한 매우 구체적인 기사를 겨냥하고 있었기 때문에 전체 범위를 통째로 차단하는 것은 너무 많은 부수적 피해를 의미했을 것이다.이것의 예는 다음과 같은 IP가 있는 자이언트 타이거 기사에 있었다: 스페셜:기여/1999.198.223.109.이 편집자는 주제와 무관한 기사에 관계없는 사람의 이름을 삽입하고 있었다.그러나 그것은 한달에 한 번 정도밖에 하지 않았고 IP 주소는 관련 없는 사용자들 사이에 공유된다.공공 기물 파손은 다른 기사로 확산될 것 같지 않은 방식으로 이 기사의 표적이 되기도 했다.기사에 대한 무기한 반보호(실행한 해결책)에 대한 대안으로, 본 기사에 관해서 IP주소에 대해 긴 부분차단을 실시하는 것이 유용했을 것이라고 생각한다.
   후속 RfC를 개최하여 이를 어떻게 이행할 것인지에 대해 논의하는 것이 유용할 것 같다.예를 들어, 나는 편집 전쟁만을 위한 구현에 반대하지 않을 것이다.Mz7 (대화) 05:45, 2019년 12월 12일 (UTC)[응답]

   편집: 나는 다른 쪽의 동료들로부터 후속 RfC가 유용할 뿐만 아니라 계획 없이 이 일에 뛰어들지 않기 위해 필요하다고 확신해왔다.위에 있는 나의 대담함에 이것을 추가했다.시험 단계에 대한 아이디어는 합리적인 이행 단계로 들리지만, 이번 RfC에서 섣불리 뛰어들지 말고 후속 RfC에서 논의해야 한다고 생각한다.Mz7 (대화) 22:23, 2019년 12월 12일 (UTC)[응답]

   Mz7, 이번 RfC는 후속 RfC보다 참석률이 더 좋을 것 같아.따라서, 우리가 이 RfC의 1일차(그리고 내가 RfC의 전체 길이를 논의하기 위해 RfC를 연 지 2분 후에 그것을 띄운 것처럼)에 대해 생각해 볼 때, 지금이 지역사회가 실험이 가치 있다고 느끼는지 확인할 수 있는 가장 좋은 시간이 될 것이다.나는 분명히 한다.만약 공동체의 대부분이 그렇지 않다면, 충분히 공평하지만, 나는 우리가 여기서 그 관점에 대해 합의를 볼 수 있고 그것에 대해 논할 필요가 없다고 생각한다.Best, Barkeep49 (대화) 22:28, 2019년 12월 12일 (UTC)[응답]

2. 지원 관리자의 도구 상자는 확실히 더 정밀한 도구를 사용할 수 있으며, 이를 통해 작업 중단을 줄이고, BITY 작업을 줄일 수 있다.그것은 또한 사회로부터 제한을 금지하는 주제 관료주의의 일부를 빼앗을 것이다.나는 이것이 바킵의 제안에 따라 재판되어야 한다고 생각한다.이것이 통과되면, 구체적인 사항을 파악하기 위한 RfC가 즉시 따라야 하며, 시스템이 구현되기 전에 본 코스를 실행할 수 있어야 한다.분명히, 이것을 작동시키려면 새로운 시스템과 정책이 시행되어야 할 것이다.캡틴 에케^{Edits Ho Cap'n!} 06:33, 2019년 12월 12일 (UTC)[응답]

   카테고리 블록이 논의되고 있지 않기 때문에 실제로 이것을 통해 토픽 금지가 시행될 수 없었고, 만약 그렇다면, 카테고리를 추가하는 것만으로 비관리자들에게 효과적으로 차단할 수 있는 권리를 줄 것이기 때문에 그들은 반대할 것이다.실마리를 찾아야겠지만 어느 순간 이 문제를 연구하고 있는 WMF 팀조차 다양한 이유로 주제 금지 시행에 유용하지 않을 것이라고 말한 것으로 알고 있다.토니발리오니 (토크) 06:44, 2019년 12월 12일 (UTC)[응답]

   아, 지적해줘서 고마워.나는 단어 선택에 신중하지 못했다. 편집 제한은 내 말의 더 정확한 정의다.캡틴^{Edits Ho Cap'n!} 에케 07:09, 2019년 12월 12일 (UTC)[응답]

   @대장Eek와 TonyBallioni: 반면에 페이지반은 이것으로 강제할 수 있다.그냥 밖으로 던져버리고 싶었어. –MJL ▲^☖토크 13:26, 2019년 12월 12일 (UTC)[응답]

   그렇다, 왜냐하면 실질적인 검토 수단 없이 페이지로부터 사람들을 금지시키는 완화되지 않은 능력을 관리자에게 주는 것은 어떤 면에서는 좋은 것이기 때문이다...토니발리오니 (토크) 13:39, 2019년 12월 12일 (UTC)[응답]

   사용자가 WP에 직접 어필할 수 있기 때문에 논쟁의 여지가 없이 페이지 블록은 서약 블록보다 검토하기 쉬울 것이다.AN. –MJL ※Talk ^☖– 14:18, 2019년 12월 12일(UTC)[응답]

3. 지지하다.나는 이것이 붕괴에 대처하기 위해 이용할 수 있는 조치의 범위를 더하고 있다고 생각한다.다소 덜 엄격한 조치를 취함으로써, 완전한 사이트 블록과 관련된 많은 긴장 + 낭비된 시간(항소, 신랄함, 지속적인 쓰라림 등)을 줄일 수 있다.나는 그것이 또한 편집자들이 특정한 논쟁을 해결하도록 격려하고, 편집자들이 활동적인 상태에서 백과사전의 다른 영역에서 그들의 가치를 증명할 수 있는 더 많은 시간을 제공하고, 열성적이긴 하지만 잘못된 편집자들을 유지함으로써 우리의 편집자 집단을 확장하고, 또한 좀 더 엄격한 접근법을 허용하고, 이것은 또한 더 많은 nua를 추진하는데 도움을 줄 수 있기를 바란다.문제 처리에 대한 nced 접근법(전부 또는 무차단보다 중요함).강력한 지지. --Tom (LT) (토크) 07:26, 2019년 12월 12일 (UTC)[응답]

   덧붙이자면. 이것을 어떻게 실행할 것인가를 생각해내면서 들끓는 문제들("양극적인 악몽")이 있을 것이라는 데는 동의하지만, 장단기적으로 우리가 이것을 어떻게 사용할 것인가를 알아내야 하는 불편함을 훨씬 능가한다고 생각한다.--톰 (LT) 07:28, 2019년 12월 12일 (UTC)[응답]

4. 서브캣 그룹 내의 IP 범위에 대해 사용할 수 있는 경우 Esp.나는 편집자가 스토킹하는 것에 시달렸고, 일단 차단되면 그들은 블록을 무시하고 IP 편집에 들어갔다.슬프게도, 그들은 몇 시간마다 IP 홉을 한다.IP 범위가 너무 커서 서구의 절반을 차단할 수 있다.그러나, 그것은 편집의 상당히 틈새적인 영역이고, 범주 레벨에서 범위를 블록하면 이것을 단번에 해결할 수 있을 것이다.러그넛 09:24, 2019년 12월 12일 (UTC)[응답]
5. RfC 형식의 시험 및 절차상 실패만 지원 - 시험 기간이 모두 필요하며, 종료 시 자동 되돌리기가 필요함(시험이 유지되려면 새로운 합의를 도출해야 함).또한 인가된 사용 사례/대상 그룹에 대한 합의와 함께 후속 RFC가 필요하다.툴킷을 추가하지만 문제점도 추가한다.전자가 후자를 능가해야 한다.노즈백베어(토크) 10:02, 2019년 12월 12일 (UTC) (추가) - 여전히 시연이 필요하며, 구체적인 사용 사례 옵션은 일반적인 예/아니오 RfC를 통해 파트웨이 방식으로 추가되어야 한다.노즈백베어(토크) 18:22, 2019년 12월 26일 (UTC) 응답으로 시작하려고 놀지 않은 것에 동의하는 것처럼 보일 수 있기 때문에 파트 1의 모든 참가자가 검토했다고 보장되지 않는 한 다른 옵션은 취소되어야 한다고 생각한다.
6. 무조건 지지하다.이 도구들은 특정한 필요를 충족시키기 위해 세심하게 설계되었다.만약 그들이 실화한다면, 그들의 사용은 축소될 수 있다.우리는 명백한 필요를 충족시키는 새로운 옵션에 대한 최악의 시나리오를 상정할 필요가 없다.EllenCT (대화) 10:23, 2019년 12월 12일 (UTC)[응답]
7. 구현에 대한 3개월 평가(특정 사용 사례/대상 그룹 이상 없음)를 지원한다.첫번째로 주목할 것은 많은 다른 위키피디아들도 이것을 실행했고, 나는 그들이 여기저기서 바리케이드를 쳤을 것이라고 확신하지만, 영구히 그것을 제거하려는 크로스위키 노력을 유발할 만큼 나쁜 것은 아무것도 없다는 것이다. 그래서 나는 이 아이디어가 상당한 잠재력을 가지고 있다고 생각하게 된다.이 도구는 단순히 금지를 고수할 수 없는 편집자들에게 가장 효과적이며, 그들의 문제 영역을 건드리지 않는 기술적 능력을 제거하는 것이 상당히 좋은 해결책이며, 현재의 해결책은 선택권을 가지고 있으며, 계속해서 같은 결과를 초래하지 않기를 바라는 것이 좋다. --qedk (t 桜 c) 11:38, 2019년 12월 12일. --qedk (t 桜 c) 11:38, 2019년 12월 12월 12일.(UTC)[응답하라]

   나는 사실 주제 금지를 시행하는 잠재적인 사용 사례를 약간 경계하고 있으며, 여기서 논의하게 되어 기쁘다.기술적 관점에서, 도구의 한계로 인해, 우리는 특정 페이지의 편집자만 부분적으로 차단할 수 있다. 예를 들어, 모든 BLP에 대해 주제 금지를 시행하기 위해 부분 블록을 사용하는 것은 실행 불가능할 것이다.기술적인 문제는 제쳐두고, 주제 금지 위반에 대한 대응으로 사이트 블록의 대체물로 부분 블록을 제시하지 않도록 주의해야 한다고 생각한다.만약 편집자가 명백하게 정해진 주제 금지를 위반한다면, 나는 관리자에게 부분 차단이 아닌 사용자를 사이트 차단을 하도록 권하고 싶다.이것에 대한 주요 논거는 신뢰 문제다: 만약 당신이 명백하게 확립된 주제 금지의 조건을 무시하기로 결정한다면, 우리는 정말로 당신이 위키백과의 어떤 사회적 규범의 조건(즉, 우리의 정책과 지침)을 존중할 수 있다고 믿을 수 있는가?사이트 블록은 또한 더 나은 억제책(c.f. WP:BLOCKDESTRENT)으로 작용할 수 있다. 편집자들이 부분 블록이나 주제 금지 위반에 대한 경고만으로 제재를 받는다는 것을 알고 있다면, 그들은 주제 금지를 위반하는 경향이 더 높아질 수 있다.Mz7 (대화) 12:11, 2019년 12월 12일 (UTC)[응답]

   포용적 주제 금지는 실현 불가능할 수 있지만, 페이지 금지는 침해 주제 금지에 대한 대응으로서 일부 금지 시행은 괜찮고, 다중 제재는 어쨌든 현장 반장으로 이어질 것이다. --qedk (t t c) 14:25, 2019년 12월 12일 (UTC)[응답]

8. 예약되지 않은 지원.이것은 사실상 신의 선물이다.스코트 위키피디아는 이미 그것을 시행하고 있다.멋진 일이다. –MJL ▲^☖토크 13:24, 2019년 12월 12일 (UTC)[응답]
9. 지원 및 장기 연체.편집자를 부분적으로 차단하는 능력은 주제 금지와 상호 작용 금지와 같은 부분적인 금지를 시행하는 필요하고 유용한 방법이다.몇 가지 기술적 개선을 생각할 수도 있지만, 그것은 실행 후 과정이고 나는 이 개념을 실행에 옮기는 것을 전적으로 지지한다. --Jayron32 14:24, 2019년 12월 12일 (UTC)[응답]
10. 지원 아이디어는 마음에 들지만 툴이 일반 툴박스에 들어가기 전에 해결해야 할 몇 가지 문제(사용 시기, 편집 제한사항 교체 등)가 있다.일단 툴이 활성화되면 모든 현재 편집 제한사항이 자동 또는 로봇적으로 변환되어야 한다고 생각하지 않는다.편집자가 현재의 편집 제한을 변환해야 한다고 생각한다면, 변환에 대한 합의가 있는지 여부를 결정하기 위한 논의가 이루어져야 한다.호서 (대화) 15:04, 2019년 12월 12일 (UTC)[응답]

    나는 사후적으로 그 도구를 사용하지 않는 것에 대한 Rushur의 지적에 동의한다.기존 제한사항에 페이지 블록이나 네임스페이스 블록을 추가하는 것은, 우리가 광범위하게 사용을 허용하기로 결정했더라도, 사례별로 명시적으로 허가될 필요가 있을 것이다. --Jayron32 15:06, 2019년 12월 12일 (UTC)[응답]

11. 지원 공구 키트에 공구가 하나 더 추가되어 항상 좋다.나는 이것이 지역사회가 더 나은 느낌을 갖게 되면 적절한 정책을 수립하기 위해 중앙집중식 토론에 이어 일종의 시범 운영이 필요하다는 것에 동의한다.2604:2000:8FC0:4:617F:E9A7:AF1C:4546 (대화) 16:03, 2019년 12월 12일 (UTC)[응답]
12. 지원 WRT 익명 편집자들이 겪고 있는 지속 불가능하고 악화되는 문제에서 궁극적으로 벗어날 수 있는 유일한 방법인 등록이 필요한 시점까지, 이것은 좋은 임시 패치다.그것은 또한 필수 등록이 궁극적으로 시행된 후에도 유용할 것이다.-Jordgette [대화] 19:02, 2019년 12월 12일 (UTC)[응답]
13. 재판 지원.이 새로운 도구는 이론적 이점이 분명하며, 특히 잠재력을 최대한 발휘할 때(WMF가 그렇게 할 수 있도록 행운을 빈다)에는 더욱 그러하다.하지만 우선 어떻게 사용할지, 그러니까 재판 기간이 얼마인지 알아내야 해. MER-C 19:15, 2019년 12월 12일(UTC)[응답]
14. 서포타 재판, 6개월 정도라고 합시다.나는 이것이 유용하다는 것을 알 수 있었다.우리는 부분 블록에 적용되는 구체적인 정책뿐만 아니라 rfc가 필요할 것이다.SQL^{Query me!} 19:43, 2019년 12월 12일 (UTC)[응답]

    몇몇 거친 정책 논의와 마찬가지로, 아래에서 재판에 대한 토론이 열렸다.정기적인 지원으로 변경됨.SQL^{Query me!} 18:02, 2019년 12월 15일 (UTC)[응답]

15. 관련 정책을 결정하는 Follow up RfC와 함께 위와 같은 지원. -FASTY 20:20, 2019년 12월 12일(UTC)[응답]
16. 지원 사이트 전체 블록과 무차단 블록 사이에 무언가가 필요하다.사이트 전체 블록이 항상 최적의 해결책인 것은 아니며, 보다 덜 제한적인 것은 없기 때문에만 사용된다.부분 블록은 분명히 누락된 옵션을 제공하는 데 도움이 될 것이다.–암마르패드 (대화) 23:12, 2019년 12월 12일 (UTC)[응답]
17. 조건부 지원, 대부분 편집 전쟁 이슈에 공감한다.본 RfC의 제안을 수용하기로 합의하는 경우, 후속 워크숍/토론 RfC 단계를 실시하여 부분 블록의 한계를 결정해야 한다.그런 다음 다른 사람이 제안한 대로 시험 기간 동안 부분 블록을 구현해야 한다.NonymousUser (talk) 04:33, 2019년 12월 13일 (UTC)[응답]
18. 지지, 거의 모든 제안된 이유들 때문에.나는 오랫동안 우리가 이것을 할 수 있는 기술적 능력이 생긴다면 이것이 필요하다고 생각했다.우리는 엄청난 WP를 가지고 있다.블록을 둘러싼 드라마 문제, 그리고 그것은 우리에게 너무 많은 생산성이 필요하다: 생산적인 편집자들이 프로젝트에서 어느 곳에서도 전혀 유용할 수 없다는 것을 의미하지 않는 고도로 국지적인 논쟁에서 선을 넘었다는 이유만으로 기여하는 능력을 부정한다는 의미에서; 그리고 지역사회가 항상 그렇다는 의미에서.블록과 그 결과에 대한 손 쓸기를 방지한다. 그리고 종종 많은 WP 라운드에서 중단이 계속되도록 허용된다.드라마라는 것은 대부분의 사람들이 관심을 갖지 않는 주제로 지역화되어 있기 때문에 우리는 다른 곳에서 기고자의 의견을 잃고 싶지 않다.둘째로, 우리가 지역적인 문제를 다루기 위해 엄청난 범위의 IP 주소를 완전히 차단하고 있다는 사실이 나를 미치게 한다.때로는 편집 가능한 VPN 끝점을 찾기 전에 12개의 VPN 끝점을 시도해야 할 때도 있다.모바일 기기를 통해 원격으로 편집하고 도서관이나 카페 와이파이를 거닐 때도 마찬가지다.그리고, 그렇다, 우리의 현재 토픽 배닝 시스템은 다소 익살스럽고, 단지 또 다른 드라마 공장이다; 지역사회가 T-Ban을 위반했다는 이유로 그들을 다시 상대해야 하는 수천 번인가?필요한 범주와 해당 범주에 없는 특정 관련 페이지로부터 차단하면 대부분의 문제가 사라진다. — SMc캔들리쉬 lish 😼 04:50, 2019년 12월 13일 (UTC)[응답]
19. 개념을 지지하다.단, 툴을 활성화하기 전에 이를 뒷받침하는 정책이 있어야 한다. --돌로타(토크) 15:26, 2019년 12월 13일 (UTC)[응답]
20. 지원으로 유용하고 잠재적으로 운영 중단을 줄일 수 있는 옵션이 추가됨유연성과 선택권은 거의 항상 좋은 것이다.반대 의견을 읽으면서, 나는 심각한 문제가 발생할 것 같지 않다고 생각한다 - 그리고 만약 문제가 발생한다면 우리는 그것에 대한 정책을 바꾸거나 그것을 사용하지 않기로 결정할 수 있다.우리가 사용을 거부할 수 있는 것에는 내재된 위협이 거의 없다.가장 나쁜 경우는 그것이 가치 있는 실패 실험이 될 것이고, 우리는 그것을 사용하는 것을 멈추고 한가롭게 그것이 불능화되기를 요청한다.알제 (대화) 17:27, 2019년 12월 13일 (UTC)[응답]
21. 한 글의 전쟁이나 일부 페이지의 주제 금지 위반과 같이, 한 페이지 또는 한 페이지의 그룹에 혼란을 야기하는 사람들에게 이 아이디어를 지지하십시오.교란이 제한되는 한, 그들이 백과사전의 나머지 부분들도 편집하는 것을 막을 특별한 이유는 없다.Hut 8.5 17:51, 2019년 12월 13일 (UTC)[응답]
22. 어떤 경우에는 풀 블록이 필요하지 않은 경우도 있다는 점을 고려하면, 지원은 꽤 멋지고 멋진 아이디어인 것 같다.부분 블록은 아마도 새로운 방법일 것이다.NNADIGUDUDLUK (Talk Incidents) 17:52, 2019년 12월 13일 (UTC)[응답]
23. 후속 RfC로 Beeblebrox당 시험 기간을 지원하여 이를 적용하는 최선의 방법의 범위를 결정한다.OhKayeSierra (대화) 20:12, 2019년 12월 13일 (UTC)[응답]
24. 나는 이것을 가능한 한 단순하게 유지하는 것에 일반적으로 찬성한다.나는 기본 개념에 전적으로 반대하지 않기 때문에, 나는 우리 프로젝트의 요구에 더 잘 맞도록 그것을 켜고, 메타 정책을 사용하고, 시간이 지남에 따라 그것을 수정한다고 말한다.그것은 우리가 그것을 모두 사용하지 않는다는 것을 수정하는 것을 포함한다. 우리가 그것을 사용하기도 전에 완벽한 정책을 개발하려고 노력하는 것이 시간이 지남에 따라 모든 정책들이 바뀐다. 만약 당신이 나에게 물어본다면 말보다 앞서가는 것이다.비블브록스 (대화) 00:08, 2019년 12월 14일 (UTC)[응답]
25. – Levivich 03:37, 2019년 12월 14일 (UTC)[응답]
26. 임시변통 - 논쟁 없이.꽤 유용하다.우리가 어떤 선택권도 잃지 않고 있다는 것 외에도, 사이트 전체 블록은 그대로 유지될 것이다.마섬 레자^📞 16:26, 2019년 12월 14일 (UTC)[응답]
27. 지원 – 독일어 위키백과에서 매우 잘 작동한다. --카운트 카운트 (대화) 19:53, 2019년 12월 14일 (UTC)[응답]
28. 무조건 지원 – 나는 이 RfC와 전반적인 기능을 오랫동안 기다려 왔다.전체 편집-경전 블록에 대한 이상적인 대안.~ ToBeFree (토크) 20:50, 2019년 12월 14일 (UTC)[응답]
29. 지지하다.다른 사람들과 마찬가지로, 나는 이 기능이 다른 곳에서 사용되고 있다는 것에 대해 처음 읽은 이후로 영어 위키백과에 오기를 기다려왔다.물론 어떻게 사용해야 하는지에 대한 가이드라인을 정해야 하지만 유익하게 사용할 수 없다는 주장은 설득력이 없다.편집자들이 완전히 차단되어야 하거나 하지 말아야 한다는 올-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노-노트는그것들과 부분 블록의 주요한 차이점은 (사이트 금지가 사회적이고 사이트 블록이 기술적인 것처럼) 그것들은 기술적 제약이라는 것이다.부분적 제약을 둘러싼 이러한 기존의 관행은 때로는 편집자가 어떤 분야에서는 유익하고 생산적이지만 다른 분야에서는 좋은 행동을 유지할 수 없다는 현실을 반영한다.만약 편집자들이 다른 분야에서 그들의 잘못된 행동에도 불구하고 어떤 분야에서 정말로 잘 행동하지 못했다면, 우리는 글로벌 블록을 가지고 있거나 아무것도 하지 않는 것이 나을 것이다. 그것은 우리가 하는 일이 아니며 아무도 요구하는 것이 아니다.부분적 차단은 이러한 모든 것이 아니거나 전혀 없는 상황을 관리하는 데 도움이 되는 또 하나의 도구일 뿐이다.부분 블록과 관련된 드라마와 위키리거링이 있을 것인가?물론 그럴 것이다; 사람들은 어떤 종류의 제재나 제한을 두고 드라마와 위키리크스를 만들어낼 것이다.그렇다고 해서 그들을 제한할 수 있는 도구가 있으면 안 된다는 뜻은 아니다. --RL0919 (대화) 21:49, 2019년 12월 14일 (UTC)[응답]
30. 후속 RfC 지원 - 때로는 사이트 전체 블록이 필요하지 않으며 WP로 보일 수 있다.다른 위키에서 효과가 있었다면 여기서 활성화해야 한다.BEANS X2 (토크) 12:03, 2019년 12월 15일 (UTC)[응답]
31. 지원 이 의지는, 분명히 몇 가지 지침이 환영하겠지만, 전체 사이트에서 편집자를 차단하거나 차단하지 않는 바이너리 선택보다는 백과사전을 보호하기 위한 좀 더 미묘한 접근을 허용할 것이라고 생각한다. --Malcolmxl5 (대화) 20:03, 2019년 12월 15일 (UTC)[응답]
32. 지원 나는 부분 블록은 특정 상황에서만 사용되어야 한다고 생각한다. 예를 들어, IP 편집의 중단을 줄이고 차단된 편집자들이 이전의 문제점으로 바로 다시 뛰어드는 것을 허락하지 않고 교훈을 얻었다는 것을 보여줄 수 있는 기회를 주는 것이다.나는 합의된 정책(또는 정책/메타 정책이 가는 길이 아니라는 합의)과 함께 부분 블록을 사용하는 데 바로 뛰어들면 도움이 될 것이라고 생각한다.아래에서 이미 일어나고 있는 일이기 때문에, 나는 지지한다.몽환 재즈 🎷 12:36, 2019년 12월 16일 (UTC)[응답]

    부분 블록을 사용할 수 있는 구체적인 상황을 갖는다는 생각은 마음에 들지만, 부분 블록의 활성화에 대한 나의 지원은 이것에 의존하지 않는다.몽환 재즈 🎷 12:39, 2019년 12월 16일 (UTC)[응답]

33. 오랫동안 지연되어온 유용한 도구로 차단을 덜 징벌적이고 혼란을 예방할 수 있다.-- Deepfriedokra 05:11, 2019년 12월 17일 (UTC)[응답]
34. 지지하다.현실은 우리가 이미 이것을 하고 있다는 것이다. 우리는 그것을 시행하기 위해 많은 추가적인 단계를 거치면 되고, 그 주체가 망쳐서 그들 스스로 금지될 위험은 계속 있다.분명 기술적인 해결책은 우리의 주제 금지 시스템을 완전히 대체할 수 없다. 왜냐하면 때때로 누군가가 다른 부분을 자유롭게 편집할 수 있는 동안 주제 금지 아래에 있는 페이지의 특정 부분이나 논쟁을 피해야 할 필요가 있기 때문이다. 그러나 이것은 최소한 그들을 더 단순하게 만들 것이고, 어떻게 그것이 어떤 큰 문제로 이어질 수 있는지 알 수 없다.Ms. --조 (대화) 10:09, 2019년 12월 22일 (UTC)[응답]
35. 조건부 지원 이것은 사이트 전체의 금지에 대한 덜 엄격한 대안으로서 좋은 생각이다.그러나 우리는 이러한 도구의 범위를 제한하기 위해 RfC가 필요하다.이것은 일부 특정 상황에서 매우 유용하게 보이지만, 경고 후에만 사용되며, 전체 사이트 금지가 정당화될 수 없는 경우 예비 옵션으로 사용되지는 않는다.포브스72 (대화) 21:31, 2019년 12월 22일 (UTC)[응답]
36. 지원 sysops에게 더 많은 유연성을 줄 수 있는 모든 툴은 좋은 것이다.분명히, 만약 도구가 남용되는 오남용으로 이어질 수 있다면, 그것은 적용되지 않을 것이지만, 이것은 그것의 예가 아니다.sysops가 사용자를 부분적으로 차단할 수 있도록 허용하면, 블록의 목적이 충족된다는 점에서 기능적으로 차단될 수 있으며, 시공적으로 편집할 수 있는 권리를 완전히 제거하지 않아도 된다.최악의 경우 사용자가 그 후 파손될 경우 항상 완전히 차단할 수 있다.최상의 경우, 차단된 사용자에게 구조적으로 편집하려는 의도를 보여줄 기회를 제공하여 잠재적으로 다소 비효율적이고 비효율적인 표준 오퍼를 쓸모 없게 만들 수 있다. --Puzzledgetable^{Is it teatime already?} 23:42, 2019년 12월 22일(UTC)[응답]
37. 강력히 지지하다.다른 영역에서는 건설적인 작업이지만 특정 페이지/네임스페이스에 문제가 있는 편집자의 업무 중단을 제한하는 데 많은 잠재적인 용도가 있다.누군가가 전쟁을 편집하는 것을 막는 것은 좋은 방법일 수 있지만 또한 그들이 다른 비논쟁 영역을 편집할 수 있도록 허용하는 것이다.또한 주제 금지 또는 기타 편집 제한을 시행하는 데 사용될 수 있다.하지만 나는 이것이 현명하게 사용되어야 한다고 생각한다.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
38. 전체 블록이 너무 조잡한 상황에서 적절한 조치가 될 수 있는 많은 잠재력을 지원하십시오.정책 세부사항을 결정하기 위해 시험 및/또는 후속 RfC가 필요할 수 있지만, 이 기능은 부인할 수 없이 유용하며, 이 양식이 아무리 넓거나 좁은 형태라 할지라도 어떤 형태로든 활성화되어야 한다. – Teratix ₵ 05:49, 2019년 12월 28일(UTC)[응답]
39. 지지하다.부분 블록은 주제 및 네임스페이스 금지 시행 필수 사항. 아베퀸^fourteen 23:01, 2019년 12월 28일 (UTC)[응답]
40. 조건부 지원은 도구상자에 담기 좋은 도구가 될 것이라고 생각하지만, 도구상자에 대한 사용방침에 대한 합의가 이루어진 후에야 비로소 시험기간이 있을 뿐이다.나는 이러한 정책 없이 또는 명시적인 종료일을 가진 재판 없이 이것을 켜는 것에 반대한다. 이후 RfC 01:59, 2019년 12월 29일 (UTC)[응답]
41. 지원 - 이것은 이미 재량적으로 사용되고 있는 현재의 공구에 대한 덜 엄격한 대안이다.단순히 저점차단을 위한 선택권인 것을 위해 새로운 정책이 필요하다고 제안하려는 시도는 적색수배다.어떤 문제가 제기되면 얼마든지 해결할 수 있지만, 솔직히 야당이 생각하는 이런 난해하고 얼굴도 없는 '문제'의 가능성은 보이지 않는다.~스왑~ 2019년 12월 30일 02:18 (UTC)[응답]
42. 응. 이 기능은 기능이 너무 제한적이어서 블록이 특정 카테고리의 페이지나 특정 기능을 가진 페이지를 편집하지 못하게 하는 것을 보고 싶어.페미니스트 (토크) 03:12, 2019년 12월 30일 (UTC)[응답]
43. 지원 - 부분 블록은 단순히 더 많은 유연성을 허용한다.그것들은 적절하지 않다고 여겨지는 경우에 사용될 필요가 없다.적합한 경우, 풀 블록에 훨씬 덜 극적인 대안을 제공한다. - 알렉시스 재즈 20:17, 2020년 1월 1일 (UTC)[응답]
44. 조건부 지원 - IQTY처럼 되지 않으면서 업무 중단을 제한하는 능력 때문에 매우 유망한 도구인 것 같다.다만 일부 블록을 중심으로 잘 정리된 정책에 대한 공감대가 있어야 남용을 막을 수 있다.--Rlin8 (인터뷰·공방) 06:11, 2020년 1월 2일 (UTC)[응답]
45. 지지 부분 블록에 대한 내 의견에는 많은 정당성이 있다.사용자들은 일부 페이지에는 문제가 있을 수 있지만 다른 페이지에는 문제가 없을 수 있다. 그것은 주제 금지에도 좋은 안전장치가 될 것이다.드루이스테이 (대화) 20:11, 2020년 1월 4일 (UTC)[응답]
46. 업무 중단이 특정 영역으로 제한되는 경우 이를 지원하는 것이 유용한 도구가 될 수 있다.완전히 차단하는 것에 대한 좋은 대안으로, 편집자들이 차단된 후에 떠나기보다는 프로젝트에 머무르고 그들의 오류로부터 배우게 될 수도 있다.Mjroot (대화) 20:13, 2020년 1월 4일 (UTC)[응답]
47. 이에 대한 정책 I 에코 Mz7, Spirm, Beeblebrox 등의 개발을 위한 후속 RfC 지원. --The Sand Doctor 20:43, 2020년 1월 4일 (UTC)[응답]
48. 지원:차단, 금지, 제재는 무엇에 대한 것인가?처벌이 아닌 피해 예방이 우리가 채택해야 할 답이다.예방적 모델에서, 길이, 범위 등 모든 면에서 제재가 최소화되어야 한다는 것을 논리적으로 따른다.—그들이 막으려는 위해를 방지하는 방법.부분블록은 범위를 제한하는데 매우 바람직하며, 목적이 부분블록과 같은 곳에서는 사전에 많은 논의를 보았으나, 기술적 이유로 풀블록의 해머를 사용해야 했다.나는 또한 부분적인 블록이 유용하게 쓰일 것이라고 생각했던 많은 문제들을 접했다.아래에 언급된 IP 이용 사례가 좋은 예다.사람들이 "Opose" 섹션에서 언급하는 이슈들은 부분 블록의 사용 사례를 제한하고 충분한 감독을 하고 우리의 정책이 상식을 허용하도록 하는 이유들이다.예를 들어, 사용자가 기술적으로 편집이 제한된 페이지에만 주제 금지를 적용해서는 안 되며, 현재와 같이 주제 금지의 전체 범위에 적용해야 한다.부분 블록은 여전히 취해야 할 심각한 조치로 간주되어야 하며 분명히 WP의 적용을 받는다.관련됨.그리고 마지막으로, 일부 사용자들이 그 과정이 다른 순서로 이루어졌어야 했다거나 RfC가 더 단순하거나 더 복잡했어야 했다라고 언급하지 않았다면 RfC가 아닐 것이다: 우리는 첫발을 내딛어야 하고 이것은 나에게 합리적인 것으로 보인다.이를 일부 차단하는 적을 마음대로 돌아다니는 권한으로 받아들이는 행정관은 여전히 우리의 정상적인 모든 행동 제재 과정에 책임을 져야 한다.— 빌로프 (대화) 00:14, 2020년 1월 5일 (UTC)[응답]
49. 지원: 부분 블록은 여전히 심리적으로 블록이며, 편집자와 관리자가 블록을 수행하는 것으로 볼 때, 관리자가 불량 블록을 만들 수도 있고 삭제된 경우도 있다.나는 그 선택권을 매우 고맙게 여길 것이다; 부분 블록은 본질적으로 덜 엄격한 제재일 뿐이고, 나는 편집자에게 특정 페이지에서 손을 떼라고 강요하는 것만이 필요한 여러 상황을 기억할 수 있다.일부 블록의 오용에 대한 위협은 이미 일반 블록에 적용되어 있는 것 같다.~ 마즈카 02:12, 2020년 1월 5일 (UTC)[응답]
50. Supprt 긴 리드를 올리고 나면, 이제 때가 되었다.상황에 맞게 조정할 수 있는 유연성.관리자들은 이미 기간을 기준으로 블록 선택을 할 수 있으므로, 현상유지는 전혀 또는 전혀 없는 블록이 되지 않았다.—바굼바 (대화) 02:20, 2020년 1월 5일 (UTC)[응답]
51. 지원, 더 적은 도구보다 더 많은 도구가 더 낫다.숨막힐 (대화) 10:07, 2020년 1월 6일 (UTC)[응답]
52. 지원하되, 초기 롤아웃은 1) 시험 기간(아래 참조) 및/또는 2a) 동안 정책 결정을 위한 후속 RfC 후 여기서 또는 2b의 명확한 합의가 있는 경우에만 허용하는 정책을 적용해야 한다.예를 들어, 여기서 이를 구현하기 위한 명확한 합의가 있지만 개별적인 "유용 사례 시나리오"가 합의점을 가지고 있지 않다면, 시험 기간 및/또는 후속 RfC를 진행하십시오.합의된 내용이 명확한 '이용사례 시나리오'가 일부 있을 경우 즉시 이행할 수 있지만, 향후 RfC가 이용정책을 갱신할 수 있도록 시험기간도 괜찮다.davidwr/(대화)/(논문)20:19, 2020년 1월 8일(UTC)[응답]
53. 지지자들은 부분 블록이 최후의 수단인 전체 블록보다 확실히 더 나은 선택이라고 느낀다.이제 우리가 건설적으로 기고하는 것은 다른 곳에 기고하는 부분적인 블록을 다루고 있는 것은 종신 편집자들이다.마법사의 파라오 (토크) 11:46, 2020년 1월 10일 (UTC)[응답]
54. 지지 나는 반대론보다 지지 이유가 더 설득력이 있다고 생각한다.— 체드 (대화) 04:29, 2020년 1월 11일 (UTC)[응답]

반대하다

1. 나는 부분 블록이 그들이 차단하려고 시도하고 있는 것보다 더 많은 혼란을 야기하지 않는 사용 사례는 생각할 수 없다.그들에게 가장 흔한 논쟁은 편집 전쟁이지만, 여기에서는 그럴 것 같지 않다: 우리는 현재 편집 전쟁에 매우 관대하다. 그리고 거의 항상 처음에 자동적으로 차단을 해제하는 것은 여기서 일어날 것 같지 않다. 그리고 만약 내가 생각하기에 실제로 편집할 수 없는 상태에서 토크 페이지에서 논쟁하는 것이 사람들을 더 화나게 할 것 같다.
   그러나 실제적인 문제에 대해 이야기해보자: 이것은 단지 역효과를 내고 프로젝트를 불안정하게 할 수 있는 방식으로 관리자 권한의 범위를 크게 확장한 것이다.현재, 매우 정의된 상황을 제외하고, 관리자는 개별 편집자에게 제재를 가할 수 없으며, 그렇지 않으면 블록에 대한 정당성을 확립할 필요가 있다.그것은 여기서 사라질 것이다.이것이 혼란을 막기 위한 덜 거슬리는 수단이라고 주장되지만, 그 대신 그것은 행정관의 제한된 권한의 범위를 재량적 제재의 범위를 훨씬 넘어 확대하는 방법이다.그것은 그 프로젝트에 건강에 좋지 않고, 그 자체로 반대해야 할 이유다.
   DS 분야로 한정됐다 하더라도 재량제 시행을 위한 기술적 수단으로 활용하면 더 이상 필요 없는 분야에서는 위키백과 극한드라마로 이어질 수 있다.이런 식으로 시행하는 것을 금지하는 주제는 악몽이 될 것이고, 우리는 그것을 필요로 하지 않는다.
   마지막으로, 방에 코끼리가 있다: en.위키에는 이미 장기간의 혼란을 특권하고 친구를 가진 사람들에 대한 제재가 거의 불가능한 문화가 있다.이러면 더 나빠질 거야블록은 관리자가 더 적은 옵션을 사용했어야 한다는 원칙에 따라 무한히 경쟁될 것이고, Wikilawyering은 풍부할 것이다.
   궁극적으로, 위의 모든 요점은 이것이다: 누군가가 차단될 정도로 파괴적이거나, 아니면 차단되어서는 안 된다.그 외 다른 것은 제한적 금지와 같은 사회적 수단을 통해 시행되어야 한다.시험이나 2차 RfC는 해결책이 아니다. 왜냐하면 그것들은 스스로 전달할 수 없는 것에 대한 지지를 얻을 수 있는 방법일 뿐이고 그것이 얼마나 비참한 실패인지에 상관없이 실행되더라도 되돌리지 않을 것이기 때문이다.우리는 이미 그것을 할 수 있는 수단을 가지고 있다.en.wiki에 대한 불필요한 나쁜 생각을 허용함으로써 더 이상의 혼란을 야기할 필요는 없다.토니발리오니 (토크) 05:46, 2019년 12월 12일 (UTC)[응답]

   @TonyBallioni:우리는 이 문제를 다른 곳에서 좀 더 길게 논의할 수 있지만, 나는 단지 그 걱정거리들 중 한 가지만 언급하고 싶다.현재 우리가 차단할 수 없는 것을 다루는 방법은 계좌에 시간제한 블록을 적용하는 것이다.사람들은 부분 블록이 가능하든 상관없이 덜 엄격한 조치가 가능했는지를 두고 위키리더처럼 될 것이다. (시간 제한 블록을 제거하면 사람들은 어떻게든 22초 경고가 충분했을 것이라고 주장할 것이다.)나는 진공상태에서 특정 문제 영역을 대상으로 하는 부단한 부분 블록이 일시적인 제한 블록보다 훨씬 더 생산적이라고 말하고 싶다. 왜냐하면 그것은 지속되는 힘을 가질 것이기 때문이다.
   다른 점에서는, 관리자들이 더 효과적으로 논의할 수 있는 사항이기 때문에 이의를 제기하지 않겠다. –MJL ※^☖Talk – 14:16, 2019년 12월 12일 (UTC)[응답]

2. 나는 그것들이 유용하거나 효과적일 것이라고 생각하지 않으며, 화난 토론으로 이어질 것 같다.좋은 이유와 함께 물어보면.--위활트(대화) 06:18, 2019년 12월 12일 (UTC)[응답]
3. 토니가 한 말.관료주의적 악몽이 될 것임은 말할 것도 없다.이제 모든 관리자가 모든 것에 대해 DS와 같은 권한을 효과적으로 갖게 될 것인가?그것은 행정 개입의 범위가 어떻게 되어야 하는지에 대한 영어 위키피디아의 오랜 관습과 일치하는 것으로 보이지 않는다.이것은 근본적으로 정책 수준의 중대한 변화다.이것은 단순히 기술적인 변화만이 아니다.El_C 06:32, 2019년 12월 12일 (UTC)[응답]
4. 매우 강한 반대 - 말 앞에 수레.우리는 부분 블록의 사용을 지배하는 것의 발전의 시작에 대한 정책이나 힌트를 가지고 있지 않다.아무런 규칙도 없이 그런 강력한 기능을 가능하게 하는 것은 완전히 바보 같은 짓이다.토니는 또한 매우 좋은 점을 지적한다.개인적으로 나는 이 기능의 구현을 기대하지만, 이 단계에 있기에는 너무 이르다.이반벡터 (/)^Talk_Edits 16:44, 2019년 12월 12일 (UTC)[응답]

   정책은 필수적이지만, 나는 정책이 활성화되어야 한다고 결정하기 전에 정책을 수립할 필요가 있다는 것에 동의하지 않는다.다른 방향에서 바라봐:어쩌면 우리는 한 달 동안 이행을 위한 정책을 만들고 쓰는 데 쓸지도 모른다; 그것이 어떻게 그리고 언제 사용될 것인지, 우리는 긴 토론과 투표 등을 하고, 우리 모두가 동의할 수 있는 좋은 정책을 만들면, 공동체는 그 도구의 사용을 전면적으로 거부한다.지역사회가 사용할 계획이 없는 도구를 위한 정책을 만드는 이유는 무엇인가?우리 둘 다 도구를 사용해야 한다는 것을, 그리고 어떤 조건에서 사용해야 한다는 것을 확립해야 하지만, 나는 공동체가 그 도구를 애초에 원하는 것을 알지 못하는 한 정책을 개발하는 것이 실망스러울 정도로 무의미하다는 것을 알게 될 것이다. --Jayron32 19:11, 2019년 12월 12일 (UTC)[응답]

   공정한 지적이지만, 이 질문은 "이 도구를 그 사용을 통제하는 정책을 개발하는 것과 함께 사용할 수 있도록 해야 하는가?"가 아니다.문제는 "이걸 켜야 하나?"이다.그리고 대답은 '아니오'이다.이것을 바라보는 다른 방법은 "여기에 도구가 있다. 이제 그것이 어떤 문제를 해결하는지 알아내라"의 또 다른 예다.아니면 한가지 더, 지역사회가 그것이 어떻게 사용될 것으로 예상하는지에 대한 안내 없이 관리자들에게 새로운 도구를 제공하는 것은 모순과 많은 드라마를 유발하는 것이다. 이유는 좋을 수도 있지만 아무도 그러한 이유가 무엇인지 알지 못한다.이반벡터 (/)^Talk_Edits 19:55, 2019년 12월 12일 (UTC)[응답]

   @Ivanvector:이것이 사실 질문이다:필요한 경우 후속 RfC를 개최하여 차단 정책이 이미 블록에 부과한 부분 블록 이외의 부분 블록 사용에 제한을 가해야 하는지 여부를 결정할 수 있다. –MJL ▲토크 04:^☖49, 2019년 12월 13일(UTC)[응답]

   아니, 그건 문제가 아니야."필요하다면..." 아니, 도구를 켜기 전에 필요한 것이다."제한...이미 블록에 적용하고 있는 것 이상으로, 이 새로운 도구를 사용할 수 있도록 할 것이며, 보다 세분화된 차단을 위한 사용 사례가 있는지 확인할 때까지 "완전한" 블록과 똑같이 사용할 것으로 예상됨을 시사하며, 실제 문제에 대한 유용한 해결책이 될 것으로 기대되지 않거나, 아니면 이 툴을 사용하여 찾을 것임을 시사한다.1. 나는 이 프로젝트의 초기 단계에서 부분 블록이 쌓일 수 없다는 것이 발견되었음을 기억한다. 따라서 당신은 정확히 한 페이지, 또는 정확히 모든 페이지로부터 누군가를 차단할 수 있지만, 그 사이에 있는 것은 아무것도 없다. 그리고 만약 그것이 해결되지 않았다면, 이것은 (예를 들어) 임의적인 제재 집행을 위해 어떤 용도로 사용되었을까?이것은 도구가 개발되었지만 어떤 문제가 해결되었는지 알 수 없었던 미결 변화 레벨 2와 매우 유사하게 진행되고 있으며, 몇 년 동안 열띤 토론 끝에 우리는 그것을 사용하지 않기로 결정했다.도구를 사용할 수 있다고 해서 그것이 유용하다는 뜻은 아니다.이반벡터 (/)^Talk_Edits 16:36, 2019년 12월 13일 (UTC)[응답]

5. 아마 나중에 지원하겠지만, 사용량 기대치가 무엇인지 먼저 파악하지 않고 이것을 가능하게 하는 것이 더 많은 드라마를 유발할 것이고, 그 후에 해결이 될 것이라고 생각한다.이것이 도움이 될 수 있는 많은 방법들이 있을 수 있지만, 신중한 고려 또한 중요하다(예를 들어, 우리가 새로운 "절제" 블록 타입을 만드는가, 어쩌면 우리는 더 이상 프록시에 있는 애논 사용자들을 완전히 차단하지 않을지도 모른다, 누가 그것이 논의될 때까지 아는가....여기서 관리자인데 테스트위키에서 기능에 대해 자세히 알아보려면 테스트위키에서 노트를 보내주십시오.사용자 대화:Xaosflux와 내가 임시 관리자 권한을 추가해 줄게.— Xaosflux^Talk 17:10, 2019년 12월 12일 (UTC)[응답]

   위 참조:나는 우리가 먼저 그것을 가능하게 해야 한다고 확립할 수 있다고 생각한다.우리는 실제로 당장 그것을 가능하게 할 필요가 없고 단지 지역사회가 실제로 이와 같은 것을 원한다는 것을 알아야 정책 프레임워크를 밀고 나갈 수 있다.지역사회가 전혀 원하지 않는 도구를 위해 정책을 미리 쓰는 이유는 무엇인가?우리가 먼저 이것을 원한다는 것을 확인한 다음 정책을 쓰고, 그 정책을 실행하자. --Jayron32 19:14, 2019년 12월 12일 (UTC)[응답]

   사용지침이 있을 때만 사용을 해야 한다고 생각해.나는 그것이 정리되는 동안 "그냥 사용하지 말라"는 규칙으로 그것을 가능하게 하는 것을 지지하지 않는다.— Xaosflux^Talk 20:21, 2019년 12월 12일 (UTC)[응답]

   아래에 제안된 사용 사례/가능한 사용 사례와 관련하여 당사에 적합한 별도의 논의가 있다면 도움이 될 만한 사용 사례를 살펴보십시오.그러면 a) 후속 RFC/trial 및 b) 후속 조치를 진지하게 고려하도록 일부 반대파/지원자를 설득할 수 있다. --Izno (대화) 20:43, 2019년 12월 12일 (UTC)[응답]

   좋은 생각이야.나는 #브레인스토밍 정책에서 아래에 브레인스토밍 아이디어를 몇 가지 추가했다.Mz7 (대화) 22:56, 2019년 12월 12일 (UTC)[응답]

6. 나는 IP/IP 범위만 지원하는데, 이 범위를 특정 페이지/네임스페이스에서 차단하는 것이 매우 유용할 것이다. 현재 편집 필터로만 할 수 있다.편집 필터는 기술적으로 유능한 관리자만 액세스할 수 있으며, 이를 사용할 줄 아는 사용자로서도 하나의 IP/IP 범위에 대해서만 생성하기에는 일종의 번거로움이다.IP/IP 범위에 대한 부분 블록의 단점이 잘 보이지 않는다.
   그러나 나는 토니 발리오니의 다른 용도에 대한 그의 지적에 동의한다. 그래서 나는 다른 사용 사례를 지지하지 않는다.이쯤에서편집 전쟁을 위해 나는 WP가 없는 편집 중인 페이지에서 "슬랩 온 더 쓰기"를 장기 사용자가 차단하는 2단계 시스템을 확실히 볼 수 있었다.블록체크렌트(BLOCKDECHRENT)는 향후 편집 전쟁에 대해 사용자에게 본질적으로 실제 결과 없이 원하는 만큼 전쟁을 편집할 수 있다고 알려준다(이미 문제가 있는 것이 아니라 부분 블록으로 악화될 가능성이 있음).부분 블록은 또한 상당한 관리 권한의 확장을 의미하며, 활성화된 경우 먼저 초안 정책을 신중하게 고려해야 한다. 부분 블록의 활성화에 대한 내가 선호하는 접근 방식은 특정 사용 사례에서만 허용(사전 지정)하는 것이다.갤럽터 (pingo mio) 22:04, 2019년 12월 12일 (UTC)[응답하라]
7. 반대: 편집자가 주제 금지 또는 편집 전쟁 정책을 준수할 수 없는 경우, 편집자는 편집해서는 안 되며, 대화 페이지에서 논쟁을 계속하여 허가받지 않은 편집자 시간을 낭비해서는 안 된다.또한, 이 제안은 제재가 시행되는 동안 편집자가 자신이 좋아하는 주제를 추구해야 하는지에 대해 생각할 필요가 있는 대신, 관리자가 계속 진행할 수 있는 모든 가능한 페이지에서 해당 주제를 기술적으로 차단해야 하는 주제 금지 사항의 일반적인 해석을 뒤집음으로써 위키레이닝을 촉진할 것이다.조누니크 (대화) 02:52, 2019년 12월 13일 (UTC)[응답]
8. 지역사회의 승인을 받는 부분 블록의 사용에 대한 정책을 가지고 있기 때문에 그러한 때까지 반대한다.이것들을 사용하기 위한 정책을 만들기 전에 활성화하는 것은 거꾸로 보인다.내가 뒤쳐질 수 있는 용도들이 있다. (예: 지역사회의 지원이나 재량적 제재로써 부과되는 일부 주제 금지들을 대체하기 위해서) 그리고 내가 할 수 없는 다른 것들이 있다.그러나 정책 없이는 이것은 관리 재량권의 엄청난 증가를 의미하기 때문에 우리는 먼저 적절하고 부적절한 사용을 기술할 필요가 있다.바나몽드 (토크) 06:18, 2019년 12월 13일 (UTC)[응답]
9. 급할 것 없다.최근에야 가능했던 다른 위키에서 이것이 어떻게 작동하는지 봅시다. 그리고 그들의 경험을 바탕으로 다시 평가합시다. --valeree (대화) 20:10, 2019년 12월 13일 (UTC)[응답]
10. 아래의 특정 사례에서 부분 블록의 사용을 지원했지만, 그 사례는 매우 드물기 때문에 전체적으로 기능 활성화는 주로 관리자의 기술력을 사회적 힘으로부터 더 크게 확장하는데 도움이 될 것이다. (나는 부분 블록의 전쟁 편집에 대해 위의 Galobtter에 동의하며, 그렇게 느낀다.주제 금지와 같이 컴퓨터가 정의할 수 없는 편집 제한을 부분 블록으로 강제하려고 하는 것은 불가능하다.* 페이퍼리 * 02:44, 2019년 12월 15일 (UTC)[응답]
11. 기본적으로 토니, 갤럽터처럼 반대하라.GAB^gab 16:12, 2019년 12월 17일 (UTC)[응답]
12. 지금은 반대다.재판일 가능성은 낮아 보이지만 재판의 가능성은 내가 반대 입장을 유보한 주요 이유 중 하나이다.아래에서 정책이 어떻게 형성되고 있는 것처럼 보이는지 볼 때, 나는 우리가 어떤 부수적인 피해가 발생할 수 있는지 확실히 이해하면서 이 문제에 개입하고 있다는 믿음이 전혀 없다.이 과정은 급박하게 느껴지고 2주간의 생각에도 불구하고 나는 여전히 아래의 제안들에 대해 확고한 의견을 가지고 있지 않다.나는 valerie의 의견에 동의한다. 우리는 우리의 차단 정책과 기술에 대한 급진적인 변화가 야기할 수 있는 결과에 대한 많은 생각 없이 이 문제에 개입하기 보다는 다른 위키에서 그것이 어떻게 작동하는지 보아야 한다.나는 내 생각을 나중에 바꿀 수 있다면 매우 기쁘겠지만, 지금으로서는, 한정된 시험 기간이 없다면, 우리가 이 연장을 가능하게 해야 한다고 생각하지 않는다.— Wug·a·po·des 20:18, 2019년 12월 31일 (UTC)[응답]
13. 일단 반대하다.나는 우리가 옵션을 켜기 전에 그것에 대한 정책이 있었으면 좋겠다.PlatypusofDoom (talk) 05:25, 2020년 1월 2일 (UTC)[응답하라]
14. 일단 반대하다.토니 발리오니와 이반벡터는 여기서 좋은 점을 지적한다; 그것은 약간 "못을 찾는 망치"와 같은 느낌이다.나는 위키피디아에서 기존의 인식된 문제에 대한 해결책과 같은 그러한 도구에 대한 강한 욕구를 본 적이 없다.한 영역에서 매우 파괴적인 편집자가 될 수 있지만(따라서 차단됨), 다른 곳에서 편집이 자유롭다는 말씀이십니까?그러므로 우리는 문제 편집자들이 (일반 블록이 아닌) 파괴적인 전체 주제에 걸쳐 개별 블록의 확장된 매트릭스를 필요로 하는 것과 같은 지속적인 호소에 종지부를 찍을 것인가?나는 이 도구가 결코 사용되지 않을 수도 있다고 말하는 것은 아니지만, 첫 번째 패스로서, 주제 금지/AE형 상황에 대한 "기술 업그레이드"로 사용하는 것이 더 나을 수 있다.내 생각에 DS형 행정제재는 관리자들에게 상당한 스트레스와 시간이 걸리고 관료적인 과정이며 (따라서 많은 사람들이 이를 멀리한다) 이는 이 상황을 악화시킬 뿐이지 않을까?영국 금융 (대화) 15:40, 2020년 1월 2일 (UTC)[응답]
15. 절대 안 돼. 우리는 단지 그 충동이 다시 그들을 강타하는 즉시 다른 곳으로 그들의 혼란을 계속하도록 내버려두기 위해서 특정 지역에서 그들을 차단해서는 안 되는 거야?그것이 어쨌든 금지와 아르브콤 제재의 주제인 것이다. 우리는 이미 이에 대한 해결책을 가지고 있다.이렇게 하는 것은 마치 은행 강도가 은행을 털지 않는 한 다른 은행을 털지 못하게 하는 것과 같은 느낌이지만, 은행을 털지 않는 한, 다른 은행을 털지 못하게 하는 것 같다. -- 10^™:46, 2020년 1월 5일 (UTC)[응답]
16. 반대--User_talk:Oldstone_James#Notice_notice_to_now_subject_to_a_community_editting_restriction을 검열에 사용하는 방법의 예로 들 수 있다.심지어 이 사람을 차단한 사용자도 이것이 검열이라는 사실에 직면했을 때, 이에 대해 "꼭 거절하지는 않는다"고 말했다.더구나 문맥상 편집자가 차단된 것은 종교적 근본주의자가 아닌 '유대인 무신론자'로 파악된다.그는 종교계의 입장을 대변하는 데 도움이 될 만한 종교적인 주제 기사에 아주 사소한 변경을 요구했다가 저지당했다.--Epiphyllumlover (대화) 01:29, 2020년 1월 11일 (UTC)[응답]

중립

1. 부분 블록에 대해 평가판 사용 기간을 지원하여 평가판 사용 기간 후 무 블록으로 되돌리십시오.이를 구현할 조건을 결정하기 위해 두 번째 RfC를 지원하십시오.그 두 가지 조건 없이 반대하라.이 두 조건이 충족되면 중립을 유지하십시오.Best, Barkeep49 (대화) 05:47, 2019년 12월 12일 (UTC)[응답]
2. 도구를 활성화하는 순간 사람들은 예상치 못한 방법으로 도구를 사용할 수 있는 방법을 찾을 것이다.예를 들어, 수정사항 삭제를 제대로 규제하는 데 수년이 걸렸지만, 우리는 여전히 관리자들이 부적절한 이유로 작은 정보들을 삭제하는 것에 대해 논란이 있다.영어 위키피디아는 논란의 여지가 있는 유일한 위키미디어 프로젝트로서, 여기에는 주제 금지의 광범위한 사용 때문에 일부 블록이 타당하지만, 비록 지역사회가 그것들을 채택하기로 결정하더라도, 그것들이 순조롭게 운영되려면 많은 시간이 걸릴 것이라는 것을 우리는 알아야 한다.그 비용은 엄청날 것이다. 이점 또한 확실히 하는 것이 중요하다.Nemo 06:41, 12 = 2019년 12월(UTC)

   반대하기 위해 움직여서 바킵49의 조건에 동의한다. 토니발리오니의 반대는 나의 예약을 잘 설명해준다. 내가 보는 주요 장점은 부분 블록이 미트볼에 도움이 된다는 것이다.문제가 특정된 LimitDamage: 예를 들어 신뢰는 좋지만 템플릿 편집은 중단되거나 프로젝트 공간에서 비생산적인 코멘트를 제공하는 경우. 그러나 일부 블록이 아이러니하게도 더 많은 피해로 이어지는 것을 볼 수 있기 때문에 시험 기간을 갖고 싶다: 사람들은 블록을 잘 받아들이는 일이 거의 없고, 좌절감이 WP로 이어질 수도 있기 때문이다.사용자가 여전히 편집할 수 있는 영역의 PITY 중단. 시험 기간이 있다면 부분 블록이 전체 블록과 상관되지 않는지 확인하고 싶다. 나는 또한 그것들이 주제 금지를 시행하는 기본 방법으로 사용되지 않기를 바란다. Wug·a·po·des 18:01, 2019년 12월 12일(UTC)[응답]

3. 나는 IP, 즉 IP 범위가 IP의 다른 사용자로부터 다른 영역에서 건설적인 기여를 허용하면서 특정 기사를 편집하는 것을 차단할 수 있는 Mz7의 제안 사례에 근거하여 일반적인 생각을 지지한다.나는 다른 경우들에 대해서는 잘 모르겠다 - 나는 우리가 지역사회의 승인 앞에서 개혁을 거부한 상습적인 편집 전사를 막지 않도록 동기를 부여받을 또 다른 상황을 상상하기 위해 애쓰고 있다. 하지만 어떤 경우든, 사용 정의에 관한 RfC가 RfC보다 먼저 도구를 켜야 한다.GirthSummit _(blether) 23:40, 2019년 12월 16일 (UTC)[응답]

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

시험 기간이 끝나면 새로운 부분 블록이 모라토리엄에 놓이고 부분 블록의 영구적 사용(또는 시험 기간의 연장)을 결정적으로 결정하기 위해 RfC를 보유해야 한다.후속 RfC는 그때까지 합의를 통해 차단방침을 형성하지 않은 경우 부분 차단방침도 결정하게 된다.

지원(재판)

1. 지원 Per my comment Per 위 제안서에서는 3개월의 시험기간을 지원한다. --qedk (t 桜c) 22:07, 2019년 12월 12일 (UTC)[응답]
2. 지원 나는 우리가 두번째 rfc에서 제안하는 어떤 요구사항의 시험기간이 중요하다고 본다.재판은 한정된 블록으로 실험하는 것이 아니라 한정된 블록에 대한 우리의 기준과 엔위키에서의 제한된 블록의 유용성에 대해 우리에게 말해주는 것을 실험하는 것이다.이제 우리는 제한된 블록에 대한 몇 가지 기준을 시도하는 것 외에는 아무것도 하지 않기로 미리 약속한다.만약 이 도구에 반대하는 사람들이 두려워하는 것만큼 끔찍하게 밝혀진다면, 우리는 영구히 앞으로 나아갈 수 있는 공감대를 갖지 못할 것이다.Best, Barkeep49 (대화) 01:41, 2019년 12월 13일 (UTC)[응답]
3. 물론, 위와 같다.SQL^{Query me!} 16:58, 2019년 12월 13일 (UTC)[응답]
4. 시험 기간 없이 두 번째 선택.나는 부도덕한 사람들이 시험 기간 동안 그들이 그렇지 않을 때와는 다른 행동 기준을 채택할 수도 있다는 느낌을 받지만, 나는 그 이유에 대해 손가락질할 수 없다.EllenCT (대화) 00:08, 2019년 12월 14일 (UTC)[응답]
5. 앞 절의 내 진술에 따르면또한 나는 "부분 차단 정책"을 사용하지 말 것을 권고할 수 있다. 왜냐하면 내 첫 번째 생각은 부분 블록에 대한 전체 정책일 때 정책의 일부만 개발한다는 것이었다.Wug·a·po·des 05:41, 2019년 12월 14일 (UTC)[응답]
6. 두 번째 선택으로 지원하십시오.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
7. 이 길을 따라갈 경우 지원 - 바쁜 RfC 중에 전체 사용 사례 옵션 목록을 작성해야 한다면, 나는 다시 주문을 해야 한다.만약 시험 없이 실행된다면, 그것을 멈추는 것에 대한 합의를 얻어야 한다.위키는 일이 잘 안 되더라도 버텨야 한다는 압박감이 상존하다.가능한 경우 이를 피해야 하므로 노즈백베어(토크) 18:25, 2019년 12월 26일(UTC)[응답]
8. 지지하되 최소한 정책이 먼저 거칠어지고, 그렇지 않으면 반대할 경우에만 지원한다.DES 02:02, 2019년 12월 29일 (UTC)[응답]
9. 내 일반 지원과 동일한 이유로 지원하지만, 전체 롤아웃 전에 시험 기간에 실제로 제대로 작동하는지 보는 것이 현명할 것이다.드루이스테이 (대화) 20:13, 2020년 1월 4일 (UTC)[응답]
10. 자격 있는 지원 나는 시험 기간을 선호하지만 절대적으로 필요하다고 생각하지 않는다.나도 위의 일반적인 질문에서 "지지"라고 말했다.davidwr/(토크)/(기증) 20:20, 2020년 1월 8일 (UTC)[응답]

반대 (재판)

1. 후속 RfC를 기다리십시오.정책에서 부분적인 블록을 구현하는 것에 대해 이야기할 때, 시험 단계가 아마도 제기되는 좋은 생각이 될 것이라고 생각한다.그러나 상대편 동료들은 정당한 우려를 제기했고, 이를 실행하기 전에 부분 블록에 대한 별도의 정책을 마련하기 위해 후속 RfC를 실시해야 한다고 생각한다.곧바로 시험 단계에 돌입하는 것은 나에겐 나쁜 생각처럼 느껴진다.Mz7 (대화) 22:26, 2019년 12월 12일 (UTC)[응답]
2. 아니오 - 새로운 도구의 사용 결과가 사람들이 편집하는 것을 방해하는 새로운 도구에 대해 실험해서는 안 된다.먼저 툴의 사용 방법을 파악한다.그런 일이 일어난 후, 재판이 보장될 가능성이 가장 높지만, "무슨 일이 일어나는지 보자"는 것은 편집자들을 차단하는 정말 나쁜 접근법이다.이반벡터 (/)^Talk_Edits 01:32, 2019년 12월 13일 (UTC)[응답]
3. 이반벡터가 한 말.갤럽터 (pingo mio) 04:26, 2019년 12월 13일 (UTC)[응답하라]
4. 부분적으로 이반벡터를 통해 반대한다.부분 블록을 테스트하기 위한 시험 기간을 가져야 하지만 후속 RfC가 부분 블록의 한계에 대한 대략적인 프레임워크를 결정한다.관리자는 특히 장기간에 걸쳐 원칙을 안내하지 않고 많은 영역에 영향을 미치는 위험한 도구를 주어서는 안 된다. 효과적인 시험 기간은 최소한 한 달 이상 소요될 것이다.NonymousUser (talk) 04:38, 2019년 12월 13일 (UTC)[응답]
5. 재판은 "사람들을 이 일의 배후로 끌어들이면 너무 게을러서 세부사항을 알아낼 수 없을 것이고 우리는 세부사항에 대해 생각하지 않고 그것에 익숙해졌기 때문에 그것을 다시 가져올 것"이라는 암호다.WP 사용 시:ACTRIAL은 실제적이고 측정 가능한 통계자료와 10년간의 지원 및 논란의 여지가 없는 이익을 가지고 있었다.심지어 이것이 시행된 프로젝트에서도 거의 극찬을 받지 못했고 반대도 여전히 존재한다.재판은 그렇게 부르지 않고 영구적으로 이 일을 끝낼 수 있는 방법일 뿐이다.토니발리오니 (토크) 05:07, 2019년 12월 13일 (UTC)[응답]

   WP 기억하기:AFT? :) --Izno (대화) 05:29, 2019년 12월 13일 (UTC)[응답]

6. 상기의 나의 논평을 들어 반대하라.우리는 먼저 그들의 사용을 위한 정책이 필요하다.바나몽드 (토크) 06:19, 2019년 12월 13일 (UTC)[응답]
7. 위에서는 배치를 지지했고, 여기서 나는 자동 종료/모라토리엄에 반대한다.누구든 적절한 경우 지체 없이 토론이나 RFC를 열 수 있고 열어야 한다.재판이 끝나기를 기다릴 필요는 없다.반면에 심각한 문제가 발생하지 않는다면 자동 유예는 의미가 없다.알제 (대화) 17:45, 2019년 12월 13일 (UTC)[응답]

   만약 그것이 정말로 비참하게 된다면, 그것을 끝내는 것은 어렵지 않을 것이다.그 목적을 위한 어떤 RFC도 빨리 합의를 이끌어 낼 것이다.만약 그것이 합의를 이끌어내지 못한다면, 그것은 지역사회가 그것이 유용하다는 것을 의미하며, 몇몇 사람들이 원하지 않더라도 그것이 머물 수 있는 타당한 이유가 된다.그래서 여기엔 어떤 부담도 없어.–암마르패드 (대화) 04:13, 2019년 12월 14일 (UTC)[응답]

   첫 번째 제안에서 대부분의 지원(중립성을 고려할 때 esp)은 1) 사용 사례 RfC, 2) 시험, 3) 영구 구현 RfC 형식을 선택한다.나는 처음 두 개를 바꾸는 것에 찬성하지 않는다.노즈백베어 (토크) 17:57, 2019년 12월 13일 (UTC)[답글]

8. 재판할 필요는 없다고 본다. -- 돌로타 (대화) 18:34, 2019년 12월 13일 (UTC)[응답하라]
9. 아니. 만약 당신이 그 근처에 있었다면, 당신은 시험결과에 대한 수집, 배포, 평가를 책임지는 사람이 정확히 누구인지를 확정하지 않은 채 시험중계 중인 것이 어떻게 보호조치를 변화시켰는지 기억할 것이다(이 제안도 마찬가지여서).만약 툴이 우리에게 잘 작동하지 않는 것 같다면 우리는 항상 두 번째 RFC를 가질 수 있고, 그때 그것을 끌 수 있다.비블브록스 (대화) 00:04, 2019년 12월 14일 (UTC)[응답]
10. 반대 나는 원래 재판에 찬성했지만 잠시 생각해 본 결과 WP 전체는 다음과 같다.ACTRIAL의 실패는 Special처럼 논쟁의 여지가 있는 도구에 대한 재판을 지원하기에는 아직도 너무 신선하다.차단. 이 도구를 사용할 수 있도록 하려면 처음에 제대로 사용할 수 있도록 합시다.OhKayeSierra (대화) 00:18, 2019년 12월 14일 (UTC)[응답]
11. 이럴 필요 없어, 그렇게 하면 더 큰 해가 될 거야.부분 블록을 활성화하고 실제로 사용한 후, 커뮤니티는 향후 RFC에서 그 사용을 평가할 수 있다.재판 기간이 있든 없든 이런 일이 생길 수 있다.하지만 시험 기간이 없다면 더욱 좋다. 그것이 우리가 진정한 이슈와 실제적인 함의를 볼 수 있는 기간이기 때문이다.시험 기간에는 (통제된 조건과 같이; 그것을 남용할 사람들은, 위키롤링 하는 사람들 등) 그 기간 내에 그렇게 하지 않을 것이다. 왜냐하면 아마도 그 기간은 심하게 감시되고 있기 때문이다. 그리고 그것은 진짜 문제를 가릴 것이다.–암마르패드 (대화) 04:13, 2019년 12월 14일 (UTC)[응답]
12. 아니, 만약 그들이 매우 문제가 있다고 입증된다면, 기능을 비활성화하는 새로운 RfC가 만들어질 수 있다. 다른 RfC를 계속/영구적으로 이동하도록 요구하는 것은 낭비처럼 보인다.— Xaosflux 17:08, 2019년 12월 15일 (UTC)[응답]
13. 반대는 필요없다고 본다. --말콤xl5 (대화) 20:10, 2019년 12월 15일 (UTC)[응답하라]
14. 위 절에서 나의 "아주 강한 반대"에 따라 반대하라.이반벡터 (/)^Talk_Edits 16:24, 2019년 12월 26일 (UTC)[응답]
15. 반대 - 너무 낮은 지분으로 재판을 받을 수 없다.~스왑~ 2019년 12월 30일 02:19 (UTC)[응답]
16. Mz7당 반대. --The Sand Doctor 03:42, 2020년 1월 5일 (UTC)[응답]
17. 반대, 그냥 계속해.숨막힐 (대화) 10:07, 2020년 1월 6일 (UTC)[응답]

중립(시행)

만약 그것이 크게 실패한다면, 우리는 재판을 기다릴 필요가 없다, 그러나 자동적인 종료/모사주의가 도움이 된다. 그렇지 않으면 당신은 그것을 끝내기 위한 합의가 필요하기 때문에 - 그것은 "증거의 부담"을 바꾸게 된다.노즈백베어 (토크) 17:56, 2019년 12월 13일 (UTC)[답글]

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

여기서의 합의는 새로운 부분 차단 정책의 일부가 될 것이다.

지원(강제)

1. 부분 블록(예: 페이지 금지)에 의해 편집 제한이 100% 집행될 수 있는 방식으로 쓰여진다면, 나는 그렇게 하지 않을 이유가 없다고 본다.* 삐삐 * 18:25, 2019년 12월 14일 (UTC)[응답]
2. 퍼 페퍼리.~ ToBeFree (토크) 20:52, 2019년 12월 14일 (UTC)[응답]
3. 편집 제한에 부분 블록에 해당될 수 있는 야심이 있는 경우 부분 블록을 사용하여 시행하거나(합의에서 특별히 달리 요구하는 경우는 제외), 기타 금지 사항으로 서야 한다. --qedk (t cc) 21:18, 2019년 12월 14일(UTC)[응답]
4. 더 단순하고 좁은 편집 제한 사항.더 복잡하고 광범위한 것은 이 도구로 관리하기가 상당히 어려울 것이다.SQL^{Query me!} 18:05, 2019년 12월 15일 (UTC)[응답]
5. 주제 금지 또는 제한 준수를 위한 자발적 합의가 실패한 후에만 조건부 지원이 중단적인 방식으로 실패함. 즉, 주로 이전에 합의된 제한 사항(분쟁 당사자의 강제된 주제 금지 또는 자발적 동의)이 위반된 후에만 실제로 관리자 또는 유사한 종류의 방해물에 대한 추가 불만을 유발한 경우n. 그리고 그러한 모든 도구들처럼, 징벌적이지 않은 예방적 수단, 즉 누군가가 그들의 주제 금지를 위반하겠다고 위협한다면, 그들이 원하는 모든 것을 비난하게 내버려 두되, 그들이 실제로 하지 않는 한, 제한적인 행동을 취하지 말라.그리고 만약 그들이 그렇게 한다면, 그리고 그들의 불평자들이 그 위반에 대해 신경쓰지 않는다면, 모든 수단을 동원해서라도, 또한 WP의 정신과 서한 안에서도 그것이 미끄러지도록 내버려두어라.IAR. EllenCT (대화) 23:12, 2019년 12월 15일 (UTC)[응답]
6. 향후 금지 및 제한에 적용되고, 구식 지원에는 소급하지 않는 경우에만 조건부 지원.또한 금지의 맥락에서 그것의 사용을 요약한 금지 또는 제한사항의 명시적 언어가 유용할 것이다. --Jayron32 16:13, 2019년 12월 16일 (UTC)[응답]
7. 일부 블록은 특정 페이지의 편집 제한을 집요하게 위반하는 경우와 같이 전체 블록보다 선호될 수 있다. --Malcolmxl5 (대화) 10:57, 2019년 12월 19일 (UTC)[응답]
8. 단순 블록용.그리고 사후적으로 사용되어서는 안 된다.캡틴 이크 ⚓ 07:47, 2019년 12월 20일 (UTC)[응답]
9. 분명히 지지.만약 우리가 그들을 가능하게 한다면, 이것은 가장 간단하고 명백한 사용 사례일 것이다. 왜냐하면 그것은 우리가 이미 사용하고 있는 제한의 형태에 대해 단순한 기계적 시행 이상의 어떤 것도 추가하지 않기 때문이다.한 가지 작은 주의사항은, 최소한 더 많은 논의가 없이 부분 블록의 역학에 맞게 기존의 편집 제한 정책을 변경해서는 안 된다는 것이다. - 그것들은 우리의 현재 광범위한 제한 시스템을 시행하는 하나의 도구일 뿐이지, 대체하는 것은 아니다. --조금 (대화) 10:10, 2019년 12월 22일 (UTC)[응답]
10. 첫 번째 질문에 대한 나의 답변에 따라 지지하라.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
11. 극히 조건부 지원 - 비반복적, 사전 예방적(더 넓은 합의를 필요로 하는 역방향) 및 제한적 금지 사항이 그러한 방식으로 작성되었을 경우에만(예: 5페이지의 TBAN은 실제로 페이지 금지를 방해함).만약 그것들 중 하나의 것이 본질적인 것으로 보이거나 합의에 의해 지지되지 않는다면, 이것은 확고하게 반대되는 것으로 보아야 한다.코백베어 (토크) 18:28, 2019년 12월 26일 (UTC)[응답]
12. 제한적 지원 이 옵션은 옵션이어야 하며, TBAN을 사용하려면 TBAN의 일부로 선언되어야 한다.많은 TBAN은 너무 광범위해서 관련된 모든 페이지를 나열할 수 없으며, 이 도구에 적합하지 않을 수 있으며, 커뮤니티는 항상 도구를 사용하지 않는 옵션을 가져야 한다.Tban을 위반할 경우, 일부 블록은 아직 합의되지 않은 정책에 따라 이 문제가 발생한 페이지에서 고소될 수 있다.DES 02:07, 2019년 12월 29일 (UTC)[응답]
13. 지원 - 이렇게 간단한 목적을 위해 부분 블록이 도구 상자의 도구가 되어서는 안 되는 이유를 모르겠다.~스왑~02:20, 2019년 12월 30일 (UTC)[응답]
14. 지원 - 아마도 내가 생각할 수 있는 부분 블록의 가장 간단하고 논란의 여지가 없는 사용일 것이다.말이 되긴 하지만, 비록 모든 TBANS에게는 효과가 없을 것이고, 누군가 TBAN을 받을 때마다 자동으로 사용하는 것은 좋은 생각이 아닐 것이다.PlatypusofDoom (talk) 05:16, 2020년 1월 2일 (UTC)[응답하라]
15. 조건부 지원 - 부분 블록이 편집 제한을 시행하는 데 매우 유용할 수 있다고 생각한다.다만 (주제가 얼마나 넓을 수 있는지) 주제가 아닌 페이지별로 한정된 경우에만 적용되어야 한다고 생각하고 소급해서 사용해서는 안 된다.--Rlin8 (인터뷰·연출) 06:15, 2020년 1월 2일 (UTC)[응답]
16. 지원 한 가지 주제에 대해 큰 기여를 하고 있지만 다른 주제(파달리즘이 아닌 전체 블록의 근거가 되는)를 파괴하는 경우 부분 블록은 정당화된다.드루이스테이 (대화) 20:15, 2020년 1월 4일 (UTC)[응답]
17. 제한된 지원.DESiegel, Jayron32, SQL이 이전에 쓴 것을 반향한다. --The Sand Doctor 03:41, 2020년 1월 5일 (UTC)[응답]
18. 파이퍼리당 지원.숨막힐 (대화) 10:08, 2020년 1월 6일 (UTC)[응답]
19. 지원하되 사례별로만 지원한다.요컨대, 관리자는 이 도구를 이러한 목적으로 사용하기 전에 대안을 찾아야 한다.긴 버전:만약 툴이 부작용을 일으키지 않고 금지를 시행했다면, 사용할 수 있지만, 그렇다고 해서 반드시 사용해야 하거나 심지어 주어진 경우에 사용해야 한다는 것을 의미하지는 않는다.도구를 사용하는 것이 금지사항을 위반할 가능성이 있는 사용자가 금지하지 못하도록 하는 경우, 도구를 사용해야 하며 그렇지 않으면 사용하지 않아야 한다.이것은 새로운 형태의 블록뿐만 아니라 기존 블록에도 적용된다.또한 차단되면 일반적으로 반환하고 싶은-반복하고 싶은-좋은-생산적인-편집자를-위키피디아-I-will-find-other-hobby 편집자로 바꾸는 등 원치 않는 부작용이 발생한다는 점을 기억하라.davidwr/(talk)/(contracts) 20:33, 2020년 1월 8일(UTC)[응답]

반대(강제)

1. 최악의 사용 사례.그것은 수 많은 위키 로위어링을 가능하게 할 것이며, 그 도구는 금지 조치를 시행하는 방법으로 개발되지 않았다.토니발리오니 (토크) 22:22, 2019년 12월 14일 (UTC)[응답]

   또한, 만약 그 문구가 정말로 위와 같다면, 나는 반대한다; 나는 위의 사례별 중립 섹션에 있다. 하지만 만약 이것이 "해야 한다"는 규칙이 될 것이라면, 나는 전적으로 반대한다. 왜냐하면 나는 기껏해야 이것이 "될 수 있다"는 규칙이 되어야 한다고 생각하기 때문이다.— Xaosflux 12:58, 2019년 12월 26일 (UTC)[응답]

2. 반대 - 매우 비현실적인; 사용자들은 한 개의 개별 페이지에서 금지되는 경우가 거의 없으며, 이것이 우리가 부분 블록으로 할 수 있는 전부다.만약 멀티블록이 실행된다면 이것은 재방문할 가치가 있을 수 있지만, 나는 그 경우에 더 넓은 주제 금지 내에서 상상할 수 있는 모든 페이지에서 누군가를 선제적으로 차단하는 것이 매우 실용적이라고 보지 않는다.페이지의 내용이나 코드에 의존하는 모든 블록은 남용에 대한 초대장이다.이반벡터 (/)^Talk_Edits 16:27, 2019년 12월 26일 (UTC)[응답]

중립(강제)

• 가능한 경우에만 해당(페이지: 참조):T202673의 제한사항).--GZWDer (talk) 21:40, 2019년 12월 14일 (UTC)[응답]
• 나는 이것이 단순히 예스나 아니오보다 더 뉘앙스로 묘사될 필요가 있다고 생각한다.사이트 금지가 있는 모든 편집자에게 항상 블록을 사전 적용하지는 않는다. 블록은 이전 중단으로 인해 이미 제자리에 있거나 편집자가 금지 사항을 위반할 경우 이를 강제하기 위한 옵션으로 보류할 수 있다.나는 부분 블록이 비슷한 방식으로 사용되었으면 좋겠어.그리고 다른 코멘트에서도 언급했듯이 모든 사례가 부분 블록으로 실질적으로 시행될 수 있는 것은 아니다. --RL0919 (토크) 22:03, 2019년 12월 14일 (UTC)[응답]
• 별로 실용적이지 않은 것 같아.편집자는 정치에서 금지된 주제라고 하자 – 페이지가 너무 많기 때문에 우리는 이것을 범주별로 해야 할 것이다.양말(IP 포함)은 범주를 쉽게 제거할 수 있으며, 우리는 설명할 수 없는 범주 제거의 의도를 알 길이 없다.하지만 우리가 이 문제를 해결할 방법을 찾거나 실제 시험 기간 동안 그렇게 큰 문제가 되지 않는다면 나는 지지할 것이다.NonymousUser (talk) 22:09, 2019년 12월 14일 (UTC)[응답]

  이름 없는 사용자, 부분 블록은 범주별로 차단되지 않는다.기능이 개발될 때는 이런 점을 고려했지만 오버헤드 때문에 떨어뜨렸다.SQL^{Query me!} 17:59, 2019년 12월 15일 (UTC)[응답]

• 케이스 바이 케이스, 정말 제약에 달려있다.템플릿과 모듈을 편집하는 것에 대한 예제는 이런 식으로 쉽게 시행될 수 있지만, 오렌지색에 관한 기사를 편집하는 것은 그리 유용하지 않을 것이다.— Xaosflux^Talk 17:06, 2019년 12월 15일 (UTC)[응답]

  더 읽고 다시 요약하자면, 나는 "해야 한다"가 "할 수 있다"로 바뀌면 대부분 이것을 지지한다.상황이 이러한 방식으로 가장 잘 처리될 것이라고 가정하면, 더 많은 재량에 개방될 수 있다.— Xaosflux 15:57, 2020년 1월 9일 (UTC)[응답]

• 동의해, 이 담요보다 더 많은 뉘앙스가 필요해. 예스/아니오.케이스 바이 케이스.– Levivich 20:46, 2019년 12월 19일 (UTC)[응답]
• 재량권에 맡겨야겠지만, 나는 일반적으로 리조트 1호선으로 반대한다.Wug·a·po·des 09:36, 2019년 12월 24일 (UTC)[응답]

토론(강제)

나는 누군가가 그들의 진술된 의도를 가지고 실행될 준비가 되어 있다고 자동적으로 가정되어서는 안 된다는 것에 동의하지만, 누군가가 실제로 블록을 부과하는 제한을 위반할 때까지 기다리는 것은 반작용이며, 따라서 실제로 징벌적 조치라고, 비록 예방적인 조치일 수도 있다.나는 편집자의 진술이 신빙성이 있다면 예방적 블록에 대한 고려가 정당하다고 생각한다.아이작 (토크) 23:39, 2019년 12월 15일 (UTC)[응답]

만약 누군가가 이미 금지된 주제였고 그들이 차단되지 않는 한 그 금지령을 위반하겠다고 협박하고 있다면, 나는 동의할 것이다.그러나 만약 그들이 단지 미래의 어느 시점에서 이 주제에 대한 잘못된 주장을 바로잡겠다고 다짐하고 있다면 그렇지 않을 것이다.우리는 앞으로 논쟁이 해결되어 주제 금지의 필요성이 이상적으로 완화되기를 바라며, 우리는 그러한 일이 열성적인 사람들이 그들의 위협을 실행하기 전에 일어나기를 바란다.주제 금지 조항이 없는 새로운 분쟁이라면, 행정부는 자발적 제한을 준수하기 위한 합의의 근저에 있는 분쟁이 해결된 것보다 실수의 혐의를 시정하겠다고 다짐하는 일이 더 빨리 일어날 것이라고 가정해서는 안 된다.나는 논쟁의 열기에 사람들이 그들이 완전히 배제하기 전에 다른 논쟁자들과 원만한 해결을 할 수 있을지에 대한 의구심의 혜택을 주고 싶다.비용 및 이점은 무엇인가?비용은 미미하며, 심리학적으로 이득은 상대적으로 엄청날 수 있다.EllenCT (대화) 00:31, 2019년 12월 16일 (UTC)[응답]

내가 말했듯이, 나는 편집자들이 그들의 진술을 끝까지 따를 것이라고 가정해서는 안 된다는 것에 동의하지만, 나는 그 맥락을 고려해야 한다고 생각한다. 그것은 과거의 행동과 그 진술의 테너를 포함한다.나도 블록이 반드시 자동이 되어야 한다고는 생각하지 않지만, 믿을 만한 진술에도 고려되어야 한다고 생각한다.아이작 (토크) 03:44, 2019년 12월 16일 (UTC)[응답]

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

여기서 대안은 지역사회의 합의와 관리자의 재량이다.여기서의 합의는 새로운 부분 차단 정책의 일부가 될 것이다.

지원(협의 필요)

1. 현재 부분 블록에 준하는 사회 편집 제한을 실시하기 위해서는 커뮤니티 컨센서스가 요구된다.* Papery * 21:02, 2019년 12월 15일 (UTC)[응답]

반대(협의 필요)

1. 부분 블록은 전체 편집-경전 블록에 대한 좋은 대안이 될 수 있으며 특정 사례에 대한 대규모 커뮤니티 토론이 필요하지 않아야 한다.~ ToBeFree (토크) 20:54, 2019년 12월 14일 (UTC)[응답]
2. 반대 – 지역사회가 승인한 제재를 시행하는 경우 부분 블록이 필요하지 않다.NonymousUser (talk) 21:59, 2019년 12월 14일 (UTC)[응답]
3. 반대 --qedk (t 桜 c) 08:36, 2019년 12월 15일 (UTC)[응답]
4. 아니, 하지만 그렇다고 해서 한없는 재량권이 있어야 한다는 뜻은 아니야.— Xaosflux 17:03, 2019년 12월 15일 (UTC)[응답]
5. 반대 커뮤니티 합의는 가이드라인에 도달해야 하며 개별 사례별로 요구되지 않아야 한다. --Malcomxl5 (대화) 20:51, 2019년 12월 15일 (UTC)[응답]
6. 관리 도구의 모든 사용을 소송할 필요성에 반대하거나, 필요하지 않다. --Jayron32 16:13, 2019년 12월 16일(UTC)[응답]
7. 반대 - 관리자가 만들 수 있는 다른 블록과 다르지 않다.관리자가 전체 블록 또는 부분 블록에 대해 도구를 잘못 사용하는 경우, 이는 서로 다른 문제다.러그넛 18:41, 2019년 12월 19일 (UTC)[응답]
8. 위와 같다.– Levivich 20:47, 2019년 12월 19일 (UTC)[응답]
9. 반대 이것은 관리자들이 다른 것들과 마찬가지로 사용할 수 있어야 하는 도구인데, 여기서 중요한 것은 커뮤니티 드라마와 관료주의를 덜 만드는 것이지, 그 이상은 아니다!캡틴 이크 ⚓ 07:44, 2019년 12월 20일 (UTC)[응답]
10. 반대 - 가치보다 더 많은 관료주의.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
11. 반대 - 지역사회 제재와 행정 도구 사이의 물꼬를 채우지 마십시오.그들은 서로 다른 짐승이다.이반벡터 (/)^Talk_Edits 16:30, 2019년 12월 26일 (UTC)[응답]
12. 반대하지 마라. 보통 블록보다 더 많이.관리자가 경고 후 편집 전쟁을 계속하거나 공공 기물 파손 행위를 계속하는 사람을 볼 경우, 해당 관리자는 게시판 토론을 차단할 수 있다.부분 블록도 동일하게 적용되어야 한다.전체 블록 이전에 공동체 논의가 필요하거나 예상되는 경우, 부분 블록 이전에 이루어져야 한다.WP:ADMINACCT가 적용된다.DES 02:12, 2019년 12월 29일 (UTC)[응답]
13. 반대 - 블록을 발행할 때 지역사회의 재량권이 필요하거나 보증되는 횟수는 0.0001% 미만이며, 의무사항은 아마도 그 시간의 50%를 달성할 수 없을 것이다.블록을 발행하는데 있어서 대체로 쓸모없는 측면이다.~스왑~ 2019년 12월 30일 02:22 (UTC)[응답]
14. 반대 행정/정책 재량에 따라야 하며, 제재가 발생하기 전에 비공식적인 합의가 나타날 수도 있다.공식적인 합의는 필요하지 않다. 만약 문제가 발생하면 그것은 동료의 검토를 받을 수 있다.드루이스테이 (대화) 20:18, 2020년 1월 4일 (UTC)[응답]
15. 반대한다. 개별 관리자가 정당화할 수 있다면 임의로 전체 블록을 부과할 수 있다. 부분 블록을 수행하기가 훨씬 더 어렵게 만드는 것은 비뚤어진 것처럼 보인다.경계선 상황에서 이는 단지 방해하는 사용자가 컨센서스 후프를 통해 점프하는 차단 관리자가 부분 차단을 하기보다는 완전 차단을 받는다는 것을 의미한다.~ 마즈카 02:15, 2020년 1월 5일 (UTC)[응답]
16. 반대해, 나는 이것에 대해 Xaosflux와 Mram의 의견에 동의해야 해.나의 반대는 한없는 재량권이 있어야 한다는 것이 아니라, 이것이 올바른 방법이 아니라는 것이다.--샌드닥터 03:38, 2020년 1월 5일 (UTC)[응답]
17. 여기서 쌓기를 반대하십시오.만약 우리가 관리자들이 정책에 따라 전체 블록을 넣을 재량권을 가질 수 있다면, 우리는 우리가 채택하는 정책에 따라 부분 블록으로 동일한 것을 할 수 있다고 믿을 수 있다. davidwr/(대화)/(contracts)/(contracts) 20:45, 2020년 1월 8일(UTC)[응답]

중립(협의 필요)

1. 공동체에 물어보는 것이 요구되어서는 안 되지만, 공동체는 확실히 그러한 제한을 뒤집을 수 있어야 하며, 부분 차단된 편집자들은 위키에서든 오프에서든 그러한 검토를 요청할 수 있을 것이다.관리자와 공동체가 동의하지 않는 퇴폐적인 경우, 관리자(관리자 커뮤니티, 기술적으로)는 권한이 있다. 이는 아스트로튀르드 필리버스터가 동종요법 관련 조항과 같은 벽으로 둘러싸인 정원을 보존하기 위해 거부권을 행사하는 것을 방지하는 역할을 해야 한다.EllenCT (대화) 23:19, 2019년 12월 15일 (UTC)[응답]

   커뮤니티 컨센서스는 모든 경우에서 일반 블록의 경우처럼, 부분 블록의 경우처럼, 여기서는 특별한 구분을 보지 않는다. --qedk (t 桜c) 21:20, 2019년 12월 16일 (UTC)[응답]

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

여기서 대안은 등록된 편집기와 IP 주소다.여기서의 합의는 새로운 부분 차단 정책의 일부가 될 것이다.

지원(IP 주소)

1. 만약 그런 일이 일어난다면 이것은 절대로 계좌에 사용되어서는 안 된다.다른 프로젝트 사람들과 대화하는 경우, IP 블록 전용이 가장 좋은 사용 사례다.토니발리오니 (토크) 16:19, 2019년 12월 15일 (UTC)[응답]
2. 위의 설명에 따르면 IP에 대한 이것의 유용성에 대해 언급한다.갤럽터 (pingo mio) 17:41, 2019년 12월 15일 (UTC)[응답하라]
3. 나는 이것을 타협적인 해결책으로 받아들일 용의가 있다.IP 주소의 특성상 IP 주소나 IP 주소 범위의 블록은 관련 없는 사용자에게 영향을 미칠 수 있으며, 부분 블록은 장애가 다른 기사로 확산될 가능성이 없는 특정 상황에서 부수적인 피해를 줄이는 방법이 될 수 있다.이러한 견해는 IP 어드레스 기여도보다 어떤 면에서 등록 사용자가 더 가치 있다는 어떤 정서와 무관하다.Mz7 (대화) 01:38, 2019년 12월 17일 (UTC)[응답]

반대(IP 주소)

1. 반대. 이런 식으로 부분 블록 사용을 제한해야 할 이유를 모르겠다. --RL0919 (대화) 22:05, 2019년 12월 14일 (UTC)[응답]
2. 반대 – 부분 블록 편집은 등록된 사용자에게 유용할 것이다.NonymousUser (talk) 00:17, 2019년 12월 15일 (UTC)[응답]
3. 반대 --qedk (t 桜 c) 08:35, 2019년 12월 15일 (UTC)[응답]
4. IP에 가장 유용할 것으로 생각되지만 여기서 명확한 규칙을 만드는 것에 반대하십시오. — xaosflux 17:01, 2019년 12월 15일 (UTC)[응답]
5. 이 툴은 IP에 매우 유용할 것이라고 생각하지만, 등록된 사용자에게도 유용할 것이라고 생각한다.SQL^{Query me!} 18:06, 2019년 12월 15일 (UTC)[응답]
6. 반대 등록되지 않은 편집자는 등록 편집자와 전혀 다르게 취급하지 않는다. --Malcomxl5 (대화) 20:53, 2019년 12월 15일 (UTC)[응답]
7. 왜 이런 일이 벌어져야 하는가?* Papery * 21:01, 2019년 12월 15일 (UTC)[응답]
8. 아니, 나는 이것이 목적 중 하나를 무너뜨릴 것이라고 믿는다.EllenCT (대화) 23:24, 2019년 12월 15일 (UTC)[응답]
9. 부분 블록이 IP의 중단을 방지하는 데 유용하겠지만, IP에만 국한되어야 할 이유는 없다.몽환 재즈 🎷 11:39, 2019년 12월 16일 (UTC)[응답]
10. 반대 이유? --Jayron32 16:14, 2019년 12월 16일 (UTC)[응답]
11. 등록한 사용자가 특정 기사에 대한 편집전을 중지하는 데 유용할 수 있는 도구의 제한에 반대한다.~ ToBeFree (토크) 13:21, 2019년 12월 17일 (UTC)[응답]
12. 반대 지금 당장은 IP 장애에 더 초점을 맞출 수 있지만, IP에만 국한되어서는 안 된다.러그넛 18:42, 2019년 12월 19일 (UTC)[응답]
13. IP와 등록된 편집기 모두에 유용하다.– Levivich 20:48, 2019년 12월 19일 (UTC)[응답]
14. 반대 위키피디아는 이미 IP에게 충분히 불친절하다.많은 편집자들을 소외시키고 선발함으로써 균형을 더 깨려고 할 필요가 없다.게다가, 내가 우연히 알게 된 등록 계좌도 많아.캡틴 이크 ⚓ 07:42, 2019년 12월 20일 (UTC)[응답]
15. 그렇게 되면 별로 쓸모가 없을 테니 반대해라.등록된 계정은 지역적 혼란을 야기할 수 있지만 다른 곳에서 유용할 수 있다.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
16. 반대 - IP도 계정이다.이반벡터 (/)^Talk_Edits 16:30, 2019년 12월 26일 (UTC)[응답]
17. 반대 나는 그러한 제한에 대한 정당한 이유가 없다고 본다.사실, 나는 이것이 등록된 계좌를 가진 더 유용한 도구가 될 것이라고 생각한다.DES 02:14, 2019년 12월 29일 (UTC)[응답]
18. 반대 나는 개인적으로 IP 사용자들에 대한 차별에 반대한다.~스왑~ 2019년 12월 30일 02:22 (UTC)[응답]
19. 반대 - 등록 사용자로부터 편집 전쟁이 많이 발생하며, 부분 블록을 IP로 제한하는 것은 그 유용성을 심각하게 저해할 것이다. --Rlin8 (인터뷰·수첩·수첩) 06:18, 2020년 1월 2일 (UTC)[응답]
20. 반대 나는 이 정책이 등록한 사용자들과 어쩌면 비상한 상황에서 관리자들에게도 이용되고 있는 많은 정당성을 볼 수 있다. 그들은 또한 그 정책에 관여해야 할 충분한 이유가 있다.드루이스테이 (대화) 20:20, 2020년 1월 4일 (UTC)[응답]
21. 반대하지만 다른 블록과 마찬가지로 블록이 꽉 찼든 부분적이든 누군가에게 블록을 씌우는 "인간/사회적" 측면에 유의하십시오.기본적으로 이 새로운 도구의 사용을 저해하지만 허용하고 있는 다른 곳에서 내 의견을 확인하십시오. davidwr/(대화)/(연락처) 20:47, 2020년 1월 8일(UTC)[응답]

중립(IP 주소)

다음의 논의는 의견요청을 기록한 기록이다.수정하지 마십시오.이 논의는 더 이상 수정해서는 안 된다. 도달한 결론의 요약은 다음과 같다.

여기서의 합의는 새로운 부분 차단 정책의 일부가 될 것이다.

지지대(조건부 차단 해제)

1. 물론, 우리는 보통 차단된 사람이 모든 종류의 제한을 "협상"하도록 내버려 둔다.— Xaosflux 17:02, 2019년 12월 15일 (UTC)[응답]
2. CAT에서는 이것이 유용한 도구라는 것을 알 수 있었다.RFU는 그렇지 않으면 생산적인 편집자들을 그 프로젝트에 복귀시키는 것을 돕기 위해서입니다.SQL^{Query me!} 18:03, 2019년 12월 15일 (UTC)[응답]
3. per xaosflux. --말콤xl5 (대화) 20:55, 2019년 12월 15일 (UTC)[응답]
4. --qedk (t 桜 c) 21:22, 2019년 12월 15일 (UTC)[응답]
5. 이것을 지지하는 것은 가능한 한 최선의 용도 중 하나인 것 같다.엘렌CT (대화) 20:18, 2019년 12월 16일 (UTC)[응답]
6. 지원팀에서는 그렇지 않은 이유를 알 수 없는데, 이는 사용자가 블록으로 이어지는 행동을 지속하지 못하도록 방지하면서 긴 블록(블록이 만료되기를 기다리지 않고 블록 해제 조건을 갖는 것이 더 타당할 만큼 충분히 긴)을 보장한 행동 때문에 차단된 사용자를 다시 불러오는 유용한 방법인 것 같다.물론 부분 블록은 특정 상황에서만 유용할 수 있지만, 만약 그것들이 다른 도움이 되는 편집자를 다시 데려오는 데 도움이 된다면, 그것들은 유용하다.나는 이것이 완전한 블록에서 아래로 내려가는 것으로 본다. 그것은 완전한 차단되지 않은 것이 보증되는지를 확인하는 데 사용될 수 있다.부분적으로 차단된 사용자는 쉽게 완전히 차단될 수 있으며, 발생할 수 있는 문제는 차단된 사이트 부분에 영향을 미치지 않았을 것이다.

   내가 가진 한 가지 예는 메인 스페이스에서 발생하는 심각한 이슈로 인해 편집자가 차단되었다면, 메인 스페이스에서 그들을 차단하는 부분 블록을 사용하여 "시행 기간"을 가질 수 있다는 것이다.이렇게 하면 드래프트 네임스페이스에서 여전히 기사를 작성 및 편집하거나 대화 페이지에 제안할 수 있다.그런 다음 "재판 기간"이 끝난 후 관리자는 사용자가 현재 부분적으로 차단될 수 있는지 여부를 확인하기 위해 그들의 기여도를 검토할 수 있다.이는 사용자가 드래프트 스페이스와 토크 페이지를 독자들이 덜 볼 수 있기 때문에 시험 중인 사용자가 할 수 있는 피해를 줄이는 데 도움이 될 수 있으며, 일단 문제가 주목을 받게 되면(평소처럼) 사용자는 여전히 차단될 수 있다.그것은 여전히 사용자가 교훈을 얻었다는 것을 보여줄 수 있게 해준다. 따라서 블록은 더 이상 예방할 수 없다.몽환 재즈 🎷 12:13, 2019년 12월 16일 (UTC)[응답]

7. 지원 이것은 합리적인 사용으로 보인다. --Jayron32 16:15, 2019년 12월 16일 (UTC)[응답]
8. 지원: 현실적이고 긍정적인 사용 사례.~ ToBeFree (토크) 13:23, 2019년 12월 17일 (UTC)[응답]
9. 당신은 이것이 필요하지 않다고 생각할 것이다. 왜냐하면 누구든지 차단되지 않은 사람은 기내에서 피드백을 받아 TBAN이나 ABAN 조건을 부분적으로 차단할 필요 없이 위반하는 것을 자제할 수 있기 때문이다.하지만 나는 관리자에게 혼란을 다루기 위해 도구 키트에 더 많은 도구를 제공하는 것에 찬성한다. 그래서 그렇다, 적절한 경우에 그것이 허용되어야 한다.– Levivich 20:51, 2019년 12월 19일 (UTC)[응답]
10. 내가 보기엔 지지가 합리적인 것 같아.퍼들럼 ^2.0 16:15, 2019년 12월 22일 (UTC)[응답]
11. 합리적인 지원.서사시게니우스 (토크) 18:28, 2019년 12월 24일 (UTC)[응답하라]
12. 지원 - 이것이 좋은 경우, 그리고 편집자들이 그들의 우발적인 문제 중 일부를 피할 수 있도록 허락하는 경우를 볼 수 있다. 노즈백베어 (토크) 18:29, 2019년 12월 26일 (UTC)[응답]
13. 지원 합리적인 사용 사례, 편집 제한의 특별한 사례.그런 경우처럼 이를 활용하기 전에 구체적인 정책이 마련돼야 한다.DES 02:15, 2019년 12월 29일 (UTC)[응답]
14. 조건부 차단을 강제할 수 있는 완벽한 도구를 지원하십시오.~스왑~ 2019년 12월 30일 02:22 (UTC)[응답]
15. 지원 - 업무 중단을 줄이는 데 도움이 되는 합리적인 사용PlatypusofDoom (talk) 05:20, 2020년 1월 2일 (UTC)[응답]
16. 그것은 문제가 있는 주제에서 중단을 중단하는 동시에 다른 곳에 건설적으로 기여할 수 있는 기회를 제공하는 훌륭한 방법이 될 수 있다.물론 이는 기사 공간에만 국한되지 않을 것이며 일시적이거나 무기한일 수도 있다.드루이스테이 (대화) 20:22, 2020년 1월 4일 (UTC)[응답]
17. Xaosflux와 Marm당 지원. --The SandDoctor 03:35, 2020년 1월 5일 (UTC)[응답]
18. 지지하지만 나는 "반대" 섹션의 Pppery에 동의한다. 이 섹션은 현재 정책에서 사실상 "편집 restricitons"를 복제한다.그것은 또한 WP에 이미 함축되어 있는 것처럼 보인다.콘둔블록은 주요 제안이 통과되어야 한다.나는 이 문제가 WP에 성명서를 추가하는 것 이상으로 축소되어도 괜찮다.블록 해제 요청이 해당 블록의 범위를 엄격히 좁히는 다른 블록으로 교체될 경우 조건이 적용될 수 있다는 CondUNBLOCK.즉, 하나 이상의 부분 블록이 전체 블록을 대체할 수 있거나, 하나 이상의 부분 블록이 하나 이상의 부분 블록을 대체할 수 있다는 것을 의미하며, 편집자가 이전에 할 수 있는 모든 것을 할 수 있다면, 그는 여전히 할 수 있다.나는 어떤 결과적 변화의 지속시간이 기존 지속시간보다 길어질 수 없다고 말하고 싶지만 이는 WP와 반대되는 것이라고 본다.UNBLOCK은 블록이 더 빨리 만료되더라도 최대 1년까지 조건을 연장할 수 있게 해 준다.WT에 대한 설명을 제안한다.차단 정책. davidwr/(대화)/(공모) 21:04, 2020년 1월 8일(UTC)[응답]
19. 지지자들은 부분 블록이 최후의 수단인 전체 블록보다 확실히 더 나은 선택이라고 느낀다.이제 우리가 건설적으로 기고하는 것은 다른 곳에 기고하는 부분적인 블록을 다루고 있는 것은 종신 편집자들이다.마법사의 파라오 (대화) 11시 50분, 2020년 1월 10일 (UTC)[응답하라]

반대(조건부 차단 해제)

1. 이것은 현재 주어진 "편집 제한 강화"와 효과적으로 중복된다.* Papery * 21:_{it has begun...}00, 2019년 12월 15일 (UTC)[응답]

   @Papery: 조건부 차단 해제란 편집 제한의 하위 집합이다.따라서, 가정적으로, 만약 그 제안이 실패하고 이것이 통과된다면, 조건부 언블록만이 부분 블록을 받을 수 있다는 것을 의미한다. --qedk (t 桜 c) 21:07, 2019년 12월 15일 (UTC)[응답]

   나는 계속해서 반대한다 -- 조건부 차단 해제도 다른 제한사항과 다르지 않다고 생각하므로, 그들이 특별하게 규정되는 것에 반대한다.* Papery * 21:09, 2019년 12월 15일 (UTC)[응답]

2. 시행 중인 밀짚 여론조사에 의하면 내 의견에 반대한다.이반벡터 (/)^Talk_Edits 16:28, 2019년 12월 26일 (UTC)[응답]

   Ivanvector, 일반적으로 CAT:RFU, 우리가 발견한 문제는 사용자:BobsWidgets는 BobsWidgets 페이지를 생성하거나 편집한다.편집자에게 편집 계획이 무엇인지 물어보는 것이 앞으로 나아갈 수 있는 방법일 때가 많은데, 봅스위젯만 있다면 차단 해제 요청에 대한 대답은 대개 '아니오'이다.Unblock 대기열을 사용하는 사람으로서, 나는 이것이 이러한 유형의 Unblock 요청뿐만 아니라 더 간단한 COI/UPE 상황에도 큰 도움이 된다는 것을 알 수 있었다.SQL^{Query me!} 03:56, 2019년 12월 27일 (UTC)[응답]

   @SQL: 우리는 이미 BobsWidgets를 만들거나, 이미 존재하는 경우 반보호를 통해 해결할 수 있다.그리고 SPI에서의 경험으로부터, 어떤 방법으로든, COI/UPE라면, 그들은 단지 초안을 작성할 것이다.Bob Widgets 또는 Bob Widgets, Bob's Widgets, Bob Widget Co, Bob Widget Company, Widgets(Bob) ...라는 아이디어를 얻으십시오.부분 블록은 이것을 다루지 않는다.어쨌든 올바른 대응은, 편집자가 원하는 모든 것이 (관심 충돌이나 유료 편집 규칙에 반하는 편집만으로) 정책을 위반하는 것이라면, 그것을 차단해 두는 것이다.이반벡터 (/)^Talk_Edits 14:21, 2019년 12월 27일 (UTC)[응답]

중립(조건부 차단 해제)