위키백과:관리자 알림판/아카이브2

내용:2004년 12월 9일 - 2005년 1월 31일

작업

WP:PUI

WP 출처:CU: 위키백과:미지근한 이미지일 수 있으므로 관리자의 심각한 주의가 필요하다.그 페이지에는 어떤 면에서 문제가 있고 9월 말 이후로 분명히 참석하지 않은 이미지들이 나열되어 있다.Thuresson 15:10, 2004년 12월 9일 (UTC)

그렇게 오래 방치된 것은 아니지만, 오래된 출품작의 밀린 부분이 매우 많다. -- Infrogmation 00:08, 2004년 12월 13일 (UTC)

오래된 물건의 밀린 것이 이제 거의 다 없어졌다.예이. -- Infrogmation 18:31, 2004년 12월 23일 (UTC)

WP:CP

위키백과의 하우스키핑에 대한 도움말:저작권 문제는 감사하게 생각한다. -- Infrogmation 08:06, 2004년 12월 10일 (UTC)

그렇다면 우리는 그리스도의 오순절 교회를 위해 브라질과 같은 것을 어떻게 해야 하는가? - 타부시 다 유 09:27, 2004년 12월 10일 (UTC)

그리고 [1]의 마르첼린 챔파그나트.그 기사는 다시 쓰여졌고 현재 카피비오는 편집 역사에 있다! - 타부시 다 유 09:32, 2004년 12월 10일 (UTC)

또한 편집 기록에서 (개발자에 의해) 제거되어야 하는 외딘 폰 호르바스를 참조하십시오.[2] - Ta bu si da u 09:34, 2004년 12월 10일(UTC)

어려운 경우를 결정하는 데 도움을 주는 것은 매우 감사한 일이다.그러나 페이지를 관리 가능한 크기로 유지하기 위해서는 적절한 경우 명백한 사례를 제거하는 작업이 항상 필요하다. -- Infrogmation 00:08, 2004년 12월 13일(UTC)

차단 버그

MediaWiki 1.4의 다소 심각한 버그로 인해 지정된 만료 날짜와 시간 이후에 블록이 만료되지 않으며, 사용자/IP가 수동으로 차단 해제된 경우에만 블록이 해제된다.오늘 아침에 차단 해제 작업을 많이 했지만 버그가 고쳐질 때까지 시간이 좀 있는 사람이 있다면 정기적으로 Special:블록이 만료된 사용자의 차단 해제 및 IP 차단 목록.Rdsmith4—Dan Talk 17:54, 2004년 12월 26일(UTC)

우연히 다른 버그로 인해 "무제한" 또는 "무한" 블록의 만료 시간이 현재 날짜와 시간으로 지정되므로 차단 해제하지 마십시오.Rdsmith4—Dan Talk 19:51, 2004년 12월 26일(UTC)

오늘 저녁에 몇 번 더 했다.벌레가 빨리 고쳐졌으면 좋겠다.한편, 적어도 버그가 고쳐질 때까지 애당초 블록을 쉽게 사용하도록 노력해야 할 것이다.테레사 너트 (The snott rack) 00:10, 2004년 12월 27일 (UTC)

고마워; 이제 버그에 대해 알게 되었을 뿐만 아니라, 이 환상적인 게시판에 대해 알게 되었다. : --골베즈 *** 09:47, 2004년 12월 27일 (UTC)

이는 블록 로그에 블록 길이 대신 블록 이유(172개 차단된 "사용자:165.247.204.19")가 표시되며 만료 시간이 (표절과 역전)인 것과 관련이 있을 수 있다.--fvw* 14:02, 2004년 12월 27일(UTC)

이 벌레들은 일제히 불행한데, ETA에서 고치는 건 없나?내가 실수로 영구적인 IP를 차단하지 않았을지도 모른다; 그들이 다시 쉽게 발견될 수 있도록 그들의 행동을 계속하기를 바란다.더 주의할 것을 약속한다.--—벤 브로커트(42) UE 뉴스 *** 04:28, 2005년 1월 1일 (UTC)

이 모든 논의를 보관하게 되는 사용자에게: 버그가 해결될 때까지 이 토론을 주의사항으로 남겨 두십시오.Rdsmith4—Dan Talk 03:59, 2005년 1월 3일(UTC)

VfD 백로그

누가 이것 좀 봐줄래?진공 c *** 01:25, 2005년 1월 2일(UTC)

반달리즘을 되돌리는 것에 대한 알림

반달족들을 되돌릴 때 과거의 편집된 내용을 확인해 달라고 모두에게 다시 한 번 부탁하고 싶다(나도 이것을 잊어버린 것은 인정하지만, 매우 중요하다).--fvw* 2005년 1월 5일(UTC) 14:07

보관 중인 사고 보고서에서 이 사실을 발견함.우리 모두는 대부분 기억하겠지만, 상기시키는 것은 상처를 줄 수 없다...노엘 (대화) 15:08, 2005년 1월 7일 (UTC)

위키백과:삭제 도움말 템플릿

삭제하기 위해 여러 개의 템플릿이 지워지고, 약간의 밀린 로그가 있다.누가 좀 도와주시겠습니까? -- Netoholic @ 23:03, 2005년 1월 6일 (UTC)

이것은 이제 다소 나아진 것 같다.다음 항목을 참조하십시오.노엘 (토크) 03:57, 2005년 1월 8일 (UTC)

페이지 및 기타 정리 작업에서 삭제될 템플릿을 지우고 계속 작업을 수행하려고 노력했었습니다.관리자가 "보류 영역"만 볼 수 있다면, 삭제될 템플릿을 배치해 둘 것이다.갈 준비가 된 것들은 "깨끗한" 것으로 기록될 것이다.고마워. -- Netoholic @ 07:58, 2005년 1월 8일 07:58

위키백과:삭제 도움말 범주

이것도 좀 치워야 할 것 같아.노엘 (대화) 2005년 1월 7일 20:00 (UTC)

이것은 정말 크게 밀렸다.나는 하루의 대부분을 방대한 양의 자료들을 해킹하는 데 보냈는데, 여전히 그것은 완전히 지나치게 자랐다.이 페이지는 영구적인 배일리윅으로 이 일을 떠맡고 지역 경찰로 거듭나기 위해 일부 행정관이 절실히 필요하다.아아, 그냥 시간이 없어.자원봉사자가 있나?노엘 (토크) 03:57, 2005년 1월 8일 (UTC)

나는 위키피디아를 가지고 놀 때마다 그것을 두드린다.위키피디아에서 하는 거의 유일한 일이라는 지경에 이르렀다.그럼에도 불구하고, 나는 최근에 게으름을 피웠고, 다른 취미 생활로 시간을 보내고 있어.누구나 조금씩은 도움이 된다.(어쨌든 희귀한 시간) CfD로 끝내면 (범주에) 삭제 표시가 된 카테고리를 땡땡이 치기 시작하지만 CfD에는 나열되지 않았다.(본질적으로 비어 있으면 간다)그렇지 않고 CfD에 없을 경우 통지문은 제거된다.) --ssd 05:01, 2005년 1월 9일(UTC)

나는 몇 시간 동안 삭제를 가장 필요로 하는 카테고리만 삭제했는데, 아직 몇 개 남아 있다.그러나 나는 CfD 페이지의 잔여물을 치우지 않았다. 일부 비관리자는 아마도 나만큼 잘 할 수 있다.또한, 투표한 것은 많지만, 취한 조치는 없다(다른 범주로 기사를 옮기는 것 같은 것).이것은 아마도 큰 범주별로 봇에 의해 수행되어야 하며, 작은 범주에서는 사람 또는 봇에 의해 수행되어야 한다.(이 작업은 관리자가 아닌 사람이 수행할 수도 있다.)봇도 있지만 방학인 것 같아. --ssd 08:06, 2005년 1월 9일(UTC)

나는 그 봇이 이미 옮겨져야 할 꽤 많은 범주들의 밀린 작업들을 하고 있다고 생각한다. (위키피디아:삭제/미국 대 미국) 범주이므로 모든 것이 정리되는 것은 시간문제일 뿐이다. --ssd 13:57, 2005년 1월 10일(UTC)

마지막 날이나 이틀을 치웠기 때문에 지금은 길이가 더 견딜 만하지만 12월부터는 꽤 많은 카테고리를 처리해야 한다.나는 범주 이름들의 페이지를 옮기는 것을 돕기 위해 내 봇을 사용해 왔다.RedWolf *** 23:46, 2005년 1월 15일(UTC)

3RR 위반 처리

만약 누군가가 #사건에 보고된 3RR 위반을 처리한다면, 그들이 그렇게 했다는 것을 알려주기 위해 우리에게 짧은 편지를 보내줄 수 있는지 요청해도 될까?그렇게 하면, 다른 사람들은 이 사건이 이미 처리되었다는 것을 알아내기 위해서만 이 사건을 보는 데 시간을 쓸 필요가 없을 것이다.고마워!노엘(토크) 14:19, 2005년 1월 9일(UTC)

주목해야 할 주요 사진 후보

피처링된 사진 후보자들은 후보작을 검토하고 홍보 및 아카이빙을 하기 위한 프로세스에 익숙한 사람이 필요하다.그들 중 몇몇은 승진을 오랫동안 못 했다.Mgm *** 10:20, 2005년 1월 13일(UTC)

이제 우리가 따라잡은 것 같아.행정관은 필요 없고, 기꺼이 도와줄 편집자 몇 명만 더 있으면 된다.지시사항은 페이지 하단에 있다.User:Solutity는 이 일을 꽤 많이 하곤 했지만 크리스마스 직전에 위키브레이크를 했고 User:Ed g2s도 며칠 동안 자리를 비웠다.홍보도 하고, 오늘의 사진 템플릿도 관리하면서 그냥 떠나버렸어.위키피디아가 기어가면서 목요일에 3장의 사진을 홍보하는데 거의 3시간이 걸렸다. -- 솔립시스트 11:32, 2005년 1월 15일 (UTC)

위키백과:소개

이것은 도입부 2를 시험 편집의 의도된 장소로 대체하였으므로, 비록 처음 두 줄이 온전한지 확인하기 위해 이따금씩 점검하는 것이 좋을 수도 있지만, 그것이 불경스럽거나 불쾌하지 않다면 명백한 헛소리를 되돌릴 필요가 없다.

{{이 선은 그대로 두십시오}<!-- 이 선 아래의 텍스트를 자유롭게 변경하십시오.불경스러운 짓은 하지 말아 주시오. -->

정말 고마워!Rdsmith4—Dan Talk 03:32, 2005년 1월 21일(UTC)

위키백과에 추가:청소부.노엘 (토크) 22:27, 2005년 2월 5일 (UTC)

NowCommons를 비워야 함

NowCommons 범주는 커먼즈 버전으로 이동되어 커먼즈 버전을 사용하기 전에 삭제해야 하는 많은 이미지를 가지고 있다.NowCommons를 사용하는 것이 Category에 이러한 모든 이미지를 나열하는 것보다 IMHO를 사용하는 것이 더 낫다.빠른 삭제 대상자.BreakedSegue 17:15, 2005년 1월 23일 (UTC)

동의해. 알았어. - UthherSRG *** 17:29, 2005년 1월 23일(UTC)

잘했어.BreakedSegue 18:51, 2005년 1월 23일 (UTC)

깨진 이미지들을 보라고 했어야 했는데.BreakedSegue 03:56, 2005년 1월 24일 (UTC)

고마워.... - UthherSRG *** 04:18, 2005년 1월 24일(UTC)

위키백과에 추가:청소부.노엘 (토크) 22:18, 2005년 2월 5일 (UTC)

MVP

예, 위키백과 WP:MVP(Most Bandalized Pages) 또는 가장 파괴된 페이지.이 페이지는 분명히 구식이고, 얼마나 많은 관리자가 이 페이지를 체크하고 있는지 모르겠다.모든 사람들이 자주 파손되는 페이지를 보고 이 공유 감시 목록을 확인한다면 좋을 것이다. -- AlliUnion (대화) 09:19, 2005년 1월 28일 (UTC)

일반

이중 차단

이미 차단된 IP를 차단하지 않으려면 어떻게 하시겠습니까?로그 확인이나 뭐 그런 거야?누군가의 사용자 페이지에 차단된 노트가 있으면 보고 싶어서 굳이 확인 안 해도 된다는 걸 알아.Mgm *** 11:52, 2004년 12월 10일(UTC)

좋은 질문입니다.평소 IP 차단 리스트를 확인하는데, 그게 좀 번거롭다.IP/사용자가 이미 차단되었다는 경고 + 확인은 상당히 도움이 될 것이다. - Ta bu si da yu 12:39, 2004년 12월 10일(UTC)

나는 IP의 토크 페이지에 글을 남겨 후속 관리자들이 시간을 낭비하지 않도록 한다.그래도 모두가 그렇게 하는 것은 아니기 때문에 차단하기 전에 IP 차단 리스트를 확인하는 방법밖에 없다.SWAdair Talk 03:45, 2004년 12월 12일 (UTC)

아마도 MediaWiki의 새로운 기능은 차단된 사용자들을 위한 자동 기호가 될 것이다.그것은 최근의 변화에서 이름/IP 옆에 나타날 수 있고, 기사의 일부가 아닌 사용자/대화 페이지에 (따라서 분리할 수 없는) 기호가 있을 수 있다.바이올렛/리거 (t) 17:20, 2004년 12월 13일 (UTC)

나는 그러한 특징을 매우 원한다.그것은 반달 사냥꾼들을 그렇게 많은 시간을 절약한다.Mgm *** 09:17, 2004년 12월 14일(UTC)

그것도 좋은 기능이지만, 현재로선 이중 차단에 대한 걱정은 하지 않는다.그들은 이유가 있어서 차단되었다.개혁적인 반달 사건은 몇 건인가? --골베즈 *** 10:17, 2004년 12월 27일 (UTC)

IP 주소 및 양말 인형

CWS, Netoholic, Viriditas, TBSDY(나 자신)는 모두 IP 주소 문제에 대한 전체 삭스푸펫에 대해 논의해왔다.개인적으로, 나는 사용자들이 24시간 동안 차단된 아논들의 의심스러운 기사들을 수정하는 것을 알아챘다.사용자의 과거 IP 주소를 확인하고 사용자와 일치시키는 어떤 종류의 검증이 도움이 될 수 있다.여기서 자동 차단이 유용하다는 점을 제외하면... - Ta bu si da yu 23:04, 2004년 12월 10일(UTC)

누군가에게 물어보려고 했는데, 아마 아실 겁니다: 관리자가 비 애논 사용자의 마지막 활성 IP를 볼 수 있는 방법이 없을까?감사합니다, 2004년 12월 9일 클록워크소울 2004년 12월 9일 (UTC)

아니, 시스템 관리자(Tim Starling이 떠오른다)만이 그것을 알아낼 수 있다. -- Netoholic @ 00:38, 2004년 12월 10일 (UTC)

아, 좋아요.고마워. -- ClockworkSoul 22:17, 2004년 12월 10일 (UTC)

CWS, 왜 알아야 해? - 타부시 다 유 02:25, 2004년 12월 10일 (UTC)

최근 발생한 삭스퍼티 고발 사건을 읽고 최근의 반달들이 사용자명을 회전시키는 것을 보면서, 내가 보기에 IP주소를 상호 참조하는 능력은 이전 무자를 렌더링하고, 후자는 좀 더 쉽게 처리할 수 있을 것 같았다. -- ClockworkSoul 22:17, 2004년 12월 10일 (UTC)

그것에 대해서 한번 말해 보세요비리다타스에게도 같은 말을 했다! - 타부시 다 유 22:21, 2004년 12월 10일 (UTC)

관리자가 작성자 외에 편집의 원본 IP 주소를 볼 수 있는 기능을 갖출 것을 제안하는 것이 가치가 있다고 생각하십니까?특히 관리자만 볼 수 있다면 보안상의 중대한 문제는 생각할 수 없다. -- 클록워크소울 22:25, 2004년 12월 10일 (UTC)

당연하지!그렇게 하면 많은 양말-양말-양말-양말-양말-유 22:26, 2004년 12월 10일(UTC)

설문조사를 작성하시겠습니까, 아니면 작성하시겠습니까? :) -- 클록워크소울 22:30, 2004년 12월 10일 (UTC)

불행히도, 그러한 제안은 현재 해당 사용자가 보안 브라우저(자바 비활성화)에서 편집하고 애논 프록시를 사용하는 경우 어떤 양말 퍼펫 문제도 해결하지 못할 것이다.IIRC(그리고 내가 착각할 수도 있음), 이 문제를 해결할 수 있는 유일한 방법은 프록시를 여는 것을 금지하는 것이다.많은 IRC 서버가 이 솔루션을 구현해 왔지만 프록시 종류에 따라 여러 가지 방법이 있다고 본다. --Viriditas 22:56, 2004년 12월 10일 (UTC)

아니, 양말 퍼즐을 완전히 없앨 수는 없지만, 어느 정도 줄일 수 있을 것이고, 우리 반달 사냥꾼들의 삶을 어느 정도 편하게 만들 수 있을 것이다.소프트웨어가 그러한 변화를 거의 대부분의 노력으로 지원할 수 있다는 것도 보너스다.나는 당신의 제안인 Viriditas가 훨씬 더 멀리 갈 것이라는 것에 동의하지만, 또한 더 큰 사업이다. -- ClockworkSoul 23:15, 2004년 12월 10일 (UTC)

• 만약 무료 우편 서비스를 받는 사람들이 등록하기 위해 관리자에게 연락해야 한다면, 그들은 우리가 귀중한 편집자들을 잃게 만드는 노력을 하지 않을 것이다.나는 더 나은 반달 및 문제 사용자 로깅을 보고 싶다. 반달 사냥꾼들이 IP나 사용자의 과거를 쉽게 확인할 수 있도록 그들의 사용자 페이지에 추가될 수도 있다.의무 가입은 문제가 되지 않는다, 우리가 검증을 꼭 하지 않는 한.Mgm *** 14:44, 2004년 12월 11일(UTC)

질문:IP 주소를 통해 사용자를 감시해야 하는 이유는 무엇인가?기고문은 누가 썼는지 판단하지 말고 자신이 어떤 사람인지 판단해야 한다.양말 인형들은 짜증나지만, 위키피디아를 대대적으로 변경하지 않고는 할 수 있는 일이 없다(예: 계정을 만들기 전에 신원 증명서를 요구하고, 아논을 차단하는 것).(사용자) 인기 없을 것이다.나는 빅 브라더 타입의 활동에 반대한다.만약 누군가의 기여가 너무 일방적이어서 그가 명백한 양말 인형이라면, 그것들을 추정된 신원보다는 POV 근거에서 삭제/데모하라.EventHorizon 05:57, 2004년 12월 12일(UTC)

음...평소 같으면 이번 건에 대해 너와 동의했을 거야.하지만 최근에 우리는 3RR 위반으로 차단을 하고 있다.우리가 차단한 기사에서 비슷한 편집이 많이 나왔고, 많은 관리자들이 가장 먼저 생각하는 것은 그러한 편집이 차단된 편집자로부터 나온다는 겁니다.그래서 우리가 편집자들이 사용하는 IP 주소를 볼 수 있다면 많은 문제가 해결될 것이다.잘 들어, 내가 알고 있는 바로는 자동 잠금이 자동으로 IP 주소를 차단하기 때문에 좀 애매한 점이야.Tabu si da yu 20:39, 2004년 12월 12일 (UTC)

편집자 IP를 보는 것이 사소한 것처럼 보일 수 있지만(개발자 사람들이 할 수 있는 것을 고려하면), 편집자 IP를 보는 것이 관리자에 의해 남용되는 힘이 될까봐 두렵다.남들이 모르는 걸 아는 건 항상 좋은 일이야, 응?관리자가 3RR(정책 재해)과 관련해 차단 정책을 남용해 왔다는 점을 고려하면, 그들에게 더 많은 '책임감'을 부여할 수 있는 좋은 생각은 아니다.저항하고 싶은 유혹이지양말 꼭두각시는 불법이 아니다.그들을 정책을 회피하기 위해 남용하는 것은 그렇다.

편집자 IP를 보는 관리자를 지원할 수 있는 유일한 방법은 3개의 레이(비관리자) 편집자가 사전에 그 행동 방침을 승인하는 것이다.언급했듯이, 관리자는 더 많은 책임을 지지만, 권위는 위키백과 커뮤니티에 있다.나는 관리자들을 믿지 않아, 미안해.

자동 잠금 장치를 고려하면 그것은 무트 포인트인 것 같다.쉽게 바꿀 수 있는 '불량 편집자' IP를 보면, 아주, 아주 조금이나마 해결할 수 있을 것이다.위키피디아는 편집자 IP를 볼 수 없는 관리자들로 인해 손상되지 않았다.Mrfixter 23:42, 2004년 12월 12일 (UTC)

좋아, 네 견해는 옳다.그러나 관리자가 3RR을 위반한 곳은 어디인가?또, 반복적인 위반 때문에 왜 우리가 차단해야 한다고 생각하십니까?중요한 것은 사람들이 그들의 변화에 대해 토론하는 것조차 귀찮게 하지 않고 되돌아가고 있다는 것이기 때문이다.그리고 우리가 그것 때문에 막으면 그들은 모두 열 받는다.글쎄, 난 터프하다고 해.만약 그들이 선의로 편집을 했다면, 그들은 그들의 의견을 받아들여 일을 진행했을 것이다.그리고 그들은 합의를 얻으려고 노력했을 것이다.그들이 하는 방식으로 되돌리는 것은 괴롭힘이다. 간단하고 간단하다. 왜일까?왜냐하면 그들은 사람들에게 그들 자신의 POV를 부과하려고 하기 때문이다.치즈드림스를 예로 들어보자.그녀는 예수의 문화와 역사적 배경에 대한 적어도 세 가지 변화를 되돌렸고, 다른 편집자들과 함께 그 페이지를 보호하도록 강요했다.너는 그것이 공평하다고 생각하니?나는 모른다. - 타부시 다 유 08:31, 2004년 12월 14일 (UTC)

관리자가 3RR 차단 정책을 위반한 위치HistoryBuffers 4는 26시간 블록에서, Alberunis 4는 24시간 5분 만에, Nasrallahs 블록은 24시간 동안 두 번 리턴한 후, Sam Spades 블로킹으로 돌아간다.3RR 정책은 관리자가 서한에 따라야 한다.이제, 주제에서 벗어나지 않고, 나는 이 편집자들의 관행을 내가 시민적 행동을 고려하는 것과는 아주 동떨어진 것으로 특징지을 것이다.그러나 정책은 고르게 그리고 정당하게 적용되어야 하는데, 행정관들이 하지 못한 것이다.나는 그것을 인정하는 것이 급진적인 입장이라고 생각하지 않는다.

3RR 차단 정책은 또한 더 많은 삭푸펫과 아논 ip가 되돌아오는 것을 의미했고, 되돌리기 전쟁을 늦추었지만 끝내지 못했다.그것이 3RR 차단 정책의 요점이었습니까?위키피디아의 다른 것들과 마찬가지로, 장기적인 해결책은 위키피디아 커뮤니티 안에 있는 것이지, 관리자 권한의 확장에 있는 것이 아니다.

위키백과 커뮤니티는 3RR을 집행하는데 있어서 관리자들에게 재량권을 주지 않았다. 관리자가 그들의 의무에 대해 진지하다면, 3RR의 개별적인 해석이 아닌 3RR을 시행해야 한다.Mrfixter 17:29, 2004년 12월 15일 (UTC)

그래, 하지만 일부러 자신의 POV를 기사에 넣기 위해 길을 벗어나는 사용자들은 자신이 차단된 것을 발견할 수도 있어.그 사용자들은 착하게 행동하는 법을 배울 필요가 있다.내가 정규 편집자 차단을 좋아한다고 생각하십니까? - 타부시유 14:39, 2004년 12월 19일 (UTC)

실제로 관리자들은 재량권을 가지고 있고 그것을 공정하게 행사하도록 요청 받는다.그들은 로봇이 아니다.HistoryBuffer와 Alburuni의 경우는, 만약 당신이 묘사하는 대로라면, 학대였다.그들이 3RR의 문자에 집착했든 아니든 간에, 그들이 의도적으로 그것의 경계를 그렇게 노골적으로 시험했다면 말이다.어떤 편집자도 다른 편집자와의 의견 불일치에 대한 기사를 갑자기 한 번 이상 되돌릴 필요가 없으며, 우리는 항상 그렇게 하는 것이 적절한 곳을 되돌리는 대신 수정하는 선택권을 가진다.내 생각에 3RR은 터무니없이 관대해서 역전전쟁을 조장한다. --Tony Sidaway Talk 15:19, 2004년 12월 19일 (UTC)

편집은 누가 만들었느냐가 아니라 어떤 내용인지 판단해야 한다.그러나 투표의 개념, 그리고 3RR은 양말 퍼펫에 의해 훼손된다.예를 들어, 삭제 투표는 삭푸펫 공격의 정규 표적이다.RFA를 고려한다면, RFA는 프로젝트에 직접적인 위협이 된다.IP를 기록하는 것은 스파이 행위가 아니다.어서.당신이 방문하는 모든 웹사이트는 당신의 IP를 가지고 있고 그들은 그들이 좋아하는 것을 할 수 있다.WP 계정은 IP를 숨기기 위한 무료한 방법이지만, 본 서비스에 대한 사용자의 고유 권한은 보이지 않는다.dab (iii) 13:19, 2004년 12월 22일 (UTC)

기물을 식별하고 차단하는 전략

IP 번호를 양말 식별을 위해 해석하는 데는 신중함과 기술이 필요하다.나는 현재 내 ISP의 http 프록시에 합법적으로 적용된 IP 블록으로 인해 간헐적으로 고통을 받고 있다. 같은 프록시를 공유하는 반달 때문에 말이다.우리가 그것에 대해 할 수 있는 일은 별로 없다; 그것은 편집을 불가능하게 하지 않는다.

앞으로 나아가는 한 가지 방법은 로그인한 사용자만 편집을 허용하는 것일 수 있다.이것은 반달은 사용자 이름으로 차단될 수 있다는 것을 의미할 것이다.반달 시도는 반달리즘에 앞서 사용자 이름을 저장하고 필요할 경우 차단되지 않은 사용자 이름으로 전환함으로써 블록을 우회할 수 있다.그러나 이 전략은 각 사용자 이름이 등록되어 있는 IP 번호를 기록한 다음 금지된 사용자와 동일한 IP 번호를 사용하여 최근 편집을 수행하는 사용자의 자동 목록(일부 특수 페이지)을 올리는 방법으로 실패할 수 있다.이것은 더 많은 공공 기물 파손을 감시할 후보자들의 감시 목록을 제공할 것이다.

그것은 또한 내가 겪고 있는 것과 같은 조잡하고 종종 비효율적인 IP 번호 금지가 필요하지 않다는 것을 의미할 것이다. --Tony Sidaway Talk 14:56, 2004년 12월 11일 (UTC)

모든 애논을 금지하는 것은 반위키적이며, 솔직히 항상 등록하고 그 후에 로그인을 원하지 않는 편집자들에게 매우 화가 난다.그러나, 나는 관리자들이 IP를 보는 개발자 권한을 가져야 한다고 생각한다.Event Horizon이 말한 것과 달리, 이것은 "빅 브라더" 전술이 아니다 - 위키피디아는 정부나 공공장소가 아니다. 위키피디아는 지미 웨일즈와 재단이 운영하고 있다. 그리고 웹사이트의 소유주들은 방문자들의 IP를 어쨌든 볼 수 있다.위키피디아의 경우 개발자들도 이미 그런 힘을 갖고 있다.여기서 유일한 차이점은 그 지위를 임명된 관리자들에게 주는 것이다.안드레 (대화) *** 06:20, 2004년 12월 12일 (UTC)

고마워. 난 계정이 있지만 위키피디아에서 쿠키를 받아 자동으로 로그인하도록 내 기본 설정을 해.내가 사용하는 웹 프록시를 다른 사람이 사용했기 때문에 위키피디아에서 가끔 문을 잠그는 것을 발견하지 못했다면 위키피디아에 호소하지 않을 수 있는 정책을 받아들일 것이다. --Tony Sidaway Talk 21:14, 2004년 12월 12일(UTC)

• 나는 이것에 대해 한동안 생각해 보았지만, 개인적으로 나는 모든 사람들의 IP를 (관리자들에게도) 게시하는 것이 좋지 않은 생각이라고 생각한다.나는 대신에 각 편집자의 IP 전체와 IP의 처음 20비트의 해시를 발행할 것을 제안한다.브루트 포스를 방지하려면, 그것은 어떤 비밀키와 연결된 값들의 해시여야 할 것이다.그래야 두 명의 사용자가 동일한 IP를 사용하고 있는지, 동일한 ISP를 사용하고 있는지를 누구나 확인할 수 있지만, 아무도 자신의 실제 IP를 검색할 수 없고, 그들의 ISP는 동일한 ISP를 사용하는 누군가에 의해서만 공개될 수 있다.내게는 합리적인 타협인 것 같은데, 유일한 단점은 IP를 그 IP로 명명된 사용자와 구별할 수 없다는 것이다.이 문제는 User를 사용하지 않음으로써 해결할 수 있다.IP 이름을 더 이상 지정하지만 사용자:<아이피의 해시>; 그렇게 되면 애논의 주소를 볼 수 있는 능력이 없어지겠지만, 나는 그렇게 하고 싶지 않다. --fvw* 2005년 1월 5일(UTC) 19시 15분

좋은 생각이야, 비록 이것이 실행되려면 시간이 좀 걸릴 것이라고 생각하지만?dab (dab) 20:01, 2005년 1월 5일 (UTC)

나는 그것이 받아들여지는 것과 실제로 일어나는 것 사이의 더 큰 부분은 미디어위키의 다음 업데이트가 엔위키에 설치되기를 기다리는 것이라고 생각한다.이건 내 코드의 또 다른 개념이야. 사실, 해프닝의 어떤 시간-순순-난 미디어위키와 함께 하고 싶어. 유일한 것은 그것이 실제로 앞에서 사용될 수 있도록 확실히 하고 싶어.이것은 정책 투표 같은 것이 필요할까 아니면 그냥 몰래 코드화되어야 할까? 그리고 디벨들이 그것을 켜기 위해 뇌물을 받아야 할까? --fvw* 20:06, 2005년 1월 5일 (UTC)

관리자가 데이터포인트 LiveJournal로 볼 수 있는 모든 편집에 대한 IP 주소의 재승인 및 해당 복제본은 모두 게시물에 코멘터의 IP 주소를 표시할 수 있으며, 해당 커뮤니티의 원래 포스터나 유지관리자가 볼 수 있으며, 이에 대한 불만 사항(NTSIDEOC)버드나무 15:08, 2005년 1월 7일 (UTC)

사용자 이름 변경

한 명 이상의 관리자가 위키피디아를 볼 수 있는가?사용자 이름 변경.내가 보기엔 10월 14일 이후로 어떤 요청도 이루어지지 않아서 밀린 일이 꽤 있어.고마워. jugu 13:26, 2004년 12월 11일 (UTC)

불행히도 당신은 그것을 하기 위해 개발자가 필요하다.안드레 (대화) *** 19:45, 2004년 12월 11일 (UTC)

하나 또는 그 이상을 어떻게 손에 넣을 수 있을까?jugu 20:13, 2004년 12월 11일 (UTC)

m:개발자는 리스트를 가지고 있지만, 공정한 경고: 그들은 과로하고 있고, 사용자 이름을 바꾸는 것과 같은 잡일은 미디어위키에서 일하는 것에 비해 우선순위가 낮다.이소모르픽 20:59, 2004년 12월 11일 (UTC)

Wiktionary 링크

안녕, 모두 위키피디아에 제안서(및 템플릿)가 있어:Wiktionary에 연결되어야 하는 페이지를 처리하기 위한 소프트 리디렉션.내가 보기엔 좋아 보이는 이것을 사용하기 시작하고 싶지만, 아직 그것이 정말로 공식적인지는 확실하지 않다. 우리가 공식적인 것을 만들 수 있도록 거기서 더 많은 코멘트를 받을 수 있을까?(이미 그런 내용이라면 사과드리며, 나는 그저 막막하기만 했다. 페이지는 그렇게 들리지 않았고, 나는 아주 최근까지 그것에 대해 들어본 적이 없었다.)노엘 (토크) 17:45, 2004년 12월 13일 (UTC)

나는 이것이 백과사전적 가능성이 없는 주제에 대한 좋은 정책이라고 생각한다. -- Jmabel Talk *** 23:00, 2004년 12월 13일 (UTC)

3회 되돌리기 규칙

최근의 변화에 대한 공감대를 빠르게 얻을 수 있는 가장 좋은 방법일 것 같아 이 자리에서 묻는다.최근에 세 가지 되돌리기 규칙이 시행 가능하게 되었다.이제 단순 되돌리기의 경우는 쉽게 식별할 수 있으며 "반복"이라고 불리는 대부분의 편집이 이 범주에 속한다. 페이지나 섹션의 두 가지 다른 버전의 텍스트 간의 차이점은 모든 중간 변경사항이 되돌아가면서 그것들이 동일하다는 것을 보여준다.

더 최근에 나는 사용자들이 다른 사용자들의 추가된 텍스트를 선택적으로 삭제하는 것을 보았다.이것은 두 버전 사이의 차이가 동일하지 않기 때문에 인식하기가 조금 더 어렵다.그러나 나타나는 것은 두 가지 버전을 비교할 경우 중간 변경사항에서 추가된 텍스트를 선택적으로 삭제한다는 것이다.예를 들어, 첫 번째 사용자는 단어의 철자를 수정하면서 외관 편집을 했고, 두 번째 사용자는 텍스트가 추가된 보다 실질적인 편집을 했다.그리고 나서 세 번째 사용자가 와서 첫 번째 사용자의 외관 편집을 유지하면서 두 번째 사용자의 추가 텍스트를 모두 삭제하는 편집을 수행했고, 섹션 제목을 수정하기도 했다.그 효과는 두 번째 사용자의 추가된 텍스트를 제거하는 것이었다.

이는 세 번째 사용자가 같은 페이지에서 두 번 반전을 수행하기 직전이었고, 세 번째 편집은 세 번 되돌리기 규칙을 회피하려는 시도로 볼 수 있었기 때문에 문제가 된다.

나는 그 문제를 터놓고 싶다.이런 종류의 편집은 기존 정책이나 관행으로 적용되는가?이 경우 세 번째 되돌리기 자격이 있는가? --Tony Sidaway Talk 02:41, 2004년 12월 14일(UTC)

내 의견은 사소한 변화(예: 철자 변경과 자본화)를 포함하는 되돌리는 것은 여전히 되돌리는 것이라고 생각한다.3RR의 목적은 역전 전쟁을 막기 위한 것이며, 분명한 철자 변경은 대부분의 그러한 전쟁에 큰 영향을 미치지 않는다.나는 경고가 첫 번째 위반에 대한 충분한 거절이라고 생각한다.-gadfium (대화) 03:08, 2004년 12월 14일 (UTC)

나는 이 의견에 동의한다. - 타부시 다 유 08:32, 2004년 12월 14일 (UTC)

나도 그래. 기계보다 사람들이 결정하게 하는 이점은 우리가 시스템을 작동시키려는 시도를 통해 볼 수 있다는 거야.테레사 노트 (The snott racke) 09:01, 2004년 12월 14일 (UTC)

동의함. Mgm *** 11:36, 2004년 12월 14일(UTC)

위키백과에서 논의한 내용에서 분명히 알 수 있다고 생각했다.다른 변경을 하는 3회 되돌리기 규칙 시행은 3회 되돌리기 규칙의 목적에 반영되어야 한다.예를 들어, 그 페이지에서 내 표를 보십시오.역전과 혼재된 다른 변화가 큰지 작은지는 중요하지 않다. 그것은 여전히 역행이다.그러나 나는 위키피디아 토크에서 다시 확인했다.3회 되돌리기 규칙 시행#3RR과 위키백과의 정신 대 편지:세 번의 되돌리기 규칙 시행#믹싱은 되돌아가고 의미심장한 편집으로, 일은 내가 기억했던 것만큼 더 이상 분명해 보이지 않는다.나는 3RR에 대한 설명을 지지한다. 다른 변화와 혼합된 되돌리는 것은 여전히 되돌리는 것이라고 말한다.—AlanBarrett 17:39, 2004년 12월 15일(UTC)

나는 변화와 혼합된 되돌리는 것은 여전히 되돌리는 것이라고 생각한다; 만약 누군가가 관련 없는 변경을 하고 싶다면, 그들은 확실히 별도의 편집으로 그렇게 할 수 있다.그리고 실제로, 만약 누군가가 되돌리기 변경을 하고, 그 다음에 관련이 없는 다른 변경을 한다면, 그들은 분명히 3RR 아래에서 차단될 것이다.내가 본 대부분의 관리자들은 리턴+에디트를 리턴으로 해석해 왔다.Jayjg 20:33, 2004년 12월 15일 (UTC)

나는 여기서 핵심 단어는 "관련되지 않은" 변화라고 생각한다. 왜냐하면 그것들은 단지 외적인 것이고 규칙에서 벗어나려는 시도일 뿐이다.논쟁의 여지가 있는 텍스트와 관련되는 문제 및 논제에 적절한지 여부에 관계없이 실질적이고/또는 대응적인 변화는 되돌리기로 간주되지 않아야 한다.나는 또한, 단지 삭제만 하면 더 비판적으로 처리될 것을 제안한다. 왜냐하면 추가가 공공 기물 파손이 아니라면, 그 가정은 선의의 기여여야 하기 때문이다.--Silverback 04:43, 2005년 1월 3일 (UTC)

나는 강하게 반대한다.사용자들은 이전에도 이러한 정확한 구실을 사용하여 규칙을 살펴본 적이 있다; 네 번째 되돌릴 때는 다른 섹션을 상당히 수정하면서 논쟁의 여지가 있는 단락을 다시 삽입한다.만약 그들이 선의로 다른 부분들에 대한 실질적인 편집을 원한다면, 그들은 확실히 그것들을 별도의 편집으로 만들 수 있다.논쟁의 여지가 있는 텍스트를 다른 주요 편집과 함께 다시 삽입하는 것은 불신이다.Jayjg (토크) 04:56, 2005년 1월 3일 (UTC)

내가 염두에 두고 있는 경우처럼 관계되고 실질적인 변화라면, 다른 전공자가 삽입과 별도로 편집하게 하는 것은 이치에 맞지 않을 것이다, 그들은 어떻게든 서로를 지지하거나, 진술된 이의에 반응하는 연계를 할 것이다, 악의의 반대였다.--은백 05:08, 2005년 1월 3일 (UTC)

내가 보기에 "역전+수정"을 역전이라고 생각하지 않는다면, 3RR로 계산하는 것이 낫다는 것은 명백하다. 그렇지 않으면 모든 사람들이 역전을 할 때마다 편집을 할 것이고, 따라서 3RR을 유발하는 것을 피할 것이기 때문이다.노엘 (대화) 04:23, 2005년 1월 1일 (UTC)

나는 위키백과에서 (역전+편집이 역전으로 간주되지 않는 한, 3RR은 죽은 편지라는) 이 문제를 제기했다.3가지 되돌리기 규칙#Edits와 역전; 논평은 환영할 것이다.노엘 (토크) 23:17, 2005년 1월 1일 (UTC)

그것은 판단력이 필요하다.실질적이고/또는 응답성이 높은 변경사항(요약 편집 또는 대화 페이지 포인트에 응답)제기된 문제를 해결하는 위키링크를 추가하는 것과 같은 사소한 변경은 실질적이고 대응적일 수 있다.--Silverback 04:43, 2005년 1월 3일(UTC)

내가 본 대부분의 경우, 그것은 단지 3RR을 둘러보려는 시도일 뿐이다.어떤 경우에는 그렇지 않을 수도 있다고 생각하는데, 물론 관리자는 모든 상황에서 항상 좋은 판단을 하려고 노력해야 한다.Jayjg (토크) 04:56, 2005년 1월 3일 (UTC)

리디렉션 프로젝트 누락

Nickj는 이 툴을 사용해 본 적이 없는 사람들을 위해 데이터베이스를 가로질러 실행되고 파이핑된 링크에서 정보를 수집하여 추가 리디렉션을 제안한다. (이 프로젝트에 대한 자세한 내용은 여기에서 사전 논의를 참조하십시오.)

그것은 긴 건의 목록을 만들었다.가짜 링크를 만들지 않기 위해 이 프로세스는 인간 매개물이다.닉이 설정해 놓았으니 한 개씩 두 번 클릭만 하면 돼. 그래서 아무 일도 없어.좋은 링크라고 생각되면 그냥 앉아서 클릭해.리스트는 5가지 제안의 블록으로 나눠져 있어 압도적이지 않고, 사람들이 원하는 만큼 또는 적게 할 수 있도록 한다.이제 우리는 도우미가 필요하다.이 프로젝트를 홍보하기에 가장 좋은 장소는 어디인가?노엘 (토크) 13:33, 2004년 12월 14일 (UTC)

내게는 RC의 커뮤니티 포털이나 노트가 시작하기에 좋은 장소처럼 보인다.Mgm *** 13:56, 2004년 12월 14일(UTC)

질문sql

스페셜에 무슨 일이 일어났는지 아는 사람 있어?질문sql? 전에는 db 질의 양식이 있었지만 지금은 "No such special page that special page"가...dab (tab) 08:34, 2004년 12월 16일 (UTC)

데이터베이스 속도를 높이기 위해 일시적으로 잠근 것 같은데, 내가 틀릴 수도 있어.Mgm *** 08:55, 2004년 12월 16일(UTC)

어차피 한 번도 안 썼으니까 틀릴 수도 있지만, 아주 오랫동안 '임시' 잠겨 있었던 것 같다.난 네 숨을 참을 수 없어.이소모르픽 21:05, 2004년 12월 16일 (UTC)

다시는 돌아오지 않을 것 같다.한 번의 서투른 질의는 사이트 전체를 무릎 꿇게 할 수 있다. -- 키리우스 ✎ 01:44, 2004년 12월 18일 (UTC)

일시적이 아니라 무한정 사라졌어.내가 가지고 있는 문제는 성능이 아니라(우리는 항상 작은 슬레이브 서버에서 실행할 수 있다) 적절한 권한을 설정하기 위해 수천 개의 그랜트 문장이 필요하다는 사실이다. -- Tim Starling *** 10:16, 2004년 12월 19일(UTC)

불쌍해. 어쨌든 난해하긴 했지만.권한 명령은 perlscript에 의해 생성될 수 있다고 가정한다.그리고 내 말이 맞다면, 30년대 쿼리의 시간 초과가 있어서, 시스템이 가장 멍청한 명령에서도 다운되지 않을까? 하지만 괜찮아, 나는 그것을 내가 직접 사용해 본 적이 거의 없고, 좋다면, 그리고 어떤 식으로든 필수적이지 않아. dab (1904) 10:32, 2004년 12월 19일 (UTC)

삭제 취소 도움말

나는 AMOK를 없애려고 노력했어! 남아프리카 공화국을 없애려고 했지만, 지금은 페이지 역사에 접근할 수 없어.누가 가장 좋은 행동에 대해 조언을 해줄 수 있는가? - Ta bu si da u 08:41, 2004년 12월 19일 (UTC)

그것은 지금 거기에 있는 것 같다.페이지 기록:

* (cur) (last)  08:45, 19 Dec 2004 Ta bu shi da yu     * (cur) (last) 08:44, 19 Dec 2004 Ta bu shi da yu (blanking copyvio)     * (cur) (last) 09:02, 5 Dec 2004 Vague Rant m (Update link.)     * (cur) (last) 01:47, 5 Dec 2004 Vague Rant (Copyvio.)     * (cur) (last) 02:18, 29 Nov 2004 168.209.97.34 (Weblinks)     * (cur) (last) 02:17, 29 Nov 2004.209.97.34 (AMOK! 남아공) * (커브) * (커브) 16:08, 2004년 11월 27일 (커브) * (커브) 15:53, 2004년 11월 27일 머드탕 m (머드탕으로 2004년 11월 27일 생성)

HTH. -- ALoan (Talk) 08:53, 2004년 12월 19일 (UTC)

언슬렛은 때때로 그들이 나타나기 전에 약간의 시간이 걸린다.쿨 핸드 루크 10:25, 2004년 12월 19일(UTC)

FWIW, 나는 그 직후에 내가 편집을 하면 모든 것이 다시 돌아온다는 것을 알았다 :) 상황을 바로잡는 것 같다. - 타부시유 14:33, 2004년 12월 19일 (UTC)

기억나는 또 다른 가능성은 당신의 브라우저가 삭제되지 않은 이전부터 캐시된 버전의 히스토리 페이지를 가지고 있었고 그것은 당신에게 업데이트된 버전을 검색하는 것이 아니라 그것을 보여주고 있었다.예전에 삭제 관련 일을 하면서 그런 일이 있었는데, 그것을 옮기려다 돌이킬 수 없을 정도로 카시니-휘겐스 탐사선 기사를 잃어버릴 것 같아서 깜짝 놀랐다.많은 브라우저에서 페이지 다시 로드 버튼을 클릭하면서 Shift 키(또는 제어 키 Pedant)를 누르고 있으면 캐시가 바이패스되므로 이 문제가 다시 발생할 경우 문제를 해결할 수 있다.브라이언 19:18, 2004년 12월 19일 (UTC)

아니, 조언은 고맙지만 위키피디아는 분명히 "데이터베이스에서 찾을 수 없는 역사" 오류를 제기했다. - Tabu si da yu 19:53, 2004년 12월 19일 (UTC)

하위 페이지 나열

안녕, 주어진 페이지의 하위 페이지(즉, 주어진/보고 나면 목록을 제공하는 명령이나 페이지)를 나열하는 방법을 누구라도 나에게 알려줄 수 있니?위키피디아에서 찾아봤는데:하위 페이지 및 메타:링크#Subpage_feature, 그러나 둘 다 이것을 어떻게 해야 하는지에 대해 아무 말도 않는다.하위 페이지에는 항상 부모에 대한 링크가 포함되어 있다. 다른 방향에서 문제가 되는 것이 있는가?답변에 대해 미리 감사한다(있는 경우 :-).노엘 (토크) 18:23, 2004년 12월 19일 (UTC)

"여기 어떤 링크"를 불러오면 그 안에서 검색을 할 수 있을 겁니다. -- Jmabel Talk *** 00:14, 2004년 12월 20일 (UTC)

아니, 부모에게 돌아가는 링크는 "여기에 있는 링크"에 포함되지 않아노엘 (토크) 00:42, 2004년 12월 20일 (UTC)

한 가지 방법은 위키피디아에서 페이지를 검색하는 것이다. 예를 들어, 이 검색은 "제목 일치사항"에 있는 내 사용자 페이지의 하위 페이지 일부를 불러오는 것이다.— Matt Crypto 00:53, 2004년 12월 20일 (UTC)

Matt의 구체적인 예에서 알 수 있듯이, 그것은 당신이 추적하지 못한 당신의 하위 페이지를 찾는 문제라면, 그리고 만약 당신이 그것들을 만들기 시작한 이후로 항상 이 페이지를 계속 체크한다면, 전체 목록은 Us of the 알파벳 아래에 깔끔하게 그룹화된 당신의 M 감시 목록 유지 관리 페이지에 나타날 것이다.빨간색 링크는 삭제를 반영하지 않고 오히려 사용자 대화: (하위) 사용자: (하위) 페이지 - 일반적으로 사용자의 대화 아카이브. --Jerzy(t) 21:28, 2004년 12월 20일 (UTC)

규칙 되돌리기 3가지 위반을 보고할 위치

다른 쪽에서는 3RR 위반을 보고할 수 있는 구체적인 장소가 필요하다(예를 들어, 개별 sysops가 많은 토크 페이지에는 없다).특정 페이지(Wikipedia:과도한 역전 진행 중?위키백과:3RR 위반?) 그러면 사람들은 (빠르게) 어떤 사용자가 3RR을 위반했는지 또는 위반하지 않았는지에 대해 논의할 수 있다.파카란 (팬을 ark a pan) 20:45, 2004년 12월 23일 (UTC)

규칙 위반을 3번 되돌리도록 관리자에게 알리는 가장 좋은 방법은?이제 차단이 정책인 만큼 관리자들이 대처할 수 있도록 이들을 이곳으로 데려와야 하는가?Jayjg 01:14, 2004년 12월 24일 (UTC)

그런 것 같아요.범죄자들은 종종 반대편인 체리픽스가 그들의 대의에 동조한다고 느낀다.위반은 일반적으로 어떤 관리자라도 위반 당사자를 차단할 수 있어야 할 정도로 명백하며, 이를 여기에 게시하면 사용자 페이지에 확대되지 않고 모든 되돌리기-카운트 분쟁을 한 곳에서 통합할 수 있다.쿨 핸드 루크 01:28, 2004년 12월 24일 (UTC)

지금은 괜찮을 것 같아.여기서 너무 많은 트래픽이 발생한다면, 우리는 그것을 다른 페이지로 옮길 수 있어.노엘 (토크) 07:18, 2004년 12월 24일 (UTC)

여기가 지금 3RR 위반을 신고하는 곳인가?나는 그것을 위한 적절한 장소를 찾으려고 노력했다(내가 관여하고 있는 분쟁으로 누군가를 막고 싶지 않다.나는 결국 WP에 다음과 같은 메모를 남겼다.RFP(거기 참조).dab (dab) 2004년 12월 26일 12:25(UTC)

나는 그렇게 믿는다; 이곳은 더 적절한 IMO 같아 보인다. Johnleemk Talk 14:19, 2004년 12월 26일 (UTC)

WP:RFP는 아마도 몇 가지 이유로 좋은 장소는 아닐 것이다.첫째, 사용자가 3RR을 위반할 경우 이를 일시적으로 차단하는 것이 해결책이다(반복된 위반 사항은 ArbComm으로 가져가야 하며, 이를 금지할 수 있다).둘째로, 내 감각은 많은 정당들 사이에 정말 열띤 편집 전쟁이 일어나지 않는 한 편집 전쟁 때문에 페이지를 보호하지 않는 것이 정책이었고, 두 사람이 싸우는 것은 그 기준에 맞지 않는다(그리고 첫 번째 요점을 본다).노엘(토크) 18:06, 2004년 12월 26일 (UTC)

아니, 네 말이 맞아.나는 사람들이 그러한 블록을 요청할 수 있는 특별한 페이지가 필요할 것이라고 생각한다(이 페이지는 명백한 선택으로 보이지 않는다) dab 21:19, 2004년 12월 26일 (UTC)

사용자:Charm's point in WT:AN#사람들이 이것이 유용하다고 생각하는가?(또한 이 페이지의 머리글에 최근 추가된 결과), 이것은 합리적인 제안으로 들린다.3RR 위반 보고서의 위치를 제안하십시오!노엘(토크) 16:13, 2004년 12월 27일 (UTC)

나는 위키피디아에 다음과 같은 메모를 추가했다.여기서 위반 사항을 보고해야 한다는 3반전 규칙.—AlanBarrett 17:00, 2005년 1월 8일(UTC)

나는 위반자를 신고하는 데 사용되는 Project Page를 제안했다.그 생각은 2분도 안 되어 토론 없이 되돌아갔다.3회귀 페이지 토크페이지에 나의 생각 2005년 2월 2일 후스녹

TBSDY는 대담했다 - 아래를 보라.노엘 (토크) 07:36, 2005년 2월 2일 (UTC)

삭제되지 않는 새로운 기능

여러 곳에 교차 포스팅되어.
Sysops는 이제 페이지의 선택된 수정사항만 삭제할 수 있는 능력을 가지고 있다.위키피디아의 설명을 읽어 보십시오.sysops별로 삭제된 페이지를 보고 복원한 후 Wikipedia Talk에 대한 토론에 참여:삭제 취소 정책.감사합니다.—Charles P. 13:44, 2004년 12월 24일 (UTC)

특수 페이지

Special과 같은 특별한 페이지를 얻을 수 있는 방법은 없을까?내 감시 목록에 기록/차단하시겠습니까?위키백과라고 불리던 시절:블록 로그, 내 감시 목록에서 업데이트를 볼 수 있는 것이 유용하다는 것을 알았다.가말리엘 21:12, 2004년 12월 24일 (UTC)

불행히도 그렇지 않다.나도 그게 그립다.BLACKFAZE (чоо??) 21:26, 2004년 12월 24일 (UTC)

작동하는지 알아보려고 해본 적은 없지만 Special에 링크를 걸어보십시오.사용자 페이지의 하위 페이지에 기록/차단(및 계속 주시하고 싶은 유사한 사항)한 다음, 거기에 가서 "관련 변경사항"을 누르고 그것이 효과가 있는지 확인하십시오. (그것이 감시목록, IIRC...) 노엘 (대화) 12:43, 2004년 12월 25일 (UTC)

프록시 목록

뭔가 헷갈리는 게 있어.우리는 현재 닐사와 같은 사람들에 의해 사용되고 있는 모든 열린 프록시를 차단해야 하는가?나는 http://www.q-cat.com/goodproxies.txt에서 업데이트된 목록을 찾았지만, 우리가 실제로 그렇게 해야 하는지를 알아내기 전까지는 이 목록을 차단하기 시작하고 싶지 않다.분명 몇몇 중국 사용자들은 이 IP 주소를 사용한다. - Ta bu si da yu 23:04, 2004년 12월 29일 (UTC)

나의 우려는 WP에 도착하기 위해 이것들을 사용하는 중국 사용자들이 잠재적으로 험난한 상황에 처할 수 있다는 것이다(그렇게 함으로써든, 아니면 WP에서 불쾌하게 여겨질 수 있는 말을 하든지).물론, 그것은 그들의 선택이다.우리가 가장 좋아하는 심령술사, 그리고 친구들이 능동적으로 대리인을 사용하고 있다면, 그들을 제거하기 위한 AOL 대리점에 따른 짧은 블록이 순서(또는 기다림과 롤백)라고 나는 생각한다.그냥 내 의견이야.파카란 (팬을 ark a pan) 04:42, 2005년 1월 1일 (UTC)

많은 사람들을 막아라.위키백과 참조:차단 정책#Anonymous_and_open_proxies. --fvw* 05:04, 2005년 1월 1일(UTC)

VfD에 대한 정책 결정

위키백과에서 결정되고 있는 몇 가지 정책을 모두에게 알리고 싶었을 뿐이다.삭제/사용자:암기네/모린의 RfC.문제는 정책상 RfC 삭제가 요구될 때 인증되지 않은 RfC 사본을 사용자 공간에 보관하는 것이 적절한지 여부다.이것은 삭제된 기사를 BJAODN에 복사하는 것과 비슷한가 아니면 위키백과 정책을 우회하는 것인가?당신의 의견을 환영한다.스와데어 토크 02:58, 2004년 12월 30일 (UTC)

개인 페이지의 하위 페이지는 항상 속도위반자들에게 중요한 것이었고, 나는 암기인이 "그의" 하위 페이지에 RfC를 시도했던 것이 더 이상 문제없이 삭제될 만하다고 생각한다.JFW T@lk 03:11, 2004년 12월 30일(UTC)

고양이벌레

Category에 짜증나는 버그가 있다.동일한 하위캣을 나열하는 국제연맹(League of Nations) 범주:국제 연맹, 3부 리그.이걸 어떻게 고칠지 알기나 해?나는 하위 캣을 삭제한 다음 다시 만들어 보았지만, 그것은 도움이 되지 않았다.AndyL 19:33, 2004년 12월 30일 (UTC)

이제 괜찮아 보인다.노엘 (토크) 03:04, 2004년 12월 31일 (UTC)

Sockpuppet 템플릿

합리적 의심의 여지가 없는 경우에 사용:템플릿:소크푸펫

사용 예: - David Gerard 20:37, 2004년 12월 31일(UTC)

지웠다.만약 그것이 양말 조각이라면, 그 사람을 와주 위로 막아라.다른 한편으로 트롤들이 사람들을 괴롭히기 위해 이 템플릿을 오용할 수 있는 가능성이 존재한다.대니 14:46, 2005년 1월 15일 (UTC)

오토브록커

오토브록커는 지금 미쳐가고 있는 것 같은데, 무슨 일인지 아는 사람 있어?Jayjg (토크) 00:22, 2004년 12월 31일 (UTC)

관련된 IP 주소를 모르면, 무슨 일이 일어나고 있는지 확실히 말하기는 어렵지만, 사용자 중 하나를 차단한 것으로 보인다.디시페이스는 많은 사람들과 대리를 공유하고 있었다(가능하지만 그럴 가능성은 희박하지 않다), 또는 그 사용자가 사용하려고 했던 가명들을 가지고 있었다(더 가능성이 높은 - 자동 잠금 장치의 시간을 기록 - 모두 원래 블록이 배치된 후 약 3/4시간 후에).이제 그만둔 것 같다.노엘 (토크) 02:59, 2004년 12월 31일 (UTC)

AOL - David Gerard 23:36, 2005년 1월 1일(UTC)

VFD로 표시된 신속한 삭제

나는 RC 순찰에서 몇 가지 사례를 우연히 발견했는데, 빠른 삭제로 vfd 태그가 추가되었다(그러나 VFD 활성화는 아직 만들어지지 않았다).현재 나는 그들을 떠나고 있지만 곧 그것이 문제가 해결되지 않는 한 이것은 장기적으로 좋은 생각이 아닐 수도 있다(또한 위키백과에 대한 기사를 1주일간 얻을 수 있는 방법을 제공한다.다른 사람들은 무엇을 하는가?Geni 21:43, 2005년 1월 2일 (UTC)

태그를 추가하는 사람에게 삭제 전에 투표할 필요가 없다는 사실을 알리고 WP에 알리겠다.CSD. Rdsmith4—Dan Talk 22:31, 2005년 1월 2일(UTC)

역사가 엉망이 되었다.

역사에 심각한 문제가 생긴 것 같다.역사 목록에는 버전이 나타나지 않고 있고, "diff"도 정말 엉망이 된 것 같다.여기서 여러 가지 사건들을 (내 습관대로) 별개의 움직임으로 기록했을 뿐인데, 여기 역사에는 변화가 나타나지 않는다.무슨 일인지 아는 사람?데이터베이스를 훼손하는 건가?노엘 (토크) 14:09, 2005년 1월 4일 (UTC)

나는 WP에서 편집한 내용을 다음과 같이 보았다.오늘 9시 46분 FARC는 페이지에서는 볼 수 있지만 역사에는 나타나지 않는다.아주 이상하다.Filiocht *** 14:42, 2005년 1월 4일(UTC)

내가 이해하기로는 위키백과에 대한 미디어위키 설정:아니, 우리는 데이터베이스를 훼손하는 것이 아니다. (기사를 만들면서 제출을 반복해서 치는 것과는 별개로, 이것이 야기하는 부패는 심각하지 않고 현재 일어나고 있는 일 없이 발생한다.)문서를 변경하면 변경사항이 마스터 데이터베이스로 전송되어 데이터베이스 읽기 서비스를 제공하는 슬레이브에 변경사항이 적용됨.현재 노예들은 변화를 처리하는 데 뒤떨어져 있기 때문에 변화가 나타나는데 시간이 좀 걸리고 그 사이에 일이 모순적으로 표시될 수도 있다. (이 모든 것은 내가 무슨 의도에 대해 어떤 생각을 하고 있는지 알 수 없을지도 모른다는 거부감과 함께 온다.)--fvw* 2005년 1월 4일(UTC) 17:11

위키백과 거부권

법적 고지 사항에는 몇 개의 허점이 있으며, 이를 해결해야 할 필요가 있다.

1. 위키백과에서:목록의 마지막 요소인 콘텐츠 거부권은 "Wikipedia가 법률적 조언을 제공하지 않음" 링크가 [[Wikipedia:법률 조언]]] 이것은 <노우키키>로 보호되지 않는 리디렉션이다.위키백과:법적 고지 사항.
2. 위키백과에서:목록의 마지막 요소인 콘텐츠 고지 사항 링크는 [[Wikipedia:위키백과 의료 표준]]]이지만 [[Wikipedia:]와 연결되어야 한다.의료 면책 조항]]]

관리자의 주의를 끌만한 다른 방법은 없다. - Amgine 18:24, 2005년 1월 7일(UTC)

나는 첫 번째 페이지를 고쳤다 - 거부권을 언급한 모든 기사 페이지를 바로 그곳으로 보내도록 수정했다.나는 우리가 지금 레디어를 보호할 필요가 없다고 생각한다.나도 두 번째 거 했어 (이제 제안된 대로 의료비 면책 조항으로 가.노엘 (토크) 04:40, 2005년 1월 8일 (UTC)

양말 인형

양말 인형을 사용하는 논란이 많은 사용자들은 어떻게 해야 할까?치즈 드림스가 두 가지를 가지고 있다고 확인했기 때문에 나는 이렇게 묻는다.사용자:치즈드림 및 사용자 대화:치즈 드림스.설치 프로그램이 기본 계정으로 리디렉션됨 사용자:치즈드림.Arbcom 주문의 시행을 보다 쉽게 하기 위해 이 두 개의 계정을 (그녀의 메인 계정을 차단하지 않고) 제거하거나 차단해 줄 것을 요청하고 싶다.또한 그녀와 연락하는 것도 어렵게 만든다. - 2005년 1월 9일 (UTC)

나는 그들을 "엉덩이 인형"이라고 부르지 않을 것이다. 왜냐하면 그것들은 보통 그곳에 단 한 사람만이 있다는 사실을 감추기 위한 것이기 때문이다.그것은 분명히 여기에서는 그렇지 않다 - 그것은 같은 사람이고 또한 그들을 사칭하는 사람도 아니다.나는 대체 사용자 이름이라는 용어가 이 경우에 더 적절하다고 생각한다.노엘 (토크) 13:38, 2005년 1월 9일 (UTC)

나도 그게 말이 된다고 생각하지만, 현재의 규칙은 정책을 회피하기 위해 사용될 때를 제외하고는 양말푸펫이 허용된다는 것이라고 생각한다.Jayjg (토크) 05:16, 2005년 1월 9일 (UTC)

2005년 1월 12일(UTC) Pedant 19:59, 블록 아래에 있는 편집에 사용된다.

테스트 wiki 깨짐

http://test.wikipedia.org/의 테스트 wiki는 기본 상태, 구성되지 않은 상태로 보인다.그것은 WP나 WP에 부적절한 시험을 하는 것을 어렵게 한다.SB. :-) — 색스프레지 ☎ *** 09:26, 2005년 1월 10일 (UTC)

브리온의 Wikitech-l 게시물을 참조하십시오.시험 위키가 함락되었다.루포 13:19, 2005년 1월 11일 (UTC)

대리점을 개설하다

개방형 프록시를 차단하기 위한 자동화된 메커니즘(즉, 개방형 프록시임을 확인한 후 IP를 자동으로 차단하는 'admin-script')을 고려할 수 있는가?그들은 골칫거리지만, 나는 캔투스의 리스트를 쫓는 것이 귀찮다. 왜냐하면 그것들 중 너무 많기 때문이다.내가 직접 그런 대본을 해킹할 수 있다고 생각하지만, 'admin-bot'은 논란이 될 것이고, 개발자들에 의해 운영되어야 한다고 생각한다.dab (dab) 11:19, 2005년 1월 11일 (UTC)

위키피디아에 따르면:차단 정책#익명 및 개방형 프록시:

사용자:프록시 차단기는 한때 열린 프록시를 자동으로 차단하는 데 사용되었으나, 일부 사용자의 ISP를 "스파이브"하면서 꺼졌다.

그래서 대답은 "싫다"! :-) 노엘 (토크) 16:31, 2005년 1월 12일 (UTC)

위대한 사람들은 똑같이 생각한다.나는 현재 RC-덤프 피드오프 콜(다른 목적으로도 이메일 변경 알림 등)을 구문 분석하는 기본 스크립트를 가지고 있으며, 기본 포트 8080과 3128 체크 인(물론 헤비 캐슁으로 몇 달에 한 개도 안 됨)을 하려고 했다.자동 차단 기능은 물론 없지만 "경고, 사용자가 프록시를 통해 내 받은 편지함에 게시 중" 메시지. --fvw* 16:48, 2005년 1월 12일(UTC)

자동 차단 해제

이거 아직도 고장났어?위키미디어 1.4로 옮긴 직후부터 매일 유통기한이 지난 블록을 풀고 있지만, 오늘은 내가 도착하기 직전에 누군가 아주 철저하게 작업을 한 것 같거나, 유통기한이 되면 블록이 다시 자동 제거되는 것 같다.블록 로그에는 누군가가 수동으로 처리했음을 나타내는 내용이 없다.-gadfium 01:03, 2005년 1월 13일(UTC)

Silsor는 버그가 수정되었다는 편집 요약과 함께 이 페이지에서 항목을 제거했으므로, 나는 그렇게 생각한다(그리고 매우 기뻤다).--fvw* 01:10, 2005년 1월 13일 (UTC)

그것은 이미 고쳐진 것 같다.Geni 01:11, 2005년 1월 13일 (UTC)

네, 그 버그와 유통기한이 안 보이게 한 버그는 둘 다 수정되었답니다.Rdsmith4—Dan Talk 12:22, 2005년 1월 15일(UTC)

이미지 저작권 문제

저작권 문제로 인해 많은 이미지들이 서서히 나열되고 있으며, 그들이 관련된 기사들의 토크 페이지에는 사전 경고가 없는 것으로 보인다.그런 만큼 여러 기사에서 영상이 누락된 것 같고 왜 삭제됐는지 추적하기가 매우 어렵다.스타 트렉과 아웃소스트(컴퓨터 게임)를 예로 들어보자. -- 앨리유니온 (토크) 08:48, 2005년 1월 14일 (UTC)

적어도 이 중 일부는 너무 자주 어떤 링크를 표시하지 않는 이미지 페이지의 지속적인 결함과도 관련이 있을 수 있다.결함이 해결될 때까지, 위키백과를 추가할 때 이미지 페이지에 이미지가 나타나는 알려진 페이지:저작권 문제 또는 위키백과:영상에 영향을 주지 않을 수 있음. -- infrogmation 20:56, 2005년 1월 15일(UTC)

저작권 문제 또는 확실하지 않은 이미지를 통한 그러한 이미지 삭제는 가능성이 희박하다-그것은 분명히 공정한 사용이며 나는 누구도 단순히 지원되지 않는 목록에 근거하여 삭제하지 않기를 바란다 - 저작권 문제 영역에서 삭제하는 사람은 적어도 o로 이미지 목록을 인식할 수 있어야 한다.이것처럼 경건한어쩌면 열의가 넘치고 공정한 사용에 대한 이해가 부족한 사람일까?그것을 이용하여 기사에서 이미지를 삭제(따라서 기사를 보는 사람들에게 문제가 있다는 것을 알리도록) 하는 이전의 가능한 카피비오 요건은 이제 없어 보인다.그것은 좋은 일이지만(공정한 사용은 이미지가 어디에 있는지 알아야 하고, 이미지가 제거된 후에는 그러한 용도를 찾기가 어려웠기 때문이다) 그러나 그것은 이미지의 상태를 알고 대체품을 찾는 데 가장 적합한 사람들에게 알려주지 않기 때문에 좋지 않다.기사의 토크 페이지에 공지사항의 요건을 추가하는 것이 적절한 대체인 것 같다.이미지에 대한 링크의 신뢰성을 향상시키기 위한 작업이 진행 중이지만, 삭제하기 전에 항상 이미지 검색을 사용하여 사용 부족을 확인해야 한다.Jamesday 22:24, 2005년 1월 21일 (UTC)

삭제 버그

오류가 발생하는 경우 - "이 아티클에는 블록 압축 리비전이 포함되어 있으므로 삭제할 수 없음.개발자들이 잘 알고 있는 일시적인 상황이라 한두 달 안에 고쳐야 한다.삭제하기 위해 기사를 표시하고 개발자가 당사의 버그 소프트웨어를 고칠 때까지 기다리십시오." - 페이지를 삭제하려고 할 때 해당 내용을 {{pending deletion}(으)로 교체하고 버그가 수정될 때까지 보호하십시오.Rdsmith4—Dan Talk 01:25, 2005년 1월 18일(UTC)

"블록 압축 개정"이란?이 벌레 신고한 사람 있어?RickK *** 05:47, 2005년 1월 18일(UTC)

벌레가 아니야.결함 :-) 오래된 개정 (2004년 12월 이전 개정)은 모두 공간을 절약하기 위해 데이터베이스에 압축된 것 같다.부작용으로서, 이것은 2004년 12월 이전 개정판, 즉 그 이전에 만들어진 기사들을 당분간 삭제할 수 없게 만든다.향후 소프트웨어 릴리스에는 압축 리비전을 삭제할 수 있는 수정 사항이 포함될 것이며, 그 후에는 그러한 문서를 삭제할 수 있다.루포 07:44, 2005년 1월 18일 (UTC)

제임스 데이는 얼마 전 오픈 팩츠 위키백과 현황판에 이와 관련한 글을 올렸다.

기사의 구 수정본의 압축이 진행되고 있다.[...] 이 일이 일어난 후 가장 눈에 띄는 징후는 소프트웨어에 완전한 지원이 이루어지기 전에 선택적 미삭제로 데이터 손실이 발생하지 않도록 하기 위해 2004년 12월 1일 이전에 만들어진 기사의 일시적 삭제 불능일 가능성이 높다.임시 해결책은 기사를 비우고 보호하는 것이다.개발자들은 실제 법적 조치가 불충분하게 만드는 어떤 경우라도 처리할 것이다.JamesDay 09:03 2005년 1월 6일 (CET)

그래서 당분간은 삭제하지 않고 살아야 할 것 같아.일반 사용자의 삶이 어떤지 보는 것으로 생각해! :-) 노엘(토크) 14:42, 2005년 1월 18일 (UTC)

벌레가 아니야.공지문에 담긴 팀 스타링의 유머감각이다.en의 이전 기사 버전은 약 80GB이다.한 번에 한 개씩 압축하면 약 40GB가 된다.많은 기사 개정판을 하나의 레코드로 결합하고 결합을 구성하면 약 15GB로 줄일 수 있을 것으로 예상된다.일부 수정본만 삭제 취소하는 새로운 기능은 블록 압축 형식을 이해하지 못하기 때문에 블록 압축 기록이 있는 문서 삭제를 해제하여 데이터 손실을 유발하는 선택적 삭제(삭제된 문서 개정 기록 또는 복원된 기록에서 본문 텍스트 누락)를 방지했다.두 가지 특징이 모두 필요했기 때문에 일부 기사의 삭제 가능성을 잠시 제한하는 것이 선택적 삭제 해제 기능에 대한 지연에 비해 최선의 접근방식인 것 같았다.더 빠르지는 않더라도 다음 소프트웨어 개정에서 처리될 것이다.Jamesday 14:42, 2005년 2월 1일 (UTC)

이러한 것들이 WP에서 나타나고 있다.CP 등.아마도 우리는 위키피디아와 같은 것을 시작해야 할 것이다.삭제는 이미 결정되었지만 결함이 있는 당사의 기사에 대해 즉시 삭제 가능한 압축된 기록 문서? - Infrogmation 18:06, 2005년 2월 9일(UTC)

아, 그게 바로 템플릿이야.삭제 보류 중(위 참조) 수행 - 카테고리에 추가:삭제 보류 중.노엘 (대화) 2005년 2월 9일 18:26 (UTC)

좋아, 고마워. -- 인포그램 17:57, 2005년 2월 11일 (UTC)

이러한 삭제 버그와 관련하여 VFD 페이지에는 다음과 같은 로그 목록도 있다.삭제/이전/블록 압축 오류에 대한 투표.VFD 기사를 삭제하는 경우 해당 페이지에 삭제 버그를 추가하십시오.VFD를 거친 페이지들에 대한 빠른 참조다. -- AlliUnion (talk) 15:24, 2005년 2월 26일 (UTC)

VfD Meritory Relisting의 중단 사항

위키백과에 대한 토론을 마무리하는 과정에서:삭제/Tom Sutter에 대한 투표 결과, 이전 자료의 완전 삭제-리터 복원 과정에서 (VfD 템플릿의 일부로 추가된) VfD-Cat 태그가 애논 에드에 의해 Tom Sutter에서 제거되었다는 것을 알게 되었다(요약: "이것은 그의 타격 경력 전체와 무관하지 않기 때문에 관련 없는 것!").

• 논쟁의 여지 없이, Cat 페이지를 컨설팅하는 것은 VfD에 있는 것을 볼 수 있는 실행 가능한 접근법이며, 볼륨 있는 VfD 페이지 메커니즘을 피하며, 이러한 행동은 Cat을 통한 노출을 120시간 정도가 아닌 18시간으로 줄였다.
• VfD 토론에 접근하는 대체수단은 결코 사용되지 않았을 수도 있지만, 우리는 VfD에 투표한 모든 사람들을 투표함으로써만 알 수 있었다.
• 이번 특정 투표는 접전(6D, 4K)이었으므로 2표만 더하면 결과가 달라질 수 있었다.
• 그렇지 않으면 손해 보는 쪽에 표를 던졌기 때문에 나는 (특히 협의 없이) 5일을 더 주기로 결정을 내리는 사람이 되고 싶지 않다.
• 내가 떠난 곳은 나의 폐쇄 취소, 협의 보류 중(여기에)이다.

--Jerzy(t) 06:50, 2005년 1월 20일(UTC)

음. 비록 내가 삭제론자지만, 나는 항상 우리가 대략적인 합의를 볼 수 있도록 충분한 시간을 갖는 것에 찬성해.일반적으로 어떤 것을 삭제하기 위해 며칠을 더 기다려도, 관련된 위해가 없다면(예: 명예훼손이나 기타 문제가 있는 자료) 문제가 되지 않는다.그래서, 이 경우에는, 나는 그것을 다시 카테고리에 추가한 후에, 기다림에는 아무런 해가 없다고 말할 것이다.노엘 (대화) 2005년 1월 20일 (UTC)

곰곰이 생각해 보면, 나는 개별적인 사례를 올바르게 다루는 것보다 이것이 어떤 패턴의 일부인지에 대해 더 많은 관심을 갖는다.다른 사람들이 VfD-Cat 태그의 제거를 알아차렸는가?다른 사람들은 만약 그들이 일어났다면 그들이 그들을 알아챘을 것이라고 생각하는가? 아니면 내가 세심한 주의를 기울인 결과인가?위키백과에 다음과 같은 것을 추가할 가치가 있는가?삭제 프로세스?:

VfD 하위 페이지를 닫힘으로 표시하기 전에 다음 범주를 참조하십시오.삭제 태그에 대한 투표 페이지는 그대로 유지된다. 삭제하지 않을 경우 토론을 종결하는 것을 건너뛰거나 위키피디아에서 해당 사실을 기록해 두십시오.관리자 알림판#마감 프로세스 중에 VfD Meritory Re-Listing의 중단은?

--Jerzy(t) 2005년 1월 20일(UTC) 18:08

이 구체적인 헤더(#VfD Merit Re-Listing의 어떤 중단?)는 며칠 안에 사라질 것 같기 때문에 언급하지는 않을 것이다.노엘(토크) 12:29, 2005년 1월 21일 (UTC)

Vfd 태그는 종종 페이지에서 제거되지만 일반적으로 태그 지정 후 몇 시간 이내에 제거된다(그 자체가 보통 페이지 생성 후 몇 분 내에 있음).나는 거의 모든 경우에 그것들이 꽤 빨리 복구된다고 생각한다. (대부분의 사람들은 watchlist에 편집된 페이지를 추가했다, 그래서 그들의 watchlist에 제거가 나타난다) 하지만, 몇몇은 네트로 빠져나가는 것이 있을지도 모른다. --fvw* 18:17, 2005년 1월 20일 (UTC)

나는 RC 순찰 중에 정기적으로 Anon 기물 파괴의 예를 찾아 VfD 하위 페이지나 태그로 되돌린다.만약 우리가 모든 경우에 투표 시간을 다시 등록하거나 연장한다면 그것은 유지 보수 악몽이 될 것이다.나는 항목이 주요 VfD 페이지에 계속 등재되어 있고 하위 페이지가 대부분 읽을 수 있는 상태로 유지된다면 충분하다고 말하고 싶다; 투표를 심각하게 방해하는 지속적인 공공 기물 파손의 경우, 차단/재검증 후 며칠간 더 목록으로 남도록 허용하라.정책에서 당신이 제안하는 문구는 트롤들이 고양이 태그를 몰래 제거한 다음 VfU. jni 12:18, 2005년 1월 21일(UTC)에서 추가 투표, 관리자 학대 또는 트롤링에 대한 주장으로 모든 사람들을 괴롭힐 뿐이다.

위키백과:자습서(편집) 및 위키백과:샌드박스

위키피디아가 다음과 같은 이유를 가지고 있는가?자습서(편집)에는 다음과 같은 하위 페이지가 있다.자습서(편집)/샌드박스 및 위키백과를 가리키지 않는 이유:샌드박스? -- 앨리 유니온 (대화) 08:32, 2005년 1월 22일 (UTC)

나도 그게 궁금했어.하위 페이지가 해를 끼치는 것으로 보지는 않지만, 리디렉션되었다면 항의하지 않을 것이다. --슬로우킹맨 *** 03:11, 2005년 1월 24일 (UTC)

튜토리얼의 처음 5페이지(일면 제외)는 지난 봄 만들어진 직후부터 그들만의 샌드박스가 있었다.그들은 아무런 해를 끼치지 않는 것 같고, 아마도 갈등을 편집하는 기회를 줄일 것이다.나는 그것이 행해진 다른, 더 구체적인 이유가 있었는지 기억나지 않는다. 그것은 위키백과/인터넷 시간에서 아주 오래 전의 일이었다.니테올네일스 21:53, 2005년 1월 29일 (UTC)

나는 그 하위 페이지들이 메인 샌드박스 자체와 같은 내용을 포함해야 한다고 생각한다...어쩌면, 그냥...그러면 누가 이 하위 페이지 샌드박스를 청소하고 있는가? -- AlliUnion (대화) 13:30, 2005년 1월 30일 (UTC)

한 가지 이유는 메인 샌드박스가 잠재적으로 꽤 붐빌 수 있기 때문에 충돌을 피하기 위해서였다.또한, 나는 새로 온 사람들이 다른 사람들의 실험을 볼 수 있는 것이 유용하다고 생각했다; 각각의 샌드박스는 종류에 대한 테마를 가지고 있다.얘기가 나왔으니까 가끔 치우는 거 잊지 않도록 할게.이소모르픽 19:34, 2005년 2월 4일 (UTC)

샌드박스 템플릿을 그 샌드박스에 추가했어. -- 앨리 유니언 (토크) 02:00, 2005년 2월 5일 (UTC)

무슨 일이 일어났는지는 잘 모르겠지만(아마도 새로 온 사람이 지웠을까?) 더 이상 없는 것 같다.어쨌든, 위키피디아에 이 모든 것을 추가했다.청소부.노엘 (토크) 22:27, 2005년 2월 5일 (UTC)

소크푸펫 검출

관리자가 IP 주소에 대한 액세스를 허용하기 위해 feure 요청이 접수되었는지 아는 사람?한 번 살펴봤지만, 이것은 내가 찾을 수 있는 가장 가까운 것이었습니다. (이 문제에 대한 이전의 논의에서 대략적인 합의는 사람들이 실제 위치를 보지 않고도 동등성을 확인할 수 있도록 IP에 접근하는 것이 좋았고, 예를 들어 다른 사이트에서 행해진 것이라고 생각한다.Live Journal - 문제 없음)그렇지 않다면 한 사람을 고발해야 한다(이미 없으면 내가 하겠다).노엘 (토크) 13:49, 2005년 1월 25일 (UTC)

IP는 매우 좋은 이유로 흔히 이용할 수 있는 것은 아니다. IP를 쉽게 이용할 수 있게 하는 것은 동의하지 않는 사용자들의 괴롭힘을 용이하게 할 것이다.심지어 관리자들에게도 너무 큰 풀이다.개발자들은 이런 이유로 IP를 비밀에 부치고, 양말 인형극에 관한 질문에 "예, 아니오, 아마도, 확실하지는 않지만" 등의 답변만 해 해당 사용자를 보호한다.사용자:알베루니의 IP가 빠져나와 직장 IP일 가능성이 있는 것으로 밝혀졌는데, 둘 이상의 사람이 자신의 게시물을 수집하여 문제의 직장으로 보내는 (비열한) 말을 한 것으로 알고 있다.그것은 쉽게 하기에는 나쁘고 나쁜 관행일 것이다 - David Gerard 14:47, 2005년 1월 25일 (UTC)

이 문제는 로그인하지 않은 것을 편집하는 사람들에게 현재 존재한다. (예, 네, 알고 있습니다, IP를 숨길 수 있는 사용자 ID를 얻을 수 있습니다.)또한, 내 노트는 어쨌든 그들을 "공통적으로" 이용할 수 있게 하는 것에 대한 것이 아니었다(하지만, 나는 당신이 관리자들도 너무 큰 풀이라고 생각한다는 것을 알고 있다.노엘 (토크) 15:56, 2005년 1월 25일 (UTC)

이러한 문제는 Jnc가 위에서 제안한 것처럼 IP 주소를 해싱함으로써 해결될 수 있다. 즉, 여러분이 볼 수 있는 모든 것은 일종의 고유 식별자일 것이고, 진짜 IP 주소는 항상 숨겨져 있을 것이다.그것은 당신의 정당한 우려를 없애는데 효과가 있을 것이고, 양말푸펫을 발견하는 능력은 정말로 큰 도움이 될 것이다-- 페르켈파라데 π 14:58, 2005년 1월 25일 (UTC)

에러, 그건 내 생각이 아니었어 - 나는 단지 앞의 토론에서 다른 사람이 한 말을 요약한 것뿐이야.노엘 (토크) 15:56, 2005년 1월 25일 (UTC)

해시함수가 알려지고 IP 번호별로 고유 번호를 생성하면(양말 인형을 포착할 수 있음) IP 번호와 해시 사이에 일대일 일치성이 있는 것으로 나타난다.이것은 해독하기 쉬울 것이다(특히 MediaWiki가 오픈 소스 코드인 경우). --Tony Sidaway Talk 15:14, 2005년 1월 25일(UTC)

여기에는 기술적 방법들이 있다(반복할 수 없는 해시함수를 사용하고, 또한 사람들이 사전을 편찬하는 것을 막기 위해 "소금"을 추가함 - 당신은 철저한 검색으로 소금 공간을 사람들이 찾을 수 없을 만큼 크게 만든다).노엘 (토크) 15:56, 2005년 1월 25일 (UTC)

정확해, 그래서 내가 관료들만 IP주소에 접근할 수 있다고 주장하는 거야.사람들이 기존 관료들이 IP를 볼 수 있는 것에 문제가 있다면, 그 기능을 새로운 관료들만 이용할 수 있도록 만드세요.이것은 새로운 권한 시스템으로 쉽게 할 수 있다.Johnleemk Talk 15:47, 2005년 1월 25일 (UTC)

나는 내가 이전의 토론의 감각을 잘못 이해한 것 같다.그들을 이용할 수 있게 하는 데에는 의견이 일치되지 않는다.그래서 우리는 개발자들에게 계속 의존해야 할 것이다. 만약 그들이 이것을 할 시간이 있다면, 그리고 언제, 나는 그들이 이것을 할 수 있을 것이다.노엘 (토크) 15:56, 2005년 1월 25일 (UTC)

나는 IP를 공표하는 것에 대한 합의가 없다는 것을 인정한다.그러나 나는 David의 위에 있는 주장에 대해 전혀 납득할 수 없다: 모든 사람들의 알버루니는 왜 공공 IP를 만드는 것이 좋은 것이 될 수 있는 완벽한 예시인 것이다.그것은 사람들이 행동하도록 격려할 수 있다.많은 사람들이 실명으로 편집한다.원한다면 2분 안에 내 집 주소를 알아낼 수 있어.내가 보기엔 우리가 관심 있는 편집자들은 자신들의 작품에 자부심을 갖는 사람들이야.트롤과 양말 탐지자들은 여전히 공공 IP에서 게시할 수 있지만, 나는 그들의 익명성을 보호하기 위해 우리 방식에서 벗어날 필요가 없다고 본다.만약 내가 직장에서 웹사이트를 방문한다면, 글쎄, 나는 내 IP를 나눠주는 것을 알고 있고, 그것이 어딘가에 서버 로그에 기록되기를 충분히 기대하고 있다.dab (dab) 16:10, 2005년 1월 25일 (UTC)

당신은 되돌릴 수 없는 해시함수를 만들어 볼 수도 있지만, 이것은 검색공간이 반드시 극도로 작기 때문에 큰 도움이 되지 않을 것이다. 그리고 후보 추측이 입력될 수 있기 때문이다.소금은 추론할 수 있고 알고리즘은 알려져 있으며 IP 번호는 항상 동일한 해시 값에 해당된다. --Tony Sidaway Talk 16:15, 2005년 1월 25일(UTC)

"소금은 추론될 수 있다" - 아, 아니에요.

첫째, "알고리즘이 알려져 있다"는 사실과는 무관하다.이러한 알고리즘은 종종 공개적으로 공개된다(예: RFC 3174 "US Secure Hash Algorithm 1 (SHA1)" 참조).('일방도'라고 한다..함수(function)"는 이유가 있다!)그러므로 당신은 결과 해시로부터 소금을 추론할 수 없다 - 그리고 입력의 일부를 갖는 것(예: 당신의 IP가 어떻게 변하는지 살펴봄으로써)도 도움이 되지 않는다 - 당신은 알고리즘을 알더라도 출력의 입력을 추론할 수 없다. (변형은 되돌릴 수 없다.)

둘째, 소금을 충분히 길게 만들면 사전 공격을 통해 알 수 없다(즉, 소금의 가능한 모든 가치를 시도해보고, 어느 것이 효과가 있는지 알아보려고 한다)는 것이다. 그래서 나는 위의 "소금의 공간을 철저히 조사해서 사람들이 찾을 수 없을 정도로 크게 만들어라"고 말한 것이다.예를 들어 소금이 992비트이고 IP 주소가 추가된 1024비트 결과를 생성하여 해시된 경우 32비트 입출력 쌍을 아는 것은 여전히 도움이 되지 않는다.노엘(토크) 17:17, 2005년 1월 25일(UTC)

나는 여기서 오해의 일부는 소금이라는 단어를 사용했기 때문이라고 생각한다.대부분의 경우 염분은 공공성이 있으며, 이 경우 분명히 그렇지 않다.나는 비록 그것이 정상적인 작동에서처럼 완전히 들어맞지는 않지만, 더 나은 용어가 열쇠라고 생각한다. 키는 절대 해독이나 검증에 사용되지 않는다.어쨌든, 지난 토론 이후로 나는 위키피디아에서 이것을 얻을 수 있는 유일한 방법은 그것을 코드화한 다음 그것을 켜야 하는지에 대한 토론을 시작하는 것이라는 것을 깨달았으니, 그렇게 할 것이다.내 위키백과판은 현재 조금 꽉 차있어서 아직 시작하지 않았어. --fvw* 21:17, 2005년 1월 25일 (UTC)

음, 일반적으로 소금은 사전 검색 및/또는 출력_value -> input_value 역매핑표의 사전 컴퓨팅을 방해하기 위해 단방향 해시 계산 과정에 첨가되는 값이다.내 생각에 여긴 목표지점인 것 같아.가장 잘 알려진 경우(유닉스 암호)에서는 소금이 공개적인 것은 사실이지만, 우리의 특정 애플리케이션에서는, 공용 소금과 함께 우리가 원하는 것을 할 수 있는 방법(IP 주소의 해시 버전을 비교하는 것을 허용하며, 사전 컴퓨팅 역방향 검색에 취약하지 않음)을 빨리 볼 수 없다.하지만, 뇌가 상쾌한 아침에 한 번쯤 생각해 볼지도 몰라! :-) 노엘(토크) 23:20, 2005년 1월 25일 (UTC)

IP가 암호화되어 있다면 오픈 프록시를 사용하고 있는지 어떻게 알 수 있을까? -Frazzydee e 18:36, 2005년 1월 25일 (UTC)

안 할 거야.이는 로그인하지 않은 사용자의 식별자로 IP를 대체하기 위한 것이 아니며, 로그인한 사용자에 대한 추가 정보일 뿐이므로 POVpusher01과 POVpusher02가 실제로 동일한 IP에서 편집하는 것인지 알 수 있다.우연히, 나의 원래 제안서는 편집자의 IP에 대한 되돌릴 수 없는 해시뿐만 아니라, 사람들이 탐지를 막기 위해 다시 전화 접속만 하는 것을 막기 위해 편집자의 /20(IP의 처음 20비트)의 되돌릴 수 없는 해시를 포함했다.완벽하지는 않지만 지금 가지고 있는 것에 비해 개선될 것 같아. --fvw* 21:38, 2005년 1월 25일 (UTC)

NLI 사용자들을 위한 IP 해쉬도 사용할 수 있게 만들어서 A.B.C.가 아닌지를 확인할 수 있도록 하십시오.D와 사용자 X는 같은 사람이었다.노엘 (토크) 23:20, 2005년 1월 25일 (UTC)

FWIW, 개발자들은 IP가 노출되지 않는 방식으로 일치하는 IP를 식별하는 방법을 적극적으로 연구하고 있다.그리고 AOL 문제에 대한 해결책 (동일한 사용자로부터의 연속적인 두 번의 액세스가 다른 프록시를 통과할 수 있는 경우) - David Gerard 08:39, 2005년 1월 26일 (UTC)

음, AOL 문제는 AOL의 협조 없이는 해결될 수 없다.그래, 쿠키 등으로 몇 가지 재주를 부릴 수는 있지만, 반쪽 정도의 실마리를 가진 사람을 상대로 AOL 문제를 해결할 수 있는 것은 아무것도 없다.(예, 알고 있습니다, AOL. 그러나 여전히). --fvw* 16:14, 2005년 1월 26일 (UTC)

특별히 분명히 한 것은 아닌 것 같다.나는 보안 알고리즘이 종종 공개적이고, 비밀로 유지될 수 있는 염가치가 실제로 매우 클 수 있으며, 실제로 순진한 사전 공격에 대한 증거가 될 것이라는 것을 알고 있다.그러나 이 특정 등급의 보안 알고리즘에서는 사전 크기가 작고 소금의 효용이 소금에 접근하지 않고 중복 IP가 포착될 수 있도록 해시가 항상 주어진 입력에 대해 동일한 값이어야 한다는 요건에 의해 제한된다. --Tony Sidaway Talk 16:00, 2005년 1월 26일 (UTC)

32비트의 IP와 연결된 128비트 랜덤 비밀 데이터의 SHA-1 패딩을 사용하면, 2-2비트의³² 해시를 안다고 해도 해시를 감안하면 나머지 2개의 IP 중 어느 것이 마녀인지 알 수 없을 것이다.이것이 가능하다고 생각되면 어느 것이 어느 것인지 결정하는 절차를 제안하십시오. --fvw* 16:14, 2005년 1월 26일(UTC)

이것은 해싱 IP에 안전하다.기본적으로 IP 10.2.3.4를 해시할 때 "수십억년 후 fhwuefhihqi:10.2.3.4"와 같은 해시를 한다.그들은 이것이 "e4bdf4208373ad7b"에 영향을 미친다는 것을 안다.공격자는 일반 텍스트의 "10.2.3.4" 부분을 알고 있다.그들은 평문의 "수십억년 후엔 결코 추측할 수 없는 정말 긴 문구"를 알지 못한다.그렇게 하기 전까지는, 그들은 "10.2.3.5"나 그 밖의 어떤 것이 어떤 영향을 미칠지 알아낼 수 없다.안전한 기능:당신이 모르는 암호와 나의 IP가 결합된 SHA1 해시는 "9c5120896f045ad9acc0c0c4fc4d740b327949e3"이다.동일한 암호와 ip 10.2.3.4의 SHA1 해시는 "c537137cdb0e178e0564b26298f7f503ef974121"이다.내 IP가 뭐야?암호를 알고 해시를 많이 하기 전에는 모른다.샘보이 09:47, 2005년 2월 11일 (UTC)

한 사람이 두 개의 사용자 이름을 입력하여 IP가 동일한지 알려 주는 기능을 만들 수 없는 이유는 무엇인가?그들은 많은 조합으로 입력하지 않으면 그 사람의 ip를 찾을 수 없다.만약 그것이 문제라면 당신은 그것을 하루에 1개의 질의나 다른 것으로 제한할 수 있다.내가 이 프로그래밍에 대해 잘 모른다는 건 알겠지?BreakedSegue 01:55, 2005년 1월 28일 (UTC)

그것 역시 가능한 해결책이다("그들은 동일한 IP 범위에 있다" 표시기와 결합), 그러나 IP의 해시가 발행되는 시스템은 ½(n-n²) 연산 대신 n 운영에서 n POV퍼들의 그룹에서 모든 sockpupting 사용자를 찾을 수 있을 것이다(이것이 좋은 것인지 나쁜 것인지 여부는 물론 취향의 문제다).나는 단지 이것에 대한 나의 취향이 옳다고 생각할 뿐이다.사용자에게 양식이 작동하는 것에 대한 추가적인 문제는 IP가 사용자와 연결되어 있지 않고 편집되어 있다는 것이다.각 편집은 다른 해시-of-ip을 가질 수 있다. --fvw* 17:11, 2005년 1월 28일(UTC)

Sockpuppet을 찾는 것이 관리자들에게 큰 문제인가?적어도 겉으로 보기엔 웬만한 양말뿌리들은 잡히고 싶은 듯 꽤 뻔해 보인다.의문스러운 훨씬 더 적은 수의 사람들에게, 양말 퍼펫과 관련된 대부분의 질문은 중재 위원회의 결정의 시행을 중심으로 하지 않는가?만약 그것이 사실이라면, 아브리트레이터 중 한 명(또는 아마도 두 명)이 개발자 권한에 접근할 수 있도록 하는 것이 더 좋을까?그냥 궁금해서.BlankVers 10:18, 2005년 2월 4일(UTC)

Sockpuppets는 종종 꽤 명백하다.불행히도 사용자와 친숙한 사람에게 명백한 것은 다른 사람에게도 분명하지 않은 경우가 많으므로, 확실한 증거를 쉽게 얻을 수 있는 방법이 있으면 좋을 것이다.이소모르픽 19:38, 2005년 2월 4일 (UTC)

사실, 나는 이것이 증거에 대한 오해라고 생각한다.우리가 잡은 양말 퍼펫은 꽤 명백하다.이게 우리가 그들을 잡는 이유야.다른 삭스푸펫은 오랫동안 발견되지 않았다(Gzornenflatz/Wik 사물은 그가 둘 다 편집하지 않았기 때문에 양말 꼭두각시는 아니지만 떠오른다) 또는 영원히. --fvw* 19:57, 2005년 2월 4일(UTC)

음....미디어위키 소프트웨어에 GPG 키 시스템을 포함시키는 것이 얼마나 어려울까... -- 앨리유니온 (토크) 20:19, 2005년 2월 11일 (UTC)

기본 페이지에 있는 동안 보호되는 이미지

보호 로그를 살펴본 후 이미지:Carson.JPG, 이미지:Caligula burst.jpg, 이미지:Rtm Witold fileci-aus.jpg, 이미지:Washingtonia filifera.jpg, 이미지:농구 게임.jpg, 이미지:A380.emirates.736pix.jpg, 이미지:메인 페이지에서 떨어진 후에도 여전히 보호되고 있는 버마 국기(1948) large.png와 이미지:Zhao.jpg.만약 내가 이것들을 좀 더 쉽게 추적할 수 있도록 템플릿과 카테고리를 만들었다면 반대할 사람이 있을까?나는 이 이미지들이 보호되는 다른 이유를 놓치고 있지 않다고 생각하지만, 내가 보호되고 있다면 나에게 알려줘. - RedWordSmith *** 21:12, 2005년 1월 25일 (UTC)

내가 듣기엔 괜찮은 것 같아.BreakedSegue 21:41, 2005년 1월 25일 (UTC)

그래, 좋은 생각이야. --fvw* 21:44, 2005년 1월 25일 (UTC)

해 봐. -- Jmabel Talk *** 22:20, 2005년 1월 25일(UTC)

지원 범위가 변경된 것처럼 들리므로 템플릿은 템플릿:mpimgprotected이고 범주는 범주:기본 페이지 이미지 보호 - RedWordSmith *** 23:59, 2005년 1월 25일(UTC)

흐음. 방금 메인 페이지를 확인했는데, 두 번째 클릭한 이미지가 보호되지 않았어.또한, 밑에 있는 자매 프로젝트 로고가 보호되지 않는다는 것을 알게 되었다.그것들은 35픽셀에 불과하기 때문에 큰 부담은 되지 않을 것이다. 그러나 템플릿에서는:위키백과 자매, 이미지 크기는 원본에 포함되지 않는다.그래서 만약 이것들 중 하나가 거대한 것으로 대체된다면... dbenbenn talk 00:22, 2005년 2월 11일 (UTC)

자동 잠금

자동 잠금 장치는 나를 혼란스럽게 한다.일부 사용자 이름이 차단되는 이유(예: Special: "Mother Larry" 참조):IPblocklist)에는 해당하는 자동 잠금이 없는 반면, 다른 (예: "OneGoy")에는 자동 잠금이 없는가?루포 12:48, 2005년 1월 27일 (UTC)

좋아, 내 질문에 대답해봐: 다음에 차단된 사용자가 편집을 시도할 때 자동 잠금이 효력을 발휘하게 되는 거야.따라서 사용자가 편집하지 않으면 사용자 이름 블록만 로그에 표시된다.루포 13:19, 2005년 1월 27일 (UTC)

공유 IP 차단

공유 IP 차단 정책은?그들의 토크 페이지에 공유된 템플릿이 있는 몇몇이 있지만, 그들의 모든 편집은 반달리즘인 것 같다.24시간 블록(반복된 반달리즘, 시험3메시지 무시 등)의 자격을 얻을 수 있는 몇 가지가 있지만 정책이 무엇인지 몰라 망설이고 있다.누군가 명확히 할 수 있을까? --DropDeadGorgias (대화) *** 20:34, 2005년 1월 28일 (UTC)

정책에 대해서는 잘 모르지만, 일반적으로 IP를 사용할 가능성이 있는 사람들이 많을수록 블록이 짧아진다는 것이 나의 평가다.예를 들어, 나는 한 시간 혹은 그 이하로 학교 IP를 차단할 것이다.Geni 20:49, 2005년 1월 28일 (UTC)

지니와 비슷하게, 만약 내가 생각하는 공유 IP 파괴를 본다면, 나는 보통 그들이 지루해하고 (희망적으로) 포기할 정도로 길게 두어 시간 동안 차단한다.Jayjg 20:52, 2005년 1월 28일 (UTC)

24시간이면 학교형 공유 IP 기물 파손의 최대치라고 할 수 있다.물론 정기적으로 반복되는 문제가 되지 않는 한, 이 경우 관련 IP/범위를 영구적으로 차단하는 것을 고려할 수 있다. --Dante Alighieri Talk *** 21:35, 2005년 1월 28일(UTC)

물론 IP를 공유하는 것은 학교뿐만이 아니다.회사 내의 많은 사용자들은 한 개 또는 몇 개의 외부 IP 주소도 공유할 수 있다.그리고 가정 내에서, 여러 대의 컴퓨터가 하나의 공용 IP 주소를 공유할 수 있기 때문에, 예를 들어, 한 아이가 위키피디아에서 금지된다면, IP 금지는 불행한 부모와 그 아이의 형제자매에게도 확대될 수 있다.

공공 접속 단말기(도서관 등)도 많은 위키백과 사용자들이 하나의 IP 주소(그리고 단일 브라우저와 쿠키 세트까지!)를 공유하는 상황을 제시한다.

Atlant 16:44, 2005년 1월 31일 (UTC)

(205.222.240.2 토크 기여), school ip, 1개월의 헛소리를 참조한다.단지 한 사람일 뿐인 것 같다.처음 24시간 금지는 아마도 그에게 약간의 스릴을 주었을 것이다.더 긴 금지는 이 젊은이의 습관을 고치는 데 도움이 될 것이다.덕 00:51, 2005년 2월 3일 (UTC)

공유 IP에 대한 공식적인 방침은 없는 것 같고, 만약 있다면 모를 것 같다.공공 터미널이 주로 공공 기물 파손에 이용되는 장기적인 패턴을 보인다면, 나는 긴 블록을 지지할 것이다.이소모르픽 20:32, 2005년 2월 4일 (UTC)

보호 경고

User(사용자)에서 나만의 보호 경고를 만들었음:AlliUnion/Protection_Warning.여러 명의 행정관이 제 토크 페이지에 메모를 남겨서 이에 대해 언급할 수 있는지, 개선이 필요한지 알려주시면 감사하겠다. -- 앨리유니온 (대화) 13:32, 2005년 1월 30일 (UTC)

3RR 회피 재다이얼

사용자 대화:83.109.185.152(노르웨이 ISP): 3RR 인식 애논이 세 번째 되돌린 후 다시 전화를 걸기만 하면 된다.이 문제를 어떻게 해결해야 할까?우리는 전체 IP 범위를 차단할 수 없다.나는 아논이 또 다른 편집을 할 때마다 짧은(30분) 블록이 지루해 질 것이라고 생각한다.일단 경고에 맡겼지만.dab (dab) 17:28, 2005년 1월 30일 (UTC)

예, AOL과 대형 DHCP 풀이 있는 네트워크에서도 동일한 문제가 발생함.보통은 막지도 않고 그냥 순진한 구경꾼들을 짜증나게 할 뿐이야.내가 생각하기에 이런 것들을 다루는 데는 담요를 뒤집어쓰는 것이 더 적절한 방법이다.아마도 우리는 "차단되었지만 기술적으로 차단할 수 없는 사용자 목록"이 필요할 것이다. --fvw* 00:26, 2005년 1월 31일 (UTC)

만약 그들이 좋은 편집을 시작한다면?매킹 00:30, 2005년 1월 31일 (UTC)

내 말은 블럭의 대체품이었으니까 24시간 동안 담요 재검증이라고 해.비록 그들이 좋은 편집을 시작한다고 해도, 비록 그들이 원할 경우, 그러한 되돌리기는 항상 좋은 편집을 무시해도 좋다. --fvw* 00:49, 2005년 1월 31일 (UTC)

많은 문제의 원인이 되는 DHCP 풀에서 편집하는 사람들에게 사용자 ID를 획득하고 로그인에 로그인하여 편집하도록 요구할 수 있다. 즉, 일부 주소 범위에 대해 로그인되지 않은 사용자로부터 편집을 허용하지 않을 수 있다.이것이 이전의 관행과 어긋난다는 것을 알지만 IP 주소를 가진 것처럼 사용자 ID를 가진 익명일 수 있다. 그리고 DHCP 풀에서 aon을 제어하지 못하는 것과 익명성의 매우 점진적인 손실과 비교한다면, 그것은 쉬운 결정이다.노엘 (토크) 05:49, 2005년 2월 2일 (UTC)

이는 해결책이며, 내가 반대하지 않는 해결책이다(또한 AOL 프록시를 차단하고 싶다).하지만 그것에 대한 합의에 가까운 어떤 것도 얻을 수 없을 것 같다.내가 선호하는 해결책은 차단된 사용자의 모든 편집을 누구나 자유롭게 되돌릴 수 있게 하는 것이다(현재 하드 금지된 사용자의 경우처럼).IP 풀을 비활성화해도 사람들을 완전히 차단할 수 있는 방법이 없기 때문에 이 또한 아마도 더 효과적일 것이다.--fvw* 05:53, 2005년 2월 2일(UTC)

단지 FYI-- 버질라에서 이것에 관한 기능 요청서 (#550)를 보았다.— 캐서린\ 02:^talk10, 2005년 2월 21일 (UTC)

또 다른 해결책은 3RR 목적으로 로그인하지 않은 사람에 의한 편집의 되돌리기를 계산하지 않는 것이다.논란이 되는 기사를 편집하는 애논은 3RR의 "보호"를 즐기기 위해 등록하고 로그인할 동기를 부여받을 수 있다.실제로 3RR 목적을 위한 익명 편집의 되돌리기를 계산하는 것은 약간 불공평해 보이는데, 이는 익명 편집자들이 실제로 편집 분쟁에서 등록된 편집자들보다 상당한 이점을 누린다는 것을 의미하기 때문이다.등록된 편집자는 3RR에 의해 제약을 받지만, 애논의 것은 다음과 같지 않다: 애논은 효과적으로 "금지"될 수 없다는 것을 알고 단순히 3RR을 넘어설 수도 있고, 다음 번 회귀를 하기 위해 다시 전화 접속하여 다른 IP를 얻을 수도 있다. --BM 02:17, 2005년 2월 11일 (UTC)

그것은 좋은 지적이고, 나는 개인적으로 이것에 동의할 것이다.하지만, 나는 당신이 편집자들을 2류 시민으로 대우하고 싶지 않은 사람들로부터 밀릴 것이라고 의심한다.또한 사용자 ID를 가진 편집자는 동일한 스턴트를 당길 수 있다. 3RR 워링 목적을 위해 애논으로 돌아와 할당량을 초과하기 위해 여러 개의 전화 접속을 사용한다.따라서 정책을 바꾸는 것은 아마도 수고할 가치가 없을 것이다.노엘 (토크) 13:49, 2005년 2월 20일 (UTC)

온라인 편집자는 자신의 IP를 쿠키에 암호화 할 수 있는가?블록 미디어를 피하기 위해 재다이얼하면 마지막으로 사용한 IP와 자동 잠금을 식별할 수 있다.이것은 쿠키를 삭제함으로써 회피하기 쉬울 것이지만, 정말 멍청한 반달들을 잡을 수도 있다.아이볼 18:35, 2005년 2월 20일 (UTC)

그것은 나에게 좋은 생각처럼 들린다.만약 당신이 그것에 대해 알고 있다면 우회하는 것은 쉬울 것이지만, 물론 우리는 그들에게 "당신이 가지고 있는 쿠키 때문에 차단되었다.삭제하는 것이 좋을 것이다." :) dbenn talk 19:08, 2005년 2월 20일 (UTC)