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

메인 페이지 기능 제안

안녕하십니까, "오늘의 특집 기사" 코너를 갖는 것도 좋지만 (또는 비슷한 이름)에 "당신의 도움이 필요한 기사" 코너를 두는 것이 좋지 않을까?매일 1개 또는 최대 5개까지 도움이 필요한 기사가 게시되는 경우, 기본적으로 어떤 기사가 될 수 있다.그것이 특집 기사가 아닌 한.나의 제안은 "오늘의 특집 기사"와 비슷한 스타일로 매일 하나의 기사가 나열되어 있는 "오늘의 특집 기사"와 같거나, 편집자들의 도움이 필요한 오늘의 기사 5개의 목록을 만드는 것이다.좀 더 많은 제안을 해주시면 의견 일치를 볼 수 있을 겁니다.좋을 것 같다.그러나 나의 주된 제안은 "오늘의 특집 기사 옆에 있거나 작은 칼럼이나 이와 비슷한 곳에 있을 수 있는 당신의 도움이 필요한 기사. --Judo112 (토크) 21:24, 2009년 9월 12일 (UTC)[응답] 아래에 있는 기사를 하루에 한 개씩 싣는 것이다.

• 내 제안의 주된 이유는 더 많은 사람들이 그것에 대해 알고 관심을 기울이면 개선될 수 있는 수천 개의 기사가 있다고 생각하기 때문이다.나 역시 위키백과 기사의 전반적인 기준을 개선할 수 있는 프로젝트라고 믿는다.--Judo112 (대화) 21:33, 2009년 9월 12일 (UTC)[응답]
• 지지 Gosh, 나는 이것이 매우 좋은 제안이라고 생각한다.(유도112호, 아주 시끄럽고 보수적인 소수의 사람들에 의해 반드시 큰 저항에 부딪힐 것이라고 경고하라.하지만 낙담하지 마!나 또한 네가 낙담한다면 도와줄 수 있어 기뻐.)지오메트리걸 (토크) 21:35, 2009년 9월 12일 (UTC)[응답]
• 걱정마세요. 하지만 진지하게 나는 대부분의 위키피디아 사람들이 이 아이디어의 위대함을 보고 위키피디아 기사의 전반적인 수준을 향상시켜줄 수 있기를 바란다.--- Judo112 (토크) 21:47, 2009년 9월 12일 (UTC)[응답]
• 든든한 지지.임시 협업에 대한 아이디어는 2001년부터 COTW, AID, 모든 종류의 위키프로젝트 공동작업 등 수많은 투옥에서 생겨났지만, 이것은 전면적인 리부팅이 필요한 아이디어라고 생각한다.개선되기 위해 매일 한 기사를 메인 페이지에 올리는 것은 많은 것을 할 것이다: 그것은 지난 몇 년 동안 잃어버린 지역사회의 마법을 다시 불러일으킬 것이다; 그것은 새로운 사용자들을 격려하고 그들을 훈련시키는데 도움을 줄 것이다; 그것은 실제로 사람들로 하여금 다시 편집을 시작하도록 설득할 것이다.내가 보기에 이것은 ITN이나 DYK보다 훨씬 더 중요하다.
  만약 당신이 너무 많은 기사를 가지고 있다면, 사람들은 그것을 그냥 무시할 것이다.하나의 기사(메인 페이지 FA와 동일한 방식으로 많이 선택될 것이며, 명확하고 실행 가능한 개선 경로를 가진 주제)를 강조하고 가능한 한 많은 관심을 기울이는 것은 우리가 이전에 시도했던 그 어떤 것보다도 훨씬 더 진전될 것이다.나는 이 아이디어를 절대적으로 지지한다.—Noisalt (대화) 21:44, 2009년 9월 12일 (UTC)[응답]
  • 응, 그리고 노이즈널츠 사상에 따르면, 가장 효과적일 것이기 때문에 나는 매일 첫 번째 제안을 하나의 기사로 바꾼다.우리가 곧 메인페이지에서 이 열풍을 시작할 수 있도록 이것에 대한 강력한 지지를 얻기를 바란다.또한 "DYK" 섹션이 이 새로운 섹션에 유리하게 이동되거나 제거될 수 있다는 것에 동의함으로서, 이것은 더 생산적일 것이다.- Judo112 (토크) 22:03, 2009년 9월 12일 (UTC)[응답]
• 나는 시끄럽고 보수적인가 봐.프로톤크 (대화) 23:17, 2009년 9월 12일 (UTC)[응답]
• 나는 이 아이디어를 지지한다. 그리고 이것은 기사를 향상시키는 좋은 방법이 될 것이다.그러나 몇 가지 의문이 남는다.

• 1. 어떤 기사가 선정될 것인가?
  2. 어떻게 지명을 하고 기사를 선정할 것인가?FAS처럼 될까?
  3. 새로운 기준이 만들어져야 하는가?
  4. 거대한 반달 유인원이 되지 않을까? 반보호를 해야 하는가? 그게 목적을 망치는 거야? 워리어4321 23:38, 2009년 9월 12일 (UTC)[응답]
• 확실히 그것 때문에 그것이 끌어당기는 어떤 반달리즘도 같은 이유로 인해 재빨리 해치울 것이다.♫ 멜로디아 샤콘네 ♫ (토크) 00:08, 2009년 9월 13일 (UTC)[응답]
  • 1, 2, 3번 질문에 대한 가능한 답은: 무작위로 스텁을 고르는 것이다.공천도 없고 기준도 없을 것이다.지오메트리걸 (토크) 00:20, 2009년 9월 13일 (UTC)[응답]
    • 스텁이라고 한 것은 기준을 원한다는 뜻이다.그 제안은 기사의 확장이 아니라 기사의 개선을 위한 것이다.FA를 겨냥한 GA 기사라도 이 제안에 들어맞을 수 있다는 얘기다.기준이 필요한 이유다.무작위로 고른 스텁이라니?누구한테?언제? 만약 스텁이 무작위로 고르는 것을 허락한다면, 우리는 500명정도의 스텁을 저기서 만들었을 겁니다.메인페이지에 게재될 예정이라면, 이것은 어느 정도의 조직을 필요로 할 것이다. 전사4321 00:27, 2009년 9월 13일 (UTC)[응답]
      • 이건 그냥 생각일 뿐이야.기본적으로 수천 개의 그루터기가 있다.내 아이디어는 기존의 스텁 중 하나를 무작위로 골라내는 것이었다(Special과 유사한 기능 사용:임의) 모든 스텁이 균등하게 선택될 가능성이 있는 경우(편향되지 않도록).지오메트리걸 (토크) 00:40, 2009년 9월 13일 (UTC)[응답]
        • 메인 페이지는 편집자가 아니라 독자를 위한 것이기 때문에 아마도 이것을 메인 페이지에 올리는 것이 가장 좋지 않을까?물론 어디에 둘 것인가에 대한 문제도 있지만, 메인 페이지는 이미 꽉 차 있다.프로데고 00:41, 2009년 9월 13일 (UTC)[응답]
  • 어떤 기사가 선정될 것인가?C급 이하 사운드는 어때?새로운 기준이 만들어져야 하는가?나는 특정 전문지식이 없는 무작위적이지만 관심 있는 연구자가 합리적으로 건설적인 기여를 할 수 있는 접근성(비기술적, 비확실성) 주제에 대한 기사를 제안하고 싶다.어떻게 지명을 하고 기사를 선정할 것인가? FAS처럼 될까?FAS보다 무게가 가벼웠으면 좋겠다. --사이버코브라(토크) 01:33, 2009년 9월 13일 (UTC)[응답]
    • 이 제안에 대한 나의 한 가지 우려는 매우 길고 적당히 잘 쓰여져 있지만 인용된 출처가 없어 GA/FA 과정 밖에서 지칠 줄 모른다는 것이다.새로운 편집자들은 인라인 인용문을 추가하는 것에 관심이 없을 것이다. 그래서 우리는 그 뒷일만 더하면 된다.—Noisalt (대화) 02:34, 2009년 9월 13일 (UTC)[응답]
      • 내 말에 따르면 어떤 기사가 특집 기사가 아니라면 어떤 기사든 고를 수 있을 것이다.B급이 가장 높은 수준의 예술적 유순함이 되어야 한다면 (그러나 나는 듣기 좋다)라고 말할 수 있다.내 생각에 우리는 이것을 위해 DYK 섹션을 제거할 수 있을 것 같다.내 말은 사람들이 목록에 있는 기사를 개선하는데 도움을 주기 위해 할 수 있는 것은 무엇이든지 할 수 있다는 것이다. 내 말은 모든 기사는 편집이 많을 때 도움을 받는다는 것이다.- Judo112 (토크) 06:17, 2009년 9월 13일 (UTC)[응답]
        • 나 또한 그날의 기사를 선택하는 FAS 과정이 가장 좋은 방법이라고 생각한다.만약 공공 기물 파손이 있다면 우리는 그것에 관한 한 그것을 보호해야 한다.위키백과는 항상 반달들이 있을 것이지만 대부분의 사람들은 위키백과에 가장 좋은 것을 원한다.-Judo112 (대화) 06:19, 2009년 9월 13일 (UTC)[응답]
• 역사적으로, 메인 페이지는 편집자가 아니라 독자들을 위한 것이어야 한다는 것이 일반적인 의견이었다.그렇기 때문에 메인페이지에서 선정된 기사(볼드 항목)는 주제가 얼마나 중요하거나 중요한지에 근거하지 않고 그 질에 따라 더 많이 선택된다.그렇기 때문에 새로운 편집자를 격려하는 링크는 몇 개뿐이지, 그것에 대한 전체 메인 페이지 섹션은 아니다.따라서 기존 편집자가 새로운 작업이나 작업을 찾기 위한 전용 섹션은 이 일반적인 지침과 모순될 수 있다.위키백과에서 제안하는 것이 더 적합할 수 있다.대신 커뮤니티 포털.Zzzx11 (대화) 06:21, 2009년 9월 13일 (UTC)[응답]
  • Zzyzx11 당신의 제안은 종종 결국 새로운 기능이 전혀 사용되지 않고 어떤 결과도 초래하지 않으며 결국 막히고 기사를 도우려는 시도의 일종의 역사적 기억으로 이어진다.또한 새로운 섹션에는 언젠가는 확장성과 참조가 필요한 카카 퍼스쿠르 같은 기사가 포함되어야 하고, 그 다음 날 안나 앤더슨 같은 기사가 포함되어야 한다고 생각한다.그래서 우리는 다양한 기사를 얻는다.하지만 나는 개인적으로 새로운 섹션이 메인 페이지에 있어야 한다고 생각한다. 왜냐하면 그렇지 않으면 많은 위키피디아를 끌어들이지 않을 것이고 결국 사용되지 않을 것이기 때문이다.- Judo112 (토크) 06:25, 2009년 9월 13일 (UTC)[응답]
    • 나는 단지 이 섹션이 메인 페이지에 자리를 잡아야만 이 제안이 효과가 있는 것을 볼 수 있다는 것을 지적하고 싶다. 그렇지 않으면 한 기사가 일주일 동안 일하기 위해 선택되었던 다른 프로젝트처럼 사라질 것이다.2007년처럼 막히고 손도 대지 않는 것을 보았다.이 제안이 안되면 같은 믿음을 가질까 봐 걱정된다. 어차피 실효성이 없어 보이는 섹션은 알고 있었니?-Judo112 (토크) 07:04, 2009년 9월 13일 (UTC)[응답]

1을 깨뜨리다

• 지원 우리는 많은 독자들과 편집자들이 필요하다. - Peregrine Fisher (토론) 07:08, 2009년 9월 13일 (UTC)[응답]
  • 우리가 이렇게 빨리 합의에 도달하는 것을 보니 반갑다.위키피디아 메인 페이지는 위키피디아 기사의 전반적인 수준을 향상시키기 위해 이와 같은 급격한 변화가 필요하다고 생각한다.그리고 Peregrine이 지적하듯이, 우리는 이미 편집자가 필요하고 우리는 기사의 전반적인 기준을 개선할 필요가 있다.- Judo112 (토크) 07:34, 2009년 9월 13일 (UTC)[응답]
• 지원 한 가지 제안: 기사 풀은 수많은 프로젝트에 의해 "높은 우선순위"로 표시된 것이어야 한다.이런 식으로, 개선된 기사는 전체에게 더 큰 기여가 될 가능성이 높고, 다양한 주제에 의해 지원된다면, 더 많은 편집자들에게 어필할 가능성이 있다.아이작 (대화) 08:25, 2009년 9월 13일 (UTC)[응답]
• 반대 – 매일의 '필수품'을 선택하는 과정에는 위키피디아에 관한 최악의 기사들을 선택하는 수단이나, 아니면 여전히 가장 훌륭하지만 아직 끝나지 않은 10가지 일을 끝내는 기사들을 선택하는 방법이 반드시 수반되어야 할 것이다.쓰레기를 보여주든지, 아니면 좋은 작품을 보여주든지, 우리의 쓰레기인 척 하든지.유감스럽게도 나는 이것이 실행 가능한 아이디어라고 생각하지 않는다.╟-TreasuryTag►senator-╢ 08:39, 2009년 9월 13일 (UTC)[응답]
• 퍼의 보물 꼬리표를 반대하라. 왜냐하면 우리는 세상에 좋은 완성된 얼굴을 보여줘야 하기 때문이다.—Patton123 (대화 • 기여) 10:27, 2009년 9월 13일에 추가된 서명되지 않은 의견 준비
• 맘에 들어!나는 우리가 1) 백과사전의 중요한 주제, 2) 현재 좋지 않은 기사, 3) 위키백과 경험 이상의 일반적인 관심을 필요로 하는 기사들을 선택할 것을 제안한다.상위 항목 선택:모든 사람들은 부모가 무엇인지 안다.육아, 역사 속 부모의 역할, 다른 문화 등에 대한 재조명이 많다.우리의 기사는 완전히 엉터리여서 아무 소용이 없는 것 같다.새롭고 원거리의 기사를 보여주기로 되어 있는 DYK와 목적의 중첩이 있을 것이다.하지만 DYK는 그동안 기준치를 높이고 이런 것에 여지를 남겼다.그 어려운 질문은 이것을 메인페이지에 어디에 올려야 하는가 입니다. --Apoc2400 (대화) 11:26, 2009년 9월 13일 (UTC)[응답]
• apoc 아이디어 지원:아포크가 지적하는 대로 할 수 있다.내가 관심있는 것은 그것이 메인페이지에 올라 약간의 결과를 볼 수 있도록 하는 것이다.-- Judo112 (토크) 13:49, 2009년 9월 13일 (UTC)[응답]
  • 그리고 반대자들에게 위키피디아는 우리가 이 제안으로 도움을 받을 수 있는 기사들을 잘 언급하지 않고 있는 상황에서 어떤 이미지/얼굴을 보여줄까?이 아이디어는 위키백과 기사의 전반적인 기준을 높여 장기적으로 위키백과가 더 나은 평판을 얻는 데 도움이 될 것이다.-Judo112 (토크) 13:49, 2009년 9월 13일 (UTC)[응답]
    • 그런데 누가 두 번째로 반대하느냐.그 사람은 심지어 그의 코멘트에 서명조차 하지 않았다.--Judo112 (대화) 13:53, 2009년 9월 13일 (UTC)[응답하라]
      • 부모는 메인 페이지에 딱 맞는 기사가 될 것이다.우정과 요리, 러브레터, 월드 등도 같은 맥락에서 볼 수 있다.지오메트리걸 (토크) 14:02, 2009년 9월 13일 (UTC)[응답]
        • 우리의 중요한 기사들 중 많은 것들은 그런 것들과 같다 – 공포, 여자, 장난감, 무역, 영역과 같이 아무도 그것에 대해 생각하지 않을 정도로 일반적인 개념들이다.사실, 중요한 기사 목록은 시작하기에 좋은 장소가 될 것이다.—Noisalt (대화) 16:00, 2009년 9월 13일 (UTC)[응답]
          • 나는 또한 중요한 기사들에 대해 생각하고 있었다.만약 우리가 GA 이하나 B 이하에서 중요한 기사를 쓴다면, 그것은 아마도 몇 년 동안 지속될 것이다.무작위 스텁은 대부분 합치거나 삭제해야 할 수도 있고, 연구하기 어려운 부분이 너무 높기 때문에 작동하지 않을 것이다.편집해 본 적이 없는 사람들에게 도움을 받겠지만 (지속되는) 작업은 여전히 대부분 일반 편집자들에 의해 이루어질 것이기 때문에, 중요한 기사를 강조하면 그들이 반대하기 어려운 다음 B,GA,FA 수준으로 향하게 될 것이다. - Peregrine Fisher (토론) 16:44, 2009년 9월 13일 (UTC)[응답]
• 지원: 위키백과 편집자들의 커뮤니티가 점점...섬광의그것은 확실히 예전과 같지 않고, 그것은 분명히 등록된 편집자들의 잘못만은 아니다.등록되지 않은 반달들은 그것을 하고 싶어하는 사람들을 위해 일상적인 편집을 어렵게 만든다.그럼에도 불구하고, '도움이 필요한 미술관' 섹션은 위키백과가 음악원이 되지 않도록 유지해야 하는 일상적인 편집 커뮤니티에 도움을 줄 수 있다고 생각한다.그래, 그렇게 멀지는 않을지 몰라도...BobAmnertiopsis bob 16:47,_ChatMe! 2009년 9월 13일 (UTC)[응답]
  • 나는 일단 마을 펌프 토론이 무언가로 이어지도록 내버려두라고 말한다.이 새로운 섹션이 유용하게 쓰일 수 있도록 기본 페이지에 새 섹션이 들어갈 공간을 만들자.그리고 토이 기사부터 시작하자. 좋은 출발이 될 것이다.-- Judo112 (토크) 16:52, 2009년 9월 13일 (UTC)[응답]
    • 그러니 얼마든지 고쳐라.우리가 마침내 메인 페이지를 위해 새롭고 신선한 것을 한다면 위키피디아는 매우 행복할 것이다.--Judo112 (대화) 16:54, 2009년 9월 13일 (UTC)[응답]

2를 깨뜨리다

• 반대 메인 페이지는 편집자가 아니라 독자를 위한 것이다.
  — V = I * R (Ω과 대화) 16:57, 2009년 9월 13일 (UTC)[응답]
  • 앞서 지적했듯이, 독자들은...그리고 많은...편집자가 필요한 것이다.그리고 이런 종류의 새로운 특징들은 위키피디아가 전반적으로 더 나은 기사를 갖게 하고 또한 많은 새로운 편집자들을 얻게 할 수 있는 것이다.그리고 만약 메인 페이지가 독자들만을 위한 것이라면, 편집자들이 오늘의 특집 기사 등과 같은 페이지를 편집하도록 하는 어떠한 시도도 없을 것이기 때문에 나는 당신이 틀렸다고 믿는다.그렇다면 그것은 단지 위키백과의 뉴스 종류나 위키백과 정보가 아닐 것이다.--Judo112 (대화) 17:33, 2009년 9월 13일 (UTC)[응답]
  • 나는 지금 내가 말할 수 있는 모든 것을 말했고, 이 토론의 섹션에서 찾을 수 있는 나의 모든 관점을 말했다.이제 나는 위키피디아 사용자들에게 결정을 맡긴다.바라건대 나는 이 특징을 곧 메인페이지에서 볼 수 있기를 바란다.- Judo112 (토크) 17:37, 2009년 9월 13일 (UTC)[응답]
    • 우리는 더 많은 편집자나 다른 편집자가 필요하지 않고 더 나은 편집자가 필요하다.이것은 해결책이 아니다. 왜냐하면 사람들은 그들이 관심을 가지고 글을 쓸 수 있는 기사들을 편집할 것이기 때문이다.메인 페이지 자체가 독자들을 위한 것인데, 그것은 주로 읽으려는 기사를 보여주기 때문이고, 그것은 그렇게 남아야 하기 때문이다.이 제안은 특별히 편집하려는 기사를 강조하기 위해 만들어진 것으로, 그것이 훌륭하고 훌륭한 목표지만 메인 페이지에 실리는 것이 되어서는 안 된다.

      여기 제안된 해결책이 있다: 위키백과 네임스페이스에서 이 과제의 목표를 달성하는 페이지를 개발하고, 그것이 가동된 후에 우리는 그것에 대한 링크를 사이드바에 추가하는 것에 대해 이야기 할 수 있다.그것은 메인 페이지만 남겨둔 채 비슷한 수준의 주의를 기울여야 한다.
      — V = I * R (Ω과 대화) 20:08, 2009년 9월 13일 (UTC)[응답]

      • 더 좋은 제안은 사람들이 이곳에 물건을 제안하기 전에 위키피디아가 이미 가지고 있는 것을 가서 보는 것이다.이것은 사람들이 이미 존재하는 것들을 제안하고 있는 현재 이 페이지의 세 번째 섹션이다.G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]
• 훌륭한 아이디어를 지원하십시오.나는 오랫동안 기존 물품의 개선에 더 높은 우선순위를 두어야 한다고 주장해 왔다.하지만 메인페이지에서 연결된 어떤 것이든 반달마그네틱이 된다는 사실은...기사의 반달리즘과 생산적인 편집의 양을 비교해 보면 흥미로울 것이다. œ^™ 18:40, 2009년 9월 13일 (UTC)[응답]
  • 이 문제는 오늘날의 위키피디아가 쉽게 해결할 수 있다.등록되지 않은 모든 사용자를 며칠, 몇 시간 또는 몇 주 동안 싱겔 기사에서 차단하는 것이 가장 쉬운 방법이며 반달들이 많을 때 투데이 특집 기사에서 꽤 자주 사용된다.항상 반달들이 있을 것이지만, 대부분의 사용자들이 위키피디아에서 도와준다고 믿어야 한다...그것이 내 철학이다:)--주도112 (대화)20:30, 2009년 9월 13일 (UTC)[응답하라]
• 지원 페이지(User:B)의 태그를 기반으로 목록을 만들고 기사를 중립적으로 선택하는데 도움을 줄 수 있는 봇들이 많이 있다. Wolterding/Cleanup lists(예:그리고 그 시간까지 관심을 필요로 하는 명확한 사람들의 수가 증가함에 따라, 나는 계속해서 변화하는 리스트가 이루어질 수 있을 것이라고 확신한다.아마도 다음과 같은 것.
  • 제1조에는 출처가 부족하다.
  • 제2조는 위키백과가 필요하다.
  • 제3조는 이미지가 부족하다.
  • (새 목록 만들기)
  • 등 - Trevor MacInnis 19:16, 2009년 9월 13일 (UTC)[응답]
• 지원, 하지만 첫 페이지에 있으면 안 돼 마을 펌프 같은 거 말이야— 207.161.190.232(토크) 19:52, 2009년 9월 13일(UTC)에 의해 추가된 이전의 부호 없는 논평
  • IP:207.161.190.232와 같은 심각한 토론에 참여하기 전에 두 개 이상의 기사를 편집하십시오.그리고 여기 위키피디아에 대한 사용자 페이지를 가져와라.--Judo112 (대화) 20:23, 2009년 9월 13일 (UTC)[응답하라]
    • 유도112, 그 코멘트를 철회해 주면 고맙겠다.그것은 지나치게 잠재적인 신인을 물어뜯는 것 같다.IP 편집자가 제기한 요점은 사실 공평한 것이며, 그 장점에 따라 판단되어야 하며, 계정 부족이나 명백한 이전 기고 부족(많은 사람들이 동적 IP 주소를 가지고 있기 때문에, 이것은 익명으로 편집한 사람일 가능성이 완전히 있다), 또는 심지어 o를 기록하지 않은 사용자일 뿐이다.n). 마을 펌프의 존재에 대한 인식은 이미 위키백과에 어느 정도 친숙함을 시사한다.그러나 IP 사용자에게:나도 네가 아직 계좌를 등록하지 않았다면 네가 계좌를 등록하는 것을 추천한다.당신은 당신이 관심 있는 기사를 보고, 편집한 내용을 추적하고, 대화를 더 쉽게 할 수 있다는 것을 알게 될 것이다:) TheGrappler (토크) 00:20, 2009년 9월 18일 (UTC)[응답]
• 절대적으로 메인페이지에 올려놓는 것을 지지한다.이것은 우리를 위키의 모든 것의 근원으로 돌아가게 하고, 나는 그것이 많은 도움이 될 것이라고 생각한다.공천보다는 무작위로 뽑은 게 가장 좋을 것 같아.쿨3 (토크) 20:17, 2009년 9월 13일 (UTC)[응답]
  • 좋아. 그리고 새로운 섹션은 메인 페이지에 배치되어야 한다고 말할 때 모든 사람들이 동의하기를 바란다. 그렇지 않으면 그것은 점점 더 적게 방문될 것이고 결국 아무도 그것을 사용하지 않을 것이기 때문이다. 그리고 그것은 차단될 것이고 위키피디아에서 전에 여기 그렇게 많이 사라졌던 몇몇 오래된 프로젝트의 공동묘지로만 방문될 것이기 때문이다.- Judo112 (대화) 20:21, 12009년 9월 3일 (UTC)[응답하라]
  • 2009년 9월 13일 (UTC) 0:00 UTC. warrior4321 20:24 (UTC)[응답]에서 기사 C급 이하를 선택한 대본을 가질 것을 제안한다.
    • 정말 좋은 생각이야 워리어.아마도 이 제안을 지지하는 사람들이 많은 것 같으니 빨리 이 문제를 해결할 수 있을 것이다.-- Judo112 (대화) 20:27, 2009년 9월 13일 (UTC)[응답]
      • 나는 이것이 메인 페이지 또는 버스트라는 것에 동의한다.다른 곳이라면 어디든 그 목적을 저버린다.하지만 더 생각해보면, 나는 그 기사에 대한 아이디어가 있다; 만약 우리가 완전히 하찮은 단발로 끝난다면 그것은 낭비일 것이다.그렇다면 적절한 위키프로젝트로부터 "상위" 또는 "상위" 등급을 받은 기사 C등급 이하를 무작위로 취한다면 어떨까?쿨3 (토크) 20:33, 2009년 9월 13일 (UTC)[응답]
        • 더 좋은 Cool3:) 좋은 생각!!--Judo112 (대화) 2009년 9월 13일 (UTC) 20:36[응답]
          • 나는 또한 새로운 섹션이 DYK 섹션이 현재 있는 곳에 위치하거나 그것에 가까운 곳에 위치할 것을 제안하고 싶다.하지만 나는 DYK가 오늘 있는 곳에서 DYK가 한 단계 더 내려갔으면 좋겠어.--- Judo112 (대화) 20:36, 2009년 9월 13일 (UTC)[응답하라]
            • 위키프로젝트에서 중요도가 높거나 가장 높은 페이지를 먼저 다룬다는 생각이 마음에 든다.나는 단지 이것이 페이지의 중요성을 남용하는 것으로 이어지지 않기를 바랄 뿐이고, 우리는 갑자기 본질적으로 중요성이 높지 않은 페이지를 개선만을 위한 높은 중요도로 보게 된다. warrior4321 20:39, 2009년 9월 13일 (UTC)[응답]
              • 난 정말 아무 걱정도 안 보여, 우리는 나쁜 것과 좋은 것을 함께 가져가야 해, 전반적으로 난 이것에서 나쁜 것이 나온다고 보지 않아.한번 해보자. 잘 안되면 항상 다른 걸 해볼 수 있어.오늘 밤 누군가가 이 새로운 섹션을 첫 번째 기사로 고쳐 우리가 어떻게 작동하는지 볼 수 있게 하는 것이 가장 좋을 것이다.--- Judo112 (토크) 20:42, 2009년 9월 13일 (UTC)[응답]
                • 메인 페이지는 어쨌든 새로운 스타일을 필요로 한다.만약 누군가가 수정작업을 하고 싶어한다면 오늘 밤 0시 UTC까지 끝낼 수 있을 것 같다.누가 그랬으면 좋겠다.--주도112 (대화) 21:05, 2009년 9월 13일 (UTC)[응답하라]
                  • 나는 그것이 좀 시기상조라고 생각한다.진짜는 누군가가 그것이 어떻게 생겼을지에 대한 프로토타입/모크업을 만드는 것이다.그런 다음, RfC 또는 유사한 것이 필요할 것이다.메인 페이지 재설계는 꽤 중요한 사건들이다.쿨3 (토크) 21:29, 2009년 9월 13일 (UTC)[응답]
                    • 지난 주말 마을 펌프에서 24시간 동안 진행된 토론 끝에 메인 페이지를 개편하지는 않을 것이다.우리는 또한 가능한 기사를 고를 수 있는 어떤 과정도 아직 마련되어 있지 않다.애니메이트^draw 21:34, 2009년 9월 13일 (UTC)[응답]

3을 깨뜨리다

• 재무부 태그별로 반대하십시오.우리는 정말 우리의 최악의 기사를 1면에 싣기를 원하는가?애니메이트^draw 21:34, 2009년 9월 13일 (UTC)[응답]
  • 위키피디아는 사람들에게 형편없이 쓰여진 일부 기사들을 편집하는 것을 도와달라고 요청하는 진행 과정으로, 위키피디아가 완성되지 않았다는 것을 보여주며, 항상 우리의 기사들에 대한 적절한 편집을 찾고 있다. 전사4321 21:44, 2009년 9월 13일 (UTC)[응답]
    • 두 번째 전사의 대답이다.지오메트리걸 (토크) 21:51, 2009년 9월 13일 (UTC)[응답]
      • 응, 하지만 전통적으로 1면은 최고의 기사들을 위한 거였어.나는 점점 더 많은 편집자들을 얻는 가장 좋은 방법은 우리 작품의 가장 좋은 부분을 부각시키는 것이지 최악의 편집자가 아니라고 생각한다.사람들이 이 기준에 해당하는 기사를 편집하도록 하는 다른 방법들이 있다...존재하지 않는 기준들을 생각해봐이것은 위키프로젝트나 다른 과정에 의해 처리될 수 있는 것으로 보인다.어쩌면 표지판 담당자들에게 연락하는 것이 더 좋은 생각일 수도 있고, 누군가가 업데이트 할 수 있는 {{pic}과 같은 템플릿을 만드는 것이 효과가 있을 수도 있을 것이다.어쨌든, 나는 이것이 메인 페이지에 적절하다고 생각하지 않는다.애니메이트^draw 21:53, 2009년 9월 13일 (UTC)[응답]
        • "전통적으로 첫 페이지는 우리의 최고의 기사를 위한 것이었다." -> 이것은 거짓이다: DYK와 ITN은 위키피디아가 가장 못하는 것을 강조한다; 새롭게 만들어진 미완성된 단편들, 그리고 편집하기 쉬운 빠르게 변화하는 주제에 대한 기사들.지오메트리걸 (토크) 22:04, 2009년 9월 13일 (UTC)[응답]
          • 그래서 이제 더 많은 "미완성 스터브"를 홍보하고 싶으십니까?좋아. 솔직히 DYK, ITN, FA는 우리 독자들에게 아주 좋아.하나는 못 들어봤을 것 같은 흥미로운 주제를 다루고, 하나는 그들이 의견을 가지고 있을 것 같은 시기적절한 기사를 다루며, 세 번째는 우리의 최고의 기사를 자랑한다.이것들은 새로운 편집자와 독자들을 끌어들이기 위한 긍정적인 방법이다.이 새로운 아이디어는 우리의 헛소리를 과시하는 것일 것이다.이것은 새로운 편집자와 독자를 끌어들이는 부정적인 방법이다.나는 여전히 반대한다, 특히 위에서 강조했던 것처럼 내부에서 이것을 할 수 있는 다른 방법들이 있기 때문이다.애니메이트^draw 22:25, 2009년 9월 13일 (UTC)[응답]
• 반대 왜 독자들이 '개선해야 할 미술품'에 관심을 가질까?이것은 메인 페이지가 편집자를 위한 것이 아니라 독자들을 위한 것이라는 오랜 합의의 변화로 명백하다. 그리고 합의는 바뀔 수 있지만, 그 합의는 있었다는 것과 왜 그것이 있었다는 것을 이해하는 것이 중요하다. 그러나 나는 좋은 징조가 되지 않는 제안에서 이것에 대한 언급이 없다고 본다.어떤 경우든, 특히 DYK, 그리고 그보다 적은 정도까지 ITN은 이미 목적을 달성했다.만약 정말로 필요하다면, 우리는 DYK 기사에 편집자가 필요하다는 것을 강조할 수 있다.닐 아인(토크) 22:31, 2009년 9월 13일 (UTC)[응답]
  • 위키의 목표는 편집자와 독자의 구별을 없애는 것이 아닌가?쿨3 (토크) 22:37, 2009년 9월 13일 (UTC)[응답]
    • 누가 그랬어?사실 선별된 편집자만 허용하고 일부 사람들은 편집 가능한 개인 웹사이트를 위해 Wiki를 사용하기도 하는 폐쇄적인 위키들이 많이 있다.위키피디아는 누구에게나 편집을 허용한다. 그것은 우리가 독자와 편집자를 같은 것으로 생각한다는 것을 의미하지는 않는다.메인 페이지 밖에서도 많은 부분에서 우리의 주된 관심사는 독자들을 위한 백과사전을 만들고 있고 편집자를 위한 것이 아니기 때문에 우리의 주된 관심사는 독자들이다.우리는 많은 독자들이 편집자가 되기를 바라지만, 그렇다고 해서 우리가 그들에게 닐 아인(토크) 22:49, 2009년 9월 13일 (UTC)[응답하라]는 것이 아니다.
  • 닐 아인:독자들이 왜 이 날에 관심을 가질까?아니면 알고 있었나?그들은 너무 지루해.하지만 내가 그것에 관심이 없다는 것은 다른 사람이 그것에 관심을 가질 수 없다는 것을 의미하지는 않아.

    이 '메인 페이지는 편집자가 아닌 독자를 위한 것이라는 공감대'에 대해서는 어디서 나온 것인지 궁금하다.나는 지금까지 그것에 대해 들어본 적이 없다.—Noisalt (대화) 22:57, 2009년 9월 13일 (UTC)[응답]

    • 당연히 넌 그들이 지루하다고 생각할 자격이 있어.나는 많은 사람들이 역사에서 오늘 일어난 일에 대해 더 많이 배우는데 관심이 있다고 생각한다. 그것은 신문이나 웹사이트에서나 공통적인 것이다.역사에 대한 관심을 인류 공통의 괴짜라고 부를 수 있고 관심이 촉발되는 방법 중 하나는 역사에서 오늘 무슨 일이 일어났는지 생각하는 것이다.마찬가지로 많은 사람들이 DYK에서 대부분의 것을 발견하지 못할 수도 있지만, 나는 많은 독자들이 적어도 한 권은 읽게 될 것이라고 추측한다. 우리는 그것들을 많이 가지고 있고 8시간마다 그것들을 바꾸게 되기 때문에, 그것은 그렇게 어렵지 않다.여러분이 알고 있듯이, 많은 사람들이 여러분에게 지루해 보이는 것들에 대해 더 많은 관심을 가지고 있다는 것을 알고 있다(그리고 대부분의 사람들은 편집하지 않기 위해 위키피디아에 온다는 것도 명백해야 한다).또한 DYK와 함께 우리의 독자들에게 관심을 갖는 것이 우리의 의도라는 것도 꽤 명백하다. 왜 우리는 그것을 '최근의 기사를 개선한다'가 아니라 '알고 있었는가'라고 부르는지, 그리고 왜 우리가 흥미있는 독자들에게 관심을 가질 수 있는 훅을 목표로 하는지 말이다.

      메인 페이지가 편집자가 아닌 독자들을 위한 것이라는 것을 들어본 적이 없는 것에 대해, 당신은 실제로 메인 페이지의 어떤 분야에 참여한 적이 있는가?난 널 여기 내려놓고 싶지 않아. 하지만 이건 항상 Talk에서 나오는 말이야.메인 페이지 및 WP의 경우:ITN(그것이 우리가 하위적인 관심사일 가능성이 있지만 기사에는 아직 관련 내용이 충분하지 않은 것을 내세우지 않는 이유) 그리고 나는 메인 페이지 논의와 관련된 다른 모든 분야를 의심하고 싶다.예를 들어, 이 초기 토론 토크를 참조하십시오.2002/2003년 메인 페이지/아카이브 4는 이를 암시한다.독자들이 원하는 것에 대한 언급이 얼마나 많은지 주목하라. 그리고 심지어 우리는 편집자 링크를 1면에 축소판과 연결시키려 하고 있다.내가 발견한 메인 페이지에 대한 가장 빠른 언급은 편집자가 아닌 독자들을 위한 것이었고 2004년 초 Talk:메인 페이지/아카이브 14#위키피아의 유니크한 본성은 물에 잠겼으며, 거기에 대한 설명은 여전히 어느 정도 관련이 있다고 생각한다.거기에 약간의 반대가 있었으므로, 나는 그것이 다음 번에 Talk에서 표현되었다는 것을 주목하겠다.메인 페이지/아카이브 25#부티풀! 이의 없이.나는 또한 내가 지적한 이전의 토론에서와 같이 다른 많은 토론에서도 그것이 함축되어 있다는 것을 유념하고 싶다. 예를 들어 독자들에게 상황을 더 좋게 만드는 방법에 대한 많은 토론을 발견할 수 있을 것이다.내가 언급했듯이 이것은 종종 언급되기 때문에 당신은 여기서 많은 관련 논의를 찾을 수 있을 것이다.닐 아인(토크) 23:38, 2009년 9월 13일 (UTC)[응답]

    • 닐 아인 제2의 닐 아인.통계에 따르면 DYK에 게재된 거의 모든 것이 페이지뷰에서 상당한 증가를 얻는다고 하는데, 이것은 독자들이 (아마 후크에 의해) 매력을 느끼는 좋은 지표다.DYK와 ITN 기사는 이론적으로 누군가 독자를 편집자로 끌어들이기 위한 훌륭한 방법이다. - 그 기사들은 적극적으로 보살핌을 받고 있기 때문에 토크 페이지 토론은 응답을 받는데 몇 주가 걸리지 않는다(또는 몇 달 혹은 몇 년이 걸리지는 않는다. 내가 이전에 본 바로는 답신을 받기 훨씬 전에 프로젝트를 포기했던 새로운 편집자들에게 말이다!).그것은 새로운 편집자를 돕기 위해 이용할 수 있는 더 많은 지침이 있다는 것을 의미한다.DYK나 ITN 기사는 모두 피처링 표준에 있지 않기 때문에, 개선의 여지가 있는 경우가 많다(그리고 ITN은 자주 업데이트가 필요하다). 그래서 새로운 편집자들은 기회를 갖게 된다.그럼에도 불구하고 그들은 기사가 이미 특정 품질 기준을 통과했을 경우에만 메인 페이지로부터 연결되며, 이것은 새로운 편집자들이 무엇이 허용 가능한지에 대한 요지를 얻는 데 도움이 될 수 있다.반면에, 나는 ITN과 DYK가 새로운 사용자들을 끌어들인다는 구체적인 증거를 본 적이 없다는 것을 인정한다.우리는 위키백과 편집자가 되는 경로가 무엇인지에 대한 좀 더 포괄적인 연구가 필요하다 - 내 장담은 DYK에 오타가 자주 나타나긴 하지만 메인 페이지 사용과 강하게 연관되어 보이지 않는 성가신 오타를 편집하기 시작하는 사람들에게 있을 것이다. (나는 우리가 방청객 독자들을 유인하기 위해 악의적인 "트랩도어" 기능을 개발해야 하는지 궁금하다.편집, 보호되지 않은 페이지의 일반적인 오타를 자동 감지함으로써... 등록되지 않은 사용자에게 오류가 감지되었음을 알리는 배너 경고를 제공하고, 이를 보려면 클릭하도록 요청하십시오...오타가 부각되고 "오타인가?Y/N" 대화 상자가 나타난다... "Y"를 클릭하면 도구 팁이 편집 버튼을 부드럽게 가리키고 ... 그리고 나서 우리는 그들을 잡았다;) 특히 그들이 저장한 후에 멋진 감사 메시지를 받게 되면, 그들이 계좌에 등록하는 것을 제안하고, 자동으로 팁을 주는 새로운 greeter가 그들에게 진정 건설적인 e를 감사하는 메시지를 남긴다.그들이 즉시 가입할 기회를 이용하지 못할 경우를 대비해서 그들의 IP 토크 페이지에 있는 것.프로그램을 짜는 것은 악몽이 될 것이라고 확신하지만, 나는 이것이 무섭게 효과적일 것이라고 생각한다!TheGrappler (talk) 01:26, 2009년 9월 18일 (UTC)[응답하라]

4를 깨뜨리다

• 반대 - DYK 및 임의 기사에 의해 중복됨.Cirt (대화) 2009년 9월 13일 23:18 (UTC)[응답]
  • DYK 훅이 독자들에게 기사를 정리하는 것을 돕도록 부추긴다고는 말할 수 없지만, 얼마나 특별한지는 알 수 있다.무작위는 독자들이 기사를 고치도록 유도하는데 도움이 될 수 있다. 매초 클릭할 때마다 대부분의 경우 정리가 필요한 스텁이 생기기 때문이다.또한 WP:매우 눈에 띄는 Special에 표시된 문제:일부 작업을 할 수 있는 기사 대신 4개의 기사를 나열한 최근변경 페이지. œ^™ 23:51, 2009년 9월 13일 (UTC)[응답]
• 반대 백과사전은 독자들을 유인하려는 노력과 분리되어야 한다."편집" 태그를 부착하고, 우리 페이지의 앞면에 관여하도록 권하는 것은 아주 좋지만, 제품 1면에서는 참을 수 없다.우리의 임무가 우선되어야 한다. 스코모록 23:23, 2009년 9월 13일 (UTC)[응답]
  • 답변 - 우습게도, 나는 우리의 임무는 누구나 편집할 수 있는 무료 백과사전을 만드는 것이라고 생각했다.더 많은 사람들이 필요한 기사를 편집하도록 장려하는 것이 그 임무와 충돌하는데 어떻게 도움이 되는가?이게 임무에 도움이 된다!Nutiketaiel (대화) 16:49, 2009년 9월 17일 (UTC)[응답하라]
• 중요한 기사 제안에 대한 추가 코멘트, 나는 중요한 기사들을 완전히 파괴할 수 있는 잠재력을 가지고 있다고 볼 수 있고 나는 여기서 과장하는 것이 아니다.WP에서 공명할 정도로 정기적인 참여자로서:ITN, Talk:메인 페이지와 또한 많은 다른 문제점도 보았으며, 나는 WP:시스템 편향의 많은 편집자들 사이에서 특히 메인 페이지에 그것을 노출시키는 것에 대한 강한 우려가 있다는 것을 알고 있다.실제로 내가 얼마 전에 중요한 기사들을 처음 읽었을 때, 그것은 나의 첫 번째 생각 중 하나였고, 그것이 그리 나쁘게 보이지는 않지만, 그것은 완벽하지 않고 많은 논쟁의 영역을 쉽게 볼 수 있다.나는 그것이 그렇게 잘 살아남은 이유들 중 하나는 많은 사람들이 그것이 그다지 큰 영향을 끼치지 않기 때문에 그렇게 많이 신경 쓰지 않기 때문이라고 강하게 의심한다.대부분의 위키피디아는 아마도 그것이 존재하는지조차 모르고 있을 것이다.그러나 나는 당신이 개선책을 위해 메인 페이지에 열거할 가치가 있는 기사들을 선택하기 위해 그것을 사용하려고 하면, 훨씬 더 많은 관심을 가질 것이고, 아마도 어떤 것들은 결코 끝나지 않을 것이고, 어떤 것들은 무엇이 속하고 속하지 않는지에 대한 다소 고약한 논쟁들이 있을 것이라고 장담할 수 있다.우리는 이미 메인 페이지의 다른 부분에서도 어느 정도 이것을 보고 있지만, 다른 기준을 충족시켜야 하고, 또한 어느 정도 확립된 시스템인 닐 아인(토크) 23:38, 2009년 9월 13일 (UTC)[응답]이 있기 때문에 자연스럽게 제한되고 있다.
• 반대한다. 특집 기사는 2,600개 정도밖에 안 되지만, 정리가 필요한 기사는 수십만 개에 달한다.여러분은 무작위로 하나를 골라야 할 것이고, 이것은 때때로 공격적이거나 스팸성 기사를 메인 페이지에 올려놓게 될 것이고, 일상적으로 별로 흥미가 없는 주제들을 골라야 할 것이다.아니면, 수작업으로 그것을 하고, 수십만의 잠재적인 풀에서 어떤 기사들을 나열할지 알아내려고 하는 조직적인 악몽을 꾸게 될 것이다.게다가, 메인 페이지에 있는 것들은 반달 자석인 경향이 있기 때문에, 실제로 얼마나 많은 개선이 일어날지는 의문이다.Mr.Z-man 00:59, 2009년 9월 14일 (UTC)[응답]
  • 그럼에도 불구하고 위키백과는:기사 협업과 개선 추진은 이론적으로 불가능하다는 주장에도 불구하고 실제로 작동하는 것 같다.〇 G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]
    • 비교가 잘 안 된다.그것은 하루에 소수의 편집자들이 보는, 잘못된 페이지에 있다.초당 수천 명의 사람들이 볼 수 있는 메인페이지에 게재된다면, 어떤 기사를 게재할지에 대한 결정은 훨씬 더 큰 거래가 될 것이다.DYK가 어떤 기사를 추천할 수 있는지에 제한이 없다고 생각해 보십시오.Mr.Z-man 23:35, 2009년 10월 3일 (UTC)[응답]
• 반대한다. 나는 이 제안의 시행에 편집자들이 정확히 어떤 기사가 도움이 필요한지 토론으로 결정하지만 광고할 수 없을 정도로 심각한 문제는 없을 것이라고 생각한다.이것은 불필요한 비오라크레이시 수준을 추가하는 반면, 그 노력은 실제로 기사를 수정하는 데 쓰는 것이 더 나을 것이다.ThemFromSpace 02:19, 2009년 9월 14일 (UTC)[응답]
  • 위에서 언급한 바와 같이:위키백과:기사 협업 및 개선 드라이브가 이미 존재함.G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]
• 반대, 우리는 같은 종류의 일에 DYK를 사용한다.아이언홀드 (토크) 2009년 9월 14일 (UTC) 13:42 [응답]
• 내 제안(다른 곳에서도 작성)은 네비게이션 섹션에 "도움이 필요한 무작위 기사" 링크를 설치하는 것이다.이것이 더 실현 가능할까?재키스펠 (대화) 13:01, 2009년 9월 14일 (UTC)[응답]
  • 응, 나는 이 제안이 마음에 들어.내 생각에 반대 의견을 밝힌 사람들은 제안의 명백하게 좋은 측면은 고려하지도 않으면서 부정적인 측면에만 초점을 맞추는 것 같다.나는 아직도 지지에 있는데, 그들은 또한 마지막 몇 사람이 반대했고 단지 유행을 따랐기 때문에 더 반대하는 것 같다.- Judo112 (대화) 13:54, 2009년 9월 14일 (UTC)[응답]
    • 언급된 반대는 제안의 명백하게 좋은 측면은 고려하지도 않으면서 부정적인 측면에만 초점을 맞추는 것 같다 - 위에서 언급한 바와 같이, 나는 이 제안이 독자들을 위한 것이 아니라 독자들을 위한 본 페이지라는 오랜 관습에 역행하는 것이라는 것을 지지한 사람들에 대해서도 똑같이 말할 수 있다.그리고 합의를 바꾸는 것은 가능하지만, 적어도 당신이 그것을 바꾸는 것을 언급하는 것은 현명하다.그들은 또한 마지막 몇 사람이 반대했고 단지 유행을 따랐기 때문에 더 반대하는 것처럼 보인다 - 그것은 당신이 선의로 생각하는 것처럼 들리지 않는다.나는 당신이 더 많은 반대를 하게 된 더 큰 이유가 입소문이 나면서(예를 들어, 그것은 Talk: Talk에서 연결되었다)라고 의심한다.메인 페이지) 정기적으로 VPP를 체크아웃하지 않는 사람들이 자신의 견해를 밝히기 위해 왔다.아마도 '보수적인 사람들' 기하학 소녀가 닐 아인(토크) 07:41, 2009년 9월 15일 (UTC)[응답]을 언급했을 것이다.
  • "도움이 필요한 문서"를 어떻게 정의하십니까?GA나 FA가 아닌 모든 기사가 "도움이 필요하다"고 한다면, 그것은 99% 이상의 기사와 일반 특집 기사 사이에는 거의 차이가 없을 것이다.무작위. 미스터 Z-man 18:32, 2009년 9월 14일 (UTC)[응답]
• 나는 이것의 일반적인 추력을 좋아하지만, 메인 페이지가 올바른 곳인지 잘 모르겠다; 새로운 편집자들의 플래시몹은 다루기 힘들다. 그리고 그것이 내 경험상 대부분 일면에 그렇게 광고를 함으로써 얻을 수 있는 것이다.마을 펌프 헤더에 뭔가 있나?감시단 안내문?템플릿, WP:CENT? – Luna Santin (토크) 16:50, 2009년 9월 14일 (UTC)[응답]
  • 예를 들어, 오늘 특집 기사에서 반달들을 어떻게 다루어야 할까?등록되지 않은 모든 사용자를 차단하는 것은 매우 효과적이고 1분밖에 걸리지 않는다.그래서 나는 정말로 여기서 어떤 종류의 공공 기물 파손 문제도 보지 않는다. 왜냐하면 오늘 소개된 기사가 위험 지역에서 더 많이 다루어질 것이기 때문이다.내게는 여전히 고통의 페이지만이 이 제안된 특징을 배치할 수 있는 곳에 있다.위키백과의 새로운 특징만큼이나 빨리 사라지겠지만그만큼 간단하다.--Judo112 (대화) 16:07, 2009년 9월 15일 (UTC)[응답]
    • 뭐라고?위키피디아의 문화에 대한 자유로운 편집의 중요성을 감안할 때, 메인페이지에서 연결된 기사는 일반적으로 반보호가 되어 있지 않다.나는 "반달리즘 문제"라고 말하지 않았다. 그렇다, 있을 것이다. 하지만 나는 유지 보수 문제가 더 큰 걱정거리라고 생각한다.새로운 사용자들의 플래시몹은 원칙적으로 품질로 이어지지 않는다."고생"하기는커녕, 감시목록 안내와 중앙집중식 토론은 시작부터 놀라운 성공을 거두었다(다른 무엇보다도 이 바로 그 토론에 수많은 경험 많은 사용자들을 끌어들였다).물론 나는 네가 왜 그 제안에 동의하지 않는지 알 수 있지만, 그것을 무시하는 것은 현명하지 못한 것 같다.– 루나 산틴(토크) 19:09, 2009년 9월 18일 (UTC)[응답]
  • {{COTWCurrentPicks}}도 이미 존재한다.〇 G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]

5를 깨뜨리다

• 지원 필요한 개선의 많은 부분은 독자들로부터도 나오고 있으며, 위키피디아가 변하고 있고, 누구나 도울 수 있다는 것을 보여주기 위해 새로운 기사를 만들고 고치는 것을 보여주는 것이 중요하다.그것은 더 많은 편집자들을 끌어들일 것이다.또한, 그것은 나쁜 기사일 필요는 없으며, Fleasure와 같이 개선이 필요한 기사나 위키백과의 다른 기사들:문제 페이지.우리는 또한 번역이 필요한 페이지나 새로운 사용자가 할 수 있는 일반적으로 쉬운 다른 작업들을 특징으로 할 수 있다.그리고 개선을 위한 기사들은 끔찍한 단편일 필요는 없고, 잘 알려질 만큼 중요하며, 새로운 사용자들에 의해 쉽게 고쳐질 수 있다.

  '[열린 작업 태그로 이동] 도움이 필요한 무작위 기사] - '랜덤 스텁'(이 중 55,000개에 대해 시작), '랜덤 최다 수배 기사' 등.재키스펠 (대화) 2009년 9월 15일 (UTC) 16:39, 답신 [응답]

• 어떤 기사가 실린 것을 반대하면, 30분 안에 목적을 무시하고 보호받게 될 것이다.아이스웨지 (대화) 05:36, 2009년 9월 16일 (UTC)[응답]
  • 왜냐하면 우리는 항상 특집 기사도 보호해야 하기 때문이지?비시몬스666 (대화) 01:18, 2009년 9월 17일 (UTC)[응답하라]
• 논평 사이드바에 "도움이 필요한 난잡한 기사"를 제안하는 사람들은 너무 완전히 핵심을 놓치고 있다. 나는 그들이 원래 제안서를 이해했는지 궁금하다.우리는 도움이 필요한 기사를 찾는 쉬운 방법을 찾고 있는 것이 아니다. 우리는 많은 편집자들이 동시에 하나의 기사를 작업하도록 하는 쉬운 방법을 찾고 있다.—Noisalt (대화) 2009년 9월 17일 00:15 (UTC)[응답]
  • 그럼 봐봐.이것들은 이미 존재하고 있다.G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]
• 지지 - 나는 이것이 좋은 생각이라고 생각한다.메인 페이지를 보는 사람들을 단순히 보는 대신 편집을 돕는 것으로 끌어들이고, 프로젝트 전체에 도움이 될 것이라고 생각한다.Nutiketaiel (대화) 16:44, 2009년 9월 17일 (UTC)[응답하라]
• 좋은 아이디어를 지원하십시오!하지만 위키피디아의 분리된 영역에 그것을 가지고 있고, 그 페이지와 연결고리가 있을 수 있다.아니면, 무작위 기사 링크처럼, 링크를 고치기 위해 무작위 기사를 쓸 수도 있을 겁니다.Acdude92 (대화) (사인) 16:53, 2009년 9월 17일 (UTC)[응답]
  • (a) 나는 이것이 실제로 실패할 것이라고 꽤 확신한다; (b) 시험 기간과 "성공"에 대한 특정 기준을 사전에 합의하는 것이 좋으며, 우리는 어쨌든 시험해 보아야 한다."좋은 징조"는 편집자의 입사 횟수의 증가일 것이다(통계적으로 유의한 증가가 발견되지 않더라도 편집자 모집 수치가 "소음"일 가능성이 높고, 그 결과로 특정 사용자가 입사하는 일화적인 증거를 유의해야 한다고 제안한다) 또는 지명된 기사가 개선되는 경향이 있다(이에 의해 이루어지더라도).반정규 편집자나 정기 편집자, 그리고 우리는 채용에서 실패한다, 그것은 여전히 플러스 포인트다.)"나쁜 징후"는 지명된 기사들을 조각조각 찢는 것을 포함한다. 이 계획에 대해 어느 정도 받아들여지는 부정적인 것은 그것이 어떤 면에서는 우리의 1면을 떨어뜨리고 우리를 덜 신뢰할 수 있는/전문적으로 보이게 한다는 것이다. 그러나 나는 이 계획이 그것에 미치는 구체적인 영향을 측정하는 방법을 생각할 수 없다.나의 의혹은 메인 페이지에 있는 것들이 종종 부정적인 편집을 끌어들이기 때문에 이 계획이 실패할 가능성이 매우 높다는 것이다.하지만 누가 확실히 말할 수 있을까?많은 웹사이트와 달리, 우리는 그들이 잘 되지 않으면 쉽게 변화를 되돌릴 수 있다; 이곳의 보수주의는 심각한 이득을 제공하지 않는 것 같다.TheGrappler (talk) 01:01, 2009년 9월 18일 (UTC)[응답]
    • 이 제안들은 이미 세 차례나 검토되었다.위키백과:그 주의 협력은 현재 역사적인 것으로 기록되어 있다.만약 당신이 이 아이디어들이 실행 가능하다고 생각한다면, CoTW를 다시 가동시켜라.그 이하의 것은 단순히 다른 누군가에게 그 문제를 해결하라고 요구하는 것이다.G 삼촌 (토크) 2009년 9월 21일 (UTC) 11:06[응답]
• 내 이전 요점과 무관한 의견(재판을 진행해야 한다는 의견)은 어떤 기사를 나열해야 하는지에 대한 문제다.위에서 여러 사용자가 논의한 바와 같이, 다양한 옵션으로 $0.02를 제시하고자 한다.
  • 분명히 1면 근처에는 가지 말아야 할 것들: 두 가지가 떠오른다. 살아있는 사람들의 전기와 논쟁적인 민족주의/종교적/정치적 관점을 끌어들이기 쉬운 어떤 기사.
  • 빈약한 기준의 "바이탈 기사": 프로는 거의 모든 사람들이 전문가가 아니더라도 이것들에 대해 뭔가를 알고 있다는 것인데, 이것은 편집을 장려할 수도 있다.하지만 결국 그것은 문제가 된다. 왜냐하면 대부분의 비전문가 편집은 결국 되돌아가게 될 것이기 때문이다.그렇게 많은 중요한 기사들이 형편없는 상태에 있는 이유는 매우 일반적인 주제에 대한 개요 기사를 구성하고 균형을 맞추는 것이 믿기 힘들 정도로 어렵기 때문이다.가장 좋은 방법은 모든 서브 아티클을 먼저 처리한 다음 이러한 개선 사항을 본문에 엮는 것이라는 것이 널리 제안되고 있다.그것은 또한 그 구조를 올바르게 하기 위해 토크 페이지에 대한 광범위한 계획이 필요할 수도 있다.필자의 비교는 많은 FA들이 메인 페이지에 나열할 때 겪는 선의의 피해에 해당할 것이다; 그들은 대개 "드라이브 바이" 편집에 의해 지나치게 특정한 일반 지식을 무작위로 추가해서 기사의 균형을 왜곡시키는 경향이 있다."토이"와 같은 주제에 관한 복잡한 중요 기사들도 같은 운명을 겪을 것 같다.중요한 물품은 역효과를 일으킬 가능성이 매우 높은 것 같다.
  • 전문가의 주의를 요하는 난해한 기사들: 이 목록에 있는 것을 보는 대부분의 사람들은 그것을 바꾸거나 그것에 끌릴 어떤 방법도 느끼지 못할 것이다.내 생각에 전문가에게는 "와, 실제로 내가 그것에 대해 뭔가를 할 수 있다"는 것이 비례적으로 더 클 수 있다.아마도 비전문가가 구글에서 검색한 정보를 (100% 사실일 가능성이 없음) 추가할 위험성이 있을 수 있는데, 이것은 실제 전문가가 확인해야 하기 때문에 확인하는데 애로사항이 될 수 있다!나는 이것이 일반적으로 물리학, 철학, 경제학 기사와 같은 반복적인 문제라는 것을 알고 있지만, 메인 페이지 캠페인이 상황을 악화시킬지는 확실하지 않다.
  • 주로 형식 지정 문제를 복사/위키화/기타 복사해야 하는 기사:나는 이것이 많은 새로운 사용자들을 위키피디아로 끌어들이는 것이라는 많은 일화를 들었다 - 오타를 교정할 기회는 중독으로 가는 특히 흔한 길인 것 같다 :) 단점에서는 위키 마크업 언어가 편집하기 무섭게 보일 수 있고, 좋은 수준의 위키링크를 판단하기 어렵다.긍정적인 측면에서는, 이것은 실질적인 내용을 추가하는 것보다 더 쉬울 것이다. (특히 그들이 WP:V를 다루고 그리기 어려운 모든 참조 템플릿을 다루는 데 골머리를 앓는 경우)그리고 그것은 토크 페이지에 있는 다른 위키피디아 사람들과의 광범위한 조율이 필요하지 않을 것이다. 이것은 또한 새로운 사용자들이 그들이 5분 후에 되돌아온다는 것을 발견하지 못한 채 단지 그것을 계속할 수 있도록 도울 수도 있다.
• 만약 우리가 3시간 동안 기사를 게재함으로써 충분한 관심을 끌었다는 것을 발견한다면, 우리는 물론 매 2시간마다 회전하면서 다양한 종류의 기사를 시도할 수 있을 것이다.그러나 특정 등급의 기사(예: 보다 광범위한 "Vital" 기사)가 가치보다 더 많은 문제를 야기하는 것처럼 보인다면, 나는 우리가 더 긍정적인 반응을 보이는 유형들에 초점을 맞출 것을 제안한다.TheGrappler (talk) 01:01, 2009년 9월 18일 (UTC)[응답]
• 나는 몇 가지 이유로 반대한다: 첫째, 나는 우리가 가능한 한 자주 독자층이 편집 작업과 분리되도록 노력해야 한다는 것에 동의한다.둘째로, 우리는 메인 페이지에 우리의 최고 품질의 작품을 홍보해야 한다. 나는 우리 독자들 사이의 참여를 장려하는 것에 전적으로 찬성하지만 메인 페이지는 우리의 "Featured 쓰레기"에서 벗어나야 한다.마지막으로, 나는 이것이 DYK에게 복제된 것처럼 보인다는 것에 동의한다.선의의 제안이고 의심할 여지 없이 합리적인 제안이지만, 나는 이것이 잘 먹힐 것이라고 생각하지 않는다.–줄리안콜튼 02:32, 2009년 9월 18일 (UTC)[응답]
• 지원 우리는 더 많은 더 나은 채용이 필요하다.사람들은 어떤 추상적인 의미에서 편집이 가능하다는 것을 알고 있지만, 나는 그들이 지금 당장 특정한 것에 대해 도움을 줄 수 있다고 생각하지 않는다.이 제안이 아직 여러 번 나왔고 항상 실패했기 때문에 좀 놀랍긴 하지만, 그 뒤에 다시 지지를 보내겠다.(최소한 지금 시범적으로) 캘리오페젠1 (대화) 13:50, 2009년 9월 18일 (UTC)[응답]
• 반대 1면에 편집이 필요한 기사를 싣는 것은 거의 즉시 수백 개의 편집이 일어나게 할 것이다.이렇게 하면 기사 편집이 거의 불가능해진다.이것은 끊임없는 편집 충돌과 엄청난 양의 쓸모없는 내용을 야기시킬 것이다.20-30개의 "당신의 도움이 필요한 미술관"이 1면 리스트에 나와 있지만, 그것을 가지고 있는 것은 말도 안 되는 일이다. --에어랜드 (토크) 18:26, 2009년 9월 18일 (UTC)[응답]
• 논평 - 나는 한 기사의 선택이 생산적이지 않을 것이라고 생각한다 - '피디아'는 현재 너무 크고, 많은 일반화된 정보가 추가되었다.WP를 참조하십시오.같은 맥락에서 작용하거나 작용하지 않는 산.그래서 나는 특정 기사에는 반대하지만 '도움이 필요한 미술관'이라는 태그가 붙어 있는 무작위 기사(확장, 리폼 스텁(stub) 및 위키나 범주화되지 않은 특정 위키 지식이 필요하지 않은 다른 것 중에서 선택됨)에 대한 링크를 지지한다.캐스리버 (토크 · 기여) 21:36, 2009년 9월 18일 (UTC)[응답]
• 강한 지지 나는 그것을 좋아한다.그리고 나는 "우리의 가장 좋은 기사들을 제시하는" 주장에 동의하지 않는다.편집자를 더 뽑아야 하는데, 이게 최선의 방법이야.또한, 내가 제안서를 연장할 수 있다면, 우리는 그 섹션을 하위섹션(과학, 예술 등)으로 나누어 더 많은 현지 관심사를 가진 사람들을 유치할 수 있을 것이다. ((Δ)² 17:15, 2009년 9월 19일 (UTC)[응답]
• 강력한 지원으로 독자들 중 몇 명을 편집자로 만들 수 있을지도 몰라!이킵 (대화) 06:58, 2009년 9월 20일 (UTC)[응답]
• "캐주얼한 독자를 혼동하지 말라"는 것부터 시작해서 이미 충분히 반대했다."누구나 편집할 수 있다"는 메시지는 여전히 존재하며 목적에 잘 부합한다.NVO (대화) 2009년 9월 20일 16:25 (UTC)[응답]
• 특히 기사 개선으로 귀결될 때, 새로운 편집자들을 끌어들이는 데 대한 지지는 좋은 생각처럼 보인다.나는 그러한 제안의 좋은 점들이 해결되어야 할 것이라고 확신한다. 하지만 적어도 시도해 볼 만한 가치가 있는 좋은 믿음의 아이디어.위키피디아는 마감일이 없기 때문에 적어도 회람을 해서 손해볼 것은 별로 없다.베스트, --A Nobody^{My talk} 02:19, 2009년 9월 21일 (UTC)[응답]
• 지원, 사람들이 기여하도록 격려하는 것은 우리의 임무에서 중요한 부분이다.메인 페이지에 '편집' 링크가 생긴 지 오래다. 이렇게 하면 그 정신이 조금 되살아난다. +sj+04:46, 2009년 9월 26일 (UTC)[응답]

6을 깨뜨리다

• 주요 사이드바에 '도움이 필요한 무작위 기사'를 두는 것이 실용적이지 않다면, 다른 곳에서도 비슷한 것을 가질 수 있을까? 예를 들어 다양한 '범주:'...' 페이지가 필요한 위키백과 기사?적절한 태그가 고안되고 'xxxx의 주제 목록(선택 주제 삽입)'이 있다면, 주제 영역에서도 유사한 배열이 이루어질 수 있다.

카테고리 페이지의 긴 목록은 사람들이 추구하는 것을 단념시킬 수 있다.2009년 9월 21일 16:27(UTC)

• 지지하다.이건 정말 좋은 생각이야. 시험 삼아 해 봐!대담하게 행동해라 벌써누가 가서.만약 그것이 잘 되지 않는다면, 그렇게 하겠지만, 왜 결과를 예측하기 위해 많은 시간을 허비하는가, 간단한 실험이 우리에게 바로 보여 줄 것이다.HiDrNick! 2009년 9월 21일 19:25 (UTC)[응답]

• 다양한 '주제별 협업' 목록과 유사한 목록을 추가한다.'이 범주에 도움이 필요한 임의의 기사 선택' 상자 링크나 페이지 하단에 하위 제목이 있는 것이 가장 도움이 필요한 페이지를 보다 적극적으로 처리하도록 권장하는 데 더 적절할 수 있다.적절하게 고안된 (목록 페이지 등) 경우, 응답을 통한 속임수만 있더라도 보유하는 것이 적절할 수 있다.재키스펠 (대화) 2009년 9월 23일 (UTC) 10:37[응답]

• 반대 - 이미 모든 사람들이 이미 무시하는 협업이 충분히 많다.다른 것을 추가하는 것은 오히려 생산성에 역행하는 것이다.메인페이지에 올려놓으면 그냥 바보같을거야. --T-rex 02:41, 2009년 9월 25일 (UTC)[응답하라]

• 지지 - 지금 우리는 편집자가 되기 위해 더 많은 평범한 독자들이 필요하다. 그리고 나는 이것이 단지 그것을 하기 위한 훌륭하고, 두드러지고 매력적인 방법이라고 생각한다.조스맥 05:40, 2009년 9월 28일 (UTC)[응답]
• 지원 – 중요하지만 현재 빈약한 기사를 확실히 내놓는다면, 이것은 정말 긍정적인 일이 될 수 있다.게다가, 나는 우리가 위키피디아의 협력적이고 올인된 모델에 대해 독자들과 마주치는 것을 피해야 한다는 생각은 독성이 있다고 생각한다.우리는 교착상태에 빠져서는 안 된다. 오히려 우리는 모든 독자들의 참여를 모집하고 부추기려고 노력해야 한다.—Anonymous Dissident^Talk 14:49, 2009년 9월 30일 (UTC)[응답]
• 지원 좋은 아이디어!위키피디아는 불완전/정확하지/불확실하다는 이유로 언론에서 계속 비난을 받고 있고 사람들은 때때로 '페디아'를 편집하는 것이 공동체의 일이라는 것을 잊어버린다.지역사회를 불안하게 하는 것은 무엇이든 좋은 일이다.한 가지 주의사항: "개선할 조항"에서는 절대 BLP가 되어서는 안 된다. 왜냐하면 그것은 새로운 사람들이 이해하기 힘든 것이고 단지 소송을 요구하는 것이기 때문이다.--24.131.95.3 (대화) 17:26, 2009년 10월 5일 (UTC)[응답]
• 강력한 지원 - 통합된 협업 노력은 멋진 아이디어인데, 이를 메인 페이지에 올리면 이전의 전체 위키피디아 협업 노력보다 실제적으로 더 빨리 그라운드를 벗어날 수 있을 것이다.--Unionhawk 18^E-mailReview:26, 2009년 10월 5일 (UTC)[응답]
• '강력한 지원* - 이것은 멋진 생각이다! 나는 질이 나쁜 많은 물건들이 있고 이것이 큰 도움이 될 것이라고 말한 다른 사람들의 말에 동의한다!또한, 나는 더 많은 위키 사용자들이 로그온해서 그들이 개선하고자 하는 것에 관심을 갖는 것을 찾는 것이 전부라면 쓰도록 장려될 것이라고 생각한다! :) —Malone94에 의해 추가된 서명되지 않은 코멘트 준비 (대화 • 기여) 2009년 10월 9일 08:40, 08:09
• 강력한 지원 더 많은 편집자들이 좋다.mkehrt (대화) 09:09, 2009년 10월 9일 (UTC)[응답하라]
• 자격을 갖춘 지원:나는 이것이 유망한 아이디어라고 생각하며, 워치리스트(내가 시작하는 곳), 신간 기사 등보다는 독자들이 보는 것과 같은 메인 페이지를 보는 것이 이따금씩 편집자들을 유혹하는 역긍정적인 효과를 가져올 수 있을 것이라고 생각한다.(홍보상의 시사점에도 불구하고) 개선을 위한 기사를 선택하는 가장 좋은 방법은 그날의 특집 기사와 밀접한 관련이 있는 기사를 선택하는 것이라고 생각한다.가상적인 예로서(그리고 실제 기사들을 전혀 모르는 상태에서) 플로렌스 나이팅게일(크리만 전쟁의 간호 선구자)이 피처링 기사였고 클라라 바튼(미국 남북전쟁에서 시작된 미국 적십자 설립자)이 모든 종류의 도움이 필요한 가치 있는 기사였다고 가정한다. (또는 역 저자)논문).그러면 '피쳐링' 여주인공에게 매료된 독자(또는 간호와 공중 보건에 대해 이미 알고 있는 사람)가 상대방의 기사에 어떤 기여를 할 수 있는지를 보고 영감을 받을 수도 있을 것이다.내가 덧붙이고 싶은 한 가지 큰 주의사항은 가능성이 있는 기사의 토크 페이지에 공정한 경고가 있어야 하며, 만약 두세 명의 주요 이전 편집자들의 신원이 명확하다면, 그들은 개인적인 통지도 받아야 한다는 것이다.단조롭고, 서투르게 쓰이거나, 양손잡이로 글을 쓸 수 있을 만큼 열심히 정리한 후에, 그 어떤 것도 갑자기 많은 낯선 사람들이 그것의 최고의 의도와 함께 그것의 과거 역사에 대해 거의 알지 못한 채 일제히 그 위에 내려오도록 하는 것만큼 사기를 떨어뜨리는 일은 없을 것이다.PR의 의미(또는 Puting One's Best Foot Forward)에 대해서는, 나는 이것이 위키피디아의 가장 좋은 특징들이 어떻게 처음부터 구축되어 자랑하지도, 자기 자랑도 하지 않고, 자기 자랑도 하지 않고, 자기 홍보도 하지 않는, 정직하고 솔직한 방법일 것이라고 생각한다.—— Shakescene (대화) 09:37, 2009년 10월 9일 (UTC)[응답]
• 자격 있는 지원.원칙적으로는 이게 좋은 생각이라고 생각하지만, 편집(편집증)을 하는 자신들 스스로 넘어질 수 있다는 반대는 타당하다.그래서 그것을 피하기 위해서는 충분히 숙고된 방법으로 할 필요가 있을 것이다.예를 들어, 개선되어야 할 조항들의 매일 풀이 있을 수 있는데, 이 풀들은 기사들 간에 편집이 확산될 정도로 빠르게 회전한다.(캐슁 중단과 같은 기술적인 문제가 있을 수 있음; 구현 시 우리가 무엇을 제안할 수 있는지에 따라 달라짐)PS가 기존의 협업 노력을 복제할 것이라는 반대는 전혀 다른 청중으로 보인다.Rd232 09:42, 2009년 10월 9일 (UTC)[응답]
• 지원 I love this ides —Tim1357 (talk • 기여) 19:53, 2009년 10월 10일, 서명되지 않은 코멘트
• 논평 - 이것은 좋은 생각처럼 들리지만, 고려해야 할 몇 가지가 있다.위키피디아의 정규 참여자들은 그 목표와 내공을 알고 있지만, 평균적인 shmo는 단서가 없다.믿기 힘들겠지만, 대부분의 사람들은 위키피디아가 완제품이라는 인상을 받고 있다.자주 읽는 많은 독자들도 백과사전을 편집할 수 있는 능력이 있다는 사실을 여전히 모르고 있다.이것이 우리가 언론에서 우리의 기사 품질에 대해 많은 비난을 받는 이유 중 하나이다.위키피디아는 널리 오해를 받고 있는 동물로, 우리가 무엇을 하든 항상 그럴 것 같다(아무나 편집할 수 있는 백과사전이라는 슬로건까지 만들려고 했는데, 그것조차 제대로 먹히지 않았다).메인 페이지를 편집자가 아닌 순수한 독자들의 숙소로 만들기로 한 결정은 이러한 대중의 인식을 다루는 한 방법이다.우리는 대중들이 우리를 신뢰하지 않고 아마추어적이라고 비난하지 않도록 최선을 다해 대중에게 얼굴을 내밀려고 노력한다. 결과적으로, 이것이 제안서에 따라 메인 페이지를 바꾸는 것에 대한 저항이 있는 이유다."우리" (위 위키피디아의 대중적 이미지와 관련된 사람들) 모두가 반드시 "막장 뒤에서" 즉시 보는 것을 원하는 것은 아니다. 왜냐하면 대부분의 사람들은 의심할 여지 없이 과거에도 그랬듯이 이해하지 못할 것이기 때문이다.이 제안의 전제조건은 훨씬 더 큰 변화다.그것은 대중들에게 다른 얼굴을 하고 있을 것이다.그것에 대한 찬반 양론은 신중하게 따져봐야 이것이 시행될 것이다.Equazcion (대화) 2009년 10월 10일 (UTC) 20:25 [응답]

7을 깨다

• 반대 - 몇 가지 이유로: 1) 메인 페이지는 우리의 최고의 작품을 강조해야 한다; 2) 기사는 무작위로 선택되거나 어떤 종류의 선택 과정을 거쳐야 한다.만약 전자라면, 우리는 결국 주목할 수 없는 주제나 모호한 주제를 홍보할 수 있을 것이다.나중에 어떤 기사를 개선해야 할지를 결정하는 데 노력을 낭비하는 것보다는 그저 기사를 개선할 수 있을 것이다; 3) 성공한다면, 몇 가지 부족한 기사들 사이에 노력이 가장 잘 전파될 때 같은 기사를 "개선"하려는 사람들이 많을 것이다.또한 잠재적으로 분쟁 편집, 전쟁 편집, 그리고 새로운 기사를 꺼낼 수 있는 다른 불쾌감을 야기할 수 있다; 4) 그 페이지는 반비보호되어 독자를 편집자로 전환하려는 요점을 오히려 물리칠 수 있을 것이다: "이 기사 편집을 도와달라...끈질긴 반달리즘 때문에 반보호를 해야 했기 때문에 못하시는 것 외에는." --ThaddeusB (대화) 20:38, 2009년 10월 10일 (UTC)[응답]

• 아주 잘 말했고, 전적으로 동의해.–Juliancolton 00:54, 2009년 10월 12일 (UTC)[응답]

• 나는 당신이 방금 꺼낸 잠재적인 문제들 대부분이 각 페이지 요청으로 인해 다른 기사(또는 페이지 요청이 다른 기사들에 대해 분할되는 경우)로 귀속된다면 실제 문제가 되지 않을 것이라고 생각한다.또는 다음과 같이 작동하는 로봇을 가질 수 있다.기사 X1을 메인 페이지에 놓아라. 그 때 몇몇 다른 편집자들이 편집(예를 들어, 논쟁을 위해서 10)을 할 때까지, X2는 10명의 다른 편집자들로부터 편집을 받을 때까지 새로운 기사 X2를 메인 페이지에 넣는다.지오메트리걸 (토크) 14:38, 2009년 10월 12일 (UTC)[응답]

• 난 그 봇 아이디어가 좋아, 좋은 생각이야.타드데우스의 다른 점들에 대해서는, 우리가 순수하게 최고의 작품을 선보여야 하는지가 논의되고 있는 질문들 중 하나이다.우리가 계속 그렇게 해야 한다고 말하는 것만으로는 그 문제를 해결할 수 없다.사람들은 아마도 그 전통에서 벗어날 수 있는 몇 가지 적절한 이유를 제공했다.기사가 일시적으로 메인페이지에 머무른다면 그 과정은 큰 과정이 될 필요가 없다.봇은 필요한 복사나 스텁과 같은 유지보수 범주에 따라 기사를 선택할 수도 있고, 확증된 사용자들이 마음대로 편집할 수 있는 목록이 있을 수도 있다.Equazcion (talk) 05:22, 2009년 10월 14일 (UTC)[응답]

• "메인 페이지는 우리의 최고의 작품을 강조해야 한다." — 근본적으로 이에 동의하지 않으며, 메인 페이지는 우리가 하는 일을 강조해야 한다.우리는 물건을 개량한다.알렉스 뮬러 09:45, 2009년 10월 15일 (UTC)[응답]

• 질문 이것은 하루 종일 메인 페이지에 남아 있는 특집 기사 또는 각 페이지 요청에 따라 다른 임의의 기사일 것이다.하루 종일 메인 페이지에 있는 경우, "임의"가 아니라 "특집 기사"가 선택되는 방식으로 많이 선택되어야 한다.Tim1357 (대화) 2009년 10월 10일 (UTC) 20:48 [응답]

• 반대 메인 페이지는 "읽기 대상" 페이지다.일차적인 목적은 외부인들을 위해 백과사전에 웃는 얼굴을 붙이는 것이다.독자가 아닌 편집자만을 위한 특색을 추가하는 것은 이 은유를 강한 목적 없이 깨뜨리는 것이다.'독서자'와 '편집자'의 구분이 결정적으로 명확하지는 않지만, 부인할 수 없는 구분이 있다는 것을 기억해야 한다.백과사전을 읽는 대다수의 사람들은 편집하지 않고 편집에 관심이 없으며, 그것은 좋은 일이다.백과사전은 바로 그 사람을 위한 것이다.APL (토크) 22:23, 2009년 10월 14일 (UTC)[응답]
  • 하지만 위키피디아의 핵심은 누구나 편집할 수 있는 백과사전이라는 것이다.독자들은 아직 발을 적시지 않은 편집자들일 뿐이고, 우리는 항상 더 많은 것을 필요로 한다.그리고 1면에 "향상을 위한 작은 기사"를 추가하면 정말로 웃는 얼굴을 빼앗을 수 있을까?무엇보다도, 우리는 독자들에게 위키피디아의 편집 가능한 본질을 상기시켜야 하며, 이것이 도움이 될 것이다.Rd232 09:58, 2009년 10월 15일 (UTC)[응답]

• 지원 메인 페이지는 프로젝트 전체를 반영해야 하며, 그것이 불완전한 자원임을 자유롭게 인정해야 한다.새로운 편집자들이 출발할 수 있는 자리를 마련해 줄 것이다. --Pretzels^Talk! 14:11, 2009년 10월 22일 (UTC)[응답]
• 타드데우스B에 대항하라.또한, DYK에서의 나의 경험은 하루에 1만 건의 조회수를 얻는다고 해도 기고자나 새로운 편집자를 끌어들이는데 거의 아무런 도움이 되지 않는다는 것을 보여준다. 그리고 나는 이 또한 그럴 수 있을지 의심스럽다.YobMod 12:37, 2009년 10월 29일 (UTC)[응답]

서브프로포졸

• 위의 논의에 참여하면서, 대안으로 다음 사항을 제안한다.단 1시간의 평가판을 위해 적절한 등급의 기사를 1면에 각각 1분씩, 개선이 필요한 항목으로 임의로 작성하십시오.영향을 평가하고 거기서부터 시작하십시오.문제는 적절한 종류의 기사를 식별하는 것이지만, 오래된 미식별 기사들은 괜찮다.일어날 수 있는 최악의 상황은 무엇일까?만약 그것이 괜찮다면, 하루 정도 더 긴 실험을 개발하십시오.빨아서 봐, 내가 말한다.Rd232 09:51, 2009년 10월 14일 (UTC)[응답]

• 지오메트리걸(토크) 13:06, 2009년 10월 14일 (UTC) 동의[응답]
• 동의 - 좋은 생각.Equazcion (대화) 2009년 10월 14일 (UTC) 23:00[응답]

• 질문 WP에서 실험은 어떻게 수행되는가?만약 그것이 재판을 위해 올라가지만, 그것을 제거하기 위한 합의가 이루어지지 않는다면?갑자기 강력한 공감대가 없었던 특징이 추가돼 쉽게 제거될 수 없다.APL (토크) 22:23, 2009년 10월 14일 (UTC)[응답]
  • 재판이기 때문에 아마도 재판의 미리 정해진 종료 시점에 제거될 것이다.재판이라는 사실에는 재판의 결론에 따라 없애자는 공감대가 암묵적으로 담겨 있다고 생각한다. --사이버코브라(토크) 23:13, 2009년 10월 14일 (UTC)[응답]
    • 바로 그거야그것은 정의된 길이의 재판으로, 재판이 평가되는 동안 그 이후의 현 상태로 되돌아가게 된다.Rd232 10:00, 2009년 10월 15일 (UTC)[응답]
• 내가 상기에 반대하는 것과 같은 이유로 나는 이것을 반대한다.나는 그것이 일종의 흥미로운 영향을 미칠 수 있다는 것을 의심하지 않는다. 나는 그것이 본지가 외부인들에게 미치는 전체적인 영향을 줄일 것이라고 믿는다.재판은 어떻게든 도움이 되지 않을 것이다.APL (토크) 22:23, 2009년 10월 14일 (UTC)[응답]
  • 그냥 시험일 뿐이야.한번 시도해 보고 사람들이 어떻게 생각하는지 보는 게 어때?Equazcion (대화) 23:05, 2009년 10월 14일 (UTC)[응답]

• 지원 편집 참여를 유도하려는 목적이 우수하며, 메인 페이지는 이를 위한 좋은 장소다.그러나 이를 위한 좋은 구조가 있어야 하이라이트된 기사가 선의의 신인들이 너무 많이 몰리는 것을 막을 수 있다.각 후보 기사를 잠깐씩만 공개한다는 발상은 좋은 생각이다.또 다른 가능성은 마스터 클래스 - 하나 이상의 전문 편집자들이 우리의 방법의 살아있는 예로서 선택된 기사를 작업하는 시연이다.인용문, 이미지, 카테고리 등과 같은 중요한 편집 기술을 시연할 뿐만 아니라, 마스터 팀도 편집 요약의 사용, 토크 페이지, 좋은 기사 리뷰 등과 같은 우리의 협업 방법을 시연할 수 있었다.해설자가 진행 중인 일을 설명하는 사이드바도 있을 수 있다.그러한 시위는 특별한 행사로 조직될 수도 있고, 자원봉사자가 충분할 경우 계속적으로 실행될 수도 있다.워든 대령 (대화) 23:32, 2009년 10월 19일 (UTC)[응답]

• 위키피디아에 새로운 문구를 추가하는 것처럼 들린다.커뮤니티 포털/오펜타스크 및 위키백과의 혼합에서 제안된 내용:기사 협업 및 개선 드라이브 및 위키백과:위키프로젝트 바이탈 기사(B급?)코드를 만들어 거기서 테스트해 보십시오. -- Quidity (토크) 07:55, 2009년 10월 23일 (UTC)
• 지지하다.'나는 일반적인 생각에 반대하지만, 증거로 확신할 수 있을 것이다.알아낼 수 있는 유일한 방법은 노력하는 것이다.하지만, 나는 1면에 한 시간 동안 침을 뱉고 24시간 동안 그것을 만들 것을 제안할 것이다.1분은 매우 짧다!YobMod 12:38, 2009년 10월 29일 (UTC)[응답]

문제

이 긴 줄기에서 놓쳤을지도 모르지만, 나는 몇몇 후기 제안들에 대해 몇 가지 문제점을 발견한다.메인 페이지에 나타나기 위해서, 사람들은 (DYK나 FA와 같이) 블럽을 써야 하고, 다른 사람들은 블럽에 동의해야 하며, 그리고 나서 그것은 메인 페이지에 올라간다(이것이 승인된 블럽들의 풀에서 무작위로 행해지든지, DYK와 같이 고정된 포맷으로 행해지든지 간에).이 모든 것을 하는 데 필요한 시간은 실제로 기사를 개선하는 데 더 잘 사용될 수 있다(위, 비식별 기사의 예: 단순히 위키화하는 것만이 기술된 과정보다 더 오래 걸리지 않는다).또한 선택할 수 있는 문서 풀이 있는 경우 충분히 개선된 문서를 제거하기 위해 디풀 프로세스도 필요하다는 것을 기억하십시오.

메인 페이지에 있는 글의 첫 단락을 어떻게든 초월하는 것과 같은 어떤 다른 시스템도 기물 파손으로부터 메인 페이지를 보호하지는 않는다.그리고 페이지를 포텍하면 더 이상 편집할 수 없어 연습의 목적이 무효화된다.프람 (대화) 09:56, 2009년 10월 15일 (UTC)[응답]

좋은 지적이지만 해결책이 있을 수 있다.본 조항은 모호하지 않고 페이지 이름만 기재할 수 있으며, 적절한 일반 제목 + "이것은 무엇인가/무엇을 하는가/어떻게 하는가" 소개서에 기재될 수 있다.그리고 표준 유지보수 범주를 기준으로 선택할 경우 개선 후 태그를 제거하면 지원자가 감퇴할 수 있다.Rd232 12:30, 2009년 10월 15일 (UTC)[응답]

기본 페이지 문서 편집 - 재부팅

위의 장시간에 걸친 토론은 메인 페이지에 "편집할 문서"가 있다는 생각에 대해 엇갈린 견해를 낳았다.이 토론은 긴 모든 것을 재탕하기를 바라지 않고, 몇 가지 논점을 만들어 냈는데, 이 아이디어는 좀 더 발전된 것으로서, 삼탕할 만한 가치가 있는 것을 만들어 낼 수도 있다.

이 일을 만드는 방법을 알아내는 것의 이점: a) 자신이나 회사에 대한 기사를 만들고자 하는 이해 상충에 의해 결정되지 않는 경로를 통해 더 많은 사람들을 편집자로 참여시키고, b) 위키백과가 어떻게 작동하는지 독자들에게 더 명확하게 전달한다.그렇다, 어떤 사람들은 "누구나 편집할 수 있는 무료 백과사전"이 정말로 무엇을 의미하는지 아직도 약간 모호하다.음, 네.)

위에 그림을 그리면서, 그 아이디어에 대한 짧고 확실히 임시적인 재판을 제안한다, 다음과 같은 형식이다.

1. 1시간만 시행해도 결과가 더 이상 나타나지 않는 한 더 이상의 조치는 취하지 않는 것이 좋다.
2. 편집해야 하는 일부 문서(또는 이와 유사한 문서) 섹션 추가
3. 이 섹션에서는 섹션의 용도에 대한 간략한 소개와 적절한 도움말 페이지 링크를 제공하십시오(기사가 필요로 하는 도움말이 무엇인지에 따라 다름).
4. 아마 5개의 기사를 나열해봐 페이지 이름만 적어줘, 흐릿하지 않게.
5. 노출을 관리할 수 있도록 1분 동안 5개 항목의 각 항목을 나열하십시오.
6. 표준 유지 관리 범주(예: 범주:복사가 필요한 위키백과 기사
7. 편집자가 충분한 개선을 보고 적절한 유지 관리 태그를 제거하면 기사는 자동으로 회전에서 제거된다.
8. 이러한 방식으로 메인 페이지에 나열된 기사는 목록(또는 날짜의 유지 관리 범주에 있을 수 있음)에 기록되어 기성 편집자가 24-48시간 동안 목록을 작성한 후 결과를 검토할 수 있다.

결정적으로, 이 버전에서 주요 추가 작업부하는 지속적이기보다는 설정이다. 즉, 작업할 유지보수 범주를 선택하고(페이지 당이 아닌 유지보수 작업당) 어떤 표준 인트로를 만들고, 기사를 선택/회전할 적절한 봇을 만드는 것이다.음, 나는 공공 기물 파손 후의 청소와 편집 확인에 수반되는 추가 업무량을 무시하는 것이다. 왜냐하면 그것은 대부분 새로운 프로세스가 아니기 때문이다. 최근 변경사항의 적용을 받으며, 최근 변경사항 순찰대가 이러한 (간단히) 높은 트래픽 페이지에 있는 것들을 놓치지 않도록 하기 위한 추가적인 메커니즘(목록/카테고리)을 가지고 있다.댓글?Rd232 16:50, 2009년 10월 22일 (UTC)[응답]

그것이 메인 페이지에 오르기 위해서는 어딘가에 그것을 맞추고 메인 페이지 디자인이 여전히 일반적인 브라우저/화면 해상도 구성에서 잘 보이도록 하기 위해 상당한 양의 작업이 필요할 것이다.짧은 평가판의 경우, 페이지를 추가하기 위한 공식 프로세스에 대한 설정의 일부를 제외한 모든 설정 작업을 수행해야 한다(따라서 작업의 약 75% 이상).나는 1시간 재판으로 얻는 이익의 양이 실제로 그것을 세우기 위해 필요한 일의 양을 정당화한다고 생각하지 않는다.게다가, 우리가 여러 번의 실험을 하는 동안 메인 페이지에서 나타나고 사라지는 섹션은, 성공적이면, 공식적인 과정을 만들어 내는 것이 독자들에게 혼란스럽고 짜증날 수 있다.Mr.Z-man 17:51, 2009년 10월 22일 (UTC)[응답]

나는 그 일에 대해 당신의 주장을 받아들이지만, 그것은 위험을 무릅쓸 가치가 있을지도 모른다 - 그리고 만약 우리가 약간의 노하우를 가진 사람들을 구한다면, 그것은 그렇게 많은 일이 아닐지도 모른다. (어쨌든, 재판이 잘 되어 궁극적으로 실행으로 이어진다면, 잠재적인 이익 때문에, 그것을 하는 것을 정당화할 수 있다.)디자인에 관해서는, 전혀 작업이 필요하지 않다. 단지 "오늘의 특집 사진" 형식을 잘라서 복제할 뿐이다.적어도 재판할 정도는 됐지겠지.그리고 웹 페이지를 조금만 바꾸면 최종 사용자들을 짜증나게 할 것인가?스트레칭이네.그리고 재판에서는 그렇게 많은 사람들에게 영향을 주지 않을 것이다.Rd232^talk 20:50, 2009년 10월 22일 (UTC)[응답]

전폭 구간을 갖고 싶다면 한 번에 몇 개의 기사를 넣을 계획인가?피처링된 사진은 피처링된 기사보다 더 많은 공간을 차지한다.그것은 그들을 성가시게 하지 않을 수도 있지만, 아마도 여러 번, 새로운 섹션이 나타났다가 없어지는 것은 분명 혼란스러울 수 있다.메인 페이지는 보통 하루에 5-7백만 건의 조회 수를 기록하기 때문에 1시간 동안 20만-290000명의 사람들이 1시간 재판을 볼 수 있다.미스터Z맨 02:18, 2009년 10월 23일 (UTC)[응답]

글쎄, 나는 그것에 많은 무게를 두기가 어렵다는 것을 알아. 왜냐하면 웹사이트는 항상 바뀌기 때문이고, 우리는 단지 한 번의 시험만 얘기하고 있고, 아마도 한 두 번의 시험만 더 이야기 하고 있을 뿐이고, 그것이 영구적이 되기 전에 더 긴 시험만 얘기하고 있기 때문이지.웹사이트는 항상 변하는데, 이것은 극적인 변화가 아니다."전폭" 포인트에 대해서는 - 위에서 5개 기사를 말했는데, 섹션에 대한 설명과 편집에 대한 도움 /요약 링크를 통해 나머지 폭을 차지할 것으로 기대했다.공간이 너무 많은 경우 두 개의 열로 분할하여 두 가지 유형의 유지 관리 범주별로 하나씩 유지 관리하십시오.Rd232 02:26, 2009년 10월 23일 (UTC)[응답]

페이스북이 5번째 홈페이지 레이아웃을 변경해 2억5000만 사용자 모두에게 영향을 미쳤다.상위 10개 웹사이트는 월별로 외관을 바꾼다.우리의 메인 페이지는 2006년 3월 이후 4년 동안 크게 바뀌지 않았다.위키피디아는 훨씬 더 기꺼이 새로운 레이아웃으로 실험할 필요가 있다.RfA와 마찬가지로 메인 페이지도 전면 개편이 필요하다는 데는 많은 사람들이 동의하지만 완전히 새로운 시스템에 대해서는 누구도 동의할 수 없다.그 교착상태를 타개하는 자연스러운 방법은 작은 변화를 시도해서 무엇이 효과가 있고 무엇이 효과가 없는지를 보는 것이다.Rd232가 그러한 특징을 준비하기 위해 작업에 투입할 준비가 되어 있다면, 관련된 노력을 그것에 반대하는 주장으로 사용하는 것은 전적으로 부정적이다.해피멜론 11:21, 2009년 10월 25일 (UTC)[응답]

페이스북의 인터페이스 변화 중 몇 가지가 이 뉴스를 매우 싫어한다는 이유로 만들었기 때문에 아마도 페이스북은 좋은 예가 아닐 것이다.나는 Rd232가 관련된 디자인 작업이 무엇인지 모르고, 현재 "오늘의 특집 사진" 형식만 잘라서 복제할 것을 제안하고 있는 것이 더 걱정된다. 시험해 보기엔 충분해" - 나는 여기 있는 대부분의 제안이 쉬운 것들, 특히 아래에 새로 추가된 리스트에 초점을 맞추고 있는 것이 걱정스럽다.독자들이 보는 섹션의 디자인과 결과의 검토라는 두 가지 가장 중요한 것은 거의 아무런 고려도 받지 않고 있다.Mr.Z-man 17:55, 2009년 10월 25일 (UTC)[응답]

그림 섹션은 세 개의 중첩된 HTML 테이블로 구성된 세트다.그 세트를 복제하는 것은 페이지의 나머지 부분에 연쇄효과를 가져서는 안 된다.또한 이러한 표 중 하나를 두 개의 열로 분할(또는 다른 중첩 테이블을 현재 가장 안쪽 열에 추가)하여 문제가 발생해서는 안 된다.별일 아니겠지.사후 검사의 경우:나는 그것을 가능하게 하기 위해 영향을 받는 기사들의 리스트를 만들도록 명기했지만, 그 이상, 나는 왜 내가 앞서 토론에서 수십 명의 사람들이 논평했을 때 그 모든 다리 작업을 해야 하는지 모르겠다.개인적으로, 나는 이것이 사전에 명시될 필요가 없다고 생각한다; 눈길 한번 보는 것으로 효과에 대한 일반적인 인상을 주는 것으로 충분할 것이다.상세 분석(자동화 필요)은 데이터의 양이 너무 많기 때문에 더 늦고 더 긴 평가판을 위해 필요할 것 같다.Rd232^talk 18:11, 2009년 10월 25일 (UTC)[응답]

위키피디아 사람들은 주의력이 다소 짧은 경향이 있다.제안 토론에 대해 의견을 개진하는 10명당 1명꼴로 최초 제안서를 통과한다.위키피디아에 대한 재판은 영구화 경향이 있어 구체적인 계획 없이 제안된 재판을 경계할 수도 있다는 점도 쟁점이다.2009년 10월 25일 Mr.Z-man 18:19 (UTC)[응답]

네, 뭐...후반부에서는 어떻게 여기서 제안된 것이 영구적으로 될 위험이 있는지 알 수 없다."영구화" 문제는 소프트웨어 사물이 켜지는 것에 더 가깝고, 어떤 상황/시간 틀에서 다시 꺼질지 충분히 명확하지 않다.Rd232 10:19, 2009년 10월 26일 (UTC)[응답]

글쎄, 그렇게 많은 일은 아니잖아.

• 섹션에 대한 흐림(개선 조항 설명)
• 유지보수 범주 선택
• 두 가지 유지보수 범주 각각에 대한 흐림(무엇/방법/도움말 링크)
• 봇은 60초 동안 해당 섹션을 업데이트하고 섹션당 임의로 5개(이전 선택 항목 제외)의 기사를 가져오고, 목록에 있는 기사를 하위 페이지에 메모한다.
• 담당자가 섹션을 만들고 한 시간 동안 봇을 실행한 다음 섹션을 삭제하십시오.
• 사후 검시.

그런 봇을 하는 것은 쉬워야 하고, 다른 사람들도 다룰 수 있을 거라고 확신해.AFAIK에 대해 논의되지 않아 별 문제가 아닐 수도 있는 나를 실제로 괴롭히는 문제는 그러한 빈번한 업데이트가 캐싱과 어떻게 상호작용하는가에 관한 것이다.Rd232 12:41, 2009년 10월 25일 (UTC)[응답]

나는 메인 페이지를 변경하기 위한 더 쉬운 과정이 필요하다는 것에 대해 해피 멜론의 의견에 동의한다.그리고 rd232의 1시간 재판을 한다는 생각은 해볼 만한 가치가 있는 것 같다.나는 실험이 끝난 후에 어떻게 될지 알고 싶다.성공의 기준은 미리 정해야 하는가?비교가 가능하도록 나열되지 않은 페이지의 제어 그룹이 있어야 하는가?시험이 끝났을 때 어떻게 해야 할지 고민해야 할 때가 되면 더 우유부단하게 될 뿐이라면 시험을 진행해도 별로 의미가 없다.--RDBury (대화) 16:32, 2009년 10월 29일 (UTC)[응답]

나는 관여하지 않았지만, 몇몇 사람들은 메인 페이지에 특집 기사를 보호받지 못한 경험이 많다.그 효과를 평가하려는 노력이 있었을 것이다.메인 페이지 토크 페이지에 크로스 포스트를 붙여야 할 것 같아.Rd232 17:21, 2009년 10월 29일 (UTC)[응답]

2010년 중재위원회 구조

나는 2010년 중재 위원회의 규모와 조건에 대한 RFC를 시작했다.다가오는 선거가 시작되기 전에 확실한 의석수를 정하려면 지금 투표하라!;-) 하지만 하단에 견해를 더하고 1~2주 후에 돌아와 다른 사람들이 무슨 말을 해야 하는지를 고려한 후 당신의 결정을 검토하라. --존 반덴버그 (UTC) 09:20, 2009년 10월 29일 (UTC)[응답]

번역자 유치

내 경험에서 알 수 있듯이, 나는 종종 내 모국어로 존재하지 않는 영어 버전의 기사를 읽으러 간다.나는 내 모국어로 번역하고 기사를 만들 수 있지만, 지금 당장 그것을 하는 것이 귀찮아질 수 없어, 그것은 그것이 결코 이루어지지 않을 것이라는 것을 의미한다.그럴수록 내 생각처럼 "지금까지 아무도 만들지 않기 때문에 이 기사는 아무에게도 불필요하다"고 했다.나는 그런 상황에 있는 사람만이 아니라고 생각한다.그래서 나는 번역가들을 끌어들이는 것을 돕기 위해 위키 엔진에 기술적인 마법을 걸려고 한다.그것은 다음과 같이 할 수 있었다.

엔진이 HTTP 헤더에서 현재 방문자가 현재 기사의 언어 외에 다른 언어를 말할 수 있다고 판단하고 다른 언어가 존재하지 않는다는 내용의 기사를 작성했으며, 그러한 기사가 매우 요구된 경우(당신이 또한 내가 생각할 수 있는 것) 엔진은 버전을 만들기 위한 일종의 간절한 요청을 표시할 것이다.그의 모국어로 "NNNN 1억의 사람들이 당신의 노력에 매우 감사할 것이다...";-) --AlexPavlenko (대화) 13:45, 2009년 10월 30일 (UTC)[응답]

내가 지지하는 것은 아주 좋은 생각이다. - 다메르룽 ☩. -- 13:42, 2009년 11월 1일 (UTC)[응답]

하지만 그것은 쉽게 짜증날 수 있다.그러나 머리글 정보를 사용하는 것은 현명하며, 번역을 장려하는 일회성 사용자 대화 게시물을 유발하는 데 사용될 수 있다.Rd232 16:14, 2009년 11월 1일 (UTC)[응답]

IP 편집기를 위한 대화 페이지에 대한 인터페이스 링크 제공

• 이 논의에서 파생된 것이다.

공공 기물 파손 등과 싸우며 끊임없이 로그인한 사용자들로서, IP 편집자들이 그들의 대화 페이지에 쉽게 접근할 수 없다는 것을 잊기가 쉬울 수 있다.나 자신도 최근에 이것을 알게 되었다.익명의 편집자들은 새로운 메시지나 경고를 받을 때 새로운 메시지 통지를 보지만, 그 시간만이 실제로 페이지에 연결된다(내가 이해한 바와 같이).그렇지 않으면, 그들은 그들의 IP 주소를 알아내고 우리의 사용자 토크 구문과 함께 그것을 수동으로 입력해야 할 것이다. 새로운 편집자들은 아마 그것에 대해 전혀 알지 못할 것이다.

IP 편집자들이 우리의 경고에 귀를 기울이고, 그들이 과거에 어떤 경고를 받았는지 계속 알고, 심지어 우리와 대화를 나누기까지 한다면, 그들은 그들의 대화 페이지에 쉽게 접근할 수 있어야 하지 않을까?나는 등록한 사용자들이 그들의 인터페이스에 가지고 있는 것처럼 오른쪽 상단 모서리에 있는 익명 편집자들을 위한 토크 페이지 링크를 제안한다.Equazcion (대화) 2009년 10월 30일 (UTC) 20:13, 30

나는 방금 위에서 연계된 토론에서 이것에 대해 꽤 긴 코멘트를 작성했다.분명히 당신은 그곳에서 나의 전체 글을 읽는 것을 환영하지만, 여기서 가장 관련 있는 요점은 다음과 같다.

1. 그렇다, Equazcion은 확실히 좋은 점을 가지고 있다: 문제가 있다.
2. 우리는 비로그인 사용자 인터페이스가 주로 그것을 읽고 편집하지 않는 대다수의 위키백과 편집자들을 위해 존재한다는 것을 기억해야 하며, "토론"이라는 태그가 주어지는 것을 혼란스럽게 할 수 있다는 것을 기억해야 한다. 다만, 그들이 이해하지 못한 메시지로 가득 차 있는 페이지를 발견했을 뿐이고, 만약 그들이 "차단"된다면 상당히 위험할 수 있다.그들은 모르는 일을 계속 했다.그러므로 나는 그 변화가 득보다 실이 많지는 않을 것이라고 확신한다.내 개인적인 의견은 이 문제를 처리하는 가장 좋은 방법은 등록되지 않은 사용자들에 의한 모든 편집을 금지하는 것이지만, 나는 동의가 이에 반대한다는 것을 안다; 따라서 이것이 일어나지 않을 것이라는 점을 감안한다면, 나는 그 제안이 현재 (적용할 정도로 매우 불완전한) 상황보다 균형 있게 진행될 것이라고 확신할 수 없다.제임스BWatson (talk) 20:39, 2009년 10월 30일 (UTC)[응답하라]

이것은 잘못된 가정이다.IP는 그들의 대화 페이지에 접근하는 적어도 세 가지 빠르고 분명한 방법을 가지고 있다.그건 문제가 아니야.메인 스페이스에서 기부를 하면 기고 이력에서 IP 옆에 있는 (토크)를 클릭할 수 있다.이름 없는 공간에 글을 올리고 내 게시물에 서명을 하면 내 IP를 클릭할 수 있고, 그 옆에 왼쪽 상단에 있는 내 토크 페이지에 대한 링크가 있다.만약 내가 이름 없는 공간에 글을 올리고 네 개의 틸다로 내 이름을 서명한다면 내 강연에 대한 링크는 이 메시지에서처럼 내 IP 목록 옆에 있을 것이다.

IP는 그들의 대화 페이지에 쉽게 접근할 수 있다.그것은 IP 사용자들을 위한 사용자 인터페이스에 내장된 기능이다.몇 년 전만 해도 더 힘들었지만, 이것을 일찍 처리하도록 바뀌었다.그것은 이미 거기에 있다.오른쪽 상단에 있는 토크 페이지 링크로 더 쉬울 수 있지만, 어렵지 않다는 것을 사람들에게 확실히 알리는 것만으로. --69.226.106.109 (토크) 00:55, 2009년 10월 31일 (UTC)[응답]

정보를 줘서 고마워.적어도 어디를 봐야 할지 알고 있거나, 토크 코멘트를 하는 데 익숙하다면 그렇게 어렵지 않을 것 같아.그런 경우에도 나는 정적 인터페이스 링크가 중요하다고 생각한다.하지만 특히 페이지 기록을 볼 줄 모르고, 서명을 받을 만한 토크 코멘트조차 하지 않았을 신인 편집자들의 관점에서, 인터페이스 링크는 그들에게 큰 도움이 될 것이라고 생각한다.Equazcion(토크) 03:05, 2009년 10월 31일 (UTC)

IP가 현재 자신의 이야기를 할 수 있는 주요 방법은 다음과 같다.

1. 모든 편집 페이지에 표시되는 "현재 로그인하지 않은 사용자" 메시지의 링크
2. 특수 입력:검색 상자 또는 주소 표시줄의 MyTalk
3. 서명(페이지를 저장하지 않아도 됨)
4. 편집한 경우 기록 페이지
5. 다른 누군가가 그들의 이야기를 편집한다.

내 생각에, 애논에게 그들의 토크 페이지에 더 직접적인 링크를 주는 것은 그들이 그것을 어떻게 해야 할지 모른다는 것이다.나는 그것이 오용될 것이라고 생각한다.나는 새로 등록된 편집자들이 자신들의 대화 페이지에 도움을 요청하는 글을 마치 24시간 동안 보지 못한 관찰자들과의 대화를 위한 포털인 것처럼 올리는 것을 본 적이 있다.위키피디아에 대해 아무것도 모른다면 "My talk"의 목적은 직관적으로 명백하지 않다.그곳의 대부분의 공공 기물 파손 행위들 역시 순찰을 받지 않을 것이다.또한 위키피디아에 있는 엄청나게 압도적인 대다수의 애논들은 편집자가 아니라는 것을 기억하라!그들은 단지 백과사전을 탐색할 뿐이고, 그들에게는 대화 페이지는 무용지물이다.• 아나킨 13:49, 2009년 10월 31일 (UTC)[응답]

• 지원 - 이것은 많은 다른 위키에서 행해지고 있는데, 왜 위키백과에서 행해지지 않는지 모르겠다.--Unionhawk^{TalkE-mailReview} 13:51, 2009년 10월 31일 (UTC)[응답하라]

  한 마디로 캐싱.위키피디아 페이지는 캐시된 양이 많기 때문에 동일한 페이지가 수많은 익명 독자들에게 제공될 수 있다.IP 주소와 같은 사용자별 데이터가 있는 경우에는 예외로 한다.그렇기 때문에 애논은 편집 화면이나 특수 페이지 등에만 페이지 링크를 볼 수 있다. 이러한 링크들은 어쨌든 각 보기에 대해 동적으로 생성되어야만 하기 때문에 별도의 성능 부하 없이 거기에 추가할 수 있다.해피멜론 14:08, 2009년 10월 31일 (UTC)[응답]

  아, 그럼 기본적으로 위키피디아가 이렇게 한다면 서버가 붐빌 거라는 말씀이시죠?아니면 적어도 평상시보다 더 자주 실패하는가?--Unionhawk 14^E-mailReview:15, 2009년 10월 31일 (UTC)[응답]

  특수:MyTalk는 링크를 클릭하기 전에 다른 페이지를 제공하지 않고 모든 사용자를 위해 작동한다.프라임헌터 (토크) 2009년 10월 31일 (UTC) 14:26 [응답]

  응, 게시하고 얼마 안 가서 생각났어.Special에 대한 링크만 있으면 어떨까?로그인 링크 옆에 MyTalk 추가?--Unionhawk 15:43^{TalkE-mailReview}, 2009년 10월 31일 (UTC)[응답]

  네, 이미 WMF에서 미디어위키에 내장되어 있는 방법이 왜 여기 WMF에서 사용되지 않는지 설명만 해피멜론 18:48, 2009년 10월 31일 (UTC)[응답하라]

첫째, 접근 용이성이 문제라고 생각하지 않는다.아논 사용자들은 쉽게 접근할 수 있지만, 만약 a) 그들이 접속할 수 있는 것을 모르고 b) 그들이 무엇에 접속할 것인지 그리고 왜 접속할 것인지를 모른다면 그것은 소용이 없다.그러나 토크 페이지에 경고를 남기는 메커니즘이 불완전하지만, 나는 그것이 실질적으로 개선될 수 있다고 생각하지 않는다.우리가 할 수 있는 일은 애논들이 (이미 매 차례마다 하고 있는) 계정을 만들도록 격려하고 그들이 혼란스러운 메시지가 튀어나오기 시작할 때 힌트를 얻기를 바라는 것이다.--RDBury (대화) 18:47, 2009년 10월 31일 (UTC)[응답]

나는 인터페이스 링크를 제공하는 것이 개선될 것이라고 생각한다.또한 "앞으로 이 페이지로 돌아가려면 오른쪽 상단에 있는 blah blah 링크를 클릭" 등의 대화 페이지를 보면서 표시되는 인터페이스 메시지일 수 있다.Equazcion (대화) 2009년 10월 31일 18:57, (UTC)

JavaScript를 사용하여 클라이언트 끝에 링크를 추가하는 것이 실용적인가?그렇게 되면 캐싱의 문제를 해결할 수 있을 것이고, 호환성에 큰 문제는 없을 것이라고 생각한다(그리고 만약 있다면, 우리는 우아한 실패를 설계할 수 있을 것이다).{{Nihiltres talk edits}}}{19:37, 2009년 10월 31일 (UTC)[응답]

그것이 실용적이라 하더라도(의심하지만) 그것이 스페셜보다 어떻게 더 좋을까:마이토크?Rd232^talk 20:45, 2009년 10월 31일 (UTC)[응답]

나는 여기서 열린 마음을 가지려고 노력하고 있다.중요한 차이점은 가시성이다.대부분의 사람들은 스페셜을 모른다.MyTalk 등.존재한다는 것이 이 특집 제안의 주된 원동력이다!나는 최근에 그것을 여자친구의 무선 네트워크의 인터넷 접속 IP를 찾는데 사용했는데, 여자친구나 룸메이트도 그것이 거기에 있다는 것을 모르고 있었다.그 특징에는 사람들이 지름길을 알게 하는 것이 시범적으로 사용된다.두 개를 포함하는 것만큼 간단하다.addPortletLink() 피부 일부를 호출한다.우리는 단순히 마이페이지, 마이토크 페이지, 그리고 우리가 원하는 어떤 것이든 링크할 수 있고, 내가 아는 한 그것은 어떤 브라우저에서도 작동할 수 있다.즉각적으로 명백하지 않은 것에 문제가 있는가(예: 그것)JavaScript를 사용할 수 있어야 함){{Nihiltrestalkedits}}} 23:25, 2009년 10월 31일 (UTC)[응답하라]

IP에는 사용자 페이지가 없는 것 같은데, 그냥 대화 페이지만 있는 것 같아.니힐트레스, 네 요점을 잘 모르겠어.내가 아는 바로는 스페셜:Mytalk는 가장 간단하며, 보이는 링크 텍스트는 "My Talk" 또는 "My Torces Page" 중 어느 쪽이든 동일할 것이다.javascript를 사용함으로써 가시성이 어떻게 다를까?Equazcion(토크) 00:10, 2009년 11월 1일(UTC)

아, 그래.미디어위키 레벨에서 마이토크와 마이콘트리브 등을 사용한다는 말씀이시죠.그 경로는 여러 가지 이유로 바람직하지 않다고 생각되지만, 그것은 링크를 생성하기 위해 JavaScript를 사용하는 것이 링크를 아예 갖지 않는 것보다 낫다는 것을 의미한다.IP에는 사용자 정의별로 사용자 페이지가 없지만 기술적으로 사용자 페이지를 가질 수 있다(예: 특수: 참조):접두사 색인/사용자:24.때때로 그것은 다른 세부사항들에 사용된다.{{Nihiltres talk edits}}}05:20, 2009년 11월 1일 (UTC)[응답]

• 그 문제를 제기한 사람으로서 지지하라.기술적인 문제에 대해서는 의견이 없지만, 새로운 사용자들은 대화 페이지 같은 것이 있다는 것조차 모른다는 것이 나의 요점이다.어떤 눈에 띄는 장소에 링크가 제공되지 않는 경우, 페이지 기록을 검색하거나 Special과 같은 기능을 사용할 것을 기대할 수 없다.MyTalk. --Pgallert (talk) 08:53, 2009년 11월 2일 (UTC)[응답]
• 반대. 위에 언급(아나킨과 제임스)BWatson) 일반 독자와 드라이브 바이 편집자의 지옥을 혼동하는 것에 대해.그것은 장기적인 IP 편집자들에게 유용할 수도 있지만, 그들은 훨씬 더 작은 지역이고 그들에게도 그 혜택이 얼마나 클지는 잘 모르겠다.Rd232 09:18, 2009년 11월 2일 (UTC)[응답]
• 두 가지 주장에 모두 동의해야 한다 - 만약 IP가 토크 페이지를 가지고 있다면, 그는 거기에 링크를 가지고 있어야 한다(이름에 있는 편집자들보다 IP에 대한 더 어려운 것은, 후자가 토크 페이지와 거기에 어떻게 도달하는지에 대해 더 잘 알기 때문이다). 그러나 우리는 위키피디아를 읽는 전세계의 모든 사람들에게 의미 없는 빨간 링크를 보여주기 시작하고 싶지 않다.IFF에 대화 페이지가 존재한다는 링크가 표시되어야 한다.프로그래밍하는 것은 어렵지 않겠지만, 캐싱과 성능에 어떤 영향을 미칠지는 잘 모르겠다.(글쎄 IP가 "새로운 메시지가 있다" 배너를 갖게 되면 소프트웨어는 이미 모든 사용자의 IP 주소를 무언가와 대조해 확인해야 하기 때문에, 토크 페이지가 있는 IP 주소 목록과 대조해서 체크한다고 해도 큰 차이는 없을 것 같다.s.)---코트니스키 (대화) 09:29, 2009년 11월 2일 (UTC)[응답]

'지연된' 신속한 삭제

이는 특정 기준에 부합하지 않거나 더 이상 충족되지 않도록 개선될 수 있는 기사에 대해 선택적으로 보다 사용자 친화적인 삭제 템플릿을 만들자는 제안이다.여기서 제안서를 보고 의견을 제시하십시오.세나륨 (대화) 18:03, 2009년 11월 2일 (UTC)[응답]

백로그 서식

안녕! 카테고리 토크에서 토론이 있어:위키백과 백로그#나는 추적 정보가 카테고리:에 유용한 것을 발견한다.위키백과 백로그는 포맷되어야 한다.원본은 [3]이었고, 제안은 [4]와 [5]이다.그 토크 페이지의 추가 입력은 모두 감사할 것이다.고마워! –Drilnoth (T • C • L) 22:35, 2009년 11월 2일 (UTC)[응답]

대화 페이지 주석 하위 페이지

제안:편집자가 자신의 네임스페이스에서 관리자가 되도록 허용.

여보세요

내 제안은 사용자들이 자신의 사용자 공간 도메인에 있는 페이지를 관리하도록 허용하는 것이다.예를 들어 페이지에 다음과 같은 접두어가 있는 한 다른 모든 관리 기능을 보호, 삭제 및 수행할 수 있다. 사용자:Tim1357/ 및 사용자 대화:팀1357/.네 생각을 말해봐.Tim1357 (대화) 2009년 10월 22일 14:39 (UTC)[응답]

User_talk: 스페이스에는 확실히 없다.사용자 요청은 삭제 및 보호에 대한 타당한 이유이므로, 이것은 정말로 필요하지 않다(기술적으로 불가능함).-Unionhawk 14^E-mailReview:43, 2009년 10월 22일 (UTC)[응답]

기발한 생각.관리자가 공공 기물 파손에 대해 경고하면, 당신은 사실을 숨기기 위해 당신의 토크 페이지를 삭제하고 새로운 페이지를 작성하기만 하면 된다.기사가 마음에 안 들면 그냥 사용자 공간으로 옮기고, 거기서 지우고, 똥을 싼다!그것의 역사는 없어졌는가?관리자를 위한 추가 작업을 많이 만들 수 있는 얼마나 좋은 방법인가.한사들러 2009년 10월 22일 14:58 (UTC)[응답]

(갈등 편집) ^이거.편리하지만 반달족에게는 정말 뷔페. --외미에 15:07, 2009년 10월 22일 (UTC)[응답]

첫째로, 유니온호크에 대한 대응으로, 기술적으로는 가능하지만, 소프트웨어에 대한 수정 작업이 필요할 수도 있다.두 번째로 한스에 대한 반응으로, 빈정거림 덕분에, 항상 듣는 것은 즐겁지만, 그런 문제를 극복할 수 있는 방법들이 있다.사용자 공간에서 작성된 글은 이와 같이 플래그가 표시될 수 있으며, 사용자가 해당 플래그가 있는 기사에 한해 삭제를 허용할 수 있다.그리고 그것은 단지 하나의 예일 뿐이다.

나는 이것이 좋은 생각이라고 생각하지만, 모든 사용자들을 위해서, 단지 잠시 동안 확립된 사람들만을 위해서 처음부터 끝까지 하는 것은 아니라고 생각한다.그리고 관리자들은 사용자가 한 모든 것을 무시할 수 있는 능력이 필요할 것이다.

그렇긴 하지만, 유감스럽게도 이 기능이 실제로 곧 구현될 수 있는 우선 순위에 충분한지 의문이다.Equazcion (talk) 15:06, 2009년 10월 22일 (UTC)[응답하라]

너무 복잡해서 얻는 게 너무 적다.–xeno^talk 15:08, 2009년 10월 22일 (UTC)[응답]

자신의 사용자 공간에서 사용자에게 부여된 추가 라이선스는 권리가 아닌 특권이다.그들에게 특별한 권력을 허락하는 것은 그것과 반대되는 것이다.크리스 커닝햄(직장이 아님) -토크 15:12, 2009년 10월 22일 (UTC)[응답]

논쟁을 위해 무언가를 말하는 것은 특권이고 권리가 아니라고 말하는 것은 능력이 주어진 만큼 쉽게 빼앗길 수 있다는 것을 보여주는 방법이다.그것은 더 많은 특권을 주는 것에 반대하는 증거가 아니다.사용자에게 자신의 사용자 공간을 관리할 수 있는 추가 권한을 부여하면, 그것은 여전히 권리가 아니라 빼앗길 수 있는 권한이다.Equazcion (대화) 2009년 10월 22일 (UTC) 15:21 [응답]

아마도 "특권"은 적절한 단어가 아니었을 것이다."라이센스?"현재 상황은 기본적으로 여러분이 해서는 안 될, 하지만 여러분이 놓칠 수 있는 여러분 자신의 사용자 공간에서 할 수 있는 것이다.그것은 다른 사람이 하기에는 물리적으로 불가능한 일을 하도록 허락하는 것과는 전혀 다른 것이다.크리스 커닝햄(직장이 아님) -토크 15:32, 2009년 10월 22일 (UTC)[응답]

제안서는 일반적으로 예상되는 편익을 설명한다.이번 건은 그렇지 않아. (비용은 위에 표시되었어.)Rd232 15:31, 2009년 10월 22일 (UTC)[응답]

권력의 환상이요?모든 사람들이 작은 관리자처럼 느낄 것이다.사기 진작 가능 :) 에콰지온 (대화) 15:47, 2009년 10월 22일 (UTC)[응답]

한스는 그 문제를 상당히 요약한다.(더 이상 묘사하지 않을 정말 엉망인 몇 가지 다른 것들이 생각난다.)쉽게 남용되고, 눈에 띄는 혜택은 거의 없다.다른 관리자 경험이 없는 사용자가 공정하지 않을 가능성이 가장 낮은 영역(사용자 공간)에서 전쟁을 주도하도록 유혹할 위험이 추가된다.편집자들이 자신의 영역에서 '실험'을 하는 것은 실수 후 정리를 위해 전문적인 도움이 필요할 수 있다.

CAT 보기:CSD는 지금 한 개의 사용자 공간 페이지만 보이는데, U1 요청이 아닌 잘못된 {hangon} 템플릿의 결과물이다.비용 편익 트레이드오프는 가치가 없어 보인다.TenOfAllTraes(토크) 16:18, 2009년 10월 22일 (UTC)[응답]

사용자 공간 CSD는 일반적으로 논란의 여지가 없고, 실제 조사가 필요하지 않기 때문에 일반적으로 가장 먼저 사용된다는 점을 지적하고 싶다.내 생각에는 그것들이 많이 있다; 그것들은 단지 빨리 처리될 뿐이다.하지만 내 생각에 그것은 여전히 같은 점을 증명하는 것 같아, 그 제안이 그렇게 가치 있는 것이 아니라는 것을.Equazcion (대화) 16:33, 2009년 10월 22일 (UTC)[응답]

빈정거려줘서 정말 고마워...이 페이지의 전체 목적은 아이디어를 내고 의미 있는 피드백을 찾는 것이다.팀1357

좋은 생각이었지만, 한스 아들러는 왜 그것이 작동하지 않는지 설명했다.펜스&윈도우즈 15:46, 2009년 10월 26일 (UTC)[응답]

이에 대한 대안은 "위키 샌드박스"가 될 것이며, "프로젝트"는 모든 사용자에게 관리자 권한을 부여하고 페이지나 계정을 만든 다음 삭제, 복원, 차단, 차단 해제, 보호, 보호 해제...물론 다른 가시적인 목적이나 가치 있는 내용이 없는, 단지 이런 목적으로 만들어진 프로젝트일 것이다.사용자가 이러한 도구가 어떻게 작동하는지 또는 "강력한 느낌"을 볼 수 있도록 할 수 있지만, 실제 프로젝트에 대해 아무런 영향(간접적이거나 미묘한 영향도 미치지 않는 곳)에 포함된 모든 물질적 위해를 유지할 수 있다.그러나 200.68.71.147 (토크) 14:31, 2009년 10월 28일 (UTC)[응답]의 "테스트" 척도로만 해도 다른 프로젝트를 진행하는데 얼마가 들지는 모르겠다.

사람들이 관리자 역할을 할 수 있도록 하는 그러한 시험 위키들이 많이 있다.위키피디아 시험에서도 허용이 되는 것 같아.–xeno^talk 14:34, 2009년 10월 28일 (UTC)[응답]

사용자가 자신의 하위 페이지를 삭제할 수 있도록 허용하면 어느 정도 이점이 있을 수 있으므로, 예를 들어 "사용자:John Doe/관리자를 거치지 않고 내가 왜 이걸 만들었는가"라고 말했다.그러나 관리자들이 이러한 요구에 개의치 않는다면, 나는 변화할 이유가 없다고 본다.--RDBury (대화) 16:13, 2009년 10월 29일 (UTC)[응답]

피드백 고마워, 나는 관리자에게 내 사용자 페이지를 삭제하라고 요청하는 것이 미안해서 이것을 제안했지만, 만약 그들이 내 사용자 페이지에 대해 신경 쓰지 않는다면 나는 동의한다; 이것은 필요하지 않다.Tim1357 (대화) 01:03, 2009년 11월 4일 (UTC)[응답]

그것의 방어로, 이 아이디어는 사실 좀 이상하다; 아마도 위키백과 그 자체로는 아니지만, 위키백과 같은 사이트에서는 그것에 대한 모든 종류의 용도를 볼 수 있다. :-)-김브루닝 (토크) 01:42, 2009년 11월 4일 (UTC) 위키 티셔츠를 마지막으로 본 모든 사람들에게, 그것은 영원한 자유분방한 유인물이었기 때문이다! 짐에 넣어둘 여지도 남겨뒀어! 맹세코 나는 어떤 식으로든 편견이 없다, 정직하다.[답답하다]

자, 만약 친한 그룹이 대화 페이지가 삭제되어 경고가 "숨기기" 위해 삭제되는 것에 대해 걱정한다면(어쨌든 경고는 의미가 없고, 만약 당신이 여기에 1년 이상 있었다면 당신은 그것을 알아내고 나면 그들은 당신을 겁주지 않는다) 그리고 누군가 언급했듯이, 그것은 사용자들이 그들의 대화 페이지를 넘어서지 않고 하위 페이지를 통해 관리자 역할을 하도록 허용한다.그들이 가진 "권력"에 대해 불안정한 관리자인가? 왜냐하면 우리 ALL, 관리자, 일반 편집자 및 IP는 "관리자"라고 불리는 그룹에게 권력을 부여하고, 그것을 쉽게 빼앗을 수 있기 때문이다. 관리라는 그룹과 우리는 모두 개인들을 탈취할 수 있다.아티클 공간에서 사용자 공간으로 기사가 이동된 다음 해당 내역이 삭제되는 것을 염려하는 경우...그런 일이 일어나는 걸 막아야지관리자 대 일반인의 전쟁을 치르는 대신 일반 사용자가 자신의 페이지를 악으로 사용할 수 없는 방식으로 제어하도록 하는 방법을 알아보는 것은 어떨까?만약 소수자가 그들을 학대할 수 있다는 이유만으로 사람들에게 권한을 주지 않는다면, 우리는 전혀 행정관이 없을 것이다.사용자들이 이런 능력을 가지기를 원하지 않는 사람들은 우리 모두를 최악의 시각에서처럼 생각하는 것 같다.정말?위키피디아에 그렇게 많은 나쁜 씨앗이 있니?좋은 생각이야, 우리가 줄을 서야 할 많은 관리자들이 있다고 생각해, 그들이 없었다면 우리는 이 모든 반달리즘과 위키피디아가 무너졌을 것이고, 우리는 부모의 감독도 받지 못한 아이들이 될 거야.세상은 당신이 책임감을 가지고 비관리자들을 신뢰할 수 없기 때문에 끝날 것이다. 왜냐하면 만약 그들이 책임감 있는 편집자라면 그들은 관리자가 되고 싶을 것이고 이미 승진했을 것이기 때문이다!카멜빈키 (토크) 02:24, 2009년 11월 4일 (UTC)[응답]

나는 약간의 이력을 뒤에 둔 편집자들에게 그들이 만든 페이지를 자신의 사용자 공간에서 삭제할 수 있는 능력을 부여할 수 있는 선택권을 강하게 지지한다.왜 편집자는 실험으로 모아 놓은 모든 사용자 공간 페이지를 삭제하기 위해 관리자에게 달려가야만 하는가? 그리고 2009년 11월 4일 (UTC)[응답]

버그 투표

질문: 개발자들은 Bugzilla에서 버그에 대한 투표에 관심을 가지고 있는가?만약 그렇다면, 지역 사회가 특히 중요하게 생각하는 몇 가지 버그를 식별하고 사람들에게 투표하도록 하는 것이 가치가 있을까?위키피디아에는 버그 관리에 대한 일반적인 토론이 도움이 될 수 있다.Rd232 10:16, 2009년 10월 29일 (UTC)[응답]

나는 그들이 어느 정도 주의를 기울인다고 생각하지만, 일반적으로 사용자들이 무엇을 필요로 하는지 별로 신경쓰지 않는다(또는 전혀 모르고 있다.정말로 편집자와 개발자 모두가 참여하는 적절한 온-위키 대화를 위한 포럼이 있어야 한다. 그래야 해결책이 건설적으로 도출되고 이를 구현하기 위해 취해야 할 조치가 있다.버질라는 이런 점에서 별로 효과가 없다. --코트니스키 (토크) 11:28, 2009년 10월 29일 (UTC)[응답하라]

물론 개발자들은 투표에 어느 정도 주의를 기울이지만, 그것은 보통 개발자의 행동을 결정하는데 있어서 그다지 설득력 있는 요소는 아니다.투표수가 많은 버그들은 대부분 찬성한다는 의미에서 "지지"되지만, 종종 필요한 변화는 이런저런 이유로 복잡해서 아무도 프로젝트를 따내지 못했다.나는 (양쪽에 있는) 공동체가 (특집 요청에 대해서는) 위키 토론 포럼(Mediawiki.org?)에서)의 혜택을 받을 수 있을 것이라는 코티스키의 의견에 동의한다. 왜냐하면, 버질라는 공동체가 자신의 선호를 표현하는 데 좋은 매개체가 아니기 때문이다.드래곤즈 비행 (토크) 2009년 10월 29일 17:01, (UTC)[응답]

아니, 우리한테 무시당했어버그에 대한 CC 리스트에 반드시 올라가지 않으려면 좋은 북마킹 시스템을 만들 수 있기 때문에 우리는 투표를 계속 할 수 있다.우선 순위/중요성 확립에 이용하는 한, 나는 한 번도 득표수를 살펴본 적이 없다.데브스와의 논의에 관해서는...나는 mw.org을 토론 포럼으로 사용하는 것을 주저한다. 왜냐하면 우리는 그것을 문서화하는데 사용했기 때문이다. 거기에는 전혀 토론이 이루어지지 않는다.^demon^{[omg plz]} 17:58, 2009년 10월 29일 (UTC)[응답하라]

나는 구조적인 문제가 어디서든 개발자와 편집자 간의 토론이 거의 이루어지지 않는다는 것에 더 있다고 생각한다.몇몇 개발자들은 이와 같은 포럼을 방문하지만, 그것은 매우 특별하고 많은 개발자들은 결코 방문하지 않는다.지금 당장은 새로운 기능에 대한 커뮤니티 토론을 위해 특별히 마련된 곳이 없기 때문에, 우리는 위키백과: 페이지, 메타에 관한 스레드, 그리고 별로 도움이 되지 않는 수다스러운 버그질라 항목 등 빠르게 사라지고, 찾기 힘든 VPT 스레드로 끝을 맺는다.mw.org보다는 미디어위키의 발전을 지역사회가 어디서 논의하게 할 것인가에 대한 더 좋은 제안이 있다면, 듣고 싶지만, 나에게는 위키 공간 중 가장 논리적인 것 같다.드래곤즈 비행 (토크) 2009년 10월 29일 21:33 (UTC)[응답]

개발자들은 #미디어위키에서 IRC에 가장 적극적이야. 거기서 우리 대부분은 쉽게 ping을 할 수 있지.위키-l과 미디어위키-l 목록이 좋으며, 버그질라는 버그/기능 요청을 논할 수 있는 궁극적인 장소다.물론 '미투(me too)' 논평은 도움이 되지 않고 어수선한 토론이지만, 부길라에게 보내는 주제 게시물은 분명 환영할 만하다.나는 대부분의 개발자들이 거대한 엔위키 토론에 참여하는 것에 관심이 없고, 그들은 장황하고 집중력을 잃기 쉽다고 말할 수 있다.전형적으로, 우리는 본질적인 부분을 다루는 더 짧은 토론을 좋아한다:) 아마도 우리는 다양한 WMF 커뮤니티에 특정한 중요한 것들을 나열할 수 있는 곳이 mw.org에 필요하며, 우리는 그 커뮤니티가 필요로 하는 것에 대해 빠르고 요약된 버전을 얻을 수 있다.^demon^{[omg plz]} 23:16, 2009년 10월 29일 (UTC)[응답하라]

그렇다, 개별 위키피디아 사람들이 dev를 "ping"하는 방법이 있다.이것은 벌레를 지적하기에 좋다.새로운 기능을 요구하는 것은 좋지 않다.존QWikipedian이 나서서 "엔위키는 날으는 원숭이가 더 필요하다"고 말한다면, 그것이 단지 그의 의견인지, 아니면 실제로 엔위키 공동체의 의견인지, 그리고 "날으는 원숭이"에 대한 요구가 "섹시 불가사리" 등에 대한 필요성과 어떻게 비교되는지를 공동체 의견인지 알 수 없다.그래서 일반적으로는 아주 시끄럽고 가장 끈질긴 요청(흔히 여러 채널을 통해 만들어지는)만이 실제로 개발자의 의식 속으로 빠져들어 관심을 받는 반면, 다른 많은 좋은 아이디어들은 버그질라로 접수되어 단지 무명으로 사라지게 된다.나는 대부분의 개발자들이 토론에서 더미를 분류하는 것을 원하지 않는다는 것에 동의한다.그들은 작업할 결과/요약을 갖고 싶어한다.좋습니다.그러나 현재 우리는 지역사회가 원하는 특징을 파악/논의할 수 있는 좋은 프로세스를 가지고 있지 않기 때문에 신뢰할 수 있는 요약을 만들 수 있는 좋은 방법이 없다.드래곤즈 항공편 (토크) 2009년 10월 30일 00:30 (UTC)[응답]

그것은 그 문제를 잘 요약한 것이다.그렇다면, 우리는 그것에 대해 무엇을 할 수 있을까?우리는 어떻게 공동체가 원하는 것에 대한 결과를 만들 수 있을까? RFC? 위키프로젝트?뉴 빌리지 펌프 하위 페이지?위키피디아를 찾았다.위키백과에서 연결된 기능 요청(아카이브):버그 리포트 및 기능 요청으로 인해 이 작업을 수행하기 위한 노력은 과거에 이루어졌다.Rd232 08:59, 2009년 10월 30일 (UTC)[응답]

제안된 것보다 좀 더 복잡한 것 같아(버질라가 작동하지 않는 이유기도 하다.사용자들이 모여 원하는 것을 결정한 다음 개발자에게 말하고, 개발자가 (혹은 실제로 하지 않는다) 하는 것이 아니다.초기 단계부터 토론에 개발자 참여가 있어야 개발자가 참여하여, 개발자가 쉽고 어렵거나 전혀 실현 불가능한 것이 무엇인지, 어떤 부작용이 발생할 수 있는지 등을 설명할 수 있고, 사용자들이 이를 근거로 기대치를 수정할 수 있도록 하고, 사용자들과 개발자가 실제로 행동할 수 있는 개발자(div)가 참여하는 합의가 이루어지도록 할 수 있어야 한다.상당히 짧은 시간 내에사용자를 분열시키고 두 개의 분리된 공동체로 발전시키는 모든 것은 나쁜 것이고, 뒤틀린 우선 순위로 이어진다 - 우리는 모두 한 편이고, 같은 목표를 위해 일하며, 완전하고 효과적인 협력이 필요하다.-코트니스키 (토크) 10:49, 2009년 10월 30일 (UTC)[응답]

그런 종류의 의견이 필요하다는 것은 타당하지만, 개발자들이 그러한 논의에 상당한 시간을 할애할 것으로 기대하는 것은 분명 비현실적이다.소프트웨어와 소프트웨어 사용에 대해 많이 알고 있는 WP 편집자들이 있다. 그들이 중앙집중화된 토론에 참여하게 하는 것은 많은 도움이 될 것이다.그리고 필요한 경우 IRC가 아닌 일부 확립된 공개/녹음된 채널을 통해 개발자에 대한 구체적인 질문을 할 수 있고, 희망적으로 답변할 수 있다.그런 채널이 있을까?그런 중앙집권적인 토론이 있는가?내가 알기로는 아니다.Rd232^talk 11:01, 2009년 10월 30일 (UTC)[응답]

그것은 필요하지만, 나는 개발자들이 토론에 참여하기를 기대하는 것이 비현실적이라는 것에 동의하지 않는다.우리는 함께 일하고 있다. 우리 모두 서로 이야기를 해야 한다.데브스는 어떤 것이 기대되고 어떤 것이 효과가 있을지 알기 위해 반드시 그리고 의심의 여지 없이 사물을 토론해야 한다 - 그 순간 나는 그들이 토론에 소비하는 시간이 단지 절반의 목적에 불과한 서로에 대해 토론하는 데 소비되는 것이 아닌가 의심한다.질병은 버질라 투표에 거의 관심을 기울이지 않는다는 것이 인정된 위의 논평에서 잘 드러난다.그들은 그들만의 세계에 살고 있다; 그들은 그들이 원하는 것과 필요한 것을 안다고 생각하고, 우선순위는 달라져야 한다고 말하는 사람을 경멸한다.이것은 개인적인 비난이 아니다; 그것은 아마도 그런 태도를 가져오는 시스템일 것이다. 그리고 우리는 그 시스템을 바꾸려고 노력할 수 있다.(아무리 아주 나이 많은 개발자가 문제를 인식하지 않는 한 그렇게 될 것이라고는 그리 낙관할 수 없지만)--코트니스키 (토크) 11:14, 2009년 10월 30일 (UTC)[응답]

그래 그것은 흥미로운 문화의 충돌이다.그러나, 더 넓은 커뮤니티(그리고 이것은 대부분의 인기 있는 오픈 소스 프로젝트에 해당)가 종종 잊어버리는 것은 개발자들이 코딩을 하기 위해 그곳에 있고 그들 대부분은 공짜로 이것을 한다는 것이다.일을 하고 싶게 만드는 것은 프로젝트에 대한 그들의 사랑이다.이제 경험으로 볼 때 나는 개발자에게 불만과 항의에 대한 논의 후에 지루한 토론을 하는 것만큼 자극적이지 않은 것은 없다는 것을 말할 수 있다.대부분 사용할 수 없는 쓰레기들이며, 무엇보다 개발자로서 프로젝트에 기부할 수 있는 시간(매시간 읽을 때마다 코드를 쓸 수 없음)을 제한적으로 줄여준다.대부분의 사람들은 당신의 문제를 해결하기 위해 돈을 받는 회사에 익숙하기 때문에 이것은 대부분의 사람들에 의해 과소평가된다.

의사소통 방법의 단편화도 작용한다.이것을 생각해 보라: 개발자들은 블로그를 통해 뉴스를 출판하고, IRC를 통해 의사소통을 하고, 메일링리스트에 대해 토론하고, bugzilla를 통해 점수를 유지하고, wiki를 통해 문서를 보관한다.그것은 여러분이 따라잡아야 할 5개의 시스템으로 실제로 코드를 작성하는 것과 전혀 관련이 없다. (다른 3개의 시스템(svn/codeReview/commit logs)은 따라잡기 위한 것이다.)그러나 비-피어들과 논의에 들어가는 것은 그 모든 것 중 가장 많은 시간이 소요될 것이며 여러분이 따라가야 할 또 다른 플랫폼이다.그것이 불가능하다는 것이 아니라, 너무 막힘이 없는 방식으로 구현하는 것이 혼란스럽고 어렵다.

가장 일반적인 해결책은 사람들을 중간에 두는 것이다.기술 및 커뮤니티에 대해 충분히 이해하고, 아이디어와 버그를 개발자에게 명확하고 적절하게 전달하고, 개발자가 6년 이상 기능 지연에 직면하는 문제를 다시 전달하는 "해외투사"의 일종.이것은 기업에서는 꽤 흔한 일이지만, 자원봉사에 있어서는 자원봉사를 하는 사람이 거의 없는 일이다.나는 다리가 되려고 하는 오픈소스 프로젝트 포럼에서 하루 몇 시간씩 시간을 보내곤 했다.너무 많아서 어느 순간엔가 내가 코드를 쓰지 않을 뻔했지만, 적어도 다른 사람들은 어느 정도 작업을 하고 있었다.본질적으로 그것은 또한 VP/T에서 보는 것이다.IRC의 사람들과 개발자가 아닌 메일링리스트들은 en.wp와 개발자 사이에 다리를 놓으려고 노력하지만, 그것은 큰 프로젝트고 많은 커뮤니케이션이다.

사용적합성팀은 위키페이지에 피드백 페이지를 띄워 지역사회와 보다 직접적으로 소통하려 하지만, 거기서 아무 대답도 하지 않기 때문에 오히려 의견의 덤프장에 가까운 것 같다.그들이 적어도 피드백을 읽었다는 것을 그곳에 표시한다면 좋을 것이다.이것은 새로운 CTO가 대처하고 힘을 쏟아야 할 것이다.—DJ (대화 • 기여) 13:19, 2009년 10월 30일 (UTC)[응답]

나는 그 모든 것에 동의한다.그래서 우리가 개발자들에게 전달하고 싶은 것에 대해 지역사회에서 더 나은 필터를 만들려고 노력하려는 나의 막연한 생각은.만약 우리가 주기적으로 필터를 통해(아마도 월간 요약?), 그리고 그러한 핵심 사항들을 전달할 수 있는 명확한 채널이 있다면(아마도 "해외투사"를 통해) 개발자들에게 소량의 유용한 정보를 제공할 수 있다면, 우리는 의사소통 방식의 어딘가를 얻을 수 있을 것이다.Rd232^talk 13:39, 2009년 10월 30일 (UTC)[응답]

해볼 수 있어.그런데 우리는 새로운 CTO가 누구인지 알고 있어서 이 모든 것에 대해 어떻게 생각하는지 물어볼 수 있을까? (혹은 DJ가 말하는 "이용가능성 팀" - 다시 한 번 나는 그들이 누구인가에 대해 좀 모호하게 생각할 수 있을까? - 사실 "투사"의 역할을 맡게 된 것일까?비록 개발자들의 시간이 그들의 동료 위키백과 직접 대화함으로써 낭비된다고 말하는 사람들에 의해 나는 정말로 납득이 가지 않지만 - 나머지는 그렇게 해야 한다 - 비록 내가 그들이 다른 사람들의 토론을 뒤져야 한다고 제안하는 것은 아니지만.)-코트니스키 (토크) 13:56, 2009년 10월 30일 (UTC)[응답]

아직 새로운 CTO는 없다 : (사용성 팀은 정말로 그 역할을 맡기에 적합하지 않다.그들은 헌신적인 임무를 가지고 있고, 너무 많이 미루어서는 안 된다.또한, 위키인으로서 우리 또한 같은 일을 한다.예를 들어 오용필터와 반달리즘 봇은 우리가 정말 다루고 싶지 않은 것들을 다루기 위한 우리의 "필터"의 일부분이다.개발자를 걸러낼 시스템을 마련해야 한다.—DJ (대화 • 기여) 2009년 10월 30일 (UTC) 14:39, 답신[응답]

문제 중 하나는 "버그"(마찰)와 "버그가 아니다"(기능요청, "항체"에 대한 불만 등)를 모두 보고하기 위해 "버그" 추적 소프트웨어를 널리 사용하는 것이다.후자는 소프트웨어가 설계한 대로 작동하지만 일부에서 바람직하지 않거나 성가시게 여기는 행동을 만들어 내는 상황이다.이것은 기술에 정통하지 않은 사용자들이 소프트웨어에 대해 마음에 들지 않는 것을 제대로 작동하고 있을지라도 "버그"로 보게 만든다.또한 '원픽스'라는 용어는 결코 마음에 들지 않았는데, 그것은 "우리는 그것이 부서진 것을 알지만 부서진 채로 놔둘 것이다"라고 말하는 것 같다.IMHO는 "진짜 버그"에 대한 어떤 보고서도 "원픽스"가 되어서는 안 된다.미디어위키나 그 문제에 대한 어떤 소프트웨어 개발자들이 어떤 이유로든 "버그가 아님"을 변경하거나 기능 요청을 이행하지 않기로 결정한다면, 그러한 보고서를 종결하는 더 좋은 용어는 "AINTBROKE"일 것이다.현재 버전의 소프트웨어에서 간단히 수정할 수 없는 진정한 의미의 오작동이라면 "CANTFIX"라고 불러야 한다. --Ron Ritzman (talk) 12:36, 2009년 10월 30일 (UTC)[응답]

흠, 그건 그냥 이름만 바꾼 거잖아.각 버그나 요청에 대해 의미 있는 평가를 하는 것이 더 좋을 것이다. 즉, 버그나 요청에 얼마나 많은 작업이 필요한지, 우선순위가 무엇인지, 그리고 결과적으로 우리가 얼마나 오랫동안 버그가 해결되기를 기다려야 하는지 합리적으로 예상할 수 있는지를 말이다.현재로서는 알 수 없으며, 버그/특징이 없는 상태가 얼마나 오래 유지될 것인가에 따라 해결 결정을 내려야 한다.-코트니스키 (대화) 13:56, 2009년 10월 30일 (UTC)[응답]

실제로 마감일을 맞출 의무가 있는 유료 개발업자에게 할당되거나 견적을 내는 사람이 즉시 작업을 시작하려고 할 정도로 변경이 중요하다고 간주되지 않는 한, 그러한 추정은 일반적으로 터무니없는 추측이 될 것이다.예를 들어, 누군가가 T20019에 도착하기까지 약 7개월이 걸렸지만, 수정 자체는 한 시간 정도밖에 걸리지 않았다.Mr.Z-man 17:08, 2009년 10월 30일 (UTC)[응답]

그 상황은 꽤 흔한 것 같아.이런 요청을 하는 것은 정말 좌절스럽다. 그들이 해결하는데 많은 시간이 걸리지 않을 것이라는 것을 알면서도, 언제 누군가 그들에게 다가갈 것인지에 대한 응답을 받지 못한다.그나저나, 그 사람은 누구라고 생각하나?확실히 사용자들의 투표는 무엇이 중요하고 무엇이 중요하지 않은지를 결정할 때 주요 기준이 되어야 한다. --Kotniski (토크) 17:43, 2009년 10월 30일 (UTC)[응답]

나는 당신의 좌절감을 공유하며 대부분의 경우 Bugzilla는 투표가 있든 없든 특징과 개선 요청을 위한 묘지라는 것을 발견했다.어떤 것을 구현하는 유일한 방법은 다른 수단으로 개발자를 관심을 갖게 하는 것뿐이다.물론 이것은 좌절스럽고 프로페셔널하지 못하지만, 파이어폭스와 같은 다른 커뮤니티 주도의 프로젝트를 연상시킨다.Cacycle (대화) 2009년 10월 30일 (UTC) 19:07 [응답]

글쎄, 우리는 그 문제에 대해 동의하는 것 같은데...이것에 대해 뭔가 하는 것에 대한 시작점 논의로서, 이것은 어떨까? (a) 위키백과:MediaWiki/토론 (b) 위키백과:MediaWiki/토론/개발자용.B는 A에서 나오는 현재의 견해와 질문의 요약으로서 아마도 매월 1일에 간헐적으로 업데이트될 것이다.각 업데이트 후 개발자에게 IRC를 통해 통보하고 의견 제시/답변을 요청한다.Rd232 20:05, 2009년 10월 30일 (UTC)[응답]

문제는 개인의 관심사와 선택, 높은 우선순위 수정, 섹시한 새로운 특징에 의해 주로 추진되는 개발자들의 업무 윤리다.외부로부터의 자원 봉사자들에게 어떤 추가적인 일을 강요하는 것도 실제로 가능하지 않다.유일한 해결책은 아마도 투표 수와 요청 날짜에 따라 안내될 수 있는 체계적이고 진지한 방식으로 Bugzilla 백로그를 정리하기 위해 개발자들 간에 자율적으로 합의하는 것일 것이다.Cacycle (대화) 2009년 10월 31일 (UTC) 17:16, 응답

나는 두 번째 문장이 어떻게 첫 번째 문장에서 이어지는지 모르겠다.공동체의 우선 순위에 대한 잘 구성된 의사소통은, 일종의 동료 압력으로서, 성취할 수 있고, 어느 정도 영향을 미칠 것 같다.Rd232^talk 17:40, 2009년 10월 31일 (UTC)[응답]

네, 자원봉사자들에게 어떤 것도 강요할 수는 없지만, 동료들의 압박은 놀라운 효과를 발휘한다(위에서 누군가가 말한 것은 개발자들이 편집자를 그들의 동료라고 생각하지 않는다는 것을 의미한다는 것을 제외한다면, 음...)비록 새로운 CTO(또는 CTO의 선택을 하는 사람들, 프로세스가 진행 중이라면)를 이 문제에 대해 도청하는 것이 중요하다고 생각하지만; 어떻게 보면 우리로부터 보수를 받는 사람은 프로젝트의 요구에 훨씬 더 잘 반응해야 한다. --Kotniski (talk) 2009년 10월 31일 (UTC) 응답하라.

만약 우리가 또래가 아니라면, 확실히 고객인가 뭔가?어느 쪽이든, 우리가 원하는 것에 대한 명확하고, 짧고, 때때로 보여주는 것은 그들에게 어떤 의미가 있어야 한다.Rd232^talk 20:47, 2009년 10월 31일 (UTC)[응답]

아니, 우리는 다른 그룹이야.그것이 항상 문제였다.백과사전에 바치지만 시간과 기술이 다른 자원 봉사자들.개발자들은 우리를 위해 일하는 것이 아니라, 우리가 글을 쓰는 것을 돕기 위해 우리에게 기부한다.유용한 방법으로 기부금을 구조화하는 것은 거의 예술의 한 형태다.구조화된 원소만이 우리에 의해 조종될 수 있다.전에는 브리온이었지만, 그는 기술자보다 CTO에 약했다.새로운 CTO를 통해 우리가 그 초점에 영향을 주고 커뮤니케이션을 개선할 수 있기를 바란다.물론, 우리는 초대하고 토론할 수 있지만, 개발자들이 접근할 수 없거나, 비합리적이거나, 집중력이 없는 것은 아니다.아마도 개발자들이 위키에서 활동하는데 도움이 되는 만큼 때때로 그들의 안전지대인 위키에서 벗어나 모험을 하는 것이 지역사회에 적합할 것이다.우리는 일부 사람들이 핵심 개발자 커뮤니티를 "적대적" 또는 이상한 것으로 간주하는 것처럼, 우리 자신의 커뮤니티는 외부 개발자들에게 이해하기 어려운 유사한 규칙과 관습에 묶여 있다는 것을 잊고 있다.그리고 우리는 물론 개발자들의 작업에서 이익을 얻고 있는 1000대 이상의 위키 하나라는 것을 기억해야 한다.우리는 중요할지 모르지만 확실히 우리만이 의견을 가진 위키는 아니다.우리는 개발자들이 모든 200개의 언어 변형 위키백과 + 다른 모든 설치에 참여하기를 기대할 수 없다.나는 위키피디아가 아니라고 생각한다.미디어위키/토론은 효과가 있겠지만, 나는 그가 이 커뮤니케이션을 그의 초점 중 하나로 만들기 위해 합류할 때 미래의 CTO에 탄원해야 한다고 생각한다.—DJ (대화 • 기여) 13:17, 2009년 11월 1일 (UTC)[응답]

"나는 위키피디아가 아니라고 생각한다.MediaWiki/토론은 효과적" - 왜 안 되는가?개발자들이 '참여'하는 것을 기대할 수 없다고 말하지만, 내가 제안한 것은 그게 아니다.나는 그들이 읽고 이상적으로 반응할 수 있는 일종의 월간 메모를 개발하자고 제안했다.매월 생산된 이 메모는 차이가 있다면 en.wp보다 더 도움이 되는 곳이면 어디든 추진될 수 있다.그리고 당신은 개발자들이 접근할 수 없다고 말한다. 아마도 그렇지 않을 것이다. 하지만 귀중한 소수의 사람들만이 그들에게 어떻게 접근해야 할지 알지 못한다. 그것은 아마도 좋은 일일 것이다. 우리는 그것들을 홍수처럼 만들고 싶지 않다.Rd232 16:22, 2009년 11월 1일 (UTC)[응답]

위에서 언급했듯이, 만약 내가 조직한다면 나는 mw와 같은 것을 가지는 것에 기울 것이다.모든 위키 커뮤니티가 자체적인 피드백 메커니즘을 개발하기 보다는 커뮤니티가 접근할 수 있는 위키 환경이 될 수 있는 조직적 프런트로서의 기능 요청.한 가지 장점은 아마존닷컴이 개발자들이 "살고 있는" 장소 중 하나라는 것이다.단점은 아마존닷컴이 역사적으로 많은 논의를 위해 이용되지 않았고 사람들이 실제로 그러한 목적을 위해 그것을 받아들일지는 불분명하다는 점이다.위치와 상관없이, 나는 그 솔루션이 적어도 두 개의 기능적인 조각이 필요하다고 생각한다.1) 다양한 제안을 검토하고 원하는 사항과 기술적으로 타당한 사항에 대한 합의를 모색하기 위한 토론 포럼, 2) 승인된 내용을 요약하고 개발자에게 명확하고 직접적인 지침을 제공하는 방식으로 취해야 할 실행 단계를 제안하기 위한 검토 과정.이상적으로는 기술 스태프의 구성원이 두 가지 모두에 관여할 수 있지만, 특히 후자에 대해서는 더욱 그러하다.드래곤즈 비행 (토크) 09:55, 2009년 11월 2일 (UTC)[응답]

위의 논의에 대한 발걸음으로, 만약 CTO 고용이 많은 요건으로 "편집자와 개발자 커뮤니티 간의 조정을 돕는다"고 한다면 나는 오히려 놀랄 것이다.Wikimedia는 여러 데이터 센터에 수백 대의 서버가 있는 상위 10대 웹 타깃이다.나는 CTO의 최우선 과제가 조직의 하드웨어 요구를 충족시키고 가용 하드웨어를 최대한 활용하도록 기반 소프트웨어 이니셔티브를 조정하는 것이라고 생각한다.그렇다, CTO 업무에는 강력한 관리 및 커뮤니케이션 요소가 있지만, 편집자와 함께 일하는 것은 개발자나 재단 직원들과 일하는 것에 비해 아마도 의사소통 우선 순위 목록에서 낮을 것이다.좀 더 현실적으로, 직원 개발자(그러나 CTO보다 순위가 낮은 사람)가 지역사회 주도의 이니셔티브를 촉진하는 책임을 맡기를 바랄 수 있다.드래곤즈 항공편 (토크) 2009년 11월 2일 (UTC)[응답]

우리가 할 수 있는 것은 영어 위키백과와 관련된 주제별 강화 요청 목록을 유지하는 것이다; 그것은 지역 사회 수준에서 노력을 조정하는데 도움을 줄 수 있고 개발자들은 한 가지 또는 다른 요청에서 관심을 찾을 수 있다; 그것은 지역사회와 기술 직원들 사이의 더 나은 의사소통을 위한 단계가 될 수 있다.세나리움 (대화) 17:21, 2009년 11월 4일 (UTC)[응답]

프로포즈

내게 생각이 있어.만약 재단이 개발자, 시스템 관리자, 직원, en.wp 커뮤니티, 커먼즈 커뮤니티, 그리고 5개의 다른 더 작은 언어 커뮤니티에 다음 CTO에 "Plea"를 쓰라고 한다면 어떨까?다음 CTO가 고려할 주요 이슈와 문제점을 기술한다.그렇게 함으로써 새로운 CTO는 그가 함께 일해야 할 여러 그룹의 도전, 의견, 감정에 대한 개요를 얻을 수 있다.—DJ (대화 • 기여) 13:26, 2009년 11월 1일 (UTC)[응답]

그건 시도해 볼 만한 가치가 있겠지만, 내 제안서를 형편없는 핸들 위에 내놓기 위해 내 en.wp 월간 메모와 경쟁해야 할 이유를 모르겠다.Rd232 16:22, 2009년 11월 1일 (UTC)[응답]

WP:DevMemo

나는 개발자들과의 의사소통에 관한 구조화된 토론에 대한 나의 아이디어를 구현하고, 일반적으로 우리가 실제로 원하는 것에 대한 우리의 생각을 조직하기 위한 시도로 WP:DevMemo를 만들었다.댓글을 달아주시고, 피칭도 하시고, 페이지도 봐주시고.Rd232 15:22, 2009년 11월 5일 (UTC)[응답]

아이디어 떠다니기 (여기서는 아무것도 변하지 않기 때문에 그것이 격추될 것이라는 것을 알고 있다)

출판된 백과사전 기사가 얼마나 최신인지 출판 날짜까지 가늠하기는 다소 쉽지만, 위키백과 기사로 그렇게 쉽지는 않다.그러면 메인 페이지의 "마지막 업데이트" 필드는 어떨까?물론, 바보 같은 짓은 아니지만 적어도 지금 없는 것보다는 나은 안내서가 될 것이다. --Malleus Fatuorum 05:16, 2009년 11월 1일 (UTC)[응답]

내 생각에 우리는 이미 모든 페이지의 바닥글에 "이 페이지는 마지막으로 수정한 날짜..."라는 위키미디어 로고 오른쪽에 있는 것을 가지고 있다.Equazcion (대화) 05:24, 2009년 11월 1일 (UTC)

네가 말한 우표가 사실 메인 페이지에는 없는 것 같구나.왜 그런지...Equazcion(토크) 05:27, 2009년 11월 1일 (UTC)

메인 페이지를 포함한 모든 (비특수) 페이지에 있지만 메인 페이지에는 최소한 각각의 MediaWiki에 각각 있는 Monobook과 Vector 둘 다에 대한 CSS가 있다.Fo.css 페이지.그것을 메인 페이지에 넣는 것은 각 페이지에서 코드의 줄이나 그 정도의 코드를 삭제하고 등록되지 않은 사용자의 캐시가 만료될 때까지 한 달 정도 기다리는 것만큼 간단할 것이다.자, 나는 이것의 유용성이 어떤 것인지 모르겠다. 왜냐하면 그것은 위키피디아 전체가 아니라 메인 페이지가 편집된 마지막 시간만을 반영할 것이기 때문이다. 그리고 위키피디아 전체는 너무 자주 편집되어 어차피 그런 자료들은 대부분 쓸모없을 것이다.나는 그 생각에 반대하지는 않지만, 왜 누가 그것을 실행했는지 이해할 수 없다.설명할 수 있겠나, 말레우스?{{Nihiltrestalkedits}}}05:36, 2009년 11월 1일 (UTC)[응답]

페이지 하단에 있는 작은 텍스트로 숨겨져 있는데, 아마 아무도 보지 않을 겁니다.하지만 나는 FA 청동 스타에게 동등하게 중요한 것을 제안하고 있었다. 말레우스 파투오룸

여기 뭔가 혼란스러운 것 같은데, 아마 내 잘못일 거야.각 기사의 최종 업데이트 시기에 대한 두드러진 전시를 말하는 겁니다. --MalleusFatuorum 05:41, 2009년 11월 1일 (UTC)[응답]

그래서 당신은 '마지막으로 업데이트된' 도장이 더 돋보이기를 원한다.나도 거기에 동의할 수 있어.난 그걸 전혀 알아차리지 못했어.나는 현재의 디스플레이가 단지 기술적인 귀속과 참조 목적을 위한 것이라고 생각한다. 사람들이 주목해야 할 실용적인 것 보다는.고려해 볼 만한 것일 수도 있어Equazcion(토크) 05:48, 2009년 11월 1일 (UTC)

네, 바로 그겁니다. --MalleusFatuorum 06:00, 2009년 11월 1일 (UTC)[응답]

총에 맞아 쓰러지는 걸 볼 수 있다고 (용서해줘 :P )나는 그 정보가 흥미롭다는 것에 동의하지만, 일반 독자도 파워 유저도 이 제안된 변화로부터 이익을 얻지 못할 것이라고 생각한다. 그 정보는 이미 거기에 있지만, 단지 독자의 면전에 있지 않다.그것을 바닥글에 남기지 않고 사용자의 얼굴에 넣는 것은 a) 무시해야 할 크롬 텍스트가 더 많은 독자에게 짜증나는 일, b) 따라서 읽을 크롬 텍스트가 더 많을 것이고, c) 어떤 점잖은 페이지 분석 때문에 상관없는 것으로 숨길 것 같은 파워 유저에게는 짜증나는 일이다.어쨌든 역사 페이지를 사용할 거야나는 특징의 사용 특성이나 사용 빈도를 더 두드러진 배치를 정당화하는 것으로 보지 않는다.그것을 그렇게 두드러지게 만드는 것에 특별한 이점이 있는가?{{Nihiltrestalkedits}} 06:11, 2009년 11월 1일 (UTC)[응답하라]

(충돌 편집)백과사전을 참조할 때 1911년판인지 2009년판인지 신경 쓰십니까?만약 그렇지 않다면, 물론 내 제안은 내가 알고 있는 것처럼 무시당한다. --MalleusFatuorum 06:26, 2009년 11월 1일 (UTC)[응답]

그것은 지푸라기 같은 논쟁이다.1911년 판과 2009년 판의 차이점에 신경을 쓰는 것은 당연한 일이지만, 짚맨으로서 주는 98년과는 반대로 (내가 언급했듯이) 시간의 차이가 기껏해야 2초나 2라면 그렇게 상당한 차이가 있을 것이라고 기대하는 것은 어리석은 일이다.백과사전 전체가 5초 전에 마지막으로 편집되었다는 것은 합리적인 가정이다.개별 기사의 경우 그 차이는 더 흥미롭지만 여전히 대부분의 독자들에게 사소한 용도의 차이가 있으며, 따라서 두드러진 위치에서는 유용하지 않다.나는 인터페이스를 가능한 한 간단하게 만드는 것을 폭넓게 지지할 것이며, 이 제안은 그 원칙에 반하는 것 같다.{{Nihiltres talk edits}}}16:24, 2009년 11월 1일 (UTC)[응답]

"실제" 논쟁은 당신이 방금 내놓은 것이다.2005년 허트포드셔 석유 저장 터미널 화재에 관한 기사를 보고 있는데, 2005년 이후 업데이트되지 않았다는 것을 알게 되면, 즉시 구식임을 알게 된다. --MalleusFatuorum 16:42, 2009년 11월 1일 (UTC)[응답]

아니, 그것은 어리석은 것이 아니다. 왜냐하면 나는 "개개의 기사에 있어서 차이는 더 흥미롭지만, 대부분의 독자들에게는 여전히 사소한 사용"이라고 구체적으로 말했기 때문이다.나는 그 정보의 이용가능성은 좋지만, 그것이 더 두드러질 필요는 없다고 생각한다.{{Nihiltres talk edits}}} 22:10, 2009년 11월 1일 (UTC)[응답]

(갈등 편집) 기사를 읽고 있을 때, 대개 애매한 주제를 찾아보고 난 후, 개정안이 몇 년 됐는지 눈치채지 못할 때가 많다.나는 한 페이지의 역사를 방황하며 그 페이지가 업데이트 된 지 얼마나 되었는지 놀라움을 금치 못했다.그것은 정말로 기사에 전혀 다른 빛을 던질 수 있다.나는 정보가 마지막으로 업데이트 된 시간이 결정적이고, 보통 다른 매체에서 명백하다고 생각한다.그 우표는 귀찮을 정도로 두드러질 필요가 없다.단지 시간과 날짜, 아마도 말레우스가 제안한 것처럼 오른쪽 상단 모서리에 있는 작은 FA 아이콘들이 어디로 가는지.Equazcion (대화) 06:21, 2009년 11월 1일 (UTC)

시도 및 실패. --사이버코브라(토크) 06:19, 2009년 11월 1일 (UTC)[응답]

대다수가 찬성하는 것 같았다.무엇이 그 토론을 실패로 만들었는가?도청장치를 해 본 적 있어?Equazcion(토크) 06:24, 2009년 11월 1일 (UTC)

대다수는 기존의 "마지막으로 수정된 분야" 옆에 "경과된 시간" 분야를 추가하는 것을 지지했지만, 두 분야 중 어느 한 분야를 더 두드러지게 만드는 데는 찬성하지 않았다.해당 분야를 추가하기 위한 버그가 신청되었다: [6] --Cybercobra(토크) 06:28, 2009년 11월 1일 (UTC)[응답]

아쉽다.나는 정말로 모의훈련이 Equazcion (talk) 06:31, 2009년 11월 1일 (UTC) → 을 약속한다고 생각한다.

이것은 정말 재방문되어야 한다.그것은 나에게 매우 직관적으로 보이며 심지어 현재 웹 사이트에서 정보가 업데이트되는 페이지에서도 기대되고 있다.Equazcion(토크) 06:33, 2009년 11월 1일(UTC)

그 모형이 바로 내가 보고 싶은 것이다. --MalleusFatuorum 06:36, 2009년 11월 1일 (UTC)[응답]

나는 아니다. 나는 장점들에 대해 전적으로 확신이 없지만, "마지막 편집 이후 2시간" 스타일에 대해서는 분명히 반대한다. "이 버전은 xx/xx/xxx/xxx yy:yy"가 형식적으로 더 나을 것이다.필자는 많은 기사들이 사실 많은 업데이트를 필요로 하지 않고, 다른 기사들도 그것을 많이 필요로 하기 때문에, 독자들은 마지막 수정한 것을 어떻게 해석해야 하는지 모를 수도 있고, 그것은 분명히 더미 편집이 마지막 수정한 것과 부딪히도록 장려할 것이기 때문에 확실하지 않다.Rd232 07:53, 2009년 11월 1일 (UTC)[응답]

솔직히 지금 우리가 가진 것 이상의 것을 갖는 것은 무의미해 보인다.페이지들은 항상 편집되고 있다.그리고, 어느 대학생이 말해주겠지만, 아무도 위키피디아를 논문이나 프로젝트의 출처로 사용하고 있지 않다(그러나 위키피디아의 출처를 사용하는 것은 전혀 다른 문제다).나는 그것을 바꾸는 것에 반대하지 않는다. 단지 그것이 왜 이슈인지 잘 모르겠다.내가 본 바로는 중요 기사들, 정기적으로 업데이트 되는 것, 그리고 어떤 불분명한 것들의 기사들은 단순히 추가될 수 있는 실제 정보가 없을 수도 있기 때문에 그렇게 자주 업데이트되지 않을 수도 있다.아나킨젯 (대화) 08:22, 2009년 11월 1일 (UTC)[응답]

보이는 바와 같이, 이것이 변경되지 않는다면, 페이지 상단에 이것을 눈에 띄게 보여주고 싶어하는 사람들을 위한 사용자 스크립트가 있을 수 있는가?MTC (대화) 08:57, 2009년 11월 1일 (UTC)[응답]

영향을 미치는 페이지와 시간 기반 변수를 캐시할 필요성 때문에 이것은 결코 실행되지 않을 것이다.사람들이 원하는 {{{{currentuser}}}개의 변수처럼 서버 쪽에서는 절대 일어나지 않을 것이다.이것은 시간의 차이 때문에 모든 페이지를 캐시할 수 없게 만들 것이다.만약 이것이 실행된다면 그것은 클라이언트측 JavaScript로 수행되어야 할 것이다.β^_command 11:31, 2009년 11월 1일 (UTC)[응답]

나는 사이트들이 24시간 이내에 변경된 페이지에 계산된 "이후 시간"을 사용하고, 24-48시간 전에 변경된 페이지에 대해 "어제 @[ 시간"으로 전환한 다음, 그 이후의 모든 것에 대한 날짜와 시간을 보여주는 것을 본 적이 있다.지난 24시간 동안 변경된 페이지에 대해 "이후 시간"만 계산하고 캐시하면, 서버에는 상대적으로 부담이 적을 것이라고 생각한다.Equazcion(토크) 13:33, 2009년 11월 1일 (UTC)

나는 사소한 편집이 오타를 고치거나 반달리즘을 되돌리는 것과 누군가가 기사를 검토한 업데이트 사이에는 차이가 있다고 생각한다.그래서 만약 이것이 계속 진행된다면, 나는 사소한 편집이나 롤백된 편집을 무시하는 것을 제안할 것이다.eereSpielCequers 13:43, 2009년 11월 1일 (UTC)[응답]

User:에서 스크립트를 작성했다.Anomie/lastmod.js를 마지막으로 수정한 날짜를 구석에 넣는다.하지만 그것은 그것이 "3분 전에 반달리즘+반복/인터위키 봇 편집/소음부 문장 부호 조정"을 제외하고 정말로 "2년 전에 마지막으로 수정한 것"인지조차 판단하려고 하지 않는데, 이는 과거 수정본을 다운로드하는 데 너무 많은 노력을 필요로 하기 때문이다.Anomie⚔ 14:54, 2009년 11월 1일 (UTC)[응답]

아노미야, 고마워!멋져 보인다.이것은 기계 장치에 포함시키는 것이 좋을 것이다.하지만 미디어위키에서는 전반적인 구현으로 간주되어야 한다고 생각한다.Equazcion(토크) 15:51, 2009년 11월 1일 (UTC)

좌표가 보통 btw?—DJ (토크 • 기여) 16:24, 2009년 11월 1일 (UTC)[응답하라]는 곳이 아닌가?

그래, 그렇지.방금 위에서 제시한 포지셔닝으로 갔었는데, 누군가 더 좋은 제안이 있다면 대본 변경에 대해 알아볼게.개인적으로, 나는 그것이 모든 사람들에게 가능해지는 것을 원하지 않지만, 만약 충분한 수요가 있다면 누군가가 기계화 하는 것은 쉬울 것이다.Anomie⚔ 18:18, 2009년 11월 1일 (UTC)[응답]

그 대신 독자들이 A) 최신이고, B)를 로드하기 전에 몇 초 동안 파손되지 않았는지 확인하기 위해 페이지의 역사를 확인하도록 장려해야 하지 않을까?이것이 위키피디아가 반신뢰적이라고 여겨지는 이유다: 파손된 페이지를 볼 때는 절대 모르기 때문이다 - 역사를 확인하지 않는 한. - ʄooʏiaɲ 18_¢:51, 2009년 11월 1일 (UTC)[응답]

빈번한 난해한 해결사로서, 나는 마지막 편집 날짜나 시간이 종종 그 기사가 최신의 정도와 관계가 없다고 확신한다.내가 하고 있던 유일한 일은 내가 몇 년 동안 만지지 않았던 기사에 대한 혼란스러운 링크를 고치는 것이었던 곳에서 편집을 했을 것이라고 확신하지만, 지금은 아주 최근에 편집되었다는 것을 나타낸다. bd2412 T 02:57, 2009년 11월 4일 (UTC)[응답]

외부 링크 섹션 개선

여보세요

나는 최근에 위키미디어 재단 Anthere의 전 이사장과 이야기를 나눌 수 있는 기쁨을 누렸다.나는 위키피디아 페이지에 Webzzle Discovery permalinks(또는 버튼)가 있는 것에 대한 관심을 설명했고, 이제 우리는 이 가치 제안에 대한 당신의 의견을 듣고 싶다.

당신의 동의에 대한 데모를 보여주기 위해 우리는 프랑스어와 영어로 된 2페이지에 링크를 추가했다.이 주제에 대해 함께 논의하기 위해 앞으로 15일 동안 그것들을 보관하십시오.

English http://en.wikipedia.org/wiki/Champagne,_France

프랑스어 http://fr.wikipedia.org/wiki/Vin_de_Champagne.

여러분이 흥미롭다고 생각하시거나, 웹즐을 향상시키기 위해 함께 노력하시거나, 여러분이 좋아하지 않으시거나, 위키피디아를 더 이상 다루지 않을 겁니다.

우리는 4가지 이유로 웹즐을 개발했다.

- 1 - 위키백과의 사용 연장위키백과 페이지의 웹즐 탐색 기능을 통해, 위키백과 편집자들은 그들의 콘텐츠에 더 많은 가치를 더할 수 있고 최종 사용자에게 위키백과 페이지의 주제에 관한 더 많은 관련 지식을 찾을 수 있는 가능성을 제공할 수 있다.

- 2 - 외부 링크의 관련성 개선웹즐은 새로운 "상호 순위" 기술을 사용하여 외부 링크의 순위를 매긴다.웹즐은 키워드 대신 개념, 오브젝트 및 오브젝트 구조를 사용하여 내용을 기술한다.기고자의 각 행동은 내용을 채점하는 데 사용된다.유추하면 구글 페이지랭크와 비슷하지만 2차원(URLs and Users)이다.URL 점수는 자격을 부여한 사용자의 점수를 사용하여 계산하고, 유저의 점수는 그가 부여한 URL 점수를 사용하여 계산한다.소셜네트워크에서 URL과 사용자를 어떻게 채점할 것인가에 대한 문제를 해결하는 선순환 시스템이다.우리는 1999년부터 그것에 대해 연구하고 있다.이 기술은 스타트업에 의해 개발되어 CNRS(프랑스 국립과학연구센터, 나사로 유명한 프랑스)에서 특정 주제에 관한 전문지식, 문서, 웹 자원을 검증하고 찾기 위해 사용되어 왔다.상호 보험 사업처럼, 우리의 순위 기술은 만약 그들이 주제별 스팸 발송자보다 커뮤니티 사용자들이 더 많다면 매우 잘 작동한다. 웹즐을 좋아한다면 그럴 것이다.사용자 수와 URL 수가 증가함에 따라 품질이 향상된다.

- 3 - 편집자의 작업 감소여러 개념으로 검증된 링크는 다른 위키백과 페이지에 자동으로 관련될 수 있다.편집자들은 아무 것도 하지 않고도 다른 편집자들의 작업으로부터 이익을 얻을 수 있다.더 많은 편집자들이 Webzzle에서 링크를 선별할수록, 외부 링크를 유지하기 위한 작업량은 줄어들고 품질은 최고가 될 것이다.

- 4 - 위키백과에서 스팸 발송자 제거오늘날, 상업 사이트들은 교통의 혜택을 보기 위해 위키피디아에 등장하기를 원한다.위키피디아에서 항상 이러한 사이트들을 삭제하는 대신에, 우리는 그것들을 웹즐에 넣을 것을 제안한다.이들 링크가 좋으면 당연히 좋은 상호 순위 점수를 받게 된다.만약 그들이 나쁘다면, 그들은 첫 번째 결과에서 제시되지 않을 것이다(상호 순위 알고리즘의 일부 실행 후).오늘날 웹즐에 있는 대부분의 링크는 가상 웹즐 사용자로부터 온다.우리는 스팸 발송자들과 싸우기 위해 이 사용자를 사용한다.이 사용자는 품질을 높이기 위해 과체중을 할 수 있는 능력이 있다.우리는 또한 스팸 발송자 역할을 하는 사용자의 점수를 0으로 매기기 위해 사용되는 "신뢰 순위" 메커니즘을 가지고 있다.

웹즐 기술은 칭찬받고 있다.이 기술은 비경쟁 프로젝트에 무료로 사용할 수 있다.

우리는 당신과 긍정적인 대화를 할 수 있기를 기대한다.자비에 바우코이스자비에르(점) 바우코이스(at) 웹즐(점) com

나는 단지 이것이 문제를 찾는 해결책처럼 보인다고 말할 것이다.효과적으로 편집자들이 이러한 것들을 제3자에게 아웃소싱하기를 원하는 것은 무료 백과사전을 만드는 아이디어에 도움이 되지 않는다.Q 08:01, 2009년 11월 2일 (UTC)[응답하라]

OverordQ에 동의하십시오.또한, 만약 소프트웨어가 오픈 소스가 아니라면, 당신은 지역사회를 설득하는 데 어려움을 겪을 것이다.우리는 오히려 문제에 대한 비무료(Speech & Beer) 해결책의 리어리. 76.123.56.217 (토크)

나는 또한 이것이 무엇을 해결하는지 정말 불분명하다.그냥 링크 가이드를 이런 식으로 도입하는 것 아닌가?—DJ (대화 • 기여) 2009년 11월 2일 (UTC) 12:04, 2[응답]

샴페인(와인)의 웹즐 링크가 두 번 반환된 이후:

• 웹즐 마을 펌프에서 논의할 기능 탐색(http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Improve_the_external_links_section)

이것은 대부분의 검색 엔진과 비슷한 많은 링크들을 만들어낸다.이리저리 쑤셔보았지만, 이 링크들이 어떻게 생성되거나 순위가 매겨지는지 잘 보이지 않아 구글이나 빙과 다른 것은 보이지 않는다.우리는 종종 Open Directory Project의 페이지에 링크하는데, 이것은 링크가 추가되는 방법이 분명하고 사람들이 링크를 제안하거나 변경할 수 있게 해준다.사용법이나 장점이 보이지 않을 뿐이다. ---— Gadget850 (Ed) 12:48, 2009년 11월 2일 (UTC)[응답]

이 '웹즐'을 제거하기보다는 스팸을 추가하는 게 핵심인 것 같다.Wikitech-l에 있는 이 실 또한 관련이 있을 수 있다.Anomie⚔ 13:32, 2009년 11월 2일 (UTC)[응답]

나는 너와 의논하기 위해 여기에 왔다.나는 안저어와의 건설적인 대화에 이어 설명과 토론을 초대하기 위해 이 긴 글을 올렸다.DMOZ는 웹즐과 같은 방식으로 링크를 가지고 있다.우리의 경우, 링크는 편집자에 의해 설정된다(Save 기능을 통해 당신은 우리의 사이트에서 찾을 수 있다).나는 DMOZ가 좋았고, 지금은 오래되었고, 편집자들의 자격증 취득에 도움이 되지 않는 디렉토리라고 생각한다.우리는 새로운 상호 순위 기술의 혜택을 받는 협업 시스템을 구축할 것을 제안한다. 협력 기술과 구글 랭킹 기술을 사용하는 일종의 DMOZ이다.특허에 대해서는 (공영권을) 나눠줬다.누구나 그 기술을 사용할 수 있다.나는 부정직한 사람이 같은 기술을 바탕으로 웹 익스플로러를 하는 것을 보고 싶지 않기 때문에 그 문장을 붙였다.또한 "왜 웹즐을 사용하는가?"를 이해하는 것도 매우 중요하다.나도 그래, 난 구글을 사용해.하지만 일반적으로 위키피디아에서 웹으로 가기 위해 무엇을 하는가? 우리 쪽에서는 구글로 돌아가서 여러 키워드의 조합을 시작하고 쓸모없는 페이지들을 많이 연다.웹즐로 우리는 당신이 원한다면 "소셜 검색"을 통해 편집자들의 작업의 혜택을 누릴 수 있다.위키피디아에 올라타지 않고, 더 질적으로 떠날 수 있는 엔진이 있을 것이다.위키피디아의 새로운 용법이다.스팸과 관련하여, 나는 만약 편집자들이 웹즐에서 링크를 검증한다면, 상호 순위 기술 덕분에 진짜 스팸 발송자들은 발표되지 않을 것이라고 반복한다.마지막으로, 위키텍에 대한 링크의 시간 이후, 나는 적어도 Anthere에게 설명할 기회가 있었고, 이것이 내가 오늘 편집자와 최종 사용자들을 위한 Webzzle의 관심에 대해 말하고자 하는 이유다.가치 제안이 편집자와 최종 사용자에게는 가치가 없다고 생각하지 않는가? 웹진

우리는 프랑스 비스트로에 대해 좋은 대화의 시작을 하고 있다.영어 버전에서, DMOZ와 Webzzzle 링크를 넣을 수 있는 위키피디아에 새로운 섹션이 있는 것에 흥미있는 사람이 있는가?12:53, 2009년 11월 5일 사용자:88.166.5.153

거미줄

설명 페이지는 기사가 아니다.

위키백과별:기사란 무엇인가? 설명 페이지는 기사가 아니다.그런데 왜 우리는 그들을 계속 하나로 계산할까?이것은 이전에 제기되어 지지와 공감대를 얻었지만 실행된 적이 없다.#REDirect처럼 #DISAMBIG 등의 태그를 추가하면 실제 기사와는 쉽게 구분할 수 있다고 본다.이것들은 단순히 그것이 그렇게 식별되는 모든 dab 페이지의 템플릿을 통해 전달될 수 있다.dab 페이지가 기사라는 것을 우리가 계속 믿지 않도록 이것을 실행해 줄 수 있을까?고마워 레이와스92^Talk 00:30, 2009년 11월 2일 (UTC)[응답]

여기서 문제가 되는 현실적인 문제는 무엇인가?위키피디아가 주장하는 총 기사 수에 대해 염려하십니까?아니면 뭐?Equazcion (대화) 00:35, 2009년 11월 2일 (UTC)

누가 우리가 그것들을 기사로 세고 있다고 하는가?AFAIK는 이미 아니니까 무슨 말인지 잘 모르겠어.PC78 (대화) 00:37, 2009년 11월 2일 (UTC)[응답]

디스컴비그 페이지는 현재 기사로 집계되지 않고 있다.MediaWiki:디스앰비게이션 페이지는 디앰비게이션 페이지를 특수:로 배치하는 템플릿을 자세히 설명한다.다시 한 번 말하지만, 현재 기사 수에는 포함되지 않는다. --Izno (토크) 00:42, 2009년 11월 2일 (UTC)[응답]

난 그들이 여전히 스페셜에서 숫자를 세고 있다고 생각했어.통계 및 기타 카운트.그런 내용을 담은 토론이나 다른 페이지로 안내해 주시겠습니까?스페셜에 출연한다.새 페이지.And Special:디스컴비게이션에는 dab 페이지 자체가 아니라 dab 페이지로 잘못 연결되는 기사가 나열된다.레이와스92^Talk 01:07, 2009년 11월 2일 (UTC)[응답]

네가 잘못 알고 있다.Special에 보고된 바와 같이:통계 및 {{NUMBOFARTILS}}의 "내용 페이지"는 길이가 0보다 크고 리디렉션으로 표시되지 않는 콘텐츠 네임스페이스의 모든 페이지(enwiki의 경우 기사 공간일 뿐)이다.코드 [7]에는 설명 페이지에 대한 예외가 없다.드래곤즈 비행 (토크) 02:39, 2009년 11월 2일 (UTC)[응답]

여기서의 문제는 리디렉션은 모든 위키에서 명확한 기술적 의미를 가지고 있지만, "비내용" 기사 공간 페이지(예: 설명 페이지, 색인 페이지, 목록 페이지 또는 기타)의 개념은 현재 데이터베이스에 명확한 정의를 가지고 있지 않다는 것이다.대신에 그것은 지역 기고자들에 의해 만들어진 순전히 콘텐츠 기반의 차별이다.위키에서 다른 위키로 이동하면서 '내용' 페이지로 무엇을 계산해야 하는지에 대한 기대치가 달라질 수 있다는 뜻이다.#DISAMB와 같은 레이블인터넷 거버넌스는 여기서 말이 되겠지만, 현장에서는 난장판을 사용하지 않는 것은 말이 되지 않을 것이다.__NOTContent__와 같은 좀 더 일반적인 라벨이 이치에 맞을 수도 있다.개발자들은 일반적으로 모든 Mediawiki 위키에서 작동할 수 있을 만큼 충분히 넓은 솔루션을 원한다.논쟁을 위해 NOTContent 플래그를 만든다고 가정해 보십시오. 기사 개수 외에 다른 용도가 있는가?드래곤즈 비행 (대화) 2009년 11월 2일 10시 10분 (UTC)[응답]

혼란스러운 페이지를 방어하기 위해, 그것들은 거의 기사들이다: 그것들은 위키링크, 참고 항목, 그리고 때때로 각주, 인포박스, 자매 프로젝트 링크를 포함한 가시적이고 백과사전적인 내용을 포함하고 있다. 그리고 추가적인 MOS 규칙을 제외하고 우리는 그것들을 똑같이 쓴다.그 중 어느 것도 리디렉션에 적용되지 않는다.• 아나킨^(talk) 16:12, 2009년 11월 3일 (UTC)[응답]

디스앰비그 페이지는 infobox나 각주를 포함해서는 안 된다.전체 가이드는 WP에 있다.모스다브. 그들은 가능한 한 단순하게, 순전히 교차로에 있는 표지판처럼 되어 있다.

나는 그의 토크 페이지에서 드래곤즈 비행기에 더 많은 답장을 했다. -- 퀴디티 (대화) 19:17, 2009년 11월 3일 (UTC)[응답]

몇몇은 인포박스를 가지고 있다.개인적으로 나는 그들이 그것에 더 좋다고 생각한다.예를 들어 코너를 참조하십시오.대안은 두 개의 (3?) 기사로 나누어 항해할 수 있을 것 같지 않다.• 아나킨^(talk) 21:02, 2009년 11월 3일 (UTC)[응답]

그것은 {{surname}/{{name}}페이지(이름 인포박스를 포함한 ence)와 혼합한 디스컴비그 페이지다.위키프로젝트 앤트로포니미는 우리에게 위키피디아에 그것들을 나열하라고 충고한다.위키프로젝트_분할 후 Antroponymy#Splits_from_disambig_pages_pages_pages_pages 또는 Category에 추가:분할이 필요한 설명 페이지.

위키프로젝트 디스컴비게이션은 "이들 역시 디스컴비게이션 페이지에 짧은 리스트가 포함될 수 있지만 디컴비게이션 페이지는 디컴비게이션 페이지는 디컴비게이션 페이지는 디컴비게이션 페이지는 디컴비게이션을 할 수 있다"고 밝히고 있다. "얼마나 긴지""";""""""""""""""&qu

이제 알겠다.링크 고마워.• 아나킨 15:11, 2009년 11월 4일 (UTC)[응답]

무작위 기사 제안

무작위 기사 링크를 편집해서 우리가 좋아하는 범주나 우리가 돕고 싶은 분야만 랜덤 기사를 줄 수 있다면 멋질 거야.우리가 환영 위원회에 있는 것처럼, 무작위적으로 환영받지 못한 사용자들.Accdude92 (Talk to me!) (사인) 14:43, 2009년 11월 3일 (UTC)[응답하라]

만약 사람들이 이 제안에 응답하기를 꺼리는 것처럼 보인다면, 그것은 그들이 그것에 동의하지 않기 때문이 아니라, 과거에 살펴본 적이 있고, 현재 현재, 이것을 현재 소프트웨어 구조에서 구현하는 충분한 "깨끗한" 방법이 없다는 것을 확신하라.아니, 난 믿지 않아. - Jarry1250 17:34, 2009년 11월 3일 (UTC)[응답하라]

그것은 외부 웹사이트가 하기에는 흥미로운 일처럼 들리는데, 마치 당신의 과거 선택에 근거한 음악을 제안하는 것 같다.아마도 위키백과를 운영하는 사람과 개가 관여하고 싶어하는 것은 아닐 것이다.그들은 항상 그들이 관심있는 간단한 것들을 검색하고 나서 알조스를 클릭한다.Dmcq (대화) 17:42, 2009년 11월 4일 (UTC)[응답]

누군가가 그들이 "보이지" 않았다고 생각했기 때문에 전체 문장을 도살하는 것(출처 포함)

나는 소개 구절에서 전체 소싱된 문장을 도축하는 것을 언급한다. - 종종 페이지를 매우 자주 방문하는 사람이 - 들어오거나 완전히 삭제하고 "소개 단락에 너무 길었다" 또는 "거기가 바로 보이지 않는다"라는 이유로 넣는다.

예: http://en.wikipedia.org/w/index.php?title=DNA&action=historysubmit&diff=323590547&oldid=323556736

만약 당신이 그것에 대해 그렇게 옳다고 생각한다면, 적어도 나머지 글에 그것을 포함시키시오 (중복적이지 않았으니까).누군가가 그들이 글에서 위치하는 예절을 완벽히 따르지 않는다고 생각하거나 심지어 그들이 글에서 "눈치"라고 생각하지 않는다는 이유만으로 전체 문장을 도살하는 것은 "오피니언스"가 되어야 한다.

이것은 하나의 발생에 관한 것이 아니고, 이것은 하나의 경향이며, 나는 위의 예나 위의 개인을 언급하는 것이 아니라, 사람들이 페이지를 보고, "잘 보지" 않는다는 이유만으로 무분별하게 소싱된 정보를 삭제하는 경향에 관한 것이다.나는 그것을 부정하는 규칙을 제안한다.

"예절 규칙이 말해주니까 내가 노골적으로 중복되지 않은 정보는 삭제해야 해"라는 변명은 그만둬야 해물론, 위키피디아는 많은 편집자들이 있고, 누군가는 결국 와서 모든 에티켓에 완벽하게 복종할 수도 있지만, 그렇게 많은 엘리티스트들이 그것이 "보이지 않는다"는 이유만으로, 그것은 사람들을 위키피디아로부터 멀어지게 하고, 결국 그것은 그것의 생산성을 파괴한다.

자연에서의 진화에서와 마찬가지로 「도면에서의 취약성」이 없고, 진화는 수정의 과정이다. --fs 17:03, 2009년 11월 3일 (UTC)[응답]

이전 편집 [8]에서 "도살"된 문장이 추가된 것 같다.나는 그 기사에 전혀 관여하지 않았기 때문에 외부 의견을 말할 수 있다: 네가 추가한 문장이 레드에 맞지 않는 것처럼 보인다.특히 잘 구축된 긴 기사(DNA는 97kb)로, 단순히 레드에 추가되는 것이 아니라 새로운 추가물을 기사에 세심하게 통합할 필요가 있다.그렇지 않으면, 기사는 나무 옆면에 있는 종양처럼 "과다 자란 납 증후군"이 된다.

네가 추가한 텍스트가 한 번 삭제되었으니, 나는 네가 제안한 추가 내용에 대해 토크 페이지에서 논의하자고 제안하고 싶다.그러나 단순히 그 구조를 무시하는 것이 아니라 이미 기사를 위해 개발된 구조로 여러분의 덧셈을 통합하는 방법을 찾도록 하라.— 칼 (CBM · talk) 17:13, 2009년 11월 3일 (UTC)[응답]

또한 외부의견으로서도 유추의 완벽성이 없다는 기본 논점을 만들기 위한 그런 장황한 발언은 지나치다고 보여진다.비유는 결코 완벽하지 않으며 이성적인 독자들은 이것을 이해할 것이다.나는 편집자들이 그러한 기고문을 정중하게 다루어야 할 의무가 있지만, 그것들이 전혀 유용하지 않을 것이라는 것이 명확하지 않은 기사의 구조에 그것들을 작업할 필요는 없다고 생각한다.나는 팀 비커스가 이 경우 잘했다고 생각한다.크리스토퍼 파럼 (talk) 2009년 11월 4일 (UTC) 21:05[응답]

오늘의 특집기사를 바탕으로 한 오리지널 곡 제안

나는 아이들과 가족을 위해 쓰여진 오리지널 노래의 팟캐스트를 시작하고 매일 새로운 노래를 쓰고 출판하는 것에 관심이 있다.위키피디아에서 오늘 특집기사가 되는 모든 것에 영감을 받는 것이 각 노래에 흥미로울 것 같아.

당연히, 나는 이것을 간단히 할 수 있었고 그것을 그냥 둘 수 있었다.많은 위키백과 기사에서 나온 "대중문화" 부분을 떠올리면서, 피처링 기사 자체에 수록된 곡에 대한 언급이 덧붙여지면서, 여기서도 가능성이 있을지도 모른다는 생각이 들었다.나는 기사 전반에 걸쳐 일관성이 있는 방식으로 그렇게 하는 것을 상상하지만, 물론 위키백과 프로토콜에 부합하는 방식으로도 상상한다.

어제 위키미디어 재단에 연락했는데, 그런 제안은 특별히 누구에 의한 이메일이 아니라 오히려 편집자 커뮤니티 내에서 해결되기 때문에 이 문제를 논의하기에 마을 펌프가 적절한 장소라고 했다.

그들은 또한 1면 컨텐츠의 팟캐스트를 참조하는 것이 홍보로 보일 수 있다는 점에 주목하면서 이해충돌 가능성에 대한 우려를 표명했다.그들은 내 의도가 잘못 해석되거나 내 계정이 기여하는 것을 차단되거나 내 웹사이트가 위키피디아에 포함되지 못하도록 차단되는 것을 피하기 위해 이 문제에 대해 여기 빌리지 펌프에서 논의하도록 나를 격려했다.

나는 분명히 용인되는 정책과 어긋나는 일, 내 계정이나 내 웹사이트를 위험에 빠뜨리는 일은 하고 싶지 않고 하지 않을 것이다.그러므로 이 게시물은 선의로 그 생각을 논의하기 위한 것이다.어떤 피드백이라도 환영할 것이다.고마워요.

팟캐스트는 괜찮지만 대중문화 코너에서는 가끔 (이렇게) 눈살을 찌푸리기도 한다.내 생각에, 팟캐스트는 아마도 위키피디아를 끝없는 정보의 무분별한 원천으로 만들지 않고 언급할 만큼 충분히 눈에 띄지 않을 것이다.--유니온호크 19^E-mailReview:18, 2009년 11월 3일 (UTC)[응답]

특집 기사에 실린 노래나 그 일에 대한 다른 어떤 것도 방해할 일은 없을 것 같다.하지만 위키피디아가 아닌 자신의 웹사이트나 유튜브 같은 것에 올리는 것이 더 나을 것이다.--RDBury (대화) 19:49, 2009년 11월 4일 (UTC)[응답]

신뢰성

나는 위키피디아에서 책임 문제를 다루는 시스템을 제안한다.위키피디아의 OTRS 시스템에서 아이디어를 얻었다.이것은 다음과 같은 것이다.

1. 토크 페이지의 편집자들이 2+2=4에 동의했다고 하자.
2. 권한이 없는 관리자는 토론을 종료하고 {consensus 2+2=4}의 합의를 위한 특별 템플릿이나 링크를 클릭하십시오.템플릿은 관리자(또는 새 사용자 그룹)만 만들거나 변경할 수 있다.
3. 2+2=4 <ref>{합의 2+2=4}</ref>라는 논문이 일치된 내용을 인용할 수 있다.

물론 누구나 2+2=5로 기사를 바꿀 수 있지만, 인용문은 그들의 주장을 지지하지 않을 것이다.

이는 기사에 "2+2=4"라는 문구를 포함하기로 한 결정에 어떠한 영향도 주어서는 안 된다.그러나 만약 인용문에 포함된다면, 독자는 더 많은 확신이 있을 수 있다.솔레솔 (토크) 2009년 11월 4일 (UTC) 18:23[응답]

합의는 바뀔 수 있고, 참고문헌은 신뢰할 수 있는 출처에 대한 것이지, 편집자 간의 페이지 논의를 위한 것이 아니다.2009년 11월 4일 Mr.Z-man 19:34 (UTC)[응답]

그것은 흥미로운 생각처럼 들리지만 나는 그것이 몇 가지 이유 때문에 실용적일 것이라고 생각하지 않는다.첫째, 그것은 사람들이 WP를 사용할 수 있는 가능성을 열 것이다.양말 인형극은 그들의 의견에 공감하는 모습을 만들어 내고 위키피디아에 따르면 그것을 사실로 인용할 수 있다.둘째로, 기사의 토크 페이지는 신뢰할 수 있는 결정을 내릴 수 있을 만큼 자격이 있거나 편견이 없는 사람에 의해 반드시 감시되는 것은 아니다.예를 들어 "웨슬리 크루셔는 얼간이다"라는 문구는 스타트랙 리스트에 대한 합의점을 얻을 수 있을 것이다. 차세대 에피소드 토크 페이지지만, 그렇다고 해서 믿을 만한 출처로 인용되어야 한다는 뜻은 아니다.--RDBury (토크) 19:38, 2009년 11월 4일 (UTC)[응답]

숨겨진 HTML 코멘트의 현재 애드호크 시스템은 이 역할에 충분하며, 대부분 그리고 이상적으로는 민감한/정밀 표현, 어느 정도 수준의 임의적인 선택(예: 예시 선택) 등과 같은 편집/비사실적 이슈에만 사용되어야 한다. --Cybercobra(대화) 19:44, 2009년 11월 4일 (UTC)[응답]

나는 Z-man이 동의가 바뀔 수 있다는 것과 "관리자들만" 동의가 바뀔 수 있다는 이 제안의 언급이 나를 두렵게 만드는 것에 반대한다.제발 그 관리자만 기억해줘. 학교 관리인만 빼고.그들은 우리의 엉망진창들을 청소하지만 그들은 진정한 "권위"를 가지고 있지 않다.그들은 우리의 상관도 아니고 우리를 감독하기 위해 여기 있는 것이 아니라 우리가 그들에게 주는 화약으로 그들에게 시키는 대로 한다.Camelbinky (대화) 00:04, 2009년 11월 5일 (UTC)[응답]

위의 다른 사람과 동의하십시오.게다가 믿을 만한 출처(즉, 우리(대부분)가 아니라)를 인용하도록 되어 있다.일반적인 각주에 간단한 설명(문단 정도)이 주어질 수 있는데, 이것은 대화 페이지에 링크하는 것보다 더 잘 나타난다.• 아나킨 02:18, 2009년 11월 5일 (UTC)[응답]

커뮤니티 라운지

나는 위키피디아가 소셜 네트워킹 사이트가 아니고 irc와 bla bla bla bla bla bla가 있다는 것을 안다.그러나 어떤 사람들은 irc를 사용할 수 없다.나는 사람들이 그냥 쉴 수 있고 위키피디아에서 일어나는 것들에 대해 수다를 떨 수 있는 커뮤니티 라운지가 있어야 한다고 생각한다.이제 이것을 소셜 네트워크와 다르게 만들려면, 주제는 위키피디아와 관련이 있어야 할 것이다.하지만 여기서, 우리 모두는 서로 만나서 위키피디아에 공통의 관심사를 가진 사람이 있는지 볼 수 있다.지금으로선 아무도 실제로 아는 사람이 없다.Acdude92 (Talk to me!) (사인) 21:10, 2009년 11월 4일 (UTC)[응답하라]

그것이 IRC를 위한 것이다.클라이언트가 없는 경우 java.freenode.net/ \backslash Forwardslash/ (대화) 21:37, 2009년 11월 4일 (UTC)[응답]

그래, 하지만 어떤 학교에서는 그걸 막고 있어.그리고 나는 단지 학교와 문제를 일으키지 않고 다른 기여자들과 이야기를 나눌 수 있는 장소를 원한다.Accdude92 (Talk to me!) (사인) 14:39, 2009년 11월 5일 (UTC)[응답하라]

WP:웹사이트

나는 위키백과의 사용법 에세이를 완성했다.WebCite를 사용하는 것은 위키백과 내에서 WebCite를 사용하는 방법을 설명한다.이것은 위키피디아의 아날로그다.웨이백 머신 사용.아마 사람들이 복습하고 교정할 수 있을 것이다.--Blargh29 (대화) 01:51, 2009년 11월 5일 (UTC)[응답]

위키백과의 3D 로고

아마도 당신은 이미 위키피디아 로고 지구본의 반대편에 무엇이 있는지 궁금해 했을 것이다.달 저편과 약간 비슷하다.그것을 발견하자.위키피디아의 완전한 3D 로고를 만들어 봅시다.미라세티 (대화) 09:44, 2009년 11월 5일 (UTC)[응답]

십중팔구 뒤쪽에 IP 기물 파손이 몇 군데 휘갈겨 있다. --외미에 17:30, 2009년 11월 5일 (UTC)[응답]

위키백과 참조:위키백과 로고#3D 버전 및 최근 블로그 포스트 a-3d-sign-globe-for-wikimedia 및 메타:위키백과/로고 등! --Quiddity (대화) 18:22, 2009년 11월 5일 (UTC)[응답]

관심이 있을 수 있는 프로젝트

안녕. 나는 이론적으로 위키백과 커뮤니티를 지원하고 회생시키는 데 도움이 될 비공식 위키프로젝트를 최근에 시작했어.나는 내가 그것을 바닥에서 내릴 수 있도록 도와줄 몇 사람을 찾고 있으니, 자유롭게 가입해라.안녕, –Juliancolton 17:47, 2009년 11월 4일 (UTC)[응답]

그 프로젝트는 이제 우리가 무엇을 할 것인지에 대한 더 확실한 생각을 갖게 되었다.기본적으로 우리는 위키피디아를 어떻게 개선할 것인가에 대한 개별적인 제안을 요구하고 있다.새로운 아이디어를 게시하여 도움을 받으십시오!–Juliancolton 21:15, 2009년 11월 7일 (UTC)[응답]

이미지 마법사

이미지 업로드를 위한 라이센스 옵션으로 새 사용자를 안내하는 이미지 마법사를 제안한다.기사 마법사가 작동하는 것처럼 작동하지만 이미지 저작권 태그를 위한 옵션을 제공한다.예를 들어, 첫 번째 질문은 "사진 찍었니?"가 될 것이고, 그 다음엔 거기서 나올 것이다. (I.E. 나사가 올린 거였니?)이렇게 하면 이미지에 태그를 지정하기 위한 올바른 옵션을 선택하는 더 쉬운 방법이 될 수 있다.나는 우리의 현재 시스템이 된 것 같다(특수:업로드)는 새로운 사용자들에게 매우 복잡하다.생각을 말해봐! --Tim1357 (대화) 00:35, 2009년 11월 6일 (UTC)[응답]

나는 한 번 이미지 저작권 사용권 마법사를 쓰려고 했다.20페이지가 지나도 나는 여전히 "무료"와 "무료" 내용을 제대로 구분하지 못했다; "공정한 사용"과 "복사비오"를 구분하는 것은 악몽이 되었을 것이다. --칼닐도 (토크) 02:00, 2009년 11월 6일 (UTC)[응답]

위키미디어 커먼스가 그들의 업로드를 어떻게 다루는지 살펴봐야 한다: http://commons.wikimedia.org/wiki/Commons:Upload.펜스&윈도우즈 04:39, 2009년 11월 6일 (UTC)[응답]

그것은 단지 그들의 위키백과 버전이 아니다.업로드? Rd232^talk 10:54, 2009년 11월 6일 (UTC)[응답]

오, 그래.만약 편집자들이 기존의 명확한 지침을 무시하고 있다면, 마법사는 전혀 차이를 만들지 않을 것이다.아마도 우리는 연속적인 저작권 남용자들에 대해 덜 관대해야 할 것이다.펜스&윈도우 19:51, 2009년 11월 6일 (UTC)[응답]

바로 그 주제에 관한 RFC가 있다.Wikipedia_talk:기여자_복사권_투자#프로세스_보드_제안.하지만 공평하게 말하자면, 두 위키피디아 모두:업로드 및 특수:업로드의 명확성은 크게 개선될 수 있다: 전자는 옵션을 보다 논리적으로 조직하고 후자는 더 나은 레이아웃과 더 적은 세부사항으로 "텍스트의 벽" 효과를 줄임으로써, 후자는 양식 자체 내에서 "1/2/3" 설명을 가질 수 있게 됨(이러한 경우에는 소프트웨어 변경이 필요함).Rd232 10:36, 2009년 11월 7일 (UTC)[응답]

위키백과를 참조하십시오.업로드할 이미지.— 마틴 (MSGJ · talk) 13:01, 2009년 11월 6일 (UTC)[응답]

SiteWideMessages

확장:SiteWideMessages는 중요한 투표, 토론, 선거를 알리는 정말 멋진 방법처럼 보인다.사용자 대화 페이지에 표시되는 무시 가능한 통지가 발송될 수 있다.한 번에 여러 개를 배치할 수 있으며, 일정 시간이 지나면 만료되도록 설정할 수 있다.개별 메시지는 관리자에게만 표시되도록 설정할 수 있으며, 이는 AIV가 엄청나게 백로그되고 DYK가 연체된 경우 관리자에게 알리는 데 사용될 수 있다.켜볼래?—Jake Bartenberg 23:20, 2009년 10월 16일 (UTC)[응답]

• 지지하다.사람들이 "전혀 말하지 않았다"고 비난했던 국기 개정판 같은 경우 또한 도움이 되어야 한다.아이언홀드 (대화) 23:34, 2009년 10월 16일 (UTC)[응답]
• 그것은 T22458에서 토크를 위해 언급되었지만, 다시 한번 로그인한 사용자만을 위한 것으로, 우리는 모든 사람들이 볼 수 있는 것이 필요하다.만약 우리가 그것을 전문화된 것에 사용한다면, 우리는 구독 시스템이 필요할 것이다. 예를 들어 모든 관리자들이 AIV 백로그에 대한 새로운 메시지를 얻고자 하는 것은 아니다.세나리움 (대화) 23:36, 2009년 10월 16일 (UTC)[응답]

• 나는 구독 제도가 필요할 것이라는 것에 동의하지 않는다.봇은 DYK가 연체되었을 때, 그것을 보는 대부분의 사람들이 아마 관심이 없을 것이라는 사실에도 불구하고 AN에게 글을 올린다.이것은 덜 거슬리고 덜 모욕적이다.그리고 한 사람은 CSS로 모든 것에서 벗어날 수 있었다 — Jake Bartenberg 00:06, 2009년 10월 17일 (UTC)[응답]

• 당신은 사람들이 메시지에 어떻게 반응하는지, 심지어 비교적 눈에 띄지 않는 감시자 명단에도 놀랄 것이다.AN에 대한 게시물은 UTP 메시지 다음에 나오는 '새로운 메시지가 있다'라는 메시지에 비하면 아무것도 아니며, AN에 대한 게시물은 단지 감시목록에 있는 또 다른 편집일 뿐이며, 당신이 그것을 보지 않는다면 아무것도 아니다. 모든 관리자가 AN/ANI에서 일어나는 일에 주의를 기울이는 것은 아니며, 대부분은 그렇지 않다.나는 사람들이 이것에 대해 심각하게 슬퍼할 것이라고 확신해. 그리고 어떤 CSS 마법도 이것을 도울 수 없을 거야.세나리움 (대화) 2009년 10월 17일 00:18 (UTC)[응답]

• 게다가, 3개 정도의 관심만 필요로 하는 문제에 대해 2,000명의 관리자의 토크 페이지에 메시지를 올릴 필요는 없다.옵트인 리스트가 좋을 수도 있고, 아니면 일종의 "교대 순환"이 될 수도 있다(매번 30명의 관리자가 통지됨)?Equazcion (대화) 2009년 10월 17일 (UTC) 00:24 [응답]

• 나는 그것이 새로운 메시지 바를 촉발시켰는지 몰랐다.그럼 이걸 밀린 일에는 사용하지 않는 게 좋을 것 같아.— Jake Bartenberg 00:28, 2009년 10월 17일 (UTC)[응답]

• 이 문제는 다음과 같은 선호 옵션으로 해결할 수 있다.

1. 사이트 메시지 표시 안 함(기본값 선택 취소됨)
2. 사이트 메시지에 대해 새 메시지 표시줄 트리거(기본값 선택 취소됨, 위에서 선택한 경우 선택되지 않음)

이런 식으로 우리는 전문화된 메시지를 위한 구독 시스템을 그렇게 많이 필요로 하지 않을 것이다.하지만 이것은 또한 우리가 일반적인 메시지를 위해 이것을 사용해서는 안 된다는 것을 의미하기도 한다. 왜냐하면 전문화된 메시지를 보고 싶지 않은 사람들은 일반적인 메시지를 보지 않을 것이기 때문이다.그래서 우리는 누구나 볼 수 있는 일반적인 메시지/커뮤니티 공지사항(UTP뿐만 아니라 모든 대화 페이지에서 볼 수 있음)과 전문화된 메시지에 대해서만 사이트 메시지를 사용할 수 있었다.나는 그것이 바람직한 효과와 기술적 실현 가능성 측면에서 가장 좋은 접근법이라고 생각한다.세나리움 (대화) 2009년 10월 17일 (UTC) 16:23[응답]

• 반대 – 우리는 감시 목록 알림과 일부 허용되지 않는 사이트 알림(자선 호소 등)을 가지고 있다 – 더 이상 사용자에게 자료를 스팸 발송할 방법이 없어야 한다.╟-TreasuryTag►ship-16:30, 2009년 10월 17일 (UTC)[응답]
• 다시 시작하려면 다음 Special이 있는 한 지원하십시오.기본 설정(misc) 옵션:

1. 사이트 메시지 표시 안 함(기본값 선택 취소됨)
2. 사이트 메시지에 대해 새 메시지 표시줄 트리거(기본값 선택 취소됨, 위에서 선택한 경우 선택되지 않음)

상술한 바와 같이 사용한다.세나륨 (대화) 2009년 10월 18일 (UTC) 20:13 [응답]

• 다른 전동 도구와 마찬가지로, 이것은 오른쪽 손에는 매우 유용하고, 다른 손에는 잠재적으로 파괴적이고 위험할 수 있다.대처 17:43, 2009년 10월 22일 (UTC)[응답]
• 지원 나는 이것이 중요한 경우에만 이것을 사용하는 것을 신뢰한다.유용할 것 같고, 세나리움이 제시한 노선을 따라 연장을 수정하면 그것을 원하는 사람들만 침범하게 될 것이다.NW (토크) 19:38, 2009년 10월 22일 (UTC)[응답]
• 사이트 요청에 대한 지원이 조금 더 필요할 것 같아, WP:CENT. Cenarium (토크) 16:01, 2009년 10월 24일 (UTC)[응답]에 추가해야겠어.
• 내가 이걸 놓친 문제는...어쨌든, 공식적으로 '반대'라고 말하진 않겠지만, 그렇게 보이는 건, 당신이 실제로 그 토크 페이지에 오른 것 뿐이겠죠?(만약 그것이 '새로운 메시지' 배너를 보여준다면 그것은 그것의 요점을 무의미하게 만들 것이다.)음 그래, 어떤 사람들은 많은 것을 얻을 수도 있지만, 나는 내 토크 페이지를 너무 자주 보지 않고, 다른 사람들도 그럴 것이라고 확신하며, 이것 때문에 메시지를 쉽게 놓칠 수도 있다.♫ 멜로디아 샤콘네 ♫ (토크) 2009년 10월 24일 (UTC) 18:14, 응답하라.
  • 확장 페이지: "사용자에게 새 메시지가 있음을 통지함"Rd232 10:43, 2009년 10월 28일 (UTC)[응답]
• 지지하다.좋은 도구인 것 같아.해봐라, 남용되거나 불만이나 결함이 너무 많으면 꺼라.펜스&윈도우즈 01:19, 2009년 10월 26일 (UTC)[응답]
• 지지하다.내 생각에는 확장자로서 그것은 기본적으로 해제되고 선호도로 설정되는 "opt-in"으로 만들어져야 한다고 생각한다.나는 이것이 좋은 생각이라고 생각한다.나는 관리 대시보드를 사용하지만, 나는 이것이 큰 개선이 될 수 있다고 생각한다.어떤 종류의 보호가 필요할까?Valley2city^‽ 06:00, 2009년 10월 26일 (UTC)[응답]
• 좋아 –Juliancolton 16:19, 2009년 10월 26일 (UTC)[응답]
• 지지, 하지만 옵트인(opt-in)은 좀 무의미하게 보이게 만든다.얼마나 많은 사람들이 귀찮게 할 것인가?지역사회가 그것을 현명하게 사용할 것을 믿고, 사람들이 탈퇴하도록 허용하라.Rd232 10:43, 2009년 10월 28일 (UTC)[응답]

• 요청된 기능, T23377.우리는 미래에 세계적인 선호를 바꿀 수 있다.기본값은 사용자 대화 페이지에 표시되지만 새 메시지 프롬프트는 표시되지 않음입니다.중요한 통지는 아마도 감시 목록 통지에 추가되어야 할 것이다.세나륨 (대화) 2009년 11월 1일 (UTC) 19:17 [응답]
• 반대 제발 안 돼, 이미 충분히 순항할 수 있다고 말했듯이, 왜 더 많은 것을 강요하는 거지?그리고 바라건대, 그들은 이것을 가능하게 하기 전에 12명 이상의 사람들에게 의견을 말해달라고 부탁할 것이다.Q 03:35, 2009년 11월 5일 (UTC)[응답하라]
• 반대파가 제기하는 대부분의 우려를 해소할 수 있는 옵트아웃이 있는 한 지원. --Tryptofish (대화) 23:30, 2009년 11월 8일 (UTC)[응답]

제안 - 굵은 워치리스트 작성

한동안 이런 생각을 했는데, 이 점이 아주 새로운 특색이 될 것 같다.특정 페이지를 굵게 표시할 수 있는 옵션(최근 변경 시 watchlist 페이지처럼)을 watchlist에 추가하는 것이 좋을 것 같다.다음은 이러한 기능을 통해 감시 목록이 어떤 모습인지 보여 주는 샘플(편집할 자유가 있음):

2009년 11월 4일

• (diff) (역사적) 예: 00:00 . (+111) 예 (토크 기여) [롤백]
• (diff) (역사) (미발행) 예시 굵은 페이지; 00:00 . (+70) 예시 (토크 기여) [롤백]
• (diff) (역사) (bold) . 조항; 00:00 . (+86) 예 (토크 기여) [롤백]

이러한 기능은 편집자가 사건 또는 특정 페이지의 대량의 공공 기물 파손 및/또는 방해로 인해 하나 이상의 특정 페이지를 주의 깊게 감시할 때 사용된다.이 기능은 대형 감시 목록을 가진 사람들에게도 유용할 것이다.

최근의 변화에서, 굵은 워치리스트 페이지는 굵고 기울임꼴로 보일 수 있다.

어떤 논평이나 걱정거리라도 감사할 것이다.건배, --Meaghan 23:33, 2009년 11월 4일 (UTC)[응답]

이 아이디어는 장점이 있지만, 하이라이트를 위해 대담하지 않은 것을 사용해야 할 수도 있다.마지막 검사 후 발생하는 감시 목록 변경에 대해 볼드체크를 사용하는 기존 기능(시스템의 일부인지 또는 실행 중인 여러 스크립트 중 하나인지 기억할 수 없음)이 있다.색깔, 혹은 이탤릭체? --Ckatz^chat_spy 23:40, 2009년 11월 4일 (UTC)[응답]

그래, 좀 더 강조해야 할 것 같아.몇 가지 예:

--Meaghan 23:55, 2009년 11월 4일 (UTC)[응답]

나는 그 아이디어가 마음에 들고, 세 가지 예 중에서 대담하고 노란색으로 강조된 것을 가장 좋아한다.하지만, 음, 바로 위 콜라피블에 있는 짙은 녹색 헤더의 유독성 광선 색상을 바꿔주시겠습니까?지금 보니까 눈이 녹아 있는 것 같아.중립적인 흙소리인가?그렇지 않은 건 뭐든지...밝고 상처받은!고마워!Camelbinky (대화) 2009년 11월 5일 00:00 (UTC)[응답]

죄송합니다, {{collapse top} 템플릿의 기본 색상이었습니다.연회색으로 바꿨어.건배, --Meaghan 00:26, 2009년 11월 5일 (UTC)[응답]

내 생각에 그들은 현재 과감한 감시목록 아이템을 얻으려고 노력하고 있는 것 같아. 네가 마지막으로 변경한 후 어떤 페이지를 봤는지와 보지 못한 페이지를 구별하기 위해서 말이야.그들은 몇 달 전에 한번 그것을 실행하려고 시도했지만 그것은 버거웠다.그것은 보류되었을지도 모른다.이와 비슷한 것이 종종 등장하는데, 여러 개의 감시 목록, 또는 감시 목록 플래그, 편집자들이 감시된 페이지의 그룹을 구별할 수 있는 방법이다.지금까지 논의된 내용은 흐지부지되었지만, 우리 중 몇몇은 어떤 형태의 조직을 사용할 수 있는 엄청난 감시 목록을 가지고 있기 때문에, 나는 그와 같은 것이 매우 유익할 것이라는 것에 계속 동의한다.Equazcion(토크) 00:31, 2009년 11월 5일(UTC)

나도 하이라이트에 찬성해! REVENUT (나 여기 있어) - 해야 할 일을 해야 해. 08:33, 2009년 11월 8일 (UTC)[응답하라]

대화 페이지의 편집 충돌 무시

위키피디아가 기사에 대한 편집 충돌을 처리하는 방식은 대화 페이지의 기능장애가 심해진다.어차피 서로의 토크 페이지 항목을 바꿔서는 안 되기 때문에 두 편집자가 기사의 같은 단락을 바꾸려고 할 때 필요한 것은 토크(프로젝트 등) 페이지에는 적용되지 않는다.왜 그들이 제출한 순서대로 기여도를 보여주지 않는가? (대부분의 블로그처럼, 토크 페이지가 아니라 기능적으로 어떻게 운영되는가)?

그렇지 않으면 신중한 코멘트를 고려하고 작성하지 않는 것, 한 번 작성한 코멘트를 미리 보거나 수정하지 않는 것, 그리고 설득력 있는 반박보다는 노골적인 한 줄 바가지 긁는 것에 프리미엄이 붙는다.이론적으로는 다른 사람의 거의 동시적인 논평을 고려하여 자신의 논평을 수정하고 수정해야 하지만, 실제로 논쟁 중에 시간을 들여 그렇게 하는 것은 모든 "저장"을 초래하지만 또 다른 편집 충돌을 야기한다는 것을 곧 알게 된다.나는 오늘 밤 30분에서 40분이라는 공간에서 세 번의 편집 충돌을 만났다; 기사를 편집할 때(활동적인 대화나 공공 기물 파괴 행위와 달리, 나는 실시간 과정이 아니다) 나는 일주일에 한 번, 두 번 편집 충돌에 부딪칠 수 있다.—— Shakescene (대화) 07:03, 2009년 11월 8일 (UTC)[응답]

• en에서 LiquidThreads의 신속한 구현을 추진하는 데 동참하십시오.위키피디아, 이것이 다루는 주요 이슈들 중 하나이기 때문이다.
  — V = I * R (Ω과 대화) 07:14, 2009년 11월 8일 (UTC)[응답]
• Bugzilla:4745Equazcion(토크) 08:02, 2009년 11월 8일(UTC) 참조

  현재 WP에 추가됨:DevMemo(위키피디아:MediaWiki/DeveloperMemo/2009년 11월).Rd232 11:57, 2009년 11월 8일 (UTC)[응답]

피드백 페이지

생각: 템플릿용 /doc 하위 페이지를 만드는 {{documentation} 템플릿이 있다.사용자에게 사전 로드 템플릿을 사용하여 도움말: 페이지 및 정책 및 지침을 위한 /feedback 하위 페이지를 만드는 유사한 템플릿을 사용할 수 있으며, 이 하위 페이지가 얼마나 도움이 되는지 등에 대한 몇 가지 질문을 제공할 수 있다.이것은 새로운 사용자들의 피드백을 장려하고 그것을 유용한 장소에 모을 것이다.(어떤 사람들은 "토크 페이지를 사용할 수 있다"고 말할지도 모르는데, 그것은 사실이다.그러나 그 토크 페이지는 온갖 종류의 지루할 정도로 복잡한 토론으로 가득 차 있을 수도 있고, 트래픽이 많은 페이지에서는 그러한 피드백이 그러한 토론을 방해하는 것을 원하지 않을 수도 있다.또한 하위 페이지에는 자체 범주가 있을 수 있으며, 후속 작업에 관심이 있는 사용자들을 위해 특별히 관련 변경사항을 사용할 수 있다.)댓글?Rd232 16:01, 2009년 11월 5일 (UTC)[응답]

좋은 생각이야; 새로운 사용자들로부터 특정 페이지나 포인트에 대한 피드백을 받아야 한다는 건 분명해.그러나 그들은 여전히 새로운 환경에 어리둥절해하고 피드백을 주는 것을 주저할지도 모른다.최상의 결과를 얻으려면, 우리는 그러한 목적을 위해 연장이 필요하다; WMF는 이미 피드백을 위한 캠페인을 조직해 놓았으니, 그것은 실행될 수 있다.세나륨 (대화) 17:38, 2009년 11월 6일 (UTC)[응답]

{{피드백 페이지}}에 금이 갔었는데, 예상대로 프리로드가 작동하지 않는 것 같아. 페이지를 덮어쓰기만 해.지금은 편집인트로만 써봤지만, 그건 덜 유용해.누구라도 있나요?Rd232 14:43, 2009년 11월 8일 (UTC)[응답]

알았어. 이제 Help에서 실험용으로 사용:사용자 공간 초안.그것에 대한 피드백은?Rd232 01:36, 2009년 11월 9일 (UTC)[응답]

다음과 같이 보인다.

Rd232 10:56, 2009년 11월 9일 (UTC)[응답]

위의 템플릿({{feedback 페이지})에 대한 의견이 있으십니까?Rd232^talk 16:26, 2009년 11월 10일 (UTC)[응답]

원칙적으로는 좋은 생각이지만 실제론 나쁜 생각처럼 느껴진다.내 두려움은 우리가 기사를 평가할 때 사용하던 논평 페이지와 같은 방식으로 흘러간다는 것이다. 그것은 단지 모두 더 이상 사용되지 않게 되었다.그렇긴 하지만, 왜 시도하지 않고 날 수 있는지 모르겠다.HiddingT 18:36, 2009년 11월 10일 (UTC)[응답]

그 댓글 페이지와는 달리, 피드백 페이지는 분명히 다른 청중을 대상으로 한다.나도 잘 될지는 확실치 않지만, 시도해 볼 만하다고 생각해.Rd232 09:20, 2009년 11월 11일 (UTC)[응답]

템플릿에 큰 변화를 줬으니 너도 동의하길 바라.{{leave 피드백}}}로 옮겼고, 이제 피드백 페이지 상단에 {{feedback 페이지}를 사용할 수 있게 되었다(일부 작업이 필요하다고 생각한다).{{leave 피드백}}}은(는) 옵션, 간단한 링크에 대한 링크:, 스팬 "span" 내의 링크에 대한 좌표, 위와 같은 섹션에 대한 섹션을 사용한다.특정 편집인트로와 프리로드를 사용할 수 있다.세나륨 (대화) 02:13, 2009년 11월 11일 (UTC)[응답]

그래, 괜찮아, 하지만 난 "코디"는 전혀 이해하지 못하지만.그리고 "피드백 페이지" 헤더는 동작이 필요해, 조금 수정했지만 레이아웃을 내가 원하는 만큼 매력적으로 만들 수가 없어.이것을 얼마나 광범위하고 신속하게 배치해야 하는가?정책/가이드라인 페이지에도 사용해야 하는가?Rd232^talk 09:20, 2009년 11월 11일 (UTC)[응답]

개별 페이지뿐만 아니라 템플릿이나 메시지에서 빠른 삭제에 대한 피드백을 받기 위해 수정할 계획이었습니다.안정되기 전에 배치해서는 안 된다.모든 피드백 페이지를 위키백과의 하위 페이지로 중앙 집중화하는 것은 어떨까?피드백(예: 위키백과:피드백/<도움말 페이지 이름>은 물론 위키백과:피드백/속도 삭제, 위키백과:피드백/페이지 보호 등. Cenarium (대화) 19:43, 2009년 11월 11일 (UTC)[응답]

조정은 대체 형식이다.특정 페이지에서는 단면을 사용할 수 없지만, 페이지노티스에 가까운 것이 더 좋지만, 기능성은 없다.다른 양식이 추가될 수 있다.정책 페이지에 대해서는, 우리도 거기에 피드백을 요청하는 것을 고려할 수 있다.세나리움 (대화) 2009년 11월 11일 (UTC) 19:48 [응답]

템플릿 토크에서 논의 및 조정:피드백을 남기다.세나륨 (대화) 03:55, 2009년 11월 12일 (UTC)[응답]

상단, [기사] 옆, [토론], [이 페이지 편집], [히스토리] 버튼

각 글의 맨 위에 [단순]에 독자를 데려가는 단추를 추가한다.wikipedia.org 단순.wikipedia.org] 기사의 버전.내가 이것을 해야 할 때, 내가 완전히 익숙하지 않은 주제에 대해 읽고 있을 때, 나는 이것을 해야 할 때가 많다.내가 할 수 있는 유일한 방법은 매우 서투른 것이다.

C-l C-[left arrow] C-[left] C-[left] C-[left] C-[backspace] s i m p l e .

이것을 중국어 위키백과의 기사 페이지 상단에 있는 방언/스크립트 변형 변환 버튼과 비교해 보십시오.

나는 이것이 간단한 위키피디아에 더 많은 노출을 줄 것이라고 생각한다. 그것은 좋은 자원이고 IMHO는 거의 충분히 이용되지 않기 때문이다.

만약 나의 제안에 반대하여 합의가 이루어진다면, 단순히 이것을 실행하기 위해 사용자 스크립트를 모노북.js에 넣으라는 요청을 고려하십시오. :)

이 아이디어에 대한 어떠한 제안이나 변주 제안도 환영할 만 하다. :)

76.190.210.196 (대화) 06:22, 2009년 11월 8일 (UTC)[응답]

EN 기사에 대한 간단한 기사가 있다면, 페이지 왼쪽의 링크 목록에 나타나는 인터위키 링크가 있어야 한다.나는 위에 더 두드러진 링크를 추가할 이유가 없다고 본다.이것은 내가 볼 수 있는 이유 없이 다른 모든 위키 변형에 대해 단순하고 부적절하고 과도한 가중치를 부여할 것이다. -- AnmaFinotera (talk · concernations) 06:32, 2009년 11월 8일 (UTC)[응답]

음, 그것은 조금 다르다. 그것들이 단지 같은, 상호 이해 가능한 언어의 서로 다른 글쓰기 스타일이기 때문이다.나는 실제로 보통 인터위키 단순 연결은 일어나지 않는다는 것을 발견한다.같은 사람들이 그 자리에 있을 가능성이 매우 높다.아마존닷컴은 또한 단순함을 발견할 것이다.wikipedia.org은 en에 있는 누군가의 그것보다 훨씬 더 높다.wikipedia.org finding, say, la.wikipedia.org 유용한.그래, 그건 나쁜 짚신같은 예였어 라틴어로 보는 건 사어인데 내 생각은 알겠지?—서명되지 않은 의견을 76.190.210.196 (대화 • 기여) 00:43, 2009년 11월 8일.

그렇지 않다(생각해 보기).인터위키 링크가 누락된 경우 추가해야 한다.Simple에 관한 기사가 정확하게 명명되었다고 가정하여 자동적으로 하는 봇이 있다. -- AnmaFinotera (토크 · 기여) 06:47, 2009년 11월 8일 (UTC)[응답]

(상충 편집) 만약 기사의 Simple English 버전이 존재한다면, 이미 페이지의 왼쪽을 따라 다른 언어의 버전과 함께 나열되어야 한다.예를 들어 맨해튼을 보십시오.특히 나나 다른 사람들이 탭(예를 들어 편집하지 않고 코드를 보기)을 선호하지만, 군집이 우려되어 기본적으로 탭이 제공되지 않는 몇 가지 사항을 생각할 수 있을 때, 상단을 따라 추가 탭이 필요하지 않기 때문에 나는 여기서 뭔가를 놓치고 있다.—— Shakescene (대화) 06:39, 2009년 11월 8일 (UTC)[응답]

Simple English Wikipedia(제공)의 목적은 제한된 어휘와 간단한 문법을 사용하여 영어 실력이 부족한 사람들을 돕는 것이다.주제를 간단히 다루는 것이 그것의 부작용일 수도 있지만, 그것의 의도는 아니며, 단지 기사가 더 짧고 덜 발전된 결과일 가능성이 더 높다.Mr.Z-man 07:54, 2009년 11월 8일 (UTC)[응답]

나는 영어와 Simple English의 관계와 다른 언어와의 관계에는 차이가 있다고 생각한다.나는 아마도 Simple English가 이탤릭체로 되어 있거나 인터위키 링크의 위나 아래쪽에 부딪혀 있는 것을 보는 것을 개의치 않을 것이다(어쨌든 S 밑에서 누가 그것을 찾겠는가).다른 탭은 도움이 안 될 것 같은데, 어지러움도 충분해.Phyomonas_(talk) 16:26, 2009년 11월 11일 (UTC)[응답]

위키백과에서 제안 토론:마을 펌프(기술)

외부 프로젝트의 위키백과 데이터에 대한 접근 가능성과 관련하여 제안이 논의되고 있다.위키백과를 참조하십시오.마을 펌프(기술)#DBpedia 템플리트 주석.Equazcion (대화) 10:59, 2009년 11월 9일 (UTC)

ConnectomeBot , 의미 wiki 및 외부 링크

편집자는 WP에서 봇을 제안하였다.외부 링크를 삽입할 RFBA.뇌 연결에 관한 의미론 위키, Connectome에 대한 위키백과 기사Wiki, 이 (PDF) PLoS 기사에 설명된 아이디어 및 목표와 관련.

이것은 더 넓은 지역사회가 먼저 해결해야 할 몇 가지 문제를 제기한다.

1. 위키백과 링크의 기본적 적절성.주제의 특수성 때문에 링크의 실질적인 가치는 신경학 또는 의사 편집자와 논의해야 할 것으로 보인다.기본 링크의 품질이 WT에서 논의되는 경우:위키프로젝트 신경과학, WT:Wiki Project Anatomy 또는 WT:위키프로젝트 의학/신경외과 전담반이나 다른 곳?
2. 한 편집자는 이 제안이 "WP와 충돌하지 않는 것 같다"고 제안했다.ELNO"라고 말하는 반면 다른 사용자는 링크를 기본적으로 에서 에 대한 스팸이라고 부른다.wiki 바깥쪽 wiki.
3. 그 링크를 제안하는 편집자는 프로젝트를 위해 그것을 하고 있으며, 취리히에 있는 신경정보학 연구소의 학생으로 자신을 묘사하고 있다.그는 지금까지 이 프로젝트에 분명한 관심을 갖고 있는 유일한 사람으로, 위키백과에서 커넥텀에 이르기까지 이미 (봇과는) 몇 가지 연계를 했다.위키피디아에 대한 뇌 기사 위키.링크 및 사용자의 편집 기록을 참조하십시오.
4. 추가로 논의해야 할 사항이 있는가?

이것에 대해 의견이 있으신 분?지금까지 두 군데(여기, VPR)에 이것을 게시하고 있지만, 여기서는 한 곳에서만 토론해야 한다.(물론 여기가 잘못 된 곳이라면 필요에 따라 얼마든지 움직여라)

이 전체 대화는 WP:BAG는 봇의 허가 여부를 결정하지만, BRFA에서 가장 잘 다루는 봇에 대한 기술적 문제에 순수하게 관심이 있는 코멘트가 있다면, 물론, 거기서 자유롭게 코멘트를 하십시오.고마워. --IP69.226.103.13 (대화) 03:14, 2009년 11월 10일 (UTC)[응답]

코넥텀 토론

찬성이나 반대, 추론 등 그 문제에 대해 논의하십시오.

• 코멘트 지금까지의 변경사항에는 "커넥텀"이 추가되었다.{{Infobox Brain}} 발생 시 Wiki" 파라미터로, 해당 템플릿을 편집하여 해당 파라미터가 www.connectome.ch에서 적합한 페이지로 연결되도록 하였다.그러나 템플릿에 대한 편집은 되돌렸다("논의 없이 EL 링크 되돌리기").템플릿에 외부 링크가 포함되기 전에 적절한 프로젝트에서 이 문제를 논의할 필요가 있다는 것 외에는 의견을 표명할 준비가 되어 있지 않다.조누니크 (대화) 04:05, 2009년 11월 10일 (UTC)[응답]
• 반대.WP:ELNO, WP:NOTLINK 및 WP:우선 RS.영향을 미치지 않는 사이트 통계.2009년 9월 9일 이후에만 존재했다[9].등록된 유저는 5명(실제 인간과 닮은 사람은 2명뿐)이다.콘텐츠는 자동화된 기사 수입에 의해 폐기된다.ConnectomeBot).Unidisigner(토크 · 기여)는 이 주제에 대한 의견수렴/공모 이외의 어떤 보고된 프로젝트에도 적극적이지 않으며, connectome.ch과 관련된 것 이외에는 어떠한 편집도 하지 않았다.나는 이 사이트가 곧 광고와 광고로 수수께끼가 될 것이며, 위키피디아에서 트래픽을 감시할 것이다.위키피디아를 "광고용 차량"으로 사용하려는 또 다른 스팸메일.--Hu12 (토크) 07:02, 2009년 11월 10일 (UTC)[응답]
• 지지하다.나는 코넥텀의 운영자다.위키백과에서 Unidesigner로 등록되었다.Hu12가 제기한 지적에 대해 코멘트를 하겠다.--Unidesigner (대화) 11:01, 2009년 11월 10일 (UTC)[응답]
  • 코넥텀위키에게는 아직 이른 시기다.나는 주로 페이지를 텍스트로 만들고, 파이톤 스크립트를 작성하고, ConnectomeBot을 사용하여 페이지를 삽입한다.9월 9일 시작일은 2009년 초부터 이미 콘텐츠 작업을 했고 서버에 대한 공격 때문에 위키 재설정을 해야 했기 때문에 다소 난감하다.
  • 아직 이용자가 많지 않은데, 주로 이 프로젝트가 공식 광고가 되지 않고, 논문이 발표되지 않았기 때문이다.사실, 코넥텀은Wiki는 구조 신경영상 연구를 위한 ConnectomeViewer 응용 프로그램의 확장 가능한 지식 기반 역할을 한다.
  • 나는 처음에 광고와 광고와 싸워야 했고 그래서 우리는 변화를 만들기 위해 계정을 요구하기로 결정했다.또한 기여하는 저자에 대한 더 나은 인식을 허용한다.
  • 지금까지 콘텐츠는 한 편으로, 우리는 뇌 연결 연구 분야에서 다양하게 확산되는 다른 프로젝트의 허브가 되기 위해 노력하고 있다.따라서 다른 데이터베이스에 대한 많은 링크.이런 의미에서 우리는 웹 스크래핑을 하고 있으며, 또한 가능하면 다른 페이지 데이터로부터 삽입하고, 그들과 적절한 논의를 한 후에만 삽입한다.예: 뇌 영역 계층 구조용 신경lex, 송버드 뇌 연결, 쥐의 측두엽 연결.현재 우리는 Escvier와 Logothetis&Saalem 지도책의 마카크 뇌 영역과 그것들의 참고문헌을 삽입하기 위한 논의를 하고 있다.반면에, 의미 속성에 주석을 달면 이 분야에서 매우 유용하게 사용될 수 있다.
  • 주요 자산 중 하나는 발표된 논문에서 뇌 연결 정보를 추출하는 것이다.그래서 저자는 그 분야의 전문가들에 의해 관리될 특정 연결성에 대한 관련 출판물들의 고도로 선택된 목록을 가지고 있다.
  • 스위스 로잔 대학병원 2기 부속 : PLOS 용지에 따른 뇌의 파셀레이션도 삽입되었으며, 이것은 커넥토메뷰어와 연계되어 있으며, 향후에 사용된다.
  • 가능하다면 신경과 전문의와 의사 편집자들 사이에서 더 폭넓은 논의를 할 수 있기를 바란다.
• 코멘트: ConnectomeBot에 관하여, 전문가 의미론 wiki ConnectomeWiki에서 적절한 페이지를 가리키는 Brain Infobox 템플릿에 링크를 삽입하고 싶다.호모 사피엔스 두뇌를 위해 약 250페이지가 태그될 것이다.--유니디그너 (대화) 11:05, 2009년 11월 10일 (UTC)[응답]
• 시기상조:우리는 Connectome 데이터를 WP로 취급할 이유가 없다.MEDRS. PLOSMed 논문은 현재 불완전하게 구현된 시스템이 아니라 이와 같은 종류의 무언가가 필요하다는 것을 말해준다.가능한 봇의 연결과 토론은 Connectome 콘텐츠가 신뢰할 수 있음을 보여주는 리뷰가 게시될 때까지 보류해야 한다.2009년 11월 10일(UTC) 16:49, 리드 송독이 왔다[응답하라]
• 시기상조:우리는 이미 또 다른 신경정보시스템인 NIF/NeuroEx 프레임워크를 미국 국립보건원의 후원으로 개발하고 있다.비교 가능한 정교화 수준에 도달할 것이라는 명확한 증거가 없는 한 다른 시스템에 링크를 추가해서는 안 된다고 생각한다.가장 좋은 것은 코넥텀을 위해서일 것이다.Wiki가 NIF 시스템에 통합될 예정인데, 내가 알기로는 그것은 매우 유연하다.루이에496 (대화) 18:38, 2009년 11월 10일 (UTC)[응답]
• 나는 강력하게 반대한다. 나는 그것이 채택할 수 있는 모든 가능한 연결고리가 허용될 수 있고 관련될 수 있다는 것을 보여줄 수 있지 않는 한 외부적으로 연결되는 어떤 봇에 일반적으로 반대한다.그 이하로는 청소의 번거로움이 생길 것이다.기사와 관련된 외부 링크가 있는 경우 손으로 배치해야 한다.만약 위키가 신뢰할 수 있는 출처라면 손으로 참조할 수 있다.이러한 기사들이 특집기사를 획득하기 위해서라면 봇이 두는 대부분의 링크는 필요하지 않을 것이다. 그래서 그들은 ELNO #1에 대항한다.이 상황을 스팸메일을 시도한 것으로 평가한 hu12의 평가에도 공감한다.ThemeFromSpace 03:56, 2009년 11월 11일 (UTC)[응답]
• 코멘트 OK, 나는 당신의 반대를 받아들인다.훌륭한 위키백과의 지속에 대한 토론과 행운에 감사한다. --Unidesigner (대화) 09:25, 2009년 11월 11일 (UTC)[응답]
  • Connectome wiki가 독립적으로 참조할 수 있는 안정적이고 잘 사용되는 리소스가 된다면 나중에 얼마든지 이 문제를 다시 살펴보십시오.이 과제에 대한 접근방법에 대해 직설적이고 투명하게 임해 주셔서 감사하다. --IP69.226.103.13 (대화) 09:38, 2009년 11월 11일 (UTC)[응답]

참조 미리 보기

그래서, 그 일은 다시 일어났다.나는 기사에 약간의 정보를 추가하고, 참고자료를 완성하고, 정보가 괜찮은지 미리 보고, 저장해 두었다가, 내가 참고자료를 꽉 채웠음을 발견한다.미리 보기 편집 창에서도 표시된 참조를 미리 볼 수 있도록 만드는 방법이 있는가?예를 들어, 기사의 한 섹션을 편집하는 경우 해당 섹션의 미리보기와 해당 섹션의 참조를 보여주는 참조 목록의 미리보기를 받으시겠습니까?그루티니스...뭐라고? 23:53, 2009년 11월 4일 (UTC)[응답하라]

미리 보는 동안 더미 Reference(참조) 하위 섹션이나 태그를 추가한 다음 제출하기 전에 제거할 수 있다. --Cybercobra(대화) 00:14, 2009년 11월 5일(UTC)[응답]

음, 그래 - 그게 도움이 될 거야.아마도 좀 엉망이긴 하지만, 효과가 있을 거야.고마워요.그루티니스...뭐라고? 00:39, 2009년 11월 5일 (UTC)[응답하라]

좀 더 통합적인 방법이 있었으면 좋았을 거라는 데 동의한다. --사이버코브라(토크) 02:07, 2009년 11월 5일 (UTC)[응답]

팁은 좋은데!그런 생각은 안 해봤어.펜스&윈도우즈 02:23, 2009년 11월 5일 (UTC)[응답]

사실, 나도 지금까진 그랬어.정신이 어떻게 작용하는지 우습다. --사이버코브라(토크) 02:30, 2009년 11월 5일 (UTC)[응답]

이런 일을 하는 사용자 스크립트가 적어도 하나 있다.아노미에 02:41, 2009년 11월 5일 (UTC)[응답]

이 기능도 추가하고 싶다.당신은 요청서를 제출해야 한다.Rmhermen (대화) 02:33, 2009년 11월 5일 (UTC)[응답]

목록 정의 참조에서는 작동하지 않지만 아노미 스크립트를 사용한다. --- - Gadget850 (Ed) 10:46, 2009년 11월 5일 (UTC)[응답]

어떻게 그럴까? Anomie⚔ 17:30, 2009년 11월 10일 (UTC)[응답]

• 미리보기 후까지 참조 태그를 항상 추가할 수 없다.숨기기 T 13:54, 2009년 11월 10일 (UTC)[응답]

저장하기 전에 supp와^{Author Name. Book Title (printing/release date). Publisher. ISBN or similar. Page or pages.} 같은 대체 태그를 사용하여 참조로 변환해 보십시오. --알렌네임 19:53, 2009년 11월 11일(UTC)[응답]

John Vandenberg가 독일 편집자 ParaDox의 원본을 바탕으로 쓴 대본이 User:FT2/scripts/previewrefs.js.그것은 완벽하지는 않지만, 대체로 그 일을 한다.만약 누군가가 그것을 개선해서 내장된 가젯에 추가하고 싶다면...?"FT2 10:17, 2009년 11월 12일 (UTC)[응답]

정보 정렬 속도를 높이기 위한 관심사 설정

그냥 생각해보자; 나는 생물학을 공부하는데 특히 약어에 관한 나의 관심사는 생물학이다.내가 찾는 것을 찾으려면 때때로 약간의 시간이 걸린다.그래서 나는 생물학을 나 같은 메인 인터레스트로 설정하고, 어쩌면 역사를 2차 인터레스트 등으로 설정할 수 있다면 위키백과 서핑을 완화할 수 있을 것이라고 생각했다. 그리고 디스컴 페이지들은 내가 로그온할 때 인터레스트에 따라 디스컴파일 페이지와 "검색 결과" 페이지에 대한 대안을 정렬할 수 있을 것이다.대부분의 기사들은 태그를 붙이기 때문에 이미 많은 작업이 끝난 것 같고, 위키피디아가 점점 더 완성될 때 중요한 문제는 당신과 관련된 정보를 찾고 관련 없는 정보를 분류하는 것이다.— 85.225.229.227 (대화) 21:25, 2009년 11월 10일 (UTC)에 의해 추가된 이전의 부호 없는 의견

디스컴비그 페이지는 동적으로 생성되지 않는다.그 페이지의 텍스트는 다른 모든 페이지와 마찬가지로 사람들이 입력한다.

동적인 페이지와 당신이 기술하고 있는 것과 같은 시스템에 대해 그것들을 바꾸는 것은 가능하지만...음, 먼저 개발되어야 할 것이다. (그리고 우리는 그러한 시스템이 이 정도 크기의 사이트에서 야기할 수 있는 성능 문제를 완전히 무시할 것이다.)
— V = I * R (Ω과 대화) 07:02, 2009년 11월 12일 (UTC)[응답]

사용 방법 네임스페이스 만들기

나는 최근에 내가 존경하는 동료 편집자가 쓴 글을 읽었는데, 그것은 내가 가진 관점을 강화시켜 주었다.따라서, 나는 인용문을 다시 게시하고 그것에 관련된 제안을 만들고 싶었다.

그래서 나는 정말로, 우리는 더 잘 나누어야 한다고 말하고 싶다.예를 들어, 도움말을 작성하십시오. 새로운 기사를 매우 명확하게 대상으로 하는 페이지 - 단순하고 너무 무섭거나 상세하지 않은 페이지; 링크에 초점을 맞추십시오.기술적 복잡성이 있는 경우, 기술 또는 하위 페이지에 초점을 맞춘 관련 이름의 도움말 페이지와 같이 기술 복잡성을 다른 곳에 배치할 수 있는 방법을 찾으십시오.가이드라인 내용을 분리해서 보관하십시오.위키피디아:이미지, 실제 가이드라인 내용은 단락으로 요약할 수 있고, 나머지는 도움말 페이지로 이동했다.

— Rd232, from [10]

그런 생각을 하면서 나는 "어떻게" 네임스페이스(또는 "어떻게?")를 제안하고 싶다.나는 이것이 반드시 더 많은 프로젝트 페이지를 만들 것이라는 사실에도 불구하고 조직과 유지보수를 더 쉽게 할 것이라고 생각한다.당신은 어떻게 생각하나요?
— V = I * R (Ω과 대화) 11:52, 2009년 11월 13일 (UTC)[응답]

말 그대로 새로운 네임스페이스를 말하는 겁니까?도움말: 네임스페이스와 어떻게 다를지 잘 모르겠다. 하우토: 페이지가 도움말: 페이지보다 더 고급일 것이라는 말씀이시죠?(이 차이가 새로운 네임스페이스를 요구할 만큼 근본적인 차이인지는 잘 모르겠지만, 목표 관객에 의한 페이지 분리는 확실히 유용할 것이다.)--코트니스키 (토크) 12:00, 2009년 11월 13일 (UTC)[응답]

도움말: 네임스페이스의 용도는?나의 제한된 인상은 독자들이 백과사전을 사용할 수 있도록 돕는 것이 목적이었다(예: "브라우저에서 이 외국어를 제대로 표시할 수 있도록 하는 방법"). --사이버코브라 (토크) 12:21, 2009년 11월 13일 (UTC)[응답]

확실히 하기 위해, 나는 "문학적으로 새로운 네임스페이스"를 제안한다. 그래서 우리는 "howto:" 페이지를 만들 수 있다.나는 결과 페이지를 도움말 페이지보다 "더 고급"으로 특징짓지 않을 것이다. 그러나 그것들은 약간 다른 기능적 위치를 차지할 것이다.네임스페이스의 "howo" 타입을 생각할 때, 나는 문서화의 빠른 시작 스타일을 생각한다.좀 더 포괄적인 "도움말" 문서와 "지금 알아야 할 것을 말해줘" 문서 방식의 "방법" 문서에 대한 차이점과 욕구가 있다.내가 제안하는 것은 "지금 알아야 할 것을 말해줘" 스타일의 문서를 보관하기 위한 네임스페이스다.
— V = I * R (Ω과 대화) 12:29, 2009년 11월 13일 (UTC)[응답]

"How-to" 네임스페이스의 문제는 그것이 비디오 게임 속임수 가이드, 레시피 컬렉션, 그리고 위키피디아가 금지한 많은 다른 아이템들을 만들기 위한 공개 초대장 역할을 한다는 것이다.위키피디아가 아닌 것은위키피디아는 매뉴얼, 가이드북, 교과서 또는 과학 학술지가 아니다(WP:NOTHOWTO)."도움말"은 소프트웨어 시스템의 온라인 매뉴얼/문서 접근에 대한 통칭이므로 기존 네임스페이스를 사용하지 않을 이유가 없다. --Alen3^talk 12:38, 2009년 11월 13일 (UTC)[응답]

도움 대 시작자 또는 도움말 대 고급 도움말 또는 도움말 대 설명서/핸드북일 수 있다. 우리가 부르는 것에는 다양한 종류가 있지만, 필요한지 아닌지 먼저 결정해야 한다.Phyomonas 12_(talk):44, 2009년 11월 13일 (UTC)[응답]

새로운 네임스페이스가 정당화될지는 잘 모르겠지만, 그렇다면 도움말: (신입자의 경우) 대 매뉴얼: (기술 세부사항의 경우)가 되어야 하며, 해당 페이지 사이에 적절한 링크가 있어야 한다.Rd232^talk 12:41, 2009년 11월 13일 (UTC)[응답]

음... 여기서 악의는 없어. 그리고 나는 이 일에 대해 일부러 경솔한 것은 아니지만, 개인적으로 나는 (내가 기꺼이 인정하고 있는 것은 합리적인 관심사라는) 추론을 거부하는 경향이 있어.나는 이것을 즉석에서 말하지는 않지만, 우리가 현재 위키백과와 도움말 네임스페이스에 일괄적으로 부여하고 있는 정상적인 수준의 경계심이 이러한 우려를 "자연적으로" 완화시킬 것이라고 생각한다.(모두에게 그 정도의 수동성이 충분한가?)
— V = I * R (Ω과 대화) 15:23, 2009년 11월 13일 (UTC)[응답]

나는 단순하게 구분된 것에 대한 만족도에 동의한다. (다른 위키백과 자료에 대한 사전 지식이 필요하지 않음 - 너무 많은 페이지들이 공통적인 작업을 수행하는 새로운 사용자들을 위한 지침/지침/지침들을 당신이 읽도록 요구함) 그리고 별도의 네임스페이스가 그것을 하는 방법이 될 수 있다.비록 내가 잠깐 취미 생활을 할 수 있다면, 우리는 네임스페이스의 가치가 아니라 소량의 재료를 갖고 싶어할 것이다.지금은 신입이 받아들이기에는 너무 많은 것이 있다.비록 그것이 너무 길긴 하지만, 나는 새로운 사람들을 위해 무언가를 입안하려고 시도했다.Phyomonas 12_(talk):27, 2009년 11월 13일 (UTC)[응답]

우리는 이미 필요한 시스템을 가지고 있다:신입 사원의 도움말 페이지는 "Help:" 공간에 들어간다.그리고 보다 심층적인 기술적 방법 안내서는 "위키피디아:" 스페이스에 들어가며 {{how-to} 박스로 페이지 상단에 표시된다.다음 두 가지 기술 사용 방법 안내서 위키백과를 참조하십시오.카테고리 억제 및 위키백과:줄 바꿈 처리.새 네임스페이스 필요 없음.

위키피디아에 있는 사람들은 다음과 같이 알고 있다.Help Project에서 모든 사용 방법 가이드를 "Help:" 공간으로 이동하려고 함.기술적 방법 안내서가 여전히 그렇게 표시되어 있는 한, 그것도 효과가 있을 수 있다.

--David Göthberg (대화) 2009년 11월 13일 (UTC) 12:46[응답]

데이빗이 옳다.위키피디아에 있는 대부분의 방법은 현재 공간이고 그것이 우리가 네임스페이스를 가지고 있는 이유 중 하나이다.에세이: 네임스페이스 또는 정책: 네임스페이스에 대한 이유가 없는 것처럼, 하우투: 네임스페이스는 필요하지 않다.모든 것을 단순하게 유지하도록 노력합시다.너무 많은 네임스페이스는 혼란스러울 것이다.SoWhy 12:53, 2009년 11월 13일 (UTC)[응답]

나는 아마도 마지막 부분에는 동의하지만 David가 전적으로 옳다는 것에 동의하지 않는다 - 도움말: 스페이스에도 많은 심층적인 페이지가 있다 (사실 나는 네임스페이스가 원래 소프트웨어 문서 페이지를 위한 덤프로서 만들어졌다고 믿는다, 이것은 확실히 새로운 사람들에게 다루어지지 않고, 그 이후로 임의로 진화되었다, 다양한 종류의 o.여기에 추가되는 f 페이지와 WP: 스페이스에 추가되는 다른 매우 유사한 페이지.나는 헬프 프로젝트의 현재 계획이 이 난장판을 정리하기 위한 첫 번째 명시적 전략이며, 일반적으로 지원되어야 한다고 생각한다.-코트니스키 (토크) 13:18, 2009년 11월 13일 (UTC)[응답]

도움말 네임스페이스의 기록

원래 개념은 미디어위키에 대한 주요 도움말 페이지를 갖는 것이었다.템플리트를 사용하여, MediaWiki 콘텐츠는 다양한 위키백과 페이지로 옮겨지고, 그 위키백과에 특정한 콘텐츠가 페이지 끝에 추가될 것이다.불행하게도, 미디어위키 페이지는 업데이트되지 않았고 위키피디아의 다른 언어 버전은 많은 면에서 갈라지기 시작했다.2008년 이 개념은 폐기되었고, 템플릿은 제거되고 삭제되었다.도움말 페이지는 다른 위키피디아와는 관계 없이 업데이트되었지만, 이제 en과 더 관련이 있는 도움말을 포함한다.위키백과

Help 네임스페이스의 문제 및 특정 문제에 대처하는 방법에 대해서는 Help Project에서 적극적으로 논의되고 있다. ---— Gadget850 (Ed) 14:51, 2009년 11월 13일 (UTC)[응답]

나는 이 토론에 대한 공지를 Help Project talk 페이지에 올렸다.나는 이 전에 내가 그 위키피디아 주제에 대해 아무것도 몰랐다는 것을 인정하는데 다소 당황스럽다.
— V = I * R (Ω과 대화) 16:32, 2009년 11월 13일 (UTC)[응답]

변명할 필요 없이, 우리는 최근에 단지 프로젝트 배너를 페이지에 추가했을 뿐이고, 그것은 나머지 도움들 사이에 잘 숨겨져 있었다!도움말 네임스페이스([11])에는 별로 많은 페이지가 없지만 새로 만들 페이지도 몇 개 있지만 일부 페이지를 병합하거나 삭제할 수 있으므로 사용 방법을 수용하는 것은 문제가 되지 않을 것이다.JoeSmack이 말했듯이, 다른 사람들이 이러한 문제에 대해 생각하고 있다는 것을 아는 것은 좋은 일이다!Lee∴V (대화 • 기여) 2009년 11월 13일 (UTC) 20:16 [응답]

위키백과 도움말 프로젝트에서

그래서 여기서의 이 논의는 특히 이 실과 관련이 있어 보인다.이 표는 WP로부터 도움말 공간에 대한 도움말/방법/내부/교육 자료를 얻는 데 어려움을 겪고 있는 대상의 예:

주의가 필요한 도움말 기사(편집)

도움말의 페이지: 네임스페이스	위키백과의 페이지: 네임스페이스	평.
카테고리의 페이지:위키백과 다국어 지원		청소하고 합병을 해야 할 것 같아.
도움말:디프		2012년 5월 현재, 새로운 diff 포맷에 대한 업데이트가 필요하다(반복되지 않는다고 가정함).
n/a	위키백과:페이지 편집 방법	읽기가 그리 쉽지 않아 - 아야!
도움말: 계정	위키백과:계정	도움말 페이지는 존재하지 않으며, WP 스페이스 1은 매우 TLDR/비친화적이다.
도움말:파일	위키백과:이미지들 위키백과:그림 자습서	이미지를 쉽게 사용하기 위한 매개 변수에 대한 유용한 정보를 찾을 수 없음 - 위키백과에서 찾을 수 있음:확장 이미지 구문이 제대로 연결되지 않을 수 있음
도움말:파일	위키백과:이미지들 위키백과:이미지 사용 정책 위키백과:확장 이미지 구문 위키백과:업로드할 이미지 준비 위키백과:그래픽 자습서 위키백과:캡션 위키백과:갤러리 태그 위키백과:미디어 파일 생성 및 사용 위키백과:이미지 찾기 튜토리얼 위키백과:이미지 업로드 중 위키백과:위키백과의 이미지에 대해 당신이 모를 수 있는 10가지 위키백과:그림 자습서	다양한 양의 중복이 있는 많은 이미지 페이지.
도움말:각주	위키백과:스타일 매뉴얼(각주)
도움말:Wiki 마크업		더 단순하고 더 포괄적으로 만드는 것과 관련이 있다!
	위키백과:문서 시작 위키백과:기사작성 위키백과:첫 번째 기사	기사 시작에 3페이지

이 표는 중복성의 일부(그리고 솔직히 말해서, 우리가 새로운 편집자들을 위해 가지고 있는 형편없는 도움 지원)를 개략적으로 설명한다.WP 공간과 Help의 구분 선과 그것이 어떤 모습이어야 하는지, Help 페이지의 중요도를 어떻게 판단해야 하는지 등을 이곳에서 작업해 왔다.기본적으로, 도울 수 있는 잠재력이 있고, 나와 몇몇 다른 편집자들만이 이 문제를 토론/해내기 위해 있는 것처럼 느껴지기 때문에, 나는 지금 더 많은 관심이 있어 기쁘다!조스맥^Talk 18:16, 2009년 11월 13일 (UTC)[응답]

Talk 페이지의 소수민족 상호연락

기사에 기고하는 대다수의 편집자들이 선호하지 않는 메인 페이지 추가를 제안하는 소수 그룹의 처우를 우려하는 에세이가 초안 작성되었다.댓글 달아줘.Brews ohare (talk) 17:23, 2009년 11월 10일 (UTC)[응답]

나는 여기 온 지 얼마 안 됐는데 벌써 이것들 몇 가지에 연루되어 있다.WP:B에 대한 참조가 확실하지 않음아틀은 아무거나 덧붙인다.WP:BFD, WP:저스타, WP:AGF가 더 유용할 수도 있다.아마도 다수의 혹은 소수의 사람들이 존재하는 것이 비생산적이라고 가정하거나 생각하더라도 의문을 제기해야 할 것이다.기본값은 모든 사람이 기사를 개선하기 위해 그 곳에 있다는 것이다.WP의 한계에 대한 논의:IAR. 또한 선호하는 분쟁 해결 방법에 대한 논의.나는 지금 RfC가 아무 쓸모도 없는 것인지 아니면 어디에도 없는 긴 느린 보트가 있는지 알아내고 있는데, 만약 당신이 그것을 가지고 있다면 답을 알고 싶다. 두 가지 수정.람바노그 (대화) 2009년 11월 14일 (UTC) 18:22 [응답]

리드 섹션의 문법 정보 버튼

(이 제안의 예에서 "문법 버튼"의 그래픽 외관은 임시방편적인 해결책에 불과하다. 제안이 받아들여진다면, 실행 전에 더 나은 그래픽 해결책을 고안해야 한다. 또한 기술 구현을 위해서는 훨씬 더 쉬운 해결책을 찾아야 한다(아마도 js).

위키피디아가 사전은 아니지만 문법적 정보(어원, 복수형 등)는 여전히 바람직하지만, 매우 긴 시간이 가독성을 훼손하는 리드 섹션에서는 그렇다.나는 선택적 버튼을 제안하고 싶다. 아마도 "접을 수 있는 접을 수 있는" 테이블과 비슷하게 작동하는 "문법"을 읽고 싶다. 단지 인라인, 즉 단락 내에서: 버튼을 클릭할 때 광범위한 문법 정보가 표시될 것이다.아래 예와 여기(또는 IE의 경우 여기)를 참조하십시오.말했듯이, 더 나은 그래픽 해법은 여전히 고안되어야 하며, 특히 단 한 단어로만 충분할 것이다("[쇼]"가 없으면 구현이 간단해야 한다(일부 js와 템플릿 프로그래밍이 필요할 것이다).또한 "인라인 테이블" css 속성에 관한 IE-bug도 해결해야 할 것이다.

캐티투스에 리드 섹션 사용 예:

카테투스 (기존 외모)

직각 삼각형에서 카테투스(원래 그리스어 κάετ,, 복수형 κθε from from; 영어의 복수형인 iεi;;;;; 라틴어 번역 카테토스에서 더 직접적으로 왔기 때문에 카테티이다)는, 일반적으로 오른쪽 삼각형의 직각과 인접한 양면 중 하나이다.

카테투스(수정된 외관 – 모질라, 크롬 등)

카테투스(수정된 외관 – IE)

여기에서 또는 IE 사용자에 대한 다른 예를 보십시오.단 dan 18:28, 2009년 11월 14일 (UTC)[응답]

그리고 페이지를 인쇄할 때?화면 판독기를 사용하여 확인하시겠습니까?MOS:COLAPE를 참조하십시오.재료가 납의 가독성에 영향을 미칠 정도로 길면 자체 섹션으로 옮겨야 한다.해피멜론 21:23, 2009년 11월 14일 (UTC)[응답]

인쇄 등의 경우, 기본값은 단순히 가시적으로 설정되어야 한다(그리고 버튼 자체는 보이지 않아야 한다).좀 더 정교한 해결책은 아마도 각주를 만들 수 있을 것이다.그리고 나는 책임감이 없이, 많은 리드에서의 문법적 정보는 리드 밖에서 재배치되어야 한다는 것에 동의한다.단 dan 23:24, 2009년 11월 14일 (UTC)[응답]

그렇다면 애초에 그냥 각주를 쓰지 그래?아노미슈 01:41, 2009년 11월 15일 (UTC)[응답]

음, 나는 붕괴 정책에 대해 읽었는데, 내가 몰랐고 내가 동의하지 않는 정책에 대해 읽었는데, 위키백과는 정적인 것이어야 한다는 것을 전제로 하기 때문에 - 위키백과는 인쇄된 형태나 다른 정적인 형태로 몇 번이나 사용되는가?이것은 주로 인터넷 백과사전이다.사실, 통계 자료를 아는 사람 있어?하지만 그 논의는 여기에 속하지 않는다.나는 이 개념에 곧 이의를 제기할 생각은 없으며, 정적 위키백과의 경우 이런 종류의 역동적인 요소는 정말 부적절하다.단 ☺ 21:09, 2009년 11월 15일 (UTC)[응답]

디프렌더링

문장 부호 옆에 공백을 넣거나 떼면 디프(diff)에 뚜렷하게 나타나지 않는다.어떤 경우에는, 특히 긴 단락에서 그 차이를 면밀히 연구해야 한다. (예: diff) 아마도 그러한 경우 diff는 (구문 부재가 없는) 두 단어 사이의 공간이 추가되거나 제거될 때(예: diff)와 같이 렌더링되어야 하는가?당신은 어떻게 생각하나요?아이스블록 (토크) 2009년 11월 14일 (UTC) 19:04 [응답]

그것이 무엇이었는지 볼 수 있다면 고맙겠는데, 아마도 다른 색상으로 다른 간격을 강조할 수 있을 것이다.Graeme Bartlett (대화) 21:32, 2009년 11월 14일 (UTC)[응답]

나는 그것을 찬성한다, 바뀐 공간을 색칠하라!단 dan 23:16, 2009년 11월 14일 (UTC)[응답]

알고리즘이 공간의 색상을 바꾸고, "작음"이 (쉼표 추가처럼) 변경되었으면 좋겠다.그것에 대해 많이 생각해 본 적은 없지만, 아마도 "길이(변경) < 2>나 변경이 공백과 일치하는지 강조할 것"이다.조누니크 (대화) 23:42, 2009년 11월 14일 (UTC)[응답]

개인적으로 나는 monobook.css에서 다음을 사용한다.

이렇게 하면 빨간색 배경에 빨간색 텍스트에서 검은색 텍스트로 변경된다.불행하게도, 공간만을 위한 변화를 강조하기 위해 여기서는 효과가 없다; MediaWiki의 개인 시험 설치에서는 그러한 공간 주위에 필요한 요소들이 잘 생성되지만, 여기 위키백과에서는 출력물에 그것들이 존재하지 않는다.아노미슈 01:51, 2009년 11월 15일 (UTC)[응답]

나는 이것을 사용한다. 그것은 모든 변화에 빨간 점 테두리를 둔다.문장 부호 변경 사항을 쉽게 파악할 수 있고, 공간도 잘 포착할 수 있다고 생각한다.

.csvchange {padding}: 0 0 2px 0px 2px, 테두리: 1px 빨간색 점선, 여백: 0px 1px 0px 0px}

에카즈시온 (토크) 2009년 11월 15일 14:18 (UTC)

여기 시험의 차이점이 있다: [12] HTML의 변화를 나타내는 데 필요한 요소가 전혀 보이지 않는다.Anomie⚔ 15:58, 2009년 11월 15일 (UTC)[응답]

새로운 RC 순찰 개념

나는 단지 우리가 RC 리스트에 직접 a!를 볼 수 있기 때문에 이 시스템이 수정 플래그로 표시되는 것을 선호한다.게다가, 그것은 이미 fr.w에서 사용되고 있다.잭팟 (대화) 2009년 11월 15일 (UTC) 19시 30분[응답]

반대: 편집이 확인되면 검토자가 서버에 다시 보고해야 하므로, 각 편집에 대해 데이터베이스 적중 횟수가 2회 필요하다.Tim1357 (대화) 01:35, 2009년 11월 16일 (UTC)[응답]

WikiContest(또는 WikiTournament)

매우 단순함:
위키컵은 매년 개최되는데 (내 생각에는) 아주 긴 기간일 것 같다.한 달 안에 이벤트를 하는 건 어때?(2개월 또는 3개월의 기간도 포함.위키컵처럼 각 참가자가 자신의 플래기콘(그러나 이 경우 반복할 수 있다)을 들고 출전한다.두 가지 범주: 메인 스페이스 편집, 페이지 작성 및 마이너 편집만 카운트(개별)되는 마이너 리그와 이전이 고려되는 메이저 리그의 경우, 또한 피처링 상태, GA, DYK 등으로 업그레이드할 수 있는 포인트가 더 많다.
또한 다른 위키미디어 프로젝트에 대한 기여는 글로벌 계정을 가진 사용자들에게 고려될 수 있다(권리 확인).이 자료들은 여기 기사에 대한 실제 기고 시리즈의 일부를 형성할 수 있는 이미지, 번역물(또는 다른 언어로, 뉴스 등으로)을 업로드하는 것일 수 있다. - ☩Damerrung☩. -- 14:09, 2009년 11월 1일 (UTC)[응답]

기사 작성을 장려하는 것은 무엇이든 좋은 생각이다.전적으로 찬성한다. - -oooia_¢: 19:03, 2009년 11월 1일 (UTC)[응답]

응, 나도 동의해. 하지만 콘테스트/관광지를 만드는 것은 단지 사용자가 콘테스트/관광순위를 올리고 싶어한다는 이유만으로 기사들을 대량으로 만들 수 있어.게다가 위키피디아는 게임 사이트가 아니라 백과사전이다.구구오12 (대화) 21:03, 2009년 11월 6일 (UTC)[응답]

누군가가 이런 일을 꾸미는 것을 금지하는 것은 확실히 없다.다만 일이 많으니 아무도 자진해서 운영하지 않아도 놀라지 말라. --ThaddeusB (토크) 21:21, 2009년 11월 1일 (UTC)[응답]

이런 생각이 마음에 든다고는 할 수 없다.나는 너무 많은 편집자들이 기사에 무분별한 잡담을 추가함으로써 엄청난 편집 수를 얻는 것을 본다.이것은 격려하기보다는 낙담해야 할 일이다.나는 특히 사실 확인과 같은 감사하지 않은 일부 작업에 대해 편집자들의 더 많은 인식 노력이 필요하다는 것에 동의한다.하지만 100개의 나쁜 것 보다는 단 한 개의 아주 좋은 덧셈을 하는 상을 보고 싶다.--RDBury (토크) 20:02, 2009년 11월 4일 (UTC)[응답]

이런 종류의 게임은 장려되어서는 안 된다.그 목표들 중 하나는 기사의 개발을 장려하는 것이다; 비록 그들이 그들의 사용자 페이지에 게시하는 어리석은 그래픽에 지나지 않더라도, 사람들에게 상을 주는 개념은 프로젝트가 묵인해야 할 것이 아니다.하지만 난 그저 투덜대는 재미에 불과하니까 나를 무시해도 돼:p Sherth 20:07, 2009년 11월 4일 (UTC)[응답하라]

우와, 이제 상은 생각지도, 얘기하지도 않았는데...사실, 내가 이 제안서를 여기에 올렸을 때, 나는 상이나 인식에 대해 완전히 잊어버렸어.너희 둘이 상에 대해 이야기 했구나. 지금 생각해 보니, 어쩌면 기존의 상(원하면)을 사용하는 것도 괜찮을지도 몰라. 그러니까, 우리가 새로운 상들을 만들 필요도 없고, 심지어 강제로 상들을 주지도 않아도 돼.완전한 편집이 아닌 편집에 대해서, 음, 나는 그것이 그것을 목표로 하는 게임을 단념시키지 말고 좀더 건설적인 편집을 하도록 장려되어야 한다고 생각한다.하지만 그것은 내가 생각해 내고 싶었던 것에 대한 나의 의견일 뿐이다.더 많은 의견들이 다시 인정될 것이다. - ☩다머룽 ☩. -- 03:51, 2009년 11월 5일 (UTC)[응답]

글쎄, 어떤 종류의 경기/게임/경쟁에서든 고유의 상이 있다.좀 더 넓은 예를 들면, 비록 양키스가 월드시리즈 우승 트로피를 수여받지 않았더라도, 그들은 여전히 "World Series Champion"이라는 타이틀을 받을 것이다.월별 위키투어나멘트의 우승자는, 비록 아무도 자신의 토크 페이지에 붙여질 트로피 그래픽을 만드는 데 방해받지 않더라도, 여전히 "위키투어나멘트의 11월 우승자"라는 타이틀을 받는다.그것이 바로 내가 얻고자 했던 것이다. 특히 그들이 무언가를 쟁취한 것에 대한 보상으로 추구될 수 있을 때, 우리가 타이틀/어워드/인정하는 습관을 가져서는 안 된다는 것이 나의 철학이다.나는 이미 제공된 서비스에 대해 개별적으로 부여된 Banstars와 아무런 문제도 없다.다시 말하지만, 그것은 모두 내 의견일 뿐이다.2009년 11월 5일 14시 37분 (UTC)[응답]

여기 다른 생각이 있다.일부 편집자들은 주간/월간 유형의 위키피디아 상을 수상하면서 "우수한" 것으로 간주하는 편집자들을 스스로 인정하게 되었다.나에게 이런 종류의 배치는 타이틀을 위해 경쟁하는 사람이 없기 때문에 받아들여질 수 있다; 그것은 먼저 특정한 목표/기준에 도달하는 것에 기초하여 허가되는 것이 아니라, 누군가의 현존하는 기여를 식별하여 그들이 보상을 기대하지 않고 좋은 기여를 한 것에 대해 보상한다.거기에는 차이점이 있다.나는 훌륭한 위키피디아 사람들을 식별하기 위해 일종의 태스크 포스를 구성하고 그들이 그렇게 인식되는 것을 "환원"하는 것에 대해 거리낌이 없겠지만, 공식적인 경쟁은 내가 장려해야 한다고 믿는 그런 종류의 것이 아니다.2009년 11월 5일 14시 45분 (UTC)[응답]

상은, 화려한 헛간 스타일지라도, 도달해야 할 목표를 준다.편집 카운트가 있는 이유는?왜 우리가 카운트/장수를 편집하여 "적격"하는 헛간을 가지고 있는가?상은 사람들을 기분 좋게 만들고, 그들은 그들의 야망을 움직인다.상은 단지 사람들에게, 모든 허영에서, 성취할 수 있는 무언가를 줄 뿐이다.- 2009년 11월 5일 (UTC) 14_¢:56, 【응답】

아마도 나는 단지 그들이 성취하기를 원하는 목표가 헛스타와 DYK 물음표와 빛나는 FA 스타들로 가득 찬 사용자 페이지인 편집자들보다 가치있고 명성 있는 백과사전인 편집자들을 격려하는 것이 더 나을 것이다... 그러나 다시 말하지만, 그것은 바로 나 자신이다:) 나의 완벽한 작은 세계에는 편집 카운트도, 사용자 페이지에는 FA 스타도 없을 것이다... 그러나 나는위키피디아는 나의 완벽한 작은 세계가 아니며 아마도 내가 내 이익을 위해 너무 진지할 것이라는 것을 이해한다.2009년 11월 5일 셰어 15:04 (UTC)[응답]

만약 위키피디아가 순전히 사심 없이 일하는 편집자들만 있었다면, 우리는 지금과 같이 거의 성공하지 못했을 것이다; 우리는 전혀 성공하지 못했을지도 모른다.Mr.Z-man 23:21, 2009년 11월 6일 (UTC)[응답]

나는 이런 '게임'은 편집자들이 가치 있고 평판이 좋은 백과사전을 만들도록 격려하는 아주 좋은 방법이라고 생각한다.비록 그들의 목표가 단지 헛간 스타를 갖는 것일지라도, 나는 위키피디아 개선에 도움이 되는 한 상관하지 않는다.그리고 물론, 3가지 부분처럼 별로 가치가 없는 편집도 있지만, 우리는 그것을 피하고 이 게임을 위키백과의 이익을 위해 사용할 수 있는 방법을 찾을 수 있을 것이다.- ☩다머룽 ☩. -- 15:04, 2009년 11월 10일 (UTC)[응답]

나는 이런 유형의 경쟁이 어떻게 한 달도 안 되는 기간 동안 기능할 수 있는지 모르겠다.내 경험상, GA 검토는 요청된 시간에서 완료되기까지 한 달 이상 걸릴 수 있다.FAS도 마찬가지로 몇 주 동안 지속될 수 있다.그러한 상황에서 "점수"를 얻는 능력은 당신의 기술이나 교묘한 능력에 의해 결정되는 것이 아니라, 특히 GA에서 주제 영역에 따라 크게 달라지는 당신의 기사를 검토자들이 얻을 수 있는 속도에 의해 결정된다.—Charles Edward 21:22, 2009년 11월 16일 (UTC)[응답]

이건 어때: 마이너리그는 한두 달 동안 지속되는 거야.메이저 리그는 세 몬트 혹은 네 몬트 정도 지속된다. - ☩다머룽 ☩. -- 08:05, 2009년 11월 17일 (UTC)[응답]

새 사용자에 대해 저장하기 전에 미리 보기 강제 실행

일부 위키피디아에서 기본적으로 이 기능이 활성화되어 있다는 것을 알고 있지만, 여기서는 잘 될 수 있다. 새 사용자가 변경 내용을 저장하기 전에 편집 내용을 미리 살펴보도록 요구하여 제출하기 전에 "생각"하도록 해야 한다.이것은 새로운 사용자들에게 보여질 수 있는 추가적인 메시지와 함께, 새로운 사용자들에게 우리가 가지고 있는 문제들 중 일부에 도움을 줄 수 있고, 새로운 페이지의 쓰레기 흐름을 늦출 수도 있다.그러나 나는 단점, 백래시 등을 예측하지만, 만약 제대로 한다면, 이것은 완벽할 수 있다.

물론 "new" 즉, 자동 확증이나 편집의 구체적인 양 등은 아니다.ViperSnake151 Talk 17:25, 2009년 11월 7일 (UTC)[응답]

그러니 혼성 메시지를 보내자.굵은 글씨로 삽입한 사람이 다시 편집하지 않게 하기보다는 뒷정리를 해야 할 것 같아. :( --Izno (토크) 21:27, 2009년 11월 7일 (UTC)[응답]

여기에서 이전의 관련 논의를 참조하십시오.---Fuhgettaboutit (대화) 00:59, 2009년 11월 8일(UTC)[응답]

아그, 또 다른 "새끼를 물어라" 제안.지난 두 달 동안 다섯 명?IP나 신참을 제한하고 싶은 사람은 누구나 한 달 동안 편집이 제한되거나 제약을 받고, 그런 식으로 자신의 제안서를 붙이는 것이 어떤 기분인지 알 수 있도록 제안할 생각이다.당신이 아닌 사람들의 능력을 제한하기 위해 청혼하는 것은 쉽다.카멜빈키 (대화) 01:49, 2009년 11월 8일 (UTC)[응답]

헷갈리는데, 이게 정확히 어떻게 물리는 거야?그들을 다르게 대하는 것.그 말은 그들이 기사들을 옮기는 것을 허락하지 않는다는 것을 의미하는가? --골베즈 (토크) 07:59, 2009년 11월 8일 (UTC)[응답]

일부 제한은 필요에 따라 나온다(모든 사람이 모든 페이지를 편집하게 할 수 없고 페이지 이동은 쉽게 지장을 줄 수 있다).그러나 정상적인 편집은 가능한 한 쉬워야 한다.장애물을 추가로 넣는 것은 단순히 더 많은 사람들의 편집을 단념시킬 뿐이다. --MZMcBride (대화) 08:04, 2009년 11월 8일 (UTC)[응답]

문제는 WP의 규칙이 항상 엄격해지고 있다는 것이다. - 대부분 정당한 이유로, 일부 성가신 사항들이 스팸 발송/POV-push/일반적으로 WP가 될 수 있는 새로운 방법을 찾기 때문이다.DE; 그리고 일부 규칙은 피할 수 없다(예: WP:BLP 또는 WP:카피비오.나는 우리가 간단하고 실용적인 (정책과 지침이 쓰여진 일반적인 관료주의자가 아니라); 최소한 95%의 시간 동안 주요 문제들을 전달할 것; 규칙의 전체 버전과 연결될 것이다. --필차 (대화) 17:49, 2009년 11월 15일 (UTC)[응답]라는 새로운 기사의 가이드가 필요하다고 생각한다.

당신의 소원은 우리가 말하는 대로 만드는 중에 있다 - 위키백과_토크:도움말_프로젝트#Simplified_ruleset_refactoring!이것은 우리가 위키백과 에 대해 몇 가지 소개를 할 때 가지고 있는 작은 추진력의 일부인데, 1페이지의 토론이 거의 끝나가고 있다.우리의 방식에 대해 자유롭게 논평/제안을 추가하라 :) Lee∴V (대화 • 기여) 2009년 11월 15일 (UTC) 20:11, 15 (응답)

방금 저기 아래 누군가가 새로운 사용자들에 의해 새로운 페이지의 미리보기를 강요할 생각을 가지고 있었다.의도하지 않은 결과를 초래하는 우리의 법칙을 그들에게 보여주는 것 또한 그렇다.나는 그 생각에 동의한다.나는 내 결정을 수정하고 모든 편집이 아닌 새로운 사용자들과 새로운 페이지들에게 좋을 것이라고 말하고 싶다.ViperSnake151 Talk 20:42, 2009년 11월 15일 (UTC)[응답]

다음을 참조하십시오.로그인되지 않은 편집기의 "페이지 저장" 단추 대신 "미리보기 표시" 단추를 굵게 표시하고 새 계정의 기본값으로 설정하십시오.만약 신입생이 한 번 편집하기 전에 "선호적인 액션" 설정을 바꾼다면, 그것은 그의 권한이다.물론 이것은 하나의 설정이 더 있다는 것을 의미한다.davidwr/(토크)/(contracts)/(e-mails) 02:09, 2009년 11월 18일 (UTC)[응답]

시 당국/특구 자치구

펜실베니아는 다른 주의 특수 목적 지구와 비슷한 1,700개 이상의 "자치 당국"이 있는 곳이다.이러한 시 당국은 대체적인 형태의 지방 정부지만, 특별한 목적을 위해 구성된다. 종종 수도, 하수, 주차, 주택 또는 경제 개발 목적의 거버넌스를 위해 구성된다.이러한 실체는 도시나 읍면지역과 같은 "일반목적정부"와 반대로 "특수목적정부"로 묘사되는 경우가 많다.이들은 단순히 시정의 하위급이 아니라, 세금과 채권발행권, 비난권한을 가진 정부 자신이며, 자치단체와 동일한 윤리와 개방된 정부법을 적용받고 있다.나는 이것이 결국 50개 주 모두의 특수 목적 정부로 확대될 수 있는 프로젝트라고 생각한다.

• 제안서 - 미국 인구조사국의 정부조사위원회는 10년에 두 번 이 모든 실체를 문서화하고 분류한다.나는 이 데이터를 시 당국의 이름, 관할권, 유형, 위치 및 기능이 있는 스프레드시트로 정리했으며, 승인된봇을 활용하여 이들 기관 각각에 대한 스터브 스타일의 기사를 만들고 싶다.나는 이 제안에서 몇 가지 자연스런 의문이 생기는 것으로 알고 있다.
  • 공신력 질문 - 거의 모든 지역 신문이 지방 자치 당국에서 회의 요약, 재무 데이터 및 사건을 다루기 때문에 각 기업과 그 활동을 기술하는 신뢰할 수 있는 출처가 부족하지 않아야 한다.게다가, 이 당국자들은 연례 보고서나 회의록과 같은 공문서를 통해서든 중요한 서류 흔적을 남긴다.마지막으로, 정부의 인구조사 자료가 있다.공신력에 대한 별개의 생각으로서, 공동체는 일반적으로 모든 정부, 종, 마을이 주목할 만하다는 데 동의했는데, 이는 필자가 생각하기에 시 당국/특구까지 확대되어야 한다고 생각한다.
  • 왜 봇인가? - 정부 인구조사에서 확인된 시 정부의 방대한 양 때문에 손으로 직접 코드화하는 것은 불가능하다.나는 이미 모든 텍스트를 쓰고 정리했지만, 그 작업은 너무 지루해서 수동으로 할 수 없다.
  • 왜 그냥 스텁일까? - 현재 데이터는 스프레드시트 형식으로 되어 있어 봇이 꽤 괜찮은 스텁처럼 보이는 기사 템플릿으로 데이터를 쉽게 구문 분석할 수 있다.
  • 예를 들어보자 - 템플릿이 어떻게 생겼는지 예를 들어보자.여기 이 스터브들이 어떻게 생겼을지 샘플이 있다.이 예로, 나는 수도권을 선택했다.
  • 이런 얘기 들은 적 없어! - 그건 이해할 수 있어.하지만, 우리는 아직 내가 들어본 적이 없는 모호한 수학 모델에 대한 기사들을 가지고 있다.여기 큰 예가 있다.필라델피아 주택청, 피츠버그와 알레게니 카운티의 스포츠 & 전시 기관
  • 확장의 가능성 - 나는 정말로 우리가 일단 이러한 실체들을 위해 스텁을 만들면, 사람들은 그것들을 확장할 것이라고 생각한다.많은 출처가 있고, 그들의 지방정부를 가까이서 따르는 사람들도 많다.나는 새로운 기사 작성이 감소하는 것에 대한 우려가 있다는 것을 알고 있어, 여기 단지 창작을 기다리고 있는 큰 기사 집단이 있다.또한 이러한 중요 실체를 인터넷의 선두에 올려놓음으로써 좋은 정부 및 개방적인 접속 혜택이 있다.--Blargh29 (대화) 22:49, 2009년 11월 10일 (UTC)[응답]

다음은 미국 인구조사국의 정부 인구조사 문서에서 가져온 특별 서비스 구역 및 시 당국 목록이며, 사용 가능한 경우 공식 URL이 있다.이 모든 예가 공신력 기준을 충족하는가?일부에서 그렇지 않다면 왜? --DThomsen8 (대화) 02:10, 2009년 11월 11일 (UTC)[응답하라]

• • • • 목록:
    • 센터 시티 구 (http://www.centercityphila.org)
    • Frankford Special Services District Of Philadelphia (http://www.frankfordssd.org)
    • 필라델피아 게만타운 특구
    • 필라델피아 마나용크 특별 서비스 구역
    • 구시 특별 서비스 구역(http://www.oldcitydistrict.org)
    • 펜실베이니아 컨벤션 센터(http://www.paconvention.com)
    • 필라델피아 병원 및 고등교육시설청(http://www.hospitalhighered.com)
    • 필라델피아 산업개발청 aka payed(http://www.paid-pa.org/)
    • 필라델피아 산업개발청(http://www.pidc-pa.org/))은 PIDA로 불린다.
    • 필라델피아 산업개발공사는 PIDC(http://www.pidc-pa.org/))로 불린다.
    • 필라델피아 지역 항만청(http://www.philaport.com/)
    • 사우스 스트리트 헤드하우스 구(http://www.southstreet.com)
      --DThomsen8 (대화) 02:16, 2009년 11월 11일 (UTC)[응답]

• 댓글을 달다.어떤 글과 마찬가지로, 이것들은 2차적인 출처를 가지고 있어야 한다.이들 중 상당수는 지역적 관심사일 뿐이고, 그마저도 국민의 재산세 고지서에 한 줄의 항목으로만 등장한다.납북(이유) 02:20, 2009년 11월 11일 (UTC)[응답]
• 정부 데이터의 인구 조사만 사용할 경우, 이러한 자료는 목록 기사로 제한되어야 한다(군별 또는 자치단체별로 구분).COG 데이터베이스에 정보가 부족하여 본격적인 기사를 작성할 수 없다.그루터기가 대량으로 생성되어서는 안 된다.목록 기사로 시작해서 2차 출처가 발견되었을 때만 개별 기사를 분리한다. --폴라론 토크 02:34, 2009년 11월 11일 (UTC)[응답]
• 앞에서 말했듯이, 기사 작성 전에 제3자 출처가 있어야지, 기본 데이터베이스의 덤프만 있는 것이 아니다.OrangeDog (주황색 • ε) 12:12, 2009년 11월 11일 (UTC)[응답]

각 주마다 이러한 여러 가지 권한을 생성, 가지치기 및 병합하기 위한 정책과 절차가 다르다.그들 중 몇몇은 정말로 중요하다. 그리고 가장 중요한 몇몇은 여러분이 들어본 적도 없고 언론에 보도되지 않은 사람들이다. (뉴올리언스의 제방 지역들을 기억하는가?)하지만 많은 사람들이 빈사상태고, 그들이 매우 중요하지 않고, 비통력적이기 때문에 듣지 못했다.지방 정부에서의 그들의 입장은 여전히 위키피디아 어딘가에서 주목되어야 하지만, 그들 모두가 그들 자신의 전문성을 가질 만한 것은 아주 멀다.봇이 각 주를 위해, 또는 각 군을 위해 만든 목록이나 테이블은 괜찮고, 아마도 필요할 것이다(또 어떤 구가 당신 자신의 강둑이나 물자원을 지키고 있는지 어떻게 알겠는가?) 그러나 모든 권위에 대한 내용 없는 그루터기를 만들면 그저 잡동사니를 만들고 나무로 숲을 감춘다.그 일은 인간 편집자에게 맡겨라.—— Shakescene (대화) 12:28, 2009년 11월 11일 (UTC)[응답]

우리는 스텁이 아닌 리스트가 가는 길이라는 것에 동의할 수 있을까?만약 그렇다면, 내가 위에서 제공한 것과 같은 리스트가 만족스러운 출발 패턴이 될까?대안은 위에 나타낸 것과 같이 공식 웹사이트 URL이 있는 일반 목록보다는 표를 갖는 것이 될 것이다.표는 더 많은 정보를 가질 수 있지만, 그것은 미국 인구 조사국의 정부 인구 조사에 이용 가능한 것으로 제한되어야 한다.그러나, 그곳의 일부 데이터는 오해를 불러일으킨다.펜실베니아 컨벤션 센터 당국은 공원과는 아무런 관련이 없지만, 정부 통계청은 달리 말한다.

여기서 공감대가 형성된다면, 나는 위의 목록에서 적절한 샘플을 만들 것이며, 일부 추가 기관이 나타나지 않는 것으로 강화될 것이다.제목이 필라델피아 카운티 시 당국 리스트가 될 수 있을까?이것에 의해, 나는 카운티별 개별 리스트를 암시하고 있다.필라델피아 카운티와 필라델피아 시가 정확히 같은 지리적 지역, 즉 펜실베이니아 연방의 독특한 상황을 가진 연합정부를 가지고 있기 때문에, 아마도 이것은 좋은 예가 아닐 것이다. --DThomsen8 (대화) 13:58, 2009년 11월 11일 (UTC)[응답]

제목이 펜실베이니아 시 당국인 List of Lacawanna County가 될 것이고, 그 카운티에서 가장 큰 도시인 펜실베이니아 스크랜턴의 See도 있을 것이다.란차완나 카운티 리스트에는 카운티 전체의 시 당국과 스크랜턴 시의 시 당국만 포함될 것이다.--DThomsen8 (대화) 14:10, 2009년 11월 11일 (UTC)[응답]

예(당분간 사용자 공간에서 주로)는 이 토론에 도움이 될 것이다.Sherth 15:47, 2009년 11월 11일 (UTC)[응답]

사용자:쉐어, 펜실베니아 카운티별 목록이 적절한 방법이라는 것에 동의하십니까?이름과 URL이 있는 목록이나 자세한 정보가 있는 테이블은?나는 적어도 현재의 방법과 기술로 이름과 URL이 있는 리스트를 더 쉽게 만들 수 있는 리스트를 선호한다.일단 샌드박스 항목으로 라카와나 카운티와 필라델피아 카운티 두 가지 예를 들어볼 수 있다.공감대가 형성된다면, 카테고리와 토크 페이지 템플릿으로 완성된 라이브 기사로 예를 옮기고 싶다. --DThomsen8 (토크) 15:57, 2009년 11월 11일 (UTC)[응답]

카운티별 리스트는 말이 되는 것 같다.앞서 언급한 바와 같이 이름/url 유형 목록을 작성하십시오. 나중에 변경될 수 있는 표 형식은 생각할 수 있지만 초기 예를 너무 복잡하게 만들 이유가 없는 경우.이 생각은 지극히 타당하다.2009년 11월 11일 셰어 16:05 (UTC)[응답]

그거 참 듣기 좋군.--Blargh29 (대화) 16:55, 2009년 11월 12일 (UTC)[응답하라]

나는 어떤 종류의 리스트를 보고 싶다.나는 이 작은 정부 기관들을 초등학교나 지역 수도 구역에서 보는 것과 같은 방식으로 본다.물론, 신뢰할 수 있는 출처에서 그것들을 참조하는 모든 방법을 찾을 수 있지만, 그것의 대부분은 디렉토리형 정보나 법에 의해 출판되어야 하는 정보들이다.목록을 구하거나 카운티와 같은 "부모" 기사 또는 시 당국(펜실바니아)과 같은 유형의 실체에 대한 기사(예: "부모" 기사)로 내용을 병합하십시오.이들 중 일부는 "그들 자신의 권리에 따라 불성실할 수 있으며" 기사를 가지고 있어야 하지만, 그것들은 손으로 만들어야 한다.데이비드워/(토크)/(기고)/(이메일) 02:16, 2009년 11월 18일 (UTC)[응답]