위키백과:마을 펌프(제안)/아카이브 79

위키피디아 우리 자연의 섭리

우리 본성의 선함을 위해 관련된 모든 주제들이 거기에 있을 것이라는 위키피디아를 게재하는 것은 어떨까?그래서 사람들은 우리의 고향 행성을 죽일 수 있는 나쁜 영향을 노출시킬 수 있다.이 간단한 메시지로 내가 하고 싶은 말을 알아내길 바래.감사 인사 및 팀에 더 많은 권한을 부여 — 202.57.35.107 (대화 • 기여) 09:51, 2011년 10월 14일 (UTC)[응답]

위키피디아와 충돌할 수도 있는 것은 여러분의 숭고한 대의에 대해 세상에 알리려는 것이 아니라, 우리는 환경보호주의와 관련 주제에 대한 기사를 가지고 있다.Dcoetzee 10:08, 2011년 10월 14일 (UTC)[응답]

포털을 찾고 있을 수도 있다.환경?스벤망구아르드화?11시51분,2011년10월15일(UTC)[응답]

우리는 위키피디아가 비누 상자가 아니라는 것을 기억해야 한다. 여러분이 세상에 말하고 싶은 고귀한 명분을 가지고 있을 수 있다. (위키피디아: 참조) 위키피디아가 아닌 것은) 그러나 위에서 지적한 바와 같이, 우리는 환경보호주의에 관한 기사를 가지고 있다.위키피디아가 이런 종류의 기사를 더 필요로 한다고 강하게 느낀다면, 만약 이미 위키프로젝트가 없다면 환경보호에 관한 위키프로젝트를 세우는 것은 어떨까?ACEOREVIVEED (토크) 15:08, 2011년 10월 20일 (UTC)[응답]

실제로 위키피디아가 있다. 위키프로젝트 환경.ACEOREVIVEED (토크) 15:21, 2011년 10월 20일 (UTC)[응답]

위키키즈 - 비키디아: 어린이를 위한 백과사전

모두 안녕하세요

나는 방금 이 주제에 관한 오래된 메시지들을 확인했는데, 가장 최근에는 여기 저기서: "우리는 간단한 영어 위키백과가 있다."라는 응답과 함께.")

나는 프랑스어 위키백과 전문 언어학자로, 이 꽤 오래된 프로젝트에 대해 말하고 싶다: 아이들이 디자인하고 부분적으로 유지 관리하는 위키 백과사전이다.

어린이들을 위한 위키백과와 동등한 개념은 이 페이지에서 특히 2005-2006년에 논의되었다:메타:위키키드

위키미디어 프로젝트로 계속되지는 않았지만, 그러한 특징을 가진 위키들이 네덜란드어로 먼저 출시되었다: 위키키즈; 몇 달 후 프랑스어로:비키디아 ([1]) 다음으로 스페인어로 (스페인어로 Vikidia) 8-13세 어린이용.비키디아를 개업했다.

프랑스어 위키키즈와 비키디아는 잘 지내고 있고 크기와 활동성이 상당히 비슷한 반면 스페인어 비키디아는 그렇게 잘 만들지 못한다.

프랑스어로 된 비키디아에 대해서는 현재 방명록이 개설되어 있으며, 이에 대한 댓글은 상당히 고무적이다(구글 번역).아이들은 위키피디아보다 글을 더 읽을 수 있는 것에 감사한다고 말하는데, 어떤 글은 충분히 개발되지 않았거나, 그들이 알고 싶은 모든 주제에 대한 기사가 없다는 것이 그들의 주요 예비사항이다...위키백과의 내용보다 더 쉬워야 하지만, 그들은 분명히 어떤 실질적인 내용을 기대하고 주장한다.

우리는 아직 프랑스어로 된 비키디아에 1만 건이 조금 넘는 기사를 보유하고 있으며, 한 달에 22만 명 정도의 독특한 방문객들이 방문한다.

이 "위키드" 질문은 1년 전 위키미디어 범위에서 다시 언급되었다:meta:2010 위키미디어 논란 콘텐츠 연구: Part 2#권고: 논란의 여지가 있는 텍스트:

---

권장 사항:논쟁의 여지가 있는 텍스트

위에서 설명한 고려사항 때문에 WMF 프로젝트에서 텍스트를 둘러싼 권고사항은 다음과 같다.

권장사항:

(...)

3. 그러나, 그 재단은 12세 이하의 어린이를 대상으로 하는 위키피디아 버젼의 「위키 주니어」의 창설을 단독 프로젝트로서 또는 현존하는 적절한 교육 기관과 제휴하여 조사한다.

설명:

(...)

권장 사항 2 및 3

(...) 훨씬 더 성공적인 것은, 우리 생각에는, 특별히 어린이들을 대상으로 하는 프로젝트로서, 다른 연령대의 어린이들의 상당히 다른 욕구를 대상으로 하는 프로젝트라고 생각한다. 위키북스의 위키 주니어 섹션에서는 이미 이러한 성격의 프로젝트들이 시작되었지만,^[1] 그러한 벤처의 범위가 이미 이 분야에 헌신한 경험과 자원을 가진 기관과의 파트너십 형성이 필요할지도 모른다는 것이 우리의 느낌이다.

---

...메타에 이렇게 답장을 썼는데...사용자 대화:SJ.

WikiKids/Vikidia의 또 다른 특징은 물론 아이들이 콘텐츠 제작에 참여하도록 하고, 학생들을 위한 위키키디아의 편집 워크샵에서 찾을 수 있는 것과 같은 혜택을 위해 어린이들을 위한 콘텐츠 제작과 제공만을 "목표"하지 않는다는 것이다.10대, 학생, 성인 작가들과 함께 비키디아에서 편집하는 일부 학교 프로젝트와 자원봉사자(그리고 종종 열정적인) 아이들이 있다.

나는 다른 언어로 만들어진 다른 동등한 영어 위키피디아가 없다는 것을 명심한다.나는 위키피디즈를 영어로 만드는 것이 어느 정도는 단순함과 비슷할 것이기 때문에 덜 쉽게 만들 것이라고 추측한다.나는 또한 이 위키가 그렇게 크지 않고 다른 언어로 만들어지지 않았다는 사실은 그것의 목표가 그렇게 명확하지 않고, 동원되고, 정당화되지 않을 것이라는 것을 보여줄지도 모른다고 말하고 싶다.그런데, 비키디아에서는, 우리는 어린이들뿐만 아니라 어떤 주제에 대한 간단한 접근이나 위키백과보다 더 짧은 접근을 원하는 모든 연령대의 사람들에게 유용하기를 바란다.우리는 만약 그것의 내용이 나이든 사람들과 관련이 없다면, 그것은 어린이들에게도 좋지 않을 것이라고 생각한다.

제 질문은 물론입니다: 왜 아직 영어로 위키피디스가 없는가?;-)

인사말, Astifyes (대화) 18:04, 2011년 10월 20일 (UTC)[응답]

자, 당신의 인용구가 언급했듯이, 위키북은 다음과 같다.Wikibooks:위키주니오르가 무엇인가?하지만 당신의 프로포머와 관련하여, 나는 이것이 정말로 이 문제를 논의하기 위한 적절한 포럼인지 궁금하다.비키디아의 영문 버전을 제안하는 것 같지만 비키디아는 WMF 프로젝트가 아니다… --필로소퍼 22:04, 2011년 10월 20일 (UTC)[응답]

다시 생각해 보면, 새로운 WMF 프로젝트를 제안하는 경우, 새로운 프로젝트를 위한 메타 m:proposals에 제안의 정확한 장소가 있다. --Philosopher^{Let us reason together.} 22:05, 2011년 10월 20일 (UTC)[응답]

사실, 이 프로젝트는 Wikijunior와 같지 않다.위키지니오르가 아닌 위키백과 같은 프로젝트다.둘째, 네 말이 맞다.올바른 장소는 메타:위키키드.하지만, WMF 프로젝트가 될 것인가 아닐 것인가, 나는 그것에 대해 위키피디아를 말하는 것이 가치 있다고 생각한다.다른 위키나 다른 기업처럼, 그것의 실현은 우선 그것을 떠맡는 소수의 사람들에게 달려있다.그것은 그들에게 전화한 것이다.

그런데, 여기 그 주제에 대한 두 가지 다른 토론이 있다: 2008년 6월과 2010년 7월.

또 다른 생각은 이 프로젯을 어린이의 권리에 관한 협약의 한 조항과 연결시킬 수도 있다는 것이다.

---

제13조

(1) 아동은 표현의 자유를 가질 권리가 있다. 이 권리는 구술이나 인쇄술, 예술의 형식, 또는 아이가 선택한 다른 매체를 통하여 모든 종류의 정보와 사상을 구하거나, 수신하고, 전달할 수 있는 자유를 포함한다.

(2) 이 권리의 행사는 일정한 제한의 대상이 될 수 있으나, 이는 법률에 의해 제공되는 것과 같은 경우에만 필요하며, 다음과 같다.

(a) 타인의 권리 또는 평판을 존중하기 위해, 또는

(b) 국가 안보 또는 공공 질서(질서) 또는 공중 보건 또는 도덕의 보호를 위하여.

---

마지막으로, 이 메시지의 요점은 공공 기물 파손, 검열, 적절한 내용 정의, 아동 동기, 기사 편집 능력 등과 관련된 "잘 될 수 없을 것 같다"는 반대에도 대처하는 것이었다.그것은 적어도 두 개의 언어에서 잘 작동하기 때문에, 위키를 향상시키기 위해 함께 일하는 어린이, 십대, 그리고 어른들이 있다.그리고 매일 수천 명의 독자들이 있다.

인사말, Astifyes (대화) 00:59, 2011년 10월 21일 (UTC)[응답]

만약 당신이 간단한 프랑스어로 된 위키피디아를 원한다면, 당신은 코멘트 요청에서 투표해야 한다.이건 거의 매년 하는 제안이야.~~에베123~ (+) • 10:52, 2011년 10월 21일 (UTC)[응답]

나는 단순한 프랑스어로 된 위키백과를 원하지 않는다. 왜냐하면: - 나는 아이들을 위해 고안된 위키백과가 단순한 언어로 쓰여지는 것을 목표로 하는 것보다 더 현명한 특징이라고 생각한다 - 왜냐하면 그들의 범위가 꽤 많이 교차할 것이기 때문이다 - 그리고 마침내 비키디아가 모두 이미 존재하기 때문이다.

요점은 영어와 다른 언어로 된 어린이들을 위한 백과사전 위키 를 출시할 것을 제안하는 것이다.2011년 10월 21일(UTC) 15:17(대화)[응답]

짐보의 토크 페이지에서 이것에 대한 논의가 있었을 뿐이다.우리는 이미 어린이 영어 위키피디아를 가지고 있다는 지적을 받았다.위키백과 CD 선택.온라인이 아닌 CD에 들어 있어 편집이 불가능하다.이것을 온라인에 올리는 것 만이 필요할 것이다.모든 작업이 이미 끝났고 이미 존재하기 때문에 이것은 그리 어렵지 않을 것이다.만약 우리가 이것을 온라인에 올려놓고 그것을 공식적인 위키미디어 제공으로 만들고 싶다면, 그것은 사소한 일일 것이다.그것은 이미 좀 시대에 뒤떨어져서 더욱 그럴 것이지만, 그것은 그렇게 끔찍하지는 않다.만약 우리가 편집 가능하고 업데이트 가능한 프로젝트의 기초를 만들고 싶다면, 조금 더 많은 작업이 필요하지만 처음부터 시작하는 것보다 훨씬 덜 한다.난 아마 이걸 선호할 거야.어디서부터 이런 일이 일어나야 할지 잘 모르겠어. 아마도 언급된 새로운 프로젝트에 대한 위키미디어 제안서나 아니면 짐보와 수, 그리고 우편물 목록에 로비를 하는 것일 수도 있지 않을까?누군가는 기꺼이 이 정치적 일을 해야 한다.내가 힘이 되어주는 동안, 나는 별로 관심이 없고 그래서 나는 아닐 거야.하지만 그것은 할 수 있어야 한다.헤로스트라투스 (대화) 15:29, 2011년 10월 21일 (UTC)[응답]

이 정보를 알려줘서 고마워.나는 여기서 이 토론을 찾았다.사실, 2008/9년 위키피디아 선정은 검색엔진이 없다고 생각하면서, 그 곳에서 온라인에 있다.

위키키드 프로젝트는 편집 가능해야 한다(Wikipedia와 동일한 방법으로 유지 관리)위 내용 참조: "아이는 (...) 정보를 찾고, 받고, 전달할 권리가 있다.위키피디아 선정은 아이들이 쉽게 읽을 수 있도록 기사가 확인되었지만 다시 쓰이지 않기 때문에 기본 내용을 제공하는 데 적합하지 않다고 생각한다.b:에서 콘텐츠를 사용하고 가져오는 것이 가능하다.Wikijunior and Simple: 이 프로젝트에 적합할 때.그렇게 하면 처음부터 훨씬 더 빨리 시작할 수 있을 것이다.2011년 10월 21일, 20시 30분 (토크)[응답]

헨릭의 '페이지뷰 통계'에 대한 공식 위키백과 지원 제안

아직도 헨릭의 페이지뷰 통계'가 제 역할을 못하고 있다는 사실에 비추어 볼 때, 예를 들어, 영의완 기사의 경우: 10월 1일부터 2011년 10월 4일까지, 그리고 지금은 [14일]이 4일이나 표류하고 있다. 이렇게 훌륭한 도구가 공식적인 위키백과 지원을 받지 못하는 것은 슬픈 일이다(그리고 매우 유감스러운 일이다).나로서는 풋내기 기고자로서 매일매일 '나의' 기사에 대한 히트곡의 진화를 따라갈 수 있는 것이 필수적이다.그것은 또한 많은 다른 기여자들에게 매우 인기가 있는 것 같다.

그래서 나는 누군가 '위쪽'이 이 도구를 보고 그것을 공식적인 위키백과 기능으로 만들 것을 간청하는데, 이것은 정기적으로 유지될 것이다.이 도구에 대한 위키피디아의 정책 및 계획이 무엇인지 조언하십시오.

헨릭의 '페이지뷰 통계'에 대한 관심도가 어느 정도인지 정확히 파악하기 위해 여론조사를 하는 것은 아마도 흥미로울 것이다.

나는 이 포럼이 위키백과 포럼의 범주에 이 탄원을 위한 적절한 장소였으면 한다.[주소 나는 다음과 같이 조언한다: "정확한 장소는 아마도 위키백과일 것이다:마을 펌프 (제안)."-- 오브시딘 소울 07:30, 2011년 10월 4일 (UTC)] 던컨.프랑스 (토크) 01:05, 2011년 10월 14일 (UTC)[응답]

당신이 우리에게 지지하거나 고쳐주길 바라는 이 위대한 일(아직은 확실하지 않다): 그것은 무엇이며 우리가 그것에 대해 어디서 더 알아낼 수 있을까?헨릭이 누구야?에스미렐다는?— JohnFromPinckney (대화) 02:01, 2011년 10월 14일 (UTC)[응답]

도움말 참조:페이지뷰 통계; 도구는 헨릭에 의해 유지된다(토크 · 기여).-- John of Reading (대화) 07:32, 2011년 10월 14일 (UTC)[응답]

확실히 하자면, 이것은 stats.grok.se을 가리키는데, stats.grok.se의 데이터에 의존하는 것으로 보인다. 이 사이트는 현재 다운된 것으로 보인다(Henrik의 도구에 대한 문제점을 설명하는 사이트).[2] [3]에 따르면, 대화할 사람은 미돔(토크 · 기여)으로 불리는 도마스 미투자스라고 한다.

헨릭의 도구는 특히 WP가 잘 사용하고 있다.RFD 및 WP:DYKTATS, 그리고 그것은 모든 역사 페이지에서 연결된다.그러한 도구를 잘 작동시키는 것은 상당히 중요하다.— 이것, 저것, 그리고 다른 (대화) 09:21, 2011년 10월 14일 (UTC)[응답]

한때 페이지뷰 통계를 이용할 수 있게 하는 것에 반대하는 미신이 있었다(나는 사람들이 통계를 늘리기 위해 일부러 페이지를 때릴지도 모른다는 두려움이 있었다고 생각한다).그러나 지금 우리는 어쨌든 외부 도구를 가지고 있고, 사람들은 그것이 유용하다고 생각하는데, 그것은 악용으로 이어지지 않는 것 같다, 아마도 개발자들은 그러한 정보를 온위키에서 이용할 수 있도록 설득할 것이다(그래서 외부 사이트의 업에 의존하지 않는다).--코트니스키 (토크) 10:14, 2011년 10월 14일 (UTC)[응답]

페이지 보기 통계는 모든 페이지 기록의 링크에서 이미 사용할 수 있다.그것은 완벽하게 작동하고, 매우 빠르고, 어떤 일에는 없어서는 안 된다.쿠드풍 กุผึ ( ((대화) 10:18, 2011년 10월 14일 (UTC)[응답]

문제는, 좀 간헐적이라는 거야.— 이것, 저것, 그리고 다른 (대화) 11:03, 2011년 10월 14일 (UTC)[응답]

헨릭의 페이지뷰 도구는 훌륭하지만 가끔 내려간다.헨릭이 바쁘거나 시내를 벗어나면 공구가 일주일 동안 다운될 수 있다.이 도구는 한 명 이상의 자원자가 지원해야 한다. -- SWTPC6800 (대화) 02:21, 2011년 10월 15일 (UTC)[응답]

만약 그렇다면, 그렇다.쿠드풍 กุผึ ( ((대화) 06:04, 2011년 10월 15일 (UTC)[응답]

이 모든 데이터 수집이 한 명의 리투아니아 데이터베이스 엔지니어(도마스 미투자스) 덕분이라고 생각하면 좀 우울하다.리투아니아의 서버가 다운되면 이러한 도구들 중 어떤 것도 작동하지 않을 것이다.그리고 현실을 직시하자, 재단이 곧 도움이 될 것 같지는 않다.어쩌면 그들은 그것을 잠재적으로 벌레 통조림을 여는 것으로 볼 수도 있고, 외부에서 조작할 수 있는 "공식적인" 통계는 그들을 비평가들의 쉬운 표적으로 만들 것이다.어떤 해결책이라도 내가 생각하는 자원 봉사자들로부터 나와야 할 것이다.오징어 서버 로그에서 데이터를 분할하여 여러 클라이언트로 보내 각 클라이언트가 기사 공유에 대한 모든 데이터를 수신하도록 하고, p2p 네트워크를 설정하여 원하는 모든 사용자에게 데이터를 배포하여 강력한 백업 시스템, 중복성, 로드 밸런싱...DS 벨기에 ٩(͡๏̯͡)۶ 13:04, 2011년 10월 15일 (UTC)[응답]

원시 통계는 현재 WMF 서버를 통해 제공되고 있기 때문에, 나는 도마스가 더 이상 그의 사이트를 유지할 필요가 없다고 생각한다.그로크는 이주하지 않은 것 같아.옛날에는, 필로틱한 반대 때문에가 아니라, 서버가 로깅에 필요한 부하를 처리할 수 없었기 때문에 페이지 뷰 통계는 없었다.이것은 내가 정확히 기억한다면, 기본적으로 로그만 하는 다른 서버의 히트를 잡아내는 "버그"를 내장함으로써 해결되었다.Rich Farmbrough, 17:45, 2011년 10월 16일 (UTC)
[답글]

쿠드풍 กุดผึ้ง(talk)의 ''' 관측에 대해, 나는 그가 http://stats.grok.se/en/201110/Yeung%20Kui-wan를 볼 것을 권한다.현재(2011년 17월 10일)에 따르면, 2011년 7월 10일 이후에는 데이터가...영의완 기사에!!자, 그게 어떻게 "완벽하게" 작동하는 거지?제발, 제발, 누군가가 이 매우 유용한 (그리고 인기 있는) '서비스'를 지지해 줄 수 있을까?던칸.프랑스 (대화) 10:37, 2011년 10월 17일 (UTC)[응답]

그것은 현재 2011년 16/10일까지의 데이터를 보여준다.도마스 서버는 오늘(음, 어제, 5시간 전) 잠시 깨어있었지만 2시 40분 전에 응답을 멈췄다.헨릭스의 사이트가 보이는 데이터를 다운로드 할 수 있을 만큼 충분히 길다.DS 벨기에(대화) 01:57, 2011년 10월 18일 (UTC)[응답]

"아마존 AWS 서비스를 사용하여 나는 "Wikipedia Traffic Statistics" 데이터를 무료로 이용할 수 있다는 것을 발견했다." 라고 그가 말했다.이 http://aws.amazon.com/search?_encoding=UTF8&searchQuery=Wikipedia을 찾았는데 아직도 출처를 찾을 수가 없어!!젠장!뭔가 명백한 걸 놓친 것 같아오전 4시 8분, 자는 시간 DS 벨기에 (대화) 02시 10분, 2011년 10월 18일 (UTC)[응답]

단지 관심에서, 사람들은 이것이 제 역할을 하고 있지 않다는 것을 어떻게 알 수 있을까?기사 이력으로 가면 '페이지뷰 통계'를 클릭할 수 있다고 생각했다.가끔은 조금 느릴 수도 있다고 장담하지만, '수집 수정'을 클릭할 때 그렇듯이, 이것을 나타낼 템플릿이 없을 수도 있을까?ACEOREVIVEED (토크) 15:58, 2011년 10월 20일 (UTC)[응답]

음, 아직 말번에서 완벽하게 작동하고 있어._Worcestershire는 내가 쓴 GA이기 때문에 많이 사용하고 있어.ToolServer에서 호스팅할 수 없는 이유

이 전화에 하나 더 보태고 싶을 뿐이야.페이지뷰 데이터는 연구와 사람들에게 위키피디아가 얼마나 중요한지 설명하는데 매우 중요하다.그것은 편집자들을 모집하고 유지하기 위한 중요한 데이터 포인트인데, 그것은 편집자들의 업무가 중요하다는 아주 긍정적인 피드백을 주기 때문이다.Henrik의 도구든 다른 도구든 페이지 보기 데이터에 대한 액세스를 지원하십시오.벤자민 굿 (토크) 22:57, 2011년 10월 20일 (UTC)[응답]

헨릭의 페이지뷰 통계가 제 역할을 하고 있는지 아닌지를 어떻게 알 수 있는지에 대한 ACEOREVIVE의 질문에 나는 '나의' 기사 '영규완'과 그 리디렉션 '양큐윤'의 히트곡을 계속 기록하고 있다.나는 다음과 같은 이상 현상을 관찰했다.

1) 주기적으로 며칠간의 데이터를 다른 일 세트로 '점프'한다.이는 '서버가 다운'(?)될 때 발생한다.'서버가 다시 온라인 상태가 되면'(say) 데이터 세트는 정확한 날짜로 이동한다.

2) 두 글 모두 0안타를 보이는 날이 있다.놀랍게도 이러한 '제로히트'의 날은 하루씩 중단된다.

3) '내' 두 기사에 대한 데이터의 마지막 날은 항상 하루 [리디렉션은 하루 늦는다]에 의해 설정되지 않는다.나는 이것이 오류인지 아닌지 확신할 수 없다.

그게 확실하길 바래...내가 설명하려는 효과는 매우 실망스럽다고만 말해두자.

위키백과 서열에서 위쪽에 있는 권력자들이 이 서비스를 그들의 휘하에 둘 수 있게 해줘.이것은 바라건대 그러한 변칙들을 예방할 수 있을 것이다.

그런 말을 했으니, 때론 그렇듯 좌절하는 헨릭의 서비스는 전혀 히트 통계가 없는 것보다는 더 낫다.던칸.프랑스 (대화) 03:59, 2011년 10월 23일 (UTC)[응답]

딸 페이지

나는 다른 페이지로 "보조 정보" 페이지를 갖고 싶지만, 그 지침이 무엇인지 잘 모르겠다.사용자 페이지처럼 "main_page/extra_page" 트릭을 할 수 있는가? 아니면 내가 독립 페이지를 만들어야 하는가?기본적으로 사용자가 보고 싶어하지 않는 한 숨기고 싶은 큰 클래도그램("가족 나무" 그러나 종을 위한)이 있는 페이지가 있다(테이블 붕괴가 서식을 엉망으로 만든다).고마워 --Qquidonius (대화) 05:03, 2011년 10월 22일 (UTC)[응답]

• 일단 기술 구현에 반대한다.나는 분명히 그것을 분류 목적으로 사용하는 것을 지지하지만, 그것은 너무 많은 혼란을 일으킬 것이다.그러나 소프트웨어/기능의 소프트웨어에 대한 실제 링크가 없는 소프트웨어/기능과 같이 비기술적으로 사용하는 것은 분명히 조직적인 목적에 유용할 수 있기 때문에 적절한 리디렉션으로 보완할 경우 이를 사용하는 것을 약하게 지원한다.그러나 페이지 이동과 같은 다른 많은 것들이 여전히 해결되어야 한다.재스퍼 덩 (대화) 05:09, 2011년 10월 22일 (UTC)[응답]

당신(스퀴도니우스)은 이것을 제안하는 것이 지도요구를 하는 것만큼 많지 않은 것 같다.여기가 사실 내가 생각하기에 적절한 장소는 아니다(하지만 (기사 토크 페이지 이외에는) 맞는 곳이 어디일지는 모르겠다; 어쩌면 헬프데스크일까?)그러나 당신의 문제를 해결할 수 있는 가능성은 스크롤링 디브에 클래도그램(나중에 그 단어를 찾아봐야 함)을 포함하는 것이다.그렇게 하면 각각 몇 줄만 차지할 수 있지만 페이지를 떠나지 않고도 충분히 볼 수 있다.여기에 더하여 (수평으로 멀리 퍼지지 않기 때문에) 다른 사람 옆에 상주할 수 있으므로 페이지 전체를 줄인다. -- fg 06^TC:21, 2011년 10월 22일 (UTC)[응답]

여기에 예를 하나 들자면 fg^TC 06:33, 2011년 10월 22일 (UTC)[응답]

확인해줘서 고마워!하지만 좋은 생각이다. 문제는 공간뿐 아니라 페이지당 템플릿 수에도 한계가 있고 박테리아 필라가 그것을 넘어섰다는 것이다.따라서 이름/하위 이름 옵션이 기술적 문제를 일으킬 수 있는 것보다, 각 트리에 대해 정상적인 기사를 만드는 것이 유일한 선택이라고 생각한다... --Squidonius (토크) 07:25, 2011년 10월 22일 (UTC)[응답]

아 그렇구나.행운을 빌어. -- fg^TC 18:42, 2011년 10월 22일 (UTC)[응답]

메인 스페이스에서는 하위 페이지가 비활성화되므로 Foo/Data 페이지를 작성하면 해당 제목의 별도 기사가 제공된다.wp:화학은 수년간 보충 정보 페이지를 사용해 왔다:메탄올(데이터 페이지), 아르신(데이터 페이지), 트립토판(데이터 페이지)요에닛 (대화) 08:04, 2011년 10월 22일 (UTC)[응답]

{{SWL} 템플릿 사용 확대

당사(사용자:플라이오트로프, 사용자:i9606)는 기사 공간에서 {{SWL} 템플릿의 사용을 확대할 것을 생각하고 있으며, 커뮤니티의 의견을 듣고자 한다.기본적으로 {{SWL} 템플릿은 편집자가 기사 공간 내에서 의미 정보를 인코딩할 수 있도록 한다.의미적 정보는 나중에 추출되어 여러 가지 다른 방법으로 사용될 수 있는 HTML에 숨겨진 관계를 기계 판독이 가능한 표현으로 귀결된다.

예를 들어, SWL 템플릿은 동물의 속성을 인코딩하는 데 사용될 수 있다.점박이올빼미를 예로 들면서, 우리는 다음 문장을 바꿔서 그것의 야행성 행동을 인코딩할 수 있다.

작은 포유류와 새를 잡아먹고 사는 엄밀한 [야행] [새]이다. 

다음 항목으로:

{{SWL형=행동대상=야행성=야행성(야행성)}} [[새]]]이 엄밀히 말해 작은 포유류와 새를 잡아먹고 산다. 

{{SWL}} 덧셈이 위키링크에 희미한 오렌지색 밑줄을 더하는 것을 제외하면 두 렌더링은 사용자가 위키링크 위를 맴돌 경우 관계를 설명하는 툴팁을 보여준다.실제로, {{SWL} 템플릿은 점박이올빼미의 기본 속성을 인코딩하기 위해 기사에 걸쳐 선택적으로 사용되며, 우리는 이 템플릿을 현명하고 제한적으로 사용하는 것이 마크업 잡음을 방지하는 데 이상적이라고 생각한다.

우리는 또한 이러한 관계의 유용성을 보여주는 사용자 설명서도 개발했다.이 스크립트는 기사에 SWL 템플릿을 구문 분석하여 메시지가 표시되면 이를 강조 표시하고 각 관계와 대상을 설명하는 infobox를 표시한다.이를 통해 빠르고 간결한 주제 이해가 가능하다. 예를 들어, 이 점박이올빼미 샌드박스 사본(SWL 템플릿 추가)에서 인포박스는 점박이올빼미가 야행성이며 일부일처제로 짝짓기하며 북아메리카에 산다는 것을 사용자에게 분명히 알려준다.사용자 설명서는 테스트해보고 싶다면 여기서 사용할 수 있으며, 사용자 설명서의 스크린샷은 아래(인포박스는 부엉이 인포박스 위에 있음)를 참조하십시오.

우리는 지역사회가 이 개념에 대해 가지고 있는 어떤 피드백이나 생각이라도 감사할 것이다. 좀 더 공식적으로 논의할 가치가 있는 것이라면 RfC로 만들 수도 있다. 하지만 이 시점에서 그것은 약간 관련이 있는 것 같다.생각? -- Pleiotrop (대화) 23:38, 2011년 10월 18일 (UTC)[응답]

이것이 infobox에 통합되지 않은 이유가 있는가? --Philosopher^{Let us reason together.} 19:39, 2011년 10월 19일 (UTC)[응답]

독자의 관점에서, 이 사용자 설명서는 각각의 주장된 사실에 대한 맥락을 제공한다.또한 관련 infobox에 존재하지 않는 새로운 필드(아마도 너무 구체적이기 때문에)를 추가할 수 있다.또한 사용자가 부정확하다고 판단될 경우 관계를 명확히 할 수 있다. 예를 들어 "행동 = 야행성"은 "능동_주기 = 야행성" 또는 이와 유사한 것으로 더 잘 표현될 수 있으며, 이는 일상적인 편집자가 신속하게 해결할 수 있다.게다가, 인포박스는 그들 대상의 "최소 평민 혐오자"가 되는 경향이 있다.예를 들어 올빼미에게만 적용될 수 있는 속성에 대해 조건부 필드를 infobox에 지속적으로 추가함으로써, infobox의 유지관리성은 한계효익에 대해서만 감소한다.동의하십니까? --Pleiotrop (대화) 21:09, 2011년 10월 19일 (UTC)[응답]

캐주얼 에디터는 앞도 뒤도 제대로 못 만들고 기사만 업데이트해 ncturnality로 정확하게 연결시키려 하기 때문에 템플릿 전체를 벗길 가능성이 높다. --Carnildo (토크) 02:03, 2011년 10월 20일 (UTC)[응답]

현재의 infobox 방법을 대체할 의미론적 코딩의 약속은 훨씬 더 큰 유연성과 재사용 가능성이다. 나는 즉각적인 적용이 다른 형식으로 기사를 다시 쓰고 재결합하는 능력일 것이라고 생각한다(예를 들어, 우리가 작은 기사를 정당화할 수 있는지 또는 그것들을 결합할 필요가 있는지에 대한 지속적인 AfD 분쟁 해결, b).y는 어느 방식으로든 표시를 허용했다), 그리고 범주의 교차점에 대한 근거를 제공함으로써 발견성을 향상시켰다. 장기적으로는 일상적인 물품에 대한 박스 접근방식을 채울 것으로 예상한다.아마 캐주얼 에디터는 준비가 안 된 것 같지만, 캐주얼 에디터도 기사를 제대로 정리할 수 있는 것은 아니다.어느 한쪽의 권리를 행사하는 것은 규율과 조직을 필요로 한다. DGG (토크 ) 04:32, 2011년 10월 20일 (UTC)[응답]

필자는 전문가와는 거리가 멀지만(사실 나는 이 제안을 보고/읽으면서 이 아이디어를 접하게 되었다) 스크립트가 페이지를 보다 효과적으로 사용할 수 있는 방식으로 데이터를 내장하는 데는 큰 가치가 있다고 확신한다.나는 이 템플릿의 사용을 형성하기 위해 고안된 표준/구축된 표준을 보고 싶다.표준 양식이 없다면 이 템플릿은 스크립트가 내장된 데이터를 읽는 것보다 스크립트가 포함된 데이터를 읽는 것이 더 나을 수 없을 정도로 다양한 방법으로 사용될 수 있다.OP의 예에서 우리는 각각의 목표가 있는 3가지 유형을 볼 수 있다. type=behaviour모두 양호하지만, 동작이 스크립트가 사용하고자 하는 인식된 용어인 경우에만 해당된다.모든 범주의 경우:새들은 내재된 데이터를 쉽게 사용할 수 있고 따라서 (더 유용하게) 예상된 유형으로서 의미론적 행동을 가지고 있었다.나는 아마도 올바른 용어를 사용하고 있지 않지만 내 뜻이 충분히 명확하기를 바란다.다른 어떤 것도 나에게 타이핑 연습을 시켜주지 않았다.본질적으로 내가 말하고 있는 것은 무작위 데이터 수집은 사람이 읽을 수 있는 페이지만큼 체계적이지 않기 때문에 이 데이터를 기계에 의해 사용되려면, 조직화되지 않은 형태로 너무 멀리 퍼지기 전에 가능한 한 조직화된 것으로 하는 것이 최선일 것이다. --fg^TC 05:26, 2011년 10월 20일 (UTC)[응답]

내가 당신을 정확히 이해한다면, 당신이 SWL 템플릿의 사용을 표준화하는 데 사용될 관계 유형의 온톨로지 개발을 제안하는 것처럼 들린다.나는 이것이 정말로 의미적 연결의 가치를 증가시킬 수 있는 칭찬할 만한 목표라고 생각한다. 중요한 문제는 우리가 그것을 어떻게 달성하느냐이다.이 온톨로지 구축에 대한 적극적인 시도와 그 이후 적용에 대한 일종의 시행을 지지하는 것처럼 들린다. (내가 틀렸으면 정정해!)내 생각에 관계유형은 기사가 하는 것과 같은 방식으로 유기적으로 그들의 사용으로부터 생겨나야 한다.누군가는 대담하게 하나를 창조하고, 다른 사람들은 동의하지 않고 변화를 만들고, 대부분의 경우 결국 안정된 공감대가 형성된다.또한, 합의와 일관성이 없는 다작의 SWL을 암시하는 최악의 시나리오에서, 나는 여전히 데이터가 일반 텍스트보다 스크립트에 더 유용할 것이라고 생각한다.플라이오트로프의 예를 보면, 나는 개인적으로 부엉이를 "야행성"과 연결시키기 위해 "행동"이 아닌 다른 속성을 사용하는 것을 선호하고 싶지만, 그럼에도 불구하고 이 느슨한 의미적 연결의 존재는 여전히 가치가 있다.스크립트가 이를 추출하여 올바르게 표시했다.나는 기본적인 아이디어를 얻었고, 내가 그것을 보았기 때문에, 나는 그곳에 들어가서 SWL을 나에게 더 이치에 맞는 것으로 바꿀 가능성이 훨씬 더 높다.벤자민 굿 (토크) 18:09, 2011년 10월 20일 (UTC)[응답]

그래 "온톨로지"는 매우 좋은 말이다.알았으면 썼을 텐데."유기농 온톨로지"는 흥미로운 구글 검색을 만든다.우리는 파도 소리를 따라 노를 젓고 있는 것 같다.우리는 우리 밑에 서있으려고 할까 아니면 그냥 내버려 두려고 할까?나는 공유할 링크를 몇 개 잡았다.나는 각각의 주소를 방문했고 어떤 주소에서도 악의를 나타내는 것을 본 적이 없다(바이러스 등이 걱정된다.

• http://bricobase.com/organic.shtml
• http://fractalontology.wordpress.com/category/parasite
• http://www.duo.uio.no/sok/work.html?WORKID=58292&lang=en

만약 의미 데이터가 자바스크립트 또는 JSON "객체"와 유사한 어떤 것으로 보유된다면, 우리는 우리의 객체가 효과적으로 무제한이라는 자유를 가지고 표준화의 길을 조종하는 기본 규칙들을 가질 것이다.이 개념은 트리가 모든 의미 데이터가 단단한 줄기에서 생성될 수 있는 잔가지들을 허용하기 때문에 허용될 것이다. (뿌리는 소리가 더 좋지만 유추에는 그다지 좋지 않다.)비록 우리 인간은 유별나게 적응할 수 있지만, 기계/스크립트는 그렇지 않다.의미론적 데이터의 가장 좋은 사용은 기계 읽기 데이터로서 우리는 스크립트의 필요성에 대해 고려할 필요가 있다.예측 가능한 구조를 원한다.JSON 파서는 특정 규칙을 따르기 때문에 JSON 파서가 던지는 JSON 개체를 다룬다.읽는 물체는 무엇이든 담을 수 있지만 대본을 뒤엎지는 않을 것이다.유기적(제한되지 않고 적응 가능한) 온톨로지(공유 개념화의 공식적이고 명시적인 사양)가 있다.나는 우리가 대담해져야 한다고 생각한다.이 황소를 뿔로 잡고 길들여라. -- fg^TC 22:08, 2011년 10월 20일 (UTC)[응답하라]

그래서, 내가 여기서 당신의 요점을 확실히 하기 위해서 - 당신은 우리가 말하고 있는 온톨로지가 링크에서 제공하는 예들이 가능하게 하는 것처럼 유기적으로 발전할 수 있고, 또 그래야 한다고 말하고 있다, 그렇지?또한 스크립트의 필요성에 대해서도.SWL 템플릿은 현재 기계 판독 가능한 HTML을 방출하고 있으며, 이미 이를 처리하는 몇 개의 프로토타입 스크립트가 있다.일관되고 구문 분석 가능한 구조(즉, 'syntax')를 가지고 있다.유일한 과제는 암호화에 사용되는 관계 유형의 의미 또는 의미론을 명확히 하는 것이다.현재 관계 유형은 범주(상위 SWL 범주의 하위 페이지)로 표현된다.이것이 공동체가 관계 유형의 유용한 존재론을 진화시키기 위해 노력할 수 있는 부분이다.벤자민 굿 (토크) 22:50, 2011년 10월 20일 (UTC)[응답]

맞아, 데이터 자체가 아니라 표준화가 필요하다고 생각하는 것은 내장 데이터의 스타일이야.JSON 객체 예는 내가 생각할 수 있는 실제 사례에 가깝다.스크립트가 순서만 보는 동안 작성자의 자유 허용.스크립트가 템플릿을 읽을 수 있다는 것은 문제가 되지 않는다. 그것은 그것으로부터 얻는 것이 더 중요하다.A페이지의 고양이:대본은 완벽하게 합리적인 데이터를 얻고 B페이지의 고양이:a 또한 완벽하게 합리적인 데이터를 얻는다.만약 그것이 고양이의 모든 페이지의 데이터를 사용하여 테이블을 구성하려고 한다면:a 그것은 치명적인 문제에 부딪힌다.그 데이터 유형은 뚜렷한 상관관계가 없다.인간으로서 우리는 우리가 발견한 것을 해석하고 그 공백을 메우는 데 익숙하다.우리는 우리가 적합하다고 생각하는 대로 편집하고 바꿀 수 있다.스크립트는 (극히 복잡하고 방대한 것이 아니라면) 할 수 없기 때문에 모든 고양이로부터 완벽하게 합리적인 데이터:한 페이지가 거의 무용지물이 된다.그러나 모든 cat:page가 지정된 객체 구조를 가지고 있다면 스크립트는 해당 범주의 어떤 페이지로부터 데이터를 끌어다 놓고 딸꾹질 없이 쓰여진 방법으로 사용할 수 있다.범주형 구조의 아이디어가 (A(a)(b)(c))와 같은 모든 범주를 포괄하기 위해 바깥쪽으로 이동되었다면, 우리는 모든 범주에 걸쳐 대본을 위한 안전한 작업 환경을 가지고 있지만, 각 고양이들은 그것 자체의 기발함과 각 페이지를 가질 수 있다.내가 이걸 잘못 설명하고 있는 것 같아.내가 주제를 너무 잘못 이해해서 내 의견 역시 가치가 거의 없다. 나는 기회가 존재하지만 적어도 그 템플릿을 보기 쉬운 미래에 대한 안목을 가지고 사용자에게 친숙하고 대본에 친숙하게 만드는 몇몇 가이드들을 내려놓는 것이 좋을 것이라고 생각하고 있다.우리의 현대적 시스템 중 너무 많은 것들이 너무 깊이 내재되어 있어서 우리는 그들의 지속적인 사용에 갇히게 될 만큼 오래된 생각에 의존하고 있다.웹의 의미론적 데이터에는 큰 가치가 있는 것 같고, 조직화되면 좋을 텐데...내 생각이 거꾸로 나오고 있다.올빼미:타입=행동 대상=야행성;참새:type=color target=갈색;결과=관련되지 않은/유용한 데이터의 표를 수집한다.추가 옵션 및 중첩 옵션.만약 우리가 도구를 갖게 된다면, 그것이 딱딱하고 날카롭게 찌르지 않도록 가능한 한 좋은지 확인하자! --fg^TC 23:37, 2011년 10월 20일 (UTC)[응답]

좋아, 여기서 저작/뷰 도구와 표현을 분리하는 것이 중요하다고 생각해.의미적 연계가 만들어지고 있을 때 사용할 관계형태를 제시함으로써 편집자 SWLs를 일관성 있게 도울 수 있는 도구가 있다면 매우 유용할 것이라고 생각한다.현재 대표성을 감안할 때 이것은 완전히 달성할 수 있는 것이며 나는 기꺼이 그 일을 도울 것이다.벤자민 굿 (토크) 00:02, 2011년 10월 21일 (UTC)[응답]

자, 아주 좋은 생각이야! -- fg^TC 00:00, 2011년 10월 21일 (UTC)[응답하라]

나는 Benjamin의 말에 동의한다. 온톨로지는 공동체 자체에서 나와야 하고, 사용자들에게 무언가를 쉽게 하기 위한 제안도 제공되어야 한다.그러나 이 온톨로지(Ontology)는 처음부터 공허할 것인가.나는 처음에 공통적인 관계가 추가되어 진화할 수 있다고 생각한다.다른 온톨로지로부터 오는 관계를 이용하는 것은 어떨까?skos:브로드밴더 및 skos:narrower를 예로 들자면 -- ljgarciac 17:43, 2011년 10월 23일(GMT)

이 생각에는 몇 가지 문제가 있다.우선 어려운 부분은 일부 자료에서 '가짜' 인포박스를 만드는 대본을 만들지 않는 것이다.어려운 부분은 합리적인 데이터 구조를 만들어 내는 것이다.그리고 이 경우 그것은 행해지지 않았다.당신은 "유형=행동 대상=야행성"을 가지고 있다.지금 당신이 제안하는 "type=active_period target=noctional"은 다른 사람이 "type=is_nocty target=yes", "type=is_nocty target=1" 등으로 표시할 것이다.또한 누군가는 "포니"의 앞부분에 있는 문장 같은 것을 취하게 될 것이다. "조랑말은 고집이 세거나 교활하다고도 하지만 일반적으로 지적인 것으로 간주된다." "형=행동 대상=지적인" "형=행동 대상=친근한" "형=행동 대상=스튜본" "형=행동 대상=스튜본"과 "형=행동 대상=커닝"을 짝짓게 된다.결과는 완전히 엉망이 될 것이다 - 그러한 데이터를 이해할 수 있는 어떤 프로그램도 아마도 기사 자체에 더 많은 의미를 부여할 것이다.더욱이, 그러한 방법으로 우리는 정보를 잃게 된다: 기사에서 "유형=행동 대상=지능적"인 "유형=행동 대상=친밀"은 "일반적으로 고려된다"로 자격을 얻은 반면, "유형=행동 대상=스텁본"과 "유형=행동 대상=커닝" - "유형=행동 대상=커닝"은 "때로는 설명될 때도 있다.우리는 "가짜" 인포박스에서 그러한 자격을 상실한다.

혼란스러운 구문에 관한 또 다른 문제가 있지만, 다른 사람들은 이미 그것을 설명했기 때문에, 나는 이 시스템을 컴퓨터에 더 유용하게 만드는 거의 모든 가능한 방법들이 구문을 더욱 혼란스럽게 만들 것이라고 덧붙일 것이다.

그러므로 나는 할 수 있는 한 그것을 거칠게 말할 것이다: 위키피디아에서는 어떤 유사한 것도 실행되어서는 안 된다.각각의 위키미디어 프로젝트는 한 가지와 한 가지 일만 해야 한다 - 하지만 잘 해야 한다.위키피디아는 백과사전이 될 예정이고 다른 것은 아니다.

하지만 위키백과에서는 그와 같은 어떤 것도 허용될 수 없지만, 나는 왜 우리가 다른 위키미디어 프로젝트를 만들어서는 안 되는지 모르겠다. 그것은 단지 그것에만 전념할 것이다.온톨로지(정보과학)를 지칭하는 '위키온톨로지(Wikiontology)'가 아닐까?그럼, m:프로포즈로 가서 새로운 프로젝트를 제안해봐!네, 진짜로.그런 프로젝트를 하고 싶은 사용자들이 충분히 있는 것 같아. --Martynas Patasius (토크) 18:29, 2011년 10월 20일 (UTC)[응답]

친애하는 마티나스에게, 당신의 조랑말 예시에 관한 짧은 메모, 나는 편집자들이 이치에 맞는 링크에 템플릿을 추가하는 것만을 사용할 것을 믿을 것이라고 생각한다.현재 당신이 강조하는 단어들("지능적", "친근한", "스튜버본", "커닝")은 모두 위키링크가 되어 있지 않기 때문에 개인적으로 나는 아무도 SWL 템플릿을 거기에 추가하지 않을 것이라고 생각한다.반면 SWL({SWL type=type=type=type=type=hors})을 이용해 위키링크를 '말'로 명확히 하는 사람이 보였다.그렇게 되면 사용자는 말의 종류인 동물 목록을 쉽게 만들 수 있게 되어, 예를 들어 말이 먹는 말과 식물을 먹는 동물과 구별하게 된다.건배, AndrewGNF (대화) 2011년 10월 20일 (UTC) 19:26[응답]

어... 그럼, '가짜 인포박스'에 어떤 사실을 집어넣고 싶은 사람은 기사 텍스트에 (이 템플릿을 사용한) 내부 링크를 삽입할 방법을 찾아야 한다는 건가?그리고 그게 대안보다 더 쉬울 거야? --Martynas Patasius (talk) 2011년 10월 21일 (UTC) 20:00[응답]

안녕 마티나스, 나는 아래에서 너의 걱정거리를 다루었다.나는 당신이 사용자들에게 이 템플릿들 중 하나를 실제로 쓸 때 어떤 일이 일어나는지 한번 시도해 보라고 권하고 싶다.플레이오트로프 (대화) 01:40, 2011년 10월 22일 (UTC)[응답]

난 다작 작가 겸 편집자야 그리고 이건 정말 정말 나쁜 생각이라고 생각해캐주얼한 편집자와 경험 많은 편집자들이 편집하는 것을 훨씬 더 어렵게 만들 겁니다.편집화면에서 할 수 있는 파싱이 너무 많다.그렇다면 이 템플릿에 무엇을 넣어야 하는지에 대한 문제가 있다.일부 편집자들은 기사가 작은 오렌지상자로 가득 차도록 거의 모든 것에 그것을 추가할 것이다.어떤 사람들은 행동의 철자를 "행동"으로 표기하여 어떤 대본이 데이터를 구문 분석하는 것을 더 어렵게 만들 것이다.편집이 쉬워질 수 있는 방안을 강구해야 하는데, 이렇게 되면 보고가 쉬워질 수도 있지만(확신할 수 없다) 오히려 편집이 더 어려워질 것이다.카라낙스 (토크) 2011년 10월 20일 (UTC) 18:05 [응답]

바로 위에 있는 카라낙스에 동의해.나는 그 개념이 매우 - 매우! - 흥미롭다고 덧붙이지만, 그 실행은 매우, 매우 나쁜 것 같다.편집은 이미 충분히 어렵다. 우리는 이것을 광고할 필요가 없다.흥미로운 도구를 사용할 사람이 부족하면(적당히) 소용이 없다 - 나블라 (대화) 18:37, 2011년 10월 20일 (UTC)[응답하라]

안녕 카라낙스, 나블라, 조언해줘서 고마워.네 말이 맞아. 이것은 이미 어려운 편집 과정에 어느 정도 복잡성을 더하는 거야.우리의 현재 실행은 개념 증명이고, 우리는 그것을 어떻게 하면 그것을 눈에 띄지 않고 유용하게 만들 수 있는지에 대한 제안을 받기를 바라고 있었다.한 가지 방법은 템플릿을 바꾸는 것이다- 밭과 구문은 어떤 방법으로도 돌로 정해져 있지 않다!나는 또한 이러한 템플릿의 사용을 확립한 지침이 파괴되지 않도록 합의될 수 있다고 생각한다.전례대로 </ref> 시스템은 기사에 복잡한 마크업이라는 큰 블록을 추가하지만, 편집자로서 우리는 그것이 필요하고 유용하기 때문에 그것을 가지고 작업한다.우리의 템플릿이 같은 수준의 중요성은 아니지만, 그것은 또한 거의 복잡하지 않다.마지막으로, 나는 장기적 편익에 대한 단기적 복잡성에는 불합리한 절충이 있다고 생각한다: 그것이 근원을 더 둔감하게 만들기는 하지만, 수동 목록 유지보수와 분류와 같은 훨씬 더 지루한 작업에 가져다 줄 수 있는 편익을 상상해보라.당신은 이것을 당신이 사용할 수 있는 것으로 만들 수 있는 가능한 변화를 생각할 수 있는가?베스트, 플레이오트로프(토크) 19:17, 2011년 10월 20일 (UTC)[응답]

나는 이 개념이 개인 데이터 템플릿과 같은 형식에서 훨씬 더 효과적이라고 생각한다 - 우리는 더 많은 정보를 얻고자 하는 정의된 분야를 가진 정의된 주제(생물학)를 가지고 있다.그런 다음 페이지 하단에 배치되므로 편집 화면을 복잡하게 만들지 않고 스크립트에서 사용할 수 있다.어떤 종류의 키워드를 사용해야 하는지에 대한 엄밀한 정의가 없는 시스템에서는 좋은 결과가 나오지 않는다고 본다.카라낙스 (대화)20:29, 2011년 10월 20일 (UTC)[응답]

동의해. 미리 정의된 온톨로지 없이는 이것이 전혀 쓸모가 없다는 걸 알 수 없어.MalleusFatuorum 20:45, 2011년 10월 20일 (UTC)[응답]

나는 너희 둘 다 어디서 왔는지 이해한다. 하지만 위키피디아가 많은 내용에 대한 어렵고 빠른 정의가 부족하기 때문에 번창하고 있다고 생각한다.예를 들어, 편집자들은 그들이 만든 기사가 이미 존재하지 않고, 위키링크를 만드는 단어들이 그것들을 뒷받침하는 기사를 가지고 있는지 확인해야만 한다(또는 그렇지 않다면, 그들은 그것들을 레드링크가 되어도 괜찮다).사람들이 이 템플릿을 사용하는 가상의 미래 위키피디아에서, 나는 템플릿 매개 변수들에 대해 같은 종류의 연습이 있을 것이라고 생각한다.편집자가 어떤 임의적인 관계를 사용하는 템플릿을 만든다면, 이미 확립된 어떤 것으로든 그것을 바꿀 수 있을 만큼 쉽다.만약 편집자가 어디에나 그것들을 추가한다면, 다른 편집자는 (대담한, 되돌리기, 정책에 대해 토론하기) 부적절한 편집자들을 제거할 수 있다.또한 이 템플릿의 사용이 상당히 보편화되면 특히 특정 위키프로젝트 내에서 선호되는 온톨로지를 설정하는 것을 막을 수 없다.이것은 위키피디아의 대부분의 다른 부분들과 마찬가지로 합의의 문제일 것이다, 그렇지 않은가?--Pleiotrop (대화) 21:11, 2011년 10월 20일 (UTC)[응답]

나는 이와 같은 분야에서 (그리고 많은 다른 일들이 일어나지만 그것은 또 다른 이야기다) 의견 일치를 그리 좋아하는 사람은 아니다.PersonDATA의 카라낙스의 예는 좋은 것이다.말레우스파투룸 21:15, 2011년 10월 20일 (UTC)[응답]

이 문제에 대한 합의 형성을 가능하게 하는 것에 반대하는 이유와, 예를 들어, 기존 시스템에서 범주를 만들고 적용하거나 기사를 명명하는 것과 어떻게 다른지 자세히 설명해 주시겠습니까?벤자민 굿 (토크) 21:31, 2011년 10월 20일 (UTC)[응답]

왜냐하면 메타데이터는 그 의미가 정의되지 않으면 무용지물이 되기 때문이다.(우리는 이미 기사 이름을 붙이는 지침을 가지고 있고, 카테고리는 어차피 거의 신경 쓰지 않는 쓸데없는 방해에 불과하다.)모든 편집자가 자신의 맛을 발명한다면 메타데이터를 내장할 이유가 무엇인가?그것은 마치 모든 사람들이 그들만의 언어를 발명하는 것과 같다.말레우스파투룸 21:50, 2011년 10월 20일 (UTC)[응답]

선의로 만들어지는 한 개별 작성 메타데이터를 활용해 플레이오트로프의 예에서 볼 수 있는 단일 기사를 강화할 수 있다.당신이 제안하는 것처럼, 많은 기사에 걸쳐 메타데이터를 사용할 때, 예를 들어 질의를 기반으로 한 목록(예: 북미의 야행성 동물)을 구성할 때, 표준형식을 기사에 일관되게 사용하는 것이 중요하다.기준서 작성에 접근하는 방법은 여러 가지가 있다.하나는 어떤 힘이 표준을 지시하는 것이다.또 다른 방법은 유기적으로 나타나게 하는 것이다(사용자 FG와의 위의 논의 참조).위키피디아 내에서 나는 후자가 가장 타당하다고 생각한다.벤자민 굿 (토크) 2011년 10월 20일 23시 12분 (UTC)[응답]

이런 맥락에서 선의는 무의미한 바벨탑 건설로 이어지는 것 외에는 아무 상관이 없다.말레우스 파투오름 23:53, 2011년 10월 20일 (UTC)[응답]

나는 또한 이것이 개인 데이터와 같은 Infobox를 대체하려는 의도가 결코 아니라는 것을 명심해야 한다고 생각한다.특정 속성 세트가 많은 페이지에 표시되기를 바라는 확립된 욕구가 있을 때, infobox 템플릿은 훌륭한 메커니즘이며 관련 기사의 해당 SWL을 대체할 수 있다.벤자민 굿 (토크) 21:45, 2011년 10월 20일 (UTC)[응답]

플레이오트로프, 더 많은 전문 템플릿을 추가하는 것은 나쁘고, 현재 상황은 이미 너무 지나쳐 버렸고, 위키 편집은 이미 매우 많은 언위키(빠르지 않고, 우호적이지 않고, '모두에게'가 아니다)가 전문화된 템플릿의 확산으로 인해 사실상 수천 개의 키워드로 위키 마크를 확장하고 있다.만약 그렇다면, 이것은 이미 언급된 개인 데이터처럼 주요 텍스트에 포함되지 않는 것이 좋을 것이다. (그 데이터도 그렇게 좋아 보이지는 않지만, 적어도 일상적인 편집자는 쉽게 무시할 수 있다) 또는 카테고리(어느 정도 비슷한 카테고리가 아닌가?기능을 추가하는 대신 개선할 아이디어 - 결국 카테고리를 대체하는 것은 어떨까?) - 나블라(토크) 22:01, 2011년 10월 20일 (UTC)[응답]

나블라, 나는 템플릿을 더 추가하는 것이 나쁘다는 것에 동의하지 않아.템플릿은 위키백과 기사의 복잡성을 통제하는 일반적인 방법이다.나는 새로운 템플릿들이 나쁜 영향 없이 페이지에서 만들어지고 사용되는 것을 보았다- 나는 경험이 부족한 편집자들이 그것들을 그냥 무시한다는 가설을 세웠다.

한 가지 짚고 싶은 점은 우리가 예측에 대해 주로 논의해왔다는 점이다. 이러한 템플릿은 확립된 온톨로지 없이는 쓸모없을 것이고, 텍스트 출처를 너무 복잡하게 만들고 편집자들을 낙담시킬 것이라는 것이다.당신의 (그리고 말레우스와 카라낙스의) 예약은 전적으로 타당하지만, 우리가 실제로 각각의 예측을 시험해야 한다고 생각하지 않으세요?이런 걱정들이 그냥 지나가지 않을 가능성이 충분히 있다.만약 이것이 효과가 있다면, 우리는 여기서 우리가 만든 엄청난 양의 정보를 분류하고 주석을 달 수 있는 귀중한 도구를 만들기 시작했다.그렇지 않으면, 템플릿은 점차 제거되고 해를 입히지 않는다.이 백과사전은 섬세한 양피지로 만들어진 것이 아니라, 우리는 혁신과 실험을 할 수 있고 또 해야 한다.

선택된 페이지 그룹에서 이러한 템플릿에 대한 작고 제한적인 테스트에 전적으로 반대하십니까?그런 다음 편집자들의 라이브 기사로 어떻게 수신되는지 보고 예측 자료를 얻을 수 있었다. --Pleiotrop (talk) 23:46, 2011년 10월 20일 (UTC)[응답]

확립된 온톨로지 없이는 그것은 예측이라기 보다는 기정사실이다.말레우스 파투오름 23:56, 2011년 10월 20일 (UTC)[응답]

그래, 나는 이 템플릿들에 대한 작고 제한적인 테스트에 반대한다.이런 것들이 유용할 것이라는 데 의견 일치가 없고 우려를 불식시킬 방법도 없다.나는 컴퓨터 프로그래머다. 내 직업의 상당 부분은 사람들이 데이터를 입력하고 보고할 수 있도록 하는 것이다.내가 신입 사원 모두에게 가르치는 첫 번째 교훈은 어떤 프로젝트에 대해 정의해야 할 가장 중요한 요건 중 하나가 "어떤 유형의 보고가 필요할 것인가?"라는 것이다.그것에 대한 구체적인 설명이 없다면, 당신이 디자인하는 것은 결국 실패할 것이다. 왜냐하면 만약 계획이 사전에 이루어지지 않는다면, 그것은 결국 당신이 원하는 보고서를 얻는 것이 불가능하기 때문이다.우리가 수집하고자 하는 메타데이터의 유형을 미리 알지 못한다면, 도대체 메타데이터가 어떻게 유용할 수 있을까?그것이 무엇에 쓰이고 있는지 모른다면 왜 기사에 넣고 싶은가.누구에게도 유용한지 모르는데 왜 편집 화면을 어지럽히고 편집이 지금보다 더 어렵게 만드는 것일까.이런 일에는 효과를 측정하는 방법이 있을 텐데, 아직 보이지 않는다.카라낙스 (토크) 2011년 10월 21일 (UTC) 14:40[응답]

하이퍼링크의 효과를 어떻게 측정하시겠습니까?벤자민 굿 (토크) 2011년 10월 21일 17시 10분 (UTC)[응답]

나는 이 템플릿들의 뚜렷한 목적이 보이지 않는다.우리는 몇 년 동안 PersonDATA를 사용해 왔다. 어떤 프로그램이 실제로 그 데이터를 사용하는가?나는 그것이 어디에서도 사용되는 것을 눈치채지 못한 것 같아.위치정보의 지리 좌표 데이터를 이용하는 프로그램이 있는가?명확한 스케줄 없이 어디에서나 사용할 수 있는 일반적인 메타데이터 클래스의 아이디어는 실패할 운명(그리고 도중에 많은 편집자를 저지할 예정)이다."제한된 테스트"를 시작하기 전에 사용 사례의 구체적인 예부터 시작하겠다.그렇지 않으면 우리는 무엇이 시험되고 있는지 알 수 없다.

예를 들어 조랑말 케이스는 내게 가치가 없어 보인다.어떤 관계가 행동에 기반한다는 것은 무엇을 의미하는가?어떤 프로그램이 그런 정보를 "내게" 하겠어?자연 언어와 섞는 것보다 다른 사이트에 동물 특성에 대한 데이터베이스를 두는 것이 어떻게 더 좋을까?그리고 다른 사람들이 지적했듯이, 당신은 모든 종류의 예선전을 잃고 있다.아마도 사람들은 이 꼬리표들을 아주 미묘함을 거의 고려하지 않고 일괄적으로 붙일 것이다.나쁜 정보는 정보가 없는 것보다 더 나쁘다.다른 예로는 한 기사가 다른 기사의 자본이라는 것이다; 두 기사는 이미 인포박스에서 서로 연결되지 않을까?그리고, 다시 말하지만, 이 정보를 찾는 사람은 영어 기사보다는 공공 데이터베이스로 눈을 돌리지 않을까?—지정 (대화) 2011년 10월 21일 20:15 (UTC)[응답]

안녕 지정, 그래, 실제로 위키백과에 메타데이터를 사용하는 정말 유용한 도구들이 많이 있다- freebase.com과 dbpedia.org을 확인해봐.그러나 이것들은 기존의 구조화된 콘텐츠에 한정되어 있기 때문에 파싱에 한계가 있다.문맥상, 나는 이 일반적인 메타데이터의 사용이 나쁜 정보가 아닌 "소음" 정보를 만든다는 것을 증명할 수 있다.시끄러운 정보는 쉽게 여과되고 청소될 수 있다.이러한 템플릿의 사용 사례에 한해서, 나는 편집자가 어떻게 기사에 있는 유용한 정보의 빠른 요약을 만들 수 있는지 보여주려고 시도하고 있었는데, 이 요약을 사용하여 페이지를 분류하거나, 기사의 infobox에 있는 추가 분야의 후보자들을 제공하거나, 또는 최소한 요점을 강조할 수 있다.내 예가 최고는 아니었을지 모르지만 상상력을 발휘한다면 더 나은 것을 상상할 수 있을 것이다.나는 위에서 사람들이 이 템플릿을 추가하는 문제를 일괄적으로 다루었다; 내 요점은 사람들이 WP의 다른 어떤 작업에서와 같은 자제력을 보여야 하고 적절한 "태깅" 정책이 합의될 수 있다는 것이었다.종종 생각되는 요점에 대해, 그것이 일상적인 편집자들을 단념시킬 것이라는 것에 대해서, 나는 이것에 대한 어떤 증거도 보지 못했고 그것이 일상적인 편집자의 지능의 불공평한 함축일 수도 있다고 생각한다.플레이오트로프 (대화) 01:40, 2011년 10월 22일 (UTC)[응답]

레: 카라낙스:안녕 친구 프로그래머!나는 현재 생물정보학을 연구 프로그래머로 일하고 있으며, 프로젝트 계획이 매우 중요하다는 것에 동의한다.그러나, 위키피디아가 시작되었을 때는 아무도 위키피디아의 구조나 조직을 계획하지 않고 있었지만, 그것은 유기적으로 엄청난 양의 조직과 정보를 발전시켰고, 사람들은 오늘날 (내가 위에 올린 링크와 같은 가벼운 독자들과 그룹들 모두) 그것을 이용할 수 있다는 것을 지적하고 싶다.우리가 온톨로지 선 정의에 저항하는 배경에는 같은 생각이 있다: 우리는 실험과 합의를 통해 자연적으로 성장한 것만큼 적절한 것을 결코 설계할 수 없다.플레이오트로프 (대화) 01:40, 2011년 10월 22일 (UTC)[응답]

"{{{{}}인지 알아내기 위해 꼭 테스트가 필요한가?SWL type=행동대상=야행}}"은 "[야행]"보다 더 혼란스러울 것 같은데...?

"나는 위키피디아가 많은 내용에 대한 어렵고 빠른 정의가 부족하기 때문에 번창한다고 가정한다"의 문제는 이 경우 위키피디아와 동등한 것을 얻을 수 없다는 것이다. 정책, 지침, 에세이와 대화 페이지 없이 위키피디아와 동등한 것을 얻을 수 있다.그리고 우리는 그것이 그렇게 작동하지 않을 것이라는 것을 안다.

예를 들어, "유형=행동"이 무엇을 의미하는지 알고 싶다면?문서를 찾으려면 어떻게 해야 하는가?그 서류는 어떻게 생겼을까?그것이 바로 당신이 보여줘야 하는 것이고, 우리가 이미 할 수 있는 것을 다른 방법으로 하는 재미있는 장난감이 아니다(그 또한 더 쉬울 수도 있다).

또한 위키백과에서 의미론적 연계(등등)를 구현하려는 시도를 중단하고, 그것만을 위해 헌신적인 자매 프로젝트를 시작하자는 나의 제안을 되풀이하고 싶다.그런 다음, 예를 들어, 이러한 "유형"에 대한 네임스페이스를 만들고, 리디렉션을 구현하고(예: "행동"과 "행동" 사이), 거기에 문서를 추가하고, 오직 "링크 메타데이터"로만 구성된 "아티클"을 만들 수 있다(혼란을 줄인다)...그게 모두에게 훨씬 더 좋은 선택사항이 아닐까? --Martynas Patasius (대화) 20:55, 2011년 10월 21일 (UTC)[응답]

개방적이고 구조화된 지식 기반을 만들겠다는 목표로 위키백과 이외의 다른 프로젝트를 구축하려는 시도가 많았다.예를 들어 Freebase를 참조하십시오.지금까지 그런 사례들이 모두 문제가 되는 것은 그 중 어느 것도 위키피디아가 가지고 있는 편집 활동의 수준에 어렴풋이 근접하지 못했다는 점이다.위키피디아에 직접 이런 기능성(일부 수준의 구조화된 데이터)을 들여오는 것은 해볼 만한 가치가 있다. 왜냐하면 이곳은 세계 지식을 공공연하게 공유하는 것에 정말로 신경을 쓰는 사람들이 실제로 일하고 있기 때문이다.위키백과 커뮤니티가 우리와 함께 일할 수 있는 더 나은 지식 저작 플랫폼을 가지고 있다면, 이런 논의를 하지 않을 것이다.시스템 내에서 쿼리를 활성화하고, 탐색을 개선하고, 검색을 개선하고, 목록 작성과 같은 일상적인 작업을 자동화하기 위해 사용할 수 있는 방식으로 개념들 간의 관계의 의미를 명확히 하는 능력이 간단히 내장될 것이다.하지만 알 수 없는 여러 가지 이유로 우리는 그렇지 않다.우리는 또 다른 더 좋은 플랫폼이 마술처럼 나타날 때까지 기다릴 수도 있고(곧 그렇게 될 것이라고는 보지 않는다), 이와 같은 노력을 이 멋진 커뮤니티(그리고 기업 관심사를 향해)에서 벗어나거나, 우리가 가진 것을 가지고 바로 여기서 일할 수도 있다.벤자민 굿 (토크) 21:50, 2011년 10월 21일 (UTC)[응답]

다른 말로 하자면, 위키피디아를 지식기반이 되게 하고 싶은 거구나. 왜냐하면 그게 그 연구분야에 도움이 될테니까..?그리고 만약 이 연구 분야가 크게 발전한다면 위키피디아도 어느 정도 혜택을 받을 수 있기를 바라십니까? (그러나 당신은 정확히 어떻게 그런 일이 일어날지 알지 못하거나 상상하지 못하십니까)?--Martynas Patasius (talk) 2011년 10월 21일 23:30 (UTC)[응답]

뭐라고? 이 코멘트를 좀 명확히 해주시겠습니까?플레이오트로프 (대화) 01:40, 2011년 10월 22일 (UTC)[응답]

음, 그럴 수 있을 것 같긴 한데, 정확히 어떤 걸 명확히 해야 하지?어쨌든, 다시 한 번 시도해보겠다. 이 변화의 지지자들은 위키피디아에서 의미적 연계를 구현하고 싶어한다는 것을 내가 정확히 이해했는가? 그것이 의미적 연계를 다루는 연구 분야를 발전시키는데 도움이 될 것이기 때문이다.그리고 그들은 이러한 발전이 위키백과에 도움이 되기를 희망한다고?--Martynas Patasius (대화) 16:25, 2011년 10월 22일 (UTC)[응답]

우리는 "연구 분야를 개발"하려고 하는 것이 아니라, 우리는 솔직히 위키피디아를 지식을 포착하고 공유하는 더 유용한 장소로 만들기 위해 노력하고 있다.나는 네가 말하는 '연구의 분야'가 의미론적 웹과 더 구체적으로 의미론적 위키라고 생각한다.이 분야들은 실제로 꽤 잘 확립되어 있고, 이 연습의 핵심은 그 연구 분야를 확장하는 것이 아니다.우리는 위키피디아가 현재 제공하고 있는 문맥에서 그들의 발전을 이용하기를 바랄 뿐이다.의미론적 관계가 위키 편집자에 의해 자유롭게 생성되고 큰 효과에 사용되는 많은 예시 목록을 보려면, 이 의미론적 미디어 위키 배포 목록을 살펴보십시오.그건 그렇고, 수고 많으셔서 이 토론에 참여해주셨다고 생각하셨어요.비록 우리가 동의하지 않지만, 나는 너의 열정에 감사한다.벤자민 굿 (토크) 17:21, 2011년 10월 24일 (UTC)[응답]

사용설명서는 실제로 장난감이 아니다.만약 당신이 그것을 설치하고 시도했더라면, 물론 의무적으로 할 의무는 없었겠지만, 당신은 "인포박스"에서 관계를 클릭하는 것이 그 관계의 의미에 관한 페이지로 안내하는 것을 보았을 것이다.샌드박스 기사에서 실제로 SWL 템플릿을 작성해 보았다면, 포니 및 행동 분야와 관련한 이전 예시들이 잘못된 형식의 위키텍스트로 귀결되었을 것이고 부적절했을 것이라는 사실도 알게 되었을 것이다.그러나 그렇지 않고 SWL 템플릿 사용에 대해 궁금하고 사용자 설명서가 설치되지 않은 상태에서 사용자의 역할을 수행 중이므로 템플릿의 설명서를 참조하십시오(템플릿:다른 템플릿과 마찬가지로 SWL/doc)을 사용하여 기사의 토크 페이지에서 논의하십시오.이것은 위키피디아에 있는 다른 모든 것에 대해 확립된 절차다.플레이오트로프 (대화) 01:40, 2011년 10월 22일 (UTC)[응답]

미안하지만, 그것은 장난감이다.놀기 재미있고 만들기에 재미있었을 법한 멋진 장난감이지만, 그래도 장난감에 불과하고 진지한 도구도 아니고 프로토타입도 아니다.만약 우리가 정말로 사용자 지정 인포박스를 만들기를 원한다면, 우리는 계승 박스로 하는 일을 할 것이다. (예를 들어, 상자 시작 템플릿, 끝 템플릿, 레코드 템플릿 - 템플릿:s-start, Template:s-end 등)나는 그것이 이 "가짜 인포박스"보다 어떤 면에서 더 나쁠지 모르겠다(물론, 당신은 의미적 링크를 나쁜 것이 아니라 좋은 것으로 간주하지 않는 한).

시멘틱 링크의 또 다른 제안된 사용이 자동으로 목록을 생성하는 것처럼 보인다.리투아니아어 위키백과에서 실제로 시도된 바 있다: 출생과 사망에 관한 며칠과 몇 년의 기사들이 생물학적 기사에서 생성되었다(lt:비키프로젝타스:Kimtadieniai ir mirty, lt:Vikiprojektas:Neaprashytos asmenybės).결과는 완전히 엉망이었다.나는 오직 개시자 자신(그리고 그의 양말 퍼펫)만이 실제로 생물학적 기사, 일용 기사, 연도 기사 - 그리고 그것에 관한 기사가 없는 사람들을 위한 출생 및 사망 기록의 전체 시스템을 사용할 수 있을 것이라고 추측한다.

이제 "조랑말과 행동분야에 관한 예시"에 대해 이야기해보자.음, 이제 나는 당신이 의미론적 연계가 추가될 수 있도록 내부 연계가 만들어지는 것을 기대하지 않는다는 것을 안다.그러나 여전히, 실제로 그렇게 말할 수 있는 지침의 초안이 있어야 하며, 나는 당신이 어떤 템플릿이나 사용자 스크립트가 아니라 그것에서 시작해야 한다고 생각한다.

또한, "만약 당신이 실제로 [...]를 시도했다면...나는 유형 "행동"이 범주에서 설명되고 문서화되어야 한다고 본다.SWL/행동, 맞지?그런 경우 그 설명은 범주의 토크 페이지에서 논의될 수 있을 것 같다.그러나 불행히도 아무런 묘사가 제시되지 않았다.또한 카테고리가 카테고리에는 추가되지 않았다.SWL은 다른 사람들을 좋아한다.그리고 또, "만약 우리 중 누군가가 실제로 그것을 봤다면, 우리는 그 범주의 메인 스페이스 기사를 몇 편 보았을 것이다...한마디로 얼마 전부터 재판이 시작된 셈이다.그리고 의미적 연계에 가장 열성적이고 박식한 사용자들이 참여했다.그리고 - 그래, 시스템은 이미 엉망이야...그럼 다른 재판이 필요한 겁니까, 아니면 이번 재판의 결과를 받아들일 수 있는 겁니까?아, 그리고 실제로 종지부를 찍고 메인 스페이스 기사에서 템플릿을 제거해야 할 것 같아. --Martynas Patasius (토크) 17:27, 2011년 10월 22일 (UTC)[응답]

나는 전체적인 비용 대비 편익 비율이 마음에 들지 않는다.독자들에게는 어떤 이득이 있다. (그것이 그렇게 큰 일인지는 확신할 수 없지만) 그리고 알고리즘이 독자들에게 도움이 될 수 있는 데이터를 이해하려고 노력하는 것에는 많은 이득이 있다.하지만 비용이 너무 많이 든다.가장 큰 문제는 추가 마크업이다.이동 위치

작은 포유류와 새를 잡아먹고 사는 엄밀한 [야행] [새]이다.

로

{{SWL형=행동대상=야행성=야행성(야행성)}} [[새]]]이 엄밀히 말해 작은 포유류와 새를 잡아먹고 산다.

새로운 편집자들에게는 중요한 문제다.사실, 참조 태그도 큰 문제지만 우리는 참조를 위한 메커니즘이 절대적으로 필요한 반면에 제안된 실험은 필수적이지 않다.나는 또한 선호되는 온톨로지와 광범위한 혼란에 대해 메가바이트의 논의를 수반하지 않는 질서 있는 도입에 대해서도 비관적이다.편집 시간은 한정된 자원이고 나는 다른 곳에서 보내는 것이 더 나을 것이라고 믿는다.피치피치(토크) 16:07, 2011년 10월 25일 (UTC)[응답하라]

현 단계에서는 특히 인라인 리프가 이미 큰 폐단이 되고 있는 상황에서, 비용 대비 편익 비율이 너무 높다는 것에도 동의하고 싶다.그리고 작은 감자로 들리듯 오렌지색 밑줄의 시각적 어수선함도 싫어. --홉스 굿이어 (토크) 12:07, 2011년 10월 26일 (UTC)[응답]

CSD 템플릿 텍스트 디스플레이 변경 제안

일부 코멘트를 북으로 전송하기 위해 템플릿 토크에서 보호되는 편집 요청이 있다:Db-meta#첫 번째 문장은 완전히 기울임꼴로 표시되어야 한다.– 루나 산틴 (토크) 20:35, 2011년 10월 26일 (UTC)[응답]

구글 크놀

더 많은 피드백을 위해 보관 해제.헤드폭탄 {토크 / 기여 / 물리학 / 책} 07:31, 2011년 10월 26일 (UTC)[답글]

나는 위키를 검색하고 있는데 구글 크놀에 대한 모든 언급은 스팸 링크이거나 다른 이유로 완전히 부적절한 것 같다.WP:RS에 따라 편집 필터에 추가하는 데 문제/이의가 있는가?헤드폭탄 {토크 / 기여 / 물리학 / 책} 05:53, 2011년 10월 14일 (UTC)[응답]

방금 LinkSearch 목록에서 확인한 커플은 도움이 되지 않는 것 같았다.조누니크 (대화) 06:53, 2011년 10월 14일 (UTC)[응답]

answers.com의 Ditto가 대답한다.yahoo.com, wolframalpha.com, metafilter.com, vark.com, nndb.com 및 이와 유사한 사이트.대화와 다른 페이지는 괜찮지만, 이런 믿을만한 출처는 기사에 없다.사이트에 대한 기사에 주요 웹사이트 링크를 포함시킬 수 있어야 한다. --— Gadget850 (Ed) 11:51, 2011년 10월 14일 (UTC)[응답]

기술적으로 말해서, 보유자가 블랙리스트에 있는 링크를 추가할 수 있는 사용자 권리가 있는가?물론 관리자가 블랙리스트에서 링크를 삭제해 페이지에 추가한 뒤 블랙리스트에 복원하는 방법도 있겠지만 그게 꼭 이상적이지는 않아 보인다.만약 그렇다면, 내가 보기에 우리는 단순히 이 페이지를 블랙리스트에 추가하고, 그들의 링크가 블랙리스트에 올라갔다는 것을 지적하는 기사에 댓글을 달 수 있으며, WP에 게시하도록 사용자에게 지시하는 관련 경고(즉, 블랙리스트에 오른 링크를 추가하려고 하면 받는 경고)에 메모를 추가할 수 있을 것 같다.링크 포함에 대한 충분한 이유가 있는 경우 관련 페이지 또는 그 페이지가 될 수 있다.나이튼드 (대화) 21:32, 2011년 10월 14일 (UTC)[응답]

더 많은 피드백을 위해 보관 해제.헤드폭탄 {토크 / 기여 / 물리학 / 책} 07:31, 2011년 10월 26일 (UTC)[응답]

잠재적으로 원하지 않는 전이성을 용서하십시오. 그러나 블랙리스트가 현재에도 편집 필터에 대한 별도의 개체로 존재하는 이유가 있는가?편집 필터는 블랙리스트 내용을 처리하는 데 필요한 모든 기능을 가지고 있는 것 같다(정규 표현과 일치하고 편집이 포함된 것을 방지).FWIW 나는 문제의 UGC 사이트들이 메인 스페이스에서 걸러져야 한다는 데 전적으로 동의한다.Chris Cunningham (사용자:thumperward) - 토크 12:34, 2011년 10월 26일 (UTC)[응답]

블랙리스트 항목을 편집 필터로 이동할 때 발생하는 한 가지 문제는 편집 필터가 이미 정기적으로 조건 제한에 도달하여 그렇지 않은 항목을 통과하도록 한다는 것이다.필터에 추가될수록 이 한계에 부딪히는 경우가 많다. 28바이트(대화) 15:40, 2011년 10월 26일(UTC)[응답]

블랙리스트 작성했으면 좋겠는데, 편집 필터가 없는 것보다는 나을 것 같아.더그웰러 (대화) 13:47, 2011년 10월 28일 (UTC)[응답]

• 중립적으로 나는 "구글 크놀" 기사가 진짜 출판된 논문의 예의 바르게 복사된 것이라고 상상할 수 있다. 그래서 블랙 리스트는 부적절할 수도 있다.그러나, 나는 거의 모든 용도가 "아티클"을 완전히 사용할 수 없거나 ArbCom Rulling (CH)을 위반하여 제안된 것이라는 것에 꽤 동의한다. 나는 확실한 의견을 가지고 있지 않다.— 아서 루빈 (대화) 22:14, 2011년 10월 29일 (UTC)[응답]
• 편집 필터로 지원.만약 몇몇 사람들이 통과한다면 링크서치는 패트롤러들이 사용법을 알아낼 수 있도록 할 것이다.일부 합법적인 용도가 있으므로 블랙리스트에 올리지 마십시오(WP:SelfPUB). — Train2104 (대화 • 기여 • 카운트) 13:47, 2011년 10월 31일 (UTC)[응답]
• 중립 내가 본 그 외적인 것은 차단된 사용자에게는 쓰레기나 스팸이었고 그것은 결코 믿을 수 있는 출처로 간주될 수 없었지만 나는 그것을 블랙리스트에 올리는 이 생각에 대해 확신이 없다.Dmcq (대화) 2011년 10월 31일 17:31 (UTC)[응답]
• 실제로 a가 아닌 것은 블랙리스트에 올리는 것을 경계함) 소유주나 b) 둘 다에 의해 적극적으로 스팸 발송되는 것은 명백한 쓸모없는 것이나 c) 둘 다.Rich Farmbrough, 00:25, 2011년 11월 1일(UTC)
  [답글]

보관 기간 및 추가 주의사항 제안

최근 (매우 최근) 나는 너무 빨리 보관된 토론을 하고 있었다.나는 WP를 주목했다.ARCHIVE는 아카이빙의 오용 사례를 제공하지 않는다.수동 아카이브가 완료되기 전에 일정 기간을 추가하고 특정 아카이브의 복구를 허용할 것을 제안한다.빵 닌자 (토크) 14:35, 2011년 10월 28일 (UTC)[응답]

모든 대화 페이지에서 사용할 수 있는 최소한의 보관 시간을 설정하기는 어려울 것이다.몇 달 동안 코멘트를 하지 않아도 되는 모호한 기사 대화 페이지의 적절한 보관 지연은 3개월일 수 있으며, 논란이 되는 뉴스 이벤트에 대한 기사의 토크 페이지는 다양한 주제에 대해 하루에 50개의 코멘트를 받는 것이 1주일 또는 2일 미만의 지연으로 매우 빠른 보관을 정당화할 수 있다(때로는 2일).(문제는 주제가 식으면 빠른 보관 속도가 느려지지 않을 수 있다는 것이다) 다른 말로 편집자들에게 좋은 판단을 요구하기 위해, 나는 어떤 사람이 구체적인 가이드라인을 어떻게 말할지 모르겠다.몬티₈₄₅ 18:31, 2011년 10월 28일 (UTC)[응답]

WP:CREEP는 아니라고 한다.실제 이벤트를 살펴보면, 새로운 사용자가 당사의 아카이빙이 어떻게 작동하는지 이해하지 못하고(그리고 상황이 해결되었다고 생각함) 사용자:C에서 다소 불운하게 되돌아온 것 같다.프레드. 그냥 상황을 처리해. (봐, 내가 그랬어!), 그것에 대해 새로운 규칙을 만들 필요는 없어.아니면 매일 이런 일이 당신에게 일어나는가?요에닛(토크) 19:46, 2011년 10월 28일 (UTC)[응답]

내가 하려는 말은 정확하지 않다.아카이빙은 "쉽게" 파괴적인 행위가 될 수 있다.하루에 50개의 포스트가 있는 기사들은, 너무 커서 다루기 힘들 것 같아 확실히 이해할 수 있어.어쨌든.. 난 여전히 수동 보관이 더 많은 통제력을 가져야 한다고 생각해또한 수동 보관이 제대로 수행되지 않는 상황을 제어하는 데 도움이 될 것이라고 생각하고 있었다.어쨌든 그것을 판단에만 의존하는 것은 좀 어렵다.빵 닌자 (토크) 19:04, 2011년 10월 31일 (UTC)[응답]

다른 wiki의 대량 페이지 작성과 관련된 문제

이것은 마을 사람들의 의견을 수렴하고 위키백과의 준수를 보장하고 싶은 제안이 아니다.Bot_policy#Mass_page_creation은 펌프에 통지해야 함을 나타낸다.블로펠드 박사는 독일의 모든 강에 걸쳐 수백 페이지(분당 5-7페이지)의 단지를 대량으로 만들고 있는데, 번역될 수 있다는 독일 기사의 링크 외에는 아무런 내용도 없다.나는 그 결과에 대해 대단한 투자를 하지는 않지만, 그것은 정책을 위반하는 것처럼 보이며, 거의 스팸이 수백 개의 기사를 만들어 내고 있는 것 같다.합의문이 괜찮다고 하면 내 구석으로 가겠다 :) 게이진42 (대화) 20:29, 2011년 10월 28일 (UTC)[응답]

스팸메일을 사방에 그만 보내면, 지장을 줄 거야.요에닛(토크) 20:31, 2011년 10월 28일 (UTC)[응답]

다양한 Δ 작업 요청

위키백과에서 토론하는 경우:관리자 게시판/사고 게시판#클리어화가 필요함, 나는 Δ에 대해 제안된 여러 작업을 게시하기 시작하려고 한다.그런 요청으로 이 위원회를 압도하려는 내 입장에서의 시도는 없다.여러분 중 몇몇은 이렇게 느낄지도 모른다는 것을 이해한다.어떤 경우든 이러한 요청의 적절성에 대한 메타토론이 각각의 특정 업무 요청 스레드가 아닌 이 스레드에 보관된다면 감사하겠다.해당 스레드에 대한 주석을 해당 작업으로만 제한하십시오.감사합니다, --Hammersoft (대화) 17:28, 2011년 10월 24일 (UTC)[응답]

나는 그들 대부분을 지지하지만 우리가 어디에 그렇게 말하길 원하는지 확실하지 않다 :) --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 18:31, 2011년 10월 24일 (UTC)[응답]

• 그럴 필요 없어.제한사항은 반대가 있는지 여부를 질의하고, 만약 있다면, 그 종류의 추가 편집을 실시하기 전에 합의점을 발전시킬 수 있도록 하는 것이다. --Hammersoft (대화) 18:32, 2011년 10월 24일 (UTC)[응답]

• 모두 반대 - 베타의 자동 편집 제한을 초래한 접근 방식에 어떤 변경의 증거도 없다.우리가 마지막으로 필요한 것은 자동화된 편집을 위한 새로운 제안들을 통해 그러한 제한사항들에 대한 최종적인 검토가 필요하다.베타가 우리를 여기까지 오게 한 모든 숙고를 극복한다면 정말 좋을 텐데, 지금으로서는 분명히 그렇지 못한 것 같다. - 위키데몬 (토크) 08:07, 2011년 10월 25일 (UTC)[응답]
• 지금은 모두 반대하라.델타는 그가 계획하고 있는 것에 대한 질문에 대답할 필요가 있으며, 그 제안들은 공개적인 것이 아니라 그가 계획하고 있는 특정한 편집의 집합이 되어야 한다.이와 같이 델타가 제안을 해야 한다.제3자가 하는 것은 "전화" 게임이 점점 더 나빠지기 때문에 재앙을 불러올 수 있는 방법이다.기사를 '패턴'으로 추론할 수 있다는 것이 _델타_는 무엇을 의미하는가?그는 그것이 한 번에 100개의 기사를 리디렉션하는 것을 허락한다고 생각하는가?나는 이 섹션 전체가 편집 제한의 요점을 오해하고 있다고 생각한다.나는 JohnFromPinckney의 의견에 동의하고 그는 나보다 훨씬 더 잘 말한다.호빗(토크) 10시 38분, 2011년 10월 25일 (UTC)[응답]
  • 어떤 경우든, 나는 어떤 "질량" 허가도 의미 있는 편집 요약을 실제로 사용하는 제한과 함께 와야 한다고 생각한다.호빗(토크) 10시 43분, 2011년 10월 25일 (UTC)[응답]
• #10에 대한 내 코멘트를 모두 받아 적으며, 솔직히 말해서 이 모든 과정은 존이 아래에 지적했듯이 다소 불신스럽고, 요점이 있고, 거의 약간 장난스러운 것 같다--크로스미르 (talk) 11:38, 2011년 10월 25일 (UTC)[응답]

• 아, 그럼 이런 요청들을 해야 하는데, 요구조건에 따라 요청이 이루어진다면, 그건 나쁜 믿음이고, 지적이고, 장난꾸러기야?요청이 없으면 그를 때려눕혀라.요청이 있으면 그를 때려눕혀라.여기서 Δ 편집과 관련된 것은 무엇이든 반대할 줄 알았지만, 당신은 지금 정말로 상어를 뛰어넘었다. --Hammersoft (대화) 13:04, 2011년 10월 25일 (UTC)[응답]

• 사실 지금 이 시점에서 방해한다고 쾅쾅 두들겨 패는 거야.제안서 20개?진심이에요?이것은 현시점에서는 요점을 벗어난다.델타는 자신이 맡고 싶은 구체적인 과제를 제안해야 한다.이러한 태스크는 일반적인 제안된 태스크와 같이 시작점과 끝점이 있어야 한다.그들은 지금부터 끝까지 그가 하고 싶은 어떤 편집에 대해서도 포괄적인 예외를 제안하지 않을 것이다.--크로스미르 (토크) 15:28, 2011년 10월 25일 (UTC)[응답]

• 이것이 바로 과거의 모든 제한사항과 ANI 스레드가 이 과정을 축소시킨 것이다. 즉, 지역사회가 델타가 한 번에 한 가지 조치를 취할 수 있는 모든 조치를 승인하도록 하는 것이다.그리고 그것은 델타가 의사소통을 개선하고 유익한 편집에 집착하면서 대신 수, 편집 비율과 그 프로젝트에서 어떤 것으로 끝날지 모르는 어떤 것에 대해서도 선의의 믿음을 주지 않는 편집자들 때문이다.편집자들은 델타가 현미경으로 작동하기를 원하기 때문에, 그가 문서화되지 않은 일을 하지 못하도록 하기 위해서, 우리는 그 과정의 모든 단계에 대해 지역사회에 대한 결재를 받아야 한다.
• 델타를 무너뜨리려는 모든 위키리거들이 이렇게 된 것이다. --MASEM (t) 13:39, 2011년 10월 26일 (UTC)[응답]

• 왜냐하면 선한 믿음은 맹목적인 방패도 아니고 또 갈 수 있는 영원한 우물이 아니기 때문이다.델타는 오랫동안 신의의식을 지켰고 그것을 되찾아야 한다.그렇기 때문에 그는 그렇게 심한 제한을 받고 있고, 사람들이 현미경 밑에서 그를 내보내지 않는 것이다.끝나지 않기 때문이다.불과 4개월 전쯤 그의 편집 전쟁(기술적이든 비기술적이든)으로 인해 NFCC 드라마를 통째로 접하게 되었고, 옆구리에 약간 야만적인 행동을 하는 등 소통이 잘 되지 않았다.몇 년 전 마지막 기회인 23:03, 2011년 10월 26일 (UTC) 회신에도 불구하고 여전히 존재하는 문제다.

• 그것 자체가, 나는 반대할 수 없다.문제는 이 특정 프로세스(햄머소프트가 델타가 어떤 작업을 하고 있는지 제안)가 달성하려고 하는 것에 대해 불평하는 문제다.델타가 운영해야 할 단계를 규정하는 겁니다.그런데도 당신은 이 과정이 한계를 정립하려는 사실에도 불구하고 "점점"이라고 불평하고 있다.사용 중인 프로세스는 "과제"와 달리 보정이 필요하므로 수정해야 하는 것으로 무한정 작동하는 많은 봇과 거의 동일하다.그것에는 아무런 문제가 없다.그렇다, 나는 많은 사람들이 더 이상 델타에 대해 선의를 가지고 있지 않다는 것을 이해한다. 하지만 선의의 범위 안에서 일하려고 하는 누군가에 대한 책임 있는 가정을 버리는 것은 또 다른 일이다.만약 당신이 그것을 지지할 수 없다면, Hammersoft가 종종 말했듯이, 당신은 그 프로젝트에서 델타에 대한 제안서를 쓰기 시작하는 것이 좋을 것이다.대신 델타가 개선될 수 있다고 생각한다면 - 비록 그러한 개선에 도달하기 위한 매우 길고 힘든 길이 있고, 그러한 금지 조치가 필요하지 않더라도, 그의 제한사항으로 이미 요약된 프로세스가 그것을 완화시키려 하지 말고, 여기서 선의의 노력을 기울이도록 하라. --MASEM (t) 23:20, 2011년 10월 26일 (UTC)[응답]

• 내가 여러 번 분명히 말했듯이 문제는 그가 어떻게 그것을 했는지에 관한 것이고 그것은 델타의 현재 제한사항의 정신에서 원격으로 이루어지는 것이 아니다.그러므로 내가 왜 그것을 문제 삼고 이 모든 과정이 위반한다고 생각하는 여러 가지 지침과 정책을 개략적으로 설명했는가 하면, 그 평가에서 나만 그런 것은 아니다.이 제한의 요점은 그의 제한에 대한 무제한적인 면제가 아니라 특정한 집중적인 작업에 대한 것이었다.이 문제는 그의 초기 제안의 대부분에 대한 지지가 실제로 없다는 것이 분명해졌을 때 더 추진되었다.WP의 재편성:IDNTHEARTHE--Crossmr (토크) 10:16, 2011년 10월 27일 (UTC)[응답하라]

• 한정된 페이지 수에 영향을 미치는 과제와 모든 페이지에 반복적으로 영향을 미칠 수 있는 진행 중인 과제 사이에는 차이가 없다. 문제는 둘 다 "25페이지 이상에 영향을 미치는 편집의 패턴"이라는 것이다.특정 작업에 초점을 맞춘 것은 아무 것도 없었다. 델타가 AWB와 같은 사용자 스크립트를 사용하여 수정하지 않은 변경 작업을 수행하는 것을 방지하기 위한 제한 사항이 있다.
• 이제, 나는 당신이 한 번에 하나씩 제안되고 있는 일의 옴니버스라는 것에 대해 걱정하는 것에 대해 공정한 우려가 있다고 말할 것이다.그러나 그렇기 때문에 적절한 편집 요약과 페이지를 얻어서 델타가 정확히 무엇을 하도록 승인되었는지, 그리고 내가 제안했던 것, 그리고 그가 승인한 임무를 수행하고 있는지 검증하기 위한 심도 있는 검토 기간이 있는 것을 설명해야 한다.그리고 단지 봇이 일을 할 수 있다고 해서 델타가 그것을 하는 것을 막는 것은 아니다; 그의 편집자나 편집자가 스스로 봇 작업을 하는 것을 제한하지 않는다. 만약 당신이 델타에게 그것이 필요하다고 생각한다면, 당신은 계속해서 그의 편집에 대한 또 다른 제한을 제안하기 시작할 필요가 있다.그 대신 내게는, 아래 델타에 대해 승인된 업무들이 봇이 할 수 있기 때문에, 델타의 변화는 조절을 하거나 그와 비슷한 것에도 해로울 가능성이 거의 없다는 사실을 받아들이고 있다. 즉, 델타의 위키그램이 그가 여전히 요청하고 있음에도 불구하고 수정하기 간단하고 일을 망치는 것이 불가능하다면, 지역사회는 아무런 문제가 없다.편집한 내용을 수동으로 확인하는 방법.
• 지역 사회의 제한은 무기한이라는 것을 기억하라. 즉, 지금 이 프로젝트에서 델타를 금지하고 싶지 않다면, 그가 그렇게 할 수 있다는 것을 증명하기 위해 그 안에서 일할 수 있는 기회를 그에게 주어야 한다는 것을 기억하라.이 과정은 그 일환이다. --MASEM (t) 13:01, 2011년 10월 27일 (UTC)[응답]

• 그들은 무기한이지만 영구적이지 않다.만약 델타가 오랜 시간동안 그것을 모을 수 있다면 그는 아마도 그것들을 제거하기 시작할 것이다.편집 봇이 하는 것과 편집 봇이 하는 것은 매우 빠르게 하는 경향이 있는데, 이는 데이트 관리 태그와 같다.요즘 나는 날짜가 없는 유지 관리 태그를 발견하는 것이 매우 드문 일이라는 것을 발견한다.구체적인 초점에 대해서는, 우리는 그 제한을 초안한 사람으로부터 들었는데, 그는 그것이 정말로 그 제한의 목적이었다고 진술했고, 반대하는 사람들 중 일부는 똑같이 느끼는 것 같다.그리고 이 모든 과정은 불신에서 비롯되었고, VPP는 지난 5월/6월에 델타에 대해 논의되었다. 왜냐하면 그는 하루 반나절의 편집 작업을 했고, 그가 VPP에 가서 제안했기 때문이다. 그것은 그의 블록 로그에는 없었지만, 적어도 4개월 동안 아무도 그 일을 해내지 못했다.ersoft와 dirk의 클레임이 일어날 예정이었다.[4]--크로스미어 (대화) 22:59, 2011년 10월 27일 (UTC)[응답]

• 누군가가 실제로 이것이 25개 이상의 기사에 영향을 미치는 편집의 패턴으로 보인다고 말하기 전에, 델타는 이와 같은 편집 작업을 8,000번 했다. 사람들은 델타가 일을 중단하거나 변경하기 위해 응답한 문제들을 지적했다.그리고 아니, 이것은 프람과 같은 편집자들이 이러한 편집들을 현장 확인하면서 파악한 몇몇 문제들을 떨쳐버리기 위한 것이 아니다. 그러나 동시에, 최종 결과는 원래 제한사항들이 놓이게 된 편집사항들과 달리 기사 발표에서 완전한 실패는 아니다.여기서의 문제는 이것이 지금까지 편집의 연속이라고 확실하게 규명되지 않아 현재의 드라마로 이어졌다는 것이다.비록 델타가 차단되지 않았고 그가 이런 종류의 편집을 계속했다면 나는 누군가가 결국 그렇게 했을 것이라고 확신한다. 하지만 동시에 누구의 감시에도 없는 동안 그들은 보트를 넘어뜨리거나 의사소통을 통해 쉽게 다루지 않은 문제를 제기하지는 않는다.원래 제한사항의 목적 그대로야.현재의 문제는 명확성이 부족하기 때문이며, 확실히 델타가 이를 우회하려는 의도는 아닌 것 같다. --MASEM (t) 17:10, 2011년 10월 28일 (UTC)[응답]

• 문제는 당신이 그 문제를 다시 회피하려 한다는 것이다.나의 요점은 망치소프트 위반이다: WP:포인트, WP:GAME, WP:BEAN과 이 절의 전제는 불신을 전제로 한다.델타와 제출이 필요한 전체가 5월에 제기되었다는 사실이 그 불신을 분명히 보여준다.해머와 더크는 AN/I 실에서 사람들이 2년에 걸쳐서 되돌아갈 것이라는 온갖 나쁜 믿음의 주장을 하고 있었는데, 편집과 같은 26개의 편집본을 찾아낸 다음 델타에게 위키피디아가 바닥나도록 했다.이 부분은 그 악신론에서 비롯되었다.5월에 있었던 이전 토론은 그 문제가 우리의 마지막 큰 델타 토론의 최전선에 있었다는 것을 보여준다.나는 그것이 몇 번 올라왔던 것을 기억한다.그리고 그때도, 그 이후로도 누가 먼저 가서 그렇게 하지 않았다.Hammersoft는 분명히 WP를 돌아다녔다.그 지역 아래 IDNTHEAR은 혼란을 더욱 가중시키고 있다.두 번째 요점은 델타항공이 이러한 종류의 업무들이 무한정 진행되기 위해 포괄적인 면제를 필요로 하지 않는다는 것이다.그는 그것을 얻기 위해 아무것도 하지 않았다.--크로스미르 (토크) 23:17, 2011년 10월 28일 (UTC)[응답]

• 이를 이끌어낸 ANI 실로부터 '2년 동안 26번의 편집'은 과장된 것이었지만, 편집자들은 델타가 1차 제한에서 경고한 편집의 패턴이라고 믿고 사전 승인 없이 일정 기간 동안 25번 이상의 편집을 하지 않기를 바라는 것이 분명하다.Hammersoft가 이것을 시작하게 된 이유는 (그것이 패턴이라고 느끼는 소수민족과는 거리가 멀었기 때문에) 예스일 것이라고 가정하고, 따라서 그 제한에 의해 마련된 VPR 과정을 확립하기 위해서였다.기본적으로, ANI 논의가 어디서부터 두 단계 앞서서 델타가 작업하게 될 이러한 과제들을 정립할 것인가 하는 것이다.당신이 어떻게 그것을 나쁘게 받아들이고 있는지 알 수 없다; 그래, 나는 해머소프트가 부드러운 언어가 아니라는 것을 알지만, 나는 델타를 법의 정확한 서한에 따르도록 확실히 하는 그 공동체조차도 델타가 정해진 절차를 따르도록 함으로써 델타를 돕도록 하는 것 외에는 아무것도 보지 않는다.그것은 뾰족하거나 불신하는 것과는 거리가 멀다.
• 두 번째 요점에 대해서는, 이것을 일괄 면제로 간주해, 재판 기간이라는 아이디어를 소개한 것도 그 때문이지만, 그것이 더 이상 재판 블록으로 확대된다면 문제가 없을 것이다.아마도 100개의 기사를 1차 블록으로, 250개의 1차 블록으로 나누어, 더 큰 블록을 요청하거나 그의 정리 측면에 새로운 작업을 추가하기 전에 편집이 모두 적절한지 커뮤니티가 판단할 수 있게 할 것이다.그러나 "이것은 X 기사에 영향을 미칠 것이다"라고 요청하려는 것은 실제로 얼마나 많은 기사들이 영향을 받는지가 전체 en.wiki의 크기이기 때문에 정리 작업에 대한 정의를 내릴 수 없다.그러나 다시 한 번 작은 블록으로 제한하고 지역사회가 기대하는 역량을 보여주면서 용돈을 더 준다면, 그는 여전히 그가 원하는 생산적인 위키그램이 될 수 있지만 그 제한의 한계 안에 있을 수 있다. --MASEM (t) 23:44, 2011년 10월 28일 (UTC)[응답]

• 그래, 과장된 말이지만, 쉽게 말하지 말자, 두 사람이 여러 번 반복한 것이고, 그것은 분명히 현실에서 근거가 없는 나쁜 믿음의 가정이다.명시한 VPR 제한은 특정 작업을 대상으로 한다.이것들이 나타내듯이 공개적인 종료된 면제 조항은 아니다.만약 해머소프트가 델타를 돕고 싶다면, 그는 그가 정해진 제한사항 내에서 일하는 것을 도와야 하고 그것들로부터 꿈틀거리며 빠져나갈 방법을 찾으려고 해서는 안 된다.이에 대한 파괴적인 측면이 분명해진 것은 이미 국내에서 아무런 지지도 받지 못한 제안이 십여 건이나 있었음에도 불구하고 그는 가서 "더 와야 할 것"이라는 불길한 메시지와 함께 몇 건을 더 추가했을 때였다.X 기사를 겨냥할 필요는 없다.특정 프로젝트, 카테고리 등의 기사를 대상으로 할 수 있다.X 편집 또는 X일 동안 실행하도록 제한될 수 있다.그러나 델타항공은 그런 생각을 스스로 내놓고 실제로 무슨 일이 일어나고 있는지 이해한다는 것을 보여줄 필요가 있는데, 그가 그렇게 생각하지 않는 것 같다는 것이 점점 분명해지고 있기 때문이다.더 있어, 하지만 가야 해.델타 편집조차 허용되지 않는다는 아래 그의 주장은 어처구니가 없다.--크로스미르 (대화) 06:12, 2011년 10월 29일 (UTC)[응답]

• 이미 그 논의에 참여했음에도 불구하고, 나는 델타에 있는 AN/I 스레드에서 이 제안 사업을 전부 제기했어.--크로스미르 (토크) 15:43, 2011년 10월 25일 (UTC)[응답]
• 위키백과에서 22개를 잡으십니까?누가 그랬을까...한숨. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 17:55, 2011년 10월 25일 (UTC)[응답]

• 나는 이러한 요구를 하는 데 있어서 그를 대신하여 운용할 수 있도록 Δ에게 요청하고 허가를 받았다.그는 내가 이런 요청을 하는 것을 도왔다.그는 그들을 알고, 그들을 지지한다.나는 독립적으로 행동하는 것이 아니다.그런 점을 감안할 때, 누가 그 제안을 하고 있는지에 대해 의견이 갈리는 것은 설득력을 얻지 못할 것이다.그는 이 제안들을 해야 한다.그것들은 만들어지고 있다.대체 제안이 있다면(그 사람 말고는 사이트에서 금지된 것이 아니라면) 나는 귀를 기울인다. --Hammersoft (대화) 16:18, 2011년 10월 25일 (UTC)[응답]

• 문제는 델타가 특정업무에 대한 요청을 할 수 있도록 제재조항의 취지가 매우 분명해 보이는 상황에서 포괄적 면제조항을 만들어주셨다는 겁니다.그 조항은 제재의 범위와 효과를 무한정 줄이려는 의도가 아니었는데, 근본적으로 이런 제안들이 있는 것이고, 이것이 바로 당신이 이 제도를 이용하려는 것처럼 보이게 하는 것이다.테크노심비오시스 (대화) 22:48, 2011년 10월 25일 (UTC)[응답]

• 그렇다면, 모든 특정 편집에 대한 승인을 얻는 것 외에 매우 구체적인 작업 설명을 승인하지 않는다면, 해결책은 무엇인가?우리가 지금 여기에 있는 이유는 그의 편집 제한사항에서 "편집 패턴"이라는 생각이 매우 광범위하게 읽혀졌고, 무엇이 패턴이고 무엇이 아닌지에 대한 회색 영역으로 이어졌기 때문이다.어떤 이들은 유익하든 그렇지 않든 간에 그의 가장 최근의 편집을 패턴으로 삼고 있기 때문에, 해머소프트는 델타사가 편집 제한에 따라 제안서를 일일이 열거하도록 했다.에르고, 그것은 예외를 조각하는 것이 아니라, 편집 제한의 범위 내에서 그가 할 수 있는 일을 식별하는 것이다.이것이 바로 그 공동체가 추구하는 것이다.일부 작업이 수용가능하고 일부 작업이 수용되지 않는 지금 해당 내용을 다시 읽어본다는 것은 편집 제한사항의 취지에서 이것이 작동하고 있다는 것을 의미한다. --MASEM (t) 13:45, 2011년 10월 26일 (UTC)[응답]

• 내가 읽은 제한사항들은 델타가 자신이 완수하고 싶은 특정 업무(예: 특정 100개 기사의 링크 순서 수정)가 있을 때, 그는 여기서 그 조치를 제안하고 검토 후 승인하거나 거절하는 것이었다.단순히 '델타는 무한한 수의 기사로 링크 순서를 바꿀 수 있다'고 제안할 수 있는 것은 내가 읽은 것이 아니다. 왜냐하면 그것은 그의 제한사항의 포괄적 축소였기 때문이다. 그는 이제 그러한 제한사항들을 위반하지 않고 애당초 자신의 제한을 야기했던 것들을 정확히 할 수 있다.나는 단지 그것을 전혀 의도하는 것으로 보지 않는다.이것들은 엄격한 제한사항이고, 그것들은 각각의 제안들이 요구하는 대로 무기한으로 축소되어야 하는 것이 아니라, 그것들은 특정 업무의 완료를 위해 일시적으로 포기되어야 한다.테크노심비오시스 (대화) 22:01, 2011년 10월 26일 (UTC)[응답]

• 그런 식으로 읽지는 않지만, 그 점을 고려해서, 그리고 아래에 내가 만든 요점을 고려한다면, 델타(또는 해머소프트)가 어떤 영향을 받을지 알 수 있도록 델타(또는 해머소프트)가 작업할 예정인 기사들을 어떻게 선정할 것인가를 정의하는 것은 매우 좋은 생각일 것이다.그렇기는 하지만, 그것은 공동체 검토를 위한 "테스트 블록"과 관련하여 아래에 추가해야 할 또 다른 아이디어를 주어서, 우리가 때때로 봇과 함께 하듯이, 제한된 작업을 진행 중인 작업으로 확장할 수 있도록 한다. --MASEM (t) 23:27, 2011년 10월 26일 (UTC)[응답]

• 이러한 면제가 델타가 현재 제한 사항을 위반하여 자동 또는 반자동 편집 또는 자동화된 것으로 보이는 편집 또는 편집을 수행할 수 있도록 어떤 식으로든 해석될 수 있다면 모든 것을 반대한다(아래에 있는 내 개별 표를 초과).델타 본인을 포함한 아래 언급의 일부는 그가 이러한 작업을 수행하기 위해 스크립트를 사용할 것임을 암시한다.내가 제재에 대해 읽은 것은 이러한 면제 요청은 델타가 자신의 25개 조항 제한을 초과하는 것만 허용한다는 것이다.자동 편집에 대한 그의 제한은 이러한 공개 요청의 범위에 포함되지 않으며, 이러한 면제에 대한 해석은 델타가 그러한 편집을 수행하지 않을 수 있다는 것을 엄격하게 인정해야 한다.테크노심비오시스 (대화) 23:26, 2011년 10월 25일 (UTC)[응답]
  • 너 자신을 속이지 마라.그와 그의 지지자들은 분명히 그가 대본을 사용한다는 것을 인정하지만, 그가 수작업으로 편집된 내용을 검토하는 한 그가 그렇게 하는 것을 금지하지는 않는다.스크립트의 완전 자동화된 사용과 스크립트의 반자동화된 사용 간의 차이는 WP의 문제다.AGF 및 위키피디아 운영의 범위 내에서 본질적으로 검증할 수 없음; WP:개인 정보 보호 등나는 그가 모든 편집에 자판을 입력하는 것에 동의할 것이라고 생각하지 않는다. 그리고 그것조차도 나머지 편집자들이 인간적인 감독을 받는다는 것을 보장하지는 않을 것이다.Uʔ (대화) 06:29, 2011년 10월 26일 (UTC)[응답]
    • 나는 그 규제의 본질만큼 그 규제의 검증가능성에 대해 지나치게 신경쓰지 않는다.나는 그것이 해제되어야 한다고 생각하지 않으며, 사람들은 종종 내가 검증될 수 있다고 생각하지 않았던 것을 검증할 방법을 찾는데 꽤 창의적이다.테크노심비오시스 (대화) 21:56, 2011년 10월 26일 (UTC)[응답]
    • AFAIK, 커뮤니티는 Δ가 감독 스크립트를 사용하는 것이 괜찮다고 말했다 - 이것은 속도 제한, 시민성 제한, 전체 자동화 제한 또는 기타 제한 사항을 무시하는 요청이 아니다.만약 대본이 그 없이 실행된다는 것이 명백하다면(예: 누군가가 그에게 대화 페이지에서 멈추라고 요청하고, 편집은 응답 없이 계속됨) 그렇다, 그것은 미개한 발언과 너무 빠른 편집이나 다른 제한사항 위반과 마찬가지로 완전히 차단할 수 있다.또한 여기서 부여되지 않은 다른 패턴이 나타나는 것도 허용하지 않으며, 여기서 부여되지 않은 패턴으로 계속 이어지는 것도 허용하지 않는다.엄밀히 말하면, 25개 이상의 어떤 패턴도 허용되지 않는다는 것이다. 단, 여기서 편집이 진행될 수 있다는 것에 대한 합의가 있는 것을 제외한다면 말이다.
    • 나는 여전히 '패턴'이라는 단어가 현재 너무 모호하고 불명확하게 정의되어 있다고 생각한다. 하지만 그것을 더 잘 정의하려고 노력하는 데는 분명 지지가 없다. 지원은 관리자의 재량에 맡겨져 있다.누군가 곧 새로운 패턴을 발견하게 될 것이기 때문에 우리가 곧 여기에 올 것이라고 확신한다(그리고/또는 AN/I 그리고/또는 Δ의 블록로그에서) 하지만, 아마도 그것은 여기서 새로운 실마리를 잘 통과할 것이다. --Dirk Beetstra 14:16, 2011년 10월 26일 (UTC)[응답]
• 대부분 반대하다.유일한 예외는 봇이 수행할 수 있는 작업이며, 봇이 정확히 무엇을 해야 하는지에 대한 합의가 이루어지며, (눈이 깨지는 것을 수정하지 않는 한) 실질적인 편집과 결합되며, 편집 요약에 정확히 어떤 작업이 수행되고 있는지에 대한 조항이 있다.과제 1-20 중에서 이것은 4, 6 (예시처럼 눈에 보이는 공백에만 적용, 참조에 포함되지 않는다는 의미), 7 (대본에 의해 반대로 수동으로 링크를 체크하는 경우에만), 8 (표시된 제한사항 포함), 9, 12 (그리고 실질적인 편집 요건에서 이를 면제할 수 있지만 참조는 동일해야 함), 13, 18, 18, 13, 18, 18, 13, 18, 13, 18, 13, 18, 8이다.20 (그리고 나는 실질적인 편집 요건에서도 이것을 면제할 수 있다.)스트롱은 10, 11, 15, 19에 반대하며 16, 17에 대해 합리적인 합의점을 찾지 못했기 때문에 별도로 반대한다.19의 예는 적절하지 않다.— 아서 루빈 (대화) 22:33, 2011년 10월 26일 (UTC)[응답]
• 모든 것에 반대하라 이 편집자의 오랜 논란적 행동 이력을 고려할 때 그 제한은 적절하다.(그가 편집을 전혀 허락받지 못했다는 것은 나에게 꽤 놀라운 일이다.)ElKevbo (대화) 17:30, 2011년 11월 1일 (UTC)[응답]

Δ 메타 토론

• 나는 이 과제들의 표현에 대해 폭넓은 관심을 가지고 있다.그들은 그들이 괜찮은 상황이지만 그럼에도 불구하고 그것들을 적용해서는 안 되는 예외적인 상황들이 있다.작업이 "승인된" 경우, 예외도 인정되어야 한다.만약 며칠 후, 사람들이 어떤 상황에서는 그 일을 적용해서는 안 된다고 말한다면, 나는 "그 일을 할 수 있도록 승인되었다"고 주장하는 논쟁을 보고 싶지 않다.김메투 (토크)20:15, 2011년 10월 24일 (UTC)[응답]
• 마찬가지로, 다른 방향에서는, Δ에 동의하지 않고, Δ에 동의하지 않으며, 그가 그들의 해석에 따라야 한다고 주장하기 때문에, 사람들이 그 제한을 맹목적인 도구로 사용해서는 안 된다.편집자마다 의견 차이는 항상 있을 것이다. --Hammersoft (토크) 20:33, 2011년 10월 24일 (UTC)[응답]
• 나는 고양이와 강아지를 지지하며 찻주머니가 바닥나는 것을 반대한다. -- fg^TC 22:07, 2011년 10월 24일 (UTC)[응답]
• 댓글을 달다.그의 친구들이 여기서 사소한 일 때문에 청원을 한다는 것은 재미있는데, 이 일이 소동을 일으킨 것이 아니라는 것은 명백하다.have mörser, will talk (talk) 04:57, 2011년 10월 25일 (UTC)[응답]
• 나는 편집 요약으로 "정리"를 극도로 지속해서 사용하는 것이 걱정된다. 반자동화 도구를 사용하는 경우에는 좀 더 유용한 요약을 제공하기 위해 쓸 수 있고, 수동으로 변경한다면 설명해도 문제가 되지 않을 것이다.제재의 성격을 감안할 때 보다 구체적인 편집 요약이 큰 도움이 될 수 있다.– 루나 산틴 (토크) 04:58, 2011년 10월 25일 (UTC)[응답]
  • 동의한다. 뫼르세르에게 여행(토크) 05:00 (UTC)[응답]

• 해명을 구하고 있다.분명히 이 실은 Δ라는 특정 사용자에 관한 것이다.그만큼 내가 스스로 알아낸 것이다.사용자:Δ에 대한 지식은 성공적으로 피했지만, 해머소프트, 당신이 그의 존재와 문제적 행동을 무시할 수 없게 만들었기 때문에, 나는 이 거대한 실(지금까지 약 60K바이트)에 대한 해명을 요구하지 않을 수 없게 되었다.

Δ는 AN/I와 ArbCom에 가본 적이 있고, 차단과 금지, 심지어 우리가 그에게 주소를 쓰거나 참조할 수 있도록 그의 개인 템플릿이 필요할 정도로 그의 동료 위키피디아인들과 친해질 수 없는 사용자인 것 같다.분명히 그는 비정보적인 편집 요약을 가지고 긴 연속 편집을 하는 것을 선호한다; 그는 편집이 WP 커뮤니티에 유용하게 보이든 원하지 않든 간에 짧은 시간 안에 많은 편집을 하는 데 도움을 주기 위해 대본을 사용하는 것 같다.종종, 내 생각에 그들은 그렇지 않은 것 같다.

이제 그의 터무니없는 행동에도 불구하고, 그는 완전한 금지를 피할 수 있는 기회를 갖게 되었다. 만약 (다른 것들 중) 그는 25페이지 이상의 편집 패턴에 대해 승인을 받는다.편집 제한사항이 25페이지의 제한시간을 명시하지 않는 것은 명백한 과실로 보이지만, 나는 그것이 어떻게든 해결될 것이라고 생각한다.하지만 내가 이해할 수 없는 것은 당신이 이 모든 "Δ 작업" 실타래로 여기서 성취하려고 하는 것이다.당신은 Δ를 애초에 곤경에 빠뜨린 모든 종류의 행동에 대해 사전 허가를 구하는 것처럼 보인다(무명 편집 요약을 사용하는 것을 제외하고, 아직 그것을 다루지 않은 것 같다).그것은 내가 편집상의 제한을 보는 방식과 배치되는 것 같다.

내가 이해하는 방식으로는 Δ는 편집(또는 다시 차단되지 않았다면)이 허용되지만, 만약 그가 그와 유사한 변경을 하고 싶은 특정 기사 집합("편집 패턴")을 본다면, 그는 그 다음에 구체적인 승인을 구할 필요가 있다.만약 그가 "법질서 에피소드에 관한 기사들을 봤고, 그들이 Y를 가져야 할 때 지난 사계절의 페이지들이 모두 X를 가지고 있다는 것을 알았다"고 말한다면, 그는 와서 그 기사들에 대한 X-to-Y 변경을 할 수 있는 허가를 구할 수 있을 것이다. (그가 합의를 볼 때 여전히 4개의 편집/분간의 제한사항을 10분 안에 관찰한다.)

대신 Δ가 그러한 편집 패턴을 수행하고자 하는 충동을 얻을 경우에 대비하여 어떤 기사(사실상 모든 기사)에 대해서도 X를 Y로 변경할 수 있도록 사전에 허가를 받고자 한다.내가 너의 목적을 정확히 이해했니?왜냐하면 내가 그렇게 하면 편집 제한의 취지와 금지를 피하기 위한 수당을 잘못 해석하는 것 같기 때문이다.하지만 아마 내가 잘못 이해한 건지도 몰라.— JohnFromPinckney (대화) 09:56, 2011년 10월 25일 (UTC)[응답]

• Δ는 반복적인 편집을 할 수 있는 허가를 요청하기 위해 필요하다.일부 사람들은 그러한 요구사항을 매우 광범위하게 적용하고 있기 때문에, 현재 상황은 Δ의 어떤 편집도 그 편집을 수행하기 위한 요청이 있을 때 근거가 있어야 하는 상황이다.그는 이미 이런 편집 작업을 하고 있다.그러니까 과거와 미래다.만약 그가 어떤 타입의 다음 타입이 24 이상의 숫자가 될 정도로 충분히 그것들을 했다면, 어떤 편집자는 여기서 특별한 요청이 없다면 비슷한 편집을 할 때 반칙을 할 것이다.이것은 우리가 싸우지 않을 수 없는 어리석음이다.그는 이러한 요청을 해야 하고, 그를 대신하여 이러한 요청을 할 수 있는 권한이 있기 때문에, 누군가가 원격으로 "패턴"으로 수축할 수 있도록 가능한 모든 종류의 편집을 다루도록 요청되고 있다. --Hammersoft (대화) 13:02, 2011년 10월 25일 (UTC)[응답]

나는 AN/I에 대해 누군가 패턴으로 어떤 것을 구성할 때 - 25일 이전이든 25일 이후에든, 그 사람은 AN 또는 AN/I로 그것을 가져와 Δ에 통보해야 한다고 제안했다. Δ는 그 순간 패턴으로 해석되는 부분과 함께 정지하며, 생성된 패턴이 패턴으로 간주되지 않는지 또는 퍼미스를 요청한다.사이온(어쨌든 최신 상태) - 패턴에 맞는 편집이 이미 수백 개라도 블록이 적용되지 않음(단, 해당 패턴으로 상당수의 편집이 통지 후인 경우 블록을 적용할 수 있음). --Dirk Beetstra 13:07, 2011년 10월 25일(UTC)[응답]

아니, 예를 들어, 델타가 2000개의 빠른 편집을 할 수 있도록 문을 열어놓으면, 아주 노골적으로 패턴을 구성하는 기사에 대해 누군가 불평을 하게 하고, 지역사회가 '그래 그게 패턴이야'라고 결정하게 한 다음, 같은 패턴의 연속이 아니라고 주장할 수 있을 정도로 다른 2000개의 빠른 편집으로 넘어가게 된다.내가 보기에 델타 편집의 문제 중 일부는, 그가 의심스러운 편집들을 너무 많이 해서, 누군가가 그의 작업을 나중에 확인하는 것이 거의 불가능하거나, 결과적으로 야기되는 혼란을 정리하는 것이 더 나쁠 수 있다는 것이다.내가 제재안을 읽은 것은 '25개 기사' 수치가 조절판이라는 점, 다른 사람들이 그의 편집을 더 쉽게 검토할 수 있도록 그를 느리게 하는 점, 그리고 만약 그가 그 이상의 것을 원한다면 사람들이 그의 의도된 변화를 미리 검토할 수 있도록 사전 승인이 필요하다는 점이다.누군가 불평하는 그런 시간이 제재를 완전히 해제하는 것이 될 때까지 그에게 자유 재위를 주는 것은 내가 의심하는 무언가가 많은 관심을 끌 것이다.테크노심비오시스 (대화) 23:34, 2011년 10월 25일 (UTC)[응답]

그의 편집 속도 제한(10분 평균 40회 편집)에 따르면 2000년 편집은 그가 그 속도 내에 머문다면 500분(약 8시간 이상)이 소요될 것이다.누군가 먼저 알아차릴 거야그래서 그는 이미 스로틀을 가지고 있다.원본 25개 기사의 아이디어는 델타가 지역사회의 승인을 받지 않은 공통적인 변경사항(예: 봇 요청 과정을 거치지 않고 허가받지 않은 봇을 운영하는 것과 동등한)을 시행하지 못하도록 하는 것이었다.문제는 여러 기사에서 편집 패턴과 유사한 편집을 하는 패턴 사이에 회색 선이 있다는 점이다.어떤 사람이 어떤 패턴을 고려할지는 다른 사람에 의해 결정되지 않을 것이다.그러므로 델타 자신이 패턴을 고려하지 않고 다른 누군가가 하는 일을 시작한다면, 그는 그것에 경각심을 가질 필요가 있고 그것이 편집의 패턴인지를 결정하기 위해 토론이 뒤따를 필요가 있다.이미 VPP를 지목해 편집 패턴을 요청했으니 거기서 논의가 이뤄지는 게 가장 일리가 있다.그러나 중요한 것은, 누군가가 그에게 패턴이라고 생각하고 그것에 대한 토론을 개시한다고 직접(대화 페이지) 말하는 순간, 델타는 그 구체적인 행동을 중지할 것으로 예상해야 한다. --MASEM (t) 13:29, 2011년 10월 26일 (UTC)[응답]

나는 이 일련의 제안들이 증가하는 것을 지켜보며 소름이 끼쳤다.그것은 이제 보건스 평의회가 할례청에서 고안한 실행 계획을 사용하여 지시하는 것처럼 보인다.

어떤 편집자도 특별한 권리를 가져서는 안 된다.편집이 잘되면 보관하십시오.의도가 좋지만 편집이 아니라면: 취소하고 극복하라.의도가 나쁜 경우: 실행 취소, 경고, 다시 경고, 차단이러한 모든 정책 및/또는 지침이 마련되어 있다.

정책이나 지침의 변경에 대해 계속 논의하려면 편집자 한 명을 중심으로 정책이나 지침의 변경에 대한 근거를 두지 않고 계속 논의해야 한다.25개 편집 사업 전체 패턴도 겉보기엔 그럴듯한 이유로 제자리걸음을 하고 있다.왜 편집자 한 명이라도 자유 출입증을 받아야 하는가?이 일련의 제안들이 터무니없기 때문에 다른 정책이나 지침에서는 받아들일 수 없는 것으로 여겨졌으면 한다. --fg^TC 06:05, 2011년 10월 26일 (UTC)[응답]

누군가 ANI에서 끊임없이 언블럭을 주장하는 지지자들을 가지고 있을 때 차단하는 것은 효과가 없다. 왜냐하면 그들은 그 제한들을 처음에는 불공평하다고 보기 때문이다.Uʔ (대화) 06:32, 2011년 10월 26일 (UTC)[응답]

불공평해? 누가 그랬어?내 고민을 표현하기 위해 '몰래'라는 단어를 쓸 것 같다. --Dirk Beetstra 14:03, 2011년 10월 26일 (UTC)[응답]

Δ는 현재 봇이 동등하게 다룰 수 있는 편집을 수행해야 하는가?라는 질문이 반복적으로 제기되었다.아래의 몇 가지 제안은 이 문제와 관련하여 이의가 있다.최근 Δ 제안 과제 #18. – 루나 산틴 (대화) 23:16, 2011년 10월 26일 (UTC)[응답]

그리고 그 질문은 그것 자체의 하위 스레드가 필요할 것 같기 때문에, 여기 또 다른 질문이 있다: 되돌리는 것은 어떨까?누군가(즉, 기사의 정기 편집자)가 일련의 변경사항, 특히 일부 다른 실질적인 변경사항을 수반하는 것으로만 승인된 변경사항에 동의하지 않는 경우, 그들은 어떻게 하는가?중립적 변화와 가시적 변화 중 하나의 좋은 부분을 보존하면서 디프의 큰 개별적 변화 집합 중에서 그들이 동의하지 않는 변화만을 분류해야 할 책임이 그들에게 있는가?아니면 그들이 모든 것을 되돌릴 수 있을까?모든 것을 "커뮤니티 승인 업무, 토크 페이지에서 구체적인 문제를 논의하라"로 되돌릴 수 있는가.이것은 조만간 나올 것이다.자신의 질문을 모호하게 하지 않기 위해서, 그것은 별도의 고려가 필요하다.프라나맥스 (대화) 02:14, 2011년 10월 27일 (UTC)[응답]

• 음, 우리끼리 엉켜있는 혼란이라는 걸 인정해야 해, 안 그래?이 모든 것의 중심은 Δ이다, 그렇지 않은가?그러므로 쉬운 길을 가자; Δ를 금지하고 그것을 끝내자.더 이상 논쟁도, 걱정도, 끝없는 실타래도 없다.멋지고 깔끔하고 편리하다. --Hammersoft (대화) 12:47, 2011년 10월 27일 (UTC)[응답]

아니, 중심은 가능한 한 빨리 위키가 무엇이 되어야 하는지에 대한 그들 자신의 생각에 부합하도록 만드는 코드 지원 편집을 하고 싶은 베타의 끊임없는 욕망이다.항상 그래왔다.의사소통의 부족한 스타일은 오직 하나의 요인이 될 뿐이다. 왜냐하면 불가피한 오류들이 빠른 속도에 곱하기 때문에, 질문이 여러 개 길어지고, 질문이 길어지게 되는데, 그것은 베타가 필연적으로 스냅하는 것이기 때문이다.프라나맥스 (대화) 21:43, 2011년 10월 27일 (UTC)[응답]

사실, 나는 사용자가 이슈를 제기하기 위해 내 토크 페이지에 온다면 좀처럼 딱딱 소리를 내지 않는다.나는 그 사람이 듣지 않고, 내가 그들에게 읽으라고 하는 것을 읽지 않고, 계속해서 나를 인신공격하거나 모욕하는 경우를 반복한 후에야 누군가에게 키가 작아진다.너무 세게 밀면 누구나 딱딱 부러진다.나는 너무 멀리 밀리지 않는 한 딱딱거리는 소리를 내지 않는다.ΔT 02:08, 2011년 10월 28일 (UTC)[응답]

• 물론 모두 Δ의 잘못이다.그러니 다시 한 번 말하지만, 왜 그냥 프로젝트에서 그를 금지하고 끝내지 않을까? --Hammersoft (대화) 02:04, 2011년 10월 28일 (UTC)[응답]

수동 대 자동

Δ는 저장하기 전에 8000여 개 정도의 정리 편집 내용을 모두 확인했으며, 봇과 같은 방식으로(즉, 확인하지 않고 단순히 "저장"을 밀어넣는 것이 아니라) 만들어지지 않았다고 주장한다.이런 편집의 속도와 그 편집이 만들어 내는 거대한 차이를 본 사람이라면 누구나 이것에 대해 의구심을 가질 수 있겠지만, 결국 우리가 확인해야 할 것은 이러한 편집의 실제 결과뿐이다.9월 말에, 나는 이 정리 편집본을 여러 번 확인했는데, 그 수정사항에서 꽤 많은 오류가 발생할 수 있었다.[5][6] 이것들은 대부분 그 후의 대본에서 수정되었지만, 나에게 이러한 편집이 실제로 수동으로 확인되지는 않았음을 제안하라.다른 정리 편집의 작은 무작위 샘플을 보면 예를 들어, 맨 URL이 "Yasni-Ergebnis für http://northtexan.unt.edu/content/nathan-kelly"이라는 설명이 주어지는 것을 알 수 있다.이것이 독일어로 되어 있다는 사실은 (아마도) Δ라는 사용자 선호도에 기인한다. 내가 같은 링크를 네덜란드어로 체크하면, 그리고 여러분 대부분은 영어로 되어 있을 것이다.수동 확인과 편집은 이것을 보고 수정했을 것이다.맨 링크가 (같은 편집에서) '책, 할인책, 싼 책, 호주 서점 - 엠포리움 책' 같은 홍보 제목 페이지보다 낫지 않은지도 궁금할 수 있다.제안된 과제 13에서 고려해야 할 사항인가?이 차이에서, 어떤 알 수 없는 이유로 인용 웹 템플릿이 베어 링크 플러스 제목에 의해 대체되고, 결과적으로 액세스 날짜와 프로모션 제목이 손실되어 ^ "photoquotations.com"을 참조하십시오.2010년 12월 29일 검색됨. to ^ photoquotations.com 세계 최대 사진 인용 자료 참조.별로 나아진게 없는데...제목이 이미 존재함에도 불구하고 베어 링크에 제목을 추가하는 예다.봇은 이것을 감지할 수 없다. 인간은 이것을 감지해야 한다. (예를 들어, 그것은 변한다.<ref>[http://www.uuchurch.org/history/middle-years]"중년"(2011년 3월).</ref> . to <ref>[http://www.uuchurch.org/history/middle-years 중년의대 단위교회]'중년'(2011년 3월)</ref> ).

6개의 수정사항을 확인했고, 3개의 수정사항은 문제가 있었다.대체로 이런 것들은 철저한 인간 견제의 흔적은 아니며, 8000여 건의 모든 편집 코멘트를 문제없이, 모두 인간에 의해 확인되고, 조금은 설득력이 떨어진다.프람 (토크) 08:05, 2011년 10월 26일 (UTC)[응답]

• 페이지 제목에 대한 검색이 있는 것 같네?검증이 이뤄지지 않는다면 그것은 확실한 문제가 될 수 있다.그러나 어떤 페이지를 보고 어떤 페이지가 제목을 직접 가져갔는지 수정 없이 검토하기는 매우 어려울 것이다.그것 없이는 오류율을 확인하기 어렵다.하지만, 내가 말했듯이, 평론 없이 맨 타이틀을 가져가는 것은 문제가 있어.그런데, 내가 확인한 당신의 한 편집본(이 섹션에 있는 당신의 게시물)에 오류가 있었다.나는 "fould"가 단어라고 생각하지 않는다.흠. 1개의 편집 선택됨, 1개의 오류가 발견됨100% 고장률?와우. 내 표본크기에 문제가 있거나 적어도 네 표본크기와는 다른 문제는 없을 거야:) (유머, 유머. --해머소프트 (대화) 17:41, 2011년 10월 26일 (UTC)[응답]
  • 유머에는 문제가 없지만 타이핑의 오류는 정상이다(그리고 나는 내 기사 편집보다 더 적게 나의 토크 페이지 게시물을 체크한다), 스크립트의 오류는 많은 편집과 페이지에 반복된다.그렇다고 해서 가끔 발생하는 오류를 예상해서는 안 된다는 뜻은 아니지만, 오류율은 매우 낮아야 한다.내가 9월 말에 적은 수의 정리 수정 사항을 확인했을 때 많은 종류의 오류를 확인할 수 있었던 것은 정상이 아니다.이러한 오류의 대부분은 스크립트를 테스트할 때, 그리고 그렇지 않다면 영향을 받는 페이지를 확인할 때 발견되어서는 안 된다.프람 (토크) 2011년 10월 26일 19:42 (UTC)[응답]
• 그런데, 인간은 실수를 하기 쉽다.Δ의 기준을 어디에 설정하고 성과를 어떻게 평가해야 하는가? --Hammersoft (토크) 17:43, 2011년 10월 26일 (UTC)[응답]
  • 이런 이슈들은 빈손으로 존재하는 것이 아니고, 델타가 20여 가지 넓은 경우에 자신의 제한을 초과할 정도로 경험하고 조심스럽다고 단숨에 주장할 수는 없으며, 다음 순간 그가 착각하기 쉽다고 말하여 "책, 할인책, 싸구려 책, 호주 서점 - 엠포륨 북스"는 주의깊고 주의깊게 주의를 기울였다.편집 제한에 의해 요구되는 대로 수동으로 검토된 편집물론, 인간은 실수를 한다.그러나 대부분의 인간은 그렇게 많은 실수를 하지 않아 엄격한 편집 제한을 받고 있다.만약 델타가 의무적이고 주의깊고 수동적인 검토에 의해 그렇게 하도록 강요받았을 때 조차도 그의 게임을 집어서 오류 없는 편집을 할 수 없다면, 만약 그의 제한이 풀린다면 비슷한 수준의 품질 관리를 적용할 수 있을 것이라고 지역사회는 어떤 믿음을 가질 수 있을까?테크노심비오시스 (대화) 22:13, 2011년 10월 26일 (UTC)[응답]

• 어느 누구도 영구적으로 오류 없는 편집을 할 수 없다.그런데 진공 철자를 잘못 쓰셨네요.게임 못 받아? --Hammersoft (대화) 12시 50분, 2011년 10월 27일 (UTC)[응답]

• 나는 확실히 할 수 있다.하지만 난 편집상의 제약이 없어델타는 영구적으로 오류 없는 편집을 할 필요가 없으며, 자신의 오류 볼륨(빈도가 아님)이 지역사회의 기대와 일치한다는 것을 증명할 때까지 오류 없는 편집을 할 필요가 있다.테크노심비오시스 (대화) 22:19, 2011년 10월 27일 (UTC)[응답]

• 그래, 영원히.이곳의 역사를 알고 있지?그런데 넌 완벽해?정말? --Hammersoft (대화) 02:05, 2011년 10월 28일 (UTC)[응답]

• "너희들 게임 못 주워?""난 확실히 할 수 있어."라고 해도 너무 혼란스럽진 않아, 해머소프트.테크노심비오시스 (대화) 03:00, 2011년 10월 28일 (UTC)[응답]

• 유머러스한 요점은 Δ가 그의 게임을 집어 들고 완벽해지라고 주장하지만, 진공상태의 철자를 제대로 쓸 수는 없다는 것이다.일반적인 믿음과는 달리, Δ _IS_인간.커뮤니티의 눈높이에서 자신을 재활하기 위해 완벽하다고 주장하는 것은 완전히 불합리하다. --Hammersoft (대화) 13:13, 2011년 10월 28일 (UTC)[응답]

• 델타는 인간이지만, 그가 편집한 것(또는 적어도 논의 중인 것)은 그것들을 살리는 것 이상의 인간의 입력은 없다.사람들이 텍스트를 입력할 때, 그들은 가끔 철자 오류를 범할 것이다.봇이나 스크립트가 편집을 할 때, 그들은 같은 오류를 반복해서 만들 것이다.누군가 콘텐츠를 추가하는 것의 이점은 일반적으로 그들이 가끔 하는 오타보다 훨씬 더 크다.델타(및 기타 봇)가 하는 대부분의 정화 작업의 이점은 너무 작아서 그 안에 있는 어떤 오류도 실제로 이전보다 기사를 더 나쁘게 만드는 경우가 많다.그래서 자동 편집이나 반자동 편집의 경우 수동, 내용 추가 편집의 경우보다 막대가 확실히 더 높은 것이다.프람 (토크) 13:24, 2011년 10월 28일 (UTC)[응답]

• 그럼 그가 할 수 있는 유일한 실수는 그가 직접 뭔가를 타이핑하는 거였단 거야?혹시 인간의 실수의 범위를 모르고 있는 건 아닐까?당신은 정의상 완벽할 수 없는 과정으로부터 여전히 완벽함을 기대하고 있다.당신이 요구하는 것은 불가능하고 불합리하다. --Hammersoft (대화) 13:27, 2011년 10월 28일 (UTC)[응답하라]

(참고, 철자 오류, 프램이라는 용어에 철자 오류를 범하는 것은 우스운 일이다.)계속 말해지고 있지만, 나는 그 반대의 증거가 없다는 것을 고백해야 한다(Δ - 음, 사실, 편집 과정을 거치면, 편집 요약이 '정리'이지만, 손으로 한 것이 분명하다), 여기의 일부 진술들 역시 찬성하는 증거가 없다.여기 프람의 말을 인용한다: "그들을 구하는 것 이상의 인간의 투입은 없다."이러한 편집 내용이 100% 스크립트로 작성된 것이 맞으십니까?Δ가 그것들을 거치지 않고, 특정한 것을 순응하거나 제거하고 나서 절약하고 있다는 증거가 있는가?Δ가 여기 저기서 '흠, 그건 옳지 않아'라고 생각하고, 저축을 하지 않거나, '오, 나도 그래야만 해, 금방 돌아올 거야'라고 생각한다는 증거가 있는가?죄송합니다, 스크립트가 사이트의 이름을 반환하는 경우 처음에 해당 이름이 잘못되었다고 생각하는 이유('사용자:위 검색창에 '프램'이 있는데, 어떤 이유로 내가 정확한 페이지에 도달했다고 생각하지 않을 수 있을까?그래, 우습게도 툴서버는 독일에 있어서 드물게 현지화된 독일어 버전을 돌려줄 수 있지만(이상한 사용자 선호도는 아님) 틀린 말은 아니다(그러나, 인정하지만, 최적의 것은 아니다).그러나 독일에서 호스팅되고 독일에서 링크되지만 en에 대한 참조 자료로 사용되는 문서들은 깨닫는다.위키피디아는 영어 버전이 없을 수도 있고, 독일어 버전만 있을 뿐이며, 그 문서들은 독일어 제목을 반환한다.그리고 독일어로 쓰여진 미국에 기반을 둔 문서들도 있을 것이고, 따라서 독일어 타이틀을 반환할 것이다.그는 '음, 웃긴, 독일어 제목, 음, 독일어를 읽을 수 있는 누군가가 참조를 추가했다'고 생각할 수도 있었다.독일에 기반을 둔 위키피디아는 실제로 독일어 버전을 사용하여 영어로 텍스트를 작성하고 참조를 추가했다.그래서 나는 동의한다, 이것은 발견될 수 있었고, 아마도 발견되었어야 했다.그러나 그것은 영원한 실수는 아니다. 너무 노골적으로 잘못되어 보여지고 각색되어야 하는 것이다.그렇다, 편집에는 항상 차선책이 있을 것이다. 그리고 나는 또한 명백한 실수들을 피할 수 있다는 것에 동의한다. 심지어 일이 너무 잘못되어 페이지가 깨지는 경우도 있다.그렇다, 우리는 높은 기대를 가져야 한다 - 그리고 나도 Δ에 대해 높은 기대를 가지고 있다 - 하지만 100% 오류가 없는 것은 아니다.

이런 편집이 완전히 자동화돼 있고, 체크되지 않았다는 회답 발언도 마찬가지다.비록 Δ가 그의 편집을 완전히 자동화하고 있지 않다는 증거는 없지만 - 그 반대에도 증거가 없다 - 단지 그것이 여기 저기 있을지도 모른다는 암시일 뿐이다.10개 모두가 20페이지 분산을 제공하는 매우 짧은 버스트에 10개의 편집이 있다고 생각하면 된다. 그러나 '열림 10페이지 - 체크 10페이지 - 복사-붙여넣기 - 요약 10페이지 - 저장 10페이지' 탭 검색으로 여전히 가능하다. 그러면 10개의 편집이 모두 철저히 확인되는 동안 저장은 극히 짧은 버스트에 있을 것이다(그리고 나는 그렇게 편집한다).때때로.그리고 내가 말했듯이, '정리' 편집 요약본으로도 분명히 수동적인 편집본들이 있다. 나에게 Δ는 모든 것이 괜찮은지, 변한 것은 없는지, 괜찮은지 확인하기 위해 스크립트를 실행했지만, 추가해야 할 다른 것을 보았고, 그 후에 그는 그렇게 했다.

나는 Δ가 페이지를 즉시 깨트리는 문제를 해결하기를 기대한다(또는 페이지를 저장하는 것을 엄격히 피함), 그리고 그것이 피할 수 있는 실수(링크 제목, null-edits)를 줄 때 합리적인 답변/토론을 기대한다.또한 어떤 것이 경고를 받은 후 추가적인 주의(스팸 링크 제목, null-edits)가 주어지는 차선적인 결과를 가져올 수 있기를 기대한다. --Dirk Beetstra 14:25, 2011년 10월 28일 (UTC)[응답]

해머소프트에 대한 답장으로, 내가 저지른 철자 실수와 델타의 실수의 비교를 끌어내어 오류를 규명하려는 당신의 시도는 불분명하다.나는 자동화된 과정이나 반자동화된 과정을 사용하지 않기 때문에 실수를 하면 한 번의 편집에 영향을 준다.델타가 실수를 하면 많은 편집에 영향을 주는 경향이 있고, 다른 사람들의 수리에 훨씬 더 많은 노력이 필요하다.그 둘 사이에는 비교가 안 된다.그리고 내가 말했듯이, 나는 편집 제한을 받지 않는다.만약 내가 그랬다면, 나는 사람들이 내가 편집한 종류의 것에 대해 엄격해지는 것에 문제가 없을 것이고, 나는 내 편집에 대해 두 배나 세 배의 정밀 조사를 하는 것에 문제가 없을 것이다.만약 내가 제한을 받는 동안 편집 품질에 대한 기준을 높일 수 있다는 것을 보여줄 수 없다면, 나는 그러한 제한이 풀릴 것이라고 합리적으로 기대할 수 없다.여기 델타에서 나 자신보다 더 많은 것을 기대하지 않는다.테크노심비오시스 (대화) 23:32, 2011년 10월 31일 (UTC)[응답]

Δ 제안 과제 #1

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [7]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 삭제된 영상에 대한 링크(예: diff의 첫 번째 줄)를 제거하기 위해 기사의 편집을 수행할 수 있다.

Δ를 대신하여 --Hammersoft (대화) 17:28, 2011년 10월 24일 (UTC)

• 주석 델타가 이와 같이 매우 많은 수의 편집을 시작하려고 할 경우 "(정리)"보다 더 많은 내용을 보여주는 편집 요약이 유용할 것이다.나는 또한 델타가 스스로 그 요청을 한다면 더 기쁠 것이다. -- 여기서의 과정의 일부는 델타의 태도를 개혁하는 것으로 되어 있기 때문에, 그는 지역 사회와 먼저 상의하고 -- 그리고 그가 프로젝트를 편집하기 전에, 불행히도 너무 많은 시간 동안 수레바퀴가 떨어져서 그런 논의를 가치 있게 생각한다는 것을 보여준다.과거제힐드 (토크) 2011년 10월 24일 (UTC) 17:57 [응답]

• 위의 해당 섹션에서 이러한 요청에 대한 메타 논의를 계속하십시오.특별히 이런 종류의 편집에 이의가 있으십니까? --Hammersoft (대화) 18:16, 2011년 10월 24일 (UTC)[응답]
• 안돼! 베타가 죽은 링크를 제거할 수 있다면 이 프로젝트에 어떤 악마가 닥칠까...그래, 빈정거림 모드 꺼.분명히, 나는 이 제안을 지지한다. 나는 우리가 무엇이 이슈화되지 않아야 하는지에 대해 토론하는데 시간을 낭비해야 한다는 것이 놀랍다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 24일 (UTC)[응답]

두 문제. 1.이것은 손으로 하는 것이 아니라 봇으로 하는 것이 좋지 않을까? 2. 비판을 덜 받는 또 다른 봇 운영자가 아니라 (최근에 일부 다른 영상 관련 작업[8]에서 금지된) 베타에게 이 작업을 수행하게 하는 것이 왜 유용한가?— 칼 (CBM · talk) 18:35, 2011년 10월 24일 (UTC)[응답]

• (1) 인간이 하면 안 되는 이유가 있는가? (2) 당신이 언급하는 제재는 자유롭지 않은 이미지와 관계가 있다.이 요청은 무료가 아닌 이미지와는 아무런 관련이 없다.Δ는 봇이 아니며, 이것은 봇을 운용해 달라는 요청이 아니라는 점을 명확히 할 필요가 있다고 생각한다. --Hammersoft (대화) 18:38, 2011년 10월 24일 (UTC)[응답]
  • 베타가 추가적인 아르브콤 움직임에서 벗어나려고 한다면, 이미지 관련 정리는 완전히 피하는 것이 좋을 것이다.더욱이 NFCC의 이유로 이미지를 삭제한 후 베타가 이미지 링크를 제거하면 이 작업은 무상으로 이미지 유지보수를 하는 분위기가 있다.나는 그가 봇이 아니라는 것에 동의한다. 하지만 왜 그가 특별히 다른 사람이나 봇과 비교해서 이 일을 해야 하는가?— 칼 (CBM · talk) 18:43, 2011년 10월 24일 (UTC)[응답]

• 그럼 ArbCom이 제재를 가한 걸 확대해서 이미지와 관련된 걸 포함하는 겁니까?이러한 확장에 대한 ArbCom 승인이 있으십니까?만약 Δ가 편집을 할 것이기 때문에 편집에 반대한다면, 그냥 프로젝트에서 그를 금지시켜 달라는 요청을 하는 게 어때?당신이 이 모든 제안에 반대하는 것은 어쨌든 그가 편집하는 것을 막고 있다. --Hammersoft (대화) 18:45, 2011년 10월 24일 (UTC)[응답]
  • Arbcom 모션은 "광범위하게 해석"된 비자유 영상 집행만 다룬다.그러나 나는 이미지 관련 작업을 전적으로 피하는 것이 베타에게 이익이 된다고 생각한다.나는 그의 편집 능력을 지지한다. 나는 금지 명령을 요구하는 것이 아니다.그러나 나는 왜 그가 그의 최근의 Arbcom 움직임으로 볼 때 이 시간에 이런 종류의 편집을 수행할 수 있는 특별한 허가를 받아야 하는지에 대해 설득력 있는 주장을 보지 않는다.— 칼 (CBM · talk) 18:50, 2011년 10월 24일 (UTC)[응답]

• 그가 편집해야 할 설득력 있는 이유가 보이나? --Hammersoft (대화) 18:51, 2011년 10월 24일 (UTC)[응답하라]

• 수정하여 지지하십시오.음, 나는 델타가 완전히 이미지로부터 멀리하는 것이 (특히 위키피디아에 비추어 볼 때론) 칼이 옳다고 생각한다.중재 요청/베타코만드_2) 그러나 한편으로 나는 그가 이미 삭제된 이미지를 대량으로 제거하지 못할 이유가 없다고 생각할 수 있다.나는 이것이 제한 요인이 될 것이라고 생각하므로 다음과 같은 단어를 다시 제안하고 싶다.

Δ는 삭제된 영상에 대한 링크를 제거하기 위해 논문의 비논쟁적 편집을 수행할 수 있다. 이는 NFCC 집행 활동이나 현재 지역사회 논의가 진행 중인 이미지의 링크("커뮤니티 토론" 광범위하게 해석되고 있다.) --트리스테사(talk) 02:22, 2011년 10월 25일 (UTC)[응답]로 확장되지는 않는다.

• 수정버전 Fram (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 수정된 버전이 문제를 일으키는 것 같아.델타는 거의 자동화된 방식으로 이러한 작업을 수행하고 있으며 변화에 거의 관심을 보이지 않고 있다.그가 정확한 이슈를 눈치채지 못하고 다시 막힐 것 같다.나는 델타의 열렬한 팬은 아니지만, 그를 위해 특히 이미지를 짜내서 효과적으로 "덫"을 놓을 이유가 없다고 본다.해머소프트, 어떻게 생각해?어쨌든 나는 그의 편집 제한에 너무 가까운 스케이팅으로 수정되지 않은 버전에 반대한다.호빗(토크) 10시 19분, 2011년 10월 25일 (UTC)[응답]
• 논쟁의 여지가 없는?이러한 논의에는 Δ가 하는 모든 것이 논쟁거리라고 생각하는 사람들이 있다.그것은 노골적으로 주관적인 용어로, 만일 그가 이런 타입의 편집을 한다면 그를 맹비난할 때 쓰일 것이다. --Hammersoft (토크) 13:46, 2011년 10월 25일 (UTC)[응답]
• 반대. diff를 볼 때 이미지가 삭제된 것이 분명하지 않으며, 편집 요약에서는 해당 이미지가 삭제된 이유를 설명하지 않는다.또한, 경우에 따라서는 이미지 파일의 이름이 후속 편집자가 이미지의 내용을 파악하고 기사를 개선하는 대체 이미지를 찾는 데 도움이 될 수도 있다.Jc3s5h (대화) 15:04, 2011년 10월 25일 (UTC)[응답]

• 지원. --Dirk Beetstra 15:09, 2011년 10월 25일 (UTC)[응답]
• Δ가 사소한 교체가 가능한지 확인하기 위해 점검하지 않는 한 반대한다. --SarekOfVulcan (대화) 15:32, 2011년 10월 25일 (UTC)[응답]
• 트리스테사의 수정된 버전에 대한 조건부 지원. 단, Δ가 사소한 교체를 확인하고 유용한 편집 요약을 제공한다.– 루나 산틴 (토크) 22:25, 2011년 10월 25일 (UTC)[응답]
• 와아에이는 모든 베타 드라마의 원래 연결점에 너무 가까이 있다.커뮤니티는 단순히 베타가 이미지에 대한 링크를 제거할 것이라고 믿지 않는다.그에게 집단적으로 그렇게 하도록 허용하는 것은 단지 문제를 자초하는 것이다.하늘은 거의 확실히 무너지지 않을 것이다. 만약 이것이 우리 나머지에게 맡겨져야 한다면 말이다.Chris Cunningham (사용자:thumperward) - 토크 14:10, 2011년 10월 26일 (UTC)[응답]
  • 그것과 관련된 ArbCom 제한사항이 따로 있는 것 같구나(NFCC 이미지).나는 지역 사회가 ArbCom과 상의 없이 그들을 무시할지 잘 모르겠다. 그것은 그들을 해고하는 것과 같다.그러므로, 나는 당신이 옳다고 생각한다. Δ가 이 특정한 과제에 대한 승인을 받기 전에 와 협의해야 한다.Uʔ (대화) 2011년 10월 26일 16:56 (UTC)[응답]
• 참고: 위키백과:RFAR#설명 요청: Δ. U u (대화) 18:08, 2011년 10월 26일 (UTC)[응답]
• 3번 과제에서 나의 주장에 따라 반대하라.델타의 편집 제한조치에 구멍을 내려는 이러한 시도들은 그러한 제한조치의 의도와는 맞지 않으며, 델타가 현재 상태로는 그의 제한조항 내에서 일할 수 있다는 것을 증명하기 전까지는, 나는 그들을 완화할 이유가 없다고 본다.테크노심비오시스 (대화) 00:17, 2011년 11월 1일 (UTC)[응답]
• 테크노심비오시스당 반대한다.게다가 이런 일을 하는 봇도 이미 있지 않은가.칼다리 (대화) 06:25, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #2

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [9]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 원래 포인터가 리디렉션된 템플릿에 대한 링크를 변경하기 위해 기사를 편집할 수 있으며, 수정된 포인터는 리디렉션이 가리키는 템플릿(예: diff의 첫 번째 줄)에 대한 링크를 변경할 수 있다.

Δ를 대신하여 --Hammersoft (대화) 17:28, 2011년 10월 24일 (UTC)

다른 유효한 편집을 해야 하고 리디렉션이 다른 편집과 결합하여 해결된다면 문제가 없다고 보지만 리디렉션 해결은 보통 자체 편집으로 할 가치가 없어 보인다.리디렉션을 해결해야 하는 다른 이유가 있는가?김메투(토크) 17:39, 2011년 10월 24일 (UTC)[응답]

특히 WP:NOTBRANNT BRACKED, 베타가 이를 위해 대규모 작업을 실행하는 것이 적절한 이유는 무엇인가?당신의 요청에는 그가 다른 일을 해야 한다는 요구사항이 없기 때문에 당신은 그가 수천 개의 기사에 대해 이것과 이것만을 할 수 있도록 허락을 구하는 것이다.— 칼 (CBM · talk) 18:29, 2011년 10월 24일 (UTC)[응답]

• 그럼 나한테 뭘 하라고? 모든 걸 하나의 거대한 요청으로 묶으라고?WP에 관하여:NOT BRANKED, 편집으로 인해 어떤 위해가 발생되고 있는가?지금 허용해야 할 이유가 있는가? --Hammersoft (대화) 18:34, 2011년 10월 24일 (UTC)[응답]
  • 우리는 일반적으로 이런 종류의 대규모 변경을 봇에 의해 허용하지 않으며, AWB 사용자들은 이런 종류의 "일반적인 수정"을 하기 전에 더 중요한 편집을 해야 한다.베타가 왜 다른 변경을 하지 않고 많은 수의 기사로 변경해야 하는지는 명확하지 않다.— 칼 (CBM · talk) 18:40, 2011년 10월 24일 (UTC)[응답]

• 좋아! AWB를 사용하거나 봇이 대신 하지 않는 한 이런 종류의 편집을 금지하는 지침/정책을 나에게 지적해 줄 수 있니?이 작업에 대해 봇이나 AWB 사용자가 해야 한다고 생각하는 것 외에 특별한 이의가 있으십니까? --Hammersoft (대화) 18:44, 2011년 10월 24일 (UTC)[응답]

Carl은 "고장되지 않은 리디렉션에 대한 링크를 "수정"하지 마십시오"라는 가이드라인에 연결했다.이것은 모두를 위한 것이다.이러한 리디렉션을 해결해야 하는 이유"이들은 리디렉션" 이외의 다른 이유가 없다면, 다른 편집과 함께 하는 것을 제외하고 수행되어서는 안 된다.김메투(토크) 18:49, 2011년 10월 24일 (UTC)[응답]

• 그럴 만도 하다.그렇다면, 이런 종류의 편집을 다른 승인된 편집과 함께 하는 것이 괜찮다는 것에 동의하는가? --Hammersoft (대화) 18:51, 2011년 10월 24일 (UTC)[응답]

• 괜찮은 것 같아, 이미 AWB가 그렇게 해서 선례가 있어.— 칼 (CBM · talk) 18:57, 2011년 10월 24일 (UTC)[응답]

• Δ가 유용한 편집 요약을 제공하는 경우, 이 스레드에 설명된 대로 지원한다.– 루나 산틴 (토크) 22:27, 2011년 10월 25일 (UTC)[응답]

일반적으로 템플릿으로 리디렉션을 해결하는 것이 다른 비교 편집과 "함께" 수행되는 한, 나는 정말로 반대하지는 않지만, 특정 경우에 템플릿으로 리디렉션을 고아화하는 것에 대한 반대 의견이 있을 수 있다는 것을 알고, 이 작업이 비판을 받을 수 있다.김메투(토크) 19:04, 2011년 10월 24일 (UTC)[응답]

• 지원 - 전혀 논란이 되지 않는다. --트리스테사 (대화) 02:24, 2011년 10월 25일 (UTC) 위의 의견을 고려하여 지원 버전으로 변경(그렇지 않으면 논쟁의 여지가 없는 것으로 생각됨):[답답하다]

Δ는 원래 포인터가 리디렉션된 템플릿에 대한 링크를 변경하기 위해 기사를 편집할 수 있으며, 수정된 포인터는 커뮤니티 합의로 별칭이 계속 사용되어야 한다는 것을 나타낼 수 있는 상황을 제외하고 리디렉션된 템플릿에 대한 것이다. --트리스테사 (talk) 02:30, 2011년 10월 25일 (UTC)[응답]

• 반대, 예측할 수 없는 이익.해머소프트, 당신은 '편집으로 인해 어떤 해악이 일어나고 있는지'를 물었다.나는 위키피디아의 편집을 위한 문턱이 '편집으로 인한 이득'이라고 주장할 것이다.답이 '없음'이라면 편집을 해서는 안 된다.테크노심비오시스 (대화) 05:01, 2011년 10월 25일 (UTC)[응답]

• 작업 3의 내 인수도 참조하십시오.델타의 편집 제한조치에 구멍을 내려는 이러한 시도들은 그러한 제한조치의 의도와는 맞지 않으며, 델타가 현재 상태로는 그의 제한조항 내에서 일할 수 있다는 것을 증명하기 전까지는, 나는 그들을 완화할 이유가 없다고 본다.테크노심비오시스 (대화) 00:18, 2011년 11월 1일 (UTC)[응답]

• 그대로 반대하라.AWB에 대해 합의된 대로 교체만 할 경우 지원할 수 있다(Wikipedia:AutoWikiBrowser/Template redirections)가 수행되며, 모든 AWB 사용자에게 허용된다면 여기서 허용하지 않는 것은 의미가 없다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]

그런 다음 다음 다음을 변경하십시오.

Δ는 원래 포인터가 리디렉션된 템플릿에 대한 링크를 변경하기 위해 기사를 편집할 수 있으며, 수정된 포인터는 AWB의 현재 버전에서도 변경된 템플릿을 리디렉션이 가리키는 템플릿에 대한 것이다(예: diff의 첫 번째 줄).

그렇지 않으면 이것은 '마지막 100 편집에서 26개의 템플릿을 변경했다'라는 지경에 이르게 될 것이고, 그렇지 않다면, '마지막 100 편집 중에 26개의 이미지를 삭제했다'는 패턴도 아니다 - 분명히 내 버전을 뒷받침한다. --Dirk Beetstra 15:12, 2011년 10월 25일 (UTC)[응답]

• NOTBRANK에 반대하며, 베타 자신의 코멘트를 검사하는 것은 이 작업의 이점을 무료 이미지를 사용하는 템플릿을 추적하는 것으로 본다는 것을 보여준다.베타는 비자유 이미지 작업에서 금지된 주제다.프라나맥스 (대화) 2011년 10월 25일 (UTC) 17:46[응답]

• 나는 {{Fact}}} 그 코멘트를 해야겠다.나는 이 작업을 근거리 무선 통신 문제에 사용한 적이 없다. 이 작업은 Wikitext를 단순화하고 템플리트를 사용하기 쉽게 만드는 데만 사용된다.ΔT _{^{The only constant}}

• 지지하다.이것은 내가 아는 한 프로젝트 EOT에 이롭다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• WP:NOTBRANK은 이것을 구체적으로 다루고 있다.지옥이 얼어붙어 WP:NOTBRANN은 더 이상 지역사회의 공감대가 없다고 선언된다. 진짜 봇은 이것을 쉽게 할 수 있다.Chris Cunningham (사용자:thumperward) - 토크 14:36, 2011년 10월 26일 (UTC)[응답]
• NOTRENT NOTRENT. 카라낙스 (대화) 16:24, 2011년 10월 28일 (UTC)[응답하라]
• 반대해 이건 무의미한 작업인 것 같아.리디렉션이 고장나지 않았다면 왜 고쳤을까?칼다리 (대화) 06:27, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #3

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [10]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 외부 링크를 인포박스에 이미지를 포함하려는 시도가 실패한 경우(예: diff의 첫 번째 줄)에 대한 편집을 수행할 수 있다.

Δ를 대신하여 --Hammersoft (대화) 17:28, 2011년 10월 24일 (UTC)

일반적으로 이것은 괜찮지만 최적의 것은 아니다.종종 이러한 외부 링크는 누군가가 허용 가능한 이미지를 대체하려고 시도했기 때문에 존재한다.외부 링크를 제거하기만 하면 이미지가 없는 페이지가 남는다.이런 종류의 편집은 편집 이력을 검사하는 사람이 더 잘한다.김메투(토크) 2011년 10월 24일 19:11 (UTC)[응답]

• 사실, 일반적인 믿음과는 반대로 Δ는 인간이다 :) --햄머소프트 (대화) 19:39, 2011년 10월 24일 (UTC)[응답]

당연하다.델타가 편집 이력을 보고 가장 최근에 사용된 삭제되지 않은 이미지를 찾아 복원할 것인가?심지어 대본도 쓸 수 있어김메투 (토크)20:02, 2011년 10월 24일 (UTC)[응답]

• 지원된 수정본은 충분히 검토됨. --트리스테사 (토크) 02:31, 2011년 10월 25일 (UTC)[응답]
• 제공된 지원 서비스 델타는 그의 다른 제한사항(자동화된 편집사항이나 편집사항 없음, 각 편집사항에 대한 수동, 주의, 개별 검토)을 계속 준수한다.테크노심비오시스 (대화) 05:03, 2011년 10월 25일 (UTC)[응답]

• 이 전체 텍스트 벽의 다른 곳에서 토론할 때마다 반대하십시오.해머소프트는 델타가 편지에 대한 존중도, 현재의 편집 제한사항의 정신도 가지고 있지 않으며, 공동체의 눈으로 자신을 되찾기 위해 자신의 제한 내에서 일할 의사가 없다고 나를 성공적으로 설득했다.대신에 모든 과정은 그가 과거의 실수를 고칠 수 있을 것이라는 확신도 없고 심지어 그가 실수를 했고 지역사회가 이것을 문제점으로 발견했다는 인정도 없이 그의 제한을 약화시키고 제거하려고 시도했다.나는 그가 지역사회에 대한 진정한 이해와 진정한 존중을 보여주고, 그의 현재 한계 내에서 자신을 되찾기 위한 조치를 취하기 전까지 그의 편집 특권의 증대에 반대한다.테크노심비오시스 (대화) 00:13, 2011년 11월 1일 (UTC)[응답]

• 지지하다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 막무가내 신인이 공식적인 변경 후 회사의 인포박스 로고를 업데이트하려고 하는 경우를 상상할 수 있지만, 새로운 사진을 업로드하는 대신, 신인이 거기에 외부 링크를 삽입한다.그 경우에는 되돌리는 것이 더 나을 것이다.반자동화 작업으로 최근 이력을 확인하지 않으면 아마도 자동으로 대화 페이지에 메시지를 남겨야 할 것이다.have mörser, 여행 (대화) 14:19, 2011년 10월 25일 (UTC)[응답]
• 외부 링크가 유효한 내부 링크를 대체하지 않았는지 Δ가 확인하지 않는 한 반대한다.--SerkOfVulcan (대화) 14:49, 2011년 10월 25일 (UTC)[응답]
• SarekOfVulcan이 14:49 UTC. Jc3s5h (대화) 15:09, 2011년 10월 25일 (UTC)[응답]에서 제안한 것과 동일한 제한으로 조건부 지원
• 지원 - 하지만 편집자에게 실제로 그 이미지를 얻는 방법을 설명하도록 하라. --Dirk Beetstra 15:14, 2011년 10월 25일 (UTC)[응답]
• 지지하다.이것은 프로젝트인 EOT에 이롭다. (그러나 SoV와 DB에 동의함). --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 14:49 UTC에서 제안된 SOV와 동일한 제한을 가진 조건부 지원, 그렇지 않으면 반대한다.Kimmetoo가 지적하듯이, 이것은 스크립트 기반 편집에는 적용할 수 없다.프라나맥스 (대화) 2011년 10월 25일 (UTC) 18:05 [응답]
• Δ가 유용한 편집 요약을 제공하는 경우, Framanax, Sarek, Kimmtoo당 조건부 지원.– 루나 산틴 (토크) 22:28, 2011년 10월 25일 (UTC)[응답]

Δ 제안 과제 #4

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [11]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 위키백과에 따라 기사의 카테고리 태그 아래에 존재하는 콘텐츠를 카테고리 태그 위의 위치로 이동하기 위한 편집을 수행할 수 있다.CAT#Categorizing_ 페이지.(1987, diff의 하단 부분)

Δ를 대신하여 --Hammersoft (대화) 17:29, 2011년 10월 24일 (UTC)

"내용"은 전적으로 템플리트를 의미하는가?김메투(토크) 17:42, 2011년 10월 24일 (UTC)[응답]

• 위에서 연계한 지시사항에 준하는 것으로 한정한다. --Hammersoft (대화) 17:46, 2011년 10월 24일 (UTC)[응답]

나는 샘플 디프가 가이드라인에서 어떻게 따르며, 이 작업이 어떻게 더 많은 사양 없이 자동화될 수 있는지 모르겠다.템플릿을 이동해야 하는 이유어떤 템플릿?더 자세한 내용 없이 나는 정말로 여기서 제안되고 있는 것이 무엇인지 모르겠다.김메투(토크) 17:58, 2011년 10월 24일 (UTC)[응답]

• 위키백과의 적절한 줄:CAT#Categorizing_ 페이지는 "관례에 따라 카테고리 선언이 위키텍스트의 끝에 배치되지만, 스텁 템플릿(그 자체가 카테고리를 초월함)과 언어 간 링크 앞에 배치된다."위의 전후 링크는 그것을 증명한다.작업이나 제안된 작업을 자동화해야 한다고 명시하지 않았다. --Hammersoft (대화) 18:17, 2011년 10월 24일 (UTC)[응답]
  • 우리는 일반적으로 AWB 사용자나 봇들이 이런 종류의 편집을 일괄적으로 하는 것을 허용하지 않는다.베타가 할 수 없을 때 자동으로 하는 것이 왜 적절한가?보통 우리는 페이지를 편집해야 할 더 중요한 이유가 있을 때만 이런 일들을 해야 한다고 말한다.— 칼 (CBM · talk) 18:27, 2011년 10월 24일 (UTC)[응답]

• 만약 그렇게 친절하다면, 내가 "자동"이라고 말한 곳이나 "자동"이라고 암시하는 곳을 표시해 주시겠습니까?감사합니다.편집을 수행하는 경우, 위키백과에서 다음과 같이 요청한다.CAT#Categorizing_ 페이지.이 가이드라인에서 상기 인용한 라인을 삭제해야 할까? --Hammersoft (대화) 18:35, 2011년 10월 24일 (UTC)[응답]
  • 베타에게 이것을 할 수 있는 허가가 주어진다면, 그는 대규모로 그것을 할 수 있는 허가가 있을 것이다.나는 왜 그것이 필요한지, 왜 그가 그것을 할 권한이 있어야 하는지에 대한 당신의 주장을 보지 않는다.필요하다면 AWB가 감당할 수 있다고 생각했을 것이다.— 칼 (CBM · talk) 18:37, 2011년 10월 24일 (UTC)[응답]

• 그가 그것을 할 수 없는 이유가 있니?위키피디아의 어떤 것도 "필요하다"는 것은 없다.사람들은 그들의 관심사에 따라 편집한다.아무도 어떤 것도 편집할 필요가 없다.그가 그러한 오류를 발견한다는 사실은 적어도 모든 AWB 사용자들이 이 오류의 모든 인스턴스를 발견하지는 못한다는 것을 보여준다.편집을 해 가이드라인에 따라 프로젝트를 돕고 있다.그가 그것을 할 수 없는 이유가 있을까? --Hammersoft (대화) 18:41, 2011년 10월 24일 (UTC)[응답하라]
  • 아마도 베타가 대규모 정비 작업을 할 수 있도록 특별 허가를 요청하는 것이라면, 베타가 그것을 해야 하는 설득력 있는 이유가 있어야 할 것이다.이 특정 작업은 봇이 할 수 있도록 승인되지 않을 것이다. 왜냐하면 기사의 하단을 재구성하는 것과 같은 사소한 유지 보수에만 대한 요청은 승인되지 않기 때문이다.나는 이 제안이 어떻게 다른 기준에서 충분히 다른지 확실하지 않다.편집할 기사를 선택하는 데 사용할 특별한 표준이 있는가?— 칼 (CBM · talk) 18:47, 2011년 10월 24일 (UTC)[응답]

• Δ가 여기서 편집해야 할 특별한 이유는 전혀 없다.왜 그냥 영구적으로 차단하지 않는 거지?나는 네가 아직 3번을 반대하지 않았다는 것을 주목한다.3번을 지지하십니까? --Hammersoft (대화) 18:49, 2011년 10월 24일 (UTC)[응답]

• 반대 - Carl에 따르면, 이러한 대규모 변화에 대한 더 넓고 구체적인 합의 없이 대규모로 이루어져야 한다는 확신이 서지 않는다; 이 업무는 또한 실수하기 쉽고, 적절한 편집 검토 없이 판도라의 상자 같은 것이다. --Tristessa (talk) 02:34, 2011년 10월 25일 (UTC)[응답하라.
• 반대, 이것은 케이스 바이 케이스(case-by-case) 단위로 해야 하는 일이고, 종종 고양이 아래에 추가되는 문자는 공공 기물 파괴 행위, 또는 토크 페이지에 속하는 댓글이다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]

• 지원 - 여기서는 sé당 자동 편집에 대해 말하는 것이 아니라 편집 패턴에 대해 이야기하고 있다.물론 반달리즘이라면 되돌릴 필요가 있지만, {ΔFilter를 따르고 반달리즘이 아닌 25개 기사에 도달하여 본문을 위로 옮기려면 확실히 그렇게 할 수 있어야 한다. --Dirk Beetstra 15:16, 2011년 10월 25일 (UTC)[응답]
• "우리는 여기서 sé당 자동화된 편집에 대해 말하는 것이 아니다"에 대해 반대한다.우리는 그래요.have mörser, 여행 (대화) 16:01, 2011년 10월 25일 (UTC)[응답]
  • 아니... 이것도 완전히 수동으로 할 수 있어. 스크립트로 작성된 것일 수도 있지만 자동화된 것은 아니야.Δ는 여전히 확인할 의무가 있다. --Dirk Beetstra 14:19, 2011년 10월 26일 (UTC)[응답]
• 댓글을 달다.대부분은 공공 기물 파손이지 전부가...사례별로 수행해야 하며, 파손될 가능성이 있는 텍스트를 본문으로 자동 이동시키는 것은 도움이 되지 않을 것이다._{Piotr Konieczny aka Prokonsul Piotrus talk to me} -- 2011년 10월 25일 (UTC)[응답]
  • 그것뿐만이 아니다.나는 AfC에서 ":"가 아닌 ";"를 사용하는 잘못된 형식의 범주를 본 적이 있다.일반적으로 사람들은 마지막에 시도하려는 것이 도대체 무엇인지 살펴볼 필요가 있다.have mörser, will talk (talk) 18:12, 2011년 10월 25일 (UTC)[응답하라]

• 내 모든 편집 내용은 저장하기 전에 수동으로 검토되고 나는 많은 문제를 확인하는데, 나는 종종 인터위키 스텁과 범주 아래에 참조 섹션이 추가되는 것을 본다.올바른 레이아웃은 카테고리, 스텁 템플릿, 그리고 마지막으로 인터위키 링크 입니다.ΔT 19:15, 2011년 10월 25일 (UTC)[응답]

  그렇게 말씀하시는데 어떤 증거가 있어야 우리가 뒷받침이 되는 겁니까?과거에는 편집 내용을 실제로 검증하지 않고 편집 내용을 승인하기 위해 "Y"를 두드리는 스크린샷을 제공했다고 한다(본적은 없지만, 오래된 AN/I 스레드를 떼어낸다). 몇 달 전에는 단순히 디프의 내용만 보고 되돌릴 때 페이지를 실제로 보고 있지 않음을 확인했었습니다(릴리).대화 또는 프로젝트 페이지에 실제 이미지가 아닌 이미지에 대한 링크를 삽입한 사람을 되돌리는 방법).WP:AGF는 맹목적인 방패가 아니다.--크로스미르 (토크) 07:33, 2011년 10월 26일 (UTC)[응답]

• 지원은 합리적인 것 같고 정리가 잘 된다. -- 지우개헤드1 <토크> 19:48, 2011년 10월 25일 (UTC)[응답]
• 이 작업은 칼 당 신속한 편집에 적합하지 않으며, 커뮤니티는 각각의 케이스에 대한 개인적인 감사에 대한 그의 보증을 Crossmr 당 받아들이기에 충분한 믿음을 가지고 있지 않다.Chris Cunningham (사용자:thumperward) - 토크 14:17, 2011년 10월 26일 (UTC)[응답]
  • 빠른가? 아직 10분동안 40개도 안남았어..그리고 확실히 모든 편집이 확인되어야 한다(Δ는 봇을 실행할 수 없고, 스크립트로 작성된 편집만 할 수 없다). --Dirk Beetstra^{T C} 14:20, 2011년 10월 26일 (UTC)[응답]
    • 10분 동안 매 15초마다 한 번 편집하는 것은 엄청나게 빠르다.특정 속도 제한은 성문화되어 있어서 1분에 4번 편집하는 것이 과학적으로 올바른 값이라고 판단했기 때문이 아니라, 그는 밝은 선을 가지고 있다.만약 우리가 일반 AWB 사용자들이 이 "과제"를 수행하도록 허용하지 않는다면, 베타명령에 대한 예외를 두는 것은 확실히 합리적이지 않다.Chris Cunningham (사용자:thumperward) - 토크 14:46, 2011년 10월 26일 (UTC)[응답]

Chris Cunningham에 반대하십시오.카라낙스 (대화) 16:28, 2011년 10월 28일 (UTC)[응답]

• 과제 #1과 #3에서 나의 주장에 따라 반대하라.테크노심비오시스 (토크) 00:20, 2011년 11월 1일 (UTC)[응답]
• 크리스 커닝엄;텍스트 온갖 종류의 범주(템플릿과 다른 유효한 편집;공공 토론에서 시도들, 경험 없는 사용자들의 다양한 도움이 되지 않는다는 것, &, 요리 등)아래와 각 경우에 그래서 끝 resu에 작은 관련된 단 하나의 변화의 속사포 같은 반복보다는 조금의 생각해야 할 일은 반대하다.lt.제대로 될 거라는 자신감이 부족하다. 보브레이너 (토크) 20:57, 2011년 11월 2일 (UTC)[응답하라]
  • 또한: 기사 하단에 있는 사물의 엄격한 순서(범주, 인터위키스, 스터브 템플릿, &c)는 단지 관습의 문제일 뿐 일반 독자들에게는 큰 차이가 없다.기사에서 실제 내용을 실제로 수정하지 않고 이것들을 고치려고 큰 노력을 하는 것은 무의미한 바쁜 일이라는 생각이 든다; 하지만 만약 징집된 Δ가 실제로 점심시간까지 울타리 기둥에서 참호를 파려고 자원하고 있다면, 내가 그들을 막을 이유는 없다. 부브레이너 (토크) 21:11, 2011년 11월 2일 (UTC)[응답]

Δ 제안 과제 #5

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [12]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 레이아웃을 수정하기 위한 스타일링이 적절한 경우 적절한 reflist 템플릿 파라미터를 적용하기 위해 편집을 수행할 수 있다.(각각: 전후)

Δ를 대신하여 --Hammersoft (대화) 17:29, 2011년 10월 24일 (UTC)

WP:CITEVAR을 참조하십시오.이런 식으로 자동적으로 많은 기사를 바꾸는 것은 누군가에게 좋지 않을 것이다.— 칼 (CBM · talk) 18:25, 2011년 10월 24일 (UTC)[응답]

• 그렇게 친절하게 대해 주신다면, 제가 "자동으로"라고 말한 곳을 지적해 주시겠습니까?감사합니다, --Hammersoft (대화) 18:35, 2011년 10월 24일 (UTC)[응답]
  • 베타가 이것을 요청해야 하는 유일한 이유는, 아마도 그의 "정리" 스크립트와 같은 자동화된 또는 반자동화된 도구를 사용하여 대규모로 그것을 할 계획이었다.AWB조차 이 일을 하지 않기 때문에 베타가 하는 것이 왜 적절한지 알 수 없다.— 칼 (CBM · talk) 18:38, 2011년 10월 24일 (UTC)[응답]

• 칼, 모든 요구에 반대할 거야?나는 여기서 패턴을 감지하고 점점 더 불안해지고 있다. 이것이 사실이라는 것을.구체적으로 이 요구에 대해서, 그가 그것을 할 수 없는 어떤 이유가 있는가?아니면 이것은 단지 Δ 편집의 세계적 예외인가, 마침표? --Hammersoft (대화) 18:42, 2011년 10월 24일 (UTC)[응답]
  • 나는 베타 편집을 지지하지만, 이것이 그가 해야 할 종류의 편집인 이유는 없다.— 칼 (CBM · talk) 18:44, 2011년 10월 24일 (UTC)[응답]

• 당신은 그가 하지 말아야 할 이유가 있는가; 이런 종류의 편집을 하는가, 아니면 단지 그 사람이라는 이유로 반대하는 것인가? --Hammersoft (대화) 18:46, 2011년 10월 24일 (UTC)[응답하라]
  • WP 때문에 이 특정 편집을 수행해서는 안 된다.CITEVAR.AWB조차 이러한 유형의 편집을 수행하지 않는다(참조 목록의 열 수 변경).— 칼 (CBM · talk) 18:48, 2011년 10월 24일 (UTC)[응답]
    • RefLinks는 많은 수의 참조를 감지할 경우 자동으로 열을 추가한다.알파_Quadrant 19:00, 2011년 10월 24일 (UTC)[응답]

• 반대 - 죄송합니다, 이 특정한 것은 손으로 직접 수행해야 하는데, 이는 자동화된/반자동 적용으로 인해 모든 종류의 오류와 예기치 못한 결과가 초래되는 경향이 있기 때문이다. 단, WP에 의해 도매로 변경되어서는 안 된다는 반론도 있다.CITEVAR. --트리스테사 (대화) 02:38, 2011년 10월 25일 (UTC)[응답]
• 트리스테사에 대항하라.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 반대, 이것은 자동화되어서는 안 된다. --SerkOfVulcan (대화) 14:53, 2011년 10월 25일 (UTC)[응답]

• 지원 - 여기서 sé당 자동 편집에 대해 말하는 것이 아니라, 언급된 상식과 함께 적용되어야 한다.연속해서 25가 될 수도 있고, 연속해서 25가 넘어도 상식, 매뉴얼, 개선을 허용하지 않을 이유가 없다고 본다. --Dirk Beetstra 15:18, 2011년 10월 25일 (UTC)[응답]
• "우리는 여기서 sé당 자동화된 편집에 대해 말하는 것이 아니다"에 대해 반대한다.위선적인 일을 그만둬라.have mörser, 여행 (대화) 15:57, 2011년 10월 25일 (UTC)[응답]
  • 위선?감사합니다, Have Mörser 여행 예정. --Dirk Beetstra 14:21, 2011년 10월 26일 (UTC)[응답]
• 반대 – 심지어 전/후의 예도 절름발이다.이후 누군가가 손으로 고쳤다.디클라이언 (대화) 2011년 10월 25일 17:21 (UTC)[응답]
• 지지하다.이것은 프로젝트에 이롭고, 베타 및 ref fixing에 대한 나의 경험은 상당히 긍정적이었다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} -- 18:03, 2011년 10월 25일 (UTC)[응답]
• 트리스테사에 대항하라.프라나맥스 (대화) 2011년 10월 25일 18:24 (UTC)[응답]

• 이것이 너무 자주 행해지지 않는다고 논평해라.참조가 8개 미만인 경우(그 소수의 참조에서 무의미한 경우) 다중 열만 제거하고, 참조가 30개 이상인 경우(물릿 컬럼이 실제로 효력을 발휘하게 되는 경우) 다중 열만 추가한다.그러니 그 점을 고려해 주십시요.ΔT 19:18, 2011년 10월 25일 (UTC)[응답]
  • 어떤 기사에 적용할 계획이니?리스트를 가지고 있는가, 아니면 그 기준에 맞는 모든 기사에 적용하자는 것인가?만약 그렇다면, 왜 봇은 합의만 있다면, 대신 할 수 없는 것일까?— 칼 (CBM · talk) 19:23, 2011년 10월 25일 (UTC)[응답]
    • 봇은 할 수 있지만, 그런 봇은 현재 할 수 없고, 그것은 아마도 승인을 받지 못할 것이다. 그것은 내가 다른 편집들과 결부시켜서 하는 아주 사소한 편집이고, 나는 필요에 따라 기사별로 그것을 한다.나는 단지 내 편집의 이 부분이 앞으로 블록이 가능한 패턴으로 여겨지지 않도록 승인을 구하는 중이다.ΔT 19:31, 2011년 10월 25일 (UTC)[응답]
  • 유용한 편집 요약을 사용할 경우 바로 여기에서 Δ의 설명을 지원하십시오.위의 설명(너무 모호함)을 강조하십시오.– 루나 산틴 (토크) 22:33, 2011년 10월 25일 (UTC)[응답]
• WP별 반대:CITEVAR.이것은 어디선가 어떤 편집자에게 문제를 일으키기 마련이고 위키피디아 전체와 비교했을 때 얼마나 특이한지에 상관없이 그들의 인용 스타일에 깊은 애착을 가진 편집자들이 있다.만약 당신이 위키피디아 경력을 망친다면, 당신은 당신의 위키피디아 경력을 위해 싸울 것이다.

또한 귀하가 제공한 예는 WP에 문서화되지 않은 형식으로 인용문을 추가했다.CITE도 그렇고 사실 좀 특이해서 봇이 엉뚱한 방향으로 기사를 옮길까 봐 걱정이다.연구 WP:CATE 및 관련 페이지(예: WP:각주,{{citation}},{{harvnb}}, 등) 효과 인용을 위한 자동 편집을 제안하기 전에. ---- CharlesGillingham (대화) 23:17, 2011년 10월 25일 (UTC)[응답]

• 봇이 아닌 임 한 명, 이 항목에 대한 불만이나 문제 제기 없이 이 gen fix로 8,000개 이상의 편집을 했다.ΔT 00:34, 2011년 10월 26일 (UTC)[응답]

• 미안해, 내가 처음 읽었을 때 디프트를 잘못 읽었어.그 변화는 얼핏 생각만큼 크지 않았다.이 요청은 단지 다음 항목을 변경/추가하기 위한 것인가? col=에{{reflist}}?그것만은 구체적으로 물어봐야 할 것 같은데, 만약 그것만이 당신이 만들어낼 변화라면..--- 찰스길링엄(토크) 02:43, 2011년 10월 26일 (UTC)[응답]

• WP별 반대:특히 CITEVAR, 그리고 과제 #1과 #3의 내 주장에 따르면 광범위하게.테크노심비오시스 (토크) 00:22, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #6

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따른 요청 시 그를 대신하여 운용할 것 [13]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 도움말에 따라 적절하게 백색 공간을 제거하기 위한 편집을 수행할 수 있다.공백. (iii, infobox에 영향을 미치는 확산의 첫 번째 부분)

Δ를 대신하여 --Hammersoft (대화) 20:50, 2011년 10월 24일 (UTC)

물론 Delta는 도움말에 설명된 공백 문제를 해결할 수 있다.백스페이스, 하지만 문제는 다양해서 내가 "패턴"을 형성할 것 같지는 않다.내가 뭘 빠트렸나요?문제의 차이와 당신의 설명은 별개의 문제인 줄 바꿈을 제거하는 것을 제안하는 것 같다; 그 차이에서 그들은 실제로 가시적인 공백을 만들어내지 못하고 있다.김메투(토크) 22:26, 2011년 10월 24일 (UTC)[응답]

• Δ는 이전에 흰색 공간을 제거하는 패턴적 편집을 수행한 혐의를 받았다.따라서, 이 요청. --Hammersoft (대화) 22:42, 2011년 10월 24일 (UTC)[응답]
  • 그러나 그것은 렌더링된 글에서 공백을 제거하기보다는 위키코드 내부의 공간을 제거하는 것을 언급하고 있었다.도움말을 참조:화이트스페이스는 전적으로 후자에 관한 것이다.— 칼 (CBM · talk) 01:18, 2011년 10월 25일 (UTC)[응답]

• 흰 공간에 대해 머리털을 쪼개고?그것이 이양된 것인가?그래서 이제 나는 다른 종류의 화이트 스페이스에 대해 요청을 해야 한다?첫째로, 하얀 공간은 패턴이고, 이제 우리는 어떤 종류의 하얀 공간을 묘사해야 하는가?그 칼날은 두 개의 가장자리가 있다. --Hammersoft (토크) 01:43, 2011년 10월 25일 (UTC)[응답하라]

• 도움말에 따른 조건부 지원:화이트스페이스(즉, 기사 공백)는 엄격하게 해석되거나, Δ가 이러한 가이드라인에 대한 변경을 제안하고, 규모에 따라 이 변경이 실행되도록 합의를 얻는다. --트리스테사 (토크) 02:43, 2011년 10월 25일 (UTC)[응답]
• 트리스테사 당 조건부 지원. 도움말:스페이스는 특히 기사 공백에 관한 것으로, 가능한 한 고쳐야 하는 나쁜 점이다. 연결된 디프는 종종 무해하고 많은 경우에 가독성을 향상시킬 수 있는 소스 공백과 더 관련이 있는 것처럼 보인다. 제재의 일부는 델타가 무차별적으로 대규모 변경을 하는 것과 관련이 있기 때문에, 나는 그가 편집한 내용이 도움말을 엄격히 준수하는 경우 이 프로젝트의 최선의 이익이 될 것이라고 확신할 수 없다.공백이 생기면 그것은 받아들일 수 있을 것 같다. 이 요청들 중 어떤 것과 마찬가지로, 나는 델타가 여전히 자동화된 편집이나 자동화된 것으로 보이는 편집을 수행할 수 없다는 것을 부드럽게 상기할 것이다. 그리고 이 제안의 승인이 델타에게 그러한 금지를 해제하지 않을 것이다.테크노심비오시스 (대화) 04:27, 2011년 10월 25일 (UTC)[응답]

• 과제 #1과 #3에서 나의 주장에 따라 반대하라.테크노심비오시스 (대화) 00:23, 2011년 11월 1일 (UTC)[응답]

• 이것의 실제 예가 주어질 때까지 반대하되, 위의 예가 공백을 제거하지 않는다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]

• 위와 같이, 우리는 흰 공간에 대해 갈라진 털로 진화했다?이런 얘기를 하고 있다니 말도 안 돼. --Hammersoft (대화) 12시 56분, 2011년 10월 25일 (UTC)[응답하라]

• • • 믿고 싶은 것은 무엇이든지 믿되, 요청된 작업의 예를 들면, 작업에 대한 설명과 주어진 예가 일치하는지 확인한다.나는 이 작업이 마치 그가 내부 섹션 헤더에서 공백을 제거할 수 있는 것처럼 읽히지 않기를 바란다.렌더링된 페이지를 변경하지 않고 몇 바이트의 공간만 제거하는 편집은 수행하지 마십시오(단, 하나의 추가 수정본인 경우 훨씬 더 많은 공간을 차지함).한 가지 선호하는 스타일을 다른 스타일보다 우선시하는 편집(예: 단면 헤더의 공백 또는 매개변수당 한 줄의 참조 대신 한 줄의 참조), 별표와 항목 사이에 공백을 추가하는 편집은 전혀 수행되지 않아야 한다.프람 (토크) 13:12, 2011년 10월 25일 (UTC)[응답]
• 요청이 diff와 일치하지 않기 때문에 절차상 반대.--SrekOfVulcan (대화) 14:59, 2011년 10월 25일 (UTC)[응답]
• 다른 변경사항이 페이지의 최종 표시에 중요한 영향을 미치는 편집의 일부인 경우 지원. --Dirk Beetstra 15:08, 2011년 10월 25일(UTC)[응답]
• 공백 변경은 디프 디스플레이에서 해석하기 어렵고 편집 요약은 진행 상황을 설명하지 않으므로 반대한다.또한, 내 의견을 바꾸기 위해, 나는 변경사항이 위키 출처가 아닌, 진열된 글의 과도한 공백을 바꾸는 것으로 제한될 것이라고 확신할 수 있다.Jc3s5h (대화) 15:20, 2011년 10월 25일 (UTC)[응답]
  • 사실, 나는 위키소스의 공백 개선을 좋아하는데, 그것은 다음 편집자가 더 쉽게 따라올 수 있도록 해준다. --SerkOfVulcan (토크) 16:28, 2011년 10월 25일 (UTC)[응답]

• 나도 위키소스의 화이트스페이스 개선은 좋아하지만, 자동화가 될 수 있다고 생각하지 않으며, 기존의 화이트스페이스에 대해 식별 가능한 패턴이 있다면 반드시 토크 페이지 컨센서스 없이 이루어져야 한다고 생각한다.Jc3s5h (대화) 18:18, 2011년 10월 25일 (UTC)[응답]

• 지지하다.이것은 프로젝트에 이로운 일이고, 어쨌든 다른 봇/스크립트에 의해 이루어진다고 생각한다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} -- 18:04, 2011년 10월 25일 (UTC)[응답]
• 반대한다. 명확한 이익과 편집자는 관련 옵션 등의 그룹 사이에 공간을 남겨두도록 선택할 수 없다.have mörser, will talk (talk) 18:09, 2011년 10월 25일 (UTC)[응답하라]

~

• 코멘트 나는 과도한 공백만 제거하며, 그것은 다른 편집과 함께만 수행된다.ΔT 19:21, 2011년 10월 25일 (UTC)[응답]
  • 어떤 종류의 공백을 말하는 거야?소스 코드 내의 유형을 말한다면, 삭제하는 이유는 무엇인가?— 칼 (CBM · talk) 19:36, 2011년 10월 25일 (UTC)[응답]
    • 일반적으로 Ill은 과도한 휴식 시간이 있는 공백을 제거하거나, Wikicode의 가독성을 향상시키기 위해 필요한 곳에 공백을 추가하며, 다른 때에는 기사에 너무 많은 공백을 추가하는 과도한 줄 바꿈을 제거한다.ΔT 19:39, 2011년 10월 25일 (UTC)[응답]
• 트리스테사 당 지원군하지만 어떤 것이든 깨지는 것을 조심해라.– 루나 산틴 (토크) 22:35, 2011년 10월 25일 (UTC)[응답]

• 나는 이 수정사항들을 8k 이상 문제없이 수정했다.ΔT 00:32, 2011년 10월 26일 (UTC)[응답]

• 도움말을 읽어 보았다.전체적으로 공백이 있고, 여기서 어떤 작업이 정의되고 있는지 모르겠다."매우 자주, 바람직하지 않은 공백이 있을 때, 문제를 해결할 수 있는 유일한 방법은 기사를 확장하는 것이다."라고 그곳의 유일한 확실한 권고인 것 같다.나는 아무도 그것에 반대할 것이라고 생각하지 않으며, 그 과정이 컴퓨터로 만들어진 패턴이 될 가능성이 있다고 생각하지 않기 때문에, 누구도 반대할 것 같지 않다.U u (대화) 2011년 10월 26일 16:48, (UTC)[응답]
• 나는 이것을 서면처럼 반대해야 할 것이다.여기에 코드나 의도의 소유자가 아닌 사람에 의한 포괄적인 제안 집합의 문제가 있다.너무 많은 내용이 실린 기사를 접했을 때 공백 문제를 해결하는 것?당연하지, 난 종종 그렇게 해, 보통 이미지 배치, 때로는 텍스트에서 재지그로.브라우저 창을 다른 크기로 끌어서 다른 독자들에게 어떻게 보이는지 보는 것이 중요하며, 다른 글꼴 크기도 시험해봐야 할 것 같아.베타(Beta)가 그런 것을 케이스 바이 케이스(case by case)로 하고 싶다면, 예측 알고리즘을 사용하여 문제가 있을 수 있는 곳을 알아내더라도 눈에 보이는 방법으로 물건을 고치고 있다면 문제없을 것이다."genfix"-es의 일부로서, 나는 자동 수정기가 무엇인지 훨씬 더 잘 이해할 필요가 있을 것이다.위키코드에서만 볼 수 있는 변경사항의 경우, 나는 특별한 필요성이나 만족감을 느끼지 못한다.프라나맥스 (대화) 01:46, 2011년 10월 27일 (UTC)[응답]

Δ 제안 과제 #7

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의는 명시된 제한에 따라 요청하는데 있어 그를 대신하여 운용하는 것에 대한 그의 동의 [14]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 링크가 비활성화된 곳의 참조에 적합하게 {{dead link}}을(를) 추가할 수 있다. (1998, diff의 두 번째 섹션(첫 번째 녹색 부분)

Δ를 대신하여 --Hammersoft (대화) 20:53, 2011년 10월 24일 (UTC)

이것은 봇이 해야 한다. 그가 그것을 수동으로 할 이유는 없다.— 칼 (CBM · talk) 21:09, 2011년 10월 24일 (UTC)[응답]

• 그가 그것을 할 수 없는 이유가 있는가? --Hammersoft (대화) 21:11, 2011년 10월 24일 (UTC)[응답하라]
  • 당신은 왜 그가 이러한 편집을 수행할 수 있는 특별한 허가를 받아야 하는지에 대해 어떠한 주장도 제시하지 않았으며, 그가 제한을 받지 않는 모든 편집자들과 비교했을 때 특별한 위치에 있다고 생각할 이유가 없다.이런 종류의 일은 베타보다 봇이 더 잘한다.— 칼 (CBM · talk) 01:16, 2011년 10월 25일 (UTC)[응답]

• 너는 그가 왜 하지 말아야 하는지에 대해 논쟁하지 않았다.그는 여기 편집장이다.그가 편집을 할 수도 있고, 할 수도 없다.그가 할 수 있다면, 그는 이 편집을 수행할 수 있다.문제는 그가 편집을 수행할 수 있는 권한이 있느냐가 아니다.넌 그를 부정할 수 없어.문제는 그가 이 중 24개 이상을 임의의 기간에 걸쳐 수행해도 되는지 여부다. --Hammersoft (대화) 01:44, 2011년 10월 25일 (UTC)[응답]
  • 그는 승인을 받지 않고는 25개 이상의 편집 패턴을 만들 수 없다.승인 획득의 일부는 왜 편집이 가치 있는가에 대한 실제 사례를 만드는 것이다.이러한 편집을 많이 할 명분이 없다면, 왜 그 수정에 대한 허가를 요청하는가?그것은 위키리듬링처럼 보인다.— 칼 (CBM · talk) 01:54, 2011년 10월 25일 (UTC)[응답]

• Δ가 왜 이런 일을 하고 싶어하는지 설명해 주시겠습니까? --트리스테사 (대화) 02:49, 2011년 10월 25일 (UTC)[응답]
• 지지하라, 그렇지 않을 이유가 없다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 지원은 반자동화하기에 합리적인 작업으로 보인다.have mörser, will talk (talk) 07:37, 2011년 10월 25일 (UTC)[응답하라]
• 위에 열거된 반대 의견 이외의 다른 지원 사항으로, 그가 수동으로 합리성을 확인한다고 가정해 보십시오.뉴트 기사가 5분 동안 다운돼서 데드링크가 뜨는 걸 보고 싶지 않아.호빗(토크) 10:26, 2011년 10월 25일 (UTC)[응답]
• 상식 적용 시 지원. --Dirk Beetstra 15:19, 2011년 10월 25일 (UTC)[응답]
• 편집 요약이 의미 있는 경우 조건부 지원.Jc3s5h (대화) 15:21, 2011년 10월 25일 (UTC)[응답]
• 지지하다.이것은 내가 아는 한 프로젝트 EOT에 이롭다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 기사가 오프라인이 되어 합리적인 기간 동안 지원. -- 지우개헤드1 <토크> 19:46, 2011년 10월 25일 (UTC)[응답]
• 조건부 지원은, 호빗에 의하면, 링크는 진짜로 죽어서, 살아날 가능성이 없다고 하는 것을 전제로 했다. --트리스테사 (토크) 21:27, 2011년 10월 25일 (UTC)[응답]
• 지원, 아주 간단하다.– 루나 산틴 (토크) 22:36, 2011년 10월 25일 (UTC)[응답]
• {{dead link}}}}}은(는) 물건을 고치려고 할 수 있는 톱니바퀴가 없는 벙어리 봇을 위한 것이다.인간 편집자들은 더 잘해야 한다.이것은 인간 편집자들에 의해 수행된다면 백과사전을 비난할 일이 아니다.Chris Cunningham (사용자:thumperward) - 토크 14:22, 2011년 10월 26일 (UTC)[응답]
  • 데드링크의 원문이 말한 내용을 인간 편집자가 알지 않는 한 인간 편집자가 적당한 대체물을 찾는 것은 기대할 수 없으며, '데드링크'로 태그를 붙이는 것도 허용된다.(제목이 충분히 서술적이면 불가능하지 않지만, 자주, 제목이 너무 짧거나 제목 표시가 없는 맨 URL을 말하는 경우, 검색이 불가능하다) --MASEM (t) 14:26, 2011년 10월 26일 (UTC)[응답]
    • WP:DEADREF는 인간 편집자를 위한 많은 작업을 제공한다.다른 동작 없이 연결 고리를 비활성 상태로 태그하는 값은 무시해도 좋다.나는 베타가 리프링크 실행을 가장한 기사(리프링크는 링크에 접속할 수 없는 경우 자동으로 리프링크를 실행함)에 {{데드링크}를 추가해도 괜찮다고 생각하지만, 별도의 업무는 아니다.Chris Cunningham (사용자:thumperward) - 토크 14:51, 2011년 10월 26일 (UTC)[응답]

• 지지하다.이러한 편집은 독자들에게 유용할 것이다.카라낙스 (대화) 16:34, 2011년 10월 28일 (UTC)[응답]
• Chris Cunningham에 반대하십시오.만약 이러한 수정사항들이 실제로 수동으로 처리된다면 델타가 실제로 유익하게 만들 수 있는 변경사항들이 있다.인간이 봇과 같은 편집을 하는 것은 봇이 더 나은, 사람이 쓴 편집을 할 수 없다는 이유만으로 행해지는 의미가 없다.대체로, 1번과 3번 작업에서 나의 주장을 보라.테크노심비오시스 (대화) 00:27, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #8

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 하는 데 있어 그를 대신하여 운용할 수 있다[15]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 <br style="clear:bothy;" />를 {{-}}(예: 14번째 '+' 기호 in diff)로 대체할 수 있다.

Δ를 대신하여 --Hammersoft (대화) 21:02, 2011년 10월 24일 (UTC)

"다양한 편집" 등급에 속함 - 기사에 다른 비다양적인 편집을 한다면 괜찮지만 일반적으로 그들 스스로 할 가치는 없다.김메투(토크) 22:10, 2011년 10월 24일 (UTC)[응답]

• 반대 - 기껏해야 HTML을 매우 이상하게 보이게 하거나 최악의 경우 HTML을 손상시킬 수 있으며, 여기서 기사(예: infobox) 내에서 인라인 이외의 상황에서 <br> 태그를 사용한다.그것은 또한 의심스러운 가치가 있다.이 HTML을 템플릿으로 교체해야 한다는 데 합의하기 위해 다른 곳에서 논의한 적이 있는가? --트리스테사 (대화) 02:53, 2011년 10월 25일 (UTC)[응답]
• 논평: 일반적인 믿음과는 달리, 위키피디아는 실제로 표준 규격의 XHTML로 제공되지 않고 있으며, XHTML 형식의 태그가 텍스트/html로 제공되는 것을 볼 때마다 나는 약간 떨린다.원시 라인브레이크 HTML을 템플릿으로 대체하는 것은 실제로 우리가 직접 사용되는 데이터베이스 전체에서 수백만 개의 장소 대신에 한 곳에서 라인브레이크 태그 형식을 변경할 수 있게 함으로써, 고장난 XHTML 표준에서 벗어나 HTML5와 같은 미래에 더 유용한 것으로 이동하는 위키피디아의 능력을 향상시킬 수 있다.테크노심비오시스 (대화) 04:36, 2011년 10월 25일 (UTC)[응답]
• 이것에 대한 필요성이 더 명확하게 설명될 때까지 반대하라.우리는 이미 너무 많은 템플리트 전이가 있는 일부 페이지에 문제가 있다. 명백한 이익을 위해 템플리트를 더 추가한다고 해서 이것이 더 나아지지는 않을 것이다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 테크노심비오시스별 지원. --SerkOfVulcan (대화) 15:06, 2011년 10월 25일 (UTC)[응답]
• 지원 - 결과가 더 이상의 템플릿 전폐를 깨지 않아야 한다는 주의와 함께(그렇다면 최소한 정확하도록 모두 변위시키십시오.) --Dirk Beetstra 15:20, 2011년 10월 25일(UTC)[응답]
• 결과 템플릿의 전폐를 깨지 않는 경우 지원. -- 지우개헤드1 <토크> 19:46, 2011년 10월 25일 (UTC)[응답]
• 인라인 사용을 대체할 수 있도록 지원하되, 템플리트나 템플리트 호출에서 주변 장애에 각별히 주의해야 한다.프람이 설명하는 상황에서는 사용을 피해야 하지만, 그게 얼마나 흔한지는 잘 모르겠다.– 루나 산틴 (토크) 22:37, 2011년 10월 25일 (UTC)[응답]
• 이와 같은 사소한 검색 대체 편집은 실제 봇에 의해 실행될 수 있다.그들은 백과사전을 전혀 개선하지 않는다.Chris Cunningham (사용자:thumperward) - 토크 14:25, 2011년 10월 26일 (UTC)[응답]
• 반대한다. 나는 대부분의 편집자들은 그 템플릿이 무엇을 의미하는지 알지 못하지만, 우리들 중 많은 사람들은 HTML 코드가 무엇인지 알고 있다.이것은 잠재적으로 혼란스러운 편집이다.또한 페이지 로딩이 느려서 템플릿 제거에 최선을 다한 페이지도 있다.나는 템플릿이 다시 추가되는 것을 원하지 않는다.카라낙스 (대화) 16:36, 2011년 10월 28일 (UTC)[응답]

Δ 제안 과제 #9

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [16]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 "Image:"를 "File:"로 대체할 수 있다. (iii, diff의 여러 예제)

Δ를 대신하여 --Hammersoft (대화) 21:06, 2011년 10월 24일 (UTC)

이렇게 할 이유는 없어, 그들은 완전히 동등해.— 칼 (CBM · talk) 21:08, 2011년 10월 24일 (UTC)[응답]

• 그가 그것을 할 수 없는 이유가 있는가? --Hammersoft (대화) 21:12, 2011년 10월 24일 (UTC)[응답하라]

"다양한 편집" 등급에 속함 - 기사에 다른 비다양적인 편집을 한다면 괜찮지만 일반적으로 그들 스스로 할 가치는 없다.김메투(토크) 22:11, 2011년 10월 24일 (UTC)[응답]

• 지원 - 사소한 것, 그래, 하지만 그가 하지 말아야 할 진짜 이유는 없어. --트리스테사 (대화) 02:54, 2011년 10월 25일 (UTC)[응답]
• 둘 다 같은 것에 대한 가명이라는 점에서 불필요한 것으로 반대하라.{{fact}}에서 {{citation 필요}}}}}}}}}까지 바꾸는 것을 누군가에게 시키지는 않았을 텐데, 이 상황이 다른 이유가 있는가?이것은 순이익 없이 헛수고를 한 것처럼 보인다.테크노심비오시스 (대화) 04:39, 2011년 10월 25일 (UTC)[응답]
  • 그래, 사실 누군가는 인용이 필요한 인용문으로 사실을 바꾸어야 해. 왜냐하면 전자는 후자로 방향을 바꾸거든.그렇게 변경하면 몇 개의 CPU 사이클이 절약된다.즉, 파일: 및 이미지:는 서로 다르며(그것은 리디렉션된 것이 아니라 위키미디어 네임스페이스 부분) 파일 아래의 미디어 사용을 명명하는 역할만 한다. ns. --MASEM (t) 10:42, 2011년 10월 25일 (UTC)[응답]
    • 성능 문제에 대해 걱정하지 말라고 명시적으로 말하는 페이지가 있으며 리디렉션은 완벽하게 허용된다.CPU 사이클은 우리의 관심사가 아니며, 그런 종류의 변화나 네임스페이스의 변화에는 이유가 없다.테크노심비오시스 (대화) 22:57, 2011년 10월 25일 (UTC)[응답]
      • 하지만 여전히 봇이 돌아다니며 기사 공간을 이중으로 리디렉션하는 것을 고치고 있다.물론, CPU 주기에 대해 너무 많이 걱정하지 않아도 되지만, 이러한 수정은 장기적으로 도움이 된다.하지만, 다시 말하지만, 그것은 이 구체적인 요청과는 동떨어진 것이다. --MASEM (t) 13:52, 2011년 10월 26일 (UTC)[응답]
        • 이중 리디렉션, 예, 이러한 리디렉션은 자동으로 해결되지 않기 때문에이중 리디렉션을 수정하는 것은 독자에게 도움이 되며, 간단한 리디렉션을 수정하는 것은 그렇지 않거나 눈에 띄게 도움이 되지 않는다.프람 (토크) 2011년 10월 26일 14:00 (UTC)[응답]
• 조건부 지원. 보다 실질적인 작업이 수행되는 편집(예: "데드링크" 추가 또는 삭제된 이미지 제거 또는 실질적인 작업이 승인을 얻는 경우)에서만 지원.그것만으로도 불필요한 편집이다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 불필요하게 반대하며 아무런 목적도 없다.A) 불필요한 편집 또는 B)의 부정적인 영향을 받아 실제 변경 내용을 확인하기 어렵다.호빗(토크) 10:28, 2011년 10월 25일 (UTC)[응답]
• 반대 나는 이것을 하는 것이 영원한 제안이라고 생각했다. 어쨌든 나는 이것이 왜 필요한 변화인지 모르겠다. Guerillero My Talk 14:58, 2011년 10월 25일 (UTC)[응답]

• 큰 이익도 해롭지도 않다.페이지 표시에 큰 영향을 미치는 다른 부분이 편집된 부분인 경우에만 지원한다. --Dirk Beetstra 15:21, 2011년 10월 25일 (UTC)[응답]
• 댓글을 달다.Image를 폐기하고 의미가 덜한 파일로 교체해야 할 필요성을 전혀 이해하지 못했는데… --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]

왜냐하면 "Image:" 공간에는 사운드 파일도 있고, 이것은 누군가 또는 다른 사람에게 그리고/또는 워너베카이트의 편집 카운터 같은 하드 코딩된 프로젝트 공간 이름을 사용하는 많은 외부 도구들을 파괴하는 것이 압도적으로 혼란스러웠기 때문이다.프라나맥스 (대화) 2011년 10월 25일 18시 55분 (UTC)[응답]

• 김므 당 조건부 지원, 비트스트라프라나맥스 (대화) 2011년 10월 25일 18시 57분 (UTC)[응답]
• 김므 당 지원하라, 비트라.– 루나 산틴 (토크) 22:38, 2011년 10월 25일 (UTC)[응답]
• 질문:재단이 "이미지:" 네임스페이스를 평가절하할 장기 계획이 있는지 아는 사람?어느 시점에서 이런 일이 일어난다고 알려지면 이 일이 중요해지기 시작한다. --MASEM (t) 13:53, 2011년 10월 26일 (UTC)[응답]
  • 그것은 "비열한" 것이 될 것이고, 그렇지 않을 것이다.이 '과제'는 때가 되면 진짜 봇이 완벽하게 처리해 줄 수 있는데, 이 봇은 잘못해서 ANI로 달려가는 친구가 없다.다른 몇몇 "태스크"들도 그렇다.Chris Cunningham (사용자:thumperward) - 토크 13:59, 2011년 10월 26일 (UTC)[응답]
  • 이름은 이미 더 이상 사용되지 않으며 파일: - [17]의 별칭으로 유지되므로 완전히 제거해야 할 특별한 이유는 없다.프라나맥스 (대화) 2011년 10월 26일 (UTC) 17:11 (답변)
• 파일:와 이미지:는 전혀 차이가 없다.어떤 것이 사용되든 소프트웨어는 여전히 네임스페이스 ID와 표준 네임스페이스 이름을 찾는다.리디렉션을 사용하는 것과 같은 추가 데이터베이스 검색은 없고 일부 PHP 변수만 검사한다.사소한.이미지 별칭을 제거하면 이유 없이 위키백과가 깨질 수 있기 때문에 개발자들은 그렇게 하지 않을 것이다.이미지 유지: 기사의 링크는 절대적으로 해롭지 않으며, 다른 어떤 것도 하는 데 시간을 보내는 것이 더 나을 것이다.이미지: 외부 공구가 파손된 경우 공구를 고정해야 한다.진실에 다가가기 19:04, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #10

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의는 명시된 제한에 따라 요청하는데 있어 그를 대신하여 운용하는 것에 대한 동의 [18]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 기사를 생성할 수 있다.(iii)

Δ를 대신하여 --Hammersoft (대화) 21:10, 2011년 10월 24일 (UTC)

물론 델타는 기사를 실을 수 있지만, 25개 이상의 프로드의 "패턴"은 거의 필요하지 않을 것이며, 특정한 이유나 상황과 관련되어야 한다고 생각한다.대체 왜 이것이 필요할까?김메투 (토크) 22:17, 2011년 10월 24일 (UTC)[응답]

• 24개 이상의 기사를 제시하면 Δ가 문제될 가능성이 높기 때문이다."이봐, 기사 25개 냈잖아.허락을 받았나?"따라서, 요청. --Hammersoft (대화) 22:43, 2011년 10월 24일 (UTC)[응답]
  • 만약 당신이 그가 25개의 기사를 PROD할 것을 제안하고 있다면, 당신은 그들의 이름을 알려야 한다.이 제안 과정은 원칙적으로 이루어질 수 있는 모든 가능한 편집에 대한 것이 아니라 베타가 수행하려고 계획하고 있는 특정 작업을 위한 것이다.— 칼 (CBM · talk) 01:20, 2011년 10월 25일 (UTC)[응답]

• 난 미래를 보고 있다.분명히 이제 당신의 승인을 얻으려면 우리는 어떤 기사가 나올지 예감하기 위해 수정구를 응시해야 한다.설마 진심은 아니겠지. --Hammersoft (대화) 01:45, 2011년 10월 25일 (UTC)[응답]
  • 제안의 요점은 제안되고 있는 것을 사람들에게 알릴 수 있을 만큼 충분히 구체적일 필요가 있다는 것이다.어떤 기사가 실릴까?왜 25명이 연달아 있는 거지?만약 25개의 기사를 게재할 실제 계획이 없다면, 일종의 추측성 승인을 받을 필요가 없다.— 칼 (CBM · talk) 01:56, 2011년 10월 25일 (UTC)[응답]

• 비자동화 PROD만 지원 - 다음과 같이 수정한다: "...수동으로 신중하게 검토했으며, 특정 기사를 PRODED로 검토한 결과 각 기사에 대한 근거를 제공했다." --트리스테사(talk) 02:58, 2011년 10월 25일(UTC)[응답]
  • 두 번째. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} -- 2011년 10월 25일 (UTC)[응답]
• 반대한다, 이것은 충분히 구체적이지 않다. '고정 리디렉션'은 한 가지, '기사 게재'는 전혀 다른 것이고, 델타는 전자보다 후자를 위해 훨씬 더 많은 비난을 감수할 것이다.칼이 말했듯이 25개의 기사를 게재하는 것은 결코 작은 일이 아니다, 그것은 델타 제한의 예외로서 지역사회가 포괄적으로 허가해야 할 일은 아니라고 생각한다.테크노심비오시스 (대화) 04:43, 2011년 10월 25일 (UTC)[응답]
• 조건부 지원.물론 그는 기사를 쓸 수 있지만, 많은 기사 집단을 만드는 것은 사전에 논의되고 사례별로 볼 수 있는 것이 더 낫다.그리고 예를 들어 프로드는 빠르게 뒤집혔기 때문에 이것들을 많이 만드는 것은 아마도 좋은 생각이 아닐 것이다.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 이 허락을 모든 하원 기사를 걸어다니고 그들을 부추기기 위한 무료 입출금 카드로 보아라.그는 IMO에 대해 자유롭게 말할 수 있다. 단지 자동적인 방식이나 패턴이 있는 것이 아니다.호빗 (토크) 2011년 10월 25일 10시 30분 (UTC)[응답]
• 반대와 정직하게 이 제안들은 나쁜 믿음의 영역으로 방황하고 있으며, 요점에 가깝다.만약 델타가 갑자기 밖으로 나가 다음 시간 안에 25개의 기사를 게재한다면, 그것은 집중적인 편집 작업이 될 것이다.만약 그가 오늘, 내일, 일주일에 4, 5번 커플을 제안한다면, 나는 그가 그 제한을 위반하고 있다고 주장하기 시작할 사람이 아무도 없을 것이라고 생각한다.나는 아무도 그렇게 하는 것을 본 적이 없다.클린업은 완전히 다르며 그는 종종 그것들을 함께 한다.이 제한의 전체 목적은 델타가 과거에 갑자기 몇 백개의 기사를 바꾸기를 좋아하기 때문에 때때로 물건을 망가뜨리고 갑자기 많은 기사에 변화를 주듯이, 그가 기사에 대규모로 변화를 주는 것에 대한 합의를 하는 것이다.--크로스미르 (대화) 11:29, 2011년 10월 25일 (UTC)[응답]

그런 다음 (합리적이지만 무작위적인 숫자):

Δ는 기사를 작성할 수 있다(그러나 연속적으로 10을 초과하지 않고 하루에 50을 넘지 않는다).(iii)

그렇지 않으면 이것은 '마지막 100개 편집에서 26개의 기사를 게재했다'라는 지경에 이르게 될 것이고, 만약 그렇지 않다면, '마지막 100개 편집 중에 26개의 이미지를 삭제했다'는 패턴도 아니다 - 분명히 내 버전을 뒷받침한다. --Dirk Beetstra 15:07, 2011년 10월 25일 (UTC)[응답]

우리는 그에게 한 달에 1,500개의 기사를 발행하는 것을 전면적으로 허락해서는 안 된다.기사의 목록이 길면 구체적인 제안서를 들고 돌아오거나 다른 사람이 하게 해야 한다.— 칼 (CBM · talk) 15:23, 2011년 10월 25일 (UTC)[응답]

• 중요한 점은 그가 기사를 쓰는 것이 하나의 패턴으로 해석될 수 있다는 것이다.따라서, 구체적인 허가를 요청한다.아무도 그가 하루에 100만개의 기사를 낼거라고 제안하지 않는다. --Hammersoft (대화) 15:26, 2011년 10월 25일 (UTC)[응답]
  • 내가 답하고 있던 제안은 정확히 그가 더 이상의 검토 없이 매달 1,500건의 기사를 게재할 수 있도록 허락하는 것이었다.역사는 베타가 가능한 한 광범위한 방식으로 권한을 해석하는 경향이 있음을 보여준다.영향을 받을 기사의 구체적인 리스트가 없으면 그가 그렇게 하는 것이 적절한지 알 길이 없다.— 칼 (CBM · talk) 2011년 10월 25일 16시 15분 (UTC)[응답]

• 칼은 어떻게 되는 거야?너는 즉석에서 Δ와 관련된 모든 것에 반대했다.그럼 넌 바로 여기 와서 그를 믿지 않는다고 말하는 거야.그냥 그를 금지하고 끝내자는 제안을 시작하는 게 어때?!?!? --해머소프트 (대화) 18:00, 2011년 10월 25일 (UTC)[답답답]

• 반대 베타가 많은 기사를 쓰려면 사례별로 별도의 승인을 받아야 한다.프라나맥스 (대화) 2011년 10월 25일 18시 59분 (UTC)[응답]
• 한번에 25개의 기사를 게재하는 것에 대해 합법적일 것 같지 않은 반대. -- 지우개헤드1 <토크> 19:44, 2011년 10월 25일 (UTC)[응답]

• 나는 너무 짧은 페이지를 검토할 수 있는 도구를 가지고 있다. 그 결과들을 검토할 때 하루에 5-10개의 태그를 다는 것이 드물지 않다. 만약 내가 그렇게 한다면, 한 달에 40개의 기사가 25개의 제한을 넘는다고 말한다.누군가 와서 항의할 것이고, 그 결과 또 다른 차단 ΔT 19:51, 2011년 10월 25일 (UTC)[응답]이 일어날 것이다.
  • 반대한다. 당신은 다른 사람들이 많은 짧은 페이지들을 삭제하기 위해 태그하는 것에 대해 걱정하게 해야 한다는 것을 알고 있다.논란을 일으키지 않고서는 이 일을 할 수 없다.— 칼 (CBM · talk) 19:53, 2011년 10월 25일 (UTC)[응답]
    • 그럼 이제 내가 필요하다고 생각하는 기사도 못 써?우습게도, 나는 대량으로 태그를 달지 않을 것이다. 그러나 만약 내가 어떤 기간 동안 25개 이상의 태그를 달게 된다면 그것은 패턴으로 간주될 것이고 나는 그것을 위해 차단될 것이다.다음 단계는 A로 시작하는 기사나 D로 끝나는 기사나 다른 아시닌 규칙으로 편집하는 거야?ΔT 20:07, 2011년 10월 25일 (UTC)[응답]
      • 방금 하루에 10개씩 한다고 하셨어요, 아니면 한 달에 40개 정도?어떤 경우에도 당신은 삭제하기 위해 다른 사람들이 기사를 검토하도록 해야 한다.당신은 매우 최근에 NFCC 집행에서 금지되었다. 그 결과 논란이 되는 다른 종류의 삭제 태깅으로 이동하는 것은 무모할 것이다.다른 사람이 하게 하고, 논란이 없는 일에만 충실하라.— 칼 (CBM · talk) 20:17, 2011년 10월 25일 (UTC)[응답]
        • 제발 내 입에 단어를 넣지 말아줘, 나는 대량 태깅을 계획하고 있지 않아. 그리고 정상적인 삭제 과정은 논란의 여지가 없어. 위키피디아:프로드의 한 예인 삭제/에어케어(2차 지명) 조항은 저자가 반대하자 결국 AfD로 격상됐다.10월에 나는 11페이지에 태그를 달았는데, 그 중 2페이지는 prod가 무효가 되도록 개선되었고, 1페이지는 리디렉션되었으며, 나머지는 삭제되었다.상당히 표준적이고 논란의 여지가 없는.ΔT 20:26, 2011년 10월 25일 (UTC)[응답]
          • 이 요청은 임의의 수의 기사(Δ는 기사를 게재할 수 있다.)를 발행하기 위한 승인을 요청하는 것이다.만약 당신이 실제로 많은 기사를 게재할 계획이 없다면, 더 제한적인 요청이 더 합리적일 수 있다.그러나 이 요청은 어떤 식으로든 제한되지 않는다.— 칼 (CBM · talk) 20:49, 2011년 10월 25일 (UTC)[응답]
            • 왜? 내가 25개 이상 태그를 달면 시간대를 불문하고 "패턴"이 될 것이기 때문에 어떤 질문도 받지 않을 것이다.ΔT 20:53, 2011년 10월 25일 (UTC)[응답]

• 반대, 너무 모호하다.더 명확한 표현을 논할 수 있도록 개방하십시오.– 루나 산틴 (토크) 22:39, 2011년 10월 25일 (UTC)[응답]

• 델타가 보통 기사를 통해 어떻게 진행되는지에 대한 일부 명확화가 도움이 될 수 있다.기사가 어떻게 그의 줄에 들어오는지 모르지만 알파벳 순서가 그 일부인 것 같다.기본적으로, 만약 델타가 그가 작업할 계획인 기사 목록을 가지고 있다면, 그 목록은 WP의 모든 기사들로부터 무작위로 추첨한 것이다.일부는 적절한 PROD 대상일 수 있지만, PROD 대상 중 어느 하나라도 상호 연관되어 있다는 호감도는 매우 낮기 때문에, 단순히 PROD를 원하는 기사의 목록을 만들기 위해 델타에게 특별한 조치를 취해야 한다는 것을 의미한다.나는 PROD가 동등한 관련 기사에 대해 만들어지는 것이 더 걱정된다(예: 호빗의 하우스 에피소드 기사 예).아마도 여기서의 단계는 델타가 어떻게 채워지는지 확실히 하는 것일지도 모른다. 그리고 우리 모두는 이것이 사실상 무작위 추첨에 충분히 가깝다는 것에 동의한다. 즉, 어떤 PRODing도 대상이 아니라는 것을 의미한다.만약 그가 고도로 연관성이 높은, 예를 들어, 하루 또는 그 이상, 다른 장소에서 먼저 승인을 받아야 하는 일련의 동등한 기사들을 PROD를 원한다면, 나는 덧붙이고 싶다. --MASEM (t) 14:05, 2011년 10월 26일 (UTC)[응답]

나는 후보 선출 방식, 평가 방식, 그리고 이것이 얼마나 자주 이루어질 것인지에 대해 좀 더 명확하게 정의된 표현을 지지할 용의가 있다.칼이 암시하고 있는 것처럼 베타가 그들의 '목록 처리' 초점을 페이지 삭제로 바꾼다면 결코 바람직하지 않을 것이다.그리고 그 방에 있는 코끼리를 주목하기 위해서, 야크노우, 과거의 예들, "나는 여기서 내가 직접 기사를 확장하고 [21가지 개선 디프] 주제를 조사하는 것이 더 나을 것이라고 결정했다." (그리고 그렇다, 나는 알고 있다, 나는 어느 누구도 억지로 내용을 추가하지는 않는다) - 이 모든 일반적 우려를 잠재우는 쪽으로 아주 멀리 갈 것이다.프라나맥스 (대화) 2011년 10월 26일 17시 30분 (UTC)[응답]

델타가 PRODING에 대해 어떤 유형의 기사를 계획하고 있는지, 또는 PRODING에 대한 블랙리스트 작성 이유를 구체적으로 적어두는 것도 좋을 것이다.해머소프트가 제시한 예는 완전히 공정한 PROD인 IMO이다.델타가 수행하는 이러한 정화 프로세스에서 공신력 부족과 같이 비객관적이고 보다 주관적인 조치에 기초한 PROD는 피해야 한다.따라서 델타가 이 정기적인 편집 패턴에서 PROD를 추가하는 것을 고려하고 다른 사람들이 할 수 있는 다른 모든 것을 남기는 유일한 이유를 나열하는 것이 더 쉬울 수 있다.나는 그가 문제가 있다고 느낄 수 있는 기사 목록을 자유롭게 유지할 수 있지만, 다른 사람들이 그 목록을 처리하도록 허용하면서, 그의 허용된 PRODable 사유에서 벗어날 수 있다고 주장한다. --MASEM (t) 17:39, 2011년 10월 26일 (UTC)[응답]

Δ 제안 과제 #11

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [19]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 적절한 리디렉션으로 기사를 변경할 수 있다.(iii)

Δ를 대신하여 --Hammersoft (대화) 21:16, 2011년 10월 24일 (UTC)

물론 델타는 "적절한" 리디렉션을 만들 수 있지만, 나는 25개 이상의 "패턴"은 거의 필요하지 않을 것이며, 특정한 이유나 상황과 연관되어야 한다고 생각한다. (예: 다수의 기사가 병합된 후)대체 왜 이것이 필요할까?김메투 (토크) 22:18, 2011년 10월 24일 (UTC)[응답]

#10과 같은 문제: 세부사항이 없으면 의뢰를 검토할 수 없다.어떤 기사들이 바뀔까?결정할 기준은 무엇인가?등등. 여기에는 제안되고 있는 것을 누구라도 알 수 있는 충분한 정보가 없다.— 칼 (CBM · talk) 01:21, 2011년 10월 25일 (UTC)[응답]

• 그리고 다시 우리는 미래를 예언할 수 없다.당신이 만들고 있는 문제(그리고 당신이 만들고 있는 문제)는 그가 2011년 10월에 기사의 리디렉션을 만들고, 11월에 5번, 12월에 5번을 더 한다면, 2월경에 당신이나 다른 누군가가 승인되지 않은 패턴 때문에 반칙을 범할 것이라는 것이다.당신이 그렇게 하는 것이 하나의 패턴이라고 느끼기 때문에, 나는 그가 적절하게 기사를 리디렉션으로 바꿀 수 있도록 구체적인 허가를 요청하는 것이다.네가 만든 네 손톱 밑이야. --Hammersoft (대화) 01:47, 2011년 10월 25일 (UTC)[응답하라]
  • 나는 당신이 사람들이 그런 식으로 퍼진 편집에 대해 불평할 것이라고 제안함으로써 위키리듬을 하고 있다고 느낀다.최근의 불만 사항은 2개월 동안 2,000건에 대한 것이었고, 1년 동안 25건에 대한 것이 아니었다.많은 수의 기사를 리디렉션할 즉각적인 계획이 없다면, 또한 즉각적인 승인도 필요하지 않다.— 칼 (CBM · talk) 02:01, 2011년 10월 25일 (UTC)[응답]
    • 사람들은 편집이 유익할 때도 델타가 자신의 제한을 어긴 지점을 찾기 위해 꼼꼼하게 기간 내 편집 내용을 세어 왔다.(10분 안에 40개 편집) 철자를 썼을 때, 그것은 적어도 그가 작업할 수 있는 것이다.만약 당신이 25번의 편집을 했지만 기간이 없다면, 26일이 나머지 25일 이후 1년이 되더라도, 그가 VPR 승인 없이 26번을 한다면 누군가 불평할 것이다.물론, 그 주장은 기각될 것 같지만, 있을 것이다. --MASEM (t) 10:39, 2011년 10월 25일 (UTC)[응답]
      • 그 상황이 현재 존재하는 것은 인덕비타블이다.누가 그런 짓을 하는 게 보이니?그 기존의 사례를 실제로 지적할 수 없다면 그것은 근거 없는 불신 가정이다.--크로스미어 (토크) 12:12, 2011년 10월 26일 (UTC)[응답]
        • (그의 최근 블록에서) 25개 한도가 나온 것은 이번이 처음이다.그가 10분 동안(한계가 40일 때) 43번의 편집을 한 것에 대해 며칠 후에 차단되었다는 것을 고려하면, 그가 스로틀을 잘못 사용했다는 사실을 인정했음에도 불구하고, 델타는 어떤 임의의 기간 동안 이러한 "25번의 편집"에 대해 같은 현미경에 처하게 될 것이다.지금 정의하면 미래에 아직 또 다른 델타 ANI 스레드가 생기는 것을 피할 수 있다. --MASEM (t) 14:12, 2011년 10월 26일 (UTC)[응답]
          • 아니, 그건 거짓이야.델타가 VPP에 가져가기 전 약 하루 반 동안 상당한 양의 편집을 수행했기 때문에 5월/6월의 NFCC 전체는 VPP 제안에 대한 메타토론을 포함하고 있었다.그의 블록 로그에 입력되지 않았을 수도 있지만, 이것이 처음 나온 것은 아니다.그건 4개월 전 일이었고 그 시간 동안 나는 아무도 당신 주장대로 하는 것을 보지 못했다.--크로스미르 (토크) 23:09, 2011년 10월 26일 (UTC)[응답]

• 어떤 상황에서?그가 통상적인 방법으로 리디렉션을 만들고 있다면, 여기서 이것이 제안이 될 필요는 없다. --트리스테사(토크) 02:59, 2011년 10월 25일 (UTC)[응답]
  • 어떤 상황에서 기사를 리디렉션할 것인지, 얼마나 자주 할 것인지 구체적인 정보 부족이 발생할 수 있는 문제 때문에 반대한다. 가장 잘 인정된 봇들조차도 총체적인 허가를 요청하기 어려울 수 있기 때문에 어떤 종류의 정화 작업에 사용될 것인지 정확히 알고 싶다.이것. --트리스테사 (대화) 21:32, 2011년 10월 25일 (UTC)[응답]

• • 필요한 경우 사례별로, 흔하지는 않지만 발생한다.나는 봇이 아니며 이것은 봇 요청이 아니라는 것을 알아두십시오.ΔT 21:36, 2011년 10월 25일 (UTC)[응답]

• 반대, 충분히 구체적이지 않다.25개의 기사를 리디렉션하는 것은 일반적인 편집 행동과는 거리가 멀다.만일 여기서 지난 24개의 예를 증명해 보이고 연장을 요청하는 요청이 온다면 나는 델타의 '전향을 위한 조항'의 특정 사례를 지지하고 싶지만, 단순히 그의 제한에 대한 면제를 선제적으로 공표하는 것만으로는 득이 되지 않는다고 본다.테크노심비오시스 (대화) 04:47, 2011년 10월 25일 (UTC)[응답]
  • 동의한다. "Δ는 기사를 편집할 수 있다"라고 덧붙이는 것이 좋을 것이다.have mörser, 여행 (대화) 05:01, 2011년 10월 25일 (UTC)[응답]
• 델타항공은 분명히 기사를 리디렉션할 수도 있지만 많은 수의 기사를 빠르게 리디렉션하는 것은 방해가 될 수 있다.필요한 경우 리디렉션 작업을 위한 특정 대규모 작업에 대한 승인을 얻으십시오.프람 (토크) 07:11, 2011년 10월 25일 (UTC)[응답]
• 위와 같이 반대하다대체적으로 정말 나쁜 생각이야.호빗 (토크) 2011년 10월 25일 (UTC) 10시 31분[응답]
• 지원 위의 코멘트는 요점을 놓치고, 결국 베타는 25개의 리디렉션을 수정하여 더 많은 논란을 일으킬 수 있다.이 제안들은 베타가 개입해서 "패턴(pattern)"이 있다고 말하는 것에서부터 CBM 등이 없는 어떤 일을 할 수 있도록 하기 위한 것으로, 베타가 다시 잠기게 된다.알파_Quadrant 14:47, 2011년 10월 25일 (UTC)[응답]

그런 다음 (합리적이지만 무작위적인 숫자):

Δ는 적절한 리디렉션으로 기사를 변경할 수 있다(그러나 순차적으로 10개 이하, 하루에 50개 이하).(iii)

그렇지 않으면 이것은 '마지막 100개 편집에서 26개의 기사를 리디렉션했다'라는 지경에 이르게 될 것이고, 그렇지 않다면, '마지막 100개 편집 중에 26개의 이미지를 제거했다'는 패턴도 아니다. - 분명히 내 버전을 뒷받침한다. --Dirk Beetstra 15:06, 2011년 10월 25일 (UTC)[응답]

만약 그가 하루에 50개를 해야 한다면, 그는 사람들이 검토할 구체적인 목록을 가지고 돌아와야 한다.우리는 그에게 1,500개의 나방을 더 이상 검토하지 않고 바꾸는 것을 전면적으로 허락해서는 안 된다.— 칼 (CBM · talk) 15:20, 2011년 10월 25일 (UTC)[응답]

나는 더 낮은 숫자에 동의할 수 있다 - 연속해서 5개, 하루 10개, 매월 100개? --Dirk Beetstra 15:23, 2011년 10월 25일 (UTC)[응답]

• @Carl; 맞아, 그러니까 승인을 받더라도 승인을 받아야 해. --Hammersoft (대화) 15:25, 2011년 10월 25일 (UTC)[응답]

기사를 리디렉션으로 적절하게 변경하려는 내 생각은 다음을 포함한다.

• 인용문 확인, 두 용어가 실제로 동의어임을 증명해야 하는 경우
• 대상 토크 페이지로 병합해야 하는 유용한 자료가 있는 토크 페이지가 있는지 확인
• 기사의 현재 버전이 일치하는지 여부를 확인하기 위해 기사 기록을 확인하거나, 아무도 보지 않을 때 몰래 끼어 들었다.

그래서 나는 이런 유형의 신속한 변화를 부적절하다고 생각할 것이다.하지만 각각의 변화에 적절한 주의를 기울인다면, 좋아.Jc3s5h (대화) 15:35, 2011년 10월 25일 (UTC)[응답]

• 논평 / 약한 반대.수동 병합(모든 범주가 병합되었는가?문자 다 보내세요?때로는 한 문장이라도 유익하다.동시에 베타는 물론 다른 사람이 할 수 있어야 하는 것처럼 마음대로 수동으로 프로드, 병합, 리디렉션 등을 할 수 있다. -- -- 18:_{Piotr Konieczny aka Prokonsul Piotrus talk to me}09, 2011년 10월 25일 (UTC)[응답]
• 반대 베타가 많은 페이지를 리디렉션하려면 사례별로 별도의 승인을 얻어야 한다.먼 미래의 어느 시점에서 누군가가 26개의 완전히 분리된 리디렉션을 다시 셀 것이라는 제안은 터무니없다고 말한다.프라나맥스 (대화) 2011년 10월 25일 (UTC) 19:04 [응답]
• 반대하라 나는 왜 당신이 25개 이상의 기사로 이 일을 해야 하는지 합리적인 시간 동안 이해할 수 없다. -- 지우개헤드1 <토크> 19:44, 2011년 10월 25일 (UTC)[응답]

• 나는 너무 짧은 페이지를 검토할 수 있는 도구를 가지고 있다. 그 결과들을 검토할 때 하루에 5-10개의 태그를 다는 것이 드물지 않다. 만약 내가 그렇게 한다면, 한 달에 40개의 기사가 25개의 제한을 넘는다고 말한다.누군가 따라와서 불평할 것이고, 그 결과 또 다른 차단이 생기게 될 것이다.ΔT 19:47, 2011년 10월 25일 (UTC)[답글]

• 너무 애매모호하게 반대하다.– 루나 산틴 (토크) 22:40, 2011년 10월 25일 (UTC)[응답]
• 반대한다. 이것은 일괄적으로 해야 할 일이 아닌 것 같다.그런 경우가 많다면 아마 사례별로 처리해야 할 것이다.칼다리 (대화) 06:37, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #12

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의는 명시된 제한에 따라 요청하는데 있어 그를 대신하여 운용하는 것에 대한 그의 동의 [20]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 중복 참조를 수정할 수 있다.(예: "제3회 베르호브나"에 나오는...")

Δ를 대신하여 --Hammersoft (대화) 14:06, 2011년 10월 25일 (UTC)

다음은 WP:CITEVAR 문제, 베타는 하나의 기준 스타일에서 다른 기준 스타일로의 대규모 변경을 수행해서는 안 된다.기사에 명명된 참조를 사용할 요건은 없으며, 매번 참조를 반복하는 것은 원칙적으로 허용된다.— 칼 (CBM · talk) 14:33, 2011년 10월 25일 (UTC)[응답]

• 지원, 명명된 참조는 기사를 읽기 쉽고 편집하기 쉽게 만든다.중복된 정보는 재난의 벡터다.--SerkOfVulcan (대화) 15:18, 2011년 10월 25일 (UTC)[응답]
• 지원 --Dirk Beetstra 15:23, 2011년 10월 25일 (UTC)[응답]
• 편집 요약을 더 기술적으로 만들 경우 조건부 지원. --Jc3s5h (대화) 15:40, 2011년 10월 25일 (UTC)[응답]
• 지지하다.이것은 프로젝트에 유익하다. 베타는 내가 경험한 바로는 EOT에서 참조를 잘하고 있는 것 같다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 지원은 확실히 유용하다. -- 지우개헤드1 <토크> 19:43, 2011년 10월 25일 (UTC)[응답]
• 반대. 모두에게 적용되는 스탠딩 가이드라인을 위반하여.김메투(토크) 21:12, 2011년 10월 25일 (UTC)[응답]
• 유감스럽게도 더 구체적이지 않은 한 반대하라 - 나는 중복 참조를 대규모로 수정하는 것이 바람직하지 않기 때문에 반대한다. 하지만 Δ가 편집 논리와 일치하는 "중복"의 정의에 동의하도록 하는 것은 어려울 수 있다; 그는 패턴 매칭 se에서 중복 참조로 보이는 관점에서 그것을 볼 가능성이 있다.nse, 개인의 판단에 근거하여 하는 것과는 반대로 아마도 제목/ISBN에 의한 것일 것이다.그는 물론 이 분야에서 어떠한 승인도 받지 않고 수작업으로 편집할 수 있다.만약 "Δ는 의도적으로 기사에 중복되지 않는 참조를 그룹화하여 수정할 수 있지만, 그 인용문이 적어도 서지학 내용에서 사실상 동일할 때만 수정할 수 있다"와 같은 문구가 쓰여진다면, 나는 지지할 것이다. --Tristessa (talk) 21:39, 2011년 10월 25일 (UTC)[응답]

• 내가 중복 참조를 언급할 때 나는 정확한 듀피를 언급한다.<ref>1</ref>1</ref>1 ΔT 21:51, 2011년 10월 25일 (UTC)[응답]

• 정확한 중복 항목에 대한 조건부 지원. 유용한 요약을 사용할 경우.– 루나 산틴 (토크) 22:41, 2011년 10월 25일 (UTC)[응답]
• 정확한 중복에 대한 지원.이에 대한 지원은 ref 태그 뒤의 텍스트가 약간 다르기 때문에 명명된 ref를 두 개의 다른 ref로 분할하여 그 반대편에 대한 지원을 의미하지 않는다는 점에 유의하십시오(이러한 작업이 수행되는 것을 보았으므로 이 주의사항을 추가함).참고: 필요 없는 한 참조 이름을 큰따옴표 안에 넣지 마십시오.프람 (토크) 14:04, 2011년 10월 26일 (UTC)[응답]
• 반대한다. CBM이 말했듯이, 명명된 참고문헌의 사용은 선택사항이며 이것은 CITEVAR의 문제다. 기사에 따라 이것은 전적으로 부적절할 수 있다.크리스토퍼 파럼 (토크) 2011년 10월 27일 00:45 (UTC)[응답]
• CITEVAR에 반대한다.또한, 많은 기사에서, 작가들은 ref에 대한 이름 지정 시스템을 가지고 있다. - 에 완전히 다른 이름 지정 시스템을 추가하는 것은 해당 기사를 편집하는 사람들을 혼란스럽게 할 수 있다.카라낙스 (대화) 2011년 10월 28일 16시 45분 (UTC)[응답]
• 참고문헌을 표준화하는 것에 반대하는 것은 많은 일을 필요로 한다.빨리 할 수도 없고 대본으로도 할 수 없다.Per Karanacs 나는 종종 이름="Lastname(Year)Pagenumber" 표준을 사용한다. --Guerillero My Talk 21:49, 2011년 10월 29일 (UTC)[응답]
• WP별 반대:특히 CITEVAR, 그리고 작업 #1과 #3에 대한 나의 주장에 따르면 광범위하게.테크노심비오시스 (토크) 00:30, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #13

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [21]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 맨 URL에 제목을 추가하고 필요한 경우 참조로 인라인 링크를 변환할 수 있다.(iii)

Δ를 대신하여 --Hammersoft (대화) 14:11, 2011년 10월 25일 (UTC)

• 지원, 안 할 이유 없어. --SerkOfVulcan (대화) 15:19, 2011년 10월 25일 (UTC)[응답]
• 지원 --Dirk Beetstra 15:24, 2011년 10월 25일 (UTC)[응답]
• "필요한 경우" 부분에 자동화 오류가 없는 한 논란의 여지가 없는 것으로 나타남(외부 링크 섹션, infobox 등)have mörser, 여행 (대화) 16:22, 2011년 10월 25일 (UTC)[응답]
• 댓글을 달다.그러나 나는 WP가 다음과 같다.REFLINKS는 그가 고용한 어떤 스크립트보다 그것을 더 잘하기 때문에 조건부 지원은 REFLINKS만큼 그의 대본이 훌륭하며, 그렇지 않다면 조건부 반대한다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} -- 18:13, 2011년 10월 25일 (UTC)[응답]

그가 사용하는 스크립트는 기술적으로 RefLinks의 일반 수정 기능이며, 스크립트 형식에서만 사용할 수 있다.유일한 차이점은 그의 대본이 자동으로 전체 참고자료를 작성하지 않는다는 것이다.알파_Quadrant 18:58, 2011년 10월 25일 (UTC)[응답]

• 유용한 작업을 지원한다. -- 지우개헤드1 <토크> 19:42, 2011년 10월 25일 (UTC)[응답]
• 지지하다.주의 깊게 처리하면 이 문제에 대한 잠재적 문제가 보이지 않는다. --트리스테사 (대화) 21:42, 2011년 10월 25일 (UTC)[응답]
• 피오트르당 조건부 지원.– 루나 산틴 (토크) 22:43, 2011년 10월 25일 (UTC)[응답]
• 아주 조건부적인 지지, 기울어진 반대.이것은 몇 가지 주의사항으로 해야 한다.이런 일은 피해야 한다.게다가, 지금까지 행해진 일은 자동으로 웹페이지 제목을 가져다가, 그것을 URL 제목으로 하는 것이었다.그러나, 이것은 종종 괜찮지만, 다른 경우에서 이것은 "Nathan Kelley, ISBN 978613356892 - 책, 할인 책, 싸구려 책, 호주 서점 - 엠포륨 책"과 같은 다소 홍보 언어를 낳는다[22].우리는 그런 종류의 URL 타이틀을 원하지 않아, 내 생각엔...프람 (토크) 2011년 10월 26일 14시 10분 (UTC)[응답]
• 골리-고쉬, 이건 실제로 백과사전을 발전시켜!물론: Beta가 GIGO 문제가 없는지 출력을 확인하여 책임감 있게 이 작업을 수행할 수 있다면, Beta는 1분에 10,000번 할 수 있다.Chris Cunningham (사용자:thumperward) - 토크 14:27, 2011년 10월 26일 (UTC)[응답]
• 프람이 제기한 문제마다 반대하라.만약 델타가 그의 25개 조항 제한 내에서 이것을 바로잡을 수 없다면, 나는 그가 그 제한을 해제한 상태에서 어떻게든 그것을 더 올바르게 할 것이라고 믿지 않는다.테크노심비오시스 (대화) 22:22, 2011년 10월 26일 (UTC)[응답]

예전에 이런 일을 하는 봇이 있지 않았는가?카라낙스 (대화) 16:49, 2011년 10월 28일 (UTC)[응답]

사용자:DumZiBoT.여기서 시사하는 바는 Reflinks가 불완전하고 정말로 인간의 감독이 필요하다는 것이다; 봇들은 너무 자주 실수를 한다.이상적으로는 베타가 이 일을 할 수 있다고 믿을 수 있고, 그것은 현재 목록에 있는 대부분의 제안보다 훨씬 더 유용하다.크리스 커닝햄 (사용자:thumperward) - 토크 08:47, 2011년 10월 29일 (UTC)[응답]

Δ 제안 과제 #14

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [23]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 WP에 따라 장치에 비파괴 공간을 추가할 수 있다.NBSP . (예)

Δ를 대신하여 --Hammersoft (대화) 14:17, 2011년 10월 25일 (UTC)

• 지원, 안 할 이유 없어. --SerkOfVulcan (대화) 15:20, 2011년 10월 25일 (UTC)[응답]
• 지원, 표시된 결과에 중대한 영향을 미치는 편집의 일부분. --Dirk Beetstra 15:24, 2011년 10월 25일 (UTC)[응답]
• 예시대로 반대하라.이 예제는 숫자와 철자가 표시된 단위 이름 사이에 경직된 공간을 배치하는 반면 WP는 다음과 같다.NBSP는 단지 숫자와 약어 사이에 그것들을 두는 것을 구체적으로 언급하고 있다.또한, 편집 요약은 설명적이지 않다.[이 예는 뉴욕 타임즈의 인용문도 엉망으로 만들고, "접근"을 "접근"하여 "회수"로 바꾼다.인용문 형식이 일관되지 않은 인용문 내에서 단어를 바꾸는 데 드는 노력은 인용문을 일관적으로 만드는 데 더 효과적일 것이다.]Jc3s5h (대화) 15:50, 2011년 10월 25일 (UTC)[응답]

• 인용문 문제(별도 과제)는 제쳐두고, 비파괴 공간 사용 문제는 WP에서 설명한다.NBSP 및 관련.유닛과 라벨을 함께 보관하라. 그것이 포인트다. WP:NBSP가 요청했고, Hammersoft (대화) 15:58, 2011년 10월 25일 (UTC)[응답하라]

• 응, 하지만 어딘가에서 끊어야 해.숫자와 약자 사이의 딱딱한 공간은 아마도 좋은 결과를 낳겠지만, 긴 숫자가 긴 단어 옆에 있을 때는 그렇게 분명하지 않다. WP:NBSP는 숫자와 약어만을 언급함으로써 암묵적으로 그것을 인정하고 있다.Jc3s5h (대화) 18:14, 2011년 10월 25일 (UTC)[응답]

• Δ가 다르게 제안하고 있다고는 생각하지 않는다. --Hammersoft (대화) 19:03, 2011년 10월 25일 (UTC)[응답]

• 숫자와 약자 간의 지원. -- 지우개헤드1 <토크> 19:40, 2011년 10월 25일 (UTC)[응답]

• WP에 따라 제공되는 지원:NBSP는 좁게 해석된다. --트리스테사 (토크) 21:49, 2011년 10월 25일 (UTC)[응답하라]
• Jc3s5h의 우려가 해소되는 한 지원한다.– 루나 산틴 (토크) 22:45, 2011년 10월 25일 (UTC)[응답]

Δ 제안 과제 #15

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의는 명시된 제한에 따라 요청하는데 있어 그를 대신하여 운용하는 것에 대한 그의 동의 [24]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 링크를 보관할 수 있다(웨이백, 웹캐스팅).(예) Δ당, 더 나은 예

Δ를 대신하여 --Hammersoft (대화) 14:20, 2011년 10월 25일 (UTC)

• 지원 --Dirk Beetstra 15:26, 2011년 10월 25일 (UTC)[응답]

• 주의하다.샘플은 변경 중인 인용 템플릿을 사용하지 않는 인용문을 보여준다.아카이빙은 이러한 작업에 수행될 수 있지만 템플릿을 사용하지 않을 경우 자동화가 인용 구문을 구문 분석하는 것이 거의 불가능하기 때문에 거의 또는 전혀 자동화 기능을 사용할 수 없다.인정된 인용 스타일(Chicago Manual of Style)이 사용 중인지, 사용 중이라면 그에 부합하는지 판단할 필요가 있다.또한 보다 정확한 편집 요약을 제공해야 한다.Jc3s5h (대화) 15:57, 2011년 10월 25일 (UTC)[응답]
• 원칙적으로는 괜찮은 것 같다.나는 그 요청이 참고/시민으로 사용되는 URL을 참조한다고 생각한다.have mörser, 여행 (대화) 16:27, 2011년 10월 25일 (UTC)[응답]
• 제공된 구체적인 사례의 빛나는 장점을 바탕으로 반대한다.우리는 이 편집이 일회성 사례에서 주의깊고 의사소통적인 편집자에 의해 특이하게 만들어지는 것을 묵과해서는 안 되며, 우리는 귀찮은 편집자에게 그러한 편집을 매해 20년 단위의 수동적인 사례에서 하도록 포괄적으로 승인해서는 안 되며, 위키피디아에 관한 모든 기사에 이러한 종류의 자동 편집을 하기 위해 Δ 포괄적 허가를 미리 주어서는 안 된다.에디아, WP에선 통과 안 돼BRFA (I wishop)와 마찬가지로 이런 종류의 편집만으로 그러한 문제의 이력이 있는 누군가에 의해 자동화가 되어서는 안 된다(그리고 또 그런 비정보적인 정리 요약이 있다).— JohnFromPinckney (대화) 16:55, 2011년 10월 25일 (UTC)[응답]
• 주어진 예에 반대하라.--사렉OfVulcan (대화) 17:19, 2011년 10월 25일 (UTC)[응답하라]
  • 여전히 반대한다 -- 요점은 그가 때때로 그것을 올바르게 한다는 것이 아니라, 그가 그것을 잘못하고, 어떤 것이 고통스러운지 알아내기 위해 모든 다른 모든 연결고리를 확인해야 한다는 것이다. --SerkOfVulcan (대화) 18:59, 2011년 10월 25일 (UTC)[응답]
• 지지하다.이것은 내가 아는 한 프로젝트인 EOT에 이롭다.두 번째 사례를 검토했는데 큰 도움이 된 것 같다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 반대한다. 사렉에 따르면, 이것은 대량 작업으로 실행될 때 이 점에서 Δ의 모든 작업을 점검해야 할 필요가 있다.어쨌든, 이런 종류의 수정은 (자동화가 되든 반자동화가 되든) 대본적인 정리 작업은 고사하고 손으로 해도 문제가 되고, 나는 이것이 도매로 이루어져야 한다는 편집적인 합의는 없다고 생각한다.향후가 있다면, 나중에 일반 편집 지침으로서 본 작전에 대한 명확한 합의를 재검토해야 한다. --트리스테사 (토크) 21:56, 2011년 10월 25일 (UTC)[응답]
• 반대한다. 이미 이런 일을 하는 봇이 있지 않은가?이미 봇이 다룬 몇 가지 과제를 제안하는 것 같다.--크로스미어(토크) 23:02, 2011년 10월 25일 (UTC)[응답]
• 사렉당 반대하라.25개 기사의 수치의 이유 중 하나는 사람들이 실수가 발생하지 않았는지 확인하기 위해 델타의 작업을 검토할 시간을 주기 위함이다.만약 델타가 그 한계를 넘어서 이것을 할 수 있는 면제를 받게 된다면, 그의 일을 확인하는 것은 훨씬 더 어려워진다.델타가 이러한 변화를 일관성 있고 정확하게 적용한다는 것을 증명할 수 있을 때, 그것은 재고될 수 있다.테크노심비오시스 (대화) 23:08, 2011년 10월 25일 (UTC)[응답]
• 슬프게도 반대한다.첫 번째 예시에 보관된 페이지를 확인했는데, 의미 있는 내용에는 없다.[25. 예, 이것은 아마도 코너 케이스일 것입니다만, 이 작업의 규모를 Δ가 아닌 다른 사람에게 맡기는 것이 가장 좋은 것은 분명합니다 Uʔ (토크) 04:46, 2011년 10월 26일 (UTC)[응답]
• "좋지 않은" 예에 따라 반대하라.또한 404개 오류의 아카이브된 페이지(보관된 이미지)를 충분히 발견하여 수동으로 수행해야 하는 작업임을 알게 되었다.그리고 웨이백의 경우, 어떤 아카이브 버전이 사용되겠는가?ref가 지원하는 텍스트를 추가한 편집자가 특별히 의존하는 버전을 찾아야 한다.프라나맥스 (대화) 17:48, 2011년 10월 26일 (UTC)[응답]

Δ 제안 과제 #16

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 하는 데 있어 그를 대신하여 운용할 수 있다[26]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 도움말에서 설정한 규칙에 따라 템플릿의 " " 위치를 끝 대신 줄의 시작 부분으로 조정할 수 있다.Infobox 및 도움말:infobox 설계 중. (예)

Δ를 대신하여 --Hammersoft (대화) 14:28, 2011년 10월 25일 (UTC)

일반적으로 베타는 기사들의 위키코드 내의 공백을 바꾸는 것을 중단해야 한다.그것은 디프를 읽기 어렵게 만들고 렌더링된 페이지에는 아무런 영향을 주지 않는다.연결된 도움말 페이지 중 어느 것도 infobox의 매개 변수를 포맷하는 방법에 대한 규칙을 설정하지 않는다(그리고 일반적인 도움말: 페이지는 대부분 모든 사람이 무시하기 때문에 매우 권위 있는 참조가 아니다).— 칼 (CBM · talk) 14:36, 2011년 10월 25일 (UTC)[응답]

• Perl별 모범 사례 지원.이해도를 높이는 것은 언제나 좋은 일이다. --SerkOfVulcan (대화) 15:22, 2011년 10월 25일 (UTC)[응답]
• 나머지 편집이 표시된 결과에 유의미한 영향을 미치는 경우 지원. --Dirk Beetstra 15:25, 2011년 10월 25일(UTC)[응답]
• 제안서가 infobox에만 적용되는지 또는 다른 종류의 템플릿에도 적용될 수 있는지 여부가 명확해질 때까지 판단을 보류한다.인용 템플릿의 변경은 과거에 이의를 제기해 왔다.Jc3s5h (대화) 2011년 10월 25일 16:00 (UTC)[응답]
• 반대해. 나는 펄이 이것과 무슨 관계가 있는지 모르겠고, 만약 어떤 기사의 편집자들이 다른 방식으로 그것을 선호한다면, 나는 이 변화를 강요할 이유를 찾지 못했어.have mörser, 여행 (대화) 16:28, 2011년 10월 25일 (UTC)[응답]
  • Perl Best Practices, 페이지 27-28 - "프로그램의 의미적 힌트 대부분이 코드 왼쪽에 나타나 있다...더 깨끗한 해결책은 운영자 앞에 긴 줄을 끊는 것이다.이러한 접근방식은 연속된 표현의 각 행이 연산자로 시작됨을 보장한다. 들여쓰기된 행은 단지 이전 행의 연속이라는 것은 즉시 명백하다.--SerkOfVulcan (대화) 17:16, 2011년 10월 25일 (UTC)[응답]
    • 위키피디아는 펄이 아니다.만약 몇몇 편집자들이 이렇게 생각하기를 원한다면; 변화하기 전의 예에서처럼 보이는 C에서, 그것은 그들의 특권이다.have mörser, will talk (talk) 17:32, 2011년 10월 25일 (UTC)[응답하라]
• 화이트 스페이스 변경은 다른 변경을 보기 어렵기 때문에 동일한 디프트에 다른 변경 사항이 없는 경우에만 화이트 스페이스 개선을 지원하십시오.편집 요약에는 공백 변경만 표시되어야 한다.디클라이언 (대화) 2011년 10월 25일 17시 35분 (UTC)[응답]
• 사용적합성을 검토하기 위해 요약에 "Wikicode 화이트스페이스 픽스만"이라고 명시한 분리된 편집으로 조건부 지원.이렇게 했을 때 지지하지 않을 정당한 이유가 보이지 않지만, 인정하지만, 이렇게 해야 하는 이유를 불타는 이유도 볼 수 없다. --트리스테사 (토크) 21:59, 2011년 10월 25일 (UTC)[응답]
• 공백만 변경하면 조건부 지원. -- 지우개헤드1 <토크> 22:45, 2011년 10월 25일 (UTC)[응답]
• 트리스테사 당 조건부 지원이며, 이것이 infobox에만 적용된다는 전제하에."opt-in" 기준으로 다른 템플리트 토론에 참여하십시오.– 루나 산틴 (토크) 22:47, 2011년 10월 25일 (UTC)[응답]

• 문제는 이러한 공백 편집 자체가 스탠드 단독 편집으로 하기에는 너무 사소한 것이기 때문에 나는 내 일반적인 수정사항으로 그것을 결합하고, 현재는 풋볼(어떤 이유로든 infobox 템플릿 접두사를 사용하지 않는)으로 시작하는 infobox와 템플릿으로 한정되어 있다는 것이다.ΔT 00:29, 2011년 10월 26일 (UTC)[응답]

• 이것들이 독립적으로 편집되어야 하는지에 관한 한, 나는 여기서 어떤 합의가 이루어지든 따를 것이다.만약 그 축구 템플릿들이 연습 중에 있다면, 나는 네가 그것들을 수정해도 괜찮아.– 루나 산틴 (대화) 00:49, 2011년 10월 26일 (UTC)[응답]

• 문제는 대부분의 경우 이러한 사소한 편집이 독립적으로 되어서는 안 된다는 것이 위키의 다른 부분에서 이미 결정되었다는 점이다.그리고 그래, 그 축구 템플릿들은 인포박스와 같이 사용된다.ΔT 00:52, 2011년 10월 26일 (UTC)[응답]

• 반대, 코드 스타일을 '수정'하는 것은 Engvar와 같다.순이익은 없고, 한 스타일을 다음 스타일만큼 선호하는 사람들이 많아서 다수에 맞게 변경이 이루어진다고는 말할 수 없다.내가 그것을 놓쳤을 수도 있지만, 두 도움말 페이지 중 어느 것도 파이프를 새로운 라인에 놓는 것을 언급하지 않고, 그들은 단지 그들의 예에 그 특정한 스타일을 포함시킨다.테크노심비오시스 (대화) 23:13, 2011년 10월 25일 (UTC)[응답]
• 확실한 반대다.나는 C 프로그램을 코딩할 때 닫는 코드 아래 닫는 버팀대를 따로 두고 다음 줄을 뗀다.다른 사람들은 닫는 버팀대를 풀었다.만약 우리가 함께 코드를 작업할 거라면, 우리는 어느 쪽으로든 갈 수 있고, 다른 코드 블록에서 서로의 cnvention을 관찰할 수 있다.하지만 네가 한 유일한 기여가 단지 와서 "더 좋으니까" 내 들여쓰기를 바꾸고 다시는 코드를 건드리지 않는 거라면, 아무 소용도 없다.이것은 유사한 상황이다.또한 도움말 페이지는 표준을 전혀 설정하지 않는다.프라나맥스 (대화) 17:56, 2011년 10월 26일 (UTC)[응답]
• 반대하라; 내가 알기로는 정해진 관습은 없다 - 이것은 단지 빈칸의 헛소리일 뿐이다.크리스토퍼 파럼 (대화) 00:50, 2011년 10월 27일 (UTC)[응답]
• 왜 이것이 이루어져야 하는지 정말 정당한 이유 없이 반대하라.프로그래머마다 다른 포맷을 선호한다.카라낙스 (대화) 16:52, 2011년 10월 28일 (UTC)[응답]
• 클로징 파이프의 어느 쪽으로든 프로그래머에게 달려있다.그가 다른 스타일의 뒤죽박죽이 되어 코드를 표준화하는 것이 아니라면, 그것은 잘못되어서는 안 된다.각 개인마다 코딩 스타일이 다르다. --게릴레로 My Talk 21:45, 2011년 10월 29일 (UTC)[응답]
• 반대. 이건 편집의 낭비야.칼다리 (대화) 06:40, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #17

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [27]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 기준들이 순차적이^[1][5][3] 되도록 기준의 순서를 정할 수 있다^[1][3][5].(iii)

Δ를 대신하여 --Hammersoft (대화) 14:31, 2011년 10월 25일 (UTC)

또 다른 WP:CITEVAR.일반적으로 참조 번호는 순차적이어야 한다는 규칙은 없으며, 기사가 다른 스타일을 확립했다면 베타 선호에 의해서만 변경되어서는 안 된다.— 칼 (CBM · talk) 14:37, 2011년 10월 25일 (UTC)[응답]

• 지원 나는 대부분의 경우에 이것은 고의적인 선택이라기 보다는 부주의로 인한 결과라고 가정할 수 있다. 그래서 고치지 않을 이유가 없다. --SerkOfVulcan (대화) 15:24, 2011년 10월 25일 (UTC)[응답]
• 지원, 나머지 편집도 페이지 표시에 상당한 영향을 미칠 경우. --Dirk Beetstra^{T C} 15:26, 2011년 10월 25일(UTC)[응답]
  • 우리가 정말 이 사건에서 그 머리칼을 쪼개고 싶은가?기사를 좀 더 전문적으로 보이게 하는 효과가 있는데, 왜 우리가 다른 변화가 충분한지 걱정해야 하는가? --SerkOfVulcan (토크) 15:36, 2011년 10월 25일 (UTC)[응답]
    • '이번 사건에서 정말 그 머리칼을 쪼개고 싶은가?'다른 곳에서 말했듯이 WP는:콩이 심어졌다, 또 다른 패턴이 나타나기를 기다리고 있다. --Dirk Beetstra 07:29, 2011년 10월 26일 (UTC)[응답]
• 요약 편집 필요.편집의 성격이 디프에서 전혀 뚜렷하지 않기 때문에 의미 있는 편집 요약이 필수적이다.Jc3s5h
• 지지하다.사소한, 그러나 왜 안 되는가 - 특히 더 큰 편집의 일부인 경우 ----_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 18:15, 2011년 10월 25일 (UTC) (토크) 16:04, 2011년 10월 25일 (UTC)[응답]
• 확실히 확실히 유용한 지원. -- 지우개헤드1 <토크> 19:38, 2011년 10월 25일 (UTC)[응답]
• 아니. 이것은 일반적으로 해서는 안 된다.김메투(토크) 21:29, 2011년 10월 25일 (UTC)[응답]
• 지원, 충분히 공평하게. --트리스테사 (대화) 22:00, 2011년 10월 25일 (UTC)[응답]
• 나는 Δ가 이 청소를 하는 것을 가장 먼저 고려하는 사람이라는 것을 상상할 수 없다.그것에 대해 다른 논의가 있었니?왜 봇이 그것을 하지 않는가?U u (토크) 22:26, 2011년 10월 25일 (UTC)[응답]
• 유용한 요약이 사용될 경우 지원.나는 이 편집이 실제로 독립적이어야 한다고 생각한다. 그렇게 하면 페이지의 기록을 더 쉽게 검토할 수 있기 때문이다.– 루나 산틴 (토크) 22:48, 2011년 10월 25일 (UTC)[응답]
• 위에서 반대하는 코멘트 외에, 이것은 극단적으로 사소한 변화고 불필요한 변화다.--크로스미르 (토크) 22:59, 2011년 10월 25일 (UTC)[응답]
• 이 과제는 그 프로젝트에 입증 가능한 이익을 거의 제공하지 않는다.Chris Cunningham (사용자:thumperward) - 토크 14:30, 2011년 10월 26일 (UTC)[응답]
• 반대한다. 일반적으로 이것은 CBM에 의해 맹목적으로 수행되어서는 안 된다.크리스토퍼 파럼 (대화) 00:53, 2011년 10월 27일 (UTC)[응답]
• 나는 편집상의 이유로 이 일이 전혀 이루어져야 한다고 확신하지 않기 때문에 반대하라.나에게 있어서, 뒷받침하는 각주는 범위와 관련성에 따라 정렬되어야 한다.ref-5가 출처에 인용된 전체 텍스트와 가장 직접적으로 관련성이 있으며(모든 단락 또는 문장), ref-1이 추가로 몇 개의 다른 부분을 지원하고, ref-3가 마지막 문장이나 구절에서 더 나은 표현을 지지한다면, 정확한 순서는 독자가 다음과 같은 순서로 출처를 확인할 수 있기 때문에 [5][1][3]이다.독자들이 가장 유용하다고 여길지도 모른다.기사에서 처음 인용된 출처가 더 아래로 내려갈 때마다 정리하는 것이 얼마나 부질없는 일인지는 말할 것도 없고, 예쁘게 보이는 기사들은 지식 다음으로 다가온다.나는 가끔 그 범위와 공개 규칙에 따라 단락을 변경할 때 나를 다시 주문한다. 하지만 그것은 편집상의 결정이다.Framanax (대화) 00:55, 2011년 10월 27일 (UTC)[응답]
• Framanax 당 반대한다.인라인 참조의 순서를 지배하는 현재의 표준은 없으며, 중요도에 따라 그것들을 주문하는 것은 임의로 '수정'되어서는 안 되는 완벽하게 유효한 스타일인 것 같다.테크노심비오시스 (대화) 22:32, 2011년 10월 27일 (UTC)[응답]
• Framanax당 반대 --Guerillero My Talk 16:47, 2011년 10월 28일 (UTC)[응답]

• 반대해. 내가 기사 텍스트를 재정렬하는 중인데 누가 와서 내가 끝나기 전에 출처를 재주문해서 순서를 잘못 잡으면 나는 상당히 실망할 거야. (난 이런 일을 많이 해.)이것은 본문과 소싱에 정통한 기사 편집자들에게 정말로 맡겨둘 필요가 있는 것이다.카라낙스 (대화) 2011년 10월 28일 16:57 (UTC)[응답]

Δ 제안 과제 #18

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 할 때 그를 대신하여 운용할 것 [28]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 유지관리 템플릿의 날짜를 정할 수 있다.(예: {{POV 날짜=2011년 9월})

Δ를 대신하여 --Hammersoft (대화) 15:07, 2011년 10월 25일 (UTC)

이 일을 자동으로 하는 봇은 이미 존재하기 때문에 베타 역시 대규모로 이 일을 시작할 이유가 없다.— 칼 (CBM · talk) 15:18, 2011년 10월 25일 (UTC)[응답]

• 페이지 표시에 중요한 영향을 미치는 페이지의 다른 편집이 있는 경우 지원.{Δ가 동일한 Δ로 할 수 있다면 2번 편집할 필요가 없다. --Dirk Beetstra 15:28, 2011년 10월 25일 (UTC)[응답]
• 베스트라별 지원--사렉OfVulcan (대화) 15:38, 2011년 10월 25일 (UTC)[응답]
• 베스트라별 지원.이것은 편집 요약을 통해 편집에 대한 다른 이유만 문서화하는 것으로 충분하다고 생각할 수 있는 차이점을 보는 동안 충분히 명백하다.Jc3s5h (대화) 16:06, 2011년 10월 25일 (UTC)[응답]
• 편집 직후에 실제로 이것을 하는 몇몇 봇들이 있다; 나는 그것들이 어떻게든 유발된다고 생각한다.하지만 나는 Δ가 그들과 경쟁하도록 내버려두는 것에 아무런 해가 없다고 본다.지지하다.뫼르서, 여행 (대화) 16:38, 2011년 10월 25일 (UTC) [편집 : 크리스 커닝햄이 전에는 생각하지 못했던 이의신청을 등록하였으므로 이제는 무질서하게 하지 않는다.16:34, 2011년 10월 26일 (UTC)][응답하라]
• 지지하다.물론이지, 왜? --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC) 18:15, 25[응답]
• 지원 왜 안 되는가? -- 지우개헤드1 <토크> 19:35, 2011년 10월 25일 (UTC)[응답]
• 지지하다.그도 그럴 것이다. --트리스테사 (대화) 22:03, 2011년 10월 25일 (UTC)[응답]
• 지원 간단하다.– 루나 산틴 (토크) 22:48, 2011년 10월 25일 (UTC)[응답]
• 이것은 내 작업 흐름을 심각하게 망칠 것이다.만약 내가 도움이 되는 픽시봇이 내 기사를 편집한 마지막 편집자임을 알게 된다면, 나는 도움이 되는 픽시봇이 단지 작고 잘 테스트된 작업만 수행했다고 믿기 때문에 편집 검사를 하지 않을 것이다.나는 또한 유한한 인간 편집자 집단에 대해서도 그것을 믿을 수 있다.베타 명령은 그 중 하나가 아니다.이것은 신뢰할 수 있는 봇에게 맡겨야 한다.Chris Cunningham (사용자:thumperward) - 토크 14:32, 2011년 10월 26일 (UTC)[응답]
  • 음, 그런 생각은 안 해봤어.아마도 Δ가 동일한 편집에서 기사의 또 다른 변경과 함께만 한다면 논란의 여지가 없을 것이다.U u (토크) 16:34, 2011년 10월 26일 (UTC)[응답]
    • 나는 그가 다른 변경을 동시에 할 것이기 때문에 무엇이 바뀌었는지 보기 위해 편집을 검토할 필요가 있다는 것이 정확히 우려된다고 생각한다.동시에, 편집의 유일한 변화로서 그가 이것을 할 이유는 없다, 왜냐하면 두 개의 봇이 이미 하고 있기 때문이다.— 칼 (CBM · talk) 16:40, 2011년 10월 26일 (UTC)[응답]
  • Δ가 템플릿의 날짜를 잘못 맞출 것으로 예상하십니까?왜? 아마도 내가 오해하고 있는 것 같아.– 루나 산틴 (토크) 20:51, 2011년 10월 26일 (UTC)[응답]
    • 칼이 못을 박았다.베타가 데이트 태그로만 편집하는 것은 의미가 없다. 왜냐하면 우리는 이미 이것을 하는 적어도 두 개의 믿을 수 있는 진정한 봇을 가지고 있기 때문이다.그래서 그가 어쨌든 그것을 하고 있다면, 그것은 해머소프트가 그를 강력한 지역사회의 합의에 대항하여 재통합하기를 바라는 백오툴의 일부일 것이다. 그리고 그 안에는 내가 아노미봇과 같은 것을 믿는 것보다 훨씬 적은 베타를 신뢰하는 도구가 있다.최종 결과는 잠재적으로 내가 현재 하고 있는 것보다 더 많은 페이지의 마지막 편집 내용을 다시 확인해야 한다는 것이다.간단히 말해서, 베타에게 봇들이 이미 잘 하고 있는 편집권을 부여할 이유가 전혀 없으며, 이것은 특별히 나쁜 사례다. 왜냐하면 나는 알려진 좋은 봇이 드라마 없이 지금 당장 나의 편집내용을 따라다니기를 강력히 기대하고 있기 때문이다.크리스 커닝햄(사용자:thumperward) - 토크 21:51, 2011년 10월 26일 (UTC)[응답]
      • 이는 메타 토론에서 해결하기에 좋은 지적일 수 있다. 그렇다면 일반적으로 Δ는 현재의 봇이 동등하게 다룰 수 있는 편집을 해야 하는가?일반적으로 편집자는 그러한 변경을 하는 것이 금지되어 있지 않지만, 만약 내가 당신의 요점을 약간 바꾸어 말하면, 당신의 감시 목록에서 Δ를 반복해서 보는 것이 당신의 작업 흐름을 방해한다는 것을, 많은 다른 사용자들도 같은 방식으로 느낄 수 있고, 따라서 우리는 그러한 작업 중단을 완화시키는 방법을 고려할 수 있다.Δ의 편집 내용을 정기적으로 다시 확인하기를 원하는 사람이라면 누구나 유사한 우려를 공유할 수 있다.그게 공정한 요약인가?– 루나 산틴 (토크) 22:54, 2011년 10월 26일 (UTC)[응답]
        • Δ에게 봇 깃발을 주라고?U u (대화) 23:37, 2011년 10월 26일 (UTC)[응답]
        • 충분히 가까이.일반적으로 편집자들은 봇과 같은 편집을 하는 것이 금지되지 않는다. 왜냐하면 일반적으로 편집자들은 그렇게 함으로써 몇 년 동안 반복적으로 엄청난 양의 드라마를 야기시키지 않았기 때문이다.이 시점에서, 나는 베타 커맨드를 내가 믿는 대부분의 봇들보다 훨씬 덜 신뢰한다. 이 봇들이 ANI로 달려가 복수에 대해 소리 지르지 않고도 그들이 잘못 행동한다면 최소한 막을 수 있다.그 프로젝트는 우리가 진짜 봇들이 할 수 있다고 알고 있는 베타 복제 작업을 함으로써 아무 이득도 얻지 못한다.반면에, 이런 유형의 "잘 알려진 편집"은 베타의 기부 리스트의 필러 역할을 한다; 그것은 둘 다 관심 있는 당사자들이 베타의 작품을 면밀히 조사하는 것을 더 어렵게 만들고, 그를 옹호하기 위해 다음 번 그들이 등장할 때 인상적이긴 하지만 궁극적으로 쓸모없는 선의의 증거를 그의 지지자들에게 준다.크리스 커닝햄 (사용자:thumperward) - 토크 07:25, 2011년 10월 27일 (UTC)[응답]
• Chris Cunningham에 의해 반대 - Guerillero My Talk 16:51, 2011년 10월 28일 (UTC)[응답]
• 반대한다. 이 작업은 이미 봇에 의해 수행되고 있으며 편집 작업에서 유일한 작업이기 때문에 다른 편집자들이 무슨 일이 일어나고 있는지 알아내는 것이 훨씬 쉽다.카라낙스 (대화) 16:59, 2011년 10월 28일 (UTC)[응답]
• 반대한다, 이렇게 하는 봇은 페이지 기록과 요약 편집에서 단일 목적이며 쉽게 식별할 수 있으며, 디프를 직접 볼 필요 없이 특정 편집을 포함하도록 신뢰할 수 있다.델타에 대량으로 이것을 하도록 하는 것은 편집자들이 편집하는 것을 검토하는 데 소비하는 시간을 크게 증가시킬 것이며 '봇보다 먼저 들어가라'는 것 외에는 별 도움이 되지 않을 것이다.대체로, 1번과 3번 작업에서 나의 코멘트를 보아라.테크노심비오시스 (대화) 00:36, 2011년 11월 1일 (UTC)[응답]

Δ 제안 과제 #19

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의에 따라 해당 제한에 따라 요청을 하는 데 있어 그를 대신하여 운용할 수 있다[29]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 잘못 배치된 템플릿의 위치를 고정할 수 있다(Ref 외부 데드링크, 그 안에 있어야 할 때 등).

Δ를 대신하여 --Hammersoft (대화) 15:09, 2011년 10월 25일 (UTC)

• 지원 --Dirk Beetstra 15:28, 2011년 10월 25일 (UTC)[응답]

• 지원 Jc3s5h (대화) 16:07, 2011년 10월 25일 (UTC)[응답]
• 반대. 너무 막연해.have mörser, 여행 (대화) 16:32, 2011년 10월 25일 (UTC)[응답]

• 이것은 주로 참조에 포함되어야 하는 데드 링크와 실패 확인과 같은 템플릿에 사용된다. 그러나 어떤 이유로 인해 참조가 언급하는 참조 밖에 배치된다. (그리고 유사한 경우).ΔT 19:25, 2011년 10월 25일 (UTC)[응답]

• {{실패한 검증}}}}은(는) 통상적으로 그 안에 포함되지 말고 ref 밖에 배치해야 한다고 생각한다.이 템플릿의 요점은 본문의 독자에게 그 문장이 평소처럼 신뢰할 수 없을 수도 있다는 것을 알리는 것이다.그래서 제안된 운동의 템플릿 목록과 방향이 명시되지 않는 한, 나는 이 포괄적인 제안을 지지할 수 없다.[지금 사용자 이름을 바꿨어.] 【例(토크)】20:37, 2011년 10월 25일(UTC)】[응답]

• 지지하다.이것은 내가 아는 한 프로젝트 EOT에 이롭다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 지원은 지극히 합리적이고 논란의 여지가 없는 것 같다. -- 지우개헤드1 <토크> 19:31, 2011년 10월 25일 (UTC)[응답]
• 너무 광범위하게 반대 - 보다 구체적인 범위로 재구성한 "절대 Δ는 기사 위키코드 내의 템플릿을 모호하게 잘못 배치하고 결과를 검토한다면 적절한 계층적 위치로 이동할 수 있다." --트리스테사 (talk) 22:07, 2011년 10월 25일 (UTC)[응답]
• 반대, 너무 모호하다.구체적인 내용에 대해 토론할 수 있다.– 루나 산틴 (토크) 22:49, 2011년 10월 25일 (UTC)[응답]
• 너무 애매모호하게 반대하다.이러한 요청은 델타항공에 포괄적 면제를 제공하기 위한 것이 아니라, 델타항공이 의도하는 구체적인 변화를 검토할 수 있는 기회를 지역사회에 주기 위한 것이다.테크노심비오시스(대화) 23:16, 2011년 10월 25일 (UTC)[응답]
• 너무 모호해.그러나 특정 사례(예를 들어, 정리 태그 아래의 주석)는 면제될 수 있다.Chris Cunningham (사용자:thumperward) - 토크 14:35, 2011년 10월 26일 (UTC)[응답]

Δ 제안 과제 #20

에 따라

• Δ의 편집 제한의 첫 번째 글머리 기호 항목,
• Δ에 의한 동의는 명시된 제한에 따라 요청하는데 있어 그를 대신하여 운용하는 것에 대한 그의 동의 [30]
• 이 요청에 적용될 수 있는 기타 편집 제한 사항 준수

다음과 같은 편집 요청이 이루어지고 있다.

Δ는 필요에 따라 템플릿을 {{복수 이슈}}에 결합할 수 있다.

Δ를 대신하여 --Hammersoft (대화) 15:12, 2011년 10월 25일 (UTC)

• 내 생각엔 다른 봇들도 그런 것 같아.페이지 표시에 중요한 영향을 미치는 편집의 일부인 경우 지원하십시오.Δ가 같은 편집으로 할 수 있다면 2번 편집할 필요가 없다. --Dirk Beetstra 15:29, 2011년 10월 25일 (UTC)[응답]
• 그래서 우리는 마침내 그가 봇과 같은 일을 하고 있다는 것을 인정하고 있다.사실, 나는 이것을 지지한다.논쟁의 여지가 없는 일이고, 이런 일에서 실수하는 것은 어렵다고 생각한다.have mörser, 여행 (대화) 16:35, 2011년 10월 25일 (UTC)[응답]
• 지지하다.이것은 내가 아는 한 프로젝트 EOT에 이롭다. --_{Piotr Konieczny aka Prokonsul Piotrus talk to me} 2011년 10월 25일 (UTC)[응답]
• 지원은 확실히 유용하다. -- 지우개헤드1 <토크> 19:34, 2011년 10월 25일 (UTC)[응답]
• 지원, 문제없음. --트리스테사 (대화) 22:08, 2011년 10월 25일 (UTC)[응답]
• 지원 – Luna Santin (토크) 22:49, 2011년 10월 25일 (UTC)[응답]
• 지원, 유용하다.프람 (토크) 14:39, 2011년 10월 26일 (UTC)[응답]

• 만약 봇이 이미 이것을 그것의 단일 작업으로 한다면, 봇이 계속 하게 두어라.그것은 편집자로서 내가 무슨 일이 일어나고 있는지 한눈에 볼 수 있게 해 준다.카라낙스 (대화) 17:01, 2011년 10월 28일 (UTC)[응답]
• 과제 #18에서 나의 주장에 따라 반대하라.만약 봇이 이미 이렇게 한다면, 그것은 그것의 다양성을 검토하는데 시간을 소비하지 않고 어떤 변화가 일어났는지 알 수 있는 지역사회의 확립된 신뢰를 이미 가지고 있다.델타는 이러한 신뢰가 없으며, 만약 그가 이러한 작업을 봇에게 맡기지 않고 수행한다면 편집자들이 편집한 내용을 검토하는 데 드는 시간을 크게 늘릴 것이다.작업 #1 및 #3의 내 의견을 참조하십시오.테크노심비오시스 (대화) 00:39, 2011년 11월 1일 (UTC)[응답]

향후 추가 제안

이들 중 일부는 실체가 있고 위와 달리 그의 '정리' 과정에서 실제 논란을 일으킨 인물에 속한다.그의 토크 페이지에는 약 25개의 과제가 수록된 리스트 초안이 나와 있는데, 나는 그의 현재 블록이 그가 이곳에 게시하는 것을 방해하고 있다고 생각한다.have mörser, 여행 (대화) 10:17, 2011년 10월 25일 (UTC)[응답]

요약 제안 편집

Δ는 지역사회의 감시와 검토를 지원하기 위해 WP:VPP가 승인한 작업을 수행할 때 기술 편집 요약을 사용해야 한다.Δ는 작업, 특성 또는 자동화가 다른 편집을 설명하기 위해 포괄적 편집 요약을 사용할 수 없다.동일한 24시간 내에 발생하는 동일한 일괄 편집 요약을 사용하는 일련의 편집은 그의 커뮤니티 편집 제한의 맥락에서 "패턴"을 구성하는 것으로 간주된다.자동 또는 반자동 편집 실행을 실행할 때 Δ는 편집 요약에 적용된 편집 작업을 합리적으로 표시해야 한다. --Tristessa (talk) 22:30, 2011년 10월 25일 (UTC)

• 제안 - "패턴" 편집 문제를 해결하는 데 큰 도움이 될 것 같다. --트리스테사(토크) 22:30, 2011년 10월 25일 (UTC)[응답]
  • 정말 좋은 생각인 것 같아 - 많이 도움이 될 것 같아. - 지우개헤드1 <토크> 22:32, 2011년 10월 25일 (UTC)[응답]
  • 나는 이것이 그 문제를 해결할 것이라고 생각하지 않는다.문제는 편집 요약이 아니라 패턴이 무엇인지에 대한 명확한 정의가 없다는 사실이다.알파_Quadrant^(talk) 22:36, 2011년 10월 25일 (UTC)[응답]
    • 문제는 결코 한 가지에만 국한된 것이 아니다.세상은 복잡하다.이것은 -적어도 도움이 될 것이다 --- 지우개헤드1 <토크> 22:42, 2011년 10월 25일 (UTC)[응답]
    • (정리와 같은) 편집의 특정 작업이나 주제는 합리적으로 가까운 시간대에 적어도 25개 기사에 게재되어야 한다.--Crossmr (talk) 22:47, 2011년 10월 25일 (UTC)[응답]
• 어차피 댓글은 편집자가 해야 하는 거 아냐?--크로스미어(토크) 22:47, 2011년 10월 25일 (UTC)[응답하라]

나는 그 제안에 동의한다.편집 요약 남용에 근거하여 (같은 요약 "정리"가 있는 2,000개) 이것은 필요한 것으로 보인다.이에 대한 공감대가 있다면 편집 제한에 추가하여 잘 홍보되도록 해야 한다.— 칼 (CBM · talk) 23:10, 2011년 10월 25일 (UTC)[응답]

• 강력한 지원 --Guerillero My Talk 23:12, 2011년 10월 25일 (UTC)[응답]
• 코멘트 요약 편집에 관한 반복적인 주제가 있는데, 뭔가 제안할 필요가 있다.하지만, 이건 아니에요.필요하십니까?이런 맥락에서 '패턴'이 어떤 의미인지 아직 파악하지 못했는데, 이제 그걸 파악해야 한다고?그건 말이 안 돼. --Hammersoft (대화) 23:56, 2011년 10월 25일 (UTC)[응답하라]
• AWB가 사용하는 것과 같은 "일반 수정"의 범주에 속하기 때문에 이러한 요청의 대부분을 설명하는 페이지에 연결하는 것이 가장 좋을 것이다. 그리고 나의 메인 편집은 뭔가 별개의 것이다.그렇지 않으면 편집 요약이 번거롭고 무의미한 ΔT 00:25, 2011년 10월 26일(UTC)[응답]으로 전환된다.

• 내가 당신의 뜻을 따른다면; 아마도 당신의 사용자공간의 하위 페이지에는 "정리"로 분류된 편집에서 수행되고 있는 조치의 유형이 상세히 기록되어 있을 것이다. 그리고 편집 요약에서 그 하위 페이지와 연결된다? --Hammersoft (토크) 00:30, 2011년 10월 26일 (UTC)[응답]
  • 정답.ΔT 00:40, 2011년 10월 26일 (UTC)[응답]

• 그러나 그것은 기본적으로 내 제안의 요점을 회피하는 포괄적인 편집 요약일 것이다. 이전 상황보다 더 나을 것이다(즉, 전혀 정보가 없다), 편집에 대한 검토/복습은 여전히 내가 직설적으로 느끼기에 충분치 않다.당신의 제안은 각 편집자가 실제로 어떤 작업을 하고 있는지 정확히 명시하지 않는다.만약 당신이 인간 편집자라고 말한다면, 당신이 각 편집에서 무엇을 변화시켰는지를 설명하는 요약을 제공하는 데 문제가 없어야 한다. 이것이 내 제안이 효과적으로 시사하는 전부고, 당신이 선택받는 것은 결코 아니다. --트리스테사 (talk) 02:08, 2011년 10월 26일 (UTC)[응답]

• 델타가 (인간의 감독으로) 도움 프로그램을 사용하는 경우, 정리 페이지가 이를 열거한다고 가정하여 "사용자:Δ/정리 작업 #1(2배), #4(3배)" 양식의 편집 요약을 쉽게 생성할 수 있다.편집요약서에 제시된 과제 수는 더 좋겠지만 제안된 과제 수가 많아 철자할 여지가 있다면, 나는 공간이 없을 것이라고 생각한다. --MASEM (t) 14:17, 2011년 10월 26일 (UTC)[응답]

• 나는 그것이 반자동 편집에 충분하다고 생각한다; 손으로 한 모든 것은 손으로 설명할 수 있다.작품? – 루나 산틴 (토크) 20:55, 2011년 10월 26일 (UTC)[응답]
• 어디인지는 기억이 안 나지만 다른 곳에서 그런 짓을 한 것을 본 적이 있다.나는 그 방법을 지지한다.편집 요약은 작업을 식별하는 데 사용된 숫자/약어를 설명하는 페이지와 같은 페이지에 대한 적절한 링크가 있는 한 자급자족할 필요가 없다.Uʔ (대화) 22:51, 2011년 10월 26일 (UTC)[응답]

• 지지하다.현재 ANI U on (대화) 04:39, 2011년 10월 26일 (UTC)[응답]에 있는 것과 같은 사고를 방지하는 데 분명히 도움이 된다.
• 제안대로 반대하다.나는 편집 요약에서 페이지가 연결되도록 하는 발상은, 아마도 마셈이 제안한 대로 약간의 변형이 있는, 합리적인 절충이라고 생각한다.이것의 '필수'적인 측면도 불편하다.Δ가 편집 요약을 놓치거나 약간의 사소한 오류를 범하는 순간 그것은 번지르르한 도구가 될 것이다. --Hammersoft (토크) 15:00, 2011년 10월 26일 (UTC)[응답]
  • 흠... "Δ는 기술 편집 요약을 사용하기 위해 노력해야 하며, 작업, 특성 또는 자동화가 다른 편집 요약을 설명하기 위해 포괄 편집 요약을 사용하는 것이 금지되어 있다."라고 말하는 것이 더 간단할까?나는 유용한 요약을 장려하는 생각은 좋지만, 그것에 대해 과장하지 않는 편이 낫겠다.– 루나 산틴 (토크) 20:59, 2011년 10월 26일 (UTC)[응답]
    • 음, 나는 "하지만 그는 모든 정리에 오직 하나의 스크립트만을 사용하므로 그들은 작업, 자연, 자동화에 있어서 다르지 않다."라는 주장을 상상할 수 있다.우리가 여전히 "패턴"의 정의에 대해 장기간 논쟁을 벌이고 있는 것을 고려하면, 우리는 더 많은 모호성을 만들지 않는 것이 좋겠다.Uʔ (대화) 22:47, 2011년 10월 26일 (UTC)[응답]
      • 하지만 나는 그것이 다소 불만이라고 생각한다: 만약 그것이 모두 하나의 대본이라면, 좀 더 서술적인 요약을 제공할 수 있다면 좋을 것이다.'정리' 페이지마다 별 말이 없다. – 루나 산틴 (대화) 22:58, 2011년 10월 26일 (UTC)[응답]
  • 편집 제한의 정신은 델타가 포괄적인 허가를 요구하기보다는 정해진 기사 집합에 대한 특정 업무를 처리할 수 있도록 허락을 구하는 것이라고 나는 믿는다.그 관점이 성공적이지 않다고 가정할 때, 이 제안은 나의 두 번째 선택지원이 있다.첫 번째 선택은 루나의 제안(바로 위)이다.호빗 (토크) 22:29, 2011년 10월 26일 (UTC)[응답]
    • 정의된 집합이 없으면 어떻게 하시겠습니까?Δ가 기사 상단에 카테고리 태그가 배치되는 16개의 기사를 찾아낸다고 하자.이것이 2011년 10월 23일이었다고 가정해보자.일주일 후, 그는 같은 문제를 가진 또 다른 11개의 기사를 발견한다.그는 그곳에 또 다른 11개가 있다는 것을 전혀 몰랐지만, 일주일 후에 그들을 발견했다.이제 27개 기사다.그게 패턴이야?일주일이 아니라 한 달이면 어쩌지?6개월?1년?언제부터 패턴이 되어 전형적인 편집 습관이 되는가(우리 모두가 가지고 있는)? --햄머소프트 (대화) 12:54, 2011년 10월 27일 (UTC)[응답]
      • 그는 11번을 하기 전에 승인을 받아야 한다.아니면 단순히 승인 과정이 부담스럽다면 이런 일은 피해야 한다.편집 제한의 요점은 그가 반자동 편집을 더 편리하게 하는 것이 아니다.— 칼 (CBM · talk) 13:40, 2011년 10월 27일 (UTC)[응답]

• 좀 더 구체적으로 대답해 주시겠습니까?16과 11이 1개월, 6개월, 1년 단위로 분리되면? --Hammersoft (대화) 14:08, 2011년 10월 27일 (UTC)[응답]

시험기간

위의 몇 가지 코멘트를 바탕으로, 위에서 승인한 제안이나 거품에 오른 제안들 중 어떤 것이든, 말하자면, 델타가 이 과제를 시작하기 전에 리스트가 설정되어야 하는 500개의 기사의 시험기간을 운영할 것을 델타에 요청하는 아이디어를 제안하고 싶다.델타가 전속력으로 움직인다고 가정하면 2시간 정도 걸릴 겁니다 하지만 거기서부터 시작합시다이 "정리"에 따라 사전 설정된 기사 그룹을 완료한 후 커뮤니티는 편집 내용을 검토하고 승인된 단계를 따르고 있음을 확인할 수 있는 1~2주의 기간을 갖게 된다.

이 시점에서 지역사회는 델타가 어떤 업무를 무한정 승인받을 수 있는지 결정할 수 있다(예상대로 정확히 실행되었기 때문이다).

500이 좋은 숫자인 이유는 현재 콘보에서 관련된 모든 편집자들이 평의에 동등하게 참여했다면, 각각의 편집이 검토될 수 있는 이유 안에서 그 보완성이 있기 때문이다.500개의 편집도 이들 편집 내용을 모두 되돌려야 하는 경우 관리할 수 있다.

명심해, 나는 델타가 이 시점 이전에 8,000번의 편집을 했다고 주장하는 것을 알고 있지만, 여기서는 그 작업을 하기 위해서만 또는 이 제안이 요청한 추가 정보(예: 요약 편집)를 반영하기 위해 그의 편집 보조 도구의 새로운 버전을 다루고 있다.

만약 당신이 이것이 좋은 생각이라고 믿지만 위의 작업들 중 어느 하나라도 반대했다면, 나는 당신이 추적 기간을 고려하여 반대되는 것을 재고할 것을 권고한다.즉, 해머소프트가 제공하지 않았다는 설명이 충분히 명확하거나 사례가 너무 모호하다면, 이 과정은 델타가 더 큰 규모로 하려고 계획했던 변화를 규명하는 데 도움이 될 수 있다.

따라서 앞으로 델타가 이 정화 과정에 더 많은 작업을 추가하고 싶다면, 그 새로운 기능에 대해 비슷한 시험 기간을 거쳐야 할 것이다. --MASEM (t) 23:39, 2011년 10월 26일 (UTC)[응답]

이것은 현재의 제한의 의도에 훨씬 가깝지만, 나는 500이 과도하다고 생각한다.나는 델타가 그의 다중 기사 제한에 대한 증가나 예외를 허용하기 전에, 그가 먼저 그 제한 내에서 적절하게 편집할 수 있다는 것을 증명할 필요가 있다고 생각한다.델타항공은 승인을 요청하는 봇과 같은 것이 아니라 과거에 이미 실수를 했고 이로 인해 사람들이 신뢰를 잃게 되었다.나는 시험 횟수를 크게 줄여야 한다고 생각해, 100번이 더 합리적일 것 같아.모든 경우에, 델타의 다른 편집 제한은 존중되어야 하며 만약 그가 주어진 재판에서 그의 다른 제한사항들 중 하나를 위반한다면 그것은 실패로 끝난다.테크노심비오시스 (대화) 00:05, 2011년 10월 27일 (UTC)[응답]

내가 걱정하는 것 중 하나는 델타에게 '더 이상 내 편집 리뷰에서 그렇게 엄격할 필요 없어'라고 말할 수 있는 포인트를 주는 것이다.그는 재판 중에 자신의 견제를 '긴축'한 다음, 무제한 편집에 대한 승인을 받으면 그것을 완화시킬 수도 있다(또는 완전히 중단시킬 수도 있다.이 재판과정이 단지 감시를 받을 때만이 아니라 항상 신중할 필요가 있다는 점을 보강할 수 있는 방법이 있을까.테크노심비오시스 (대화) 00:10, 2011년 10월 27일 (UTC)[응답]

추가 옵션은 이 특정 프로세스의 일부로서 할당된 권한이 없는 편집자가 이 정리 태스크에 나열된 편집 내용을 식별해야 한다는 것이다.그리고 물론 어떤 사람이 (이 편집자가 되든 아니든) 문제를 발견하게 되면, 그들은 델타의 페이지나 다른 중앙 위치에서 그 문제를 논의해야 한다(그리고 정리 작업을 요약한 이 제안된 사용자 페이지에 가능한 위반 사항을 보고할 수 있는 포인터가 있는지 확인해야 한다).위의 태도를 볼 때 델타는 자신이 항상 현미경으로 수술한다고 가정해야 하지만, 시험 기간의 핵심은 그가 하고 있는 일이 정확히 명시된 대로, 그 이상도 이하도 아니라는 것을 확인하는 것이다. --MASEM (t) 00:20, 2011년 10월 27일 (UTC)[응답]

평가판 자체 내에서 편집한 내용에 대해, 이러한 편집 내용은 트라이얼되는 작업에 국한되어야 하는가?예를 들어 데드링크 수정사항을 3번 반복하는 경우 100번의 시험 편집에는 데드링크 수정사항만 포함되어야 하는가?나는 이렇게 해야 한다고 생각하는 경향이 있지만, 일단 작업이 승인되고 동시에 다른 작업들과 섞이게 되면 델타가 어떻게 수행될 것인지를 정확하게 나타내지 못할 수도 있다.주어진 편집에서 수행되는 다양한 작업의 수가 특정 임계값을 초과할 때, 그의 편집 내용을 수동으로 검토하는 능력은 복잡할 수 있다.테크노심비오시스 (대화) 00:38, 2011년 10월 27일 (UTC)[응답]

모든 작업이 동시에 이루어져야 한다. 코드가 충돌하거나 이와 유사한 경우, 그리고 그가 이 모든 편집을 동시에 수행하기를 원하기 때문에 이 작업을 수행할 수 있는 자신의 역량을 보장할 수 있다(그리고 만약 그렇지 않다면, 그는 필요에 따라 각 작업을 단독 편집으로 재인쇄할 수 있다).내가 암시했듯이, 이 평가의 모든 편집은 각 작업별로 평가되고 탭으로 표시되어야 한다(모든 성공과 실패한 작업과 그로 인한 통계량을 세는 몇 가지 표를 상상할 수 있다).--MASEM (t) 02:10, 2011년 10월 27일 (UTC)[응답]

위의 제안에 대해 내가 본 유일한 유의미한 지지자는 봇들이 이미 하고 있는 것들이다.그 말의 요점을 전혀 알지 못한다.--크로스미르 (토크) 10:09, 2011년 10월 27일 (UTC)[응답]

• 모든 편집자들이 봇이 하는 일을 하는 것을 금지하는 것은 좋은 생각일지도 모른다.단순한 현실은 인간은 실수하기 쉽다는 것이다.WP가 인증한 대로 봇이 올바르게 수행하는 경우:BAG, 그러면 우리는 걱정할 오류율이 없다는 것을 안다.편집자보다 봇이 하는 게 훨씬 낫지? --Hammersoft (대화) 12:55, 2011년 10월 27일 (UTC)[응답하라]
  • 문제는 모든 편집자들이 아니라 단순히 베타다.왜 그에게 봇이 이미 할 수 있는 대규모 편집을 할 수 있는 특별 허가를 받아야 하는가?확실히 그가 할 수 있는 다른 것들이 있다.— 칼 (CBM · talk) 13:43, 2011년 10월 27일 (UTC)[응답]
    • 그러나 어떤 편집자(델타 포함)도 이미 대규모로 하는 워크봇을 하는 것을 막을 수 있는 것은 없으며, 이것은 델타(델타)의 제약(봇들이 이미 하는 일을 할 수 없는 것)의 일부도 아니다.델타항공은 분명히 이런 종류의 작업을 하고 싶어하며, 현재의 제한사항과 WP 개선에 필요한 작업(적어도 승인된 작업)을 하고 싶어 한다. --MASEM (t) 13:54, 2011년 10월 27일(UTC)[응답]
      • 그 제한사항들은 베타의 대규모 편집은 다른 편집자들의 승인을 받아야만 한다고 말한다.이 제한사항은 의도적으로 편집자들이 요청을 평가할 때 사용할 기준을 명시하지 않는다. 즉, 우리는 요청의 전체 상황을 자유롭게 고려할 수 있다.편집 제한사항의 목적은 베타가 일반적으로 다른 편집자들이 할 수 있는 일을 할 수 있도록 허락되지 않는다는 것이기 때문에 "다른 사람들이 할 수 있다"는 내가 중요시하는 기준은 아니다.개인적으로, 나는 그에게 봇들이 이미 하고 있는 일을 할 수 있도록 특별한 승인을 주는 것에 찬성하는 주장을 보지 않는다.— 칼 (CBM · talk) 13:59, 2011년 10월 27일 (UTC)[응답]

• 물론 봇이 할 수 있다면 Δ는 하지 말아야 한다는 주장이 있다.그러한 제재가 시행된 것은 아니며, 예를 들어 Δ가 {{npov}}과 같은 유지 관리 태그와 연대를 맺지 못한 이유를 알 수 없다.당신은 그가 기사를 만들고 내용을 추가하는 것에 집중하기를 원한다.하지만, 당신은 그가 정비 태그와 데이트를 할 수 있다고 믿지 않는다.내 생각에 너는 그를 믿지 않는 것 같아. --Hammersoft (대화) 14:07, 2011년 10월 27일 (UTC)[응답하라]

• 지역 사회도 전혀 그렇지 않다.만약 그가 파이썬 모듈 묶음에 의해 이미 처리된 것보다 더 복잡한 것으로 믿을 수 없다면, 그가 그것들을 만들 수 있도록 허용하는 프로젝트의 이점은 사실상 무효다.사실, Python 모듈의 묶음이 편집 전쟁에 참여하거나, 인신공격하거나, 그것을 차단하는 누군가를 괴롭히는 친구를 갖지 않기 때문에, 아마도 부정적일 수 있다.Chris Cunningham (사용자:thumperward) - 토크 14:11, 2011년 10월 27일 (UTC)[응답]
• 아니, 그렇지 않았다.제 요점은 문제가 제기되지 않은 채 중요한 지원을 받는 몇 가지 과제는 봇이 매우 빠르게 수행하는 작업뿐이라는 것이었습니다.델타가 정비 태그 데이트 같은 일을 하기 위해 봇들과 경쟁하는 시나리오.데이트를 잊은 경우 90%는 아주 빨리 혹은 거의 즉각적으로 내가 데이트를 한 후에 이루어진다.델타항공이 그런 편집 작업을 하는 것을 재판으로 해서 큰일을 치르게 된 이유가 뭘까?--크로스미르 (토크) 22:49, 2011년 10월 27일 (UTC)[응답하라]

• 당연하지, 네 말이 맞아. 델타가 봇이 할 수 있는 일을 해선 안 된다는 게 네 생각이야.그러나 우리가 제한을 받는 이유는 델타가 정상적인 편집자처럼 행동하기를 원하지만, 특정 분야(편집 속도, 예의 등)에서 주의 깊게 부각되기 때문이라고 지적할 것이다.그것만이 델타를 특별하게 만드는 것이다.델타가 특정한 일을 하도록 허락되지 않은 경우는 아니다. 사실, 편집자로서 "권리"를 주어진다면, 그 제한은 델타가 정규 편집자로서 할 수 있는 것을 줄이는 데 거의 도움이 되지 않는다고 나는 주장한다.내 걱정은 그 반대론자들이 델타에게 그가 일하고 싶은 지역에서 무기한 제한에 대해 상환할 기회를 주지 않고 그의 능력을 증명해 보인다는 것이다. --MASEM (t) 14:16, 2011년 10월 27일 (UTC)[응답]

다른 편집자들이 드라마와 혼란을 야기하지 않고 프로젝트의 특정 영역에서 활동할 수 없는 능력을 보일 때 우리는 그들의 열정, 전문성 수준 등에 관계없이 편집하는 것을 금지한다.베타 커맨드(BetaCommand)는 문제가 되는 분야가 이스라엘-팔레스타인 상황이나 트랜스포머 캐릭터, 점성술 등이 아니라 위키그노밍이라는 점에서 다소 독특하다. 이는 단어 제한에 관한 한 독특한 도전이다.다른 편집자들과 함께, 우리는 그들이 프로젝트의 다른 부분에서의 작업을 통해 그들 자신을 되찾기를 기대하지만, 이 경우에 우리는 어떻게든 베타가 그들이 말 그대로 가장 무심한 다양성인 한 대량 편집을 수행할 수 있다는 것을 보여주면서 자신을 되찾을 수 있다고 제안하는 상황에 처했다.이게 어떻게 작동하는지 모르겠어.그는 다른 사람들과 함께 일할 수 있다는 것을 보여줄 필요가 있고, 6개월 동안 유지 보수표를 사귀는 것은 그것을 증명하지 못할 것이다.Chris Cunningham (사용자:thumperward) - 토크 14:29, 2011년 10월 27일 (UTC)[응답]

• 동의한다. 커뮤니티는 Δ가 무엇을 하든, 얼마나 잘하든 Δ가 자신을 되찾을 수 없는 상황을 만들었다. --Hammersoft (토크) 15:24, 2011년 10월 27일 (UTC)[응답]

  다시 한번 이것은 거짓이다.델타항공이 그의 제한 범위 내에서 상당한 기간 동안 자유롭게 문제를 해결하기로 한다면, 그는 약간의 선의를 쌓을 수 있을 것이다.하지만 그는 그것을 할 능력이 없어 보인다.그것이 그가 자신을 되찾을 수 없는 이유다.누구도 그가 하는 나쁜 편집을 강요한 적이 없다.--크로스미르 (토크) 22:49, 2011년 10월 27일 (UTC)[응답하라]

• 공동체 제한은 델타가 그의 지노밍 작업이 수반되는 것처럼 반복적인 편집을 계속하기를 원할 가능성에 따라 고안된 것으로 볼 때, 그 공동체가 그를 다른 곳에서 일하기를 원했던 경우는 아니며, 계속하기 위해서는 그가 인간적인 방식으로 하고 있다는 것을 보여줘야 할 것이다.만약 그 공동체가 그가 그네오밍을 멈추기를 원했다면, 그 제한은 크게 달라졌을 것이다.물론, 몇몇 지역사회는 델타가 소싱된 재료 등을 추가하여 메인 스페이스 기사의 개선으로 방향을 틀기를 바랐을 것이라고 확신하지만, 그것은 이러한 제한사항의 요건이나 면은 아니었다. --MASEM (t) 15:37, 2011년 10월 27일 (UTC)[응답]
  • 그가 생산적인 편집을 하도록 강요하는 것은 공동체의 과제가 아니다.공동체의 임무는 그가 그 사업을 방해하는 것을 막는 것인데, 이것이 그 규제들이 의도한 것이다.속사포 봇형 편집 말고도 'gnomish' 작업이 많다.결국 베타는 자신이 대략 봇만큼 유능하다는 것을 보여줌으로써 자신의 제한을 없애지 못할 것인데, 기본적으로 이 모든 제안들이 요구하는 것이다(지원이 거의 없는 것처럼 보이는 "캔 프러드 기사" 같은 것을 제외한다).Chris Cunningham (사용자:thumperward) - 토크 17:38, 2011년 10월 27일 (UTC)[응답]

• 그럼 간단히 말해라. 프로젝트에서 그를 배제하라.만약 공동체가 Δ가 자신을 증명할 수 있는 구조를 개발할 수 없다면, 공동체는 실패했을 것이다.커뮤니티가 인정하지 않을 것이기 때문에, 그 다음으로 나쁜 대안은 그를 완전히 금지하는 것이다. --Hammersoft (대화) 18:03, 2011년 10월 27일 (UTC)[응답]

• 만약 그가 아주 작고 대부분 로봇적인 성격의 매우 제한된 범위의 대량 편집으로 그 프로젝트에 여전히 이득이 될 수 있다는 것을 증명할 마음이 내키지 않거나 증명할 수 없다면, 그것은 그렇게 될 것이다.실제로, 그것은 대체로 그렇게 되었다.만약 이 프로젝트가 2008년 완전 금지에 대한 첫 번째 확실한 제안이 계류되었을 때 우리가 3년 후에도 여기 있을 것이라는 것을 알았다면, 우리는 지금 당장 이 일에 시간을 낭비하고 있지는 않을 것이다.크리스 커닝햄(사용자:thumperward) - 토크 19:25, 2011년 10월 27일 (UTC)[응답]

• 그는 상당히 의지가 있다.문제는 커뮤니티가 그가 무엇을 하든 요건을 충족하고 논란을 일으키지 않는 상황을 만들었다는 점이다.하지만, 그게 다 Δ의 잘못이지?그 지역사회는 빛나는 후광이 머리를 감싸고 있어 잘못은 할 수 없어아니, 커뮤니티가 완벽해. --Hammersoft (대화) 19:36, 2011년 10월 27일 (UTC)[응답]

• 이 이득은 아무도 납득시키지 못한다."요구사항"은 베타콤랜드가 드라마를 유발하지 않고 프로젝트의 애견 영역에서 작업할 수 있도록 신뢰할 수 있을 때까지 편집해야 하는 논란의 여지가 없는 것(그리고 위의 프로젝트에 명백한 이점이 있음)을 찾는 것이다.그 법안에 들어맞는 업무는 부족함이 없다.그는 대신 자신이 받고 있는 제한 사항을 반복적으로 회피하거나 다른 방법으로 회피하는 것을 선택했는데, 이는 다른 작업에 대한 완전한 배제인 것으로 보인다.두 가지 모두 현재의 제약을 초래하고 그것을 지탱하는 합의에 대한 당신의 콧방귀와 완강한 공격은 당신이 당신의 또래들 사이에서 가지고 있었을지도 모르는 어떤 것이라도 손상시키는 것 외에는 아무 것도 하지 않는다.이 일로 네가 얻는 것은 내 능력 밖이다.Chris Cunningham (사용자:thumperward) - talk 20:16, 2011년 10월 27일 (UTC)[응답]
• Delta는 자신을 되찾을 수 있는 충분한 공간을 가지고 있다. 이것은 이 모든 제안들을 통해 항상 짚이는 사람이다.문제는 그가 공동체가 허락한 것보다 더 꿈틀거리는 공간을 원한다는 것이고, 그것은 그야말로 위로의 문제일 뿐 그 이상은 아니다.누군가가 언젠가 나타날지도 모른다는 끊임없는 주장은, 델타가 지난 2년 동안 수행했던 26개의 편집본을 찾아낸 다음, 그것을 위해 그를 금지시키려 하는 것은 우스꽝스럽기도 하고 부적절하다.만약 우리가 무슨 일이 일어날지 말하고 있다면, 누군가가 델타의 삼각형 사용자 이름처럼 되지 않고 그를 '치즈원숭이'라는 이유로 금지시킬지도 모른다.근거가 전혀 없는 '무엇을 할 수 있는가'에 근거한 주장은 전혀 장점이 없다.

당신이 말한 것처럼 델타가 자신의 이익을 '양심할 용의가 있다'고 한다면, 그는 기존의 제한 내에서 그렇게 하는 데 문제가 없어야 한다.100개의 기사에 데드링크를 태그하는 것은 어떤 방식으로 그가 25명이 할 수 없는 방식으로 그의 문제를 해결했음을 보여주는가?그는 그런 식으로 25개 이상의 기사를 쓰고 싶어할지도 모르지만, 솔직히 그건 너무 안됐어.전에도 그런 기회가 있었고, 그걸 날려버렸고, 지금은 이런 제한을 받고 있어.그가 그 제한 내에서 일할 수 있다는 것을 보여줄 수조차 없다면, 그것을 느슨하게 할 이유가 전혀 없다.

위에서 언급했듯이, AGF는 영원한 웰 스프링이 아니며 나쁜 행동을 한 다음 누군가가 악의를 품을 때마다 AGF를 다시 가리키는 것은 무료 티켓이 아니다.내가 이 제안들을 읽을수록, 나는 당신의 논평, 해머소프트, 그리고 델타 사의 몇몇 회답을 여기서 읽을수록, 나는 당신들 둘 다 이 상황을 공격당하고, 훼손되고, 불명예스러워지고, 법으로 간주되고, 법으로 간주되고, 제약이 더 이상 테나를 볼 수 없을 때까지 의심과 불확실성을 조작할 수 있는 것으로 확신해.실소를 불문하고 표백하다구속의 정신과 의도에 순응하고 그 기회를 살려 구원을 보여주려는 진솔하고 정직한 욕망은 없어 보인다.대신, 당신은 그들을 파괴하려고 한다.솔직히 이런 행태가 진행될수록 위의 다양한 제안에 대한 지지표를 수정해 반대하려는 마음이 더 크다.델타항공은 그의 규제가 축소되기 전에 이를 준수할 필요가 있다.그가 그렇게도 할 수 없다면, 당신이 옳다. 그를 금지하는 것이 유일한 선택일 수도 있다.나는 이전에 그 만일의 사태에 대해 중립적이었지만, 만약 그것이 일어난다면, 이것은 점진적으로 내가 그것을 지지하는 쪽으로 기울어져 왔다.만약 이것이 델타를 도우려는 당신의 생각이라면, 나는 개인적으로 당신의 접근방식을 진지하게 재고해야 한다고 생각한다.테크노심비오시스 (대화) 22:56, 2011년 10월 27일 (UTC)[응답]

• 모두 반대하다.델타는 오랫동안 나를 포함한 많은 공동체 구성원들이 가정할 준비가 되어 있는 선의를 모두 써버렸다.델타항공이 (적어도 1년 이상) 지속적인 기간 동안 자신의 제한에 대한 편지와 정신을 준수하는 것에 대한 신의를 증명하고, 왜 그가 제한되는지에 대한 이해를 증명하고, 일반적인 가능성이 아닌 특정 업무에 대한 허가를 스스로 요청할 때, 나는 그 요청을 고려할 준비가 되어 있을 것이다.그럴 때까지 나는 공동체의 건강을 위해 반대할 수밖에 없다.Thryduulf (대화) 2011년 10월 28일 (UTC) 18:05 [응답]

• 그는 선의를 보여야 하는데, 그럴 때까지 편집이 허락되지 않는다고?와우. --Hammersoft (대화) 22:07, 2011년 10월 28일 (UTC)[응답]

• 그는 그의 제한 내에서 편집하는 것이 허용된다. 그는 항상 허용되어 왔다.당신이 지금 이 시점에서 사용하고 있는 이 거짓 박해적인 언사는 정말로 당신의 사건에 전혀 도움이 되지 않는다.심각한 WP 사례가 있으십니다.IDNTHEAR 지금 당장.--크로스미어(토크) 23:07, 2011년 10월 28일 (UTC)[응답하라]

• 사실 꽤 틀렸어, 닥터.나는 모순된 메시지를 식별하는 심각한 사례를 가지고 있다.내가 하지 않으면 좋을 텐데.생활이 훨씬 편할 것이다.하지만, 진공상태에서 철자를 쓸 수 없는 사람들에게 완벽을 요구하는 것, 신의의 증명은 요구하지만 편집은 승인하지 않는 사람들을 보면...커뮤니티가 정말 성장하고 있는 것은 제재다. --Hammersoft (대화) 02:48, 2011년 10월 29일 (UTC)[응답]

• 그리고 더 나아가서 나쁜 믿음과 미개한 논평에 대한 가정도 있다.그래서 만약 누군가가 오타를 하면 어떻게 될까?더 이상 델타에 반대할 말이 없다고?와우, 그건 확실히 네가 지역 사회의 많은 지지를 얻을 수 있는 직책이야지금 델타 편집이 가능한가?그가 기사로 가서 편집 버튼을 누르거나 텍스트를 추가하거나 삭제하고 저장할 수 있을까?예스냐 노냐.솔직하게 대답할 수 없고 어떻게 탈선하는지를 볼 수 없다면, 나쁜 길로 향하고 있으니 진지하게 물러나는 것이 좋을 것이다.--크로스미어 (토크) 06:04, 2011년 10월 29일 (UTC)[응답]

• 미개한?왜, 나 자신을 공격하는 거야?비현실적이다.진짜인 것은 Δ가 어떤 것이든, 그것이 무엇이든 간에 하는 모든 것에 대한 당신의 반대다.철로에서 무슨 일이 일어나고 있다면, 그것은 이 제재에 대한 지역사회의 열차 파괴 관리다. --Hammersoft (대화) 12:58, 2011년 10월 29일 (UTC)[응답]

• 진공 청소기의 철자를 쓸 수 없는 사람들의 완벽에 대한 요구가 당신 자신에 대해 쓰여졌는가?완벽을 요구하는 사람은 없다.그들은 델타가 보여주지 않은 합리성을 요구한다.선의의 증빙을 요구하면서도 편집에 찬성하지 않는 사람들. 다시 한 번:지금 델타 편집이 가능한가? 그가 기사로 가서 편집 버튼을 누르거나 텍스트를 추가하거나 삭제하고 저장할 수 있을까?이것들은 뻔한 거짓말이기 때문에 미개하다.반복된 것, 누구의 말도 듣지 않는 것.--크로스미르 (대화) 22:30, 2011년 10월 29일 (UTC)[응답하라]

• 즐거운 하루 보내길 바래. --Hammersoft (대화) 00:38, 2011년 10월 30일 (UTC)[응답]

• 크로스 씨의 질문에 답하십시오.테크노심비오시스 (대화) 00:00, 2011년 11월 1일 (UTC)[응답]

Δ(베타코만드)에 부과된 편집 제한 #1 변경

ANI(및 위와 같은 논의)에서 베타코만드의 편집 제한에 대한 논의에 따라, 향후의 문제를 피하기 위해 현재의 제한에 대한 변경을 제안하고 싶다.현재 첫 번째 제한 사항은 다음과 같다.

“

제한 #1: 25페이지 이상에 영향을 미치는 편집 패턴(여러 페이지에서 수행되는 단일 작업 등)을 수행하기 전에 베타콤랜드는 WP에서 작업을 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드는 그가 시작하기 전에 이 요청을 지지하는 합의를 기다려야 한다.

”

첫 번째 제한은 상당히 모호하며, 무엇이 "패턴"을 구성하는지 해석할 수 있다.제한사항이 불합리하게 모호하기 때문에, 어떤 편집자도 그 제한을 따르기를 기대할 수 없다.패턴으로 구성되는 것에 대한 시간 정의나 명확한 정의는 없다.따라서 그는 이 제한사항의 정확한 문구를 지키지 못해 수많은 AN과 AN/I 논의를 거쳐 파견되었다.그러므로 나는 제한 #1을 다시 표기할 것을 제안하고 싶다.제안된 문구는 다음과 같다.

“

100개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드는 WP에서 이 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드는 그가 시작하기 전에 이 요청을 지지하는 합의를 기다려야 한다.태스크는 편집이 정확히 동일하거나 거의 정확하게 동일한 한 달 내의 모든 편집 그룹으로 정의된다.정책 내에서 명확하게 편집(예: Manual of Style fix)하는 경우에는 사전 논의가 필요하지 않다.

”

제안된 변경사항들은 현재 제한사항의 모호성을 해소할 뿐만 아니라 향후 문제 발생 가능성을 줄일 것이다.알파_Quadrant 19:11, 2011년 10월 24일 (UTC)[응답]

• 나는 그 제한 #1이 좀 더 명확하게 정의될 필요가 있다고 생각한다.있는 그대로, 그것은 많은 다른 방법으로 해석되어 엄청난 경악의 결과를 초래하고 있다.편집 스로틀을 변화의 일부로 통합하는 것이 지금 당장 필요한지 모르겠고, 이를 포함하면 토론의 물꼬가 트일 수도 있다. --Hammersoft (토크) 19:46, 2011년 10월 24일 (UTC)[응답]

• 제한사항 #1과 #3을 결합하자는 제안을 제거했다.알파_Quadrant 19:57, 2011년 10월 24일 (UTC)[응답]

나는 기사 수를 100개로 늘리는 것에 동의하지 않는다.25 편집 예외를 둔 동기는 베타가 그 제한을 어기지 않고 아주 최소한의 다중 기사 편집을 할 수 있게 하기 위해서였다.그러나 요점은 그가 이런 대규모의 유지 보수 작업을 전적으로 피하고 대신 다른 종류의 편집에 집중해야 한다는 것이다.('유지' 작업이란 무엇인가?)라고 말하기에 엄밀한 제한을 찾기는 어렵지만, 이것은 앞으로 이런 종류의 문제를 피하기 위해 필요한 일종의 변화다.— 칼 (CBM · talk) 20:06, 2011년 10월 24일 (UTC)[응답]

• A에 있어서는 안 되는가?어쨌든, 지지하지만 25개 기사에 대해서는.~~에베123~ (+)20:10, 2011년 10월 24일 (UTC)[응답]

• 그럴지도 모르지, 하지만 아닌 것 같아.이것은 관리자가 부과하지 않은 공동체 제한이다.관리자들은 필요에 따라 시행하도록 요청받지만, 제한을 두는 것은 지역사회의 결정이다.이 논의의 포인터를 적절한 장소에 두는 것이 좋을 것이다.원래 제한 페이지는 3년이 지나도록 편집이 되지 않아 1장을 배치하기엔 좋지 않은 곳. --Hammersoft (토크) 20:36, 2011년 10월 24일 (UTC)[응답]

• 질문"과업은 편집이 정확히 동일하거나 거의 정확하게 동일한 한 달 내의 편집 그룹으로 정의된다."
  나는 이 공식에 대해 이해할 수 없다.다음과 같은 두 가지 편집을 예로 들 수 있다: [31][32].이 두 편집은 상당히 비슷하게 생겼지만, 분명히 똑같지는 않다.
  1. 다른 두 페이지에 해당되며
  2. 다른 숫자와 ID를 가지고 있다.
  그래서 적어도 나에게 앞서 말한 정의가 완전히 명확한 것은 아니다.야마구치 도시오 (토크) 22:52, 2011년 10월 24일 (UTC)[응답]

아마도 "과제는 기사에 대한 변경사항이 극히 유사한 여러 페이지에 대해 한 달 안에 편집된 어떤 그룹으로 정의된다"라고 표현해야 할 것이다.알파_Quadrant^(talk) 23:35, 2011년 10월 24일 (UTC)[응답]

"극히 비슷함"의 어려움은 그것이 이미 우리가 처해 있는 것과 같은 위치에 우리를 남겨둔다는 것이다.반면에, 페이지 내용에 따라 약간 다른 작업을 수행하는 유지보수 스크립트를 실행할 수 있기 때문에 변경사항이 정확히 같도록 요구하는 것은 작동하지 않을 것이다.편집에서 패턴을 파악하기 위해서는 관리자에게 의존해야 할 것 같아.— 칼 (CBM · talk) 02:03, 2011년 10월 25일 (UTC)[응답]

나는 당신이 찾고 있는 구절이 "대체로 동일하다"라고 믿는다.http://en.wiktionary.org/wiki/substantiveGuy Macon (대화) 02:35, 2011년 10월 25일 (UTC)[응답]을 참조하십시오.

이런 게 있어야죠.

"과업은 한 달 내에 편집된 모든 그룹으로 정의되며, 두 편집은 영향을 미치는 페이지와 디프 번호와 ID에 의해서만 달라진다."

이것은 적어도 그 부분을 모호하지 않게 만들 것이다.야마구치 도시오 (토크) 08:33, 2011년 10월 25일 (UTC)[응답]

• 반대 - (이 시나리오를 악화시킬 수 있을 뿐) 기사의 수를 100개로 늘리는 것은 좋지 않은 생각이며, 정책 내에서 명확하게 편집(즉, 스타일 수정 매뉴얼)은 사전 논의 조항이 원본보다 훨씬 모호하다.실제로 이 후자는 심각한 문제에 개방되어 있다. 편집자는 개별적으로 편집자가 개별적으로 실행하는 정책 내에 있을 수 있지만, 편집자는 다양한 기사에 걸쳐 자동으로 또는 반자동으로 적용할 때 정책 내에 있지 않을 수 있다.유감스럽게도 나는 이 제안을 지지할 수 없다.나 또한 이 특정한 하위 토론이 아마 이곳 VPP에서가 아니라 AN/I에서 이루어질 것이라고 믿는다. --트리스테사 (토크) 03:04, 2011년 10월 25일 (UTC)[응답]

100타를 쳐서 25로 줄였다.베타코만드가 자신의 편집 내용을 반자동 또는 자동으로 적용하고 있다는 증거는 거의 없다.알파_Quadrant^(talk) 03:32, 2011년 10월 25일 (UTC)[응답]

사실 많은 것이 있다.예를 들어 User talk:Δ/20110901을 참조하십시오.have mörser, will talk (talk) 04:25, 2011년 10월 25일 (UTC)[응답하라]

• 혼합: 나는 '월 25개 품목' 스로틀을 지지한다.나는 이 문장에 반대한다. '정책 내에서 분명하게 쓰여진 문구(즉, 스타일 수정 매뉴얼)는 사전 논의가 필요하지 않다.'첫째로, MOS는 지침이지 정책이 아니다.이러한 구분은 현학적인 것처럼 보일 수도 있지만 그렇지 않다.- 지침은 지역 합의에 의해 무시될 수 있으며, 델타의 편집은 논의 없이 지역 합의를 위반할 수 있는 상황에서 이루어지면 안 된다.테크노심비오시스 (대화) 04:54, 2011년 10월 25일 (UTC)[응답]
• 현재의 "패턴" 문구는 이러한 관점에서 더 타당해 보인다: Δ는 공동체 금지에서 한 걸음 떨어져 있었고, 이러한 제재는 사실상 그러한 결과를 피하기 위한 마지막 노력이다.그 제재는 광범위하게 해석될 수 있도록 되어 있기 때문에 널리 언급되어 있다.하지만 나는 시간의 감각이 도움이 될 수 있다는 것에 동의한다. 10분 동안 25페이지에 영향을 주는 일은 2년 동안 지속되는 것과 매우 다르다.그러나 나는 제재가 제3의 레일보다 더 의도된 것처럼 보이는 곳에서 그러한 어떤 표현도 허용으로 취급되지 않을까 걱정한다.– 루나 산틴 (대화) 05:23, 2011년 10월 25일 (UTC)[응답]
• 내 생각에 한 달에 25개는 너무 낮은 것 같아. 25로 유지하려면 2주 혹은 비슷한 시간으로 단축하는 게 좋겠어.2011년 10월 25일 (UTC) עישווו Od Mishehu 07:37, odreplyreply[응답]
• 강한 나는 알지 못하며 정말 신경 쓰지 않는다. 2007년 이후 4년 간의 논쟁 끝에 수많은 차단, 금지, 제한, 제재, 과제, ...조만간 이 일이 중단되길 바랄 뿐이다. - 나블라 (대화) 08:18, 2011년 10월 25일 (UTC)[응답하라]
• 질문"과제는 한 달 안에 어떤 편집 그룹으로 정의된다...". 여기서 "월"은 월#줄리안 및 그레고리안 달력의 상자에 열거된 내용을 참조하는가, 아니면 기간(예: 30일)을 지칭하는가?그가 4월 15일에 25개 기사에 영향을 줄 그룹 편집을 시작한다고 하자.그가 5월 1일에 계속하기 위해 새로운 제안을 해야 할 것인가?아니면 15일만 편집하고 5월 15일까지는 15일 정도 더 편집이 가능하기 때문에 그렇지 않은가.야마구치 도시오 (토크) 08:50, 2011년 10월 25일 (UTC)[응답]

  <아래에 있는 것>호빗(토크) 14:21, 2011년 10월 25일 (UTC)[응답]

• 이건 내 질문에 대한 대답이 아니야, 호빗.제 질문에 구체적으로 답변해 주시죠.현재 상태로는 여기서 무엇을 의미하는지 명확하지 않으며, Δ가 제한치 내에 머무를 가능성이 있으려면 이 점을 명확히 해야 한다.야마구치 도시오 (토크) 11시 48분, 2011년 10월 25일 (UTC)[응답]

• 죄송합니다, 형식 지정 오류(공백 제외).너에게 대답할 생각은 없었어.혼란스러워서 미안해.텍스트를 아래로 이동.호빗(토크) 14:21, 2011년 10월 25일 (UTC)[응답]

• 편집자의 "정책 안에 있다"의 면제에 반대하는 것은 델타가 자신을 교수형하고 드라마를 창조할 수 있는 더 많은 로프를 줄 뿐이다.이전에 그의 문제는 "내가 옳고 정책 복귀 안에 있다"는 접근방식과 그것을 허용한 유인책이었다.그 행동은 때때로 그가 하고 있는 일에 슬그머니 끼어들어 더 많은 문제를 일으킬 수 있는 오류들로 인해 더욱 복잡해졌다.델타가 제한 규정을 따르지 못하는 것은 골대를 옮기기 위한 핑계가 아니다.결과를 강요하는 이유가 된다.--크로스미르 (토크) 11:25, 2011년 10월 25일 (UTC)[응답]
• 의미 있는 편집 요약 필요.나는 만약 편집 요약이 같다면 25개의 편집은 같은 것으로 간주할 것을 제안하고 싶다.또한 다른 것으로 간주되기 위해서는 편집 요약에서 서로 다른 것이 분명해야 하며 편집 요약은 편집 요약을 정확하게 설명해야 한다고 제안한다.정확한 편집 요약은 인간 편집자라면 누구나 기대하는 것이다(Bott, 또는 Betacommand가 하지 말아야 하는 Betacomand의 행동과는 반대로).과거에 편집이 의심스러운 편집자의 경우, 편집 요약 요건의 강화된 시행이 적절하다.Jc3s5h (대화) 13:02, 2011년 10월 25일 (UTC)[응답]
• #1 VP가 이런 일을 할 수 있는 적절한 장소가 아니라고 생각한다.#2 그렇게 세세하게 편집자의 비위를 맞춰야 한다면 금지하거나 자유롭게 하는 것이 낫다고 생각한다.어쨌든, 나는 그 변화들이 너무 관료적이라고 반대한다.호빗(토크) 10시 35분, 2011년 10월 25일 (UTC)[응답]
• 반대한다. MOS는 봇과 같은 편집자가 특정한 작업에 대한 사전 승인 없이 그것의 모든 측면을 집행할 수 있도록 하기에는 너무 많은 것을 가지고 있다.Δ는 분명히 WP를 따르지 않는다.예를 들어 CITEVAR.have mörser, will talk (talk) 17:28, 2011년 10월 25일 (UTC)[응답하라]
• 다음 제안들 중 많은 것, 특히 WP당 "기능"이라는 단어와 단어 수 측면에서 "과제"를 정의하려는 모든 제안에 반대한다.크리프. --NYKevin @125, 즉 2011년 10월 29일 02:00 (UTC)[응답]

제안 n+1

나는 그 제한에 대해 다음과 같은 표현을 제안한다.

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.태스크는 30일 이내의 모든 편집 그룹으로 정의된다(그룹을 처음 편집한 시점부터 30일 이후의 동일한 시간으로 계산됨). 여기서 두 편집은 영향을 미치는 페이지와 해당 편집 번호 및 ID에 의해서만 달라진다.정책 내에서 명확하게 편집(예: Manual of Style fix)하는 경우에는 사전 논의가 필요하지 않다.

”

야마구치 도시오(토크) 16시 5분, 2011년 10월 25일 (UTC)[응답]

• 지지 나는 표현이 훨씬 더 좋다고 믿는다.알파_Quadrant 16:41, 2011년 10월 25일 (UTC)[응답]

• 이것은 그가 모든 기사에서 변경이 동일하지 않은 거의 모든 자동화 또는 반자동화 작업을 할 수 있게 해줄 것이다.예를 들어, 날짜 재포맷, 각 기사에서 다른 이미지 제거 등.그는 지역 사회의 검토 없이 그런 종류의 일을 처리할 수 없는 만성적인 무능함을 보여주었고, 그가 다시 그렇게 하도록 허용하는 것은 현명하지 못한 일일 것이다.— 칼 (CBM · talk) 17:19, 2011년 10월 25일 (UTC)[응답]

만약 그 변화가 분명히 정책 내에 있지 않다면 그는 여기에 와야 한다.대량 재포맷 날짜는 정책상 낙담하기 때문에, 그는 그것을 하기 전에 여기에 와야 할 것이다.만약 이미지가 정책을 위반한다면, 그는 그것을 제거할 권리가 있다.제거가 정책에 근거하지 않는다면, 그는 여기에 와야 한다.해머소프트가 지적한 상기의 요청된 변경사항의 대부분은 이미 Reflinks의 일반 수정사항이다.이러한 편집은 분명히 논란의 여지가 없다.나(그리고 많은 다른 사람들)는 종종 RefLinks를 사용하며, 아무도 우리에게 와서 그 변화가 정책에 반한다고 말할 생각을 하지 않을 것이다.위의 당신의 주장은 단순히 Δ가 Δ라는 사실에 근거하고 있으며, 당신은 그가 어떤 편집도 하지 말아야 한다고 생각한다.안부, 알파_Quadrant^(talk) 17:31, 2011년 10월 25일 (UTC)[응답]

베타는 사람들이 그와 문제를 제기할 때 만성적인 의사소통 문제를 동반하면서, 논란이 되는 일과 논란의 여지가 없는 일을 구별할 수 없거나 원하지 않는 것을 보여주었다.그가 현재 강력한 편집 제한과 아르브컴 모션을 동시에 받고 있는 이유다.바로 위의 제안은 편집 제한을 약하게 하고, 베타가 각 기사를 정확하게 변경하지 않은 경우 검토 없이 자동화된 또는 반자동화된 작업을 수행할 수 있게 한다.경험에 의하면 그 결과는 더 논란이 많은 편집에 불과할 것이다.— 칼 (CBM · talk) 17:53, 2011년 10월 25일 (UTC)[응답]

현재의 제한 하에서 Δ는 당신이 원하는 것과 패턴이 아닌 것을 정의하게 해주기 때문에 아무것도 할 수 없다.제한에 대한 제안된 문구는 누구나 객관적으로 확인할 수 있게 한다.그런데 Δ가 수행하는 작업을 논쟁거리로 분류하는 정책을 보여줘.논란이 있다는 것은 특정 사안에 대해 의견이 다르다는 것을 의미한다.만약 그것이 당신이 의미하는 것이라면, 이 토론과 이전의 토론은 분명히 아무도 당신에게 동의하지 않는다는 것을 보여주므로, Δs 편집에 대한 당신의 분류 자체는 꽤 논쟁의 여지가 있다.따라서 그렇게 하지 않으면 더 논란이 많은 편집자 분류가 될 수 있기 때문에 편집 제한에 처해야 한다는 말씀이십니까?야마구치 도시오 (토크) 2011년 10월 25일 (UTC) 18:12, 응답

제안된 문구는 실제로 객관적이지만, 베타가 과거에 일으킨 만성적인 혼란을 막기에는 너무 약하다.베타가 이처럼 엄격한 제한을 받고 있는 데는 이유가 있다.그 제한사항이 만들어졌을 때, 베타를 전면적으로 금지하는 대신, 그 제한에 사람들이 동의하도록 하는 것은 나와 다른 사람들에게 어려운 주장이었다.위키백과 참조:관리자 알림판/사건/내가 베타코만드를 차단했다.— 칼 (CBM · talk) 20:54, 2011년 10월 25일 (UTC)[응답]

"...하지만 과거에 베타가 일으킨 만성적인 혼란을 막기에는 너무 약해."
아마도 내가 Δs의 이력을 충분히 확인하지는 못했지만, 당신이 파괴적이라고 생각하는 과거의 편집에 대해 몇 가지 차이점을 제공하고 이러한 편집들이 어떻게 프로젝트를 방해하는지 간단히 설명해 주시겠습니까?야마구치 도시오 (토크) 21:38, 2011년 10월 25일 (UTC)[응답]

CBM은 아마도 NFCC 정책의 시행을 초래한 베타코만드의 행동 중 하나를 인용할 것이다.베타코만드의 행동은 공정한 사용 근거 없이 수천 개의 부동한 이미지를 삭제하는 결과를 가져왔다.내가 읽은 바로는, 그것은 꽤 많은 사용자들을 화나게 했다.알파_Quadrant^(talk) 21:54, 2011년 10월 25일 (UTC)[응답]

편집 제한사항에는 이미 Δ가 NFCC의 시행을 무기한 금지된 주제라고 명시되어 있다.

@CBM: 이 제한의 목적이 기사로부터 자유롭지 않은 매체를 대량으로 삭제하는 것을 막기 위해서라는 말인가?야마구치 도시오 (토크) 22:09, 2011년 10월 25일 (UTC)[응답]

• 반대한다. MOS는 봇과 같은 편집자가 특정한 작업에 대한 사전 승인 없이 그것의 모든 측면을 집행할 수 있도록 하기에는 너무 많은 것을 가지고 있다.Δ는 분명히 WP를 따르지 않는다.예를 들어 CITEVAR.have mörser, will talk (talk) 17:28, 2011년 10월 25일 (UTC)[응답하라]

기사에 명확한 인용 스타일이 없는 경우, 어떤 편집자도 기사의 표준화를 한 가지 또는 다른 스타일로 할 수 있도록 허용(그리고 권장)템플릿 참조:인용 스타일.알파_Quadrant^(talk) 17:33, 2011년 10월 25일 (UTC)[응답]

제재가 지켜지기 어렵다고 불평하기 전에 당신은 불평했다; 마법처럼 받아들일 수 있는 막연하고 주관적인 범주를 제외하고는 모든 패턴이 토론을 필요로 할 때 얼마나 어려울지 상상해 보라.내가 보기에는 모든 패턴에 대한 논의를 요구하는 것이 훨씬 안전하고 분명할 것 같다."명확한" MOS 편집에 대한 예외는 문제와 혼란을 야기할 것으로 보인다.– 루나 산틴 (토크) 22:55, 2011년 10월 25일 (UTC)[응답]

• 위의 나의 논거에 따라 반대하라.MOS는 정책이 아닌 가이드라인으로 지역 합의에 의해 오버라이드될 수 있다.델타가 토론과 승인 없이 지역 합의를 무시하도록 해서는 절대 안 된다.테크노심비오시스 (대화) 23:22, 2011년 10월 25일 (UTC)[응답]

이것이 이 제안과 무슨 관계가 있는가?이 제안이 하는 일은 그의 편집이 25개 이상의 기사에 영향을 미치는 업무에 해당하지 않는 한 다른 사람들처럼 편집하도록 허용하는 것이다.이 제안이 하는 일은 반대 의견이 있거나 이 편집이 합의로 뒷받침되지 않은 경우 25개 이상의 기사와 유사한 편집을 금지하는 것이다.이 제안이 어떻게 그가 토론과 승인 없이 지역 합의를 무효로 할 수 있는지 보여주시겠습니까?내가 알기로는 Δ는 일반적으로 편집이 금지되어 있지 않다.야마구치 도시오 (토크) 00:36, 2011년 10월 26일 (UTC)[응답]

난 그게 꽤 확실하다고 생각해.당신의 제안은 '정책 내에서 명확하게 작성된 보고서(즉, 스타일 수정 매뉴얼)는 사전 논의가 필요하지 않다'고 말한다.나는 그것을 받아들일 수 있다고 생각하지 않는다.MOS는 우선 정책이 아니며, 그것 때문에 지역적으로 재정의될 수 있다.델타의 제한은 부분적으로 상황, 뉘앙스 또는 사전 합의 없이 자동화된(또는 자동화된) 패션으로 행동하는 것에서 기인한다.그는 이미 과거에도 이런 변화를 문제없이 일괄적으로 할 수 없다는 것을 입증한 바 있어 이 제한이 가해진 것이다.너의 제안은 명분도 없이 그 제한을 완화하려고 한다.델타가 그의 25개 조항 한도 내에서 적절한 변경을 할 수 있다는 것을 보여줄 때, 우리는 제한을 완화하는 것을 고려할 수 있다.전에는 안 그랬어.테크노심비오시스 (대화) 00:55, 2011년 10월 26일 (UTC)[응답]

제안 n+2

재구성됨, MOS 편집과 관련된 부분을 제거함.제한사항의 제안된 문구는 다음과 같다.

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.태스크는 30일 이내의 모든 편집 그룹으로 정의된다(그룹을 처음 편집한 시점부터 30일 이후의 동일한 시간으로 계산됨). 여기서 두 편집은 영향을 미치는 페이지와 해당 편집 번호 및 ID에 의해서만 달라진다.

”

이것은 MOS 편집에 관한 우려를 다루어야 한다.야마구치 도시오 (토크) 00:47, 2011년 10월 26일 (UTC)[응답]

그것은 주요 걸림돌로 보였다.고마워요.나는 아직도 (25쪽/30일)이 용돈으로 보여질까 봐 조금 걱정이 되는데, 여기서 나는 차라리 제3의 철도로 보는 게 낫지만, 모든 것이 평등하다는 것은 현재 시행되고 있는 문구보다 이것을 더 선호할 것 같다.– 루나 산틴 (대화) 00:51, 2011년 10월 26일 (UTC)[응답]

나는 '어떤 두 편집이 영향을 미치는 페이지와 디프 번호와 id에 의해서만 달라지는 경우'는 너무 좁은 정의라는 것에 근거하여 여전히 이 공식화에 반대한다.이 용어에 따르면 델타는 타이틀 케이스(예: 제목 케이스)에서 모든 기사의 이름을 제목으로 바꿀 수 있다.핼리 혜성(Halley's Comety)을 선고 케이스(예:핼리의 혜성) 그리고 이것이 분명한 패턴임에도 불구하고 용어는 각 변화의 내용이 다르기 때문에 허용한다(C->c, D->d 등).나는 모든 사람을 만족시킬 수 있는 용어는 없다고 생각한다 - 누군가는 항상 그것이 너무 엄격하거나 너무 관대하다고 생각할 것이다.나는 개인적으로 '각 편집자가 동일한 실질적인 변경을 수행하는 곳'이라는 표현을 선호한다.테크노심비오시스 (대화) 01:06, 2011년 10월 26일 (UTC)[응답]

• 나는 이것 또한 반대한다.삭제된 이미지를 제거하는 것은 분명히 나에게 패턴/태스크일 뿐이며, 삭제된 이미지가 페이지마다 다를 수 있기 때문에 이 문구는 그렇게 정의하지 않는다.Uʔ (대화) 05:55, 2011년 10월 26일 (UTC)[응답]

제안서 n+3: 만약 봇이 그것을 하도록 프로그램 될 수 있다면, 그것은 패턴이다.

정확한 diff 일치가 필요하지 않도록 재구성:

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.업무는 30일 이내의 모든 편집 그룹으로 정의된다(그룹을 처음 편집한 시점부터 30일 후의 동일한 시간까지 계산함). 여기서 두 편집 간의 차이는 정규 표현식에 의한 패턴 매칭과 같은 일반적인 컴퓨터 프로그래밍 작업의 구현으로 설명될 수 있다.

”

원하는 대로 자유롭게 수정했지만, 그 생각은 충분히 명확하다고 생각한다.기본적으로 프로그래머가 위키백과 봇과 반자동 스크립트 작성에 일반적으로 이용되는 노력으로 편집 작업을 할 수 있는 봇/스크립트를 작성할 수 있다면, 그것들은 이 제한의 목적을 위한 패턴으로 간주되어야 한다.이것보다 더 좁은 생각을 지지해 달라고 부탁하지 마라.ArbCom이 그들의 제재에 "광범위하게" 해석되는 이유가 있다: 절름발이 위키리위딩을 피하기 위해서.Uʔ (대화) 06:10, 2011년 10월 26일 (UTC)[응답]

이것은 또한 현재의 제한조치의 이면에 있는 의도였다.반자동화 또는 자동화된 작업처럼 보이면 승인이 필요하다.— 칼 (CBM · talk) 15:28, 2011년 10월 26일 (UTC)[응답]

내가 가상의 상황을 제공하겠다.일부 신뢰할 수 있는 주요 제3자 출처에서는 역대 최고 수익 영화 50편의 목록을 제공한다.델타는 이 정보를 여기 WP에 있는 50개의 영화 기사 각각에 추가하기를 원한다. 그들은 모두 동일한 참고문헌/씨이트를 사용할 것이고, 예를 들어, 50개의 기사 각각에 나타나는 특정 섹션의 끝에 있는 새로운 단락으로서 대본의 사전 형식화된 텍스트를 기사에 간단히 배치하도록 요구한다.반자동/자동 작업인가, 아니면 우리가 걱정해야 할 편집 패턴인가?

만약 그렇지 않다면, 나는 문제가 델타의 청소와 유지 관리 측면에 더 있다고 주장할 것이고, 그것으로부터 패턴을 식별하는 것은 실제로 훨씬 더 쉽다.기사 텍스트를 추가하거나 제거하지 않지만 봇으로 가능하거나 불가능할 수 있는 위키 코드를 정리하기 위한 편집의 개요를 명확하게 제시한 경우, 25개 기사 아래에 있어야 하는 "편집 패턴"으로 간주하거나 VPP 제한을 모색할 수 있는 "편집 패턴"의 시작을 알린다. --MASEM (t) 17:26, 2011년 10월 26일 (UTC)[응답]

내가 이것에 대해 더 많이 읽을수록, 나는 ArbCom에도 더 많이 보내져야 한다고 생각한다.내가 보기에는 Δ의 편집에서 '패턴'이 어떤 의미인지 커뮤니티가 결코 동의할 것 같지 않다.(위에 대해 불평을 많이 하는 더크 비트스트라는 이런 구체적인 제안에 대해 아직 자신의 의견을 밝히지 않았다.)"Delta는 여기 WP에 있는 50개의 영화 기사에 각각 이 정보를 추가하기를 원한다." - 만약 이것이 (일부 앨범이나 비디오 게임이 가지고 있는) 리뷰 스타를 추가하는 것과 같은 익폭스 편집과 관련이 있다면, 나는 그것을 하는 프로그래밍된 작업을 상상할 수 있기 때문에 승인을 받아야 한다.만약 그가 각 페이지에 텍스트 한 단락을 추가하려고 한다면, 각 단락은 페이지의 주제에 관련된 가상의 출처로부터 요약이나 인용만을 포함하고 있다면, 나는 누군가가 그것에 대해 봇을 프로그램할 가능성은 낮다고 생각하므로, 나는 승인을 요청할 필요가 없다고 본다.U u (대화) 2011년 10월 26일 18:00 (UTC)[응답]

1년에 걸쳐 25편의 기사 편집이 포함된 보기 힘든 패턴 때문에 사람들이 불평하지 않는다는 것을 기억하는 것이 유용하다고 생각한다.이번 호는 동일한 편집 요약을 가진 2,000개의 편집에 관한 것이다.그래서 이상적인 세계에서는 '패턴'이 무엇인지 정확하게 아는 것이 좋을 수도 있지만, 실제로는 그 패턴이 완전히 명백하여 모호한 정의라도 충분하다.— 칼 (CBM · talk) 18:36, 2011년 10월 26일 (UTC)[응답]

칼(위 진술이 제재의 이질적 공동체 의도와 매우 밀접하게 일치한다는 것을 포함)을 반추하면서, 순수한 증오나 심지어 진정한 혼란을 목적으로 어떤 미래 시나리오에서 "패턴"의 불가사의한 정의가 발동될 것이라는 증거는 전혀 없다.그것은 여기 편집자의 아주 작은 부분집합(2 또는 3)의 발명이다.사람들은 패턴을 식별하고 분류하는데 꽤 능숙하다.많은 독립 편집자들은 최근의 편집 이력이 패턴, 즉 개별적인 "규칙"에 따라 각각 제정된 기사에 대해 서로 다른 일련의 변경을 할 때 동일한 편집 요약을 사용하지만, 대상 기사가 그 "규칙"을 위반하는 실제 사례가 있을 때만 제정된다는 것을 확인했다.편집된 내용을 검사할 때는 정말 분명하지만, 유용한 테스트는 "규칙 위반"이 시정되지 않은 경우를 찾아보는 것이다.그것은 한 사람이 한 번에 한 가지씩 그것을 개선하면서 기사를 통해 작업하고 있었다는 설득력 있는 증거가 될 것이다. 그러나 나는 그러한 증거가 존재하는지 의심스럽다.오버헤치 패턴이 꽤 선명하다.베타가 기사 2개 또는 200개에 대해 일련의 긍정적인 가시적 텍스트 기고를 하는 것에 대해 아무도 반대하지 않았고, 만약 그렇게 한다면, 나는 바로 그 자리에서 피실험자를 소리쳐 쓰러뜨릴 것이다.프라나맥스 (대화) 02:49, 2011년 10월 27일 (UTC)[응답]

내가 보기에 만약 우리가 같은(또는 본질적으로 같은) 편집 요약을 패턴의 일부로 고려한다면, 실제 편집이 묘사된 패턴을 형성하든 아니든 간에 (내 제안서 n+6 참조) 합리적인 것 같다.— 아서 루빈 (대화) 02:16, 2011년 10월 28일 (UTC)[응답]

제안 n+4

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.태스크는 30일 이내의 모든 편집 그룹으로 정의된다(그룹 첫 번째 편집 시점부터 30일 이후의 동일한 시간까지 카운트). 여기서 태스크의 모든 편집(편집 내용에 영향을 받지 않는 마지막 수정본과 편집의 변경 내용을 포함하는 첫 번째 수정본 사이의 모든 변경)은 단순한 함수로 표현 가능하다.함수(이 제한의 목적상)는 20단어 이하로 구성된 서면 텍스트를 통해 표현할 수 있다면 간단하다(예:아티클 마크업에서 발생하는 모든 + 항목을 -로 변경(예:기사 제목 그룹의 예시 발생 사례를 모두 예시로 변경).

”

편집마다 내용이 달라지는 편집 패턴에 대한 우려를 해소하기 위해 본문을 수정했다.야마구치 도시오 (토크) 14:41, 2011년 10월 26일 (UTC)[응답]

• 주석;모든 사람을 행복하게 하려는 시도가 많아질수록 모든 사람은 불행해질 것이다.이 시간이 길어질수록 윈도 비스타와 더 비슷해 보일수록 맥주캔과 철조망이 더 커진다.더 문제가 되는 것은 그것이 더 오래 걸릴수록 위키리거들이 허점을 이용할 기회가 더 많아진다는 것이다.앙투안 드 생텍쥐페리 --해머소프트 (토크) 15:04, 2011년 10월 26일 (UTC)[응답] : "디자이너는 추가할 것이 없을 때가 아니라 빼앗을 것이 없을 때 완벽을 달성했다는 것을 알고 있다."

내 의견의 문제는 그 제한이 모든 것을 요점까지 못박지 않는다면 Δ가 그의 제한을 위반했다는 논의와 비난이 계속될 것이라는 점이다.내 희망은 (그리고 이것이 가능한지 나는 모르겠다) 제한에 대한 모호하지 않은 공식화를 만드는 것이고, 아마도 그가 제한을 위반했다고 비난하는 사람들이 그의 편집이 실제로 그리고 분명히 제한을 위반한다는 증거를 제공해야 하는 것을 포함할 것이다.WP의 현재 공식:RESTRICT는 분명히 이것을 달성하지 못하기 때문에 누구든지 패턴을 구성하기 위해 Δs 편집의 일부를 주장할 수 있고 아무도 그것이 사실인지 아닌지를 합리적으로 알 수 없다.만약 본문이 충분히 수정될 수 있다면, 우리는 아마도 사람들이 "Δ가 여기 저기 저기서 그렇게 했다 (diff) (diff) (diff) (diff)이는 XY 기간에 걸쳐 이루어졌고 그 기간 동안 Z 편집에 해당하기 때문에 제한을 위반하는 것이다."그것은 절대적으로 객관적일 것이다.야마구치 도시오 (토크) 15:24, 2011년 10월 26일 (UTC)[응답]

• 탁월한 목표다. --Hammersoft (대화) 15:31, 2011년 10월 26일 (UTC)[응답]

• 제안: 나는 위의 제한사항 공식에 제안서를 포함시키고 싶다.의 선에 따라 무엇인가가 떠오른다.

Δ가 이 제한을 위반했다는 증거의 부담은 위반이 있다고 주장하는 사람들에게 있다.이 증명은 디프의 타임스탬프에서 위반이 명백하도록 편집에 차이를 제공하는 형식을 취해야 한다.이러한 위반 증거는 WP에서 보고해야 한다.A/I."

야마구치 도시오 (토크) 15:44, 2011년 10월 27일 (UTC)[응답]

제한사항의 제안된 공식의 전체 텍스트는 다음과 같다.

제안 n+5

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.태스크는 30일 이내의 모든 편집 그룹으로 정의된다(그룹 첫 번째 편집 시점부터 30일 이후의 동일한 시간까지 카운트). 여기서 태스크의 모든 편집(편집 내용에 영향을 받지 않는 마지막 수정본과 편집의 변경 내용을 포함하는 첫 번째 수정본 사이의 모든 변경)은 단순한 함수로 표현 가능하다.함수(이 제한의 목적상)는 20단어 이하로 구성된 서면 텍스트를 통해 표현할 수 있다면 간단하다(예:아티클 마크업에서 발생하는 모든 + 항목을 -로 변경(예:기사 제목 그룹의 예시 발생 사례를 모두 예시로 변경). 참고: Δ가 이 제한을 위반했다는 증거의 부담은 위반이 있다고 주장하는 사람들에게 있다.이 증명은 디프의 타임스탬프에서 위반이 명백하도록 편집에 차이를 제공하는 형식을 취해야 한다.이러한 위반 증거는 WP에서 보고해야 한다.A/I.

”

야마구치 도시오 (토크) 16:33, 2011년 10월 27일 (UTC)[응답]

터무니없는 것으로 반대하다.예를 들어, "예" 예제에 적절한 규칙은 "자본화 변경"이다. 2단어.또한 Δ가 동일한 편집 요약을 사용하는 경우 ANI를 처리하지 않고 동일한 작업으로 계산해야 한다.즉, 만일 Δ가 그의 업무가 "정리"라고 말한다면 우리는 그의 말을 믿어야 하며, 그것을 "과제"로 간주해야 한다.— 아서 루빈(토크) 17:06, 2011년 10월 27일 (UTC)[응답]

이는 불합리하다고 반대할 이유가 아니라 정확하고 의미 있는 편집 요약을 제공하기 위해 Δ를 요구하는 것이다.야마구치 도시오 (토크) 17:13, 2011년 10월 27일 (UTC)[응답]

대부분 나는 이것이 확실하다고 생각한다. 그리고 30일안에 문제가 해결될 것이다.하지만 나는 "증거의 부담" 언어를 이해하지 못한다.최근의 예에서는 베타가 삭제된 이미지로의 링크를 삭제한 25개 이상의 기사 목록을 줄 수 있다는 것에 의문의 여지가 없었으므로, 이 입증책임을 쉽게 충족시킬 수 있었을 것이다.이것의 동기는 무엇인가?— 칼 (CBM · talk) 17:51, 2011년 10월 27일 (UTC)[응답]

Δ가 제한을 위반하면 차단된다고 가정하자.그렇다면 Δ나 블록을 다투는 다른 사람에게 그가 실제로 제한을 위반하지 않았다는 것을 증명하도록 요구하는 것은 불합리하다고 생각한다.내 생각에, 그를 가로막는 사람은 Δ가 실제로 그의 제한을 위반했다는 증거를 (확실히) 제공해야 한다.야마구치 토시오 (토크) 18:06, 2011년 10월 27일 (UTC)[응답]

그것은 불합리하지는 않지만, 만약 그 증거가 "마지막 100번의 편집을 보았고 그 중 75개는 모두 동일한 작업을 포함하고 있다"라면, 기여 페이지에서 이미 이용할 수 있는 그러한 차이점들을 누군가에게 수동으로 복사하도록 요구하는 것은 이상해 보인다.만약 편집된 내용이 덜 명백하다면, 그것은 더 합리적인 것 같다.— 칼 (CBM · talk) 18:10, 2011년 10월 27일 (UTC)[응답]

"증거 부담" 부분은 WP와 인라인으로 연결되어 있다고 생각한다.AGF(그리고 내가 아는 한 Δ는 자신에게 AGF를 적용했을 때 탁월하지 않다.이것의 목적은 이 제한에 관하여 Δ에 추가적인 여유를 주는 것이 아니라, 예를 들어 Δ가 증거가 제공되기 전에 조기 차단되는 것을 방지하기 위함이라는 점에 유의하십시오.위반의 증거가 있다면 제재(블록 등)를 적용하는 것은 대부분 논란의 여지가 없어야 한다.야마구치 도시오 (토크) 18:34, 2011년 10월 27일 (UTC)[응답]

그러나 제안된 본문은 증거가 제공되기 전에는 그를 차단할 수 없다고 말하지 않는다. 즉석에서 증거를 차단한 다음 ANI에 배치하는 것은 본문과 일치하는 것으로 보인다.그러나 나는 왜 "그의 기여에서 마지막 50개의 편집을 보라"는 단순한 문구가 지난 50개의 편집에 대한 차이점 목록보다 훨씬 더 나쁜지 모르겠다.또한 베타와 어느 정도 선의로 가정해야 하지만, 베타의 이력과 편집 제한은 베타를 아직 그 사이트를 모르는 새 편집자처럼 취급하는 것은 어리석은 짓이라는 것을 의미한다.— 칼 (CBM · talk) 18:49, 2011년 10월 27일 (UTC)[응답]

본문은 증거가 제시되기 전에 그를 차단할 수 없다는 것을 의미하지는 않는다.미안, 내가 전에 답장에서 한 말은 분명히 틀렸어.이 사용자를 둘러싸고 있는 드라마의 양을 줄이기 위한 것이다.그리고 나는 그가 그 제한을 위반했다는 명확한 증거가 제공된다면, 이 블록은 거의 논란의 여지가 없을 것이라고 믿는다.야마구치 도시오 (토크) 19:03, 2011년 10월 27일 (UTC)[응답]

고마워, 그리고 난 너의 마지막 문장에 전적으로 동의해.— 칼 (CBM · talk) 22:06, 2011년 10월 27일 (UTC)[응답]

아래 제안서 n+7에 요약 편집에 관한 요구사항을 추가했다.야마구치 도시오 (토크) 23:09, 2011년 10월 27일 (UTC)[응답]

제안 n+6(요약 편집, 동일한 작업)

“

25개 이상의 기사에 영향을 미치는 과제를 수행하기 전에 베타콤랜드 / Δ는 WP에서 과제를 제안해야 한다.VPR을 사용하고 최소 24시간 동안 커뮤니티 토론을 기다리십시오.만약 반대 의견이 있다면, 베타코만드 / Δ는 그가 시작하기 전에 그 요청을 지지하는 합의를 기다려야 한다.태스크는 30일 이내의 모든 편집 그룹으로 정의된다(그룹을 처음 편집한 시점부터 30일 이후의 동일한 시간으로 계산됨). 여기서 편집 요약은 기본적으로 동일하다(예: "정리" "삭제된 이미지 삭제(파일 이름), "정확한 대문자화", "이동 태그").이것은 기존의 제한을 없애는 것이 아니라, 위키피디아가 동일한 편집 요약을 가진 편집이 동일한 작업이라고 가정해야 한다는 것을 명확히 하는 것이다.

”

— 아서 루빈 (대화) 17:06, 2011년 10월 27일 (UTC)[응답]

• 좋은 설명.ASCIIn2Bme (대화) 18:01, 2011년 10월 28일 (UTC)[응답]

제안 n+7

요약 편집에 대한 요구 사항을 추가했다.야마구치 도시오 (토크) 22시 30분, 2011년 10월 27일 (UTC)[응답]

• Δ의 부분에 대한 가장 터무니없는 편집조차도 그의 지지자들에 의해 끝도 없이 논쟁의 대상이 될 수 있게 만드는 임의의 후프를 도입하는 것에 반대한다."기능"의 전체 정의와 위반에 대한 청구에 대한 "증거 부담" 요소의 추가는 그의 입장에서의 거의 모든 오해가 의미론과 불완전하다는 판단에 의해 지상으로 논의될 수 있는 끝없는 수단을 제공한다. 또는 편집이 너무 복잡해서 정의될 수 없다.20단어 알고리즘 설명.이게 어떻게 개선됐는지 도저히 알 수 없다. --트리스테사 (토크) 00:21, 2011년 10월 28일 (UTC)[응답하라]

나는 그것이 적절하지 않다고 생각한다."변경 대문자화" 또는 "삭제된 이미지를 제거(또는 주석으로)"하는 것으로는 충분하지만, 설명에 반드시 충분하지는 않을 것이다.그런 점을 감안할 때 명백한 위반을 제외하고는 증거가 게시되기 전에 합법적으로 블록이 만들어질 수 있다는 점을 제외하면 입증 책임은 합리적으로 고발자에게 돌아갈 수 있다.그러나, 그때도, Δ에 너무 많은 부담을 주고 있는데, Δ는 AWB와 같은 편집을 포함하여, 그의 편집 각각에 상세한 편집 요약을 넣어야 하기 때문이다.그가 그럴 수 있을지 모르겠으니, 평소 의도적인 위반과는 달리 우연히 위반했을지도 모른다.— 아서 루빈(토크) 01:29, 2011년 10월 28일 (UTC)[응답]

나는 델타의 편집 도구가 위키피디아의 일반적으로, 그리고 특별히 그의 편집 조건들을 준수할 수 없다면, 그는 그것들을 사용하는 것을 피해야 한다고 제안하고 싶다.그의 제한의 용어는 델타에 어떤 종류의 행동을 기대하느냐에 기초해야 하며, 그의 문제 있는 편집 도구가 무엇이냐에 기초해서는 안 된다.테크노심비오시스 (대화) 01:36, 2011년 10월 28일 (UTC)[응답]

이것. 우리는 이 모든 것을 잘못 생각하고 있다. 도구를 제어하는 편집 제한사항으로 나뉜다. 그러나 문제를 해결하지는 않는다.강력한 자동차를 가진 나쁜 운전자는 자동차가 어디로 갈 수 있는지에 대한 제한이 아니라 운전 레슨이 필요하다.이 '패턴' 헛소리는 집어치우고, "이 사용자는 정책 내에서 그리고 합의 내에서 편집해야 한다"는 말만 하십시오.그는 명확한 편집 요약을 사용해야 한다.그는 합의가 반대되는 일을 해서는 안 된다.만약 그에게 실수나 의견 일치를 거스르는 편집이 지적된다면, 그는 반드시 예의 바르게 행동하고 그 문제를 조사해야 한다.만약 그가 또다시 같은 실수를 저지르거나 합의 없이 편집한다면 - 그것이 그에게 지적되었다는 것을 인정하고, 그 문제를 예의 바르게 논의한다면, 그는 차단될 것이다.누군가 실수나 다른 현명한 대상을 지적할 때 미개하면 막히게 된다고 말했다.도로의 엘렌 (대화) 16:01, 2011년 10월 28일 (UTC)[응답]

나는 엘렌과 함께 있다.제한사항의 이 정도의 세부사항은 말도 안 된다.베타코만드는 WP 정책이나 가이드라인을 준수하는 동안 편집을 할 수 있거나 할 수 없다.그가 공감대를 가지고 편집하고 있든 아니든 둘 중 하나다.만약 그가 공감대를 가지고 있고 지침과 정책을 따르고 있다면, 그가 하고 있는 일을 묘사하는 데 얼마나 많은 단어가 필요한지 누가 알겠는가?카라낙스 (대화) 2011년 10월 28일 (UTC) 16:12, 응답

나는 우리가 본론으로 들어가야 한다는 것에 동의한다.베타는 어떤 종류의 대규모 유지보수 편집도 수행해서는 안 되며, 연대적이고 성공적인 편집의 실적이 있을 때까지 콘텐츠 편집에만 그 자신을 제한해야 한다.— 칼 (CBM · talk) 00:19, 2011년 10월 29일 (UTC)[응답]

제안 n+8

나는 제기된 몇 가지 우려를 해소하기 위해 제한사항의 문구를 추가로 수정했다.좀 더 정밀하게 정의해야 할 점은 Δs의 요약 편집 요건이 어느 정도 합리적으로 그가 변경한 내용과 일치해야 한다는 것이다.이 제한은 또한 이러한 편집 요약이 따라야 하는 기본적인 표현을 정의해야 한다.야마구치 도시오 (토크) 09:02, 2011년 10월 28일 (UTC)[응답]

제한사항이 의회 법안처럼 보이면 안 된다 --GuerilleroMy Talk 17:00, 2011년 10월 28일 (UTC)[응답]

나도 동의해, 이건 확실히 너무 복잡해서 실용적이지 못해.ASCIIn2Bme (대화) 17:02, 2011년 10월 28일 (UTC)[응답]

단순화

이미 언급한 바와 같이, 이것은 점점 미쳐가고 있으며, 위키리워링에 가깝다.

필자에게 있어, 현재의 제한은 기사 평문 내용을 추가하거나 삭제하는 것이 아니라 읽기 쉽도록 백업 Wikipode를 수정하는 것으로 느슨하게 정의되어 기사 "유지"에서 델타의 행동을 느리게 하기 위해 시행되고 있으며, WP의 성능을 향상시키거나 데드 링크 템플릿 추가나 데이트 정리 템플릿 추가와 같은 다른 프로세스를 관리하는 것이다.델타항공이 과거에 인간이 잡을 수 있는 중대한 실수를 저지르고, 잘못되면 반응하지 않는다는 이유로 비판 받아온 행동들이다.

따라서 여기서 중요한 점은 첫 번째 제한 사항을 유지보수 작업에 관한 것으로 수정하는 것이며, 유지보수 작업은 25개의 편집 번호를 충족하도록 광범위하게 제한된다.따라서 이러한 작업에 대한 델타 승인에 대한 위의 프로세스는 바로 여기에 해당되며, 델타가 다른 유지 보수 작업을 수행하려면 먼저 VPR에 대한 승인을 받아야 한다.

이것은 또한 델타가 기사 텍스트에 추가할 경우, 유지 보수 작업(그렇지 않으면 일반적으로 텍스트를 추가하는 작업의 일부)을 기사에 맡기지 말고, 그 대신 별도의 편집을 해야 한다는 것을 의미한다.예를 들어, 만약 그가 참고자료를 추가한다면, 그 때 그것을 올바른 순서로 배치하면 문제가 없다.그러나 참조를 추가하고 다른 곳에서 공백 수정 작업을 같은 편집으로 수행해서는 안 된다.

그가 텍스트 내용을 삭제해야 하는가에 대해서는 여기서 선의로 생각해야 하며, 정상적인 편집도 40 편집/10분 규칙에 따른다는 점을 감안할 때 델타가 의심스러운 삭제 조치를 취한다면 다른 편집자와 마찬가지로 잡아서 처리할 수 있다. --MASEM (t) 16:31, 2011년 10월 28일 (UTC)[응답]

• 지원 내 제안(n+10) 이후 두 번째 선택.--NYKevin @753, 즉, 17:04, 2011년 10월 28일 (UTC)[응답]
• 지지하다.이것은 나에게 훨씬 더 이치에 맞는다.카라낙스 (대화) 17:39, 2011년 10월 28일 (UTC)[응답]
• 나는 그 제안서를 두 번 읽었는데, 여기서 실제로 제안되고 있는 것이 무엇인지 아직도 전혀 모르겠다.ASCIIn2Bme (대화) 17:59, 2011년 10월 28일 (UTC)[응답]
  • 나는 그것을 제안으로 받아들이려고 한 것이 아니라, 좀 더 구체적으로 말하자면, 첫 번째 공동체 제한은 어떤 "유지관리 업무"를 특별히 목표로 하고 있다는 것이다. 즉, 기사의 실제 본문을 건드리지 않고 그 뒤에 있는 위키 코드를 고치는 것으로 광범위하게 해석된다.이로 인해 델타는 여전히 자유롭게 어떤 "진정한 편집"(기사 텍스트의 수정)을 할 수 있게 되는데, 이것은 일반적으로 패턴에 빠지지 않고, 여전히 4분의 1로 긴장하고 있는데, 이것이 지역사회가 그를 밀어붙이기를 원하는 것처럼 보인다.그는 여전히 유지할 수 있지만, 그가 하는 유지보수가 매우 구체적이고 기술적으로 이루어져야만 한다. --MASEM (t) 20:03, 2011년 10월 28일 (UTC)[응답]

제안서 n+9: 커뮤니티가 부과하는 모든 제한 해제

단순히 공동체가 부과하는 모든 제한을 해제하십시오.n+7의 Elen of the Roads' 의견을 참조하십시오.WP:MEATBOT는 정책이기 때문에 Δ가 [지정되지 않은] 제한속도를 시험하고자 한다면 할 수 있지만, 합의에 어긋난다면 erhöhte Betriebsgefahr를 받는다.ASCIIn2Bme (대화) 16:35, 2011년 10월 28일 (UTC)[응답]

베타는 편집 제한에 대한 필요성을 거듭 입증했다.어떤 것이든, 우리는 더 엄격한 규제로 옮겨야 한다.— 칼 (CBM · talk) 00:17, 2011년 10월 29일 (UTC)[응답]

• 누군가 "Δ"를 언급할 때마다 지역사회에서 그를 두들겨 팼다고, 그래.Δ 그 자체로?그렇게 많지는 않지만, 끔찍하게 작성된 제한에 대한 대체 제한 사항을 작성하기 위한 n+인피니티 제안이 있는 이 하위 스레드가 지역사회의 행동의 부조리를 증명한다고 한다면. --Hammersoft (대화) 13:20, 2011년 10월 29일 (UTC)[응답]

관련된 관리자라도 WP와는 달리, 분명히 자동화된 편집이 그의 아이디어를 포함하여 어떤 잘못도 저지할 수 있는 경우에만:MOS, 그 {{dead link}} 태그는 < ref> 태그 안에 있어야 한다.— 아서 루빈(토크) 2011년 10월 29일 20:31 (UTC)[응답]

그렇다면 {{dead link}}}에 설명서를 업데이트해야 할 것 같은데, 현재 글에서 클릭 가능한 각주를 사용한다고 되어 있는 경우, 이 태그는 데드 링크가 포함된 </ref> 바로 앞에 붙여야 한다. 그러면 통지가 참조 섹션에 올바르게 나타난다(권장하지 않는 텍스트 본문 대신).ΔT 20:37, 2011년 10월 29일 (UTC)[응답]

Δ의 이력으로 미루어 볼 때 이 제안은 좋은 생각이 아닌 것 같다.칼다리 (대화) 06:43, 2011년 11월 1일 (UTC)[응답]

제안서 n+10: 상식

(충돌 편집)이건 말도 안 돼.그 "기능" 아이디어는 결코 효과가 없을 것이다.그의 제한을 어기지 않는 것이 베타콤랜드 / Δ의 일이다."기능" 아이디어는 위키리거링과 광기의 관문이다.또한 제재완전 해제는 좋은 생각이라고 생각하지 않는다.--NYKevin @728, 즉, 2011년 10월 28일 (UTC)[응답]

음, 누가 위 (n+10)를 제안했는가?내 생각에 NYKevin은 단지 그것에 동의하지 않기 위해 그것을 제안하지 않았겠죠...ASCIIn2Bme (대화) 16:39, 2011년 10월 28일 (UTC)[응답]

위 (n+10)를 제안했다.내가 어디서 그것에 동의하지 않았을까?(n+9)에 동의하지 않는다는 것을 알 수 있지만, 그것은 내 것이 아니다.--NYKevin @739, 즉, 16:44, 2011년 10월 28일 (UTC)[응답]

이 차이점에 따르면 NYKevin은 n+10을 제안했다.야마구치 도시오 (토크) 16:45, 2011년 10월 28일 (UTC)[응답]

그래, 설명해줘서 고마워.바로 밑에 "이건 말도 안 돼."라고 쓰고 거기에 (갈등 편집) 접두사를 붙이는 것은 나를 혼란스럽게 했다.ASCIIn2Bme (대화) 16:48, 2011년 10월 28일 (UTC)[응답]

미안, (n+8)와 다른 모든 것에 대해 "기능"을 언급하고 있었어. --NYKevin @745, 즉, 16:53, 2011년 10월 28일 (UTC)[응답]

나는 지금 n+10과 n+3의 차이점을 이해하려고 노력하고 있다...ASCIIn2Bme (대화) 16:58, 2011년 10월 28일 (UTC)[응답]

(iii) n+3은 정규식 및 기타 구체적인 기준을 언급한다.이것은 상식적인 접근법을 적용하여, 규칙을 어기지 않도록 베타코만드 / Δ에 오누스를 놓는다. --NYKevin @751, 즉, 17:01, 2011년 10월 28일 (UTC)[응답]

예를 들면.유일한 구체적인 기준은 컴퓨터 프로그래머가 잠재적으로 매우 유사한 것을 코딩할 수 있다는 것이다.이는 단순히 "사용자 상식"이라고 말하는 것 보다 더 구체적이지만, ANI에서 보았듯이, 그러한 의미에서 "패턴"을 쉽게 해석하는 것은 일부 사람들에게는 효과가 없었기 때문에 WP:이 경우에는 상식이 없고, 마음에 들면 '공통 프로그래머 감각'밖에 없다.ASCIIn2Bme (대화) 17:07, 2011년 10월 28일 (UTC)[응답]

IMHO Betacommand / Δ는 규칙을 따르고 문제를 피하는 책임을 갖는 것이 매우 중요하다.그는 제재를 받고 있다.그런 것들은 폭넓게 해석해야 하고, 경계선이라 하더라도 의심스러운 것은 피해야 한다.제재 대상이 된다는 뜻. --NYKevin @757, 즉 17:10, 2011년 10월 28일 (UTC)[응답]

• 왜 이 문제 사용자가 모든 사람의 시간을 그렇게 많이 낭비하도록 허락되는가?86.160.218.77(대화)

ArbCom이 직접 이 제재들을 검토하기로 결정한 것으로 보인다.

나는 사람들이 그들의 시간을 낭비하지 않기 위해 이 노트를 만들고 있다! 개별적인 제안들에 대한 투표는 머지않아 그것들이 충분히 엉망이 될 것 같기 때문이다.위키백과 참조:중재/요청/정리#모션.ASCIIn2Bme (대화) 22:10, 2011년 10월 31일 (UTC)[응답]

좋았어. 우리는 공동체가 부과하는 제약으로 인해 많은 혼란을 보아왔기 때문에 나는 그들이 명확하고 내부적으로 일관된 규제들을 내렸으면 좋겠다; 나는 그들이 하는 일이 현재의 제한사항보다 더 이해하기 쉽고 실행하기 쉬운 한, 그들이 하는 일은 정말 신경 쓰지 않는다.나이튼드 (대화) 06:26, 2011년 11월 3일 (UTC)[응답]