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

마을펌프
- 정책
- 기술
- 제안. (iii)
- 아이디어 랩
- WMF
- 잡다한

마을 펌프(제안) 아카이브

이 페이지에는 빌리지 펌프(제안)에서 보관된 토론이 수록되어 있다.이 페이지의 내용을 편집하지 마십시오.이러한 토론 중 하나를 다시 시작하려면 새 스레드를 시작하거나 해당 주제와 관련된 대화 페이지를 사용하십시오.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125,126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188

소스 코드의 산술 태그에서 이동

위키피디아 기사의 "Rational number" 섹션인 Number에서, 나는 분수를 이미지라기보다는 텍스트로 쓰는 방법을 발견했다.예를 들어.1/2은 그대로 썼다.제안서에 분율 코드를 어떻게 표시할지 모르겠지만, 당신은 제안서를 수정하여 답변할 때 분율 작성 방법을 볼 수 있을 것이다.나는 ${\sqrt {2}}$ {\ $displaystyle$ {\ $sqrt{2}}:}$ 이(가) 별도의 제곱근 기호로 오버라인 포맷을 하지 않고 이미지 대신 텍스트로 나타날 수 있는 ${\sqrt {2}}$ 어떤 방법도 아직 모른다.변수는 이미지일 필요는 없지만 이탤릭체 형식의 일반 문자가 될 수 있다.어떤 수학적인 표현이라도 이미지 대신 텍스트로 보이게 할 수 있는 소스 코드가 있어야 한다고 생각한다.일단 그렇게 되면, 수학 태그를 사용하는 낡은 메토들은 기사에서 새로운 수학적 표현을 만드는 방법에 대한 경각심을 높이기 위해 작업을 중단해야 한다. 그렇지 않으면 그 수백만의 사람들이 모두 무식하고 새로운 수학적 표현의 존재를 깨닫지 못하기 때문에 수학적 표현을 창조하는 낡은 방법을 하게 될 것이기 때문이다.방법의블랙밤추 (토크) 22:17, 2013년 11월 21일 (UTC)[응답]

나는 여기에 실제 제안이 있다고 보지 않는다.기본적으로 당신은 "LaTeX를 아직 작성되지 않은 새로운 템플릿으로 대체하고, 규격처럼 원격으로 아무것도 없는, 만약 파란하늘이 좋다면"이라고 말하고 있다.

그러나, 미디어위키 소프트웨어에서 수학의 렌더링을 향상시키기 위한 매우 실질적인 프로젝트가 있다.몇 년째 서서히 타오르면서 진행되어 온 일인데, 현재 상태가 어떤지 말해줄 수가 없었다.위키피디아와 미디어위키 공간에 'mathjax'와 'blahtex'를 검색하십시오. --Trovatore (대화) 22:32, 2013년 11월 21일 (UTC)[응답]

많은 수학적 표현은 텍스트로 쓸 수 없다.우리가 원하는 표현을 만들어 낼 수 있는 브라우저에 보낼 수 있는 것은 아무것도 없다.우리가 적절한 외모를 표현하고 싶다면 어떤 일에는 이미지가 불가피하다.프라임헌터 (대화) 2013년 11월 21일 (UTC) 23:00[응답]

분수는 쉽다.n번째 루트, 확실한 적분 또는 증강 매트릭스를 어떻게 할 것을 제안하는가? --카르닐도(토크) 02:25, 2013년 11월 22일 (UTC)[응답]

아마도 브라우저는 시간이 지남에 따라 천천히 진화하여 한 번에 하나의 텍스트로 나타날 수 있는 수학 연산 수를 점차 증가시킬 것이다.제곱근은 수학에서 매우 흔하기 때문에 아마도 제곱근 기호가 브라우저가 수용하는 첫 번째 것일 수 있고, 그리고 훨씬 나중에 그들은 확실한 적분처럼 더 복잡한 표현을 수용하게 될 것이다.화학에서 원소는 때때로 원자 번호와 원자 질량을 나타내는 첨자와 위첨자로 표시되므로 브라우저가 첨자 바로 위에 있는 위첨자를 수용하도록 진화한다.블랙밤추 (토크) 03:35, 2013년 11월 22일 (UTC)[응답]

위키피디아가 아닌 모질라, 마이크로소프트, 구글에 제안해야 할 것 같은데 --골베즈 (대화) 14:58, 2013년 11월 22일 (UTC)[응답]

이는 실제적인 이유가 있기보다는 변화를 위해 변화를 꾀하자는 제안으로 보인다.나는 이 "제안"이 왜 만들어졌는지 이해할 수 없다.— Huntster (t @ c) 03:17, 2013년 11월 22일 (UTC)[응답]

영상의 형태가 되면 수학 식이 영상의 형태가 아닌 텍스트보다 더 큰 텍스트를 갖게 된다.위키피디아가 글과 크기가 같은 울프램 수학월드와 같았다고 해도, 수학적인 표현으로 나타나는 숫자들은 텍스트와 같은 숫자로 나타나기 때문에, 특히 인터넷을 확대해서 볼 때, 정확히 똑같아 보이지는 않을 것이다.긴 수학적 표현이 이미지의 형태인 것은 전체적 표현 대신에 그 표현식의 일부만 복사하고 붙여넣는 것도 불가능하게 만든다.블랙밤추 (토크) 03:47, 2013년 11월 22일 (UTC)[응답]

안녕 블랙밤추.MathJax를 보셨나요? --MZMcBride (대화) 04:16, 2013년 11월 22일 (UTC)[응답]

What are you going to do about expressions like $\oint \limits _{\partial S}\mathbf {F} \cdot d\mathbf {L} =\iint \limits _{S}\nabla \times \mathbf {F} \cdot d\mathbf {S}$ (here, Stokes' theorem)?(이 작업을 수행하려면 템플릿이 너무 많이 필요함).반면, LaTeX는 그것을 보여주는 좋은 표준화된 방식이고, 사실 템플릿이 아닌 다른 문서로 수출하는 것이 더 쉽다.브라우저가 도입했다 하더라도 이를 지원하지 않는 구형 브라우저에 대한 지원이 끊길 수 있기까지는 수년이 지난 후일 것이다.--Jasper Dung (talk) 04:58, 2013년 11월 22일 (UTC)[응답]

나는 일단 모든 수학 표현을 다룰 수 있는 브라우저가 만들어지면, 위키피디아는 새로운 브라우저와 복잡한 수학 표현을 다룰 수 없는 오래된 브라우저를 위한 두 가지 버전의 기사를 가져야 한다고 생각한다.수학 식을 변경하지 않는 인증자 유형의 편집의 경우, 두 가지 버전의 기사에 대해 동시에 동일한 편집을 하는 두 번째 편집 옵션도 있어야 한다.블랙밤추 (토크) 01:51, 2013년 11월 27일 (UTC)[응답]

LaTeX는 수학과 과학계에서 꽤 잘 확립되어 있다.일반 사용자는 익숙하지 않을 수 있지만, 적어도 위키백과 등에 잘 문서화되어 있다.이것은 기본적으로 그것을 위키백과 특유의 것으로 대체하고, 현재 아무도 알지 못하며, 에 대한 어떤 문서도 존재하지 않는다고 제안하고 있다.그것은 아마도 수학 전문가들이 기여하는 것을 심각하게 단념시킬 것이다.{{sfrac}}}은 분수를 표시하도록 고안된 어떤 특별한 브라우저 동작이 아니라 단지 CSS와 템플릿 코드의 뭉치일 뿐 어떤 것을 분수처럼 보이게 만드는 것이다.텍스트로 강조할 수 있지만 복사해서 붙여넣으면 1/2이 그냥 1/2이 된다.Mr.Z-man 05:43, 2013년 11월 22일 (UTC)[응답]

인터넷에서 읽었는데, 어떻게 해야 할지 모르겠지만 마이크로소프트 단어로 네모난 뿌리를 쓸 수 있다고 했어.그런 말을 했으니, 마이크로소프트 단어로 분수를 쓰는 것도 가능할 것 같다.마이크로소프트 워드는 분수를 다룰 수 있기 때문에, 위키피디아는 12을 복사해서 마이크로소프트 워드에 붙여넣으면 12로 붙여넣지만 메모장에 붙여넣으면 마치 마이크로소프트 워드에서 복사하여 메모장에 붙여넣은 것처럼 붙여넣을 수 있는 방식으로 진화하는 것이 가능해야 한다.블랙밤추 (토크) 01:59, 2013년 11월 27일 (UTC)[응답]

단어에는 방정식 편집기가 내장되어 있다.그러나 마이크로소프트의 독점적인 OLE 포맷을 사용하기 때문에 무료/오픈 소스 소프트웨어를 선호하는 위키백과와의 호환성은 거의 없다.방정식 편집기(WYSIWYG 편집기 [1])와 유사한 기능을 하는 것을 VisualEditor에서 구할 수 있을 것이다.Mr.Z-man 15:48, 2013년 12월 2일 (UTC)[응답]

모욕적인 말을 숨기기 위한 제안

이 논의는 건설적인 방향으로 흐를 것 같지 않다.우리 같이 갈까?The OriginalSoni (talk) 09:22, 2013년 12월 3일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

나는 원래 WP에서 이 아이디어를 발표했다.VPIL, 그리고 이게 지원을 받아서 여기로 가져왔어.이 아이디어는 위키피디아가 사람들이 그들의 브라우저를 구성해서 마호메트를 묘사하는 것과 같은 불쾌한 이미지를 표시하지 않도록 한다는 사실에 영감을 받았다.내 제안은 우리가 같은 일을 하지만 노골적인 단어에 대해서는, 그래서 내 제안 하에, 사람들은 그들의 브라우저를 구성할 수 있는 선택권을 가지고 있어서 "젠장", "시발" 그리고 유사한 단어들이 검은 검열봉으로 대체될 것이다.위키피디아는 검열되지 않지만, 내가 보기에 위키피디아는 절대적으로 필요한 것 이상으로 사람들의 기분을 상하게 해서는 안 된다는 것을 알고 있다.진킨슨은 2013년 11월 27일 16:43, 27 (UTC)과 통화[응답]

반대하라 나는 특별히 불안한 이미지들을 메인페이지에 붙이지 않는 것은 괜찮지만, 나는 다른 제도화된 "모래 속의 머리" 행동에 대한 관용은 거의 없다.이것은 백과사전이고, 역사와 시사 문제를 제대로 다루는 과정에서 우리는 현대 서구의 사회적 가치에 의해 "끔찍한" 것으로 여겨질 것들을 사람들이 말할 수 있고 인용할 수 있다.우리는 열한 살마다 듣고 대부분의 열한 살들이 사용하는 말을 숨기려고 시간을 낭비해서는 안 된다.만약 누군가가 사용자설명서를 만들고, 코딩과 목록을 전적으로 그들 자신의 사용자 공간 내에 유지하기를 원한다면, 그들은 자유롭게 그렇게 할 수 있고, 나는 반대하지 않을 것이다.하지만 만약 누군가가 이것을 기기로 바꾸거나, 미디어위키 네임스페이스를 사용하거나, 다른 사람들이 그 단어들을 보는 것을 방해할 수 있는 어떤 것을 하고 싶다면, 나는 큰소리로 반대할 것이다.극도로 마른 피부를 가진 사람들이 더 편안하게 느끼도록 하기 위해 현실을 왜곡하지 말자.Sven Manguard Wha? 22:09, 2013년 11월 25일 (UTC) 이전 포럼에서 복사, 타임스탬프 등, 그 문제에 대한 나의 생각이 변하지 않았기 때문이다.[답답하다]
반대 WP:NOTCENSORED, 그리고 이것을 하고 싶은 사람은 누구나 스스로 할 수 있다.잭mcbarn (대화) 2013년 11월 27일 18:10 (UTC)[응답]
스벤 므앙구아르에 따라 반대하라.비록 이것이 선택사항이라 할지라도, 어떤 단어가 선택사항의 대상이 되고, 그렇지 않을지에 대한 논쟁은 독성이 있고, 대단히 도움이 되지 않을 것이다.나는 모든 이미지를 똑같이 차단하지 않는 한 위에서 언급한 진킨슨과 같은 이미지-센서링 옵션을 별로 찬성하지 않는다.이 아이디어는 이전에 제안된 적이 있고 합의 같은 것을 얻은 적이 없으며, 그럴 것 같지는 않다.DES 19:33, 2013년 11월 27일 (UTC)[응답]
모욕적인 단어에 대한 토론은 한 문맥에서 중요할 수 있고 다른 문맥에서 불필요할 수 있기 때문에, 기사의 토크 페이지에 속한다.그런 결정을 내리기 위해 NOTCENSORED(있긴 하지만!)에 기댈 필요는 없다고 생각한다.프로톤크 (대화) 19:54, 2013년 11월 27일 (UTC)[응답]
빌어먹을 지원군나는 처음에 이 빌어먹을 것에 반대했다, 내가 다른 사람들이 확실히 말할 것에 맞춰, 여기 이 제안들에 대한 전통적인 대답과 함께, 단지 내 의견을 듣고 있다는 것을 깨닫기 전까지.생각해보면, 이런 빌어먹을 기계장치의 해악은 볼 수 없지만, 그래도 토글 링크나 자극에 의해 단어를 보여줘야 할 겁니다. 사용자들이 그 단어를 볼 필요가 있을 때마다 기기를 사용하지 않도록 해야 하는 것은 원치 않습니다.위의 투표들 중 어느 것도 실제로 이것이 기기로서 문제가 될 만한 이유를 제시하지 않았다. 어떤 단어를 포함해야 하는가에 대한 질문 외에는 말이다. 나는 우리가 어떤 외부 표준(예: 서부 TV 방송국에서 말할 수 없는 단어)을 사용함으로써 해결할 수 있다고 생각한다.기계는 우리가 검열을 받지 않는 원리를 해칠 것 같지 않다.Sven이 위에서 주장하는 것처럼 우리가 실제로 "시간을 낭비한다"거나 그것을 수용하기 위해 노력한다면 문제가 될 수 있지만, 만약 어떤 개인이 코딩에 시간을 쏟고 싶다면, 내가 볼 수 있는 지역사회에 실질적인 비용 없이 그들을 그냥 내버려둘 수 있다.equazcion → 19:57, 2013년 11월 27일 (UTC)
나는 위의 아이디어를 지지한다.또한 단어 목록을 미리 정의하기보다는 사용자가 찾은 모든 단어를 단순히 목록에 추가할 것을 제안한다.따라서 "and" 또는 "was" 또는 "프랑스"라는 단어를 좋아하지 않는 사람은 공격 리스트에 그 단어들을 간단히 추가할 수 있다.누수 솥 20:02, 2013년 11월 27일 (UTC)[응답]
- 각 사용자가 자신의 목록을 유지한다는 말씀이시죠?그냥 해명하는 거야.equazcion → 20:06, 2013년 11월 27일 (UTC)
  - 까다롭지 않다.블랙리스트 '프랑스'는 왜 모두에게!누수 솥 20:08, 2013년 11월 27일 (UTC)[응답]
    - 아, 그렇구나.그래서 당신의 지지 투표는 실제로 반대표를 던지는 것이다.그냥 모두에게 알려주고 있어.설명해줘서 고마워.equazcion → 20:10, 2013년 11월 27일 (UTC)
만약 누군가가 이것을 위한 개인 대본을 개발하고 싶어하고 다른 누군가가 그것을 사용하길 원한다면, 나는 그것이 다른 편집자들의 작업을 방해하지 않는 한 우리가 왜 금지해야 하는지 모르겠다.어떤 사람들은 이미 이 클라이언트측을 사용하고 있으며, 그들은 분명히 다른 곳에서 같은 단어를 차단하기를 원할 것이다.그러나 세계적인 구현으로서, 이것은 결코 효과가 있을 수 없다.시스템은 단어의 맥락을 결정할 수 없으므로 어떤 것을 검열할지 여부를 정확하게 결정할 수 없다.이것은 무엇이 불쾌하고 불쾌하지 않은지를 결정하는 것은 매우 주관적이고 너무 많은 요인에 의존하고 있다는 것을 언급하기 전에도 이 시스템이 모든 것을 설명할 수 없었다.유일한 해결책은 각 인스턴스에 수동으로 플래그를 지정하는 것인데, 이 경우 나는 이러한 임의 워크로드를 생성하는 것을 강력히 반대한다.— HELLKOWZ zTALK 20:33, 2013년 11월 27일 (UTC)[응답]
- +1. 브라우저 플러그인이나 사용자 설명만 원하는 것처럼 들린다.이것이 사이트 레벨 기능이 되어야 할 이유는 없다.프로톤크 (대화)20:40, 2013년 11월 27일 (UTC)[응답]
사용자가 표현한 이유와는 별도로 반대:Sven Manguard, 그러한 도구들은 또한 실수로 많은 다른 것들을 검열한다.얼마 전 중국 정부는 특정 반체제 인사들에 대해 구글링을 하는 사람들을 막기 위해 江(장칭, 장쩌민)과 周(장쩌민)에 대한 검색을 차단했다.츄엔라이).이 때문에 구글이 중국에서 이들 세 사람을 검색하는 것을 차단했지만, 강이나 주간 출판물의 이름을 입력해 검색하지 못하는 안타까운 부작용도 있었다.[2] 차단 스크립트는 나쁜 단어들을 차단할 뿐만 아니라, 나쁘지는 않지만 영어로 된 나쁜 단어와 동일하게 철자가 되는 단어들, 예를 들어, 참고문헌의 영어 이외의 책 제목에 있는 임의 단어들도 차단할 수 있다.일부 잘못 작성된 검열 대본은 비록 그 긴 단어가 처음부터 나쁜 단어가 아니더라도 "토요일"과 같이 짧은 나쁜 단어가 포함된 긴 단어를 검열한다.이런 부작용은 오히려 나쁜 말에 더욱 주의를 끌게 되고 따라서 역효과를 낳는다. --Stefan2 (토크) 22:10, 2013년 11월 27일 (UTC)[응답]

반대한다. 만약 사람들이 브라우저에서 어떤 종류의 언어를 사용해야 하는지, 일종의 편리한 플러그인으로 사용자 정의하기를 원한다면. (Google Chrome Extension이 이미 이것을 가지고 있는 것 같다; Google Chrome Extension Sure You'll Never See You Words You Hate를 참조하라.) 위키백과 사용자들이 그들이 보는 언어에 대해 강하게 느낀다면 아마도 리스트로 향할 수 있을 것이다.적절한 플러그인의 t. ~ J. Johnson (JJ) (토크) 22:29, 2013년 11월 27일 (UTC)[응답]
반대한다. 위키피디아는 검열되지 않는다.미안해, 사람들이 뛰어들어 정책을 인용하는 게 싫지만, 여기서 해야 해.만약 누군가가 사람들이 이것을 하기 위해 사용할 수 있는 기기를 개발하기를 원한다면, 그렇다면, 괜찮다.나는 네가 그것을 어떻게 할 지 모르겠다. 무엇이 "악의적"이고 무엇이 아닌지는 매우 주관적이고 문화에 민감하기 때문이다.그래도 배를 띄우는 건!나는 사람들이 그들만의 인터페이스를 수정하는 것에 문제가 없다.나는 이것이 사이트 레벨의 기능이 되는 것에 문제가 있다.우리는 검열받지 않는다. --(ʞɿɐʇ) ɐuɐsǝp 22:40, 2013년 11월 27일 (UTC)[응답하라]

나는 WP의 경계를 넓힌 적이 없다.보통은 꽤 유치하기 때문에 NOTCENSORED.하지만 나는 또한 만약 여러분이 어떤 것에 쉽게 불쾌해한다면, 인터넷은 아마도 여러분을 위한 것이 아닐 것이라고 믿는다.'나쁜 말'은 역사적으로나 학문적으로나 관련 있는 용도가 많으며, 무엇을 용납할 수 없는가를 결정하는 것은 독자의 몫이다.– Juliancolton 22:35, 2013년 11월 27일 (UTC)[응답]
반대하라 UAA에서 봇(그리고 살아있는 사용자들 역시...)이 '나치르'(Nazir) '시시르'(Dikshitar'에서처럼)를 포함한 이름들을 불러오는 문제를 보면, 그들이 무엇에 대해 하고 있는지 자세히 살펴봐야 하는 다른 문제들을 볼 수 있을 것이다.영국에도 페니스토네, 스쿤토프, 프리크윌로우와 같은 꽤 순진한 플래카드들이 있다.그리고 'fag' 같은 단어들이 있다.미국에서는 거의 치명적인 모욕 같지만, 영국에서는 담배(또는 공립학교에서 온 구식 용어)에 불과하다.사기꾼은 미트볼의 일종이나 나무다발이다.어느 정도의 '나쁨'을 말하는 거야?공은 나쁜가?공중에서 토하기 전에 코트에서 튕기는 테니스 선수들에게 행운이 따르길 바란다.공이 나쁘면 고환은?다른 언어에서는 '나쁘지만' 영어에서는 그렇지 않은 단어는 어떨까?기분 상하게 하려는 의도로 '나쁜 말'을 불필요하게 사용하는 것은 공공 기물 파손으로 분류할 수 있다.그것들을 모든 용도로 사용하는 것을 검열하는 것은 실행 불가능하며, 어쨌든 모든 사람들의 만족을 규정하는 것은 거의 불가능할 것이다.페리돈 (토크) 2013년 11월 29일 (UTC) 14:36[응답]
- 하하! 페니스톤! 에카즈시온 → 2013년 11월 29일 (UTC)
  사물을 검열하기 위해 소프트웨어를 설치한 스코틀랜드 의회도 있었다.'삐'를 넣었다.그들은 심지어 그들의 사이트에 '배추와 홍합'과 '배추'와 같은 것들을 간신히 얻을 수 있었다.그들이 매우 어리석게 보인다고 결정하기 전까지는 정말 재미있었다...페리돈 (대화) 2013년 11월 29일 17시 10분 (UTC)[응답]
그래, 이건 박쥐같아.그리고 내 말을 믿어라, 경계라는 단어는 해결책이 아니다.Theopolisme (대화) 2013년 11월 29일 (UTC) 16:21[응답]
지원 퍼 리키, 위.여기서 '프랑스'라는 말을 못 보고 싶은 마음이 조금이라도 든다면 나만의 대본을 쓰지 않고도 그렇게 할 수 있었으면 좋겠다.반대쪽 사람들이 제발 그게 무슨 문제인지 말해줄 수 있어?진짜.이 기능이 원하지 않는 사람에게 불편을 끼치지 않는다면, 왜 그것을 원하는 사람과 그것을 만들고자 하는 사람들을 막아야 하는가?그러한 특징의 금지에 의해 예방되는 해악은 무엇인가?

위에서 스벤은 "열한 살마다 듣고 대부분의 열한 살들이 사용하는 말을 숨기려고 시간을 낭비해서는 안 된다"고 말한다.그러나 그는 왜 독자들이 독자들을 자신을 위해 숨기도록 돕지 않는지, 또는 그가 낭비되는 것에 대해 걱정하는지 우리에게 말하지 않는다.아무도 그가 무엇을 해야 한다고 제안하지 않는다.그는 또 "너무 마른 피부를 가진 사람들이 더 편안함을 느끼도록 하기 위해 현실을 왜곡하지 말자"고 권한다.현실 왜곡?그리고 어떤 말들이 불쾌하다고 생각하는 사람들은 "피부가 얇고" 그들의 감정은 중요하지 않다는 주장도 있다.미안, 자원 봉사자들이 원한다면 이 기능을 만들지 못하게 할만한 이유가 여기선 아무것도 안 보여

그렇긴 하지만, 위의 J. Johnson의 링크를 보면 왜 아무도 귀찮게 하는지 알 수 없다. --Anthonyhcole (대화 · 기여 · 이메일) 16:51, 2013년 11월 29일 (UTC)[응답]

나는 아무도 그들 자신의 일을 하지 못하도록 금지하자는 것이 아니다.그들은 내가 신경쓰는 한 모든 s와 x 글자가 분홍색으로 변하는 대본을 만들 수 있다. 그것이 그들 자신의 기계에서만 그렇게 하는 한 말이다.아니면 크롬을 이용해서 북방 블립 오 더 북방 같은 곡조를 발견하거나, 블립 아 리키 수프를 먹어보거나, 그 인디언 이름으로 된 블립이 무엇인지 결코 알아내지 못할 수도 있다.그것을 이용하려면, 그들은 거부감을 극복하고 불쾌한 단어를 입력해야 한다.그거 참 신기하네. (많이 안걸리는데...) 페리돈(토크) 17:20, 2013년 11월 29일 (UTC)[응답]

하지만 당신은 자원 봉사자들이 미디어위키에 기기를 추가하는 것을 금지하자고 제안하고 있다. 왜?네가 왜 그렇게 하고 싶은지 모르겠어.말해줄래? --Anthonyhcole (대화 · 기여 · 이메일) 18:35, 2013년 11월 29일 (UTC)[응답]

기본적으로 서양의 문화적인 것이다.몇몇 사람들은 여러분이 그들이 게시하기로 선택한 어떤 불경스런 글도 읽고 싶지 않을 정도로 불쾌해하고, 그들은 가능한 한 여러분 자신의 독서를 통제하는 것을 어렵게 하고, 공식적으로 못마땅하게 만들고 싶어한다."실버봇이 그것을 되돌리기 위해 돌아다니기 전에 어떤 종류의 공공 기물 파괴 행위를 보지 말라고 진정으로 고집한다면, 혹은 분명히 전문적이지 않은 의사소통 기술을 가진 사람들 사이의 대화에서 불경스러운 행위를 보지 말자고 주장한다면, 우리들 중 몇몇은 아마도 당신이 당신의 이상한 전화 끊기에 대해 심리학자를 만나야 한다고 생각하겠지만, 그러나 당신이 p에서 자기 검시를 하는 한,리바이트, 그렇다면 네가 그 자유를 행사하는 걸 막을 수는 없겠군다만 그들이 올리는 욕설이나 외설적인 글을 읽고 있지 않다는 사실을 아무에게도 알리지 말게."

당신은 아시아, 아프리카, 혹은 세계 남부의 문화권 출신의 많은 사람들이 이 관점을 지지하고 있는 것을 발견하지 못할 것이다.그들은 듣는 사람들이 그들이 선택해서 듣지 않는, 즉 지나가는 사람들에게 불경한 소리를 지르는 사람에게서 도망치거나, 페이지를 필터링하거나 대화에서 손을 떼는 것과 동등한 인터넷 행위를 할 수 있는 분명한 권리를 가지고 있다는 관점을 취하는 경향이 있다.

그 모든 것이, 나는 매우 많은 사람들이 실제로 이런 대본을 쓰려고 할 것이라고는 상상할 수 없다.나는 어떤 WP와도 아무런 문제가 없다.자원봉사는 그것을 만들거나, 심지어 그것이 안정적이면 기기로 설치하는데 시간을 보내지만, 나는 그것이 인기 있는 것으로 증명될 것이라고 생각하지 않는다.WhatamIdoing (talk) 19:12, 2013년 11월 29일 (UTC)[응답]

만약 누군가가 그들 자신의 대본을 쓰고 싶다면, 그들을 막을 수 있는 것은 아무것도 없다.그렇게 하는 것은 지역사회의 승인을 필요로 하지도 않고, 결코 요구하지도 않는다.그것이 바로 무함마드 이미지 필터의 작동 방식이다.그러나 검열이 위키피디아에서 지원하는 기기로 만들어서는 안 된다.또한, 나는 너의 비유가 형편없다고 생각한다.아무도 위키피디아를 방문하거나 읽을 필요가 없다.그들은 불경스러운 소리를 지르는 가상의 사람으로부터 벗어나는 것만큼이나 자유롭게 웹사이트를 떠날 수 있다.게다가, "서양 문화" 안에는 검열을 추구하고 촉진하는 많은 사람들이 있다.이 경우 그것에 대한 반대는 인터넷 문화에 더 정확히 반영된다.결연한 19:25, 2013년 11월 29일 (UTC)[응답]

Anthonyhcole - 무료 백과사전인 위키피디아에 있다면, 무언가를 배우기 위해 여기에 있는 것이다.불쾌하다는 이유만으로 불쾌감을 주는 말을 가리는 것은 백과사전적인 목적에 도움이 되지 않는다고 믿고 있으며, 적절한 방법으로 사용되는 경우, "n 단어"가 "허클베리 핀의 모험"과 "아프리카계 미국인의 고정관념" 또는 "f 단어"를 포함하는 다양한 밴드나 노래에 있는 것처럼 실제로 학습을 방해한다.ng. 나는 위키피디아가 사람들에게 역사와 문화를 화이트 워싱하거나 청소할 수 있는 도구를 주어야 한다고 생각하지 않는다.스벤망구아르화 ? 2013년 11월 29일 18시 5분 (UTC)[응답]

글쎄, 나는 이 도구를 사용할 사람들이 다른 사람들에게 강요하고 있다면 당연히 동의할 거라고 생각해.그러나 우리는 독자들이 선택할 수 있는 도구에 대해 이야기하고 있다.그게 정확히 어떻게 문제야?여기서 정확히 누가 피해를 입었는가? --Anthonyhcole (talk · 기여 · e-메일) 2013년 11월 29일 (UTC)[응답]

언어를 두려워하는 백과사전은 가치가 없다는 이유로 반대한다.모든 기술적인 문제는 신경쓰지 마십시오.결연한 16:57, 2013년 11월 29일 (UTC)[응답]
NOTCensored 및 ChildProtect에 따른 강력한 지원.나는 위의 표에 반대하는 사람들 중 많은 수가 제안의 요점을 놓쳤다고 생각한다.이것은 잠재적으로 모욕적인 모든 단어들에 대해 사이트 전체의 검열을 부과하려는 제안이 아니다.이것은 불경한 꼴을 보고 싶지 않은 사람들을 위해 전적으로 선택 가능한 도구에 대한 제안이다(그러나 아마도 ChildProtect의 정신으로 자신을 미성년자로 식별하는 편집자들에게 권장되어야 할 것이다).이것은 나처럼 NOTCensored를 지지하는 모든 사람들에게 "위키피디아는 검열되어야 한다"는 끊임없는 제안의 헛소리로부터 쉽게 벗어날 수 있는 방법을 제공한다."아, 검열해야 한다고 생각하나? 괜찮아. 여기 위키피디아에 있는 모든 사람들은 너를 위해 검열을 받을 권리를 지지해. 당신이 해야 할 일은 Preferences → Gadgets → CroporMe 옆에 있는 박스에 가서 확인만 하면 된다. 그리고 모든 "나쁜 말"은 당신을 위해 블랙아웃될 수 있다. 행복한 편집!"뭐가 더 좋을까?기술 13 (대화) 2013년 11월 29일 17:24 (UTC)[응답]

위키피디아를 편집하거나 읽을 수 있을 만큼 나이가 많은 아이는 생각나지 않는다.그리고 누가 그들을 위해 그것을 켤 것인가?하지만 당신은 누가 어떤 단어를 결정하느냐의 핵심을 놓친다.나는 '도망'을 찾아볼 수 없는 학교 여과 시스템을 사용했던 것을 기억한다.빌어먹을, 포드 자동차였어! (하나를 구해서 문제에 대한 정보를 원했어.)'cock'을 막으십니까?영국에서는 보통 수탉과 암탉에 대해 이야기하지 않는다.'프릭'을 막느냐 - 샤일록 : "나를 찌르면 피가 안 나나? (그 문장 부위가 좋아...)누구의 편견이 차단 기준이 되는가?페리돈 (토크) 2013년 11월 29일 (UTC) 17:37 [응답]

각 언어 그룹이 어떤 단어가 그들의 문화에서 나쁜지 결정하게 하는 것은 어떨까?우리는 여기서 기술적 문제에 대해 이야기하고 있으며, 만약 그것이 각 지역사이에 대해 상당히 정확한 곳에서 이루어질 수 있다면, 기술적인 문제는 그다지 큰 문제가 되지 않는다.기술 13 (대화) 2013년 11월 29일 18:15 (UTC)[응답]

그래서 영국의 한 미국인은 'ass'를 막을 수 없을 것이다. 왜냐하면 이 곳은 그저 허풍스러운 곳이기 때문이다.아니면 '영어'가 단일 언어집단이 되는 것일까?(그럼 노새를 얻기 위해 말과 함께 건너가는 것은 무엇일까?)'나쁜 말'의 수준은 다르다.생각할 수 있는 어떤 것에 대해서도 불쾌하지 않지만, 특정 장소에서는 특정 단어를 사용하지 않고 특정 관객에게 특정 농담을 하지 않는다.'나쁜 말' 등에 대한 소동이 많은 것은 주목받는 사람들이 만든다.때때로 그것은 부메랑이다 - 나는 메리 화이트하우스가 어떤 잡지가 그녀의 이름을 따서 명명된 것을 별로 달가워하지 않았다고 확신한다.위에서 물어본 바와 같이, 누구의 편견들이 리스트에 올라가고 있는가?우리는 그것에 대해 공개적인 토론을 해야 할까? 아니면 비밀 위원회에 그것을 넘겨야 할까?아니면 검열관을 임명할 것인가?위에 있는 Theopolisme이 올린 링크를 봐.정말 좋다.페리돈 (토크) 2013년 11월 29일 (UTC) 18:56 [응답]

페리돈, 나는 영국에 있는 미국인이 그들의 언어로 Preferences → User profile → Internationalization/Language = enGB를 선택할 것이라고 생각하지 않아, 그렇지?나는 mw 이상 보고 있다.매뉴얼:인터페이스/JavaScript#wgPageContentLanguage는 잘못된 변수일 수 있지만, 각 사용자의 선택된 언어는 최악의 경우 api에서 끌어낼 수 있다는 것을 알고 있으며, 그것 때문에 너무 작은 대기열이기 때문에 원하는 사람들에게는 어떤 것도 해치지 않을 것이다.기술 13 (대화) 16:08, 2013년 12월 2일 (UTC)[응답]

내가 말하고자 하는 요점은 잠재적으로 불쾌한 단어들의 목록이 크다는 것이다 - 그리고 그것들 모두가 하나의 의미 단어인 것은 아니다.미국인에게 있어 엉덩이는 그가 앉아 있는 것이다.영국인도 당나귀를 가지고 있다면 엉덩이에 앉을 수 있다.그럼 엉덩이가 리스트에 올라야 하는거야?I Love Little Pussy 같은 기사는 어때?이제 검열관이 한 명 있는데...누가 리스트를 작성할 것인가?아무도 그들이 이것이 어떻게 이루어져야 한다고 생각하는지에 대해 지금까지 어떤 암시도 하지 않는 것 같다.나는 누가 고양이에게 종을 울릴지 알고 싶다.페리돈 (토크) 2013년 12월 2일 (UTC) 16:24 [응답]

내가 말하고자 하는 요점은 다른 목록(즉, /언어/en 및 /언어/en-GB)이 있을 것이고 "ass"는 /언어/en-GB 목록에 있는지 여부에 대한 부담이 없는 /언어/en 목록에 있을 수도 있고 없을 수도 있다는 것이다."공식" 목록은 물론 연방 통신 위원회 또는 방송 광고 허가 센터 지침과 같은 각각의 가이드라인 목록에 기재될 것이다.그런 다음 사용자는 Twinkle uses with twinkleprefs.js와 같은 사용자 구성 페이지의 개인 목록에 추가하도록 선택할 수 있다.기술 13 (대화) 19:47, 2013년 12월 2일 (UTC)[응답]

명기한 대로 반대하다.자신이나 다른 사람이 자신의 공통으로 설치할 수 있는 사용자 스크립트를 작성하는 모든 사용자를 지원하십시오.js 커뮤니티가 이를 지원하기 위해 전반적으로 어떤 것도 요구하지 않는 한(참고 나는 이 스크립트를 커뮤니티가 기본적으로 지원하는 단어 포함에 대한 논쟁을 야기할 수 있으므로 커뮤니티가 대규모로 지원하는 것으로 간주한다).에 대해 합의를 보다아노미에 17:27, 2013년 11월 29일 (UTC)[응답]
- 그래, 그래서 난 도전을 받아들이고 잠재적으로 모욕적인 단어들을 차단할 대본을 만들기로 했어.이 단어는 단어 목록에서 매우 공격적이며(허위 부정어를 최소화하기 위해) 구성할 수 없다는 점에 유의하십시오.사용 지침:아노미/검열.Anomie november 19:29, 2013년 11월 29일 (UTC)[응답]
  - 하! --Atlasawa (대화)20:06, 2013년 11월 29일 (UTC)[응답]
  - 사용자:애노미:사이드바도 필터링되지 않는 이유"도구"라는 단어는 나를 매우 불쾌하게 한다.정말 시시한 대본이야.Ke decemberr 21:14, 2013년 12월 2일 (UTC)[응답]
    - 미디어위키 인터페이스에서 사람들이 불쾌해한다면, 그들이 만족할 가망은 거의 없기 때문이다.Anomie december 22:14, 2013년 12월 2일 (UTC)[응답]
순수한 정치적 올바름으로 반대하라.이것은 스쿤토프의 인터넷 검열이다.어떤 것들은 불쾌하고, 그렇다. 그리고 사용되어서는 안 된다. 만약 그것들이 (예를 들어) 방향을 바꾸었다면, 그들은 여기에 있어서는 안 된다. 하지만 G_d를 타이핑하고 무함마드에 대해 화가 나면서 평생을 보내면서, 그리고 솜털이 많은 토끼들이 피해를 당하는 것을 보고 싶지 않은 것은, 음, 음, 솜털이 보송보송보송보송보송보송보송보송보송보송보송보송보송보송보송보송보송보송보송한 것이다.Fiddle Faddle 18:40, 2013년 11월 29일 (UTC)[응답]
Teopolisme의 훌륭한 링크에 반대하라 - 우리가 집단적으로 그것을 하고 싶었더라도, 모든 사람들에게 그들 자신의 단어 목록을 만들고 선택하도록 요구하지 않는 한, 그것을 잘 하는 것은 불가능하다. (페리돈이 지적하는 것처럼) 우리가 다소 씁쓸하게 재미있을 것이다. ("이 거대한 잠재적으로 모욕적인 단어 목록을 읽어달라"에서처럼)–Quiddity (대화) 21:19, 2013년 11월 29일 (UTC)[응답]
푸크, 씨발, 씨발, 씨발, 씨발, 씨발, 씨발, 씨발, 씨발.피터 제임스 (대화) 01:28, 2013년 11월 30일 (UTC)[응답]
반대 ....정말 구식이야! WP에 따르면:NOTCensored -Davey2010Talk! 01:45, 2013년 11월 30일 (UTC)[응답]
위의 Anthonyhcole과 Technical 13에 따라 어느 정도 지원하십시오. 그리고 프로토타입을 개발한 아노미에게 감사드리며, 나는 이 프로토타입을 Signpost나 다른 곳에 공개하고 싶고, 좀 더 구성 가능한 프로토타입을 희망한다.나는 그것을 사용하고자 하는 사람들이 사용할 수 있는 일종의 추가 기능의 사용을 요청하지 않을 이유가 없다고 본다.나 자신은, 거의 확실히, 어떤 상황에서도 그것을 사용하지 않을 것이다, 왜냐하면 솔직히 주제에 극히 중요한 어떤 직접 인용문은 그러한 언어를 포함할 것이기 때문이다.그러나 우리는 모든 사람들에게 무료 백과사전이 되고 심지어 기사에서 특정 단어를 보는 것에 반대할 광적인 이념가들이 될 것이다.또한, 솔직히, 나는 어떤 학회나 공공 와이파이 서비스와 같은 인터넷 서버가 특정 유형의 콘텐츠를 특정 단어나 이미지로 차단하는 것을 본 적이 있다. 예를 들어, 한 대학생이 나에게 대학 컴퓨터에서 접근할 수 없다고 말한 어떤 나라의 성적 학대에 관한 한 기사처럼 말이다.그리고 나는 특정 편집자나 독자들이 콘텐츠에 접근하는 것을 효과적으로 차단하는 것이 어떤 사람에게 이익이 되는지 알 수 없다. 왜냐하면 우리는 일부 사람들이 의심스러운 언어로 여기는 것을 포함하기를 원하기 때문이다.또한, 그러한 추가 기능이 개발된다면, 그것은 그러한 서버에 의해 가장 "차단할 수 있는" 단어들 중 어떤 것이 필수적이지 않을 수 있는 단어를 결정하는 도구로서 유용할 수 있으며, 그것을 아는 것은 도서관이나 다른 곳에서 우리에게 접근할 수 있는 사람들을 포함하여, 우리의 모든 콘텐츠를 필요로 하는 사람들이 이용할 수 있도록 하는 데 도움이 될 것이다.ch는 그러한 차단 메커니즘을 가지고 있으며, 심지어 대학의 서비스에 의존하는 일부 대학생들도 그들에게 학문적으로나 개인적으로 중요할 수 있는 기사에 접근하는 것을 불가능하게 할 수 있다.물론, 개별 단어 목록은 다른 어떤 것 보다 더 재미있을 것이고, 내가 말했듯이, 내가 직접 단어를 사용하는 것은 상상할 수 없지만, 그것은 궁극적으로 우리의 모든 콘텐츠를 사용하기를 원하는 모든 사람들이 쉽게 이용할 수 있도록 만들 수 있을 것이다.존 카터 (대화) 00:52, 2013년 12월 2일 (UTC)[응답]

"...시제품 개발에 아노미에게 고맙다는 말을 전하는데, 이 말이 사인포스트나 다른 곳에서 널리 알려졌으면 좋겠다는 생각이 든다."이게 나를 LOL로 만들었다.대본을 설치하면 왜 그런지 알 수 있을 것 같은데...Theopolisme (대화) 12:09, 2013년 12월 2일 (UTC)[응답]

내가 아노미(Anomie)를 믿지 않는 것은 아니지만, 여기 있는 몇몇 사람들이 생각하는 대로 되지 않는 그 대본이 아닌가 의심했다… 8-) 페리돈(토크) 16:43, 2013년 12월 2일 (UTC)[응답]

사람들이 뭐라고 생각할지 모르겠지만, 사용자:아노미/검열은 그것이 무엇을 하는지 정확하게 설명한다.;) Anomie ⚔ 22:14, 2013년 12월 2일 (UTC)[응답]

다른 유용한 기능들이 많이 밀려있을 때 개발자들의 시간을 낭비하는 것을 반대한다.그것을 사용하는 소수의 PC 강경파들은 단순히 브라우저 확장을 사용할 수 있다. --_{Piotr Konieczny aka Prokonsul Piotrus reply here} 2013년 12월 2일 (UTC)[응답]
사용자 스크립트 작성은 모든 사용자가 할 수 있다.미디어위키 개발자 시간이 필요 없다.그러나 설사 그렇다 하더라도 대부분의 미디어위키 개발사는 자원 봉사자들이며 WP에 허용된다.대부분의 편집자가 원하는 기사를 자원봉사를 할 수 있는 것처럼, 자신이 원하는 프로젝트에 자원봉사를 하거나 하지 않는 것이 허용된다.WhatamIdoing (talk) 19:20, 2013년 12월 2일 (UTC)[응답]

메 - 내가 NOTCENSORED의 원칙을 지지하지만, 일부 학교에서는 위키백과가 부적절한 이미지와 언어, 그리고 그렇지 않은 것이 있는 것처럼 보여지는 것을 허용하지 않을 가능성이 높다는 점을 유의해야 한다.학교가 구현할 수 있는 (위로는 10대 남학생이 거의 필터를 켜지 않을 것) 메커니즘이 있다면, 그것이 유리할 수 있지만, 원칙적으로는 NOTCensored를 지지한다.Go Phightins! 2013년 12월 2일(UTC) 22시 39분 답변
관련 정책 및 관련 지침은 "원래 위키백과 내용에서 천박함이나 외설스러움은 완전한 형태로 나타나거나 전혀 나타나지 않아야 하며, 단어는 절대 대시, 별표 또는 다른 기호로 대체하여 활달하게 해서는 안 된다"고 분명히 말할 수 없다.그것은 빈 글자나 단어를 포함할 것이다.내용 은폐에 도움이 되는 보조 도구/도구/가젯은 WP 내에 제공되어서는 안 된다.정책에 이의를 제기하려면 관련 정책 페이지에서 논의하십시오.필자는 몇 명의 기고자들이 필요한 정책 수정안을 확보하기 전에 이 제안의 실용성을 논의하는데 있어서 아주 작은 말 앞에 아주 큰 수레를 놓고 있는 것 같다.누수 솥 23:04, 2013년 12월 2일 (UTC)[응답]
- 글쎄, 그것은 거의 문제가 되지 않는다: 그것은 정책 이슈와 상관없이 기술적으로 전혀 실현 가능하지 않다.더구나 그것을 기기로 하는 것은 그것이 검열하는 것과 그렇지 않은 것에 관해서 어느 정도 합리적인 기능을 유지하는 공동체에 도덕적 책임을 지게 될 것이고, 만일 역사가 어떤 재판관이라면, 그 공동체가 그런 것에 대해 어떤 종류의 합의에도 도달할 수 있는 고드름의 기회는 지옥에서 없을 것이다(기타).아무 것도 검열하지 않는다는 현재의 합의를 검토하다.그래서 그것은 무트 포인트다.이 섹션이 아직 열려 있을 이유가 없어, 솔직히 말해서 우리가 원한다고 해도 할 일이 없어.2013년 12월 2일 (UTC) 23:10, Writ Keeper[응답]
위키피디아가 검열되지 않고, 이를 위해 사용할 수 있는 많은 도구, 모든 페이지에 대한 브라우저 "FoxReplace"용 플러그인, 전체 웹 사이트[3]용 도구 및 컨텐츠 제어 소프트웨어에 대한 도구들이 있다.당신의 말이 검열되길 원한다면, 단지 어떤 나라가 당신을 위해 그것을 하는지 찾아보고 거기서 대리인으로 로그인하면 된다.미온(토크) 23:36, 2013년 12월 2일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

업로드 시 워터마크 정보

어떤 사람들은 이미지에서 워터마크를 제거하는데 많은 시간을 소비하는데, 그것은 때때로 매우 어려울 수 있다. 그래서 나는 제안이 있다.
-업로드 시 이미 정책 Watermark 정책에 대한 명확한 정보를 얻을 수 없을까.
이것은 나중에 편집해야 할 이미지 양을 줄일 수 있을 것이고 우리는 그 시간을 여기서 좀 더 유용한 것을 하기 위해 쓸 수 있을 것이다.고란 tek-en (대화) 09:58, 2013년 12월 2일 (UTC)[응답]

업로드 과정에서 사용자에게 우리가 가지고 있는 모든 5000개의 규칙을 알려주는 것은 좋은 시스템이나 작업 시스템이 되지 않는다.규칙을 만든다는 것은 규칙 후에 정리를 해야 한다는 것을 의미한다: (시간 낭비라고 보지 말고, 최고의 양질의 콘텐츠를 얻기 위한 투자 시간으로 보아라.—DJ (대화 • 기여) 11:02, 2013년 12월 2일 (UTC)[응답]

나는 네가 그들에게 모든 것을 말할 수 없다는 것을 이해하지만 아마도 가장 많은 시간을 소비하는 것 중 몇 가지를 말할 수 있다는 것을 이해한다. 하지만 나는 네가 이것에 대해 전에 또는 비슷한 것에 대해 논의했다고 생각한다. 고마워.— 고란 tek-en (대화) 12:07, 2013년 12월 2일 (UTC)[응답]

오늘의 특집 기사 사전 보호에 관한 RfC

Wikipedia_talk:오늘의_featured_기사#Is_it_time_to_revisit_the_protection_status_of_the_general_featured_on_the_main_page.3F. 라마수드2000 19:37, 2013년 12월 3일 (UTC)[응답]

위키백과 네임스페이스의 모든 페이지 반보호

다음의 논의는 종결되었다.수정하지 마십시오.후속 코멘트는 새로운 섹션으로 작성되어야 한다. 도달한 결론의 요약은 다음과 같다.

합의는 이 생각에 크게 반대한다.스벤망구아르드화?18:50, 2013년 12월 4일 (UTC)[응답]

헤드라인에서 알 수 있듯이, 나는 "위키피디아"로 시작하는 모든 페이지와 콜론이 뒤따르는 모든 페이지는 편집으로부터 영구적으로 반보호될 것을 제안한다.(이 제안서는 게시판과 이와 같은 페이지를 포함하지 않을 것이다. 이 제안은 공신력 지침과 같은 정책 페이지에만 해당된다.) 왜인가?이유: 1.신규 사용자나 등록되지 않은 사용자가 이러한 페이지를 편집해야 할 이유는 없다. 그들은 아마도 이러한 페이지를 구조적으로 이해할 수 없을 것이기 때문이다. 2.그러나, 예를 들어, 금지된 사용자 목록에서 자신을 삭제하거나, 관리자가 얼마나 사악하고 무정한지, WP:Administrators 및 3에 대한 기여에 대해 불평하는 등, 그들이 이러한 페이지를 파괴하고 싶어하는 주요 이유가 있다.내가 방금 말한 두 가지를 포함해 이미 반보호된 경우가 많기 때문에 특별히 급격한 변화는 아닐 것이다.나는 내가 이 아이디어를 처음 제안하는 것은 아니지만, 그럼에도 불구하고 좋은 아이디어라고 자신하며, 다른 편집자들이 동의하는지 보고 싶었다.진킨슨은 나에게 2013년 11월 15일 05:26 (UTC)[응답하라]

등록은 요건이 아니다.실제로 일반 사용자인 데다 정책과 절차에 정통하지만 어떤 이유로든 등록을 하지 않기로 한 미등록 사용자도 있다.Mr.Z-man 05:45, 2013년 11월 15일 (UTC)[응답]

위키백과 공간에 정기적으로 기고하는 등록되지 않은 사용자들이 많이 있다.'(예를 들어 RfA와 같이) 투표할 수 없는 몇몇 장소를 제외하고, 그들의 의견은 등록한 사용자들의 의견만큼 환영받는다.이와 같은 제한을 가하는 것은 WP에 엄청난 관료적 과부하를 초래할 것이다.ERQ. Kudpyung ผผ้ ( ( ( ( ((토크) 06:20, 2013년 11월 15일 (UTC)[응답]
일반적으로 페이지가 사전에 보호되지 않는다는 생각을 정면으로 반박하는 것은 물론, 이것이 커뮤니티고, 계정 등록이 필요 없다는 원칙에 반하는 것이기 때문에 나는 이 아이디어를 지지할 수 없을 것이다.보호는 항상 사례별로 사용해야 한다.비블브록스 (대화) 19:52, 2013년 11월 15일 (UTC)[응답]
원칙에 반대하다.이것은 나에게 문제를 찾기 위한 해결책인 것 같다.기술 13 (대화) 17:32, 2013년 11월 17일 (UTC)[응답]
반대 – 관리자 게시판에서 보고서를 작성하는 것은?IP가 편집되기를 기대한다면, 관리자(admin)가 필요한 문제에 직면했을 때 도움을 받을 수 있는 방법을 제공해야 한다.WP:ANI 및 WP:A3는 둘 다 위키피디아 공간에 있다.에드존스턴 (대화) 23:07, 2013년 11월 21일 (UTC)[응답]
사실이야. 하지만 에드존스턴, 내 원래 제안을 읽으면 내가 WP와 같은 게시판에 대한 예외를 포함했다는 걸 알게 될 거야.AN. WP:ANI 등.이 제안서는 주로 WP:Administrators와 같은 정책 페이지와 WP와 같은 새로운 사용자에게 지시하기 위한 페이지에 적용된다.첫 번째 기사 및 WP:스타일 매뉴얼뿐만 아니라 더 좋은 기사를 쓰는 것.진킨슨은 2013년 11월 23일 04:19, 나에게 이야기한다[응답하라]
m당 강한 반대:건국 원칙.T13이 말했듯이, 이것은 문제를 찾기 위한 해결책처럼 보인다.레곡™ (대화) 05:12, 2013년 11월 23일 (UTC)[응답]
반대 프로젝트 페이지는 다른 페이지와 다르지 않다.필요할 때만 보호하라.--Jasper Dung (대화) 22:23, 2013년 11월 23일 (UTC)[응답하라]
도덕적 지원, 왜냐하면 나는 사용자 등록을 요구하는 것에 찬성하기 때문이고, 이러한 종류의 제안은 그러한 (대중적이고 비인기적인) 행동에 해당될 것이다.Binksternet (talk) 23:56, 2013년 11월 23일 (UTC)[응답하라]
지지, 내가 후회하는 이유들로 나는 분명하게 말할 시간이 없었다.익명의 편집 허용은 이익이 과장될 가능성이 높은 신성한 소로 보이며, 우리를 공동체로 만드는 것을 보호해야 한다는 것이 기본 논거일 것이다. ~ J. Johnson (JJ ) (토크) 22:03, 2013년 11월 24일 (UTC)[응답]
IP는 종종 가치 있는 기여자로서, 그리고 IP 입력을 필요로 하는 알림판 때문에 반대한다. WP:예를 들어 ANI.로스 힐 (토크) 22:37, 2013년 11월 24일 (UTC)

IP 편집이 모두 나쁘다고 주장하는 사람은 없다.그러나 1) "좋은" IP 편집은 나쁜 IP 편집을 억제하는 데 시간과 에너지를 소비해야 하는 등록된 편집자들이 하지 않은 모든 가치 있는 기여를 할 가치가 있는가?2) IP 편집자들이 왜 등록 편집자로서 가치 있는 기여를 할 수 없는가(또는 원하지 않는가)? ~ J. Johnson (JJ) (토크) 23:13, 2013년 11월 25일 (UTC)[응답]

미안하지만, IP 편집이 그 반대의 경우를 증명하기 위해 내 것이 아니라, IP 편집의 가치가 3초라는 것을 증명하는 것이 제안자로서 너의 일이다.참고 항목: 입증 책임. -- Ross Hill • Talk • 도움 필요?• 2013년 11월 27일 00:30[응답]

문제는, 만약 우리가 등록되지 않은 사용자들의 편집을 막음으로써 많은 공공 기물 파손을 막을 수 있다면, 우리는 왜 그렇게 하지 않을까?계정을 만들기에는 너무 게으르지만, 수천 개의 건설적인 편집을 하기에는 너무 게으르지 않은 수많은 도움이 되는 IP들 때문에?나는 그런 사람들이 존재하는지조차 확신할 수 없다.우리가 반달리즘적이거나 비파괴적인 편집만 되돌릴 수 있다는 것은 큰 문제가 되지 않을지도 모르지만, 그 반달리즘은 인터넷에서 가장 인기 있는 10대 웹사이트의 방문자들에 의해 그들의 반달리즘을 보게 되었다.그러므로, 나는 IP 편집이 허용할 가치가 없다고 생각한다. 왜냐하면 반달리즘의 97%는 그것들로부터 나오기 때문이다.Jinkinsontalk to me 16:18, 2013년 11월 27일 (UTC)[응답하라]

그러나 IP 편집의 50% 미만이 공공 기물 파손이다.Thryduulf (대화) 22:29, 2013년 12월 1일 (UTC)[응답하라]

스노우 클로즈.이것은 합의점을 얻지 못할 것이다. -- 로스 힐 • 대화 • 도움이 필요하십니까?• 2013년 12월 1일 (UTC) 23:29, 회신[응답]

절대 아니다.예를 들어 IP가 공공 기물 파손 행위를 보고하는 방법은 무엇인가?WP의 경우:AFC/R? 둘 다 게시판도 아니고 이런 페이지도 아니야.나이튼드 (대화) 01:48, 2013년 11월 30일 (UTC)[응답]
매우 강하게 반대한다.위키백과의 공간 페이지에 대한 대부분의 IP 편집은 건설적이므로 특별한 문제가 없는 한(예: WP:NOT) 그러면 나머지 백과사전 IP와 마찬가지로 편집할 수 있어야 한다.이것은 근본적인 원칙이므로 가볍게 바뀌면 안 된다.Thryduulf (대화) 22:29, 2013년 12월 1일 (UTC)[응답하라]
반대한다. 경험이 부족한 사용자들은 독특한 관점을 가지고 있고 다른 noobs들이 이해할 수 있는 단어로 철자를 쓰는 면에서 기존의 편집자들이 할 수 있는 것보다 문서와 정책 페이지를 더 잘 편집할 수 있다.또는 때로는 정확하지 않은 편집이 새로운 사용자로부터 나타나 적어도 새로운 사용자에게 불명확한 내용을 알려줌으로써 간접적으로 개선의 결과를 가져올 것이다.이것은 아마도 충분한 이유인 모든 원칙을 무시하는 것이다.나는 사실 모든 템플릿이 일반적으로 백과사전의 일부인지 아니면 더 많은 인터페이스의 일부인지에 대해 논쟁의 여지가 있기 때문에, 새로운 사용자들은 그것들을 훨씬 더 드물게 편집해야 하며, 평균 템플릿은 일반적인 위키백과 페이지만큼 관찰되지 않는다.그러나 그것은 전체 원칙("누구나 편집할 수 있다") 때문에 이것보다 통과 가능성이 아주 조금 더 높다.equazcion → 23:38, 2013년 12월 1일 (UTC)

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

WebCite가 다운될 수 있음

WebCite는 48000개 이상의 기사와 7000개 프로젝트 페이지에 사용된다.그들은 내년에 새로운 출품작의 접수를 중단할 수도 있다고 발표했는데, 이것은 영구적으로 폐업으로 이어질 수도 있다.어떻게 해야 할지 잘 몰라서 몇 가지 의견을 내놓고 토론하고 있다.

위키피디아 사람들에게 알리십시오.특히 나처럼 웹을 인용할 때 일상적으로 WebCite를 사용하는 사람들은 관심이 있을 것이다.
기금모금자 돕기
- 페이지에 현수막을 내걸어라.
- WMF에 물어봐, 그들은 기꺼이 공유하려고 할지도 몰라.
WebCite를 archive.org으로 변환하는 프로젝트/봇이 인용된다.
우리만의 아카이빙 프로젝트?
아무것도 하지 말고 나중에 그것에 대해 불평해라.

안녕하십니까, Paradoctor (talk) 18:28, 2013년 11월 23일 (UTC)[응답]

음, 바로 이 문제에 대한 논의는 적어도 2월 이후부터 꾸준히 진행되어 왔다.Chris857 (대화) 23:03, 2013년 11월 23일 (UTC)[응답]

고마워. Paradoctor (대화) 00:33, 2013년 11월 24일 (UTC)[응답]

archive.org은 웹 사이트보다 못하다. 내가 주목한 두 가지는 archive.org이 모든 캡처를 로봇들이 즉시 사용할 수 없게 만든다는 것이다.txt가 말하길, 쿠키를 잘 다루지 못한다.Josh Parris 23:16, 2013년 11월 24일 (UTC)[응답]

나는 쿠키가 없으면 잘 대처하지 못한다.미안, 그 농담의 기회를 놓칠 수가 없었어.카멜빈키 (대화) 21:26, 2013년 11월 27일 (UTC)[응답]

웹캐이트를 죽게 내버려두는 것은 큰 실수일 것이다.그것은 분명히 같은 URL에서 정기적으로 업데이트되는 순위, 점수판, 기후 통계 및 기타 데이터에 유용하다.특히 글의 주제가 출처를 통제하고 이를 변경하거나 제거하는 데 기득권이 있을 수 있는 경우, 살아 있는 사람과 소송 당사자들에 대한 논란이 있는 주장을 소싱하는 데도 가치가 있다.거의 모든 {{cite 웹} 및 웹 기반 {{cite 뉴스} 참조에 대해 봇이 호출하여 정확한 버전의 소스가 자동으로 캡처되도록 해야 한다. - 포인트릴리스트(토크) 12:17, 2013년 12월 3일(UTC)[응답]

정말 그럴 것이다.그리고 우리는 어떤 대안이 있을까?archive.is과 같은 잠재적으로 블랙리스트에 오를 수 있는 사이트?한숨. Wbm1058 (대화) 16:31, 2013년 12월 5일 (UTC)[응답하라]

사전 RfA 피드백 페이지

우리가 모두 알고 있듯이, 현재 RfA 시스템에 문제가 있다.내가 주목한 두 가지 주요 쟁점은 다음과 같다.

사람들은 거절을 두려워하고 지원하지 않는다.
사람들은 곧 지원하게 된다.NOTNOW), 거절당하면 다시 지원을 망설이게 된다.

내가 이것을 해결할 수 있다고 느끼는 한 가지 방법은 RfA 전 페이지를 만드는 것이다.편집자는 사용자가 결과 없이 피드백을 제공할 수 있는 'mock RfA'를 거의 실행할 수 있다.편집자가 '통과'하면 실제 RfA에 출마할 수 있고, '실패'하면 관리직에 출마하기 전에 개선 사항을 알 수 있다.

많은 사람들이 과거에 미래의 RfA에 대해 실패한 RfA를 보유하고 있지만, 이 사전 RfA는 단순히 피드백을 찾는 사용자로서 동일한 영향을 미치지는 않을 것이다.또 사용자가 이를 통과할 수 있다면 다른 편집자의 지지가 이미 있다는 것을 사용자가 보여줄 수 있어 자체 지명의 오명을 벗을 수도 있다.

물론, 모든 편집자들이 이것을 하기를 원하는 것은 아니며 그것이 RfA의 전제조건이 되어서는 안 된다.전통적인 루트는 여전히 이용 가능하지만 이것은 RfA에 들어갈 생각을 하지 않는 편집자들을 격려하는 데 도움이 될 것이다.Oddbodz - (Talk) (Contribs) 14:09, 2013년 11월 24일 (UTC)[응답]

WP:ER을 참조하십시오.그곳의 편집자들은 누가 RfA를 고려하고 있는지 재검토를 요청한다.나는 우리가 RfA 전 목적을 위한 전용 전문가 영역은 필요하지 않다고 생각한다.예비 후보자가 RfA에서 사용 가능한 자료의 질량을 읽지 않았거나, 주요 RfA 페이지를 통해 최근 합격 및 불합격 후보들과 비교했거나, 다른 편집자들로부터 일대일 피드백을 받은 경우, 적합성에 의문을 제기해야 한다.드레스 리허설에는 별로 관심이 없어.누수 솥 2013년 11월 24일 (UTC) 14:39, 응답

WP:ER. 아마도 우리는 한 달 넘게 응답을 받지 못한 채 많은 요청이 있기 때문에 그것을 더 널리 알릴 수 있을 것이다.Oddbodz - (Talk) (Contribs) 15:03, 2013년 11월 24일 (UTC)[응답]

네, WP:ER은 단지 관리자 희망 이상의 목적을 위한 것이지만, 그러한 목적을 위해 봉사한다.위키피디아(WP:AfC는 또 다른 과정, IIRC)에서 관리자가 필요로 하지 않는 대부분의 과정처럼, 그것은 끔찍하게 뒤처져 지금은 거의 무용지물이다.RfA 전문 페이지가 유용할 것 같진 않은데, 방문자가 더 적어질 거야.안sh666 23:08, 2013년 11월 24일 (UTC)[응답]

RfA 문제에 대한 새로운 솔루션을 기꺼이 시도해 볼 수 있도록 지원하십시오.내가 알기로는, 당신은 합의된 승인 없이 위키프로젝트를 시작할 수 있고, 만약 그것이 실행된다면, 적어도 그것을 원점에서 벗어나기 위해 기꺼이 도울 수 있을 것이다.ER에 대해서는, 여기서 유용할 정도로 효과적이라고 생각하지 않는다(개인 경험으로 말하면, 나 자신을 위해 Editor Review를 개설한 적이 있는데, 피드백을 받기 전에 거의 한 달 동안 열려 있었다).AutomaticStrikeout(자동 스트라이크아웃) – Rest in Peace, Jackson Peebles 15:53, 2013년 11월 25일(UTC)[응답]

AutomaticStrikeout, 그것은 아이디어다. 나는 위키프로젝트의 가능성에 대해 생각해 본 적이 없다.사용자:에서 초안 페이지를 작성한 경우:Oddbodz/Wiki Project 관리자 모집을 하고 어디로 가는지 알아보겠다.만약 당신이 그것의 개발을 돕고 싶다면, 그것은 매우 좋을 것이다.다른 지역사회가 어떻게 생각하는지 보고 싶다.Oddbodz - (Talk) (Contribs) 22:59, 2013년 11월 25일 (UTC)[응답]

나는 위키피디아 주제에 대해 생각해 보았고, 여기서 하나를 제안했다.관심이 얼마나 적은지 놀랐지만, 여전히 그런 조직적인 접근 없이는 의미 있는 개혁의 희망이 없다고 생각한다.--S 필브릭 (Talk) 17:06, 2013년 11월 27일 (UTC)[응답]

내 생각에, 네가 제안한 위키피디아 주제의 범위가 너무 좁다.하지만 이미 멤버가 한 명인데 내가 한 명 없어서 틀렸을지도 몰라.--S 필브릭 (Talk) 17:10, 2013년 11월 27일 (UTC)[응답]

필요성 여부를 떠나 새로운 위키프로젝트를 고민할 경우 정식 제안서를 작성하는 것이 일반적으로 바람직하다는 것을 알게 되었다. --Trevj (대화) 15:23, 2013년 11월 28일 (UTC)[응답]

WP:ER은 이미 충분히 목적을 달성했지만 더 많은 노출을 필요로 한다.쿠드풍 กุผึ ( ((대화) 01:29, 2013년 11월 28일 (UTC)[응답]
몇 년 전 영국 정부는 교육의 질이 평가되기를 원했다.그래서 그들은 선생님들이 얼마나 잘 하고 있는지 보기 위해 SATS 시험을 도입했다.무슨 일입니까?대부분의 선생님들은 아이들에게 시험을 '합격'하라고 가르쳤고, 부모들은 아이들에게 시험을 통과하도록 압력을 가했다.아이들은 스트레스를 받았다.선생님들은 스트레스를 받았다.그래도 그렇긴 한데, 내 생각엔 그들이 그걸 없애버릴 것 같아.그리고 연습에서 어떤 유효한 정보도 나오지 않았다.RfA 이전의 '시험'도 비슷한 문제를 겪게 될 것이다.자동차 시험(MOT)과 달리, RfA는 특정한 예 혹은 지금 체크 박스에 대한 문제가 아니다.MOT 전 검사를 통해 오류를 방지할 수 있다.사전 RfA는 곧 정보의 출처가 되기 보다는 통과될 예비 시험으로 간주될 것이다.RfA 자체에서, 사람들은 "응, 그들은 통과했어, 우리는 그들을 위해 투표할거야"라고 말할 것이다.아니면 그들이 이미 지나갔기 때문에 굳이 오지 않아도 되겠지?페리돈 (토크) 2013년 11월 29일 14:53 (UTC)[응답]

나는 전적으로 페리돈에 동의한다.올바른 칼리브레이션의 새로운 관리자들이 필요하긴 하지만, 우리는 편집자들이 위키백과의 참여를 위한 그들의 주요 목표로 관리직을 설정하는 것을 피하고 싶다.우리는 예비 관리자들을 위한 충분한 조언 페이지 이상을 가지고 있고 그들은 가능한 한 많은 페이지로부터 연결된다. 그리고 만약 그들이 그것들을 읽는 것을 귀찮게 할 수 없다면, 그들은 실패하더라도 놀라지 말아야 한다.쿠드풍 กุผึ ((대화) 01:55, 2013년 12월 5일 (UTC)[응답]

대중들의 거절을 즐기는 사람은 누구인가?편집자 리뷰는 대중들의 잠재적인 거절을 위한 또 다른 포럼일 뿐이다.나는 이메일이나 채팅이 아마도 완전히 안전하고 사적인 것은 아니지만, 잠재적 후보가 성공할 수 있을지를 결정하기 위해 질문을 제기하는 더 좋은 방법이라고 생각한다.Wbm1058 (대화) 16:08, 2013년 12월 5일 (UTC)[응답]

위키백과에서 가능한 한 적은 실수를 하는 방법

기사 Sinc 함수에서 나는 아무도 눈치채거나 고치지 않고 수년간 지속되어 온 도입부의 명백한 실수를 보았다.sinc 함수의 정의는 $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ ( $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ ) $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ = $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ ( x $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ ) $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ $displaystyle \mathrm {sinc}(x)={\frac {\sin(x)}{x}\}\!}$ 라고 되어 있었지만 $\mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!$ , 0으로 나눌 수 없기 때문에 x = 0에 대해서는 그럴 수 없다.자신들을 더 나은 위키백과 편집자가 되도록 훈련시키고자 하는 모든 사람들을 위해, 온라인 위키백과 시험이 있어야 한다. 온라인 위키백과 시험은 이미 존재하는 기사에 기사를 더하고, 그 안에 오류가 있는 기사들을 시험하는 사람에게 보여주는 것이다. 그리고 시험을 하는 사람의 임무는 그들이 그러한 실수를 발견할 수 있는지 확인하는 것이다.s는 그들이 무엇이었는지 말하지 않고 그들 스스로에게 말한다.이러한 실수들이 시험 기간 동안 시험을 보는 사람에게만 기사의 외관을 바꾸어서는 안 된다.관리자들은 이미 존재하는 기사들을 가지고, 그들이 스스로 발견하는 능력을 시험하고, 의도적으로 실수를 더하고 사람들에게 통보하는 실수를 정확히 알고 있기 때문에, 가능한 한 자연적인 실수와 구별할 수 없는 실수에 어떤 유형의 실수를 덧붙여야 하는지를 생각하려고 노력해야 한다.위키백과 기사에서 실수를 더 잘 찾도록 훈련시키는 것을 그들이 놓친 실수를 시험한다.시험에서 우연히 그 기사를 받게 된 모든 사람에게 같은 실수를 추가해서는 안 된다.

나는 이 테스트가 더 이상 그런 실수가 없는, 특히 가장 알아보기 힘든, 오래된 버전의 기사에서 자연적인 실수를 찾아내는 능력을 테스트하는 것도 포함할 수 있다고 생각한다.좀 더 도전적으로 만들기 위해, 시험에 응시하는 일부 위키피디아 기사들은 어떤 실수가 있는지 확실히 모를 때 실수가 있는 기사에서 실수를 발견하기가 더 어렵기 때문에 그 기사에 아무 것도 없다는 말을 듣지 않고 시험을 보는 사람이 시험받는 실수는 없어야 한다.사람들이 때때로 발견에 대해 시험을 받아야 하는 또 다른 유형의 실수는 물리학이나 수학적 공식에 2가 빠져 있는 것이다.블랙밤추 (토크) 00:35, 2013년 12월 2일 (UTC)[응답]

음, 구체적으로 말하자면, 기사는 "두 경우 모두 0의 탈착 가능한 특이점에서의 함수의 값이 한계값 1로 이해된다."라고 언급하고 있다. 왜냐하면 죄(x)/x는 0에 가까워짐에 따라, 표현은 L'He becausepital의 규칙#예에서 볼 수 있듯이 1에 접근하기 때문이다.그래서, 나는 거기에 문제가 있다고 보지 않는다.* 나머지에 대한 코멘트 없음* Chris857 (토크) 02:36, 2013년 12월 2일 (UTC)[응답]

그들의 오류 감지 능력을 연구하기를 원하는 편집자들은 그저 실제 기사를 검토하고 보통 있는 오류를 찾으려고 노력할 수 있다.기사 사본에서 고의적으로 추가된 오류를 찾는 것은 일부 시험의 일부가 아닐 때 시간을 잘 활용하지 못하는 것처럼 들린다(나는 그러한 요구사항에 반대한다.프라임헌터 (대화) 03:17, 2013년 12월 2일 (UTC)[응답]

만약 이런 일련의 테스트가 만들어지면 편집자들이 편집 권한을 얻기 위해 그것들을 통과해야 한다는 것이 당신의 기대인가?만약 그렇다면, 그것은 어떤 근본적인 원칙에 직면하게 된다.--S Philbrick (Talk) 14:07, 2013년 12월 2일 (UTC)[응답]

아니, 그것은 그들 자신이 정말 훌륭한 편집자가 되기를 원하는 사람들을 위한 것이었다.편집 가능한 사람들의 수를 줄이는 것은 아마도 위키백과 기사들이 더 빨리 나아지지 않게 만들 것이다.한편, 보류 중인 변경이 승인될 때까지 애초에 변경이 이루어지지 않는 변경 보류라는 나의 이전의 제안을 따르는 것이 좋을지도 모른다.그 이유는, 그렇게 함으로써, 사람들은 그들이 원하는 대로 자유롭게 기사를 바꿀 수 있게 되었기 때문이다.그러한 변화 중 하나는 더 명확한 방법으로 정보를 표현하기 위해 전체 기사에 정보를 재배열하는 것일 수 있으며, 만약 그 사람이 정말로 훌륭한 영국 작가라면, 미결된 변화는 아마도 받아들여질 것이다.내가 사람들에게 편집하기 위해 그 시험을 통과하도록 요구하는 유일한 장점은 기사 전체를 재정렬하는 아주 큰 편집이 이루어질 수 있다는 것이다. 하지만 나는 그들이 정말 훌륭한 편집자가 되기로 선택한 사람들을 위한 선택적인 시험이라고 더 생각하고 있었다.블랙밤추 (토크) 14:52, 2013년 12월 2일 (UTC)[응답]

아마도 그 시험은 누구나 응시할 수 있어야 하고 사람들은 보류 중인 변경사항을 승인하거나 거부할 수 있는 힘을 갖도록 그것을 통과시켜야 한다.블랙밤추 (토크) 14:57, 2013년 12월 2일 (UTC)[응답]

벌써 이런 제안을 하지 않으셨나요?위키피디아를 편집하는데 필요한 외부 테스트는 절대 없을 것이다.— HELLKOWZ ▎토크 15:08, 2013년 12월 2일 (UTC)[응답]

위키백과의 모든 주제에 대한 기사를 편집할 수 있는 능력이 있는 편집자가 없기 때문에 그런 시험이 이루어질 수 있다고 해도 아무도 통과할 수 없었다.또한, 한정된 테스트를 만드는 것 조차도 매우 복잡하고 오류가 발생하기 쉬울 것이다. 기사에서 간단한 오류라도 고칠 수 있는 창의적인 방법이 많기 때문이다 —Anne Delong (talk) 15:33, 2013년 12월 2일 (UTC)[응답]

아마도 과목별 또는 과목의 특정 영역에 대해 별도의 유형의 시험이 있을 수 있다.정말 훌륭한 편집자가 되고 싶은 각자는 어떤 과목이 그 과목에서 실수를 알아채는 능력을 시험하는 시험을 가장 잘 볼 수 있는지 추측할 수 있다.예를 들어, 수학 전문가는 모든 쌍둥이 소수점이 그 형태(6n - 1, 6n + 1)가 아닐 때(6n - 1, 6n + 1)라고 기술하는 것과 같은 수학 실수를 알아차리는 시험을 선택할 수 있으며, 영어 전문가는 더 명확한 방법으로 정보를 표현하기 위해 기사의 정보를 재정렬하는 능력을 시험하는 시험을 볼 수 있다.기사에서 언급하고 있는 잘 알려지지 않은 용어의 정의를 제시한다.블랙밤추 (토크) 2013년 12월 2일 (UTC) 16:23[응답]

어떤 면에서는 좋은 생각 같지만...Dendrocnide photinophyella에서 History 페이지와 편집을 위한 diff를 보십시오.나는 자격 있는 식물학자나 호주의 거주자가 아니다.이 나무들 중 한 그루도 본 적이 없어.하지만 나는 영어에 꽤 능숙하다.그러니 기사 주제에 대한 자격 부족을 통해 이 기사를 편집하는 것이 금지되어야 하는가?나는 열대 파충류에 관한 출판물의 영어판과 독일판 모두에서 실수를 발견했다.나는 파충류에 대해 아무것도 몰랐고, 독일어를 뛰어난 것으로 여기지 않았지만, 작가들은 내가 제안한 모든 변화를 받아들였다.모든 사람이 전문가는 아니다.하지만 우리는 쓰레기를 치우고, 문구를 수정할 수 있다.그리고, 누가 이 시험들을 쓰고 관리하는지 물어봐도 될까?시험을 치르는 사람들이 정말로 과목에 대해 모든 것을 알고 있다는 것을 어떻게 알 수 있을까?우리들 중 많은 사람들은 개인적인 이유나 직업적인 이유로 익명이다.페리돈(토크) 18:18, 2013년 12월 2일 (UTC)[응답]

나는 이 제안서에 특정 기사를 편집하는 것을 금지해야 한다고 쓴 적이 없다.당신은 내가 변경되기 위해 승인을 기다리는 모든 기사에 대해 간결한 제안을 하는 것과 혼동하고 있다.그렇다고 해서 인증된 사람들이 인증된 기사를 편집하는 것이 금지되는 것은 아니다.이것은 그들이 어떤 편집이 좋을지 추측할 수 있고 그들이 매우 확신할 수 없더라도 그들이 그들의 편집이 승인 보류 중이고 기사를 해칠 위험이 없다는 것을 알기 때문에 그것들을 만들 수 있다는 것을 의미한다.내가 정말로 제안한 것은 누구든지 그들이 원하는 기사를 편집할 수 있다는 것이고 시험의 유일한 목적은 자유 선택으로 자신을 훨씬 더 나은 편집자로 선택하려는 사람을 위한 것이었다.시험을 통과해야만 하는 사람들에 대해 내가 조금이라도 제안했던 것은 기사를 편집하는 것이 아니라, 보류 중인 변화를 받아들이거나 거부할 수 있는 힘을 갖는 것뿐이었다.블랙밤추 (토크) 01:44, 2013년 12월 3일 (UTC)[응답]

이것은 아이디어 랩에서 더 좋은 제안의 좋은 예다.Idea Lab을 아이디어 브레인스토밍의 장으로 생각하는데, 완전히 형성된 제안서를 개발한다는 목표를 가지고, 그 다음에 제안 페이지로 올지도 모른다.자신이 제안하는 것을 어느 정도 하는 것에는 가치가 있다고 생각하지만, 반복적으로 '시험'이라고 부름으로써 시험에 합격하지 못하면 어떤 결과도 있다는 인상을 남긴다.오류가 있는 페이지 집합을 만드는 데 가치가 있다는 것을 알 수 있고, 실제 예를 사용하여 수정되기 전에 가치가 있다는 것을 알 수 있다.그러나, 나는 그것들이 어떻게 사용되어야 하는지, 혹은 어디에 존재해야 하는지는 명확하지 않기 때문에, 그것들은 아이디어 공간에서 해결할 수 있는 세부사항들 중 일부분이다.제안으로 제시한다는 것은 독자들이 수정을 제안하기보다는 거절할 가능성이 높다는 것을 의미한다.--S 필브릭 (Talk) 14:06, 2013년 12월 3일 (UTC)[응답]

나는 사람들이 원하는 만큼 시험을 계속 볼 수 있는 애당초 시험을 본 적이 없는 것처럼 처리되지 않는 것을 생각하고 있었다.아이디도 좋네.나는 시험이 없는 것보다 이미 틀린 것이 고쳐지기 전에 알아채는 것이 더 낫다는 시험처럼 속았다.그러한 테스트는 다른 사람이 다른 사람의 실수를 발견하는 것만큼 쉽게 결과를 얻을 수 있다. 그 때 그들은 테스트를 통해 그들이 발견한 실수라고 오해하기 전에는 아무도 눈치채지 못했던 실수를 발견하게 된다.시험에서 실수를 발견하는 새로운 발견은 또한 다른 사람들에 의해 수행되는 미래 시험의 큰 이점을 가지고 있을 것이다. 그리고 무작위로 그 기사가 이전에 시험되지 않았던 동일한 실수를 발견하기 위해 시험되는 것을 보게 되었다.시험을 해서 발견한 새로운 실수는 바로 기사에서 지워져서는 안 된다.이러한 실수를 짧은 시간 동안 시험해 보는 것은 아마도 사람들이 실수를 알아채는 것을 정말 잘 훈련시킬 것이기 때문에 즉시 그것들을 제거함으로써 제거되었을 다른 기사의 실수보다 더 많은 실수를 나중에 제거할 것이다.어떤 사람들은 기사를 실제로 더 나쁘게 만들 때 기사를 더 좋게 만들기 위해 어떤 기사의 변화를 판단하기 때문에 시험에서 실수를 발견하는 것은 기사에서 즉시 그것을 제거해서는 안 된다.블랙밤추 (토크) 01:31, 2013년 12월 5일 (UTC)[응답]

모든 페이지에 링크 기록

툴박스는 우리가 어떤 사용자 공간/usertalkspace 페이지에 있을 때마다 사용자의 로그에 대한 링크를 가지고 있다는 생각이 방금 들었지만, 다른 네임스페이스에서는 그렇지 않다.왜 안 되지?"관련 변경사항"과 "업로드 파일" 사이에 있는 모든 페이지의 도구 상자에 [https://en.wikipedia.org/w/index.php?title=Special:Log&page={{FULLPAGENAME}}}]을(를) 추가하면 어떻게 하시겠습니까?나는 지역 관리자들이 이 변화를 시행할 수 있을지 잘 모르겠다. 우리가 그것에 대해 합의를 본다면, 나는 버그 요청이 제출되어야 할지도 모른다는 것을 이해한다.Nytend 백업(대화) 01:37, 2013년 12월 6일(UTC)[응답]

userspace 페이지의 툴박스 "Logs" 링크는 조회된 페이지가 아닌 사용자의 로그용이기 때문에 다른 네임스페이스에 대해서는 "같은" 개념이 없다.기록 페이지에는 "이 페이지에 대한 로그 보기" 링크가 있다.그것은 사용자 공간과 다른 네임스페이스에서도 마찬가지다.페이지 로그는 기록 페이지에서 한 번만 클릭하면 비논리적 사용자를 포함한 모든 사용자에게 도구 상자에 넣을 수 있는 기술이라고 생각한다.하지만 지방 관리자들이 그것을 하는 것은 가능할 것이다.개별 사용자도 Special에서 다음과 같은 코드로 스스로 할 수 있다.MyPage/common.js.특수: "도구 모음의 드롭다운 메뉴에 페이지 및 사용자 옵션 추가":기본 설정#mw-prefection-gadgets는 로그 링크와 다른 많은 것들을 탭에 추가한다.프라임헌터 (토크) 02:40, 2013년 12월 6일 (UTC)[응답]

mw.util.addPortletLink('p-tb', mw.util.위키Getlink('Special:Log')+?page='+wgPageName', '페이지 로그', 't-logs', '이 페이지에 대한 로그 보기', null, '#t-info' );

WP:FICT#허구적 요소

나는 위키피디아와 같은 삭제 토론에 관해서 편집자들이 이 에세이를 거의 지침이나 정책처럼 인용하는 것을 본 적이 있다.모바일 슈트 건담 유니콘 모바일 무기의 삭제/목록.내 문제는 소설의 전체 허구적 요소들에 대해 우리가 어디에 설 것인가 하는 것이다.무엇이 허용 가능한지, 아닌지에 선을 긋는 방법이 있는가?로미오와 줄리엣의 등장인물 목록이나 등장인물 목록에서는 꺼진 것으로 볼 수 있지만 괜찮다고 볼 수 있다. - Knowledkid87 (토크) 18:45, 2013년 12월 8일 (UTC)[응답]

프랜차이즈나 스토리 아크로 묘사하면 가상의 무기 목록을 볼 수 있었다. DLOhcierkim 18:49, 2013년 12월 8일 (UTC)[응답]

글쎄, 선을 긋기 위한 지침이 마련될 수 있다고 생각하십니까? - Knowledkid87 (대화) 18:52, 2013년 12월 8일 (UTC)[응답]

등장인물 목록은 픽션의 작품이 그들에 대해 공전하기 때문에 일반적으로 항상 괜찮지만, 다른 허구적인 요소에 관한 한, 굳이 모든 요소를 분해할 필요는 없더라도, 우리는 이차적인 출처가 작품에 어떻게 접근하는지에 대해 안내받아야 한다.예를 들어, 이것은 이야기의 그러한 요소들이 전부는 아니더라도 어떤 논의의 대상이 되어 왔기 때문에 로스트의 신화 포함을 주장할 수 있게 한다.요소들에 대해 이야기하는 유일한 사람들이 팬 사이트나 1차 작업이라면 WP에는 적절하지 않을 것이다. --MASEM (t) 18:58, 2013년 12월 8일 (UTC)[응답]

전체 페이지 대신 섹션 보기

만약 당신이 페이지의 전체 페이지를 보는 대신에, 이 페이지의 특정 부분만 볼 수 있다면, 만약 누군가가 페이지의 어떤 것을 편집한 것이 아니라, 누군가가 그 부분을 편집했을 때에만 당신에게 통지할 수 있다면 어떨까?몇 개의 스레드를 제외한 어떤 스레드에 대한 응답도 신경쓰지 않는 이런 페이지에서는 이 방법이 매우 유용할 것 같다.이것을 하는 것이 절망적일 정도로 비실용적일 수 있는 기술적 문제가 있다면, 잊어버려라(이곳은 내 전문 분야가 아니다), 그렇지 않으면 나는 이것이 왜 나쁜 생각인지 이유를 알 수 없다.하지만 내가 틀릴 수도 있어, 내가 전에 여기서 분명히 틀렸었어.진킨슨이 나한테 말했어 지금 무슨 짓을 한 거야?02:55, 2013년 12월 10일 (UTC)[응답하라]

위키백과:영구 제안#Watchlist 변경사항: "많은 사용자가 이러한 기능의 사용을 지원하지만, 현재 버전의 MediaWiki에서는 불가능하지는 않더라도 이 기능의 기술적 구현이 어렵다." Prime헌터 (토크) 03:06, 2013년 12월 10일 (UTC)[응답]

이것은, 거의 정확하게, 플로우의 주요 이점 중 하나이다.--조름 (WMF) (토크) 03:20, 2013년 12월 10일 (UTC)[응답]

대화 공간에 없는 게시판에서 플로우가 작동하지 않는다는 것만 빼면.조먼이 맞나?기술 13 (대화) 03:32, 2013년 12월 10일 (UTC)[응답]

아니오. 흐름은 모든 페이지에서 활성화할 수 있다.결국최초 롤아웃에서는 그렇지 않다.--조름 (WMF) (토크) 03:43, 2013년 12월 10일 (UTC)[응답]

기사 공간엔 없는 게 확실해?그게 어떻게 말이 되는지 전혀 모르겠어. --트로바토어 (대화) 03:55, 2013년 12월 10일 (UTC)[응답하라]

맞아, 아마 대화 공간 + 프로젝트 공간을 의미했을 거야.레곡™ (대화) 04:08, 2013년 12월 10일 (UTC)[응답]

네임스페이스에 관계없이 모든 페이지에서 흐름이 활성화될 수 있다.결국대화/말하지 말고, 상관없어.--조름 (WMF) (대화) 04:22, 2013년 12월 10일 (UTC)[응답]

네임스페이스가 인공적인 구조인 건 아시죠?소프트웨어는 상관없다.조금도우리는 "그것이 메인 스페이스에서 활성화되는 것을 허용하지 말라"고 말할 수 있다.아니면 우리가 허락할 수도 있어구성 가능.--조름 (WMF) (토크) 04:24, 2013년 12월 10일 (UTC)[응답]

아, 소프트웨어적인 관점에서, 나는 그것이 말이 된다고 생각한다.나는 단지 기사 공간에 Flow에 대한 그럴듯한 사용 모델이 없다고 생각한다.Flow가 무엇인지 완전히 오해한 것이 아니라면. --Trovatore (대화) 04:29, 2013년 12월 10일 (UTC)[응답]

나는 동의한다: 위키피디아 프로젝트에서, 나는 주요 네임스페이스에서 그것을 별로 쓸만한 것을 볼 수 없다.그러나 다른 프로젝트나 네임스페이스에 대해서는 인정하지 않을 것이다. --Jorm (WMF) (토크) 05:30, 2013년 12월 10일 (UTC)[응답]

(갈등 편집) 결국엔 모든 대화 페이지에서 전체 게시판에 걸쳐 Flow를 활성화할 계획이지만, 마을 펌프, {{Noticeboard 링크}의 모든 내용, 그리고 토론에 사용되는 다른 모든 페이지 등 토론에 사용되는 모든 개별 페이지에서 수동으로 플로우를 활성화할 계획이라고 생각한다.기사-공간-대화하지 않는 페이지에는 어떤 이유로든 그 중 하나가 토론에 이용되지 않는 한, 아마도 그런 일은 일어나지 않을 것이다.네임스페이스 제한이 실제로 필요한지 모르겠다.사용 가능 여부는 이전 사용자가 결정할 수 없다.Equazcion → 04:26, 2013년 12월 10일 (UTC)

태그 지정 방법에 필요한 지침

여보세요. 나는 최근 토크:에드워드 스노든에서 우연히 매복을 만났는데, 5만 피트 상공에서 허용 가능한 태깅 관행에 대한 의견 차이를 줄였다.나는 그 기사에서 심오한 불균형을 본 것에 대해 최상위 {{undue} 태그를 추가했었다.불균형(및 그 범위)이 있었는지에 대해서는 다소 의견이 분분했지만, 토론은 장기적으로 기사와 지역사회에 지속적인 불신과 피해를 줄 수 있는 신랄하고 비생산적인 싸움으로 빠르게 전개되었다.

이 논쟁에서 누가 "옳은"지에 대해 어떻게 느끼는지와 상관없이(그리고 분명하게 말해서, 나는 그 논쟁을 연장하기 위해 여기 온 것이 아니다), 태그 지정에 대한 지침이 있었다면, 태그 지정이 적절할 때, 하지 않을 때, 태그 제거 시기, 그리고 분쟁 해결 방법을 피했을 것이다.내가 이 주제에 대해 잘 알고 있는 유일한 에세이는 WP이다.이 주제를 다루는 TAGGING, 그리고 나는 오히려 그것에 동의하지만 다른 많은 편집자들은 그렇지 않을 것이다.만약 우리가 그 에세이의 홍보를 위한 합의를 얻을 수 없다면, 우리는 합의를 이루기 위해 그것을 조정하도록 노력해야 한다.어쨌든, 우리는 나 같은 편집자들이 언제 어떻게 태그를 붙여야 하는지 알 수 있도록 이 주제에 대한 지침이 필요하다; 그래서 그 논쟁에 휘말린 다른 편집자들과 같은 편집자들은 어떻게 대응해야 하는지 안다.이 니즈가 명확하게 표현된 것은 이번이 처음이 아닙니다, 예를 들어, 여기, 여기 -- 그리고 이러한 논의들을 통해 그 아이디어에 대한 폭넓은 지지가 있다는 것은 명백합니다.그 문제는 물론 후속 조치다.그리고 나는 그러한 문제들에 대해 비교적 새로운 사람이며 WP 네임스페이스에서 일한 경험이 없다는 것을 인정한다.아마도 이 대의에 기꺼이 지지할 사람이 있을 것이다.여기 희망사항이 있다. --박사님. 플라이슈만 (대화) 19:21, 2013년 12월 3일 (UTC)[응답]

나는 그 문제에 대해 동정한다.나는 많은 신입 편집자들과 함께 일해왔고, 그들 중 많은 편집자들은 태그에 대해 타당하지만 부정확한 가정을 한다.그들은 첫 번째 기사를 만든 다음 문제를 식별하는 몇 개의 태그를 본다.그들은 문제를 해결하려고 노력한 다음, 태그가 제거되기를 기다리며, 누가 그것들을 놓았는지 기사를 감시하고 있을 것이며, 문제가 해결되는 즉시 그것들을 제거할 것이라고 자신한다.그런 일은 자주 일어나지 않기 때문에, 그들은 헬프 데스크나 찻집 또는 다른 장소에 연락하여 왜 그들의 수정이 불충분하다고 여겨졌는지 물어본다.

우리는 (그리고 나는 금지를 지지할 마음이 없다) 태깅을 통해 운전하는 것을 허용하지만, 그것은 새로운 사람들의 가정이 그럴듯하기 때문에 어색한 상황을 남긴다.나는 이 문제를 어떻게 해결해야 할지 가끔 고민해 보았지만, 아무 것도 생각해내지 못했다.

나는 위키피디아 에세이를 보지 못했다.태그 지정 전이며, 잠재적인 가이드라인을 위한 좋은 시작이라고 생각한다.그리고 구체적으로는 내가 방금 설명한 문제를 해결하기 위한 몇 가지 제안이 있다.나는 드라이브 바이 태깅을 금지하고 싶지는 않지만, 나는 태깅하는 사람이 토크 페이지에 코멘트를 추가해야 한다는 요구사항을 지지하는 것을 고려해 볼 것이다.다른 것은 아니지만, 많은 신입 사원들은 기사 이력을 아직 볼 줄 모르기 때문에 태그를 추가하는 편집자가 토크 페이지에 코멘트를 추가하라고 주장함으로써 태그를 추가한 사람을 식별하는 방법을 알지 못한다는 것을 기억하라.이상적인 상황에서, 토크 페이지 노트는 "이 글은 제2항의 클레임 A, 제3항의 클레임 B, 제5항의 클레임 C에 대한 언급이 누락되어 있다.이러한 주장이 참조되는 경우, 누구나 Requires More reference 태그"를 제거할 수 있다.또 다른 좋은 상황은 "이 기사는 A항목이 포함되고 B항목이 언급되지 않아 편향된 것 같다.이 문제를 해결하기 위해 편집을 했다면 나에게 알려주면 태그가 여전히 필요한지 다시 생각해 보겠다."

그들이 문제를 해결한다면 그 누구보다도 태그를 제거할 수 있다는 사실은 새로 온 사람들이 아는 것이 아니다.아는 사람이라도 태거가 무엇을 우려했는지 정확히 알지 못할 수 있기 때문에 제3자가 태그 제거 여부를 결정하려 한다면 설명이 도움이 될 것이다.--S 필브릭 (Talk) 22:36, 2013년 12월 4일 (UTC)[응답]

응답해줘서 고마워.태그에 대한 여러 가지 가정과 기대가 있는 것 같은데, 네가 언급하는 것을 나는 몰랐어.Edward Snowden의 태그 논쟁에서 긴장감은 (i) 태그 편집자가 태그를 붙이기 전에 자신의 우려를 확인하기 위해 독립적인 연구를 해야 하는지, (ii) 태그 편집자가 태그를 붙인 후에 문제를 해결할 것으로 예상되는지를 중심으로 보였다. --Dr. Fleischman (talk) 00:00, 2013년 12월 5일 (UTC)[응답]

나는 WP에서 읽은 모든 것에 동의한다.지금은 처음 보는 태그 지정.하지만, 우리는 이미 너무 많은 규칙을 가지고 있다; 교육용 크리프 (그리고 그것의 시행, 특히)는 새로운 사람들을 끌어들이고 오래된 것들을 보관하는 데 좋지 않다.WP의 상태를 변경하는 대신:TAGGING이나 다른 에세이에서는 다음과 같이 하자.(1) 누군가가 WP를 "폭행"하는 것을 볼 때:TAGGING, 사용자 토크 페이지에 "Hi, I don't know what you mean [편집]"과 같은 내용의 메모를 남기십시오.기사의 토크 페이지로 가서 당신의 추리를 설명해 주시겠습니까?[[WP:TAGGING 당신의 태그 설명]] 다른 사람들이 태그에 대해 더 잘 이해할 수 있도록 도와준다.이것은 신참들에게는 따끔한 것이 아니다. (2) 그것을 파괴적인 것으로 간주하고 의도적으로 편집 내용을 설명하지 않는 사람들에 대한 제재를 모색하기 시작한다.그러나, 이것은 극단적인 상황에서 사용되어야 한다. 페이지 하나가 태그 설명이 필요하다는 것을 여러 번 상기시켜주었지만, 그러한 설명들을 거절하는 사람에 의해 정말로 그리고 진정으로 상처를 받고 있을 때; 이것의 좋은 징조는 설명되지 않고 모호하지 않은 태그가 제거된다면, 그럼에도 불구하고 태그거는 그것들을 복구하기 위해 편집하는 것이다.Nytend 백업(대화) 01:45, 2013년 12월 6일(UTC)[응답]

오래 전에 각 유지 관리 템플릿에 도움말 페이지(정책 페이지가 아님)에 대한 링크와 도움말 페이지로 연결되는 도움말 페이지(이 통지 삭제 방법)에 대한 링크를 추가하자고 제안했었습니다. -- Gadget850^talk 23:52, 2013년 12월 9일 (UTC)[응답]

나쁘지 않은 생각이야.그 토론을 파헤칠 수 있겠니?결과는? --Dr. 플라이슈만 (대화) 18:52, 2013년 12월 10일 (UTC)[응답]

유료 프로젝트 금지 제안

안녕, 이 기사[4]를 읽고 내가 몇 가지 가능한 개선을 제안하고 싶은 것을 읽으면서, 첫 번째 언급은 챕터에서 자원봉사자로 자금을 옮기는 것이다. 나는 이 토론이 이제 위키피디아에서 유료 편집에 대한 최근의 논의로 끝났다고 생각한다. 나는 우리가 유료 편집인 구글 KNO로부터 교훈을 얻었다고 생각한다.L[5] 프로젝트도 마찬가지여서, 위키백과의 유료 프로젝트에서 이것이 어떻게 이루어지며, 위키백과는 프로젝트에 대해 지불해야 하는가?초기에는 5개의 개발자가 있었는데, 주로 미디어위키 임플레메트를 요청했고, 지금은 175명의 사람들이 위키백과뿐만 아니라 자매 프로젝트도 하고 있다. 우선 WMF가 차와 함께 놀랄만한 성공을 거두었다는 주장으로부터 우리를 보호하기 위해 위키백과와 분할한 후에 우리 모두가 동의한다고 말하겠다.위키피디아에서 PR을 보다 전문적으로 다룰 수 있도록 분할된 기금모금운동에 대해서는, 우리는 몇몇이 매우 성공적이고, 주목할 만한 것은 예술작품을 자유롭게 재사용하기 위한 네덜란드 뮤즈의 라이센스 변경과 우리의 자매 프로젝트 커먼즈[6]가 더 많은 것을 얻기 위한 프로젝트들이다.사진 그리고 의심의 여지 없이 그러한 챕터 프로젝트들, 매우 멋진 프로젝트들이 더 많이 있지만 위키피디아 프로젝트들은 아니다, 지금 너무 많은 시간이 경과하고 새로운 모델을 시험한 후, 이 글에서 두 번째 언급은 그 챕터들의 영향력이 원하는 대로 작용하지 않고 있다는 것을 언급한다, 역할 b와 명확하게 분리된 챕터들의 설립에서.자원봉사자 위키피디아와 장 사이에 의도된 것이었지만, 메타의 기부금과 무급 자원봉사 사이의 경계를 모호하게 하는 트라이아가 형성되어 있는 것으로 밝혀졌다.

프로포즈

이러한 분열을 단기적으로 최대화하기 위해 로그인 이름 끝에 (WMF) a (WMFC)와 유사한 챕터 광고에서 유상 수입을 얻은 모든 회원은 모든 위키백과 관련 이슈만을 결합하는 채널로서 META 채널을 위키백과 자원봉사자로만 회수할 것을 제안한다.TAWMF는 이런 식으로 무급 자원봉사자들이 이 프로젝트에 머물기를 희망한다. 우리 모두가 유급 프로젝트 가이드와 무급 자원봉사자들 대신 이 프로젝트에 대한 무급이기 때문에 그들의 사기가 더욱 뒷받침되고 있기 때문이다.요컨대, 그것은 어떤 프로젝트에 대한 공격이 아니라, 각 프로젝트가 혼합된 관심 영역 대신 그들의 기여자 기반을 바탕으로 자신의 장점에 따라 결정할 수 있는 분명한 선을 만들려는 시도다.미온(토크) 21:33, 2013년 12월 10일 (UTC)[응답]

이해가 안가..기록부는 트롤이 담당하지만, 위 내용 중 꽤 많은 부분을 차지하고 있다.어떤 경우든, 위키백과를 편집해야 하는 유료 챕터 스텝들이 이미 사용자 이름 포스트픽스로서 적절한 챕터 약어를 가지고 있는 무언의 관습이 있다(사용자: 참조).리디아 핀츠셔(WMDE)가 그 예다.아이언홀드 (대화) 22:11, 2013년 12월 10일 (UTC)[응답]

제안서의 첫 부분을 명확히 해줘서 고마워, 나는 이름을 붙이는 그런 무언의 관습이 이미 존재하는지 몰랐지만, 많은 사람들이 그것을 알지 못할 수도 있는 것처럼 모든 위키피디아에 "규칙"을 만들어야 할지도 몰라.

개혁안

META 채널을 위키백과 자원 봉사자에게만 회수, 모든 위키백과 관련 이슈만을 결합하는 채널로서 모든 자매 프로젝트, WMF 및 챕터들은 새로운 채널 METAWMF로 이동하며, 이러한 방식으로 우리 모두가 유료 프로젝트 가이드 대신 이 프로젝트에 무급 지원되기 때문에 그들의 사기가 더 많이 지원되기 때문에 희망적으로 이 프로젝트에 머물기를 바란다.rs 및 무급 자원봉사자요컨대, 그것은 어떤 프로젝트에 대한 공격이 아니라, 각 프로젝트가 혼합된 관심 영역 대신 그들의 기여자 기반을 바탕으로 자신의 장점에 따라 결정할 수 있는 분명한 선을 만들려는 시도다.미온 (토크) 22:19, 2013년 12월 10일 (UTC)[응답]

"META 채널"이 무슨 뜻인지 설명해 주시겠습니까?당신이 에세이 WP에서 언급된 위키피디아를 의미한다면:무시메타, 어차피 이 위키백과에 대해서는 그 위키백과에 대해 제안은 하지 않는 것 같아. --Demiurge1000 (토크) 22:27, 2013년 12월 10일 (UTC)[응답]

그래, [7]이 바로 그 뜻이야. 월와이드 위키피디아의 모든 META 채널과 위키피디아 프로젝트를 위한 전용으로 결합되어야 해. 만약 다른 프로젝트와 혼합된다면 우리는 (자원봉사자 입력에 비해 WMF 또는 WMFC 기여자들에 의해) 많은 영향력을 받게 되는 것으로 밝혀졌어.미온 (토크) 22:38, 2013년 12월 10일 (UTC)[응답]

미디어위키*.레곡™ (대화) 22:39, 2013년 12월 10일 (UTC)[응답]

무슨 기사인지, 수의 논평인지, 유료 편집 제안서인지 제대로 이해하지 못한 것 같은데...왜냐하면 그들은 정말 전혀 관계가 없기 때문이다.유료 편집 문제는 위키피디아의 위키-PR 편집 사건에서 비롯됐으며 주로 기업과 홍보업체가 위키미디어 장이 아닌 위키피디아를 편집하는 내용이다.Sue의 논평과 Register 기사는 WMF 돈을 가장 잘 쓰는 방법에 관한 것이었다.그 문제들은 정말로 전혀 연관되어 있지 않다.자매 프로젝트와 장은 같은 것이 아니다.자매 프로젝트는 위키피디아나 위키북스 같은 것으로, 위키백과처럼 자원봉사를 한다.챕터들은 위키미디어 도이칠랜드와 위키미디어 NYC와 같은 조직들이다.그들은 도서관이나 박물관과 함께 봉사 활동 같은 것들을 한다.대부분의 챕터 멤버들은 급여를 받는 직원이 아니라(많은 챕터들이 멤버가 되기 위한 수수료를 가지고 있기 때문에), 다양한 프로젝트에서 나오는 정규 자원봉사 편집자에 불과하기 때문에 챕터와 자원봉사자 사이의 명확한 구분은 거의 없다.Mr.Z-man 23:09, 2013년 12월 10일 (UTC)[응답]

이야기의 핵심은 챕터들이 위키피디아가 아닌 프로젝트를 운영하는 것으로 판명되었고, 따라서 챕터의 인구는 위키피디아의 무급 자원봉사자로 대표되는 최소한의 인구에 불과하다는 것이다. 또한 그들이 입장료 등을 올리기 때문이다.이 혼합된 프로젝트 인구는 유료 회원이 위키백과 등에서 어떤 위키백과 프로젝트 전반에 걸친 컨설팅 없이 자원봉사자들의 적극적인 코칭을 해야 한다고 결정하는데, 그렇다, 나는 코칭이 "프로젝트 비용 지불"이라고 명명했다.미온(토크) 23:26, 2013년 12월 10일 (UTC)[응답]

문제는 왜 위키피디아에 있는 모든 작은 프로젝트들에 돈을 지불하지 않는가? 그리고 지금과 같은 몇몇 프로젝트들은?미온(토크) 23:28, 2013년 12월 10일 (UTC)[응답]

"이야기"의 핵심은 수가 실제로 쓴 것에 대한 엄청난 왜곡이다.나는 네가 "위키피아가 아닌 사람들이 프로젝트를 실행하게 된다"는 말이 무슨 뜻인지 잘 모르겠다. - 그것이 장들의 목적의 일종이다.챕터들은 지역 편집자들을 위한 클럽이 되어서는 안 된다.그들은 편집에 관심을 가질 수 있는 새로운 편집자들이 나오도록 하거나 지역 교육 기관들과 협력을 시작하기 위해 홍보 활동을 한다.다시 말하지만, 장에 관련된 대부분의 사람들은 자원 봉사자들이다.나는 사람들에게 사용자들을 "코칭"하도록 돈을 지불하는 어떤 프로젝트도 알지 못한다.레지스터 기사에도 그런 언급이 없다.아마도 우리가 알고 있다고 추측하는 것들에 대해 모호하게 언급하는 대신에, 당신은 그들이 무엇을 하고 있는지 당신이 문제가 있다고 생각하는 것에 대해 구체적인 정보를 제공할 수 있을 것이다.Mr.Z-man 03:16, 2013년 12월 11일 (UTC)[응답]

나는 이 제안서의 언어를 구문 분석하기 어렵다.내가 알고 있는 유일한 WMF '채널'은 IRC에 있지만, 이 말은 그것과 관련이 없는 것 같다.그리고 나는 그것이 누구에게 제안되고 있는지 확실하지 않다.나는 또한 내가 말한 챕터 스태프들이 24시간 동안 위키피디아를 편집하는 것이 허락되지 않는다는 것을 지적했다는 것을 주목한다. 그것은 그들이 지불받는 것이 아니기 때문이다.이 제안이 성공할 가능성이 있으려면 완전히 다시 써야 한다고 생각하는데, 현재로선 말이 안 된다.비블브록스 (대화) 01:53, 2013년 12월 11일 (UTC)[응답]

나도 동의해.제안서 전체를 읽었는데 이해가 안 돼.--S 필브릭 (토크) 13:54, 2013년 12월 11일 (UTC)[응답]

위키백과 업데이트:가장 놓친 기사

위키백과:대부분의 누락된 기사는 5년 만이 아니라면 유용할 것이다.이것을 과거 목록으로 표시하고, 보관하고, 새로운 목록(또는 더 나은 동적 목록)을 생성할 수 있는가?bd2412 T 19:20, 2013년 12월 16일 (UTC)[응답]

자세한 내용은 WP:TOPRED를 참조하십시오.지난 한 달여 동안 문제가 좀 있었지만 매주 업데이트된다.VanIsaac 21_{WS Vex}^contribs:12, 2013년 12월 16일 (UTC)[응답]

만약 WP:TOPRED가 유효하다면, 그것은 네임스페이스 4로 유지되어야 한다.위키백과:놓친 기사들은 대부분 그것으로 방향을 바꿀 수 있다. - 포인틸리스트 (토크) 22:06, 2013년 12월 16일 (UTC)[응답]

m:MassMessage에 대한 새 사용자 그룹 만들기

그 안에 '매스메시지'만 들어 있는 사용자 권리의 창설에 대해서는 분명한 공감대가 형성돼 있다.Armbrust 19:47, 2013년 12월 19일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

지난 몇 달 동안 나와 MZMcBride는 사용자 교체 작업을 해왔다.사용자가 직접 위키에서 뉴스레터와 기타 메시지를 사용자 목록으로 보낼 수 있도록 허용한 EdwardsBot.어제 MassMessage 확장 버전이 배포되었으며 'MassMessage' 권한(현재 sysops만)을 가진 사용자가 Special:메시지(지침)를 전송하기 위한 MassMessage(사용자:EdwardsBot/Spam이 작동했다.그것은 건전한 옵트 아웃 시스템을 특징으로 한다. (그냥 당신의 토크 페이지를 카테고리에 추가하라:메시지 전달 거부), 기타 개선 사항 및 버그 수정 사항.메시지는 MediaWiki 메시지 배달 계정을 통해 전달된다.자세한 내용은 m:MassMessage 및 mw:도움말:확장:매스메시지.

현재 도구는 관리자만 사용할 수 있다.나는 우리가 '매스메시지'만 있는 새로운 사용자 그룹을 만들 것을 제안한다.관리자는 이 그룹을 사용자로부터 배포하고 제거할 수 있을 것이다.사용자는 도구(일부 뉴스레터를 전달하기 위해 필요함)를 사용할 필요가 있음을 보여주고 도구 사용 방법을 이해해야 한다.이것은 User talk의 현재 프로세스와 동일하다.EdwardsBot/액세스 목록.레고크tm (대화) 2013년 11월 20일 (UTC) 17:47 [응답]

질문(MM)

당신은 "뉴스레터와 다른 메시지"라고 말한다.예를 들어, 새로운 관련 토론의 이전 논의에 관련된 사람들에게 통지하는 것을 포함시킬 것인가?프로젝트 업데이트?이 메커니즘을 합리적으로 사용할 수 있는 다른 것은 무엇인가?DES 21:16, 2013년 11월 20일 (UTC)[응답]

이곳은 내 영역은 아니지만 정기적인 발표를 해야 하는 그룹에 관련된 사람들을 위한 곳이라고 생각해.User talk를 보았다.EdwardsBot/Access list for 몇 가지 예.equazcion → 21:32, 2013년 11월 20일 (UTC)

이 도구는 뉴스레터와 위키프로젝트 업데이트 유형을 위해 설계되었다.그렇긴 하지만, 만약 사람들이 그것을 다른 것에 사용하기를 원한다면, 그러한 종류의 원하지 않는 메시지가 괜찮은지에 대한 것은 지역사회에 달려있다.레곡™ (대화) 21:43, 2013년 11월 20일 (UTC)[응답]

누가 이런 종류의 메시지 전달을 만드는지에 대한 로그가 있는가? 단지 남용될 경우를 대비해서 어디에서 그 출처를 찾을 수 있는지 궁금할 뿐이다.—DJ (대화 • 기여) 23:14, 2013년 11월 20일 (UTC)[응답]
- 예, 스페셜:로그/매스메시지.각 메시지에는 메시지를 보낸 사용자, 메시지를 보낸 wiki(might be from Meta), 사용한 입력 목록이 포함된 숨겨진 댓글(원하는 경우 숨김 없이 만들 수 있음)도 있다.레곡™ (대화) 00:47, 2013년 11월 21일 (UTC)[응답]
현재 User talk에 나열된 사용자:EdwardsBot/Access 목록이 확장되어 더 이상 권한이 없음을 증명할 수 없는 경우에만 이 새 사용자 권한을 자동으로 수신하시겠습니까?기술 13 (대화) 03:40, 2013년 11월 22일 (UTC)[응답]
- 토크 페이지에 올라 있지 않고 실제로 리스트에 올라 있는 사람들?당연하지, 말이 돼.레곡™ (대화) 04:13, 2013년 11월 22일 (UTC)[응답]

지지대(MM)

레고크tm (대화) 2013년 11월 20일 (UTC) 17:47 [응답]
지원: 어느 쪽이든 우리는 이 문제에 대해 관리자들에게 교육해야 한다.이런 목적으로 매스메세지를 사용하는 것은 부적절하지만!Graeme Bartlett (대화)20:47, 2013년 11월 20일 (UTC)[응답]
만약 누군가가 가까운 미래에 단지 하나의 메세지만을 보낼 예정이라면, 아마도 단지 요청을 게시하는 것이 더 나을 것이다.권리는 실제로 사용할 수 있는 사람(분명히)에게 주어져야 한다.Killiondude (대화) 22:17, 2013년 11월 20일 (UTC)[응답]
그것은 정말 좋은 생각이고 쓸모없는 시간 소비를 줄이는 데 도움이 될 수 있기 때문에 지원을 하라.예를 들어, 만약 사람들이 위키프로젝트에서 체크되지 않은 모든 기사를 평가하기 위한 드라이브를 시작할 계획이라면, 모든 회원들은 쉽게 기고할 수 있다.대규모 재구성을 위해 기사를 계획하고 있는 것과 같은 방법으로 주요 기고자들을 쉽게 초대할 수 있다. - Jayadevp13 00:53, 2013년 11월 21일 (UTC)[응답]
지원 나는 몇몇 더 큰 위키피디아 주제와 수화 포스트에 있는 제한된 수의 사람들이 이것을 사용자 권리로 갖는 타당한 이유를 가지고 있다고 생각한다.주요 싱포스트 멤버들 중 일부는 관리자가 아닌 것으로 알고 있으며, 현재 편집장이 관리자인 반면, 배달을 촉발시킬 수 있는 여러 사람이 있는 것은 항상 좋은 일이다.하지만 만약 관리자들이 대량 메시지를 보낼 타당한 이유가 없는 사용자들에게 사탕처럼 이것을 나눠주기 시작한다면, 나는 오히려 화가 날 것이다.나는 스팸메일을 좋아하지 않는다.스벤망구아르 Wha?04:09, 2013년 11월 21일 (UTC)[응답]
날 위해 일한다.제안은 충분히 고려된 것으로 보이며, 이것이 유용한 것으로 만족한다. – Juliancolton 04:20, 2013년 11월 21일 (UTC)[응답]
만약 우리가 이것을 위한 새로운 사용자 그룹을 갖게 된다면, 사용자 그룹은 입소문이 나야만 한다. 이미 그 그룹에 속해 있는 사람은 누구나 그것을 다른 사람들에게 제공할 수 있다.MediaWiki는 기본적으로 이 구성을 지원한다.MassMessage의 핵심은 많은 브라우저 탭과 클릭을 대신하는 것이다.단일 사용자 권한에 대한 사용자 그룹은 약간 바보스럽다고 느끼지만, 괜찮다. --MZMcBride (대화) 04:29, 2013년 11월 21일 (UTC)[응답]
지원 - 이 권한은 해당 권한을 사용할 가능성이 있는 사용자에게만 부여해야 한다.필자도 봇 패키지의 일부여야 한다고 생각한다(봇은 스스로 소량의 인적 노력으로 이것을 할 수 있지만, 이것은 사이트 자원을 적게 사용하여 할 수 있게 해줄 것이다), 그러나 아마도 자동 관리 패키지의 일부는 아닐 것이다(관리자는 필요할 경우 그것을 가져갈 수 있어야 한다).이것은 뉴스레터 봇을 대체하게 될 것이다. (뉴스레터를 담당하는 사용자들은 관리자 지위에 관계없이 이 권리를 가져야 한다.)2013년 11월 21일(UTC) 오드 미셰후 14:06[응답]
유일한 합리적인 선택사항은 관리자가 그들에게 대량 메시지를 보내줄 것을 요청할 수 있는 페이지를 만드는 것인데, 이것은 이것보다 더 관료적인 것 같다."관리자 전용"의 기본값은 관리자가 실제로 무언가를 관리할 시간이 있는 소규모 위키에서는 이치에 맞지만, enwiki에서는 덜 위험하고 민감한 사항을 다른 신뢰할 수 있는 사용자에게 위임하는 것이 이치에 맞는다.미스터 지맨 21:57, 2013년 11월 21일 (UTC)[응답]
관료주의를 없애기 위해 더 많은 번들링되지 않은 사용자 권리를 갖는 것에 대한 지원.로스 힐 (토크) 2013년 11월 22일 01:15 (UTC)
EdwardsBot을 통해 이전에 가능했던 것을 달성하기 위한 보다 공식적인 시설로서의 지원.권한은 요청 시 간단한 사용 합리성을 고려한 후 신뢰할 수 있는 커뮤니티 구성원이 할당해야 한다.권리는 단순히 그것을 가진 사람들이 다른 사람들에게 할당되어서는 안 된다. 예를 들어, 채택된 관습에 익숙하지 않은 사람들이 악용할 가능성이 있기 때문이다. -- Trevj (대화) 03:57, 2013년 11월 22일 (UTC)[응답]
지원하되 권리 부여는 관리자만 해야 한다. --Rschen7754 04:40, 2013년 11월 22일 (UTC)[응답]
위의 질문에 대한 답변이 "예"였기 때문에 기존 목록의 사용자들은 확장되어 다시 신청할 필요가 없을 것이다.기술 13 (대화) 2013년 11월 22일 12:21, (UTC)[응답]
지원(사용자:조누니크도 아래에 일리가 있다.EdwardsBot의 사용은 다소 불명확한 반면, 사용자 권리는 이러한 기능을 각광받게 한다.RFC와 같은 다른 방법보다 언제 이것이 적절한지, 그리고 가능한 사용에 대해 먼저 논의해야 하는지에 대한 지침이 마련되어야 한다.예: 여러 개인에 의한 위키프로젝트 뉴스레터 = 아마도 괜찮을 것이다; 당신 자신의 마을 펌프 제안 광고 = 아마도 좋지 않을 것이다; 등. equazcion → 12:42, 2013년 11월 22일 (UTC)

EdwardsBot이 제공한 유사한 라인에 따른 지원: 당신은 그것을 사용해야 할 지속적인 이유가 있을 때에만 지원(예:WP에 도움이 될 만한 것이 있다.WPAFC 메시지 배달.) --Mdann52톡! 2013년 11월 22일(UTC) 13:15, 22(응답)

지지, 현명한 생각인 것 같군– Quadell 14:00, 2013년 11월 22일(UTC)[응답]
지원이 위키프로젝트에 가장 도움이 될 것이다.:) — Cirt (대화) 04:13, 2013년 11월 23일 (UTC)[응답]
지원—현재 위키프로젝트 뉴스레터를 편집하고 있는 우리들 중 일부는 관리자가 아니며, EdwardsBot을 사용하여 대량 우편물을 처리할 수 있는 권한을 가지고 있다.EdwardsBot 허용과 같은 사용자 권한을 제공하지 않는 것은 단지 관리자들로 하여금 다른 사람들이 이미 하고 있는 일, 즉 뉴스레터 전달을 맡도록 하는 것을 방해할 수 있다는 것을 의미한다.임자디 1979 → 05:45, 2013년 11월 23일 (UTC)[응답]
지원 매우 유용하다.고마워, 이 내선 공사를 하셨던 분들.Courcelles 19:26, 2013년 11월 25일 (UTC)[응답]
지원 나는 왜 우리가 현상 유지를 원하는지 모르겠다. (EdwardsBot 리스트에 편집자가 추가될 수 있다.)나는 쿠르첼레스가 위에서 말한 것에 대해 에코하고, 감사하며, 연장 작업한 사람들에게 잘 해 주었다.Callanec (대화 • 기여 • 로그) 05:54, 2013년 11월 27일 (UTC)[응답]
내가 보기엔 지원이 괜찮은 것 같아.페리돈 (토크) 2013년 11월 29일 (UTC) 17:47[응답]
지지하다.이에 대한 사례는 분명히 이루어졌으며, 새로운 사용자 권리가 책임 있게 할당되는 한 이 제안에는 명백한 부정적인 면이 없다.AGK [•] 23:35, 2013년 11월 29일 (UTC)[응답]
지지하다.나는 단점이 보이지 않는다.매우 유용할 수도 있다.닌자RobotPirate (토크) 00:21, 2013년 12월 5일 (UTC)[응답]
물론이지.나는 이것에 대해 몰랐다.그래서 내가 여기서 요청한 거야.어쨌든 이쪽의 지원. --Pratyya 16:06, 2013년 12월 5일 (UTC)[응답]
지지하다.우리는 이미 EdwardsBot 리스트에 이러한 기능을 가지고 있기 때문에 제안서는 기본적으로 사용자들이 그것을 얻기 위한 과정을 단순화시키고 있다.우리는 정말로 요청자 지망자들에게 일종의 경고를 해야 한다. (1) 과거에 EdwardsBot에 접속하지 않았거나 (2) 그들이 이미 메시지를 준비하지 않았더라면, 그들은 권리를 얻자마자 보낼 수 있을 것이다.이것은 모자의 수집을 상당히 줄일 것이다.Nytend 백업(대화) 00:26, 2013년 12월 6일(UTC)[응답]
지지하다.관리자에게 각 개별 메시지를 검토하고 전송하도록 요청하기보다는 도구 사용에 대한 허가를 요청하는 것이 타당하다.그것은 그것을 위해 입증된 용도를 가진 사람들에게만 허용되어야 하고, 그것을 오용한 사람들은 추첨되고, 4등분되고, 독수리에게 남겨져야 한다.~ 닝어블 (대화) 12:54, 2013년 12월 8일 (UTC)[응답]
지지하다.관리자들이 일을 좀 아낄 수 있을 거야, 내 관점에서 보면 좋은 거지.또한 EdwardsBot 시스템이 잘 작동하고 있기 때문에 MassMessage 허가 시스템이 유사하게 작동하도록 하는 것이 타당하다.— Mr. Stradivarius 04:15, 2013년 12월 9일 (UTC)[응답]
지지 - 그 생각은 일리가 있다.나는 스팸메일의 문제가 극히 드물 것이라고 확신한다. 왜냐하면 이것은 본질적으로 EdwardsBot을 대체하는 역할을 할 것이고 이 허가에 대한 합법적인 필요성을 가진 신뢰할 수 있는 사용자들에게 주어질 것이기 때문이다.우리는 사안마다 사안별로 처리할 수 있다.Michaelzeng7 (대화) 22:25, 2013년 12월 9일 (UTC)[응답]
지원 - 유용할 것 같아. -- TOW 04:49, 2013년 12월 12일 (UTC)[응답]

반대(MM)

~~나는 이것이 대부분의 비관리 도구들처럼 사탕처럼 주어지는 것을 원하지 않는다. --Guerillero My Talk 16:30, 2013년 11월 21일 (UTC)~~[답글]

비관리자들이 다양한 사용자 권한을 수집하는 것이 싫다는 뜻인가, 아니면 남용될 가능성이 있다고 생각하는가?궁금해요– Juliancolton 18:24, 2013년 11월 21일 (UTC)[응답]

욕설 잠재력이 상당 부분 보이는 데다가 열차가 굴러가는 것을 막기 위한 오프버튼도 보이지 않는다. --게릴레로 마이토크 04:28, 2013년 11월 22일 (UTC)[응답]

특수:도움말 페이지에 설명된 대로 블록/MediaWiki 메시지 전달레곡™ (대화) 04:47, 2013년 11월 22일 (UTC)[응답]

이 정보에 대한 내 투표 철회 --Guerillero My Talk 21:09, 2013년 11월 23일 (UTC)[응답]

토론(MM)

나는 이것에 대해 완전히 확신할 수 없다. 왜냐하면 문자 그대로 원하지 않는 메시지로 수천 명의 사용자들을 짜증나게 할 가능성 때문이다.나는 아마도 그것을 부여하는 기준이 더 잘 정의되어야 한다고 생각한다.WP:PERM?Beeblebrox (대화) 03:12, 2013년 11월 21일 (UTC)[응답]의 새로운 페이지에서 요청이 있을 것으로 가정한다.

이를 위한 기능은 이미 User(사용자:EdwardsBot, 단지 지금 그것은 적절한 MediaWiki 확장자로 옮겨졌다.솔직히, 나는 위키피디아 토크와 같은 토크 페이지에서 그것을 하는 것이 더 낫다.WT와 같은 MassMessage :EF는 '필터 매니저 편집'을 다루는데, 이것은 희망컨대 무작위적인 모자 수집 등을 방해할 것이다.이것은 꽤 구체적인 권리라서 매일 접속 요청이 없을 것이다.레곡™ (대화) 04:39, 2013년 11월 21일 (UTC)[응답]

Beeblebrox: 누구나 포루프를 쓸 수 있는 능력을 가진 사람은 말 그대로 수천 명의 사용자를 괴롭힐 수 있다. :-) 브라우저 탭을 사용할 수 있는 사람은 말 그대로 수십 명(수백 명은 아니더라도)의 사용자를 괴롭힐 수 있다. --MZMcBrid (대화) 05:34, 2013년 11월 21일(UTC)[응답]

다음과 같은 중요한 차이가 있다.천 개의 토크 페이지에 메시지를 남기기 위해 대본을 쓰는 사람은 누구나 외설적일 가능성이 매우 높은 반면, 편집자 천 명을 스팸으로 보내기 위해 공식 도구를 사용하는 사람은 표준 운영 절차를 따르고 있다고 주장할 수 있다("설문 초대를 읽고 싶지 않으면 그냥 삭제하라, 무슨 일로 칭얼대느냐"). 조누니크(토크) 08:4:42013년 11월 21일 (UTC)[응답하라]

별도의 사용자 권한을 갖음으로써, 이 기능을 남용하는 모든 사용자는 권한을 제거할 수 있으며, 여전히 여기서 다른 종류의 편집을 계속할 수 있다.2013년 11월 21일 (UTC) ododשוווOd Mishehu 14:09 [응답]

Od Mishehu: 난 동의하지 않아.이 기능을 남용하는 사람은 이 프로젝트에 대해 오랫동안 다른 종류의 편집을 해서는 안 된다.분명히 블록의 강도는 맥락에 얽매여 있어야 하지만, 그것이 사람들을 얼마나 화나게 하는가를 고려하면, 내가 생각하는 것은 무거운 손으로 블록을 다루어야 한다는 것이다.스벤망구아르드화?2013년 12월 4일 18:47 (UTC)[응답]

MassMessage는 허글이나 AWB와 같은 도구일 뿐이다.만약 당신이 Hugel을 남용한다면, 당신의 롤백 권리는 없어진다.왕립으로 망치면 막힌다.저도 마찬가지에요.레고크™ (대화) 08:51, 2013년 11월 22일 (UTC)[응답]

(아마도 별것 아닌) 가치로, 메타에게는 이미 이런 것이 있다.πr² (t • c) 15:18, 2013년 12월 5일 (UTC)[응답]

나는 레고크트엠에 동의하고 스벤 므구아드에 동의하지 않는다.일반적으로 프로젝트에 신뢰할 수 있고 유용한 사람만이 이것을 바로잡을 수 있는 타당한 이유를 가지고 이 권리를 갖게 될 것이다.현재 사용자는 처음에 허글이나 AWB를 오용할 경우 경고를 받는다.그래서 나는 여기서 그가 처음으로 경고를 받아야 한다고 믿는다.그런 다음 사용자가 계속 악용할 경우 자신의 권리를 제거해야 한다.사용자는 차단되지 않아야 한다.신뢰할 수 있는 사용자가 도구를 의도적으로 남용하지 않기 때문이다.잘못해서 그런 일이 생기니 기회를 줘야 한다.--프라티야 17:50, 2013년 12월 5일 (UTC)[응답하라]

또한 기존 EdwardBot 액세스 목록에 있는 사용자에게는 재신청 없이 이 권한이 부여되어야 한다고 생각한다.--Pratya 18:02, 2013년 12월 5일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

봇

봇(사용자:Jakebot) 특수에서 스터브 감지 및 태그 지정:새 페이지.분명히 BRFA를 열기 전에 여기에 물어봐야 할 것 같아.생각? --Jakob (내가 망가뜨린 것에 대한 그림) 18:08, 2013년 12월 7일 (UTC)[응답]

이것은 문제가 있는 것처럼 들린다.어떤 스텁 태그를 추가하시겠습니까?그냥 비정보적인 {{stub}}}?위키피디아와 대화해 본 적이 있는가?위키프로젝트 스텁 정렬?기사라고 할 수 없는 짧은 글과 메인 스페이스 페이지를 어떻게 구분할 계획인가?프라임헌터 (토크) 2013년 12월 7일 (UTC) 19:13[응답]

WP를 인용하려면:스텁, 기사가 스텁이 되는 것을 멈추는 정해진 크기는 없다.1500자 마크는 어디에서 왔는가?단점이 봇(또는 적어도 크기에 근거한 것이 아니라)에 의해 결정될 수 있는 것이라고 확신할 수 없다.2013년 12월 7일(UTC) 19:33, Writ Keeper ⚇[응답]

@PrimeHunter:잘 모르겠어.어쩌면 위키프로젝트 스터브 정렬의 누군가가 알고 있을지도 몰라.

@Writer Keeper: 1500자의 읽기 쉬운 산문은 WP에 따르면 기사가 단조로운 것이 멈추는 경우:DYK 표준.위키 마크업 1500자=스텁(stub)으로 편하게 평가할 수 있는 읽기 쉬운 산문이 상당히 적어서. --Jakob(내가 망가뜨린 것에 대한 그림) 19:45, 2013년 12월 7일(UTC)[응답]

당신의 봇이 1500자 DYK와 대조하기 전에 모든 위키/html/css 포맷을 걸러낸다는 말씀이십니까? DYK는 재지정 WP를 받아들이기가 불편하다.스텁, 임계값?기술 13 (대화) 21:47, 2013년 12월 7일 (UTC)[응답]

Jakob, DYK가 1500자 이하의 산문 문자(또는 적어도 1500자 이하의 비 스텁)로 스텁을 박았다고 말하는 것은 정확하지 않다.DYK는 1500개의 산문 문자를 DYK에서 지명된 기사에 대한 자격을 얻기 위한 바닥으로 가지고 있으며, 또한 그 기사가 스텁이 되지 않도록 요구한다.내가 1500을 훨씬 상회하면서 검토한 많은 기사들은 여전히 단조롭고 더 확대되지 않는 한 승인되지 않았다: 주제 적용 범위가 다른 문제들 중에서 지나치게 약했다.WP 참조:DYKSG#D7 및 D11.블루문셋 (토크) 00:40, 2013년 12월 17일 (UTC)[응답]

나는 Prime에 동의하는 경향이 있다.헌터, 나는 이것이 믿을 수 있게 자동화할 수 있는 것인지 확신할 수 없다.실제 스텁이 99.9%가 될 만한 것을 얻기 위해 몇 가지 세부적인 기준을 마련할 수 있을 것이라고 확신하지만, 많이 놓칠 것이고, {{stub}}} 외에 어떤 스텁 템플릿을 사용해야 할지 궁리해 보면 매우 어려울 것이다.인간은 여전히 다른 범주를 추가하고, 유지 관리 템플릿을 추가하고, 좀 더 구체적인 스텁 태그를 사용해야 하기 때문에, 나는 이것이 어떤 가치를 더하는지 잘 모르겠다.Mr.Z-man 21:36, 2013년 12월 7일 (UTC)[응답]

그렇다, 봇으로 스텁을 안정적으로 분류하는 것은 거의 불가능하다.나는 그게 문제가 될 수도 있다고 생각했다.사용자:MenoBot II는 참조되지 않은 페이지에 대한 태그 지정을 제외하고 다른 많은 유지 관리 태그를 수행한다.기사에는 {{Reflist}}(또는 <참고/>), 참고문헌 섹션, 외부 링크 또는 추가 읽기가 포함되어 있지 않으면 반드시 99.99%의 미참고라고 생각한다. --Jakob(내가 망가뜨린 것에 대한 그림) 22:14, 2013년 12월 7일(UTC)[응답]

당신은 1만분의 1의 잘못된 긍정률을 어디서 얻으십니까?— HELLKOWNZ 22:46, 2013년 12월 7일 (UTC)[응답]

무작위 추정치.참고문헌은 보았지만 언급된 내용은 하나도 없는 기사를 본 적이 없다. --Jakob(내가 망가뜨린 것에 대한 그림) 22:47, 2013년 12월 7일 (UTC)[응답]

그런 다음 실제 악의로 이동하십시오. 여기서 인라인 인용문을 포함하지만 해당 인용문을 제대로 수집하지 않는 기사가 별도의 섹션에 표시되며, 그러한 섹션은 포함되지만 참조 목록 템플릿보다는 <참조 />를 사용하고, 섹션 제목에는 ==참조==를 사용한다.

다른 방향에서는 사용자 요소 중 하나를 포함하지만 실제로 참조되지 않는 요약(법률)을 참조하십시오.기사 작성 마법사로 인해 스크립트에 참조되지 않은 기사가 많이 누락될 수 있음.

이 물건들을 찾는데 그리 오래 걸리지 않았다.WhatamIdoing (대화)20:06, 2013년 12월 9일 (UTC)[응답]

@WhatamIdoing:실제 악의는 외부 링크를 포함하므로 참조된 것으로 간주된다.Reversible error에 대해서는 위의 파라미터를 편집했다.모든 봇들이 그렇듯이, 약간의 잘못된 긍정도 있을 것이다. 하지만 나는 그것이 매우 많지는 않을 것이다.현재 봇의 정확도는 96%로 쉽게 개선될 수 있다.봇은 AFC가 아닌 메인스페이스에서 작동하게 될 것이다. 2013년 12월 9일 20:25, 2013년 12월 9일 (UTC) [응답]

"외부 링크"는 다른 섹션 제목 목록에 있으므로, 나는 당신이 ==외부 링크==섹션이라고 생각했었다.

기사 작성 마법사는 AFC만을 위한 것이 아니다.마법사를 사용하여 주 네임스페이스에 직접 기사를 작성할 수 있다.WhatamIdoing (대화)20:36, 2013년 12월 9일 (UTC)[응답]

@King jakob c 2: - AutoWikiBrowser를 사용해서 태깅을 할 수도 있지만, 이 봇이 신참들을 물어뜯는 것으로 간주되는지를 고려해 보는 것이 좋다.GoingBatty (토크) 00:12, 2013년 12월 8일 (UTC)[응답]

@GoingBatty: 일리는 있지만, {{비참조}}}}은(는) 스터브, 고아, 범주화되지 않은 것을 추가하는 것보다 본질적으로 신참들에게 훨씬 더 불쾌하다고는 생각하지 않는다. --Jakob (내가 망가뜨린 것에 대한 향기) 00:32, 2013년 12월 8일 (UTC)[응답]

팝업 금지 제안

위키피디아에 와서 로그인하지 않을 때마다 돈을 요구하는 일종의 팝업창이 뜬다.웹 사이트에 이보다 더 짜증나거나 사용자 친화적이지 않은 것은 없다.나는 팝업 요청보다는 광고나 서비스 감소를 많이 보고 싶다.나는 팝업을 절대적으로 금지할 것을 제안한다.아폴로 (토크) 2013년 12월 10일 (UTC) 14:02 (답변)

WMF에 충분히 많은 기부금을 줘서 다시는 돈을 요구하지 않아도 된다면 그 문제를 해결할 수 있을 것 같아.--Jayron32 14:42, 2013년 12월 10일 (UTC)[응답]

내 생각에 선호에는 선택사항이 있다.내가 메가 슈퍼듀퍼 셋팅 복권에 당첨되면, 나는 팝업을 필요로 하는 것을 고칠 것이다.일부 다른 프로젝트에서 추가된 항목보다 낫다. DLOhcierkim 15:51, 2013년 12월 10일 (UTC)[응답]

큰 'X'를 치면 없어진다.레곡™ (대화) 19:04, 2013년 12월 10일 (UTC)[응답]

내가 가지고 있는 문제의 일부는 그것이 다른 특징들과 겹친다는 것이다.가끔 짜증날 때가 있어루시아 블랙 (토크) 19:07, 2013년 12월 10일 (UTC)[응답]

솔루션 = Preferences --> Gadgets --> [Checkbox] "모금자 배너 표시 억제" DLOhcierkim 19:21, 2013년 12월 10일 (UTC)[응답]

로그인하지 않은 상태에서는 IP가 기본 설정을 받지 못하기 때문에 이 옵트아웃은 작동하지 않는다.리드송독이 울부짖다!20:43,2013년 12월 10일 (UTC)[응답]

안녕 아폴로, 얼마나 자주 이런 일이 일어나니(하루에 한 번?일주일에 한번?다른 컴퓨터?다른 브라우저?모금현황은 알 수 없지만, 올해 초에는 로그인한 사용자 1000명 중 1명 꼴로 되어 있었고, 같은 컴퓨터/브라우저에서는 한 번도 한 번 이상 하지 않기로 되어 있었다.그것보다 더 자주 받는 거면 알려줘, 그럼 내가 누구랑 얘기해야 할지 알아낼게.Whatamidoing (WMF) (토크) 19:43, 2013년 12월 10일 (UTC)[응답]

또한, 우리는 진정한 팝업을 말하는 것인가, 아니면 단지 현수막인가?리드송도그컴 울부짖음!20:43,2013년 12월 10일 (UTC)[응답]

응, 사이트에서 진짜 팝업은 본 적이 없어.내가 문제가 있을 수도 있는 사람들.현수막은 죽은 말이다._{Piotr Konieczny aka Prokonsul Piotrus reply here} -- 2013년 12월 12일 (UTC) 04:39, 답신

12월은 매년 열리는 기부 운동이다.IP는 쿠키를 설정할 "X"를 클릭할 수 있어야 더 이상의 표시를 방지할 수 있으므로 쿠키를 지우면 다시 볼 수 있다.자세한 내용은 m:Funding 2013을 참조하고 m:에서 버그를 보고하십시오.토크:모금 2013.–Quiddity (대화) 21:16, 2013년 12월 10일 (UTC)[응답]

m:2013#Campaign Launch 업데이트 2013년 12월 2일, "배너들은 미국, 영국, 캐나다, 호주, 뉴질랜드에서 100%의 영어 독자들을 대상으로 운영될 것"이라고 명시되어 있다.GoingBatty (토크) 01:43, 2013년 12월 12일 (UTC)[응답]

아니면 계속 로그인해 계십시오._{Piotr Konieczny aka Prokonsul Piotrus reply here} -- 2013년 12월 12일 (UTC)[응답]

그 배너는 자바스크립트를 필요로 한다.자바스크립트가 없으면 현수막이 보이지 않는다.위에서 말한 Quidity가 말한 것처럼, 쿠키를 지우면 배너를 여러 번 볼 수 있다.@Whatamidoing (WMF): 최근에 살펴본 적은 없지만, 기금모금팀이 12월의 기금모금운동과는 반대로 얼마나 잘 작동하는지 X 이용자 중 1명의 아이디어를 실험하고 있었던 것으로 기억한다.불행히도 그것은 쿠키를 필요로 하기 때문에, 쿠키를 지우는 사람들은 벤너를 여러 번 볼 것이다.다른 컴퓨터에서는 두 번에서 일곱 번 클릭하면 배너가 보여.예를 들어, 나는 위키피디아에 있는 페이지로 가서 다른 기사에 대한 링크를 클릭해서 배너를 본다.현수막을 보기 전에 내가 할 수 있는 가장 많은 클릭은 7번 정도였고 가장 적은 것은 2번이었다.나는 처음 클릭할 때 배너를 본 적이 없다.나는 여러 기사를 클릭했기 때문에 항상 현수막을 본다.그래서 그런 의미에서 1대 1 비율이다.IMHO, 쿠키를 클리어(또는 장애인으로)하면 기금모금팀이 보게 될 결과가 왜곡될 것이라는 독자들.너는 아마 그들에게 그것을 언급하고 싶을 것이다.고마워. 64.40.54.101 (대화) 06:20, 2013년 12월 13일 (UTC)[응답]
그렇다, 이것은 알려진 문제다.쿠키를 비활성화하면 절대 쿠키를 얻을 수 없다.그러나 쿠키를 수락한 다음(예: 브라우저를 닫을 때) 지우기를 하면 '새로운' 사람처럼 보인다.(다른 사람이 Firefox가 '지금 아니면 영원히'가 아니라 'X일 후에 쿠키 지우기' 설정을 갖기를 바라는가?나는 일주일이나 한 달 동안 쿠키를 가지고 노는 것을 개의치 않는다. 나는 정말 WMF 쿠키[따라서 로그인 세션 길이!]가 30일 이상 지속되었으면 좋겠는데, 나는 20년 만기일에 짜증이 난다.)Whatamidoing (WMF) (토크) 18:06, 2013년 12월 13일 (UTC)[응답]
위키피디아를 보기 위해서만 사용할 때(내 개인 컴퓨터 이외의 기계에서는 로그인하지 않음), 나는 그 배너가 얼마나 끔찍하게 끔찍한지를 본 적이 있다.벡터의 느낌(추가 웹 2.0)과 충돌할 뿐만 아니라, 짜증스럽게 미니 배너로 변경되어 상단(닫지 않으면)의 밉살스러운 배너를 지나 스크롤할 때 화면 왼쪽 상단의 위치를 유지한다.정말, 모금팀?Killiondude (대화) 22:52, 2013년 12월 16일 (UTC)[응답]

웹 사이트 템플릿의 알렉사 순위

나는 왜 우리가 알렉사 순위를 사용하여 웹사이트를 묘사하는지 궁금했는데, 그 데이터를 제공할 수 있는 것보다 훨씬 더 정확하고 신뢰할 수 있는 서비스가 몇 개 더 있다.— Noamsp가 추가한 선행 서명되지 않은 의견(대화 • 기여)

예를 들어...- Ypnypn (대화) 16:24, 2013년 12월 11일 (UTC)[응답하라]

나는 몇 가지 예시를 바라고 있었다. DLOhcierkim 14:16, 2013년 12월 13일 (UTC)[응답]

웹 트래픽에 대한 우리의 기사#웹 트래픽 측정은 알렉사 인터넷과 닐슨 넷레이팅스만을 언급하고 있다.만약 실제로 "더 정확하고 신뢰할 수 있는 서비스"가 있다면, 그것들은 그 기사에 나열되어야 한다.'알렉사에게 대체적인 것'에 대한 웹 검색에서는 여러 후보가 올라온다. --Guy Macon (대화) 17:14, 2013년 12월 13일 (UTC)[응답]

노암스프가 유일하게 사인 안 한 편집인데 이게 얼마나 심각한지 모르겠다.{{Infobox 웹사이트}}}의 알렉사 파라미터를 가리키는 것 같다.실제 제안이 있는 경우 템플릿 토크에 게시하십시오.Infobox 웹 사이트.알렉사 파라미터는 이전에 논의된 적이 있다.프라임헌터 (토크) 2013년 12월 13일 (UTC) 18시 30분[응답]

기본적인 질문은 알렉시아 랭킹이 정말 그렇게 중요한가?웹 초기에는, 많은 웹사이트들이 그들의 알렉시아 랭킹에 대해 자랑하곤 했다.그러나 지금, 그것은 거의 언급되지 않았다.그렇다면 웹사이트에 관한 기사에서 알렉시아 순위를 제공하는 것이 과연 무슨 의미가 있을까?일반 독자들에게는 웹사이트에 대해 아무것도 알리지 않고, 일반 독자들에게는 의미 없는 숫자다.(대화) 23:17, 2013년 12월 15일 (UTC)[응답]

알렉사 또는 유사 웹 생산물과 같은 글로벌 순위는 높은 프로필 사이트(페이스북, 구글, 위키백과, 야후 등)의 관련성을 이해하는 데 적절하지만 목록에 있는 대부분의 사이트와 같이 소규모 사이트를 조사하는 경우에는 그렇지 않다.그러나, 실제 교통 번호를 보여주는 것이 더 흥미롭고, IMHO를 나타낸다.예를 들어, 두 서비스 모두 위키피디아의 세계 랭킹이 7이라는 것을 나타내지만, SamarousWeb도 실제 방문자 수를 추정할 수 있다(위키피아의 경우 2.4B).

편집 시 "미리보기 표시" 및 "변경사항 표시" 옵션 병합 제안

그것은 꽤 간단하지만 나는 우리가 그것으로부터 이익을 얻을 수 있다고 생각한다.우리가 역사 페이지를 볼 때나 우리의 감시 목록에서 선택사항들이 병합되어 있기 때문에, 우리가 편집할 때 왜 그것들을 분리해서 보관하는가?나는 이것이 그들이 조심스럽지만 가능한 한 빨리 끝내고 싶을 때 많은 시간을 절약할 것이라고 생각한다.루시아 블랙 (토크) 05:30, 2013년 12월 16일 (UTC)[응답]

미리보기를 페이지 아래로 이동시킬 수 있기 때문에 그것들을 병합하는 것에 반대하지만, 나는 쇼 변경 버튼이 비교 기록 기능처럼 작동하고 변경된 코드와 페이지/섹션의 미리보기를 모두 보여주도록 하는 것을 지지한다.VanIsaac_{WS Vex}^contribs 05:52, 2013년 12월 16일 (UTC)[응답]

반대파는 지지만큼 강하지 않다.난 개인적으로 상관없어.때로는 미리보기 전에 그 변화를 볼 필요가 있다.아마도 제안된 합병과 이미 합병된 합병에서 변경 옵션에 대한 담합성은 역사 페이지의 미리보기 링크와 우리의 감시 목록의 차이 링크와 같은 것이다.루시아 블랙 (토크) 05:56, 2013년 12월 16일 (UTC)[응답]

난 이걸 원하지 않아.이런 식으로 대형 기사를 관리하기는 어려운데, 특히 여러 군데를 변경하면 더욱 그렇다.

하지만, 나는 옛날 옛적에 그것을 원하는 사람들에게 이 옵션을 제공하는 (대부분 인기가 없는) 프리프 설정이나 스크립트가 있다고 생각했다.나는 지금 그것을 찾을 수 없다.WhatamIdoing (대화)20:09, 2013년 12월 16일 (UTC)[응답]

나 역시 이것에 반대한다.열 번 중 아홉 번, 내가 원하는 것은 미리보기일 뿐이고, 스크린에 디프트를 띄우는 것은 원하지 않는다.내가 한번 변화를 보여주고 싶을 때, 내가 가장 관심 있는 것은 변화인데, 대개 단어나 기술적인 것을 대신했기 때문이고, 그 다음에는 시사회를 원하지 않는다.그들은 두 개의 분리된 도구인데, 나는 일반 대중을 위해 그것들을 합쳐서 무엇을 얻어야 하는지 모르겠다.—C.Fred (대화)20:15, 2013년 12월 16일 (UTC)[응답]

나는 WhatamIdoing에 동의한다.큰 기사에 대한 많은 변화를 위한 디프플렉스 프리뷰를 하는 것은 스크롤하기에 많은 것이 될 수 있다."아래 페이지 콘텐츠를 표시하지 않음" 기본 설정 옵션이 있어 감시 목록/내역의 차이 링크가 페이지가 아닌 차이만 표시되도록 할 수 있다는 점에 유의하십시오.두 개의 버튼이 있는 이유는 그들이 두 가지 다른 일을 하기 때문이고 당신은 항상 두 가지를 모두 사용할 필요가 없다.미스터 지맨 20:24, 2013년 12월 16일 (UTC)[응답]

제안된 편집 공간과 diff/prev 공간 모두에 대해 diff를 접을 수 있다면 모두 지원하시겠습니까?만약 누군가가 대규모 변화를 일으켜 미리보기와 차이점을 모두 봐야 한다면, 그것은 필요할 것이다.계속 오타 같은 걸 하는 사람을 위해서.또는 인용에서 실수를 한 경우.디프는 때때로 결점을 바로 보여주지 않는다.하지만 난 타협할 것이다.우리는 두 가지를 동시에 볼 수 있는 선택권을 가져야 한다.루시아 블랙 (토크) 21:08, 2013년 12월 16일 (UTC)[응답]

아니야. 아직 diff를 생성해서 데이터를 전송해야 하니까 시간이 좀 걸려.아니면 디프프레이만 원해도 미리보기를 생성해야 한다.당신은 여전히 모든 사람들이 소수의 사람들에게만 더 효율적이고 다른 모든 사람들에게 더 느린 시스템을 사용하도록 강요받고 있는 것 같다.누군가 이것을 하기 위해 대본을 만들고 싶다면, 그것은 괜찮을 것이다.그러나 소프트웨어에서 이것을 지원하는 유일한 방법은 기본적으로 사용하지 않는 사용자 선호도가 있는 경우일 것이다.미스터 지만 21:42, 2013년 12월 16일 (UTC)[응답]

스피드는 과거에 실제로 제안을 중단한 적이 없다.그러면 페이지가 상당히 느려진다는 말씀이세요?어쨌든 옵션을 제안하는 겁니다.이걸로 널 먹여 살리지 말자.그러면 기본적으로 비활성화된 기본 설정일 경우에만 지원하시겠습니까?그 knd는 디폴트로 비활성화되지는 않을 것이다.하지만 선호를 바꾸면 아픈가?또 다시...나는 가냘픈 이유를 근거로 강한 반대를 느낀다.루시아 블랙 (토크) 21:51, 2013년 12월 16일 (UTC)[응답]
과거에는 속도 때문에 제안이 꽤 많이 사라졌다.아마도 너는 그들을 기억하지 못할 것이다.그리고, 그렇다, 이것은 페이지의 검토 편집 시간을 상당히 느리게 만들 것이다. 특히, 차이점을 보고자 하는 사람들을 위해서 말이다.지금은 버락 오바마(악명높게도 복잡한 페이지)에 대한 불안감이 12초 정도 걸린다.페이지 미리보기는 34초가 걸린다.내가 원하는 디프트와 내가 원하지 않는 프리뷰를 동시에 공급할 수 있는 방법은 단 한 가지만 주는 것에 비해 22초라도 낭비하지 않고서는 없다.미리보기를 접어도 시간에 큰 차이가 없다.매 페이지마다 편집 리뷰를 하나씩 달고 시간을 허비하는 것에 대한 나의 반대는 단지 내가 원하지 않는 미리 보기를 제공하기 위해서가 아니다.스크롤을 훨씬 더 많이 해야 한다는 두어 사람의 반대도 이를 반대할 '약소한 이유'가 아니다.스크롤은 시간이 많이 걸리고 특정한 종류의 장애를 가진 사람들에게 심각한 문제가 될 수 있다.
둘 다 원하면 둘 다 받는 거에 반대하지 않아.WP를 작성할 수 있도록 코딩 방법을 자유롭게 배우십시오.이 작업을 직접 수행하기 위한 사용자 스크립트.그러나 나는 당신이 나의 diff 전용 리뷰에 대한 접근을 취소하는 것에 강력히 반대한다.
마지막으로, 이런 종류의 변화를 요구할지는 보통 토론을 위해 나타나는 사람들의 희망에 의해 결정되는데, 지금까지는 오직 당신만이 이 생각을 거리낌 없이 지지한다.당신의 아이디어를 거절하는 것은 Mr.Z-man을 만족시키는 예가 아니다. 대신, 그것을 받아들이는 것은 당신을 만족시키는 예가 될 것이다.WhatamIdoing (대화) 22:43, 2013년 12월 16일 (UTC)[응답]
아니. 그 시스템은 이미 여러 가지 이유로 느리다. 우리는 다른 것을 추가할 필요가 없다.Killiondude (대화) 22:46, 2013년 12월 16일 (UTC)[응답]

그렇지는 않지만, 일반적인 생각은 시간을 절약하는 것이다.그리고 만약 당신이 diff만 보고 싶었더라도, 그것 또한 선택사항으로 유지함으로써 정리될 수 있다.하지만 우리도 현실적이 되자.당신이 버락 오바마 기사를 오프닝 포스트에서 바로 참조 페이지로 편집한다고 가정해보자.12초 이상 걸리는데, 단지 디프트에 실수가 없었는지 확인하기 위해서, 특히 인용문을 덧붙일 경우, 미리보기가 더 필요할 것이다.또한 현실적으로 오바마의 막사 페이지를 살펴본 결과, 당신이 주장하는 것보다 훨씬 더 적은 시간이 소요될 것이라는 점을 고려해 보자.시간이 더 오래 걸린다면, 그냥 끝내는 것이 아니라, 양쪽을 다 사용하고 그것을 철저히 보기 때문이다.

하지만 나는 너의 지지를 사심 없이 받았으면 좋겠어. 결국 지금 타협은 선택권을 갖는 거야.만약 네가 나를 지지한다면 그것은 나를 "감정"하는 것이 아니다. 왜냐하면 그것은 나에 대한 것이 아니라 그것을 필요로 하는 사람들에 대한 것이기 때문이다.반면에 어떤 사람들은 선택적이고 자동적으로 장애인이 되는 것과 같은 비현실적인 조건을 만드는 것은 내가 그것을 고칠 수 없을 때에만 말하는 것과 같다.

나? 난 그게 충분히 유용하다고 생각해, 뉘앙스?처음에는 그럴지도 모르지.하지만 다른 사람들은 그것에 대한 필요성을 알지도 모른다.네가 둘 다 원한다면, 난 네가 둘 다 받는 것에 반대하지 않아. WP를 작성할 수 있도록 코딩 방법을 자유롭게 배우십시오.이 작업을 직접 수행하기 위한 사용자 스크립트. 그러나, 나는 다른 편집자가 기꺼이 그것을 할 수 있는 한 지원자로서 당신이 나의 diff 전용 리뷰에 대한 접근을 취소하는 것에 강력히 반대한다.

킬리웃두드.공급자나 컴퓨터일거야 인터넷아마 너의.하지만 여기있는 모든것들은원활하게 작동해.게다가 그것은 기술적으로 이미 존재하는 옵션이다.루시아 블랙 (토크) 23:00, 2013년 12월 16일 (UTC)[응답]

lol. Killiondude (대화) 23:03, 2013년 12월 16일 (UTC)[응답]

나는 오늘 조금 늦게 이것에 대한 사용자 설명서를 코딩하는 것에 대해 알아볼 수 있다.쓸모가 있을 거라는 걸 알고 있고, 그렇게 힘들 것 같지는 않아.하지만 나는 그것이 가젯이 되어야 하는지 아니면 다른 기본 기능이 되어야 하는지 모른다.2013년 12월 16일(UTC) 23시 5분, Writ Keeper ⚇[응답]

사용자의 경우 제안할 수 있는 대로 사용자가 디프, 미리보기 또는 둘 모두를 지정할 수 있도록 확인란 한 쌍이 있을 수 있는가?또는 경우에 따라 선택할 수 있는 다른 인터페이스(채무불이행에 대한 선호도)도 있다.DES ^(talk) 00:42, 2013년 12월 17일 (UTC)[응답]

@루시아 블랙:@DESiegel:됐어, 대본은 여기 있어설치하기 위해, 설치importScript("User:Writ Keeper/Scripts/previewAndDiff.js"); common.js 페이지로 이동하여 필요한 경우 캐시를 바이패스하십시오.현재 "show preview" 및 "show changes" 버튼 옆에 있는 세 번째 버튼이 표시되며, 스크립트는 여전히 원하는 경우 하나를 선택할 수 있도록 해준다.당신의 의견을 저에게 알려주십시오.2013년 12월 17일(UTC) 10:56, Writ Keeper ⚇[응답]

그래, 고마워.이것에 감사드립니다.그래도 대본을 다른 사람에게 광고하는 방법은 없을까.혹시 같은 생각이 들까 봐?루시아 블랙 (토크) 15:19, 2013년 12월 17일 (UTC)[응답]

부적절한 페이지 필터링

일어나지 않을 것이다.WP 참조:NOTCensored, WP:PEREN#내용 경고, WP:PEREN#Censor 공격 이미지.Anomie december 13:04, 2013년 12월 20일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

나는 이 위키에 실린 몇몇 기사들이 특정 기고자들에게 부적절하다는 것을 알고 있다.등록되지 않은 (익명) 사용자와 사용자가 미성년자를 등록하여 이러한 위키백과 페이지를 보지 못하도록 검색 필터링을 요청한다.또한 명시적인 성인 콘텐츠에 대해 사용자에게 경고하는 템플릿을 요청하고 있다. -- Ismael755 — Ismael755 (토크 • 기여) 04:17, 2013년 12월 20일 (UTC)[응답]

투표

NOTCENSORED에 따라 반대 및 스노우 클로즈.기술 13 (대화) 04:34, 2013년 12월 20일 (UTC)[응답]
코멘트 우리는 최근에 이러한 끊임없는 논의들 중 또 다른 하나를 했다.위키피디아는 검열되지 않고 그냥 지금 닫으면 안 될까?GenQuest 07:30, 2013년 12월 20일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

유사 네임스페이스 리디렉션

마을 펌프에는 현재 RFC가 개설되어 있어 여러분이 참여하고 싶어할 수도 있는 논란의 사이비 네임스페이스 리디렉션에 대한 현재의 의견과 정책을 명확히 하고 있다.TeleComNasSprVen (대화 • 기여) 23:48, 2013년 12월 20일 (UTC)[응답]

대화 페이지로 고아 태그를 이동하도록 제안

고아 태그를 봇을 포함한 토크 페이지로 옮기자는 공감대가 형성돼 있다.'소규모 유지관리 템플릿'의 어떤 종류의 새로운 클래스를 만들자는 다양한 제안이 있었지만, 광범위한 지지를 얻지 못했다.라마수드2000 20:41, 2013년 12월 19일 (UTC)[응답]

다음의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

위키백과의 대화에서 다시 게시:위키프로젝트 고아원, 보다 넓은 시야 확보

안녕. 짧게 빨리 할게.나는 아직도 얼마나 유용한지 몰라 안간힘을 쓰고 있어.{{Orphan}}태그는.그것은 크고 추하며, 대부분의 경우 해결책이 없다는 매우 사소한 문제를 걱정한다.어떤 기사는 단순히 다른 위키백과 기사에 언급되지 않은 주제에 관한 것이다.위키백과의 매우 많은 백로그:위키프로젝트 고아원은 분명히 하고 있다.막연하게만 관련성이 있는 곳에서도 편집자에게 링크시키거나 추가하도록 강요하는 것은 좋은 관행은 아니다.독자들 중 어느 누구도 상관하지 않지만, 그 페이지에서 태그를 먼저 봐야 하는 것은 그들이다.만약 그것이 출처의 문제였다면, 나는 독자들이 그것에 대해 알아야 할 것처럼 이해했을 것이다.그러나 충분히 연계되지 않는 것은 기사를 방어할 만한 가치가 있는 심각한 문제가 아니다.

나는 글의 가독성에 미치는 영향을 최소화하기 위해 태그 자체를 토크 페이지로 이동할 것을 제안한다.

이 작업이 어떻게 수행될 수 있는지 잘 모른다는 점에 유의하십시오(아마도 봇에 의해 수행될 수 있는가?)나도 이것을 정식 제안으로 만들 시간이 없지만, 그렇지 않으면 완벽하게 훌륭한 기사들을 항상 보는 것에 질렸을 뿐이다.다른 사람들은 어떻게 생각하나?-- OBSIDIAL 01:41, 2013년 11월 14일 (UTC)[응답하라]

나는 다른 모든 콘텐츠 공지사항과 정확히 동일하게 포맷되고 텍스트 높이가 겨우 두 줄인 템플릿이 어떻게 "크고"하고 "못된" 것으로 해석될 수 있는지 상상할 수 없다.나는 기사 페이지가 도움이 될 수 있는 유일한 장소라고 주장한다.만약 원작자나 다른 기고 편집자들이 적절했던 수신 링크를 생각했다면, 그들은 아마 이미 그것을 했을 것이다.관련 기사를 읽고 나서 표면적으로는 고아 페이지를 찾아내는 드라이브 바이 리더인데, 이 일은 꼭 해야 한다는 것을 알아야 한다.즉, 해당 공지사항의 작업에 토크 페이지가 완전히 불충분하다는 것을 의미한다.VanIsaac_{WS Vex}^contribs 02:38, 2013년 11월 14일 (UTC)[응답]

그것은 정확히 같은 방식으로 포맷되지만 동일한 문제에 대해서는 포맷되지 않는다.충분한 참고문헌, 부적절한 언어, 가능한 COI, 이것들은 독자에게 주목받을 권리가 있는 템플릿이며 그들이 읽으려던 내용이 그렇게 믿을 수 없거나 나쁜 상태에 있지 않을 수 있다는 가능성에 대한 경고로서 기사를 읽기 전에 소리를 질러야 한다.

하지만 고아들은?정말?그 기사들은 문제가 있거나 완전히 접근하기 어려운 내용들이 있는 것은 아니다.사실상 모든 독자들은 검색엔진을 통해 기사를 얻지만, 어디선가 위키링크를 클릭하는 것은 아니다.그리고 또 어떤 기사들은, 단순히 다른 곳에서는 위키링크를 할 수 없다.그게 정확히 뭐가 문제야?단지 태그가 당신이 그것을 연관시킬 필요가 있다고 말해준다는 이유 때문에 멀리 떨어진 관련 기사를 다른 기사로 바꾸는 것은 훨씬 더 많은 문제가 있다.나는 이런 현상을 작은 고도로 전문화된 기사가 언급조차 되지 않고 단지 태그가 지시한다고 해서 모호하게만 관련성이 있는 그들의 창작자에 의해 수준 높은 기사와 연결될 때 보았다.

일반 독자에 대해서는, 그들이 그것이 무엇에 쓰이는 것인지 알고 있거나 신경 쓸 것인지에 대해 매우 의심스럽다.그리고 다시 말하지만, 백로그로부터 (우리 기사들 중 12만개 이상이 이 태그를 가지고 있는데, 자동화된 도구와 드라이브-태깅의 증가로 2007년부터 거슬러 올라가면), 그들은 그것을 고칠 수 없거나 (대부분의 경우) 고칠 수 없을 것이다.그들은 기본적으로 영원히 그곳에 머무를 겁니다.

독자가 읽고 있는 글이 고아라는 것을 알아야 하는 좋은 이유를 하나 대라.그리고 왜 그렇게 다급하게 알아야만 하는지, 커다란 노란 위협 표지판이 달린 버스 크기일 수밖에 없다.

그렇다, 그것은 가독성에 영향을 준다.기사 작가로서는 이런 일은 극도로 귀찮다.토크 페이지가 아니라면 스터브 경고 같은 것은 어떠세요?단조로운 물건의 맨 아래에 있는 것.적어도 그것들은 본문 뒤에 배치되어 있고 방어적이지 않을 정도로 충분히 작다.

이것에 대해 불평한 것은 내가 처음이 아니다.템플릿 토크 참조:고아, 그리고 이것은 위키피디아에서 AFAIK(편집자 입력 IMO가 충분하지 않았음에도 불구하고) 이전에 최소한 한 번 제안되었다.토론/Log/2013년 1월 5일 템플릿:고아 배치 논의… 2013년 11월 14일 (UTC) 03:18, 답변

그리고 만약 여러분이 이전의 모든 토론들을 실제로 읽었더라면, 위키피디아에 대한 수많은 링크들을 보았을 것이다.다년제 제안#유지관리 태그를 대화 페이지로 이동, 이것이 왜 나쁜 생각인지 정확히 설명한다.VanIsaac 04:28, 2013년_{WS Vex}^contribs 11월 14일 (UTC)[응답]

다른 방법은 태그를 "범주 없음" 태그 근처로 이동하는 것이다.카테고리와 연결은 기사가 처음 작성될 때 동시에 이루어지는 경우가 많으며, 이것은 페이지 상단의 태그에 의해 지적되는 내용 문제와 구분된다.—앤 들롱 (대화) 04:36, 2013년 11월 14일 (UTC)[응답]

나는 "Offan 기사", "Deletion provider" 등의 간단한 바만 "Offan 기사", "Deletion provider"라고 되어 있는 유지 관리 태그가 기본적으로 자동화된 다음, 세부 정보를 얻을 수 있도록 표준 "show" 버튼을 갖는 것이 행복할 것이다.분명히 이 대화에서 우리가 수립할 수 있는 것보다 훨씬 더 큰 합의가 필요하겠지만, 125,000개의 기사를 수정하기 위해 봇런을 요구하지 않는 이점이 있고, AWB와 같은 도구의 재프로그래밍, 그리고 모든 (도젠스?수백?) 기사 태그를 지정하는 도구 및 봇.VanIsaac 08:52, 2013년 11월_{WS Vex}^contribs 14일 (UTC)[응답]

이게 다년생 식물이야?왜 나는 그것에 놀라지 않았을까.그것만으로도 정말 문제가 있다는 것을 배반한다, 그렇지 않은가?그러나 그렇다, 안네 들롱의 생각은 지금 우리가 가지고 있는 것의 측면에서 훨씬 더 낫다.자기공명증도 낫겠다.저 미친 듯이 눈에 띄는 것 외에는 아무거나 "알려줘! 이 페이지는 가장 불쾌한 방법으로 알아야 할 아주 작은 문제가 있다(2013년 11월).그냥 행진곡만 빠지고 라스베가스 간판일 수도 있어. -- OBSIDIAL 12:46, 2013년 11월 14일 (UTC)[응답]

"orphan" 태그는 사소한 문제를 지적하는 반면, 다른 태그들 중 일부는 광고와 언급이 없는 것과 같은 주요 문제를 지적한다.나는 이것이 무너져야 한다고 생각하지 않는다.고아 태그를 맨 아래로 이동 정보:나는 이것이 절대적으로 일관적이라는 것이 중요하지 않을 것이라고 생각한다.반드시 다른 봇이나 대본을 모두 바꾸지 않고, 아마도 일주일에 한 번 또는 심지어 매달 한 번 실행된 새로운 봇은 마지막으로 실행된 이후 고아 태그가 놓여 있던 기사를 확인하고 태그를 맨 아래로 옮길 수 있었다.만약 몇몇이 놓쳤거나 몇몇이 다른 봇들에 의해 움직였다면 그것은 여전히 개선일 것이다.오래된 태그는 링크가 추가되면서 점차 사라지곤 했고, 어느 순간엔가 한번 달린 봇이 몇 년 전에 남겨진 것을 잡을 수 있었다.그냥 머리 위로 떠드는 소리야...—안네 들롱 (대화) 14:08, 2013년 11월 14일 (UTC)[응답]

응. 위에서 말한 것처럼, 나는 사실 미참조, COI, POV 등의 태그에는 문제가 없어.글의 실제 내용에 영향을 미치기 때문에 독자들이 그것에 대해 알아야 하는 것은 지극히 타당하다.하지만 고아들은 사실 그 내용과 아무런 관련이 없으며, 기사의 자연적인 진화에서 결국 사라지게 되는 것은 아주 사소한 문제다.영원히 연결되지 않을 가능성이 매우 낮고, 그 위에 붙은 고아 태그는 영구적이고 불합리하게 된다.-- OBSIDIALSOUL 21:22, 2013년 11월 14일 (UTC)[응답]

표(고형 태그)

지지하다.고아를 다른 곳으로 옮겨라.모든 방문객에게 일일이 소리지르지 않아도 된다.Rmhermen (대화) 2013년 11월 14일 (UTC) 17:24 [응답]

모든 BLP, 기업 및 조직(고아들은 내 경험상 탈고정될 가능성이 가장 낮음) 및/또는 탈고정화 시도 여부 지원.태그가 페이지에 "있어야" 하는 이유는 우리는 문제를 해결하려고 노력함으로써 "독서자"가 "편집자"로 변하기를 바라고 있기 때문이다.그러나 (분명히) 문제를 해결할 수 없다면 IMO는 태그를 안전하게 다른 곳에 배치할 수 있다(또는 제거해도 나중에 바쁜 사람이 대신할 수도 있다).WhatamIdoing (대화) 18:44, 2013년 11월 14일 (UTC)[응답]

주석 – 편집자가 탈부착을 시도했다고 주장하기 위해 사용할 수 있는 매개변수가 있다. 이 매개변수를 사용하면 {{Ambox}}이(가) 사라지고 카테고리를 채운다.탈동형 시도.예를 들어, 이 차이점을 참조하십시오.Wbm1058 (대화) 15:28, 2013년 12월 4일 (UTC)[응답]

나는 또한 스터브 태그의 줄을 따라 페이지 하단으로 이동시키는 아이디어를 지지한다.WhatamIdoing (talk) 01:15, 2013년 12월 6일 (UTC)[응답]

지원 고아 태그들은 항상 나를 매우 낮은 가치와 집중을 방해한다고 짜증나게 했다.우리는 그것에 대해 알고 싶어하는 사람들을 위한 기기를 가질 수 있지만, 적어도 99%의 독자들은 신경 쓰지 않을 것이다.탈동형화 시도 여부와는 상관없다. 다른 곳에서 기사를 연결시킬 필요가 없다.Graeme Bartlett (대화)20:33, 2013년 11월 14일 (UTC)[응답]

지원 I는 "최소 유지관리 태그"의 범주 또는 클래스를 별도로 만들어 다르게 처리하고 템플릿 코드를 재구성하여 디스플레이를 변경하여 방해 요소를 줄이거나 봇을 사용하여 토크 페이지로 이동시킬 수 있다.DES 21:54, 2013년 11월 14일 (UTC)[응답]

Graeme Bartlett당 지원.쿠드풍 กุผึ ( ((대화) 06:24, 2013년 11월 15일 (UTC)[응답]

그것을 찾는 데 다소 시간이 걸릴 수도 있지만, 나는 4, 5년 전에 정확히 같은 제안을 한 것을 기억한다.다른 태그와 달리 고아가 되는 것은 독자들에게 알려야 할 중요한 정보가 아니다.우리는 탭 페이지나 깨진 괄호 링크에 대한 공지사항과 같은 방식으로 다루어야 한다. 단지 그것을 토크 페이지에 올리면 결국 처리될 것이다.비블브록스 (대화) 19:57, 2013년 11월 15일 (UTC)[응답]

결국 땅을 파는데 별로 걸리지 않았네, 여기 봐.비블브록스 (대화)20:01, 2013년 11월 15일 (UTC)[응답]

DES별 지원 --NeilN 21:34, 2013년 11월 15일 (UTC)[응답]

다른 사람들을 위한 지원.독자는 신뢰성에 대해 염려할 이유를 제공하는 유지관리 태그(Ref, POV 등)를 보아야 한다.그러나 이와 같은 태그를 대면하는 편집자는 편집자 영역, 즉 토크 페이지에 보관해야 한다.Resolute 21:39, 2013년 11월 15일 (UTC)[응답]

완전히 제거 지원 - 다음과 같은 다른 유지 관리 템플릿과는 달리 "Ophan" 템플릿{{ref improve}}또는{{COI}}(이러한 예)는 전혀 새로운 정보를 제공하지 않는다.다른 템플릿은 다른 곳에서는 획득할 수 없는 유용한 정보를 제공하는 반면(예를 들어, 관심의 충돌을 자동으로 감지할 수 있는 봇은 없다), 고아 템플릿이 하는 모든 것은 위키백과 API나 Special을 통해 이미 볼 수 있는 하나의 데이타포인트를 제공하는 것이다.WhatLinksHere.또한 템플릿이 제거될 경우, 여전히 고아를 보고자 하는 사람들을 위해 고아 통지가 적재 시 자동으로 고아 통지의 맨 위에 삽입되도록 사용자 설명서를 개발하는 것은 사소한 일일 것이다.Theopolisme (talk) 00:19, 2013년 11월 16일 (UTC)[응답]

지원 위의 주장에 동의한다.너무 많은 기사들은 정당한 이유 없이 사형에 처해지고 고아 태그와 같이 관련성이 가장 낮은 기사들은 도움을 주는 것보다 해를 끼칠 수도 있다.토크 페이지에는 이미 DAB 링크 및 커먼스 이미지 삭제와 같은 링크 관련 유지 관리 태그 및 공지사항(예: --ELEKH^T 00:24, 2013년 11월 16일(UTC)[응답]

지원 기사 공간에 보관하는 태그 수가 적을수록, 기사 자체는 독자의 기사 사용에 영향을 미치는 필요한 템플릿(예: NPOV)만 가지고 있어야 한다.여기에는 참조되지 않음과 같은 태그도 포함될 수 있으며, 이러한 태그는 신뢰성에 대한 경고 역할을 하기 때문이다.여기에는 개선이 필요할 수 있는 순수하게 기술적인 문제 중 어떤 것도 포함시켜서는 안 되며, 독자들에게 즉시 영향을 주어서는 안 된다.어느 방향이든 적절한 링크를 갖지 못하는 것은 대부분의 기사에 최적이지는 않지만, 그것은 편집자에게만 직접적으로 영향을 미친다. DGG (토크 ) 00:49, 2013년 11월 16일 (UTC)[응답]

지지하다.보통 내 입장은 "기사에 태그가 많으면 많을수록 좋다!"에 가까울 수도 있지만 고아 태그는 예외다.첫째로, 그것은 기사 자체에 어떤 문제가 있음을 나타내지 않는다 - 다른 곳에서 연계가 되지 않는다는 사실은 위키백과의 나머지 부분에는 문제가 될 수 있지만, 그 기사에는 문제가 되지 않는다.둘째, 기사 자체에 태그를 부착해야 하는 주요 이유 중 하나는 여기에 적용되지 않는데, 문제를 수정하는 사용자는 태그를 볼 가능성이 높지 않기 때문에 이 배치에서는 태그가 적용을 중단할 때 제거하도록 권장하지 않는다.셋째, 들어오는 링크가 없는 것은 그리 큰 문제가 아니다.사실, 봇이 관리하는 리스트는 이 태그를 대체하는 것이 좋을 것 같아...말이 나와서 말인데, 러시아어 위키피디아는 "고형"이 아닌, 극히 제한된 양의 다른 기사에서만 도달할 수 있는 기사를 찾는 프로젝트를 하고 있다(Ru:пп пп пп пп пп: :::::::::::::::::::::::::::::::::::::::ииоирееее,, ru, ru ru ru, ru:пр::::Связность).아마 "고형" 기사들과 일하는 것을 좋아하는 사람들은 한 번 보고 싶어 할 것이다.? --Martynas Patasius (talk) 02:49, 2013년 11월 16일 (UTC)[응답하라]

러시아 프로젝트는 실제로 논란이 되고 있는데, 많은 성악 편집자들이 어떤 맥락에서든 "연결성"에 대해 언급하는 것에 대해 대다수의 편집자들이 떨기 시작할 정도로 밀어붙이기 시작했다.-Ymblanter (대화) 12:02, 2013년 11월 16일 (UTC)[응답]

"지지"Anne Delong,Reso,ELEKHH,Martnas,Rmhermen. --andrea 편집 (토크) 05:58, 2013년 11월 16일 (UTC)[응답]

지원, 제공된 주장은 사실 꽤 타당하다.--Ymblanter (대화) 12:02, 2013년 11월 16일 (UTC)[응답]
기사가 고아라면 그 주제의 공신력에 대해 뭐라고 쓰여 있다고 생각하는 내가 느끼기에 반대하라.만약 이 주제가 다른 수백만 개의 주제와 연관될 만큼 충분히 눈에 띄지 않는다면, 얼마나 "알려지지" 않을 수 있는가?그래서, 나는 그것을 기반으로 토크 페이지로 옮겨지는 것에 반대한다.붕괴에 관해서는, 나는 그것이 어떻게 가능한지 제대로 보지 못했다.나는 이 템플릿의 사용의 "대부분"이 {{Multiple problement} 그룹의 내부에 있기 때문에 이미 한 줄로 잘려져 있다고 감히 말하고자 한다.나는 그것이 외로운 템플릿이 될 수도 있고 다른 문제가 없는 기사일 수도 있다고 생각하지만, 그것은 나에게 전혀 일어날 것 같지 않다.기술 13 (대화) 15:51, 2013년 11월 17일 (UTC)[응답]
- 기사의 주제가 불통으로 의심될 경우 관련 템플릿은 {{notability}}}이다.기사가 고아인지 정말 알아야 한다면 다음과 같은 간단한 기술적 해결책이 있다.특수:여기 뭐가 있지?Ke novemberr 17:05, 2013년 11월 17일 (UTC)[응답]
  - 그렇다면 기사 페이지에는 어쨌든 여러 가지 이슈가 있고 두 가지 템플릿을 만들기 위해 두 가지 편집을 할 필요가 없다. 하나는 기사 페이지와 다른 하나는 불필요한 편집 수를 늘리기 위한 것이다.이것의 핵심은 작업과 템플릿 크기를 줄이는 것이다.두 번을 따로 편집해서 취지를 꺾어야 한다.기술 13 (대화) 15:45, 2013년 11월 19일 (UTC)[응답]

호카이. 그건 좀 복잡한 논리야.첫째, 고아 태그가 존재할 때 다른 문제들도 존재해야 한다고 가정하는 것이다.너도 알고 있잖아{{Multiple issues}}!={{Orphan}}그렇죠?둘째로, 이미 언급했듯이, 공명은 완전히 별개의 문제(그리고 훨씬 더 심각한 문제)이다.기사가 다른 기사의 링크를 가질 수 없거나 그렇지 않은 이유는 주제가 얼마나 주목할 만한지와는 관계가 없다.그것은 대개 그들이 매우 전문적이기 때문이거나 혹은 우리가 아직 관련 주제에 대한 충분한 기사를 가지고 있지 않기 때문이다.그렇다, 믿기 어려운 만큼, 위키피디아는 아직 완성되지 않았다.왜냐하면 모든 고아들이 불성실하다면 지금쯤 모두 삭제되었어야 했기 때문이다.셋째, 고아들은 이미 여러 페이지를 편집하도록 요구한다.사실 여러 이슈 태그에서 찾을 수 있는 다른 문제들과 달리 고아들은 다른 기사들을 편집하도록 요구한다는 점에서 독특하다.현재 고아인 기사는 아니다.그리고 내가 아는 한 탈형성술은 주기적인 봇 가동으로 이루어진다.

그리고 마지막으로, 이 제안의 핵심은 다른 이슈에 속하지 않는 "이슈" 중 하나를 제거함으로써 작업과 템플릿 크기 또한 줄이는 것이다.우선 순위도 아니고 일반 독자들이 알아야 할 사항이다.또한 미분류, 스터브 상태, 사진 부족, 낮은 내부 기사 평가 등급 등을 현장에 배치하지 않는다.{{Multiple issues}}템플릿 우리? -- OBSIDIAL 04:22, 2013년 11월 22일 (UTC)[응답]

약한 지지, 고아가 되는 것은 그리 급한 일이 아니며, 예를 들어 {{unreferenced}}}}과 달리 독자는 그것에 대해 경고를 받을 필요가 없다고 생각한다.Ke novemberr 17:05, 2013년 11월 17일 (UTC)[응답]
Graeme Bartlett & DES. →Davey2010→→→Talk to me!→ 00:57, 2013년 11월 18일 (UTC)[응답]
기사 상단에 있는 메시지를 토크 페이지에 올리거나 템플릿에 단순히 "숨겨진 범주"를 추가하되 아무것도 표시하지 않도록 하는 방법으로 삭제하는 것을 지원한다(예: {{coord missing}).독자는 단지 이 정보가 필요하지 않으며, 그것은 글에서 멀어지게 한다.대부분의 유지 관리 태그는 기사에 발생할 수 있는 문제에 대해 독자들에게 경고하고, 이에 대해 주의를 기울여야 한다.어떤 기사도 그것에 연결되지 않는다는 사실은 독자와 무관하다.PamD 22:55, 2013년 11월 18일 (UTC)[응답]
마르티나스 파타시우스를 지지하십시오.– Quadell 01:29, 2013년 11월 19일 (UTC)[응답]
지지하다.다른 페이지의 문제를 자세히 설명하는 페이지에 태그를 붙이는 것은 항상 명백히 어리석은 것처럼 보였다.:) 프로톤크 (대화)20:20, 2013년 11월 20일 (UTC)[응답]
지원 나는 독자들에게 이것에 대해 경고할 필요가 없다고 생각하는데, 고아 태그는 접선 관련 페이지에 의심스러운 링크를 추가하도록 장려한다. --Cerebellum (대화) 01:53, 2013년 11월 26일 (UTC)[응답]
지원, 위와 같은 Rmhermen의 의견에 동의한다.건배, —— Cirt (대화) 18:49, 2013년 11월 26일 (UTC)[응답]
지원하거나 템플릿 전체를 삭제하십시오.그것은 그 유용성보다 오래 지속되어 왔다.칼다리 (대화) 2013년 11월 27일 00:57 (UTC)[응답]
지지하다.실제로 유용한 정보를 제공하지 않거나 실행 가능한 솔루션을 제공하지 않기 때문에 템플릿 삭제를 지원할 수 있다(이미 주제를 언급한 기사를 찾기는 어려울 수 있음).실크토크 01:54, 2013년 11월 27일 (UTC)[응답]
서포트 제거 작업을 모두 수행하십시오.경고 태그는 독자에게 영향을 미치는 문제에만 사용해야 한다.또한 기존의 고립된 태그는 종종 경험 없는 편집자들이 부적절한 내부 링크를 만들도록 이끈다.적절한 기사가 존재하지 않는다면 내부 링크를 삽입할 필요가 없다는 것을 텍스트가 분명히 한 이상, 나는 봇이 고아 기사를 만든 사람에게 알리는 아이디어가 좋다.에스프레소 중독자 (대화) 03:17, 2013년 11월 27일 (UTC)[응답]
명목별, 태그별 지원은 고아일 때 {{unreferenced}}, {{Disput}} 등의 태그를 보는 데 익숙해 독자들에게 알릴 가치가 없고 작은 이슈인 만큼 기사에 문제가 있다고 생각하게 한다.라마수드2000 06:23, 2013년 11월 27일 (UTC)[응답]
WP와 반대되는 지원:FRURED와 WP:RF, 이 기괴한 배너들은 우리 독자들에게 관심없는 이슈에 과도한 비중을 두고 있다.대부분의 다른 배너 태그도 하향 조정해야 한다.모든 페이지에는 고지 사항에 대한 링크가 표시된다는 점에 유의하십시오.이것은 대부분의 청소 태그보다 더 중요한 법적 정보다.그러나 그것은 눈에 띄지 않는 방법으로 모든 페이지의 맨 아래에 배치된다.우리는 배너에 몇 개의 정리 태그를 배치함으로써, 그 중요성을 과장하고 고지 사항의 중요성을 감소시킨다.사실 대부분의 정리 태그는 너무 모호하고 실행 가능한 디테일이 부족하여 생산적인 결과 없이 몇 년 동안 페이지 상에 머물러 있기 때문에 상당히 쓸모가 없다.그들은 늑대를 울린 소년처럼 배너 실명을 초래한다.즉각적인 주의가 필요하고 AFD와 같은 토론으로 연결되는 배너를 저장하십시오.소장 (토크) 07:43, 2013년 11월 27일 (UTC)[응답]
반대 누가 고아가 된 기사와 어떤 다른 기사를 연결해야 하는지에 대한 아이디어를 가질 가능성이 가장 높은가?읽고 있는 사람들!왜 우리가 그들을 초대하는 것을 그만두어야 하는가?나는 어떻게 우리가 고아에 대한 독자들을 핵심을 놓치도록 "워닝"할 필요가 없는지에 대한 위의 코멘트를 발견하는데, 그것은 유지 태그가 문제들에 대한 "워닝"을 위해 독자들을 백과사전의 편집에 참여하게 하는 것이나 다름없기 때문이다.이와 유사하게, 특수(Special)를 통해 이 정보를 이용할 수 있다는 주장도 다음과 같다.WhatLinks여기서, 기기 등은 이러한 특징에 대해 모르는 독자나 새로운 편집자에게 별로 도움이 되지 않는다.Anomie november 13:53, 2013년 11월 27일 (UTC)[응답]

기사들을 제대로 위키리크하는 방법을 알거나 관심을 갖지 않는 사람들은 누구인가?독자들.만약 그들이 가젯과 특별한 페이지에 대해 알지 못한다면, 그들 역시 제대로 연결될 만큼 충분히 알지 못할 가능성이 있다.방대한 양의 고정되지 않은 고아들은 이미 독자들이 그것을 고치고 싶어하지 않는다는 것을 분명히 하고 있다(특히 고칠 수 있는 모든 고아들은 독자가 아니라 기사의 원저자에 의해 고친다).그리고 설사 그렇다 하더라도, 독자들은 언제 어떻게 기사를 연결해야 하는지 알 수 있는 경험이 없을 것이고, 그로 인해 관련성이 의심스러운 다른 기사에 연계가 추가될 것이다.결국 그들의 유일한 동기부여는, 만약 그렇게 한다면, 그 추악한 현수막을 걷어내고 그 기사를 평화롭게 읽을 수 있을지도 모른다는 것이다.유지 관리 태그도 초대장이지만, 가능한 한 빨리 고쳐야 하는 긴급한 문제에 대한 초대장이다.고아가 되는 것은 치명적인 오류가 아니며, 다시 한 번 말하지만 즉각적인 주의가 필요한 것도 아니며, 그것들과 연결되는 위키피디아에 더 많은 기사가 추가되면서 그들 대부분은 자연스럽게 고쳐진다.우리는 정확하게 이러한 이유로 선납 유지 관리 태그에 포함되지 않은 다른 사소한 문제도 있다. -- OBSIDIAL SOUL 15:01, 2013년 11월 27일 (UTC)[응답]

초대장이 아니니까.독자에게 무시당하거나 글에 뭔가 잘못되었다는 막연한 암시다.나는 새로운 편집자들이 경고 템플릿이 있는 페이지를 읽는 것을 보는 것을 추천한다.아니면 그 경험에 대해 물어보는 것도.나의 상호작용에서, 태그는 위키피디아에 충분히 풍부해서 그들은 단지 '오 이것들은 문제야'라고 정신적으로 분류할 뿐이다.우리(언어 위키피디아인으로서)가 집단적으로 미쳤기 때문에 우리는 그들을 '귀속'이라고만 생각한다.내 말은 가능한 한 가장 사랑스런 방법으로 말이야.독자들이 태그 때문에 더 높은 비율로 편집자로 전환되거나 그것들 때문에 더 비판적으로 기사를 읽는다는 것을 보여주는 연구는 없다.나는 누군가가 고칠 수 있는 페이지에 문제가 있거나, 제거될 필요는 없지만 'whole'으로 표시하고 싶지 않을 수 있는 페이지에 태그를 지원한다.그렇지 않으면, 무슨 소용이야?프로톤크 (대화) 19:35, 2013년 11월 27일 (UTC)[응답]

지지하다.나는 스텁 태그의 배치와 같은 기사의 끝에 작은 코멘트를 하는 아이디어를 선호한다.이것은 "불이야"라고 외치지 않고 그 기사를 분류할 것이다.filbecaturous talk 18:22, 2013년 11월 27일 (UTC)[응답]
대화 페이지로 이동하거나 아예 삭제하는 것을 지지하는 것은 큰 문제가 아니다. 샌드스타인 20:32, 2013년 11월 28일 (UTC)[응답]
Respected당 지원.독자를 위한 불필요한 방해.나는 프로포즈봇을 통해 몇 개의 오래된 고아 기사를 찾아갔다; 이들 고아들 중 많은 수가 노르웨이 의회의 전 부위원이었고, 그것들을 자연스럽게 삽입할 기사가 종종 없어서 나는 단순히 태그를 제거했다.그러나 토크 페이지에서는 태그가 전혀 신경쓰이지 않을 것이다.안녕, 이슬릴자 (토크) 21:15, 2013년 11월 28일 (UTC)[응답]
고아 태그를 옮기거나 숨겨서 얼굴에서 덜 보이게 하는 것을 지지하십시오. 에릭 코벳 21:31, 2013년 11월 28일 (UTC)[응답]
대화 페이지 이동 반대, 어떻게든 숨기는 지지.오랜 세월 동안 유지보수 백로그를 수행하고 일부 진행 상황을 추적한 결과, 편집자가 드라이브를 통해 유지보수를 거의 수행하지 않았다.거의 모든 일이 고양이를 치우는 프로젝트나 개인 드라이브에 의해 일어난다.우리가 무엇을 하든, 그 카테고리는 페이지에 남아 있어야만 svick 도구와 같은 도구들이 그것들을 집어 들고 catscan을 사용하여 분류할 수 있다.단순히 {{orphan} 템플릿의 내용을 변경하는 것에 비해, 태그를 토크 페이지로 이동하는 것은 분류 작업에 불필요한 복잡성을 가중시킬 뿐 아니라, 해야 할 큰 과제가 될 것이다.<3링크>라는 낡은 지침이 아니라 현행 0링크라는 가이드라인에 근거한 봇 운영은 12만1천명 중 얼마나 많은 사람이 현재 규칙에 의해 실제로 고아인지 알아내는 데 유용할 것이다.The-Pope (대화) 07:36, 2013년 11월 30일 (UTC)[응답]

말이 되네.여기 투표하는 대부분의 사람들은 어쨌든 어디에 두든 별로 신경 쓰지 않는 것 같다.선행 배너와 함께 포함되지 않는 한.-- OBSIDIAL 15:06, 2013년 12월 4일 (UTC)[응답]

Respected당 지원.로바 포크토크 09:50, 2013년 11월 30일 (UTC)[응답]
두 가지 관점에서 강력한 지원.첫째로, 만약 우리가 우리의 독자 앞에 커다란 현란한 꼬리표를 던질 것이라면, 우리는 그들이 다른 방법으로는 (작가를 위한 coi, 주목할 수 없는 주제 등) 잡지 못했을지도 모르는 기사에 심각한 문제가 있음을 그들에게 알려주고 싶다.둘째로, 당신이 새로운 사용자라고 생각해라.당신은 방금 반짝거리는 새 기사를 썼는데, 다만 비정한 로봇이 다가와 그 앞에 추악한 꼬리표를 찰싹찰싹 때릴 뿐이었다.이러한 태그 중 일부는 순이익이지만, 다른 태그, 특히 고아 태그 등은 새로운 사용자가 최소한의 이익을 얻도록 하는 데 그친다.태저다독 (대화) 17:36, 2013년 12월 2일 (UTC)[응답]
서포트 그것은 바보 같은 태그다. 왜냐하면 그것들에 링크를 가지고 있는 기사를 필요로 하는 정책이 없기 때문이다.이상하게도 태그는 태그가 붙은 기사를 고치는 것이 아니라 링크를 추가하기 위해 다른 기사를 작업하는 것이다.그런 사소한 것에 관심이 있는 사람들에게는 토크 페이지가 좋은 장소다.참고: 단순히 들어오는 링크가 없는 모호한 식물 기사가 있지만, 그 식물/주체는 기사에 충분히 주목할 수 있다.이제 '문제'를 고치지 않고 꼬리표만 떼지 않아도 될 것이다.First Light (talk) 05:23, 2013년 12월 3일 (UTC)[응답]
지원 나는 고아 태그가 가치와 목적을 가지고 있다고 믿지만, 그 때 주요 기사 페이지를 뒤죽박죽으로 만들 필요는 없다.나는 메인 기사의 하단에 있는 스텁 같은 메시지를 선호하지만, 토크 페이지 템플릿도 괜찮다.Gizza 00:41, 2013년 12월 4일 (UTC) Gizza 00:38, 2013년 12월 4일 (UTC)[응답]
지지하다.바바카시 (대화) 10:59, 2013년 12월 4일 (UTC)[응답]
오 신이시여, 네.결국 이런 일이 일어나기를 바랐던 것이다. -DJSAsso (토크) 14:23, 2013년 12월 4일 (UTC)[응답하라]
{{유형화되지 않은}}}}이(가) 배치된 하단 영역으로 태그를 이동할 수 있도록 지지하고, 메타 템플레이트 강화가 필요할 수 있지만(봇은 그냥 이동할 수 있어야 한다) 자동 충돌도 지원한다.그것을 대화 페이지로 옮기는 것에 반대한다.범주:고아가 된 기사는 대화 페이지가 아니라 기사로 채워져야 한다.토크 페이지는 요청된 움직임과 같이 실제로 논의할 것이 있는 문제에 적합하다.어떤 기사가 고아와 연결되어야 하는지에 대한 논의는 아마도 그럴 것 같지 않고, 그저 누군가에게 달려 있을 뿐이다.또한, 새로운 위키백과 메시지 박스 템플릿 범주를 의미하는 {{asbox}}(문서 스텁박스) 메타 템플레이트와 유사하게, 이러한 목적을 위한 보다 미묘한 새 메타 템플레이트를 만드는 것을 지지한다. – Wbm1058 (대화) 18:55, 2013년 12월 4일 (UTC) ~~사용자~~도 지원할 수 ~~있다고~~ 내 입장을 수정한다.비록 그것이 내가 선호하는 해결책은 아니지만, 기존 배너보다 선호되는 것처럼 메시지 박스를 완전히 존재하지 않게 효과적으로 붕괴시키겠다는 PamD의 제안. ~~고아들과 자주 연결해서 그 꼬리표를 보면 떼어버린다...~~ ~~보통 한 두개의 좋은 기사들을 연결하는 것은 쉽다.~~ ~~어쩌면 밑에 작은 음표라도?~~ ~~이 물건은 고아다.~~ ~~난 이것들을 위해 순찰하지 않는다.~~ ~~비록 그것이 완전히 제거되었다면 우리는 태그들을 옮기는 봇도 필요하지 않을 것이다.~~ ~~Wbm1058~~ (~~대화) 23:48, 2013년 12월 4일 (UTC)~~ 단순히 "숨겨진 범주"를 추가하고 아무것도 표시하지 않는 것을 반대한다.적어도 과로한 편집자의 편의를 위해 #찾기 링크 도구에 대한 링크는 유지되어야 한다.Wbm1058 (대화) 16:04, 2013년 12월 9일 (UTC)[응답]
지지 나의 초기 반응은 태그가 못생긴 것은 버그가 아니라 특징이라고 생각하면서 반대였지만, 조금 생각해보니 편집자보다는 독자를 겨냥한 태그에 대해 그렇게 느낀다.나는 내 지원 위치를 쓰기 시작했지만, 그 후 몇 가지 의견을 읽고 사용자:PamD가 내 생각을 미러링했으니까 "PamD가 말한 것"으로 응원할게.--S Philbrick (Talk) 22:47, 2013년 12월 4일 (UTC)[응답]
그것을 토크 페이지로 옮기는 것을 지지한다(유지관리는 토크 페이지의 기능이다), 두 번째 선호도는 망각이다(삭제).유지관리 태그(편집자 통신의 편집자 전용)에 대한 나의 입장은 잘 알려져 있다(예: 템플릿 토크:고아와 위키백과의 대화:지속적인 제안#관리 태그를 이동하여 페이지 및 위키백과의 전체 논쟁:이 문제에 대해 (지금까지) 의견 일치를 본 적이 없기 때문에 유지 관리 태그를 대화 페이지로 이동시키는 것은 가짜다.내가 강조할 필요가 있는 대화 페이지에 유지 관리 태그를 배치하는 한 가지 요점은 관리 태그를 봇으로 자동화할 수 있다는 것이다.만약 봇이 기사 공간 편집기에 태그를 배치한다면, 그 태그를 제거해서 봇 파일럿에게 항의할 수도 있다.그러나 대화 페이지의 유사한 태그 플레이스는 다른 편집자들을 그렇게 많이 짜증나게 할 것 같지 않다.즉, 그러한 페이지의 정확한 범주는 그러한 것들을 고치는 것을 좋아하는 위키그놈들을 위해 토크 페이지의 태그를 통해 봇에 의해 자동으로 유지될 수 있다는 것을 의미한다.수정 작업을 수행하는 사람들은 가능한 한 낮게 표시하려고 하는 기사 공간에서 템플릿이 불필요하다고 생각하는 사람 없이 링크 수에 적합한 수준이 무엇인지 스스로 결정할 수 있다. -- PBS (대화) 14:45, 2013년 12월 5일 (UTC)[응답]
지원 - 태그를 기사에서 제거하거나(대화 페이지에 표시하면 작동 가능) 보이지 않아야 한다.이러한 기사의 평균적인 독자는 정확하게 하는 것보다 일을 망칠 가능성이 더 높고, 문제는 비교적 경미하다(예를 들어, 기사의 신뢰도가 여기서 받아들일 수 있는 수준 이하임을 시사하는 {{hoax}} 태그 또는 {{coi}} 태그와 달리).עודדוו od יו od 16 od 16 od 16 16:37, 2013년 12월 5일 (UTC)[응답]
조건부 지원.그러나 페이지 하단으로 이동하거나 숨길 뿐이었다.대화 페이지 이동에 반대하십시오. 이 페이지를 편집 대상으로 하는 사용자만 더 어려워질 수 있음.GenQuest 18:36, 2013년 12월 5일 (UTC)[응답]
Support Move to talk 페이지는 사소한 문제지만 악의는 없다.Acalycine 08:13, 2013년 12월 6일 (UTC)[응답]
지지 - 이제 이 일을 끝낼 때가 되었다.기사 상단에 있는 태그는 태그의 실제 중요성에 대한 불균형한 주의를 산만하게 한다.토크 페이지에 올리는 것이 훨씬 낫다.Jusdafax 01:01, 2013년 12월 7일 (UTC)[응답]
위에 제시된 이유에 대한 지원.스노우파이어 (토크) 19:03, 2013년 12월 7일 (UTC)[응답]
아노미 당 반대.유지 관리 템플릿이 보기 싫으면 기사를 개선하십시오!크리스 트라우트맨 (토크) 01:36, 2013년 12월 8일 (UTC)[응답]
물론 그것은 우스꽝스러운 입장이다. 왜냐하면 어떤 "개선"은 태그가 붙는 기사가 아니라 다른 기사에 대한 것이어야 하기 때문이다. 에릭 코벳 03:02, 2013년 12월 8일 (UTC)[응답]
토크 페이지로 이동(또는 완전히 제거)하는 지원.기사의 사소한 문제를 독자들에게 덜 알릴수록 좋다. iMatthew / talk 04:03, 2013년 12월 8일 (UTC)[응답]
PamD 및 SPhilbrick별 지원("토크 페이지에 올리거나 템플리트를 단순히 "숨겨진 카테고리"를 추가하게 함으로써)" –Quiddity (토크) 23:24, 2013년 12월 8일 (UTC)[응답]
지지하다.시간이 다 됐어.이것은 과거에 논의된 적이 있어, 끊임없는 골칫거리야.위와 같이 글의 추론과 소외는 작은 이익의 가치가 없다.심각한 문제에 대한 큰 골칫거리들을 저장해라.헤로스트라투스 (대화) 2013년 12월 9일 08:55 (UTC)[응답]

@Herostratus:템플릿 사용:암박스#소형, 아마도 더 자주.–Quiddity (대화) 15:50, 2013년 12월 9일 (UTC)[응답]

네, 아마도.나는 그것에 대해 잊어버렸었다.그 모든 것들을 추적하는 것은 어렵다.타협이 될 수 있을 것 같아.선호도 순으로 내가 원하는 결과는 1)토크페이지로 옮기고 2)기사 하단으로 옮기고 3)더 작은 박스로 다시 쓰는 것이 아닐까 싶다.헤로스트라투스 (대화) 2013년 12월 9일 (UTC) 17:21 [응답]

템플릿 제거에는 동의하지만, 대화 페이지가 올바른 곳인지 잘 모르겠어.내 선호도는 템플릿을 시스템에 의해 자동으로 생성된 범주로 대체하는 것이 이상적일 것이다.그것은 고아를 찾는 사람들에게도 효과가 있을 것이고, 또한 우리의 독자들에게도 효과가 있을 것이다.아무도 이상한 관리 범주를 신경 쓰지 않는다.2013년 12월 10일(UTC) 22:54 [응답]
상기의 다수 의견별 지원. --LT910001 (대화) 03:53, 2013년 12월 11일 (UTC)[응답]
서포트를 하고 눈을 치울 것을 요청하라.편집자는 관심을 가지지만 독자는 관심을 갖지 않는 문제에 과도한 비중을 둔다.내 생각에, 이것을 진정으로 이해하기를 원하는 사람은 다음 두 페이지를 보아야 한다.

사용자:Greg L의 집 앞 Greg L/Sever 커버

사용자:Guy Macon/Greg L의 집 앞 하수구 덮개 지름에 대하여

이게 도움이 되었으면 좋겠는데... --Guy Macon (토크) 01:18, 2013년 12월 13일 (UTC)[응답]

반대 - 고아 태그가 페이지 자체의 문제를 나타내는 것은 아니며, 단지 누군가가 페이지와 관련이 있는 다른 기사를 찾아 링크해야 한다는 것이다.위키피디아 페이지는 다른 어떤 기사와도 연결되지 않고 거의 쓸모가 없다; 그것은 사실상 접근할 수 없다.지금까지 기사가 만들어지지 않았고, 고아인데다, 아무도 그것과 연계할 다른 고도로 관련 있는 기사를 찾을 수 없다면, 새 페이지가 눈에 띄지 않을 수 있다는 매우 강력한(그리고 매우 유용한) 신호를 준다.이것은 위키피디아에 실리지 않는 새로운 기사들을 정리하는데 유용하다.2005년 같은 해였다면 나는 이것에 동의했을지도 모르지만, 2013년, 고아 태그는 매우 유용하고, 매우 말해준다.잇힌키칸 (대화) 05:45, 2013년 12월 25일 (UTC)[응답]

가능한 구현

댓글을 달다.만약 이것이 통과된다면, 다른 장소들 중에서도, 자동 고아 태그를 부착한 몇 개의 봇들이 있기 때문에, 이 변화를 우리에게 알리기 위해 봇 주인들의 게시판에 쪽지를 보내주십시오.— HELLKOWZ zTALK 12:48, 2013년 11월 16일 (UTC)[응답]

그리고 페이지 순찰이나 AFC처럼 이것 또한 할 많은 대본들이 있다.그래서 우리는 이것들이 템플릿을 추가하지 않도록 해야 한다.(일시적 교정조치로서 템플릿은 페이지에서 보이지 않을 수 있음)Graeme Bartlett (대화)20:31, 2013년 11월 16일 (UTC)[응답]

나는 위키피디아에서 유지보수의 더 깊은 측면에 대해 좀처럼 탐구하지 않는다.그래서 만약 여러분 중 많은 수의 편집자들을 어떻게 끌어들이는지 아신다면! 이것에 대해 투표해서 우리가 공감대를 얻을 수 있도록 그렇게 하십시오.통과될 경우 이를 이행할 수 있는 방법과 동일함.-- OBSIDIAn 16SOUL 21:38, 2013년 11월 16일 (UTC)[응답]

위키피디아를 추가했다.설명 태그 요청.Theopolisme (talk) 18:06, 2013년 11월 17일 (UTC)[응답하라]

고마워.. OBSIDIAL 01:33, 2013년 11월 19일 (UTC)[응답]

논평 - 편집자들이 서로 기사를 연결하도록 장려하는 것이 중요하다.고아 통지가 기사의 맨 위에 있지 않도록 하려면 (1) "범주 개선" 태그 근처의 기사 하단에 있는 태그, (2) 그 자체의 범주, (3) 토크 페이지에 있는 태그, 또는 (4) 전혀 표시되지 않는 태그가 될 수도 있고, 또는 (5) 숨겨진 방법으로 추적하거나, (5) 완전히 무시될 수도 있다.나는 옵션 1을 선호한다. 왜냐하면 새로운 페이지일 때 카테고리 수정과 페이지 연결은 함께 하는 경우가 많기 때문이다. 그러나 다른 방법에는 장점이 있을 수 있다.눈에 보이는 태그의 한 가지 좋은 점은 "여기 링크된 내용" 검색을 사용하면 모든 고아 페이지를 쉽게 찾을 수 있다는 것이다.또 다른 가능성은 두 개의 태그, 즉 아무도 연결하려고 시도하지 않았던 새로운 기사를 위한 태그, 그리고 (당시) 정말 독특한 주제였던 기사들을 위한 태그가 두 번째 덜 눈에 띄는 태그가 있을 것이다.—앤 들롱 (대화) 21:45, 2013년 11월 16일 (UTC)[응답]

(갈등 편집) 만약 이것이 합의점을 얻으려면 다음과 같은 몇 가지 방법을 사용할 수 있다.

기존 템플리트가 페이지 하단의 위치 및 덜 거슬리는 스타일로 다르게 표시되도록 수정.
대신 대화 페이지 사용을 위한 대체 템플리트 작성.
스크립트 유지관리자에게 통보하고 앞으로 대체 템플리트를 사용하도록 요청
- 또는 템플릿이 기사 페이지와 다르게 대화 페이지에 나타나도록 템플릿을 추가로 수정하십시오.
일단 대화 페이지에 적합한 버전의 템플릿이 만들어지면, 봇 또는 봇 태스크가 페이지를 말하기 위해 기존 사용을 이동하도록 요청하거나, 봇 권한을 요청하여 AWB를 이 목적으로 사용하도록 한다.

그들은 함께 이것을 바꾸기 위한 결정(하나의 결정이 내려졌다고 가정)을 실행해야 한다.DES 21:52, 2013년 11월 16일 (UTC) @Anne Delong, 물론 중요하지만, 눈에 보이는 태그가 얼마나 의미 있는 연계를 조장하는지는 IMO가 의심스럽다.선택사항과 관련하여, 태그는 숨겨진 태그처럼 카테고리에 기사를 넣을 수 있으며, 숨겨진 태그도 여기에 있는 링크를 통해 추적할 수 있다는 점에 유의하십시오.DES 21:57, 2013년 11월 16일 (UTC)[응답]

이것들 고마워.나는 그것이 실제로 어디에 배치될 수 있는지에 대한 선호도가 없다.단지 내가 믿는 바로는{{Orphan}}태그는 리드 앞에 나타나는 "알 수 있는" 태그에 속하지 않는다.이것들은 아마도 충분한 편집자들이 의견 일치를 위해 의견을 개진했을 때 더 자세히 논의될 수 있을 것이다.위키프로젝트 고아원 회원들의 의견(위키프로젝트가 여전히 활동 중인 경우)이 가장 좋으며, 결국 이들에 대한 작업을 하는 것은 그들이다.--- OBSIDIAn†SOUL 01:33, 2013년 11월 19일 (UTC)[응답]

설명:템플리트를 수정하여 독자에게 아무것도 표시하지 않고 숨겨진 카테고리를 계속 추가할 것을 제안한다.2013년 12월 등의 고아 기사, {{coord missing}}과 같은 방식으로.그러면 고치기 위해 고아를 찾는 편집자는 고친 후에 고친 후에 고친 템플릿을 제거할 수 있다.다른 사람은 누구나 무시할 수 있다. (현재 시스템에는 121k의 고아 기사가 있지만, 그렇게까지 하는 것이 얼마나 중요한지 궁금하다.)PamD 23:02, 2013년 12월 4일 (UTC)[응답]

그것들을 기사 공간에 숨기는 것의 문제는 그들이 링크하는 숨겨진 범주가 위키그놈의 보존이 되는 경향이 있다는 것이다.이 유지 관리 태그를 토크 페이지로 옮겨서 토크 페이지 맨 위에 유지 관리로 표시하면 다른 편집자들이 관여할 가능성이 더 높다고 생각한다(나는 그럴 것이라고 알고 있다).나는 삭제가 이 특정 템플릿에 허용될 수 있다 하더라도 더 중요할 수 있지만 기사 공간에서 보여서는 안 되는 다른 유지보수 템플릿이 있기 때문에 좋은 해결책은 아니라고 생각한다.이것을 토크 페이지로 옮기는 것은 테스트가 될 수 있고 다른 사람들이 토크 페이지로 이동하기 전에 버그를 제거하기 위한 포러너일 수 있다.특히 토크 페이지의 템플릿 배치 및 삭제가 봇(동일하게 분류되지 않음)에게 넘겨질 수 있는 경우(동일하게 분류되지 않음) - PBS(토크) 15:16, 2013년 12월 5일(UTC)[응답]

현실적으로 위키그놈들만이 이 기사들을 다룰 것이다. 대부분 가이 매콘이 그의 위에서 언급한 것처럼 순탄하다.그들은 종종 새로운 페이지 순찰에 의해 위반으로 태그가 붙었기 때문에 이러한 순항 작업을 발견한다.gnome이 고아 중심이라면, 그들은 그것을 Category:에서 발견하기 때문에 온라인 통지가 필요하지 않다.고아한 물건.토크 페이지가 분류된 경우, 다음 단계에서는 기사 탭을 클릭할 것이기 때문에 단지 gnome 속도를 늦출 뿐이고, 여기서 확인할 링크를 클릭하십시오.그리고 나서 그들은 그것에 무엇을 연결해야 할 지에 대한 단서를 찾기 위해 그 기사를 읽을 필요가 있다.종종 토크 페이지에 있는 유일한 것은 위키프로젝트 태그가 될 것이기 때문에, 토크 페이지는 대개 무용지물이다.나는 보통 다른 문제 때문에 순찰할 때 이것들을 발견한다.나는 단지 내가 보는 것을 고치고, 대개는 굳이 토크 페이지를 보거나, 어떤 링크를 여기 있는지 확인하려고 하지 않는다.그러니 적어도 작은 메시지가 없다면 그냥 놓칠지도 몰라.Wbm1058 (대화) 18:19, 2013년 12월 5일 (UTC)[응답]

@Wbm1058 다음 섹션의 편집과 관련하여 "읽은 횟수를 추측할 수 있을 뿐이다... 나는 메시지 박스 텍스트의 개선이 스크린의 어디에 메시지를 배치하는 것보다 도움을 줄 수 있는 좋은 도구가 있다는 것을 강조하는 것이 더 중요하다고 생각한다."나는 당신이 제안하는 것이 이 구체적인 템플릿에 대해 나타난 합의와 명백히 반대되는 것이라고 생각한다.그 합의는 그것을 없애는 것이다.합의가 안 되는 영역은 완전히 삭제할지, 토크 페이지를 옮겨야 할지, 아니면 기사 페이지의 보이지 않는 템플릿으로 만들어야 할지(아마 그런 선호 순서에 따라)뿐이다.-- PBS (대화) 11시 19분, 2013년 12월 11일 (UTC)[응답]

회피하기 위한 자기 참조

이 논의에 포함될 만큼 {{Ophan}}과(와) 유사한 유지 관리 템플릿이 여러 개 더 있다고 생각한다.2012년 9월 29일 07:01에 생성되었으며, 생성에 대한 지원이 거의 없는 상태로 생성된 {{Underlinked}}을(를) 예로 들어보자.

한 가지 중요한 문제는 누구나 기사 공간에서 사용할 수 있도록 새로운 유지보수/클린 템플릿을 만들 수 있다는 점이다.일단 만들어지면, 그들은 삭제하기가 어렵다. 왜냐하면 그것을 만든 사람은 보통 그것을 삭제하는 데 동의할 수 없다고 주장하며 그들의 아기를 끈질기게 변호할 것이기 때문이다.위키피디아에는 다음과 같은 템플릿이 꽤 많이 있다.템플릿 메시지/정리

나는 위키피디아의 표현을 강화하는 것이 먼저라고 생각한다.회피할 스타일/자기 참조 매뉴얼.약 1년 전 여기서 제안했던 제안서를 보십시오. 당시 관심 부족으로 인해 중단되었던 제안서를 보십시오. -- PBS (대화) 23:25, 2013년 12월 8일 (UTC)[응답]

{{Underlinked}}}}}}}}}}그냥 최소한의 지원만으로 '갑작스러운 일'이라는 것은 그다지 사실이 아니다.{{내부 링크}}}은 이 태그의 이전 버전이었고, {{Wikify}}은 이러한 목적으로 자주 사용되었지만 위키피디라는 용어가 너무 모호하기 때문에 더 이상 사용되지 않았다.Wbm1058 (대화) 01:01, 2013년 12월 9일 (UTC)[응답]

{{Underlinked}}{dead end}}}는 기사가 0, 1, 2 또는 3개의 링크가 있음을 의미하는 {{Undlinked}}} 이전도 있었다.GoingBatty (토크) 01:04, 2013년 12월 9일 (UTC)[응답]

다른 이전 템플릿이 있었든 없었든 간에, {{Underlinked}}라고 하는 새로운 템플릿을 만드는 것에 대한 만족도에 대해 다수의 편집자들이 참여한 논의의 증거가 없다."위키파이", "언글링킹", "데드엔드"와 같은 지시사항 외에도, 기사 공간이 아닌 대화 페이지에 있어야 할 모든 것들이 있다.만약 누군가가 정말로 "Wikify"가 의미하는 것을 이해하지 못한다면, 그것은 자넷과 존 용어로 그들에게 설명될 수 있다.만약 편집자가 기사 맨 위에 밑줄 친 이탤릭체로 글을 쓴다면, 그들은 그러한 논평은 기사 공간이 아닌 토크 페이지에 속한다고 말할 것이다.그것을 상자에 넣는다고 해서 메시지의 본질이나 어디에 있어야 하는지는 바뀌지 않는다."이 리스트는 불완전하다"를 시작하는 기사에 텍스트를 넣는 것은 독자가 그것을 확장함으로써 편집자가 되는지에 대한 독자들에게 유용한 경고이기 때문에 삭제되지 않을 것이다. -- PBS (토크) 08:34, 2013년 12월 9일 (UTC)[응답]

위키백과:위키프로젝트 위키피디아는 확립된 상당히 활동적인 프로젝트로, 프로젝트의 핵심 기능은 아니더라도 내부 링크를 추가하는 것이 핵심 기능이라는 것을 프로젝트 페이지와 프로젝트의 로고를 통해 분명히 밝혀야 한다.그래서, 광범위한 논의가 있었든 없었든 간에, 그 템플릿에 대한 사실상의 지원이나, 혹은 그것의 이름을 딴 변종들에 대한 지원이 널리 퍼져있다.

들여쓰여진 이탤릭체로 기사의 맨 위에 "나는 이 기사가 언더링크 된 것 같다"라고 쓴 편집자가 평면적으로 되돌리거나 토크 페이지로 이동하는 것보다 그들의 편집이 {{Underlinked} 템플릿으로 변환된 것을 발견할 가능성이 더 높을 것이다.

그러나 당신의 핵심 제안에 대한 논의의 증거가 있다.위키백과 참조:지속적인 제안#유지관리 태그를 대화 페이지로 이동Wbm1058 (대화) 12:48, 2013년 12월 9일 (UTC)[응답]

내부 링크를 추가하는 것이 핵심 기능일 수도 있고 아닐 수도 있지만(특히 날짜 초과 연계에 대한 소란을 참조), {{Underlinked}}와 같은 템플릿을 기사 공간에 배치해야 하는지는 중요하지 않다.2007년에 나는 편집자들이 어떻게 독자와 다르게 페이지를 볼 수 있고 자주 하는지에 대해 썼다.그들은 대부분의 사람들이 주제에 대한 발표가 어떻게 개선될 수 있는지에 대한 것이 아니라 주제에 대해 읽기 위해 한 페이지에 온다는 것을 잊을 수 있다.기사는 주제에 관한 것이어야 하고, 토크 페이지는 편집자들이 어떻게 기사를 개선할 수 있는가에 사용되어야 한다. (왜 굳이 토크 페이지를 귀찮게 하지 않고 대신에 페이지 끝에 많은 블로그 사이트에서 하는 것처럼 토크 페이지 채팅을 추가해야 하는가?) -- PBS (토크) 15:05, 2013년 12월 9일 (UTC)[응답]

당신이 6년 전에 이 템플릿들을 제거/이동하기에 충분한 사례를 제시했고 (어떤 편집자가 당신에게 회신했든 상관없는) 표준 데이터 무자료, '트루티' 반응을 얻었다는 것은 나를 완전히 화나게 한다.우리는 프로젝트 시작 이후 몇 페이지에 걸쳐 템플릿을 다듬으며 우리 자신에게 꽤 위안이 되는 우화라고 말하고 있다.프로톤크 (대화) 23:41, 2013년 12월 9일 (UTC)[응답]

다년생 제안서의 섹션은 오해의 소지가 있는 방식으로 쓰여 있다.이는 실제로 그러한 합의가 없었던 경우 제안을 거절하는 데 동의가 있음을 시사한다(자세한 내용은 다년생 제안 대화 페이지 참조).나는 이 RfC가 기사 공간에서 그들의 사용을 억제하기 위해 균형을 더 잘 잡는다고 생각한다. -- PBS (토크) 14:49, 2013년 12월 9일 (UTC)[응답]

아 그렇구나: 위키백과 대화:지속적인 제안#유지관리 태그를 대화 페이지로 이동영화 비유를 하자면, 그래, 나는 현재 맨 위에 있는 대담한 템플릿이 배우들과 감독들의 DVD 해설을 켜는 것과 같을 수도 있다는 것에 동의해.하지만 왜 꼬리표를 바닥으로 옮기고 톤 다운하는 것이 해로울까?그것은 DVD 끝부분에서 크레딧을 굴리는 것과 더 비슷할 것이다.시청자들이 자유롭게 극장 밖으로 걸어나오거나 DVD를 꺼내거나 TV를 끄듯이, 독자들은 그 시점에 도달하면 그냥 책을 읽는 것을 그만두는 것이 자유롭다.나는 독자들이 특정 기사의 편집자가 될 가능성이 가장 높은 사람들이 기사 끝까지 시간을 들여 읽는 사람들이라고 추측한다.다른 곳을 클릭하기 전에 무심코 리드를 읽는 사람들은 편집 가능성이 가장 낮으며, 얼굴 내 태그에 짜증이 날 가능성이 가장 높다.그리고 나는 고아 태그가 독자로서 유용하다는 것을 안다.그것은 내게 그 기사가 백과사전에 제대로 통합되어 있지 않다고 말해주는데, 그것은 그 기사의 신뢰성과 명성에 의문을 갖게 한다.그래서 나는 태그가 없는 기사만큼 그 기사를 신뢰하지 않을 수도 있다.Wbm1058 (대화) 15:50, 2013년 12월 9일 (UTC)[응답]

참조 섹션이 큰 기사에 대해 외부 링크나 내비게이션 박스를 찾지 않는 한, 얼마나 많은 사람들이 기사의 맨 아래에 있는 것을 보기 위해 기사를 지나칠 것인가?Anomie ⚔ 19:18, 2013년 12월 9일 (UTC)[응답]

네가 올린 글이 나에게 명확하지 않아서 미안해.그들을 최하위에 두는 것을 지지하는가? - PBS (대화) 13:09, 2013년 12월 10일 (UTC)[응답하라]

영화 크레딧과의 비교가 반드시 적절한 것은 아니라는 점을 지적하고 있다.Anomie december 16:54, 2013년 12월 10일 (UTC)[응답]

@Anomie:우리는 얼마나 많은 독서를 끝까지 하는지, 그리고 만약 있다면, 고아 링크 활동을 얼마나 줄일 것인지에 대해서만 추측할 수 있다.나는 참고문헌이 많은 잘 발달된 기사들 중 고아들이라고 장담할 수 있다.더 많은 고아들은 위아래가 모두 와이드스크린 HD 모니터에 맞거나, 끝까지 가기 위해 최소한의 스크롤이 필요한 스터브다.나는 고아 링크 편집의 증가를 위한 방법을 찾는 것에 대한 당신의 우려를 공유한다.그 대사들을 따라, 나는 메시지 박스 텍스트의 개선이 스크린의 어디에 메시지를 배치하는 것보다 도움이 되는 좋은 도구가 있을 수 있다는 것을 강조하는 것이 더 중요하다고 생각한다(다음 섹션 참조).가장 잠재적으로 연결 가능한 기사의 봇으로 생성된 목록은 찾기 링크 도구의 알고리즘을 사용하여 위키백과의 작업관리 목록과 유사한 고아 연결에 큰 자극제가 될 수 있다고 생각한다.링크가 있는 디스암호화 페이지는 그 프로젝트에 도움이 되고, 도움을 필요로 하는 우리의 가장 중요한 고아들을 더 빨리 해고시킬 수 있을 것이다.덜 알려진 기사들을 연결시키는 것에 대해서는, 나는 그냥 오래 된 기사를 무작위로 골랐을 뿐인데, 공교롭게도 그것이 내가 전형적으로 느끼는 것이다.Ken Nimori는 Category에 속해있다.오리건 주립 대학교 동문.그 범주를 오리건 주립대학 동문 목록과 짝을 이루는 룩업 테이블을 만들면 좋을 것이다.이 범주의 모든 구성원이 이 목록에 포함되어야 한다.그런 짝을 수백 개 만들 수 있을 것 같다.그런 다음, 봇에게 그 범주들을 목록과 비교하게 하고, 켄 니모리 같은 고아들을 오리건 주립대학 동문들의 목록에도 넣게 하고, 그곳에서 인간 편집자는 그를 이동시킬 정확한 섹션을 찾을 수 있었다.나는 바닥으로의 이동의 단계적 실행이 가장 효과적이고 최소한의 혼란을 야기할 것이라고 생각한다.무한 단계 진입 기간 동안 태그가 상단 또는 하단에 있도록 하십시오.{{여러 이슈}}에 포장을 했을 때 당연히 여전히 상위에 있을 것이다.시간이 지남에 따라 봇과 AWB는 하단에 새로운 것을 추가하기 시작할 수 있다.만약 우리가 이러한 움직임이 고아 연계를 현저하게 감소시킨다고 발견한다면, 그 움직임은 너무 많은 피해가 발생하기 전에 역전될 수 있다.내가 생각하기에 좋은, 덜 만화 같은 밑바닥의 드웰링 템플릿의 샌드박스 버전을 만들거야. 얼굴에는 덜하지만 눈에 띄어야 하는.안녕하십니까, Wbm1058 (대화) 00:30, 2013년 12월 11일 (UTC)[응답]

내 생각에 우리가 여기서 역행하고 있는 것 같아.이 마지막 게시물에서 Wbm1058이 제기한 구체적인 사항은 이전 섹션에 있어야 하며, 이에 대해 이전 섹션에 코멘트를 할 것이다. -- PBS (토크) 11:09, 2013년 12월 11일 (UTC)[응답]

찾기 링크 도구

얼마나 많은 분들이 찾기 링크를 알고 사용하셨습니까?나는 이 템플릿을 여러 번 읽었음을 고백할 것이다. 그리고 제안이 가능할지도 모른다고 가정하면, 고아와 연결하기 위한 기사를 찾는 방법에 대한 어떤 "도움이 되는 조언"의 연결고리에 불과하다고 가정할 것이다. "나는 이미 그 방법을 알고 있었기 때문에 그 링크를 클릭할 필요가 없었다.그래서 나는 이것이 매우 유용한 도구와의 연결고리라는 것을 알고 매우 유쾌하게 놀랐다.모호한 "제안이 있을 수 있음"을 "찾기 링크 도구"로 변경하여 툴에 더 많은 트래픽을 유발하지 않는지 확인해 보십시오.내 생각에 몇몇은 그것을 사용하는 것이 재미있다고 생각할 수도 있고, 어쩌면 약간 중독적일 수도 있다.이 템플릿이 {{여러 가지 이슈} 안에 샌드위치 되어 있을 때 툴에 대한 링크가 없어지는 것은 부끄러운 일이라고 생각한다.우리는 고아들을 효율적으로 태그하는 봇을 운영하고 있다. 예를 들어 최근 괴물 같은 연합이 태그가 붙었다.나는 단지 그것을 7개의 기사에 연결하기 위해 도구를 사용했다.그것은 마치 대박을 터뜨린 것 같았다.공구가 비어 있는 경우가 많다.도구는 백과사전 어디에서도 기사 제목을 찾을 수 없을 때, "초고형"을 갖게 되고, 우리는 그런 것들을 많이 갖게 된다.봇이 모든 것에 대해 이 도구를 실행하고 인간 편집자들이 더 많은 관심을 가질 수 있도록 가장 잠재적으로 연결 가능한 기사 목록을 생성하는 것이 도움이 될 수 있기 때문에, 우리는 우리의 시간에 가장 큰 영향을 미친다.– Wbm1058 (대화) 03:49, 2013년 12월 9일 (UTC)[응답]

Template talk에서의 토론에서도 누군가가 이 문제를 가지고 있는 것을 알 수 있다.고아#Toolbox에서 제공하는 기능을 사용할 수 있는가?나는 해결책을 찾고 있는데 이것에 대한 의견을 듣고 싶다.고마워, Wbm1058 (대화) 23:14, 2013년 12월 10일 (UTC)[응답]

다음은 새로운 찾기 링크 도구 조언과 함께 고아 하단의 템플릿에 대한 빠른 패스워드 입니다.

외부 링크를 내부 링크로 변환하지 못했기 때문에 수동 작업이 필요하지만 찾기 링크 도구는 생물학적 데이터베이스 목록에 연결된다는 점에 유의하십시오.Category가 다음과 같은 경우 다시 한 번 말함:생물학적 데이터베이스는 생물학적 데이터베이스 목록과 짝을 이루었는데, 이는 봇이 목록 기사의 참조 섹션에 범주의 모든 고아 구성원을 추가할 수 있기 때문이다.Wbm1058 (대화) 02:48, 2013년 12월 11일 (UTC)[응답]

위의 논의는 종결되었다.수정하지 마십시오.이후 코멘트는 해당 토론 페이지에서 작성해야 한다.이 논의는 더 이상 수정해서는 안 된다.

물품 인큐베이터

안녕.

위키백과에 RFC가 있다.아티클 인큐베이터를 닫기 위해 인큐베이터/RfC를 닫으십시오.거기서 토론에 참여하십시오.

The OriginalSoni (talk) 07:33, 2013년 12월 23일 (UTC)[응답]

미발송 페이지에서 카테고리 자동 숨기기

지금, 우리는 네임스페이스 초안으로 옮겨진 몇몇 기사들을 가지고 있다.옛날에는 "사용자:XYZ/뭔가."현재, 그들은 "Draft:XYZ" 모든 것이 사용자 공간, 창작 공간 조항, 다른 사람들이 출품하는 곳이면 어디든 카테고리를 무효화하기가 더 힘들었다.이제 우리가 그것들을 하나의 공간에 두고 있기 때문에(글쎄, 이론적으로는 어쨌든), 사람들은 우리가 잠재적으로 눈에 띄지 않는 사람들/장소/사물을 일반 범주에서 제거할 수 있도록 그 범주들이 자동으로 무효화되거나 봇이 이 일을 하도록 하는 것에 반대할까?그것은 현재 이러한 범주에 존재하는 많은 잡동사니들을 제거해 줄 것이며, 그것은 종종 반쯤 작업된 글과 아이디어를 담고 있으며, 그 사이트를 청소하는 데 도움이 될 것이다.게다가, 기사가 옮겨지면, 그 사이트는 AFC 제출 과정에서 지금 일어나고 있는 것과 같은 이러한 카테고리를 자동으로 포함하도록 설치될 수 있다.케빈 러더포드 (대화) 07:14, 2013년 12월 24일 (UTC)[응답]

새로운 드래프트 네임스페이스에 대한 논의는 대개 위키백과에서 이루어진다.초안. 프라임헌터 (토크) 11:27, 2013년 12월 24일 (UTC)[응답]

이미지가 있는 템플릿 파괴 행위

지난 며칠 동안 WP에서 공공 기물 파손이나 "해킹"에 대한 보도가 몇 차례 있었다.A 및 WP:템플릿 파괴에 관한 ANI.반달들은 많은 기사들에 이미지를 배치하여 독자들의 주의를 딴 데로 돌리게 하고 나체나 징그러운 것으로 그들을 충격에 빠뜨릴 수 있는 고도로 사용되는 템플릿을 목표로 삼는다.반달리즘을 되돌리고, 템플릿을 보호하고, 이미지를 "나쁜 이미지"로 표시하고, 이 순간 현재 우리가 할 수 있는 일은 거의 없다.

나의 제안은 비록 그것을 구현하는 기술적 측면은 좀 더 복잡하지만 짧다.템플릿 네임스페이스에 이미지를 추가하려면 편집기에 자동 확증 권한이 있어야 한다.bugzilla를 제출하고 변경을 요청한 후 저장 버튼을 누르면 편집이 템플릿 네임스페이스의 이미지를 초월할 경우 소프트웨어가 계정 확인을 수행하고 계정에 자동 확인이 없으면 저장을 중지하고 미리보기 창으로 다시 가져온다.그들은 적절한 권리를 가지고 있지 않다.

그 결과는 다음과 같다.

대부분의 등록되지 않은 사용자들은 이미지를 템플릿 구문에 올바르게 배치하는 방법을 이해하지 못하거나 이미지가 템플릿 네임스페이스에서 일반적인 것이 아니라는 것을 이해하지 못하기 때문에 템플릿에 이미지를 추가하는 IP는 없을 것이다.이 문제와 관련하여, 공공 기물 파손의 대부분은 IP에서도 발생한다.이미지를 저장하기 위해 오토콘을 강제로 적용하면 최소한 계정을 생성해야 할 것이다.
반달리즘에 이미지를 추가하려는 의도를 가진 새로운 계정들 역시 작동하지 않을 것이다. 왜냐하면 오토콘 확증 허가는 그들이 약 4일을 기다려야 하고 10번 편집을 해야 한다는 것을 의미하기 때문이다. 이것은 그들이 며칠을 기다려야 하고 그것들을 차단하지 않는 편집을 해야 한다면 템플릿 반달리즘을 거의 무의미하게 만든다.반달들은 그런 식으로 지루해 한다.
새로운 것이 아닌 사용자들에게 그것은 아무것도 바꾸지 않는다.
유일한 잠재적인 담보는 템플릿 네임스페이스에 합법적인 이미지를 삽입하려고 시도하지만 그럴 수 없는 새롭고 선의의 사용자일 것이다. 그리고 이 문제를 경험하는 사용자 수는 상당히 적을 것이다.

안녕, — Moe Epsilon 04:17, 2013년 12월 19일 (UTC)[응답]

누군가가 그 문제를 해결할 수 있는 방법은 너무 많다(WP:BEANS; 알고 싶으면 이메일 보내줄게.)모든 템플릿을 효과적으로 반보호하지 않고서는 완벽하게 예방하는 것은 거의 불가능할 것이다.잭mcbarn (대화) 04:30, 2013년 12월 19일 (UTC)[응답]

Nirvana 오류#완벽한 솔루션 오류 참조. --Guy Macon (대화) 11:02, 2013년 12월 21일 (UTC)[응답]

그것은 문제를 끝내는 해결책이 될 의도가 아니다. 관리자만이 페이지를 편집할 수 있도록 사실상 완전한 보호 이외의 공공 기물 파괴 행위를 끝낼 방법이 없다.물론 그것을 극복하는 방법들도 있지만, 그것은 여전히 대다수의 그것을 막을 것이다.문제를 늦추기 위한 것이지 완전한 예방이 되기 위한 것이 아니다.그것은 일상적인 일이 되어가고 있고, 우리는 단지 그것을 기다려서 독자들이 다시 오줌 누는 여성의 이미지를 우연히 보게 하는 것 말고 다른 것을 바꿔야 한다.안녕, — Moe Epsilon 04:40, 2013년 12월 19일 (UTC)[응답]

이 제안을 가장 효과적인 대응책으로 지지하십시오. -- Ross Hill • Talk • 도움 필요?• 2013년 12월 19일 04:45, (UTC)[응답하라]

실제로 언급되지 않은 다른 두 가지 담보가 있는데, 1) 계정이 손상될 수 있는 보안되지 않은 연결에서 일반 편집자 편집과 2) 계정이 없는 일반 편집자가 있다.이 두 그룹 모두 전체 템플릿 네임스페이스의 반보호-에스크 편집 필터에 의해 부정적인 영향을 받을 수 있다.그래서 나는 이런 것에 반대해야 할 것이다.그러나 나는 WP의 확대를 지지할 것이다.성숙한 위키백과 대상 인포박스 및 확장 탐색 상자를 포함하여 반범위로 변환된 템플릿에 대한 기준을 작성하는 고위험 템플릿.VanIsaac_{WS Vex}^contribs 05:13, 2013년 12월 19일 (UTC)[응답]

"계정 없는 일반 편집자" — 이는 IP 액세스를 제한하자는 제안에 대한 영구적인(거의 신성함) 이의 제기다.이게 몇 개야?"정규적인"은 어떻게 정의되며, 정규 IP 편집 후 정리하는 데 시간과 노력을 들였기 때문에 작업과 비교해서 이들의 집단적 기여는 얼마나 큰가?~ J. Johnson (JJ ) (토크) 22:01, 2013년 12월 20일 (UTC)[응답]

얼마나 많은 장기 IP가 있는가?나는 이런 제안을 보면 "하지만 그렇게 되면 정규 IP 편집자들이 X를 하지 못하게 될 것"이라고 생각할 만큼 충분히 접했지만, IP와 관련된 문제에 부딪쳤을 때, 그들이 실제로 장기 IP 편집자라는 가능성에 대해 지나가는 생각 이상의 것을 주지 않는다.그러나 당신은 이것이 문제가 될 수 있는 템플릿의 종류에 대한 기본 반 보호 기능을 가져오기 위해 고위험 템플릿 정의를 확장하는 것에 대한 다른 조사 라인의 가능성을 무시하기로 선택했다. 그래서 나는 당신이 실제로 이 중 어떤 것을 심각하게 받아들이고 있는지, 아니면 내가 전혀 그렇지 않은 다른 일이 일어나고 있는지 모르겠다.보고있습니다VanIsaac 12_{WS Vex}^contribs:30, 2013년 12월 21일 (UTC)[응답]

「정규적인」(좋은가? 심각한가?)인 IP 편집자의 비율은, 단지 베이스가 크다는 이유만으로, 작으며, 그 총수도 의심스럽다.그러나 내가 궁금한 것은 이러한 소위 말하는 "정규 IP 편집자"의 기여가 모든 것을 반보호적으로 하지 않음으로써 필요한 작업과 비교했을 때 얼마나 실질적인가?~ J. Johnson (JJ) (토크) 20:27, 2013년 12월 21일 (UTC)[응답]

솔직히 말해서, 나는 잘 모르겠고, 누가 그것에 대해 제대로 된 추측을 할 수 있을지조차 확신할 수 없다.보통 어떤 종류의 충돌이 일어나지 않는 한, 개인적인 경험을 끔찍하게 편향시키고, 도구는 동적 IP를 통해 볼 수 없다.여기서 실제로 5개의 서로 다른 인구를 다루고 있는데, 그 중 많은 인구를 구별하는 것은 거의 불가능하며, 그 어떤 종류의 비교 열거도 할 수 없다: 1) 단일 사건 IP 반달 2) 편집 분쟁에 관여하는 단기 IP 편집자 3) 편집 충돌에 관여하지 않는 단기적이고 생산적인 IP 편집자 4) 장기적이고 생산적인 IP 편집자 4)편집에 관련된 ve IP 편집기 5) 편집 충돌에 관여하지 않는 장기적이고 생산적인 IP 편집기IP는 동적으로 할당되기 때문에 #2와 #4 또는 #3과 #5의 차이를 우리에게 말해줄 수 있는 툴이 없으며, 기본적으로 #3와 #5를 실제로 알아차릴 수 있는 수단이 없고, #1은 타겟팅하려는 유일한 그룹이지만 #2, #3, #4, #5는 모두 ge이다.십자 포화에 걸린 팅팅답은 모르지만, 이미지 태그가 있는 템플릿 편집에 대해 전면적으로 금지시키는 것은 과잉반응이라고 분명히 주장할 것이다.VanIsaac 21_{WS Vex}^contribs:57, 2013년 12월 21일 (UTC)[응답]

Visual Editor가 유일하게 잘했던 것 중 하나는 행동적 선택을 엿보는 것이었다.선택권이 주어졌을 때, 새로운 계정들은 Visual Editor의 약 25%를 사용했고, IP는 약 10%를 사용했으며, 편집자는 약 8%를 설립했다.그 팩토이드에 대한 약간의 수치를 보면 IP 편집자의 약 80%가 경험이 풍부한 편집자임을 알 수 있다.확실히 복음적 진리로 인용할 수는 없지만, 그럼에도 불구하고 흥미로운 지표다.—Kww(대화) 00:37, 2013년 12월 22일 (UTC)[응답]

그래, 그 통계는 꽤 흥미로웠어.그러나 "경험"은 반드시 "선"과 상관관계가 있는 것은 아니다; 그것은 대부분의 반달들이 경험했다는 것 이상을 의미하지 않을 수도 있다.IP가 하고 있는 모든 좋은 일들에 대해 아무것도 말해주지 않는 것 같아. ~ J. 존슨 (JJ) (토크) 00:44, 2013년 12월 23일 (UTC)[응답]

이것은 몇 년 동안 큰 문제가 되지 않았으니 반대하라.그것은 수 년 동안 IP 편집자들이 이따금씩 물건으로 더럽혀지는 것만으로 유용하고 적절한 이미지를 템플릿에 추가해 왔다는 것을 말해준다.그것은 나에게 이것이 너무 많은 부수적인 피해를 남길 수 있다는 인상을 남긴다.이것은 또한 IP가 (이미지를 거기에 배치하지 않았더라도) 이미지를 포함하는 템플릿을 편집하지 못하게 할 것이다.따라서, 만약 그들이 예를 들어 연도의 범위를 조정하거나 드물게 사용되는 버전에서 국가 이름의 오타를 수정하기 위해 플래그 아이콘 템플릿을 업데이트하고 싶다면, 그들은 편집 요청을 제출할 수 없고 요구될 것이다.이것은 너무 지루하고 나는 나쁜 생각이라고 생각한다.기술 13 (대화) 2013년 12월 19일 12시 59분 (UTC)[응답]

이것은 사실 몇 년 동안 문제였습니다. 단지 반달들이 시간이 지날수록 더 창의적이 되기 때문이었습니다. 이것이 바로 고위험 템플릿의 페이지가 존재하며 오랫동안 존재해온 이유였습니다.독자들에게 충격을 주기 위해 징그럽거나 나체로 된 이미지를 찾아 템플릿에 꽂는 것은 오랜 반달 전술이었다.단지 '나쁜 것'으로 표시되지 않은 이미지를 찾아내고 아직 보호되지 않은 새로운 템플릿을 찾아내는 문제일 뿐이고, 최근 들어 반달은 여전히 수백 개의 기사로 퍼져 있는 덜 위험한 템플릿을 악용해 고위험이 없는 것들을 보호하도록 강요하고 있다.또한 IP 편집자가 기존 이미지로 템플릿을 편집할 수 없을 것이라는 두려움은 필요하지 않다.저장 버튼을 클릭하면 소프트웨어는 변경해야 할 텍스트가 무엇인지 식별하며, 편집과 무관한 주변 텍스트가 아닌 기록의 디프트에 표시된다.소프트웨어는 삽입되는 새 텍스트를 해석하고 렌더링할 수 있는지 여부를 확인하는 것이다.[[File:imagename.extension]]또는[[Image:imagename.extension]] 성공적으로, 사용자에 대한 권한 확인이 수행될 것이다.기존의 이미지들은 문제가 되지 않을 것이고, 높은 담보에 대한 두려움 또한 실제로 보증되지 않는다.이미지는 템플릿 네임스페이스에서 많이 사용되지 않으며, 일반 편집자가 로그아웃한 외부에서는 대부분의 IP 편집자가 되돌리지 않는 이미지를 언제 삽입해야 하는지 또는 어떻게 삽입해야 하는지를 모를 수 있다.안부, — MoeEpsilon 17:42, 2013년 12월 19일 (UTC)[응답]

문제는 그것이 실현될 수 있을지를 알아낸다는 것이다.[[File:imagename.extension]]또는[[Image:imagename.extension]]할팅 문제는 해결이 불가능하기 때문에 (실제로, 할팅 문제는 해결이 불가능하기 때문에) 매우 어렵다.많은 거짓 긍정, 효과적으로 모든 템플릿을 반비례하거나 또는 거짓 부정으로 보호를 무가치하게 만들거나 둘 중 하나, 둘 중 하나이다.잭mcbarn (대화) 2013년 12월 19일 (UTC) 17:53[응답]

Nirvana 오류#완벽한 솔루션 오류 참조. --Guy Macon (대화) 11:02, 2013년 12월 21일 (UTC)[응답]

어, 그게 정지 문제와 무슨 상관이야?regex에서 added_text가 포함되는지 여부를 검색하는 것뿐입니다./\[\[(File Image):[^\]]+\]\]/ , (혹은 그런 것)2013년 12월 19일(UTC) 18:01, Writ Keeper ⚇[응답]

답장을 이메일로 보냈어.나는 WP때문에 그것을 공개적으로 게시하지 않을 것이다.콩. 잭맥바른 (대화) 2013년 12월 19일 (UTC) 18:31 [응답]
확실히 해두자면, 만약 누군가가[[File:imagename.extension]]템플릿에 바로 넣으면 쉽게 찾을 수 있지만, 그렇게 하지 않고도 이미지를 추가할 수 있는 방법이 있다.잭mcbarn (대화) 2013년 12월 19일 18:49 (UTC)[응답]

특수:남용필터/599.어떻게 될지 두고 보자.레고크tm (대화) 18:37, 2013년 12월 19일 (UTC)[응답]

특수:남용필터/599는 애논이 "템플릿:"에 이미지를 게시하는 것을 막지 못하는 것 같다.기술 13 (대화) 19:14, 2013년 12월 19일 (UTC)[응답]

필터 코드는 공개 보기에서는 숨겨져 있지만, 잘못된 긍정을 줄이기 위해 특정 조건(확정된 반달은 알고 싶지 않음)에서만 활성화되며, 편집을 방해하지 않고 기록만 남긴다(연결된 편집은 기록되지 않음).프라임헌터 (토크) 2013년 12월 19일 (UTC) 19:33[응답]

"거짓 긍정"이라는 말은 비반달리즘 편집의 로그들을 의미한다.프라임헌터 (토크) 2013년 12월 19일 (UTC) 19:38[응답]

제안에 공감하지만, 이 토론은 나에게 너무 기술적이다. Johnbod (토크) 22:05, 2013년 12월 20일 (UTC)[응답]
질문 - 이러한 높은 위험/높은 사용 템플릿에 대해 보류 중인 변경 사항(아마도 보류 중인 변경 사항 2와 같은 것)의 변종이 유용한 경우인가?만약 그것이 위키피디아를 가로지르는 파괴 행위를 중단한다면, 그것은 그것의 요점을 빼앗고, 또한 사람들이 실수로 높은 사용 템플릿을 만드는 가능성을 최소화하는 데 도움이 될 수 있다.나이젤 이스 (토크) 2013년 12월 21일 (UTC) 23:35 [응답]

아아, 보류 중인 변경사항 레벨 2는 선택사항이 아니다.

확장 콘텐츠

위키백과 사용자 그룹 및 페이지 보호 수준의 상호 작용
	미등록 또는 신규등록	확인됨 또는 자동 확인됨	연장확정	템플릿 편집기	관리인	인터페이스 관리자	에 적합하다. (다음 항목 참조):위키백과:보호 정책)
보호 없음	보통 편집						대부분의 페이지.(기본 보호 수준임)
대기 중이다. 보호 변경	모든 사용자가 편집할 수 있다. 등록되지 않았거나 새로운 편집자에 의한 편집(및 모든 사용자에 의한 후속 편집)은 보류 중인 변경 검토자 또는 관리자가 검토할 때까지 로그인하지 않은 독서자로부터 숨겨진다.로그인한 편집자는 승인 여부에 관계없이 모든 편집을 본다.						기물 파손, BLP 위반, 편집-경전 또는 등록되지 않은 사용자 및 새로운 사용자로부터의 기타 중단이 많은 페이지 간헐적으로 편집
반보호	편집할 수 없다	보통 편집					익명 및 등록된 사용자가 자주 편집하는 페이지, 일부 잘 보이는 템플릿 및 모듈
확장- 확정 양성자	편집할 수 없다		보통 편집*				ArbCom에서 인증된 특정 주제 영역, 반보호에 실패한 페이지, 템플릿 보호가 너무 제한적인 고위험 템플릿
템플릿 protect.	편집할 수 없다			보통 편집			고위험 또는 매우 자주 사용되는 템플릿 및 모듈, 템플릿 공간 외부의 일부 고위험 페이지
완전한 보호	편집할 수 없다				보통 편집		확장된 확인된 계정, 중요한 템플릿 및 모듈로 인한 지속적인 중단이 있는 기사
인터페이스 보호	편집할 수 없다					보통 편집	사이트 운영의 중심에 있는 스크립트, 스타일시트 및 유사한 개체
* 확장된 확정 보호를 통해 편집하려면 템플릿 편집기도 확장해야 하지만 실제로는 항상 그러하다. 기타 보호 모드: 보호 만들기 이동 보호 업로드 보호 사무실 보호 캐스케이드 보호 관람하다 이야기를 나누다

--Guy Macon (대화) 00:23, 2013년 12월 22일 (UTC)[응답]

PC2는 왜 선택이 안 되는가?그 RFC는 PC1이 출시된 후 6개월 정도 동안 그것을 사용하지 말라고만 말했다.PC2가 절대 사용되지 않을 수도 있다는 말은 없다. 그리고 사용했다고 해도, WP:Consensus는 바뀔 수 있다.PC2에 특히 적합한 경우 WP를 만드십시오.그렇게 할 것을 제안한다.WhatamIdoing (대화) 18:14, 2013년 12월 23일 (UTC)[응답]

그것은 기술적인 문제지 정책적인 문제가 아니다.보류 중인 변경사항 보호는 전폐를 통해 작동하지 않는다.최신판은 비록 받아들여지지 않더라도 항상 망각되어 있다.잭mcbarn (대화) 2013년 12월 23일 (UTC) 18:23[응답]

더 이상 관리자가 필요 없기 때문에 '고위험 템플릿'을 구성하는 것에 대한 문턱을 낮춰야 한다고 생각한다.완전한 보호를 위해서라면 반폐합계수의 반부터 시작해야 하지 않을까?어쨌든 그 문턱이 정확히 무엇이었는지 아는 사람 있어?약 2천명 정도로 낮게 봤다.댓글?불만?나는 이 아이디어에 둘 다 있을 거라고 확신해, 그러니 지금 당장 그것들을 얻는 게 좋겠어.기술 13 (대화) 05:52, 2013년 12월 22일 (UTC)[응답]

확실히는 모르겠어.고위험 템플릿 가이드라인은 각 템플릿을 개별적으로 검토했으며, 이를 개별적으로 재평가해야 할 수도 있다고 말한다.분명한 것은 높은 폐색 카운트 문제가 있지만, 눈에 잘 띄고 계단식 보호가 되지 않는 템플릿과 대체 템플릿도 높은 위험성이 있다.마찬가지로 뺑소니 기물 파손 및 소수의 페이지에서의 전신에 대한 일회성 표적이 반보호되어서는 안 되었다.남용 필터 599는 어떤 상태인지, 어떤 기록인지 잘 안 보여서 궁금하다.안녕, — Moe Epsilon 07:49, 2013년 12월 22일 (UTC)[응답]

반대 이것은 템플릿 편집자 RfC를 완전히 위반한다. "고위험 템플릿을 구성하는 것에 대한 표준은 새롭게 만들어진 보호 수준과 권리 그룹에도 불구하고 변경되지 않고 확장되어서는 안 된다는 것을 이해해야 한다."잭mcbarn (대화) 2013년 12월 22일 16:19 (UTC)[응답하라]

나는 단지 새로운 사용자 권리를 근거로 그것을 바꾸자고 제안하는 것이 아니다.나는 문턱을 바꾸는 것을 제안하는 것이다. 왜냐하면 지금은 더 낮은 수준의 전폐를 가진 템플릿에 공공 기물 파손의 증거가 있기 때문이다.거기엔 큰 차이가 있어, 네가 그걸 봤으면 좋겠어.기술 13 (토크) 00:06, 2013년 12월 23일 (UTC)[응답]

당신은 위에서 "관리자가 더 이상 필요하지 않기 때문"이라고 말했다.그것은 정확히 새로운 사용자 권리 때문에 있는 것과 같다.Jackmcbarn (대화) 17:08, 2013년 12월 23일 (UTC)[응답]

"이미지가 있는 템플릿 파괴 행위"라는 제목의 섹션에서는, "관리자가 더 이상 필요하지 않기 때문"이라는 것만이 유일한 이유는 아니다.기술 13 (대화) 2013년 12월 23일 (UTC) 17:52, 응답

그렇다, 나는 Rfc 기간 동안 많은 편집자들이 새로운 권리를 반대하는 이유는 시간이 지남에 따라 권리를 가진 사람들이 점점 더 많은 템플릿을 보호해야 할 이유를 찾을 것이라고 믿었기 때문에 그것이 없는 사람들에게 좌절감을 안겨주었기 때문인 것으로 기억한다.—안네 들롱 (대화) 05:51, 2013년 12월 23일 (UTC)[응답]

나는 차라리 전횡에 대한 기록 정보를 추가하고, 가능하다면 요약이 기록 페이지에 이미지를 추가하거나 삭제하는 솔루션을 보고 싶다.예를 들어 아티클이 템플릿을 사용한 경우:Infobox_Foobar는 해당 템플릿의 최근 변경 내용을 기록에 표시해야 한다.템플릿에 대한 전체 기록을 표시할 필요는 없으며 전체 기록에 대한 링크가 있는 각 템플릿에 대한 가장 최근의 기록만 표시할 필요가 있다.PaleAqua (토크) 08:26, 2013년 12월 23일 (UTC)[응답]

이제 그런게 있잖아.사용자:Anomie/previewtemplatelastmod Jackmcbarn (talk) 17:08, 2013년 12월 23일 (UTC)[응답]

나는 그 대본에 익숙하다.그래서 역사 페이지를 위해 이것을 하는 것이 가능해야 한다고 생각한다.역사 페이지는 반달리즘을 다루기 위한 미리보기 페이지보다 더 나은 곳인 것 같다.페이지가 파손된 것을 알아차렸을 때 내가 제일 먼저 하는 수표는 기록 페이지인데, 나는 이것이 꽤 흔하다고 생각한다.또한 템플릿 변경이 원인일 수 있다고 자동으로 고려하지 않는 편집자는 common.js 파일에 사용자 정의 js 스크립트를 추가할 편집자도 아닐 가능성이 높다.PaleAqua (대화) 2013년 12월 23일 (UTC) 18:09 [응답]

이 모든 것이 정말로 필요한 것은 템플릿 파괴 행위를 발견하고 되돌리는 빠른 방법이다.대부분의 불만은 사람들이 발견하는데 어려움을 겪기 때문에 고치는 것이 더디다.예를 들어, 파손된 페이지의 "관련 변경사항"을 사용하고 템플릿 네임스페이스로 제한하는 것보다 더 어려운가?그렇지 않은 경우 지침은 AN/ANI 편집 통지에 포함되어야 한다.사람들은 위키피디아를 편집하는 것이 불편하기 때문에, 템플릿에서든 아니든, 공공 기물 파괴의 징후를 보여주는 기사가 나면, 여전히 ANI와 관련 게시판으로 달려갈 것이다.—/Mendaliv///^2¢_Δ's 08:43, 2013년 12월 29일 (UTC)[응답]

이 반달리즘의 한 사례의 결과를 다룬 편집자 중 한 명으로서, 내가 여기서 작용하게 된 것을 알아차린 더 큰 요인이 있다.템플릿이 반환된 후에도, 몇몇 편집자들은 여러 기사에서 오래된 파손된 템플릿을 보았다고 보고했다.(이것은, 같은 것을 볼 수 없음에도 불구하고)

이것은 페이지의 삭제와 관련된 것이었고, 나는 그것의 기술적 특성을 이해하지 못하지만, 우리는 파괴된 버전이 일부 독자들에게 보여지지 않도록 하기 위해 우리의 반달파이터들이 이것을 확실히 알아야 한다.The OriginalSoni (talk) 2013년 12월 29일 (UTC) 11:17[응답]

따라서 기술성은 다음과 같다. 종속 템플릿이 변경될 때 페이지는 자동으로 삭제되지만, 즉시 삭제되지는 않는다.action=purge그런 페이지에 단추를 끼우다.그들은 작업 대기열의 맨 아래로 간다.아마도 작업 대기열의 맨 위로 템플릿 반달리즘 되돌리기를 위한 메커니즘이 있어야 할 것이다(예를 들어, 되돌리는 사람은 AN/ANI에 요청을 게시할 것이고, 고급 권한을 가진 사람은 그러한 단계적 숙청을 강요할 수 있는 권한을 부여받을 것이다). 비록 이것이 MediaWiki l에서 개발자의 개입을 필요로 할 것이라고 상상하지만.evel.———/Mendaliv//^2¢_Δ's 11:25, 2013년 12월 29일 (UTC)[응답]

Mendaliv 사용자 스크립트/봇이 제안된 삭제를 수행할 수 있을 만큼 충분할까?The OriginalSoni (talk) 2013년 12월 29일 12시 45분 (UTC)[응답]

대본은 아마도 효과가 있을 것이다. 그러나 나는 WP에 접근하는 문제들이 있다고 생각한다.콩 영역.개발자 수준에서 구현되는 것을 보고 싶다. 이 작업을 처리하고 스크립팅과 관련된 작업을 차단한다.—/Mendaliv///^2¢_Δ's 12:52, 2013년 12월 29일 (UTC)[응답]

최근 기획된 템플릿 반달리즘이 급증하고 있는 점을 감안할 때, 임시/임시적 조치라고 하더라도 IP 편집 템플릿에 대한 일종의 제한이 필요하다고 믿을 만한 이유가 있다.담보물이 있을 것이라는 데는 동의하지만, 우리는 대화 페이지에 배치되어 템플릿 편집을 요청할 수 있는 일종의 {{템플릿-편집}}템플릿을 사용하여 처리할 수 있다(현재 {{Help me}의 작동 방식과 유사함).The OriginalSoni (talk) 2013년 12월 29일 (UTC) 11:17[응답]

나는 위키피디아에서 RFC를 시작했다.마을_펌프_(정책)#템플릿_템플릿 보호를 위한 Vandalism.The OriginalSoni (토크) 2013년 12월 29일 (UTC) 19:46[응답]

위키.png

곧 새해가 밝기 때문에 파일을 위해 새해 테마로 특별 출두할 것을 제안하고 싶다.Wiki.png는 단 이틀 – 31/12'13 및 01/01'14.파일 업로드 기록을 보면 알 수 있듯이, 이것은 전에는 연습이 아니었다.(아무에게도 그런 일이 일어나지 않았는지도 모른다.)하지만 왜 우리는 특별한 휴일 세부사항으로 우리의 위키 공간을 더 좋게 만들지 않을까?나는 우리 중 많은 사람들이 올해 매우 열심히 일했다는 것에 의심의 여지가 없다. 그래서 우리는 축하할 것이 아주 많다.그렇게 생각하지 않니?알렉스^{discussion ★} 08:57, 2013년 12월 26일 (UTC)[응답하라]

좋은 생각이야!파티모자 준비 중. --NaBUru38 (토크) 21:21, 2013년 12월 27일 (UTC)[응답]

@알렉사 루키치: 나는 그 사상의 정신을 좋아하지만 그것이 실제로 이루어져야 하는지는 잘 모르겠다.현재, 그리고 내가 아는 한, 우리는 10주년 기념행사 이외에 어떤 다른 기념식이나 축제의 로고를 바꾸지 않았고 바꾸지 않았다.새해를 기념함으로써 우리는 양력 새해의 날짜를 다른 사람에 대한 '특별 대우'(즉 중국의 새해)로 정했을 뿐 아니라, 이는 단지 enwp에 서구 세계에 대한 체계적 편견을 악화시키는 것처럼 보일 뿐이다.편집자들이 행사를 기념하고 싶다면, 그들은 DYK, TFA, FP 등에서 특별한 날 동안 기사를 지명할 수 있다. 비록 나는 개인적으로 로고를 세속적이고 논쟁적이지 않으며 비정치적인 사건들을 표시하는 재미있고 가벼운 방법으로 바꾸는 것에 공감한다.흥청망청해서 미안하지만, 이번 설날에만 하는 것이 아니라 원칙적으로 행사 로고를 바꾸는 것에 대한 전반적인 합의가 필요할 것 같아.그리고 좀 늦었어. 괜찮은 로고를 잘 꾸며서 제때에 결정해 줄 수 있을까?아쉽게도 의심스럽다. :(Acather96 (연락하려면 여기를 클릭) 22:33, 2013년 12월 27일 (UTC)[응답]

Acather의 말에 전적으로 동의한다.나는 특정한 경우에 우리의 로고를 바꾸는 것을 좋아하지만, 우리는 그것을 실행하기 전에 주어진 선택된 이벤트(및 지정된 대체 로고)에 대한 광범위한 합의가 필요하다.확실히 더 긴 논의를 위해 심사숙고해야 할 생각이다.The OriginalSoni (talk) 00:11, 2013년 12월 28일 (UTC)[응답]

나는 Acather의 말에 동의하지만, 나는 이 아이디어를 좋아하기 때문에(그리고 내가 실제로 DDOwiki에 설정한 것과 같은 선에 있는 것은) 이것이 이용 가능한 것으로 보고 싶은 사람이라면 누구나 이용할 수 있는 사용자 설명서를 기꺼이 쓸 것이라고 덧붙이고 싶다.나는 실제로 그 이미지를 바꾸는 다른 스크립트가 있는데, 그것은 .sysop-show (관리자와 템플릿 편집자를 위해 고안된 숨겨진 섹션) 페이지에 어떤 일이 일어나고 있다는 것을 상징하기 때문에 그러한 논평과 노트를 표시하거나 숨기도록 설정을 전환할 수 있다.그래서, 만약 내가 이 제안에 적절한 크기의 .svg 이미지를 기꺼이 만들 수 있는 사람을 찾을 수 있다면, 나는 어떤 휴일이나 가능한 이미지가 있는 행사에 대해 정확한 날짜에 이미지를 바꿀 수 있는 대본을 쓰고 싶다.각 사용자가 사용자 공간에 휴일 목록을 정의할 수 있도록 사용자 지정이 가능했다.이것이 위키피디아에 있는 모든 독자와 편집자에게 휴일/종교/이벤트를 똑같이 강요하는 것에 대한 허용 가능한 대안인지 내게 알려줘.행복한 편집!기술 13 (대화) 01:44, 2013년 12월 28일 (UTC)[응답]

FYI - 위키백과에 휴일 로고가 있다.위키백과_Signpost/2013-12-25/토론_보고서GoingBatty (토크) 05:20, 2013년 12월 28일 (UTC)[응답]

그 이미지를 일반인들에게 보여주고 고양이 구조물을 살펴보니, 현재 휴일 로고는 많지 않아...크리스마스, 할로윈, 발렌타인, 성 패트릭스 같은 날은 보지만 새해, 하누카, 부활절, 추수감사절, 독립기념일 등 다른 명절에는 보지도 않는다.그런 것들을 잘 하는 사람이라면 누구나 자진해서 로고를 만들고 싶은가?기술 13 (토크) 01:57, 2013년 12월 29일 (UTC)[응답]

RFC on Template 보호

여보세요

위키백과에 RFC가 있다.마을_펌프_(정책)#템플릿_템플릿 반달리즘을 처리하기 위해 순서대로 템플릿을 보호하는 Vandalism.토론에 참여하십시오.

고마워, The OriginalSoni (토크) 19:47, 2013년 12월 29일 (UTC)[응답]

모든 Wiki 문서에서 "Like & Comment" 옵션 필요

친애하는 위키 팀에게,

나는 모든 위키 기사에 "라이크 앤 코멘트" 옵션이 있어야 한다고 제안한다.페이스북과 마찬가지로 이 두 가지 옵션은 기사를 더욱 매력적으로 만든다.

감사 & 안부, Vinod Patil — 41.194.23.4 (대화 • 기여) 10:55, 2014년 1월 2일 (UTC)[응답]

기사 피드백을 참조하면 위키백과 기사로 피드백을 보낼 수 있으며, 페이지마다 고전적인 대화를 할 수 있다. --Rezonansowy (대화 • 기여) 13:16, 2014년 1월 2일 (UTC)[응답]

WP에 제안된 변경사항:리드

나는 다른 편집자들의 의견을 필요로 하는 리드에 대한 가이드라인에 대한 두 가지 변경을 제안했다.그들은 위키백과 강연에 있다.스타일/리드 섹션 #4항 리드 및 위키백과의 대화:스타일/리드 섹션의 매뉴얼#기사 범위.SpiningSpark 00:23, 2014년 1월 7일 (UTC)[응답]

계정 병합 및 삭제

mw: 구현을 고려해 본 적이 있는가?확장:UserMerge?보아하니 적어도 하나의 WMF 프로젝트에 의해 이미 사용되고 있는 것 같으니까, 기술적 관점에서 여기서 할 수 있어야 하는데, 아이디어는 좋은 것 같다.나이튼드 (대화) 01:22, 2014년 1월 7일 (UTC)[응답]

이것은 Wikivoyage Wiki가 수입될 때만 사용 가능했기 때문에 Wikiboyage 데이터베이스와 WMF Wiki의 나머지 사용자들을 적절히 병합할 수 있었다.CentralAuth(CentralAuth)를 존중하지 않기 때문에 기본적으로 비스타터(Non-starter)이지만, CentralAuth(CentralAuth)를 위해 구현한 용도보다 더 넓은 용도가 필요하다.^데몬 ^{[omg plz]} 02:02, 2014년 1월 7일 (UTC)[응답하라]

실행 취소 불가능으로 설정

그것은 오직 관리자만이 실행 취소를 취소할 수 있다면 편집 전쟁의 횟수를 크게 줄일 수 있을 것이며, 예외는 누구나 실행 취소를 취소할 수 있다는 것이다.만약 편집하지 않은 사람이 실수를 해서 편집에 문제가 생긴다면, 대신, 인증된 사람들이 편집 전쟁을 했다는 것이 밝혀진 후 일정 기간 동안 완전히 차단되기 보다는 실행하지 않은 것을 되돌리는 것을 막을 수 있을 것이다.블랙밤추 (토크) 04:38, 2014년 1월 7일 (UTC)[응답]

이것은 단지 공공 기물 파손 행위를 제거하기 어렵게 만들 것이다.그리고 전쟁을 편집하는 편집자들은 여전히 이전 버전의 기사로 가서 저장을 클릭할 수 있다. --NeilN 04:44, 2014년 1월 7일 (UTC)[응답]

비스타터.이유: 닐N이 말한 것을 보라.GenQuest 05:34, 2014년 1월 7일 (UTC)[응답]

VE on Wikipedia: 네임스페이스

위키백과에서 시각적 편집자: 네임스페이스? --Rezonansowy (대화 • 기여) 17:29, 2014년 1월 1일 (UTC)[응답]

사람들이 그것을 하고 싶다면 기술적으로 가능하다.하지만 비주얼에디터는 게시물에 서명하는 방법을 모르기 때문에 이런 페이지에는 특별히 유용하지 않을 것이다.Whatamidoing (WMF) (토크) 19:25, 2014년 1월 1일 (UTC)[응답]

위키피디아 페이지는 대화만 다루는 것이 아니라 기사 같은 페이지가 많이 들어 있어 좋은 생각이 될 것 같다. --Rezonansowy (대화 • 기여) 13:14, 2014년 1월 2일 (UTC)[응답]

이것에 대해 다른 의견이 있으십니까?Whatamidoing (WMF) (토크) 21:34, 2014년 1월 2일 (UTC)[응답]

VE의 주안점은 새롭고 경험이 부족한 편집자들이 기사 영역에 기여하도록 격려하는 정도라면, 나는 요점을 모르겠다.만약 경험이 많은 편집자들이 그것이 유용하다고 생각한다면, 그리고 우리는 이전의 메인 스페이스 문제를 피할 수 있을 것이다.우리는 새로운 사람들이 WP: 우주에서 많은 편집을 하기를 원하지 않는다. 그렇지 않은가?Wbm1058 (대화) 21:47, 2014년 1월 2일 (UTC)[응답]

그러나 WP:Draft 네임스페이스는 또 다른 이야기다.그곳은 VE를 베타 테스트하기에 완벽한 장소일 수 있다! Wbm1058 (토크) 21:51, 2014년 1월 2일 (UTC)[응답하라]

새로운 사용자가 위키피디아에서 말할 가치가 있는 것이 있다면, 네임스페이스로 바로 가서 해야 한다.나에게 있어 WP 공간에서 VE를 활성화하는 문제는 기사형 페이지와 토크형 페이지가 혼합된 것이고, VE는 아직 서명을 처리할 수 없다는 것이다.초안: 네임스페이스에 대해서는 VE가 이미 사용 가능한 것으로 보인다(내 의견대로).2014년 1월 2일(UTC) 노부수나^talk 22:02[응답]

그러나 VE를 사용하려면, 초안: 네임스페이스에서라도 사용자 환경설정에서 VE를 사용 가능으로 설정해야 한다.나는 지난 여름 논란이 많았지만, 이것이 WMF가 VE를 기본 편집자가 되도록 하는 데 대한 합의를 얻을 수 있는 유일한 네임스페이스라고 제안하고 있다.– Wbm1058 (대화) 22:26, 2014년 1월 2일 (UTC)[응답]

자, 이제 어떻게 되는 겁니까? --Rezonansowy (대화 • 기여) 20:03, 2014년 1월 3일 (UTC)[응답하라]

현재로서는 기술적으로 이것을 할 수 없다.하지만 사람들이 원하면 버질라에서 요청서를 작성할 수 있고, 우리는 그들이 그것을 가능케 할 수 있는지 알 수 있었다.Whatamidoing (WMF) (토크) 23:26, 2014년 1월 3일 (UTC)[응답]

WMF(Whatamidoing, WMF), 드래프트 네임스페이스에서 활성화와 관련된 이슈를 추적할 수 있는 버그를 만들어주면 고맙겠다.나는 bugzilla:50172가 문제들 중 하나라고 생각한다.존 반덴버그 2014년 1월 8일(UTC) 11시 8분 [응답]

나는 너를 위해 T61885를 만들었다.나는 아직 거기에 추가해야 할 다른 것을 찾지 못했다.Whatamidoing (WMF) (토크) 22:05, 2014년 1월 9일 (UTC)[응답]

내 의견으로는 비주얼 에디터는 버려야 하며, 영어 위키백과의 어떤 면에서도 디폴트가 되지 말아야 한다.물어봤잖아.카라이트 (대화) 03:04, 2014년 1월 4일 (UTC)[응답]

그리고 왜 그럴까?The OriginalSoni (talk) 03:17, 2014년 1월 4일 (UTC)[응답]

Carrite, 위키피디아의 힘은 당신이 항상 선택할 수 있다는 것이다.VE를 사용하거나 코드를 편집하거나 VE 편집에서 직접 코드로 전환할 수도 있다.그것은 커뮤니티 프로젝트의 힘이다. 아무도 당신이 무엇을 사용하고 있는지 결정하지 않는다. --Rezonansowy (대화 • 기여) 10:21, 2014년 1월 4일 (UTC)[응답]

이 진술은 VE에 대해서는 정확하지만, FLOW에 대해서는 정확하지 않다.--Ymblanter (대화) 15:28, 2014년 1월 4일 (UTC)[응답]

VE는 서명 추가를 허용하지 않을 뿐만 아니라(bugzilla:51154/bugzilla:51899) 기존 서명도 손상시킨다(bugzilla:59229).또한 섹션을 효율적으로 편집할 수 없다(bugzilla:48429).특정 페이지(bugzilla:50883)에서 VE를 활성화할 수 있도록 하는 강화 요청이 있다(예: 프로젝트 공간의 샌드박스).나는 관련 이슈에 대한 추적 버그를 시작했다.bugzilla:59818 John Vandenberg 11:05, 2014년 1월 8일(UTC)[응답]을 참조하십시오.

날짜 형식 및 언어 템플릿에 편집 알림 추가

일부 소프트웨어 변경이나 연장이 필요할 수 있어 실용적일지는 모르겠지만, 날짜 형식과 언어 템플릿(예: {{영국식 영어 사용}, {{미국식 영어 사용}, {{dmy 날짜 사용} 등)을 초월하는 페이지에 편집 공지를 표시하도록 구성할 수 있을까?사용자가 대화 페이지나 기사 본문의 하단, 또는 모호한 숨겨진 카테고리에서 템플릿을 찾을 필요 없이 어떤 형식을 사용해야 하는지 사용자에게 알려주는 꽤 깔끔한 방법이 될 수 있다. --W. D. Graham 11:15, 2014년 1월 7일(UTC)[응답]

방금 새 하위 범주 범주를 만들었어:영어 방언에는 영어 템플릿을 사용하십시오.관리자와 템플릿 편집자만이 이러한 메시지를 만들거나 편집할 수 있는 적절한 편집 메시지를 만드는 것은 봇에게 좋은 작업이 될 수 있다.그러나 나는 이 템플릿들의 목적에 대해 혼동이 있다고 생각한다.이미 하나의 영어 사투리를 일관되게 사용하고 있는 기사에 대한 자문 메시지로 설계되어 있는가, 편집자가 기사에 다른 사투리를 도입하는 것을 방지하기 위해 설계되어 있는가, 아니면 날짜별 범주화가 의미하는 바와 같이 일단 문제가 수정되면 제거되도록 의도된 사투리가 혼합되거나 부정확한 기사에만 태그를 붙이기 위해 설계되어 있는가?.g.category:2013년 12월부터 미국식 영어 사용. – Wbm1058 (대화) 18:05, 2014년 1월 7일 (UTC)[응답]

나는 이것을 위해 봇을 사용하는 것보다, 자바스크립트를 사용하여 편집인트로스를 주입할 수 있을 것이라고 생각한다. 이것은 BLP에게 지금과 같은 방식이다.잭mcbarn (대화) 2014년 1월 7일 18:13 (UTC)[응답]

{{use dmy date}}에 대한 문서에는 "기사 내에서 일관된 형식을 유지하기 위한 것"이라고 명시되어 있다.그것은 일시적인 "정리" 템플릿이 아니다.템플릿의 원래 목적 중 하나는 편집 시 이러한 템플릿을 찾는 몇 명의 사용자(자신을 포함)를 알고 있지만 봇을 안내하는 것이었습니다.익숙하지 않거나 볼 곳을 알고 있는 사용자들을 안내하는 편집통지서 등 좀 더 눈에 띄게 하는 것이 좋을 것 같다는 생각이 들었다. --W. D. Graham 18:13, 2014년 1월 8일 (UTC)[응답]

맞아, 나는 두 가지 모두 영구적인 권고사항일 뿐이라고 생각해.잘못된 날짜 형식이나 잘못된 사투리를 알아차린 편집자는 다른 사람을 위해 태그를 달지 말고 바로 그 자리에서 수정해야 한다.그런 점을 감안하면 굳이 카테고리를 하위 분류할 필요는 없을 것 같다.밀린 일이 없으므로 dmy 날짜 또는 Use English by monthly 카테고리를 사용하십시오.Wbm1058 (대화) 22:48, 2014년 1월 8일 (UTC)[응답]

오, 미안, 이제 알겠어.날짜는 봇이 주기적으로 방문하여 날짜 형식이나 사투리를 수정하는 것을 사용하기 위한 것이므로, 봇이 날짜 또는 형식 불일치를 확인하기 위해 마지막으로 지나간 시간을 알 수 있다.Wbm1058 (대화) 22:52, 2014년 1월 8일 (UTC)[응답]

{{편집통지서}에 메모를 붙이는 매개 변수(2개)를 추가하는 것이 효과가 있을까?템플리트가 페이지 자체에 있는 경우, Maint Bots는 적어도 TE 그룹에 속하거나 편집 요청을 자동으로 제출하는 경우 편집 통지에 추가할 수 있다.샌드박스에서 그걸 만들어내면 좋겠어.기술 13 (대화) 22:39, 2014년 1월 8일 (UTC)[응답]
템플릿과 같은 경우:편집통지서/페이지/국제우주정거장?하지만 국제우주정거장을 편집하면, {{영국식 영어 사용}} 템플릿도 가지고 있는 것을 알 수 있다.어떻게 우리가 그 중복성을 피할 수 있을까? 그리고 편집 고지와 고양이 둘다 가질 수 있을까?Wbm1058 (대화) 22:58, 2014년 1월 8일 (UTC)[응답]

그건 그냥 못생겼어...하지만, 그래, 그것만 비슷한 것이 완전히 새로운 편집 템플릿 대신에 매개 변수가 될 것이다.어쨌든, 왜 중복이 되는 거지?템플릿이 실제로 아무것도 표시되지 않는 것 같음(아마 뭔가 꺼진 게 있어서 안 보이는 건가?)기술 13 (토크) 00:43, 2014년 1월 9일 (UTC)[응답]
내가 준 링크는 당신이 편집 고지를 편집할 때 보이는 것과 똑같다.기사를 편집할 때는 이겁니다.나한텐 잘 어울리는데.원본 포스터의 질문을 명심하라.{{영국식 영어 사용}}} 태그로 아무 페이지나 만들 수 있을까? 자동으로 편집 통지가 뜨는 거지?공지사항을 별도로 수정해야 하는 것은 불필요한 것이다.위에서 가장 촉망되는 대답은 "지금 BLP에게 하는 것과 같은 방법으로 JavaScript를 사용하여 편집인트로스를 주입하자"는 제안이었다.나도 언젠가 그걸 어떻게 하는지 배워야겠어.Wbm1058 (대화) 04:24, 2014년 1월 9일 (UTC)[응답]

찾음! – 편집 통지가 아닌 이 템플리트와 함께 편집 소개 사용.바로 그거예요!WP 참조:편집인트로. Wbm1058 (대화) 05:09, 2014년 1월 9일 (UTC)[응답]

위에서 잭이 말한 것과 같은 것인데, 그 요령은 미디어위키에 필요한 코드를 추가하기 위한 커뮤니티의 합의를 이끌어내는 것이다.보통.js. 암탉의 이빨을 잡아당기는 것과 같을 수도 있다.기술 13 (토크) 05:37, 2014년 1월 9일 (UTC)[응답]
- 그가 WP와 연결하지 않았다는 것만 빼면:디테일을 더욱 명확히 하는 EDITINTRO.이것은 편집자들이 그들의 common.css 또는 common.js를 편집하여 선택하도록 함으로써 우리가 테스트할 수 있는 것인가?만약 사람들이 투표 전에 도로 주행 테스트를 할 수 있는 기회가 있다면, 합의를 얻기가 더 쉬울 것이다.BTW 나는 아직 나의 공통점을 만들지 못했다.나는 위의 {{orphan}}개념이 정말 효과가 있다고 믿는다. 그렇지 않으면 어떤 사람들은 "파괴"라고 말하면 일리가 있을지도 모른다.Wbm1058 (대화) 14:09, 2014년 1월 9일 (UTC)[응답]
  - BLP와 DAB 알림의 구현 방식을 살펴보면, 자바스크립트가 고정되기 위해서는 중심 카테고리나 html 요소가 있어야 할 것으로 보인다.우리는 눈에 보이지 않는 html 요소를 넣어야 할지도 모른다 - <div id=>와 같은.각 템플릿에 "XXXEnglish" style="display:none;"</div" - 를 사용하여 스크립트를 트리거하십시오. --W. D. Graham 14:56, 2014년 1월 9일(UTC)[응답]
    - 중앙 카테고리, 카테고리:영어 템플릿을 쓰세요, 아마 유용할 겁니다.Wbm1058 (대화) 15:35, 2014년 1월 9일 (UTC)[응답]
    - 더 가능성이 높은 것은 다음과 같은 것이다.<span id="UseEnglish" data-which="XXX"></span>. 스크립트는 해당 ID를 찾아 어떤 매개 변수인지 읽어낼 것이다.아노미슈 01:12, 2014년 1월 10일 (UTC)[응답]

나는 Edokter나 Stradivarius씨가 위의 고아 논의를 고치는 방법으로 공통.js/css를 제안했던 사람이라고 믿는다.{{Opan}}}이(가) 사용하는 메시지 박스 템플릿과 여러 이슈에 대해 루아 모듈을 통해 인라인으로 쉽게 해결할 수 있다고 생각한다.나는 그 페이지에 무언가를 추가하는 것이 얼마나 고통스러운 일인지 알기 때문에 차라리 흔한 일 없이 그것을 하려고 한다.시험에 관한 당신의 질문에 대해, 만약 그것이 인기를 얻는다면, 우리는 그것을 사용자 설명서로 만들 수 있다. 만약 그것이 확실히 더 넓은 범위의 사용을 얻기 위한 기기로 지명될 수 있다. (그것은 지역사회가 생각하는 것에 기초하거나 디폴트 오프로 설정될 수 있다.)기술 13 (대화) 15:04, 2014년 1월 9일 (UTC)[응답]
- 맞아, 구현 경로는 사용자 기술 → 선택적 기기 → 필수 기기일 수 있고, 지금까지 오직 불명예와 BLP만이 그 수준으로 올라갔기 때문에 마지막 장애물이 가장 어려울 수 있다고 생각해.
- (iii) 다음과 같은 두 가지 문제가 있다는 것을 기억하십시오. (1) 그들이 가져올 수 있는 고아 순찰 편집자 텍스트를 common.css에 제공하여 항상 {{ visible}}}을(를) 볼 수 있도록 한다.우리는 이것을 샌드박스 템플릿과 함께 작동하는 {{orphan/sandbox}}과 common.css 코드로 지금 바로 테스트하고 있을 수 있다.{{orphan/sandbox}}}}}은(는) 기본적으로 보이지 않으며, {{multiple 발행}} 내부에서도 보이지 않는다.이 작품은 필수로 생각한다{{orphan/sandbox}}}과 common.css 텍스트는 내가 테스트할 수 있도록 준비되어 있는가?이슈(2)는 {{여러 이슈}}}에서 기본적으로 표시되도록 하고 있다.나는 이 작품을 선택사항으로 생각하고 있으며, 아마도 여전히 논란이 있을 수도 있다고 생각한다. - Wbm1058 (대화) 15:35, 2014년 1월 9일 (UTC)[응답]
- (더 많은 사이드바) 아, 미안. (입밖으로 발을 빼는) 며칠 전에 테스트를 했어야 했는데.온 토픽 위치로 돌아가는 중...Wbm1058 (대화)20:39, 2014년 1월 9일 (UTC)[응답]

파일을 마우스 오른쪽 단추로 클릭하여 전체 해상도로 보기

나는 위키피디아 기사에 있는 어떤 이미지 파일을 마우스 오른쪽 단추로 클릭하는 것은 기사에 대한 완전한 해상도 버전을 만들어야 하며, 두 번째로 마우스 오른쪽 버튼을 클릭하는 것과 이미지 마우스를 움직이면 이미지가 화면에서 사라지게 될 것이라고 생각한다.이렇게 하면 번거로운 두 번의 클릭으로 전체 해상도로 볼 수 있고 다시 기사로 돌아갈 수 있는 두 번의 클릭을 피할 수 있다.이미지의 치수 중 하나가 컴퓨터 화면의 치수보다 큰 경우, 이미지를 왼쪽 클릭하는 것은 화면 피팅과 전체 해상도 사이에서 교환되어야 하며, 최대 해상도로 볼 때, 한 치수 또는 두 치수 모두 화면의 잘린 부분을 차지할 수 있도록 이미지를 끌기 위한 손 기호가 있어야 한다.스크롤 막대나 브라우저 상단을 통해 화면에 표시되는 이미지 양을 줄이거나, 화면 크기보다 크거나 둘 다 크면 전체 화면편집 중에 편집 내용을 손실하지 않고 새 탭에서 파일을 열 수 없는 문제가 발생한다.이 문제는 미리보기의 아무 링크나 마우스 왼쪽 단추로 클릭하면 자동으로 새 탭에서 해당 링크를 열 수 있다.편집 중에 검색란에 입력하고 돋보기 기호를 클릭하면 검색 결과가 자동으로 새 탭에서 열리게 된다.블랙밤추 (토크)20:24, 2014년 1월 7일 (UTC)[응답]

깜빡했네, 왼손 클릭은 손 기호가 있는 이미지를 끌 때와 불가능한 화면 피팅과 전체 해상도를 전환할 때 모두 사용한다는 걸.이 문제에 대한 한 가지 해결책은 좌클릭이 화면 피팅에서 전체 해상도로 전환될 수 있도록 만드는 것이지만 다른 방법은 아니다.스크린 피팅 버전의 이미지를 보고자 하는 사람들은 애초에 그것을 클릭하는 것을 그냥 내버려둘 수 없다.또 다른 해결책은 화면보다 큰 이미지의 전체 해상도 버전을 마우스 왼쪽 단추로 클릭하는 동안 마우스가 1픽셀 이상 움직일 때까지 마우스가 있는 - 기호가 손으로 바뀌지 않도록 하는 것이다.블랙밤추 (토크)20:35, 2014년 1월 7일 (UTC)[응답]

마우스 오른쪽 버튼 클릭은 항상 브라우저 및 기타 응용프로그램 컨텍스트 메뉴에 예약되어 있으며, 이를 지원하지 않거나 지원할 수 없는 메뉴는 물론 접근성도 언급하지 않았다.마우스 오른쪽 버튼 클릭 기능을 무시하면 기존의 브라우저 기능이 모두 깨지므로 제안 문제를 능가하는 것은 결코 아니다.거의 모든 현대의 브라우저는 표준화된 제어장치로 위의 모든 동작을 지원한다.— HELLKOWNZ ▎TOK 23:17, 2014년 1월 7일 (UTC)[응답]

파일 위를 맴도는 게 이런 모양이라고 제안하는 겁니다

이미지 주위에 가장자리가 없어 팝업 창처럼 보인다.블랙밤추 (토크) 02:38, 2014년 1월 8일 (UTC)[응답]

솔직히, 마우스 클릭에 모든 기능을 추가하자는 당신의 제안은 "거추운 두 번의 클릭"이라는 문구에 의해 캡슐화되었듯이 문제를 찾는 해결책처럼 들린다.그리고 내가 정확히 읽고 있는 것은 당신이 이미지 위를 맴돌면 그것이 튀어나온다고 제안하는 것인가?나는 솔직히 이런 일이 절대 실행되지 않기를 바란다.그나저나, 그 제안들은 좀 진정해.위키피디아를 개선할 수 있는 훨씬 더 생산적이고 효율적인 방법이 있는데, 이는 지역사회에서 설득력을 얻지 못하는 것 같은 많은 제안서를 쓰는 것보다 더 많은 것이다.:) -잘 ^Talk 쉰 06:59, 2014년 1월 8일 (UTC)[응답]

아마도 더 좋은 해결책은 마우스 오른쪽 버튼을 누르면 설명 페이지 대신 이미지를 직접 보여주는 페이지로 바로 이동하여 마우스 오른쪽 버튼을 한 번 클릭하면 왼쪽 클릭과 동일한 기능을 두 번 수행하는 것이다.그래야 뒷 단추도 한 번만 누르면 된다.블랙밤추 (토크) 14:54, 2014년 1월 8일 (UTC)[응답]

훨씬 더 좋은 해결책은 파일에 대한 링크가 하이퍼링크 제목 파일을 포함하는 것이다.블랙밤추 (토크) 15:10, 2014년 1월 8일 (UTC)[응답]

아마도 가장 좋은 해결책은 위키백과 기사의 이미지들이 다음과 같이 보이는 것일 것이다.

(파일) 줄리아 집합의 한 유형

블랙밤추 (토크) 2014년 1월 9일 (UTC) 16:39, 응답

전체 이미지에 액세스하기 위해 파일 페이지를 로드해야 하는 것(두 번의 클릭 + 페이지 로드)이 문제라는 블랙밤추의 의견에 동의한다.그러나 마우스 오른쪽 버튼을 누르거나 맴도는 것은 잘못된 해결책으로 보인다.이미지를 마우스 왼쪽 단추로 클릭하면 확장된 이미지가 라이트 박스에 표시되어야 하며, 라이트 박스는 현재 웹 상의 이미지의 표준 동작이다. 라이트 박스는 파일 페이지에 대한 링크를 포함해야 하며, 따라서 동작 순서를 거꾸로 하고 빈번한 상호작용을 쉽게 할 수 있다.Javascript가 비활성화된 경우에만 이미지에는 파일 페이지에 대한 직접 링크가 포함되어야 한다.디에고 (토크) 11시 1분 2014년 1월 8일 (UTC)[응답하라]

만약 이것이 물건이라면 옵트인/아웃이 될 수 있을까?왜냐하면 나는 지금 이 사이트에서 이미지들이 행동하는 방식을 개인적으로 즐기기 때문이다. - 보라색 와이즈 (토크) 14:30, 2014년 1월 8일 (UTC)[응답]

이건 벌써 물건 아니야?이는 사용자 기본 설정의 베타 페이지에서 제공되는 미디어 뷰어와 비슷하거나 다소 유사하다.노부스나 16:40, 2014년 1월^talk 8일 (UTC)[응답]

W00t! 지적해줘서 고마워, 베타 선호도를 몰랐어.디에고 (토크) 17:23, 2014년 1월 8일 (UTC)[응답하라]

Welp. XP 자주 가지 않고 베타 파트에 자주 가지 않기 때문에 몰랐다는 게 말이 돼. - 보라색 와이즈 (토크) 04:22, 2014년 1월 9일 (UTC)[응답]

위키백과 기사에서 확인 가능한 모든 정보 허용

정보를 검증할 수 있도록 요구하는 원래 목적은 위키백과 기사에 있는 거의 모든 정보가 사실일 수 있도록 하는 것이 아니라, 거의 모든 정보가 사실일 수 있도록 하는 것이었는데, 그것이 없다면, 어떤 사람들은 사실이라고 생각하지만 사실이 아니라고 생각되는 정보에 추가될 것이기 때문이다.할 수 있는 검증 방법이 출처를 보는 방식과 다르더라도 모든 검증 가능한 정보는 허용해야 한다.예를 들어, 유튜브에 가면 확인할 수 있기 때문에 유튜브가 동영상 시청을 위한 웹사이트라는 정보를 찾을 수 없더라도 삭제하지 않아도 된다.한편, 유투브 상부에 종 기호가 있다고 하는 것은, 서명되지 않은 사람들을 위한 것이 아니기 때문에 그다지 사실이 아니기 때문에, 만약 그러한 사실이 없는 정보가 기사에서 발견된다면, 그 정보를 삭제하는 대신에, 유튜브가 때때로 종 기호를 가지고 있다는 진실한 정보로 대체하는 것이 좋을지도 모른다.맨 위블랙밤추 (토크) 22:56, 2014년 1월 7일 (UTC)[응답]

당신이 제안하는 것은 소스에서 직접 지지하지 않는 결론을 내리는 것이다. 기본적으로 WP:OR은 매우 좋은 이유로 제외된다.— HELLKOWNZ ▎토크 23:12, 2014년 1월 7일 (UTC)[응답]

(갈등 편집) 많은 정보는 검증가능하지만 중요하지는 않을 수 있고, 따라서 자극에 적합하지 않다.예를 들어 나는 흰 머리를 가지고 있다.이것은 내 사진(사용자 페이지)에서 확인할 수 있지만 나는 눈에 띄지 않기 때문에 어떤 글에도 이것을 포함시킬 이유가 없다.설사 내가 눈에 띄었다 하더라도 그것은 아마 사소한 일일 것이다.마찬가지로, 우리는 그러한 정보를 백과사전적으로 고려하지 않기 때문에 일반적으로 확인하기가 쉽지만, 대부분의 사업체의 거리 주소는 포함시키지 않는다.명백하고 도전할 수 없는 정보에 대해서는 하늘이 파랗다고 인용할 필요가 없다.어떤 종류의 검증 가능한 정보를 지금 제외하시겠습니까?DES ^(talk) 23:13, 2014년 1월 7일 (UTC)[응답]

Bing 피드백이 400자로 제한되어 있다는 사실 같은 것은 거의 모든 사람이 쉽게 확인할 수 있으며, 나는 피드백(인터넷 )으로 이름을 바꾼 후 Google 피드백에 포함시키자고 제안했지만, 위키피디아에서는 그러한 유형의 정보가 반대되는 것 같다.삭제/Google 피드백 문서.기사를 쓰기에 충분한 양의 정보를 얻기 위해서는 그러한 방법으로 그 주제에 대한 다른 사실들이 충분히 있을 수 있다.블랙밤추 (토크) 00:51, 2014년 1월 8일 (UTC)[응답]

제3의 출처로서, 우리는 세부사항이 아닌 정보를 요약해야 한다.구글이 자사 서비스에 대한 피드백을 허용하는 것도 중요하지만, 어떤 이유로든 2차 출처에 의해 팩스가 불려지지 않는 한, 당신이 얼마나 많은 문자를 포함시킬 수 있는가는 그렇지 않다.400자 한도를 보고 검증할 수 있다고는 하지만 실제로는 필요한 시점이 아니다.--MASEM (t) 01:02, 2014년 1월 8일 (UTC)[응답]

당신의 사용자 페이지에서 당신의 사진을 보는 것은 당신이 하얀 머리를 가지고 있다는 것을 증명하지 못한다. 왜냐하면 그것은 다른 사람의 사진일 수 있기 때문이다.반면 빙 피드백이 400자로 제한돼 있다는 것을 검증하면 400자로 제한돼 있다는 것을 증명한다.블랙밤추 (토크) 22:41, 2014년 1월 9일 (UTC)[응답]

위키피디아는 무분별한 정보 수집이 아니다.그것이 검증될 수 있다고 해서 그것이 WP를 만난다는 뜻은 아니다.GNG 또는 WP:V.콘베이어벨트 2014년 1월 7일 (UTC) 23:22 [응답]

게다가, "유튜브는 비디오 시청을 위한 웹사이트"와 같은 사실은 믿을 만한 출처들로 쉽게 검증될 가능성이 높다; 출처들이 토론한다는 것은 그것이 사실이라는 증거일 뿐만 아니라, 그 중요성을 보여주는 것이다.bd2412 T 00:07, 2014년 1월 8일 (UTC)[응답]

WP:상식이 바로 당신이 찾고 있는 것이다.WP:Verifyable은 "모든 인용문, 그리고 검증가능성이 도전받았거나 도전받을 가능성이 있는 모든 자료는 그 자료를 직접적으로 지지하는 인라인 인용문을 포함해야 한다"고 말한다.그것은 모든 사실이 언급되어야 한다고 말하지 않는다.Rmhermen (대화) 00:13, 2014년 1월 8일 (UTC)[응답]

WP:검증가능성은 (누구, 시기, 장소 등에 대한 일부 표시와 함께) 명시되었다는 것을 문서화하는 데까지만 해당된다.그러나 정확히 인용된 텍스트가 있다는 것을 우리가 확인할 수 있다고 해서 그 진실성에 대해서는 전혀 알 수 없다.그것이 우리가 WP와 같은 추가 요건을 가지고 있는 이유다.RS, WP:Weight 등그 중 어느 것도 "진실"을 확립하지 못한다.그들 또한 그래서는 안 된다.우리는 남들이 결정한 것만 보고한다.아니면 적어도 그랬다고 했거나. ~ J. Johnson (JJ) (토크) 01:10, 2014년 1월 8일 (UTC)[응답]

블랙밤추, 구글 피드백과 관련하여 제기된 이슈는 검증가능성이 아니라, 불분명하다.—라르고 플라조 (대화) 11:58, 2014년 1월 8일 (UTC)[응답]

기사 소개에 굵은 글씨로 된 기사 제목 없음

대담하게 다루지 않는 이유는 원래 시작했던 방식이 편집자들이 우발적인 실수를 한 것이라고 믿기 때문이다.나는 기사 제목을 대담하게 쓰는 방법이 때때로 누군가가 기사의 본문에 제목을 덧붙였을 때, 사람들이 이미 기사에 올라갔기 때문에 나중에 그것에 연계가 필요 없다는 것을 잊어버리고 [[기사의 이름]]을 써서 실수를 해서 다른 사람들이 실수를 하고 대담하게 생각하게 된 것이라고 믿는다.그것이 정상적으로 작동되어야 하는 방식이었기 때문에 그들은 ''기사의 이름'''을 쓰면서 대담해지는 다른 방법을 썼다.블랙밤추 (토크) 00:30, 2014년 1월 8일 (UTC)[응답]

블랙밤추, 열정은 대단하지만, 제안하는 건수를 줄여줘.그 중 누구도 매력을 얻지 못하는 것 같다. --Floquenbeam (대화) 00:33, 2014년 1월 8일 (UTC)[응답]

나는 여기서 너의 "역사"가 틀렸다고 생각한다.하지만 그것이 옳다고 해도, 처음 언급할 때 주제를 해독하는 것은 이제 위키백과의 표준이고, 그것을 바꾸는 것은 400만개가 넘는 우리의 모든 기사들을 내가 볼 수 있는 특별한 이득으로 바꾸는 것을 수반할 것이다.나 또한 위의 Floquenbeam에 동의한다, 천천히.DES 00:40, 2014년 1월 8일 (UTC)[응답]

+1 → DES : 주제 이름을 굵게 하는 것은 이제 그 기원에 관계없이 표준 관행이 되었다.내 마음속에 있는 질문은 언어-피디아들 중 어느 누구도 다른 길을 가고 이것을 표준적인 관행으로 가지고 있지 않은가 하는 것이다. --사용자:씨요키(말씀) 01:02, 2014년 1월 8일 (UTC)[응답]

기원에 대한 너의 추측이 틀렸다.당시에는 [기사 이름]에 실제로 연결할 수 없었다.위키는 브라켓이 없는 기술적 한계 때문에 CamelCase를 사용했다.제목을 굵은 글씨로 쓰는 것은 아주 일찍부터 하나의 관습이 되었다. 아마도 첫 문장에 제목을 넣는 것과 정확히 같은 순간에 (원래 그렇게 하지 않았기 때문에),CamelCase에서 무료 링크로의 전환에 대해서는 이것을 참조하라. 첫 문장에 제목을 추가하는 것은 여기를 참조하라. 표준 굵은 글씨로 완성하라. (이 예들은 영어 위키백과에서 가장 오래 존속된 기사들 중 하나에서 인용한 것이다.)WhatamIdoing (talk) 05:19, 2014년 1월 8일 (UTC)[응답]

나는 그 변화에 동의하지 않는다.DESiegel의 말대로 변경에 대한 혜택은 없다. --NaBUru38 (토크) 23:28, 2014년 1월 8일 (UTC)[응답]

반대:기사 제목을 대담하게 쓰는 것은 주제가 무엇인지 강조하는 데 도움이 된다.WhisperToMe (토크) 23:46, 2014년 1월 9일 (UTC)[응답]

다른 한 가지: 위키백과 밖에서 몇 가지 예를 살펴봄

나는 다른 백과사전들과 "완벽한" 자료들이 이것을 어떻게 다룰지 궁금해서, 나는 다음과 같이 살펴보았다.

브리태니커 백과사전은 위키백과가 하는 방식으로 대담성을 발휘하는 것처럼 보인다(예: 마모셋).
그러나 군사과학 백과사전은 대담성을 발휘하지 않는다(예: 약물중독)
Story in Stone: 묘지 상징주의와 아이콘그래피에 대한 필드 가이드는 대담성을 발휘하지 않는다(내 책장에 있는 책, 예를 들어 "돌"과 "히비스커스"의 출품)
인쇄 사전은 입력과 페이지 사이에 이분법이 없기 때문에 항상 굵은 글씨로 나타난다. 위키트리노리를 보면, 항목 내의 단어들은 굵은 글씨로 되어 있다(예: wikt:landing).
레닝거의 고전 교과서 생화학에는 단일한 주제인 '트리사카리드'(pg. 263)와 '엑설션-콘트랙션 커플링'(pg. 763)이 꽤 있다; 주제 구절의 대담한 사용은 이 교과서에서는 일어나지 않는다(내 책장에 있는 다른 책)

--User:Ceyockey (Talk to me) 01:02, 2014년 1월 8일 (UTC)[응답]

제안서는 이것을 바꾸는 데 어떤 이점이 있는지 설명하지 않는다.--찰스 (대화) 10:19, 2014년 1월 8일 (UTC)[응답]

그렇다. 글의 대담한 제목을 바꾸면 아무런 이득도 없다.사실, 그러한 변화를 실행하기 위해 400만 개의 기사를 거쳐야 하는 것은 엄청난 시간과 노력의 낭비일 뿐이다.결연한 14:37, 2014년 1월 8일 (UTC)[응답]

프로메테우스(2012년 영화)에서는 어떤 포털이 적합한가?

이 문제에 대한 이전의 논의는 기사토크 페이지에서 이루어지지 않았다.대신에 그들은 이곳에서 일어났다.

프로메테우스(2012년 영화)에서는 어떤 포털이 적합한가?이 영화와 관련된 4가지 의견이 기록보관소에서 발견되어 4가지 제안으로 생각할 수 있다: 5개의 포털, 0개의 포털, 3개의 위키프로젝트에 속하는 관련 포털 수 이하, 5개의 포털(하나의 포털은 첫 번째와 다른 것)이다.

제안서 A: 나는 다음의 포털을 포함시켰다. diff:
2010년대 - 영화가 개봉된 10년
필름 - 필름의 일반 포털(디프에서 실수로 이 포털을 두 번 추가했음)
미국의 영화 - 일부 제작사가 미국 출신이기 때문에
영국 - 다른 제작사가 영국인이기 때문에
SF - 장르

제안 B: 사용자:다크워리어블레이크는 어떤 포털도 적절하지 않다고 주장했고, 내가 추가한 포털을 제거했다.나머지 포털을 제거한 Diff #1, Diff #2 - Prometeus_ (2012_film) 작성 시 포털이 없다.

제안 C: 사용자:베티 로건은 위키피디아_토크에서 다음과 같이 말했다.위키프로젝트_Film/Archive_46#Use_Portals_in_film_articles (Diff) : "필름 포털은 프로메테우스에서 두 번 나열된다!하지만, 나는 다른 프로젝트에 속한 포털이 그들의 범위에 포함되지 않는 기사들에 설치되어서는 안 된다고 생각한다.프로메테우스는 영화, 에일리언, 공상과학 프로젝트에 속해 있기 때문에 기껏해야 그 프로젝트에 속하는 포털만 가지고 있어야 한다."(주: 두 번 열거된 영화 포털은 나의 실수였다)WhisperToMe (talk) 01:51, 2013년 12월 29일 (UTC)[응답]

제안 D: 사용자:니혼죠가 주장(See diff) : "분명히 적어도 한 사람은 그것이 지나치다고 생각했다.나는 그 페이지의 에일리언 바닥글 템플릿에 에일리언 포털을 추가했다.2010년대의 포털이 조금 과했을 수도 있다고 생각하지만, 다른 것들은 괜찮아 보였다.일부 기사에 포털 링크가 여러 개 포함된 것은 드문 일이 아니다.확실히, 미국의 영화, 공상과학 소설 (실제로 투기성 소설 포털의 공상 과학 섹션으로 리디렉션), 그리고 (실제로 존재했어야 하는) 영국의 영화들은 단순히 접선적으로만 연관되어 있지 않다. 다크워리오블레이크가 포털을 없앤다는 것을 암시하듯이 말이다." - "그"는 것은 의미하는 것이다.첫 번째 "제안"에서 언급한 포털 수

그렇다면 이 기사에 적합한 포털은 무엇인가?어떤 제안을 선택해야 하는가?아니면 다른 것을 사용해야 하는가?WhisperToMe (talk) 01:41, 2013년 12월 29일 (UTC)[응답]

포탈이 있다면 무엇이 적절한가.질문을 분명히 유도하려고 한 건 아니란 거 알아.위의 링크에서 지속적인 논의가 진행 중이며, 나는 이 새로운 것이 지지를 위한 유세 및 포럼 쇼핑의 한 예라고 믿는다.글을 쓰면서 프로메테우스는 포탈이 없고, 포탈은 기사의 요건이 아니며, 프로메테우스가 한 GA나 FA 지위에 도달하기 위한 요건이 아니다.우리는 인터위키 링크, 더 구체적이고 직접적으로 관련된 범주, 그리고 내비게이션 템플릿을 가지고 있는데, 이 템플릿은 추가된 포털을 포함한 대부분의 포털을 영화에 대한 링크가 없고, 독자들에게 당면한 주제에 대한 전혀 또는 더 이상의 통찰력을 제공할 수 없다.그러나 지금 3, 4위 위스퍼토미가 이 토론을 열어준 것이 아니라, 그것이 시작된 위의 두 번째 링크에서 토론이 계속되어야 한다.다크워리어블레이크 (대화) 02:03, 2013년 12월 29일 (UTC)[응답]

위키백과를 검토하십시오.유세하다.토론이 어느 한쪽으로 특별히 설정되지 않는 한("일반적으로, 보다 완전하게 합의를 달성하도록 참여 범위를 넓혀 토론의 질을 개선하려는 의도로 이루어진다면, 진행 중인 토론에 대해 다른 편집자에게 통지하는 것이 전적으로 허용된다."(엠파)sis mine)).이 경우 "부적절한 통지"라는 제목 아래에 있는 내용은?또한 위키프로젝트 필름의 관할 구역에 어떤 기사도 포털을 갖지 않아야 한다거나 위키프로젝트 필름이 포털의 사용을 완전히 통제해야 한다고 말할 수 있는 권한을 가져야 하는가도 평행하게 논의되고 있다.영화, 위키프로젝트 멤버들의 말에 기사로 금지 (멤버마다 생각이 다른 것 같다)WhisperToMe (토크) 02:10, 2013년 12월 29일 (UTC)[응답]

그런데 블레이크, 내가 한 일은 한 제안이 0 포털을 요구한다는 것을 분명히 한 거야.WhisperToMe (토크) 04:05, 2013년 12월 29일 (UTC)[응답]

또한 나는 "있는 경우"를 추가하기 위해 이 제안과 유도 질문의 제목을 변경했고, 0이 이 기사에 대한 선택사항임을 분명히 했다.WhisperToMe (토크) 04:40, 2013년 12월 29일 (UTC)[응답]

포털 스팸에 대해 이야기하십시오.가장 관련성이 높은 포털인 Films and Science Fictures에 계속 접속하십시오.그 이상은 과도할 것이다.미국에서 필름을 추가할 경우 필름 링크를 제거하십시오.10년 포털에 대한 링크는 기사 자체가 10년 정도가 아니면 절대 기사에 들어가서는 안 된다.(영화에서 2010년을 제외) 24.149.119.20 (토크) 12:12, 2013년 12.149.119.20 (토크)

설명:솔직히 나는 "미국에 영화"가 있을 것이기 때문에 필름을 생략해도 괜찮아.그러나 대중문화 상품과 시사회는 수십 년과 연관되어 있다는 것을 명심하라.결국 비비스나 버트헤드는 1990년대와 관련이 있다.썬더캣(1985년 TV 시리즈)은 1980년대와 관련이 있다.수십 년에서 10 년으로 포털을 제한하는 것은 특정 10 년 동안 제작된 특정 쇼/영화/등과 그 10 년을 연관시키는 "데케이드 향수"에 대한 대중의 인식과 일치하지 않을 것이다.일부 기사는 단순히 여러 주제와 여러 장르와 연관되어 있다는 것을 기억하라.나는 위키프로젝트 수에 비해 포털 세트가 최대한 응축되어야 한다는 것에 동의한다.대화 비교:제2차 세계 대전에서 제2차 세계 대전으로_전쟁으로_II#2차 세계대전을 위해 특별히 전용 포털이 만들어졌으므로 참조.포털이 더 구체적으로 만들어질수록 각 기사에 필요한 포털의 수가 줄어들고 각 기사의 관련성이 더 높아진다.또한 엄밀히 말하면 미국영화가 아니라 공동제작이기 때문에 영국을 추가했다.어떤 주제들은 다른 주제들보다 더 복잡하다.하지만 포털을 시작하게 되어 기쁘다.영국에서 그 이슈를 축소하기 위해 필름 작업을 한다.WhisperToMe (talk) 19:58, 2013년 12월 30일 (UTC)[응답]

포털에 포함할 내용에 대한 나의 일반적인 진술은 "만약 그 기사가 포털에서 '선정된 기사'로 사용되는 것이 타당하다면, 그 글에서 그 포털로 연결되는 것이 타당하다"이다.Portal(포털)에 입력된 정보로 사용할 수 있을 것 같다.에일리언, 하지만 이 영화는 에일리언의 모국 포털인 포탈에 포함되도록 선정될 만큼 충분히 주목할 만한 것은 아닐 것이다.추측성 소설 및 포털:공포 소설.나는 또한 이 영화가 포털에서 통할 것이라고 생각한다.미국에서는 영화, 그러나 다시 말하지만, 부모 포털인 포탈에 포함되도록 선정될 만큼 충분히 주목할 만한 것은 아니다.필름이지. 10년의 포털에 포함시키진 않을 거야. 비록 지금은 그런 것들이 다소 정의가 약하지만 말이야.스벤망구아르화 ?2013년 12월 30일(UTC) 22:23[응답]
- 내가 직접 10년 포탈을 만들었지만 그 아이디어는 프랑스어 위키피디아에서 나온 것이다.그 10년 후의 10년 뒤의 개념은 10년 안에 문화와 사건이 어떻게 흘러가는가에 대한 대중의 인식과 그 10년 안에 찾아오는 '십년 향수'에 부합하는 것이라고 생각한다.10년 후의 영화/노벨/텔레비전 쇼는 그 10년의 "상품"으로 볼 수 있기 때문에 나는 그 10년의 포털의 "선정된 기사"로 볼 수 있다.WhisperToMe (talk) 00:07, 2013년 12월 31일 (UTC)[응답]
  - 여기에 더 이상의 언급이 없다면, 7일 이내에 나는 이 기사를 위해 영국에서 필름을 위한 포탈을 작성하게 되어 기쁘지만 미국 포털과 에일리언만 다시 설립하고 싶다.또한 위키백과 커뮤니티가 왜 널리 사용되어야 한다고 생각하는지 이해할 수 있도록 10년 포탈의 중요성을 설명하고 싶다.WhisperToMe (토크) 12:53, 2014년 1월 3일 (UTC)[응답]

아니, 아니, 아니, 아니! 당신은 당신이 원하는 방식으로 이것을 끝내기로 결정하지 않는다. 물론 사람들을 지치게 한 후 무언의 합의를 이끌어내지는 않는다.그것을 자발적인 편집자(관리자)에게 맡겨 종결 결정을 내리고 합의사항이 무엇인지 결정한다. - SchroCat (대화) 19:48, 2014년 1월 10일 (UTC)[응답]

있잖아, 슈로캣, 어제 토크에 가봐야겠다고 생각했어.바람과 함께 사라져서 그 페이지에 포털 링크 하나를 포함하자는 제안에 대해 내 의견을 말해봐라...그리고 당신의 말다툼으로 가득 차서 나는 의견을 형성하기 위해 기사를 보는 것조차 귀찮게 하지 않기로 했다.만약 당신이 RFC의 다른 사람들의 의견을 듣고 싶다면, 나는 당신이 당신 자신의 견해를 다시 게시하는 것을 그만두도록 격려하겠다.사실, 나는 그 무의미한 논쟁은 모두 백지화하거나 모자가 될 것을 제안하고 싶다. 그리고 당신과 WhisperToMe 둘 다 RFC에 대해 당분간 한마디도 하지 않기로 결심해야 한다.만약 이것이 RFC에서 WTM에게 했던 조언과 이상할 정도로 유사하게 들린다면, 나는 당신에게 거위를 위한 소스는 Gander를 위한 소스라고 제안할 것이다.WhatamIdoing (대화) 19:59, 2014년 1월 10일 (UTC)[응답]

WhatamIdoing, 나는 당신이 누구인지, 또는 당신이 이것에 대해 얼마나 아는지는 모르지만(위의 당신의 코멘트로 볼 때, 별로 아는 것이 없다), 내가 나의 두 기사 토크 페이지와 나 자신의 페이지에 있는 텍스트의 벽을 포함하여, WTM과 관련된 세 가지 토론에서 벗어났다는 것을 고려하면 (두 번째:나는 토론을 끝내기 위해 그들 둘 다 기록해야 했다), 그렇다면 내가 도발적이고 불규칙적인 조치를 취하는 것을 막으려 할 때 아마도 너는 조금 덜 판단적일 수 있을 것이다.게다가, 다음번에는, 아마도 당신은 또한 당신의 사실을 바로잡을 수 있을 것이다.나는 <바람과 함께 사라지다>(RfC였기 때문에, 토론이었을 때만), 이 페이지의 프로메테우스 실(이것은 나의 두 번째일 뿐), 이 페이지의 GwtW 실(GwtW 실)에 대한 코멘트는 한 개도 하지 ~~않았다~~.WTM이 간신히 해냈을 정도로 판단력과 나를 더 화나게 해줘서 고마워. - SchroCat (대화) 20:16, 2014년 1월 10일 (UTC)[응답]

만약 당신이 어떤 종류의 "주요"가 필요하다면, 당신은 이 두 링크가 유용한 것을 발견할 것이다: [8][9].나는 이런 "마이 위키프로젝트 WP:이 특정 RFC로 이어지는 몇 가지 논의를 포함하여 해당 기사를 소유하십시오.

즉석 "토론"에 대해서는, 그 실에서 6개의 논평을 냈는데, 그 대부분이 기본적으로 무관한(다른 어떤 다른, 무관한 영화도 있을 수 있는데, 미국 시나리오 작가, 미국 프로듀서, 미국 배급사, 그리고 7개의 미국 아카데미 상이 있다면, 어떤 식으로든 "미국인" 영화라고 여겨질 수 있다.기술적으로 영국 법인을 제작에 이용했다) 또는 도움이 되지 않는다(예: WTM이 "전혀 요점을 놓치고 있다"는 비난과 다른 사람의 의견을 요청하여 "무시"한다는 비난).이 토론이 원래 다른 방법으로 광고되었기 때문에 RFC 태그가 추가되기 전이나 후에 게시되었는지 여부는 관련이 없다.

그리고 관련 사항: 특정 기사에 링크를 추가할지 여부(모든 링크)는 해당 기사에 있는 편집자들이 사례별로 결정하는 것이 가장 좋으며, 매우 일반적으로 말해서 이러한 유형의 링크가 보통 좋은 아이디어인지에 대한 일반적인 논의에서는 아니다.그 기사에서 이 링크를 연결하거나 연결하지 않기로 한 결정은 그 기사에서 일하는 사람들에 의해 모든 사실과 상황을 고려한 후에 저쪽에서 이루어져야 한다.그 토크 페이지 토론은 링크에 대한 정책을 만들려고 하는 것이 아니다.그것은 한 가지 특정 기사에서 한 가지 연결고리에 대한 의견을 표현하기 위해 (즉, 두 분 모두) 자유롭지 못한 사람들이 노력하도록 하는 것이다.WhatamIdoing (대화) 22:41, 2014년 1월 10일 (UTC)[응답]

나는 네가 자격증에 대해 자랑하고 있는 것이 무엇에 대한 것인지, 왜 이것에 대해 나팔을 불어야 할 필요성을 느끼는지 잘 모르겠다.쓸 만한 말이 있으면 다른 편집자들을 화나게 하지 말고 어서 가서 말하라.(기록상으로는 나는 어떤 프로젝트의 일원이 아니다-본드에 살짝 고개를 끄덕이는 것이 가장 가깝지만 다른 것은 없다.)당신의 두 번째 요점은 도움이 안 되고, 불필요하고, 오프 토픽이다. (나에게 초점을 맞추려 하지 않지만, RfC의 제안자가 그들에게 응답하지 않는 사람들에 의해서만 토의를 종결시킬 수 있는 사람이 되어야 하는지에 대해 내가 만든 시점에서.만약 당신이 그것에 문제가 없다면, 내가 처음 생각했던 것보다 당신의 판단에 더 많은 우려가 있다.셋째로, 나는 그러한 논의가 어떻게 어디서 일어나야 하는지를 잘 알고 있다. 나는 당신이 나를 "인볼루션"이라고 부르는 것에 약간 어리둥절하다.나는 그 기사를 3번만 수정했고 그 한 줄기에 대해서만 논평했다.아마도 당신은 다음에 누군가와 대화하고 싶을 때 당신의 태도를 살피고 그렇게 판단적이고 아첨하는 것을 그만둘 수 있을 것이다.아마도 당신은 또한 이것에 대한 나의 역할이 무엇인지에 대한 몇 가지 기본적인 요점을 올바르게 얻을 수 있을 것이다(나는 이미 WTM에서 해제했다고 설명했고, 당신이 앞으로 나와의 대응에서 해제할 것을 강력히 제안한다).펌프 소유로 돌아가 누가 언제 어디서 상호작용을 할 수 있는지 지시하도록 하겠다. - 슈로캣 (대화) 23:15, 2014년 1월 10일 (UTC)[응답]

0바이트 길이 변경과 비교하여 감시 목록의 기사가 변경되지 않을 때 명확히 표시

그 감시목록은 현재 충분히 똑똑해서 보여줄 수 있다.(10 changes history) . . (+505)여러 변경사항이 있을 때(diff hist) . . (-2)‎하나밖에 없을 때하지만, 만약 당신이 그것을 가지고 있을 때.(4 changes history) . . (0)편집한 다음 원본을 되돌리는 것인지, 기사 길이를 변경하지 않은 진짜 변경인지(즉, 1980년에서 1940년으로 생년월일을 변경하거나 존에서 빌 등으로 이름을 변경하는 것인지 알 수 없다.그런 다음 디프프티 체크나 팝업/호버를 통해 실제로 무엇이 변경되었는지 확인하십시오.워치리스트가 이런 걸 더 똑똑하게 보여줄 수 있을까?(4 edits, no net change history) . . (0)언제 현재 버전이 원본과 정확히 같을 때?그렇게 되면 어떤 기사 변경을 안전하게 무시할 수 있는지 매우 분명해질 것이다.The-Pope (대화) 14:21, 2014년 1월 4일 (UTC)[응답]

내 감시원은 이런 일을 하지 않는다.어떤 기기를 실행하십니까?WhatamIdoing (대화) 15:52, 2014년 1월 4일 (UTC)[응답]

Special:에서 "최근 변경사항 및 감시 목록의 페이지별 변경사항"을 활성화하십시오.Preferences#mw-prefection-rc 및 Special에서 "최신 변경사항뿐만 아니라 모든 변경사항을 표시하도록 감시 목록 확장":기본 설정#mw-prefection-watchlist.프라임헌터 (토크) 2014년 1월 4일 (UTC) 16:24 [응답]

나는 이것이 정말 유용한 기능이 될 것이라는 것에 동의한다.왜냐하면 기사가 길어지든 짧아지든 상관하지 않기 때문이다.나는 그것이 얼마나 많이 변하는지 정말로 신경쓴다.현재 버전과 내가 마지막으로 본 버전 사이에 얼마나 많은 바이트가 다른지(또는 가장 적은 바이트 수 중에서, 삽입/삭제를 설명해야 하기 때문에)의 측도는 내가 원하는 것에 훨씬 더 가까울 것이다.(아직도 나를 완벽하게 만족시키지는 못하겠지만, 예를 들어 문장의 의미를 부정하는 단어는 mo가 될 수도 있다.기존 2개 하위섹션의 순서를 바꾸는 것보다 더 중요해.내가 진정으로 원하는 것은 두 개의 DNA 시퀀스 사이의 분자 클럭 전달 시간 차이를 계산하는 데 사용되는 알고리즘에 더 가깝고, 점 교정은 물론 대규모 돌연변이도 고려하며, 이 알고리즘은 두 버전을 연결하는 최소 또는 "최대의 파르시모닉" 가능한 역사를 찾는 것을 포함한다.)

분명히, 이것은 우리가 현재 가지고 있는 것보다 계산적으로 훨씬 더 비싸다. (단순히 페이지 길이를 비교하는 것은 절대적으로 사소한 것이기 때문이다.)나는 그것이 엄청나게 어려울지 확실하지 않다.세슘프로그(대화) 23:10, 2014년 1월 4일 (UTC)[응답]

워치리스트가 기사나 카테고리를 "소유"하는 데 도움이 되지 않도록 하기 위해 워치리스트를 보다 효율적으로 만드는 것이 반드시 좋은 일은 아니다.유료 편집자 외에도, 그 누구도 그들이 돕기 위해 추가적인 기능이 필요할 정도로 많은 페이지 감시 목록을 가지고 있어서는 안 된다.이상적으로는 어차피 몇 달 안에 페이지가 자동으로 워치리스트를 내려놓는 것이 좋다. - 포인트리스트(대화) 23:44, 2014년 1월 4일(UTC)[응답]

그것은 정말 이상한 주장이다.지금 나는 17,171페이지의 내 감시 목록을 가지고 있다.관리자가 광범위한 기사에 최소한 피상적인 주의를 기울이는 것이 왜 문제라고 생각하는가?—Kww(대화) 23:55, 2014년 1월 4일 (UTC)[응답]

지난 7년간 19,858개의 고유 페이지를 편집했는데도 86%를 여전히 보고 있다는 것이 꼭 좋은 것만은 아니다(관리자가 되는 것이 어떻게 관련이 있는지 모르겠다)."누구나 편집할 수 있다"는 전체적인 생각은 개별 기고자들이 기사 내용을 통제하지 못하기 때문에 주제가 눈에 띄지 않아 지속적으로 검토하는 안목이 많으면 결국 '단서봇' 등이 쉽게 감지할 수 없는 방식으로 파기된다는 것이다.젊은이들이 아빠의 위키피디아를 유지하기를 원하지 않는다면, 해결책은 단지 은퇴한 미성년 선수들에 관한 기사들에 엽총을 더 효율적으로 타는 노령화된 스포츠 광신자들을 돕기 위해 새로운 감시 목록 기능을 구축하는 것이 아니다, 그렇지 않은가? - 포인틸리스트 (토크) 01:14, 2014년 1월 5일 (UTC)[응답]

정말 기괴한 광경이군.단서 봇과 편집 필터가 항상 미묘한 변화를 포착하는 것은 아니다.기성 편집자들이 커다란 감시 목록을 가지고 있지 않다면, 기사들을 "심각하게" 할 것인지 아니면 아버지의 은퇴한 미성년 운동선수들을 "심각하게" 할 것인지, 아니면 그들 중 많은 사람들이 아직 살아있는지, WP:BLP는 자신의 것을 능가한다.우리가 워치리스트를 더 효과적으로 만들기 위해 할 수 있는 일은 무엇이든지 좋은 일일 것이다.아니면 이 제안을 N스포츠에 대한 비판으로 몰고 가려는 것인가?The-Pope (대화) 01:47, 2014년 1월 5일 (UTC)[응답하라]

기사의 반달리즘을 되돌리고 포맷 수정을 소유하지 않고 하는 것도 가능하다.사람들은 또한 이 페이지를 몇 달 이상 보고 싶어할 것이다.GoingBatty (토크) 01:55, 2014년 1월 5일 (UTC)[응답]

대규모 감시단에는 여러 가지 타당한 이유가 있다.소유권 문제로 보는 것은 매우 이상하다.많은 사용자가 Special:에서 "Add page and add I addit I an at my watchlist"를 사용 가능으로 설정했다.기본 설정#mw-prefection-watchlist.그것은 당신이 오래된 항목들을 제거하는데 시간을 보내지 않는다면 엄청난 감시 목록을 야기시킬 수 있다.프라임헌터 (토크) 02:50, 2014년 1월 5일 (UTC)[응답]

반달파이터들이 서버 캣츠와 프라임에게 미치는 영향을 제외하고는 많은 페이지를 추적하는 데 문제가 없다고 본다.헌터의 체크섬 제안은 통계, 기후표 등에서 데이터 파괴 행위를 탐지하는 좋은 방법이 될 것이다.기고자들은 항상 그들의 내용을 감시하고 싶어하는데, 내가 생각하기에 그들은 반드시 추가적인 기능을 제공함으로써 도움을 받아서는 안 된다.스포츠맨이나 다른 "임시 연예인"의 취재에 대해서도 반대하지 않는다. 다만 다음 세대의 편집자들이 이 기사들을 유지하는데 관심을 가질 것 같지 않다는 점을 제외하면 말이다. - 포인틸리스트 (토크) 13:19, 2014년 1월 5일 (UTC)[응답]

정답.아주 기괴하다.만약 당신이 일반 반달 투사이고, 당신이 친숙하고 편안한 주제를 다루는 기사들을 구체적으로 다루고 싶다면, 당신은 불가피하게 큰 감시 목록을 갖게 될 것이다.내 워치리스트는 "절대 안 된다"는 기사의 시계를 가지고 있다.나에게 꼭 큰 관심사는 아니지만 어쨌든 내가 도와준 다른 사람들을 위해, 나는 원래 그것에 관심을 끌었던 반달리즘(또는 그 무엇이든)이 계속되면 그들을 감시자 명단에서 주기적으로 삭제하는 경향이 있지만, 나에게 관심 있는 수백 개의 기사들은 항상 그 위에 있다.위키피디아에는 그런 감시가 필요한 기사가 수십만 개 있다.그것은 소유권이 아니다. 위키피디아에 중요한 기사나 나 또는 다른 경계하는 편집자에게 특별한 관심을 갖는 기사들을 처리하는 것이다.GenQuest 04:20, 2014년 1월 5일 (UTC)[응답]

나는 개인적으로 내 감시 목록을 1,000페이지 이하로 유지하려고 노력한다. 나는 0바이트 변경은 null 바이트 변경과 다르다는 것에 동의한다.개발자들이 이것에 대해 할 수 있는 일이 있는지 리드 소프트웨어 설계자에게 물어보고, 가능하다면 내가 직접 부질라 티켓을 기꺼이 넣도록 하자.기술 13 (대화) 04:40, 2014년 1월 5일 (UTC)[응답]

나는 종종 현재의 개정뿐만 아니라 동일한 수정사항을 표시하는 페이지 기록 기능을 놓쳤다.만약 각 개정안에 대해 해시 값을 저장했다면, 그것은 저렴해야 한다.프라임헌터 (대화) 04:52, 2014년 1월 5일 (UTC)[응답]

이 작업이 가능한지 여부에 대해 Lead Software Architect 또는 Devs로부터 피드백을 받으셨습니까?The-Pope (대화) 09:12, 2014년 1월 9일 (UTC)[응답]

나는 브리온이나 다른 핵심 개발자들(AKlapper (WMF)—Steven (WMF)—WMF (Whatamidoing)—Anomie—Magnus Manske)로부터 들은 바가 없다.조금 더 ping을 해봤는데(Briion이 알림 기능이 없거나 별로 없는 것 같아)기술 13 (대화) 15:52, 2014년 1월 9일 (UTC)[응답]

나는 핵심 개발자가 아니다. :) --AKlapper (WMF) (토크) 04:32, 2014년 1월 10일 (UTC)[응답]

원칙적으로 diff에 기초한 일종의 '변경된 문자 수'가 절약 시간에 생성되도록 소프트웨어를 변경할 수 있다.(표시되는 즉시 계산하는 것은 너무 비쌀 것이다; 현재의 '변경 크기'는 절약 시간에 기록되는 새로운 텍스트 크기(바이트)에서 구 텍스트 크기를 빼는 것만으로 계산된다.)하지만, 사람들에게 높은 우선순위인지는 잘 모르겠고, 좋은 대체 측정 기준을 찾는 것이 자전거 타기 악몽일 수도 있다. :) --briion (대화) 19:28, 2014년 1월 9일 (UTC)[응답]

포털 추가 제안:미국의 영화 바람과 함께 사라지다(영화)

에 토론이 있다: Talk:Gone_with_the_Wind_(필름)#Is_Portal:Film_in_the_United_States_tangential_to_to_to_to_to.3층.

기사 토크 페이지에서 의견을 제시하십시오.

포털의 추가를 제안하고자 함:미국의 영화.이 포털을 fr:의 적응으로 만들었어.포트레일:시네마 아메리카인.

일부 편집자는 이 포털을 믿는다(포탈:미국의 영화)는 개별 영화에 관한 기사와 접선되며 일반/전반적인 주제에만 관련되므로 이 포털은 포함되지 않아야 한다.나는 이 영화가 믿을만한 출처들에 의해 미국 영화의 가장 좋은 예들 중 하나로 인식되어 왔으며 따라서 이 포탈은 관련성이 있고 접선적이지 않다고 주장한다.이번 토론에서 편집자가 한정되어 있었기 때문에 RFC로서 이것을 내세우고 있다.기사토크 페이지에서 토론이 이루어질 수 있다.

여기에 몇 가지 관련 논의가 있다: 위키백과_토크:위키프로젝트_필름#크로스_위키프로젝트_관계_and_decisions_about_portals WhisperToMe (토크) 23:10, 2014년 1월 9일 (UTC)[응답]

반대한다. 그들의 POV에 찬성하지 않는 의견 일치를 듣고 싶지 않은 편집자에 의해 제안이 이루어졌다.돈이야고 (대화) 01:26, 2014년 1월 10일 (UTC)[응답]

논평: 도니아고는 위키프로젝트 필름의 회원들 사이에서 포털에 대한 일반적인 반대를 언급하고 있다.나는 여기서 그 문제에 대한 안내를 받았다: 위키백과_토크:위키프로젝트_협의회#Do.2FShould_위키프로젝트s_have_have_power_over_how_the_portals_in_their_scope_are_used.3F

사용자가 나에게 위키피디아를 가리켰다.조언_pages#Avidice_pages(Wipedia 가이드라인).그것은 일반적으로 지침이기 때문에 따라야 하지만 예외와 상식을 허용한다.어쨌든, 내가 이 프로젝트에 대해 알리자, 한 영화 프로젝트 멤버는 위키프로젝트가 위키프로젝트 페이지에서 결정을 내릴 수 있어야 한다고 주장했다.이에 대해 지침을 준 사용자는 위키프로젝트 페이지에서 결정을 내릴 수 있지만 위키프로젝트의 구성원만 관여할 수는 없다고 말했다.조언 페이지에는 다음과 같이 명시되어 있다.

그는 "그러나 일부 프로젝트에서 관심 있는 모든 기사에는 비판 섹션이 포함되거나 인포박스가 포함되지 않아야 하며, 기사 편집자들은 전문가 내 '합의' 때문에 이에 대해 발언권을 얻지 못한다고 주장하는 등 프로젝트 범위 내 기사 소유권을 주장하는 수단으로 이 페이지를 잘못 사용해 왔다"고 덧붙였다.프로젝트의 몇몇 구성원에 의해 쓰여진 조언 페이지는 어떤 개별 편집자에 의해 쓰여진 조언 페이지보다 더 이상 편집자에게 구속력이 없다.WP를 통해 지역사회가 공식적으로 승인하지 않은 모든 조언 페이지:프로포즈 프로세스는 선택 사항인 {{essay}}}의 실제 상태를 가지고 있다.(관련 부분을 굵게 표시)

내 인상은 회원들이 특정 기사의 주요 기고자들이 그들의 기사에 포털을 원하지 않는다면 포털은 배제되어야 한다고 믿는 것이다.나는 다음과 같은 정서를 들었다.

한 명의 사용자:포털을 전혀 믿지 않으며, 왜 포털이 프로메테우스(2012년 영화)에서 모든 포털을 제거하기 위한 근거로서 포함되어서는 안 되는가에 대한 일반성에 대해 논증한다.그는 이러한 포털의 연결을 "포털 남용"이라고 언급했고, 불필요하고 접선적으로 관련이 있다고 말하는 모든 포털을 제거했다. 나는 이것에 대해 또 다른 마을 펌프 제안 RFC를 시작했다.위키백과:빌리지_펌프_(제안)#what_portals.2C_if_any.2C_are_적정_at_Prometeus_282012_film.29.3F. 원래 토론에 참여하지 않은 편집자들은 처음에 내가 포함시킨 숫자가 너무 많다고 주장했지만, 소수의 포털을 포함하자고 제안했다.
다른 사용자는 포털을 다음과 같이 제안하였다.미국의 영화는 기사당 세 명의 편집자가 포털을 포함하는데 동의할 경우에만 기사에 추가되어야 한다.
또 다른 이용자는 위키프로젝트 필름 사용자들이 포털의 다음 사항을 결정할 권리를 가져야 한다고 주장했다.필름을 사용하고 있으며, WikiProject Film과 Wiki Project 미국은 Portal:미국에서 필름을 사용한다.같은 사용자: "포털은 기사의 요구사항이 아니며, 만약 그들이 반대한다면, 그들은 반대한다."같은 이용자는 "사실상 포함에 반대되는 지적들이 제기됐음에도 불구하고 반박점을 올리지 않았음에도 불구하고 포털이 존재하기 때문에 관련성이나 유용성에 관계없이 기사에 추가해야 한다는 주장은 단순하게 요약되는 것 같다"고 물었다.

위와 같은 위키프로젝트의 권한에 대해 언급하고 있는 것을 고려해 볼 때, 이러한 견해는 공식적으로 커뮤니티에 제안되어야 위키프로젝트와 그 범위 내의 포털 간의 관계가 명확해질 수 있다고 생각한다.필자는 프로젝트를 직접 작성하자고 제안했지만, 만약 그것이 이것을 원하지 않는다면, 나는 프로젝트를 위해 작성한 제안서에 이러한 견해를 제시할 것이고, 따라서 지역사회가 결정할 것이다.

요컨대 물질은 더 넓은 공동체가 결정할 일이고, 이것이 최선의 행동 방침이라고 확신한다.어떤 정책이나 가이드라인이 포털이 포함되어야 한다고 말하는 것은 아니지만 실제로는 커뮤니티가 작은 편집자 그룹만이 아니라 어떤 기사가 포털을 갖는지 결정해야 한다.만약 지역사회가 각 정규 기사에 하나의 포털을 추가하는 것을 일관되게 지지한다면, 이것은 사실상 기사가 관련 포털을 가져야 한다는 것을 의미할 것이다.도니아고, 이 특정 기사가 왜 이 포털을 가지고 있으면 안 되는지 설명해줄래? 아니면 이것은 단지 어드바이저 페이지가 말하는 것에 관한 것인가? WhisperToMe (talk) 01:45, 2014년 1월 10일 (UTC)[응답]

나의 이유는 이미 연결된 토론에서 다른 편집자들에 의해 구두로 표현되었다.수많은 편집자들이 동의하지 않았음에도 불구하고 당신이 계속 이것을 밀어붙이기로 선택한 것은, 이 시점에서, 단지 당신이 동료 편집자들과 함께 일하는 것보다 당신 자신의 편집 내용을 전달하는 것에 더 관심이 있다는 내 감정을 강화시키는 것이다.돈이야고 (대화) 02:34, 2014년 1월 10일 (UTC)[응답]

위를 보라: 편집자들은 다른 말을 하고 있고, 다른 사람들이 다른 말을 하는 다른 토론의 실이 있다 .포털을 어떻게 사용해야 하는지에 대한 위키프로젝트 회원들의 통일된 메시지는 없으며, 포털에 대한 일반적인 혐오만 있을 뿐이다.

그러나 나를 좌절시킨 것은 포털이 어떤 프로젝트에 있어서는 안 된다는 한 사용자의 주장이었고, 프로메테우스(2012년 영화)에 최소한 일부라도 포함시키는 것을 고려하기를 거부해 왔다(2012년 영화) (이것은 내가 페이지에 포털을 너무 많이 추가했다는 그의 믿음과는 구별된다).이러한 주장은 반대되는 것이 아니며, 포털이 필요한지에 대해 토론해야 한다고 주장하는 그의 거듭된 메시지들은 포털이 이용 가능한지에 대한 외부 출처 토론을 포함한 많은 곳에서 나타났으며, 그 중에는 포털이 이용 가능한지에 대한 외부 토론도 포함되어 있다.hat 범주는 다음과 같이 말하지 않는다.Wikipedia_talk:WikiProject_Portals/Archive_2#질문_need_of_portals_when_categories_존재

포털에 대한 이러한 일반적인 믿음의 사용은 특정 기사에 포털의 배치를 방해하기 위해 나를 매우 좌절시켰고, 나는 최후통첩이 필요하다는 결론을 내렸으며, 따라서 그가 그것을 고집한다면 어떤 포털도 없다는 그의 구체적인 관점에 대한 마을 펌프 제안이 필요하다.나는 이 사용자가 포털이 필요하지 않다는 그의 믿음에서 기사의 포털 배치를 계속 방해해야 하는지를 해결하기 위해 제안할 것을 주장해왔다.따라서 그의 제안은 성공(포털은 폐지)되거나 실패(포털은 남아 있고, 기사별로 논하는 것)할 것이며, 대신 그는 자신이 의도하는 대로 특정 기사에서 특정 포탈의 장점을 논의해야 할 것이다.

도니아고, 위키백과:조언_pages#Avidice_pages는 사용자가 Wiki Project 구성원과 의견이 다를 경우 더 넓은 커뮤니티로 이동하도록 권장한다.이 "수많은 편집자"들은 모두 같은 위키프로젝트에서 왔다.위키프로젝트의 수많은 편집자들이 A를 주장하고 한 사람이 B를 주장할 경우, 사용자는 이 가이드라인에서 "A"가 위키백과의 상태를 가지고 있다는 것을 알게 된다.더 넓은 지역사회가 그것을 승인하지 않는 한 에세이를 쓰세요.또한 위키프로젝트 위원회에서 받은 메시지도 고려하십시오.Wikipedia_talk:위키프로젝트_협의회#Do.2FShould_위키프로젝트s_have_have_power_over_how_the_portals_in_their_scope_are_used.3FWhisperToMe (토크) 02:42, 2014년 1월 10일 (UTC)[응답]

이미 생각해 봤어, 고마워.돈이야고 (대화) 03:04, 2014년 1월 10일 (UTC)[응답]

천만에요.가이드라인에 다음과 같이 나와 있는 내용을 이해했으므로:만약 내가 많은 기사에 영향을 미치는 그러한 제안을 한다면(이 제안은 하나의 기사에 대해 하나의 포털에 대해 이야기하고 많은 기사에 대한 넓은 제안은 아니라는 것을 기억하라) 일어날 수 있는 일은 더 넓은 지역사회가 위키프로젝트 필름의 관련 포털의 사용을 제한하도록 승인하거나 허용할 수 있다는 것이다. 이는 위키프로젝트 필름의 관행이 위키피디아를 만족시킬 수 있다는 것을 의미한다.조언_pages#Avidice_pages.이 문제를 해결하는 것은 조언_페이지가 권장하는 것이다.WhisperToMe (talk) 03:23, 2014년 1월 10일 (UTC)[응답]

코멘트 나는 왜 여기서 "바람과 함께 사라지다" 기사에 포털을 추가하자는 제안이 있는지 잘 이해가 가지 않는다.페이지 맨 위에 있는 서론을 지금 두 번 읽었는데 아직도 이 게시판이 뭘 위한 건지 잘 모르겠지만, '바람과 함께 사라지다'에 대해 논의하기 위한 건 아닐 거야.GWTW에 영향을 미치는 RFC가 있을 경우 GWT 대화 페이지에 파일을 첨부하고 적절한 방법으로 태그를 부착해야 한다.베티 로건 (대화) 03:25, 2014년 1월 10일 (UTC)[응답]
- 설명:위키백과:Request_for_comment#Publicizing_an_RfC는 RFC가 여러 가지 방법으로 공개될 수 있으며, 그 중 하나가 이 마을 펌프를 사용하고 있다고 기술하고 있다.나는 또한 맨 위에 "논의가 기사토크 페이지에서 이루어질 수 있다"고 언급했었다.만약 내가 다른 방법을 사용해야 한다고 생각한다면 조언해줘.WhisperToMe (토크) 04:09, 2014년 1월 10일 (UTC)[응답]
- 응, RFC 태그를 추가했어야 해서 그렇게 했어.그렇게 해야 한다고 말해줘서 고마워.나는 게시판에 토론을 나열하는 것에 익숙해서 RFC 태그를 사용하지 않았다.나는 계속 진행하다가 뒤늦게 프로메테우스 토론을 위해 RFC 태그를 추가했다.WhisperToMe (토크) 04:18, 2014년 1월 10일 (UTC)[응답]

불행히도, 나는 위스퍼의 의도와 그것에 대해 둘 다 선의로 생각할 수 없다고 생각한다.돈이야고 (대화) 03:45, 2014년 1월 10일 (UTC)[응답]

- - 설명:베티에게 말한 대로 이 보드는 RFC를 사용하는 옵션 중 하나이지만 나는 이것이 더 낫다면 그것을 하는 다른 방법을 듣게 되어 기쁘다.내가 왜 RFC를 했는지 알고 싶어?여기서 논의가 진행되고 있었다.어느 순간 사용자가 토론에서 응답을 멈췄다.나는 더 많은 피드백을 받기 위해 지역사회에 이것을 제안할 수 있는 방법에 대해 물었다.상대방은 대화를 중단하고 "아카이빙과 이동"을 제안했다.나는 내 입장을 설명했고, 다른 사람들은 그들의 입장을 설명했고 나는 당신이 듣고 있는지 확실하지 않다.나는 너에게 WP:DROPTESTick을 추천하고 다음 단계로 넘어가라"고 제안했다.나는 이 문제를 바탕으로 RFC를 하기로 결정했다.WhisperToMe (토크) 04:09, 2014년 1월 10일 (UTC)[응답]

그래, 나도 알아.이 시점에서 무능력한 편집자들이 끼어들도록 해주시겠습니까?도니아고 (대화) 04:12, 2014년 1월 10일 (UTC)[응답]

기꺼이 그러겠다.WhisperToMe (토크) 04:18, 2014년 1월 10일 (UTC)[응답]

글과 관련 없는 콘텐츠, 포털, 카테고리 등의 추가에 반대한다.사실, 나는 포털 AND 카테고리가 동일한 영역을 커버할 수 있고 연결된 기사에 동일한 정보를 제공할 수 있기 때문에 기사에 AND 카테고리를 두는 데 이점이 거의 없다고 본다.IMO는 지난 몇 년간 주요 정보 박스, 마이너 인포 박스, 템플릿, 포털, 카테고리, 긴 "See Annothers" 목록, 외부 링크 등으로 인해 많은 기사들이 막히고 있다.여기서 잠시 편집한 사람이라면 누구나 이것이 사실임을 알고 있다.나를 배제론자라고 부르지만, 때로는 충분할 때도 있다.GenQuest 06:12, 2014년 1월 10일 (UTC)[응답]
반대 이러한 일반적인 포털은 시간 낭비일 뿐 기사에 가치를 추가하지 않는다.이 태그들은 모두 토크 페이지에서 찾을 수 있으며, 나는 "영화 포털"이나 "1980년대 포털"에 대한 링크를 가지고 있는 기사에서는 아무런 가치도 볼 수 없다.다른 형식의 스팸.러그넛 08:41, 2014년 1월 10일 (UTC)[응답하라]
위의 모든 좋은 이유와 같이 반대하라.포탈의 포인트를 너무 길게 늘려서 과잉 살상하기도 한다.또한 이것은 WhisperToMe의 포럼 쇼핑인 것 같다고 덧붙이겠다. 기사 토크 페이지나 영화 프로젝트, 심지어 나의 토크 페이지에서도 그는 그 문제를 계속 때려부수기로 결정했다.우리는 WP로 더 나아가고 있다.지금 IDHT-ish 영토. - SchroCat (대화) 10:11, 2014년 1월 10일 (UTC)[응답하라]
반대 포털은 "주제적 관련성"이 없다.WhisperToMe는 포털을 범주처럼 취급하고 싶어 하는 것 같지만 범주가 이 일을 잘 하기 때문에 나는 이 접근법에 반대한다.그래, '바람과 함께 사라지다'는 훌륭한 미국 영화지만 기사 자체는 사실 미국 영화의 소재가 아니다.나는 포털이 글의 주제를 독자들에게 알려야 한다는 점에서 모든 내부 위키링크의 원칙을 따라야 한다고 믿는다.예를 들어, 다른 스타트랙 콘텐츠가 기사의 주제를 알려주기 때문에 스타트랙 포털과 같은 것을 스타트랙 기사에 포함시켜도 괜찮을 것이다.바람과 함께 사라지다의 경우 나는 미국 영화산업에 관한 다른 기사들이 독자와 어떻게 연관되어 있는지 모르겠다; 다른 바람과 함께 사라짐 기사는 그러한 목적으로 {{바람과 함께 사라짐}이 있다.나는 포털이 그 자리를 차지하고 있다는 것을 인정하지만 그것들은 현명하게 사용되어야 한다.너무 많은 링크를 가진 독자를 상대하는 것은 그들이 원하는 정보를 찾는데 있어서 역효과를 낼 수 있기 때문에 위키피디아에 있는 다른 자료와 연결하는 것은 집중적이고 목적적합해야 한다.베티 로건 (토크) 2014년 1월 10일 (UTC) 12시 54분 [응답]

여러분, 특히 여러분 중 "무관심"인 분들은 베티가 위에서 제안한 RFC에 여러분의 의견을 올려주시면 정말 좋을 것 같다.RFC의 질문은 특정 기사에 게시되는 특정 포털에 대한 것이지 포털이 일반적으로 스팸인지 시간 낭비인지에 대한 것이 아니라는 점을 기억하십시오.

그리고 만약 당신이 WTM과 며칠 혹은 몇 주 동안 이것에 대해 논쟁을 벌였었다면, 잠시 동안 글을 올리지 않을 것인가, 아니면 정말 기다릴 수 없다면, 가능한 한 가장 친절하고, 가장 대립적인 방법으로 당신의 의견을 올릴 수 있는가?RFC는 보통 한 달 정도 영업한다.만약 우리가 완전히 무관심한 사람들을 볼 수 있다면 좋을 텐데, 여기 영어 위키피디아에서 사람들이 그들에게 소리를 지를 것이라고 생각한다면 그들이 응답하지 않을 것이라는 것을 여러 번 증명해 보였지요.나는 다른 어떤 영화가 정말 '미국인'인지에 대한 두 편집자 간의 논쟁을 부추겼기 때문에 RFC는 기회가 있다고 생각하지만, 외부 편집자들이 논평할 수 있는 우호적인 공간을 만들어 줌으로써 정말로 도움을 줄 수 있다.WhatamIdoing (대화) 22:57, 2014년 1월 10일 (UTC)[응답]

Search

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

소스 코드의 산술 태그에서 이동

모욕적인 말을 숨기기 위한 제안

업로드 시 워터마크 정보

오늘의 특집 기사 사전 보호에 관한 RfC

위키백과 네임스페이스의 모든 페이지 반보호

WebCite가 다운될 수 있음

사전 RfA 피드백 페이지

위키백과에서 가능한 한 적은 실수를 하는 방법

모든 페이지에 링크 기록

WP:FICT#허구적 요소

전체 페이지 대신 섹션 보기

태그 지정 방법에 필요한 지침

유료 프로젝트 금지 제안

프로포즈

개혁안

위키백과 업데이트:가장 놓친 기사

m:MassMessage에 대한 새 사용자 그룹 만들기

질문(MM)

지지대(MM)

반대(MM)

토론(MM)

봇

팝업 금지 제안

웹 사이트 템플릿의 알렉사 순위

편집 시 "미리보기 표시" 및 "변경사항 표시" 옵션 병합 제안

부적절한 페이지 필터링

투표

유사 네임스페이스 리디렉션

대화 페이지로 고아 태그를 이동하도록 제안

표(고형 태그)

가능한 구현

회피하기 위한 자기 참조

찾기 링크 도구

물품 인큐베이터

미발송 페이지에서 카테고리 자동 숨기기

이미지가 있는 템플릿 파괴 행위

위키.png

RFC on Template 보호

모든 Wiki 문서에서 "Like & Comment" 옵션 필요

WP에 제안된 변경사항:리드

계정 병합 및 삭제

실행 취소 불가능으로 설정

VE on Wikipedia: 네임스페이스

날짜 형식 및 언어 템플릿에 편집 알림 추가

파일을 마우스 오른쪽 단추로 클릭하여 전체 해상도로 보기

위키백과 기사에서 확인 가능한 모든 정보 허용

기사 소개에 굵은 글씨로 된 기사 제목 없음

다른 한 가지: 위키백과 밖에서 몇 가지 예를 살펴봄

프로메테우스(2012년 영화)에서는 어떤 포털이 적합한가?

0바이트 길이 변경과 비교하여 감시 목록의 기사가 변경되지 않을 때 명확히 표시

포털 추가 제안:미국의 영화 바람과 함께 사라지다(영화)