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

삭제된 페이지를 다른 Wiki로 리디렉션하여 삭제된 페이지를 변환하는 중

트랜스위킹의 중요한 점은 많은 독자와 편집자들이 이 기사들을 위해 이곳에 오고 그리고 다른 전문 위키들을 구글로 검색하기 보다는 하나의 주요 위키들을 탐색하는 편리함의 요소가 있다는 것이다. 그리고 나는 위키피디아가 이 다른 위키들에 비해 훨씬 더 많은 편집자들을 끌어들인다고 믿는다. 이것은 우리가 일부 위키피디아를 다룰 가능성을 증가시킨다.이 기사들 중에서 다른 위키보다 훨씬 더 좋은 기사들이다.이제, 우리의 기사들을 다른 위키백과로 옮겼을 때, 우리의 기사들을 허락해 주었지만, 여기서 그 기사들을 작업하거나 사용했던 편집자들과 독자들은 종종 당황하게 된다. 갑자기 당황할 때가 많다.아이디어는 위키 사이의 더 쉬운 탐색을 가능하게 하는 내부 연결과 같은 것일 수 있다.또는 어떤 식으로든 다른 페이지로 리디렉션된 페이지를 삭제한 경우(어쩌면 기술적으로 매우 유용해야 함). --해피 편집! 진심으로, Le Grand Roy des Citrouilles^Tally-ho! 15:04, 2008년 7월 6일 (UTC)[응답]

또 다른 가능성은 외부 링크에 관련된 Wikia 페이지를 갖는 것이다.하지만, 나는 두 가지 제안 모두를 좋아하고 여기 있는 르 그랑 로이의 아이디어가 백과사전을 구현하고 개선할 수 있는 좋은 아이디어라고 믿는다.레드 피닉스^{flame of life...protector of all...} 15:10, 2008년 7월 6일 (UTC)[응답]

참고 항목 - Qwika 및 Qwika - WikiIndex. -- 파장(토크) 15:27, 2008년 7월 6일(UTC)[응답]

최근에 이와 같은 것이 제안되었다. 위키백과:마을 펌프(제안)/아카이브 29#인터위키가 Mr.Z-man 15:36, 2008년 7월 6일 (UTC)[응답]

그 논의 내용을 확인해봤지만, 반대 이유인 '반달리즘 대상'은 대통령 관련 기사부터 내 자신의 사용자 페이지까지 모두 반달리즘 대상이었던 만큼 그렇게 설득력이 있는 것은 아니다. --행복한 편집! 진심으로, Le Grand Roy des Citruilles^Tally-ho! 16:20, 2008년 7월 6일 (UTC)[응답]

• 나는 위키미디어 재단 프로젝트로 전환하는 것에 대한 많은 감각이 있다고 생각한다. 하지만 나는 우리가 적어도 존경할 만한 것으로 연결된 다른 위키들을 기대한다.나는 개인적으로 이것이 실행되기 전에 어떻게 작동하는지 몇 가지 예를 보고 싶지만 나는 가능성이 있다는 것에 동의한다.나는 대부분 면책 조항이 있어야 하는지 궁금하다.스파르타즈^Humbug! 16:56, 2008년 7월 6일 (UTC)[응답]
  • 샘플/실습을 통해 어떻게 작동하는지 확인한 후 작업을 진행하는 방법이 있는가? --해피 편집! 진심으로^Tally-ho! 2008년 7월 6일 (UTC) 17:00 (UTC)[응답]
    • 스파르타즈에게, 그래, 우리는 고지서를 제출하면 된다.우리가 이것을 실행하기로 결정한다면 도움이 될 것 같아.그리고 르그랑 로이에게는 부드러운 리디렉션이 그렇게 할 수 있을지 없을지는 잘 모르겠지만, 가능성이 있다.Red Phoenix 18:54, 2008년 7월 6일 (UTC)[응답]

• 공공 기물 파손 및 스팸 링크 문제를 해결하는 것은 좋은 생각이다.
  1. 페이지를 만들고 완전히 보호할 관리자
  2. 이 페이지를 모니터하고 링크를 끊도록 편집하십시오.보호되지 않은 페이지에서는 봇이 이렇게 한 후 빠른 삭제 목록에 추가할 수 있다.
  3. 그러면 지속적인 스팸 링크가 스팸 사이트 목록에 추가되고 편집자가 해당될 경우 차단될 수 있다.Gnangarra 04:18, 2008년 7월 7일 (UTC)[응답]

이 대사들을 따라, 나는 이 삭제된 페이지들 중 일부를 메인 스페이스가 아닌 위키백과 안에 보관할 가능성에 대해 생각해 왔다.브리태니커 백과사전 사무실에 가면 편집자들이 판본에 맞지 않는다고 판단한 자료들이 실린 수많은 파일 캐비닛을 찾을 수 있을 것 같다.쓰레기와 주공간에 적합한 재료 사이에 중간 지대가 있다.이 자료를 삭제하는 대신 "백파일"에 보관하는 것은 다음과 같은 몇 가지 이점을 가질 수 있다.

• 선의로 페이지를 만든 사람들은 위키백과 내에서 계속해서 페이지를 작업할 수 있다.한 페이지를 삭제하는 것은 종종 우리가 받아들일 수 있다고 생각하는 것을 단지 수줍어하는 페이지에 대한 심각한 반응이다.그것들을 삭제하는 것은 가혹하고 새로운 사람들에게 불쾌감을 줄 수 있다.
• 사람에 대한 기사나 현재 공신력 테스트에 실패한 물건들은 어떤 사건의 결과로 더 주목받을 수 있을 것이다.그 때, 우리는 받아들일 수 있는 물건으로 만들 준비가 되어 있었다.
• 집단지식은 엄격한 검증가능성 지침을 종종 위반하지만, 전혀 유용하지 않다.
• 만약 기사가 삭제되는 대신 뒷파일로 옮겨진다면, AFD에서 훨씬 덜 논쟁적인 싸움이 될 것이다.

실험으로, 나는 이 페이지들을 보유하기 위해 사용자 공간에 더미 계정을 만들었다.기본 계정은 User:파일을 백업하십시오.나는 계정을 소유하고 있지만 편집에는 사용하지 않는다.몇 달 전, AFD 토론에서 제목에 번호가 있는 노래 목록이 삭제된 후, 나는 그것을 내 더미 사용자 계정 중 하나의 하위 페이지로 이동시켰다.이제 User(사용자:위키리스트/제목 숫자가 들어간 노래 목록이 페이지에서 작업한 일부 편집자는 계속해서 페이지에 정보를 추가했다.

나는 여전히 많은 페이지들이 삭제되어야 한다고 믿는다.나는 빠른 삭제를 위한 어떤 정책도 바꾸지 않을 것이다.그러나 AFD에서 현재 삭제된 다른 페이지 중 대부분은 아니더라도 사용자 공간으로 이동할 수 있다.내가 알기로는 삭제된 페이지를 사용자 공간으로 옮겨 작업하고 개선할 수 있도록 하는 정책에 반하는 것이 없다.그러나 이러한 페이지를 더 유용하게 만들기 위해서는 이러한 페이지에 대한 더 많은 링크가 있어야 한다.이전에 메인 스페이스에 적합하지 않다고 판단되었던 페이지가 있었다는 것을 설명하고 페이지가 부적합하다고 판단된 이유의 목록을 첨부하여 이동하는 페이지가 있다면 도움이 될 것이라고 생각한다.그러면 사용자 공간에 이동된 페이지에 대한 링크가 있을 수 있다.프로젝트 외부에 유사한 페이지에 대한 링크도 있을 수 있다.이것은 혼란스러운 페이지와 매우 유사할 수 있다.뒷면 파일이 가득 차면서, 사용자에게 기사의 단점이 무엇인지 매우 명확하게 해주는 템플릿이 만들어져야 할 것이다.또한 이러한 페이지에 대한 범주 분류법이 있다면 도움이 될 것이다.분류법은 다른 범주와 별도로 유지되어야 하지만 적절할 때 연계될 수 있다.예를 들어, Category에 연결된 노래 목록의 백 파일 하위 카테고리가 있을 수 있다.노래 목록.

나는 집합적인 사용자 공간이 그 공간에 있는 기사의 문제점이 무엇인지 투명하고 우리는 쓰레기를 치우는 데 도움이 되는 명확한 기준을 가지고 있는 한 효과가 있을 것이라고 생각한다.심지어 위키피디아를 웹 상에서 훨씬 더 즐거운 곳으로 만들 수도 있다. -- ★ 사무엘완트맨 06:05, 2008년 7월 8일 (UTC)[응답]

더스트박스 정책제안

신속한 경고

나는 최근에 내 토크 페이지에 페이지 작성 후 너무 빨리 태그를 달았다는 관리자로부터 메시지를 받았다.그것은 사실이었을지 모르지만, 그 페이지가 서 있는 것처럼 그것은 확실히 유명하다고 주장하지 않는 것으로 인정받을 만했다.나는 그 페이지에 알림 태그를 붙일 수도 있었지만, 내 생각에는 그것이 그 페이지가 빨리 삭제될 수 있다는 사실을 언급할 수 없기 때문에 이것은 정말 맞지 않는다.실제로 '완전히 삭제됨'이라고 쓰여 있는데, 내가 보기엔 꽤 오랜 시간 동안 삭제되지 않을 것이라고 시사하는 바는, 만약 속도가 빨라지면 몇 분/몇 시간 동안 삭제될 수도 있다는 것이다.만약 내가 새로운 편집자였고 나의 페이지가 알림 태그를 읽은 후에 속도를 냈다면 나는 가장 적게 말하면 놀랄 것이다.그것은 빠른 태그를 페이지에 붙임으로써 편집자가 그들이 유명함을 주장할 필요가 있다는 것을 인식하게 하고 또한 페이지를 관리하게 되는데, 이것은 그들이 기회를 얻기 전에 그것이 사라질 수도 있다는 것을 의미한다.중간 단계로서 "이 페이지는 빠른 삭제에 적합해 보이고 이것을 피하려면 신뢰성의 주장이 필요하다"는 선에 따라 템플릿을 작성할 가치가 있는가?만약 한 시간 안에 한 사람이 오지 않는다면, 빠른 태그가 추가될 수 있을 것이다.이렇게 하면 편집자는 가능하면 페이지를 업데이트할 기회를 얻을 수 있지만, 새로운 페이지를 순찰하는 사람들에 의해 여전히 태그될 수 있기 때문에 우리가 태그를 붙이는 것을 피한다면, 예를 들어, 첫 시간 동안 페이지를 놓칠 가능성을 줄일 수 있다.내가 볼 수 있는 유일한 빠른 기준은 저작권 태그야.만약 이것이 전에 제기되었다면 미안하다.Dpmuk (대화) 21:38, 2008년 7월 3일 (UTC)[응답]

나는 DPMUK의 빠른 경고 템플릿 아이디어가 좋은 아이디어라고 생각한다.아마도 그것은 미래에 1, 2시간으로 설정된 시간을 포함할 수 있고, 그 후에 제대로 소싱되지 않으면 삭제될 수도 있다.--SerkOfVulcan (대화) 21:53, 2008년 7월 3일 (UTC)[응답]

나는 그 과정에 더 많은 단계와 규제를 추가할 특별한 이유가 없다고 본다.그것들이 완벽하거나 완전히 형성될 필요는 없지만, 기사들은 창조물에 대한 소싱과 주장이 있어야 한다.만약 편집자가 그 기사가 기준을 충족시킬 수 있다고 믿는다면, 그는 충분히 자유롭게 사용할 수 있다.{{hangon}}. seresin ( "? ) 21:58, 2008년 7월 3일 (UTC)[응답하라]

우리의 과정에 또 다른 단계를 추가하기 보다는, 아마도 우리는 공신력 부족을 이유로 삭제를 권고하는 편집자들이 어떤 주제가 실제로 주목할 가능성을 평가해야 한다는 것을 강조할 수 있을 것이다 - 이상적으로, 의심이 존재하는 경우에 약간의 연구만 함으로써, 그리고 주제가 모호해질수록 편집자는 더 많은 관심을 가져야 한다.ean 신속한 삭제 템플릿이 아닌 "신뢰성" 템플릿 방향으로.그렇게 하면, 우리는 (정말 유용한 기사를 추가하는 사람들에게) 반겨줄 수 있고, 여전히 빠른 속도로 정글을 지울 수 있다. -- 존 브레본 (리틀링) 22:06, 2008년 7월 3일 (UTC)[응답]

그렇다, 그들은 소싱과 주장을 해야 한다. 하지만 나는 내가 처음 일했을 때 어떤 것을 저지르기 전에 편집된 것들을 모두 정리하고 미리 보는 것을 하지 않았다고 확신한다 - 많은 사람들이 단락을 쓰고, 그것을 아끼는 등 - 만약 그들이 다음 에디에서 요점을 말하려고 한다면 너무 심하게 물리지 않는 것이 타당하다.t. 자극받음, 예스; 뺨을 맞음, 아니오.uw-vand를 사용하여 uw-test와는 다른 상황에서 임의의 수의 경고 템플릿 중에서 선택할 수 있는 것과 같은 방식으로 다른 단계, 단지 다른 변형 템플릿이 되어서는 안 된다.나는 아마도 그 통지에 시간을 기록하겠지만, 한 시간을 엄격히 제한하지는 않을 것이다; 나는 그것을 현재 경영진의 재량에 맡기겠다.Phyomonas_(talk) 22:16, 2008년 7월 3일 (UTC)[응답]

그게 바로 내 요점이야.물론 그것은 소스가 되어야 하고 그것이 창간될 때 그것이 유명하다고 주장되어야 하지만 새로운 사용자들은 이것을 모를 수 있기 때문에 내가 보기에 이 모든 빠른 카테고리는 종종 WP:Bite에 반하는 것처럼 보일 것이다.아마도 내가 최고의 제안서를 작성하지 못한 것 같지만, 이것은 뭔가 해야 할 필요가 있는 지니우네 문제인 것 같다.Dpmuk (대화) 18:45, 2008년 7월 7일 (UTC)[응답]

db-friendly 템플릿과 관련 사용자 경고를 받을 수 있는가?"이곳에서 괜찮은 페이지를 만들려고 하는 것처럼 보이지만, 적어도 하나의 출처와 적어도 하나의 유명무실함을 주장할 필요가 있다. 감사합니다, 당신의 노력은 감사하다."라는 요지를 가지고 있다.관리자가 비공식적으로 db-attack에게 최우선 순위를 부여하는 것과 마찬가지로, 그들은 db-friendly가 관료주의의 또 다른 계층이 될 필요 없이 좀 더 여유를 줄 수 있다.녹농균_(talk) 12:18, 2008년 7월 8일 (UTC)[응답]

탐색에 "퍼지" 추가

항행(...역사,관찰,숙청)에 숙청을 추가하는 것에 반대는 없을까?아니면 툴박스로 갈까?어떻게 하는지 도무지 기억이 안 나 매번 찾아봐야 해.해롭기보다는 오히려 도움이 될 것 같다.생각?조니미르닌자 05:15, 2008년 7월 7일 (UTC)[응답]

삭제 작업은 때때로 추가 서버 로드를 유발하고 작업 대기열에 추가하지 않는가?우리는 그것을 장려하고 싶은가?나도 기억은 안 나지만, 노력과 퍼지는 것은 항상 어느 쪽으로든 그것을 깨끗이 지워버린다.Framanax (대화) 05:33, 2008년 7월 7일 (UTC)[응답하라]

원하는 대로 화면의 오른쪽 상단 모서리에 UTC 시계를 표시하고 클릭할 경우 페이지를 지우는 "개인 도구 모음의 시계"("사용자 인터페이스 가젯" 섹션 아래)를 활성화할 수 있다.두 기능 모두 매우 유용하다.2008년 7월 7일 (UTC) 08:27의 공작 월섬 (Walthaltham, The Duke of 08:27

이거 대박이다.고마워!

또는 탭으로 사용하려면 다음 웹 사이트를 사용하십시오.WikiProject 사용자 스크립트/스크립트/탭에 제거 추가대수학자 10:25, 2008년 7월 8일 (UTC)[응답]

인쇄 가능한 버전의 모든 탐색 상자 확장

이제 대부분의 Navbox가 접을 수 있게 되었으니 인쇄 가능한 버전은 인쇄할 때 필요한 모든 것을 확장해야 하는가?그네빈 (대화) 09:29, 2008년 7월 8일 (UTC)[응답]

관리봇 허용에 대한 RFC 및 관리봇에 대한 규칙

위키피디아에서 큰 소리로 말하십시오.설명/Adminbots 요청.고마워. 뿌리학 (T) 13:12, 2008년 7월 8일 (UTC)[응답]

'새 섹션'을 굵게 표시하고 '이 페이지 편집'을 정기적으로 수행

자주 사용하는 대규모 토론 페이지를 편집하는 현명한 방법은 관심 섹션 옆에 있는 '새 섹션' 또는 '편집' 링크를 클릭하는 것이다.그렇지 않으면 편집 창 내에서 관련 섹션을 검색하여 편집 충돌의 공포를 다루어야 한다.현재 Science Reference Desk 등 페이지에서는 '이 페이지 편집' 링크가 굵고 '새 섹션' 링크가 규칙적이어서, 내가 일반 링크를 원할 때 우연히 굵은 링크에 끌리게 된다.실제로, 나는 참조 데스크의 '이 페이지 편집' 버튼을 필요로 하는 사람은 거의 없을 것이라고 생각한다.나는 '새로운 섹션' 링크를 과감하게 만들고 '이 페이지 편집' 링크를 정기적으로 만들어 사람들이 둘 중 올바른 링크에 끌리도록 제안한다.------감자 사업 17:29, 2008년 6월 7일 (UTC)[응답]

합리적인 것 같지만...이것은 한 페이지에 할 수 있을까?2008년 6월 7일 (UTC) 20:13, 월텀 공작 (Walthaltham, The Duke of 20:13, The Duke of 2008 (UTC)

__NEWSectionLINK__이(가) 있는 모든 토크 페이지와 페이지에 대해 해보는 것은 어떨까?– FISDOF9 23:54, 2008년 6월 7일(UTC)[응답]

그거 좋은 생각인 것 같아.우리가 여기서 충분한 관심을 받지 못한 것 같아 안타깝다.난 거의 일주일 동안 이 일을 잊고 있었어...바보 펌프.2008년 6월 14일 00:30(UTC)의 공작 월텀(Walthaltham, The Duke of 00:30 (UTC)

WikiDataSource 또는 WikiStatistics(2부)

여기서 볼 수 있는 나의 이전 게시물을 사용자들이 오해한 것 같다. [1]. 구독 사이트들이 데이터를 수집하는 것은 데이터를 얻기 어렵기 때문이지, 돈을 지불해서가 아니라, 수집하기 어렵기 때문이다.나는 사람들이 가입을 해서 위키피디아에 자료를 올리라고 제안하지는 않지만, 위키피디아가 스스로 자료를 편집하여 자료를 올리는 메커니즘 역할을 한다고 제안한다.따라서 데이터를 검색하고 컴파일할 때 제공되는 다른 웹 페이지 서비스는 더 이상 필요하지 않을 것이다.학계에서는 인식된 수요가 적기 때문에 이를 통해 돈을 벌 수 없다고 생각한다면 수집한 자료를 쉽게 게시할 수 있다.

많은 연구자들이 데이터가 존재하는지조차 알지 못할 때 많은 데이터 집합이 위키피디아에 등장할 것이고, 사람들은 스스로 데이터를 컴파일할 수 있는 자원이 없을 때 이미 수집된 데이터를 활용할 수 있을 것이다.

낡은 것을 훔치는 것이 아니라 새로운 시스템을 만드는 것이다.—서명되지 않은 의견을 216.37.94.10 (대화) 20:07, 2008년 7월 1일 (UTC)[응답]까지 추가

지원:나는 이것이 꽤 좋은 생각이라고 생각한다.외환보유액별 국가 목록이나 GDP별 국가 목록(명목)과 같은 자료를 이용하는 페이지들이 연도별 또는 월별로 추적하기 좋은 페이지들이 많이 있다. --PatrickFlaherty (대화) 23:07, 2008년 7월 1일 (UTC)[응답]

강력한 지원 이와 같이 별도의 DataCommons는 시맨틱 Wiki 도구를 사용하여 데이터를 다른 방법으로 재사용할 수 있는 좋은 장소가 될 수 있다.만약 위키백과 인포박스의 데이터가 그곳으로 옮겨진다면, 그 데이터는 모든 언어 위키에서 이용할 수 있을 것이다.한 언어가 데이터를 가져오기 위한 템플릿을 만들고 나면 다른 언어도 템플릿을 로컬로 만드는 것만으로 동일할 수 있다.그러나 이 아이디어는 영국 WP보다 훨씬 더 많은 영향을 미치기 때문에 메타에 대해 제기될 필요가 있다.

그동안 위키스페이드의 정보를 엔으로 변환할 수 있는 방법이 있을까.WP 택스박스?내가 그걸 하는 것에 대해 어디서 배울 수 있을까?Filceolaire (대화) 2008년 7월 8일 10:26, 8 (UTC)[응답하라]

구독 웹사이트가 데이터를 컴파일하는 것은 데이터를 얻기 힘들기 때문이지, 돈을 지불해서가 아니라, 수집하기 어렵기 때문이기도 하다.나는 이것에 의문을 제기한다 - 다른 견해는 사람들이 기꺼이 그 데이터에 대해 지불할 의사가 있기 때문에 구독 웹사이트가 데이터를 컴파일한다는 것이다.이러한 관점에서, 구독의 수입은 주로 웹 호스팅을 위한 것이 아니라 데이터 수집, 데이터 품질 검토 등을 위한 비용이다.내 생각에는, 사실상 모든 데이터 수집이 아니어도, 만약 누군가가 그것을 합친 사람들에게 돈을 지불하지 않는다면, 모든 데이터 수집은 일어나지 않을 것이다. 요컨대, 위키미디어 데이터커먼즈를 보유하지 않을 이유가 없지만, 그것이 큰 차이를 만들 것이라고 극단적으로 낙관하지는 말자. -- 존 브로튼 (리빙) 02:07, 2008년 7월 10일 (UTC)[응답]

검색란 이동

이 마을 펌프(여기)에 대한 여론조사와 최근의 소프트웨어 변경에 이어, 나는 이곳 검색대의 이전을 실시할 것을 제안했다.그 토크 페이지에서는 어떤 생각이나 코멘트가 있어도 크게 감사한다. --MZMcBride (토크) 08:18, 2008년 7월 9일 (UTC)[응답]

테이블의 선택적 필터

위키피디아에는 긴 테이블이 몇 개 있다.예를 들어 장치 테스트 프레임워크의 목록을 참조하십시오.운영체제 X, 언어 Y, 라이선스 Z에 대한 결과만 걸러내는 방법이 있으면 좋지 않을까.마아텐 트롬프 14:30, 2008년 7월 1일 (CEST)

흥미롭지만, 역동적인 모든 테이블을 만드는 것은 복잡해 보이고 부하 시간을 증가시킬 것 같아.그라시몬키는?다아페 03:50, 2008년 7월 7일 (UTC)[응답]

Greasemonkey에서 작동하는 거의 모든 것은 위키백과 사용자 스크립트로 작동하며, 아마도 Preferences 섹션의 모든 사람들에게 제공될 수 있을 것이다.Phyomonas_(talk) 07:56, 2008년 7월 11일 (UTC)[응답]

선택한 문서의 일부 섹션에 대한 일부 추가 링크를 되돌릴 수 있는 잠재적 봇

제안서를 작성하기 전에 기술적인 문제만큼이나 사회적 이슈로서 좀 더 일반적인 논의가 필요하다고 생각되어 봇 승인보다는 여기에 글을 올린다.

익명 사용자나 최근에 등록한 사용자가 만든 날짜 페이지(예: 1986년 또는 10월 15일)의 출생 또는 사망 섹션에 추가된 레드링크/노링크/링크 연결/해체 페이지 링크-해체 페이지(Links to disdigaggement-page)를 되돌리는 PhyseBot을 쓰고 관리했다.이것은 날짜 페이지 정책과 일맥상통한다.

나는 이제 몇몇 사람들이 다른 기사의 목록 부분에 대해서도 똑같이 할 수 있는지 물어보도록 했다. 그리고 내가 최근 순찰과 반반항만주의를 많이 하는 것을 보면, 나는 분명히 호소력을 볼 수 있다. 어떤 부분들은 허영심과 공격 입력을 끌어들이는 것 같다.생각나는 것은 특정 학교의 '명성 있는 동창회' 코너, 특정 마을/마을의 '유명한 주민' 코너, 푸가 어느 나라든 있는 '유명한 주민 목록' 등이다.

제대로만 된다면, 봇에 섹션을 등록하는 것은 덜 거슬리는 버전의 세미 프로텍션이 될 수 있고, 많은 잡동사니를 예방하며, 낭비되는 시간을 많이 절약할 수 있다.잘못하면 진짜 편집이 제한되고 신참을 물릴 수도 있다.어떤 경우든, 나는 그것이 비자동 확증 사용자만 되돌리는 것에 가장 제한될 것이라고 생각한다 - 그렇게 함으로써 만약 어떤 것이 잘못되었다면, 자동 확증 편집자는 본문을 다시 복구할 수 있고, 봇은 그것을 다시 만지지 말아야 한다.

봇을 만드는 것은 기술적으로 쉬울 것이다. 봇에 등록될 수 있는 많은 방법들이 있을 것이다. 나는 이미 많은 부분들을 생각해 보았다. 그리고 (내가 사람들에게 무엇을 말할지는 모르지만) 나는 그러한 메커니즘을 결정하는 것이 봇 승인 단계까지는 최선이라고 생각한다. 우리가 어떤 색깔을 칠해야 할지 논쟁하지 않기 위해서.자전거 보관소

다음 사항에 대한 의견:

1. 이건 그냥 모든 경우에 끔찍한 생각일까?
2. 그렇지 않은 경우, "스쿨 스텁" 또는 "카테고리 구성원:Foo의 마을" 또는 "현재 등록자 수가 5% 이하인 사람들의 목록") 또는 기사나 위키피디아 주제 또는 항반달리즘에 종사하는 커뮤니티의 비트가 필요에 따라 개별 기사를 지명해야 하는가?
3. 누가 페이지를 등록할 수 있어야 하는가?관리자만 또는 자동 확인 사용자 또는 누구라도?
4. 어떤 방법으로 페이지를 등록해야 하는가?
5. 날짜 페이지와 같이 이미 "redlink 없음" 정책이 있는 페이지 세트가 있는가?
6. 섹션에 어떤 공지사항을 붙여야 하는가?날짜 페이지에는 이 목록에 위키백과 기사가 없는 사용자를 추가하지 않음과 같은 HTML 형식의 설명이 있다.
7. 기고가 되돌아간 편집자에게 어떤 통지가 발행되어야 하는가?나는 공공 기물 파손을 암시하지 않도록 조심하고 꽤 온화한 것을 선호한다.
8. 사람들이 관련있다고 생각하는 그 밖의 모든 것.

Phyomonas_(talk) 13:17, 2008년 7월 1일 (UTC)[응답]

내가 보기에, 필요한 것은 페이지 그룹에 대한 정책을 수립하고, 필요하다면 봇 경찰로 하여금 정책을 수립하도록 하는 것이다.시작하기에 좋은 장소는 "직업별 사람 목록에 있는 하위 수준 페이지 목록"일 것이다.현재 스타일 가이드라인(Wipedia:목록(독립 실행형 목록)#목록) : "선정된 인물목록은 그 범주에서 중요성/알림성을 위해 선정되어야 하며 위키백과 기사(또는 향후 기사에 대한 합리적인 기대치)가 있어야 한다."만약 그것을 "적색 연결은 없다"라고 말하고 그것을 정책으로 만들기 위한 합의가 이루어질 수 있다면, 그 정책을 감독하는 것은 봇에게 좋은 일이 될 것이다.나는 그것이 큰 질문이라고 생각하지 않는다: 그 정책이 말하는 모든 것은 "먼저 스텁을 만들어라"는 것이다.나는 BAG가 최상위 단계 외에는 관여할 필요가 없다고 본다. 즉, 특정 종류의 페이지(예: 목록)를 경찰에 승인하기 위해 Redlink 정책이 확립되어 있는 것이다.페이지를 추가하거나 삭제하기 위한 별도의 메커니즘을 갖는 것은 훨씬 더 나쁘다 - 그것은 단지 관료주의를 더하는 것이다.무적립 정책에 대한 합의가 성립되고 BAG가 봇을 승인했다면 그것으로 충분할 것이다.필립 트루먼 (대화) 13:45, 2008년 7월 1일 (UTC)[응답]

(e/c) 나는 이것이 훌륭한 생각이라고 생각한다.봇 순찰을 어느 페이지에 해야 할지, 네가 어떻게 다 찾을 수 있을지 모르겠어.쉽게 찾을 수 있는 만큼 더하고, 확증된 사용자들이 찾으면 목록에 더 많은 것을 추가하도록 하십시오.나는 그 페이지들이 목록에 영구적으로 추가되는 것으로 가정되어야 한다고 생각한다.문제가 발생한 경우 자동 확인 사용자가 이름을 제거하도록 하십시오.봇이 사람들에게 그것을 되돌려준다는 통지에 대해서, 이런 것은 어떨까?

안녕, 네가 최근에 미들오프나우 고등학교로 편집한 것이 자동화된 봇에 의해 번복되었어. 왜냐하면 그것은 "명성 있는 동문" 섹션에 빨간색 링크가 있는 이름을 추가했기 때문이야.이것이 오류였고 이름이 추가되었어야 했다고 생각되는 경우, 이 페이지에 메모를 남겨 두십시오.고마워, [PhysiBot 서명이 여기 있을 거야 ]

그런 다음 오류 페이지를 사용자:LeverBot/FalsePositives.자동 확증된 사람들은 어떤 요청도 검토할 수 있고, 만약 그 이름이 합법적이라면, 기사에 그것을 추가할 수도 있고, 봇은 그것들을 되돌리지 않을 것이다.얼마나 적은 사람들(상대적으로)이 CleverBot 에러 페이지에 메시지를 남기는가를 고려하면, 나는 PhysiousBot에 대한 가상의 에러 페이지가 큰 부담이 되지 않을까 심각하게 의심하고, 어떤 경우든 오류를 보고하는 사람들을 처리하는 데 낭비되는 시간은 이 다른 모든 페이지를 되돌릴 경우 로봇이 절약할 수 있는 시간보다 훨씬 더 많을 것이다.es는 날짜 페이지와 함께.J.delanoy^gabs_adds 13:56, 2008년 7월 1일 (UTC)[응답]

나는 천천히 출발할 것을 제안한다 - 특정 기사/목록의 특정 섹션에 대해서만 요청한다.잠시(적어도 두어 달은) 봇이 이런 일을 하게 한 후에, 나는 당신이 적합하다고 생각되는 대로 그것을 확장하는 것에 반대하는 사람이 있는지 커뮤니티에 다시 와서 물어봐야 한다고 생각한다.누가 요청을 할 수 있는가에 대해서는 과감하게, 누구라도 그렇게 하도록 할 것을 제안하지만, 경험이 풍부한 편집자가 삭제를 거부하면, 그 특정 부분에 대해서는 봇 사용을 중지하는 관행을 채택할 것을 제안한다.(이것은 편을 들지 않을 콘텐츠 분쟁으로 처리하라.)나는 네가 언급하는 것과 비슷한 보이지 않는 논평이 섹션에 추가하기 좋다고 생각한다.많은 편집자들이 아마도 IP 편집자가 될 것이고, 그것은 상당히 무의미하기 때문에, 잘못된 편집자들에게는, 특히 코멘트가 있는 경우에는, 통지하지 말 것을 제안한다.훌륭한 편집 요약은 편집자들에게 왜 추가가 되돌아가게 되었는지를 알려주기에 충분할 것이다.(삭제에 대한 많은 질문에 답변하고 있는 경우, 예, 사용자 대화 페이지에 공지사항을 게시하는 것을 고려하십시오.

그리고 이렇게 해줘서 고마워!당신 같은 봇은 위키백과 기사를 더 좋게 만드는 데 도움이 된다. -- 존 브로튼 (기침) 14:47, 2008년 7월 1일 (UTC)[응답]

(ec)이 여기 있는 많은 "xyz 밴드/예술가 목록" 기사에 매우 효과적일 수 있는 것처럼 들리는데, 그들 중 일부는 스파가 그들의 악보들을 홍보하기 위해 추가한 데드 링크 집단이다. 예를 들어, Jac1688 (talk) 14:50, 2008년 7월 1일 (UTC) 응답하라.

대담하게 행동하게 되어 기쁘지만, 봇을 운영하려면 봇 승인 그룹의 허가가 필요하며, 시작하기 전에 봇이 어떻게 행동할 것인지에 대한 세부 사항을 자세히 설명해야 한다.사이비봇은 이미 몇 달 동안 내가 좋은 트랙이라고 여기는 것을 가지고 달려왔기 때문에 나는 어쩌면 더 논쟁적인 분야로 확장을 요청하는 단계에 와 있다고 느낀다.IP에 알리지 않는 것에 대해 당신이 제기하는 흥미로운 점 - 그것에 대한 일반적인 관점은 무엇인가?Phyomonas_(talk) 15:00, 2008년 7월 1일 (UTC)[응답]

내가 생각하기에 이것이 잘되고 유용할 수 있다면 많은 사람들을 화나게 할 것이다.코딩과 사용법에 주의해야 할 겁니다. — Rlevse • Talk • 20:22, 2008년 7월 2일 (UTC)[응답]

확실히 정확한 코딩이 중요하다, 그렇다.어떤 특징이 그것이 야기할 수 있는 화를 최소화할 것이라고 생각하는가?Phyomonas_(talk) 21:15, 2008년 7월 2일 (UTC)[응답]

그것은 레드 링크가 괜찮다고 생각하는 사람들을 화나게 할 수도 있다.다시 말하지만, 느리게 시작할 것을 제안한다. - 요청별로 봇을 실행할 수 있는 권한을 요청하고, 사용자 공간에 하위 페이지를 설정하여 봇이 순찰하고 있는 페이지를 나열하고, 몇 달 동안 상황이 어떻게 돌아가는지 확인해 보십시오.그러면 여러분은 봇이 더 널리 사용될 수 있는지에 대해 더 많은 정보를 얻게 될 것이다.WP에 대해서는 다음과 같다.BOTREQ, 나는 네가 그냥 가서 시작 허락을 구해야 한다고 생각해(느리게, 수동 요청) 그리고 무슨 일이 일어나는지.최악의 경우는 BAG가 당신의 요청을 거절한다는 것이다. 그들이 거절한다면, 당신은 당신의 대답을 얻을 것이다. (아니면, 그것을 다르게 말하면, 당신이 점증적 접근법으로 시작한다면, 당신이 가지고 있는 "특징"은 그다지 중요하지 않다; BAG는 중요한 문제를 제기할 것이다.) -- 존 브로튼 (UTC) 01:30, 2008년 7월 7월 [응답]

문제는, 내 생각에 사실적으로 채식주의자들의 리스트에서 임의의 비협조적 레드 링크를 삭제하는 인간 편집자일지라도, 레드 링크는 괜찮다는 추정이 있다는 것이다.아마도 당신이 BAG에 그것을 가져가서 그들이 어떤 조건을 부과하려고 마음먹는지 보자고 제안하는 것이 가는 길일 것이다.녹농균_(talk) 12:34, 2008년 7월 8일 (UTC)[응답]

나는 대체로 찬성한다.몇 가지 생각:

• 신시내티의 이웃이나 세시미 스트리트의 꼭두각시 인형사 목록과 같이 일부 목록은 사실적이고 제한적이다.이론적으로 모든 구성원은 기사를 쓸 자격이 있으며, 따라서 레드링크(사실상 맞다면)는 그대로 있어야 한다.다른 목록은 완료되지 않아야 한다.신시내티 출신자 명단은 신시내티에서 태어난 수백만 명 한 명을 일일이 열거해서는 안 되기 때문에, 한 사람이 기사를 쓸 정도로 눈에 띄지 않으면 그 명단에 포함될 만큼 눈에 띄지 않는다.이 과제는 후자의 목록에만 초점을 맞춰야 한다. (일부 목록은 회색 영역일 수 있다: 모든 신시내티 고등학교는 오하이오 주 신시내티의 고등학교 목록에 등재되어야 하며, 모든 학교가 기사를 쓸 자격이 있는가?)하지만 나는 그것이 여전히 지침이 되어야 한다고 생각한다.
• 이 과제는 기사에 새로운 레드링크를 추가하는 데 초점을 맞추는 것 같지만, 그것이 현명한 우선순위인지는 잘 모르겠다.신시내티에서 온 사람들 목록에 있는 두 개의 레드링크와 몇 달 동안 있었던 한 개, 그리고 최근에 추가된 한 개를 상상해 보라.내 생각에는 오래된 레드링크를 없애는 것이 더 우선순위가 되어야 할 것 같아.결국, 새로운 레드링크를 추가하는 것은 기사를 만드는 첫 번째 단계가 될 수 있는 반면, 케케묵은 기사는 그 기사를 처리하고 있지 않을 것 같다.내가 설명한 대로 그 일을 반대하지는 않을 것이다; 나는 단지 48시간을 기다리면서 레드와인을 삭제하는 것이 더 나을 것이라고 생각한다. 그래야 그 기사가 작업되고 있지 않다고 합리적으로 확신할 수 있을 것이다.반면에, 나는 누가 그것들을 추가했든 간에, 그 리스트에서 한 달 이상 된 모든 레드 링크를 제거하는 것을 지지할 것이다.
• 이것은 정말로 반반달리즘적인 과제가 아니다; 그것은 반반달리즘, 또는 반삼륜적인 과제에 가깝다.확인되지 않은 이용자들은 확인된 것보다 공공 기물 파손 행위를 저지르기 쉽지만, 허영심 편집이나 사소한 편집은 저지르기 쉬운가?잘 모르겠어.나는 모든 사용자를 위해 이 작업을 지원하고 싶다. 레드 링크는 링크를 제거하기 전에 기사를 작성하는데 48시간의 유예기간을 부여한다.아마도 그 주의사항은 확인되지 않은 사용자에게는 적용되지 말아야 할 것이다...아마도 봇은 즉시 사용자에게 경고하고 48시간 후에 레드링크(실행 취소 가능 시)를 제거해야 할 것이다.하지만 이것들은 세부사항이다.
• 자전거 헛간 그림 그리기 방법이 무엇이든, 그것은 옵트인이어야 한다.목록의 섹션에 있는 숨겨진 템플리트를 사용하는 것이 바람직하다.
• 나는 이것을 해명 페이지에서도 지지할 것이다.존재하지 않는 물품에 대한 해명은 유용하지 않다.
• IPs를 알리는 것은 유용하지 않을 것이라고 추측하지만, 그것은 강한 의견이 아니다.

전반적으로, 나는 이것이 잘 필요한 과제라고 생각하는데, 나는 네가 봇 요청을 제출하기를 권장한다.– Quadell 14:08, 2008년 7월 8일 (UTC)[응답]

P.S. 유사한 비목록 섹션도 이러한 허영심 추가에 매우 취약하다. 예를 들어, 당신의 비목록 밴드를 당신의 도시 페이지에 추가하는 것이다.(이 예에서 링크는 파란색이지만 아이디어를 얻는다.)이 봇은 목록에 없는 항목도 처리해야 하는가?– Quadell 12:42, 2008년 7월 9일 (UTC)[응답]

위에서 말했듯이, 나는 "유명 주민"과 "명성 있는 동문" 등을 염두에 두고 있었다.나는 사람들이 산문에 레드링크를 삽입하는 것에 대해 아무것도 할 수 없다고 생각한다.나는 심지어 리스트에 있는 합법적인 산문 항목들, 특히 모호한 페이지들에 대해 걱정한다. 예를 들면:

• • 다양한 종류의 물건들, 예를 들면
    • 위젯
    • Whatsit
    • 두다드

이 경우 첫 번째 줄은 링크가 없는 글머리 기둥이긴 하지만 나는 되돌리는 것을 피해야 한다.글자가 일정 길이 이상이고 어떤 색깔의 링크도 없다면 나는 괜찮다고 생각해야 한다.내 생각에 결론은 봇이 모든 부분에 적합하지 않다는 것이다.Phyomonas_(talk) 16:45, 2008년 7월 9일 (UTC)[응답]

• 나는 우리가 여기서 시간 제한을 확실히 할 필요가 있다고 생각한다.나는 적어도 하나의 다른 기사에서 먼저 그것에 대한 빨간 링크를 만들지 않고 새로운 기사를 작성하기 전에 몇 년 동안 위키피디아를 편집했다. ("웹을 구축하라", 고아들을 구하라 등)우리는 누군가가 그 주제에 관한 기사를 쓰고 있는지 확인하기 위해 적어도 얼마 동안 기다리지 않고 즉시 빨간 링크를 제거해서는 안 된다.(또한 "신인을 물지 말라"가 적용될 것이다) Rmhermen (토크) 17:01, 2008년 7월 9일 (UTC)[응답]

좋은 지적이야, 고마워.어떤 지연 메커니즘이 가장 좋을지, 그 사이에 다른 사용자들이 편집하는 페이지를 어떻게 처리해야 할지 궁금하다.Phyomonas_(talk) 07:52, 2008년 7월 11일 (UTC)[응답]

• 이에 대한 BRFA가 생성되면 여기에 알려주십시오.– Quadell 14:03, 2008년 7월 10일 (UTC)[응답]

할 일 - 고민 중 :) 녹농성_(talk) 07:52, 2008년 7월 11일 (UTC)[응답]

상위 10개 위키백과

안녕 여러분.

위키백과 주요 포털 사이트(http://www.wikipedia.org)에 표시되는 상위 10개 위키백과들의 재배치와 관련하여, 오늘 자정부터 시작되는 투표에 주목해 주시기를 부탁드린다.

이 주제는 토크:www.wikipedia.org 템플릿에서 오랫동안 떠돌아다녔으며, 특히 중국과 러시아어 위키피디아 기사의 100,000개 기사의 이정표를 전후로 많은 경우에 표면화되었다.

Talk:www.wikipedia.org 템플릿#Top 10에서 수개월 동안 이 페이지에서 제안된 모든 제안들을 잠정적으로 마무리한 후, 모든 주요 위키백과들이 마을 펌프에 초대된 Top 10 위키백과에서 토론이 시작되었다.

많은 좋은 의견들을 수렴하고 토론했으며, 투표 제안이 이루어졌고 약간의 피드백을 받았다.그 제안은 현재 메타휴브에서 시행되었다.투표하러 투표소로 가십시오.거기서 보자! --월디르 12:46, 2008년 7월 5일 (UTC)[응답]

이제 폴이 m:로 이동했다는 점에 유의하십시오.Top_Ten_Wikipedias/poll.Dcoetzee 06:54, 2008년 7월 10일 (UTC)[응답]

위키백과 기사 내의 텍스트 검색.

html이 아닌 .txt 형식의 파일에서만 잘 작동하는 것 같은 표준 찾기 기능을 사용하여 글에서 특정 단어나 구문을 찾는데 어려움을 겪었다.나는 위키피디아가 글 안에서 큰따옴표(")를 사용하여 특정 단어 또는 구문을 검색하는 검색 기능을 추가할 수 있다면 다른 사람들도 같은 문제를 겪고 있는지 궁금했다.—서명되지 않은 의견을 76.243.178.196 (대화) 21:37, 2008년 7월 6일 (UTC)[응답]까지 추가한 준비

Ctrl+F는 FF와 IE로 잘 작동한다. 90:1 21:40, 2008년 7월 6일 (UTC)[응답]

다른 사용자가 이 문제를 겪고 있지 않으면 무시하십시오.—서명되지 않은 코멘트 76.243.178.196 (대화) 21:44, 2008년 7월 6일 (UTC)[응답]

나는 90:1에 동의한다; 브라우저의 검색 기능은 보통 충분하다.

이와는 별도로, 나는 사람들이 문제없이 게시물 작성자의 이름(또는 당신의 경우 IP 주소)과 그것이 만들어진 정확한 시간을 볼 수 있도록 당신의 게시물에 서명할 것을 제안한다.끝에 4개의 틸트를 입력하면 된다(~~~).2008년 7월 7일 (UTC) 08:33의 공작 월섬 (Walthaltham, The Duke of 08:33

당신은 지금 구글에서 검색을 할 수 있고, 단지 당신의 검색어를 입력하고 그것이 "site:wikipedia.org"을 입력한 후에 그것은 당신에게 다른 검색과 마찬가지로 결과를 줄 것이다.이전에 %%-SYKKO-%(Talk to me) 18:52, 2008년 7월 11일(UTC)[응답]에 대해 특정 주제가 작성되었는지 알아보려고 할 때 이 항목이 매우 유용하다는 것을 알게 된다.

유니파이드 로그인을 사용하지 않도록 설정하는 중

사용자의 선호에 따라 로그온한 상태에서 검색하는 것만으로 다른 위키에서 통합 로그인을 활성화한 후 일시적으로 비활성화하거나 다른 위키에서 계정 생성을 일시적으로 비활성화하는 옵션이 있어야 한다고 생각한다.나는 단 한 번 방문했을 뿐인 다른 언어의 위키피디아에서는 결코 사용하지 않을 계정을 우연히 만드는 것을 좋아하지 않는다.— 광기의 화신 21:30, 2008년 7월 7일 (UTC)[응답]

왜 싫어?—Wknight94 (대화) 21:45, 2008년 7월 7일 (UTC)[응답]

그것은 과거에 이슈가 되었던 다른 위키에서 사람들이 당신을 사칭하는 것을 막는다.그랜드마스터카 22:12, 2008년 7월 7일 (UTC)[응답]

특징 요청은 위키미디아의 버그 트래커에서 이루어져야 한다.건배. --MZMcBride (대화) 08:19, 2008년 7월 9일 (UTC)[응답]

나는 이것에 대해 몇 번 투덜거렸었는데, 그 때 (특히 낮은 교통 사이트에서) 다른 위키 기사에 대한 링크를 따라가다가 최근 변경사항의 맨 위에 내 이름이 있는 것을 알아차렸다.나는 종종 사람들이 샬롯웹이 "계정이 자동으로 생성된다"는 것을 보고(아니면 이것은 현지 언어로 설명되어 있다), 도대체 그녀가 여기서 무엇을 하고 있는지 자문해 볼까 하는 생각을 해 본 적이 있다. 그녀가 뭘 읽고 있는지 궁금하군...물론 만약 내가 다시 같은 사이트를 방문해서 내 토크 페이지에서 큰 것을 보게 된다면(아마도, Babelfish로 판단하는 것은 일종의 "환영" 템플릿일 것이다) 그 질문에 대한 답을 기억하지 못할 것이다.그래서 나는 그것에 대해 너무 걱정하지 않으려고 노력한다.이게 도움이 되길 바래.

실제로 나는 모든 계정이 글로벌화되는 이 일시적인 해킹을 고려한다. 결국 (이 때 "로컬" 계정 생성 로그는 단계적으로 폐기된다.)그러나 서로 다른 사이트에서 동일한 이름을 가진 두 개 이상의 계정에 대해 어떻게 해야 하는지에 대한 딜레마가 있지만, 암호나 전자 메일 주소가 공통적이지 않기 때문에 (즉, 1개 또는 0개의 계정이 확인된 전자 메일 주소를 가지고 있는 경우) 동일한 사람임을 확인하거나 부인할 수 없다(주소가 서로 다를 경우).다른 정체성을 가지고 있다.이러한 방식으로 모든 상충되는 계정들은 (원산지 위키에 의해) 강제적으로 혼란될 수 있고, 나중에 동일인으로 설정된 계정들은 다시 합쳐질 수 있다.그때까지 우리는 그들이 다르다고 가정하는 쪽으로 실수를 해야 한다.— CharlotteWebb 14:16, 2008년 7월 11일 (UTC)[응답]

매스워치.

만약 매스 워치 페이지가 있다면 나는 그것이 매우 유용할 것이다.위키피디아에 그런 기능이 있는지는 모르겠지만 아마 있을 것이다.내가 염두에 두고 있는 것은 특정 위키피디아 제목이 태그된 모든 페이지 또는 카테고리 내의 모든 페이지를 볼 수 있는 능력이다.이렇게 해서 군대 역사라는 말에 관심을 갖게 되면 {{Wiki Project 군사 역사}} 태그가 붙은 모든 페이지를 볼 수 있게 된다.헤드폭탄 {ταλ – WP 물리학: PotW} 01:37, 2008년 7월 8일 (UTC)[응답]

• 강력한 지원 만약 그것이 가능하고 그것을 하는 것이 현실적인 것이라면 그것은 또한 하위 페이지나 전횡에 근거한 그룹을 할 수 있게 한다면 좋을 것이다.프로젝트의 모든 기사를 보는 것이 매우 도움이 될 것 같아서 나는 이 아이디어가 정말 좋아!%-SYKKO-% (토크) 02:18, 2008년 7월 8일 (UTC)[응답]
• 반달족이 내 감시목록을 가지고 장난치는 것을 막기 위해 변전소여야 한다는 경고와 함께 지원.예를 들어 "미국의 위키프로젝트 모든 것을 감시하라"는 현재 해당 프로젝트에 포함되지만 프로젝트에서 추가되거나 제거된 기사를 추가 또는 삭제하지 않는 것이다.나는 어떤 반달족이 위키피디아 제목에 그것을 추가했기 때문에 내 감시목록에 나타나는 것에 신경 쓰지 않는 페이지를 원하지 않는다고 생각한다.마찬가지로, 일부 반달들이 프로젝트에서 제거했기 때문에 미국이 없어지는 것을 원하지 않는다.davidwr/(대화)/(contracts)/(e-mails) 03:42, 2008년 7월 8일 (UTC)[응답]
• 위키백과 주제의 모든 페이지가 특수:를 사용하여 한 페이지 또는 카테고리에 있는 경우 지금 이와 같은 작업을 수행할 수 있다.최근 ChangesLinked.예를 들어, 살아있는 사람들에 대한 모든 기사의 변경 사항을 보려면 Special:최근 변경사항 링크/범주:살아 있는 사람들.Hut 8.5 06:47, 2008년 7월 8일 (UTC)[응답]
• 나는 나 자신과 다른 몇 사람을 위해 이것을 하기 위해 간단한 자바스크립트를 썼다.페이지의 카테고리 링크를 "이 카테고리 보기" 버튼으로 변경하고 하위 카테고리에 대한 단추를 작성한다.도구 상자에 "Watch What links here" 버튼을 추가하는 백링크 버전을 추가하는 것은 어렵지 않을 것이다.잭슈미트 (토크) 2008년 7월 8일 (UTC) 18:46[응답]

• 그럼... 어떻게 되는 거야?사람들이 대본을 어떻게 사용할까?헤드폭탄 {τακ – WP 물리학: PotW} 15:42, 2008년 7월 9일 (UTC)[응답]

• 위키피디아는 Special을 사용하여 이러한 목록을 유지관리할 수 있다.최근 ChangesLinked 및 참가자를 초대하여 모니터링하십시오.나는 WP 어딘가에서 "Public Watchlist"라고 불리는 것을 본 적이 있다고 생각한다.에클립스 (대화) 14:29, 2008년 7월 11일 (UTC)[응답]

그냥 당신의 원시 감시 목록을 편집해서 거기에 기사 목록을 붙여넣으면 된다. 2008년 7월 11일 (UTC) 15:41, 11 (응답)

왼쪽 및 배경 이미지 탐색 변경

왼쪽의 탐색 막대가 변조되었음을 알 수 있다(즉, 표제가 대문자로 표시되지 않음).http://en.wikipedia.org/skins-1.5/monobook/headbg.jpg에서는 위키피디아의 배경도 약간 녹슬어 보인다.
내가 생각하는 배경은 필요하지 않다.
나도 로고를 다채롭게 만들고 싶다(하지만 바꾸지는 않는다).
내 말에 다들 어떻게 생각해?
• RRaunak의 서명 • 그를 만나고 싶은가? •

위키백과에서 기본적으로 사용되는 로고를 말하는 겁니까?위키피디아에는 더 다양한 색상의 로고가 있다.위키백과 로고...읽을 수 있다. --ɔɹǝɐ!!!^Talk 2008년 7월 9일 15:26 (UTC)[응답]

때때로 WP가 새로운 스타일의 주입을 필요로 한다는 것은 고무적이지만 그래픽 디자이너로서 그리고 지루한 사용적합성 웹 테스트를 많이 수행한 사람으로서 현재의 레이아웃은 괜찮다고 느낀다.그래, 약간 수정될 수도 있어. 난 항상 몇 픽셀을 여기저기 옮기고 싶었어. 하지만 WP 레이아웃의 "대기권"을 고려하면, 집중을 할 수 있는 충분한 질감과 변화량이야.Rraunak 나는 당신이 기사를 편집하고 시간외 근무를 하는 것을 제안한다. 나는 당신이 새로운 사용자라는 것을 알았다.WP는 항상 내용에 초점을 맞춰야 하며, 스타일은 2차적으로 나온다(기본 css를 변경할 수 있는 것은 말할 것도 없다). .:다부마야:. 15:33, 2008년 7월 11일 (UTC)[응답]

브로드캐스트 출연 전에 커뮤니티에 경고

지미 웨일스는 오늘 아침 TV쇼 '스쿼크 박스'에 출연했는데, 출연하는 시간대에 진행자 레베카 퀵에 대한 기사가 야만적인 취급을 받았다.다른 사용자는 여기서 위키미디어 직원과 이사회가 주목할 만한 공개 방송 출연 전에 지역사회에 경고해야 한다고 제안하여 관련 페이지(쇼에 관한 정보, 진행자에 관한 정보 등)를 24시간 가량 임시로 보호할 수 있도록 하였다.이것은 많은 당혹감을 덜어줄 것이다.오늘 아침에 그 쇼를 봤는데 베키 퀵은 그녀의 전기 페이지에서 본 어떤 것에 굴욕감을 느꼈다.이것은 매우 쉽게 막을 수 있었지만, 지미 웨일즈와 남자 공동 진행자는 퀵을 성적으로 불쾌하게 할 것이라는 전망에 거의 자극받은 것처럼 보였다.정책 변경을 제안한 다른 사용자는 기본적으로 Rebecca Quick Talk 페이지를 삭제했는데, 이 또한 부끄러운 일이다.왜 "우리가 살아있는 사람들을 얼마나 기분 상하게 하든지 상관하지 않는다"는 문화인가?

Go Green Go White (talk) 22:22, 2008년 7월 10일 (UTC)[응답]

나는 다른 사용자들이 하나의 기사에 대해 토론하는 대신에 정책 토론을 여기로 가져오라고 제안함으로써 다른 사용자들을 대화 페이지에서 빼내도록 한 사용자였다.

기사를 선제적으로 보호하자는 의견에는 반대하지만, 공공 기물 파손이 급증할 우려가 있는 기사에 더 많은 시선/감시 목록을 얻기 위해 지역사회가 외모를 인식하게 했다면 나쁘다고 생각하지는 않는다. --오노렘 il 22:30, 2008년 7월 10일 (UTC)[응답]

• 정중하게 묻는 구체적인 이유에 대한 지지 오노렘의 말처럼 페이지 보호에 대한 어느 쪽도 확신할 수 없지만, 앞으로 있을 언론출연에 대해 알 수 있는 중앙의 장소를 갖고 싶다.%-SYKKO-% (말씀) 22:39, 2008년 7월 10일 (UTC)[응답]
  • 재단이 이런 일을 하도록 강요하는 것은, 지역 정책으로는 불가능하다.그들에게 친절하게 물어보는 것은 당신이 할 수 있는 유일한 것이 될 것이고, 결과를 얻을 가능성이 더 높다.다니엘 (토크) 08:12, 2008년 7월 11일 (UTC)[응답]
    • 사용자:Go Green Go White는 우리가 위키백과를 만드는 것이 아니라 "정책"을 통해 그들이 그렇게 하는 정책을 가져야 한다는 것을 의미했을지도 모른다.그 문제에 대한 정책; 그 표현은 분명하지 않았을지도 모른다.친절하게 부탁하는 것만으로도 아마 충분할 것이라는 데 동의하십시오.:-)_{tiny plastic} -- 그레이 나이트 ⊖ 08:54, 2008년 7월 11일 (UTC)[응답]
  • 좋은 지적이야, 난 내 지지 성명 %-SYKKO-% (대화) 12:59, 2008년 7월 11일 (UTC)[응답하라]를 작성했다.

나는 "정책"이 사용하기에 잘못된 단어였다는 것에 동의한다.나는 여전히 커뮤니티의 어떤 공식적인 요청이 개별 사용자들이 사용자 대화에 메모를 남기는 것보다 결과를 볼 가능성이 더 높다고 생각한다.짐보 웨일스가 TV에 출연할 때 메모를 남겨달라고 요청하는 것. --오노렘♠Dil 14:05, 2008년 7월 11일 (UTC)[응답]

"커뮤니티"가 영어 위키백과 이상으로 구성되어 있다는 것을 기억하라.만약 재단이 이와 같은 사항에 대해 사전 통보를 했다면, WP에서는 해당 재단이 만들어지지 않을 것이다.위키에 있는 A 또는 다른 곳.그것은 아마도 cc'd to wikiEN-l (이 제안서에도 역시 더 좋은 장소가 될 것이다)에 있는 meta 또는 foundation-l 메일 리스트에 있을 가능성이 더 높을 것이다.Mr.Z-man 23:35, 2008년 7월 11일 (UTC)[응답]

이 제안 페이지는 작동하지 않으며 자동 보관도 문제의 일부분임

나는 우리가 그 제안들을 늦추고, 그것에 대해 꽤 많은 청중과 의견을 모았는지 확인하기를 제안한다.나중에 수동으로 보관한다우리는 심지어 카테고리별로 제안의 이력을 나열하기 시작할 수도 있고, 사람들이 비슷한 제안들을 생각해 낼 때, 그것들을 다시 참조하라.우리는 한 번에 몇 가지 제안만 진행해야 하고, 그 제안들이 진행되는 동안 다른 제안들은 기다려야 할 것이다.그것은 그들이 좋은 제안을 가지고 있다고 생각하는 사람들에게 현존하는 제안에 대해 논평할 동기를 줄 것이다.그 동안 그들은 제안서를 하위 페이지로 작성할 수 있다.크게 서두를 필요는 없다.여기서 제기된 몇 가지 아이디어를 실제로 다루는 것이 더 중요하다.II (t - c) 03:35, 2008년 7월 10일 (UTC)[응답]

나는 그것이 실용적이라고 생각하지 않는다.그런 제한을 어떻게 시행하시겠습니까?— 당신을 먹여 살리는 손:^Bite 2008년 7월 13일(UTC) 12:09[응답]

플래그가 지정된 봇을 편집하여 보호됨

이 제안은 두 부분으로 되어 있다.

• 보호된 페이지를 편집할 수 있도록 플래그가 지정된 봇
• 중요한 페이지(예: 기본 페이지)에 플래그가 지정된 봇 편집을 방지하기 위한 새로운 보호 수준

봇은 논쟁의 여지가 없고 생각이 없는 일을 처리한다.만약 봇이 논란이 되는 편집을 한다면, 봇 플래그는 사라질 위험이 있고, 봇 운영자는 블록이나 다른 제재를 받을 위험을 무릅쓴다.봇 운영자는 봇을 이용해 혼란을 일으키지 않는 합리적인 사람들이다.

이러한 이면의 아이디어는 Special의 고정과 같은 무신경한 작업이다.DoubleRedirects는 "보호된 페이지"를 자주 친다.이 페이지들은 반보호를 이용할 수 없었던 훨씬 이전부터 전쟁, 공공 기물 파손, 또는 어떤 다른 형태의 방해 때문에 보호되었다.

• 페이지가 플래그 지정된 봇 편집으로부터 보호되지 않는 한 봇은 보호된 페이지를 편집할 수 있어야 한다.

이에 대한 다른 대안은 봇이 그러한 보호된 페이지를 편집할 수 있도록 관리 플래그를 부여하는 것이다.이것은 내가 내 제안보다 더 바람직하다고 믿지 않는 것이다.

-- 고양이 13:14, 2008년 7월 10일 (UTC)

1단계는 개발자가 작은 변화를 일으키는 것과 관련이 있고, 2단계는 오히려 많은 작업을 수반할 것이다.봇들을 관리자로 만들고 코드를 그들이 할 수 있는 것으로 제한할 수 있을 것 같아.전에도 그런 일이 있었다.업무량이 많은 (세미)자동관리계좌도 있다. 15:43, 2008년 7월 11일 (UTC)[응답]

코딩이 끝났다.참고: https://bugzilla.wikimedia.org/show_bug.cgi?id=13137 또한 Stewards는 처음부터 이러한 사용자 그룹을 쉽게 만들 수 있을 것으로 믿는다.

너는 그 봇이 제대로 작동한다고 가정하고 있다.봇의 코드가 제대로 작동하지 않을 수 있다.예를 들어, 봇이 실수로 메인 페이지를 비우고 관리 플래그가 있으면 계속 그렇게 할 수 있다.보안상의 이유 외에도 봇 관리자 계정이 적을수록 더 좋다.Bots는 보호된 페이지를 편집하기 위해 관리자만 사용한다.그렇다, 이것은 현재 범주를 통해 행해지고 있다. 하지만 그것은 정말로 일시적인 해결책이지 영구적인 해결책이 아니다.

반자동 관리자 계정(보호된 페이지 편집 기능 이상의 admintools를 사용하는 계정)은 관리 플래그를 유지할 수 있다.하지만 그것은 이 논의의 범위를 넘어선 완전히 다른 동물이다.

-- 고양이 09:22, 2008년 7월 12일 (UTC)

더블리디렉션이 보호된 페이지를 히트시킨다면, 그들이 정말로 보호되어야 하는지 확인하는 것이 아마도 좋은 생각일 것이다.나는 모든 것을 똑같이 취급하기보다는 이런 경우에 보호를 통한 비보호와 편집 사이에서 결정을 내리는 인간 행정가에게 맡기고 싶다.어차피 몇 번이나 이런 얘기가 나오느냐(데이터가 있나?)다른 봇 작업(CFD 후 재분류와 같은)은 이미 관리자 계정으로 실행되는 봇에 의해 수행된다.인터위키봇은 이 질문(추가 권한/보호 그룹이 과잉 살상일 가능성이 있음)에 대해 논쟁의 여지가 있기 때문에 보호를 통해 편집할 수 없어야 한다.쿠스마 (토크) 15:53, 2008년 7월 11일 (UTC)[응답]

맞아, 우리는 보호되는 페이지 수를 줄여야 해. 그건 전혀 다른 문제야.이중 리디렉션의 수동 수정에서 인간이 오류를 범할 확률은 봇보다 훨씬 크다.나는 이중 리디렉션(페이지가 보호되든 안 되든)의 수리를 봇에게 맡기는 게 낫겠다.관리자들은 그런 일에 신경 쓰지 말아야 한다.나는 더블 리디렉션에서 매주 보호된 페이지 히트를 받는다.실수는 없지만 범위가 다르다.

이 제안의 이면에 있는 아이디어는 관리자 권한을 가진 봇을 갖는 것이 아니다.일반적으로 봇은 차단, 삭제 등의 도구가 필요하지 않다.모든 관리 도구 중에서 봇은 보호된 페이지를 편집하는 데 그것을 사용한다.우리는 정말로 그렇게 많은 admin-bot 계정을 갖고 싶어 하는가?정말?

추가 보호 수준은 봇이 편집하지 않기를 원하는 메인 페이지와 같은 민감한 페이지에 대한 것이다.현재 이 작업은 템플릿/카테고리(오랜 기간 동안 수행됨)로 수행된다.내가 제안하는 것은 그것에 대한 미디어위키 지원이다.

-- 고양이^chi? 09:22, 2008년 7월 12일 (UTC)

"편집 보호" 권한이 있는 사용자는 내 생각에 계단식 보호 페이지(예: 메인 페이지)를 변경할 수 없다는 점에 유의해야 한다.펑피카 11:28, 2008년 7월 13일 (UTC)[응답]

나는 알 수 없을 것이다(나는 메인 페이지를 편집하려고 한 적이 없다 - 내가 할 수 있는 것은 아니다:P) 그러나 봇들이 계단식으로 보호되지 않는 반갑지 않은 페이지들이 있다.;) -- 고양이 13:15, 2008년 7월 13일 (UTC)

아티클 등급 설정

논사이클로피디아 같은 기사들을 평가해보는 건 어떨까.네비게이션 패널에 별 5개가 있는 페이지의 등급을 매기는 좋은 아이디어가 될 것 같다.
[+] • RRaunak에 의해 서명 및 서명 • [+]
2008년 7월 12일 11시 7분 (UTC)[응답하라]

그럼 네 싸인을 반 스타로 주겠다.너무 길고, 너무 산만하고, 마우스 포인터에 우스꽝스러운 짓을 한다. --카닐도 (토크) 23:19, 2008년 7월 11일 (UTC)[응답]

우리는 기사를 평가하는 방법을 가지고 있다. 그것들은 민주주의에 기반을 둔 것이 아니라, 지역사회가 우리의 글에서 우리가 원하는 특정 기준에 기초한다.위키백과 참조:좋은 기사 및 위키백과:특집기사. --Tango (토크) 01:39, 2008년 7월 13일 (UTC)[응답]

페이지가 어떻게 생겼는지에 대해 독자들로부터 피드백을 받는다는 생각은 장점이 있지만, 나는 그것이 효과가 있을 것이라고 생각하지 않는다.위키피디아에서는 너무 많은 것이 논란이 되고 있다.II (t - c) 01:51, 2008년 7월 13일 (UTC)[응답]

정치적 주제에 대한 SlashDot의 의견을 살펴봄으로써 이것이 왜 효과가 없는지 알아보세요.그리고 여론조사는 항상 충돌한다. (온라인 투표에서 모든 사람들이 한 가지 방법으로 투표하도록 포럼에 참석하게 한다.)— 당신을 먹여 살리는 손:^Bite 2008년 7월 13일 12시 12분(UTC)[응답]

요약 편집 가능

좋아, 난 이런 식으로 너무 자주 했어.편집하고, 편집 요약을 쓰고, "페이지 저장"을 클릭하지만, 단어의 철자를 완전히 틀렸다는 것을 알아차린다.지금 이 시점에서, 아무도 나의 기여를 보지 않기를 바라는 것 외에는 내가 할 수 있는 일이 없다.내 제안은 당신 자신의 편집 요약을 편집할 수 있는 것이다.위키백과 IRC 채널 중 한 채널에서 이 토론을 꺼냈는데, 아이디어는 아주 많았다.첫째는 관리자가 요약을 편집하게 하고, 다른 사용자들이 요약을 남용하여 조작할 수 있다는 두려움이 있기 때문에, 사람들이 요약을 요청하도록 하는 것이다.다른 하나는 오타를 수정하기 위해 사소한 편집만 할 수 있고, 편집 요약을 완전히 다시 쓰는 것을 금지한다.이상하게 들릴지 모르겠지만, 일부 사람들은 이것이 편집을 조금 더 쉽게 해줄 것이라고 생각한다.줄리안콜튼^Cyclone 17:06, 2008년 4월 23일 (UTC)[응답]

나는 정말로 이것이 필요하다고 생각하지 않는다. 또한 이것이 해결할 큰 문제도 아니다.만약 있다면, 사용자 스크립트는 저장하기 전에 편집 요약을 어느 정도 확인해야 하는 사용자 스크립트를 작성할 수 있다. - Rjd0060 (talk) 17:36, 2008년 4월 23일 (UTC)[응답

관리자만이 변경할 수 있고 변경 내역이 기록되는 한 그러한 기능은 유용할 것이라고 생각한다.그것은 오자와 사소한 실수에만 행해져야 한다.요약 편집은 당연히 허용되지 않을 것이다.메이저리 (토크) 2008년 4월 23일 18:17 (UTC)[응답]

나는 그것이 그 기사의 가장 최근의 편집일 경우에만 그것을 바꿀 수 있도록 그것을 가지고 있다고 말할 것이다. 물론 그것은 당신의 편집이었다.이것은 변경 이력, 관리자 전용 제한 등의 필요를 없앨 수 있고, 편집 요약을 유용하고 적절할 수 있는 대부분의 경우에 수정할 수 있다.케빈 바스^talk 18:21, 2008년 4월 23일 (UTC)[응답]

이것은 위키피디아의 데이터베이스가 어떻게 구성되는지에 대한 근본적인 변화를 필요로 할 것이다._{(1 == 2)}^Until 2008년 4월 23일(UTC) 18:40[응답]

어떻게 그럴 수가 있지? 테이블 이름이나 기둥 구조를 변경할 필요가 없을 것이다.데이터베이스에 관한 한, 그것은 단지 하나의 추가 "업데이트" 질의일 뿐이다."update [table] set summary=?어디의 물건인가?그리고 revision=?, and editor=?와 revision=[table]에서 max(개정)를 선택한다]. "데이터베이스 [구조]에서 근본적인 변화"라고 하는 것은 아니다.케빈 바스^talk

차라리 오자로 인해 가끔 이상하게 보일 수 있는 로그 요약(차단, 보호 등)을 변경할 수 있는 편이 낫겠다.MBisanz 18:43, 2008년 4월 23일 (UTC)[응답]

가능하다면 나는 그것을 지지할 것이다.그러나 요약의 끝에 "이 편집 요약은 <TIME/DATE>에 추가됨"과 같은 메시지가 추가된 다음 관리자가 편집 요약의 모든 버전을 볼 수 있도록 하는 것이 좋다. -- 임페라이터3733 (대화) 20:29, 2008년 5월 12일 (UTC)[응답]

편집 요약의 오타를 수정하는 데 시간을 낭비하는 이유요약 편집은 기사 내용의 일부가 아니므로 문법이 완벽하다는 것은 중요하지 않다.편집 요약을 수정하거나 철회해야 할 경우, 더미를 편집하거나 토크 페이지를 사용하십시오.–폼테 20:12, 2008년 4월 23일 (UTC)[응답]

왜냐하면 그것은 토크 페이지에 메시지를 남기기에는 훨씬 더 큰 시간 낭비가 될 것이기 때문이다.그리고 그렇게 오래 걸리지 않을 것이다.롤백 같은 것일 수도 있다.편집 요약을 편집할 수 있는 권한을 부여받고 버튼 같은 것을 누르면 된다.그리고 정말, 얼마나 많은 시간을 낭비할 것인가?또한, 편집 요약은 기사에서 변경한 내용에 대한 개요를 제공하도록 되어 있다.만약 당신이 철자를 잘못 썼거나 잘못된 정보를 주었다면, 사람들은 당신이 한 일을 오해할 수도 있다.줄리안콜튼 20:27^Cyclone (UTC) 2008년 4월 23일 (화)[응답]

그리고 더 나빠질 수도 있다.편집 요약을 쓰면서 가끔 키를 잘못 눌렀는데(아직 정확히 무엇을 했는지 모른다) 그 결과 요약의 절반만 남기고 편집이 저장됐다.이것은 분명히 도움이 되지 않는다.2008년 4월 23일(UTC) 21:02의 공작 월섬[응답]

그런 일은 항상 내게 일어난다.Enter 키를 누른 경우.hmwithm 18:26, 2008년 5월 15일 (UTC)[응답하라]

나는 케빈 바아스와 함께 이것을 할 것이다.가장 최근의 요약은 오타를 수정하기 위해 편집할 수 있어야 한다.그 이상, 나와 RfA 후보자들이 다시 한 번 자신들에게 힘을 실어주기 위해 돌아가는 것을 본다.—Paragon12321 (대화 • 기여) 22:29, 2008년 4월 23일 (UTC)[응답]

더 간단한 해결책이 있다.미리 보기를 표시할 때 편집 요약과 실제 편집을 교정하는 습관을 기르십시오.작은 실수를 하면 정말 문제가 되지 않는다.만약 당신이 정말로 그것을 망쳤다면, 수정하기 위해 다른 편집을 하라.

사람들이 요약 편집이나 편집 내용을 변경하도록 허용하는 것은 편집 기록을 다시 쓰는 것을 허용하고 있다.그것은 편집 이력의 무결성을 훼손한다.그 이득은 그 비용만큼 가치가 있는 것이 아니다.IMO. Wanderer57 (대화) 02:25, 2008년 4월 24일 (UTC)[응답]

해당 기사의 가장 최근 편집인 경우에만 편집 요약을 변경하도록 허용하지 않는 경우 - 다른 편집인 경우 편집 요약을 더 이상 변경할 수 없으므로 다시 쓸 수 없는 기록 레코드가 보관(및 표시됨)된다.케빈 바스^talk 2008년 4월 24일 (UTC) 15:36 [응답]

네 말이 맞을지도 몰라.나는 사람들이 편집 요약을 편집하는 데 수반되는 기술적 어려움을 과소평가하고 있고, 편집 요약을 편집하는 것의 이점을 과대평가하고 있다고 생각한다.Wanderer57 (대화) 06:01, 2008년 4월 25일 (UTC)[응답]

좋은 생각이야!나는 1시간에서 12시간 동안 최신 편집으로 제한할 것을 제안한다.코딩-현재는 절대적으로 비뇌적인 요소로서 (위의 코멘트와 대조적으로) 구현이 매우 쉬울 것이다.전폭적 지원 - 2008년 4월 26일 (UTC) су у 00:15, 응답하라

요약을 실수로 추가하지 않았거나 잘못된 요약을 삽입한 경우에도 이 방법이 좋다(탭이 많이 열려 있으면 해프닝).이것은 단지 요약본을 주거나 수정하기 위해 사이비언트들을 줄일 것이다.2008년 4월 26일 (UTC) 20:49, 샨샤할루드[응답]

짚폴

짚풀 여론조사를 시작하기에는 아직 이르다고 생각하는데, 세부 사항과 시사점을 조금 더 논의해 봅시다.2008년 4월 26일 (UTC) 20:49, 샨샤할루드[응답]

참고 항목: bugzilla:10105. --MZMcBride (대화) 20:55, 2008년 4월 26일 (UTC)[응답]

지원

1. 이것은 훌륭한 생각이다.현재, 반달들은 편집 요약에 불쾌한 의견을 넣을 수 있으며, 편집 내용을 기록에서 삭제하려는 시도 외에는 어떤 것도 할 수 없다.GO-PHS-NJROTC (대화) 20:29, 2008년 4월 26일 (UTC)[응답]

   나는 관리자가 다른 사용자의 요약을 편집하지 않아야 한다는 폭넓은 공감대가 있다고 확신한다.우리는 지금까지 모든 사용자들을 위해 제한된 시간 동안 당신 자신의 요약을 바꾸는 것에 대해 이야기 하고 있다.2008년 4월 26일 (UTC) 20:49, 샨샤할루드[응답]

   그것 참 안됐군; 나는 관리자들이 편집 요약을 편집할 수 있어야 한다고 생각해; 나는 너무 많은 위반자들이 편집 요약을 사용하는 것을 봐왔다.하지만 나는 여전히 지지한다. 내가 편집 요약을 망쳐서 다시 들어가서 문제를 해결할 수 있기를 바랬던 적은 많이 있었다.GO-PHS-NJROTC (대화) 00:20, 2008년 4월 28일 (UTC)[응답]

   공공 기물 파손 편집의 편집 요약이 그렇게 불쾌한 경우, 관리자가 수정본을 삭제할 수 있으므로 편집이 필요하지 않다.Equazcion •property/C • 09:34, 2008년 5월 4일 (UTC)[응답]

2. 나는 종종 내 요약을 편집할 수 있기를 바랐다 - 때때로 저장 버튼을 클릭했을 때 내 오류를 알아차렸다.사용자가 저장 후 즉시, 그리고 페이지의 다른 편집 전에 자신의 요약을 편집할 수 있도록 허용하는 것은 매우 타당해 보인다.Sbowers3 (대화) 00:02, 2008년 4월 28일 (UTC)[응답]
3. 해당 기사의 최신 편집일 경우에만 변경할 수 있도록 하십시오(물론 편집일 수도 있음).케빈 바아스^talk 2008년 5월 3일 (UTC) 14:19[응답]
4. 이 아이디어가 실행될 수 있다면 정말 멋질 것이다.관리자는 다른 사용자 요약을 편집하여 바보 같은 주석을 제거할 수 있다는 점을 제외하고 사용자는 자신의 요약만 편집할 수 있어야 한다.알렉스:. 2008년 5월 3일 19:25 (UTC)[응답하라]
5. 좋은 생각이야; 더 많은 사람들이 실제 텍스트의 편집 코멘트를 보고, 그리고 버튼을 누른 후 우리 모두는 몇 번이나 부우를 보았는가?토니 (토크) 2008년 5월 5일 (UTC) 14:00[응답]
6. 좋은 생각 - 몇 번 "페이지 저장"을 눌렀는데, 마지막 순간에 내가 편집 요약에서 아마도 거기에 있었어야 할 무언가를 빠뜨렸다는 것을 깨달았다.나는 이 제안에 대해 실질적인 단점이 없다고 본다.란키베일 12:12, 2008년 5월 12일 (UTC)[답답하다]
7. 지원 - 사용자는 페이지의 마지막 편집이고 2시간 이내인 경우 마지막 편집을 편집할 수 있어야 한다. -- 임페라이터3733(대화) 20:35, 2008년 5월 12일(UTC)[응답]
8. 지지 - 내 오른손의 손가락이 원래 있어야 할 위치에서 한 개의 키를 넘겨 "Save page"를 누를 때까지 알아차리지 못했던 이런 것들을 당황하게 하는 것을 멈출 수 있을 것이다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 00:02, 2008년 5월 17일 (UTC)[응답]
9. 지원, 사용자가 자신의 요약만 편집할 수 있다는 이유로.또한 관리자에게 요약을 편집할 수 있는 권한이 부여되어야 한다.Rgodermote 19:46, 2008년 5월 20일 (UTC)[응답]
10. 자체 편집 요약만 지원하지만 관리자는 누구나 불쾌한 편집 요약을 편집할 수 있다.던컨힐 (대화) 2008년 5월 21일 (UTC) 11시 5분 (답변)
11. 마지막 편집만 지원, 동일인/IP만 지원. --207.176.159.90 (대화) 23:58, 2008년 5월 21일 (UTC)[응답]

    설명:악의는 없지만 나 자신은 IP가 자신의 편집 요약을 편집하는 것을 좋아하지 않는다.나는 네가 IP인 것을 안다.하지만 나는 IP에 한도가 주어질 것을 제안하고 싶다.Rgodermote 18:11, 2008년 5월 22일 (UTC)[응답]

12. 지원 - 개인 데이터를 노출하는 모욕적인 요약이나 요약이 큰 문제지만, 지금은 편집 내용을 완전히 삭제하는 것 외에는 편집할 방법이 없다...대부분의 경우 해결책이 아니다.남용 방지를 위한 방법을 강구하되 실행해야 한다.레나타 (토크) 21:51, 2008년 5월 24일 (UTC)[응답]
13. 지원 나도 이 아이디어를 좋아하지만 그것이 도입할 수 있는 문제점들을 확실히 알 수 있다.만약 이것이 실행된다면, 나는 그것이 자동 확인 사용자 이상에 제한되어야 한다고 생각한다.아마도 sysops가 사용자의 요약 편집 권한을 취소할 수 있는 기능이 있을 것이다.또한 사용자의 마지막 편집에 대해 그리고 정해진 시간 동안만 가능해야 한다.——Ryan t • c 08:43, 2008년 6월 16일 (UTC)[응답]
14. 다시 돌아가서 편집 요약을 수정하고 싶기 때문에 뭔가를 넣지 못하거나 인쇄상의 실수를 범한 경우. --편집 축하해! 진심으로 2008년 7월 8일 (UTC) 02:26, 르그랜드 로이 데 시트로이유^Tally-ho!(Le Grand Roi des Citrouils) [응답]

조건부 지원

• 한편으로, 불찬성, 불쾌감, 홍보, 또는 위험한 편집 요약을 감시를 거치지 않고 제거할 수 있는 메커니즘이 있어야 한다.반면에, 나는 모든 사용자가 편집 요약을 변경할 수 있도록 허용하는 것에 반대한다.그것은 오용이나 오용의 가능성이 매우 크며 나는 일반 기고자가 마지막 편집에서 오타를 수정하는 것을 제외하고는 어쨌든 왜 그러한 능력이 필요한지 잘 모르겠다.내 의견은 sysops에게 공격적이거나 파괴적인 편집 요약을 수정하거나 제거할 수 있는 기능을 확실히 제공하고, 다른 사용자들이 어떤 종류의 시간 제한 하에서 가장 최근의 요약을 편집할 수 있도록 하는 것이다.Mr. Underness™ (Speak - 기여) 18:39, 2008년 5월 1일 (UTC)[응답]
• 예 – 요약 편집에서 오타를 만들었고, 때로는 (기본값을 사용하는 대신) 한 개를 썼으면 하는 바람도 있었다.이것은 깔끔한 생각이다.다만 법적인 문제가 있는지는 잘 모르겠다(따라서 '조건부'로 지원을 하고 있다.) 69.140.152.55 (토크) 14:10, 2008년 5월 12일 (UTC)[응답]
• "사실 중요하지 않다"는 쪽으로 기울어진 약한 지지, 편집 요약을 고칠 수 있었으면 하는 몇 가지 사례가 있었지만, 다시 말하지만 (상투적인 말은 무시하라) 별거 아니다.큰 기술적 장애물이 아니라면 편집 후 5분 동안 마지막 편집 요약만 편집하는 것을 지원하겠다.이종격리(talk ) review ) 16:40, 2008년 5월 15일 (UTC)[응답]
• 편집자가 편집 요약을 변경할 수 있는 경우 편집자가 자신의 편집인 경우에만 해당 페이지의 가장 최근 편집이며 12시간 또는 24시간 이상 경과하지 않은 경우, 이는 sysops를 포함한 모든 등록된 사용자에게 동일하게 적용되어야 한다.거기에는 남용될 가능성이 없으며(아무도 "기사 역사를 다시 쓰는 사람"은 없을 것이며), 잘못되거나 불완전한 요약의 모든 종류의 문제들은 혼란스럽거나 오해의 소지가 있는 요약을 남기거나 그렇지 않으면 쓸모없는 편집을 함으로써 역사를 복잡하게 만들지 않고 해결될 것이다.2008년 5월 18일 (UTC) 09:39, 월텀 공작 (Waltham, The Duke of 09:39 (UTC)[응답]
• 조건부 지원 좋은 생각, 비록 나는 이 능력을 갖지 않는 것이 위키피디아에 있는 대부분의 편집자들의 작업을 방해하는 중요한 장애로 보지 않는다.비교적 간단한 방법으로 고칠 수 있는 것이라면 나는 전적으로 찬성한다.만약 그렇지 않다면, 더 큰 물고기가 튀겨야 할 것이다. - 메이슨 패트리엇 (토크) 15:46, 2008년 6월 3일 (UTC)[응답하라]
• 조건부 지원 나는 사용자들이 자신의 편집 요약을 편집하는 것 만이 허용되어야 한다고 생각한다. 이렇게 하면 실수할 경우 수정할 수 있다.누가 편집 요약에서 모욕적인 말을 해도 상관없어.의사 익명 (대화) 02:03, 2008년 6월 9일 (UTC)[응답]
• 조건부 지원.이것은 좋은 생각인 것 같지만, 그것은 문제를 일으킬 수 있다.문제가 있는지 확인하려면 요약 편집 히스토리가 있어야 하는가?요약 편집 요약 편집?요약 편집 카운트?요약 기여 편집?요약 감시 목록 편집?최근 변경 사항의 요약 편집?그동안 자주 나만의 편집 요약을 편집하고 싶었는데, 200자 이내로 제한돼 있어 문제가 생길 수 있다.아마도 오직 당신이 당신 자신의 요약을 편집하는 것이 허용되고, 그러면 관리자는 당신의 편집 요약 편집이나 그와 비슷한 것을 볼 수 있을 것이다.고마워. ~AH1^(TCU) 16:40, 2008년 6월 15일 (UTC)[응답]
• 월섬 당 조건부 지원, 비록 컷오프 시간이 더 길어진다고 해도 나는 개의치 않는다.3일을 제안한다. « D. Trebien (대화) 2008년 6월 17일 (UTC 01:15
• 좋은 생각이야, 실용적이면 위키백과 개발자들은 그냥 앉아서 일을 기다리고 있을 거야.중요한 데이터베이스 문제가 있을 수 있는 것처럼 들리는데, 너무 많은 문제를 해결할 가치가 없다.타협안으로서, 나는 가장 최근의 편집만 바꿀 수 있다는 생각이 마음에 든다. 왜냐하면 그때가 네가 망쳤다는 것을 알기 때문이다.이건 어때?일반적으로 다시 편집하고 변경하지 않으면 새로운 결과가 나타나지 않는다.유일한 변경 사항이 편집 요약인 경우 다른 변경사항 대신 변경사항을 유지하거나 일부 변경사항인 경우그것은 다른 사람의 것이 아니라 당신 자신의 편집만을 위한 것이어야 할 것이다.야구 벅스 07:28, 2008년 7월 3일 (UTC)[응답]
• 아이디어 - 편집 요약에 추가할 수 있도록 설정예를 들어 어떤 것을 명확히 하기 위해 덧붙이고 더 이상 아무것도 하지 말라.예를 들어 7월 2일에 실수로 "핸들의 편집 삭제"를 입력하고 나중에 "(7/2/2008:1220)를 추가할 수 있다.반들 편집 내용 지우기(7/3/2008:1250 추가)를 의미했다."Kopf1988 (대화) 00:18, 2008년 7월 6일 (UTC)[응답]

반대하다

1. 야단 칠 가치도 없어.당황스러운 실수를 저지르거나, 편집되지 않은 후속 조치를 통해 잘못된 형식의 이전 편집을 올바르게 설명하십시오.그들의 제안서에서는 편집 히스토리 데이터베이스의 신뢰성과 고정성에 관한 너무 많은 문제가 발생한다. -- Yellowdesk (대화) 20:04, 2008년 5월 3일 (UTC)[응답]
2. 편집 요약의 언어는 종종 논쟁에서 인용되는데, 편집 후에 종종 매우 빨리 인용된다.요약의 오타에 대한 사소한 문제를 수정하는 것은 편집자가 돌아가서 미래의 사건에 기초하여 요약본을 수정할 수 있다면 이러한 주장을 검증할 수 있는 능력을 심각하게 위태롭게 할 것이다.솔직히, 선의의 의도는 차치하고라도, 이것은 전혀 생각나는 것이 아니며, 아니면 전에 몇 번의 논쟁을 따라온 사람에게도 그래야만 한다.어드레싱이 필요한 훨씬 더 나쁜 문제는 요약을 허용하지 않는 것이다.믹맥니 (대화) 18:16, 2008년 5월 13일 (UTC)[응답]

   그러나 이 제안에 따르면, 편집 요약은 마지막 편집일 경우에만 변경될 수 있었다.내가 보기엔 네가 하는 말은 대부분 일어나지 않을 것 같아.게다가, 누군가 관리자가 이전의 편집 요약을 볼 수 있도록 제안했다고 생각한다. -- 임페라이터3733 (대화) 14:42, 2008년 5월 14일 (UTC)[응답]

3. 많은 반대 - tooooooooooooooo의 많은 잠재력은 거의 아무런 혜택도 주지 않고 약간의 손상을 입힌다(Yeah, I know...), 만약 사람들이 편집을 철회하고 싶다면, 그들은 그 후에 항상 무효 편집을 할 수 있다.—TreasuryTag—t—c 18:56, 2008년 5월 13일 (UTC)[응답]
4. 이는 분쟁 해결, 반달리즘 투쟁 등의 과정에서 발생할 수 있는 큰 혼란을 상쇄하기 위한 편집 경험의 실질적인 개선은 거의 없는 것으로 보인다 --Gwguffey (토크) 19:46, 2008년 5월 13일 (UTC)[응답]
5. 강한 반대.우리는 "요약적인 공공 기물 파손"을 위한 경로를 만들지 않고 기물 파손에 대해 충분한 문제를 가지고 있다.– ukexpat (대화) 15:22, 2008년 5월 14일 (UTC)[응답]

   편집이 비교적 짧은 시간 간격 동안 마지막 편집으로 제한되는 경우 후속 편집(예: 반달리즘 수정)이 요약을 영구적으로 만들 때 반달리즘 또는 교란의 가능성을 보지 못한다.Cacycle (대화) 03:57, 2008년 5월 15일 (UTC)[응답]

6. 이런 일이 실제로 일어날지 의심스럽지만, 어쨌든 내 의견은 이렇다.네가 실수로 편집 요약에서 바보 같은 문법이나 철자 오류를 범했을 때 짜증난다는 건 동의해, 그래, 창피할 수도 있어. 하지만 알아맞혀봐, 우리 모두에게 일어난 일이고 중요하지 않으니 그냥 처리해.또한, 누군가가 위에서 지적했듯이, 요약은 논쟁에서 증거로 사용된다. 그래서 요약본을 편집하는 능력은 특정한 종류의 재귀적 복잡성을 더한다.페이지를 편집할 때 요약 편집이 필요하다는 것과 마찬가지로 요약 편집 역시 요약 편집이 필요할 수 있다. 결국, 그것은 증거를 변경할 수 있는 능력이기 때문에 이전 버전의 이력은 말할 것도 없고...그럼 점점 바보같아지지?틀림 없어요.이것은 단지 문제를 일으킬 뿐이고, 나를 믿어줘--그것은 그냥 일어나지 않을거야.어떤 개발자도 이런 불필요한 기능을 추가하지 않을 것이다.Equazcion •property/C • 2008년 5월 15일 (UTC)[응답]
7. 위와 같다.ES는 여기에 문서 문자를 가지고 있다.만약 우리가 편집가능하게 만든다면 우리는 그들을 위한 역사/퍼말릭 기능도 필요하다.이런 일은 없을 것이다.그 일로 시간을 낭비하지 마라.혜택은 미미하다.누구나 가끔 오타를 만들어, 그냥 빨아. --dschwen 17:09, 2008년 5월 15일 (UTC)[응답]
8. 강한 반대:RFArb 케이스에 자주 사용되기 때문에 당황스러운 편집은 숨기지 않는다. --Dragon695 (토크) 00:50, 2008년 5월 23일 (UTC)[응답]
9. 나는 편집 요약에서 철자 실수를 몇 번이나 했지만, 그것들을 편집하는 선택권이 백과사전을 향상시키는 것을 볼 수는 없다.철자 오류 - 사실 큰 문제가 아니라 과거의 부정적인 행동을 쉽게 숨길 수 있다는 것은 잠재적으로 큰 문제가 될 수 있다.요약 편집이 가능한 경우, 요약 편집이 가능한 기록인 경우, 요약 편집이 가능한 기록인 경우 요약 편집이 가능한가?게스트9999 (대화) 02:50, 2008년 5월 23일 (UTC)[응답]
10. 강한 반대 - 무시할 수 있는 이점, 오용/남용 가능성이 매우 높음. /Blaxthos(t / c ) 12:11, 2008년 5월 24일(UTC)[응답]
    • 나는 모든 야당들이 이것을 논쟁으로 사용하는 것을 언급하고 있다.요약이 몇 시간 안에만 변경될 수 있고 편집이 상위인 경우 어떻게 기능이 남용될 수 있는가?아니면 사람들은 편집 요약을 주는 것과 같은 날에 사건이 열릴 것으로 예상하는가?솔직히, 나는 이것을 이해할 수 없다.2008년 5월 26일 (UTC) 23:29의 공작 월섬[응답]
11. 반대한다. 그 혜택은 무시해도 되지만, 남용될 가능성은 상당하다.nsk92 (대화) 19:08, 2008년 5월 24일 (UTC)[응답]
12. 반대 요약 편집의 포인트 중 하나는 기록을 유지하는 것이다.요약 기록도 편집해야 하는가?편집 요약을 작성하여 변경 사항을 설명하시겠습니까?편집 요약도 좀 바꿔줄 수 있어?이 역시 개발자 시간 낭비다, 현재의 소프트웨어는 이렇게 할 수 없기 때문이다. 2008년 5월 24일 (UTC) 19:14, 24 (응답)
13. 반대 나는 이 제안이 해결책을 진전시키는 문제를 보지 않는다.나는 누가 어떤 요약을 편집하도록 허용되고, 그 특징을 남용하는 사람들, 그 특징을 남용한 것으로 의심되는 사람들, 또는 그 기능을 사용하지 않는 사람들이 그들에게 지시되어야 하는지에 대한 새로운 문제와 새로운 규칙을 상상할 수 있다.무효 편집 등 대신에현 상태가 실제로 괜찮은데 왜 새로운 쓰레기 층을 만들까?제리 토크 2008년 5월 26일 (UTC) 17:34, 응답
14. 만약 이것이 실행된다면, 수정은 투명성을 위해 기록되어야 할 것이다.그리고 물론, 사용자들이 왜 요약을 편집했는지에 대한 설명을 할 수 있는 분야가 있어야 한다.그리고 나서...오... 해피멜론 16:42, 2008년 5월 27일 (UTC)[응답하라]
15. 반대한다. 너무 적은 이익은 시간과 노력에 너무 많은 비용이 들 것이다.WODUP 20:36, 2008년 5월 27일 (UTC)[응답]
16. 그럴 가치도 없어그것은 위키에서 일어난 일에 대한 기록으로 되어 있다 - 만약 당신이 그것을 바꿀 수 있다면! 그것은 목적을 좌절시킨다.또한, 우리는 변화를 위한 로그가 필요할 것이다.하지만 사람들이 오타를 할 수도 있어...– Mike.lifeguard 23:39, 2008년 5월 31일 (UTC)[응답]
17. 강한 반대 완전히 불필요하고 학대의 진정한 잠재력이 이것을 매우 나쁜 아이디어로 만들기 위해 추가된다.우리는 모두 오타를 만들었고 다른 오타를 만들었고, 그래, 창피하다.하지만 그것은 큰 문제가 아니다.너무 실제적인 남용 가능성 때문에 이것이 실행될 수 없다.무신론 ^speak() 08:28, 2008년 6월 1일 (UTC)[응답]
18. 강한 반대 - 우리는 요약본이 아닌 기사 편집에 집중해야 한다.물론, 당신의 편집 역사에 철자가 틀린 단어가 있다는 것은 바보처럼 보이지만, 더 큰 그림에서 누가 신경 쓰겠는가?이 모든 것은 정말로 잠재적인 새로운 문제들을 열어주고 (아래에 언급된 "소유, 마지막, 최근의" 제한에도 불구하고) 위키피디아의 백과사전적인 내용을 개선하지 않는다.이와 같이 위키백과의 원칙에 어긋난다.위에서 언급한 바와 같이, 제출하기 전에 당신의 작품을 확인하라.또한 작업을 미리 보십시오.나는 제출하기 전에 때때로 이틀 동안 전체 기사를 편집하고 다시 쓰는 것을 미리 볼 것이다.변경 로그는 한 번의 편집으로 1만 개 이상의 문서 길이가 증가함을 나타내며, 다시 돌아가서 추가 편집을 할 필요가 없다.조심하면 편집한 내용을 편집할 필요가 없다.그렇다고 해서 내가 결코 실수를 하지 않는다는 말은 아니다(나는 결국 인간이지 봇이 아니다). 그래서 어쩌자는 것이다.가끔 바보들을 돌아보며 웃는 모습이 우스울 때가 있다. --Willscrlt (Talk) 11:07, 2008년 6월 1일 (UTC)[응답]

    Wilscrlt: 나는 우리가 요약의 오자를 수정하는 것에 신경 쓰지 말아야 한다는 것에 전적으로 동의한다.하지만 그것이 어쨌든 이 제안의 이유는 아니다.우리가 이것을 필요로 하는 유일한 이유는 빈 요약, 교환 요약, 또는 반작성 요약과 같이 실수로 오해의 소지가 있는 요약을 수정하기 위함이다.나는 위키피디아 사람들이 기사 대신에 오래된 요약을 편집하는 것에 집중하기 시작할 것이라고 생각하지 않는다. 그래서 나는 특색을 갖기 위해 이 좋은 것에 대한 당신의 강한 반대 - 특히 당신조차도 가끔 요약 실수를 한다는 당신의 고백 이후;-) Cacycle (대화) 19:07, 2008년 6월 1일 (UTC)[응답]을 갖는 것에 대해 당신이 강하게 반대하는 것을 이해할 수 없다.

    나는 그 이유가 a) 요약을 실수로 오해할 수 있기 때문이라고 생각한다. 어떤 주제에 대해 약간만 알고 있는 사람이 "심각한 변화"라고 여기는 것은 그것에 친숙한 누군가에게 큰 문제가 될 수 있다; b) 고의적으로 오해할 수 있다. 반달은 실제로 "오류"의 모든 발생을 바꿀 때 "오류 교정"이라고 말할 수 있다."purple"; c)는 많은 사람들이 신경 쓰지 않거나 이해하지 못하기 때문에 생략되는 경우가 많으며, d) 빠른 diff 비교에는 상대가 되지 않는다(나는 그것에 대해 팝업을 사랑한다).내 생각은 요약은 좋지만 소프트웨어의 필수적인 기능은 아니라는 것 같아.코멘트를 편집하는 것은 정말 그 프로젝트를 개선하는 데 소요될 수 있는 시간을 낭비하고 있다.그것은 또한 소프트웨어를 더 복잡하게 만들고 버그가 도입될 가능성을 증가시킨다.나는 MediaWiki 소프트웨어를 사용하는 다른 위키 두 개를 운영하고 있는데, 나는 그것이 크게 개선되지 않을 때 소프트웨어에서 피쳐링을 방지하고 싶다. --Wilscrlt (Talk) 23:08, 2008년 6월 1일 (UTC)[응답]

19. 반대 편집 요약은 독자에게 편집자가 한 일에 대한 일반적인 생각을 제공하는 데 사용된다.그들은 매우 중요하지 않다.결국, 독자는 항상 버전을 비교할 수 있고, 그 두 버전 사이에 무슨 일이 일어났는지 정확히 볼 수 있다.계속적으로 편집 요약을 변경하면 독자가 헷갈릴 수 있다("잠깐-뭐?방금 전에 다른 말을 하지 않았는가?") 그리고 반달족들의 다른 장소에도 쓰일이었다.요약 편집은 그다지 중요하지 않다!아까 말했듯이, 아무도 네가 한 일을 정확히 그 페이지에 옮기지 않을 거야, 그게 가장 중요해.IceUnshattered (talk) 00:12, 2008년 6월 10일 (UTC)[응답]

    나는 이 기능이 제안된 제한사항 하에서 공공 기물 파손에 어떻게 사용될 수 있는지에 대한 설명을 여전히 기다리고 있다.나는 또한 어떻게 당신이 편집자들이 그러한 제약에 따라 그들의 요약을 "지속적으로" 바꿀 것이라는 결론에 도달했는지도 흥미로울 것이다.나는 요약이 중요하지 않다는 것에 동의하지 않는다. 우리는 그것들을 좋은 이유로 가지고 있다. 즉, 삶을 더 쉽게 하기 위해서. 그리고 다시 말하지만, 이 제안은 실수로 오해하고 혼란스러운 요약을 수정하기 위한 것이다.Cacycle (talk) 00:50, 2008년 6월 16일 (UTC)[응답]

20. 그렇지 않으면 편집자가 RFA, RFB 또는 ARBCOM의 리드의 일부로 편집 요약을 삭제하게 되는 것에 반대한다.그래, 우리 모두 이상한 철자/일반적인 오류를 남기지만, 편집자가 편집 요약을 변경하면서 낭비 서버를 로드하는 이유를 잘 알고 있어.Gnangarra 04:10, 2008년 6월 17일 (UTC)[응답]

    실제 제안서는 아래의 "짧은 휴식" 섹션을 확인하십시오.편집 요약을 정리하는 것이 불가능하다는 것을 알게 될 것이다.Cacycle (대화) 2008년 6월 17일 (UTC) 23:05 [응답]

21. 반대한다. 나는 편집 요약을 편집하는 데 시간을 낭비하거나 심지어 이것을 하는 데 있어서 오용이나 혼동이 일어날 가능성이 무시해도 될 이익을 쉽게 능가한다고 생각한다.데이브윌드 (대화) 2008년 6월 19일 (UTC) 20:58[응답]
22. 반대론 이 기능이 남용될 수 있는 많은 방법들이 있다. 반달들은 편집된 요약본에 극도로 치명적인 인신공격이나 다른 외설적인 진술들을 게재한 다음, 그들이 그 당시에 최근의 변화를 지켜보면서 모든 사람들을 모욕했다는 사실과, 그리고, 그들이 그것을 가지고 있기 때문에 몇 초 안에 그것들을 제거할 수 있다.거기서 사용자들은 증거가 없는 요약을 한다.이러한 남용을 막을 수 있는 유일한 방법은 각 편집 요약본에 자신의 내력을 부여하는 것 뿐일 것이다. -Ic -wedGwed (gal () 06:12, 2008년 6월 30일 (UTC)[응답]
23. Oppose 기사의 발전을 따라가려면 불변의 기록이 있어야 한다.편집의 이력도 다시 작업해야 하는 것은 "teh"와 다른 철자를 고치는 사람들의 혼란은 가치가 없을 것이다.제이슨 퀸 (토크) 15:38, 2008년 7월 3일 (UTC)[응답]
24. 반대 왜 고장나지 않은 것을 고치는가?Yngvar (c) 12:52, 2008년 7월 5일 (UTC)[응답하라]
25. 반대하라. 그저 긴장을 풀고 후각적 오해가 당신의 평판에 그리 나쁜 오점이 아니라는 것을 받아들이라.루모스3 (대화) 10:01, 2008년 7월 14일 (UTC)[응답]

짧은 휴식 시간:

같은 얘기를 하지 않고 여론조사를 시작한 것은 정말 좋은 생각이 아니었다.

현재의 제안과 버그질라 논의는 여기서 찾을 수 있다.자신의 편집 (2)인 경우, 짧은 시간 동안 마지막 편집 (3)인 경우 요약 편집을 수정할 수 있는 메커니즘을 요구한다.이 정확히 동일한 메커니즘은 대부분의 온라인 포럼 시스템에서 구현되며 그 효과와 안전성을 입증했다.이러한 제한사항(소유, 마지막, 최근)에서는 남용 가능성이 절대 없다(예: 다음과 같은 편집은 이전 요약을 영구적으로 만든다).동시에 실수로 비어 있는 요약, 전환된 요약(탭이 많이 열린 경우) 및 반쯤 완료된 원시 요약을 수정하는 등의 이점을 유지하십시오.

나는 반대되는 사용자들 중 다수가 (분명히 다른 메커니즘에 대해 투표하고 있었던 일부 지원 사용자뿐만 아니라) 실제로 이러한 제한사항 하에서 그러한 구현을 지원할 것이라고 확신한다.다시 말하지만, 이것은 관리자가 요약을 변경할 수 있도록 허용하는 것이 아니라, 관리 후보자들이 편집 기록을 화이트 워싱하도록 허용하는 것이 아니며, 반달들에게 어떤 종류의 새로운 장난감을 주는 것도 아니다.위키피디아의 편집을 더 쉽게 하는 것은 좋은 기능일 것이다. 그 이상도 이하도 아니다.Cacycle (대화) 03:28, 2008년 5월 28일 (UTC)[응답]

전적으로 동의한다.위에서 투표한 편집자와 그들의 주장에 대한 정당한 이유와 더불어, 이것만큼 잘못 조직된 여론조사는 여기서 만들어진 특정 제안에 대한 합의에 대해 거의 유용한 정보를 제공하지 못한다.2008년 5월 30일 (UTC) 15:22, 월텀 공작 (Walthaltham, the Duke of 15:22

나도 동의해.나 역시 이 부분을 읽을 때까지 반대한다고 생각하고 투표의 희생자가 되려 했다.지금은 그 제안이 꽤 괜찮은 생각이라고 생각하고 있다. -- 네드 스콧 2008년 6월 25일 (UTC)[응답하라]

짧은 시간 동안 마지막 편집 (3)인 경우 - 단 1분 동안만 편집 요약이 존재하더라도 최근 변경 패트롤러뿐만 아니라 감시 목록에 페이지를 가지고 있는 편집자(특히 RSS 피드를 모니터링에 사용하는 편집자)에게도 이 요약이 표시된다는 점이 걸림돌이다.아마도 그것은 큰 문제가 아닐 것이다. 만약 반달족이 외설물을 게시하고 45초 후에 그것을 제거한다면, 외설물이 존재했다는 것을 증명하는 데 사용될 수 있는 통나무가 있을 것이다.그래도 위키피디아의 복잡성에 한 가지를 더 보태고 있다. -- 존 브로우턴 (식용차) 14:54, 2008년 7월 1일 (UTC)[응답]

중립

• 위에서 언급한 많은 사람들처럼, 이것은 구현에 있어 어려울 수 있고 아마도 더 중요한 것은 광범위한 영향을 미칠 수 있다.내 제안은 특별한 종류의 '변경 편집 요약' 편집이 될 것이다.이것은 실제로 편집 요약을 변경하는 대신 자동으로 완전히 null 편집을 만들고 이전 편집 요약을 '복구됨' 또는 그 중 어떤 것으로 표시한다는 점을 제외하고 위와 같은 기능(편집한 사람이 가장 최근에 편집한 경우에만 가능함)을 할 수 있다.rt(사소한 편집 및 봇 편집에 적용)기본적으로, 이러한 폐기된 편집 요약은 숨겨지지만 편집자들이 그렇게 원한다면 분명히 요약본을 보도록 선택할 수 있다.내 제안은 이것을 편집에도 적용시키는 것이다. (항상 완전히 선택적일 것이다.)이러한 방식으로, 예를 들어, 미리 보기를 하지 않거나 빠르게 여러 번 편집하지 않는 편집자는 다른 편집자가 편집 내역을 더 쉽게 검색하도록 하려면(그러나 다른 편집자가 원할 경우 다른 편집자는 여전히 중간 편집 내용을 볼 수 있다) 중간 편집 내용을 숨길 수 있다.이 경우 시간 제한은 아마도 자신이 재미있고 파괴적이거나 다른 문제를 일으킨다고 생각하는 편집자들을 피하고 몇 시간 후에 자신이 하고 있는 일을 숨기려 하고, 나중에 나쁜 일을 숨길 수 있다고 생각될 때 편집자들이 편집하도록 부추기는 것을 피하기 위해 중요할 것이다.잠재적으로 이것은 추가적인 오용을 방지하기 위해 자동 확증 옵션 또는 롤백 옵션으로 추가되어야 한다.닐 아인 (대화) 06:50, 2008년 5월 1일 (UTC)[응답]

  우리가 현재 이야기하고 있는 제한사항(마지막 + 짧은 시간 동안 자체 편집)에서 나는 남용 가능성을 보지 못한다(결국, 페이지에 대한 다음 편집은 이전 요약을 영구적으로 만든다).그러므로, 나는 우리가 이것을 위해 역사가 필요하다고 생각하지 않는다.해당 편집의 요약 항목을 변경할 수 있는 기록 페이지의 단순 링크가 이 작업을 수행할 수 있다.우리는 아마도 이것을 등록된 사용자들로 제한하고 싶지만, 나는 우리가 더 이상의 제한이 필요하지 않다고 생각한다.2008년 5월 1일 (UTC) 21:46, с사할 с사할 е사할 е사할 е사할 е사할 е사할 е사할 е

• 편집자가 자신의 편집 요약을 편집할 수 있어야 하는지에 대해서는 여전히 대략 중립적인 입장이지만(두 가지 관점은 다 볼 수 있지만, 개인적으로 아직 결정하지 않았다) 관리자들은 '누구의 편집'을 편집할 수 있어야 한다고는 생각하지 않는다.그렇다, 토크 페이지 코멘트는 편집될 수 있지만, 특정 상황에서만 편집될 수 있다. (그리고 나는 그러한 편집에 대한 관리자의 연속적인 복귀를 충분히 보았다.)그리고 우리는 정말로 요약 편집의 역행 이력이 만들어지는 것을 볼 필요가 없다.그래서 이 문을 여는 것은 좋지 않은 생각인 것 같다.그리고 관리자들은 항상 문제의 수정본을 삭제할 수 있기 때문에 진짜 "필수"는 없다. (그리고 그것은 또한 삭제되지 않을 수도 있다.그리고 이미 통나무 세트가 있다.)만약 그것이 정말로 필요하다고 생각되면, 단지 이 능력을 감독 "패키지"에 추가하라. - jc37 20:17, 2008년 5월 6일 (UTC)[응답]

https://bugzilla.wikimedia.org/show_bug.cgi?id=13937에서 이에 대한 "공식 기능 요청" 토론에 참여하십시오.Cacycle 19:16, 2008년 5월 3일 (UTC)

Bugzilla는 기술적인 구현을 위한 것이지 이런 종류의 논의를 위한 것이 아니다.개발자들은 당신이 "DO WAND!"로 버그를 스팸메일을 보내기 시작하면 기분이 좋지 않을 것이다. – Mike.lifeguard 03:59, 2008년 6월 1일 (UTC)[응답]

제안:기존/경험이 풍부한 편집자가 삭제된 기여도를 볼 수 있도록 허용

많은 편집자들이 몇 년 동안 존재해왔고 수천 개의 편집을 했지만, 반드시 관리자가 되는 것에 관심이 있는 것은 아니다.그럼에도 불구하고, 그러한 편집자들은 삭제된 기고문을 보는 것이 정말로 적절하고 논의 중인 기사들과 후보자들을 평가하는 데 도움이 될 수 있는 삭제 검토와 관리 논의 요청에 참여한다.그러므로, 나는 우리가 그러한 토론의 목적을 위해 기고문을 삭제한 것을 (삭제하지 않고, 그냥 볼 수 있는) 수천 개의 편집이 있는 확립되고 경험 많은 편집자들이 볼 수 있는 기준을 제시할 것을 제안한다.나는 그러한 편집자들이 삭제되지 않은 기능을 다루지 않고 기여를 볼 수 있도록 하는 것이 기술적으로 가능하다고 확신한다.진심으로 --Le Grand Roi des Citruilles^Tally-ho! 20:07, 2008년 6월 27일 (UTC)[응답]

좋은 생각인 것 같아, 그 내용을 실제로 볼 수 없다면 기사 삭제 여부를 결정하기는 좀 어려울 것 같아--Jac1688 (토크) 20:16, 2008년 6월 27일 (UTC)[응답]

• 나는 100% 동의한다. 정말 아무도 그것을 보지 않을 이유가 없다.실제 위키백과 공간에 들어 있지 않기 때문에 누구도 허가된 글과 혼동하지 않을 것이다.--리처드 아서 노턴(1958- ) (토크) 20:29, 2008년 6월 27일 (UTC)[응답]

• 누락된 사용자는 Wikipedia:중재위원회/2008년 6월 발표/시청각삭제 페이지 활성화 - 위원회가 지역사회를 정책적으로 구성하도록 권고하는 발표로서, 결정의 발표가 아닌 최소한 포함시킬 것을 권고한다.GRBerry 21:16, 2008년 6월 27일 (UTC)[응답]

• 위키백과 대화:중재 위원회/2008년 6월 발표/뷰 삭제 페이지 활성화는 아마도 이 논의를 하기에 가장 좋은 장소일 것이다.davidwr/(대화)/(논문)/(이메일) 00:11, 2008년 6월 28일(UTC)[응답]

• 카피비오, BLP 등은 철저히 통제하는 것이 중요하다.내가 그런 제안을 하기 전에, 그것은 일정 기간 동안 특정 기사로 제한되어야 할 것이다.삭제 검토가 활발하게 진행되고 있는 기사에 접근할 수 있는 "삭제 검토자" 사용자 권리는 타당하다.RfA 또는 기타 권한 이양 과정에서 삭제된 편집에 액세스할 수 있는 별도의 사용자 권한도 이치에 맞는다.삭제된 기사의 경우, 이것은 RfA 후보자들이 편집한 것과 비교를 위한 바로 앞의 편집만 보여줄 뿐 다른 편집은 볼 수 없다.RfA 방식의 투표가 없다면, 두 가지 권한을 모두 편집이 많은 오래된 계정과 최근 활성화된 편집 이력을 모두 가진 사람에게 제한하는 것도 타당하다.그러한 권리는 6개월 후에 자동으로 만료되며, 만약 그 사람이 여전히 편집자라면 거의 자동 갱신으로 권리는 갱신될 것을 권하고 싶다.'능동적 편집자', '옛 계정', '여러 편집자'를 정의하는 것은 나중에 해시할 수 있는 것이지만, 적어도 6개월, 수 천 개의 편집자, 그리고 바로 지난 6개월 동안 최소 100개의 편집을 권하고 싶다.이 말이 복잡하게 들리기도 하고, 그렇기도 하지만, 모든 비지견적인 삭제 편집에 접근할 수 있는 클래스 "읽기 전용 관리자"를 만드는 것은 필요하지도 바람직하지도 않다.davidwr/(대화)/(논문)/(이메일) 21:08, 2008년 6월 27일(UTC)[응답]

• 꽤 좋은 계획인 것 같은데.그러한 권리를 얻는 과정은 AWB 권리를 얻는 과정에 기초할 수 있다. -- 임페라이터3733 (대화) 21:13, 2008년 6월 27일 (UTC)[응답]

• AWB에 대한 요구사항이 이 개념에 대한 요구사항과 비교될 만큼 선택적인가(삭제된 페이지 보기)?—레너드^블룸(토크 • 기여) 22:47, 2008년 6월 27일 (UTC)[응답]에 의한 서명되지 않은 논평 준비

• 내 생각에는 스레드의 영향을 받는 사람으로서 총 편집이 2만 건이 넘었고 2006년부터 편집도 해왔으며 롤백 권한도 있지만, 몇몇 편집자들이 나를 관리직에 지명하겠다고 제안했지만 나는 비관리 분야에 집중하느라 지금까지 거절했다.나는 RfAs와 DRV에 대한 나의 논평이 삭제된 기여에 근거한다면 더 현명할 것이라고 생각한다.게다가, 개인적으로도, 나는 결코 카피비오나 BLP를 편집한 적이 없고 앞으로도 결코 없을 것이다. 그래서 나는 내 기여의 총체성을 볼 수 있어야 한다고 생각한다.Best, --Le Grand Roi des Citruilles^Tally-ho! 23:24, 2008년 6월 27일 (UTC)[응답]
• 단지, 알다시피, 나는 그 과정이 AWB와 정확히 같아야 한다고 말한 것이 아니라, 단지 그 과정이 비슷해야 한다는 것. 즉, 일련의 "요건들"을 생각해 내라, 그리고 만약 누군가가 그러한 능력을 원한다면, 한 페이지에 지원(AWB와 마찬가지로), 그리고 대부분의 경우에 그들은 허가를 받는다.이렇게 하면 어느 정도 승인절차가 있게 되겠지만 RfAs만큼 관여하지는 않는다. -- 임페라이터3733 (토크) 19:21, 2008년 6월 30일 (UTC)[응답]

(ec) 이것에 대해 지나치게 제한하지 말자.기성 편집자들은 blp와 copyvio를 퍼뜨리는 것을 피하기에 충분한 감각을 가지고 있으며, 만약 그들이 그것을 다시 삽입하려고 한다면 그들은 더 이상 기성 편집자가 될 수 없을 것이다.만약 그들이 다른 곳에서 그것을 사용하는 것이 걱정된다면, 만약 누군가가 불신감을 갖고 싶다면 삭제된 코멘트를 받을 수 있는 다른 방법들도 충분히 있다.나는 여기서 좋은 평판을 가진 사람이 그것을 가지지 못하게 할 이유가 없다고 본다. 그것에 대해 하지 말아야 할 것에 대한 적절한 경고와 함께.우리는 1500명의 모든 관리자들을 100% 지각 있는 사람으로 완전히 신뢰하지 않기 때문에, 정말로 민감한 자료는 지나친 시력이다.

6개월의 제한은 말도 안 되는 일이다. 왜냐하면 우리는 그들이 일을 제대로 한다면 그보다 경험이 적은 완전한 관리자로 만들었기 때문이다.AWB는 메인 스페이스에서 500개의 편집을 필요로 하며, 그렇게 많은 작업을 성공적으로 수행하는 사람은 아마도 이 매우 제한된 목적을 위해 충분히 신뢰할 수 있을 것이다.하지만 이것이 AWB와 같은 상영권이 아닌 자동권이라면, 그렇다, 그것은 그것보다 조금 더 높아야 한다.그리고 Arb com에 의해 제안된 사용의 일부는 AWB가 할 수 있는 대부분의 것과 달리 메인 스페이스에서의 많은 경험을 요구하지 않는다.

또한 편집자는 자신이 작성한 편집 내용을 볼 수 있어야 한다.단순히 말이 되지 않는다. 23:31, 2008년 6월 27일 (UTC) —DGG(대화 • 기여) 23:31, 2008년 6월 27일 (UTC)[응답]

카피비오와 BLP를 언급한 것은 재게시될 가능성이 높기 때문이 아니라, 저작권이 있는 자료를 선별된 소수가 이용할 수 있게 되면 저작권 소송을 제기할 수 있기 때문이다.마찬가지로 BLP 자료가 시야에서 삭제되지 않으면 명예훼손 소송을 불러올 수 있다.현재 현실은 많은 BLP와 카피비오 항목들이 지구상의 모든 인터넷 사용자들에게 공개되는 삭제되지 않은 편집에 포함되어 있기 때문에 소송의 위험성이 그렇게 높지 않을 수도 있다.단, 진행하기 전에 최소한 가능성을 인정해야 한다.davidwr/(대화)/(기여)/(이메일) 23:45, 2008년 6월 27일(UTC)[응답]

관리자가 그 내용을 보는 것이 괜찮다면 DRV와 RfAs에 참여하는 관리자만큼 많은 기여를 한 사용자들도 이러한 기여를 볼 수 있어야 한다고 생각한다(물론 그것은 전반적으로 편집자의 수가 제한적일 것이다) 그리고 DGG나 다른 누군가가 말한 것처럼 우리는 최소한 우리 회사의 전체성을 볼 수 있어야 한다.전입금Best, --Le Grand Roi des Citruilles^Tally-ho! 00:08, 2008년 6월 28일 (UTC)[응답]

확실히 승인 롤백 도구 시스템을 사용하는 것이 좋을 것 같으며, 이 역시 관리 도구인 만큼 유사한 설정-Jac16888 (토크) 23:37, 2008년 6월 27일 (UTC)[응답]을 하는 것이 더 타당하다.

중요한 차이점은 롤백과 AWB는 어떤 새로운 힘도 부여하지 않는다는 것이다. 단지 새로운 편의성과 정말로 천천히 보다는 급하게 일을 망칠 수 있는 능력이다.삭제된 자료를 볼 수 있는 권한을 부여하는 것은 의미심장하며, 극단적으로 그것은 컴퓨터에 대한 "백업 운영자" 권한과 같다.그렇기 때문에 그것은 지역사회의 승인을 받은 사람들 또는 실수를 저지르지 않는 것만을 신뢰하는 것이 아니라 대중에게 숨겨져 있는 정보를 오용하지 않는 것을 신뢰하는 사람들을 위해 남겨져야 한다.나는 우리가 WP에게 가시성을 이야기하지 않는다는 것을 안다.감독된 편집이 있지만, 우리는 대부분의 사람들이 할 수 없는 것을 보고 이야기하고 있다. davidwr/(대화)/(기여)/(이메일) 23:51, 2008년 6월 27일 (UTC)[응답]

현재 관리자(많은 사용자)가 자신의 사용자 페이지에서 삭제된 자료를 사용자가 요청에 따라 볼 수 있도록 하는 시스템이 왜 충분하지 않은지 모르겠다.가래닭 (토크) 2008년 6월 28일 (UTC) 00:00[응답]

중간자를 건너뛰는 것은 시간을 절약하고 더 효율적이다.기존의 편집자들이 그들의 기여를 모두 볼 수 없는 이유는 없다.진심으로 --Le Grand Roi des Citruilles^Tally-ho! 00:03, 2008년 6월 28일 (UTC)[응답]

단편화는 의도적인 것이 아니다: ArbCom의 논의는 커먼스-관리자-관찰-우리의 삭제-이미지 문제에 관한 것이며, 이는 이 논의와 연관되어 있을 뿐이다.새로운 문제에 대한 논의.삭제된 기부금을 볼 수 있는 위키 권한, 즉 이것이 바로 이 실에 보관되어야 한다.해피멜론 21:23, 2008년 6월 28일 (UTC)[응답]

크론즈 문제는 아르브컴 페이지에서도 언급되지 않고, 토크 페이지의 첫 부분에서만 언급되었다고 생각한다.그 제안은 세계 권리를 위한 것이고 메타에 대해 주로 논의되고 있다.Mr.Z-man 22:30, 2008년 6월 28일 (UTC)[응답]

나는 모든 관리자 권한 없이 약간 확대된 사용자 권한 세트에 매우 관심이 있다.나는 사용자를 차단하거나 페이지 보호를 다루고 싶지 않지만, 삭제된 페이지/이미지를 볼 수 있다면 도움이 된다는 것을 종종 발견하곤 한다.WP의 나머지 두 가지 항목은 다음과 같다.내가 관심있는 UAL#Table list에는 "editprotected"와 "unwatched pages"가 포함되어 있다. -- Quidity (talk) 20:13, 2008년 6월 29일 (UTC)[reply]

뭐야, 너만 먹을 수 있는 옵션을 원하지 않는 거야?그리고 우리는 단 하루만 1대 2의 감독 제안을 하고 있다: 구매, 반값 받기!!:D 심각하게도, 내가 보고 싶은 많은 관리자 권한이 있지만, la 롤백, ipblockexempt 등이 따로 있는 것은 아니다.왜 우리는 (물론 더 좋은 이름을 가진) 사용자 그룹과 이념적으로 반대되는가., , , , , , , , , 그리고 다른 소수의 사람들을 한데 묶어서 롤백처럼 펼쳐라: 당신은 날카로운 모서리가 없는 모든 관리 도구를 갖춘 사람을 구하게 되고, 당신은 관리자들로 하여금 보호, 삭제, 차단이라는 '빅3'를 자유롭게 처리하게 한다.해피멜론 20:26, 2008년 6월 29일 (UTC)[응답]

APIusergroups 목록을 보면 덜 위험한 관리 권한 deletedhistory, 수입(사용하지 않는), move-subpages, autopatrol,proxyunbannable(사용하지 않는), 역행, trackback(사용하지 않는), reupload-shared(이 무슨야겠지, 사용하면 안 될 것), unwatchedpages,upload_by_url(장애인이 되는 것 같습니까?),ipblock-exempt, markbotedits(rollback에), 저녁밥을 먹다 있다.Pressredirect(현재 사용되고 있지), apihighlimits,browsearchive,noratelimit, tboverride,override-antispoof, uboverride.Mr.Z-man 03:48, 302008년 6월(CoordinatedUniversalTime)[답장].

나는 사용자 그룹에 대한 해피멜론의 생각에 동의해.이 그룹은 관리자가 될 준비가 되지 않았다고 생각하거나 전혀 원하지 않는 숙련된 편집자들에게 주어질 수 있다.현 그룹도 이 그룹에 합병될 수 있다. -- 임페라이터3733 (대화) 19:30, 2008년 6월 30일 (UTC)[응답]

여러 가지 이유로, 나는 "신뢰할 수 있는" 그룹의 아이디어도 좋아한다 - 누구나 RFA를 필요로 하지 않는 기준인 계정을 얻을 수 있기 때문에, 단순히 "이 사람은 아이디어를 폭넓게 가지고 있고, 비록 완벽하지는 않더라도 대부분 확실하게 편집한다"고 말할 수 있다.대략적으로 높은 위험 대 낮은 위험과 연관되며, 또한 그것을 원하는 사용자, 자신의 명성과 업무에 대한 검토가 있을 것이라는 것을 알고, 따라서 좋은 평판을 쌓고 좋은 일을 하는 것이 조금 더 의미 있을 수 있다는 것을 의미할 수도 있다:) FT2^{(Talk email)} 23:08, 2008년 7월 3일 (UTC)[응답]

유일한 문제는 삭제된 컨텐츠를 볼 수 있는 능력 외에, 대부분의 "안전한" 관리자 권한은 사용되지 않거나(수입), 거의 사용되지 않거나(표시되지 않음), 별로 도움이 되지 않거나(비공개 페이지), 또는 대다수의 사용자가 결코 필요로 하지 않을 수 있는 중단 예방 조치(tboverride)를 위한 우회(tboverride)라는 점이다.특히 우리가 삭제된 역사권을 이것과 함께 묶지 않기로 선택한다면, 그것은 기본적으로 상태 상징에 지나지 않을 것이다.Mr.Z-man 23:37, 2008년 7월 3일 (UTC)[응답]

위와 같은 답변으로, 삭제된 기사를 복사해 주겠다고 하는 현재의 관리자 체계는 주의사항과 함께 있다.카피비오도 없고 BLP도 없고 일반 대중에게 부적절한 것도 없어나는 내가 삭제했다는 것을 알고 있으며, 대중이나 일반 편집자가 접근하기에는 적합하지 않은 기사에서 삭제된 정보를 본 적이 있다.그들의 삭제된 기고문을 보는 일반 편집자에 대해서는, 나는 그것이 이 제안의 목적이 아니라고 생각한다.이것은 진정한 욕구를 가진 사람들을 위한 것이다.호기심은 진정한 욕구가 아니다.내가 방금 말한 이유 때문에 중인을 건너뛰겠다는 생각은 추호도 없다.이것이 구현될 경우, 요건은 성공적인 RfA와 동등한 수준이 될 것이다.커뮤니티 신뢰, 블록이나 학대의 실제 이력 없음 등나는 누군가가 이 능력을 원하면 그들이 RfA를 통과시킬 수 있다는 것을 증명할 필요가 있다고 생각한다.나이트라고 (토크) 19:07, 2008년 7월 3일 (UTC)[응답]

일반적인 의견:일단.나는 이것이 기발한 생각이라고 생각한다.이 제안에는 헛간 스타가 있어야 한다고 생각해!KnightLago에 대한 답변:안녕 나이트라고.나는 정중하게 반대한다.그 이유는 이렇다.나는 이 기능을 직접 사용하고 싶지만 과거에는 차단되었었다.나는 몇 가지 이유로 개인적으로 차단당했는데, 지금 생각해 보면, 그것이 정당화되었을지도 모른다.그러나 나처럼 막혔을 만큼 충분한 경험을 가진 사람이라면 공동체의 신뢰를 저버린다면 그 실체가 무엇인지를 확실히 알아야 한다.예를 들어, 이 새로운 기능을 중단에 사용하는 것은 자동 블록으로 간주될 가능성이 높다.나는 다른 많은 예들을 생각할 수 있지만, 한가지 떠오르는 것은 내용을 둘러싼 편집상의 논쟁이다.그러한 분쟁은 삭제된 페이지 기록으로 돌아갈 수 있는 특권을 쉽게 영구적으로 또는 일시적으로 빼앗을 수 있는 현재의 채널(Admins)에 의해 처리될 것이다.또한, 나는 RfA가 정말로 이 특권에는 적용되지 않는, 거의 쓰레기 같은 정치라고 생각한다.(몇 년 전 나의 RfA가 많은 공을 세웠기 때문에 나는 약간 편견을 가지고 있다.그럼에도 불구하고, 나 역시 지금 당장은 관리자가 되는 것에 별로 관심이 없고, 경험이 많은 사용자들이 삭제된 페이지를 확인할 수 있는 것이 좋은 생각이라고 생각한다.특히 경험 있는 사용자(2년 동안 8000개 이상 편집)라고 생각한다.의무적으로 2년)은 삭제된 모든 페이지에 대한 액세스가 허용되어야 한다.경험이 적은 사용자(2000~799번 편집 또는 1년 경력(2000~799번 편집 또는 2년 이상 편집한 경우 편집 번호를 충족해야 함)는 자신이 특별히 제공하는 콘텐츠에만 액세스할 수 있어야 한다.(내가 경험이 적은 사용자라고 말하는 이유는, 가끔 나의 경우, 새로운 기사를 만들었던 기억이 나며 (2008년 5월만) 정직하게 그것이 만들어낼 수 있다고 믿기 때문이다. (사용자: 참조)CyclePat/Rhumart).페이지를 내 사용자 페이지로 이동한 후 다시 요청해야 Free World Trust 대 Elelectro Santé Inc.로 정보를 병합할 수 있었다.그리고 그 위에 내가 유일하게 편집자였기 때문에 덧붙인 멜로드라마가 있었는데, 그 이유는 콘텐츠의 빠른 삭제를 시도했기 때문이고, 페이지를 내 자신의 사용자 페이지로 옮기려고 했기 때문이다.어쨌든...나는 단지 이 이야기를 여러분과 나누고 싶었을 뿐인데, 그것은 책에 의한 절차를 따르기를 원하는 멜로디 관리자들을 어떻게 줄일 수 있는가에 대한 적절한 예라고 생각하기 때문이다.나의 경우, 관리자가 페이지를 삭제할 수도 있었고, 그때 내가 직접 페이지를 사용했을 수도 있었다.마지막으로, 새로운 편집자들은 위키피디아의 정책을 완전히 이해하지 못할 수도 있고 트롤일 수도 있으며, 단순히 같은 페이지를 다시 만들 수도 있기 때문에 접근해서는 안 된다고 생각한다. --CyclePat (대화) 17:54, 2008년 7월 5일 (UTC)[응답]

음, 내 리스트에 추가되는 걸 보면 항상 행복해! :) --해피 편집! 진심으로 2008년 7월 5일 (UTC) 18:05 (Le Grand Roi des Citruilles^Tally-ho!)[응답]

FWIW, 계층화된 삭제에 대한 소프트웨어 지원은 아직 코드 검토 중이고 아직 켜지지 않았지만 거의 완료되었다.그것이 활성화되면 그것을 어떻게 사용할지 결정하는 것은 지역사회에 달려있다.건배. --Gmaxwell (대화) 20:35, 2008년 7월 3일 (UTC)[응답]

나는 계층화된 삭제 시스템을 사용하여 삭제된 내용을 나누어야 한다고 생각한다."신뢰할 수 있는" 사용자 그룹은 알림 문제 등으로 인해 삭제된 모든 항목에 액세스할 수 있었다.Copyvios와 BLP는 여전히 관리자만 볼 수 있다.설정/경험이 있는 사용자가 인지성 문제가 있는 정보를 보는 것이 잘못된 것은 생각할 수 없고, 그 정보에서 주목할 만한 것을 발견할 수도 있을 것이다.나는 "알 수 없는" 기사들이 아니었기 때문에 빠르게 고갈된 기사를 몇 개 만들었지만, 나는 여전히 그것들이 위키피디아에 포함되어야 한다고 믿는다.기존 사용자에게 이 콘텐츠에 대한 액세스 권한을 부여하면 위키백과에 도움이 되고 부정적인 영향이 많지 않을 것이다. -- 임페라이터3733 (대화) 01:10, 2008년 7월 4일 (UTC)[응답]

확실히 이 계층적 삭제 시스템은 이 제안에 대한 유일한 주요 우려를 효과적으로 부정한다. 더 많은 사람들이 카피바이오와 블립비오에 접근할 수 있다는 것. 관리자에 의한 이상한 실수에서 벗어난 두려움으로, 그렇다면 나는 정말로 이것을 진행하지 않을 어떠한 이유도 볼 수 없다. Jac16888 (토크) 20:03, 2008년 7월 5일 (UTC)[응답].

나는 단지 전체 토론을 다시 읽었을 뿐이고 몇 가지 유망한 아이디어가 있다는 것을 인정한다.내가 주장하던 RFA와 유사한 요건을 갖춘 높은 기준은 삭제된 특권을 일반적인 관점으로 보는 것이다.나는 그런 생각을 하는 것이 마음에 들지 않고 몇 가지 이상의 문제가 있을 것이라고 생각한다.다비드워의 말대로 카피비오스, BLP 정보, 명예훼손, 공격 페이지 등은 호기심 외에 그 정보를 실제로 볼 필요가 없는 대중이 이용할 수 있을 것이다.소송의 위험성이 높지 않다는 데는 동의하지만, 가능성은 더 커진다.게다가, RFA와 DRV는 시청만 삭제한다는 아이디어는 흥미롭고 그것에 대해 생각해 본 후에 나는 진정한 필요가 있다는 것을 인식하기 때문에 나는 그것을 지지할 것이다.삭제된 자신의 편집 내용을 볼 때, 특정 시간 제한 및/또는 편집 횟수 이후가 허용될 수 있다.문제는 제한/가능성이 너무 낮게 설정되면 새로운 사용자가 삭제된 콘텐츠나 트롤을 계속 재생성하는 것이다.계층적 삭제 시스템에 대해서는, 그것을 읽고 난 후, 나는 정확히 어떤 변수들이 있는지, 얼마나 그것이 이 제안에 적용될 수 있는지 확신할 수 없다.지금은 관리자들에게 더 적합해 보이고, 그들이 볼 수 있는, 그리고 어느 정도까지 삭제된 정보를 볼 수 있다.계층화된 삭제 시스템은 흥미롭게 들리지만, 내가 진정한 의견을 제시하기 위해서는 세부 사항들이 크게 확대되어야 한다.이 모든 것을 읽고 나서 내가 가진 질문은 지금 어떤 제안이 진전되고 있는가 하는 것이다.왜냐하면 이 페이지에 던져진 아이디어들이 많지만, 제안서의 세부사항에 집중하기 위해서는 어느 정도 방향성이 있어야 하기 때문이다.나이트라고 (토크) 23:52, 2008년 7월 7일 (UTC)[응답]

제안:설정된/경험이 있는 사용자 그룹과 계층화된 삭제

이 코너가 좀 복잡해져서 내가 제안하는 아이디어를 요약해 볼까 생각했어.

• 자동 확인과 관리자 사이의 새로운 사용자 그룹을 생성하고 롤백과 같은 권한과 현재 관리자 전용인 다른 "위험성이 적은" 권한(나중에 결정)을 부여한다.이 그룹은 현재 롤백 그룹을 대체할 수 있다.
• 계층화된 삭제 시스템은 다음과 같은 범주로 구현된다.

• 과시 편집(과시만 해당)
• Copyvio, BLP, 공격 등(Admins 이상만 해당)
• 기타, 비통보 등 기사(설치/경험자 이상만 해당)

• 기사가 삭제되면 관리자는 삭제된 페이지가 속한 카테고리를 선택한다.대부분의 사용자들에게 그 결과는 현재의 시스템과 동일할 것이다.그러나 가장 낮은 계층(알림 등)은 확립된/경험이 있는 사용자에게 보일 것이다.

나는 이 사용자들이 가장 낮은 단계의 기사를 접할 수 있고, 그 사용자들이 어떤 지적 문제를 해결하기 위해 기사를 개선할 수 있다면 그렇게 큰 문제가 될 것이라고 생각하지 않는다. -- 임페라이터3733 (대화) 20:34, 2008년 7월 14일 (UTC)[응답]

별보기

현재 여러 별과 관련된 기호의 다양한 사용과 관련하여 약간의 혼란이 있다.

예를 들면 다음과 같다.

• 별 4개가 별 4등급으로 리디렉션됨
• 네 개의 별이 스타로 방향을 바꾸는데, 내가 간단한 섹션을 추가하기 전까지는 해트노트로도 군계열을 전혀 언급하지 않았다.
• 포스타는 적어도 혼란스러운 페이지를 가리키는 해트노트가 있는 포스타 레코드로 리디렉션한다.

'포스타' 페이지에는 4성 관련 기사가 일부 나열되어 있으며, 4성 관련 기사 및 기타 별 수 관련 기사 목록이 더 많이 수록된 섹션도 있다.두 명 모두 불완전하며, 두 번째 명단은 아마도 부적절할 것이다.여기에 다른 수의 별들이 있다는 것은 나에게 더 일반적인 문제를 나타낸다.

쓰리 스타는 쓰리 스타 클럽으로 방향을 바꾸고, 다시 목표물에는 해트노트가 없고, 세 별에 대한 혼란은 없어 보인다.

파이브 스타(동음이의)는 포스타 디스패치와 구조가 비슷하다.

이 일을 정리하기 전에, 나는 토론을 초대할 것이다.우리는 심지어 가이드라인을 작성하게 될지도 모르지만, 우리가 무엇을 해야 하는지에 대한 어떤 합의점을 먼저 생각해 봅시다.

아니면, 내가 간과하고 있는 관련 지침이 이미 있는가?

문제:

• 혼란스러운 페이지 이름의 자본화...4성(동음이의)이 되어야 하지 않을까?
• 설명 페이지를 완료해야 함...그 숫자들은 얼마나 더 올라가야 하는가?
• 해트노트 누락
• 리디렉션...개별 기사보다는 혼란스러운 페이지로 가야 하며, 명확한 주요 사용법이 될 것 같지 않다.
• 다른 수의 별에 대한 항법에 대한 설명 페이지의 섹션(템플릿일 수 있음)도 참조하십시오.
• 다른 사람들은...?

당연히 댓글이 달렸지.또한 적절한 시기에 청소를 돕는다.위의 기존 관행에 대한 조사는 철저하지 않지만, 이 단계에서 다른 의견을 구해야 한다고 생각했을 정도로 충분하다.안드레와 (대화) 2008년 7월 10일 17:39 (UTC)[응답]

세 개의 별이 존재한다.

위키피디아 토크에서 더 나은 답을 얻을 수 있을 것이다.설명 또는 위키백과 대화:Manual of Style(해제 페이지)둘 다 상당히 활동적이다. :) -- Quidity (대화) 18:41, 2008년 7월 11일 (UTC)[응답]

"Four star"를 불분명한 페이지로 만들고 다른 페이지들을 그것으로 리디렉션하라.그랜드마스터카 02:46, 2008년 7월 13일 (UTC)[응답]

지금까지 코멘트 고마워...토크에서 계속 진행:스타(분류)/아카이브/2013#관련 기사 및 리디렉션안드레와 (대화) 2008년 7월 14일 19:23 (UTC)[답글]

특수에 링크 추가:새로운 페이지 - 위키백과 사이드바

안녕, 스페셜에 링크를 추가해야 할 것 같아위키백과 사이드바의 상호 작용 섹션에 있는 새로운 페이지들은 그 페이지들의 순찰을 증가시키고 그렇게 하는 것을 더 쉽게 만들 것이다.다들 어떻게 생각해? - 2008년 7월 11일 23시 9분에 선드래곤34(토크)가 추가한 서명되지 않은 댓글에 앞서

좋은 생각이 될 것 같아.사실, 생각해보니, 그 버튼들이 메뉴판일 수도 있지 않을까?예를 들어, 최근 변경사항 옆의 더하기 기호를 클릭하면 새 페이지, 새 페이지 기여, 사용자 작성 로그 등이 있는 메뉴가 드롭다운된다.TN-X-Man 19:16, 2008년 7월 13일 (UTC)[응답]

드롭다운 메뉴 아이디어가 좋을 것 같아.그러한 변화를 만드는 것은 아마도 그들의 사용을 증가시킬 것이다. -- 임페라이터3733 (대화) 18:55, 2008년 7월 14일 (UTC)[응답]

어제 IRC에서 누군가와 얘기 중이었는데, 이미 제안된 줄 몰랐어!나도 얼마 전에 NP패트롤을 시작했으니까 좋은 생각인 것 같아.현재 새로운 페이지 순시대는 720시간의 시간이 끝날 때 여전히 등록되지 않은 페이지가 있을 정도로 백업되어 있다.패트롤러에게 쉽게 다가갈 수 있는 것은 정말 큰 도움이 될 것이다. 그리고 드롭다운 [+]은 아주 좋은 생각이다!나는 저 alot %%-SYKKO-% (말씀) 19:19, 2008년 7월 14일 (UTC)[응답]을 좋아한다.

나도 동의해, 그 링크 하나를 사이드바에 추가하면 아주 유용할 거야, 아마도 "상호작용" 섹션에 있을 거야.드롭다운 메뉴도 추가될 수 있을 것 같아.아티초커^[talk] 02:10, 2008년 7월 15일 (UTC)[응답]

세기별 성

우리는 위키피디아를 여러 용도로 사용하지만, 대부분 다양한 가족을 위한 우리의 족보 연구를 위해 사용한다.우리 시간의 많은 부분은 특정 세기에 지어진 것을 알아내기 위해 유럽의 여러 성들을 살펴보는 데 소비된다.만약 위키피디아가 그들이 지어진 세기까지 다양한 성을 나열하는 페이지를 만든다면, 그것은 우리와 다른 연구원들에게 매우 도움이 될 것이다.

예를 들어, 바로 요전 날, 우리는 11세기의 덴마크 성을 찾고 있었다. 하지만 불행하게도, 위키피디아에서 그 성을 찾을 수 없었다.그것은 우리를 몇 시간, 며칠, 몇 주, 심지어 때때로 몇 달 동안 검색하는 것을 절약할 뿐만 아니라, 다른 많은 사람들/그룹들의 다양한 형태의 연구를 도울 것이다.

우리는 이 문제에 대해 위키피디아에 편지를 썼고, 필 샌디퍼로부터 제안/제안을 하기 위해 이 양식을 사용하자는 회신을 받았다.우리는 진심으로 당신이 우리의 제안을 고려할 것이다.시간 내 주셔서 감사합니다

범주:11세기 시설과 범주: 범주의 범주 교차로를 사용하여 질의에 대한 답변을 얻을 수 있다.덴마크의 성.카테고리 교차로들은 위키피디아 내에서 직접적으로 수행될 수 없지만, 그것들을 수행할 수 있는 외부 도구가 있다.

이 질문은 콜딩후스가 당신의 기준에 맞는 유일한 성이라는 것을 말해준다; 물론, 우리가 아직 기사를 쓰지 않은 성이나 적절한 범주에 추가되지 않은 기사가 있을 가능성이 매우 높다.

나 자신의 이익을 위해 다른 세기를 시도했고, 카테고리:12세기 건축물을 카테고리:12세기 건축보다 내 시대 카테고리로 사용하여 더 많은 결과를 얻었다.직접 카테고리에 기사를 추가하면 도움이 된다.-gadfium 19:41, 2008년 7월 13일 (UTC)[응답]

이 검색은 위키피디아에서 실제로 수행될 수 있다.그저 '인카테고리:'11세기 시설''인카테고리:'덴마크의 캐슬''을 검색해 보십시오.대수학자 17:18, 2008년 7월 14일 (UTC)[응답]

위키백과:권한 요청

Rjd0060이 나와 이 아이디어를 논의한 후, 나는 대담하게 여기서 모든 관리자 권한 요청을 처리할 수 있는 새로운 제안 "권한 요청 페이지"를 만들었다.그것은 기본적으로 모든 것을 한 페이지에 정리할 것이다.이 페이지는 롤백, IPblockexempt 및 계정 생성 플래그를 처리한다.그것은 현재 RfR 페이지를 기반으로 하며, 사용자가 기여/로그를 통해 한 번 찍은 후에 모든 관리자가 권한을 부여할 수 있다.위키피디아 토크에서 너의 생각을 알려줘:권한 요청.Ryan Postlethwaite 23:21, 2008년 7월 14일 (UTC)[응답]

RE: 통합 로그인과 함께 사용할 범용 탐색 모음

(구 토의)

User:에서 대충 이런 식으로 해킹을 해봤다.작은 플라스틱 그레이 나이트/스크립트/설드롭다운.js.스크립트를 가져오고 메뉴를 사용자 지정하는 방법에 대한 예는 monobook.js를 참조하십시오.아직 벌레가 몇 마리 있지만 위험한 것은 없다.메뉴가 나타나길 원하는 각 프로젝트에 그런 수입명세서를 추가해야 하는데, 그것은 당신을 따라다니지 않을 것이다.

지금까지 가장 짜증나는 버그: 인터넷 착취기에서, 목록에는 여전히 총탄 자국이 있고 첫 번째 프로젝트는 선택할 수 없다.메뉴는 메인 페이지 블록 뒤로 점프하는 것 같다.#content내가 설정하지 않는 한 )#content의 z-index를 0으로 설정하고 메뉴의 z-index를 0으로 설정하면 아무 효과도 없는 것 같다.

의견과 버그픽스는 환영! --_{tiny plastic} 그레이 나이트 ⊖ 08:27, 2008년 7월 10일 (UTC)[응답]

아, 아마 더 예쁘게 만들 수도 있을 것 같은데, 그걸 버그픽스로 세어보자. --_{tiny plastic} 그레이 나이트 ⊖ 12:40, 2008년 7월 10일 (UTC)[응답]

네아토! 나 많이 좋아해!!!!!!!!!!!당신이 선택한 화살 그라픽스는 매우 보완적이다.행 링크 사이에 간격을 더하고, 당신이 맴돌 때 각각의 빛이 배경색으로 켜지도록 할 수 있다고 생각하십니까? .:다부마야:2008년 7월 15일 16:04 (UTC)[응답하라]

사이드바 변경

사이드바 언제 바뀌었어?나는 검색 상자가 올라가는 것을 별로 개의치 않지만, 그것의 새 이름은 끔찍해.찾기는 그것에 적합한 용어가 아니다.enwiki의 모든 것에 영향을 미치는 것을 바꾸기 전에 정말로 더 많은 공동체 입력이 필요하다.레이와스92^Talk 18:57, 2008년 7월 12일 (UTC)[응답]

헤더 변경에 대한 커뮤니티의 반응을 측정하려고 한다(MonoBook 사용자들이 이미 박스의 새로운 위치에 적응해야 한다는 점을 감안할 때, 가장 파괴력이 적은 시점).15시간 이상 전에 편집한 후 두 번째로 본 비평이네.

이것은 (다른 사이드바 재설계와 함께) 꽤 오래 전에 논의되었다.그 편집자 그룹 내에서의 의견 일치가 불분명했기 때문에 더 광범위한 투입이 필요하다.

그 근거에 대해서는, 「Go」와 「Search」가 「Search」의 표제(그리고 자동 완성 기능의 추가는 이것을 그 어느 때보다도 사실적으로 한다)에 해당한다는 것은 도저히 납득이 가지 않는다.둘 다 기사를 찾는 방법이기 때문에, 나는 '찾아가는' 라벨(이미 쾰른 블루 피부에 사용되었으므로 완전히 새로운 것은 아니다)이 가장 논리적인 선택이라고 강하게 느낀다.—데이비드 레비 19:59, 2008년 7월 12일 (UTC)[응답]

이 논의는 아마도 미디어위키 토크로 옮겨져야 할 것이다.사이드바.하지만 '찾아가는 것'이 훨씬 더 적절하다고 생각한다고 말할 것이다. --MZMcBride (대화) 20:01, 2008년 7월 12일 (UTC)[응답]

나머지는 명사('find' 등)이지만, 'find'는 동사. 약간 어울리지 않아 보이지만 바꿀 가치가 없다.90:11 20:10, 2008년 7월 12일 (UTC)[응답]

"검색"과 "찾기"는 모두 명사나 동사의 역할을 할 수 있고, 나는 이 경우 표제가 동사로 이해된다는 것에 동의한다.우리는 "navigate"와 "interaction"이라는 제목을 사용하려고 했지만, "navigation"의 대체는 분명히 몇몇 사용자들의 사용자 지정 스크립트를 깨뜨렸다.—데이비드 레비 20:23, 2008년 7월 12일 (UTC)[응답]

일반적인 웹 브라우저 용어로 "검색" = "이 입력과 일치하는 페이지 찾기" 및 "찾기" = "현재 페이지에서 이 입력 검색"으로 더 좋거나 더 나쁠 수 있다.주차장에 주차해서 진입로에 주차하면 마일리지가 달라질 수 있어.— CharlotteWebb 13:22, 2008년 7월 14일 (UTC)[응답]

일반적으로 검색은 과정의 시작이며, 찾기는 끝이다. 즉, "X를 검색해 Y를 찾았다"는 것이다.여기서 찾는 것이 더 정확한 제목일 수 있다. -Steve Sanbeg (대화) 22:35, 2008년 7월 14일 (UTC)[응답]

참고: 이 상자의 제목은 다시 "검색"입니다. -- 존 브로튼 (바깥쪽) 14:06, 2008년 7월 15일 (UTC)[응답]

나는 동의하지 않는다.나에게 "Locate"는 더 강하게 성공을 암시한다(또는 적어도 찾는 항목이 실제로 존재하는 것으로 알려져 있다).— CharlotteWebb 14:37, 2008년 7월 15일 (UTC)[응답]

목차마진

사용자 대화에서 간략한 설명에 따라:에드 피츠제럴드#스페이스? 사람들은 이것에 대해 어떻게 생각할까?:

#toc { margin-top: 10˚; }

—Wknight94 (대화) 18:24, 2008년 7월 15일 (UTC)[응답]

나는 그것이 간격이 좋고 간결하고 간결하며 매우 훌륭한 CSS 진술이라고 생각한다.만약 당신이 위키피디아의 글로벌 CSS 파일에 추가되었을 때 그 진술이 무엇을 할 것인지에 대한 의견을 원한다면, 당신은 아마도 몇 가지 세부사항과 몇 가지 예를 게시해야 할 것이다.Anomie⚔ 21:43, 2008년 7월 15일 (UTC)[응답]

내 말은 사람들이 목차 위에 공간을 추가하는 것에 대해 어떻게 생각하느냐는 것이었다.내가 언급한 토크 페이지의 남자는 공간을 추가하는 것에 대해 너무 격렬해서 여러 기사의 첫 단락 끝에 빈 줄과 코멘트를 삽입하고 있었다!—Wknight94 (토크) 22:32, 2008년 7월 15일 (UTC)[응답]

10px 대신 일부 상대 단위(예: 3% 또는 1.5em)를 사용하는 것이 좋을 수 있다. -- 타쿠(토크) 23:32, 2008년 7월 15일 (UTC)[응답]

기본 주제 목록을 함께 보관하기 위한 제안.누군가 그 중 한 명의 이름을 바꿔서 더 이상 세트와 맞지 않게 되었답니다!

기본 오페라 주제 목록 유지 관리자들은 그 목록의 이름을 오페라 주제 목록으로 바꾸었다.그 페이지는 다른 기본 주제 목록과 동일한 범위와 표준 형식을 가지고 있다.그리고 그것이 옮겨진 주제들의 목록이라고 불리는 페이지들의 집합은 포괄적이다.그 페이지는 분명히 지금 잘못된 페이지 세트의 회원이다.

나는 기본 주제 목록을 함께 보관하고, 그들이 속한 세트의 표준 이름을 유지할 것을 제안한다.이름을 바꾸려면 위 절의 제안에서와 같이 세트로 함께 이름을 바꾸어야 한다.

만약 각각의 토크 페이지에서 지역적인 합의에 의해 페이지 이름을 바꿀 수 있다면, 위 섹션의 토론은 큰 차이가 없을 것이다. 왜냐하면 그 페이지들 중 어떤 페이지라도 변덕스럽게 언제든지 이름을 바꿀 수 있기 때문이다.페이지를 세트 밖으로 옮길 때마다 세트 커버리지에 구멍이 생기거나, 적어도 이름이 바뀐 페이지의 목적과 범위가 무엇인지에 대한 혼란을 야기할 수 있는 잠재력이 있다.

오페라 주제 목록은 기본 오페라 주제 목록으로 다시 이름을 바꾸어야 한다. 이는 그것이 그것의 일부가 되도록 설계된 세트에 현재 사용 중인 명명 규칙과 일치하기 때문이다.그리고 앞의 절에서 논의한 결과 세트의 새로운 명칭이 결정되면, 그 오페라 컴포넌트에도 적용되어야 한다.트랜스휴머니스트 19:22, 2008년 7월 4일 (UTC)[응답]

• 지원 - 제안자로서.트랜스휴머니스트 19:25, 2008년 7월 4일 (UTC)[응답]
  • 위의 논의가 오페라적 맥락에서 이치에 맞지 않는다면(이러는지 모르면) 무시해야 한다.일관성은 이치에 맞는 것만큼 중요하지 않다.쿠스마 (토크) 06:02, 2008년 7월 5일 (UTC)[응답]

• 본 기사의 편집 이력을 살펴보면, 편집자의 POV 결정을 요구하는 '기본'과 '아웃라인'이라는 단어에 대한 반대가 있었던 것으로 보인다.이 이의는 여전히 적용되며 이전 섹션에도 적용될 수 있는가?흐메인 (대화) 22:52, 2008년 7월 5일 (UTC)[응답]

• 이의는 철회한다. (하지만 이 제안은 아니다.):) 트랜스휴머니스트 05:39, 2008년 7월 6일 (UTC)[응답]

• Hmains에 반대한다: 목록 기사의 제목에서 "기본"이라는 단어는 문제가 있다(PoV이기 때문에). "알림 가능"과 "촉진"과 같은 단어와 같다.(주: 편집 요약에 근거하여 사용자:Nrswanson은 "기본"과 같은 PoV 문제를 가지고 있는 것으로 보인다.UnitedStatesian (대화) 19:50, 2008년 7월 11일 (UTC)[응답하라]
  • 아마도 "핵심" 또는 "근본적"과 같은 대체 단어가 대부분의 대학(또는 그 이전) 입문 강좌에서 가르친다는 의미에서?그것은 적어도 출판된 교과서를 통해 검증될 수 있을 것이다.—RJH (대화) 16:24, 2008년 7월 16일 (UTC)[응답]

위키피디아는 적절한 이름일까?

메인 페이지 재설계 제안서가 깔끔하면서도 더 예쁜 외관을 주는 좋은 아이디어지만, 나는 또 다른 고민이 있다.

내 말은, 위키피디아의 국제/다국어 목표를 고려할 때, 위키피디아는 다른 언어로 발음하기 어려운 단어일 수도 있다.우리 영어권 사람들에게는 꽤 쉽고 친숙하지만, 나는 다른 사람들이 이 음절에 우연히 부딪힐까 봐 두려워.간단한 영어 위키피디아에 대해 생각해봐. Marlith (Talk) 00:08, 2008년 7월 8일 (UTC)[응답]

위키피디아가 가지고 있는 거대한 '브랜드'로, 나는 솔직히 당신이 이름을 바꾸는데 거의 성공하는 것을 볼 수 없다._Talk아일랜드인 00:11, 2008년 7월 8일 (UTC)[응답]

동의해, 게다가 위키피디아는 동등한 번역으로 다른 언어로 채택되었으니, 그것은 그들만의 개별 청중이 있는 수십 개의 이름을 바꾸자는 제안이 될 거야.WP-in-other-anguage는 영어 WP에 대한 절충점이라고 생각한다.영어 제품을 국제화하기에는 너무 어려우니 번역으로 생존력을 높이면 어떨까.이 제안이 더 장점이 있다고 느낀다면 위키미디아에 발표하는 것이 현명할 것 같아. .:davumaya:. 15:35, 2008년 7월 11일 (UTC)[응답]

응, 그냥 쪽지 하나.큰 거 없어...

우선 나는 그것이 적절한 이름이라고 생각하지만(그리고 당신은 지금 그것을 바꿀 수 없을 것이다) 영어에서도 그것이 어떻게 발음되어야 하는지에 대한 논쟁이 있다는 것을 알아야 한다고 생각한다.위키백과 참조(단어학)#발언(그 중 일부는 하와이어 위키 발음 문제를 중심으로 전개) 여기 이 문제에 대한 외부 토론의 연결고리가 있다:[3] Rmhermen (대화) 00:29, 2008년 7월 8일 (UTC)[응답]

a) 이름은 그냥 괜찮고, 알아볼 수 있고, 사람들은 우리가 백과사전이라는 것을 금방 알게 되고, b) 지금 바꾸기에는 너무 늦었다. 15:39, 2008년 7월 11일 (UTC)[응답]

a) 사실, 나는 원래의 포스터에 동의한다. 나는 항상 그 이름이 이상하고, 오해의 소지가 있으며, 그리고 터치 오프 푸팅이라고 생각해왔다.난 항상 그렇게 생각했어바꾸기엔 너무 늦었나?그래, 아마도 (하지만 아래를 봐.하지만 만약 그 이름이 "위페디아"나 "우르페디아" 또는 "넷페디아"라면, 예를 들어, 얼마나 더 멋질까?내가 틀렸다면 고쳐줘. 하지만 나는 항상 위키라는 단어가 좀 이상한 신세대 컬트 반종교와 관련이 있다고 생각해왔고, 이 공공 백과사전이 왜 이 공공 인터넷 백과사전을 사용했는지는 세상에 결코 알 수 없었다. 물론 이 공공 인터넷 백과사전이 위키실습자들에 의해 실제로 시작된 것이 아니라면 말이다.그리고, 더 생각해보면, 이름 바꾸기는 엄청난 홍보와 함께 환상적인 홍보 행사가 될 것이다.에소, 엔코, 그리고... 음, 다른 하나가 뭐였든 간에...그들의 이름을 엑슨으로 바꾸었다.기술적 어려움은 아무것도 아니다; 위키라는 이름의 소유권을 유지하는 것, 단순히 "우리피디아" 홈 페이지로 리디렉션하는 것, 그리고 나는 구글이 "우리피디아"에 관련된 모든 것을 포함하도록 위키를 포함하는 검색을 리디렉션하는 방법을 알아낼 수 있을 만큼 충분히 똑똑하다는 것에 의심의 여지가 없다.이것은 또한 Linquist들에게 흥미로운 도전을 제기한다; 세상에서 가장 보편적인 단어의 의미는 무엇인가?개인적으로는 (만약 그 단어가 '위키'로 밝혀지면 얼마나 웃을까)라는 것이 무엇인지 전혀 짐작하지 못하지만, 한 번 살펴볼 만하다.

그렇다, 그것은 새로운 시대의 컬트 문화인 반종교와 관련이 있다.인터넷.위키피디아의 이름 때문에 위키피디아를 비난하는 사람은 들어본 적이 없다.다른 일 때문에 그럴 수도 있지만, 그 이름 때문에 그런 건 아니야.그 이름도 일단 그 이유를 알게 되면 논리적으로 타당성이 있다."웨페디아?"우르페디아?이상하게 들리네'우리들'이 아니라 '모두들'이겠지, 그럼 '모두들'이겠지?아니, 하지만 누구나 편집할 수 있다는 전제하에, 모든 사람들이 그들의 키보드로 달려들면, 당신은 "스탬피디아"라는 모든 것을 할 수 있다.야구벅스^{What's up, Doc?} 01:58, 2008년 7월 14일 (UTC)[응답]

위키백과의 아이디어는 몇 년 전에 위키백과보다 앞서 있다.미스터Z맨 02:06, 2008년 7월 14일 (UTC)[응답]

바로 그거야게다가 위키미디어 재단은 어떠한가?이름 변경은 절대 절대 일어나지 않을 것이다.스탬피디아에 대한 생각은 마음에 드는데...;)

위키피디아는 등록상표로서, 일부 사람들에 의해 적어도 70억 달러의 가치가 있는 것으로 평가되고 있기 때문에, 그렇게 될 가능성은 거의 없다.Titoxd^{(?!? - cool stuff)} 18:08, 2008년 7월 16일 (UTC)[응답]

하위 카테고리 정렬

현재 하위 카테고리는 일반 기사처럼 알파벳 순으로 정렬되어 있다.이렇게 하면 하위 고양이를 추가하는 사람이 교묘하게 특수 텍스트를 사용하지 않는 한, 모든 하위 범주를 찾기 위해 전체 범주를 살펴볼 필요가 생긴다.나는 하위 범주를 범주 내의 기사 앞에 알파벳 순으로 배치하고, 항상 모든 하위 범주를 범주의 시작 부분에 배치할 것을 제안한다.내가 예상할 수 있는 유일한 바람직하지 않은 효과는 그 수가 500개 이상에 도달하면 하위 범주가 자체 TOC를 요구한다는 것이다. 그러나 대부분의 범주에는 거의 이 많은 하위 범주가 포함되어 있지 않기 때문에 이것은 좀처럼 나타나지 않을 것이다.생각?조니미르닌자 09:49, 2008년 7월 9일 (UTC)[응답]

하위 카테고리는 카테고리의 기사 앞에 배치된다. 예를 들어 카테고리:직업별 파키스탄 사람.지금 말씀하시는 것은 한 카테고리에 200여개의 기사가 있을 때 여러 페이지에 걸쳐서 나오고 하위 카테고리는 기사의 알파벳 범위를 따른다는 겁니다.예를 들어 범주:경제학자들은 6개의 하위 범주가 있는데, 첫 페이지에 3개, 두 번째 페이지에 1개, 세 번째 페이지에 1개, 그리고 네 번째에 1개가 있다.첫 페이지에 6개의 하위 카테고리가 모두 나온다면 확실히 더 좋을 것이다. -- 존 브로턴(식별) 02:19, 2008년 7월 10일 (UTC)[응답]

나도 동의해, 다만...만약 200개의 하위 카테고리가 있다면? : - jc37 02:26, 2008년 7월 10일 (UTC)[응답]

그렇다면 이러한 하위 캐트는 좀 더 일반적인 하위 캐럿에 배치되어야 할 것이다.Wrad (대화) 02:28, 2008년 7월 10일 (UTC)[응답]

그것들은 자동으로 있는 것이 아니다.그것은 그 뒤의 공간과의 파이핑 링크와 같은 것을 요구한다. [4]를 참조하라.화면 맨 위에 배치되어 있는데, 그게 네가 말하는 거라면, 내가 말하는 건 그게 아니야.그것들은 여전히 상부에 진열된 일반 기사와 함께 알파벳으로 표기되어 있다.범주:사용자 에세이에 카테고리 포함:위키프로젝트 U.S. Roads 에세이, 하지만 자동으로 배치되는 W 섹션에 도달할 때까지 다음 200을 클릭해야 한다.아마 많은 사람들이 그곳에서 그것을 결코 보지 못할 것이다.조니미르닌자 02:50, 2008년 7월 10일 (UTC)[응답]

미안해, 내가 답장하기 전에 너의 답변을 완전히 처리하지 못했어.그래서 이게 좋은 생각인 것 같니?버질라에게 가져가야 할까?(이러한 것들이 어디로 가는 거지?)조니미르닌자 02:53, 2008년 7월 10일 (UTC)[응답]

나는 그 아이디어가 마음에 든다.네임스페이스에 관계 없이 각 페이지에 알파벳의 특정 섹션을 가져오기 위해 현재 단일 SQL 조회가 이루어지기 때문에 구현이 다소 어려울 수 있다.먼저 네임스페이스로 결과를 주문하는 것이 쉽겠지만, 그렇다면 다음 페이지를 어디서 시작할 것인가를 결정하는 논리는 좀 더 복잡하고(그래서 코드가 좀 더 추할 것이다), 사람들이 데이터베이스에서 페이지를 검색하고자 하는 순서를 바꿔서 SQL 성능에 영향이 있을지는 잘 모르겠다.잭슈미트 (대화) 03:23, 2008년 7월 10일 (UTC)[응답]

나는 SQL에 대해 정말 아무것도 모르니까, 이 말이 바보같이 들리더라도 용서해 줘, 하지만 카테고리 이름 처리 방식에 대한 코딩은 효과적으로 두 개의 연속 알파벳, 카테고리 1에 이어 일반 알파벳을 만들면서 변경되지 않았을까?그것들은 정상적으로 표시되지만 알파벳 순으로 표시된다.일반적으로 이러한 페이지는 알파벳으로 구분되는 유일한 장소인 만큼 다른 페이지에는 큰 영향을 미치지 않는다(이것은 심지어 약간 말이 되는가).이렇게 하면 일이 간단해질 것이다조니미르닌자 03:41, 2008년 7월 10일 (UTC)[응답]

분명히 하자면, 기술적 세부사항은 개발자(또는 WP:VP/T)를 어떻게 표현해야 할지 조언을 얻고 싶다면, 그리고 나는 단지 개발자가 바쁘고 이것은 코드에 대한 비합리적 원라인 변경이 아니기 때문에 기능이 구현되지 않았더라도 놀라지 말라는 것이다.이 페이지는 제안이 좋은지 여부를 결정하는 데 초점을 맞춰야 한다(실제 실현 가능한지는 포함하지만, 쉬운지는 포함하지 않는다).나는 이것이 좋은 제안이고, 개발자들이 그것을 좋아하는지 볼 가치가 있다고 생각한다.

해결책에 대한 당신의 설명은 기본적으로 옳다; 페이지 이름만 알파벳 순으로 사용하는 대신, 네임스페이스(아래쪽)를 사용하고 페이지 이름을 입력하여 각 네임스페이스에 대한 알파벳을 효과적으로 만든다.문제는 엄청나게 많은 것들이 페이지를 알파벳순으로 되돌려 놓아야 한다는 것이고, 그래서 그들은 색인이 필요하다는 것이다.이 새로운 정렬 방법에도 인덱스가 필요한 경우 추가해야 하는 큰 문제가 발생하거나 인덱스를 얻지 못하는 경우, 갑자기 아무도 Category를 검색할 수 없음:더 이상 살아 있는 사람들.내가 신경질적인 사람일 수도 있고, 어떤 dev도 SQL에 문제가 있다고 생각하지 않을 수도 있다. 그러면 그것은 기본적으로 한 줄의 사소한 변화다.잭슈미트 (대화) 04:00, 2008년 7월 10일 (UTC)[응답]

그럼 어떻게 알아낼까?조니미르닌자 04:36, 2008년 7월 10일 (UTC)[응답]

(후회) WP의 토크 페이지에서 토론을 시작할 것을 제안한다.CAT, 그리고 아마도 WP의 토크 페이지에 상호 참조 게시:SUBCAT, 이를 위한 일반적인 지원이 있는지 확인.좋은 생각인 것 같아.(편집자들이 정기적으로 기사를 하위 범주로 옮기는 아주 소수의 상위 범주에 대해 내가 볼 수 있는 단점은, 내가 추측하기에 200개 이상의 하위 범주가 있다면, 그 범주의 첫 페이지에는 문제가 있는 사례가 나타나지 않을 것이다.) - 존 브로튼 (기타) 13:18, 2008년 7월 10일 (UTC)[응답]

예, 고려해야 할 문제 범주의 한 예는 다음과 같다.아티스트별 앨범 "이 카테고리는 총 9,559개 중 다음과 같은 200개의 하위 카테고리가 있다."개인적으로, 나는 api.php가 당신이 보고 싶은 네임스페이스를 선택할 수 있도록 하는 방법이 마음에 들어, 당신은 카테고리 내 모든 카테고리(하위 카테고리), 그것의 모든 토크 페이지, 그것의 모든 사용자 페이지 등을 각각의 리포트에서 찾을 수 있다.카테고리를 제한할 수 있는 기능을 추가하는 것이 더 쉬울 수 있다.*just* 하위 카테고리 또는 *just* 페이지(기본값은 현재와 같음, 둘 다 함께 정렬됨)에 표시되는 모든 항목내 생각에 그것은 한 줄의 변화일 것 같다.잭슈미트 (대화) 2008년 7월 10일 (UTC) 13:49 [응답]

조니의 원래 제안에 내 지지만 보태면 돼.페이지당 200장 한도도 올릴 수 있을 것 같아 (500장이 문제될까?) --코트니스키 (토크) 08:21, 2008년 7월 16일 (UTC)[응답]

내 지지도 더하고.어떤 기사를 나열하기 전에 모든 하위 카탈로그를 나열하는 것이 나에게 큰 도움이 될 것이다.대부분의 카테고리는 하위 카테고리가 200개 미만이고 매우 적은 카테고리로 별도의 목차가 실제 도움이 될 수 있기 때문에 목차는 기사에만 연결될 수 있다.항목의 페이지 수가 증가할수록 목차 인덱싱이 더욱 중요해진다.Dbiel 22:38, 2008년 7월 16일 (UTC)[응답]

아마도 범주는 역사 등과 마찬가지로 200 (또는 500) 디폴트 옵션도 가질 수 있을 것이다.9000개 이상의 하위 카테고리를 갖는 것은 흔한 것과는 거리가 멀기 때문에, 그것은 행복한 타협으로 보일 것이다.조니미르닌자 04:39, 2008년 7월 17일 (UTC)[응답]

미국 도시 인구 업데이트 봇

나는 내 봇에 기능성을 추가해 달라는 요청을 제출했고, 특히 업데이트된 공식 인구 조사 수치(WP에 의해 사용되어야 하는 수치:USCITY).BAG에 있는 사람들은 잠재적인 범위(미국에는 약 19,500개의 법인화된 곳이 있음)를 감안할 때 지역사회의 더 많은 의견이 필요하다고 제안했고, 그래서 나는 이 문제에 대해 여기서 주의를 기울이려고 한다.

봇의 실제 기능은 간단할 것이다.infobox의 "population_total" 필드는 현재의 인구조사 수치와 일치하도록 업데이트되고, "population_footnotes" 섹션은 새로운 소스를 반영하도록 업데이트될 것이다.그 분야의 기존 출처는 기사의 다른 곳에서 사용되는 경우에 유지될 것이다.기사의 본체는 봇에 의해 변형되지 않을 것이다.

이 봇은 미국 인구조사국이 연간 추정치를 발표하는 유일한 곳이기 때문에 미국 내 편입된 장소에 대한 기사에만 영향을 미칠 것이다.비법인 공동체는 이 일의 범위에 속하지 않을 것이다.BAG 사람들이 엿볼 수 있도록 내가 이 토론과 연결시켜 놓을게.만약 당신이 관심이 있다면 여기서 자유롭게 논평을 하시오.감사합니다, 2008년 7월 15일(UTC) 15시 26분 (답장)

WP 이후:USCITY는 "미국 인구 조사 번호만"을 사용하라고 말하는데, 나는 당신의 미국 인구 조사 추정치 전환이 논란이 될 수 있다고 생각한다.우리는 디트로이트에서 이미 이것을 본 적이 있는데, 디트로이트에서는 그 도시의 공식 항의가 있은 후 5만 (약 90만 정도밖에 되지 않는 도시에서)[5]가 인상되었다.Rmhermen (대화) 2008년 7월 15일 15:54 (UTC)[응답]

아마도, 비록 누가 2000년 수치가 2007년 추정치보다 오늘날 더 정확하고 적절하다고 주장할지 의심스럽지만.현재 많은 기사에서 미국 인구 조사 이외의 여러 해의 추정치와 출처가 나와 있는데, 나는 어느 정도 일관성을 목표로 하고 있다.Sherth 16:36, 2008년 7월 15일 (UTC)[응답]

나는 이 생각이 괜찮은 것 같다.편집이 많겠지만 정확한 정보를 확보하는 것이 중요하다. -- 임페라이터3733 (대화) 15:50, 2008년 7월 15일 (UTC)[응답]

위와 같은 정확한 정보가 아닌 추정치라는 요점을 놓친 것 같다.제안이 다음과 같은 분야라고 가정해 보십시오(WP에서 확인:USCITY:

그리고 두 번째 파라미터와 '테이블'(테이블) 출력 형식을 사용하여 두 수치가 나란히 나타나도록 '스플'을 테스트하기 위해 수정된 논리(registics, iff 정의됨).

모집단 총계의 출력 라인에 대한 예시로서 다음 중 하나:

{{#if: est-population_total (est: boo<ref name="Latest estimates"/>}}... ''however that field ends now.'' 나는 "(최신 추정치>를 사용하여 모집단 출력 라인에 대해 동일한 종류의 if-logic을 가정한다.여기 참조>)" 등

주변에 300~400명이 있을거야. 그런 식으로 템플릿을 바꿀 수 있는...모두의 코끝을 "조인트"로 유지하도록 해

이 접근방식은 아무것도 깨뜨리지 않으며, 공식적인 통계(예: '공식 조사')를 변경하지 않으며, 추정치와 마지막 공식 인구 조사 결과의 구분을 유지하면서 구 통계치를 숨기지 않는다.수작업으로 20-30페이지까지 변경한 {{Tt#} 템플릿 중 하나에서 수정된 템플릿으로 약간 테스트하면 새 템플릿을 입증한 다음 봇이 이전 템플릿을 변경하는 필드를 추가할 수 있는지 확인할 수 있다. // FrankB 19:10, 2008년 7월 16일(UTC)[응답]

나는 이 아이디어가 정말 마음에 들어.사실, 인포박스에 새로운 선을 추가하는 것에 대해 아무도 당황하지 않는 한, 나는 차라리 이런 식으로 하는 것을 선호한다.발놀림을 하기 위해 봇을 다시 코드화하고 실제 선이 공식(2000) 수치를 동시에 나타내는지 확인하는 것은 그리 어렵지 않을 것이다.세레 19:17, 2008년 7월 16일 (UTC)[응답]

부록 - 나는 여전히 그 아이디어를 좋아하지만, 미국 도시들(다른 나라의 몇몇 도시들뿐만 아니라)을 위한 많은 기사를 검토한 결과, 대다수가 가장 최근의 추정치라면 무엇이든 사용하고 있는 것으로 보인다.이 프로젝트를 진행하기 전에, 나는 지역사회의 합의가 무엇인지, 인구조사에서 추정하는 "공식"의 자격이 있는지, 아니면 우리는 이것을 다시 200명의 인구조사 숫자로 되돌려야 하는지에 대해 더 잘 느끼고 싶다.Sherth 20:04, 2008년 7월 16일 (UTC)[응답]

아티클의 GA 기호

나는 특집 기사의 오른쪽 상단 모서리에 특집 기사들이 얼마나 있는지 알아챘다.왜 좋은 기사들은 거기에 상징이 없는 거지?그럴 수 있을까?샤피로스10 17:19, 2008년 7월 15일 (UTC)[응답]

WT에서 보관된 이 토론을 참조하십시오.그 특정 주제에 대한 GA.고마워, D.M.N. (대화) 17:23, 2008년 7월 15일 (UTC)[응답]

나는 그 아이디어가 마음에 든다. 왜냐하면 나는 기사의 평점에 대해 배운 이후로 그것이 얼마나 믿을 만한지 알기 위해 기사의 평점에 의존하게 되었기 때문이다.나는 어떤 종류의 아이콘이 있으면 반위키*%-SYKKO-% (내게 말하라) 04:30, 2008년 7월 16일 (UTC)[응답하라]라고 말하는 일부 반(反)위키*%-SYKO-% (내게 말하라)를 억압하는 데 도움이 될 수 있다고 생각한다.

정말이지, 이건 맞아 죽었어.이 링크를 확인하십시오. 아이디어에 대한 찬반 논쟁이 모두 해당된다.2008년 7월 16일 (UTC) 15:43의 월섬 공작 (Waltham, The Duke of 15:43

최근에 논의되었고 다시 한번은 아닌, 수십억번 째로 광범위하게 패배했다.달라질 것 없어.샌디조지아 (토크) 15:45, 2008년 7월 16일 (UTC)[응답]

위키혁신

나는 위키피디아가 위키이노베이션이라는 자매 프로젝트를 시작한다면 유용할 것이라고 생각한다.그 아이디어는 대중에게 오픈소스 개발을 가져가는 것이다.만약 비전문가가 제품, 소프트웨어 또는 서비스에 대한 혁신 아이디어를 가지고 있다면, 그는 그것을 사이트에 올릴 수 있다.사람들은 혁신에 대해 의견을 개진하거나 아이디어를 추가할 수 있다.

여러분이 생각해왔던 모든 시간을 생각해 보십시오. "만약에 ...하면 좋지 않을까?" 그러면 그 생각은 여러분의 다음 생각 속으로 빠르게 빠져들어간다.당신은 위키이노베이션에 전달된 아이디어를 "트위킹"할 수 있으며, 그것은 새로운 제품이나 더 많은 아이디어의 씨앗이 될 것이다.아이폰에 있는 어플리케이션에 대한 아이디어를 가진 모든 사람들을 생각하되, 코드를 맞추거나 너무 바빠서 그 아이디어에 신경 쓰지 마십시오.많은 사람들은 아마도 그들의 자동차나 냉장고에 점진적인 개선을 위한 아이디어를 가지고 있었을 것이지만 가까운 미래에 GM이나 GE와 경쟁하지 않을 것이다.

결국, 대부분의 제품, 소프트웨어 및 서비스는 각각의 미래 특징과 논의의 희망 목록과 함께 분류될 것이다.그 아이디어는 유용성이나 필요성에 대한 사용자들의 평가를 받을 수 있다.최고의 아이디어가 떠오를 것이다.마케터들은 좋은 아이디어를 얻기 위해 사이트를 채굴하고 충분한 시장 지배력을 가진 혁신을 추구할 수 있다.이 사이트는 제품의 진화를 실질적으로 가속화하고 급변하는 환경에서 사람들의 요구를 충족시킬 수 있다.

데이비드 컨 로버츠

좋은 생각이긴 한데, 장소가 잘못됐어.이것은 영어 위키피디아에 대한 제안서를 위한 것이다.새로운 프로젝트 아이디어가 메타에 게시되어야 한다. -- 임페라토르3733 (토크) 00:45, 2008년 7월 16일 (UTC)[응답]

재단은 새로운 프로젝트를 시작하는 것에 대해 매우 보수적이다; 그냥 직접 위키백과를 만드는 것이 더 쉬울지도 모른다.WikiWikiWeb을 참조하십시오.WikiFarms가 Wiki를 시작하는 데 도움을 줄 수 있는 장소 목록!위키인덱스를 검색해 볼 수도 있다. 다른 사람이 이미 비슷한 생각을 갖고 있는 경우. --_{tiny plastic} 그레이 나이트 ⊖ 12:01, 2008년 7월 16일 (UTC)[응답]

하위 페이지 탭

나는 History 탭과 같이 WP의 특정 페이지에 대한 모든 하위 페이지(및 모든 하위 페이지의 하위 페이지)의 동적 목록을 만드는 하위 페이지 탭이 필요하다.그것은 사물을 찾는 것을 훨씬 더 단순하게 만들 것이고, 또한 WP를 더 투명하게 하는 데 도움이 될 것이다.나는 개인적으로 내 사용자 페이지 아래에 있는 내가 가지고 있는 쓰레기 절반에 어떻게 도달해야 하는지 기억하지 못하며, WP의 모든 하위 페이지를 뒤져보면 매우 좋을 것이다.VG. JohnnyMrNinja 06:16, 2008년 7월 16일 (UTC)[응답]

특별 체험:PrefixIndex. --- RockMFR 06:17, 2008년 7월 16일(UTC)[응답]

이건 완벽해.Special:에 나열되어 있는 것을 보지 못했다.특수 페이지.이것이 탭으로서 바람직하지 않을까?조니미르닌자 06:23, 2008년 7월 16일 (UTC)[응답]

그렇다, 그래서 나는 그것을 1 :)로 가지고 있다.위키피디아에서 가져왔어:WikiProject 사용자 스크립트/스크립트/사용자 탭. 사용자 공간을 벗어나려면 쉽게 다시 쓰십시오.대수학자 10:54, 2008년 7월 16일 (UTC)[응답]

위키백과

이 토론에서 에마누엘렘은 어린이들을 위한 위키백과(사랑스럽게 "위키페디아키드"라고 불림)의 아이디어를 생각해 냈고 나는 이 아이디어를 강력히 지지한다; 위키백과는 검열되지 않고, 그렇게 해야 하지만, 그것은 우리에게 부적절한 내용을 가진 인터넷 소수자를 배제하는 문제를 남겨준다.만약 "위키페디아키드"가 고려되고 논의된다면, 나는 우리가 알고 사랑하는 '페디아'와는 다른 기본적인 프리니컬 세트를 제안한다.

검열 등

1. 기사들이 어린이들에게 적합할 것이며, 사이트들이 제공할 콘텐츠의 범위도 보존하기 위해 주의를 기울여야 할 것이다.즉, 섹스는 기사가 아닐 테지만, 어머니와 아버지는 기사가 될 것이다. (그게 말이 안 된다면, 제발 나를 헐뜯어줘.
2. 그림은 적절하고 자기 설명이 필요할 것이다. (아래 참조)

기사 명확성 및 가독성

1. 기사는 기본적으로 도입 단락이 길어질 것이다.이것은 기사의 길이를 합리적으로 하고 내용을 이해할 수 있게 할 것이다.그들은 en에 관한 전체 기사와 연결되어 있을 것이다.위키, 그렇게 하면 그들이 "죽여버릴" 수도 있어.
2. 사진이나 다른 매체들은 자기 설명이 가능하고 관심을 끌 것이다; 나는 대부분의 젊은 사람들이 화보적인 표현으로 더 효과적으로 이해할 것이라고 거의 확신한다.
3. 길이(더 자세히)는 위키키즈에서 큰 이슈가 될 것이다.그 글은 읽기 쉬운 크기여야 할 텐데, 어쩌면 긴 스텁의 평이한 크기일 수도 있지 않을까?

반달리즘

상당히 명백한 이유(나는 희망한다) 때문에, (특히 동성애 혐오/불가르 함량을 가진) 이곳에 만연한 공공 기물 파괴 행위는 거기서 명백할 수 없다.그것은 전체 목적을 망칠 것이고, 나는 이 문제에 대해 다음과 같은 해결책을 제시한다.

1. en에 등록된 사용자만.wiki는 편집할 수 있다.
2. WikiKids에서 편집을 원하는 사람은 관리자의 검토 또는 승인을 받아야 한다.
3. 업로드된 모든 파일을 검토한 후 게시한다.
4. 새 페이지는 다른 두 명의 사용자를 통해 실행되어야 한다.

그것밖에 생각이 나지 않는다.네 생각을 말해봐!아니면 내 것을 부수거나.레너드^(Bloom) 03:34, 2008년 6월 27일 (UTC)[응답]

"사진은 스스로 설명할 수 있는 것이 될 것이다"라고만 말할 수는 없다. 우리는 자유롭게 허가된 미디어로 제한하기 때문에 우리는 우리가 얻을 수 있는 것을 고수하고 있다.만약 그러한 프로젝트가 위키미디아가 주최하거나 위키피디아 이름을 사용한다면, 나는 그것이 무료 미디어를 사용해야 할 것이라고 생각한다.그리고 위키백과 기사로 다시 연결하면, 아이들이 "세이퍼" 사이트로 분리되도록 하기 위한 목적을 다소 좌절시키지 않는가?마지막으로, 공공 기물 파괴 행위를 진정으로 제거하려면(또는 최소한 정말 가능성이 희박하게) 신뢰할 수 있는 사용자들이 모든 편집을 실행하기 전에 승인하도록 해야 하거나, 또는 편집 승인을 받을 수 있는 사람에 대한 매우 엄격한 요구 사항을 가지고 있어야 하며, 이것은 여러분의 잠재적인 사용자 기반을 획기적으로 감소시킬 것이다.Mr.Z-man 03:44, 2008년 6월 27일 (UTC)[응답]

자유분방한 언론매체에 대한 그 말은 일리가 있고, 나는 그것을 간과했다.흐음... 그건 나중에 곰곰이 생각해 볼게.다음으로, 내가 말하지 않는 링크백 이슈는 자기 파괴적이다; 링크백은 부적절한 콘텐츠의 위험을 무릅쓰고 더 많은 정보를 제공할 수 있다.링크나 뭐 그런 거 할 때 경고 페이지 같은 거?경고로 리디렉션된 다음 "계속하시겠습니까?예/아니오" 비트.공공 기물 파손에 대해서는, 네가 약간 말했듯이, 항상 인간적인 요소가 있지만, 선의의 가정과 더 엄격한 기물 파손주의 시계를 갖는 것이 도움이 될 것이다.나는 그것이 몇 가지 일을 해결하는 데 도움이 되기를 바란다.레너드^(Bloom) 03:59, 2008년 6월 27일 (UTC)[응답]

그럼, 예언자의 사진은 없군, 그렇지?그것은 몇몇 작은 토트들에게 피해를 줄 수 있다.브래지어 입은 사람의 사진은 없어, 사실 브래지어나 젖가슴에 관한 건 아무것도 갖고 있지 않는 게 좋겠어.동성애 혐오증이 아닌 건 동성애자 모집인 것처럼 들리는데물론, 종교 교육이 어린이들에게 어떻게 영향을 미치는지에 대한 어떠한 아이디어도 없고, 확실히 어떤 지방, 주 또는 국가에서 어린이들을 교육하는 방법에 대한 논쟁을 나타내는 것은 아무것도 없다.질병에 관한 많은 기사들은 "괜찮을 거야, 그냥 약을 먹어"로 바뀌어야 할 것이다.

나는 내가 방금 말한 것 중 어느 것도 지지하지 않지만, 그들 중 어느 누구도 위키피디아키드를 생산하기 위한 완벽한 지뢰밭을 보여준다.우리는 어른들에게 무엇이 좋은지 겨우 알 수 있다.훌륭한 아이디어지만, Z-man의 의견을 따르는 것은 신뢰할 수 있는 사용자 - 어떤 사용자가 내용을 승인할 수 있는지 정의하는 사람?부모의 현실은 모든 사람들이 그들의 아이들에게 무엇이 옳은지에 대한 그들만의 특별한 생각을 가지고 있다는 것이다.나는 여러 가지 측면에서 문제가 발생하는 것을 볼 수 있다.만약 여러분이 이 백과사전을 젊은 사용자들이 사용할 수 있도록 확장할 수 있는 방법을 찾을 수 있다면, 여러분에게 더 많은 힘이 될 것이다!프라나맥스 (대화) 06:03, 2008년 6월 27일 (UTC)[응답]

위키미디어 재단 자신이 그것을 하고 싶어할지 의심스럽다. 위키피디아는 아마도 그들이 원하는 콘텐츠 분리형 종류의 일에까지 관여하고 있을 것이다.물론, 당신은 항상 스스로 그것을 갈 수 있다.:-)

사용자에게 묻겠다:NonvocalScream to chism in here, I believe him he's asking some basic understanding problems and what the telling peoples to the traph.

--_{tiny plastic} Grey Knight , 13:27, 2008년 6월 27일 (UTC)[응답]

이미 간단한 영어 위키백과가 있다.그것은 언어적 근거에 의한 것이긴 하지만, 콘텐츠 포킹에 대한 일종의 선례다.나는 아이가 접근할 수 있는 기사(단순하고 친근한 설명, 글쓰기 스타일, 일반적인 관용어)가 있는 위키백과에 상당히 찬성하겠지만, 나는 그것이 비공세적일 것이라는 어떤 종류의 약속에도 극단적으로 반대한다.-나는 a) 어떤 잠재적인 위법 행위도 피하기 위한 검열이라는 개념, 또는 b) 프로페즈에도 반대한다.불가피한 실수의 여파를 ct.Phyomonas_(talk) 15:58, 2008년 6월 27일 (UTC)[응답]

대부분의 인터넷 브라우저에는 부모들의 통제가 있기 때문에 부모들은 그것들을 위키피디아에 있는 검열되지 않은 자료들을 차단하는데 사용할 수 있다.RedThunder 16:49, 2008년 6월 27일 (UTC)[응답]

위의 코멘트에 대한 기본적인 대응.

1. "신뢰할 수 있는 사용자"는 위키키즈를 돕고자 하는 사람을 검토하게 하는 것을 의미한다.롤백을 받는 것과 같이, 이름과 이유를 게시하면 응답을 받는다."지뢰밭" 비트에 대해서는, 나는 무엇이 적절하고 적절하지 않은지를 결정하는 것이 비교적 쉬울 것이라고 생각한다; 성적 또는 도덕적으로 금기시되는 주제는 제외되지만, en.wiki와의 연결을 통해 연결될 수 있을 것이다.하지만 내가 모든 과정을 하향 평준화시키고 있는지도 모른다.
2. 그래, 이런 생각이 짐보에게까지 전해지진 않을 거야.하지만 또 누가 알겠는가?눈덩이가 아니다.
3. 어린이가 접근할 수 있는 위키백과는 훌륭한 아이디어로, 장기적으로 위키키즈보다 더 이치에 맞을 수도 있다.나도 검열을 지지하지는 않지만("검열은 아기가 스테이크를 먹을 수 없기 때문에 금지시키는 것과 같다" - 마크 트웨인) 위키피디아가 검열을 거부함으로써 잠재적인 시청자들에게 손해를 끼치고 있는 것 같다.나는 위키피디아가 검열되어야 한다고 말하는 것이 아니라, 대안이 제공되어야 한다.
4. 아무런 반응이 떠오르지 않는다.미안해. 답장은 정말 고맙고, 나는 이 아이디어가 토론되고 검토되는 것을 봤으면 좋겠어.레너드^(Bloom) 19:36, 2008년 6월 27일 (UTC)[응답]

컨셉이 마음에 드는데...아마도 다른 무료 콘텐츠 백과사전, 또 다른 프로젝트를 여는 것이 제안일 것이다."어린이를 위한 영어 위키백과" 또는 비슷한 것.새 프로젝트(인큐베이터/메타에 승인되고 설정되는 경우)는 지침과 내용 지침까지 기초부터 작업이 필요할 것이다.하지만 아마도 여기서 위키백과의 한 부분은 좋은 생각이 아니라, 다른 위키백과 프로젝트가 아이들을 대상으로 하는 것을 목표로 하는지를 고려해보자(즉, 프로젝트 페디아의 청중은 아이들이다).각 프로젝트에는 실행 방식을 설정할 수 있는 능력이 있다.이것은 아마도 이 백과사전(영어 위키백과)의 무결성을 침해하지 않는 방법이 될 것이다.메타에 대한 새로운 프로젝트를 제안하는 것을 고려해보라.생각?NonvocalScream (대화) 03:09, 2008년 6월 28일 (UTC)[응답]

"키즈"는 꽤 광범위한 대상 인구통계학이다. 우리는 5-10세, 11-14세, 15-18세 사이의 콘텐츠 사이에 모든 어린이들을 겨냥하거나 다른 종류의 위키나 다른 종류의 벽을 둘 것인가?공공 기물 파손에 대한 우려는 다음과 같다.플래그 지정된 개정은 결실을 맺는 데 도움이 될 수 있다.— Matt Eason 21:33, 2008년 6월 28일 (UTC)[응답]

아이들은 스스로 정의되는 인구통계학일 것이고, 결정적인 요인은 부모일 것이다; 자녀들(또는 부모들)은 그들이 부적절한 내용을 볼 것을 원하는지(또는 그들의 자녀들)를 결정할 것이다.위키백과또한, WP:플래그 지정은 좋은 추가 사항이고, 코멘트 고마워!레너드^(Bloom) 00:47, 2008년 6월 29일 (UTC)[응답]

그것은 까다로운 것이다.위키피디아의 요점은 누구나 그것을 편집할 수 있지만, 인용문으로 항상 정보를 확인해야 한다는 것이다. 그리고 그들의 편집은 다른 사용자들에 의해 도전 받을 수 있다.그것은 내용, 편집, 스타일, 참조 등에 관한 위키피디아의 규칙과 지침을 따를 수 있을 것 같지 않은 어린이들에게는 그다지 잘 번역되지 않는다. & 만일 그러한 모든 규칙이 완화되어 (예를 들어) 아이들이 참조되지 않은 내용 & POV 댓글을 추가할 수 있다면, 그것은 금방 매우 질이 나쁜 백과사전으로 전락할 것이다.반면 WPKIDS가 성인 사용자들에 의해 편집되었고, 어린이들 스스로가 그것을 편집할 수 없다면, 그것은 CD-Rom에서 구할 수 있는 어린이 백과사전들과 크게 다르지 않을 것이다.족제비 페틀록스 (대화) 2008년 6월 29일 14:18 (UTC)[응답]

어린이 버전을 위한 완전히 새로운 위키를 만드는 대신에, 기존의 위키백과 데이터베이스를 사용하기 위한 인터페이스로 위키백과들을 만드는 것이 어떨까 하는 생각이 든다.그것은 더 어린이 친화적인 그래픽을 가질 수 있고 간단한 검색 페이지에서 시작할 수 있다.검색은 위키피디아에서 관련 기사를 끄집어내지만 위키피디아키드 창에 표시되는데, 위키피디아키드 창에는 아이들이 이해할 수 없는 글의 어떤 단어도 바로 찾을 수 있도록 위키피디아 검색 필드도 포함될 수 있다.특정 주제(예: 성적인 주제)에 대한 위키백과 기사를 위키백과 검색으로 볼 수 없도록 '블록'을 넣는 것이 매우 쉬울 것이라고 확신한다.족제비 페틀록스 (토크) 2008년 6월 29일 (UTC) 15:05[응답]

그 생각은 아마도 이 실 중에서 가장 실용적일 것이고, 나는 그것이 쉽게 이루어질 수 있다고 생각한다.이 시점에서 '지지'나 '반대'를 요구하는 것은 무리일까.이 아이디어가 어디든 갈 수 있는지 보고 싶어.레너드^(Bloom) 17:39, 2008년 6월 29일 (UTC)[응답]

위키피디아를 현장에서 '창살'하려는 모든 시도에 반대한다.네가 갈퀴로 복사한 것은 너에게 달려 있다.하지만 여기 위키피디아에서는 WP가 되지 마십시오.토비. 튀김 - tk 12:57, 2008년 7월 1일 (UTC)[응답]

나는 어린이들을 위한 위키피디아에 대한 이러한 생각은 이미 존재하는 간단한 영어 위키피디아와 대체로 중복될 것이라고 생각한다; 후자 프로젝트는 특별히 어린이들을 위해 고안된 것이 아니지만, 그것은 비기술적이고 이해하기 쉬운 언어로 특별히 쓰여져 있다. -- Anonymous Dissident^Talk 08:39, 2008년 7월 7일 (UTC)[응답]

이 제안이 완전히 실패하는 것이 아니라 위키백과 제품에 대한 접근성을 높인다는 측면에서 장점이 있는 반면, WP 전체가 완전히 강력한 상태가 아니라는 점을 고려할 때, 사람과 자원을 줄여서 확장시킨다. 위키프로젝트에 가면, 특집 기사나 좋은 기사가 몇 개나 되는가?직접 점을 다루다.

• 검열을 이용하는 것은 판도라의 파멸의 상자를 열 것이다.이것이 단순히 영어 제품이 아니라 미국 제품이라고 가정한다면, 우리는 기독교 국가인 미국인가?좋아, 우리는 "적절함"을 복음주의, 개신교, 가톨릭 또는 루터교 신앙에 맞추는가?종교를 배제하고, 어떤 근거로 무엇이 포함되고 포함되지 않는지를 결정하는 것은 누구인가?정책 페이지를 개발해야 할까, 단순히 토론하는 데 몇 달이 걸릴까?
• 교육자들은 우리가 진짜 교육 상품을 홍보하려고 하는 것인지, 그리고 우리가 어떤 지침을 따르고 있는지, 그리고 어떤 등급을 목표로 하고 있는지 물어볼 것이다.얘들아? 우리 유치원 말하는 거야 초등학교 말하는 거야?
• 우리가 사용자들이 가입할 수 있는 적절한 안전장치를 가지고 있다고 해도, 그들이 몰래 어떤 소아성애자나 싸이코가 아니라고 누가 말하겠는가?지금 WP의 세이프가드는 반달들이 몇 분 안에 잡힐 수 있도록 투자된 많은 사용자들이 서로를 감시하고 있다는 것이다.우리는 "키즈" 버전을 함으로써 위키미디어 재단을 위한 소송과 책임의 완전히 새로운 세계를 열 것이다.벌써 손이 꽉 찬 것 같아.
• 따라서 이러한 모든 제한을 수표, 리뷰 등과 같은 위키피디아키드에 적용하면 위키피디아의 정신은 저하되고 이 제품과 연관되어서는 안 된다.스스로 발전한 뒤 성공적이라고 판단되면 나중에 합병하는 것이 좋다.브랜드와 품질을 지켜야 해. .:다부마야:. 15:57, 2008년 7월 11일 (UTC)[응답]

나는 이 생각에 반대한다. WPK는 더 많은 포함/배제 논쟁을 의미하기 때문이다. 예를 들어, 생물학적 성에 관한 기사가 있어야 할지도 모른다. 아이들이 그것에 대해 배우도록 해서는 안 된다고 누가 말할 수 있겠는가?게다가, 그것은 대부분의 WP를 다시 쓰거나 베끼는 것을 의미할 것이고 그것은 Simple English Wikipedia와 비슷한 것처럼 보인다.그러나 나의 주된 문제는 "키드"를 정의하기 어렵다는 것이다.다섯 살짜리는 12살짜리가 필요로 하는 것과는 다른 스타일의/다른 난이도로 쓰여진 자료를 필요로 하는데, 이것은 전쟁을 편집하거나 WPK로 하여금 그것의 목표 청중들 대부분에게 쓸모없는 것이 되게 할 수도 있다.It Is Me Here (토크) 16:23, 2008년 7월 17일 (UTC)[응답하라]

예로 사용하기 위한 위키프로젝트

페이지 플립 위키백과

위키백과 편집자들 안녕!

내 이름은 와일리 콜먼, 잉게이지 사의 인사이드 세일즈 담당자야.Wikimedia Foundation과 Igague 간의 향후 작업 관계에 대해 귀하께 연락을 드리며, 귀하에게 큰 가치가 있는 제품을 제공한다고 믿기 때문이다.

잉게이지(ingage)는 디지털 출판사다.우리는 비용 효과적으로 인쇄 매체를 디지털, 온라인, 페이지 이동, 대화형 문서로 변환한다.본질적으로, 우리는 사용자에게 실제 인쇄물을 읽는 느낌을 준다.내 생각은 위키미디어 재단의 프로젝트에 우리의 페이지 플립 기술을 통합하는 것이다. 더 이상 위아래로 스크롤하는 일은 없을 것이고, 당신은 마치 실제 물리 백과사전처럼 페이지를 넘기고 있을 것이다(그리고 그것은 전체 문서 전체에서 매우 쉽게 이동할 수 있는 상호작용이 가능한 특징들을 가지고 있을 것이다). 이 이메일에 샘플을 첨부해서 제품에 대한 더 나은 느낌을 얻고, 어떻게 작동하는지, 그리고 그것이 당신에게 어떤 혜택을 줄 수 있는지 알아보도록 하겠다.나는 다른 이메일이나 전화를 통해 잉게이지에 대한 더 많은 정보를 설명하고 이 가능성에 대해 더 자세히 논의했으면 좋겠다.우리는 Wikimedia Foundation에서 팀과 함께 일할 수 있다는 가능성에 대해 흥분하고 있으며, 당신의 답변을 기다리겠습니다.나는 wiley@ingageinteractive.com으로 연락할 수 있다.

샘플 – http://publications.ingagepublication.com/BRIERCREEKMAGAZINE07/

고마워!와일리 콜먼

위키피디아는 무료 오픈소스 소프트웨어만 사용하는 정책을 가지고 있다.당신의 소프트웨어는 Adobe Flash를 기반으로 하는 것으로 보이기 때문에, 그 자체로 오픈 소스라 하더라도, 우리의 사용을 고려할 수 없다.-gadfium 21:18, 2008년 7월 16일 (UTC)[응답]

물론 재단()foundation-l@lists.wikimedia.org이나 기술팀()과 대화할 수 있다.—wikitech-l@lists.wikimedia.org 베르드나 • 대화 04:30, 2008년 7월 17일 (UTC)[응답]

맙소사! 위키피디아는 그대로 완벽하게 작동한다.플래시를 기반으로 한 벨과 휘파람은 지금보다 훨씬 더 어렵게 기사를 탐색하고 검색할 필요가 없다.그가 돌아왔니?(토크) 2008년 7월 17일 10시 39분 (UTC)[응답하라]

(ec) 연계된 예도 열어볼 수가 없었다.나는 재단이 그에게 불확실한 조건으로 곧 알려줄 것이라고 확신해, 다음 번에는 그런 제안들이 적절한 장소로 갈 수 있기를 바라.혐오표현의 필연적인 맹공을 미리 차단하기 위해 이 섹션을 닫아야 할까?:-) 아니면 이것이 어떤 실제적인 문제를 제기하는가(내가 생각할 수 있는 것은 (위의 것과 같은 전체 인터페이스를 플래시 문제로 대체하는 것과는 대조적으로) 기사에 플래시 문제를 포함시키는 것 뿐이며, 그 문제가 제기될 때마다 완패했다고 생각한다. --_{tiny plastic} 그레이 나이트 ⊖ 11:31, 2008년 7월 17일 (UTC)[응답]

이것은 문제가 아니라, 위의 원본 포스터가 물론 무료라는 것을 상기시켜주는 것으로, GFDL의 제약조건 내에서 위키피디아의 텍스트를 가져다가 자신의 웹스페이스에 원하는 어떤 표시 형식에 넣어도 된다.Phyogonas_(talk) 11:51, 2008년 7월 17일 (UTC)[응답]

상당히 심각한 KISS 문제가 발생했고 우리는 이미 TOC와 스크롤 막대 또는 휠을 "전체 문서 전체에서 매우 쉽게 이동할 수 있는 기능"을 가지고 있다.Geni 11:47, 2008년 7월 17일 (UTC)[응답하라]

데모를 진행했는데, 그것에 대해 "아주 쉬운" 것은 하나도 보이지 않았다.PDF에 비하면 느리고 추악하며, 이미 하고 있는 일에 비하면 형편없다.보아하니, 페이지 전환 애니메이션밖에 없는 것 같은데, 사용자들이 금방 싫증을 낼 것 같은 속임수인 것 같다. -- 팀 스타링 (토크) 09:23, 2008년 7월 28일 (UTC)[응답]