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

사용자 이동 제안:PhantomTech/sandbox/IRC 위키백과에 대한 거부권:IRC 도움말 거부권 및 사용자를 #wikipedia-en-help 채널로 연결하는 모든 링크 리디렉션:IRC 도움말 거부권 및 사용자:PhantomTech/Scripts/IRCNik.js to MediaWiki:보통.js.팬텀텍 (대화) 04:02, 2015년 4월 12일 (UTC)[응답]

세부 정보:IRC 도움말 채널에는 현재 몇 가지 문제가 있으며, 그러한 문제 중 몇 가지는 사람들이 종종 같은 질문을 하고, 도우미들은 때때로 그들이 받은 흠집 때문에 사람들을 돕는 문제를 가지고 있다는 것이다.지금은 거의 모든 링크가 기본 닉네임을 준다.WP help" 끝에 멋진 긴 숫자가 있다.이 게시물이 지적하듯이, 이것은 도움을 주려는 사람들뿐만 아니라 도움을 받는 사람들에게도 문제를 일으킨다.이 제안은 반복 질문 수를 줄이고(모든 사람이 페이지를 읽을 수는 없겠지만) 사용자의 IRC 닉네임을 기본적으로 제공하는 것을 목표로 한다.도움말 채널의 모든 문제가 이것으로 해결되는 것은 아니지만, 더 큰 문제 중 하나를 해결할 수 있는 아주 간단한 수정이다.현재 이 스크립트는 다음과 같은 방법으로 닉네임을 선택한다.

• Javascript 폴백(fallback)을 지원하지 않는 사용자는 현재 "" 중 하나를 사용하십시오.WPhelp" 닉스
• 사용자가 로그인한 경우, 닉네임은 영숫자가 아닌 문자가 밑줄로 대체되고 "-WP##"가 끝에 추가된 사용자 이름의 처음 11문자로, 사용자 이름에 밑줄로 대체된 문자가 4자 이상인 경우를 제외하고 ##는 두 자리 숫자 번호로, 다음 옵션이 사용된다.
• 다른 모든 사용자에게는 무작위 색상으로 시작하는 사용자 이름이 부여되며, 여기서 ###는 3자리 숫자다.색은 사람들의 기분을 상하게 할 가능성이 가장 적기 때문에 사용된다.

예: 사용자 이름이 User인 사용자 이름 WP42인 사용자 이름, 사용자 이름이 Full인 사용자 이름.Stop이 사용자 이름 Full_Stop-WP20을 가져올 수 있으며 로그인하지 않은 사용자는 사용자 이름 Blue-WP493을 얻을 수 있다.참고로 "might"는 사용자 이름 끝에 있는 숫자가 랜덤하게 선택되고 마지막 예시의 색상도 랜덤하게 선택되기 때문에 사용된다.설명이나 다른 예시를 자유롭게 요청하십시오. 스크립트는 페이지의 맨 위에 있는 지침에 따라 테스트할 수 있습니다(User:팬텀테크/샌드박스/IRC 고지 사항: 어떤 닉네임이 주어질지 확인하십시오.팬텀텍 (대화) 04:02, 2015년 4월 12일 (UTC)[응답]

크로스는 위키프로젝트 AFC, 찻집, 헬프 데스크에 게시했다.팬텀텍 (대화) 2015년 4월 15일 16:54 (UTC)[응답]

• 거부권 아래에 서면 설명을 참조하면, 일부 중대한 개정으로 이를 뒷받침할 수 있다.Common.js에 그러한 대본을 추가하는 것을 반대하며, 그러한 대본은 그러한 것에 적합한 장소가 아니다.기본 가젯(예: 찻집 질문 스크립트)에 추가된 닉 선택기를 볼 수 있었고, 나는 그러한 제안을 지지할 것이다.—{{U Technical 13}} (e • t • c)15:41, 2015년 4월 13일 (UTC)[응답하라]

고지서에 무엇이 잘못되었다고 생각하는지 좀 더 구체적으로 말해 주시겠습니까?IP 사용자에게 기본 가젯이 사용 가능하다고 가정할 때, 나는 이것을 공통적인 것이 아닌 기본 가젯으로 만드는 것에 문제가 없다.팬텀텍 (대화) 2015년 4월 13일 (UTC) 19:44[응답]

• 전폭적인 지지.디폴트온 가젯으로 구현하거나 common.js에 추가하여 구현하는 것에 대해 언급하는 것은 아니지만, 관례에 따른 것은 무엇이든 나는 괜찮다. --L235 (t / c / ping in response) 16:35, 2015년 4월 13일 (UTC)[응답하라]
• 지지하다.왜냐하면 사람들에게 프리노드 웹챗 인터페이스에 대한 문맥을 주는 것도 좋고, 사용자 이름 일관성도 좋은 터치감이기 때문이다.그러나 나는 질문하기 전에 질문자들에게 RTFM에게 말하는 것은 불필요하고 도움이 되지 않는다고 생각한다.찻집 IRC 채널(TH는 반RTFM이다.)을 위해 이것을 시행할 계획이라면 언어가 없어지는 것을 강력히 선호한다. 즉, TH IRC 채널은 어차피 아무도 사용하지 않기 때문에 기본적으로 논제다.건배 - 제이모^{Talk to Me}_{Email Me}
  • 그래, 난 거기서 새로운 편집자들을 자주 보지는 않지만, 그건 THQ 페이지에서 연결된 것과 지금까지 언급된 유일한 것이기 때문일 거야.그런 식으로 찻집 채널에 도움을 주기도 하는데, 그것은 또한 반RTFM이 되어야 한다는 것을 시사한다.—{{U Technical 13}} (e • t • c)2015년 4월 16일(UTC) 16:41, 16[응답하라]
• 지지하다.훌륭한 솔루션 및 구현.아퍼슨 (토크!) 03:29, 2015년 4월 17일 (UTC)[응답]
• 그래서... 당신은 사람들에게 그들의 사용자 이름을 그들의 IP주소와 매우 쉽게 연결할 수 있는 링크를 제공하길 원하십니까?레곡™ (대화) 03:39, 2015년 4월 17일 (UTC)[응답]

@Legoktm:그래, 하지만 이미 끝난 일보다 많지 않아.이 스크립트는 사용자 이름을 강요하는 것이 아니라 미리 작성해서 그들이 원할 경우 변경할 수 있는 선택권을 갖게 한다.현재와 같이, 사람들은 이미 그들의 사용자 이름을 그들의 IP와 연관시키고 있다. 아마도 그것을 알지 못한 채.사람들이 흔히 받는 첫 번째 질문 중 하나는 "사용자 이름은 무엇인가" 또는 "어떤 기사/초안"으로 쉽게 도움을 받을 수 있다. 마지막 질문은 직접적이지 않지만, 한 명의 기고자가 있는 초안에서 사용자 이름을 알아내는 것은 어렵지 않으며 IRC는 가입할 때 IP를 제공한다.이 해결책으로 협회는 더욱 자동화되고 있지만 IRC에 익숙하지 않은 사람이라면 누구나 경고할 수 있는데, 그것은 지금 현재 존재하지 않는 것이다.팬텀텍 (대화) 2015년 4월 17일 16:50 (UTC)[응답]

• 지원 - 나는 그것이 잘 작동하고, 멋지고, 모든 IRC를 연결할 수 있는 중심적인 장소를 제공한다고 생각한다.우리는 어쨌든 IP주소에 대해 이야기하는 거부권이 필요하며, 다른 것들도 꽤 유용하다.13번 기술자가 만족하는 방식으로 고지서를 수정하는 것에 반대하지 않는다.— 키키추걸 17:02, 2015년 4월 20일 (UTC)[응답]
• 지원, 비록 불필요한 전문용어(IP 어드레스 대신 IP, 아무 설명 없이 IRC, 자주 묻는 질문 대신 FAQ, #위키피디아-엔헬프)는 녹색 상자에서 피하겠지만.User:에서 녹색 상자의 "noob 친화적" 버전을 조롱했다.Ahecht/샌드박스/IRC_Disclaimer --Ahecht (TOKPAGE
  ) 17:18, 2015년 4월 20일 (UTC)[응답]

@아헤흐트:변경 사항을 내 샌드박스에 자유롭게 병합하십시오. 버전이 더 사용자 친화적인 것 같긴 하지만.팬텀텍 (대화) 2015년 4월 20일 (UTC) 20:09 [응답]

• 나는 코드를 다듬어 HTML5 호환으로 만들었다.그것은 나에게 잘 어울린다.IRC 닉스에 대해서는 WPHelp/Guest 이슈와 레고크tm이 여기서 꺼낸 익명 이슈를 모두 다루는 다른 옵션을 추가했다.—{{U Technical 13}} (e • t • c)2015년 4월 20일(UTC) 20:30[응답]

• 아직 안 끝났다고 가정하면 좋은 생각인 것 같아.나는 왜 개정 ID와 관련된 이상한 것이 대신 시행되었는지 잘 모르겠다.그것은 누군가의 초안이 무엇인지 알아내는 소름끼치는 방법인 것 같다; 그들의 사용자 이름만 가지고 있는 것이 더 낫고, 등록된 닉스에게는 -WP#### 일이 좋은 해결책이다.ekips39❦talk 01:54, 2015년 4월 28일 (UTC)[응답]
• 첫 번째 문자가 문자여야 하는 16개의 영숫자와 밑줄, 하이픈 및 파이프에 대한 IRC 이름 지정 제한으로 인해 대부분의 경우 작동하지 않는 것을 위해 백과사전의 모든 사용자에게 글로벌 자바스크립트를 추가하도록 하는 것에 강력히 반대한다.Many of the people who come to help in the channel are IP editors, so the script wouldn't work for them (can't start with a number or include a period), many of the editors with accounts I've found to have non-latin usernames (Múññå ShÈœhzÄdå), start with a number (2-Door), or include disallowed punctuation (Dermont~enwiki or As'ad A R).

또한, 현재의 닉스 계획도 잘못 전달되고 있다(어제 합의 내용에 따라 수정되었으므로).WPHelp 사용자 이름은 도우미에게 도움을 청하는 사람에게 도움을 줄 수 있는 출발점을 제공하는 닉네임을 선호하지 않는다.꽤 자주, 사람들은 그들의 초안을 어떻게 연결하는지 알지 못하고, 사용자 이름이 없고, 도우미를 그들의 초안이나 질문에 가리키지 못하고, 그리고 그 사람들은 "미안하지만, 어쩔 수 없어, 네가 단서를 얻었을 때, 가버리고 돌아올 수 없어"라고 보내진다.현재, 모든 템플리트는 초안이나 단일 문자 표시기의 상태와 그들이 가져온 페이지의 수정 ID를 제공하며, 그렇지 않으면 도우미가 친근감을 높이고 편집자 보존을 개선하는 데 도움을 받을 수 있다.

초안으로부터 IRC로의 링크를 빼앗기 위한 이 제안은 ("그냥 도움을 받을 수 없을까?"라는 좌절감을 더하기 위해 별도의 페이지를 통해 탐색해야 한다) Common.js에 글로벌 자바스크립트 팽창을 추가한다. (그 못지않게 가젯에 WMF 표준을 준수하지 않는 코드 사용)내가 설명을 잘 못 하는 건 알지만, 이 커뮤니티는 나를 "기술 지향적인 편집자들의 강한 목소리"라고 해서 이번 주의 편집자로 만들었고, 이 말이 내 목표가 이 고도의 기술 제안이 야기할 피해로부터 위키를 보호하는 것이라는 것을 여러분 중 몇몇에게 말해주길 바란다.—{{U Technical 13}} (e • t • c)2015년 4월 28일 19:23 (UTC)[응답하라]

존중한다; 기술 13은 각각 대담하게 투표한 두 개의 분리된 글머리 기호로 두 번 게시하는 것은 오해의 소지가 있다.그리고 나는 당신이 이번 주 편집장을 받은 것에 대한 지명 성명서를 쓴 사람으로 다음과 같이 말한다: EotW는 확실히 공동체 토론에서 어떤 것에든 영향을 미치는 것으로 언급되어서는 안 된다.감사합니다, --L235 (t / c / ping in response) 04:10, 2015년 4월 29일 (UTC)[응답]

@technical 13: 왜 당신이 당신의 원래 직책을 확장하는 것 대신에 두 번 투표하기로 결정했는지 혹은 왜 당신이 당신의 "강한 반대"에 그렇게 많은 형식을 추가할 필요성을 느꼈는지 확실하지 않지만, 내가 당신의 요점에 답하기 시작해야 한다고 추측한다.IP 유저에 문제가 있어서 무슨 말을 하는지 모르겠는데, 제안서를 읽어보셨죠?나는 앞서 IRC에서 당신에게 익명 사용자들은 존재하지 않는 사용자 이름을 사용하려고 하지 않고 스크립트에 의해 색상으로 회계처리된다고 설명하기도 했다.닉네임으로 사용할 수 없는 사용자 이름 또한 설명되며, 제안서에 설명되어 있듯이 영숫자가 아닌 문자는 밑줄로 대체되고 너무 많은 문자를 교체할 경우 색상으로 대체된다.사용자 이름에 문제가 생길 수 있는 사용자가 많다고 하셨는데, 혹시 그런 문제를 뒷받침할 만한 통계 자료가 있으신지요?닉네임을 '잘못 표현'해서 미안한데, 이 제안이 나온 후에 바뀌었다고 지적하셨으니, 그나저나 변경에 대한 공감대가 어디인지 지적해도 괜찮으시겠습니까?그것은 없었던 것 같다.다시 말하지만, 사람들이 그들의 초안을 지적할 수 없거나 도움이 필요한 것에 대해, 얼마나 많은 사람들이 이 문제를 가지고 있는지 보여주는 통계를 제공할 수 있는가? 이 제안의 결과로 문제가 없을 사람을 제외한다면?이 제안에 대한 합의가 이루어지지 않더라도, 현재의 (새로운) 시스템은 교체되어야 하고, 아무런 합의 없이 실행된 것으로 보이며, 주요한 프라이버시 문제로서, 사용자 이름을 IP 주소로 효과적으로 연결하기 위해 임의 번호처럼 보이는 것을 이용한다.
당신의 EOTW 메시지와 관련된 부 메모로서, "커뮤니티"가 당신을 이번 주의 편집자로 만들었다고 말하는 것은 매우 적은 수의 사용자만이 토론에 참여한 것처럼 보이기 때문에 총체적인 잘못된 표현인 것 같다.게다가, 이런 식으로 자신을 광고하는 것은 다소 부정직하고 옹졸해 보인다.당신과 친숙한 편집자들이 있고, 이 편집자들은 당신의 기술에 대한 그들만의 의견, 당신이 얼마나 신뢰받아야 하는지 등등, 그들에게 이것은 무의미하다.당신이 남긴 것은 어떤 이유로든 당신에게 익숙하지 않고 EOTW에 익숙하지 않을 수 있는 편집자들인데, 그들에게 이 정보를 제공하는 것은 만약 sysops가 그들의 응답에 그들의 관리자 지위를 광고하고 그들이 하지 않는 것은 이러한 이유들로 인해 생성될 것과 같은 방식으로 불필요한 편견을 만들어낸다."이 코드가 제대로 포맷되지 않았으니 그냥 생각을 버리자, 날 믿어"라고 말하는 것은 비생산적일 수도 있다.확실히 당신이 주장하는 기술적 전문지식을 가진 누군가에게 그것이 문제가 될 수 있는 어떤 기준에 따라 코드를 적합하게 만들어야 한다고 주장하는 것은 사소한 일이며, 당신이 당신의 원래 반대편에서 잘못된 선택 장치를 지원하겠다고 명시적으로 말한 것은 도움이 되지 않는다.팬텀텍 (대화) 04:37, 2015년 4월 29일 (UTC)[응답]

응. 비슷한 거 썼는데 별로 안 좋고 많이 넣지도 않아서 굳이 다 올리지 않을게.하지만 몇 가지 추가 포인트가 있었다.T13이 주는 이유로 외면하는 사람들을 본 적이 없고, 많은 사람들이 수정 ID 닉스의 취지를 꺾는 맞춤 닉스를 들고 들어온다.ekips39❦talk 04:43, 2015년 4월 29일 (UTC)[응답]

• 나는 여기 아래를 볼 수 있는 쪽지와 함께 위의 표를 쳤다.위에 그렇게 많은 문자를 들여놓는 것은 부적절했을 것이고, 지난번처럼 내가 몰래 들어가려 했다고 비난했을 것이다.그래서 여기에다가 넣었어.나는 편집자의 사생활과 보안을 손상시키기 위해 자바스크립트 코드를 추가하는 것이, 특히 그 코드가 기술적 관점에서처럼 심하게 결함이 있을 때, 큰 문제라고 매우 생각한다.또한, 이 섹션의 제목은 매우 기만적이기 때문에, 나는 그것을 적절하다고 다시 말했다.—{{U Technical 13}} (e • t • c)2015년 4월 29일 14시 19분(UTC)[응답하라]

• 흥미로운 새 제목.제안서는 도움말 채널에 관한 것이지, 모든 IRC 링크에 (어쨌든, 모든 IRC 링크에 거부권을 어떻게 추가할 것인가?)에 관한 것이 아니며, "글로벌 자바스크립트 추가 제안"은 마치 우리가 전에는 글로벌 자바스크립트를 전혀 가지고 있지 않았던 것처럼 들린다.내 생각에 이전 제목이 잘못된 것은 아니지만, 닉 비트에 대한 것을 포함할 가치가 있다.글로벌 자바스크립트의 목적이 무엇인지 분명히 해 주는 것.너무 장황하게 들리지 않는 말을 할 수 있는 방법이 생각나지 않는다.또한, 자바스크립트는 그렇게 하지 않을 것이지만, 이것은 상세하게 설명되어 있다...ekips39❦talk 23:17, 2015년 4월 29일 (UTC)[응답]

• @Ekips39:제목을 좀 더 정확하게 하기 위해 편집했다.또한, 여전히 기술 13의 반대 의견을 구매하지 않고, 팬텀으로 본다.테크사는 그들의 대본이 영숫자 문제를 모두 해결할 것이라고 분명히 설명한다.현재 개정된 사용법은 또한 이 텍스트 벽 어딘가에서 언급된 것처럼 잠재적인 사생활 문제 입니다...— 키키추걸 18:23, 2015년 4월 30일 (UTC)[응답]
  • 초안을 볼 수 있는 IP/개인만 초안에 연결하기 때문에 현재의 revid 사용은 프라이버시 문제가 아니지만, 이 제안은 사용자 이름을 IP에 직접 연결하고 사용자를 아웃소싱하는 것이기 때문에 프라이버시 문제임에 틀림없다.—{{U Technical 13}} (e • t • c)03:07, 2015년 5월 7일 (UTC)[응답하라]
    • 그 면책 조항은 그 문제를 해결하기 위한 것이다.그것은 당신에게 당신의 IP를 폭로할 것이라고 경고한다.어차피 자진해서 방에 들어간다면, 기꺼이 공개하고 당신의 사용자 이름에 연결시켜라.합의 없이 행해진 RevId는 사생활 침해 문제라거나 IP가 공개될 것이라는 내용조차 명확하게 밝히지 않고 있다.— 키키추걸 03:38, 2015년 5월 7일 (UTC)[응답]
    • 초안 링크에서 IRC 도움말 채널에 가입하는 사용자가 주요 기여자 또는 대개 유일한 기여자라고 말하는 것은 안전한 가정이며, 현재 시스템에 대한 당신의 원래 언급은 익명성이 중요한 정도가 헬프에서 인지하는 익명성에 한정되어 있다고 언급함으로써 이러한 익명성의 결여를 인정하는 것 같다.익명성으로 위장한 거의 완전한 투명성보다 더 나쁜 익명성은 없으며, 무작위 숫자처럼 보이는 것을 사용함으로써 현재의 시스템이 정확히 그렇게 하는 것이다.사용자명을 사용함으로써 사용자는 자신이 공유하고 있는 정보를 충분히 인지하고, 연결하기 전에 자유롭게 변경할 수 있다.팬텀텍 (대화) 04:00, 2015년 5월 7일 (UTC)[응답]

• 고지 사항을 지지하십시오.나는 항상 도움말 채널에 접속하는 편집자들이 그들의 IP가 노출될 것이라고 충분히 경고받지 못했다고 생각해 왔다.그들이 온위키 계정으로 IP를 식별하기 위해 추가적인 조치를 취해야 할 것이기 때문에, 그것은 큰 문제가 아니었지만, 나를 약간 불편하게 만들었다.현재의 시행으로 인해 이 문제는 훨씬 더 심각해졌다.이제 IRC에 입력하는 기본 닉네임으로 세션을 가져온 페이지의 수정본과 다시 연결하십시오. 대부분의 경우 IRC에서 이미 볼 수 있는 IP는 여기에 있는 계정에 직접 연결될 수 있습니다,내가 보기에, 이것이 가능할 것이라는 사용자에게 명확한 통지가 없는 경우, 이것은 기초 프라이버시 정책의 위반이다.나는 실제로 조금 더 나아가서, 접속을 통해 IP와 사용자 이름을 연결할 수 있을 것이라고 명시적으로 말하겠다.우리는 또한 그들이 그 언어가 무엇이 밝혀질 것인지에 대해 충분한 경고를 제공한다고 느끼는지, 재단 법인의 누군가에게 묻고 싶을지도 모른다.(한편으로는 IP정보를 공개하는 것에 대해 불합리하게 민감하게 반응하는 사람이 많다고 생각하지만 커뮤니티는 그들의 우려를 존중하기로 결정했기 때문에 우리는 일관성을 유지해야 한다) 몬티₈₄₅ 14:37, 2015년 4월 29일 (UTC)[응답]
• 해당 채널에 대한 고지 사항을 지원하십시오.common.js에 대본을 추가하는 데 내가 뒤쳐질 수 있을지 모르겠어.IRC 링크와 채널 사이에 중간 페이지를 추가하면 실제로 도움을 받기 위해 채널로 가는 사람이 줄어들 것이라는 점도 우리 모두 알아야 한다.균형을 맞추면 아마 괜찮겠지만(당신의 IP를 무심코 노출하는 것이 실제 피해를 줄 수 있다는 점을 고려할 때), 그럴 가능성이 높은 결과일 것이다.프로톤크 (대화) 00:13, 2015년 5월 8일 (UTC)[응답]

@Protonk:common.js 대신 스크립트를 기본 가젯으로 추가하는 것을 지원하시겠습니까?팬텀텍 (대화) 01:06, 2015년 5월 8일 (UTC)[응답]

글쎄, 나도 몰라.첫째, IRC에 맞추기 위해 사용자 이름을 망칠 경우(그리고 중복 제거?)왜 그냥 무작위 이름을 지정하지 않았을까?프로톤크 (대화) 01:15, 2015년 5월 8일 (UTC)[응답]

• 왜 그 닉은 조타수가 도움을 원하는 페이지와 직접 연결되지 않았을까? 그래서 그들은 언어나 기술적 장벽 때문에 아무런 도움 없이 보내질 필요가 없다.(그것이 현재 btw, 상태 표시기 및 revid 번호로 도우미가 실제로 헬피에 도움을 줄 수 있다.—{{U Technical 13}} (e • t • c)01:49, 2015년 5월 8일 (UTC)[응답하라]

@Protonk:사용자 이름을 사용하면 도우미가 헬프(Helpee)를 돕는 데 필요한 정보를 쉽게 찾을 수 있으며, IP에 임의의 이름(일부 이름은 불쾌하다고 간주될 수 있으므로 색상)이 할당된다.@기술 13: 사용자 이름은 무작위 숫자처럼 보이지 않기 때문에 헬프들은 닉이 어떤 정보를 담고 있는지 알고, 레비드는 헬프들과 헬프들이 모두 가지고 있는 헬프들을 구분하기 쉽게 만드는 문제를 해결하지 못한다.팬텀텍 (토크) 02:04, 2015년 5월 8일 (UTC)[응답]

그럴듯하게 들리네.코드를 한 번 더 살펴보겠다.프로톤크 (대화) 02:25, 2015년 5월 8일 (UTC)[응답]

난 지금 코드를 가지고 있어나는 여전히 우리가 애초에 사용자 이름을 망치고 싶어한다는 것에 대해 회의적이다. 특히 긴 사용자 이름이 잘리고, "_"의 추가가 많은 경우에 임의 사용자 이름보다 더 나쁠 수 있다.프로톤크 (대화) 2015년 5월 14일 (UTC) 16:55 [응답]

나는 사용자 이름을 편집하는 것이 전혀 이상적이지 않고 무작위로 편집하는 것이 더 나을 수 있다는 것에 동의하지만 나는 그것이 그렇게 흔할 것이라고 생각하지 않는다.사용자 이름이 변경되는 경우가 대부분인 것 같지만, 나는 대개 라이브 도움말 채널에 있기 때문에 내가 틀렸다면 알아차리고 스크립트를 수정할 수 있어야 한다.팬텀테크 (대화) 2015년 5월 14일 (UTC) 17:57, 응답

• 반대 둘 다 특히 자바스크립트에 반대한다.말하기 싫지만 JavaScript는 보안상의 결함과 많은 문제들이 일어나길 기다리고 있다.그리고 또 다른 요점은, 사용자를 다른 페이지로 연결하는 것이 도움이 될 것이라고 생각하지 않는다.내가 처음 만났을 때, 내가 원했던 것은 실제 사람과 대화하는 것이 아니라 도움말 페이지와 위키피디아에서 원을 그리며 보내지는 것이었다.또한 지적하고 싶은 것은 IP에서 편집하는 사람은 누구나 자신의 IP가 이리저리 던져지고 있다는 것을 알고 있다는 것이다(더 많은 거부권을 거기에 추가해야 할까) 그리고 일반적으로 위키피디아는 "개인적이거나 일대일"이 아니라는 것이다.내 생각에는 IRC 채팅 페이지에 이미 했던 것처럼 작은 것을 추가하는 것이 더 타당할 것 같아. "안녕, WP헬프44410...다른 쓰레기들...회신은 몇 분 정도 걸릴 수 있다. 특정 페이지에 대해 문의하는 경우 링크 및/또는 Wiki 사용자 이름을 제공하여 당사의 자원봉사자가 쉽게 도움을 받을 수 있도록 하십시오. " 사용자를 도움으로부터 멀리 떨어뜨리고, 더 쓸모없는 FAQ 및 지침 페이지로 이동시키는 대신, 그 위에 무언가를 그냥 버리는 것이 더 타당하다.EoRdE6^{(Come Talk to Me!)} 01:27, 2015년 5월 14일 (UTC)[응답]

위키피디아는 이미 자바스크립트를 사용하고 있는데, 이 스크립트는 어떤 추가적인 보안 결함과 이슈를 도입할 것인가?이 고지 사항은 사용자 이름을 IP가 아닌 IP에 연결하는 것에 대해 경고한다.IRC 채널 내에 고지서를 추가하는 것은 누군가가 서명할 때까지 계약을 읽지 못하게 하는 것과 같다. 그 시점에서는 너무 늦었다.팬텀텍 (대화) 06:18, 2015년 5월 14일 (UTC)[응답]

"IP에서 편집하는 사람은 자신의 IP가 버려지는 것을 알고 있을 것이다"라는 문제는 IRC 채널에 가입하면 망토를 가지고 있지 않은 한 IP가 보일 수 있다는 것(헬프 99.9%는 그렇지 않은 경우)에 로그인하든 말든 상관 없다는 것이다.샘 월튼 (대화) 08:59, 2015년 5월 14일 (UTC)[응답]

• 자바스크립트에 반대하는 이유는 사람들이 작은 인쇄물(또는 큰 인쇄물)을 읽지 않고 자신도 모르게 자신의 IP를 의미 없이 자신의 계정과 연결시키기 때문이다.몬티별로 모든 것이 주목받지는 않겠지만 사용자에게 가능성을 경고하는 고지서를 지지한다.알락지 (대화) 01:49, 2015년 5월 14일 (UTC)[응답]

전에도 말했지만, 지금은 많은 것이 있기 때문에, 사람들은 이미 알지 못하는 사이에 어떤 드래프트나 도움이 필요한지 말할 때, 사용자 이름을 기본값으로 사용하여 사용자 이름을 사용하는 경우(또는 가입하는 것만으로 현재 리비드 시스템이 제자리에 있는 동안), 도우미/헬프에게 덜 혼란스러운 IP를 자신의 계정에 연결한다.피와 도움을 주는 사람들이 더 빨리 구조자들이 더 빨리 구조하는 것을 돕는다.팬텀텍 (대화) 06:18, 2015년 5월 14일 (UTC)[응답]

• 기록되지 않은 채, 공식적인 근접을 기다리고 있다.팬텀테크 (talk) 07:42, 2015년 5월 22일 (UTC) 아카이브 봇 팬텀테크 (talk) 05:08, 2015년 5월 28일 (UTC)[응답]

영어 위키백과에서 선택적 다요소 인증이 가능해야 하는가?

지원(옵션 다요소 인증)

1. 제안자로서 지원하십시오.옵션인 다중 요소 인증을 허용하지 않는 이유를 알지 못함팬텀텍 (대화) 2015년 5월 21일 (UTC) 23시 30분[응답]
2. 지지하다.I use 2FA for almost all my services (email, Dropbox, finance, heck even Wikimedia Labs) myself, so I personally support this and would use it fully, but I would also ask those who don't to still support, as there will be no disruption or difference to those who do not use MFA/2FA. --L235 (t / c / ping in reply) 02:14, 22 May 2015 (UTC)[reply]
3. 지지하다.당연하지. -- ♥의 왕 ♠ 04:36, 2015년 5월 22일 (UTC)[응답]
4. 지지하다.다요소 인증은 매우 좋은 생각일 것이다.누군가 내 Wikimedia 이메일 주소와 함께 "비밀번호 재설정" 기능을 사용한 후 외부 사이트에서 알림 이메일을 받았을 때 누군가가 내 관리 계정에 침입하려는 증거를 본 적이 있다.그리고 잠기기 전에 손상된 관리자 계정으로 많은 피해를 입힐 수 있으며, 그 중 일부는 쉽게 복구할 수 없다.다중 요인은 패스워드 스누핑 공격 등이 효과적이기 훨씬 어렵게 만들 것이고, 특히 선택적일 경우 단점이 보이지 않는다.— Mr. Stradivarius 06:26, 2015년 5월 22일 (UTC)[응답]
5. 지원 - 내게는 매우 좋은 생각인 것 같은데, 관리자에게는 강력하게 추천되어야 한다.AWB나 PyWikiBot과 같은 툴 개발자들로부터 듣고 싶어할 것이다. Bots는 추가적인 보호의 혜택을 받을 수 있는 또 다른 유형의 계정이지만, 그 툴은 어떤 다요소라도 사용할 수 있도록 업데이트되어야 할 것이다.Jamesmcmahon0 (대화) 10:28, 2015년 5월 22일 (UTC)[응답]
6. 지지는 완전히 합리적인 선택인 것 같다.샘 월튼 (대화) 11시 10분, 2015년 5월 22일 (UTC)[응답]
7. 지지하다.내가 사용하는 대부분의 다른 웹사이트들은 이것을 허용하는데, 왜 위키피디아는 안 되는가?아퍼슨 (토크!) 2015년 5월 22일 18시 31분 (UTC)[응답]
8. 선택 사항으로 지원하십시오.Andy Mabbett (Pigsonthewing); 앤디와 대화: 앤디의 편집 2015년 5월 22일 (UTC)[응답]
9. 선택사항으로 지원. --월보(토크) 23:18, 2015년 5월 22일 (UTC)[응답]
10. 옵션으로서의 지원.만약 사람들이 그것을 훌륭하게 사용하고 싶다면, 그렇지 않다면 그들은 하지 않는다.상각(T)(C) 10:07, 2015년 5월 23일(UTC)[응답]
11. 오래전에 늦었네.고급 권한을 가진 편집자에게 필수 - 2015년 5월 24일 (UTC)[응답]
12. 지원 - 추가 보안은 반가운 추가가 될 것이다.팬텀 하나당 단점이 보이지 않는다.개인 정보 보호에 대한 우려를 반박하는 테크사의 주장은 다음과 같다.- MrX 15:28, 2015년 5월 24일 (UTC)[응답]
13. 팬텀에 따라 개인 식별 가능 정보가 필요하지 않는 한 지원아래 기술자의 설명. — SMc캔들리쉬 lish ¢ ≽^ʌ _ᴥ08 08 08 08 08^ʌ 08 08 08 08 08:25 (UTC)[응답]
14. 지원: 자동 확인, 관리자, 관료, 스튜어드 또는 (최악의 악몽) 짐보 웨일스의 계정에 대한 무단 액세스는 재앙이 될 수 있다.다요소 인증은 보안을 대폭 강화한다. 즉, 아마추어 해커의 99%에 미치지 못하는 계정 분리를 자동으로 발생시키고 나머지 1%에 대한 작업량을 증가시키는 MITM 공격이나 2FA 시스템에 대한 세심한 검사를 수행해야 한다.불편 문제는 공용 컴퓨터의 대체 계정을 갖는 것으로 해결할 수 있다.에스콰이언스 02:45, 2015년 5월 26일 (UTC)[응답]
15. 조건부 지원:나는 추가적인 인증(특히 특권 계정의 경우)이라는 발상이 마음에 들지만, 특히 시스템이 정보를 검색할 수 있도록 저장해야 하는 경우(전화 번호와 같이) 식별 가능한 개인 정보를 제공해야 하는 시스템을 지원할 수 없다.d, 소금에 절인 암호 포함).{{Nihiltres talk edits}}}07:24, 2015년 5월 26일 (UTC)[응답]
16. 지원하되 엄밀히 말하면 선택 사항일 뿐이다.숨막힘 (대화) 14:44, 2015년 5월 26일 (UTC)[응답]
17. 지원 이것은 특히 추가 권한이 있는 사용자에게 매우 좋은 일일 것이다. Mike V • Talk 22:27, 2015년 5월 26일 (UTC)[응답]
18. 옵션 기능으로 지원.이건 마치 무뇌자 같아. --아헤흐트 (TOKPAGE
    ) 14:13, 2015년 5월 27일 (UTC)[응답하라]
19. 조건부 지원 나는 2단계가 까다로운 부분이라고 생각한다.단순히 개표가 아니라 신중히 생각해 볼 필요가 있다.--농업 (대화) 00:25, 2015년 5월 28일 (UTC)[응답]

    나도 동의해, 2단계에서 내린 결정은 보안 기능을 단지 귀찮은 것으로 만들 수 있어.팬텀텍 (대화) 01:20, 2015년 5월 28일 (UTC)[응답]

20. 이 기능을 옵트인 기능으로 추가하지 않을 이유가 전혀 없다.잭mcbarn (대화) 01:32, 2015년 5월 28일 (UTC)[응답]
21. 이것은 증권가의 아주 좋은 층이 될 수 있다.일부 편집자들이 위에서 설명했듯이, 손상된 계정은 사이트 운영에 치명적인 영향을 미칠 수 있다.2600:1003:B12D:D329:9442:C04B:E459:ED40 (대화) 04:09, 2015년 5월 29일 (UTC)[응답]
22. 우리 중 몇몇은 더 잘 남겨진 사물에 접근할 수 있다 --Guerillero Parlez Moi 05:26, 2015년 5월 29일 (UTC)[응답하라]
23. 그리고 이것은 (그들의 이메일 계정과 마찬가지로) 모든 기능 제공자/임의 제공자에 의해 한 번에 구현되어야 한다.쿠르셀 (대화) 05:38, 2015년 5월 29일 (UTC)[응답]
24. 네이티브포머 06:12, 2015년 5월 29일 (UTC)[응답]
25. 오래전에 늦었네.T. 캐넌스 (대화) 2015년 5월 29일 07:00 (UTC)[응답]
26. 업무 담당자와 중재자에게 필수적인 지원.더그 웰러 (대화) 09:45, 2015년 5월 29일 (UTC)[응답]
27. 란키베일 09:47, 2015년 5월 29일 (UTC)[답답하다]
28. 선택 사항으로서 지원 2015년 5월 29일(UTC) 10:00, Lor를^Talk 적극 추천[응답]
29. 선택 사항으로 지원하십시오.이것의 비용/이행에 대해서는 전혀 알 수 없음에도 불구하고, 나는 과거에 (스마트폰 앱이 아닌 동글을 사용했음에도 불구하고) 계정 로그인에 이런 종류의 것을 사용해 왔다.로그인할 때 이런 일에는 문제가 없으며, 추가 보안 계층을 환영한다. --kelapstick^(bainuu) 11:00, 2015년 5월 29일 (UTC)[응답]
30. 지원 - 나는 몇 가지 서비스에 2FA를 사용하고 있으며, 위키피디아가 이것에 대해 훨씬 뒤처져 있다고 느낀다.특히 고급 권한을 가진 사람들에게 이것은 매우 중요한 추가 보안 계층이다.—DoRD (대화) 11:53, 2015년 5월 29일 (UTC)[응답]
31. 지지 - 말 그대로 이 제안에 반대할 이유가 없다.— foxj 13:07, 2015년 5월 29일 (UTC)[응답]
32. 선택 사항으로 지원하십시오./ 톰.레딩 (토크 ⋅contribs ⋅dgaf) 13:12, 2015년 5월 29일 (UTC)[응답]
33. RG루스터당 지원.아이언홀드 (대화) 2015년 5월 29일 15시 40분 (UTC)[응답]
34. 지지는 권리 소유자를 위한 옵션으로 매우 유용할 것이다.나콘 15:48, 2015년 5월 29일 (UTC)[응답]
35. 원칙을 지지하되...Wikimedia CentralAuth에 로그인하려면 선택적 2단계 인증을 활성화해야 한다고 생각한다.아래에 간략히 설명했듯이, en.wp와 같은 하나의 지역 프로젝트에서만 실행될 수 있는 방법은 없다고 생각한다.선택적으로 2단계 인증을 해야 한다는 원칙은 지지하지만 프로젝트별 수준에서 실행될 수 있다고는 생각하지 않는다.가장 좋은 방법은 아마도 메타위키 및/또는 mediawiki.org에 대한 토론일 것이다.만약 우리가 재단에 수많은 프로젝트들이 CentralAuth 글로벌 로그인 수준에서 2FA를 갖기를 열망한다는 것을 보여줄 수 있다면, 그것은 그들이 그것을 가능하게 하기 위한 작업을 할 동기를 부여할 수 있을 것이다.그것을 하는 것에는 몇 가지 문제가 있다(예를 들어, 국제화를 지원하는 우수하고 안전한 FLOS TOTP 구현이 있는지 확인하는 것).—톰 모리스 (토크) 2015년 5월 29일 (UTC) 16:05[응답]
36. 임시변통.제1야당 주장(개인정보의 불필요한 수집, 비기술적 성향 편집자의 불필요한 복잡성)은 2FA가 선택사항이라는 이유로 대부분 부정된다고 생각한다.만약 그것이 옵션으로 유지된다면, 나는 이것에 아무런 문제가 없다고 본다. (그리고 위키피디아는 당신이 그것을 가능하게 할 때까지 당신을 무자비하게 도청하는 구글 루트로 가지 않는다.)보안의 추가 계층은 높은 권한을 가진 사용자에게도 환영받을 것이다.–GlottalFricative (대화) 20:09, 2015년 5월 29일 (UTC)[응답]
37. 지원 - 모든 개인 정보 보호에 대한 우려는 선택 사항이라는 사실에 의해 완화된다(그리고 나는 이것이 선택 사항이라고 생각한다.이 기능을 활성화할 때 WMF/서버/ 등을 제공하는 정보에 스필이 적용되었다면,스티븐 장 07:38, 2015년 5월 30일 (UTC)[응답]
38. 선택적 구현을 지원하되, 비공개 데이터에 대한 접근 권한을 가진 개인에 대한 사용을 의무화한다.어떤 기술 회사나 금융 회사에서도 민감한 정보에 접근할 수 있는 직원에 대한 강력한 다중 요소 인증의 결여는 경계선 과실일 것이다.우리가 여기 자원 봉사자들이지만, 많은 경우에 보호되는 데이터들은 똑같이 민감하다.LFARAone 06:11, 2015년 5월 31일 (UTC)[응답]

반대(선택적 다요소 인증)

1. 반대: 이것은 전자 메일 주소, 전화 번호 등과 같은 잠재적으로 많은 양의 개인 정보를 수집하고 보존해야 할 것으로 보인다.이것은 만약 해킹당하거나 악용된다면 심각한 사생활 문제를 야기할 것이다.나는 사람들이 이 정보를 안전하게 지키기 위해 노력할 것이라고 확신하지만, 그것이 누설될 위험을 피하는 가장 좋은 방법은 애초에 그것을 갖지 않는 것이다.나이젤 이스 (토크) 2015년 5월 22일 (UTC) 16:08 [응답]

   다요소 인증의 일부 유형은 개인정보가 필요하지만, 시간 기반 일회성 비밀번호 알고리즘을 사용하면 개인정보를 저장하거나 공유할 필요가 없다.서버(Wikipedia)는 코드 생성에 필요한 정보를 클라이언트에게 제공하는데, 이상적으로는 정보가 한 번만 공유되고 안전하게 공유된다는 것이다.그 시점부터 클라이언트와 서버 모두 정보를 보관하고 현재 시간과 결합하여 현재 코드를 확인해야 한다.그래서 요약하자면, 유일하게 공유되는 정보는 위키피디아에서 클라이언트로, 그리고 개인적이지 않으며, 그 후 클라이언트는 코드를 생성하기 위해 현재 시간 외에는 아무것도 요구하지 않으며, 그 시간은 서버가 전송한 정보와 현재 시간으로 체크한다.팬텀텍 (대화) 2015년 5월 22일 (UTC) 18:55 [응답]

   편집자들은 전화기를 가지고 있어야 하고 로그온할 때마다 충전해야 하거나 위키피디아를 편집하기 위해 사용하는 컴퓨터에 특정 소프트웨어(즉, 브라우저 확장자)를 설치해야 할 것으로 보인다.이것은 많은 사람들의 로그온 능력을 제한할 것이다. 즉, 사용자가 소프트웨어를 설치할 수 없는 컴퓨터(예: 직장, 도서관, 학교 등)에서는 편집이 안 된다.매일 이런 루틴을 겪는 것은 극단적인 것으로 보이며, OTT는 내가 본 다른 다중 요소 인증(일반적으로 계정을 설정하거나 암호를 변경하는 것)의 사용과 비교된다.또한, 나는 미끄러운 비탈길 문제에 대해 우려한다. 여기서 제안되고 있는 것은 선택적인 제안이지만, HTTPS의 사용과 같이, 그것은 확장되고 의무화 될 것이다.나이젤 이스 (토크) 2015년 5월 25일 (UTC) 12시 15분[응답]

   기능 사용을 선택한 편집자들은 위키피디아에 로그인할 때마다 소프트웨어와 함께 설치된 전화기나 컴퓨터를 가지고 있어야 하는 것이 사실이다.이는 일부 사용자, 특히 로그인하는 동안 장치에 액세스할 수 없는 사용자, 그리고 편집자가 장치를 활성화하기로 결정할 때 고려해야 할 사항으로, 만약 그들이 편집을 활성화한다면, 일부 사용자들을 제한할 수 있다.이러한 종류의 돌연변이 인증은 페이스북과 구글을 포함한 많은 사이트들이 제공하는 표준 타입이며, 나는 그것을 극단적이라고 생각하지 않을 것이다.나는 이것이 곧 의무화될 가능성은 없다고 생각한다.나는 금융 사이트를 포함한 단일 사이트가 다중 행위자 인증을 필요로 한다는 것을 알지 못한다. 위키피디아에 그것을 요구하는 것은 이치에 맞지 않을 것이고 WMF가 그것을 요구조건으로 만들려고 할 것이라고 생각한다.팬텀텍 (대화) 2015년 5월 25일 (UTC) 15:41, 25[응답]

2. 반대 – 나는 이것이 무엇인지 모르지만, 나는 그것이 단지 "기술적인" 쓰레기의 일종이라고 생각한다.기존 시스템 위에 추가된 어떤 합병증도 용납할 수 없다.우리는 기술에 뿌리를 둔 사람들에게 고개를 숙일 필요가 없다.가장 기본적이고 간단한 프로그램은 위키피디아를 운영하는 데 사용되어야 한다.RG루스터 — ▷인터뷰 11:48, 2015년 5월 24일 (UTC)[응답]

   RGloucester, 이것은 우리가 선택적 특징을 구현하는 것을 제안한다.선택하는 사람들은 위키피디아에 로그인하기 위해 전화기(또는 다른 장치)를 통해 메시지(아마도 문자 메시지)를 보내거나 받아야 할 것이다.이 제안은 필수사항이 아닌 선택사항이기 때문에, 내가 알고 있는 바와 같이, 이 제안을 선택하지 않는 사용자에게는 아무런 영향도 미치지 않을 것이다.DES^(talk) 16:21, 2015년 5월 24일 (UTC)[응답하라]

   DES는 선택권이 없는 사용자가 선택권이 있는 설정을 보는 것 외에 영향을 받지 않는 것이 옳다.내가 알고 있는 확장자는 문자 메시지를 사용하지 않고, 설정 중에 서버와 사용자 간에 공유되는 비밀키를 사용하며, 사용자의 장치는 그 키와 현재 시간을 사용하여 로그인하는 동안 입력되어야 하는 최소 30초 동안 기본적으로 유효한 코드를 생성하는데, 이 코드는 일반 암호와 함께.팬텀텍 (토크) 2015년 5월 24일 (UTC) 19:19[응답]

   아 내 실수.나는 문자 메시지를 사용하는 비위키 2단계 인증 프로토콜로 작업한 적이 있다.나 또한 물리적인 키 시스템을 가지고 일을 했다 (몇 년 전만 해도) 키 장치가 1분에 한 번, 아니 어쩌면 30초였던 것 같은 변화된 코드를 표시했다.이것은 비슷하게 들리지만 전용 하드웨어 대신 스마트폰이나 다른 기기를 사용한다.DES 20:01, 2015년 5월 24일 (UTC)[응답하라]

https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/OccultZone

사용자:AmritasyaPutra는 OccultZone의 삭푸펫으로 밝혀졌다.사용자:AmritasyaPutra의 계정은 2008년 8월 10일에 열렸고 그는 (변경 검토자, 롤백자)가 되었다.몇 달 전에 나는 한 오래된 사용자를 보았다.어둠은 마크 너틀리(Darknights rights 2)의 양말 조각처럼 막혔다.이제 어둠은 차단되지 않았다.

SPI 건은 2개의 계정에서 의심스러운 행위가 있거나 새로운 계정 3/4개가 오래된 차단된 계정을 지원할 때 제기된다.그러면 SPI 점원이 충분한 증거를 제공받았는지 CU 검사를 요청한다. 증거가 없는 SPI 사건은 인신공격으로 간주된다.

나는 다음과 같이 제안한다.

"사용자가 롤백 권한, 변경 검토 권한으로 추가 권한을 얻을 경우 CU 검사를 의무화해야 한다.Auotopatroller, 템플릿 편집기 권한, 대량 메시징 권한 및 관리자 권한.그리고 사용자들은 그것에 대해 나쁘게 생각해서는 안 된다.공항에서는 테러리스트가 아니더라도 모두 금속탐지기 테스트를 받아야 한다.그러므로 편집자들은 여기 WP에서 언급된 추가적인 권리를 얻기 위해 의무적인 CU 검사에 직면할 준비가 되어 있어야 한다.UAL."

이와는 달리, 대부분의 SPI 사례에서 오직 한 명의 점원만이 모든 사례에 대해 일하고 있다.다른 점원들도 있을 것이다.대부분의 페이지에서 나는 반자게니의 코멘트를 본다.다른 SPI 사무원들은 어떻게 되었는가? --우주황제 18:33, 2015년 6월 3일 (UTC)[응답]

타이핑을 하는 사람들은 반대한다: 너는 이 영리한 양말장사를 막을 해결책을 줄 수 있다.CU는 낚시용이 아니다.그러나 사용자처럼 양말이 강력한 편집자가 되는 것을 막는 방법:AmritasyaPutra와 어둠이 빛나니?사람들은 체크 유저들에게 너무 많은 부담이 될 것이라고 생각한다.대부분의 Check Users는 SPI에서 작동하지 않는다.SPI에서 일하는 Check Users, 나는 그들의 부담을 늘리고 싶지 않다.그러나 Check User 권한을 가진 사람들은 여전히 SPI에서 CU 체크를 수행하지 않는다. 나는 그들이 이것을 하기를 원한다.-- Cosmic Emperial (UTC) 01:40, 2015년 6월 4일 (UTC)[응답]

• 지원 개념: 비록 CU가 낚시를 위한 것은 아니지만, 나는 이 개념(이 특정 목적을 위해 CU의 범위를 수정하고 CU에게 너무 많은 부담을 주지 않는다면)이 그러한 사용자들이 그들의 오래된 파괴적인 계정의 꼭두각시 인형임을 밝힌 문제의 "잘못된 측면"에 있었다는 것을 정말로 지지한다.나는 사용자 CU'd를 보호하고 그러한 개념을 시행하기 위해 모든 허점을 커버할 수 있도록 하는 동의 가능한 버전을 지지하고 싶다.CU에게 단일 롤백 권한으로는 이치에 맞지 않지만, sysop에 대해서는 그렇지 않을 수도 있고, 사용자가 숙련된 편집자가 신뢰할 수 있는 도구를 제공하는 3-4의 권한을 얻었을 때, --lTopGunl (talk) 18:45, 2015년 6월 3일 (UTC)[응답]
• CU에 따른 반대는 낚시용이 아니다.행동 집행의 사회적 방법에서 기술적 방법으로 이동하는 것이 군비 경쟁의 길이다.스튜어트예이츠 (대화) 2015년 6월 3일 20:30 (UTC)[응답]
• 반대(갈등 편집)A:CU와 B의 과다한 사용: 일부 사용자는 공개 없이 여러 계정을 사용하지만 정책 내에서 rfp에서는 공개하지 않는다.

EoRdE6^{(Come Talk to Me!)} 20:34, 2015년 6월 3일 (UTC)[응답]

네 말에 동의해.그런 경우, 테스트를 수행할 체크 유저는 합법적인 양말들에 대해 전자우편을 보내야 한다.--우주황제 01:50, 2015년 6월 4일 (UTC)[응답]

• 대부분의 권리에 접근할 수 있는 양말뭉치로 인한 지역사회의 해악은 미미하며, 따라서 나는 자동 체크 사용자 낚시는 정당하지 않을 것이라고 생각한다.admin, template editor, edit filter manager, Arbcom 후보의 경우 수표를 지원하는 것을 볼 수 있었다.그러나 만약 모든 사람들이 그들이 입후보의 결과로 체크 이용될 것이라는 것을 안다면, 어떤 심각한 양말장수가 그들이 기술적인 증거를 찾기 위해 창밖으로 나올 때까지 기다렸는지 확인하는 것은 사소한 일이 될 것이다.그래서 허락을 받으려고 허름한 양말을 잘 잡는다.대체로 그럴 만한 가치가 있는지 확실하지 않다.만약 당신이 정말로 그것을 멈추기를 원한다면, 당신은 당신이 염려하는 권리의 기존 소유자에 대한 어떤 종류의 무작위적인 점검이 필요할 것이다.몬티₈₄₅ 22:42, 2015년 6월 3일 (UTC)[응답]
• 반대야. 공항에서 모든 사람이 겪는 금속탐지기?테러리스트를 막는데 거의 도움이 되지 않는 보안 극장이고, 어쨌든 전혀 무관하다.아니, CU는 낚시용이 아니야.추가 권리를 부여받은 사람들은 이미 그러한 권리를 얻기 전과 후에 편집에 대한 강화된 조사를 받고 있다.얼마나 그렇게 많은 것이 권리에 따라 크게 달라진다.예를 들어 관리자가 쉽게 관리자 역할을 수행할 수 있다고 생각되면 RfA에서 관리자 역할을 수행하십시오.하지만 CU는 그 방법이 아니다.--존블랙번^words_deeds 22:52, 2015년 6월 3일 (UTC)[응답하라]
• 당신의 마지막 질문에 먼저 대답해 드리자면, 가장 활동적인 SPI 사무원 두 명이 3월에 CheckUsers가 되었기 때문에, 그들은 사건의 다른 측면에 더 집중하고 있다.그 제안에 대해서는 반대하지 않을 수 없다.나는 대부분의 사용자 권리에 대해 그러한 점검이 필요하거나 심지어 정책에 의해서도 허용된다고 생각하지 않는다.또한 앞의 반대에도 따라 특히 몬티845와 존 블랙번 등이 반대한다.—DoRD (대화) 02:05, 2015년 6월 4일 (UTC) 편집:또한 오컬트존 사건은 복잡한 수사였다.나는 그 계좌들 중 어느 하나라도 피상적인 "권리 확인"에 걸려들었을 것이라는 의심이 든다.—DoRD (대화) 02:13, 2015년 6월 4일 (UTC)[응답]
• 반대한다. CheckUser는 사용자가 여러 계정을 남용하고 있다는 충분한 증거가 없는 한 사용해서는 안 된다.더욱이 CheckUser는 사용자의 위치를 공개할 수 있기 때문에, 남용(새로운 권리를 갖는다는 것은 명백히 남용되지 않는다는 것)의 사전 증거 없이 그것을 사용하는 것은 근거 없는 사생활 침해가 될 것이다. --Biblioworm 02:08, 2015년 6월 4일 (UTC)[응답]
• 일어나지 않을 것이다.이는 개인 정보 보호 정책에 대한 전면적인 위반으로, "자율적으로 확인된 이상 허가를 신청하는 것"은 확인에 필요한 기준에 근접하지 않는다.위험자 (대화) 02:44, 2015년 6월 4일 (UTC)[응답]

@Risker:개인정보 보호정책에는 사용자의 허락을 받아 정보를 공유할 수 있다는 캐치얼 조항이 있다.이 제안이 아무데도 진행되지 않는 것은 분명해 보이지만, 사용자 권리 신청 당시 확인자 수행에 대한 동의가 명시적으로 주어지는 과정이라면 개인정보 보호정책상 허용될 것이라고 생각한다.메타체크유저 정책에도 그것을 금지하는 것은 없는 것 같다.우리의 지역 체커 사용자 정책은 기준 메타 정책보다 훨씬 엄격하다. 내 생각에 그것은 아마도 좋은 것이라고 생각하지만, 그것은 우리가 지역사회가 그것을 원한다면 융통성을 가지고 있다는 것을 의미한다.몬티₈₄₅ 04:56, 2015년 6월 4일 (UTC)[응답]

미안해, 아니야.그렇지 않으면 정당하지 않은 수표에 나타날 수 있는 다른 모든 사용자의 사생활은 말할 것도 없고, 사용자들이 사생활을 포기하도록 요구하는 것은 불가능하며, 결국 그들은 다소 무해하고 무해한 도구에 접근할 수 있다.WMF 영역 전체의 어느 곳에서도 사용자가 단지 그 허가에 대한 정당성이 없다고 해서 스스로 체크유저에게 제출하도록 요구하는 다른 사용자 허가는 없다.(그렇지 않아도 체크유저와 오버래이터는 개인정보 보호정책에서 요구하는 대로 개인정보를 공급할 필요가 있다.그것은 CU를 운영하는 것과 같지 않다 - 또한 다른 사람들의 사생활을 침해한다.)리스크 담당자 (대화) 05:08, 2015년 6월 4일 (UTC)[응답]

• 반대 - 위험인당, 이것은 꽤 심각한 개인 정보 보호 정책 위반이다.또한 다른 사람들의 사생활을 많이 침해했다.--조름 (토크) 02:47, 2015년 6월 4일 (UTC)[응답]
• 반대하라. 나는 어떤 것이 지각하거나 방해받지 않는 것을 막을 필요가 없다고 본다.오행의 직접적인 의혹이 없다면 예외적인 수사 수단을 동원해서라도 찾아내서는 안 된다.숨겨진 대체 계정들이 뿌리 뽑아야 할 골칫거리를 제공한다는 OP의 전제는 내가 지지하는 입장이 아니다; 적어도 우리가 정당한 절차와 프라이버시의 핵심 가치를 희생해야 한다는 것은 아니다. --Jayron32 02:52, 2015년 6월 4일 (UTC)[응답]
• 안 돼, 안 돼.첫째, 우리는 낚시 여행을 가지 않는다.두 번째로, 어떤 선을 긋는가? - 메일러 디아블로 06:17, 2015년 6월 4일 (UTC)[응답하라]
• 개인 정보 보호 정책의 위반으로 인해 반대하며 실행되지 않을 것이다.리퍼 이터널(토크) 02:57, 2015년 6월 4일 (UTC)[응답]
• 정책에 반한다고 지적한 다른 사람에 따라 반대한다.--Bb23 (대화) 04:20, 2015년 6월 4일 (UTC)[응답]

일부 관리자는 OccultZone 사건에 대한 DoRD의 진술 이후 이 논의를 종결해야 한다.우주황제 04:51, 2015년 6월 4일 (UTC)[응답]

• 댓글을 달다.나는 체크 유저가 개인 정보 보호 정책을 위반한다는 주장에 어리둥절하다. 만약 그렇다면, 우리는 왜 그것을 가지고 있는가?그것을 만들기 위한 기존의 문턱은 표면적으로는 공동체 린치 폭도인데, 그가 궁금해 하는지 아닌지를 결정하는 행정관이다.그 과정은 좀 더 투명성을 필요로 한다 - 사람들이 3년 이상 된 계좌에 체크 이용되는 것에 대한 이야기들이 있다.나는 지금 진정한 보호가 있다고 생각하지 않아, 그래서 충격을 받은 사생활 침해는 '너무 많은 것을 시험하는 것 같다.그렇긴 하지만, 나는 검토와 롤백 같은 사소한 권리들이 그렇게 중요하고, 또한 그렇게 되어서는 안 된다고 생각하지 않는다.관리자들에게 일상적으로 점검하는 것이 더 흥미로울 수 있지만, 나는 전체 기능이 제거되는 것을 보고 싶다.Wnt (토크) 12:21, 2015년 6월 4일 (UTC)[응답]

새로운 종류의 기사가 소개될 것이다.그것은 좋은 목록이 될 것이다.좋은 기사 기준과 비슷하지만 목록 형식으로 되어 있다.리스트에서 FL로 올라가는 단계가 너무 커서 기사처럼 좋은 리스트가 필요해.기준은 아래와 같다.

목록 형식(WP:List 참조)에 자신을 빌려주는 주제를 다루며, 모든 위키백과 콘텐츠(특히 명명 규칙, 중립성, 원본 연구, 검증가능성, 인용문, 신뢰할 수 있는 출처, 생활자, 비자유 콘텐츠 및 위키백과가 아닌 것)에 대한 요건을 충족하는 것 외에 좋은 목록에는 다음과 같은 속성이 있다.

1. 산문. 중요한 카피편집 문제 없이 글쓰기의 좋은 기준이 특징이지만,
2. 리드. 주제를 소개하고 범위와 포함 기준을 규정하는 리드를 가지고 있다.
3. 포괄성.
   • (a) 정의된 범위를 포괄적으로 포괄하여 모든 주요 항목을 제공하며,
   • (b) 길이 및/또는 주제에서 독립 실행형 목록에 대한 모든 요구 사항을 충족하며, 내용 요청 지침을 위반하지 않으며, 다른 기사에서 크게 중복되지 않으며, 관련 기사의 일부로 합리적으로 포함될 수 없다.
4. 구조.쉽게 탐색할 수 있으며, 도움이 되는 경우 섹션 제목 및 테이블 정렬 설비를 포함한다.
5. 스타일. 일반적으로 스타일 매뉴얼 및 추가 페이지를 준수한다.
   • (a) 시각적 호소.텍스트 레이아웃, 서식, 표 및 색상을 적절히 사용하고 최소 비율의 항목이 재연결된다.
   • (b) 미디어 파일.그것은 주제에 적절하다면 간결한 자막과 함께 위키피디아의 사용 정책을 따르는 이미지와 다른 매체를 가지고 있다.비자유 영상 및 기타 매체는 비자유 콘텐츠 포함 기준을 충족하고 그에 따라 라벨이 붙는다.
6. 안정.현재 진행 중인 편집 전쟁의 주제가 아니며, 좋은 리스트 과정에 대한 대응 외에는 그 내용이 하루하루 크게 바뀌지 않는다.

The MagikCow (talk) 17:09, 2015년 5월 3일 (UTC)[응답]

이 일은 전에 논의된 적이 있지만, 나는 어떠한 연고도 가지고 있지 않다.개인적으로, 나는 추천 목록 프로세스에 궁극적으로 중복되는 또 다른 검토 프로세스를 만드는 데 큰 가치가 있다고 생각하지 않는다."좋은" 리스트와 "기능적인" 리스트 사이에는 그 과정을 가치 있게 만들 충분한 차이가 없을 것이다.결연한 17:11, 2015년 5월 3일 (UTC)[응답]

이 제안은 FL과 어떻게 비교되는가?유사점과 차이점은 무엇인가?—{{U Technical 13}} (e • t • c)17:32, 2015년 5월 3일 (UTC)[응답하라]

이러한 기준과 WP의 기준 사이에는 큰 차이가 없다.WIAFL. 전체적으로 "featureed"라는 단어를 "good"로 바꾸는 것 외에도, 차이점은 단지 두 가지 주요 기준과 하나의 하위 기준이다.

기준 1에서 "...전문적 글쓰기 표준"은 "... 좋은 글쓰기 표준"으로 대체되며, 카피편집 문제는 없다."

기준 2에서는 "engaging"이라는 단어가 생략된다.

하위 기준 3(a)에서는 "실용적인 경우 전체 항목 집합"과 같이 "적어도"라는 단어가 생략되며, 적절한 경우 항목에 대한 유용하고 적절한 정보를 제공하는 주석을 가지고 있다.

간단히 말해서, 위의 제안은 좋은 리스트에 대해 너무 많은 기대를 하고 있다고 생각한다.특집 기사에 대한 요구 사항과 좋은 기사에 대한 요구 사항을 비교하십시오. 차이가 훨씬 크다.특히 FA와 FL 모두 '스타일 매뉴얼' 준수를 요구하지만, GA는 리드 섹션, 레이아웃, 볼 단어, 픽션, 목록 통합 등 5개 분야에서만 MoS를 충족하면 된다.GL 제안에도 MoS 준수가 전면적으로 필요한 것은 아니라고 생각한다. --Redrose64 (대화) 09:58, 2015년 5월 4일 (UTC)[응답]

위키프로젝트 군사 역사(MILHIST)는 중간 레벨의 CL, BL 및 AL을 포함하는 목록에 대한 품질 척도를 가지고 있지만 "좋은 목록" 수준은 없다는 것을 발견했다. WP:MHA#SCOLE.이에 따라, 나는 MILHIST에게 쪽지를 보냈다.더 짧은 버전은 일부 다른 토크 페이지로 전송되었다(예: --Redrose64 (토크) 10:36, 2015년 5월 4일 (UTC)[응답]

• 반대 나는 우리가 이 아이디어를 일년에 한 번 정도 재방문한다고 생각한다.Redrose64가 지적하듯이, 이 제안은 이미 FLC에 매우 가깝고, "좋은 목록"에 대한 고의적으로 약한 기준을 정의하려고 하는 것은 우리 사회에 도움이 되지 않는다.MOS를 완전히 준수하는 것은 사실 어떤 기사에도 그렇게 어려운 것은 아니지만, 목록과 함께 기술적인 관점에서 보면 사실 꽤 중요하기 때문에, 그것을 다운그레이드하는 것 역시 좋지 않은 일일 것이다.더 램블링맨 (토크) 10:21, 2015년 5월 4일 (UTC)[응답]
• 지원 예와 신뢰할 수 있는 출처를 가진 수 천 년 동안 유지되고 있는 수천 년 관련 기사들은 어느 정도 인정을 필요로 한다.OccultZone(Talk • 기여 • 로그)

  그 수천 년 관련 기사들 중 무엇이 FL 기준을 충족하지 못하게 하고 있는지 물어봐도 될까?당신은 좋은 리스트가 될 만큼 훌륭하다고 생각하는 예시를 가지고 있는가?더 람블링맨 (토크) 2015년 5월 4일 (UTC) 10:46[응답]

2012년 미국, 2014년 미국 등.FL에 실제로 요구되는 집중력과 헌신이 부족해 이 FL 이정표를 달성할 수 없다.OccultZone(Talk • 기여 • 로그) 11:00, 2015년 5월 4일(UTC)[응답]

우리가 집중력이 부족해서 제안서를 지지하는 거야?그렇다, 그 기사들은 끔찍하고 끔찍하다. 하지만 우리는 누군가 그것을 조사하는 것을 귀찮게 한다면 기본으로 사용될 수 있는 많은 "시간표" 특집 목록들을 가지고 있다.더 램블링맨 (토크) 11:18, 2015년 5월 4일 (UTC)[응답]

• 지원 나는 F(L)C와 G(L)C의 가장 큰 차이점은 절차에 있다고 생각한다.F(L)C 지명을 승인하려면 복수의 검토자가 필요하며, G(L)C 지명을 승인하려면 검토자가 한 명만 필요하다.F(L)C는 한 번에 하나의 기사/목록만 지정할 수 있지만 G(L)C는 여러 개를 동시에 지정할 수 있다.F(L)C 기사/목록의 품질은 복수의 검토자가 기여하는 다양성에 따라 증가한다.그 후, 모든 검토에는 약점과 강점이 있기 때문에, 한 사람만이 검토했던 목록은 질적으로 문제가 될 가능성이 가장 높다.그런 말을 했으니, 비록 기준이 조금 다를 수 있지만, 나는 GL급이 말이 된다고 생각한다.미스터비1966 (토크) 12:16, 2015년 5월 4일 (UTC)[응답]
• 부분적 지원 WP:MHA#SCOLE 접근법은 좋은 것 같아, 나는 많은 경우에 최고 수준의 완벽함을 달성할 수 없다는 것을 알게 되었지만, 출발 클래스 리스트를 C까지 끌어올릴 필요가 있다.만약 당신이 영국의 수밀 목록이나 더 나쁜 세계의 수밀 목록을 기록하고 있다면, 더 낮은 수준의 목표를 갖는 것이 도움이 될 것이다.새로운 편집자들은 우리가 낮은 수준의 목표를 설정한다면 아마도 이 논쟁적이지 않은 분야에서 일하는 것이 행복할 것이다. -- 클렘 러터 (대화) 13:27, 2015년 5월 4일 (UTC)[응답]
• 적어도 내게는, 이 "좋은 목록" 아이디어의 가장 일반적인 후보자들이 단지 매우 길고 따라서 그것들을 적절히 포맷하고 참조하기 위해 많은 작업이 필요한 것처럼 보이는 질문, 그것이 그 아이디어인가?더 람블링맨 (토크) 13:38, 2015년 5월 4일 (UTC)[응답]

  아니, FA 클래스가 아닌 리스트는 인정을 받는다는 것이 아니다.목록에 WP가 있는 한 최소 항목은 없다.주목할 만한 내용—TheMagikCow(대화 • 기여)가 추가한 서명되지 않은 이전 의견 2015년 5월 4일 16:14, 4

  유감스럽게도 나는 너의 요점을 전혀 이해하지 못하겠어.더 람블링맨 (토크) 2015년 5월 4일 (UTC) 19:44[응답]

• 나는 정말로 이 토론이 위키피디아에서 단편화되지 않았기를 바란다.마을 펌프(아이디어 랩)/아카이브 17#굿 리스트그렇긴 하지만, 나는 이 제안을 지지한다.—{{U Technical 13}} (e • t • c)14:03, 2015년 5월 4일 (UTC)[응답하라]
• 반대 우리는 전에 이 토론을 한 적이 있다(아마도 몇 년 전일 것이다) 그리고 내 의견은 변함이 없다.Good List 개념을 채우는 데 필요한 품질 격차가 없다.어떤 퍼팅된 "좋은 리스트"도 본질적으로 피처링 리스트가 될 것이다. --Jayron32 14:56, 2015년 5월 4일 (UTC)[응답]
• 반대 - 모든 "좋은 목록"은 여전히 완전하고 참조되어야 한다. 그렇지?GA처럼?그쯤 되면 FL로 지명하는 게 좋을 거야 기본적으로 넌 거기 있어 대부분의 리스트에는 걸려들 만큼 충분한 산문이 없어정말 많은 노력이 드는 긴 리스트에 중간 수준을 갖는다는 생각은 고맙지만, "많은 노력이 들지만 이루어지지 않는다"는 것은 스타를 무언가에 찰싹 때리는 좋은 지적은 아니다.나는 그들이 "좋다"고 생각하는 현재 목록의 지지자들로부터 몇 가지 예를 보고 싶다 -지금까지 게재된 예들은 "완성하려면 많은 작업이 필요할 것"일 뿐이지 전혀 같지 않다. --PrsN 16:13, 2015년 5월 4일 (UTC)[응답]

  바로 그거야이건 단지 더 많은 작업이 필요한 목록일 뿐이지, 그 이상은 아니다.더 람블링맨 (토크) 2015년 5월 4일 (UTC) 19:44[응답]

• 명명자로 지원하십시오.The MagikCow (토크) 2015년 5월 4일 (UTC) 19:13[응답]
• 반대하라. 나는 이 아이디어에 대해 어떠한 실익도 보지 못한다.비블브록스 (대화) 23:58, 2015년 5월 4일 (UTC)[응답]
• 반대. 퍼 비블브록스. --드웰러 (대화) 09:30, 2015년 5월 6일 (UTC)[응답]
• 반대 추천 리스트는 이미 달성하기가 매우 쉬우며 우리는 이미 불균형한 산들을 가지고 있는 것 같다.그래서 이것을 가지는 것은 단지 쉽게 인정을 받을 수 있는 낮은 품질의 막대를 만들 수 있을 것이다.대신 그냥 FL로 해.Graeme Bartlett (대화) 08:32, 2015년 5월 8일 (UTC)[응답]
• 반대. 말도 안 되는 소리, 이것은 단순히 목록의 기준을 낮추는 것이다.FL은 성취하기 매우 쉽다.HYH.124 (대화) 08:46, 2015년 5월 8일 (UTC)[응답]
• 반대한다. 어떤 정규 리스트도 특집 리스트로 승격시키는 것은 어렵지 않다.만약 그 과정 자체가 좋은 기사 검토 과정과 같다면, 상대적으로 필요한 작업이 적고 일방적인 검토 과정이 밀리기 때문에 좋은 목록보다는 기사를 특집 목록으로 홍보하는 데 시간이 덜 걸릴 것이다.에스콰이컬레이션 02:55, 2015년 5월 9일 (UTC)[응답]
• 반대하다. 영어 위키백과는 가장 큰 위키백과지만, GL을 만들 만한 목록 기사가 충분하지 않다고 생각한다.--Sky999 (토크) 02:36, 2015년 5월 10일 (UTC)[응답]
• 지원: FL은 아니지만 GL을 만들 수 있고 인식이 필요한 목록이 여러 개 있다.또한 어떤 목록이 GL이 될 가능성이 있고 단기적인 노력을 해당 목록으로 전환시킬 수 있는지 식별하는 데 도움이 될 수 있다. --lTopGunl (대화) 16:32, 2015년 5월 16일 (UTC)[응답]
• 지지하다.나는 미스터비1966과 GA와 FL 평가 과정에 동의한다.목록 기사의 평가를 확대하는 것은 편집자에게 목록(Stub, List, FL)의 버스 평가의 구식 뒷면이 아닌 조항과 같은 방식으로 목록 기사를 개선하는 과정을 제공함으로써 백과사전의 목록 기사의 개선을 위한 올바른 방향이다.gmcbjames (대화) 01:38, 2015년 5월 18일 (UTC)[응답하라]
• 지원:이와 같은 이정표를 가지고 점진적인 기사 개선을 장려하는 것은 좋은 일이고, 이 특정한 이정표가 없는 것은 다소 눈에 띈다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ^ʌ ҅ ҅_ᴥ 12:27, 2015년 5월 24일 (UTC)[응답]
• 강한 반대.이 기준은 FL과 거의 같다. 게다가 특집 리스트는 만드는 데 그다지 많은 노력을 기울이지 않는다. 두 사람 사이의 차이점은 머리를 쪼개고 더 많은 밀린 일과 관료주의를 위해 더 많은 밀린 일을 하는 것이다.대부분의 지지자들은 나를 설득하지 않을 뿐만 아니라 GL 연습이 얼마나 무의미할 것인가를 나에게 납득시킨다.Wizardman 17:48, 2015년 5월 25일 (UTC)[응답]
• 지원 -- :D 데리 아다마 (대화) 14:08, 2015년 5월 29일 (UTC)[응답]
• 반대 기사 기사를 쓰는 데 들어가는 일의 양은 잠시 멈춰서 그것이 적절한 수준("좋다")이고 특집 수준에 도달했을 때 또 다른 수준임을 인식하는 것을 가치 있게 만든다.리스트는 그들에게 동일한 수준의 작업을 하지 않는다. 일단 리스트가 완성되고 참조되면, 그것을 특집으로 만들기 위해 더 이상 할 일이 많지 않다.맷 드레스(대화) 15:56, 2015년 6월 5일 (UTC)[응답]

전용 양식 게시판을 설치하자는 제안이 무산되었기 때문에, 위키피디아는 다음과 같이 이야기할 것을 제안한다.MoS는 스타일 Q&A를 위한 위키피디아의 공식 페이지로 설정된다.여기에는 다음과 같은 조치가 수반된다.

1) "그리고 위키백과에서 대문자화, 구두점, 조직화, 그 밖의 스타일의 사용에 관한 질문에 대해서는" "스타일 매뉴얼 페이지 개선을 논의하기 위한 토크 페이지"라는 효과에 텍스트를 추가한다.

2) 위키백과의 대화에서 스타일 질문을 하는 효과에 텍스트 삽입:MoS"라고 하지 않았다면 스타일 게시판을 가리켰을 모든 장소.

3) 다른 스타일 가이드 페이지의 토크 페이지에 "Wipedia talk:MoS (여기는 아님)" 효과에 대한 텍스트를 삽입하여 스타일 Q&A가 보다 집중화되도록 한다.

여기 사람들이 질문하는 종류의 질문이 있다: 1, 2, 3

이 제안의 목적은 포럼 쇼핑의 기회를 늘리지 않고 위키백과 스타일 이슈에 대한 도움을 더 쉽게 찾고 중앙 집중화시키는 것이다.WT: MoS는 이미 수년간 비공식적인 Q&A 이사회 역할을 해왔다.이 제안에 대한 논의는 여기서 할 수 있다.05:06, 2015년 5월 14일 (UTC)

지원: WT:Q&A용 MoS

1. 지원 1, 2, 3 MoS는 수년 동안 명확하고 낮은 수준의 Q&A를 제공해 왔다.현 시스템의 문제는 사람들이 충분히 알지 못하고, 여러 개의 대화 페이지에 걸쳐 겹친다는 것이고, 비공식적이기 때문에, 사람들은 그것을 사용함으로써 규칙을 어기고 있다고 생각할 수도 있다.공지사항 게시판이 이러한 문제를 더 깨끗하게 해결했을 수도 있지만, 기존 시스템으로 능동적으로 질문으로 사용자를 안내하는 것도 그렇게 할 것이다.다크프로그24 (대화) 05:06, 2015년 5월 14일 (UTC)[응답]
2. 지원 1, 2, 3 지원으로 이동:공식 페이지 한 장은 새로운 편집자/편집자에게 질문을 하는 것을 도울 것이다.The MagikCow (토크) 2015년 5월 16일 (UTC) 14:40, 응답하라
3. 지원 1, 2, 3 - 스타일 문제를 중앙 집중화하는 것이 좋다.반대하는 편집자들의 의견에 반대한다.로버트 맥클레논 (대화) 21:43, 2015년 5월 16일 (UTC)[응답]
4. 지원 1, 2, 3 모스타파 '합리화' 과정과 이곳의 섭정 선수들이 미친 듯이 화를 내는 것을 크게 싫어한 만큼, 보고 응답할 수 있는 확실한 장소를 물어야 할 필요가 있다.사이드 토크 페이지에 있는 나의 최근 질문은 아마도 한 사람 이상의 바보 같은 존재에게 보이지 않았을 것이다.그래서 나의 감정적 충동은 비블브록스와 많이 같지만, 나는 검토된 질문들에 대해 "어디로 갈 것인가"의 필요성을 본다.심메(토크) 05:13, 2015년 5월 17일 (UTC)[응답]
5. 지원 1, 2, 3 - 위키백과 '스타일 매뉴얼'에 대한 질의응답 공식 페이지는 새로 온 사람들에게 정말 도움이 될 것이다.새로운 사람들이 관리자 알림판에서 MoS에 대해 질문하도록 하는 것은 다음과 같은 질문을 하는 장소가 되어서는 안 된다.MoS에 대한 공식적인 질의응답은 문맥상 그 정책에 대한 질문의 장이 될 것이다.쿠키몬스터755 (대화) 23:03, 2015년 5월 22일 (UTC)[응답]

   아무도 그러한 질문에 대해 관리자 알림판을 제안하지 않았다.합리적인 대안은 헬프 데스크다.지도방 (대화) 2015년 5월 23일 (UTC) 10시 58분 [응답]

6. 지지하다.반대되는 정도를 감안하면 오히려 토큰 지원이다.나는 솔직히 여기서 문제를 보지 않는다.문제가 있는 행동이나 사용자가 있다면 ANI가 있다.또 MOS 페이지는 이미 재량권 제재를 받고 있어 문제가 있는 사용자들은 빨리 제거될 수 있다.닌자로봇피리테 (대화) 04:52, 2015년 5월 24일 (UTC)[응답]
7. 지원 1, 2, 3 - 우리는 그것이 필요하다. --Atsme^📞📧 16:41, 2015년 6월 6일 (UTC)[응답]

빠른 권한 부여 지원

#1 조치를 지지하지만 나머지 제안에 반대하는 사용자:

@Scs: (스티브 서밋)

@테빌도:

나를 이 문제에 대해 중립적인 사람으로 내려놔라.내 생각에, 사람들은 WP에서 그러한 질문을 하도록 격려되어야 한다.WT가 아닌 HD:MOS, 하지만 나는 그들이 WT에서 그들에게 질문하도록 요구하거나 막아야 한다고 생각하지 않는다.MOS. 요컨대, 나는 현상유지에 찬성한다.테빌도 (대화) 00:42, 2015년 6월 2일 (UTC)[응답]

@SMCCandlish:

@Finell:

모든 사용자는 이 목록에서 자신의 이름을 추가하거나 제거할 수 있는 권한이 있다. 다른 변경 사항이 있으면 요청하십시오.다크프로그24 (대화) 23:04, 2015년 6월 1일 (UTC)[응답]

반대: WT:Q&A를 위한 MoS

1. 모두 반대 – 이는 최근 RfC를 정면으로 거스르는 것으로, 분명한 의견 일치를 통해 이러한 스타일에 대한 지정된 장소를 갖지 않기로 했다.게다가, MoS에서 제안된 공간을 찾는 것은 이 제안을 당파적인 분위기로 만들어, MoS 편집자들이 외부 분쟁에 부당한 영향력을 행사할 수 있게 한다.이것을 용인할 수 있는 방법은 없다."기존의 시스템"에 대해 개구리씨의 수다를 사지 마라.현존하는 시스템이 없다.MoS talk 페이지는 MoS의 변화를 논의하기 위한 것일 뿐, 다른 것은 없다.RGlucester — 인터뷰 14:27, 2015년 5월 14일 (UTC)[응답]

   이전의 제안은 새로운 게시판을 만들 것인가 말 것인가에 대해 우려였다.이미 질의응답이 이뤄지고 있는 기존 페이지들에 대해서는 아무런 결정도 내리지 않았다."기존의 시스템"이라는 것은 사람들이 WT:MoS에서 스타일 질문을 하고 거기서 답변을 받는다는 것을 의미한다. [5].다크프로그24 (대화)20:09, 2015년 5월 15일 (UTC)[응답]

2. RGloucher에 의해 크게 반대한다.이는 기본적으로 스타일 공지 게시판을 만들자는 거부된 제안을 재탕한 것이다.칼리덤TC 23:26, 2015년 5월 14일 (UTC)[응답]

   반대 WP:HD TheMagikCow (talk) 14:38, 2015년 5월 16일 (UTC) 지원으로 이동:공식 페이지 한 장은 새로운 편집자/편집자에게 질문을 하는 것을 도울 것이다.The MagikCow (토크) 2015년 5월 16일 (UTC) 14:40, 응답하라

3. 반대 나는 여기서 의도를 이해한다.관리자에 대한 질문이 있는 경우 WP로 이동하십시오.A. 전기 기사에 대한 질문이 있는 경우 WP로 이동하십시오.BLPN, 소싱을 위해 WP:RSN 등.그래서 그것은 논리적으로 따라야 한다. 만약 여러분이 글쓰기 스타일에 대해 질문이 있다면, 여러분은 전문가나 "구루스"가 있는 MOS로 가게 된다.그리고 그것이 고쳐지지 않는 한, 그리고 고쳐지지 않는 한, 이것을 하려는 어떤 시도도 방해할 문제에 부딪히게 되는 것이다: MOS 단골들의 등급은 문법/구식 강박증을 많이 포함하고 있다. 그들은 모든 상황에 딱딱하고 빠른 규칙이 있다고 잘못 믿고 있다.만약 그들이 적어도 그 규칙이 무엇인지 동의한다면 이것은 무시할 수 없는 문제가 아닐 것이다. 하지만 그들은 거의 하지 않는다.그래서 이것은 순진하고 호기심 많은 사용자들을 위키피디아의 뒷방에 있는 코스로 끌어들이게 될 것이다. 스타일에 대한 간단한 질문은 최근 몇 년 동안 MOS 지역에서 일어났던 것처럼 여러 명의 사용자들이 차단되는 거대한 드라마 축제로 끝날 수 있다.나는 이런 강박적인 타입들이 실제 내용에 부당한 영향을 미치도록 내버려두느니 차라리 우리의 전반적인 스타일에서 약간의 모순을 가지고 싶다.비블브록스 (대화) 16:03, 2015년 5월 16일 (UTC)[응답]

   WT:MoS에서 사람들이 스타일 질문을 할 때 실제로 무슨 일이 일어나는지 잘못 알고 있는 것 같다. 이 링크를 클릭하거나 아카이브를 확인하십시오. 1, 2, 3. Darkfrog24 (대화) 21:26, 2015년 5월 16일 (UTC)[응답]

   실제로. 드라마 페스트는 거의 전적으로 애완동물 새 "규칙"을 삽입하거나(대개 위키백과에서) 누군가 개인적으로 좋아하지 않는 것을 삭제하기 위한 도끼 그라인딩에 한정된다.어떤 이유에서인지 WP 편집장의 아주 작은 퍼센트가 MOS의 모든 것에 개인적으로 동의하는 것은 본질적으로 불가능하다는 명백한 사실을 흡수하기를 거부한다. 왜냐하면 모든 스타일 포인트에서 최소한 하나의 오프 WP 스타일 가이드는 다른 사람들로부터 상반된 조언을 제공하므로, 우리 모두는 서로 다른 기대를 가지고 있기 때문이다.MOS는 필연적으로 절충안이며(즉, 어느 누구도 모든 면에서 완벽하게 만족하지 않는 것), 우리는 여기서 그것을 준수하기로 동의한다. 그래서 우리는 실제로 약간의 일관된 편집을 할 수 있고 우리의 독자와 다른 편집자들이 스타일 잡기에 열광하지 않도록 할 수 있다.이 드라마는 일상적인 글쓰기에서 그들이 원하는/기대하는 것과 WP 편집자들이 그 내용을 다루기 위해 합의 과정에서 타협하고 있는 것에 대한 혼동을 지나칠 수 없는 사람들로부터 나온다.MOS는 세계를 위한 스타일 가이드가 아니며, WP만을 위한 것이며, 사실상 모든 MOS 불꽃전쟁은 이것을 이해하거나 기억하지 못한 데서 나온다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ ⱷ^ʌ ҅_ᴥ ҅ 14:46, 2015년 5월 24일 (UTC)[응답]

   명확한 질문들은 간단히 대답될 수 있지만, 만약 질문자가 무심코 몇몇 애완동물 "규칙"을 건드리는 주제에 대해 질문한다면 어떻게 될까?순진한 질문 때문에 드라마 페스트에 손을 대는 것은 신식 사용자들에게 위협적일 것이다.("WT:MoS는 스타일 질문을 하는 곳이지만 전쟁에 대해서는 언급하지 말라") -- 162.238.240.55 (대화)

   @162.238.240.55: 사실 그런 일은 한 번 있었다.나는 "애완동물"이라는 용어를 경시하지는 않지만, WP는 WP:LQ는 격렬한 지지자와 격렬한 반대자를 둘 다 가지고 있다.(RfC 체인과 관련 토론은 1년에 한 번 정도 지속된다.)누군가가 그것에 대해 물었을 때 일어난 일이다: [6] 다크프록24 (대화) 02:31, 2015년 5월 30일 (UTC)[응답하라]

4. 반대 - 절대 아니다.MoS와 그것의 말도 안 되는 난해한 논쟁은 강박적인 나방을 위한 6,000와트 봉이다.그런 생물체에게 게시판으로 독이 있는 송곳니를 주는 일은 절대로 하고 싶지 않다.카라이트 (대화) 2015년 5월 16:29 (UTC)[응답]
5. 반대 나는 MOS 편집자들이 하는 일을 존중하고 감사하지만, 대부분의 편집자들은 단지 내용을 쓰고 개선하기를 원한다고 느낀다.지금까지, 나는 문법, 철자, 섹션 등과 같은 일반적인 가독성 요건은 토크 페이지 상의 토론과 사람들이 와서 복사를 함으로써 달성될 수 있다는 것을 발견했다.MOS가 분쟁에 이용되는 것을 볼 때마다 잘 되지 않았다(일반적으로 콘텐츠에 대한 집중력 부족, 위키와이어링 등).유용한 백과사전을 제작하는 것이 목표인 만큼 MOS 문제가 분쟁을 일으키고 있다면 이제는 MOS를 내려놓고 내용에 집중해야 할 때라고 생각한다.나는 어떤 MOS 게시판 형태의 단체가 MOS를 위키피디아의 목표로 보는 사람들 또는 그것을 위키와이어에게 사용하기를 원하는 사람들을 끌어들일까 두렵다(요컨대, wp:NOTHER HERE).오해하지 마, 대부분의 MOS 편집은 논란의 여지가 없고 백과사전을 아름답게 하는 것 같아. 하지만 어쨌든 그런 편집은 포럼/공지가 필요 없어.해피 다람쥐 (향상 방법을 알려달라!) 2015년 5월 16일 (UTC) 17:43[응답]
6. 모두 반대하다.헬프 데스크는 "섹션 헤더를 대문자로 활용하는 권장 방법이 무엇인가?"와 같은 질문을 하는 새로운 편집자를 다루는 데 경험이 있고, 잘한다고 믿는다.모스 토크 페이지는 인간을 다룬 경험이 없다.나는 오늘까지 그것의 존재를 전혀 몰랐다. 나는 방금 그것을 보았고, "큐란"에서 아포스트로피 사물의 정확한 형태에 대한 긴 토론을 읽었다. 그런 토론이 열려야 한다는 것은 고맙고, 그런 토론들을 개최하는 편집자들의 장학금에 감탄하는 한편, 그런 토론은 일반 이용자들의 눈에 띄지 않도록 해야 한다고 본다.위키피디아에 대한 첫 질문을 하는 것은 스트레스를 주는 경험이다.여기에 리디렉션을 추가하면 스트레스가 가중된다.그리고 새로운 사용자들을 그들이 유용한 대답을 얻을 수 있는 장소에서 다른 곳으로 리디렉션하는 것은 미친 짓이다.지도방 (토크) 07:34, 2015년 5월 17일 (UTC)[응답]
7. 모두 반대하다.이것은 단지 구조와 맞지 않고 RGluster와 Beeblebrox에 따르면 나에게 잘못되었다고 느낀다.SpindingSpark 12:24, 2015년 5월 17일 (UTC)[응답]
8. Beeblebrox와 Maproom 당 모든 것을 반대한다.내가 말하고 싶은 모든 것은 이미 그들에 의해 말해졌지만, 나는 WT:MoS가 우리가 새로운 편집자를 보내야 할 곳은 절대 아니라는 것을 강조할 것이다.아퍼슨 (토크!) 2015년 5월 18:29 (UTC)[응답]
9. 반대한다. 최근의 합의는 사람들이 스타일 질문을 위해 지정된 영역을 원하지 않는다는 것이었다.누구나 어디서든 스타일 질문을 할 수 있으며, WT에 가고 싶은 경우:MOS 그들은 그것을 하는 것을 환영한다.사라 (SV)^(talk) 2015년 5월 20일 (UTC) 19:29 [응답]

   그것은 전혀 공감대가 아니었다.통지는 일반적으로 해석의 대상이 되는 가이드라인이 아니라 집행(또는 관료나 봇 소유자와 같은 전적으로 절차적인 사항)이 필요한 정책 사항이기 때문에 원하지 않는다는 것이다.RS 공지 게시판과 WP와 같은 예외가 있다.알림판은 알림판이 아닌 많은 것들을 나열한다. — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ ⱷ^ʌ ҅_ᴥ ҅ 14:46, 2015년 5월 24일 (UTC)[응답]

10. 반대하라. 일반적인 명제로서, 우리는 더이상이 아닌 스타일의 미니티아에 대해 "규칙"을 시행하는 것에 대해 덜 걱정해야 한다.—스티브 서밋 (대화) 21:16, 2015년 5월 20일 (UTC)[응답]

    나는 1a면 괜찮을 것 같아.「스타일 매뉴얼의 해석에 관한 질문」의 효과에 대해, 「스타일 매뉴얼 페이지 개선을 논의하기 위한 토크 페이지」 —Steve Summit (토크) 21:25, 2015년 5월 20일 (UTC)[응답]

    음, 그렇다면 그건 "반대"처럼 들리지 않는데, 제안 포인트 #1에 대한 간결한 제안과 #2와 #3에 대한 선호도만 있으면 된다. SMcCandlish ☺ ☺ ☺ ≽^ʌ ⱷ ҅ ҅ ҅_ᴥ 14 14 14:46^ʌ, 2015년 5월 24일 (UTC)[응답]

    나는 내가 제안한 단어 바꾸기가 "의 효과까지"라는 단어들에 의해 수용될 수 있는 것보다 더 중요할까 봐 걱정했다. (어쨌든 당신은 토크 페이지의 소개 텍스트를 바꾸는 데 VP/Pr의 동의가 필요하지 않다.)—스티브 서밋 (대화) 11:32, 2015년 5월 25일 (UTC)[응답]

11. 반대, 이게 뭐야?이거에 대해서 RFC가 방금 있지 않았니?왜 중앙 집중화된 위치가 필요한가?위키프로젝트 페이지에서 링크를 클릭해보는 것은 어떨까?— RightCow LeftCoast(대화 • 기여) 21:29, 2015년 5월 22일(UTC)[응답]

    이것은 wakamole 게임도 아니고, 골대를 향해 공을 많이 차는 게임도 아니고, 무엇이 들어오는지 본다.--RightCow LeftCoast (토크) 21:29, 2015년 5월 22일 (UTC)[응답]

    나도 그 제안을 지지하지는 않지만, 애초에 제안되었던 방식으로 실패한 제안을 수정하는 것이 표준 운영 절차라는 것을 관찰해야 하고, 그 대안적 접근법이 설득력을 얻는지 살펴봐야 한다.실제로 실제 범위의 제안이 여러 번 반복되지 않는 경우는 드물다.두 제안(및 세 번째 아이디어는 헬프 데스크 페이지에 대한)에서 중앙 집중화된 이유는 동일한 일반 주제에 대한 토론을 중앙 집중화하는 것이 일반적으로 편집자에게 도움이 된다는 것이다.그래서 우리가 그렇게 많이 하는 거야. — SMcCndlish ¢ ⱷ ^ʌⱷ ≽ 15 _ᴥ15^ʌ 15:37, 2015년 5월 24일 (UTC)[응답]

12. MoS 블랙 피트에게 권한을 부여하거나 특별 지명을 주는 더 이상의 움직임에 반대한다.생산적인 콘텐츠 편집자(신작이든 구작이든)가 절대 필요로 하는 것은 MoS의 바보 같은 마엘스트롬에 빠져드는 것이다.중립성^talk 21:35, 2015년 5월 22일 (UTC)[응답]
13. 반대한다. 위키피디아에서 스타일에 대해 질문하는 장소는 WP:HD 또는 기사 토크 페이지 - 일반적으로 스타일에 대한 질문을 위한 장소는 WP:RD/L. 물론 사람들이 WT의 스타일에 대해 질문하고 싶다면:MOS, 그들은 할 수 있지만, 나는 우리가 더 공식적인 지원 페이지의 제외에 그것을 사용하도록 그들에게 요구해서는 안 된다고 생각한다.테빌도 (대화) 21:36, 2015년 5월 22일 (UTC)[응답]
14. 부드러운 반대 나는 중앙집권적인 스타일과 형식적인 토론 공간의 제안을 지지했지만, 이것은 단지 그것에 적합한 장소가 아니다.사실상, MoS 토크 페이지는 이미 이런 식으로 기능하는 경향이 있고, 그러한 임시 관행을 단념시킬 실질적인 이유는 없지만, 주요 가이드라인의 토크 페이지 역할을 체계화하는 것은 단지 빈대만을 불러올 뿐이라는 것을 상상할 수 있을 뿐이다.나는 다른 몇몇 반대자들은 이 토론 페이지에 일반적인 수준의 "관념"을 주장하는 반대자들 때문에 나는 불필요하고 증명할 수 없는 지나치게 초인적이고 비난적인 일반화에 사로잡혀 있다고 생각한다고 말할 것이다.내 경험상, 그 페이지에서 활동하는 편집자들은 일반적으로 매우 도움이 되고, 연대적이며, 합의된 접근법을 따른다.그러나 그 모든 것이, 나는 이러한 움직임이 확정적이고 광범위한 지역사회의 합의가 이루어지지 않는 분야에서 이 한 페이지의 견해에 부합되는 난해성 증가와 가중치의 확대로 이어질 수 있다는 것에 동의한다.간단히 말해서, 나는 차라리 공식적인 게시판 개념을 다듬고 다시 제안하는 것을 보고 싶다. 너무 아래쪽으로 가지 않기를 바란다.눈 22:49, 2015년 5월 22일 (UTC)[응답]
15. 헬프 데스크는 이러한 질문에 대해 괜찮기 때문에 반대하십시오.그리고 WT:MoS는 강박 관념이 있는 곳이기 때문이다.Andy TheGrump (talk) 22:56, 2015년 5월 22일 (UTC)[응답]

    왜 집단 인신공격?당신은 매년 수백명의 편집자들이 그 페이지에 글을 올리고, 장기 퇴역군인에서 초창기 신입 사원에 이르기까지, 정기적으로 그것을 합법적인 WP스타일의 질문을 하는 장소로 사용하고 있다는 사실을 어떻게 알고 있는가?

16. 어떤 식으로든 MoS의 더 이상의 코드화 또는 결정화에 반대한다.—S 마샬 T/C 23:14, 2015년 5월 22일 (UTC)[응답]
17. 질문하기 위해 첫번째 줄의 장소를 조각내거나 간단한 스타일의 질문으로 MoS 토크 페이지를 진흙탕으로 만드는 것은 도움이 되지 않기 때문에 마지못해 반대한다.WP:Tea House and Help Desk는 첫 번째 연락항이어야 한다.난해한 질문들이 WT:MoS와 공유되는 것에 반대하지 않는다.리치 팜브루, 2015년 5월 23일 (UTC)
    
18. 모두 반대하라: 가장 놀라울 정도로 반대하라!나는 이 일의 마지막 반복에서 그렇게 했고 나는 이 일이 있은 후에도 그것을 지킬 만큼 충분히 신경을 썼다.나는 RGloucester가 거기에 쓴 것이 나의 반대라는 최근 제안에 이르는 모든 대화를 읽었다.내가 이해한 바와 같이 "CREEP"의 반대는 그러한 페이지(또는 이 페이지로 가는 방향)가 과잉규제의 한 형태가 될 것이라는 전제에 근거하고 있다. 기사와 관련되지 않은 편집자들이 로컬 페이지 프로세스를 간섭하도록 지시할 것이다. 단, 나는 기사를 작성하는 동안 이외에 기사에 대한 변경사항을 포함시킬 것이다.여기에는 정적인 기사가 없다.만약 그것이 충분하지 않다면, 나는 여기서 비블브록스가 반대편에서 작성한 것을 호출하고 그것을 반향한다.내가 반대한다고 했니?나는 분명히 했다.2015년 5월 23일 12시 38분 (UTC)[응답]
19. 반대 - 헬프 데스크, AN/I 및 기타 다양한 게시판은 모두 이러한 기능을 가지고 있어서 무의미한 작업을 한다.–Davey2010^Talk 18:56, 2015년 5월 23일 (UTC)[응답]
20. 반대 우리는 편집자들에게 위키피디아를 편집하지 못하게 할 다른 장소가 필요하지 않다.MOS 질문이 어디서 발생하는지 쉽게 대답할 수 있다.—Finell 23:30, 2015년 5월 23일 (UTC)[응답]
21. 반대는 크게 근본적인 개선 없이 철저히 거부된 제안을 슬쩍 끼워넣으려는 의도로 보인다.Andrew Lenahan - Starblind 10:41, 2015년 5월 24일 (UTC)[응답]

    왜 나쁜 믿음의 가정인가?안내판(일반적으로 정책 시행을 위한)을 만들자는 제안은 WT:MOS는 일반적으로 편집자들이 WP 스타일 질문을 하기 위해 사용한다(그리고 그곳 사람들을 가리키는 리디렉션을 사용한다). — SMc캔들리쉬 lish ¢ ≽^ʌ ≽ ⱷ ⱷ^ʌ ҅_ᴥ ҅ 14:46, 2015년 5월 24일 (UTC)[응답]

    알림판은 "정책 시행"에 사용되지 않는다.RGlucester — 인터뷰 15:08, 2015년 5월 24일 (UTC)[응답]

    음, 그래. 안내판은 잘 안 읽나 보네. 그게 대부분 하는 일이니까. WP와 같은 기본적인 운영 방침이나.WP에서 컨센서스 등:ANI 또는 WP:V와 같은 특정 정책에는 자체 게시판이 있다.그렇다, 몇몇 가이드라인 문제에 대한 알림판이 있다(내가 "보통"이라고 말했던 것을 기억하라) 하지만 나는 그것들이 홀수라고 말하고, 가이드라인 해석에 관한 질문에 어떻게 대처해야 하는지에 대한 좋지 않은 모델이라고 생각한다.그 대부분은 WP:RS와 같은 정책에 관한 가이드라인에 관한 것이다.그들은 MOS와 다르다. (또한 봇 주인 NB나 관료 NB와 같은 전적으로 절차상의 공지사항 게시판도 있지만, 우리 모두는 내가 그런 것들을 의미하지 않는다는 것을 알고 있다고 생각한다.또한 WP에 나열된 많은 수의 비고지 보드:공지사항.) 그럼에도 불구하고, 요점은 분명히 MOS 공지사항 게시판이 좋은 접근방식은 아니지만(그리고 당신은 그 제안을 스스로 반대했음), 그것은 분명히 이 제안과 같지 않으며, 그들이 같다는 근거에 근거한 이 다른 제안 뒤에 숨겨진 악의에 대한 가정은 적절하지 않다는 것이었다.스타블라인드는 스스로 반응할 수 있고 그를 위해 뛰어들어 스포츠 경기를 할 필요는 없다고 생각해. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅_ᴥ 15:20, 2015년 5월 24일 (UTC)[응답]

    나는 그 제안을 "반대"하지 않았다.나는 그 제안서를 써서 제출했다.게시판에 대한 너의 정의는 틀렸다.이 문제에 관한 협약, WP:PNB, 당신이 생각하는 안내판이 안내판과 같지 않다는 것을 분명히 하라.RGlucester — 인터뷰 15:39, 2015년 5월 24일 (UTC)[응답]

    첫번째로 미안하다. 나는 내가 누구한테 응답했는지 잊어버렸다.안내판에 대한 정의는 어디에서도 제시하지 않았다.필자는 이름에 '공지판'이 있는 페이지를 상당히 분명히 언급하고 있는데, 그 대부분은 ('크래트 사업'과 같은 절차적 내용을 다루지 않을 때) 사실상 정책 집행 문제에 이용된다.아마도 당신은 단지 "강제"라는 단어에 부정적으로 반응하고 있을 뿐이지만, 나는 그것을 옹호할 것이다; 나는 누군가가 정책 위반을 멈추도록 하기 위해 경고, 차단, 주제 금지, 그리고 다른 지역사회와 행정 제재를 뭐라고 불러야 할지 모르겠다.나는 내가 어떻게 이것에 대해 더 명확하게 말할 수 있는지 잘 모르겠다. 그리고 나는 다시 당신에게 그것을 설명하는 것을 거절한다.나는 또한 이미 WP를 언급하였다.공지사항 게시판, 예.WP:PNB, 그래서 내가 방금 지적한 바로 그 페이지로 당신이 나를 안내하는 요점이 무엇인지 모르겠지만, 실제로 게시판이 아닌 비슷한 많은 것들의 목록들이다.나는 이 순환 대화에 더 이상 관심이 없다. — SMcCndlish ☺ ¢ ^ʌ≽ ≽ 16 16 _ᴥ16^ʌ 16:02, 2015년 5월 24일 (UTC)[응답]

    @스타블라인드라인드:당신의 불신에 대한 우려에 대응하여, 이 제안으로 이어지는 대화는 제안서에 연계되어 있다.[7] 클릭하고 싶지 않다면, 내가 스타일 공지 게시판에 대한 제안에 대한 반대 의견을 정리해 봤다는 것이 제스트다.너무 많은 사람들이 "스타일을 위해 한 페이지도 더 만들지 말자"고 했고, "토크 페이지가 이렇게 하도록 해야 한다"고 했기 때문에, 나는 기존의 토크 페이지를 단순히 승인하는 것에 대한 반대는 덜할 것이라고 생각했다.다크프로그24 (대화) 05:33, 2015년 5월 25일 (UTC)[응답]

22. 비록 약한 반대지만, 나는 "그리고 스타일 매뉴얼의 해석에 관한 질문들"을 선호한다. (실제로 2번째와 3번째 점에만 반대되는 "반대"로 만들어진 투표)WT:MOS는 이미 몇 년 동안 지속적으로 이런 방식으로 사용되어 왔으며, 사람들이 그것을 그렇게 사용할 수 있고 사용할 것이라는 사실을 "숨길" 필요는 없지만, 나는 WP:헬프 데스크가 적합한 장소인데, 왜냐하면 헬프 데스크가 좀 더 새롭기 때문이다.(WT에서의 논의는 사실 완벽하게 합법적이다.MOS는 페이지 상단이 편집자들에게 그들이 BTW에서 그런 질문을 할 수 있다는 것을 알려줄 수 있다는 생각에 찬성하거나 반대하기로 결정한다.)다른 몇 가지 사항을 해결하려면:

    MOS 단골들이 답을 지배할 것이라는 한 MOS 비난자의 반대는 어리석다; 사람들이 어디에서 이런 질문을 하는지는 중요하지 않다, MOS를 가장 잘 아는 편집자들이 대부분의 답을 제공하고 가장 정확한 답을 제공하는 경향이 있을 것이다.당연하지물리학에 관한 사실을 알고 싶으면 점성술이나 제빵 책 대신 물리학 책을 참고해야 하고, 법률 자문을 원하면 간호사가 아닌 변호사를 찾아가야 한다.

    많은 반대자들이 여기에 있다!이것은 미개하고, 나쁜 믿음의 추측이며, 어떤 경우에는 대규모로 인신공격에 대한 특허를 가지고 있다.여기서 편집하는 페이지들 때문에 "불굴의-강제"라고 불리는 이름이 되고 싶으세요?"MOS 편집자"의 특별한 카스트 같은 것은 없다.MOS 또는 WT 편집을 원하는 모든 사용자:MOS는 항상 "MOS 편집자"이다.반딧불 에피소드 목록 작업을 원하는 모든 사람은 "반딧불 에피소드 편집자"가 될 수 있다.그러한 라벨링은 말도 안 되는, 잘못된 이분법, 즉 명백히 존재할 수 없는 계층적 카스트 제도를 상상하는 것이다.

    특히 그러한 오류는 WP가 분쇄한 동일한 잘못된 개념과 밀접하게 관련되어 있다.현지 컨센서스 정책, 위키피디아 주체는 사이트 전체의 지침과 정책을 무시하고 "they" 기사에 대한 그들 자신의 규칙을 정립하는 주권적인 작은 구제책이다.대부분의 MOS 탈취자들과 완전 삭제 옹호자들이 위키백과 주제에 대한 잘못된 견해 아래 스스로를 "우리 부족 대 너희 부족"으로 몰아넣으며 전진하거나 운영한 편집자들인 것은 우연이 아니다.WT에서 거의 모든 분쟁을 일으키는 위닝 스트레이디:MOS. WP:B가 장착된 MOS 디플렉터만 해당가이드라인에 반하는 AT틀그라운드 도끼는 심지어 MOS와 관련된 질문을 가진 사람들을 돕고자 하는 것이 WT에 "당파적인 공기"를 준다는 비위키적인 개념을 상상할 수도 있다.MOS. 만약 내가 풀 플레이어에 관한 기사를 쓰고 있는데, 누군가 개인적으로 풀 플레이어가 눈에 띄지 않는다고 생각한다면, 그것은 나를 "풀 플레이어" 당파적인 사람으로 만들 것인가, 아니면 그 편집자 자신의 키보드와 의자 사이에 문제가 존재하는 것인가?아니면 이리저리 돌려보자.만약 당신이 캐나다 정기 간행물에 대한 참조 인용문을 포맷하기 위한 템플릿을 만든다면, 나는 그것이 무의미하다고 본다.{{Cite journal}}, 내가 너를 너의 일에 대해 "불쌍한"이라고 부르는 것은 예의에 어긋나는 일이니?{{Cite Canadian journal}}아니겠지.

    다음으로, 여기에 페이지를 작성하는데 부사장 제안이 필요하지 않다. 만약 누군가가 실제로 스타일 질문을 위해 HD 페이지를 실행하기를 원한다면, 가서 작성해서 작업을 하라.그것이 모든 WP가 완성되는 방법이다.

    마지막으로, MOS는 정책 문제가 아니며 "강제"될 수 없기 때문에 MOS 알림판은 부적절하다는 이전의 의견에는 동의한다(가장 가까운 것은 파괴적인 안티-MOS 편집이 WP에서 블록을 초래할 수 있다는 것이다).ANI는 때때로 WP를 위한 블록이다.DE, MOS "불복"을 위한 것이 아니다. — SMcCndlish ☺ ☺ ≽ ≽^ʌ ≽ 14ⱷ 14 14^ʌ:_ᴥ58, 2015년 5월 24일 (UTC)[응답]

23. 반대해. 새로 온 사람들이 위키피디아의 집 스타일에 대해 질문할 수 있는 한 장소 뒤에 숨은 생각은 이해할 수 있지만, WT에서 돼지들의 미친 소굴은 다음과 같다.MOS는 확실히 그것이 아니다.어딘가에 있는 누군가는 아마도 어떤 부분이 진지하게 다뤄져야 하는지 그리고 어떤 부분이 단지 개인적인 선호도를 표현하는 몇 명의 MOS 작가들인지 간단히 훑어보면서 새로운 사용자들을 위한 단순화된 MOS의 훨씬 더 단순한 버전을 써야 할 것이다. 그러나 그것이 무엇을 말하는지에 대한 합의를 얻는 것은 아마도 불가능할 것이다.– 무지개빛 11시 50분, 2015년 5월 25일 (UTC)[응답]
24. 반대하라; 단지 기사 페이지에 있는 스타일에 대해 이야기하라; 그것을 MoS라는 밑바닥 없는 구덩이와 토크 페이지를 보는 사람들에게 보내지 말라.문제 현장에서 처리해, 나는 어떤 종류의 것을 지지할 것이다.{{help me MoS}}기사 회담에 붙일 꼬리표를 붙이되, 거기에 두어라.하르키브07 (T) 12:55, 2015년 5월 26일 (UTC)[응답]
25. 반대해, 엉망진창인 것 같아.숨막힘(대화) 14:45, 2015년 5월 26일 (UTC)[응답]
26. 모든 BMK (토크) 08:30, 2015년 6월 5일 (UTC)[응답하라]

토론: WT:Q&A를 위한 MoS

지금 당장은 반대도 지지도 없이 이전의 논의는 여러 가지 이유로 반대했고, 거부당했다는 사실은 보편적으로 합의되지 않았다는 점에 주목하겠다.악마는 여기에 있고, RGlouscester가 주장하는 것(그리고 다른 곳)과는 달리, 우리는 "공동체가 어떤 형태의 중앙집중식 토론도 일방적으로 거절했다"고 말할 수 없다.우리가 말할 수 있는 것은 지역사회가 스타일 기반 토론을 관리하기 위한 한 가지 매우 구체적인 방법에 대한 한 가지 제안을 거절했다는 것이다. 그리고 사람들은 그 토론을 반대하는 많은 다른 이유들을 가지고 있었기 때문에, 그 문제를 다루는 다른 방법에 대해 새로운 논의를 하는 것은 완벽하게 괜찮다.공동체는 중앙집권적인 스타일의 토론을 하는 것을 거부하지 않았다.그 공동체는 그것을 한 가지 구체적인 방법으로 하자는 제안을 거절했다.다른 시각으로 재방문해도 괜찮을 것 같아. --Jayron32 20:18, 2015년 5월 15일 (UTC)[응답]

여기에 스타일게시판을 만들고 싶은 사람이 있다면 참석자들이 찬성하고 반대하는 이유로 제시한 이유를 정리해봤다.많은 반대자들은 스타일 토론을 위해 한 페이지를 더 만들고 싶지 않다고 말했다.적어도 이들 참가자 중 일부는 입증된 기록으로 기존 페이지를 승인하는 것을 지지한다고 말하는 것이 타당하다.심지어 게시판보다 토크 페이지 시스템이 낫다고 생각한다는 명시적 언급도 있었다.다크프록24 (대화) 21:11, 2015년 5월 15일 (UTC)[응답]

• 댓글을 달다.만약 편집자가 스타일에 대한 질문이 있다면, 그에게 MOS를 읽으라고 말하는 것은 나쁘지 않다.만약 그가 MOS에 대해 질문이 있다면, WT:MOS가 맞는 곳이야.그러나 만약 그가 MOS에서 규정되지 않은 어떤 결정에 대해, 예를 들어, 남아 있는 것이 있다면, 그것은 기사에 대한 이야기일 수도 있고, 아니면 그냥 시도해서 무슨 일이 일어나는지 볼 수도 있다.Wnt (토크) 20:09, 2015년 5월 28일 (UTC)[응답]

보통 일어나는 일은 답을 아는 사람은 그 질문을 보지 않는다는 것이다.

우리가 말하는 질문의 종류는 "모델링에 L이 하나냐, 두 개냐?"와 같은 것들이다.ENGVAR 문제인가?"[8] "그저 그럭저럭 내 변화를 되돌리고 있었다.누가 옳은가?" " 위키피디아는 X에 관한 규칙을 가지고 있는가?" "나는 중단 항공기에 대한 여러 기사를 편집해 왔다. 그것들이 과거형이어야 하는가 아니면 현재형이어야 하는가?"[9] "이 문장을 시작하는 올바른 방법이 하나 있을까, 아니면 내게 선택권이 있을까?"[10] 그들 모두가 특정 스타일 페이지와 관련된 것은 아니다.다크프로그24 (대화) 2015년 5월 29일 (UTC) 16:44 (대화)[응답]

만약 누군가 스타일과 관련된 질문이 있다면, 그들은 그것을 묻기 위해 어디로 가야 하는가?

이것은 정말로 대답해야 할 첫 번째 질문이다...답은 "공식" 페이지가 단 한 장도 없다는 것일지도 모른다...만약 그렇지 않다면, 어떤 선택들이...어디로 안내해야 할지 아는 게 도움이 될 거야블루보아 (대화) 21:04, 2015년 5월 15일 (UTC)[응답]

기사토크페이지.RG루스터 — ▷인터뷰 21:05, 2015년 5월 15일 (UTC)[응답]

기사 작업을 하는 스타일 구루들이 많다면...편집자가 거의 없는 기사는 어때?그 기사에서 일하는 편집자들 중 어느 누구도 그 질문에 대한 답을 알지 못할 것이다.그렇다면 그들은 토크 페이지에서 물어보는 것이 효과가 없다면 답을 찾기 위해 어디로 갈까?블루보아 (대화) 21:10, 2015년 5월 15일 (UTC)[응답]

존재하지 않는 '구루스'는 필요 없다.주어진 토크페이지의 편집자의 합의만으로도 분쟁을 해결할 수 있으며, 합의가 성립되지 않으면, DRN. RG루스터 — ▷인터뷰 21:21, 2015년 5월 15일 (UTC)[응답] 등 통상적인 채널이 열려 있다.

미안해, 난 분쟁 해결에 대해 말한게 아니야...나는 편집자들이 스타일에 대해 간단한 질문이 있는지, 도움과 조언이 필요한지, 어디로 가는지 묻고 있었다.예를 들면 다음과 같다.자신이 구두점을 잘 못 쓴다는 것을 아는 편집자 - 도움과 조언을 구하고 싶은 사람...그 편집자는 어디에 가서 도움을 청할 것인가?블루보아 (토크) 02:14, 2015년 5월 16일 (UTC)[응답]

WP:HD. --Redros64 (대화) 05:11, 2015년 5월 16일 (UTC)[응답]

네, 레드로스 씨.만약 누군가가 그의 영어 맞춤법에 약간 불쾌감을 느낀다면, 그것은 MoS와는 전혀 상관이 없다.그것은 그러한 문제들에 대한 기존의 장소에 속한다.RGlucester — 인터뷰 13:43, 2015년 5월 16일 (UTC)[응답]

MoS가 우리가 그 문제들에 관한 모든 규칙들을 적어놓은 곳이라는 것만 빼면, 대부분의 사람들이 이미 가고 있는 곳이지.다크프록24 (대화) 21:32, 2015년 5월 16일 (UTC)[응답]

동의한다. 이 상황은 욕망의 길로 인도하는 것과 유사하다; 우리는 가장 이상적이라고 믿는 정확한 방법론을 주장할 수 있다. 하지만 그것은 여러분이 그들에게 다른 분명하고 효율적인 선택-좋은 공공 공간-을 주지 않는 한, 강한 다수가 현재 그들에게 가장 직관적인 접근법을 따르는 것을 막지 못할 것이다.요즘엔 엔지니어들이 이런 요인들을 설명하기 때문에 우리도 여기에 와야 한다.MoS 토크 페이지는 분명히 헬프 데스크보다 스타일 문의에서 훨씬 더 많은 트래픽을 얻는다(최소한 수많은 정책과 가이드라인에 걸쳐 연결된 MoS와 비교할 때, 새로운 편집자들에게는 솔직히 쉽게 눈에 띄는 옵션이 아니다).나는 실제로 이 역할을 공식화하는 것에 반대한다. 그러나 나는 스타일과 형식 문제를 위한 어떤 형태의 중앙집중화된 공간이 이상적일 것이라고 생각한다.눈^{let's rap} 03:34, 2015년 5월 23일 (UTC)[응답]

특히 스타일에 도움이 되지만 WT:MoS가 아닌 페이지는 'MoS가 말하는 것'과 'MoS가 말하는 것'을 구분하는 것이 더 쉬워지겠지만, 토크 페이지 토론에서는 게시판의 제안이 합의를 보지 못한 것을 고려할 때 그러한 페이지는 시스템 게임으로 해석될 것이라는 우려가 있었다.제이런과 구IP는 하위 페이지 WT:MOS/questions Darkfrog24 (대화) 06:19, 2015년 5월 23일 (UTC)[응답]를 만들 것을 권고했다.

음, 나는 근본적으로 제안과 다른 공간에 같은 종류의 게시판을 만들어 이전 제안의 합의되지 않은 결과에 대해 최종 결론을 내리는 것에 대해 말하는 것이 아니다.오히려 나는 원래의 제안은 잠시 보류되었다가 (그리고 제안된 형식과 차원)에 대한 논쟁이 더 크게 개선되면 다시 중앙 공동체 논의를 위해 가져오자고 제안하고 있다.이전 토론의 다소 편향된 반대는, 나는 이 제안이 (내 견해에) 확실하기 때문에 조만간 지역사회에서 설득력과 폭넓은 승인을 얻을 수 있을 것이라고 생각한다.한편, 가이드라인 토크 페이지를 공식적인 해결/도움 공간으로 설정하려고 노력하는 것은 (VPP 실에서 연설한 사람들 중 가장 많은) 양쪽에 있는 대부분의 편집자들이 지지하는 우선순위와 우려에 역효과적일 것이라고 생각한다.눈^{let's rap} 07:54, 2015년 5월 23일 (UTC)[응답]

흥미롭군.이 제안과 이전 제안에 대해 어떻게 바꾸시겠습니까?다크프록24 (대화) 04:38, 2015년 5월 24일 (UTC)[응답]

당장 스타일 Q&A에 대한 공식 페이지는 한 장도 없지만(WT:MoS가 비공식적으로 많은 부분을 해냈지만) 한 장만 있어야 한다고 생각한다.안내판이라고 부르고 헬프 데스크라고 불러라; 나는 우리가 현재 WT:MoS와 다른 대화 페이지에서 하고 있는 Q&A가 모두 한 곳에서 일어나고 편집자들이 쉽게 찾을 수 있도록 만들어지는 한, 별로 신경 쓰지 않는다.만약 우리가 여러 페이지를 사용한다면, 사람들은 모순된 결과를 얻는다.다른 편집자들도 포럼 쇼핑에 대해 우려를 표명했다.다크프로그24 (대화) 2015년 5월 15일 21:16 (UTC)[응답]

나는 그것이 우리가 제안하는 포럼이라고 부르는 것에 영향을 미치지 않는다는 것에 동의한다.내가 위에서 언급한 바와 같이 문제는 이러한 자칭 '구루'들은 종종 극도로 강박적인 규칙 고수들이며, 다른 모든 사람들이 더 이상 신경 쓰지 않는다고 판단하고 그냥 가버릴 정도로 서로 동의하지 않으며, 심지어는 어떤 것이든 자기네 선반으로 들어가려고 때론 양말질이나 다른 용납할 수 없는 행동에 의지하기도 한다는 것이다.무의미한 논쟁을 일으키다누구에게나 도움을 청하러 이 사람들에게 가라고 지시하는 것은 끔찍한 생각일 것이다.그래서 페이지 이름과 상관없이, 우리는 이것을 해서는 안 된다.사실, 나는 현재 MOS 토크 페이지에서 사용자들이 그들의 문의를 가지고 다른 곳으로 가도록 조언하는 큰 고지를 지지할 것이다.비블브록스 (대화) 17:50, 2015년 5월 16일 (UTC)[응답]

Beeblebrox, 예시 질문의 링크를 클릭하십시오. 체리 픽업이라고 생각되면 WT:MoS 아카이브를 확인하십시오.사람들은 나타나서 질문을 하고 대답을 듣고 앞으로 나아간다.사람들이 "MoS가 뭐라고 말해야 할까?"라고 말할 때, 우리는 그것에 대해 싸운다. 하지만 사람들이 "MoS가 무엇을 말하는가?"라고 물을 때, 그것은 꽤 간단하다.아니면 반대로, 편집자가 스타일 질문을 해서 양말 인형(또는 그에 필적하는 악랄함)과의 싸움으로 번진 시기의 링크를 올릴 수 있는가?다크프로그24 (대화) 2015년 5월 16일 21:30 (UTC)[응답]