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

제안/RfC: ISBN 오류가 있는 기사 대화 페이지에 ISBN 경고 허용

내 봇을 이용해서 할 수 있어.WPCleaner에는 WPCleaner의 "ISBN 경고 메시지 업데이트"라는 기능이 있다.나는 약 2주 전에 이 기능에 대해 토론하고 있다.이 토론은 다음과 같은 위키백과의 대화를 찾을 수 있다.WPCleaner#ISBN 경고.해당 기사의 토크 페이지에 ISBN 경고 메시지를 추가하고 삭제하는 기능이다.ISBN에 영향을 미치는 이유를 알려주고 ISBN이 영향을 받는 이유도 알려준다.이것은 위키피디아 사람들이 영어 위키피디아에서 ISBN을 훨씬 더 쉽게 고칠 수 있도록 도울 것이다.템플릿은 User:현재 NicoV/ISBN 경고.템플릿으로이동해야 함:ISBN 경고.ISBN 경고 메시지가 포함된 토크 페이지는 Category:잘못된 ISBN이 있는 문서.WPCleaner 스크립트는 영향을 받는 기사에 대한 경고 메시지를 추가하고 자동으로 수정된 기사에 대한 경고 메시지를 제거할 수 있다.나는 이것을 내 샌드박스에 테스트해봤고 효과가 있다구.이 기능은 이미 프랑스어 위키백과 및 사용자:NicoV는 친절하게도 영어 위키백과에서도 이런 일이 일어날 수 있도록 WPCleaner를 구성할 수 있다고 말했다.출력은 다음과 같다.
기사에서 발견된 잘못된 ISBN 번호(설명서)를 수정하기 위해 도움말이 요청됨:

• • ISBN 0-123-456-78 : ISBN은 10자리 대신 9자리만 가지고 있어 무효다.

영어 위키백과에서 부정확한 ISBN을 식별하는 데 도움이 되는 이 훌륭한 특징을 가질까?pkbwcgs (대화) 10:19, 2018년 12월 31일 (UTC)[응답하라]

나는 우리가 분명히 결함이 있는 ISBN들로부터 오류 메시지를 이미 받고 있다고 생각했다. - 어떻게 이 제안이 상황을 개선할 것인가?나이젤 이스 (토크) 10:24, 2018년 12월 31일 (UTC)[응답]

@니겔 이스: 그것은 일부 ISBN들에게만 이렇게 할 것이다.현재 ISBN 오류는 목록 형태로 되어 있다.ISBN 형식도 잘못 신고할 예정인데 직접 그렇게 말하지는 않는다.pkbwcgs (대화) 10:29, 2018년 12월 31일 (UTC)[응답하라]

이것은 또한 자동으로 업데이트될 수 있고 이로 인해 결함이 있는 ISBN을 쉽게 찾을 수 있다. 나는 그것이 ISBN이 결함이 있는 이유를 말해줄지는 확실하지 않지만 이것은 수동으로 추가될 수 있다.결함이 있는 ISBN을 반드시 열거할 것이다.pkbwcgs (토크) 10:33, 2018년 12월 31일 (UTC)[응답]

내가 생각하는 주된 관심사는 템플릿으로 만들어진 ISBN(이미 템플릿에 의해 유효하지 않은 것으로 감지될 수 있음)에 국한되지 않고, 마법 구문으로 만들어진 ISBN에도 효과가 있다는 것이다.예를 들어, 1946년 난파선 목록 189는 유효하지 않은 ISBN을 사용하고 있지만, 마법의 링크를 사용하여 완료되었기 때문에 탐지되지 않는다.WPCleaner는 잘못된 ISBN을 찾기 위해 여러 소스를 사용한다. 범주, Check Wiki 프로젝트, 덤프 분석...발견된 오류는 위키피디아에 나열되어 있다.위키프로젝트 확인 위키백과/ISBN 오류는 확인했지만, 기사 편집자는 현재 이를 모르고 있다. --NicoV 10:44, 2018년 12월 31일(UTC)[응답]

매직 링크를 생성하지 않는 잘못된 구문(ISBN 주위의 노위키 태그, ISBN과 번호 사이의 콜론...)도 감지한다. --NicoV 10:46, 2018년 12월 31일(UTC)[응답]

• 결함이 있는 ISBN을 고칠 수 있는 봇의 아이디어가 마음에 든다. 결함이 있는 ISSN(국제표준 일련번호)에도 똑같이 적용되는지 물어봐도 될까?보르비 (토크) 14:39, 2019년 1월 2일 (UTC)[응답]

  @Vorbee:pkbwcgs가 론칭한 RfC는 기사 토크 페이지에 봇으로 결함이 있는 ISBN을 보고하기 위한 것이지 봇으로 고치는 것은 아니라고 생각한다.아마도 언젠가 ISBN에 대한 WPCleaner에 자동 수정을 추가할 수 있겠지만, ISBN 번호 자체에 대한 문제(잘못된 길이, 잘못된 체크섬...)가 무엇인지(또는 결함이 있는 ISBN이 진짜일지라도)를 자동으로 알기란 정말 어렵기 때문에, 아마도 포맷 문제(잘못된 대시, 콜론, 점...)로 제한될 것이다.…). ISSN에 관해서는 WPCleaner가 ISBN과 같은 일을 할 수 있는데, 전용 경고 템플릿을 만들고 WPCleaner를 구성하는 것에 지나지 않는다(이미 frwiki에서 하고 있다).Pkbwcgs는 ISSN이 받아들여져 생산에 투입되면 아마도 또 다른 RfC를 출시할 것이다. --NicoV^{(Talk on frwiki)} 16:35, 2019년 1월 2일 (UTC)[응답]

  @Vorbee:ISBN에 많은 도움을 주고 있다. AWB(PkbwcgsBot 과제 5)를 이용해 불량 ISBN을 고칠 수 있는 RegEx를 준비했고, 불량 ISBN과 ISSN이 매일 업데이트(PkbwcgsBot 과제 8) 승인을 받았다.오류가 있는 페이지는 위키피디아에 나열되어 있다.Wiki Project Check Wikipedia/ISBN 오류.단, 기사 토크 페이지에는 ISBN 경고가 없어 사용자가 일부 ISBN 오류를 인지하지 못하여 어떤 ISBN이 잘못 포맷되어 있는지 또는 유효하지 않은지를 알려주는 토크 페이지의 공지 사항.이 RfC가 성공하면 사용자:NicoV는 영어 위키피디아에 대해 이 기능을 구성한 다음 WPCleaner를 사용하여 매일 이러한 ISBN 경고 메시지를 추가 및 제거하도록 BRFA를 제출한다.사용자:NicoV는 "이번이 성공하면 ISSN을 위한 RfC를 하나 더 제출하겠다.그러나, 위키피디아:위키프로젝트 체크 위키백과/ISBN 오류는 ISBN 오류의 크고 긴 목록을 가지고 있다. Pkbwcgs (대화) 17:11, 2019년 1월 2일 (UTC)[응답]

• 최종 결과를 보려면 테스트 계정에 WPCleaner를 구성하여 표시: 사용자 대화:NicoV/1946년 난파선 목록 작성해메시지의 각 부분을 구성할 수 있다(Checkwiki의 구성 또는 WPCleaner의 구성). --NicoV^{(Talk on frwiki)} 18:12, 2019년 1월 2일(UTC)[응답]

  @NicoV: 좋아 보이지만 그 기능은 현재 나의 WPCleaner 테스트 버전에서는 작동하지 않는다."WPCleaner's configuration에서 'isbn_warning_template' 속성을 정의해야 한다"고 되어 있다.pkbwcgs (대화) 18:30, 2019년 1월 2일 (UTC)[응답하라]

  @Pkbwcgs:응, 내 테스트 계정(NicoVTEST)에서만 구성을 했기 때문에 다른 사람들은 구성을 사용할 수 없어.그리고 WPCleaner도 일부 파라미터에 대한 사용자별 구성을 허용하도록 수정했다.이 RfC가 수락되면 구성을 일반 구성 페이지에 넣을 수 있다. --NicoV^{(Talk on frwiki)} 20:50, 2019년 1월 2일(UTC)[응답]

  @NicoV: 알았어.질문 하나 있습니다.이 기능이 ISBN의 문제(예: 부정확한 체크섬, ISBN이 너무 긴 등)를 자동으로 보고하고 ISBN 경고 메시지에 이 정보를 알릴 것인가?pkbwcgs (대화) 20:54, 2019년 1월 2일 (UTC)[응답하라]

  @Pkbwcgs:사용자 대화 예제와 동일한 수준의 세부사항을 제공한다.NicoV/1946년 난파선 목록 : 예를 들어, 메시지에는 체크섬이 부정확하다고 되어 있다.메시지는 일부 가변적인 부분으로 Checkwiki의 구성 i를 사용자 정의할 수 있다. --NicoV^{(Talk on frwiki)} 21:25, 2019년 1월 2일 (UTC)[응답]

  @NicoV: 그것은 훌륭한 특징이며, ISBN에 무엇이 잘못되어 있는지 사용자가 인식하여 고칠 수 있게 함으로써 영어 위키백과에 도움이 될 것이라고 확신한다.그 특징을 만들어줘서 고마워.나는 그것이 도움이 될 것이라고 확신한다.Pkbwcgs (대화) 22:05, 2019년 1월 2일 (UTC)[응답]

내가 처음 확인한 것은: Lepidosperma squamatum의 0 7209 3995 2가 http://museum.wa.gov.au/sites/default/files/1.%20Storr_5.pdf의 출판물에 있는 숫자와 일치한다는 것이다. 그러면 어떻게 하시겠습니까?인쇄된 번호가 권위있는가?Graeme Bartlett (대화) 22:45, 2019년 1월 2일 (UTC)[응답]

그래미 바틀렛은 좋은 질문인데, 불행히도 나는 각각의 경우에 맞는 결정적인 답을 가지고 있지 않다.예를 들어 ISBN이 ISBN 구성 규칙과 일치하지 않음: 계산된 체크섬은 "X"이지만 ISBN에는 "2"가 표시됨.

나는 주로 프루키에 종사하기 때문에 프랑스어로 출판된 ISBN(ISBN 2, 978-2 또는 979-10으로 시작하는 ISBN)의 권한은 프랑스 국립도서관이다.나는 주로 그곳에서 책을 찾아보고 만약 그 공지가 존재한다면, 그것은 어느 쪽이라고 말할 것이다.

• #1) 실제로 ISBN이지만 오류에 가깝다(그 경우, 나는 "ISBN" 대신 "isbn erroné"라는 특수 매개변수를 사용하여 오류가 없는 ISBN과 함께 책이 출판되었음을 명확히 기술한다)
• #2) 다른 ISBN이 있다(이 경우 공지사항의 ISBN을 이용한다)
• #3) 실제로 ISBN이지만 오류라고 하는 것은 없다(그 경우 BNF에 문제를 보고하고 보통 일주일 이내에 고치기 때문에 결국 사례 #1이나 #2로 끝난다).

영어로 된 책이라면, 그런 권위자가 있는지...나는 그들을 위해 월드캣을 많이 사용하지만, 나는 기사 속의 ISBN이 공지사항의 ISBN과 같지 않을 때에만 유용함을 발견한다.당신의 경우, 월드캣은 이 책의 출품작을 단 2개만 가지고 있다. OCLC24474223 및 OCLC941859713. 이들 중 ISBN을 제공하는 것은 없다.호주 국립도서관도 마찬가지야...그래서 이번 건은 잘 모르겠다.기사에서 ISBN을 제거하고 OCLC 또는 NLA 링크를 사용할 수 있는가? 또는 인쇄 중인 ISBN이 권위적이고 인용 템플릿에 대한 특별한 매개 변수가 있다고 생각하여?

모든 토크 페이지에 메시지를 담기 위해 봇을 실행하기 전에 WPCleaner와 수동으로 첫 패스를 수행하여 가장 쉬운 패스를 수정하는 것이 좋을 수 있다고 생각한다(Wikipedia:ChECKWIKI/WPC 069 덤프: 잘못된 구문, 위키백과:CheckWIKI/WPC 070 덤프: 10 또는 13 접두사가 있는 덤프).--NicoV^{(Talk on frwiki)} 07:53, 2019년 1월 3일 (UTC)[응답]

@NicoV: 나도 이 기능을 구성하고 내 사용자 공간에서 테스트할 것이다.pkbwcgs (대화) 11:39, 2019년 1월 3일 (UTC)[응답하라]

@Pkbwcgs:공개적으로 사용할 수 있는 WPCleaner 버전은 ISBN 경고에 대한 사용자별 구성을 허용하지 않는다(테스트 계정에서 실행하도록 소스 코드를 로컬로 수정했다).그러나 일반 구성 페이지에서 구성을 시도해보십시오. 사용자:NicoV/WikiCleanerConfiguration(원하는 경우): 정상 사용(봇 모드가 아님) 시 WPCleaner는 기존 경고만 업데이트하고 생성하지 않는다(이 때문에 수동으로 사용자 대화:NicoV/ 1946년/할 일) 및 기사 페이지의 수정으로 ISBN 관련 문제가 해결된 경우에만.테스트 후 구성을 확실히 코멘트하십시오. --NicoV^{(Talk on frwiki)} 11:50, 2019년 1월 3일(UTC)[응답]

@NicoV: 벤플릿 기차역에서 시도하고 있다(참고자료 2에 ISBN 오류가 있다).구성 위치:Pkbwcgs/WikiCleanerConfiguration 및 내 사용자 공간의 기사는 User:Pkbwcgs/벤플레트 기차역.작업관리 페이지는 User talk에 있다.Pkbwcgs/Benfleet 기차역/할 일 및 토크 페이지는 사용자 토크:Pkbwcgs/벤플레트 기차역.하지만 이 테스트는 효과가 없다.내가 뭘 잘못하고 있는 거지?pkbwcgs (대화) 12:03, 2019년 1월 3일 (UTC)[응답]

@Pkbwcgs:이전 메시지 확인: #1 기본 구성 페이지에서 구성을 수행해야 함 사용자:WPCleaner에서 해당 매개 변수에 대해 사용자 특정 구성을 허용하지 않기 때문에 NicoV/WikiCleanerConfiguration이 구성됨또한 ISBN과 관련된 내용을 사용자: 페이지에서 수정하십시오.ISBN 경고 업데이트를 트리거하는 Pkbwcgs/Benfleet 철도역.그렇지 않으면 모든 것이 봇모드로 이루어지지만, 어느 페이지를 작동할지는 선택할 수 없다. --NicoV^{(Talk on frwiki)} 12:41, 2019년 1월 3일(UTC)[응답]

@NicoV: User에서 이 기능을 구성할 수 있는가?NicoV/WikiCleanerConfiguration 테스트를 마치면 되돌릴까?Pkbwcgs (대화) 16:05, 2019년 1월 3일 (UTC)[응답]

@Pkbwcgs:예, 사용자:NicoV/WikiCleanerConfiguration, 사용자:필요한 항목을 확인하려면 NicoVTest/WikiCleanerConfiguration을 사용하십시오.테스트를 마치면 수정 내용을 되돌리거나 코멘트에 담으면 된다(줄의 시작에 #가 코멘트임). --NicoV^{(Talk on frwiki)} 16:16, 2019년 1월 3일(UTC)[응답]

@NicoV: 어떤 이유에서인지 그 특징은 아무것도 바꾸지 않고 있다.그것은 단지 내용물을 회수하고 있다고 말하고 있을 뿐이다.Pkbwcgs (대화) 16:35, 2019년 1월 3일 (UTC)[응답하라]

@Pkbwcgs:업데이트를 트리거하려면 WPCleaner로 테스트 페이지의 ISBN 문제를 수정해야 한다(내 테스트를 위해 이 문제를 해결했다).--NicoV 16:47, 2019년 1월 3일 (UTC)[응답]

@Pkbwcgs:ISBN 경고를 직접 추가할 수 있는 메뉴가 있다는 것을 깜빡하고, 그래서 페이지에서 ISBN을 수정하자는 이야기를 하고 있었다.하지만 메뉴를 통해 경고를 추가하려고 했지만 효과가 없었다: 아마도 나는 enwiki에 대한 구성을 처리하기 위해 내 코드의 무언가를 수정해야 할 것이다(frwiki와는 다르다).계속 알려줄게. --NicoV^{(Talk on frwiki)} 16:57, 2019년 1월 3일 (UTC)[응답]

@NicoV: 여기서 ISBN 경고 메시지를 업데이트했다.그러나, 나는 영어 위키피디아가 이 기능을 작동시키기 위해 또 다른 "할 일" 하위 페이지가 있는 것보다 이 경고 메시지가 내 봇에 의해 기사의 토크 페이지에 직접 추가되고 삭제될 수 있다면, 이것의 혜택을 볼 수 있을 것이라고 생각한다.Pkbwcgs (대화) 18:32, 2019년 1월 3일 (UTC)[응답]

@NicoV: 당신의 특색은 훌륭하게 작동한다.버튼을 잘못 눌러서 예상치 못한 일이었지만 수정 내용을 되돌렸다.하지만, 이런 차이점들은 위키피디아에 절대적으로 도움이 될 것이다.Pkbwcgs (대화) 21:06, 2019년 1월 3일 (UTC)[응답하라]

@Pkbwcgs: WPCleaner는 구성에 따라 토크 페이지나 하위 페이지에 직접 경고를 넣을 수 있다.파라미터general_todo_templates대화 페이지에 직접 템플릿을 추가하는 경우(이 디프트에서 발생한 경우):{{todo}}}}이(가) 작업 목록을 매개 변수로 받아들이지 않기 때문에 엔위키에 맞게 올바르게 구성되지 않은 것 같다.파라미터general_todo_subpage경고가 하위 페이지에 표시될 때 사용할 하위 페이지 이름.하위 페이지 또는 대화 페이지에 경고를 표시할 것인지 여부를 결정하려면:general_todo_subpage_force다른 테스트에 관계없이 하위 페이지를 사용하도록 강제한다; 하위 페이지가 이미 존재하는 경우 하위 페이지에 경고가 표시된다; 토크 페이지에 하위 페이지로 연결되는 링크를 제공하는 템플릿이 이미 있는 경우(부터)general_todo_link_templates ,{{todo}}}의 정확한 목록인 것 같음) 그러면 경고가 하위 페이지에 붙는다. --NicoV^{(Talk on frwiki)} 10:16, 2019년 1월 4일 (UTC)[응답]

이 차이에서 볼 수 있듯이(그리고 OP의 예에서), 렌더링된 템플릿은 목록 표시가 깨졌다(한 개의 별표가 그와 같이 표시되고, 마지막 줄에는 글머리 기호 하나가 아닌 두 개의 점이 표시된다).봇이 뛰기 전에 이걸 고쳐야 해Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 11시 28분, 2019년 1월 4일 (UTC)[응답]

@Pigsonthewing:좋은 지적이야.나는 사실 그 문제를 어떻게 해결해야 할지 잘 모르겠어.템플릿은 User:현재 NicoV/ISBN Warning(NicoV/ISBN 경고)에서 해결하려는 경우템플릿에서 변환됨:그렇게 하는 것은 또한 그 템플릿에도 문제가 있을 수 있다.나는 그것을 고치려고 노력했지만 효과가 없었다.pkbwcgs (대화) 12:37, 2019년 1월 4일 (UTC)[응답]

@Pkbwcgs:사용자: 참조:NicoV/ISBN 경고/Sandbox.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집은 17:07, 2019년 1월 4일 (UTC)[응답]

@Pigsonthewing:그것은 좋아 보이네요.@NicoV:이 기능이 템플릿을 다음과 같이 렌더링하도록 WPCleaner를 수정하십시오.

{{todo  * {{ User:NicoV/ISBN Warning   revisionid=875583851   978-3-931473-16-4   Computing the checksum gives 7, not 4 }} -- 21:02, 3 January 2019 (UTC) <!-- This line is updated from time to time by a bot. -->}}

우리는 모든 대화 페이지에 "할 일" 하위 페이지가 필요하지 않다. 나는 그것이 업데이트되고 있다고 생각하므로 그것을 바꾸지 마십시오.하지만, 우리는 다음 줄의 공간을 원한다.{{to do . pkbwcgs (대화) 18:57, 2019년 1월 4일 (UTC)[응답하라]

@Pkbwcgs:마지막 버전을 사용해 보십시오... --NicoV^{(Talk on frwiki)} 23:07, 2019년 1월 4일 (UTC)[응답]

@NicoV: "마지막 버전"이라니 무슨 뜻이야?Pkbwcgs (대화) 12:03, 2019년 1월 5일 (UTC)[응답]

@Pkbwcgs:WPCleaner를 정상적으로 실행 중이면(다운다운 또는 제공된 스크립트를 통해) WPCleaner가 자동으로 어제 릴리스로 업데이트되어야 한다.버전 번호는 동일함. --NicoV^{(Talk on frwiki)} 12:21, 2019년 1월 5일 (UTC)[응답]

@NicoV: 작업 중인 ISBN 경고 템플릿을 사용자에서 이동할까?템플릿에 대한 NicoV/ISBN 경고:ISBN 경고?Pkbwcgs (대화) 12:25, 2019년 1월 5일 (UTC)[응답하라]

@Pkbwcgs:봇을 운영하고 싶다면 더 좋을 것이다. --NicoV^{(Talk on frwiki)} 13:22, 2019년 1월 5일 (UTC)[응답]

@NicoV: 알았어.나는 여전히 BRFA를 신청하기 전에 어느 정도 의견 일치를 보고 싶다.Pkbwcgs (대화) 13:31, 2019년 1월 5일 (UTC)[응답하라]

@Pkbwcgs:문제 없어요.템플릿과 설명서 하위 페이지의 이름을 바꾸고, 사용하기 전에 합의 사항이 필요하다는 내용을 문서에 메모를 추가하라는 것이 나만의 조언이 있을 것이다.적어도 템플릿 이름을 잘못 입력하여 수동으로 경고를 수정할 필요는 없을 것이다... --NicoV 14:06, 2019년 1월 7일(UTC)[응답]

템플릿을 추가할 봇:reflist-talk

편집 시 "이 페이지 보기"가 기본 동작이어야 함

프로포즈

내가 위키피디아 페이지를 편집한다고 하자.몇 달 후, 누군가가 내 버전을 수정한다("undo"를 사용하지 않고, 내가 한 일을 덮어쓰기만 한다).기본적으로 이것에 대한 경각심은 없을 것이다.기본 설정은 페이지를 편집할 때마다 "이 페이지 보기" 확인란을 기본적으로 선택하도록 하는 것이어야 한다.

• "이 페이지 보기"에 대한 코멘트는 "사용자가 보고 싶은 것"에 대해 개인에게 좀 더 선택적인 선택권을 주어야 한다.현재 그것은 가지고 있지 않다.콜튼 멜처 (대화) 05:44, 2018년 12월 28일 (UTC)[응답]

단점

"전원" 편집자들은 수천 페이지를 편집하고, 물론 많은 통지를 받을 것이다.그러나 첫째, 모든 파워 에디터에게 실용적이지 않은지 확실하지 않으며 둘째, 이러한 종류의 편집자는 이 옵션을 전세계적으로 비활성화하는 방법을 알고 있다(기본 설정).워치리스트>내 워치리스트에 편집하는 페이지와 파일 추가).이 옵션은 선택사항에 약간 포함되어 있기 때문에 대부분의 사용자가 이 선택사항을 사용하지 않을 수 있지만 "전원" 편집기의 경우는 그렇지 않을 수 있다.

프로스

• 반직관적이다.

대부분의 인터넷 게시판, 블로그 댓글 코너에서 볼 수 있는 것이 바로 이런 종류의 사이트에 있는 모든 사용자들에게 기대되는 행동인 것 같다.알림을 받을 수 있는 옵션을 찾기 위해 설정을 뒤질 필요가 없다.

• It's Harmous

"정규 편집자가 아니다"가 정기 편집자가 되도록 격려할 기회를 놓치기 때문에 해롭다.나는 페이지를 편집하는 사람들은 아주 드물게 그들의 수정을 완전히 잊어버릴 것이라고 생각한다.만약 그들이 더 많은 수정을 요구받지 않는다면, 대부분은 아마 그것을 알지 못할 것이고, 다시는 그 페이지에 나오지 않을 것이다.Linuxo (talk) 12:14, 2018년 12월 18일 (UTC)[응답]

토론

제안은 고맙지만, 나는 그것이 필요하지 않다고 생각해.편집하는 페이지 중에는 작은 파란 별을 확인하고 그렇지 않은 페이지도 있다.너는 곧 그 습관을 갖게 된다.당신의 편집 횟수가 증가하면 당신은 더 이상 당신이 개별 페이지에 무엇을 추가하는지 기억할 수 없을 것이고 당신은 다른 사람들이 분별력을 갖도록 신뢰하는 법을 배울 것이다.WP의 구석에는 내가 다른 곳을 밟지 않는 곳이 있을지도 몰라. 거기서 일하고 있다면 별을 확인해봐.ClemRutter (대화) 12:31, 2018년 12월 18일 (UTC)[응답]

직접 스페셜로 이동하십시오.Preferences#mw-prefection-watchlist(기본 설정#mw-prefection-watchlist)를 선택하고 편집하는 페이지 및 파일을 내 감시 목록에 추가 확인란을 선택하십시오.만약 당신이 새로운 사용자들을 위해 기본적으로 그 체크박스를 체크받기를 원한다면, 그것은 T38316에서 논의된 이슈들에 대한 커뮤니티의 합의와 고려를 보여주기 위한 RFC가 필요할 것이다.아노미야 03:00, 2018년 12월 19일 (UTC)[응답]

이 옵션을 알려줘서 고맙네고마워!WelpThatWorked (대화) 05:23, 2018년 12월 20일 (UTC)[응답]

편집하는 모든 페이지를 내 감시 목록에 배치하도록 내 기본 설정을 지정했다.그 결과는 다음과 같다.나는 지금 내 감시 목록에 5,300개 이상의 아이템을 가지고 있다. (내가 가끔 그것을 다듬지만, 내가 편집한 7,000 페이지 이상이 현재 내 감시 목록에 없다.)나는 매일의 상당 부분을 내 감시 목록을 훑어보며 보낸다.나는 많은 편집자들이 그것을 다루기를 원하지 않거나, 시간이 있을 것이라고 확신한다.이걸 옵션으로 남겨두는 게 좋을 것 같아. - 도널드 앨버리 13:31, 2018년 12월 19일 (UTC)[응답하라]

당신이 편집하는 모든 페이지를 보는 것은 쉽게 압도될 수 있다.오직 고급 사용자만이 그것을 좋아할 것이다.따라서 기능성을 계속 선택적으로 유지하는 것이 좋을 것 같다. --NaBUru38 (토크) 14:26, 2018년 12월 26일 (UTC)[응답]

한 페이지를 보고 싶다면 파란 별을 클릭하십시오.새로운 글의 편집이 증가할 때 편집이 압도적으로 많은 모든 페이지에 기본값을 설정하는 것. 카시오피아^(talk) 14:37, 2018년 12월 26일 (UTC)[응답]

• 반대한다. 나는 이것이 디폴트인 위키에 참여한다. 그리고 그것은 실행가능하지 않다.당신은 결국 수백, 수천 페이지의 감시 목록을 갖게 되고, 감시 목록은 사실상 쓸모 없게 된다.우리는 이미 이것을 켜기 위한 선택권을 가지고 있다. 그것을 원하는 사람들과 그것을 다룰 수 있는 사람들을 위해서. (아마도 편집자들은 극명하게 제한된 주제 범위에 매우 좁게 초점을 맞추었고, 그것은 대부분의 편집자들은 아니다.)우리들 중 너무 많은 사람들(아마도 거의 모든 사람들)이 오자를 고치고 텍스트를 개선하기 위해 페이지를 무작위로 편집하기 때문에, 이 제안은 특히 수백만 개의 글과 많은 수의 과정과 절차 페이지, 그리고 사용자 토크 페이지를 사용하여 의사소통을 하고 삭제 제안과 삭제에 대한 통지를 남기는 커뮤니티 규범이 있는 현장에서는 실용적이지 않다.관련 프로젝트 토크 페이지 등에 실린 그녀의 그런 사항들 — SMc캔들리쉬 lish 23:50, 2019년 1월 6일 (UTC)[응답]
• 반대- Per SMcCCandlsih: 최소한 그들이 보는 것보다 더 많은 페이지를 편집하는 우리에게는 실행 가능한 옵션이 아니다.비욘드 마이 켄 (토크) 17:08, 2019년 1월 7일 (UTC)[응답]
• 지원 대안을 제시하라 나는 우리가 그 제안을 다시 바꾸어 말할 필요가 있다고 생각한다.기본적으로 "이 페이지 보기"를 선택하는 대신, 새로운 사용자를 위해 "내 감시 목록에 편집하는 페이지 및 파일 추가"를 기본적으로 선택하십시오.보기보다 많은 페이지를 편집하는 파워 유저들은 한 번 쉽게 선호도를 선택 해제할 수 있지만, 많은 유저들은 선호도가 존재하는지 모를 수 있다. --Ahecht (TOKPAGE
  ) 15:19, 2019년 1월 8일 (UTC)[응답]
• 《Per SMcCandlist》에 반대하여 2015년에 누락된 기사 3만 건을 내 워치리스트에 추가하고 2017년에 만들어진 많은 것들을 정리했다. 2018년 말에 나는 모든 엔트리를 정리하고 원래의 페이지를 복원하고 Xtools를 통해 내가 만든 다른 페이지(토크 페이지 등 포함)를 찾아냈다.하지만 나는 우리가 편집된 모든 페이지를 포함한다면, 감시목록이 너무 복잡할 것이라는 것에 동의한다.극소수(예: 사용자:J3Mrs)는 페이지 수가 많지 않은 데 많은 기여를 하는 사람이 유용할 수 있다.그것은 또한 편집 전쟁을 증가시킬 수 있다. 비록 그것이 공공 기물을 파괴하는 것을 더 빨리 되돌리도록 만들 수는 있지만, 만약 관련 없는 페이지가 너무 많다면 사람들이 감시된 페이지를 확인하는 것을 방해할 수도 있다.창작물을 보는 기본은 합리적이고 충분하다고 생각한다.이것을 원하는 소수의 사람들은 이것을 선택할 수 있다.내가 도널드 앨버리에게 말했듯이 나는 최근의 문제들로 인해 애쉬포드 카보넬을 내 감시목록에 추가했지만 나는 편집된 모든 페이지를 보는 것이 일반적으로 합리적이라고 생각하지 않는다.크라우치, 스와일 (대화) 17:31, 2019년 1월 8일 (UTC)[응답]
• 지원 내 생각에는 당신이 편집한 내용을 잊어버리고 잊어버리기보다 나중에 제거할 수 있는 추가 페이지가 있는 것이 더 낫다고 생각한다.물론 "이 페이지 보기"를 선택 해제하는 옵션이 있어야 하지만 기본적으로 켜져 있어야 한다.사람들, 특히 새로운 사람들은 편집 내용을 추가하는 것을 잊는다.프러시아어울 (대화) 23:11, 2019년 1월 8일 (UTC)[응답]
• 수년 동안 편집한 내용을 다 켰는데도 불구하고 디폴트로 만드는 것에 반대한다.사실, 나는 단지 (오늘) 내가 만든 페이지만 내 감시 목록에 추가하도록 설정을 변경했다.내 감시목록은 5,300페이지 이상으로 커졌지만, 오늘 나는 약 1,800페이지를 삭제했는데, 거의 모두 빈사상태였다.내 감시 목록에 있는 대부분의 페이지들은 아마도 몇 달에 한 번 또는 그 이하로 자주 나타난다.그 페이지들 중 상당수는 감시자 수가 적어서 내가 떨어뜨리면 그들에 대한 반달리즘이 오랫동안 눈에 띄지 않을 수도 있다.만약 내가 프로젝트 페이지의 팔로잉을 중단한다면, 내 감시 목록은 매우 쉽게 관리될 것이다.하지만 내게 맞는 것은 다른 사람에게는 통하지 않을 수도 있다. - 도널드 앨버리 00:38, 2019년 1월 9일 (UTC)[응답]
• 반대 - 편집하는 모든 페이지를 볼 필요 없고, 관심도 없는 여러 페이지(최소 편집)를 편집하며, Huggle이나 AWB 같은 프로그램을 사용하는 사용자도 언급하지 않는다. – BrandonXLF (t@lk) 01:48, 2019년 1월 9일 (UTC)[응답]
• 반대한다, 나는 어떤 상황에서도 내 감시 목록에 추가하고 싶지 않은 많은 페이지에 짧은 설명을 추가한다.내 워치리스트는 내가 만든 페이지와 내가 직접 추가한 페이지들만으로 최적의 페이지보다 더 크다. 왜냐하면 나는 실제로 그것들을 감시하고 싶기 때문이다.만약 내가 편집하는 모든 페이지가 추가된다면, 나는 편집하는 것을 심각하게 줄여야 할 것이다.내가 정확히 기억한다면, 이것은 이미 충분히 화가 나 있거나 편집한 페이지 수가 너무 적어서 큰 불편이 되지 않는 누구에게나 선택사항이다.이것은 어떤 경우에도 채무불이행으로 해서 그 누구에게도 강요되어서는 안 된다.····피터 사우스우드 : 2019년 1월 9일 17시 31분(UTC)[응답]
• Alt 제안.처음에 편집한 100개의 기사가 감시 목록에 추가되고 시스템이 당신에게 물었다면, 우리는 신참과 구손 모두에게 더 잘 맞는 시스템을 갖출 수 있을 것이라고 생각한다.얼마 전에 9,000페이지를 뺐을 때 잔혹한 다듬기에도 불구하고 내 자신의 감시목록이 4,000페이지에서 5,000페이지로 몰래 올라갔어쩌면 9,000페이지를 뺐을 때 말이야.그래서 나는 확실히 확장된 감시 목록을 원하지 않는다. 하지만 나는 섹션을 볼 수 있는 옵션을 원한다.ϣereSpielCequers 19:08, 2019년 1월 9일 (UTC)[응답]

  나는 그것이 통할 수 있을 것이라고 생각하지만, 더 복잡하고 혼란스러울지도 모른다, 당신의 기여에 '현재'가 나타나는지를 확인하고(내가 그렇게 많이 하지는 않지만), 당신의 사용자 페이지로 연결되는 페이지와 연결된 최근의 변경사항을 보는 것만으로도 충분한 IMO. 나는 그것을 재빨리 확인함으로써 그것을 디프로그래밍한 후 AFD에 나열되어 있던 기사를 발견했다.기부는 자주 하지 않지만크라우치, 스와일 (대화) 19:16, 2019년 1월 9일 (UTC)[응답]

• 지원, 이 논의에는 노년층만 있고, 취향에 따라 쉽게 조정할 수 있다.그러나, 그것은 noobs에 관한 것이다.22시간 전에 나는 감시 목록을 설명하는 동안 두 명의 새로운 편집자와 식사를 했다.신입 사원들은 그들의 감시 목록을 보는 것에 대해 일찍 배워야 하고, 나중에 그것을 조정하는 것에 대해 자세히 알아야 한다.짐.헨더슨 (대화) 22:28, 2019년 1월 9일 (UTC)[응답]
• 반대하면 나는 확실히 늙은 타이머가 아니다.나는 이미 내 감시 목록에 27,308페이지가 있는데, 주로 스팸 방지 작업 때문이다. 내가 편집했지만 태그를 지정하지 않은 모든 페이지가 감시 목록에 포함되었다면, 그리고 완전히 무의미한 이유 때문에-- 90% (적어도) 내가 다시는 게시하지 않는 것과 같은 낮은 수준의 스팸 발송자들이 다시는 게시하지 않기 때문에, 감시 목록은 무의미하다.스팸 메일을 보내지 않는 사람은 고사하고!———SerialNumber54129 23:34, 2019년 1월 9일(UTC)[응답]

{{섹션사이즈}}을(를) 추가하는 봇으로 페이지 토크

이 템플릿을 기사가 15만 바이트를 초과하는 약 6300개의 기사 토크 페이지에 추가하자는 봇 제안이 있다(Special:LongPages), 이 편집에서와 같이..만약 이런 일이 일어나길 바란다면, 봇을 운영하기 위한 지역사회의 지원이 필요하다.봇이 이런 일을 하기를 원하면 목소리를 낼 수 있는 곳이다. -- GreenC 15:56, 2019년 1월 4일 (UTC)[응답]

15만 바이트는 컷오프가 너무 적은 것 같다.템플릿의 요점은 크기가 너무 큰 기사를 위한 것으로 보이기 때문에, 약 150000바이트의 대부분의 페이지는 크기를 줄일 필요가 없기 때문에, 250000과 같은 것은 컷오프로서 훨씬 더 의미가 있을 것이다(물론 상황은 다양하지만, 크기를 줄이거나 분할할 필요가 있을 수 있다).갤럽터 (pingo mio) 16:24, 2019년 1월 4일 (UTC)[응답하라]

@Pigsonthewing: -- GreenC 17:09, 2019년 1월 4일 (UTC)[응답하라]

나는 Galobtter의 평가에 동의하지 않는다(대부분의 150000바이트 기사는 너무 길다; WP: 참조):AS); 그러나 어떤 경우에도 그러한 자전거 타기는 관련이 없다; 이 템플릿은 편집자에게 기사 섹션의 상대적 크기를 알리기 위한 것이다; 그것은 분할을 의무화하거나 권고하지도 않는다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2019년 1월 4일 (UTC)[응답]

WP:AS는 주로 읽을 수 있는 산문 크기에 대해 이야기하며, 대부분의 150000바이트 기사는 그 가이드라인에 따라 분할이 필요한 것보다 훨씬 적은 가독성 산문 크기를 가지고 있다(실제로 150000바이트 이상의 FA가 많다).토크 페이지에 추가되는 모든 템플릿은 복잡성을 가중시키므로 어느 정도 이점이 있을 수 밖에 없다. 그 이점은 주로 분할에 대해 이야기할 때 있기 때문에, 자동으로 템플릿을 추가할 때 컷오프에 대해 이야기하는 것이 여기서는 중요해 보인다.갤럽터 (pingo mio) 15:35, 2019년 1월 5일 (UTC)[응답하라]

25만 한도는 약 1000개의 물품이다.25만 명은 어떻게 도착했는가?컷오프 번호가 어디인지에 따라 얼마나 많은 기사가 템플릿을 가질지 큰 차이가 나는 것 같아서 물어보는 것이다.개인적으로 나는 5700,000개의 기사의 계획에는 6000개의 기사가 별로 없다고 생각한다. 대부분의 사람들이 평생 위키백과에서 그 템플릿을 볼 것이라고 의심하는 사람은 거의 없다. -- GreenC 16:03, 2019년 1월 5일 (UTC)[응답하라]

대형 기사들은 이미 그들의 토크 페이지에 매우 많은 수의 템플릿이 있는 매우 불균형하게 인기 있는 기사일 것이다.(Talk와 같은 페이지:크리스티아누 호날두와 토크:명백한 기사가 아닌 태그가 붙은 기사가 버락 오바마일 것이다)갤럽터 (pingo mio) 17:01, 2019년 1월 5일 (UTC)[응답하라]

내가 말했듯이, "그런 자전거 타기는 무관하다."Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2019년 1월 5일 (UTC)[응답]

읽을 수 있는 텍스트의 150kbyte를 말하는 것인가, 아니면 전체 페이지 크기의 것인가?150kb의 읽기 가능한 산문은 모든 자료를 함께 보관해야 한다는 유효한 주장이 있는 예외적인 경우를 제외하고 거의 확실히 너무 길지만, 150kb의 저장 크기는 복잡한 템플릿 표시를 많이 포함하는 페이지에서는 드물지 않다(예를 들어, Barack Obama는 79kb의 읽기 가능한 산문을 만들기 위해 340kb의 코드를 사용한다).나는 코드 크기만으로 모든 것에 태그를 붙이는 봇을 사용하는 것에 상당히 반대한다. 왜냐하면 그것은 결국 많은 수의 완전히 문제가 없는 기사들을 너무 길다고 플래그로 만들고 결과적으로 많은 사람들을 짜증나게 만들 것이기 때문이다.∙ 무지개빛 17:10, 2019년 1월 5일 (UTC)[응답하라]

약간의 혼란이 있는 것 같다.논의되고 있는 템플릿은 기사가 너무 길다는 것을 시사하지 않는다.잭 N. 주식(토크) 17:15, 2019년 1월 5일 (UTC)[응답]

그것에 동의하다.그리고 우리가 너무 긴 기사에 대해 이야기하지 않는다면, 우리는 무엇에 대해 이야기하고 있는가?템플리트 디큐레이션은 위의 제안과 같이 (평소대로) 불분명하다.존보드 (대화) 17:17, 2019년 1월 5일 (UTC)[응답]

전체 페이지 크기(Special:그것을 사용하는 LongPages), 즉 나의 코멘트는 이렇다.갤럽터 (pingo mio) 17:19, 2019년 1월 5일 (UTC)[응답하라]

당신이 Talk:Barack Obama - 왜 우리가 그것을 정확히 태그하는 것인가?존보드 (대화) 17:22, 2019년 1월 5일 (UTC)[응답]

글쎄, 봇은 150kb 이상의 위키텍스트를 가진 기사의 토크 페이지에 템플릿을 추가하게 될 것이고, 여기에는 버락 오바마 (Iri가 언급한 340kb의 코드를 가지고 있다) 갤로브터 (pingo mio) 17:25, 2019년 1월 5일 (UTC)[응답하라]가 포함될 것이다.

바로 그거야!하지만 왜?앤디의 원래 도구 요청은 "매우 긴 페이지"에 대해 많은 이야기를 하고 있었다.존보드 (대화) 17:27, 2019년 1월 5일 (UTC)[응답]

그것은 어떤 목적으로든 유용한 정보다.부분부분을 하위섹션으로 나누고, 부분부분을 별도의 기사로 나누고, 내용을 삭제하여 부분부분을 리팩터링하는 것.대형 기사는 이러한 성격의 작업을 수행할 가능성이 가장 높기 때문에 템플릿의 대상이 된다. 사용자가 작업하고 싶은 섹션을 식별할 수 있도록 도와준다. -- GreenC 17:32, 2019년 1월 5일(UTC)[응답]

FWIW 버락 오바마는 API[1]에 따른 일반 텍스트로 85,394이다. -- GreenC 17:44, 2019년 1월 5일 (UTC)[응답]

• 위의 답변에 비추어 볼 때, 강력하게 반대하라; 이것은 분명히 실제 문제를 해결하려는 시도가 아니라 존재하지 않는 문제를 고친다는 미명하에 이 템플릿을 대량 스팸 발송하기 위해 봇을 사용하는 구실이다.∙ 무지개빛 19:27, 2019년 1월 5일(UTC)[응답]
  • WP:AGF는 이만...Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 21:27, 2019년 1월 5일 (UTC)[응답]
• 이 일의 요점을 모르겠다.헤드폭탄 {t · c · p · b} 20:58, 2019년 1월 5일(UTC)[응답]
• 반대 - 이것은 문제를 찾는 해결책이다.–Davey2010^Talk 22:21, 2019년 1월 5일(UTC)[응답]
• 나는 이것이 유용할 수 있다고 생각하지만, 읽을 수 있는 산문 크기나 단어와 같은 다른 중요한 크기 정보도 포함해야만 한다.이 대본의 결과물 같은 것이 도움이 될 것이다.사용자:Dr_pda/prosize.js. -MrX 🖋 22:24, 2019년 1월 5일(UTC)[응답]
• @GreenC:예제 편집이 65바이트 크기의 토크 페이지에 템플릿을 추가함에 따라, 오프닝 코멘트가 부정확하고 오해의 소지가 있는 것으로 보인다.이것은 대화 페이지의 크기에 관한 것이 아니다.나와 같은 혼동을 막기 위해 취소선과 수정을 제안하라.-맨드러스 인터뷰 22:37, 2019년 1월 5일 (UTC)[응답]

  고정 -- GreenC 23:14, 2019년 1월 5일 (UTC)[응답]

  취소선(및 밑줄) 없이 고정되지만 어쨌든.FTR, 올바른 형식은 "기사가 15만 바이트를 초과하는 기사 토크 페이지"이다.-맨드러스 ▷인터뷰 23:23, 2019년 1월 5일(UTC)[응답]

• 유용한 목적을 보지 마라.그것이 없다고 말하지 않았지만, 설명되지 않았다.의도된 목적이 명시되지 않은 부분에 대해 코멘트를 요청했을 때 자전거 차단을 피하기 어렵다.· · · 피터 사우스우드^(talk) : 05:48, 2019년 1월 6일 (UTC)[응답]
  • 넛지 이론.너무 긴 기사는 여러 VP에 대해 잘 알려져 있고 영원한 주제다.긴 물건의 크기를 줄이는 것이 완강히 어렵다는 것이 증명되어, 그들은 계속 성장한다; 그것은 축소하는 것보다 더 쉽다, 마치 지하실과 차고에서 수집하는 것과 같은.이 템플릿은 콘덴싱 소재를 향한 눈에 띄지 않는 작은 쐐기풀입니다. -- GreenC 04:48, 2019년 1월 7일 (UTC)[응답]
• 지원 이것은 기사에 대한 유용한 정보가 될 것이다.—Eli355 (대화 • 기여) 22:02, 2019년 1월 8일 (UTC)[응답]
• 반대는 말머리-템플릿 정사각형 위에 쌓이지 않도록 하십시오.이것의 유일한 분명한 목적은 만약 누군가가 페이지 크기를 줄이는 작업을 하고 있다면, 그리고 만약 누군가가 그것을 작업하고 있다면, 그것은 맹목적인 숫자 섹션 크기보다는 각 섹션의 실제 텍스트의 검사에 기초해야 하는 일종의 보조 수단일 것이다.알제 (대화) 09:43, 2019년 1월 10일 (UTC)[응답]
• 더 많은 대화 페이지를 어지럽히는 것에 반대한다.레나타 (토크) 13:21, 2019년 1월 10일 (UTC)[응답]

기본적으로 그래프의 모범 사례

우리는 위키피디아에서 많은 그래프를 사용하고 있고, 그것은 좋은 일이다.그래프는 정말로 데이터를 이해하는 데 도움을 줄 수 있다.

슬프게도, 위키피디아에 있는 많은 그래프들은 그들이 기본적인 좋은 관행을 따르지 않기 때문에 오해의 소지가 있다.

몇 가지 이름을 지정하려면:

• 파이 차트 사용(거의 좋은 생각은 거의 없으며 막대 차트를 선호해야 함)
• 0이 아닌 다른 값에서 그래프의 원점
• 축에 이름 없음
• 백분율 사용, 그러나 축이 0-100%의 전체 범위를 표시하지 않음

그래프의 대부분은 https://en.wikipedia.org/wiki/Template:Graph:Chart을 사용하여 작성된다.그리고 나는 우리가 이 템플릿을 수정함으로써 많은 일반적인 문제들을 해결할 수 있다고 믿는다.나는 https://en.wikipedia.org/wiki/Template_talk:Graph:Chart#Convert_all_Pie_chart_to_Bar_chart에서 토론을 열었지만, 나는 이것이 템플릿 페이지를 넘어선다고 생각한다.

내 제안:

1. xAxisMin 및 yAxisMin의 기본값으로 0을 사용하십시오.
2. 두 값이 막대 차트를 사용하도록 강제하는 파이 유형을 더 많이 사용하는 경우(정확)
3. xAxisTitle 및 yAxis인 경우제목이 비어 있다.경고를 표시한다.
4. xAxisMax 및 yAxisMax에 대해 좀 현명하게 대처하십시오.어떻게 그들의 백분율을 감지할 수 있는가?확실하지는 않지만, 예를 들어 값의 합이 100과 같을 때 기본적으로 yAxisMax=100을 사용할 수 있다.

가가린 (대화) 17:47, 2018년 12월 30일 (UTC)[응답]

가가린, 위키피디아의 많은 그래프들이 좋은 관행을 따르지 못할 수도 있다는 관념을 지지하면서, 나는 좋은 관행을 의무화하는 것은 잠재적으로 문제가 될 수 있다고 제안한다.최소한, 우리는 몇 가지 제안부터 시작해야 하고 시간이 지남에 따라, 몇 가지 어려운 규칙들이 실행될 수 있는지를 점차적으로 결정해야 한다.나는 그것이 불가능할지 모른다고 의심한다.당신의 규칙 중 일부는 그럴듯하게 들리지만, 예외를 찾는 것은 어렵지 않다.예를 들어 0을 최소값으로 의무화하는 것이 반드시 정답은 아니다.나는 선택적 가치의 사용이 오해를 불러일으킬 수 있다는 것을 잘 알고 있지만, 0을 의무화하는 것이 항상 옳은 답은 아니다.온도 그래프는 세 가지 면에서 좋은 예다.그래프가 화씨일 경우, 화씨 0도는 임의의 값이다.마찬가지로, 만약 당신이 어떤 사람들이 말하는 것처럼 섭씨나 섭씨도에 대한 과학적 선호도를 채택한다면, 0은 화씨와는 같지 않고 거의 임의적이다.그런 다음 이 두 값이 임의적이지만 비임의 값은 절대 영점이라는 점을 유념한다면 절대 영점을 영점으로 사용하고자 하는 온도 그래프는 거의 없을 것을 제안한다.

나는 파이 차트가 거의 좋은 생각이 아니라는 생각을 밀고 나갈 것이다.내가 놓치고 있는 근거도 있겠지만, 그룹 전체를 100%로 보는 어떤 그룹의 구성을 이야기할 때 파이 차트가 적절할 수 있다고 생각한다.

접속자 명단에 이름이 없는 것은 좋지 않은 생각이라는 것에 동의하기 어렵다.좋은 관행이 축에 이름을 넣는다는 것에 동의하지 않지만, 규칙으로 바꾸는 것은 문제가 될 수 있다.몇몇 예술가들이 축에 이름이 없는 유명한 그래프를 재현하고 있다고 상상해보라.그래프의 원본을 향해 솥 사진을 찍어도 괜찮지만, (대개 공공영역) 그래프의 충실한 복제에 인위적으로 이름이 포함되어야 한다고 주장해서는 안 된다.

머리 위에서 좋은 예를 떠올리지 않는 동안, 그 범위를 100%로 강제하는 것이 항상 가장 좋은 생각인 백분율 그래프를 생각해 낼 수 없다면 나는 놀랄 것이다.(%가 100%를 초과할 수 있다는 사실은 말할 것도 없고, 따라서 규칙을 강요하는 것은 문제가 될 것이다.

네거티브에만 집중한 것에 대해 사과드리지만, 우리는 최상의 형식이 아닌 형식을 인위적으로 시행하지 않는다는 규칙을 시행할 때 신중할 필요가 있다.S 필브릭(토크) 02:17, 2019년 1월 1일 (UTC)[응답]

Spilbrick 나는 물건을 부과하는 것보다 좋은 채무 불이행에 더 가깝다.예를 들어, 나는 0을 최소값으로 의무화하고 싶지 않지만 만약 값이 제공되지 않는다면 우리는 0을 사용해야 한다.

파이 차트에 관한 페이지는 다음과 같이 시작한다: "파이 차트는 비즈니스 세계와 대중 매체에서 매우 널리 사용된다.하지만, 그들은 비난을 받았고, 많은 전문가들은 연구 결과 주어진 파이 차트의 다른 부분들과 비교하거나 다른 파이 차트의 데이터를 비교하는 것이 어렵다는 것을 보여주었다고 지적하며, 그것들을 피하라고 권고하고 있다.대부분의 경우 원형 차트를 막대 차트, 상자 그림 또는 점 그림 같은 다른 그림으로 대체할 수 있다."그 페이지에서 참조를 찾을 수 있다.

나는 우리가 조심할 필요가 있다는 것에 동의하지만, 나는 우리가 모범 사례에 대한 문서와 템플릿에 더 나은 디폴트를 사용함으로써 더 똑똑해질 수 있다고 생각한다.가가린 (대화) 2019년 1월 1일 18시 30분 (UTC)[응답]

Gagarine, 우리는 당신의 목표가 규칙을 강요하는 것이 아니라 좋은 조언을 제공하는 것이라면 같은 입장에 있다.최근 올린 글에서 "나는 강요하는 것보다 디폴트(채무불이행)에 더 가깝다"고 말한 것이 그런 경우인 것 같다.그러나 "두 가지 값이 막대 차트를 사용하도록 강제하는 더 많은 용도로 파이 유형을 사용하는 경우(수정)"를 제안한다.충고라기 보다는 명령처럼 들리는군

나는 투프테의 팬이다.내가 그의 주목할 만한 작품을 읽은 지 꽤 오래되었고 나는 그가 파이 차트를 싫어하는 것을 기억하지 못했지만, 나는 그를 나쁜 파이 차트에 반대한다고 읽었고, 아마도 그것들이 결코 적절하지 않다고 제안함으로써 약간 지나친 수행일 것이다.(원문을 다시 읽으러 간 것은 아니지만 몇 가지 요약을 알아보고 있다.)

다가오는 115회 미국 의회에 대한 우리의 기사는 회원국의 분열을 보여주는 멋진 그래픽을 가지고 있다.각각의 점들을 사용하는 것이 파이 차트보다 틀림없이 더 낫지만 나는 명백하지 않은 것에 반대하여 논쟁할 수 있다는 것을 강조할 것이다.프레젠테이션을 하는 모든 사람이 그러한 그래픽 기능에 쉽게 접근할 수 있는 것은 아니다.이 사이트에서 지적한 바와 같이, 나쁜 파이 차트는 매우 형편없는 도구가 될 수 있지만, 자연스럽게 일부에서 100%의 값에 대해 막대 차트를 사용하는 것이 반드시 파이 차트보다 선호되는 것은 아니다.두 가지 가치에 대해 예외를 포함했다는 것을 알지만, 정당 붕괴를 보여주는 미국의 정치 기사는 그 가치가 100%에 더해지고, 일반적으로 두 개의 지배적인 가치를 가지고 있지만 종종 세 번째(또는 그 이상)를 가지고 있으며, 가장 중요한 단 하나의 정보는 어느 정당이 가장 큰지 그리고 그것이 50%를 초과하는지 여부다.두 서너 개의 값을 가진 파이 차트는 그것을 깨끗하고 즉시 전달한다.막대 차트도 그 일을 해내지 못한다.정확히 두 개의 값이 있어야만 파이 차트를 사용할 수 있다는 규정을 부과하는 것은 제3자 후보가 없을 때 파이 차트를 사용하지만 제3자 정치인이 조금 있으면 막대 차트로 바꾸겠다는 어처구니없는 결과를 초래할 것이다.

이 링크는 파이 차트가 오용될 수 있는 예를 보여주고 있다. 그래서 다시 말하지만, 우리가 그들의 오용을 피하고 싶다면, 우리는 같은 입장이지만, 내 우려는 당신의 제안이 조언처럼 들리지 않고 규칙을 강요하는 것처럼 들린다는 것이다.S 필브릭(토크) 16:39, 2019년 1월 2일 (UTC)[응답]

나는 다양한 차트와 그래프의 형식이 특정한 관점을 뒷받침하기 위해 마사지가 될 수 있고, 종종 되어왔고, 이러한 셰나니건들은 WP에서 설 자리가 없다는 것에 동의한다.이것의 가장 터무니없는 예는 숫자의 차이를 강조하기 위해 기원을 예기치 않은 위치에 배치한 것이다.그러나 나는 WP에서 나쁘거나 오해의 소지가 있는 포맷 선택의 대부분의 예가 의도적인 나쁜 설계보다는 좋은 설계를 구성하는 것에 대한 무지의 결과로서 본질이 더 순수하다고 의심한다.그 제안에 대한 나의 반대는 시각적 정보의 설계가 크고 복잡한 주제라는 것이고 아마도 그 주제에 대한 적절한 표준 작업에 편집자들을 참고하는 것이 더 나을 것이다.우리는 WP 정책에 시카고 매뉴얼이나 Strunk and White를 포함하려고 하지 않으며 마찬가지로 Tufte의 '양적 정보의 시각적 표시'를 WP 정책에 요약하려고 해서는 안 된다.차트와 그래프가 명확하고 안정적으로 소싱되고, 다른 편집자들이 필요에 따라 쉽게 디자인을 수정하고 개선할 수 있다는 점이 더 걱정된다. --RDBury (토크) 07:07, 2019년 1월 9일 (UTC)[응답]

내가 이 논쟁에서 본 바로는, 일반적인 합의는 그래, 우리는 나쁜 그래프 관행을 피해야 하지만, 아니다, 우리는 너무 많은 예외/규정이 있다고 해서 특정한 것들을 강요해서는 안 된다는 것으로 보인다.공식적인 규칙 변경이나 템플릿 변경 대신 에세이를 쓰라고 제안해도 될까?또는 코드에서 특정 사항을 구현하지 않고 템플릿 설명서에 이러한 지침을 추가하시겠습니까? Integrated Python 15:37, 2019년 1월 11일 (UTC)[응답]

"날짜봇"(제한 범위)

바스트 RC, 크로 CM, 아이티 WN, 홍 WK, 쿠페 DW, 피카르트-게브하트 M, 폴록 RE, 웨이첼바움 RR, 양 H, 홀랜드 JF(2016년 10월 3일).홀랜드-프리 암 의학.와일리, ISBN 978-1-118-93469-2클레인스미스 LJ(2006년).암 생물학의 원리.피어슨 벤자민 커밍스ISBN 978-0-8053-4003-7무케르제, 싯다르타 (2010년 11월 16일)모든 말라디아의 황제:암 전기.사이먼 & 슈스터.ISBN 978-1-4391-0795-92013년 8월 7일 회수Pazdur R, Camphausen KA, Wagman LD, Hoskins WJ (2009년 5월)암 관리: 다원적 접근법.Cmp United Business Media.ISBN 978-1-891483-62-2구글북스의 암.2009년 5월 15일 원본에서 보관.타녹 1세(2005년).종양학의 기본 과학.맥그로힐 프로페셔널ISBN 978-0-07-138774-3슈와브 M (2008년 9월 23일)암 백과사전.스프링거 사이언스 & 비즈니스 미디어.ISBN 978-3-540-36847-2

"날 괴롭혀" 봇

개요

이전 토론:위키백과:Bot_reminds#Remind_me_bot.

이 아이디어는 요청에 따라 특정 페이지로 돌아가라는 알림을 보내는 봇/템플릿 쌍을 만드는 것이다.사례 사용은 일반적으로 감시목록이 비효율적인 고교통량 페이지에 대한 토론을 다시 확인하는 것이다. 또는 (반대로) 토론의 참여가 거의 없고, 합의점을 평가하기 위해 일주일 후에 다시 돌아오기를 원할 때.

상기 내용은 인 wp 포스팅의 형태를 띠기 때문에, 그러한 봇은 WP:BRFA에 의한 합의가 필요하다. 나는 VPP가 그 토론을 위한 최고의 (또는 최소한 더 나쁜) 포럼이 될 것이라고 믿지만, 내가 뭔가를 놓쳤는지 아닌지는 말해라.

계획된 기술 구현

템플릿(예:{{remind me}}고정된 날짜 또는 지속 시간 중 하나의 인수가 필요한 경우 사용자가 상기시키기를 원하는 페이지에 남겨둔다.Toolforge 봇(매시간 또는 그 정도 실행?)이 템플릿의 전횡을 감시한다.시간이 지나면 봇은 요청 사용자의 토크 페이지에 공지사항을 게시한다.

이 프로세스에 의해 알림을 요청하는 것은 공개적이다(즉, 다른 편집자는 업데이트를 요청한 경우, 업데이트를 요청한 경우 등을 알고 있음).

기술적 세부사항에 따라, 그리고 그 템플릿이 널리 사용될 경우, 사용에 제한을 둘 필요가 있을 수 있다.사용자당 보류 중인 알림은 X개 이상(크리스마스 2118에 대해 보류 알림을 넣을 수 있지만 슬롯 중 하나를 차지함)하지 않는 것이 좋다.나는 X=10이 그것에 관한 한 합리적인 출발 값이라고 생각하지만, 그것이 완전히 필요한 것은 아니라고 생각한다.

가능한 이의 제기

1. 봇 게시물 자체는 상당히 악의적이지 않지만(당신이 그것을 요청해야만 그것을 얻을 수 있다), 리마인더 요청 템플릿에는 여전히 다소 잡음이 있을 수 있다: 예를 들어, 100개의 포스터가 5명이 실제로 참여하는 토론에서 "날 없애줘" 템플릿만 떨어뜨릴 경우.나는 (1) 상당히 추측성적이고 (2) 그것이 문제가 된다면 (예를 들어, "지나치게 의미 있는 게시물 밖에서 이 템플릿을 사용하지 않는 것, 이것은 파괴적인 것으로 간주될 수 있기 때문에)" 수행 지침으로 해결될 수 있다고 믿는다.
2. 이전 논의에서 지적했듯이, 그것은 상위 10개 항목 중 하나였던 커뮤니티 위시리스트 항목을 복제할 수 있다(따라서 WMF 직원이 작업할 것이다.나는 사용 사례가 약간 다르다고 믿고 있다(기사와는 달리, 대화 페이지를 대상으로 한다) 그리고 그것이 정말로 중복된다 하더라도 나는 해를 보지 않는다. (봇 코딩을 다루는 사람이 될 것이기 때문에, 시스템을 복제하는 데 낭비되는 시간은 무시할 수 있다.코디하면 재밌을 것 같아.유일한 문제는 두 개의 시스템을 갖는 것이 쓸모없는 것이 아니라 해로운 것일지도 모른다는 것이다.)

댓글

나는 더 좋은 디자인을 가지고 있다.

동일한 고정 날짜/시간 인수를 사용하여 자신의 토크 페이지(또는 특별한 페이지)에 배치하는 봇을 만드십시오.

만약 내가 말한다면

{{remindme 03:14, 2038년 1월 19일 (UTC) Check [[Talk:응답용 Cockcroft-Walton 생성기]]}}

적절한 페이지에. 2038년 1월까지 기다렸다가 내 토크 페이지에 다음을 게시할 것이다.

봇 알림 통지

1970년 1월 1일 03:14 (UTC) 03:14, 2038년 1월 19일 (UTC) 주의사항을 요청하셨습니다.상기 알림의 텍스트:

대화 확인:응답용 Cockcroft-Walton 생성기

- [봇 서명]

그렇게 하면 어떤 것이든 상기될 수 있을 것이다.블록이 만료된 후 일주일 후에 차단된 IP 반달의 편집 기록을 확인하도록 알림에 사용하는 유사한 알림 세트가 로컬에서 있음.그래야 반달로 돌아가면 신고할 수 있어

오용을 줄이려면:

어떤 반달인이 요청을 삭제하더라도 상기 알림은 발생해야 한다.

독촉을 취소할 방법이 있어야 한다.

사용자 또는 관리자는 해당 사용자에 대한 주의사항을 취소할 수 있어야 한다.

주의사항은 255자로 제한되어야 한다.

사용자는 32개 이하의 공개 주의사항 요청으로 제한되어야 한다.

FAQ는 이것이 위키피디아와 관련된 용도로만 사용된다는 것을 설명해야 한다; "베게마이트를 더 구입하는 것을 잊지 말라"는 독촉 요청을 잊지 말아야 한다.

가능하면 다른 사람의 대화 페이지에 표시되도록 주의사항을 설정하는 것이 불가능하거나 최소한 어려워야 한다.

--Guy Macon (대화) 14:06, 2018년 12월 18일 (UTC)[응답]

@Guy Macon:사용자 "JSON" 페이지에서 이 작업을 수행한 경우(예: 사용자:예/remindme.json)은 봇이 요청을 구문 분석하는 것이 더 간단하고, 동일한 사용자에 의해 편집이 제한되거나 관리자에 의해 제한되는 경우(반달리즘은 문제가 되지 않으며, 해당 요청이 지정된 시간에 존재하는 경우에만 주의사항이 발송되는 경우, 첫 번째에만 주의를 기울이도록 함) 요청을 제한할 수 있다(나는 첫 번째에만 주의를 기울임).32 json 객체).생각? --DannyS712 (대화) 00:59, 2018년 12월 27일 (UTC)[응답]

• 그냥 봇 없는 디자인을 만들면 안 돼?XXX 시간까지 공백으로 표시되는 템플릿을 사용자 페이지에 넣은 다음 표시할 주의사항을 표시하십시오.어떤 페이지에서도 이러한 주의사항을 자동으로 추가하는 사용자 스크립트를 만들 수 있을 것이다.—쿠스마 (t·c) 11:04, 2019년 1월 12일 (UTC)[응답]

  @Kusma : 사용자 스크립트 작업을 시작할 수 있었는데, (내 생각엔) 스크립트가 대본이기 때문에 커뮤니티 승인(봇처럼)이 필요 없고 사용자 공간에서 편집만 할 것... --DannyS712 (토크) 17:33, 2019년 1월 12일 (UTC)[응답]

커뮤니티 위시리스트

안녕 얘들아, 내가 뭔가를 잘못 읽고 있을 수도 있지만, 이것이 지역사회의 위시리스트 기사 리마인더스의 상위권에 있는 것 같지 않니?코백베어(토크) 19:55, 2018년 12월 18일 (UTC)[응답]

그렇다.관심 있는 IMO 사람들은 대부분 같은 일을 하기 위해 봇을 서둘러 구현하기 보다는 그러한 기능의 생성에 관여해야 한다.아노미에 03:02, 2018년 12월 19일 (UTC)[응답]

그래, 아노미도 동의해지금 당장은 봇/사용자 대본에 너무 많은 시간을 투자하지 않을 것이다.장기적인 해결책은 결국 미디어위키 확장이 될 수 있는데, 이는 봇 게시물에 대한 가능한 이의제기를 다룰 것이다.나는 그 구현이 어떤 페이지에 대해서도 상기시킬 수 있을 것이라고 의심한다.확실히, 이 프로젝트는 WMF에 의해 "소유"된 것이 아니라, 이제는 그들의 책임이다.과거 자원봉사자들이 시행한 10대 소망도 있었다.따라서, 만약 여러분이 코딩을 가장 간절히 원한다면, 확실히 코딩의 일부가 될 수 있다:) 우리는 먼저 필요한 워크플로우를 수용하고 모든 위키에서 작동할 솔루션인 올바른 솔루션을 찾아야 한다.— 뮤지크애니멀 23:34, 2018년 12월 30일 (UTC)[응답]

토크 페이지 상태: 편집자가 토크 페이지의 상태를 순위를 매길 수 있는 순위 지정 템플릿.

배경

2018년 7월 위키미디아는 보조금 아이디어 연구소에서 제안서를 요청했다.그 요청은 위키백과 커뮤니티의 건강을 향상시키기 위한 아이디어를 요구했다.내 첫 번째 생각은 위키피디아의 일부 고압적인 영역은 잘 밀거래되고 감시되지만, 토론 건강이 문제가 될 수 있는 다른 덜 눈에 띄는 영역은 있을 수 있다는 것이었다.

제안(건강 등급)

라디오 단추, 확인란 또는 단일 선택 옵션이 있는 대화 페이지의 상태 순위를 매기는 대화 페이지 상단에 선택적으로 배치될 수 있는 템플릿을 만들려면

• 그 때 정보가 있을 것이다.
  • 피드백이 필요한 영역을 식별하는 데 사용
  • 주의가 필요한 영역에 대한 통계 데이터 작성

위키미디어 제안 페이지

이 제안에 대한 몇 가지 논의가 위키미디어에서 이루어졌다.

• 이 논의는 다음을 포함한다.
  • 제안서에 대한 기본 설명
  • 몇 가지 스크린샷 예
  • 프로젝트에 필요한 전문가 및 공동작업자 요청
  • 엔위키 진행 방법에 대한 몇 가지 아이디어.

이 제안서는 위키백과_talk에서 언급되었다.커뮤니티_health_initiative_on_영어_위키백과

에다함 (대화) 02:52, 2019년 1월 4일 (UTC)[응답]

토론(건강 등급)

순위 기준은?개인적인 의견?만약 그렇다면, 이것은 어떤 유용한 목적에 도움이 될까?실행 가능한 결과가 있는가?····피터 사우스우드 : 06:00, 2019년 1월 6일 (UTC)[응답]

• 나는 특히 '건강하다'거나 '건강하지 않다'는 대화 페이지가 알고리즘으로 바뀔 수 있는 것이 아니기 때문에 이 점에서 요점을 모르겠다.헤드폭탄 {t · c · p · b} 15:21, 2019년 1월 6일 (UTC)[응답]
• 만약 누군가가 이것을 대화 페이지에 추가하려고 한다면, 나는 대량으로 되돌아가서 방해되는 것을 차단할 것이라고까지 말하고 싶다.자신이 좋아하는 페이지는 "건강하다"고 일방적으로 선언하고, 싫어하는 페이지는 "건강하지 않다"고 선언하는 것은 가능한 한 비법조적인 것이다.위의 다른 사람들에 따르면, 어쨌든, 여러분은 "건강하다"와 "건강하지 않다"는 어떤 것을 생각하는가?논쟁으로 가득찬 토크 페이지는 사람들로 하여금 논쟁을 일으키게 하기 때문에 건강에 좋지 않은 징조인가, 아니면 공동체가 관여하고 있다는 것을 보여주기 때문에 건강한 징조인가?6년 동안 단 한 건의 언급도 없던 토크페이지는 건강이 나빠졌다는 신호일까, 아니면 첨부된 글이 너무 환상적이어서 아무도 그것을 개선할 방법을 제안할 수 없다는 신호일까?당신은 어떻게 일반적인 미치광이 프린지들이 그들의 모든 친구들을 찾아가서 기후 변화, 로프 벌레 또는 게메르게이트 논란을 "건강하지 않다"고 투표하는 것을 막을 수 있는가?∙ 무지개빛 15:52, 2019년 1월 6일 (UTC)[응답]

  (추가) 이제 그 제안서를 "아니오"에서 "지옥, 아니오"로 바꾸면서 전부 다 읽었다.모든 것은, 단도직입적으로 말하면, 위키피디아가 어떻게 운영되는가에 대한 완전히 말도 안 되는 개념으로, "주제에 대해 더 많은 분쟁 해결이 이루어질수록, 그 주제가 더 건강하다"는 근본적인 오해에 기초하고 있다.∙ 무지개빛 16:34, 2019년 1월 6일 (UTC)[응답]

"고마워" 로프 웜에 연결시켜줘서.나는 아마도 그것을 알 필요가 없었다.오 인간성! p --Elmidae (토크 · 기여) 16:54, 2019년 1월 7일 (UTC)[답글]

• 문제를 찾는 해결책으로 보인다. - 시투시(대화) 16:01, 2019년 1월 6일 (UTC)[응답]
• 이것이 무엇을 의미하는지 확실하지 않지만, 확실히 문제를 찾는 해결책이라는 생각이 든다.우리가 "토크 페이지의 건강"이 무엇을 의미하는지 좋은 정의를 보기 전까지는, 나는 이것이 필요하다고 생각하지 않는다.aldgyth - Talk 16:27, 2019년 1월 6일 (UTC)[응답]
• 아니. 문제를 찾는 해결책.페이지 건강에 대한 에다함의 해석은 대단히 거칠고 부정확하다.이리가 하는 말.∯WBG^converse 16:50, 2019년 1월 6일 (UTC)[응답]
  • 어, 진정해?나는 다른 위키 프로젝트에서 읽은 몇 가지 토론을 통해 도움을 주려고 했다.그 아이디어는 백과사전의 문제 영역을 식별하고, 지역사회가 페이지에 걸쳐 불평을 등록할 필요 없이 피드백을 줄 수 있도록 하는 것이다.나는 이런 성질의 청혼을 해 본 적이 없으니 부디 선의를 가지도록 하시오.나는 페이지 건강에 대한 "해석"을 실제로 제안하지 않았고 일부러 열어두었다.당신이 참조한 페이지는 템플릿을 통해 도달할 수 있는 페이지의 예였다(실제로 페이지 상단에 그렇게 적혀있었지만, 그 이후 혼란을 피하기 위해 비워두었다). 그래서 내 제안의 어떤 부분이 "거짓말" 또는 "거짓말"이라고 불릴 수 있을지, 혹은 "거짓말이라고 불릴 수 있을지 모르겠다.날개가 달린 신의 칼날.그 아이디어는 결과적인 평균이 표시되지 않고, 문제가 되는 부분이 어디에 있는지 알고 싶어 하는 사람들이 기록되고 이용할 수 있게 된다는 것이다. 그리고 시간이 지남에 따라 건강에 대한 아이디어를 준다.따라서 "대량 하향식"은 문제가 있는 지역에 대한 경계심을 갖는다는 관점에서 바람직할 것이다.피드백 시스템이다.그래도 댓글 달아줘서 고마워.내가 너의 하루를 너무 오래 끌지 않았길 바래.에다함 (대화) 00:57, 2019년 1월 7일 (UTC)[응답]
• 있음직하지 않다.이 아이디어는 두 가지 문제가 되는 아이디어를 떠올리게 하는데 하나는 미국 소셜미디어에 만연한 '상향투표'와 '하향투표'이고 다른 하나는 중국 정부가 추진 중인 '사회적 신용' 제도다.이 두 가지 모두 같은 문제를 안고 있다. 즉, 신뢰할 수 없는 게으름뱅이들, 즉 미국의 경우 무지한 당파적 폭동이나 중국인의 경우 사악한 당 엘리트 AI가 그것이다.위키피디아의 경우, "중립적인" 편집자들이 등급을 매기기 위해 어떤 노력을 기울일 수 있다는 것은 충분히 상상할 수 있다; 나는 오랫동안 분쟁 해결을 위한 배심원 제도를 선호해 왔다.하지만 당신이 배심원들에게 간청하고 있고 공정한 결정을 원하며 무작위적이고 투명한 선택 과정을 원한다는 것을 명시하지 않은 채 그렇게 하는 것은, 한 페이지에 대한 평가보다는 문제를 해결하는 쪽으로 모든 것을 목표로 삼을 것이다…. 글쎄, 이것이 되기 전에, 내가 원하는 많은 세부사항들이 있다.Wnt (토크) 01:06, 2019년 1월 7일 (UTC)[응답]

먼저 투표 결과를 표시할 필요가 없다는 점을 명확히 하기 위한 간단한 두 번째 의견.사용자가 토론을 하지 않아도 경험치를 평가할 수 있는 기회다.우리는 사람들이 듣기 위해 그것을 갈고 닦아야 하는 많은 영역을 가지고 있다.우리는 사람들이 쉽고 익명으로 일반적인 피드백을 제출할 수 있는 시스템을 가지고 있지 않다.수집된 데이터는 사람들이 이 정보를 제출한 영역에 대한 열 지도를 제공하여 일반적인 규모의 상호작용과 만족도를 모두 알려준다.

두 번째:나는 완전히 wp:MIAB 호환이니 히트인지 미스인지 편하게 말해줘.무뚝뚝하다.난 미친놈이라고 불리는 건 싫어가능하다면 그러지 마, 건배.에다함 (대화) 01:19, 2019년 1월 7일 (UTC)[응답]

음, '열 지도'의 가장 큰 문제는, 내가 그것을 이해하는 방식으로는, 사람들이 서로에게 격노하는 토크 페이지를 찾는다는 것이다.그런 토크 페이지를 찾으면 누구나 다 분쟁이 있다는 것을 안다.그들 중 일부는 10년 이상 "위키피디아의 가장 작은 편집 전쟁" 목록에 올라 있다.아마도 그곳의 편집자들은 진정으로 무관심한 당사자들에 의한 어떤 종류의 중재를 원하겠지만, 위키피디아는 그렇게 하는 것을 극도로 어렵게 만든다.새로운 편집자가 프락카스에 합류하여 공정한 질서를 부여하려고 할 때마다, 그들은 결국 논쟁에 말려들게 된다.

또한, 위키피디아 엘리트에게 비밀스러운 결과를 제공하는 도구를 개발하는 것이 편집자 간의 불평등을 더욱 심화시켜 프로젝트 전체의 하락에 기여할 수 있을지 염려된다.우리는 컴퓨터가 -> 소유권 -> 특권 -> 독재라는 불건전한 역동성을 가지고 있으며, 그것은 "매체는 메시지"이며, 온라인 콘텐츠 유통은 단지 완전히 실패할 운명이라고 주장할 수 있다.어떤 반작용 세력이 고안될 수 있을지 모르지만, 그 동안 나는 새로운 구별과 특권을 끌어내는 것을 매우 경계한다.

마지막으로 빠른 시청률은 피상적일 수밖에 없다는 측면이 있다.만약 하플로타입에 관한 기사가 오류투성이라면, 당신은 30분 동안 앉아서 여러 개의 논문을 검토해야 할지도 모른다.그림 속 여성이 벌거벗은 상태라면 무작위 독자는 몇 초 만에 불평할 수도 있다.그래서 나는 그런 시스템에서 나오는 어떤 결과도 그다지 심각하게 받아들이고 싶지 않을 것이다.Wnt (토크) 01:59, 2019년 1월 7일 (UTC)[응답]

• 알트 제안.우리는 편집자들이 거의 보지 않는 많은 토크 페이지들을 가지고 있다. 나는 내가 프로젝트에 산재한 질문의 수에서 이것을 안다.위키피디아 주제별 또는 질의가 제기된 이후 시간별로 열린 질의와 함께 기사 대화 페이지를 나열한 AI 등이 있으면 좋을 것이다.이러한 페이지를 사용할 수 있는 목록을 확보하는 것이 유용할 것이며, 방해가 될 필요는 없으며, 만약 토크를 업데이트하지 않고 기사를 편집하여 질의를 해결했다면 누구든지 섹션에 {{done}}을(를) 추가하는 것이 간단해야 한다.ϣereSpielCequers 14:10, 2019년 1월 7일 (UTC)[응답]

  이것은 간단히 예를 들어 검토하면 될 수 있다.특수:최근 변경 사항 링크/템플릿:위키프로젝트 비디오 게임. --Izno (토크) 16:09, 2019년 1월 7일 (UTC)[응답]

  멋진 속임수야, 난 몰랐어. 그리고 내가 제안하는 것의 일부분을 하는 것도 알 수 있어.그러나 부분적으로만 기사 평가, 다른 위키프로젝트 및 기타 편집에 대한 태그 지정, 집중될 위험이 있다.일주일에 한 번 이상 이곳에 오는 열성 팬이라면 효과가 있을 것이라고 확신하지만, 한 달에 한 번쯤 불쑥 찾아 오는 사람, 혹은 오랫동안 휴면 중인 위키피디아 주제를 탐구하는 사람 등을 더 생각하고 있었다.이러한 시나리오에서는 미결된 쿼리가 있는 토크 페이지를 나열할 수 있는 것이 유용할 것이다.위키프로젝트에서 좀 더 관련성 있는 것으로 바꿀 수 있을 것 같은데.ϣerSpielCequers 21:32, 2019년 1월 7일 (UTC)[응답]

• 아니 - 우리는 우리의 백과사전을 발전시키고 발전시키기 위해 여기에 있다.어떤 토크 페이지가 건강하고 어떤 것이 건강한지 지시하는 데 주저하지 않고, 문제를 찾는 솔루션이 바로 그것이다. –Davey2010^Talk 21:25, 2019년 1월 7일 (UTC)[응답]

• '건강'에 대한 정의도 없고, '건강'에 대한 정의도 분명히 개인이 스스로 결정할 몫이기 때문에 1-5점 만점에 대한 가이드도 없기 때문에, 이것은 전혀 이해가 되지 않는다.그것은 무언가를 정량화하려고 하지만, 그것이 실제로 무엇인지에 대한 객관적인 정의가 없다면, 어떤 점수도 완전히 무의미할 것이다.또한 '나쁜 건강'을 바로잡는 것이 관리자들의 일이어야 한다는 생각은 제안자가 관리자의 역할을 이해하지 못한다는 것을 시사한다.보잉! 제베디(토크) 14:45, 2019년 1월 13일 (UTC)[응답]

응답

• • 데이터 수집 시스템에 대한 제안으로서, 이것은 문제에 대한 직접적인 해결책은 아니지만, 만약 그것이 그렇게 틀이 잡혔다면 다음과 같이 고려할 수 있다.
    • 커뮤니티 피드백이 대부분 토론에 기반하고 있기 때문에 평가와 정량화가 어려울 뿐만 아니라, 현재 피드백 평가 시스템은 토론에 기여하기를 원하지 않거나 더 이상 원하지 않는 사람들의 피드백을 허용하지 않는다.사람들은 간단히 대화만 하고 나서 그 경험에 대해 어떻게 생각했는지 우리에게 말할 수 없다.이것은 우리가 시간을 들여 자신의 의견을 반복해서 말하는 사람들로부터 불균형적으로 듣는다는 것을 의미한다.본질적으로 우리는 한 가지를 가지고 있다.우리는 다른 하나를 가지고 있지 않다.우리 둘 다 가져야 할 것 같아.
    • 집단 투표, 투표 부재, 풍부한 투표는 모두 공동체 행동의 지표로, 이 시스템을 통해 볼 수 있을 것이다.100% 정품 편집자에 의한 정확한 투표는 그러한 시스템에서는 가능하지도 바람직하지도 않다.
    • 수집된 데이터에 대한 평가는 우리가 아직 고려하지 않은 인기, 갈등 영역, 그리고 그것에 대처하는 방법에 대한 통찰로 이어질 것이다.이러한 것들 중에는 커뮤니티 보건 평가에 대한 시간 기반 접근법이 있을 것이며, 이는 시간이 지남에 따라 건강의 지표를 제공할 수 있으며, 사용자 경험 개선을 목적으로 하는 다른 이니셔티브의 효과에 대한 통찰력을 제공한다.
    • 따라서 간단히 말해서, 문제는 우리가 공동체 경험의 건강에 관한 일반적인 데이터를 수집할 수 있는 수단이 없다는 것이며, 나는 그것을 수집할 수 있는 방법을 제안하고 있다.

나는 이것을 나보다 더 많이 팔고 싶지 않다. 그래서 나는 이 제안이 거절될 가능성이 있는 사건에서 위키피디아 사람들이 그들의 경험에 대해 우리에게 말하는 방법을 고려하고 우리의 현재 방법이 의견이 있지만 성향이 없는 사람들을 부당하게 배제하는지를 고려해야 한다고 말하면서 나의 제안을 끝낼 것이다.우리의 토론 페이지에 그것을 공개적으로 공유하자는 의견바라건대 이 점에 대한 고려가 제안서의 개선이나 더 나은 아이디어로 이어지기를 바란다.대담한 텍스트는 미안하지만 몇 가지 포인트를 더 돋보이게 하고 싶었어.

에다함 (대화) 02:11, 2019년 1월 7일 (UTC)[응답]

만약 사람들이 자신의 의견을 공개적으로 표명하려고 하지 않는다면, 그들은 여기서 목소리를 낼 특별한 권리가 없다.위키피디아의 핵심 포인트 중 하나는 협업이며, 비밀투표는 그것을 이루기 위한 방법이 아니다.따라서 여기서 비밀로 하는 것은 ArbCom 투표와 법적으로 보호되는 정보(예: checkuser)뿐이다.

당신의 제안은 사람들을 착취하려는 시도에서 훨씬 더 극단적으로 변형된 "친절한 공간"의 버전인 것 같다.실생활은 고달프고 실생활은 상호작용이 필요하다(은둔자가 아니라면), 실생활은 의견 불일치를 수반한다: 셀 수 있으려면 일어서야 한다.어쨌든, 다른 사람들이 지적했듯이, 이 제안의 방법과 기초 이론 모두 치명적인 결함이 있다. - 시투시 (토크) 13:34, 2019년 1월 7일 (UTC)[응답]

파티에 조금 늦게 도착하는 거 맞지?스티로폼 컵을 치우러 오셨나요?투표하는 것과 조사 자료를 수집하는 것은 같지 않다.정말 연결되지 않는 것이 바로 그것이다.에다함 (대화) 15:53, 2019년 1월 7일 (UTC)[응답]

뭘 해?며칠 전에 내가 한 말 봤니?어떤 일에도 늦지 않았다.네 제안이 무산된 것에 화가 나겠지만 그럴 필요는 없어.만약 지금 당신의 제안의 문제점을 볼 수 없다면, 아마 결코 그렇지 않을 것이다.하지만, 나는 당신의 설명에 응답했다: 사람들이 익명으로 불평하는 것을 허용하는 것은 도움이 되지 않는다.문제가 있어서 고치려면 좆까, 아니면 솥에서 내려놔야 한다. - 시투시 (토크) 16:09, 2019년 1월 7일 (UTC)[응답]

와우.내려오길 잘했어!위키백과에서 이겼어!난 전혀 화나지 않았어.믿을 수 없다는 말이 바로 그 말이다.많은 양의 데이터를 수집하기 쉬운 대형 프로젝트에서 설문조사는 드문 일이 아니다.위키피디아는 실제로 고객이 없기 때문에 고객만족에 전형적인 개념은 다소 이질적일 수 있다.난 그걸 이해해.다른 제안이 있으십니까?그 제안과 그 결과들이 다소 오해를 받고 있다고 생각하지만, 나는 제기된 우려를 이해할 수 있다.생각해보고 좀 정리되면 아이디어를 다시 제출하도록 할게.에다함 (대화) 16:33, 2019년 1월 7일 (UTC)[응답]

애초에 말했듯이, 당신이 존재하지 않는 문제에 대한 해결책을 찾으려고 하는 것 같기 때문에 다른 제안은 없다.조사가 이루어질 수 있다고 해서 그것이 이루어져야 한다는 뜻은 아니다.그리고 당신이 나와 스트로피를 하지 않았다면 나도 비슷한 맥락으로 반박하지 않았을 것이다. - 시투시 (대화) 16:46, 2019년 1월 7일 (UTC)[응답]

나는 그것이 친절하고 건방진 농담이라고 생각했다.나는 네가 게으름을 피우는 것 같지 않았어.사실 매우 흥미로운 단어인데 어원이 모호하다.말하자면, "스트롭"은 더 이상 그것을 망쳐놓는다. 왜냐하면 그것은 그렇게 되면 가죽을 갈고 닦는 낱말과 발음을 공유하기 때문이며, 원래 단어와 관련이 없는 어원이기 때문인데, 이것은 빨갱이와 동의어인 것이다.아마 다른 곳에서 논의될 겁니다.이 특별한 조사가 이루어져야 하는 이유는 만약 그러한 데이터가 쏟아져 들어온다면, 시간이 지남에 따라 그것의 변화를 검토하는 것이 다른 시책의 영향을 측정하는 데 사용될 수 있기 때문이다.우리가 노력한 무언가가 희망적인 효과를 얻었는지 아닌지를 알아내는 것은 직업이다. 그것은 우리가 미래에 노력을 낭비하는 것에서 멀어지게 할 것이기 때문에 이루어져야 한다.만약 우리가 토론의 목적을 그 중요한 점으로 줄이고 거기서부터 쌓아간다면 우리는 더 나은 것을 생각해낼 수 있을 것이다.내 말은, 왜냐하면 나는 내심 낙관론자라서, 조금 더 따뜻해지면 결국 에다함 캠프로 돌아올 거라고 믿기 때문이야.에다함 (대화) 17:01, 2019년 1월 7일 (UTC)[응답]

이게 진짜 문제(저교통 토픽 페이지)에 도달하고 있지만, 처음부터 투표에 대한 것은 줄이고 토론과 합의는 더 많이 하고 있다.좋은 원칙, 나쁜 실행.비활성 토크 페이지를 활성화하는 가장 좋은 방법은 활발한 토론이나 편집자들이 관심을 갖고 싶어하는 것에 관한 공지사항을 다른 곳에 게시하는 것이다. - 프러시아어울 (토크) 23:08, 2019년 1월 8일 (UTC)[응답]

아마도 내가 원래 그 생각을 틀에 박아놓은 방식 때문에, 내 잘못 때문에, 우리는 투표라는 생각을 극복하는 데 정말 많은 어려움을 겪고 있다.이건 투표가 아니야사람들은 결과에 투표한다. 우리가 커스터드나 아이스크림을 사막으로 가져갈 것처럼.이건 투표가 아니야아니에요.투표하는 게 아니에요.그 아이디어의 의도는 우리가 지역사회의 건강을 향상시키기 위한 다른 계획들을 가지고 있다는 것이다.우리는 그들이 긍정적인 영향을 끼치고 있는지 (보고 판단해서 제외한다면) 실제로 측정하지 않는다. (아니면 우리는?)만약 사람들이 대략 일정한 비율로 마케팅 데이터를 기부할 수 있다면, 우리는 그 비율을 측정하여 우리의 이니셔티브가 영향을 미쳤는지 확인할 수 있다.우리는 우리가 얻은 데이터와 그 장소를 개선하기 위해 우리가 하고 있는 일들 사이의 상관관계를 찾을 수 있을 것이다.이것을 하는 많은 방법들이 있고 내가 제안했던 것은 기초적이고 대략적인 스케치여서 그것이 명백히 그 아이디어를 망쳐 놓았다는 것이다.

내 말은, 당신은 아마도 지역 보건 이니셔티브와 "퇴직" 템플릿의 사용 빈도, 그리고 대화 페이지에서 외설적인 사용 사이의 상관관계를 찾을 수 있을 것이다. 그래서 확실히 이것만이 일을 처리하는 유일한 방법은 아니다.사람들은 이미 어휘적 입력과 파싱을 통해 그들의 일반적인 만족도를 보여주는 많은 데이터를 기여하고 있다.

또한 곁눈질로 친구 한 명이 내가 가볍고 유머러스한 정신으로 한 발언과 답변을 보게 했는데, 그들은 내가 하고 있는 대화의 성격을 볼 때 아마도 투박하고 경솔하게 말하고 있는 것 같다고 말했다.그런 경우라면 미안하다.나를 믿어줘. 나는 이 포럼에 아이디어를 기부할 수 있는 기회를 갖게 되어 매우 기뻐!에다함 (대화) 02:40, 2019년 1월 9일 (UTC)[응답]

빌리지 펌프 탭을 분할하여 별도의 "이력" 구성 요소 생성

"마을 펌프" 탭을 "정책/정책 역사", "기술/기술 역사", "제안/제안 역사", "아이디어 랩/아이디어 랩 역사", "기타/기타 역사"로 구분하십시오.이렇게 하면 빌리지 펌프의 다양한 구획을 검토할 때 "클릭"이 절약된다.단지 삽화 목적으로 지금 하고 있는 것처럼 이 용어를 반복할 필요는 없을 것이다.그리고 사실 용어는 공간을 절약하기 위해 수직으로 쌓을 수 있는데, 탭 이름 아래에 "역사"라는 이름이 붙을 수 있다.버스정류장(대화) 15시 20분, 2019년 1월 14일 (UTC)[응답]

이렇게 하면 클릭 한 번으로 무엇을 절약할 수 있을까?무슨 접속을 하려는 거야? --Izno (대화) 17:54, 2019년 1월 14일 (UTC)[응답하라]

"뭘 접근하려는 거야?"난 마을 펌프의 분업 역사에 접근하려고 했을 거야정책 분과, 제안 분과 및 기타 분과에서 전개되는 개발에 관심이 있다고 합시다.정책을 클릭한 다음 기록을 클릭하기 보다는 간단히 "정책 기록"을 클릭해 클릭 한 번을 저장하겠다.버스정류장(대화) 18시 15분, 2019년 1월 14일 (UTC)[응답]

이건 바보 같은 짓이야.다른 페이지로 이동하지 않고 상단의 이름 위에 마우스를 올려놓고 기록에 액세스할 수 있도록 자신의 보기를 사용자 정의하거나 팝업을 활성화하십시오.킬리움두드 (대화) 19:05, 2019년 1월 14일 (UTC)[응답]

고마워, 킬리웃두드.팝업을 활성화했어멋지다.나는 그것에 대해 알지 못했다.버스정류장(토크) 19:18, 2019년 1월 14일 (UTC)[응답]

후속 조치.난 그걸 껐다.귀찮다.버스정류장 (대화) 21:18, 2019년 1월 14일 (UTC)[응답]

해결됨

롤백 기능

내 제안은 사용자의 편집을 롤백한 후 자동으로 대화 페이지를 여는 것이다.나는 WP가 있다는 것을 안다.반짝반짝하지만 그것은 자동으로 작동하거나 대화 페이지를 여는 것은 아니다.선호에는 특징이 없다.만약 Java 스크립트나 기능이 있다면, 롤백업자들에게는 큰 도움이 될 것이다.고마워, Siddiqsazzad001 <토크/> 09:00 (UTC) 2019년 1월 14일 (회신)

@Siddiqsazzad001: Done Script made.사용자의 편집 내용을 롤백한 후, 사용자의 대화 페이지를 여십시오.롤백하기 전에 확인이 필요한 스크립트를 설치한 경우 작동하지 않음사용자: 참조:대니S712/롤백 토크 --대니S712 (토크) 09:27, 2019년 1월 14일 (UTC)[응답]

@DannyS712:고마워, 친구!그건 효과가 있다.나는 이 스크립트를 사용한 첫번째 사용자다.:) Siddiqsazzad001 <토크/> 14:58, 2019년 1월 14일 (UTC)[응답]

상을 드려야 하나?:P -Abelmoschus Escanticus (토크 • 기여) 15:03, 2019년 1월 14일 (UTC)[답글]

@Abelmoschus Escanticus: 나? 또는 Siddiqsazad001?idk... --DannyS712 (토크) 16:54, 2019년 1월 14일 (UTC)[응답]

아니 시디크사자드와 농담하는 것 뿐 :) -아벨모스쿠스 에스칼란투스 (토크 • 기여) 23:12, 2019년 1월 14일 (UTC)[응답하라]

@Abelmoschus Escanticus:물론이지그들은 이렇게 훌륭한 사용자 스크립트 아이디어를 가졌다는 이유로 상을 받을 자격이 있다... --DannyS712 (토크) 23:54, 2019년 1월 14일 (UTC)[응답]

페이지 삭제권 도입

• WP에서 "핵심 관리 툴킷을 스핀아웃"하는 논의를 시작했다는 코멘트를 여기에 남기고 싶다.PEREN. 잠시 시간을 내어 검토 및/또는 페이지에 추가할 숙제를 도와줘. --Izno (토크) 20:49, 2019년 1월 22일 (UTC)[응답]

기사를 편집할 때 WikiProject/주제 관련 가이드라인에 대한 링크를 표시하시겠습니까?

종종 처음 편집하는 편집자들은 자신이 편집하고 있는 특정 주제에 대한 지침을 아는 데 어려움을 겪는다.예를 들어 경험이 부족한 사용자는 위키프로젝트 스쿨(보통 상급자 이하 관리자를 나열하지 않고 학교/파이트송의 텍스트/리듬을 포함하지 않음)의 일반적인 지침을 알지 못할 수 있으며, 따라서 가짜를 할 수도 있다.나는 사용자가 페이지를 편집할 때 특정 기사에 대한 주제별 가이드라인에 대한 편리한 링크를 표시할 수 있는 방법을 찾을 것을 제안한다.그래서 조니가 애니메이션에 관한 기사를 편집하면 가이드라인에 대한 링크를 보게 된다.또는 수지가 자신의 고등학교에 대해 편집했을 때, 그녀는 주제별 가이드라인에 대한 링크를 보게 된다.그것은 또한 지침의 각 정립에 도움이 될 수 있다. 세부사항 앞에 "간단히"가 있는 것이다.WhisperToMe (talk) 03:46, 2019년 1월 8일 (UTC)[응답]

위키백과:편집통지서는 이미 그렇게 하고 있다.제안하는 대로 링크와 짧은 메모를 표시할 수 있으며, 활성화된 페이지의 편집 창 위쪽에서 활성화된다.–Ammarpad (대화) 06:19, 2019년 1월 8일 (UTC)[응답]

특정 WikiProject 태그로 태그가 지정된 페이지에 편집 알림을 자동으로 추가하는 방법이 있다면(모든 관련 페이지에 편집 알림을 수동으로 추가하는 대신 자동으로 추가됨) 좋을 것이다.WhisperToMe (talk) 10:22, 2019년 1월 8일 (UTC)[응답]

이는 MediaWiki를 통한 BLP 및 설명 페이지에 대해 수행된다.Common.js. 특정 범주의 기사가 공지사항을 표시해야 한다는 데 동의해야 한다.갤럽터 (pingo mio) 13:56, 2019년 1월 9일 (UTC)[응답하라]

팁 고마워!나는 먼저 학교 위키프로젝트에 다음과 같이 통보했다.위키백과 대화:위키프로젝트 학교# 위키프로젝트의 모든 페이지에 대해 프로젝트 가이드라인(학교 또는 학교 시스템/학군 기사를 만드는 방법에 대한 지침)으로 페이지노티스를 추가하시겠습니까?WhisperToMe (talk) 12:54, 2019년 1월 10일 (UTC)[응답]

Anime and managa, 중국, 일본 WhisperToMe (대화) 05:57, 2019년 1월 11일 (UTC)[응답]에도 통보

• @WhisperToMe: 여기엔 여러분이 모르고 있을 수 있는 몇 가지 문제가 있는데, 이것은 보기만큼 쉽지 않다.내가 알기로는 오직 BLP와 Dissambigation 페이지만이 Common.js를 통해 그러한 알림 주사를 가지고 있고, 그것들은 표준보다는 예외다.무엇보다도, 페이지를 설정하기 위해 구현되기 위해서는, 그들은 다른 분류와 무관하게 모든 구성원이 직접 참여하는 마스터 카테고리를 가질 필요가 있다.범주: 방법 보기리빙 피플 및 카테고리:디스컴버전 페이지는.이것은 현재 학교에 존재하지 않는다.범주:학교는 기사 자체가 아닌 하위 카테고리를 가지고 있다.먼저 그것을 바꾸려면 공감대가 있어야 한다.
  둘째, 카테고리에서 페이지 공지 편집:살아 있는 사람들은 핵심 정책을 보여주고 있는 반면, 카테고리:디스컴비게이션 페이지는 널리 받아들여지는 불명확한 가이드라인을 보여주고 있는데, 둘 다 위키프로젝트 통지가 아니다. 당신은 왜 하나의 위키프로젝트가 이것을 가져야 하는지, 그리고 만약 다른 위키프로젝트가 같은 것을 요구한다면 어떻게 해야 하는지를 강력하게 주장할 필요가 있다.이것은 당신이 카테고리에 대한 첫 번째 문제를 극복했다고 가정한다.학교.–Ammarpad (대화) 07:03, 2019년 1월 14일 (UTC)[응답]
  • 프로그래밍 문제를 알려줘서 고마워.나는 어떤 위키피디아 사람들이 이런 종류의 일을 가장 많이 경험했는지 궁금하다.
  • 나는 WP를 느낀다:프로젝트 편집자들이 다양한 콘텐츠 가이드라인(예: 위키백과_talk:WikiProject_Schools#Request_for_comments:_What_administrators_to_list_on_school_articles) 프로젝트 범위의 모든 기사를 대상으로 하고 프로젝트 구성원에 의해 시행되는 긴 학교 관리자 목록을 계속 기사에 추가하기 때문에 이루어진 것이지만, 편집 화면에 표시되는 공지 없이는 드라이브 바이 편집자와 최초 편집자는 그 어느 것도 알지 못할 것이다.ese: 그들은 하단에 표시되는 일반적인 공지만 볼 수 있다.그러면 그들은 그들의 변화가 되돌릴 때 놀라거나 속상할 수도 있다.그들은 심지어 그들의 토크 페이지에 개별적으로 공지되지 않을 수도 있다; 누가 변화를 만들었는지를 명시하는 리턴이 있을 수도 있지만, 그들은 논평 시스템을 알지 못할 수도 있고, 다른 편집자에게 접근하는 방법을 이해하지 못할 수도 있다.그들은 위키프로젝트가 무엇인지조차 모를 수도 있기 때문에 프로젝트 가이드라인에 대해 알지 못할 것이다.사용자에게 이러한 정보를 개인화된 토크 페이지 메시지로 알려주는 것이 이 정보에 대해 배우기를 기대할 수 있는 유일한 방법이다.위키피디아에 대해 매우 경험이 없는 사람의 입장을 고려하는 것은 중요하다.
  • 프로젝트 구성원들 스스로가 낮은 품질의 콘텐츠를 여러 번 되돌리는 것을 싫어할 수 있는데, 이는 부분적으로 합의된 가이드라인에 어긋나는 것에 기인한다.통지가 결정된 반달 행위를 멈추지는 않겠지만, 낮은 품질의 편집을 줄이면 관리자 작업량과 프로젝트 사용자 작업량이 줄어들 것이다.행정을 자유롭게 한다는 것은 콘텐츠 제작에 더 많은 시간이 있다는 것을 의미한다; 나는 다른 사람들에게 학교 출석 경계와 지역 사회(도시/마을/이웃 지역)를 확인하자고 제안했지만, 다른 편집자는 그들 대부분이 행정적인 것에 집중되어 있고, 이 과제에 나 혼자 있을 것 같다는 것을 부드럽게 상기시켰다.
  • WhisperToMe (토크) 07:13, 2019년 1월 14일 (UTC)[응답]

• 좋아, 그 제안은 VPR이나 그 토크페이지에서 진행해도 된다. 이제 논의해야 할 이슈들이 명확해졌기 때문이다.–Ammarpad (대화) 07:59, 2019년 1월 15일 (UTC)[응답]

Infobox 코미디언을 래퍼로 변환

템플릿 토크 참조:인포박스 코미디언#포장지로 전환댓글 초대.고마워 카판카즈밀리오^{(Talk Infobox assistance)} 02:51, 2019년 1월 16일 (UTC)[응답]

비사용 파일 정보

오늘날 무료가 아닌 파일은 결국 공용 도메인에 들어가게 될 것이다.그 날이 오면, 그들은 하원으로 옮겨지게 되어 있다.나는 위키피디아가 그러한 파일에 대한 표준 절차를 세워야 한다고 제안하고, 향후 이 과정을 돕기 위해 현재 절차에 대한 몇 가지 수정사항이 있어야 한다.다음은 내가 인식한 우선 순위에 따른 목록이다.

1. 사용자:테오의 리틀봇은 무료가 아닌 파일의 크기를 줄이지만, 현재 파일 히스토리 외에 이미지 축소 여부를 추적할 수 있는 것은 없다.나는 다음과 같이 제안한다.
   1. Bot이 파일을 줄이면, EXIF에 봇에 의해 축소된 이미지와 같은 짧은 메모를 삽입한다.축소된 이미지들이 귀속될 수 있는 최선의 해결책이라고 생각한다.만약 그것들이 하원으로 이전된다면, 다른 봇, 커먼스헬퍼 또는 내장 미디어위키 기능들은 EXIF를 기반으로 그것들을 식별하거나 차단하도록 개발될 수 있을 것이다.이 조치는 모든 위키에서 이미지를 축소하는 모든 봇에 의해 채택되어야 한다.
   2. 1.1이 불가능한 경우 또는 모든 봇 축소 영상을 추적 범주에 포함하십시오.
2. Commons로 전송하기 전에 원본 하이라이트 파일을 복원하고 복구해야 한다.이것은 관리자 권한이 있는 봇에 의해 이루어질 수 있다.템플릿 설계:전송을 위해 복원하십시오.신뢰할 수 있는 사용자(자동 등록자?)가 이를 사용하여 파일에 태그를 지정하면 봇이 모든 리비전을 복원하고 첫 번째 버전으로 되돌릴 수 있으며, 이는 대부분의 파일에 가장 적합해야 한다. (신뢰할 수 없는 사용자의 태그 지정은 무시되거나 봇에 의해 되돌릴 수 있다.그럼에도 불구하고, 사용자들에게 가장 좋은 이적 상품을 선택하도록 상기시키기 위해 메모가 게시되어야 한다.
3. 파일이 언제 어디서 만들어졌는지 추적할 수 있는 것이 있을 수 있다.1930년에 미국에서 촬영되어 출판된 익명의 사진은 아마도 2026년에 PD에 들어갈 것이다.그때쯤이면 이감 과정에 도움이 될 수 있는 일.--로이17(토크) 01:01, 2019년 1월 10일 (UTC)[응답]

무상으로 업로드하는 대부분의 편집자는 이미 축소된 이미지로 시작하고, 원래 해상도에는 "이전" 버전이 없다는 점을 명심하십시오.또한 커먼즈는 어디에서나 PD가 되는 작품을 원하며, 현재 시스템이 허용하는 것보다 작품의 기원에 대한 약간의 지식이 필요하다는 것을 기억하십시오.나는 어떤 봇이 비무료 잠재력을 인간이 검토한 리스트에 "아마도 지금 PD"라고 태그하고 인간들이 확인 후에 그 일을 하게끔 하는 것에 전적으로 찬성하지만, 확실히 봇이 모든 일을 하는 것은 아니다. --마샘 (t) 01:11, 2019년 1월 10일 (UTC]

또한 당신의 1번 지점에서는 파일 히스토리가 봇 축소를 보여줄 것이다.우리는 EXIF에 아무것도 추가할 필요가 없다 (그리고 모든 파일이 EXIF를 가지는 것은 아니다). --Masem (t) 01:11, 2019년 1월 10일 (UTC)[응답]

나는 그것을 알고 있다.그래도 우리는 봇을 줄인 이미지들이 결국 하원에 도착하는 것을 막기 위해 작은 일을 할 수 있다.축소된 이미지가 전송되고 enwp 관리자가 로컬 페이지를 삭제했다면, 공유지에서 거의 누구도 파일이 축소되었는지 확인할 수 없었다.로컬 위키에서 축소된 미리보기를 다운받아 수동으로 커먼스에 업로드해 사용자가 파일을 전송(초기 위키 업로드, 텍스트로고 등)하는 사례를 많이 보아 삭제하기 전에 적절한 전송을 다시 해야 한다.이것은 확실히 봇이 줄인 비자유 파일에서 일어날 것이다.나는 EXIF에서 jpg와 tif의 경우든, 또는 다른 형태의 임베디드 코드나 워터마크의 경우든, 축소된 이미지 자체를 표시하는 것이 최선이라고 믿는다.표시는 기계 판독이 가능해야 한다.이것은 Commons가 파일을 바로 거부할 수 있게 한다.축소된 이미지를 경고하기 위해 템플릿 메시지를 현재 로컬 파일 페이지에 추가할 수도 있다.예방 조치를 많이 취하면 할수록 실수를 덜 하게 된다.

많은 이미지들이 PD에 들어갈 때까지 지역 위키에서 오랫동안 머물 것이다.외부 소스는 종종 대기 중에 발견되지 않는 404가 된다.가장 좋은 버전은 물론, 위키 원본을 편집했을 경우를 대비해서 외적인 원본이다.그러나 위키가 전근 대상이었다면 가장 큰 것이 최고다.

나는 완전히 자동화된 복원과 이전을 제안하지 않았다.봇은 복원 부분만 한다.파일은 PD에 들어가기 전에 150년 동안 공정하게 사용될 수 있다. (20요 사진작가가 죽은 사람의 유일한 이미지를 100으로 가져가고, 삶의 법칙+70이 적용된다고 말한다.)원년이 실제 PD 날짜를 의미하는 것은 아니지만 그런 극단적인 경우는 흔치 않다.많은 파일이 생성 후 120~150년이 지난 후 PD에 입력되어야 한다.2020년대와 2030년대의 위키 편집자들은 곧 1920년대와 1930년대의 파일을 처리해야 할 것이다.앞으로 정기적인 정비 과제가 될 것이다.일종의 선제적 목록 작성은 유익해야 한다.

나는 이것이 모든 위키에서 실행되어야 할 것이라고 믿지만, enwp가 가장 활동적이고 기술에 정통한 사용자들이 가장 많이 참석하기 때문에 여기에 올린다.--로이17 (토크) 04:02, 2019년 1월 10일 (UTC)[응답]

파일의 저작권 상태를 결정하기 위해서는 저자/저작권 청구인, 창작년, 발행년, 원산지 등의 매개변수가 가장 중요하다.여기 Yuewp에 대한 나의 발명품이 있는데, {{정보}}}을(를) 수정하고 두 개의 템플릿을 만드는 것으로, 일부 업로드를 YYYY에서 또는 이전에 만든 파일, Yue:special:diff/1246619, yue:t 전과 yue:t:between.---Roy17 (토크) 04:19, 2019년 1월 10일(UTC)[응답]

나는 봇이 파일 크기를 줄이는 것 외에 파일 자체를 망쳐서는 안 된다고 생각한다. 그러나 카테고리를 갖는 것은 어떤 해로움이 있을 것인가?봇이나 이와 비슷한 방법으로 줄인 비사용 파일?덧붙여/대안으로, 이미지 크기를 조절한 봇이 "이 파일은 봇에 의해 자동으로 크기가 조정되었고 F5에 따라 이전 버전이 삭제되었다"는 템플릿을 추가하면 좋을 것 같다.사이즈 조절이 잘못되었다고 판단되면 환불을 요청할 수 있다." 또는 이와 비슷한 것.그러면 이 파일들을 추적할 수 있을거야 템플릿의 전횡을 통해서 말이야SoWhy 11:36, 2019년 1월 10일 (UTC)[응답]

• 템플릿:Commons로 이동하지 않음에는 이미 만료에 대한 필드가 포함되어 있으며, 이 필드는 다음 파일을 Category에 추가하십시오.이제 커먼즈에게 적합한 매체.문제는, 그렇게 많은 사람들이 그것을 사용하는 것 같지 않다는 것이다.원본 고해상도 파일을 전송하기 위해 해제하는 봇이 있으면 7일 내에 파일을 전송하지 않고 PROD를 템플릿으로 대체하는 즉시 파일을 PRODS하기만 하면 된다.이제 커먼즈, 그러면 구 개정판은 자동으로 다시 삭제되어야 한다.또한 이전 버전을 복원하는 데 그치는 것이 아니라, 이전 버전을 복원하여 그 동안에도 우리는 여전히 기사에서 공정하게 사용 중인 저해상도 버전을 사용하고 있다.이복은 사람이 이양하기 전에 해야 한다.또한 파일과의 역량과 특별히 관련된 사용자 그룹은 파일 무버뿐입니다.그래서 이 그룹이 프로xy에 의한 무삭제 옵션을 갖는 것이 타당할 수 있는 유일한 그룹이다.GMG^talk 12:00, 2019년 1월 10일 (UTC)[응답]
• 이 무료가 아닌 파일들 중 극소수만이 곧 저작권이 만료될 것이다.또한 이 파일들을 보관하는 것은 위키피디아의 일이 아니다.대신 파일을 저장할 다른 아카이브(법률적으로)를 살펴보고 저작권이 만료되면 복사본을 복사할 준비를 해야 한다.또한 봇은 왜 이전 파일이 사용되지 않았는지 모를 것이다.오류나 다른 품질 문제가 있을 수 있다.그래서 수동적인 개입이 필요할 것이다.무료가 아닌 파일의 경우, 원본 사진작가와 국가가 종종 정보를 놓치기 때문에 저작권 만료를 결정할 충분한 정보가 없는 경우가 많다.Graeme Bartlett (대화) 02:58, 2019년 1월 11일 (UTC)[응답]

나는 확실히 1위(편리한 추적)에는 동의하지만, 나머지는 동의하지 않는다.이미지가 PD가 되는 시기를 결정하는 것은 때때로 복잡할 수 있다는 것을 명심하십시오.대신 특정 이미지가 이미 PD에 있거나 한 달 내에 있을 것으로 믿는 사용자가 해당 개별 이미지에 대해 요청할 수 있도록 하십시오.עוד מישהו Od Mishehu 13:11, 13 January 2019 (UTC)[reply]

FileImporter의 새로운 개발에 따라, 우리는 이제 삭제되지 않은 모든 수정사항을 공유지로 직접 이전할 수 있게 되었다.원상으로 되돌리는 부분은 삭제될 수 있는데, 이는 성공적인 이적 후 하원에서 할 수 있기 때문이다.--로이17 (토크) 17:21, 2019년 1월 16일 (UTC)[응답]

모든 사용자 페이지가 관련 사용자의 액세스 수준으로 자동 보호됨

작업 없이 닫기 요청 철회/WP:SOW. — xaosfluxTalk 15:05, 2019년 1월 17일(UTC)[응답]

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

---

나는 위키피디아의 모든 사용자 페이지가 관련 사용자의 사용자 수준 에 자동으로 보호될 것을 제안한다.예를 들어, IP 또는 새로운 사용자의 의지는 변경 보류 중 보호되고, 내 의지는 확장 확인 보호되며, 기타 등등.내가 이렇게 해야 한다고 생각하는 이유는 반달리즘(기본적으로 살아있는 사람들의 전기만큼)에 매우 민감하기 때문이며, 사용자 자신을 제외하고는 그 누구도 자신의 페이지를 편집할 이유가 거의 없기 때문이다(대부분 관리자와 그런 의지가 하는 사용되지 않는 템플릿 업데이트 등의 유지보수를 제외하고는).모든 콘텐츠가 IP-vandal에 의해 "이 사용자는 나쁜 사용자다"로 대체되었는지 확인하기 위해 아무도 자신의 페이지로 가고 싶어하지 않는다.(이것은 내가 가지고 있는 아이디어일 뿐이며, 이것이 실제로 현재 소프트웨어와 함께 작동할 수 있는지 확실하지 않다는 점에 유의하십시오.)Geolodus (대화) 10:05, 2019년 1월 12일 (UTC)[응답]

답안을 읽고 난 후, 나는 내 관점을 바꾸었고 지금은 이것을 나쁜 생각이라고 생각한다.이 토론을 거부된 것으로 간주하거나 또는 그 무엇이든 간에 자유롭게 닫거나 보관하십시오.Geolodus (대화) 15:03, 2019년 1월 17일 (UTC)[응답]

왜일까?이것은 여전히 누구나 편집할 수 있는 백과사전이며, 그들이 반달리즘(기본적으로 살아있는 사람들의 전기만큼)에 매우 민감하다는 증거는 없다.또한 새로운 사용자 User 페이지 편집에 대한 최근 변경사항 페이지는 대부분 OK 편집으로 구성된다.조조 유메루스 (토크, 기여) 10:42, 2019년 1월 12일 (UTC)[응답]

• 반대, 당신은 WP가 아니다.사용자 페이지를 소유하십시오.또한 사용자 페이지에 대한 어떤 파괴 행위도 기사를 대상으로 하지 않는다.나는 글의 숫자를 바꾸는 것과 같은 정말 나쁜 일보다는 내 사용자 페이지에 그래피티가 있는 것을 훨씬 더 좋아한다.—쿠스마 (t·c) 11:01, 2019년 1월 12일 (UTC)[응답]
• 반대한다. IP 편집자는 현재 사용자 페이지를 편집할 수 없다. 내 생각에 이 문제는 아마도 여기서 주요 관심사인 것 같다(데이터: 필터 803).사실 유용한 편집은 종종 사용자 페이지에 이루어질 수 있다.또한 관리자만 관리 사용자 페이지를 편집할 수 있도록 허용하는 것은 나에게 끔찍한 생각인 것 같다. -- zzuzz^(talk) 15:10, 2019년 1월 12일 (UTC)[응답]
  • 또한, 사용자 페이지가 자주 파손되는 관리자는 자신의 페이지를 보호할 수 있는 권한을 가지고 있으므로 자동화할 필요가 없다. bd2412 T 15:37, 2019년 1월 15일 (UTC)[응답]
• 반대 사용자 페이지 반달리즘은 흔하지 않고 쉽게 처리된다.신규 사용자나 등록되지 않은 사용자들은 어차피 다른 사람의 사용자 페이지를 편집할 수도 없고, 더 이상의 제한은 필요 없을 것 같아.펑플루스마트 (대화) 20:27, 2019년 1월 12일 (UTC)[응답]
• 반대...내가 이 글을 제대로 읽었더라면 관리자만이 관리 페이지를 편집할 수 있지 않을까?!비록 그것이 WP의 소음을 멈추게 하겠지만:창립자 페이지 전체 :D———SerialNumber54129 20:38, 2019년 1월 12일(UTC)[응답]

• 그리고 물론 우리의 사랑하는 창업자(BBHB)가 원한다면 이미 자신의 사용자 페이지를 보호해 줄 수도 있었을 것이다. --Guy Macon (토크) 16:30, 2019년 1월 13일 (UTC)[응답]

• 여기에 현재 중대한 문제가 있다는 것을 보여줄 수 없다면 반대하라.우리는 애논이나 새로운 사용자가 다른 사용자의 사용자 페이지를 편집하지 못하도록 하기 위해 편집 필터를 가지고 있다; 우리는 아마도 그 이상이 필요하지 않을 것이다.עודדוו od יוו od mis od 13 od od od mis od od od od od 13 od 13:06, 2019년 1월 13일 (UTC)[응답]
• 반대 위키피디아는 누구나 편집할 수 있다는 원칙을 바탕으로 만들어졌다.단, 기물 파손과 같은 특정 상황에서는 WP:RFP에서 요청할 수 있다. 이 WP를 참조하십시오.PPDRV. Siddiqsazzad001 <토크/> 05:06, 2019년 1월 14일 (UTC)[응답]
• Per WP 반대:선제적, 선제적 조치로 페이지 보호를 적용하는 것은 위키피디아의 개방적 성격에 반하며, 이러한 이유로 적용하면 일반적으로 허용되지 않는다.-Abelmoschus Escanticus (대화 • 기여) 05:18, 2019년 1월 14일 (UTC)[응답]

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

Bot for outreachdashboard.wmflabs.org

위키백과 대화에서 제안 토론을 참조하십시오.권한 요청#제안:_아웃리치 대시보드 계정 생성 워크플로우에 대한 서비스 계정 추가와 관련된 outreachdashboard.wmflabs.org용 Bot for outreachdashboard.wmflabs.org 생성.감사합니다, — xaosflux 15:20, 2019년 1월 17일 (UTC)[응답]

위키백과에 ReCaptcha 2.0 사용

Retriefcha 2.0은 원클릭 확인을 허용하여 편집 및 게시를 가속화할 수 있다.[[2]에서 그것을 조사하라.고마워. --무엇이든 젤리를 띄우는 것! (토크) 18:47, 2019년 1월 17일 (UTC)[응답]

@One Blue Hat: 위키백과 참조:다년제안#과거에 거부된 이유에 대해 reCAPtCHA 사용. --DannyS712 (대화) 18:55, 2019년 1월 17일 (UTC)[응답]

@DannyS712: Gotcha, 말이 돼. --Why Flight your Jelie! (토크) 19:10, 2019년 1월 17일 (UTC)[응답]

RfC: 확장 G13

이전 IP 자동 아카이브 경고

위키백과의 이전 토론:Bot 요청/아카이브 78#자동아카이브 IP 경고

나는 IP 사용자들이 그들의 실제 메시지에 도달하기 전에 그들의 IP의 이전 사용자들로부터 많은 오래된 경고들을 스크롤해야 한다는 것이 꽤 혼란스럽다고 생각한다.우리는 {{Old IP warning top}(또는 {{wan}} 또는 {{ow}})을 가지고 있지만, 그것은 나중에 자전거로 사용할 수 있다.—1년 이상 전에 자동으로 모든 것에 적용하는 것을 봇이라고 생각하는가?게일란 💬️19:49, 2019년 1월 11일 (UTC)[응답]

• 지원 나는 IP 경고가 몇 달 이상 지속될 필요가 없다고 생각한다.내 경험상 IP로부터의 반달리즘은 거의 이틀 이상 지속되지 않는 버스트(burst)로 들어온다.
• 나는 이것이 좋은 생각이라고 생각한다.1년이 너무 짧은 줄 알았는데 누가 알겠어.기술적으로는 아카이브 봇처럼 작동하지만 하위 페이지에 아카이빙하는 대신 의 상단/하단 부분에 아카이빙할 수 있다.그것은 날짜를 찾기 위해 섹션 내에서 가장 최근의 게시물을 보고, 만약 그 섹션이 경고와 함께 진행된다면.경고가 섹션 내에 있지 않고 후속 게시물 등이 있는 것처럼 일이 제대로 진행되지 않는 방법이 있으므로, 경고문이 혼자 남겨지는 형식을 이해할 수 없다면 이것이 더 이상 최선의 해결책은 아닐 것이다. -- GreenC 20:09, 2019년 1월 11일 (UTC)[응답]
• 나는 이 모든 것을 쫓기 위해 봇을 주변에 보내는 것은 좋은 생각이 아니라고 생각한다.그러나, 나는 이러한 경고의 대부분이 Huggle/Twinkle/etc와 같은 도구에서 나온다고 가정한다. 만약 그렇다면, "과거 (결정되는) IP 토크 경고를 역사에 보관하는 것"이 허용된다. 이러한 도구 시스템은 그러한 기능을 그들의 경고 루틴에 추가할 수 있다.— Xaosflux 20:21, 2019년 1월 11일 (UTC)[응답]
• 지원 - 2006년으로 거슬러 올라가는 많은 사례들을 볼 때, 나는 개인적으로 경고가 남겨진 시점으로부터 1년 반 후에 보관되어야 한다고 말하고 싶다. 2-3년은 너무 지나치고 1년은 너무 짧은 것 같다. –Davey2010^Talk 20:24, 2019년 1월 11일 (UTC) 응답하라.

나는 사람들이 편집하는 대부분의 IP가 그렇게 오래 지속되지 않는 역동적인 IP라고 상상하지만, 나는 전혀 모르겠다.게일란 💬️️ 20:50, 2019년 1월 11일 (UTC)[응답]

• 여기와 여기, 그리고 사실 사람들이 그 어떤 것보다도 먼저 살펴봐야 할 몇몇 다른 장소들이 있다.이미 여러 번 봇(BD2412와 같은 편집자)이 이 일을 해오고 있다.다른 어떤 것과 마찬가지로, 최근의 IP라면, IP가 능동적으로 또는 최근에 차단되거나, 범위가 차단되거나, 전 세계적으로 차단되어서는 안 되는 복잡한 요소가 복잡할 것이다.봇은 아마도 태그와 공유 IP 템플릿, 그리고 스팸과 관련된 백링크, 몇몇 맞춤 통지, 그리고 이해할 수 있는 비경고, IMO를 보관하거나 빈 삭푸페트리 태그를 비워서는 안 될 것이다. 문제는 그것이 오랫동안 행해져 온 일이기 때문에, 그것이 행해져야 하는 것인가 하는 것이 아니라 자전거 타기의 세부사항이라고 생각한다.그 제안에서 회피되었다.그리고 물론 누가 봇을 쓰고 운영할 것인가.개인적으로 나는 일반적으로 1년은 너무 짧다고 생각한다. (아마도 Dirk와 Petrb도 마찬가지일 것이다.)-- zzuzz 21:43, 2019년 1월 11일 (UTC)[응답]
• 지지하다.나는 이전에 이것에 대해 봇을 요청했는데 아무도 그것을 받아들이지 않고 대화가 끊겼다.이 토론의 다른 사람들과 마찬가지로, 나는 지난 2년 이내에 IP가 블록의 대상이 되지 않는 한 5년 이상 된 모든 토론은 페이지에서 삭제된다는 매우 구체적인 한계를 제안할 것이다.개인적으로, 나는 IP 주소가 그 기간 내에 재할당될 수 있기 때문에 2010년대 이전이라면 태그를 블랭킹해 왔으며, 그렇지 않더라도 위키피디아는 IP 주소의 영구적인 디렉토리가 아니다. bd2412 T 22:15, 2019년 1월 11일 (UTC)[응답]
• 정책을 복잡하게 만들수록, 글을 쓰고 봇을 운영하는 데 더 많은 시간이 소요될수록, 아무도 프로젝트를 맡을 기회가 줄어들어, 결코 일어나지 않을 가능성이 더 커진다. -- GreenC 22:39, 2019년 1월 11일 (UTC)[응답]
  • 그럼 10년 전의 경고처럼 모두가 동의할 수 있는 쉬운 것부터 시작합시다. bd2412T 04:38, 2019년 1월 12일 (UTC)[응답]
    • 그렇게 하는 거야.보수적이고 논란의 여지가 없는 것부터 시작해라.모든 사람이 볼 수 있는 개념 증명.일단 봇이 승인되고 실행되면, 다음 단계로 가는 것이 상당히 쉬워진다.첫날부터 완전한 성을 쌓으려는 것은 기술적으로나 지역 사회와의 지나친 접촉일 것이다. -- GreenC 00:41, 2019년 1월 27일 (UTC)[응답]
• 코멘트는 이것을 출발점으로 생각하는가?
  • IP 사용자가 편집하는 경우…(비활성 사용자의 대화 페이지를 스팸으로 정리하는 것은 의미가 없음)
  • IP가 최근 3년간 활동이 없는 경우…(활동 = 기여, 토크 메시지 수신, 차단, 5년 전 블록 발행해도 차단)
  • 토크 페이지가 화이트리스트의 템플릿으로만 구성된 경우… (우선 해당 CleverBot 및 Hugle 변종과 공유 IP 알림 반짝임 사용)
  • 토크 페이지를 {Old IP warning top}(으)로 마무리하십시오.

보수적이긴 하지만, 대부분의 사건을 다루게 될 것이고 우리는 미래에 그것을 확대할 수 있을 것이다.게일란 💬️️ 05:03, 2019년 1월 12일 (UTC)[응답]

• 1년 이상 된 공지 사항 보관 지원여기에는 "학교" 통지 및 이와 유사한 통지 또는 아직 유효한 블록 통지(예: 하드 블록된 IP 주소)는 포함되지 않는다.또한 1년 이상 된 IP 주소의 양말 태그를 100% 제거할 것을 권장한다. 동적 또는 이동 전화 IP인 경우에는 더 빨리 제거할 것을 권장한다.이러한 경고와 태그는 잠재적인 신규 사용자를 놀라게 할 가능성이 상당히 높으며, 프로젝트 관리에 유용한 목적을 거의 또는 전혀 제공하지 않는다.리스크 담당자(토크) 05:36, 2019년 1월 12일 (UTC)[응답]
• 사용자:Zzuzzz와 함께라면 반대하십시오.@리스크린저:, 1년은 너무 짧을 수 있다고 생각해.한 사이즈로 다 맞출 수 있을지 모르겠어.더그 웰러톡 13:08, 2019년 1월 12일 (UTC)[응답]

  약간의 준비만 하면 될 것 같은데, 그래, 1년 후에 페이지를 비워두는 것 만으로도 아마 좀 무리일 거야.만약 우리가 낮게 매달린 과일을 먹기 시작한다면, 나는 아마도 게일런이 위에서 말한 것과 같은 것을 가지고 갈 것이다.5년간 활동 없음, 5년간 토크 페이지 기록 없음, 역사 내 자동 경고만 표시됨.5년은 다시 초보수지만 앞으로 보게 될 가장 긴 블럭이고 아마 일반 룰의 출발점이 될 겁니다.BD2412가 예전에도 백링크를 불평한 적이 있다는 것을 알고 있기 때문에 경고문을 포장하는 것이 그냥 블랭킹하는 것만큼 도움이 될지 모르겠다.IP 편집 시 유용한 기존 도구에 연결할 수 있다면(또는 사용할 수 있지만) 봇이 스케줄에 따라 편집하는 데 문제가 없다고 본다.나의 주된 관심사는 단지 몇 년 전에 편집된 내용을 이해하는 데 도움이 될 수 있는 유용한 노트나 토론이 될 수 있는 것을 비워두는 것이다.어떤 사람들은 이런 것들을 일종의 공간 낭비라고 치부할 수도 있지만 역사적으로 나는 그것이 정말로 유용할 수 있다고 생각한다. -- 즈즈즈즈^(talk) 14:53, 2019년 1월 12일 (UTC)[응답하라]

  그래, 백링크는 나의 주요 관심사 중 하나야. 왜냐하면 때때로 편집자는 모든 네임스페이스에서 제목과 연결되는 것이 무엇인지 정확하게 파악해야 하고, IP 토크 페이지들은 단지 진흙투성이가 되어 보기 때문이다.이에 대한 메시지를 IP에 전달하기 위해 필요 이상으로 오래 보관해서는 안 된다.bd2412 T 17:30, 2019년 1월 19일 (UTC)[응답]

• 코멘트 내가 전에 말했듯이, 나는 보관하거나 심지어 오래된 경고/제거를 공백으로 만드는 것에 문제가 없다.나는 절대 해서는 안 되는 구 IP 토크 페이지를 완전히 삭제하는 것에 문제가 있다.

2-3개월 후에도 공유 IP에 있는 것(예, 알고 있다, 탐지)과 정적 IP에 있는 것(1-2년 이상 사용하지 않은 것)을 보관(또는 일반 보관처럼)하는 것에는 문제가 없다고 본다.나는 단지 모든 것을 보관하는 것을 선호한다. 왜냐하면 그것은 흔적을 더 잘 보이게 하고 비워두지 말아야 할 것을 선택하지 않아도 되기 때문이다.

내 추리를 반복해서 말하자면, IP 상의 명백한 파괴 행위는 사람에게 추적할 수 없다.그러나 어떤 형태의 조직적인 반달리즘(대부분 구체적으로 스팸, 양말, 강력한 COI, 스트링 단일 목적 편집)은 항상 특정인(/조직)에 의해 이루어진다.IP는 변하고 있고, 개인/조직은 변화하고 있지 않다.X씨가 www.mrx.com을 IP 1.1.1.1을 사용하는 페이지로 스팸 발송하고 있는데 우리는 그들이 그렇게 해서는 안 된다는 레벨 1 경고를 그들에게 주었고, X씨는 IP 1.1.1.2를 사용하여 1시간 후에 돌아오는데, 그는 다른 레벨 1 경고가 아닌 레벨 2 경고를 받을 자격이 있다.그것은 분명히 같은 사람이다.일부 스팸 발송자들은 그들이 실제로 스팸을 보내고 있다는 것을 아무도 눈치채지 못하기 때문에 10가지 레벨 1 경고를 작성한다.여전히 '듣지 않는다'고 말할 정도로 스팸 블랙리스트에 대해 우리는 경고하려 했지만 경고가 도착하지 않는다.그 나이와 관련하여, 2009년 X씨가 (IP 1.1.1.1에서) 몇 번 스탬핑을 하면 레벨 4 경고를 래핑하여 정지한다.그리고 경고를 몇 개 작성하기 위해 2019년에 다시 시작(1.1.1.2에 따라)하는 것은 여전히 동일한 물리적 실체 스팸 발송이다(영역 소유자가 변경되지 않는 한, 볼 수 있다).그들은 위키피디아의 규칙이 바뀌었다고 예상할지 모르지만, 2009년에 4개의 경고와 2019년에 불필요하게 주의를 기울이는 수준 1 경고는 더 이상의 혼란을 막기 위한 블랙리스트 작성에 충분할 수 있다(10년 동안 우리는 좀 더 부드러워질 것 같다).이러한 사용자 대화 페이지가 삭제되면 1.1.1.1의 트랙이 손실된다.그러나 1.1.1.1이 동일한 사이트를 스팸으로 처리했지만, 해당 대화 페이지가 없으면 탐지하기가 매우 어렵다(페이지에 삭제된 리비드가 있는 것을 볼 때 관리자 권한이 필요하다).(참고, 8-10년 동안 회사/기업이 스팸 메일을 보내는 경우가 있는데, 시간이 오래 걸리지만 그렇지 않다.) --Dirk Beetstra 05:31, 2019년 1월 13일 (UTC)[응답]

• 단순히 1년 또는 2년 이상의 자료가 포함된 모든 비공백 IP 토크 페이지에 1년 또는 2년 아카이브 시간을 가진 기존 아카이브봇을 추가할 수 없는 이유가 있는가?IP 토크 페이지에 경고를 추가할 때 수동으로 이 작업을 수행하면 선호하는 봇이 있는가? --Guy Macon (토크) 16:24, 2019년 1월 13일 (UTC)[응답]

• 이는 경고가 남아 있는 시간이 아닌 마지막 블록의 만료로부터 실행되어야 할 것이다. IP가 오랜 기간 후에 차단 해제된 경우(예: 개방 프록시로 1년 동안 차단 해제된 경우) 블록이 해제된 후 몇 분 이내에 문제가 재개된 경우, 우리는 분명히 그 배경을 알고자 한다.이런 일을 하기 위해 봇을 코드화하는 것은 어렵지 않을 것이라고 확신하지만, 기존의 봇들 중 한 개는 즉석에서 사용할 수 없었다.∙ 무지개빛 16:34, 2019년 1월 13일 (UTC)[응답]

• 어떤 세부사항이든 지원하라, 이것은 좋은 생각이다.헤드폭탄 {t · c · p · b} 06:08, 2019년 1월 14일 (UTC)[응답]
• 나는 일반적인 아이디어가 좋다. "보관됨"이 단순히 빈칸이 아니라 보관됨을 의미한다고 가정한다.또한, 봇과 반대로, 아카이브는 하지 않지만 오래된 경고를 붕괴시키는 {{old ip warning top}을 반자동으로 사용하는 Twinkle과 같은 기존 도구에 어떤 기능을 추가하는 것이 가능하지 않을까 하는 생각도 든다.새로운 정책이 없는 지금과 같이 경고 사용자의 최선의 판단에 맡길 수 있다.비블브록스 (대화) 18:44, 2019년 1월 19일 (UTC)[응답]

• 잠정적인 지원.나는 트윙클, 허글 등을 수정하여 새 경고를 발행할 때 오래된 경고를 자동으로 접도록 하는 아이디어가 꽤 마음에 든다. 왜냐하면 그러한 도구들은 애초에 얼마나 많은 경고가 발행되는지이기 때문이다.노부스나 22:08, 2019년 1월 21일 (UTC)[응답]
• Twinkle, Huggle 등 수정 지원이것을 하기 위해 봇을 실행한다면, 이것이 문제의 IP에 대해 "새로운 메시지가 있다"로 나타날 것이라는 점을 고려해야 하는데, 이는 동적 IP를 가진 사용자들에게는 다소 혼란스럽고 확실히 역효과를 낳을 수 있다.다아 뵐프 23:40, 2019년 1월 26일 (UTC)[응답]

잠재적 관심사 RFC

제안서를 포함하는 RfC가 진행 중이고, 토론이 진행 중이고 ("이 페이지의 관찰자"가 참여함으로써 더 심해지는) 많은 사람들이 그러기를 바란다!이 토론은 위키피디아 토크에서 확인할 수 있다.추가 소스를 포함할 것을 권장하는 "Ambox generated" 유지 관리 태그 관련 Twinkle#RfC.고마워.--존 클라인 (대화) 06:10, 2019년 1월 29일 (UTC)[응답]

참조 데스크

하위 페이지로 이동된 참조 데스크에 대한 스레드가 거의 다 떨어진 것 같다.결론이 날까? --76.69.46.228 (대화) 08:55, 2019년 1월 23일 (UTC)[응답하라]

토론은 오늘도 사람들이 글을 올리는 등 여전히 활발한 것으로 보이며, RFC가 문을 여는 기본 시간은 30일이기 때문에 아직 시간이 남아 있다.누구나 WP에서 권한 없는 편집자에 의해 폐쇄를 요청할 수 있다.RFCl은 30일이 지나면 더 많은 숙련된 편집자가 이 작업을 마무리해야 할 것이다.SoWhy 12:04, 2019년 1월 23일 (UTC)[응답]

미안, 기본 기간이 있는 줄 몰랐어. --76.69.46.228 (대화) 20:50, 2019년 1월 24일 (UTC)[응답]

좋아, 이제 30일이 지났어. (이전된 실에는 이제 닫아야 할 때라는 말도 나오고 있어.)자 이제? --76.69.46.228 (대화) 07:58, 2019년 1월 30일 (UTC)[응답]

이미 WP에 등재되어 있다.ANRFC는 그러나 나는 그것에 대한 적절한 마무리를 위해 숨을 죽이지 않을 것이다.그것은 많은 제안된 선택사항들이 있는 매우 큰 토론이다.주요 정책 질문(전체를 셧다운하든 안 하든)은 거수기(실제 토론 없음/합의구축)에 지나지 않는다.누구든 그 난장판에서 실행 가능한 정보를 추출해내는 걸 추천하겠어. 하지만 가끔, RfCs가 실패하기도 하고...티그라안^{Click here to contact me} 08:17, 2019년 1월 30일 (UTC)[응답]

퍼블릭 도메인 2019 러시아

• EN: 동료 여러분, 퍼블릭 도메인 2019 러시아 업로드&기사 공모전에 대한 CentralNotice 배너 제안에 대해 의견을 제시하십시오. (2월 18일 - 3월 31일, 러시아의 모든 IP, Wp/Ws/Commons, 2주마다 배너 인상 1개).감사합니다.주코FF (토크) 15:02, 2019년 1월 30일 (UTC)[응답]

두 번째 찬스 대본

WP의 요청에 따라:Enterprisey의 조언에 따라 SCRIPREQ, 멋진 DannyS712와 Danski454는 각각 대본과 모듈을 작성하여 {{2차 찬스}}}의 상당 부분을 자동화했다.특히 사용자 스크립트는 {{2차 찬스}}에 해당 템플릿을 수령하는 신규 사용자를 위해 기술/법률 단계를 상당 부분 자동화할 수 있어, 사용자 스크립트 사용에 관심이 많다.대니S712 대본에 대한 요청된 변경 사항을 보내드리겠지만, 실제 차단되지 않은 요청으로 테스트하고 싶은 수준에 불과해.

나는 이 대본을 실제 차단된 사용자들에게 제한적으로 시험해 볼 수 있는 합의를 요청하기 위해 여기에 왔다.특히 {{2차 찬스}}을(를) 사용하지 않았을 때 이 사용자 스크립트를 사용자의 common.js에 추가하고 사용자들의 토크 페이지에 스크립트 사용 방법을 알리고 싶다.이 평가판은 사용자 3명이 이 사용자 스크립트를 사용하여 차단 해제 요청이 {{2차 기회}}(으)로 거부된 후 두 번째로 차단 해제 요청을 할 때까지 지속된다.이 작업을 수행하려면 다른 사용자의 common.js를 직접 편집해야 하기 때문에 이 테스트를 수행하기 전에 커뮤니티의 승인을 받고 싶다.베스트, 케빈 (일명 L235 · t · c) 19:33, 2019년 1월 21일 (UTC)[응답]

@L235: 테스트 wiki에서 사용자 스크립트를 직접 테스트하고 싶었고 admin과 iadmin(여기서는 안 됨)을 요청하여 사용자를 차단할 수 있음:DannyS712는 테스트하고 그 계정에서 사용해보고, 어떤 버그라도 올라오는 것을 편집할 수정이 가능하다.나는 우리가 차단된 용도의 공통 js를 편집하기 전에 그것을 하고 싶다.@Xaosflux: 권한 요청을 거절하고, 관리자 권한을 가지고 장난치는 데 전념하는 위키 중 하나로 나를 안내했지만, 만약 이것이 사용자들을 차단하는 도구가 된다면, 나는 그들이 재고하기를 바란다. --DannyS712 (대화) 19:37, 2019년 1월 21일 (UTC)[응답]

@DannyS712: 베타 클러스터에서 계정을 열면 테스트 권한을 가져올게.하지만 여기서 몇 가지 테스트를 해 본 결과, 여기 있는 몇몇 사용자들과 함께 테스트할 수 있을 만큼 충분히 효과가 있는 것 같다.케빈 (akaL235·t·c) 19:40, 2019년 1월 21일 (UTC)[응답]

@L235: 토크 페이지 참조 --DannyS712 (토크) 19:50, 2019년 1월 21일 (UTC)[응답]

• 음....다른 사용자에게 개인 javascript를 강제로 추가할 수 있는 권한을 찾고 있으며 법적 요구 사항을 인용하는 경우 이 스크립트에는 다음이 포함됨import 다른 사용자로부터의 스크립트 - 그렇다면, 나는 보안상의 문제만을 이유로 이것에 대해 매우 강하게 반대한다.— Xaosflux^Talk 21:33, 2019년 1월 21일 (UTC)[응답]

  @Xaosflux: 일단 꼬인 부분을 다져내고 나면, 편집이 안 되도록 미디어위키 공간으로 옮겨놓으면 좋겠다.내 코드가 가져오는 유일한 것은 나의 또 다른 기능인데, 그것은 마찬가지로 움직일 수 있다.iadmins만 편집할 수 있으면 안전하다는 판단 아래 다른 사용자(common.js, skins 등)를 위해 javascript를 이미 추가했는데, 일단 이 스크립트를 이동하면 그렇다.(1) 사용자가 "두 번째 기회"를 시도하도록 이미 지시하고 2) 사용자에 의해 활성화되지 않고 편집하지 않으며 3) 코드 자체는 (이모) 읽기 쉽고 숨겨진 편집이 없음을 확인하는 것이 매우 쉽기 때문에, DannyS712 (talk) 21:41, 2019 (UTC) 응답으로 인해 새로운 보안 문제가 발생하는지 모르겠다.

  일반적인 스크립트(vector.js, common.js 등)는 쓰기 액세스가 심각하게 제한되어 있기 때문에 안전할 뿐만 아니라, 가시성이 높기 때문에(즉, watchlisted가 높기 때문에) 안전하다.이러한 페이지의 중요한 변경은 일반적으로 각 편집에 대한 제안/검토/실행/모니터 프로세스를 취소한다.임의의 User:username/common.js 파일에 변경을 강요하는 것은 또한 이 액세스 감소 목표 중 하나와 반대로 이 프로세스에 참여할 모든 사람이 인터페이스 관리자가 되어야 할 것이다.— Xaosflux^Talk 21:51, 2019년 1월 21일 (UTC)[응답]

  @Xaosflux: 또는 차단된 사용자가 차단되지 않은 요청을 두 번째 기회로 거절할 때마다 어느 곳에 노트를 넣은 다음(전용 페이지, iadmin 알림판?) 기존 iadmin은 해당 사용자의 common.js(importScript('MediaWiki:두 번째 기회.js' );) 또는 그 비슷한 것. --DannyS712 (대화) 21:57, 2019년 1월 21일 (UTC)[응답]

  사용자 동의가 없는 우려라면 어떤 종류의 기기로도 포장할 수 있지만, 그 전에 미리 케이빈(일명 L235 · t · c) 00:59, 2019년 1월 22일(UTC)에 대한 문자 테스트가 상당히 필요할 것으로 예상한다.베스트, 케빈 (akaL235·t·c) 22:27, 2019년 1월 21일 (UTC)[응답]

  @L235: 테스트? --DannyS712 (토크) 22:30, 2019년 1월 21일 (UTC)[응답]

안녕. 베타클러스터에서 테스트해보기 전까지는, 포함에 대한 논의조차 할 준비가 안 된 것 같아.그러므로, 이것은 표현되어야 한다. 호출될 때까지 대기:T212327은 그곳에서 계정을 확인할 수 있어야 하므로 해결되었다. --DannyS712 (대화) 04:23, 2019년 1월 22일 (UTC)[응답]

위에서 언급한 바와 같이, 나는 이것이 나쁜 생각이라고 생각하지만, 당신의 alt 계정이 이것을 그들의 사용자.js에게 로드하고 누군가 당신의 계정을 차단하도록 하는 것은 사소한 일일 것이다.— Xaosflux^Talk 04:46, 2019년 1월 22일 (UTC)[응답]

@Xaosflux: 테스트 wiki의 "my" userspace에 스크립트를 추가했으며 테스트 계정이 이를 가져오도록 했으므로 베타 버전이 작동하지 않으면 사용자:대니S712 테스트위키에서 일주일간 테스트?그리고, 거기서 수입업자에게도 대본을 시험해 볼 수 있는 다양한 페이지를 줄 수 있니? --DannyS712 (대화) 06:31, 2019년 1월 22일 (UTC)[응답]

우리는 이것을 가젯으로 만들 수 있고, 그들이 가젯을 활성화하고 거기서부터 진행하도록 요청하는 선을 템플릿에 추가할 수 있다.<< FR 06:41, 2019년 1월 22일 (UTC)>[응답]

@F30799386: 나는 그런 종류의 메커니즘을 보는 것이 훨씬 더 좋다.비기술적인 측면에서 볼 때, 그러한 요청은 차단된 사람에게 '더 쉽게' 할 수 있는 옵션이 되어야 하며, 반드시 우리가 차단된 IMHO를 해제할 수 있는 유일한 방법은 아니다. — xaosflux 12:30, 2019년 1월 22일 (UTC)[응답]

@DannyS712: 블록이 만들어지고, 수입업자는 인터페이스 관리자보다 더 드물게 발행된다(그리고 당신이 그것을 할 수 있도록 스튜어드에게 요청해야 할 필요가 있다). - 테스트 페이지를 적절히 복사/붙여넣고, 완료하면 빨리 삭제하도록 표시하면 된다.— Xaosflux^Talk 12:28, 2019년 1월 22일 (UTC)[응답]

@Xaosflux: 아, 알았어.고마워 --DannyS712 (대화) 16:17, 2019년 1월 22일 (UTC)[응답]

@DannyS712: 나는 사실 현재의 관심사가 무엇인지 완전히 확신할 수 없다.베타 클러스터의 계정이 손상될까 걱정되십니까?테스트 사이트야, 내용물이 없고 어떤 경우에도 계정을 쉽게 잠글 수 있어.@Xaosflux: 스크립트를 추가하기 전에 차단된 사용자의 동의를 얻었다면?그렇게 하면 너의 걱정이 조금이라도 완화될 수 있을까?베스트, 케빈 (akaL235·t·c) 08:48, 2019년 1월 26일 (UTC)[응답]

@L235: 테스트 계정으로 베타 클러스터에 로그인할 수 없는 경우.시험 위키에서 조금 테스트해 보았는데, 지금 가서 몇 가지 테스트를 더 해보겠다 --DannyS712 (토크) 09:02, 2019년 1월 26일 (UTC)[응답하라]

@L235: 헤이 그래서 나는 동의하는 사용자들의 베타 테스트에 적용되어야 할 2.0 버전의 스크립트를 가지고 있다.혹시 하루 동안 차단되어 도전해 볼 의향이 있는지 물어볼 수 있을까? --DannyS712 (대화) 10시 15분, 2019년 1월 26일 (UTC)[응답]

@L235: 위의 아이디어는 기기로 출판하고, 사용자에게 그것에 참여하라고 말하는 것이 가장 좋게 들린다.또한 프로세스 현명한 선택 사항: 이 작업은 항상 선택 사항이어야 한다(즉, 편집자가 수행하기를 원하는 태스크는 스크립트 도움 없이도 수행할 수 있어야 함).— Xaosflux 15:50, 2019년 1월 26일 (UTC)[응답]

DannyS712, 나는 지금 당장은 새로운 테스트 계정을 만들고, 그 티켓이 해결되기를 기다리는 대신 테스트 클러스터에 특정 이름을 붙이는 것에 대해 걱정하지 않을 것이다(잠시 매우 긴 시간이 될 수 있다.베타 클러스터에 대한 권한이 필요한 경우 언제든지 알려주십시오.SQL^{Query me!} 16:08, 2019년 1월 26일 (UTC)[응답]

@SQL: 그렇다면, 나는 새로운 계정을 만들었어.이(내 기본 계정)에 대해 admin 및 iadmin 권한을 추가할 수 있는가?고마워 --DannyS712 (대화) 17:28, 2019년 1월 26일 (UTC)[응답]

대니S712, 물론이지, 끝났어!SQL^{Query me!} 17:36, 2019년 1월 26일 (UTC)[응답]

• 사람들이 더 이상 이 템플릿을 그렇게 많이 사용하는가?나는 CAT에서 꽤 활동적이다.RFU, 그리고 난 이게 사용되는 걸 본 적이 없는 것 같아.{{여기서}}}}}이(가) 지금 가장 많이 사용하는 것이고, 템플릿이 사용되면, 그 외 2차 찬스가 옵션일 때는 대부분 무차별로 반응이 나타난다.기술적인 코멘트가 아니라 "언제나 사용될 수 있는 것을 논의하고 있는가?"토니발리오니(토크) 19:00, 2019년 1월 26일 (UTC)[응답]
  • 새로운 편집자들이 기술적인 지시를 따르는 것이 사실 그렇게 그럴듯하지 않기 때문에 나는 그것을 꽤 많이 이해하지만 그렇게 하는 것은 죄책감을 느낀다.나는 그것이 실제 옵션이라면 더 많이 쓰일 것이라고 확신해.케빈 (일명 L235 · t · c) 19:34, 2019년 1월 26일 (UTC)[응답]

  @TonyBallioni:Idk, 난 그냥 대본을 만들 뿐이야. 우리가 이걸 가지고 있다면 더 많은 사람들이 두 번째 기회를 이용할까? --DannyS712 (토크) 19:36, 2019년 1월 26일 (UTC)[응답]

그래, 네가 꺼낸 이후로 네가 사용한 줄 알았어 :) 그래도 다른 사람이 쓰는 건 본 적이 없는 것 같아.SQL과 얘기했는데, 솔직히 오늘 전에는 이런 게 있는지 몰랐어. 사용한 걸 본 적이 없어서.

실용적인 측면에서도, 나는 언어가 그렇게 유용하다고 생각하지 않는다. 그리고 만약 내가 차단된 사용자였다면, 만약 누군가가 그것을 가지고 나를 템플리트로 만들면 차단되지 않는 것을 포기했을 것이다. 왜냐하면 그것은 텍스트의 벽이고 내가 받을 메시지는 우리가 당신을 믿지 않는다는 것이기 때문이다.나는 스크립트가 그것이 의도하는 작업에 대해 정말 형편없이 설계/단어화되어 있다는 사실을 바꾸지 않을 것이라고 생각한다.토니발리오니(토크) 19:40, 2019년 1월 26일 (UTC)[응답]

@TonyBallioni:음, 만약 당신이 https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-secondChance.js,을 본다면, 나는 언어를 부드럽게 하려고 노력했다.물론 어떤 이유로 베타클러스터에서는 작동하지 않지만 테스트위키 등에서 효과가 있기 때문에 문제 해결을 위해 노력하겠다 --DannyS712 (토크) 19:55, 2019년 1월 26일 (UTC)[응답]

내 말은, 블록은 "우리는 당신을 믿지 않는다"는 좋은 분명한 메시지일 것이다.VOA 블록 등의 항소에 대해 어떻게 대응해야 하는가?두 번째 기회는 직선 언블록(실제 WP 기사 편집 가능, 사용자 토크 페이지에만 게시될 수 있음)과 하락(실제로 블록을 바꾸지 않음) 사이에 좋은 중간점을 준다.케빈 (akaL235·t·c) 20:00, 2019년 1월 26일 (UTC)[응답]

@L235 와 SQL : 야.베타클러스터에서 더 많은 테스트를 해 봤는데 지금까지 두 가지 이슈에 부딪혔어.첫 번째는 내가 해결한 것 같은 캡샤를 다루는 것이다.두 번째는 남용 필터다.글로벌 규칙 11(https://deployment.wikimedia.beta.wmflabs.org/wiki/Special:AbuseFilter/11)에서 외부 링크를 추가하지 못하도록 했지만, 구체적으로 어떤 링크를 검색하는지 볼 수 있어 그에 따라 내 regex를 변경할 수 있었으면 한다.나는 그것을 볼 수 없다. 왜냐하면 그것은 사적인 것으로 표시되어 있기 때문이다.두 분 중 한 분이 배치페이지에 admin을 내놔서 내가 대본을 고칠 수 있게? --DannyS712 (대화) 20:18, 2019년 1월 26일 (UTC)[응답]

L235, re: 어떻게 대응해야 할까: 만약 고등학생들이 장난치는 것이 분명하다면, 나는 보통 그들의 말을 차단하지 않는다. 만약 차단되지 않은 요청이 타당하다면 그들은 다시는 그것을 하지 않을 것이다.유용한 콘텐츠나 다른 것을 식별할 필요가 없다.개혁을 주장하고 있는 LTA라면 템플릿보다 더 깊은 논의가 필요하다, IMO. 소싱되지 않은 콘텐츠 블록에 소싱된 콘텐츠를 추가하는 방법을 누군가 설명하게 하는 것 외에 두 번째 기회 절차를 이용하는 것을 지지하는 상황은 별로 보이지 않는다.상위권(고교생)을 훨씬 넘거나 부족하거나(LTAs) 어느 쪽이든 말이다."정규어"의 블록은 그것에도 너무 복잡한 경향이 있다.토니발리오니 (토크) 22:58, 2019년 1월 26일 (UTC)[응답]

@L235와 SQL: 그래서 나는 개인 필터를 읽었고, 내 스크립트와 교란되는 것을 막을 해결 방법을 찾은 것 같다.

"&! (user_user & page_page ==3)"

그러나, 나는 실제로 테스트할 수 없다. 왜냐하면 글로벌 필터는 수정하기 위해 "abusefilter-modify-global"을 필요로 하기 때문이다.자꾸 귀찮게 해드려서 죄송한데, 이거 포함된 사용자 그룹에 나 좀 추가해줄래?목록은 https://deployment.wikimedia.beta.wmflabs.org/wiki/Special:GlobalGroupPermissions을 참조하십시오.

감사합니다, --DannyS712 (대화) 23:32, 2019년 1월 26일 (UTC)[응답]

대니S712, 끝!SQL^{Query me!} 02:30, 2019년 1월 27일 (UTC)[응답]

@SQL, TonyBallioni, L235 및 Xaosflux: https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-secondChance.js에서 최신 버전을 참조하십시오.내 생각에 이건 몇 가지 테스트를 위한 준비가 된 것 같아.현재 표준 오퍼에 따른 차단 해제에 대한 A의 논의가 진행 중이다.혹시 그들이 그것을 시도해 볼 의향이 있는지 알아볼까?나는 ping을 하는 것이 아니다. 왜냐하면 이것은 IAdmin 승인이 먼저 필요하기 때문이다. 그리고 그 편집자는 현재 차단되지 않은 상태이기 때문에(그러나 AN 토론에만 참여하기 위해), 스크립트는 쓸모없게 된다(실제로 현재 형태로 차단된 경우에만 작동한다).고마워, --DannyS712 (대화) 00:52, 2019년 1월 31일 (UTC)[응답]

전체 화면 편집 버튼

때로는 더 긴 페이지나 섹션을 편집할 때, 편집 상자의 모서리를 끌어서 화면에서 가능한 가장 많은 공간을 차지하는 것을 좋아한다.이것은 약간의 조작과 조정이 필요하다.다른 사람들도 이런 것을 좋아할 수도 있다는 생각이 들어서, 스크린 밖으로 나가지 않고 자동으로 편집창을 가장 큰 크기로 확장하는 버튼 하나만 있으면 좋을 것 같다.이게 할 수 있는 일인가?bd2412 T 16:58, 2019년 1월 30일 (UTC)[응답]

@BD2412: - 화면을 확장할 수 있는가?!왜 아무도 내게 말하지 않았지?나는 그 제안에 대해 잘 모르지만 그 문제만으로도 충분히 도움이 될 수 있어!코백베어(토크) 17:42, 2019년 1월 30일 (UTC)[응답]

또는 2010년도의 mw를 사용한다고 가정할 때 축소하십시오.위키에디터.주 편집 창의 오른쪽 하단 모서리에 있는 작은 삼각형 모양의 선만 끌어다 놓으십시오.만약 당신에게 잘 맞는 특정한 사이즈가 있다면, 당신은 당신의 개인 CSS 페이지에서 그 사이즈를 설정할 수 있다.(WP 확인:VPT의 지침에 대한 아카이브)WhatamIdoing (대화) 04:06, 2019년 2월 1일 (UTC)[응답]

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

---

편집자들의 일반적인 의견 일치는 Current events 게시판을 설치하는 것이다.그러나 기존 WP와의 중복을 목적으로 하는 예약도 있다.ITN/C 프로세스와 둘째, 프로젝트에서 실제로 긍정적인 역할을 하는 새로운 게시판의 타당성과 유용성.이러한 게시판에 대한 설립을 찬성하는 편집자들은 또한 이 아이디어가 최소한 탐색적 재판을 받을 만하다는 것을 강조해왔다. 내 생각에, 이것은 또한 그들이 게시판이 어떻게 작동하는지 실시간으로 보고 그들의 의견을 공식화할 수 있는 기회를 가질 것이기 때문에, 내 생각에, 일부 반대 편집자들의 우려를 완화시킬 것이다.아첨하듯모두의 의견을 읽으면서, 나는 시사 게시판이 아마도 순긍정적일 것이라는 것에 동의하는 경향이 있다.따라서 우리는 Current events 알림판의 구성을 최대 1년까지 9개월까지 연장하여 운영할 것이며, 이후 게시판의 기능에 대해 편집자들이 이의를 제기할 경우 AN RfC. --QEDK (後 )) 08:46, 2019년 3월 19일 (UTC)[응답]을 통해 문제를 제기해야 한다.

Current events notice board의 필요성 및 구현에 대한 RfC

뉴스에서 기사 주제에 대한 정확한 정보를 유지하는 게시판이 있어야 하는가, 시사문제와 관련된 게시판이 있어야 하는가?-MJL -Talk-22^☖:54, 2019년 1월 30일 (UTC)[응답]

지원

• 프로포저로서 지원하십시오.-MJL -Talk-22^☖:55, 2019년 1월 30일 (UTC)[응답]
  • 좋아, 이제 그 살림살이는 손을 뗐어. 더 자세히 말해볼게.WP에 따르면:PNB, 위키백과의 알림판은 편집자가 각 개별 게시판에서 다루는 정책과 지침에 익숙한 사람들에게 질문을 하고 도움을 요청할 수 있는 관리 페이지다.내가 아는 한, 뉴스와 위키피디아 특유의 질문을 하기 위해 사용자가 갈 수 있는 중앙 장소는 없다.현장의 정책, 지침, 에세이 등에 대해서는 WP:NOTNNEWS, WP:BREAKING, WP:NOTCrystal, WP:CAFET (그냥 몇 가지만 말하자면)일반적으로 뉴스 속 항목들은 활동이 급증하고 있으며, 편집자들이 이슈, 내용, 합의를 논의할 수 있는 단 하나의 장소를 갖는 것이 가치 있는 일이라고 생각한다.내가 구체적으로 제안하는 것은 위키피디아와 같은 것이다.'현재 사건'이 많은 토론 게시판이 교차하는 어딘가에 존재한다고 느끼기 때문에 살아있는 사람들의 전기/알림판나는 우리가 카테고리에 있는 기사들을 가지고 더 높은 기준을 시도하는 것이 가장 좋다고 생각한다.현재 이벤트.시간 내줘서 고마워.-MJL -Talk-23^☖:42, 2019년 1월 30일 (UTC)[응답]
• 게시판이 유용한지 여부에 대한 나의 우려를 불식시킬 수 있는 것은 지명자를 지지하는 것이다.나는 그것이 이슈와 BRD가 통제할 수 없을 때 유용할 것이라고 생각한다.나는 그것을 A와 기사의 토크 페이지 사이의 중개자로 본다.위키프로젝트의 활동 수준이 다양하고 많은 요소(연간)에 따라 달라지기 때문에 위키프로젝트의 대화 페이지가 이러한 논의의 장소라는 생각은 항상 가능하지는 않을 수 있다.잠재적으로 중요한 결정이나 이슈를 시간적으로 그들의 활동에 의존해야 하는 것은 이 이슈가 좀 더 일반적인 목적의 게시판에서 토론할 가치가 없을 수 있기 때문에 한동안 기사에 문제를 남길 수 있다.더 일반적인 게시판 논의를 할 가치가 없는 현재 사건과 관련된 문제에 대해 중앙집중화된 게시판을 갖는 것은 좋은 생각처럼 보인다.그러나, 나의 지지는 이 게시판이 잘 거래되고 시사 분야에서 경험하는 편집자들에 의해 확인될 것이라는 추정에 근거하고 있다.편집자들이 거기에 글을 올리면 며칠 후에 누군가가 도움을 주기 위해 올 수 있다; 만약 그것이 AN으로 옮겨졌다면, 이번에는 그 문제를 다루는데 시간을 쓸 수 있었을 것이다. 따라서 나의 지지 주장은 추정에 바탕을 두고 있기 때문에 약한 지지로 남기겠다.제안된 페이지의 범위가 단순히 {{}}이상일 것이기 때문에 ITN은 적절한 장소라고 생각하지 않는다.ITN}페이지.몽환적인 재즈 10 10:52, 2019년 2월 1일 (UTC) (나중에 내가 결정한 스트라이크 부분은 좀 엉뚱하다)[응답하라]
• 지원 토론 섹션의 예시들은 그것이 유용할 수 있다는 것을 나에게 확신시켜준다.샤즈질드 (대화) 20:23, 2019년 2월 2일 (UTC)[응답]
• 지지는 합리적이고 유용하게 들린다.세미하이퍼큐브 21:28, 2019년 2월 2일(UTC)[응답]
• 지지하다.시사 관련 기사를 논의할 수 있는 중앙의 장소가 없기 때문에 제안된 게시판이 많이 활용될 것으로 기대한다.뉴스에서는 메인페이지에서 링크된 소수의 기사만 다루며, 이 게시판의 혜택을 볼 수 있는 다른 기사들도 많이 있다.시사회는 많은 교통을 끌어들인다.피해 기사는 휘발성이 강해지고 피해 기사 목록은 끊임없이 바뀌고 있다.이러한 유형의 상황을 다루는 데 익숙한 편집자들은 이 게시판을 통해 주의를 요하는 이러한 성격의 모든 기사를 쉽게 보고 기여할 수 있을 것이다.— 뉴스링거 토크 22:01, 2019년 2월 7일 (UTC)[응답]
• 이것을 지지하는 것은 일반적인 문제이고 시험해 볼 만한 가치가 있는 좋은 생각이다.잘 뛰어라, 우리 프로젝트에 순긍정이 될 것이다. --Tom (LT) 08:06, 2019년 2월 8일 (UTC)[응답]
• 지지자들은 아래 나의 논평을 중립적으로 보고, 이익이 해를 능가하기를 바라며, 현재의 사건들로 가는 길을 찾는 건방진 편집자들을 다룰 중앙집권적인 장소가 필요하다.샌디조지아 (토크) 11:21, 2019년 2월 8일 (UTC)[응답]

  SandyGeorgia 아직 예약되어 있다면 투표 지지에 부담을 느끼지 마십시오.나는 그 제안이 마지못해 하는 지지자들과 함께 성공하는 것을 보느니 차라리 실패하기를 원한다.그것은 개인적으로 나에겐 아무런 악의도 없을 것이다.기여해줘서 고마워.:D -MJL -Talk-^☖ 22:36, 2019년 2월 9일 (UTC)[응답]

  걱정마, 그냥 천천히 생각해보고 싶었어내가 편집한 기사가 거들먹거리는 편집으로 히트했을 때, 나는 게시판이 있든 없든 그 사람들이 나타날 거라고 결정했어. 그러니 게시판을 가지고 있는 편이 나을 거야!Best evail, SandyGeorgia (Talk) 01:04, 2019년 2월 10일 (UTC)[응답]

• 캠발라체로 지원 (대화) 12:21, 2019년 2월 8일 (UTC)[응답]
• 지원 위키피디아는 수백만의 사람들에게 중요한 뉴스가 되었다.우리는 이 분야에서 우리의 노력을 지원하기 위한 몇 가지 메커니즘이 더 필요하며 IMO는 방해하기 보다는 도움을 줄 가능성이 더 높다.Doc James (대화 · 기여 · 이메일) 06:18, 2019년 2월 9일 (UTC)[응답]
• 지원 -Abelmoschus Escanticus (대화 • 기여) 08:22, 2019년 2월 9일 (UTC)[응답]
• 지원:우리는 이것이 필요하다: 우리는 BLP/N이 필요한 이유와 같은 이유로 긴급한 사건들을 처리할 수 있는 중앙집권적인 장소.나는 다른 편집자들이 제기한 우려를 공유하지만 주어진 답변과 사례에 반영되어 이러한 생각을 잘 하고 있는 것에 대해 칭찬한다.내 생각에 우리는 이것을 할 준비가 된 것 같아.중요한 질문은 CE/N일까 CUR/N일까? 레비비치 07:18, 2019년 2월 10일(UTC)[응답]

  레비비치, 그게 어디에 위치할지 생각해 본 적 없어.WP를 추천한다.WP 이후 CUR/N:CE는 복사 편집과 매우 관련이 있다.참여해주셔서 너무 감사! :D -MJL -Talk-^☖ 20:30, 2019년 2월 10일 (UTC)[응답]

  WP:CEN은 중앙집중식 토론으로 연결된다.CONN만이 가능한 옵션이다.power~enwiki (π, ν) 22:34, 2019년 2월 16일 (UTC)[응답]

• 지지하다.나는 이것이 확실히 해볼만한 가치가 있다고 생각한다.NPOV와 RS, BLP에 대한 알림판을 가지고 있지만 위키피디아는 (역사적 관점이 부족한) 현재의 사건들을 다루는 데 분명히 어려움을 겪고 있다.그리고 분쟁이 ANI로 가기 전에 오는 게시판에 대해 할 말이 있다.나는 우리가 시사 문제를 어떻게 다루고 있는지(또는 처리하지 않는지) 오랫동안 걱정했는데, 이것은 매우 가치 있는 아이디어로 떠오른다. --Tryptofish (토크) 00:09, 2019년 2월 13일 (UTC)[응답]
• 해볼 만한 가치가 있는 좋은 아이디어로 지원을 하라.~ 롭₁₃^Talk 01:22, 2019년 2월 13일 (UTC)[응답]
• 지원 - 기사를 바로 잡을 수 있도록 안전망 추가. 01:37, 2019년 2월 13일 (UTC)[응답]
• 적어도 시험 삼아 지원하라.너무 많은 시사회가 BLP, NPOV, RS 이슈를 넘나들며 게시판을 반드시 최고의 장소로 만든다. --Masem (t) 02:07, 2019년 2월 13일 (UTC)[응답]
• EEng가 1년 평가판 ping을 지원하십시오.^Thanks,L3X1 ◊distænt write◊ 16:47, 2019년 2월 13일 (UTC)[응답]
• 지원:완전히 분별 있는 제안이고, 급변하는 사건 때 믿을 수 없을 정도로 유용할 수 있는 제안이다.GN-z11 09^★:10, 2019년 2월 14일 (UTC)[응답]
• 지원 - 잠재적으로 유용한 지원. --Jax 0677 (대화) 13:11, 2019년 2월 16일 (UTC)[응답]
• 지원 - 나는 이것에 대한 시험 기간이라는 아이디어가 좋다.그것의 내용이 어떤 모양을 가질지 예측하기는 좀 어렵지만, 이것이 다른 게시판에 많은 공간을 차지하는 것은 사실이다.우리가 그것을 인정하고 싶든 간에 그것은 (a) 중요한 것, (b) 절차적으로 논란의 여지가 있는 것, (c) 광범위한 문제 편집의 대상이 되는 것, 즉 토론을 중앙집중화하는 데 유용할 수 있는 것과 관련이 있다.\ 17:55, 2019년 2월 16일 (UTC)[응답]
• 지지 그것은 이러한 토론에 더 다양한 편집자들을 끌어들이고, 비밀에 부칠 수 있는 토론을 함께 하는 가장 실용적인 방법인 것 같다. DGG (토크 ) 00:04, 2019년 2월 17일 (UTC) 아래에서 반대[응답]로 변경됨을 확인
• 단문토크페이지 토론은 기사토크에 보관할 것을 유의하여 지원한다.이는 다른 논의에 대한 통지를 게시할 때(예: WP 제외):ITNC. 현재 이벤트가 현재 이벤트라는 것에 모두가 동의하기 때문에 POV 추진의 체계적 근거를 마련할 여지가 별로 없다고 본다.wumbolo ^09:33, 2019년 2월 17일 (UTC)[응답]
• 지원 현재/최근 이벤트와 관련된 콘텐츠의 범위와 관련하여 해결되지 않은 질문이 많다.현재의 몇 가지 관행은 의문스럽고 이 분야에서 더 많은 논의가 필요하여 포용정책에 대한 확고하고 명확하며 설득력 있는 합의를 도출할 필요가 있다.중앙 안내판이 도움이 될 겁니다SD0001 (대화) 16:01, 2019년 2월 21일 (UTC)[응답]
• 지지하다.WP:근현대사 및 WP:NOT#NEWS 문제(및 WP와 같은 관련 문제):NOT#MEMORIORIORY 등)은 주로 그러한 비임시적 충돌에 대한 지역사회 합의 결과의 "집중" 부족에 의해 항상 악화되고 있다. — SMcCandlish lish 😼 05:27, 2019년 2월 27일 (UTC)[응답]
• 지지하다.나는 최근 뉴스 아이템들이 WP때문에 AfD에 많이 뜨는 것을 본다.TOOSUN 및 WP:NOTNEWS(예: 최근 보잉 737 MAX 위기 AfD)는 이러한 기사를 작성하기 전에 그런 것들을 논의할 수 있는 중앙집권적인 장소가 있다면 좋을 것이다.그래서 그러한 시사안건 게시판의 가능한 사용 사례의 예로서: 바로 오늘, 미국의 대학 뇌물 스캔들이 있었고, 나는 '이것이 기사를 쓸 만한 가치가 있을까?' '누군가 이미 이것에 대한 기사를 만들었을까?' 그리고 '이 뉴스 항목이 어떤 기존 기사를 추가할 수 있을까?'라는 의문이 들었다.그런 게시판은 그런 질문에 대한 신속한 답을 얻기에 좋은 장소일 수 있다. -- 운세티(토크) 01:26, 2019년 3월 13일 (UTC)[응답]

반대하다

• 기사토크페이지가 바로 그것이다.Andy Mabbett (Pigsonthewing); 앤디와 대화 : 앤디의 편집 12시 50분 2019년 2월 11일 (UTC)[응답]

  피그선더윙, 나는 이 문제에 대한 당신의 이견에 얼마나 감사한지 말할 수조차 없다.참여해주셔서 감사합니다! -MJL -Talk-^☖ 14:07, 2019년 2월 11일 (UTC)[응답]

• 나는 WP가 더 효과적일 것이라고 생각한다.부활 위키백과:WikiProject Current events는 다른 알림판을 만드는 것 이상이다.우리는 무작위 편집자들이 위키 전문가에게 분쟁을 일으킬 수 있도록 중심적인 장소가 필요하지 않다; 우리는 영향을 받는 기사들(그리고 살아있는 사람들이 관련된 현재 사건에 대한 분쟁을 위해 BLPN으로 직접 가서 현장에서 문제를 해결하고자 하는 모바일 편집자들이 필요하다.위키프로젝트 형식은 내가 게시판에 앉아서 누군가가 나에게 질문을 가져다 주기를 기다리는 형식보다 더 효과적인 모델이 될 것이다.알림판은 문제가 작고 이동성이 좋을 때 더 잘 작동한다.여기서 묘사되고 있는 논쟁은 작지도 않고 휴대하지도 않다.WhatamIdoing (대화) 20:32, 2019년 2월 11일 (UTC)[응답]
• WP 위반을 지나치게 강조하는 것에 반대한다.NOTNNEWS.그러나 나는 적어도 2016년 6월 이후의 현재의 사건들이 매우 이례적일 뿐만 아니라, 여러 국제 그룹, 개인, 출판물들이 연합한 노력으로 영향을 받고, 모호해지고, 난독화되고, 비껴가고, 완전히 잘못 전달되어 왔으며, 따라서 그러한 안내판이 어느 정도 유용할 수 있다는 것을 알고 있다.그러나 앤디의 말처럼 기사토크 페이지가 바로 그것이며 WP는 다음과 같다.RSN과 다른 장소들은.예를 들어, 그 문제에 대해 BullRangifer와 Galobtter의 의견을 듣고 싶다. -- Softlavender (토크) 03:05, 2019년 2월 13일 (UTC)[응답]

  나는 이 RfC에 대해 알고 있지만 코멘트를 하지 않았다. 왜냐하면 게시판이 실제로 만들어지고 사용될 때까지는 이 게시판이 도움이 될 것인지 아닌지를 판단하기가 꽤 어렵기 때문이다. 단지 누가 나타나느냐가 거기에 어떤 종류의 문제가 나타나느냐에 달려 있기 때문이다.갤럽터 (pingo mio) 09:18, 2019년 2월 13일 (UTC)[응답하라]

  Galobtter, Softlavender, L3X1, 나는 1년 실험에 아주 만족한다.그것은 또한 SandyGeorgia와 다른 사람들의 걱정거리도 다룰 수 있을 것이다.알림판은 다른 알림판과 달리 Current Events 정책이 없어 사뭇 다르다. -MJL -Talk-^☖ 18:52, 2019년 2월 13일(UTC)[응답]

  왜 NOTNEWS를 위반하는 것이 좋은 것으로 여겨지는지 아무리 생각해도 모르겠다.다음에는 NPOV를 위반하지 않는 것에 너무 많은 강조가 있는가?그리고 어쨌든 게시판이 존재한다고 해서 거기서 단 한 종류의 의견만 용인되는 것은 아니다. --Tryptofish (대화) 18:00, 2019년 2월 14일 (UTC)[응답]

  Tryptofish Beats me; 나는 여기서 일하지 않는다.\__/'MJL -Talk-^☖ 03:04, 2019년 2월 15일(UTC)[응답]

  하지만 진지하게, 그들은 그들의 걱정을 받을 권리가 있다.나는 그들을 검증할 입장이 아니다.그냥 어드레스만 하려고 한다. -MJL -Talk-^☖ 03:04, 2019년 2월 15일 (UTC)[답글]

• 반대 - 여러 WP와 기능적 문제에 반대되는 것으로서.먼저, 토크 페이지는 WP별로 내용에 대해 이야기할 수 있는 곳이다.TALK는 이것이 그것과 싸우며 경쟁하는 장소를 설정하는 것처럼 보일 것이고 또한 기능적으로 두 개의 토론 장소를 갖는 것은 편집이 논의된 장소나 심지어 두 개의 다른 합의점을 갖는 것을 식별하는 것을 어렵게 할 것이다.일을 풀려면 추가적인 지도와 노력이 필요하며, 일을 얽어놓을 가치도 없다.둘째, 정말 48시간의 대기 시간이 있어야 한다...이것은 명백히 NOTNNEWS, BREaking, Crystal, CHATEL, CATPIANY 등과 반대로 실행될 것이고, 덜 분명히 그것은 정당한 것과 NPOV에 대항할 것이다.기능적으로 어떤 것의 WIGHT가 발달하고, 반응과 더 많은 정보가 나타나기까지는 단지 시간이 걸린다.매일의 바이러스들이 대개 지속되지 않는 것처럼 보이고 거짓으로 인해 죽는 경우가 너무 많기 때문에 아침의 사료를 사용하는 것은 단지 잘못된 관행이다.나는 가장 최근 버즈피드 플랩인 도널드 트럼프 페이지에서 아침식사를 게재하는 것이 수술실 주장과 추측에 수 톤의 편집 시간을 낭비하는 것을 반복적으로 보았다.각각의 이야기를 게재하는 것은 또한 대부분 눈에 띄지 않는 단편들로 구성된 일기장 모음에서 형편없는 서술의 질을 낳는다.궁극적으로, 매일 아침 NYT의 리드가 중요한 역사적 항목이 되지는 않을 것이며, 우리가 믿을 수 있는 유일한 방법은 그것이 자라나 죽는지 여부를 보기 위한 적어도 며칠을 되돌아보는 것이다.또한 최신의 설익은 최신 정보로 인해 품질과 신뢰성의 손실은 가치가 없다.품질은 적어도 부분적으로는 구속에 있다.치어리더 마크바셋(토크) 21:02, 2019년 2월 17일 (UTC)[응답]
• 반대 당일의 뉴스에 대해 사람들이 거드름을 피우는 장소가 이미 있다 – WP:ITN/C. 우리는 그곳에서 스포츠 대 과학, 영국 대 미국, 좋은 소식 대 나쁜 소식 등 양극화를 보고 있으며, 그 결과는 그리 교묘하거나 생산적이지 않다.제안된 게시판이 이것에 어떤 가치를 더할지는 명확하지 않다.The Independent Group과 같은 뉴스의 항목들은 이미 그들의 토크 페이지에서 관심과 토론을 끌어모으고 있다.또 다른 게시판은 포럼 쇼핑과 탐색을 유발하는 경향이 있다.앤드류 D. (대화) 11시 13분, 2019년 2월 21일 (UTC)[응답]
• 마크바셋에 대항하라.현재 이벤트를 최신 상태로 유지하려면 다음 범주로 이동하십시오.현재 이벤트.만약 당신이 그들을 토론하고 싶다면, 그들의 대화 페이지를 이용하라.메인 페이지에 나타나는 내용에 관한 것이라면 WP:ITN/C가 그 장소다.만약 거기에 행동, RS 또는 BLP 문제가 있다면, 게시판은 이미 존재한다.이렇다 할 목적이 보이지 않는다. --Pudeo (대화) 10:29, 2019년 2월 24일 (UTC)[응답하라]
• 불필요한 논쟁의 여지가 있는 현재 사건들의 토론은 이미 충분히 두드러져 우리가 그것들을 더 이상 광고할 필요가 없기 때문에 반대하라.이것의 순효과는 그 주제들에 대한 논쟁에 또 다른 층을 더하는 것이 될 것이다. 그것은 우리가 결코 필요로 하지 않는 것이다.나는 원래 지지했지만, 지금은 이것이 토론을 중앙집권화하기보다는 단편화시킬 가능성이 높다고 생각한다. DGG (토크 ) 20:13, 2019년 2월 28일 (UTC)[응답]

중립

• 제안이나 아이디어에 대해 나쁜 점은 없다고 보지만, 제안과 추가 정보는 그러한 게시판이 필요한지 여부를 실제로 설명하지 않기 때문에 나는 중립적이다.그것이 존재한다면, 편집자와 독자들이 그것을 찾을 것이고 그래서 사용될 것이라고 이해하지만, 그러한 안내판이 도움이 되었을 시사 관련 사건들이 있었는가?그런 니즈가 드러나면 알림판이 유용하게 활용될 수 있도록 지원으로 옮겨갈 것이라고 생각한다.몽환 재즈 🎷 17:40, 2019년 1월 31일 (UTC) 지지로 이동했다.[답글]
• 지금은 중립이야, 나 역시 지금 당장 이 필요가 있다고는 보지 않으니까.위키백과 대화:뉴스 및 위키백과에서:뉴스/후보자들은 메인 페이지의 ITN 섹션 기사에 관해 좋은 일을 한다.기사 내용에 대한 좀 더 일반적인 논의를 위해, 나는 주제별 공지사항/위키프로젝트 페이지가 편집자들로서 더 유용할 것이라고 예상한다. 편집자들은 발생된 유형의 사건, 어디에서 좋은 출처를 찾아야 하는지, 그리고 비전문가에 의해 작성된 뉴스 보고서의 (부분)이 유용한지, 그리고 어떤 (비트)가 단지 유용한지 등을 더 잘 알고 있다.어느 쪽이든WP가 다음과 같이 반복해서 말할 수 있을 만큼 충분한 단서를 가진 사람들.NOTNEWS는 해석이 필요한 가이드라인(뉴스 이벤트 취재를 절대적으로 금지하는 것은 아님)이며, 무작위 유명인사의 포뮬러틱 트윗의 긴 목록은 백과사전이 아니라는 것(Wikiquote의 어느 곳에 속한다면) 나는 새로운 게시판이 어떤 가치를 가져올지 잘 모르겠다.Thryduulf (대화) 23:40, 2019년 1월 31일 (UTC)[응답하라]
• 나는 여기 중립적이다 - 나는 ITNC에서 단순히 주목도가 높은 시사회에 관한 것이었고 편집자가 더 필요했기 때문에 확실히 준비되지 않은 페이지를 지명했다.그것은 기술적으로는 규칙에 어긋나지만 IAR도 규칙이다.이렇게 해서 2019년 베네수엘라 대통령 사태와 같은 기사의 편집자를 쉽게 찾을 수 있다면, 나는 전적으로 찬성한다. 하지만 그 기사는 이미 메인 페이지에 올라와 있고 기고자가 부족해 고통을 받고 있다(IP와 뉴스 업데이트에 압도되는 4명 정도의 훌륭한 편집자들이 있다). 그래서 안내판이 도움이 될지는 잘 모르겠다. power~enwiki(권력~엔위키)) 17:08, 2019년 2월 4일 (UTC)[응답하라]

• 4명이 압도당했어, 그래우리에게 필요한 것은 2개 국어를 구사하는 사람들의 도움, 토크 페이지를 정돈하는 것, WP를 다루는 것 등이다.TED 등양말, NOTAFORUM, POV 푸셔를 다루는 데 많은 시간이 소요되며, 단지 일반적으로 IP가 대화에서 요구하는 것이 무엇인지 이해하려고 노력할 뿐이다.

  게시판이 그것을 제공할 것인가, 아니면 단지 권력에 굶주린 불량배들이 모여드는 또 다른 게시판이 될 것인가(예: CONE)?

  나의 또 다른 우려는 훌륭하고 중립적이며 경험이 풍부한 위키백과인들에게도 유용한 편집을 할 수 있도록 문맥과 역사를 알려주는 데 상당한 시간이 걸린다는 것이다; 자유 언론이나 독립적인 사법부가 없는 경우, 도움이 되는 위키백과인들조차 편집 내용을 알리는 데 많은 배경이 필요하다.게시판이 그 문제를 어떻게 도울 수 있을까, 아니면 악화시킬까?언론의 자유가 보장되는 환경에서 편집에 익숙하지 않은 좋은 의도를 가진 훌륭한 편집자들이 어떻게 더 잘 참여할 수 있을까?어떻게 해서든 납득하고 싶지만, 안내판을 통해 얻은 나의 전반적인 경험은 그들이 학대와 지식도 없는 부족주의의 집결지가 된다는 것이다.샌디조지아 (토크) 17:40, 2019년 2월 6일 (UTC)[응답]

• 다른 방법이 없기 때문에 나는 지원하기로 했다. 그러나 나의 예측은 모든 현재 사건에 나타나는 우호적인 편집자들이 단지 그들의 POV 발사를 조정하기 위한 모임 장소로 이사회를 이용할 것이라는 것이다.내가 틀렸기를 바라자.샌디조지아 (토크) 13:47, 2019년 2월 8일 (UTC)[응답]

토론

• @MJL: 이것을 갖게 된 이유를 설명해 주시겠습니까? --DannyS712 (대화) 23:33, 2019년 1월 30일 (UTC)[응답]
  • DannyS712, 네가 물어봐서 기뻐!현재 우리가 말하는 타이핑은 거의 끝났다.-MJL -Talk-23^☖:36, 2019년 1월 30일 (UTC)[응답]
    • 대니S712, 다 됐다.
• 몽환적인 재즈와 트리듀울프, 사실 나는 Current 이벤트 게시판이 도움이 될 수 있는 몇 가지 예시를 가지고 있다.

예 1: 위키백과:토론/로그/2019년 1월 30일~2017년 1월 30일~2019년 이란 시위 및 위키백과:삭제 조항/2018~2019년 이란 총파업 및 항의이 두 논의는 모두 서로 관련이 없다.양쪽 모두에게 문제는 이 사건의 현재 중요성과 이 백과사전에 필요한 세부사항들에 대한 필요한 이해다.이러한 기사에 가장 도움이 될 만한 것은 이러한 사건 뒤에 숨겨진 맥락을 이해하는 편집자들이 기여할 수 있는 중앙집중화된 위치에서 논의된 경우다.최소한 중앙 게시판을 사용하여 사용자들에게 두 가지 논의를 통지할 수 있었다.

예 2 WP를 좋아하지만ITN 및 WP:ITN/C, 어느 것도 특정 기사를 논하기 위한 것이 아니다.마단 샤르의 공격이나 탈레반에게 {{Current}} 태그가 붙어야 하는지에 대해서는 현재 (아마도 항상 그렇지는 않을 것이다) 논의되고 있다.

예제 3은 1면에 있는 글과 링크가 더 심하게 파손된다는 것도 분명히 잘 알려져 있다.WP 기사에서의 어려움:ITN은 사실들이 항상 명확하지는 않다는 것이다.또한 일반적으로 사람들이 이 행사와 관련하여 덜 잘 팔리는 기사를 편집하는 경우가 있기 때문에 관리하기가 더 어렵다.그 사건들에 대한 합의를 결정하는 것은 훨씬 더 어렵다.예를 들어, 카타르가 탈레반을 지지하는지 여부.분명히, 토크 페이지는 이 문제를 대부분 간단히 다룰 수 있지만, 게시판은 이러한 문제에 관심을 끌 수 있는 좋은 대안이 될 것이다.

사례 넷, 후안 과이도에는 수많은 내용 논쟁이 있었다.[3] [4] [5] [6] [7] 세부사항이 분 단위로 변경될 수 있는 행사다.샌디조지아와 킹시프가 정확한지 확인하기 위해 그렇게 부지런히 일하지 않았다면 전혀 다른 기사일 것이다.그러나 우리는 모든 기사에 그들 같은 편집자에게 의존할 수는 없다.

위키백과 주제가 왜 충분하지 않은지에 대해서는 그럴 수도 있지만, 얼마나 적절할지 모르겠다.현재 사건에 대한 나의 우려는 WP와 유사하다.BLP. 나는 우리가 Current Events의 BLP와 비슷한 기준을 가져야 한다고 생각한다. 왜?현재 행사 중에 위키피디아는 WP에도 불구하고 즉각적인 검색 결과 중 하나이다.NOTNNEWS.나는 사람들이 어떤 주제에 대한 배경 정보(예: 2019년 공격 이후 Jussie Smollett가 누구인지 또는 새로고침을 위해 Jussie Smollett를 찾는 방법)를 위해 이것을 한다고 의심한다.그러한 경우에 잘못된 정보를 얻는 것은 우리의 신뢰도뿐만 아니라 다른 사람들의 건강과 복지에 심각한 손상을 줄 수 있다.

그럼 됐군! :D -MJL -Talk-^☖ 01:58, 2019년 2월 1일 (UTC)[응답하라]

• 관심 영역에 있는 기사가 현재 이벤트인 경우 다양한 위키백과 제목에 접속하여 입력하는 것이 문제가 되는가?ITN/C의 "정규"로서, 당신의 제안에 대한 나의 관심사는 기사가 현재 사건이라는 이유만으로 광범위한 주제에서 기사 내용의 "신호"를 결정하는 비공식 중재자의 좁은 캐벌이다. --LaserLegs (대화) 12:32, 2019년 2월 1일 (UTC)[응답]

레이저레그 나는 게시판이 WP:CABAL과 같은 것인지에 대해 생각해 본 적이 없다고 생각한다.나는 그것이 모든 WP의 이슈라고 생각한다.COMPANTDISPUT 포럼, 그러나 주제가 좁은 보드에 의해 악화되는 것은 아마도 맞을 것이다.당신의 우려를 줄이지 않기 위해서가 아니라, 나는 WP가 어떻게 다음과 같은지 모르겠다.FTN은 당신이 설명한 것과 같은 종류의 문제를 가지고 있지 않다.나는 그들이 나쁜 일을 한다고 말하는 것이 아니라 이론적으로 그럴 수도 있다.게시판은 상황을 좀 더 투명하게 유지함으로써 문제에 더 많은 주의를 기울여야 하기 때문에 이 문제는 거기서 일어나지 않을 수 있다.우리가 시사문제와 관련된 일들을 다루는 특별한 방법은 사람들이 시스템을 탐색하는데 어려움을 겪으면 그 문제에 대해 목소리를 낮추게 한다.위키프로젝트에 손을 내밀 수 없는 이유에 대해, 나는 그것이 이 게시판에서 사라질 것 같지 않다.사실, 그렇게 되면, 이 프로젝트의 구성원들은 더 많은 사람들에게 이 문제에 대해 경고할 수 있는 장소를 가질 수 있을 것이다.이 게시판의 임무는 그들이 이미 더 시기적절하게 해야 하는 결정을 내리는 것일 것이다.내가 그랬으면 해서 네 질문에 답한 거야? -MJL -Talk-^☖ 20:55, 2019년 2월 1일(UTC)[응답]

고마워, MJL, 네가 그랬어. 그리고 내 관심사는 그 자체가 프린지 이론일 수도 있어.고마워. --LaserLegs (대화) 22:49, 2019년 2월 1일 (UTC)[응답]

질문:ITN에 대한 지명이 진행 중이거나 실패했거나, 아직 지명되지는 않았지만 뉴스에 보도된 것에 대해 논란이 있는 기사는 어떨까?이 게시판이 그들도 커버할 수 있을까?어느 주어진 시간에나 어느 정도 '뉴스 속'에 실려 있는 기사가 수백 개에 달하지만, 메인 페이지의 ITN 섹션에는 엄선된 소수의 기사만이 실려 있다는 것을 명심하라.캠발라체로 (대화) 22:56, 2019년 2월 2일 (UTC)[응답]

Cambalachero, WP 후보 선정 진행 중 및 실패:ITN뿐만 아니라, 지명되지 않은 기사도 본 공지 이사회에서 다루게 되지만, 컨텐츠와 관련하여 어떤 종류의 문제가 있는 경우에만 다루게 된다.나는 메인 페이지의 ITN 기사가 이 게시판에 자주 게재될 것이라고 추측한다. 그러나 그것들은 더 많은 트래픽이 있기 때문이다.질문 고마워! -MJL -Talk-^☖ 23:25, 2019년 2월 2일 (UTC)[응답]

논평: 뉴스의 주제들은 대개 단조롭거나 잘못된 기사를 포함하거나 심지어 아직 쓰여진 기사가 없을 수도 있다는 것을 명심하라. (새로운 주제들이 새로운 주제이기 때문에 혹은 지금까지 간과되었기 때문이다.기사 작성 및 개선에 대한 페이지(뉴스에도 불구하고 새로운 기사를 작성하지 않을 경우)에 링크를 추가하십시오.캠발라체로 (대화) 00:34, 2019년 2월 3일 (UTC)[응답]

• 코멘트는 적어도 이것을 시도해 보자는 공감대가 있는 것 같다.빨리 끝낼 수 있을까?우리는 여기서 너무 많은 관료주의를 필요로 하지 않는다.한편 2019년 나이지리아 총선(오늘 GMT로 예정)은 연기된 것으로 보인다. 시사주간지 편집자들은 앞으로 10일 동안 이 페이지를 보고 싶어할지도 모른다.power~enwiki (π, ν) 16:34, 2019년 2월 16일 (UTC)[응답]

  Power~enwiki, 귀하 또는 다른 사용자가 언제든지 닫으십시오.미국 남부 국경과 관련된 국가 비상사태를 업데이트하고 있어서 내가 충분히 어려움을 겪고 있다는 것을 안다.그러나 여전히..)이 뉴스 사이클은 나에게 치명적이었다. -MJL -Talk-16^☖:49, 2019년 2월 16일 (UTC)[응답]

  내가 너무 관여해서 토론을 끝낼 수는 없지만, 오늘 늦게 페이지를 만들 수도 있다(여기서 페이지를 갖지 말라는 합의가 있으면 G6/G7이 삭제될 것이라는 주의로).power~enwiki (π, ν) 16:55, 2019년 2월 16일 (UTC)[응답]

  내 충고는 그것을 더 오래 열어두라는 것일 것이다.RfCs는 반응이 거의 만장일치로 나오지 않는 한 일반적으로 한 달 동안 공개가 되지 않고 있으며, 이것은 WP:CENT에 등재될 만큼 중요하다. 아직 응답하지 않은 편집자들의 유용한 입력이 있을 수 있다. --Tryptofish (talk) 20:25, 2019년 2월 16일 (UTC) 응답[응답]

  내가 만든 위키백과:댓글 요청/현재 이벤트 알림판/헤더에 대한 요청으로, 사람들이 댓글 요청과 동시에 이 알림판을 설명하는 방법에 대해 협업할 수 있다.power~enwiki (π, ν) 17:51, 2019년 2월 17일 (UTC)[응답]

설명:이 RfC를 보고 나는 2015년 연구 논문에서 우리가 가지고 있던 비슷한 생각을 떠올렸다(여기서 Signpost 커버리지 참조.우리가 살펴본 것 중 하나는 가장 인기 있는 기사가 안정적인 인기척을 보였는지, 아니면 단기적으로 큰 인기변화가 있는 뉴스 속보를 내보내고 있는지 여부였다.우리는 가장 인기 있는 기사 중 46%(한 달 동안)가 인기가 급상승하는 징후를 보였으며, 위키피디아가 그러한 기사에 효과가 있을 수 있는 '신속한 대응팀'의 혜택을 받을 수 있다고 제안했다.이미 어느 정도 이런 일이 있을 것으로 예상하지만, 토론과 조율을 위한 중심적인 장소를 갖는 것은 좋은 생각인 것 같다.건배, 넷트롬 (대화) 15:06, 2019년 2월 28일 (UTC)[응답]

하우스키핑 / 알림

확장 콘텐츠

이 RfC는 다음 위치에 게시되고 있다. 위키백과:마을 펌프(제안) 포털 대화:현재 이벤트 위키백과 대화:게시판 위키백과 대화:뉴스에서 위키백과 대화:WikiProject 현재 이벤트 참가자의 토크 페이지 포함 위키백과 대화:근세주의 위키백과 대화:현재 이벤트 템플릿을 잘못 사용하지 않음 -MJL -Talk-☖ 23:22, 2019년 1월 30일 (UTC)[응답] 또한 WP에서 다음을 참조하십시오.POST/N/S — Pythoncoder (토크 기여) 13:27, 2019년 2월 5일 (UTC)[응답] WP에 추가:CENT by Mirb.[8] -MJL -Talk-☖ 13:37, 2019년 2월 8일 (UTC)[응답] 나는 또한 내 자신의 편의를 위해 내 토크 페이지에 그것을 옮겨 놓았다.-MJL -Talk-14☖:04, 2019년 2월 8일(UTC) 찔리고 제거되었다.-MJL -Talk-☖ 14:05, 2019년 2월 8일(UTC)[답글] 추가 언급 또는 위치: 사용자 대화:MJL/아카이브 4#헤딩 없음 위키백과:의견/Wikipedia 제안 요청 위키백과:의견/WikiProjects 및 공동작업 요청 위키백과:댓글/정치, 정부, 법률 요청 사용자 대화:몽환 재즈 위키백과:마을 펌프(모두) 사용자 대화:아직도 무리지어 수용하는 입양아들? 사용자 대화:옐로데스크 -MJL -Talk-☖ 01:32, 2019년 2월 11일 (UTC)[응답] 임의 중단 나중에 언급된 내용: 위키백과 대화:이 대화 페이지의 현재 읽기 가능성에 대한 RFC#Concerns 명명 규칙(Macedonia)/2019 RFC#Concerns. 템플릿 토크:현재 이벤트 -MJL -Talk-☖ 03:23, 2019년 2월 14일 (UTC)[응답] 순간적인 언급: 토크:2019년 미국 국가비상사태 선포— MJL이 추가한 선행 미서명 의견(토크 • 기여) 17:10, 2019년 2월 15일(UTC)[답글] 게다가... 카테고리에 추가됨:자동으로 서명된 대화하지 않는 페이지 토크:2019 베네수엘라 대통령 위기 대응 -MJL -Talk-☖ 15:42, 2019년 2월 24일 (UTC)[응답] 마을 건설에 대한 이전 논평 방금 RfC를 열었어.확인해줘! :D -MJL -Talk-☖ 23:12, 2019년 1월 30일 (UTC)[응답] (여기서 이동) -MJL -Talk-☖ 20:08, 2019년 2월 2일 (UTC)[답글]

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