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

새 아티클의 봇 태그 지정

"디스플레이타이틀" 마법 단어 및 DAB 제목

개요:모호한 제목에 대한 잠재적인 스타일 변화.예를 들면 다음과 같다.

초안 페이지가 설정된 경우 WP:VPR/Styling 제목을 참조하십시오.

나는 토론을 위에서 저기에 있는 토크로 베꼈다.이 아이디어를 더 분석하고 고려할 수 있도록 도와주십시오.생각할 만한 더 많은 예시를 찾아라.일단 거기서 더 확실한 결론에 도달하면, 우리는 보다 공식적인 RfC, 여기, VPT 또는 다른 곳으로 그것을 가져올 수 있다.도움이 되길 바라. -- Quidity (대화) 22:51, 2010년 10월 26일 (UTC)[응답]

Ultra Records 링크를 악의적인 웹 사이트에 연결

Ultra Records 공식 웹사이트(www.ultrarecords.com)로 연결하기 위한 이 글의 링크를 클릭했을 때, 나는 Wait a minute로 리디렉션되었다.이것은 중요하다 - 우리는 당신의 장치를 체크한다. 그것은 허수아비 웹 페이지 ([1])이다.나는 이 사이트를 닫기 위해 인터넷 연결을 꺼야 했다.

몇 가지 Wait a minute에 대한 기사를 읽은 후!이것은 중요하다 - 우리는 당신의 기기를 점검한다. 나는 처음에 이것이 웹사이트보다 내 컴퓨터에 문제가 있다고 생각했지만, 1) 구글은 www.ultrarecords.com을 악성 웹사이트로 표기한다 ([2]; 2) 나는 잠시 기다려!로 리디렉션된다!중요한 사항 - ultrarecords.com에서만 장치를 확인하십시오. 3) 컴퓨터에서 찾을 수 없는 경우, 잠시 기다리십시오!이것은 중요하다 - 우리는 spyware-db.com에서 당신의 기기의 파일을 확인한다(그러나 나는 전문가가 아니다 - 아마도 그것들은 숨겨져 있고 나는 그것들을 어떻게 밝혀낼지 모른다).

내가 확신할 수 없는 사실은 내가 Ultra Records 기사에 있는 두 링크를 즉시 삭제하지 않은 첫 번째 이유인데, 다른 하나는 만약 내가 링크를 제거하기만 하면 공공 기물 파손으로 위협받을 것이고, 그 링크는 곧 복원될 것이라는 우려 때문이었다.

실수해서 미안해(영어가 토착이 아니라서)

마크갈 (토크) 09:22, 2010년 10월 24일 (UTC)[응답]

구글의 모든 결과는 이것이 사이트가 아니라 당신의 브라우저에 문제가 있다는 것을 나타낸다.더 나은 바이러스 검사기를 구하십시오.→ ROX ₪ 09:26, 2010년 10월 24일 (UTC)[응답]

아니, 구글은 사실 이 사이트를 블랙리스트에 올려놨어. — Edokter • Talk • 2010년 10월 24일 (UTC)[응답]

어, 네.OP가 제공한 구글 검색은 -- 아마 클릭했을 겁니다 -- 이 특정한 문제가 바이러스 감염의 결과라는 것을 보여주었다.→ ROX₪ 10:42, 2010년 10월 24일 (UTC)[응답]

응, 사이트가 감염되었어. 컴퓨터에 몰웨어를 설치하려고 할 거야.네가 내 링크를 클릭했다고 생각해? — Edokter • Talk • 2010년 10월 24일 (UTC)[응답]

물론 그랬지.그러나 위에서 말했듯이 OP가 제기한 구체적인 문제는 그가 직접 올린 링크에 따른 국소 바이러스 감염이다.더 나아가기 전에 다시 읽어보십시오.→ ROX₪ 10:58, 2010년 10월 24일 (UTC)[응답]

그렇다고 해서 OP에게 더 나은 버러스캐너를 얻으라고 말하는 것은 정당하지 않다.문제는 OP가 감염되었다는 것이 아니다; 문제는 ultrarecords.com이 그 특정 악성코드를 누군가의 컴퓨터에 설치하려고 할 것이라는 것이다; 그리고 그 문제는 OP가 우리에게 말하고자 하는 경고의 정당성을 보장한다는 것이다.기사에 구글의 분석 페이지를 가리키는 경고 링크를 걸었다. — Edokter • Talk • 2010년 10월 24일 (UTC)[응답]

내 FireFox가 G10, 어, 아니, 공격 페이지로 막았어.액세스^{[FATAL ERROR]} 거부 02:27, 2010년 10월 25일 (UTC)[응답]

이것은 적대적인 사이트라기보다는 합법적인 사이트에 침입한 것처럼 보인다.ultrarecords.com은 합법적인 회사다.적대적인 콘텐츠를 확인하는 McAfee SiteAdvisor를 시도해봤더니 아무런 문제가 없다고 한다.스톱배드웨어는 그들이 지난 이틀 동안 두 차례나 명단에 오르내렸다고 보고한다.(또한 Sitetruth.com을 통해 도메인을 운영했는데, Sitetruth.com은 그들이 미국공산당과 거리 주소를 공유한다고 보도하고 있는데, 그들은 같은 사무실 건물에 있다.)그래서 그들의 블록에 시간제한을 두도록 한다. --존 나글 (토크) 05:43, 2010년 10월 27일 (UTC)[응답]

보관 봇에 주석을 추가하는 중

현재 H3llBot은 아카이브된 링크 옆을 떠나고 있다.여기에는 의 용도가 포함된다. archiveurl=파라미터 및 {{Wayback}} 템플릿.이것은 내용에 대한 수동적인 검증이 없기 때문에 행해진다.보관된 버전은 원래 접속일로부터 6개월 이내에만 검색되지만, 그렇더라도 실제 보관된 내용은 인용 자료와 다를 수 있다.이 코멘트는 보관된 복사본이 사람의 개입 없이 검색된다는 사실을 확인하는 데 도움이 된다. 이는 배치 방식과 유사하다.

이러면 안 된다는 코멘트가 들어와서 이 얘기를 꺼내는 겁니다.보관된 사본 링크를 추가하는 봇도 자동으로 검색된 링크임을 명시한 의견을 게시해야 하는가?— HELLKOWNZ ▎TALK 12:40, 2010년 10월 27일 (UTC)[응답]

충돌 해결 등에 대한 관리자 튜토리얼

• 나는 여기서 짐보의 강연을 시작했는데, 짐보는 대체로 지지의 확언(비디오 포맷의 제안에 동의하지 않음)으로 대답했다.여기 내가 처음 올린 글의 전문이 있다.

공손함, 공손함 경찰 등의 문제는 행정/비행정 역학에서 특히 전쟁 편집 등과 관련하여 곪아 터지는 병이다.내 위치가 여기 좀 그려져 있어.내 제안은 이것이다. 지갑 열어라, 꼬마야!분쟁 해결 컨설턴트를 고용해서 일종의...난 내 전문 분야가 아니지만..인터넷에 접속할 수 있는..비디오 시리즈?어떤 형식인지는 모르겠지만, 행정가들이 그들을 보고 소통할 수 있는, 갈등 관리에 대해 훈련시킬 수 있는 무언가가 있다.IRC 정기 세미나라도?어딘가에 경찰서에 자원이 있는 것 같은데..?실제 직업도 비슷한 종류의 컨설턴트 일을 하는 위키피디아에서 이런 걸 공짜로 얻을 수도 있지 않을까?그 관리자들을 훈련시키고 그들이 될 수 있는 모든 것이 되도록 도와라.Tks.

• Tks • Ling.너트 (토크) 01:50, 2010년 10월 29일 (UTC)[응답]
  • 더 이상 파운데이션 후원 비디오 시리즈를 사용하지 마십시오.그것은 우리의 정책 페이지에 그런 것들이 들어가지 않도록 하기 위한 싸움이었다.긱스 (토크) 02:01, 2010년 10월 29일 (UTC)[응답]
• 만약 이런 것이 가능해진다면, 나는 비관리자들도 그것을 이용할 수 있게 하는 것을 강력히 지지할 것이다.론크01톡 02:03, 2010년 10월 29일 (UTC)[응답]

템플릿 구현 수정 제안:참조 목록

Template talk에서는 다음과 같은 제안이 있다.템플릿 구현을 수정하기 위한 참조 목록:참조 목록.이 변경은 템플릿이 열 개수를 고정하는 대신 열의 너비를 설정하게 된다.이것은 대부분의 사용자들에게 본질적으로 같은 것을 유지하면서 특히 큰 화면이나 작은 화면에서 디스플레이를 향상시킨다.이는 템플릿 구문에 영향을 주지 않으며 동일한 브라우저 호환성을 유지한다.그 제안은 템플릿의 사용이 많기 때문에 여기에서 발표되고 있다.템플릿 대화 페이지에 주석을 달으십시오.고마워, — 칼 (CBM · talk) 2010년 10월 29일 (UTC) 19:18[응답]

편집 창 높이 설정

제목대로.댐 레터박스 안에서 편집하는 느낌이고 섹션 편집만 해도 끊임없이 위아래로 스크롤해야 한다.사용자 환경설정(예: 높이에서 줄 수 n개)으로 설정할 수 있도록 설정하되, 모든 사용자의 기본값을 현재 기본값보다 약 1/3 증가시키십시오.안부 전해요Zunaid 10:56, 2010년 10월 30일 (UTC)[응답]

든든한 지지.짧은 상자가 꽤 거슬린다.그리고 사용자 선호도는 좋은 생각이다.레흐만⁽⁺⁾ 11:01, 2010년 10월 30일 (UTC)[응답]

지원 - 조정 가능한 사용자 선호도를 만드는 것은 좋은 생각이라고 생각한다.Mlpearc wow 11:14, 2010년 10월 30일 (UTC)[응답]

댓글을 달다.그것이 선호도/편집/크기편집 창문의 용도가 아닌가?2010년 10월 30일 보르쇼프 동쪽(UTC)[응답하라]

주석 사용자 환경설정을 살펴보십시오. 사용자가 이미 구성할 수 있습니다...—DJ (대화 • 기여) 11:34, 2010년 10월 30일 (UTC)[응답]

그러나 "편집 상자를 전체 화면을 채우도록 확대" 옵션은 편집 상자를 더 크게 만들지는 않지, 그렇지?레흐만 11시 44분⁽⁺⁾, 2010년 10월 30일 (UTC)[응답]

특수:Preferences -> Editing -> Editing 창 크기는 나에게 잘 맞는다.실패하는가, 아니면 바람직하지 않은/예상치 못한 결과를 내놓는가?보브레이너(토크) 11:48, 2010년 10월 30일(UTC)[응답]

오, 그거...그래, 그건 나한테 효과가 있어...*창문을 난처하게 만들다* 레흐만⁽⁺⁾ 11:51, 2010년 10월 30일 (UTC)[응답]

아이고!!! 참 난처하군!(지금 50줄이나 되는 상자 안에서 편집하고 있는데, 공백 :P에 빠져 죽겠어.제안서는 우리의 IP 사용자들을 대신하여 그에 따라 수정되었다.Zunaid 05:58, 2010년 10월 31일 (UTC)[응답]

크레이그리스트 포럼의 길을 개척하다.

들여쓰기 목록은 * 또는 :를 사용하여 만들 수 있다.
나는 세 번째 선택권을 제안한다.
크레이그 리스트 포럼에서 볼 수 있는 것과 유사한 들여쓰기 리스트를 생성하는 것.
http://sfbay.craigslist.org/forums/?forumID=96&mode=night
각 들여쓰기 수준이 ":.."

sfo 왜 아직도 미국에서 담배를 구할 수 있는가 < 과학-연구- have > 10/30/10 12:27
: . . 인구조절 < - > 10/30/10 12:32
: . . . . . *_켐 트레일_* § < -> 10/30/10 12:33
: . . 신뢰할 수 있는 세수?§ < 너무> 10/30/10 12:39
왜 그레이들은 항상 멍청한 질문들을 올리지?§ < 마녀곡> 10/30/10 12:51 -3+5
: . . . . 왜 그 질문이 § < ?--> 10/30/10 13:18을 혼란스럽게 하는가.
: . . . . . . 혼란은 없다.< 마녀곡> 10/30/10 13:23
: . . . . . . . . 그것은 더 많은 사람들이 빠른 foo < 10/30/10 13:29>를 소비하기 때문일 뿐이다.
: . 물론 농담이지!< 10/30/10 13:12>
: . . . . . 그 <사람-최고의 이익> 10/30/10 13:28을 뒷받침할 만한 과학이 충분히 있기 때문이다.
: . . . . . . 흡연의 혜택은 없다...< 10/30/10 13:34>
: . . . . . . . 그건 확실하지 않아. 나는 <신뢰성-신뢰성-신뢰성-신뢰성-신뢰성-신뢰성> 10/30/10 13:38이 적은 것 같아.
: . . . . . . . . 음, 니코틴에는 몇 가지 유익한 효과가 있다.< Achernar > 10/30/10 13:39 링크
: . 금주(역사를 배우다) < 10/30/10 13:44>
: . . . . 말이 안 되는군.태양은 생명체의 사실이다 § 10/30/10 13:56
: . . 당신의 글의 진짜 질문은 정부 < 10/30/10 13:48>인가이다.
: . . . . 근본적인 문제는 한 사람의 행동 <ior-the-the 10/30/10 13:55>일 때다.

이것은 어떤 게시물에 응답하고 있는지 쉽게 알 수 있게 해준다.
이것은 많은 수준의 들여쓰기가 있는 긴 리스트에 매우 유용할 것이다.
아마도 이것은 이미 존재하는 리스트 작성 방법 중 하나에 대해 선택될 수 있을 것이다(: 및 *)
을 이용하여<span class="something">
just granpa (대화) 21:18, 2010년 10월 30일 (UTC)
[답글]

WP:LiquidThreads, 아마도 곧 현실로 나타날 것이다. -- Quidity (대화) 21:21, 2010년 10월 30일 (UTC)[응답]을 참조하십시오.

그거 정말 좋은 생각인 것 같아.그러나 나는 기사 페이지에도 그 문구를 사용하고 싶었다.just granpa (예를 들어 말하기) 22:04, 2010년 10월 30일 (UTC)[응답]

프랑스어 위키백과에서 구현한 것처럼 좋은 '올 CSS'도 사용할 수 있다(fr:토론 위키백과: 참조):어큐일 교장).–MuZemike 23:31, 2010년 10월 30일 (UTC)[응답]

나는 크레이그 리스트 방식이 마음에 들지 않지만, 나는 프르위키 방식을 사용하고 있다.enwp가 그런 식으로 적응했으면 좋겠다. / /ETECCOMMS/02:06, 2010년 10월 31일 (UTC)[응답]

대화 페이지에 들여쓰기

현재의 정책은 대화 페이지에서 서로 다른 사용자의 말을 구분하기 위해 들여쓰기를 사용하는 것이다.그러나 같은 주제에 대한 많은 답변으로 토론이 가열되면, 예전에 들여쓰던 콜론들은 점점 더 많아지고 페이지는 보기 흉해 보인다.바꿀 수 있을까?전용 박스 템플릿을 만드는 것처럼?--Netheril96 (토크) 11:06, 2010년 10월 9일 (UTC)[응답]

템플릿 {{od}}} 액세스 거부 15:46, 2010년 10월 9일 (UTC)[응답]

들여쓰기는 단순히 코멘트를 구분하는 것이 아니라, 어떤 코멘트가 회신되고 있는지 보여준다(도움말: 참고:Talk_page#들여쓰기.박스가 움푹 패지 않고 어떻게 그것을 이룰 수 있을까?또한 WP:LiquidThreads는 결국 이곳에 배치될 것이다.PL290 (대화) 2010년 10월 9일 (UTC) 19:22 [응답]

제발 LQT는 안돼 No No No No No No No No No No No.그것은 WP에 위배된다.NOTFORM, WP:NOTBLOG, WP:NOTChAT, WP:NOTWITER, WP:NOTFACEBOOK, WP:MYSpace 및 기타 여러 정책그것은 또한 나의 아이팟 터치에 대한 부하 시간을 증가시킬 것이다.게다가, 그것들은 못생겼고, 거의 모든 사람들이 원하지 않는다.2010년^{[FATAL ERROR]} 10월 9일(UTC) 19:25 액세스 거부[응답]

이거 정말 꼴사납다.2010년^{[FATAL ERROR]} 10월 9일(UTC) 19:27, 액세스 거부[응답]

그것은 개인적인 취향의 문제다. 나는 개인적으로 괜찮게 보인다.어쨌든, 적어도 예시의 대화 흐름이 따라 하기 쉽다는 것에 동의하십니까? --Cybercobra (대화) 22:03, 2010년 10월 9일 (UTC)[응답]

당신은 당신이 인용하는 바로 가기들을 잘못 해석하고 있다. (실제로 그것들 사이에 2개의 뚜렷한 정책만을 가리키고 있다; 중복성의 뎁트!); 그것들은 위키피디아가 소셜 미디어 사이트나 웹 포럼이 아닌, 우리가 말하는 페이지와 메타 토론 페이지의 의미에서 "포럼"을 갖는 것에 관한 것이 아니다.그렇지 않으면 마을 펌프가 존재하지도 않고 이런 논의도 일어나지 않을 것이다.--사이버코브라(토크) 22:03, 2010년 10월 9일 (UTC)[응답]

나에게 리퀴드스레드는 토론 페이지의 큰 발전이 될 것이고, 나는 그것이 en.wiki에서 소개되도록 시험되고 있다는 것을 알게 되어 기쁘다.액세스 거부:정책에 대한 오해에도 불구하고, 인터페이스에 대한 커뮤니티의 합의를 측정하려는 마지막 시도의 결과를 고려할 때, 나는 "거의 모든 사람들이 원하지 않는다"라고 말하기 전에 주의할 것이다.--Cyclopia^talk 17:40, 2010년 10월 15일 (UTC)[응답]

LQT가 개선될 것이라는 데 동의했다.그것에 대해 나를 매료시킨 것은 유연한 사후 주문이었다.나는 항상 토론이 진부하고 대답하지 못하고 결국 보관되고 잊혀지는 것을 주요한 단점으로 여겼다.LQT를 사용하면, 포스트에 답장하면 다시 정상으로 올라온다.개별 스레드를 감시할 수 있는 능력도 또 하나의 주요 판매점이다. -- œ^™ 23:01, 2010년 10월 16일 (UTC)[응답]

만약 LQT가 추가되었다면 나는 여전히 정상적인 대화 페이지를 가질 수 있을까?또한, 나는 위가 아닌 아래쪽에 새로운 메시지를 원한다.액세스^{[FATAL ERROR]} 거부 23:15, 2010년 10월 16일(UTC)[응답]

이것은 액체 실에 대한 일종의 투표가 되어가고 있는 것처럼 보이기 때문이다.나는 전략위키에서 그들과 맞닥뜨렸고 그들이 극도로 혼란스럽다는 것을 알았다.주된 문제는 위키와 그 페이지에서의 나의 준지리적 지향성이 그들이 액상 실을 위해 구현해 온 감시원 대체와 함께 완전히 무너졌다는 것이었다.실들은 이리저리 움직이며 다른 장소에 나타난다.그러다가 내가 읽은 것을 확인한 후 갑자기 실이 사라진다.서로 다른 대화 페이지의 스레드도 같은 페이지에 같이 나타나는데, 어느 순간엔가 댓글을 달았고, 마지막으로 읽은 이후로 모두 새로운 댓글을 달았다고 생각한다.이것은 심지어 내가 두 페이지 정도밖에 논평하지 않았던 그 미니 위키에서도 혼란스러워졌다.그냥 바보 같은 기본 설정이나 그런 걸 영어 위키피디아에 소개할 수 있는 유일한 기회는 처음에는 ANI를 액체 쓰레드로만 변환하는 것과 같은 속임수를 통해서일 수도 있는데, 처음에는 최소한 게시물 수를 절반으로 줄일 수 있기 때문에 타당할 것이다.한사들러 23:24, 2010년 10월 16일 (UTC)[응답]

음, 우리 모두 각자 취향이 다른 것 같아.LQT에 대한 명확한 합의점을 얻을 수 없을 것 같은데, 대부분의 사용자들 사이에서 꽤 균등하게 나누어져 있는 것 같아. -- 04^™ 04:59, 2010년 10월 17일 (UTC)[응답]

…LQT가 사용적합성 영역에서 더 많은 작업이 필요하다는 것을 보여준다. --Morn (대화) 14:42, 2010년 10월 18일 (UTC)[응답]

위키리드와 달리 리퀴드스레드는 개별 사용자의 취향에 맞게 구성 가능하다.스레드를 생성 시간별로 오름차순으로 정렬하면 스레드가 예기치 않게 "이동"되지 않는다(개인적으로는 기본 LQ 정렬 순서가 더 좋다).Dcoetzee 11:03, 2010년 10월 25일 (UTC)[응답]

사용자에게 다른 사용자의 게시물을 편집할 수 있는 능력 부여, 페이지의 모든 새로운 게시물을 읽을 수 없는 차이점, 수직 화면 공간의 일반적인 낭비 등과 같은 다른 사용적합성 문제가 있다.토크 페이지는 편집하기가 좀 번거롭지만 꽤 효율적이다.LQT는 단지 아직 그것들과 일치하지 않을 뿐이고 아마도 큰 개발 노력이 없는 한 결코 그럴 수 없을 것이다.그래도 제안된 기사토론 포럼 등 비편집자가 주로 사용하는 페이지의 경우 LQT가 이상적일 수 있다. --Morn (토크) 14:37, 2010년 10월 25일 (UTC)[응답]

위에서 거부된 액세스에 동의해야 한다.그가 액상 실을 준 예에서, 메시지는 완전히 무관해 보이는 반면, 여기서 움푹 들어간 메시지는 분명히 위의 것과 관련이 있다.또한, 이 페이지의 내 경험상, 많은 ppl이 그것의 존재를 인식하지 못하지만, 그것은 사용하기 매우 간단하다.마크^Dask 07:38, 2010년 10월 31일 (UTC)[응답]

사용자 권한 수정

롤백을 부여받은 사용자는 분명히 충분히 신뢰할 수 있기 때문에 검토자 사용자 권한은 롤백 사용자 권한과 함께 자동으로 번들되어야 한다고 생각한다.두 사용자 권리는 롤백자가 PC 보호 페이지에서 반달리즘으로 식별된 편집을 롤백할 때, 기존 검토자에게 필요 없는 작업을 조금 더 추가해 검토할 필요가 있다.검토자에게 충분한 경험이 있지만 롤백하지 않은 새로운 사용자에 대해서는 검토자 권한도 별도로 유지되어야 한다.생각?—ғяіaз'Trsđøм • 샴페인? • 오후 7:18 • 08:18, 2010년 10월 14일 (UTC)[응답]

이대로 유지하는 것 만으로도 더 쉬울 것이다.롤백자가 검토자를 원할 경우 WP에서 신청할 수 있다.PERM. WikiCopter (라디오 • 정렬 • 이미지 • 촬영) 23:36, 2010년 10월 14일 (UTC)[응답]

개념적으로 효과가 있는 것 같아, 그렇게 하는 것이 얼마나 힘들지 모르겠어(너무 어려워 보이지는 않는다).데릴드4921☼ 23:54, 2010년 10월 14일 (UTC)[응답]

확인, 롤백, 검토자, 자동 등록, 계정 작성자(여기서 간략하게 설명), 그리고 (대규모 목록을 작성해야 하는 AWB 사용자에게 유용한)의 권한을 포함하는 '분할된 권한' 사용자 그룹을 고려해야 할 때일 수 있다.–xeno^talk 00:09, 2010년 10월 15일 (UTC)[응답]

move-subpages 또한–xeno^talk 13:20, 2010년 10월 15일 (UTC)[응답]

나는 권리집단을 지지한다. 억압하는 간접은 분명히 있어야 한다.—ғяіaз'Trsđøм • 샴페인? • 오후 8시 12분 • 09시 12분, 2010년 10월 15일 (UTC)[응답]

나는 평론가의 권리가 너무 무차별적으로 분배되었다고 생각한다. 그래서 나는 그곳에서 일하지 않는다.NPP나 RCP보다 덜 중요해, 패트롤러들이 쿼를 전혀 필요로 하지 않는 곳이지!지금은 취소할 수 없고, 확정, 롤백, 검토자, 자동화된 계정 생성자를 포함하면 그러한 특권이 줄어들 것이다.--쿠드풍 (토크) 10:13, 2010년 10월 15일 (UTC)[응답]

확실히 하자면, 기존 사용자 권한을 함께 롤링하는 것이 아니라 새로운 사용자 권한을 만드는 것이 나의 제안이었다.당신의 진술에 따르면, 나는 이전에 모든 사용자들이 가지고 있던 능력이 어떻게 "너무 무차별적으로" 배포될 수 있는지 잘 모르겠다.변경 보류 중이기 전에 모든 사용자는 익명 변경을 검토할 수 있었다(수동적으로 - 실행을 취소하지 않음).–xeno^talk 12:54, 2010년 10월 15일 (UTC)[응답]

이 "분할된 권리" 제안의 선에서 분명히 무언가를 지지한다.내 기여에 크게 도움이 될 만한 권리들이 있지만, 나는 걸레를 갈망하지 않고 단지 그것들을 얻기 위해 그 고리들을 뛰어넘고 싶지도 않다.PC78 (대화) 21:08, 2010년 10월 15일 (UTC)[응답]

확실히 하자면, 기존의 비관리자 권한이 모두 번들로 제공된다면 위키 혼란을 야기할 수 있는 별도의 사용자 권리를 제안하는 것이었습니다.Suppressredirect 미사용 페이지에서 고도로 사용되며 가시성이 높은 페이지로 리디렉션하는 것은 무의미하며, 관리자가 이러한 리디렉션을 삭제할 때 불필요한 작업을 추가한다.apihighlimits AWB 사용자를 도울 수 있는 이것과 다른 개별 비트를 정기적으로 사용하는 사람들을 위해 별도의 AWB에 넣어야 한다.—ғяіaз'Trsđøм • 샴페인? • 오후 2:35pm • 03:35, 2010년 10월 16일 (UTC)[응답]

그래서, 난 여기서 이름을 만들거야.

• Patroller(더 나은 이름을 원하면 대부분 관리자 동의 하에 제공됨) = 억제 간접, 검토자, 롤백자, 자동 정렬, 이동 하위 페이지
• 플러더 = api하이리츠, bot

댓글얼어붙은 바람이 차가울까?20:43, 2010년 10월 16일 (UTC)[응답하라]

나는 네가 무엇과/또는 무엇을 위한 것인지 이해하지 못한다고 생각한다.Killiondude (대화) 19:34, 2010년 10월 17일 (UTC)[응답]

나는 알고 있다: 결과 제한을 500에서 5000으로 늘리고, 일반적인 최근의 변화로부터 편집 내용을 숨기지만, 만약 당신이 "Show bots"를 켜면, 그것은 그것들을 보여준다.얼어붙은 바람이 쌀쌀해지려나? 21:34, 2010년 10월 17일 (UTC)[응답]

나는 그것들을 분리할 필요가 없다고 보고, 자동화가 되지 않은 편집자들에게 '봇'을 주는 것에 동의하지 않는다.–xeno^talk 13:17, 2010년 10월 18일 (UTC)[응답]

봇은 확실히 봇에 국한되어야 한다.APIhighlimits는, 전혀 그렇지 않다면, 그것의 필요성을 증명할 수 있는 편집자에게만 사례별로 외출해야 한다.'패트럴러' 묶음은 작동 가능한 것 같지만.--Fyre2387^{(talk • contribs)} 18:38, 2010년 10월 18일 (UTC)[응답하라]

지금 당장은 봇그룹 외부에 배정할 수 없기 때문에 묶음 안에 넣는 게 가장 좋을 것 같아.–xeno^talk 18:44, 2010년 10월 18일 (UTC)[응답]

apihighlimits 그러나 다른 사용자 그룹에 쉽게 할당될 수 있다.나는 ACC 비트에 없는 사람들에게 어카운트 크리에이터가 주어지는 것을 좋아하지 않지만, 리뷰어를 번들로 묶어서 롤백하는 것이 좋을 것이다.또한 좋은 점은 자동 확인/확인된 사람 이상의 모든 사람이 허가할 수 있는 apihighlimits를 위해 특별히 새로운 그룹을 보는 것이다(즉, 롤백업자가 그것을 허가할 수 있다).나는 이것에 의해 부과되는 어떠한 실질적인 위험도 보지 않는다. 왜냐하면 그것이 무엇을 하는지/그것을 어떻게 사용하는지를 아는 사람들은 그 문제들을 이해해야 하고, 이해하지 못하고 놀려고 노력하는 사람들은 아마도 그것이 무엇을 위한 것인지 알아내지 못할 것이기 때문이다.그냥 내 0.02달러야.[stwalkerster talk] 01:22, 2010년 10월 19일 (UTC)[응답하라]

Patroller 번들은 좋은 아이디어 IMO이다. 하지만 만약 실행된다면, 나는 사용자를 Patroller로 플래그를 지정하는 것이, 참조되지 않은 BLP 작성, 편집 전쟁에서의 롤백 등과 같은 사용자 권리의 일부가 남용될 수 있기 때문에, 더 이상 자유분방하게 수행되지 않아야 한다고 말한다.Stwalkerster의 의견에 동의하지만, Account Creator 플래그는 ACC와 전혀 관련되지 않은 사용자에게 주어서는 안 된다.—ғяіaз'Trsđøм • 샴페인? • 오후 4시 13분 • 05시 13분, 2010년 10월 20일 (UTC)[응답]

나는 패트롤러 오른쪽 보따리가 매우 좋은 생각이라고 생각한다.억제 리디렉션 플래그는 특히 잘못 배치된 작성용 문서를 이동하는 데 유용할 것이다.그렇게 하면 메인스페이스에서 위키백과 네임스페이스로 리디렉션되지 않는다.그것은 또한 페이지 이동 반달리즘을 되돌리는 데도 꽤 유용할 것이다.나는 자동 등록 깃발이 묶음에 추가되는 것을 좋아하지 않는다.그렇게 하려면 사용자는 75개의 제안 기사를 작성해야 할 것이다.나는 도구를 받기 위한 표준이 있어야 한다고 믿지만, 번들을 받기 위한 표준이 RFA보다 커야 한다고 생각하지 않는다.최소 3,000개의 편집, 20개의 적절한 페이지 이동, 신뢰할 수 있는 출처 및 기타 정책(예: 참조되지 않은/적절한 기사 작성)의 적절한 이해 및 사용.이건 그냥 대략적인 제안이야. --Alpha Quadrant^talk 14:33, 2010년 10월 20일 (UTC)[응답]

지푸라기라도 잡는 게 좋을까?—ғяіaз'Trsđøм • 샴페인? • 오전 11시 46분 • 00:46, 2010년 10월 24일 (UTC)[응답]

아니다. 두 달 전 이 주제에 대해 내가 시작한 지난 토론에서 지역사회는 의견 일치를 보지 못했다.보통 여론조사는 사악하기 때문에 지금 지푸라기 여론조사는 도움이 되지 않을 것이다. /ƒETCOMMS/18:03, 2010년 10월 25일 (UTC)[응답]

여론조사는 대체로 사악하다. 동의할 수 없다.그러나 이러한 권리는 대부분의 사용자에게 이익이 될 것이다.Suppress redirect는 AfC에서 활동하는 사람들에게 유용하며, apihighlimits는 AWB를 자주 사용하는 사람들에게 유용하다.영어 위키백과에서는 먹혔는데, 영어 위키백과에서는 안 먹힐 것 같아?—ғяіaз'Trsđøм • 샴페인? • 오후 7시 33분 • 08시 33분, 2010년 10월 26일 (UTC)[응답]

또한 사용자가 파일을 이동할 수 있는 새로운 사용자 권한을 만드는 것이 좋은 생각일 것이라고 생각한다. 이 권한은 OTRS 자원봉사자 등과 같은 어떤 기준을 충족하는 사용자에게만 주어질 것이다.—ғяіaз'Trsđøм • 샴페인? • 오전 11시 28분 • 00시 28분, 2010년 10월 30일 (UTC)[응답]

개인적으로, 나는 번들을 하는 것을 경계한다; 나는 한 번에 다수의 권리를 할당하는 것의 이익보다 누가 할 수 있는가에 대해 어느 정도 세분화함으로써 얻는 이득이 더 크다고 생각한다.

최악의 경우, 만약 여러분이 여러 가지 다양한 일을 할 수 있는 능력을 한데 묶었다면, 많은 위키피디아는 자연스럽게 더 엄격한 조사를 주장할 것이다. 후보자가 실제로 능력 중 하나를 원하는 경우에도 모든 능력을 신뢰할 수 있도록 하기 위해서 말이다.다음에 나올 드라마를 생각해봐! ;;-)

하지만 새로운 파일 이동권에 대한 생각은 흥미롭게 들린다.혹시라도 단점이 있을까?

보브레이너 (대화) 08:27, 2010년 10월 30일 (UTC)[응답하라]

나는 검토자, 롤백자, 억제 간접 페이지, 이동 서브 페이지가 결합되어야 한다고 생각한다.(위의 논의에서 살아남은 경우) 자동 조정과 접근은 서로 다른 포커스로 사용자에게 서비스를 제공하기 때문에 별도로 유지되어야 한다.(Vandalism fighting vs content creation vs "사용자 관계")—Train2104 (talk • 기여 • counts) 18:06, 2010년 10월 31일 (UTC)[응답]

엄지손가락 또는 프레임 없는 SVG

일반적으로 이미지와 함께 "썸" 또는 "무결함"을 사용할 경우 이미지 너비에 대해 너비 기본 설정(220px) 또는 편집자의 너비 기본 설정이 사용되지만, 이미지가 그 너비보다 작을 경우 이미지 너비가 대신 사용된다.SVG를 "thumb" 또는 "framless"와 함께 사용하고 SVG가 폭 디폴트(대부분 220px)보다 작을 때 SVG의 폭은 다음과 같이 사용된다. 다른 영상에 대해서는 이것이 올바르지만, 이는 SVG가 설계한 것, 즉 스케일링에 역행하기 때문에 SVG에게는 부정확하다.그래서 나는 SVG를 다룰 때 이미지 체크는 건너뛰어야 한다고 제안한다. -- 도! 15:21, 2010년 10월 30일 (UTC)[응답]

아이콘은 항상 스텁이나 플래그 템플릿 내에 위치하며, 기사에 추가해야 하는 아이콘은 일반 이미지의 아이콘은 일반 이미지로 연결되지 않는다.만약 누군가가 "소설 속의 로봇은 보통 이것과 같다"에서와 같이 직접적으로 그렇게 하려고 한다면, 그 이미지는 분명히 이 더 높은 크기로 보여질 것이다.MBelgrano (대화) 2010년 10월 31일 (UTC) 14:21 [응답]

bugzilla:1933.나는 그것을 위한 패치가 있지만, 아직 다른 사람들과 이것에 대해 논의할 시간이 없었다.—DJ (대화 • 기여) 2010년 10월 31일 (UTC) 14:24[응답]

구현되었지만 여기서 즐기려면 몇 달이 걸릴 것이다:D —DJ(대화 및 기여) 22:13, 2010년 10월 31일(UTC)[응답]

TorNodeBot

모두 안녕하십니까, 조금 전에 개발한 관리봇, TorNodeBot이 다시 승인을 받기 시작했음을 알리는 쪽지를 올리고자 했다.이 봇은 이전에 시험 승인을 받았으나 필요성이 없어져서 내가 철회했다.최근 TorBlock 확장에 의해 픽업되지 않고 있는 Tor를 남용한 것에 대한 대응으로 나는 다시 승인을 재개한다.어떤 지역사회의 입력도 가장 높이 평가된다.승인을 위한 논의는 위키백과에서 한다.승인/TorNodeBot 2에 대한 Bots/Requests.고마워, 시릭 (질문이나 코멘트?) 2010년 10월 31일 18:18 (UTC)[응답]

SineBot 이전 상태로 되돌리는 중 - 제안

기술적으로 가능한지 모르겠지만 사용자:SineBot을 되돌릴 때? 즉, 동시에 서명한 이전 편집 ** 및 SineBot을 되돌릴 수 있도록 롤백을 유발하시겠습니까?이것은 토크 페이지 반달리즘을 되돌릴 때 유용할 수 있다(관리자와 롤백자가 감시 목록의 반달리즘을 알아차리고 '롤백'을 클릭하는 사이에 SineBot 편집으로 인해 롤백 실패를 한 번 이상 경험했다고 확신한다).단지 사소한 문제일 뿐 - 하지만 유용할 수도 있는 것(이것을 언급하고 싶었는데, 사실)... --쿠르트 모양 상자 (토크) 00:53, 2010년 11월 1일 (UTC)[응답]

Twinkle 롤백은 SineBot과 그 이전의 편집을 모두 올바르게 되돌릴 것이다.위키소프트웨어의 일부인 일반적인 롤백으로 그것을 하는 것은 불행히도 비싸고 연약할 것이다.— 가비아 임머 (대화) 01:28, 2010년 11월 1일 (UTC)[응답]

아, 트윙클이 그렇게 할 수 있는지 몰랐어.꽤 유용하게 들리네.진실에 접근하기 04:16, 2010년 11월 1일 (UTC)[응답]

보관 시 참조 데스크 섹션 헤더 제목 개선

위키백과가 참조 데스크 보관소에 들어가도록 권장하고 섹션 헤더를 개선하여 질문 내용을 더 잘 반영하도록 합시다.그래야 사람들이 질문을 구글에 입력하면 자신의 질문을 반영한 참조 데스크 항목을 찾을 가능성이 높아진다.(예를 들어 참조 데스크는 '낚시에 관한 질문'의 줄을 따라 헤더를 보는 경우가 많지만 첫 번째 문장은 '아칸소 주에서 낚시하기에 가장 좋은 장소는 어디인가'가 될 것이다.위키피디아 사람들이 기록보관소에서 머리말로서 '낚시에 관한 질문'을 우연히 발견했을 때, 첫 문장에 '아칸소 주에서 낚시하러 가기 가장 좋은 곳이 어디인가'로 수정해야 한다.

여기서 내가 제안한 구체적인 구현.
(1) 참조 데스크 페이지가 자동으로 보관될 때마다 보관봇은 헤더 아래에 원래 헤더 제목을 포함한 {{anchor} 템플릿이 자동으로 제공되어야 한다.그렇게 하면, 우리는 원래 헤더에 대한 퍼멀링크를 파괴하지 않는다.
(2) 위키피디아 사람들이 참조 데스크 보관소에 들어가 질문의 섹션 헤더를 수정하여 해당 헤더가 질문의 내용을 더 잘 반영하도록 권장하는 것이 우리의 방침이어야 한다.

생각?user:IP 주소 128.59.179.127 (대화) 07:08, 2010년 10월 31일 (UTC)[응답]

아카이브될 때까지 기다리는 이유는?제목이 모호하면 즉시 수정하십시오.Anomie 31 14:48, 2010년 10월 31일 (UTC)[응답]

그것도 훌륭하지만 수천 개의 보관된 질문들이 있다.보통 우리의 정책은 보관된 페이지를 편집하지 않는 것이고, 그래서 나는 기존 정책의 변경을 제안하는 것이다.AGradman / talk / 2010년 11월 1일 (UTC) 16:23, 1번 편집을 했을 때 주제 페이지가 어떻게 보였는지[응답]

지원:우리가 보통 기록물이나 다른 사람들의 논평 편집을 피하려고 하는 데는 그럴 만한 이유가 있다.그러나, 이 경우 나는 그러한 반대는 더 쉬운 참고의 이점보다 더 클 것이라고 생각한다.소문에 의하면 위키피디아는 엔클로페아디아라고 한다... :-)

일반적으로 보관 파일 편집을 피하는 이유는?사람들이 그것들을 읽지 않기 때문에 혹은 그것이 그 당시에 일어났던 일을 잘못 전달할 수도 있기 때문에?글쎄, 그건 여기서 문제가 아니야마찬가지로 다른 사람의 댓글을 편집하는 오명이 있지만, 다른 사람을 잘못 표현하거나 말을 꼬는 것은 매우 나쁘기 때문이다.이 경우 나는 그 변화가 저자의 본래의 의도를 뒷받침하기 위한 것이라고 생각한다.

하지만, 기록 보관소를 돌아다니는 비교적 지루한 직업에는 충분한 자원 봉사 시간을 얻기가 어려울 수 있다.머리글 텍스트를 더 정확하고 유용하게 편집하는 것은 봇물이 할 수 있는 작업이 아니다. bobrayner (talk) 16:40, 2010년 11월 1일 (UTC)[응답]

위키피디아 토크에서 의견을 구하고자 할 수 있다.참조 데스크.많은 RD 단골들은 쓸모없는 섹션 제목을 고치고 명백한 오자와 오류를 수정하는 등 다른 사람의 게시물을 편집하는 것에 광적으로 반대한다.Staecker (대화) 2010년 11월 2일 16:28, (UTC)[응답]

• 기록 보관소를 오웰리언으로 편집하는 것에 반대한다.Corvus_talk cornix 20:55, 2010년 11월 2일 (UTC)[응답]

비고 불투명한 머리글을 보다 유용한 정보로 만들고 이에 따라 아카이브 검색을 개선하기 위해 Orwellian은 어떤 방식으로 수정하고 있는가?1984년 그런 일은 기억나지 않는다.사실 정반대다.보브라이너 (대화) 22:26, 2010년 11월 2일 (UTC)[응답]

기록물을 편집한다는 것은 그들이 실제 토론의 기록물이 아니라 아직 진행 중인 토론이라는 것을 의미한다.아카이빙을 번거롭게 하는 이유는?Corvus_talk cornix 22:58, 2010년 11월 2일 (UTC)[응답]

그들은 그 당시에 질문에 답했기 때문에 "보관"되었다.이 제안은 검색을 쉽게 할 수 있는 일부 헤더를 변경하여 향후 방문자에 대한 도움을 개선하는 것이다.이러한 방식으로 헤더 수정과 호환되지 않는 "아카이브" 단어에 대한 고정 정의가 있는 경우 다음 네 가지 옵션만 남는다.

• (a) 이름을 " "" 대신 다른 이름으로 변경해야 한다.
• (b) 도움의 한 가지 함의가 라벨과 호환되지 않는 경우, 우리가 덜 도움이 되었을 때 수행한 작업에 적용해야 하는 경우, 사람들을 돕기를 거부해야 한다.
• (c) 페달 답례는 제쳐두고,
• (d) 보관을 중지하십시오.

옵션 D. Bobbrayner(토크) 03:28, 2010년 11월 3일(UTC)[응답]을 선택한 지 한 달 후에 상황이 복잡해 보일 수 있지만, A, C, D 중 어느 쪽이든 나는 괜찮을 것이다.

외부 링크를 새 창 또는 탭에서 열어야 함

나는 이것이 영구적인 문제인지 확실하지 않지만 다른 곳에서 그것을 찾을 수 없었다."외부 웹 사이트" 로고가 있는 외부 웹 사이트에 대한 링크(예: 이 링크: Google.com)는 새로운 브라우어 창이나 탭에서 열어야 한다고 생각한다.내가 하고 싶었던 말은 그게 다야.

그 이유는 매우 간단하다.

• 사용자는 외부 링크를 목적지가 아닌 참고자료로 사용할 가능성이 높다. 그들은 위키백과 기사의 내용에 대한 이해를 더하기 위해 사이트를 방문할 것이다.이것은 외부 출처로부터 정보를 얻은 후, 그들은 아마도 기사를 계속 읽기 위해 위키백과로 돌아가기를 원할 것이라는 것을 의미한다.이것은 원본 기사의 브라우저 공간을 대체하지 않고 새로운 정보 출처(외부 링크)가 새로운 창이면 훨씬 쉽게 할 수 있다.
• 내가 이해한 바로는, 현재 외부 링크에 사용되는 아이콘은 다른 맥락에서 "이 링크는 새로운 창을 연다"는 의미여서, 위키피디아가 이 같은 아이콘을 사용한다는 것은 좀 혼란스럽다.이 이미지 검색에서 "새 창에서 열기" 아이콘 - 버번을 참조하십시오.

이것은 사용자 환경설정을 통한 선택사항이다.그렇게 하려면 계정을 만들어야 할 것이다.→ ROX₪ 18:02, 2010년 11월 1일 (UTC)[응답]

이해는 하지만 이 동작은 기본적으로 설정되어 있고 사용자 선호도에 따라 비활성화되어야 하지 않을까? - 베르반

왜 그런지 이유를 모르겠다.HTML의 기본값은 새 창/탭에서 링크를 열지 않는 것이다. 온라인 상의 임의의 링크 10개를 클릭하는 것이며, 나는 그 중 8개를 현재 창에 열 것이라고 확신한다.계정을 등록하기만 하면 원하는 대로 기본 설정을 지정할 수 있다.→ ROX ₪ 18:10, 2010년 11월 1일 (UTC)[응답]

탭이 있는 모든 브라우저에는 새 탭에서 링크를 쉽게 열 수 있는 방법이 있다.일반적으로 Ctrl 키를 누르거나 가운데 마우스 버튼으로 클릭한다.그러나 링크가 항상 새 탭에서 열리도록 설계되어 있다면, 나는 이것을 재정의하는 빠른 방법을 알지 못한다.새 창에서 강제로 열도록 하는 것도 지나치게 열성적인 팝업 차단을 발생시킬 수 있다.2010년 11월 1일(UTC) 18시 15분 미스터 지맨[응답]

개인적으로, 나는 현명한 Z-man씨가 좋은 점을 지적했다고 생각한다; 만약 독자가 보통 동일한 창/탭을 재사용하는 것이 일반적인 링크 동작일 때 새로운 창/탭에서 여는 사소한 쉬운 선택권을 가지고 있다면, 그러나 그 반대도 아닌 에티켓이 대부분의 인터넷이 그렇지 않을 때 새로운 창을 강요하는 것을 막을 수 있을 것이라고 생각한다.독자가 새로운 창을 원한다면 스스로 쉽게 할 수 있다.보브레이너(토크) 12:59, 2010년 11월 2일(UTC)[응답]

"알고 있었니" 변경

위키백과에서 현재 제안사항:#Change DYK:

• 제안 1: 출력 속도 저하
• 제안 2: 보다 투명한 로그
• 제안 3: 일부 GA DYK 소개

G 삼촌 (토크) 22:17, 2010년 11월 1일 (UTC)[응답]

다음 사항에 대해 논의하십시오.

참조 편집 시 메모 남기기 섹션

헬프 데스크에 있을 때부터 많은 사람들, 특히 신규 사용자가 {{Reflist}}}만 들어 있는 "Reference" 섹션을 편집하려고 하기 때문에 참조 편집에 어려움을 겪는 것을 알게 되었다.본 섹션을 편집하는 분들을 위해 참고문헌을 본문에서 사용하는 곳에서 편집해야 한다는 쪽지를 원하십니까? -- Bk314159 (Talk to what I didn't know) 13:54, 2010년 10월 24일 (UTC)[응답]

또한 최근에는 템플릿 토크에 {{editprotected}}의 요청을 게시하는 경우도 꽤 있다.Reflist 및 Template talk:인용 필요.우리가 미디어위키를 다음과 같이 만들어야 하는지 궁금하다.보호 대상 페이지 익스텐트는 사용하기 쉬운 버튼이나 이와 같은 것을 제공하는 대신 "기사로 돌아가서 거기서 편집하십시오"라고 말할 수 있는 이런 종류의 템플릿을 조건부로 사용한다.Anomie october 15:36, 2010년 10월 24일 (UTC)[응답]

좀 더 복잡하다.WP를 사용하는 경우:LDR, 그러면 참조가 기준 섹션에 있고, 작은 조각이 주 섹션에 있다.대부분의 신규 편집자들은 LDR을 사용하지 않겠지만, 보편적으로 사실이 아닌 노트에 주의하자.--SPHILbrickT 21:51, 2010년 10월 27일 (UTC)[응답]

LDR이든 아니든, 이곳은 결코 편집을 시도할 수 있는 정확한 장소가 아니다.하지만 사람들은 아무렇게나 볶는다.아노미에 22:53, 2010년 10월 27일 (UTC)[응답]

이것은 명백한 단점이 없는 훌륭한 아이디어로 들리고, 비교적 간단한 아이디어도 구현해 보지만, 토론은 사라진 것 같다.왜?알자리아16 (대화) 13:08, 2010년 11월 3일 (UTC)[응답]

나도 좋은 생각이라고 생각해.출처에 관심을 갖는 새로운 편집자들은 금가루와 같지만, 현재의 메커니즘은 직관에 반한다; 그들은 참고문헌 부분을 편집하려고 할 것이고 당황스러운 공허함을 발견할지도 모른다.

템플릿 토크:참조 목록에 다음 헤더가 있음:

이 페이지는 템플리트에 대한 일반적인 토론에 사용된다.위키피디아의 Reflist는 많은 기사에서 사용되는 템플릿을 참조한다.문서에 참조를 추가하는 방법에 대한 자세한 내용은 Wikipedia:출처를 인용하거나 해당 기사의 토크 페이지에 도움을 요청한다.

하지만 차라리 그 문제를 원천적으로 다루고 싶다.보브레이너 (토크) 16:03, 2010년 11월 3일 (UTC)[응답하라]

인용 정크

물리학 기사의 선두에는 인용구가 너무 많다.나는 인용을 금지할 것을 가이드라인으로 제안한다.알렌22 (대화) 14:45, 2010년 11월 3일 (UTC)[응답]

WP:LEADCITE. ---— Gadget850 (Ed) 16:14, 2010년 11월 3일 (UTC)[응답]을 참조하십시오.

모든 새 기사에는 인용문 또는 외부 링크가 하나 포함되어야 함

새로운 기사를 작성하기 위해서는 반드시 하나의 인용 또는 외부 링크, 즉 "존재 증명" 참고문헌이 있어야 한다.의견?----occono (대화) 14:22, 2010년 11월 1일 (UTC)[응답]

자동 메커니즘을 생각하고 있는가?효과가 없을 겁니다. WP:CITE는 어떤 스타일의 인용도 허용하며, 자동화는 모든 인용 스타일을 감지할 수 없다.Jc3s5h (대화) 14:26, 2010년 11월 1일 (UTC)[응답]

그래, 그건 내 생각이었어.음, 그럼 신경 쓰지 마, 내 생각엔.답장 고마워.

궁금해서 그러는데 어떤 스타일의 인용문이 눈에 띄지 않을 것 같아?수동으로 추가한 각주와 ? - Pointillist (토크) 15:03, 2010년 11월 4일 (UTC)[응답] 같은 것

나는 새로운 편집자들이 온갖 종류의 참신한 인용구를 사용하는 것을 보았다.예를 들어, 하버드 대학교의 인용문(또는 하나의 부분)과 같은 것으로 (존 도, "블라흐의 역사", 1991년)이 인라인으로 표시된다.가능한 모든 변종의 탐지를 자동화하는 것은 매우 어려울 것이고, 나는 소싱된 기사를 만들기 위해 진실한 노력을 기울이고 있는 사람들을 물리고 싶지 않다. 보브레이너 (토크) 15:47, 2010년 11월 4일 (UTC)[응답]

유효한 인용의 다른 예로는 모두 책과 영화에 관한 기사인데, 이 기사에서는 기사의 주제가 되는 책이나 영화를 암묵적으로 인용하고 있다.Jc3s5h (대화) 2010년 11월 4일 16:00 (UTC)[응답]

흠, 아무도 '잇티'가 되고 싶어하지 않지만, 기사 작성자들이 더 빨리 참조하는 요령을 익히도록 장려하는 것이 도움이 될 것이다.제작자에게 보내는 (봇?) 메시지가 도움이 되는 말로 전달되었다면, "어쨌든 간에 새로운 글에 기고해줘서 고마워. 나는 글에서 외부 출처에 대한 언급은 전혀 감지할 수 없었으며, 아마도 그들이 포맷된 방식을 인식하지 못했기 때문일 것이다. 이 문제 또는 소싱의 다른 측면에 대해 도움을 받으려면 위키백과를 참조하십시오.소식통을 인용해."픽션 MoS와 영화 MoS는 둘 다 2차 출처를 요구하므로, 출처 작품의 암묵적인 인용문을 무시하는 것도 예외가 될 필요는 없다. - 포인트리스트 (토크) 17:06, 2010년 11월 4일 (UTC)[응답]

봇이 올바른 기사를 비판하는 것은 잘못된 것이다.괄호를 사용하는 기사는 봇이 감지할 수 없는 완전히 정확한 글의 한 예다.너는 너의 생각을 버려야 한다.Jc3s5h (대화) 17:13, 2010년 11월 4일 (UTC)[응답]

개인적으로, 나는 봇이 언급되지 않은 기사를 만든 사람들에게 친절하게 상기시켜주는 것을 기쁘게 생각한다. 만약 규칙이 충분히 관대하게 그려져서 괄목할 만한 것이라도 포함된다면(더 일반적으로: 잘못된 긍정도 드물게 나타날 만큼 관대한 규칙)하지만 그렇게 하려면 누군가 봇을 써야 할 것이다.기술적으로 그 일을 할 수 있는 사람이 아직 없다면. 보브레이너 (대화) 17:45, 2010년 11월 4일 (UTC)[응답하라]

봇에 대한 덜 불쾌한 대안은 특수:참조되지 않은 페이지에 플래그를 표시하는 새 페이지... 잘못된 긍정의 비율은 해당 컨텍스트에서 중요하지 않다(필터를 참조하면 "Notes", "Reference", "Bibliography" 또는 "Works 인용"라는 섹션을 참조의 증거로 받아들일 수 있다).또 다른 단계는 신규 페이지 패트롤러가 새로운 기사를 참조되지 않은 것으로 플래그를 표시할 때마다 작성자의 대화 페이지에 {{Uw-reftene}}을(를) 게시하는 것이다.BTW, 그건 사실 내 생각이 아니야. 나는 인용문을 쉽게 만들고 참조 문화를 더 널리 퍼뜨릴 수 있는 가능성(또는 불가능)에 흥미를 느꼈을 뿐인데, 그래서 이것이 내 눈에 띄었어.어쨌든 고마워 - 포인틸리스트 (토크) 17:59, 2010년 11월 4일 (UTC)[응답]

(od)WP:트윙클에는 Proddding을 위한 "가능한 경우 통지" 상자가 있다.그것은 아마도 참조되지 않은 것으로 페이지를 태그할 때 기사 작성자에게 {{Uw-reftene}}과 유사한 일을 할 수 있을 것이다.Rd232 18:05, 2010년 11월 4일 (UTC)[응답]

대규모 업데이트

위키백과별:Requests__arbitration/Betacommand_2#Community-imped_restrictions 여기에 공지를 게시해야 하는데, 나의 계획은 IP 주소를 사용하는 외부 링크/레퍼런스를 대량 업데이트하여 실제 도메인 이름으로 대체하는 것이다. 한 가지 예: [3]이렇게 하는 주된 이유는 IP 주소는 변경되지만 도메인 이름은 변경되지 않기 때문이다.ΔT 18:49, 2010년 11월 2일 (UTC)[응답]

캐시에 있는 동안 "더 이상 캐시에 저장되지 않음" 메시지를 확인할 수 있다고 가정하지 마십시오.왜냐하면 만약 당신이 하나의 죽은 링크를 다른 죽은 링크 세트로 교체한다면, 이것은 별로 도움이 되지 않을 것이기 때문이다.--SerkOfVulcan (대화) 19:14, 2010년 11월 2일 (UTC)[응답]

"Not in cache"의 예를 들어 보셨습니까? 또한 비활성 링크일 수도 있고 아닐 수도 있습니다, 임씨는 서버가 새 IP 주소를 얻었을 때 끊어지는 것을 방지하기 위해 호스트 이름으로 변환하는 것뿐입니다.이것은 단지 구글일 수도 있고 아닐 수도 있다.내가 처음 마주친 것은 구글이었다.ΔT 19:26, 2010년 11월 2일 (UTC)[응답]

음, 네가 준 정확한 예는 내가 가지고 있는 예야.그 중 하나를 고쳤으나 아직 다른 하나를 쫓지 않았다. --SerkOfVulcan (대화) 19:27, 2010년 11월 2일 (UTC)[응답]

죽어서 참조에 사용된 경우 {{죽음 링크}}와 함께 태그를 지정하면 다른 예는 [4]를 참조하십시오.ΔT 20:05, 2010년 11월 2일 (UTC)[응답]

고마워, 앞으로 나아가는 데 도움이 될 거야.첫 번째 예제의 두 링크가 태그 지정 기준에 부합하는가?--SerkOfVulcan (대화) 20:09, 2010년 11월 2일 (UTC)[응답]

자세한 내용을 보기 위해 샌드박스로 옮겼는데, 처음에 내가 하려던 것보다 더 많이 요청했기 때문에, 임씨는 내 모든 정리정돈에 그것을 넣을 것이다. 그것이 무엇이었는지는 [5]를 참조하십시오.ΔT 20:18, 2010년 11월 2일 (UTC)[응답]

당신은 IP에서 google.com으로 변경하여 세 번째 링크를 깼다.현재로서는 자동화된 실행이 최선의 자동 실행이 아닐 수도 있다고 제안하고 싶다. --SarekOfVulcan (대화) 20:22, 2010년 11월 2일 (UTC)[답글]

어떤 거?세번째는 1993년 인도 입니다.ΔT 20:26, 2010년 11월 2일 (UTC)[응답]

그리고 이제 그것은 나에게도 효과가 있다.이상해. 미안해. --SerkOfVulcan (대화) 20:30, 2010년 11월 2일 (UTC)[응답하라]

좋아, 그렇다면, 왜 데드링크 템플릿은? --SarekOfVulcan (토크) 20:32, 2010년 11월 2일 (UTC)[응답]

나는 구글을 싫어한다. 그래서 구글이 캐시서버로부터 내 IP주소를 차단하는 문제가 무엇인지 알아내는 과정에서...그것이 일시적인 문제인지 아니면 정확히 어떤 문제인지 잘 모르겠어, 그것은 간헐적인 구글 장애와 같은 것일 수도 있어.ΔT 20:52, 2010년 11월 2일 (UTC)[응답]

• 안 될 이유가 없지.→ ROX ₪ 19:16, 2010년 11월 2일 (UTC)[응답]

• 지원 - 그리고 우리가 하는 동안 편집 제한도 버리십시오.부과된 지 2년이 넘었는데, 지금은 무의미하고 비파괴적이다. --알파 쿼드런트 19:28, 2010년 11월 2일 (UTC)[응답]
• 우리는 기사에 구글 캐시 링크를 사용해야만 하는가?Anomie 2 20:19, 2010년 11월 2일 (UTC)[응답]
  • 개인적으로 나는 그렇게 생각하지 않는다. 나는 모든 IP 기반 URL이 WP에 추가되어야 한다고 생각한다.SBL 그러나 그것은 위키들이 해결해야 할 또 다른 논쟁이다. 나의 목표는 IP가 깨지기 전에 도메인 이름으로 변환하는 것이고 우리는 그들이 어디를 가리키는지 알아낼 수 없다.ΔT 20:22, 2010년 11월 2일 (UTC)[응답]
    • 구글 캐시 링크는 나에게 좋은 아이디어로 보이지 않지만, 누군가가 그것을 사용하는 좋은 이유를 가지고 있었기 때문에 나는 그것들을 모두 자동으로 제외하는 것을 경계할 것이다. (구글 캐시 링크를 사용하는 것은 일반적으로 기본 URL을 사용하는 것 이상의 추가적인 조치를 취하기 때문에, 그리고 확실하지 않기 때문에; 편집자가 그렇게 하기로 선택한 어떤 이유가 있었을 것이다) bObrayner (대화) 03:07, 2010년 11월 3일 (UTC)[응답]
• 이 모든 작업을 수행하는 데 있어 내가 우려하는 것은 이미 손을 바꾼 IP 주소뿐이므로 관련 없는 웹 사이트를 가리키는 것이다.IP를 도메인 이름으로 변경해도 수정되지 않으며, 비활성 링크가 아닌지 확인할 수 없다.— 당신을 먹여 살리는 손:^Bite 21:03, 2010년 11월 2일 (UTC)[응답]

• 교체를 시작하기 전에 ip->호스트 이름을 수동으로 검증하는 작업을 하고 있는데 호스트 이름을 식별할 수 없는 IP 주소를 여러 개 발견해 임씨는 그냥 무시했다.ΔT 21:19, 2010년 11월 2일 (UTC)[응답]

• • 좋아, 그럼 난 이걸 전적으로 지지해— 당신을 먹여 살리는 손:^Bite 2010년 11월 4일 (UTC)[응답]
• 위의 코멘트는 내가 생각할 수 있는 유일한 주요 문제야. 비록 나는 그것이 그렇게 전공이라고 생각하지 않는다. 만약 IP가 지금 다른 도메인을 가지고 있다면, 그것은 어쨌든 잘못된 웹 사이트를 가리킨다. 어떻게 해서든 그것은 죽었으므로 때때로 잘못된 긍정을 도메인 이름으로 대체하고 다시 수백 개의 유효한 링크를 수정하는 것이 좋을 것이다.나는 이것을 지지한다, 비록 나는 이것이 자동으로 변환되는 것에 대한 마크업 코멘트가 배치되어야 한다고 생각한다.— HELLKOWZ zTOK 21:16, 2010년 11월 2일 (UTC)[응답]
  • 위의 회신에 따라, 나는 편집자와 함께 그가 동일한 IP의 여러 링크를 수동으로 확인하여 그들이 올바른 위치를 가리키는지 확인한 다음 이 IP의 나머지 발생을 자동으로 대체한다는 것을 명확히 했다.그러니 그때는 내가 볼 수 있는 문제가 하나도 없어.— HELLKOWZ zTALK 21:38, 2010년 11월 2일 (UTC)[응답]

이미지 주석기

나는 이 제안에 대한 의견을 듣고 싶다.독일어 위키백과에서도 시행되었고, 영어 위키백과에서도 시행되어야 한다고 믿는다.--Mbz1 (토크) 16:30, 2010년 11월 3일 (UTC)[응답]

이미지 주석은 이미 Preferences → Gadgets → Browseing 가젯을 통해 사용할 수 있다.만약 당신이 모든 사람들을 위해 주석을 달아줄 것을 제안한다면, 나는 이전에도 그랬듯이 그것에 반대할 것이다.— 가비아 임머 (대화) 19:38, 2010년 11월 4일 (UTC)[응답]

이미지 맵 관련 독서자 참여

이미지 맵은 링크된 오버레이가 있는 이미지(일종의 쿨함)이다.그러나, 그들은 눈에 띄지 않게 될 수도 있다. 이와 유사한 스타일로 {{Image map} 태그를 지원하는 사람이 있는가?ǝɥM0N0 02:54, 2010년 11월 5일 (UTC)[응답]

포럼

여보세요. 기사의 토론 탭에 대해 위키피디아와 관련된 사람에게 연락하고 싶었어.나는 탭들에 섹션들을 올렸고 사람들은 임이 "옳은" 말을 하지 않았기 때문에 나에게 접근해 왔다.그들은 "이것은 포럼이 아니다.이것은 기사에 관한 것일 뿐이오."좋아. 그럼 왜 토론 탭처럼 각 기사에 포럼 탭이 될 수 없는 거지? 사람들이 잘못된 말을 하거나 위키피디아 전문가들에게 떠들어대는 것에 대해 걱정할 필요 없이 그 주제에 대해 정말로 말할 수 있는 곳이야.만약 "토론" 탭의 오른쪽에 "Forum" 탭이 있다면, 주제를 "논의"할 수 있는 더 많은 자유가 있을 것이다.나는 이것이 올바른 사람들에게 전달되기를 바란다.캐시스 손(대화) 21:52, 2010년 10월 19일 (UTC)[응답]

WP:NOT#FORum을 참조하십시오.위키피디아는 백과사전 프로젝트다.인터넷에는 일반적인 주제에 대한 토론을 위한 몇 가지 포럼이 있다.빠른 검색이 뭔가 일어날 겁니다.구글 검색 후 사이드 바에서 토론 옵션을 사용해 보십시오. --n123645 (대화) 15:13, 2010년 10월 20일 (UTC)[응답]

Cathys Son의 제안은 정확히 WP를 약화시키는 것이다.NOT#FORum, 그리고 추가적인 전용 토크 페이지에서 그러한 자유로운 토론을 허용한다.
그렇게 되면 여러 가지 문제가 생기겠지만, 한 가지 장점도 있다.더 많은 사람들이 위키피디아 페이지를 적극적으로 편집하고, 그들 중 일부는 기사를 건설적으로 편집하기 시작할 것이다.아말테아 15:28, 2010년 10월 20일 (UTC)[응답]

과연 포럼형 제도가 지역사회 육성에 도움이 될지 궁금하다.우리는 가끔 신선한 피가 필요하다고 불평한다; 어쩌면 이것이 사람들을 참여시키는 좋은 방법이 될 수 있을까?Wikinews는 Talk 네임스페이스 외에 Comments 네임스페이스를 가지고 있는데, 전자는 주제에 대한 토론(chit-chat)에 사용되고, 후자는 기사에 대한 토론(편집 지향)에 사용되며, 그들에게 상당히 잘 된 것 같다.나는 내가 기사 그 자체만이 아니라 기사의 주제를 토론하기를 원했던 때가 있었다는 것을 인정하겠다; 결국, 위키피디아는 사람들이 당신이 관심 있는 어떤 틈새 주제에 대해 같은 생각을 가진 사람들을 찾을 수 있게 해준다.그것은 백과사전 편집이 아니라도, 여전히 사람들이 위키피디아에 더 적극적으로 참여하도록 하는 것은 나쁜 일이 아니다.EVula // talk // talk // 15:51, 2010년 10월 20일 (UTC)[응답]

나는 Wikinews에서 의견 네임스페이스를 가지고 있다는 것을 안다.위키피디아에 그런 걸 올려놓는 게 편집자가 아닌 사람에 의한 공간적인 분위기를 조장할까 봐 걱정이야.내 생각에 당신이 보게 될 것은 많은 사람들의 이목을 끄는 기사들인데, 다른 것들은 거의 모두 그럭저럭 진행되고 있다.한 가지 주요 이슈는 WP와 같은 정책을 고수하는 것이다.Civil 및 WP:낙태와 이스레일리-팔렌티니아 분쟁과 같은 논란이 많은 기사에 대한 독자들의 NPA. --n123645 (대화) 16:13, 2010년 10월 20일 (UTC)[응답]

나는 많은 사람들이 WP:에스페란자와 같은 오래된 문제들을 꺼낼 것이라고 생각한다.내 생각에는, 주로, 내 생각에는, 의견들이 종종 열띤 논쟁을 일으킬 수 있고, 관리자들이 그들이 '가입하지 않은' 추가 업무를 해야 하는 것에 대해 불평을 하게 할 것이기 때문에, 그런 일은 일어나지 않을 것이다.다른 말로 하자면, 나는 한편으로는 기사의 틀에서 벗어난 주제에 대해 채팅하는 것이 반드시 나쁜 생각은 아니라는 것에 동의하지만, 다른 한편으로는 다양한 이유로 그것이 효과가 없을 것이라고 상상한다.♫ 멜로디아 샤콘네 ♫ (토크) 2010년 10월 20일 16:16, 20 (UTC)[응답하라]

논란이 있는 것으로 알려진 주제(기사의 편집 전쟁 때문만은 아님)는 주요 종교, 진화, 지적설계, 낙태, 동성결혼 등과 같은 포럼 개최에서 제외될 수 있다.그러나 과학적인 개념, 사람, 책, 영화, 언어, 음악, 국가, 취미, 그리고 상대적으로 논란의 여지가 없는 다른 모든 것에 관한 기사들은 토론 포럼에서 이익을 얻을 수 있을 것이다.또한 액상 나사산의 일부 대규모 사용적합성 시험에도 좋은 기회가 될 것이다.그냥 구글처럼 하라: 새로운 기능에 베타라는 딱지를 붙여서 문제가 생기면 예고 없이 언제든 낚아챌 수 있다는 점을 모두에게 분명히 하라. --Morn (대화) 16:44, 2010년 10월 20일 (UTC)[응답]

그것은 WP의 문제를 제기한다."무감각"포럼 페이지를 토크 페이지로 리디렉션하는 것은 독자들에게 혼란을 줄 수 있고, 그러한 이슈들이 디커들에게 받아들여지지 않는다는 통지를 붙이는 것은 적대감을 불러일으킬 수도 있고, 사람들이 이 통지를 무시하고 토크 페이지에서 토론하게 할 수도 있다.일반적으로 어떤 것을 추가하는 것이 그것을 제거하는 것보다 훨씬 더 쉬우며, 그것은 이미지: 네임스페이스와 같이 끈기 있게 우리와 함께 붙어 있을 가능성이 높다.미디어위키는 결코 진정한 포럼이 되도록 설계되지 않았으며, 멜로드라마가 언급했듯이, 실을 잠그는 것과 같은 표준적인 포럼 특징에 문제를 제기한다.액상 나사산은 개선된 것이지만, 궁극적으로 처음부터 미디어위키에 포함되었어야 할 것을 고치려고 하는 것은 해킹이다. --n123645 (토크) 01:57, 2010년 10월 21일 (UTC)[응답]

동의하든 동의하지 않든, 나는 정말로 피드백을 고맙게 생각한다.나는 이것이 백과사전 사이트이지 포럼 사이트가 아니라는 것을 이해한다.하지만 사람들은 정보를 얻기 위해 이곳에 온다.기사에서 찾고 있는 것을 찾지 못한다면, 간단한 질문을 하는 것에 대해 계속적으로 정정되지 않고 어떻게 물어볼 수 있겠는가.다시 말하지만, 이것은 백과사전 사이트지만 대부분의 사람들은 어떤 포럼 사이트가 아니라 답을 얻기 위해 이 사이트에 온다.캐시스 손 (대화) 2010년 10월 20일 19:14 (UTC)[응답]

그것이 바로 우리가 참고 책상을 가지고 있는 이유다.보통 위키피디아 사람들은 새로 온 사람들을 기꺼이 돕는 것 이상이며, 우리는 그것에 대한 정책도 가지고 있다.물림. WP:NOT#FORUM은 기사와 전혀 무관한 것들을 더 토론하는 것에 관한 것이다.For instance if you were to discuss how cute the color of <actor/singer/general famous person x>'s hair is (which on an article like Justian Beber I'd imagine that you'd get alot of) that would be a forumish type of discussion that would be inappropiate for the talk page. --nn123645 (talk) 19:40, 20 October 2010 (UTC)[reply]

새로운 사용자들이 위키피디아 정책을 이해하는지 아닌지는 임씨가 말하고자 하는 요점이 아니다.나는 사용자들이 주제에 대해 자유롭게 말할 수 있어야 한다고 말한다.이 사이트에서 저스틴 비버스의 머리카락이 얼마나 귀여운지, 기록에서 벗어나고, '토론' 코너에서도, 기사에서도 빼놓으면 좋을 것 같다.(FYI: 팬이 아니다) 캐시스 손(토크) 20:18, 2010년 10월 20일 (UTC) 답변 [응답]

요점은 WP가 그것을 위한 장소가 아니라는 것이다."좋겠다"는 많은 것들이 있지만, 온라인에는 대다수의 주제에 대해 "사용자들이 자유롭게 주제에 대해 말할 수 있는" 장소들이 많이 있다.♫ 멜로디아 샤콘네 ♫ (대화) 22:35, 2010년 10월 20일 (UTC)[응답]

Anathea와 Evula는 이런 종류의 것들을 허용하면 결국 편집자가 될 새로운 사용자들을 끌어들이는데 도움이 될 수 있고, 프로젝트는 항상 새로운 손이 필요할 것이다.나는 "정책은 그것을 허용하지 않는다"나 "여기는 그런 곳이 아니다"는 단순한 보수주의로만 머물지 말고, 대신에 이 제안의 중요한 문제점이 무엇인지 논의하기를 제안한다. --MBelgrano (토크) 23:02, 2010년 10월 20일 (UTC)[응답]

글쎄, 그것은 현재 상황이 어떤지 아는 것과 함께 장단점을 보는 것만큼 보수적이지는 않다.나는 이와 같은 것이 사람들을 불러올 가능성이 꽤 있다는 것에 동의한다. 그리고 내가 다른 방법을 모색하지 않거나 혹은 다른 것에 대한 어떠한 반응도 기대하지 않는 흥미로운 대화를 보는 것을 꺼리지 않을 것이다. WP의 개방성으로 인해 사람들이 페이지를 통제하는 것이 매우 쉬울 것이다.es 그리고 사람들을 화나게 한다, 심지어 일반적인 대화 페이지들보다 더.게임faqs와 같은 곳에서 일어나는 불꽃전쟁의 유형, 검열기 필터(주제목에서 '행콕'을 사용할 수도 없고, 때로는 묵직한 모드의 사용도 할 수 없다)와 함께, 누구나 게시물을 '삭제'(복원할 수 있음에도 불구하고), 또는 '논의 종결, 종료'(비유를 하자) 등을 고려할 때...가치 있는 것보다 훨씬 더 큰 문제가 될 수도 있어게다가, 나는 다시 한번 관리자들이 그들이 '서명한' 것이 아닐 때, 조정자를 연기하도록 강요당하는 문제를 덧붙인다.사람들은 백과사전에 대해 이야기할 때 서로에게 예의 바르게 행동하는 데 어려움을 겪는다. 사람들이 그 요구사항을 무시하는 것이 자유롭다면 훨씬 더 나빠질 것이다.♫ 멜로디아 샤콘네 ♫ (토크) 00:20, 2010년 10월 21일 (UTC)[응답]

그리고 나는 더 많은 문제를 생각할 수 있다. 예를 들어, WP:BLP는 모든 네임스페이스에 적용되기 때문에, 우리는 BLP 위반에 대한 포럼을 순찰해야 한다. 하지만 만약 BLP가 포럼에 신청했다면, 나는 어떻게 누군가가 살아있는 사람에 대한 의견을 표현할 수 있을지를 생각할 수 없다.그리고 나는 포럼이 BLP 규칙을 따르지 않도록 하는 것에 상당히 반대할 것이다; 나는 포럼에만 적합한 2차 행동 규칙을 개발하려고 애쓰는 번거로움을 상상할 수도 없다.또한, 우리는 토크와 포럼을 왔다 갔다 하면서 토론을 하게 될 것이고, 그것은 혼란스러울 것이다. (예를 들어, 포룸은 근거 없는 루머를 가지고 있고, 그것은 기사에 포함시키기 위해 토크로 넘어간다. 그리고 그것은 거부되었다. 그리고 어쩌면 출처가 올지도 모른다. 그래서 그것은 되돌아왔다.blah blah blah).마지막으로, 우리는 우리의 임무에 포함되지 않는 것에 대해 서버 사용을 엄청나게 증가시킬 것이다. 우리는 채팅이 아닌 세계의 "지식"을 수집하기 위해 여기에 왔다.그리고 나는 그것이 "새로운 사용자"를 원하는 것이 아니라 우리의 가이드라인 내에서 기꺼이 일하는 새로운 사용자들을 원하기 때문에 새로운 사용자들을 데려오는 아이디어조차 이룰 수 있을지 확신할 수 없다.나는 사람들이 포럼에서 "대화"를 시작하고, 그 다음 그들의 "대화"를 기사로 옮기려고 하는 것을 쉽게 상상할 수 있다. 어떻게 그것이 허용되지 않는지를 배우기만 하면, 그들은 화가 나고, 다른 정보들이 합법적으로 포럼에서 기사로 옮겨갈 때, 그것이 소스화되었기 때문에, 그들은 더욱 더 쓰라릴 것이다.단, ction.마지막으로, 많은 경우에, 포럼은 나쁜 믿음의 편집 카바를 발전시키는 장소가 될 것이다.

tl:dr:우리가 하는 것은 아니고, 나는 그들이 다른 사람들이 유용하다고 말한 목표를 달성하지 못할 것이라고 생각한다.Qwyrxian (대화) 01:11, 2010년 10월 21일 (UTC)[응답]

알았어. 인터넷에 접속할 수 있는 모든 사람과 모든 사람은 기사를 편집하고 "토론" 탭에 글을 올릴 수 있어.그렇게 쉽게 편집이 가능해지면 포럼이나 게시판의 회원들이 어쨌든 이 사이트에 와서 올리고 싶은 글을 올리지 않을까.만약 그들이 할 거라면?특히 등록 사용자도 아닌 경우 누구나 "토론" 탭에 어떤 내용이든 올릴 수 있다.그리고 그들이 정말로 원한다면, 그들은 "토론" 섹션을 일종의 포럼으로 바꿀 수 있을 것이다.나는 많은 기사에서 그것을 보았다.사람들은 어차피 자기가 원하는 것을 말할 텐데, 왜 바로 그 목적을 위한 섹션이 없을까?캐시스 손(토크) 01:50, 2010년 10월 21일 (UTC)[응답]

우리는 사람들이 무엇을 할 수 있는지에 대해 이야기하는 것이 아니라 정책 하에서 허용되는 것에 대해 이야기하고 있다.메인 스페이스나 공공 기물 파손도 마찬가지다.같은 논리로 우리는 반달리즘(Bandalism)을 만들어야 한다. 단지 기술적으로 콘텐츠 정책을 준수하지 않는 것을 게시하는 것이 가능하다고 해서 네임스페이스를 만들어야 한다.어떤 일을 하는 데 방해가 되는 기술적 제한이 없다고 해서 해도 괜찮다는 뜻은 아니다(메인 페이지 삭제 안 함 참조).미디어위키는 디자인에 의한 기술적 제약이 거의 없이 개방되어 있다.정책을 무시한 채 지속적으로 파괴적이고 악의적인 편집을 하는 사람들은 스스로 차단되고 편집이 되돌아가게 될 가능성이 높다(WP:DE 및 WP:GAME). "그것을 위한 정책이 있다"는 사과 슬로건을 훔칠 수 있을 것 같다. --n123645 (대화) 08:15, 2010년 10월 21일 (UTC)[응답]

이것은 좋은 의미지만 궁극적으로 해로운 제안이다.대체로 검증가능성에 대한 생각을 훼손하기 때문이다.위의 주장은 그것이 더 많은 기여자들을 불러올지도 모른다는 것이다; 그것은 흔들릴 것이다.그러나 나의 우려는 그러한 기고자들이 (물론 그들에게 자격이 있는) 그들 자신의 기사 관점을 토론하기 위해 여기 있을 것이고, 우리는 "포름" 타입 토크를 바탕으로 한 기사들에 OR과 의견의 증가를 감수해야 한다는 것이다. --Errrrant [tmorton166] 09:42, 2010년 10월 21일 (UTC)[응답]

그렇기 때문에 롤아웃은 좀 더 고상한 기사부터 시작해야 한다.WP는 저스틴 비버에 관한 포럼보다 웰-성격 클라비에 관한 포럼이 더 유용할 것이다.후자는 이미 다른 곳에 전용 포럼을 두고 있지만, 전자와 같은 보다 구체적인 주제는 그렇지 않다.포럼 토론을 위해 공개되는 기사의 종류는 크게 우리가 어떤 기고자(및 기고자)를 유치하느냐에 달려 있다. --Morn (토크) 10:22, 2010년 10월 21일 (UTC)[응답]

만약 내가 새로운 프로젝트 wikiforum.org을 제안할 수 있다면, 비록 그것을 기존 프로젝트에 어떻게 통합할 것인지는 결정되어야 할 것이다.930913 (축하/불만) 2010년 10월 25일 (UTC) 12시 21분[응답]

이와 관련하여 위키 정책을 위반했을 가능성이 있는 사람으로서, 나는 각 위키 페이지에 포럼을 첨부하자는 제안에 전적으로 동의한다.가장 큰 장점 중 하나는 형식에 집중하지 않고 아이디어를 교환하기 쉽게 하고, 특수 문자를 추가하며, 적절한 들여쓰기를 하고, 모든 것을 기계들이 우리가 성취하려고 하는 것을 이해할 수 있도록 완벽하게 배치하는 것이다.내 Ottawahitech (대화) 11:44, 2010년 11월 1일 (UTC)[응답]

토론

• 진정한 강력한 지원:위키피디아는 일반적으로 꽤 인기 있는 사이트다.더 정확히 말하면, 인터넷에서 가장 많이 방문하는 10대 웹사이트 중 하나이다.나는 항상 인큐베이터에서 Wikimedia Foundation이 소유하고 있는 사이트 네트워크의 일부로 포럼 웹사이트를 실제로 시작하기 위해 새로운 위키(그래, 네가 제대로 읽었구나, 새로운 위키)를 제안하고 싶었다.그러나 나는 그것이 왜 성공할지에 대한 충분한 이유를 찾지 못했다. (위의 제안은 실제로 그것을 시작하려는 나의 계획을 죽일 것이다.)

  캐시스는 현재까지도 위키백과 외부와 내부의 수많은 편집자들이 기사 범위와는 전혀 다른 내용을 토픽 페이지에 게재하고 있다는 사실에 매우 좋은 지적을 하고 있다."Forum" 탭을 추가하는 것은 결국 Wikimedia Foundation을 온라인 포럼에서 정복자로 만들 뿐만 아니라(온라인 백과사전처럼), 많은 수의 사람들을 끌어 모을 수 있을 것이며, 이들 중 상당수는 훌륭한 편집자가 될 수 있을 것이다.

  현재, 위 제안서의 주요 이슈는, 만약 당신이 "Forum" 페이지를 추가하고, 또한 "자유 백과사전" 정책을 따른다면, 나는 위키피디아가 또한 10대 스팸 사이트로 급상승할 것이라고 말하고 싶다.이 문제를 극복하기 위해 우리는 로그인하지 않은 사용자들을 위한 포럼을 비활성화하거나 숨길 수 있다.

  어떤 이유로든, 커뮤니티의 결정은 백과사전과 함께 완전히 발달된 온라인 포럼을 결코 허용하지 않는 것이 아니라, 소수의 위키백과 커뮤니티만을 위한 포럼을 허용하는 것이라면, 우리는 2주간의 성숙기와 100여개의 편집요건을 시행할 수 있을 것이다.편집자, 단지 포럼을 위해 등록하는 사람들을 피하기 위해.

  어느 쪽이든 나는 포럼을 확실히 지지한다.레만⁽⁺⁾ 12:34, 2010년 11월 1일 (UTC)[응답]

• 반대 - 다양한 이유로.BLP는 큰 것이다. BLP 위반이 없도록 포럼 페이지를 순찰해야 할 것이다. (현재 기사 토크 페이지에서는 충분히 형편없다.)우리는 그것을 다룰 충분한 관리자가 없다.다음은 일반적인 논쟁에 대한 관심이다; 여기서의 토론은 기사 내용에 대해 이야기할 때 충분히 가열된다.그것을 주제와 모호하게 관련된 어떤 것에 대해서도 토론할 수 있도록 열어라. 그리고 갑자기 우리는 지속적인 중용을 요구하는 뿔넷 둥지를 갖게 된다. (온라인에 있는 모든 포럼은 중용을 필요로 한다; 변덕스럽지 않은 포럼 스타일의 예를 들어 /b/를 보라) 그리고 우리는 중용을 담당할 관리자가 충분하지 않다.비록 절제된 임무가 관리자 전용 기능이 아니었다 하더라도, 그것은 단지 다른 모든 문제들을 열어준다: 누가 사회자가 되는가?그들은 어떻게 선택되는가?우리에게 필요한 마지막 것은 또 다른 RFA 스타일의 지옥 구멍이다.포럼의 범위를 어떻게 규정할 것인가에 대한 피할 수 없는 논쟁, 무엇이 주제인지, 그리고 "와아 너는 내 게시물을 삭제했다"는 말도 안 되는 헛소리는 하지 않는다.게다가, 편집자들이 온건한 포럼을 갖는 것은 이 곳이 존재하는 전체 이유로부터 시간과 에너지를 빼앗아 간다.스팸 또한 명백한 우려사항이다. 그리고 다시 말하지만, 우리는 단지 그 문제를 해결할 충분한 관리자가 없다.나는 포럼이 더 많은 편집자들을 설득시키지 않을 것이라는 주장을 발견한다; 우리는 포럼에서 이야기하기를 원하는 사람들을 더 많이 포럼에 끌어들일 것이다.만약 당신이 위키피디아와 관련된 포럼을 만들고 싶다면, 당신의 가장 좋은 두 가지 선택사항은 데이터베이스를 당신 자신의 영역으로 분산시키고 당신의 심장의 내용에 맞는 포럼을 가지는 것 또는 당신이 원하는 곳 어디에나 당신만의 포럼 소프트웨어 패키지를 만드는 것이다.그러나 결론은 간단하다.위키피디아는 백과사전이고, 그 목적을 퇴색시키는 것은 단순히 좋은 생각이 아니다.우리는 좁은 범위의 이유를 가지고 있다: 그것은 초점을 제공한다.그 초점을 부드럽게 하는 것은 그 프로젝트의 순손상이다.→ ROX ₪ 12:47, 2010년 11월 1일 (UTC)[응답]

넌 분명 강점이 있어, 의심의 여지가 없어.하지만 중요한 것은, 위의 내 논평에서 캐시스가 말한 것을 상기시키면서, 이미 토크 페이지는 포럼으로 변하는 무언가가 있고, 서든체인지는 모든 IP 코멘트를 계속 검토하지 않는 것 같다.그리고 이것은 더 악화될 것이다. 위키피디아는 성장하고 있다.

WP에서:BLP 문제, 어디까지 가능한지는 모르겠지만, 포럼에 대한 새로운 정책을 만드는 것에 대한 아이디어를 재단에 내야 할까?그 내용은 모니터링이 안 돼, 블라, 블라?우리는 이미 WP를 가지고 있다.NOTCENSORED, 그러니 욕설이나 그와 같은 것들은 문제가 되지 않을 수 있지만, 저작권 위반 업로드나 다른 많은 이슈들을 증가시킬 수 있기 때문에 우리는 거기에 있는 어떤 종류의 이미지 표시도 제한해야 한다.그동안 포럼은 페이스북(주제를 올리고 댓글을 달 수 있는 곳)에서 보듯이 '토론'이나 (누구나 좋아할 것 같지 않은) 하나의 메가 스트림(mega stream) 같은 기능도 할 수 있다.또한 사용자가 부적절한 의견을 하나의 ForumCenter에 보고할 수 있는 범용 "Report" 버튼을 추가할 수 있다(이러한 방식으로 사용자는 관리자가 항상 있는 것이 아니라 필요할 때 관리자에게 전화한다).리퀴드 스레드(LiquidThreads)를 기반으로 할 수 있지 않을까?레만⁽⁺⁾ 13:11, 2010년 11월 1일 (UTC)[응답]

(충돌 편집)이해가 안 되는데, 너는 문제가 더 악화될 것이라고 말하니, 우리 좀 더 속도를 낼 수 있는 경기장을 마련해보자.말도 안 돼.BLP에 대한 WMF 지침은 매우 좋은 이유로 WMF 관점에 따른 어떤 사이트에도 변경되거나 완화될 가능성이 없다고 생각한다.MGodwin이 WMF 법률고문이라는 결정적인 답변을 원하면 MGodwin과 대화하십시오.귀하가 제안하는 ForumCenter의 담당자는 누구인가?우리가 이미 부족한 관리자들?완전히 새로운 문제를 일으킬 수 있는 잠재적 무리들?어떤 식으로든, 포럼의 아이디어는 관리자 또는 준관리 진행자의 수를 늘리지 않고 관리 책임을 증가시킨다(어쨌든 사용자가 편집하는 것을 차단할 수 있는 기능이 필요하므로 관리자가 되어야 함을 의미한다).→ ROX₪ 13:19, 2010년 11월 1일 (UTC)[응답]

사실 이건 제안이야 아직 실행되지 않았다는 뜻이지그렇다, 이 제안은 다른 새로운 개발들처럼 작업량을 증가시킬 것이다."관리자 부족" 또는 "효율적이지 못한 관리자"는 이 토론이 아닌 다른 곳에서 다뤄져야 한다.레만⁽⁺⁾ 13:32, 2010년 11월 1일 (UTC)[응답]

불충분한 행정관은 (어쨌든 내가 반대하는) 이 제안이 원점에서 벗어나기 전에 내가 반대한다.늘어난 업무량과 이를 어떻게 처리할 것인가를 해결해야 한다.→ ROX ₪ 13:38, 2010년 11월 1일 (UTC)[응답]

내가 본 거의 모든 "포름다운" 토론은 파괴적/침해적 등이었다.나는 그것을 격려하기 위한 지속가능한 것으로 보지 않는다.특히 일반적인 대화 페이지와는 완전히 다른 규칙을 필요로 하기 때문이다(적절한 "모더레이션"을 허용하기 위해).우리는 이미 대화 페이지에서 POV에 대해 충분히 문제가 있는데, 왜 그것을 장려하는가! --Errrant [tmorton166] 13:14, 2010년 11월 1일 (UTC)[응답]

음, 좋게 되려면, 우리는 악을 좀 풀어줘야 해.만약 포럼이 실행되려면 우리는 새로운 정책을 고려해야 한다.레만⁽⁺⁾ 13:32, 2010년 11월 1일 (UTC)[응답]

이는 일리가 있는 말이 아니다, "마을을 파괴해야만 구했다." → ROX ₪ 13:38, 2010년 11월 1일 (UTC)[응답]

나는 토크 페이지가 포럼으로 전환되고 있다는 레만의 관찰을 볼 수 있을지 잘 모르겠다.오히려 포럼형 질문/토론은 예전보다 줄었다.나는 내가 정말 인기 있는 페이지를 대부분 보지 않는다는 것을 인정하지만, 나는 종종 그 날의 FA를 시청하고 거기서 그것을 거의 보지 못한다.내가 보고 있는 것에 그런 질문/댓글이 추가되는 시간의 절반은 어차피 주제에서 벗어난 것으로 삭제된다(더 이상의 불평 없이).♫ 멜로디아 샤콘네 ♫ (대화) 13:43, 2010년 11월 1일 (UTC)[응답]

제한된 관찰자, 논란이 되는 주제가 쟁점이라면 포럼 특집 기사의 양을 제한할 수도 있다.기사를 훑어보거나 특집기사를 갖기에 적합한 기사로 투표했다면, 그들은 그것을 가질 것이다.이들이 종교나 낙태와 같은 민감한 주제라면 '토론' 탭만 갖게 된다.캐시스 손(대화) 03:19, 2010년 11월 2일 (UTC)[응답]

그리고 어떤 기사가 어떤 기사를 쓸지 누가 결정하겠는가?그리고 어떻게?내 생각에, 그리고 나는 모욕적인 말을 하지 않고, 당신은 이 주변에서 매우 새로운 사람임에 틀림없고, 따라서 위키백과 편집자들이 싸우기 위해 찾게 될 진정으로 정신적으로 미친 것들에 익숙하지 않을 것이다. (WP: 참조)몇 가지 훌륭한 예에는 LIM)이 있다.이 전체 제안은 어떠한 종류의 순이익도 표시하지 않고 다수의 새롭거나 악화되는 문제를 야기한다.→ ROX ₪ 03:23, 2010년 11월 2일 (UTC)[응답]

Wikia에는 포럼 네임스페이스가 있지만, 포럼은 일반적으로 각각의 Wikia의 주제를 다루기 때문에 좀 더 관리가 가능하다.약간. 그렇다고 해도 좀 너무 산만해서...무작위 논평자들에게 너무 쉽게 욕을 먹는다.포럼을 유지하기 위해서는 시간과 자원이 필요하며, 결국 가장 좋은 일이 될지는 잘 모르겠다. 서지컬러맨틱15 03:37, 2010년 11월 2일 (UTC)[응답]

그래, 뭐로부터 '불신'을 받았어기사?그 주제에 대한 토론회가 언제인가?나는 포럼이 어떻게 무작위로 논평하는 것을 지금보다 더 나쁘게 만들 수 있는지 모르겠다.포럼이 있든 없든 간에, 누구나 여전히 그렇게 할 수 있는 똑같은 자유를 가지고 있는 것을 보는 것이다.포럼은 기사를 편집한다는 목표에서 산만하게 하지 않을 것이다. 다시 말하지만, 그것은 포럼의 주요 목적이 아닐 것이다.그 포럼은 완전히 분리된 섹션이 될 것이다.누군가 전에 말했듯이, 인터넷에는 많은 주제를 다루는 포럼들이 많이 있다.수천 개의 포럼과 포럼을 기반으로 한 인터넷 사이트들이 있다.나는 그 같은 포럼을 하는 많은 진행자들이 위키피디아에 관한 포럼에서 일하는 것을 매우 좋아할 것이라고 확신한다.여기서 하면 뭐가 그렇게 힘들까?캐시스 손(토크) 17:44, 2010년 11월 2일 (UTC)[응답]

우리는 지금 우리가 하는 말을 귀담아듣지 않고 있는 지경에 이르고 있다.위키피디아가 이 제안을 통해 얻는 순이익을 증명하는 것도 아니고, 우리가 왜 여기 있는지, 그리고 우리가 무엇을 하는지에 대한 직접적인 왜곡을 보여주는 것도 아니다.이 a)가 왜 작동하지 않는지, 그리고 b)는 정책과 사명에 완전히 반대되는지에 대해 실제로 만들어지고 있는 점에 대해 직접 답변해 주시겠습니까?→ ROX ₪ 17:49, 2010년 11월 2일 (UTC)[응답]

포럼이 안 될 이유가 없다.난 네가 무슨 말을 하는지조차 모르겠어.포럼을 가질 때의 유일한 이점은 사용자가 주제에 대해 자유롭게 말하는 것이다.내가 보기에 이 생각이 "안 먹힐 것"인 유일한 이유는 그것이 깨지는 정책들 때문인 것 같다.나는 이 특정 기능이 그러한 경계선을 가지지 않기를 원하기 때문에 이 정책들을 무시한다.그것이 지금까지 나의 목표였다.캐시스 손(토크) 18:28, 2010년 11월 2일 (UTC)[응답]

사실 많은 이유가 있다.내가 몇 개를 열거했는데, 너는 아직 그 문제들이 어떻게 극복될 수 있는지 보여주지 못했다.→ ROX ₪ 18:29, 2010년 11월 2일 (UTC)[응답]

정책을 다루지 않고 이러한 문제를 나열할 수 있는 방법이 있는가?캐시스 손(토크) 19:05, 2010년 11월 2일 (UTC)[응답]

위의 내 의견을 읽어라.그리고 아니, 나는 정책을 무시하지 않을 것이다; 당신은 포럼 능력을 더하기 위해 정책을 바꾸는 데 있어 순이익이 있다는 것을 증명해야 한다.그냥 손으로 흔들어 버릴 수는 없어.생활인 정책은 여러분이 다루어야 할 가장 중요한 것이며 어떤 상황에서도 무시할 수 없다; 그것은 위키미디어 재단의 지시사항이다.→ ROX ₪ 19:09, 2010년 11월 2일 (UTC)[응답]

이것은 그 특색을 갖도록 기사를 승인하는 발상일 것이다.BLP에서 제안된 경계선을 넘는 기사는 포럼을 가질 수 없다.캐시스 손(토크) 02:13, 2010년 11월 3일 (UTC)[응답]

요점을 놓친 것 같은데...자, 오프라 윈프리.모든 사람들이 오프라를 사랑한다.당신은 그녀의 기사에 대해 포럼에서 BLP를 위반하는 사람들을 어떻게 처리할 것을 제안하는가?아니면 불가사리에 대한 포럼?수백만 개의 기사로 어떤 기사와 그렇지 않은 기사에 대해 어떻게 결정하겠는가?우리가 왜 여기 있지 않은지(특히 이 부분) 뿐만 아니라 우리가 여기 있는 이유 전체를 어떻게 다루고 극복하는가?당신은 어떻게 우리가 중재자를 찾아서 고를 것을 제안하는가? (Hint: 당신은 다른 웹사이트의 무작위 중재자들에게 와서 그것을 하도록 요청할 수 없다; 그들은 그들 자신의 고민거리가 있다; 만약 그들이 이미 위키피디아 사람들이 아니라면, 위키피디아 문화를 이해하지 못할 것이다)?어떻게 진행자에게 삭제 및 차단 권한을 부여할 것을 제안하십니까?스팸 메일은 어떻게 처리할까? 그리고, 아, 방금 네 기부금을 살펴봤어.나는 당신이 여기서 선의로 행동하고 있다고 생각하는 실수를 저질렀었다. 당신이 허락되지 않았다는 말을 들은 후에 위키피디아를 포럼으로 사용할 수 있기를 원하는 것으로 밝혀졌다.나는 이것을 더 이상 즐길 이유가 없다고 본다.→ ROX₪ 11:58, 2010년 11월 3일 (UTC)[응답]

루스, 나는 당신이 "나는 당신이 여기서 선의로 행동하고 있다고 생각하는 실수를 했다; 당신이 허락되지 않았다는 말을 듣고 위키피디아를 포럼으로 사용하고 싶어한다는 것이 밝혀졌다. 나는 이것을 더 이상 즐길 이유가 없다고 본다"고 말했다.예의 바르게 행동해야 한다는 것을 명심하십시오.다른 사용자들이 캐시에 대해 말하는 것은 그가 이 제안을 실행할 때 가지고 있는 자유를 조금도 바꾸지 않는다.존경심을 가지고.레만⁽⁺⁾ 12:41, 2010년 11월 3일 (UTC)[응답]

이것은 다른 사람들이 캐시에 대해 말한 것과 아무 상관이 없다; 기여도를 보라:캐시스는 두 개 이상의 기사 토크 페이지를 포럼으로 사용하려고 노력했고, 그것이 허용되지 않는다는 말을 들었다.그리고 그렇게 말했을 때 반응이 좋지 않았다.이 모든 제안은 본질적으로 "내가 원하는 것을 할 수 있도록 모든 것을 바꾸고 싶다"는 것이지 백과사전을 실제로 개선하려는 어떠한 시도도 아니다.→ ROX ₪ 13:04, 2010년 11월 3일 (UTC)[응답]

• 반대, 경찰에게 훌륭한 행정관이 부족한 상황에서, 이런 포럼은 재앙이 기다리고 있다. -- 도! 12:39, 2010년 11월 3일 (UTC)[응답]
• 진정한 강력한 지원:내가 위키피디아가 각 페이지에 토론 포럼을 추가해야 한다고 믿는 이유는 위키피디아가 현재 다른 어느 곳에도 존재하지 않는 필수적인 서비스를 중앙집중화된 형태로 제공할 것이고, 그렇게 함으로써 위키피디아 사람들의 순위를 높이는 데 도움이 될 수 있기 때문이다.예를 들어 우체국에 불만족스러운 모든 사람들을 생각해 보라.한자리에 모여 '공포' 이야기를 주고받는 게 그들에게 좋지 않을까.아니면 누구의 집을 압류하고 있는 사람들인가?아니면 항공사를 상대하는 나쁜 경험이 있는 사람들?- 계속.그렇다, 허위보고도 있겠지만, 문명화되고 생산적인 분위기 속에서 사람들이 토론에 참여하고 그렇게 하는 UNMODERATED 포럼이 많이 존재한다.물론 우체국, 은행, 항공사, 또는 당신이 있는 사람들을 포함한 모든 사람들이 그들의 의견을 듣는다면 도움이 될 것이다.어떤 기관들은 심지어 밀실 뒤에서 각각의 개별적인 불평을 별도로 처리하는 대신에 고객이 공공장소에서 해야 할 말을 들을 수 있는 기회를 높이 평가할 수도 있다.오타와히텍 (토크) 2010년 11월 5일 (UTC) 19:49 [응답]

• 포럼 페이지는 관련 주제에 대해 토론하고자 하는 편집자들에게 편리하겠지만, 이것은 백과사전 그 자체를 개선하는 것과 거의 관계가 없다.진실되고 자극적인 논의를 끌어들이는 주제가 너무 적고, WP가 논쟁할 공간이 더 필요하지 않다고 생각한다.나는 오히려 사람들이 WP를 밀지 않는 것을 본다.NOTFORUM을 실시하고, 관련 없는 논의를 시작하거나 이에 대응할 때 어느 정도 선의의 태도를 취한다.— HELLKOWNZ ▎토크 13:36, 2010년 11월 3일 (UTC)[응답]

그러한 "공헌"의 대부분은 내가 내 사용자 이름을 시작했을 때 (내가 13살 때)이다.마지막 "기여"는 내가 여기서 내 생각을 제안하도록 영향을 준 것이다(그리고 아니, 나는 그 상황에 대해 그다지 성숙하게 행동하지 않았다).내가 하고 싶은 일을 하기 위해 모든 것을 바꿀 필요는 없다, 나는 무엇이든 할 수 있다/할 수 있다(마지막 기고에서 보듯이).나는 위의 글에 동의한다.나는 특정 사람들이 여기 있는 사람들을 바로잡는 것으로 취미를 만들고 그들이 그런 힘을 갖지 못하는 포럼으로 그들은 별로 할 일이 없을 것이라고 믿는다.지금 그걸 가질 순 없잖아, 안 그래?캐시스 손(토크) 15:01, 2010년 11월 3일 (UTC)[응답]

한숨. 그건 왜 이것이 나쁜 생각인지와 아무 상관이 없다.왜 이것이 나쁜 생각인지에 대한 많은, 많은 이유들이 당신에게 주어졌다.우리가 마음을 바꾸기를 원한다면, 실제로 우리가 만드는 요점에 대응해야 하고, 손으로만 흔들거나 무시해서는 안 된다.다시 한 번 말하지만:모든 사람들이 오프라를 사랑한다.당신은 그녀의 기사에 대해 포럼에서 BLP를 위반하는 사람들을 어떻게 처리할 것을 제안하는가?아니면 불가사리에 대한 포럼?수백만 개의 기사로 어떤 기사와 그렇지 않은 기사에 대해 어떻게 결정하겠는가?우리가 왜 여기 있지 않은지(특히 이 부분) 뿐만 아니라 우리가 여기 있는 이유 전체를 어떻게 다루고 극복하는가?당신은 어떻게 우리가 중재자를 찾아서 고를 것을 제안하는가? (Hint: 당신은 다른 웹사이트의 무작위 중재자들에게 와서 그것을 하도록 요청할 수 없다; 그들은 그들 자신의 고민거리가 있다; 만약 그들이 이미 위키피디아 사람들이 아니라면, 위키피디아 문화를 이해하지 못할 것이다)?어떻게 진행자에게 삭제 및 차단 권한을 부여할 것을 제안하십니까?스팸 메일은 어떻게 처리하는 게 좋을까?당신이 실제로 선의로 행동하고 있다고 믿기를 원한다면, 백과사전을 개선할 것이라고 생각하는 것을 제안할 필요가 있다.그리고 다른 것들부터 시작해보자.→ ROX ₪ 15:07, 2010년 11월 3일 (UTC)[응답]

그래. 오프라 윈프리는 살아 있는 사람이어서 그녀의 기사는 분명히 특집기사가 없을 거야.다른 기사에 대한 언급에 대해서는 "토론" 탭에서와 같은 방식으로 다루어질 것이다.종교, 성, 생활자, 낙태 또는 동성애자 권리와 같은 민감한 주제에 기반하거나 관련된 기사는 포럼을 가질 수 없을 것이다.따라서 제안된 주제와 관련된 기사의 양을 고려하여 포럼의 양을 제한한다.다른 기사에 대한 언급도 "토론" 탭에서와 같이 다루어질 것이다.기사는 투표로 결정되거나 관리자에 의해 포럼이 허용될 것이다.그리고 투표를 통해 그들은 또한 자발적으로 포럼의 진행자가 된다.책임감을 원하지 않거나 포럼을 조정하는 데 익숙하지 않은 관리자를 고려하여 포럼의 양을 더욱 제한.이 제안이 가진 유일한 베니피트는 위키백과 기사의 기초가 되는 주제에 대한 오락적 대화의 자유다.

위키백과의 기존 특징인 "토론" 탭을 참고한다.캐시스 손(토크) 23:43, 2010년 11월 3일 (UTC)[응답]

다시 말하지만, 그 중 어느 것도 실제로 실현 가능한 것은 없으며, 위키피디아 사람들이 '민감한' 것을 발견할 수 있는 광대한 다양성을 여러분은 모르고 있는 것 같다. (심각하게, 그것은 매우 놀랍다.)그러나 요약하자면, 이 제안은 백과사전을 개선하는 데 아무런 도움이 되지 않으며, 따라서 단순히 일어나서는 안 되며, 앞으로도 일어나지 않을 것이다.→ ROX ₪ 23:46, 2010년 11월 3일 (UTC)[응답]

그럼 자유롭게 대화하는 게 나아진 게 아니란 말씀이세요?캐시스 손(토크) 23:51, 2010년 11월 3일 (UTC)[응답]

정말로 위키백과 기사를 토론의 출발점으로 삼아 포럼을 시작하려는 의도가 있다면, 가서 해라!포럼 소프트웨어를 설치하고, 개별 스레드 주제의 "초기 게시물"로 기사를 쓸 수 있도록 하고, 사람들이 토론할 수 있도록 할 수 있다.콘텐츠는 모두 크리에이티브 커먼즈(Creative Commons) 라이센스를 받았기 때문에 귀속 요구 사항을 준수하기만 하면 괜찮다.아무도 위키백과 기사에 대한 포럼을 기초로 할 수 없다고 말하지 않고 있고, 나는 그것이 정말 흥미로운 프로젝트가 될 것이라고 생각한다.하지만 그것은 이 프로젝트를 위한 것이 아니다.그래서 그렇게 좋은 생각이라고 생각되면 가서 하면 되잖아.여기 있는 데브들이 자네를 위해 쓰고 관리들이 자네를 위해 감시하는 건 아닐 거야하지만 그렇게 좋은 생각이라면, 그런 일을 돕는데 관심이 있는 사람들을 주선해 줄 수 있어야 해.세라핌블레이드 23:55, 2010년 11월 3일 (UTC)[응답]

나는 그것이 백과사전을 개선하는 데 아무런 도움이 되지 않으며, 온건한 데 걸리는 방대한 시간과 관심을 감안할 때, 거의 틀림없이 적극적으로 백과사전을 해칠 것이라고 말하고 있다.예를 들어 메타필터를 보십시오.수만 개의 사용자 기반에서 활성 사용자 기반, 그리고 훨씬 더 적은 페이지까지 계속 감시해야 한다.풀타임(이것은 그들의 유급 업무) 진행자가 세 명 있다.그리고 그들의 절제하는 스타일은 매우 가볍다. 게다가 그들은 Checkuser 권한과 동등한 권한을 가지고 있고 문제가 되기 전에 문제가 되는 사용자들을 차단할 수 있다.여기서 요구되는 절제된 스타일은 매우 무겁고, 시간과 인격을 훨씬 더 많이 필요로 할 것이며, 우리가 왜 여기 있는지, 즉 백과사전을 만드는 것의 전체 요점에서 탈피한다.당신이 인용하는 유일한 장점은 레크리에이션이다.그것은 백과사전을 만드는 데 기여하지 않는다.나는 솔직히 어떻게 너에게 그것을 더 명확하게 할 수 있는지 모르겠다; 이 사이트는 하나의 목적과 오직 하나의 목적만을 가지고 있다.당신이 마음껏 말할 수 있는 수천의 많은 사람들이 있다.심지어 자신만의 것을 만들 수도 있다.일어나지 않을 일은 위키피디아 프레임워크의 일부가 되는 것이다.→ ROX ₪ 23:59, 2010년 11월 3일 (UTC)[응답]

The End Cathys Son (talk) 00:05, 2010년 11월 4일 (UTC)[응답]

나는 이 토론/제안이 오래 전에 죽었다는 것을 알지만, 이 논쟁에서 어느 시점이든, 왜 이것이 언급되지 않았는가?WP:LiquidThreads Cathys Son (talk) 00:26, 2010년 12월 21일 (UTC)[응답]

왜냐하면 그것은 백과사전을 실제로 개선시키는 토론을 보여주는 형식이고, 그들이 단순히 맞지 않는 곳에 포라를 넣는 방법이 아니기 때문이다.→ ROX ₪ 03:39, 2010년 12월 21일 (UTC)[응답]

"LiquidThreads는 토론 페이지를 실제 포럼으로 대체한다."모든 기사 토론 탭이 포럼의 형식으로 전환되면서, 정책이 시행되기는 더 어려워질 것이라고 말하지 않겠는가?그리고 여기 저기 특정 기사들, 혹은 특징에 대해 이야기 하고 있었을 뿐이지만, 그것은 실제로 모든 기사의 토론 탭을 포럼으로 대체하고 심지어 민감한 주제에 대한 토론으로 대체한다.이것은 내 소품보다 기사에 더 많은 피해를 줄 것 같다.캐시스 손(토크) 07:21, 2010년 12월 21일 (UTC)[응답]

도시

믿을 수 없을 정도로 복잡한 상황에 대한 짧은 제목.나는 이 주제에 대해 한 걸음 한 걸음 내딛기 시작했는데, 반응이 엇갈렸다.일부 사람들은 그 기사에 참고자료가 없더라도 도시 기사를 삭제하는 것을 싫어했다.그들의 주된 주장은 "결과"와 "언젠가 누군가가 기사를 확장하고 싶어할지도 모른다는 사실"이었다.기사를 보관하는 것에 반대하는 주장들에는 우리가 출처를 찾을 수 없다면, 그 장소는 백과사전에 포함될 만큼 충분히 눈에 띄지 않는다.

나의 제안은 도시나 법인체에 관한 새로운 기사들을 적어도 하나의 참고자료를 갖도록 요구하는 것이다.나는 또한 비소싱 BLP PROD를 좋아하는 스티키 프로드를 제안한다. (특정 날짜 이후에 만들어진 기사에만 해당)어떠세요?--인텔라티^talk 01:51, 2010년 10월 31일 (UTC)[응답]

나는 정보원을 요청하면 기쁠 것이다.하지만, 그것은 그렇게 간단하지 않을 수도 있다.

내가 이해한 바로는 이러한 정착 기사들 중 아주 많은 수가 오랜 시간 지루한 관보나 인구 조사를 읽은 어떤 봇에 의해 만들어졌다는 것이다.만약 그렇다면, 관보나 인구조사에서 출처가 분명해?그것이 항상 작성 당시 기사에 추가되는지 아닌지는 또 다른 질문이다. 아마도 어떤 출처나 다른 것에 기초하여 만들어진 그러한 정착 스텁들이 매우 많겠지만, 현재 기사에 어떠한 참고 자료도 없는 것이다.그런 것들을 일괄적으로 도입하는 것은 많은 소음을 발생시킬 가능성이 있다.;-)

보브레이너 (대화) 02:17, 2010년 10월 31일 (UTC)[응답]

BLP Prod와 비슷하게, 내 말은 제안이 발효된 후에 만들어진 기사에만 적용된다는 뜻이다.비소싱 BLP 문제와 같은 유사한 프로세스를 다른 프로세스에도 적용하십시오.

소싱됨으로써는, 어떻게 해서든 검증 가능한 출처와 연결됨을 의미한다.--인텔라티^talk 02:20, 2010년 10월 31일 (UTC)[응답]

• 나는 도시에 대해 WP:N의 어떤 표준도 사용할 이유가 없다고 본다: 도시 자체와 독립적인 복수의 신뢰할 수 있는 출처에서 주제에 대한 직접적이고 상세한 검토.나는 우리가 발견하지 못한 원천이 존재할지 모른다는 것에 개의치 않는다.나는 사람들이 원천이 존재할 가능성이 높다고 믿든 상관하지 않는다.기사를 작성하기 전에 여러 개의 독립적인 출처를 찾아야 한다.나는 또한 인구조사나 지도상의 점(또는 지리적 데이터베이스에 있는 항목의 사이버 등가)의 항목이 주제에 대한 직접적이고 상세한 조사를 구성하지 않는다는 것도 분명하다고 생각한다.—Kww(토크) 02:40, 2010년 10월 31일 (UTC)[응답]

WP:N은 WP가 아니다.GNG. WT에서 논의 중인 바와 같이:시 기사에 대한 합의는 무엇인가? 시 자체에서 독립된 여러 신뢰할 수 있는 출처들은 도시에 대한 독립된 기사에 대해 요구된 적이 없다.patsw (대화) 03:17, 2010년 10월 31일 (UTC)[응답]

항상 그랬어야 했다.GNG는 정당한 이유 없이 우회했고, 그럴 만한 충분한 이유가 남아 있지 않다.도시 자체와 독립된 복수의 신뢰할 수 있는 출처에서 주제를 직접 상세하게 검토하는 것은 비록 과거에 포함 기준을 갖추지 못했더라도 적용해야 할 기준이다.—Kww(대화) 03:56, 2010년 10월 31일 (UTC)[응답]

그냥 우회하는 게 아니라많은 것들이 모든 기사가 GNG를 통과해야 한다는 명확한 요구사항이 있기 전에 만들어진 것들이기 때문에, 그것들을 만든 사람들이 선의로 행동하지 않았다고는 말하지 않을 것이다.하지만, 그들이 그곳에 있다는 것은, 그들 중 많은 수가 GNG를 망친다는 것이고, 따라서 정리가 필요하다.나는 "예시 카운티 내 장소 목록" (또는 해당 국가의 유사한 행정 구역)을 만들자고 제안하는 경향이 있는데, 인구, 좌표 등을 위한 표와 함께, 지리적 거점에 대한 주요 내용을 담고, 그리고 나서, 정말로 주목할 만한 장소 기사에 대해 허심탄회하게 말한다.비고지 플레이스 기사는 목록으로 리디렉션할 수 있다.세라핌블레이드 09:49, 2010년 10월 31일 (UTC)[응답]

"도시 자체로부터 독립된 자원"이란 무엇을 의미하는가?도시는 차고 록 밴드나 아마추어 배우들처럼 "공신력을 얻을" 필요가 없고, 도시는 단지 그들의 존재만으로도 눈에 띈다.통계적 수준(인구, 소득 또는 기타 등)에서라도 우리는 항상 그에 대한 정보를 제공할 수 있는 원천을 찾을 수 있을 것이다.현지 언론도 그 도시의 누구와 어떻게 룰을 정하는지, 도시개발 등에 관한 정보를 찾는 데 도움이 될 것 같다.그리고 단지 도시 출신이라고 해서 그들이 그것에 의존하고 있다는 것을 의미하지는 않는다(공신력 기준에서 의미하는 의미), 그렇지 않으면 우리는 지구나 인간에 관한 기사를 가질 수 없었다.

어쨌든 도시에 관한 비소급 기사를 삭제한다면, 우리는 공신력 가이드라인에 대한 기술적 제한적 해석 후 주목할 만한 것에 관한 기사가 삭제될 때 발생하는 문제에 직면하게 될 것이다: 다른 누군가가 그 기사의 결함을 알아차리고 (록밴드나 아마추어 기사와는 달리) 그 기사의 결함을 다시 쓰게 될 것이다.대상자 자신 또는 가까운 사람 이외의 다른 사람이 고려하는 것).모든 삭제 과정이 무의미해질 것이고, 이것은 확실히 사람들에게 참고자료를 추가하도록 격려하는 매우 나쁜 방법이다.MBelgrano (대화) 13:56, 2010년 10월 31일 (UTC)[응답]

우리 제발 용어가 맞으면 안 될까?우리는 도시, 마을, 교외, 마을, 햄릿, 또는 일반적으로 모든 정착지를 말하는가?그 질문은 수사적인데, 왜냐하면 이미 어디선가 모든 거주지가 사실적으로 주목할 만한데, 특히 영국의 OS 지도에 나타난다면, (그것을 파헤칠 시간이 없었다) 동의가 있기 때문이다.그럼에도 불구하고 정글 속 공터에 있는 포레스터 오두막에서 선을 그어야 할지도 모른다. --쿠드풍 (토크) 14:11, 2010년 10월 31일 (UTC)[응답]

그래, MBelgrano, 내 말은 지리적 장소와 연결되지 않은 사람들은 그것에 대해 쓸 필요가 있어. 단지 인구 조사 자료만이 아니라.독립적인 독립형 기사를 얻으려면 그 장소의 일부 측면을 합리적으로 심도 있게 논의할 수 있는 출처가 있어야 하며 이는 단지 상공회의소 발표일 뿐만이 아니다.WP:V는 논문이 주제와 무관한 출처에 근거할 것을 요구하고 있으며, 지리적 위치는 해당 요건에 대한 면역이 없다.하지만 세라핌블레이드가 지적하듯이, 아마도 해로울 의도는 아니었을 것이다.—Kww(대화) 15:30, 2010년 10월 31일 (UTC)[응답]

MBelgrano의 요점을 다시 읽었으니까, 더 명확하게 해두자세한 내용은 MBelgrano의 요점을 다시 읽어 보았다.일반적으로, 나는 지역 신문들이 도시에서 독립적이라고 생각한다.내가 우려하는 것은 상공회의소 공개나 한두 명이 소유한 작은 마을의 홍보에 더 해당될 것이다.여기서 우리가 가지고 있는 문제는 지도상의 얼룩무늬만 있는 도시들인데, 그 도시들 중 독립된 신문이 발견되는 곳은 많지 않을 것이다.—Kww(대화) 16:00, 2010년 10월 31일 (UTC)[응답]

무언가가 "지도상의 한 점"인지 아닌지는 당신이 어디에 있느냐에 달려 있다.그곳에 가면 티끌보다 훨씬 더 많은 것을 발견할 수 있을 것이고, 그 곳에 대한 실질적인 정보를 담고 있는 지방 서적과 신문도 거의 확실히 있다.우리는 사람들이 와서 기사에 정보를 추가하기 시작할 때까지 참을성 있게 기다리면 된다.도시는 명예훼손으로 고소하지 않을 것이기 때문에, 우리는 BLP 기사에 대한 특별 대우의 배후에 있던 문제들은 가지고 있지 않다.사실, 나는 이 토론들이 어떤 문제를 해결해야 하는지 전혀 모르겠다.위키피디아를 쓰고 사용하는 사람들은 위키피디아가 상세한 지리 정보를 포함하고 있다는 것에 매우 기뻐한다 - 나는 어떤 경우에는 아주 작은 장소에 대한 기사가 더 큰 곳으로 통합될 수 있다는 것에 동의하지만, 나는 그것들에 대해 상당한 양의 기사를 쓸 수 있었던 (그러나 아직 쓰지 않은) 장소들에 대한 짧은 기사를 유지하지 않을 이유가 없다고 본다.s 우리는 많은 다른 과목들에 대해 그러한 단점을 유지하고 있다.--Kotniski (토크) 16:20, 2010년 10월 31일 (UTC)[응답]

기사 작성 전에 인내심을 요하는 것이지, 그 후에 하는 것이 아니다.단조로운 기사는 다른 대안이 없을 때 허용되지만, 99%의 시간 동안, 우리는 더 큰 기사가 유용한 정보를 제공할 수 있는 더 큰 기사로의 전환을 통해 더 나은 서비스를 제공받을 수 있을 것이다.그것은 내가 반대하는 것이다: 스텁은 일반적으로 정보를 표시하는 가장 나쁜 방법이지만, 스텁은 없는 것처럼 정보 품질을 떨어뜨리는 것처럼 스텁을 갖기 위해 싸운다.플라이스펙 마을 이름에서 그 지역에 관한 좋은 기사로 리디렉션하는 것이 촌뜨기 보다는 낫다.—Kww(대화) 17:10, 2010년 10월 31일 (UTC)[응답]

다시 말하지만, 그것은 "플라이스펙"이 무엇을 의미하느냐에 달려있다.그것이 정말 작은 마을이라면, 나는 동의할 것이다.그러나 만약 그것이 실제로 완전히 완성된 마을이나 마을이라면(이것은 거의 확실히 합리적인 기사가 될 잠재력을 가지고 있다는 것을 의미), 나는 우리가 그 스터브를 유지해야 한다고 생각한다 - 이것은 항상 위키피디아가 사람들에게 새로운 정보를 추가하도록 장려하는 원칙적인 방법 중 하나였다. (그리고 어떤 면에서는 스텁을 갖는 것은 독자들에게도 유용하다.-이것이 정말로 위키피디아가 그 주제에 대해 가지고 있는 정보의 한계임을 확인시켜준다.)--코트니스키 (토크) 20:31, 2010년 10월 31일 (UTC)[응답]

• 내일부터 한 달 동안 공백기를 가질 예정이라, 그냥 지금 여기서 의견을 내놓고 싶었어.만약 당신이 이것에 대해 내일 응답한다면 나는 당신에게 응답할 수 없다는 것을 유의해라.필자가 Notability talk 페이지에 대한 논의에서 언급한 바와 같이, 위의 MBelgrano에 의해 전문가적으로 개략적으로 요약된 바와 같이, 도시, 마을 및 마을에 대한 notability 요건은 다른 기사의 notability 요건과는 상당히 다르다.장소의 기사와 위키피디아에 있는 생물 종에 관한 수많은 기사의 비교를 할 수 있다.

그것이 만들어졌을 때의 Notability의 요점은 어떤 종류의 기사가 만들어질 수 있는가에 한계가 있는지 확인하는 것이었기 때문에, 우리는 어떤 일을 한 적이 없는 사람에 대한 기사나 자동차 사고 때마다의 기사나 기사로 끝나지 않았다.그러나 장소는 다르다.이들이 존재한다는 것이 입증된 이상 주목할 만하다.5대 기둥에 약술된 위키피디아의 관보 역할을 따랐을 때 지구상의 모든 곳은 존재 여부를 확인할 수 있는 한 눈에 띈다.나는 정부 인구 조사 기관이든 아니든 모든 장소에는 그것이 존재하는지 확인하는 최소한 하나의 출처가 있어야 한다는 사실에는 동의하지만, 모든 장소마다 어느 정도 커버리지가 있다고 가정하기 때문에 "비경쟁적 커버리지의 다중 출처"의 요건에 부합해야 한다는 데는 동의하지 않는다.e

그 역사를 간직한 곳마다 지역 역사책이든 다른 것이든 어디선가 인쇄물로 뒤덮여 있었다.이러한 이유로 오래 전부터 지역사회에서 장소들이 존재한다는 것이 확인될 수 있는 한 항상 주목할 만한 것으로 여겨져 온 것이다.그게 다야, 난 나갈거야모두 11월 잘 보내세요.실버스렌^C 18:05, 2010년 10월 31일 (UTC)[응답]

고마워내 포지션과 일치해. :)--인텔라티^talk 18:08, 2010년 10월 31일 (UTC)[응답]

문제없어.하지만, 나는 스티키 프로드 아이디어에 별로 동의하지 않는데, 이 많은 장소 기사들은 감시 목록에 없기 때문에, 아무도 출처를 찾으려고 하지 않았기 때문에 삭제될 것이다.모든 곳이 존재한다는 것이 확인되면 눈에 띈다고 가정하기 때문에, 구글에 접속해서 인구조사 보고서나 다른 것을 찾는 것은 그렇게 어렵지 않을 것이다.나는 이 기사들의 출처를 돕기 위해 다른 어떤 것을 사용해야 한다고 생각한다. 곧 삭제될 위협은 없다.우리는 여기에 있는 콘텐츠를 삭제하는 것이 아니라 보존하고 싶기 때문에 그 목표에 부합하는 옵션을 찾아야 한다.(그리고 이제 나는 정말 한 달 동안 외출한다) 실버스렌^C 18:21, 2010년 10월 31일 (UTC)[응답]

당신은 매우 불확실한 가정을 하고 있다. 누군가가 이름을 지어준 모든 장소에 대해 믿을 만한 출처가 있다고 믿을 만한 근거가 전혀 없다.그것은 단순히 사실이 아니다: 구술 역사는 대부분의 시간 동안 세계 대부분의 사람들에게 흔하다.대부분의 장소는 인구조사 자료만 가지고 있고, 인구조사 자료를 별도의 기사에 담을 이유가 없다.—Kww(대화) 21:40, 2010년 10월 31일 (UTC)[응답]

믿을 만한 출처가 쓰여 있다고 믿을 만한 이유가 전혀 없다면, 봇은 어떻게 그렇게 많은 기사를 만들었을까?나는 봇들이 변덕스럽게 무작위 기사를 만들 가능성은 낮다고 생각한다.

그들은 국가마다 차이가 있을 것이지만 원시 인구 조사 자료는 아닐 것 같은 일종의 공식 목록에 기초했을 것이다.불확실한 가정에 대해 말하자면:이 모든 정산물이 동질질질량이고, 같은 출처 물질에서 같은 방식으로 만들어졌다는 가정이 있는 것 같다.

만약 매우 많은 기사에 대해 과감한 조치를 제안한다면, 나는 정책을 면밀히 고수하고 이 모든 기사의 성격과 기원에 대해 신중하게 생각하는 것이 더 적절하다고 생각할 것이다.

보브레이너 (토크) 21:50, 2010년 10월 31일 (UTC)[응답하라]

단조로운 기사들은 인구 조사와 지도 데이터를 기반으로 하고 있으며, 문제의 장소에 대한 심도 있는 논의는 거의 하지 않았으며, 합리적인 기사를 작성하기에는 충분하지 않았다.그것들은 상당히 동질적이다. 그것이 봇이 만든 물건의 유일한 장점이다.—Kww(대화) 22:19, 2010년 10월 31일 (UTC)[응답]

의미 있는 글을 쓸 만한 검증 가능한 내용이 별로 없는 단조로운 것들만 통폐합하면 되지 않겠는가.어떤 반점은 그 자체로 의미가 있다.어떤 점들은 군, 읍, 지역 등으로 다른 점들과 결합할 때만 의미가 있다.그것은 WP:V 및 WP:N과 일관되고 보다 유용하고 신뢰할 수 있는 컨텐츠로 이어지는 제정신이고 합리적인 정책이다.슈터워커 (대화) 06:41, 2010년 11월 1일 (UTC)[응답]

우리 둘 다 할 수 있고 해야 한다.문제는 모든 거주지 때문에 사람들이 그 리디렉션들을 되돌리는 경향이 있다는 것이다. 왜냐하면 모든 거주지들이 그 자신만의 기사 이론을 가질 자격이 있기 때문이다.우리는 무엇이 정보를 가장 잘 표현하게 하는가에 대한 문제를 고려하는 대신 독립된 기사 이하의 것을 당면한 주제에 대한 모독으로 보는 경향이 있는 수많은 편집자들이 있다.—Kww(대화) 21:19, 2010년 11월 2일 (UTC)[응답]

(은색 세레나데) 음, 그렇게 하기 위해 지역 사회의 합의를 얻을 수 있을 때까지는 안 되겠지?자경단 스타일로 하려고 하면, 많은 사람들을 화나게 하고 결국 ANI에 가게 될 거야.나도 실제로 전에 본 적이 있어. 165.91.173.45 (대화) 04:51, 2010년 11월 3일 (UTC)[응답]

단지 우리가 정보를 가장 잘 제시하는 대신 별도의 기사를 고집하는 잘못된 사람들을 가지고 있기 때문이다.그들이 존재한다는 것은 부끄러운 일이지만, 그들을 지나칠 수는 없다.—Kww(대화) 14:08, 2010년 11월 3일 (UTC)[응답]

(은색 세레나데) 컨센서스라고 불리는데, 쿠우, 위키백과에 대해 어떤 것을 하고 싶다면 그저 그것을 준수하는 데 익숙해져야 한다.그런 식이다. 165.91.174.83 (토크) 21:52, 2010년 11월 3일 (UTC)[응답하라]

지금 당장은 의견 일치가 없는 것 같다.우리는 하나를 만들려고 노력하고 있다.현재 상황은 혼란스럽고, 편집 전쟁, 잘못된 길을 가는 AFD(삭제 후 보관)로 인해...이 기사들을 다루는 가장 좋은 방법에 대한 공통적인 이해를 구하려고 노력해보는 것은 어떨까?슈터워커 (대화) 2010년 11월 5일 16:14, (UTC)[응답]

나는 네가 공감대를 찾으려고 해서는 안 된다고 말한 적이 없어.나는 Kww에게 당신이 아무런 결의도 없이 이전의 오랜 합의와 어긋날 것이기 때문에 어떻게 합의점을 찾지 못한 채 단지 시의 단편적인 기사들을 병합하려고 해서는 안 되는지 설명하고 있었다.또한, 이 토론은 좀 더 공공장소나 다른 곳으로 옮겨져야 할까?우리는 여기에 많은 사용자들을 끌어들이지 못하고 있다.몇몇 위키백과 학생들에게 이것이나 다른 것에 대해 알려주시겠습니까? 165.91.173.45 (대화) 22:04, 2010년 11월 5일 (UTC)[응답]

마을 펌프스는 공공장소만큼이나..다른 옵션은 정식 RfC뿐입니다. œ^™ 13:54, 2010년 11월 6일(UTC)[응답]

그런 것 같긴 한데, 여기서 진짜 논의는 원래 논의하던 네다섯 명의 사람들끼리만 하는 것이기 때문에 그때는 더 많은 사람들이 참여하도록 하는 방법이 필요하다.사실 공감대가 형성되지 않았다. :/ 165.91.173.213 (대화) 20:03, 2010년 11월 6일 (UTC)[응답]

문서 탭 및 토론 탭 옆에 있는 예제 TAB

GidaY! 너희들은 정말 멋진 일을 하고 있지만, 많은 기사의 기능성은 순수하게 이론적인 성격이나 대학 교수들과 특정 분야의 이해도가 높은 사람들 사이의 논쟁으로 해결되었을지도 모르는 복잡하고 정확한 예와 정의의 사용에 의해 제한된다.이것은 학생과 일반 독자들이 공감하고 이해하기 어려운 많은 양의 기사를 만들어낸다.이 문제를 해결하려면 예제 탭을 작성하여 문서 및 토론 탭 옆에 두도록 하십시오.

이것은 사람들이 기사들의 내용 자체를 바꿀 필요 없이 기사에 실질적인 예를 추가할 수 있게 해줄 것이다.아시다시피, 대부분의 사람들은 실제적으로 배우는데, 예를 들어, 운동과 참여가 이론 자체보다 훨씬 빠른 선생님이다.모든 페이지에 대한 졸업 난이도 예제를 한 페이지씩 갖는 것은 사람들이 기사 섹션에 포함된 이론을 훨씬 더 잘 그리고 더 빨리 이해할 수 있게 해줄 것이다.

이 추가 섹션을 구성하기 위해서, 나는 순진하게 당신이 편집 가능한 공간으로서 저장 공간의 추가 영역을 이미 존재하는 항목들과 병행하여 각 위키백과 항목들에 할당하고, 기사 섹션에 사용된 것과 동일한 규칙과 프로그래밍을 적용할 수 있어야 한다고 생각할 수 있다.기사 단추 옆에 있는 바의 탭을 위한 공간이 이미 존재한다는 사실은 다른 코드도 변경할 필요가 없다는 것을 의미할 것이다.이것은 아마도 엄청난 과소평가일 것이다. 하지만 위키피디아의 질에 대한 혜택, 전체 경험에서 10-30%의 개선은 노력의 가치가 충분히 있을 것이다.

뉴질랜드의 건배와 행운이 깃들길

예제 탭에서 크게 도움이 되는 항목의 예:

모든 수학 미술가, 물리학, 일반 경제학 과학, 회계학, 미술 - 질문 및 그림 그리기.동물 종, 그들의 characteristics와 위치의 예시 자동차 부품, 설치 후 조리법, 재료의 출처, 유명한 시대 요리가 제공되었다. 사람들, 연설, 음악, 예술, 행위 등의 예시, 코드화 예시 등.무제한 예시.나는 위키피디아에 관한 거의 모든 기사들은 예제 탭으로부터 이익을 얻을 것이라고 주장한다.— 115.188.181.7이 추가된 선행 서명되지 않은 의견(대화 • 기여)

• 대신 간단한 영어 위키백과를 사용해 보셨나요?기사를 이해하기 쉽도록 설계되었다... --Jayron32 03:33, 2010년 11월 7일 (UTC)[응답]
  • 물론 (단순 영어)어 위키백과인데, 제이론이 잘 알겠지만, 그래서 '단순 영어 위키백과'가 되는 것은 바람직한 목표보다는 부작용이다. - 재리1250 13:07, 2010년 11월 7일 (UTC)[응답]
• 위키피디아는 교과서나 학문적 학습 과정이 아니라 백과사전이다; 브리타니카는 추가적인 예시나 연습들을 포함하고 있는가?전 그렇지 않다고 생각해요.그러나, 이미 위키북스와 위키다양성이 있는데, 여기서 작업한 사례들의 모음이 전적으로 적절하고 환영받을 것이다. 그들에게 기여하기를 권장한다. --Cybercobra (대화) 05:12, 2010년 11월 7일 (UTC)[응답]
• Wiktionary는 'Cittions' 탭에 비슷한 것이 있다.나는 그것이 가치 있는 생각이라고 생각한다.하지만 왜 예들은 텍스트 자체에 통합될 수 없었을까?따로 페이지를 둘 필요는 없다. -- 05^™:49, 2010년 11월 7일 (UTC)[응답]
• 내가 항상 이 골치 아픈 문제에 대해 생각하는 방법은 다음과 같다: a) 주어진 기사를 누가 읽는지 알아내라 b) 필요하다면 예를 들어 그 문제에 가장 좋은 기사를 쓰라.IMHO, 어떤 기사도 매 단계마다 예시(*백삼배수 리스트에 대한 준비 사항*)를 통합하여 매우 상세하고 대중적으로 이해할 필요가 없다.경험 많은 프로그래머는 컴퓨터 프로그래밍이 세부적인 기사가 될 필요가 없으며, 그래서 컴퓨터 프로그래밍은 예를 포함할 수 있다; 만약 그들이 세부적인 것을 원한다면, 그들은 추상화(컴퓨터 과학)와 같은 보다 상세한 기사를 찾아서 대신 그것을 읽을 수 있다.마찬가지로 일반인은 CS에서 추상화에 대해 직접 읽기를 원하거나 필요할 것 같지 않지만, 컴퓨터 프로그래밍과 같은 예와 함께 더 넓은 범위의 기사에 그것을 배치하기를 원한다.자, 내 돈으로는, 그 이론을 제대로 구현하는 것은 양방향이지만, 궁극적으로 예는 어떤 상황에서든 논쟁적일 필요가 없으며, 마찬가지로 별도의 표에 있을 필요도 없다.하지만 여기 있다. - Jarry1250 13:07, 2010년 11월 7일 (UTC)[응답하라]

RevDel 사용을 위한 소프트웨어 코드 변경

이 논의를 참고하십시오. WP의 요약 사용 편집에 코드화할 수 있는가?요약 편집자가 검색한 요약 편집자는 이 정보를 왜 또는 어디서 찾아야 하는지 모를 수 있으므로 REVDEL은 해당 페이지에 대한 링크를 클릭하십시오.샌디조지아 (토크) 18:35, 2010년 11월 7일 (UTC)[응답]

MediaWiki를 편집하면 다음과 같은 작업을 수행할 수 있다.Rev-deleted-comment.Ucucha 18:40, 2010년 11월 7일 (UTC)[응답]

아하, 좋아.MediaWiki:Rev-deleted-no-diff 및 MediaWiki:정책에 대한 rev-deleted-text-permission 링크MediaWiki:Rev-deleted-comment, MediaWiki:Rev-deleted-user 및 MediaWiki:rev-deleted-user-contents는 그렇지 않다.내 생각에, 비록 그것이 정책에 "제거된" 위키리크일지라도, 그들 모두가 그래야 한다고 생각한다.Rd232^talk 18:46, 2010년 11월 7일 (UTC)[응답]

나는 방금 Rev-deleted-comment를 시도했다. 불행하게도 위키링크를 받아들이지 않기 때문에 나타나는 텍스트는

(요약 편집 [Wikipedia:개정삭제제거]])

Ucucha 18:53, 2010년 11월 7일 (UTC)[응답]

그리고 그것을 발견한 것은 내가 처음이 아니었다.Ucucha 18:57, 2010년 11월 7일 (UTC)[응답]

짜증나.누가 이 일을 성사시킬 수 있는지 설명해 줄 수 있니?결국 소프트웨어 변경이 필요할 수 있는가?Rd232 21:39, 2010년 11월 7일 (UTC)[응답]

기술적으로 가능한 변경사항이라면 IDK이지만 버그를 신고하십시오. /1987 ETCOMMS/ 02:54, 2010년 11월 8일 (UTC)[응답]

다른 가능성은 정책에 대한 링크가 있는 "관리자가 수정사항을 방금 삭제했다"고 말하면서 사용자의 토크 페이지나 기사 토크 페이지에 배치할 템플릿을 작성하는 것이 될 것이다.도로의 엘렌 (대화) 00:13, 2010년 11월 9일 (UTC)[응답]

기사토크 페이지에서는 말이 되는지 모르겠고, 사용자토크 템플릿이 실제로 얼마나 자주 관련될지는 잘 모르겠다.나는 WP에 대한 수정안을 마련하는데 몇 분 동안 노력했지만 실패했다.사용자에게 통지할 수 있는 역할에 대한 REVDEL.문제는 일반적으로 사용자에게 통지하는 것이 불필요하거나 비생산적이라는 점이다. 관리자가 "여기 메모가 도움이 될 수 있다"고 생각하는 것은 그들이 RevDel을 해서는 안 된다는 경고 신호로 보아야 한다.또는 만약 그렇다면, 의심스러운 RevDel을 한 다음 정책에 대한 링크를 게시하는 것보다 AN에서 검토를 요청하는 것이 낫다.내 말 알겠어?정책에 대한 자동 연결은 일반적으로 유용한 정보일 뿐이지만, 가능한 항소나 검토를 위해 플래그 지정이라는 하위 텍스트로 통지하거나 경고하는 관점에서 생각하는 것은 잘못된 것이다. 왜냐하면 RevDel은 논란이 되어서는 안 되며, 가능한 경우 A에서 검토를 요청해야 하기 때문이다.Rd232 00:48, 2010년 11월 9일 (UTC)[응답]

위키백과 작성:수정사항 수정 요청

안녕. 나는 위키백과의 새로운 프로젝트 페이지를 만들까 생각중이야. 위키백과:수정기호 수정 요청.기본적으로 사용자가 삭제를 요청할 수 있는 수정사항 요청 페이지(WP와 약간 유사한 맥락:수정사항이 보고되는 경우를 제외하고 AIV).RevDelete(기본적으로 제공되지는 않지만)관리자에게 부여되었으므로, AIV 및 UFAA뿐만 아니라 동일한 관리자 개입도 그곳에서 작동해야 한다고 생각한다 도구는.나는 WP:감독요청이 있다는 것을 알지만, 그러한 요청은 오직 사적인 이메일을 통해서만 이루어질 수 있다.WP:RRFR은 수정 삭제 프로세스가 훨씬 더 빠르게 이루어질 수 있는 "공용" 프로젝트로서, 이를 다룰 수 있는 프로젝트 주변에 관리자가 많다.미니맥 (대화)20:02, 2010년 11월 8일 (UTC)[응답]

위키백과 참조:관리자 알림판/아카이브217#WP:RFRD? 및 위키백과의 시간:관리자 게시판/아카이브218#이 주제에 대한 이전의 논의를 위한 WP:RFRD?의 TIME.Anomie november 20:53, 2010년 11월 8일 (UTC)[응답]

WP에 추가된 최근 참고 사항도 참조하십시오.REVDEL 및 CAT:RFD. Rd232^talk 21:20, 2010년 11월 8일(UTC)[응답]

FWIW, 적어도 시험해 보고 어떻게 작동하는지 보자는 대략적인 합의가 있었던 것 같았다(개인적으로는 그 제안에 동의하지 않았지만).–MuZemike 06:31, 2010년 11월 9일 (UTC)[응답]

"이제 RevDelete 툴이 (기본적으로 제공되지는 않지만) 관리자에게 부여되었으므로"라는 빠른 코멘트는 어느 관리자도 할 수 있는 일이기 때문에 나는 이해할 수 없다.그것은 블록/보호/삭제 같은 표준 패키지의 일부분이다.오용필터 편집은 기본적으로 주어지지 않는 것이다. / /ETECCOMMS/ 01:05, 2010년 11월 9일 (UTC)[응답]

사이드바에서 도움말 링크 이동

여러분 안녕하십니까?
경험 많은 위키피디아 사람들은 그들의 길을 알고 있을 수도 있고, 혹은 적어도 어디를 찾아야 할 지 알 수도 있지만, 나는 새로 온 사람들이 그다지 잘 적응하지 못한다고 생각한다.기본 스킨 &c를 사용하는 신입생의 경우, 나는 "도움말"이 메인 페이지의 왼쪽 사이드바에서 12번째 링크라고 믿는다. "상호작용" 섹션에서는 메인 페이지의 시각적 디자인이 사이드바에서 눈을 떼는 경향이 있다.
사이드바에서 도움말 링크를 더 위로 이동하여 링크를 더 돋보이게 하는 것이 좋을 것 같아.윗부분에서는 더 좋을 것 같다, (현재 모노북에서는 '내비게이션'이라고 불리고 있다(기존 콘텐츠로도 최고의 이름인지 확실치 않지만 옆길로 새지 말자...)이것은 위키피디아에서 그들의 길을 찾는 데 가장 도움이 필요한 사람들을 위해 조금이나마 도움의 가시성을 향상시킬 것이다.공동체는 어떻게 생각하는가?예, 아니오?
보브레이너 (대화) 09:01, 2010년 10월 30일 (UTC)[응답]

그 외는 다음과 같다.이러한 아이디어는 Help talk에 대한 앞선 토론에서 영감을 얻었다.도움말을 위한 다른 개선사항에 대한 내용/초안, 그리고 거기에는 약간의 지원이 있었지만, 나는 더 넓은 청중들 앞에 이 아이디어를 놓고 싶다.분명히 마지막 사이드바 재설계에는 도움 링크가 더 필요했지만, 그것이 최종 컷에 들어가지 못했다; 나는 이유를 모르겠다. 보브레이너 (토크) 10:19, 2010년 10월 30일 (UTC)[응답]

• 지지하다."Help" 링크를 "Interaction" 섹션의 상단에 있는 "About Wikipedia" 링크 위로 이동하십시오. (그러나 백과사전-컨텐츠로 연결하기 위한 상단 섹션에는 해당되지 않음).인터랙션 섹션은 메타 콘텐트에 연결하기 위한 것이다.) -- Quidity (토크) 19:13, 2010년 10월 30일 (UTC)[응답]
• "도움말" 링크를 Quiddity당 위의 "Interaction" 섹션 상단으로 이동하십시오.맨 위 섹션은 독서자/찾아보기용이다.상호 작용 섹션은 편집자(커뮤니티)를 위한 섹션이다.인터랙션 부분의 상단은 그것을 위한 완벽한 장소가 될 것이다.트랜스휴머니스트 02:47, 2010년 10월 31일 (UTC)[응답]
• 지원 I는 기본적으로 상호 작용 탭이 축소되어 사용자에게 보이지 않는다는 점을 지적한다.네비게이션으로 옮겨야 할 것 같은데...비록 그것이 그 구역들의 명칭의 유용성을 정말로 망쳐놓는다.—DJ (대화 • 기여) 2010년 10월 31일 (UTC) 14:19[응답]
• 지지하다.합리적인 제안인 것 같군비록 그것이 아마도 최소한의 효과만 가질 수 있을 것이다 - 그것을 찾는데 많은 검색이 필요하지 않고, 그것을 옮기는 것은 심지어 그것이 현재 있는 장소에서 그것을 찾는데 익숙한 일부 독자들을 혼란스럽게 할 수도 있다. -- -- 12^™:24, 2010년 11월 5일 (UTC)[응답]
• 지원, '상호작용' 탭에서 빼서 '도너테이트' 바로 밑에 넣으세요. -- 도오! 12:56, 2010년 11월 5일 (UTC)[응답]
• MediaWiki Talk의 요청별:사이드바 내가 도움말 링크를 탐색 섹션의 맨 위로 이동했다.만약 이것이 최선의 해결책이 아니라면, 여러분들은 모두 다른 장소를 제안하고 있었기 때문에 논의를 계속하십시오.건배 — 마틴 (MSGJ · talk) 13:16, 2010년 11월 8일 (UTC)[응답]

  교호작용의 맨 윗부분을 말하는 겁니까?Ruslik_Zero 19:55, 2010년 11월 8일 (UTC)[응답]

  바로 그거야.— 마틴 (MSGJ · talk) 09:17, 2010년 11월 9일 (UTC)[응답]

요약 보고서 편집

AIV 또는 SPI와 유사한 페이지가 있어야만 요약 반달리즘을 편집할 수 있는가?'위키피디아:관리자의 주의를 끌기 위해 요약 편집' 또는 'Wikipedia:관리자 주의를 끌기 위한 차이점'?이것을 만들 수 있지만, 다른 사람들의 의견을 먼저 얻고 싶었다. --고느러미 향유고래 21:33, 2010년 11월 9일 (UTC)[응답]

왜?우쿠차 21:37, 2010년 11월 9일 (UTC)[응답]

'요약 반달리즘 편집' 같은 것은 없다.통상적인 방법으로 ANI에 보고할 수 있는 '요약적 인신공격 편집', '요약적 인종차별적 학대 편집' 등이 있을 수 있다. --Elen of the Roads (대화) 21:40, 2010년 11월 9일 (UTC)[응답]

나는 스팸 링크나 극도로 명예 훼손적인 편집 요약은 삭제되어야 마땅하다고 생각한다.그리고 나는 당신이 그것을 보거나 관리자에게 요청할 때마다 ANI 보고서를 작성하기에는 너무 많다고 생각한다.관리자만이 제거할 수 있기 때문에 일반인들이 신고할 수 있는 방법이 있어야 한다.그리고 그것이 피해를 줄 수 있을까? --TheHighFinSpermWhale 21:48, 2010년 11월 9일 (UTC)[응답]

그럼 본질적으로 "RevDel에 대한 요청"을 원하십니까?자세한 내용은 이 항목 바로 위의 섹션을 참조하십시오.Ucucha 21:52, 2010년 11월 9일 (UTC)[응답]

위키백과 설명서

초보 등록 편집자로서 나는 마크업/태그/사이트/커뮤니티를 배우는데 어려움을 겪고 있다. 위키피디아가 현관문이 없는 것처럼 모든 것을 배운다.나는 위키백과를 지원하고 홍보하기 위해 위키백과 매뉴얼을 발간할 것을 제안한다.나는 온라인에서 someschuch를 검색했고 이것을 발견했다; 위키피디아;;; John Brownon의 사라진 설명서 - hah - 는 아이러니를 좋아한다.사본은 사겠지만, 왜 공식 매뉴얼이 없는가, 초보 편집자들이 사용할 수 있게 하고, 화재의 시행착오 세례도 아끼지 않는가. (?) 공식 매뉴얼은 그 프로젝트에 유용한 페니스를 몇 푼 줄 수 있는데, 왜 존재하지 않는가?마크^Dask 13:35, 2010년 11월 3일 (UTC)[응답]

Zeno는 그 이후로 나에게 "The missing manual - 고마워 Zeno. 하지만 나는 하드 카피를 원해.왜 존재하지 않는 거지?마크^Dask 13:48, 2010년 11월 3일 (UTC)[응답]

위키피디아는 너무 자주 바뀌어서 하드카피 매뉴얼이 말이 되지 않는다.게다가, 하드카피 매뉴얼은 업데이트하기가 어렵다.만약 당신이 어려움을 겪고 있다면, 여기서의 몇몇 교훈은 당신에게 유용할 것이다.→ ROX₪ 13:51, 2010년 11월 3일 (UTC)[응답]

하드카피는 존재한다. 위키피디아 – 분실 매뉴얼을 참조하라.2008년판이며 지난 2년간 다수의 업데이트를 포함하지 않는다는 점을 이해하십시오. ---— Gadget850 (Ed) 16:17, 2010년 11월 3일 (UTC)[응답]

나는 그것에 대해 꽤 알고 있어, 고마워.2008년 버전이라는 것에 대한 당신 자신의 요점을 고려한다면, 즉..음, 그건 내가 무슨 말을 하고 있었는지 정확히 증명하는거야. 그래서 난 네가 여기에 뭘 덧붙이고 있다고 생각했는지 잘 모르겠어.→ ROX ₪ 16:19, 2010년 11월 3일 (UTC)[응답]

루와 가젯, 고마워분명히 위키백과 – 사실 분실 매뉴얼은 위키뿐만 아니라 하드카피에도 있는 공식 매뉴얼이다.그러나 나는 Roux에게 이 하드 카피가 2년 전의 것이라는 사실이 위키의 작동 방식에 대한 포괄적인 소개로서 새로운 편집자들에게 그것의 가치를 떨어뜨리지 않는다고 말하고 싶다.그것은 내가 그것의 존재에 대해 알고 있는 24시간 동안 나에게 많은 질문에 대답해 왔다.마크^Dask 14:18, 2010년 11월 4일 (UTC)[응답]

나는 그것을 어떤 식으로든 "공식"이라고 부르지 않을 것이다.누락된 설명서 시리즈는 제3자에 의해 만들어지며 다양한 주제를 다룬다.— 당신을 먹여 살리는 손:^Bite 2010년 11월 4일(UTC) 19:17[응답]

좋아, 핸드, 내가 다시 말할게.내 부분에 대한 약간의 작은 재발견에 기초하여, 그리고 공식 매뉴얼이 없는 경우, 위키백과 – 분실 매뉴얼은 특히 위키백과 자체, (공용 도메인) 내에서, 그리고 하드카피에서도 위키백과가 어떻게 작동하는지, 새로운 편집자들에게 가장 적절한 소개 가이드로 보일 것이다.마크^Dask 05:25, 2010년 11월 5일 (UTC)[응답하라]

참고 사항으로, Book:에서 항상 최신 버전을 찾을 수 있다.위키백과: 누락된 설명서.당신은 그것을 인쇄하거나 PDF를 다운로드 할 수 있다. 어느 것이든 당신에게 가장 적합한 것이다.헤드폭탄 {talk / 기여 / 물리학 / 책} 05:55, 2010년 11월 5일 (UTC)[응답]

고마워 헤드밤.그 프린터는 페디아프레스다. 위키프로젝트인가 아니면 제3자인가?마크^Dask 15:30, 2010년 11월 5일 (UTC)[응답]

페디아프레스사는 책 도구를 만든 회사다.그들은 위키미디어 재단과 파트너십을 맺고 있다.진실에 접근하기 2010년 11월 5일(UTC) 18:52 [응답]

ROTT가 말한 것과 거의 같다.페디아프레스와 위키미디어 재단은 파트너십을 맺고 있다.페디아프레스는 책 도구("왼쪽 인쇄/내보내기" 도구 상자에 책 만들기")와 PDF 렌더링 도구("같은 도구 상자에 PDF 다운로드")를 개발하며, 주문 시 책도 인쇄할 예정이다.이 책들의 10%는 위키미디어 재단으로 직접 간다.더 자세한 내용은 시그널포스트(Signpost)에서 읽을 수 있다.(신고자: 나는 페디아프레스와 함께 있다.)

헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 11월 5일 (UTC) 19:05, 답변

위의 내용을 고려할 때, 위키백과 – 분실 설명서 또는 일부 형태의 설명서는 기본 페이지 도구 상자 섹션에서 직접 접근할 수 있다면 잘 맞을 것이다. - 설명서는 도구 상자 안에서만 찾을 수 있는가?Wiki 설명서는 새로운 편집자들이 가장 새로운 사용자에게 친숙한 문서로 간주하기에는 너무 방대하고 구조화되지 않았다.편집자 지망생들은 수동적이고 구조적인 학습에 더 쉽게 갈 수 있다.이렇게 하면 얼마나 쉬울까?마크^Dask 21:07, 2010년 11월 5일 (UTC)[응답]

기본 도움말 페이지인 도움말에서 연결됨:내용("도움말" 사이드바의 도움말)이지만 그다지 두드러지지는 않는다.만일 우리의 온위키판 <실종 매뉴얼>이 몇 가지 주요 문제를 해결했다면, 나는 그것을 더욱 두드러지게 만드는 데 동의할 것이다.

(주요 문제점은 구 사이트킨(모노북)을 지칭하는 이미지와 산문, 미완성 섹션 링크(원본에 페이지 번호가 있는 "xx에 관한 섹션"이라고 쓰여 있다) 등이다.도움말 토크를 참조하십시오.위키백과: 누락된 설명서#알려진 몇 가지 문제).--Quiddity (대화) 19:33, 2010년 11월 6일 (UTC)[응답]

고마워 Quiddity - 나는 네가 언급한 각각의 문제점들을 알아챘다.도움말의 경우:컨텐츠 페이지는 메인 페이지 도구상자 섹션에서 연결되었는데, 그것조차도 엄청난 개선이 될 것이고, 너무 쉽게 할 수 있을 것이다.'도움말'이라는 단어인 만큼 메인 페이지에도 등장하지 않는다.또한 [[도움말:Contents] 페이지는 매우 사용자 친화적이지만 섹션 전체에 걸쳐 하단에 있는 "Main 메뉴로 돌아가기" 버튼의 혜택을 받을 수 있다.할 수 있는 일인가?마크^Dask 07:15, 2010년 11월 7일 (UTC)[응답]

[도움말]에 링크 추가:위키백과의 다른 영역 섹션의 메인 페이지에 있는 내용]이 가능할 수 있다.거기에 물어봐야 할 것이다.(현재 메인 페이지 디자인의 또 다른 측면, 즉 맨 위에 보이는 "기사 수"에 대해 집중적인 논의를 하고 있기 때문에 며칠 기다리기를 권한다.)

[#Top] 링크와 같은 아래쪽 링크는 권장되지 않는다.또한, 우리는 이미 헤더 바로 아래에 자동 생성된 브레드크럼 링크를 가지고 있는데, 이것은 UI에서 상당히 표준적이다.

피이, 헬프토크에서 토론이 있어주요 도움말의 일부 변경 가능 내용에 대한 내용/초안:내용 메뉴. --Quiddity(토크) 20:42, 2010년 11월 9일(UTC)[응답]

이해는 고사하고, 거기서 읽을 것이 많은 링크에 감사한다.나는 초안을 연구해서 내가 어떤 식으로든 기여할 수 있는지 알아볼 것이다.그런 일이 내게 일어났는데, 왜 단순히 상호작용 섹션 도움말을 다시 라벨로 표시하지 않는 걸까?그런 다음 Help를 Help: Content로 다시 라벨링하십시오.상호 작용이라는 단어는 모호하고, 싱겁고, 거의 디콘텍스트화 되어 있다.새로 온 사람에게 도움을 청하러 가야 할 장소로서 분명하지 않다.다시한번 감사합니다.2010년 11월 10일(UTC) 마크^Dask 20:00[응답]

우리는 정책 문제를 위한 마을 펌프가 필요하다.

누군가 정책 위반 가능성을 보면서도 어떻게 진행해야 할지 잘 모르는 경우Vchim 침팬지 · 대화 · 기부 · 21:53, 2010년 11월 10일 (UTC)[응답]

수많은 공지사항 게시판이 있다(WP 상단에 나열됨:A 등)은 다양한 위반 및 정책에 대한 우려로 존재한다.당신이 염려하는 특별한 정책이 있는가?2010년 11월 10일(UTC) 결연한 21:55[응답]

생활자의 출판목록에서 "그녀 자신의 위키백과 페이지"라는 여러 정책을 한꺼번에 위반하는 것처럼 보여 <정책 마을 펌프>에 적합하다고 생각했다.아니면 죽은 사람일 수도 있었다.어느 쪽이든 잠재적으로 두 WP였다.소유 또는 WP:COI.어떠한 기사에서든 일어날 수 있는 일이었지만(일반적인 문제로 만들면), 앞으로 6개월 안에 누가 정확히 그 기사의 토크 페이지에서 나의 우려를 보게 될까?WP 중 다음 중 어느 것을 참조하십시오.A가 그럴까?Vchim 침팬지/대화/공헌/22:03, 2010년 11월 10일 (UTC)[응답]

실제 사건에 대해 더 말해야 해, 그렇지 않으면 우리가 어떻게 조언해야 할지 모를 거야.에드존스턴 (대화)22:16, 2010년 11월 10일 (UTC)[응답]

이건 도움이 안 돼내가 구체적으로 말하려고 할 때마다, 나는 욕을 먹는다.Vchim 침팬지/대화/공헌/22:20, 2010년 11월 10일 (UTC)[응답]

두 가지 예를 더 들겠다.내게는 단어들이 관련이 없는 것처럼 보이지만 누군가 그 페이지에 두 단어를 모두 넣고 싶어 하는 Adisambigation 페이지.기사의 토크 페이지가 가야 할 곳이라는 말을 들었지만, 정책 마을 펌프에서 시작하지 않았다면 아무도 눈치채지 못했을 것 같다.또한 적절한 절차에 대한 조언이 필요했다(정책?)독일어 어게인에서 훨씬 더 나은 기사에 대한 기고를 위해 독일어 연사와 접촉한 Policy Village Pump는 내가 필요로 하는 사람을 끌어들였다.그리고 그 사건들 역시 내가 게시한 곳에 대한 비난을 받았다.

구체적인 기사는 베티 다이아몬드, 워퍼(동음이의), 보스타파인 등이다.그리고 그 구체적인 내용을 파악했으니 정책 논의는 아닌 것 같다.Vchim 침팬지/대화/공헌/22:36, 2010년 11월 10일 (UTC)[응답]

방금 WP:빌리지 펌프(정책)를 살펴봤다.문제는 당신이 질문을 펌프로 가져온 것이 아니라, 기사의 토크 페이지에서 시작하지 않은 것이다.아무도 눈치채지 못할 거라고 생각하지만, 그건 문제가 아니야.질서의 외형을 유지하기 위해서는 기사에 대한 질문이 기사 자체에 관한 것일 때 항상 기사의 토크페이지에서 시작해야 한다.글쎄, 그건 100% 사실이 아니지만, 그렇지 않은 경우가 훨씬 더 많다.예를 들어, 베티 다이아몬드 이슈에서는, 기사의 토크 페이지에서 시작할 수 있었다.그런 다음 응답을 받지 못했거나 자신에게 유리한 응답을 받았다면 먼저 수정하면 된다.헉, 그럴 필요조차 없었잖아. 그냥 편집만 하고 그 후에 토론을 할 수도 있었을 텐데.변경사항이 잠재적으로 논란이 될 수 있는 경우(또는 주제 자체가)에만 먼저 토의하면 된다.어떤 변화를 해야 할지 잘 몰랐다면 먼저 물어보는 것도 좋은 계획이다.기사의 정기 편집자가 있다면 가장 좋은 답을 얻을 가능성이 높다는 생각이다.그러면 이견이 있으면 해당 이사회에 문제를 상정할 수 있다.이제, 내가 동의하는 부분은 어느 이사회에 갈지 결정하는 것이 매우 어려울 수 있다는 것이다.내 생각엔 네가 물어보는 건 빌리지 펌프에 가지 말고 WP처럼 안내판 중 하나에 가는 게 좋을 것 같아.신뢰할 수 있는 출처의 통지 게시판인 RSN 또는 WP:BLPN, 살아있는 사람들의 전기 관련 게시판.후자는 베티 다이아몬드를 타기에 좋은 장소였을지도 모른다.그녀가 죽었더라도, 그 정책은 부분적으로 적용되고, 그들은 적어도 너를 도울 수 있다.마지막으로, 위키피디아를 사용하는 데 도움이 필요하면, 이미 대화 페이지에서 좋은 대화를 나눈 사용자에게 물어보거나 헬프 데스크에 문의하면 적절한 장소를 안내할 수 있다.그러나, 당신의 특정한 우려 가운데, 아마도 우리가 새로운 사용자를 돕기 위해 우리의 모든 게시판을 위해 더 나은 조직이 필요하다는 당신의 핵심 개념은 조사할 가치가 있을 것이다. 202.246.44.5 (대화) 01:07, 2010년 11월 11일 (UTC) 죄송합니다, 그것은 실수로 로그아웃되었다. Qwyrxian (대화) 23:43, 2010년 11월 11일 (UTC)[응답]

그리고 나는 단지 한 군데 더 볼 곳이 생각났다.특정 주제에 대한 도움이 필요하면 WP:위키피디아 제목.모두 도움이 될 만큼 활동적인 것은 아니지만, 독일어 화자를 찾던 때와 같이 주제별 전문가에게 도움을 받을 수 있는 좋은 장소가 될 수 있다.202.246.44.5(대화) 01:07, 2010년 11월 11일(UTC) 미안, 바로 나, 실수로 로그아웃했다. Qwyrxian (대화) 23:43, 2010년 11월 11일 (UTC)[응답]

디토, 202.246.44.5가 말한 것.

위키백과 참조:세부사항 및 템플리트 안내판:퀵리스트에 대한 알림판 링크. --Quiddity (토크) 02:04, 2010년 11월 11일 (UTC)[응답]

게시판은 논쟁이나 토론을 중앙집중화하는 도구일 뿐, 기사의 특정 측면만을 다루고 다른 부분을 무시하려는 의도는 아니다.만약 어떤 기사에 많은 문제가 있다면, 어떤 것이 정말 가장 큰 문제인지 간단히 정의하고, 특정 게시판에 가서 전체 내용을 설명하시오.예를 들어, MBelgrano (토크) 02:26, 2010년 11월 11일 (UTC)[응답]을 유도하기 위해 원래 연구와 POV 추진이 주로 채용된다.

나는 모든 도움에 감사한다.하지만 여전히 내가 신참인 것처럼 혼란스럽다.Vchim 침팬지 · 대화 · 기여 · 2010년 11월 11일 (UTC) 17:08, 응답

1단계: 연결된 대화 페이지에서 질문하십시오.2단계: 의문 사항이 있을 경우 WP에 요청하십시오.헬프 데스크.3단계: 이익!

("만약 혼란스럽지 않다면, 당신은 주의를 기울이지 않는 것이다." - 톰 피터스의 덕택이다.)--Quiddity (대화) 20:03, 2010년 11월 12일 (UTC)[응답]

모든 날들의 감시목록은 정말로 30일동안이다. 그래서 다시 라벨을 붙이거나 다시 녹음한다.

위키피디아와 위키피디아에서 감시목록은 30일 제한이 있는 것 같다.따라서 감시 목록 페이지에 "어떻게 지속되는지 1 2 6 12시간 1 3 7일"이라고 쓰여 있는 내용은 "전체"가 "30일"이 되도록 수정되어야 한다.훨씬 더 긴, 또는 무한의 시간을 제공하는 것이 더 좋지만, 이 편집은 아마도 구현하기가 더 쉬울 것이다.WP에서 많이 편집하고 워치리스트를 자주 확인하지만 다른 프로젝트에서는 거의 편집하지 않기 때문에 그들의 워치리스트를 자주 확인하고 싶지 않다.고마워요.닉 레빈슨 (대화) 05:35, 2010년 11월 11일 (UTC)[응답]

최근의 변화표는 30일 동안만 물건을 보관하므로, 30일이 전부다.그러나 30일이 보장되지는 않는다. $wgRcmaxAge 문서를 참조하십시오.$wgRcmaxAge의 값은 일수가 아닌 초이므로 디스플레이에 적합하지 않다.그리고 표를 완전히 정리하는 것 또한 완전히 안전하며, 그 시점 이후 편집된 내용을 포함하고 30일 동안 편집한 것은 아니다.진실과 접촉하기 05:51, 2010년 11월 11일 (UTC)[응답]

좋아, "30까지"는 어때?그것은 "전부"와 달리 정확하고 오해하지 않을 것이다.우리는 "전부"를 보지만 편집이 전혀 없었으리라 추측한다.닉 레빈슨 (대화) 06:23, 2010년 11월 11일 (UTC)[응답]

bugzilla에서는 패치를 환영한다: —DJ (대화 • 기여) 23:46, 2010년 11월 17일 (UTC)[응답]

고마워. 좋은 생각이야. 그래서 나는 거기에 버그 26022로 신고했어.닉 레빈슨 (대화) 04:56, 2010년 11월 20일 (UTC)[응답]

위키백과에서 사용되는 영어단어의 순위

여보세요

wikipedia.org에 실린 방대한 양의 기사는 영어로 쓰여 있다.이 언어를 배우는 것은 좋은 이유다.나는 영어를 스마트하게 배우고 싶다.그래서 나는 단어를 배우는 가장 좋은 출발점은 오늘날의 영어에서 단어 인기에 대한 지식을 얻는 것이라고 생각한다.나는 그런 단어 순위 목록을 검색했고 마침내 http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists을 찾았다.이 페이지에는 "TV와 영화 대본"과 "구텐베르크 프로젝트"의 두 가지 눈에 띄는 목록이 있다.그러나 나는 전자가 서술 대신 대화방식의 지향성 때문에 불충분하고, 후자는 서열화에 사용되는 고대 영어판 때문에 불충분하다고 생각한다.

그래서 나는 "위키피디아에서 가장 흔한 영어 단어"를 만들 필요가 있다고 생각한다.왜냐하면 그렇게 되면 엄청난 수의 나라들이 합리적인 방법으로 영어 단어를 배울 수 있기 때문이다.

나는 적어도 가장 인기 있는 단어 1만개가 있는 리스트가 출판되어야 한다고 생각한다.파일 형식은 [행 번호][탭 문자][워드][탭 문자][탭 문자]와 같은 모든 행을 포함하는 일반 텍스트 파일이어야 한다.][어퍼런스 카운터]

나는 이 과제를 완성하는 두 가지 방법이 있다고 생각한다: 1.나는 프로그래머이기 때문에 그런 리스트를 만드는 대본이나 프로그램을 쓸 수 있다.이를 위해서는 일부 API에 대한 액세스가 필요하다(더미/가짜일 수 있음).그러면 내가 이 프로그램을 너에게 줄 것이고, 너는 그것들을 실제 위키백과 데이터베이스(읽기 전용 모드)에서 호출할 것이다.2. 보안(또는 다른) 이유로 이 프로젝트는 위키백과 직원이 수행할 수 있다.

어느 쪽이든 나는 이 프로젝트를 빨리 성공시키기 위해 작은 기부를 할 수 있다.나는 100달러를 기부할 수 있다.나는 그것이 하루 동안 프로그래머를 고용하는 데 고려되어야 한다고 생각한다.만약 이 금액을 지불하지 않았다면 이 프로젝트를 성공시키기 위해 얼마나 많은 돈이 필요한지 말해줘.

보바스를 존경하다

ps. 다른 나라들의 인기 단어들의 비슷한 순위가 만들어질 때 좋을 것이다.하지만 나는 이것이 영어 단어 순위만큼 급하지는 않다고 생각한다.

—Bobaskonto가 추가한 서명되지 않은 의견 준비 (대화 • 기여) 16:50, 2010년 11월 12일 (UTC)
[답글]

당신은 영어로 된 가장 흔한 단어들을 살펴본 적이 있는가, 아니면 웹에서 그와 같은 것을 검색해 본 적이 있는가?Dmcq (대화) 22:35, 2010년 11월 12일 (UTC)[응답]

안녕 보바스, 위키백과:데이터베이스 다운로드는 위키피디아 사본을 다운로드하는 방법을 알려준다.서버 유지보수 때문에 며칠 기다려야 할 수도 있고, 하드디스크에 많은 공간이 필요할 것이다.그러나 엔에 관한 그 기사들을 기억하라.위키피디아는 군중의 지혜를 이용하여 만들어졌다.중요한 것에 대한 마스터 플랜이 있는 것이 아니라, 백과사전에 각 개인이 있어야 한다고 생각하는 것 때문에 기사가 만들어지고 유지된다.그것은 산술적으로 자연스러운 물품 분배를 만들어내지 못한다.예를 들어, 대중문화에 관한 자료(영화, 노래, TV 시리즈, 트레이딩 카드 등)는 많은 편집자들이 관심을 가지고 있기 때문에 많은 자료가 있다.그것을 분석해 보면 포켓몬스터, 해리포터, 로스트 등에 대한 언급이 많이 나올 것이다.영어권 국가를 방문해서 음식을 사먹거나, 여행을 준비하거나, 좋아하는 사람과 대화를 하고 싶다면 그건 그다지 도움이 되지 않는다.선생님과 교과서 출판사에서 제공한 목록을 사용하면 영어를 더 빨리 배울 수 있을 것이다! - 포인틸리스트 (토크) 01:20, 2010년 11월 13일 (UTC)[응답]

@Dmcq

나는 영어의 가장 흔한 단어들에 대해 알지 못하지만, 그것이 가장 인기 있는 단어들인 100개의 단어들만을 포함하고 있기 때문에 그것은 나에게 쓸모없는 것이다 - 나는 100배가 더 필요하다(100개).

@포인트릴리스트

네가 할 수 있듯이 나는 이미 약간의 영어 기초 지식을 가지고 있다.하지만 나는 사람들이 기사에 쓰는 것을 잘 이해하고 싶어. 그리고 내가 중요하거나 유망하다고 생각하는 다른 문서들도 영어로 이해하고 싶어.나는 영어 기사를 이해하는 데 큰 어려움은 없지만, 좀 더 많은 것을 원한다 - 나의 목표 중 하나는 사전 사용을 거의 없애는 것이다.당신에게 위키백과 영어 기사는 학습 목적에 완벽하게 들어맞는다고 생각한다. 왜냐하면 그것은 오늘날의 영어에 대한 훌륭한 탐구이기 때문이다.더 많은 - 이것은 동기 부여된 영어 대변인에 의해 사용되는 언어에 대한 조사다.

나는 이미 이 일을 한 적이 있다. 단 한 마디의 말과 일치된 말을 위해서.내가 결과를 찾을 수 있는지 알아볼게.2010년 11월 19일(UTC) 10:06, Rich Farmbrough.
[답글]

음 나는 실제로 특정 빅그램에 대해 이 작업을 수행했지만 사용자에게 다음과 같은 거칠고 준비된 변경사항을 제공한다.리치 Farmbrough/temp110.Rich Farmbrough, 21:12, 2010년 11월 19일 (UTC)
[답글]

범주:가능성이 있는 기사

개선될 가능성이 있는 기사 카테고리를 만들어보는 건 어떨까?이 범주는 새로운 미사용 출처가 있거나, 쉽게 찾을 수 있는 정보가 없거나, 더 많은 출처를 찾을 수 있을 정도로 충분히 주목할 만한 기사 또는 기존 출처가 완전히 콘텐츠에 맞게 조정되지 않은 기사를 대상으로 한다.성장 가능성이 있는 기사를 사방으로 뒤져봐야 하는 대신 이미 모두 반올림해 작가들이 알고 있는 기사 목록에서 선택할 수 있다는 뜻. --vgmddg (룩토크 do) 02:26, 2010년 11월 14일 (UTC)[응답]

그것은 우리가 가진 모든 기사를 묘사할 것이다.2010년 11월 14일 02:29 (UTC)[응답]

그런 범주의 좋은 의도가 있건 간에, 조만간 누군가가 이 범주를 모든 기사에 추가하기 시작할 것이다. --Conti ✉ 22:41, 2010년 11월 14일 (UTC)[응답]

비슷한 것에 대한 기사가 이미 있다. 예를 들어, 소스가 없는 기사가 있는 기사에는 이미 범주가 있다.정리 태그가 일부 기사의 앞면을 장식하고 있다는 점을 지적할 가치가 있다고 생각한다.ACEOREVIVEED (토크) 22:29, 2010년 11월 14일 (UTC)[응답]

{{Cleanup}}} 태그 또는 {{Unreferenced} 태그와 같은 태그는 청소의 어려움에 관계없이 청소해야 하는 물품을 나타낸다.불행하게도, 그 문제를 해결하기 어렵거나 심지어 해결할 수 없는 경우도 있을 수 있다.내가 하고 싶은 것은 그 기사들을 분리해서 사람들이 쉽게 개선할 수 있는 기사들에 집중해서 성장을 극대화하는 것이다.위키프로젝트 비참조 기사의 토크 페이지에도 비슷한 요청을 올렸지만, 여기서는 성장 기회가 충분한 ANY 기사에 대한 일반 카테고리를 요청한다.결단력과 콘티에는 좋은 점이 있고, 그 범주에 들어가는 구체적인 기준이 있어야 한다.예를 들어 페이스북처럼 스스로 충분히 잘 된 기사는 리스트에 올라서는 안 된다. --vgmddg (룩토크 do) 01:18, 2010년 11월 15일 (UTC)[응답]

위키백과:가장 중요한 기사 중 일부와 현재 개발 수준을 나열하는 중요 기사.그것은 비슷한 도움을 준다: 비록 모든 기사가 개선될 수 있고, 이상적인 세상에서는 모든 기사가 특집되어야 하지만, 그것은 개선으로 더 많은 혜택을 받을 수 있는 기사들을 찾을 수 있다.또 다른 대안은 위키피디아 주제에 가입하여 프로젝트의 범위 내에 있는 기사에 대해 유사한 목록을 작성하는 것이다.MBelgrano (대화) 01:51, 2010년 11월 15일 (UTC)[응답]

위키백과:활력 있는 물품은 필수 물품만 추적한다.나는 개선될 수 있는 가능성이 있는 ANY* 기사를 말하는 거야.예를 들어, 2주 조금 전에 나는 블루 헤일리(Apple Computer)라는 기사에 출처를 추가했다.새로운 출처는 기사에 더 많은 정보가 추가될 수 있고, 그것이 확장될 수 있다는 것을 의미한다.하지만, 이 기사에 대한 링크들이 많지 않기 때문에, 많은 사람들이 그것을 발견하지 못했고, 실제로 그 기사에 정보를 포함시키는 것에 익숙해지지 않았다.만약 우리가 이와 같은 다른 기사들을 정리하기 위해 카테고리를 만들었다면, 사람들은 그것을 찾고 그것을 확장할 수 있을 것이다.만약 이런 식으로 충분한 기사가 확장된다면, 위키피디아는 시간이 지나면서 훨씬 더 포괄적이 될 것이고, 사람들은 확장 가능한 기사를 찾느라 시간을 낭비할 필요가 없다.

참고: "Any"는 자체적으로 포괄적일 정도로 좋지 않은 모든 기사를 의미한다. (즉, FaceBook과 같은 것이 아닌 Blue Medies(Apple Computer)와 같은 시작 클래스 기사 이하) --vgmdg (룩토크 do) 23:03, 2010년 11월 17일 (UTC)[응답]

이것은 기사를 범주별로 분류한 {{expand}}에 의해 커버되는 것처럼 들린다.확장할 기사.Rd232 15:50, 2010년 11월 18일 (UTC)[응답]

또는 실제 범주:Start-Class 기사 및 카테고리:스터브. 리치 팜브루, 10:56, 2010년 11월 19일 (UTC)
[답글]

특수 작성:올레디렉트

MediaWiki 소프트웨어에 특정 Wiki에 대한 모든 리디렉션을 나열하는 새로운 특수 페이지가 있을 수 있는가?이러한 종류의 특수 페이지의 현재 형태는 특별하다.ListRedirects(목록Redirects)이지만, 현재 비활성/비활성화되었으며 위키백과 초기에는 과거 1000개의 리디렉션에서만 작동한다.새로운 특수 페이지가 필요하며, 특수 페이지와 동일한 원칙에 기초할 것이라고 믿는다.임의 페이지 및 특수:RandomRedirect.예를 들어 사용자가 리디렉션을 모니터링하거나 복구할 수 있는 작은 위키에서 특수:와 같은 방식으로 리디렉션을 보다 잘 구성할 수 있다.AllPages는 다음과 같이 리디렉션 아래에 잘못 배치된 추가 콘텐츠를 보고 되돌리는 것과 같이, 고장 나거나 다른 방식으로 수정해야 하는 경우를 위해 작성되었다.

#REDirect [[Foo]]

Rorem ipsum dolor sit amet, consectetur adipiscising elit, sed do eiusmod timped incidunt utlobal et dolorle magna aliqua.Ut enim ad minimiminimum veniam, Quis noistudition ulamco drughis nisi ut ut aliquip ea commodo 결과.Duis aute irure dolor in repected in voluptate velit esse cillum dolor eu fugiat nulla pariatur.비동시인 오카에캣 큐피다트를 제외하고, culpa juilia deserunt mollit id imal id est lovum.

그리고 Wiktionary의 경우, 위키백과 최초 문자 자동 자본화의 이전 시스템에서 남은 불필요한 리디렉션을 사용자가 삭제하는 데 도움이 될 수 있다. : TelCoNaSpVe : 07:37, 2010년 11월 16일 (UTC)[응답]

나는 이것이 아마도 미디어위키에 대한 토론으로 제공될 것이라고 생각한다.¿SFGInts! 2010년 11월 17일 04:30 (UTC)[응답하라]

Wiktionary 작업은 데이터베이스 검색이나 SQL 쿼리를 사용하는 것이 더 나을 것이다.나는 en:wikipedia가 온위키에 있는 수백만 개의 리디렉션 목록을 볼 수 있는 효용성이 보이지 않는다. - 카테고리도 있고, 검색도 있고, 데이터 베이스 덤프도 있다(우리는 희망한다.Rich Farmbrough, 2010년 11월 19일(UTC)[응답]

이 기능을 Special로 구축하는 것:모든 페이지들이 이 문제를 해결하는 더 좋은 방법이 될 것이다.페이지가 리디렉션인지 아닌지에 대한 간단한 확인란은 사용자 관점에서 실행될 것이다. imo. --Izno (대화) 21:27, 2010년 11월 19일 (UTC)[응답]

생각해보니 스페셜:모든 페이지에는 리디렉션이 포함되어 있으므로 Special과 같이 실현 가능한 기능:AllPage/Redirect는 기능에도 유용한 제목이 될 것이다. : TelCoNaSpVe : 22:46, 2010년 11월 19일 (UTC)[응답]

광고배너

광고 현수막도 좋지만 짜증날 수 있다.닫기 버튼을 누르면 로그인하지 않으면 다음 페이지에 뜬다.배너를 영구적으로 닫는 버튼 하나만 있으면 안 될까?WikiCopter (라디오 • 정렬 • 이미지 • 손실 • 방어 • 공격) 23:29, 2010년 11월 17일 (UTC)[응답]

• 로그아웃되면 IP주소에 있고, 다음번 리더에게 주소가 순환될 때 이전에 IP주소의 점유자였던 당신이 그것을 영구적으로 닫으면 배너는 어떻게 나타날까? : TelCoNaSpVe : 2010년 11월 17일 (UTC)[응답]

분명한 해결책은 로그인한 채로 자금 조달자 가젯을 원하는 대로 사용하는 것이다.하지만 엄밀히 말하면, 당신이 모금 행사를 몇 번 닫은 후에 당신의 브라우저가 인기를 끌어야 한다. 그래서 나는 당신이 로그인했든 안 했든 상관없이 읽는다.인텔리전트시움 23:41, 2010년 11월 17일 (UTC)[응답]

위키백과 와이드, 위키백과 등 쿠키에 의해 억제될 수 있다.별거 아니지만, 다른 위키에 방문하거나, 다른 브라우저를 사용하거나, 계정을 변경할 때마다, 그는...Rich Farmbrough, 09:58, 2010년 11월 19일 (UTC)
[답글]

고마워 Intelligentsium (그리고 오랜만에 입력 :P) 나는 "가젯"을 몰랐어.Mlpearc wow 13:39, 2010년 11월 19일 (UTC)[응답]

지미 웨일스를 위한 어필 아이디어

지미 웨일즈에게, 나는 위키에서 당신의 호소를 보았고 그것은 좋은 생각이라고 생각한다.불행히도 인터넷을 사용하는 사람들은 인터넷 사용이 항상 그렇지는 않지만 무료여야 한다고 생각한다.내 생각은 간단하다: 위키를 구하기 위해 기부하는 사람들에게 작은 선물(의미 있는)을 제공하라. 즉, 만약 누군가가 20달러를 기부한다면 당신은 위키의 2011년 가장 흥미로운 사실이 담긴 펜 드라이브를 그들에게 보낼 수 있다./ 나는 당신이 더 많은 기부를 받을 것이라고 확신한다.생각일 뿐이야.잘했어, 조

비슷한 모금 제도가 몇 년 전부터 사용돼 왔고, 재단이 결과에 만족하고 있는 것으로 알고 있어 기부 의향이 있는 사람도 부족하지 않다.모두에게 선물을 보내는 것은 매우 비현실적일 것이다.나는 WMF가 수십만 개의 소포를 분배할 물류 인프라를 갖추고 있다고 생각하지 않으며, 기부금의 대부분이 소량이고, 전 세계에서 많은 사람들이 온다는 점을 고려하면, 운임 비용은 수입의 비비례적인 부분을 소비할 것이다.돈을 벌기 위해 뭔가 확실한 것을 얻어야 하는 사람들을 위해, 항상 상품이 있다.—Emil J. 12:29, 2010년 11월 19일 (UTC)[응답]

호소력 향상: 과도한 개인 설정 방지

친애하는 지미 웨일즈에게, 나는 위에 있는 사람이 아니지만, 나 역시 당신의 호소를 읽었고, 나는 지난 몇 달 동안 내가 찾고 있던 콘테트보다 위키피디아에서 당신의 얼굴과 호소를 더 자주 보았고, 그들이 너무나 자주 그리고 눈에 띄게 등장했다는 것을 알게 되었다.그렇게 친절하게 호소를 해도 얼굴이라도 빼줄 수 있겠소?솔직히, 그것은 위키백과 서퍼가 찾고 있는 것이 아닌 일종의 시각적 영향을 준다.물론 위키피디아는 자금 부족으로 인해 문을 닫거나 닫지 못할 수도 있다.하지만 두 경우 모두, 지금쯤이면 솔직히 과도한 빈도로 당신의 얼굴 특징을 관리할 충분한 이유가 되지 않는다.이것이 당신이 듣고 싶었던 것이 아니라면, 나는 단지 솔직할 뿐이고 나는 당신이 그들을 후보 배우로서의 개인적인 명성을 위해 대리인으로 이용하는 것을 피한다면 당신의 호소가 더 나을 것이라고 생각한다 - 당신은 지금쯤 이 인상을 주고 있고, 나는 그것이 당신의 원래 의도는 아니었다고 확신한다.당신의 호소를 페이스 샷과 자주 결합하는 것은 당신의 의도에 정말 해롭다.— 94.34.246.114 (대화) 18:54, 2011년 11월 18일 (UTC)[응답]이(가) 추가된 선행 미서명 의견

입력 임의화

분쟁 해결을 위한 여러 가지 문제들 중 하나는 충분한 외부 의견을 얻지 못하는 것이다. 즉, 이전에 관련되지 않은 사람들로부터 그 문제를 진지하게 받아들일 의사가 없는 사람들로부터 의견을 받는 것이다.나의 제안은 (아마도 현재 RFC 세분화와 유사한) 다양한 주제로 나누어진, 편집자의 목록이나 범주 시스템을 만드는 것이다. 봇은 임의로 다수의 편집자가 자신의 입력을 요청하도록 (대화 페이지의 게시물을 통해) 또는 가능하면 이메일을 통해, 편집자가 원할 경우, 그들의 입력을 요청하는 것이다.이러한 편집자의 입력은 다른 어떤 편집자의 입력보다 더 큰 비중을 차지하지 않으며, 입력 요청을 이행할 필요도 없다. 그러나 그것은 많은 낮은 가시성 RFC에서 입력의 다양성을 장려함으로써 RFC를 더 효과적으로 만들 수 있다.그리고 콘텐츠 RFC를 보다 효과적으로 만드는 데 성공한다면, 콘텐츠 RFC를 더 자주 사용할 수 있으며, 문제가 사용자 행동 문제로 확대되는 것을 방지하는 데 도움이 될 수 있다.Rd232 15:44, 2010년 11월 18일 (UTC)[응답]

PS가 하나의 가능한 응답을 예상하는 경우: 편집자는 RFC 목록을 모니터링하는 것보다 자신의 토크 페이지나 이메일을 통해 특정 요청에 응답할 가능성이 훨씬 높다(WP의 상자:현재 접근 방식인 감시 목록을 통해 RFC).Rd232^talk 15:47, 2010년 11월 18일 (UTC)[응답]

왜 무작위화하지?만약 사람들이 자원봉사를 했다면 왜 그냥 그들 모두에게 물어보지 않았을까?물론 자원봉사자를 충분히 확보할 수 있을지는 흥미로울 것이다.

또한, 나는 이것을 공식적인 RfC 접근방식으로 제한할 이유가 없다고 본다.안내판에도 정확히 같은 문제가 적용된다.그것들은 공식적으로 그렇게 불리지 않았지만 사실상 RfCs이다.피터 잭슨 (토크) 2010년 11월 18일 (UTC) 18:12 (응답)

왜 무작위화하지?왜냐하면 그것이 작동하기 위해서는 당신은 자원봉사를 하는 꽤 많은 사용자들의 리스트가 필요하기 때문이다. 그리고 대부분의 RFC들은 100명의 사람들이 올 필요가 없을 것이다.또한 만약 사람들이, 예를 들어, 4명의 다른 사람들이 질문을 받았다는 것을 안다면, 그들은 응답할 가능성이 더 높다; 만약 수백명의 사람들이 질문을 받았다면, 그것은 개인적인 요청이라기 보다는 "당신이 관심을 가질 수 있는 뉴스"에 가깝다.왜 RFC인가? 구조적으로 적합하고 접근법을 테스트할 수 있는 좋은 방법이기 때문이다.만약 그것이 효과가 있다면, 그것을 게시판에 적용하는 것이 조금 더 까다로울 수도 있지만 아마 그렇게 많이는 아닐 것이다.Rd232^talk 18:56, 2010년 11월 18일 (UTC)[응답]

"수백 명이 질문을 받았다면..증거가 필요해나는 그것을 다르게 본다: 자원 봉사자들의 풀이 너무 작아서 무작위화 할 수 없다. (그것은 모든 "우리에게 충분한 증거가 없다"와 같이)" 성명서).사용자 대화 페이지에 매주 알림을 게시하는 간단한 구독을 시도해 보십시오.시그널 포스트는 이미 진행 중인 RFAR과 보류 중인 RFAR에 대해 보고했으며 RFC는 크게 다르지 않다.그러나 누군가는 이러한 사례들을 검토하고 간략하고 입맛에 맞는 개요를 써야 한다 - WP의 모호한 내용보다 더 나은 것.RFC. 보르쇼프 동부 2010년 11월 19일 (UTC)[응답]

RFCs는 그것보다 더 빠른 외부 반응이 필요한 경향이 있다.하지만 더 많은 입력을 필요로 하는 더 큰 사람들을 위해, 그렇다, 모든 수단을 동원해서 그것들을 써서 표지판에 언급하자.그리고 이것은 피터 잭슨의 논점과 더 아래로 깔끔하게 연결된다.Rd232 17:08, 2010년 11월 19일 (UTC)[응답]

선택권을 제외한 배심원 명단 같은 거지나한테는 아주 좋은 생각인 것 같아.Dmcq (대화) 18:48, 2010년 11월 18일 (UTC)[응답]

그것은 약간 그렇다 - 게다가, 누구나 궁정에 모습을 드러내는 것 만으로도 배심원에 오를 수 있다는 것을 제외한다면;) 은유법이 사람들을 혼란스럽게 하지 않도록 주의해야 한다: 그래서 요청된 입력은 다른 어떤 것보다 높은 지위를 가지고 있지 않다.Rd232 19:00, 2010년 11월 18일 (UTC)[응답]

과도한 스팸 없이 편집자를 보다 선택적으로 끌어들이는데 실제로 유용하게 들린다.— HELLKOWNZ ▎TOK 19:00, 2010년 11월 18일 (UTC)[응답]

나는 사실 이 아이디어를 한동안 곰곰이 생각해 보았는데, '주르'의 풀(pool)을 만들기 위한 소프트웨어를 만드는 것은 비교적 쉬운데, 우리는 단지 많은 풀(pool)을 구해서 그들이 들을 수 있는 '사례(case)'를 요청하는 구조를 만들면 된다.ΔT 19:02, 2010년 11월 18일 (UTC)[응답]

멋지다 - 하지만 내가 RFCs에 대해 이야기한 이유 중 하나는 새로운 프로세스를 만드는 것을 피하기 위함이다. 이것은 기존 프로세스를 더 잘 작동하게 할 것이다.그 일환으로, 제발 "juror" / "case" 은유에서 물러나자!기존의 RFC 구조는 명확한 질문들을 제공한다; 목록이나 범주에서 무작위로 사람을 선택하고 그들에게 흥미로운 질문 삽입을 포함하는 새로운 RFC X에 대한 입력을 요구하는 메시지를 보내는 기술적 측면은 간단해야 하며, 지나친 불만사항으로 그 누구도 화나게 해서는 안 된다, WP:CREEP, WP:NOT 등Rd232 19:11, 2010년 11월 18일 (UTC)[응답]

나는 이것이 (RFCs 등에 더 많은 외부 시선을 보내는) 무엇을 다루기 위해 고안된 것인지 이해한다고 생각하지만, 나는 이 제안이 장기적으로 어떤 개선으로 이어질 것이라고 생각하지 않는다.문제는 기꺼이 의견을 묻는 편집자를 찾는 것이 아니라, 실제로 그렇게 하는 편집자를 기꺼이 의견을 주는 편집자를 찾는 것이다."할 용의가 있는 편집자"와 "참가하는 편집자"의 많은 프로젝트 공간 목록을 살펴보십시오.그들은 더 이상 원하지 않거나, 더 이상 참여하지 않거나, 더 이상 컴퓨터를 가지고 있지 않은 편집자들의 이름들로 가득 차 있다.이 목록 역시 필연적으로 실제 유효한 안타를 얻는 것이 불가능해지는 크기로 커질 것이다.물론, 봇은 최근의 활동을 확인할 수 있지만, 얼마나 많은 통지가 발행되어야 하는지를 결정하기 위해 대응력을 측정해야 할 것이다.그리고 새로 오는 사람들은 거대한 이름들의 목록을 보고 "오, 글쎄, 벌써 300명이 가입했어"라고 생각하고 그것에 관여하지 않을 것이다.봇 메시지에 대한 옵트인 리스트를 갖는 것은 큰 해는 없지만, 나는 최종 결과가 큰 목적 없이 운영되는 봇에 불과할 것이라고 생각한다.외부 의견을 기꺼이 내는 편집자들은 아마 이미 그렇게 했을 것이다.더 찾아내는 것도 문제지만 사회문제고 (배심원의무나 병역기피처럼 의무화되지 않는 한) 사회문제에 대한 자동화된 해결책은 거의 효과가 없다.프라나맥스 (대화) 2010년 11월 18일 19:57 (UTC)[응답]

너의 요점은 이해하지만, 나는 네가 이 접근방식의 부가가치를 과소평가한다고 생각해.그렇다, 봇은 편집의 빈도를 고려하기 때문에 목록이나 범주가 점차 비활성 편집기로 채워지는 것은 문제가 되지 않는다.중요한 것은, 5명의 사람들이 물어본 것처럼, 토크 페이지나 이메일을 통해, 특정 요청을 받고 접근한 편집자들의 경우, RFC가 당신의 감시 목록에 올라오거나, 드물게 편집된 위키프로젝트 페이지에 당신의 이름을 올린 것과는 매우 다르다는 것이다.지원 미달 대상자와 교전하는 시스템인데, RFC에 효과가 있다면 다른 용도로도 교전할 수 있다.Rd232^talk 20:50, 2010년 11월 18일 (UTC)[응답]

그래, 여기 어디에도 별자리 3쿼터, 반대 3쿼터를 넣지 않을 거야.나는 내가 오랫동안 생각해왔던 것을 하고, RFCs와 "자원봉사" 의무를 수행하기 위해 종종 내 시간의 일부를 잘라내는 훈련을 받았으면 좋겠다.나는 단지 나에게 봇이 잔소리를 해도 잘 대답하지 못할 것 같아.나는 "당신이 봉사해 달라고 요청했고, 여기 당신이 봉사할 수 있는 곳이 있다"의 가치를 알 수 있다.그러나 나의 힐로이 나선형 속박에는 이미 많은 "자아에 대한 노트"가 들어 있고, 항상 다른 현안이 있는 것 같아서, 나는 그냥 끼어들지 않을 것 같다.내가 부가가치를 과소평가하는 것은 확실히 가능한 일이고, 나는 그것이 적어도 짧은 시간 동안 RFC에 대한 외부 투입을 유익하게 증가시킬 것이라고 생각한다.하지만 나는 그것이 그 자체의 무게로 무너질 것이라는 나의 예측을 지지할 것이고, 나는 틀렸다는 것이 증명되어 기쁘다.프라나맥스 (대화) 22:38, 2010년 11월 18일 (UTC)[응답]

또한, 이것의 장점 중 하나는 궁극적으로 어떤 가입 시스템이 사용되든 환영 메시지 등에서 연결될 수 있기 때문에, 그것은 새로운 편집자들이 즉각적인 관심사를 넘어서는 주제를 가지고 새로운 편집자들을 참여시키도록 돕는 또 다른 경로가 된다는 것이다.일상적인 편집자들을 위키피디아어로 바꾸는 것은 우리가 더 열심히 노력해야 할 중요한 일들 중 하나이며, 나는 이것이 조금 도움이 될 것이라고 생각한다.Rd232 20:55, 2010년 11월 18일 (UTC)[응답]

웃기게도, 내가 다른 쪽으로부터 이것에 대해 생각하고 있었기 때문에, "나는 2달 전에 NoticeBot에 가입했는데, 나는 대부분 표절이 없는 DYK가 있는데, 내가 3일 동안 롤백을 남용한 적이 없는데, 지금 내가 관리자가 될 수 있을까?"와 같이, 내가 반대편에서 이 문제에 대해 생각하고 있었기 때문에, 그것을 언급해야 한다.분쟁 해결은 아마도 새로운 편집자가 그들의 발을 적시는 데 가장 좋은 분야는 아닐 것이다. (그러나 나는 그것이 아마도 당신의 차고 밴드에서 당신의 기사를 옹호하는 것보다 더 잘 될 것이라고 인정한다.)나는 아마도 그 주제에 대해 너무 냉소적일 것이고 새로운 사람들에게 그들이 기여할 수 있는 많은 분야에 대해 알리는 것이 중요하다는 것을 알고 있다.그러나 환영 템플릿에서, "지금 당장 할 수 있다"에서처럼?프라나맥스 (대화) 21:58, 2010년 11월 18일 (UTC)[응답]

새로운 사용자들은 때때로 단지 투표하는 것 대신에 실제로 다른 것을 읽고 역사를 편집하는 인내심을 가지고 있다.하지만 때때로 그들은 그렇지 않다.Rich Farmbrough, 21:16, 2010년 11월 19일 (UTC)
[답글]

응, 그런 것 같아.그들이 엄청난 기득권을 가지고 있지 않은 콘텐츠 RFC에 대해 언급하는 것은 새로운 사람들이 그 요령을 배울 수 있는 좋은 방법이라고 생각한다. 그리고 무작위성 때문에, 가입 직후에 질문을 받지는 않을 것이다.어떤 것이든 바우블로서 비하될 수 있으므로 나는 그것을 할인한다.그리고 RFC에 대한 기여도는 DYK의 수보다 단순하게 측정 가능하지 않기 때문에, 그것은 문제가 되지 않는다.Rd232^talk 22:21, 2010년 11월 18일 (UTC)[응답]

아직도 마음에 안 들어.완전히 공개해야 할 것이다.새롭고 열정적인 편집자가 코멘트의 의무로 취급하고 싶은 것에 가입하여 "당신은 RFC에서 코멘트를 하도록 초대받았다"라는 봇 메시지를 받고 기후 연구 부서가 무엇이고 훔치고, 해킹하고, 누설하는 것의 차이점이 무엇인지 생각하면서 내가 뭔가를 말해야 한다는 것을 알게 되면 어떨까?그리고 두 명의 오랜 기사 작가들 사이에 논쟁거리가 있는 곳에, 비록 여러분이 동의한다 하더라도, 작은 부정확성으로 인해 여러분의 머리를 쥐어뜯을 수 있는 난이도 등급 체계가 있을까?무작위 임무는 새로운 편집자들이 존재조차 몰랐던 상황에 무작위로 투입하고, 그들이 가라앉는지, 수영을 하는지, 아니면 그만두는지 무작위로 찾아내는 것과 같다.만약 그들이 그걸 알고 있다면, 문제 없어.프라나맥스 (대화) 23:50, 2010년 11월 18일 (UTC)[응답]

글쎄, 내가 말했듯이, 그들은 가입하고 나서 바로 요청을 받을 것 같지 않아.그러나 더 중요한 것은, 그 목적은 주어진 RFC에 몇 명의 새로운 사람들을 참여시키는 것이 될 것이며, 그들 중 일부는 다른 사람들보다 경험이 많을 것이다.그들이 뚜렷한 이유 없이 나타나기 보다는 봇에 의해 선택되었다는 사실만으로도 양말/미트푸펫이 이슈가 되는 이런 상황들 중 일부에서는 AGF에 도움이 될 것이다.또한, 이러한 종류의 기사의 토크 페이지에는 종종 "논쟁 주제" 경고 라벨 또는 중재 집행과 관련된 템플릿이 있는데, 이는 봇이 주의해서 통보 메시지에 적절히 구울 수도 있다.Rd232^talk 00:30, 2010년 11월 19일 (UTC)[응답]

나는 이미 이런 종류의 일을 하기 위한 조잡한 "로타" 코드를 가지고 있고, 나는 로타 기반의 시스템이 무작위화된 시스템보다 더 낫다고 생각한다.부하에 비해 목록과 응답이 충분히 크면, 원하는 경우 한동안 요청을 받지 않은 자와 응답하지 않은 자에 우선순위를 매기는 것이 가능해진다.이것은 리스트에 "앉아" 있는 사람은 그들이 관여하거나 그들의 이름을 뽑을 때까지 더 많은 초대장을 받게 된다는 것을 의미하며, 그래서 리스트를 정리하는 것을 돕는다.Rich Farmbrough, 09:56, 2010년 11월 19일 (UTC)
[답글]

나는 그 단순함과 철학적인 접근법 때문에 무작위화가 좋긴 하지만 (어쩌면 로타가 나를 불쾌하게 하는 것처럼 들림) 나는 당신이 부하를 분산시키는 것에 대한 요점을 알고 있다.우리는 그 시스템이 예측가능하지 않게 확실히 하고 싶다.Rd232 11:20, 2010년 11월 19일 (UTC)[응답]

2008년에 많은 RfC에 응답하는 데 몇 주(몇 주)를 보냈다.종종 나 혼자였다.피터 잭슨 (토크) 2010년 11월 19일 (UTC) 11시 34분[응답]

이제 네가 언급했듯이, 나도 같은 경험을 했던 기억이 난다.이것으로부터 어떤 특별한 결론을 얻으십니까?Rd232^talk 12:07, 2010년 11월 19일 (UTC)[응답]

1. 뭔가 조치를 취해야 한다.
2. 이 제안이 효과가 있을지는 의문이다(원칙적으로는 좋은 생각이지만)

피터 잭슨 (토크) 2010년 11월 19일 (UTC) 14:44[응답]

(a) 왜 그것이 의심스러운가? (b) 그것이 작동하기 더 쉽도록 하기 위해 무엇을 할 수 있는가?Rd232^talk 15:01, 2010년 11월 19일 (UTC)[응답]

글쎄, 네가 말하는 케이스에 따라 다를지도 몰라.당신은 위에서 "대부분의 RFCs는 100명의 사람들이 올 필요가 없을 것"이라고 말했다.그건 사실일 거야, 하지만 네 시스템은 어떻게 구별할 수 있지?당신이 100명의 편집자를 찾아야 하는 경우는 편집자의 카발(cabal)이 기사를 소유하고 있는 경우들이다.그 시스템은 그 사건들과 나머지 사건들을 어떻게 구별할 것인가?특히 편집자의 카발(NPA, AGF)이 기사를 소유한다고 말할 수 없을 때 더욱 그렇다.보통의 경우라면, 나는 단지 당신이 필요한 승수를 얻을 수 있을지는 의심스럽다고 생각한다.명심해, 만약 내가 종종 유일한 응답자였다면, 많은 시간 동안 아무도 응답하지 않는다는 것을.당신은 개선하려고 노력할 수 있는 아주 낮은 기준을 가지고 있다.피터 잭슨 (토크) 2010년 11월 19일 (UTC) 16:36[응답]

위의 보르쇼프 동부에 대한 나의 반응을 보아라, 나는 이것을 다소 깔끔하게 연결한다고 생각한다.이 제안서는 "더 작은" RFC를 처리하며, 필요한 입력은 더 적다.더 많은 입력이 필요한 경우, 참가자는 그것을 인식하고 모호한 내용이나 요약문을 작성할 수 있으며(또는 원래 질문을 반복할 뿐), 더 넓은 입력을 위해(그리고 아마도 입력을 위한 추가적인 무작위 요청을 위한 메커니즘을 위해) 표지판에 제출할 수 있다.그래서 당신의 주요 질문에 답하기 위해: 더 많은 편집자 입력이 필요한 경우는 참가자들에 의해 확인될 것이고, 더 많은 입력을 요구하는 명확한 경로가 있어야 한다.Rd232 17:08, 2010년 11월 19일 (UTC)[응답]

시험

좋아, 누가 이걸 시도해보는 것에 대해 구체적으로 반대하는 사람 있어?내가 보는 주요 관심사는 잠재적으로 편집자들을 전쟁터 영역으로 버리는 것이지만, 입력 요청서에는 대화 페이지에서 관련 템플릿이 감지될 경우 일반적인 경고와 특정 경고가 포함될 수 있다.그리고 아마도 시험 단계에서는 새로운 편집자들이 제외될 수 있을 것이다(예: < 100개의 토크 스페이스 편집) 우리가 그것이 어떻게 작동하는지 어느 정도 이해할 때까지.댓글?Rd232 00:55, 2010년 11월 22일 (UTC)[응답]

사용[[diff:$1]]그리고[[oldid:$1]]

이 두 접두사를 인터위키스(interwikis)로 만들어 wiki 내의 특정 개정 번호(예: http://en.wikipedia.org/w/index.php?diff=397820813를 http://en.wikipedia.org/w/index.php?diff=397820813로 참조)를 참조할 수 있는가?[[diff:397820813]]? 특정 숫자를 참조하면 wiki 구문을 보존하기 때문에 반복적으로 사용해야 하는 것은 무엇인가?<span class=plainlinks>예를 들어, 다른 위키의 확산에 대한 보다 쉬운 참조를 참조하십시오.[[:ar:wikt:diff:12345]]. : TelCoNaSpV : 01:45, 2010년 11월 21일 (UTC)[응답]

그러한 시스템이 보안 서버를 올바르게 지원하는 경우(독자가 사용하고 있는 서버와의 링크, la)에는 매우 감사할 것이다.{{FULLURL}}). 또한 diff:와 oldid: 같은 링크에서 어떻게 사용할 것인가? --NYKevin @273, 즉 05:33, 2010년 11월 21일 (UTC)[응답]

왜 두 가지를 다 사용해야 하는 거지?IMO, 특정 개정판을 보여주려면 하나만 있으면 된다. : TelCoNaSpVe : 05:42, 2010년 11월 21일 (UTC)[응답]

URL로 디프 링크를 만들 때는 플레인링크를 사용하지 않으며, 이렇게 해도 링크 제작에 필요한 추가 작업으로 인해 거의 사용하지 않을 것({{diff}, {{oldid} 등)을 볼 수 있을 것이다.미스터 지맨 06:00, 2010년 11월 21일 (UTC)[응답]

{{Commons cat}, {{Commons} 또는 {{Commons 및 범주}} 추가

안녕! 여기와 여기엔 아무런 회신이 없었으니, 여기 제안이 있다.

• 제안: {{Commons cat}, {{Commons} 또는 {{Commons 및 범주}}}}이(가) 포함되어 있지 않지만 Commons에 특정 범주 또는 페이지가 있는 경우, 이러한 템플릿을 추가하는 것이 좋다.
  • Commons on Commons가 범주 및 페이지(갤러리) 모두 존재하는 경우, 갤러리 페이지는 대개 관리 상태가 좋지 않으므로 {{Commons}}보다 항상 {{Commons}을(를) 선호해야 하며, 갤러리 자체는 실제 값을 거의 추가하지 않는다.범주는 관리 및 스케일업(하위 범주 추가)이 더 쉽다.게다가 잘 쓰여지고 잘 꾸며진 갤러리 페이지는 대개 en.wiki로부터 이미 연결되어 있다.
  • {{Sister 프로젝트 링크}}}의 존재는 {{Commons cat} 또는 {{Commons}}}의 삽입에 영향을 미치지 않아야 하는데, 이는 {{Sister 프로젝트 링크}}}}이(가) 단순히 "다양한 위키미디어 자매 프로젝트의 '검색' 페이지에 링크를 제공"한다는 점에 유의해야 하기 때문이다.관련 콘텐츠가 실제로 존재한다는 것을 인정하지 않고 (눈먼) 추측에 불과하다는 뜻이다.{{Commons}, {{Commons cat}}} 대신 Wikimedia Commons가 실제로 대상과 관련된 미디어를 보유하고 있다고 명시하고 이에 대한 링크를 제공한다.이것은 귀중한 정보다.검색 기능과 링크의 차이점이다.
  • 이 과정이 봇을 통해 안전하게 수행될 수 있는 몇 가지 사례가 있다.난 그걸 하려고 노력중이지만 아무도 이 문제에 신경 쓰지 않고 BRFA가 기다리고 있어...

이 제안이 타당하다고 생각될 경우, 여기에 쓰십시오(또는 아래)."아까... 합리적인 것 같다"고 말하고 서명했다.;)고맙다. -- 바실리코프레스코 (msg) 08:45, 2010년 11월 21일 (UTC)[응답하라]

새 편집 알림:템플릿:편집 공지사항/페이지/위키피디아 대화:사용자 페이지

최근 위키백과에서 스팸이 많이 올라왔기 때문에:사용자 페이지, 나는 이 문제를 완화하는 방법은 새로운 편집자 경고 사용자들이 광고 자료를 대화 페이지에 올리지 않도록 하는 것이라고 생각한다.그것은 "관심:위키백과의 변경사항을 논의하기 위한 토픽페이지 입니다.사용자 페이지에 대한 사용자 페이지 가이드라인(광고 자료나 사용자 페이지에 글을 게시하는 것이 아님) : TelCoNaSpVe : 2010년 11월 21일 (UTC)[응답]

이의는 없지만 아마 막지 못할 것이다.) 아노미에 15:10, 2010년 11월 21일 (UTC)[응답]

대담하게 해냈다.Rd232 16:28, 2010년 11월 21일 (UTC)[응답]

새로운 사용자 권한 제안

최근에 후보자에게 관리자 도구의 특정 영역이 필요한 RFA가 몇 개 있었지만, 모두 필요한 것은 아니라는 것을 알았다.많은 사용자들은 일부 툴이 유용하다고 생각하지만, 모든 툴은 유용하지 않다.관리자 업무는 크게 세 가지 영역이 있다.나는 관리자 권한을 구역으로 나누는 것을 둘러싸고 몇 번의 논쟁이 있었다는 것을 알고 있다.나는 몇 가지 사용자 권리를 추가할 것을 제안한다.이러한 권한은 위키백과의 관리자 또는 관료들에 의해 신뢰할 수 있는 사용자에게 부여될 것이다.관료들에 의해 허가 요청 및 취소된 이러한 권한은 표준 시스템 운영권을 대체하지 못할 것이다.일반적으로 sysops용으로 예약된 특정 도구가 유용할 수 있는 특정 영역에서 작업하는 편집자를 돕기 위한 것이지만 전체 sysops를 올바르게 사용하고 싶지는 않다.또한 행정가와 비행정가 사이의 "권한 격차"를 줄일 수 있을 것이다.내가 제안하는 권리는 다음과 같다.생각? --Alpha Quadrant 19:04, 2010년 10월 27일 (UTC)[응답]

일반적으로 우리는 블록, 삭제권, 그리고 다른 사람들에게 사용자 권리를 주는 능력이 이 모든 것에서 가장 논란이 많은 권리는 아닐 것이라고 생각하는 바보가 될 것이다.만약 이게 전화를 끊는 거라면, 오른쪽 X가 무리에서 제외된다고 가정하면 이걸 지지할 수 있을 거라고 말해줘."파일 업로더"는 삭제 권한이 없는 파일 업로더에게 여전히 놀라운 권리일 것이고, "패트롤러"는 반달 파이터들이 그들을 차단할 능력이 없더라도 훨씬 더 효율적으로 파일 업로더를 이용할 수 있게 해줄 것이다.만약 권리들이 일괄 처리되기 보다는 모듈화 되어 있다면, 파일이나 템플릿에서 정리를 하고 싶은 사람들은 (예를 들어) "음, 나는 당신의 파일 작업이 좋지만, 당신이 도구를 얻을 수 있는 충분한 반달 전투 경험이 있다고 생각하지 않아" 등의 반대 때문에 그들의 열정을 꺾을 필요가 없을 것이다.다른 임의의 지연헤드폭탄 {토크 / 기여 / 물리학 / 책} 2010년 10월 27일 (UTC) 20:06, 응답하라]

내가 제안한 도구는 결코 롤백처럼 주어지지 않는다.특정 도구로 사용자를 신뢰할 수 있는지 여부를 평가하는 엄격한 과정이 있을 것이다.그것은 RFA를 대체하기 위한 것이 아니며 결코 그렇지 않을 것이다.모듈 도구를 나눠주는 것은 특정 영역에서 충분한 작업이 없는 신뢰할 수 있는 편집자를 만드는 것을 의미할 뿐이다.보통 지역사회는 편집자에게 전체 관리자 보따리를 주는 것에 안전하게 동의할 수 없을 것이다.이 제안은 잠재적으로 많은 신규 사용자가 존재한다고 가정하는 피소된 "카스트 시스템"을 제거할 수 있다.그것은 잠재적으로 RFA를 질식하게 만들 수 있는데, 관리자가 먼저 모듈을 신청하도록 한 다음 나중에 관리직을 신청하면 지역사회가 편집자를 더 쉽게 평가할 수 있을 것이다.당연히 편집자들은 적절한 RFA 없이 세 모듈로부터 모두 접근하는 것이 금지될 것이다.관리자 그룹에 제한되는 몇 가지 도구가 있을 것이다.편집 필터, 편집 인터페이스 및 다른 사용자의 .js 및 .css는 관리자로 제한된다.그 도구들은 전체 관리자보다 제거하기가 더 쉬울 것이다. 왜냐하면 어떤 관료들도 그것들을 남용한다면 제거할 수 있기 때문이다.도구의 일부만 제공되기 때문에 표준은 RFA보다 다소 낮을 것이다.허스폴드는 그 제안에서 한 가지 이슈를 지적했다.만약 모듈 아이디어가 성공한다면, "퍼지" 모듈을 가진 편집자가 지속적인 공격 페이지 반달과 마주친다면, 그들은 그것들을 막을 수 없을 것이다.편집자는 AIV에 보고서를 제출하여 전체 관리자 또는 "패트롤러"가 반달 행위를 차단하도록 할 수 있다.이는 롤백업자가 한 페이지에서 지속적인 반달리즘을 접하는 페이지를 발견했을 때 RFPP에 요청을 하는 것과 다를 바 없다.

제안된 사용자 권한

*최초 제안된 3가지 권한은 관리자 또는 관료에 의해 부여되며, 남용될 경우 관료에 의해 취소됨.관리자 권한 요청 시 "플로더" 및 "파일 업로더"가 허가 및 해지될 수 있다.자세한 내용은 관련 페이지와 아래를 참조하십시오. 관련 페이지: 위키백과:도구 요청 안내서 위키백과:도구 요청 패트롤러 - 최근의 변화를 순찰하고 반달리즘을 되돌리는 반달리즘 투사들.반달에 대한 적절한 경고 및 보고 기록이 우수한 믿을 만한 반달 투사가 있는 사용자에게 할당될 수 있다. 사용자의 전자 메일 전송 차단(블록메일) 다른 사용자의 편집 차단(차단) 로컬에서 전역 블록 사용 안 함(글로벌 블록-화이트리스트) 자신의 수정본을 자동으로 "수락됨"으로 표시(자동 보기) 수정본을 "수락됨"으로 표시(검토) 다른 사람의 편집 내용을 순찰(패트롤)으로 표시 자신의 편집 내용을 자동으로 순열로 표시(자동 제어) 특정 페이지를 편집한 마지막 사용자의 편집 내용을 신속하게 롤백(롤백) 지정된 남용 필터를 통해 모든 변경 사항 되돌리기(오버스필터-반전) 페이지를 이동할 때 원본 페이지에서 리디렉션을 만들지 않음(압축된 간접) 확장 소프트웨어 버전 정보 표시(버전 세부 정보) 속도 제한에 영향을 받지 않음(노르테리미트) API 쿼리에 더 높은 제한 사용(apihighlimits) 승인된 최신 개정판을 선택하고 표시하는 방법 구성(테이블셋팅) 프록시의 자동 블록 바이패스(프록시 해제 가능) IP 블록 바이패스, 자동 차단 및 범위 블록(ipblock-exe) 개인으로 표시된 남용 필터 보기(abusefilter-view-private) 자세한 남용 로그 항목 보기(유용필터-log-detail) 제목 블랙리스트 재정의(tboverride) 다른 사용자(사용자 권한)의 사용자 그룹 변경 +/- 필터 관리자 편집 +/-IP 블록 예외 +/-롤백 +/- 검토자 보호자 - 페이지 이동 및 기사 개선 등 다양한 정리 작업을 수행하는 사용자작업 유지보수와 컨텐츠 개선 영역을 잘 수행하는 편집자에게 할당될 것이다. 보호 수준 변경 및 보호된 페이지 편집(보호) 페이지 이동(이동) 파일 이동(파일 이동) 보류 중인 변경사항으로 페이지 이동(동영상) 승인된 최신 개정판을 선택하고 표시하는 방법 구성(테이블셋팅) 다른 사용자의 CSS 파일 편집(editusercss) 다른 사용자의 JS 파일 편집(편집자j) 반보호된 페이지 편집(자동 확인) 사용자 인터페이스 편집(인터페이스 편집) 감시되지 않은 페이지 목록 보기(보이지 않은 페이지) 하위 페이지를 사용하여 페이지 이동(하위 페이지 이동) 루트 사용자 페이지 이동(루트 사용자 페이지 이동) 페이지를 이동할 때 원본 페이지에서 리디렉션을 만들지 않음(리디렉트 중압) 확장 소프트웨어 버전 정보 표시(버전 세부 정보) 속도 제한에 영향을 받지 않음(노르테리미트) API 쿼리에 더 높은 제한 사용(apihighlimits) 제목 블랙리스트 재정의(tboverride) 스푸핑 체크 오버라이드(오버라이드 앤티스푸핑) 자신의 수정본을 자동으로 "수락됨"으로 표시(자동 보기) 수정본을 "수락됨"으로 표시(검토) 다른 사람의 편집 내용을 순찰(패트롤)으로 표시 자신의 편집 내용을 자동으로 순열로 표시(자동 제어) 다른 사용자(사용자 권한)의 사용자 그룹 변경 +/- 롤백 +/- 검토자 +/- 확인 +/- 자동 등록 +/- 계정 생성자 Purger - New Page 순찰 업무에 신뢰받는 사용자 및 AFD에서의 좋은 작업과 CSD를 적절히 사용하는 사용자에게 할당될 것이다. 페이지의 특정 수정사항 삭제 및 삭제 취소(삭제 수정) 페이지 삭제(삭제) 페이지 삭제 취소(삭제 취소) 관련 텍스트 없이 삭제된 기록 항목 보기(삭제된 기록) 삭제된 텍스트 및 삭제된 수정사항 간의 변경사항 보기(삭제된 텍스트) 삭제된 페이지 검색(브라우저 보관) 대량 삭제 페이지(핵심) 개인으로 표시된 남용 필터 보기(abusefilter-view-private) 자세한 남용 로그 항목 보기(유용필터-log-detail) 확장 소프트웨어 버전 정보 표시(버전 세부 정보) 속도 제한에 영향을 받지 않음(노르테리미트) API 쿼리에 더 높은 제한 사용(apihighlimits) 제목 블랙리스트 재정의(tboverride) 자신의 수정본을 자동으로 "수락됨"으로 표시(자동 보기) 수정본을 "수락됨"으로 표시(검토) 다른 사람의 편집 내용을 순찰(패트롤)으로 표시 자신의 편집 내용을 자동으로 순열로 표시(자동 제어) 특정 페이지를 편집한 마지막 사용자의 편집 내용을 신속하게 롤백(롤백) 다른 사용자(사용자 권한)의 사용자 그룹 변경 +/- 필터 관리자 편집 +/-확인된 +/-롤백 +/- 검토자 플러더 - AWB 사용자와 편집 횟수가 매우 많은 사용자 속도 제한에 영향을 받지 않음(노르테리미트) API 쿼리에 더 높은 제한 사용(apihighlimits) 롤백된 편집 내용을 봇 편집으로 표시(마크봇릿) 특정 페이지를 편집한 마지막 사용자의 편집 내용을 신속하게 롤백(롤백) 파일 업로더 - 위키백과에서 공용으로 파일을 전송하는 사용자에게 유용함 파일 이동(파일 이동) 페이지 이동(이동) 기존 파일 덮어쓰기(업로드) 파일 업로드(업로드) URL에서 파일 업로드(uppload_by_url) 로컬로 공유 미디어 저장소의 파일 재정의(업로드 공유) 제목 블랙리스트 재정의(tboverride) 페이지 삭제(삭제) 페이지 삭제 취소(삭제 취소) 가능한 프로세스 사용자 권한을 얻기 위해 사용자는 위키피디아에서 요청을 제출한다.도구 요청(제목 가능). 커뮤니티에는 3(3) 7일이 소요되며, 편집자에게 깃발을 수여하거나 사용자가 깃발을 수여하는 것을 반대한다. 관리자(administrator) 또는 Officialat은 요청을 검토하고 70% 이상의 지원이 있을 경우 깃발을 부여한다. 남용될 경우, Officat는 도구를 제거할 것이다.예:Patroller가 사용자를 부적절하게 차단할 경우 도구 --Alpha Quadrant 19:37, 2010년 10월 27일(UTC)[응답]이 제거될 수 있다.

토론

• '그래'라고 외치고 있어이렇게 하면 완전히 논란의 여지가 없는 청소 일을 할 수 있으려면 RfAs의 공포를 겪지 않아도 될 것이다.헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 10월 27일 (UTC) 19:07, 답변

정확한 세부 사항은 물론 나중에 자세히 정리해야겠지만, 대체적인 생각을 말하는 겁니다."파일 업로더"처럼 파일 삭제/삭제 권한이 없더라도 상당히 유용할 것이다.헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 10월 27일 (UTC) 19:19, 답변

• 헤드폭탄 및 제안자당 강력한 지원.(대화)19:12, 2010년 10월 27일 (UTC)[응답하라]
• 지지하다.하지만, 나는 '구입자' 그룹은 만들어지지 않을 것이라고 생각한다.MGodwin 당, WMF는 커뮤니티의 입력 없이 삭제된 뷰를 제공할 수 없다.→ ROX ₪ 19:14, 2010년 10월 27일 (UTC)[응답]
• (갈등 편집) 나는 핵심권(차단, 삭제, 보호)을 분열시키는 열렬한 팬이 된 적이 없다.차단할 수 있는 신뢰가 있다면 삭제와 보호 등을 신뢰할 수 있어야 한다.현재 RfA에서는 이러한 관리 도구를 사용해야 한다.삭제된 자료를 보는 것은 2008년 마이크 고드윈의 발표에 따르면 절대 안 된다.내가 생각하기에 더 낮은 단계의 그룹에게 주어질 수 있는 몇 가지 덜 해로운 권리들이 있지만, 이것은 여기에서 제안된 것이 아니다. PeterSymonds (대화) 2010년 10월 27일 19:16, (UTC)[응답]
• 나는 그 아이디어는 좋지만 세부적인 것에 문제가 있다.patroler의 block button과 purger의 delete button을 특정한다.나는 이것이 지역사회의 의견 없이 배포되는 것을 지지하지 않는다.블록버튼의 핵심 문제, 단순한 반달리즘 블록에 대한 사용능력과 기존 이용자의 매우 어려운 영역을 더 논란이 많은 이유로 분리할 수 있는 기술적 방법이 없다.--큐브 루머 (토크) 2010년 10월 27일 (UTC)[응답]

  "patroller"가 IP 및 비자동 확인 사용자만 차단할 수 있도록 항상 구성할 수 있다.논란이 되고 있는 블록, 아니 블록 버튼의 완전한 능력은 정상적인 관리자의 관할권에 있을 것이다.(대화)19:23, 2010년 10월 27일 (UTC)[응답하라]

또한 편집자가 깃발을 가지고 신뢰할 수 있다고 생각하는지 여부에 대해 커뮤니티가 3일 동안 결정하는 특별 허가 요청도 있을 수 있다.그것은 또한 "구매자" 권리를 허용하게 될 것이다.당연히 RFA만큼 어렵지 않을 것이다. --Alpha Quadrant 19:27, 2010년 10월 27일 (UTC)[응답]

• 중립(더 많은 정보를 볼 수 있다면, 내가 머무를 곳이다.)자세한 것은 더 보고 싶으니까 일단 기권해.이전의 의견은 다음과 같았다: 현재 언급된 바와 같이 이 제안에 반대하라.단순히 사용자 권리 때문만이 아니라, 관리자들이 커뮤니티 승인 없이 나눠준다는 사실 때문이다.당신은 그들이 관리자 권한을 대체하는 것이 아니라고 말하지만, "블록"과 "삭제"는 아마도 가장 논란이 많은 두 가지 도구일 것이다. 그리고 만약 당신이 한 사람에게 그 두 가지를 모두 준다면, 그들은 사실상 관리자일 것이고, 나는 관리자가 커뮤니티의 입력 없이 새로운 거의 관리자를 여러 명 만들 수 있다는 생각이 불편하다.기껏해야 이러한 사용자 권한을 부여하는 RfA와 같은 프로세스가 있어야 한다.만약 이것이 RfA와 같은 과정을 포함하도록 다시 쓰여진다면 나는 나의 의견을 바꿀 수 있을 것이다."P"로 시작하는 그룹들이 가장 걱정된다는 것을 덧붙여야겠다."Fluder"는 Simple과 몇몇 다른 위키에 이미 존재하기 때문에 좋은 생각일 수 있다. 그리고 나는 우리가 여기에 그것에 대해 그렇게 많이 필요하지 않다고 생각하지만, 그것이 나쁘다는 것을 의미하지는 않는다.—Soap—2010년 10월 27일 (UTC)[응답]

• 처음에는 이것이 콘텐츠 제작이 거의 없는 반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반(反)반)반(反)반(反)반(反)반)반(反)반(反)반(反)반(反)반(反)반(反))반(反)))))반(反)반(反)반)반(反))반)반그런 만큼 나는 '지지'나 '반대' 열에 편하게 몸을 넣을 수 있을 만큼 확고한 의견을 갖고 있지 못하며 중립을 지킬 것이다.—Soap—2010년 10월 28일(UTC) 12시 46분[응답]

• 지원—이는 관료주의를 줄이고 효율성을 높인다.나한테는 좋은 계획인 것 같아.╟-TreasuryTag►Africa, Asia and UN-19:34, 2010년 10월 27일 (UTC)[응답]
• 적어도 이런 식으로는 안 된다.관리자가 아닌 사용자에게 차단 버튼을 부여하시겠습니까?아, 이런...이미 방아쇠를 당기는 관리자들이 있다.츄우우우히:2010년 10월 27일(UTC) Seb Az86556 19:35 [응답]

관리인을 선출하는 것과 정확히 뭐가 다를까?츄우우우히:2010년 10월 27일(UTC) Seb Az86556^{> haneʼ} 19:39 [응답]

왜냐하면 전체 관리자 비트가 아니라 특정 도구일 뿐이기 때문이다.(대화) 19:42, 2010년 10월 27일 (UTC)[응답하라]

모든 편집자가 모든 도구를 원하는 것은 아니다.그러나 일부 사용자들은 특정 권리가 자신의 업무에 유용하다고 생각할 것이다.패트롤러들은 공공 기물 파손과 싸울 때 그 블록 툴이 유용하다는 것을 알게 될 것이다.RFA 프로세스를 실행하면 유용하다고 생각되고 나머지 툴은 그다지 유용하지 않게 되므로, 필요한 툴을 요청하기만 하면 된다.만약 그들이 모든 도구를 필요로 한다면 그들은 RFA를 실행할 수 있었다. --Alpha Quadrant^talk 19:46, 2010년 10월 27일 (UTC)[응답]

리스트를 봐.'삭제할 수 없는 관리자'라든가 이런 건데, 어쨌든 내 말은..."오직"..."음향"은...?누군가 블록 해머를 받는다는 말을 들으면 깃발이 뭐라고 부르든 상관없어.같은 조사, 같은 토론, 같은 이유.츄우우우히:2010년 10월 27일(UTC) Seb Az86556 19:45[응답]

• 왜 7일은 안 돼?아니면 14살?만약 있다면, 나는 이 RfT들이 RfA의 전체 투표보다 잠재 유권자들에게 덜 매력적일 것이라고 예상했고, 투표는 더 느리게 들어올 것이다.괴롭히려고 하는 것이 아니라, 단지 이 제안의 이면에 있는 생각을 이해하려고 하는 것이다.—Soap—2010년 10월 27일 (UTC)[응답]

좋은 점 비누, 내가 제안하는 일수를 늘리겠다.숫자는 그냥 제안일 뿐이었다. --Alpha Quadrant 19:47, 2010년 10월 27일 (UTC)[응답]

• 반대한다. 나는 피터시몬드의 의견에 동의한다.하나의 행정 도구로 신뢰받을 수 있는 사람은 그 모든 것(사용할 의향이 없는 것 포함)으로 신뢰받을 수 있다.후보자가 일부 관리 도구만 자주 사용할 것이라는 이유로 관리 요청이 거부되고 있다면 RfA 프로세스에서 이러한 결함을 해결해야 한다.—데이비드 레비 21:49, 2010년 10월 27일 (UTC)[응답]

그건 사실이 아니야.만약 그렇다면, 사람들은 파괴적인 전투 도구를 원할 때 RfA에 거절당하지 않을 것이다. 그러나 삭제나 콘텐츠 작업 등에 경험이 없다는 이유로 반대한다.모듈식 권한만이 RfA를 고칠 수 있는 유일한 방법이다. 왜냐하면 사람들은 RfA 후보자들을 그들이 요청한 도구들을 거부하고 있기 때문이다. 왜냐하면 그들은 어차피 사용하지 않을 도구들을 신뢰하지 않을 것이기 때문이다.헤드폭탄 {talk / 기여 / 물리학 / 책} 22:05, 2010년 10월 27일 (UTC)[응답]

후보자가 일부 관리 도구만 사용하려고 하기 때문에 관리 요청이 거부되는 가상 시나리오를 언급했다.어떤 도구를 가지고 누군가를 불신하는 것은 전혀 다른 문제다.

행정의 다양한 측면들이 심하게 얽혀 있고 고립되기 어렵기 때문에, 위키백과 전체를 합리적으로 이해하는 것이 문제의 개별 도구를 대부분 소유하고 있는 사람에게 필수적이라고 생각한다.만약 예비 관리자가 한 분야에 주로 또는 전적으로 집중하기를 원한다면, 그것은 괜찮고, 나는 그것이 그의 관리 요청을 반대할 타당한 이유라고 생각하지 않는다.그러나 핵심 프로세스에 대해 아는 사람이 너무 적어서 커뮤니티가 실제로 관련 도구로 그를 불신한다면, 그것은 그가 사이트 전체를 더 잘 이해해야 한다는 것을 보여주는 것이다.—데이비드 레비 22:47, 2010년 10월 27일 (UTC)[응답]

그리고 나는 실제 사례에 대해 말하고 있다.문제는 지원자들이 위키피디아에 대해 매우 생소하다는 것이 아니라, 지원자들이 선호도를 가지고 있고, 단지 이러한 도구들 중 일부에 대해서는 신경 쓰지 않는다는 것이다.반달 파이터들은 삭제 토론에 경험이 없기 때문에 도구를 거부당한다.템플릿 편집자는 콘텐츠 작업이 없기 때문에 거부된다.AfD/MfD/etc... 유형의 행정가들은 반달 투쟁이 부족하기 때문에 반대한다.RfA가 제정신이거나 툴이 번들거리지 않았다면, 이것은 문제가 되지 않을 것이다.만약 지미 롱팬츠가 전문 템플릿 작성자라면, 편집 전쟁 등의 역사가 없다면...CSD 기준이나 반달 싸움에 대한 경험이 많지 않다면 무엇이 문제인가?아마도 당신은 그것에 대해 그를 반대하지는 않을 것이다. 하지만 많은 사람들이 반대할 것이다. 그리고 그것은 위키피디아가 선거권을 박탈당하기 보다는 더 단서가 있는 편집자들에게 권한을 부여하는 것을 보는 차이를 만든다.헤드폭탄 {talk / 기여 / 물리학 / 책} 23:23, 2010년 10월 27일 (UTC)[응답]

그렇다면 해결책은 RfA를 "sane"으로 만드는 것이지, "별일 없다"고 의도한 것을 지나치게 불평하는 것이 아니다.

아래에서, 미스터 Z-man은 제안된 설정에서 몇 가지 중요한 결함을 지적한다.—데이비드 레비 01:55, 2010년 10월 28일 (UTC)[응답]

나는 걱정을 끼친 권리를 수정하고 폐지했다.실격하지 않은 선수는 설정되기 전에 WMF 승인을 받아야 한다.이 제안은 그러한 권리 창출의 지원 여부에 관한 것이다.어떤 권리도 가볍게 주어지지 않을 것이다.관료들이 사용자 자격 중 하나만 빼앗을 수 있어야 하는 이유는 관리자들이 논쟁에서 그들의 지위를 남용하지 않기 때문이다.만약 그 도구들이 지역사회의 합의에 의해 제공되었다면 그들은 비상사태를 제외하고 지역사회의 합의 없이 취소되어서는 안 된다."관리자 재량권 제거"는 작동하지 않을 것이다.관리자가 전쟁을 조종하는 대신, 편집자가 해야 할 일은 편집자의 권리를 없애는 것이 될 것이다. 왜냐하면 그들은 전체 관리자였고 다른 편집자는 그렇지 않았기 때문이다. 따라서, 전체 관리자의 의견은 정확하다.이것은 결국 일어날 가능성이 훨씬 더 높기 때문에, 이 이슈에 관한 것이다.관료들은 예의 바르게 행동하고, 남용과 정책 위반을 측정하는 일을 꽤 잘 한다고 믿어지는 반면, 행정가들은 냉정을 잃고 그러한 종류의 위협을 할 가능성이 더 높다.예를 들어 AN/I에서 블록 간식에 대한 보고가 꽤 있다. --Alpha Quadrant^talk 03:04, 2010년 10월 28일 (UTC)[응답]

아직 해결되지 않은 일부 우려 사항은 10월 28일 01:23(UTC)에서 Z-man씨의 메시지를 확인하십시오.—데이비드 레비 03:49, 2010년 10월 28일 (UTC)[응답]

마을 펌프에 대한 여론조사는 이와 같은 복잡한 제안을 위한 최선의 형식은 아니다. 그리고 그것은 거의 확실히 어떤 시행 전에 더 큰 논의가 필요할 것이다. 그러나 내 의견은 다음과 같다.

• 취약한 지원 패트롤러 - 여기에는 ipblockexempt, proxyunbannable(Media를 사용하지 않기 때문에 Wikimedia 사이트에서는 아무 것도 할 수 없음)이라는 불필요한 권리도 있다.Wiki의 프록시 차단기), stablesettings(차단보다 보호에 가깝다), 버전 세부사항(뭐?), +/-롤백 및 +/-IP 블록 면제(이것은 항바이러스제가 아닌 관리 작업이다).
• 보호자 반대 - 이를 정당화할 수 있는 보호와 관련된 관리 작업이 많지 않다.편집인터페이스, 편집유저j, 편집유저스는 남용될 경우 잠재적인 손상으로 인해 가능한 한 제한되어야 한다.이상적으로는 모든 관리자라도 그것을 가져서는 안 된다.
• Purger 반대 - 삭제/삭제되지 않은 텍스트를 제거하지 않으면 발생하지 않으며, 이로 인해 사용자가 자신의 작업을 취소할 수 없는 상황이 발생할 수 있음
• Fait Fluder - 이것은 본질적으로 봇이며, 대부분의 사용자들이 이미 가지고 있거나 필요하지 않기 때문에 실제로 중요하지 않은 몇 가지 권리들이 없다. 이것은 기본적으로 봇 승인 과정을 우회하는 방법을 만든다.

• 나는 목록을 다시 읽었고 그 제안이 봇이 아닌 마크브래킷을 주는 것을 보았다.이 경우, 그것은 무의미하다.기존 사용자에게 영향을 미치는 유일한 속도 제한은 분당 8페이지 이동, 하루에 200개의 이메일, 계정 생성 스로틀 및 분당 100개의 롤백이며, 정상적인 편집은 전혀 제한되지 않는다.이것은 사람들이 AWB와 마주칠 일이 아니다.

• 취약한 지원 파일 업로더 - 삭제/삭제 해제 시 "파일 이동자"로 지원하겠다.upply_by_properties는 여기서 비활성화된다.

또한 관리자가 권한을 추가할 수 있다면 이를 제거할 수 있어야 한다.이것은 이것들을 덜 중요한 것으로 만드는 데 도움이 될 것이다.2010년 10월 27일 Mr.Z-man 22:30 (UTC)[응답]

이것과 이것에 따라 적어도 2005년부터 진행되어 온 것에 대해 뭔가 조치가 필요하다.무슨 일이 일어날 필요가 있다.핵심 관리자 구성요소를 분할하는 것은 매우 유용할 것이다.Sysops 그룹에는 삭제/삭제 해제, 보호/페이지 이동, 차단/차단 해제, 그리고 (오랜 토론 끝에 마침내 비관리자에게 넘겨진) 롤백의 네 가지 구성 요소가 있다.모든 사용자가 모든 관리 작업을 수행하기를 원하는 것은 아니다.이 모듈은 커뮤니티의 지원이 없으면 사용자에게 제공되지 않을 것이다.그것은 실제로 편집자들이 작업을 더 쉽게 할 수 있게 해줄 것이다.행정관이 하는 일은 기본적으로 세 가지 측면이 있다.모든 편집자들은 그 범주들 중 하나에 속한다.그들은 주로 공공 기물 파괴 행위와 싸우고, 기사 내용을 개선하는데 많은 시간을 소비한다(보호자는 기사 작업에 도움을 줄 것이다), 그리고 CSD 기사 및 기사 삭제에 대한 기사를 지명하는 새로운 페이지 패트롤러/기사 태거, 사용자들(구매자는 기사 문제를 삭제하는 것을 도울 것이다).다른 부적절한 내용뿐만 아니라 ack 페이지.그들이 실수를 했을 때 그들의 행동을 되돌릴 수 있도록 하는 데 있어 무절제한이 유용할 것이다).이래서 유저가 추가되면 도움이 될 것 같아. --Alpha Quadrant^talk 23:55, 2010년 10월 27일 (UTC)[응답]

더 간단한 해결책은 행정력을 잃기 쉽게 만드는 것이다.분할 시 발생할 수 있는 한 가지 잠재적 위험은 전체 관리자 권한을 얻는 것이 더 어려워질 수 있다는 것이다.나는 "야당-후보가 차단할 필요성을 보여주지 않고 보호자와 푸르거만 얻어야 한다"와 같은 RFA 표를 상상할 수 있다.그리고 물론 골든 해머 문제도 있다; 많은 경우 행정 문제를 다루는 여러 가지 방법이 있다.완전한 관리자 권한이 없는 사람은 그들이 할 수 있는 모든 것이기 때문에 차선의 해결책을 사용할 수 있다.미스터 지맨 01:23, 2010년 10월 28일 (UTC)[응답]

행정력을 잃기 쉽게 만드는 것이 통과를 쉽게 할 수 있다고는 생각하지 않지만, 그것은 WP와 같은 또 다른 페이지를 위한 토론이다.CDA 제안.(사실, 내 생각은 나와 다른 사람들에 의해 이미 그곳에서 표현되었다.) —소프— 13:20, 2010년 10월 28일 (UTC)[응답]

• 나는 헤드밤이 말한 방식이 마음에 든다.전체 지원- 미스터 R00t 22:50^Talk, 2010년 10월 27일 (UTC)[응답]

• 지원 패트롤러 - 나는 그것에 대한 확실한 용도를 알 수 있지만, 솔직히, 나는 다른 것들에 대해 확신이 없다.나도 잘 모르겠어; 이 사람들이 정말로 사용자 권리를 부여할 필요가 있을까?1700명의 관리자들이 있다; 확실히 그들은 그것에 대해 책임질 수 있다.Ajraddatz (토크) 22:51, 2010년 10월 27일 (UTC)[응답]

• 강력한 지원: (유지보수에 관한) 나의 주요 업무 분야는 CSD, 특히 F8이다.나는 CSD를 위해 수백 개의 파일과 페이지를 "태그"했지만, 다른 관리자가 삭제 버튼을 다시 수백 번 클릭할 때까지 기다리기만 했다.나는 모든 관리 분야에서 단순히 "준비되지 않았다"는 것에 비해 RFA에 두 번 실패했다. 3위를 하는 것에 대한 나의 흥미를 거의 잃었다.나는 특정 관리 작업을 수행하겠다고 제안하는 편집자들에게 특별한 삭제 권한이 매우 유용하다고 생각한다.레흐만⁽⁺⁾ 00:20, 2010년 10월 28일 (UTC)[응답]
• 모듈형 권리에 대한 매우 강력한 지원; 모듈과 프로세스는 지역사회가 다져놓지 않은 것과 같은 요철을 갖춰야 할 것이다._{Is is just me, or are the admins opposing, while non admins are supporting?} 930913 (축하/불만) 01:23, 2010년 10월 28일 (UTC)[응답]

• 반대, 나는 PeterSymonds의 의견에 동의한다. 나는 권력을 나눌 이유가 없다고 본다. 만약 어떤 사람이 페이지를 삭제할 수 있다고 신뢰 받는다면 왜 그들 역시 페이지를 보호할 수 없는가? - 도! 01:59, 2010년 10월 28일 (UTC)[응답]

콘텐츠 제작자와 신규 페이지 패트롤러/발행태거 간에는 차이가 있다.컨텐츠 작성자는 새로운 페이지 등록자보다 보호 도구가 더 필요할 가능성이 높다.컨텐츠 작성자는 종종 템플리트(종종 완전하게 보호되는)에서 작업한다.페이지 이동과 동일한 모듈에 보호가 있는 것은 논리적이다.보호된 페이지를 제대로 이동하려면 페이지 보호도 이동해야 한다.새로운 페이지 등록자들은 페이지를 보호할 필요가 덜할 것이다.그러한 경우, 보호 요청 시 요청을 할 수 있다.가끔 들판이 교차하는 문제가 있을 수 있고, 그들은 권리를 가진 누군가에게 도움을 요청해야 한다.만약 그런 일이 자주 일어난다면 그들은 관리직이나 특정 모듈에 지원할 수 있다. --Alpha Quadrant^talk 02:16, 2010년 10월 28일 (UTC)[응답]

위에서 논의한 바와 같이, 도구가 필요한 것과 도구를 신뢰받는 것 사이에는 차이점도 있다.삭제 도구를 남용하지 않는다고 믿을 수 있는 사람은 보호 도구를 남용하지 않는 것으로 믿을 수 있다(사용 의도와 무관하게).—데이비드 레비 02:26, 2010년 10월 28일 (UTC)[응답]

그래, 차이가 있다.그러나 일부 사용자는 특정 분야의 기여도가 부족하기 때문에 하나의 모듈을 신뢰받지만 다른 사용자는 신뢰받지 못한다.그들은 특정 분야의 기여가 부족하여 RFA에서 반대하게 될 것이다.앞에서 말했듯이, 만약 일부 편집자들이 전체 sysops를 필요로 하지 않는다면, 왜 그들은 한 분야에서 기여가 부족하기 때문에 낙담해야 하는가.그것은 편집자들이 RFA를 통해 그들이 사용할 몇 가지 도구뿐만 아니라 사용하지 않을 몇 가지 도구를 얻기 위해 싸우는 것보다, 그들이 신뢰할 수 있는 도구를 얻는 것을 더 쉽게 만들 것이다.sysops 그룹에는 아무 일도 일어나지 않을 것이다.관리자 모듈을 만들면 어떤 문제가 있을까? --Alpha Quadrant^talk 02:49, 2010년 10월 28일(UTC)[응답]

위에서 말한 바와 같이, 행정의 다양한 측면들이 심하게 얽혀 있고 고립되기 어려우므로, 위키백과 전체를 합리적으로 이해하는 것이 문제의 개별 도구를 대부분 소유하고 있는 사람에게 필수적이라고 생각한다.이런 도구들 중 하나로 믿을 수 없는 사람이 있다면, 나는 그 누구에게도 신뢰를 받아야 한다고 생각하지 않는다. (어떤 도구를 사용하지 않으려는 사람은 괜찮지만, 우리는 그/그 사람을 그 능력으로 믿을 수 있어야 한다.) —데이비드 레비 03:49, 2010년 10월 28일 (UTC)[응답]

• (충돌 편집)패트롤러에 대한 지원, 그러나 단일 사용자보다는 커뮤니티에 의해 제공된다.이 그룹에 사용자 권한을 부여하지 맙시다. 왜냐하면 그들이 존재하는 모든 그룹을 허가하고 취소할 수 있기 때문이다. 그룹 추가/제거 작업은 별개지만, 봇 편집에 대한 지원 - 어차피 봇 편집으로 표시할 수 있는 롤백과 같은 것(IERC)만 의미가 없기 때문에 무슨 뜻인지 안다.관리자 한 명이 이 항목을 결정해도 괜찮다.보호자에 대한 지원, 다시 지역사회 동의와 함께 하지만 나는 감시되지 않은 페이지들이 tbh에 포함된 것을 좋아하지 않는다 - 그 안에 있는 정보는 악의적인 누군가가 그것을 잡으면 상당히 위험하다.푸르거에 대한 약한 반대, IMHO 당신은 삭제된 텍스트를 포함시킬 수 없다. 이것은 기본적으로 이 그룹의 유용성을 상당히 떨어뜨린다.그 용도를 위해서, 당신은 무삭제, 삭제 수정, 찾아보기, 핵, 삭제 히스토리 또한 두드리는 것이 좋을 것이다.이 그룹의 주요 기능으로 삭제되고 사용자가 실수를 되돌릴 수 없게 된다.그러니 삭제도 해줘.그게 뭐가 남았어?약한 파일 업로더 지원, 그러나 삭제는 그 안에 있다(위 참조).그래, 파일을 다시 업로드할 수 있는 등등이 있지만, 그 안에 있는 대부분의 것은 아마도 (IERC) 주로 오토콘 확증 그룹에 있기 때문에(언제나 그렇듯이 자유롭게 나를 수정할 수 있다) 이 점에서도 별로 의미가 없다고 본다.나는 권리를 분리한다는 생각은 좋지만, 크게는 아니다. 내 의견으로는 이것이 번들번들한 끝에 다다르고 있다. 그리고 관리자들이 이것을 좋아하지 않는다고 말한 사람은, 여기 원칙적인[stwalker talk] 02:17, 2010년 10월 28일 (UTC)[응답]을 좋아하는 관리자가 있다.

  그리고 위 코멘트를 시작할 때 과감하게/이탈리즘을 고치는 사람에게 쿠키 - 뭐가 잘못됐는지 알 수가 없어. :([stwalkerster talk] 02:17, 2010년 10월 28일 (UTC) 고정 :) [stwalker talk] 02:19, 2010년 10월 28일 (UTC)[응답]

• 레밍스!–MuZemike 02:44, 2010년 10월 28일 (UTC)[응답]
• 이 모든 권리에 반대하라 이 권리는 분열될 필요가 없다.사용자는 sysop이 됨으로써 패키지 거래를 얻는다.Acps110 03:55, 2010년 10월 28일 (UTC)[응답]
• TL;DR-ness에 대해 강력하게 반대하며, 여러 가지 이유로 사과한다.첫째, 이것은 해결하고자 하는 문제를 해결하지 못할 것이며, 비관리자가 자신이 관여하는 관리 관련 분야에서 더 쉽게 작업을 완료할 수 있을 것이다.그렇다, 새로운 페이지/CSD 순찰에서 많은 일을 하는 사람은 이 "구입자" 권리의 혜택을 받을 수 있다.그래, 반달 순찰하는 사람은 패트롤러 권리의 혜택을 받아서 사용자들을 차단할 수 있어.등등.하지만 내 경험상, 비록 당신이 하고 있는 일이 그 분야들 중 하나에 정면으로 떨어지더라도, 당신은 종종 다른 관리 도구도 필요할 것이다.예를 들어 다음과 같다.나는 새로운 페이지 순찰 중인데 사용자가 공격 페이지를 만드는 것을 알아차렸다.퍼거가 있으니 문제 없어, 페이지 삭제.5분 후에 다시 와서 다시 지운다.등등.패트롤러가 없어서 반달도 막을 수 없고, 프로텍터도 없으니 제목을 소금으로 칠 수 없다.내가 어떻게 해야 하나요?나는 AIV와 RFPP에 글을 올리고, 내가 애초에 Purger를 요청하기 전의 상황을 다시 찾는다.또는 시나리오 2:나는 이 페이지를 알아차렸지만 아무런 권리도 없다.CSD를 위해 페이지에 태그를 달았는데, 태그를 취급하는 관리자는 페이지를 삭제할 뿐만 아니라 사용자를 차단하고 향후 솔팅이 필요할 경우를 대비해 감시 목록에 페이지를 추가한다.훨씬 더 효율적이지 않나?아주 자주 나는 한 가지 일을 하기 시작할 것이고, 당신이 언뜻 보기에 전혀 관련이 없을 것이라고 생각하는 일을 하고 있는 나 자신을 발견할 것이다.누군가가 RFA를 거치는 것이 훨씬 더 나을 것이다. 그래야 그들이 이 모든 도구들에 접근할 수 있기 때문에 필요할 때 그것들을 사용할 수 있기 때문이다.
  두 번째 이유: 첫 번째 시나리오를 생각해 봅시다. 그리고 우리의 가상적인 푸거는 이것이 그들이 패트롤러에게 권리를 요구하는 좋은 이유라고 결정한다고 하자.그들은 그렇게 하고, 공동체의 검토 결과, 그에게 권리를 주지 않을 이유가 없다고 본다.인생은 계속된다.우리의 푸르거/패트롤러는 그들이 여러 번 그 시나리오에 참여한다는 것을 알게 되었고, 보호자 또한 정말 좋아할 것이다.그래서 그들은 그것을 요청하고, 그것을 얻는다.이제 블록, 삭제, 보호 버튼에 액세스할 수 있게 되어 이름만 빼고 모든 것을 관리하게 되었다.여전히 관리자와 동일한 표준(여러 ArbCom 사례에 의해 확립된 표준)을 준수하고 있는가?아마도, 그들이 걸레를 휘두르는 것이 아니라, 많은 수의 스위퍼스 깃털 걸레들을 휘두르는 것이기 때문에 그럴 것이다.그들은 이러한 도구를 얻는데 있어서 동일한 수준의 정밀 조사를 받고 있는가?안 그럴 거야, 한 번에 한 명씩 데리.이것은 누군가가 RFA를 실제로 청산하지 않고 RFA를 클리어할 수 있는 훌륭한 방법처럼 보인다; 그것은 훨씬 더 오래 걸릴 것이다; 하지만 RFA를 통과할 수 없을지도 모르는 누군가는 이 과정을 통해 자신이 행정관이 되는 데 필요한 모든 장애물을 뛰어넘을 수 있을 것이다.
  마지막으로, 앞에서 지적한 바와 같이, 이것과 관련된 여러 가지 사소한 문제들이 있다.삭제된 수정사항과 관련된 법적 문제.감시되지 않은 페이지 액세스, 개인 남용 필터 등과 관련된 보안 문제.버튼 하나로 사용자가 신뢰할 수 있는 정합성 보장 문제, 즉 IT 버튼이 아닌 큰 혼란과 드라마를 야기할 수 있는 문제.등등.그런 점들은 대부분 이미 다 만들어졌고 이미 너무 오랫동안 장황하게 늘어놓았기 때문에 자세히 설명하지는 않겠지만, 나는 이것을 좋은 아이디어로 보지 않고, 사실 심각한 문제를 일으킬 수 있는 큰 잠재력을 가진 것으로 본다.허스폴드^(t/a/c) 04:15, 2010년 10월 28일 (UTC)[응답]

  나는 Swiffers가 mops보다 낫다고 들었다.좋아. 그럼 이 추가 권리들을 "걸레질하는 사람들"이라고 부를게. :-P 허즈폴드 04:20, 2010년 10월 28일 (UTC)[응답]

• 그래서 그 논리는 어떤 때는 망치가 필요하고, 어떤 때는 스크루드라이버가 필요하기 때문에, 어떤 것은 가지고 있는 것보다 공구가 전혀 없는 편이 더 낫다는 겁니다.아니면 다르게 표현하면, 망치와 스크류드라이버를 가진 2명, 망치와 스크류드라이버를 가진 2명, 그리고 스크류드라이버를 가진 5명, 그리고 망치를 가진 5명이 더 낫다.우리는 단서를 가진 사람들이 그들이 잘하고 돕고 싶은 것에 더 효율적이게 할 수 있는 도구를 이용할 수 있게 함으로써 어떤 것도 잃지 않는다.헤드폭탄 {talk / 기여 / 물리학 / 책} 06:04, 2010년 10월 28일 (UTC)[응답]

• 물론 망치를 든 사람들 중 한 명이 망치를 이용해 나사로 운전하려다가 결국 아무 짓도 안 한 것 보다 더 나쁜 일을 부숴버리는 경우가 아니라면 말이다.모든 것이 망치일 때는 모든 것이 못처럼 보인다.미스터 지맨 2010년 10월 28일 (UTC) 14:25 (응답)

• 미안하지만, "내가 편집한 내용을 [패트롤러가 아니라] 순찰하는 것으로 표시할 수 없기 때문에, 내가 대신 파일을 옮길게!"라는 이 말은 정말 터무니없고 쓸모가 없어 보인다.위키피디아의 종말이 어떻게 될 것인가에 대한 큰 소동을 기억하라. 사용자들이 터무니없는 비율로 전쟁을 되돌릴 수 있게 하는 등...그리고 어떻게 우리가 아직 여기 있고 롤백이 번들거리지 않아서 기쁘지?헤드폭탄 {talk / 기여 / 물리학 / 책} 2010년 10월 28일(UTC) 16:51, 응답하라]

• 그런 것이 아니라(파일 무버는 사실 내가 가장 많이 지지하는 것으로, 다른 도구와 가장 덜 얽혀 있기 때문에), "이 편집 전쟁은 페이지를 보호함으로써 더 잘 해결될 수 있지만, 나는 차단만 할 수 있기 때문에 사용자들을 차단할 수 있다." 또는 "이 페이지는 한 IP 범위에서 많은 공공 기물을 파괴하고 있지만 나는 보호만 할 수 있다."와 같은 경우.스스로 차선책으로 대처하기보다는 적절하게 대처할 수 있는 사람에게 보고하는 것이 낫다.2010년 10월 28일(UTC) 10시 33분 미스터 Z맨[응답]

• 그렇다면 차단 도구를 포함하지 않는 버전에서는 왜 지원하지 않는가?헤드폭탄 {talk / 기여 / 물리학 / 책} 21:01, 2010년 10월 28일 (UTC)[응답]

• 우리는 롤백기라고 불리는 것을 가지고 있는데 롤백과 블록을 제외한 대부분의 권리들은 단지 불필요한 것이다.2010년 10월 28일(UTC) Mr.Z-man 21:07[응답]

• 롤백자는 리디렉션을 남기지 않고 페이지를 이동할 수 없음, 파일 이동, 보호된 템플릿 편집 등...아니, 그게 뭔지는 몰라도 '그것"은 없어헤드폭탄 {토크 / 기여 / 물리학 / 책} 03:39, 2010년 10월 29일 (UTC)[응답]

• 그러나 그것들 중 오직 하나만이 차단을 포함하는 제안된 그룹의 일부분이다.이슈(또는 이슈 중 하나)는 나 자신과 같은 데이비드 레비, 허스폴드, 비블브록스가 (데이비드의 말을 인용하면) "관리권의 다양한 측면들이 심하게 얽혀 있고 고립되기 어렵다"고 했을 때 이들 그룹 각각은 (Fluder를 제외한) 하나의 주요 관리자 권한만을 포함하고 있다는 점이다.만약 사람들이 이와 같은 것을 유지 보수 작업을 하기 위해 원한다면, 이것은 아마도 여전히 너무 복잡할 것이다; 여기의 제안들은 기본적으로 3분의 1로 쪼개진 관리 패키지에 불과하다.만약 이들 중 어떤 것도 "큰" 권리(블록/보호/삭제)와 noratetlimit, 감시되지 않은 페이지, tboverride와 같은 관련 없는 것을 포함하지 않고 단지 특정 유지 보수 작업을 수행하는 데 필요한 특정 권한을 포함하지 않는다면, 아마도 훨씬 더 많은 지원이 있을 것이다.1, 2개의 권한만을 가진 사용자 그룹을 가질 수 없는 이유는 없다.관리자는 미디어위키가 그렇게 설계되었고, 그것에 대한 정책이 없기 때문에 많은 일들을 처리하고 있을 뿐이다.미스터 지맨 04:47, 2010년 10월 29일 (UTC)[응답]

• 반대, 공구의 번들을 풀려는 시도로 멈춰라.그것이 해낸 모든 것은 전혀 새로운 종류의 상을 만들어 리워드 문화를 강화하고, 준비되지 않은 미성숙한 편집자들에게 도구를 나눠주는 것이다.샌디조지아 (토크) 04:37, 2010년 10월 28일 (UTC)[응답]

반대로 그것은 마침내 그 문화를 약화시킬 것이다.왜냐하면 지금 당장, 우리가 모든 도구에 한 번에 접근할 수 있게 해주기 때문에, 사람들은 2006년에 한 번 방귀를 뀌었던 사람이 "공포 또는 남용"을 이유로 도구에 손을 대도록 하는 것에 대해 편집증적으로 생각하고 있기 때문이다.기준은 올라가고, 관리자는 내려간다.더 작은 묶음으로 도구를 만들면, 더 많은 사람들이 앞으로 나아가서 다양한 분야에서 위키백과(Vandals, 템플릿, 파일, 페이지 순찰, ...)를 향상시키고 도구에 접근하는 "일관적인 위신"을 제거하도록 장려할 것이다.나는 아직 롤백업자나 계정 크리에이터를 두고 빈둥거리는 사람을 본 적이 없다. 그리고 나는 패트롤러나 업로더, 혹은 어떤 것이든 어느 정도의 예배를 받을 수 있을지 매우 의심스럽다.헤드폭탄 {talk / 기여 / 물리학 / 책} 06:14, 2010년 10월 28일 (UTC)[응답]

• 반대하라; 샌디는 거의 머리를 때린다.점점 더 많은 사람들이 위키피디아를 다른 수준과 상태 위치를 가진 거대한 게임처럼 하는 문화가 발달하고 있다.이것은 정답이 아니다. (정답이 무엇인지 잘 모르겠지만, 잘 들어; 이것은 단지 정답이 아니야.)Antandrus (대화) 04:47, 2010년 10월 28일 (UTC)[응답하라]
• 결함으로 반대하다.Patroller (blockemails), Protector (move-rootuser pages), Purger (nke)는 sysops와 crats를 위해 예약되어야 하는 권한을 부여받을 것이다.그렇지 않으면 나는 3개월에서 6개월의 재판을 승인할 것이다.– 알렌 for IPv6 06:18, 2010년 10월 28일 (UTC)[응답]

완전히 잔소리하지 말고, 내 질문(^위)을 반복하도록 하자.왜 지지자들은 이것이 현재의 과정과 같은 "허들-드라마"로 바뀌지 않을 것이라고 생각하는가? ("다시 말해")물론:) 왜 사람들은 갑자기 의심하고, 회의적이고, 지나치게 비판적인 것을 그만두는가? 후보자에게 장대높이뛰기를 시키는가?정확히 무엇이 바뀔까?만약 당신이 이것이 정말로 사람들에게 이런 도구를 제공하는 과정을 더 쉽게 만들 것이라고 나를 설득할 수 있다면, 나는 전체 아이디어에 대해 준비될 수 있을 것이다.고마워요.츄우우우히:2010년 10월 28일(UTC) Seb Az86556 06:30[응답]

나는 사람들이 장애물을 낮출 것이라고 생각한다고 생각한다. 아마도 적은 권리 = 적은 잠재적 위해에 기초했을 것이다.개인적으로 찬성한다는 것은 아니다. --사이버코브라 (대화) 08:56, 2010년 10월 28일 (UTC)[응답]

• 완전히 반대 이것은 단지 후원과 편파성의 기회를 증가시킬 뿐이고 봉건주의로 민주주의를 바꿀 것이다.앤서니 (토크) 08:34, 2010년 10월 28일 (UTC)[응답]

• 삭제된 콘텐츠를 볼 수 있도록 지원하지만 다른 툴에 반대한다. 이러한 툴 중 일부는 관리자가 아닌 사용자에게 너무 강력하지만, 정상적인 사용자가 삭제된 콘텐츠를 볼 수 없는 이유는 무엇인가?왜 우리는 삭제된 것들로부터 사람들을 검열하고 있는가? (이것은 위키피디아 입니다. 공격/파괴적이기 때문에 볼 수 없다고 말하는 위키피디아 입니다) 이것은 유모 문화입니다, 만약 내가 또한 할 수 있어야 할 다른 사용자들을 모욕하고 있는 삭제된 내용을 읽으면서 웃기를 원한다면, 우리는 여기 있는 우리 모두 검열당해서는 안 되는 어른들입니다--Lerdthenerd (talk) 13:13, 2010년 10월 28일 (UTC)[응답하라]

  주로 안보를 위해서라고 생각한다.관리자도 볼 수 없는 억제(또는 "overight")라는 삭제 유형이 있다는 점에 유의하십시오.—Soap—2010년 10월 28일 (UTC)[응답]

  기사만 놓고 보면, 삭제된 기사에 대한 내용을 알려달라고 사용자들에게 요청했고, 접근 권한이 없기 때문에 거절해야 했다. 확인된 사용자들은 삭제된 작품의 사본을 가질 수 있도록 이 권한을 가져야 한다.--Lerdthenerd (대화) 13:23, 2010년 10월 28일 (UTC)[응답]

  이상적인 세계에서는, 그러한 요청을 신속하게 처리할 수 있는 충분한 행정관이 있을 것이다.그런 건 없지만, 그런 식으로 자동으로 할당된 사용자 권리로 바꾸는 건 좋은 해결책이 아니라고 생각해.Simple English와 같은 일부 위키에서 RfA 과정은 우리보다 훨씬 관대하며, 그들은 RfA 기준을 완화하는 것에 반대하는 사람들이 예측한 끊임없는 재난 없이 살아남을 수 있다.우리가 노력해야 할 것은 그들이 우리가 잘못하고 있다는 것을 그들이 옳게 하고 있는 것을 알아내는 것이라고 나는 생각한다.—Soap—13:41, 2010년 10월 28일 (UTC)[응답]

  사실, 나는 관점이 삭제된 것이 누군가에게 주는 가장 위험한 관리자 권한 중 하나라고 생각한다.예를 들어, 차단 또는 삭제 기능을 사용하면 적어도 누군가가 이를 악용하고 있는 것이 분명하며, 사용자 그룹을 신속하게 되돌리고 차단/제거할 수 있다.뷰가 삭제된 상태에서는 조회된 내용에 대한 로그도, 효과를 되돌릴 수 있는 방법도 없다. (편집/작성된 삭제된 기사를 볼 수 있다는 것은 다른 문제다.)그리고 WP:환불 정말 그렇게 밀렸나?) --ais523 15:55, 2010년 10월 28일 (UTC)

  나는 법적인 이유로 재단이 RFA보다 훨씬 덜 엄격한 과정을 통해 사람들에게 삭제된 권리를 주지 않을 것이라는 것을 기억하는 것 같다.삭제된 콘텐츠는 삭제하도록 되어 있지만, 널리 볼 수 있는 콘텐츠는 아니다.Rd232 15:57, 2010년 10월 28일 (UTC)[응답]

뷰 삭제의 위험한 점은?위키피디아가 잘못된 손에 들어갔을 경우 위키피디아를 엉망으로 만들 수 있는 다른 권리로, 당신이 하고 있는 일은 아무것도 바꾸지 않고 읽는 것뿐입니다.--Lerdthenerd (대화) 11:01, 2010년 10월 29일 (UTC)[응답]

강력한 평가판 지원 관리 패키지에서 롤백 및 자동 로드 해제 시와 어떻게 다르지 않은지 여부Feinoha 15:36^{Talk, My master}, 2010년 10월 28일 (UTC)[응답]

롤백과 오토캐트롤은 다른 사용자에게 영향을 주지 않으며 파워를 행사할 수 없으며, 롤백이 없으면 더 느리지만 같은 효과가 있는 실행 취소를 사용할 수 있다.여기 있는 크랙스는 적어도 나에겐 차단과 삭제다.이것들은 잘못 사용하면 정말로 사람들을 화나게 할 수 있다.츄우우우히:2010년 10월 28일(UTC) Seb Az86556^{> haneʼ} 16:59 [응답]

핼러윈에 사탕 같은 사람에게 이런 권리를 나눠주진 않을 거야아마 이런 도구들에 대한 엄격한 기준이 있을 겁니다.그 기준들이 정확히 무엇인지 나는 모르겠다.Thing // Talk // 기여:17:37, 2010년 10월 28일 (UTC)[응답]

위키백과:도구 및 위키백과에 대한 요청:도구 요청에 대한 가이드는 초안이다.미세한 디테일이 해결되어야 할 것이다. --Alpha Quadrant^talk 18:00, 2010년 10월 28일 (UTC)[응답]

패트롤러 권리의 요건은 최소한 몇 천 명으로 대폭 상향 조정되어야 한다.마음만 먹으면 하루 만에 500번의 반전과 500번의 경고를 받을 수 있었다.나는 적어도 8개월에서 9개월에 걸친 반달 투병 경험이 있어야 한다고 생각한다. 특히 권리를 요구하기 1~2개월 전에 실수가 거의 없다.Thing // Talk // 기여 18:07, 2010년 10월 28일 (UTC)[응답]

최소 5000개의 반반달리즘 편집 및 8개월 경험으로 변경. --Alpha Quadrant 18:22, 2010년 10월 28일(UTC)[응답]

File Uploader I는 파일 네임스페이스로 제한된 권한을 원하지만, Commons 사용자, 특히 Commons Administrator의 경우 마이그레이션을 쉽게 할 수 있는 권한을 얻는 것을 볼 수 있다.다른 사람들은...전체적인 상황을 복잡하게 만드는 측면에서, 아마도 그들이 가치 있는 것보다 더 많은 문제를 일으킬 것이다.대부분의 WP 백로그들은 이러한 권한을 필요로 하지 않는다.Rd232 15:57, 2010년 10월 28일 (UTC)[응답]

• 반대하라. 이 제안은 실행될 경우 해결할 수 있는 더 많은 문제를 야기할 것이다.나는 '사용자 권한'movefile을 별도의 사용자 그룹으로 나누는 것만을 지지할 것이다. 이는 관리자 권한으로 의도된 적이 없다.Ruslik_Zero 18:59, 2010년 10월 28일 (UTC)[응답]
• 아니, 내가 다시 버튼 하나라도 있었으면 좋겠지만, 그것은 심한 학대를 받는다는 장점이 있다.만약 사용자가 RFA를 통과할 수 없다면, 그것은 그들 자신의 잘못이다.나는 샌디의 말에 동의한다.시크릿 20:38, 2010년 10월 28일 (UTC)[응답]
• 반대 이런 종류의 일은 계속 올라왔고, 같은 이유로 몇 번이고 격추되었다.관리직은 신뢰할 수 있는 사용자를 위한 것이다.사용자가 완전한 관리자가 될 만큼 신뢰할 수 없는 경우 몰래 들어갈 수 있는 백도어가 없어야 하며, 다른 사용자를 차단하지 않아야 한다.또한, 언급했듯이, 관리자는 스팸 발송자를 차단하고 그들이 추가한 모든 스팸을 삭제하는 것과 같은 상황에 대처하기 위해 mre를 사용하는 경우가 많다.한 명의 관리자가 처리할 수 있는 상황은 이러한 부분 관리자를 여러 명 필요로 하거나, 작업을 완료하기 위해 실제 관리자를 찾아가야 할 것이며, 실제로 효율성을 떨어뜨릴 수 있다.비블브록스 (대화)20:46, 2010년 10월 28일 (UTC)[응답]
• 아니란 말은 아니란 뜻이다.Killiondude (대화) 20:57, 2010년 10월 28일 (UTC)[응답]
• "관리자"라는 생각을 버리는 것을 지지하라. 반대자들은 "이것은 관리자로 가는 뒷문"과 같은 말을 계속한다.그것은 요점을 완전히 빗나가고 있다.우리는 "관리자"라고 불리는 것을 가져서는 안 된다.우리가 이런 기술적 허가의 보따리를 가져다가 전통적으로 추가적인 권한과 연관되어 있는 것이라고 부른 것은 오해의 주요 원인이 되어 왔다.우리가 이것을 고칠 수 있는 유일한 방법은 그것이 실제로 기술적인 허가에 불과하다는 것을 분명히 하는 것이다.중요한 기능을 분산시켜 후계구도를 없애면 사실상 '레벨업핑'을 없앨 수 있다고 생각한다.물론 차단이나 삭제와 같은 민감한 기능은 롤백보다 체크 유저가 더 얻기 어려운 것처럼 더 높은 막대를 가질 것이다.긱스 (토크) 21:20, 2010년 10월 28일 (UTC)[응답]
• 이 RFA의 일부 지원은 중단되었고, 우리의 적극적 관리자 수는 줄어들고 있으며, 지난 2년 반 동안 1,021명에서 800명 미만으로 감소했다.어떤 시점에서는 상황이 바뀌어야 할 것이다. 아무리 불쾌한 시점이라 할지라도 변화에 대한 생각은 어떤 시점에서는 바뀌어야 할 것이다.나는 상황이 위기에 이르기 전에 우리 자신을 개혁하는 공동체의 모습을 선호한다. 좋은 때에 방향의 완만한 변화가 보통 마지막 순간의 공황보다 더 부드럽기 때문도 아니다.나는 이러한 특정한 해결책들이 복잡하고, 각각의 패키지에 너무 많은 권리를 포함하며, 콘텐츠 제작자와 파괴 투사의 기묘한 혼합을 가지고 있다고 생각한다.분리가 되지 않은 다음 오른쪽을 위한 나의 제안은 블록 버튼일 것이다. 그것은 두 번째로 많이 사용되는 관리 도구지만, 우리가 항상 이용할 수 있어야 할 것은 공공 기물을 파괴할 수 있는 사람들을 차단할 수 있는 것이다.IP와 확증된 편집자에 대해서만 사용할 수 있는 블록버튼을 만들면 유용한 사용자 그룹을 만들었다고 믿으며, "GA나 FA가 있어야 한다"는 여단이 이 역할에 신뢰할 수 있는 반달파이터를 임명하는 것을 용인할 수 있기를 바란다.대부분의 AIV 보고서는 그러한 사용자들에 의해 해결될 수 있고, 때때로 그들이 관리자가 삭제하도록 몇 개의 속도를 남겨도 상관없다 - 긴급한 것은 반달 행위를 중단시키는 것이다.2010년 10월 28일 (UTC) 21:45, 에레슈피엘체커스[응답]
  • • 도메인별로 권리를 제한하는 것은 지역사회의 승인을 받을 가능성이 더 높다.소프트웨어에 대한 권한이 제한된 파일 네임스페이스(File 네임스페이스)를 추천했다. IP 및 비자동 확인 소프트웨어에 제한된 블록 툴도 WP를 장려할 우려가 있지만 내 표를 얻을 수 있을 것이다.물림.Rd232 11:57, 2010년 10월 29일 (UTC)[응답]
  • 나는 지금까지 이 제안을 지지하는 유일한 관리자, 다른 모든 사람들이 비관리자라는 것을 알게 되었다. 그것은 사람들이 도구에 관심이 있지만 RFA를 통해 기꺼이 가지 않을 것이라는 것을 말해준다.우리는 RFA를 몇 년 전의 표준으로 되돌려야 하는데, 그것은 관리 도구를 주는 것이 아니라 실수를 하는 편집자에게 더 관대했던 것이다.지금 당장은 어떤 질문에서 한 번 실수하거나 (나처럼) 낙담하게 만드는 잘못된 결정을 한 편집자를 용서할 수 없다.비밀 22:22, 2010년 10월 28일 (UTC)[응답]

비밀, User:stwalker 또한 관리자다.또한, 관리자가 되는 것은 감독자가 아니다. --Alpha Quadrant 00:00, 2010년 10월 29일 (UTC)[응답]

• • • 나한테는 그게 바로 문제야."관리자가 되기", "관리자가 되기"그냥 데이터베이스에 조금 있을 뿐이야.그것은 당신을 사람으로 정의하거나 편집자로 정의하지 않는다.우리는 그것이 정말로 무엇을 의미하는지 모든 사람들에게 상기시키기 위해 그것을 더 자주 "비트"라고 부르곤 했다.나는 "행정가"라는 단어의 정상적인 비위키 함축이 사물을 더럽혔다고 생각한다.그들은 관료에게 했던 것처럼 바보 같은 이름을 붙였어야 했다.긱스 (토크) 01:52, 2010년 10월 29일 (UTC)[응답]
      • 에러, 남성/여성/죽음/생존하는 것 역시 "데이터베이스의 비트"에 불과하지만, 그렇다고 그것들이 중요하지 않다는 뜻은 아니다."조금만"/"걸레만" 유사점을 은퇴해야 할 때다.일회용 주사바늘이 생기기 전 며칠 동안 주사를 "조금만 따끔한 것"으로 가장한 것처럼 오해하고 있다. - 포인틸리스트 (토크) 11:37, 2010년 10월 29일 (UTC)[응답]
• 지난 몇 달 동안 이것에 대한 토론을 본 것이 이번이 네 번째였기 때문에 매우 반대한다.그 합의는 항상 "아니오"를 외치고 있다.위키피디아 토크에서 내 모든 관심사에 대해 누군가 언급한다.반달 전투기#나의 의견(반달 전투기 반관리권뿐만 아니라 그러한 모든 제안에 적용됨)과 나는 지지할 것이다.그러나 이것은 많은 사용자들에 의한 포럼 쇼핑이 되고 있으며(의도적이든 아니든) WT에는 여전히 두 개의 스레드가 있다.RFA 역시 권리 분리와 관련된 것으로, 어느 쪽도 전혀 공감대가 없다.누군가 나에게 말해주길: 왜 우리가 RfA를 먼저 고치지 않고 더 복잡한 RfA 타입의 프로세스를 만들어야 하는가? 그리고 TTTSNB를 예로 들자면, 왜 그가 컨텐츠로 더 일하라고 요구하는 사용자들의 말을 듣지 않았는데 내가 그에게 추가적인 권리를 믿어야 하는가?내가 그를 믿을 수 없다면, 나는 그를 블록으로 믿을 이유가 없다고 본다. 왜냐하면 그것들은 비슷한 원칙에 기초하고 있기 때문이다.사용자가 CSD만 온위키 작업으로 기사를 작성하는데, 차단이나 보호로 신뢰할 수 없다면 왜 삭제 기능을 얻어야 하는가?모든 것이 교차한다; 당신은 모든 주요 정책을 알고 있거나 알지 못하며, 당신은 모든 권리를 얻거나 얻지 못한다. 왜냐하면 어떤 것이 특히 어떤 표준적인 디스소프나 디 라이트 과정 없이 심각하게 잘못될 수 있기 때문이다. /the etechCOMMS/ 01:28, 2010년 10월 29일 (UTC)[응답]
• 구현을 많이 지원하지 않는 경우 아이디어를 지원하십시오.관리자 능력을 따로 나눠주자는 생각은 한동안 있던 생각이다.광범위하게 지지해 왔지만, 일반적으로는 특별히 나쁘지 않은 현상 유지에 대한 공감대가 형성되어 왔다.나는 그것이 어떤 면에서는 "게임과 같은" 것으로 여겨질 수도 있지만, 낮은 신뢰와 책임으로부터 관리자의 넓은 권리와 신뢰로 가는 분명한 길을 갖는 것이 전체 범위의 관리자 권한으로 가는 스트레스를 줄이는 데 도움이 될 것 같은 좋은 생각이라고 생각한다.나는 특히 업무 중심 패키지에 대한 아이디어가 마음에 드는데, 이 패키지는 제안서에 진정으로 추가되는 것이다.그러나 나는 우리가 어떤 특정한 일련의 소포를 받아들이는 것으로 곧장 달려가야 한다고 생각하지 않는다: 우리는 먼저 이 소포에 어떤 권리가 포함되어야 하는지에 대한 몇 가지 원칙을 정해야 한다.예를 들어, 나는 자신의 행동을 되돌리는 능력이 중요하다고 생각하며, '삭제되지 않은' 권리 없이 주어지는 '삭제' 권리는 지지하지 않을 것이다.다만 삭제된 콘텐츠의 특성상 누가 입수하는지가 더 높은 차원에서 중요하다는 점에서 '미필터링'은 시사하는 바가 있다.내 생각에 이건 좋은 생각이야. 하지만 이 제안서를 수정해보자구.:){{Nihiltres talk 편집 }}} 01:45, 2010년 10월 29일 (UTC)[응답]
  • 날 용서해줘야겠지만, 난 관리자들이 신뢰받는다는 생각이 좀 이상하다고 생각해.신뢰는 책임감을 동반할 수 있지만 현재로서는 부족하다.2010년 10월 29일(UTC) 01:53, MalleusFatuorum 01:53, [응답]
    • 날 용서해줘야겠지만, 난 관리자들이 믿을 수 없다는 생각이 좀 이상하다고 생각해.행정관이 행정 특권을 부적절하게 사용한다면 백과사전에 큰 피해를 줄 수 있는 방법은 무궁무진하다."회계성" 드라마는 하루 더 남겨두어라: 그것은 이 토론과 거의 관련이 없다.{{Nihiltres talk 편집 ⚡}} 04:00, 2010년 10월 29일 (UTC)[응답]
      • 너는 네가 얼마나 현실과 동떨어져 있는지를 아주 잘 보여주었다.해결되어야 할 근본적인 문제는 반달 투사들에게 올바른 X와 Y를 주어야 하는지 아닌 관리자가 사실상 평생의 직업이라는 것이다.만약 그렇지 않다면, 이 모든 권리들은 이런 반복적인 떠들어대는 헛소리 없이 (물론 빼앗길 수도 있다.) 나눠줄 수 있을 것이다.MalleusFatuorum 13:41, 2010년 10월 29일 (UTC)[응답]
        • 동의하라. 이 모든 것은 만약 남용될 경우에 쉽게 탈피할 수 있는 방법이 있다면 불필요할 것이다; 현재 상태로는, 사람들은 폭탄을 주었고, 그 폭탄을 그들에게서 다시 빼앗을 방법이 없다. (그래, 그래, 이론적으로는 있지만 실제로는 일어나지 않는다.)이것을 쪼개서 논쟁하는 대신에, 단지 탈지하는 것을 더 쉽게 만들어라.츄우우우히:2010년 10월 29일(UTC) 쎄브 아즈86556 15:17[응답]
        • 말레우스, "현실과의 접촉에서 벗어난" 비트는 오히려 불필요했다.행정이라는 '생명을 위한 일자리' 문제가 이 논의와 접선돼 있다고 생각하지만, 정말 도입하고 싶다면 오히려 역할 지향적 권리 패키지에 대한 생각을 지지한다고 본다.영어 위키피디아가 탈피에 대한 좋은 정책이 없는 이유는 매우 드라마틱하기 때문이다.그것은 빅딜이다, 아니면 적어도 큰 거래는 성립된다.보다 세분화된 권한 배정을 허용함으로써 최소한 드라마 일부를 제거할 수 있다.예를 들어 블록 버튼을 두어 번 남용한 관리자가 있다고 가정해 보십시오. 관리 기능을 제거하지만 하나 이상의 다른 패키지를 허용할 수 있으며, 이는 사용자가 다른 영역에서 생산적인 관리자 유형의 작업을 자유롭게 계속할 수 있음을 의미한다.제거 조치에 내재된 사회적 피해를 최소화할 수 있다.관리자 특권을 획득하는 데 대한 장벽을 낮추는 것(이 구상이 주장할 수 있는 것임)도 이를 제거하는 데 대한 장벽을 낮추는 데 도움이 될 것이다(당신이 주장하는 것처럼 보이는 것은 매우 바람직하다).{{Nihiltres talk 편집 ⚡}} 2010년 10월 29일(UTC) 16:25[응답]
          • 나는 당신의 추리가 관리자들을 신뢰한다는 당신의 생각보다 훨씬 더 기괴하다고 생각한다.말레우스 파투오름 17:17, 2010년 10월 29일 (UTC)[응답]
• Patroller I의 아이디어를 지지하라. Patroller는 많은 항바이러스제 투사들에게 도움이 될 수 있기 때문에 Patroller의 아이디어를 지지하라. 그러나, 그 관행은 상당히 심각하게 논의될 수 있다.다른 사람들은 지금 중립을 느끼고 있다.--iGeMiNix 02:22, 2010년 10월 29일 (UTC)[응답하라]
• 지원 원칙.관리자 권한에는 특별히 관심이 없지만 "보호자" 도구, 특히 리디렉션 위로 페이지를 이동할 수 있는 기능 중 일부를 사용하고 싶다.이렇게 하면 필요할 때마다 관리자를 번거롭게 하기보다는 유지보수 작업을 직접 더 많이 할 수 있을 것이다.사사타 (대화) 03:05, 2010년 10월 29일 (UTC)[응답]
  • 그것은 내가 항상 부족하다고 느끼는 유일한 관리 도구일 뿐이다.MalleusFatuorum 03:10, 2010년 10월 29일 (UTC)[응답]
    • 개인적으로, 내가 가장 많이 사용했던 것 중 하나야, 내가 접근할 수 있다고 가정할 때.헤드폭탄 {토크 / 기여 / 물리학 / 책} 03:45, 2010년 10월 29일 (UTC)[응답]
• 보호 권한은 지원하되 다른 권한은 지원하지 마십시오.삭제와 차단이 보호보다 더 가혹하다.그러나 내 관점에서, 나는 반보호 페이지만 안전하다고 생각한다. 그리고 자동확증된 비관리자들은 여전히 보호된 페이지를 편집할 수 있기 때문에 회색 자물쇠로 페이지를 보호하지 않는 것이 안전하다고 생각한다.하지만, 나는 샌드박스를 보호하려는 의도를 가진 사용자들에게, 예를 들어, 메인 페이지나 이와 같은 어떤 허가된 텍스트도 보호하지 않을 것이다.요약하자면, 나는 보호자가 회색 자물쇠를 채우거나 떨어뜨리는 것만이 허용될 것이라고 생각한다.미니맥 (대화) 2010년 10월 29일 (UTC) 14:36[응답]

보류 중인 변경사항 보호를 추가 및 제거하는 방법은?계속 시행된다고 가정하면. --Alpha Quadrant^talk 15:20, 2010년 10월 29일 (UTC)[응답]

아 맞다, 내가 리뷰어가 아니라서 그걸 까먹었어.검토자 권리가 부여되었는지 여부에 관계없이 보호자에게도 보류 중인 변경 보호가 허용되어야 한다고 생각한다.미니맥 (대화) 2010년 11월 2일 12시 19분 (UTC)[응답]

• WareSpielChequers 및 Stwalkerster별로 파일 업로더, 패트롤러, 보호자 및 플러더 지원.—ғяіaз'Trsđøм • 샴페인? • 오후 12:27pm • 01:27, 2010년 10월 30일 (UTC)[응답]
• 극도의 지원!그것은 행정상의 밀린 업무들을 정리하는데 도움이 될 수 있다.또한, 일부 사건에 대한 대응 시간을 개선할 수도 있다.나는 이것이 훌륭한 제안이라고 믿는다. 그리고, 앞서 말했듯이, 모든 관리자가 모든 관리자 권한을 사용하는 것은 아니다. 따라서, RFA는 또한 그들을 돕는 것을 더 어렵게 만들 것이다.패트롤러의 경우, 많은 롤백업자들이 리뷰어들이며, 이 오른쪽은 그들에게 몇 가지 다른 반-반달리즘 도구뿐만 아니라 둘 다 제공한다.위험-SJ ^Talk 16:37, 2010년 10월 30일 (UTC)[응답]
• 강력한 지원; 나는 이러한 것들이 몇 가지 더 많은 손에 넣을 수 있는 귀중한 도구가 될 것이며, 계속해서 논의되어 온 하나의 사용자 역할(관리자)에 모든 권리를 집중시키는 문제를 피할 수 있을 것이라고 생각한다...: 대중에게 나눠주지는 않지만, 적어도 RfA의 지옥같은 주보다 조금 덜 고통스러운 지역사회의 정밀조사를 통해, 우리는 더 많은 좋은 사람들이 이런 가치 있는 일을 하도록 할 수 있다.개인적으로 선호하는 것은 이러한 제안된 역할에서 적은 수의 권한을 제거하여 세부사항의 일부를 수정하는 것이다(예를 들어, "Patroller"가 반달-파이터인 경우, 콘텐츠 제작을 위한 오토파일 및 이미 확립된 사용자 역할을 위한 오토파일롤을 소급해야 하는가).나는 차라리 권리들을 번들거리는 것에서 벗어나고 싶다.리스트에서 적은 숫자를 넘으면 다른 사람들의 걱정을 덜어주는 데 도움이 될 수도 있다. 보브레이너 (토크) 17:01, 2010년 10월 30일 (UTC)[응답]
• 추후 지역사회가 협의할 사항과 함께 원칙적으로 지원한다.shoy (reactions) 13:45, 2010년 11월 1일 (UTC)[응답]
• 모두 반대하라. 아마도 재판일 것이다. 하지만 이것은 트로피 수집가들에게는 대단한 일인 것 같다.또한, 동시에 (동일한 사용자로부터) 여러 문제를 처리할 수 있는 우리의 능력을 무력화시킬 것이다.ǝɥM0N0 04:43, 2010년 11월 12일 (UTC)[응답]
• 방금 궁금했던 질문.몇 년 전에 관리 패키지에서 롤백 버튼이 번들링되지 않았는가?만약 그렇다면, 그것이 일부 사람들이 이 제안에 반대하는 이유일 수도 있다.미니맥(토크) 13:24, 2010년 11월 12일 (UTC)[응답]
• 지지하다.나는 처음에 "Patroller"와 "Flooder" 권리도 제안했다.얼어붙은 바람이 쌀쌀해질까? 2010년 11월 16일 00시 54분 (UTC)[응답]
• 지원 - 나는 이것을 대부분 지지하지만 나는 또한 대부분의 항목이 개별적으로 허용될 수 있거나 허용되어야 한다고 생각한다.15만 개 이상의 편집으로 나는 보호 페이지 편집, 속도 제한(노라테리미트), API 쿼리(apihighlimits) 및 기타 다양한 이벤트에서 더 높은 제한을 사용할 가치가 있다는 것을 증명했어야 했다. 오래 전에 관리자가 되는 것에 흥미를 잃었었다. --쿠미오코 (talk) 05:42, 2010년 11월 26일 (UTC)[응답]

평가판 제안

자, 이제 이 질문을 던졌네. "변경 보류 중"에서 했던 것처럼 재판을 위해 이 권한을 만들까?—ғяіaз'Trsđøм • 샴페인? • 오후 7시 49분 • 08시 49분, 2010년 11월 3일 (UTC)[응답]

Purger 사용자 권한을 생성하려면 Wikimedia Foundation Permission이 필요할 것이다. --Alpha Quadrant^talk 13:29, 2010년 11월 3일(UTC)[응답]

왜? --에어랜드 (대화) 00:57, 2010년 11월 4일 (UTC)[응답]

비관리자 사용자에게 삭제된 콘텐츠를 볼 수 있는 능력을 부여하는 것은 위키미디어 기반 정책에 어긋난다.푸르거 권리를 구현하기 위해서는 위키미디어 재단이 승인을 해야 할 것이다.그래서 위키미디어 재단 이사회의 승인이 필요할 것이다.지난주에 지미 웨일즈에게 WMF 연락처 문의 메일을 보냈는데 아직 답장을 받지 못했어. --알파 쿼드런트 01:29, 2010년 11월 4일 (UTC)[응답]

나는 투표에 대해 세 가지 선택사항을 제안한다.반대(자체 설명), 지원 원칙은 번들 반대(SPOB) (제안된 번들에 동의하지 않으면서 권한 번들 반대 원칙을 지원) 또는 지원(지원 원칙 및 위의 번들에 동의)

{class="wikable" - ! 반대!!지원 원칙은 묶음에 반대!!지원 - 0 2 0 }

SPOB 및 사용자들이 새로운 번들을 제안하고, 설명하고, 커뮤니티 컨센서스가 있는 번들을 전달할 수 있는 페이지를 제안한다.930913 (축하/불만) 00:46, 2010년 11월 4일 (UTC)[응답]

SPOB 이 "투표" 혹은 무엇이든지 간에 우리가 투표하고 있는 것이 잘못 정의되어 있기 때문에 실패할 것이다.가장 좋은 방법은 "도구 요청서"나 이와 유사한 초안을 작성하는 것이고, 초안이 확정되면 각 개별 묶음을 지역사회 승인에 제출하라. 그렇지 않으면 일부는 반대한다는 이유로 모두 반대할 것이다.그리고 차단과 삭제가 반대파를 독점할 것이기 때문에, 제안된 묶음에서 즉시 제거하자.헤드폭탄 {talk / 기여 / 물리학 / 책} 01:07, 2010년 11월 4일 (UTC)[응답]

이것을 서둘러 구현하는 것은 실패할 가능성이 높다.이 투표는 아마도 합의를 이끌어내는 최선의 방법은 아닐 것이다.나는 제안된 과정을 시작할 것이다.내가 초고를 쓰는 것을 도와줄 사람 있어?나는 편집자들이 초안에 대해 가지고 있을 수 있는 문제나 우려사항에 대해 위키피디아 토크 페이지에 이슈 섹션을 설정하여 그것들을 다룰 것이다.더 폭넓은 합의를 위해 우리가 이것을 제출하기 전에 초안을 작성하는데 도움을 받으려면, 아래에 당신의 이름을 입력하십시오.알파 사분면^talk

모금 현수막과 비슷한 방법으로 묶음을 만들 것을 제안해도 될까?930913 (축하/불만) 01:56, 2010년 11월 4일 (UTC)[응답]

수십 개의 사용자 권리를 만드는 것은 편집자들이 이해하기 더 어렵게 만들 것이다.이러한 사용자 권한을 만들면 편집자가 작업을 더 쉽게 할 수 있고, 더 혼란스럽게 할 수 없다.각 사용자에 대한 사용자 정의 권한을 만드는 것은 혼란을 야기할 뿐이다. --Alpha Quadrant^talk 13:38, 2010년 11월 4일(UTC)[응답]

수십 개가 제안될 수도 있지만, 나는 소수의 사람들만이 지역사회의 합의를 얻을 것이라고 생각한다.사용 전에 제안된 각 묶음에 대한 합의를 이끌어내는 것이 어떻게 혼란을 줄지 모르겠다.사용자 정의 사용자 권한은 어디에서 왔는가?930913 (축하/불만) 21:53, 2010년 11월 4일 (UTC)[응답]

요청 프로세스 작성 2차 초안

1. 알파 사분면 ^{이야기를 나누다}
2. 기꺼이 돕겠다.미스터 R00t 02^Talk:01, 2010년 11월 9일 (UTC)[응답]

위의 내 논평에 따르면 반대하며 투표는 악하지 않은가? -- 도! 01:52, 2010년 11월 4일 (UTC)[응답하라]

반대 - 나는 일부 비관리자들이 일을 더 쉽게 할 수 있도록 하는 잠재적인 사용자 그룹이 있을 수 있다고 생각하지만, 이것이 그것을 하는 방법이 아니다.이 그룹에는 별로 많은 생각들이 들어있지 않은 것 같다."보호자 - 다음과 같은 다양한 정리 태스크를 수행하는 사용자. 개선된 기사" - 사용자의 95%에 해당된다.새로운 사용자 그룹을 만들기 전에, 그룹 내 각각의 권리에 대한 정당성과 해결책의 어떤 특정한 문제가 있어야 한다.그것은 "번들"이 될 필요는 없다 - 만약 하나의 권리를 갖는 것이 유용하다면, 우리는 하나의 우파 그룹을 만들 수 있다; 그것은 단지 그것을 더 좋게 보이게 하기 위해 쓸모없는 잡동사니들로 채워질 필요는 없다.미스터 지맨 2010년 11월 4일 (UTC) 19:50[응답]

그래서 반대하기보다, 당신은 SPOB를 원한다.우리가 모금과 유사한 수단으로 묶음을 선택한다면(위 참조), 제안자들은 어떤 묶음의 필요성과 각 권리의 필요성을 정당화해야 할 것이다. 그렇지 않으면 공동체가 반대할 것이다. 930913 (축하/불만) 21:53, 2010년 11월 4일 (UTC)[응답]

그렇지 않아, 나는 특정 묶음보다 더 많은 것에 동의하지 않아.나는 이곳의 모든 과정이 완전히 결점이 있다고 생각한다.그것은 잘못된 지점에서 출발한다.여기서의 질문은 "다발을 가져야 할까?그렇다면 그들은 무엇이 되어야 하는가?"첫 번째 질문은 무의미하다.우리는 이미 롤백, 계정 생성자, 필터 관리자 편집, 자동 실행이 있다.우리는 새로운 사용자 그룹을 생각해내기 위해 우리가 할 수 있는 일을 할 필요가 없다.만약 이것에 대해 어떤 종류의 과정이 있다면, 그것은 단지 사용자들에게 그들이 개인적으로 유용하다고 생각하는 것을 물어보고, 그 사용자들을 도울 수 있는 그룹을 결정하는 것이어야 한다.만약 그 아이디어가 단순히 가상적인 상황에 근거하여 관리 도구를 분할하는 것이라면, 아니, 나는 그것을 완전히 반대할 것이다.2010년 11월 4일(UTC) 11월 4일 Mr.Z-man 22:52[응답]

''만 만들 수 있는 사용자 그룹'은 하나뿐입니다.filemover그것은 이미 하원에 존재하며 여기에 유용할 것이다.Ruslik_Zero 19:53, 2010년 11월 5일 (UTC)[응답]

• 반대한다. 나는 일부 취객 편집자들이 "좋아, 내 목표는 일주일 안에 가능한 많은 사용자를 차단하는 것이다."라고 생각할 것이라는 것을 알고 있다.이러한 시간적 실험에 대한 아이디어는 여전히 관리자 권한을 얻을 때 말하는 것만큼 많은 문제를 일으킬 수 있다; 당신은 여전히 백과사전에게 많은 해를 끼칠 수 있다.미니맥 (대화) 2010년 11월 19일 (UTC) 14:58 (대화)[응답]
• 반대 몇몇은 실제로 이 제안에 참여했는가, 아니면 30초간의 아찔한 흥분 속에 만들어졌는가?이 모든 것은 결점이 있고 불필요하다.---다이브폭탄은 영국인 18:33, 2010년 11월 23일 (UTC)[응답하라]