위키백과:마을 펌프(모두)

Wikipedia:

모든 항목을 쉽게 볼 수 있는 Village pump (all) 페이지입니다.마을 펌프로 이동하여 마을 펌프 분할 목록을 보거나 주석을 달 섹션 위에 있는 편집 링크를 클릭합니다.이 페이지의 모든 최신 리비전 목록을 보려면 위의 이력 링크를 클릭하고 화면의 지시에 따르십시오.

이 페이지서버 캐시를 삭제하려면 여기를 클릭하십시오(빌리지 펌프 서브 페이지의 최근 변경 내용을 보려면).

마을 펌프 섹션
Edit-find-replace.svg
투고, 감시, 검색
기존 정책 및 제안된 정책에 대해 논의하다
Preferences-system.svg
투고, 감시, 검색
Wikipedia 관련 기술 문제 논의
Dialog-information on.svg
투고, 감시, 검색
정책과 무관한 새로운 제안에 대해 논의하다
Tools-hammer.svg
투고, 감시, 검색
새로운 아이디어를 정식으로 제안하기 전에 육성하다
Wikimedia-logo black.svg
투고, 감시, 검색
Wikimedia Foundation 관련 문제 논의
Help-browser.svg
투고, 감시, 검색
다른 카테고리에 맞지 않는 메시지 투고
기타 도움말 및 토론 장소
저는... 행선지
...Wikipedia 사용 또는 편집 도움말 찻집(신규 사용자용) 또는 헬프 데스크(경험 있는 사용자용)
위키피디아를 돌아다니는 내 길을 찾기 위해 부서 디렉토리
...특정 사실(예: 번째 교황은 누구였습니까? 레퍼런스 데스크
...특정 기사에 대한 타인으로부터의 적극적인 비판 안전 점검
...특정 기사 편집 경합을 해결하는 데 도움이 됩니다. 코멘트 요청
...특정 기사에 대해 코멘트를 하다 기사 토크 페이지
...다른 Wikimedia 프로젝트를 보려면 위키미디어 메타위키
참고 문헌에서 위키피디아를 인용하는 방법을 배우려면 위키피디아 인용
...Wikipedia 콘텐츠를 복사하는 사이트를 보고하려면 거울과 포크
...질문이나 코멘트를 하다 문의사항


7일이 지난 토론(마지막 주석 작성 날짜)은 각 섹션(섹션 이름)/아카이브)의 하위 페이지로 이동합니다.

정책

위키피디아에 대한 지리적 소싱 편견

왜 일부 위키피디아 편집자들은 인기 있는 서양 소스만이 주제의 주목도를 결정할 수 있는 유일한 독립적인 소스라고 믿는가?Patrick Lancaster에 대한 삭제 토론에서 한 편집자는 Zabroona가 이 주제에 대해 쓴 장문의 논문이 저널리즘이 아니라고 주장하고 있으며, 다른 편집자들은 독립적인 출처가 없다며 이를 지지하고 있다.이 주제는 우크라이나에 매우 특유하며 Zabroona는 우크라이나에서 매우 질 높은 독립 정보원으로서 위키피디아에서 커뮤니티의 의견을 얻으려고 했다.신뢰할 수 있는 출처/Wikipedia의 조언에 따른 알림판:믿을 만한 소식통이지만 아직까지는 반응이 없어요서방의 독립적인 정보원이 믿을 수 있는 유일한 정보원이라면, 저명한 타타르 음악가, 인도 무당, 그리고 인도네시아 정치인에 대한 수백만 개의 글은 위키피디아에서 사라졌을 것이다.Intrepid Contributor (토크) 2022년 7월 13일 (UTC) 09:58

'독립된' 소스를 정의하고 위키피디아 기사 172.254.222.178(대화) 11:28, 2022년 7월 13일(UTC)에 이러한 소스의 예를 제시합니다.
"독립적"은 사전적 정의보다 더 이상 필요하지 않다고 생각합니다.인도네시아의 현지 신문인 Kompas와 같이 위키피디아에서 사용되는 비서방 독립 소스에는 많은 예가 있습니다.문제는 위의 예시와 같이 이러한 소스가 주제에 대한 인지도를 확립할 만큼 품질이 높지 않다는 견해가 지배적인 것처럼 보인다는 것이다.Intrepid Contributor (토크) 2022년 7월 13일 (UTC) 13:50
둔감하게 들리려는 것은 아니지만, 출처에 관해서는 "독립적"이라는 설명이 필요합니다.특정 문제에 대한 다양한 관점의 출처가 "독립적"인가?그렇다고 해서 그 문제에 대해 신뢰할 수 있는 것으로 여겨져야 한다는 뜻은 아닙니다.POV에 준거하지 않는 경우도 있지만, 독자적인 POV가 있습니다.는 "독립적" 관점으로 다른 POV와 마찬가지로 신뢰성이 떨어진다.
독립에 대한 정의가 정말 더 명확해질 필요가 있다면 Zabroona와 Patrick Lancaster에 대해 구체적으로 설명하겠습니다.Zabroona가 (바이스와 함께) 랭커스터의 인지도를 판단할 수 있는 신뢰할 수 있는 소스라고 생각하지 않는 이유가 있습니까?다른 편집자들은 다른 예를 들 수 있다.Intrepid Contributor (토크) 2022년 7월 13일 (UTC) 18:23
심사숙고된 답변을 하기 위해서는 주제와 이에 대한 보고에 대해 배울 필요가 있다.지금은 그럴 시간이 없지만, 일반적으로 "신뢰할 수 있는 출처"라는 것은 존재하지 않으며, 토토나 영속적으로 그 성배를 소유하는 개인이나 단체는 없다.신뢰할 수 있는 참조가 있을 수 있습니다.신뢰할 수 있는 참조는 Wikitext 프레젠테이션과 소스 선택에 따라 달라집니다.편파적인 선전에 대해서는 널리 보급되어 있을 것이다.그것은 선전을 두드러지게 할 것이다.Wikitext는 중립적인 방법으로 [biased?]소스를 예로 들 수 있습니다.하지만 이것은 사실이지만 오해의 소지가 있다.선전에 반대되는 사례(있는 경우)도 중립적인 방식으로 자체 출처를 제시해야 한다.그것 또한 사실일 수 있지만, 불완전하다.독자(관심이 없는 관찰자)가 전체 그림을 볼 수 있도록 한쪽 또는 모든 면이 편향될 수 있다는 검증 가능한 정보를 포함하십시오.다른 소스가 문제에 대해 보다 진실한 설명을 제공하는 경우, 그 소스도 그 상태에 대한 설명과 함께 포함되어야 한다. 68.132.154.35 (대화) 21:17, 2022년 7월 13일 (UTC)
예를 살펴볼 시간이 없었으면 답변을 하지 말았어야 했을지도 모릅니다.Intrepid Contributor (토크) 2022년 7월 15일 (UTC) 17:26
만약 우리가 다른 사람들이 무엇을 해야 할지 말아야 할지에 대한 의견을 공유한다면, 아마도 독자 분은 눈을 끌기 위해 사이트 전체의 "편견"이라고 추정되는 일반적인 문제로 애완동물 관심을 높이려고 하지 말아야 할 것입니다.어쨌든 당신은 응답에 대한 예의를 지켰어요.104.247.55.106 (대화) 2022년 7월 17일 (UTC) 13:23
변경/논의할 필요가 있다고 제안하고 있는 정책은 무엇입니까?Lee Vilenski 2022년 7월 13일 (UTC) 15:07
WP를 읽은 후:GNG는 1회, 2회, 변경은 필요 없다고 생각합니다.문제는 자브로나 기사가 "주제로부터 독립적"이 아니라고 믿는 편집자 한 명(그리고 현재 두 명)이 분명히 그렇지 않을 때 광고라고 주장하는 것이라고 생각합니다.Intrepid Contributor (토크) 2022년 7월 15일 (UTC) 17:31)
그것은 매우 까다로운 문제이기 때문에 쉬운 해결책이 없을지 잘 모르겠습니다.위키피디아는 기본적으로 서양의 웹사이트이기 때문에 위키피디아 DNA에 내재된 내재된 편견을 없애는 것은 거의 불가능하다. 대신 진정한 100% NPOV를 갖는다.서양의 "컨센서스"와 약간 다른 것은 "친 아랍" / "친 러시아" / "친 중국" 등의 비난과 함께 쉽게 버려질 것이다. 왜냐하면 대부분의 서양 편집자들은 중립적인 관점이 어디에 위치해야 하는지에 도달하기 위해 다른 모든 관점에서 볼 수 있는 유연성이 부족하기 때문이다.서양의 시각에서만 볼 수 있다면 당연히 '중립의 시각'이 서양의 시각의 중간으로 떨어지는 것을 자연스럽게 인식하고, 그 과정에서 다른 시각은 완전히 무시하게 된다.MathmoTalk 16:55, 2022년 7월 13일 (UTC)
이것은 짧은 단락에 대한 가정, 의견 및 일반화의 꽤 두꺼운 스택입니다.68.132.154.35 (대화) 2022년 7월 13일 (UTC) 21:20
아마도 아랍, 러시아, 중국이 언론의 자유를 더 많이 가졌다면 우리는 그 나라들로부터 더 신뢰할 수 있는 정보원을 얻을 수 있었을 것이다.제 문제는 영어 위키피디아에서 주제의 인지도를 확립하기 위해 배제되고 있는 하위 "카스트" 국가 출신의 신뢰할 수 있는 두 번째 "계층" 정보원에 관한 것입니다.Intrepid Contributor (토크) 2022년 7월 15일 (UTC) 17:15
"그러면 저명한 타타르 음악가, 인도 무당, 인도네시아 정치인에 대한 수백만 개의 글이 위키피디아에서 사라졌을 것입니다."
당신이 전적으로 옳아요.Mathmo 17:01, 2022년 7월 13일 (UTC)
네, 최근에 AfD를 보세요. 방글라데시와 스리랑카 기사들 중 분명히 눈에 띄는 것들이 사라집니다. 왜냐하면 영어 위키피디아에는 그들을 옹호할 사람이 없기 때문입니다.한두 명은 구했지만, 내 전문지식이 아니어서 다 구해줄 힘이 없어.삭제론자의 전문 지식도 아니지만 기사 몇 개를 파기하고 싶다면 쉽게 표적이 될 수 있습니다.자코나 (대화) 2022년 7월 17일 (UT) 14:53,
"기사를 파괴"하고 싶은 사람은 없다.사람들이 원하는 것은 신뢰할 수 있는 정보를 중심으로 만들어진 기사들이다.어떤 주제, 특히 BLP에 대해 침묵하는 것이 신뢰할 수 없는 주제보다 낫고, 아무도 신뢰할 수 있는 출처로부터 어떤 검증 가능한 정보를 만들어 낼 수 없는 주제에 대해 기사를 쓰는 것은 무엇을 하는가?(어느 언어로든) 출처가 존재한다면 기사를 삭제할 이유가 없지만, 기사 작성자의 말이나 해당자의 팬이 "나를 믿어"라고 말하는 것만으로는 위키피디아에서 기사를 만들기에 충분하지 않습니다.아무도, 한 사람이 아니라, 기사를 삭제하는 것을 선호하지 않는다.그러나 검증할 수 없는 텍스트가 위키피디아와 기사의 주제에 다음보다 더 해를 끼친다는 것을 기꺼이 인정하는 것이 중요하다.--Jayron32 18:28, 2022년 7월 19일(UTC)
오랜 위키친구(다행히 나의 학식과 강박관념에 인내심이 있는 사람)와 함께 이 주제에 대해 6차례 정도 논의해 왔습니다.그리고 다음과 같은 짧은 코멘트가 있습니다.
  • IP는 기본적으로 모든 것이 잘못되어 있습니다.우선 WP:편향된 소스가 허용됩니다.또한 Wikipedia에 대한 정의는 이미 있습니다.독립된 소스첫 번째 근사치(첫 번째 근사치까지, 전체 우주가 수소로 구성되어 있음)로서, 그 내용을 실행하는데 대한 비용이 지불되지 않은 경우, 선원은 독립적입니다.
  • 일부 편집자는 신뢰할 수 있는 소스가 "소리"를 내야 하는 방법이나 웹 사이트가 올바른™ 모양과 느낌을 가지고 있기 때문에 개인적인 의견을 가지고 있습니다.이것은 한 컴퓨터 시스템이 다른 컴퓨터 시스템보다 더 발전했다고 믿는 것만큼 믿을 수 없지만, 그 효과는 진짜입니다.이 편집자들은 독립적으로 확인된 사실들이 어리석고, 아첨하고, 시대에 뒤떨어지거나, 다른 방법으로 (그들만의 문화에 대해) 부적절하게 표현되지 않을 것이라고 믿는다.그들이 틀릴 수도 있지만, 그들을 설득하는 것은 당신의 시간을 낭비할 가치가 없을 수도 있습니다.
  • 이런 종류의 문제에 대처하기 위한 정말 실용적인 방법 중 하나는, 비록 때때로 어렵더라도, 출처에 대한 목록과 기사를 만드는 것입니다."2018년에 발행된 주간신문 발행부수 12,453부"와 같은 Wikipedia 엔트리에 대해 편집자들은 전혀 알지 못하는 소식통에 대해 다르게 반응한다.또한 네이티브 광고도 받아들입니다.이것은 큰 문제입니다(모든 유료 광고가 "광고"로 명확하게 표시되지 않는 ).그렇지 않으면 어떤 것이 유료 광고이고 어떤 것이 그렇지 않은지 어떻게 알 수 있을까요?
WhatamIdoing (대화) 2022년 7월 21일 (UTC) 18:05

또 다른 흥미로운 사건입니다.내가 방금 아나톨리 레빈-우트킨에 추가한 우크라이나어와 카작의 새로운 소스가 그의 인지도를 확립하기에 충분할까?Intrepid Contributor (talk) 2022년 7월 18일 (UTC) 19:43, 43)

불법체류자 용어

Wikipedia 페이지:명명 규칙(이민)은 해결하지 않고 보관되어 있습니다.현재 AP Stylebook은 "불법 이민자"라는 용어를 제안하고 있지만, 2013년 현재 이는 [1]더 이상 사실이 아니다.2021년 조 바이든 정부는 '무허가 비시민'이라는 용어로 전환했다.이로써 이전 논의 때보다 문제가 더 명확해졌다.직접 인용은 인용된 정확한 표현을 사용해야 한다.인용되지 않은 텍스트에 대해서는 특정인을 "불법"으로 기술하는 것은 적절하지 않다고 생각한다.John Moser (talk) 05:34, 2022년 7월 18일 (UTC)

만약 그게 여기서 행해지고 있다면 그건 타당할 거야"불법 이민자"는 다음과 같은 경우에 사용되는 "불법 이민자"와 정확히 유사합니다. https://casetext.com/case/us-v-crisp-10 . --사용자:하지다 (기고) 2022년 7월 18일 (UTC) 12:21
2014년에 이민자 용어 가이드라인에 대한 마을 펌프 제안이 있었다.WP:2017년 WTW 제안서 "불법 외국인"이라는 용어.둘 다 실패했습니다.좋아, 내가 가장 좋아하는 반박은 축구선수들을 "와이드 리시버"라고 부르지 않는다는 것이다.Peter Gulutzan (대화) 2022년 7월 18일 (UTC) 14:08
네가 그걸 해결해서 기뻐.미국인이 아닌 제 귀에는 "와이드 리시버"가 다소 외설적인 성적 용어처럼 들리는데요.Phil Bridger (대화) 15:53, 2022년 7월 18일 (UTC
많은 미국인들도 그것에 대해 농담을 한다.같은 팀에서 "긴축한 끝"은 말할 것도 없고심지어 "풀백"도 빈정거릴 가능성이 있다. --사용자:하지다 (기고) 2022년 7월 18일 (UTC) 15:59
이 용어는 캐나다 축구에도 존재한다.Peter Gulutzan (대화) 2022년 7월 19일 (UTC) 15:12
재밌는 거.만약 "와이드 리시버"라는 용어가 와이드 리시버에 대한 권리를 잠그고 추방하고 거부하면서 사용되었다면; 만약 와이드 리시버 자체가 오랜 세월 동안 이 용어에 반대해 왔다면; 만약 많은 주류 스타일 가이드들이 "와이드 리시버"라는 용어에서 멀어진다면, 위키피디아인들은 오를 선호했다.어쨌든 비웃으면, 그래, 꽤 비슷할 거야.- \\ 2022년 7월 18일 (UTC)
문맥이 중요합니다.동사에서 파생된 명사 앞에 형용사가 나타나면 동사의 의미를 나타낼 수 없다는 논거였다.Peter Gulutzan (대화) 2022년 7월 19일 (UTC) 15:12
아니요, 그 주장은 사람들을 "불법"이라고 지칭하는 것은 비인간적이고 비인기적이며, 우리가 반성하고 있는 신뢰할 수 있는 출처와 우리를 대립하게 만든다는 것이었습니다.그것은 꽤 설득력 있는 주장이다.MastCell 2022년 7월 19일 (UTC) 16:39
WP:MOS#어휘는 이것을 꽤 잘 다루고 있다: (a)불법 이민이라는 용어는 (b)신뢰할 수 있는 출처에서 가장 일반적인 용어가 아니며, (c) 그것이 언급하는 사람들에 의해 일반적으로 사용되지 않기 때문에 직접 인용문 이외의 용어로 사용할 충분한 이유가 없을 것이다.--Visviva (talk) 2022년 7월 16일 (UTC) 16:18 (UTC)

새로운 AP지침은 기본적으로 불법체류자로 명사를 사용하는 사람들을 피하도록 되어 있다.대신 불법행위의 관점에서, 그리고 아마도 그 측면이 관련이 있을 때만 그것을 묘사하는 것이다."문서화되어 있지 않다"는 주장은 하지 않으며, 애매한 용어가 "특정"에 사용되는 요점을 모호하게 한다는 점에 주목하고 있습니다.입력 또는 존재는 불법입니다.North8000 (대화) 2022년 7월 18일 (UTC) 17:28

다음 두 가지 문제가 있습니다.첫 번째 문제는 기본적으로 모든 경우에 용어가 선호(또는 회피)된다는 광범위한 공감대를 찾을 수 있지만, 위키피디아인들은 명시적인 선호도를 성문화하거나 일부 용어를 금지하는 것을 극도로 꺼린다는 것입니다.네, "불법 이민자", "불법 외국인" 그리고 "불법 외국인"은 모두 다양한 사회적, 역사적, 법적 이유로 이민자들을 비하하는 언어입니다.이것이 사실 논쟁의 여지가 없다-논쟁은 그것에 대해 무엇을 할 것인가 하는 것이다.찬성하는 가장 흔한 주장 중 하나는 ("내가 사용하는 단어가 불쾌하다고 사람들이 말할 때 나는 좋아하지 않는다"를 제외하고) 그것들이 여전히 일부 공식 소식통들에 의해 사용되고 있다는 것이다.스타일가이드와 우리가 신뢰할 수 있다고 생각하는 다양한 소스가 점차 언어를 폐지하고 있지만, 그것들은 여전히 다양한 공식 문서에 나타나고 있는 것은 사실이다.논란의 여지가 없는 것은 이 용어들에 의해 영향을 받는 그룹들은 팬이 아니라는 것이다.
두 번째 문제는 명백한 대체품의 부족이다."미등록 이민자", "무허가 이민자", "불법 월경자" 등 사람마다 취향이 다르며, 예를 들어 다음과 같은 정당한 비판이 있다."creducated"는 정확하지 않습니다.명확한 대체물이 없다면, 다시 성문화하기가 어렵습니다.Wikipedia에는 선호하는 공식은 없지만 위에 열거한 세 가지는 권장되지 않으며, 이를 설명하는 자료 더미를 기꺼이 제공할 수 있다는 제안을 지지합니다(여기서 자세히 설명하지 않을 것입니다).궁극적으로, 이 용어를 사용하지 않는 이유는 많지만 사용해야 할 이유는 많지 않습니다.누가 알겠나, 충분히 많은 인원이 탑승할 수 있을지 모르지만, 나는 비관적이다.- \\ 2022년 7월 18일 (UTC)

그거 말이 되네.그 공식에 대해 폭넓은 동의를 얻는 것은 당신이 지적한 바와 같이 어려울 수 있습니다.- 도널드 앨버리 22:05, 2022년 7월 18일(UTC)
네, 공식은 까다롭겠지만 로덴드리테스의 제안은 좋아 보입니다.Doug Weller talk 2022년 7월 19일 07:04 (UTC)
만약 그 제안이 "불법체류자"를 막기 위한 것이라면, 저는 좋게 보이지 않습니다.위키피디아 기사 불법 이민, 불법 미국 이민 미국불법 이민의 경제적 영향캐나다로의 불법 이민존재하지만 제안된 대안이 없습니다.위키피디아 기사에도 "문서화되어 있지 않다"는 말이 나온다(그것을 단념시키는 제안은 모른다). 그러나 구글 Ngrs를 보면 "불법 이민자"가 감소하고 있는 것처럼 보이지만, 여전히 문서화되어 있지 않은 이민자를 능가한다.확실히 나는 그것이 "이민자에 대한 경멸적인 언어"라는 Rodendrites의 의견에 동의하지 않는다.그것은 매우 구체적으로 불법 이민자에 관한 언어이다.이것은 단순한 힌트가 아니다.반대가 있다면 그것은 불법에 관한 것임을 전 세계에 알리는 것이다.Peter Gulutzan (대화) 2022년 7월 19일 (UTC) 15:12
Ngs에서 스무딩을 해제하면 보다 정확한 그림이 표시됩니다. [1].이들은 0.000001% 미만으로 하락해 사실상 동률을 이뤘으며, 만약 2019년에 거의 같다면 지난 20년간 매우 강력한 추세선을 감안할 때 2022년에는 이미 넘어섰을 것이다.마지막 불법 이민 RM은 7년 전으로 보인다.오늘 결과가 달라질지 모르겠네요.Levivich (대화) 2022년 7월 19일 (UTC) 15:42
Ngs로 할까요?사용자가 이 텍스트를 복사한 것에 대해 사과드립니다.위커리 몬스터
A) N그램이 포지션 방어에 사용됩니다.대문자화에 관한 한 Ngram은 문헌에서 사용을 확립하는 효과적이거나 신뢰할 수 있는 수단이 아닙니다.[2], [3], [4] 효과가 없을 뿐만 아니라 조작이 용이합니다.N그램 [5]를 사용하면 구리 헤드 컬쳐가 주요 용어로 표시됩니다.
B) 신뢰할 수 있는 용도를 확립하는 유일한 방법은 문헌 리뷰입니다.
Doug Wellertalk 2022년 7월 19일 (UTC) 15:59
여기서 말하는 대소문자가 여기서 말하는 것과 무슨 관계가 있는지는 잘 모르겠습니다만, 이러한 Ngram의 예는 스무딩 설정을 변경하여 조작되고 있습니다.이러한 예들은 모두 매우 높은 값으로 설정됩니다.최고의 값은 0(최근 트렌드를 원하는 경우)입니다.기본값은 3(장기 트렌드에 적합합니다.평활을 0으로 설정하면 모든 관리도에 동일한 내용이 표시됩니다.Ngrams가 전부가 아니라는 것은 사실이고 조작할 수도 있지만, 그들이 보여주는 것은 정확합니다.Levivich (대화) 2022년 7월 19일 (UTC) 16:08
데이터를 매끄럽게 하지 않고서는 Ngram을 사용하지 말 것을 제안하지 않습니다.단기적인 트렌드를 보고 싶다면 작은 값을, 장기적인 트렌드를 보고 싶다면 큰 값을 사용합니다.장기적인 트렌드를 보고 싶다면 10은 높지 않습니다.일반적으로 1 또는 0은 너무 작습니다.3은 장기적인 트렌드에 비해 너무 작지만 10년 이상 동안 보고 싶다면 추천할 만하다.그것은 여기서 훨씬 잘 설명된다.언어 사용 트렌드에 Ngram을 사용해서는 안 된다는 것이 아니라 대문자화 트렌드를 주장하려고 하는 것은 매우 약해서 쓸모가 없다고 말할 수 있습니다.만약 당신이 한 구절을 다른 구절과 비교하고 싶다면 그것은 매우 미묘한 차이일 수 있다.예를 들어 특정 기간 동안 출처를 검색하기 위해 사용할 수 있지만, 문헌의 경향을 찾기 위해 출처를 검토하는 것을 대체할 수는 없다고 생각한다.WCMemail 16:27, 2022년 7월 19일 (UTC)
제시된 특정 주제를 보면 몇 가지 경향을 관찰할 수 있습니다.미국 영어로는 최근 불법체류자를 [6]법규화되지 않은 이민자가 추월했다.영국 영어의 경우, [7]의 반대는 그 용어의 사용이 빈약하다는 사실이다.두 명의 불법 이민자를 결합하는 것이 여전히 지배적인 용어이다.WP마다 상당한 차이가 있기 때문에 사용하지 말 것을 권장하는 것만큼 간단하지 않다고 생각한다.ENGVAR. 어떤 영어 변종에서 흔히 볼 수 있는 용어를 다른 영어에서는 보기 드문 용어로 사용하는 것은 갈등의 원인입니다.WCMemail 16:41, 2022년 7월 19일 (UTC)
캐나다에서는 '불규칙'이라는 단어가 논쟁에 휘말려 왔다.공개:인용된 소식통이 그런 말을 하지 않았기 때문에 나는 캐나다에서의 불법 이민 기사에서 캐나다에서의 사용에 대한 주장을 없앴다.Peter Gulutzan (대화) 2022년 7월 19일 (UTC) 17:31
"불법 이민"이라는 용어는 괜찮을 것이다. 왜냐하면 그것은 이민을 이민자가 아니라 불법이라고 부르고 있기 때문이다.확립된 법에 반하는 행위는 합법적으로 불법이라고 할 수 있지만, 사람을 불법이라고 명기하는 것은 문제가 있다.-아히트(토크
페이지) 22:01, 2022년 7월 19일 (UTC)

ngs를 비교하는 것은 용어가 의미와 함축 모두 대략 동일하며 단순히 가장 일반적인 것을 선택하는 것이라고 가정합니다.여기서는 그렇지 않다."퇴치"와 "퇴치"는 여전히 "지적/정신적/발달적/적극적 형태"보다 더 흔하다.미국 영어에서 "에스키모"는 여전히 "이누이트"나 "유픽"보다 더 흔하다.하지만 이 주제에 대한 우리의 기사는 더 흔한 것이 아닙니다. 왜일까요?"불법 이민자"와 마찬가지로, 이러한 용어들이 문제가 되는 많은 이유들은 간단한 검색만으로도 쉽게 찾을 수 있다.하나의 영어권 국가에서 용어가 불쾌하지만 다른 용어가 아니기 때문에 우리는 다른 용어로 디폴트해야 한다는 생각은 마치 다른 대안이 이해되지 않거나 전자의 의미가 무관한 것처럼 말이 안 된다.2022년에는 위에서 설명한 두 가지 사례보다 불법체류자가 더 폭넓게 받아들여진다는 것은 인정하지만, 많은 사람들에게 모욕적인 용어라는 사실은 여전혀.같은 용어로 여러 용어를 사용할 수 있고 함축된 함축성 때문에 내용에서 주의가 산만해지는 경우가 있을 때, 그 용어를 선택하는 이유는 무엇입니까?그런 맥락에서 "일반적으로 사용하는" 것으로는 충분하지 않다고 생각합니다.- \\ 2022년 7월 19일 (UTC) 17:20

나는 실제로 그것을 불쾌하거나 문제가 있는 용어로 보지 않으며 그것은 확실히 내가 살고 있는 곳이 아니다.당신은 분명히 내가 알지 못하는 어떤 이유로 이것에 대해 열정적이다.나는 그렇지 않기 때문에 나가서 내 시간을 좀 더 유용하게 쓸 수 있는 것을 찾을 것이다.나는 당신이 당신의 세계관을 공유하지 않는 그룹에 해결책을 강요한다면 그것은 좀처럼 좋게 끝나지 않을 것입니다.좋은 하루 되세요.WCMemail 17:33, 2022년 7월 19일 (UTC)
나는 실제로 그것을 불쾌하거나 문제가 있는 용어로 보지 않으며 그것은 확실히 내가 살고 있는 곳이 아니다. 당신은 분명히 내가 알지 못하는 어떤 이유로 이것에 대해 열정적이다.이 용어는 비록 당신이 사는 곳이 아니더라도 세계 여러 곳에서 불쾌하거나 문제가 있기 때문입니다.그것은 미국 영어에서는 불쾌하고, 영어의 주요 변종이다.Levivich (대화) 2022년 7월 19일 (UTC) 17:36
캐나다에서도 불쾌해요.에스키모 식별표 시스템 같은 끔찍한 것들이 우리 과거에 있었다.사람들이 그런 말을 쓰지 않는 데는 이유가 있다.이 이야기가 주로 불법 이민자에 관한 것임을 깨달았습니다.제가 Project Same을 시작했기 때문에 한 가지 예가 갑자기 떠올랐습니다. 하지만 제 의견은 인간을 묘사하기 위해 "불법"을 사용하는 것도 불쾌하다는 것입니다. 존재하는 것은 죄가 아니다.Clovermoss (토크) 17:53, 2022년 7월 19일(UTC), 편집:18:01, 2022년 7월 19일(UTC)
제가 모르는 어떤 이유 때문에 - 저는 많은 독자들을 모욕하지 않는 것에 열정을 가지고 있고, 가능한 한 부하가 적고 산만하지 않은 용어를 사용하는 것을 선호합니다.여기서 그게 가능했으면 좋겠어요.당신이 살고 있는 곳에 문제가 되지 않는 것이 사람들이 다른 곳에서 그것을 어떻게/왜 모욕적인 용어로 간주하는지 연구하고 배울 기회라기보다는 몇몇 프린지 POV처럼 그 아이디어를 일축하는 이유라는 것이 내게는 이상하다.북미 이외에서는 그다지 등장하지 않는 것은 놀랄 일이 아니지만, 구글 검색도 매우 간단합니다.- \\ 2022년 7월 19일 (UTC) 18:14

좋은 일반적인 규칙은 상당한 이유 없이 어떤 속성으로 인해 사람들을 "무고하게 만드는" 것을 피하는 것이다.그러나 컨텍스트가 불법인지 합법인지 여부를 중요하게 만드는 경우, PC는 제쳐두고 애매하거나 상태를 전달하지 않기 때문에 "문서화되어 있지 않음"은 문제가 되지 않습니다.North8000 (대화) 2022년 7월 19일 (UTC) 17:44

위의 Visibia와 Rhodendrite에 따르면, 한 사람(및 그러한 모든 변종)을 묘사할 때 경멸적인 "불법" 제형을 금지하지만, 그러한 다른 용도를 규정하지는 않는 것이 타당해 보인다.특정인을 전기적인 의미로 묘사할 때, "불법적으로 들어간" 등의 문구는 행동을 묘사하는 것처럼 괜찮지만, "불법체류자"나 "불법체류자" 또는 이와 유사한 용어를 사용하여 전기적인 의미로 표현해서는 안 된다.나는 단지 개념을 기술하는 것과 같은 일반적인 비개인적인 용법의 공식에 대해 별로 염려하지 않는다. 비록 나는 무관심하지는 않지만, 나는 "불법 이민자"가 가지고 있는 짐을 싣지 않는 덜 경멸적이고 중립적인 용어를 선호하지만, "등록되지 않은" 또는 "등록되지 않은"과 같은 대체 용어는 고통을 겪는다.유사한 문제를 해결합니다.감정적이지 않은 용어가 존재하지 않는다는 것은 인정하지만, 전기적인 맥락에서 사용할 때는 피할 수 있을 정도로 주의를 기울여야 한다는 것을 의미합니다.즉, 누군가가 합리적으로 중립적으로 간주되는 제제를 제안할 수 없는 한, 우리는 아마도 인도로의 불법 이민과 같은 기사 제목에 얽매여 있을 것이다.그러나 우리는 여전히 기본적으로 "존 도우는 불법 이민자였다"와 같은 것을 접해서는 안 된다. -제이론32 17:58, 2022년 7월 19일(UTC)

개인적으로 위키피디아에 가이드라인이 있어서는 안 되는 상황이라고 생각합니다.위키피디아는 크고 다양한 곳이고 몇몇 사람들이 싫어하게 된 용어가 다른 분야에서는 경멸적이지 않은 용어로 완전히 일반적일 수 있다.내 생각에, 누군가가 불법으로 한 나라에 있다는 것은 경멸할 만한 것이 아니다. 그것은 단지 사실의 진술일 뿐이다(명백하고 명백한 대체자가 없다).그렇긴 하지만 합리적인 사람들이 동의하지 않는 건 이해해요.제가 보기엔 위키피디아에서 지역 합의나 작가 개개인이 용도를 결정하도록 해야 할 상황이 바로 그런 상황입니다.Zoozaz1 (대화) 2022년 7월 19일 23:46 (UTC)

나는 그것이 그것에 대한 좋은 요약이라고 생각한다.제가 유일하게 언급하는 것은 다른 분야와 마찬가지로, 우리는 정말로 긴급한 이유 없이 사람을 부정적으로 명사화하는 것을 피해야 한다는 것입니다.우리는 일반적으로 "Joe Doe는 경주용 자동차 운전자"라고 말한다. 우리는 존재하지 않는 도시 전설 정책을 사용하여 "Dog Kicker"에서 위키로위커를 할 수 있다고 해도, 정말 절박한 이유 없이 "Joe Doe는 개 키커"라고 말하면 안 된다.North8000 (대화)12:54, 2022년 7월 21일 (UTC)
그것이 좋은 요약이라는 것에 동의하지 않는다.어떤 사람이 불법으로 나라에 있다고 해서 그 토론이 무엇에 관한 것인지조차 배우려고 노력하지 않은 것을 배신하는 것은 경멸할 만한 것아니다.누군가가 불법으로 한 나라에 있다고 말하는 것에 대해 경멸적인 것이 없다는 것에 아무도 동의하지 않는다."그것은 나에게 불쾌하지 않다"는 것은 왜 누군가가 그것을 불쾌하게 여기는지(혹은 우리가 이야기하고 있는 것조차) 알아내기 위해 노력하지 않지만, 많은 사람들에게 문제가 있다는 사실을 부정하지 않는다. 그리고 다른 선택사항이 있을 때 "동의하지 않는다"는 동의와 함께 그것을 완전히 무시하는 것은...이상적이지 않다.- \\ \ \ 15:33, 2022년 7월 21일 (UTC)
법을 어기는 사람은 누구나 "불법"이라는 용어에 불쾌감을 느낄 수 있다고 나는 말할 수 있을 것 같다.이 특정한 경우에 대한 용어의 회피는 미국 정치와 더 관련이 있다.그럼에도 불구하고, 합법성이 그것이 사용되는 문장/텍스트와 관련이 없는 한 이 용어를 사용할 이유가 없다.North8000 (대화) 2022년 7월 21일 (UTC) 16:09
법을 어기는 사람은 누구나 불법이라는 용어에 불쾌감을 느낄 수 있다고 말할있을 것이다-그렇다. 만약 그들이 합법적으로 주차했지만 너무 오래 머물렀을 때, 또는 그들이 주차한 장소에 대한 발언권이 없을 때, 그리고 "불법 주차자들"이 인종차별주의자들의 컨텐트에서 자주 사용되었을 때 등, 그들이 해서는 안 될 곳에 주차를 하는 사람들이 "불법 주차자들"이라고 불린다면.특정 그룹의 사람들에 대해 확장하면 유사할 수 있습니다.- \\ 2022년 7월 21일 (UTC) 18:31
제 견해는 위키피디아는 매우 다양하기 때문에 다른 관점에 대해 관대해야 한다는 것입니다.나는 어떤 사람들이 그 용어를 "무언정"하는 것에 불쾌감을 느낀다는 것을 충분히 이해한다.그들은 그들이 원하는 대로 위키피디아에 글을 쓸 수 있어야 한다.다른 사람들은 그것을 중립적인 사실의 진술로 본다; 그들은 또한 그들이 원하는 대로 쓸 수 있어야 한다.나에게 이상적인 것은 궁극적으로 상당히 무해한 토론에 대해 다른 관점을 강요하는 것이 아니다.더 명확한 경우, 그 용어가 주류로 받아들여지지 않았다면, 비 경멸적인 수용(예: "불법")이 훨씬 더 나은 용어가 있지만, 불법 이민이라는 용어는 여전히 많은 맥락에서 중립적이고 비 경멸적으로 사용되고 있다.Zoozaz1 (대화) 2022년 7월 21일 (UTC) 18:09
신원이 확인되거나 확인될 수 있는 실제 사람들과 관련된 토론은 사실 무해한 토론이 아닙니다.Doug Wellertalk 2022년 7월 21일 18:12 (UTC)
내 요점은 어떤 사람이 불법적으로 (또는 그 반대로) 어떤 나라에 있다고 말하는 대신 불법 이민자라고 부르는 것은 궁극적으로 대범한 계획에서 공평하게 (전혀) 해가 없다는 것이다.Zoozaz1 (대화) 2022년 7월 21일 (UTC) 18:21
그래서 개인은 계산에 넣지 않고 일종의 "대계획"에 불과합니다.당신은 그것으로 많은 것을 용서할 수 있습니다.Doug Weller talk 2022년 7월 21일 18:46 (UTC)
우리는 "글쎄요, 어떤 사람들은 그것이 불쾌하거나 부정확하다고 생각하지 않기 때문에 위키피디아에 대해서는 OK"보다 더 정교한 논리로 작동해야 합니다.그것은 어떤 사람들이 단순히 "그것은 모욕적이지 않다"고 말하는 한 불쾌하게 여겨지는 어떤 용어라도 절대적으로 허용할 것이다.유일하게 관련된 질문은 그 관점이 얼마나 두드러지는가 하는 것이다. 그것이 불쾌하거나 다른 면에서 문제가 있다는 것이다.그룹 구성원이 거의 한결같이 반대할 때, 주요 언론사가 명백하게 사용을 중단했을 때, 다양한 조직 및 제도 핸드북에서 제외되었을 때..."위키피디아에서 Zoozaz1이 별것 아니라고 한다"라고만 말하는 것은 정책의 좋은 근거가 아닐지도 모른다.추가:이것은 마치 헛수고처럼 느껴집니다.저는 이 섹션을 너무 많이 차지하기 때문에, 뭔가에 투표할 시간이 되지 않는 한(혹은 제안서를 작성하는 데 도움이 필요한 사람이 있는 경우) 이 스레드를 회피합니다.- \\ 2022년 7월 21일 (UTC) 18:31
그럼 이렇게 말할게요.나는 중립적이라고 생각하는 모든 공격적인 용어들이 허용되어야 한다고 생각하지 않는다.그러나 만약 그 용어가 주류 소스와 사회 전반에서 경멸적이지 않은 방식으로 자주 사용되어 왔고 앞으로도 계속 사용되고 있다면, 나는 다원주의를 위해 그것을 용인해야 한다고 생각한다.Zoozaz1 (대화) 2022년 7월 21일 19:27 (UTC)
하지만 그것은 경멸적이지 않은 방식으로 사용되는가?여기 영국의 많은 신문들은 불법 이민자라는 용어를 사용하지만, 내 경험상 그것은 거의 항상 경멸적인 말로 사용되어 사람들을 그렇게 묘사하는 사람들에게 등을 돌리게 한다.우리는 신문보다 더 나은 소식통을 따라가야 한다.Phil Bridger (대화) 2022년 7월 21일 (UTC) 20:04
위키피디아 용어 사용은 신뢰할 수 있는 출처에서의 사용을 반영해야 합니다.rs는 대부분 "불법 이민자"라는 용어의 사용을 중단했기 때문에 기사도 그래야 한다.만약 현학적인 태도를 원한다면, 법원에서 최종적으로 결정이 내려질 때까지 이 불법체류 노동자들 중 어떤 사람도 미국에 불법체류되어 있다는 것은 확실치 않다.IOW, 우리는 그들이 "불법 이민자"인지 아닌지를 그들이 추방될 때까지 알 수 없으며, 이 경우 그들은 더 이상 불법 이민자가 아니다.TFD (토크) 2022년 7월 21일 (UTC) 16:29

IMO, 이건 공격보다는 미국 정치에 관한 거야저는 국경 남쪽에서 온 많은 친구들이 있고(몇몇은 불법적으로 이곳에) 그들의 집을 포함해서 그들과 많은 시간을 보내고 있습니다.법적 지위에 따라 사람을 명사화하지 않고 법적 지위는 관련이 없는 대화에서 사용되지 않지만, 자신을 포함한 법적 지위에 대해 언급할 때 "불법"이라는 용어를 사용하는 것을 주저하지 않는다.그런데 나는 그들이 정치적으로 유행하는 용어 "라틴"을 자랑스럽게 젠더 명사를 사용하는 그들의 문화에 대한 모욕으로 간주한다는 것을 알았을 때 정치와 범죄를 구별하기 시작했다.North8000 (대화)2022년 7월 21일 (UTC)

재미있는 읽을거리네요.저자는 "불법"의 경멸적 사용에 대해 논하면서 이 용어가 인종차별적 프로파일링을 위한 "개 호루라기"라는 주장이 있다고 지적한다.한 가지 흥미로운 점은 사전 허가 없이 미국에 입국하는 것은 형사 범죄이며, 비자 만료 후 미국에 체류하는 것은 민사 범죄이며, 현재 허가 없이 미국에 거주하는 모든 사람을 "불법"으로 부르는 것은 모호하다는 저자의 진술이다. - 도널드 알버리 22:53 (UTC)

그들은 불법인 것은 "민사상 범죄"이기 때문에 "범죄"가 아니면 불법이라고 할 수 없다고 말하는 것 같다.민법(개인의 법정행동의 근거가 되는 것) 같은 것은 있지만 민사범이라는 것은 들어본 적이 없고, 그런 공식적인 것은 없다고 의심하고 있습니다.불법 주차도 불법입니다.North8000 (대화)3:55, 2022년 7월 22일 (UTC)
그거 좋네요.North8000 (대화)12:35, 2022년 7월 22일 (UTC)
거의요. 아래를 보세요.
우선, 나는 그 행동이 사람이 아니라 불법이라는 당신(North8000)과 아히트(Ahecht)의 의견에 동의한다(예를 들어, 불법 출판은 저작권 침해를 의미하지만, 누군가에게 '불법 출판자'라고 하는 것은 흔치 않다고 생각한다).그러나 미디어가 문법적인 단축키를 즐기는 것은 이해할 수 있으며, 따라서 식별자를 사용하는 소스를 쉽게 찾을 수 있을 것이다.
둘째, 저의 요점은 OP가 언급한 '무허가 비시민'이라는 어색한 용어가 더 정확하다는 것입니다.나는 조 바이든 삼촌의 팬은 아니지만, 그의 용어는 내가 읽은 기사에서 "불법 이민자"의 많은 부분(40% 혹은 60%?)이 합법적으로 입국했지만 비자를 초과한 사람들이라고 말하는 것과 더 잘 들어맞는다.그런 의미에서 그들은 법을 따르지 않은 사람들과는 다르게 분류된다(또는 IMO여야 한다).몇몇 나라들은 어느 정도 그것에 대해 유연하다.
셋째로, 이들 중 많은 사람들은 이민자가 아닙니다.영원히 머물 생각이 없습니다.그것은 단지 돈을 벌어서 모국에 집을 살 수 있을 정도로만입니다.취업 비자를 받은 많은 사람들이 비슷한 동기를 가지고 있지만, 그들은 합법적으로 DHS 분류에서 "비이민자"로 지정된 그들의 지위를 신청했다.마르틴도 (토크)2022년 8월 2일 (UTC)
우리가 어떤 새로운 용어를 사용하든 위키피디아의 용어 포함은 공통의 담론에의 진입과 불가피한 오용을 보장할 것이기 때문에 10년 후에는 경멸적인 것으로 간주될 것이다.만약 이것이 특정한 사람들에 관한 것이라면, 그 용어를 피하고 사실을 진술하세요.John Doe는 비자 없이 Fooland에 입국한 베스트셀러 작가이며, 이후 사전 승인 없이 Fooland에 입국한 혐의로 기소되었습니다.라벨이 사실을 바꾸지 않기 때문에 일반적으로 주제를 논의할 때 사용합니다.노숙자/얼굴 벗기지 않은/숨기지 않은 누군가가 여전히 안정된 주거의 부족으로 고통 받고 있는 것처럼, 이런저런 꼬리표를 사용하는 것은 다른 사람들의 기분을 나아지게 할 수 있지만, 실제로 개인의 환경을 바꾸는 데는 아무 것도 하지 않는다.Sliwriter (토크) 21:11, 2022년 8월 2일 (UTC)

한편, 2006년판 Wikipedia:명명 규칙(이민)은 보다 적절한 페이지 제목으로 이동해야 할 수 있습니다.델의 위키피디아:명명 규칙은 기사 본문이 아닌 기사 제목(예: 인도의 불법 이민자, 리다이렉트)에 기재된 내용에 관한 것입니다.그 페이지의 실패한 제안서는 주로 기사에 무엇을 쓸 것인가에 관한 것이다("밥은 불법체류자로 의심되었다.성공적이었으면 스타일 매뉴얼의 하위 페이지로 끝났을 수도 있지만 그렇지 못했기 때문에 정책이나 가이드라인과의 연결을 암시하지 않는 간단한 이름을 지정하는 것이 더 나을 수 있습니다.좋은 생각 있는 사람?WhatamIdoing (대화) 2022년 7월 22일 (UTC) 17:56

레퍼런스

목록 소개 자료에 대한 MOS 섹션

목록 소개 섹션의 확립된 관행을 더 잘 설명하기 위해 일련의 편집을 했다[9].실제 관행에 대한 변경은 의도되지 않았다.좀 더 좋게(혹은 내 실수를 잡아내기 위해) 다른 눈알들도 체크해 주면 고맙겠다.고마워요.NewsAndEventsGuy (토크) 2022년 7월 19일 (UTC) 13:23

독립 실행형 목록에 대한 지침의 관련 편집

마찬가지로 WP:Stand-alone lists#Documenting selection criteria의 새로운 서브섹션에 기존 프랙티스를 추가하려고 했습니다.다시 말하지만, 관행의 변경은 의도되지 않았다.검토 부탁드립니다.NewsAndEventsGuy (토크) 2022년 7월 19일 (UTC) 15:38

그 편집은 꽤 괜찮은 것 같습니다.그렇게 보람없는 일을 맡아 주셔서 감사합니다.다만, 새로운 「문서 선택 기준」의 섹션이, 현재의 표현대로, 리스트의 포함 기준을 확립하기 전에 편집자가 합의를 구한다는 새로운 기대를 낳는 것 같아, 조금 염려됩니다.편집자 개개인이 대담하게 새로운 목록을 만들고 그에 대한 합리적인 초기 기준을 정의하는 것을 단념할 수 있는 것은 없어야 한다고 생각합니다만, 이러한 기준은 나중에 다른 편집자에 의해 논의되거나 개선될 수 있습니다.Wikipedia가 현재 얼마나 많은 문제를 겪고 있는지 고려할 때, 의견 일치를 볼 수 있는 사람을 찾는 것은 어려울 수 있으며, 추가적인 장벽은 상황에 도움이 되지 않는다. (물론, 많은 위키피디아인들은 WP:EDITCON은 당연하지만, "합의의 확립"은 특히 "합의가 확립된 문서"에 대한 후속 참조를 고려할 때 보통 "합의의 확립"을 의미하는 것은 아니다.)토크 페이지에 다른 표현을 제안했습니다.- Visviva ( talk ) 2022년 7월 19일 (UTC) 17:50
"새 목록" 각도가 정말 좋은 뉘앙스입니다. 감사합니다.소스 행사장에서 답변을 드렸습니다.NewsAndEventsGuy (토크) 2022년 7월 19일 (UTC) 18:56

참고로 프로포즈 Ver 2는 방금 여기서 라이브로...NewsAndEventsGuy (토크) 2022년 7월 23일 09:05 (UTC)

길 좀 가르쳐 주세요

진행 중인 콘텐츠 분쟁에서 유리한 정책 수정 제안 및/또는 정책 제안에 대해 콘텐츠 분쟁 참가자에게 알릴 의무에 대한 정책 또는 지침을 찾는 데 어려움을 겪고 있습니다.대체 어디 있는 거야? 원하는 모든 (대화) 2022년 7월 25일(UTC) 02:29

관련 정책은 WP:AGFWP:NPAWP:POINT. 더 얘기하고 싶으면 ANI/AE/ARBCOM에서 하고 여기서는 안 돼요.NewsAndEventsGuy (토크) 2022년 7월 25일 (UTC) 02:56
세 사람 모두 콘텐츠 분쟁에서 유리한 정책 편집에 대해 논의합니까?나는 단지 P&G에서 그 주제에 대한 명확한 논의를 찾고 있다.일단 내가 관련된 명시적인 P&G를 찾으면 나는 다른 것을 할지 말지 결정할 것입니다. 원하는 모든 (대화) 2022년 7월 25일(UTC) 03:10
확실하지 않지만(구체적으로 찾지 않음) WP를 볼 수 있습니다.GAMING News And Events Guy (토크) 2022년 7월 25일 03:12 (UTC)
저는 이 문제에 대해 아무것도 보지 못했고, 관련 토크 페이지나 아카이브에서도 보지 못했습니다.만약 다른 사람에게 적절한 규칙을 알려준다면 답변을 주세요.응답하면 다른 편집자가 질문에 답한 것으로 간주할 수 있습니다.고마워요. 원하는 모든 것(대화) 2022년 7월 25일 (UTC) 03:17
아마 아무것도 적혀 있지 않을 거예요. 그랬으면 좋겠어요.모든 것에 대한 규칙이 있는 것은 아닙니다.우선, 분쟁 중에 정책 수정을 제안하는 것이 좋은 것인지 나쁜 것인지 명확하지 않습니다.내 생각에 답은 "둘 중 하나일 수도 있다"이다.그래서 규칙은 기본적으로 "글쎄요, 때로는 예, 때로는 아니오, 당신의 상식을 사용하세요"라고 해야 합니다.그 문제에 대한 설득력 있는 에세이가 좋을 것이다.
최근에 작가와 다투던 중에 MOS를 바꿨는데...그는 MOS가 잘못 해석해서 하지 말아야 할 말을 하고 있었습니다. 하지만 그것은 조금 불분명했습니다.그래서 바로 해결했고, 문제는 해결됐어요.어떤 경우 편집자는 나쁜 이유로 정책 변경을 제안할 것이고, 정책 변경을 제안하지 않을 경우 변경에 대한 공감대가 형성될 경우 어떤 문제가 발생합니까?Herostratus (토크) 2022년 7월 25일 13:30 (UTC)
예를 들어, 기사 토크에서 콘텐츠 분쟁이 발생하여 편집자가 관련 가이드라인이나 정책을 변경하기 위해 떠났을 경우, 해당 편집자에게 기사 토크에서 이에 대한 발언을 요구하고, 반대로 정책 토크 페이지(및/또는 마을 펌프)에서 콘텐츠 분쟁을 언급하도록 하는 것이 현명하지 않을까요? 원하는 모든 것(대화) 2022년 7월 25일 (UTC) 15:56
@당신이 원하는 것은 무엇이든 WP:PGBOLD: "적극적인 토론에서 자신의 주장을 뒷받침하는 정책을 편집하는 것은 시스템을 조작하는 으로 보일 수 있습니다.특히 편집 시 논쟁에 관여하는 것을 공개하지 않는 경우에는 더욱 그렇습니다.
('정책 편집'과 '토크 페이지에 변경 제안' 사이의 간격에 유의하십시오.)WhatamIdoing (대화) 2022년 7월 25일 (UTC) 21:06
좋은 정보네요, 감사합니다.나는 그것을 찾느라 많은 시간을 소비했다.저도 실생활에서 특별히 물건을 잘 찾지는 못했지만, 그래도 그 방침에 대한 연결고리를 좀 뿌려보겠습니다.2022년 7월 25일(UTC) 21:22 (토크)
물론 적용되려면 제안된 변경이 기사 내용 분쟁의 합의 결정을 변경하기 위한 것이었음을 보여주는 것이 필요하지만, 저는 단지 우리 모두가 공감할 수 있도록 여기서 언급하는 것입니다.지금은 그 토론에 들어갈 자리가 아니다.NewsAndEventsGuy (토크) 2022년 7월 25일 (UTC) 23:27
ArbCom의 전례도 있습니다.「정책 페이지의 편집은, 특정의 편집 경험에 의해서 촉진되는 경우가 많지만, 특정의 분쟁에 있어서의 자신의 입장을 높이기 위해서 정책 페이지를 변경하는 것은 부적절합니다.」굳이 짚고 넘어가진 않겠지만, 당신이 원하는 건 뭐든지 그 결과에 익숙할 거예요.MastCell 00:59, 2022년 7월 27일 (UTC)
  • 우리는 여기에 이것에 대한 해트를 방금 설치했다.지금부터 MastCell의 11년 된 인용문에 대해 언급하겠습니다(기억이 잘 나지 않습니다).WP보다 조금 더 엄격한 것 같습니다.PGBOLD는 우리가 방금 해트노트를 썼던 것에 대한 이다.그 불일치를 쉽게 처리할 수 있기를 바랍니다.이 문제에 대한 나의 현재의 관심은 11년 전의 일에서 비롯된 것이 아니라 이것에서 비롯된 것이다.11년 전의 정책 편집에 대해서는, 적절한 편집 개요(「오늘 편집한 기사에 관해서 굵은 추가」)를 붙여 편집한 지 몇 주 후의 정책 수정과 다른 편집자가 정책 변경 편집을 수정한 지 몇 주 정책 수정을 예로 들었습니다.2011년에 ArbCom이 MastCell에 의해 여기서 인용된 성명(및 ArbCom이 그 성명을 발표하도록 유도한 정책을 편집했을 때)을 발표했을 때 WP:PGBOLD의 관련 부분은 오늘날 그대로였다.MastCell에 의해 인용된 ArbCom의 스테이트먼트가 WP보다 우선하는지는 알 수 없습니다.특히 ArbCom이 WP:PGBOLD에 대한 인식을 분명히 나타내지 않았기 때문에 PGBOLD 또는 그 반대도 마찬가지입니다.WP:PGBOLD가 위키피디아로 하여금 이 문제에 대한 위키피디아 통치 입장이 실제와 다르다고 생각하도록 유도한다면 유감스러울 것이다.2011년에 WP를 봤다고 믿었는지 기억나지 않는다.PGBOLD든 아니든 간에, 나는 Arbcom에게 단어 제한이 초과되고 있으며 과도한 비난에 대처할 의무가 없다고 말했다(Arbcom은 분명히 그들이 전혀 언급하지 않았기 때문에 그 주장을 크게 생각하지 않았다).2011년에도 정책 편집은 정책 변경이라기보다는 명확화라고 생각한다는 점을 지적하고 몇 년 후 편집자를 만나 정책 편집은 기본적으로 정책에 의해 암시되고 있음을 확인했습니다.여기 WP 편집에 관심이 있는 사람이 있다면:PGBOLD는 MastCell이 인용한 2011년 ArbCom의 발언에 대한 반응으로, 이제 당신은 그것에 대해 더 많은 배경을 갖게 되었고, 당신은 내가 명확하고 솔직하게 글을 쓰려는 최선의 노력에도 불구하고 왜 편견을 가질 수 있는지 알게 되었다. 원하는 모든 것(대화) 2022년 7월 27일(UTC) 10:52

@ 원하는 것:나는 네가 이만큼 오랫동안 나를 비방하도록 지겹고 참을성 있게 내버려두었다.WP에서 최선을 다해 주세요.ANI 또는 WP:DROPTESTIC.NewsAndEventsGuy (토크) 2022년 7월 27일 (UTC) 11:14

이봐, 내가 이 전체 섹션에서 "지휘해 주세요"라는 제목으로 당신을 비난한 적이 있나요?이 섹션 전체가 적절한 정책을 찾기 위해 시작되었습니다.사용자 덕분에 정책을 사용할 수 있게 되었습니다.'정책 편집'과 '토크 페이지 변경 제안'의 차이를 신경써야 한다는 지적은 누가 제대로 했는가.리스트 기준에 관한 정책을 편집한 적이 없기 때문에 WP:PGBOLD를 위반하지 않은 것은 분명합니다.또한 ArbCom이 더 엄격한 정책을 가지고 있는지 여부는 현재로선 상관없습니다. 원하는 모든 (대화) 2022년 7월 27일 (UTC) 11:24

새로운 기사의 초안이 작성되었을 때 작성자에게 보내는 메시지

이 문제는 리뷰어에 의해 초안 공간으로 이동된 기사 작성자의 사용자 토크 페이지에 게시된 메시지에 대한 것입니다.새 문서를 초안 공간으로 이동하는 새 페이지 검토자는 일반적으로 다음과 같은 메시지를 게시하는 스크립트를 사용합니다.

신뢰할 수 있는 독립적인 출처로부터 더 많은 인용문이 필요하다. (참조할 수 없는 정보는 삭제되어야 한다(Wikipedia에서 검증가능성이 가장 중요하다).

문제는 적어도 두 가지 다른 이유로 새로운 기사의 초안이 작성된다는 것이다.첫 번째, 즉 캔 메시지가 지향하는 것은 소싱 또는 검증 가능성 문제입니다.두 번째는 새로운 기사의 초안이 작성되는 일반적인 이유이기도 하지만, 주목할 만한 문제입니다.기사는 신뢰할 수 있는 출처를 가지고 있지만, 일반적인 인지도를 충족시키기 위한 중요한 커버리지를 제공하지 않거나, 음악적 인지도와 같은 특별한 인지도를 충족시키지 못합니다.이것은 저자에게 도움이 되지 않는 안내로 귀결된다.그런 다음 작성자는 통지성 문제를 해결하지 않고 초안을 참조 폭격하고 다시 제출할 수 있습니다.사용된 메시지는 문서를 초안 공간으로 이동할 때 새 페이지 검토자가 일반적으로 적용하는 표준과 일치하지 않습니다.소싱이 불충분한 많은 기사에는 해당되지만, 알림이 확립되지 않은 적절한 소스 기사에는 해당되지 않습니다.

초안 공간으로 기사를 옮긴 저자가 DRN에서 제기한 분쟁 해결 요청을 거절하고 거절했습니다.기사는 이스라엘 음악가의 BLP로, 신뢰할 수 있는 이스라엘 신문들에 대한 언급이었다.그 기사는 음악적 인지도를 확립하지 못했다.저자는 출처가 믿을 만하다고 말했다.출처는 믿을 만했지만, 그 기사는 주목을 끌지 못했다.그 메시지는 전혀 도움이 되지 않았다.이것은 일반적인 문제입니다.

다음 4가지 해결책이 있습니다.

  • 1. 새 페이지 리뷰어에게 소싱이 불충분한 경우에만 기사를 초안 공간으로 이동하도록 지시합니다. 페이지 검토자에게 문서를 삭제하도록 제안하거나, 소싱 문제가 아닌 알림 문제가 있는 경우 해당 문서를 삭제하도록 지정합니다.
  • 2. 새 페이지 검토자에게 통지할 수 있는 이유로 기사를 초안 공간으로 이동할 때 초안 메시지를 다시 쓰도록 지시합니다.
  • 3. 기사를 초안 공간으로 이동시키는 이유에 대한 설명을 확장하거나 검토자에게 지침을 요청하기 위한 조언을 포함하도록 캔 메시지를 다시 작성합니다.
  • 4. 드래프트 스크립트를 확장하여 메시지를 선택할 수 있도록 합니다.

어떤 옵션을 선택해도 검토자를 위한 작업이 더 많이 생성될 수 있습니다.제 의견은 어떤 경우든 검토자에게 지침을 요청하기 위한 조언을 포함시켜야 한다는 것입니다.검토자는 새로운 저자가 좋아하지 않는 조치를 취한 이유를 기꺼이 설명해야 한다.옵션 1은 권장하지 않습니다.검토자는 통지 가능성의 이유로 기사를 초안 공간으로 이동할 수 있어야 합니다.또, 통지 가능성의 확립에 도움이 되지 않는 참조가 있는 경우에서도, 통지 가능성의 이유로 기사를 초안 스페이스로 이동할 수 있습니다.Robert McClenon (대화) 2022년 7월 27일 (UTC) 01:27

초안 편집자가 드롭다운 메뉴에서 기준을 선택할 수 있는 XfD 인터페이스와 같은 도구를 사용해 보겠습니다.BD2412T 2022년 7월 27일 02:09 (UTC)
사용자만 포함하면 안 될까요?완전히 새로운 툴을 작성하는 대신 Evad37/MoveToDraft를 사용하시겠습니까?Curbon7 (대화) 2022년 7월 27일 (UTC) 04:38
@Robert McClenon은 매우 광범위합니다. 구체적으로 어떤 정책 및/또는 가이드라인에 변경을 제안하십니까?편집자가 다른 편집자와 의사소통이 원활하지 않은 경우, 지도하는 것으로 충분할 수 있습니다. 주요 문제는 WP를 검토하고 따라야 하는 사람들과 관련이 있는 것으로 들립니다.BITE/WP:DTTR? 위키피디아 토크:새로운 페이지의 순찰/리뷰어는 NPR 프로세스의 일반적인 개선을 검토하는 데 더 좋은 포럼이 될 수 있습니다.- xaosflux 13:11, 2022년 7월 27일 (UTC)

GNG를 필요로 하는 기사의 경우, 수많은 편집자가 GNG 소스를 찾아 포함하거나, 없으면 포기해야 하며, 기사에 GNG가 없을 때는 초안이 적절한 작업 장소입니다.「단일 AFD these」(현재의 wp:before 루틴으로)라고 하는 것으로써, 「소스 검색」의 작업 전체를 편집자로부터, 매일 약 1,000건의 기사의 리뷰와 폐기 워크로드를 처리하려고 하는, 이미 매몰되어 있는 NPP로 이행하는 것을(의도하지 않고) 제안하고 있는 것입니다.North8000 (대화)2:38, 2022년 7월 27일 (UTC)

사용자: North8000 - 제가 쓴 글을 잘못 읽었거나 명확하게 쓰지 않았습니다.당신은 제가 의도치 않게 소스 검색의 전체 작업을 편집자에서 NPPers로 옮기자고 제안했다고 말했습니다.아니요. 옵션 1을 추천하지 않는다고 말씀드렸기 때문에 검토자에게 더 많은 작업을 제공할 수 있습니다.스크립트가 사용자 토크 페이지에 메시지를 남기는 방식과 일관성이 있기 때문에 완전성을 위해 옵션 1을 나열해야 했습니다.당신이 나열한 이유로 옵션 1은 마음에 들지 않지만, 현재 툴과 일치합니다.Robert McClenon (토크) 06:02, 2022년 7월 27일 (UTC)
@Robert McClenon:네, 맞아요.못 알아 들었어요.미안해요.North8000 (대화) 2022년 7월 27일 (UTC) 13:02
편집자는 표준 텍스트를 수정하여 초안의 이유를 반영할 수 있으며, 상자에는 큰 빨간색 글씨로 텍스트를 적절히 변경할 수 있습니다.검증 가능성보다는 알림에 초점을 맞춘 기본 텍스트를 옵션으로 사용하는 것이 더 쉬울 것이라는 데 동의합니다.Mccapra (대화) 5:00, 2022년 7월 27일 (UTC)
사용자:Mccapra - 편집자가 표준 텍스트를 수정할 수 있음을 알고 있습니다.나는 평론가들이 그것을 하는 것을 거의 본 적이 없다.리뷰어들이 초안 메시지의 표현을 중요하게 여기거나 다시 쓸지 고민하는지는 잘 모르겠습니다.Robert McClenon (토크) 06:02, 2022년 7월 27일 (UTC)
우리가 해결책의 일부로서 동의해야 할 것은 표준 초안 메시지에 언어를 추가하여 작성자가 검토자에게 지침을 요청할 수 있다는 것입니다.Robert McClenon (토크) 06:02, 2022년 7월 27일 (UTC)
그게 좋겠네요, 네.Mccapra (대화) 2022년 7월 27일 (UTC) 07:33
저도 동의합니다만, 드래프트의 이유로 자동 메시지에 체크 박스 옵션이 포함되어 있으면 도움이 됩니다.잉그라티스 (대화) 2022년 7월 27일 (UTC) 08:22

기본 메시지를 삭제하고 "여기에 메시지 삽입"이라고 말하는 것만으로도 개선됩니다.IMO 디폴트메시지는 너무 전문적이고 너무 까다롭습니다.그것은 또한 잘못된 것을 암시하는데, 그것은 그들이 스스로 드래프트 밖으로 그것을 옮길 수 없다는 것이다.North8000 (대화) 2022년 7월 27일 (UTC) 13:22

NPP 페이지 큐레이션 도구에 정식 드래프트 옵션을 제공하는 공개 요청이 있습니다.WMF가 NPP를 지원하기 위해 더 많은 리소스를 할당할 때까지 이 작업은 그다지 빠르게 구현되지 않을 수 있습니다.만약 그렇다면 이 새로운 툴에는 적절한 메시징 옵션이 포함되어 있을 것입니다.새 도구를 구할 때까지 기본 메시지를 다시 쓰는 것이 더 쉬울 것입니다.MB 1:40, 2022년 7월 28일 (UTC)
  • 주석 편집자는 제도 도구 내에서 자유롭게 언어를 변경할 수 있습니다.편집자가 잘라내거나 삭제 및 입력할 수 있도록 텍스트에 메시지를 추가하고 있습니다.몇 분 더 걸리는 건 알지만, 효과가 있어요.브룩스턴 (토크) 2022년 7월 28일 (UTC) 23:12

스타일 설명서 - 전기에서 포스트 노미네랄

Wikipedia_talk의 토크 페이지에 글을 올렸습니다.포스트 후보자에 대한 정책 개선을 제안하기 위한 Manual_of_Style/Biography. 일부 포스트 후보자는 기사 제목과 정보 상자에서 제거됩니다.Wikipedia_talk:매뉴얼_of_Style/Biography # 펠로우십_by_subscription, 예를 들어_e.FRSA

저는 [10]을 변경했지만, 더 많은 논의가 필요하다고 느낀 다른 편집자에 의해 수정되었습니다.관심있으시면 토론에 참여해주세요.History like you (talk) 2022년 7월 29일 (UTC) 11:59

나는 "더 많은 논의가 필요하다"고 느끼지 못했다.나는 어떤 논의도 필요하다고 느꼈다.이전에 정확히 17개의 편집을 했던 이 편집자는 WP를 전혀 사용하지 않고 일방적으로 MOS를 대폭 변경했습니다.컨센서스(CONSUMENCE)는 영국 전기에서 특정 포스트노미네이트를 대량 삭제함으로써 그의 변화를 대대적으로 실행했다.WP:Administrators'_noticeboard/Incidents #Newbie 대량 삭제 영국 전기(현재 permalink [11])를 참조하십시오.Softlavender (토크) 2022년 7월 31일 (UTC) 01:30

테크니컬

벡터 2022의 좌표

안녕하세요. mediawiki.org의 Desktop Improvements/Vector 2022 토크 페이지에 "버그 보고서"가 있지만 WMF에서는 수정할 수 없습니다.이것은 지역 커뮤니티에 전적으로 달려있는 것입니다.이 경우는 영어 위키피디아 커뮤니티입니다.

좌표에 관한 거야 스크린샷에서 볼 수 있듯이 FA 및 페이지 보호 아이콘에 너무 가깝습니다.@Jdlrobson은 이 문제를 해결하는 가지 방법을 공유했습니다.이제 인디케이터 태그를 사용하는 것을 강력히 권장한다고 말할 수 있을 것 같기 때문에 Jon's Option 1입니다.모듈을 변경해야 합니다.좌표.

@The DJ, Sdkb Xaosflux: 참고하세요.

감사합니다! SGrabarczuk (WMF) (대화) 2022년 7월 20일 (UTC) 22:59

@SGrabarczuk(WMF) 라이브 오버랩 페이지의 를 다음에 나타냅니다.이 템플릿은 100만 페이지 이상에 사용되고 있기 때문에 변경을 신중하게 검토하고 테스트해야 합니다.또, 프리젠테이션의 관점에서 독자를 위한 최선의 레이아웃을 결정하려면 편집자가 필요하다고 생각합니다(「그 큰 언어를 위에서 떼어내면, 독자를 프로젝트에서 멀어지게 할 뿐입니다」라고 하는 반대가 분명히 있다고 가정합니다).저는 실제로 그것이 있는 곳의 좌표를 좋아합니다.그것은 결국 "콘텐츠"입니다.메타 지표는 이동할 수 있을지도 모릅니다(언어 바의 왼쪽).?) - xaosfluxTalk 23:44, 2022년 7월 20일 (UTC)
저는 Fabricator에 대해 답변했습니다만, 여기서 다시 한 번 말씀드리지만, 다른 곳에서 주장했듯이, 좋은/특징 기사 아이콘은 제목 바로 뒤에 있는 것이 가장 좋습니다.이 아이콘은 정보 리터러시(information literacy)를 위해 훨씬 더 두드러질 것이기 때문입니다.
보호 아이콘의 경우 보호와 관련된 대부분의 사용자에게 주요 질문은 "현재 권한으로 이 페이지를 편집할 수 있습니까?"이기 때문에 편집 버튼과 관련이 있어야 합니다.Minerva Neue는 이 문제를 잘 처리합니다.페이지를 편집할 수 있으면 편집 버튼이 표시되고, 편집할 수 없으면 회색으로 표시되거나 잠겨 있거나, 그 이유를 설명합니다.독자들에게 보호 수준을 알려주고 그들이 읽고 있는 기사가 공공 기물 파손에 얼마나 취약한지를 이해시키는 것도 가치가 있지만, 그건 부차적인 것이고, 저는 그렇게 눈에 띄는 알림이 필요하지 않다고 생각합니다.{{u Sdkb}}talk 2022년 7월 21일 01:28 (UTC)
보호를 위해 코어 핸들 아이콘이 있는 은 phab:T12347 이즈노 (토크)2:54, 2022년 7월 21일 (UTC)
2007년 6월 23일 오후 5시 24분 bzimport에 의해 작성되었습니다.실제로 해결할 수 있는 에너지의 20배를 소비하지 않는 기술적인 문제는 없을까?{{u Sdkb}}talk 2022년 7월 21일 04:40 (UTC)
고려해야 할 한 가지 방법은 스킨을 입은 일등 시민으로 좌표를 만드는 것이다.@TheDJ: 이 POC는 스킨 베이스로 활성화할 수 있는 하나의 옵션을 시연하기 위해 작성되었습니다.표시할 수 있습니다.시간을 더 벌기 위해 해당 스킨에 현재 좌표가 없습니다.이 어프로치가 어느 쪽인가 하면, 한층 더 추진할 가치가 있다고 생각되는 경우는, 연락해 주세요.https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GeoData/+/816009 Jdlrobson (talk) 2022년 7월 21일 (UTC) 16:11
@Sdkb, 이 점 감사합니다.보호 아이콘에 대해서는 동의합니다.앞으로 나아갈 길이 분명해 보입니다.제목 바로 뒤에 좋은/특징 기사 아이콘을 배치하는 것에 대해: 우선, 나는 그것이 그것들을 더 두드러지게 한다는 것에 동의합니다.저에게 가장 중요한 질문은 사람들이 이 아이콘들을 어떻게 해석하는지 알아내기 위해 우리가 어떤 종류의 조사와 테스트를 할 수 있는가 하는 것입니다.나는 그들이 사람들이 글의 질을 이해하는데 도움을 줄 수 있는 많은 잠재력을 가지고 있다고 생각하는데, 이것은 읽기 경험에 도움이 될 수 있다.그러나 Wiki 전반에 걸쳐 표준화가 이루어지지 않고 페이지의 다른 아이콘(예를 들어 Watchstar 대 특집 기사 스타)과 혼동될 수 있습니다.이것에 의해, 유저 익스피리언스에 대해 한층 더 알고 싶다고 생각하고 있습니다.흥미롭게도 몇 년 전 카네기 멜론의 HCI 부서와 제휴하여 관련 연구를 진행했습니다.여기서 보실 수 있습니다.https://drive.google.com/file/d/1UCdW37reywLLc4r50pJHSQl3JfYxRHLU/view?usp=sharing
요약하자면, 저는 사람들이 적절한 위치를 찾을 수 있는 좋은/특징 기사 아이콘을 어떻게 이해하는지에 대한 더 많은 정보를 얻는다는 목표를 지지합니다.이 연구는 또한 아이콘 자체의 디자인에 대한 유용한 통찰력을 제공할 수 있습니다.AHollender (WMF) (대화) 2022년 7월 28일 (UTC) 16:02
@AHollender(WMF)님, 참여해 주셔서 감사합니다!CMU 기사를 대충 훑어봤더니 꽤 흥미롭네요. 비록 CMU가 구상하는 평가 툴이 기술적으로 매우 진보된 것처럼 들리긴 하지만요.저는 조사/시험 계획 작성에 전문가가 아니지만, 제 생각은 이렇습니다.
전반적으로, 우리의 목표는 독자들이 자신이 읽은 콘텐츠가 얼마나 신뢰할 수 있는지 빠르고 쉽게 판단할 수 있도록 돕고, 독자들이 그것을 어떻게 가장 잘 활용할지를 결정할 수 있도록 돕는 것입니다.이를 위해 디자인 차원에서 이 결정에 도움이 되는 요소를 강조하여 독자들이 주의를 기울이도록 유도하고자 합니다.
첫 번째 단계는 그 요소들이 무엇인지 알아내는 것입니다.이에 답하기 위해서는 위키피디아 정보의 신뢰성을 판단하기 위한 전문가들로 구성된 포커스 그룹을 소집하여 신속하게 평가할 수 있는 기사를 제공해야 합니다.숙련된 위키피디아인, 사서 또는 기타 연구자, 정보학자들이 모두 적절한 의견을 제공할 수 있습니다.어떤 의미에서는 이미 Wikipedians의 포커스 그룹이 있습니다.GA/FA 스타는 한눈에 기사를 판단할 때 매우 중요한 지표라고 말할 수 있습니다(다른 요소로는 Cite Unsee와 같은 툴에 의한 유지보수 태그의 존재, 레퍼런스, 토크 페이지 액티비티 등이 있습니다).
다음으로, 당신은 평균적인 독자로 구성된 포커스 그룹을 소집하고 그들에게 같은 과제를 주고 싶을 것이다.같은 인자를 사용하는지 다른 인자를 사용하는지 확인합니다.전문가들이 중요하다고 생각한 GA/FA 아이콘을 완전히 무시한 경우, 당신은 그것들을 더욱 두드러지게 할 필요성을 테스트함으로써 확인했습니다.
마지막 단계는 그렇게 하는 가장 좋은 방법을 찾는 것입니다.덴마크어 위키피디아는 문서 제목 뒤에 이미 GA/FA 아이콘이 있으므로, 여기에서 설문조사 데이터를 수집할 수 있습니다.독자 포커스 그룹이 아이콘을 검토하도록 요구받으면, 독자들도 생각을 가지고 있을 것입니다.현재 아이콘의 디자인이 잘 이해하는데 방해가 될 수 있다는 당신의 의견에 동의합니다.
그 모든 것이 당신의 질문에 대답하는 데 도움이 됩니까?건배 {{u Sdkb}}talk 2022년 7월 29일 05:13 (UTC)
@Sdkb - 실제로 지난 1주일 동안 내부에서 나눈 대화입니다:) "읽는 콘텐츠가 얼마나 신뢰할 수 있는지 독자가 빠르고 쉽게 판단할 수 있도록 도와드립니다."라는 목표에 대해 100%가 동의합니다.그렇게 하면 독자는 그것을 가장 잘 활용할 수 있는 방법을 결정할 수 있습니다.조금 다른 관점에서 접근하려고 생각하고 있었습니다.기사의 편집 횟수, 토크 페이지의 코멘트 수 등, 추천자가 추천하는 CMU의 연구 방식보다 품질에 관한 일반적인 판단을 할 수 있는 메타데이터를 기사에 제공하는 것입니다.on은 이미 제공되고 있습니다.여기서의 논거는, 독자가 읽고 있는 컨텐츠에 대해 보다 비판적으로 생각할 수 있을 뿐만 아니라, Wiki가 과거에 비해 보다 미묘하고 응집력 있는 방법으로 작업하는 방법을 소개하고, 그 중 많은 독자가 잠재적으로 공헌에 관심을 가질 수 있다는 것입니다.또, 컨텐츠가 적극적으로 개발되고 있는 소규모의 Wiki에서는, 이 어프로치가, Wiki의 컨텐츠에 근거해 기대치를 조정하는 것이 좋다고 생각합니다.
새로운 프로젝트에 집중하기 전에 먼저 Vector(2022) 도입을 완료하고 싶다고 생각하고, 아직 계획의 초기 단계에 있습니다.그러나 실제로는 신뢰 요소를 먼저 특정하기 위해 연구팀과 함께 몇 가지 조사 개요를 작성하기 시작했습니다.우리의 접근방식은 문헌 리뷰에서 시작해 독자 및 신규 편집자에게 직접 테스트를 시작하는 것이었습니다.즉, 메타데이터의 다른 신호/부분을 보여 주고, 컨텐츠 자체에 대한 신뢰와 사이트 전체에 대한 신뢰에 영향을 주는 방법을 검토하는 것이었습니다.다만, 우선, 일종의 인터뷰 라운드를 실시하는 것을 추천합니다.전문가로부터 신뢰에 영향을 줄 수 있는 잠재적인 신호의 예를 수집합니다.이 프로젝트에 대한 자세한 정보를 곧 wiki에서 얻을 수 있으면 좋겠다고 생각하고 있습니다.그게 뜨면 꼭 의견이나 피드백을 받을 수고를 해 주세요.OVasileva (WMF) (대화) 2022년 8월 2일 (UTC) 11:55
이것은 진행 중이지만, 매우 오랜 관습이 적용되어야 할 때는 어렵습니다.모든 종류의 해크와 오버라이드가 준비되어 있으며 좌표 ID를 조작하기 시작하면 영향을 받는 템플릿의 여러 종류가 있습니다(모듈:좌표는 가장 두드러지고 가장 눈에 띄는 사용자입니다.) 그리고 우리는 한 사람뿐만 아니라 모든 스킨을 고려해야 합니다.그 때문에, 모두가 물건의 파손을 두려워하기 때문에, 해결책의 실시에 있어서의 진척이 정체됩니다.
마지막으로, 가장 중요한 것은, 이것을 지표로 한다고 해도, 옵션의 위치나 레이아웃이 사람들에게 있어서 의미가 있는 것은 아니라는 것입니다.이것은 지금까지 팀에 의해 쉽게 무시되어 새로운 디자인의 제작을 커뮤니티에 위임되어 왔지만, 낡은 디자인과 포지셔닝은 매우 오래된 관습으로 사람들의 관습에 깊이 자리 잡고 있다.이런 상황에서 사람들에게 새로운 배치를 설득하는 것은 어렵다.: The DJ (토크기여)9:38, 2022년 7월 21일 (UTC)
"레이아웃" 문제는 정말 다뤄야 할 문제입니다.SGrabarczuk(WMF) 및 아마도 @OVASileva(WMF): - 이 판독 레이아웃의 어느 정도가 중앙에서 하드 드라이브 될 것인가, 그리고 커뮤니티의 경우 얼마인가?테크놀로지의 변경은 이미 진행되고 있는 것 같습니다만, 페이지 메타 컨텐츠의 프레젠테이션에 관한 UX/UI 레이아웃은 아직 안정적이지 않습니다.mediawiki 소프트웨어측의 강경한 견해는, 정상적으로 동작하고 있는 것 같습니다만, 망가뜨리고 싶지 않으면 페이지에 게재하지 말아 주세요.하지만, 편집자는, 이러한 컨텐츠가 독자들에게 좋은 평가를 받고 있는 것을 알았습니다.- xaosfluxTalk 14:05, 2022년 7월 21일 (UTC)
@Xaosflux, 마지막 문장을 잘 모르겠다.다른 말로 해주시겠어요?SGrabarczuk (WMF) (대화) 2022년 7월 21일 (UTC) 14:31)
@SGrabarczuk(WMF)는, 페이지, 특히 백과사전 기사에서 볼 수 있는 종래의 「콘텐츠」에 가세해, 편집(보호 상태)에 제한을 적용했을 경우, 페이지를 품질 페이지(FA, GA 등)로 간주하는 경우 등, 메타데이터 컨텐츠에 대해 독자나 편집자에게 알리는 것이 편리하다고 생각되고 있습니다.가장 일반적인 레이아웃(모노북, 그 다음 벡터).mediawiki 소프트웨어에는 이 메타 콘텐츠 표시용 디자인 섹션이 없었기 때문에 콘텐츠 영역 위에 배치하기로 했습니다.새로운 벡터 2022에서는, 이것을 사용하는 장소가 새로운 UI 요소(언어 셀렉터)와 함께 사용되고 있습니다.이에 대한 "로컬" 회피책을 마련하기 전에, 미디어위키를 사용하는 프로젝트에 대해 일반적으로 이러한 지표/메타 콘텐츠를 표시하는 방법에 대한 읽기 팀이나 새로운 스킨 팀의 디자인 작업이 있는지, 그리고 만약 그렇다면 현재 선택은 얼마나 확고한지 물어봅니다. - xaosfluxTalk 14:44, 2022년 7월 21일(UTC)
p.s. '좌표'와 같은 것은 기사의 주제에 대한 실제적인 사실 정보이기 때문에 나는 실제로 '메타 콘텐츠'로 보지 않는다.- xaosflux 14:45, 2022년 7월 21일 (UTC)
그래, 그래 내가 직접 몇 권을 썼으니 근본적인 문제는 잘 알겠어그러나 좌표 표시 태그를 사용하는 것은 로컬이 아니므로 회피책도 되지 않습니다.미디어위키 규격의 응용 프로그램입니다.말씀하신 설계 작업에 대해서는 검토했습니다만, 이는 Desktop Envelopments 1.0을 넘어서는 것이므로, 그 방법을 추구하지 않았습니다.SGrabarczuk (WMF) (대화) 2022년 7월 21일 (UTC) 14:56
@SGrabarczuk(WMF) 감사합니다.vector-2022용으로 갱신된 "인디케이터" 설계 레이아웃/문서 페이지를 알려주실 수 있습니까? (mw:도움말: 페이지 상태 표시기가 가장 최신입니까?)이 페이지에는 벡터 2022 업데이트가 없지만 "메인 콘텐츠 외" 디자인 가이드를 사용합니다.- xaosfluxTalk 15:03, 2022년 7월 21일 (UTC)
이 스레드는 "좌표"에 대해 질문하는 것으로 시작되었지만, 우리의 설계 충돌은 현재 메타 지표가 벡터 2022의 컨텐츠 영역 내에 있기 때문에, 그것들을 이동하는 것이 더 우선이라고 생각합니다.- xaosflux 15:07, 2022년 7월 21일 (UTC)
하지만 현재의 디자인과는 다른 변화입니다.당신은 우리에게 변화를 강요하고 나서 "어떻게 해야 할지에 대해 생각하지 않았다. 당신이 알아내야 한다"고 말한다.갑자기 템플릿 에디터가 수정자, 디자이너, 그리고 ppl이 마음에 들지 않기 때문에 외칠 수 있는 벽이 됩니다.그것이 왜 나와 다른 사람들에게 '위키피디아 편집으로 긴장을 풀자' 저녁이 되지 않는지 알 수 있습니까?-DJ (talk & contributes) 2022년 7월 21일 (UTC) 15:03
@SGrabarczuk (WMF) / @Jdlrobson - 제안대로 "인디케이터"를 사용하는 것에 대한 후속 질문. 벡터 2022의 오른쪽 상단 아이콘과 testwiki의 벡터-2022의 아이콘을 비교합니다.이 아이콘은 mw에 기재되어 있지 않습니다.도움말: 페이지 상태 표시기.'콘텐츠 영역 밖' 표시기 섹션이 아직 있습니까?- xaosfluxTalk 12:28, 2022년 7월 22일 (UTC)
아직 콘텐츠 영역 밖에 있는 것으로 간주하고 있습니다.「Wikitext 페이지에 텍스트를 쓰는 것만으로, 통상은 그 텍스트가 끝날 수 있는 위치가 아닙니다.」와 같이:DJ(talk & contributes) 2022년 7월 28일(UTC) 20:24
@DJ님, "모든 종류의 해킹과 오버라이드가 있고 영향을 받는 템플릿의 여러 종류가 있습니다."라고 쓰셨습니다.이 모든 것이 인디케이터 태그가 사용되었을 때 사실일까요?예를 들어 주시겠습니까?SGrabarczuk (WMF) (대화) 2022년 7월 21일 (UTC) 14:43)
템플릿:Sky는 최근까지 좌표 ID를 재사용했지만 모듈:접속되어 있는 KML은 대응하고 있습니다(아마도 몇 개 더 있을 겁니다.이것들 또한 다루어져야 합니다.다음으로 템플릿이 있습니다.좌표 자체. 출력은 다른 모듈에 의해 읽힙니다(이것은 악명 높은 코디네이트 해킹입니다).그리고 모든 스킨은 포지셔닝이 다르므로 전후 상황에 대응할 수 있는 CSS를 배치해야 합니다.이 모든 작업에는 몇 시간의 작업, 리뷰, 테스트 및 느린 이동이 필요합니다.그리고 만약 여러분이 이 일을 할 수 있는 몇 시간을 찾을 수 있다고 해도, 가장 재미있는 일은 아니며, 일단 여러분이 일을 마치면, 여러분은 그 결과에 대처해야 할 수도 있습니다.: The DJ (토크기여) 2022년 7월 21일 (UTC) 14:59
Special 인스턴스를 삭제했습니다.어젯밤 검색 결과(쿼리, 삭제는 EDT 19:56, UTC 23:56?)Attached KML과 Sky를 제외하고 어느 누구도 #좌표를 사용하지 않아야 합니다.
그렇지 않으면, 특히 ULS의 이동에 관한 연구가 그럴듯할 때, 나는 이곳에서의 그의 논평에서 TheDJ의 의견에 전적으로 동의한다."폴드 위로 무언가를 옮겼는데, 주목도가 높아질까요?"아이디케이, 안 그래?질문에는 "이 공간에 무엇이 살고 있고, 그것이 주의를 감소시킬 것인가?"라는 내용이 포함되어야 한다.이즈노 (대화) 2022년 7월 21일 (UTC) 15:21
말씀하신 설계 작업에 대해서는 검토했습니다만, 이는 Desktop Envelopments 1.0을 넘어서는 것이므로, 그 방법을 추구하지 않았습니다.@SGrabarczuk(WMF)VPR에서의 코멘트에서 인용하겠습니다.이것에 대해, 언젠가 회답할 생각이 있는 것을 알고 있습니다.「그것은 이해할 수 없습니다.그들을 밀어내는 것은 고려하지만, 어디에 밀어넣을지는 개의치 않는 것입니까?」{U Sdkb} 15:46, 2022 (C)
좌표와 페이지 인디케이터의 배치에 대해서: 델은 가이던스를 제공할 수 있는 설계 사양을 작성했습니다(결국 프로젝트 전체의 일관성이 확보됩니다).
톱 페이지 디자인 사양 (Media Wiki 페이지)
설계 사양을 따를 경우 좌표 및 페이지 표시기의 예를 4개 나타냅니다.
과거 한 가지 문제가 제기되었던 것은 Wiki의 공백이 Wikipedia에서...를 표시하지 않는다는 것입니다.태그 라인처음에는 이 경우 좌표와 지표를 이동시켜 공간을 채우는 것이 타당하다고 생각했습니다.그러나 여러 Wiki에 걸쳐 이러한 요소를 일관되게 배치하는 것이 우선 순위를 정하는 데 더 중요하다고 생각합니다.(이러한 Wiki들 중 일부는 그 영역의 균형을 맞추기 위해 태그라인을 켜기로 결정할지 의문입니다.)
이 디자인 사양이 Vector 2022에서 보다 체계적이고 일관된 톱 페이지 체험으로 나아가는 데 도움이 되기를 바랍니다.당신의 생각을 알려주세요.고마워요.AHollender (WMF) (대화) 2022년 7월 27일 (UTC) 21:21
phab 티켓에 기재되어 있듯이, 「좌표」는 「메타 데이터」가 아니고, 「페이지에 관한 정보」가 아니고, 그 주제에 관한 유저가 작성한 컨텐츠입니다.이"좌표"또한은 소프트웨어 설계에서 부르는 것은 이상 있는 일이 생기면, 어떤 프로젝트 내용의 다른 종류의-아마도 사전"기원의 원천"의 일종은 아마도 마법의 모임 위키가"mana 색"을 갖기를 원할 것 등— xaosfluxTalk 22:16 7월 27일 2를 원할 것을 미칠 수 있다.022 (UTC)
또한 phab 태스크에서 이 점을 언급했지만, 일부 사용자가 읽지 않는 경우를 위해 여기에 추가하겠습니다.좌표와 지표가 다른 내용과 겹치는 문제를 해결하기 위한 이 태스크의 첫 번째 논의에서 "좌표를 메타데이터로 간주해야 하며, 그렇지 않으면 어디에 표시해야 하는가?"라는 다소 새로운 논의를 분리하는 것이 좋다고 생각합니다.좌표를 두 번 이동하면 우습게 보일 수 있지만, 우선 페이지 제목 막대의 밑줄 바로 아래에 있는 좌표를 페이지 툴바(약 10px 이동)로 이동한 후 더 이동할 가치가 있다고 생각되면 별도의 논의를 시작하는 것이 간단해질 수 있다고 생각합니다.
(두 번째 논의에 대한 메모를 추가함으로써 제 자신과 너무 모순되지 않기를 바랍니다.이것도 다른 태스크에서 일어날 수 있다고 생각합니다.최소한 대부분의 경우 좌표는 중복되어 있다는 것을 명심해야 합니다.이러한 항목은 문서의 맨 위 및 정보 상자 안에 표시됩니다.어디에 배치할지에 대한 논의를 잘 하기 위해서는 먼저 두 개의 다른 좌표 링크에 대한 클릭에 관한 데이터를 수집해야 한다고 생각합니다).AHollender (WMF) (대화) 2022년 7월 29일 (UTC) 15:07
@AHollender(WMF)의 긴 토론으로 인해 기사에 인포박스를 포함하거나 제외하는 것은 선택사항이라는 현재의 가이드라인이 생겼습니다.예를 들어, 여기 인포박스가 있는 페이지는 1방콕입니다.이 논의는 현재도 여러 개의 온/오프 위키 페이지에 걸쳐 매우 단편화되어 있다고 생각합니다.- xaosflux 15:17, 2022년 7월 29일 (UTC)
  • 우리는 좋은 첫 대화를 많이 나눴지만, 우리의 커뮤니티에 "우리 기사의 어디에 이 정보를 독자들에게 보여주고 싶은가?"라는 주요 질문을 던질 필요가 있다.의사결정을 위한 기술적 목업을 할 수 있는 것은 유용할 수 있다.- xaosfluxTalk 20:06, 2022년 7월 28일 (UTC)
    +1 이 항목과 바로 위의 메타데이터 코멘트.{{u Sdkb}} 2022년 7월 29일 05:25 (UTC)

Module_talk에서 이 토픽의 진척을 위해 기술 블로커목록 업데이트에 대해 자세히 설명합니다.좌표#Outstanding_problems_for_indicators : The DJ (talkcontributes )2022년 7월 28일 (UTC) 20:21

템플릿 문서 헤더

자, 여러분, 저는 또 난처합니다. 이번이 처음도 아니고 마지막도 아닐 것입니다.최근 변경으로 {{Document subpage}}의 적용은 템플릿 /doc 페이지뿐만 아니라 해당 페이지로 리다이렉트되는 모든 페이지로 자동화된 것 같습니다.를 들어 Module 입니다.Infobox3cols/doc. 연관된 템플릿 /doc 페이지를 대상으로 합니다.문서 헤더는 리다이렉트되지 않고 실제 템플릿 문서 페이지에만 표시되어야 한다고 생각합니다."/doc"라는 이름의 모든 하위 페이지에 문서 헤더를 배치하면 "문서 하위 페이지" 템플리트의 잘못된 변환 번호가 나타납니다.템플릿을 넘나드는 인터페이스 페이지는 MediaWiki:스크리번투닥 페이지헤더, 하지만 그건 잘 모르겠어요.저보다 훨씬 더 잘 아는 기술자가 모든 /doc 페이지 리다이렉트에서 문서 헤더를 삭제하는 방법을 생각해 낼 수 있는지 궁금해서요.P.I. Ellsworth, ed. 12:12, 2022년 7월 21일 (UTC)

생각할 수 있는 유일한 것은 페이지를 리다이렉트 할 수 있는지 확인하기 위해 모듈을 사용하는 것입니다.모듈:리다이렉트는 동작합니다(리다이렉트는isRedirect기능)을 클릭합니다.그런 다음 MediaWiki 페이지에 테스트를 실행하여 페이지가 리다이렉트인지 여부를 확인하고 리다이렉트된 경우 헤더를 숨길 수 있습니다. --ais523 12:55, 2022년 7월 21일 (UTC)
고마워요! 저도 그렇게 생각했어요.토크 페이지에 편집 요청을 넣기 전에 정확한 MW 페이지가 있는지 확인하고 싶습니다.저는 모듈에 대해서는 그다지 강하지 않기 때문에 모듈 추가에 도움이 필요합니다.isRedirect 인터페이스 페이지로 이동합니다.P.I. Ellsworth, put'r thereed.13:07, 2022년 7월 21일 (UTC)

토크 페이지의 리다이렉트

여기 자동 생성된 텍스트가 있는 다른 텍스트가 있습니다. 이번에는 편집자에게 샌드박스 페이지에 대해 설명하도록 요청합니다.물론 리다이렉트는 논의의 장도 아니고, 토크 페이지의 리다이렉트도 아닙니다.특정 페이지의 사용을 배제하기 위해 테스트하고 있다고는 생각하지 않습니다.그들은 그저 "희망적으로" 적용되고 있을 뿐이다.이것으로 식별할 수 있습니다만, 리다이렉트상의 이러한 메시지는 소거할 필요가 있습니다.P.I. Ellsworth, ed. 19:45, 2022년 7월 21일(UTC)

@Paine Elsworth: 저는 {{redirect other}}를 만들었습니다(MediaWiki:-space에서 동작한다고 가정합니다만, MediaWiki:-space는 때때로 이상합니다).(사이트 인터페이스의 일부로 사용하려면 템플릿을 완전히 보호해야 합니다). --ais523 23:14, 2022년 7월 21일(UTC)

MediaWiki 네임스페이스의 어느 페이지가 Doc 서브페이지와 해당 토크페이지 템플릿을 적용하는지 비교적 확실하게 아는 사람이 있습니까?리다이렉트에서 템플릿을 삭제하기 위해 편집 요청을 하고 싶습니다.P.I. Ellsworth, ed. 14:24, 2022년 7월 26일 (UTC)

@Paine Elsworth MediaWiki:Scribunto-doc 페이지 헤더 및 MediaWiki:Watchlist-messages는 무조건 사용하는 유일한 페이지인 것 같습니다(MediaWiki:space, MediaWiki 토크스페이스에 문서 서브페이지가 있는 템플릿이기 때문에 Watchlist-messages는 직접 페이지를 볼 때만 표시되지 않습니다).조건부로 사용할 수 있는 검색 기능을 구축하려고 했지만 아직 사용할 수 있는 검색 기능을 찾지 못했습니다.MediaWiki에 대한 편집 요청을 하는 것이 좋습니다.먼저 Scribunto-doc-page-header를 작성한 후 다른 곳에 문제가 있는지 확인할 수 있습니다. --ais523 12:04, 2022년 7월 30일(UTC)
감사합니다, ais523 편집장님!MediaWiki 토크에서 편집 요청이 열렸습니다.Scribunto-doc-page-header. {{Redirect other}} 템플릿 사용을 제안합니다.MediaWiki 네임스페이스에서 토론 시작 초대를 토크 페이지 리다이렉트에 잘못 적용한 페이지를 찾을 수 없습니다.이를 수정하려면 버그 보고서가 필요할 수 있습니다.P.I. Ellsworth, ed. 20:14, 2022년 7월 30일 (UTC)

문서 하위 페이지 템플릿을 제거하는 문제가 이 편집으로 해결되었습니다.여기서같은 모든 토크 페이지 리다이렉트에 있는 토론 초대장 자동 발송에 관한 도움말과 가이던스를 찾고 있습니다.MediaWiki 네임스페이스에 유사한 페이지가 있는지, 완전히 보호된 편집 요청을 할 수 있는지, 아니면 개발자가 직접 수정해야 하는 것인지 알 수 없습니다. P.I. Ellsworth, ed. 22:57, 2022년 7월 30일 (UTC)

T270323과 같은 유사한 내용을 설명하는 여러 Phab 페이지가 있는 것 같기 때문에 수정은 개발자에게 달려 있는 것 같습니다.특히 토크 페이지 리다이렉트에는 편집자가 직접 리다이렉트 토크 페이지에서 토론을 시작하도록 제안하는 새로운 토크 페이지 도구가 필요하지 않습니다.P.I. Ellsworth, ed. 23:25, 2022년 7월 30일(UTC)

다음으로 리다이렉트 미작성 토크페이지의 를 나타냅니다. 페이지에 토크 페이지를 작성하기 위한 초대가 표시됩니다.새로운 편집자가 거의 아무도 읽지 않는 토크 페이지와 토론을 만들도록 자극하고 싶지 않기 때문에 이 공지사항도 삭제해야 합니다.이 새로운 토론은 대상 페이지의 리다이렉트 대상 토크 페이지에서 열어야 한다.P.I. Ellsworth, ed. 16:29, 2022년 7월 31일(UTC)

파브에서 세 번째 환자가 발견됐어요Talk에서와 같이 리다이렉트가 이미 생성되어 그 자체가 리다이렉트가 아닌 경우입니다.지우기(노래).그 페이지는 AfD로 이동해, 이 편집으로 봇 태그가 붙여졌습니다.또, 이러한 현상은 빈번하게 발생합니다.또, 토크 페이지에는, 제목 페이지의 리다이렉트에 관한 논의를 개시하는 초대도 있습니다.저는 Phab에서 초대장을 해당 페이지에서도 삭제해야 한다고 제안했습니다. 왜냐하면 우리는 새로운 편집자들이 이러한 페이지가 응답을 보장할 수 있을 정도로 충분히 감시되고 있다고 생각하지 않기 때문입니다.P.I. Ellsworth, ed. 02:21, 2022년 8월 1일(UTC)

제안: CS1 유지보수 메시지 표시 자동화

페이지를 편집하고 있는데 미리보기 표시 버튼을 클릭하면 경고 텍스트가 표시됩니다.

스크립트 경고:하나 이상의 {{cite web} 템플릿에 유지보수 메시지가 있습니다.메시지가 숨겨져 있을 수 있습니다(도움말).스크립트 경고:하나 이상의 {{cite news} 템플릿에 유지보수 메시지가 있습니다.메시지가 숨겨져 있을 수 있습니다(도움말). 

'도움말' 링크는 다음과 같습니다.CS1 errors © Controlling error message ,,,,메시지 표시.사용자에게 "공통 CSS 페이지 또는 특정 스킨의 CSS 페이지(각각 common.css 및 skin.css)"에 코드를 포함하도록 지시합니다.

이 작업을 수행할 수 있었지만 페이지를 삭제하기 전에 유지 보수 메시지를 볼 수 없었습니다. 이 작업에는 다른 간단한 단계가 필요했습니다.

이 절차는 일반 편집자에게 너무 복잡하므로 자동화해야 한다고 제안합니다.

페이지를 미리 볼 때 유지 보수 메시지에 대한 경고가 표시되면 유지 보수 메시지를 표시하거나 표시하지 않는 간단한 버튼 또는 슬라이더가 있을 수 있습니다.버튼을 클릭하거나 슬라이더를 슬라이드하는 것도 사용자가 당황하지 않도록 하기 위한 퍼지 스텝을 포함할 수 있습니다.

템플릿의 토크 페이지에서 이것에 대해 논의를 개시해, 거기서부터 현재의 섹션까지 링크했습니다.저는 이 제안에 대한 논의를 토크 페이지가 아닌 여기서 계속할 것을 제안합니다.

이 토크 페이지에서 사용자 Trappist the monk는 내 제안에 다음과 같이 답했습니다. "인터페이스 편집 권한을 가진 사용자 또는 소수의 편집자만이 .css 페이지를 편집할 수 있기 때문에 절차를 자동화할 수 없습니다.알아냈나 보네수행해야 할 작업을 설명하는 더 나은 방법이 생각나는 경우 현재 설명을 편집하여 개선하십시오."

대부분의 경우 다른 사용자가 내 .css 페이지를 편집하는 것은 불가능할 수 있지만, 이는 내가 제안하는 절차가 사용자의 CSS에 의존하지 않아야 한다는 것을 의미합니다.기본 시스템을 코딩하는 방법에 대해서는 잘 모르지만, 유지보수 메시지를 표시할지 표시할지 여부를 전환하는 것은 어렵지 않습니다.Teemu Leisti (토크) 2022년 7월 27일 (UTC) 15:28

제안하신 내용은 사용자 개발 모듈 단일 그룹의 범위를 훨씬 벗어난 것 같습니다.
이것이 일반 편집자에게 너무 복잡한 것은 사실이다.이는 평균 이상의 편집을 수반하기 때문입니다.50.75.226.250 (토크) 16:09, 2022년 7월 27일 (UTC)
그것은 사실 단순화될 수 없는 것이다.제공되는 방법만큼 복잡한 대안들이 있고, 그러한 방법들은 관심 시스템의 유지자들에게 더 복잡하기 때문에, 이것이 권장되는 방법입니다.이즈노 (대화) 2022년 7월 27일 (UTC) 16:20
무엇이 "자동화"될 수 있는지 확실하지 않지만 기타 추가 오류 메시지(예: User:기술적으로 권한이 낮은 편집자(CSS를 읽는 것보다 라틴어를 읽는 것이 더 쉽다고 생각함)가젯을 사용하여 monk/HarvErrors.js를 통해 Trappist를 활성화할 수 있습니다.Enterprisey/script-installer.기본 CSS 방식을 변경하지 않고 이를 쉽게 할 수 있는 사용자 스크립트를 작성할 수 있습니까?: Kusma (토크) 2022년 7월 27일 (UTC) 16:28
숨겨진 유지보수 메시지 표시(도움말) 가젯은 어떻습니까?도움말 링크는 표시되는 메시지 유형을 나열하는 페이지로 이동합니다(예: Wikipedia:#문서 유지보수 시점) 및 가젯 대신 사용자 CSS를 사용하여 개별적으로 제어하는 방법.여기서 논의된 CS1 메시지만을 위한 가젯을 만들어야 한다고 생각하지 않습니다.다양한 유형의 메시지를 위한 여러 가젯이 뒤죽박죽이 됩니다.스페셜:Preferences #mw-prefsection-gadgets에서 가젯 수를 제한합니다.기존 메시지를 숨기는 대신 메시지를 추가하는 스크립트는 제안된 가젯에서 다루지 않습니다.PrimeHunter (토크) 2022년 7월 27일 (UTC) 16:45
A.withCSS링크(및 CSS를 포함한 Mediawiki css 페이지)가 기능하는 경우가 있습니다.- Qwerfjkltalk 2022년 7월 27일 19:47 (UTC)
미리보기에서 WithCSS를 사용할 수 있을지는 모르겠지만 적어도 저장된 버전의 페이지 링크에서 작동해야 합니다.PrimeHunter (대화) 2022년 7월 27일 23:15 (UTC)

좋아요, 제 제안에 대한 열의가 별로 없는 것 같네요. 그리고 어쨌든 그렇게 중요한 것도 아니네요.그러니까 신경 쓰지 마세요.Teemu Leisti (토크) 2022년 7월 31일 (UTC) 00:12

템플릿 표시 글리치

{{unblock-spamun}} 템플릿 표시 방법에 약간의 오류가 있는 것 같습니다.사용자가 이 템플릿을 사용하여 차단 해제를 요청했지만 들여쓰기(콜론)가 선행된 경우가 몇 번 있습니다.이렇게 하면 일반적으로 텍스트를 둘러싼 테두리 및 배경색이 대신 텍스트 위에 얇은 한 줄 상자로 나타납니다(샘플 차이).들여쓰기 부분을 제거하면 디스플레이 문제가 해결됩니다(샘플 diff).그렇지 않으면 템플릿은 정상적으로 기능하며 블록 해제 요구는 CAT에 정상적으로 표시됩니다.UNB. 이 문제의 영향을 받는 다른 템플릿이 있는지 알 수 없습니다. --Drm310 🍁 (대화) 2022년 7월 27일 (UTC)

이 문제를 해결할 유일한 방법은 결장을 제거하는 것입니다.이즈노 (대화) 2022년 7월 27일 (UTC) 16:22
들여쓰기를 하면 다수의 상자형 템플릿이 깨집니다.일반적으로 텍스트의 일부(또는 전부)가 상자 밖으로 배출됩니다.가장 쉬운 수정은 들여쓰기를 하지 않는 것입니다. --Redrose64 🌹 (대화) 2022년 7월 27일 (UTC)
Wikitext 소스 모드에서 [reply] 도구를 사용하는 사람이 몇 명인지 궁금하네요.(이 문제를 피하기 위해 비주얼 모드에서는 템플릿이 비활성화되어 있습니다).Whatamidoing (WMF) (대화) 2022년 8월 1일 (UTC) 23:28

계속 로그아웃을 합니다.

최근 30분 정도 사이에 인터페이스가 이상한 동작을 시작하고 있습니다.로그인하여 편집을 시작합니다.미리 보거나 저장하려고 하면 로그인하지 않았다고 표시됩니다.로그인하려고 하면 페이지가 저장되지만 변경 내용은 저장되지 않고 로그인했다고 표시됩니다.그러면 사이클이 반복되고 편집하려고 하면 다시 로그인하지 않는다고 표시됩니다.여러분, 이제 집에 갑니다.소스 에디터를 사용하고 있습니다.MaryMO (AR) (대화) 2022년 7월 28일 (UTC) 00:03

@MaryMO(AR): 이 문제를 해결하기 위한 포럼 포럼인 VPT로 옮겼습니다.- xaosfluxTalk 00:34, 2022년 7월 28일 (UTC)
@MaryMO(AR), 부정한 쿠키로 인해 로그인 문제가 발생할 수 있습니다.그래도 문제가 있는 경우 WP를 사용해 보십시오.BYPASS; 그래도 작동하지 않으면 다음으로 mw:safemode를 시도합니다.어떻게 됐는지 알려주세요.Whatamidoing (WMF) (대화) 2022년 8월 1일 (UTC) 23:29

사용자: Restorer.js

안녕하세요. Bnwiki를 제외한 모든 Wiki에 User:Jarkur/Restorer.js를 설치합니다.global.js에서 사용하는 코드는 무엇입니까?--Abdullah☆(대화) 2022년 7월 28일(UTC) 09:40

@MdaNoman 참조:도움말: 내선번호:GlobalCssJs#To_exclude_a_wiki.- xaosflux 13:45, 2022년 7월 28일 (UTC)

부적절한 이름의 링크가 대상인 이미지

여기서 편집 요약을 본 파일:General-Shigenori-Kuroda.png; 파일:M98 열대 유니폼을 입은 일본 소령.png.Wtmitchell (대화)(이전 보라카이 법안) 2022년 7월 28일 (UTC) 11:49

무슨 질문이신지 모르겠네요.파일이 Commons로 이동되어 리다이렉트를 남겼습니다.Commons에 "(Redirected from File: 파일로부터 리다이렉트됨:General-Shigenori-Kuroda.png), enwiki에서는 리다이렉트 타깃이 표시되고 "Redirected from"이 표시되지 않으며 URL이 갱신되지 않습니다.6년 전 T127418을 찾았습니다. --rchard2scout (대화) 2022년 7월 28일 (UTC) 12:04

자동 인덱스 기능

안녕하세요, 헬프 데스크에서 이 질문을 하고 있습니다.위키피디아에는 주어진 최상위 범주의 모든 페이지를 A-Z 형식으로 보여주는 다수의 색인 페이지가 있습니다(: 사회학).다만, 제가 관심 있는 것은 수동으로 작성하기 때문에, 모든 페이지가 포함되도록 하기 위해서 많은 작업이 필요한 경우가 많습니다./새로운 페이지가 생성될 때 최신 상태를 유지하는 것은 어렵습니다.

특정 부모 카테고리에 따라 모든 페이지를 알파벳 순으로 페이지에 표시할 수 있는 Wikicode, 템플릿 또는 기타 기능을 알고 계신 분 계십니까?기본적으로 "Societology"에 있는 모든 페이지를 표시하기 위해 카테고리 트리 대신 해당 카테고리 A-Z에 중첩된 모든 개별 페이지를 표시합니다.

도움을 주셔서 감사드리며, 혹시 다른 곳에서 요청할 일이 있으면 알려주세요.이것이 실제로 새로운 종류의 기능 요청이라면, 이 기능을 작성하기 위한 최적의 방법을 알려주세요.Jamzze (토크) 2022년 7월 28일 (UTC) 14:01

@Jamze 특별합니다.카테고리트리가 효과가 있나요?- xaosfluxTalk 2022년 7월 28일 14:15 (UTC)
사용할 수 있는 방법이 많이 있는 경우 mw를 참조하십시오.내선번호:카테고리문서용 트리.- xaosfluxTalk 14:17, 2022년 7월 28일 (UTC)
공유해주셔서 감사합니다.제가 읽은 바로는, 이 함수는 페이지를 알파벳 순으로 표시하는 것이 아니라 카테고리를 통해 표시하는 것입니다(잘못 읽고 있는 경우가 아니면).만약 그렇다면, 이것은 지수에 적합하지 않을 것이다.Jamzze (토크) 2022년 7월 28일 (UTC) 14:57
카테고리 트리 출력 정렬은 10년 이상 된 태스크 phab에 포함되어 있습니다.T32753. 카테고리의 페이지는 카테고리 페이지 자체에 정렬됩니다(c.f. 카테고리:사회학).카테고리는 트리 계층이 아니라 거미줄 계층에 가깝고 루프, 포크, 데드엔드를 포함할 수 있다는 점을 기억하십시오.예를 들어, "Societology"의 "Index"에서 "Uniform Map"에 대한 기사를 원하십니까? 왜냐하면 카테고리 트리를 횡단하면 결국 거기에 도달하기 때문입니다.그렇다면 다음과 같은 확장 요청을 원하는 것처럼 들립니다.내선번호:카테고리트리와 당신은 mw에서 그것에 대해 묻기 시작할 수 있습니다.확장 토크:카테고리 트리- xaosfluxTalk 15:44, 2022년 7월 28일 (UTC)
{{categorytree}}의 출력을 Lua, Xaosflux로 리게이징할 수 없습니까? — Guarapanga 2022년 7월 29일 01:32 (UTC)
루아가 그걸 봤을 때, 그건 스트립 마커 안에 있어요.이즈노 (대화) 2022년 7월 29일 (UTC) 02:06
{{unstrip}}'d는 안 되나요?- 과라피랑가 2022년 7월 29일 (UTC) 03:32
Lua가 할 수 있는 유일한 것은 nowiki 마커이며, 이것이 {{unstrip}}의 기능입니다.노비키 스트립 마커는 스트립 마커의 한 종류일 뿐입니다.이즈노 (대화) 2022년 7월 29일 (UTC) 03:40
맞아! 알았어.고마워요.- 과라피랑가 2022년 7월 29일 (UTC) 03:42
@Xaosflux @Guarapiranga @Izno 의 모든 의견 감사합니다.이것들 중 일부는 제 지식을 훨씬 뛰어넘는 것이므로 Xaosflux가 제안하는 페이지에 링크하겠습니다!Jamzze (토크) 2022년 7월 30일 (UTC) 12:03
나는 그것이 2단계 과정이라고 생각한다.외부 목록은 펫스캔을 사용할 수 있습니다.결과를 정렬하려면 설정을 사용해야 합니다. 기본적으로는 그렇지 않습니다.이것이 자동화된다면 아마도 봇, pywikipediabot, AWB 모두 목록을 만들 수 있지만, 개봉 즉시 원하는 것을 하지 않기 때문에 약간의 코딩이 필요합니다.--Snévar (talk) 16:58, 2022 (UTC) 7월 28일 (UTC)
감사합니다! Jamzze (토크) 2022년 7월 30일 (UTC) 12:03

모바일 데스크톱 사용 중 검색 상자 및 기본 줌이 잘못됨

Wikipedia의 데스크톱 버전을 모바일로 사용할 때 이상한 일이 일어나고 있습니다.예를 들어, 위키피디아에서 새로운 페이지로 이동할 때, 위키피디아 로고/링크가 위치한 페이지의 왼쪽 상단에 페이지가 상당히 확대됩니다.또한 페이지 오른쪽 상단에 있는 검색 표시줄이 예전보다 상당히 작아졌습니다.이전 크기의 절반도 안 되는 것 같아요.여러 브라우저(Safari [I using a iPhone]및 Firefox)에서 이 문제가 발생하고 있음을 확인하고 브라우저의 캐시와 쿠키를 클리어한 후에도 문제가 해결되지 않았습니다.이 문제는 "Vector legacy (2010)" 또는 "Vector (2022)" 스킨을 사용할 때 발생합니다.Steel1943 (대화)20:32, 2022년 7월 28일 (UTC)

크롬도 그렇고.짜증나!Neiltonks (토크) 22:01, 2022년 7월 28일 (UTC)
나한테도 일어나고 있어.투고하러 왔는데 이게 벌써 와있더라고요.변경 사항을 되돌리십시오.: pythoncoder(토크컨트롤) 2022년 7월 28일 22:00 (UTC)
이것은 다른 모든 Wiki에서 이틀 동안 있었던 일이다.지금에야 엔위키도 할 수 있어처음 Commons에서 시작되었을 때 Commons에 글을 올렸습니다: c:Commons:빌리지 펌프/기술 번호이상한 관찰이군Jonteemil (대화) 22:54, 2022년 7월 28일 (UTC)
SVG 파일의 "Edit source" 버튼(: File:FK Mladost GAT logo.svg도 다른 문제가 발생한 것과 동시에 엉망이 되었습니다.@TheDJ: 1. 이것을 재현할 수 있습니까? 2. 이것도 phab 때문입니까?T31795?편집: "Vector legacy (2010)" 스킨을 사용해야만 재현할 수 있습니다.Jonteemil (대화) 2022년 7월 29일 (UTC) 19:59
이 문제를 해결하려면 파브레이터를 어떻게 해야 하는지 아는 사람?'해결 완료' 상태의 티켓에 코멘트를 붙이는 것은 효과가 없는 것 같습니다.Steel1943 (대화) 2022년 7월 30일 (UTC) 11:36
위 링크 티켓을 다시 열었습니다.제가 그렇게 할 수 있을지는 모르겠지만, 이 문제는 고쳐져야 합니다.: pythoncoder (talk contributes)20:39, 2022년 7월 31일(UTC)

Chrome 모바일 문제

지난 몇 시간 동안 모바일 장치에 Chrome을 사용하여 Wikipedia 페이지를 로드하면 해당 페이지가 화면보다 크게 표시됩니다.쉽게 축소할 수 있지만, 전에는 이렇게 할 필요가 없었습니다.설정을 변경하지 않은 것 같습니다.좋은 생각 있어요?331 도트 (토크) 00:28, 2022년 7월 29일 (UTC)

@331 도트:모바일에서 데스크톱을 사용하는 동안 #Search 박스와 기본 줌이 잘못되었습니까?Jonteemil (대화) 2022년 7월 29일 (UTC) 01:05
이게 phab의 부작용인 것 같아요.T31795phab 때문에 필요했습니다.T306910.: The DJ (토크기여)8:35, 2022년 7월 29일 (UTC)
Android의 MS Edge에서도 같은 문제가 발생했습니다.: CX[그/그 사람] 2022년 7월 29일 09:40 (UTC)

Twinkle에서 섹션 제목 오류 발생?

오늘 오후에 Twinkle 경고에 대한 문제가 보입니다.섹션 제목에 == 세트를 작성 및 복제하고 있으므로 "2022년 7월" 대신 "== 2022년 7월 =="로 표시됩니다.

다른 사람에게도 이런 일이 일어나고 있습니까?이것은 하나의 예이며, 다른 예는 시각적인 예가 필요한 경우에 테스트용으로 제 토크 페이지 하단에 남겨둔 것입니다.

여기서 Twinkle 문제를 보고하는 것이 적절하지 않은 경우, 보고/수정하는 방법 및 방법은 무엇입니까?감사합니다, Zinnober9 (토크) 2022년 7월 28일 (UTC) 20:34

WT에 보고되었습니다.Twinkle #Bug 보고서: 잘못된 형식의 헤더입니다.오늘은 목요일이니까 그것도 한 요인일 수 있어요. 맨다락스 XAB manAM 20:55, 2022년 7월 28일 (UTC)
아, 감사합니다! Zinnober9 (토크) 2022년 7월 28일 21:00 (UTC)

IPv6 anon과의 통신

Wikipedia 관련:모바일 통신의 버그, IPv6 유저와의 통신에도 큰 문제가 있습니다.나는 최근에 이것에 대한 집중적인 논의가 어디에서 이루어졌는지 잘 모르겠다.

IPv6 는 v4 와는 다른 동작을 하기 때문에, 그것을 잘 이해하는 사람은 많지 않습니다.기본 원칙 중 하나는 64비트 인터페이스 식별자입니다.실제로는, IPv6 주소가 할당되어 있는 모든 유저에게는, 64비트 분의 플레이 공간이 할당됩니다.따라서 첫 번째 64비트는 단일 고객을 식별하기 위해 매우 안정적인 상태를 유지할 수 있으며 마지막 64비트는 순식간에 변경될 수 있습니다.

따라서, 거의 모든 IPv6 유저도, 좋든 싫든, IP 호퍼입니다.모든 IPv6 사용자는 18,446,744,073,709,551,616개의 사용자 토크 페이지를 가질 수 있습니다.장기간에 걸쳐 편집하는 모든 IPv6 유저는, 지금까지 본 적이 없는 대량의 IP호핑 파괴 행위와 같이, 토크 페이지나 다양한 투고를 축적하게 됩니다.

결과적으로, IPv6 유저의 경고와 통신의 이력을 알 수 없게 됩니다.64/64의 투고 내용을 돌아보고 어떤 주소를 사용했는지 확인할 수 있지만, 각 토크 페이지의 리뷰(및 삭제된 경고에 대한 이력 조사) 프로세스는 번거롭고 번거로운 작업입니다.아무도 데이트할 시간이 없어IPv6 에 경고 또는 친근한 메세지를 드롭 하면, 기입이 완료했을 때에, 벌써 녹색의 풀로 이행해, 그 토크 메세지는 다시 표시되지 않게 됩니다.MediaWiki는 순진하게 그들이 함께 있을 수 없다고 믿지만, 그들은 함께 할 수 있다.IPv6 유저는, 어느 기간이라도, 다른 에디터와 의미 있는 커뮤니케이션을 즐길 수 없습니다.

그래서 WMF가 익명을 위해 무엇을 준비하고 있는지 모르겠습니다.Wiki에서 IP 기반 ID를 삭제하면 이 모든 것이 무의미해질 수 있습니다.그 시점에서 이 특정 문제는 쓸모없게 되는 건가요?

그 미래는 얼마나 먼가?그때까지 어떤 완화책이 있나요?Elizium 23 (토크) 2022년 7월 29일 (UTC) 04:15

Wiki에서 IP 기반 ID를 삭제하면 이 문제는 모두 해결됩니다.이 문제는 등록되지 않은 컨트리뷰터("세션 기반")를 추적하기 위한 대체 방법으로 선택되었기 때문입니다.이즈노 (대화) 2022년 7월 29일 (UTC) 04:24
  • 이는 phab에서 논의되고 있는 것처럼 보입니다.T112325. - xaosflux 14:30, 2022년 7월 29일 (UTC)

참조: iPad Pro의 글꼴 크기

Fabricator bug # T31119라고도 불립니다.

며칠 후 위키피디아에서 페이지를 열었는데 갑자기 글꼴 크기가 매우 작았다.이 버그를 보고하고 나서, iPad의 기능을 관리하는 기술이 조금 향상되어, Wikipedia의 폰트 사이즈를 간단하게 조정할 수 있게 되었습니다.그것은 며칠전까지는 없었습니다.(Fabricator 로그에는 버그가 1개월 이상 전에 수정되었다고 기록되어 있습니다만, 오늘까지 개선은 없었습니다.

즉, 이 버그를 수정하기 위해 어떤 일이 일어났고, 무엇이 변경되었는지 알겠다고 주장하지는 않지만, 이 정보를 전달할 의무가 있다고 생각합니다.(제 버그가 Fabricator에 보고된 버그가 아닐 수도 있습니다.또는 캐시 문제로 인해 수정이 지연되었을 수 있습니다.--lywrch (talk) 2022년 7월 29일 (UTC) 04:39

아마 phab도 경험했을 것입니다.이번 주에 수리된 T31795입니다.: The DJ (토크기여)8:26, 2022년 7월 29일 (UTC)

델리

Delhi infobox.png

안녕하세요, 어떤 이유에서인지 사진 몽타주가 옆으로 밀리고 맨 위에 왼쪽에서 오른쪽으로 자막이 튀어나와 있습니다.누군가가 사진 아래쪽으로 "왼쪽에서 오른쪽으로"를 이동시켜 이미지가 정보 상자의 너비를 깔끔하게 가로지르도록 할 수 있습니까?그렇게 튀어나온 꼴불견! ♦ Dr. Blofeld 2022년 7월 29일 (UTC) 11:53,

@Blofeld 박사님, 저는 (태블릿에 세로모드로) 잘 표시됩니다.- Qwerfjkltalk 2022년 7월 29일 (UTC) 12:03
지금 PC를 하고 있어요.뭄바이는 괜찮아 보인다.델리 몽타주는 왼쪽에 큰 흰 틈이 있고, 자막으로 인해 오른쪽 아래에 큰 틈이 있다.스크린샷 QwerfjklDr. Blofeld 12:11, 2022년 7월 29일(UTC) 참조
이상하게도 {{multiple image}}의 폭을 100으로 바꾸면 이미지 옆에 캡션도 표시됩니다.그런데 이번에는 자막이 이미지 왼쪽에 있어요.현재의 폭(250)에서 화면에는 예상대로 인포박스가 표시됩니다.뭄바이의 폭을 100으로 줄인다고 해서 이미지 캡션의 위치가 바뀌는 것은 아닙니다.: CX[그/그 사람] 2022년 7월 29일 13:07 (UTC)
플로팅 얼라인먼트가 문제입니다.[Now centered] : The DJ (talk • contributes) 2022년 7월 29일 14:30 (UTC)
Gracias TheDJ!♦ Blofeld 박사 2022년 7월 31일 (UTC) 15:58

검색, RedLinks의

안녕하세요. 마라티 위키피디아(mrwiki)에 문의합니다.몇 년 전 사용자로부터 다음과 같은 유사한 질문을 받았습니다.Wikipedia 토크에서의 ★★★★★★★★★★★★★★★★★★★」빨간색 링크/아카이브 6이지만 토론에서 아무런 결과도 나오지 않았습니다.

요컨대, 마라티 위키피디아에는 약 9만 개의 글이 있고, 고아들의 수많은 글과 레드링크(흔히 철자가 틀린다)가 있습니다.redlinks가 포함된 기사 목록을 검색/작성할 수 있는 방법이 있습니까?경위: 사용자명 키란(대화) 2022년 7월 29일(UTC) 13:52

@Usernamekiran은 당신이 요구하는 것은 아니지만, 만약 그들의 목표가 그들의 레드링크를 통과하는 것이라면, Special:Wanted 페이지에는 각 Redlink가 호출된 횟수 순으로 나열됩니다.- xaosflux 14:04, 2022년 7월 29일 (UTC)
@Xaosflux:, 다음에서 찾았습니다.★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★도와주셔서 정말 감사합니다.: 사용자명 키란(대화) 2022년 7월 29일(UTC) 14:15

드롭다운 메뉴의 차단 버튼

방금 UAA를 확인하던 중 드롭다운 메뉴에서 Block 옵션이 다른 무엇보다 큰 텍스트로 표시되어 있는 것을 발견했습니다.너무 커서 주변 옵션을 즉시 대체할 수 있습니다.iPhone에서 데스크톱 모드로 기본 스킨을 사용하고 있으며 표준 삭제 및 차단 옵션 외에 드롭다운 메뉴에 표시되는 스크립트가 몇 개 있습니다.비슷한 걸 눈치챈 사람?The Blade of the North Lights (북극광의 칼날) 2022년 7월 29일 (UTC) 14:31

@'북극의 칼날' 좀 더 구체적으로 말씀해 주시겠어요?예를 들어, safemode의 사용자 페이지는 다음과 같습니다.https://en.wikipedia.org/wiki/User:The_Blade_of_the_Northern_Lights?useskin=vector&safemode=1 "Block"은 "드롭다운 메뉴"가 아니라 왼쪽 사이드바에 있습니다.- xaosfluxTalk 14:42, 2022년 7월 29일 (UTC)
혼란을 드려 죄송합니다.시계 목록 별과 트윙클 드롭다운 사이에 있는 "더 보기" 탭 아래에 있습니다.제대로 된 용어가 있을 거예요. 잘 모르겠어요.The Blade of the North Lights (북극광의 칼날) 2022년 7월 29일 (UTC) 14:46
@The Blade of the North Lights ah OK, Import하는 것은 개인 사용자 스크립트인 것 같습니다.사용자:Animum/easyblock.js.그 스크립트의 메인터너는 2015년 이후 실제로 활성화 되어 있지 않기 때문에 사용을 중지하는 것이 좋습니다.제안할 수정 사항이 있는 경우 User talk에서 편집 요청을 삭제해 볼 수 있습니다.Animum/easyblock.js.- xaosfluxTalk 14:53, 2022년 7월 29일 (UTC)
말이 되네.하필이면 왜 오늘부터 말썽을 피웠는지 모르겠지만, 뭔가 오래된 걸 간직할 이유는 없어.감사합니다! (또한 유사한 작업을 수행하는 유지관리 스크립트를 알고 있는 사람이 있다면 그 중 하나를 시도해 보겠습니다.)The Blade of the North Lights (북극광의 칼날) 2022년 7월 29일 (UTC) 15:10

외부 링크 사진이 변경되었습니다.그 얘기는 어디서 하지?

Vector 2010 아래의 외부 링크가 표시기로 표시됩니다.이러한 변화가 어디에서 오는 것인지, 그리고 왜 어디서 논의해야 하는지 아는 사람이 있습니까?제이슨 퀸 (토크) 2022년 7월 29일 (UTC) 14:44

@Jason Quinn: the technical answer to your question is: see phab:T261391. — xaosfluxTalk 14:48, 29 July 2022 (UTC)
Great. Thank you. Rather than an image, I wonder if a UNICODE character like ⧉ or 🔗 would satisfy the web design guidelines they are following. Jason Quinn (talk) 16:06, 29 July 2022 (UTC)
This is also under discussion at WP:VPPRO#RfC: Should we use the longstanding external links icon or the new one?, but the change has been reverted for the moment. Izno (talk) 16:10, 29 July 2022 (UTC)

Seeing redirect pages to section while editing

Is there any sort of script that exists or other implementation that is able to show when editing a section if there are redirect pages currently targeted to that section? I know one can go to the "What links here" and select only redirects for any page to see this, but I didn't know if there was the ability to see this while editing or previewing a page. I'm thinking it as a way to know what is linking to a section in question, in the event the heading needs to be altered or the section gets moved elsewhere to a more relevant page (if applicable), to know if anchors need to be added, or at the very least to be aware of such pages to help fix redirect locations without leaving them potentially broken. Thanks. (Also apologies if this isn't the correct location to inquire about such a thing.) - Favre1fan93 (talk) 15:31, 29 July 2022 (UTC)

Openstreetmap based maps on Wikipedia

I had a question about what to do to fix the openstreetmap-based map that I am trying to put into this one page. On the Ahmedabad-Dholera Expressway page, you can see that I have added the source code but something is still wrong. I have added all the source code but the base map does not show up in the infobox as it should. A correct example of this is on the page Bundelkhand Expressway where the expressway is outlined in red and shows up in the info box. I know that you have to get the wiki data tag and put that into the source code in order for it to work and I did do that. But it still seems to not be working and I was wondering if someone could guide me so that I can see what I am doing wrong in adding these maps. Any help would be appreciated. Thanks, - User:Yellow alligator 18:02, 29 July 2022 (UTC)

Bundelkhand Expressway gets its map data from its Wikidata item (wikidata:Q48730051). This data most likely comes from it's Google Knowledge Graph ID (/g/11f2wbm55j). This knowledge graph already has a map which is simply copied on Wikipedia. Now, Ahmedabad–Dholera Expressway's knowledge graph ID (/g/11j8kw9dpj) doesn't contain a map. There is no source from which we can extract a map. That's why a map isn't visible. If you can manually recreate the route online, Wikipedia:Creating route maps from OpenStreetMap data may guide you through the process to add a new map yourself. CX Zoom[he/him](let's talk • {CX}) 23:59, 30 July 2022 (UTC)
@Yellow alligator: ping. CX Zoom[he/him] (let's talk • {CX}) 07:01, 31 July 2022 (UTC)
Thanks. I just noticed this A-D-Expressway is still under construction. I think we should wait till it gets completed. Infrastructure projects may never even get completed. Venkat TL (talk) 07:04, 31 July 2022 (UTC)

Can I get a list of most common first words for article titles?

I do a fair amount of anthroponymy work, and have gotten to wondering where there might be gaps in our coverage of common given names. To that end, I'm curious as to whether it would be possible to generate a list of number of articles in Wikipedia by first whole word (e.g., how many articles start with "Albert" or "Gerry" or "Zane" as a word, followed by a space, followed by another word). I would want to exclude redirects, and I think it would be reasonable to cut it off (for a first run) at words that have more than 50 articles starting with that word.

If such a list already exists, please point me to it. Cheers! BD2412 T 18:23, 29 July 2022 (UTC)

If "exclude redirects" isn't that important you can download the list of all article titles here and then just do some datamining on it. — xaosfluxTalk 18:36, 29 July 2022 (UTC)
Suppose you could "minus out" from the list of redirects file — xaosfluxTalk 18:39, 29 July 2022 (UTC)
I don't particularly have the kung fu to do that kind of data mining. I'm just looking for the assist. BD2412T 18:49, 29 July 2022 (UTC)
@BD2412: The following SQL query should do it:
SELECT COUNT(*) AS total, SUBSTRING_INDEX(page_title, "_", 1) AS first_word FROM page WHERE page_is_redirect = 0 AND page_namespace = 0 GROUP BY first_word HAVING total >= 50; 
I went ahead and ran it for you at quarry:query/66345. Unsurprisingly, the top words are "List" and "The", but then you start to get names such as John, William, James, Robert, David, George, THomas, Charles, etc. --Ahecht (TALK
PAGE
) 19:08, 31 July 2022 (UTC)
@Ahecht: Fascinating. Thanks, this is perfect. BD2412T 19:55, 31 July 2022 (UTC)
@BD2412: I developed the query a little further to limit it to people and to exclude names which already have (or redirect to) an article, here. Most results are still false positives. "List" has gone, but "The" still hangs in there due to The Weeknd, etc. and there are a few other non-names such as Sir. Names like Jesús redirect to a dab with a name article as one entry; eliminating such cases in SQL would be way too slow. (The query is already ridiculously complex because the SQL implementation fails to use an index on page_title when given a prefix, insisting on one single exact title.) Certes (talk) 00:44, 1 August 2022 (UTC)
Eliminating the numerical and organizational prefixes is a help, thanks. BD2412 T 00:46, 1 August 2022 (UTC)

Italic title at 2000 Summer Olympics opening ceremony

Can someone explain to me why this article displays an italic title, and how to change it. I see no {{italic title}} in the article, and {{Infobox news event}} doesn't seem to carry automatic italics either. StAnselm (talk) 18:48, 29 July 2022 (UTC)

@StAnselm: just by brute force previewing, it was something in the "Music" section. I have split that out into a separate article on the album, which has resolved the problem. BD2412T 18:55, 29 July 2022 (UTC)
Oh, of course - the album infobox. Thanks. StAnselm (talk) 19:04, 29 July 2022 (UTC)
Unwanted italics in the title are nearly always from an infobox somewhere in the page. {{Infobox album}} supports italic_title=no. PrimeHunter (talk) 00:11, 30 July 2022 (UTC)

List of 'list articles' by page views

I want to generate a list of 'list articles' (List of United States Presidents, List of medieval composers etc.) by page views, but trying to do so on pageviews.wmcloud.org has (inevitably) been too large of a request to load. Does anyone know of an better way, or can do so for me? Looking for say, top 50 list articles. Aza24 (talk) 07:19, 30 July 2022 (UTC)

For example, doing mass page views on this category of 139,979+ articles does not work on my computer. Aza24 (talk) 18:44, 30 July 2022 (UTC)

Like a... list of lists? — Guarapiranga 01:28, 1 August 2022 (UTC)
Not really Guarapiranga, I'm trying to see what the most viewed lists are (order them by page views), to get ideas of what to work on. Aza24 (talk) 04:00, 1 August 2022 (UTC)
I see... Somewhat like that? — Guarapiranga 04:20, 1 August 2022 (UTC)
How about looking at what lists have been edited recently (and which haven't), as a proxy (presumably, lists popular with readers are also popular with editors)? — Guarapiranga 04:32, 1 August 2022 (UTC)
The top 73 "List of..." articles appear on User:HostBot/Top 1000 report (along with hundreds of non-list articles). Certes (talk) 09:07, 1 August 2022 (UTC)
Thank you to both Guarapiranga and Certes! These pages should definitely help! – Aza24 (talk) 19:07, 1 August 2022 (UTC)

Cite recovery

I am sure that in the past when I deleted list cites a bot came round and fixed the cites. But that has not happened yet at European emission standards. I cannot remember the name of the bot Chidgk1 (talk) 11:43, 30 July 2022 (UTC)

There's an easy way to fix this: revert your edit that removed references, and edit the article instead of doing fly-by deletions that may contravene policy. If you actually edit an article you will be able to tell which references are necessary. It is a lot of work, of the most uninspiring sort, and you will not be rewarded. So that's it. Another option (a fairly common one) is to come at VP and complain about this thing or another. 68.132.154.35 (talk) 15:52, 30 July 2022 (UTC)
(edit conflict) If you're thinking of AnomieBOT (which you probably are), it doesn't handle refs defined by screwy templates like {{r}}. Anomie 15:54, 30 July 2022 (UTC)
Why is {{r}} "screwy"? 68.132.154.35 (talk) 15:56, 30 July 2022 (UTC)
@Chidgk1: this is a really bad approach to editing live pages. You are knowingly removing refs that you know are likely in-use. That's a detriment to readers and bumps up against WP:V policy up until the time they get re-added. It might be transient (but now you know it might not be), but even if so, it's better to have unused refs (no obvious harm). DMacks (talk) 16:08, 30 July 2022 (UTC)
Thanks for explaining - for this particular article manually editing to remove unused refs will likely not be too time consuming for someone (probably not me as they are not doing much harm). For the previous 2 - where the bot worked very well thanks - there were far too many used and unused old-style refs to edit manually. Chidgk1 (talk) 06:13, 31 July 2022 (UTC)
"Flagging unused list-defined references" seems like a well-defined feature-request. That help-page notes "All references in reference list must be referenced in the content, otherwise an error message will be shown." and Help:Cite errors/Cite error references missing group says this error message should be easily visible. At least for mainspace and default ref-group, it explicitly says which ref-name is unused. For example, the version prior to your edit at European emission standards said (links omitted):
Cite error: A list-defined reference named "BBC 6337057" is not used in the content (see the help page).
Cite error: A list-defined reference named "EC" is not used in the content (see the help page).
Cite error: A list-defined reference named "Europa 1" is not used in the content (see the help page).
Cite error: A list-defined reference named "IHT 2007/02/06" is not used in the content (see the help page).
So if there are lot of them, you have to spend a moment finding each in the list, but it's mindless and easy. And it also doesn't seem to work in all namespaces (does in main, not in user), so that's an annoyance for out-of-mainspace article development and discussion. DMacks (talk) 21:52, 31 July 2022 (UTC)
@Chidgk1 this is clearly a "bad edit", and I've reverted it. You should never assume that any future edit will ever be made. — xaosflux Talk 16:09, 30 July 2022 (UTC)

"Talk pages are where people discuss how to make content on Wikipedia the best that it can be"

I very strongly dislike seeing this on redlinked talk pages. Never liked it to begin with and am fed up with it now. I would rather it just take me to a blank editing window like old times. Sometimes I'm making redirects or disambig pages that need talk pages in a hurry (some redirect pages meet the criteria for having talk pages, e.g. song title redirects to album pages which is what I work on sometimes). It would be a lot quicker and less annoying to be able to cut straight to the chase and skip this banner, like before — in fact, like earlier just this year. Is there any way to disable this, or do we really need it for any group of users? Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 07:13, 31 July 2022 (UTC)

You may be able to change this behaviour in Special:Preferences#mw-prefsection-editing, section Discussion pages, item When I visit a discussion page that hasn't been created yet:. Certes (talk) 10:46, 31 July 2022 (UTC)
That certainly seems to have worked. The only place I can see it may not have taken effect is on talk pages for user subpages (e.g. any uncreated archives for my talk page will result in the same type of message, and in their case it seems unskippable), but I don't care since I obviously won't be working in user subpages with any frequency at all. For those interested, this is what you do — go to Preferences, Editing, and scroll down until you see:
When I visit a discussion page that hasn't been created yet:
  • Offer to add new topic
  • Open the wikitext editor
"Offer to add new topic" is the default. Switch to "Open the wikitext editor".
Many thanks for your help! Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 17:02, 31 July 2022 (UTC)

Pass parameters to parsed interface messages

How do I pass parameters to interface messages in an API parse request? {{MediaWiki:Protectedpagetext editprotected add rubbish to}} doesn't work, that outputs "This page is currently semi-protected so that only established, registered users can $2 it." (when it should say fully protected and "$2" should be "add rubbish to") Alexis Jazz (talk or ping me) 18:46, 31 July 2022 (UTC)

@Alexis Jazz: The wikitext method is to use {{int:}} at mw:Help:Magic words#Localization: {{int:Protectedpagetext editprotected add rubbish to}}. I guess that works for your purpose. If you are logged in then it uses the message in your language setting at Special:Preferences. We usually only customize en messages. PrimeHunter (talk) 18:55, 31 July 2022 (UTC)
PrimeHunter, that works indeed. Face-smile.svg Makes sense, I hadn't realized int: would affect this. Thanks! Alexis Jazz (talk or ping me) 19:23, 31 July 2022 (UTC)

Searching and sorting the deletion log by reason

Is there an efficient way to search through the deletion log by reason, e.g., XfD closures/expired PROD/specific CSD criteria? If there isn't a script or tool available for this, would it be technically possible to implement in a similar manner to searching/sorting the log by user? User:Pppery and I were having a short discussion about this at Wikipedia talk:Criteria for speedy deletion#Adding to Non-criteria list section, as such a feature could be very helpful to those who may be interested in reviewing deletions. Complex/Rational 01:46, 1 August 2022 (UTC)

New talkpage welcome message

Hi, On my talkpage I'm now greeted with a rather patronizing message: "Welcome to your talk page People on Wikipedia can use this talk page to post a public message for you and you will be notified when they do." and I'm now greeted with similar messages on other peoples tps

Is there any way this can be disabled as I think by now I know what a talkpage is and the purpose of it!. Thanks, –Davey2010Talk 12:56, 1 August 2022 (UTC)

@Davey2010:Special:Preferences#mw-prefsection-editing, uncheck "Enable quick topic adding". --Ahecht (TALK
PAGE
) 13:05, 1 August 2022 (UTC)
@Ahecht that doesn't fix the problem that "others" are seeing this where it doesn't seem to make sense. For example, open Dave2010's user talk in a private browser. — xaosfluxTalk 13:10, 1 August 2022 (UTC)
I suppose if you wanted to prevent "new topic" from running on specific pages (for others) another feature request could be added (mirror that of phab:T249293 that is looking for a way to disable reply-tool on certain pages). — xaosflux Talk 13:16, 1 August 2022 (UTC)
Hmmm, seems like you are getting MediaWiki:discussiontools-emptystate-title-user. Are you only seeing this on talk pages that have no sections? — xaosfluxTalk 13:09, 1 August 2022 (UTC)
Yes, I see them too when there are no sections, and I see it on Davey2010's talk page. I see this at User talk:Sandbox too. Special:Permalink/1093717911 is the latest revision as of now, and shows this message. Special:Permalink/1092296292 is an old version with the same exact source code, but does not show the message. CX Zoom[he/him] (let's talk • {CX}) 13:16, 1 August 2022 (UTC)
I created a template, {{No discussion tools empty state}} that can suppress this for others on a per-page basis, such as if you want to build a page workflow that never uses that. See example at User talk:Xaosflux/Sanbox 12. As far as that message goes, if you don't want to see it on other-people's pages, but do want to use discussion tools - perhaps you can suppress it in your usercss. — xaosflux Talk 13:50, 1 August 2022 (UTC)
@Davey2010: try putting the code below in Special:MyPage/common.css
.ext-discussiontools-emptystate {  display:none; } 
That Should hide that dialog "for just you" on all pages. — xaosfluxTalk 13:56, 1 August 2022 (UTC)
Hi Xaosflux, Ahecht and CX Zoom - Many thanks for your help and special thanks to Xaosflux for the workaround greatly appreciate everyones help here, I do apologise for not mentioning earlier that I'm using the discussion tools feature I had completely forgot I was even using it (or that it was a beta feature still), Anyway thanks Xaosflux for your help and workaround greatly appreciated,
I've added the No discussion tools empty state template to my talkpage however it now says on my talkpage toc "Invisible section to prevent the discussiontools-emptystate-title tool from running on select pages with no sections" - Not sure if that's meant to be included in my TOC but I'd rather have that then the patronizing message! :), Added the other codding and can confirm it removes the message for myself on others talkpages so yeah I'm happy now and once again thanks Xaosflux and everyone else shelp today I greatly appreciate it, Many thanks, Warm Regards, –Davey2010Talk 17:21, 1 August 2022 (UTC)
@Davey2010 Hmm, I made it shorter. It is not really the best fix for this, that would require a magic word, I'll see about creating a phab task. — xaosfluxTalk 17:34, 1 August 2022 (UTC)
It will still work on a page that has a special sort of workflow, as they won't normally show a TOC. — xaosfluxTalk 17:35, 1 August 2022 (UTC)
Ah okay thank you @Xaosflux, Exactly there's not a great fix and I guess we're not going to please everyone but I would take the long title over that message any day of the week! - I just didn't know if anyone was aware which is why I mentioned it. It's gone so I'm happy as larry! :), Thanks again!, –Davey2010Talk 17:45, 1 August 2022 (UTC)
@Xaosflux Instead of using a hidden section header, how about using a hidden signature? The tool checks for either a section header or a signature, so a hidden signature should be enough to stop the message appearing, without messing up the table of contents. 192.76.8.85 (talk) 01:09, 2 August 2022 (UTC)
You could also hide it by putting that CSS in TemplateStyles (the message box is part of the page content, so it'll work). That'd be my preferred way, as one of the developers of the tool, since it seems least likely to affect our stuff in unexpected ways. Matma Rextalk 02:17, 2 August 2022 (UTC)
Hidden signature seems to work via a template, updated Template:No discussion tools empty state and when I look at @Davey2010:'s talk page it seems to be preventing the "empty state" state. — xaosflux Talk 11:45, 2 August 2022 (UTC)
That could be a fix for project-talk, etc - but is a bit cumbersome for usertalk for any user to have to load a templatstyle control to their page. — xaosflux Talk 11:53, 2 August 2022 (UTC)
@Xaosflux: If you create a phab task for a magic word, please also ask to make the absence of this notice the default setting on talk page redirects, see for example, Talk:2020–2022 Pakistani political crises. CX Zoom[he/him] (let's talk • {CX}) 20:51, 1 August 2022 (UTC)
One workaround would be to use a level 6 invisible heading instead of level 2 like {{No discussion tools empty state}} currently does. And then also using {{TOC limit}} at level 5 or lower header. CX Zoom[he/him](let's talk • {CX}) 17:34, 1 August 2022 (UTC)
The devs have been talking about __NONEWSECTIONLINK__ as a way to suppress some of Discussion Tools. (I'm not sure which Phab task it is right now.) Whatamidoing (WMF) (talk) 23:48, 1 August 2022 (UTC)
@Whatamidoing (WMF) that is phab:T249293 and is specific to reply-tool (and that should indeed get solved either with that or a new magic word, lots of people don't like it on "archive" pages) - not sure if it should also control "new topic", but maybe? — xaosflux Talk 11:51, 2 August 2022 (UTC)
@Davey2010 Do you really want to prevent other users from seeing the message on your talk page? I understand that you find it silly as an editor with years of experience, but it could genuinely be helpful for a new editor reaching your talk page for whatever reason (as currently it contains many things, but little that hints that you can write this person a message there). I'd suggest just hiding it for yourself with the CSS snippet provided by @Xaosflux if it is distracting for you. Matma Rextalk 02:15, 2 August 2022 (UTC)
@Matma Rex I'd see hiding it for others mostly useful if we have a page with non-standard workflows, say we build a giant "click this to leave a message" type of button, have an input box with a preload, etc. — xaosflux Talk 11:49, 2 August 2022 (UTC)
Davey2010 en msg.png
Matma Rex, At the time of writing the above issue I actually thought it could be disabled for me only, I never wanted to impact other editors or readers, But that being said because of the way my talkpage is laid out the message never looked right to begin with (see image below) and I really am not going to fart-arse around changing everything for the sake of a message I cannot see and don't want to see.
IMHO by removing the message no newbies or editors are missing out - It's 2022 and so far mostly everyone has grasped what a talkpage is and the purpose of it so I really don't see a need for a message stating the obvious, Thanks, –Davey2010Talk 15:41, 2 August 2022 (UTC)
Thanks for the explanation. (And thanks for that screenshot, I think that's a bug we should be able to fix.) Matma Rex talk 17:35, 2 August 2022 (UTC)

Lua error

What causes multiple red messages "Lua error in Module:Citation/CS1 at line 1392" here? I suspect this has something to do with introduced Template:Harvard citation no brackets, but can't find the error in wikimarkup. Thanks. Brandmeistertalk 13:08, 1 August 2022 (UTC)

The citation templates are broken right now. There is nothing you can do about it. AManWithNoPlan (talk) 13:10, 1 August 2022 (UTC)
Ok, will wait, as per another complaint below. Any word about time of fixing? Brandmeistertalk 13:13, 1 August 2022 (UTC)
Issue has been resolved now Kpddg(talk) 13:18, 1 August 2022 (UTC)
Looks good now, whew! SandyGeorgia (Talk) 13:22, 1 August 2022 (UTC)

Help needed fixing Lua errors

The Clarence Campbell article has multiple Lua errors. Does anyone know where to ask for help, or could be a hero and fix the problems? Flibirigit (talk) 13:08, 1 August 2022 (UTC)

The citation templates are broken right now. There is nothing you can do about it. AManWithNoPlan (talk) 13:09, 1 August 2022 (UTC)
Where is the place for updates? Help talk:Citation Style 1 is not the place. Bluerasberry (talk) 13:11, 1 August 2022 (UTC)
Is it related to this edit ('bump pmc')? I lack the WP:Boldness to mess with modules :) Dsp13 (talk) 13:11, 1 August 2022 (UTC)
How on earth did this get rolled out without testing it fully first?! Citations broken all over the encyclopedia! MeegsC (talk) 13:12, 1 August 2022 (UTC)
Seems to be everywhere,. I get it on all my citation efforts today. Also, a thread at Wikipedia:Administrators' noticeboard/Incidents#CS1 going haywire. — Maile (talk) 13:13, 1 August 2022 (UTC)
@Maile66: You can fix the problem, as you're an admin, by undoing the edit Dsp13 linked to above. * Pppery * it has begun... 13:14, 1 August 2022 (UTC)
User who did it inactive 20 minutes since edit User_talk:Trappist_the_monk#Lua_errors_everywhere Only admin can undo Bluerasberry (talk) 13:15, 1 August 2022 (UTC)
Looks like Trappist the monk has fixed it now. If you're still seeing errors, you may need to do a WP:PURGE on articles with the errors. --Ahecht (TALK
PAGE
) 13:18, 1 August 2022 (UTC)
I don't think it's fixed. It's still happening. — Maile (talk) 13:24, 1 August 2022 (UTC)
OK, it's fine now. — Maile (talk) 13:28, 1 August 2022 (UTC)

Clive Stephen - refs replaced with Lua error

I also was going fine with Clive Stephen but now I seem to have lost all references - most are replaced by "Lua error in Module:Citation/CS1 at line 1392: bad argument #1 to 'pairs' (table expected, got nil)." I've tried reverting to earlier versions, but without result . Thank you for any help. Jamesmcardle(talk) 13:16, 1 August 2022 (UTC)

See the above thread. * Pppery * it has begun... 13:19, 1 August 2022 (UTC)

"Lua error in module citation"

I have noticed that the references I've added suddenly have the Lua error in module citation... I do not know anything about what this means, and I do not know if this is the correct venue to report it, but I'd be glad if I knew how to prevent such events. At this version of today the sources appear alright, in this one a few hours later and after only introducing a wikilink, Kurdish Theatre in Turkey has the Lua error. Paradise Chronicle (talk) 13:23, 1 August 2022 (UTC)

@Paradise Chronicle: The issue has been resolved. You may need to do a WP:PURGE on any pages still showing the error. --Ahecht (TALK
PAGE
) 13:25, 1 August 2022 (UTC)
Oh, it appears I am not the first to report the Lua errors... Paradise Chronicle (talk) 13:43, 1 August 2022 (UTC)
Thank you all Paradise Chronicle (talk) 13:47, 1 August 2022 (UTC)

Tech News: 2022-31

21:20, 1 August 2022 (UTC)

Prototype: Talk Page Design

Hi y'all – for those interested in talk page design changes, would you be open to trying out a prototype that includes the set of optional visual changes the Editing Team is proposing to make to wikitext talk pages? More details below.

Mockup: talk page design (desktop)

For context, these changes are a part of the ongoing Talk Pages Project, and they are designed to make it easier for people to understand talk pages and assess the activity happening within them.

Try the Prototype

To try the prototype....

  1. Visit this article talk page on the special prototype wiki using a skin and device (desktop/laptop or mobile) of your choosing:
    1. Vector (2022)
    2. Vector
    3. Monobook
    4. Timeless
  2. Explore and experiment with the talk page
  3. ✅ Share your feedback (see instructions below)

Share Feedback

We would value you publishing the feedback you have in either of these places:

  1. Post the feedback you have by commenting in this discussion
  2. Post the feedback you have by creating a new section on Wikipedia talk:Talk pages project

Of course, if you run into any questions as you're trying out the prototype, please ping me or @Whatamidoing (WMF). PPelberg (WMF) (talk) 00:00, 2 August 2022 (UTC)

@PPelberg (WMF) I like the idea behind the "Latest comment" line, but it seems like there's a lot of unnecessary whitespace around it. Something like File:Patchdemo talk page ahecht suggestion.png visually separates that line without adding a ton of unnecessary whitespace. --Ahecht (TALK
PAGE
) 16:08, 2 August 2022 (UTC)
@Ahecht, which skin do you normally use? Whatamidoing (WMF) (talk) 20:33, 2 August 2022 (UTC)

gadget notice

(cross post from IANB)

Wikipedia:EditNoticesOnMobile will be launching as a default gadget. It is limited to mobile users who are using Minerva skin. A waved approach is being done, wave one is only admins. Should something break, it can be instantly disabled via MediaWiki:Gadgets-definition. Please report any issues to Wikipedia talk:EditNoticesOnMobile. Best regards, — xaosflux Talk 23:04, 19 July 2022 (UTC)

  • Update: this has been expanded to wave 2 today, extendedconfirmed users. — xaosflux Talk 17:59, 2 August 2022 (UTC)

Can you change the "red alert" for messages?

--Redrose64 🌹 (talk) 19:04, 2 August 2022 (UTC)

I don't know if this is the right place, but I have a softward suggestion. Why do we get a "red alert" on the bell, even for something as innocuous as somebody pinging you on a talk page? Red means "something bad!" / "someone's mad at you!" / "you did something wrong!". The blue number on the "thanks" / "someone mentioned you" message is much less stressful to see. When I see the red alert, I often ignore it or delete it without reading, because I don't need additional stress in my life. Mr Serjeant Buzfuz (talk) 21:15, 1 August 2022 (UTC)

@Mr Serjeant Buzfuz: If you put the following rule
#pt-notifications-alert .mw-echo-notifications-badge.oo-ui-flaggedElement-unseen::after, #pt-notifications-alert .mw-echo-notifications-badge.mw-echo-unseen-notifications::after {   background-color: Sienna; } 
into your CSS, it will alter that red to Sienna, which should give something like this: 2 . You can set any of the web colors instead. --Redrose64 🌹 (talk) 19:17, 2 August 2022 (UTC)
...and to use the exact same color with thanks notifications, use background-color: #3366cc;. NguoiDungKhongDinhDanh 19:42, 2 August 2022 (UTC)

Proposals

Clerk reform at RfA/RfB

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This RfC attempts to gauge a consensus for a reform of clerking at RfAs/RfBs, which is proposed due to much discussion on that topic during a recent RfB. The general proposal is submitted below for evaluation, please share your thoughts. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)

Proposal (Clerk reform at RfA/RfB)

  1. Clerking for RfAs and RfBs is delegated exclusively to the clerks serving at the Arbitration Committee who do not simultaneously have bureaucrat rights.
  2. Bureaucrats may !vote but may not clerk discussions. If they submit a !vote, they shall not be active during the determination of consensus for approval of the request for adminship/bureaucratship and may not participate in the bureaucrat discussion, if it is started.
  3. A clerk that has had substantial interaction with the candidate in question, or has nominated the candidate for RfA/RfB, must refrain from clerking it.
  4. The clerks must refrain from making comments in support or opposition of the candidate, and shall not modify or remove the comments based on whether the clerk agrees or disagrees with the opinion expressed there, but may only do so in case of violation of civility. They shall make explicit any intervention in the comments, along with the reasoning of intervention.
  5. Using their administrative tools (if they have access to them), the clerks may ban the editor from the RfA/RfB they are participating in case of persistent refusal to maintain decorum, but only for the duration of that RfA/RfB. A general ban from such discussions may only be enacted following a discussion at the administrator's noticeboard.
  6. Any sockpuppetry/meatpuppetry investigations, or those of canvassing, if started by a clerk or a bureaucrat in relation to an RfA/RfB, must be resolved as a first priority.
  7. The community will determine the venue of appeal or review of clerk's actions. (Formulated that way due to the current uncertainty over the existence of XRV and its scope)
  8. The Arbitration Committee may, if the rational usage of user resources so requires, appoint more clerks.

Rationale (Clerk reform at RfA/RfB)

In 2011, there was a proposal to introduce clerking as an ad hoc role for administrators and non-administrators in good standing alike, but it was not approved. The 2015 RfC established that bureaucrats may have the right to clerk discussions. In the answers submitted as part of the most recent RfB, however, Wugapodes, an (unsuccessful) candidate for a bureaucrat, said that bureaucrats are reluctant to clerk the discussions themselves, particularly since they may be perceived as non-neutral if they intervene. There has been some discussion during the RfB of the proposal of more active clerking as a way to reduce the stress and drama that often accompany the process, and there seemed to be some support to let it have a try, though not much certainty over the effectiveness of such a solution.

This proposal suggests a change from the bureaucrat-enforced decorum (which apparently does not work) to clerk-enforced decorum. Clerks are supposed to be experienced in dealing with incivility, which is often in ample supply at ArbCom, and the ways to respond to it. A drawback to this solution is that there are few clerks to begin with, and some bureaucrats are already arbiters. That said, let's try this proposal to see if people agree to make some sort of change, or even if it fails, we could see where the community in general stands on this issue. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)

Feedback (Clerk reform at RfA/RfB)

(summoned by the bot) I applaud such efforts but 'Oppose This would be 8 new rules and procedures to solve 2 non-existent problems. The big problem at RFA isn't uncivil decorum, the problem and fix is more complex than that. And Wikipedia already has rules and processes regarding uncivil behavior. But thanks for such efforts. Sincerely, North8000 (talk) 12:02, 21 June 2022 (UTC)

If approval for sanctions is determined at the administrators' noticeboard, then I think any uninvolved administrator should be able to evaluate consensus (and, if deemed necessary, implement any suitable blocks). I don't think it's a good idea to prioritize sockpuppet investigations for an internal procedure versus those for mainspace edits. If necessary, an internal procedure can be put on hold or extended, without consequences to readers. Regarding the 2015 RfC, note the option of "any editor" received almost as much support as "bureaucrats", which is in practice what is done today. (On more minor editorial notes, the first sentence of point 2 is redundant with point 1, and point 8 is always generally the case.) isaacl (talk) 16:03, 21 June 2022 (UTC)

  • Feedback on components:
    1. I don't see any reason to forbid 'crats from clerking. I also don't like the idea of having arbcom be in charge of RfA's (as they are in charge of the arbcom clerks). I vote for arbcom members for dispute resolution skills, not for this.
    2. 'Crats already recuse when appropriate; this sets up a scenario that could prevent closure (as recusal isn't required if every active crat participated in an RFA it would be stuck - in practice this doesn't happen as the majority of 'crats do abstain from !voting.
    3. There are currently only 4 active clerks - who are also active throughout the project - some are already likely to have interacted with admin candidates.
    4. Volunteering to clerk arbcom cases should not disenfranchise someone from participating in RfA's.
    5. "Bans" don't require admin tools, and I don't think we should have any situation where a single editor can ban another one.
    6. CU's are volunteers - dictating the order of their work, or that they must volunteer to do something before they are allowed to volunteer to do other things is very anti-volunteer.
    7. Um, sure.
    8. Arbcom can already appoint as many clerks as they want.
    • So, I think there are many problems with this as proposed. I am fairly open to expanding the 'clerking' capacity of our 1,030 strong admin corps. — xaosflux Talk 12:59, 22 June 2022 (UTC)
  • Oppose. While some RFA/RFB discussions could be better, this amount of bureaucracy isn't going to resolve the issues and could lead to others. Thryduulf (talk) 11:56, 23 June 2022 (UTC)
  • I'd quite like to see some sort of "authorized" clerking system, but this seems like too much. What's needed are a few admins who are clear on what won't fly at RfX and what to do about it. Whoever clerks an RfX shouldn't !vote in it, but otherwise they really don't need any special qualifications. valereee (talk) 13:34, 24 June 2022 (UTC)
  • I'd also oppose - let's have Crats (those who don't (!)vote) clerk. In the same way that admin actions don't make someone INVOLVED for a future admin action, clerking would not logically disqualify from 'cratchats anyway. Nosebagbear (talk) 16:26, 24 June 2022 (UTC)
  • Oppose - I'm a longstanding proponent of clerking at RfA, to the extent that I myself wrote a proposal over a decade ago. So this definitely caught my attention. And then immediately lost it with the very first point. I find the proposal to be tone deaf towards the RfB that inspired it. The RfB mostly failed because the user was an active arbitrator, and a significant group came out in opposition to the existence of an overlap between the two roles, with many comments clarifying that it is nothing personal against the user. I certainly don't think the community wants a special class of people hand-picked by Arbcom to be policing RfA, when they don't want even the most uncontentious arbitrator policing RfA as a crat. In spite of this result, it did not fail because the community doesn't want crats to clerk RfA. Indeed, the community has repeatedly established that it supports the notion of crats clerking RfA, it is supported by a formal RfC, and based on the RfB, this hasn't changed. ~Swarm~ {sting} 05:36, 25 June 2022 (UTC)
  • Oppose: How does this solve anything is beyond me. I might be dumb but please don't tell me that sockstriking a sock's !vote at a RfA would get me blocked just because I'm not a ArbCom clerk. CX Zoom[he/him] (let's talk • {CX}) 20:43, 25 June 2022 (UTC)
  • Oppose - Preventing crats from clerking at RfB seems like a good idea, but the rest of the proposals seem to me like formalizing a lot of things that already happen, and work just fine at that. Not to be too libertarian, but I think setting rules beyond what is necessary is...not necessary. Toadspike (talk) 09:11, 7 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Defining a process for the discussion of making Vector 2022 the new default

Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default on desktop across all wikis, including English Wikipedia. The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector. We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more. The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

Making this change is important for both readers and contributors.

We need your help and feedback on how to proceed. We have two requests:

  1. We need to talk in a way that works well for the English Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
    1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on English Wikipedia
    2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
    3. Before the deployment,
      1. Banners announcing the change will be displayed for logged-out and logged-in users
      2. The announcement will be made both on the Village Pump as well as in the Tech News.
    4. We proceed with deployment once the agreed upon fixes are ready.
  2. We need to understand the perspectives of different parts of the English Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the English Wikipedia community? We would like to have an open discussion, but are open to other forms such as requests for comments, office hours dedicated specifically for the English Wikipedia community, or guest presentations at community meetings. If necessary, we can also adjust the timeline of conversations based on your needs.

We welcome your replies here, or via email (olga@wikimedia.org, sgrabarczuk@wikimedia.org), as well as during our next office hours (26 July).

Thank you for your time and help. OVasileva (WMF), SGrabarczuk (WMF) (talk) 12:05, 13 July 2022 (UTC)

The comments from jawp above suggest that this change may not be entirely uncontroversial, with some editors feeling that it is not an improvement. Will enwp be allowed any say in whether the change is rolled out at all, or is it being imposed with our only input being into the details? Certes (talk) 12:48, 13 July 2022 (UTC)
No matter what change, there is a guarantee that a certain amount of people will not feel like it is an improvement. That in itself is a very bad metric for decision making. Are the points being made valid, is there an opt out, what other problems are we solving and are the people responding an accurate representation of the larger group of users. Those seem like much more critical questions to me. —TheDJ (talkcontribs) 13:08, 13 July 2022 (UTC)
I didn’t like it at all when I tried it, but I’ve been won over after spending some time with it. Doug Weller talk 13:14, 13 July 2022 (UTC)
Is there a list of blockers that are being accepted as blocking tasks right now?
  • I think the table of contents handling parts are the biggest problem right now. We currently have a lot of control over the TOC placement and display, which seems much harder or impossible with vector-2022.
  • Personally, I think with our "wide vector-2022" gadget option being an option for editors, general editors may be OK -- if we can ever get control over what is going on with the left sidebar - it comes, it goes, it is hard to control.
xaosflux Talk 13:08, 13 July 2022 (UTC)
Here are 2 examples of the sidebar with the wide gadget: an article that doesn't for a TOC, and article that has a displayed TOC. In the later, the entire sidebar will collapse, but only at certain display sizes, there is a task out there about being able to collapse the TOC - but very notably, even when collapsed that sidebar stays open an empty. Is the "grid" work going to address that at all? The sidebar element seems to be part of the content container. — xaosfluxTalk 13:11, 13 July 2022 (UTC)
I quite like the wide-vector-2022 layout and I'm sure I could be won over after a few weeks of it being the default. I think I'm in the minority when I say I like the ToC positioning on the left (but only on wide-vector). I strongly dislike the normal (non wide) version of Vector 2022, and I've left comments here on why this is. As for the OP's question: I don't think enwp will take kindly to a discussion about setting Vector as the default while these issues of narrowness, ToC placement, and unnecessary top banner whitespace exist. Anarchyte (talk) 13:31, 13 July 2022 (UTC)
I don't hate the side-bar based TOC in vector-2022 (even with wide mode) - I mostly hate that when all the sidebar elements (toolbar, and hopefully soon to be TOC) are collapsed or docked, that the sidebar can't be collapsed without also adding in javascript hacks - I'd think this should be possible with css and a layout that allows it to widen if there are contained elements pushing the margin. — xaosfluxTalk 13:38, 13 July 2022 (UTC)
Hiding the TOC and then regenerating a custom TOC (as in this article does achieve what I'm looking for I suppose - not sure why that is so hard? — xaosfluxTalk 13:42, 13 July 2022 (UTC)
Perhaps something the team could look into could be having the __TOC__ magic word forcing the TOC to exist within the page instead of in the sidebar. Anarchyte (talk) 14:38, 13 July 2022 (UTC)
Hey @Xaosflux - thanks for the feedback, and quick answer to the sidebar question (I'll follow up on your other points around magic words a bit later). Once the new ToC collapsing behavior is ready (phab:T306660), the gadget should work again to stretch the full width if both the sidebar and the ToC are collapsed OVasileva (WMF) (talk) 13:37, 15 July 2022 (UTC)
@OVasileva (WMF) thanks, looking forward to trying that out - I think it will at least alleviate some worry for logged-in-editors that have concerns about "too narrow" - likely some of the more heavy power editors that are using wide desktop monitors, I don't think it is a big deal for casual readers. From initial notes below, seems like the loosing control of Table of Contents styling in general is at least an emerging concern among editors - I'd hate to see ugly hacks get pushed by the community if there is an impasse (like the continuing problems going on in Wikipedia:Village_pump_(proposals)#RfC:_Showing_Editnotices_to_mobile_editors below with Mobile Front End and developers preventing certain elements from being controllable). — xaosflux Talk 13:52, 15 July 2022 (UTC)
  • Regarding TOC handling in general, for example in these articles editors have specified a custom right-sided TOC, which vector-2022 overrides. — xaosfluxTalk 13:34, 13 July 2022 (UTC)
    It seems quite inconsistent though, see this article in vector where editors have determined the best TOC layout type, compared to it vector-2022. — xaosflux Talk 13:46, 13 July 2022 (UTC)
    I think the primary reason we have customized TOCs is when they are very long. Of the most common variants, the floating variants ({{toc left}}, {{toc right}}), {{toc limit}}, and {{horizontal toc}} all exist to deal with a long table of contents. General point: except for people who customize their skin selection away from Vector22, I don't think we need to support these at all in the new skin. We can leave the templates alone right now for those people who do use the other skins, if we want. Specific points:
    1. Floating variants: simply don't care
    2. Toc limit: With a per-level collapsible table, totally obsolete.
    3. Horizontal toc: Maybe the only interesting one, since its major use cases are 'letter/number-driven' lists and large categories, and I expect that a TOC that long will be rough on the sidebar version (I haven't checked yet). I think there's probably a feasible feature request somewhere regarding category tables of contents.
    I think forcing the TOC to appear in page besides maybe that last one isn't needed at all (and I don't think that needs anything more than the customization we can already build with a template). Izno (talk) 19:59, 13 July 2022 (UTC)
phab:T306246 was mentioned above in #Consultation on Search improvements by CX Zoom and Ahecht and myself. That must be solved, and not by updating documentation, declaring it not a bug or closing it as a duplicate of $random other task. (I occasionally see tasks getting closed without a real solution so I'm just saying) I see plenty of open tasks on phab:T309972 so there's plenty to do. From a UI perspective, I suggested some improvements on phab:T302641, that alone is a hard deal breaker to switch for me personally. Alexis Jazz (talk or ping me) 20:31, 15 July 2022 (UTC)
@OVasileva (WMF) / @SGrabarczuk (WMF) - I think the entire design/implementation/documentation/testing about page meta-content and collisions with content things like our "coordinates" templates (see also -Wikipedia:Village_pump_(technical)#Coordinates_in_Vector_2022, phab:T292617, and phab:T281974) may be a bit of a blocking issue here - seeing as we make use of these features on literally millions of pages. I fear there seems to be a bit of tension in layout/design goals between skin developers and community use. What are your thoughts on the best way to reconcile these sort of things? — xaosflux Talk 12:41, 22 July 2022 (UTC)
Visual Editor is still in beta as of July 2022

SGrabarczuk (WMF), if you choose to make this change, it will be important to the success of the change to have a team of developers available to monitor forums where bugs and feature requests are reported, create phab tickets actively, and resolve those tickets quickly. Too often, new features are rolled out in beta form (I'm thinking especially of the Visual Editor) and then the development team appears to move on to new projects, leading to bug reports that linger for years (I'm thinking especially of the Visual Editor). I encourage you to designate a place local to en.WP, de.WP, Commons, and other large MediaWiki installations, where editors can report problems without having to travel to unfamiliar sites with different interfaces and watchlists, like mediawiki.org. – Jonesey95 (talk) 14:38, 13 July 2022 (UTC)

Hi @Jonesey95. Oh, that's a very fair comment. I'm giving a bunch of quick replies to different parts of your comment. I hope these bits make sense together:
  1. VE was launched, correct me if I'm wrong, like... 9 years ago? we've learned a lot since that. For example, earlier this year, when planning the current Californian fiscal year, we decided that we would dedicate some time this summer and fall (the first months of the fiscal year) just to further improve Desktop Improvements if needed. So that part's safe, not only in our hearts, but on the governance level, too.
  2. As a result, some bugs and feature requests will definitely be handled. Depending on how much related to Desktop Improvements, these will either be just done or considered as part of future projects.
  3. Vector 2022 is the default on ~30 wikis. On a few of these, incl. French Wikipedia, it has been the default for almost two years! So they've done a great deal of bug-reporting/feature-requesting already. I think both our team and other communities may be truly grateful for that.
SGrabarczuk (WMF) (talk) 15:04, 13 July 2022 (UTC)
Thanks. I wish you luck. If all goes well with desktop improvements and the developers find that the set-aside time is available for other work, maybe some of the team can work on the VE backlog and officially get it out of beta status. A bunch of us gnomes who clean up errors that it generates would be very grateful. – Jonesey95 (talk) 15:52, 13 July 2022 (UTC)
?? "Vector 2022" has been the default on frwiki since 2020? Does it have time traveling properties? — xaosfluxTalk 18:22, 13 July 2022 (UTC)
@Xaosflux, you are kidding, right? Let's make it clear for everyone around: back then, it wasn't labelled as "Vector 2022", but it was there. We've been adding more and more features and changes, but the first ones (different logo, collapsible sidebar, limited width) have been the default on some wikis since July 2020. SGrabarczuk (WMF) (talk) 19:11, 13 July 2022 (UTC)
@SGrabarczuk (WMF) Yes, that was mostly humorous, just contrasting that the entire current incarnation it hasn't had 2 years of bake-in. — xaosfluxTalk 19:17, 13 July 2022 (UTC)
Yeah, right. It's a good opportunity to make it clear that this interface isn't static, really. These incarnations are like ogres - both have layers. Some are two years old, and some (like the sticky ToC) are two months old. The older a layer is, the more people have actually used it, noticed bugs, advocated for improvements, everything. It's not like we're pulling Vector 2022 with everything about it out of a hat. I hope it's reassuring. SGrabarczuk (WMF) (talk) 19:29, 13 July 2022 (UTC)
Jonesey95, to sober up here's Growth-Team's profile on Phabricator. Two projects in active development, one project with a new owner and 11 projects with "passive maintenance" (read: unless the building is on fire expect nothing) with the note "New owner needed". Probably just some obscure projects, right? Yeah, it's just WP:WikiLove, WP:Echo, WP:Thanks, WP:Nuke, WP:Page Curation, Special:RecentChanges. Not anything people really use, you know. Alexis Jazz (talk or ping me) 21:03, 15 July 2022 (UTC)

I suggest having a page somewhere that essentially functions as a press release and/or a list of FAQs. At the miminum, link this page in the banners (i.e. with a CTA: 'Read more about the upcoming change!') so that 1. non-registered visitors can read more about the impending changes (and possibly encourage them to register as editor even if it is just to revert back to the previous skin); 2. interested publications may organically pick it up as a story for their audience. – robertsky (talk) 18:08, 13 July 2022 (UTC)

Great idea, @Robertsky! We're working on a page on wikimediafoundation.org (for readers, media, the "general public"), and we'll definitely have a more detailed FAQ for editors. SGrabarczuk (WMF) (talk) 18:18, 13 July 2022 (UTC)
I'd recommend that said press release/FAQ page should also include instructions on how to revert back to the older vector skin. I imagine that there will be a fair few (including myself) using the current vector who would like revert back to the older form, and while I know how to switch skins, there are some who may not be familiar. Hog Farm Talk 19:58, 13 July 2022 (UTC)

For this change to be a success you can't just impose this on enwiki; you need consensus from the community. Are you willing to open an RfC that seeks to obtain consensus to implement this change? BilledMammal (talk) 21:25, 13 July 2022 (UTC)

@BilledMammal, I think the proposal pretty much answers your question. Let me rephrase a part of the first message: in the next conversation, we'd like to talk what remains to be done instead of having a yes/no situation. And we do mention RfC there, too. SGrabarczuk (WMF) (talk) 22:36, 13 July 2022 (UTC)
Your comment comes across as if this is a done deal, with only small details (what remains to be done) to be worked out, but the community needs to be able to reject this. It needs to be able to say that it is not satisfied with the current version of Vector 2022, and instead ask you to come back and see if consensus has changed when you believe you have addressed the objections raised in the discussion.
To rephrase my question; are you willing to open an RfC that seeks to obtain consensus to implement this change, with an option that will permit the community to reject the change? BilledMammal (talk) 22:53, 13 July 2022 (UTC)
+1 to User:BilledMammal's comment. In that vein: Consider me an Oppose to switching the default. On my screen at least, V2022 has a very poor layout that looks unclean and would create a poor impression of Wikipedia, forced upon us by the WMF. I want to see a finished product before everyone without an account (that is the majority of users) are suddenly switched to a new (worse) look. Happy Editing--IAmChaos 21:44, 13 July 2022 (UTC) edited 01:50, 14 July 2022 (UTC)
We believe this change is extremely important for readers, and have a lot of data and research that can help us prove this. That said, we understand that that community might need more from the skin than what is currently developed. That’s why we hope to get into the details so we can identify what needs to be changed before the conversation on whether and when that change will happen begins. That said, to be clear, we will not be rolling out the new skin prior to coming to such an agreement with the community. SGrabarczuk (WMF) (talk) 16:46, 15 July 2022 (UTC)
@SGrabarczuk (WMF): Thank you, I am glad to hear that. Are you able to provide us with the data and research reports so that we can consider this change in that context? BilledMammal (talk) 22:35, 16 July 2022 (UTC)
@BilledMammal see § UX research and usability testing below. There's a great deal available there and at other pages, so please specify what else you're seeking if you'd like additional research. {{u Sdkb}}talk 22:40, 16 July 2022 (UTC)
Thank you, I missed that. BilledMammal (talk) 02:13, 17 July 2022 (UTC)
@IAmChaos Olga and Szymon explicitly structured this conversation as a meta-conversation about process, not a !vote on implementation. Let's respect that by avoiding bolded !votes, just as we do at VPI. {{u Sdkb}}talk 23:02, 13 July 2022 (UTC)
I appreciate that. I will unbold. Happy Editing--IAmChaos 01:50, 14 July 2022 (UTC)

I think just waiting until the "final" release version is ready and usable before starting any discussions on adding it is best. While prototypes are still ongoing it isn't great to start any discussion on a non "final" version when signficant changes can still occur and the outcomes on changes are not released. Using the latest prototypes: Color schemes, borders, toc highlighting & logo choices should be able to be viewed at the point the discussion starts rather than lumped in at the end and not allowing anyone to voice their opinions on these choices specifically isn't a good idea. Terasail[✉️] 22:02, 13 July 2022 (UTC)

@IAmChaos, @Terasail, we're not there yet. Please take a look at the proposal. You'll find the replies there. We don't have a definition of a "good enough" product. (In a way, it will never be quite "finished", just as most Wikipedia articles never are.) We'd like to make it together with the community, and now, we're asking how do you think we should do that. SGrabarczuk (WMF) (talk) 22:34, 13 July 2022 (UTC)
It sounds like this product, if approved, will see regular releases. Will these releases also be discussed with the community or will they be boldly implemented? BilledMammal (talk) 22:58, 13 July 2022 (UTC)
@BilledMammal, I'm not sure I understand your question. What do you mean? Could you elaborate on that? SGrabarczuk (WMF) (talk) 23:26, 13 July 2022 (UTC)
@SGrabarczuk (WMF): If I have understood you correctly this version of Vector 2022 is not the final version; instead, it will see regular significant updates. My question is what your process for implementing these updates will be; will you do them boldly or will you discuss them with the community first?
In some ways, this question is related to my question above from 22:53, 13 July 2022, which I believe you may have missed. BilledMammal (talk) 00:58, 14 July 2022 (UTC)
Thanks for clarifying your question! What we mean when we say that this is not the final version is:
  • We still have some identified issues (documented as tasks) that are not resolved. This is the list that is under this task.
  • The two-week conversation we're proposing would be meant to help us define the version upon deployment. We need agreement between our team, the needs of readers, and the community in the identification of what their needs from the skin are. What are the blockers to changing the default? That is the conversation we are currently trying to set up.
  • Once deployed, we plan on continuing to work on the desktop experience. Our next focus will be on improving some of the features we’ve built here, but also using some of the things within the new interface to begin exploring goals that are even further-reaching, such as encouraging more interested readers to begin editing. With Vector on most Wikipedias, we didn’t change the skin for 12 years. This project, while improving usability for existing tools, did not add or remove any current tools from the interface. Once it’s done, it gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is a process that is ongoing and will be done with the feedback and collaboration of the community here and across other projects.
SGrabarczuk (WMF) (talk) 17:18, 15 July 2022 (UTC)
Thank you for clarifying this as well. I am glad to hear that you will seek input and hopefully consensus from the community before implementing any significant updates. BilledMammal (talk) 22:35, 16 July 2022 (UTC)
@SGrabarczuk (WMF) Firstly, thanks for your reply, I appreciate you being willing to answer so please don't feel like I'm jumping on you specifically, its just that you brought this here and I figured I should voice my concerns with a switch to V22. @Sdkb replied to my earlier comment, and I agreed so I modified it with their suggestion. I strongly believe though, even in this so called "meta" conversation about process, we shouldn't be ignoring the issues. Logged out editors are the most populous user, even though they have practically no voice in ProjectSpace discussions. If we are to implement a change to what they see (ie default settings), we need to address this more than other things, because those affected won't discuss it. Here's a quick list of what I've found.
  1. The TOC issues. They are being overriden against specific decisions by editors who chose to design a page a certain way. for example, see Alien, which is the first page alphabetically that uses {{TOC right}}, why should V22 override, there is no precedence in monobook, timeless, minerva which are the other skins installed on enwiki. I think overrides like that (and there may be others, this is just what I have seen conversation about above) should fall to editors, not to software.
  2. The look of it. Not to be mean to the team who worked very hard on it, and I appreciate what you've done for the MediaWiki community, but I feel that there are (in the current state) some things objectively worse. Why is there just blank space to the right of articles when V(legacy) reaches the edge of my screen? Why is there space blank to the left of the sidebar that is just white? The sidebar is highlighted in gray which only makes the large blank more obvious.
  3. In a similar vein to the blank space - the bar across the top is unbalanced - The user icon is all the way to the right over the blank space, but the arrow on the left is indented like the sidebar, it looks unbalanced.
  4. This one is a much more niche issue - and probably one that you will never work on (and don't need to at least for enwiki), but for a user such as myself who has a long sidebar - multiple scripts add links to mine, the TOC is impossible to find for multiple sections - for example on Butetown - I have scrolled down to section 4 (#Welsh language) before the TOC is caught up with me. This may be a concern though for other projects that have added links to their sidebar, such as my private mediawiki site, which has many sidebar links for my convenience.
On the note that I have now spoken about your hard work in a less than stellar light, I again apologize if I came across as harsh, but these are things that I feel need to be addressed before such a big switch for such a prominent website in today's world. Again, I don't want to come across as rude, but I feel we shouldn't rush into this, and that as sdkb called it, the 'meta-process' should include the community's voice on the actual skin itself, and how it could work for enwiki, instead of just how it will be rolled out. (full disclosure: I havent looked at the deployment blockers you linked, because that's a long phab list, and I still don't quite understand all the lines on it, but I will and am open to the possibility that there are other concerns that are more pressing or maybe I'm a complete minority opinion.) Happy Editing--IAmChaos 02:20, 14 July 2022 (UTC)
I find myself agreeing with you here, particularly on aesthetic grounds, where it looks almost amateurish to me. I have not yet had the time to introspect on why I’m receiving that impression (perhaps I’ll update this later though), so take my take with a grain of salt. I definitely think it’s important not to rush this, considering the extreme outsized effect UX design seems to have on people. Yitz (talk) 03:29, 17 July 2022 (UTC)
@Yitzilitt, thanks for mentioning the aesthetic aspect. Look at this page. We simply haven't built that part yet, because we've been focused on changing the features. We'll implement the visual changes in the next couple of weeks. SGrabarczuk (WMF) (talk) 15:48, 18 July 2022 (UTC)
Hey @IAmChaos — thank you for your feedback, and apologies for my delayed response. We appreciate your honesty here.
Regarding your comments about whitespace and the look of Vector 2022: I’m curious if you have been able to take a bit of time to sit with the new skin, and if so, if that has changed any of your opinions so far? The reason why I ask is: several editors who have given feedback and collaborated with us over the past two years have initially disliked Vector 2022 (often for similar reasons), and then after a few weeks of using it they have come to appreciate the changes that have been made, and even ended up liking it more than legacy Vector.
Some design-specific notes regarding the whitespace: the majority of research on readability and reading comfort over the past ten years have concluded that limited line-length, and whitespace surrounding the text, are critical to a good reading experience (more info here). So we started by limiting the line-length, which ultimately leads to limiting the width of the entire interface (otherwise we would end up with even more whitespace). I know it’s a big adjustment, and it feels like there is a lot of “wasted” space. Fortunately there are several community members who have already begun to develop scripts and gadgets to address this, resulting in a more dense version of Vector 2022 (we were joking that it’s kind of like Monobook version of Vector 2022). You can find those gadgets and scripts here. From a process standpoint: the layout has been worked on and reviewed extensively by the entire WMF design team, supported by the majority of community members who have given feedback over the two year development process, and proven via testing to work better for both logged-in and logged-out people in various ways. So while it may not look aesthetically pleasing to you at this time, we wonder if you can go more in depth in terms of what makes it objectively worse. I am of course happy to discuss these topics further with you.
Regarding your comment about the long sidebar pushing the table of contents down the page: fortunately this is a functional issue so it is easier for us to discuss and agree on. In case you have not yet seen it I invite you to first look at our latest prototype here: https://di-collapsible-menus.web.app/Flamingo. You will find that with the tools menu moved to the article toolbar the sidebar becomes much shorter (and please note that the tools menu is able to be pinned to the right side of the article for immediate access upon page load). Secondly, due to the infrequent use of the remaining items in the main menu, we expect that over time most logged-in people will discover their experience is improved by collapsing the main menu (allowing for immediate access to the table of contents upon page load), and then opening the main menu when needed.
Thanks, AHollender (WMF) (talk) 23:27, 28 July 2022 (UTC)
Thanks for the reply @AHollender (WMF). I have looked a bit more, and noticed that I hadn't collapsed teh sidebar which addressed part of my issues mentioned above - particularly the long sidebar hiding the TOC. I will definitely look into the research on readability, I personally find it disconcerting as the software used at my day job is chock full of information too all four corners of my work desktop, all of which I need access to, so maybe it's a bit of Status quo bias in my comfortability with a crowded workspace, but I feel like after looking around there are a few places I don't quite feel fit together right. As for an example where it doesnt match up well: Clicking on Special:Random today brings me to an article in V22. The Categories box is the width of the article, followed immediately by a horizontal line the width of the screen and the footer info is full width across the bottom. I will definitely be looking into the community scripts with density, thanks for the link. Happy Editing--IAmChaos 03:46, 29 July 2022 (UTC)
Hey @IAmChaos — ok right, so this is related to your earlier comment about the width of the header. So how we've currently setup the page layout is:
- there's a max-width for the entire interface, which is currently 1514px. This is the max-width that the site-header, sticky header, and footer all have
- there is a max-width for the content, which is currently 1244px for pages that have a table of contents, or 960px for pages that do not. Again, this max-width is the result of first establishing a comfortable line-length for the article text, then finding a reasonable width for the table of contents. Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced. To explain visually:
Currently this is the situation, with the blank space you're noticing called out in red:
Vector 2022 page layout schematic
However if your screen is less than 1325px wide (which most laptops are), there is no longer a blank space:
Vector 2022 page layout schematic (laptop screen)
Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced:
Vector 2022 page layout schematic (with page tools)
Unfortunately, aside from having the tools menu pinned, there's not really an easy way to make these max-widths match. The easiest thing to explore would be limiting the max-width of the site header to 1244px. However if we did this, and then you decided to pin the page tools, the max-width of the site header would have to change in order to stay aligned.
I hope this is helpful. I can promise you that we are also concerned about possible imbalances in the page layout, are keeping a close eye on this, and are on the lookout for opportunities to achieve better harmony. Your comments are super helpful to us as we continue to explore our options here. AHollender (WMF) (talk) 16:39, 29 July 2022 (UTC)
A request for comment is an open discussion. It's just an open discussion that is geared towards assessing consensus rather than discussing something in the abstract, or as in this topic, having a discussion where you create a plan. So a request for comment, which often runs for 30 days but can go shorter if consensus is clear or longer if discussion remains active, advertised on WP:CENT feels like the right way of having this open discussion with the enwiki community. Best, Barkeep49 (talk) 01:34, 14 July 2022 (UTC)
One extra thought. If there's a sense that consensus might be initially hard but there's a courage of conviction that the skin will genuinely help, some sort of testing, whether through a trial period (owing to enwiki's massive reach lots of data can be collected in shorts period of time), or through A/B testing, with clearly defined metrics could lead to a consensus that wouldn't be there without that data. This is something the Growth Team has done to large success. Best, Barkeep49 (talk) 01:39, 14 July 2022 (UTC)
I like a lot of what Skdb has said below, particularily that it will be an uphill battle for it to gain acceptance. Another factor is that the enwiki users being asked what they think about the change would generally be the heaviest users; casual readers won't see any future RfC's. These users are probably most accustomed to Wikipedia's current look and would most likely be relatively quick to oppose in my opinion. I also think that starting an RfC about 'Should Vector 2022 become the default after it is modified' (so that the RfCs aren't forcing the community to do things and don't have that appearance, also forestalling complete skin opposition in other RfCs) and then following up with one about 'what should those modifications be' could be a good idea. That assumes the community would reject the skin in its current form. —Danre98(talk^contribs) 00:05, 15 July 2022 (UTC)
I would second both thoughts by Barkeep. Specifically, (1) a full 30-day policy RfC, listed on CENT and following the requirements of WP:PROPOSAL, is the gold standard and the only realistic path to legitimacy for such a large change. (2) The change is much more likely to gain consensus with solid supporting data from A/B testing. Best, KevinL (aka L235 · t · c) 00:39, 15 July 2022 (UTC)

FWIW, I am a moderate user (just under 10 edits per day average over the past year, but with over 5,000 pages on my watchlist). After using Monobook for many years, I switched to Vector 2022 a few months ago. It felt a bit wierd at first, but I am now quite comfortable with it. Of course, you are much more likely to hear from users that don't like it than from the rest of the spectrum of user reactions. - Donald Albury 15:56, 15 July 2022 (UTC)

Agreed. Doug Weller talk 17:24, 15 July 2022 (UTC)

Re BilledMammal, Barkeep49, IAmChaos, Sdkb comments on this page about consensus...YES. Changing the editing experience by default for Vector 2010 users without an Opt in....not my favorite and would probably guarantee a strong blowback. Changing the editing experience around here is always fraught with challenges and difficulties (Yeah, VisualEditor...), the chief among them, for me at least, is that I am an editor. I am not someone who approached Wikipedia editing from a developer/programmer/coding/data point of view, I'm just an editing/researching/writing fool and I think there are many of my kind amongst named Wikipedia accounts. I just stumbled upon this discussion by accident and probably wouldn't have known that a change was coming/had been instituted until it happened...
And a plea for the future... If the Vector 2022 skin comes online can we please have clear/easy-to-understand Opt-Out instructions? Maybe have them come up for six months afterwards for Vector 2010? Maybe have an Easy-to-find/Clearly-labeled FAQ for the changes and for Opting-Out? When the "Section edit/Reply to individual posts" change came online recently (I'm sorry but I can't quite remember what the name actually is/was) it was Not Easy to find how to disable/Opt-out from the change. Heh, at least it was not easy for me and I have over 35K posts... That's about all, I'll try to keep up and follow this discussion so it won't be another Big Surprise to me. Shearonink (talk) 17:01, 15 July 2022 (UTC)

Hey @Shearonink, first of all, I understand you. I became a Wikipedian years before I was hired by the Foundation. I personally, as well as other staffers at the Foundation, know that there are thousands of people not editing every day, not engaging in the Village Pump discussions, and finding it difficult to adjust to technical changes impacting the editing experience. So the link to opt-out is and will be available in the Vector 2022 version of the sidebar (left menu). As we wrote, we are also thinking about putting up banners before the launch. SGrabarczuk (WMF) (talk) 17:46, 15 July 2022 (UTC)
It is unfortunate that the en.wiki editor community has been determined through all obstacle to keep this embarrassment of a UI stuck in the year 2001. Despite many excellent proposals for reform of the Main Page, it remains a dull and outmoded layout; the left sidebar is cluttered and unusable by all who have not become accustomed through years of use to its contradictions. Here we have a vector that is far more modern, far more intuitive and far more pleasant for readers—the only problem is that editors who have been here for many years can't possibly approve of it because they've optimised their workflow within the current janky hackjob we have, and the slightest change threatens that.
There are suggestions for changes to the skin that would be useful, but the website's design should not be motivated by the navel-gazing within the editor community. It is apparent in many editor discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile. There are discussions for us to have on what the new layout will mean for ToC placement, but we cannot hash out every small detail before first agreeing the adoption of the new layout. There are complaints here about interaction with gadgets and Javascript: this means that those bits of code need to be changed, not the website layout. Many of these gadgets are operating under UI assumptions that are not some functional specification guarantee.
We should not hold back on improvements due to complaints of a vocal minority, but go forwards with the quantitative testing-approved solutions to the problems identified by readers and editors (see below for the WMF's explanation of each stage of this project). — Bilorv (talk) 20:46, 16 July 2022 (UTC)
discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile - It's possible to give different views for mobile and desktop readers; I don't think we should be catering for mobile to the exception of desktop. I also note that even the current mobile view is less than ideal; I switch to desktop view when reading from mobile because even there it is easier to read the article in that format. BilledMammal (talk) 22:40, 16 July 2022 (UTC)
I think you've missed my point, BilledMammal, perhaps because I didn't make it clear enough. The issue is not that desktop layout doesn't matter, or that making a good desktop layout contradicts making a good mobile layout. It's that editors generally consider their own layout only (often a desktop layout and specific browser and specific skin) and give no thought to other layouts. As editors, we should be thinking as much about mobile (or more!) as about desktop. But we don't, and that is one example of how editors are not the best people to consult about UI changes. — Bilorv (talk) 08:03, 17 July 2022 (UTC)
Ah, I see what you are saying now - I fully agree, we do need to consider this on a variety of platforms, and even if it isn't currently suitable for all platforms it may be suitable for some. Below, I have actually asked for some data to be presented separately for desktop and mobile users. BilledMammal (talk) 02:53, 18 July 2022 (UTC) Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)

Sdkb comments

I've been following/commenting on New Vector throughout the development process and have a lot to say here, so with apologies in advance for the length, I'm creating a subsection.

@SGrabarczuk (WMF) and @OVasileva (WMF): In some other circumstances, I've encouraged the WMF to plunge forward with seeking consensus for deployment, even though development isn't yet complete. My advice here is the opposite: we're not ready for that conversation yet. Users of any site are inherently biased against redesigns, and with Wikipedia's community consensus model, that gives you an unenviable uphill climb if you wish to succeed where past efforts have failed. Because of this, there will be a certain level of guaranteed opposition, and to overcome it, you'll need the design refined enough to get every winnable editor on your side. New Vector has improved a lot over legacy Vector, but I don't think it's at that point yet.

Some of the changes are fairly simple things. For instance, looking at the ToC to the left right now, it ends a ways before the bottom of the page, resulting in an ugly scrollbar that likely could've been avoided if it just extended the full vertical length of the page. Making refinements like that will help avert a gut "this is ugly" reaction and could making the difference between consensus and no consensus.

Other changes are more fundamental. The reduced screen width is something I'm fairly used to at this point, but it seems to be a sticking point with many others. Given that, I think you need to decide how many of the New Vector changes are segmentable. I.e. if the community says "we're okay with everything in New Vector except the screen width" or "we're okay with everything except the ToC", will you be able to implement that? I know you'd prefer to be able to implement everything, but if it has to be an all-or-nothing decision it'll make your task all the harder, because opposition to any one element could foil the entire proposal. So I'd put some thought into what can be segmented out vs. what has to be bundled.

On the ToC, getting it to display so that it doesn't require scrolling in normal cases, even when the main menu is uncollapsed, is something that I predict will be crucial for getting community buy-in. We've been discussing it on MediaWiki, so let's continue the conversation centralized there.

Lastly, I'll reiterate that I think that the upper right corner is going to be a sticking point. We've previously discussed (with Izno and others) how the decision to commandeer that spot for the language switcher appears to have been made based on user research that began with the baseline assumption that making it more prominent was an inherent good, ignoring the other elements that currently occupy that space and that are also important. In your most recent newsletter, you write that the page tabs/title switch moved the language button into an even more prominent position at the top of the page, once again making this assumption, and once again ignoring that you're pushing the other elements down yet another row. When we've brought up those elements, namely coordinates and good/featured article icons, you've declared them out of scope for your project. I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to? Helping readers understand through the site design which articles have undergone a peer review is absolutely crucial for information literacy, and I really wish you'd convene one of your focus groups to understand whether they have any clue about GA/FA currently (my guess is no) and, if not, what can be done through design to fix that (my suggestion is moving them left next to the article name).

If you manage to address these sorts of things, I think it'd be possible to start a productive conversation on making New Vector a default few months from now. That conversation could incorporate multiple steps as you suggest, and it'd probably best take the form of a CENT-listed and watchlist-advertised RfC. If you start it prematurely, though, I think the combination of reasonable and knee-jerk concerns will result in failure to reach consensus, which would set you back. (And I hope it goes without saying that attempting to push through the changes without community consensus would result in a Framgate-level firestorm.) Cheers, {{u Sdkb}} talk 00:34, 14 July 2022 (UTC)

@Sdkb Thank you for your thoughtful reply and thoughts here, and for being super helpful and giving us feedback throughout the process! Apologies for the long response time - we’ve been monitoring this conversation and replying to quick questions, but wanted to sit with your comment for a little bit to make sure we can address all the points you raised. Here are some of our thoughts and answers - curious what you think as well:
  1. Thank you for flagging that you think the conversation feels a bit premature. We're very excited to begin bringing the changes to readers as well as to flag where the issues are early on, but agree that the next step would be to continue at a longer timeline than the three weeks we had originally suggested. We would like to continue the conversation by identifying which blockers we have for deployment, making sure that our understanding of “finalized” matches that of the community here. In future iterations of this conversation, we’ll also make sure to highlight this point so as to avoid confusion.
  2. ToC issues. Just adding note here, but also agree we can continue discussing in the other thread - sorry for the repetition! We’re currently working on some improvements to the ToC for narrow screens, tracked in phab:T306660 which we hope to have live next week. In these, we have improved the styling of the ToC so that the scrollbar does not appear unless actively scrolling - I agree it’s pretty unsightly. Does that alleviate your concerns somewhat? In the future, after the deployment, we plan on separating more tools out from the main menu, such as the page specific tools. These changes will also allow all menus to be individually collapsible and can also serve as the first step to a more highly customizable system. They will also shorten the main menu significantly. That said, as these changes are pretty technically significant, we would like to confirm the plans for the new default before beginning this next part of our desktop development.
  3. On the reduced width - I agree this is tricky. We do have some capability to offer customization, but this becomes more difficult to maintain and test with every option we add. To us, the best case scenario would be to continue to promote the use of individual gadgets and scripts among editors, but if this is deemed insufficient, we can begin scoping out a potential setting for logged-in users. That said, it’s probably not something we’d be able to offer for every feature - it would depend on the request, how difficult it would be to maintain, and how independent it is of the other changes we’ve introduced.
  4. Coordinates and upper-right corner issues. This is a priority for us right now as well. In terms of the prominence of language switching - getting higher priority for languages is an important aspect of the project’s goals which are to focus on growing our readership and communities globally. This includes an enormous audience for whom language switching is crucial, and who tend to use a global language, such as English or French, in addition to their local language, for learning on a daily basis. We want to make sure we’re taking their needs into account as much as those who are native speakers. That said, we need to make sure the other elements like indicators and coordinates work well with the new location. This has been tricky as the location of these has traditionally been in the hands of the community. Our view on this is that the order should be as follows (vertically): language button, tabs, indicators and coordinates. Indicators and coordinates should appear on the same line and preferably, coordinates would be treated as indicators. We'll be adding some more thoughts and hopefully some ideas for next steps on the current conversation in VPT.
Hope this is helpful! We’ll continue getting into the details on the individual threads as well, but can also definitely keep talking here too. Also we hope to post a longer response to everyone that’s been involved in the conversation here later today on the next steps in the process. OVasileva (WMF) (talk) 12:27, 27 July 2022 (UTC)
@OVasileva (WMF), thanks for the reply! On the ToC scrollbar, it's not the scrollbar itself that's ugly so much as the fact that you have to scroll to see the full ToC. The entire point of a ToC is to let you see a summary of a page without having to scroll through it all, so if you can't do that, why have a ToC at all? This is certainly an issue for larger articles or talk pages. One possible solution to explore is having the ToC width double when you hover the cursor over it so that less needs to go onto two lines; does that make sense as a concept? {{u Sdkb}}talk 04:12, 29 July 2022 (UTC)
I think that spacing the TOC entries out less would be a good idea as well. The current TOC is just a bit too "fluffy" in my opinion. CactiStaccingCrane (talk) 04:14, 29 July 2022 (UTC)
Hey @Sdkb - thanks for replying to the reply! You bring up a good point. Hovering on the ToC is something that we had initially explored in our first prototypes which we tested with groups of readers and editors in English, Spanish, and Indonesian (more details on the report page). However, we saw that across all groups, people preferred having the ToC shown in full without having to take an action (such as hover or collapse) to view it. So we decided against it and opted for maximizing the space within the sidebar instead to show as much of the ToC as possible. It's possible that later on, we can explore a more specialized solution for cases where line wrapping is particularly prominent (such as talk pages like you mentioned). For now though, I think the tradeoff of having the ToC available persistently is worth the introduction of scrolling in some cases. Our A/B test data came in recently and we're seeing a 50% increase in clicks to the ToC. We'll be monitoring this over time, but are really happy to see that it's helping people navigate back and forth across the page more. Next we'll be looking at the scrolling data - we hope to see a similar decrease in scrolling that we saw with the sticky header. OVasileva (WMF) (talk) 08:51, 2 August 2022 (UTC)

UX research and usability testing

Note, I am an engineer that uses terminals a lot and I still use the MonoBook skin. But, here's a question. If moving to the new Vector skin is controversial, why not commission and publish an extensive user-centered design case study to prove that the Vector 2022 is actually better. Then the community will have to see reason. (Maybe) Andrevan@ 03:23, 15 July 2022 (UTC)

Hey all,

A number of you have asked us about our research and testing (both Qualitative and Quantitative), so we wanted to write a pretty detailed and long comment to address this. We wanted to confirm that not only the Growth team conducts complex testing :) This is more like the standard for big projects now. Each feature change has gone through the process below (which we also described in the Signpost in April). This is what gives us the confidence that everything we have built so far is, in principle, an improvement. At the same time, we acknowledge that there's room for more adjustments.

  1. Problem identification research with both readers and editors - during this phase, in 2019, we studied the way people used the site and identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations. (See the links: Research and design: Phase 1, Research and design: Phase 2.)
  2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing solutions to our audiences. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. Generally, for testing with editors we used central notice across multiple language Wikipedias, including English Wikipedia, so that we can get the widest audience possible. Each prototype was tested by approximately 200 editors on average. (Example)
  3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback during this process so that we’re sure we’re making the right decisions.
  4. A/B testing and other quantitative testing on pilot (early adopter) wikis - we perform a quantitative test for whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that people who had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. This is the "beta" phase. During this phase, we also monitor usage across all wikis, including English Wikipedia, where many account holders are already using the new skin.
  5. Finally, we deploy Vector 2022 on more wikis and continue monitoring the way people are using it so that we can flag any issues. In this phase, Vector 2022 isn't "beta" anymore. It's more like a B-class article. Different wikis have different thresholds for B-class, and we believe that in the case of English Wikipedia, we'll be there when the visual refinements and other deployment blockers are ready.

We are currently working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to learn more about the testing is:

  • From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
  • Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

Just so we can have a short version of this as a part of this conversation, we're posting a quick list of our learnings:

Collapsible sidebar

The collapsible sidebar allows people to collapse the main menu in order to focus on reading - helping to find the information needed without distraction

  • Qualitative testing with readers and editors on the usefulness of the sidebar and our navigation. Our conclusion here was that the number of different tools provided on the page by default was found to be overwhelming by readers and actively discouraged them from reading, but also from exploring the functionality within the page, an effect opposite of what the exposure of multiple tools aims to do. More details can be found on our feature page for the collapsible sidebar, as well as within the original report
  • Quantitative testing on the usage behavior of the sidebar itself, in both its open and collapsed states (see the results). When using the sidebar, logged-out users are much more likely to collapse it and, once collapsed, to keep it collapsed. In addition, the rate of un-collapsing also indicated that users are aware that, were they to need to navigate to an item in the sidebar, that option was available to them.
Maximum line width

We have introduced a maximum line width to articles. Research has shown that limiting the width of long-form text leads to a more comfortable reading experience, and better retention of the content itself.

  • Our studies with readers showed that readability was an issue with the current interface, in particular being able to focus on the content
  • Pages that are not in a long-text format (such as diffs, special pages, page history) will be presented at full-width as before
  • Logged-in users who wish to read articles at full width are welcomed to set up a script or gadget that will allow for this, such as this one
  • For more details on research and motivation, see ourresearch section
Search

The new search widget includes important context that makes it easier for users to find the query they are looking for by adding images and descriptions for each search results

  • People had difficulties finding the correct result using our previous search
  • Our A/B testing showed that adding the new search can lead to a 30% increase in search sessions initiated on the wikis we tested
Language switching

The new language switching tools are more prominently-placed than before. They allow multilingual readers and editors to find their preferred language more easily.

  • Readers did not previously know they could switch languages from the page, even if they read multiple language wikis habitually. They would use external search engines to find the correct article instead.
  • In our user testing, new readers were able to find the new location much quicker than the previous location
  • Our qualitative testing showed that this was more difficult to find for existing users who were used to the previous location, leading us to iterate on the feature. We have since added a note in the previous location of the language switcher and made the button itself a more prominent color
  • In the future, we will continue exploration on languages, considering potentially a direct link to a person’s most frequent languages
(note to @Sdkb: we know you have some questions on language links that are still open - we’ll get back to you on these in a separate message)
User menu

The new user menu provides links to all links related to the user in one place. This reduces confusion between general navigation links and specific user links

  • New editors were confused between the links at the top of the page and other navigation. They didn’t know these links pertained to their personal tools
  • Our user testing with readers and editors showed that people found it intuitive that all user links are in a single menu and that the menu is easy to find
  • In our prototype testing, 27 out of 38 (71%) editors and other logged-in users showed strong positive experiences with the user menu
  • Based on community requests and current data, we iterated on the feature and moved the watchlist link out of the user menu for easier access
Sticky header

The sticky header gives access to functionality that is used most frequently that was previously only accessible at the top of the page. The goal is for people to scroll less and thus, save time

  • Our A/B test showed an average 15% decrease in scrolls to the top per session for logged-in users within the 15 pilot wikis we tested on

OVasileva (WMF), SGrabarczuk (WMF) (talk) 16:14, 15 July 2022 (UTC)

Thank you for posting this; there is a lot to read through so I have only reviewed two features so far, sticky header and persistent table of contents. For the latter, it appears you have yet to conduct A/B testing but when you do I would be interested in seeing data on the percentage of page views that involve at least one click on the table of contents, and the percentage of page views that involve at least two clicks on the table of contents. In addition, I would be interested in seeing separate data for mobile users and desktop users. Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)
For the former, I see you have already conducted A/B testing but there is some additional data that I would like to see:
  1. Currently, you show the clicks per session and clicks per page only when skinversion=2; I would be interested in comparing this to the clicks per session and clicks per page for skinversion=1. My hypothesis would be that the sticky_header makes it more convenient for readers to access these links, and thus increases the number of readers using them.
  2. The rate of accidental clicks. Assessing this would vary by link, but I have a few ideas and am happy to discuss further if required. My hypothesis would be that the sticky_header increases the number of accidental clicks, and we would need to consider whether this increase offsets the benefits of the sticky_header.
  3. Time on page, time on page when limited to pageviews that do not involve following a header link, and time on page when limited to pageviews that involve following a header link. Clicks on pages with stickyHeaderDisabled would need to be split between those that involve a scroll back and those that do not. My hypothesis would be that it does not affect time on page for readers who do not click on a header link, and that it has a small but relatively constant absolute decrease in time on page for readers who follow links on the sticky_header compared to those who scroll back to click on a header link. The former would suggest that this does not negatively affect the reading experience, the latter would suggest that that this has a positive effect on the reading experience for readers who are wanting to navigate to one of those pages.
Alternatively, is there raw data that we can look at from the A/B testing for the sticky header? I suspect it won't answer #2, but it may contain information on #1 and #3.
BilledMammal (talk) 03:33, 17 July 2022 (UTC)
@BilledMammal - thanks for your questions! You bring up some really good points that we considered during the design phase of the experiment. The full data analysis is available here: https://jenniferwang-wmf.github.io/Web_sticky_header/. In terms of your questions:
1. Comparing overall clicks. This is something we can look into and report back. The reason it wasn't a main goal for the A/B test is because we wanted to focus on decreasing scrolling (i.e. making the site easier to navigate by requiring less of the user) rather than setting a goal for increased interactions. As in, we would still consider the feature a success if people used the tools as frequently as they did before but had to scroll significantly less in order to do so. That said, I agree with your hypothesis that we most likely would see a significant increase in clicks as well.
2. Accidental clicks are a bit trickier to measure. Generally, with new features, we get a lot of clicks in the first day or so after deployment (which are generally more based on curiosity than accident). This is why we run our tests for an extended period of time - 2 weeks, to make sure it's sufficient time for people to get used to the new functionality and begin using it as they would naturally
3. We discussed looking at time on page at the beginning of the test but decided to look at scrolling specifically instead. While I personally believe that your hypothesis is correct, we've had some issues in the past with looking at the time on page metric and receiving conflicting data. For example - time on page may actually increase over time with the sticky header available because people would be less frustrated with not being able to access specific tasks and thus more open to spending longer on our sites overall. The same is true of scrolling - people might scroll more overall because the site is easier to use. This is why we specifically looked at scrolling to the top of the page as we thought it was the clearest signal that people are going there specifically to find one of the tools available in the sticky header. OVasileva (WMF) (talk) 09:06, 2 August 2022 (UTC)

Has anyone actually used the link given at the very top as "see what it looks like" on a smartphone? For me, instead of getting an encyclopedia article, I get a full screen with the sidebar and no encyclopedic content until I scroll down. Can other people please test this? Because this seems like a quite major bug or worse experience than the current mobile version. Fram (talk) 08:46, 17 July 2022 (UTC)

Same bug here but only if I'm using the mobile view in a browser. If I'm using the desktop view on mobile it works fine (and actually looks quite nice). With this said, it may be a non-issue as I've not read anything about mobile transitioning away from MinervaNeue. Anarchyte (talk) 09:01, 17 July 2022 (UTC)
FWIW, I see the same bug as Fram does, on both a Macbook laptop (not mobile) running Safari 14.1.2, and on an Android phone running Opera 69.3.3606.65458 in desktop mode. I just see a banner at the top, a sidebar on the left, and a big blank space on the rest of the page. I have to scroll way down past the sidebar before I see any content, and the content fills the full window width (that is, the sidebar is not to the left of the content, it's above it). There's also no visible TOC on the left side or anywhere, just a hamburger icon that I have to click on to open a TOC. I do not see this bug on Firefox 102.0.1 on a Windows machine. It seems there is still some browser dependency that makes this skin very unpleasant to use in some environments, and not only mobile ones. CodeTalker (talk) 00:51, 18 July 2022 (UTC)
Confirming I see the same thing as Fram in mobile view on Firefox 101.2.0 on Android 11. Desktop view looks intentional. Folly Mox (talk) 18:01, 18 July 2022 (UTC)
It looks great to me (tablet, mobile & desktop) if the sidebar's collapsed. ― Qwerfjkltalk 21:29, 18 July 2022 (UTC)
This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing) and you open the menu (for me the menu is collapsed by default on that size). While this desktop skin is more compatible with mobile and will eventually probably be fully suitable for mobile, that has not been the primary target of these changes. I believe there is an invite on its talk page asking people for feedback and ideas on what the menu SHOULD look like on mobile. But don't forget that lots of the content is not mobile compatible (minerva on the mobile site has all kinds of hacks to make content not break out of the mobile constraints) and Vector 2022 doesn't have those hacks. So for the immediate future it is still better to use the mobile website on mobile. —TheDJ (talkcontribs) 08:49, 19 July 2022 (UTC)
Apparently you get the same bad results on a Macbook laptop though, see above... Fram (talk) 09:21, 19 July 2022 (UTC)
I've just tested this on a Macbook in Safari and can't reproduce the issue - the link destination looks exactly as intended. Sam Walton (talk) 10:39, 19 July 2022 (UTC)
And of course, nothing in the opening statement of this section said anything about this not being for mobile and only for desktop, it just said that this would become the default, full stop. Fram (talk) 09:23, 19 July 2022 (UTC)
Just to confirm, this conversation concerns changing the skin on desktop only. This will affect the desktop view on mobile as well, but not the current default mobile view. OVasileva (WMF) (talk) 13:27, 20 July 2022 (UTC)

Easy switching skins

After I switched to the 2022 skin, I noticed a new link "Switch to old look" in the left margin, right below the "donate" link. But in the legacy (current) skin there is no corresponding "Switch to new look" link. Why not? wbm1058 (talk) 05:21, 23 July 2022 (UTC)

@Wbm1058 that is a temporary link designed to help anyone that is all of a sudden lost in the change to get back to being able to get around again. — xaosfluxTalk 11:40, 23 July 2022 (UTC)
I understand that, but the purpose of the "Switch to new look" link is to give readers a heads up that the change is coming so that they can check it out if they opt to. Then hopefully feedback on the changes is given in a manageable trickle so that things can be fixed before a hard change is made that causes an angry mob reaction. Not everyone is as tuned into this as you are; the only way I've become aware of this is from seeing the change in the French and other foreign-language versions. Not everyone is a power-user like me who reads foreign language wikis using Google Translate.
Will the French 2022 skin and the English 2022 skin be the same width, or is the English 2022 skin wider than the French 2022 skin? – wbm1058 (talk) 15:05, 23 July 2022 (UTC)
@Wbm1058 by default all of the vector-2022 skinned sites will have a similar look and feel. We have a opt-in gadget available if you want vector-2022 but in wide mode (mostly for wide screen desktop monitor users); it is still getting some improvements. — xaosfluxTalk 16:01, 23 July 2022 (UTC)
It looks like this. — xaosfluxTalk 16:04, 23 July 2022 (UTC)
Wide vector-2022 on a page with a TOC , there is work pending on a collapsible TOC for vector-2022 overall still. — xaosfluxTalk 16:06, 23 July 2022 (UTC)
And for users like me, will it be easy to use the version suitable for a large monitor on my PC and the other on my iPad. Doug Wellertalk 17:20, 23 July 2022 (UTC)
If it became popular, a toggle such as "dark mode" toggle could possibly be built. — xaosflux Talk 17:02, 25 July 2022 (UTC)
This is a great question, @Wbm1058. When we made the decision to put this link into the sidebar, the project was on an early stage. Now I think we could revisit this and put an equivalent link into the legacy Vector sidebar. SGrabarczuk (WMF) (talk) 16:48, 25 July 2022 (UTC)

Vector 2022 office hours

Vector 2022 showing language menu with a blue menu trigger and blue menu items 01.jpg

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:49, 25 July 2022 (UTC)

Hey all, wanted to ping @Sdkb, @Xaosflux, @Bilorv, @TheDJ, @BilledMammal, @IAmChaos, @Jonesey95 and anyone else who is curious - we're hosting office hours later today - if you're interested and have the time, you're welcome to join to talk through questions, comments, and the plan overall. In terms of the conversation here, we plan on answering open questions (we know there's still a few), summarizing the discussion, and identifying some next steps over the next couple of days. OVasileva (WMF) (talk) 08:07, 26 July 2022 (UTC)
Just want to say it's great that you are offering this and I hope people take you up on it! Andrevan@ 21:34, 30 July 2022 (UTC)

An update after two weeks of discussion

1. What should the process look like?

Hey all,

Thank you for your feedback. We recognize that this is a large and important change to our interfaces that will affect the default experience for millions of people. We appreciate your patience in this discussion on how to proceed in the best way possible for our readers, contributors, and communities.

We will try to summarize the feedback we have gotten so far, and continue with identifying next steps. Based on your feedback, we would like to propose the following process:

  1. Agree on what changes need to be made to the interface before the final deployment conversation
  2. Continue with a conversation focused on building consensus around deployment
  3. Deploy and continue with other improvements and requests that were agreed to be non-crucial for deployment

Does this seem in-line with your expectations? Do you have any concerns?

2. Why are these changes improvements?

Many of you were curios about the changes, and especially expressed interest in getting more details on our data and process. Below, we are outlining a bit about our process, as well as the data we have collected that proves that each feature is an improvement. Ping: @BilledMammal, @IAmChaos, Barkeep49, KevinL, Andrevan.

TLDR: Every one of our changes goes through a rigorous process of research, development, qualitative and quantitative testing with readers and editors, prototype testing with editors (across 30+ language communities), iteration, and post-deployment monitoring. When a change does not meet the success criteria or does not perform better than the existing version of a tool, we either stop developing the change or iterate until performance is improved.

We believe that the changes we have made will be crucial to making the site more welcoming and easier to use to new readers and editors.

When compared to the older version of the Vector skin, Vector 2022 is proven to:

  • Save time while reading and editing (measured by decreases in scrolling to the top of the page after the introduction of sticky header and table of contents)
  • Increase exploration within a given page (measured by increased clicks to the table of contents)
  • Improve readability (measured via collapsible sidebar usage)
  • Improve the discovery of new content (measured by an increase in searching)

You will find more details in the section #UX research and usability testing. We have tweaked the existing comment a bit.

Thank you for spending the time to write this out. My concern is that you are focused too much on testing for the change you intended to make and in doing so miss the broader impact. Because of this I feel your analysis only proves that you brought about your intended change, rather than proving that each feature is an improvement.
For example, consider the sticky header. Here, the goal is to (1) improve the user experience, by (2) saving reader time, by (3) reducing the amount of scrolling to the top that they need to do.
However, you only test for (3); you then infer (2) from the positive result for (3), and infer (1) from the positive result for (2). Testing directly for user experience is difficult, but to reduce the risk of errors the goal should be to get as close to that level as possible, and in this case it means testing for (2) rather than (3); if you look at #3 in my previous comment you will see that I am requesting data that should give us an answer to (2).
In addition, you assume there are no negative impacts from the change. This isn't a safe assumption, and with #2 and #3 of my previous comment I request data that will allow us to consider this possibility. BilledMammal (talk) 06:56, 28 July 2022 (UTC)
Hey @BilledMammal - sorry for the delay in response! I replied briefly to your initial comment above. TLDR is that we try to design experiments using more precise metrics because more open-ended metrics (such as time spent on page) could be interpreted in multiple ways. More time on page could be an improvement (people have a better experience and thus spend more time on the site overall). Less time on page could also be seen as an improvement (we're saving people time in scrolling so they get to what they need to do quicker). We can keep discussing there or under this thread - whatever is easier! OVasileva (WMF) (talk) 09:11, 2 August 2022 (UTC)

3. Why are we having this conversation while development is still happening?

We are eager to bring the improvements mentioned above to our readers. Currently, many new readers do not feel welcome by the interface as it is, and this is something we hope to solve as soon as possible. We recognize that no feature or skin will ever be perfect, and there will always be room for improvement. As we mentioned above, the skin, in its current form, is already a significant improvement over the current state.

The final state of the skin also depends on the conversation we’re having right now. There are many possible improvements or ideas for changes we can build and focus on. We’d like to discuss which of these are most important to the community as we proceed to implement and put the last touches on this version of the skin.

Finally, as we mentioned in a previous post, once deployed, we plan on continuing to work on the desktop experience. This project opens more possibilities for the future and gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is an ongoing process and it will be done with the feedback and collaboration of the community here and across other projects.

4. What changes will be made before deployment?

Our request for you is to review the list below and let us know if it looks correct in your opinion. What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

As a part of these conversations, we plan on placing requests into three categories. This categorization is based on our research, previous conversations with communities and prototype testing, as well as the feedback we received from all of you last week. These categories are flexible. We need your feedback to move something from one category to another, as well as to add items to each category.

  1. Issues we would like to address prior to the deployment
    1. Table of Contents collapsing and narrow screens behavior (@xaosflux, @sdkb). We are working on this and hope to have it ready within the next few weeks (more details in T306660)
    2. Visual refinements (@IAmChaos, @Terasail). We are working on this and we will finish before deployment, with the first part landing next week (week of August 1). To see more details on what visual refinements we are and how we worked with communities to define these, please see this page
    3. Making a decision on ToC handling and magic words (ping @xaosflux, @izno, @IAmChaos, @Anarchyte). We are doing a more in-depth review of magic words and hope to come to you all with a proposal on what (if anything) we think would be best to change. Our sense is that for some of these use cases, the new ToC has solved the initial issues for them existing. We’re interested in finding out which use cases this is not the case for, and providing a solution for those. To confirm, however, the __NOTOC__ magic word will continue to work, as will the templates creating the ToC based on __NOTOC__ such as {{horizontal toc}}
    4. Coordinates display and other indicator issues. We would like to ensure that coordinates do not overlap with any existing indicators and that the area in the top right corner of the article is well-organized (T281974). Special thanks to Xaosflux, Izno, theDJ, Sdkb, AlexisJazz for participating in the discussion and helping us identify next steps. The conversation around coordinates continues in VPT#Coordinates in Vector 2022
    5. Making it easy to opt-in and opt-out (@Shearonink, @wbm1058) - we have a button in the sidebar, which allows for easy recognition of opting out. Opting in is, however, only available through the preferences page. We’d like to explore the possibility of running banners that explain that the change was made and provide opt-out instructions as well. Similarly, prior to the change, we’d like to run more banners that encourage people to opt in and give us feedback
  2. Issues we would like to address after the deployment
    1. ToC/sidebar length and the separation of page tools from wiki-wide tools (@sdkb). This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to study and build out customizations for the various use cases (example: the ability to add admin tools or gadgets like Twinkle to the menu)
  3. Issues that will not be addressed at this time (issues that are not part of the Desktop Improvements project, belonging to other teams, etc.)
    1. A preference which allows the fixed width of the page to be turned off.
      A local gadget (currently experimental) or personal userscripts may address this at an individual editor level. — xaosflux Talk 10:10, 28 July 2022 (UTC)

5. What should the deployment conversation look like?

Some of you said that an RfC would be the best approach for the conversation around deployment. Does that sound like the right course of action? One thing that we have been thinking about is ways to include the voices of readers into the decision making process. We are planning to run surveys asking readers what they think about the new skin compared to the old one. How can we incorporate their thoughts into the conversation?

OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:53, 28 July 2022 (UTC)

Amazing work! CactiStaccingCrane (talk) 05:31, 28 July 2022 (UTC)
You could run a banner that provides an opt-in button for the new skin only visible for unregistered users, but then I'm not sure how they'd be able to leave feedback anonymously. The RfC could then be run in parallel with this campaign, with the ultimate decision relying on the inputs from both. Anarchyte (talk) 06:03, 28 July 2022 (UTC)
with the ultimate decision relying on the inputs from both How would this work? Who gets to decide how much to weight each if they conflict? I don't foresee the community willingly relinquishing control, so as much as I'm concerned that the community isn't going to follow WP:READER and is going to overprivilege editor needs, I think BilledMammal's suggestion is the only practical way to take reader input into account. {{u Sdkb}}talk 04:27, 29 July 2022 (UTC)
I echo Sdkb's concerns. The skin should only be implemented if there is an affirmative consensus to switch to the new skin, especially since the new skin (as it currently stands) will make breaking changes to Wikipedia editor tools and Wikipedia article layouts. — Ⓜ️hawk10 (talk) 23:41, 29 July 2022 (UTC)
To incorporate their thoughts I would suggest running the surveys prior to the RfC, and allowing editors to assess the results of the survey when making their decision. In the end, this needs to be based on the consensus of the community, as assessed by the community. For this assessment I would suggest one thing; asking for a panel close, such as was done for the 2021 review of RfA. BilledMammal (talk) 07:23, 28 July 2022 (UTC)
I think it's premature to decide in advance that multiple closers are needed. Most discussions can be evaluated adequately by a single closer. The 2021 RfA review was by design open-ended in the number of proposals that could be made, and thus unconstrained in the variety of rationales, which were primarily opinion-based, since often there's no way to collect data without actually trying a change to the process. It remains to be seen if an RfC on a new skin will have these or other characteristics such that more than one closer might be desirable. Ideally, if the development process goes as planned, there won't be an RfC unless there is already widespread support for the changes in question, much like the default deployment of the reply tool feature. isaacl (talk) 07:45, 28 July 2022 (UTC)
My suggestion was mainly to reduce the chance of the close being appealed at AN; I don't want us to have a situation where the discussion is closed with a consensus to implement the change, only to have the AN overturn the close. Normally such a situation would not be problematic but in this case I believe it would be due to the scale, prominence, and technical nature of the change. BilledMammal (talk) 08:04, 28 July 2022 (UTC)
I think I agree with BilledMammal that the best way is to present the results of the surveys at the RfC. Olga, you really don't want to end up in the scenario where the enwiki community reaches a consensus against the change while readers say they like the change – I think the community will feel betrayed if you don't respect its decision. If you don't think you can commit to abiding by the outcome of an RfC, you shouldn't hold an RfC; I would be quite upset but less than if you ran an RfC and then overruled its outcome. Best, KevinL (aka L235 · t · c) 17:55, 2 August 2022 (UTC)

Two pretty glaring issues

Ok, so, first, the collapsable toc. if you say readers find it easy, cool, but to me it seems like we're burying our navigational tools. Which to me seems like a really really bad idea. This feels more like something done for phones to save screen real estate, than what would need to be done on a computer monitor, but whatever. If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links.

That aside, not having the user talk page right next to the user's name is also a really bad idea.

We've already had issues with the mobile interface where it was difficult for new editors to know they were receiving warnings, because they didn't see they had a user talk page.

I realize we have our alerts system, but a direct link to the user talk page seems paramount.

if space is an issue, move the watchlist to the drop down, next to contributions (they both should be at the top of the drop down)..

But "talk" should be right next to the user name, before the notice icons. to make it clear that it's the user's talk page. - jc37 11:51, 28 July 2022 (UTC)

If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links. That is a good point, and A/B testing should include data on this. Hopefully the WMF will be willing to engage with this and the other requests for data I made above. BilledMammal (talk) 00:09, 30 July 2022 (UTC)
Can u explain ur thoughts further? Because talk page is a concept completely unique to us, id think. So why would that be more recognizable to ppl than a notice in the notice menu? More recognizable outside of a user’s menu than within the menu ? Isn’t it just that ppl simply need to learn these things no matter where they are ? —TheDJ (talkcontribs) 08:58, 31 July 2022 (UTC)
It's simply a matter of understandability and use-ability. If you look at the various icons that are intended for the user, both displayed and those in the drop-down, I think it's fair to say that the most important ones would be the user page, the user talk page, and alerts/notices. Contributions/watchlist next, then misc "other stuff", and then preferences and logout at the end/bottom.
Wikipedia is a learning curve, to be sure. But as our user model is based upon consensus, and discussing things is often the way of things here, putting the user talk page readily viewable would seem rather obvious.
My return question might be: Why shouldn't it be there? What is the logic here?
And with that in mind, pinging @User:OVasileva (WMF) and @User:SGrabarczuk (WMF). - jc37 08:00, 1 August 2022 (UTC)


About mass shootings

Actually in America they are becoming more and more serious, and the only reasons are irresponsible news media and social media users and platforms, according to the American Psychological Association. However, the English Wikipedia community may be partially responsible as well, since mass shootings sometimes appear on the Main Page (for example, 2012 Aurora, Colorado shooting is included in the "On this day" section today), and there is evidence that giving a mass shooting massive attention can cause contagion. So I propose that such tragedies (excl. state violence, events accompanied with a military operation and more-than-three perpetrator ones) be excluded from the Main Page, except for "From today's featured article" and "Did you know ..." to mitigate the current mass shooting epidemic in America. RekishiEJ (talk) 16:47, 20 July 2022 (UTC) altered a bit 10:21, 21 July 2022 (UTC)

This is a classic WP:NOTCENSORED situation. Wikipedia does not hide things that are upsetting or controversial as long as they are reliably sourced. It would lead to a form of gesture politics, because the information would be freely available elsewhere, eg television and newspaper headlines.--♦IanMacM♦ (talk to me) 17:03, 20 July 2022 (UTC)
While I, in principle, agree/understand where RekishiEJ is coming with this, Ianmacm is correct about WP:NOTCENSORED. TheSandDoctorTalk 18:07, 20 July 2022 (UTC)
I am not sure that WP:NOTCENSORED is really the right policy to apply… no one is proposing that we delete the articles on these events. The question is whether we want to highlight these events on the main page. That’s more of a WP:DUE/UNDUE question. Blueboar (talk) 19:56, 20 July 2022 (UTC)
  • @RekishiEJ: We need a discourse. WP:NOTCENSORED is not the end of the consideration, but only one thread in a massive conversation going in many directions. While I think NOTCENSORED is a guiding principle, we have related conversations such as how explicit Wikipedia should be in discussing suicide or other topics where research says that exposure to information encourages unwanted behavior. I support you or anyone else starting an essay, seeking prior conversation, and identifying other perspectives. We also have a Wikipedia article on the issue that could inform thought - Effects of violence in mass media. It has come up in the past as to whether terrorists are allowed to share images of crime that we republish in Wikipedia. I the discussion has hardly begun. Bluerasberry (talk) 20:05, 20 July 2022 (UTC)
"The only reasons [that mass shootings are becoming more serious] are irresponsible news media and social media users and platforms" is flat-out wrong. Putting that aside, if someone is going to do a copycat shooting, it's generally because they have a community egging them on via platforms like Discord, Telegram, 8chan, etc. It is almost definitely not because they happened to see an article about shootings on Wikipedia and independently decided it was cool. (I sincerely hope to never be proven wrong about this.) Gnomingstuff (talk) 20:20, 24 July 2022 (UTC)
@Gnomingstuff: The statement which you think is wrong is taken from [12], which reflects the consensus of the American Psychological Association on mass shooting contagion.--RekishiEJ (talk) 12:50, 25 July 2022 (UTC) altered a little 12:51, 25 July 2022 (UTC) altered a little again 11:18, 26 July 2022 (UTC)
What the paper says is that media coverage "may ultimately be contributing to the perpetuation of [mass shootings]" and names three other contributing factors, which is quite a different statement than "the only reasons mass shootings are increasing are news media." It also doesn't recommend anything analogous to not putting these articles on the main page. Gnomingstuff (talk) 15:31, 25 July 2022 (UTC)
I think we shouldn't mention the name or race of the shooter on the front page similar to this] .Agree that WP is an unlikely source for mass shootings, but I don't see any reason why a shooter would not have edited WP. Wakelamp d[@-@]b (talk) 11:19, 26 July 2022 (UTC)
In fact, we know a good number of them did – among them James von Brunn, John Patrick Bedell, Anders Breivik, Adam Lanza, Elliot Rodger and Raymond Spencer. Most only made a few edits, but still -- that is more than most people do. Andreas JN466 16:56, 26 July 2022 (UTC)

I think that they should be treated as any other even of similar significance, including the main page. But to not follow the US media practice of reporting on covering each one ~50 times...each day for for 20 days afterwards and then 30 more times in following years for anniversaries etc.. This increases the issues, perceptions and problems described in the OP.North8000 (talk) 22:24, 20 July 2022 (UTC)

The news media decided that it would not show the videos of the planes hitting the towers over and over again in the September 11 attacks. Some of the material is disturbing and upsetting so caution is needed. What is needed is a way of addressing this without trying to hide things that are legitimate matters of news and encyclopedic coverage.--♦IanMacM♦ (talk to me) 09:40, 21 July 2022 (UTC)
The news media decided that it would not show the videos of the planes hitting the towers over and over again
You could not avoid those videos if you tried back in 2001. They were everywhere.
Anyway, that's a different discussion. IanMacM is correct that this is ultimately a WP:NOTCENSORED issue. Americans will continue mass murdering themselves, and it will continue to be news. Much like bombings and other acts of terrorism, accidents, and other disasters will continue to occur, and continue to be news. Headbomb {t · c · p · b} 10:59, 21 July 2022 (UTC)
@North8000: "the US media practice of reporting on covering each one ~50 times...each day for for 20 days afterwards and then 30 more times in following years for anniversaries etc.."? You mean after a mass shooting receives national coverage in the U.S., it is reported by American news outlets from Day 1 to Day 20, and during this period it is repeated at most 49 times everyday (which seems impossible), and in the following years it is repeated 30 times each year? Sorry I don't understand what you mean very well.--RekishiEJ (talk) 08:36, 23 July 2022 (UTC)
@RekishiEJ, I believe North8000 means it's covered around 50 times (by various different news outlets) for 20 days, and then over the anniversaries etc. it is covered 30 more times (in total). If that's still implausible, it could also be exaggeration. ― Qwerfjkltalk 09:01, 23 July 2022 (UTC)
I was a little vague, but what I meant roughly speaking is that each larger scale mass shooting gets covered by national media on about (rough guess) 50 days. And as a rough example, daily coverage for each of the 20 days following the event and then on about an additional 30 different days spread amongst during the following years. (e.g. the 1 month anniversary, the 2 month anniversary, 3 month anniversary, 8th year anniversary, interviews about the event with survivors and friends / families of victims about upcoming anniversaries, coverage triggered by their actions in subsequent months and years etc. North8000 (talk) 12:47, 23 July 2022 (UTC)
In short, we should cover them when they are current news, but not amp up coverage (as the US media does) via anniversaries etc. North8000 (talk) 14:47, 24 July 2022 (UTC)
To clarify further, the "current news" coverage should be subject to the usual criteria, such as Masem described in the next post. North8000 (talk) 17:17, 26 July 2022 (UTC)
  • I would say that we should be trying to recall that WP:NOT#NEWS exists and that WP:NEVENT should be used to judge the long-term notability of such events. There are clearly some shootings that will remain notable like the Uvadle shooting, but we are often far too eager to rush to create an article about a mass shooting without waiting to see how much coverage it actually is going to have in the future. --Masem (t) 15:00, 24 July 2022 (UTC)
    I would have thought it unlikely that a mass shooting would not get at least some longer-term coverage from regional media, though of course many won't in a national or even a state sense. Nosebagbear (talk) 17:25, 25 July 2022 (UTC)
    In the US, mass shootings happen, on average, more than once a day. These events are notable according to the same criteria we use for anything else, but as a practical matter we'd need to hire or appoint a full-time editor in residence just to keep up with the death toll associated with our... "freedom". MastCell Talk 17:30, 26 July 2022 (UTC)
There are different ways that they are defined for different purposes including ones where people were only wounded. I think that the OP was referring to those of the type with several deaths which make national news. North8000 (talk)
  • The entire premise of this proposal is faulty. To say that "the only reasons are irresponsible news media and social media users and platforms, according to the American Psychological Association" is patently false and lacks citation. RekishiEJ is incorrect that this press release "reflects the consensus of the American Psychological Association on mass shooting contagion". Rather, it is a presented paper from the APA national conference, meaning it is not even a peer-reviewed published scholarly article and certainly not a position statement of any sort. Social contagion theory is a perfectly valid theory and likely has some significant R2, but to suggest we stop writing any articles due to it is absurd. Most damning to this contagion idea, to me, is that this "contagion" near-universally affects only boys and young men for some unspecified reason. EvergreenFir (talk) 17:55, 26 July 2022 (UTC)
  • Agree with user Masem above. I would also add that when these events are highlighted, for whatever reason, that the perpetrator's name should only appear once in the article or summary, and never in the headline. Regards, GenQuest "scribble" 18:59, 26 July 2022 (UTC)

Upgrade opt-in Appearance gadget to show blocked users without talk page access

— Preceding unsigned comment added by EpicPupper (talkcontribs) 22:26, 21 July 2022 (UTC)

DABs on very common names: how to improve

DABs on very common names: how to improveI'm not a coder, but others are. There is a dilemma here: any DAB page on very common first names (such as Ben) or surnames (such as Müller (surname)) has the problem that it is NEVER complete. It can't be. Also, updating the details (such as death year when it occurs) is a Sisyphean task, which will also never catch up with events.

The second option would be to only use the template {{intitle ''search word''}} for displaying "All pages with titles containing search word". Besides the problem of bringing up hits other than pages about people with that name, the main problem there is that it leads to endless lists of hits, which are not organised alphabetically (can't figure out how they are organised), split into pages of 50, so totally non-user-friendly and almost useless.

We need a bot here, which would transform the template, so the result would still be

  • an automatically created list, but one
  • ordered alphabetically,
  • displaying the "short description" next to the name and being
  • as updated as the Wikidata file is,
  • at best with the option of getting fixed manually (because there are more editors who know how to do that than such who know how to fix "short descriptions" and Wikidata files),
  • ideally with a mechanism pinging interested editors when such manual changes happen, so that they can adopt the change, if they see fit, to the "short description" and Wikidata file.
  • Adding headings for each letter of the alphabet, like at Müller (surname), is also helpful.
  • The option of giving priority to manual fixes: if the name stems from, say, a biblical character or a few ancient saints, those should be set first, at the top, in their own sub-section, preferably in a chronological order, which should be stated in a short sentence (intro) under the sub-heading. That's the job of an experienced editor, not a bot, and the bot should not mess it up.

Repetitive work is typically best fit for bots, and this is a clear case of such work. Is anyone interested & able to create the mechanism? I guess there might be Wiki proposal pages better suited than this one. Who can point me to them? Thank you, Arminden (talk) 08:44, 25 July 2022 (UTC)

Automatically displaying the short description would indeed be a major improvement. SDs are specifically written with disambiguation of this type in mind, and many biographical SDs include birth and death dates which helps quickly readers focus on titles of interest. One slight correction: SDs aren't linked in any way with Wikidata (they used to be, but the link was removed a few years ago). Now, all SDs are stored locally here, and are written with solely with Wikipedia in mind. MichaelMaggs (talk) 10:29, 25 July 2022 (UTC)
@Arminden, I wonder whether a link to Special:AllPages/Ben would address some of your concerns for common first names. Whatamidoing (WMF) (talk) 21:02, 25 July 2022 (UTC)
Whatamidoing (WMF), thanks for the template. I knew of a similar one, {{intitle Ben}} (leads to All pages with titles containing Ben). There is even one leading to [[Special:search/~"Ben" All pages containing ''Ben'']] (leads to All pages containing Ben). The two can be both replaced by a single, much shorter one, {{srt}}. Anyway, they're all useful, but lacking details (short description and life years) and are not good for replacing the existing DAB page. Arminden (talk) 21:48, 25 July 2022 (UTC)
Not sure that DAB is supposed to be an index of every “Ben”. The point of a DAB page is to disambiguate topics that might have the same title.Blueboar (talk) 22:01, 25 July 2022 (UTC)
Having a list of all people named Bibi is a useful disambiguation tool; there are 33 people listed there, divided into nickname, first name and last name. Ben is probably the name of too many people to be useful even as a navigation aid, unless some reasonable split can be made (by a human, not a bot) and enforced. Animal lover 666 18:38, 26 July 2022 (UTC)
{{Get short description}} might help (though it doesn't work perfectly). The birth and death dates could be obtained from Wikidata (via a bot or template). ― Qwerfjkltalk 06:36, 28 July 2022 (UTC)

Protecting important list articles indefinitely

I think it is important to protect important list articles from promotional edits such as List of news websites in India and Over-the-top media services in India. I believe these types article has an importance in search results that people search for it. Unfortunately, there is a high chance to get the article vandalized for promotional uses by others (business, agency) to list their assets in Wikipedia. IPs are also coming with the same after the vandal's block. So, I believe it would be important to make these types of article reliable and vandal free by protecting it with SemiP or ECP. Onmyway22 talk 07:18, 27 July 2022 (UTC)

Remember that protection also protects against good edits, such as removing vandalism and spam. Phil Bridger (talk) 07:28, 27 July 2022 (UTC)
WP:PREEMPTIVE makes it clear that pages should not be pre-emptively protected; neither linked article has any recent disruption, so I do not see the need to protect at the moment. Curbon7 (talk) 13:49, 28 July 2022 (UTC)
I can't see why list articles in general would needs special exceptions from Wikipedia:Protection_policy#Pre-emptive_protection; if a page is having a problem we should be able to deal with it already. — xaosfluxTalk 13:50, 28 July 2022 (UTC)
The general rule is to apply the lowest level of protection, for the shortest period of time, required to prevent ongoing disruption. Apply indef protection of any level is a drastic step which shouldn't be taken without extensive evidence that it's needed and that previous efforts have failed. -- RoySmith (talk) 16:11, 28 July 2022 (UTC)

To whatever extent that people use those lists, any entry is promotional and will financially benefit whoever is listed. And being subjective with no inclusion criteria noted, what would make any particular addition be considered to be "promotional" any more than the others on the list? North8000 (talk) 16:20, 28 July 2022 (UTC)

As a general principle, we should ask editors to fix their mistakes. Why don't we?

We have, or have had, systems in place that drop a user talk note where an editor adds a disambiguation link to an article, or leaves unbalanced brackets in an article.

Why don't we have something set up so that for every WP:CHECKWIKI issue for which we scan (e.g., an editor putting a footnote in a header), we have a bot find the editor who made that edit and drop them a note informing them of the relevant rule and asking that they fix it? BD2412 T 15:44, 28 July 2022 (UTC)

In theory, I think this would be a great idea, but requires a bit of thought. We could certainly come up with a list of things that can be checked automatically (in the tradition of lint). We could then drop a (friendly and educational) note on the editor's page, alerting them to the issue and suggesting improvements. The problem is, as anybody who has worked with a linting system knows, the burden of sorting out false or trivial alerts can exceed the value of the system if you're not careful. -- RoySmith (talk) 16:07, 28 July 2022 (UTC)
In principle this is a nice idea, but out of interest what do you mean by "putting a footnote in a header"? Do you mean including references in the lead, as in (from today's OTD) Rædwald of East Anglia notes [1] and [2]? While this is in principle not correct, all lead facts should be mentioned and cited in the body, and would be something to bring up at GA or FA, we definitely shouldn't be discouraging this for each and every article of any quality. It is much better for a fact to be referenced only in the lead than not referenced at all... Cheers — Amakuru (talk) 16:13, 28 July 2022 (UTC)
I think BD2412 meant something like == Awards<ref>{{cite web ... }}</ref> == in articles. DanCherek (talk) 16:16, 28 July 2022 (UTC)
Yes, per DanCherek, last I checked we have over 5,000 instances of a footnote in a section header, with many of these being in the ==References== header, and therefore not properly associated with specific article text. In every one of those cases, some editor first put that ref tag in the header, and a search of the article history should reveal which one, so they can be messaged and asked to fix the error. BD2412 T 19:01, 28 July 2022 (UTC)
To be clear, by the way, I am not just suggesting that we do this going forward, but that we do this retroactively with respect to currently-existing errors. BD2412 T 19:03, 28 July 2022 (UTC)
I've seen == Awards==<ref>{{cite web ... }}</ref> too, and I am fine if we have that notice, but I don't I know how many of these standard type mistake edits there are. Alanscottwalker (talk) 19:20, 28 July 2022 (UTC)
As a general principle experienced users should fix mistakes that are made by new editors. Why don't we? Phil Bridger (talk) 21:39, 28 July 2022 (UTC)
Oh, I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakers. And fixing one's own mistakes when they are pointed out is how we hopefully learn not to make the same mistakes again. - Donald Albury 22:51, 28 July 2022 (UTC)
@Phil Bridger: let me ask you this. Do you remember all of your old mistakes? Some of the things we are fixing today were originally done years ago by editors who are still active, and now experienced. If, say, fourteen years ago, you did something erroneous in an article and it was still there, wouldn't you want a bot to drop you a note asking you to revisit it? BD2412 T 05:26, 29 July 2022 (UTC)
I just thought I would trial a problem solving approach to proposal evaluation.
Problem
  • Quality - Editors creating work for others
Root Cause
  • Process - The editing systems are not mistake proof.
  • Training - Help is not context-sensitive, but in complex guidelines. Ignorantia juris non excusat (ignorance of the law is no excuse) approach
  • User Experience - Overload of information. Action and Error message are complex and long.
  • Policy - WP:5P4 "Wikipedia's editors should treat each other with respect and civility" does not specify that editors should not waste other's time.
  • Process Management - There is no overview of errors to fix
  • People - Lack of editors to fix minor issues "I do, sometimes, but I have other things to do, and don't want to spend all of my time fixing other editor's mistakes. " @Donald Albury
Proposed solution
  • Create an automated system to ask problem creator to fix.
Can we trial it at low cost?
  • Yes - identify minor errors and manually send errors, and see responses both from a bot type editor name and from a normal editor name,
Risks
  • Against Best practise -Blame_in_organizations
  • Editor retention : Creator of error may respond negatively especially if many years old (See comment by @BD2412) justice delayed_is_justice_denied or maybe there needs to be a statute of limitations
  • Editor Retention - Major reason for "Golden editors" is perceived negative interactions, especially on talk (there is WMF research somewhere that someone can find)
  • Editor retention : Bot Human interactions can be problematic
  • New Process Risk- Pushing error notifications to editors.
  • User Experience - We are allowing a bot to send errors a few minutes later rather than tell the editor at the time
  • Editor retention - Notifications are static. If the error is fixed, before the editor looks, then wasted effort.
Cost
  • Labour - Increased effort of "ask to fix" vs "fix yourself" (Wikipedia Editor hours)
  • Quality - High Failure rate - Using talk as an example (and figures based on a random sample I just did), only 5 to 10 % get a response within 5 years, or before being archived. FA are 50 &, stubs are zero
  • Turnover/Retention - (see @BD2412
Benefit to Readers
  • Would they notice if this is not fixed?
What do we need to monitor current state and success rate?
  • Data - results from similar request processes. (notifications, messages, talk)
  • Data - percentage of minor errors after receiving notification
  • Data - percentage of active editors who stop being active within say 12 months of receiving notification, compared with editors who don't receive notification
  • Definition of success -what percentage is success
  • Policy - no process for evaluating proposal success Wakelamp d[@-@]b (talk) 08:30, 29 July 2022 (UTC)
  • @Wakelamp: For the record, the "don't want to spend all of my time fixing other editor's mistakes" comment that you quote was Donald Albury, not me. BD2412 T 16:52, 29 July 2022 (UTC)
Doh! CorrectedWakelamp d[@-@]b (talk) 13:34, 30 July 2022 (UTC)

RfC: Should we use the longstanding external links icon or the new one?

old icon
new icon
How the new icon appears in Chrome on a 1920x1080 display in Windows 10


Recently, a new icon has been rolled out and implemented for external links. Should we use the longstanding icon or keep the new one? — Ⓜ️hawk10 (talk) 04:26, 29 July 2022 (UTC)

Discussion: Should we use the longstanding external links icon or the new one?

  • Use the longstanding icon. The old icon was functioning quite fine, no editors on EnWiki seemed to complain about it, though the Wikimedia foundation decided to make changes to the current Vector skin that has used the longstanding external links icon. The new icon, frankly, is too thin to properly render on my monitor and (per comments on phabricator) it appears to be this way on low-density screens more generally. While some may be ok using the new icon before it is fully finished, I personally am frankly disappointed that the way that this icon renders on low-density screens was not given due consideration before its implementation. The longstanding icon should be used until the glaring issues with how the new icon renders on different screens are resolved. — Ⓜ️hawk10 (talk) 04:26, 29 July 2022 (UTC)
  • This is clearly premature. --Izno (talk) 04:37, 29 July 2022 (UTC)
    I disagree. If anything was premature, it was pushing the icon onto EnWiki without (a) local communication that this was going to happen and (b) testing to make sure that the icon would appear well on low-density screens. — Ⓜ️hawk10 (talk) 04:39, 29 July 2022 (UTC)
    I disagree, no one is asking you about the 300 changes per week being deployed and you should be glad, you don't have enough waking hours to read them. Be bold and revert is a much better strategy. —TheDJ (talkcontribs) 14:34, 29 July 2022 (UTC)
    Per TheDJ. In addition, the change itself has already been reverted in the source. See phab:T261391#8112692. Izno (talk) 15:24, 29 July 2022 (UTC)
    Hi @Mhawk10 and all,
    Volker E. here, I'm Design Lead at the Wikimedia Foundation Product Design team and this change implemented by myself is part of a multi-year user-interface standardization approach. In short the icon collection design and agreed upon by the Design team follows generalized guidelines

    First things first, as @Izno already shared, the proposed icon change has already been reverted by us. The rollout featured two problems that we haven't fully anticipated. This will not go into production as is. For completion, visit also the corresponding Phabricator task.
    Second, we have been working and implementing a unified icon set with various quality characteristics for several years now. Among the characteristics are reduction to the essential form and making the icons as universally recognizable as possible. Keep in mind, that given the small icon size, the lesser the details, the better they are recognized by the users. Other high visibility icons, which have changed during that time were 'search', 'user avatar', 'watchlist', 'edit' (pencil) or the 'language' icon. Also Wikipedia's mobile frontend/Minerva Neue skin features the proposed new icon for over a year already. Users switching from mobile to desktop should find the same icons for the same thing.
    Third, the current (old) icon features long-standing technical issues. It's not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences and doesn't hold up to other quality characteristics above, like the most simple form.
    Therefore we're aiming at amending the icon patch once more and at reintroducing it with better targeting all the special cases undiscovered before. Also with more testing time upfront. It should then work well for lo-dpi and hi-dpi (“retina display”) environments and without technical issues that were caused by having it featured in a bigger font-size in running text and smaller one in References.
    – Regards, Volker E. (WMF) (talk) 13:40, 1 August 2022 (UTC)
  • WP:BIKESHED If you prefer the 'old one' once the 'new one' is rolled out, you can always customize it in your on skin. Headbomb {t · c · p · b} 04:44, 29 July 2022 (UTC)
    This isn't about just me, and I'm aware of how to do customizations. The issue is that affects readers who have low-density screens by making the rendering sloppy. — Ⓜ️hawk10 (talk) 05:19, 29 July 2022 (UTC)
    Bikeshedding is when you get caught up discussing the color of the bikeshed instead of the construction of the nuclear power plant. The point isn't that one should never care about the color of a bikeshed. After all, there may be all sorts of aesthetic, logistical, and environmental concerns absolutely worth raising about a bikeshed's color. It just shouldn't become the focus over more important things. So if Mhawk had started this RfC in the middle of a discussion about the external links guideline, then yeah, that'd be bikeshedding. But it's perfectly fine to start a discussion with the specific scope of deciding what the icon should be, just like it's fine for the nuclear power plant to put together a committee with the dedicated purpose of picking a color for the bikeshed. -- Tamzin[cetacean needed] (she they xe) 06:41, 29 July 2022 (UTC)
  • Use the longstanding icon, per MOS:RESOL and Mhawk's comments. BilledMammal (talk) 05:56, 29 July 2022 (UTC)
  • Use the longstanding icon per the visibility concerns Mhawk raises. A new icon that doesn't render right is about as useful as installing chandeliers in a condemned house. —Jéské Couriano v^_^v a little blue Bori 06:27, 29 July 2022 (UTC)
  • Looks like the change was undone last night – I assume we will see the old icon again on Thursday — GhostInTheMachine talk to me 09:07, 29 July 2022 (UTC)
  • Comment: I like the new icon but to me on my mobile screen using desktop site, it appears as four disconnected straight lines which is rather awkward to see. The old one at least worked fine. CX Zoom[he/him](let's talk • {CX}) 09:44, 29 July 2022 (UTC)
    I'm on regular desktop and I see the same: four disconnected lines as the box. Also at high zoom it becomes clear the the diagonal arrow looks terrible and it's got obvious issues. So the "new image" shown for this RfC doesn't match the actual image being used for the external links. Jason Quinn (talk) 16:27, 29 July 2022 (UTC)
  • Given that the change has been reverted for now this RfC should be closed. Sam Walton (talk) 11:19, 29 July 2022 (UTC)
  • The old icon looks like ass. I mean, I kind of grew attached to it over the years, but let's be honest, it was very much a product of its time. It doesn't make sense. Look at it for a minute. There is this big, open arrow, and a random diagonal line in the middle of the icon, that's a completely different color. Maybe there are some problems with the new one (it looks fine on my desktop computer but it seems like some people were having issues) -- but come on, there's a lot of room for improvement. jp×g 11:53, 29 July 2022 (UTC)
  • What do you mean "has been rolled out and implemented"? I still see the "old icon" on EL's. — xaosfluxTalk 13:31, 29 July 2022 (UTC)
    • I’m still seeing the new icon on desktop while logged out and logged in. What skin are you using? — Ⓜ️hawk10 (talk) 14:10, 29 July 2022 (UTC)
      Looks like this is skin-specific; only seeing the 'new' one in (minerva, vector, vector-2022). FWIW, I don't really care one way or the other there. — xaosflux Talk 14:37, 29 July 2022 (UTC)
  • WP:BIKESHED, no one should care, start writing articles or become a designer ffs —TheDJ (talkcontribs) 14:02, 29 July 2022 (UTC)
    • Seconded! Another waste of time survey to distract people from meaningful discussions and content creation. Aza24 (talk) 20:51, 29 July 2022 (UTC)
    It is good that people care about the site's design and point out problems with updates. Your dismissive attitude is not helpful. —Kusma (talk) 12:13, 30 July 2022 (UTC)
  • While I don't like the old icon much and will not shed a tear when it gets replaced by something better, the new icon sort of breaks when I decrease my font size. (Just tested on zhwiki, which has the new xlink icon but the old PDF icon). I am hoping we'll see a third icon that is better than both soon. —Kusma (talk) 16:00, 29 July 2022 (UTC)
  • The old icon should be used until resolution issues are fixed. That said, the new one if it renders correctly is much clearer than the old icon. —Danre98(talk^contribs) 16:44, 29 July 2022 (UTC)
  • Reconsider when they want to re-add, if we care I'm not quite on the "let the devs do and only revert if needed" side as suggested as pure default, but I don't think this would have been the drastic change that heralded the (formal) dev takeover without prior notice. It's been rightly reverted. Presumably it'll only be re-added when they're fairly confident that it'll serve all the usecases of the current one - i.e. when it's down to being a stylistic choice. As both are perfectly understandable I pray we can skip the pdf slog as I really couldn't care less at that point. Please consider this !vote as a akin to a procedural close !vote, if it matters. Nosebagbear (talk) 21:08, 29 July 2022 (UTC)
  • Comment. What articulatable problem does this icon change solve? Not super clear from the phab thread. In my opinion, the icon's reduction in density is a bit jarring. –Novem Linguae (talk) 03:10, 30 July 2022 (UTC)
  • Make the new icon thicker, per others. The new icon is inherently better as it is more modern, easier to see, etc. People who are wanting the old icon back can copy a CSS code from somewhere. A rocky implementation should not kill a good idea. CactiStaccingCrane (talk) 13:16, 30 July 2022 (UTC)
  • WP:BIKESHED, WP:BRD Andrevan@ 21:32, 30 July 2022 (UTC)
  • New logo no issues with the new logo, I think there's some response bias in terms of people actually liking the new logo but not commenting here. This isn't a big deal IMO. Use the new one. Therapyisgood (talk) 01:53, 31 July 2022 (UTC)
    The problem is not that proposal logo is bad. Infact, I like the modern feel of it. The problem is that what has been proposed, isn't the one being seen by many, if not all, of us. User experience should be the driving force behind change, not making changes for the sake of making changes when there's lots of rather urgent technical issues needing resolve. CX Zoom[he/him] (let's talk • {CX}) 06:41, 31 July 2022 (UTC)
    For what it's worth, I prefer the new icon. ― Qwerfjkltalk 18:02, 31 July 2022 (UTC)
  • Oppose any local solution. Just use whatever MediaWiki and Vector developers decide to use. If you want to push a certain option, do it on Phabricator or Meta, not here. Nardog (talk) 02:01, 31 July 2022 (UTC)
  • Use the longstanding icon. In Chrome a 1920x1080 monitor in Windows 10, the new icon looks disjoined and lopsided. --Ahecht (TALK
    PAGE
    ) 18:10, 31 July 2022 (UTC)
link text ← At least for me, this example is missing the line on the right side, which is even worse. --Ahecht (TALK
PAGE
) 13:35, 1 August 2022 (UTC)
Patch author here. The (second) implementation has featured a technical issue with the icon canvas, hence the lost side lines. We've reverted the patch, but will provide an updated one which aims to work in your case. Please see also my message to the original thread. – Volker E. (WMF) (talk) 15:01, 1 August 2022 (UTC)
  • Old one - 2560x1440 resolution and the border lines are incredibly thin, almost looking missrendered. Anarchyte (talk) 08:15, 1 August 2022 (UTC)
  • New one I'd never considered we could change it, but now that I know we can, I agree that the old one looks not great. CaptainEek Edits Ho Cap'n! 03:28, 2 August 2022 (UTC)

Communication issue

@Volker E. (WMF), AHollender (WMF), and Jon (WMF): Completely separate from the issue of whether or not the new design is an improvement (which I still need to investigate more before forming an opinion), I think we need to take a bit of space here to diagnose what went wrong with communication between the WMF and the community. This is a major design change (far more impactful than the PDF icon change for which there was a CENT-listed RfC) that should have been presented to the community rather than rolled out unilaterally. Why didn't that happen? {{u Sdkb}} talk 14:37, 29 July 2022 (UTC)

Because the PDF change took 3 months ? —TheDJ (talkcontribs) 14:43, 29 July 2022 (UTC)
The WMF had nothing to do with the pdf change; the icon is a local thing used by MediaWiki:Common.css circa row 92. In addition, per TheDJ above, there are several changes each week and I don't think enwiki needs consulted about every single one. Devs being bold and others reverting if necessary (as someone has) works just fine. —Danre98(talk^contribs) 16:48, 29 July 2022 (UTC)
I really have to question it as a "major design change". No, New Vector is obviously such, but the external link tag is not. The pdf change took forever because so many proposed changes were un-understandable. Nosebagbear (talk) 21:10, 29 July 2022 (UTC)
The external links icon is not a "major design change" but it is extremely visible. Many of the key Wikipedians are some of the most thoughtful, helpful, and capable people on the planet. Maybe it's just me but I think common sense suggests to consult them before making any highly visible global change. Jason Quinn (talk) 02:30, 30 July 2022 (UTC)
It makes no economic sense however. —TheDJ (talkcontribs) 08:59, 30 July 2022 (UTC)
And yet, I didn't notice it until I saw this discussion. - Donald Albury 16:19, 30 July 2022 (UTC)
I would agree with Jason here. I also don't like setting the standard that we make our source code easier to change than MediaWiki:Common.css. There should be some sort of community review before highly visible changes go live.
FWIW, I say this as the person who got the PDF icon change rolling (despite not getting my preferred result). @Nosebagbear: From that perspective, I can say the pdf change took forever simply because the community didn't just want an improved icon (which my suggestion in comparison to the lousy gif) but a better icon (the one they ended up going with without the Adobe logo on it -_-). –MJL Talk 18:41, 30 July 2022 (UTC)
"There should be some sort of community review before highly visible changes go live." There is, you can register on gerrit.wikimedia.org and review to your hearts content. You can read all the many dozens of MediaWiki.org pages that summarise some of the changes and you can participate in any Phabricator ticket that has the "design" tag (currently about 1100 open tickets all mostly about 'visible' things). —TheDJ (talkcontribs) 09:06, 2 August 2022 (UTC)
Please review mw:Bug management/Phabricator etiquette before posting comments on Phab tickets (it's not difficult, but it's not a Wikipedia talk page). Also, voting-type behaviors are banned; this is not the place to discuss who supports/opposes something (although links to external discussions are usually welcome). Whatamidoing (WMF) (talk) 20:08, 2 August 2022 (UTC)
@Whatamidoing (WMF): Thank you for clearing that up for folks. Face-smile.svgMJL Talk 21:38, 2 August 2022 (UTC)
Not every change needs an RfC, but every change that alters how we view or interact with the website should be presented to the community; if there are reasonable objections, we can then open a broader discussion and if necessary an RfC. BilledMammal (talk) 00:11, 30 July 2022 (UTC)

Related changes link from redlinked pages

We already have a What Links Here link on redlinked pages. I propose a link to Related Changes be added directly after it (with options set to list changes to pages linking to the page in question).

Rationale: It saves a few clicks or keystrokes, and it is useful to check the popularity of an article subject or the amount of editing activity on connected subjects, something that may indicate importance or demand of a new article. Utfor (talk) 17:43, 31 July 2022 (UTC)

Bots fixing double redirects should tag them with rcat

Suppose a double redirect ABC is straightened to AC. If B is retargeted or expanded to an article later, A should be updated accordingly. We already have a mechanism for that, the template {{R avoided double redirect}}. However, the double-redirect-fixing bots currently fail to tag the straightened redirect (A) with the template. I thus propose to make it mandatory for the bots to apply the tag when straightening a double redirect. It has already been discussed at Wikipedia talk:Double redirects § The bots should operate with a delay. Petr Matas 05:40, 1 August 2022 (UTC). Updated: 11:09, 1 August 2022 (UTC)

It's really a bad task for a bot, and {{R avoided double redirect}} is rather pointless tagging in most cases. Many redirects are created as double redirects with the understand that a both will cleanup after them. What's gained by tagging those with {{R avoided double redirect}}? Headbomb {t · c · p · b} 07:32, 1 August 2022 (UTC)
Support. I completely disagree with Headbomb - {{R avoided double redirect}} is for situations where the avoided double redirect could potentially become an article later or where that redirect is retargetted - when the avoided redirect changes the dependent redirect can be automatically updated to best serve readers. For example if "Foo (song)" is created as a redirect to "Foo (album)" that is itself a redirect to "Foo (band)" then tagging the first redirect as a {{R avoided double redirect}} will allow it to be automatically retargetted to "Foo (album)" when someone writes that article; it can also be retargetted automatically if "Foo (album)" is retargetted to the new article "Foo discography" without the author of the article needing to know the redirect exists - this is even more useful when the redirect is from a less obvious title than in this example. I can see lots of advantages of doing this by a bot and no downsides. Thryduulf (talk) 10:45, 1 August 2022 (UTC)
Thryduulf, I see the downsides. Let's say "Death of Foo" is a redirect to "Shooting of Foo" which is then moved to "Assassination of Foo", causing a double redirect at the first one, we would not want the bot to tag "Death of Foo" with {{R avoided double redirect}}, because the avoided double redirect doesn't really have the potential to become a standalone article without duplicating an existing article, and it would just bloat up the category with unwanted pages. CX Zoom[he/him] (let's talk • {CX}) 11:43, 1 August 2022 (UTC)
It's never "mandatory" for a human editor to put that template on a page, so it shouldn't be for their bot-aided edit either. Fixing the double redirect alone is still better for readers, so if it comes down to fixing it or skipping it over this new proposed rule - I'm for the former. — xaosflux Talk 12:52, 1 August 2022 (UTC)
Here's a concrete example. There is the journal Proceedings of the National Academy of Sciences of the United States of America. Because that is a mouthful, I create PNASProceedings of the National Academy of Sciences of the United States of America, it's most common abbreviation. Now, because this isn't the only way to refer to PNAS, and because I am lazy, I also create
P.N.A.S.PNAS
PNAS USAPNAS
Proc Natl Acad SciPNAS
Proc. Natl. Acad. Sci.PNAS
Proc Natl Acad Sci USAPNAS
Proc. Natl. Acad. Sci. U.S.A.PNAS
Proceedings of the National Academy of SciencesPNAS
And a bunch of others
Should those be tagged with {{R avoided double redirect}} once the bot cleans up after me? The answer here is clearly no. These are not distinct topics, these are the same topics. Headbomb {t · c · p · b} 13:30, 1 August 2022 (UTC)
Oppose per WP:CONTEXTBOT. The original premise here is not correct, a redirect chain ABC does not mean that B is the intended target for A or that the process of retargeting A results in an avoided double redirect. B could be a misspelling, an alternate capitalisation, an alternate disambiguation, a synonym etc. {{R avoided double redirect}} is for the situation "If B was an article A should point to it, but since B is a redirect A points to C instead". Any bot applying these tags would need to be making editorial judgements about what the intention of person who created redirect A was, and whether B has the potential to be a separate subject from C, which is not an appropriate task for a bot. 163.1.15.238 (talk) 13:08, 1 August 2022 (UTC)

Idea lab

Using "Edit distance" instead of "Byte size difference"

Hi, in history pages like https://en.wikipedia.org/w/index.php?title=Main_Page&action=history there is a "Byte difference" in parentheses like

(cur-prev) 15:25, June 17, 2022‎ Cyberpower678 (talk - contribs‎) (2,964 bytes) (+3‎) Undid revision 1093586636 by Cyberpower678 (talk) Whoops. Tested on the wrong page (thank) (Tag: Undo)

Here (+3) denotes "Byte size difference of previous and current edition of this page". I really think that "Byte size difference" is wrong here, and we should show "Edit distance", for example by using Levenshtein distance. Suppose this scenario: someone only changes one word e.g., "on" to "in" in his edit. Here "Byte size difference" says that their difference is zero, because no change occurs in length of strings, but "Edit distance" shows the correct item to to the user, e.g. by Levenshtein distance the edit distance of "on" and "in" is equal to 1. So what should be shown to the users in parenthesis is the "edit distance" not "byte size distance" of editions. Thanks, Hooman Mallahzadeh (talk) 11:23, 7 July 2022 (UTC)

How do you propose this be reconciled with the page size value (unavoidably in bytes) right before it? It might be that the edit distance would be a more informative indicator in some cases, but it would also be very unintuitive to very many people, and certainly so with the way this information is currently being displayed. That is to say nothing about the technical feasibility of making such a change, which I'm not qualified to speak on. Dr. Duh 🩺 (talk) 11:36, 7 July 2022 (UTC)
It might not be perfect but it is only an indicator of a change. No matter what the value represents you will not be able to tell what the edit is by having a number (+2/-50) explain what a user has done. The difference here would mostly be for copy editing which I don't see an improvement of showing a +1 over a 0. Terasail[✉️] 11:48, 7 July 2022 (UTC)
@Terasail For myself +1 (i.e., edit distance) is very more informative than 0. And I really think that (and hope) it would be more informative to others. Hooman Mallahzadeh (talk) 11:52, 7 July 2022 (UTC)
@Terasail Yes! A copy task makes "Byte size difference" equal to 0, but in such cases, "edit distance" should be equal to 1, and not bigger than 1, so implementation by Levenshtein distance is not a good choice for such scenarios. You are right! We should somehow modify the algorithm for such copy tasks, to return edit distance equal to 1. But for scenario of "in" and "on", Levenshtein distance is good enough. Hooman Mallahzadeh (talk) 13:16, 7 July 2022 (UTC)
@Doctor Duh You are right, for someone that does not know anything about edit distance, this data may be unintuitive. But edit distance is more informative for an expert. I really think that by using the idea of edit distance here, this concept becomes more frequent among people. I have an idea too. We can show both items, i.e., both "Byte size difference" for beginners and "edit distance" for experts, be shown here.
Technically edit distance is

The minimum number of operations required to transform one string into the other.

implementing that technically is not hard. Hooman Mallahzadeh (talk) 11:49, 7 July 2022 (UTC)
@Doctor Duh@Terasail Implementing for different scenarios like copy/paste scenario makes it more difficult, but I think number of scenarios is small and we can implement that. Hooman Mallahzadeh (talk) 13:24, 7 July 2022 (UTC)
@Doctor Duh @Terasail And I should note that "Byte size difference of editions is equal to -5", is so much ambiguous that nearly says nothing about what happened in the article, it says nothing about how much change have been occurred in the article. These are some probable scenarios:
  1. a word omitted - in this case edit distance is equal to byte size change by a sign change
  2. in article many changes occurred but size difference is equal to -5 - in this case edit distance is big
  3. very small parts changed but size difference is equal to -5, - in this case edit distance is small but greater than 5
  4. some copy/paste occurred and a word omitted - in this case, "edit distance" information is much more reliable
Among these scenarios, only in the first scenario, byte size has good information about what has been occurred in the article. Edit distance says how much (minimum) operations required to achieve the next edition of an article. Hooman Mallahzadeh (talk) 13:57, 7 July 2022 (UTC)
I find just remembering the bounds of a metric is often sufficient for practical intuition in this kind of thing. From the Levenshtein distance article:
  • It is at least the difference of the sizes of the two strings. [Lower bound]
  • It is at most the length of the longer string. [Upper bound]
  • It is zero if and only if the strings are equal. [Null case]
Moving blocks of text wouldn't count, but if that's a desired feature it's an easy addendum to the code (appearing as "mv" text on the Watchlist or something). As for the issue of minor copy edits, they can still vary in byte difference, and that's what the "minor edit" flag is for. There is no non-linguistic algorithm that can determine if a "small" edit may actually be vandalism: it takes only 4 chars to do Jeffrey Dahmer was a jerkJeffrey Dahmer was not a jerk.
Of course my preference for quantitative metrics is determined first by the Rule of Cool (first search result is such a downer), but I imagine this idea would lose a lot more people if we brought in some stat mech spice. So regardless I'm on board 100%. SamuelRiv (talk) 14:10, 7 July 2022 (UTC)
  • @Hooman Mallahzadeh: this idea has been proposed in phab:T10571 - I don't think this is anything that we can just do here on the English Wikipedia (having to run some script to rewrite every one of those values on each line for everyone is really unlikely to happen - but maybe you could do some initial trials with a personal user script) - and that it is something that would be best done server side. You can join in the discussion at T10571 to further develop it. — xaosfluxTalk 14:06, 7 July 2022 (UTC)
    Yep - I proposed this a few months ago as well and was told the same IIRC. Cross-fingers we'll get it at some point. Theknightwho (talk) 22:45, 7 July 2022 (UTC)
  • Good idea (whether original or not). In particular, I would love my watchlist to show at a glance whether Some article‎ (2 changes history) .. (0) .. [Vandal420; GoodGuy123] has a net change of zero because the first edit was reverted (nothing to see here) or for other reasons (investigation required). Certes (talk) 17:42, 7 July 2022 (UTC)
    It would certainly make life easier for human patrollers, yeah. Theknightwho (talk) 22:46, 7 July 2022 (UTC)

One way to clarify the size of the edit is to show separate values for characters added and characters removed (characters changed contributing to both values). So an edit that changes 1,000 characters but does not affect the total size of the article would be shown as "+1,000 −1,000". Gdr 07:57, 18 July 2022 (UTC)

@Gdr I am not agree with you! A single value showing «functionally» the amount of edit distance is more appropriate for patrollers. But you are right, we can tooltip edit script operation numbers. For example, edit script summary could be shown in a tooltip as:
Edit distance = {{tooltip 100 ins:50, del:48, subs:2}}
which yields:
Edit distance = 100
which in tooltip, we show that this edit distance that equals 100, is made up of 50 insertions, 48 deletions, and 2 substitutions (assuming operations of Levenshtein distance). Hooman Mallahzadeh (talk) 08:43, 18 July 2022 (UTC)
I like the idea of splitting the edit distance into insertions and deletions with their difference being equal to the byte size change. This would be both informative enough for experienced editors and intuitive enough for beginners. Some examples:
no change → (0)
(in → on) → (+1/−1)
(in → where) → (+5/−2)
(in → into) → (+2)
(into → in) → (−2)
(unconditionally surrender → surrender unconditionally) → (+9/−9)
Petr Matas 07:42, 19 July 2022 (UTC)

Merge reform

Adapting a comment I made on Discord last month:

Does this situation sound familiar to anyone else? You nominate a textbook merge for topics with clear very heavy overlap per guidelines [WP:BROADCONCEPT and WP:MULTIPLENAMES]. You get a bit of early support from one or two users following merge discussions. Then an oppose from a newer editor who's clearly a specialist in the area and thinks the miniscule difference in scopes between the articles is the most important distinction in the world. And then, after a few weeks/months, another along the same lines. And then another. And then a no consensus close from someone too timid to go against the numbers. This very much isn't the first time I've encountered this; merge reform can't come soon enough.

I'm looking for concrete suggestions about how to change the merge process to make it functional again. I think having a tighter timeframe and involvement from a dedicated group of editors independent of the topic is essential, and that we could take substantial inspiration from the many XfD forums that function (comparatively) well. {{u Sdkb}} talk 16:56, 10 July 2022 (UTC)

Notified: WT:Merging, WT:WikiProject Merge, WT:BROADCONCEPT, WT:Ambiguous subjects. {{u Sdkb}} talk 17:05, 10 July 2022 (UTC)
  • A general comment: it is incredibly difficult for non-experts to reliably and generally distinguish between cases where an apparently "minuscule distinction" is important to a general audience and where it is not. One could just as easily come to this discussion with praise for stubborn experts who refuse to allow a drive-by discussion from some people who don't know better to conflate two topics whose difference matters. Protonk (talk) 17:37, 10 July 2022 (UTC)
    I'd say that, as a general rule, if you need to be an expert to tell the difference between two topics even after reading their respective articles, then they're closely related enough that they should be merged under WP:BROADCONCEPT. The most ideal editors to hear from would be those with both subject expertise and WP guidance expertise, but such editors often do not exist. What's currently happening is that subject experts are dominating discussions, and failing to understand that, per our policies, the question is not "are these two things identical?" (they almost never are) but rather "are they closely related enough that they do not justify the substantial cost of forking them?" {{u Sdkb}}talk 18:08, 10 July 2022 (UTC)
    it's hard to judge the merit of what you're saying without some examples. can you point to a few instances of insignificant differences being overblown by experts/enthusiasts? TryKid [dubiousdiscuss] 18:21, 10 July 2022 (UTC)
    If one starts from the assumption that differences which aren't immediately apparent to non-experts don't require differentiation then they will invariably conclude that a merger should proceed regardless of expert opinion. Protonk (talk) 19:17, 10 July 2022 (UTC)
  • One thing that makes creating a “process” for mergers difficult is that “merge X into Y” is not always the best option. While parts of X might work well in Y, other parts of X might best work in Z (etc). We thus need to keep mergers somewhat flexible. Blueboar (talk) 17:43, 10 July 2022 (UTC)
  • As always, it would we good to have some actual concrete examples to go on. Wikipedia works by such concrete examples, rather than possibly hypothetical cases. Could we start by having some evidence that the merge process is dysfunctional, as implied by the OP's statement that we need to change the merge process to make it functional again. Phil Bridger (talk) 18:19, 10 July 2022 (UTC)
    @Phil Bridger and @TryKid, I sometimes leave out specific examples since I want us to focus on the broader issue rather than particulars of a single case, and since I don't want to seem like I'm just appealing a specific result. With those caveats, the close that motivated me to post here was at Talk:Oriental studies#Proposed merge of Asian studies with Oriental studies, where the current lead of Asian studies begins Asian studies is the term used usually in North America and Australia for what in Europe is known as Oriental studies. {{u Sdkb}} talk 18:56, 10 July 2022 (UTC)
  • I suspect that there is a bias that encourages "oppose" votes on discussion posts such as proposed mergers. For every one oppose vote from a vocal SME with idiosyncratic views about overlap, there may be a dozen or so lurkers who believe the change is so common sense that there is no need to leave a supportive comment. The solution may be to encourage a shorter discussion period, followed by a WP:BOLD merge by the proposer. Schierbecker (talk) 19:19, 10 July 2022 (UTC)
  • Many mergers are content matters, and the apparent problem that's driving this proposal is the fact that merge discussions receive input from content editors? – Uanfala (talk) 23:59, 10 July 2022 (UTC)
  • In the few merge discussions I've initiated and participated in, I've found it to be a lot smoother of a process if you make the proposal, wait around a month (or longer depending on the size of the page/what's being merged), and then do it yourself if there's no opposition or comments whatsoever. Unless you're seeking a WP:HISTMERGE (which you shouldn't be in most merge cases), bold merges are very easily undone if someone refutes them in the future. Anarchyte (talk) 04:25, 11 July 2022 (UTC)
  • Justlettersandnumbers and Talpedia had a discussion recently at Wikipedia talk:WikiProject Medicine#Preventive and social medicine related to this point. You can't always tell from the name what the difference is, but when there actually is a material difference, then it should be possible to write and source a paragraph that says "Foo and bar are both types of baz, but they are different because foo is qux and bar is quuz." I would think that any actual experts in such a discussion would be very well placed to identify such sources. Such a paragraph would not only be useful for readers, but should make it clear to future editors why the article hasn't been merged. WhatamIdoing (talk) 18:38, 11 July 2022 (UTC)
    • I'm a fan of this. Given my experience I'm not sure it will always result in a merge, since in this case I added some details to a couple of articles then moved on to other this, but at least some useful information is added to the articles, the articles are linked for readers and the link encourages future readers or editors to considering merging or add more information - which is perhaps a good alternative to lots of messages on talk pages without clarity about what is actually true. I'll repeat what I said before, that it isn't necessarily easy to find sources that do this sort of "meta-commentary" comparing different fields, but I guess in the cases where I've tried to do this I have suceeded eventually.
    • I'd also throw in the sometimes I'm not sure that merges are always based on literature comparing the two topics. Sometimes you get "self-contained literature" that aren't connected to the rest of the literature (kinda like pseudoscience) and you might want to merge to add contextualization (Victim mentality and Trauma come to mind) or (Mental illness denial and Antipsychiatry)) and the choice to merge is more of an editorial decision than one based on the literature. Who knows if this sort of "editorial original research" is a good thing. It feels sort of related to the "See also" sections in articles. Talpedia (talk) 22:37, 12 July 2022 (UTC)
  • I have seen this and it doesn't make me think of merge reform. IME, merge discussions take a long time (I usually give them a year). You often don't get the result you're expecting and I try to flow with that. As articles are improved the issue usually becomes more clear and a consensus you're comfortable with will typically emerge. ~Kvng (talk) 13:50, 13 July 2022 (UTC)
  • This is too abstract a proposal to give a solid answer. Yes, there are times where I've seen two articles duplicate most of the same subject matter, and they really should be merged, as per WP:MULTIPLENAMES. But there are other times where two articles cover different material as per WP:MULTIPLESUBJECTS and should continue to be treated as separate articles. All that said, I think some type of WikiProject could be beneficial here. (Compare: Wikipedia:Articles for improvement or Wikipedia:Counter-Vandalism Unit) But it would be hard to keep it free from bias, and there's a risk it promotes a WP:BATTLEGROUND instead of encouraging more consensus building. Shooterwalker (talk) 20:38, 13 July 2022 (UTC)
    • We do have WP:WPMERGE. I think you're suggesting project members could take a more authoritative role in closing merge proposals so that the forest perspective has more sway than the trees. ~Kvng (talk) 20:56, 13 July 2022 (UTC)
  • I fully agree that the merge process is broken; not enough independent editors see the discussion, and it takes far too long for the discussions to be closed. I have wondered if this could be addressed by merging the merge process into WP:RM. BilledMammal (talk) 21:54, 13 July 2022 (UTC)
  • Can people get notified of requested merges in certain topics similar to how people are notified of RFCs through Wikipedia:Feedback request service? If not, perhaps working towards a tool like that would be useful imo. — Ixtal( T / C ) Join WP:FINANCE! 12:35, 16 July 2022 (UTC)
    Merge requests are included in WP:AALERTS. --Redrose64 🌹 (talk) 16:09, 16 July 2022 (UTC)
  • I've made some comments in the past on merge reform, among which are to look at turning WP:Proposed mergers into something useful and make it function like WP:RM, where merge discussions still occur on talk pages of one of the involved articles, but open discussions are automatically listed in a centralized place. In regards to the original post above, I can see how it's frustrating when someone comes along to the discussion late and spoils what was previously an unopposed proposal, but if that user is a subject-matter expert, don't we want their input? These are discussions, not polls, so take their initial opposition and discuss further until consensus is reached. That said, if one is truly worried about or dislikes someone coming along and opposing the merge, and believe that such a user isn't really strongly opposed to the merge (i.e., would not contest the merge if it had already happened) or they really are in the minority if there were only more participants in the discussion, then I will point to the fact that 1) merges can be done boldly on a WP:BRD cycle, though reverting a bold merge becomes more difficult and problematic as time goes on due to follow-on edits of the merged article, and 2) merge discussions can be closed after 1 week, even by the original proposer, per WP:MERGECLOSE. So, the real value in initiating a merge discussion is to check for subject-matter experts or other users who are watchlisting the page who may oppose the merge. I've only rarely encountered this, and sometimes they have valid reasoning for why a merge is ill-advised. More often, you encounter WP:SILENCE or get 1 or 2 support comments and can proceed with the merge with some confidence it is unlikely to be reverted. There is usually no need for a merge discussion to go on for months; the reason why many merge discussions do is because the proposer expects someone else to do the merge. If the user who most strongly believes the merge should happen would just complete the merge, then that avoids many of the issues raised above. Overall though, IMHO the merge process is not as nefariously awful and some users believe, the problem is most users don't follow it. Mdewman6 (talk) 21:21, 21 July 2022 (UTC)

Track Changes / Show Markup to Display Edit History

Alternative to the Compare Selected Revisions diff viewer. Have a version where you can select (Revision 1) to (Revision 2) and then view an inline markup / changes comparison of the results superimposed over the actual page with colorization per user. An implementation reference for such a feature is the Google Docs collaborative editing feature, which shows each user with a color next to their edits. Ex: Added some text (User1, 00:00, 01 Jan 2022)Removed some text (User2, 00:01, 01 Jan 2022) Possibly with the names and timestamps only visible with onHover/onMouseOver. I believe this would make it easier to find changes on particularly active pages such as Portal:Current_events where some days there may be 100's of edits and it can be difficult to find when a specific edit was added or removed. This seems like it would also make contentious edit war pages easier to see at a glance because they would look like AddedRemovedAddedRemovedAddedRemoved in any region that was especially fought over. Araesmojo (talk) 21:50, 13 July 2022 (UTC)

You may be interested in Wikipedia:WikiBlame or mw:Who Wrote That?WhatamIdoing (talk) 21:08, 18 July 2022 (UTC)
@WhatamIdoing Thanks. Who Wrote That is pretty close to what I was considering. Had never heard about that tool or seen it advertised. Be nice if it was integrated other than as a browser extension. However, accept that its a close answer. WikiBlame is oddly named. Adds functionality, yet not quite what I was recommending. Araesmojo (talk) 19:28, 28 July 2022 (UTC)

WP:Vital Direct

I've written down sorta a plan to boost the production of WP:Vital Articles, which in the last 15 years have made zero progress. What do you think about the plan and how could it be improved? CactiStaccingCrane (talk) 02:29, 15 July 2022 (UTC)

Anyone? CactiStaccingCrane (talk) 10:28, 27 July 2022 (UTC)
I am not sure where the plan is on the page? Wakelamp d[@-@]b (talk) 05:10, 29 July 2022 (UTC)
The Vital Direct plan is as follows: Make two Vital GAs, one broad, one controversial. Doing so would give us a lot of experience at tackling other Vital articles, as well as giving cred to the project (similar to how the WP:MILHIST and WP:AVIATION have done in the past). Making 2 GAs would also prove that the first success is not just a fluke or hype. Improve the lead/image/layout first, then add citations to uncited statements. Only afterwards does experts' knowledge is required, which the experts would probably be noticed by a flurry of activities in the article. Lure them in and collaborate with them. Do not improve the prose – just make them readable first. These processes would probably take about 2-6 months if done efficiently.
Then, once the group is satisfied, a simple copyedit and final check take place, then the article gets nominated for GA. If the nomination failed, improve till the last reviewer is satisfied. If the nomination is successful, well done, go out have a drink or something, and get back to work with the other GA. The articles can be pushed all the way to FA if we want to, but it is not mandatory nor necessary. Hopefully by then these efforts would inspire other editors to take initiative and do the same. I originally tried to tackle Science and United States, but the former is immensely difficult, and the latter is currently being haunted by LTAs. So, I organize a trial drive of expanding short Vital articles to garner experience instead. CactiStaccingCrane (talk) 06:06, 29 July 2022 (UTC)

Incentivise article improvement

Background: The ArbCom are some weeks into taking evidence about Conduct in deletion-related editing. I've been watching, thinking, and trying to imagine a solution to what I perceive as the underlying problem. On the face of it, the problem is behaviour at WP:AFD. This idea, attempts to deal with the issues that motivate editor behaviour.

I raised this issue here, and @Tryptofish suggest I post here.

The Problem (my amateur psychology musings): The problem is human tendencies. Consider the politician who makes the front page of the local newspaper for opening a school. Consider how no politician ever gets on the front page for quietly, smoothly running a school. It's human nature, we value starting things more than maintaining things. And it's the same here. Editors like to say how many articles we created, tools allow us to see that and compare ourselves. It plays to our nature: enjoyment of competition, gamification. Tools, as far as I know, don't make it easy to see how many articles we improved. Less editors, I think, boast on their user page how many gnomish improvements they made. I am sure I am not alone in getting a little dopamine hit every time I create a new article. Likewise I have seen people boast on user pages how many bad pages they got deleted, I am sure people get a little satisfaction knowing they improved the encyclopaedia, removed the junk, maintained the standards. Which leaves us with behaviours, supported by tools and culture that gives little rewards for creating and little rewards for deleting. Less clear rewards and less strong incentives exist and to measure or undertake article improvement. Humans respond to incentives. We are emotional animals that like to feel good about ourselves. We tend to do what we can measure.

Suggested strategic solution: We need to incentivise article improvement. Mass stub creation is only a problem when there is not an equal or larger effort to improve them, I say that with the assumption that all these articles about Olympians, sports people, islands, or TV shows are notable. I assume good faith by those who create them. Wikipedia would be better if there were better ways to measure article improvement. We need to add gamification: rank editors by their efforts to improve articles. Maybe the Article Rescue Squadron should have been called the Article Improvement Team. Maybe the tendency to frame this as tension between deflationists and inclusionists is wrong and it's more of problem about lack of article improvement efforts and incentives. CT55555 (talk) 21:12, 15 July 2022 (UTC)

  • Rank editors how? We've already got various things like Wikipedia:List of Wikipedians by article count, Wikipedia:List of Wikipedians by number of edits, Wikipedia:List of Wikipedians by featured list nominations, Wikipedia:List of Wikipedians by featured article nominations, and similar, plus people already collect barn stars and other forms of WikiLove and thanks, icons for WP:GOOD articles they've worked on, etc. There are various gamified drives to improve backlogs in some areas (e.g. I'm taking part in Wikipedia:New pages patrol/Backlog drives/July 2022), and thinking of NPP in particular there's lists like Wikipedia:Database reports/Top new article reviewers, etc. I am however also conscious of WP:EDITCOUNT. I personally don't create many articles and am definitely more of a WP:GNOME/WP:ELF. -Kj cheetham (talk) 13:56, 16 July 2022 (UTC)
    I hope others might chime in with ideas about how. But I still think we need to incentivise to me more like you. At risk of relying on anecdote, I think you have edited more articles I created more than anyone, and I see your role-model behaviour as a statistical outlier. I don't mean to diminish anyone else's work, but what I see from reading the ArbCom case is a consequence of too much focus on creation and deletion at the expense of article improvement. Maybe I should ask, what motivates you so we can try and bottle and replicate that?
    Also the "number of edits" I think encourages small bot like edits over article improvement. I note we're not comparing Wikipedians by volume (kb) of kept content added, Wikipedians by number of articles improved out of stub. CT55555 (talk) 14:09, 16 July 2022 (UTC)
    Highly likely I think I'm not a "typical" editor. :) Stats based on articles moved from stubs would be very hard to track technically I think, if relying on people from projects to manually classify articles. Something by volume of content could be interesting though... Things like https://xtools.wmflabs.org/ec/en.wikipedia.org/Kj_cheetham can tell you average edit size, and the ratio of small/big at least for a single editor, and things like https://xtools.wmflabs.org/authorship tell you what fraction editors contributed to a single article. I suspect I find looking at stats more interesting than most people. (I do have a highly scientific background.) Barnstars and Wikipedia:Service awards are slightly motivational to me, as well as watching numbers increase, but generally I just like to try and make things better by doing some of the "boring" things other people don't tend to like to do, though I primarily focus on biographies most of the time. I try to stick to uncontraversial things most of the time (hence I work on things like WP:RMTR rather than closing discussions) and mostly staying off the "drama boards", and I like to do little edits than require minimal thinking by me a lot of the time. -Kj cheetham (talk) 14:24, 16 July 2022 (UTC)
    There are some ways in which we encourage article improvement, for example 5x expansion DYKs are an excellent way to earn WikiCup points. There are also improvement projects like Women in Green or the Core Contest. But perhaps we should have more ways to celebrate content creation and improvement outside DYK and GA/FA. —Kusma (talk) 14:36, 16 July 2022 (UTC)
  • One of my fellow editors expressed the sentiment that Wikipedia is not a video game, and I agree wholeheartedly. Humans are good enough at creating hierarchies without making it this formal – we already have lists of our works on our userpages, and barnstars... I would oppose any sort of further social-status-based incentive to write articles. Another editor pointed out DYK – main page exposure is definitely a neat reward for a new or expanded article, as is the very formal DYK credit you receive for it. theleekycauldron (talkcontribs) (she/they) 03:50, 17 July 2022 (UTC)
    @TheleekycauldronI think we have to careful that we don't start to think that there is only one way to Wiki. I am sure there is shortcut for that, but I can't remember it. I understand people who don't want social status incentives, but there are 30 or 40 K regular editors, we are largely anonymous so the status isn't really that hig. Wakelamp d[@-@]b (talk) 12:56, 17 July 2022 (UTC)
@CT55555 "Maybe the tendency to frame this as tension between deflationists and inclusionists is wrong and it's more of problem about lack of article improvement efforts and incentives." I agree. My personal bugbear is drive-by taggers, and the various "this article needs improvement" tags. Yes, you have found a problem, well done - now fix it. I think that is in part because of mismatched incentives, and of power imbalances. The NPP tools allow and editor to rack up edits faster than if they were playing Galaga with tags. but does that improve WP? Wakelamp d[@-@]b (talk) 12:58, 17 July 2022 (UTC)
Thing is… tagging is a step towards fixing. I can identify a problem with an article just from reading it… but not know the topic well enough to know how to fix that problem. For example, I can say “hmmm… this statement needs a source” but not know what the best sources are… so I tag it with a “citation needed” tag so that other editors (who DO know what the best sources for the topic are) can follow up and add the needed citation. Blueboar (talk) 13:27, 17 July 2022 (UTC)
@Blueboar I am 50/50 on the citation tags, because although they are a great collaboration tool, however
  • Tagging stubs is redundant, on the benefit of tagging mid-class articles I am uncertain, but i agree for others for the reasons you mention. Wikipedia:Template index/Cleanup has similar advice.
  • Tagging is shaping the way WP works in negative ways. When an editor tags it satisfies the itch, by moving the resposibility to subsequent editors. If enough editors existed, then it would be great process, but they don't {based on the age of unaddressed tag edits and the huge backlogs). Instead, mass tagging could be seen a way we reduce the impetuous to change, so that new editors stay, Wakelamp d[@-@]b (talk) 03:36, 18 July 2022 (UTC)
I do think that certain kinds of tags are pointless. Do we need a (visible) {{more footnotes}} banner on a one-sentence substub? I don't think so. I don't think it provides value to us, and I don't think our readers are so stupid that they can't count the number of little blue clicky numbers all by themselves in extremely short articles. Most readers can count up to at least three pretty reliably.
I'm also doubtful that these tags produce improvements merely by lingering at the top of the page. Maybe if someone's actively improving the article, they'd respond, but when nobody has made a substantive edit in the article for a long time, then it's probably pointless.
Also, in terms of edits, the way to make lots of edits is generally to do nothing important. Fix a tiny formatting error. Remove your pet WP:CLICHE. If you want to a contest to really improve articles, then Wikipedia:Citation Hunt has a leaderboard. This month's leader has posted only 51 citations. I bet you could beat that. WhatamIdoing (talk) 21:17, 18 July 2022 (UTC)
The justification for tags is that they urge users to become editors. The justification for this is personal experience But there is no quanitiative proof that that first edits are tag corrections or ...., but I am not certain whather quantitative data would be compelling in our process.
I must disagree that "Most readers can count up to at least three pretty reliably.", as I think we are underestimatimg as I remember in Watership Downs rabbits can count up to four. :-)
And I shall try to avoid talking in cliches, but only "At the appropriate juncture.In the fullness of time. When the moment is ripe. When the necessary procedures have been completed. Nothing precipitate, of course." Yes, Minister Season 1 episode 5 Wakelamp d[@-@]b (talk) 06:14, 19 July 2022 (UTC)
Then if we assume readers have the intelligence of rabbits, we can quit putting {{more footnotes}} on any stub with 4 or fewer ref tags. WhatamIdoing (talk) 20:36, 26 July 2022 (UTC)
Also, much more in the range of pet peeves, we have no evidence that these tags actually have the desired effect of converting readers into editors. It's plausible but untested. WhatamIdoing (talk) 20:44, 26 July 2022 (UTC)
I don't think tagging is a problem. I do both, as in, I both tag, and I remove tags. I both improve articles (from creating new ones to rescuing bad ones) and get others deleted. IMHO, tags "look bad", making our articles more obvious work in-progress, ugly to the readers, but are important both as indicators of what needs to be fixed, and yes, reminder for the readers that many articles are not finished and that they can help. While I do agree tag bombed articles are not aesthetically pleasing, I think it's ok. Bad, untagged articles which "look" good are not a service to the readers. It's better for everyone to see there's a problem then to mask it with swathes of problematic content that looks good for uninformed readers. Piotr Konieczny aka Prokonsul Piotrus reply here 11:28, 18 July 2022 (UTC)
In the past, I've tried to use notability tags to give editors time to address the notability issues prior to taking the article to AfD. I no longer do that, due to a very negative reaction from an editor, but I believe it is generally a good practice, and a step towards improving the encyclopedia, either by improving the article or deleting it. BilledMammal (talk) 13:23, 18 July 2022 (UTC)
  • I seem to detect (but I apologise already if I'm wrong) that there's an underlying suggestion that NPPers are at fault for either over-tagging, or not immediately addressing the issues. I would just like to point out however, that fixing articles is absolutely not within the NPP remit. If it were, the huge backlog would be even bigger. Let's also not forget that anyone, however inexperienced, can tag articles; the only thing they can't do is pass them as reviewed for indexing. There are millions of perma-tagged articles and most of them will never be improved; Wikipedia needs to find a way to ensure that at least the creators of new articles are made aware of the minimum required standards before they click 'publish', Currently they are not informed. Kudpung กุดผึ้ง (talk) 00:57, 19 July 2022 (UTC)
    Nothing about my suggestion has anything to do with NPP, which is something I am completely under informed to have an opinion about. I have only good things to say about the editors who do the effort to review the huge number of new pages. I did not intend to suggest otherwise. CT55555 (talk) 01:47, 19 July 2022 (UTC)
CT55555 ,It was a general observation and there was nothing to suggest that you in particular were responsible for any trend I felt I detected in the thread. That said, you may wish to get up to speed with what WP:NPP is all about and apply for the user right and help out. It looks to me as if you already have more than sufficient experience and it would be much appreciated. Kudpung กุดผึ้ง (talk) 02:16, 19 July 2022 (UTC)
Thanks. I did consider it before. I looked at the process and felt a bit intimidated by the user interface and rules and decided to keep my focus on article creation instead, but I'll reconsider. I fear it is a role that attracts confrontation and I'm already borderline stepping back from Wikipedia due to the nature of some debates, but I'll not use this space as any more of an outlet on that now. All the best. CT55555 (talk) 02:20, 19 July 2022 (UTC)
@CT55555 I beleive that was addressed at me. Choosing incentives can be tricky, as there are often unintended consequences, especially if they are blanket or are not in line with a desire path. There is an adage (apoligies I can't remember the ref) that any part of an organisation/person will optimise itself at the expense of the others, and the origanisational goals.
Rejection of new incentives that you may not perform well against, or reduce your existing status, is very human. Even if we are not a video game, people deserve recognition and satisfaction for their ggo faith work.
@Kudpung I think the NPP do a great job, but there is a possibility of tool misuse that I think an article on the NPP page acknowledges.
So, are there any stats on what % of how many tags are added by NPP/automated tool users? About ten years ago there was a WMF foundation paper by the NPP tool creator, where he expressed his disquiet at how it had changed WP, particularly to do with new editors. NPP automatically judge new articles, by tools that we oo not provide new article creators (10 hours work versus 10 seconds to review). The justification why we don't is that vandals might use these tools in the same way google does not reveal pagerank for fear of SEOs.
Wakelamp d[@-@]b (talk) 07:36, 19 July 2022 (UTC)
Wakelamp, New Page Reviewers do not use any automated tools for their work and they do not judge or criticize the articles' creators. Apart from being able to pass articles as reviewed there are no tools that are not available to anyone else in Twinkle and the NewPagesFeed. Everything is based on having enough knowledge and experience to correctly asses the quality and notability of a new article, and more often than not it means checking out the sources. I would be extremely concerned if any NPPers think 10 seconds is enough to thoroughly review a new page.
I don't know anything about a ten-year-old paper by the NPP tool creator. but I would be very interested to read it. I knew the the team of tool creators personally - I collaborated with them in 2012 on the development of the new NPP system. Any negative effect of the tools or even ACTRIAL has been thoroughly disproved and acknowledged by the WMF in an in-depth scientific study. All Wikipedia wants now is more New Page Reviewers of the right calibre, some bugs and a couple of new features in the software being addressed, and better incentive for new users who create articles to create them properly.
Probably the best solution would be to end the constant experiments with the design and function of the Article Wizard, rebuild it to the professional principles of UX and communication studies, give it a sleek modern look, and insist that new editors use it. The mantra 'The encyclopedia anyone can edit' does not mean 'Come to Wikipedia and dump your spam, junk, CV, and garage band here'. Kudpung กุดผึ้ง (talk) 10:48, 19 July 2022 (UTC)
Do you think that new article creators should have access to any of the page curator tools? Specifically the reliable source check? Wakelamp d[@-@]b (talk) 11:57, 20 July 2022 (UTC)
First, "New Page Reviewers do not use any automated tools" @Epochfail refers to them as semi-automated tools, so both of us are correct.Wakelamp d[@-@]b (talk) 23:11, 20 July 2022 (UTC)
Second, "and they do not judge or criticize the articles' creators" Indirectly The Rise of Warnings to New Editors on English Wikipedia"..we discovered a distinct trend: a marked decrease in praise for contributions (anything from a simple “great job on that article!” to a barnstar), and a simultaneous increase in warnings and criticism delivered via templates" and page curator has "Over 70 different tags are provided, ... You can ...add them to the page all at once."Wakelamp d[@-@]b (talk) 23:11, 20 July 2022 (UTC)
Third, 'if any NPPers think 10 seconds is enough to thoroughly review a new page." I agree. That was hyperbole on my part, but it seems PDQ. How much time would a NPP spend on reviewing a page?Wakelamp d[@-@]b (talk) 23:11, 20 July 2022 (UTC)
Fourth, "Paper by NPP tool creator. but I would be very interested to read it." @Epochfail metawiki:Research:Newcomer_quality 2012 "Semi-automated revert tools were brought in to deal with exponentially-increasing numbers of undesirable newcomers; the results suggest that using these tools to reject undesirable newcomers may have little effect on the desirable ones, but that using them to reject the undesirable edits of good-faith newcomers may decrease retention.", 2013 "Specifically, the restrictiveness of the encyclopedia’s primary quality control mechanism and the algorithmic tools used to reject contributions are implicated as key causes of decreased newcomer retention. Furthermore, the community’s formal mechanisms for norm articulation are shown to have calcified against changes—especially changes proposed by newer editor", and 2011 "Don't bite the newbies: How reverts affect the quantity and quality of Wikipedia work".
Fifth, "wants now is more New Page Reviewers of the right calibre" W. Edwards Deming addressed this same issue. Deming invented Total Quality Management which while initially of little impact in America. transformed a “Made in Japan” from being seen as poor to [Deming_Prize highest quality]. At the time, American manufacturing had hordes of quality inspectors, but did not allow the the worker/"New Editor" to have pride/control over their work.
Sixth, “rebuild it to the professional principles of UX and communication studies, give it a sleek modern look, and insist that new editors use it.” This won't work. Wakelamp d[@-@]b (talk) 15:11, 20 July 2022 (UTC)Wakelamp d[@-@]b (talk) 23:11, 20 July 2022 (UTC)
@Wakelamp, your comment above is quite difficult to make sense of, not least because of the large amount of seemingly arbitrary nowiki tags. Dr. Duh 🩺 (talk) 15:24, 20 July 2022 (UTC)
@Dr. Duh Thank-you. Apologies for the nowiki tags; the editor is crashing so I copied it from elsewhere. Is this better? Wakelamp d[@-@]b (talk) 23:11, 20 July 2022 (UTC)
I took the liberty of fixing a few more malformed links with this edit, but yes, thank you. Dr. Duh 🩺 (talk) 06:52, 21 July 2022 (UTC)
@Kudpung So what do you think? Wakelamp d[@-@]b (talk) 09:36, 2 August 2022 (UTC)

One sidebar note. For encyclopedia that a zillion people have been working on for over 20 years, we don't have areas left where mass or high quantity stub creation is beneficial. North8000 (talk) 13:13, 20 July 2022 (UTC):

@[[[User talk:North8000#top talk]] I don't think there is suggestion that we create more stubs, just increase the quality of existing stubs. Wakelamp d[@-@]b (talk) 09:42, 26 July 2022 (UTC)

@Kj cheetham I think this is a great idea But I think even with incentives, having enough people is going to be the major, but solvable, issue; at an hour each, there are Wikipedia:Content_assessment 4 million hours work on stubs. So,where do we get people...

  • New editors won't solve it; editor retention is decreasing, it takes years to understand WP, and you are competing against other projects.
  • Diverting editors from non productive (category assignment, tags, adding templates..) might help a bit.
  • Having lomg term editors stay by reducing conflict would help, but they don't tend to work on stubs
  • Process changes and tools could reduce the amount of work per hour, but I think the best option is
  • Crowd sourcing. The first Oxford English Dictionary crowd sourced references, but had experienced editors check. We could crowd source the selection of relevant references from an automated curated list, with the option to flag the stub as not notable. The stubs would be randomly selected within a reviewer's area of interest. Multiple users could check the same article before the article was updated; there would be no incentive for vandalsSo, instead of WP, the users would use a more open source social website that wouldn't be wikified and more like [this] Wakelamp d[@-@]b (talk) 09:42, 26 July 2022 (UTC)
Wikipedia is already the epitome of crowdsourcing. It's one of the few websites where a random passer-by can improve content without even registering. We have a few initiatives where editors can request suggestions for articles they may wish to improve; perhaps they could be made better (how?) and more prominent. Certes (talk) 12:49, 26 July 2022 (UTC)
I agree WP is very good at crowd sourcing,but we have problems on keeping editors,and diversity.

But with the calls to improve, there are no statistics on whether the current calls to improve work. They may actually harm, as there are a lot of real world User Experience work that shows that people are annoyed by long messages, and I suspect that the age when the templates are added undermines the perceived quality of WP Wakelamp d[@-@]b (talk) 23:02, 26 July 2022 (UTC)

The articles and issues are so diverse that any effort is going to overgeneralize. I wouldn't focus too much on expanding stubs. We probably have a million geographic & species stubs that are OK but which will be slow and hard to expand. We probably have a 1/2 millions stubs which shouldn't be articles. Much of our flow of new articles are promotional (aspiring musicians, aspiring Bollywood actors, business people who pay to get an article made on them, sports players, future albums, future movies, future tournaments) and people mass producing articles as a part of their wikipedia hobby which shouldn't be a articles To avoid pointing real world fingers, I'll just say like "I think that my Wikipedia hobby will be to make an article on each house in my town". IMO the substantive areas that Wikipedia could most benefit from more work are:

  • Where subject matter experts are needed. But between needing to learn the Wikipedia alternate universe and Wikipedia being such a vicious place, they are hard to get and hard to keep.
  • Articles imported from other language wikis. Many substantive topics from other countries are not yet covered in English Wikipedia. But when imported, they have many problems.
  • Articles related to real-world tussles (with American Politics at the top of that list) are all in bad shape but anybody who tries to fix them will get butchered by clever warriors. Fixing that will require policy changes.

Finally, Wikipedia keeps getting harder and harder to learn. Efforts to make it easier have been misdirected. For example, on dumbing down what is already easy (basic text editing) while expecting them to figure out how to use complicated undocumented templates and complex multi-leveled reference architectures to add a reference. North8000 (talk) 21:19, 26 July 2022 (UTC)

Sincerely, North8000 (talk) 21:19, 26 July 2022 (UTC) @(talk

Great taxonomy. Accurate evaluation of proposals to do with big problems always need statistics We need to know progress measures (new/downgrades/upgrades), users (# editors, readers, and activewatchers ), and age (improve tag, last edit, creation, date of talk topic). How would we find out these details? 23:02, 26 July 2022 (UTC)

I have a proposal here that gets largely abandoned in the Village pump called WP:Vital Direct. With some modifications, I think this plan would effectively resolve a lot of bitter conflicts between deletionists and inclusionists, by redirecting focus from stubs to Vital articles. Inclusionists would add content to the article, while deletionists cull out cruft and spams from it. And believe me, there's a lot of very short yet Vital articles that needs improvement. This is done by setting a very ambitious goal (all Vital Articles GA/FA within a decade) that is attainable via careful planning and execution. We don't need to have a big panel of experts made for improving these vital topics, we don't need to radically reform TFA/FAC/GAN, we don't need to get a thousand more new editors to do the job, nor we need to make a bazillions of RfCs on contagious topics. We already have the tools to make all Vital Articles GAs within a decade, as detailed in the plan. Furthermore, the Vital Direct plan is not exactly just Powerpoint slides stuff (like User:TCO/Improving Wikipedia's important articles), as the Vital Direct's philosophy is currently being implemented right now at the Wikiproject Vital Articles. Yes, I might sound like a shill, but I truly think that a lot of Wikipedia's inefficiencies and conflicts can be solved if we set a big overarching and meaningful goal and actually achieve it, just like what the Apollo program in real life and on Wikipedia did. CactiStaccingCrane (talk) 11:08, 27 July 2022 (UTC)

I like idea of the Apollo mission on Vital,but I doubt we have enough people unless we change policies WP is not going to die, but maintenance and lack of people will mean it declines. My personal version of Hell is WP is replaced by this project where FB/Meta is creating an AI version of WP (using current WP to train it) Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 12:45, 27 July 2022 (UTC)
I will do it. Let's see how it goes. CactiStaccingCrane (talk) 13:43, 27 July 2022 (UTC)
There is no doubt that the deletionists have won, but I don't think we have ever worked out the cost of the policy for good faith (and possibly misguided) articles. We could cost using say WP edit hours (WPED ?) with experienced editor time worth a lot more to WP, as they are less than 1 in a hundred editors, and take years to understand WP. The cost would be
  • Article creator's time ( both the article edit + expected loss of future edits)
  • NPP
  • AfD
  • A share of guideline discussions
  • Experienced editor burnout (expected loss of future edits)
  • Expected reputational risk from article being deleted (The US senate candidate)
  • Reputational risk from disgruntled article creator
  • LESS Maintenance saved over next 10 years
  • LESS Expected reading of the article over next 10 years
  • LESS Reputational benefit from article not existing Wakelamp d[@-@]b (talk)
Talking about Wikipedia's reputation feels like voters talking about whether a candidate is "electable". We'd be better off talking about what we personally/individually want, instead of pretending that we know what other people want/value. If someone were to say "I personally think deleting Bollywood stubs makes Wikipedia less useful, especially to millions of people who read English in India" and another were to say "I personally am disappointed whenever Google offers me a link to a Wikipedia article containing two sentences and two sources, because I never search for simple facts like 'Which film was that actor in?'", then we could have a functional conversation about what our editors want from an article. As it is, I suspect that we are presenting our personal preferences and pretending that they are The True™ Facts About the Whole World.
CactiStaccingCrane, have you checked the list of potential GA articles against featured content in other languages? If we've got a stub and another wiki has a FA or GA, then it might be faster to use the Wikipedia:Content translation tool to bring in a solid base, and update it from there. WhatamIdoing (talk) 18:12, 1 August 2022 (UTC)
I think that's a great idea! It's gonna be tricky to figure out how to make a query to do so though... CactiStaccingCrane (talk) 09:51, 2 August 2022 (UTC)
I am not pretending to "know what other people want/value" and included reputation only or the sake of completeness, Reputation is probably only a second or third order effect for any one article, but over the whole of WP it would add up. The decision-making methodology of using creating a model using a cost-like metric, (WP edit hours for tasks) is quite standard in business, government, and academia. (As an attempt at levity, I suspect that when building a pyramid they put the "rubbish" side facing inwards as there was no "benefit", but higher cost.)
With editors, what I suggest is
  • We need more of them, so we can incentivise them.
  • Prioritisation of WP editor work using Statistics of the trend and amount of work that is outstanding by class/importance of articles.
  • A test of whether tags encourage new editors. This could be done as a randomised trial where we remove the templates from 10K random stubs and compare the amount of new editors on those pages 10K other random stubs after 12 months.
  • Statistics of editor productivity after deletion of their new articles, including an email survey if they become inactive,
  • We need to seamlessly divert new editors of vanity articles elsewhere (Nonnotable-pedia :-)) , and to create quality at source through moving NPP checks (such as reputation) to be part of the New Article process. 02:15, 2 August 2022 (UTC) Wakelamp d[@-@]b (talk) 02:15, 2 August 2022 (UTC)
I do think that the third idea is the most likely to take off. The second idea can be done the crude way by editing Top/High importance and Stub/Start-Class articles, while the fourth idea can be kinda intrusive in my opinion. CactiStaccingCrane (talk) 09:57, 2 August 2022 (UTC)
You might not claim to know what other people want, but some editors do. To protect the guilty (and to avoid singling out individuals unfairly when they are not the only ones saying it), I won't provide any links, but I imagine that a search on Wikipedia's reputation NPP in the Wikipedia: namespace would provide many examples of editors asserting that NPP must work this way, or the Draft: space must be handled thusly, or else Wikipedia's reputation will be destroyed. WhatamIdoing (talk) 19:26, 2 August 2022 (UTC)

@Wakelamp: What do I think? Well, in 2011, Aaron Halfaker, (user:EpochFail), former Principal Research Scientist of the WMF, initiated a research program, which confirmed the importance of the NPP process:

“New Page Patrol is a vital function of many Wikipedias as the front line of interaction between new authors and community members devoted to policing the quality of the project. It has variety of detailed, quite complex possible actions for patrolling pages in all namespaces.”

I was involved in the development of PageTriage (the software name for the system we use since 2012) from the patrollers’ perspective and I can categorically state that reviewing new pages is a job that requires a lot of skill, thick skin, and a lot of putting up with aggressive reactions from creators of truly worthless 'articles' that have been confined to the trash can. The only automations are a couple of scrips that save one or two mouse clicks when reviewers have made up their minds what to do with a new article. Despite Halfaker’s revelation however, most of the WMF regard NPPers as a bunch of deletionists, while the community perceives the Foundation Growth Department’s policy as ‘the quantity of articles is more important than the quality’. For more background on new page reviewing, please take just five minutes to read NPP: This could be heaven or this could be hell for new users – and for the reviewers. Kudpung กุดผึ้ง (talk) 16:10, 2 August 2022 (UTC)

Automatic notification of users at ANI/AN; templatising AE/ARBCOM cases

At the present stage people have to manually notify every user involved in the discussion, which I think should be automated (after all, if it is so important as to be highlighted in a red box, it could just as well be at least semi-automated so that there is no chance it is overlooked. Unfortunately not being able to program, I have no idea how to implement it in code, but the idea is more or less this:

For AN/ANI:

  1. A user starts a thread about other users concerned.
  2. Writes some text
  3. When clicking "Save changes", the user is prompted (by popup or any other means) to notify users - the user has to choose a valid username (with the options to choose more) or click "I don't wish to notify anyone".
  4. An automatic comment in small font is added about the users notified for the discussion, or that none were.
  5. A bot notifies specified users (if any).
  6. Drama begins.

The only problem in this particular case is to force it to be the case only for the OP but not for the other users who happen to comment in the thread (maybe by triggering the prompt when == [Some title] == pattern is typed or when the user clicks on "New section" button?)

For AE:

  1. A user clicks the link as instructed
  2. A popup appears, similar to DYK-helper; could be some other form. Since the reported must have autoconfirmed user status, the program checks the user rights. The following fields are created: User(s) notified as accused in the case; remedy enforced (dropdown list); diffs (by id or by link), up to 20; diffs of previous sanctions, if any; awareness criteria fulfilled for each user (ticking boxes, upon ticking, the box displays a prompt to enter either a diff id or the date); additional comments, with a word counter, writing in wiki syntax (warning displayed at 500 words, hard limit at 550 words). The report is then automatically generated, either by itself or as a template; apart from the text, it generates sections titled as "Statement of [accused party]" and the admin section.
    1. For appeals, the user ticks the relevant box, and the following changes occur: "users notified as accused" becomes "admin imposing sanctions"; awareness criteria are removed from the menu.
  3. A bot automatically inserts a notification on the talk pages of relevant parties/admins.
  4. The deliberations begin.

For ARBCOM: The word limits are adjusted accordingly; prior dispute resolution box is added. Otherwise similar to AE.

I would like to see your thoughts. Szmenderowiecki (talk) 13:44, 16 July 2022 (UTC)

I don't really think we need to make it easier to open ANI or AE cases. But if someone wants to write an optional helper script, they are free to do that. —Kusma (talk) 14:11, 16 July 2022 (UTC)
The idea is more about making compliance with the rules of notification (and word limits) easier, rather than enabling more drama; and non-compliance with these technicalities wastes userhours of work. Szmenderowiecki (talk) 16:16, 16 July 2022 (UTC)
Is it really making it easier to open a case, or simply easier to open one correctly if you've never done it before? I don't actually see it as a huge problem, either, though -- the most common response to a newer editor opening a case at ANI without notifying is "You are required to notify; I have done that for you." Occasionally someone points out the big red alert, but honestly I think most editors at ANI understand that there's a lot of clutter in those edit notices, and that someone navigating the process for the first time while upset might not be reading the instructions thoroughly. valereee (talk) 16:21, 16 July 2022 (UTC)
It would seem that since pings are now well-implemented and widely known, that it is time for us to revisit the consensus against pings being sufficient as notification for such threads. It seems nearly duplicative of effort that even though someone is pinged in a thread they still need to be notified in a really clunky, manual, "old-fashioned" way as well. Did the MediaWiki team not implement user pinging for a good reason? Why not lean on this mechanism with a little more faith than we had 6 years ago? Elizium23 (talk) 20:17, 21 July 2022 (UTC)

Make Talk Pages shorter and more useful

They are long and I skim, so here are some ideas

  • All editors to show compressed view of a template. (maybe just the template name and paramaters. Show only the template name rather than an explanation. Experienced Editors know what the rules are.
  • Be able to show archived topics back on the page in say a different colour.
  • Make it easy to do mass updates without triggering watchlists. Change watchlist preference (except for admin users) to ignore minor edits to yes, and send a message to users to change back if they wish
  • Be transparent about the # of editors watching, and warn the user that know one is watching except anti-vandalim . Even on popular articles,80 % never get a reply. For instance looking at the old movie which is far better Talk:Top Gun/Archive 1 - Wikipedia. The argument is that vandalism will increase, but why not try it on a secton of wikipeia and see?
  • Watchlist on Talk transparency. Does the number of watchers include only permanent and non expired?
  • Watchlist details on user talk - why can't an editor see who is watching their own page?
  • Prompt to look at the talk page. I don't unless i see something odd, or it's controversial. Have the Tab show a nunebr similar to how email systems show open messages
  • Does archiving actually still serve a purpose? The Bulk of the page is because of the above, and slow internet connecion is a thing of the past.

"It is customary to periodically archive old discussions on a talk page when that page becomes too large. Bulky talk pages may be hard to navigate, contain obsolete discussion, or become a burden for users with slow Internet connections or computers. Notices are placed at the beginning of the talk page to inform all editors of an archive.: Wakelamp d[@-@]b (talk) 14:42, 16 July 2022 (UTC)

By "compressed" I assume you mean collapsed? Not sure how archived topics in a different colour would help? Most of the other ideas seem to be about watchlists more generally. I wish slow internet connections were a thing of the past for everyone though! -Kj cheetham (talk) 23:10, 16 July 2022 (UTC)
The issue of too many template banners on Talk pages has been raised before. I saw someone in the archives raise the idea of combining them all into an infobox – not sure if anyone's actually tried that yet.
Mass updates are typically done by bots which users can filter on the Watchlists, including to just the Talk namespaces. While some bot actions simply noise on a Watchlist (archiving, rating, category fixes), a great number of users would still like to watch bot edits for mistakes, because they do happen and can be quite controversial. Plus the bots have fairly descriptive edit summaries so it's easy enough to ignore.
Talk page tab prompts seem odd -- they would only be relevant to editors who have visited the Talk page previously, and thus likely have it on their Watchlist already... so the logical place to put a prompt (if desired) is on the Watchlist.
Regarding page size, maybe dial-up is mostly gone (places with no internet infrastructure tend not to have phone infrastructure either), but data rates and memory usage are still a thing.
Having the number of watchers visible to those wanting to post on the Talk page is an interesting idea -- I don't know if it's been explored before. I'm sure you could get a good metric for what you think would represent which editors watching are "expired" at the moment, but I'm reasonably sure most people here have had long periods of inactivity. Still, it could be useful. SamuelRiv (talk) 23:41, 16 July 2022 (UTC)
My experience is that all too many edits that are marked minor are major. It shouldn’t be a default. Doug Wellertalk 15:34, 26 July 2022 (UTC)
"minor" shouldn't be the default can you point to what part of the interface has this set? — xaosfluxTalk 15:51, 29 July 2022 (UTC)
Bots that revert vandalism mark their edits as minor. Maybe the default that needs to be changed is the one in Special:Preferences#mw-prefsection-rc-changesrc that hides minor edits from the watchlist. WhatamIdoing (talk) 18:20, 1 August 2022 (UTC)

BLP violations in non-linked on the main page

There was recently a discussion at WP:ERRORS concerning a DYK entry that had a BLP violation – not in the bolded article, mind you, but in one of the supplementary links that are just applied. BLP is a super important policy – how should we approach not publicizing violations on the main page? We could allow for unlinking if BLP issues aren't resolved... theleekycauldron (talkcontribs) (she/they) 03:46, 17 July 2022 (UTC)

(For reference, the discussion in question is here Caeciliusinhorto-public (talk) 15:54, 22 July 2022 (UTC))
BLP violations must not be linked from the Main Page. If the vio can't be fixed and the link is crucial for the hook, the hook must be pulled. —Kusma (talk) 13:53, 17 July 2022 (UTC)
Why pull the hook instead of deleting the BLP violation from the target article? Anomie 15:08, 17 July 2022 (UTC)
We seem to agree on the order of things to attempt to fix the problem. —Kusma (talk) 15:31, 17 July 2022 (UTC)
Being that Charlotte von Mahlsdorf has been dead for 20 years now, there was no BLP issue whatsoever involved in this discussion. Some editors were erroneously tagging her article with BLP issues, and that has been resolved. Elizium23 (talk) 04:29, 21 July 2022 (UTC)

Invisible comments about section's incoming links

Notifying editors about incoming links pointing to a given section seems so important, that MOS:COMMENT and WP:HIDDEN mention it as the first use case for invisible comments:

<!-- If you change this section title, also change the links to it on the pages ... --> 

I would like to see this markup standardized, for example with a template understandable even to VisualEditor (VE). For example in the article Limit of a function we could write

===Limits at infinity=== {{If you change this section title, also change the links to it on the pages Limit at infinity}} 

to inform editors (especially the VE users, as mentioned in Wikipedia talk:Manual of Style/Hidden text/Archive 1#This is now obsolete) that Limit at infinity redirects to this section. Transclusion of the template will not output anything, just like the invisible comment. A related discussion: Wikipedia:Village pump (proposals)/Archive 8#Redirects to sections in articles. Petr Matas 11:39, 18 July 2022 (UTC)

The ideal solution, which is unlikely to happen, is to warn editors automatically by checking [the API equivalent of] Special:WhatLinksHere for section links whenever an editor attempts to change or remove a section heading. We have 276,000 {{R to section}}s, plus an unknown number of section redirects without the template, so commenting every destination might create a lot of clutter as well as being a major maintenance task. Certes (talk) 11:56, 18 July 2022 (UTC)
Hidden comments are now visible in the VE (the fact that they weren't for a long time was a bug that got fixed some time ago). However, using a standardised template can bring other advantages, so the proposal sounds like a good idea. – Uanfala (talk) 11:58, 18 July 2022 (UTC)
That was fixed in 2014, as part of phab:T51603.
I'm not sure why this should be standardized. Offhand, the cons are:
  • It's more complicated.
  • More things to get 'wrong'.
  • One more fiddly little thing to learn.
  • One more Shibboleth to separate the outsiders from those of us who know the right way to do things.
  • It doesn't work if you copy it other wikis.
  • If you get a typo in the template name, you'll have a visible mess in the article.
The pros are:
  • Some of us like to have everything match.
If we wanted to solve the actual problem, then I would think that {{anchor Limits at infinity}} would be more pointful. Then you could change the section heading and still have the incoming links work. We could even set up a redirect for that template with a name like Template:Anchor for incoming links, if you were worried that people might not understand what Template:Anchor is for. WhatamIdoing (talk) 22:37, 18 July 2022 (UTC)
I must agree. Maybe the problem needs a different approach: A bot could track all redirects to sections (independently from R templates) and update them automatically. If it is unable to solve a specific case (for example, a section removed altogether), it will leave a message on the culprit's talk page. Petr Matas 08:04, 19 July 2022 (UTC)
We already have such a bot, so the problem is solved. Certes (talk) 11:20, 19 July 2022 (UTC)

Another Forum for Content Volunteer Requests

Some of the case requests that are filed at the Dispute Resolution Noticeboard are closed as not really requests for moderated dispute resolution. There are various types of requests that get filed at DRN because it is one of our content noticeboards, and is a "less wrong" place for many requests than WP:ANI, such as for someone to verify or comment on an edit, or for another editor to join in discussion at an article talk page. The suggestion has been made that there should be another noticeboard, maybe not considered part of the dispute resolution mechanism, but with a name such as Volunteer Requests or Content Advice. It could also be used to request assistance in writing a neutrally worded RFC on a topic, for instance.

Does anyone have any ideas as to some form that could be useful? Robert McClenon (talk) 00:27, 27 July 2022 (UTC)

I think this could be a good place to maybe diffuse situations before they blow up to the DRN or ANI. Getting a neutral mediator involved before they are Problems with a capital P- and just keep level heads. But also remove the idea some editors have that going to the DRN is a "punishment" or "negative mark" on their record. Nightenbelle (talk) 19:09, 27 July 2022 (UTC)

Viewing deleted pages and separating types of deletions

At Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted, the discussion ended with statements from the OTRS (now VRT) legal queue as well as WMF around legal concerns of allowing more users to see deleted pages. I suppose we could add a new checkbox when deleting pages or revisions for separating those that should only be viewable to admins from those would be viewable to a new user group. I think the easiest way to manage this is to make all current deleted revisions and pages only visible to admins by default, and new deletions could then be made available to a "trusted" group. 0xDeadbeef 06:19, 27 July 2022 (UTC)

What is this for? I thought that "deleted" should mean "deleted", meaning that it is not accessible to anyone (except admins)? If anybody can see them, how they can be called "deleted" in any practical sense? Ruslik_Zero 20:06, 28 July 2022 (UTC)
See also Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages. This is not proposing that deleted pages should be accessible to anyone, but only to an additional user group granted for obtaining evidence of vandalism/sock puppetry as well as other uses as determined by the community. 0xDeadbeef 09:24, 29 July 2022 (UTC)
This is a non-starter for any number of reasons, but I think it's still worth pointing out that for deleted articles, there will usually be a fairly recent copy stored at the Wayback Machine, as long as it was live on Wikipedia long enough for it to be picked up. Automatic archiving doesn't really happen for user- and draftspace (AFAIK because of the default search engine indexing rules), but there's usually little reason for anyone to look at deleted stuff in those, anyway. Dr. Duh 🩺 (talk) 20:34, 28 July 2022 (UTC)

Articles for Cleanup

Inspired in part by the current ArbCom case about conduct in deletion discussions, and partly by various other discussions I've been involved in recently, I've begun workshopping an idea for a Articles for cleanup process. That link goes to a first rough outline in my userspace, and I would like feedback on the idea. ~ ONUnicorn(Talk Contribs)problem solving 18:32, 27 July 2022 (UTC)

@ONUnicorn: Are you aware of Wikipedia:Article Rescue Squadron? --Redrose64 🌹 (talk) 22:12, 27 July 2022 (UTC)
@Redrose64: Yes, but I'm envisioning something slightly different. That's a project whose members might be interested in this idea. The idea however, is for a process - one that would complement AFD. ~ ONUnicorn(Talk Contribs)problem solving 22:25, 27 July 2022 (UTC)
ONUnicorn, I think you should make a demo of the process and try it on a few articles. Tweak stuff that didn't work. Retain those that does. Rinse and repeat – you would obtain a much better process than if you try to fashion everything in advance. CactiStaccingCrane (talk) 13:23, 30 July 2022 (UTC)
My overall view: It's not going to work. The threat of deletion encourages effort. The threat of nothing does nothing.
Some details:
  • I think you might want to consider the name "Articles for sourcing", because otherwise you're going to get a lot of complaints unrelated to notability or otherwise related to deletion. (This is where I dump articles with wikitext errors, right?)
  • Also, I suspect that you're going to need a WP:QPQ process. You can't dump articles here if you don't help fix someone else's. (I can just copy the ~21,000 articles listed in https://bambots.brucemyers.com/cwb/bycat/Medicine.html to your new thing, right?)
  • You might consider this as a possible AFD outcome or a way to pause the AFD process.
More broadly, I wonder if we need to encourage writing and sourcing articles as a primary activity. Tagging, "processing", and even long AWB runs to fix typos don't build the encyclopedia. To give you an example, about 14 years ago, I wrote Oculodentodigital dysplasia. There have been 63 edits by 38 editors (including me). But there are only 12 words in the entire article (never more than four words in a row) that were written by someone else. What were those 37 other editors doing? WhatamIdoing (talk) 18:42, 1 August 2022 (UTC)
@WhatamIdoing Thank you for the helpful suggestions. The main idea actually was this as a sort of AFD outcome or a pre-AFD step - have articles that actually have a shot at surviving AFD go through a different and less antagonistic process to try to reduce some of the friction at AFD. "Articles for Sourcing and Improvement" is a better name than Articles for Cleanup, or maybe "Articles for Notability Review" would be clearer.
The idea for a QPQ strikes me as both good and bad. I think some people who nominate a lot of articles for AFD don't like the requirement to do WP:BEFORE (they're busy - they're trying to get through some backlog somewhere quickly - they think the article creators should have done this work - etc.), and some of them just aren't very good at it. Moreover, if you use WP:DYK for an example of how a QPQ does and doesn't work on Wikipedia - well, it works at pushing noms through, but there are constant problems with incompetent reviews being done by people who are just trying to check a box so their own noms get reviewed. If someone isn't good at searching for sources, or thinks they are too busy to search for sources or that it's someone else's job to search for sources, they either aren't going to use the process if there is a QPQ, or they are going to do a shoddy job with whatever they are doing as a QPQ.
I like your idea of it being a pause button on the AFD process - Maybe mid AFD someone finds some sources and suggests it get sent to AFCU or AFSI or AFNR or whatever it ultimately gets called, and it's there for people to work on for 30 days and then the revised article is evaluated.
I do kind of try to leave the threat of deletion as part of it, just a less imminent threat than the 7 day AFD, with people shouting "Delete" the entire time. ~ ONUnicorn(Talk Contribs)problem solving 19:43, 1 August 2022 (UTC)
"Articles for Notability Review" sounds like the old Wikipedia:Notability/Noticeboard, which we closed. I won't give you a summary of why I think it closed, to avoid biasing your thoughts, but I think you might want to look at its day-to-day operations as well as the discussions about it. WhatamIdoing (talk) 19:31, 2 August 2022 (UTC)

Trial a different Idea Labs process

Ideas seem to have a low chance of becoming successful proposals, even though experienced editors are proposing them. Maybe the reason is due to our process, especially that we jump to a solution before understanding the problem totally, I suggest we trial a few small to medium size problems using a problem solving process with the following steps:

  • Define the problem,
  • Generate Alternative Solutions ,
  • Evaluate and select an Alternative
  • Implement and follow up Wakelamp d[@-@]b (talk) 07:17, 29 July 2022 (UTC)
Wakelamp, super strong agree. See also: Iterative and incremental development. We need this. We have stagnated for so long because we are being too bureaucratic, too un-WP:IARy, and love stuff to not change. CactiStaccingCrane (talk) 13:19, 30 July 2022 (UTC)
I don't think our editors are accustomed to separating these steps. We jump to proposed solutions rapidly, and we tend to insist upon our proposed solutions even if we're told that it won't work. Consider, e.g., the decision to spam {{unref}} into articles in 2009. That was supposed to result in editors adding sources to the articles. Nobody ever checked to see whether that worked, though. WhatamIdoing (talk) 18:45, 1 August 2022 (UTC)
Yes, I agree that using this Wikipedia for testing is a bad idea and that's why we have Test Wikipedia for such purposes. As for ideas that does not involve the main namespace or require A/B testing, it may be done here in a temporary Wikipedia namespace page. CactiStaccingCrane (talk) 10:02, 2 August 2022 (UTC)

Splitting the English Wikipedia

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

After suffering something of a burnout, I have come to the conclusion that serious discussion ought to be given to splitting the English Wikipedia into American English and British/Commonwealth English editions. I have no doubt that the "Wikipedia prefers no national variety of English" policy was made in good faith, but this means articles not tagged with either "use American English" or "use British English" are often a complete mess flipping at random in grammar and spelling. Translations and transcriptions often come down to a mere popularity contest between the American users and the other native English speakers on the site.

Bokmål and Nynorsk have separate Wikipedias, even though these are simply two written standards for the same language and are not spoken languages. While there is mutual intelligibility between American and Commonwealth English, forcing them to cohabit on the same site just seems forced and can be quite irritating, especially when it comes to grammatical and vocabulary distinctions. While the spelling distinctions are often given more attention, the grammar and vocabulary are the greatest blocks to complete mutual intelligibility as sentences which the author considers correct grammar using what are basic and universally understood words in their major form of English may seem nonsensical or needlessly complex or obscure in the other.

A possible way of distinguishing the two editions might be to retain the spelling "Wikipedia" for the American English site and use "Wikipaedia" for the new British/Commonwealth English site. There can of course be ongoing collaboration and co-operation between the two, as happens on the Wikipedias for the Scandinavian languages. TheCurrencyGuy (talk) 14:20, 29 July 2022 (UTC)

If you're getting burned out after a month and a half of editing, maybe the problem is what you're focusing on, and how you're editing, and not WP:ENGVAR shenanigans. Tens of thousands of editors over a couple decades have been able to deal with this, so the solution probably isn't splitting. ScottishFinnishRadish (talk) 14:24, 29 July 2022 (UTC)
I've been on the project for years, and I don't think annoyances over English variants have ever made it into my top 40 of wikipedia annoyances. Still, I understand that there is a problem here and that it needs addressing. Having separate wikipedias will have all sorts of obvious major negative effects, but something else that we can do is try making the same underlying text display differently to readers depending on their locale. Stuff like, inches vs. centimetres, or American vs. British spelling, or the occasional phrase with slightly different wordings. Uanfala (talk) 14:35, 29 July 2022 (UTC)
I'm burned out because this site's language policy makes absolutely no sense. TheCurrencyGuy (talk) 17:14, 29 July 2022 (UTC)
You are greatly exaggerating the problem. I, as a Brit, have no trouble reading American books and I'm pretty sure that my American friends have no trouble reading British ones. This is a trivial issue, which is not worth spending time or energy on. Phil Bridger (talk) 15:06, 29 July 2022 (UTC)
Here in America, we're so infiltrated by Brits that we don't realize that almost all of our favorite actors are actually from England. It's like They Live, but instead of special sunglasses it's seeing them buy Heinz Beanz when shopping. ScottishFinnishRadish (talk) 15:47, 29 July 2022 (UTC)
on the contrary, it's like They Live, but instead of a covert group of extraterrestrials manipulating all of human history, and working right alongside unwitting humans to do so, it is like some covert cabal of elitists saving us whimsically naive Americans by making sure we use the right fork. or something. Face-smile.svg Sm8900 (talk) 17:29, 29 July 2022 (UTC)
  • Sorry, but this is nonsense. For one thing, there's no such thing as a single "British/Commonwealth English" - try spending some time in India and you'll know what I mean. Secondly, as soon as a split happened, the two versions would diverge, different versions would be out of date with each other, and there would be no realistic chance of keeping them in sync. Finally, and most importantly, there is no significant problem anyway. We are simply not awash with Americans not understanding British English or Brits not understanding American English. I don't think I've ever seen any genuine misunderstandings in all the years I've been here - at least, none that were not trivially easy to clarify. Boing! said Zebedee (talk) 15:43, 29 July 2022 (UTC)
    For the British readers, what was meant in the first sentence was, Oi, mate! This is bollocks!ScottishFinnishRadish (talk) 15:49, 29 July 2022 (UTC)
    Hehe. Boing! said Zebedee (talk) 15:58, 29 July 2022 (UTC)
    ScottishFinnishRadish, I learned the other day that "oi" means "egg" in Swabian and Pennsylvania German. Cullen328 (talk) 16:02, 29 July 2022 (UTC)
    Maybe I can corner a niche market by advertising the eggs from my chickens as "farm fresh oi." ScottishFinnishRadish (talk) 16:06, 29 July 2022 (UTC)
  • Nah ---Another Believer (Talk) 15:45, 29 July 2022 (UTC)
  • Like Uanfala, this is nowhere near the top of my personal list of what is wrong or contentious about Wikipedia. I can only think of one other editor who harps on this issue because of their dislike of American English. Speaking as an American, I frequently read British publications and the work of British editors without a trace of any problem with comprehension. The same is true of the work of colleagues from Australia, New Zealand, Canada and so on. To me, this is a complete waste of time that has zero chance of gaining consensus. Cullen328 (talk) 15:54, 29 July 2022 (UTC)
  • It's worth noting that to the contrary of this proposal, the English project (alongside other pluricentric language projects) is actually considered a role model moving forward per the WMF's assessment in the aftermath of the Croatian Wikipedia scandal. While there's been some issues on other pluricentric projects (zh.wiki), in general the "many standards, one project" approach used by English, Spanish, etc. seems to produce much better results than the balkanization of the Serbo-Croatian, Norwegian, or Belarusian projects. signed, Rosguilltalk 16:02, 29 July 2022 (UTC)
    that reply seems highly informative. I was not aware of this issue having emerged or having been addressed previously on other wikis. thanks for your data, and please feel free to add further info and details if you wish. thanks, @Rosguill:. Sm8900 (talk) 17:30, 29 July 2022 (UTC)
    And FWIW, since I realize it was vague in my first post, as far as I'm aware the problems with zh.wiki are largely issues of political disagreements between mainland, Taiwan, and overseas Chinese editors that have led to off-site government retaliations against editors and a breakdown of internal trust within the community, not issues of spelling standards per se. signed, Rosguill talk 17:58, 29 July 2022 (UTC)
  • Just to take this proposal seriously for a moment, who is going to convert all the several million articles in the other language style, or will each of the new wikis just have enormous gaps? Johnbod (talk) 16:03, 29 July 2022 (UTC)
  • Actually, I don't think this goes far enough. What we really need is to split Wikipedia into enough versions that every single person has a version written entirely in their own idiolect and is completely comfortable and unperturbed by even a single word choice that they find unfamiliar. --Jayron32 16:10, 29 July 2022 (UTC)
A split is a non-starter. It would be technically possible to have preferences to display different varieties of English (zhwiki can display different varieties of Chinese), but it would be a lot of work to implement and to check all special cases in six million articles. —Kusma (talk) 17:46, 29 July 2022 (UTC)

And all this is why I got burned out. This is why Wikipedia is a joke.TheCurrencyGuy (talk) 16:39, 29 July 2022 (UTC)

...because of a poorly presented nonsensical RFC proposed by yourself? PRAXIDICAE🌈 16:43, 29 July 2022 (UTC)
Charming. What a ridiculous website this is. "Waaah, you can't separate them", "waaaah, you can't standardise". What a load of rot. TheCurrencyGuy (talk) 16:45, 29 July 2022 (UTC)
You're welcome to stop editing in that case. The only person who seems to have an issue with the English variants appears to be you. PRAXIDICAE🌈 16:47, 29 July 2022 (UTC)
So because I suggest an answer to the fact the grammar and spelling on the website are an inconsistent mess I'm the one with the issue? TheCurrencyGuy (talk) 16:48, 29 July 2022 (UTC)
There's already an solution in-place that is acceptable to the overwhelmingly vast majority of editors. ScottishFinnishRadish (talk) 16:50, 29 July 2022 (UTC)
By having no solution and having the website be a schizophrenic bombsite. TheCurrencyGuy (talk) 16:51, 29 July 2022 (UTC)
Again, save for a few instances, this isn't the overwhelming problem you're making it out to be. You're frustrating yourself by coming up with solutions for problems that don't really exist. PRAXIDICAE🌈 16:53, 29 July 2022 (UTC)
This website would be considered an illiterate bombsite by any reasonable metric. TheCurrencyGuy (talk) 16:57, 29 July 2022 (UTC)
If you've been having disputes where WP:ENGVAR has not been clearly applicable or is not being adequately followed, then the next step is really WP:3O or WP:RFC, or if you're sick of arguing over the trivial stuff, just walk away. And really, if you're going to protest the state of Wikipedia, surely you could have picked a meatier issue? SamuelRiv (talk) 16:54, 29 July 2022 (UTC)
I have tried extraordinarily hard, but this website's absurd indifference toward literacy is driving me insane. TheCurrencyGuy (talk) 16:57, 29 July 2022 (UTC)
I made a serious suggestion in good faith, and now I'm just getting a load of flak. Why is nobody taking anything seriously?
Fine, stew in your madness. TheCurrencyGuy (talk) 17:21, 29 July 2022 (UTC)
Goodness. You take a long time storming out the door, don't you? --Jayron32 17:31, 29 July 2022 (UTC)
TheCurrencyGuy, all that's happening is that people are disagreeing with you, and don't see any real problem the way you do. Yes, there have to be compromises over how to handle different varieties of English. And the current compromise is the one that the vast majority of community members support - and it has been working acceptably well for years. If you wish to be part of a collaborative project like Wikipedia, you have to be able to accept disagreement and the way consensus develops like this. Simply getting angry and lashing out at people because you can't get your own way is not going to achieve anything. Boing! said Zebedee (talk) 17:34, 29 July 2022 (UTC)
All I have done is make serious suggestions for a solution to the ongoing issue that the site is an illiterate mess. TheCurrencyGuy (talk) 17:37, 29 July 2022 (UTC)
I'm sorry, I can't read. What did you say? ScottishFinnishRadish (talk) 17:39, 29 July 2022 (UTC)
No, that's not *all* you are doing. You are also then failing to accept that everyone else doesn't see as big a problem as you do, and do not accept your solution. And you're getting shitty with us about it. It would be possible to discuss this in more detail - but not while you have your fingers in your ears and you're responding so obnoxiously. I suggest you need to change your approach to interaction with others, or it might not end well for you. Boing! said Zebedee (talk) 17:40, 29 July 2022 (UTC)
(edit conflict) It has been shown and explained to you why this wouldn't work and why this would take a massive amount of time and effort to do. Yet you insist on it. You call this an illiterate mess but have shown no specific example I can see where something written in British English is actually difficult to understand for an American or vice versa. If you were to come up with examples, you'd see that many solutions to these problems are actually quite simple. Issues with units of measurement, for example, can easily be fixed by using the template {{Convert}}. For what it's worth, I have no idea whether most of you are British or American or Kiwi or Australian without either looking for the info in your user pages or finding something like colour instead of color, and that just tells me you're not American, I still can't tell whether you're British or Australian or all the other kinds of English-speakers there are out there. —El Millo (talk) 17:47, 29 July 2022 (UTC)
I'm British. Many of Wikipedia's articles are in British English. Many others are so short and simple that they could pass for any variety of English, including British. As for the rest, I'd much rather have a blue link to text in a different variety of English, which I can easily understand, than the red link which would result if we split the encyclopaedia. Perhaps you could work on some user script which inserts the missing "u" into "color", or takes the spurious "u" out of "colour", according to your preference. Certes (talk) 17:41, 29 July 2022 (UTC)
You don't seem that British to me. Real British would be I'm British. Many ouf Wikipedia's articles are in British English. Many outhers are sou shourt and simple that they could pass four any variety of English, inclouding British. As four the rest, I'd mouch rather have a bloue link tou text in a different variety of English, which I can easily ounderstand, than the red link which would resoult if we split the encycloupaedia. Perhaps you could wourk oun soume ouser script which inserts the missing "u" into "color", our takes the spourious "u" out of "colour", accourding tou your preference.ScottishFinnishRadish (talk) 17:46, 29 July 2022 (UTC)
Personal attack intended to extract a negative response. How charming. TheCurrencyGuy (talk) 18:27, 29 July 2022 (UTC)
Perhaps you should check a primer on descriptivism vs. prescriptivism, especially in the internet age (which links to more in-depth topical articles). WP doesn't have an "anything goes" policy toward language and its real-time evolution, but it certainly can respond to both local and professional writing convention of the current era. SamuelRiv (talk) 17:54, 29 July 2022 (UTC)
  • I want a Scottish English version. Not a Scots version, just Scottish English, where I can write 'aumbry' without having someone change the spelling to ambry. Or I can use the word 'outwith' without fear of the GOCE. Seriously, this would be such an enormous amount of effort, for something which is (or should be) at most a very minor annoyance, it isn't worth discussing. Girth Summit (blether) 17:46, 29 July 2022 (UTC)
    Surely some code monkey could program a bot that would change Rod Stewart's Gasoline Alley to the correct British name of Petrol Alley. Cullen328 (talk) 17:50, 29 July 2022 (UTC)
    lots of aumbry'sxaosflux Talk 18:11, 29 July 2022 (UTC)

I've tried very hard, and I'm just being crucified. I simply do not understand the facetiousness and ridicule I'm getting.TheCurrencyGuy (talk) 18:18, 29 July 2022 (UTC)

Perhaps you should consider a break as your personal attacks are unacceptable and this is clearly too sore a subject for you to collaboratively deal with. PRAXIDICAE🌈 18:20, 29 July 2022 (UTC)
I cannot cope when I make a proposal in good faith and just get nailed up. TheCurrencyGuy (talk) 18:22, 29 July 2022 (UTC)
Then Wikipedia is not the place for you. It's pretty simple. PRAXIDICAE🌈 18:23, 29 July 2022 (UTC)
Charming. And this is why this website is a mess. TheCurrencyGuy (talk) 18:25, 29 July 2022 (UTC)
I think Praxidicae is just making a practical suggestion - being able to handle rejection of ideas is pretty much required here, if you want to retain your sanity. I suggest the best thing you could do now is forget this idea (as it is clearly not going to be accepted), and think instead about how you could work on things that don't annoy you so much. It was clear that the English language thing got you riled up well before you started this discussion, and it can be wise to step away from things that do that to you. Boing! said Zebedee (talk) 18:28, 29 July 2022 (UTC)
All I'm suggesting is a solution to a problem that has existed for two decades and is at a complete impasse. The amount of bad faith above is frankly astonishing. Why has nobody even taken the example I gave of Bokmal and Nynorsk into account? Those aren't even separate languages, just two ways of writing down the same language that are by definition entirely mutually intelligible. Why is the site obsessed with its American English imperialism when it could just cut its losses and fork? TheCurrencyGuy (talk) 18:33, 29 July 2022 (UTC)
The answer is because that would create more problems than it solves - as people have explained, but you refuse to listen. Anyway, I'm going to give up banging my head against the wall now. Boing! said Zebedee (talk) 18:43, 29 July 2022 (UTC)
One of the top ten visited websites on earth isn't really a "loss." Readers don't seem to be bothered, and the overwhelming majority of editors think the way WP:ENGVAR works is good enough. I suspect that most editors don't even care about or notice ENGVAR stuff. ScottishFinnishRadish (talk) 18:50, 29 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WMF

What we've got here is failure to communicate (some mobile editors you just can't reach)

Summary of overall issues: User:Suffusion of Yellow/Mobile communication bugs ProcrastinatingReader (talk) 03:08, 21 March 2021 (UTC)

Over a year ago, I reported two problems to the WMF:

(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."

(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.

But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.

This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.

We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.

Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?

WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)

I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)
Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. {{u Sdkb}}talk 08:11, 18 February 2021 (UTC)
I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talkcontribs) 09:26, 18 February 2021 (UTC)
@TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task: Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand. ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)
I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)
I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe(talk) 09:39, 18 February 2021 (UTC)
@Joe Roe: Sorry if this is not the right place, but I'm trying to find out why you can't access an article talk page if you're not logged in (on mobile). This was the only mention I could find. Do you know if this issue is being addressed anywhere? Cheers, Fredlesaltique (talk) 07:50, 18 June 2021 (UTC)
@Fredlesaltique: AFAICT the talk page link is a feature of mw:Reading/Web/Advanced mobile contributions (see § January 14, 2019 - Getting started with Talk page links), which is currently only available to logged in editors (I don't know why, though). See also phab:T54165, though that doesn't seem very active. – Rummskartoffel 11:30, 18 June 2021 (UTC)
The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)
The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk contribs) 14:04, 18 February 2021 (UTC)
I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)
Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen328 Let's discuss it 18:34, 18 February 2021 (UTC)
  • In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[13] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)
  • @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 (talk) (cont) 16:10, 18 February 2021 (UTC)
  • To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u Sdkb}}talk 18:55, 18 February 2021 (UTC)
    I agree 100 % with the your 99.9 % comment. ( :-)). The user interface is editor-centric, is an example ofConway's law to extremes and [[Design_by_committee]]. To add to the list, the bottom part of the [[Main_Page]] and worse of all all the uncollapsed header tags on Talk and Article such [[WP:NPOV]], which emphasis Editing or reading. To continue the Cool Hand Luke topic name reference, we are making readers eat too many boiled eggs of information Wakelamp d[@-@]b (talk) 00:48, 9 November 2021 (UTC)
  • I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagic ( messages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagic ( messages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)
    Pelagic: Thank you for the ping and highlighting how this is a related need for my current project. I've been following this thread and will be including the comments (and phabricator links - thank you for those!) in my work categorized under important requests for additional human or technical resources to assist with on-wiki workflows. Xeno (WMF) (talk) 15:02, 14 March 2021 (UTC)

Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)

@Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)
What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
I wish it could be brought back for all editors. Looks like bringing it in for IPs on mobiles could be the cure here. Mjroots (talk) 18:40, 23 February 2021 (UTC)
Maybe WMF cares more about the app's aesthetics than they do its functionality (hence why they made dark mode the default even though it ruins tables by making their text blend in with the background, and why the mobile wikitext editor is missing features as basic as template insertion so it can fit on the screen). ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 20:33, 13 December 2021 (UTC)
This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)
  • Does anyone with a (WMF) account plan on commenting in this thread? Suffusion of Yellow (talk) 17:21, 8 March 2021 (UTC)
    Don't hold your breath. For most WMF employees, commenting on Wikipedia using a WMF account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)
    @Guy Macon: When they did the same thing with desktop IPs, it was fixed within hours of being pointed out. Serious, not rhetorical question: what's changed about WMF culture since 2013? Suffusion of Yellow (talk) 17:58, 8 March 2021 (UTC)



When you spend three times as much money without the actual job you were hired to do changing, you start to focus more on spending all of that money instead of on doing your job. When you hire a boatload of new employees when the current bunch are more that enough to do the job, those new employees find something to do, whether that something needs doing or not. I'm just saying. --Guy Macon (talk) 18:31, 8 March 2021 (UTC)

  • User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)
    Well, imagine this. Someone is standing on your foot. You politely ask them to move off of it. They don't. You repeat your request more loudly. They continue to ignore you. It still hurts. At some point, does shouting and shoving come into play?
    If WMF doesn't like being shouted at, well—certainly, no one does. But people do not like being ignored either, and doing so is an excellent way to get them started shouting just to be heard at all. SeraphimbladeTalk to me 21:42, 14 March 2021 (UTC)
  • Action from the WMF! Onetwothreenew mobile bugs I discovered while investigating this have been triaged as "low" priority, and a fourth was lowered to "medium", after a volunteer developer had raised it to "high". All without a word of explanation. The first (unparsed spam blacklist messages) isn't a huge deal I'll agree. But why is not telling users why they're blocked or falsely telling registered users that they're blocked personally not a major concern? That's how we lose people. Suffusion of Yellow (talk) 22:55, 22 March 2021 (UTC)
    • Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)
      @Fences and windows: Yes, this can be done with the edit filter. It could even be limited to users with no confirmed email address. But there's a catch. The apps don't properly display custom edit filter warnings, either! The iOS app just displays the title of the page where the message is stored. And the Android app doesn't display custom messages at all. The mobile web editor does display messages properly, however. Suffusion of Yellow (talk) 00:10, 26 March 2021 (UTC)
      If this were a lower-priority issue, I would say we should come back in a month and see if the WMF fixed it. But this is such a glaring oversight that I feel this may be the only option if we want to fix this. Question: would this apply to just the app, or to the mobile site as well? —pythoncoder (talkcontribs) 15:06, 29 March 2021 (UTC)
      It's app only (the user_app variable in the edit filter). ProcrastinatingReader (talk) 15:12, 29 March 2021 (UTC)
    Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)
    @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)
    We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xenotalk 23:54, 29 March 2021 (UTC)
    I really don't want to rush into an RFC, though. There are many questions. Should we also disallow mobile IP web editors? Should we disallow edits from users with a confirmed email address? Which bugs, exactly, do we want fixed? How long do we give the WMF to fix them? This is a nuclear option. It should not be taken lightly.
    But please don't move the whole thread to VPT. It's here so it doesn't get buried in the archives. Suffusion of Yellow (talk) 00:33, 30 March 2021 (UTC)
    (edit conflict) Two-question RfC maybe? Initial brainstorm - Question 1: consensus 'letter' to WMF requesting resources be allocated to promptly fix the issues. Question 2: if not done within 90 days, mobile apps blocked from editing enwiki by edit filter. Best to move this particular matter to VPI. ProcrastinatingReader (talk) 00:36, 30 March 2021 (UTC)
    It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)
    As I said. Nuclear. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)
    Yes, IDEALAB is the best place (for a new thread). That will discourage any supporting and opposing until we figure just what we're asking for. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)
    This needs caution—an overly enthusiastic RfC or proposal at WP:VPI is bound to be voted down and that would cause a lot of people to automatically vote down any future proposals of a similar nature. I'm thinking of masked IPs—any proposal to impede or block such users could easily fail if it appeared to be similar to an earlier idea to block "good faith" users who were unaware that communication was even possible, let alone required. Johnuniq (talk) 08:34, 30 March 2021 (UTC)
  • I wish I could say I was surprised by any of this but I've long assumed that something like this was the cause of numerous editors I've come across who display quite clearly that they have never seen their IP/user talk page, and simply have no idea why their edits "aren't going through" (because a human editor keeps undoing them). A thorough waste of thousands of hours of volunteer time, on both ends. There are some countries or regions in which accessing the internet is only financially possible for the everyday person via a mobile phone, so the WMF's inaction here is another built-in systemic bias which prevents some cultures from effectively contributing their knowledge and skills to Wikipedia. — Bilorv (talk) 06:51, 29 March 2021 (UTC)

  • User:Suffusion of Yellow/Mobile communication bugs seems to be an excellent overview but it would get more attention if it were on phab. I have tried to roughly copy it to https://phabricator.wikimedia.org/T278838 which can probably be used as a parent task for all these issues. – SD0001 (talk) 15:04, 30 March 2021 (UTC)

Hi everyone, thanks for raising these issues, and documenting the problems so thoroughly. We're going to get a group of people from the Product department together next week to talk about these problems, and see what we can do about it. I'll let you know what we figure out. I appreciate you all bringing it up. — DannyH (WMF) (talk) 22:17, 7 April 2021 (UTC)

Thank you, Danny! I look forward to seeing what you come up with. Suffusion of Yellow (talk) 19:55, 9 April 2021 (UTC)

26 April update

Hi everyone, we talked in the Product department about the issues that are being raised in this conversation.

We're currently showing notifications to logged-in editors on mobile web, which appear as a number in a red circle at the top of the page. It's the standard design on mobile that indicates that there are messages for you.

We've been reluctant to do that for IP editors on mobile web, because mobile IPs shift around so much. Desktop IPs can change as well, so there's some risk of not reaching the right person on desktop, but the risk is a lot greater for mobile. People walk around with their phones and move from one wifi or cell tower to another. We haven't wanted to show a message bar to a mobile reader who happens to be picking up the same cell tower or wifi access point as someone who made an edit a year ago.

On the apps, the Android team has released improvements to the talk page experience in February and March. Echo notifications currently exist in the Android app, and user talk pages are also discoverable through the watchlist. Users can access article talk using a dropdown menu at the top right; you can see how this works in this walkthrough gif. There are some further improvements planned, including enabling in-line replies, and building onboarding features to help people discover both the watchlist and talk pages. You can learn more, and ask the team questions, on their Android communication project page.

The iOS team is also looking at improving the talk experience on their app. They're currently in the initial design and technical planning phase for enabling Echo notifications on iOS. Later this year, they're planning to fill in some of the missing collaboration features on the app, including making editing tools and talk pages more prominent.

There are some different things to discuss here, and I'd like to know what you think. — DannyH (WMF) (talk) 18:47, 26 April 2021 (UTC)

What are we doing about the block notification messages and the other edit screen notices?? —TheDJ (talkcontribs) 19:02, 26 April 2021 (UTC)
@DannyH (WMF):
  • About IP users: As myself and others have suggested, there's a solution to the "random unrelated reader" problem: Don't show the alert if the new message is over X days old. Or (if the privacy policy permits) set a cookie anytime they click "publish", and only show any new message alert to people who have edited in the past X days. Or even both. I think most people already understand that messages sent to IP users are not guaranteed to reach the user. But we do expect that when 1.2.3.4 edits Foo, we leave them a message, and then an hour later 1.2.3.4 edits Foo again, that they've seen our message. That's the disconnect between expectations and reality that's been bothering us. You're also making the assumption that users on mobile devices are also on mobile connections. What about the phone user on their home WiFi? That could be stable for months.
  • About logged in users: No, the red circle is not (only) the standard "you have new messages" alert. It's also the standard "we have some spammy garbage we'd like to sell you" alert. Of course experienced users know Wikipedia doesn't do that, but inexperienced ones are the people we're trying to reach. As matter of habit, I ignore similar-looking notices on unfamiliar websites.
  • About the Android app: Again, what about spam-weary users who have turned off push notifications. With no in-app alert, how are they supposed to know that there is an urgent message on their talk page?
  • About the iOS app: If users are currently in a total bubble, why enable editing at all? Why not wait until basic communication features are implemented, and keep the app read-only in the meantime?
I'm really getting the impression that the WMF thinks that user communication is an afterthought. Y'all didn't just forget one communication-related feature, you forgot most communication-related features. How did this happen in the first place? Suffusion of Yellow (talk) 20:15, 26 April 2021 (UTC)
@DannyH (WMF): Thank you for your time working on and responding to this. I recognize the difficulties in developing a good software product for the diverse projects that rely on MediaWiki software. However, I am deeply frustrated that this has been allowed to occur. Ensuring that existing community mechanisms for communicating with other editors, especially new editors, continue to function is a bare-bones requirement for any Wikimedia minimum viable product. To paraphrase Risker's related thoughts on Wikimedia software development in a different area: the intention behind a lot of this has been good, but sometimes I think engineers have no idea how our projects actually function and how significant some of these problems are. Frankly, if logged-out mobile editors don't have an interface to see messages, then the logged-out mobile interface should not contain editing functionality. Otherwise, this software is wasting many many hours a day of volunteer time tracking down and reverting and warning (not that they'll see the warnings) and blocking good faith IP users who are oblivious to community norms and this software is wasting just as much time spent by new editors trying to help out but unable to access any feedback about their editing. Best, KevinL (akaL235·t·c) 10:01, 28 April 2021 (UTC)
Let me make more explicit a position that I suspect a broad swath of the English Wikipedia community may support: If the Foundation feels that it is impractical to build a communication system to communicate with logged-out mobile editors, then logged-out mobile users should be required to log in to edit. Wikipedia is a collaborative project; we simply cannot allow users to edit without being able to communicate with them effectively. KevinL (akaL235·t·c) 10:05, 28 April 2021 (UTC)
Absolutely, thank you for the clear description of the situation. I was thinking of going rogue and just blocking any uncommunicative user/IP after a single warning. That would avoid mega-frustration and wasted time and would focus minds on fixing the problem rather than ticking boxes for the number of new edits from new users. Johnuniq (talk) 10:23, 28 April 2021 (UTC)
@DannyH (WMF): If fixing all the issues is going to take some time, and you don't want to disable editing entirely, can you break the Android app a bit more? See this. Using that hack a message can be conveyed to iOS users but the same can't be done for Android. It shouldn't take long to make the tweak, which would at least allow a custom mechanism to communicate a message to Android editors. Perhaps directing them to login via their browser app, for example. ProcrastinatingReader (talk) 03:16, 30 April 2021 (UTC)

Hi everyone, thanks for posting more thoughts. As usual, there's lots to respond to here.

It's true that the apps are late to including talk page features. That's partly because we didn't have a clear strategy for how we could improve talk pages sitewide — we knew that we wanted to improve the usability of talk pages, but the Flow project was not successful, and we knew that we needed to find a new direction. We determined that new direction with the Talk Pages Consultation in mid-2019, and then the Editing team started their Talk pages project to build tools for replying, starting new discussions and being notified when people comment in specific talk page sections. (If you haven't yet, you can turn on the new tools for replying and starting new discussions in the Beta preferences tab.)

As part of that project, the Editing team has developed the ability to break down wikitext conversations into individual comments, and all of that work is now informing the work that both the Android and iOS teams are doing to improve the talk page experience on the apps as well.

Now, one of the things that we do when a product team is working on a feature is to look at both the usage numbers and the revert rate for edits that are made using the feature. If the revert rate is higher than average, then clearly there's a problem with the feature that we need to fix.

Comparing the revert rates across desktop, mobile and apps, we see a similar pattern with both logged-in and logged-out editors. Looking at the last 30 days on English Wikipedia, mobile web edits have a higher revert rate compared to desktop edits. That's true for both logged-in users (10.2% revert on mobile web to 3.7% revert on desktop) and IP editors (35% revert on mobile web to 22% revert on desktop). Edits made through the apps are closer to the desktop revert rate. For logged-in app users, about 6.5% of app edits are reverted, compared to 3.7% on desktop. For IP app users, it's around 24% app edits reverted vs 22% IP edits on desktop. So while every single revert is a waste of time for somebody, we don't see app editing causing significantly more problems than desktop editing, especially compared to mobile web.

As I said earlier, the Android team has recently released improvements for talk pages just last month, and has plans to continue work on it, and iOS will be working on communication features later this year. So while those teams had a late start on these features, they are currently getting attention.

Some more specific points: Suffusion of Yellow, your suggestion about offering a time-limited message is interesting, and started a conversation in a couple of teams, so thanks for bringing that up. For your question about the assumption that mobile devices are used on the go: yes, there are definitely people who use mobile devices on stable IPs. However, it's a lot more likely that any given mobile device will be on an inconsistent IP than a desktop device.

Regarding people who ignore red circles and turn off push notifications, it's true that banner blindness is very strong, and that's a problem for web designers in general. However, we've found that when someone takes a specific step like turning off push notifications, responding with larger and more insistent notifications is not likely to help.

I'm happy to keep talking, if folks have more questions or suggestions. DannyH (WMF) (talk) 18:47, 30 April 2021 (UTC)

Danny, I'm intrigued and puzzled by your statement here. You have people here (and in many previous conversations) expressing frustrations at an inability to communicate with users. Some prior discussions have been about specific editors who have a mixture of constructive and troubling edits which are the kind of editors who can frequently be helped to stop the troubling edits. Your response, if I'm understanding it correctly, is that because there is no difference in revert rates for these editors compared to those on other platforms that the lack of communication doesn't matter. This might be true but would be a radical shift in culture in terms of how we handle disruptive editing and would be at odds with other foundation sponsored initiatives, including obligations to help new users in the UCoC. Can you help me either understand where I am failing to get what you're saying or if I do understand what you're saying how we, as an enwiki community, can square this circle. Best, Barkeep49 (talk) 19:17, 30 April 2021 (UTC)
Hi Barkeep49: What I shared about the revert rate was in response to a couple of things. First, Johnuniq commented on the fact that I'd only talked about edits from app users, and didn't acknowledge the impact on the editor community who have to clean up a mess. (The part about "ticking boxes for the number of new edits from new users.") It was also a response to the suggestion made in a few places that the apps shouldn't allow editing if the communication features aren't up to desktop standard. My point is that we do try to take the impact on the community into account, by making sure that features that we build don't result in a mess that's noticeably bigger than the mess that already exists.
But yes, this conversation is mostly about reaching specific editors who might be helped to stop making troubling edits. I agree that the communication features are important, and both apps teams have been and will continue to work on communication features. Some of the problems that we're talking about have already been addressed on Android; I think that in the case mentioned in the thread on Jimbo's talk page, they would have received talk page notifications as of March 30th — but that was sadly too late to reach that user. These conversations have inspired us to talk more about the communication features as a product team, and I appreciate the folks who have brought it up here. — DannyH (WMF) (talk) 20:37, 3 May 2021 (UTC)
DannyH (WMF), the desktop site is fully functional on modern mobile devices. The solution to this problem to shut down all apps and sites that are not fully functional, and redirect all users to the desktop site, which should be renamed the "fully functional site". That would save enormous amounts of money and draw a gigantic worldwide pool of new editors into the WMF free knowledge websites. Right now, we are erecting barriers to collaboration with people editing with mobile devices, and that is terribly sad. I speak as an editor who has been editing and more recently administrating with Android smartphones for ten years. 99+% of my edits are on smartphones. The WMF is spending buckets of money on a problem that does not exist, and making matters worse in the process. Cullen328Let's discuss it
While this may have been a hypothetical, I would personally oppose such a proposal, solely because while the desktop site is functional on mobile, the text is still really small. The probably-crazy solution that immediately comes to mind is to switch the site skin to the new Responsive MonoBook, because that would display the content at a reasonable size on mobile while presumably allowing IPs to see the Orange Bar of Doom. (I haven't tested this, but I assume it works because unlike Minerva, MonoBook is maintained by the editing community.) Also, there are some plans to make Vector responsive too, but I don't know anything about that. —pythoncoder (talk contribs) 22:19, 5 May 2021 (UTC)
At least a couple of us have disagreed with your view a few times, Cullen. The desktop site is not at all well optimised, and the apps are better for reading already. The solution is not to delete everything, rather than fix the issues. It's such an overly simplistic view anyway; compare this to this in terms of page size. I mean, the suggestion just isn't considerate of all the language projects and global users, and is just so unlikely to happen that it distracts from real solutions, which really is to disable editing in the interim / provide a roadmap, or at least allow the community to do that if it wishes to by consensus. ProcrastinatingReader (talk) 01:36, 6 May 2021 (UTC)
hear hear. —TheDJ (talkcontribs) 08:35, 6 May 2021 (UTC)
I agree that just nuking mobile and forcing everyone to use desktop is the wrong solution. What many people don't quite grasp is that not everyone is like them. They assume that because they have a large screen smartphone and a fast connection, then of course everyone does, and if a desktop website works for them then of course it works fine for for everyone else.
In the real world some people access Wikipedia on old flip phones, satellite phones with huge packet delays, rugged industrial phones with tiny screens, and ancient computers using modems.
I recently finished a preliminary design for a major toy manufacturer that includes a very low performance web browser with a really cheap display. That one got cancelled (90% of toys that make it to prototype do) but sooner or later you are going to see something similar in the toy aisle at Wal-mart for $29.95 USD. --Guy Macon (talk) 11:02, 6 May 2021 (UTC)
@DannyH (WMF): is this a joke or am I misunderstanding? You're saying that it's a deliberate design choice that mobile app editors are not seeing the messages being left for them? How do you suggest that we contact CejeroC, or does it not matter that thousands of volunteers' time (both newbie and experienced) are being wasted? — Bilorv (talk) 23:33, 29 May 2021 (UTC)
Hi @Bilorv: I think that you're misunderstanding slightly. It's a deliberate design choice not to show notifications for IP editors on mobile web, because there's a higher chance that we'll show the notification to the wrong person. It's more likely that a mobile web edit was made by someone who's moving around, so the notification would appear for a random reader who happens to be picking up the same cell tower or wifi access. We are showing notifications for logged-in editors on mobile web, and both logged-in and logged-out editors on the Android and iOS apps.
CejeroC was an editor on the Android app, which added talk page notifications in some changes made in February-March 2021. This was too late for the people trying to contact CejeroC, unfortunately, but it should be easier to contact Android app editors from now on. — DannyH (WMF) (talk) 18:35, 4 June 2021 (UTC)
Thanks for the reply, DannyH (WMF). I'm glad that I was misunderstanding, as the other option was deeply undesirable. My new questions are as follows: you're saying that it's a deliberate design choice that unregistered mobile web editors are not seeing the messages being left for them? Where can I see the WMF's data on the percentage of IP talk page messages that would have been seen by someone who was not the intended target, versus the percentage that would have been seen by the intended target? And how should a volunteer attempt to get in contact with an IP editor tagged as making mobile web edits, particularly when the IP has clearly been static for a non-trivial amount of time (based on the length of the editor's contributions)? — Bilorv (talk) 18:57, 4 June 2021 (UTC)
@Bilorv: I wish we could get data on who sees which notifications; it would make life easier. Unfortunately, we don't know. (There are a lot of stats that are typically collected by other big websites that we don't collect out of respect for users' privacy.) The judgment call that we're making right now is based on our understanding that a large number of IPs move around and are unreachable even on desktop, and that problem is obviously magnified for mobile IPs. For the question of how a volunteer could get in contact with a stable mobile IP editor, one potential workaround would be to leave them a message on the IP's talk page, and then when you revert one of their edits, you put a link to their talk page in the edit summary. That's obviously a hack, but IP editors having a talk page at all is kind of a hack. — DannyH (WMF) (talk) 20:58, 8 June 2021 (UTC)
I don't believe that the users I'm thinking of are aware that there's a page history—in fact, I often see behaviour that makes me think they are going "my edit didn't go through, why is it not there when I look again a few hours later?" after a revert (and I don't think the layout makes the page history obvious). I need to send a big fuck-off banner saying "SOMEONE IS TRYING TO TALK TO YOU ABOUT THE EDIT YOU DID" in order to engage attention. Unfortunately, no such functionality exists. I do appreciate the privacy afforded to readers and editors, but you're making a judgement call based on not very much—certainly not what the community wants—and using a 2001 IP-based system is not the solid foundation for communication that I need. (I understand the WMF is planning to anonymise IPs but not change them as the method of tracking unregistered contributors.) I don't necessarily want us to start tracking people with cookies, so I know every solution comes with a disadvantage, but this situation is honestly ridiculous. So much of my time is wasted with sending out messages to people who will never see it, and the alternative is just undoing what they did without explanation (what message is that to send to a newcomer? How can we get new editors involved by doing that?). — Bilorv (talk) 21:25, 8 June 2021 (UTC)
@Bilorv: As you say, the 2001 IP-based communication system is very flawed. The big f'off banner doesn't even work for desktop IP editors all too often, because IPs shift around, or just because the person who's making the edits doesn't understand or doesn't respond to talk page messages. For mobile IP editors, you're even less likely to make a connection. I think that if the folks who created MediaWiki twenty years ago were creating it today, they probably wouldn't use IP addresses as the foundation for communication, but this is the legacy system that we have.
I do think that the work that the Anti-Harassment Tools team is doing on "IP masking" will help with this, especially if we use cookies on mobile devices to associate the device with an auto-generated user name. There's a lot of planning and discussion left to do on the IP masking project, and figuring out how to communicate with "masked" IP editors will be one of many things to figure out. — DannyH (WMF) (talk) 22:42, 9 June 2021 (UTC)
@DannyH (WMF):We are showing notifications for ... both logged-in and logged-out editors on the Android and iOS apps. Can you link me to the phab task where the the lack of iOS notifications was fixed? I don't have an iOS device handy and phab:T274404 and its subtasks suggest work is just getting started. Also, the Android app still isn't showing me any alerts for logged-out talk page messages. And least no one has responded to my simple question at phab:T95396. So what have I missed? Suffusion of Yellow (talk) 19:37, 6 June 2021 (UTC)
@Suffusion of Yellow: Sorry, you're correct about iOS. I just checked my own post at the top of the section and realized that I made a mistake when I replied to Bilorv. Android has already made the changes; iOS is getting started on that work. I looked at your question on that ticket, which I think was not the correct ticket for that bug report — it looks like that ticket was closed in May 2020, and may not have been the right ticket anyway. I just asked the PM to take a look at it, and tell me where that report should go; I'll let you know when I get an answer. — DannyH (WMF) (talk) 21:06, 8 June 2021 (UTC)
Ah, I see that you've already made that connection on phab:T276147. At least, I think so. Let me know if I'm not correct. — DannyH (WMF) (talk) 21:22, 8 June 2021 (UTC)
@DannyH (WMF): So I understand there is still a subset of logged-out mobile editors not getting talk page notifications, yet they are still editing? This is unacceptable.
As has been stated above, if an interface does not have basic communication capabilities, then the interface should not have editing capabilities. --DB1729 (talk) 02:17, 8 June 2021 (UTC)
@DB1729: I understand your dismay; I agree that communication is essential for productive wiki collaboration. I think that at the root, this is actually a flaw in the concept of allowing people to edit without an account on Wikipedia. Twenty years ago, it may have been roughly accurate to assume that IP addresses were mostly stable, because everybody had a desktop and mostly a dial-up connection, so if you posted a message for a particular IP address then you were likely to reach the same person. Today, the use of laptops at wifi hotspots and phones and tablets using cell service has basically broken that model. A few years ago, we reached the point when mobile pageviews hit 50% of our traffic, and by now the majority of Wikipedia readers are accessing our site with a mobile device.
I think that your suggestion of restricting IP editing on mobile is an interesting one, and it's possible to argue that that should apply to desktop as well as mobile. But that's a much bigger conversation, and I don't think we'd be able to settle it here. — DannyH (WMF) (talk) 21:19, 8 June 2021 (UTC)
I don't have the data, but edits I make using my phone usually come from the same IP (my home or work wifi) that my desktop edits come from. (I use responsive monobook, so my phone edits count as "desktop"). What's inhibiting communication with some mobile editors is not that their IP changes, it is that the software they use is not fit for purpose. Do you know any of the people who can fix the software? —Kusma (talk) 08:28, 10 June 2021 (UTC)
@DannyH (WMF): Speaking of notifications Danny, for some reason I never got that ping from your last reply.(ironic) Did you get a confirmation it was sent? Thank you for the reply and for sharing your thoughts. In the meantime, yes I understand the dynamic IP problem, but these users are notified (I hope) when their IP addresses are blocked, are they not? Presumably when they open an edit window? Similarly, a talk page notification could be displayed only when there is an attempt to edit. It could then time-out or become invisible after a set duration, much like I assume a block notice will disappear once the block expires. DB1729 (talk) 15:48, 12 June 2021 (UTC)

#suggestededit-add 1.0

I think it would be a good idea to also bring up what I think is the related issue of the #suggestededit-add 1.0 process, as this seems to a mobile idea. See for example Jomart Allaguliyev (talk · contribs), a new mobile user who has made over 1000 edits exclusively through this process. Most are fine, but some are wrong, and some are almost nonsensical. Sometimes they re-do and worsen their own better work! [14] [15]. They've also a few times made the same edit twice after being reverted [16][17], which feels like something popped up and they simply repeated the action? The only documentation seems to be on Wikidata, so it is unclear how exactly these are happening or where they're happening from. There is an old Phab task (T227623) closed suggesting the process is working as intended. CMD (talk) 02:42, 22 April 2021 (UTC)

I'm confused about how this is a suggestedit issue. That editor was given exactly one warning, as far as I can tell. If an editor is editing disruptively, the first step is to notify them on their talk page, isn't it? (Also, I have fixed your broken link above.) – Jonesey95 (talk) 04:26, 22 April 2021 (UTC)
Thanks for the fix. The user is not editing disruptively, on the whole. The point is, this user's edits are being solely guided by some program out there providing editing suggestions to new users, provided by WMF, of which there seems to be little documentation. How is it not a suggested edit issue, when any potential disruptiveness would presumably be due to this feature? It would be nice to have documentation. If the edit summaries are automatically generated, why don't they include a wikilink to such documentation? The Mediawiki FAQ states only that it is to "Add short descriptions to articles that are missing descriptions", which is clearly not the case given these are edits to existing short descriptions. CMD (talk) 09:14, 22 April 2021 (UTC)

As an update here, the page Wikipedia:Suggestededit-add 1.0 has been created by Guy Macon, but I'm still seeing edits like these ones which add the short description "Overview of the topic", and am no less enlightened as to whether these somewhat meaningless descriptions are being suggested by Wikimedia software. CMD (talk) 05:21, 13 September 2021 (UTC)

Another block. Any progress?

[18] Didn't seem like there was any other option. Any progress on resolving these issues? As I requested somewhere, any chance we can break the Android app some more so we can use a hack like Filter 1139 (for iOS) for Android users as well? That hack works due to the fact that iOS edit filter disallows do not parse the page but just display the page title instead. Android unfortunately uses a hardcoded vandalism warning, so this does not work there. It should be trivial for WMF engineers to make Android behave the same as iOS while they do proper fixes. @DannyH (WMF)? ProcrastinatingReader (talk) 14:19, 15 July 2021 (UTC)

@ProcrastinatingReader: It looks like the fix for edit filter messages on Android has made it to the official (app store) release. So it should be possible to "communicate" with Android users through the filter now. However, links in the edit filter message will open in the browser. And if they're viewing a wiki that isn't their default language, the links will go the wrong language wiki. e.g., if we (on enwiki) send them to Special:MyTalk or WP:EF/FP/R, they might end up at fr:Special:MyTalk or de:WP:EF/FP/R. I don't know if that bug is being actively worked on, but we're getting somewhere. Suffusion of Yellow (talk) 23:34, 17 July 2021 (UTC)
Suffusion of Yellow I don't know a lot about edit filter, but I (maybe) have an idea for a work around. Can we redefine all edit filter links as fully defined [external links] and explicitly point them to https://en.wikipedia.org/_whatever_ ? Alsee (talk) 12:34, 18 July 2021 (UTC)
@Alsee: Tested here. That seems to work. The first link (Foo) opens at frwiki (because that's the first language in my settings), but both testwiki:Foo and https://test.wikipedia.org/wiki/Foo open at testwiki. That should work for a filter like 1139 (hist · log) but I don't think we should "fix" the dozens of other messages to work around this bug. Suffusion of Yellow (talk) 20:06, 18 July 2021 (UTC)

Some progress - see the latest update at mw:Wikimedia Apps/Team/Android/Communication. Nthep (talk) 21:00, 2 August 2021 (UTC)

Some progress: logged-out web

From T284642: Add yellow talk page message banner to non-main namespace pages on mobile, they (Reading product team?) have created an alert bar for logged-out mobile web users. It is displayed when the user taps edit or visits a non-mainspace page. ⁓ Pelagic ( messages ) 22:10, 13 January 2022 (UTC)

P.S. For reference, T278838: Mobile user communication issues (WP:THEYCANTHEARYOU) appears to be the master task, it has a good long list of sub-tasks. ⁓ Pelagic ( messages ) 22:10, 13 January 2022 (UTC)
Yes, this was deployed a while ago but because of a caching bug it only worked some of the time. The caching bug has supposedly just been fixed, but I haven't tested this recently. I would not assume that all mobile IPs can "hear us" without extensive testing. But some certainly can. Suffusion of Yellow (talk) 04:57, 15 January 2022 (UTC)

Wishlist

m:Community Wishlist Survey 2022/Mobile and apps/Better warning display for mobile usersPelagic ( messages ) 22:00, 13 January 2022 (UTC)

Drop everything and focus on the collaborative issues!

While the apps may be works-in-progress, this project is a collaborative one, and an app that allows you to edit but does not allow collaborating means a lot of good-faith editors who would be competent if editing with a browser are getting blocked for reasons they don't even understand. WMF added dark mode to their app before they allowed IOS users to access the talk namespace. I say, if you want the app to be decent, drop cosmetics, drop the rare (or even somewhat common) bugs, and get this issue over with. While users may have issues viewing certain pages, or their eyes may be strained looking at certain layouts, or it isn't quite ergonomic enough, that's small potatoes compared to the inability to see other editors' warnings. And then AN/I is not viewable on Android. The version shown starts with a thread from 2020 about the BLM protests. All of this means that editors who edit on mobile are not able to collaborate properly.

A proposed roadmap would be

  • Drop everything until the issue is dealt with
  • Direct all resources to creating a way for mobile users to collaborate in the same way desktop users can (Especially IOS users, who are worse off than their android companions)
  • Fix the bug affecting AN/I, as it is one of the most important pages for dealing with certain editors or issues
  • Unblock any users who were blocked for CIR or refusal to communicate on mobile.
  • Return to whatever you were dealing with before.

Of course, you should take everything I say with a fifty-gallon drum of salt given that I have no background in web engineering and have no idea what issues WMF is facing. If someone more qualified than me steps up and says that this is not feasible, I will gladly retract it. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 15:54, 10 February 2022 (UTC)

Bug Bounty Program

I wanted to propose this here after reading a recent Wikipedia Signpost article regarding WMF allocating surplus cash on hand.

WMF may benefit from a bug bounty program, where WMF offers bounties for individuals who find and report security vulnerability bugs.

These programs have seen a lot of success elsewhere in the software industry, and would be a great way not only to patch security vulnerabilities and improve MediaWiki and related software, but also engage more developers in Wikimedia's tech stack and get people familiar with contributing to Wikimedia's software.

Additionally, some bounty programs also allocate money for volunteers who close existing bugs or feature requests being tracked, as a way to entice more volunteers to help.

This seems like a very direct way to allocate WMF's surplus in a way that would both benefit the tech that WMF relies on, as well as drawing more people into the development community.

Thanks! Catleeball (talk) 17:56, 28 June 2022 (UTC)

A potential downside: Even more reports from self-described "security researchers" who discover bugs like the fact that anyone can edit almost any page. Anyway, this isn't something we could do here. You'd have to convince the WMF. Anomie 11:55, 29 June 2022 (UTC)
while the WMF has money, it lacks IT resources to act on existing bugs reported by volunteers. Incentivising people to report more bugs would only exacerbate existing problems for volunteers trying to get improvements through phabricator. ϢereSpielChequers 18:55, 12 July 2022 (UTC)
We already have enough free bug reports outstanding and don't want to buy any more. The part about incentives for closing existing bugs is tempting but would need careful implementation. Someone would have to check all the alleged fixes, and that might take an experienced developer longer than doing the work themselves. Certes (talk) 22:17, 12 July 2022 (UTC)
I haven't checked lately but what's the phabricator backlog? Like 8,000 bugs volunteers have found but can't fix? Levivich[block] 22:52, 12 July 2022 (UTC)
This might be crazy, but maybe instead of a bug bounty, they spend that money to hire more it staff and resolve exist issues? ScottishFinnishRadish (talk) 23:39, 12 July 2022 (UTC)
"In total there's something like 300 staff between the Tech and Product departments at WMF." Levivich[block] 23:44, 12 July 2022 (UTC)
How many of which are engaged in something more meaningful to the actual encyclopedia and editing than fundraising technology, campaign, community programs, and the like? Product Design Strategy has six employees listed, a VP, a program manager, two leads and two senior researchers. A VP overseeing a manager overseeing two leads overseeing two researchers doesn't seem like an efficient use of capital. ScottishFinnishRadish (talk) 00:48, 13 July 2022 (UTC)
I've learned titles are just a way to create more salary scales in the USA. And while I appreciate people complaining about 'overhead', I'll also point out that a lot of overhead is the direct result of complaints of the community, requiring higher quality, more diverse quality, more communication and overall more aspects of the software process to be covered and 'informed by data' etc etc. Little of this overhead was there in the days of Multimedia Viewer, but ppl didn't really seem to appreciate that time either. So to some degree, it's a self inflicted wound. —TheDJ (talkcontribs) 08:37, 13 July 2022 (UTC)
Oh, so it's the users' fault the software is poor. Levivich[block] 15:43, 13 July 2022 (UTC)
No, it’s not that simple… it’s only ironic. Some overhead is good, some of it is not. For instance, overhead makes creating solutions (the process) more complex, without necessarily dealing with the inherent complexity the software and its target audience already pose. The point is that ppl keep thinking they can contribute simple solutions like ‘add a researcher’, ‘remove research department’ but the actual problems are so complex and simplifying it like that is as useful as screaming at a wall. —TheDJ (talkcontribs) 06:37, 16 July 2022 (UTC)
Brooks's law on adding programmers to a project. - Donald Albury 14:18, 16 July 2022 (UTC)
Just a few notes. 1. A lot of tickets are features requests, which will likely never be fulfilled (too complicated, too expensive, too far removed from the projects core goals) 2. Lots of tickets are more open discussions and exchanging of ideas, which doesn't necessarily make them 'a thing to do'. 3. A lot of issues are also starting points, and when actually tackled will sprout a dozen or sometimes even a hundred new tickets. 4. A significant amount of the issues only relate to VERY few users. 5. There are also several hundred volunteer projects and tech related committees which are not directly related to mediawiki projects and/or might not even be bugs at all, just todo's, which are tracked in Phabricator.
All in all, this is to say that any listing of numbers would require careful interpretation to get a clear view of the state of things. —TheDJ (talkcontribs) 08:25, 13 July 2022 (UTC)

Forbid ukranian WP crowdfunds on ukranian military forces

There is the page (translation) that calls to donate money to ukranian military forces.

1. I do think it's against any WP rules. I never saw calls to donate to Afganistan, Australia, China, Iraq, Italy or Korea military forces. If I'm wrong - please, correct.

2. I do think this page could be a cause to block the entire WP in Russia. That's why it requires WMF official response. This page looks like local ukranian administrators action, not like WP ones. homk 17:42, 12 July 2022 (UTC)

Questions about the Ukrainian Wikipedia should be asked on the Ukrainian Wikipedia or at meta. The English Wikipedia can do nothing about this. Phil Bridger (talk) 17:48, 12 July 2022 (UTC)
Redirected, ty. -- homk 18:00, 12 July 2022 (UTC)

Technical Decision Forum: community representatives

This week's Tech News reports that the Technical Decision Forum is seeking community representatives. You can apply on wiki or by emailing TDFSupport@wikimedia.org before 12 August. Prerequisites include +2 rights on the mediawiki ACL on Wikimedia's Gerrit instance. Certes (talk) 10:56, 19 July 2022 (UTC)

Note: The WMF has doubly outdone itself in abusive propaganda here. The WMF has explicitly forbidden any decision making by this group, and the WMF has explicitly forbidden any community representation in the group.

  • The documentation explicitly states this group does not make decisions.[1] (I am not the one who decided to make that text screaming-red, the WMF made it screaming red in the original source.) The group's sole purpose is to offer opinions and feedback to WMF product teams - who make decisions. Anyone can already show up and offer teams opinions and feedback.
  • Aside from egregious constraints on eligibility, the document explicitly states all members will be selected and appointed by the WMF itself.[2] As such, they by definition represent the WMF. Furthermore any member who displeases the WMF can be unilaterally dropped from the group by the WMF Chief Officer on a twice-yearly reappointment schedule, or banished immediately by a vote of staff in the group.

Alsee (talk) 16:42, 29 July 2022 (UTC)

the WMF has explicitly forbidden any community representation in the group — you're going to have to run that one by me again.. the WMF has done no such thing as far as I can see? — TheresNoTime (talk • she/her) 17:16, 29 July 2022 (UTC)
@TheresNoTime: I think Alsee means that members appointed by the WMF cannot truly be community representation, regardless of whether the WMF claims they are. * Pppery * it has begun... 16:06, 30 July 2022 (UTC)

footnotes

Discussion at Wikipedia:Village pump (proposals) § Communication issue

You are invited to join the discussion at Wikipedia:Village pump (proposals) § Communication issue. This relates to the unilateral rollout of a new external link icon. {{u Sdkb}}talk 14:38, 29 July 2022 (UTC)

new resource for movement discussions.

There is a whole new set of forums being utilized now, which are available for discussion of any and every topic that pertains to Wikipedia, and our community and the Wikimedia movement. please feel free to go there and sign up for an account, and participate as often as you may wish. I hope you will click the link below to do so. we would welcome your input. thanks!!

thanks. --Sm8900 (talk) 17:25, 29 July 2022 (UTC)

Miscellaneous

Seeking recent editor stratification research

Does anybody know of recent work that updates the findings of m:Research:Editor classes or strategy:Editor Trends Study? I have poked around a bit but haven't found anything that works on the same issues; stats.wikimedia.org doesn't quite get into those issues AFAICT. Doesn't need to be formal research; I'd be interested in anything that people have found from just tooling around on toolserver or diving in the dumps. -- Visviva (talk) 18:06, 20 July 2022 (UTC)

As an update, I have been doing some initial poking around in the latest stub-meta-history dump. One thing that jumps out at me is that something odd was happening in 2014: that year saw a dramatic jump in new users in the 1-9 mainspace edits band (>70k absolute, >15% YoY), but also saw sharp drops in the absolute number of edits being made by editors in the 1k-9k and 10k+ mainspace-edit bands (which were largely reversed in subsequent years). I looked through the Signpost archives but didn't see anything that would indicate a titanic shift in wiki practice that year. But I wasn't very active at that time, so I don't really know what might have been happening that would have made 2014 special. Any ideas? -- Visviva (talk) 21:38, 23 July 2022 (UTC)

Interesting work. The only thing I can think of re 2014 was that it was the first full year when both the VisualEditor and the notifications feature were enabled, though I'm not sure how much effect either of these things might have had. Mobile viewing and editing were becoming more popular as indicated by this, but once again, that probably wasn't a seismic shift. Graham87 08:42, 24 July 2022 (UTC)
Ooh, thanks, good thought. Intuitively, that makes a lot of sense: barriers to editing come down so long-tail activity picks up, while "power users" get annoyed and their activity drops. (I recall having some rather cranky things to say about the VisualEditor myself, although my power user days were long behind me at that point.) And that same annoyance could explain the subsequent reversion to trend: annoyed power users make changes to policy and practice that push the balance back toward exclusion. Will be interesting to see if this holds once I've cleaned up the data a little better. -- Visviva (talk) 22:09, 24 July 2022 (UTC)
@Visviva, is that the all-wikis database? If so, then I believe you will see a quite dramatic effect at the Portuguese Wikipedia, which (if memory serves) had unusually stringent CAPTCHA rules in place until December 2013. Whatamidoing (WMF) (talk) 20:55, 25 July 2022 (UTC)
@Whatamidoing (WMF): I've never heard of a database dump for all wikis and I can't find it on the relevant page. Can you point me to such a thing if it exists? Graham87 05:34, 26 July 2022 (UTC)
I don't know how the dumps are arranged. I just saw on the page that there were 16,666,393 pages in the mainspace, which is 10 million more than our current 6,559,574 mainspace articles, and it sounded approximately plausible to me as the number of articles if you added all the Wikipedias together. Whatamidoing (WMF) (talk) 18:09, 26 July 2022 (UTC)
It's just the EN database. I believe 16.7M is accurate as the approximate total number of pages in mainspace (i.e. including redirects and other very short pages that NUMBEROFARTICLES excludes.) I found a version of that number ... uh, somewhere ... that jibed with my result, which was a nice feeling at the time -- although now I can't seem to find it. -- Visviva (talk) 22:00, 26 July 2022 (UTC)
It's at Wikipedia:Database reports/Page count by namespace. We have a grand total of about 59,000,000 articles on all Wikipedias. Graham87 12:53, 27 July 2022 (UTC)

Creating a new page

Wanting to create a redirect page for a common term, I find we have a new layer of bureacratic form-filling; it has to be a draft, am I a lizard, how many false teeth does my grandmother have? No, I do not do that shit, you will never get another page from me if this is to be the bright New World of conformant droids. — Cheers, Steelpillow (Talk) 07:58, 25 July 2022 (UTC)

Maybe the issue would become more obvious if you reformulated this without the allusions to Little Red Riding Hood and lizardpeople (?), but none of the obvious steps necessary for the creation of the redirect (go to page, paste #REDIRECT [[XY]], click "Publish changes") would seem to involve the draft namespace – certainly not if your account is autoconfirmed, which it is. Dr. Duh 🩺 (talk) 08:42, 25 July 2022 (UTC)
Thanks for the prompt reply, but you misread the problem. The page (in this case, Minus number) is not there to be redirected, it has to be created. That used to be straight forward, now it is not - even for autoconfirmed users. Sorry, wrong grandmother too. ;-) — Cheers, Steelpillow (Talk) 09:41, 25 July 2022 (UTC)
I'm afraid I still don't get it. To my personal embarrassment, I have to admit that I've never actually written an article myself (one of my reasons for finally creating an account, but have yet to get around to it) – however, when testing for any unexpected roadblocks by momentarily breaking my recently created redirect Peri Rossi and technically turning it into a normal, non-redirect article, I didn't get as much as a warning, much less a cabal-mandated trip to draftspace. We might have to wait for someone less clueless to drop by, because I'm stumped. Dr. Duh 🩺 (talk) 12:10, 25 July 2022 (UTC)
The trouble has now vanished and I have happily turned my red link above here blue. For what it's worth, your creation of Peri Rossi predates the trouble which sparked this thread. Let us hope it does not recur. Thanks for engaging, anyway. — Cheers, Steelpillow (Talk) 12:51, 25 July 2022 (UTC)
@Steelpillow Were you having a technical problem? There shouldn't be anything that is preventing you from creating new pages the way you have been. If this isn't a problem now, that's good to hear; if you are can you please give us the exact steps you are following, what you expect to be happening, and what is happening instead - so we can look in to this further. Best regards, — xaosfluxTalk 14:02, 25 July 2022 (UTC)
Your description above sort of sounds like you were logged out, if so - non-logged in and confirmed users are actually prevented from creating new articles or article redirects. — xaosfluxTalk 14:04, 25 July 2022 (UTC)
@Xaosflux: As I said above, all is now back to normal. I was logged in all right - my IP address is currently blocked from editing if I am logged out, and it was the first thing I checked. One of life's little mysteries. — Cheers, Steelpillow (Talk) 15:37, 25 July 2022 (UTC)
@Steelpillow thanks for the update, if it happens again and you can get a screen shot that could help, it shouldn't be that hard and if it is a recurring problem fixing it would be a good idea! — xaosfluxTalk 15:47, 25 July 2022 (UTC)
If it does happen again, it probably won't be to me. But if it is, I'll be back. — Cheers, Steelpillow (Talk) 16:11, 25 July 2022 (UTC)

Let's talk about the Desktop Improvements

Vector 2022 showing language menu with a blue menu trigger and blue menu items 01.jpg

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:19, 25 July 2022 (UTC)

Is "speed of light" misleading?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Is it misleading to use the phrase "speed of light" in an article such as "International System of Units" when what is really being referred to is the speed of electromagnetic radiation in a vaccum? Is "speed of causality" more appropriate? Jc3s5h (talk) 18:38, 26 July 2022 (UTC)

No. See also WP:COMMONNAME. Also, why is this here? This belong on the article talk page. Headbomb {t · c · p · b} 18:41, 26 July 2022 (UTC)
The important qualification is "in a vacuum", which seems to be used in that article where needed. Phil Bridger (talk) 20:40, 26 July 2022 (UTC)
The constant being refereed to is 'C' which literally stands for causality. Marrew (talk) 21:49, 26 July 2022 (UTC)
c comes from the latin celeritas, which simply means speed. It does not stand for causality. Headbomb {t · c · p · b} 22:47, 26 July 2022 (UTC)
Either way, c does not stand for speed of light, and calling the speed of light a constant is misleading, and more confusing. Marrew (talk) 23:10, 26 July 2022 (UTC)
Celeritas, meaning speed, of what? The answer is still the celeritas of causality, not the speed of light. Marrew (talk) 23:13, 26 July 2022 (UTC)
"of what?" Of light. Duh. Headbomb {t · c · p · b} 23:23, 26 July 2022 (UTC)
Ad hominem aside (no need to insult my intelligence here), the issue is listing the speed of light as a constant, when it is not a constant. Whether c stands for celeritas or causality is not really the issue here. This is confusing to people studying optics, which relies on the existence of refraction, a phenomenon that relies on the fact that the speed of light is not a constant. The table should include "in a vacuum" at the very least, as the paragraph talking about it does, to avoid this confusion.
The speed of causality, also known as the fastest speed that any one point in the universe can communicate any data to any other point in the universe that is separated in space, is far more specific, and could lead people to reading further on the topic rather than being misinformed.
https://en.wikipedia.org/wiki/Speed_of_light#Upper_limit_on_speeds is a better part of the article to link to in this regard, and is what a link for "speed of causality" automatically corrects/scrolls to. Marrew (talk) 00:09, 27 July 2022 (UTC)
The speed of light is NOT a constant. If it were, the field of optics would not exist. This is more confusing. Marrew (talk) 21:50, 26 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Updated contributor study?

Howdy hello folks. A friend had been telling me about how male dominated the open source community is, and it made me look up the gender breakdown of Wikipedians. As far as I could tell, our data is almost comically outdated at this point: the most recent data is from 2013, when we were 84% male (see Wikipedia:Wikipedians). Does anyone know of any more recent data? If not, anyone know how we could get that number updated? I think it would be very good to track our progress (or lack thereof) of diversifying the community. CaptainEek Edits Ho Cap'n! 19:27, 27 July 2022 (UTC)

Hi CaptainEek, thanks for drawing attention to this. A couple of recent sources:
However, there are many more. For some lists of data sources on the gender breakdown of Wikipedians:
I hope this helps a bit! -TAndic (WMF) (talk) 10:34, 29 July 2022 (UTC)

Vote for Election Compass Statements

You can find this message translated into additional languages on Meta-wiki.

Hi all,

Volunteers in the 2022 Board of Trustees election are invited to vote for statements to use in the Election Compass. You can vote for the statements you would like to see included in the Election Compass on Meta-wiki.

An Election Compass is a tool to help voters select the candidates that best align with their beliefs and views. The community members will propose statements for the candidates to answer using a Lickert scale (agree/neutral/disagree). The candidates’ answers to the statements will be loaded into the Election Compass tool. Voters will use the tool by entering in their answer to the statements (agree/disagree/neutral). The results will show the candidates that best align with the voter’s beliefs and views.

Here is the timeline for the Election Compass:

  • July 8 - 20: Volunteers propose statements for the Election Compass
  • July 21 - 22: Elections Committee reviews statements for clarity and removes off-topic statements
  • July 23 - August 1: Volunteers vote on the statements
  • August 2 - 4: Elections Committee selects the top 15 statements
  • August 5 - 12: candidates align themselves with the statements
  • August 15: The Election Compass opens for voters to use to help guide their voting decision

The Elections Committee will select the top 15 statements at the beginning of August

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

MNadzikiewicz (WMF) (talk) 21:22, 27 July 2022 (UTC)

Insects, athletes?

Has anyone else noticed, in the course of magnanimously contributing editing ideas to random WP articles, that insects and athletes seem to outnumber everything else on Earth? – AndyFielding (talk) 11:34, 29 July 2022 (UTC)

Easy to resolve, just feed the insects to the athletes (or perhaps vice versa). Blueboar (talk) 11:42, 29 July 2022 (UTC)
Well, at least in terms of insects, they DO outnumber everything on earth. Over 50% of all described eukaryotes...are insects. As J.B.S. Haldane is said to have noted versions of on several occasions, "the Creator, if he exists, has a special preference for beetles." It would appear it's their planet, we just live on it... --Jayron32 17:38, 29 July 2022 (UTC)
Or, it used to be theirs: The decline in insect populations is pretty scary. WhatamIdoing (talk) 19:47, 1 August 2022 (UTC)

History of article on Bernard Cribbins

If one goes to the article Bernard Cribbins, and then looks at its history, you will see that some of its revisions are not in wikilinks, and have been crossed out, making it impossible to compare them. Why is this? YTKJ (talk) 17:46, 29 July 2022 (UTC)

They have undergone revision deletion. It seems like there was a copyright violation in that article. Revision deletion makes sure it cannot be easily put back. Femke (talk) 17:51, 29 July 2022 (UTC)
Per Femke, while Wikipedia maintains a database copy of every version of every page, sometimes those versions need to be hidden from public view for any number of reasons. In the case of the Bernard Cribbins article, some of the text in an earlier version was a blatant copyright violation, and needed to be removed. There are actually two levels of removal we have; there's simple reversion deletion, whereby admins remove the versions, but admins still have access to those versions. Given there are many hundreds of Wikipedia admins, sometimes versions are so egregious, even they shouldn't be allowed to see them, and in those cases higher level functionaries have access to oversight, which even admins cannot view. WP:CRD contains reasons why information may be removed from an article history. --Jayron32 18:13, 29 July 2022 (UTC)

Try out the new edit wizard

User:Ankit18gupta/Editwizard is a new script aiming to make it easier for beginners to edit. It is a step-by-step form for filing an edit request. Please try it out; your feedback would be greatly appreciated.

The goal is to show this to logged-out editors on select articles soon, and maybe on every article eventually; a VPPR discussion will be opened about that once there's enough feedback here. Enterprisey (talk!) 21:04, 29 July 2022 (UTC)

@Enterprisey: Installed it on my alt account common.js. While using vector 2022 on desktop version on a smartphone, clicking on the "Edit Wizard" button at the top produces a pop-up above that button. The pop-up is mostly not visible because it exceeds the the page's top margin. Only the two blue buttons, "Verify" & "Next" could be seen. Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:10, 30 July 2022 (UTC)
@Enterprisey Haven't debugged it completely, but looks like it is having to funnel something through toolforge, that does not seem to be documented as a tool (c.f. wikitech:Category:Toolforge tools)? Is this really necessary for an edit request script? — xaosfluxTalk 14:25, 30 July 2022 (UTC)
Looks like it only works on vector and vector-2022, the landing page needs more documentation. — xaosfluxTalk 14:36, 30 July 2022 (UTC)
Got it to run in Vector. Tried to use it, went out and found a source and a quote - then loaded the wizard. It wanted the source URL (so assuming this is useless for off-line references?) - gave it; clicked next - it said I had to Verify, so clicked Verity - it just hung at "Loading..." : END OF TEST - dead end of the workflow there. — xaosfluxTalk 14:46, 30 July 2022 (UTC)
FWIW my reliable source url was: http://www.jstor.org/stable/40681013 ( <ref>{{cite journal last1=Tonry first1=John L. last2=Burke first2=Barry E. last3=Schechter first3=Paul L. title=The Orthogonal Transfer CCD url=http://www.jstor.org/stable/40681013 access-date=30 July 2022 work=Publications of the Astronomical Society of the Pacific date=1997 pages=1154–1164}}</ref> ) — xaosfluxTalk 14:49, 30 July 2022 (UTC)
@Xaosflux, that bug is fixed now. Enterprisey (talk!) 04:12, 31 July 2022 (UTC)
I haven't tried it yet, but my first thought was that anything which requires you to go through a multi-step installation process is going to be a non-starter for beginners. I do see that "The hope is to eventually deploy this as a part of the regular interface shown to logged-out users", so I guess all I'm saying is, "Yes, please do that". -- RoySmith(talk) 15:00, 30 July 2022 (UTC)
As a more productive comment, I tried this out, attempting to add "http://en.wikipedia.org" as a source URL, and was informed that I couldn't do that because it's an unreliable source. This seems like a good thing, thanks for making it available! -- RoySmith(talk) 15:06, 30 July 2022 (UTC)
@RoySmith the notes above suggest this would either be some sort of click-to-load (using a url parameter to load the script) or a default gadget (ehhh.... that's gonna take some convincing!). — xaosfluxTalk 15:09, 30 July 2022 (UTC)
Likely can be done as a click-to-load in Module:Submit an edit request without needing a default gadget. But that's putting the cart before the horse. * Pppery * it has begun... 16:02, 30 July 2022 (UTC)
Thanks everyone for the comments. @CX Zoom, the tool was not originally developed with mobile users in mind but that will be fixed at some point. In the meantime I've filed a bug for the popup location thing. @Xaosflux, the backend is for bypassing the same-origin policy: we can't make requests to URLs provided by users from the script. wikitech:Tool:Edit Wizard created. Bug with the URLs filed. @RoySmith, thanks, and yes that's right. @Pppery/xaosflux, hopefully people will think this is useful enough that we can finagle it into MW:Common.js - putting it in that module will be a bonus, but the main goal is to add it as a tab next to the current edit tab. Enterprisey (talk!) 19:49, 30 July 2022 (UTC)

Wikimedia Foundation fundraising campaign in Denmark, Israel, Malaysia, Norway, and Portugal starts tomorrow, 2nd of August

Dear all,

This is just a brief reminder (see previous announcement) that the Wikimedia Foundation fundraising banners will go live in Denmark, Israel, Malaysia, Norway, and Portugal on Wikipedia tomorrow, the 2nd of August. The campaign will finish on the 30th of August.

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards,

Julia JBrungs (WMF) (talk) 10:29, 1 August 2022 (UTC)

@JBrungs (WMF): I suggest posting these at Wikipedia:Village pump (WMF) instead or in addition. * Pppery * it has begun... 13:09, 1 August 2022 (UTC)

Wikimedia Foundation English fundraising campaign - further pre-test dates

Dear community members,

I wanted to give you a quick update on further pre-test dates around the English campaign (see my previous message for more background).

As part of the English campaign we test our infrastructure on a regular basis throughout the next few months. Currently I can share with you when we will be running banner tests in August.

In August we will be running short banner tests for a few hours on the 3rd and 8th of August. We will add more August dates as the month progresses and I will inform you here, once we know more about the next testing phase. These tests mean that you might see banners, if you are logged out of your Wikipedia account.

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards,

Julia JBrungs (WMF) (talk) 07:48, 2 August 2022 (UTC)