위키백과:주석/템플릿 편집기 사용자 권한 요청

제안: 신뢰할 수 있는 템플리트 코더가 사전 예방적 이유로 완전히 보호되어 있는 템플리트, 모듈을 편집하고 통지를 편집할 수 있는 새 사용자 권한을 만드십시오. 이 RFC는 2013년 10월 11일에 폐쇄될 예정이다. Equazcion 10:07, 2013년 9월 11일 (UTC)

배경

이 제안에 대해 다음과 같은 논의가 선행되었다.

• 이 관리자의 게시판 스레드
• 관리 요청: 스님을 트라피스트하다.

위키피디아의 가장 보편적인 템플릿은 일반적으로 완전히 보호된다. 그들은 한 페이지를 편집함으로써 악의적이거나 알려지지 않은 사람들이 한번에 수천 페이지에 부정적인 영향을 미칠 수 있도록 하기 때문에 고위험군으로 간주된다. 따라서 고사용 템플릿은 사전 예방 조치로서 체계적으로 완전하게 보호된다. 어떤 페이지가 완전히 보호될 때, 관리자는 페이지를 편집할 수 있는 유일한 편집자다.

완전한 보호는 압도적인 논쟁의 상태를 보여준 기사들에게는 이상적인 임시 해결책이지만, 템플릿에 대한 영구적인 예방책으로는 덜 이상적이다. 코딩 템플릿에 적성을 보이고, 업무를 수행하면서 지역사회의 신뢰를 얻은 많은 편집자들은 반드시 관리자일 수도 없고, 관리자가 되는 것에도 관심이 없을 수도 있다.

비관리자는 관리자가 자신을 대신하여 제정할 수 있도록 완전히 보호된 템플릿에서 편집을 요청할 수 있는 능력이 있지만, 이를 안정적으로 수행할 수 있는 시간과 필요한 기술을 갖춘 관리자가 상당히 부족하다. 코디네이터들은 또한 이 추가 단계를 단순한 짜증보다 더 많이 발견하는 경향이 있다. 기술직 종사자는 실무경험을 중시한다는 점에서 기술직 종사자에게 대체로 보람을 느낀다. 많은 사람들은 결국 완전히 보호된 템플릿에 대한 작업을 완전히 피함으로써 다른 사람이 자신을 대신하여 편집을 제정하도록 설득하기 위해 만들어진 논란의 여지가 없는 편집 요청을 구두로 표현하지 않아도 되는 것을 선택하게 된다.

현재 템플릿 노하우를 가진 신뢰할 수 있는 편집자만 출입할 수 있는 조치가 없어 일부 편집자는 트라피스트 스님의 RfA처럼 관리직 신청에 의존하고 있다. 최적의 해결책은 사용자 권한을 부여하여 이 편집자가 사용량이 많은 템플릿에 액세스할 수 있도록 하는 것이라는 각 측의 많은 의견을 참고하십시오.

프로포즈

지식 있고 책임감 있는 템플릿 코드 사용자로서 커뮤니티의 신뢰를 얻은 편집자가 사전 예방적 이유로 완벽하게 보호되어 있는 템플릿, 모듈 및 통지를 수정할 수 있는 새 사용자 권한을 만드십시오.

허가

이 권한은 기술적 수단을 통해 템플릿 및 모듈 네임스페이스의 페이지와 편집 통지에 제한된다.

템플리트 및 모듈 네임스페이스 내에서만 예방적 이유로 현재 완전히 보호되고 있는 페이지의 보호 수준은 새로 생성된 보호 수준으로 변경된다. 이 새로운 보호 수준이 있는 페이지는 새로운 템플릿 편집기 사용자 권한 그룹뿐만 아니라 sysops 이상에서도 편집할 수 있다. 이런 식으로, 새로운 권리 그룹은 기술 수준에서 네임스페이스 제한을 시행할 것이다. 예를 들어, 그들이 기사나 프로젝트에서 완전히 보호된 페이지("Wikipedia:")를 편집하는 것은 불가능할 것이다. 그러면 실제 전체 "동기식" 보호는 템플릿 및 모듈 네임스페이스에서 특별한 방법으로 사용할 수 있으며, 필요에 따라 관리자를 제외한 모든 사용자가 일시적으로 편집을 허용하지 않을 수 있다.

고위험 템플릿을 구성하는 것에 대한 표준은 이 새롭게 만들어진 보호 수준과 권리 그룹에도 불구하고 변하지 않고 확장되어서는 안 된다는 것을 이해해야 한다. 많은 편집자들이 이 권리 그룹이 존재하기 때문에 여전히 편집 권한을 가지고 있다는 이유로 이 개발이 위키백과의 덜 위험한 템플릿을 더 많이 보호할 수 있는 사실상의 라이선스를 허가하지 않도록 경계해야 한다. 템플릿 편집기 사용자 권한은 일반 편집기 모집단에 대해 더 많은 템플릿이 편집 불가능하게 되는 결과를 초래해서는 안 된다.

사용하다

편집자는 유지보수를 수행하고, 합리적인 편집 요청에 응답하며, 템플릿, 모듈 및 통지에 대해 단순하고 일반적으로 논란의 여지가 없는 다른 편집을 할 수 있도록 이 권한을 행사할 수 있다. 또한 시험 샌드박스에 대한 편집이 처음 이루어지며, 다른 정보 편집자들 간의 합의뿐만 아니라 기술적 신뢰성이 확립된 후, 그들은 더 복잡하거나 논란이 많은 편집들을 제정할 수 있게 될 것이다.

요청 중

편집자는 위키피디아를 통해 이 허가를 요청할 수 있다.이 제안서 통과 시 생성되는 권한/템플릿 편집기 요청.

부여지침

새 템플릿 편집기 사용자 권한은 관리자가 부여한다. 관리자는 다음과 같은 일반 지침뿐만 아니라 편집자의 템플릿 기여 가치에 대한 자체 재량적 평가를 사용한다.

1. 편집자는 적어도 1년 동안 등록된 위키백과 사용자여야 한다.

2. 편집자는 적어도 1,000개 이상의 전체 편집을 했어야 한다.

3. 편집자는 템플릿 네임스페이스를 150개 이상 편집해야 한다.

4. 편집자는 적용하기 전 6개월 동안 행동 블록이나 3RR 위반이 없어야 한다.

또한 편집자는 위험성이 높은 템플릿 수정을 다룰 때 요구되는 주의와 책임에 익숙할 뿐만 아니라 권리에 대한 필요성을 입증했어야 한다.

5. 편집자는 최소 3개의 완전 보호된 템플릿의 샌드박스 버전을 작업했어야 한다.

6. 편집자는 완전히 보호된 템플릿에서 적어도 5개의 중요한 편집을 요청하고 성공적으로 제정했어야 한다.

이 절의 항목은 지침일 뿐이다. 관리자는 고위험 템플릿 책임을 처리하는 데 있어 편집자의 역량에 대한 다른 증명서를 대체할 수 있다.

해지기준

다음 각 호의 어느 하나에 해당하는 경우에는 관리자가 절차나 사전통지 없이 언제든지 사용권을 취소할 수 있다.

1. 편집자는 먼저 합의점을 결정하지 않고 보호된 템플리트에 논란의 여지가 있는 편집을 수행하는 패턴을 보여주었다.
2. 편집자는 보호된 템플릿을 편집할 때 충분한 주의를 기울이지 않아 페이지에 심각한 오류가 나타나는 패턴을 보였다.
3. 편집자는 그 허락을 이용하여 논쟁에서 우위를 점했다.
4. 편집자는 노골적인 공공 기물 파괴 행위를 하기 위해 허가를 이용했다.
5. 편집자는 12개월째 활동을 하지 않고 있다.

또한 편집자의 요청에 따라 권리를 즉시 제거할 수 있다.

지원

1. 베티 로건(토크). 내게는 합리적인 제안인 것 같다. 신뢰할 수 있는 커뮤니티 구성원이 매번 관리자에게 달려가야 할 이유는 없다. 베티 로건 (토크) 10:24, 2013년 9월 11일 (UTC)[]
2. DJ 네, 벌써 제정할 수 있을까? 나는 이 사이트에서 유능한 코더가 관리자여야 할 이유를 모르겠다. 신뢰만 있으면 충분하다. —DJ (대화 • 기여) 10:57, 2013년 9월 11일 (UTC)[]
3. 프람. 그것을 제거하는 이유는 좀 더 확장될 필요가 있을 수 있고, 그것을 허가하는 요건은 아마도 약간 느슨해졌을 수도 있지만, 이것은 기본적으로 건전한 접근법이다. 프람 (토크) 11:01, 2013년 9월 11일 (UTC)[]
4. 사용자가 WP에서 성공할 수 있는 원격 기회를 갖기 위해 필요한 최소 표준:RFA는 위키 분석기 기능 또는 루아 코딩에 대한 지식을 보유해야 하는 요건의 완전한 결여와 결합되어, 이 사용자는 오랫동안 지연된 도구로, 기술적으로 숙련된 편집자가 우리의 규칙/정책/지침서에 대한 능력과 적절한 이해를 보여주었지만, 책임과 관련된 책임을 원하지 않는 편집자에게 부여할 권리를 갖게 된다.d 전체 관리자 권한을 가진 경우, 전체 도구 세트를 필요로 할 정도로 자주 편집하지 않거나 잠재적 관리자의 삐걱거리는 깨끗한 태도를 기대하지 않는다. 특정 템플릿이 신뢰할 수 있고 경험이 풍부하며 숙련된 편집자라도 너무 섬세하거나 가시성이 높다는 우려가 있다면 새로운 수준의 보호가 만들어질 수 있을 것이다. 편집 전쟁이 발발할 때도 적용할 수 있다. - 플로이드^τ_¢ 11:03, 2013년 9월 11일 (UTC)[]

   플로이드어: 참고로 이 제안에 따르면, 이 그룹에 대한 접근은 완전 이하의 새로운 보호 수준을 통해 허가될 것이므로, 템플릿이 이 새로운 사용자 그룹에 대해 너무 민감하다고 간주될 경우 일반적인 전체 보호를 여전히 사용할 수 있다. Equazcion 11:20, 2013년 9월 11일(UTC)

5. 자주 카테고리 순찰:위키피디아는 편집 요청을 보호했고, 나는 고위험 템플릿을 편집하기 위해 신뢰하지만 RfA를 받고 싶지 않거나 통과하는데 필요한 광범위한 경험을 가지고 있지 않은 편집자들이 많이 보인다. 현재로서는 편집 요청을 적극적으로 순찰하는 관리자가 두세 명밖에 되지 않으며, 우리 모두가 한 시간 동안 사라진다면(혹은 우리 자신의 템플릿과 모듈 작성에 몰두하게 되면), 요청에 응답하기 며칠 혹은 심지어 몇 주가 걸릴 수도 있다. 제안된 사용자 권리는 이 상황을 훨씬 더 효율적으로 만들 것이다. — Mr. Stradivarius 11:06, 2013년 9월 11일 (UTC)[]
6. 점묘사. 만약 이것이 기술적으로 타당하다면, 나는 이 제안의 단점을 볼 수 없다. 전통적인 RfA를 수행하지 않고 전체 관리자 권한을 부여하는 것보다 훨씬 더 나은 접근방식: 후보자에게 더 간단하고, 덜 요구되며, 지역사회에 덜 위험하다. - 포인트리스트 (대화) 11:12, 2013년 9월 11일 (UTC)[]

   나는 방금 아칼라마리의 반대 의견을 읽었다. 나는 그 입장을 이해하지만 이것이 "비관리자에 대한 여러 가지 혼란스러운 보호 사용자 권리를 갖기 위한 발판"이 되기 보다는 일회성으로 본다. 그러나, 만약 이 제안이 일회성이 아니라면, 나는 그것이 어느 정도 단점이 될 것이라는 것에 동의한다. - 포인트리스트 (토크) 16:20, 2013년 9월 13일 (UTC)[]

7. 내가 보기엔 좋아 보인다. 세부 사항들을 조율해야 한다. 하지만 나는 기술자들에게 그 전에 이것이 정말로 가능한지 말하라고 권하고 싶다. 페리돈 (토크) 11:22, 2013년 9월 11일 (UTC)[]
8. 아마 모든 숙련된 편집자는 위키 마크업에 대한 기본적인 지식을 가지고 있을 것이다. 하지만 루아나 파서 기능은 다른 이야기일 것이다. (코드는커녕 루아도 거의 읽을 수 없다!) 경험이 많은 코딩가들은 관리자일 필요가 없다. ~HueSatLum 11:58, 2013년 9월 11일 (UTC)[]
9. 다른 위키[1]에 대한 관리자로서의 경험을 통해, 템플릿 변경은 사용자의 변경에 어떠한 분명하고 즉각적인 부작용 없이, 그러한 변경이 완전히 선의로 이루어졌고 겉으로 보기에 정책을 준수하는 것처럼 보일 때에도, 말할 수 없는 성능 문제를 야기할 수 있다는 것을 나는 잘 알고 있다. 더욱이 필요한 기술력은 일반적으로 RfA에서 시험하는 외교 및 정책 이해 능력과 약간의 중복만 있을 뿐이다. 한 가지 주의할 점 - 내 템플릿 편집의 대부분은 WP와 관련이 있다.일반적으로 이 RFC가 해결해야 할 문제와 무관한 DYK, 그리고 나는 그 자리에 나만이 있는 것이 아닌가 의심한다. 리치333 13^(cont):11, 2013년 9월 11일 (UTC)[]
10. 사실, 나는 그것이 편집 보호된 요청(항상 논란이 없는(일반적인 등)으로 작업할 수 있도록 허용하는 것으로 확장되는 것을 보고 싶지 않다. ~Charmlet 13:31, 2013년 9월 11일 (UTC)[]
11. 확실히 올바른 방향으로 한 걸음 나아간다. 사용자들을 신뢰하지 않을 수 없는 지역사회에 대한 신뢰가 크게 부족하고 관리자 도구에 대한 보호주의가 심하기 때문에 완전히 새로운 사용자 권리를 만들어야 한다는 점이 실망스럽다.별일 아닌 일 아니야. 쿠미오코(토크) 13:32, 2013년 9월 11일 (UTC)[]

    나는 이것으로부터 어떤 해악도 볼 수 없다고 본다. Jackmcbarn (대화) 14:57, 2013년 9월 11일 (UTC) 반대 방향으로 변경됨, 아래를 참조하십시오. Jackmcbarn (대화) 12:33, 2013년 9월 12일 (UTC)[]

    @Jackmcbarn: 투표하는 것을 잊지 마십시오. — PinkAmpers&^{(Je vous invite à me parler)} 07:15, 2013년 9월 15일 (UTC)[]

12. 나는 이 제안으로 인해 반대한다는 전제 하에 이곳에 왔는데, 이는 사람들이 행정적인 장애물을 받아들이기 더 어렵게 만든다. 우리는 더 많은 행정가들을 더 많이 원한다. 그러나: 제안된 추가 보호 계층은 신속한 수정의 주장과 함께 나를 지지하도록 만들었다. 아가토클레아 (대화) 15:40, 2013년 9월 11일 (UTC)[]
13. 관리자에 대한 기술과 기술적 업무는 매우 다르다. 내가 믿는 몇몇 사람들은 다른 한 사람은 하지 않고 한 사람은 하지 않을 것이다. 이에 대한 대안은 샌드박스 메인 템플릿 모델로 반보호 또는 현상유지를 위해 일부 고가용 템플릿에 대한 보호를 내리는 것이다. 템플릿 경험이 없는 편집자가 중요한 템플릿을 정보 없이 편집할 수 있기 때문에 일부 템플릿에는 반 보호 기능이 너무 낮다. 샌드박스 모델도 좋고 이런 상태에 해당하는 편집자라면 샌드박스의 모든 주요 변화를 먼저 시험해 보길 기대한다. 일부 문구가 변경되는 사소한 수정은 검토 과정이 필요하지 않다. 또한 TemplateData 시스템은 이 상태에 대한 새로운 용도를 도입했다. 템플릿의 TemplateData 문서를 업데이트하려면 null 편집을 필요로 하며 이러한 추가 템플릿 데이터 중 상당수는 관리 비트가 없기 때문에 작업을 완료할 수 없다. null 편집을 기다리는 동안 올바른 숫자 템플릿이 사용되었음.--사용자:Salix alba (토크): 2013년 9월 11일 16:16 (UTC)[]
14. 자격 있는 지원 나는 개념과 자격 등을 지지하며, 이를 그대로 구현하기 위한 합의를 차단하지는 않겠지만, 제안서의 기준과 다른 항목들은 내가 원하는 것이 정확히 아니다. 예를 들어, 나는 편집자들이 관리자들이 걸레를 사용할 때 더 높은 기준에 따라 관리자들이 유지되는 것처럼, 그들이 더 높은 기준에 따라 유지될 것이라는 것을 편집자들에게 상기시키는 대담한 진술을 덧붙이겠다. 우리는 그것이 시행된 후에 기준을 수정하는 것에 대해 논의할 수 있다. 또한 다른 위키피디아가 사용자 권한을 위임하는 데 더 많은 옵션을 가질 수 있도록 하기 위해 이 제안서의 기술적 측면을 수행하는 다른 방법에 대한 아래 내 토론 항목을 참조하십시오. davidwr/(토크)/(contracts) 17:09, 2013년 9월 11일(UTC)[]
15. 나는 요약한 대로 사용자 권리를 만드는 것을 지지한다. 템플릿 편집 방법(많은 관리자 이상)을 알고 있는 기술 기술을 가진 편집자가 다수 있는데, 이들은 신뢰할 수 있는 방식으로 기본 페이지를 편집하고 삭제하지 않는다. 조금 느슨해 보이는 교부절차에 대해 좀 더 논의를 했으면 좋았을 텐데, 진행하면서 좀 더 조여줄 수 있을 것 같아. --SP힐브릭(Talk) 18:14, 2013년 9월 11일(UTC)[]
16. 지지하다. 이 네임스페이스는 (내가 그들을 탓하는 것도 아니고) 현 관리자로부터 그다지 많은 관심을 받지 못하는 곳이며, 기술 노하우 외에 기본적인 갈등 해결 기술만 필요한데 이러한 분야에서 숙련된 편집자들이 RfA 과정을 거쳐야 하는 것은 매우, 매우 실망스럽고, 좌절스럽다.템플릿을 개선하는 방법을 아는 데 필요한 dge와 선견지명이 필요하다. 나는 이 공간에서 그들의 작업을 즐기는 편집자들이 이미 부담스럽고 바쁜 관리 풀에 세금을 부과하지 않고 더 효과적으로 업무를 수행할 수 있도록 격려하는 아이디어가 좋다. I, JethroBT 18:30, 2013년 9월 11일 (UTC)[]
17. 지원 편집 요청 목록을 불필요하게 막아버리는 것과 커뮤니티(나 포함)가 불편해 보이는 단일 목적의 RfA 사이에서 좋은 절충안을 제시한다. Miniapolis 19:29, 2013년 9월 11일 (UTC)[]
18. 기본적으로 사용자당 지원:플로이드의 취소 기준에서 나는 "실행한" 패턴이 "실행한" 것이 되고 "실패한" 패턴이 "실패한" 것이 되는 것을 선호한다. 그러나 그러한 세부사항에도 불구하고, 나는 이것이 프로젝트에 도움이 될 것이라고 생각한다. --Stfg (대화)20:53, 2013년 9월 11일 (UTC)[]

    Stfg 내가 그 초안을 기억한다면, "has"라는 답사보다 "pattern"을 선택한 이유는 하나의 (잠재적으로 사소한) 실수를 방지하는 것이 사용자 권리를 제거하기 위해 무력을 동원하는 피치포크 몹(또는 헌신적인 반대자)의 근거였다. 호서 (토크) 21:08, 2013년 9월 11일 (UTC)[]

    그렇구나, 고마워. 나는 피치포크 폭도들이 이 다소 난해한 권리를 없애는 데 그렇게 흔하거나 효과적일 것이라고 생각하지 않는다; 그것은 블록/언블록 버튼과 같지 않다. 또한, 다른 쪽에서는 패턴이 구성되기 전에 어디까지 갈 수 있는지에 대해 위키리듬을 할 수 있는 범위가 있다;) 그래도, 어느 쪽이든, 이것은 내 지지에 영향을 주지 않을 것이다. --Stfg (대화) 21:17, 2013년 9월 11일 (UTC)[]

19. 관리 도구 세트를 템플릿 편집에만 사용하려는 경우에도 신뢰할 수 있는 사용자에게 관리 도구 세트에 대한 액세스 권한을 부여할 수 있다. 그러나 그러한 RFA는 불필요한 논란을 일으키기 때문에 그것을 위한 분리 시스템을 만드는 것은 많은 이치에 맞는다. 개인적으로, 나는 편집 보호 요청을 이행하는 것이 불편하다고 말할 수 있다. 내가 그 변경이 무엇을 할 것인지 완전히 이해하지 못한다면, 그리고 더 복잡한 템플릿은 매우 어려울 수 있다. 몬티₈₄₅ 21:27, 2013년 9월 11일 (UTC)[]
20. 이와 같은 특정 분야에서만 일하기를 원하는 사람에게 풀키트를 나눠줄 이유가 없다고 본다. 툴의 사용이 문제(현재 풀 세트로는 불가능한 것)로 입증될 경우 취소의 용이성과 결합하여 이를 좋은 해결책으로 만든다. 2013년 9월 11일 21:36(UTC)[]
21. 나는 구체적인 허가/제거 기준이나 세부사항은 신경도 쓰지 않는다; 그것들은 나중에 해결/수정될 수 있다. 그리고 나는 분명히 지금 기준을 수정하는 것을 제안함으로써 이 아이디어를 죽이는 위험을 무릅쓰지는 않을 것이다. 나는 단지 문제가 된 RFA를 지지했을 뿐이다. 왜냐하면 이것은 현재 존재하지 않기 때문이다. 그래서 나의 지지는 우리가 이 옵션이 필요하지 않다는 증거로 받아들여져서는 안 된다. 이게 더 좋다. --Floquenbeam (대화) 22:00, 2013년 9월 11일 (UTC)[]
22. 최근 RfA와 다른 곳에서 발생한 문제를 고려할 때 분명히 필요함. 멋진 제안서 btw. 호빗 (토크) 22:21, 2013년 9월 11일 (UTC)[]
23. 플로이드식당 지원, 다양한 이유로 관리자가 되지 않는 템플릿을 편집할 수 있는 편집자가 많다. 이것은 단지 프로젝트에 순이익이 될 수 있다. AIRCON (토크) 22:57, 2013년 9월 11일 (UTC)[]
24. 나는 이 제안을 매우 열성적으로 지지한다. 여기서 많은 선을 행할 수 있지만, 다른 관리 도구를 가지고 있어서는 안 되는 사용자들이 있다는 것은 매우 분명하다. 지금까지 반대 의견을 읽었는데, 균형적으로 보면 아무런 단점도 보이지 않는다. --Tryptofish (토크) 00:11, 2013년 9월 12일 (UTC)[]
25. 지원 - 위의 지원 대부분에 동의하십시오. 이 접근방식은 숙련된 코더가 템플릿 작업을 할 수 없도록 하는 실제 문제를 다루며 샌드박스와 테스트의 중요성을 강조함으로써 모범 사례를 장려한다. 이 제안은 콘텐츠 불일치에 대한 보호를 별도로 취급한 후 높은 가시성 또는 높은 사용량에 대한 보호를 포함한 합리적인 안전장치를 허용한다. 그것은 일부 보호된 템플릿에 가장 익숙한 것과 같은 현재 상황의 많은 실제 문제를 해결한다. 테스트를 하더라도 템플릿의 비정상적인 사용과 관련된 버그가 여전히 누락될 가능성이 항상 있다. 현재 상황에서 편집 요청을 승인하는 관리자가 템플릿에 익숙하지 않을 수 있으므로, 어떤 버전이 더 오래 존재하는지 소개하는 문제를 신속하게 해결할 수 있다. 이는 요청된 편집을 적용한 관리자가 템플릿이나 루아 코딩에 능숙했더라도, 특정 템플릿의 세부사항과 사용에 익숙하지 않은 사람이 구현의 모든 부분에 대한 이유를 이해하지 못할 수 있다. 특정 템플리트의 설계와 작성에 관여하는 신뢰할 수 있는 편집자들이 스스로 변경을 할 수 있도록 허용함으로써, 그들은 또한 그러한 버그를 훨씬 더 빨리 고칠 수 있다는 것을 의미한다. 마지막으로, 사용량이 많은 템플릿을 보호하면서 언급된 다른 사람들이 오늘날에는 그러한 템플릿을 작업하거나 만든 편집자들을 소외시킬 수 있다. 내가 개인적으로 편집 속도를 늦춘 이유 중 하나는 내가 열심히 작업한 (그리고 막 재설계를 하려던) 일부 템플릿이 사소한 공공 기물 파손에 부딪힌 후 완전히 보호되고 난 후 낙담하기 때문이었다. PaleAqua (토크) 02:18, 2013년 9월 12일 (UTC)[]
26. 제안된 대로 지원하십시오. 쿠드풍 กุดผ ( ((토크) 02:27, 2013년 9월 12일 (UTC)[]
27. 지원 - 이는 단순히 WP:상식. 불행히도 쉽게 파괴되는 목표물인 동시에 이미 과부하된 작업 대기열에 기술적 부하 때문에 심지어 완전히 보호되어야 하는 템플릿과 같은 것들이 있다. 그리고 그러한 템플릿들을 필요할 때나 필요할 때나 수정하려는 편집자들이 많이 있다.관리직에 대한 관심이 없거나 시간이 없다. 이것은 그들이 대걸레와 함께 오는 짐 없이 백과사전을 도울 수 있는 능력을 향상시킨다. - 부시 레인저 02:59, 2013년 9월 12일 (UTC)[]
28. 지원 - 고위험 템플릿의 복잡성과 전문화가 증가함에 따라 기본적으로 이것이 존재해야 한다는 것이 합리적이다. 자발적이긴 하지만 비기술적인 관리자를 통해 고도의 기술 편집을 걸러내려는 것은 문제의 해결책이다. Choess (대화) 03:36, 2013년 9월 12일 (UTC)[]
29. 오래 전부터 있었던 상식처럼 보이네 Joefromrandb (대화) 04:22, 2013년 9월 12일 (UTC)[]
30. 지원 - 관리자가 되고 싶지 않거나 될 수 없는 훌륭한 코디네이터에게 유용함. -- ♥의 킹 ♦ 0 06:07, 2013년 9월 12일 (UTC)[]
31. 다른 많은 사람당 지원 - 부시 레인저, KoH 등 나는 제안된 기준을 트집잡지 않을 것이다. 나는 대부분 그것에 동의하지만 그것은 나중에 다룰 수 있다. — 이것, 저것과 다른 (대화) 08:29, 2013년 9월 12일 (UTC)[]
32. 물론이지, 위험하지 않아. 요즘 관리 기준이 너무 까다롭다. jni (대화) 09:07, 2013년 9월 12일 (UTC)[]
33. 지지하다. 이것은 이 활동을 하고 싶어하는 트라피스트와 같은 사람들에게 관료주의를 감소시킬 것이다. 그것은 또한 RfA에서의 불필요한 시간 낭비를 줄일 것이다. Axl ¤ [Talk] 11:12, 2013년 9월 12일 (UTC)[]
34. 지원 - 위키백과별:행정 요청/스님 트래피스트. 이것은 다른 일에 능숙하지 않거나 다른 일을 하고 싶지 않은 사람들이 그들이 하기로 결정한 것을 여전히 편집할 수 있는 난제를 해결하는 데 도움이 될 것이다. öBrambleberry of RiverClan (UTC) 12:58, 2013년 9월 12일 (UTC)[]
35. 가시성 때문에 완벽하게 보호된 템플릿은 수천 페이지에 걸쳐 확산되는 문제를 방지하기 위한 수단일 뿐이다. 이것은 편집자들에게 불신이 아니라, 1000명의 반달들이 개별 기사에서 할 수 없었던 피해와 터무니없는 짐을 야기할 수 있는 반달에 대한 예방책이다. 그렇지 않으면, 템플릿은 WP의 다른 영역과 다르지 않다. 단, 경험이 부족하면 문제가 발생할 수 있다. 그래서 나는 이 제안이 좋은 중도라고 생각한다. 변화를 만들 때 합의와 테스트는 여전히 가장 중요하다. — HELLKOWNZ ▎토크 13:50, 2013년 9월 12일 (UTC)[]
36. 위의 대부분에 따른 지원 – 경험이 풍부한 코더들은 걸레 없이도 자신의 일을 할 수 있어야 한다. - Evad37 (대화) 15:14, 2013년 9월 12일 (UTC)[]
37. 이것은 오랜 문제에 대한 우아한 해결책이다. 이를 통해 다양한 자격 증명 및/또는 RFA 통과 욕구가 없는 숙련된 편집자에게 불편을 주지 않으면서 가장 민감한 권한에 대한 높은 기준을 유지할 수 있을 것이다. 내가 생각하기에 "템플릿 편집기"는 아마도 가장 좋은 이름이 아닐 것이다. 다른 사람들이 템플릿을 편집할 수 없다는 잘못된 인상을 줄 수 있기 때문이다. "보호된 템플릿 편집기"? — PublicAmpers&^{(main account • talk • block)} 15:51, 2013년 9월 12일 (UTC)[]
38. 합리적인 제안. AutomaticStrikeout (1998년) 20:01, 2013년 9월 12일 (UTC)[]
39. 지지 - 너무 그렇지 않은 이유 없음. 템플릿을 보호하는 이유는 반달리즘으로부터 보호하기 위해서가 아니라, 훌륭한 편집자들이 템플릿을 편집하는 것을 막기 위해서였다. 이 제안은 그 문제를 해결할 것이다. 가리온96 (대화)20:20, 2013년 9월 12일 (UTC)[]
40. 지원- 승려의 RfA 트라피스트 기반 단일 목적의 RfA는 여기에 있으면 안 된다. buffbills7701 22:31, 2013년 9월 12일(UTC)[]
41. 지원 - 이 새로운 사용자 권한은 완전히 보호된 템플릿 편집 요청의 백로그를 줄이는 데 도움이 될 것이다. 이렇게 하면 신뢰할 수 있고 경험이 많은 사용자가 템플릿 편집을 위해 걸레를 요청할 때 RfA 프로세스를 거치지 않고도 작업을 계속할 수 있다. 대체로 나는 그것이 지역사회를 위한 좋은 일이라고 생각한다. — -dainomite 23:06, 2013년 9월 12일 (UTC)[]
42. 지원 - 오랜 문제를 해결하는 잘 생각한 제안처럼 보인다. 이렇게 하면 RfAs라는 단일한 목적을 해결할 수 있을 것이다. 그것은 또한 관리자에 필요한 신뢰를 증명하기 위한 단계가 될 수 있다. - tucoxn\^talk 23:24, 2013년 9월 12일 (UTC)[]
43. 지지하다. 네임스페이스당 편집 액세스 허용은 MediaWiki 소프트웨어에서 가능한 것으로 보이며, 일반적으로 많은 사용자가 다른 편집자와 광범위한 논의를 하지 않으면 이해할 수 없을 정도로 루아 스크립트가 매우 복잡하기 때문에 템플릿 네임스페이스 페이지와 별도로 보호된 루아 스크립트 모듈의 편집을 제한해야 할 수 있다. 모듈 편집 액세스 권한이 이미 있음. -Wikid77 (대화) 04:42, 2013년 9월 13일 (UTC)[]
44. 지원은 적은 양의 관리 작업만 내리지만 템플릿 편집 능력이 있는 관리자에게 불균형적으로 넘어설 가능성이 높다. 그래서 우리가 좀 더 유능한 템플릿과 단서가 있는 편집자들이 그것을 도울 수 있다면 좋을 것이다. 모듈 부분을 추가하는 게 좋을 것 같아. 편집 통지가 별로 좋지 않지만, 편집 통지로 당황하지 않도록 이 사람들을 신뢰할 수 있어야 한다. Graeme Bartlett (대화) 10:33, 2013년 9월 13일 (UTC)[]
45. 지원 - 향후 이 권한의 잠재력이 크다고 본다. -- 숫자 관리 12 ^c:03, 2013년 9월 13일 (UTC)[]
46. 나는 아칼라마리가 제기하는 요점을 인정한다. 나는 단지 이것의 이점이 어떤 단점보다 크다고 생각한다. NW (토크) 15:49, 2013년 9월 13일 (UTC)[]
47. 지원 DavidLeighEllis (talk) 17:24, 2013년 9월 13일 (UTC)[]
48. 스트라디바리우스 씨의 지지. 사용자 권리의 확산이 문제라면 이 권리를 파일 무버와 거래함으로써 기꺼이 해결하겠다. 파일 이동자는 여기서 잠을 많이 잔다; Wbm1058 (대화) 19:40, 2013년 9월 13일 (UTC)[]
49. 지지하다. 하지만, 코멘트: 당신은 사용자 "권리"를 "권리"라고 묘사할 수 없다! 그 부분은 다시 써야 한다. 아니면 "사용자 권리"가 애초에 이런 종류의 것에 대한 잘못된 이름이라는 것이 문제일 수도 있다. — Scott•talk 00:25, 2013년 9월 14일 (UTC)[]

    알겠어. '허락'으로 바꿨는데 그걸로 충분했으면 좋겠는데. Equazcion 01:10, 2013년 9월 14일 (UTC)

50. 보호 템플릿 편집 지원 및 보호 기사 편집은 서로 다른 스킬 세트와 다양한 종류의 신뢰가 필요하다. -- John of Reading (토크) 07:10, 2013년 9월 14일 (UTC)[]
51. 지원 --Rschen7754 09:06, 2013년 9월 14일 (UTC)[]
52. 지원 – 나는 전문 템플릿 코더(일용직)이다. WP에서는 그들에게 가까이 가면 안 되고 십대에게 부탁해야 해. 이것은 오래전부터 미친 짓이었다. 앤디 딩리 (대화) 12:34, 2013년 9월 14일 (UTC)[]

    @앤디 딩리: 나는 CAT를 순찰하는 관리자들 중 어느 누구도 다음과 같이 생각하지 않는다.EP는 10대들이다. 난 그보다 꽤 나이가 많아, 어쨌든... — Mr. Stradivarius 15:20, 2013년 9월 14일 (UTC)[]

53. 관리자로서의 지원 (십대는 아니지만) 나는 나보다 템플릿에 대해 훨씬 더 많이 알고 있는 비관리자들이 많다는 것을 깨닫고, 우리는 그들에게 확실히 더 많은 도움을 줄 수 있는 기회를 주어야 한다. 마크 아르스텐 (대화)20:27, 2013년 9월 14일 (UTC)[]
54. 지지하다. 네, 그리고 어디서 가입하면 되는 겁니까? –Freddie™ 23:31, 2013년 9월 14일(UTC)[]
55. 지원 - 템플릿을 코딩하기 위해 RfA를 통과할 필요가 없다. 심플 TCN7JM 00:26, 2013년 9월 15일(UTC)[]
56. 지지는 훌륭한 제안으로 들린다. →Davey2010→→Talk to me!→01:02, 2013년 9월 15일 (UTC)[]
57. 지원 나는 그것이 좋은 생각이라고 생각한다. 왜 안 되지? Bananapeel89 (talk) 01:33, 2013년 9월 15일 (UTC)Banananapeel89Banananapeel89 (talk) 01:33, 2013년 9월 15일 (UTC)[]
58. 정말 지지해당. 이것은 일부 사용자들이 그들의 일을 하는 데 도움을 줄 수 있다. — —χς 02:03, 2013년 9월 15일 (UTC)[]
59. 무의미한 지원 - 이것은 "보호된 페이지 편집기" 사용자 그룹을 만들려는 다른 많은 시도와 마찬가지로 (관리자에 의해) 무시될 것이다. 아마도 행정관들은 번들번들한 토론에서 투표하는 것을 제한해야 할 것이다. 리퍼 이터널(토크) 02:17, 2013년 9월 15일 (UTC)[]

    어? 이건 61대 8로, 관리자들만 봐도 23대 2로 더 높아. — PinkAmpers&^{(Je vous invite à me parler)} 07:13, 2013년 9월 15일 (UTC)[]

60. 지원 좋은 아이디어, 템플릿을 보호하는 것은 공공 기물 파손으로부터 보호하는 데 도움이 될 뿐, 검증된 편집자가 템플릿을 수정하는 것을 막지 못한다.휴즈다렌 (대화) 2013년 9월 15일 03:51, (UTC)[]
61. 지지 – 내게는 합리적인 것 같다. Graham87 04:14, 2013년 9월 15일 (UTC)[]
62. 지지하다. 난 괜찮을 것 같아. Genhui67 Talk 07:20, 2013년 9월 15일 (UTC)[]
63. 접근성 증대의 이익을 지지해 주는 것이 내게는 지침서보다 더 중요하다. VQuakr (토크) 07:47, 2013년 9월 15일 (UTC)[]
64. 여기서 작업을 보다 쉽게 수행할 수 있도록 지원하십시오. (일명 체드) — 체드즈ILA 07:59, 2013년 9월 15일 (UTC)[]
65. 지지하다. 템플릿 보호는 몇 가지 측면에서 기사를 보호하는 것과 근본적으로 다르므로 별도로 접근을 허용하는 것이 타당하다. 그레고르B (대화) 09:22, 2013년 9월 15일 (UTC)[]
66. 내 도로 템플릿별 지원 팀 동료 프레디 편집 즉시 신청할 사람으로서, 때가 되었다! -happy5214 09:45, 2013년 9월 15일 (UTC)[]
67. 응! 나는 이것을 여러 번 필요로 했고, 그 아이디어를 내 스스로도 여러 번 언급했어. 이상적인 해결책. Debresser (talk) 10:21, 2013년 9월 15일 (UTC)[]
68. 지원, 반드시 필요하다. 나는 아래에도 현재 이것이 제자리에 있지 않기 때문에 오직 달리고 있는 편집자의 RFA에 반대하는 반대자들이 없었으면 좋겠다(그리고 만약 있다면, 케이크도 먹을 수 없고 먹을 수 없다. 스티븐 장 13:34, 2013년 9월 15일 (UTC)[]
69. 기술 구현이 가능하다고 가정하는 지원. 아이언홀드 (대화) 2013년 9월 15일 17:27 (UTC)[]
70. 지원, 그것은 많은 사용자들이 위키피디아에 머물도록 격려할 것이다. 왜 안 되는지 모르겠어. SHIVAM SETU (U-T-C-E) 17:58, 2013년 9월 15일 (UTC)[]
71. 사용자별 지원:Stradivarius Chris Trutman (talk) 18:38, 2013년 9월 15일 (UTC)[]
72. 지지하다. 내게는 꽤 합리적인 것 같다. 신뢰할 수 있는 편집자는 신뢰할 수 있어야 한다. -- 위키피디아 (대화) 21:04, 2013년 9월 15일 (UTC)[]
73. 지원 템플릿과 기사는 완전히 다른 두 가지 이유로 보호되므로, 나는 기사 보호와 관련된 유사한 번들을 지원하지 않을지라도 이를 지원할 준비가 되어 있다. Ryan Vessey 21:20, 2013년 9월 15일 (UTC)[]
74. 주로 트라피스트의 RfA를 기반으로 하는 지원.Tazerdadog (대화) 22:03, 2013년 9월 15일 (UTC)[]
75. 지지하다. 어째서 이것은 이미 존재하지 않는 것일까? 아질버 (대화) 22:28, 2013년 9월 15일 (UTC)[]
76. 템플릿 비트 생성을 적극 지원한다. '일반 지침'에 반대하는 여러 주장들이 눈에 띄지만, 동의안이 가결된 뒤(전혀 있다면)까지는 그것들에 대해 담금질할 필요가 없다는 생각이 든다. 즉, 성공할 수도 있고 실패할 수도 있는 어떤 것의 더 미세한 디테일을 논할 필요가 무엇인가. – AJL^talk 23:14, 2013년 9월 15일 (UTC)[]
77. 이것이 관리 도구 세트의 번들거림에서 미끄러운 비탈길로 바뀌지 않기를 바라지만, 나는 이러한 종류의 사용자 권리가 도움이 될 수 있는 많은 사례들을 보아왔다. Killiondude (대화) 00:47, 2013년 9월 16일 (UTC)[]
78. 자격 있는 지원, 하지만 나는 어떤 관리자보다 '부정 행위'에 의해서만 허가나 취소가 이루어지는 것을 훨씬 더 보고 싶다. 메타에 대한 "번역관리자" 권리가 부여되는 방식과 같은 것은 나를 훨씬 더 우월하게 만들 것이다; 가볍지만, 후보들에 대한 커뮤니티의 논평은 허용한다. Courcelles 00:50, 2013년 9월 16일 (UTC)[]
79. 지원, RFA는 깨졌고, 사람들은 단지 하나의 특정 분야에 기여하기 위해 모든 것을 할 필요가 없어야 한다. —Locke Cole • t • c 01:19, 2013년 9월 16일 (UTC)[]
80. Supprt 꽤 분별 있고 안전한 것 같다. wctaiwan (대화) 01:53, 2013년 9월 16일 (UTC)[]
81. 지지, 좋은 것 같아. 신뢰할 수 있는 편집자에게 유용하고 유용한 기능이 될 것이다. ////EuroCarGT 01:56, 2013년 9월 16일 (UTC)[]
82. 지원은 효율적이고 유용해 보인다. 정확한 기준에 전적으로 동의하지는 마십시오만, 위에서 다른 사람들이 말했듯이, 이러한 것들은 나중에 해결할 수 있다. --LukeSurl ^{t c} 08:28, 2013년 9월 16일 (UTC)[]
83. 지원, 신뢰할 수 있는 편집자가 직접 수행하도록 한다. --Gerda Arendt (talk) 09:29, 2013년 9월 16일 (UTC)[]
84. 템플릿의 완전한 보호를 지원하지만 악용 방지를 위해 필요하며, 관리자가 아닌 경우 많은 템플릿으로 작업하기 어렵게 하는 효과도 있다. RfA가 템플릿 편집과 무관한 분야에 대한 전문 지식을 불합리하게 기대하지 않기 때문에 관리직은 이러한 사람들에게 선택사항이 아닐 수 있다. 보호된 템플릿을 편집할 수 있는 많은 관리자는 필요한 기술 기술을 가지고 있지 않다. 템플릿 네임스페이스는 보호가 선제적으로 사용되는 유일한 장소라는 점에서 다른 영역과도 근본적으로 다르다. Hut 8.5 10:36, 2013년 9월 16일 (UTC)[]
85. 지원 - 의견별 및 강력한 관리자 지원. 공손히, 티양 (대화) 12:36, 2013년 9월 16일 (UTC)[]
86. 본 제안서는 현재 기사에 사용되고 있는 것과 마찬가지로 템플릿에서 사용할 수 있는 옵션으로 완전 보호를 제공하므로, 즉, 편집-경쟁이 발생한 경우/사용한 내용을 지원하십시오. It Is Me Here 12:50, 2013년 9월 16일 (UTC)[]
87. Jamesmcmahon0 지원 - 이는 코더들이 변경을 하기 위해 관리자나 페스터 관리자를 신청할 필요가 없고 관리자가 코드를 이해하거나 검토 요청을 검토할 필요가 없다는 것을 의미하는 좋은 타협으로 보인다. 관리자가 부지런히 특권을 부여한다면 나는 이 권리를 부여받은 편집자들이 논란이 될 수 있는 편집과 지역사회의 합의에 관한 통상적인 규칙을 따를 것이라고 확신한다. Jamesmcmahon0 (대화) 13:43, 2013년 9월 16일 (UTC)[]
88. 지원 개인적으로 큰 영향을 주지는 않겠지만, 사용량이 많은 보호 템플릿에 필요한 변경을 빨리 할 수 없다는 것이 얼마나 좌절스러운지 알 수 있다. 그들이 무엇을 하고 있는지 안다면, 나는 그들이 그것을 하는 것을 막을 이유가 없다고 본다. RfA는 이를 위해 필요한 이정표가 되어서는 안 된다. IMHO. 나열된 지침은 타당해 보이지만, 나는 아마도 당신이 요청할 수 있는 다른 사용자 권리에 대해 우리가 가지고 있는 것과 같이 "만약 당신이 나열된 지침을 충족하지 못한다면, 당신은 여전히 지원할 수 있지만, 이유를 주어야 한다"라는 취지의 내용을 덧붙일 것이다. 더블 샤프(토크) 14:04, 2013년 9월 16일 (UTC)[]
89. 지원 나는 오랫동안 우리가 관리자 아래 공인된 신뢰할 수 있는 편집자 수준이 필요하다고 생각했지만, 더 제한적인 권한을 가지고 있지만, 정치적 검토 과정은 덜 했다. 이것은 내가 원하는 것보다 좁지만 올바른 방향으로 가는 한 걸음이다.--농업 (대화) 14:19, 2013년 9월 16일 (UTC)[]
90. 지원, 신뢰할 수 있는 편집자가 보호된 템플릿에 대한 작업을 수행하도록 허용 및 관리자가 다른 작업을 수행하도록 허용 사용자 대화부터 시작하여 이러한 권한의 수가 매우 제한적이어야 한다.스님을 트라피스트하십시오.DThomsen8 (대화) 15:03, 2013년 9월 16일 (UTC)[]
91. 지원 - 템플릿을 보호하는 이유는 기사를 보호하는 이유와 다르다. 특정 고위험 템플릿이 특정 신뢰할 수 있는 사람에 의해서만 편집되도록 해야 하기 때문에 템플릿이 보호된다. 그러나, 우리의 모든 관리자가 좋은 코딩인은 아니며, 우리의 좋은 코딩인들이 모두 관리자인 것은 아니다. 따라서 우리가 신뢰해야 할 사람들에게 고위험 템플릿(경쟁력 있는 코드 사용자)을 허용하여 그러한 템플릿을 편집하도록 하는 것이 타당하다. ItsZippy 15:36, 2013년 9월 16일 (UTC)[]
92. 실망한 지원 나는 이것이 심각한 코디네이터들에게 템플릿을 편집하는 능력을 허락할 것이기 때문에 이것을 지지한다. 나는 그것이 필요하고, 템플릿 코드 작성자들이 관리자로써 충분히 신뢰받지 못한다는 것에 실망했다. 나는 우리가 위키피디아에 다른 수준의 신뢰를 더하는 것에 실망했다.마틴451 (대화) 2013년 9월 16일 17:41, (UTC)[]

    wrt. edit. edit 요청을 다른 곳에 추가하고자 한다. 기사에 대한 편집 요청은 종종 명백하게 잘리며, 철자 오류가 발생하거나 텍스트를 잘못된 장소에 넣는 경우(등) 그것은 중요하지 않다. 만약 내가 템플릿에 대한 편집을 요청한다면, 편집에 버그가 있거나, 또는 sysop이 그것을 잘못 구현했다면, 그것은 위키백과의 많은 부분에 영향을 줄 수 있고, 또한 아는 사람이 그것을 수정하기까지 몇 시간이 걸릴 수도 있다. 이 권리를 주는 것은 잘 아는 사람들이 처음으로 그것을 바로잡을 수 있게 해줄 것이고, 혹은 그들의 실수를 매우 빨리 고칠 수 있게 해줄 것이다. 또한 에 있는 사람들이 템플릿에 대한 편집 요청을 모니터링하고, 대부분의 관리자보다 더 나은 결정을 내릴 수 있도록 하며, 필요한 경우 디버그/반복할 수 있다.마틴451 (대화) 23:32, 2013년 9월 17일 (UTC)[]

93. 지원 - 이 사용자 권한은 타당하다. 템플릿 편집은 불명확하며, 몇 가지 관리 요청서를 읽었을 때, 이 영역에 어떤 능력도 필요하지 않은 것으로 보인다. 또한 템플릿에 대한 열띤 토론도 몇 번 읽었는데, 관리자들은 템플릿 토크 페이지에서 편집 내용을 논의하지 않고 완벽하게 보호된 템플릿을 편집했다. 신뢰할 수 있고 유능한 사용자 범주를 갖는 것도 이러한 열의 일부를 제거하는 데 도움이 될 수 있다. 나도 템플릿 편집하는 거 싫어해. 시도하기가 답답하고, 편집만 한 것 같아. 나는 또한 이 범주의 사용자들이 필요할 때 특정 사용자들이 나를 위해 이것을 할 수 있도록 하고 싶다. --(AfadsBad (talk) 17:54, 2013년 9월 16일 (UTC)[]
94. 지원 - 이것은 일부 불필요한 관리 오버헤드를 제거할 수 있는 합리적인 신뢰의 사용이다. kencf0618 (대화)20:55, 2013년 9월 16일 (UTC)[]
95. 지원 - 관리 오버헤드 제거 및 점진적인 분산 또는 관리 권한을 허용하여 RfA의 일부 실언에 도움이 됨 섀도잼 (토크) 23:20, 2013년 9월 16일 (UTC)[]
96. 지원, 하지만 우리는 그것이 필요 없어. 신뢰할 수 있는 편집자는 관리자여야 한다! 관리직의 기준이 터무니없이 높으니, 적어도 신뢰할 수 있는 비관리자들에게 필요한 것은 좀 주도록 하자. 그런데, 우리는 정말로 제거의 네 번째 기준이 필요하다: 템플릿 파괴 행위. 노골적인 반달리즘을 행하기 위해 템플릿 편집자 사용자 권한을 이용하는 것이 포착되면 차단하는 것 외에 권리도 제거할 것이며, 관련 정책이 WP에 의존할 필요 없이 과감하게 삭제를 허용했으면 한다.IAR. Nyttend (대화) 00:03, 2013년 9월 17일 (UTC)[]

    이 내용은 WP에서 다룬다고 생각한다.상식, 그러나 그렇게 노골적으로 말하는 것은 나쁘지 않다 :) 나는 위에 덧셈을 했다. Equazcion 00:24, 2013년 9월 17일(UTC)

    당신의 논평과 물론 당신의 변화에 동의하라. 나는 필요할 때 기꺼이 IAR을 할 용의가 있지만, 규칙을 무시하지 않고 우리가 필요한 것을 할 수 있을 때 더 좋다. 다른 것이 없다면, 그것은 가능한 위키리거링 전략을 없앨 것이다. Nyttend (토크) 2013년 9월 17일 00:38 (UTC)[]

97. 지지하다. 반대표 중 일부는 중요한 문제를 제기하지만, 이것은 이 프로젝트에 도움이 되고 유용한 추가인 것 같다. NinjaRobotPirate (talk) 05:44, 2013년 9월 17일 (UTC)[]
98. 지원. - filelakeshoe (t / c) 10:48, 2013년 9월 17일 (UTC)[]
99. 지지하다. 아마도 수십 명의 코더들만이 이 책임을 인정받을 수 있을 것이다. 하지만 이 사람들을 약혼시키는 것은 위키에게 도움이 될 것 같다. Binksternet (대화) 13:37, 2013년 9월 17일 (UTC)[]
100. 지지하다. 나는 이것이 제정되어서는 안 될 이유를 모르겠다. —고든 P. 헴슬리→15:06, 2013년 9월 17일 (UTC)[]
101. 지지하다. 많은 재능 있는 편집자들이 RfA가 된 후프 점프 서커스에 자신을 노출시키고 싶어하지 않기 때문에, 개별 관리 도구를 사용자 권리로 바꾸는 것이 좋은 해결책이다. RfA의 정밀검사도 좋을 것이다. 인탄 15:22, 2013년 9월 17일 (UTC)[]
102. 이를 편집할 수 있는 사용자 수를 늘리면 일부 사용자의 작업량이 현저히 감소하므로 지원하십시오. 자흐 베가 (나하고 대화) 2013년 9월 17일 16:55 (UTC)[]
103. 마크 아르스텐당 지지. 28바이트 (대화) 17:38, 2013년 9월 17일 (UTC)[]
104. yes per yintan Dlohcierkim 20:30, 2013년 9월 17일 (UTC)[]
105. 현재 상황을 고려할 때 합리적이고 적절한 지원으로 들린다. 템플릿은 골칫거리가 될 수 있고 편집하는 방법을 아는 사용자들은 공급이 부족하다. 에버그린피르 (talk) 03:48, 2013년 9월 18일 (UTC)[]
106. 지지 - 네덜란드 위키에서 나는 이것이 유용할 수 있는 경우를 보아왔다. 어떤 사람들은 인간의 능력 때문에 관리자 기능에 맞지 않지만 위키 기술, 초능력, 비열함을 잘 가지고 있다. 타케타 (토크) 07:28, 2013년 9월 18일 (UTC)[]
107. 지원 - 관리자 권한을 분산시키는 어떠한 시도도 환영한다. 이것도 좋은 생각이야, 어서 해. --Ekabhishek^talk 09:44, 2013년 9월 18일 (UTC)[]
108. 숙련된 편집자에 의한 템플릿/모듈 개발 및 이 권한 대 전체 관리자 권한의 분리를 촉진하기 위한 지원 노력. Rjwilmsi 13:48, 2013년 9월 18일 (UTC)[]
109. 지원, 이것은 좋은 아이디어로 관리자의 업무량을 줄이는 데 도움이 될 것이다. --Funandtrvl (대화) 17:03, 2013년 9월 18일 (UTC)[]
110. 지지; 이것은 좋은 생각이다. -sche (대화) 2013년 9월 18:58, (UTC)[]
111. 자격 있는 지원 I는 적어도 자격 있는 개념을 지지한다. [a] 중립성의 일부 장기적 긍정적 표시, [b] "유용한 목적을 입증"하는 정의. [c] (아마도) 위키백과에서 더 긴 시간. –DjScrawl (대화) 19:21, 2013년 9월 18일 (UTC)[]
112. 지원. - 이 작업을 수행하려면 신뢰할 수 있는 사용자만 필요하며, 관리자도 필요하지 않다. GabeMc 21:14, 2013년 9월 18일 (UTC)[]
113. 지지 현재의 상황이 좀 이상하다. 예를 들어, 나는 최근에 파괴된 템플릿을 포함하여 여러 개의 템플릿을 만들었고, 그 템플릿을 고쳐야 했다. 만약 내가 공공 기물 파손을 제한하기 위해 그것을 보호해 달라고 요구한다면, 나는 그것을 편집할 수 없을 것이다. 피터 콕스헤드 (대화) 21:47, 2013년 9월 18일 (UTC)[]
114. 지지하다. 내가 읽은 반대 합리화는 기껏해야 잘못 이해된 것 같다. 많은 템플릿은 영구적으로 완전하게 보호되며, 그것은 변하지 않을 것이다. 이 제안의 대안은 훨씬 더 적은 수의 사람들이 템플릿을 편집할 수 있는 현상이다. 위키피디아를 향상시키는 데 원칙적인 입장을 취하는 것을 허용하지 말자. Sometguy1221 (대화) 05:17, 2013년 9월 19일 (UTC)[]
115. 지지하다. 적격성 등의 세부사항에는 약간의 미세 조정이 필요할 수 있지만, 일반적인 개념은 양호하다. • • Peter (Southwood) : 2013년 9월 19일 (UTC)[]
116. 일반 원칙과 특정 제안을 다음과 같은 몇 가지 제안으로 지지한다.

     나는 어려운 숫자와 빠른 숫자가 좋은 생각이라고 생각하지 않는다. 우리는 RfAs에서 편집의 구체적인 길이나 편집 횟수를 요구하지 않는다. 그리고 이것은 걸레보다 더 쉽게 얻을 수 있을 것이다. 왜냐하면 그것은 절대적으로 덜 강력하기 때문이다.

     나는 예비 템플릿 편집자들이 변화를 주었어야 할 뿐만 아니라, 그들의 코드가 좋은 품질이고, 그들이 카우보이가 아니고, 생방송에 들어가기 전에 적절한 테스트를 하지 않고, 그들의 자료를 문서화해야 한다는 추가적인 요구들을 보고 싶다.

     현재 '시스템'의 한 가지 특징은 템플릿 편집자 비트(지금은 관리자와 같음)가 없는 편집자는 두 번째 쌍의 눈을 지나 중요한 템플릿에 대한 변경 사항을 얻어야 한다는 것이다. 나는 능력 있고 자발적인 검토자가 부족한 상황에서, 이것은 현재 많은 양에 이르지는 않지만, 적용 가능한 변화가 좋은 품질인지 확인하기 위해 만들어질 수 있지만, 그들이 모든 것을 요구하고 받을 필요가 없다면, 능력 있고 의지가 있는 커밋의 사관생도를 만드는 것이 더 쉬워야 한다는 것을 깨달았다. 관리자와 템플릿 편집자가 템플릿을 변경하기 위한 요청을 철저히 검토하고 그렇지 않다면 처음부터 다시 시작해야 한다는 규범을 세워야 한다고 생각한다. Kleptomaniac Viol (talk) 15:54, 2013년 9월 19일 (UTC)[]

117. 물론이지 안 할 이유가 없어. 쓰기 키퍼 keeper keeper 17:03, 2013년 9월 19일 (UTC)[]
118. 총체적 지원 - 나는 관리자여서 때때로 편집 요청을 완료하지만, 템플릿 요청은 내 전문성을 넘어선 것이며, 관리든 아니든 간에 템플릿에 대해 더 많이 알고 있는 사람이 수정하도록 하는 것이 좋다. :) ·살비드림!· ✉ 2013년 9월 19일(UTC) 17:47[]
119. 지지하다. 특권 시스템에 짜증나는 구멍을 메울 수 있을 거야 올바른 방향으로 한 걸음. —Stepung3 (대화) 18:10, 2013년 9월 19일 (UTC)[]
120. 관리 도구 상자의 분해를 위한 이 작업과 다른 모든 사려 깊은 노력을 지지하십시오. 카라이트 (토크) 2013년 9월 19일 (UTC)[]
121. 지원; 이러한 템플릿이 보호되는 이유는 "정상적인" 보호가 아닌 안전 중 하나이며, 템플릿을 편집할 수 있는 것은 오직 기술 시연만 필요로 한다는 것이 타당하다. — Coren 19:58, 2013년 9월 19일 (UTC)[]
122. 지원 나는 매우 숙련된 템플릿 코더지만, 내 모든 작업은 NDA의 미디어위키 소프트웨어 사용에 의해 보호되는 Wiki에 위치한다. 그렇기는 하지만, 보호된 템플릿으로 여러 사이트를 관리했으므로 템플릿을 편집하기 위해 템플릿 코딩에 능숙한 비관리자가 필요하다는 것을 알 수 있다. 하지만 교통량이 많은 보호대상자의 경우, 편집이 이루어지기 전에 일정 기간 동안 미리 공지사항과 샌드박스 버전이 만들어지는 일종의 절차를 제안하고 싶다. 개선된 템플리트와 개선된 템플리트를 잘 코딩할 수 있지만 역할이 할당되지 않은 사람들의 신뢰할 수 있는 템플리트 편집자 및 템플리트 편집 요청 역할에 대해 문의하고자 한다. 나는 그것이 개선을 위한 접근성을 증가시킬 것이라고 생각하지만, 다른 사용자들이 대규모 반달리즘을 야기할 경우 위키피디아 외부의 어떤 종류의 결과에도 직면할 필요가 없는 사용자들을 업신여기는 관문이 될 수도 있다고 생각한다. php에서 MediaWiki 소프트웨어에 워크플로우 시스템을 구현한 나는 이러한 변화에도 불구하고 Wikis는 여전히 접근성이 부족하다고 생각한다. 참회 (대화) 2013년 9월 19일 21:00 (UTC)[]
123. 지지하다. "자유롭게" WP:HRT가 적용된다. 본명을 사용하지 않는 사람(토크) 21:40, 2013년 9월 19일 (UTC)[]
124. 지지하다. 나는 이 도구가 "관리 도구 상자"에 도움이 될 수 있다고 생각한다. 숙련된 사용자가 도울 수 있다. --Dэя-бøg 23:04, 2013년 9월 19일 (UTC)[]
125. 지원 --AmaryllisGardener (talk) 00:10, 2013년 9월 20일 (UTC)[]
126. 지원 - 이제 Lua를 사용할 수 있게 됨에 따라 점점 더 많은 수의 템플릿과 모듈이 이와 같은 권리의 필요성을 정당화한다. 필요에 의해 태어나서 적기에 도착했다. -- œ^™ 04:29, 2013년 9월 20일 (UTC)[]
127. 지원 - 자격 요건에 약간의 조정이 필요할 수 있음(점수 5와 6은 아마도 너무 제한적임) - Nbound (토크) 05:37, 2013년 9월 20일 (UTC)[]
128. 지원 - 내게는 합리적인 것 같다. --Kevjonesin (대화) 08:52, 2013년 9월 20일 (UTC)[]
129. 지원 나는 이것을 과거에 100만 번 지원했으니까 지금 다시 지원하겠다. 헤드폭탄 {토크 / 기여 / 물리학 / 책} 12:41, 2013년 9월 20일 (UTC)[]
130. 지원 - 내게는 합리적인 것 같다.--Unionhawk 21^E-mail:13, 2013년 9월 20일 (UTC)[]
131. 지지 - 이것은 나에게 전적으로 타당해 보인다. Aneah talk 00:03, 2013년 9월 21일 (UTC)[]
132. 지지 - 내게는 머리가 잘 돌지 않는 것 같다. 보호된 템플릿을 수 천 페이지에 걸쳐 동시에 파괴될 위험에 노출시키지 않고, 또는 위키피디아가 폭발적으로 폭발하는 위험성에 노출시키지 않고 쉽게 고칠 수 있을 겁니다. "야당" 섹션에 있는 일부 사람들이 우리가 해야 한다고 생각하는 것처럼, 누군가 들어가서 그들이 원하는 템플릿들을 편집하게 한다면 말이죠. --잃어버린 지레, 잃어버린 지레. dutch :O (talk) 01:51, 2013년 9월 21일 (UTC)[]
133. 논리적인 이동을 지원한다. 스펜서^T♦C 17:20, 2013년 9월 21일 (UTC)[]
134. 그 권리를 가질 것을 요청할 수 있는 사람으로서 지원하라. 내가 높은 자신감을 가지고 있는 간단한 변화를 제안해야 한다는 것은 모든 사람의 시간을 잘 활용하는 것 같지 않다. 특히 (명백한 MOS 문제처럼) 트집잡는 것일 때, 나는 기꺼이 빨리 해치웠을 때, 누군가의 시간을 읽고, 이해하고, 변화시킬 수 있는 것을 "쓰레기"해야 하는 죄책감을 느낀다. 내가 할 수 있다면 기꺼이 직접 하겠지만, 어떤 일들은 보고도 하지 않는다. 나는 그것이 혼란이나 논란을 일으킬 수 있는 것이라면 도움을 요청하거나 입력해야 할 때를 알고 있다. 나 같은 사람도 분명히 있을 거야. —[AlanM1(대화)]—20:19, 2013년 9월 21일 (UTC)[]
135. 주로 본명을 사용하지 않는 누군가와 베티 로건을 지지한다. 위에서는 모든 관리자가 템플릿 편집에 익숙하지 않다고 여러 번 말했으며, 나는 모든 템플릿 코더가 관리직에 출마하는 데 편안함을 느낄 만큼 충분히 숙련된 것은 아니라고 주장할 것이다. Go Phightins!20:27,2013년 9월 21일 (UTC)[]
136. 지원: 이것은 템플릿 편집 속도를 높이기 위해 정말로 필요하다. 하지만 나는 한 가지 사소한 수정을 제안한다. 편집자는 최소 3개의 완전 보호된 템플릿의 샌드박스 버전을 작업했어야 했다. 편집자는 최소 3개의 완전 보호된 템플릿의 샌드박스 버전에서 작업해야 한다. 일부 기술자들은 (표준 샌드박스에서 일어날 수 있는) 변경사항을 다른 사람이 덮어쓰도록 하지 않고 시간 경과에 따라 작업하기 위해 템플릿 복사 작업을 사용자 공간에 두는 것을 좋아한다.--Siddhartha Ghai (talk) 20:52, 2013년 9월 21일 (UTC)[]
137. 지지 - 좋은 생각인 것 같다. 아퍼슨 (토크!) 21:49, 2013년 9월 28일 (UTC)[]
138. 지원 - 이 제안을 철저히 검토한 후, 템플릿, 모듈 및 편집 통지 편집/수정 경험이 있는 편집자에 대해 별도의 사용자 권한을 갖는 것이 정당해 보인다. 이것은 많은 관리자와 다른 사용자들의 작업량을 줄이는 데 분명히 도움이 될 것이다. 왜냐하면 이 분야에 능숙한 편집자들은 이미 그들 스스로 작업하는 데 필요한 기술과 지식을 가지고 있기 때문이다. 전반적으로 제안서와 제공된 이유는 이 새로운 사용자 권리를 만드는 데 유효해 보인다. GeneralUser (talk) 15:04, 2013년 10월 2일 (UTC)[]
139. 지원 - 내게는 잘 들린다. 우리는 그러한 민감한 템플릿을 큰 문제없이 편집할 수 있는 기술적으로 숙련된 사용자들을 필요로 한다. 어차피 비트로 할 일이 제한된 템플릿을 편집하는 일이라면 관리자 권한은 과잉 살상이다. WP:부로는 어쨌든 크게 잘못 해석되는 경향이 있다.--Aunva6^{talk - contribs} 07:15, 2013년 10월 5일 (UTC)[]
140. 지원--- — Keithbob • Talk • 2013년 10월 6일 (UTC)[]
141. 신청자/제안자 중 한 명으로서 지원하십시오. 기술 13 (토크) 11:29, 2013년 10월 9일 (UTC)[]
142. 제안자로서 지원 - 의심이 있었던 것이 아니라 정확한 계산을 위해:) 15:47, 2013년 10월 9일 (UTC)
143. 지지와 나는 이 권리를 부여하는 (그리고 취소하는) 과정이 가벼운 무게로 유지되기를 바란다. 사실, 아칼라마리 행을 따라, 나의 첫 번째 선호도는 만약 새로운 권리를 부여받은 편집자들이 기술적으로 어떤 템플릿도 편집할 수 있다면(즉, 새로운 보호 수준의 복잡성은 추가되지 않았다). 드물지만, 어떤 이유로 페이지의 편집 고시로 표시될 수 있는 특정 템플릿을 관리자만 편집하고 새로운 오른쪽 홀더만 이를 따르는 것이 바람직하다(cf, WP로 인한 페이지 보호 방법:사무처리는 기술적으로 준비가 되어 있더라도 관리자가 실행 취소하지 않는다. 일반적으로 우리는 기술적 장벽에 의존하지 않고 신뢰와 규범의 문화를 배양해야 한다. 아베케다레 (대화) 11:06, 2013년 10월 12일 (UTC)[]

     이 솔루션이 기술적으로 가능하려면 새 확장자를 설치하거나 이 권한을 가진 사용자가 보호된 페이지(사용자 .js 및 .css, MediaWiki의 페이지: 네임스페이스 및 계단식 보호 페이지 제외)를 편집할 수 있어야 한다. Jackmcbarn (대화) 14:31, 2013년 10월 12일 (UTC)[]

     트레이드오프를 명확히 해줘서 고마워. 새로운 소프트웨어 확장을 목표로 하는 것(그리고 내가 선호하는 접근법에 대한 지원을 테스트하기 위해 이 RFC를 재실행하는 것)이 단지 전체 과정을 지연시키고 탈선시킬 수도 있다는 것이 두렵다. 그리고 나는 템플릿 편집자 권한이 부여된 편집자들이 (대부분) 완전히 보호된 페이지를 편집할 수 있는 것이 편하지 않다. 왜냐하면 그것이 가능하다면, 결국 1) 템플릿 편집자 권리는 관리자로 간주되어 RFA처럼 부담이 되고, 그것을 얻는 것은 2) 많은 RFA 후보자들이 신청하고 찬성하도록 지시받을 것이기 때문이다....의 추가 권리를 얻기 전에 스스로 관리자로서 행동하다.증가하는 위키백과 관료주의 간단히 말해서, 이상적인 세계에서는 다른 제안을 하겠지만, 나는 그 제안을 지지한다. 아베케다레 (대화) 2013년 10월 12일 18:38, (UTC)[]

     지지하다. 반년 전쯤, 나는 이 토론에서 비슷한 권리가 존재한다고 제안했었다. 그러나, 위키백과의 대화를 위해 "마감 시간"에 제안되었기 때문에, 내가 제안한 토론은 아무 진전이 없는 것 같았다.제안서를 게시한 보호 페이지 편집자 토론. 이 제안이 내가 시작하려고 했던 제안보다 훨씬 더 많은 관심을 받고 있는 것을 보니 기쁘다. Steel1943 (대화) 00:58, 2013년 10월 13일 (UTC)[]

     중립으로 투표 이동 (아래 참조) 스틸1943 (토크) 01:32, 2013년 10월 13일 (UTC)[]

144. 나는 주로 현재 관리자로 제한된 일부 업무를 "분할" 방법으로 이 제안을 지지한다. 우리는 템플릿 파괴 행위를 방지하는 통제가 필요하지만, 현 접근방식인 많이 전달된 템플릿의 완전한 보호는 완벽한 통제가 아니다. 왜냐하면 관리자들은 템플릿 전문지식을 가질 필요가 없기 때문이다. 이는 RfA 시험 평가 중 하나가 아니며, 그렇게 해서는 안 된다. 관리자가 핵심 관리 작업에 집중하고 템플릿 전문가가 템플릿에 대해 작업할 수 있도록 하십시오. 템플릿 전문가가 템플릿에 대해 작업할 수 있도록 하십시오. Bobrayner(대화) 12:54, 2013년 10월 14일(UTC)[]

반대하다

1. 내가 이것을 뒷받침하기 전에 더 나은 근거가 있어야 한다. 코디네이터들이 변화를 원하는 이유를 말로 표현하고 싶어하지 않고 따라서 그렇게 해서는 안 된다고 말하는 것은 적절한 이유가 아니다. 이 완전한 보호 템플릿이 그렇게 중요하다면, 그것들에 대한 변경은 합의에 의해서만 이루어져야 하지 않을까? 그런 공감대를 얻기 위해서는 어쨌든 그 이유를 설명해야 하지 않을까? 그러나 나는 코더가 자신의 일을 즐기고 스스로 하고 싶어한다는 것을 이해한다. 따라서 나는 관리자가 변경의 근거를 설명한 후에 코더가 특정 템플릿이나 템플릿 세트에 대한 대리보다 자신의 변경을 할 수 있도록 하는 임시 권리를 지지할 것이다. —Anne Delong (talk) 11:54, 2013년 9월 11일 (UTC)[]
   • 앤 들롱에게 물어봐줘서 고마워! 요청된 많은 변경사항들은 사소한 것이며 논란의 여지가 없다; 구두점 오류 수정, 철자 오류 수정, 새로운 선택적 매개변수 추가, 또는 확립된 패턴을 기반으로 더 많은 입력을 허용하도록 템플릿을 확장한다. 기술 13 (토크) 2013년 9월 11일 12:43 (UTC)[]

   • 오타들은 설명하기 쉽고 관리적인 해결책이 있어야 한다. 네가 언급하는 다른 항목들은 내가 느끼는 공감대가 있어야 한다. 코더들은 때때로 그들이 다른 사람들에 의해 그렇게 여겨지지 않을 수도 있는 사소한 것으로 간주하는 변화를 만든다. 예를 들어, Afc 대본에서 "hoax"라는 단어는 검토자 공동체 간의 논의 없이 쇠퇴 이유인 "joke or false"에서 계속 삭제되고 있다. 누군가는 아마 (한 번 이상) 이것이 사소한 변화라고 생각했을 것이다. 지난 주 한동안 감소 템플릿이 선언문의 이름을 나열하는 것을 소홀히 했다. 그 전에 어느 날, 템플릿 중 하나에서 도움 페이지 링크가 불가사의하게 사라졌다. 보호 템플릿은 이들 템플릿보다 더 중요하게 고려되어야 하기 때문에 코드 작성자들이 무엇을 할 것인지 설명하고 관리자로부터 허가를 받아야만 관리자가 나중에 결과가 정확하고 정책 내에서 확인할 수 있다면 나는 더 편할 것이다. —안네 들롱 (대화) 13:29, 2013년 9월 11일 (UTC)[]

   • 당신이 설명하는 상황은 관리자가 편집을 할 때 발생할 수 있는 것과 같다. 사소한 실수는 누가 관여하든 간에 가끔 발생할 것이다(부정적인 경우, 관리자는 자신의 사소한 편집을 하기 전에 다른 사람과 확인할 필요가 없으며, 우리는 일부 관리 코더가 있다). 관리직은 실수를 예방할 수 있는 코딩 지식의 수준을 보장하거나 표시하지 않는다. 실수가 최소한으로 유지될 것이라는 최선의 보장은 보다 유능한 코더들을 참여시키는 것이며, 현재 대부분의 코더들은 언급된 이유 때문에 관리자가 아니며, 완전히 보호되는 템플릿에 전문지식을 기여하고 싶지도 않다. 13:42, 2013년 9월 11일 (UTC)

   사실 대부분의 관리자들은 그 코드가 맞는지 모를 것이라고 시인하고, 그저 맹목적인 믿음으로 변화를 만든다. 그래서 코드가 어떻게 될 지 아는 사람이 변경을 해서 문제가 생기면 편집요청을 제출하지 않고 수시간에서 일주일 동안 어디서든 수정될 수 있도록 하는 것이 좋다. 쿠미오코 (토크) 15:01, 2013년 9월 11일 (UTC)[]

   ...이것은 또한 보호되는 편집 요청의 대기열을 처리하기 위해 스스로 책임을 지는 관리자들이 주변에 상대적으로 적다는 문제를 다룬다. (나는 거기서 판단을 하지 않는다. 그것은 단지 사실이다.) 따라서 개선 사항, 유지보수 및 필요한 수정에 대해서는 잊어버리는 것이 시간이 오래 걸릴 수 있다. Equazcion 15:14, 2013년 9월 11일(UTC)

   • (충돌 편집) 당신이 앤을 묘사하고 있는 문제들은 창조 도우미를 위한 또 다른 조항들과 함께 있는데, 최근에 최신 코드를 사용하는 것에 적응하기 위한 많은 새로운 특징들로 인해 많은 변화가 일어나고 있다(팀에서는 최근에 로드 시간과 pr을 개선하기 위해 대본의 많은 부분을 jQuery로 변환하고 CSS3/HTML5를 사용하는 것에 적응하고 있다).이전 코드가 브라우저에서 더 이상 지원되지 않고 상당히 새로운 CSD:G13 기준에 해당하는 초안을 검토하기 위한 사내 옵션을 제공하는 경우 이벤트 대량 실패. 스크립트를 사용하지 않고 수동으로 편집했기 때문에(GitHub의 ticket) 거부 템플릿이 보고서에 거부 선언기와 타임스탬프를 표시하지 않는 것으로 스크립트의 리드 개발자에 의해 결정되었다. 또한 기록상, 감소 템플릿은 완전히 보호(검증)되어 있어, 일이 잘못되었을 때, AFCH 개발자(mabdul — Nathan2055 — Technical 13 — Theopolisme — Rushur: — APerson241)는 어느 누구도 빨리 고칠 수 없으며, 관리자가 요청을 받을 때까지 앉아 있어야 하며, 보통 며칠이 걸린다. 기술 13 (토크) 15:48, 2013년 9월 11일 (UTC)[]

   글쎄, 나는 근거가 약하다고 생각했기 때문에 반대한다고 말했다. 여기서 제기되는 항목들 중 일부는 합법적인 사항이며 근거에 추가되어야 한다. —Anne Delong (대화) 22:56, 2013년 9월 11일 (UTC)[]

   (약해지고 있는..) 비록 나는 여전히 이 새로운 특권이 정말로 필요하다고 생각하지 않지만, 왜 그것이 편리하고 어쩌면 바람직할 지에 대한 좋은 논쟁이 있어왔다. 템플릿 편집 자격은 충분히 숙고된 것 같다. 편집 횟수가 좀 적은 것 같은데, 그건 내가 편집한 지 2주 정도 되는 시간이고, 위키피디아의 정책 내에서 작업하려면 경험이 필요하다. 나 역시 '신뢰' 자격의 약점에 대해서는 거의 걱정하지 않는다. 최근에 전쟁을 막거나 편집하지 않는 것은 별로 지지할 만한 것이 못 된다. 합의 과정에 대한 이해를 증명하는 것을 추가하는 것은 어떨까? 그리고 행정관들이 특권을 정지하기 전에 합의 없이 논란이 되는 편집의 '패턴'이 생길 때까지 기다리는 모습을 보고 싶지 않다. —Anne Delong (talk) 16:18, 2013년 9월 13일 (UTC)[]

   • 나는 그 제안서를 읽는 데도 같은 고민을 했다. "정당한 편집요청 언어화"를 "논의적이지 않은 편집요청 언어화"로 바꾸면 내 걱정은 사라질 것이다.--Wikimedes (대화) 23:38, 2013년 9월 14일 (UTC)[]
     • 그것은 타당해 보여서 내가 제안했던 대로 변경했어. Equazcion 23:44, 2013년 9월 14일 (UTC)
2. 자격 있는 반대 몇 달 전에 이런 일이 일어났던 것과 같은 이유로 나는 이것이 심각한 문제라는 것을 여전히 확신하지 못하는데, 그러한 극단적인 조치들이 그것을 해결하기 위해 다시 요청된다. 나는 또한 현재 거의 사용되지 않고 있는 보류 중인 변경사항 수준 2를 다시 구매하여 새로운 사용자 권리와 보호 수준을 만들지 않고 정확히 같은 것을 달성하는 훨씬 더 간단한 아이디어를 지지한다. 그렇게 해서 우리는 단순히 존재할 수 없다. WMF가 이 아이디어를 알고 있는지 알 수 있을까? 개발도 제대로 될 수 있을까? 이것을 제안한 사람들은 이것이 승인되고 WMF가 그것을 시행하는 데 동의하더라도 그것이 현실이 되려면 아마도 6개월에서 1년이 걸릴 것이라는 것을 알고 있는가? 이전의 모든 논의에도 불구하고, 이것은 여전히 우리가 이미 가지고 있는 도구를 사용하여 훨씬 더 간단한 옵션을 무시하는 형편없는 생각의 제안으로 나를 놀라게 한다. Beeblebrox (대화) 15:39, 2013년 9월 11일 (UTC)[]

   PC2를 이러한 방식으로 사용할 수 있는 가능성에 대해 논의한 이 제안서의 초안 토크 페이지에서 이 토론을 참조하십시오. 현재 이러한 방식으로 PC2를 사용하는 데는 몇 가지 문제가 있으며, 여러 가지 방법(예: 코딩)으로 허가가 작동하는 방식을 변경해야 할 것이다. 미디어위키 구성 파일에 약간의 새 텍스트만 있으면 되기 때문에 실제로 새 권한을 만드는 것이 더 간단하다. 같은 토론에서, 당신은 몇몇 개발자들이 이 제안을 알고 있다는 것을 알게 될 것이고, 그들 중 한 명은 지역사회가 그것을 결정할 때 새로운 허가가 실현 가능하다고 말했다. equazcion 15:44, 2013년 9월 11일 (UTC)

   PS. PC2가 이미 많은, 많은 사용자에게 이러한 기능을 염두에 두지 않고 제공되었다는 사실 또한 있다. 고위험 템플릿을 편집할 수 있는 능력을 갖추려면 어느 정도 특별한 검사를 받아야 한다고 가정한다면, 그러한 검사를 거치지 않은 사람들에게 이미 완전히 부여된 허가를 재사용하는 것은 현실적으로 불가능해 보인다. Equazcion 15:53, 2013년 9월 11일(UTC)

   관리자 도구 세트가 급격한 상황에 대한 대응인가, 아니면 신뢰할 수 있는 사용자가 이미 수행하는 종류의 노력을 지원하기 위해 이를 제공하지 않는가? 이건... 과격한... 숙련된 코더에 대한 생산성 증가 - 플로이드 18:09_¢, 2013년 9월 11일 (UTC)[]

3. 반대 옛날에, 몇몇 선각적인 사람들은 일반 대중들이 옳은 일을 할 수 있다고 믿을 수 있다는 터무니없는 생각을 바탕으로 백과사전을 짓기 시작했다. 게다가, 어떤 악한 행위자라도 선한 사람들에 의해 너무 많은 수가 될 것이고 최종 결과물은 예외적일 것이다. 그들이 옳았다. 여기 우리는 백과사전을 만드는 터무니없는 일을 할 수 있다고 믿었던 이 일반 대중들에 의해 만들어진 430만 개의 기사의 산 위에 앉아 있다. 그리고 이제 우리는 "아니, 우리는 당신을 믿지 않는다. 아니, 당신이 만든 것은 당신으로부터 보호되어야 한다. 아니, 당신은 이제 계속 확대되고 있는 우리의 관료제도에 있어서 특권을 추구해야 한다. 거울 속의 당신 자신을 보라. 위키백과가 시작되었을 때 여기에 표현된 태도가 존재했다면 위키백과는 존재하지도 않았을 것이다. 이 빌어먹을 프로젝트를 만든 대중을 믿고 템플릿을 보호하지 마십시오. 단 한 번도 반달리즘을 저지른 적이 없지만, 필요한 경우가 수없이 많았는데도 템플릿 편집을 신뢰할 수 없다. 아니, 대신 나는 믿을 수 없는 사람에게 부탁해야 해. 왜냐하면 나는 믿을 수 없으니까. 도대체. --Hammersoft (대화) 21:33, 2013년 9월 11일 (UTC)[]

   일리가 있겠지만, 이상적 상황이 없는 상황에서는, 전부 또는 무(無)의 입장을 취하기보다는, 그것을 필요로 하는 더 많은 사람들에게 접근을 제공함으로써 사물을 한 발짝 더 가까이 다가가는 것이 좋지 않을까? Equazcion 21:42, 2013년 9월 11일(UTC)

   아니, 사람을 믿거나 믿지 않거나 둘 중 하나야 당신은 확대되는 관료주의의 문제를 해결하기 위해 관료주의를 확장하지 않는다. --Hammersoft (대화) 21:53, 2013년 9월 11일 (UTC)[]

   이것은 완벽한 것을 선의 적이 되게 하는 것 같다, 해머소프트. 여기서 당신의 관점을 이해한다고 생각하지만(나는 동의하지 않는 경향이 있지만), 그 논쟁은 이미 없어졌다고 생각한다. 나는 고도로 사용된 템플릿을 반단위로 다시 보호하거나 보호하지 않는 것에 대한 합의가 있을 것이라고 생각하지 않는다. 만약 그것이 사실이라면, 여러분과 같은 경험 많은 사용자들이 이러한 템플릿을 편집할 수 있는 가장 좋은 방법은 무엇인가? 이건. --Floquenbeam (대화) 22:11, 2013년 9월 11일 (UTC)[]

   해머소프트, 이 제안은 편집자들이 현재 가지고 있는 어떤 능력도 빼앗지 않을 것이다; 그것은 그 반대로, 일부 사용자들에게 추가적인 능력을 주고, 그들에게 더 많은 신뢰를 줄 것이다. 그러므로 이것은 비록 끝까지가 아니더라도 당신이 원하는 방향으로의 움직임이어야 한다. 한 가지 가능한 부작용: 일단 보호된 템플릿을 편집하는 코더가 많으면, 이를 보호하지 않는 이유 중 하나가 제거될 것이기 때문에 더 많은 템플릿이 보호되어야 한다는 생각이 들 수 있다. —Anne Delong (대화) 22:50, 2013년 9월 11일 (UTC)[]

   내 요점은 그 권리를 원래 있던 곳으로 돌려주는 것이다. 이것은 마치 나를 위해 일을 대신 해달라는 나의 요청에 더 많은 사람들이 대답할 수 있을 것이기 때문에 내 일을 바로 가져간 다음, 상황이 나아지고 있다고 말하는 것과 같다. 그리고 나는 이것에 대해 행복해야 한다고? 프로젝트에서 가장 눈에 띄는 기사를 편집할 수 있을 정도로 신뢰할 수 있는 사람이 신뢰받는 데 몇 년, 몇 번의 편집이 필요한가? 내가 대신 대답해줄게. 0, 두 경우 모두 0. 하지만 템플릿 편집은 신뢰할 수 없는가? 무슨 일이 일어날지 말해줄게. 지금 8:1로 통과하고 있다. 지금부터 1년 후에는 훨씬 더 많은 템플릿이 보호될 것이고, 나는 내가 과거에 했던 일을 할 수 있는 프로젝트에 대해 훨씬 더 적은 권한을 갖게 될 것이다. 하지만 괜찮아, 이건 ANYone이 편집할 수 있는 프로젝트야..."신뢰할 수 있는" 한. 하지만 난 믿을 수 없어. 난 그저 구두끈을 묶을 수 있는 천박하게 멍청한 편집자일 뿐이니까. --Hammersoft (토크) 12:58, 2013년 9월 12일 (UTC)[]

   기사를 편집하면 기사에 오류가 발생할 수 있다. 템플리트의 오류는 수십만 개의 기사와 현재 서버 문제에 오류를 일으킬 수 있다. 그것이 그 차이점의 이유야. 나는 당신의 두 번째 요점이 있을 가능성에 대해 동의하지 않는다. 그리고 그것은 적극적으로 맞서 싸워야 한다. SFB 21:10, 2013년 9월 20일 (UTC)[]

4. 반대한다. 나는 이것을 사용할 수 있게 되면 더 많은 사람들이 더 많은 템플릿을 편집하도록 하는 목표와는 반대로, 세미 프로텍션이 더 적절할 때 그것을 사용할 수 있게 될까봐 걱정한다. 나는 이것이 가능해지기 전에 각 수준의 보호가 언제 만들어져야 하는지에 대해 더 강력한 지침이 필요하다고 생각한다. Jackmcbarn (대화) 12:33, 2013년 9월 12일 (UTC)[]

   Jackmcbarn 그것은 초안 작성 중에 제기되었던 유효한 사항이며, 아마도 처음에 RfC 텍스트에서 다루었어야 했을 것이다. 나는 위에 이것에 대해 무언가를 추가했다. #특권 아래에. Equazcion 12:50, 2013년 9월 12일(UTC)

   @Equazcion:나는 "이런 일이 일어나지 않도록 하라"는 문단을 포함시킬 생각이 없다. 나는 더 강력한 해결책이 필요하다고 생각한다. Jackmcbarn (대화) 17:35, 2013년 9월 15일 (UTC)[]

5. 나는 도구 분리를 전반적으로 지지하며, 따라서 비관리자가 단지 일부 페이지보다 완전히 보호된 페이지를 편집할 수 있는 사용자 권한을 구현하는 것을 선호한다. 나는 이와 같은 과잉 전문화가 정당화될 수 없다고 확신한다: 나는 이 사용자 권리를 추구하는 사람이 높은 기준을 가질 것이라고 확신하기 때문에, 나는 만약 누군가가 한 유형의 보호된 페이지를 편집하는 것으로 신뢰받는다면 다른 페이지를 편집하는 것으로 신뢰받을 수 있다고 생각한다. 과장에 의존하지 않고, 나는 이것이 비관리자에 대한 여러 가지 혼란스러운 보호 사용자 권한을 가질 수 있는 디딤돌이 되지 않기를 바란다. 나는 RfA의 단일 목적의 허심탄회함의 "문제"에 대해서도 확신할 수 없다: 그것들은 과정을 압도하지도 않고 큰 부담도 아니다. 아칼라마리 13:25, 2013년 9월 13일 (UTC)[]

   그러나 많은 사람들은 단일 목적의 RFA에 대해 여전히 불편해 보이는데, 통과를 시키는 것은 앞뒤가 맞지 않는다; 그리고 그것은 대부분의 열성적인 코드 사용자들이 RFA를 통과하는데 관심이 없고, 다른 관련 도구들과도 무관하다는 사실을 무시하는 것이다. 당신이 제안하는 방식으로 번들을 풀려는 제안은 반복적으로 실패해왔기 때문에, 우리의 열렬한 코더들이 마침내 그들이 필요한 곳에서 일할 수 있게 할 수 있는 차선책을 시행하는 것이 이치에 맞지 않을까? Equazcion 15:05, 2013년 9월 13일 (UTC)

   "비관리자에 대한 여러 가지 혼란스러운 보호 사용자 권한을 갖기 위한 디딤돌"이라는 특정 요점을 다루기 위해 제안서에 추가할 수 있는 것이 있는지 모르겠다. IMO가 이것을 일회성 상황으로 만들지만, 그것은 타당한 우려다. - 포인트리스트 (토크) 16:27, 2013년 9월 13일 (UTC)[]

   만약 그것이 특정한 것에 능한 사람들 중 더 많은 사람들이 그것을 하도록 허용하고 또한 멀리까지 도달하는 도구 꾸러미를 주지 않으려는 사람들의 걱정을 덜어준다는 것을 의미한다면, 앞으로 지역 특유한 권리들이 더 이상 커지게 되는 것이 무엇이 그렇게 나쁜 것인지 나는 완전히 확실하지 않다. 나는 "충돌"이 뒤따를 것이라는 것에 대해 다소 회의적이며, 심지어 몇몇 사람들이 위키피디아에서 이용 가능한 다양한 권리들을 조사했을 때 혼란에 빠졌다고 해도 그것은 다소 쉽게 다룰 수 있는 것이 아니다. 게다가, 나는 이런 조치들이 취해질 때, 실제 분쟁이 더 많은 사람들에게 이해되기 시작할 수 있고, 개인의 권리가 결합되기 시작할 수도 있다고 생각한다. 어느 쪽이든, 우리가 실제로 단계를 시행하기 시작하지 않고, 대신에 우리의 다양하고 많은 개인 이상이 완전히 충족되도록 요구한다면, 이 중 어떤 것도 일어날 수 없다. 위키백과가 무엇이 되어야 하는지에 대한 그들의 이상을 가지고 있지만, 그러한 이상을 바탕으로 한 요구를 하는 것은 우리를 전혀 진전시키지 못하게 한다. 등거리 16:36, 2013년 9월 13일 (UTC)

   음, 하지만 이 RfC는 이 특정한 경우보다는 일반적인 분열을 푸는 것이어야 할 겁니다. 이 제안이 많은 지원을 받는 이유의 일부인 템플릿 유지보수를 위한 특별한 사정이 있다. 필자는 반드시 "향후 더 이상의 지역 특유한 권리에 대해 나쁜 점이 있을 것"이라고 말하는 것은 아니지만, 물론 다른 편집자들은 점진주의/간단한 쐐기 끝 등에 대해 우려할지도 모른다. IMO. - Pointillist (토크) 16:55, 2013년 9월 13일 (UTC)[] 이 RfC를 가능한 한 좁게 유지하는 것이 가장 좋다.

   만약 몇몇 지역 특유의 권리들이 유사한 덕목을 수반하는 것처럼 보인다면, 그 경계 아래 분리가 사람들에게 이치에 맞기 시작할 수도 있다. 그렇다고 해서 RFC가 번들거릴 필요가 있는 것은 아니다. 나는 예측할 수 없는 미래에 무슨 일이 일어날지 모르겠고 또한 그러한 예측이 이 제안의 일부분일 수도 있다. 단지 하나의 가능성일 뿐이다. 내가 아는 것은 그런 일이 일어나기를 원하는 사람들은 전자가 그럴 가능성이 낮다는 것이 증명되었듯이, 지금이나 아니면 논쟁의 여지가 없을 정도로 작은 부분이라도 그 일이 일어날 수 있도록 요구함으로써 스스로를 위해 봉사하고 있지 않다는 것이다. Equazcion 17:12, 2013년 9월 13일 (UTC)

   100% 동의 - 포인트리스트 (대화) 18:12, 2013년 9월 13일 (UTC)[]

6. Hammersoft와 Jackmcbarn에 반대한다. 또한 이 "특권"을 부여하기 위한 지침 #1은 거의 터무니없고 새로운 템플릿 편집자들을 몰아낼 뿐이며, 아마도 위키피디아의 일반적인 편집증과 익명성 무시에서 비롯되었을 것이다. — Lfdder (대화) 17:45, 2013년 9월 13일 (UTC)[]

   이와 같은 제안은 과거에 그러한 권리와 관련된 사람들이 입증되지 않은 손에 들어가는 저항을 불러일으켰기 때문에, 그 우려들을 완화시킬 수 있다는 희망으로 가이드라인이 보수적으로 작성되었다. 다소 보편적으로 받아들여질 수 있는 지침을 마련하는 것은 만약 이것이 통과된다면 미래에 다루어질 수 있는 도전이다; 그리고 그 지침은 엄격한 규칙과 거리가 멀다. 권한을 부여한 관리자는 편집자가 자신이 능력 있고 신뢰할 수 있음을 입증했는지 여부를 평가할 때 자신의 재량권을 사용할 것이다. Equazcion 18:06, 2013년 9월 13일 (UTC)

7. 반대하라 난 필요없다고 본다. 기본적으로, 나는 Beeblebrox에 동의한다. 사람들이 다른 6명의 반대자들과 했던 것처럼 논쟁하고 싶다면, 나는 좀처럼!보트를 다시 찾지 않는다.--Wehwalt (대화) 00:03, 2013년 9월 15일 (UTC)[]

   단지 FIY, 나는 반대자들의 반응을 얻기 위해 그런 경우들에 논쟁을 게시한 것이 아니라, 오히려 구경꾼들에게 그들이 제기한 독특한 문제들에 대한 반대가 있다는 것을 알려주기 위해서였다. 네가 그렇게 하지 않았으니, 나는 여기에 논쟁 글을 올리지 않을 거야. Equazcion 00:22, 2013년 9월 15일(UTC)

8. 반대: "완전한 보호는 압도적인 논쟁의 상태를 보여준 템플릿의 이상적인 임시 해결책이지만, 그것은 기사에 대한 영구적인 예방 조치로서 덜 이상적이다. 기사 편집에 적성을 보이고, 자신의 업무를 수행하면서 지역사회의 신뢰를 얻은 많은 편집자들이 반드시 관리자일 수도 없고, 관리자가 되는 것에도 관심이 없을 수도 있다.
   "비관리자는 관리자가 자신을 대신하여 제정할 수 있도록 완전히 보호된 기사에서 편집을 요청할 수 있는 능력이 있지만, 이를 신뢰할 수 있도록 시간과 평정을 갖춘 관리자가 상당히 부족하다. 편집자들은 또한 이러한 추가 조치를 단순한 짜증보다 더 많이 발견하는 경향이 있다. 편집 작업은 창의적인 경험을 중시한다는 점에서 언어적 마인드를 가진 사람들에게 큰 보람을 준다. 많은 사람들은 결국 완전히 보호된 기사에 대한 작업을 완전히 피함으로써 다른 사람이 자신을 대신하여 편집을 제정하도록 설득하기 위해 만들어진 논란의 여지가 없는 편집 요청을 구두로 표현하지 않아도 되는 것을 선택하게 된다.
   "현재 기사 편집 노하우를 가진 신뢰할 수 있는 편집자만 출입할 수 있는 조치가 없어 일부 편집자는 관리직 신청에 의존하고 있다."브라이스허그(토크) 05:50, 2013년 9월 15일(UTC)[]
   • 나는 네가 말하는 요점을 이해하지만 유사점은 같지 않다. (하지만 나는 보호되는 페이지 편집자가 있어야 한다고 생각하지만, 그것은 이 RfC가 아니다.) 완전한 보호는 템플릿에 대한 임시 해결책이 아니며.... 그리고 영구적인 보호는 기사에 있어서 그렇게 흔한 것이 아니다. "파란색" 페이지는 파란색이 많은 페이지에 사용된다는 이유만으로 보호되는 것이 아니라, 템플릿 공간만으로 페이지를 완전히 보호할 수 있는 좋은 이유가 될 것이다. 보호된 기사(특히 그러한 페이지들이 이의를 제기하는 경향이 있고 활성 관리자의 감시 목록에서)를 지원하는 훨씬 더 큰 관리자 풀이 있는 반면 템플릿에 대한 편집 요청을 적극적으로 감시하는 관리자는 3명뿐이다. 기사에 대한 수정 작업이 지연되면 편집 요청이 실행될 때까지 해당 기사만 "불완전한" 상태로 남게 된다. 높은 가시성 템플릿에 대한 수정 작업이 지연되면 많은 페이지가 손상될 것이다. 또한 템플리트를 변경하려면 템플리트를 사용하는 모든 페이지를 변경해야 할 수 있으며, 이는 프로세스에서 오버헤드가 확대될 수 있음을 의미한다. PaleAqua (talk) 06:45, 2013년 9월 15일 (UTC)[]

   중요한 것은 보호 템플릿 대 기사 수가 아니라, 템플릿이 편집되는 빈도, 또는 편집하려는 사람이 있는 빈도 입니다. 왜 기술자가 뒷구멍을 뚫지? Brycehughes (대화) 07:04, 2013년 9월 15일 (UTC)[]

   그것은 사람들이 기술적으로 마음먹는지 아닌지에 관한 것이 아니다. 중요한 것은 많은 템플릿이 있는 반면, 기사는 "예방의 차원에서" 보호되지 않는다는 것이다. 보호정책을 인용하면 "기사의 사전 완전보호는 위키피디아의 개방성에 반한다"는 것이다. 아무도 우리가 엉망일 가능성이 있기 때문에 고사용 템플리트를 개방해야 한다고 주장하지 않는다. 야리스678 (토크) 07:52, 2013년 9월 15일 (UTC)[]

   나는 페이지나 템플릿이 보호되는 이유가 위키백과 프로젝트의 이익을 위해 해결해야 할 진정한 문제가 존재하는지 여부에 어떤 관계가 있는지 모르겠다. 나는 템플릿이 어떻게 사전에 보호되는지 알고 있다. 템플릿 편집을 좋아하는 사람들을 짜증나게 할 수 있다. Brycehughes (대화) 08:04, 2013년 9월 15일 (UTC)[]

   만약 사전에 보호되는 많은 기사들이 있다면, 사람들은 아마도 그것들을 편집할 수 있는 사용자 권리를 주장할 것이다. 그렇다, 그러한 주장은 아마도 그들이 사전 예방적으로 보호된 기사들을 편집하지 못하는 것에 대해 짜증을 내는 것에서 나올 것이다, 하지만 그렇게 나쁜가? 확실히 사용자들을 성가시게 하지 않는 것은 좋은 일이다. 야리스678 (대화) 09:34, 2013년 9월 15일 (UTC)[]

   또 다른 사용자 권리를 만들자는 것이 유일한 주장일 때는 좋지 않다. 지금 몇 명이지? 16명? 다른 사람들은 모두 WP:진정하고 편집이 진행될 때까지 기다리십시오. 나는 우리가 템플릿 편집자를 위해 특별한 예외를 만들어야 하는 이유를 모르겠다. Brycehughes (대화) 14:41, 2013년 9월 15일 (UTC)[]

   단순히 성가신 것에 관한 것이 아니다. 위에서와 연계된 토론에서 모두 그 근거를 읽는다면; 논쟁을 위해서, 비록 어떤 일을 할 수 있는 사람들이 그 일을 완전히 그만둘 정도로 충분히 짜증난다면, 그것은 충분한 이유가 될 수 있다. 만약 기사가 선제적으로 보호되고 편집 요청이 요구되었고, 그것이 모든 숙련된 콘텐츠 기고자들이 콘텐츠 기고를 중단하게 했다면, 사람들은 변화를 고려해야 할 이유를 생각할 것이다. 어쨌든, 여러분의 "뒷문" 코멘트에 답하기 위해, 템플릿은 완전히 보호된다. 왜냐하면 필요한 기술과 책임이 없는 사람들은 한 번의 실수로 많은 피해를 입힐 수 있기 때문이다. 기사 공간에서 일어나는 모든 다양한 "ops" 편집은 만약 그것들이 높은 사용의 템플릿에서 일어난다면 엄청난 문제를 일으킬 수 있다. 그렇기 때문에 이 분야에 대해 학식과 책임감을 가지고 조사를 받은 사람들이 해당 허가를 받은 것처럼 제안되고 있는 것이다. 기술적으로 사고방식이 있는 사람들을 특별 대우를 받을 만한 상위 계층으로 보는 것이 아니라, 그들은 단지 이 특정 영역에서 안전하게 도움을 주기 위해 독특하게 적합하다. Equazcion 14:59, 2013년 9월 15일(UTC)

   그것은 말이 안됩니다. 제안서에 따르면 권리는 편집자가 '간단하고 일반적으로 논란의 여지가 없는 템플릿 편집'을 할 수 있도록 하고, 더 많은 '복잡하거나 논쟁적인 편집'은 시험과 합의의 대상이 된다. 간단한 편집을 위해 필요한 기술 수준은 무엇인가? 이것은 우리 중 가장 "숙련"하고 "책임감 있는" 사람들만이 그러한 무서운 템플릿 비상 상황에서 즉시 사용할 수 있는 새로운 도구를 만드는 것이 아니다. 사실 그러한 상황은 사전 예방적 보호에 의해 예방된다. 오히려 자신의 사용자 권리를 위해 위키백과 커뮤니티에 로비를 할 수 있는 권한을 가진 사람들을 위한 새로운 특권을 만드는 것이다. Brycehughes (대화) 15:35, 2013년 9월 15일 (UTC)[]

   간단한 편집을 위해 필요한 기술 수준은 없다. 그러나 어떤 편집이 간단한지 결정하는 데는 필요한 기술 수준이 있다. 할 수 있는 사람들을 위한 새로운 특권을 만드는 것에 대해, 나는 당신이 아마 그런 말을 하지 않을 역사에 익숙하다면 말하겠다. 이것은 여러 해 동안 계속되어온 골칫거리였고, 지금까지 아무도 로비력을 가지고 있지 않았다. 문제의 허락을 받을 사람들은 지금까지 결정적으로 할 수 없다고 해서 이렇게 오랫동안 이 일을 계속하지 않았을 것이다. 그리고 만약 그것이 누구에게도 영향을 준다면, 이 제안의 저자인 나는 그것이 현실이 된다면 허락을 신청할 계획이 없다. 사실 이 RFC가 통과로 폐쇄된다면, 나는 "퇴직한" 배너를 다시 걸게 될 것이다. Equazcion 16:28, 2013년 9월 15일(UTC)

   어떤 템플릿 편집이 간단한지 결정하는 데 필요한 기술 수준이 사실이라면, 모든 템플릿은 그러한 기술이 없는 편집자로부터 보호되어야 할 것이다. 하지만 그들은 그렇지 않아, 왜냐하면 너의 진술이 사실이 아니거든. 네 다년간의 두통에 대해서, 그게 내 요점을 어떻게 반박하는 거지? 특권을 위한 로비 노력은 실패할 수 없다? 몇 년 동안 못 버텨? 과거 문제가 정확하게 결정됐음을 확인하는 것 외에 우리 앞의 비용/편익 분석과는 아무런 관계가 없다. Brycehughes (대화) 17:07, 2013년 9월 15일 (UTC)[]

   네가 속셈이 있어서 내가 역사를 꺼내는 거야. 당신은 허락을 받을 사람들이 로비의 책임이 있다고 말하고, 단순히 할 수 있기 때문에 그렇게 하고 있고, 그것이 그들에게 이익이 될 것이기 때문에 그렇게 하지 않을 이유가 없다고 말한다. 처음 한두 번 시도했을 때 그들이 할 수 있다고 해서 뭔가를 얻으려 했지만, 그들이 할 수 없는 것이 분명해 보였을 겁니다. 이 시점에서, 이런 일이 이렇게 오래 지속되었다는 것은 분별할 수 있어야 한다. 왜냐하면 그러한 잠재적 편집자들 외에 많은 사람들은 백과사전이 이런 것을 필요로 한다고 믿기 때문이다. 그리고/또는 적어도 개선은 될 것이라고 믿기 때문이다. 물론, 기술자들이 이 일을 시작했으며, 이 모든 부당한 지원을 초래한 것에 대해 비난을 받아야 한다는 비난은 실제로 어느 쪽이든 증명할 수 있는 것은 아니다. 내가 할 수 있는 일은 이 일이 성사되면 내 스스로 허락을 받지 못할 것이라고 말하는 것뿐인데, 적어도 내 의도를 보여주길 바라야 할 것이다. 나는 또한 당신이 모든 사람의 동기를 평가하기 보다는 이 제안의 잠재적인 순비용과 그것의 순이익의 비교를 볼 것을 요청할 수 있다. Equazcion 17:28, 2013년 9월 15일 (UTC)

   나는 속셈을 하지 않았다 나는 쉽게 볼 때 동기를 가정해 본 적이 있는데, 그것은 또한 당신의 전제가 되기도 하기 때문이다. 제안 배경에는 템플리트 편집을 좋아하는 사람들은 편집이 승인되기를 기다리는 것을 좋아하지 않는다고 분명히 명시되어 있다. 이 제안을 실행함으로써 위키피디아는 템플릿 편집을 좋아하는 사람들을 행복하게 만들 것이다. 내가 그들 중 한 명이라면, 나도 아마 이것이 좋은 생각이라고 생각할 것이다. 그러나, 더 큰 그림에서, 나는 또한 나와 템플릿 편집자 동료들이 프로젝트 전반에 영향을 미치기 때문에 다른 편집자 계층을 설립하는 것에 반대하는 특정 그룹의 편집자들에게 특권을 부여함으로써 얻을 수 있는 이점을 축소하고 저울질할 수 있기를 바란다. 여기에는 제안의 약점에 대한 공격 외에는 비난이 없다. Brycehughes (대화) 17:55, 2013년 9월 15일 (UTC)[]

   나는 당신의 첫 번째 요점에 대답하는 것을 잊었다: "만약 어떤 템플릿 편집이 간단한지 결정하는 데 필요한 기술 수준이 사실이라면, 모든 템플릿은 그러한 기술을 가지고 있지 않은 편집자들로부터 보호되어야 할 필요가 있을 것이다." -- 대부분의 템플릿은 충분히 널리 퍼져 있지 않아서 그것들을 편집하는 것이 심각한 문제를 일으킬 수 있다. 그것들은 수천 페이지에 존재하기 때문에 보호된다. 템플릿의 취약성을 고려할 때 편집이 위험 없이 수행될 수 있을 정도로 간단한지 여부를 판단하려면 필요한 기술 수준이 필요하다. Equazcion 17:45, 2013년 9월 15일 (UTC)

   그런 다음 템플릿을 편집하는 데 시간을 할애하여 이러한 위험을 감수할 만큼 광범위하지 않은 대부분의 템플릿을 편집하십시오. 영구적으로 보호되는 템플릿의 경우 편집 요청을 수행하십시오. 다른 사람들처럼. 보호된 템플릿 편집이 완료되는 것을 보기 전에 세상은 끝나지 않을 것이다. Brycehughes (대화) 2013년 9월 15일 18:00 (UTC)[]

   "그렇다면 이런 위험을 감수할 만큼 널리 퍼지지 않은 대부분의 템플릿을 편집하는 데 시간을 투자하십시오." -- 이것이 바로 현재 그들이 하고 있는 일이다. 그래서, 널리 퍼져있는 템플릿에 대한 작업은 어려움을 겪는다. Equazcion 18:04, 2013년 9월 15일 (UTC)

   그래야지, 위험성이 높으니까 Brycehughes (대화) 18:07, 2013년 9월 15일 (UTC)[]

9. 반대 - 형편없는 생각의 제안. 사용자 권리를 부여하는 기준은 WP:CREP의 끔찍한 경우인데, 나는 또한 그 요점을 알지 못한다. 3-템플릿 요건에서 이는 여전히 {{protected}}을(를) 사용해야 하는 특정 영역보다는 전체 사이트에 걸쳐 템플릿을 유지하려는 사용자들을 목표로 하는 것으로 보인다. 만약 누군가가 사이트 전체의 유지관리에 관심이 있다면 관리직에 출마할 것을 권장한다. 그렇지 않다면 샌드박스와 {{editprotected}}{{editprotected}}}}를 나머지 우리와 같이 사용하십시오. 여기서 가장 큰 문제는 사용자권의 부족이 아니라 선제적 보호의 남용이 문제다. --W. D. Graham 08:45, 2013년 9월 15일 (UTC)[]
10. 반대-이것은 많은 학대를 초래할 수 있다. 이 지위를 얻기 위한 기준은 권력이 남용되지 않을 만큼 엄격하지 않다. 스누드1205 (대화) 01:02, 2013년 9월 16일 (UTC)[]
11. 임시 "규칙 크리프"로서 반대 - "ref fix flag", "typasso fix flag", "personal attack deletion flag" 등이 필요할 것이다 - 나는 십여 개 이상의 특별한 목적 깃발을 생각할 수 있다. 이 추가에 대한 진짜 이유가 없는 한, 나는 반대한다. 수집(대화) 13:20, 2013년 9월 16일 (UTC)[]

    너는 여기서 사과를 오렌지와 비교하고 있다. 현재 참고문헌을 고치고 오자를 고치고 인신공격을 삭제하는 데 행정적 권한이 필요하지 않다. 그러나 완전히 보호된 템플릿을 편집하려면 관리자 권한이 필요하다. AutomaticStrikeout (1998년) 17:10, 2013년 9월 20일 (UTC)[]

12. 반대는 좋은 생각이지만 나는 이것이 기대했던 대로 되지 않을 것이라고 생각한다. 문제가 생길 수도 있어 조금 더 엄격하고 조금 더 명확해. 그때까지 여기 좋은 게 있을지도 몰라. 나는 반대한다. FockeWulf FW 190 (토크) 15:10, 2013년 9월 16일 (UTC)[]
13. 반대한다. 나는 왜 이것이 필요한지 모르겠고 이것이 너무 많은 조각이 될 것이라는 것에 동의한다. 사용자가 완전히 보호된 템플릿을 편집하도록 신뢰할 수 있는 경우, 관리 작업을 통해 동일한 사용자를 신뢰할 수 있는지 확인하십시오. 다른 관리 작업을 수행하지 않으려면 수행할 필요가 없으므로 원하는 템플릿에서만 작업할 수 있다. 결국 우리는 모두 자원 봉사자들이야. 그리고 만약 그들이 전혀 관리자가 되고 싶지 않다면(또는 과정을 거치기 위해), 그들은 샌드박스에서 템플릿 작업을 계속한 다음, 완료되었을 때 업데이트 요청을 제출할 수 있다. 약간 불편할 수도 있지만 새로운 권리의 이행이 필요한 것은 아니다.—erzhiki(Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 16일; 19:45(UTC)
14. 반대 - 보다 기술 지향적인 사람들이 보호된 템플릿을 편집할 수 있는 능력이 필요하지만, 해결책은 그들을 관리자로 만드는 것이다. 바로 위의 에에지키의 주장은 전적으로 내가 동의하는 것이다.-- 마이클 스콧 커트버트(토크) 03:23, 2013년 9월 17일 (UTC)[]

    어떤 사람들은 이상적이라고 생각할지 모르지만, 현재의 상황은 그것을 실행 가능한 해결책으로 배제하고 있다. 이러한 편집자들은 주로 관리직에 지원하기를 원하지 않으며, 그럴 수도 있는 편집자들에게도, 그 단일 목적만으로 관리직에 지원하는 사람들을 홍보할 것인지 아닌지에 대한 커뮤니티의 일반적인 느낌은 분분하다. 관리자가 이용할 수 있는 도구는 많은 사람들이 잠재적 관리자가 특정 정치적 위상을 증명할 뿐만 아니라 대부분의 경우 사용할 수 있고 이해가능하다고 느끼는 광범위한 영역을 포괄한다. 많은 사람들은 그것이나 다른 이상들이 이기기를 원하지만, 타협이 가까운 미래에 이용할 수 있는 유일한 실용적인 해결책일 수도 있다. 2013년 9월 17일 03:42, Equazcion (UTC)

    관리 애플리케이션이나 편집자들이 템플릿 작업에만 관리자 비트를 부여하고 싶어하지 않는 것은 잘 이해할 수 있지만, 샌드박스에서 템플릿을 편집한 다음 작업이 완료되면 업데이트를 요청하는 것이 무엇이 그리 비현실적인지 아직도 잘 모르겠다. 나는 템플릿 작업을 직접 공평하게 분담해 왔으며, 관리인이든 아니든 간에 보호되는 매우 눈에 잘 띄는 템플릿은 절대로 라이브 작업으로 작업해서는 안 된다. 그러니까 본질적으로 나 같은 관리자와 비관리자 템플릿 노동자의 차이점은 비관리자가 요청을 하고 아마도 며칠을 기다려야 하는 동안 내가 일을 마치면 직접 게시할 수 있다는 겁니다. 나는 단지 이 접근방식이 새로운 권리의 이행을 요구하는데 무엇이 그렇게 문제가 되는지 모르겠다.—erzhiki(Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 17일; 13:52(UTC)

    트라피스트의 질문 #8에 대한 답변은 위의 많은 지지 논평과 마찬가지로 거기에서 약간의 통찰력을 제공한다. 현재의 시스템은 비효율적이고 기술자들이 기여하는 것을 방해한다. 편집은 편집이 올바른지 여부를 평가하기 위해 친숙하지 않은 다양한 관련 없는 프로젝트로 이동하는 것이 업무인 일부의 승인을 요구하기 보다는 적극적으로 관여하거나 최소한 관심이 있는 동료들 사이에서 확인될 수 있어야 한다. 코딩의 특성은 그러한 영역에서 보호된 편집 요청에 응답하는 것을 보호된 기사 편집에 비해 실질적으로 다르고 관련된 노력들로 만든다. 이것이 실제로 그것을 하기 위해 스스로 그것을 떠맡는 관리자가 없는 이유다. 나는 관리자로서 코딩에 대한 경험이 있지만, 도움이 될 만한 코딩은 하지 않을 것이다. 이러한 변화와 그 결과(템플릿 코드가 더 다양하다는 사실에 의해 더 어렵게 만들어짐)에 대해 아무것도 모르는 프로젝트에 대해 반복적으로 뛰어들어야 하는 것은 두통을 유발하는 사업일 뿐이다.다른 대부분의 프로그래밍 언어보다 기능성에 영향을 주지 않고 체계적이고 읽기 쉽도록 만들기 위해, 그리고 적어도 내가 알기로는, 그러한 조사를 용이하게 하기 위해 이용할 수 있는 실질적인 개발 환경이 없다는 사실) 하지만, 결국, 현재의 시스템이 왜 작동하지 않는지 알기는 힘들지 몰라도, 사실은 그렇지 않다는 것이다. 열성적인 코드 사용자들은 사용량이 많은 템플릿에 대한 작업을 피하는 경향이 있기 때문이다. 이것은 그 자체로 문제가 있으며, 만약 우리가 변화를 제정할 수 있다면, 우리는 이것을 바꿀 것이고, 안전하게 할 것이다. Equazcion 14:13, 2013년 9월 17일(UTC)

    설명 고마워, 고맙긴 한데 그런 상황은 아닌 것 같아. 다른 사람의 코딩 작업을 거치며 해독을 시도하는 것은 실로 많은 일이긴 하지만, 과연 그럴 필요가 있을까? 버그는 템플릿 작업의 고유한 부산물로, 나중에 가장 부지런한 접근으로도 표면화될 수 있다. 샌드박스에 현재 변경 중인 템플릿의 모양과 변경 후 템플릿의 모양/구조에 대한 예가 포함되어 있는 한, 나는 개인적으로 템플릿 변경 요청을 승인할 것이다. 나는 만약 어떤 것이 제대로 보이지 않는다면 추가적인 시험 사례나 설명을 요구할 수도 있고 아닐 수도 있지만, 눈에 보이는 문제가 없고 어떤 중대한 변화들이 합의점을 가지고 있는 한, 그 코드를 깊이 파고들어 버그가 몰래 들어온 오프 체인지에 구문 분석할 필요는 없다. 그리고 만약 내가 몇몇 간과된 심각한 문제로 이어지는 수정을 승인한다면, 나는 문제의 첫 징후가 있을 때 그것을 되돌릴 준비가 되어 있다. 승인 관리자의 임무는 변경사항이 완벽하지 않은지 확인하는 것이 아니라, 변경사항이 악의적이지 않은지 확인하고, 기능적이며, 관련자 모두의 합의를 반영하는 것이다. 물론 검토 관리자의 일부 시간 약속이 필요하지만, 다른 보호된 편집 요청과 다를 바 없다.—erzhiki(Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 17일; 14:36(UTC)

    흠, 우리는 편집이 건전하게 이루어지도록 하기 위해 얼마나 많은 필요가 있는지, 또는 얼마나 확실한 건전성이 필요한지에 대해 논쟁할 수 있다. 하지만 어떤 식으로든, 나는 우리가 더 많은 잠재적 버그를 더 일찍 잡는 것이 더 쉽다면 더 낫다는 것에 동의할 수 있다고 생각한다. 더 많은 장비를 갖춘 사람들이 그러한 평가를 하게 하면 상황이 개선된다. 꼭 필요한가? 나는 사람들이 어떤 것이 필요하지 않고 따라서 실행되어서는 안 된다고 말하는 것이 무슨 뜻인지 잘 모르겠다. 당신과 내가 의지하게 된 많은 것들은 반드시... 아닌 개선의 결과였다. 뭐, 꼭 "거짓말"은 아니겠지 그리고 이것은 여러분이 그것을 어떻게 보더라도, 학위를 둘러싼 약간의 의견 불일치가 있더라도, 개선될 것이다. 또한, 더 많은 사람들이 적극적으로 참여하고 필요한 허가를 받는다면, 더 빨리 시행될 수 있는 해결책의 문제도 있다. (당신의 논평과 관련하여) 논쟁에 반대하는 유일한 진짜 반대는 계층 혼란인데, 나는 이것이 실제로 어떤 실질적인 문제로 해석된다고 생각하지 않는다. 하지만 우리는 아마도 그것에 대해 의견 차이를 보이는 것에 동의해야 할 것이다. Equazcion 14:55, 2013년 9월 17일(UTC)

    음, 나는 너를 어두운 쪽으로 끌어들이려고 하는 것이 아니다:) 나는 단지 내 입장을 다른 사람이 읽을 수 있는 사람에게 분명히 말하려고 하는 것뿐이니까, 우리가 동의하지 않는 것은 완벽하게 괜찮다. 내가 "필요하다"고 말한 것은 단순히 코드 수정을 구문 분석하기 싫다는 이유만으로 보호된 템플릿 편집 요청을 검토하는 것을 주저해서는 안 된다는 것이다. 명백한 문제(실제로 최소한의 기술적 지식으로 수행할 수 있음)가 없는지 확인하는 것으로 충분해야 한다. 그리고 그들이 수정 사항을 분석할 수 있다면, 그것은 단지 보너스일 뿐이다. 당신이 말하고자 하는 것(내가 당신을 정확히 읽고 있다면), 이것은 모든 것이 가장 미세한 세부사항으로 정리되어 있는지 확인하는 것을 선호하는 검토 관리자들 사이에 널리 퍼져 있는 태도가 아니라는 것(그리고 후자는 더 자주 발생한다). 이 말을 믿지 않을 이유가 없지만(만약 이것이 당신이 말하는 것이라면), 내 경험에 비추어 볼 때, 나는 그것이 사실이라는 것을 알아차리지 못했다. 그래서 나는 반대한다. 건배,———————Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 17일; 15:25(UTC)

    지지 #5는 관리자들 사이에 널리 행해지는 관행이 전면적인 검토를 피하는 것임을 나타낸다. 그리고 나는 더 나아가 그것을 세부적인 세부사항을 이해하고 싶은 욕구로 치부하지는 않을 것이다. "만약 그들이 수정사항을 분석할 수 있다면, 그것은 단지 추가 보너스일 뿐이다." -- 이 제안은 사실 표준일 수도 있는 "보너스"를 더 널리 이용할 수 있게 할 것이다. Equazcion 15:34, 2013년 9월 17일(UTC)

    그 코멘트를 지적해줘서 고마워. 그것은 계몽적인 코멘트야. 그러나, 변경사항이 적용되기까지 몇 주가 걸리더라도, 그것은 여전히 큰 문제가 되지 않는다고 동등하게 주장할 수 있다. 한편, 변경사항을 신속하게 적용하는 것이 중요한 템플릿의 경우, 변경사항을 이행하는 데 관심이 있는 사람들이 자신의 관심을 공유하고 변경사항을 이행하는 데 기꺼이 도움을 줄 수 있는 일부 개별 관리자에게 적극적으로 연락할 것이라고 생각할 수 있다. 어쨌든, 내가 본 바로는, 보호 템플릿에 대한 변경을 실행하기를 꺼리는 것은 기술적 전문지식의 부족보다는 그러한 변화를 둘러싼 자주 일어나는 논쟁에서 비롯된다. 즉, 제안된 깃발은 완화하기보다는 악화되기 쉽다.—에르지키(Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 17일; 16:01(UTC)

    우리 각자가 충분히 감정을 드러냈다고 생각하니까 이 일은 대부분 그냥 둘게. 하지만 내 생각에 영장 발부 사유에 대한 새로운 문제를 해결한 것 같아 그것은 우리가 다루고 있는 변경사항의 이행거부가 아니며, 또한 널리 퍼져있는 문제도 아니다. 내가 지적한 것에 대해 네가 이것을 언급했을 거라고 추측하지만, 네가 반대하는 실질적인 주장을 하지 않았다는 것에 대해, 하지만 나는 그 특정한 것에 대해 반칙을 해야 해, 왜냐하면 그것은 많은 것들에 대한 명백한 논쟁이기 때문이야. 물론 때때로 의견 불일치는 어디에서나 발생할 것이지만, 고용도 템플릿에서는 논쟁이 일반적인 이슈가 되지 않았다. 전체 프로세스의 비효율성 때문에 관리자와 코디네이터 모두 근본적인 참여가 부족한 것이다. 논란의 여지가 있는 변경은 제안서에 명시된 바와 같이 먼저 합의가 이루어져야 할 것이다. 그렇지 않으면 제정한 편집자의 허가가 위태로워질 것이다. Equazcion 16:55, 2013년 9월 17일(UTC)

    맞아, 내 마지막 부분은 제안서와 특별히 관련이 없었고, 여기에는 별로 관련이 없는 템플릿 코딩 과정의 전혀 다른 측면을 설명했어. 그러나 나는 일화적인 증거와 추측을 지지하기 위해 주저하기 때문에 내 나머지 주장에 동의한다. 물론, 나는 내 주장이 일화로도 보여질 수 있다는 것을 알고 있다. 그래서 더 넓은 지역사회의 의견이 이로운 것이다. 어쨌든 이 제안을 지지하는 쪽으로 상황이 전개되고 있는 것 같다. 만약 내 평가가 틀리고 새로운 비트가 이익만 가져다준다면, 훨씬 더 좋을 것이다. 만약 새로운 비트가 문제가 될 것이라는 나의 (그리고 다른 반대편 편집자들의) 평가가 옳다면, 그 비트는 상당히 쉽게 철회될 수 있을 것이다. 건배,———————Igels Hérissonovich ïzhakoff-Amursky) • (yo?); 2013년 9월 17일; 17:59(UTC)

    나의 반대 투표에 대한 좋은 의견과 사려 깊은 의견들에 감사한다. 그 제안이 통과될 것임이 분명하므로, 그것을 지지하는 사람들이 그 주제에 대해 그렇게 깊이 생각해왔다는 것을 아는 것은 좋은 일이다. 프로젝트의 어떤 측면에서도 잘 해낸 기여자들을 더 많이 참여시키기 위해 관리직을 개방하는 것이 WP가 정력을 유지하기 위해 해야 할 가장 중요한 변화 중 하나라고 생각하기 때문에 나는 여기서 반대 입장을 견지할 것이다. 그래서 만약 그것이 일어나지 않는다면, 나는 이 제안을 지지하지만, 나는 우리가 더 많은 노력을 기울일 수 있기를 바란다. 관리자 수에 추가. 이 제안은 아마 그 과정을 더욱 어렵게 만들 것이다. -- 마이클 스콧 커트버트 (대화) 21:41, 2013년 9월 18일 (UTC)[]

15. 반대 - 등록한 사용자들은 거의 모든 것에 대한 기본 편집 환경이 되어야 하며, 안타깝게도 이것은 신뢰받을 필요가 있는 순위나 파일 개인들(예: 수년 동안 위키피디아를 편집하고 참여해온 나 같은 많은 사람들)의 일부 엘리트주의를 보여주고 선의의 결여를 가정한 또 다른 움직임이다. 만약 그렇다면, 정말 보호되어야 할 필요가 있는 템플릿에 대한 평가가 있어야 하고, 그 이유는... "앞 페이지"에 포함시키는 것. "신뢰할 수 있는 등록 사용자"에 대한 기준을 바꾸고 싶다면, 그것은 확실히 정당한 논쟁이다. 그러나 이러한 맥락에서 나는 단지 템플릿을 반보호하는 것이 수백, 수천 명의 "신뢰할 수 있는 사용자"에게 이 "권리"를 부여하는 것보다 더 나쁘다는 것을 보지 못한다. 나는 또한 이것이 현재 완벽하게 보호될 수 있는 것으로 간주되지도 않는 많은 종류의 템플릿들이 그 보호 상태를 추가하게 되는 상황이라고 본다.... 또는 이러한 템플릿을 여전히 "관리자 편집 전용"으로 만드는 추가적인 "보호"가 필요할 수 있다. 이것은 정말 최악인 기능이다. --Robert Horning (토크) 19:21, 2013년 9월 17일 (UTC)[]
16. 나는 내가 이 RfC를 두 번 언급하고 다시 방문할 것이라고 생각하지 않았지만, 나는 반대하는 것이 나의 의무라고 믿는다. 로버트 호닝이 위에서 말하거나 암시하듯이, 기본 위치는 정기적인 등록된 사용자들이 거의 모든 것을 편집할 수 있는 것이어야 한다; 만약 그것이 너무 연약하거나 중요해서 허락되지 않는다면, 우리는 그들이 지역사회의 신뢰를 가지고 있다는 것을 그들에게 보여줄 수 있는 과정이 있다 - 그것은 RfA라고 불리며, 근접한 원인이었다.이 토론의 e는 통과되었고, 커뮤니티의 충분한 구성원들이 그가 말한 것을 할 누군가를 믿을 준비가 되어 있다는 것을 보여준다. 나는 또한, 다른 사용자 두 명이 언급했듯이, 이것은 규칙 위반의 가능한 예라고 생각한다; 또는 현관문이 닫혔기 때문에 옆문 옆에 뭔가를 (번들거리지 않고) 넣을 수도 있다고 생각한다. 그 이전 문장은 파일러나 지지자의 입장에서 서투른 믿음을 암시하는 것으로 읽힐지도 모른다; 나는 그러한 추론을 허용할 의도가 없었고, 서투른 표현에 대해 사과할 생각이 없었다. 건배, 린제이^Hello 17:27, 2013년 9월 18일 (UTC) 18:18, 2013년 9월 18일 (UTC)[]의 의도를 명확히 하기 위해 편집.
17. 나는 이것이 건국 원칙에 정면으로 위배된다고 생각한다. 사용자 읽기:Jimbo_Wales/Statement_of_원칙. 지니가 이미 병 밖으로 나왔으니, 이것을 미끄러운 비탈이라고 부르는 것은 그저 죽은 말을 때리는 것일 뿐이다. 혼합된 은유로는 어때? 2003년 이후 우리와 함께 해 온 계층의 정도를 포함해 거의 모든 계층의 수준은 프로젝트에 좋지 않다. 여러 개의 템플릿을 만들고 편집한 사람으로 말하자면, 나는 양쪽의 주장을 이해하지만, 나는 누가 신뢰할 수 있고 누가 신뢰할 수 없는지를 결정하기 위해 커뮤니티에 있는 폐쇄적인 시스템에 대해 즉각적으로 수백 페이지(따라서, 빠르게 주목되고 고정되는) 편집의 개방성을 선호한다. 기사 작성자가 아니라 기사에 집중하라.임조겔모 (대화) 03:10, 2013년 9월 19일 (UTC)[]
18. 관리자들이 정말로 이것이 그들에게 문제라고 생각한다면, 해결책은 "보호된 템플릿의 수를 줄인다"거나 "관리자 수를 늘린다"(관리자의 요구 사항을 줄일 수도 있다)는 것이어야 한다고 생각한다. 우리는 또 다른 권리 층을 필요로 하지 않는다. McKay (talk) 20:20, 2013년 9월 19일 (UTC)[]
19. 여기에 분명히 문제가 있다고 생각하지만, 이 제안이 그것을 해결하는 최선의 방법은 아니라고 생각한다. 나는 임조겔모의 논평이 상당히 설득력이 있다고 생각한다; 우리는 여기에 관료주의의 추가적인 층을 필요로 하지 않는다. 그러나 그것보다 나는 해결해야 할 두 가지 문제가 있다고 본다.
    (1) 미발송 문서와 플래그 지정된 개정 문서의 일부 하이브리드를 사용하여 템플릿을 더 쉽게 편집할 수 있는 방법에 초점을 맞추어야 한다.
    (2) 페이지 보호를 훨씬 더 유연하게 하는 데 초점을 맞춰야 한다(현재 모든 종류의 못에 대해 두 개의 망치를 가지고 있으며 이것은 전혀 도움이 되지 않는다).
    추가적인 보호 수준을 만드는 것은 우리를 다소 두 번째 목표에 가까워지게 하지만 많은 추가 수하물이 없이는 그렇지 않다. 어떤 페이지에 대해서도 "X보다 더 많은 편집이 필요하다"거나 "Y보다 더 오랫동안 등록된 사용자였을 필요가 있다"고 쉽게 지정할 수 있어야 한다. 이렇게 하면 반보호가 적절하지 않을 때 그렇게 많은 페이지를 완전히 보호하는 것을 멈출 수 있을 것이다. --MZMcBride (대화) 22:12, 2013년 9월 19일 (UTC)[]

    그것들은 언젠가는 현실이 될지도 모르는 고상한 목표들이다. 앞에서 말했듯이, 어떤 사람들은 더 이상적이라고 부를 수 있는 해결책들이 있지만, 현재 상황에서는 그것들을 요구하고 다른 것을 막는 것이 이치에 맞지 않는 반면, 여러분의 관점에 따르면, 여전히 상황을 개선할 수 있는 덜 완벽한 해결책이 테이블에 있다. 이 제안은 즉시 실행될 수 있는 반면, 가까운 미래에 당신의 제안이 일어날 가능성은 거의 없다. 당신의 제안과 함께 제공되는 그 이상의 "추가 수하물"은 여기 없다. 사실 나는 이 제안이 초안, 플래그 수정사항 및 소프트웨어와 절차상의 중대한 변경이 필요한 방대한 페이지 보호 옵션을 결합하는 것보다 훨씬 더 적은 "가방"을 수반한다고 생각한다. 이것은 사용자 권한으로, 새로운 소프트웨어 코딩 없이 구현되며, 중요한 프로세스 없이 할당 및 해지된다. Equazcion 22:39, 2013년 9월 19일(UTC)

    물론, 우리는 완벽한 적을 만들지 말아야 한다. 그것은 항상 균형잡힌 행동이다: 당신은 일시적인 해결책을 받아들일 수 있고 그것이 영구적이지 않기를 바라거나 적절한 해결책을 기다릴 수 있다. 일시적 해결을 받아들이면 더욱 고통스러운 결과 중 하나는 적절한 해결책의 개발을 저해한다는 것이다. 이것은 내가 개인적으로 해킹(읽기: 빠른 해결)이 득보다 실이 많다고 생각하는 상황 중 하나이다. 소프트웨어가 더 좋아져야 한다. 여기 있는 백 명이 넘는 편집자들이 소프트웨어를 더 똑똑하게 만드는 데 도움이 된다면 좋겠다. 내 코멘트에서 제기된 두 가지 사항 외에 세 번째 사항은 현재 사용자 인터페이스를 통해 임의 사용자 그룹을 만들 수 없다는 것이다. stewards가 임의 사용자 권한을 가진 글로벌 그룹을 만들 수 있듯이 관료들은 임의 사용자 권한을 가진 로컬 사용자 그룹을 만들 수 있어야 한다. 여기에는 여러 가지 잠재적 해결책이 있지만, 보호 수준을 추가하면 사용자 그룹이 내가 가고 싶은 방향으로 우리를 전진시키는 것 같지는 않다. --MZMcBride (대화) 03:50, 2013년 9월 20일 (UTC)[]

20. 나는 방금 이 모든 것을 다 읽었고 그것을 모두 소화시킬 시간이 필요하다. 그러나 반대하는 것은 나의 첫 번째 직감이다. 나는 아칼라마리의 의견에 전적으로 동의한다. 5. 나는 도구 분리를 전반적으로 강력히 지지하며, 따라서 비관리자가 일부 페이지보다 완전히 보호된 페이지를 편집할 수 있는 사용자 권한을 구현하는 것을 선호한다. 편집자가 수천 개의 훌륭하고 도움이 되는 개선사항을 수행했을 때, 관리직은 주어진 것이 되어야 한다. 그러나 이 시점에서 내가 보기에 또 다른 보호수준의 창조는 느슨한 반창고일 뿐이다. 그런데도 왜 좋은 템플릿 코디네이터들을 신뢰하지 않는 현재의, 그렇게 완고한 시스템으로 낙담시킬까? 그것은 정말로 열린 벌레 통조림이다. 그리고 나는 더 큰 통조림을 찾는 더 좋은 방법들이 있다고 느낀다. – Paine Elsworth^CLIMAX! 17:26, 2013년 9월 20일(UTC)[]
21. 템플릿이 손상에 너무 민감하여 템플릿의 기본 상태가 완전히 보호되어야 하는 경우, 변경 내용이 편집 보호되어 여러 개의 눈 아래를 통해 실행되는 것은 아마도 유용한 지연일 것이다. 크리스토퍼 파럼 (대화) 22:55, 2013년 9월 26일 (UTC)[]

중립

1. 나는 이것을 정말 지지하고 싶지만, 나는 인정에 대한 지침이 확대될 필요가 있다고 생각해. 내 생각에, 이 사용자 권리는 잠재적으로 사이트에 광범위한 손상을 입힐 수 있다는 관점에서 편집 필터로 순위를 매긴다. 비관리자가 편집필터 관리자가 되려면 먼저 토론이 있어야 한다. 나는 이 사용자 권한이 편집 필터 매니저가 부여되는 방식과 유사한 프로세스를 가져야 한다고 생각한다. Elockid^(Talk) 21:12, 2013년 9월 27일 (UTC)[]

   괜찮은 지적인 것 같은데, 필터 매니저가 부여되는 방법에 대해 설명해 주시겠습니까? 나는 그들의 과정 요약을 찾느라 20분을 허비했다. 내가 엉뚱한 곳을 찾고 있는 게 틀림없어. 고마워 - 포인틸리스트 (대화) 22:11, 2013년 9월 27일 (UTC)[]

   WP:Edit filter에서 리드의 끝 부분에 대한 간략한 설명이 있다. Elockid^(Talk) 23:04, 2013년 9월 27일 (UTC)[]

   누군가가 이 사용자 권리로 한번에 많은 페이지를 파괴할 수 있지만, 그로 인한 손상은 매우 빨리 해결될 수 있다. 편집 필터는 훨씬 더 광범위한 문제를 일으킬 수 있고, 복구하기 훨씬 더 어려울 수 있고, 어떤 면에서는 되돌릴 수 없는 손상이 있을 수 있다. 몬티₈₄₅ 02:13, 2013년 9월 28일 (UTC)[]

   파손된 템플릿을 되돌리는 것은 쉽다, 그렇다. 문제의 원인을 찾는 것, 아니. 템플릿 파괴 시 사용자:지구 폭발 생생한 파괴된 템플릿(그것들은 보호되지 않았지만 나는 단지 예를 들어줄 뿐), 가장 숙련된 파괴된 전투원들조차 문제의 근원을 찾기란 매우 어려웠다. 편집 필터로 우리는 문제를 꽤 빨리 찾을 수 있다. 필터 편집 문제를 해결하는 것이 훨씬 쉬워, 나는 개인적으로 두 가지 문제를 모두 처리했다. 엘로키드^(Talk) 02:20, 2013년 9월 28일 (UTC)[]

   편집 필터가 위키백과의 모든 사람이 편집하는 것을 차단하고, 편집하려고 했던 편집을 취소하고, 그들의 위법행위에 대한 경고를 그들에게 줄 때, 당신은 어떻게 행해진 피해를 되돌릴 수 있는가? 물론, 편집 필터가 몇 분 안에 고정되었지만, 그렇다고 해서 활성 상태에서의 손상이 복구되지는 않는다. 그리고 그것은 내가 알고 있는 선의의 편집(두 번 해프닝)에서의 실수에서 나온 것일 뿐, 고의로 남용한 사람도 아니었다. 몬티₈₄₅ 02:31, 2013년 9월 28일 (UTC)[]

   나도 비슷한 주장을 제기할 수 있다. 템플릿이 변환된 페이지의 아무 곳이나 클릭하면 충격 현장으로 이동하는 템플릿의 손상을 어떻게 복구하시겠습니까? 문제를 찾는 데 시간이 더 걸린다는 점을 고려하면 IMO는 결과적으로 선의의 편집을 막을 가능성이 훨씬 더 크다. 사람들이 페이지를 편집할 수 없을 뿐만 아니라 템플리트를 만들어 읽을 수 없게 할 수도 있다. 메인 페이지의 템플릿이 파손되면 어떻게 하시겠습니까? 내가 여기서 말하는 것은 템플릿 파괴 행위가 편집 필터만큼 위험하거나 심지어 더 위험할 수 있다는 것이다. 이 두 사건에서 비롯된 결과를 되돌릴 수는 없다. 우리의 최선의 선택은 문제를 해결하고 예방하는 것이다. Elockid^(Talk) 04:21, 2013년 9월 28일 (UTC)[]

   여기에 열거된 기준(물론 나중에 수정될 수 있는 btw)을 가진 공공 기물 파손에 대해서는 그다지 염려하지 않는다. 신청자는 지난 6개월 동안 차단할 가치가 있는 행동이나 3RR 위반(반달에게 좋은 행동의 높은 명령처럼 보이는)이 없었으며, 그러한 기준을 조사하는 동안 나타날 의심스러운 행동(이 기준들은 조용함을 필요로 할 것이다) 없이 그들을 만나기 위해 상당히 많은 시간과 노력을 기울여야 할 것이다.대부분의 관리자 권한에 관한 조사보다 좀 더 적극적인 조사를 한다. 누군가 겉치레에 그렇게 많은 시간과 노력을 쏟았다면, 토론 요건이 추가될 가능성도 그들을 붙잡지 못할 것이다. 게다가, 그것은 고의적으로 뭔가를 해칠 누군가를 위한 비현실적으로 중요한 약속처럼 보인다. 그리고 나는 그것이 현실적으로 일어나는 것을 볼 수 없다. 반달들은 일반적으로 차를 타고 다닌다. 마지막으로, 이 권리를 가진 사람들은 그리 많지 않을 것이고, 그들의 기여는 만약 무엇인가 깨지기 시작한다면, 가장 먼저 살펴보는 것이 될 것이다. 그래서 만약 문제가 템플릿 편집자에 의해 야기된다면, 범인은 꽤 빨리 발견되고 다시 굴러갈 것이고, 찾기 위해 많은 것을 파헤칠 필요가 없을 것이다.

   이 모든 것은 WP에서 논의되는 것을 배제하는 것은 없다.PUMER, 비록 그것이 일반적으로 현재 존재하는 권리에 대한 것은 아니지만. 관련자라면 누구나 신청서를 보고 의견을 말할 수 있다. "RfA 라이트"로 치부되지 않도록 상당히 짧아야 하지만, 어쨌든 권리가 쉽게 취소되기 때문에 우리는 코멘트를 기다리는 대기 기간도 가질 수 있다. 나는 나중에 처리될 수 있는 물류와 같은 것들을 보고, 지금 당장 성문화할 필요는 없다. 2013년 9월 28일 06:02, (UTC)

   필자의 요점은 필터 파괴와 템플릿 파괴는 서로 똑같이 파괴적이거나 위험할 수 있다는 것이었습니다. 이것이 내가 먼저 토론을 주장하는 이유다. 롤백기나 검토자와 같은 권한을 신청할 때 쉽게 실행될 수 있는 프로세스와 유사한 것은 없다. 심지어 가이드라인을 따르지 않을 정도로 지나치게 자유롭게 사용자 권리를 부여한 사례도 많다. WP에 있는 것만 말하는 게 아니다.PERM. 검토자 권리는 거의 모든 경우에 어떠한 형태의 논의도 없이 너무 자유롭게 주어졌다. 게다가, 내가 정확히 기억한다면, 관리자들이 Autoreviewer에게 너무 자유롭게 권리를 주는 지점이 있었다. IP블록 면제가 있더라도 관리자는 권리 부여 시 가이드라인이나 프로토콜에 따르지 않는 것이 일상적이며, 이는 관리자의 신뢰수준과 유사할 필요가 있는 권리다. 검토자에게 일어난 일과 마찬가지로, IP 블록 면제 플래그가 너무 자유롭게 주어졌다. 나는 이 문제가 토론이 부족한 데서 비롯되었다고 생각한다. 짧은 토론(아마도 3일)이라도 한다면 한 사람으로부터만 평가를 받을 수 있는데, 많은 경우 그렇다. Elockid 14:17, 2013년 9월 28일 (UTC)[]

   @Elockid: 사실, 대부분의 경우, 만약 당신이 방법을 안다면, 템플릿 파괴의 근원을 찾기가 쉽다. 일반적인 방법은 Special을 사용하는 것이다.Template 네임스페이스의 링크된 페이지에 대한 최근 변경 목록을 가져오는 LatestChangesLinked. 아니면, 만약 당신이 약간의 fancier를 얻고 싶다면, 당신은 이 userscript를 사용할 수 있다. 그것이 항상 도움이 되는 것은 아니다(예: Talk:인간/아카이브 33#인포박스 코드 깨짐으로 누군가 자동택시박스 템플릿 중 하나를 공공 기물 파손이 아닌 다른 비트의 택시가 템플릿 제한을 초과하도록 변경한 경우) 그러나 그러한 상황은 드물다. Anomie⚔ 13:20, 2013년 9월 28일 (UTC)[]

   하지만 문제가 있다. 대부분의 사람들은 지난 번 공공 기물 파괴 재난에서 드러난 대로 그 문제를 어떻게 해결해야 할지 모른다. 지난 번에는 지역사회가 준비되지 않았고, 이것은 공공연한 공공 기물 파손의 형태가 아니기 때문에, 나는 지역사회가 이번에는 전체라고 믿지 않는다. Elockid^(Talk) 14:01, 2013년 9월 28일 (UTC)[]

   IMO, 그것을 고치는 방법은 사람들이 그것을 하는 방법에 대한 지시를 쉽게 찾을 수 있도록 하는 것이다. 네가 말하는 이 "마지막 템플릿 파괴 재해"는 잘 모르겠지만, 아마도 그것을 찾지 못한 사람들이 도움을 구해서 그 곳에 지시를 내리는지(또는 지시로 연결되는 링크)
   또한 BTW, 위 어딘가에서 누군가가 메인 페이지에 있는 템플릿을 파괴하는 것을 우려했지만, 메인 페이지는 계단식으로 보호되어 있어서 비관리자가 템플릿을 편집하지 못하게 한다는 점에 유의하십시오. Anomie⚔ 15:09, 2013년 9월 28일 (UTC)[]

   여기 ANI와 내 토크 페이지에 있는 예시 스레드가 있다. 사용자들이 WP별로 이메일을 보내주기도 했다.콩이요. 이거 몇 달이나 걸렸어. 메인 페이지와 관련하여, 내가 그것을 꺼내는 주된 이유는 편집 필터처럼 선한 믿음의 편집을 허용하지 않는 템플릿 파괴 행위도 또한 선한 믿음의 편집을 허용하지 않기 때문이다. Elockid 19:29, 2013년 9월 28일 (UTC)[]

2. 엘로키드에 따라서. 이미 무거운 관리자 작업량을 제거하기 위한 훌륭한 단계지만 잘못된 손에 잠재적으로 위험한 도구. - Jayadevp 13 15:32, 2013년 10월 9일(UTC)[]
3. 중립. 약 반년 전, 나는 이 토론에서 비슷한 권리가 존재한다고 제안했었다. 그러나, 위키백과의 대화를 위해 "마감 시간"에 제안되었기 때문에, 내가 제안한 토론은 아무 진전이 없는 것 같았다.제안서를 게시한 보호 페이지 편집자 토론. 이 제안이 내가 시작하려고 했던 제안보다 훨씬 더 많은 관심을 받고 있는 것을 보니 기쁘다. 그러나, (제안서를 전체적으로 읽은 후) 나는 템플릿 편집 권한을 제공하는 것에 동의하지 않는다.이 권한의 일부로 네임스페이스에 있는 공지사항/페이지 페이지 또는 하위 페이지를 편집하십시오. 나는 편집 고지가 이 권리를 가지는 것의 일부로 고의적이거나 우발적으로 파손되는 것을 볼 수 있다. 독자들이 볼 수 있도록 기사나 다른 페이지에 경고를 게시하는 것은 "템플릿 코더"가 되는 것과 모든 사람이 중요한 경고 메시지를 보게 하는 것과 전혀 상관이 없다. (하지만, 이 제안의 한 가지 결함은 내가 "반대"하기에 충분하지 않지만, "지지"를 투표하지 않는 것으로 충분하다.) 스틸1943 (토크) 01:32, 2013년 10월 13일 (UTC)[]

토론

임의 브레이크

• 마지막 세 가지 허용 기준은 너무 구체적이어서, 나는 그것보다 조금 느슨하게 할 수 있지만, 우리는 그것을 해결할 수 있다. 루아도 여기에 모듈 공간을 포함시켜야 할 것 같아 —DJ (대화 • 기여) 10:58, 2013년 9월 11일 (UTC)[]

제목이 "기준"이 아니라 "지침"이 되어야 할까? - 점묘사 (토크) 11:02, 2013년 9월 11일 (UTC)[]

나는 모듈들이 포함되어야 한다고 생각한다 - 문구는 어디에도 불명확한가? — Stradivarius씨^{♪ talk ♪} 11:08, 2013년 9월 11일 (UTC)[]

TheDJ, 포인트리스트: 모듈 공간은 이미 여기에 포함되어 있다. 그 기준에 관해서는, 이 특권이 자격 없는 손에 넘어갈 가능성에 대한 우려를 완화시키는 것이 구체적이다. 구체적인 방안이 마련된다면 지역사회를 가로질러 더 나은 수용 기회가 있을 것이라고 느꼈다. 그렇기는 하지만, 이 섹션의 내용은 이미 "지침"을 굵은 글씨로 가지고 있고, 실제로 관리자의 재량에 달렸다고 언급하고 있다. 하지만 어쩌면 머리말도 바꿀지도 모른다. Equazcion 11:15, 2013년 9월 11일 (UTC)

잘 하고 있어. 다만 "허여지침"과 "허여지침"을 "취소기준"과 대조하는 것이 수용에 도움이 될 수 있다고 생각했다. - 점술가(토크) 11:29, 2013년 9월 11일 (UTC)[]

고마워 :) 내가 헤더를 바꿨어, FYI. equazcion 11:38, 2013년 9월 11일 (UTC)

• 마지막 두 가지 기준인 IMO는 편집자가 템플릿 편집에서 실제로 학습되도록 하기 위한 것이다... 그러나, 템플릿 네트워크와 함께 일하는 많은 편집자들이, 편집자가 IRC, 이메일 또는 사용자 대화 페이지에서 코딩 변경을 요청할 수 있다. 이 두 사람은 신중해야 한다. 아마도 첫 번째 네 가지 기준은 요건에 더 가까워야 하는 반면 마지막 두 가지 기준은 편집자의 전문성을 결정하기 위한 더 큰 기술 목록의 일부로 사용될 수 있을 것이다. Lua에서의 코딩은 편집 보호 템플릿의 사용보다 더 큰 지표다. - Floydian^τ_¢ 11:53, 2013년 9월 11일 (UTC)[]
  • 나는 이것을 받아들일 용의가 있고 지금까지 사람들은 그 기준이 느슨해져야 한다는 느낌을 표현해 온 것 같다. 최종 두 가지 기준이 좀 더 신중하다고 규정하는 것은, 여러분이 제시한 이유로 볼 때, 좋은 생각인 것 같다. 나는 아직 정확한 텍스트 변화가 무엇인지 잘 모르겠다. 이것은 메타 이슈이기 때문에 우리는 토크 페이지에서 채용하기 위한 정확한 변화에 대해 논의할 수 있다. Equazcion 12:03, 2013년 9월 11일 (UTC)
  • 나는 여전히 마지막 두 가지 지침이 약하다고 생각하지만, 나는 타협했다. 나는 11.6년을 보냈고 수백 개의 템플릿 편집(대부분 내가 위키백과에서 재생한 MMO를 위한 전문 위키에서)을 했는데 아직도 템플릿에 대해 알아야 할 모든 것을 알지 못한다. 이 모든 경험을 통해 미디어위키위키에 대한 적절한 매뉴얼을 빨리 찾아볼 수 있다. 현재 가이드라인의 문구는 템플릿 토크 페이지, IRC, 이메일, 사용자 토크 페이지를 포함하되 이에 국한되지 않는 모든 곳에서 편집 요청을 고려할 수 있다고 생각한다. 기술 13 (대화) 13:03, 2013년 9월 11일 (UTC)[]
• 질문: 이것이 기술적인 추정이지만, 개발자들이 사용자 권리를 창출하기 위해 필요한 비트를 실제로 수정할 시간과 경향이 있다는 것을 우리는 알고 있는가? 페드로 : Chat 11:56, 2013년 9월 11일 (UTC)[]
  • 기술적 영향은 초안 토크 페이지에서 철저히 탐구되었으며, 현재는 보관되어 있지만 이 토크 페이지에 링크되어 있다. 개발자 측에서, 이러한 변경은 새로운 코딩(새로운 사용자 권리 + 새로운 보호 수준)이 아닌 구성 변경만을 필요로 할 것이다. 그 일부를 보려면 여기를 참조하십시오. 사용자:Anomie가 들렀고 커뮤니티가 그것을 위한 것이라면 새로운 보호수준이 가능하다고 말했다. Equazcion 12:00, 2013년 9월 11일 (UTC)
    • 고마워 에카지온, 난 그 링크를 못 봤어, 고마워. 페드로 : 채트 12:17, 2013년 9월 11일 (UTC)[]
• (여러 EC) 일반적으로 나는 번들링 해제에 찬성하지는 않지만, 현재 반대하지는 않을 것이다. 그러나, 나는 RfC가 시작되었을 때 실행되는 RfA에 비추어 볼 때, 이 RfC의 타이밍이 약간 유감스럽다고 생각한다(그렇다, 나는 이 특정 RfA가 RfC의 동기의 일부라는 것을 알고 있다). 내가 보기에 이 요청서가 성공적이면, 내가 이것을 쓸 때 가능성이 없어 보이지 않는 것처럼 보인다면, 그것은 커뮤니티가 더 그럴 준비가 되어 있다는 신호인 것 같다.이전보다 일회용 개미 관리 그렇다면, 나는 여기서 제공되는 새로운 사용자 그룹에 찬성하지 않을 것이다. 더 일반적으로, 나는 우리가 왜 또는 어디에 신뢰의 선을 그어야 하는지 잘 모르겠다. 만약 우리가 누군가 보호를 통해 템플릿을 편집할 수 있다고 믿는다면, 우리는 왜 그를 다른 분야에서 신뢰하지 않을까? 건배, 린제이^Hello 12:03, 2013년 9월 11일 (UTC)[]

이 제안은 템플릿 편집자 후보가 RfA에 있는 후보보다 훨씬 좁고 어느 정도 더 객관적인 기준을 사용하여 평가될 수 있음을 의미한다. 또한 훨씬 더 신뢰할 수 있는 해지 메커니즘이 있다. - 포인트리스트 (토크) 13:04, 2013년 9월 11일 (UTC)[]

고마워, 포인트리스트 너의 마지막 요점은 아마도 내가 그 제안을 지지하는 가장 강력한 이유일 거야; 정확히 말하면, 나는 그것을 놓치지 않았지만, 내 마음은 그것을 약간 얼버무렸다. 건배, 린제이^Hello 15:22, 2013년 9월 11일 (UTC)[]

덧붙여 RfA의 서포터들조차도 여기에 기술된 것과 같은 옵션이 없기 때문에 지지하고 있을 뿐이라는 일반적인 느낌을 표현했다. Equazcion 13:11, 2013년 9월 11일(UTC)

• • 안녕 린제이! 나는 너의 걱정과 질문에 감사한다. 내가 대답할 수 있는지, 다른 사람들이 나를 지지하거나 더 많은 통찰력을 제공할 수 있는지 알아보자. 현재의 RfA 과정은 기술 능력과 신뢰에 관한 것이 아니다. 여러 개의 새로운 기사를 만들어 내고 많은 관리자 분야 토론(AfD, RPP, AIV 등 몇 가지를 언급하는 것)에 기여하여 극단적인 상황(PA 또는 TROLing f의 주체가 되는 것)에서 다른 편집자와 대화하고 토론할 수 있는 좋은 능력을 갖추는 것(AfD, RPP, AIV)에 이르기까지 광범위한 능력과 약속이 요구되는 관료적 과정이다.또는 예) 그냥 물러날 수 있는 것이 아니라. 더구나 내가 기여한 RfAs에 대한 나의 관찰은 그것이 기술력과 신뢰도에 관한 것보다 인기 경연에 관한 것이 훨씬 더 많다는 것이었다. 이 새로운 제안된 권리는 기술적으로 기울어진 편집자들이 그들의 기술 집합에 기초하여 관심 있는 특정 영역에서 더 생산적일 수 있도록 해주는 사용자 그룹을 만드는 것에 더 가깝다. 기술 13 (대화) 13:43, 2013년 9월 11일 (UTC)[]

안녕, 13번 기술자. 나는 너의 요점 중 하나에 완전히 동의하지 않는다고 말해야겠다(미안해!) / RfA는 신뢰에 관한 것이 매우 크다고 생각하는데, 그래서 내가 앞서 언급했던 것이다. 우리는 한 후보자에게 공동체로서 그가 망치지 않는다고 믿거나 미치지 않는다고 믿는지 여부에 따라 일련의 도구를 주고 있다. 그들의 다양한 능력/경험을 보는 것은 그들의 신뢰도를 평가하는 수단일 뿐이다. 그래서 내가 보기에 트라피스트 스님과 다른 사람들이 그들의 기술을 바탕으로 관심 있는 특정 분야에서 더 생산적이 되기 위해 최고의 길을 택한 것 같다. 그러므로, 나의 관점에서는, 이 새로운 사용자 권리는 필요하지 않다. 하지만, 우리는 다른 것에 동의할 수 있다. 건배, 린제이^Hello 15:22, 2013년 9월 11일 (UTC)[]

• 대체 구현은 코드에 메커니즘을 만들어 개인이 특정 페이지 또는 페이지 그룹에 대한 편집 보호를 우회할 수 있도록 하는 것을 권장한 다음, 영어 위키피디아는 위에서 제안된 것을 하기 위해 이 새로운 메커니즘을 사용할 것을 권장한다. 이 구현은 소프트웨어를 사용하는 비창업 프로젝트를 포함하여 다른 위키피디아에게 임의의 기사나 기사 그룹 및 관련 페이지의 큐레이터에게 "보호된 페이지 편집" 권한을 부여하거나 유사한 기능을 제공하는 등의 작업을 유연하게 수행할 수 있다. 영어 위키백과는 특별히 "소유"를 허용하지 않기 때문에, 이것은 영어 위키백과의 기사-공간에서 내용을 큐레이션하거나 다른 목적으로 사용되지 않을 것이다. 데이비드wr/(토크)/(기고) 17:03, 2013년 9월 11일(UTC)[]
  • 이것은 이 제안의 입안 단계에서 논의되었지만, 개발자들은 기술적으로 실현 가능하지 않다고 지적했다. 나는 (소프트웨어 개발 관점에서 그렇게 터무니없어 보이지는 않지만) 할 수 있다고 가정하고 있지만, 소프트웨어의 실질적인 개발과 재작업이 필요하기 때문에, 재단에 대한 제안이 통과된다면 재단에 의해 실제로 구현될 가능성은 훨씬 낮을 것이다. Equazcion 17:17, 2013년 9월 11일 (UTC)
• 질문: 편집 통지가 여기에 포함되는 이유 전혀 다른 범위와 기술 세트지요? --Stfg (대화) 19:14, 2013년 9월 11일 (UTC)[]

응답: 위키백과:EDITNOTICE, 그것들은 매우 단순한 템플릿이다. 호서 (토크) 2013년 9월 11일 19:21 (UTC)[]

그렇긴 하지만, 이 제안에 대한 어떤 합리성도 편집기사에 적용되지 않는다. 템플릿 네임스페이스에 있다고 해서 다른 템플릿과 함께 묶어야 하는 것은 아니다. - Ypnni (talk) 19:25, 2013년 9월 11일 (UTC)[]

(갈등 편집) 범위는 논쟁의 여지가 있지만, 다른 기술 세트는 아니다. 편집 통지는 Wikicode로 만들어진 배너일 뿐이기 때문에 동일한 종류의 코딩을 수반한다. 편집자 자신의 토크 페이지 편집 통지와는 별도로, 대부분의 사용자로부터 편집 통지에 대한 접근은 논쟁의 이유 등이 아닌 유사한 예방 원칙에 따라 잠겨 있다. 그들은 우리의 열성적인 많은 코드 작성자들이 실질적으로 기여할 수 있는 것들의 범주에 속하지만, 현재 불필요하게 금지되어 있다. 또한 편집에 대한 접근 권한은 이미 다른 비관리 권한 그룹인 계정 작성자를 통해 부여되었다. 여기에 포함시키는 것이 적절해 보였다. Equazcion 19:28, 2013년 9월 11일 (UTC)

• 질문 - 최근 논의되고 있는 또 다른 제안된 권리 변경과 달리, Afc에서 기사를 검토하기 전에 편집자들이 어느 정도 경험을 쌓아야 하는 것과 달리, 이 제안은 일부 개인에게 더 많은 권리를 준다. 만약 100명의 비관리자들이 모두 이 제안에 찬성하고 아무도 반대하지 않는다면, 그들은 이것을 실행할 능력이 있을까? 새로운 사용자 권한을 생성하기 위해 누구의 지원이 필요한지, 그리고 누가 그것을 얻는지 결정할 것인가? —안네 들롱 (대화) 23:06, 2013년 9월 11일 (UTC)[]
  • 행정관은 일반적으로 제안서를 닫는 사람으로 제안서 통과 여부에 대한 최종 평가를 한다. 관리자들은 그럴 때 그들의 개인적인 감정을 무시해야 할 책임이 있고, 그렇게 할 수 있는 그들의 인식된 능력에 의해 선출되기 때문에, 제안을 지지하는 모든 사람이 비관리자라면 그것은 중요하지 않을 것이고 일반적으로 중요하지 않다. 새로운 권리와 보호 수준은 위키미디어 재단의 개발자들에 의해 제정된다. 그들의 행동을 요구하는 지역사회의 제안이 성공적 으로 종결되면, 그들에게 요청이 들어온다. 재단이 지역사회를 무시하기로 선택하고 지역사회가 지원하는 제안의 제정을 거부한 사례도 있었지만, 드물게, 초안 작성 과정에서 적어도 두 명의 개발자가 이 제안에 대해 의견을 개진했고 지역사회가 그러한지 여부에 대해 개방적인 것처럼 보였다. Equazcion 23:14, 2013년 9월 11일 (UTC)
  • PS. 지금까지 이 페이지에 있는 몇몇 지지자들은 사실 관리자들이다. 만약 그것이 당신의 관심사와 관련이 있다면. Equazcion 23:17, 2013년 9월 11일 (UTC)

기술적으로 sysops, (서버를 운영하는 사람들)에 의해 구현될 수 있다고 생각하는데, 그것은 단지 구성 파일의 변경일 뿐이라고 생각한다. 정비사가 구현되면 RFC가 제공하는 가이드라인에 따라 지역 관리자에 의해 권리가 부여된다. 추정컨대, 보호 수준이 새로운 보호 수준으로 변경되는 것은 지역 관리자에 의해서도 수행될 것이다. 참고로 제안서에 대한 지원은 비관리자보다 더 높기 때문에 관리자가 협조하기를 거부하는 것은 문제가 되지 않을 것으로 보인다. 몬티₈₄₅ 23:26, 2013년 9월 11일 (UTC)[]

^그가 말한 것 :) Sysops와 개발자들은 아마도 각각 구성 액세스 권한을 가지고 있을 것이고, 나는 어떤 것이 실제로 초기 변화를 제정할 것인지 잘 모르겠다. 그건 사실 중요하지 않아. 어느 쪽이든 (당신의 질문에 간단히 대답하기 위해) 재단이 거부권을 행사하는 것을 금지한다면, 우리 관리들은 실제로 해야 할 대부분의 일을 하고 있을 것이다. 몬티가 말한 대로; 만약 이것이 통과된다면, 그들은 누가 투표했든 상관없이 할 것이다. Equazcion 23:39, 2013년 9월 11일 (UTC)

이것을 명확히 하는데 도움을 준 모든 사람들 덕분이다. 공동체 구성원들이 스스로에게 새로운 권리를 주자고 제안하는 것을 처음 보는 것인데, 그것이 무의미한 연습이 아니라는 것을 확실히 하고 싶었다. —안네 들롱 (대화) 00:01, 2013년 9월 12일 (UTC)[]

• 그것은 실제로 언급되지 않은 문제를 제기한다. 제안이 통과되면 완전히 보호된 모든 템플릿을 새 템플릿 보호로 변경해야 하며(7k+ 템플릿) 감소를 위한 안목으로 모든 완전 보호 템플릿을 검토해야 하는가(7k+ 템플릿) 아니면 요청된 대로 검토 및 축소해야 하는가? 몬티₈₄₅ 23:52, 2013년 9월 11일 (UTC)[]
  • 그 질문은 내 생각에 수레를 말 앞에 놓는 것 같기 때문에 후속 논의를 위해 남겨두는 것이 좋다. 기술 13 (토크) 00:49, 2013년 9월 12일 (UTC)[]
  • 나는 그 세 가지 옵션 중 하나 또는 그 조합 중 하나가 일어날 것이라고 상상한다. 비록 그것이 때가 되면 우리가 다룰 수 있는 로지스틱이긴 하지만 말이다. 그러나 새로운 보호 수준은 완전하게 보호되는 템플릿의 수를 "감소"하는 데만 적용되기 보다는 고위험 템플릿의 사전 예방 조치로서 완전한 보호를 대체하기 위한 것이다. 특별하고 일시적인 상황에 대해서는 완전한 보호가 엄격히 지켜질 것이다. Equazcion 03:13, 2013년 9월 12일(UTC)

• 몇몇 참가자들은 내가 지지에 투표했다는 것을 알아차렸을 것이다. 이것은 volte-face로 보일 수 있다; 그것은 아니고, 현재 RfAs에 대한 어떤 편견도 없다. RfC 제안은 매우 구체적이며, 나는 그것이 관리자 도구들의 일부분이라고 생각하지 않는다. 임계값 요구사항은 매우 정확하며, 나는 신규 및/또는 경험이 없는 사용자 또는 모자 수집가들에 의해 해당 임계값에 대한 애플리케이션이 남용될 것이라고 생각하지 않는다. 나는 그것을 예를 들어 파일 무버와 매우 비슷한 방식으로 본다. 이 새로운 '권리'가 기술적으로 어떻게 구현될 수 있는지/그것은 이 RfC의 범위를 벗어나는 것이다. - Kudpyung กผผึง ( ( ( ((토크) 03:35, 2013년 9월 12일 (UTC)[]

• 나는 이것이 많이 변하는지 잘 모르겠다. 만약 템플릿이 이미 너무 많은 페이지에서 사용되고 있다면, 나는 그것에 대해 고쳐져야 하는 약간의 오류가 있을 것 같지 않고, 지역사회가 집단적으로 결정한 어떤 것이라도 그것에 대해 변경되어야 한다고 생각한다. 고장나지 않았다면 고치지 마. LazyBastardGuy 04:15, 2013년 9월 15일 (UTC)[]

• 이 번들번들하지 않는 논의의 흥미로운 점은 최종 결과가 관리자들에게 무엇을 의미할 것인가이다. 확실히 우리의 롤백업자들은 이전에 독점했던 관리 영역으로부터 그러한 권리를 가짐으로써 공공 기물 파손에 대항할 수 있다. 다른 모든 권력이 결국 양도되면, 관리자들은 결국 이 금지 망치를 들고 있는 유일한 위키피디아 사람들이 될 것인가? 행정관들은 주로 전쟁 중인 편집자들 사이의 해결책을 협상하는 일을 담당할 것인가? 위키피디아가 우리 관리자들이 관리할 수 있는 크고 다양한 형태로 성장했기 때문에 이것은 올바른 방향으로 나아가는 한 단계라고 생각한다. 크리스 트라우트만 (토크) 2013년 9월 15일 18:36 (UTC)[]

후보의 콘텐츠 기여도, 경험, 행동, 정책에 대한 지식 등에 대한 RfA와 같은 정밀 조사 없이 번들거릴 수 있는 관리자 권한은 많지 않다. "위키피디아가 관리자가 관리할 수 있도록 크고 다양한 형태로 성장했다"고 한다면, 새로운 유형의 슈퍼 유저보다는 커뮤니티 기반의 솔루션이 더 나을 것이다. 만약 우리가 계속해서 경험 많은 편집자와 활동적인 행정가들의 숫자가 감소한다면, 몇몇 흥미로운 결정들이 있을 것이라는 것에 동의한다. 몇 년 동안 우리는 가끔 모호하거나 모순되는 선례를 해석할 수 있는 관리자가 무제한으로 있을 것이라고 생각해 왔다. 관리자 부족은 위키피디아의 작동 방식에 대한 재점검을 강요할 수 있다. 꼭 나쁜 것만은 아니다. - 포인트리스트 (대화) 22:21, 2013년 9월 15일 (UTC)[]

나는 "필수"해야 한다고 (즉, 재단이 그렇게 말하거나 이슈가 된다면 그렇게 말할 것이기 때문에) RfA와 같은 참조 국민투표를 거치는 주요 관리 권한은 삭제된 자료에 대한 접근권을 주는 권한, 사용자 권리에 영향을 주는 권한, 그리고 편집자가 페이지를 변경할 수 있는 권한에 영향을 주는 권한이다. 일부 관리자 권한은 이러한 권한과 협력하므로 특별한 경우를 제외하고는 페이지나 수정사항을 분리하는 것이 타당하지 않을 수 있다(예: 구독 전용 저널 기사에 대한 접근 권한을 가진 편집자에게만 부여할 수 있지만, 저작권상의 이유로, 그리고 어느 정도의 책임만 있는 경우에만 부여할 수 있다). 대부분의 다른 행정권리는, 이론적으로, 재단이 거부권을 행사하지 않는 한, 공동체의 합의에 의해 분리될 수 있다. 재단의 직원, 임원, 자원봉사자 등 개인들이 개인 편집자로서 의견을 제시할 수도 있지만, 보호 페이지 편집권을 분리하는 것에 대해서는 재단이 공식적인 언급을 하지 않을 것이라고 생각한다.davidwr/(대화)/(논문)/(논문) 23:37, 2013년 9월 15일(UTC)[]

• 누가 이 권리를 부여할 것인가? 어떤 관리자가 이 권한을 부여하기 보다는, 템플릿 편집 경험이 있는 관리자만이 권한을 부여할 것을 제안하고 싶다. 나의 특별한 요점은 템플릿 네임스페이스에 대한 150개의 편집 기준이다. 이것은 편집이 좋은지 나쁜지, 편집 횟수만 올리기 위한 사소한 편집이 많은지 또는 주요 편집은 말하지 않는다. 한 편집자는 10개의 사소한 편집을 할 수 있고 동시에 다른 편집자는 하나의 주요한 편집을 할 수 있다. 관리자는 신청자가 자신이 하고 있는 일을 이해하고 있는지 여부를 알 수 있어야 한다.마틴451 (대화) 2013년 9월 16일 18:05, (UTC)[]

• 필요성(요청 시 템플릿 편집, 내가 완전히 이해하지 못한 템플릿 편집)을 본 것처럼 여기서 투표하지는 않을 것이지만, 적절한 기준을 확신할 수는 없다. 수십만 개의 기사에서 발생하는 템플릿을 편집하는 것은 실제로 필요할지라도 쉽게 파괴될 수 있기 때문에 신뢰의 표시가 필요하다. 그것은 덜 혼란스러운 선택일 것이다. — Arthur Rubin (대화) 23:49, 2013년 9월 20일 (UTC)[]

기본 페이지 템플릿 편집

이것은 내가 제기하고 싶은 중요한 질문이다(그리고 여기서 섹션 브레이크를 도입하는 것은 좋은 지적인 것 같다). 이러한 사용자 권한을 통해 이러한 사용자가 완전히 보호된 기본 페이지 템플릿을 편집할 수 있는가? 알지 못하는 사람들에게, 기본 페이지에 보이는 거의 모든 텍스트는 템플릿에서 나온 것이다. 위키피디아에서 가장 눈에 띄는 페이지로서, 메인 페이지는 역사적으로 손상된 관리자 계정에 의한 공공 기물 파손의 첫 번째 대상 중 하나이다. 그리고 실제로 사이트 보안을 이유로 몇 명의 손상된 관리자가 차단되고 권한이 취소됨(이러다 보니 템플릿과 같은 편집 공지 사항 생성:편집통지서/페이지/메인 페이지, 경고 관리자). 예스라면 비슷한 사건이 없었으면 좋겠다. 템플릿 편집을 도와주는 것에 반대하지 않는다.뉴스에서 템플릿:다른 기본 페이지 템플릿도 알고 계시는지요? 하지만 강력한 암호를 사용하고 일반 관리자처럼 적절한 개인 보안 방식을 따르십시오. Zzzx11 (대화) 04:36, 2013년 9월 12일 (UTC)[]

난 내 질문에 대답할 수 있을 것 같아: 새로 만든 보호수준으로 설정하자는 공감대도 있는지, 아니면 기존의 완전한 보호수준에 그대로 두자는 것인지에 따라 달라진다. 또한 계단식 보호가 그러한 페이지에 어떤 역할을 하는가에 따라 달라진다: 새로 만든 보호 수준을 취소하고 자동으로 전체 보호를 적용할 것인가? Zzyzx11 (대화) 05:01, 2013년 9월 12일 (UTC)[]

나는 모두를 대변할 수 없고, 이 문제에 대해 어느 정도의 최종적인 답변을 하려는 것이 아니다. 이것은 아마도 논의되어야 할 사항이기 때문에, 나는 단지 그 논의에 기여하고 있을 뿐이다. 나 스스로 이것에 대해 생각해보면, 우리는 책임감 있게 그것을 다룰 수 있는 권리를 가진 사람들을 조사하고 신뢰하고 있다. 그리고 만약 있다면, 그것은 메인 페이지의 템플릿은 특별히 주의해서 다루어야 한다는 것을 알고 있고, 코드와 관련된 어떤 변화도 먼저 샌드박스화되어야 한다는 것을 의미한다. 이 권리를 갖게 되는 대부분의 사람들은 (그 목적을 위해 특별히 조사받았다는 사실만으로, 그리고 대부분의 관리자가 코더가 아니라는 이유만으로) 템플릿으로 무엇을 하고 있는지 더 많이 알 것이기 때문에, 계정 손상 문제는 남아 있는 것이다.

단순히 더 많은 계정들이 손상될 수 있다는 단순한 사실 때문에, 사람들은 이것을 손상된 계정들이 피해를 입힐 수 있는 위험을 증가시키는 것으로 볼 수 있다. 그렇다면 새 행정관을 많이 추가해도 마찬가지일 것이다. 각각의 수정은 동일한 위험(균등하지 않음, 손상된 관리자가 훨씬 더 많은 위해를 가할 수 있으므로)이 될 수 있지만, 우리가 편익을 대가로 계산한 위험(calcalcalculated improbability(수정: 동일하지 않음). 사실 우리는 새로운 관리자를 임명하거나 다른 권한을 부여할 때마다 계산된 위험을 감수한다. 나는 그들의 계정이 손상될 수 있는 위험을 제한하기 위해 취해진 조치에 관해서 템플릿 편집기를 관리자와 다르게 취급해야 하는 논리적인 이유를 모르겠다.

손상된 템플릿 편집자는, 그러한 편집자가 발생한다면, 손상된 관리자와 유사한 방식으로 처리될 것이다. 즉, 필요하다고 간주될 경우 템플릿 편집자가 권한을 훨씬 더 쉽게 취소할 수 있는 유일한 차이점이다. 이 권리를 요청하기 위한 최종 페이지에는 보안에 관한 적절한 경고와 권고사항이 포함되어야 하며, 또한 그러한 훌륭한 점을 제기해 준 것에 감사해야 한다.

나는 캐스케이드 보호에 완전히 정통하지는 않지만 그것이 아동 템플릿의 보호를 부모 수준으로 끌어올릴 것이라고 생각한다. 만약 현재의 관행이 메인 페이지 자체를 sysop 수준에서 계단식으로 보호하는 것이라면, 그것은 템플릿 편집자들이 그것의 템플릿에 대한 접근을 타당하게 얻을 수 없다는 것을 의미할 수 있다. 메인 페이지 템플릿을 편집하는 템플릿 편집자에 대한 일반적인 느낌에 따라 이를 허용하는 기술적 솔루션이 있는지 확인할 수 있었다. Equazcion 05:14, 2013년 9월 12일(UTC)

나는 계단식 보호 시스템이 구현에 중요한 기술적 장애물을 야기할 것으로 알고 있다. 일단 이 문제는 일단 접어두고, 나머지 템플릿 공간이 새로운 시스템 아래 있는 후, 미래의 어느 시점에 다시 시작해야 한다고 말하고 싶다. 몬티₈₄₅ 05:50, 2013년 9월 12일 (UTC)[]

나도 그렇게 알고 있어. (구성 매개변수의 예를 따르면, 새로운 보호 수준을 계단식으로 사용할 수 있게 함으로써 그것을 처리하는 방법이 있을 수 있어.) 동의한다. 동의한다. 이 페이지들에 대한 새로운 허가가 어떻게 작용하는지에 대한 느낌이 있는 후에 아마 더 잘 결정된다.그것이 통과한다고 가정할 때. PaleAqua (talk) 06:07, 2013년 9월 12일 (UTC)[]

새로운 보호 수준을 계단식 작업에 사용할 수 없도록 할 수 없다. 왜냐하면 그렇게 하면 새로운 사용자 권한을 가진 편집자가 페이지를 보호할 수 있을 뿐만 아니라 편집만 할 수 있기 때문이다. (카스케이드 보호 페이지에 있는 페이지를 초월하여 페이지를 보호할 수 있다.) 기본 페이지 템플리트 편집을 관리자에게 맡기는 것이 가장 좋을 것이다. 그러나 계단식으로 보호되는 템플릿은 실제로 그럴 필요가 없는 것이 많다. 예를 들어 {{db-meta}}은(는) 계단식으로 보호되지만 정말 필요하지는 않다 - 반보호 기능이 더 잘 맞을 것 같다. 이와 같은 템플릿의 경우 새 사용자 권한을 가진 편집자가 편집할 수 있도록 계단식 보호를 간단히 제거할 수 있다. — Mr. Stradivarius, 2013년 9월 12일 (UTC)[]

• 나는 메인 페이지의 모든 페이지들이 계단식 보호 하에 커버된다고 믿는데, 이것은 특정 네임스페이스에 대한 구현이 가능하지 않을 것이라고 개발자들과 논의한 후 이 제안에 대한 허가가 없는 것이다. 이 제안을 초안한 편집자들은 이 권리를 위한 자격을 갖춘 편집자들이 시작할 수 있도록 이것을 출발점으로서 가능한 한 슬림하게 만들기를 원했다. 초안에는 이와 같은 이해관계가 축소되어 이 제안이 통과될 경우 향후 RfC에서 제기될 수 있는 몇 가지 다른 사항이 있었다. 고마워요. 기술 13 (토크) 14:02, 2013년 9월 12일 (UTC)[]
  • 동의한다. 여기서 몇 가지 생각해 보고 반응을 읽어본 결과, 당분간은 그대로 두어야 할 계단식 보호를 제거하지 않으면 새로운 사용자 그룹에 의해 메인 페이지는 편집이 불가능할 것으로 보인다. 만약 미래에 필요하다고 판단되어야 한다면 이것은 항상 재검토될 수 있다. Equazcion 14:12, 2013년 9월 12일(UTC)

캐스케이드 보호는 나에게 걱정거리야. 내가 일하고 싶은 곳은 계단식으로 보호된다(모듈:인용/CS1). 템플릿 편집기 사용자 권한을 정의하는 정책 및 절차에는 계단식 보호된 페이지를 템플릿 편집기 사용자가 페이지를 편집할 수 있는 보호 수준으로 강등하는 방법을 지정하는 메커니즘이 필요하다.

—스승 (대화) 15:56, 2013년 9월 12일 (UTC)[]

Module:Citation/CS1은 위키백과에서 삭제될 수 있음:캐스케이드 보호 품목 및 보호 수준이 떨어질 수 있음 메인 페이지와 같이 "실제" 계단식 보호 페이지에 사용되는 모든 경우, 페이지를 보호하고 보호 해제할 능력이 없으면 페이지를 편집할 수 있는 방법이 없다. Jackmcbarn (대화) 16:10, 2013년 9월 12일 (UTC)[]

나는 당신이 이 페이지들이 위키피디아에서 그냥 삭제될 수 있다는 것이 옳다고 확신한다.계단식 보호 항목. 하지만 누가 그런 짓을 하지? 템플릿 편집기 사용자로 보호 변경을 시작하는 방법 보호 변경을 이행하기 위해 요청자와 관리자가 준수해야 할 정책과 절차는 무엇인가? 이런 것들이 지금 정의되지 않는다면, 정의될 필요가 있다. 그들은 정말로 이 RfC의 채택과 손을 잡고 있다, 그렇지 않은가?

—스승 (대화) 16:46, 2013년 9월 12일 (UTC)[]

폭포수 보호가 이렇게 엉망인 줄은 몰랐어. 위키백과에서 두 가지 모두 어떻게 사용되는지를 지지하는 광범위한 토론이 있었는가?캐스케이드 보호 품목의 다양한 사용자 공간 버전에서 사용하시겠습니까? 이 용도는 WP에 확실히 반영되지 않았다.캐스케이드. 나는 그것을 분류하는 것은 아마도 이 RFC의 범위를 벗어나는 것이라고 말하고 싶다. 몬티₈₄₅ 17:06, 2013년 9월 12일 (UTC)[]

그냥 아무 관리자에게나 제거해 달라고 하고, 그들이 그렇게 하기를 바란다. 그래, 엉망진창이야 Jackmcbarn (대화) 17:17, 2013년 9월 12일 (UTC)[]

현재 계단식 보호로 인해 템플릿 편집자가 직접 편집하는 것을 방해하는 여러 영역이 있지만, 대부분의 고위험 템플릿은 해당 범주에 속하지 않는다. 과거 이 같은 권리단체와 관련해 맞닥뜨린 저항세력과 지금 우리가 얼마나 가까이 다가가고 있는 것처럼 받아들여지고 있는 상황에서 이 시점에서 이것이 완벽한 해결책이 되라고 요구하는 것은 현명하지 않다고 생각한다. 계단식 보호에 의해 제기되는 문제는 나중에 공동체가 고위험 템플릿에 대한 접근 권한을 가진 신뢰할 수 있는 템플릿 편집자를 지원한다는 점에서 물류 관점에서 다룰 수 있다. 이 RFC가 통과되면 이미 입증될 것이다. 계단식 보호를 둘러싼 절차들은 이 제안과 같은 것을 염두에 두고 채택되지 않았으며, 나는 비교적 사소한 절차 부가 사항으로 다룰 수 있다고 확신한다. Equazcion 17:48, 2013년 9월 12일(UTC)

만약 그들이 신뢰한다면 그들은 허용되어야 한다.WWE 팬 4.0 (토크) 02:28, 2013년 9월 16일 (UTC)[]

제안추가

계단식 보호의 기술적 측면으로 인해 이것이 다소 모호한 점이 되겠지만, 나는 여전히 명시적으로 다음과 같이 언급해야 한다고 생각한다. 그러면 실제 전체 "동기식" 보호는 템플릿 및 모듈 네임스페이스에서 특별한 방법으로 사용할 수 있으며, 필요에 따라 관리자를 제외한 모든 사용자가 일시적으로 편집을 허용하지 않을 수 있다. 기본 페이지로 변환된 모든 템플릿과 모듈은 영구적으로 보호된다. (아래에 표시된 추가 사항). — PublicAmpers&^{(main account • talk • block)} 16:04, 2013년 9월 12일 (UTC)[]

나는 현재와 같은 이유들이 다소 진부한 상황에서 새로운 권리집단이 메인 페이지를 편집할 수 없을 것이라고 선언하는 것을 경계한다. 적어도 기술적/논리학적 한계 때문이고, 만약 그것이 향후 어느 시점에 바뀌게 된다면, 그것이 여전히 원칙에 따라 제한될 것인가 하는 문제가 있다. 메인 페이지와 관련된 이슈는, 만약 온다면, 오면서 그것에 대해 우려를 표명할 수 있는 누구에게도 설명해주는 것이 가장 좋을 것 같다. 나의 겸손한 의견. Equazcion 18:11, 2013년 9월 12일(UTC)

• 내가 영구히 말할 때 겪는 어려움은 메인 페이지는 역동적이고 끊임없이 변화하기 때문에, 언젠가 그 페이지 위에 옮겨져 있는 것이 반드시 다음 날이 되지는 않을 것이라는 점이다. 또한, 나는 그런 일을 추가하는 현재 문제가 있어야 하는가 새로운 template_editor 그룹"이런 지역에 역량을 보여 준 편집자들은을 소망할지도 모르는 사람 이상이 걸릴 위험이 높은 지역을 열지 않고non-cascading 보호된 템플릿을, 그리고 editnotices 편집할 수 있는 집중 t. 해를 줄 생각하길불쌍히 여겼고, 그 encyclo페디아?" 만약/언제, 이 제안이 통과된다면, 향후 RfC에서 추가 특권 및/또는 제한을 완충하는 것은 불합리하지 않을 것이다. 기술 13 (토크) 18:39, 2013년 9월 12일 (UTC)[]

워치리스트 공지

나는 이 토론이 충분한 편집자들에게 영향을 미쳐서 감시 목록 통지의 혜택을 받을 것이라고 생각한다. 다른 사람들은 이것이 좋은 생각이라고 생각하는가? — Mr. Stradivarius, 2013년 9월 13일 (UTC)[]

물론이지 Equazcion 12:54, 2013년 9월 13일 (UTC)

관리자만 있으면 돼! 오, 잠깐... 예! 기술 13:53, 2013년 9월 13일 (UTC)[]

나는 미디어위키 토크에 다음과 같은 제안을 추가했다.감시자 명세서. RfC의 초안 작성에 관여했으므로 적어도 당장 실행하기는 싫다. 아마 며칠이 지나도 이의가 없으면 나는 그것을 추가할 수 있을 것이다. 하지만 나는 그 페이지를 보는 편집자들에게 먼저 그것에 대해 논평할 기회를 주고 싶다. — Stradivarius씨^{♪ talk ♪} 14:22, 2013년 9월 13일 (UTC)[]

네, 해주시죠. —Anne Delong (대화) 14:53, 2013년 9월 13일 (UTC)[]

이제 덧붙였다. — Mr. Stradivarius 23:13, 2013년 9월 14일 (UTC)[]

이게 무슨 뜻인지는 모르겠지만 내 감시 목록에 올라와서 여기서 얘기해야겠다고 생각했어 감사합니다. 뉴잉글랜드 캅 (토크) 01:58, 2013년 9월 15일 (UTC)[]

대안책

나는 이 일에 관여하지 않았고 그럴 의도도 없다. 나는 위 WDGraham의 주장이 상당히 설득력이 있다고 생각한다. 그리고 만약 이 RfC가 성공하지 못한다면 WDGraham의 논평이 몇 가지 다른 조치들을 고무시킬 수 있을 것이라고 생각한다. 구체적으로:

• 템플릿용 샌드박스에 대한 지침이 있는가? 만약 사람들이 그것을 하는 가장 효율적인 방법을 안다면 그들은 더 쉽게 설득될 것이다. 좀 써야 할 것 같아. 또는 이미 이것에 대해 정말 좋은 에세이가 있다면(또는 이와 비슷한) 약간의 광고만 필요할지도 모른다.
• 템플릿의 사전 예방적 보호를 줄이는 가장 좋은 방법은 무엇인가? 현재 완전하게 보호되어야 하는 템플릿이 있는가, 아니면 보호되지 않아야 하는 템플릿이 있는가?

야리스678 (대화) 09:48, 2013년 9월 15일 (UTC)[]

선제적 보호에 대한 내 의견을 확대하기 위해 좋은 예는 모듈:이러한 논의를 촉발시킨 것으로 보이는 RfA의 중심에 있는 템플릿인 인용/CS1. 그래, 널리 쓰이지만, 그것은 기사로 직접 번역되지 않는 불명확한 하위 페이지야. 하루 평균 30회 미만의 조회수를 기록하지. 파괴적인 사용자들이 그것을 찾을 것 같지 않고 만약 그들이 그것을 한다면 관리 가능한 속도로 그들은 그것이 기사로 전파되기 전에 되돌아갈 것이다. --W. D. Graham 10:18, 2013년 9월 15일 (UTC)[]

중요한 템플릿에 대한 중요한 변경사항은 이미 샌드박스에 저장되어 있다. 문제는 무엇보다도 변화를 확인하고 이행할 수 있을 만큼 자신이 하고 있는 일을 알고 있는 관리자가 부족하다는 점이다. 문자 그대로 거의 아무도 실제로 {{editteprotected} 대기열을 다루는 사람이 없으며, 그렇게 하지 않으면 아무것도 이루어질 수 없기 때문에 단순히 돕기 위해 그것을 하는 커플은 코더가 자신이 무엇을 하고 있는지 알고 있다는 맹목적인 믿음으로 편집을 실행한다.

CS1과 상대적으로 덜 알려진 다른 모듈들은 실제로 평균적인 고사용 템플릿보다 더 위험하다고 말할 수 있는데, 그것은 누구나 거의 관찰하지 않고, 낮은 수준의 기술 템플릿이기 때문에, 문제는 신속하게 추적되지 않을 것이다. 사실 그 이유로 인해, 깊이 인식되고 상대적으로 알려지지 않은 템플릿이 거의 유일하게 완벽하게 보호되던 시절이 있었다.

우리는 선제적 보호관행의 만연성에 대해 토론할 수 있지만, 이것은 새로운 문제가 아니기 때문에 그렇게 되었다. 이 최근의 제안은 사용자 트라피스트와 그의 CS1 작업에 의해 촉발되었지만, "보호"를 통해 편집이 허용되는 신뢰할 수 있는 사용자 그룹을 만들기 위한 제안의 오랜 역사가 있다. 모두 실패했는데, 일차적으로 행정도구의 '분할' 원칙을 건드렸기 때문이다(모든 것을 할당하지 않고 하나의 행정력을 할당할 수 있도록). 입증된 필요성과 적성이 입증된 작업물에 대한 허가를 엄격히 제한하자는 이 제안은 "번들링"을 둘러싼 끊임없는 논란과 드라마를 헤쳐나가려는 노력의 일환으로 그들의 먼지 속에서 나온 것이고, 아마도 수년이 지난 후에, 아마도 마지막으로, 우리의 의지와 능력을 갖춘 훌륭한 코더들을 대량으로 공급받게 될 것이다. 그들이 할 수 있는 접근권.

사람들이 더 이상적이라고 말할 수 있는 많은 대안들이 있다; 문제는 그것들을 분열된 공동체에서 구현하는 것이다. 그들 중 많은 수가 이미 시도되고, 논의되고, 토론되고, 제안되었다. 이것은 새로운 문제가 아니다. 만약 이 제안이 적어도 타협이 될 수 있고, 많은 사람들이 유혹에 넘어가지 않을 수도 있지만 최소한 용인할 수 있다면, 우리는 마침내 이번에 실제적인 진보적인 조치를 취할 수 있을 것이다. Equazcion 11:15, 2013년 9월 15일 (UTC)

내가 다른 곳에서 이런 말을 했을 수도 있지만, 나는 편집이 보호된 대기열을 보고 있다; 텍스트만 변경하면, 논란의 여지가 없어 보이면, 문제가 없다. 마찬가지로, 만약 실제로 합의가 뒤따르는 토론이 있다면, 나는 변화를 만들 의향이 꽤 있다. 왜냐하면 최악의 경우 문제를 일으킨 것에 대해 찬성하는 의견이 있었기 때문이다. 문제는 대기열에서 편집한 대부분의 내용이 비교적 복잡한 템플릿 코드에 대한 변경을 포함하며, 대부분의 템플릿은 코드 구조를 쉽게 따르도록 코딩되지 않으며, 여러 개의 중첩된 템플릿에 대해서는 코드의 기능을 이해하기 위해 템플릿을 기본적으로 해체하는 데 많은 시간이 소요될 수 있다는 점이다. 샌드박싱은 비교적 단순한 템플릿에 적합하지만 복잡하거나 내포된 활용 사례는 너무 많아 샌드박스를 사용해도 파손 여부를 평가하기 어려울 수 있다. 이제 나는 요청자가 옳게 얻은 것을 맹신하는 관리자들을 탓하지 않지만, 나는 그것을 하는 것이 편치 않으며, 그것이 아마도 그곳의 적극적 관리자들의 부족의 주요 요인이라고 생각한다. 몬티₈₄₅ 05:05, 2013년 9월 17일 (UTC)[]

나는 거기서 아무런 판단도 하지 않는다. 내가 전에 말했듯이, 그것은 단지 진술이 필요한 사실일 뿐이다. (보호된 편집 대기열을 맡는 관리자가 거의 없다는 사실 - 하지만 그렇게 하는 사람들 중 한 명이 되어줘서 고마워!) 코딩 편집은 자신이 무엇을 하고 있는지 알고 있어도 평가하기가 쉽지 않고, 내가 관리자라면 내가 직접 보호된 편집 요청으로부터 멀리 떨어져 있을 것이다. 여러분이 노력을 쏟는 대본 두 개를 맡는 것은 한 가지 입니다. 하지만 이건... 다른 코딩 프로젝트의 모든 방식에 걸쳐 서로 관련이 없는 몇 가지 편집 내용을 차례로 평가하는 것은 쉽지 않고, 재미도 없고, 빠르지도 않다. 그것은 효율적이지도 않고 필요하지도 않다. Equazcion 11:17, 2013년 9월 17일 (UTC)

제거 기준 단순화

위의 제거 기준을 다음과 같은 일반 기준으로 대체하십시오.

1. 편집자는 12개월째 활동을 하지 않고 있다.
2. 편집자는 실수로 도구에 대한 액세스 권한을 부여받았다.
3. 편집자는 반복된 경고 후에 도구를 남용하는 패턴을 보여준다.
4. 편집자가 노골적으로 도구를 남용하다.

2번은 새로운 것으로, 관리자가 거짓된 핑계로 접근 권한을 부여하도록 속인 경우(예: 편집자가 부여 관리자에게 공개되지 않은 복수의 계정, 이것은 그의 "깨끗한" 계정), 또한 누군가가 접근해서는 안 될 때 접근하게 되는 사무상의 오류(예: 부여 관리자에 의한 사용자 이름-일반)를 다루기 위한 것이다.

3번에는 반복적인 블래터블러티 기물 파손, 파괴적인 편집, 충분한 주의를 기울이지 않고 논쟁적인 상황에서 우위를 점하기 위한 도구 사용, 그리고 반복적인 오용에 따른 경고의 결과를 초래하는 다른 도구 사용에 대한 내용이 포함된다.

4번은 노골적인 오용을 다루는데, 대개 관리자 재량에 따라 차단을 받을 수 있는 종류의 것이다. 한 번 스트라이크를 하면 넌 탈락이야.

생각? davidwr/(대화)/(기여) 00:36, 2013년 9월 17일 (UTC)[]

#2는 약간 소름끼치는 것 같다, 즉 지나치게 구체적이다. 반드시 일어나게 되어 있고 그 후에 사실로 증명되는 극히 드문 경우에, 나는 어떤 조치가 취해져야 하는지에 대해서는 의심의 여지가 없을 것이라고 생각한다.

반면에 3과 4는 해석에 약간 너무 개방적이다. '갑질'은 모든 것을 커버하지만, 빈혈이고 애매모호해서 그렇다. "모두가 동의하는 목적으로 사용한다면 허가를 취소할 수 있다"는 말과 같다. 이들 제안의 이력을 감안할 때 해임기준은 안심할 필요가 있다. 정확히 무엇이 학대를 구성하게 될 것인지를 보다 구체적으로 제시하는 것이 무엇보다 중요하다고 생각한다. Equazcion 01:09, 2013년 9월 17일(UTC)

대체임용절차

관찰 결과, 서기가 되기 위한 과정이 끝난 후에 임명 과정을 더 잘 모델링할 수 있을 것이다. 점원 임용제도는 매우 잘 작동하며, 비슷한 기준이 적용되는데, 이는 여러분이 그들의 동료들로부터 검사를 받은 사람들을 원한다는 점에서 그렇다.

SPI 점원 프로세스에 따라 다음 절차를 제안한다.

상태가 양호한 사용자는 템플릿 편집기로 간주할 것을 요청할 수 있다. 템플릿 편집기는 처음에 템플릿 편집기에 대한 요청에 따라 현재 템플릿 편집기 구성원 자격의 합의에 따라 수락된다. 기술 역량 편집 템플릿 및/또는 모듈에 대한 입증된 기록이 없는 경우, 예비 템플릿 편집자에게 수습 기간(일반적으로 X개월 지속)을 제공하도록 요청할 수 있으며, 이 기간 동안 편집 내용은 전체 템플릿 편집자의 승인을 받아야 한다. 그러면 템플릿 편집자는 문제를 결정할 관료에게 템플릿 편집자 전체 지위를 추천할 수 있다.

나는 이것이 그 제안에 반대하는 사람들이 주는 많은 우려를 주어진 것으로서 해결한다고 생각한다. 특히, 어떤 오픈소스 프로젝트에서처럼 재능 있는 코더라도 기술팀에 바로 뛰어들 수 있다.

우연히, 자전거 타기의 위험을 무릅쓰고, 우리는 "템플릿 편집기"보다 더 멋진 이름을 생각해 낼 수 있을까? "기술자"는 어떠세요? -- 드 게레 (토크) 08:11, 2013년 9월 18일 (UTC)[]

나는 현재 회원들이 누구를 회원으로 받아들일지 결정하는 시스템을 만드는 것을 경계할 것이다. SPI와 Arb 사무원 모두 그들이 서기를 맡고 있는 사람들에 의해 감독을 받는 반면, 템플릿 편집기 카발은 매우 독립적일 것이다. 위키에 그런 제도가 존재하는 곳은 다른 크랫들에 의해 판단되는 크라트로의 승격뿐이지만, 워낙 참여도가 높은 토론이며, 그만큼 높은 지원수준이 요구되기 때문에 이 문제는 상당 부분 해소된다. 이제 템플리트 편집자 알림판을 가지고 있고(이미 너무 많은 알림판을 가지고 있다는 것을 알고 있다), 그리고 누구에게나 열려있겠지만, 주로 템플리트 편집자에 의해 주목을 받고 참여하게 되는, 그 오른쪽에 대한 요청에 대한 짧은 토론을 하는 것과 같은 좀 더 부드러운 것이 더 받아들일 수 있는 발상이 될 것이다. 이름에 대해서는, 자기 설명이 더 잘 되어 있는데, 기술자가 보호된 템플릿의 편집자를 의미한다는 것을 누구도 직감하지 않을 것이다. 몬티₈₄₅ 17:47, 2013년 9월 18일 (UTC)[]

현재의 제안에서 내가 싫어하는 것은 어떤 관리자든 그 기술이 있든 없든 간에 누구든지 템플릿 편집자로 만들 수 있다는 것이다. 이것이 Davidwr의 제안 #2의 근거다. 나는 해결책을 제시하지 않고 불평하는 것이 잘못되었다고 생각했기 때문에 구체적인 절차를 제안했을 뿐이다. 해결책으로는 팔지 않지만, 그것과 데이빗워의 제안이 모두 해결하려고 하는 문제는 진짜 문제라고 생각한다. -- 드 게레 (토크) 07:45, 2013년 9월 19일 (UTC)[]

절차 없이 특정 권한을 처리하는 것은 일반적으로 허가된 만큼 쉽게 취소할 수 있기 때문에 안전하다고 간주된다. Monty가 "공지판" 유형의 구현을 숙고하고 있는 것에 대해, 나는 WP를 검토하고 있었다.PUMER, 이 허가에 대한 요청이 있을 예정인데, 나는 거기에 외부 의견을 명시적으로 금지하는 것은 없다고 본다. RfA-esque가 되지 않도록 무심코 투표 환경을 장려하는 것이 망설여지겠지만, 편집자들이 신청자의 사전 요구 사항이 정확하다는 것을 순수하게 확인하는 데 도움을 주도록 하는 것은 고려할 만한 일일지도 모른다. Equazcion 08:26, 2013년 9월 19일(UTC)

드 게레, 편집 필터 매니저를 제대로 생각해봐. 그 권한은 관리자가 부여할 수 있지만, 그 권한은 거의 없지만, 매우 조심스럽게 분배된다. 요청은 편집 필터 토크 페이지로 가서 일정 시간 동안 앉아 이의제기를 허용하고, 만약 내가 연습을 이해한다면, 최종 허가 전에 A에게 하루 동안 교차 게시되는 경우가 많다. 템플릿 편집자 권리는 그렇게 엄격할 필요는 없지만, 그곳의 관행은 대안의 예를 제공한다. 몬티₈₄₅ 14:12, 2013년 9월 19일 (UTC)[]

나의 비슷한 두려움은 관리자들이 단순히 모든 또는 대부분의 요청을 신뢰할 수 없는 것으로 또는 어떤 다른 이유로 부정할 것이기 때문에 결국 그것은 쓸모없는 역할일 뿐이다. 이것은 우리가 얻을 수 있는 만큼 좋지만 여전히 이상적이지는 않다. 이상적으로는 노련한 편집자들이 모든 쟁점과 드라마 없이 관리자 도구에 접근할 수 있도록 하는 것이 좋을 것이다. 만약 그들이 그것들을 남용했다면, 그 도구들은 다시 빼앗길 수 있을 것이다. 그러나 관리 클럽은 절대로 그것을 허용하지 않을 것이기 때문에, 우리가 할 수 있는 유일한 일은 보호 템플릿에 접근하는 대부분의 관리자들은 그들이 어떻게 작동하는지 모르기 때문에 새로운 사용자 권리를 만드는 추가적인 어려움을 겪는 것이다. 138.162.8.57 (대화) 18:10, 2013년 9월 24일 (UTC)[]

@138.162.8.57: RfA 토크 페이지에서 비슷한 말을 하는 너의 댓글을 방금 봤어. 여기서 얼마나 많은 경험을 했는지는 모르겠지만(CIDR 범위 검색에서 138.162.0.0/16의 기여도를 1만 건으로 계산함) RfA에서는 새로운 관리자 진급에 대해 좀 더 신중한 비관리자들이 종종 참석했는데, 이는 과거에는 필요할 때 도구를 제거하는 데 몇 달, 많은 드라마들이 필요했기 때문이다. 템플리트 편집자 제안의 좋은 점은 관리자가 되고 싶지 않고 필요한 배경과 정책 지식이 없는 사람들에게 적합하다는 것이다. 그러니 아직 제안서를 지지하지 않으셨다면 그렇게 해주십시오! - 고마워 - 포인틸리스트 (대화) 21:12, 2013년 9월 24일 (UTC)[]

당신이 묘사하는 데 게레, 클럽의 독점적 사고방식을 부추길 것 같다. 논쟁의 여지가 없을 정도로 겸손한 사람일지라도 아이러니컬한 허영심을 조장하기 때문에, "스냅피" 타이틀을 부여하자는 제안은 위험하다. 그것을 현행 회원들의 승인을 받아야만 사람들이 들어올 수 있도록 하는 정책과 결합하면, 의제와 엘리트주의에 대한 비난의 레시피가 있다. 구체적인 권리는 전통적으로 관리자에 의해 부여되는데, 일반적으로는 싱거운 문자 그대로의 설명인 직함을 가지고 있으며, 실제로 나는 그것이 가장 안전한 경로라고 생각한다. Equazcion 02:35, 2013년 9월 19일 (UTC)

• 이름 비트의 경우, "템플릿 커밋터"가 더 나은 이름이 될 수 있는지 궁금했다. 이 허가는 많은 오픈 소스 프로젝트에서 커밋 비트와 유사하며, 커밋이라는 용어를 사용함으로써 분기(샌드박스)에서 수행되는 변경의 새로운 프로세스에서 원하는 프로세스 모델을 호출하고, 변경사항이 괜찮다는 것을 보장(동의 등)한 후에 커밋(페이지 보호 등을 통해 적용)한다. 이것 없이는 다른 편집자들이 만들거나 템플릿 작업을 할 수 없는 "템플릿 편집기"라는 이름의 함축도 피한다. PaleAqua (talk) 2013년 9월 19일 16:15 (UTC)[]
  • 부정적인 낸시처럼 들릴 위험을 무릅쓰고... 템플릿 커밋이 기술적으로 더 정확할 수 있지만, 또한 더 난해한 -- 즉. 지역사회에 대한 직관력이 떨어지는 것. 나는 또한 개인적으로 "템플릿 편집자"가 "나는 단지 초능력을 가지고 있다"가 아니라 "나는 우연히 템플릿을 전문적으로 다루는 편집자일 뿐"이라는 것과 같이 특별한 "별일 없는" 함축성을 가지고 있다고 생각한다. 만약 다른 모든 사람들이 다르게 느낀다면 당연히 그 이름은 바뀔 수 있다. Equazcion 19:13, 2013년 9월 19일(UTC)
• 템플릿 코드 작성자 또는 단순 코드 작성자는? 이 페이지에 대한 감시자 통지가 읽은 내용과 일치한다.--Siddhartha Ghai (대화) 21:04, 2013년 9월 21일 (UTC)[]
• 나는 그 이름에 대해 그다지 강하게 생각하지 않지만, "경련자"는 어떤 의미가 있다. 여기 엔위키에서 점원들은 과정을 중립적으로 따르는 사람들인 것 같다. 마찬가지로, 관리자들은 자신들의 관점을 지지하기 위해 그들의 힘을 사용해서는 안 된다. 그들이 지역사회의 신뢰를 잃기라도 하면 안 된다. 하지만 나는 우리가 잠재적인 템플릿 편집자들로부터 이런 종류의 소극적인 입장을 기대한다고 생각하지 않는다, 그렇지 않은가? 반대로, 그들은 우리가 늘 하는 유형의 기고자가 될 것이고, 항상 무언가를 고치려는 동기가 있을 것이다. 유일한 차이점은 그들이 광범위하게 기사화 되어 있는 템플릿을 다룰 수 있는 [기술력, 경험, 조심스러운 기질 등]을 가지고 있다는 것을 증명했다는 것이다. 우리가 의미하는 것은 "보호된 템플릿 편집기"이다. 그렇게 말하는 가장 좋은 방법은 무엇일까? - 점묘사 (대화) 21:36, 2013년 9월 24일 (UTC)[]
  • 나는 PaleAqua의 "템플릿 커밋터" 제안이 가장 정확하면서도 우리가 원하는 것이라면 간결하다고 생각한다. 나는 여전히 "템플릿 편집자"가 엘리트주의를 잘 피하면서 충분히 정확하다고 생각한다. 그러나 만약 다른 이름이 있다면, 템플릿 커밋자는 지금까지 언급된 사람들 중에서 나의 표를 가지고 있다. equazcion ^ 21:45, 2013년 9월 24일 (UTC)

해지-포인트 번호 5에 대한 기준

나는 이 제안서와 숙련된 편집자들을 위한 이 새로운 사용자 권리를 만들기 위해 타당하다고 제공된 모든 이유를 발견했다. 그러나 내가 별로 유용하지 않다고 생각하는 한 가지는 편집자가 12개월 동안 활동을 하지 않았다는 취소 기준의 5번 지점이다. 또한 롤백, 자동 실행, 검토자, 파일 이동자와 같은 다른 사용자 권한과 계정 작성자, 관리자 및 관료주의를 제외하고 해당 사용자가 12개월 이상 비활성 상태였더라도 이러한 권한이 제거되지 않는 기타 사용자 권한을 가지고 있다. 계정 작성자는 사용자가 더 이상 ACC 과정이나 교육 프로그램에 관여하지 않고 이러한 장소에서 활동을 중지하는 경우 대개 제거된다. 하지만 그건 다른 거야. 이 사용자 권리는 위키백과 편집과 관련이 있고, 편집자가 템플릿 편집자 권한을 오용하지 않는다고 믿을 수 있다면, 그리고 그들은 그것을 건설적으로 사용해 왔다; 나는 단지 각각의 사용자/편집자가 비활용적이라는 이유만으로 1년 후에 그것을 제거해야 할 이유를 모르겠다. 그런데 왜 굳이 여기에 그것을 가지고 있어야 하는가? GeneralUser (talk) 16:03, 2013년 10월 2일 (UTC)[]

• 전적으로 동의해, 관리자들에게 적용되는 이유와 비슷한 이유로 일반 조항으로 추가된 것 같아. 나는 지금 이 시점에서 이 조항이 삭제되는 것을 지지하지만, 이와 같은 조정은 후속 RfC에서 약 6개월 후에 이루어져야만 이 조항이 있는 사람들에게 더 잘 작동할 수 있다고 생각한다. 나는 우리가 권리가 어떻게 사용되는지에 대한 약 6개월의 자료를 얻을 때까지 기다리는 것이 대부분의 사람들이 편안하게 느낄 수 있는 방법으로 이러한 것들을 수정하는데 큰 도움이 될 것이라고 생각한다. 기술 13 (토크) 16:16, 2013년 10월 2일 (UTC)[]
• 나는 일반적인 원칙에 동의하지 않는다: 실제로 수동으로 수행할 수 없는 작업을 수행할 수 있는 기능을 제공하는 모든 사용자 권한은 요청 시 다시 활성화하는 데 대한 편견 없이 오랜 기간 동안 사용하지 않은 후에 자동으로 제거되어야 한다. 그 이유는? 장기간 활동을 하지 않으면 계정이 자신도 모르게 손상될 가능성이 커진다. 심지어 1년 이상 사용하지 않는 계정도 자동 확인 상태를 잃게 하고, 계정이 손상되면 자동 확인/확인 상태를 필요로 하는 남용에 즉시 사용할 수 없게 된다. 나는 기술 13에 동의한다. 이것을 논의하기 위한 가장 좋은 시기는 그것이 시행된 후 몇 달이 될 것이다. 나는 6개월의 기다림에 만족하고, 물론 지역사회가 이 요구를 철회하기로 동의한다면 나는 괜찮다.davidwr/(대화)/(출연) 21:33, 2013년 10월 2일 (UTC)[]

템플릿이 무엇인지 어떻게 정의하고 있는가?

나는 이것을 다 읽어 보았는데, '템플릿'의 정의가 모호하다고 생각한다. (핵심문장을 놓쳤으면 계몽해줘 : )

기술적 관점에서, 템플릿이 템플릿의 모든 것, 즉 공간과 동일하다고 가정하는 것이 옳은가? 그리고 그것은 다른 어떤 것도 포함하지 않는다.

내가 구체적인 것을 요구하는 이유는 첫째로, 우리 모두가 알고 있는 것처럼, 대부분의 페이지는 템플릿 공간의 페이지처럼 변환될 수 있고, 둘째로, 이것이 어떤 방식으로든 미디어위키 공간을 포함하는지 여부. - jc37 05:59, 2013년 10월 3일 (UTC)[]

템플릿 네임스페이스 또는 모듈 네임스페이스에는 "템플릿"이 포함될 수 있다. 템플릿과 모듈 네임스페이스에만 적용할 수 있는 새로운 종류의 보호를 만든 뒤 기존의 모든 보호 템플릿과 모듈에 대한 보호를 새로운 유형의 보호로 전환하자는 제안이다. 그런 다음 우리는 편집자가 새로운 종류의 보호로 보호되는 페이지를 편집할 수 있는 새로운 사용자 권한을 만들 것이다. 또한 이 사용자 권한을 통해 편집자가 제목 블랙리스트(모든 네임스페이스에서)를 바이패스하여 편집자에게 편집 통지를 작성할 수 있는 권한을 부여할 것을 제안한다. 사용자 권한은 네임스페이스에 의해 제한되지 않으므로 새로운 유형의 보호가 필요하고 템플릿 네임스페이스에 대한 블랙리스트 통과를 제한할 수 없는 이유. 이 제안에는 미디어위키 네임스페이스를 편집하는 데 필요한 권한이 포함되어 있지 않다. (이것은 단지 나의 이해일 뿐이라는 점에 유의하십시오. 만약 내가 잘못된 세부사항을 가지고 있다면, 얼마든지 고쳐주십시오.) — Stradivarius 07:32, 2013년 10월 3일 (UTC)[]

본질적으로 스트라디바리우스 씨의 말이다. 보호의 체계적 변화는 템플릿: 네임스페이스의 템플릿에 대해서만 발생할 수 있다. 템플릿 외부의 변환된 페이지: 공간이 포함될 수 있는지 묻는다면, 동일한 이유로 완전히 보호되어 있다면, 예를 들어, 높은 위험성을 야기하는 높은 변환률로 인해 해당 페이지가 보호될 수 있을 것이다. 현재 그런 페이지는 잘 모르겠지만, 만약 그런 페이지가 있다면, 그것도 아주 드문 경우일 겁니다. 케이스 바이 케이스(case by case)에 따라 새로운 보호 수준으로 전환될 수도 있을 겁니다. 만약 여러분이 염두에 두고 있는 어떤 구체적인 예들이 있다면, 우리가 그것들을 살펴본다면 이것에 대답하는 것이 더 쉬울지도 모른다. 미디어위키 공간의 경우, 이 제안은 전혀 관련되지 않는다. 이 제안은 2013년 10월 3일 (UTC)

정말로, 그 지상에서 보호를 받을 자격이 충분할 정도의 전용이 있는 것은 이미 템플릿 공간에 있어야 할 것이다(사용자 박스는 예외로 할 수 있지만, 어쨌든 그 중 어떤 것도 보호되고 있는지 모르겠다). 몬티₈₄₅ 16:02, 2013년 10월 8일 (UTC)[]

@Equazcion: 나는 그 아이디어가 모듈: 네임스페이스도 포함하는 것이라고 생각했다. 아니면 내가 여기서 놓치고 있는 것이 있을까? — 2013년 10월 9일(UTC) 투어 06:49^{♪ talk ♪}, Stradivarius씨[]

편집 통지처럼 모듈 네임스페이스가 실제로 포함되어 있다. 페이지 전이에 대한 Jc37의 특정 질문에 간단하게 답할 수 있었다:) Equazcion 09:14, 2013년 10월 9일 (UTC)

템플릿 코드 구문 강조 표시

관심 있는 사람: 사용자:Equazcion/WikiTemplate UDL equazcion ^ 03:46, 2013년 10월 10일 (UTC)