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

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

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

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

요청된 인터페이스 변경

먼저 MediaWiki_talk에 컨센서스가 필요한 요청을 게시했다.Common.js#Requested_change_to_Monobook_skin. -- IRP ☎ 22:21, 2009년 4월 17일 (UTC)[응답]

내 제안:굿 앤 피처링...편집자들!

안녕! 위키피디아의 일원으로서:친선 캠페인, 나는 편집자에 대한 우리의 고마움을 어떻게 보여줄 것인가에 대한 아이디어를 생각해 내고 싶었다.자, 무엇보다도 우선, 나는 여기서 우리가 강조하는 것이 내용, 즉, 종이 없는 백과사전-알마나크-게제터 조합의 일부로서 인간 지식의 총합에 기여하기 위한 글쓰기라는 것을 알고 있다. 하지만 위키피디아는 결국 자원 봉사 프로젝트로서 우리의 기여자들을 인정하고 미래의 기여자들을 위해 발표하기 위한 하나의 방법으로서 말이다.위키피디아가 그것의 반대편에 대해 감사하는 환영 환경으로서, 나는 우리가 좋은 기사들과 추천 기사들뿐만 아니라 좋은 기사들과 추천된 편집자들을 가지고 있다고 제안한다!나는 그것이 종종 메인 페이지에 있는 몇몇 편집자에게 정말 좋은 일이 될 것이라고 생각한다. 그 사이트에 건설적인 많은 기여를 한 몇몇 편집자는 물론, 그것은 누가 모범 편집자가 모방해야 하는지 그리고 무엇이 성공적인 위키피디아인이 수반하는지 보여주는 한 방법으로 우리의 독자들에게 모범 편집자의 몇 가지 예를 줄 것이다.우리는 RfAs와 Editor 리뷰와 관련하여 누구를 특징으로 할 것인가에 대해 토론을 할 수 있으며, 나는 우리가 보편적 지지에 꽤 가까운 심각한 충돌 없이 소수의 편집자들을 가지고 있다고 확신한다(예를 들어, 소수의 반대자가 있는 일부 Arbcom 후보자들은 수백 명의 지지자를 받고 있지 않은가).너희들은 어떻게 생각해?베스트, --A NobodyMy talk 03:31, 2009년 4월 11일 (UTC)[응답]

나는 이 아이디어를 좋아한다 - 그러나 고려해야 할 많은 문제들이 있다:
  1. 당신이 설정한 어떤 기준들에 대해 누군가가 그것을 게임을 시도하려고 할 수 있는 위험이 있다.이러한 이유로, 그것은 특정 기준을 만족시키는 것이 아니라 전반적으로 긍정적인 기여를 하는 것이라는 것을 강조해야 한다.
  2. RfA와 마찬가지로, 이것은 건설적인 비판을 위한 훌륭한 포럼이 될 수 있지만, 약간의 상처를 줄 수도 있다.누군가가 "공천 협박"을 할 때 사람들이 위협을 느낄 정도로, 그것에 너무 많은 중요성을 부여하지 않는 것이 중요하다.
  3. 너무 많은 수준은 사회적 계층의 위험을 야기한다."좋은" 편집자만 있으면 괜찮을 것 같아.
이것이 도움이 되길 바라. :-) Dcoetze 23:45, 2009년 4월 14일 (UTC)[응답]

관심사로서, 이것은 편집자들에게 헛간 스타를 주는 것과 어떻게 다를까?ACEOREVIVEED (토크) 2009년 4월 16일 (UTC) 20:06[응답]

우린 이미 이걸 가지고 있어.GA는 편집자 한 명의 승인만 필요한 반면 FA는 커뮤니티가 필요하다.헛간 별과 관리직은 동등하다.–MT 02:33, 2009년 4월 19일 (UTC)[응답]

삭제된 이미지를 숨기는 카르닐도의 봇들

카닐도가 만든 OrphanBot이나 ImageRemovalBot 같은 봇들은 현재 이렇게 완전히 삭제된 이미지를 삭제하는 대신 이렇게 삭제된 영상을 숨기고 있다.여기서 카르닐도에게 그것에 대해 물어봤더니, 그 당시 많은 사람들이 이미지가 어디에 있는지 알아보기 위해 이것을 요청한 것 같았다.만약 공감대가 있다면 카르닐도는 영상이 완전히 제거되도록 그것을 바꾸는 것을 기뻐한다.이것은 때때로 간격을 망치기도 하는 기사에 더 많은 숨겨진 잡동사니가 나타나는 것을 막을 것이다.여기를 봐(때로는 더 귀찮을 때도 있다.반대하시는 분?가리온96 (대화) 22:29, 2009년 4월 13일 (UTC)[응답]

그것들을 완전히 제거하는 것이 좋을 것 같아.내가 본 바로는 편집자들은 어쨌든 나중에 그것들을 삭제하는 경향이 있다.케임브리지베이 진입날씨, 소시지 22:37, 2009년 4월 13일 (UTC)이 아닌 관객들의 박수를 기다린다[응답하라]
추가 입력은 환영! :) 가리온96(대화) 16:59, 2009년 4월 15일 (UTC)[응답]
숨기는 것은 분명히 좋은 선택이다.이렇게 하면 어떤 방향으로든 해를 끼치지 않고 모든 봇과 세미봇 작업을 인간적으로 여유롭게 점검할 수 있다.나 자신도 숨겨진 이미지를 접하게 되었고, 그렇지 않았다면 할 수 없었을 이미지의 이름/로그에 기초하여 그것들을 대체할 수 있었다.아가토클레아 (대화) 21:37, 2009년 4월 15일 (UTC)[응답]
아가토클레아에 동의해...봇들이 이미지에 대한 참조를 완전히 없애도록 하는 것은 봇들에게 너무 많은 편집 통제권을 넘겨주는 것 같다...–xeno (대화) 21:42, 2009년 4월 15일 (UTC)[응답]
아마도 고아봇과 함께라면 나는 그것을 이해할 수 있을 것이다.하지만 이미지리모발봇은 어떨까?이미 삭제된 영상만 제거한다.페이지에서 삭제된 이미지를 제거하는 것은 삭제 관리자의 작업이어야 하며 관리자는 해당 이미지를 숨기지 않는다.이 봇은 단순히 그 일을 대신하는데, 왜 봇이 그것들을 숨겨야 하는가?가리온96 (대화) 2009년 4월 15일 22:22 (UTC)[응답]
IMHO, 봇은 이미 너무 많은 편집권을 가지고 있다.나는 최근에 로고가 gif->png에서 변환된 경우를 우연히 발견했고, 기사에서 변경되었다.그런 다음 gif는 봇에 의해 중복으로 표시되었다가 삭제되었다가, 그 페이지가 다시 이전 버전으로 파괴되었다가, png는 봇에 의해 고아로 표시되고 삭제되었다.코멘트에 이미지가 숨겨져 있다면 코멘트에 해당 이미지가 삭제된 이유도 포함시켜 사람의 개입 가능성을 높이는 것이 낫다고 덧붙이고 싶다.이상적으로는 중복 영상만 제거하지 말고 대체해야 하며 고아로 삭제된 영상을 제거해서는 안 된다. -스티브 산베그(대화) 22:11, 2009년 4월 15일(UTC)[응답]
봇이 이미지를 대체하는 것은 정말 너무 많은 편집 통제일 것이다.가리온96 (대화) 2009년 4월 15일 22:22 (UTC)[응답]

삭제된 이미지를 기본 "이미지 없음 - 업로드한 이미지" 이미지로 교체하는 것이 좋을 수 있다.나는 많은 템플릿들이 부적절한 이미지로 대체되고 되돌리는 대신 삭제되는 것으로 시작한다는 것을 안다.OrangeDog (토크 • 편집) 00:01, 2009년 4월 16일 (UTC)[응답]

페이지에서 삭제된 이미지를 제거하는 것은 삭제 관리자의 작업이어야 하며 관리자는 해당 이미지를 숨기지 않는다. 이 봇은 단순히 그 일을 대신하는데, 왜 봇이 그것들을 숨겨야 하는가? 너무 자주 이런 일이 발생하지 않으며, 삭제 관리자가 자동화된 프로세스와 얕은 검토를 통해 이미지를 삭제하는 경우가 너무 많으며(우리가 엄청난 백로그를 가지고 있기 때문에 공감할 수 있다...) 쉽게 수정되는 FUR 누락이나 잘못된 형식의 FUR과 같은 단순한 이유로 인해 이미지가 삭제되기도 한다.숨겨진 논평은 남아서 사람이 검토해야 한다.–xenotalk 14:07, 2009년 4월 18일 (UTC)[응답]
그 봇은 불과 4일 만에 500페이지를 편집했다.머지않아 위키피디아의 모든 페이지에 이런 잡음이 숨겨질 것이다.그런데 사람들이 그런 걸 좋아하는 것 같아.:) 가리온96 (대화) 2009년 4월 18일 16:19 (UTC)[응답]

제안사항

나는 당신의 웹사이트의 일반적인 레이아웃에 대해 몇 가지 제안이 있다.

모든 화면의 왼쪽 끝에 있는 전체 열인 탐색, 검색, 상호 작용, 도구 상자 및 언어 상자는 뷰어가 기사를 스크롤할 때 아래로 스크롤하도록 해야 한다.

이렇게 하면 글 중간에 멈추고 맨 위로 스크롤하는 대신 해당 기능을 사용해야 할 경우 뷰어를 위해 이러한 기능에 더 쉽게 액세스할 수 있다.

또한 –

기사 끝에 나타나는 '카테고리'에 대한 복사본을 추가하거나 종료 필드를 왼쪽 열로 이동하십시오.다시 한 번 말하지만, 이것은 사용자의 탐색을 쉽게 하는 데 도움이 될 것 같아.

좋은 웹사이트를 더 좋게 만들기 위한 몇 가지 제안.

고마워, 로버트 엘킨스

첫 번째 제안의 문제점은 모든 사람이 보이는 만큼 스크린을 가지고 있지 않다는 것이다; 만약 왼쪽 열이 화면에 고정되어 있다면, 한 화면에 맞지 않는 어떤 것으로 가기 위해 그 칼럼을 아래로 스크롤할 방법이 없다.아노미에 13:42, 2009년 4월 18일 (UTC)[응답]

WYSIWYG 테이블

미디어위키에게 일종의 WYSIWYG 테이블 편집 시스템이 있었다면, 더 많은 편집자들이 이런 정보 제시 방법을 활용할 수 있을 것이고, 기존 기사의 테이블의 품질도 크게 향상될 수 있는 잠재력을 가지고 있을 것이라고 생각한다.나는 이것이 얼마나 구현하기 어려운 것인지, 아니면 실현 가능한 것인지 전혀 알지 못하지만, 나는 당신이 행과 열을 추가/제거/분할/merge할 수 있는 일종의 '테이블 편집기' 페이지를 가질 것이라고 생각했다.개별 셀이나 다른 요소의 형식을 변경할 수도 있다.아래쪽에는 '테이블 삽입' 버튼이 있어 모든 것을 위키 마크업으로 변환하여 기사에 붙여넣을 수 있다.일단 요령을 터득하면 테이블 구문은 괜찮지만, 백과사전의 일반 편집보다 학습 곡선이 훨씬 높다.생각?자살 (토크) 08:46, 2009년 4월 19일 (UTC)[응답]

MediaWiki UI의 전면적인 개편이 진행 중이며, 가까운 곳에 곧 푸른 달이 떠오를 것이다.여기에는 기사 산문으로부터 메타데이터(ref, 카테고리, 테이블 등)의 분리, WYSIWYG 인터페이스가 포함될 가능성이 있다.아주 멋질 거야해피멜론 09:34, 2009년 4월 19일 (UTC)[응답]
매우 흥미롭지만, 어디서 논의되는가?러슬릭 (대화) 2009년 4월 19일 (UTC) 12시 18분[응답]
http://usability.wikimedia.org/wiki/에는 다른 곳들 중에서도 흥미로운 것들이 몇 가지 있다…{Nihiltres talk log}} 16:51, 2009년 4월 19일 (UTC)[응답]
UI에 대해 전반적으로 잘 모르지만 WYSIWYG 테이블 편집기에 대한 매우 강력한 지지를 표명하고 싶다.나는 그것이 정말 환상적인 생각이라고 생각한다.쿨3 (토크) 2009년 4월 19일 17:10 (UTC)[응답]

중재 페이지 이전

조정위원회는 중재 절차를 간소화하고 능률화하기 위해 아래와 같이 다양한 중재 관련 페이지를 재구성하고 재배치하기로 결정했다.

1단계(리리 페가지)

1A단계는 핵심 관리 페이지를 재배치하고 통합한다.

1B단계는 핵심 행정 상담 페이지를 통합한다.

1단계 후 구조

2단계(임의 요청 및 사례)

2A단계는 현재 진행 중인 중재 사례와 요청 페이지를 재배치하고 통합한다.

2B 단계는 중재 사건을 재배치하고 통합하며 기록물을 요청한다.

2C단계는 활성 중재 집행 페이지를 재배치하고 통합한다.

2단계 후 구조

이 제안은 9/0의 투표로 채택되었으며, 기권은 다음과 같다.

  • 지원: 카스리버, 카르차롯, 플로나이트, 키릴 록신, 렐레브스, 로저 데이비스, 샘 블랙테터, 바시아나, 마법사맨
  • 반대: 없음
  • 기권: 존 반덴버그
  • 투표 함: Hand Luke, Coren, FayssalF, Newyorkbrad, Risker, Stephen Bain

계획된 변경에 대한 언급은 4월 25일까지 이루어져야 한다.위원회가 접수된 의견에 따라 달리 결정하지 않는 한, 1단계는 4월 26일, 5월 1일까지, 2단계는 5월 2일에, 2단계는 5월 8일까지 완료된다.

위원회의 경우, Hersfold 02:31, 2009년 4월 20일 (UTC)[응답]

이 문제에 대해 논의하십시오.

감사 소위원회 절차, 기간 및 구성원

중재 위원회는 새로 구성된 감사 소위원회가 CU/OS 감사를 사용할 수 있는 잠정 절차를 채택하였다.위원회는 소위원회의 권고를 바탕으로 향후 절차를 수정할 수 있을 것으로 기대하고 있다.

이 절차는 기권 없이 11/0 투표로 채택되었다.

  • 지원: 카샤롯, 카스리버, 페이잘프, 플로나이트, 존 반덴버그, 키릴 록신, 리스크러, 렐레브세, 로저 데이비스, 샘 블랙케터, 위저드맨
  • 반대: 없음
  • 기권:없음
  • 투표 안 함:쿨 핸드 루크, 코렌, 뉴욕브래드, 스티븐 베인, 바시아나

위원회는 또한 소위원회의 중재위원을 6개월 임기로 임명하고, 나머지 위원들은 12개월 임기로 선출하기로 결정했다.

중재자 기간 길이는 기권 없이 12/0의 투표로 채택되었다.

  • 지원: 카샤롯, 카스리버, 페이잘프, 플로나이트, 존 반덴버그, 키릴 록신, 리스크러, 렐레브세, 로저 데이비스, 샘 블랙케터, 바시아나, 마법사맨
  • 반대: 없음
  • 기권:없음
  • 투표 안 함:쿨핸드 루크, 코렌, 뉴욕브래드, 스티븐 베인, Stephen Bain

선출된 임기 기간은 기권 없이 13/0의 투표로 채택되었다.

  • 지원: 카샤롯, 카스리버, 코렌, 페이샬F, 플로나이트, 존 반덴버그, 키릴 록신, 리스크러, 렙세, 로저 데이비스, 샘 블랙케터, 바시아나, 마법사맨
  • 반대: 없음
  • 기권:없음
  • 투표 안 함:쿨 핸드 루크, 뉴욕브래드, 스티븐 베인

소위원회의 초기 중재위원은 플로나이트, 존 반덴버그, 로저 데이비스다.다른 슬롯에 대한 중간 임명이 곧 발표될 것이다.

위원회의 경우, Hersfold 02:33, 2009년 4월 20일 (UTC)[응답]

이 문제에 대해 논의하십시오.

페이지 미리보기

섹션 편집 링크의 (비활성) 시뮬레이션을 페이지 미리보기에 포함시킬 수 있다면 정말 도움이 될 것이다.이를 통해 사용자는 복수의 사진이나 인포박스를 추가할 때 {{fixbunching}이(가) 필요한지 판단할 수 있다.극적(토크) 06:05, 2009년 4월 20일(UTC)[응답]

WP:RIP

나는 다음에 따라야 할 가능한 관행에 대해 토론하기 위해 제안을 추가했다: 위키백과의 대화:사망한 위키백과/사망된 위키백과인에게 따라야 할 실천요강 확립을 위한 제안 — Ched : ? 16:07, 2009년 4월 20일 (UTC)[응답]

이 제안은 어디로 가는가?

방금 위키프로젝트법 토크페이지에 제안서 올려놨어. (이거)좋은 피드백을 받고 토론을 시작하려면 누가 더 적절한 장소를 알고 있는지 궁금하다.내 제안서는 어디로 가는가?라는 질문에 대한 답변을 내 자신의 "대화" 페이지에 적어 주시겠습니까?고마워요.아그라드만 (대화) 03:27, 2009년 4월 21일 (UTC)[응답]

의제의 사례 마일스톤

앞서 약속한 대로 위원회의 안건은 아이티아스, 률롱, 요르단강 서안-유대와 사마리아 사건의 이정표 날짜를 표시하도록 갱신되었다.우리는 미래의 모든 사건들이 이런 식으로 추적될 것으로 기대한다.

위원회의 경우, Hersfold 01:55, 2009년 4월 23일 (UTC)[응답]

이 문제에 대해 논의하십시오.

감사소위 중간임명

중재위는 선거가 치러질 때까지 중간 감사소위에서 비임의석을 채울 매켄센, 대처, 츠츠나이를 임명했다.이들 편집자는 앞서 임명된 3명의 중재자와 함께 CheckUser- and Supervision 관련 불만사항에 대한 조사를 수행할 뿐만 아니라 감사 프로세스에 대해 설정된 임시 절차에 대한 위원회에 피드백을 제공할 것이다.

위원회의 경우, Hersfold 01:55, 2009년 4월 23일 (UTC)[응답]

이 문제에 대해 논의하십시오.

WP를 개정하기 위한 제안:PROD 정책

해결됨
- 그렇게 좋은 생각이 아니었을 수도 있다. tempodivalse [인터뷰] 2009년 4월 14일 (UTC) 19:07 [응답]

여러분 안녕하십니까?범주에 있는 몇 가지 기사를 훑어보고 있었는데:불분명한 주제의 기사들은 내가 무언가를 생각했을 때 내가 AfD를 할 수 있는지 확인하면서, 조금 전에 목록을 작성했다.우리가 제안하는 삭제 정책은 현재 별로 유용하지 않다. 왜냐하면 누구든지, 심지어 페이지의 작성자조차도 설명 없이 prod를 제거할 수 있기 때문이다. 왜냐하면, prod는 좀 쓸모없게 만들 수 있기 때문이다.제 아이디어: WP를 두 가지 수정:PROD 정책.다음 구성 요소:

  1. 페이지 작성자를 제외한 모든 사용자가 prod를 제거할 수 있다고 말하도록 변경하십시오.
  2. 기사의 토크 페이지나 편집 요약에서, 왜 프로드가 이의를 제기했는지 이유를 제시해야 한다고 덧붙인다.

위의 기준을 충족하지 못하면 프로드를 다시 작성할 수 있다.생각? tempodivalse [인터뷰] 17:46, 2009년 4월 14일 (UTC)[응답]

개인적으로, 나는 논쟁의 여지가 없는 삭제들을 위해 설계되었기 때문에 논쟁의 대상이 될 것이라고 생각한다.누구든지 이의를 제기하면 진실이 밝혀질 AFD로 가져가야 한다. - Jarry1250 17:49, 2009년 4월 14일 (UTC)[응답]
  • 반대한다. 프로드는 있는 그대로의 나쁜데, 기본적으로 아무도 보지 않는 동안 낮은 교통량의 기사가 깔개 밑으로 쓸려 들어가는, 나는 왜 기사 작성자가 그 위에 삭제에 이의를 제기할 기회를 거부당해야 하는지 이해할 수 없다.Equendil Talk 18:49, 2009년 4월 14일 (UTC)[응답]
  • 반대하라 누구나 prod 태그를 제거할 수 있다는 사실이 중요하다.태그를 지정함으로써 삭제는 논란의 여지가 없으며, 즉 아무도 반대할 수 없다고 말하는 것이다.태그 제거는 이의제기로, 기사 작성자는 다른 누구 못지않게 삭제에 반대할 권리가 있다.파블로hablo. 18:54, 2009년 4월 14일 (UTC)[응답]

흐흐흐흐.... 파블로미스모와 다른 사람들이 거기에 일리가 있는 것 같아, 나는 그런 생각은 별로 안 했어.삭제가 논란의 여지가 없더라도 PROD보다 AfD를 선호하는 이유다.나는 나의 제안을 철회한다, 너의 조언에 감사한다.Smile.png 건배. 템포디발스 [인터뷰] 2009년 4월 14일 (UTC) 19:07 [응답]

AFD 시스템은 이미 경색되어 있으며, 모든 PROD 기사를 AFD에 입력하면 매일 AFD의 수가 50-100%씩 증가할 것이므로 더 많은 논의가 필요한 기사는 논쟁의 여지가 없는 삭제에 더 많은 시간을 허비할 것이기 때문에 그것을 얻지 못할 수도 있다.PROD 대신 AfD로 기사를 넣는 것은 토론에 실제로 참여한 사람이 얼마나 적든 간에 나중에 누군가가 이의를 제기할 경우 완전한 DRV가 필요하다는 것을 의미하기도 한다.AFD !보터들은 또한 시스템 WP:V, WP:NPOV, WP:OR 또는 심지어 WP가 있는 기사들과 같이 종종 너무 공신력에 초점을 맞춘다.BLP 문제는 그러한 제안이 실제로 얼마나 합리적인지에 관계없이 주제가 주목할 수 있다면 "유지 및 정리"의 결과를 얻을 수 있다.미스터 지맨 02:27, 2009년 4월 15일 (UTC)[응답]
  • 아무도 반대하지 않을 정도로 논란의 여지가 없는 기사라면 기사는 속도감 있게 진행된다.Equendil은 거의 정곡을 찌른다.PROD는 기본적으로 당신의 작업을 추가적으로 확인하지 않고 무언가를 삭제하는 방법이다. - Mgm 10:21, 2009년 4월 17일 (UTC)[응답]
삭제 관리자가 삭제하기 전에 판단을 내리기를 바란다.Leithp 12:02, 2009년 4월 17일 (UTC)[응답]
  • prod의 개선은 토크 페이지나 편집 요약에 이유를 제시하지 않고 태그를 제거하지 못하게 하는 것이다. - Mgm 10:14, 2009년 4월 24일 (UTC)[응답]

사용자 정의 가능한 리디렉션 텍스트

이것이 얼마나 실행하기 어려울지 모르지만, 복잡할 수도 있는 것 같아, 버질라로 가기 전에 이곳에 글을 만들고 있다(이것은 이 논의의 결과물이다).

단순(X에서 리디렉션됨)을 넘어 사용자가 리디렉션될 때 대상 페이지 상단에 사용자 정의가 가능한 작은 메시지를 표시할 수 있도록 제안하고 싶다.이것 대신에, 몇 개의 사용자 정의가 가능한 위키텍스트가 한 두 문장으로 상단에 표시될 수 있다.이것은 문제를 찾는 해결책이 아니라 다음과 같은 몇 가지 문제를 해결하는 데 도움이 될 것이다.

  1. 그것은 여기서 "X"의 리디렉션의 필요성을 없앨 것이다.다른 용도의 경우, "X"에서 페이지로 오지 않은 경우 Y" 메시지를 참조하십시오.큰 문제는 아니지만, 많은 사람들은 이러한 메시지들이 짜증나고, 시각적으로 매력적이지 않거나, 주의를 산만하게 한다고 생각한다.사용자 지정 가능한 리디렉션 메시지와 함께, 이것들은 당신이 X페이지에서 왔을 때만 보여질 것이다.
  2. 그것은 잠재적으로 혼란스러울 수 있는 리디렉션을 명확히 할 수 있다.예를 들어 밥 덴트는 1995년 말기 병법의 권리로, 마누엘라 테스토리니는 프린스(뮤지션)로 방향을 바꾼다.만약 당신이 왜 이 페이지들에 도착하는지 모른다면, 그것은 꽤 혼란스러울 수 있다.당신이 리디렉션된 이유를 설명하는 상단의 작은 텍스트(예: "Manueal Testolini는 음악가 Prince의 전 부인")는 훨씬 더 명확할 것이다.
  3. 리디렉션된 이벤트/사물/장소에 대해 덜 일반적인 이름/닉네임을 명확히 할 수 있지만 리드에서는 언급되지 않는다.예를 들어 옥스퍼드 대학용 코울리 폴리테크닉(코울리 폴리테크닉에 대한 참조를 어디선가 보고 타이핑을 하지만 옥스퍼드 페이지에서 끝나는 경우, 무슨 일이 일어났는지 분명하지 않을 것이다)과 반대로 "코울리 폴리테크닉은 옥스퍼드 대학의 별명이다"는 메시지는 그것을 빨리 정리한다.

네 생각은?쿨3 (토크) 17:52, 2009년 4월 15일 (UTC)[응답]

좋은 생각인 것 같지만 소프트웨어 변경이 필요할 것 같아. --Apoc2400 (대화) 18:34, 2009년 4월 15일 (UTC)[응답]
  • 나는 이런 종류의 일에는 기술적으로 능숙하지 않지만, 리디렉션을 통해 페이지에 도달할 때만 나타나는 해트노트를 제안하는 것처럼 들린다.그 경우 나는 WP에 직관을 반영할 것이다.HATNOTE를 참고하고, 그러한 자료는 리디렉션 페이지에 수록되어 일부 독자들에게만 해트노트로 표시될 것이 아니라 주요 기사의 본문에 남아 있어야 한다고 제안한다.이렇게 하면 편집자들이 기사 자체뿐만 아니라 기사로의 모든 리디렉션을 유지할 필요가 없게 되고, 콘텐츠 요청의 위험을 피할 수 있으며, 모자 노트에 인용되어야 하지만 인용될 수 없는 주장을 하는 해트 노트의 위험성을 피할 수 있다. 또는 모자 노트에 사용할 수 있는 공간이 제한되어 손상된다.리디렉션하는 편집자들이 대상 페이지에 리디렉션 제목에 대한 언급을 포함하도록 하고 리디렉션을 해당 섹션에 연결하도록 권장하는 것이 좋을 것 같다.베일리팔블루 (대화) 2009년 4월 15일 18:37 (UTC)[응답]
    음, 난 정확히 해트노트를 제안하는게 아니야.나는 본문의 본문에 있는 정보를 유지하는 것에 전적으로 찬성하지만, 그것에 주의를 끌 수 있도록 돕는다.위의 예에서, 그 정보는 항상 기사에 포함되어 있지 않다. 단지 선두에 있지 않을 뿐(그리고 선두에 적절하지 않을 것이다), 그래서 내가 제안하는 것은 사람들이 그것을 찾을 수 있도록 돕는 방법이기 때문에, 리디렉션된 후에, 그들은 "내가 왜 이 페이지에 있는가?"라고 생각하지 않을 것이다.쿨3 (토크) 2009년 4월 15일 19:33 (UTC)[응답]
이는 MediaWiki를 편집하여 수행할 수 있는 작업:{{editetice load}}과(와) 유사한 템플릿에서 변환된 템플릿으로 리디렉션됨{{redirect notice load $1}}. 그것이 좋은 생각인지 아닌지는 말할 수 없었다.Anomie⚔ 22:50, 2009년 4월 15일 (UTC)[응답]
그것은 기술적으로 가능하다. 왜냐하면 그 메시지는 완전한 위키마크를 필요로 하기 때문이다. (많은 시스템 메시지는 그렇지 않다.)우리는 그 아이디어에 어느 정도 주의를 기울여 접근해야 할 것이고, 우선 해트노트를 어디에 둘 것인지에 대해 생각해 볼 필요가 있을 것이다. 하지만 나는 근본적인 문제가 있다고 생각한다.사실 꽤 좋은 생각일 수도 있다.해피멜론 09:39, 2009년 4월 17일 (UTC)[응답]
소프트웨어 변경 없이 할 수 있다면 해볼 만한 가치가 있을 것 같다(공개: 위키백과 강연에서 한 내 발언이었다.공신력(사람)#Cool3가 이 제안을 하게 된 BIO1E 구현 방식 변경 제안).사용 지침은 WP에서 쉽게 적용할 수 있다.해트노트.한편, 유지관리성 문제가 너무 강한 경우, 대상 기사에 해트노트 텍스트를 포함시킬 수 있는 방법이 있을 수 있지만, 특정 리디렉션에서 온 경우에만 표시된다.Rd232talk 01:43, 2009년 4월 18일 (UTC)[응답]
이것의 많은 혜택은 기사 그 자체가 아니라 기사의 한 섹션으로 리디렉션하여 처리할 수 있다.어려운 것은 물론 그것을 유지하는 것이다; 우리는 경고문을 넣을 수 있고 심지어 본문에 앵커까지 넣을 수 있지만, 이것들은 거의 사용되지 않고 종종 무시된다.다행히 링크의 섹션 부분이 고장날 경우 여전히 기사 상단으로 리디렉션되기 때문에 한 섹션을 넣는 데 부정적인 결과는 없다.DGG (대화) 21:22, 2009년 4월 18일 (UTC)[응답]
토론의 시작점(Wikipedia Talkipedia Talk:공신력(사람)#BIO1E 시행방식 변경 제안) 바이오 기사는 다른 곳으로 넘어가는 경우가 많고, 목적지에서 명확하게 다루는 구간이 없을 수 있다는 것이다.지나가는 사람을 언급하는 섹션으로 리디렉션하는 것이 기사로 리디렉션하는 것보다 낫지만, 그것은 리디렉션을 약간 혼란스럽게 만든다.그러나 리디렉션 + 메시지가 더 도움이 될 것이다.Rd232talk 22:28, 2009년 4월 18일 (UTC)[응답]
페이지 상단에 리디렉션 메시지가 표시되도록 하려면, 동시에 기사의 #섹션으로 리디렉션할 수 없다.따라서 페이지 상단 리디렉션 메시지가 있으면 리디렉션 용어가 언급된 문서에서 위치를 찾기가 더 어려워질 수 있다.리디렉션 메시지 자체에 해당 기사에서 리디렉션 용어가 발견되는 #섹션 링크가 포함되어 있지 않은 경우. --83.253.240.46 (대화) 11:35, 2009년 4월 24일 (UTC)[응답]
이 제안은 필요를 채워줄 수 있고, 나는 그것이 정책의 간단한 설명으로 이루어질 수 있다고 생각한다...좀 직관에 반하는 것이긴 하지만우리는 위키피디아에 항목이 없는 주제에 대해 모호한 페이지를 허용해야 한다.놀랄 것도 없이, 위키피디아:해명은 사실 이 점을 언급하지는 않지만, 나는 그것이 가장 좋은 해결책이라고 생각한다.밥 덴트의 예와 같은 리디렉션과 혼동을 일으키는 유일한 이유는, 놀랍게도, 지금까지 위키피디아의 주목을 받은 사람은 오직 한 사람뿐이며, 그렇지 않으면 다른 "밥 덴트" 페이지 상단에 있는 해트노트가 상대방이 누구였는지 말하거나, 또는 모호한 페이지가 원하는 정보를 제공할 것이기 때문이다.설명 페이지는 밥 덴트의 기존 리디렉션을 대체할 것이기 때문에 실제로 전체 기사 수를 증가시키지 않을 것이다.
그렇긴 하지만, 이 예는 실제로 필요하지 않은 경우 중 하나인데, 검색 결과 다른 "밥 덴트"를 참조하는 위키백과 기사를 찾을 수 없고, 현재 리디렉션 기사에서 #섹션 링크가 가능하기 때문이다.그러나 이 두 가지 중 어느 하나라도 그렇지 않다면, 나는 디스큐 페이지를 이용하는 것이 좋을 것 같다.마이크 세파스 (토크) 2009년 4월 24일 (UTC) 21:38[응답]

알려진 언어

나는 전기 과목에 알려진 언어를 추가할 가능성에 대해 생각해 보았다.많은 전기 기사들이 인용문을 번역했기 때문에 나는 그것이 꽤 유용한 정보가 될 수 있다고 생각했다.''wuffyz'(대화) 04:23, 2009년 4월 16일 (UTC)[응답]

이건 이해가 안 돼기사의 주제가 이해한 언어를 나열하라는 말씀이십니까?아니면 다른 언어 위키피디아로 기사를 나열하려면? --Gadget850 (대화) 13:09, 2009년 4월 18일 (UTC)[응답]
주제에 의해 이해되는 언어 목록.Wuffyz 00:50, 2009년 4월 20일 (UTC)
  • 백과사전일 수도 있지만, 내 경험상 그런 정보는 보통 검증하기가 매우 어렵다. - Mgm 10:15, 2009년 4월 24일 (UTC)[응답]

새로운 "이세이" 네임스페이스 제안

나는 "위키피디아" 네임스페이스에 에세이를 배치하는 것은 혼란스럽고 때때로 파괴적일 수 있다고 믿는다.한편으로 에세이(본질적으로 개인적인 논평)와 다른 한편으로 정책과 지침(본질적으로 표현하면 아무리 불완전하더라도 지역사회의 공감대가 형성되는 것)의 구분이 부족하게 된다.새로운 "이세이" 네임스페이스는 그러한 잠재적인 혼란이나 혼란을 피할 수 있을 것이다.던컨힐 (대화) 15:38, 2009년 4월 17일 (UTC)[응답]

프로젝트 네임스페이스에서 에세이에 의해 야기된 "분란"의 특별한 예를 알고 있는가?나는 약간의 혼란에 개의치 않는다. 특히 그것이 사람들을 WP로 이끈다면 더욱 그렇다.IAR, 그리고 만약 그들이 어떤 것이 정책인지 가이드라인인지 에세이인지에 대한 관심을 멈추는 법을 배운다면.나는 그러한 구별을 강조하는 어떤 것에도 동의하지 않는 경향이 있는데, 별도의 네임스페이스가 분명히 그렇게 할 것이다. -GTBacchus(talk) 16:15, 2009년 4월 17일 (UTC)[응답]
위키백과 네임스페이스에 있는 대부분의 것들은 에세이도 아니고 정책도 가이드라인도 아니다.우리는 MFD 토론과 정책을 혼동하는 사람들이 없다.어쨌든 나는 GTBacchus에 동의한다.메시지는 중요한 것이지 태그가 아니다.미스터 지맨 2009년 4월 17일 (UTC) 16:18[응답]
GTBacchus와 Mr.Z-man의 의견에 동의하라. 나는 어떠한 혼란이나 혼란도 보지 않는다.고장나지 않았다면 고치지 마.EVULA // talk // talk // 21:31, 2009년 4월 17일 (UTC)[응답]
  • 위키백과 네임스페이스에 있는 모든 글들은 그 이름들 중 하나라도 해당되는 경우 에세이, 정책 또는 지침으로 태그될 수 있다.템플릿이 이미 그 기능을 충족시켰을 때 별도의 네임스페이스를 만들 필요는 없다. - Mgm 10:17, 2009년 4월 24일 (UTC)[응답]

관리자는 사용자의 자동 확인 상태를 취소할 권한이 있어야 함

이것을 지지하거나 반대하는 사람은 누구인가?관리자가 이미 이 작업을 수행할 수 있는 능력을 가지고 있는가?그렇지 않으면 페이지 이동 전쟁 대처에 유용하기 때문에 이용할 수 있도록 해야 한다. -- IRP ☎ 22:28, 2009년 4월 20일 (UTC)[응답]

나는 반대한다.현재, 관리자는 사용자를 차단할 수 있으며, 이는 사용자를 취소하는 것과 같다. -Porchcrop(talk contributions) 22:58, 2009년 4월 20일 (UTC)[응답]
그렇다면 남용필터가 사용자들의 자동확증 상태를 해지할 수 있는 이유가 뭘까? - IRP인터뷰 23:11, 2009년 4월 20일 (UTC)[응답]
남용 필터는 필터를 트리거하는 사용자를 차단, 디스샵 또는 디래트하는 기술적 능력을 가지고 있다. 그것이 바로 작동 방식이다.놀랄 것도 없이, 그 아세톤은 사용되지 않고 있으며, 현재 엔위키에서 사용할 수 없다.디오토콘펌프도 똑같이 사용하지 않는 AFAIK인데, 마침 사용할 수 있게 되었다.해피멜론 16:53, 2009년 4월 24일 (UTC)[응답]
최근에 여기서 논의한 내용.대수학자 23:04, 2009년 4월 20일 (UTC)[응답]

'움직임=syop'도 효과가 있다.–xeno 12:34, 2009년 4월 24일 (UTC)[응답]

실제로, 사용자 X가 페이지를 이동하는 것을 막을 필요는 없지만(단순히 사용자 X를 차단할 수는 없음) 모든 사용자들이 동일한 페이지를 이동하는 것을 막을 필요는 없는 상황은 생각할 수 없다.이동 전쟁이 있거나(이동 보호를 위해), 사용자가 페이지 이동-반달라이징(이 경우 블록) 중이거나, 해결할 문제가 없다.다른 시나리오를 제안할 수 없다면?해피멜론 16:53, 2009년 4월 24일 (UTC)[응답]
AF 디오토콘 확인에 대한 주장에 대항하기 위해: 그것은 관리자가 상황을 검토하고 적절한 경우 차단할 수 있을 때까지의 임시 조치일 뿐이다.–xeno 16:57, 2009년 4월 24일 (UTC)[응답]

봇에서 하드 코드로 템플릿 결과 변환

이동됨. 위키백과:마을 펌프(기술)#봇을 하드 코드로 변환 템플릿 결과.—EncMstr (talk) 05:32, 2009년 4월 24일 (UTC)[응답]

그 통지의 요점은 논란이 될 수 있는 봇 요청을 더 많이 보는 것이었고, 여러 곳에서 토론을 시작하는 것이 아니라, 마지막에는 사람들이 BRFA 페이지에 댓글을 달도록 지시하는 것이었다.아마도 좀 장황한 것이었을지 모르지만 완전히 제거하는 것이 올바른 방법인지는 잘 모르겠다.Anomie⚔ 11:01, 2009년 4월 24일 (UTC)[응답]

의견조사/토론: '설립된' 사용자 그룹 생성에 대해

자동화를 통한 확립된 사용자 그룹 생성, 자동 승인 및 검토자 상태 간의 중개, 플래그 지정된 보호 및 개정 시험 이행 순찰을 위한 토론/공론이 있다.댓글 환영, Cenarium (대화) 23:52, 2009년 4월 24일 (UTC)[응답]

검색 결과 - 문서 작성 마법사

가정: 빨리 고갈되거나 AFD로 끝나는 많은 기사는 사람들이 무언가를 찾고, 아무것도 찾지 못하고, 검색 결과 페이지에서 두 개의 빨간색 링크 중 하나를 클릭하여 기사를 작성함으로써 만들어진다.제안:새로운 사용자가 위키백과 사용을 권장하는 새로운 페이지로 이동하십시오.조항_for_creation/Wizard 및 보다 경험이 많은 사용자를 위한 레드링크(및 관련 정책에 대한 링크)를 제공한다.Rd232 22:40, 2009년 4월 18일 (UTC)[응답]

기사를 좋아하는 사람들을 도우려고 노력하는 것은 고귀한 일이다.그러나 너무 많은 정보를 가지고 수색자들에게 과부하를 주는 것과 그들이 하고 싶은 것을 돕는 것 사이에는 상충이 있다.이미 빨간색 링크에는 충분한 옵션이 있다.일단 이 버튼을 클릭하면, 그것은 로그인하지 않은 사람들에게 오류 메시지를 주는 것이 아니라 AfC 프로세스가 광고될 수 있는 기회다.그것은 결국 AfC 기부의 수를 엄청나게 증가시킬 수도 있기 때문에, 우리는 더 많은 자원봉사자들이 필요할 수도 있다.로그인하지 않은 것을 감지하여 빨간색 링크가 다른 일을 하도록 하는 것이 가능한가?Graeme Bartlett (talk) 2009년 4월 19일 21:16 (UTC)[응답]
나는 검색 결과 페이지에 대한 더 많은 정보를 제안하는 것이 아니라, 그 페이지에 있는 두 개의 빨간색 링크를 클릭하면 새로운 중간 페이지가 나타나도록 제안하고 있었는데, 이 중 하나는 AfC 마법사를 위한 도움말 안내와 옵션이다.그렇다, 이것은 더 많은 AfC 자원 봉사자들을 필요로 할 것이다; 그러나 아마도 이것은 최소한 덜 CSD와 AFD 작업으로 균형을 맞출 것이다.Rd232talk 21:35, 2009년 4월 19일 (UTC)[응답]
그 점에서는 내가 너의 의견에 동의하는 것처럼 들린다.Graeme Bartlett (대화) 21:52, 2009년 4월 19일 (UTC)[응답]
WP:기사 마법사 -그 틀이 거기 있어, 약간의 시간을 쓸 수 있는 사람들이 필요할 뿐이야.Mr.Z-man 01:04, 2009년 4월 20일 (UTC)[응답]
야, 너 그거 우리꺼 훔쳤니? 아니면 우리가 훔쳤니?— 마틴 (MSGJ · talk) 2009년 4월 21일 16:31 (UTC)[응답]
AfC 마법사가 더 잘 개발되었지만, 그것은 부차적인 점이다.사람들이 원칙적으로 좋은 아이디어라고 생각하는지, 그리고 그렇게 생각한다면 새로운 중간 페이지로 레드링크를 만들기 위해 검색 결과 페이지를 편집하는 것이 기술적으로 얼마나 어려운지 알고 싶다.Rd232 00:46, 2009년 4월 22일 (UTC)[응답]

내가 보기엔 보기에도 좋고 좋은 생각인 것 같아.나는 그 제안을 전적으로 지지한다.나는 미디어위키: 검색결과 텍스트를 편집할 수 있는 어딘가에 페이지가 있다고 생각한다.-코트니스키 (토크) 14:25, 2009년 4월 26일 (UTC)[응답]

네가 보내준 메시지 덕분에 관련 메시지를 찾았어.하나는 적절히 편집할 수 있다.MediaWiki:Noexactmatch는 Create New Page redlink를 제공한다.다른 하나는 다른 것에 소프트웨어가 내장되어 있는 것 같다(미디어위키:검색결과 제목?) 따라서 개발자의 개입이 필요할 수 있다.그러나 새로운 페이지 작성은 더 두드러지기 때문에, 우리는 그것부터 시작할 수 있다.내가 보는 유일한 문제는 새로운 중간 페이지에 적절한 레드링크를 가지고 싶은데, 어떻게 해야 하는지 모르겠어.대안은 MediaWiki의 Create This Page 하위 섹션(Create This Page:노익스펙트 매치.User:Rd232/Noexactmatch/Proposal에서 제안서를 작성했다.Rd232 16:27, 2009년 4월 26일 (UTC)[응답]

요청됨

MediaWiki에 대해 이 요청을 했다.새로운 기사문 fahadah (talk, contracts) 2009년 4월 26일 (UTC) 18:52 [응답]

그것은 시기상조라는 이유로 거절당했다.또한 뉴기사 텍스트는 기능이 실질적으로 다르다.당신의 열정은 고맙지만, 한 번에 한 가지씩 하자.Rd232talk 22:41, 2009년 4월 26일 (UTC)[응답]
아, 그리고 AfC 마법사는 무등록 사용자를 대상으로 하기 때문에 적응하지 않으면 적합하지 않다는 지적이 있어.그래서 사람들이 그렇게 할 가치가 있다고 생각한다면, 우리는 마법사를 따라하고 적응할 필요가 있을 것이다. 내 생각에는 큰 문제가 아니다.Rd232 02:04, 2009년 4월 27일 (UTC)[응답]

새 각주 태그

나는 위첨자 각주 태그가 위키백과에서 발견되는 6가지 과학 분류 각각에 대해 만들어질 것을 제안한다: 체외, 체내, 체외, 자궁 내, 그리고 심지어 실리코에서도 발견된다.

니즈: 각주로 참조되고 있는 실험의 특수성을 독자에게 균일하고 간결하게 전달한다.이 변경사항을 이행하면 참고문헌의 필요성 검토에도 영향을 미칠 수 있다.

해결해야 할 문제: 기사에서 언급된 사실 진술은 예를 들어 체내 문맥을 암시할 수 있지만, 언급된 연구는 사실상 체외 문맥일 수 있다.이러한 제안된 변경은 위첨자 각주 자체의 식별자를 통해 그러한 혼란을 방지할 수 있을 것이다.

이것은 문제를 찾기 위한 해결책처럼 보인다.우리는 항상 어떤 일이 일어나고 있는지 설명하기 위해 텍스트를 사용할 수 있고, 그것은 각주의 암호화된 표시보다 99%의 독자들에게 훨씬 더 명확할 것이다.— 칼 (CBM · talk) 00:56, 2009년 4월 23일 (UTC)[응답]
OP가 굳이 제공하려고 하지 않았기 때문에, 여기 그들이 마지막으로 이 제안을 한 시점과의 연결고리가 있다.대수학자 01:02, 2009년 4월 23일 (UTC)[응답하라]
어디선가 알아본 것 같은데...해피멜론 12:26, 2009년 4월 25일 (UTC)[응답]

요소 팩트 상자에 EC 번호 포함

나는 CAS 번호가 이미 존재하므로 Element 팩트 박스에 EC 번호를 포함시킬 것을 제안한다.이런 목적을 위해 템플릿을 만들었다.템플릿:Elementbox_ec_number.만약 받아들여진다면, 나는 이제 모든 요소에 대해 이것을 한 번에 어떻게 해야 하는지 모르겠다(실제 숫자가 아닌 필드를 제자리에 놓아라). --Eivindgh (토크) 09:06, 2009년 4월 24일 (UTC)[응답하라]

{{Elementbox}}을(를) 변경하여 변경 사항을 적용하십시오.템플릿이 보호되지 않기 때문에 관리자가 변경하도록 할 필요는 없다.이에 대한 합의가 있기 전에 변경하지 마십시오.최소한 템플릿 토크에 게시하십시오.Elementbox, 여기 말고, 변경에 관심이 있는 편집자들이 이 페이지를 읽지 않을 가능성이 높기 때문이다.위키피디아 토크에도 글을 올려야 한다.위키프로젝트 요소 - 관심 있는 편집자들이 당신의 제안을 볼 수 있도록 하기 위한 것. -- John Brown (식별) 13:26, 2009년 4월 26일 (UTC)[응답]

제안된 위키백과 제목, 삭제 취소 요청

여기 완전 제안. --Ron Ritzman (토크) 20:56, 2009년 4월 26일 (UTC)[응답]

위키백과:삭제 취소 요청

이 프로세스 페이지는 사용자:위키백과의 론 리츠만:삭제 프로세스#프로포즈된 위키백과 제목, 삭제 취소 요청(permlink) 및 우리들 중 몇몇은 논란의 여지가 없는 복원과 사용자 통신을 요청하는 중앙 페이지에 동의하는 것이 좋은 생각이었다.나는 그 페이지를 자유롭게 초안을 작성하고 그 과정을 커뮤니티에 제출하여 의견을 개진하고 추가 검토를 했다.여기서가 아니라 WT:삭제 요청에서 논의하십시오.–xeno 13:59, 2009년 4월 27일 (UTC)[응답]

ArbCom 청문회 개편 관련 RFC

모든 편집자들이 주목하는 것은 영어 위키백과의 주요 이슈에 대한 논평 요청(Request for Comment)에 관한 것으로, ArbCom 청문회 과정을 지금까지 특징지었던 느슨하고 확장적인 모델에서 벗어나 보다 엄격한 조직적 모델로 옮기자는 6가지 제안의 패키지다.RFC는 4월 29일 화요일에 시작되었다.토니 (토크) 2009년 4월 28일 14:31 (UTC)[응답]

뒤죽박죽인 링크 종류들

이 문제는 어떻게든 고쳐야 한다.문제는 이렇게 많은 내부 링크가 외부 링크로 나타나고, 외부 링크가 내부 링크나 인터위키 링크로 나타나는 것이다.일부 예는 다음과 같다.

  • 일부 구글 링크는 인터위키 링크를 사용하여 구글과의 연결이 가능하기 때문에 내부 또는 인터위키로 나타난다.인터위키 테이블은 의도된 목적을 위해 사용되지 않고 있다.구글은 위키가 아니기 때문에 인터위키 테이블에서 제외되어야 한다.{{Google}} 템플릿을 사용하여 외부 링크를 사용하는 구글에 연결해야 한다.
  • 많은 편집자가 디프 링크에 <span class="plainlinks"></span>을 사용하지 않기 때문에 많은 디프프 링크가 외부로 나타난다.거의 2년 전 Bugzilla:11477에서 그러한 링크를 외부로 표시해서는 안 된다는 것이 제안되었지만, 그 제안은 잊혀져 왔다.그래서 나는 미디어위키 토크에서 그것을 재제안했다.Common.js#모노북 피부 변경 요청

이것은 어떻게든 고쳐질 필요가 있다.어느 쪽이든

  • 인터위키 테이블에서 비위키 제거.그게 인터위키 테이블이 아니라 외부 링크 템플릿이 제공하는 목적이지
    • Wikimedia 외부에서 연결된 모든 접두사를 인터위키 테이블에서 제거하고 Wikimedia의 일부인 사이트만 그대로 두는 경우(그런 다음 템플릿 사용)
  • 인터위키 테이블의 접두사를 포함하는 링크가 외부 또는 외부로 표시되지 않도록 모노북 스킨 변경
  • 수정할 수 없는 경우 링크 유형을 모두 제거하는 중

현재 링크 유형은 너무 일관성 없이 사용되기 때문에 더 이상 목적에 부합하지 않는 것 같다.이를 쉽게 고칠 수 없다면 링크 유형을 제거하고 모든 링크가 동일하게 보이게 하는 것이 좋다. -- IRP ☎ 21:30, 2009년 4월 23일 (UTC), 수정 22:37, 2009년 4월 23일 (UTC)[응답]

T20562는 이를 도울 수 있을 것이다. T20562는 구글과 같은 '외부' 인터위키 링크를 요청한다.Foo, meta와 같은 '로컬' 인터위키 링크로부터 분리:Foo. 불행히도, 그러한 변화는 악명 높은 기능을 다시 쓰도록 요구하는데, 이것은 심지어 bugzilla에 대한 Tim Starling의 quip을 가지고 있다("모든 사람은 한 번 교체하는 것을 본다.InternalLinks and go to watch TV").그러나 충족될 경우, '외부' 인터위키 링크에 외부 링크 화살표가 주어질 수 있다.
이것이 문제라는 데는 동의하지만, 나는 "연결유형을 완전히 없애는 것"은 조금 심하고 목욕물과 함께 아기를 버리는 것 둘 다라고 말했다.이 상황을 명확히 하기 위해서는 다음 두 가지가 필요하다.
  1. 외부 링크 구문 [http://en.wikipedia.org/wiki/Foo]으로 구성된 로컬 Wiki에 대한 링크는 외부 링크 아이콘을 가져오지 않아야 함
  2. 인터위키 링크 구문 구글을 통해 형성된 '외부' 위키 링크:Foo, 외부 링크 아이콘이 표시되어야 한다.
이러한 목적을 어떻게 달성하는가는 논의의 여지가 있다.해피멜론 22:22, 2009년 4월 23일 (UTC)[응답]
인터위키 테이블에서 외부 접두사를 제거하고 대신 외부 링크 템플릿을 사용하는 것이 더 나을 것이다(적어도 임시로).Parser::replaceInternalLinks() 고정되어 있다. -- IRP인터뷰 20:43, 2009년 4월 24일 (UTC)[응답하라]
그럴 필요는 없을 것 같아.우리는 특정 대상과의 외부 링크에서 제거할 수 있는 것처럼 특정 대상과의 인터위키에 외부 링크 아이콘을 줄 수 있다.그렇게 하기 위해서는 단지 의견이 일치할 필요가 있다.해피멜론 12:21, 2009년 4월 25일 (UTC)[응답]
어떻게 그렇게 할 수 있을까?파서 기능을 수정해야 할까? - IRP 인터뷰 20:28, 2009년 4월 25일 (UTC)[응답하라]
역작전에 제안된 코드와 유사한 코드를 사용하여 CSS로 수행할 수 있다.이와 같은 코드:
#바디컨텐츠 a[href ^="http://en.wikipedia.org/"] {     배경: 없는 !중요하다;     패딩 우의: 0 !중요하다; }
위키백과 링크에 대한 아이콘을 숨긴다.
#바디컨텐츠 a[href ^="mbp://ww.google."] {     배경: .(.png) 중심 맞다 무통행의;      처리: 0 13px를 붙이다; }
구글에 추가할 것이다.이 코드는 Common.css에 추가해야 하는 것이 아니라, Common.css에 추가되어야 한다.다른 토론에서 MediaWiki에 지속적으로 연결하는 것은 실제로 잘못한 것이다.보통.js "모노북 피부"라고 말할 때."모노북"은 전체 사용자 인터페이스를 구성하는 약 40개의 파일들로 구성된 그룹으로, 이 중 on-wiki JS 파일은 작은 부분에 불과하다.외부 링크 화살표는 CSS를 통해 추가되므로 CSS와 동일하게 숨겨질 수 있다.어쨌든 대부분의 사용자들에게, 위의 CSS는 모든 브라우저에서 작동하지 않을 것이다.해피멜론 16:04, 2009년 4월 26일 (UTC)[응답]
애초에 추가되지 않은 곳에 만들 수 있을까?그래야 어떤 브라우저에서도 잘못된 링크가 나오지 않을 것이다. -- IRP인터뷰 18:18, 2009년 4월 26일 (UTC)[응답]
그것은 "수정" 옵션일 것이다.해피멜론 18:27, 2009년 4월 26일 (UTC)[응답]
그렇다면 파서 기능이 작동할 때까지 위의 코드를 임시로 빠른 수정으로 사용해야 한다. -- IRP ☎ 18:37, 2009년 4월 26일 (UTC)[응답]
(ec) "인터위키 테이블은 의도된 목적으로 사용되고 있지 않다.구글은 위키가 아니기 때문에 인터위키 테이블에서 제외되어야 한다." – 아마도 당신은 내가 의도하지 않은 목적에 대해 알고 있을 것이다. 하지만 나는 그것이 단순히 다른 위키와 연결을 더 편리하게 하기 위한 것이라고 생각했다.구글과도 통할 줄은 몰랐지만, 이제 구글:테스트를 생산하기 위해 간단히 [[구글:테스트]를 쓸 수 있다는 것을 알게 되었으니, 나는 아마도 가끔 그것을 사용할 것이다. (하지만, 공간은 밑줄로 대체되기 때문에 여러 단어로 이 작업을 할 수 있는 방법은 없어 보인다.)
내가 이해할 수 없는 것은 왜 그러한 링크가 외부 링크 아이콘 없이 나타나는가 하는 것이다.이것은 다른 위키미디어 재단 프로젝트에는 이치에 맞지만, 인터위키 테이블에 있는 대부분의 사이트에서는 이치에 맞지 않는다.현재 아이콘은 "http:"를 시작하는 모든 외부 링크에 대해 추가되며 인터위키 접두사로 시작하는 외부 링크에는 추가되지 않는다.서버가 예외 목록에 없는 모든 외부 링크에 아이콘을 추가하는 것이 올바른 행동일 것이다. 인터위키 접두사를 통해 구성되었는지, 인터위키 맵에 나타나는지 여부 등은 차이를 만들어서는 안 된다. --Hans Adler (talk) 22:38, 2009년 4월 23일 (UTC)[응답]

(갈등 편집) "인터위키 지도"가 비위키에 사용되려면 다른 것으로 이름을 바꿀 필요가 있다고 말하고 싶다.또한 많은 제안들이 잊혀져 왔다.나는 개발자들의 게시판이 존재해야 한다고 말하고 싶다.내가 만들까?그곳이 버질라보다 개발자의 관심을 끌기에 더 좋은 곳이 될 것 같다.또 한 가지 짚고 넘어가고 싶은 것은 다른 프로젝트의 링크 유형에 대해서도 같은 문제가 있기 때문에, 이 문제가 모든 프로젝트에 고정되기 위해서는 이 프로젝트의 관리자들이 다른 프로젝트의 관리자들에게 연락을 해야 할 것이다. -- IRP ☎ 인터뷰 23:31, 2009년 4월 23일 (UTC)[응답]

아니, 온위키 개발 게시판은 그냥 무시될 거야.sysadmin(즉, 위키미디어 서버에 접근할 수 있는 사람)의 주의를 끄는 세 가지 방법이 있다. 긴급성을 높이기 위해 bugzilla(느리지만 체계적)에 버그를 제출하거나, Wikitech-l에 이메일을 보내거나, IRC의 #wikitech(일반 채팅용이라면 어떤 행운을 가져다 주거나, 그러나 전체적으로는)에 로그온한다.es. 개발자(즉, SVN을 가지고 있고 반드시 sysadmin이 아닌 MediaWiki를 업데이트할 수 있는 사람)에게 기술 마을 펌프와 Wikimedia Forum은 각각 지역 및 WMF 범위의 변경에도 좋은 장소다.수석 개발자(sysadmins가 되는 경향이 있는)는 거의 온위키에서 이용할 수 없다.
"인터위키 지도 이름을 바꾸어야 한다"는 말은 그렇게 쉽게 할 수 있는 것처럼 말하는 것이다. 결코 이런 일은 없을 것이라고 자신 있게 장담할 수 있다. 그것은 역호환성 악몽이다.아마도 진정한 '인터위키' 링크만을 보유하기 위해 용도 변경될 수도 있지만, 나는 이런 일이 또한 일어날지 의심스럽다.표에는 현재 '외부'와 '로컬' 링크의 구분이 있다.우리가 해야 할 일은 그 구별을 더 잘 활용하는 것이다.해피멜론 11시 48분, 2009년 4월 24일 (UTC)[응답]
위의 게시물에 대한 나의 답장을 보라. -- IRP ☎ 20:47, 2009년 4월 24일 (UTC)[응답]
Briion, 그리고 때때로 Tim은 WP에서 다음과 같이 읽고 논평한다.VPT, 그러나 메시지를 일주일 이내에 읽으려면 Wikitech-l 또는 IRC가 가장 좋다.브리온에게 직접 이메일을 보낼 수도 있지만, 브리온의 받은 편지함보다 더 많은 사람들이 읽어서 리스트가 일반적으로 더 좋다.Mr.Z-man 21:44, 2009년 4월 25일 (UTC)[응답]
이 제안은 개발자가 이행할 필요가 없다.관리자가 MediaWiki에 코드를 추가하기만 하면 된다.모노북.js. -- IRP 인터뷰 22:40, 2009년 4월 25일 (UTC)[응답]
인터위키 지도에는 위키백과가 아닌 위키백과가 많다.또한 ISBN 1234567890과 RFC 1234와 같은 마법의 링크도 있는데, 이 링크는 브래킷이 전혀 없는 링크로 바뀐다. 하지만 그것은 완전히 '알려진 실'이다.Mr.Z-man 23:27, 2009년 4월 23일 (UTC)[응답]

추가 논의가 필요하므로 이 게시물에 댓글을 달아서 보관하지 않도록 하는 것. -- IRP ☎ 20:15, 2009년 4월 28일 (UTC)[응답]

밑에서.해피멜론 09:14, 2009년 4월 29일 (UTC)[답글]

해피멜론, 위 게시물 중 하나에 대한 나의 답장을 보셨는지 잘 모르겠는데, IRP april 00:10, 2009년 4월 27일 (UTC)[응답]

응, 봤어.해피멜론 13:44, 2009년 4월 27일 (UTC)[응답]
그렇다면 왜 응하지 않았는지 궁금했다. -- IRP인터뷰 20:30, 2009년 4월 27일 (UTC)[응답하라]
"그렇다면 파서 기능이 작동할 때까지 위의 코드를 임시로 빠른 수정으로 사용해야 한다"는 말씀이시죠?내가 보기에 대응할 필요가 있는 것은 아무것도 없는 것 같다.당신이 전적으로 옳다: 우리는 링크 처리를 개선할 수 있을 때까지 그 코드를 수정으로 사용해야 한다.Google:foo와 같은 인터위키 링크가 외부 링크 아이콘('하나의 기능만 다시 쓰도록' 요구됨)을 얻는 기능은 비교적 용이하지만, 위키백과 외부 링크가 지속적으로 연결되지 않는 것이 다소 어려우며, 코어 코드(즉, 그렇게 될 가능성은 낮다)에서 달성될 가능성이 낮다는 점에 유의하십시오.애초에 추가되지 않는 것이 아니라, 더하고 나서 빼앗아야 한다.)해피멜론 09:14, 2009년 4월 29일 (UTC)[응답]

최소화된 글꼴 크기

내가 위키에서 읽으려고 하는 많은 기사들은 괄목할 만한 자료(예: 대체 철자법과 IPA)의 엉킨 것으로 시작한다.서류상으로는 이것이 그렇게 문제가 되지 않을 수도 있지만, 컴퓨터 화면에서는 이 자료를 단순히 읽을 수가 없는데, 특히 이 자료에는 대개 읽기를 방해하는 파란 단어들로 인해 읽기가 불편하기 때문이다.나는 이 자료가 포함되어야 한다는 것을 깨달았고, 종종 처음에 그렇게 하기 위한 "최고의" 장소인 경우가 있다.그러나 그 결과는 내가 -- 그리고 다른 많은 사람들이 -- 적어도 첫 번째 라운드에서 소개를 그냥 건너뛰게 만드는 엉클어진 것이다. 비록 그것이 내가 종종 더 나아가는 전부일지라도 말이다.여기 내 해결책이 있다: 괄호 안에 있는 재료를 작은 타입으로 넣어 눈이 그 위를 바로 건너뛰어 빨리 괄호 끝부분을 찾을 수 있도록 한다.Kdammers (대화) 03:09, 2009년 4월 25일 (UTC)[응답]

다양한 글꼴 크기에 위험이 있다. 정보가 중요할 경우, 사람들은 글꼴 크기가 작을 경우 다른 정보보다 덜 중요하다고 생각하기 시작할 수 있다.종종 괄호는 위키피디아에 있는 다른 기사에 대한 위키링크를 나타내는 역할을 한다. 예를 들어, 이 문장의 타임즈 뉴로맨과 같다.나는 Verdana가 컴퓨터 화면에 사용하기에 꽤 좋은 폰트라고 들었다. 비록 내 추측으로는 Times New Roman이 아마도 가장 인기 있는 폰트가 될 것이다(하지만 나는 거기에 나를 뒷받침할 통계는 없지만).당신은 단지 글꼴 크기의 변화, 또는 실제로 사용된 글꼴의 변화만을 생각하고 있었는가?ACEOREVIVEED (토크) 2009년 4월 26일 (UTC) 19:06[응답]

다른 생각일 뿐이야.당신이 언급하고 있는 것 중 일부는 이미 더 작은 글꼴 크기로 되어 있지 않은가?나는 "Typing x redirections here"와 같은 대사를 생각하고 있다.또는 "미국식 영어 철자법"과 같은 것(노화에 관한 기사 참조).또한, 만약 여러분이 기사를 더 쉽게 접하기 쉽게 만들고 싶다면, 나는 독자들이 자유롭게 건너뛸 수 있는 상자를 페이지 오른쪽에 두는 것이 더 작은 글꼴 크기를 갖는 것보다 더 적합하다고 생각할 것이다.ACEOREVIVEED (토크) 2009년 4월 27일 19:31, (UTC)[응답]

내 컴퓨터 화면에는 [[나이지] 글의 전체 글자 크기가 같다.리디렉션 통지가 있는 "사전 예약" 부분에만 차이가 있다.하지만 전도에 사용된 차이점이 바로 내가 제안했던 것이다.나는 별도의 상자가 가장 사용하기 쉬운 해결책을 만들 것이라는 것에 동의한다.문제는, 내가 생각하기에, 그러한 자료를 일관성 있고 유용한 방법으로 쓰는 것이 많은 경우에 꽤 어려울 수 있다는 것이다.Kdammers (대화) 23:34, 2009년 4월 28일 (UTC)[응답]

'나이듦'이라는 글에서 현재 글자 크기가 작은 '노화에서 리디렉션'이라고 쓰인 글귀가 바로 '노화에서 리디렉션됨'대체적으로 다른 리디렉션된 엔트리가 이런 식으로 나올지 궁금하다.ACEOREVIVEED (토크) 2009년 4월 29일 (UTC) 19:47 [응답]

특수에서 편집하지 않은 차단된 사용자 및 사용자 제외:기본적으로 사용자 나열

편집하지 않고 차단된 사용자는 Special에서 제외할 것을 제안한다.기본적으로 목록 사용자, "차단된 사용자 표시" 및 "편집하지 않은 사용자 표시" 링크. -- IRP ☎ 20:32, 2009년 4월 26일 (UTC), 수정 20:33, 2009년 4월 26일 (UTC)[응답]

왜? 그 사람들이 페이지를 보지 못하게 하려는 거야, 아니면 목록에 올리지 말라는 거야?칠음 20:34, 2009년 4월 26일 (UTC)[응답]
따라서 Special을 통해 검색할 때 반달리즘 사용자 이름을 모두 볼 수 없음:목록 사용자.현재, 우리는 Special:에서 꽤 많은 반달리즘을 본다.우리가 찾고 있는 것을 찾기 전에 리스트 유저들을 찾아라.우리가 찾고 있는 것을 더 쉽게 찾을 수 있도록 반달리즘을 리스트에 걸러내야 한다. -- IRP appy 20:40, 2009년 4월 26일 (UTC)[응답]
우리도 편집하지 않은 유저들을 자주 찾지는 않을 것이다. - IRP인터뷰 20:41, 2009년 4월 26일 (UTC)[응답]
나는 너에 대해 잘 모르지만 스페셜의 목적은 다음과 같아.ListUsers는 차단되었는지 또는 편집되었는지 여부에 관계없이 존재하는 사용자의 전체 목록을 제공하는 것이다.특정 사용자를 찾으려면 검색 상자의 제안 드롭다운을 사용하십시오. 찾는 사용자는 사용자 페이지가 있을 수 있기 때문이다.또한, 당신이 주의해야 할 또 다른 점은 만약 당신이 http://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=Example+user&group=&limit=50 링크를 클릭한다면 그것은 사용자:예제 사용자가 존재함.그러나 해당 계정은 편집이 없고 차단되므로 제안서에 따라 예제 사용자는 해당 목록에 나타나지 않는다.이렇게 하면 주어진 계정이 존재하는지 여부를 결정하는 데 모든 유사한 링크가 무용지물이 될 것이다.트라 (토크) 2009년 4월 26일 21:26 (UTC)[응답]
아, 그래, 그거 좋은 기능이야.칠음 21:23, 2009년 4월 26일 (UTC)[응답]
나는 그러한 기능을 사용할 수 있다는 생각을 지지하지만, 기본적으로 제외하는 것을 지지하지 않는다. 옵션을 선택 해제하지 않았기 때문에 무언가를 찾지 않는 것은 좋지 않은 상황이다.{{Nihiltrestalk log}}{{Nihiltrestalk log}} 21:55, 2009년 4월 26일 (UTC)[응답]
나도 동의해; 목록을 필터링할 수 있는 능력이 있다면 매우 소중하겠지만, 나는 그것들을 숨기는 기본 설정에 대해서는 양면적이다.한편, 그러한 검사에 사용하는 URL을 몇 개의 추가 값(&hideblocked=0&hidenoedits=0또는 유사한 값)을 포함하도록 변경하면 된다.다른 한편으로, 물론, 우리가 그러한 수표에 사용하는 URL을 변경해야 할 것이다. 그리고 몇 개의 추가 값을 포함한다.당신이 적은 양의 작업이 변화를 정당화한다고 생각하는지는 매우 큰 의견의 문제다; 만약 목록의 맨 윗부분이 무작위 반달계정으로 채워지지 않았다면 그것은 분명히 또 다른 'lulz' 요소를 제거할 것이다.해피멜론 22:31, 2009년 4월 26일 (UTC)[응답]
주제에서 벗어난 토의는 올바른 스레드로 이동했다.해피멜론 09:13, 2009년 4월 29일 (UTC)[답글]

MediaWiki: 네임스페이스

미디어위키 페이지의 "메시지" 탭을 "인터페이스 페이지"로 변경할 필요가 있는데, 인터페이스 메시지뿐만 아니라 스킨도 그 네임스페이스에 저장되기 때문이다. -- IRP ☎ 인터뷰 03:45, 2009년 4월 29일 (UTC)[응답]

기계장치와 모든 종류의 다른 것들도 그렇다.나는 이 변화를 지지할 것이다.해피멜론 07:56, 2009년 4월 29일 (UTC)[응답]
나도 그랬어."메시지" 티격태격하는 것은 낡고 허풍스럽지만, 그렇다고 그것을 지킬 이유는 없다.— 가비아 임머 (대화) 2009년 4월 29일 19:24 (UTC)[응답]
미디어위키를 보는 것 같네Nstab-mediawiki; 나는 토크 페이지에 메모를 남길 것이다, 저기, 여기를 가리키며.– 루나 산틴 (토크) 2009년 4월 29일 21:24 (UTC)[응답]
어느 쪽이든 그게 중요한지는 잘 모르겠어.하지만 너희 모두가 무엇을 하기로 결정하든 난 괜찮아. - Rjd0060 (대화) 00:35, 2009년 4월 30일 (UTC)[응답하라]
나는 WP:편집 요약에 있는 링크를 사용하여 과감하게 업데이트했다.흔들림이 없는지 한번 봅시다.해피멜론 09:43, 2009년 4월 30일 (UTC)[응답]

코멘트가 있음

위키백과에서 코멘트가 요청됨:{{Wiki ProjectBanners} 및 {{Wiki ProjectBannerShell} 템플릿에 보이지 않게 변경하여 KingbotK가 해당 페이지를 더 잘 처리할 수 있도록 하는 Bots/ListasBot 5의 승인 요청.맷 (토크) 2009년 4월 30일 17시 45분 (UTC)[응답]

봇 허가가 "최근 사망" 태그를 자동 추가할 수 있을까?

오늘(4월 28일) 밤, 2009_죽음의 범주를 살펴보았다.여기서 가장 최근에 출품된 두 글에는 "이 글은 최근에 죽은 사람에 관한 글"이라고 적힌 태그가 없다는 것을 알아채고 수작업으로 추가했다.그러나 이것(그리고 적어도 어떤 경우에는 수동으로 수행되는 것처럼 보이는 일주일 정도 후에 태그 제거)이 다소 지루할 수 있기 때문에, 최근의 사망 태그의 추가와 삭제를 위해 봇을 고용할 수 있을지 궁금하다.ACEOREVIVEED (토크) 2009년 4월 29일 (UTC) 20:38 [응답]

태그가 항상 필요한 것은 아니다.때때로 정보는 빠르게 변경되지 않으므로 템플리트를 불필요하게 만든다.일주일 정도 지난 후에 그 꼬리표를 떼는 봇이 정말 유용할 것이다.가리온96 (대화) 18:47, 2009년 5월 2일 (UTC)[응답]
아마도 이 요청은 WP로 이동/복사될 수 있다.BOTREQ를 누른 다음 닫으십시오.–MT

등록되지 않은 사용자가 각 아티클의 클래스를 볼 수 있도록 설정

일부 편집자들이 fancruft로 간주하는 것, 예를 들어 비디오 게임과 대중 소설의 등장인물들에 대해 WP에 추가하는 것에 대해 거의 일정한 논의가 있다.대부분의 제안들은 삭제주의자들의 손을 강화하는 경향이 있는데, 나는 그것이 나쁜 것이라고 생각한다. 그것은 이미 언론에서 불리한 인상을 받아 한 출판사가 명백히 주목할 만한 주제인 정치 분기별이라는 새로운 단편 기사의 몇 시간 내에 삭제를 보도한 것이다. 모든 편집자들은 새로운 기사로 시작하고 삭제주의는 사라진다.진짜 자산이 될 수도 있지만 팬 보이들의 무리들을 따라가지 못하는 몇몇 사람들은; 나는 WP가 "위대한 것과 좋은 것"이 가치 있다고 생각되는 주제에 대한 기사만을 포함해야 한다는 권위주의적인 생각을 싫어하고, 그러한 정책이 일부 독자들을 몰아낼 것이라고 생각하는데, 그들 중 일부는 훌륭한 편집자가 될 수도 있다.

그래서 나는 "팬크루프트"와 그 밖의 저품질 기사의 존재에 대해 우리가 각 기사의 등급을 모든 사용자가 볼 수 있도록 하고, 등록은 물론 등록되지 않은 채로, 등급에 대한 간단한 설명으로 연결시켜 줄 것을 제안한다. 즉, 각 등급에 대한 간략한 설명과 이를 달성하는데 필요한 사항을 간결하게 설명하는 한 페이지.WP:N에 실패하거나 텍스트의 많은 비율이 WP:V 또는 WP에 실패한 기사:NPOV는 절대로 스타트 클래스보다 높은 등급을 매겨서는 안 되며, 등급의 요약은 WP가 이러한 기준을 충족하지 못하는 기사는 신뢰할 수 없는 것으로 간주된다는 점을 지적해야 한다.

WP가 "누구나 편집할 수 있는 백과사전"이면서도 품질 기준을 가지고 있다는 것을 세계에 분명히 할 것이기 때문에, 그것은 내게 윈윈처럼 들린다.그것은 심지어 저품질 기사의 생산자들이 그것들을 개선하기 시작하거나 개선의 여지가 더 많은 주제로 넘어가도록 부추길 수도 있다.

PS 일반적으로 삭제주의를 싫어함에도 불구하고, 나는 WP를 위반하는 기사의 신속한 삭제를 지지한다.BLP 및/또는 주로 WP로 구성된다.CopyVio 및 WP:표절, WP를 고소하는 것은 나쁜 일이기 때문이다.-필차 (토크) 14:50, 2009년 4월 30일 (UTC)[응답]

좋아, "팬 크랩"을 정량적으로 정의해줘.당신의 제안에 편향은 전혀 없다. - 데님아데프트 (대화) 16:41, 2009년 4월 30일 (UTC)[응답하라]
요점은 그러한 것들을 정확하게 정의하려는 시도에서 비롯되는 위키리듬과 물리는 것을 피하는 것이다.나는 그 제안이 편파적이라고 생각하지 않는다. 그것은 반복적이고 종종 긴장된 논쟁을 야기시키는 문제에 대한 합의된 해결책을 찾기 위한 시도다.나는 어떤 종류의 주제에 관심이 있는지, 그리고 중립의 이익에 있어서, 당신이 알아내기 위해 기여하는 것을 보지 않았는지 모르겠다.당신의 관심사가 무엇이든 간에, 나의 제안은 당신이 편집한 기사가 WP:N, WP:V, WP를 만난다면:NPOV "더 좋은" 수업 중 하나로 승급할 수 있고 모든 독자에게 그렇게 광고될 수 있다. --Philcha (토크) 17:01, 2009년 4월 30일 (UTC)[응답]
종종 어떤 것이 어떻게 눈에 띄는가를 인용하는 것은 어려운 일이다.또한 픽션 구성요소 목록이 픽션 자체("단일주의")의 관점에서만 검증 가능한 경우가 많다.공상과학소설이나 환상은 이런 경우가 많다.취재해야 할 부분에 한계가 있다는 점은 인정하겠지만, "마일즈 보코시건이 공을 긁는 사례 목록"은 선을 넘을 가능성이 높지만, 문제는 그 한계를 파악하고 방어하는 것이다. - 데님아데프트 (토크) 17:11, 2009년 4월 30일 (UTC)[응답]
"마일즈 보르코시건이 공을 긁는 사례 목록"은 특히 내가 SF 팬이기 때문에 나를 놀라게 했다.만약 당신이 그것을 위한 좋은 제3자 자료를 얻을 수 있다면, 나는 WP가 밝아져야 한다고 생각하므로 도울 수 있을 것이다 - 나는 위키피디아:파스#Gropecont_Lane이 재미있어. --Philcha (대화) 17:42, 2009년 4월 30일 (UTC)[응답]
그게 내 요점이야. 유일한 출처는 원작 그 자체야."In-Universe"를 하지 않고서는 WP:V를 어렵게 만든다.그렇다면, 무엇이 남고 어떻게 되는지를 어떻게 결정할 것인가?그것은 나의 원래 대답으로 거슬러 올라간다.내가 하는 말을 오해한 사람도 있는 것 같다.필차가 아니라 '특정 사람들' - 데님아뎁트(토크) 17:54, 2009년 4월 30일 (UTC)[응답하라]
나는 때문에 그 시도가 많은 단점, 혈압계 떠나"무엇에 머물러 있어 것"에서, 검토, 시간을 낭비하고 종종 적대적인 토론이 많이, 물리는 것은 잘 모르는 시간의 더 잘 및 편집한 시간이 될 것이다 많은 낭비하며 잠재적 좋은 편집자들을 잃는 것일 수도 있다. 쓸데 없는 일이다, 왜냐하면 fan-boys fancr을 만들 수 있고 있습니다.uft경험 많은 편집자들이 그것을 제거할 수 있는 속도보다 더 빠르다.내가 제안하는 것은, 우리가 팬 보이들을 쫓는 대신에, 우리가 그들을 쫓아오도록 강요해야 한다는 것이다 - 더 좋은 성적의 당근이 그들이 기여도를 향상시키도록 동기를 부여하지 않는다면, 단지 C-클래스 아래 기사의 맨 위에 표시되는 텍스트/배너를 변화시킴으로써 그들의 사기 위에 "건강 경고"를 붙이는 것은 선택사항이다.
그 마지막 점은 다른 것을 암시한다.많은 위키백과 주체는 검토/평가 요청에 응답하지 않는다.중앙 평가 센터가 있는지 모르겠고, 없으면 내가 만들어서 운영할 수 있도록 도와줄게.나는 현재 GA 지위에 대한 기사를 검토하지만, 필요하다면 덜 좋은 기사와 그들의 편집자들의 개선을 돕기 위해 그 기사를 줄일 수 있을 것이다 - 나는 그것이 너무 오래지 않아 WP에게 더 많은 GA, 그들이 무엇을 하고 있는지 아는 편집자, 그리고 WP가 모든 수준에서 부족한 리뷰어를 제공하기를 바란다. --Philcha (대화) 18:37, 2009년 4월 30일 (UTC)[응답]
좋아, 난 그것에 대해 전혀 논쟁할 수 없어.나는 무엇이 좋은 기사를 구성하는지에 대해 확정적이라고 주장하지 않기 때문에 일반적으로 스스로 기사를 검토하지 않는다.OTOH, Harvard Bridge와 현재 작업 중인 User:데님아데프트/하버드 다리, 나는 그 미해결 노력을 검토한 사람들로부터 힌트를 얻었다고 들었다.하지만 나는 종종 어떤 사람들이 "팬 크랩"이라고 부르는 것을 옹호하는 나 자신을 발견하곤 한다.최근에 나는 아너 해링턴 책들을 바탕으로 어떤 책들은 선을 넘은 것 같았기 때문에 실제로 방어할 수 없었지만, 다른 책들은 사우스 파크 지역에 있는 내 다리 기사들과 기사들과 같은 치아를 위해 싸운 적이 있다.내가 보기에 당신은 AFD에서 검토자 토론으로 토론을 효과적으로 옮기고 있는 것 같다.그런 의도인가? - 데님아데프트(토크) 19:02, 2009년 4월 30일 (UTC)[응답하라]
나는 그 제안이 "AfD에서 검토자 토론으로 토론의 방향을 바꾸는 것"에 대한 것인지는 잘 모르겠다.
  • 지명자의 요청에 따라 리뷰가 진행되는 반면, AfD에 대한 기사의 추천은 그 창작자(특히 워치리스트 등에 대해 잘 모르는 신인 등)가 눈치채지 못하는 경우도 있다.
  • 검토에서 입증책임은 일반적으로 지명자들에게 있다.AfD의 이론상, WP에 따르면, 그 부담은 "삭제" 유권자들에게 있다.DELETE의 "삭감은 최후의 수단이 되어야 한다"는 말은 하지만, 나는 그것이 그렇게 작동하는 것을 거의 본 적이 없다.만약 명목상의 사람들이 재정비하지 않는다면, 그들은 상당한 수의 불평을 야기하는 AFD와 달리 그들 자신 외에는 아무도 비난 받지 않는다.
  • AFD는 순수하게 홍보적이거나 당파적인 기사 또는 그들이 WP를 준수하는지에 대한 의심이 있는지에 대한 논의가 필요한 기사를 제거하는 데 여전히 중요한 역할을 할 것이다.BLP 또는 WP:표절. --Philcha (대화) 2009년 4월 30일 (UTC) 20:03, [응답]
그것은 나에게 훌륭한 포용주의적 방법이라는 인상을 준다.네, 그렇게 하겠습니다만 - 데님아뎁 (토크) 20:10, 2009년 4월 30일 (UTC)[응답]
User:의 infobox와 텍스트에서 매끄럽게 연결되는 링크가 마음에 든다.데님아데프트/하버드 다리.그것이 WP가 밝아지도록 도와준 좋은 사례고, 이번 토론에서 두 번째 웃음은 당신이 내게 준 것이다.고마워! --Philcha (대화) 2009년 4월 30일 (UTC) 20:29 [응답]
천만에요.나는 더 많은 출처를 찾으면서 그 기사에 대한 비평도 좀 하고 있다. - 데님아데프트 (토크) 20:32, 2009년 4월 30일 (UTC)[응답]

최소한 어느 정도까지 포함요건을 없애고 모든 것을 채점 기준으로 삼으라는 말씀이세요?실행 가능한 발상은 아니라고 생각하지만 앞으로 나아가려면 하위권 기사들이 구글에 의해 색인화되지 않는 등 장애인 특권을 갖는 것이 중요할 것이다.원칙적으로는 그것은 일종의 깔끔한 생각이지만, 그렇다면 일반적인 그루브와 스타트 또한 고통을 겪지 않을까?◆ 조니미르닌자 19:35, 2009년 4월 30일 (UTC)[응답]

나는 그 제안이 사람들이 AfD 토론에서 많은 시간을 보내지만 그것이 공황상태의 흐름을 막지 못하는 현재의 시스템보다 덜 실행 가능하다고 생각하지 않는다.나는 우리가 방어할 수 있는 위치로 후퇴해야 한다고 제안하는 것 같다.
"정상적인" 스텁이나 스타트란 무엇인가?
예를 들어, "이것은 ...때문에 형편없는 기사다"와 같은 정말 두드러진 건강 경고와 함께 "가난한 기사" 등급을 도입하는 것은 좋은 생각일 것이다.우리는 그것의 내용이 믿을만하다고 확신하지 않는다.더 높은 점수를 받기 위한 검토 방법을 포함한 짧고 간단한 제안 집합에 대한 링크가 있는 "개선할 수 있도록 도와주십시오."그래서 기사는 처음에는 "무의견"이 될 것이고, 어떤 실제 리뷰를 하기에는 너무 짧으면 "스텁"으로 갈 수도 있고, 만약 괜찮다면 그것은 시작 단계일 수도 있고, 엉터리라면 "불량"으로 될 수도 있다.
서치들의 하급 기사들의 색인을 삭제하는 것이 좋을지 모르겠다.기사를 찾아내고, 기사의 결함을 발견하고 편집하는 것으로 WP에 들어갔다.많은 Talk 페이지에서 나의 인상은 많은 편집자들이 그렇게 시작한다는 것이다.디인덱싱은 기사의 개선과 관심 있는 새로운 편집자를 모집하기 위해 기회를 버리는 것이다. --필차 (토크) 20:18, 2009년 4월 30일 (UTC)[응답]
우리가 그것들을 삭제하지 않으면, 그들은 또 하나의 거대한 밀린 일이 될 것이다.삭제는 조류를 억제하는 것이 아니라 최소한 조류를 다루는 것일 수도 있고, 가난한 기사들을 분류하는 데 노력을 쏟는 대신 사람들이 절약할 수 있는 기사들을 구할 수 있도록 하는 일종의 트라이어티 역할을 하는 것이다.마감일을 지키지 않은 것에 대해 전적으로 찬성하지만, 이것은 뒤로 넘어지기 보다는 백기를 흔드는 것 같다.이전에 삭제했던 사람들이 또한 "가난한 기사"를 다시 쓰기 시작할 것이기 때문에 이전에 삭제된 페이지 클래스를 만들 수 있도록 허용하면 그러한 종류의 페이지들이 만들어지는 수가 증가할 것이다.2009년 4월 30일 Mr.Z-man 21:07 (UTC)[응답]
"또 하나의 거대한 밀린 업무"로, 대부분의 등록된 사용자들은 나를 포함한 유지보수 업무를 하기 보다는 편집하기 때문에 우리는 항상 밀린 업무들을 하게 될 것이다.
삭제로 인해 누군가가 나쁜 기사를 쓰는 것을 방해한다는 증거는 무엇인가?나는 기사를 검토하고 "가난하다"고 채점하는 것이 AfD보다 노동집약성이 훨씬 덜할 것으로 예상한다. 그래서 만족스럽지 못한 기사들의 밀린 작업으로 더 많은 진전을 이룰 수 있을 것이다.그러면 AFD는 정말 심각한 사건에 집중할 수 있다. --Philcha (토크) 21:30, 2009년 4월 30일 (UTC)[응답]
코네티컷 강 다리에 대한 기사를 쓰는 것을 단념했다.그 글들이 좋아질지 어떨지는 알 수 없다. - 데님아뎁 (토크) 21:34, 2009년 4월 30일 (UTC)[응답]
우리는 항상 밀린 일이 있을 텐데, 한 번 더 만들까?나는 내가 그 논리에 동의하는지 잘 모르겠다.내 요점은 기본적으로 기고자의 수가 한정되어 있기 때문에, 한 번에 일정량의 전체 밀린 일을 통해서만 일을 할 수 있다는 것이다.작업하는 편집자의 수를 두 배로 늘리지 않고 백로그의 크기를 두 배로 늘리면, 사람들이 새로운 백로그로 이동할 때 더 중요한 백로그(예: 비소싱 BLP, 현재 약 3만 명)를 포함하여 전체 백로그가 삭제되는 비율을 줄인다.분명히 이것은 단순화되었지만, 나는 삭제를 백로그로 대체하는 것이 어떻게 어떤 것을 해결하는지 모르겠다.최악의 경우, 그것은 잘 감시되지 않는 페이지의 밀린 작업량을 증가시켜 RC 순찰에도 더 많은 부담을 줄 것이고, 또 다른 Seigentaler 사건을 야기시킬 가능성이 있다. (이것이 현재 우리가 공신력 지침을 가지고 있는 이유 중 하나라고 나는 믿는다.)그것은 꼭 "가난한 기사"에 있을 필요는 없을 것이다. 그것들은 단지 RC패트롤러들의 주의를 다른 곳으로 옮겨야만 할 것이다.
삭제 로그와 새로운 페이지에 대한 통계적 분석을 하는 것 외에는 어떻게 어느 한쪽을 뒷받침할 증거를 모을 수 있을지 모르겠다.고전적 조건화 이론은 삭제하는 것이 억제력을 제공한다는 것을 암시할 것이다.만약 당신의 기사가 계속 삭제된다면, 당신은 당신이 쓰는 것에 대해 바꿀지도 모른다.현재 상태로는 GA 이하의 어떤 등급도 본질적으로 무의미하고 자의적인 것으로서, 대개는 초서적인 기계적인 검토만을 거쳐 배정된다(가능한 한 빨리 기사를 평가하도록 장려되는 큰 프로젝트에 대해서는 "평가 추진"을 더 나쁘게 하고, 그 다음에는 이러한 평가들이 작은 프로젝트에 대해서는 봇에 의해 베끼게 된다). 그래서 나는 "나쁜"를 얻는 것이 의심스럽다.기사" 등급은 삭제만큼이나 부정적인 피드백을 제공할 것이다.하루에 100~150회의 AFD밖에 없는데, 12명 이상의 Relists를 포함해서, 그렇게 형편없이 할 수는 없다.Mr.Z-man 22:02, 2009년 4월 30일 (UTC)[응답]
나는 그러한 것들을 감지하고 수업 시간에 따라 제목을 기억하고 "무료 백과사전인 위키백과에서 온 좋은 기사"와 같은 것으로 모토를 바꿀 수 있는 그 확장을 가능하게 했다.전 특집 기사 후보."비록 캐주얼한 사용자들이 그것이 실패한 FC인지 아닌지 알 필요는 없다고 생각하지만, 우리는 이것을 할 수 있는 기능을 가지고 있다.ViperSnake151 Talk 00:10, 2009년 5월 3일 (UTC)[응답]

링크에 대한 간단한 정의/참고

링크 위에 마우스를 올려 놓으면 용어에 대한 간략한 정의를 얻을 수 있도록 대화 상자에 간단한 정의를 추가하는 것이 어떨까?그렇게 하면 내가 현재 보고 있는 페이지를 클릭하거나 탐색할 필요가 없기 때문에 시간이 절약될 것이다.

나는 너희들이 동의하기를 바란다.

이것은 존재한다.등록된 사용자 계정으로 로그인한 후 Special: "Gadgets" 섹션으로 이동하십시오.기본 설정에서 "내비게이션 팝업"으로 표시된 상자에 체크 표시를 하고 저장을 누르십시오.:) {{Nihiltres talk log}}{18:20, 2009년 5월 1일 (UTC)[응답]
해결됨
– 이미 prefs>prefs>properties>pops에서 구현됨. –MT

인트로 서브섹션을 만들 수 있을까?

누군가 기사의 소개문을 편집할 때마다 맨 위 줄에 있는 "이 페이지 편집"을 클릭해야 한다.때로는 복수의 편집자가 기사의 다른 자료를 위해 동시에 기사를 편집하기도 한다.그래서 그들의 편집은 상충될 수 있고, 때로는 오해에 근거한 편집 전쟁이 일어날 수 있다.A나 B급 기사의 전체 크기는 매우 크기 때문에 편집자들이 조금만 바꾸고 미리 보기만 한다면 로딩은 매우 오래 걸린다.그러니 다른 하위세션들처럼 도입부를 위한 작은 하위섹션을 만드는 것이 어떨까 [편집] 아무 생각 없이? --카스피해 블루 17:25, 2009년 4월 29일 (UTC)[응답]

Preferences → Gadgets → Y 페이지 리드 섹션에 대한 [편집] 링크 추가–xenotalk 17:43, 2009년 4월 29일 (UTC)[응답]
아!!!!!!!!고마워!당신은 정말로 위키그놈들 중 한 명이다("위키그노메 반스타"가 있는가?) .---카스피해 블루 17:49, 2009년 4월 29일 (UTC)[응답하라]
또는 기사 URL을 가져다가 "?action=edit&section=0"을 붙이면 되는데, 기본적으로 이 기기는 괜찮은 작은 버튼만 있으면 된다. --Izno (토크) 19:36, 2009년 4월 29일 (UTC)[응답]
응, 가젯 전에 방금 첫 번째 섹션의 편집 링크를 클릭하고 수동으로 섹션을 1에서 0으로 바꿨어. EVULA//토크 // ☯ // 22:29, 2009년 5월 2일(UTC)[응답]
가젯을 추가했는데 어떻게 해야 할지 모르겠어. Spilbrick (talk) 18:19, 2009년 5월 4일 (UTC)[응답하라.
해결됨
– 해결 방법: 이미 구현됨, prefs>gadgets 참조>리드에 편집 링크 추가 –MT

위키백과 홍보 캠페인

나는 위키피디아를 신뢰할 수 있는 출처로 사용하는 것을 촉진하기 위한 위키피디아 전역의 캠페인을 제안한다.많은 교사들과 지지자들은 위키피디아가 사용자에 의해 편집된다는 사실만을 근거로 위키피디아를 에세이나 다른 논문의 참고자료로 사용하는 것을 배제한다.그러나, 이것은 정보의 원천으로서 그것의 신뢰성을 감소시키지 않는다.종종, 위키피디아는 다른 많은 장소들이 위키피디아에 제공된 정보의 일부와 일부만을 가지고 있기 때문에 정보의 가장 좋은 원천이다.나는 사람들에게 우리가 얼마나 신뢰할 수 있고 왜 그런지 보여주는 캠페인을 제안한다.우리가 사용자 편집을 하는 동안 다른 사용자가 잘못된 정보를 제거하는 것은 매우 간단한 문제이며, 관리자가 규칙을 준수하지 못할 경우 사용자가 편집을 금지할 수 있다는 점을 사람들에게 지적하십시오.드류 스미스 (토크) 02:30, 2009년 5월 1일 (UTC)[응답]

우리는 보통 좋은 공급원이지만 믿을 만한 공급원이 아니다.위키피디아를 그렇게 홍보하고 싶다면, 이 블로그 게시물에 설명된 것과 같은 일을 하는 것을 추천한다.{{Nihiltrestalk log}}04:01, 2009년 5월 1일 (UTC)[응답]
위키피디아처럼 변덕스러운 사이트는 그 내용이 결코 구체적인 상태에 있지 않기 때문에 결코 신뢰할 수 있는 출처가 될 수 없다.풀 프로트도 관리자가 우회할 수 있다. -제레미 04:12, 2009년 5월 1일 (UTC)[응답]
나는 백과사전이 일반적으로 연구를 위한 좋은(또는 '적절한') 원천으로 여겨지지 않는다는 인상을 받았다.♫ 멜로디아 샤콘네 ♫ (대화) 11:17, 2009년 5월 1일 (UTC)[응답]
그것들은 연구의 좋은 출발점이다.반면 위키피디아를 인용하는 것은, 논문의 주제가 위키피디아나 인터넷 사용 패턴이나 이와 비슷한 것이 아니라면, 나쁜 학문이다.--존 브레본(usc) 00:24, 2009년 5월 3일 (UTC)[응답]
물론 아니다.위키피디아는 매우 의심스러운 출처다.(나는 우연히 내 기사가 예외에 속한다고 생각하지만, 그러면 편파적이 된다.)자, 위키백과 등에 대한 회의론을 높이기 위한 캠페인이 있었다면, 나는 그것을 지지할지도 모른다. -- 후아리 (토크) 11:03, 2009년 5월 3일 (UTC)[응답]
해결됨
- 의견 일치는: 필요 없음, 위키피디아는 이런 방식으로 신뢰할 수 있도록 의도되지 않았다. –MT

참조에 대한 대화 하위 페이지

우선, 이것은 제안이라기보다는 자발적인 발상에 가깝다.얼마 전에 외부 링크 정리에 대한 작업을 해 봤는데 곧 WP별로 제거했던 대부분의 링크는 다음과 같다는 것을 알게 되었다.EL은 유효한 외부 연계는 아니지만 해당 기사에 유효한 출처가 될 수 있었던 인터뷰나 신문 보도였다.나는 이러한 모든 기사들을 개선하기 위해 이러한 링크를 사용할 시간이 없었으며(그리고, 종종, 나는 전문지식이 없었다) 그래서 나는 소스로서 가능한 그들의 사용에 대한 편집 요약에 메모가 있는 외부 링크를 제거했다.기사에 대한 출처를 찾기 위해 기사의 역사를 들여다볼 사람이 없을 것 같아, 토..만약 어떤 기사가 잠재적인 참조를 나열하는 하위 페이지를 가질 수 있다면 어떨까?따라서, 블루 (래퍼) (대개 무작위 예제)는 Talk:Blu (래퍼)/Reference를 가질 수 있으며, WP별 편집에서 방금 제거한 링크를 포함할 수 있다.EL. 대화 페이지의 템플릿은 편집자에게 사용되거나 분류되기를 기다리고 있는 참조가 있음을 통지할 수 있으며, 사용자가 찾을 경우(그리고 기사에 추가할 시간이 없음) 하위 페이지에 참조를 추가할 수 있다.너희들은 어떻게 생각하니? --콘티 ✉ 22:24, 2009년 4월 28일 (UTC)[응답하라]

기존의 두 가지 접근방식이 이를 다루는 것처럼 보일 수 있다(WP:편집 정책 참조). 링크가 많이 없는 한, 그냥 메모로 해당 링크를 토크 페이지에 올려 놓기만 하면 된다.부하가 있는 경우 사용자 공간의 하위 페이지에 배치하고 대화에서 링크를 클릭하십시오.Rd232talk 05:16, 2009년 4월 29일 (UTC)[응답]
rd232가 말하는 것처럼 토크 페이지의 새로운 섹션에 그들을 올려 놓았을 것이다.해피멜론 07:54, 2009년 4월 29일 (UTC)[응답]
나도 그렇게 할까 생각했지만, 토크 페이지 섹션은 결국 보관되고 (그리고 잊혀져서) 편집 요약의 메시지처럼 눈에 띄지 않게 된다.사용하지 않는 참조를 위한 중앙의 장소를 갖는 것(하위 페이지일 필요는 없음)은 이러한 참조를 훨씬 쉽게 찾을 수 있게 할 것이다. --Conti ✉ 11:04, 2009년 4월 29일 (UTC)[응답]
대화 하위 페이지로 작업관리 목록에 추가하십시오. ---— Gadget850 (Ed) 17:48, 2009년 4월 29일 (UTC)[응답]
토크 페이지 섹션은 결국 보관된다(그리고 잊혀진다) - 사실 그것은 상대적으로 바쁜 토크 페이지들, 즉 소수민족에게만 해당된다.아카이브가 있는 대화 페이지에서도 아카이빙을 수동으로 수행하는 경우가 대부분이었습니다.즉, 아카이빙을 수행하는 편집자가 훌륭하지만 사용되지 않는 출처가 있는 섹션을 혼자 남겨둘 수 있으며(그리고 그래야 한다고 생각한다).그러니까, 삭제해도 좋지만 아직 기사에서 출처로는 사용되지 않는 좋은 EL을 기사의 토크/토론 페이지의 새로운 섹션에 넣어주십시오. -- John Brown (리콜링) 15:22, 2009년 5월 3일 (UTC)[응답]
알았어, 나중에 할게.여하튼 내가 여기서 너무 비관적이었던 것 같아. :) --Conti 11 11:58, 2009년 5월 6일 (UTC)[응답]
해결됨
– 해결책: 좋은 출처인 부적절한 외부 링크는 보통 대화 페이지로 이동할 수 있으며, 보관 및 잊혀질 염려가 없다. –MT

날짜 가능성이 있는 용어 추적

기본 페이지:위키백과:및 위키백과:정보 업데이트 중

{{as of}}}의 템플릿은 시간에 민감한 클레임을 일시적으로 스탬핑하여 업데이트가 필요할 때 다시 검토할 수 있도록 독자에게 보이지 않게 작동한다.그렇게

{{2007년 6월 현재}}} [[Juan Carlos]]는 [[스페인 왕]]이다.

로 나타나다.

2007년 6월 현재 후안 카를로스는 스페인의 왕이다.

기사가 카테고리(Category에 추가됨:2007년 6월부터의 잠재적으로 날짜가 기재된 조항.{{Update after}}}에는 이와 관련된 목적이 있다.나의 제안은 "현재"와 "최근"과 같은 용어들을 유사한 방식으로 취급하는 것이다: {{현재}}(현재 취합)와 {{recently}}} 템플릿이 존재하며, 독자는 "현재"와 "최근"이라는 평문 용어를 출력하지만, 편집자는 템플릿 중 하나를 포함하는 기사를 카테고리에 추가한다.잠재적으로 날짜가 기재된 모든 문서.예를 들어, 그 선은

[[Al Franken]]은(는) {{현재 2009년 5월}에 [[미국 상원의원]에 앉기 위해 대기하고 있다.

읽었을 것이다

알 프랑켄은 현재 미국 상원의원 자리를 기다리고 있다.

라인이 표시된 기사는 카테고리로 분류된다.2009년 5월 이후의 잠재적으로 날짜가 기재된 기사

편집자들은 이것이 좋은 생각이라고 생각하는가?모든 의견, 제안 또는 아이디어에 감사스코모록 17:32, 2009년 5월 4일 (UTC)[응답]

흥미롭군약간 마음에 들어. --골베즈 (토크) 18:36, 2009년 5월 4일 (UTC)[응답]
아마 {{to inner=<content>}}}}. --Izno (토크) 18:47, 2009년 5월 4일 (UTC)[답답답]에 찬성하여 {{현재}}}}을(를) 탈피할 수 있을 것이다.
나는 "현재"로 좋아한다.나는 "X"라는 어떤 종류의 진술에 의해 명확하지 않는 한 거의 항상 쓸데없이 모호하기 때문에 "최근"의 사용은 금지되어야 한다고 생각한다. 그리고 그 때조차도, 특별히 명확하지 않다(최근 몇 주? 일주일? 한 달?).500년?)Mr.Z-man 18:58, 2009년 5월 4일 (UTC)[응답]
현재도 똑같이 낙담해서는 안 되며, 그 성명은 "{{{{2009년 5월 현재}}}}] [[Al Franken]]이 [미국 상원의원]에 앉기 위해 대기 중"으로 다시 작성된다.템플리트화된 "현재"는 편집자들에게 그러한 진술들을 최신 상태로 유지할 수 있는 더 쉬운 수단을 제공하기 때문에 확실히 평범한 것보다 낫다. 하지만 독자들은 그러한 진술이 얼마나 시대에 뒤떨어진 것인지 알지 못할 것이다.그는 데이트가 더 좋다.아말테아 21:36, 2009년 5월 4일 (UTC)[응답]
생각해 봤는데, "현재 버락 오바마는 미국의 대통령"이 "2009년 현재, 버락 오바마는 미국의 대통령"보다 낫다고 들리는데, 어떤 재앙적인 사건을 막으면, 그는 4-8년 동안 대통령직을 수행하게 되는데, 이것은 위키피디아 시대에는 영원하다.아주 단기적인 일에는 특정한 날짜를 사용해야 하지만 장기간의 일에는 어색해 보인다.Mr.Z-man 21:50, 2009년 5월 4일 (UTC)[응답]
"현재 버락 오바마는 대통령이다" 또는 "현재‡ 대통령이다" 또는 "현재[nb 1] 대통령이다" 또한 모두 효과가 있을 수 있다.우리는 또한 그 단어를 실제 날짜와 연관시킬 수도 있다.현재 사용처인 '현재'를 수정하자는 제안이니 문제없다고 본다.누군가가 가서 템플릿을 만들어야 한다.–MT 04:54, 2009년 5월 5일 (UTC)[응답]
나는 그 옵션이 나무로 숲을 가린다고 생각한다; 과도한 태그는 텍스트를 읽기 어렵게 만든다.EVULA// talk // ☯ // 05:57, 2009년 5월 5일 (UTC)[응답]
일단 컨벤션이면 대충 훑어보기가 아주 쉬울 것이다.요점은 많은 선택지가 있다는 것이다.나는 수년 전에 파란색 링크를 알아차리지 못했던 것처럼 노트 마커도 더 이상 눈에 띄지 않는다.노트에 대한 링크로 만드세요.색상을 조금 벗겨라.아니면 굳이 표시도 하지 마라.–MT 08:29, 2009년 5월 5일 (UTC)[응답]
장기적인 안목으로 볼 때, 나는 그것이 필요하지 않다고 생각한다.기사들이 기한이 4년이나 지난 것에 대해 정말 그렇게 걱정할 필요가 있을까?Mr.Z-man 15:29, 2009년 5월 5일 (UTC)[응답]

일반적으로 이러한 용어를 사용하는 것에 대한 비호감에는 공감하지만, 나는 이 용어를 이미 사용하고 있는 곳에 이것을 구현하는 것에 대한 공감대를 감지하고 있다.템플릿을 만들고 사용해 보는 데 반대는 없으십니까?{현재}}의 모든 용도를 기술적으로 움직이고 조정할 수 있는 사람이 필요하겠소요.스코모록 15:34, 2009년 5월 5일 (UTC)[응답하라]

내가 보기에 이상적인 것은 다음과 같이 자동으로 생성되는 숨겨진 카테고리와 함께 알려진 종료점이 있는 상황의 경우 {{current=2013-01-20}과 같은 것으로 보인다.2013-01-20에 대한 업데이트가 필요한 기사.그리고 그렇지 않다면, 정확히 왜 "현재"라는 단어가 유용한가?"버핏은 버크셔 해서웨이의 CEO" "프랑켄은 미국 상원에 앉힐지 여부를 결정하기 위해 법적 절차의 결과를 기다리고 있다"고 말했다.
만약 우리가 정말로 "current"를 사용하기를 원하며, 누군가가 변경사항을 눈치채지 못할 것을 걱정한다면, 아마도 {{current=2009-10}, 자동으로 생성되는 보이지 않는 카테고리:2009년 10월에 업데이트가 필요할 수 있는 기사들. (재점검은 앞으로 1년 이상 예정되어서는 안 된다고 주장한다.) -- John Brown (리콜링) 19:13, 2009년 5월 6일 (UTC)[응답]
이미 유통기한이 알려진 클레임에 대해 {{Update 이후}}을(를) 보유하고 있다.나는 그 주장이 만들어진 시점부터의 데이트 관행은 나중에 변경될 필요가 있을 수 있는 특정 기간으로 확약하지 않기 때문에 앞으로 임의의 기간으로부터 데이트하는 것보다 더 이치에 맞는다고 생각한다.그리고 다시 반복하기 위해, 이 제안은 이러한 유형의 용어들이 언제 사용되어야 하는지에 대해서는 어떤 편도 들지 않으며, 단지 그것들이 있을 때 어떻게 다루어져야 하는지에 대해서만 다룬다.이것이 도움이 되길 바라며, 스코모록은 2009년 5월 6일 (UTC)[응답]

리디렉션할 리디렉션 있음

안녕, 현재 리디렉션 페이지가 다른 페이지로 리디렉션된 경우 두 번째 리디렉션 경로를 따르지 않는 경우.

이것이 문제가 될 수 있는 이유 1. 기존에 있던 페이지를 리디렉션 페이지로 변경했다.해당 페이지로 리디렉션된 모든 페이지는 이제 해당 페이지에 고착될 것이다(글쎄, 사용자는 링크를 클릭하면 해당 페이지가 올바른 페이지로 이동하지만, 나는 이것이 최선의 해결책이라고 생각하지 않는다).2. 두 번째 리디렉션 페이지가 독립적일 경우에 대비하여 누군가 리디렉션 페이지로 리디렉션하기를 원할 수 있다.예를 들어, 나는 "galley proofs"로 리디렉션되는 리디렉션 페이지 "page proofs"를 만들었다.나는 또한 다른 리디렉션 페이지 "page proof"를 만들었는데, "page proofs"가 "galley proof"와 같지 않기 때문에 "page proofs"로 리디렉션하고 싶었다.나는 이 예가 매우 가능성이 없는 시나리오(즉, 나는 페이지 증명 페이지 작성은 무시하지 않는다)를 제공한다고 생각하지만, 이 문제가 발생할 수 있는 몇 가지 사례가 있다고 생각한다.PGScooter (대화) 13:09, 2009년 5월 6일 (UTC)[응답]

이것은 최근에 여기서 논의되었다: 위키백과:마을 펌프(제안)/아카이브 44#이중 리디렉션기술적으로 가능한 일이고 그 논의를 아주 잠깐 들여다보면 이중(그리고 어쩌면 삼중++)의 리디렉션을 허용하기로 합의가 되어 있다는 것을 알 수 있다.–xenotalk 13:13, 2009년 5월 6일 (UTC)[응답]
제노, 참고해줘서 고마워!많은 지원을 받고 있는 것 같은데, 아직도 이 기능을 구현하지 못하고 있다.아마도 그들은 그것에 대해 연구하고 있을 것이다.PGScooter (대화) 13:46, 2009년 5월 6일 (UTC)[응답]
아니면 아직 아무도 버질라를 신고하지 않았거나...=) –xenotalk 13:59, 2009년 5월 6일 (UTC)[응답]
bugzilla:17888은 꽤 오래 전에 제출되었다.대수학자 18:36, 2009년 5월 7일 (UTC)[응답]

wikipedia.org 페이지의 이름

안녕, 제안 하나만 들어봐. 로그인/검색 중인 국가의 wiki를 이 페이지에 표시할 수 있어.사용자들에게 덜 자주 사용되는 위키도 체크아웃하고 편집하도록 권장한다.이 실을 읽고 이렇게 물어본다. 고맙다.BigDuncTalk 16:40, 2009년 5월 6일 (UTC)[응답]

기술적으로는 가능하지만 반드시 도움이 되는 것은 아니다(일부에서는 해당 페이지로 가지 않고 여러 나라에서는 여러 언어를 사용하지만 한 가지 선호만 가질 수 있기 때문이다).하지만 여기서가 아니라 메타에서 논의되어야 할 문제라고 생각한다.Rmhermen (talk) 2009년 5월 6일 (UTC) 16:49 [응답]
답장 고마워 메타에 게시할 수 있는 장소가 링크를 줄 수 있겠니?BigDuncTalk 20:56, 2009년 5월 6일 (UTC)[응답]
그 페이지의 텍스트는 m:Www.wikipedia.org 템플릿은 내가 거기서 토크를 시작하고 m:에 메모를 남길 것이다.다른 페이지를 더 자세히 보기 위한 위키미디어 포럼. - Rjd0060 (대화) 02:47, 2009년 5월 7일 (UTC)[응답]
답장 고마워.BigDuncTalk 08:10, 2009년 5월 7일 (UTC)[응답]
해결됨
– (생각해) 메타로 리디렉션된 원산지를 포함하도록 글로벌 위키 홈페이지 편집 요청 –MT

위키백과의 로컬 버전

위키피디아의 오프라인 버전(DVD/Blu-Ray)의 창조에 대해 생각해보십시오.아직 인터넷 연결이 충분하지 않은 지역에서는 매우 유용할 것이다.

비용이 많이 들고 때로는 쓸모없는 결정이라는 것은 이해하지만, 포함된 자료가 까다로운 청각과 과목에 맞게 준비된다면 교육목적으로 널리 사용될 수 있다.내 말은 그것은 자연과학에 대한 일반 정보가 수록된 DVD일 수도 있고, 역사나 수학 같은 구체적인 주제에 관한 DVD일 수도 있다는 거야.

위키피디아는 이미 좋은 정보 기반을 가지고 있다.다양한 사용자들을 위해 좋은 인터랙티브 흥미로운 백과사전을 편집하기 위한 기본적인 검증과 선택이 필요했다.또한 그것은 온라인 프로젝트에 대한 좋은 지원이 될 수 있다.

단지 오프라인 미디어를 위한 정보를 선택하고 검증하며 개선하는 부서를 만드는 것이 필요했다.

--NoRad (대화) 14:30, 2009년 5월 7일 (UTC)[응답]

위키백과 참조:버전 1.0 편집팀.–xeno 14:32, 2009년 5월 7일 (UTC)[응답]
해결됨
– 이미 구현됨. –MT

위키백과에 오신 것을 환영합니다(미국)

위키피디아를 국제적인 대표성을 더 많이 만드는 것을 위해서 미국과 관련된 'Welcome to Wikipedia'에 대한 기사나 논평이 없는 날을 갖는 것은 어떨까.

나는 매일 환영 페이지를 읽으며, 다음 환영 섹션 중 하나 이상 아래에 항상 적어도 하나 이상의 미국 참조 자료들이 있다.
오늘의 특집 기사
뉴스에서
혹시 아십니까...
이 날에...

세계에는 200개 이상의 국가가 있으며, 그 중 (위키피디아에 따르면) 53개국이 영어를 공용어로 사용하고 있다.나는 항상 미국에서 이야기를 찾는 것에 싫증이 난다.적어도 시작 페이지의 미국 콘텐츠를 줄이도록 시도하십시오.미국에 대한 반감은 없지만, 웰컴페이지에 미국에 대한 언급이 없는 날을 기대해본다. B. 페어바인 (대화) 2009년 4월 26일 (UTC) 23:11 [응답]

편견을 없애기 위해 특정 국가에 대한 언급을 모두 생략하시겠습니까?그게 편파적이지 않아?왜 그걸 꺼내지도 않는 거야?또한, 위키백과에 온 것을 환영해!미국에 대한 강조가 너무 많은가에 대한 논쟁이 끊이지 않기 때문에 당신은 여기서 처음이거나 메인 페이지에 대한 논의에 참여한 적이 없을 것이다.공교롭게도, 지금, 주요 기사는 미국과 베트남에 관한 것이다; ITN은 미국을 언급하는 제로 스토리를 가지고 있다; DYK에 대한 8개의 출품작 중 3개는 미국을 포함하거나 언급하고 있다; 그리고 6개의 On This Day 출품작 중 1개는 미국을 포함한다.그렇다면, 당신의 불평은 정확히 무엇인가?그렇다, 세계에는 200개 이상의 나라가 있다 - 그리고 현재 메인 페이지에는 적어도 18개국이 있다.그러니까, 분명히 당신의 문제는 미국 물건들이 너무 많다는 것이 아니라 미국 물건들이 있다는 것이다. --골베즈 (대화) 23:17, 2009년 4월 26일 (UTC)[응답하라]
나는 위키피디아가 365개 중 적어도 하루 동안 특정 국가에 대한 언급을 생략할 것을 제안하고 있다.365일 중 365일 위키백과 웰컴 투 위키백과에서 언급되는 나라는 미국이 유일하다.그것이 편견이 있는 곳이다. B. 페어베언 (대화) 23:33, 2009년 4월 26일 (UTC)[응답하라]
너는 그 일에 대해 너의 작품을 보여줘야 할 것이다.그래서?대부분의 제1언어 영어 사용자들, 그리고 아마도 편집자들은 미국인이다.각 나라에 특별한 날을 줄까? --골베즈 (대화) 23:35, 2009년 4월 26일 (UTC)[응답]
좋은 생각이야.매일 한 나라를 언급하는 것보다 낫다.증거를 원한다면, 기록 보관소를 뒤져봐. B. 페어베언 (대화) 2009년 4월 26일 (UTC) 23:48[응답]

영어권 국가의 수는 그러한 내용과 관련이 있는 것이 아니라, 그러한 국가들에서 온 영어 사용자들의 비율이다.영어가 세인트빈센트 및 그레나딘족의 공용어일 수도 있지만, 그들의 총인구는 미국의 0.04%에 불과하다.심지어 영국의 인구도 미국의 23%에 불과하다.많은 나라들 또한 여러 개의 공용어를 가지고 있다.영어는 케냐의 공용어지만 스와힐리어도 마찬가지여서 인구의 7.19%만이 실제로 영어를 구사한다.[ref]Mr.Z-man 23:42, 2009년 4월 26일 (UTC)[응답]

영어권 국가들에 관한 한, 공평한 지적이다.심지어 영어 이외의 다른 언어를 모국어로 사용하는 미국인들이 수백만 명이라는 사실을 감안하더라도 말이다.
하지만... 위키백과에 오신 것을 환영합니다 페이지에는 영어권 이외의 많은 나라들에 대한 언급이 포함되어 있다. 예를 들어 이라크, 스페인, 필리핀, 케냐, 멕시코, 아이슬란드, 우크라이나 등.이 경우 미국은 677만7000명(4.56%) 가운데 3억600만 명이다.물론 당신은 다른 어떤 나라보다 더 높은 비율의 미국인이 인터넷 접속을 한다고 주장할 수 있지만, 이것은 여전히 제기된 이슈를 다루지 못한다: 왜 위키백과에 온 것을 환영하기 위해 매년 매일 하나 이상의 미국에 대한 언급이 있어야 하는가. B. 페어베언 (대화) 2009년 4월 27일 00:09 (UTC)[응답]
왜냐하면 1) 다른 어떤 유형보다 미국 편집자가 많기 때문에 미국 주제에 대해 더 많이 쓴다는 것은 일리가 있고 2) 미국 이야기는 세인트에 있는 것보다 더 국제적인 언론을 얻는 경향이 있기 때문이다.빈센트, 그래서 ITN에 더 널리 퍼지는 경향이 있고 3) 정확히 무슨 문제인가?그래서 만약 미국이 매일 언급된다면?그래서? --골베즈 (대화) 00:37, 2009년 4월 27일 (UTC)[응답]
나는 변화를 요구하고 있다.하루만.불가능 한 건가요?항상 미국인의 언급이 있어야만 하는가?아니면 위키백과의 조건인가? 계약 조항이 있는가? "위키피디아에는 매년 위키백과에 온 것을 환영한다. 그렇지 않으면 미국이 위키백과를 금지할 것이다."와 같은 것이 있는가? B. 페어바인 (대화) 2009년 4월 27일 01:14 (UTC)[응답하라]

B. 페어밴은 WP에 관심이 있을 수 있다.위키피디아에 대한 체계적 편견에 대항하기 위한 시도로 존재하는 체계적 편견.그리고 그게 무슨 가치가 있는지는- 내 생각에 그것은 미국에 관한 것이 항상 1면에 있다는 것이 그리 많지 않다. 그것은 너무 자주 불명확하고, 언급할 가치가 없고, "알라바마 힉스빌에서 유명한 세계" 타입의 물건들이 나를 짜증나게 한다.그것과 이해할 수 없는 "모든 상태 8회 러닝코"의 악랄함.던컨힐 (대화) 2009년 4월 27일 00:48 (UTC)[응답]

훌륭한 기여, 특히 "흔히 불명확하고, 메모할 수 없는" 포인트.
그리고 종종 미국의 주는 마치 국가인 것처럼 언급된다.예를 들어, 오늘을 환영하는 의미에서, '오레곤주 후드 리버에 있는 라디오 방송국 KIHR의 전 소유주가 그의 경력을 시작했다...' 영국, 호주, 남아프리카, 스웨덴인에게 미국의 50개 주를 이름 지어달라고 요청하면 아마도 천 명 중 한 명 미만이 그 모든 것을 알 것이다.아니면 걱정. B. 페어바인 (대화) 2009년 4월 27일 01:23 (UTC)[응답하라]
그래서 오리건주 후드 리버가 상장에 연계된 것이다.미스터 지맨 01:29, 2009년 4월 27일 (UTC)[응답]
네 말이 맞아.나는 나라 이름에 대한 언급 없이 다른 나라들의 장소들에 대한 언급들을 찾아봤고, 그래서 코멘트를 철회했다.주요 이슈로 돌아가면: 항상 미국의 연결고리가 있고, 사소한 미국 이야기나 이야기가 있다. B. 페어베언 (토크) 2009년 4월 27일 01:40 (UTC)[응답하라]
그래서?이 문제가 어떻게 전투 규칙이 필요한 문제인지 아직 증명하지 못하셨군요. --골베즈 (토크) 02:26, 2009년 4월 27일 (UTC)[응답]
"다양한 이야기"에 대해서는, 알고 계셨는지요...섹션은 최근에 만들어진 기사들을 강조한다.우리는 이미 거의 모든 "주요"에 대한 기사를 가지고 있기 때문에 (DYK보다 새로운 "주요"는 뉴스 섹션에 있을 것 같기 때문에, 블러버는 일반적으로 그들이 어떤 나라와 관련이 있든 상관없이 사소한 것에 관한 것이다.나는 확실히 빅아이 모래 호랑이는 신경 쓰지 않지만, 그것이 메인 페이지에 있는 것에 대해서는 아무런 문제가 없다.미스터Z맨 02:38, 2009년 4월 27일 (UTC)[응답]

문제는 없다; 사소한 문제가 있다. 그리고 그것은 위키 환영에 항상 yank 자료가 있다는 것이다.항상매일
이제 나는 미국인과 미국에 대해 아무런 반대도 하지 않는다.미국은 세계에서 가장 위대한 나라다.그것이 무슨 일이든 중요한 것이라면 그것은 내 의견이다.
아무것도 아닌 것에서 미국의 개척자들은 각자가 다음 사람과 동등하고 모든 사람이 자신의 신념을 표현할 수 있는 훌륭한 자유국가(노예 250년)를 건설했다(공산주의를 지지하지 않는 한.
미국은 두 번의 세계 대전 동안 자발적으로 들어와 평등한 세력 간의 차이를 만들어 많은 사람들이 폭정에 시달리지 않고 계속 자유롭게 살 수 있게 함으로써 자유세계를 환상적인 서비스로 만들었다.
그 후 몇 년 동안 미국 정부가 아시아에서 "도미노 이론"에 사로잡힌 것은 유감스러운 일이며, 미국 정부는 때때로 다른 나라들이 운영되는 방식에 간섭할 권리가 있다고 생각하는 경향이 있었지만, 어느 누구도 완벽하지 않다.
미국은 최고고, 나는 미국인들이 자신들과 그들의 멋진 나라에 대해 읽는 것을 좋아한다는 것을 이해하지만, 확실히 한계가 있다. B. 페어베언 (대화) 09:49, 2009년 4월 27일 (UTC)[응답]

나는 "미국이 세계에서 가장 위대한 나라"라는 것에 동의하지 않을 것이다. 당신은 그것의 "위대한 나라"를 과학적으로 측정할 수 없기 때문이다.어쨌든 화제가 되고 있다:골베즈는 (비유를 하자면) "...다른 어떤 유형보다 미국 편집자가 더 많으니 [그들의 나라에 대해 더 많이]"라고 썼는데, 그것은 잘못된 것이다.사람들은 위키피디아에 와서 한 명의 특정 대상자를 위해 쓰지 않는 상당히 대표되는 백과사전을 찾는다.그것은 사실 매우 편협한 견해고 나는 기꺼이 골베즈가 미국 출신이라고 확신한다.나는 한 지지자 B를 지지한다.위키피디아(메인 페이지뿐만 아니라)에 대한 미국의 일반적인 영향력의 양을 줄이자는 페어베언의 제안.이것은 국제적인 백과사전이다. 그 이하도 아니다.스카리안Call me Pat! 13:12, 2009년 4월 27일 (UTC)[응답]
또한 골베즈가 긍정도 반대도 말하지 않은 상황에서 미국 출신이라고 보는 것은 매우 편협한 생각이다.;) --Izno (대화) 2009년 4월 27일 (UTC) 13:33[응답]
지지해줘서 고마워, 팻.불행히도 많은 미국인들은 어려서부터 세뇌되어 미국이 우주에서 가장 위대한 나라라고 믿게 되고, 다른 모든 민족들은 열등하다.많은 수의 미국인들이 그들 자신을 칭찬하는 것을 멈추게 하는 것은 미국인들이 무엇보다도 그들의 나라를 사랑하도록 훈련 받을 때 매우 어려운 일이다(아마도 돈일 것이다).이런 태도는 미국의 일반적인 캐치프레이즈 "God Bless America"에 의해 증명된다.다시 말해서, 다른 모든 사람들에게 너무 안 좋은 것이다. B. 페어바인 (대화) 2009년 4월 27일 13:34 (UTC)[응답하라]
빈정거림과 미사여구는 당신의 사건에 도움이 되지 않는다.페어베언. --Izno (대화) 2009년 4월 27일 (UTC) 13:37[응답]
나는 보는 대로 말한다, 이즈노구드(아스테릭스 책의 등장인물)그리고 접선하지 않고 요점을 고수하려고 노력한다. B. 페어바인 (대화) 2009년 4월 27일 14:12 (UTC)[응답]
아스테릭스가 어떤 책이었는지 기억은 안 나지만 아스테릭스 책에서 유래된 이름도 몰랐어! :O (친구 한 명이 사용하는 걸 보고 이름 으로 "아이즈노구드"를 들었다...말하자면, 이즈노는 내가 알 수 있는 바로는 독특한 파생상품이다.그럼에도 불구하고, 비아냥거리는 것은 스페이드라고 부르는 것과 같지 않기 때문에, 스페이드라고 부르는 것은 당신의 본래의 메시지에 더 많은 피부일 수 있기 때문에, 그 비아냥거림은 그만둬야 한다.우리가 이미 알고 있는 것, 그리고 그것을 줄이기 위해 일하는 많은 활동적인 편집자들이 있다.아래의 제안과 같이, 우리가 언제 무엇을 편집하는지에 대한 통제권이 없는데 왜 당신은 그것을 바꾸라고 주장하지 않고 지원으로 돌아가지 않는가? --Izno (대화) 15:19, 2009년 4월 27일 (UTC)[응답]
아스테릭스 말고.같은 작가(고시니)지만 다른 예술가.Iznogoud --83.253.251.213 (대화) 20:20, 2009년 4월 27일 (UTC)[응답]
이타 에스트(라틴어: 그래, 그렇구나.네 말이 맞아.그리고 아스테릭스 책의 영어 번역본 중 어딘가에 '이즈노구드'라는 인물이 있다고 맹세할 수 있다.그렇다면 왜 그 이름이 선택되었는지(고시니 링크) 이제 알겠다.어떤 책을 읽었는지 기억이 나지 않는다.'블랙 골드'나 '매직 카펫'과 같은 새로운 것이었을지도 모른다. B. 페어밴 (토크) 02:37, 2009년 4월 28일 (UTC)[응답하라]

언제부터 미국만이 "God Bless America?" – God Save the Queen과 같은 모토를 가지고 있을까?미국은 민족주의를 창안하지 않았다.2009년 4월 27일 Mr.Z-man 16:18 (UTC)[응답]

신과 함께 탁월한 포인트를 주어 왕/여왕을 구하십시오.이 논의는 몇 가지 흥미로운 관찰을 끌어내고 있다.잘했어, Z.그것 때문에 생각났어.어쩌면 나 역시 내 출신국가에 의해 세뇌된 죄를 지었을지도 모른다. B. 페어밴 (토크) 02:37, 2009년 4월 28일 (UTC)[응답하라]
미국 주제에 대한 금지를 요구하는 대신, 의사 결정 과정에 참여하여 미국 이외의 주제를 홍보하는 것은 어떨까?그것은 여기서 징징거리는 것보다 훨씬 더 효과적이고, 임의적인 금지나 할당량보다 훨씬 더 건설적일 것이다.아노미에 13:39, 2009년 4월 27일 (UTC)[응답]
나는 미국 주제에 대한 금지를 요구하지 않았다.아직 멀었지요나는 위키피디아 웰컴에 관한 미국 관련 이야기가 없는 적어도 일년에 하루 정도는 있어야 한다고 요청해 왔다.한 달에 한 번이면 예상을 훨씬 뛰어넘을 것이다.일주일에 한번은 불가능하다.나는 금지가 아닌 미국 없는 날을 부르고 있다. B. 페어바인 (대화) 2009년 4월 27일 (UTC) 13:46[응답]
이런저런 이유로 위키피디아의 편집자들이 미국에 관한 기사에 더 많은 에너지를 쏟는다.그들은 이러한 노력에 대해 더 높은 비율의 1면 보상으로 보상받는다.이것이 문제로 본다면, 해결책은 저울 반대편의 기사를 개선하는 데 힘을 쏟는 것이다.그러면 당신이 불균형으로 인식하는 것을 볼 수 있는 보상을 받게 될 것이라고 반박한다.본질적으로 당신은 위키피디아의 한 영역이 다른 영역보다 더 빨리 개선되고 있다고 불평하는 것처럼 보이십니까?해피멜론 13:52, 2009년 4월 27일 (UTC)[응답]

왜 내가 이미 위키피디아 웰컴에 자료를 기부하고 있는 수많은 사람들에게 미국적인 모든 것에 집중하는 것을 멈추도록 설득하는 것 외에 다른 것을 해야 하는가.나는 한 사람일 뿐이다.다른 모든 기고자들을 다른 나라들에 대한 자료들로 덮어씌우려고 허망하게 시도하기보다는, 다른 사람들이 한 나라에 대해서만 글을 쓰는 것에 그렇게 집착하지 않도록 돕는 것이 낫다. B. 페어바인 (대화) 2009년 4월 27일 (UTC) 14:07 [응답]

왜냐하면 이건 봉사활동이고 사람들은 자신이 하고 싶은 일만 하기 때문이다.물론 제안할 수도 있지만, 그 이상의 어떤 것이든 간에 사람들에게 WP를 편집하는 데 시간을 할애할 수 있는 방법을 알려주려는 것 같아. ♫ 멜로디아 샤콘 ♫ (토크) 2009년 4월 14:48, (UTC)[응답하라]
왜냐하면 편견을 퇴치하고 프로젝트를 개선하는 방법은 우리가 현재 편견을 갖고 있는 내용으로 대항하는 것이지, 더 편견을 가지고 싸우는 것이 아니기 때문이다.특정 콘텐츠가 메인 페이지에 나타나지 않더라도 금지시키는 것은 편집자의 의욕을 떨어뜨린다.네가 하는 말은 네가 어떤 일도 하지 않아도 된다는 것이고, 다른 사람들은 네 말만 들어야 한다는 거야.그런 식으로는 안 된다.멜로디아가 말했듯이, 우리는 모두 자원 봉사자들이고, 우리가 하고 싶은 일을 한다.2009년 4월 27일 Mr.Z-man 16:18 (UTC)[응답]
맞아. 누군가가 그들의 우려를 논하려고 하는 것은 절대적으로 잘못된 거야. 위키피디아에서는 그런 행동이 참을 수 없어!던컨힐 (대화) 2009년 4월 27일 16시 30분 (UTC)[응답]
나는 늘 그렇듯이 무작위 기사를 반복해서 치면 영어권 이외의 플래카드와 축구/축구 선수 및 팀의 평소의 높은 비율을 포함하여 미국과 전혀 상관없는 최소한 절반의 기사가 생산된다는 점에 주목한다.
더 심각하게, 우리는 미국 주제에 대한 한 사람의 반감을 존중해서는 안 된다.망고 (대화) 2009년 4월 27일 17:53 (UTC)[응답]

메인 페이지의 정보는 기여도에 기초하기 때문에 영향력 이상의 것을 해야 한다.최근에 만들거나 개선된 기사들은 DYK로 보내진다; 그들을 위해 만들어진 페이지가 있는 실질적인 뉴스 기사들은 뉴스에서 나온다; 피처링된 콘텐츠는 예외적으로 여겨지는 페이지를 포함한다.만약 당신이 환영 페이지에 더 많은 정보를 원한다면, 당신은 그것을 그곳에 도착하기 위해 기여해야 한다.지지자들에게 도움을 주도록 할 수는 있지만, 전면 금지는 (하루라도) 가는 길이 아니다.당신은 미국에서 역사적인 일이 전혀 일어나지 않았고, 실질적인 미국 기사가 만들어지지 않았으며, 최근의 뉴스가 미국에 관련되지 않은 날을 보내야 할 것이다.이것은 하루 동안 페이지가 다르게 행동하게 할 뿐만 아니라, 미국에서 중요한 일이 일어난다면 뉴스를 검열하는 것이 될 것이다.여러분과 여러분의 대의에 대한 지지자들은 특별한 사례를 만들기 보다는, 필요한 기사를 만들고, 뉴스 기사를 기고하고, 주제를 개선하는 등 미국 범위 밖에 집중함으로써 환영 페이지에 영향을 줄 수 있다.당신은 심지어 평소보다 더 많은 미국 주제들을 페이지 밖으로 밀어내기 위해 하루를 계획할 수도 있다.하지만 위에서 언급된 다른 사람들처럼, 이것은 주제에 관심이 있는 자원봉사자들의 도움이 필요하다.—Ost (토크) 2009년 4월 27일 18:17 (UTC)[응답]

나는 위키피디아가 특히 북아메리카와 서유럽의 엄선된 지역에 문화적으로 양분된 백과사전이라는 것을 알아챘다.위키피디아의 비판에 가면, 거기에 언급되는 비판은 위키피디아의 미국 중심 편향이라는 점이 흥미롭다.ACEOREVIVEED (토크) 2009년 4월 27일 (UTC) 19:35 [응답]
거기서 인용한 참고자료를 찾아보면, 그것은 우고 차베스 편집에 대한 오시에 폴리 에콘 교수의 주장을 가리킨다.문제의 기사는 모든 사람들에 의해 사방에 묶여져 있고, 역사를 들여다보면 나는 이 사람이 기사를 편집하거나 그 연설 페이지에 어떤 언급도 한 적이 없다는 것을 볼 수 없다. 그가 하지 않았다고 확신하는 것이 아니라, 그가 했다는 명백한 증거가 없다.어쨌든 한 기사일 뿐이다.필자는 개인적으로 미국과 유럽의 경험에 상당한 차이가 있었던 사례들을 우연히 접해 왔으며, 과감하게 미국 측의 자료를 편입하려 했다는 이유로 편견을 갖고 있다는 비난을 받았다.나는 이것이 주장했던 것만큼 나쁜 문제는 아니라고 생각한다. 만약 찾을 수 있는 모든 것이 IMO의 의심스럽고 뒷받침되지 않는 주장이라면.
더 깊은 문제는 미국을 하루 동안 일면에서 빼는 것은 이 문제에 대해 아무런 도움이 되지 않는다는 것이다.나는 이 순간 현재 미국에 관련된 품목은 DYK의 5개 품목뿐이며, 그 중 3개 품목은 확실히 확인해야만 한다는 점에 주목한다.그 점에서, 사람들은 "오늘의 날"에서 적어도 하나의 아이템이 미국 이벤트와 관련되기를 기대하는 경향이 있기 때문에, 이것은 아마도 조금 특이한 것일 것이다.뉴스에 미국 아이템이 없거나, 특집 기사가 미국 내 무언가에 관한 것이 아닌 것은 드문 일이 아니다.내가 보기에 그 제안은 반미 분개심을 달래기 위해 행해지는 일종의 참회 행위인 것 같다.망고 (토크) 2009년 4월 27일 (UTC) 20:42 [응답]
안녕, 여러분 (혹은 내가 '버디'라고 말해야 할까) - 이미 개선이 이루어지고 있는 것 같다.오늘의 위키피디아 웰컴 투 위키피디아 1) 샌프란시스코 조약, 2) 원주민들과 그들의 침략자들 사이의 아주 사소한 분쟁에 대한 언급, 3) 완전하고 완전히 쓸모없는 트라이비아 " 펜실베이니아 브래독의 시장 존 페터만이, l.그는 2000달러(약 2천원)에 구입한 창고에 보관하고 있다.어서, 넌 할 수 있어.
위의 몇 가지 요점을 간단히 훑어보면서 내가 추가한 어떤 자료들이 비꼬는 것처럼 보인다는 것을 이제 깨달았다.일부 논평은 그렇게 의도된 것이 아니었다.나는 미국이 위대한 나라라고 굳게 믿는다.미국 정부는 다른 어떤 나라보다 더 많은 나라들을 도왔다.미국은 다른 나라보다 더 많은 박해받는 사람들(예: 유대인)에게 안전한 피난처를 제공했다.나는 미국과 미국인들이 민주주의와 자유를 추구하는데 있어서 전세계에 정말로 긍정적인 영향을 끼쳤다고 생각한다.
단지 얼마 후 다른 나라 사람들이 미국의 태도와 미국의 방식과 독선에 노출되는 것에 싫증을 낼 수 있다.많은 텔레비전 쇼는 미국에서 나오고, 대부분의 영화는 미국에서 나오고, 많은 관광객들은 미국에서 오고, 인터넷은 미국에 의해 정말로 지배된다.그리고 아직 세계 인구의 4.56%만이 미국에 살고 있다. B. 페어바인 (토크) 01:38, 2009년 4월 28일 (UTC)[응답]
당신의 게시물은 오늘의 특집 기사와 사진, 그리고 ITN, DYK, OTD의 출품작과 전혀 관련이 없다는 것을 확신할 수 있다.그것에 싫증이 난 것에 대해 - 그것을 극복해라.그리고 대신 중국이 지배할 다음 세기를 즐겨라. --골베즈 (대화) 01:59, 2009년 4월 28일 (UTC)[응답]

'다음 세기'?지금의 세기, 즉 21세기를 말하는 거구나.기대할게적어도 그것은 변화가 될 것이다.궁헤이파트코이(광동어:축하하고 번창하라. B. 페어베언 (토크) 02:20, 2009년 4월 28일 (UTC)[응답하라]

골베즈는 믿음을 좀 더 가져야 해, 메뚜기.그리고 나는 "잊어버려"보다 더 좋은 101가지 글을 쓸 수 있다.동의하지 않으세요?나는 B를 축하해야 한다.Fairbairn은 그의 냉정을 유지할 수 있었다; 더 적은 사람들이 Golbez의 실패를 지적할 수 있는 기회에 뛰어들었을 것이다.스카리안Call me Pat! 12:25, 2009년 4월 28일 (UTC)[응답]
고마워 팻.종종 의미 없는 은어 시합에 말려드는 것을 거부하는 것이 가장 좋은 방법이며, 특히 그것이 정확히 다른 개인이 원하는 것일 때는 더욱 그렇다. B. 페어바인 (대화) 2009년 4월 29일 (UTC) 10:57 (대화)[응답]
미국 이외의 다른 나라가 메인 페이지나 "Welcome to Wikipedia"에 가장 중점을 두는 날을 갖는 것이 위키백과의 문화적 편향 문제를 해결하는 데 정말로 도움이 될지 궁금하다; 만약 다른 기사를 본다면, 다른 기사들보다 세계의 특정 부분에 대한 보도가 더 낫다는 것을 알 수 있다.(사실, 미국뿐만 아니라, 내 조국 영국도 동 아시아나 아프리카와 관련된 주제보다 그것에 관련된 주제를 더 잘 다루게 될 것 같다.존 미비티와 같은 아프리카의 철학자-신학자는 현재 미국 정치인이나 수잔 보일과 같은 영국 언론이나 지난 가을 조나단 로스나 러셀 브랜드의 거짓 전화에 관한 논쟁에서 찾을 수 있는 것보다 더 적은 정보를 가지고 있다.하지만, 내 한쪽은 - 단지 직면하기만 하면 된다고 말하는데, 단순한 이유로 위키백과뿐만 아니라 다른 웹사이트에서 선택된 지역에 대한 문화적 편견이 있을 가능성이 높다.미국, 영국, 독일 또는 프랑스 등 세계 어디에서 사람들이 웹을 사용할 가능성이 더 높은가?아니면 아프리카나 아시아에서?아마도 이 제안은 일반적으로 웹 자원에서 찾을 수 있는 문화적 편견에 부딪혔을 것이다.ACEOREVIVEED (토크) 21:28, 2009년 4월 28일 (UTC)[응답]
그리고 위키피디아와 전세계 웹에 공평하게 말하자면, 나는 인쇄된 브리타니카가 비슷한 문화적 편견을 보였을지 궁금하다.ACEOREVIVEED (토크) 23:08, 2009년 4월 28일 (UTC)[응답]
좋은 생각인 것 같아.나도 끼워줘.나는 브리타니카 백과사전을 공부한 적이 없으며, 다행히도 위키피디아가 모든 사용자에게 무료인 한 그럴 필요가 없다. B. 페어뱅 (대화) 2009년 4월 29일 (UTC) 11:00[응답]
DYK에서의 과거의 경험에 근거하여, 이러한 "해결"은 두 가지 시나리오 중 하나로 귀결될 것이다. 즉, 반미일마다 모든 미국인의 날을 강제적으로 만들거나 기고자를 몰아내는 것이다.위키피디아는 자원봉사자들에 의해 쓰여지고 있으며, 자원봉사자들은 그들이 흥미와 지식을 겸비한 주제에 기여하려는 경향이 강하다.모든 위키백과 기고자의 약 절반이 미국에서 40~60%의 지리적 편향을 가진 기고문은 따라서 미국과 관련이 있다.따라서 미국 이외의 날을 지정하면 미국 관련 주제의 백로그가 생성되어 대기열에서 플러시되면 기본적으로 미국 전체 날이 된다.다른 옵션은 이러한 기여를 기본 페이지에 표시하는 것으로부터 자격을 박탈하여 미국 관련 주제에 대한 지식과 관심이 있는 사람들의 기여에 대한 일차적인 인센티브를 제거하는 것이다. --Alen3 12:25, 2009년 4월 29일 (UTC)[응답]

그래, 쉽지 않다.아마도 위키피디아의 내 취향에 옵션이 추가될 수 있을 것이다. 시작 페이지의 미국 자료는 어떠한가? 예스 또는 아니오.Yes(예)를 선택하면 일반적인 시작 페이지가 표시되며, No(아니오)를 선택하면 Did You Know 및 On This Day(이날) 열에 미국 이벤트가 포함되지 않는다.인 더 뉴스 영역은 그대로 남아 있을 것이다.기고자가 기사를 추가할 때 "이것은 American Material"과 같은 작은 편집 상자가 있을 수 있으며, 시작 페이지의 American Material 옵션이 "Yes"로 설정된 사용자에게는 기본적으로 선택된다. B. 페어베언 (대화) 09:04, 2009년 4월 30일 (UTC)[응답]

그래서 내가 옳았어 - 너의 문제는 1면에 미국 콘텐츠가 있다는 거야. 그리고 너는 그것을 완전히 생략하는 옵션을 선호할 거야.질문 - 만약 미국을 대신해서 다른 국가가 지배하게 된다면?만약 어떤 미국 기사도 없는 상태에서 모든 이야기들이 대부분 호주에 관한 것이라면?그것들 또한 생략할 수 있는 선택사항을 캠페인 하시겠습니까? --골베즈 (토크) 00:00, 2009년 5월 2일 (UTC)[응답]
하지만 미국 재료의 특별한 점은 무엇인가?위키피디아는 또한 인도의 알려지지 않은 스포츠 선수들과 작은 마을들에 관련된 콘텐츠에 편중되어 있다; "메인 페이지의 축구 선수"가 선호되어야 하는가?"아프리카 마을 메인페이지"?왜 "미국이 없는" 메인 페이지를 만들기 위해 애를 쓸 필요가 있는가? 그러나 이러한 과도한 가중치를 가진 다른 주제들을 피하는 메인 페이지를 만들지는 않는가?해피멜론 09:41, 2009년 4월 30일 (UTC)[응답]
이 주제의 시작을 읽으면 시작 페이지에 항상 미국 자료가 있다는 사실을 언급하는 것을 볼 수 있다.그것이 바로 이 일에 관한 것이다.그 어느 나라도 그렇게 가까운 곳에 언급된 나라는 없다.이것이 독자들에게 미치는 영향에 대한 예를 들어보자.나는 온라인 접속이 가능한 사람이 수십 명인 섹션에서 일하지만 내가 아는 한 위키피디아를 방문하는 사람은 단 두 명뿐이며, 다른 대부분의 사람들로부터 그것을 사용하지 않는 핑계는 위키피디아가 너무 미국화되어 있다는 것이다.나는 사람들에게 그것이 아니라고 장담한다 - 미국과 상관없는 수천개의 아이템이 있다.하지만 물론 그들이 위키백과의 메인 페이지를 여는 순간에는 항상 많은 미국 기사들(국제 기사들뿐만 아니라)이 있다...그리고 그것은 사람들을 멀어지게 한다. B. 페어베언 (대화) 09:53, 2009년 4월 30일 (UTC)[응답]
그러나 내가 말했듯이 해결책은 편견을 가지고 싸우지 않는 것이다.기고자를 낙담시키고 전반적인 성장을 둔화시키는 것만이 독자들에게 해를 끼친다.2009년 4월 30일 Mr.Z-man 16:53 (UTC)[응답]

이는 원안에 대한 답변이 아니라 전반적으로 이 논의에 대한 논평이다.내게는 이 토론이 위키백과에서 나온 가장 흥미로운 토론 중 하나였던 것 같다. 빌리지 펌프, 그리고 나는 이것이 위키피디아의 새로운 기사의 시작이 될 수 있는지 궁금하다. 예를 들어 "Wipedia의 문화적 편견"이라고 불린다.이 글이 그 자체로 기사화할 가치가 있다고 생각하지 않는 사람이라면, 예를 들어 위키백과의 비판이나 위키백과의 역사 같은 것과 통합될 수 있다.어쩌면 우리는 이것을 확장하고 "세계와이드웹의 문화적 편견"에 대한 기사를 만들 수도 있을까?위키피디아의 주요 부분에 있는 기사는 미래에 많은 독자들이 볼 수 있는 반면, 이곳의 항목은 너무 오래지 않아 보관될 것이다.나는 이 흥미로운 토론의 결실이 위키백과의 대부분의 독자들이 쉽게 볼 수 있는 것에서 곧 사라진다면 수치스러울 것이라고 생각한다 - "위키백과의 문화적 편견"과 같은 것에 관한 기사가 이 토론을 출발점으로 삼을 수 있을 것이다.ACEOREVIVEED (토크) 2009년 4월 30일 (UTC) 19:58[응답]

좋아 - 해보자.우선 사용자 이름, 날짜, 그리고 "그것을 잊어라" "무슨 문제인가"와 같은 지적 수준이 높은 코멘트를 지워야 할 것 같다. :-) B. 페어뱅(토크) 23:48, 2009년 5월 1일 (UTC)
위키백과에 대한 다수의 위키백과 사용자들의 의견과 진술은 확실히 어떤 것에 대해서도 믿을 만한 출처는 아니다.Mr.Z-man 23:54, 2009년 5월 1일 (UTC)[응답]
사실을 지켜라.의견과 진술, 공격을 제거한다.
사실 1: 미국은 365일 중 365일 동안 위키피디아에 온 것을 환영한다.
사실 2: 미국은 677만 7천 명 중 3억 6천 6백만 명(4.56%)이다.이 숫자는 위키피디아 웰컴에 나타나는 미국 자료의 양에 비해 불균형적으로 낮다. B. 페어베언 (대화) 00:05, 2009년 5월 2일 (UTC)[응답]
우리는 그들의 나라가 대표하는 인구의 비율에 전적으로 기초하여 1면에 언급해야 하는가?왜냐하면 세계 인구의 0.007%를 차지하는 솔로몬 제도들이 40년에 한 번 이상 언급되어 과잉대표되고 있는 것이 아닌가 의심하기 때문이다.--골베즈 (토크) 00:23, 2009년 5월 2일 (UTC)[응답]
B. 페어바인, 나는 이것이 이 토론에서 한 사람이 얻을 수 있는 것이라고 생각한다.우리가 배운 것을 가지고 가서 백과사전을 너의 능력을 최대한으로 향상시키는 것을 추천하고 싶다.골베즈:나는 이 실에서 너의 행동에 실망했다.당신은 무시하며 빈정거렸소. 결코 좋은 조합이 아니오, 선생님.스카리안Call me Pat! 00:52, 2009년 5월 2일 (UTC)[응답]
em을 보고 em을 부른다. --골베즈 (대화) 00:59, 2009년 5월 2일 (UTC)[응답]
전체 주제(TLDR)를 읽어본 적은 없지만, 지금 메인 페이지는 단 한 분야의 미국 주제(오늘날의 FA, 국적에 관한 한 총체적인 헛소리)에만 관심을 끈다.내가 이 주제에 대해 읽은 것에 대한 나의 인상을 고려할 때, 나는 무시적이고 비꼬는 태도로 대답하지 말아야 한다는 압박을 받을 것이다; 메인 페이지는 너무 미국 중심적이라는 생각(또는 하늘이 금지한, 전혀 미국을 언급하고 있지 않다는 생각)은 꽤 어리석다.EVULA // talk // talk // 02:27, 2009년 5월 2일 (UTC)[응답]

임의 중단:위키백과에 오신 것을 환영합니다(미국)

"사실"은 여전히 거의 전적으로 사용자에 의한 독창적인 연구로 구성되어 있다.토론이나 에세이로서는 괜찮지만, 기사에 있어서는 꽤 끔찍한 근거가 된다.개인적으로 골베즈의 00:23 코멘트가 정말 뭐가 잘못됐는지 모르겠다.빈정거렸지만 누구를 공격한 것도 아니고, 좋은 점을 제기한다.인구만 놓고 보더라도 미국 보장의 90%는 중국과 인도의 보도로 대체될 겁니다.우리는 그것이 더 이상 편향되지 않는다고 주장할 수 있지만, 그것은 지금보다 훨씬 덜 다양할 것이다.미스터Z맨 02:05, 2009년 5월 2일 (UTC)[응답]

아니. 나는 각 나라의 대표성이 균등하게 나타나기를 바라는 것이 아니라, 미국과 관련된 위키백과에 관한 기사의 수를 줄여달라는 것이다.그것은 미국 독자들이 아닌 다른 독자들을 위해 위키피디아를 방문하는 것을 더 즐겁게 만들 것이다 - 그들은 미국 관련 곱창을 거치지 않고도 위키피디아의 웰컴 투 위키피디아에 관한 기사를 읽을 수 있을 것이다.미국의 진정한 뉴스 기사와 중요한 미국 물품은 다른 나라와 마찬가지로 그대로 남아 있어야 하지만, 미국 특종 기사들을 미국 전용 섹션에 넣자.내 말은, 미국. B. 페어베언 (대화) 17:14, 2009년 5월 2일 (UTC)[응답하라]
그래서 미국에 관한 기사들은 지금 "트리프"이다.그리고 알아들었어, 넌 그 나라의 이름에 대해 농담을 했어.그렇게 해서 높은 길을 유지하는 거야! --골베즈 (토크) 17:17, 2009년 5월 2일 (UTC)[응답하라]
(충돌 편집)그리고 미국에서 온 독자들의 상당한 비율(모든 위키피디아 방문자 중 22%가 미국인이지만, 나는 단지 en에 대한 통계는 찾을 수 없다.위키피디아), 우리는 그냥 "너희들"이라고 말하는거야?당신이 제안하는 것은 암묵적인 편견과 싸우는 것이 아니라, 단지 명백한 편견으로 그것을 대체하는 것이다. 더 나쁜 것이다.그렇다면 우리는 가장 눈에 띄는 페이지를 편향되게 만들기 위해 적극적으로 노력할 것이기 때문에 프로젝트에 대한 편향과 싸우려고 한다고 말할 수도 없었다.Mr.Z-man 17:41, 2009년 5월 2일 (UTC)[응답]
그것은 진짜 오타였다.나는 그 실수를 조금이나마 즐거워했기 때문에 그것을 바로잡지 않았다.

몇 가지 작은 연구를 하면서, 내가 발견한 것은 이렇다.2009년 오늘의 특별 기사에는 다음 사항이 적용된다. (비국가 및 복수 국가 참조는 포함되지 않음)

위치 기사들
남극 2
호주. 3
캐나다 3
중앙아프리카 공화국 2
중국 1
이스터 섬 1
유럽 1
프랑스. 2
독일. 2
그리스 1
인도 2
이탈리아 3
리투아니아 1
로마 제국 3
싱가포르 1
남베트남 1
스웨덴 1
영국 21
미국 36
USSR 1
베트남 1

(주: '영국'은 영국, 스코틀랜드, 웨일스, 북아일랜드 등을 포함하며, 기원전 2,400년 스톤헨지가 창조한 것을 취재한다.'미국' 기사에는 1513년 북미에서 최초로 기록된 유럽 상륙 기록부터 지금까지) B에 관한 내용이 실려 있다. 페어베언 (토크) 17:32, 2009년 5월 2일 (UTC)[응답]

나는 어떻게 "트리프"가 오타가 될 수 있는지 알 수 없지만, 당신의 연구 결과 또한 다소 의심스럽다.Acid2는 무엇에 넣으십니까?시퀀스 정렬, 액츄어, 알돌 반응, 오일 셰일, 사프론, 낭포성 섬유화, 무한 원숭이 정리, 자유 의지, 파삽입학, 만능의 역설, 인텔리전트 디자인은 어떨까?모두 피처링 기사 퀄리티로, 어느 순간 메인 페이지에 "오늘의 피처링 기사"로 등장한 적이 있다.EVULA // talk // talk // 17:44, 2009년 5월 2일 (UTC)[응답]
자, 계산기로 여러분은 2009년 현재까지 31+28+31+30+3일, 즉 123일이라는 것을 알 수 있을 것이다.위 표에는 89일이 수록되어 있다.위 표의 텍스트에는 "비국가 및 복수 국가 참조는 포함되지 않음" 조항이 있다.네가 언급한 기사들은 바로 여기에 있어. B. 페어베언 (대화) 17:51, 2009년 5월 2일 (UTC)[응답하라]
응, 게시하고 나서 봤어.하지만, 당신의 표는 여전히 심각한 결함이 있는 정보다. 만약 당신이 한 나라가 1년 동안 참조되는 횟수를 표로 작성했다면, 우리는 조금 더 정확한 정보를 얻을 수 있을 것이다.그럼에도 불구하고, 나는 무엇이 문제인지 모르겠다; 메인 페이지는 미국이 지배하고 있는 것이 아니고, 당신은 편견을 상쇄하려는 것이 아니라, 다른 방향으로 치우쳐 있는 것을 보고 있다는 것을 충분히 분명히 했다.EVULA // talk // talk // 17:54, 2009년 5월 2일 (UTC)[응답]
그러나 이스터섬과 남극대륙은 상당히 과대포장된 것으로 보인다.미스터 Z-man 18:07, 2009년 5월 2일 (UTC)[응답]
TFA는 미국 기사가 지배하고 있다.그 뒤를 영국 기사가 이었다.그리고 1년 중 3분의 1은 상당히 중요한 표현이다.내가 만들기 시작한 지점으로 돌아가면, 시작 페이지에는 항상 미국 자료가 있다.항상하루도 없는 날이 없다.다른 어떤 국적도 매일 대표되지 않는다.미국인들은 일 년 중 매일 그들의 나라에 대한 항목을 읽어야 하기 때문일까?다른 세계에 대한 당신의 중요성을 계속 확신할 필요가 있나, 친구들? B. 페어바인 (대화) 18:05, 2009년 5월 2일 (UTC)[응답하라]
"당신의 중요성에 대한 보장이 계속 필요하다"는 식의 헛소리는 이제 그만 하고 말겠어.너는 분명히 트롤을 하고 있어, 간단하고 간단해.EVula // talk // talk // 18:24, 2009년 5월 2일 (UTC)[응답]

이것은 이상한 실이다.누군가는 너무 많은 취재가 미국에 집중되어 있다고 말하기도 하고, "어떻게 하면 국제적인 특집 콘텐츠를 더 많이 얻을 수 있을까?"라고 말하기 보다는, 우리는 정말로 불균형이 없다고 방어적으로 주장한다.알 게 뭐야?

미국 중심적이지 않은 주제에서 나오는 특집 콘텐츠의 더 큰 비율에 대한 생각에 반대하는 사람이 있는가?그 제안은 분명히 장점이 있는데, 왜 그것을 만들 때 사용된 단어들을 비난하는가? -GTBaccus(talk) 18:11, 2009년 5월 2일 (UTC)[응답하라]

국제적으로 특집된 콘텐츠를 더 많이 갖자는 주장이 아니라 미국 관련 주제를 제한하자는 것이다.그것은 의미상의 차이가 아니다.EVula // talk // talk // 18:24, 2009년 5월 2일 (UTC)[응답]
나는 정말 그것을 오리지널 포스터의 주요 포인트로 보지 않는다.'미국의 취재가 없는 날'은 수사적 기구의 불행한 선택이지만, 그 제안의 고기를 찾는다면 우리가 좀 더 다양해질 수 있다는 유효한 전제에서 찾는다. -GTBaccus(talk) 18:38, 2009년 5월 2일 (UTC)[응답]
불행히도 일부 독자들은 미국 콘텐츠의 감소를 자신들과 그들의 나라에 대한 인신공격으로 받아들이고 있다.모든 미국의 애국자들에게 '웰컴 페이지 미국 자료 축소' 제안은 반미적인 것이 아니며 반미적인 것처럼 들리도록 의도된 것이 아니라는 것을 확신시켜주겠다.미국은 훌륭한 나라야. 그리고 그곳에는 많은 멋진 사람들이 있어.일부러 빈정거린 것은 아니다.단지 일부 미국인들이 자기 나라가 세계 최고라고 믿도록 길러지는 경향이 있고, 다른 모든 사람들이 이 믿음을 공유해야 하며, 다른 모든 사람들이 미국에 대해 모든 것을 알고 싶어한다는 것은 불행한 일이다. B. Fairbairn (대화) 18:33, 2009년 5월 2일 (UTC)[응답]
미국 콘텐츠 제한이라는 측면보다는 비미국 콘텐츠 확대라는 측면에서 넣는 게 최선이라고 생각한다.그런 식으로 방어력을 유발할 가능성은 훨씬 적을 겁니다.최고의 전략은 "미국이 너무 지루해"를 FA 지위에 올려놓는 것일 수도 있다.;) -GTBacchus(talk) 18:38, 2009년 5월 2일 (UTC)[응답]
그렇다, 다시 읽어보면, "당신의 중요성을 계속 확신해야 한다"는 말은 좀 지나치다.나의 (역상 다소 실망스러운) 발언은 미국을 마지막 남은 세계 초강대국으로 선포한 기사를 읽은 데서 비롯되었다.EVulta를 의도한 위반은 없다.그리고 나는 트롤링하지 않을 것이다: 만약 당신이 읽는 것에 방해받으면, 그것을 읽지 말라. B. 페어베언 (대화) 18:51, 2009년 5월 2일 (UTC)[응답하라]
나는 또한 당신에게 당신과 의견이 다른 사람들에게 동기를 부여하지 말 것을 제안하고 싶다.어쩌면 그들은 모두 국기를 게양하는 미국의 애국자 무리들이기 때문이 아니라 정말로 그 아이디어가 이 프로젝트에 가장 도움이 되지 않는다고 생각하기 때문에 동의하지 않을지도 모른다.생각일 뿐이야.Mr.Z-man 19:03, 2009년 5월 2일 (UTC)[응답]
바로 그거야나의 반응은 내가 미국인이기 때문이 아니라 내가 바보 같은 생각에 강하게 반응하기 때문이다.더 많은 편집과 다양한 기사의 특색을 옹호하는 것은 한 가지, 즉 내가 강력히 지지하는 것이다.칭얼거리는 것도 또 다른 일이지 "미국이 너무 많아!그걸 무시할 수 있는 선택권을 우리에게 줘!" 그리고 놀랍게도, 어떻게 해서든, 1) 모욕적인 것과 2) 바보 같은 것은 보지 못한다.Fairbairn, 너무 많은 미국이 걱정돼?그럼 희석시켜라.호주의 기사를 특집으로 다루어 보십시오.새로운 기사를 써서 DYK에 넣어라.특정한 날에 미국 밖에서 일어났던 재미있는 일들을 찾아라.하지만 당신이 단지 세계의 다른 나라들에게 공평한 변화를 주고 싶어하는 것에 대해 우리에게 이 곱창을 먹이지 마라.그들은 하나를 가지고 있다. 모든 것은 너에게 달려 있다.여러분이나 다른 사람들이 메인 페이지에서 더 다양한 나라에 대한 주제를 얻는 것을 막는 것은 제로다.하지만 당신은 사람들이 미국에 대해 그들의 작품을 전시하는 것을 막을 수 있을까? --골베즈 (토크) 19:30, 2009년 5월 2일 (UTC)[응답]

만약 영어 위키피디아 편집자의 상당 부분이 북아메리카나 영국 섬에서 온 것이라면, 다음과 같은 특정한 것들이 사실일 가능성이 높다.

  1. 그들이 가장 친숙해질 것 같은 주제나 사람들은 미국이나 영국과 관련될 것이다. (이것이 한 두 세기 전이고, 편집자들이 전통적인 학교 출신이라면, 그들은 성경이나 고전적인 주제에도 똑같이 친숙할 것이다.)
  2. 다른 주제보다 미국이나 영국 테마에 기여하고 확인하는 편집자가 더 많을 것이다(물론 위키백과 전체의 질, 정확성, 중립성을 유지할 수 있었던 방법의 필수적인 부분).
  3. 따라서, 뉴욕시와 같은 미국이나 영국 기사가 특집 기사 지위를 얻을 가능성이 더 높다.

§ 또 다른 평행한 원인은 인터넷과 지역 도서관 모두에서 대부분의 위키백과 편집자들이 이해하는 언어의 출처 가용성이 있을 수 있다.서점, 그리고 학문적인 수업.여러 가지 이유로, 어떤 것은 분명하고 어떤 것은 그렇지 못하기 때문에, 그들이 북미와 영국 제도에 대해 세계의 다른 지역보다 그러한 자료를 찾는 것이 훨씬 쉽다. (인터넷 자료의 많은 비율이 중국어, 스페인어 또는 남아시아 언어로 되어 있다고 해도, 그것이 유능한 E의 수 증가를 의미하지는 않을 것이다.nglish-Wikipedia 편집자는 이러한 자료를 좋은 기사로 전환할 수 있다.)
§ 이것은 어떤 종류의 자랑도 아니다. (내가 런던에서 태어나 미국에 살고 있음에도 불구하고), 심지어 대륙, 오스트랄라시아 또는 제3세계에 관한 기사를 폄하하려는 시도도 아니다.나는 단지 특집 기사와 홈 페이지 기사의 불균형의 이유가 단순한 우월주의, 나르시시시즘, 자기중심주의, 외국인 혐오증 또는 다른 문화에 대한 경멸이 아닐 수도 있다고 생각한다.그리고 그 답은 논앙로-미국인 주제에 대해 학식과 관심이 있는 편집자를 더 많이 모집하거나, 그런 주제에 대해 연구하고 글을 쓰는 데 더 많은 노력을 기울임으로써 근본적인 원인을 다루는 것이다.
§ 불행한 공명("적격 X만 충분하다면, 그렇다면..") 그러나 그런 오만함은 의도된 것이 아니다.—— Shakescene (대화) 19:54, 2009년 5월 2일 (UTC)[응답]

이번 분기부터 오만함은 눈에 띄지 않았다.학식 있는 기고자에게서 기고를 받으니 좋다.위의 코멘트를 대충 훑어보면 일부 기여자들은 매우 타당한 논점을 제기할 수 있고, 일부는 그렇지 않다는 것이 명백하다.아래는 지금까지 제시된 가장 쓸모없는 논평 중 5가지와 혼합된 가장 유용한 논평 중 5가지다.지혜의 진주와 아무 쓸모가 없는 것을 스스로 결정하라.
1. "정확히 뭐가 문제야?그래서 만약 미국이 매일 언급된다면?그래서?"골베즈
그리고 당신은 아직 그 문제를 지적하지 않았다. 미국이 너무 많다고 생각하는 것과는 별개로.당신은 어떻게 그것이 당신 이외의 사람들이 신경써야 할 문제였는지 결코 해명하지 않았다. --골베즈 (대화) 16:07, 2009년 5월 3일 (UTC)[응답]
2. "나는 위키백과가 문화적으로 다소 양립된 백과사전이라는 것을 알게 되었다." ACEOREVIVEED
3. "위키피디아(Wikipedia)는 자원봉사자에 의해 쓰여지고, 자원봉사자들은 흥미와 지식을 겸비한 주제에 기여하는 경향이 강하다."알렌3
4. "그래도 그 빈정거림은 스페이드라고 하는 것과 같지 않으니, 떨어뜨려야 한다." 이즈노
5. "지긋지긋해서 - 극복해."골베즈
만약 메인 페이지에 있는 모든 것이 호주인이었다면, 나는 조금도 개의치 않을 것이라고 100% 확신할 수 있다.내 예에서 배울 수 있어! --골베즈 (토크) 16:07, 2009년 5월 3일 (UTC)[응답]
6. "해법은 저울 반대편의 기사를 개선하는 데 힘을 쏟는 것이다."해피멜론
7. "모든 위키피디아 방문자의 22%가 미국출신인데, en에 대한 통계는 찾을 수가 없다.위키백과), 우리는 단지 '당신을 없애라'라고 말한다" Z_Man
8. "내 생각으로는 미국에 관한 내용이 항상 1면에 실려 있다는 것이 그리 대단한 것이 아니라, 너무나 자주 불명확하고, 주석을 달 수 없다는 것이다." 던컨힐
9. "메인페이지의 정보는 기여에 근거하기 때문에 영향력 이상의 것을 해야 한다" ost
10. "나는 '계속 너의 중요성에 대한 확신이 필요하다' 같은 헛소리 끝에 너와 이야기하는 것을 끝냈다." EVULA
B. 페어바인 (대화) 10:20, 2009년 5월 3일 (UTC)[응답하라]
나는 위의 논평 중 어떤 것이 어떤 범주에 들어맞는지 질문을 받았다.대응: 숫자 1, 4, 5, 7, 10은 쓸모없고 부적절했다.2번은 유효점이다.숫자 3, 6, 9는 '미국을 지지하라' 쪽에서 주장되었지만 또한 유효 포인트였다.8번은 내가 주로 말하던 것을 말해주기 때문에 포함되었다. B. 페어바인 (대화) 22:12, 2009년 5월 9일 (UTC) [응답하라]
이게 토론을 하는 적절한 방법이기 때문에 - 문맥 없이 10개의 덩어리를 잡으면...정확히 뭔데?당신이 철회한 논평에 대한 정당한 불만이었음에도 불구하고 #10을 다시 인쇄하는 이유는 무엇인가?제기랄. 그만 트롤링하고 실제 편집으로 들어가. --골베즈 (토크) 16:07, 2009년 5월 3일 (UTC)[응답]
WP:DFT는 어때? ♫ 멜로디아 샤콘네 ♫ (토크) 11:33, 2009년 5월 3일 (UTC)[응답]
(ec)그래, 시간을 들여 토론을 거치고 두드러진 점을 골라낸 것은 분명하다.이제, 개인적으로 그들을 어떻게 할 생각이세요?어느 학파에 귀의할 생각인가?해피멜론 12:09, 2009년 5월 3일 (UTC)[응답]
이 제안은 아무데도 안 가는 게 분명해이것은 내 시간을 낭비하는 것을 멈추기 위한 다른 어떤 시간처럼 보인다.Mr.Z-man 18:48, 2009년 5월 3일 (UTC)[응답]

TFA를 약간 제외하고, 메인 페이지에 무엇이 실릴지에 대한 결정권자가 한 명도 없고 오히려 기고자 중 하나를 선택하는 자원 봉사자들의 협력적인 노력이 있다.WP의 메인 페이지에 나타나는 내용을 바꾸고 싶은 사람이 있다면:DYK, WP:ITN 및 WP:그렇다면 OTD의 간단한 해결책은 미국적이지 않은 "비경쟁적인" 콘텐츠를 생산하는 것이다.다른 사람들이 지적했듯이, 당신은 자원 봉사자들이 "다양한" 미국 콘텐츠를 만들기 위해 그들만의 자유 시간을 사용하는 것에 대해 비판할 수 없다. 왜냐하면 그것이 그들이 하는 일이기 때문이다.메인 페이지에서 다른 콘텐츠를 보려면 다른 콘텐츠 옵션을 제공함으로써 대안을 제시하기만 하면 된다.마법처럼 내용이 나타나기를 앉아서 기다릴 수는 없다.AgneCheese/Wine12:01, 2009년 5월 3일 (UTC)[응답]

나는 확실히 자원 봉사자들이 그들의 여가 시간을 이용하여 "다양한" 미국 콘텐츠를 만드는 것에 대해 전혀 관심이 없다.내가 말하는 것은 위키피디아의 웰컴 페이지에 트라이비아가 등장해서는 안 된다는 것이다.위키피디아에 남겨두어라 - 일부는 흥미롭지만 - 다른 곳에 두어라.내 말은, 오늘을 봐.아마도 후손들과 별도로 "레오나드 T. '맥스' 슈뢰더 주니어는 돌격선에서 노르망디에 상륙한 최초의 미군"이라는 사실은 누가 신경쓸 수 있겠는가.
B. 페어뱅 (대화) 12:17, 2009년 5월 3일 (UTC)[응답하라]
네... 기사 레너드 T. 슈뢰더는 WP를 위해 만들어졌다.주제에 관심이 있는 편집자에 의한 DYK는 피처링할 수 있는 모든 유효한 기준을 충족시켰다.하지만 왜 레오나드 T인가. 슈뢰더 기사가 오늘 특집 기사인데 서아프리카 외교관에 대한 기사가 아닌 이유는 그 기사가 아직 만들어지지 않았기 때문이다!아니면 만들어졌을지 몰라도 한두 줄짜리 스텁일 뿐인데 확대하면 되는 겁니까?다시 한 번, 메인 페이지에 보이는 콘텐츠 유형을 변경할 수 있는 쉬운 해결책이 있다.당신은 미국과 관련이 없는 특징에 대한 대체 콘텐츠를 제공해야 한다.그렇지 않으면, 우리는 그들이 관심 있는 주제에 대해 쓰기 위해 여가 시간을 할애하는 자원 봉사자들에 의해 제출되는 가능한 내용에서 벗어나게 될 것이다.AgneCheese/Wine12:41, 2009년 5월 3일 (UTC)[응답]
나는 그들이 관심 있는 주제에 대해 쓰기 위해 자유시간을 바치는 자원 봉사자들에게 어떤 이의도 가지고 있지 않다.배변(;-)이 아닌 헌신이 되는 한, "해변의 첫 얀크"의 경우처럼 말이다.자, 여러분, 여러분의 동포들이 다른 사람들에게 노출시키지 않고도 그 모든 것을 읽을 수 있는 어딘가에 여러분의 나라와 관련된 애국적인 글귀를 넣으세요. B. 페어베언(토크) 13:01, 2009년 5월 3일 (UTC)[응답하라]
위키피디아는 차별하지 않으며 "미국 전용" 또는 "비 미국 전용" 섹션이 아니라 "WP:Dids You Know, WP:In The News, WP:오늘의 특집 기사 및 WP:이 날의 섹션은 모든 인종과 국적을 망라하는 색맹이다.메인 페이지에 이르는 이 모든 섹션은 대중에게 열려 있는 문으로, 하나의 기사에 관심을 가지고 그것을 표준으로 끌어올리고 특색을 갖도록 하기 위해 오직 하나의 헌신적인 영혼만 필요로 한다.당신이 제안하는 것은 편견을 가지고 편향과 싸우고, 아직 아무도 아프리카 마을을 위한 물뿌리개를 건설하지 않은 것을 우려하기 때문에 "미국 전용" 식수대를 설치하는 것이다.명분은 고귀하지만 수단은 잘못 알고 있다.체계적 편견을 해소하기 위한 해결책은 우리의 소매를 걷어붙이고 이 과소표시된 주제들을 DYK, ITN, FAS, OTD로 가져와서 미국/영국 주제들의 집중도를 희석시키는 것이다."미국 전용" 식수대를 만드는 것은 단지 문제를 비밀에 부칠 뿐이기 때문에 이 주제의 질과 커버력을 향상시키는데 아무런 도움이 되지 않는다.이 미국 이외의 기사들은 여전히 만들어질 필요가 있다."미국의 3대" 기사를 내보낸다고 해서 미국 이외의 기사의 품질과 양이 하룻밤 사이에 마법처럼 향상되지는 않을 것이다.Agne Wine/ 13:36, 2009년 5월 3일 (UTC)[응답]

이 섹션의 형식 지정

다음 논의는 보관한다.수정하지 마십시오.후속 코멘트는 새로운 섹션으로 작성되어야 한다.

이 섹션을 읽고 있는 동안 사용자:B. 페어베언은 서식을 망치느라 바빴고, 누가 누구에게 회신하는지에 대해 대개 실마리를 주는 모든 들여쓰기를 없애고, 서명을 다시 포맷하여 훨씬 더 돋보이게 만들기에 바빴다(서명이 있는 색과 서명이 있는 모든 연극을 가지고 있었기 때문에 충분히 나쁘다고 생각했다).

왜 이러는 거야?더 예쁘다고 생각해?난 그냥 그게 짜증나.그들의 작가들이 의도한 대로 댓글을 복원해 주시겠습니까? --Hegvald (대화) 12:42, 2009년 5월 3일 (UTC)[응답]

아니, 이건 내 제안이야그 거의 모든 것에 대해 그 들여쓰기는 아무 소용이 없었다.나는 그것을 더 읽기 쉽게 만들었다.만약 네가 그것을 좋아하지 않는다면, 미안해.

B. 페어바인 (대화) 13:07, 2009년 5월 3일 (UTC)[응답하라]
진짜로, 너 블록을 얻으려고 하는 거야?당신은 토크 페이지에 사용되는 일반적인 형식을 완전히 바꾸거나, 주관적인 문제일 때 객관적으로 도움이 되지 않는 것으로 사람들을 선별하려고 노력함으로써 상당히 파괴적인 행동을 하고 있으며, 많은 사람들이 당신이 지나치게 반응하고 있다고 말한 후에도 계속해서 요점을 지적하고 있다.만약 내가 행정관이었다면, 혹은 나보다 더 대담했다면, 나는 아마도 여기서 어떤 조치를 취했을 것이다...하지만 난 아니야하지만 나는 너의 모든 헛된 일을 완전히 되돌리고 싶어. 비록 네가 그것을 되돌리고 있다는 것을 알고 있지만.♫ 멜로디아 샤콘네 ♫ (대화) 13:17, 2009년 5월 3일 (UTC)[응답하라]
둘째, 나도 같은 말을 하려던 참이었다.특히 지금 나는 섹션의 실제 렌더링된 위키텍스트(모든 쓸모없는 편집 때문에 내가 단독으로 호출해야만 했던 디프 대신)를 보고, B 페어페어가 대화의 실타래를 완전히 그리고 완전히 파괴했다는 것을 알게 된다.아노미에 13:30, 2009년 5월 3일 (UTC)[응답]

그것은 나의 제안이다.그리고 그것은 엉망진창으로 변하고 있었다.나는 내용을 삭제하지 않고 정리했다.이제 따라가기가 더 쉽다.그리고 그것을 다시 바꾸는 것에 대해서는 - 당신 자신의 제안으로 당신이 좋아하는 것을 하지만, 내 제안은 그냥 내버려 두시오.마음에 들지 않으면 보이콧하라.B. 페어베언 (대화) 13:35, 2009년 5월 3일 (UTC)[응답하라]

WP가 없는 경우:이 페이지 섹션의 형식에 대한 소유권 및 다른 편집자가 자신의 주석 및 서명을 변경할 수 있는 권한.AgneCheese/Wine13:46, 2009년 5월 3일 (UTC)[응답]
(ec) "당신의" 제안이 아니라 공동체에 속하는 논의다.당신의 편집은 개별적인 단어들을 하나도 잃지 않았을 수도 있지만, 그들은 정확히 누가 그 문자로 누구에게 회신하고 있었는지에 대한 귀중한 정보를 잃어버렸다.제발 그만해.이 토론을 계속 중단하면 편집이 차단될 수 있다.Anomie⚔ 13:54, 2009년 5월 3일 (UTC)[응답]

나는 지나가는 모든 사용자가 비건설적인 방식으로 다른 편집자의 형식을 계속 변경할 경우 B 페어바인(B Fairbann)을 되돌릴 것을 촉구하며, 지나가는 관리자라도 동일한 방법으로 블록을 발행할 것을 권고한다.감사합니다.내가 다른 사람의 코멘트를 복구하지 못했다면 사과한다. 나는 다른 방식으로 다른 코멘트를 거쳐야 했다. 그리고 나는 형식에 지장을 주지 않고 유용한 코멘트를 통합해야 했다.Anomie⚔ 13:54, 2009년 5월 3일 (UTC)[응답]

두번째 아노미님의 합리적인 요청.AgneCheese/Wine14:03, 2009년 5월 3일 (UTC)[응답]
고마워, 아노미.(페어베언의 재포맷을 다시 되돌려야만 했다.) --헤그발드 (대화) 14:00, 2009년 5월 3일 (UTC)[응답]

좋아, 얘들아 - 내가 틀렸어.잠시 밖에 있어라. 그러면 내가 원래대로 되돌릴게.B. 페어바인 (대화) 14:06, 2009년 5월 3일 (UTC)[응답하라]

됐다.이제 다 나았다.나는 지금 위키피디아에 대해 조금 더 배우고 있고 마침내 왜 사물이 있는 그대로인지 알게 된다.나는 다시는 다른 사람의 직책을 바꾸지 않도록 노력할 것이다.B. 페어바인 (대화) 14:09, 2009년 5월 3일 (UTC)[응답하라]

실행 또는 실행 안 함 - 시도 없음 =) –xenotalk 14:11, 2009년 5월 3일(UTC)[응답]
화낼 필요 없어나는 다시는 다른 사람의 포스트 서식을 바꾸지 않을 것이다.이제 우리는 나의 일시적인 어리석음을 잊어버리고 그것에 대해 더 이상 언급하지 않고 계속할 수 있다.B. 페어베언 (대화) 2009년 5월 3일 14:15 (UTC)[응답하라]
위의 논의는 아카이브로 보존되어 있다.수정하지 마십시오.후속 코멘트는 새로운 섹션으로 작성되어야 한다.

위키백과: 미국 버전: 중간 휴식 시간 동안 형식 변경 후 중단

B 페어바인, 나는 당신의 최근 코멘트를 문제 삼는다: "이리와, 여러분, 당신의 동포들이 다른 모든 사람들에게 그것을 노출시키지 않고도 그 모든 것을 읽을 수 있는 곳에 당신의 나라에 관련된 애국적인 글귀를 넣으세요."내 생각에 이것은 무슨 일이 일어나고 있는지 잘못 읽은 것 같아.사람들은 알고 있는 것과 쉽게 연구할 수 있는 것을 쓴다.그러므로, 우리는 대부분의 편집자들을 즉각적으로 둘러싼 주제를 더 잘 다룰 수 있다.

세계 다른 지역에 대한 커버리지 개선을 위한 당신의 제안은 매우 좋은 제안이라고 생각한다.다만, 미국의 커버리지 축소라는 관점에서 제시하면, 필연적으로 방어적인 반응을 일으켜 어떤 종류의 제안이라도 띄울 수 있는 능력이 저하될 것이다.사람들을 민족주의라고 비난하는 것은 그들이 당신의 생각에서 가장 좋은 것을 보게 하고 그것에 동의하게 하는 끔찍한 방법이다.꿀은 식초보다 더 많은 파리를 잡는다, 그렇지?

균형이 맞지 않는 커버리지의 해결책은 적은 곳에 더하여 밸런스를 맞추는 것이다.동기부여가 더 좋고 친숙한 세계에 대해 글을 쓸 줄 아는 사람들을 공격하는 것은 좋은 곳으로 이끌 것 같지 않다.어떻게 생각하십니까? -GTBaccus(talk) 19:49, 2009년 5월 3일 (UTC)[응답하라]

보관하십시오.

이 논의는 종결되었다.수정하지 마십시오.
다음의 논의는 종결되었다.수정하지 마십시오.

이 토론은 Z-man씨의 마지막 입장에는 전혀 도움이 되지 않는 것 같으니 보관할 것을 제안한다.
이 논의는 임의의 pxriod, 즉.x. onx day에 대해 xlinmatx에서 xxxfxrxxx를 thx Xnglish Wikipedia의 main pagx에 xx Unitxd Statxs로 제안하는 것에 관한 것이다.이러한 제안이 달성할 수 있는 xxamplxd의 xxrx mandatxd가 xxxxxxt bxxtxt bxxtxt rxtxd의 5번째 lxtxxxr를 txxxx twxnty-4번째 lxtxtxd에서 xxrxr mandquirxxd를 토론하는 경우 imaginxinxinxxxxxxxxxxxxxxxxxxxxx.bxtxxr sxxtaI itsxlf prxsxxdia의 공통 목표인 xxxx xncylopxdia의 nxxxxd 토론의 연속성에 대한 정보를 위해 txx articlxxxxxxxxxxxtics에 대한 마지막 단락의 rxfxfxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxr.Sswonk (대화) 20:04, 2009년 5월 3일 (UTC)

[답글]

이걸 보관해줘서 고마워이것은 매우 흥미로워져서 나는 여전히 우리가 위키피디아의 문화적 편견 혹은 "웹의 문화적 편견"이라고 불리는 위키피디아를 위한 새로운 기사를 시작할 수 있다고 생각한다.위키피디아인을 무작위로 선정하는 것에 의한 소수의견은 믿을 만한 출처가 될 수 없을 것이라고 나는 위에서 지적한다(좋아, 나는 통계적으로 알고 있다, 우리는 정말로 무작위 샘플을 구성한다). 그러나 만약 우리가 웹에서 문화적 편견을 위한 구절을 찾을 수 있다면, 다른 웹사이트만 하더라도, 이것이 위키피디아에 대한 새로운 기사의 씨앗이 될 수 있다.그래도 한마디 해도 될까?B. 페어바인은 이 주제를 제기하는 데 있어서 미국 중심의 편견을 언급하는 것처럼 보였지만, 예를 들어, 나는 내 조국, 영국이 스웨덴이나 핀란드보다 영어 위키백과에서 더 나은 커버리지를 얻을 것이라고 확신하고 있다.유럽이나 북아메리카를 제외한 다른 나라들만약 우리가 통계를 낼 수 있다면, 이것은 확실히 내가 가치 있는 대답을 만들 수 있을 것이다.솔로몬 제도에 얼마나 많은 취재가 이뤄지는지 관찰하지 못했다는 사실을 고백해야겠습니다.ACEOREVIVEED (토크) 21:25, 2009년 5월 6일 (UTC)[응답]


물론 사람들은 자신이 알고 있는 것과 관심 있는 것에 초점을 맞추고 있으며, 기사를 기고하는 미국인들일수록 미국 관련 기사가 더 많이 등장한다.그리고 다른 나라들에도 행사와 사람들에 관한 기사가 있고, 이것들 중 상당한 비율 또한 미국 시민들에 의해 기고될 가능성이 있다.나를 놀라게 하는 것은 미국 관련 자료가 훨씬 덜 흥미로운 사건들과 사람들에 관한 것이라는 점이다.오늘의 DYK 섹션을 보면 다음과 같은 이야기가 있다.

  • 1805년 해전
  • 주 의회에서의 법질서(적합한 정도) 논쟁 중에 일어난 배터리 행위
  • 유럽 왕의 측근에 관한 이야기
  • 2009년 텔레비전 영화에 대한 리뷰와 그것을 둘러싼 논란
  • 5년도 안 돼 4계급 오른 병사에 대한 기사(최고병사 콜린 파월도 17년이 걸려서 같은 일을 했다)

그리고

  • 캘리포니아에 있는 라디오 방송국에 관한 기사는 아무것도 없다.
  • 지하에 임시 거처가 있는 뉴욕의 한 유대교 회당에 관한 이야기
  • 미국의 한 라디오 쇼 방송에 관한 이야기

아마도 더 주목할 만한 미국의 관심 품목은 이미 다 다루어져 있었고, 미국 기부자들은 쓸 만한 것들을 찾느라 골머리를 앓는 채로 남아 있었을 것이다... B. 페어베언 (대화) 09:30, 2009년 5월 7일 (UTC)[응답]

기록에 의하면

이 논의에 활력을 불어넣을 위험을 무릅쓰고 WP는 다음과 같은 점을 지적하고 싶다.DYK/N은 다음과 같이 말한다.

"주: 제안 페이지에 있는 후크의 평균 약 50%가 미국 관련이기 때문에, 일반적으로 미국 주제에 대한 특정 업데이트에 후크를 절반 정도 두는 것이 적절하다. 고마워

DYKers가 이것에 주목하고 있다고 가정하면, 그것은 미국 상품의 일관된 외관을 설명할 수 있을 것이다.망고 (토크) 21:18, 2009년 5월 7일 (UTC)[응답]

그러나... 단지 그들이 미국에서 왔다고 해서 그들이 미국에 관한 기사만을 기고해야 한다는 것을 의미하지는 않는다 - 대부분의 미국 시민들이 관심을 갖는 것이 아니라면 말이다.해외여행을 떠나는 미국 시민의 수와 해외로 나가는 미국의 대외원조 규모를 고려하면 대부분의 미국 시민이 미국에만 관심을 갖지는 않을 것으로 보인다.단지 미국을 홍보하기 위해, 그리고 그들 스스로 기분 좋게 만들기 위해 이런 짓을 하지 않는 한. :- (부적절한 제안이나 부적절한 논평은 제발) B. 페어베언 (토크) 22:49, 2009년 5월 7일 (UTC)[응답]

파리에서 일주일간 휴가를 보내는 것과 그것에 관한 특집기사를 쓰기 위해 파리의 한 아로니션의 역사를 연구하는 것 사이에는 흥미 수준에서 큰 차이가 있다.DYK에 대한 노트에 대해서는, 나는 그것이 사람들이 미국에 대해 더 많이 쓰도록 장려하기 위해서가 아니라, 그것을 운영하는 사람들이 미국 관련 기사로 전체를 채우지 않기 위해서라고 추측한다.미스터 지맨 06:15, 2009년 5월 8일 (UTC)[응답하라]
그것은 적어도 두 번째고, 아마도 세 번째, 나는 당신이 편집자들이 오로지 "나라를 홍보한다"거나 "그들에 대해 기분이 좋아지게 하기 위해" 미국 관련 주제에 대해 쓴다는 것을 넌지시 암시했을 것이라고 생각한다.수많은 편집자들을 모욕하지 마라. --골베즈 (대화) 06:19, 2009년 5월 8일 (UTC)[응답하라]
내가 아무데서나 '솔직하게' 말했어?아니면 내가 '솔직히'를 제안했는가?아니면 마음 속에만 있는 것일까.어떤 경우든 나는 그들을 (미국 편집자들이 아니라) 너를 모욕하는 것처럼 보인다.그들 중 누구도 나서서 불평하지 않았다.아마도 그들은 비판을 받아들일 만한 성숙함을 가지고 있을 것이다.불행히도 그러지 마 B. 페어베언 (대화) 09:29, 2009년 5월 9일 (UTC)[응답]
당신은 내가 DYK와 POTD에 대해 한 5건의 제출 때문에 미국 관련 업무를 DYK, TFA, POTD에 기고했던 수천 명의 편집자들을 모욕하고 있다. 그 중 하나는 분명히 당신에게 너무 많은 것 같다.다른 사람들이 당신의 모욕에 대해 알지 못한다는 것은 그것이 모욕적인 것이 아니라는 것을 의미하지 않는다. (그리고 나는 이 토론에서 당신의 조롱하는 어조에 대해 당신에게 불평한 적어도 세 명의 사람들을 셀 수 있다. 더 많은 사람들이 필요한가?)또한, 사람들에게 "부적절한 제안이나 코멘트를 하지 마십시오."라고 말하지 마십시오. 위키백과 정책에 따라 코멘트가 허용되거나 그렇지 않은 경우.당신은 다행히 어떤 종류의 응답을 받을 수 있는지 지시하지 않는다. --골베즈 (대화) 21:41, 2009년 5월 9일 (UTC)[응답하라]
그래, 네가 "..."라고 했을 때 네가 제안했었지.그들은 단지 미국을 홍보하고 그들 스스로 기분 좋게 만들려고 노력하기 위해 이런 일들을 한다."(내 것을 강조함).미스터 지맨 2009년 5월 9일 (UTC) 13:47[응답]
그래, 네가 날 거기 데려갔어. 'just'라는 단어는 사용하기 좋은 단어가 아니었어.차라리 '...대부분의 광고는...'B.페어밴(토크) 05:38, 2009년 5월 10일 (UTC)[응답]이라고 말하는 편이 나았을 것이다.

스트라이프 & 스타즈

이 논의는 종결되었다.수정하지 마십시오.
다음의 논의는 종결되었다.수정하지 마십시오.

작은 일례로, 나는 왜 미국 국기에 줄무늬가 있는지 궁금했다.어떤 연구는 13개의 줄무늬가 있으며, 그것들은 영국 아메리카의 일부였고 후에 미국이 된 13개의 영국 식민지를 나타낸다.물론 50개의 별은 50개의 현재 주를 나타낸다.콜롬비아 특별구는 대표되어 있지 않다.
내가 보기엔 줄무늬가 깃발 위에 남아 있는 것은 특이하게 보인다. 각 줄무늬가 영국의 과거 식민지를 상징하기 때문이다.나는 "세금 없이는 대표할 수 없다"는 외침에서 예시된 것처럼 미국이 영국으로부터 탈피하고 싶다는 인상을 받았다.50개의 별들만이 더 적절하지 않을 것이다. B. 페어베언 (대화) 09:29, 2009년 5월 9일 (UTC)[응답]

그들이 13개의 원래 주를 대표한다고 말하는 것은 좀 더 정확할 것이다.이전에 이런 것들이 식민지였던 것은 사실이지만, 영국을 탈피해 미국 독립전쟁에 맞서 싸운 것도 바로 이들인 것도 사실이다.한 나라가 그 나라를 실제로 만든 사람들을 공경하는 것은 타당해 보인다.—JAO • T • C 09:43, 2009년 5월 9일 (UTC)[응답]
그럴 만도 하다.나는 줄무늬가 영국이 형성한 식민지가 아니라 분리된 식민지를 나타낸다고 본다.여전히 깃발은 줄무늬가 없다면 미적으로 더 즐거울 것이다. 하지만 물론 깃발이 다시 바뀐다면 말 그대로 수천 개의 깃발을 교체해야 할 것이다.나는 그 문제에 대한 어떤 연구도 알지 못하지만 세상에 다른 모든 국기들을 합친 것보다 더 많은 미국 국기가 있는 것 같다. B. 페어바인 (대화) 09:45, 2009년 5월 9일 (UTC)[응답]
나 역시 놀라지 않을 것이다.나는 국기 제작자들이 1959년과 1960년에 좋은 시간을 보냈다고 생각한다.—JAO • T • C 10:41, 2009년 5월 9일 (UTC)[응답]
그들이 곤경에 빠지지 않게 하기 위해 주위에 충분한 일이 있었을 것이다!
다시 현재 주제로 돌아가자: 편집자, 훨씬 더 많은 사람들이 살고 있고, 내부보다는 미국 밖에서 훨씬 더 많은 사건들이 일어난다.네가 해야 할 일은 시야를 넓히는 것뿐이야.B. 페어밴 토크 10:46, 2009년 5월 9일 (UTC)[응답]
누구더러 시야를 넓히라는 거야?일반적으로 편집자, 또는 TFA, DYK, ITN 등에 대해 어떤 일이 일어나는지 선택하는 사람들? --골베즈 (토크) 06:06, 2009년 5월 10일 (UTC)[응답]
나는 일반적으로 편집자들에게 A. B. Fairbann Talk 06:18, 2009년 5월 10일 (UTC)[답답답]의 좋은 '올 US'에 초점을 맞추는 것을 그만두라고 부탁하고 있다.
청혼을 하십시오.너는 주제에서 벗어나서 방해받고 있다.메인 페이지를 관리하는 편집자에게 규칙을 적용하자고 제안하시겠습니까?그럴 순 없어규칙이 뭔지도 확실하지 않다.일년 중 하루가 미국 아닌 날이 되길 바라니?이것은 이상하고 무의미하다.당신은 편집자들이 매일 미국/다른 세계의 동등한 보도 범위를 주의 깊게 검사하기를 원하십니까?일이 너무 많다.너의 제안은 무엇이니?–MT 07:22, 2009년 5월 10일 (UTC)[응답]

나는 처음에 위키피디아가 국제적인 현상이라는 인상을 받았다.내가 그 사이트를 더 사용하기 시작하면서 나는 위키피디아에 온 웰컴 페이지에는 항상 다양한 나라의 이야기들이 있고, 미국에 현지인 이야기가 하나 이상 있다는 것을 주목했다.위키피디아 웰컴 페이지에는 왜 항상 미국 이야기가 나오는지, 왜 미국 이야기 중 하나 이상이 사건이나 인물의 중요성 면에서 일반적인 기준이 되지 않는지 궁금했다.위키피디아가 미국인에 의해 주로 통제되고, 운영되며, 기여하고 있다는 것이 곧 명백해졌다.
위키피디아를 적어도 1면에 관한 한, 더 국제적인 것처럼 보이게 하는 것에 대한 관심에서, 나는 페이지에 있는 미국 콘텐츠가 줄어들 수 있는 어떤 방법이 있는지, 아니면 하루만이라도 삭제될 수 있는 방법이 있는지 궁금했다.나의 제안은 가능하다면 이것을 성취할 방법을 찾고 있었다. (Welcome to Wikipedia 페이지에서 예외적으로 사소한 미국 항목은 제외)
그 이후로 이것은 불가능하다는 것이 명백해졌다.위키피디아 환영 기사를 즐겨 읽는 비미국 사용자들은 웰컴 페이지의 사소한 미국 이야기들을 계속 무시해야 할 것이며, 동료들/친구들/관계자들이 겉으로 드러나는 미국의 초점이나 편향에 의해 외면당하지 않도록 충고해야 할 것이다.
오해하지 마십시오. 미국은 환상적인 나라로서, 일각에서 지적하듯이, 세계에서 가장 부유한 나라, 남아 있는 유일한 초강대국, 자유와 평등의 땅, 다른 모든 국가들이 따라야 할 올바른 모범을 보이는 나라가 된 비교적 젊은 나라다.훌륭한 일이지, 하지만 잠시 후에 다른 나라 사람들이 미국의 만능주의에 질릴 수 있어.B. 페어밴 토크 11:52, 2009년 5월 10일 (UTC)[응답]

그럼 제안이 없다는 거야?해피멜론 19:19, 2009년 5월 10일 (UTC)[응답하라]
이 섹션의 논의가 효과적으로 종료되었기 때문에, 이것은 더 이상 관련 질문이 아닐 수 있다.–MT 19:27, 2009년 5월 10일 (UTC)[응답]
메인 페이지는 주로 미국 거주자들이 개발한 것으로 보인다.아마도 메인페이지에서 활동하는 그룹에 가입하여 미국 이외의 좋은 콘텐츠를 기부함으로써 당신은 상황을 흔들 수 있을 것이다.우리가 편견을 줄이는 방법을 개발하지 못한 것은 유감스러운 일이다.–MT 19:27, 2009년 5월 10일 (UTC)[응답]
해결됨
– 구현 및 시행이 불가능하고 제안자가 철회함. –MT
보관할 수 있도록 이 절에서 주석을 달지 마십시오.

감시 목록 알림

우리는 "새로운 메시지가 있다" 배너와 비슷한 통지를 가져야 한다.다음과 같은 경우:

감시 목록에서 하나 이상의 페이지가 편집됨(감시 목록 보기)

-- IRP ▷인터뷰 03:00 (UTC) 2009년 4월 27일 (화)[응답]

하지만 이것은 가장 짜증나는 일일 것이다.새 메시지 배너는 지금 나를 짜증나게 하고, 드문 일이다.♫ 멜로디아 샤콘네 ♫ (토크) 11:24, 2009년 4월 27일 (UTC)[응답하라]

배너 옵트 아웃 기능

배너가 성가시다면, 사용자들이 감시 목록이나/또는 새로운 메시지 배너를 선택할 수 있는 옵션이 있어야 한다. -- IRP ▷인터뷰 20:32, 2009년 4월 27일 (UTC)[응답]

watchlist의 페이지를 편집할 때 "새로운 메시지가 표시됨" 경고와 유사한 경고가 있어야 한다(단, 선택적 기능이어야 함).예를 보려면 "표시"(위)를 클릭하십시오.누가 이 제안을 지지하거나 반대하는가? -- IRP ☎ 00:30, 2009년 4월 28일 (UTC)[응답]

이 제안은 (원래) 이 섹션을 시작한 제안과 대부분 관련이 없기 때문에 숨겨졌다.그것이 어떻게 구현되었느냐에 따라, 만약 그것이 구현된다면, 다른 것을 구현하는 것이 반드시 쉽다는 것을 의미하지는 않을 것이다.이들 중 하나를 핵심 소프트웨어에 구현하는 것은 중대한 변화가 될 것이며, 특히 곧 일어날 것 같지는 않다(만약 누군가가 지금 일을 시작한다면, 나는 영구적인 감시 목록 제안과 유사한 이유로 한 달을 절대 최소로 말할 것이다).지금 당장 감시목록 시스템은 다소 간단하다.여기서 만들어진 제안들 중 일부를 포함한 대부분의 제안들은 큰 변화가 될 것이다.Mr.Z-man 01:48, 2009년 4월 28일 (UTC)[응답]
가장 간단한 방법은 소프트웨어의 변경 대신 그것을 위한 .js 파일을 만드는 것이다(위의 제안서와 같다).-- IRP 인터뷰 02:59, 2009년 4월 28일 (UTC)[응답]
감시 목록에 있는 기사가 몇 개 이상 있는 사람이라면 정말 비실용적일 것이다.나는 항상 큰 오렌지 바를 가지고 있지 않기 때문에, 나는 분명히 탈퇴할 것이다.과연 얼마나 많은 사람들이 이런 기능이 도움이 될지 궁금하다.라디오프샬롯 04:13, 2009년 4월 28일 (UTC)[응답]

나는 내 감시 목록에 2,861개의 아이템을 가지고 있는데, 그것은 백과사전을 간단하게 훑어보는 것을 거의 불가능하게 만들 것이다.감시 목록에 있는 페이지 중 하나가 편집되었는지 알고 싶으시면...감시 목록을 확인해봐EVULA // talk // talk // 17:59, 2009년 5월 2일 (UTC)[응답]

그건 정말 급진적인 생각이야 EVULA...그건 차치하고라도 나 또한 내 감시 목록에 1,554개의 항목이 있기 때문에 거절할 것이다.솔직히 50개 이상의 아이템을 가진 사람은 이런 걸 고려해도 볼 수가 없어...Talk아일랜드인 22:23, 2009년 5월 2일 (UTC)[응답]
아마도, 당신은 이 배너에 어떤 아이템이 들어있을지 선택할 수 있을 것이다.그래도 짜증날 것 같아, 윈들러가 12시 45분, 2009년 5월 7일 (UTC)[응답하라]
좋은 생각이야.지난 3일 동안 800여 개의 변화로 인해, 나는 각 페이지 로드는 아니더라도 각 편집에 이 메시지를 삽입할 것이라고 생각한다.이것은 비록 이것을 기기로 하는 것이 좋고 내 사용자 공간과 같은 것에 대한 파괴 행위를 확인하기 위해 확실히 이것이 필요하지만, 많은 수의 활성 편집자들에게는 확실히 실현 불가능할 것이다.—Admiral Norton 17:13, 2009년 5월 8일 (UTC)[응답]

현수막은 끔찍해, 하루에 20번 정도 일어날 것 같아. 그리고 나는 비교적 적은 수의 감시 목록을 가지고 있어.WP를 시청하는 사람들을 위해:A등. 악몽이 될 것이다.옵트 아웃이 가능해야 할 것이다.하지만, 나는 거의 같은 일을 하고 그것에 대해 신중한 이 훌륭한 도구를 사용한다.╟-TreasuryTag►contribes-17:37, 2009년 5월 8일 (UTC)[응답]

이런 종류의 특징은 기본적으로 사람들이 포함되지 않는 옵트인 시스템과 함께 하는 것이 더 나을 것이다.또는 페이지당 작동하도록 하고, '시계'와 '진짜 시계' 버튼을 두십시오.칠음 17:40, 2009년 5월 8일 (UTC)[응답]

태그라인

MediaWiki 편집 지원자 또는 반대자:태그라인? -- IRP ▷인터뷰 19:54, 2009년 5월 8일 (UTC) [응답]

나는 그것에 반대할 것이다.내 걱정은 만약 평범한 독자가 위키피디아 페이지를 훑어보고 있는데, 그들이 모든 페이지의 맨 위에 '위키피디아'라는 파란색 링크를 본다면, 그들은 아마 그것이 홈 페이지로 연결되는 링크라고 생각할 것이다.그들을 위키백과에 관한 위키백과 기사로 데려가는 것은 그들에게 조금 혼란스러울 수 있다.Tra(Talk) 20:08, 2009년 5월 8일 (UTC)[응답]
Tra의 의견에 동의하십시오.그 메시지는 자기 참고사항이다; 기사와의 연계를 통해 그것을 '내용화'하는 것은 혼란스러울 뿐이다.사람들이 기사를 접할 때까지 위키피디아가 무엇인지 모른다면, 우리는 정말로 곤경에 처하게 된다. 해피멜론 20:23, 2009년 5월 8일 (UTC)[응답]
나는 HM과 Tra의 의견에 동의한다.그것은 불필요하다.미스터 지맨 20:27, 2009년 5월 8일 (UTC)[응답]
모두의 의견에 동의하라.변화를 반대하다.╟-TreasuryTag►contribes-20:38, 2009년 5월 8일 (UTC)[응답]
나도 동의해; 우리는 어디에나 링크가 필요하지 않아.EVULA// talk // talk // 20:40, 2009년 5월 8일 (UTC)[응답]
여기 같은 느낌.—DJ (대화 • 기여) 21:04, 2009년 5월 8일 (UTC)[응답]
해결됨
– 합의는 거절이었다. –MT

검색창!!

위키백과의 유일한 목적인 위키백과, 사람들이 필요로 하는 것을 빨리 찾을 수 있도록 위키백과, 앞쪽과 가운데(위)에 매우 유용한 기능을 제안하고 싶다.그 기사들은 좀 더 두드러진 검색대를 위해 내려갈 여유가 있다.웹 개발자가 되기 위해서는 궁극적인 목표인 사용자를 위한 ui를 만드는 것이 중요하다.왼쪽의 작은 컬럼 검색대를 찾아 키워드를 입력하는 것은 짜증나는 일이다.나는 네가 이 문제를 해결해서 지금까지 만들어진 최고의 웹 자원을 더 잘 만들 수 있기를 바란다.—173.73.168.77 (대화) 02:59, 2009년 5월 4일 (UTC)[응답]이 추가된 미서명 코멘트 준비

글로벌 인터페이스에서 검색대를 옮기는 데 큰 지지를 받지는 못할 것 같지만, 이런 일을 할 수 있는 스킨이나 자바스크립트가 있을 수 있다.–xenotalk 13:33, 2009년 5월 4일 (UTC)[응답]
나는 wp 인터페이스가 편집자들, 특히 새로운 사람들이 사용하기에 매우 고통스러운 이유들 중 하나가 '스킨스나 js를 사용할 수 있다'는 반응이라고 생각한다.그렇기는 하지만, 만약 그녀가 기사 제목 위에 큰 텍스트 상자를 넣는 것에 대해 말하고 있다면, 이것은 무지하거나 나쁜 생각이다.나는 그것이 항법 위로 이동되어야 한다는 것에 동의한다. 또는 오른쪽 위로 이동되어야 한다는 것에 동의한다.–MT 05:03, 2009년 5월 5일 (UTC)[응답]
나도 동의해, 위키피디아의 목적은 당신이 찾고 있는 것을 찾는 것이 아니라, 당신이 찾고 있는 것에 대해 읽는 거야.검색창에 기사 텍스트보다 더 부각시켜서는 안 된다.미스터 지맨 2009년 5월 9일 (UTC) 13:52 (응답)
해결됨
– 의견 일치: 각 기사의 맨 위에 있는 검색창은 사람들이 위키백과를 사용하는 데 도움이 되지 않을 것이다. –MT

인라인 인용 번호 지정을 위해 글꼴 크기 작게 만들기

나는 비교적 실행하기 쉽고 우리 기사의 가독성과 시각적 매력을 향상시킬 수 있는 매우 간단한 제안서를 가지고 있다: 인라인 인용 부호를 위한 글꼴 크기를 줄이는 것이다.[1][2]마지막 문장과 현재 문장의 끝에 있는 저 크고 못생긴 숫자들 말이야.[3][4]우리[5] 모두는 인용구를 좋아하지만, 현재의 숫자 지정은 너무 커![6]현대 위키백과 기사에 기대되는 참조의 밀도와 함께, 문장의 끝에 있는 여러 노트, 그리고 그 가운데에[7] 있는 노트의 끝없는 축적이 눈에 띄지 않게 되고 있다.[8]위첨자 숫자들은 크고 막힘이 많아서 글들이 지저분해 보이고 각각의 문장이 이웃들과 멀리 떨어져 있는데, 이는 흐르는 산문을 미묘하게 방해하는 효과다.[9]아이러니하게도 기사 참조가 서툴수록 더 훌륭하고 품위가 있고 전문적으로 보이는 반면 참조가 잘될수록 기사는 추악해지고...그리고 영주님, 삼배는 말할 것도 없고 두 자리 숫자가 될 때쯤이면 정말 고약해 보이십니다.[10][11][12]예를 들어, 이 문장은 이전의 문장과는 거리가 멀다. 어떤 문장이든...거의 1인치 정도 떨어진 곳이라고 말할 수 있지 않을까?[13][14]더 나쁜 것은, 당신은 특집 기사 수에서 훨씬 더 끔찍한 예들을 찾을 수 있다는 것이다...우리 콘텐트에 가장 좋은 쇼피스로 여겨지는 [15]물건들왜 우리의 최고의 작품이 가장 추해야 하는가?[16]파란색 큰 숫자의 세 자리 블록을 네 배로 쌓았고, 한 단락의 중간에도 쌓았다.[17]아야.[18]

나는 많은 오랜 시간 동안 편집자들이 그들이 표현하는 것, 즉 백과사전 작업에서[19] 진지함과 정확성에 대한 참조 태그를 보게 되었고, 이것이 그들이 못생긴 글들이 이 못생긴 블록버스터에 완전히 빠져있을 때 어떻게[20] 되는지를 서서히 보지 못하게 되었다고 생각한다.[21]캐주얼 WP 독자들로부터 이 주제에 대한 몇 가지 코멘트를 본 적이 있는데, 이것이 내가 이 제안을 하게 된 계기가 되었다.[22][23]

어쨌든, 해결책은 간단하다: 숫자를 훨씬 더 작게 만드는 것이다.[24]우리는 가독성에 대해 걱정할 필요가 없다. 왜냐하면 상당히 작은 크기에서도 가독성은[25] 여전할 것이기 때문이다. 그리고 어쨌든 접속/비전 문제가 심각한 사람은 이미 브라우저에서 더 높은 줌 레벨을 사용하고 있을 것이기 때문이다.[26]더 작은 숫자가 통하지 않는 강력한 기술적 이유가 없는 한, 이것은 충분히 쉽고 명백하며 논란의 여지가 없는 개선으로서 가능한 한 빨리 이루어져야 한다고 생각한다.[27][28][29][30][31]— Mr. IP 《열린 편집의 정의》 23:32, 2009년 5월 5일 (UTC)[응답]

추신. 정말 큰 발전을 위해서, 어느 곳에서도 어떤 대가를 치르지 않고, 우리는 또한 불필요하게 모든 숫자를 둘러싸고 있는 작은 괄호들을 제거할 수 있었고, 슬래시나 대시 같은 이웃 도시들을 서로 구별할 수 있는 더 낫거나 덜 거슬리는 방법을 찾을 수 있었다.

참고 자료

  1. ^ 내 말은, 왜 이렇게 숫자가 커야 하는 거지?
  2. ^ 그들은 지옥처럼 못생겼고, 너무 눈에 띄어서, 그들이 그 기사의 실제 텍스트보다 더 빛나고 무색하게 한다.
  3. ^ 크다.
  4. ^ 못생겼다.
  5. ^ 위키피디아 사람들처럼..
  6. ^ 크기는 반 정도 될 수 있지만 그래도 너무 클 수 있어
  7. ^ 얼마나 못생겼는지 봐, 문장 중간에 앉아 있어.
  8. ^ "보기글"은 "읽을 수 없는" 것이 더 비슷할 때 절제된 표현이다.
  9. ^ 이런 이유로 우리는 일반적으로 참고문헌을 원문으로 쓰는 방식을 개혁해야 하지만 그것이 훨씬 더 높은 순서다.
  10. ^ 그렇게
  11. ^ 젠장
  12. ^ 못생겼다.
  13. ^ 1인치도 안되지만 가까이 있어
  14. ^ 두 개가 한 개보다 낫기 때문에 다른 언급이 있다.
  15. ^ 많은 FA들은 이 이야기에서 모든 예쁜 사진들에도 불구하고 그저 단순한 흉물일 뿐이다.
  16. ^ 사실, 우리의 최고의 작품들이 우리의 가장 못생긴 작품일 이유는 없다.
  17. ^ 비록 거대한 숫자의 블록이 "전혀 흐르는 산문을 억제하지 못한다"고 해도, 그들은 확실히 유창한 독서를 막고 있다.
  18. ^ 나는 TA MOVE IT MOVE IT MOVE IT를 좋아한다.
  19. ^ 가끔.
  20. ^ 이런 종류는 최악이다. 빌어먹을 문장 중간에 있는 구절들, 중간 단어의 바로 뒤에, 구두점이 없고, 아무것도 없다.
  21. ^ "Ungly Blocky Blues" — Sleippy John Estes, 1935.
  22. ^ 독자들은 이런 빌어먹을 것들을 싫어한다.
  23. ^ 하나 더 먹어!두 배로 못생겼어!
  24. ^ 훨씬 더 작다, 심각하다.
  25. ^ 그리고 어쨌든 글의 가독성에 비해 숫자의 가독성이 얼마나 중요한가?
  26. ^ 아니면 안경.
  27. ^ 나는 분명한 기술적 장애는 없었으면 좋겠어, 그렇게 되면 이 모든 직책이 무효가 될 테니까.
  28. ^ 하지만 있다 하더라도, 해결책에 시간을 투자하는 것은 가치 있는 일일 것이다.
  29. ^ 잠깐, 내가 위키피디아의 명백한 개선이 논란의 여지가 없을 거라고 제안했었나?
  30. ^ 인라인 인용 숫자가 더 커야 하는 이유를 지금 생각해보고 있는 사람은 아마 16명일 것이다.
  31. ^ 왜냐하면...BLP 고민!

댓글

  • 기술적으로 MediaWiki를 수정하여 가능:참조 링크 및 관련 메시지를 인용하십시오.참조 링크를 얼마나 작게 원하십니까?[current 0.8em][0.7em][0.6em][0.5em] 링크를 분리하기 위해 무엇을 사용하십니까? -- - Gadget850 (Ed) 01:40, 2009년 5월 6일 (UTC)[응답]
    개인적으로, 나는 브래킷만 제거하면 훨씬 더 예쁘게 만들 수 있을 거라고 생각해.나는 사이즈에 문제가 없다.위에서는 여전히 한 음과 다른 음을 구별하기가 쉽고, 다른 매체(책, 저널, 논문)에서는 각주를 괄호 없이 숫자로만 처리한다.쿨3 (토크) 01:47, 2009년 5월 6일 (UTC)[응답]
    응답해줘서 고마워.나는 두 번째 "1 2 3" 글꼴 크기, 또는 더 작은 "mite"가 거의 완벽할 것이라고 생각한다.대시가 리프를 분리하는 가장 좋은 방법일 것 같은데, 확실하진 않아.미스터 IP 《열린 편집의 정의》 02:11, 2009년 5월 6일 (UTC)[응답]
  • 반대: 화면 크기에 따라 달라진다.각주가 얼마나 거슬릴 수 있는지는 이해하지만, 내 자신의 화면과 적절하지만 완벽한 시력으로는 사팔뜨기 없이 구별할 수 있는 적당한 크기일 뿐이다.그리고 대괄호는 한 구역 내의 각주(예: 표에 대한 각주)나 지수적인 힘과 같은 다른 것들과 구별된다.내가 [대괄호]와 결혼했다는 것은 아니다. 누군가가 같은 일을 하는 좀 더 심미적인 것을 발견한다면, 물론 그것은 좋을 것이다. (현재의 형식에 대한 한 측면의 이점은 누군가가 위키피디아에서 복사하여 붙여넣었을 때 다른 곳에서는 꽤 확실한 선물이라는 것이다.)—— Shakescene (대화) 05:17, 2009년 5월 6일 (UTC)[응답]
  • 반대야, 만약 깨지지 않았다면...또한 괄호들은 더 큰 마우스 표적을 제공함으로써 사용성을 향상시킨다.국수 간식 (토크) 06:30, 2009년 5월 6일 (UTC)[응답]
  • 사용적합성을 이유로 반대한다. .참고문헌{font-size:80%;}스타일시트는 최소한 크기를 조정할 수 있다. - Jarry1250 12:02, 2009년 5월 6일(UTC)[응답]
  • 이렇게 인용문을 다시 포맷할 수 있다면 그에 대한 지지가 있을 것인가?1, 5, 12, 42, 255그럴 수도 있겠지.해피멜론 13:04, 2009년 5월 6일 (UTC)[응답]
  • 나는 안경을 쓰더라도 작은 글씨를 읽는 데 문제가 생기기 시작하는 사람으로서 이것을 지지한다.왜? 왜냐하면 숫자를 실제로 읽을 필요가 거의 없기 때문이다.내가 각주: 호기심 많은 역사 (페이퍼백)를 읽지는 않았지만,[1] 나는 그것이 초기 각주가 숫자가 아니라 단지 상징이었다는 것을 지적할 것이다.글쓴이는 독자가 본문의 기호를 페이지 하단이나 작품의 끝에 있는 해당 기호로 추적할 수 있도록 작은 세트의 고유한 기호를 사용했다.내가 어디로 가고 있는지 알고 있을 거라고 확신해. 바로 그 개념은 하이퍼링크의 개념보다 앞서고, 하이퍼링크를 사용할 때는 기술적으로 불필요해.우리는 하나의 공통(작은) 기호를 사용하여 참조를 나타낼 수 있다.참조를 보고자 하는 사람은 기호를 클릭하기만 하면 된다.나는 제안서의 수정안을 제안하는 것이 아니라, 숫자가 유용한 경우도 있다. 때때로, 나는 참조 목록을 읽고 참조가 지원하는 것이 무엇인지 살펴본 적이 있다. 따라서 하이퍼링크를 쉽게 되돌릴 수 있는 방법이 없는 한, 고유한 각주에 가치가 있으며, 숫자는 유용한 선택이다.내 요점은 그 숫자가 읽을 필요가 없고 단지 독자들이 클릭할 수 있을 정도로 충분히 커야 한다는 것이다.만약 독자가 정말로 숫자를 알고 싶다면, 드물게 원하는 경우, 독자는 글꼴 크기를 늘릴 수 있다.나는 괄호 제거에 찬성하지 않는다.단어를2 보면 "참고"가 아니라 "단어 제곱"이라고 생각한다.그러나 그것을 덜 거슬리게 하는 다른 방법이 있을지도 모른다.스필브릭 (대화) 13:17, 2009년 5월 6일 (UTC)[응답]
    특히 하이퍼링크가 없는 매체에서 각주 기호는 링크의 두 끝을 고유하게 식별해야 한다.책과 같은 페이징 미디어에서는 페이지를 넘길 때마다 설정된 기호를 '재설정'할 수 있으며, 따라서 의미적 의미 손실 없이 동일한 작은 기호의 집합을 여러 번 재사용할 수 있다.위키백과 같은 비포장 매체에서는 (아직 인쇄가 가능하여 하이퍼링크 기능을 사용할 수 없음) 불가능한 것으로, 각주 마커는 각각 고유해야 한다.
    모든 것을 괄호로 묶는 것은 어떨까?그럼, 이거 말고,[1][5][12][42][255] 이거 알아들었어?[1,5,12,42,255]해피멜론 13:58, 2009년 5월 6일 (UTC)[응답]
우리가 그렇게 할 수 있을지 모르겠어.나는 이것이 어떻게 조합되는지를 살펴보았다. 나는 User:Gadget850/Cite 메시지또한 참고문헌과 연계하여 {{rp}}을(를) 사용하는 것도 고려할 필요가 있다.---— Gadget850 (Ed) 15:23, 2009년 5월 6일 (UTC)[응답]
그것은 확실히 Javascript로, 어쩌면 현대 브라우저를 위한 CSS로 할 수도 있고, 혹은 그것에 대한 지원이 있다면 확장 자체로 할 수도 있다.해피멜론 14:43, 2009년 5월 6일 (UTC)[응답]
괄호를 제거하거나 변경할 수 있고 Cite 참조 링크를 편집하여 글꼴 크기를 변경할 수 있지만, 여러 인라인 인용 링크를 cite.php를 변경하지 않고 기호로 묶을 수 있는 방법은 없을 것 같다.메세지로 우리가 하는 모든 일은 전세계적이 될 겁니다.개폐 기호를 정의하는 클래스를 추가할 수 있을까? -- - Gadget850 (Ed) 15:23, 2009년 5월 6일 (UTC)[응답]
CSS를 사용하면 한 참조가 다른 참조(형제 + 선택기)를 따라가는 시점을 감지할 수 있다.그런 다음 "후" 선택기를 사용하여 "분리 기호"를 추가할 수 있다.불행히도 IE6과 IE 7에서 중단될 것이다. —DJ (대화 • 기여) 2009년 5월 6일 (UTC)[응답]
  • 반대 아마도 약간의 크기를 조정할 수 있지만 읽을 수 있어야 한다.또한, 정사각형 괄호는 심지어 인쇄물에서도 각주를 위한 매우 오래된 표기법이다.한 쌍으로 그 시간을 결합하는 것은 성능에 영향을 미치지 않고 수행될 수 있는 한 문제가 될 것이다. — Edokter • Talk • 15:34, 2009년 5월 6일 (UTC)[응답]
  • 반대한다. 우리는 그것들이 필요하다. 그리고 그것들을 더 작게 만드는 것은 그들을 클릭하기 어렵게 할 것이다.괄호는 클릭하기 쉽고 사물을 알아보기232425 쉽게 한다.자바스크립트를 이용해 어딘가에 버튼 하나를 추가하면 돼–MT 02:59, 2009년 5월 7일 (UTC)[응답]
  • 원금 지원 - 그러나 위의 두 가지를 모두 수용할 수 있는 쉬운 방법이 있어야 한다.EG: 나는 쥐를 좋아하는 사람이 인용하는 곳에 불을 켰어 - 나는 그것들이 모두 단지 위첨자 크기의 별자리라면 더 기쁠 거야.
  • Shakescene당 포괄적인 변경(js 수정 지원)을 반대한다.의학적인 이유를 제외하고, 나는 그것을 덧붙여야만 한다. 하지만 그 텍스트는 IE에서 크게 보일 수 있지만, 파이어폭스에서는 더 작고 읽기 힘들다. 그리고 나 같은 많은 사용자들은 작은 점과 콤마를 찾을 용기가 없다.인용문에는 괄호가 있고 이 크기의 인용문도 있어야 할 만큼 눈에 띄지 않는다(fr).wiki는 내가 알기 어려운 다른 설정을 사용한다.OTOH 우리는 훨씬 덜 깔끔하고 훨씬 더 부피가 큰 하버드 인용을 선택하게 될지도 모른다.—Admiral Norton 12:54, 2009년 5월 9일 (UTC)[응답]
  • 비고: 이 제안은 숫자를 더 작게 하기 위한 것이다. 숫자를 기호로 바꾸는 제안은 별도의 제안이어야 한다.텍스트 확대/축소된 사람들은 텍스트 확대/축소를 하는 이유가 있다: 그들은 더 작은 것을 읽는 데 어려움을 겪는다.그것을 한 픽셀씩 바꾸는 것은 가치가 없고, 그것을 더 많이 바꾸는 것은 사물을 알아보기 어렵게 만든다.두 지지표 모두 숫자를 기호로 바꾸는 것을 지지하지만, 이 제안 자체는 지지하지 않기 때문에, 현재 우리는 1개의 지지자(초기 제안자), 6개의 반대자, 2개의 지지자(기호)에 있다.이것은 그 제안에 반대하는 의견의 일치인 것 같다.아무도 반대하지 않는다면, 나는 그것을 닫고 해결했음을 표시하고, 관심 있는 사람이 '기호에 대한 변경 참조' 제안을 할 것을 제안할 것이다.–MT 00:08, 2009년 5월 10일 (UTC)[응답]

참고 자료

  1. ^ Grafton, Anthony ((April 1, 1999)). The Footnote: A Curious History (Paperback). Harvard University Press. pp. 256 pages. ISBN 978-0674307605. {{cite book}}:날짜 값 확인: date=(도움말)

무감시자에 대한 기사

나는 편집자의 감시 목록에 없는 기사 목록을 보고 싶다.정기적인 기여자 감시 목록에 있는 기사는 보다 쉽게 유지되고 적절한 기준에 부합하는 반면, 균열 사이에 끼지 않고 표준 이하의 정보를 포함하고 있다.이 페이지를 감시하고 그 다음에 그들의 리스트에 추가하는 데 전념하는 사람들의 태스크포스가 도움이 될 수 있다.나는 그런 프로젝트를 어떻게 시작해야 하는지에 대한 기술적인 지식은 없지만 몇 십 페이지 정도는 확실히 "적용"할 것이다.J04n(대화페이지) 13:41, 2009년 5월 6일 (UTC)[응답]

There is a list: Special:UnwatchedPages. — Edokter • Talk • 13:44, 6 May 2009 (UTC)[reply]
I suppose I should have read this proposal page before making my proposal (shame on me). I am not an admin and have no desire to become one but I do enjoy contributing to and maintaing Wikipedia. Since I am not an admin I have no access to the list of unwatched pages. J04n(talk page) 13:54, 6 May 2009 (UTC)[reply]
Looks like its been broken for years, you can only get the first 1000. That's my experience and commented upon on the talk page. Dougweller (talk) 14:04, 6 May 2009 (UTC)[reply]
Oops, that page only being visible to admins slipped my mind. — Edokter • Talk • 15:45, 6 May 2009 (UTC)[reply]
Hmmm, thought this was a perennial proposal. Doesn't seem to be, but here's a related one: Wikipedia:Perennial proposals#Create a counter of people watching a page. The arguments against that proposal are even stronger regarding this proposal. -- John Broughton (♫♫) 18:29, 6 May 2009 (UTC)[reply]
Perhaps, Autoconfirmed users could have access to the list? I would be suprised if many vandals fall into that category. J04n(talk page) 18:40, 6 May 2009 (UTC)[reply]
Then you'd need just one vandal to log on, wait a few days, make some edits and copy/paste the list to a website somewhere. Then the whole thing would become public knowledge. Tra (Talk) 19:11, 6 May 2009 (UTC)[reply]
Well, don't worry J04n – you aren't missing much. –Whitehorse1 03:16, 7 May 2009 (UTC)[reply]
The link target helps illustrate the unwatched; one of the commenters there posted an update all of those, at least, are now watched. –Whitehorse1 03:48, 7 May 2009 (UTC)[reply]
This is on Wikipedia:Perennial proposals under Technical. Rmhermen (talk) 18:58, 6 May 2009 (UTC)[reply]
Near the top of this very proposals page you will find #Watched counter, which a) solves this problem b) solves the problem with Special:UnwatchedPages lag c) leads to solutions to a large number of other serious and popular problems. All of the points made here have been addressed, though you don't need to read that to support the proposal. Unfortunately, nobody pays attention to the upper 80% of this proposals page, so it'll be dead and archived soon. Please consider reading through and supporting that proposal. –MT 03:05, 7 May 2009 (UTC)[reply]
Or moving/copying it to the wikiproject WP:PROJPOL for further development. Rd232 talk 03:51, 8 May 2009 (UTC)[reply]

Wikipedia:WikiProject Japan uses User:AlexNewArtBot to track new articles. Could the be configured to notify projects of pages that are not on anyone's watchlist? This doesn't require any changes to Media Wiki. Fg2 (talk) 03:03, 9 May 2009 (UTC)[reply]

I think the proposal mentioned by M is superior (and I've posted a "support" opinion above). Rather than identify targets of opportunity, it identifies articles that have just been edited that were not on anyone's watchlist. In essence, the proposal provides a list of edits that are "worth a second look"; should someone then find vandalism, then they would be inclined to add the article to their watchlist, taking it off such a list. -- John Broughton (♫♫) 18:29, 9 May 2009 (UTC)[reply]

Section with logical progression of academic articles within Wikipedia

Having seen Wikipedia's current system of lists and categories, it would be quite useful to create a section with a logical, natural and constructivist list of articles of a specific area. Topics would be ordered based on the knowledge required for the reader to understand it, instead of topics being ordered alphabetically. It could even be portrayed as an article tree, which would be more intuitive. It would not override the current categorizing systems, but would add another way for the reader to reach an article.

This system may have a huge positive impact on the reader, who does not always have the knowledge needed to understand a particular subject and generally leads him/her to search related topics, but with no guide at all (and falls into circular browsing). I think that, specifically in areas like Physics, Chemistry or Mathematics, it would be a great way for people to learn in a more logical order. Of course, these sections would be maintained and created by users, as in the current system. ((unsigned comment by --Elethan ?))

List of calculus topics or WikiBooks? --Izno (talk) 17:28, 9 May 2009 (UTC)[reply]
I think you may be trying to reinvent WP:Books. --Hans Adler (talk) 18:37, 9 May 2009 (UTC)[reply]
Oops, you are right! I'm sorry! --Elethan (talk) 20:51, 9 May 2009 (UTC)[reply]
Resolved

Make the Watchlist more like an Inbox

In my email inbox, I can mark new emails as read, mark them for followup, and move them out of the inbox. The Watchlist is Wikipedia's equivalent of an inbox, but I can't do any of those things. The most important one would be the ability to mark the recent changes appearing in the Watchlist as "OK, don't show this change on the Watchlist anymore" (but show any subsequent ones, of course). This would allow a degree of processing of the Watchlist in the manner of an inbox, and make it much easier to process very large watchlists. Thoughts? Rd232 talk 20:27, 26 April 2009 (UTC)[reply]

I think this could be accomplished fairly simply as a javascript in your monobook.js. I don't really have the time or javascript specific skill to make it myself though. Chillum 20:33, 26 April 2009 (UTC)[reply]
Me neither. Any volunteers? Anywhere I can request this from editors who do have the skills? Rd232talk 23:35, 26 April 2009 (UTC)[reply]
Just want to voice my support for this stunningly simple, and brilliant, idea. DuncanHill (talk) 23:39, 26 April 2009 (UTC)[reply]
I'd support this, as long as it's an optional feature. –JuliancoltonTalk 02:39, 27 April 2009 (UTC)[reply]
After some thought I'm guessing you're drawing a parallel with emails being marked as read automatically? That's not what was suggested, though as an optional feature, there's no harm in it. Rd232 talk 04:17, 27 April 2009 (UTC)[reply]
  • Tagging articles on our watchlist, so that any notices about them appear in the folder we specify, would be quite nice. That'd make things much easier to manage. I'd also like to set it, so that if something I care about has a tag for deletion or merge discussion, or someone erases everything and puts a redirect there, I'd have it in a main category, so I'd notice right away. There are just far too many articles to keep track of otherwise. If everyone had everything they ever worked on, on their active watchlist, it'd be too huge to pick anything of importance out. So some sorting is going to be quite useful to make sure people can stay aware of what's going on. Dream Focus 04:40, 27 April 2009 (UTC)[reply]

MediaWiki has had at least part of this feature request for a long time. On wikis like Meta, bold entries are the unread changes. When you click the diff and reload your watchlist, the entry is no longer bold. And there's an option to mark all entries as read. (Much like an e-mail client.)

It's not enabled on en.wiki due to ... performance reasons? They tried to enable it a few months ago and it didn't work properly. Or something.

The folders idea is interesting, but would require rewriting the watchlist code significantly, and there's no shortage of other bugs that are already long overdue to be fixed. Someone should still file a bug about the folders idea.

In general, the watchlist code is rather outdated and could stand for a major rewrite (including being able to watch only talk pages, being able to set auto-refresh, inline unwatch links, URL parameterization for things like hiding bots, etc.) --MZMcBride (talk) 06:41, 27 April 2009 (UTC)[reply]

Didn't it cause the mail server to explode for some reason? I seem to remember Brion strangling someone because it dumped the load of the entire site onto the mail-sending daemon. Or something like that.
I expect the 'folders' idea would be duped to the "multiple watchlists" bug...
Happy‑melon 14:01, 27 April 2009 (UTC)[reply]
  • Yes, I totally support something like this. I don't use the watchlist, because it fails to give me vital information and doesn't allow me to check off certain edits as okay or requiring follow-up. These options are really needed. - Mgm (talk) 09:54, 27 April 2009 (UTC)[reply]
  • I would absolutely love to be able to watch only talk pages. ♫ Melodia Chaconne ♫ (talk) 11:24, 27 April 2009 (UTC)[reply]
    • Go to the watchlist, and in the "Watchlist options" box, pick the Talk namespace. Voila, only talk page edits. EVula// talk // ☯ // 17:57, 2 May 2009 (UTC)[reply]

'Comment: I didn't really want this to become a shopping list for Things I'd Like My Watchlist To Do. In the back of my mind was that what I was suggesting might be relatively simple technically (as simple as anything is on WP), because it could just be an additional per-user table (edits to be filtered from watchlist). I don't know if the thinking was right (probably not...), but please bear this in mind. That said, I'd love to know more about the idea that some major revision to the watchlist system exploded (and hence might be fixed?). Rd232 talk 01:58, 28 April 2009 (UTC)[reply]

  • I like this idea. All this time I've just been trying to be the most recent editor on every page of my watchlist. --Explodicle (T/C) 15:35, 6 May 2009 (UTC)[reply]

The watchlist table contains an item for every page watched by every editor. I have a record in there for every page I watch, and so do you - different records for us even if we watch the same page. For every record, there's a date for the last time you opened the page you watchlisted, but this isn't turned on because it might harm performance (perhaps premature optimization). We could put a button or link (that uses ajax to submit without reloading, like the watch tab does) beside items in our watchlist, with the word "approve". After the editor checks the page's changes, they click the button and it updates that date. We could now make a 'diffs since last check' to make watchlist-checking much easier. Note that this isn't flagged revs - flagged revs is public, and makes a table where people can approve every single revision on wikipedia. This change uses a field that's already in the watchlist table to say "yep, I'm up to date on this article that I'm watching". Will hundreds of editors clicking this button every day/hour/minute cause strain on the database? Perhaps, but then again it should reduce people's messing with diffs, and the editing of an article just to put it to the top of a watchlist - and it would make editing much easier. –MT 22:13, 9 May 2009 (UTC)[reply]

That sounds promising and persuasive. This sounds like it deserves more discussion (and some way to collect more support). Since you have a better idea of the issues that I do, could you draft a WP:PROJPOL proposal for it? Rd232 talk 13:06, 10 May 2009 (UTC)[reply]

No archiving of proposals [resolved]

If proposals made on this page do not lead to results, then we're not doing much except chatting about neat ideas and informing people of why things are done in certain ways. Proposals should have a clear path of resolution or escalation. Only proposals that have been resolved should be be archived, proposals that have not should either remain or be escalated. The tentative proposal is that

Proposals should not be archived until they've been looked at. Where the consensus is rejection, archive it. Where consensus is approval, keep it until it is implemented - though all discussion except for a nutshell summary may be archived if someone has taken the proposal up. [amended 08:02, 9 May 2009 (UTC)]

Or in specific detail: [amended 08:23, 9 May 2009 (UTC)]

  1. Proposals are not archived until they've been alive for 3 days and have at least 15 participants who supported or opposed.
  2. A proposal is rejected by consensus, or when it has no support. It is then archived.
  3. When a proposal is approved by consensus, it is not archived until it is implemented.
  4. If responsibility for implementation has been accepted, a very brief summary can be placed in a 'todo' section, and the rest archived.
  5. Proposals with no consensus for 10 days can be escalated/moved to central discussion.

The above policy is essentially handled by the archiving bot. If more than 15 people want to keep this page clean by giving feedback to proposals, then size will not be a problem. What this means for this page is that everyone who offers a proposal will see something come out of it. It's likely that this would reduce the size of this page, and kill certain proposals that should have been dead a very long time ago. #2 has two weird clauses: the last-10-votes clause catches swings in opinion (presumably due to some great point just made); the no-support clause lets "requesting feedback on [link]"s to die a normal death - that is, it's not a proposal until someone supports it. The idea here is that some proposers want feedback and a chance to amend if they missed an obvious problem. Objections on the basis of ambiguous proposal wording, the proposal being too long, and so on are all acceptable and encouraged. Thoughts? –MT 06:49, 9 May 2009 (UTC)[reply]

  • Oppose - too complicated, too much of a bright line, encourages voting. ╟─TreasuryTag►contribs─╢ 06:56, 9 May 2009 (UTC)[reply]
    Well at least let me amend it :) I don't think it's very complicated - I think you might be mistaking formality with complexity. In a nutshell, Where by consensus a proposal is rejected, archive it. Where by consensus it is approved, keep it until it is implemented, though a substantial part may be archived if the proposal is pending implementation. A bot cannot recognize consensus, so I used hard numbers in #1 and #2. Could you explain the problem with bright line rules? –MT 07:19, 9 May 2009 (UTC)[reply]
    It's simply complicated. It categorises proposals into three or four complex groups, creates new sections of this page, multiplies bureaucracy. With bright-line rules, I could explain the problem that Wikipedia has, but I reckon that WP:IAR could do it even better. There are always exceptions, and having such a rigid structure is completely un-necessary. Is there anything specifically not working about how we do things now? ╟─TreasuryTag►contribs─╢ 07:35, 9 May 2009 (UTC)[reply]
    This complexity is handled by the bot, not by you - and for a bot, this is one of the simpler programs. All you have to do is vote on proposals that you want to see canned or resolved. It creates one new section - a very helpful section. I don't see how my summary of the proposal, in italics, is anywhere near bureaucratic. It's simple: stop letting proposals slip away into the archives. If you'd like to see what isn't working, look through those archives. Very few of the proposals in there have been implemented, most of them died because there was no path to implementation. The three proposals at the top of this page are about to be canned even though they look like they have some great potential. And they're the ones we should be paying attention to, not the stuff down here. The fourth proposal seems like it should have been canned long ago, yet it was sitting around drawing attention with what seems to be a single person supporting it. Would you mind unbolding your oppose until I've had a chance to address your concerns? –MT 07:54, 9 May 2009 (UTC)[reply]
    No, I will not unbold my oppose. I oppose any bright-line rule of this sort, unequivocally. You seem to misunderstand WP:VOTE. Consensus is not a poll. It is a discussion, where points of view and weights of case and opinion count. Do you propose coding a bot which can evaluate arguments, which would be the only way a bot could judge consensus and archive sections accordingly? Because I think that NASA might be interested, if you know how to create such a program. ╟─TreasuryTag►contribs─╢ 07:57, 9 May 2009 (UTC)[reply]
    Ok - I don't mean that you shouldn't oppose it, I just want to hold off on "voting" until I've had a chance to address any issues that come up. I'm trying to modify the proposal so that you don't consider it to be a bright line rule, though I'm still not sure what that is because WP:IAR is just one sentence long. I've already changed the proposal to not make reference to a vote, so I'm not sure what you're referring to. As for the bot, we could simply have it evaluate "discussion closed, consensus was rejection / implementor found / implementation completed" messages placed at the bottom, as we usually do. –MT 08:12, 9 May 2009 (UTC)[reply]
    Your system involves sections of this page being archived differently depending on whether or not they have garnered consensus. However, you've said above, "All you have to do is vote on proposals that you want to see canned or resolved." A bot can assess votes, but not consensus. ╟─TreasuryTag►contribs─╢ 08:19, 9 May 2009 (UTC)[reply]
    The bot would only need to look for a template/message placed at the bottom of the straw poll/proposal. This would mean that an editor would have to do that, though perhaps we can use the bot for cases of obvious numerical consensus (e.g. 10 oppositions, 1 support). Do my amendments to the proposal address your concerns? –MT 08:30, 9 May 2009 (UTC)[reply]
What makes a proposal with 79% support any less worthy than a proposal with 80% support? —kurykh 07:23, 9 May 2009 (UTC)[reply]
Nothing - I should amend the proposal (and have now done so) to refer to consensus (though perhaps I should talk about 'structured discussion'). But to answer your question, a proposal with 79% support is only one vote away from approval, while a proposal with 70% may be a lot further away. –MT 07:30, 9 May 2009 (UTC)[reply]
If you're going to amend the proposal to refer to consensus, then this proposal is pointless; it merely states the status quo. —kurykh 22:29, 9 May 2009 (UTC)[reply]

I think this idea is fundamentally misguided (WP:VOTE). I suggest instead moving proposals considered worth developing to WP:PROJPOL for development. Rd232 talk 13:32, 9 May 2009 (UTC)[reply]

The proposal doesn't talk about a vote, though have a look at WP:VINE - could you elaborate? This proposal says that proposals need a certain number of comments before being archived. Will proposals moved to projpol have a greater visibility than if they are here, or will this be 'sweeping under the rug'? –MT 15:37, 9 May 2009 (UTC)[reply]
Your proposal may not be explicitly votey but the underlying WP:VOTE principle is that arguments matter, not the number of participants, and it goes against that. Now I might support the idea that proposals may be archived early on a sort of WP:SNOW principle if the initial poster is notified and anyone may undo the archiving. But no bots, please. (For example I'd count "Local version of Wikipedia" and "Tagline" above as candidates for that.) Rd232 talk 15:55, 9 May 2009 (UTC)[reply]
Proposals will have a greater visibility than in the VP archive. A link to proposals there (which would only be proposals a number of people think are worth discussing in more detail) can be posted here and elsewhere after being moved there, and even eventually re-posted if appropriate to help keep discussion going, rather than just falling into the swamp of history. Rd232talk 15:55, 9 May 2009 (UTC)[reply]
Could you suggest a change to the proposal, then? The number of participants doesn't have anything to do with it being implemented, it only has to do with it not being archived. The problem here is that even proposals that have support and potential are getting thrown into archives. Look at the cancel button proposal at the very top - are you planning to copy it to projpol? Once it's there, what strategy do you have for seeing that it's implemented? –MT 18:39, 9 May 2009 (UTC)[reply]
Well I'd create a projpol proposal subpage for each good proposal (once a number of people support; see also Wikipedia:WikiProject Policy and Guidelines/Suggestion Box), which would restate the proposal and rationale as clearly as possible, taking into account prior discussion. If it needs further development, that can happen there. Once it's ready, it depends on whether it needs dev action. If it requires a software change, it needs a bugzilla post - and perhaps something resembling a petition, to get dev attention; so find ways to get attention for it. At least without the archiving bot deadline here, that can happen over longer periods. Or if it's just a policy change, once it's ready either go to the specific policy page or pages, or create a new one, and go through the usual discussion processes (but on basis of well-developed and already thoroughly-discussed proposal). But you know this is basically off the top of my head - this is one of the things projpol is for - to figure out how to get good ideas implemented (and possibly-good ideas thoroughly discussed). Rd232talk 18:59, 9 May 2009 (UTC)[reply]
Subpages on projects are typically ignored, unless there is some reason for many people to look at them. I don't mind 'escalating' things to projpol, but it should be escalation, not 'sweeping under the rug'. You can have the best intentions to help implement 10 proposals per week, but that's the sort of sustained effort that needs to be based on an established community (the one that reads this page, for example). The proposal above gives a clear path to implementation, because it prevents people from sweeping things under the rug. If you want it gone, you have to say why. I'm still interested in the top 3 proposals, but I'm afraid that expressing that will be bad form. ... –MT 21:35, 9 May 2009 (UTC)[reply]
"Subpages on projects are typically ignored, unless there is some reason for many people to look at them." Well the whole idea of projpol is to develop a system where people have a reason to look at these things (summaries of current state of subpages, for example, might help). And I don't quite get your "sweeping under the rug" remarks; I've already said the idea is to find ways to better develop interesting-seeming proposals; which compared to letting VP proposals fall into the VP archive is surely quite a low standard. I wish you'd engage with that instead of persisting with your current No Archiving Until idea which doesn't seem likely to go anywhere in anything like its current form. Consider too that the draft two-step system of WP:PROJPOL is designed to avoid exactly the problem you're trying to address (weeding the wheat from the chaff). Rd232talk 03:09, 10 May 2009 (UTC)[reply]
By sweeping under the rug I mean that people on this page would assume that "someone else will handle it" when it gets taken up by projpol. I think that it's a great idea to develop policy, which is why I'm trying to put all of it on WP:Nutshell (I renamed it) so we can get a feel for how the whole thing really looks (most of policy pages is needless explanation and can be omitted). I think that implementing just the below-bolded proposal for getting more comments on this page will help, no matter what projpol does, so I don't want to give up just yet. –MT 06:45, 10 May 2009 (UTC)[reply]

<undent> ...Say someone drops by and makes a great proposal here, and then leaves. It has tons of support, but instead of figuring out how to implement it, everyone is going off to read the latest interesting proposal blurbs. And what about proposals which have no comments? If they were "in line" first, shouldn't we take greater care to comment on them before we comment on whatever the latest thing is? How about just the following proposal:

  • Proposals are not archived until they've been alive for 3 days and have had at least 15 distinct editors who have commented.

This will encourage more feedback, even if it is just "oppose: too confusing/unclear/long/nobody will implement/not really a problem". Is this a good idea? Should we give this level of consideration to all proposals? Would it be harmful to do a test run of this policy? –MT 21:35, 9 May 2009 (UTC)[reply]

I would oppose this, I think it has too many issues to be workable.
  • Many proposals are either perennial proposals or just really bad ideas. We shouldn't force people to comment just to get it off the page. On the other hand, certain proposals need a significant amount of support where 15 people may be far too few to implement.
  • We don't need consensus to reject; we need consensus to implement. We shouldn't be voting on everything. Just because a proposal has no consensus either way doesn't mean we should let it sit indefinitely.
  • Define "implemented". For a software change, is it considered implemented when a bug report is filed, do we have to wait until the change is checked in to SVN, or do we have to wait until the change goes live on Wikipedia? What if there's consensus that something is a good idea, but implementation would be extremely difficult or even impossible?
  • How will a bot determine whether a proposal has been implemented?
  • I find it very difficult to believe that this will do anything but massively increase the size of this page. Most proposals do not get comments by 15 people, let alone enough to be considered consensus. The largest proposal on this page right now, "Welcome to Wikipedia (United States)," has fewer than 20 people commenting on it, and is 70 kilobytes long (slightly more than 25% of the total page size). Not including my comment, this proposal is almost 13 kilobytes, and has only 3 people who aren't the nominator commenting.
  • Possibly the worst part was the "a proposal with 79% support is only one vote away from approval" - arbitrary cut-offs like that are a terrible way to decide whether or not a proposal is successful.
If nobody who supports it is actually willing to do the work to implement a proposal, perhaps it wasn't that great of an idea after all. Mr.Z-man 23:52, 9 May 2009 (UTC)[reply]
Getting 15 people to comment should be trivial, and proposals with no bold 'support' can be archived as usual. We're not voting, just leaving comments, and I think that someone who's taken the time to make a proposal deserves some level of feedback: the number of people reading this page vs proposing is approximately 100:1. The very purpose is to attract more comments to proposals, so saying 'look at how many proposals don't get enough comments' only supports my point, I think. The page-size issue is hypothetical and somewhat pessimistic threat - meanwhile, the archives are full of hundreds of dead good proposals. Your points #5 and #3 are not about my current proposal (the answers are "ok" and 'it's implemented when it's live, and it goes into a todo list when someone takes responsibility for implementation').–MT 01:02, 10 May 2009 (UTC)[reply]
So if people support the proposal, but don't indicate their support with bold text, they won't be counted? The page is a discussion already. Making it like AFD or RFA is just going to make it more like a vote and less like a discussion. You seem to have misunderstood almost all of my comments. I'm not saying proposals are getting too few comments, I'm saying requiring 15 users to comment is far too many. If each proposal on this page had 15 users commenting and a real discussion (not an AFD-style pseudo-vote/straw poll), this page would be unusably huge. Its not hypothetical, look at the size of the discussions of the proposals that currently meet this requirement; I'm pretty sure there's only 1 or 2. Even a minor software change might take several weeks to go live (the version of MediaWiki we're currently using is 6 weeks old, while a wait that long is not normal, it is possible), for an extension like AbuseFilter, it might be months before it can be written, reviewed, tested, and deployed. You seem to be contradicting yourself a lot here. On one hand you say we won't be voting, on the other you keep talking about percentages, numbers, and bolded comments. Mr.Z-man 02:54, 10 May 2009 (UTC)[reply]
I'm not currently proposing the 'implementation' tracking aspect, so perhaps we should put that aside for now. Sorry about any contradictions, I'm just trying to work out the problems in the proposal. Let me know if you want me to re-state anything more clearly. Getting AFD-style feedback is better than getting no feedback at all. That "discussion" about usa-bias taking up 1/3rd of this page (please support my proposal to manually archive it, if you think I should) is not characteristic. Forget the bolded support thing, I'll bite the bullet on "yes, 15 people comment on every proposal" - #Tagline had no problems being shot down by 6-7 people once the objection had been raised. I think that if more people comment, the exchanges are actually shorter. And more ideas can be thrown out. What do you think? Is there still a problem with getting 15 people to comment? –MT 06:23, 10 May 2009 (UTC)[reply]
Let's put it this way: would you propose some method to get people to comment on proposals, if there was no problem with getting them, or downside of doing so? But it doesn't seem easy - Wikipedia is not a concentration camp and it's hardly possible to force someone to do some work in here (it is easier to force someone to avoid doing something unnecessary or harmful). So, I'm afraid that many proposals are likely to end up waiting for those 15 people for several months, or else, they would be simply rejected unthinkingly by someone trying to "reduce the backlog". Neither case looks very good...
Finally, what exactly is wrong with the current system? From what I understand, a bot (User:MiszaBot) archives the discussion when at least 7 days have passed after the last comment. Presumably, the discussion is over at that point (although I guess that one may argue about the preferable number of days), with nothing being left to discuss. If no one is trying to implement the proposal then, why would waiting more be likely to help? And if someone is trying to implement it, what is going to be gained by the discussion being "open"? If the one implementing the proposal needs to make an announcement or to "prove" the presence of consensus, using the link to archive might even be preferable, as such a link (and the discussion) would be less likely to change. --Martynas Patasius (talk) 19:22, 10 May 2009 (UTC)[reply]
I retract the proposal. –MT 21:06, 10 May 2009 (UTC)[reply]
Resolved
– lack of support, retracted.–MT

Getting reverting changes to not show up on a watchlist report, again

I would like to repeat a proposal that has been made before; I wonder if this could be moved to the list of perennial proposals.

As the maintainer of a WikiProject comprising several hundred articles, I have a big watchlist and I have to check nearly everything on it, because even vandalism reversions sometimes leave the job incomplete. It would save me a lot of time if changes that have been reverted could be filtered from my watchlist. Specifically, the ideal thing would be that edits made by IP editors that have been rolled back or undone, and the edits that perform the rollback or undo, are omitted from the watchlist. This would probably cut my watchlist in half and save me at least 15 minutes a day. I specified "IP editors" because I like to examine even vandal edits if they are made by registered editors. Looie496 (talk) 23:40, 9 May 2009 (UTC)[reply]

You might be interested in #Make_the_Watchlist_more_like_an_Inbox. Do you use the default watchlist, or the one that offers an expanded view? –MT 00:43, 10 May 2009 (UTC)[reply]
That's also a nice idea, but the problem it solves is completely different. With 50-100 articles a day showing up on my watchlist, some heavily edited, the expanded list is a nightmare for me. If it could group edits to a given article together and limit the number it shows per article, it would be a lot more helpful. Looie496 (talk) 03:47, 10 May 2009 (UTC)[reply]
Have you tried http://en.wikipedia.org/wiki/Help:Watching_pages#Expanded_Watchlist , and how would you want it to be different? Do most of the changes you want to ignore happen in the same day? Would that expanded watchlist be too much of a pain to use anyway? What do you mean by "omit from the watchlist"? Say that I edit some stuff, then an ip comes along and gets reverted. Ip/revert detection "omits" that entry - but of course you still want to see it on your watchlist, since you want to check my edit. What you would need now is a script that checks every single item on your watchlist, and if the last edit content was the same as 2 edits ago, then load the summary text/info of that older edit. Then, after this is done, re-sort the entire list according to dates. Now when you look at the list, you'll start with whatever date you hadn't checked, and move upwards. The problem here is that this is annoying to implement. If, however, that above proposal went through, it would be almost trivial. We'd have your 'last approved' date (something we don't currently have) and the current edit date. Your proposal becomes "If the last-checked and current edits are equal and there is one edit between them by an ip, then auto-approve the most recent edit". This script could probably be written faster than I wrote this reply to you. The first half of this message is a difficult/messy solution to your problem given the current system (maybe someone will come up with something better, or implement it for you), the second half is a very easy solution, but it needs that above proposal to be supported and implemented. –MT 05:59, 10 May 2009 (UTC)[reply]
Let me try to clarify. What frequently happens is that an IP makes a bad edit or series of bad edits, and then somebody reverts them, often within seconds. I don't feel any need to look at articles where that is all that has happened, but currently I am forced to look at the article history anyway because otherwise I can't tell whether there have been other unreverted edits. The extended watchlist is not useful because it doesn't tell me whether the article contains unreverted changes -- the information is there but is scattered so widely that in practice I can't integrate it. Looie496 (talk) 06:29, 10 May 2009 (UTC)[reply]
I understand, but the problem is, how will a script know how far back to go? So say you look at it on Monday, Tuesday I edit it, Wednesday you get vandal/revert, and then you look at it again on Thursday. The script doesn't know what the last thing you looked at is. Maybe you looked at it Monday and want to see my edit, maybe you looked at it Tuesday night and already saw my edit. Should the script display it? Who knows! That's why it would have to do all that backtracking and re-sorting - that way you can figure it out for yourself. But that's not fun to program. So what you're asking can be done, it's just messy, tedious, and a lot of work. (The alternative is fun, clean, and fast, though.) –MT 06:57, 10 May 2009 (UTC)[reply]
My practice is to go through my watchlist in order, starting at the point where I last checked it, so I can tell whether I've examined an edit by the time at which it occurred. The "mark as examined" change would allow me to be more flexible about the order I do things in, and would reduce the size of my watchlist by quite a bit, but wouldn't actually save me much time. Regarding how far back to go: The script would go back to the most recent edit that is not flagged ignore. Edits are flagged ignore if they are either (1) an IP edit that has been reverted, or (2) an edit that reverts an IP edit. Looie496 (talk) 16:22, 10 May 2009 (UTC)[reply]
The software can't mark edits ignored, so the script would have to. So, it takes the most recent edit, and grabs that page's history. It marks revisions ignored as you describe. Then it takes the latest unignored revision and puts it in place of the current revision (which is ignored). However, that last unignored revision might be from two months ago, or from an hour ago. So now you're stuck going through this (though the dates would be there). The script could however just sort them for you, and then you'll have what you want. Each of these steps is difficult to program and server-intensive. I'm not saying that the above proposal is what you need instead of this - what I'm saying is that if the above proposal goes through, your problem could be solved very easily using those tools. –MT 20:07, 10 May 2009 (UTC)[reply]

Beneficial links

While advertizing is greatly censused to not suit Wikipedia, what about the idea of making a buck through beneficial links?

To me this is more obvious when it comes to books, but it might apply to other thigs as well: When I want to learn about a certain book or essay on WP, I sometimes also want to buy it. If the article had a direct link to a publisher selling the book, then both me, the publisher, and wikipedia would gain from it.

Unlike common advertizing, I don't see how this method can greatly offend the neutrality of the articles, as the fact that a "where to buy" link leads to this and not that publisher should probably not cause someone to over-boast or under-boast the book in a way that damages the neutrality of the article, and even if it does happen by a publisher wanting to boast a book that now leads to their online store, it can still be moderated by the community, I think.

Perhaps theres a place to consider this as an experiment on a small number of items and see how this works? This could develop into a good income stream while improving the service to many users who want the thing they just searched.

WP:PEREN#Advertising. Explicitly dismissed by the Foundation. Wikimedia does not, and will not, sell advertising of any sort. Happy‑melon 08:54, 10 May 2009 (UTC)[reply]
However, if you remember to find and add the International Standard Book Number (ISBN) of your footnotes and references in one of the formats that Wikipedia's software can read, it will automatically convert to a Wikilink like this, which in turn, when clicked by a reader, will direct him or her to not only free libraries but to booksellers and publishers, both commercial and non-profit. Whether this can be used as a source of revenue for Wikipedia, and if so, whether this is compatible with Wikipedia's aims and principles (especially neutrality), is an altogether different question. —— Shakescene (talk) 09:01, 10 May 2009 (UTC)[reply]
So the non-revenue aspect is already implemented, the revenue aspect has been dismissed by the foundation. Anything else to say about this one? –MT 09:15, 10 May 2009 (UTC)[reply]
Resolved
– peren. Please delete this template if discussion resumes. –MT

Suggestion to include eyePlorer into http://en.wikipedia.org/wiki/Special:Search

Hello. My name is Georg Rehm, I'm a product manager with vionto GmbH which is based in Berlin, Germany. Our product http://eyePlorer.com is an award winning graphical knowledge engine that enables a novel, interactive way of working with concepts, terms and knowledge. We use methods from language technology and computational linguistics in order to analyse and compute knowledge from the German and English Wikipedia, next to selected other highly specialised content sources.

We would like to suggest the integration of http://eyePlorer.com into the Wikipedia search page available at http://en.wikipedia.org/wiki/Special:Search because we think that eyePlorer.com provides a unique way of exploring and working with Wikipedia concepts and facts (eyePlorer.com is already included in the hub page http://www.wikipedia.de which redirects searches to http://de.wikipedia.org). We would be very happy if you could integrate eyePlorer.com into the list of optional search engines that currently contains Google, Yahoo, Windows Live, Wikiwix and Exalead. One of the developers who work for de.wikipedia.org (Wikimedia Deutschland e.V.) told me that the file http://en.wikipedia.org/wiki/MediaWiki:Common.js/search.js needs to be modified in order to include a new search engine. The line 

selectBox.appendChild(createOption('eyePlorer.com', 'http://www.eyeplorer.com/eyeplorer/', 'conceptTerms', 'language', 'en'));

should insert eyePlorer.com into the menu on the Wikipedia search page; the linking scheme is 

http://www.eyeplorer.com/eyePlorer/?conceptTerms=hand&language=en

Please let me know what you think of this suggestion. Should you have any questions please don't hesitate to drop me a line.

Thanks to Brandon Weeks from the support team for pointing out that the Village Pump is the right place to post suggestions such as this one. -- Georg Rehm (talk) 13:22, 5 May 2009 (UTC)[reply]

I see from your message that you think it is useful, novel, and all sorts of other fuzzy things, but what does it actually do, and why would it be useful to wikipedia? As I understand it, those engines are included due to popularity. –MT 02:45, 7 May 2009 (UTC)[reply]
Currently listed on http://en.wikipedia.org/wiki/Special:Search are traditional search engines run by companies (Google, Yahoo, Windows Live etc.). In contrast, eyePlorer.com provides an interactive, graphical, alternative view for Wikipedia articles and relations that exist between different articles, i.e., eyePlorer.com offers a significant amount of added value to those users who would like to explore Wikipedia with an interactive interface. eyePlorer.com is currently specialised on Wikipedia content but additional data will be available in the near future (such as, for example, the Medline database of research article abstracts). Could you please do me a favour and explain why you think that including eyePlorer.com in the list of optional search engines available at http://en.wikipedia.org/wiki/Special:Search would be "promotional" and why you think that the actual inclusion of Google, Yahoo, Windows Live, Wikiwix and Exalead is not? Thanks in advance! -- Georg Rehm (talk) 12:27, 11 May 2009 (UTC)[reply]
The difference is that your proposal is promotional. There is no reason why we cannot add eyePlorer to the Search box, but in general, we prefer to do things like this upon the request of our users, and not upon the request of owners of companies. —TheDJ (talk • contribs) 18:13, 11 May 2009 (UTC)[reply]
I think he does make some good points, despite his association with a company. I think MZMcBride nails the bigger problem: M 20:54, 11 May 2009 (UTC)[reply]

Hmmm. We need a standardized way of picking search engines or we need to not include any at all. The current selection is arbitrary and I imagine it's the result of the original code writer's preference. Wikiwix and Exalead? Come on. I don't know whether we want to include eyePlorer or not, but we certainly need a standardized selection criteria for what's included in Special:Search. Esp. given that it's viewed over 5,000,000 times a day. --MZMcBride (talk) 18:34, 11 May 2009 (UTC)[reply]

We might do this by popularity, but I don't think that's the best idea. Yes, the most popular engines should be included, but if there's an engine custom-built to serve wp that just came out, and performs very well and has specific and verifiable benefits, I think we should include it. We probably need to set up a review for these things. How did we handle the isbn thing? Just list every single online company? M 20:54, 11 May 2009 (UTC)[reply]

Facilitation rather than Mediation

I would like to suggest our thinking about renaming "mediation", calling it "facilitation" instead, or using facilitation more frequently in known trouble spots so that things don't have to go to "mediation" (or arbitration).

Mediation conjures up the image of one person "in the middle" mediating between "the two sides". The concept is adversarial. Arbitration is even more so. Facilitation, on the other hand, widely used in business, just aims to ensure that everybody's interests and concerns are addressed. It does not start with an a-priori assumption that every participant can be assigned to a "side" and ideally prevents situations coming to a point where mediation or arbitration is necessary. Having participated in business meetings with and without facilitation, I can vouch for the fact that the difference it can make to the pleasantness of the interaction, and the quality of the result, is tremendous.

Looking at the current RFAR involving Mattisse, that is exactly the sort of situation that good facilitation can help to avoid. Clearly, we can't have a facilitator on every WP talk page, but there might be merit to having a pool of neutral facilitators, who in their role as facilitators are bound not to express views on the topic under discussion, but only to comment on group dynamics and the quality of communication, on talk pages relating to important WP processes, like GA and FAC.

Thoughts? Jayen466 11:56, 7 May 2009 (UTC)[reply]

It's an in interesting idea, however the problem I see here is that most users won't know that there are issues to resolve until it escalates to a level where there's problems, and informal/formal mediation is requested. Not sure how users would be able to detect problems on an article page without being told. What do you think? Steve Crossin Talk/Help us mediate! 23:19, 7 May 2009 (UTC)[reply]
Thanks for commenting. I am open to ideas ... we could think about adding routine facilitator support to certain processes, such as User RfCs, arbitration, FAC, GAR, AE, AN/I or generally any other area that has historically led to people getting upset. A facilitator's task would be just to look at the quality of communication, and check if people have actually understood what others have been saying, and to help them understand if they haven't. It's a role that would have to be defined. Jayen466 23:48, 7 May 2009 (UTC)[reply]
Not too sure how workable this is. I'm all for improving communication between users, but I don't really see who would volunteer to do this. Who would have the time to watch every AN/FAC/GAR etc? Steve Crossin Talk/Help us mediate! 23:12, 8 May 2009 (UTC)[reply]
"facilitate" sounds like a meaningless buzzword to me. "I'm an expert at facilitating proactive paradigm shifts to leverage the empowerment of all dialogue agents to achieve a solution in which all viewpoints are effectively integrated." Mr.Z-man 06:25, 8 May 2009 (UTC)[reply]
"Facilitation"... of what, drama? Zetawoof(ζ) 11:40, 8 May 2009 (UTC)[reply]
I see where you're coming from Jayen but sometimes its better, when there are issues (which there always will be on an encyclopaedia), for people to be who they are rather than appear to be somewhat different through the medium of a facilitator. Most editors have an authentic voice which becomes apparent when you deal with them for any length of time. Facilitation might help the appearance of civilised discourse but it won't help actual communication between humans.Fainites barleyscribs 17:42, 8 May 2009 (UTC)[reply]
I am not sure you understand what a facilitator does. A facilitator observes the conversation and simply points out when people talk past each other. When people get upset, perceptions suffer, and things often get unnecessarily heated. A facilitator can help bring people back on the carpet, or ensure that they actually address what someone else has said. Jayen466 23:05, 8 May 2009 (UTC)[reply]
That sounds like it has the potential to make things worse. Rather than a mediator working toward a compromise, they'll be chiding users for poor communication skills? Mr.Z-man 01:46, 9 May 2009 (UTC)[reply]
You can also call it a moderator, as in a moderated newsgroup etc. Jayen466 23:09, 8 May 2009 (UTC)[reply]
The term "moderator" has a lot of baggage from web forums and mailing lists, where it generally implies administrative privileges. Zetawoof(ζ) 00:46, 9 May 2009 (UTC)[reply]
"Intermediary" (a means through which people communicate)? but then what would be the noun? "Intermediation" is a word, but it means something different. Can someone ask Kofi Annan, Richard Holbrooke or George Mitchell? ;-) Maybe "consultant" and "[mutual] consultation"? —— Shakescene (talk) 01:10, 9 May 2009 (UTC)[reply]
Diplomat? Carcharoth (talk) 04:38, 9 May 2009 (UTC)[reply]

From the original proposal: "Clearly, we can't have a facilitator on every WP talk page, but there might be merit to having a pool of neutral facilitators, who in their role as facilitators are bound not to express views on the topic under discussion, but only to comment on group dynamics and the quality of communication, on talk pages relating to important WP processes, like GA and FAC." That idea may have merit (though I don't see why they should be limited to certain talk pages); but I don't see much point in renaming Mediation - it is what it is. Rd232 talk 02:36, 9 May 2009 (UTC)[reply]

Facilitators would need great skill, but if such people exist, they should be able to start acting now, rather than wait for a formal process or approval. Just find a dispute and try and calm things down and get people talking again. Do be aware though that one common outcome is this. If on the other hand, the participants in the dispute are willing to climb down and talk more reasonably, then facilitation may help. Carcharoth (talk) 04:37, 9 May 2009 (UTC)[reply]

A process would help (a wikiproject would do) to provide a point for people to ask for facilitation assistance. It could also help collect guidance for facilitators. Rd232talk 18:39, 9 May 2009 (UTC)[reply]
Agree. A role description is the first thing that would be needed. There is some overlap between mediation and facilitation, and some of the role description would be the same. Jayen466 11:01, 11 May 2009 (UTC)[reply]
  • I reject the notion that mediation and facilitation are synonymous. With that in mind, I'd view this thread as a proposal to introduce a system named "facilitation"; being less scrupulous and focussing on the proposal's content rather than its title, I think it to be a reasonably good idea. It's a shame that systems such as facilitation are usually successful or unsuccessful because of the competence of the individual mediator (or equivalent figure); perhaps involving multiple mediators in a single dispute—with maximum co-operation and communication between them—would serve to improve the success rate of systems such as mediation and facilitation. AGK 16:50, 9 May 2009 (UTC)[reply]

Artificial Intelligence Wiki

Resolved
– PEREN request for new wiki redirected to appropriate resources M

There are various projects currently in development that utilize the vast amount of interlinking wiki articles to create artificial intelligence. This is accomplished by analyzing the content of articles and the relationship to linked to and related pages.

For example, in the article "Automobile" we learn that: An automobile or motor car is a wheeled motor vehicle used for transporting passengers, which also carries its own engine or motor. From this sentence an AI script could deduce that a car has wheels and is used for transporting passengers.

With enough pages analyzed and an intelligent enough parsing engine, we can create an AI that "understands" various objects in the world and how other objects relate to them.

However, even with the fairly uniform article structure at present the articles are maintained by different people and different people have their own style of writing and structuring sentences and paragraphs. This increases the difficulty of parsing the articles and the relationship with other articles.

I propose a structured interrelation wiki format that describes an article and its components in a very basic form, without words to pad the sentence for correct grammar. This could be used for artificial intelligence and perhaps other applications.

With the power of user-submitted and maintained content, the artificial intelligence could truly be a living and ever adapting 'consciousness'.

An article could contain facts in such a simplified manner that parsing it would be easy and also more efficient.

To perhaps jump-start this idea the current pages of Wikipedia could be analyzed and broken down to create the simplified version.

I thought this was a good place to discuss the syntax of the markup and how the relationship between articles could be described.—Preceding unsigned comment added by Thermalite (talk • contribs) 09:17, 2009 May 11

  • If your proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. These are different from WikiProjects. You might find this article interesting, since it talks roughly about what you're talking about. But this isn't really the place to discuss new wiki projects, or AI. M 21:04, 11 May 2009 (UTC)[reply]

DYK-New Articles or New Content?

There is currently a discussion going on over at WT:DYK regarding the current rules for considering expansions and rewrites, Wikipedia_talk:Did_you_know#A_graduated_standard_for_DYK?, that has evolved into a larger discussion about what the purpose of DYK is and whether to change the main page title of From our Newest Articles to From our Newest Content. All opinions are welcomed in this discussion. AgneCheese/Wine 16:36, 11 May 2009 (UTC)[reply]

Watchlist in other projects

Can we users having unified logins get links to our watchlist in other projects? Not every single Wikimedia project, but those we've edited. Since I have watchlists on Commons, the Japanese Wikipedia and a couple of other projects, it would be convenient to have the links on my watchlist, just where the Languages box would be in articles. But including projects other than just languages. Fg2 (talk) 03:54, 8 May 2009 (UTC)[reply]

Since this is an interwiki issue, may I suggest you discuss it at meta's m:Wikimedia Forum? --Philosopher Let us reason together. 14:41, 8 May 2009 (UTC)[reply]
I use a greasemonkey script for a 'global watchlist'; a software-based implementation of this is a longstanding bug request (T5525). Happy‑melon 15:35, 8 May 2009 (UTC)[reply]
That appears to be much more ambitious than what I'm proposing. All I'm asking is a list of links to other wikis. The watchlist doesn't get generated until you click the link, which takes you to the My Watchlist page of the wiki and generates it normally. There is no merger of watchlists from separate wikis. Thanks for pointing it out, though. Fg2 (talk) 21:22, 8 May 2009 (UTC)[reply]
You mean like this? en:Special:Watchlist, m:Special:Watchlist, wikt:Special:Watchlist? You can find your watchlist at Special:Watchlist on any Wikimedia wiki - and a list of the prefixes for linking between projects is here. --Philosopher Let us reason together. 03:17, 9 May 2009 (UTC)[reply]
Right -- those are the links. My suggestion is to have Wikipedia organize those links in a box in the left column, beneath the "create a book" box, just like articles have links to their counterparts in other languages. The space is unused in Watchlist, and it would be useful to have those links in it. Fg2 (talk) 04:42, 9 May 2009 (UTC)[reply]
Most users don't use that, so I would object to adding it globally. If you want me to make you a user script that throws that stuff into the toolbox, give me a list of URLs with titles, and the url of the page where you would like to see it happen, and I'll do this for you. –MT 07:04, 10 May 2009 (UTC)[reply]
That's very kind -- thank you. I'll think about it some more and possibly leave a note on your talk page. Fg2 (talk) 08:13, 12 May 2009 (UTC)[reply]

Hiding certain edits in an articles revision history for easier readability

Has there been any recent updates regarding pruning article revisions?

I don't know if there's been any proposals in the past about this but it would make browsing through an article's history much easier if there was a way of hiding bot edits in the revision history.

For example, looking at http://en.wikipedia.org/w/index.php?title=778&action=history you can see that most of the edits are interwiki language links done by bots. These are relatively unimportant if one is trying to study the article's history and they may get in the way.

If at least there was a preference setting to show/hide bot edits (or even automatic reverts) like there is for watchlists that would be nice. Does the MediaWiki software currently allow for this? Or maybe someone out there wrote a script that could do this? -- OlEnglish (Talk) 00:13, 12 May 2009 (UTC)[reply]

In general, it would be good if the features of Special:Watchlist, Special:Contributions and page histories (and perhaps Special:RecentChanges) were consolidated and, where possible, all features should be available on each page. The defaults should be similar to what features they use now however.
Mark Hurd (talk) 03:00, 12 May 2009 (UTC)[reply]

T13181 is relevant; essentially the 'bot' nature of an edit is only retained for 30 days. Happy‑melon 13:27, 12 May 2009 (UTC)[reply]

Summary List

I'm thinking, couldn't you just put on option for established users to choose one of two options. One can be the normal edit summary, and one can be a check list of things, like spelling check, wording error, etc... It also can work for things that aren't minor edits, like cleaning up bad links, etc.... But as said before, only for established users, as an IP could change "as is" to "fuck", and then say spell check, and it will say they only have -1. Just and Idea. Thanks, Old Al (talk) 12:26, 7 May 2009 (UTC)[reply]

The save page button could be a number of buttons. "Submit as spelling", "Submit as rewording", etc. Automatic diffs into the summary would be pretty nice too. –MT 15:37, 7 May 2009 (UTC)[reply]
Russian Wikipedia uses a small set of boxes between the edit summary box and the minor edit checkbox that dynamically add notices in the edit summary (e.g. clicking "орфогр." and "пункт." puts "орфография, пунктуация" - "spelling, punctuation" in the edit summary box). Try editing a page over there to see what it looks like. —Admiral Norton (talk)
http://ru.wikipedia.org/w/index.php?title=Московский_метрополитен&action=edit is a link. Perhaps something like this would increase people's willingness to complete edit summaries? –MT 22:33, 9 May 2009 (UTC)[reply]
Seems very nice to me. We could at least do it as a gadget. DGG (talk) 06:12, 13 May 2009 (UTC)[reply]
Does anyone know of any scripts that implement this? M 15:05, 13 May 2009 (UTC)[reply]

Asterisk beside resolved proposals

I've been trying to make this page a bit easier to use by slapping "resolved" templates on proposals that are very obviously over (or that seem to have run their course, like the US-bias proposal). If nobody objects, I'd like to add an asterisk to the front of proposals that have been resolved, or perhaps "[resolved]". This might make things easier to navigate in the archives, too. –MT 20:20, 10 May 2009 (UTC)[reply]

M; it ain't broke. There are so many hypothetical ways of clearing up this page, but I think it works fairly well as it is. ╟─TreasuryTag►contribs─╢ 20:24, 10 May 2009 (UTC)[reply]
I agree with Treasury Tag. I'm guessing from your comment in the section above that you're waiting to pounce with the {{resolved}} tag there too. It's just not necessary, and it could stifle further discussion. Happy‑melon 20:27, 10 May 2009 (UTC)[reply]
I've been trying to keep up with every proposal on this page. Though this page might be easy to use if you're just looking at the proposals at the very bottom, it's difficult to keep track of proposals if you're trying to make sure that proposals are addressed. If I have added the resolved tag to any proposal that seems to require further discussion, please let me know. I've avoided putting it on many of the proposals above in favor actually leaving a comment to help try to get them resolved. Not being able to tell which proposals are resolved makes it difficult to find any proposal at all to comment on. I think that this is one of the reasons people tend to ignore proposals at the top, and I think that this will remedy that. –MT 20:39, 10 May 2009 (UTC)[reply]
Come to think of it, I've noticed you making quite a few edits to this page over the last couple of days aimed at hastening discussion along so that it can be removed. Your policy suggestion above was just instruction creep, and this page (and Wikipedia) has survived - exceptionally well, as it happens - without such intervention for many years. ╟─TreasuryTag►contribs─╢ 20:32, 10 May 2009 (UTC)[reply]
This isn't a policy, I'm just asking if other participants will have serious objections to me adding an asterisk to titles that appear to be resolved. –MT 20:39, 10 May 2009 (UTC)[reply]
I didn't say it was a policy, and the fact that you managed to misinterpret my quite simple comment is a strong indication that you shouldn't be, as seems to be your wish, the sole, final and ultimate judge of when a proposal has consensus or not; I'm merely making a general comment that your actions on this page, while no doubt well-intentioned, are overkill, and I urge you to slow down and consider the fact that the system has always worked. Thanks. ╟─TreasuryTag►contribs─╢ 20:45, 10 May 2009 (UTC)[reply]
Sorry, what above policy suggestion are you referring to? Given the number of proposals in archives that have consensus, I don't agree with you that this system works as well as it can, so I'm doing my best to improve it. –MT 20:50, 10 May 2009 (UTC)[reply]
I was referring to the one in which you proposed a complicated, bot-operated numerical system for judging consensus. And while you may think that the system needs desperate overhaul, the large numbers of people who objected to that proposal, who are objecting to this proposal, and who were a bit put off by your comment in the section directly above this one, should be food for thought. ╟─TreasuryTag►contribs─╢ 20:53, 10 May 2009 (UTC)[reply]
I think you might be misrepresenting that proposal and my attitude towards this system. –MT 20:59, 10 May 2009 (UTC)[reply]
It seems kind of pointless, I don't see many discussions here which need a resolved tag (or an asterisk or whatever). It gets archived anyway by the bot in so many days if no new comments appear. Garion96(talk) 20:43, 10 May 2009 (UTC)[reply]
Ok, but do you object to me doing adding the asterisk? It would really help me keep better track of proposals. –MT 20:50, 10 May 2009 (UTC)[reply]
Since it seems you are the only who wants/needs this. Yes, I object. Garion96 (talk) 21:56, 10 May 2009 (UTC)[reply]
I didn't say anything before about this, but I think M has really REALLY stepped over the line. I've NEVER seen such major pushing of trying to close discussions on this or any other page on WP before, and it's akin to locking a topic in a forum because the question is answered....except that being WP 'anyone' can do it. This is a REALLY HORRIBLE precident, and I don't mean to assume bad faith, but it's a HUGE pet peeve of mine when threads are not allowed to die their natural death. This page has survived with bot archiving (and manuel archiving before it) just fine, there's no reason not to allow late comers to add their input, even if something is seen by someone else as 'resolved'. It's pretty much the antithesis of what WP is all about. Leave the forced archiving to flamefests and trolls. If I didn't think I'd get reverted, I'd go ahead and remove all the ones M messed up. ♫ Melodia Chaconne ♫ (talk) 20:59, 10 May 2009 (UTC)[reply]
I didn't think I was using the resolved tag to "close" discussions, I was using it to a) mark discussions that were resolved as resolved and b) summarize the outcome of such discussions so that it is easier to look through later. I certainly didn't intend to "close" discussions. Just as I'm able to add the 'resolved' template, anyone is able to remove it. Should I change it to say "please remove this template if adding more comments to this discussion"? Which discussions are you referring to? I looked through them all just now, and most of them seem quite clearly finished. –MT 21:13, 10 May 2009 (UTC)[reply]
Well I was more talking about the use of the archive templates to prevent further discussion than than the resolved checks (which, incidently, are usually put at the top of the thread). Those are ok if there's actually someone that's been /resolved/ (like a person asking for specific help, or the proposal already fixed), but a simple "no I disagree" by a few people isn't really 'resolution' even if it means nothing will change -- and even with the checkmark people are still free to add their input if needed. ♫ Melodia Chaconne ♫ (talk) 22:18, 10 May 2009 (UTC)[reply]
Oh, ok, sorry about that. I skimmed through that discussion and it seemed that large parts of it were finished. I put tags around it because it was becoming difficult to render this page given that that particular proposal takes about 1/4th of it up when expanded. I added the resolved on that proposal because the proposer seemed to have retracted it. Sorry about that - would you still like me to remove the collapse templates? –MT 22:26, 10 May 2009 (UTC)[reply]
No, just don't do anything. We don't need {{resolved}} or an asterisk with every old topic. Garion96(talk) 21:56, 10 May 2009 (UTC)[reply]
Well, I'd like to comment on them and say that I think that they have been resolved. That way, people looking through the archives will have a better idea of which ones haven't been. I'd also like to give a summary. How should I do this in a way that doesn't bother you? I'd like to use a small graphic so that it's a bit easier for people to spot later. –MT 22:08, 10 May 2009 (UTC)[reply]
  1. Suggestion to make Cancel button noticeable
  2. Watched counter
  3. Make the Watchlist more like an Inbox
  4. Watchlist alerts
  5. [R] Welcome to Wikipedia (United States)
  6. [R] Talk subpage for references
  7. [R] Can we make a sub-section for intro?
  8. [R] Adverising Campaign for Wikipedia
  9. History tab at the top
  10. [R] search bar!!
  11. Tracking potentially dated terms
  12. [R] Suggestion to include eyePlorer.com into ...
  13. Making the font size smaller for inline citation ...
  14. Source verification process
  15. Have redirects to redirects redirect
  16. Articles on no watchlists
  17. [R] Names on wikipedia.org page
  18. Disabling "create a book"
  19. Facilitation rather than Mediation
  20. Summary List
  21. [R] Local version of Wikipedia
  22. Watchlist in other projects
  23. [R] Tagline
  24. [R] No archiving of proposals
  25. [R] Section with logical progression of acade...
  26. Create an article
  27. Getting reverting changes to not show up on ...
  28. Beneficial links
  29. Asterisk beside resolved proposals

The toc would end up looking something like what's to the right. Do others use the toc to find proposals to comment on, or do they just look at the proposals at the bottom of the page? –MT 22:02, 10 May 2009 (UTC)[reply]

Yep, that's prety horrible and way too much instruction creep. This page works fine as it is. Garion96 (talk) 22:05, 10 May 2009 (UTC)[reply]

Don't archive discussions until they are closed

I my view, good idea is to leave discussions on this page until they are resolved, this way, we won't need to add a "resolved" template, asterisk, or "[resolved]" note. When they are resolved, they should be immediately archived. This way, unresolved posts don't get archived. Who supports or opposes this? -- IRP ☎ 21:18, 10 May 2009 (UTC)[reply]

I get the feeling, given the above responses, that if anyone tried to do this, even for proposals that are very obviously closed, then they would wind up flogged very badly. I've tried to leave a comment expressing my view that they are closed by leaving a signed 'resolved' template, to help people go through this page. I think this is a good alternative, since it lets anyone open the discussion back up - it's much harder to open a discussion if it's been archived. –MT 21:25, 10 May 2009 (UTC)[reply]
What is "resolved"? How do you define "resolved"? More importantly, how do you define "resolved" without needless bureaucracy or legalesse? Happy‑melon 21:25, 10 May 2009 (UTC)[reply]
You look at the proposal, and if the author says "oh, thanks, that works" (or a clear solution has been given) and nobody's commented for a few days, you use the resolved template to say 'hey, looks resolved to me', and then you hope that nobody disagrees with you. If you're not sure, then you ask participants whether they think the discussion has the capacity to go further. –MT 21:31, 10 May 2009 (UTC)[reply]
And this serves what purpose? You're essentially saying we should highlight the set of proposals that every sane commenter can identify, to aid recognition of that set?!? Happy‑melon 22:12, 10 May 2009 (UTC)[reply]
Right, but instead of having to read through every single proposal to figure out that it's been resolved, they can just look at a little symbol that represents a consensus that the topic is resolved. –MT 22:14, 10 May 2009 (UTC)[reply]
Or they can actually read the discussion they are interested in, see if they want to comment or not even if the discussion is over. And by over I mean no new comments in a while, I don't mean changing of the header to indicate this, or an asterisk and please not a {{resolved}} tag either. Garion96 (talk) 22:19, 10 May 2009 (UTC)[reply]
Or you could do a bit of reading. One assumes anyone coming to this page has that ability (that was a bit of a joke). ♫ Melodia Chaconne ♫ (talk) 22:21, 10 May 2009 (UTC)[reply]
Well I'm sure that the little R won't induce dyslexia :) They can still read, but they now have a bit more info about which proposals need their attention more –MT
They would also break any links people have made to the section. Anomie⚔ 03:38, 11 May 2009 (UTC)[reply]
Yes, but in that case it'll only take them to the top of the page, and they can find the section from the TOC. And in practice the things we're talking about applying this to are almost never going to be sectionlinked from elsewhere. Rd232 talk 03:44, 11 May 2009 (UTC)[reply]
The archive-bot does far more damage to inbound links. –MT 05:47, 11 May 2009 (UTC)[reply]
True. Perhaps User:ClueBot III should be used for the archiving? Anomie⚔ 16:15, 11 May 2009 (UTC)[reply]
What does that bot do differently? M 20:37, 11 May 2009 (UTC)[reply]

Comment - I may be in a minority of two, but I totally see what M was trying to do and would support it. The idea that this page isn't broken is laughable. An aid to readers of this page to skip things that are clearly history (it's not like it's deletion - titles remain, and even collapsed content is still easily accessible) will make it easier to focus on the other things. People's ability to read is not the issue - efficiency is. M's approach seems perfectly sensible and the things he archived in his initial test are things surely everyone can agree with. A standard any higher would be problematic but what he's proposed seems useful to me. I'd certainly support a test - if the sky falls on our heads if people hate it after a week, we can get rid of it... Rd232 talk 03:44, 11 May 2009 (UTC)[reply]

Discussions here don't need to be "closed" - this isn't a bureaucracy; we don't need to rubber stamp everything. Changing the section heading will break any existing links to the section, so please, if we do have to do this, don't do that, that's, frankly, a really poor idea. From my experience, the resolved template has 2 real purposes: On pages like WP:BOTREQ or WP:HD, to indicate when a task has been quantifiably completed or a question clearly answered, or, on discussion pages, to shut down discussion without actually archiving the discussion. Technically the discussion is still open, but its "resolved" so most people won't comment. I would have no problem with early archiving of proposals where the proposer explicitly indicates they no longer support it, there's no useful discussion other than for the specific proposal, and its clear that it doesn't stand a chance at success. But in any other case I see no reason to stifle or hide a discussion early. Mr.Z-man 04:29, 11 May 2009 (UTC)[reply]

Faderesolved.png
People often throw around the words "bureaucracy" and "instruction creep" and the like (usually to kill proposals), but I suspect that these are used more to sway opinion than to describe anything actual. Wikipedia's problem isn't bureaucracy, it's a painful lack of formalized policy. This isn't just my opinion - the recent usability study results back this up. It's hard to figure out what is expected, what should be done, what shouldn't. Our policies and processes, save for a few, are shallow, redundant, and unspecific. Right now on this page we have "someone proposes, a few people comment". I'd like to see it move towards "Proposal, non-hostile suggestions/improvements/criticisms, resolution+death or: specification, support established, determine goal and next-step towards implementation, track it". This isn't a binding rule, it's a way to get proposals implemented. Please find me a proposal that we've seen to implementation, and I'll find you five that we've let die. We need to spend more time developing these proposals. Yes, they become much less fun when you get down to the details. Yes, it's much more fun to see the latest cool ideas, and to fill up 1/3rd of this page with 'discussion' about US-bias on Wikipedia (am I mistaken, or was that a policy proposal?). I wrote a script (screenshot on the right) that now tells me which proposals have consensus resolutions, perhaps someone in HD will find it useful. I still think that [marking] them for everyone would be useful, since it would provide focus. Resolved proposals don't need the inbound links. For continued discussion about my closed archiving proposal, come to my talk; if it's about policy, let's take it to WP:PROJPOL. Otherwise, let's stick to the issue of modifying titles, and avoid calling the addition of an asterisk to help people find things bureaucratic. –MT 05:45, 11 May 2009 (UTC)[reply]
Putting aside your accusation of me being a straw man, the lack of "formalised policy" is absolutely deliberate. There are always exceptions to everything, and any bureaucratic system is instruction creep. If you click on that link, and read the example given on that page, it says: "Instruction creep begins when someone thinks 'This page would be better if everyone was supposed to do this' and adds more requirements. Procedures are popular to suggest but not so popular to follow, due to the effort to find, read, learn and actually follow the complex procedures." That "example" is precisely what is going on here.
Also, I'd just like to point out that - while you seem to think everyone here is out to get you ("People often throw around the words 'bureaucracy' and 'instruction creep' and the like, usually to kill proposals, but I suspect that these are used more to sway opinion...") I would point out that the numerical count, as well as the weight of opinion, does seem to be firmly against you, and against your actions here. May I just ask; will this encourage you to think more carefully before stepping in to "deal with" discussions here? Or is everyone here wrong? Thanks. ╟─TreasuryTag►contribs─╢ 07:16, 11 May 2009 (UTC)[reply]
(I think you misunderstand what a straw man is.) I want to focus on this proposal, not on policy. If you'd like to do that, come to WP:PROJPOL. If you'd like to talk about me, then come to my talk. Spending your time talking about me isn't going to advance your position. Stop speaking for other people and evaluating consensus on a topic that clearly doesn't have it. Again, let's please keep the comments to the proposal. Should we or should we not establish a rule that prohibits editors from adding an asterisk to headings? –MT 07:33, 11 May 2009 (UTC)[reply]
Yes, sorry, I do know what a straw man is, I mis-wrote.
Yes, we should establish a rule prohibiting people from messing up the toc with asterisks. It's sad that Wikipedia has existed peacefully without such a rule for many years, but I have a feeling that explicitly implementing such a policy is the only way to prevent you from doing it.
This issue clearly DOES have consensus, and I am not speaking for anyone else. I am reading the discussion, and counting 6 people against your proposal (most of whom have also spoken out, here, in this section, about your general actions on this page) and only 2 for. While that's perhaps not a solid consensus, it's a fair indication, and that's what I was pointing out. ╟─TreasuryTag►contribs─╢ 07:42, 11 May 2009 (UTC)[reply]
By the way, could I just re-ask this? And an answer would be nice. Will the balance of opinion on your actions with regards to this page encourage you to think more carefully before stepping in to "deal with" discussions here? Or is everyone wrong? Thanks. ╟─TreasuryTag►contribs─╢ 07:56, 11 May 2009 (UTC)[reply]
You can ask me this on my talk page. I want to stay on topic. M 08:39, 11 May 2009 (UTC)[reply]
<undent>Let's not tally consensus while we're still discussing. What is the problem with an editor adding an asterisk? What is the argument against it? Will links break? Will it be hard to read? Will it be displeasing to the eye? –MT 08:00, 11 May 2009 (UTC)[reply]
  • I see no reason not to tally consensus.
  • It will be displeasing to the eye, and it is just un-necessary. It encourages hastening of discussions, such as you've been doing above, sets a harsh workflow on the page, and is an unpleasant precedent.
  • I'm talking about your actions on this page generally. Including the comments like, "Anyone else got anything to say on this?" And the proposal that all ideas with 15 comments of which at least 4:1 support are archived separately, or whatever. And this one here. ╟─TreasuryTag►contribs─╢ 08:10, 11 May 2009 (UTC)[reply]
Which discussion has been hastened by that template? What does "harsh" mean? What is it an unpleasant precedent for? Please provide reasons and arguments, not just statements. And please stop misquoting me. –MT 08:20, 11 May 2009 (UTC)[reply]
Are you just trolling now? ♫ Melodia Chaconne ♫ (talk) 11:29, 11 May 2009 (UTC)[reply]
I genuinely do not understand what is meant, and am trying to list the specific parts I don't understand. I'd like to know what the harsh workflow is, and what we are on a slippery slope towards. The text in quotes above purports to be mine, but please scroll up and verify that I'd never said that. There's a substantial difference in tone. If you can paste my text, why not do that, rather than put it in your own words? M 20:28, 11 May 2009 (UTC)[reply]
From my experience, people generally just throw around "usability problem" when they want to push some new proposal forward, since anyone opposing fixing a usability problem obviously hates new users. I don't see where the usability study results concluded we need more policies, could you link to that? The problem is not lack of rules, the problem is too many rules and documentation, poorly presented. New users can't find the rules, and then when they do, they're overwhelmed. In any case, the usability study was about editing articles, not proposing policies.
The resolved template doesn't hasten discussion, it kills it. Most people will not comment in a thread marked resolved. On some pages, the resolved template will trigger the bots to archive the thread faster.
I don't see why its such a huge deal to require the person who starts a proposal, or the people who support it, to do the follow-through for implementation. Personally, I feel that if you are not able to, or don't want to implement your idea yourself, you should find someone willing to do so before proposing it or make it clear in the proposal that implementation has not yet been worked out. Imagine if real life worked this way: Someone submits a bid to a local government to build a road, then when their bid gets accepted, they turn around and say "well, we don't actually have any construction equipment, or engineering experience." I don't see why we should make it easier for people to do a half-assed job. Mr.Z-man 15:37, 11 May 2009 (UTC)[reply]
Yeah, I think you're right about that, though I think I've avoided saying this proposal was a problem for new users. I have a section on my talk page with comments on the usability study and policy. I think the problem is the poor presentation of rules, not the rules themselves. We have rules and conventions even when we don't write them down. If we deleted 3RR, you'd still get blocked for edit warring. But this is a separate (though interesting) discussion.
I agree with the bids example, but what I'm pushing is that we take more responsibility for implementation than we do now. Imagine a company with a suggestion box right outside its front doors. They have a meeting, sort the wheat from the chaff, and then mail the proposal to the person who submitted it saying "great plan, now implement it". I'm not saying that this page is like a suggestion box for a corporation, but it's not like a contractor's bid either. It's something in between. If people are taking the time to suggest, let's spend a bit more time on the implementation aspect, because I think we entirely let that slip by. But this is a separate issue too, and might belong in WP:PROJPOL.
One of the reasons people may avoid commenting on threads marked resolved is that they are in fact resolved. I've been asking for some specific case where that template I added was inappropriate, so that I could understand where the problem is. Do you mean the us-bias thread? I agree that if I had slapped it on any one of the conversations that I've been very careful not to slap it on, then this would be bad. But I think I've applied it appropriately. I don't think it's shut down discussion. And I think that it has made it easier for some editors to find unclosed discussions, because there seem to have been more edits to discussions near the top. I could be wrong! but I'd like more information.M 20:28, 11 May 2009 (UTC)[reply]
My comment was based on the actual, published results of the study so far from [2] - "Before subjects even hit the ‘edit’ or ‘edit this page’ buttons, they voiced concerns about the rules, proper etiquette, formatting, and were naturally conscientious of and inhibited by maintaining the community expectations. When a few of them attempted to find answers to their questions about rules and etiquette, they were overwhelmed with the amount of information and documentation they encountered."
I disagree about what the purpose of the page should be. There's 2 common "misuses" of this page that I see a lot.
  1. Technical proposals – Unless its a case of an existing feature where the proposal is just to turn it on/off for the English Wikipedia (a configuration change or installing an existing extension), the existence of a straw poll or a proposal on the English Wikipedia will likely not determine whether a developer works on it. At best it will be an influence. Positive response might encourage a developer with ties to Wikipedia to work on it; negative response might discourage work, but except for configuration changes, the developers are not bound by local consensus.
  2. Vague ideas – I have no problem with people coming here to bounce ideas off of people to see if there's interest, to finalize some details, or decide on an implementation for a real proposal, but such threads should make it clear that they are not a real proposal and that they're looking for comments, not consensus. I've seen people start straw polls on vague, theoretical ideas.
The comment about the resolved template was primarily from other places, mainly WP:AN and WP:ANI where its used to stop a discussion without requiring as much boldness as {{Archive top}}/{{Archive bottom}}. This is why we need the {{unresolved}} template, so that people can boldly restart the discussion. Mr.Z-man 21:17, 11 May 2009 (UTC)[reply]
Well, there are a couple of reasons to start a straw poll: "hey, is this worth figuring out how to do?" and "ok, here's how - good plan or bad plan?". About developers - the tech VP is for tech support, more or less. Then there's a policy VP. So... what's this pump for? Well, the rest. But if you look at what they come down to, the majority end up being to do with software. Regular readers don't go to bugzilla to sort insects, they come here. If the developers aren't connected to actual requests, like you say, then what are they working on? They're doing a fine job, but I don't think they're reading pages like this - which might be the reason we need a usability study in the first place. "The devs don't look here" isn't a good excuse, I think. M 02:25, 12 May 2009 (UTC)[reply]
You seem to have somewhat read past my comments. I'm not sure what you mean by "the developers aren't connected to actual requests" - I don't believe I said anything like that. The developers, as volunteers and not all associated with the English Wikipedia, are not required to act on any consensus here, unless its a configuration change for this site only. With the exception of a few paid developers, the developers work on whatever they want to work on. But the English Wikipedia has about as much control over MediaWiki development as it does over the policies of the English Wikibooks. Mr.Z-man 06:01, 12 May 2009 (UTC)[reply]
Discussions here won't be binding, but they should be informative. Better communication will make things easier for both devs and editors. M 06:33, 12 May 2009 (UTC)[reply]
Um, okay, I'm not sure what that has to do with what I just said though. Mr.Z-man 16:23, 12 May 2009 (UTC)[reply]

After all this discussion, I'm still none the wiser why people oppose this proposal. There's much talk of (a) bureaucracy even though there are no extra hoops for anyone to jump through to get something done; it's just an optional tool for making this page more manageable and (b) of "shutting down discussion", which on the proposed standards for applying these tools just isn't the case (plus this page is different from ANI etc - a good idea can always be reposted, probably in a form which is better for having been discussed previously). (Nor, if anyone disagrees in a particular instance, do we need an "unresolved" template - just remove the resolved template! By definition if someone wants to remove it the issue isn't resolved!)

So let's boil it down: if the proposal was to provide these tools but they could only be used by whoever proposes a particular proposal, if they wish to be helpful to readers of this page (=optional, mmkay?) would that be OK? The only problem I see with that is the section title thing, which is a pretty minor hypothetical benefit (archiving breaks it much more badly; after Resolving but before Archiving you'll still come to the TOC), against the concrete substantial benefit of making this page more readable. Rd232 talk 22:55, 11 May 2009 (UTC)[reply]

Is there a reason why adding a {{resolved}} tag, like the way we do now, is somehow inadequate? And what is this "concrete substantial benefit" that you speak of? Is the page somehow unreadable at this time? —kurykh 23:33, 11 May 2009 (UTC)[reply]
"like we do now"? AFAIK we don't do this now! That's what the proposal is about (I thought)! Also, additionally identifying resolved proposals in the TOC seems obviously helpful/time-saving to me. And yes, the page at the moment generally has too much stuff which isn't worth reading because the issue has already been resolved. Frankly for most of my WP life I've ignored this page because it's just too much chaff and not enough wheat - and I can't believe I'm the only one. Rd232 talk 23:55, 11 May 2009 (UTC)[reply]
1) If people start changing section headers to add an asterisk or something, I will be reverting it. An optional thing to help some people should not annoy other people. 2) The added bureaucracy is that proposals won't be archived until they're implemented, or something. This section is titled Don't archive discussions until they are closed - that doesn't sound very optional. 3) A discussion is done when people stop discussing, why must we tag the discussions to indicate this? At best, its making a pointless edit to state the obvious, at worst, it might scare away comments from people who don't want to post to a discussion that's already "resolved." 4) Adding resolved tags doesn't make the page more readable. This argument seems to be based on the reasoning that if a thread has a {{resolved}} tag, people will just skip it, but why would they do that? If they want to see what its about, they'll read it regardless of the tag. If they want to comment, they'll do so regardless of the tag (and if they want to comment, then the discussion wasn't over, and it shouldn't have been tagged in the first place, bringing us back to point 3).
The best argument I've seen here is that it makes some scripts easier to code, which isn't very convincing. Mr.Z-man 02:31, 12 May 2009 (UTC)[reply]
The discussion can deviate from the subheading back to the original topic, and clearly it has. I've changed several headings on this page, and I can't imagine how this could have annoyed anyone. "It annoys me" isn't a good reason - "it's distracting" or "it's rude" or "it breaks links" are good reasons. Some people appreciate a focus on discussions that have not ended, if you want to read everything you are still able to. It seems to me that a discussion is 'done' when it gets archived: I think that a person is a much better judge of "done" than an archive bot. M 03:02, 12 May 2009 (UTC)[reply]
Wow. (1) What's so "annoying" about a tiny change to a section heading? This mystifies me. (Apart from the fact that it is a style preference, not an argument.) (2) this point of yours is based entirely on a section heading ("Don't archive discussions until they are closed") added by someone other than proposer with no relation to the proposal. This is not helpful. (3 and 4) your points are contradictory - either you're going to scare people off (from obviously resolved discussions - the standard proposed for Resolved tagging) or not. And it does make the page easier to read/navigate/keep up with / whatever you want to call it. You may not think it worth the cost, but how you can't see this benefit is beyond me. (5) scripts, for me, are irrelevant to this (except that the archive bot already does this "discussion closing" in a much more brutal way - got a suggestion to improve that?) Rd232talk 03:14, 12 May 2009 (UTC)[reply]
I don't know about you, but things that are distracting and rude tend to annoy me. On watchlists and page histories, the little arrow in the edit summary links directly to the section, however, if someone changes the section header, like to add an asterisk, they no longer work. My points 3 and 4 are not contradictory, they simply provide 2 distinct possibilities, neither of which are good; not every person will act the same. I disagree that a person is always better. Bots have no biases and can be trusted to apply the same standards equally to all proposals and I disagree that we need something better than the archive bot. If the issue isn't scripts, what the hell is it? What is the benefit to tagging proposals as "resolved"? A discussion is done when people no longer discuss it. Why is this so difficult to comprehend? The bot seems to do it just fine without people fucking with the section headers, or adding obvious-stating templates. How does it make the page easier to read? Just saying it does so does not make it so. People will know what proposals have been declared "resolved" by some random person. But that's likely not going to change whether or not they want to read about it. Do you expect people to think: "Oh, that sounds interesting, but its resolved, so I won't bother reading about it"? If people are interested in something, they're going to read it. It may prevent them from commenting on resolved proposals, but why would we want to do that? I guess to summarize: Why do we not want people to read or comment on "resolved" proposals? Mr.Z-man 06:01, 12 May 2009 (UTC)[reply]
How exactly is an asterisk distracting and rude? Or "[resolved]", for that matter? Inbound links are a non-issue, the bot already destroys them. There's nothing stopping your hypothetical biased editor from messing with this page right now, so I don't see the problem there, either. We have 34 proposals on this page, please don't tell me that this is casual reading material. Do you not see a difference between a proposal where the editor says "oh, that fixes it" and this one? M 06:33, 12 May 2009 (UTC)[reply]
Are you really that dense? Inbound links are an issue. After 7 days of no comments, there will be no links to them on people's watchlists, so a bot archiving it isn't a problem. But if the discussion just ended, then people may still see may be following thread on their watchlist. Why can't it be casual reading material? You can't just say stuff like that and declare it to be true. What does there being 34 proposals have to with anything? If there were 15 would it be different? 674? Are you saying that there's a lot of people who come to this page once a day and just read the entire thing top to bottom? That's the problem I have with your proposals! You just keep saying stuff to back up your proposals with no evidence or logical reasoning whatsoever. If you actually read my comments instead of just misinterpreting them, you'll see I did say I have no problem with people tagging obviously implemented or rejected proposals, though I think its a waste of time to state the obvious. My problem is with encouraging it. From what I've seen on other pages, {{resolved}} has 2 uses. About 50% of the time its used to mark an obviously resolved thread. This is more useful for pages like WP:AN, where a significant majority of threads will be resolved quickly. The other 50% of the time, its used when people want a thread to be resolved. The discussion may not be over, and nothing actually done, but the discussion is getting less productive or turning toward an area that someone doesn't want it to. Give some real evidence or logical reasoning, and maybe I'll reconsider. Mr.Z-man 16:23, 12 May 2009 (UTC)[reply]
Z-Man - "People will know what proposals have been declared "resolved" by some random person. But that's likely not going to change whether or not they want to read about it. Do you expect people to think: "Oh, that sounds interesting, but its resolved, so I won't bother reading about it"? If people are interested in something, they're going to read it. It may prevent them from commenting on resolved proposals, but why would we want to do that? I guess to summarize: Why do we not want people to read or comment on "resolved" proposals?" I've already explained this multiple times. The fact that you have not yet understood the proposal's advantages helps me understand your confused and unhelpful and increasingly irritated responses. Please go back and read my comments above, especially my comment about an alternative version where only the proposer can close his discussion as a courtesy to others. Rd232talk 12:18, 12 May 2009 (UTC)[reply]
No, my confused and irritated responses are from you and M misunderstanding and misinterpreting my arguments, then replying with faulty logic and repeated arguments. Mr.Z-man 16:23, 12 May 2009 (UTC)[reply]

★Random section break [☢adding asterixes to resolved sections☂]

Incidentally, I notice that you're very anxious to draw a quick end to others' discussions - how would you feel if someone put something like that on this discussion? You told me off for pointing out a 6-2 consensus against your idea earlier; I think it's a fairly clear-cut issue. So, as a hypothetical test issue, if you came across this proposal, how would you treat it with asterisks? ╟─TreasuryTag►contribs─╢ 07:06, 12 May 2009 (UTC)[reply]

You seem to favor attempts at caricature of the opposing position. This is fun and popular, but a bad way to argue. Please respond to what I'm actually saying, not to an exaggerated version. You've said discouraging things in this discussion multiple times, but I've toughed it out. It's absolutely not a big deal. You just say "I don't think this is over" and continue the discussion exactly as before. As for this proposal - well, it's not sick, it doesn't need to be treated with asterisks. When it looks like it's over, I'd probably do something like the above. Also, my proposal isn't to insert random meaningless unicode garbage into headings. M 07:50, 12 May 2009 (UTC)[reply]
I do favour caricature, yes, it's called humour :-) I'm asking you a direct question; in the link I provided, you were attempting to hurry along discussion and bring it to a close. Would you do the same on this one if your new systems of asterixes were implemented? Thanks. ╟─TreasuryTag►contribs─╢ 07:53, 12 May 2009 (UTC)[reply]
Caricature is funny, but you can do it without misrepresenting my position. You can call me Ptolemy and talk about how you don't want to see Cassiopeia in the ToC. But you're not being that funny, because all of your arguments are against a position that isn't mine. I see that you put the unicode garbage back. Would I put [resolved] on this proposal once it's clearly been resolved? Yes, of course I would. M 08:09, 12 May 2009 (UTC)[reply]

<< I am arguing against your position, without misrepresenting it. You are misunderstanding my position (did that possibility ever occur to you?). I object not only to your asterixes idea for this page, but also generally to your other proposal above - regarding archival after a certain ratio of support or opposition has been garnered - and to your comments on this page designed to speed up others' discussion... like the one I linked above. You can see how many people agree with you, and you can see how many agree with me. This page has worked well for a long time without comments like, (and I quote) "Anything else to say about this one?" about half-an-hour after the discussion was opened. That is all I have to say on the matter, other than the fact that it's not garbage, it's an amusing hyperbole of your policy idea (I quite like the notion of adding radiation symbols to some discussion threads, come to think of it!) ╟─TreasuryTag►contribs─╢ 08:19, 12 May 2009 (UTC)[reply]

Look at the heading of the other proposal - it says resolved. Clearly the addition of asterisks would help you :) I have no idea why you're bringing that up here. And what does my message above have to do with anything? I certainly hope that "look how many people disagree with you" is not your only argument, since that isn't an argument. M 08:31, 12 May 2009 (UTC)[reply]
Shouldn't that be look how many people disagree with you?? Much more importantly, look at the arguments they have presented. The question as I see it is, why is breaking external, internal and historical links, annoying editors who dislike the stylistic changes, actively discouraging further discussion of topics (and proactively closing discussions that in some cases have barely even begun), introducing bureaucratic and legalistic rules for section archiving, removing the incentive for proponents to actually do some of the work of getting their proposals implemented, and making essentially useless edits to state either the dubious or blindingly-obvious, justified by the arguments you present in favour? Naturally that is not the question as you see it; you (must) have an entirely different assessment of the balance of advantages and disadvantages. To avoid TLDR syndrome, it would probably be a good idea to summarise them similarly. Happy‑melon 11:44, 12 May 2009 (UTC)[reply]
"removing the incentive for proponents to actually do some of the work of getting their proposals implemented"? It mystifies how experienced editors can get so confused about what a fairly simple proposal is actually proposing. Resolved would not be applied to anything that required future action. Because, erm, that would mean it isn't resolved. Cough. Rd232talk 12:21, 12 May 2009 (UTC)[reply]
This was point 4 of M's proposal above. To which you or someone else is going to say "yes but that was retracted/rejected..." So what? The 'closing' comment "I retract the proposal" makes the exact same mistake B Fairbairn made above with refactoring discussion: proposals don't 'belong' to the person who suggested them, they don't have 'control' over them. Proposals are considered on their merits (or lack thereof), it's not the OP 'verses' the rest of the community. Which is not to say (to cover the original point) that the OP is not responsible for taking a proposal forward if there is consensus to support its implementation. You're quite right that marking proposals as "resolved" when they have not been implemented would be semantically wrong. M's proposal, seemingly intended to reduce the amount of inactive discussion on this page, ironically required that proposals that had been made and then 'abandoned' by their OPs be left on this page indefinitely, until "responsibility for implementation [is] accepted" by someone. So an OP can make a proposal, then drift away, confident that it will remain here until someone get sufficiently annoyed by its presence to take on responsibility for it themselves. That sounds like removing incentive to me.
Of course I'm treating the two proposals as linked here, when it's true that one (the rejected process) is an extension of the other (this marking 'resolved' threads). But if you make the very small further step of saying that only "resolved" proposals should be archived (and take the very axiom that you note, that proposals requiring further action cannot be resolved" then you immediately reach one from the other. Happy‑melon 12:40, 12 May 2009 (UTC)[reply]
Inbound links are a non-issue, the bot already destroys them. Should we move on from this, or are there still concerns? M 13:04, 12 May 2009 (UTC)[reply]
Oh that's ironic. :D Move on in which direction? Happy‑melon 13:18, 12 May 2009 (UTC)[reply]
I don't want to wind up on a wild goose chase. I think most of your concerns have already been resolved. So let's take them one step at a time. Do you have a problem with inbound links? M 13:24, 12 May 2009 (UTC)[reply]
Are you joking? When I saw your previous comment, I thought, oh, he has just come to reason, has understood he will never get consensus, and is going to mark this thread as resolved. Not so, apparently. --Hans Adler (talk) 13:31, 12 May 2009 (UTC)[reply]
I have a nice little JS script that activates on viewing diff pages. If the new edit's editsummary contains a section title, the script looks at the target page, calculates the appropriate section number, and appends that to the "edit" link on the diff. So when I click the "edit" link, I can go straight to editing the section. It's a useful script, you're welcome to use it youself if you want (it's in my monobook.js). It will break if you start changing section titles. People often link to ongoing threads on this page; it's accepted that those links will die when the section is archived. However, they are easily accessible by just copying the section fragment from the URL into the 'search archives' box and looking through the archives, where the relevant section is usually at the top of the search list. I don't know if that method will continue to work if you start habitually changing section titles. I have no particular desire to find out. Bugzilla reports for feature requests usually include a link to the discussion that resulted in the consensus the developers need to see; these links should be made permalinks; when they are not, they will break. Yes, I have a problem with breaking inbound links by changing section titles unnecessarily. Happy‑melon 13:47, 12 May 2009 (UTC)[reply]
Though I don't think the script breaking is a real worry (trivial fix; only one out of the many resolved-marked threads reactivated, so you wouldn't see such diffs), the searching is a good point. Perhaps the bot should be configured to archive resolved discussions more promptly, instead. M 14:31, 12 May 2009 (UTC)[reply]
That is not the point. Of course the script could be fixed, and in the (rather unlikely it seems) situation where your proposal gains consensus, I will fix it, because I am following this discussion and understand why and how it would be broken. How many people and bots will be similarly affected by such a change? You don't know; you can't know, and unless they're following this discussion, they themselves probably won't know why things are going wrong until the bug reports start flying. Now, why should I be forced to spend time fixing my script, so that you can add little asterisks next to certain threads? Are you going to fix my script for me? And any others that are broken, becuase you put them in the same position? Happy‑melon 17:16, 12 May 2009 (UTC)[reply]
Though I still don't think that title change is catastrophic for scripts (I don't think anyone's wiki-lifesupport depends on titles, and several titles have already changed without corpses piling up on our doorstep) I think we might want to put that discussion aside, since I agree with your searching point. M 18:37, 12 May 2009 (UTC)[reply]

M, if your only concern is wanting to monitor every discussion why not just use the history page and compare the most recent version with the last one you looked at? Then you can easily read every new comment without losing track. I don't see a problem with a discussion being live until it gets archived after seven days of no activity. That's a pretty good indication it is resolved. David D. (Talk) 13:56, 12 May 2009 (UTC)[reply]

I do use history, plus the script that I wrote (screenshot above). The problem is that this discussion page contains about 34 proposals. The total time required to read this is 4 hours. Some of these proposals, because a resolution has been reached, are just not worth reading through. Yes, maybe halfway through reading the usa-bias proposal you'll get a great idea about how we can prevent bias on the main page. Probably not, though. There are proposals in the middle (and top) of the page that are as good as the ones down here. I strongly suspect this is because nobody likes sifting through the middle of this page. M 14:31, 12 May 2009 (UTC)[reply]
Is your concern a newcomer? Why would they read every proposal? I only read the ones that have a title of interest, resolved or not. IMO, adding this extra formatting is a classic example of extra bells and whistles that are barely functional but look good. David D.(Talk) 15:00, 12 May 2009 (UTC)[reply]
They wouldn't read every proposal. Perhaps we have different assumptions as to how people approach this page. What purpose does the resolved template serve on, say, helpdesk, and why can't it serve that purpose here? M 18:37, 12 May 2009 (UTC)[reply]
I agree they would not read every proposal. But you inferred that when you said it would take four hours to read. Maybe I misunderstood your comment? My main point is that when I look at the pump page i normally look at one or two topics and ignore the rest whether they are resolved or not. The tags would not save me time and I would not use them to direct my reading. Maybe I am atypical? David D.(Talk) 18:51, 12 May 2009 (UTC)[reply]
I was just trying to give an impression of the size. When I first came here I was overwhelmed by the number of issues to comment on. The easiest thing was to just jump to the bottom, which neglects many proposals. I find that the titles aren't usually a good indicator of interest for me. I can understand that they might be indicators for others. The ones that interest me are the ones that still need attention. M 21:35, 12 May 2009 (UTC)[reply]


Help desk discussions generally don't need more than a couple people to be involved, and have a lifespan of minutes to hours, not days or weeks. The help desk gets a dozen or two new threads every day. Though looking at it now, the template doesn't seem to be used as much on the help desk as it used to be (only a couple threads each day), perhaps they found it to not be very helpful as well. This is a good summary of the problems with the tag there, some of them would apply here as well. Mr.Z-man 19:31, 12 May 2009 (UTC)[reply]
I think that the 'resolved' template is being taken a bit too seriously, though perhaps it could be made more 'passive'. Why should people who come here bother commenting if there are 30 proposals, and half of them look abandoned? The resolved template, aside from providing focus, gives the impression that issues receive conclusive answers. I still have trouble with the 'casual browsing' idea. Resolved proposals shouldn't be kept around so that people could have interesting reading. There's plenty of casual browsing to be had in the archives. Wouldn't you prefer to have a selection of 30 unresolved proposals, rather than a 15, and 15 dead ones? And why even bother archiving if having 30 proposals is no big deal? You might say "well, the bot makes sure it's fair" - but before you say that, show that there's an actual problem of fairness. Where has that template been used improperly on this page? If the bot had a rule 'resolved proposals have a 2-day timeout', wouldn't 'unfairness' be avoidable? To recap: We remove 'resolved' proposals mindlessly using a 7 day rule so there exists a need to remove them; people, though imperfect, are much better at figuring out when a proposal is over than a bot; any 'abuse' can be easily spotted if there's a 2-day delay on the tag. M 21:35, 12 May 2009 (UTC)[reply]
A discussion is "dead" when people don't comment and that's the criteria the bot uses to archive them, so they aren't going to be sitting around "dead" for very long; just long enough to be sure that they really are dead. Right now, 22 of the 34 proposals on the page have had at least 1 comment in the last 3 days.
  • Why should people who come here bother commenting if there are 30 proposals, and half of them look abandoned? - Because once they comment, its no longer abandoned. Or they can just comment on the ones that aren't abandoned. Why would people just leave without commenting because the page has some dead discussions? How is that any different than any other discussion page?
  • Wouldn't you prefer to have a selection of 30 unresolved proposals, rather than a 15, and 15 dead ones? - This proposal is not to archive things faster, but just to tag them, they'll still be on the page, so I don't see how this is relevant. In any case, "dead" is not really a resolution, just a state. "Resolution" means that there's some consensus either way, "dead" just means people aren't commenting.
  • And why even bother archiving if having 30 proposals is no big deal? - Because we get more proposals as time goes on ... ? Is this supposed to be a rhetorical question? Given the context, I can't tell.
  • show that there's an actual problem of fairness - Right now you're the only person using the tag on this page and have only been doing so for a couple days. You're asking me to prove something using evidence from the future, after this is widely implemented. But since you asked, I would call [3] an improper tagging (or at least the closest thing to one since you started doing it a couple days ago). You were involved in the discussion and had indicated elsewhere that you thought it didn't belong on the page, then you tagged it "resolved" just a few minutes after a comment by someone else, and I don't see where the proposer retracted anything.
  • If the bot had a rule 'resolved proposals have a 2-day timeout', wouldn't 'unfairness' be avoidable - I don't see how. If anything, it could make it worse, as it would provide a way for people to get proposals that they don't like off the page faster.
  • We remove 'resolved' proposals mindlessly - We remove dead proposals. The bot makes no judgment at resolved-ness.
The {{resolved}} template works on pages that have a clear workflow like the help desk and the bot request page. It just doesn't make much sense on a page that consists mostly of open-ended discussions. Mr.Z-man 23:58, 12 May 2009 (UTC)[reply]
We don't archive "because we get more proposals" - so what? Just let people keep adding them, and let this page continue to grow. Why do we archive dead proposals, instead of just leaving them? M 00:30, 13 May 2009 (UTC)[reply]
Because letting the page continue to grow indefinitely won't work. We need more space, so given that its a discussion page, if we have to get rid of something, it makes sense to get rid of the things that people are no longer interested in discussing. Mr.Z-man 01:41, 13 May 2009 (UTC)[reply]

OK, I'm withdrawing from this discussion. I guess those who see no problem a all with current VP process can carry on as before, because clearly this proposal is rejected. Anyone opposing who sees the problems raised want to come up with an alternative for improving VP? PS In future we might want to bear in mind the self-selection effect of discussing possible improvements to VP on VP: those who can't stand it probably won't see the discussion! Rd232 talk 03:00, 13 May 2009 (UTC)[reply]

Oh, don't be like that about it. Yes, I'm fairly sure that there is a consensus to reject the proposal, but there's really no need to take the, "Well, more people support it, OK, that's their own funeral," line - really. Encouraging M to make his future proposals somewhere where we won't find them isn't a smart idea, because I have no doubt that he'll follow it - but there we go. ╟─TreasuryTag►contribs─╢ 06:56, 13 May 2009 (UTC)[reply]
(a) what? (b) what? To clarify, I'm not being like anything, this proposal is rejected so let's draw a line under it. There's nothing about "it's their funeral" since I'm asking for new ideas to avoid death! And it is outrageously obvious that I'm not suggesting forum-shopping and not suggesting actively avoiding VP participant input. I mean really. Rd232talk 07:44, 13 May 2009 (UTC)[reply]
OK, I'm really sorry, I obviously misinterpreted your use of phrases such as, "I guess those who see no problem a all with current VP process can carry on as before." ╟─TreasuryTag►contribs─╢ 07:47, 13 May 2009 (UTC)[reply]
As far as the proposal to add a symbol to the titles, I think that Happy-melon's point of objection above was a good one, though I thought that some discussion of the problem in general and other possible solutions might be worthwhile. You may have a point about this not being an appropriate place to discuss things, though. M 14:00, 13 May 2009 (UTC)[reply]
I think this is as appropriate a place as any. But, as always, you will have a limited and self selected audience. David D.(Talk) 14:30, 13 May 2009 (UTC)[reply]
The only other place that would be appropriate would be Wikipedia talk:Village pump (proposals). Making and discussing a proposal to change a page, without at least notifying the people who use the page would be rather inappropriate, and would probably be seen as deceptive or gaming the system, especially given that there's already been 2 proposals on this. Mr.Z-man 16:13, 13 May 2009 (UTC)[reply]
Ah, good. I wasn't the only person with that impression after all. ╟─TreasuryTag►contribs─╢ 19:35, 13 May 2009 (UTC)[reply]
<undent> Well, discussing title-changing policy in general might not belong on this page, though of course editors here should be notified. That's not much of an issue though - I certainly won't pursue it. As for this proposal, I think I should resign in my capacity as promoter since, as Rd232 points out, it's a snowball in it's current form. This particular thread isn't exactly an incubator for some alternative way to resolve the page size, so I should avoid that as well - except, is there any chance that the us-bias thread and this one could be manually archived, given that they take up 1/3rd of this proposals page and have been withdrawn by their proposers? M 02:55, 14 May 2009 (UTC)[reply]