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

삭제 가시성

FAQ와 특정 페이지에 기고된 모든 기고자에게 삭제에 대해 통지하는 것을 읽은 후, 나는 편집자의 무리를 알리는 것에 대한 순수한 부담감 때문에 이것이 어려운 과정이라고 이해한다.제안된 치료법은 페이지를 보는 것이다.삭제된 로그 항목이 워치리스트에 표시되길 바란다.예를 들어, 삭제할 페이지를 볼 때, 삭제 로그 항목이 내 감시 목록에 기록되며, 예를 들어 다음과 같이 삭제 로그 항목이 삭제된다.

관리자 삭제(G6에 따라 삭제, 하우스키핑)에 의해 삭제되는 15:40

• 다른 사람들은 이것을 우리가 원하는 것으로 보는가?
• 기술적으로 가능한가?2007년 11월 16일(UTC) Martijn Hoekstra 13:41 [응답]

이미 알려준 것 같아.모든 기여자는 빠른 삭제로 통지될 필요가 없으며, Prods 또는 AFD만 통지되며, 그 후에도 주요 기여자만 통지된다--Phoenix-wiki (talk·contracts) 21:22, 2007년 11월 16일 (UTC)[응답]

기술적으로, 통지는 결코 필요하지 않다. 그것은 단지 예의 바르게 하는 것이다.그러나 이 제안은 통보가 아니라 실제 삭제된 내용을 감시 목록에 표시하는 것이다.마르틴 회크스트라 (대화) 2007년 11월 16일 (UTC) 22:56 [응답]

삭제 및 보호 로그 항목이 감시 목록에 표시되지 않음삭제 항목이 삭제된 경우 유용할 수 있다. 사용자가 페이지가 삭제되었는지 확인하려면 해당 페이지로 이동하거나 전체 버전의 감시 목록을 편집한 후 이전의 빨간색 링크가 파란색으로 변했음을 알려야 한다.(일부 사용자(많은 관리자 포함)는 일부 삭제된 페이지를 의도적으로 감시하므로, 빨간색으로 표시된 것만으로는 충분한 증거가 되지 않는다.)나는 이것이 (삭제가 보호보다 더 중요하기 때문에) 갖기 좋은 것으로 평가하지, 중요한 요구사항으로 평가하지 않는다.아마도 개발자의 노력이 필요하기 때문에 버그질라(bugzilla)가 그 장소일 것이다. 또는 WP:VPT. GRBerry (대화) 16:03, 2007년 11월 19일 (UTC)[응답]

나는 이것이 좋은 일이 될 것이라는 것에 동의한다(이미 보호가 나타나지 않는다는 사실에 놀랐다-역사에 나타나 있다)—랜덤832 17:23, 2007년 11월 19일 (UTC)[응답]

나타나지 않는 것보다 더 나쁘다.보호 기능은 실제로 이전 편집 내용을 숨긴다.페이지를 편집한 다음 보호하면 편집이 누구의 감시 목록에 나타나지 않을 것이다. --카닐도 (대화) 09:11, 2007년 11월 20일 (UTC)[응답]

디지털 음극 형식(DNG)

여보세요, 얼마 전에 위키미디어 프로젝트에서 고화질 이미지의 DNG 포맷을 허용하자고 제안했었습니다.[1] DNG의 주요 차이점은 Raw image format, 즉 프로페셔널 품질을 위한 무손실 이미지 압축이라는 점이다.현재는 일부 디지털 카메라(단, 다른 원시 포맷의 변환 도구가 있음)에 의해서만 지원되지만, 이러한 고화질의 영상을 업로드할 수 있도록 허용하고(이미지 뷰어의 비교 참조), MediaWiki는 고화질의 벡터 이미지를 위한 SVG에 대해서처럼 이미지를 jpeg/png로 변환한다.

주요 관심사, 그리고 제안을 중단한 것은 로열티 무료 DNG 특허 규격의 면허가 위키미디어 재단의 프로젝트에 충분히 무료인지 확인하는 것이다([2] 참조).이 일을 경험해 본 사람이 있는가?즉, DNG가 공개형식인가가 포인트라고 생각한다.안부 —수루냐 15:09, 2007년 11월 19일 (UTC)[응답]

나는 이것이 여기보다는 커먼즈 마을 펌프에서 가장 잘 논의되는 것으로 의심한다. 왜냐하면 그것은 모든 위키백과 프로젝트에 관한 것이거나 영어 위키백과가 단지 하나일 뿐이기 때문이다. -- John Brown (usclusic) 16:00, 2007년 11월 19일 (UTC)[응답]

사실, 나는 이것을 Commons에서 제안하고 싶다. 이론적으로, 우리가 여기서 가져야 할 유일한 이미지는 Fair Use 이미지인데, 여기서 우리가 가장 원하지 않는 것은 초고화질 이미지를 제공하는 것이다.EVULA// talk // talk // 16:30, 2007년 11월 19일 (UTC)[응답]

나는 그것에 약간 동의하지 않는다.공용 도메인, CC 및 GFDL 영상은 고화질일 수 있다.Corvus cornix (talk) 22:39, 2007년 11월 20일 (UTC)[응답하라]

나도 동의하지만, 공용 도메인, CC, GFDL 이미지는 여기에 업로드되어서는 안 된다. 그것들은 Commons로 설정되어야 한다.EVULA// talk // talk // 22:46, 2007년 11월 20일 (UTC)[응답]

아, 무슨 말인지 알겠어.2007년 11월_talk 20일 코버스 코닉스 23:41, (UTC)[응답]

ICD9에 대한 일부 도움말

누군가는 당연히 왜 {{}}}을(*)ICD9}}은(는) 관련되지 않고 권한 없는 .com 사이트를 링크에 사용하며, {{}ICD10}은(는) 다소 복잡한 시스템을 통해 WHO에 직접 연결된다.WHO의 ICD9 페이지가 ICD9 템플릿을 통해 체계적으로 연결될 수 있는지 아는 사람?68.39.174.238 (대화) 01:00, 2007년 11월 20일 (UTC)[응답]

아르카디안에게 물어보아라(토크 · 기여).그는 이 과정의 편집장이다.그가 세계보건기구(WHO) 페이지에 연결하지 않을 설득력 있는 이유가 있었을 것이다.JFW T@lk 13:12, 2007년 11월 20일 (UTC)[응답]

Tanx, 그의 말을 보겠다. 68.39.174.238 (대화) 00:41, 2007년 11월 21일 (UTC)[응답]

템플릿 토크에서의 응답:ICD9. --Arcadian (대화) 01:18, 2007년 11월 21일 (UTC)[응답]

저널스프록시

위키백과에서 교차 게시:위키프로젝트 학술지

내가 의대에 있을 때 우리 대학의 도서관은 가장 놀라운 도구를 고안해냈다: 그것은 도서관 시스템에 프록시 서버를 설치해서 사람들이 기관 구독료만 사용하더라도 자신의 집에서 편안하게 온라인 저널에 접근할 수 있도록 했다.

나는 위키피디아가 비슷한 시설을 운영하거나, 적어도 비슷한 시설에 대한 접근권을 획득하는 것을 한동안 꿈꿔왔다.물류와 비용이 상당하다는 것은 알고 있지만, 학문 중심적인 과목(과학과 인문학과)에 대한 콜라보적인 힘이 될 것이라는 생각도 든다.개인적으로, 나는 대부분의 병원에서 저널에 대한 접근이 제한되어 있기 때문에 나의 출처를 선택해야만 한다. 그러므로 나는 그것을 손에 넣을 수 있기 때문에 더 낮은 품질의 참고자료를 선택할 수도 있고, 대영 도서관에서 그것을 주문하기 위해 도서관에 돈을 지불하는 일이 거의 없기 때문이다.

나는 단지 그러한 노력에 대한 지역사회의 지지가 궁금하다.JFW T@lk 13:14, 2007년 11월 20일 (UTC)[응답]

좋은 생각처럼 들리지만, 누구나 위키백과 계정을 등록할 수 있기 때문에 아마도 실행 불가능할 것이다.그것은 당신이 접속을 규제할 수 없다는 것을 의미하고, 적절한 금액을 부과할 수 없다는 것을 의미하는데, 이것은 기관 가입에 관한 것이다.기관지 구독은 얼마나 많은 사람들이 저널에 접속하고 있는지 명확히 알 필요가 있는데, 이것은 비용에 대한 아이디어를 준다.나는 우리가 소스를 제공하고 검증하기 위해 그러한 접근 권한을 가진 위키피디아 사람들에 의존하는 것에 집착하고 있다고 생각한다.카차롯 (대화) 2007년 11월 20일 (UTC) 13:19[응답]

그것은 정말 멋질 것이다. 그러나 또한 Carcharoth에 의해 요약된 이유들 때문에 작동하지 않을 것이다.사이트 인허가 제한에 관한 문제 외에도, 순전히 드는 비용은 위키피디아의 가격 범위 밖에 있을 가능성이 높다.여기 네이처 저널 계열의 가격 책정 링크가 있다.대형 학술기관이 주요 학술지를 구독하는 데 드는 비용은 수만 달러에 크게 달할 것이다.주요 대학 도서관은 수천만 명을 투입할 수 있는 정기 간행물 예산을 보유하게 된다. (참고로 위키피디아의 전체 예상 2007-08년 예산은 460만 달러로, 대부분은 서버실에 불을 켜놓기 위해 책정되어 있다.)TenOfAllTraes(대화) 2007년 11월 20일(UTC) 13:45[응답]

1998년 영화 '마딩 크라우드로부터 멀리'의 기사 제안

여보세요

이렇게 명백하고 기본적인 질문에 대해 사과한다.나는 이 영화에 대한 기사를 쓰고 싶다.그것을 위한 단 한 가닥의 스텁만 있을 뿐, 확장해 달라는 간청도 있다.이것은 내가 그것을 검토할 수 있다는 것을 의미하는가?이것이 "편향된" 정보로 여겨질지 아닐지는 모르겠지만, 나는 영화가 일상적으로 쓰여지는 것을 본다.이것이 적절한 기사 주제인가?루시1492 (대화) 2007년 11월 20일 16:35 (UTC)[응답]

백과사전적인 방법으로 기사를 확대할 수는 있지만, 아니, 리뷰를 쓰지 않을 수도 있고, 오히려 여기에 올릴 수도 없다.EVula // talk // talk // 16:37, 2007년 11월 20일 (UTC)[응답]

미리보기의 각주

편집한 내용을 미리 볼 수 있지만, 작업을 저장하기 전에는 각주를 미리 볼 수 없어.종종, 나는 "단순" 각주가 파이프나 파라미터가 없어져서 두 번째 정리가 필요하다는 것을 알게 되었다.를 미리보기 하단에 통합할 수 있는가?응, 편집 중인 섹션에 내 자신을 추가한 다음 저장하기 전에 제거할 수 있다는 걸 알아.그러나 이는 궁극적으로 거기에 있을 의도가 없는 텍스트를 추가하기 위한 해결책으로 보인다.MediaWiki 소프트웨어에서 하드 코딩이 필요한지 잘 모르겠다. Special:모든 메시지, 하지만 간단한 해결책이 있을지도 몰라.—Twigboy 16:07, 2007년 11월 14일 (UTC)[응답]

그렇게 할 수 있다.두 가지 옵션이 있다. 1) 전체 페이지를 편집하여 참조 섹션이 미리보기에 표시되도록 하면 해당 페이지가 나타난다.2) 임시로 편집 중인 섹션 끝에 {{reflist}} 또는 <참조 />를 추가하고(예: 미리보기 전용) 저장하기 전에 최종 저장소에서 제거한다.둘 다 꽤 잘 된다. --Jayron32talkcontracts 04:32, 2007년 11월 15일 (UTC)[응답]

그래, 트위그보이가 이미 그 얘기를 한 것 같아.소프트웨어가 그것을 자동으로 할 수 있다면 좋을 것이다.그동안 Javascript로 할 수 있었던 것 같아. -- DatRoot 14:39, 2007년 11월 15일 (UTC)[응답]

나는 이제 이것을 하기 위해 대본을 만들었다.추가하기importScript("User:DatRoot/Scripts/PreviewRefs.js‎");js 파일로. -- DatRoot 14:20, 2007년 11월 19일 (UTC)[응답]

API에서 사용자:를 만들 수 있는 렌더 액션을 발견했다.Anomie/ajaxpreview.js.꽤 효과가 있는 것 같아, 심지어 기사의 다른 곳에 정의된 명명된 참조 자료로 섹션을 편집하는 사례까지 다루고 있어.IE 등에 효과가 있다는 보장은 없다.아노미에 04:53, 2007년 11월 21일 (UTC)[응답]

맘에 들어!난 아직 아약스에 관심 없어.IE에서도 잘 되는 것 같다. -- DatRoot 15:01, 2007년 11월 22일 (UTC)[응답]

나는 이것이 정말 흥미롭고 좋은 생각이라고 생각해.버그 리포트를 작성했는데, 여기: [3]도움이 되길 바라며, 위트 있는 라마 06:23, 2011년 5월 6일 (UTC)[응답]

카테고리 분할:생년 누락 및 범주:사망 년도 실종?

범주:생년 누락 및 범주:실종사망 연도는 유지하기가 불가능할 정도로 거대해졌다.전에 꺼낸 이야기인지 모르겠지만, 나는 카테고리를 나누는 것을 제안한다.이를 위한 두 가지 방법이 있다.

• 나라별로 나누기.나를 예로 들자면: 네덜란드인으로서, 나는 비교적 쉽게 네덜란드 출처를 접할 수 있다.이러한 출처는 주제의 탄생 연도를 제공할 수 있다.내가 만약 생년월일이나 사망연도를 알 수 없는 네덜란드 사람들의 범주를 가지고 있다면, 나는 어디를 봐야 할지 알 수 있을 것이다.
• 주제별로 나누기.스포츠 팬들은 어떤 스포츠 사람들이 생년월일 또는 사망년도를 알 수 없는지를 더 쉽게 알 수 있을 것이다.음악 애호가, 항공 전문가 등에게도 마찬가지다.다시 말하지만, 그들은 근원을 알지도 모른다.그러한 범주는 관련 위키프로젝트에 의해 유지될 수 있다.

생각나는 거 있어?aecis^Brievenbus 02:33, 2007년 11월 18일 (UTC)[응답]

대규모 정리 범주(예: 카테고리:출처가 부족한 기사)는 날짜별로 나눠 쓰는 것이다.Hut 8.5 10:20, 2007년 11월 18일 (UTC)[응답]

맞아, 내가 카테고리:스텁이 정렬됨(카테고리:스텁 카테고리).나는 그런 분류가 그 주제를 아는 사람이 와서 그 문제를 고치는 것을 더 쉽게 만들 것이라고 생각한다.Aecis^Brievenbus 12:18, 2007년 11월 18일 (UTC)[응답]

만약 그것이 WPJLY 기준으로 이루어진다면, 매우 산발적인 취재를 기대하라: 사실상 그것의 면면에서는 "이것들이 '당신의' 기사들인데, 그것들을 고치는 데 도움을 주는 것은 어떨까?"라고 말하는 것이 타당해 보일지도 모른다. 하지만, 그 근거로 관심을 가질 만한 것은 모든 편집자가 아닐 것이고, 실제로 그것은 거의 없을지도 모른다.그렇다고 그것이 어느 정도 도움이 되지 않을 수도 있다는 말은 아니다.월별로도 도움이 될 수 있지만, "후진"만큼 "후진" 작업을 함으로써, 기사가 오랫동안 YoB 없이 나른했다면 본질적으로 출처가 어려울 수 있는 반면, 새로운 추가는 "낮은 매달린 과일"일 수 있다.알라이 (대화) 03:43, 2007년 11월 19일 (UTC)[응답]

나는 이것이 "이것들은 당신의" 기사들인데, 그것들을 고치는 데 도움을 주는 것은 어떨까?"라고 말하는 것과 비슷하지 않을 것이라고 생각한다."당신의 범위 안에 있는 이 기사들이 이런 특정한 문제를 가지고 있다는 것을 알고 있었느냐"는 말에 가까울 것 같다.그것은 또한 위키프로젝트 내에 아직 관여하지 않았지만 특정 위키프로젝트의 범위 내에서 "할 일"을 찾고 있는 관심 있는 편집자들에게 인센티브를 줄 수 있는데, 이것은 무엇을 해야 하는지에 대한 제안이다.대체로, 나는 주제별로 분류하는 것이 날짜별로 분류하는 것보다 문제가 해결될 수 있는 더 좋은 기회를 준다고 생각한다.aecis^Brievenbus 13:11, 2007년 11월 22일 (UTC)[응답]

럭비를 예로 들어보자, 내가 위에서 말한 것을 더 자세히 설명하기 위해서.12개의 럭비선수 전기에서 1년의 생년월일이 실종되었다고 말한다.럭비에 대해 아는 사람이 이 기사들 중 하나를 우연히 발견하게 될 가능성은 작지만 럭비에 대해 아는 사람이 이 문제를 가지고 두 번째 기사를 찾을 가능성은 카테고리의 수만 가지 기사 중에서 다음과 같다.생년월 실종은 나머지 10개 기사는 말할 것도 없고 영(0)이다.만약 12개 조항이 (광학명칭) 범주로 분류된다면 문제가 해결될 가능성은 실질적으로 더 크다.럭비선수들의 출생연도가 실종되었다.aecis^Brievenbus 13:23, 2007년 11월 22일 (UTC)[응답]

포럼과 같이 구성된 토크 페이지

여러 개의 스레드에서 동시에 방대한 양의 데이터를 생성하는 매우 활발한 대화 페이지에서 나온 나 자신도 한동안 간단한 코드 구현을 통해 대화 페이지를 실제 포럼처럼 구성해야 한다고 제안하는 것을 고려하고 있었다.대화 페이지를 클릭하면 마지막 게시 날짜(스레드 제목 옆에 언급된 날짜)별로 정렬된 테이블의 스레드 제목이 표시되며, 읽을 스레드를 클릭하십시오.이것은 특히 이것처럼 활동적인 토크 페이지들을 위해 동료 편집자들을 인용할 수 있는 적절한 인용 장치는 말할 것도 없고, 더 나은 우선 순위 분류 시스템을 가진 훨씬 더 효율적이고 읽기 쉬운 시스템일 것이다.서명이 부족하거나 게시물마다 박스가 있는 포럼 같은 테이블을 도입하여 모든 사람이 더 많은 일에 집착하는 것은 아닌 것처럼 사람들의 게시물을 구분하려고 노력함으로써 우리에게도 서명이 부족한 문제를 덜어줄 것이다.게다가, 응답하지 않는 스레드가 단순히 목록 아래로 미끄러져 내려가기 때문에, 아카이빙은 오히려 헛된 결과를 초래할 것이다. --Tlatosmd (talk) 00:42, 2007년 11월 20일 (UTC)[응답]

그런 일이 생긴다면 내 편집의 끝을 알 수 있을 것 같다.위키피디아의 강점 중 하나는 과대평가된 레이아웃과 (당신이 언급하는 그런 볼품없는 인용문 등)의 완전한 부재다.현재의 시스템은 우리에게 완벽하게 도움이 되고 항상 그렇게 해 왔다; 그것은 전적으로 우리의 편집과 보관 관행에 적합하고 본능적으로 복잡하지 않고 단순하다.아드리안 M. H. 00:58, 2007년 11월 20일 (UTC)[응답하라]

진심이야?이 문제는 위키피디아가 상징하는 어떤 것과도 전혀 무관하며, 이것은 단지 더 편리하고, 더 좋고, 더 깨끗한 포맷이고, 더 읽기 쉽다는 것에 대한 질문일 뿐이다.매일 5개, 10개 또는 그 이상의 스레드가 시작되는 매우 활동적인 토크 페이지에서는 쉽게 파악이 되지 않는다. --Tlatosmd (토크) 01:21, 2007년 11월 20일 (UTC)[응답]

물론 나는 진지하다.이 우스꽝스러운 생각은 그것이 보증하는 것보다 더 많이 제안되고 논의되었다.그것은 보기 흉한 형식과 열등한 사용성을 야기할 가능성이 높고 작업 관행과 상충된다.아드리안 M. H. 01:36, 2007년 11월 20일 (UTC)[응답하라]

동일한 모양과 느낌을 유지하면서 포럼 스타일의 특징을 추가하는 것은 꽤 가능하다; 위키피디아에서 사용하는 구현은 이것의 좋은 예다[4].개별 "스레드"는 여전히 대화 페이지로 작동하지만, 사용자에게 새로운 게시물이 있는 스레드까지 보여주는 모든 스레드 목록이 날짜 순서대로 제공된다.헬프 데스크와 참조 데스크가 그 시스템을 사용하도록 변환될 가능성이 작을 것 같다. -- DatRoot 01:33, 2007년 11월 20일 (UTC)[응답]

음, 물론 내가 생각하고 있는 것은 위키피디아의 기본적인 디자인 계획을 따르고 그것이 당신이 문제를 겪고 있는 것인지 자세히 살펴보겠다.나는 그것이 어떻게 작업 관행이나 사용성을 손상시킬 수 있는지 도저히 알 수 없다. 내가 볼 수 있는 것은 지금과 비교해 많은 장점들이다.지금과 같은 방식으로, 그들은 누군가 너무 게을러서 그들을 위해 사용할 수 있는 개념을 생각해내지 못한 것처럼 보인다.위키피디아에 수년간의 기고 후에도, 나는 종종 며칠과 몇 주 동안 계속해서 그들에 참여한 후에 매우 활동적인 대화 페이지에서 완전히 빠져드는 나를 발견하곤 하는데, 반면에 항상 완전히 보이는 섹션과 스레드를 자동으로 그리고 수동으로 검색해야 하는 필요성은 (실드 타이틀만 보여주는 대신에) 매우 산만하다.ve와 불편함. --Tlatosmd (대화) 01:41, 2007년 11월 20일 (UTC)[응답하라]

현재의 형편없는 미디어위키 토론 시스템을 어떻게 완벽하다고 할 수 있을까?새로운 사용자들에게 "직책에 서명"하도록 훈련시키는 동안 수천 시간을 소비했고, 멍청한 컷 앤드 페이스트(cut-paste)로 토론을 보관하는 데 많은 노력을 기울였다(그리고 대부분의 다른 프로젝트에는 "bots xx and yy"가 없기 때문에 "bots xx and yy"라고 말하지 말라).일부 사용자가 마지막 섹션을 편집하여 새 섹션을 시작하지 않도록 하십시오(결과 편집 요약이 잘못됨).포럼 페이지의 특정 섹션(일명 스레드)을 "관심"할 수 있기를 원한다; 다른 사용자의 게시물을 편집하는 사용자들은 괜찮지만, 이 편집에 특별한 깃발이 있어서 모든 디프피를 확인할 필요가 없다. 2007년 11월 20일 (UTC)[응답]

논의되고 있는 특성은 존재한다."Liquid srads(액체 스레드)"라고 불리는데, Extension(확장)에 이에 대한 페이지가 있다.리퀴드스레드.그것을 위한 시험위키가 있고, 토론페이지와 연계되어 있지만, 위키피디아에 소개할 현황이나 계획이 무엇인지 모르겠다.-가드피움 07:36, 2007년 11월 20일 (UTC)[응답]

내가 제안하고 싶은 시스템 중 하나는 페이지 하단에 새 스레드를 배치해야 한다는 것을 확실히 하는 방법일 것이다. 또한 페이지 맨 위에 실수로 배치된 스레드를 사이펀으로 잘라내야 하는 보관 시 상당히 귀찮은 일 뿐만 아니라, 새로운 스레드를 보기 위해서는 페이지 맨 아래로 쉽게 이동할 수 있는 명백한 장점이다.페이지 전체를 스캔해야 한다는 광고. --Ferdia O'Brien (Talk) 02:22, 2007년 11월 21일 (UTC)[응답]

대화 페이지의 편집 버튼(관리자 제외)은 페이지 전체에서 개별 스레드에 대한 편집만 남겨두고 "새로운 토론 추가" 단추나 편집 및 + 단추 대신 다른 단추를 제거하십시오.TheGreatZorko (talk) 2007년 11월 22일 (UTC) 11시 14분[응답]

그러면 관리자만 a) 토크 페이지를 보관할 수 있고, b) 프로젝트에 포함하기 위해 토크 페이지에 태그를 지정할 수 있으며, c) AfD 결과 템플릿 등을 추가할 수 있으므로 좋지 않은 생각이 될 수 있다.케쉬 (대화) 2007년 11월 22일 12시 44분 (UTC)[응답]

내 경험상, 대개 IP주소를 통과하는 것은 오류를 범하는 등록회원과 대조되므로, 위의 아이디어를 사용할 수 있지만, 등록회원은 무엇이든 할 수 있는 자유가 있다(TheGreatZorko가 언급한 세 가지 일을 하는 등록회원이 될 것이기 때문이다).페르디아 오브라이언 (토크) 03:18, 2007년 11월 23일 (UTC)[응답]

다른 사용자가 사용자 페이지를 편집할 때 알림

사용자의 사용자 페이지가 "새 메시지" 표시기와 유사한 다른 사용자에 의해 편집될 때 표시기가 표시되도록 구현될 수 있는가?내 사용자 페이지는 며칠 전에 파괴되었고 얼마 후에야 알아차렸다.--Pusy Galore양(토크) 14:51, 2007년 11월 21일 (UTC)[응답]

나쁘지 않은 생각이야.해결책은 토크 페이지를 감시 목록에 유지하고, 자주 감시 목록을 확인하는 것이다.이것은 꽤 효과가 있다. 당신이 당신의 감시 목록을 계속 감시하는 한.그러나 최종 사용자의 관점에서 볼 때 귀사의 솔루션은 더 쉽다.아마도 그것은 '슈퍼워치리스트'의 일종으로 구현될 수 있을 것이다. 이 목록에는 기본적으로 사용자 페이지가 포함되어 있을 것이다.Bugzilla를 위한 것일 수도 있다.마르틴 회크스트라 (토크) 2007년 11월 21일 (UTC) 15:02 [응답]

곧 아카이브될 것 같지만 페이지 상단에 비슷한 주제가 붙어 있다.한 위키피디아는 사용자 스크립트까지 썼다.

/* 다른 사용자에 의해 사용자 페이지가 변경되는 경우 경고하는 스크립트.[[사용자:ais53]에 의해.메시지는 편집될 때까지 계속된다는 점에 유의하십시오. 사용자 페이지를 직접 만드십시오.*/   기능을 발휘하다 upm_checktheisme(xmlreq.) {   시합을 하다 잡동사니;   해보다   {     시합을 하다 에이드=xmlreq..반응하다텍스트.갈라지다('<rev user="')[1].갈라지다('"')[0];     만일(에이드!=wgUserName) 문서화하다.GetElementBy아이디('사이트 서브').innerHTML+="<div class='usermessage'"사용자 페이지가 "로 변경됨+       "<a href='/wiki/사용자:"+엔코드URI(에이드)+"'>"+에이드.갈라지다('<').합류하다('&lt;').갈라지다('>').합류하다('&gt;').갈라지다('&').합류하다('&amp;')+"</a"+       " (<a href='/wiki/Special:마이페이지''사용자 페이지, <a href='/w/index.php?title=사용자:"+엔코드URI(wgUserName)+"&#=마지막">"+        "마지막 변화"";   } 잡히다(잡동사니) {}; }   애드온로드 후크(기능을 발휘하다(){   시합을 하다 a = sajax_init_object();   a.개방된('GET', wg서버+wgScript 경로+'/api.php?action=query&prop=revisions=사용자:'+     엔코드URI(wgUserName)+'&rvlimit=1&rvppprop=user&format=xml');   a.보내다('');   a.온프레미스 체인지 = 기능을 발휘하다(){만일(a.레디스테이트==4) upm_checktheisme(a)}; }); 

그러나 위에서 지적했듯이 다른 해결책이 있다.푸치코 (토크-이메일) 2007년 11월 21일 (UTC) 15:27 [응답]

기본 페이지에 "오늘의 특집 목록" 추가 제안

위키백과 참조:오늘의 특집 기사 목록.

트랜스휴머니스트 09:57, 2007년 11월 22일 (UTC)[응답]

이것은 좋은 생각이다.그렇게 많은 리스트들이 나쁜 품질의 문제인 것이 도움이 될 것이다. 2007년 11월 22일(UTC) 10:01, 22 (응답)

제안

나는 위키피디아가 다음과 같이 말할 것을 제안한다.Billage Poople(제안)은 위키백과로 리디렉션되어야 한다.여기서 모든 논의가 진행되듯이, 그 기사는 필요없기 때문에 '마을 통통'(제안)이다.피드백 06:13, 2007년 11월 23일 (UTC)[응답]

통통하지 말고 마을 펌프를 말하는 거지?어쨌든, 난 동의해.이 펌프뿐만 아니라 모든 마을 펌프에 대한 토크 페이지...의 이유는 무엇인가? - Rjd0060 (토크) 06:16, 2007년 11월 23일 (UTC)[응답]

그래서 마을 펌프 자체에 대해 의논할 수 있는 거야?예를 들어, Village Pump 보관 관행에 대해 논의하기에 적절한 장소가 될 것이다(그리고 그러한 논의는 현재 거기에 있다).모두 WT로 리디렉션:그러나 VP는 WT와 마찬가지로 다음과 같은 의미가 있을 수 있다.A. --ais523 10:24, 2007년 11월 23일(UTC)

기사삭제

페이지를 이동할 때 체크박스 수명으로 기사의 Talk 페이지를 삭제할 수 있는 선택사항에 반대하는 사람이 있는가?나는 이것의 문제점을 보지 못했고 한 페이지가 삭제될 때마다 몇 초씩 절약될 것이다.(누군가가 이것을 벌레로 정한다고?어떻게 해야 할지 모르겠다.) -- 플라시보 효과 07:08, 2007년 11월 14일 (UTC)[응답하라]

• 그래, 반대하겠어.기사를 옮기는 동안 대화 페이지를 삭제해야 할 정당한 이유가 없다고 본다.두 사람은 연결되어 있고, 대화 페이지를 삭제해야 할 타당한 이유가 거의 없다. - Mgm^(talk) 09:20, 2007년 11월 17일 (UTC)[응답]
  • *stateed* 제안에 대해 Mgm에 동의하십시오.기사를 옮길 때 토크 페이지는 삭제해야 한다는 의견이 나올 수 있지만 극히 드물다.내가 할 수 있는 유일한 상황은 그 기사가 하지 않는 공격, 카피비오 또는 허튼소리로 구성된 토크 페이지가 토크 페이지에 있었던 유일한 내용이라는 것이다.하지만, "움직임"이라는 단어를 사용하는 첫 번째 문장 후에, 여러분은 "페이지가 삭제될 때마다 몇 초씩 절약될 것이다."라고 말한다.기사를 삭제할 때(이동하지 않을 경우) 기사의 토크 페이지를 자동으로 삭제할 수 있는 관리자용 체크박스를 의미하셨습니까?CSD G8에 따라 기록되지 않은 삭제 토론이 포함된 대화 페이지를 보관하는 상황이 여전히 존재하지만, 그것은 어느 정도 장점이 있다.만약 당신이 의도한 것이라면, 나는 그것을 지지하지만, 나는 "CSD G8 - 삭제되었거나 존재하지 않는 기사의 토크 페이지"와 다른 것을 체크할 때 토크 페이지 삭제에 대한 자동 삭제 요약을 입력해야 한다고 생각한다. 다른 확인란 옵션은 이동할 때 리디렉션이 생성되지 않도록 지정하는 것이 유용할 것이다.많은 움직임은 재연결되지 않아야 하는 믿을 수 없는 이름에서 온다.--Fuhgetaboutit (대화) 09:56, 2007년 11월 17일 (UTC)[응답]
    • 내가 한 말을 명확히 하자면, 기사를 옮길 때, 당신은 체크박스를 통해 토크 페이지를 이동할 수 있는지 아닌지를 선택할 수 있다.나는 이 기능을 기사 삭제에도 사용하고 싶다.(기사를 삭제할 때, 토크 페이지는 삭제 대상)플라시보 효과 (토크) 2007년 11월 17일 (UTC) 17:08[응답]
      • 나쁜 생각이야.우리는 관리자가 삭제하기 전에 대화 페이지를 읽기를 원한다 - 거기에는 삭제하지 않을 이유가 있을 수 있다.그러한 증거는 WP를 능가하는 이전의 AFD 증거를 포함하여 다양한 형태를 취할 수 있다.CSD#A7; 오래된 AFD에서 G4를 능가하는 보다 최근의 AFD; WP를 능가하는 다른 곳에서 유래한 텍스트를 사용하도록 허가한 주장 또는 증명:CSD#G12; 새로운 프로드를 파괴하는 "keep it" 또는 Oldprod 템플릿; 현재 버전이 파괴된 버전임을 보여주는 토론; 기타 세부 사항.기사를 삭제하기 전에 토크 페이지(및 모든 보관 파일)를 읽어 보십시오. 해당 페이지를 이미 로드한 경우 해당 페이지를 삭제하려면 두 번만 클릭하십시오.GRBERRI (대화) 2007년 11월 19일 (UTC) 16:10 [응답]
        • 관리자는 기사를 삭제하기 전에 토크 페이지를 읽었어야 한다.나는 AFD와 같이 페이지가 삭제될 것이 분명한 상황에서 말하는 것이다.그리고 그것은 디폴트로 꺼질 옵션이기 때문에, 나는 이것에 해를 끼치지 않는다고 본다.플라시보 효과 (토크) 2007년 11월 23일 (UTC) 18:20[응답]

호버 텍스트의 각주

둘째로, 호버 텍스트로 발톱 자재를 렌더링할 수 있는 능력에 대해 생각해 본 적이 있는가?나는 호버 텍스트에서 링크를 클릭하는 것이 가능하지 않을 것이라고 생각하지만, 그러한 경우, 당신은 평상시처럼 각주로 이동할 수 있다.이것은 또한 기사를 통해 앞뒤로 튕기는 것보다 참조 확인이 더 쉬워진다.—Twigboy 16:07, 2007년 11월 14일 (UTC)[응답]

흥미로운 아이디어인 것 같은데, 실행하기가 좀 더 복잡하고, 주의를 산만하게 할 수도 있다. -아이스웨지 03:34, 2007년 11월 15일 (UTC)[응답]

다시 말하지만, 나는 합리적인 해결책이 큰 어려움 없이 자바스크립트로 만들어질 수 있다고 생각한다.클릭 가능한 링크가 포함된 전체 HTML 툴팁도 조금 더 많은 작업을 할 수 있다. -- DatRoot 15:04, 2007년 11월 15일 (UTC)[응답]

여기 간단한 각주 텍스트를 툴팁으로 추가하기 위해 한 간단한 스크립트가 있다.(이거 문제 있으면 좀 봐줘 :) IE, 파이어폭스 & 오페라에서 나한테 효과가 있어.

// 각주 링크의 툴팁에 대한 각주 텍스트를 스크립팅 애드온로드 후크(기능을 발휘하다 refTooltips() {     시합을 하다 링클렘, linkHref, 노트엘렘;     // 각주 링크 목록 가져오기(모두 클래스가 있음: '참조')     시합을 하다 리필름 = getElementsByClassName(문서화하다.보디, "SUP", "참고");     을 위해(시합을 하다 i = 0; i < 리필름.길이; i++)     {         만일(링클렘 = 리필름[i].getElementsByTagName("a")[0])         {             linkHref = 링클렘.href;             // 링크 href에서 각주 ID를 가져오고 링크 도구 설명에 텍스트 내용 추가             만일(노트엘렘 = 문서화하다.GetElementBy아이디(linkHref.기판을 달다(linkHref.인덱스오프("#") + 1)))                 링클렘.칭호를 붙이다 = 노트엘렘.내부 텍스트    노트엘렘.텍스트 내용    "";         }     } }); 

-- DatRoot 16:04, 2007년 11월 15일 (UTC)[응답]

아주 간단하게, 멋지다.고마워!—Twigboy 22:27, 2007년 11월 15일 (UTC)[응답]

대본 좋네!나는 그것을 복사해서 "^"와 편지 링크를 벗겨내기 위해 약간 수정했다.아노미 14:27, 2007년 11월 16일 (UTC)[응답]

멋지다. 나는 이제 (원업맨십의 경우는 아니지만, 정직한!) 클릭 가능한 링크로 풍부한 html 툴팁을 만드는 대본을 만들었다.덧셈으로 사용할 수 있다.importScript("User:DatRoot/Scripts/RichRefTooltips.js");당신의 js파일로.현재는 베타 버전이지만 꽤 잘 작동하는 것 같다 -- DatRoot 19:19, 2007년 11월 18일 (UTC)[응답]

Ok는 잠시 그것을 무시한다, 그것은 오페라에서만 작동한다 (9.5에서 테스트됨) -- DatRoot 00:19, 2007년 11월 19일 (UTC) 2007년 11월 19일 (UTC) 지금 고정되었다고 생각한다 -- DatRoot 12:11, 2007년 11월 19일 (UTC)[응답]

WP 설치:POP은 이렇게 한다.-kslays (대화) 04:30, 2007년 11월 24일 (UTC)[응답]

삭제 또는 삭제 검토를 위해 문서의 색상 링크, 링크를 쉽게 추가하기 위해 하위 템플리트 추가

2부 제안:

1. 상태별 색상 링크 및 추가 링크:

• 활성 = 파란색(지금과 같음)
• 삭제 시 X로 나열됨 = 보라색 + 현재 XfD에 연결된 작은 위첨자 "AfD"(또는 기타)
• Deletion Review(삭제 검토)용으로 나열됨 = 진홍색 + 현재 DRV에 연결된 작은 위첨자 "DRV"(아마도 보라색이 더 좋을 것 같음)또 다른 것은?)
• 삭제됨 = 진홍색 + 지난 XfD에 연결된 작은 위첨자 "AfD"(또는 기타)
• 존재하지않았다 =빨간색(지금처럼)

위첨자 링크를 추가하는 것이 마음에 들지 않으면 다음을 고려하십시오.

1. 사람들이 WP 선호를 통해 위첨자 링크를 볼 수 있도록 허용(기본적으로 새로운 색을 볼 수 있음)
2. 사람들이 링크와 색상을 모두 선택할 수 있도록 허용(기본적으로 현재와 동일하게 표시)

2. 양식에 하위 템플릿 추가: {{subst:deletionlinks arctlename}}

출력(하위부가 아닌 동적으로 출력됨?【기사】 [#1 AfD에 대한 링크] [[DRV DRV에 대한 링크]] [[AfD #2 AfD 2]] (시간 순으로 연결)VfD와 같이 구식이지만 완전히 리디렉션되지는 않은 것들을 포함)

Wiki Project 구성 언어/전쟁 및 삭제 편집 예를 참조하십시오.

목적:

1. 워치리스트에 없는 경우 삭제될 기사를 훨씬 쉽게 알아차리고 삭제/삭제 토론에 쉽게 참여할 수 있도록 하기 위해
2. 기사가 삭제되었을 때 명확하게 하기 위해, 당신은 그것이 단지 끊어진 링크라고 생각하지 않고, 다시 만들기 전에 삭제 추론을 확인 할 가능성이 더 높다.
3. 삭제 참여 및 나열을 보다 쉽게 자동화할 수 있도록 하기 위해
4. 위의 페이지와 같은 삭제 정렬 페이지를 쉽게 유지 관리

고마워. 사이 에미리스 ¿?✍ 09:18, 2007년 11월 14일 (UTC)[응답]

흥미로운 아이디어지만 어떻게 구현될 수 있는지 모르겠다. --ais523 18:13, 2007년 11월 14일(UTC)

비록 그것이 편집자에게 매우 유용하게 들리지만, 나는 그것이 모든 사람들과 기사 공간에 있어서 정말 좋은 아이디어라고 생각하지 않는다.대신, 특정 페이지에 대한 링크를 강조하기 위해 AfD의 업데이트 목록을 사용한 사용자 스크립트가 순서대로 정렬되어 있어서, 기능을 원하지 않거나 필요로 하는 사람들은 이 스크립트를 받지 않을 수 있다.나는 그런 대본이 청록색으로 관리자 이름을 강조하는 대본과 비슷할 것이라고 생각한다.니힐트레스^{t.l} 22:58, 2007년 11월 14일 (UTC)[응답]

나도 대본을 쓸 만큼 흥미롭고 흥미롭다고 생각했다.스크립트는 적절한 링크에 CSS 클래스(현재 "redirect" 및 "deletion")를 추가하기만 하면 monobook.css를 편집하여 작업을 수행할 수 있다.[5]Anomie 06:03, 2007년 11월 15일 (UTC)[응답]

CSS도 포함시킬 수 있도록 해줄 수 있니?IIRC는 모노북.js 페이지에 쉽게 그것을 할 수 있는 방법이 있다.

혹시 '삭제되어 현재 비어 있음'과 'DRV 아래' 부분을 만들 수 있는가?내 추측으로는 이 두 가지가 코딩하기가 더 어려운 것 같지만, 만약 코딩이 된다면 모든 관련 링크를 덤프하기 위한 하위 템플릿을 만드는 것은 (?) 비교적 쉬운 확장일 것이다.고마워!사이 에브리시?✍ 2007년 11월 15일 (UTC) 23:28[응답]

이름을 바꿨는데 User:Anomie/linkclassifier.js.이제 CSS 규칙을 포함할 수 있습니다, 사용자:Anomie/linkclassifier.css."삭제됨"은 카테고리 외에 페이지 로그를 다운로드해야 하며, DRV는 DRV에서 모든 링크를 받아야 한다.다른 사람이 그런 것들을 하기 위해 비슷한 대본을 만들고 싶다면, 계속 해, 하지만 난 관심 없어.미안. AfD/DRV에 연결하는 것은 그렇게 어렵지 않겠지만, AfD/DRV 페이지가 이상하게 이름 붙여져서 실패한 경우가 있을 거야.아노미에 04:49, 2007년 11월 21일 (UTC)[응답]

고마워! DRV & 삭제된 기사들의 문제는 사용자 설명서가 아닌 서버 끝의 수정으로 해결될 수 있는 문제야?예를 들어, 날짜별로 로그를 대규모로 검색할 필요 없이 기사 이름에서 모든 afd/drv/etc를 찾을 수 있는 간단한 방법이 있도록...?사이 에브리시?✍ 02:38, 2007년 11월 24일 (UTC)[응답]

AfD/DRV 명명에는 두 가지 문제가 있는데, 바로 머리 위에서 생각난다.때로는 여러 개의 관련(또는 그다지 관련되지 않은) 기사가 한 개의 이름으로 나열되거나(예: 이) 기사가 여러 번 지명되어 후속 지명에 대한 새로운 이름을 얻게 되는 경우도 있다(예: 이 경우).만약 누군가가 정말로 이것의 일부를 처리하기를 원한다면, 나는 그들이 AfDed 페이지의 wikitxt를 다운로드하고 {{AfDM} 템플릿 구문을 구문 분석할 수 있을 것이라고 생각한다.DRV는 기사당 개별 페이지 의향조차 없기 때문에 더욱 어렵다.나는 또한 "DRV로부터 모든 링크를 얻는 것"은 또한 그 페이지에서 다른 위키링크가 DRV로 만들어지고 있다고 생각할 것이기 때문에 위의 내 진술이 틀렸다는 것을 방금 깨달았다.아노미야 23:13, 2007년 11월 24일 (UTC)[응답]

숫자가 필요하다.

우리 아이들은 지구상의 모든 것의 총수에 대해 항상 질문을 한다.전 세계에 석탄 화력발전소가 몇 개 있을까?야생에 얼마나 많은 호랑이들이 남아 있을까?지금 중국에는 얼마나 많은 사람들이 있고 매일 얼마나 많은 사람들이 태어나는가.아마존에 얼마나 많은 우림이 남아 있는지, 야생에는 얼마나 많은 황금 타마린이 남아 있는지.

당신의 출처에서 나온 모든 것에 대한 최신 집계를 주시고 그냥 번호로 불러 주시겠습니까?—서명되지 않은 의견을 69.230.57.250 (대화) 15:51, 2007년 11월 19일까지 추가하기

"What Wikipedia is not"의 여러 섹션에 따르면, 위키백과에 적합하지 않을 것이라고 생각한다. - Rjd0060 (talk) 15:55, 2007년 11월 19일 (UTC)[응답]

당신은 그들의 호기심을 지렛대로 삼아 그들이 좀 더 실질적인 정보를 읽도록 할 수 있다.레이먼드 아릿 (토크) 2007년 11월 19일 (UTC) 16:06[응답]

• 문제는 그러한 수치가 끊임없이 변하고 정보가 최신인지 알 수 없다는 것이다. - Mgm 18:47, 2007년 11월 25일 (UTC)[응답]

와... 사용자 플래그 10개가 잠재적으로 12개로 증가할 수 있음...

난 Special을 보고 있었어.WP 덕분에 사용자 수가 12개로 증가할 수 있는 10개의 사용자 플래그가 있다는 것을 알게 되었다.FLR! 등록되지 않은 사용자, 등록한 사용자, 자동 확인 사용자, 이메일 확인 등을 세면, 우리는 이제 14명(플래그 리브 포함 16명)의 개별 사용자 레벨이 된다!enwiki의 현재 액세스 수준 목록:

1. 미등록(애논)
2. 등록한
3. 오토콘 확증(4일)
4. 이메일 확인(계정에 유효한 이메일 주소 있음)
5. 봇스
6. 가져오기(터키에 가져오기를 사용하지 않는다는 점 때문에 더 나쁜 점만 제외하고, 우습게도 롤백 플래그를 만드는 것과 같다)
7. 관리자
8. 비크랏츠
9. 이사회 의결 관리자(다음 이사회 선출은 언제인가?)
10. 체크유저
11. 감독
12. Stewards(엔위키 특정 스테워즈 없음)
13. 창시자(짐보는 자신만이 가질 수 있는 자신만의 특별한 깃발을 스스로에게 주었다)
14. 개발자

내가 여러 토크 페이지에서 읽은 것을 보면, 사람들은 깃발/접근 수준이 너무 많다는 생각을 좋아하지 않는다.그렇다면 어떻게 하면 현재 깃발의 수를 줄일 수 있을까?내가 가지고 있는 몇 가지 아이디어는 다음과 같다.

1. Checkuser와 Superve를 하나의 플래그에 결합하십시오(일부 CU/OS에는 플래그가 1개뿐이므로 해당 사람들은 제거되거나 두 플래그 모두에 대해 신뢰할 수 있는 것으로 간주되므로 최선의 생각은 아닐 수 있음).
2. 쓸모없는 가져오기 플래그를 제거하십시오.
3. 이사 선거가 실제로 진행 중일 때만 BV 관리 플래그를 표시하십시오.
4. 짐보를 다시 엔위키 특정한 관리인으로 만들어라. 오직 자신만이 위키백디아 위키에 탑승할 수 있는 독점적인 깃발을 그에게 주기 보다는 말이다(스튜어드는 메타에 다른 스테워즈가 있는 것처럼 독점적이지 않다는 것을 의미한다.

그러면 anon, 등록, 자동 확인, 이메일 확인 없이 플래그가 6개로 줄어들게 된다.펑피카 21:00, 2007년 11월 22일 (UTC)[응답]

왜 깃발을 너무 많이 꽂는 것이 문제일까?Gracenotes^T § 21:06, 2007년 11월 22일 (UTC)[응답]

Checkuser 또는 감독 플래그가 신뢰할 수 있는 것으로 간주되는 것은 ArbCom에 달려 있다.어쨌든 그들은 완전히 별개의 도구들이다.수입은 쓸모없는 것이 아니며 가끔 발생한다.우리는 또한 사용자 그룹이 언제 표시되는지 선택하고 선택할 수 없다.내가 막연히 동의하고 있는 유일한 것은 짐보의 "창시자" 깃발은 메타에 있는 그의 깃발에는 중복되어 있기 때문에 제거해야 한다는 것이다.하지만 나는 그라세노테스의 말에 동의해, 뭐가 문제야?주요 (대화) 2007년 11월 22일 21:17 (UTC)[응답]

내가 본 유일한 문제는 깃발을 더한다는 생각만으로 많은 사람들이 강하게 반대하고 있다는 것을 관찰했다는 것이다.예:Wikipedia_talk:플래그 지정된_revisions/Sighted_versions/Archive_4#the_definition_ of..., 편집자 및 검토자 플래그가 추가되었다는 이유만으로 플래그 지정된 개정판 확장의 이행을 반대하는 일부 사람들이 있었다.여기서 (짐보의 깃발 말고는) 이런 논의를 하지 말았어야 했다고 생각하기 시작한다...펑피카 21:36, 2007년 11월 22일 (UTC)[응답]

• 왜 12가 너무 많은지 모르겠어. 120은 또 다른 문제야.압도적이지 않다면 더 미세한 정보를 갖고 있는 것이 뭐가 문제인가?--피해자 포크는 00:11, 2007년 11월 23일 (UTC)[응답하라]
  • 깃발을 저장할 필요가 없다고 생각하십니까? 우리가 달성하고자 하는 것은?사용자당 몇 비트를 저장하시겠습니까?깃발이 우리가 특정한 문제를 해결하는 데 도움이 된다면, 왜 안 되는가?알렉스 바하레프 (토크) 2007년 11월 23일 (UTC) 00:21[응답]

• 좀 더 자세히 설명해 주시겠습니까?그 주제에 대해 잘 모르는데...하지만 내게는 사용자 깃발은 도구인 것 같고, 다양한 다양성을 갖는 것은 크기가 다를수록 더 유연해지는 것 같다. --빅토르 포크 03:25, 2007년 11월 23일 (UTC)[응답]

그것이 바로 내가 말하던 것이다.깃발의 수는 우리가 어떤 희생을 치르더라도 절약해야 하는 부족한 자원이 아니다.100개의 깃발로 시스템이 10개보다 잘 작동한다면, 2007년 11월 23일 (UTC) 05:53, 100개의 알렉스 바하레프 (토크)로 하자[응답하라]

• 이러한 플래그의 전체 목적은 사용자 목록을 검색하기 쉽게 만드는 것이다.나는 그 깃발들 중 어떤 것도 갖지 않을 이유가 없다고 본다.모두 유익하다. - Mgm 18:35, 2007년 11월 25일 (UTC)[응답하라]

사용자 대화

사용자들의 대화 페이지는 대화를 추적하는데 끔찍하다.우리가 위키피디아를 페이스북과 유사한 수동 "벽대벽"으로 만들 수 있는 방법이 있을까?피드백 07:33, 2007년 11월 25일 (UTC)[응답]

페이스북은 잘 모르지만, 위키피디아에서 대화 페이지를 바꾸는 것에 대한 논의가 있다:mw:확장:리퀴드스레드. -- 존 브로튼 (리퀴드) 2007년 11월 25일 (UTC) 19:16, 25 (응답)

새로운 위키프로젝트 제안

노화에 관한 기사를 보면 현재 위키프로젝트 생물학의 일부임을 알 수 있을 것이다.그러나 이것은 분명 학제간 주제일 것이고 사회학, 심리학, 기술, 법률, 종교학 분야의 종사자들은 모두 노화 연구에 공헌할 수도 있다.사실 나도 이 글을 꽤 편집해 보았지만, 내 배경은 생물학이 아니라 심리학이다.새로운 위키프로젝트인 위키프로젝트 게론톨로지 제안을 할 수 있을까?만약 어떤 사람이 노인학에 관한 기사를 보고 그것의 토크 페이지로 간다면, 사람들은 이것이 몇몇 위키프로젝트의 조사 하에 있다는 것을 알게 될 것이다; 위키프로젝트 노인학을 갖는다는 것은 동일한 위키피디아 팀이 이것과 노화에 관한 기사 모두를 볼 수 있다는 것을 의미할 것이다.ACEOREVIVEED (토크) 2007년 11월 25일 (UTC) 19:59 [응답]

WP에서 제안할 수 있다.Council 또는 그러한 노력에 관심이 있는 편집자가 충분할 경우, 당신은 대담하고 간단하게 페이지를 작성할 수 있다.세피로 BCR 20:07, 2007년 11월 25일 (UTC)[응답하라]

위키백과 위키백과일제 제안

'이 사용자의 Wikiage는 x년, y개월, z일'이라는 텍스트로 사용자 박스가 가능한지 궁금했는데, 여기서 x, y, z는 사용자가 Wiki를 처음 편집한 날짜와 현재 날짜 사이에 계산한 연령을 기준으로 일부 프로그램을 사용하여 각 사용자에 대해 계산해야 할 숫자다.만약 사용자 박스가 가능하지 않다면, 그런 종류의 다른 무언가가 사용자의 대화 페이지에서 사용자의 위키피지를 보여주는 것이 좋을 것이고, 나중에 우리는 사용자의 위키피디데이(실제 생일을 대신하는 것)를 축하할 수 있을 것이다.나는 이 조치가 지역사회에 더 많은 조화를 가져올 것이라고 확신한다.DSachan (대화) 2007년 11월 25일 (UTC) 20:19, 응답

사용자 상자 템플릿:생일과 함께 사용되는 사용자 현재 연령. 그러나 생일과 함께 사용할 경우 Wikiage를 포함하도록 변경할 수 있다.레이와스92^Talk 20:29, 2007년 11월 25일 (UTC)[응답]

감독 로그

관리자는 삭제된 페이지 수정사항을 볼 수 있다.나는 그들이 감독에서 삭제된 수정본의 삭제 로그(문자 또는 기타 정보는 아님)도 볼 수 있도록 제안하고 싶다.관리자들은 감독 내용을 볼 필요는 없지만, 책임감과 투명성을 위해 감독이 발생했다는 사실을 이용할 수 있어야 한다.개정안이 지나치게 선견지명이 있었던 사실과 이유는 사생활 문제가 아니라 개정 내용 자체만 그렇다.따라서, 신뢰할 수 있는 사용자들이 누가 어떤 페이지를 넘나들었는지 알 수 있게 해도 해롭지 않다. --Hemlock Martinis (대화) 03:32, 2007년 11월 23일 (UTC)[응답]

훌륭한 아이디어! :) 위에 열거된 모든 이유들로 인해, 그리고 그것이 어떻게 프로젝트에 해를 끼칠지 알 수 없다.SQL^{Query me!} 03:40, 2007년 11월 23일 (UTC)[응답]

나도 동의해, 감독 목적으로, 관리자들이 무엇이 과시되고 있는지, 누구에 의해, 그리고 왜 이 중요한 도구가 잘못 사용되고 있는지 확실히 하기 위해 (말장난이 의도되지 않은) 로그를 감독할 수 있도록 하는 것이 좋을 것 같아. --krimpet⟲ 03:44, 2007년 11월 23일 (UTC)[응답]

나도 동의해.나는 이것이 해롭지 않고 도움이 되는 것으로 볼 수 있다.Lara novemberLove 03:49, 2007년 11월 23일 (UTC)[응답]

많은 감독들이 합법적이고, 필요하며, 오버파이터들의 토크 페이지에 쏟아지지 않아야 한다는 이해와 함께, 몇몇 견제와 균형이 형편없지는 않을 것이다.Gracenotes^T § 03:51, 2007년 11월 23일 (UTC)[응답]

• T14069 Mercury 03:58, 2007년 11월 23일 (UTC)[응답]

나는 내가 이것이 나쁜 생각이라고 믿는 많은 이유를 가지고 있다.하지만 난 지금 당장 자러 가야 해.의논은 남에게 맡긴다캐리 베이스 04:20, 2007년 11월 23일 (UTC)[응답]

당신이 들어오면, 그 이유들 중 몇 가지를 우리와 공유해 주시겠습니까? :) 적어도 하나는 민감한 데이터를 포함할 수 있는 '과잉 이유'라고 추측한다.여기 내 시험 위키에 나온 것 같은 로그가 있어, 누가 궁금하다면.(세부사항) (diff) 07:03, 2007년 11월 22일 MySQL이 페이지 (이유) SQL^{Query me!} 04:26, 2007년 11월 23일 (UTC)[응답]에서 편집 삭제됨

캐리가 내일 설명해야 하는 이유 때문에(그, Pathoschild, MZMcbride, 그리고 나는 이것에 대해 아주 오랫동안 토론했었어...) 나는 우리가 이것을 필요로 할 이유가 없다고 본다.사용자가 자신을 감시할 수 있으며 이는 유익함보다 더 많은 위해를 일으킬 가능성이 크다(그가 내일 설명할 이유 때문에).Cbrown1023 talk 04:31, 2007년 11월 23일 (UTC)[응답]

나는 이런 걱정들을 볼 수 있기를 기대한다.버그 보고서를 검토하지 않은 사용자:개발자인 Tim Starling은 "로그의 페이지 제목과 사용자 이름에는 제거되고 있는 개인 데이터가 포함될 수 있다"고 말했다.궁금한데, 사용자 생성 로그에 이 사용자 이름이 표시되지 않을까?블록 로그는?로그 삭제?삭제된 페이지 제목은 어떠세요?삭제된 경우 삭제 로그에 계속 표시되는가, 지나치게 주의하기 전에 삭제된 경우에는 삭제 로그에 삭제된 삭제 로그가 여전히 표시되고 있는가?Special은?새 페이지?SQL^{Query me!} 05:00, 2007년 11월 23일 (UTC)[응답]

문제 텍스트가 공개 로그에 나타나면 해당 로그 항목은 영구히 삭제된다.우리는 현재 로그 항목을 보관하는 방법을 가지고 있지 않다. -- Tim Starling (대화) 05:19, 2007년 11월 23일 (UTC)[응답]

몰랐네, 입력 고마워! : :) SQL^{Query me!} 05:22 (UTC) 2007년 11월 23일 (UTC)[응답]

나는 버그 리포트에 대한 반응이 가장 좋은 이유였다고 생각한다.;) Mercury 04:40, 2007년 11월 23일 (UTC)[응답]

• 강력한 지원 중립 투명성, 2007년 11월 23일 (UTC) 05:35, 승리자 포크[응답]

나는 이것의 이유를 모르겠다.관리자들은 감독 대상자들을 "지나치게" 할 필요가 없다.그게 무슨 소용이야?관리자가 감독 문제에 대해 문제를 가지고 있다면, 사람이 할 수 있는 일은 아무것도 없다.감독관은 감독 일지를 볼 수 있는 능력을 가지고 있고, 그들은 서로를 "상관"한다.감독절차는 가능한 한 비밀로 해야 하며(분명히 숨겨진 맥락과 숨겨진 기여가 있었다는 사실 포함), 1500++++의 사람들이 이러한 거래를 볼 수 있도록 허용하는 발상은 IMO, 끔찍한 발상이다. - Rjd0060 (대화) 05:57, 2007년 11월 23일 (UTC)[응답]

편집한 날짜와 편집한 날짜를 지나쳐 보는 사람이 있을 뿐이었죠.그게 다야.관리자들은 여전히 편집 내용에서 격리되어 사생활이 보호될 것이다.그것이 전부이다, 그저 그뿐이다.누가 무엇을 지나치게 보는지는 문제가 없다고 본다. --Hemlock Martinis (대화) 06:32, 2007년 11월 23일 (UTC)[응답]

나는 아직도 행정가들과 지역사회가 이것에 의해 어떤 이익을 얻을지 이해할 수 없다. - Rjd0060 (대화) 06:34, 2007년 11월 23일 (UTC)[응답]

투명성 증대?Durova AN/I 하위 페이지는 부적절하게 과시를 하는 섹션이 있다; 만약 우리가 그것을 하는 사람을 볼 수 있다면 이런 일은 일어나지 않을 것이다. --Hemlock Martinis (대화) 06:42, 2007년 11월 23일 (UTC)[응답]

숨은 기여금 본문을 볼 수 없는 경우, 어떤 것이 부적절하게(또는 제대로) 과시관념이 있는지 어떻게 알 수 있는가? - Rjd0060 (대화) 06:49, 2007년 11월 23일 (UTC)[응답]

그럴 리 없겠지만 적어도 누구한테 물어봐야 할지는 알 것 같아. --Hemlock Martinis (대화) 06:51, 2007년 11월 23일 (UTC)[응답]

숨겨진 수정안에 무엇이 들어있었는지 모른다면, 당신은 그것이 부적절한 감독 사용이라고 생각할 이유가 없을 것이기 때문에, 누구에게 물어볼 이유도 없을 것이다.매번 실수가 있을 때마다 개인적으로는 그것이 제대로 된 것이었음을 보여줄 만한 세부사항이 없다고 생각하고 있지 않다면, 왜 그랬는지 물어보기 위해 그것을 한 사람의 페이지에 나타날 수 있다.ElinorD (대화) 2007년 11월 23일 11:41, (UTC)[응답]

흐음, 찬성보다 반대 의견이 더 강한지 더 생각해봐야겠어.그러나 그것은 quis 관리형 ipsos 커스터드의 경우인데, 점점 더 불투명해지는 계층의 층마다 층을 추가하는 것은 최대한 피해야 할 일이다; 대중의 눈은 좋은 행동을 보장하는 최선의 방법이다.감독관이 정확히 누구야?--피해자 가짜 06:28, 2007년 11월 23일 (UTC)[응답하라]

그 질문의 의미는 확실하지 않다.나는 알고 있다(WP:감독관리는 감독 권한을 가진 모든 사람의 감독 행위를 볼 수 있는 능력을 가지고 있고 (그리고 나는 그들이 그렇게 한다고 확신한다) 그리고 그것은 사다리로 올라간다(즉 그들이 감독권을 취소할 수 있기 때문에 나는 Stewards가 감독 활동을 감시할 것을 확신한다).- Rjd0060 (대화) 06:33, 2007년 11월 23일 (UTC)[응답]

나는 그들이 지역 감독권을 가져야 하기 때문에 그들이 그렇게 하는 것이 의심스럽다. 그리고 나는 관리인이 항상 최소한 두 개의 감독(및 점검 사용자)이 있기 때문에 로그를 확인하는 것만으로 스스로 감독권을 부여해야 하고, 따라서 서로를 감시해야 하는 시나리오가 있는지 의심스럽다.이 제안에 대해 나는 관리자가 로그를 볼 수 있어야 한다는 것에 동의한다.그러나 때로는 버그 리포트에서 말한 것처럼 통나무에서 드러난 것은 제거해야 할 사항이고, 다른 사람으로부터 그것들을 걸러낼 방법이 없기 때문에 나는 그 문제를 거기서 본다.나는 또한 Checkuser 로그를 볼 수 있는 것을 포함시키는 것이 좋을지 궁금하다(분명 IP가 아닌 것임).I (대화) 06:44, 2007년 11월 23일 (UTC)[응답]

"편집자가 자격이 없는 수정사항을 숨김으로써 감독을 남용한 경우" 권한을 취소할 수 있다는 점을 고려하면, Stewards가 로그를 볼 수 있을 것이라고 확신한다. - Rjd0060 (대화) 06:52, 2007년 11월 23일 (UTC)[응답]

그렇다, 하지만 나는 감독 허락을 취소하는 권한은 스튜어드가 아니라 그들에게 권한을 부여한 사람들(즉, ArbCom이나 지방 선거)에게 있다고 믿는다. 그리고 다른 감독관은 아마도 지역 사회/아브컴에게 부정행위에 대해 경고할 것이다. 스튜어드 비트는 감독 기록을 볼 수 없고 감독만이 할 수 있기 때문에, 스튜어드 비트는 기능사일 뿐이다. 나는 이런 것들이 아니기 때문에 잘 모르겠지만, 그것이 내가 믿게 된 것이다. Redex에게 물어보면 되겠네. 그는 감독관이고 관리인이니까. 감독 페이지에서 취소 섹션을 읽은 후, 나는 당신이 Stewards가 자체 인식으로 감독 비트를 제거할 수 있다고 말한 것이 옳다고 본다.이것은 내 마음속의 m:Steward 정책과 모순되는 것 같다.그래도 리덱스한테 물어봐야 할 것 같아.I (대화) 2007년 11월 23일 07:19 (UTC)[응답]

햇빛은 최고의 소독제다.감독 조치를 더 잘 감시할 수 있게 한 것이 뭐가 문제인가? --Hemlock Martinis (대화) 06:42, 2007년 11월 23일 (UTC)[응답]

이 정보(감독 로그)로 무엇을 하시겠습니까?- Rjd0060 (대화) 06:49, 2007년 11월 23일 (UTC)[응답]

오용 및/또는 오용이 있는지 확인하십시오. --Hemlock Martinis (대화) 06:51, 2007년 11월 23일 (UTC)[응답]

제거된 것을 모르면 할 수 없다.ElinorD(대화) 11:41, 2007년 11월 23일 (UTC)[응답하라]

삭제 로그도 마찬가지지만.페이지의 삭제 로그에서 삭제/부분 복구 상황을 보는 편집자는 무엇이 삭제되었는지 모를 수 있지만, 문제가 있는 경우 관리자에게 수정본이 삭제된 이유를 물을 수 있다.Gracenotes^T § 2007년 11월 23일 (UTC)[응답]

엄밀히 말하면, 이것은 stewards "job"이다. - Rjd0060 (talk) 06:53, 2007년 11월 23일 (UTC)[응답하라]

이것은 한 번에 모든 사용자가 이용할 수 있었는가?위키백과 대화 참조:감독#오버사이트 로그 - Rjd0060 (대화) 07:00, 2007년 11월 23일 (UTC)[응답]

(u)아니, AFAIK, 해지 자체가 스테어워드 작업이다.그리고 당연히 그렇다.그럼에도 불구하고, 왜 더 큰 그룹은 감독 조치를 검토할 능력이 없어야 하는가?'크리스틱스'라면 괜찮을까?난 아무거나 상관없어, 같은 소그룹 리뷰에 의해 임명되지 않은...SQL^{Query me!} 07:24, 2007년 11월 23일 (UTC)[응답]

이 "같은 소그룹"은 지역사회에서 선출된 그룹이다.ElinorD(대화) 11:41, 2007년 11월 23일 (UTC)[응답하라]

관리자도 그렇고, 크랫도 그렇고...SQL^{Query me!} 06:43, 2007년 11월 24일 (UTC)[응답]

나는 이것이 앞으로 나아가서는 안 될 진짜 이유를 모르겠다.명백히, 개발자들은 공공 로그에 있는 것들을 제거하기 때문에, 감독 로그에서 사적인 것은 아무것도 드러나지 않을 것이다.그것을 적절하게 사용하고, 보수적으로 논평하라. 위키백과의 수정사항을 영구히 삭제하는 이 과정에서 내가 투명하지 않을 이유가 없다.SQL^{Query me!} 07:27, 2007년 11월 23일 (UTC)[응답]

이것은 감독 통계가 한 때 완전히 공개되었던 것처럼 보이게 한다.나는 단지 1500명의 사람들이 일어나는 기밀 거래를 볼 수 있도록 허용하는 것에 문제가 있다.나는 그들이 실제의 맥락이 숨겨져 있는 것을 볼 수 없을 것이라는 것을 알지만, 나는 여전히 그것이 내려가기에는 좋지 않은 길이라고 생각한다.크래트가 로그를 볼 수 있도록 하는 것에 대해서는, 나는 여전히 지역적이기 때문에, (스티워즈가 어디에나 있는 것과는 대조적으로) 나의 예약을 하고 있지만, 그 수가 적다는 것을 고려하면, 나는 그것이 가능할 것이라고 생각한다.날짜, 시간, 코멘트만 들어 있는 로그 자체도 소수의 사람들에게 더 잘 알려진 정보를 담을 수 있었고, 이전에도 "루지 관리자"가 있었다.나는 "불량자/스튜어드"가 있었다고 생각하지 않기 때문에, 나는 관리자보다 그들을 더 신뢰하고 싶다. (우리의 위대한 관리자들에게 악의는 없다.)- Rjd0060 (대화) 07:32, 2007년 11월 23일 (UTC)[응답]

끔찍한 생각이야.언제, 어디서 감시를 사용했는지 아는 것 만으로도 비침습자가 알아야 할 것보다 더 많은 정보가 될 수 있다.존 리브스209.159.32.50 (대화) 07:35, 2007년 11월 23일 (UTC)[응답]

SPA. - Rjd0060 (대화) 07:37, 2007년 11월 23일 (UTC)[응답]

네가 체크유저였으면 좋았을 텐데 내가 사용하는 IP를 보고 선의로 네가 얼마나 멍청해 보이는지 알아봐줘존 리브스 07:40, 2007년 11월 23일 (UTC)[응답]

뭐라고?인신공격일까?나는 선의라고 단정하는 것이 아니라, 사실, 나는 이미 양말을 사용했다는 비난을 받았기 때문에, 그리고 이것에 반대하는 유일한 사람이기 때문에, 나는 더 이상 고발을 하지 않을 것이라고 덧붙이고 있었다. - Rjd0060 (대화) 07:42, 2007년 11월 23일 (UTC)[응답]

너도 내가 그것에 반대했다는 것을 알게 될 거야.존 리브스 07:45, 2007년 11월 23일 (UTC)[응답]

응, 방금 봤어.하지만 너는 여기서 내 요점을 깨달아야 해.관리자의 인신공격은, 더 잘 알아야 한다.심지어 ArbCom에도 출마하셨고요.흠. - Rjd0060 (대화) 07:46, 2007년 11월 23일 (UTC)[응답]

나는 "당신이 AGF를 하지 않을 때 당신은 얼간이처럼 보인다"라는 에세이를 써야 할 것 같다.그것은 단순한 진술이고 AGF에 대한 격려이지 공격이 아니다.이 모든 것이 지금 주제에서 벗어났어...존 리브스 07:56, 2007년 11월 23일 (UTC)[응답]

• 강한 반대다.누가 잘못을 저질렀는지 아는 것은 우리가 무엇이 제거되었는지 알지 못하는 한 그것이 학대였는지 아는 데 도움이 되지 않을 것이다.우리가 무엇이 제거되었는지 안다고 해도, 우리는 그 이유를 이해하지 못할 수도 있다.우리는 확실히 사용자의 사생활을 보호하기 위해 어떤 것을 지나치게 선견지명이 있고, 그들의 토크 페이지에 그것에 대한 질문들로 넘쳐나는 상황은 필요하지 않다.최근 블랑구옌이 올린 e-메일을 오버래핑한 경우, 애초에 해당 e-메일이 게시되지 말았어야 했다.그리고 Blnguyen은 즉시 나서서 자신이 그것을 과시하는 사람이라고 말했다.그래서 통나무를 갖는 것은 도움이 되지 않을 것이다.만약 사람들이 제거하기 전에 이미 그 내용을 봤고, 그것이 지나친 관점을 갖지 말았어야 했다고 생각한다면, 그 내용에는 그들이 이해하지 못한 극도로 민감한 정보가 들어 있었을 가능성이 있다.만약 그것이 잘못된 감독 사용이었다면, 그것은 학대하지 않았을지도 모른다.오버사이터는 결정을 내려야 하고, (IAR은 말할 것도 없고) 국경선 사례가 많아야 한다.진정으로 폭력적인 오버 세일러는 그들의 동료나 개발자들에 의해 곧 발견될 것이다.만약 내가 FloNight가 감독을 남용했다고 생각하는데, 맥켄슨이 그녀가 하지 않았다고 나에게 확언한다면, 나는 더 이상의 세부사항을 알지 못한 채 그것을 받아들이게 되어 매우 기쁘다.우리가 절대 원하지 않는 것은 누군가가 실수로 자신의 전화번호를 올리고 이를 감독한 다음 5, 6명의 관리자(사용자 17명 뒤이어)가 자신의 토크 페이지에 나타나 왜 그것을 과시하는지를 요구하는 상황이다.또한, 어떤 경우에는 어떤 페이지가 과시, 누구에 의해, 그리고 언제인지를 보고 그 정보가 무엇인지를 추측할 수 있을 수도 있다.ElinorD (대화) 2007년 11월 23일 11시 59분 (UTC)[응답]

이런 일은 현실적으로 불가능할 것 같다.편집 내용은 편집 내용만이 아니라, 편집한 페이지 이름 때문에 편집이 충분히 과시되는 경우가 많다.그것은 사생활 문제다.사생활/리벨 위반이 페이지명에 직접 기재되어 있지 않은 다른 경우라도, 글과 이유를 자주 아는 것은 그것이 무엇이었는지를 유추하기에 충분하다(두말할 필요도 없이, 감독할 가치가 있다고 판단되면 좋지 않다).어쨌든, 나는 이 제안이 해결되는 어떤 문제도 없다고 본다.감독 책임성이 문제라고 가정할 때, 로그를 볼 수 있지만 실제 과시 편집은 볼 수 없다는 것은 그 문제를 다루지 않는다. 왜냐하면 외부인이 감독 결정이 좋은지 아닌지 추측할 만한 충분한 정보가 없기 때문이다.Dmcdevit/t 12:13, 2007년 11월 23일 (UTC)[응답]

• 제한된 지원.나는 이 제안서의 한정된 버전을 지지한다.기존 페이지에 일부 수정사항이 있는 경우, "이 페이지의 일부 수정사항이 감독으로 제거되었을 수 있다"는 짧은 메모가 기록 보기에 나타나며, 이는 삭제된 수정사항에 대한 메모와 동일한 방식으로 관리자에 대해 표시된다.또는 Special:에 나타날 수 있다.삭제 취소어느 쪽이든, 그 목적은 관리자들에게 역사관에 예기치 않은 공백이 있을 수 있다는 것을 알리는 것이다; 편집 이력의 무결성과 편집의 정확한 귀속성을 유지하기 위해 일반적으로 오버파이터만큼 많은 주의를 기울이는 것은 때때로 이것이 완전히 가능하지는 않다.이러한 경우, 조사 관리자는 명백한 이력 공백과 그에 상응하는 삭제된 수정 사항이 없기 때문에 결국 감시가 사용되었을 것이라고 판단할 수 있지만, 이는 시간이 걸리고 상당한 혼란을 초래할 수 있다.감시가 적용되었을 수 있다는 간단한 메모는 이러한 혼란을 줄이고 관리자가 페이지 내력을 추가로 조사할 필요가 있을 경우 해당 담당자에게 연락할 수 있게 해준다.(사실 같은 이유로 해당 페이지가 삭제되거나 오버시되는 경우 비관리자에게도 이력 뷰에서 유사한 메모를 지원할 수도 있다.삭제된 버전)나는 또한 감독 인터페이스에서 이 통지조차도 과도한 정보가 유출될 수 있는 경우에 억제할 수 있는 옵션을 지지한다.—일마리 카로넨 (대화) 2007년 11월 23일 12시 30분 (UTC)[응답]

이것은 매우 합리적인 제안이다.나는 이것을 지지할 것이다.카차롯 (대화) 2007년 11월 23일 (UTC) 12시 34분[응답]

나 또한 이것이 합리적인 접근법처럼 보인다는 것에 동의한다.여기서 일부 사람들이 놓치고 있을 것이라고 생각하는 것은 (내 의견으로는) 역사표에는 어떤 청렴성이 있다는 것이다.이 역사를 수정할 수 있다는 믿을 수 없을 정도로 신뢰받는 사람들이 아주 한정되어 있고, 그럴만한 이유가 있다.페이지 이력은 법률적, 윤리적 이유 모두에 따라 수정하기는 어렵다.이러한 내용을 수정(또는 변경)한 경우, 그 효과에 대한 통지가 적절할 수 있다. --MZMcBride (대화) 2007년 11월 23일 (UTC)[응답]

문제는 현재의 시스템이 충분히 투명하지 않다는 점이다.필요한 것은 남용될 수 있는 경우에 사람들이 감독에 대한 검토를 요청할 수 있는 공식적인 시스템이다.그러기 위해서는 감시가 이뤄졌는지 알 필요가 있다.현재 위키에 게시된 자료는 이를 알고 인터넷 접속을 할 수 있는 모든 사람이 볼 수 있다.자료는 다음과 같을 수 있다: (a) 편집에 의해 제거(페이지 기록에 남아 있음 - 이를 알고 있는 모든 사람이 액세스할 수 있음); (b) 페이지 수정본을 삭제하여 제거(관리자는 이러한 삭제된 수정본을 볼 수 있으며, 페이지 기록에서 이러한 삭제가 수행되었음을 확인할 수 있음 - 비관리자가 볼 수 있는 것은 확실치 않음 - 나는 그들이 l에서 확인할 수 있다고 생각한다.동쪽은 여전히 개정판을 클릭해서 누락되었다는 말을 듣지만, 윗부분에서 무엇이 누락되었다는 단서를 얻지 못할 수도 있다; (c) 감독으로 인해 오버서터를 제외한 모든 자료에서 자료가 제거된다(관리자도 주변 환경에 상황적인 단서가 있을 수 있지만, 어떤 것도 변한 것을 보지 못할 것이다).텍스트); (d) 개발자 및 '루트' 액세스 권한을 가진 기타 사용자는 영구적인 제거에 영향을 미칠 수 있지만, 이를 방지하기 위한 점검이 시행되기를 바란다.

아무도 무슨 일이 일어났는지 알아차리지 못하는 것은 빠른 제거와 감독 사례에서 가능하다.많은 경우에 이것은 좋다.그러나 그것은 투명성에 대한 우려와 시스템 남용을 막을 방법에 대한 문제를 제기한다.문제의 일부는, 진정한 감시의 경우, 그 정보는 비밀로 유지되어야 하지만, 감독 남용 사례의 경우, 사생활에 대한 요구는 감독 시스템을 남용하는 모든 사람들을 돕는다.아마도 앞으로 나아가는 가장 좋은 방법은 모든 감독들을 두 번째 오버파이터에 의해 검토하도록 요구하는 것이다.그게 실현 가능할 것 같니?현재 시스템에 과부하가 걸릴까?카차롯 (대화) 2007년 11월 23일 (UTC) 12시 34분[응답]

나는 현재 바로 이런 이유로 특정 위키에 적어도 두 명의 오버래이터와 체크 유저가 있어야 한다고 믿는다. --MZMcBride (대화) 19:14, 2007년 11월 23일 (UTC)[응답]

• 강한 반대다.감독 기능이 구현되었을 때, 로그는 처음에 공개되었다.그리고 나서 우리는 이 모든 것이 사람들에게 거울, 덤프, 구글의 캐시 등에서 과도한 시각의 정보를 읽을 수 있는 페이지 목록을 주는 것이라는 것을 알게 되었다. 다시 말해, 그것은 실제로 득보다는 해를 끼치고 있었다.만약 우리가 감독 기능을 갖게 된다면(그리고 그것은 수많은 이유로 필요) 그것은 무엇이 제거되었고 왜 제거되었는지에 대한 공개 로그를 가질 수 없다.매슈 브라운 (Morven) (T:C) 17:12, 2007년 11월 23일 (UTC)[응답]

나는 많은 사람들이 특정 페이지 목록이 어떤 특정한 페이지인지/과시적이었는지 문제가 있다는 것을 인식하고 있다고 생각한다. 그래서 단순히 "사용자:John Q. Public overview 8:45 2006년 11월 9일" 그리고 그 이상 최악의 생각은 아닐 것이다.그냥 생각나는 음식. --MZMcBride (대화) 2007년 11월 23일 (UTC) 19:14, 응답하라.

• 강한 반대

이것은 전혀 실행 불가능한 제안이다.심지어 어떤 것이 지나치게 시시하다는 사실조차도 때로는 사적인 것으로 유지되어야 하는 것의 일부분이다.

우리는 로그의 페이지 제목과 사용자 이름에 제거되고 있는 개인 데이터가 포함되어 있을 수 있다는 것을 근거로 하여 감독 로그에 대한 액세스를 제공하지 않는다. - 팀 스타링.

그것보다 더 선명해지지 않는다.감독하기에 충분한(3)의 견제와 균형이 이미 존재한다.

• 우리가 가장 신뢰하는 기관인 ArbCom에 의해 감독 대상자가 선정된다.
• 감독하는 사람들은 서로를 검토한다.
• m:dv 공정

나는 이 제안을 즉각 거절할 것을 촉구한다.++Lar: t/c 20:43, 2007년 11월 23일 (UTC)[응답]

• 일마리 카로넨 당 제한된 지원.방대한 (십백 ) 편집 이력이 있는 페이지의 삭제 취소 작업을 해 본 적이 있는데, 삭제 로그에서 이전 관리자가 N+4 수정본을 삭제한 다음 즉시 삭제된 N을 삭제한 것을 본 적이 있는데, 이는 4가 보이지 않아야 하는 내용을 담고 있었기 때문이다.4개 수정안도 너무 많은 것을 알 수 있다면, 그것이 문제인지 확인하기 위해 몇 백 개 수정안을 시험하거나 무명을 통한 안전 보장을 바라는 것으로 허풍을 떨지 않아도 될 것이다.이것을 나에게 알려 줄 자료는 나의 목적을 위해 이것들은 삭제되지 않은 로그에 나타나야 할 지나친 관점의 개정에 대한 #와 타임스탬프다.그것은 그 기사의 삭제되지 않은 로그에 과대분전의 수정 횟수와 타임스탬프가 나타나도록 하는 것으로 충분할 것이다.GRBerry 21:16, 2007년 11월 23일 (UTC)[응답]

나는 이것을 지지할 생각이었지만, 모븐의 진술은 좋은 점을 제기한다.보통 누가 과반을 저질렀는지 다른 감독에게 물어보면, 그들은 또한 말할 것이다.투명성에 도움이 되겠지만 양날의 칼이 될 수도 있다.Kwsn (Ni!) 2007년 11월 23일 17:20 (UTC)[응답]

최소한 월별, 또는 연간 감독 조치의 수를 공개적으로 공개하는 것은 어떨까?숫자가 적은 것을 보면 안심할 수 있을 것이다. --코퍼트위그(토크) 01:26, 2007년 11월 28일 (UTC)[응답]

Real Soon Now에 나오는 텍스트/편집 요약/사용자 이름/ 등의 가시성을 세부적으로 제어할 수 있는 "개정 삭제" 기능에 대해 계속 듣고 있으며, 이 문제를 여기서 해결해야 한다.—Random832 15:08, 2007년 11월 28일 (UTC)[응답]