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

수집을 비활성화하시겠습니까?

난 Special을 보고 있었어.그리고 주변 페이지들을 모아라.Gather는 2015년 3월 WMF가 (Beta로) 활성화한 연장선인데, 주로 모바일 사용자를 목표로 하고 있는데, 그 목적은, 글쎄, 사실 명확하지 않다.분명히 사용자 공간 밖에서 사용자 정의 목록을 만들어 친구나 세계와 공유하기 위해서입니다.흔히 있는 일이지만, 엔위키는 다시 시험장으로 이용되는데, 마치 우리가 할 일이 없고 수백 개의 위키미디어 사이트가 없는 것처럼 말이다.[1]

수집에 대한 편집 내용은 관련 사용자의 기여도에 기록되지 않으며, 이러한 목록을 확인하는 것 역시 표준 페이지 큐레이션(최근 변경사항, 새로운 페이지 등록 등)에 포함되지 않는다.

이와 관련된 페이지에는 다소 흉측한 Special:가난한 사람의 감시목록의 일종인 GatherEditFeed.이것은 Gather를 여러 개의 watchlist(오래 요청된 기능)를 만드는 데 사용할 수 있다는 것을 보여주지만, 이것은 공공장소에서(모든 사람들이 이런 방식으로 당신의 watchlist를 확인할 수 있다) 그리고 매우 낮은 인터페이스를 가지고 있기 때문에 전혀 유용하지 않아 보인다.

수집 목록은 공정한 사용 이미지를 포함하여 큰 이미지를 가지고 있다.이것은 전형적인 WMF 문제인 것 같다. 그들은 이미지의 저작권 상태에 대해 전혀 신경 쓰지 않는다. (또한 같은 문제를 가진 최근의 "더 읽기" 베타 확장자 참조)

Gather 및 인터페이스에 문제가 더 많으므로 직접 확인하십시오.

내 질문은 백과사전을 위해 "게더"가 무슨 소용이냐는 것이다. 그리고 우리는 그것을 간단히 비활성화해야 하지 않을까(혹은 WMF에 의해 비활성화되어야 하지 않을까) 하는 것이다.내가 보기엔, 일반적으로 유용하지도 않고 통합적이지도 않고 유익하지도 않으며, 더 많은 편집자들을 끌어들이지도 않는 것 같다.가장 다작인 Gatherlist 편집자는 User인 것 같다.Elisagwanor (Special:수집 목록: 편집보다 수집 목록이 더 많은 오래된 창작물, 주제별 목록, 원하는 기준별 목록)을 확인하는 것은 불가능할 것으로 보인다.

이들 리스트의 대다수는 하나의 기사만 가지고 있어 다소 기괴한 리스트가 되고 있다.그들은 자신들을 만든 사용자만을 위한 90%의 이자를 가지고 있지만, 다른 누군가를 위한 것은 아니다.나는 왜 WMF가 이것을 위한 도구를 제공해야 하는지, 엔위키가 왜 이것을 순찰하고 유지해야 하는지 모르겠다.하지만 다른 사람들은 아마 동의하지 않을 것이다. 그래서 나는 이것에 대해 RfC를 시작하기로 결정하기 전에 모든 의견에 관심이 있다.프람 (대화) 2016년 1월 20일 15:21 (UTC)[응답]

WMF는 지역사회 협의 없이 목적이 불분명한 설계되지 않은 기능을 구현했는가?내가 이런 말을 듣고 있다니 믿을 수가 없어.∙ 무지개빛 15:22, 2016년 1월 20일 (UTC)[응답]

;-) 프람 (대화) 15:31, 2016년 1월 20일 (UTC)[응답]

롤! - 시투시(토크) 15:32, 2016년 1월 20일 (UTC)[응답]

오, 글쎄, 나는 최소한의 시험으로 마주치는 전형적인 작은 문제들 중 몇 가지를 나열하는 것을 참을 수 없었다.모든 수집 목록의 개요에서 왼쪽 상단에 "숨겨진 목록 표시" 링크가 있다.이것은 [2]로 이어진다.오류...더 아래로 스크롤하면 페이지 모양이 이렇게 달라질 수 있다[3]."show hidden lists" 링크는 훨씬 작으며, 다른 오류를 발생시키는 [4]로 이어진다.따라서 데스크톱이나 모바일은 여기서 아무런 차이가 없는 것 같다.

또 다른 이상한 문제: 내가 Special에 갔을 때:모여라, 나는 더 이상 오른쪽 상단에 있는 "검색" 상자에 입력할 수 없다.이것은 다른 "특수" 페이지에서는 일어나지 않는다.

아, 그리고 그들은 위키피디아도 만들었다.enwiki에서 Flow를 더 이상 롤아웃하지 않겠다는 모든 약속에 대해 Flow 페이지로 사용자 피드백을 수집/사용하십시오.잘했어, WMF! 프람 (토크) 15:31, 2016년 1월 20일 (UTC)[응답]

• OP에 우리가 wp를 비활성화해야 하는 이유를 좀 더 명확하게 (그리고 가능하면 더 적은 산문으로) 명시해 줄 것을 요청해도 될까?모였는가? OP는 또 다른 WMF 비활성화에도 관여하지 않았는가? 소규모 위키백과 주체가 내부 프로젝트 커뮤니케이션을 스스로 선택할 수 없도록 막았다.

• 배경

• 나에 대해: 나는 너무 많은 위키 대화를 멀리하려고 노력하고 콘텐츠 작업을 더 선호한다.
• '게더'라는 말은 처음 듣는 말인데 그게 뭔지 제대로 들여다볼 겨를이 없다.
• 나는 wp에서 가장 활동적인 참가자 중 한 명이었다.WikiProject 조식 wp:유량을 시험하고 있었다.
• 나는 위키프로젝트 조찬에서 Flow trial을 삭제하는데 실패했지만 반대하려고 노력했다.
• 관심이 많고 시간이 많은 사람은 다음을 참고하십시오.User_talk:Ottawahitech#Flow_.2F_프로젝트브레이크패스트_RFC 오타와이텍(토크) 2016년 1월 20일 16시 45분(UTC) ping me[답장]

• • 무슨 일인지 모르시겠지만, 위키피디아에서 테스트를 계속했으면 하는 Flow 테스트에 반대했기 때문에(이러한 프로젝트에 대해 어떤 이점도 표시하지 않고 반대쪽이 Flow로 인한 불이익을 나타냄) 나를 구우러 오셨나요?만약 당신이 "너무 많은 위키 대화를 피하고 콘텐츠에 대해 일하는 것을 선호한다"고 한다면, 나는 당신이 여기서 하고 있는 것처럼 보이는 것을 이해할 수 없다. 즉 당신이 있는 것을 좋아하지 않는 장소와 당신이 아무것도 알지 못하는 주제에 대해 그리고 친숙해질 시간이 없다.

• • 이 주제에 객관적으로 관심이 있을 수 있는 다른 모든 사람들에게: 지금까지의 나의 의견은 Gather는 매우 버거운 소프트웨어 조각이며, enwiki에게 조급하게 굴었고, 백과사전(우리가 여기 있는 이유)에게는 거의 아무런 이득도 없는 것 같다는 것이다.그것에서 만들어진 대부분의 "목록"은 길고 종종 다소 무작위적인 기사들이다.이 도구는 위키피디아의 나머지 부분과 매우 잘못 통합되어 있고, 공정한 사용 이미지를 의심스럽게 사용하며, 순찰하기 어렵고, 일반적으로는 실제적인 이익을 거의 제공하지 않는 것처럼 보인다.그러나 나는 이미 그것에 경험이 있거나 그것을 확인하려고 애쓰는 다른 사람들의 의견을 듣고 싶다.또 다른 논의에 대해 불평만 하러 오는 사람들(그 폐지는 이미 WP에서 논의되고 승인되었다)어쨌든 ANI)는 별로 도움이 되지 않는다.프람 (토크) 2016년 1월 20일 19:28 (UTC)[응답]
• 지금은 수집을 사용하지 않도록 설정하십시오.또는 적어도 이미지 표시 기능을 제거하십시오.특수:Gather/id/22108/Astix는 무료 갤러리로, 우리의 정책을 위반한다.단, 영상 설명 페이지에 영상 사용이 나타나지 않아 비자유 영상이 사용되는 것을 검출할 수 없다.예제를 참조하십시오. 파일:아스테릭스커버-20.jpg.이 페이지들이 우리의 정책에 부합하는지조차 확인할 수 없다면, 우리는 그것들을 여기에 두어서는 안 된다.—쿠스마 (t·c) 20:03, 2016년 1월 20일 (UTC)[응답]
  • 아주 놀라운 예를 들어줘서 고마워.한편, 나는 그것을 더 시험하기 위해 컬렉션을 만들려고 노력했지만, 그 사이트는 단지 다음과 같이 고착되어 있다.이름과 설명을 하고 저장을 클릭했고, 그것으로 끝이었다.오, 글쎄...프람 (토크)20:08, 2016년 1월 20 (UTC)[응답]
    • 나는 mw:Talk:그 문제에 대해 집중해라.나는 그 페이지가 얼마나 잘 보였는지 잘 모르겠다.—쿠스마 (t·c) 20:24, 2016년 1월 20일 (UTC)[응답]

• 이 구현은 분명히 재앙이지만, 단지 아이디어 그 자체로, 왜 책을 개선하는 대신에 이것을 별개의 것으로 가지고 있는가?그들은 사용자가 만든 기사 목록과 같은 목적을 가진 것 같다.우리는 책에도 같은 디자인 개념을 적용할 수 있다.— 이어비히 22:39, 2016년 1월 20일 (UTC)[응답]
• WMF는 위에서 언급된 것들과 그 두 가지 논의에서 언급된 것들과 같은 다른 단점들 중에서, 이 연장은 백과사전을 개선하지 못하기 때문에, 이들 목록에 대한 관리자들 사이에 경찰관의 거부가 있을 수 있다는 것을, 두 번 분명히 들었다.사실, 이 연장은 우리가 아니라고 했을 때 "성격"을 무력화시키지 않고 상어들에게 "사자"를 먹이는 것이 아니라, 추가적인 중량을 부과하는 연장을 설계하기 전에 지역사회와 협의하지 않음으로써 WMF의 순전한 경멸밖에 보이지 않는다.이 확장자는 단순히 비활성화된 것이 아니라 삭제되어야 한다.MER-C 02:01, 2016년 1월 21일 (UTC)[응답]
  • 사실, 더 큰 문제는 이 페이지들이 "특수" 네임스페이스에 있기 때문에 (편집자나 관리자에 의해) 큐레이션이 완전히 불가능하다는 것이다.그것들은 삭제될 수 없고, 억압될 수 없으며, 창조자 이외의 누구도 편집할 수 없다.토론을 위한 페이브리케이터 표를 빼내려고 노력하겠지만, 본질적으로 우리가 가지고 있는 것은 편집계가 완전히 관리할 수 없는 공개적인 내용인데, 바로 이 내용이 생방송 '제작' 프로젝트에서 철회하기에 충분해야 한다.시험 환경에서는 괜찮겠지만 영어 위키피디아는 시험 환경이 아니다.나는 최근에 새로운 확장에 관해서 할 때 그것을 *하지 말아야 할 것*의 예로서 사용했는데; 제대로 된 것은 거의 없다.심지어 연장의 이름조차 문제가 있다.리스크 담당자 (대화) 2016년 1월 22일 19:56 (UTC)[응답]
    • 위의 두 번의 토론에서 공동체가 온건한 컬렉션을 할 수 있었다.WMF는 이에 대응하여 전체 확장을 제거하는 대신 이 능력을 제거하고 콘텐츠에 대한 단독 책임을 지는 것으로 보인다.WMF가 스스로 궁지에 몰렸다는 것을 깨닫기를 바랍시다.MER-C 04:25, 2016년 1월 23일 (UTC)[응답]
• 한숨 쉬어.. WMF 개발자들이 우리의 시간을 낭비하는 문제를 해결하지 않기 때문에 시간을 더 낭비하도록 강요하는 더 많은 시간 낭비를 해.annd delete 사용 안 함. --Dirk Beetstra 03:26, 2016년 1월 21일(UTC)[응답]
• 사용 안 함을 승인하십시오.주어진 편집자가 느끼는 페이지의 공개적인 컬렉션을 만드는 수단의 원칙은 어떤 면에서는 나쁘지 않다. 예를 들어, 페이지 하단에 나타나지 않는 사이비 카테고리를 만드는 수단을 갖는 것은 이와 같은 문제를 예방하고, 위키피디아 주체가 "페이지 tha"를 만드는 것을 가능하게 할 것이다."일할 필요가 없다"는 명단은 태그가 부착된 기사를 붙이지 않고 있다.그러나, 리스트를 편집할 수 없는 것과 무료가 아닌 컨텐츠의 남용으로 완성된 현재의 실행은 분명히 그렇지 않다.WMF 개발자들은 플로우, 벡터, VE가 여전히 메시지를 통과하지 못한 것으로 보이므로 그들의 포트폴리오에서 가장 많이 보는 사이트는 그들의 개인 샌드박스가 아니라는 강력한 신호를 보낼 필요가 있다.∙ 무지개빛 20:07, 2016년 1월 22일 (UTC)[응답]

일부 긍정적 댓글

나는 사실 Gather가 소셜 네트워킹 웹사이트로의 이동의 일부가 될 수 있다고 생각한다.나는 우리가 전통적으로 "소셜 네트워킹" 타입의 활동에 대해 눈살을 찌푸려왔다는 것을 알지만, 나는 우리가 그 입장을 재검토해야 한다고 생각한다.10년 전 우리는 백과사전 위주의 글을 쓰지 않는 것에 대해 지금보다 좀 더 관대한 태도를 보였는데, 나는 그것이 이 곳을 더 멋지고 덜 짜증나는 곳으로 만드는 데 한 몫을 했다고 생각한다.우리는 조금 느긋하게 사람들이 백과사전을 훼손하지 않고 약간의 허황된 사용자 페이지와 방명록을 가질 수 있도록 허락할 수 있고 바보 같은 게임을 하고 "favourite 기사" 목록을 공유하며, 우리는 더 많은 사람들이 이 사이트에 로그인할 수 있을 것이다. 그리고 가끔 "편집"을 클릭하도록 설득될 수 있을 것이다.기고자가 될 수도 있어—쿠스마 (t·c) 20:11, 2016년 1월 20일 (UTC)[응답]

모두가 '소셜 미디어' 같은 냄새가 나는 어떤 일에도 항상 소름이 끼치지만, 나는 적극적으로 편집하기보다는 자신의 독서 경험을 최적화하기 위해 계정을 사용하는 것에 대한 반감을 결코 이해하지 못했다.기본 설정 설정, 책갈피 작성, 기사 공유는 2016년 웹사이트에서 독자들이 할 수 있는 모든 것이다.이 연장은 잘 짜여져 보이지 않지만, 올바른 방향을 목표로 하고 있다.오파비니아 레갈리스 (토크) 2016년 1월 20일 (UTC) 20:30[응답]

그래, 위키피디아에 사교적인 것을 추가하는 것은 좋은 일일지도 몰라.그러나 이것은 평소처럼 충분히 잘 생각되지 않았다.만약 이러한 목록들이 공개적으로 접근할 수 있으려면(그러나 공개적으로 편집할 수 있는 것은 아님) 이 콘텐츠가 백과사전의 일부가 아니라는 것을 매우 명확히 할 필요가 있다.별도의 도메인(또는 적어도 사용자 이름 아래 하위 페이지)에서 호스팅하고, 전체 커뮤니티가 아닌 한 편집자가 이 내용을 큐레이션한다는 고지 사항을 추가하십시오.—Ruud 21:19, 2016년 1월 20일(UTC)[응답]

물론이지현재 상태에서는 즉시 비활성화해야 한다.—쿠스마 (t·c) 13:55, 2016년 1월 21일 (UTC)[응답]

사실, 어떻게 되는 거야?

각 컬렉션에는 "플래그"와 "숨기기" 버튼이 있다.이거 누르면 어떻게 돼?—루우드 22:10, 2016년 1월 20일 (UTC)[응답]

위키백과:수집/관리 기준이 이와 관련이 있는 것 같음...—uud 22:14, 2016년 1월 20일 (UTC)[응답]

누가 이것들을 중재하는가?커뮤니티가 아니라 희망컨대, 다수의 관리자들(나 자신이 포함)이 명시적으로 이를 거절했고 WMF가 명시적으로 자신들의 콘텐츠 진행자를 고용하기로 동의한 것처럼 보였기 때문이다.MER-C 02:02, 2016년 1월 21일 (UTC)[응답]

명확히 하기 위해 WMF는 지금까지 콘텐츠 진행자, 컬렉션 등을 고용하지 않았으며, 하위권인 Gather admins에 의해 조정되어 기능 작업을 하는 사람들이 테스트 내내 컬렉션을 필터링할 수 있게 되었다.--Melamrawy (WMF) (토크) 16:52, 2016년 1월 22일 (UTC)[응답]

수집 페이지와 관련 페이지 모두(Webedia: 참조):마을 펌프(정책)/아카이브 124#WMF는 자동으로 생성된 "See alone" 섹션)을 통해 비자유 콘텐츠를 기사에 삽입하는 것으로 보이며, 이들은 "여기도 발명되지 않은" 신드롬에 시달리고 있는 것으로 보인다. 즉, 기존의 유사한 특징과 잘 통합되지 않은 기능뿐만 아니라, 다른 일반적인 역량 문제들...(위키피디아:miscellany_for_deletion#위키백과:수집/사용자 피드백, [5], [6], ... —루드 02:51, 2016년 1월 21일(UTC)[응답]

하지만 구체적으로 말하자면, 만약 누군가가 "공화당 대선 후보들과 SS 장교들의 리스트"를 만든다면, 내가 "내 리스트인데 내가 원하는 어떤 기사도 넣을 수 있다"고 해서 '플랙'이나 '숨기기'를 클릭해야 할까, 아니면 아무것도 하지 말아야 할까?(hypotically, 물론, 나는 하루종일 버튼을 클릭하는 것보다 더 좋은 일이 있다.) —루드 03:14, 2016년 1월 21일 (UTC)[응답]

WMF는 커뮤니티에 일일이 확인하지 않고 Gather를 개발했고, 수용/수용 불가 정책을 만든 것에 대해 "책임 있다"는 메시지와 함께 배치를 발표했고, 그들을 위해 우리가 그것을 경찰에 신고하기를 기대했다.어떤 정책도 만들어지지 않았다.여기서 답변에 가장 가까운 것은 몇몇 사람들이 대부분의 컬렉션이 스피드 삭제 기준 U5에 해당한다고 말한 것이다.만약 당신이 손으로 모든 수집품들을 훑어보고 싶다면, 당신은 어떤 수집품에도 플래그를 달거나 숨길 수 있다고 말하고 싶다.관리자 공지사항 게시판은 관리자가 수집과 관련된 문제를 처리하기 위해 어떤 조치도 취하지 않아야 한다는 데 동의했다.알제 (대화) 2016년 1월 22일 19:42 (UTC)[응답]

하하하 뤼드! (첫 줄) 보스코스웰 (토크) 10:59, 2016년 1월 23일 (UTC)[응답하라]

결론

좋아, 이 테스트-더-워터 토론은 복수의 편집자들이 당분간 enwiki에서 Gather를 비활성화해야 한다고 생각한다는 것을 보여주었다.이제 WMF에 발표할 공식적인 논의를 시작할 때다(RfC의 결론이 물론 같다면).어디가 제일 좋니?여기? 마을 펌프 정책?WP:AN? 나는 가능하면 절차상의 반대를 피하기 위해 처음부터 바로잡고 싶다(WMF 개발은 기술적으로 합의에 반하여 그들이 원하는 것은 무엇이든 할 수 있다는 반대와는 별개로, 이것은 사실이지만 그렇게 하는 것이 매우 현명하다는 것을 의미하지는 않는다.프람 (대화)20:52, 2016년 1월 21일 (UTC)[응답]

마을 펌프가 작동하든지, 내가 보기엔.조조 유메루스 (토크, 기여) 2016년 1월 21일 (UTC) 20:55 [응답]

IMO 이 페이지는 단순히 RFC가 종료되도록 제안하는 것에 가장 적합하다.한편, 수집 컬렉션 처리에 대한 정책도 없으므로, 수집 컬렉션을 처리하기 위한 정책을 만들 것인지에 대한 정책 페이지 토론회를 여는 것도 타당할 수 있으며... 또한 그렇지 않다면 모두 단순히 빠른 삭제(또는 봇 삭제)의 대상이 되는지에 대한 정책 페이지 토론을 여는 것도 타당할 수 있다.꺼져야 하는지에 대한 "불안한" 질문이 있을 수 있다.알제 (대화) 03:01, 2016년 1월 22일 (UTC)[응답]

• 우리는 그것을 여기에 넣어야 한다.내 생각에 문제는 그것이 장애인이라는 것이고, 그 경우에는 정책이 중복될 것이다.만약 불능화 RFC가 실패한다면, 우리는 이미 AN에서 그것들을 완화시키고 싶지 않다는 합의를 가지고 있다.베스넛 (대화) 11시 32분, 2016년 1월 26일 (UTC)[응답]

다음주에 WMF 회신

안녕하십니까, 대화를 시작해주셔서 감사드리며, 정당한 우려를 분명히 밝혀주셨습니다.더 이상의 커뮤니티 반응은 계획할 필요가 없다. 다음 주까지 Gather 팀은 베타 테스트 전체에서의 성능과 위에서 공유한 합법적인 우려에 기초하여 이 기능에 대해 공유할 주요 업데이트를 가질 것이다.더 이상 "공동체의 협의 없이 목적이 불분명한 설계되지 않은 기능?"이 다시 출시되지 않기를 바란다. :)대화를 시작하고 명확한 우려를 나열해줘서 다시 한번 고마워.--멜라므라이 (WMF) (토크) 16:46, 2016년 1월 22일 (UTC)[응답]

@Melamrawy (WMF): 이 말은 커뮤니티가 반복적으로 요청해 온 것처럼 (a) 영어 위키백과에서 Gather on the English Wikipedia를 무력화시키거나 (b) 현지 정책을 위반하지 않는 완제품을 제시하거나, 정확한 이미지 귀속에 게을리하지 않으며, 라일라의 토크 페이지에서 작년에 레이져가 지적한 기본 사항을 다루기도 한다는 것을 의미한다고 본다.ere: 위키피디아에 공개되는 모든 것은 커뮤니티에 의해 큐레이션될 수 있어야 하며 커뮤니티의 도구(예: 최근 변경사항 피드 및 사용자 기여 목록)와 혼합될 수 있어야 한다.나로서는 (a)나 (b)가 발생하지 않는 한, 당신 팀이 무엇을 하고 있는지에 대한 업데이트에는 특별히 관심이 없다.베타 소프트웨어를 실행하는 데는 문제가 없지만, 선택적 확장의 중대한 문제가 발견되면, 예를 들어 선택적 확장을 해제하는 등 즉시 대처해야 한다.—쿠스마 (t·c) 19:35, 2016년 1월 22일 (UTC)[응답]

이미지 속성 질문에 대한 자세한 내용은 WP:VPP#기사와 연결되는 이미지—쿠스마 (t·c) 20:14, 2016년 1월 23일 (UTC)[응답]

Melamrawy (WMF), 나는 당신에게 반복적으로 WMF가 Gather에 대해 무엇을 해야 하는지에 대해 지역사회를 건설적으로 참여시킬 의향이 있는지 물어봤다는 것을 상기시키고 싶다.넌 그 질문에 대답하기를 반복해서 거부했다.프로젝트 매니저의 토크 페이지에서 적어도 두 번은 질문을 했는데, 그는 그 질문을 반복해서 무시했다.나는 WMF 전무에게 똑같은 질문을 했고, 그녀 또한 그것을 무시했다.나는 여섯 번 정도 물었다.내가 일방적인 RFC를 시작하지 않은 주된 이유는 한 가족이 암으로 병원에 입원했기 때문이다.나는 단지 지역 사회 참여에 대한 예의 바르게 행동하는 접근법을 다룰 수 없었기 때문에 그것을 그만두었다.

그 다음은 내가 다른 사람을 대변할 수는 없지만 다른 사람들이 RFC의 시작을 일주일 연기하는 것이 타당하다고 생각할 것 같다.나는 네가 Gather에게 유리한 WMF의 정보, 계획, 사례를 게시하는 것을 확실히 환영한다.내가 WMF-Community에 가입해 달라고 애원했을 때 나는 그런 것을 바라고 있었다.나는 네가 그것을 논의하기 위해 거의 확실히 RFC가 있을 것이라는 것을 알아주길 바란다.나는 WMF가 Gather를 끄는 것이 그 논의의 유효한 주제라는 것을 인정하기를 정말 바란다.아마도 최악의 시나리오는 커뮤니티가 수집을 거부하는 경우일 것이다. WMF는 커뮤니티가 이러한 결정에 참여하는 사업이 없는 사용자일 뿐이라는 입장을 취하고, 커뮤니티는 모든 컬렉션을 삭제/숨기기 위한 정책을 설정한 다음, 커뮤니티가 모든 컬렉션을 누르는 드러지 작업을 처리할 봇을 할당한다.WMF-커뮤니티 관계의 또 다른 다리를 태우는 것만이 성취될 수 있을 것이다.나는 좀 더 협력적인 결과가 있기를 바란다.알제 (대화) 22:58, 2016년 1월 22일 (UTC)[응답]

내 프로젝트가 아니라서 내가 틀릴 수도 있지만, 위의 레이져의 코멘트로 볼 때, 지역사회가 수집 목록을 삭제하는 것은 사실상 불가능해 보인다.

나는 그 팀이 중간고사에서 회복되어 가까운 미래에 대한 그들의 계획이 무엇인지 알려줄 수 있을 때까지 기다려야 한다고 생각해.Whatamidoing (WMF) (토크) 02:21, 2016년 1월 23일 (UTC)[응답]

Alsee에 돌아온걸 환영해. 그리고 너의 가족에 대해 듣게되서 정말 유감이야.나는 그들이 지금 훨씬 더 잘 지내고 있기를 바란다.아시다시피, WMF는 엔지니어링을 재평가했고, 그리고 나서 Reading 부서는 앞으로 나아가는 단계를 정의하기 위해 전략 프로세스를 시작했다.그러한 단계는 팀의 변화를 의미할 뿐만 아니라 기능 :)을 중심으로 RFC를 시작하는 것이 아니라 재사고와 계획을 위해 몇 걸음 뒤로 물러서는 것을 의미했다.로드맵에 따르면, 업그레이드 수집이 포함되며, 이러한 업데이트가 반드시 의미하는 것은 아니며, 기능의 현재 상태에 대한 작업을 계속한다.일반적으로, 그리고 위의 긍정적인 코멘트에서 언급된 바와 같이, 이 기능은 잠재력이 있고, 다른 커뮤니티 요청에도 응할 수 있으며, 베타 버전에서 잠시 실행한 후, 이 기능의 미래를 함께 재프로비저닝하는 것도 나쁘지 않을 것이다. :)---멜라므라이 (WMF) (토크) 20:17, 2016 (UTC)[응답]

나는 WMF 답변이 어떤 식으로든 만족스러운지 2월 초까지 기다려보고, 그 후에야 이것을 무력화시키는 RfC를 개최하기로 결정하기를 제안한다.이제 2주만 더 기다리면 크게 다치지 않을 정도로 반년 이상 반년 넘게 있었어.WMF가 이 RfC를 연기하기 위해 설득력 있고 중요한 것이 필요하다는 것을 깨닫는 한.앞으로 있을 화장품 변화나 개선 약속으로는 충분하지 않을 것이다.

WMF가 여기서만 수집을 시작했다고 내가 알고 있는 한.시험 첫 달에 대한 지역사회의 필요한 피드백을 어디서 수집했는가?아니면 결론과 새로운 방향은 문자 피드백이나 유지보수 고려사항에 기초하지 않고 순수하게 자료 중심적인 것인가?프람 (대화) 09:43, 2016년 1월 25일 (UTC)[응답]

위의 내용을 자세히 설명하자면, 당신은 "WMF가 아시다시피 엔지니어링 리오그(re-org)를 가지고 있었고, 리딩 부서는 앞으로 나아가는 단계를 정의하기 위해 전략 프로세스를 시작했다."고 말했는데, Gather에 대해서는 아무것도 없다.로드맵에서 업그레이드 수집 및 수집에 대해 언급하지만, 이 과정을 통해 얻을 수 있는 프로세스(또는 수집을 위한 업그레이드는 어떻게 되는지)에 대해서는 아무 것도 알 수 없지만, 이번 주나 다음 주에 듣게 될 내용인 것 같다.)프람 (토크) 2016년 1월 25일 (UTC) 10:00[응답]

안녕 Fram, Gather 개발은 엔지니어링과 디자인 작업을 필요로 한다.기능의 미래에 따라, 이러한 것들은 팀의 나머지 업무량과 함께 편리하도록 그에 따라 결정되어야 한다.예를 들어, 현재의 절제 시나리오를 변경하기 위해서는 기능이 구축되는 방식을 변경하기 위한 전용 엔지니어링 작업이 필요하며, 따라서 팀이 1월부터 4월까지 작업하고 있는 다른 계획별 사항을 감안할 때 향후 3개월 이내에 기대할 수 있는 것은 아닐 수 있다.수집은 한동안 진행되어 왔으며, 또한 한동안 유지되지도 않았는데, 이는 이상적인 경우는 아니지만, 불행하게도 변화와 계획 단계와 함께 이런 일이 일어날 수 있다.이런 상황을 함께 정리하면서 공동체적 가치를 유지하면서 좋은 잠재력을 잃지 않도록 하는 방법에 대해 우리 모두가 이해했으면 좋겠다.--멜라므라이(WMF) (대화) 2016년 1월 18:26, 2016년 1월 25일 (UTC)[응답]

솔직히, 멜라마와이(WMF)는 아무 말도 하지 않는 와플처럼 들린다.그래서 원하지 않는 툴은 어쨌든 여기서 실행되지만 유지되지는 않는다; 우리가 너무 오래 기다린 후, 그것을 종료하기를 원할 때, 당신은 다음 주에 "중대한 업데이트"를 할 것을 약속한다.그러나 지금은 큰 업데이트가 없을 것으로 보이지만, 2016년 5월 이후 계획에 대한 일부 발표(내가 짐작하는 "주요" 발표)가 있을 것으로 보인다.좋아, 그렇다면 종료하고 공지하고 변경되면 다시 활성화할 수 있는지 물어봐.그래야 '우리 공동체의 가치를 유지'하는 한 걸음을 내디뎠을 것이다.좋은 잠재력은 a) 훨씬 낫고 b) 여기서 원하는 도구를 닫아 버림으로써 상실되는 것이 아니지만, 도움이 안 되고, 원하지 않고 유지될 수 없는 도구를 활성화시켜 줌으로써 많은 지역사회 호의가 상실된다.우선 순위를 가지고 있고 가장 잘 반영되는 것은 여러분(WMF, 개인적으로 그렇지 않을 것이다)에게 달려있다.프람 (토크) 2016년 1월 25일 18:50 (UTC)[응답]

나는 네가 말하는 "좋은 잠재력"이 무엇인지 약간 당황스럽다.이 위키백과에서 사용하기에 적합하게 만들어졌을 때 지금 이 기능을 비활성화하고 다시 활성화할 수 있는 것은 무엇인가?고장난 연장선만 앞으로 두어 달 동안 계속 가동시키는 것보다 더 나쁜 것은 아무것도 보이지 않는다.—쿠스마 (t·c) 20:28, 2016년 1월 25일 (UTC)[응답]

내 설명이 전혀 아무것도 아닌 것처럼 보여서 안됐군, 프람 :)나는 왜 우리가 지금 있는 곳에 서 있는지, 그리고 내가 그 시간에 대해 언급했던 것은 비밀이 아니며, 팀은 이미 계획을 일찍 공유했고, 그것은 그들을 따르기에 좋은 신호다.또 다른 관점에서, (비공개적인 경우에도) 개인 사용자 목록을 갖는 것은 흥미로운 사용 사례로, 사용자 감시 목록에 대해 동일한 인프라(수정 후)를 사용하는 것은 이미 다른 곳에서 논의된 사용 사례로, 이 기능이 우리의 워크플로우와 가치를 유지하면서 독자들에게 어떻게 서비스를 제공할 수 있는지 탐구하고, 위키에 대해 어떻게 이해하도록 초대하는 것이다.페디아는 효과가 있어, 나쁘지 않은 노력이야.이것은 내가 일반적으로 좋은 잠재력을 의미한 것이고, 비활성화와 재활성화에 관계없이 말이다.마지막으로 팀은 여전히 현실적이고 실현 가능한 다음 단계를 논의하고 있으며, 추가 발표가 있을 것이다.고마워.--멜라므라이 (WMF) (토크) 21:56, 2016년 1월 25일 (UTC)[응답하라]

그게 문제야, 너의 '설명서'는 이번 주에 게허가 크게 바뀔 것이라는 인상을 먼저 주었고, 이것이 우리가 RfC와 함께 기다릴 수 있다는 반응을 불러일으켰다.하지만 당신의 다음 게시물에서는, 중요한 것은 아무것도 변하지 않을 것처럼 보였고, 단지 당신이 4월이나 그 이후에 어떤 일을 시작할 것인지에 대한 일부 발표만 있을 것이다.당신은 왜 아무도 원하지 않는 이 도구에 아무 일도 일어나지 않았는지에 대한 추론을 제시했지만, 당신은 왜 그것이 지금 비활성화되어서는 안 되는 이유를 단 한 가지도 제시하지 않았다."팀에서 계획을 일찍 공유한 장소와 이를 토대로 한 링크(link)가 존재한다면 명확한 링크를 제공할 수 있는가?그리고 지금이나 이번 주 후반에 발표될 때, 새로운 발표와 새로운 계획들이 기초가 될 정보에 대한 좋은 연결고리를 우리에게 줄 수 있는가?나는 당신이 이 전에 실제 커뮤니티의 의견을 모았기를 바라며, 이 발표가 지금과 지금 이 토론에 대한 단순한 무릎에 거슬리는 반응이 아니기를 바란다(시점은 우연일 수도 있지만, 이것에 대한 아무런 증거도 없이 확실히 의심스러워 보인다).동일한 인프라를 수리한 후 사용할 수 있도록 "사용자 감시 목록"을 좋은 사용자 사례로 제공하십시오.당신은 우리가 이미 워치리스트를 위한 인프라를 가지고 있고, 수년 동안 워치리스트에 대한 개선이 요구되어 왔다는 것을 알고 있는가?현재 기존 유형보다 훨씬 더 나쁜 새로운 유형을 얻는 것은 아마도 최선의 해결책은 아닐 것이다.사용자 워치리스트(및 일반적으로 워치리스트)는 어쨌든 대부분의 독자들에게는 별로 유용하지 않다. 그것들은 훨씬 더 편집자적인 것이다.모바일용으로 먼저 개발한다는 것은 사용자 상호작용을 얻고자 하는 바람 등을 훨씬 덜 나타낸다.아마도 당신은 Gather에서 이러한 잘못 생각되고 제대로 구성되지 않은 기능을 사용하는 대신, 모바일에서 쉽게 대화 페이지에 접근하고 편집할 수 있도록 하는 것에 초점을 맞출 수 있을 것이다.마지막으로, 현실적이고 실현 가능한 첫 단계가 이루어지지 않았고, 원하는 것과 필요한 것에 대한 명확한 초점이 존재하지 않는 것 같은데, 왜 우리는 "팀이 여전히 현실적이고 실현 가능한 다음 단계를 논의하고 있다"고 믿어야 하는가?이 개발은 "또 다른 WMF 대실패"라고 쓰여져 있다.하지만 이런 것이 이제 사용자들에게 더 쉽게 공유될 수 있고, WMF가 그것을 순찰할 수 있다는 것은 좋은 일이다.또는 [7] 또는 [8]과 같은 것.당신은 정말로 사람들이 이것을 창조하고 세상에 더 쉽게 공유하도록 하는 것이 현명하다고 생각하는가? 먼저 좋은 방법을 가지지 않고 사람들이 이런 것들을 추적하고 관리하지 않고?나는 당신에게 페이스북이나 트위터 링크나 이메일 주소로만 구성된 "수집"이나, [9]나 [10] 같은 것을 홍보하는 (비효과적인) 방법만을 보여주지도 않는다. (물론, 당신은 회사 등을 공격하는 데 사용되는 수집품도 많이 얻지만, 별로 낫지도 않다.)프람 (토크) 08:30, 2016년 1월 26일 (UTC)[응답]

WMF가 공식적으로 이 콘텐츠의 치안 유지 업무를 담당하고 있기 때문에, 나는 Melamrawy와 그녀의 팀 모두가 이 콘텐츠가 괜찮다고 생각한다고 생각한다.아니면 그들은 그들의 일을 하고 있지 않다.이 경우 Gather를 간단히 차단하는 것이 관련자 모두에게 더 좋을 것이다.—쿠스마 (t·c) 14:37, 2016년 1월 26일 (UTC)[응답]

@Melamrawy (WMF): "다음 주까지, Gather 팀이 이 기능에 대해 공유할 중대한 업데이트가 있을 것"이라는 당신의 진술에 혼란스러워. ("업데이트"가 소프트웨어 감각이 아니라 여기서 정보 감각에 사용되고 있다고 가정하고 있어?)당신은 Gather 팀의 일원이십니까?그렇다면 이 "사전 업데이트" 대신 업데이트만 주면 안 될까?만약 그렇지 않다면, 당신은 이것에 대해 어떻게 아는가?그들이 어디선가 무슨 말을 했니?링크 좀 줄래?개방적인 의사소통이 진행되고 있는 것일까, 아니면 이런 것들이 민간 WMF 전용 채널을 통해서만 이뤄지고 있는 것일까?

어떤 상황인지 설명해 주시겠습니까?이런 댓글들이 꽤 걱정스럽다. --에어랜드 (토크) 08:48, 2016년 1월 26일 (UTC)[응답하라]

프람, 독서 로드맵은 내가 공유한 초기 계획과 야어랜드, 나는 Gather 패치를 개발하지 않고 Gather 인터페이스를 설계하지 않는다. 그래서 내가 팀에 속해 있는 동안, 개발자와 디자이너의 워크플로우를 고려하는 더 넓은 내부 논의가 이루어져야 한다. 그렇지 않으면, 우리는 결국 약속된 것을 끝낼 수 있다.또는 잘못 해석한 것, 그것은 우리에게 확실히 필요하지 않다.이것은 조직적이고 매우 논리적인 과정으로, 여기서 우리의 공개적인 논의를 따라 일어나야 한다. :)--멜라므라이 (WMF) (토크) 10:55, 2016년 1월 26일 (UTC)[응답]

멜라므로이, 진심이야?WMF 커뮤니티 연락은 WMF 보드나 WMF 품질 관리만큼 쓸모없는 것 같아, 내가 얼마 동안 교류한 두 개의 리아나로부터 판단할 수 있는 한."독서 로드맵은 공유되는 초기 계획에서 말한 것이다."정말, 바로 그거야.두려운 일이지만 그래도 뭔가 오해가 일어나길 바랐다.그 페이지에서 Gather에 대해 뭐라고 하는지 확인해 봤어?전략적인 기둥: "독자 커뮤니티를 개발하라"팀: "웹" Q4: "TBD(감시 목록/게더)"그게 다야, 그게 다야.그리고 "그"는 "팀이 이미 일찍 계획을 공유했고, 그것은 그들을 준수하는 좋은 신호"라고 감히 말할 수 있다.음, 그들의 "계획"은 4분기(회계연도 일정에 따라 기술적 변화가 발표되는 이유를 이해하지 못하는 대부분의 사람들을 위한 2016년 2분기)에 어떤 것을 결정하는 것이었는데, 그것은 웹 기반의 "무엇"이며 "미안하지만, 자본이 R인 독자 커뮤니티"를 개발하려는 의도였다.그래, 나눠줘서 고맙고 팀원들이 잘 지켜줘서 고마워, 정말 인상적이야

다시 한 번 말해보죠: "우리 WMF는 아무도 원하지 않았고, 아무도 테스트하지 않았으며, 유지 방법을 아는 사람이 없었다. 그리고 나서 엔위키가 진저리를 치고 그것을 없애겠다고 위협할 때까지 우리는 9개월 동안 그것을 포기했다.그리고 나서 우리는 어쨌든 그 기간 동안만 중대한 변화를 계획한 척했고, 그 후 우리는 주요 발표를 약속하는 것으로 바뀌어야 했고, 빠르면 2014년 4월 이전에는 아무런 변화가 없었다.우리는 우리의 계획과 목표를 공유했다고 주장했지만, 실제로 이것과 유사한 원격으로 어떤 것도 하지 않았다.우리는 일방통행식 지역사회 연락책들을 좀 더 망쳐놓음으로써 평정을 유지하려고 노력하는 동안, 우리는 더 이상의 공동체 입력을 하지 않고 몇몇 추정치와 목표를 개발하기 위해 싸운다. 그리고 그것은 단지 웃기 위해서, 매우 논리적인 과정이라고 주장한다.운이 좋으면, 그들은 그것에 속아 넘어갈 것이고 우리는 적어도 6개월은 더 이상 우리가 그랬던 것처럼 계속할 수 있을 것이고, 우리가 새로운 프로젝트로 다시 실패할 뻔했다는 것을 아무도 알 수 없을 것이다.또 하나의 주요 WMF 성공!"프람 (토크) 2016년 1월 26일 11시 16분 (UTC)[응답]

프람, 어떤 로드맵이든 장단기적으로 다뤄져야 할 주요 이슈를 표시한다.아직 6개월도 남지 않은 일에 대해 구체적인 계획을 제시한다는 것은 말이 안 되기 때문에 실행 계획이 아니다.결코 정확하지 않을 것이다.Reading Roadmap에서 보듯이, Gather는 Android 워크플로우에서 지금부터 4월까지의 3분기 동안 "Synchronized saved page list"로 언급되고, 그러면 웹 팀은 4월 이후 3개월인 4분기에 아직 결정되지 않은 Gather 작업을 하게 된다.그게 무슨 의미죠?'모으기'에 어떤 변화가 일어나야 한다는 것을 이해하지만, 이것이 논의 없이는 앞으로 나아갈 수 없다는 뜻이다.우연히 계획과 일치하는 의견을 게시하셨는데, 제가 자세히 설명하고자 하는 것은, 네, Gather가 계획을 세웠고, 다음 단계의 세부사항은 커뮤니티 토론(여기서 처음 토론 후)과 함께 정의해야 할 사항이며, 특집 성과와 팀 역량도 함께 정의해야 할 사항입니다.이것은 Gather에 관한 한이다.다른 말로 하자면, 당신의 최근 논평은 나와 나의 동료들 그리고 이사회를 불쾌하게 만드는 불쾌한 말투로 시작하는 반면, 내가 이해한 바로는 진정한 인간이고, 우리의 공동체의 가치에 WMF 제품을 맞추려고 노력하는 사용자는 우리의 가치관을 스스로 돌볼 것이고, 그래서 나는 내가 읽은 것이 단지 아주 긴 시간이었기를 바란다.오타, 또는 그 무엇 :).--멜라므라이 (WMF) (토크) 14:18, 2016년 1월 26일 (UTC)[응답]

그러나 "저장된 페이지 목록 동기화"가 수집과 관련이 있다는 징후는 없다.수집은 4분기에만 언급된다."저장된 페이지 목록 동기화"는 극히 모호한 용어임에도 불구하고 어떤 경우에도 수집을 비활성화하려는 이유를 설명하지 않는다."그게 무슨 뜻이야?'모으기'에 어떤 변화가 일어나야 한다는 것을 팀원들이 이해한다는 뜻인데, 이는 논의 없이는 앞으로 나아갈 수 없다."아니, 그건 전혀 그런 뜻이 아니야.너는 이것을 그것에 투영할 수 있지만, 우리가 그것에 속을 거라고 기대하지는 마.그것은 불쾌하다.당신은 FAQ를 "초기 토론"으로 연결한다(또한 상당히 혼란스럽다, FAQ는 유사하게 만들어졌음에도 불구하고 토론이 아니다).2015년 5월 이후 편집되지 않은 그 FAQ에서 : " 로드맵이란?3월 말까지 베타 버전을 출시할 예정이고 3개월 동안 운영될 예정이고, 그 후에 배운 교훈을 풀 릴리즈에 적용한다고 말했다.우리는 이제 10개월( ~ 3개월)이나 더 남았는데, "배운 사람들"이 모여 논의되는 장소가 있다는 징후는 전혀 없다.FAQ는 실제 구현(예: 페이지 관리)과 별로 유사하지 않다."관리자는 문제가 플래그로 표시되면 목록을 숨기거나 숨길 권리가 있다."나는 지금 며칠 동안 Gather를 보았고, 심지어 내가 숨길 수 있고, 숨길 수 있는 테스트 리스트를 만들었지만, 다시 삭제할 수는 없다.수집 목록에 플래그를 지정하는 위치와 방법을 알고 있다.하지만 어느 페이지에 플래그가 붙었는지, 언제, 누구에 의해...유용하다!

그래서, "다음 단계의 세부사항들은 우리가 공동체의 논의에 따라 함께 정의해야 할 사항이다.어디서, 언제 커뮤니티 토론이 계획되었는가?이번 분기에 Gather에 대해 작업할 계획인데, 이 문제는 어디서 논의되고 결정되었는가?

다른 쪽에서는, WMF 제품을 우리의 공동체 가치에 맞추려고 노력하는 사람을 발견하면, 나는 그들을 예의 바르게 대할 것이다.내가는 Windows메타 파일행동해야할 누군가가 민간적이고, 그렇지 않으면 전혀 관련성이 없고, 유용하고, 구체적인 정보가 없는 많은 환자 설명을 하는 것을 발견했을 때, 나는 그들에게 그들의 접근법을 고칠 수 있는 기회를 한두 번 주고, 그리고 나서 그들이 최고의 이익을 가진 것처럼 행동하는 것을 끝냈다 옹호자처럼.마음속의 재주기분이 상할 수 있는 동료들에 대해 말하자면, 내가 그녀에 대해 어떻게 느끼는지 완벽하게 알고 있는 한 명의 다른 지역사회 연락 담당자는, 내가 그녀에 대해 어떻게 느끼는지, WMF는 오랫동안 많은 존경을 받을 만한 가치가 있는 것을 그만두었다. 하지만 그 안에 있는 몇몇 사람들은 정확하고 사실적인 정보와 대답을 주고 정말로 도와주려고 하는, 내가 하는, 좋은 뜻을 가진 사람들이다.그들이 누구인지 알겠다는 의지로 네터레이트를 한 것; 그리고 "보드"는 WMF 이사회를 말하는가?현재 90%가 새로 선임된 위원을 해임하고 앞으로 누구를 임명할 것인지에 대한 의견을 묻는 청원 대상이다.공동체에서 선출된 구성원을 제거했지만 그에 대한 하나의 적절한 이유를 제공하지 못하는 사람?어떤 경우에도 무의미하고 이빨이 없는 것 같아 아무도 신경 쓰지 않는 그 사람?그 위원회의 현재 구성원들이 사용하는 언어는 훨씬 더 불쾌하다. 어쨌든 그 차이점의 끝을 보라.만약 그들이 내가 여기에 올린 글에 기분이 상했다면 정말 미안해.반대로 이 마을 펌프를 말하는 거라면, 글쎄, 토론 게시판이 기분 나빠할 수는 없을 것 같고, 참여하는 사람들이 기분 상했는지 안 상했는지 스스로 결정할 것이다.물론 내 이전 직책의 대담한 부분은 불쾌했고, 당신의 실수는 대개 단기적으로는 불쾌하다.그렇다고 해서 그 어느 것도 명백히 잘못되는 것은 아니다.

기본적으로 기분 나빠하는 대신, 당신은 마침내 몇 가지 구체적인 것을 나타낼 수 있을 것이다.Gather에 대한 추가 작업이 시작되기 전에 어떤 지역사회 논의가 계획되고 있는가?팀은 어디에서 수집에 대한 데이터와 피드백을 수집했는가?이 오작동, 유지보수가 불가능하고 문제가 있는 도구(예: 이전 게시물의 링크 참조)를 당분간 비활성화하면 안 되는 이유는 무엇인가?이번 주에는 어떤 주요 업데이트를 받을까?제발, 다시는 그 로드맵을 지적하지 마, 너는 그냥 웃음거리가 되고 있어.프람 (대화) 2016년 1월 26일 (UTC) 15:00[응답]

이것 좀 그만해.이집트 알렉산드리아에 있는 한 시간제 계약자에게 마치 자신이 더 나쁜 제1세계 다국적 보스인 것처럼 소리치고 있는 것이다.정말 싫습니다.알란스코트워커 (대화) 15:19, 2016년 1월 26일 (UTC)[응답]

이집트 알렉산드리아에서 왜 1세계 대 계약자를 추가해야 하는지 모르겠다.나는 멜라모웨이가 어디서 왔는지, 현재 일하고 있는지 전혀 모르고, 신경도 안 써.내가 신경쓰는 것은 유용하고 진실된 대답을 얻는 것이다.지역 연락 담당자에게서 그런 걸 얻을 수 없다면 그게 무슨 소용이겠어?위의 모든 반응에서, 그들의 Gather에 대한 계획과 이 계획들이 더 명확하게 근거하고 있다는 것을 내가 지적할 수 있는 것은 아무것도 없다.우리가 얻는 것은 난독화, 무지, 그리고 이것이 지적되었을 때 불쾌해지는 것뿐이다.유사성을 원하는 경우:나는 계약자에게 소리를 지르는 것이 아니라, 내가 원하지도 않았고, 사용할 수도 없고, 없애고 싶은 도구를 내 집에 설치했지만, 그들은 새롭고 더 좋은 버전이 코앞에 다가왔기 때문에 그것을 다시 없애는 것을 고려조차 하지 않는 판매원에게 질렸다.프람 (토크) 15:44, 2016년 1월 26일 (UTC)[응답]

네 코멘트가 너무 리얼리티 체크를 필요로 한다고 해서 꺼냈어.여긴 네 집이 아니야이곳은 넓은 문화공간을 가로질러 다른 사람들과 함께 일해야 하는 곳인데, 이 근처에서는 힘들 수도 있고, 때로는 감당하지 못하는 사람들도 있다.참고 항목: 위키백과:분노한 마스토돈 없음 --Alanscottwalker (대화) 15:51, 2016년 1월 26일 (UTC)[응답하라]

나는 소리지르는 것(그리고 위원회와 짐보에 대한 다소 엉뚱한 주제 발언)이 특별히 건설적이라고 생각하지는 않지만, 프람의 게시물에는 멜라마이로이보다 수집에 대한 내용과 정보가 더 많이 포함되어 있는데, 이는 앨시가 위에서 언급한 것처럼 "지역 사회 참여에 대한 "극단적인 벽돌벽 접근법"에 들어맞는 것 같다.가장 명백한 문제(장식용 비자유매체 표시)를 고치는 것에도 저항이 있는 것으로 보인다.—쿠스마 (t·c) 15:58, 2016년 1월 26일 (UTC)[응답]

Melamrawy (WMF) 위의 긍정적인 진행에 대해 감사드리고 싶다.당신의 처음 두 개의 답변은 우리에게 RFC를 운영하지 말라고 말하려고 했고, 우리가 하는 말의 중요한 부분을 인정하지 않았다.위의 일부 "공세적인 어조"에 대한 당신의 반대는 전적으로 이해할 수 있지만, 그 어조의 이유 또한 매우 이해할 수 있다.무슨 말을 하려는 건지, 무슨 말을 해도 되는지 모르겠지만, 한 가지 제안을 하고 싶다.(1) WMF는 여기서 파트너로서 커뮤니티 컨센서스를 존중하며, (2) Gather를 영구적으로 종료하는 것이 논의 테이블에서 유효한 주제임을 인정한다면, 즉시 온도를 낮추고 우리가 함께 작업할 수 있도록 도울 것이다.WMF가 의무적인 프로젝트에 대한 업그레이드를 제외한 어떤 논의도 존중하지 않으려 한다는 인식이 있을 때 협력적인 논의를 하기는 어렵다.알제 (대화) 2016년 1월 26일 (UTC) 17시 15분 아, RFC가 막 시작되었다.오케이, 저쪽으로 가.알제 (대화) 2016년 1월 26일 17:25 (UTC)[응답]

이제 RfC 시작

RfC는 이제 위키백과에서 시작되었다.마을 펌프(제안)#RfC: 아래 enwiki에서 수집 사용 안 함.프람 (대화) 2016년 1월 26일 15:45 (UTC)[응답]

다음 단계 발표가 있을 때까지 기다리는 줄 알았는데?:. 비활성화를 지원하는 문제가 실제로 해결된다면? --멜라므라이 (WMF) (토크) 2016년 1월 26일 (UTC) 16:31, 26 (응답)

WMF가 이 문제들에 관여할 수 있는 충분한 시간이 있었고 우리는 이미 당신의 약속된 발표를 기다렸으나 아무것도 아닌 것으로 판명되었다.적어도 우리 중 몇몇에게는 우리의 인내심이 이제 끝이 났다.베스넛 (대화) 2016년 1월 26일 (UTC) 16:46[응답]

웃는 얼굴을 삽입하는 PS는 사람들을 더 행복하게 하거나 협동심을 갖게 하지 않는다.당신이 불만을 가진 사람들을 대할 때 그것은 후견인으로 간주된다.베스노우트 (대화) 2016년 1월 26일 (UTC) 16:48 [응답]

그래?언제? 어떻게?나는 사람들이 모든 돌담에 약간 싫증을 낸다고 생각한다.—uud 16:57, 2016년 1월 26일 (UTC)[응답]

글쎄요, 위에서 여러 번 설명했듯이, 팀은 특성으로 수집하려면 설계 및 엔지니어링 변경이 필요하며, 특성은 이미 로드맵에 나와 있으며, 더 넓은 커뮤니티 토론을 하기 전에 내부 대화를 하는 것이 허용된다는 것을 알고 있다.웃음은 거드름을 피우지 않는다. 이런 일이 일어난 것이 유감스럽지만, 누구에게도 악의는 없다. 나는 단지 왜 상황이 변하는지 놀랐고, 팀이 새로운 소식을 발표한 후에 팀 발표가 있을 때까지 기다리지 않기로 결정했다.어쨌든 WMF 업데이트는 이번 주말까지 계속 발표될 것이다.Melamrawy (WMF) (토크) 17:27, 2016년 1월 26일 (UTC)[응답]

@Melamrawy (WMF): 이쯤 되면 기술자들과 대화해서 그냥 끄는 것이 좋을 것이다.The RfC is very unlikely to say to keep it and you have been advised of how the lists can violate Wikipedia's core content policies, WP:BLP(To the point of an example being provided that seems to target a named minor), WP:NFCC(By making use of images beyond their Fair-use rational.), and WP:NPOV. You have also been informed that the community has이러한 목록을 적절하게 감시할 수 있는 방법이나, 이러한 정책 위반이 발견되는 경우 또는 발견되는 경우 이를 해결할 수 있는 방법이 없다.이는 사소한 문제가 아니며 개발자들이 "로드맵"과 "내부 엔지니어링 대화"를 하는 동안 en.wp(또는 어디에서나)를 계속하도록 허용해서는 안 되며, 다른 의미 없는 프로젝트 관리가 바퀴 돌리기 위해 말하는 것이 유행하고 있다.

공동체 관계 관리의 본질은 당신이 승산이 없는 상황에 직면했을 때, 그리고 어떻게 하면 자신의 관련성을 상실할 때까지 말을 타고 공동체의 신뢰를 느슨하게 하지 않을 수 있는지를 인식하는 것이다.Jbh^Talk 18:36, 2016년 1월 26일 (UTC)[응답하라]

법적 문제

그래서 지역사회와 개발팀 모두 현재 이러한 리스트를 조정하고 있는 것 같지 않다.Fram이 위에서 지적한 리스트들 중 일부는 잠재적으로 거짓말이 될 수 있다.개발팀은 WMF Lawy와 이 도구의 잠재적 영향에 대해 논의하였는가?그들은 괜찮니?누가 고소하면 어떻게 해야 하는지 알아?과거에 나는 사용자에게 다음과 같이 물었을 것이다.필립(WMF)은 이 일에 대해, 그가 떠난 것 같다.—루우드 17:46, 2016년 1월 26일 (UTC)[응답]

@Ruud Koot:사용자:지금 엠데니스(WMF)가 그 일을 처리하고 있다. (확실하지 않다.) --에어랜드(토크) 21:30, 2016년 1월 26일 (UTC)[응답하라]

WMF의 응답

안녕하십니까, 저는 Gather를 만든 팀을 포함하여 독서팀을 운영하고 있는 Toby입니다. 그리고 그것에 대한 최신 정보를 알려드리고 싶었습니다.

무엇보다도, 나는 Gather에 대한 이슈와 영어 위키백과 커뮤니티의 가치를 완전히 이해하고 인정한다.나는 그 특징이 기여자의 수를 늘리려는 의도로 선의로 만들어졌다고 믿지만, 그 시행은 분명히 생각되지 않은 문제들을 만들어냈다.나는 또한 우리가 재단으로서 그 특징의 창조와 디자인에 있어서 충분히 투명하지 않았다고 믿는다.

이것은 복잡한 상황이고 리딩 팀에 있는 우리는 다양한 옵션의 영향을 분석하는 데 시간이 필요하다는 것을 이해해줘.예를 들어 기능이 비활성화된 경우 생성된 컬렉션에 대해 수행할 작업을 평가해야 한다.그동안 제기된 법률적 우려도 들여다보고 있다.다음 주 결정과 함께 공개적으로 공유한다는 취지에서 지금부터 이 분석을 종합한다는 계획이다.

나는 우리 지역사회와 훨씬 더 좋은 관계를 맺고 싶고 이것이 리딩 팀의 더 좋고 투명한 소통의 시작이 되기를 바란다.TNegrin (WMF) (토크) 21:11, 2016년 1월 28일 (UTC)[응답]

그렇다면 WMF가 지역사회의 우려에 대응하기 전에 기능을 비활성화해야 한다는 RfC의 위협이 필요한가?몇 가지 RfC를 써야 하는데...어쨌든, RfC 타이밍에 따르면 한 달은 남았을 겁니다.또한 좋은 공동체 관계를 원하면 홍보 톤을 떨어뜨릴 수 있다.행동들은 말보다 더 큰 소리로 말하고, 만약 당신이 내가 이름지을 수 있는 어떤 WMF 직원들처럼 말한다면, 당신은 당신 자신만을 소외시킬 것이다.베스넛 (대화) 21:26, 2016년 1월 28일 (UTC)[응답]

내가 뭘 가장 방해하는지 알아?WMF에 어떤 교훈이 담긴 데이터베이스가 없다는 사실은 마치 VE팀이 리딩 팀에게 지역사회가 나중에 용서를 구하는 것보다 먼저 허가를 내주겠다고 말하는 것을 잊은 것 같다.많은 다른 팀들이 같은 잘못된 인상을 공유한 것 같다."우리의 지역사회와 훨씬 더 나은 관계를 가지라"는 표현은 우리가 전에, 계속해서 들은 것이다.겉으로 드러나는 사일로에서 벗어나 서로 이야기를 나누거나, 위키를 이용해 지역사회 참여에 관한 내용을 적어 팀원들에게 읽게 한다. --Izno (대화) 12:37, 2016년 1월 29일 (UTC)[응답]

호기심에서, 사용자:Melamrawy (WMF), 이것이 지난 주에 약속한 "주요 업데이트"인가, 아니면 조기 업데이트인가, 아니면 우리가 대신 받을 수 있는 것인가?단지 당신의 WMF 동료가 주요 업데이트가 이미 개발 중이고 거의 완료되었다고 말했을 뿐이고, 나는 "[...] 우연히 당신의 코멘트를 계획 [...]과 동조하여 게시하였다고 말했을 뿐인데, 이것은 당신이 여기서 토론과 RfC에 대응하여 토론과 분석을 시작했을 뿐이라는 인상을 준다.기본적으로 "지금부터 이 분석을 종합할 것"은 이미 WMF가 계획했던 약속된 주요 업데이트와 일치하지 않는 것 같다.프람(토크) 13:23, 2016년 1월 31일 (UTC)[응답]

User:TNegrin (WMF), 우선 mw 하단에 있는 다소 잘못된 알림을 제거해 주시겠습니까?확장:모이라고?"이 확장자는 하나 이상의 위키미디어 프로젝트에 사용되고 있다.이는 아마도 그 연장이 안정적이고 그렇게 트래픽이 많은 웹사이트에서 이용될 수 있을 만큼 충분히 잘 작동한다는 것을 의미할 것이다." 너무나 많은 단계에서 잘못된 것이다...프람(대화) 12시 48분, 2016년 2월 1일 (UTC)[응답]

아니, 그건 불가능해.그 진술은 템플릿의 일부분이다.그리고 기술적으로 위키백과 위키백과 위키에서 사용할 수 있을 정도로 확장성이 안정적(버기가 아닌 상태)으로, 예를 들어 위키를 손상시키지 않는다. --Izno (토크) 12:58, 2016년 2월 1일 (UTC)[응답]

아주 이상한 대답이야, 이즈노나는 통지의 삭제, 즉 그 페이지에 있는 그 템플릿의 삭제를 요청했다.나는 여기서 "불가능"한 것을 보지 못한다.프람 (토크) 13:13, 2016년 2월 1일 (UTC)[응답]

여기서 제기되는 우려가 철거를 정당화하지 못한다는 것이 문제라고 생각한다."확장"은 최고 등급에서 일부 버그, 심각한 오작동, 주요 보안 문제까지 질적으로 다양할 수 있으며, 여기서 제기되는 우려는 최고 등급이 아니라 낮은 수준 어딘가에 해당된다.조조 유메루스 (토크, 기여) 13:15, 2016년 2월 1일 (UTC)[응답]

다시 말하자면:미디어위키키에는 확장 페이지에 대한 지침이 있다.그 중 하나는 확장을 사용할 수 있는지(또는 일반적으로 어떤 상태인지)에 대한 문서화다.따라서, 이 템플릿의 제거는 위키미디어 위키에서 사용될 수 있을 만큼 충분히 잘 기능하기 때문에 해당 가이드라인에 위배된다.기본적으로 이 요청은 잘못 짚고 있다. --Izno (대화) 13:18, 2016년 2월 1일 (UTC)[응답하라]

그리고 여기서 제거되면 그들은 어떻게 할 것인가?확장은 여전히 똑같겠지만, 템플릿은 다른 위키미디어 프로젝트에서 사용되지 않기 때문에 거짓일 것이다(내가 아는 한.어쨌든, WMF가 이런 것을 "사용 가능한" 것으로 여긴다면, 그것은 많은 것을 설명해준다.한편, 나는 리퀴드스레드도 같은 것을 가지고 있다는 것을 주목한다. 비록 맨 위에 있는 것이 모든 새로운 설비를 좌절시키지만 말이다.꽤 모순적이군, 그거.사람들은 실현에 대한 자부심을 기대할 것이다. 즉, 모든 주요 버그에서 벗어나 철저히 테스트를 거친 "배포 준비 완료" 라벨을 몇 주 안에 해킹하여 폐기한 것이 아니라, 초기에 약속한 기능 중 절반은 (예: 플래그링 문제) 필요한 재미에 신경 쓰지 않는다.이온성프람 (토크) 13:23, 2016년 2월 1일 (UTC)[응답]

수집은 히브리 위키백과에서도 사용되고 있다.[11]을 참조하십시오.연장의 문제는 기술적인 문제가 아니라, 연장이 웹사이트의 위키 부분과 잘 연계되지 않고, 주변의 사회적, 사용적합성 문제가 있다는 것이다.다른 MediaWiki 사용자는 이 기능이 유용하다고 생각할 수 있다.—쿠스마 (t·c) 13:47, 2016년 2월 1일 (UTC)[응답]

고마워. 나도 많은 기술적 이슈들을 봐. 하지만 WMF의 MVP(이것을 설치하는 것은 사이트의 나머지 부분을 파괴하지 않을 것이다)를 고려할 때, 그것은 아마도 실패보다는 성공으로 여겨져야 할 것이다.그나저나 Gather에 대한 지난 주 약속된 주요 업데이트를 어디서 읽을 수 있는지 아십니까?아니면 중요한 업데이트는 그들이 이제 상황을 살펴보고 2주 후에 우리에게 중요한 업데이트를 주겠다는 대답인가?긴장은 견딜 수 없다...프람 (토크) 13:58, 2016년 2월 1일 (UTC)[응답]

@Melamrawy(WMF): 1월 22일 "더 이상의 커뮤니티 반응은 계획할 필요가 없다. 다음 주까지 Gather 팀은 베타 테스트의 성능과 위에서 공유한 정당한 우려를 바탕으로 이 기능에 대한 주요 업데이트를 할 것이다."라고 약속하셨습니다.지금까지 User가 받은 답변은 다음과 같다.TNegrin(WMF)은 "다음 주 결정과 함께 다음 주 공개적으로 공유한다는 취지에서 지금부터 이 분석을 종합하겠다"고 밝혔다.따라서 (여러 번) 중대한 업데이트가 (그리고 지난주에 게시되었어야 했다고 선언하고 나서) 그리고 우리의 토론이 동시에 시작된 것은 단순한 우연이었다고 본다("모으는 것은 팀이 어떤 변화가 일어나야 한다는 것을 이해한다는 것을 의미하지만 이것은 디스커시 없이는 앞으로 나아갈 수 없다.on. 당신은 우연히 그 계획에 동조하여 당신의 의견을 올리게 되었다. [...]" 지금 우리는 우리가 여기서 논의를 한 후에야 분석이 시작되었으며, 2주 후에 결정이 내려질 것이라고 진술하고 있다.이 불일치와 당신이 여기 처음 진술에서 언급했던 "주요 업데이트"에 대해 설명해 주시겠습니까?프람 (토크) 08:09, 2016년 2월 3일 (UTC)[응답]

이것이 어떻게 중요한지 아직도 모르겠다, 사용자:TNegrin(WMF).RFC 아래에서는 그런 공감대가 형성되기 시작한다.위키피디아는 그것이 비활성화된 것을 원한다.나는 이 모든 연장이 선의로 만들어진다는 것을 이해하지만, 그 선의의 믿음에서는 그것이 지역사회를 있는 그대로 좌절시키는 것으로 간주되지 않았고, 따라서 결과적으로 편집자들이 실제로 떠나게 될 수도 있다(또는 그 연장으로 만들어진 상황의 결과로 새로운 편집자들이 떠나게 될 수도 있다 - 내가 c를 삭제하면 이해한다.Olilection, 흔적도 없이 영원히 사라졌는데, 새로운 사용자에게는 어떻게 보이는가?그들은 무언가를 만들었고 그들은 그것이 어디로 갔는지 알지 못했으며 삭제하는 관리자 외에는 아무도 알지 못한다.내가 이해할 수 없는 것은 왜 이러한 '특징'이 살아있는 위키에서 활성화되어야 하는지, 그리고 무엇보다도 먼저 지역사회의 합의 없이 활성화되어야 하는지에 대한 것이다.테스트 위키피디아에서 먼저 이 기능을 활성화할 수 없고, 초기에 나타나지 않는 문제(삭제?)를 제거하기 위해 철저히 테스트하고 토론할 수 없으며, 위키에서 온라인으로 가져와 로컬 정책(NCFF, WP:NOT)과 어떻게 연계되는지, 그리고 어떻게 해결할 수 있는지(아마도 더 많은 코드 변경)에 대해 논의할 수 있을까?그리고 어쩌면 특정한 '특징'은 위키/어느 위키에 적합하지 않을 수도 있고, 모든 발전은 선의로라도 완전한 시간 낭비일 수도 있다.이러한 생각들이 지역 사회와 제대로 논의된 적이 있는가?

이 모든 특징들을 위해, WMF는 계속해서 성공한다.아래의 RFC에 따르면(나는 거기서 (WP:SWOW에 따라) RFC가 '불능 수집' 합의로서 닫힐 가능성이 높다는 것을 고려하기 위해) RFC가 이에 대해 선의의 태도를 보이는 것이 어떻겠으며, RFC가 소진되기 전에 이를 무력화시키는 것이 어떻겠으며, (적어도) 문제를 해결하고, 어떤 기능을 활성화하기 전에 작업 테스트 버전을 보여주고 RFC를 시작하는 것이 좋다.커뮤니티는 그것이 위키에 적합하다고 생각하고, 그들 스스로 적절하게 작동하며, 그것이 그들의 지역 정책과 가이드라인에 맞는지, 그들이 그것을 원하는지 여부를 생각한다.또는 더 나은 방법 - 먼저 커뮤니티가 이러한 것들을 개발하기 전에 원하는지 고려하십시오. --Dirk Beetstra 08:46, 2016년 2월 3일 (UTC)[응답]

무엇보다도, 위로부터의 정당한 피드백을 인정하고자 한다. 이 문제에 대한 재단의 관심을 끌기 위해 RFC가 필요하지 않았어야 했다. 분명히 이 기능을 통신 없이 오랫동안 베타 상태로 두는 것은 옳지 않았다.내가 전에 말했듯이, 나는 영어 WP와 수집의 가치에 관한 이슈들을 완전히 인정한다; 그것들은 확실히 문제가 있다.투명하게 하기 위해 독서팀 내부에 보다 사려 깊고 협력적인 문화를 구축하고 있으며, Gather를 시작할 때 이러한 가치관이 더 필요했던 것처럼 나는 우리가 모든 이슈에 이런 방식으로 접근하도록 하고 싶다.시간과 노력이 들지만 생산량이 더 좋고 보람 있을 것 같아.TNegrin (WMF) (토크) 17:32, 2016년 2월 3일 (UTC)[응답]

@Melamrawy (WMF)와 TNegrin (WMF): 다 잘 되고 좋지만, 그 모호한 기업 PR이 뭔가 구체적인 것으로 말하는 것을 구분해 줄 수 있겠나?예를 들어, RfC의 예상 결과를 준수할 것을 약속하시겠습니까?그렇지 않다면 당장 부인하는 편이 낫다."생각 많고 협력적인 문화"를 원한다고 말하는 것은 그것이 가시적인 결과로 이어지지 않는다면 아무 의미가 없다.지금까지 WMF가 우리에게 이 문제에 대해 말한 모든 것은 모호한 상투로 이 문제를 긴 풀밭으로 밀어넣는 것이었다.베스넛 (대화) 17:46, 2016년 2월 3일 (UTC)[응답]

• 여기서 우리는 서로에게 조금 더 친절하게 대할 수 있을 것 같아.이것은 새로운 문제가 아니다; 나는 몇 년 동안 "최소 생산 위키 표준을 충족하지 못한다"는 싸움을 연장 없이 해오고 있다.이번에는 태도 변화가 감지된다. 우리는 리딩의 수장이 이 대화에 관여하고 있다. 이는 SNAFU가 대규모 반란을 일으킬 때까지의 어떤 이전 논의보다 훨씬 높은 수준이다.내가 주목하듯이, 나는 이 토론을 몇 번이고 반복해서 해왔지만, 그 일이 일어날 때마다, 그것은 WMF 내의 다른 개발 사일로와 함께 해 왔다. 내가 토비의 말을 듣고 있는 것은 그가 (그리고 바라건대 다른 사람들이) 이것이 더 보편적인 문제이며, 실제로 연장에만 국한된 문제가 아니라고 생각하고 있다는 것이다.언제 그리고 어떻게 큐레이션/코레이션/코레이션이 새로운 확장에 통합될 것인지에 대한 이해를 돕기 위해 wiki에서 장애물을 발견하기 전에*나는 마침내 스스로 자리에 앉아 시험위키에서 벗어나기 전에 식별된 문제들과 그 문제들이 어떻게 다뤄져야 하는지를 쓰기 시작했으며, 약간의 추가 검토와 완충을 거친 후 널리 공유할 것이다.(진짜 궁금하다면, 내 기여도를 보더라도 내 사용자 공간에 있다.)WMF 직원들은 수년간 그들의 업무 구조와 리더십에 의해 비견할 정도로 장애를 받아왔으며, 우리는 이러한 패턴의 변화를 활용해야 한다.개발자, CL, 프로젝트 매니저들이 우리 프로젝트의 일상적이고 일상적인 활동을 처리할 수 없는 *또 다른* 제품을 보는 것처럼 그들의 작업 제품이 꽝꽝하는 것을 보는 것은 더 이상 즐겁지 않다.우리 모두를 위해 그것을 더 좋게 만들도록 노력하자 - 그들이 생각해낸 것들 중 일부는 정말 유용하고, 일부는 다시 생각해 볼 필요가 있더라도 잠재력이 있다; 모든 것이 쓰레기인 것은 아니다.리스크 담당자 (대화) 2016년 2월 3일 19:31, (UTC)[응답]
  • 그렇긴 하지만, 다시 생각하고 더 나은 접근법이 당분간 이 연장을 없애기 위한 기본적인 질문들이 외면당하는 것을 의미하지는 않는다.그리고 나는 이 더 나은 접근과 소통이 그들의 약속에 무슨 일이 일어났는지 아직도 설명해야 하는 지역사회 연락 담당자에게도 전달되기를 바란다.프람 (토크) 19:42, 2016년 2월 3일 (UTC)[응답]
    • 괜찮습니다, 프람.지금까지 거론된 요점 중 하나는 '창작된 '집합'을 어떻게 해야 하는가'이다.그 문제를 해결하는 방법에 대해 제안해 주시겠습니까?어떤 것들은 어떤 일이 일어나든 다양한 이유로 삭제되어야 한다고 말하는 것이 타당하지만, 어떤 것들은 사용자들이 자신에게 유용할 무언가를 창조하려는 착하고 선의의 시도인 것처럼 보인다.우리가 그들을 어떻게 도울까?아마도 우리는 이 문제를 브레인스토밍할 수 있을 것이고, 아마도 더 자주 사용하는 확장 사용자 중 한 명 이상을 그것에 참여하도록 초대할 수 있을 것이다.리스크 담당자 (대화) 2016년 2월 3일 (UTC) 20:21, 응답
      • 모든 목록을 원래 목록을 구성하는 모든 페이지(목록과 동일한 하위 페이지 제목 포함)에 대한 링크가 있는 해당 사용자의 사용자 공간에 있는 일반 하위 페이지로 만드십시오.WMF는 아마도 이러한 수집 페이지 아래의 데이터베이스에 더 쉽게 접근할 수 있기 때문에 이를 위해 봇을 작성할 수 있을 것이다.한편(즉, 위와 같은 것이 실현 가능할 때까지), 더 이상 페이지를 추가하거나 변경할 수 없지만, 봇 변환이 생성될 때까지 기존 페이지는 남아 있다는 의미에서 채집을 비활성화할 수 있다.물론 빈 페이지(기사 없는 목록)는 즉시 삭제할 수 있다.그냥 여기서 브레인스토밍을 하는 건데, 이런 게 실현 가능해야 할 것 같아.프람 (대화)20:34, 2016년 2월 3일 (UTC)[응답]
        • 나는 그것이 현실적이지 않다고 생각한다.그냥 무력화하자, 이 모든 것들이 이제 모든 사람들의 시간을 낭비했어.몇 백 시간을 더 낭비하지 말자.—DJ (대화 • 기여) 22:43, 2016년 2월 3일 (UTC)[응답]
          • 아, 난 그 해결책에는 문제가 없어, 다만 WMF가 지금까지 만들어진 것들을 어떻게든 지켜야 한다고 확신한다면, 위는 그들이 할 수 있는 가능한 해결책이야.어떤 경우든, 더 이상 엔위키 시간을 이것에 써서는 안 된다, 그것은 우리들 대부분이 동의하는 것이다.프람 (토크) 08:12, 2016년 2월 4일 (UTC)[응답]
        • 확장자가 비활성화되어 있고 페이지가 삭제된다는 것을 알려주는 봇 메시지가 수집 페이지 작성자에게 전달되는 것은 아닐까?원하는 경우 선택한 페이지를 사용자 공간에 있는 다른 페이지로 "복사"할 수 있도록 며칠 전에 알림을 보내시겠습니까?리스크 담당자 (대화) 2016년 2월 4일 (UTC) 19:34 [응답]
        • 우리는 사용자 페이지에 컬렉션을 다운로드하는 봇을 작성했다. 그것은 좋은 해결책이고 컬렉션에 정보를 보관한다.Gather 크리에이터에게 보내는 봇 메시지는 좋은 생각이고 우리는 다음 주에 그것을 검토할 것이다.생각해줘서 고마워TNegrin (WMF) (토크) 23:12, 2016년 2월 5일 (UTC)[응답]
• 고마워 Risker - 그 문서는 매우 유용하다.나는 토크 페이지에 댓글을 달았고 이것이 위키피디아와 다른 커뮤니티의 일종의 문화적 입문서가 될 수 있을 것 같은 느낌이 든다.그것은 분명히 내가 재단에 근무하기 시작했을 때 혜택을 받았을 거야!TNegrin (WMF) (토크) 23:12, 2016년 2월 5일 (UTC)[응답]

WMF 논의의 근거로 삼고 있는 요약문서를 여기에 올렸다.문서가 고급이지만, 나는 최소한 커뮤니티의 관심사를 요약하고 내가 할 수 있는 한 객관적인 방법으로 일부 사용 지표를 제공하려고 노력했다.확실히 하기 위해, 나는 RFC 과정에 의해 할당된 시간을 가지고 재단 내에서 이러한 이슈들에 대한 구조적인 논의를 하기 위해 노력하고 있다.리딩팀은 2월 6일(화요일)에 토론회를 가지는데 최대한 빨리 결과를 전달하겠다.TNegrin (WMF) (토크) 23:12, 2016년 2월 5일 (UTC)[응답]

적어도 개선점 (BTW는 2월 9일을 의미하는가?)내 생각에 그것은 우리를 "우리가 볼 것"까지 데려다 주는 것 같다.©제니 (대화) 17:59, 2016년 2월 7일 (UTC)[응답]

네, 9일.수정해줘서 고마워.TNegrin (WMF) (토크) 23:03, 2016년 2월 7일 (UTC)[응답]

잠깐 언급하자면, 우리는 회의를 했지만 내가 예상했던 것보다 분석이 더 오래 걸렸다.최대한 빨리 결과를 올리겠다.늦어진 것에 대해 사과한다.TNegrin (WMF) (토크) 02:13, 2016년 2월 12일 (UTC)[응답]

불길하다.©Geni (대화) 05:46, 2016년 2월 12일 (UTC)[응답]

@TNegrin (WMF): 소식 없나?회의가 끝난 지 거의 일주일이 지났고 RfC는 12일도 채 남지 않았다.베스넛 (대화) 23:37, 2016년 2월 15일 (UTC)[응답]

거의 일주일이요?Patience, my young padawan, I'm still waiting for a follow-up to things like "Anyway, WMF update will still be announced by the end of this week --Melamrawy (WMF) (talk) 17:27, 26 January 2016 (UTC)" and all the other Melamrawy promises. ("I thought we are waiting until our further announcement of next steps?:. 비활성화를 지원하는 문제가 실제로 해결된다면? --멜라므라이(WMF) (토크) 16:31, 2016년 1월 26일 (UTC)"그 이후로, 멜라모웨이는 Gather 지도에서 완전히 사라졌지만, 그 이후로 엔위키를 편집했기 때문에, 후속 질문들과 핑들을 알아챘어야 했다.나는 몇 주 전에 어떤 주요 업데이트가 주어질지 아직도 모르겠고, 다른 WMF 사람들의 반응을 보면, 그들도 그런 업데이트가 올 줄은 몰랐던 것 같다.WMF를 지키기 위해 이야기만 꾸며내는 것 같은 공동체 연락원이 무슨 소용이 있겠는가.프람 (토크) 08:02, 2016년 2월 17일 (UTC)[응답]

물론, 멜라므라이의 "내가 지금 하고 있는 일" 이사회를 보면 Gather에 대해 아무것도 모른다.더 이상 이 문제로 바쁜 것 같지 않아, 대신 사용자 설문 조사에 대해 비난을 받고 있어.꽤 멋진 기록을 쌓고 있어!프람 (토크) 08:11, 2016년 2월 17일 (UTC)[응답]

@TNegrin (WMF): 이제 일주일이 지났다.©제니 (대화) 23:40, 2016년 2월 18일 (UTC)[응답]

늦어서 미안해, 일주일이나 지났어.나는 RFC에서 제기된 이슈들을 다루기 위한 제안서를 게시했다.피드백의 가장 좋은 장소는 게시물 자체의 토크 페이지라고 생각한다.이 제안에 대한 당신의 인내심과 배려에 감사한다.TNegrin (WMF) (토크) 06:56, 2016년 2월 19일 (UTC)[응답]

와우, 그 제안은 지역사회에 대한 모욕이야.WMF는 지역사회의 합의에 대해 신경도 안 써, 정말 놀랍다!키호테틱 포테이토 (토크) 08:05, 2016년 2월 19일 (UTC)[응답]

"RFC에서 제기된 문제를 해결하기 위한 제안"을 실제로 작성한 것이 아니라, RfC에서 제기된 문제를 해결하기 위한 단계를 개략적으로 설명하는 로드맵을 3개월 내에 작성하자는 제안서를 작성하셨습니다.그리고 여기서 나는 우리가 이미 RfC의 문제를 해결할 수 있는 중요한 업데이트를 1월 말에 받을 수 있을 것이라고 생각하고 있었다.WMF와 얼마나 자주 소통이 잘 안되는지 이상하다. 어쨌든 나는 그곳의 토크 페이지에서 그 제안에 대한 나의 논평과 거절을 했다.프람 (토크) 08:15, 2016년 2월 19일 (UTC)[응답]

마찬가지로.이것은 더 많은 지연 전술과 체면을 구하려는 시도의 흔적이 있다.베스넛 (대화) 08:27, 2016년 2월 19일 (UTC)[응답]

왜 우리가 그 제안서에서 Gather 컬렉션을 비공개적으로 만들자고 제안하는지에 대해 좀 더 명확하게 설명해주었다.나는 저쪽에서 논의를 계속할 것이다.TNegrin (WMF) (토크) 16:46, 2016년 2월 19일 (UTC)[응답]

@TNegrin (WMF): "모으는 컬렉션을 비공개로 하되, 4월 전에는 안 된다"는 것이 "모으는 것을 지금 비활성화시켜 달라"는 잘 합리화된 요구에 대한 정말 납득할 만한 답변이라고 생각하는가?—쿠스마 (t·c) 17:01, 2016년 2월 19일 (UTC)[응답]

@TNegrin (WMF): 수집 컬렉션을 사적인 것으로 만드는 대신 단순히 사용자 정의만 하는 이유라도?당신은 5일 WMF가 RfC를 회피하지 않고 따를 수 있도록 하는 것을 가능하게 하면서 "우리는 컬렉션을 사용자 페이지에 다운로드하는 좋은 솔루션이며 컬렉션에 정보를 보관하는 봇을 작성했다"고 주장했다.나는 "우리는 무슨 일이 있어도 수집을 무력화시키고 싶지 않다"는 것 외에 위의 봇 제안 대신 새로운 제안을 할 이유가 없다고 본다.그렇게 생각하지 않으세요? 어느 정도 신용을 얻고 엔위키에 대한 존경을 표하기 위해서는 RfC를 따르는 것이 아마도 몇 달 안에, 운이 좋다면 RfC가 원하는 것을 할 수 있는, 그러나 또 한편으로는 아닐 수도 있는, 희망적인 제안을 하는 것보다 더 좋은 출발이 될 것이라고 생각하십니까?지금은 그렇게 보여서 그래.신뢰할 수 없는 커뮤니티 연락 담당자와 결합하여, RfC와 귀하의 제안서(그것이 그들의 잘못인지 또는 WMF의 잘못인지 여기서부터 명확하지 않은지)의 차이를 모르는 Phabricator의 개발자들과 WMF를 다루는 데 있어서 지연과 지연만 있을 뿐(공정 사용 이미지 제거에는 얼마나 오래 걸리는지)그런데, 그들이 허락되지 않는 곳에서 온 것?), 너는 여기에 어떤 다리도 건설하지 않을 것이다.프람 (토크) 13:28, 2016년 2월 20일 (UTC)[응답]

위의 것 외에도, Gather는 이제 우리 영역 밖에서 호스팅되는 소프트웨어에 의해 중복으로 만들어졌고 지역사회에 어떠한 중압도 부과하지 않는다.MER-C 04:30, 2016년 2월 8일 (UTC)[응답]

범주:템플리트 포함 크기가 콘텐츠 공간에 의해 분할된 페이지

이 카테고리는 이제 (나 같은 편집자가) 개선할 수 없는 많은 Userspace 페이지를 나열한다.분석기는 내용 공간(또는 기사 공간)에 의해 목록을 두 범주로 나눌 것을 제안한다.-DePiep (대화) 20:01, 2016년 1월 25일 (UTC)[응답]

그러한 파서가 기술적으로 가능한가?미디어위키에게 이렇게 할 수 있을지 모르겠다.사후 확장-템플릿-폐쇄 범주, 일부 MediaWiki 네임스페이스 페이지에는 Wiki 텍스트가 포함될 수 없으며, 이 페이지에는 Wiki 텍스트가 포함될 가능성이 있어 보인다.2016년 1월 27일(UTC) odושווodOd Mishehu 08:51, replyreply[응답]

나는 그것에 대해 아는 것이 없지만, 그 카테고리는 그것이 "미디어위키 소프트웨어에 의해 자동으로 입력된다"고 말하고 있어, 그 소프트웨어는 두 가지 카테고리를 생산하기 위해 업그레이드될 수 있다. 하나는 기사용이고 다른 하나는 모든 것을 위한 것이다.반면 카테고리 견적이 정확하다면 832페이지가 들어 있다고 돼 있어 봇이 모든 페이지를 나열하고 메인 스페이스 링크만 포함된 페이지를 만드는 것은 상당히 간단하다.그것은 일주일에 한 번 또는 하루에 한 번 할 수 있다.조누니크 (대화) 02:43, 2016년 1월 31일 (UTC)[응답]

MediaWiki 소프트웨어를 변경하려면 WP:를 참조하십시오.BUGS. דדווodododododododododווMishehu 22:12, 2016년 1월 31일 (UTC)[응답]

예, 조누니크에게. -DePiep (대화) 22:35, 2016년 2월 2일 (UTC)[응답]

@DePiep: 나는 cat talk에 목록을 넣었고, 새로운 목록을 생성하는 데 사용할 수 있는 API 링크를 넣었다.조누니크 (대화) 08:55, 2016년 2월 3일 (UTC)[응답]

• 내 생각에 이것은 정확히 해서는 안 되는 일이다.이 범주는 비워야지, 더 편하게 만들 수 없다.나는 카테고리 토크 페이지에서 몇 가지 통계를 제공했다.주요 사실은 823쪽 중 411쪽이 위키백과에 속해 있다는 것이다.WikiProject_Spam/LinkReports/xxx.대표적인 페이지는 위키백과:WikiProject_Spam/LinkReports/adland.tv.COIBot에 의해 2011년 7월 10일 13:18, 13:10에 생성되어 수정되었다.이 날짜부터 수정한 적이 없음.아무도 이 페이지를 사용하고 있지 않다(http://stats.grok.se/en/latest90/Wikipedia:WikiProject_Spam/LinkReports/adland.tv) 참조).그리고 이것이 아무도 그런 말을 하지 않은 이유일 것이다.

1. 2011-06-15 03:09:48(UTC): 사용자 68.90.23.27 t • c • dc • ef • ef • b • b; (12) 어린이 TV의 Smile of a Child TV(토크 히스토리 링크 감시 로그 편집) (1911!top) - 링크: adland.tv/commercials/oreo-chocolate-creme-mommm-2002-030-usa (R/X^meta/L- 제거)
   Other links: www.smileofachildtv.org/watch/schedule_weekview.php (12, 7, 1, 1- R/X/L) www.youtube.com/watch?v=AcJkkolEUws (12, -1, X, X- R/X/L) adland.tv/commercials/stayfree-maxi-aisle-2004-030-usa (12, 104, 4, 1- R/X/L) www.youtube.com/watch?v=S24kVjBGC8M (12, -1, X, X- R/X/L) www.youtube.com/watch?v=Z1YDj4GyGV8, (12, -1, X, X- R/X/L)www.youtube.com/watch?v=2XwFFYdSu3w (12, -1, X, X- R/X/L) www.youtube.com/watch?v=nGQT5GX6HhY&feature=related (12, -1, X, X- R/X/L) www.youtube.com/watch?v=kv3bMgs_OxM (12, -1, X, X- R/X/L) adland.tv/commercials/enbrel-en-2006-60-usa (12, 104, 4, 1- R/X/L) adland.tv/commercials/depend-road-trip-2003-030-usa (12, 104, 4, 1- R/X/L)adland.tv/commercials/oreo-chocolate-creme-mommm-2002-030-usa (12, 104, 4, 1- R/X/L) www.bananascomedy.com (12, 8, 1, 1- R/X/L)

페이지 끝에 표시되지 않음.Pldx1 (대화) 17:06, 2016년 2월 10일 (UTC)[응답]

청소하는 게 좋을 거야.몇 번 해 보고 모듈을 만들었는데 쉽지 않아.다음 사항은 어떠세요?사용자:Rich Farmbrough/Talk Archive Mega2(Rich Farmbrough) 및 사용자:리겔2222/모래박스(리겔22222)조누니크 (대화) 00:52, 2016년 2월 11일 (UTC)[응답]

나도 "몇 개"를 했다. (사용자 최적화 포함:COIBot/EditSummary.)

다음 코드를 사용하면 원하는 효과를 얻을 수 있다.{{Namespace Greek}}해당 MediaWiki 오류 메시지 페이지의 텍스트에서.파서가 템플릿 확장을 포기했을 때쯤에는 코드 전체를 복제해야 한다.

나는 봇으로 만들어진 많은 것들이 결코 사용되지 않는다는 것에 동의한다.

최상의 선택:Rich Farmbrough, 01:32, 2016년 2월 11일 (UTC)
[답글]

나는 네가 고양이 토크에서 한 말에서 많은 일을 한 것을 알아챘어.나는 그것이 내가 불평하는 것처럼 보이지 않았기를 바란다. 내가 위의 두 가지 예를 언급한 이유는 그들이 그 범주를 청소하려는 탐구의 까다로운 사회성을 보여주기 때문이다.조누니크 (대화) 01:53, 2016년 2월 11일 (UTC)[응답]

그렇다. 그러나 많은 사용자들은 이미 떠났고, 그들의 페이지는 합법적이고 거리낌 없이 순응할 수 있다.내 아카이브 페이지는 어차피 재구축이 필요하지만, 현재 크기로 한정된 이유가 전폐 제한 때문이었음을 주목하는 것은 흥미롭기 때문에, 많은 템플릿들이 크기가 커진 것 같다.

나는 우리가 큰 문제를 다룰 수 있다고 확신해, 그것은 실제로 시간이 많이 걸리는 작은 문제들이 효과가 있다고 생각해.최상의 선택:리치 팜브루, 2016년 2월 11일 (UTC) 15:56.
[답글]

여기서 근본적인 문제는 MediaWiki가 다음과 같다.포스트-확장-템플릿-폐쇄-카테고리(post-expand-template-inclusion-category)는 위키 텍스트의 자유 형식이 아니라 범주의 이름이다.그럼에도 불구하고 나는 그것이 아마 해결될 수 있다고 생각한다.최상의 선택:Rich Farmbrough, 01:08, 2016년 2월 14일 (UTC)
[답글]

어디인지는 모르겠지만, 카테고리 이름만 추가되는 그런 종류의 MediaWiki 페이지에서 네임스페이스 탐지기를 본 적이 있는 것 같아.그러니까, 기술적으로 가능해야 한다. --Edgars2007(대화/출연) 03:38, 2016년 2월 14일 (UTC)[응답]

MediaWiki: 이후 소프트웨어 변경이 필요할 수 있음:사후 확장-템플릿-폐쇄-범주는 [Category: part and close ]가 아닌 범주 이름만 포함한다.

그러나 ]] 이전에 발생하기 때문에 분류 코드를 광고하는 것이 가능할 수 있다.내가 찾을 수 없었던 암호에 따라 달라지겠지

정말 테스트위키에서 시험해봐야겠다.

최상의 선택:Rich Farmbrough, 19:14, 2016년 2월 16일 (19:14, 16)
[답글]

단지 명확히 하기 위해서, 추적 카테고리는 위키텍스트를 가질 수 있도록 허용된다.예를 들어, 손상된 파일 범주는 이렇게 한다.최상의 지원은 네임스페이스에만 의존하는 경우(페이지 이름에 따라 다르지만 특수:추적 범주에 나타나지 않는 경우)이다.또한 해당 페이지의 변경 내용은 전파 속도가 다소 느리다는 점을 유념하십시오. 해당 페이지가 null로 편집될 때만 범주가 업데이트됩니다.바월프 (대화) 15:33, 2016년 2월 20일 (UTC)[응답]

아까는 이 토론 내용을 몰랐는데, 한도를 넘는 페이지에 대해 핑핑을 받을 때도 똑같이 제안했다.문제의 페이지들에 대해, 나는 이 페이지들이 그 한계를 초과하고 아무도 하지 않는다는 것을 신경 쓰지 않을 수 없었다. 만약 정보를 읽을 필요가 있다면, 그것을 해결하는 방법들이 있다.그렇지 않으면, 이 페이지들이 그 안에 있는 다른 페이지들을 모호하게 한다는 것 외에는 이 범주에서 이 페이지들을 빼낼 이유가 없다.

이 문제는 콘텐츠 네임스페이스의 문제일 뿐이며, 대화 페이지(및 아카이브)의 성가신 문제다.나머지 페이지는 반드시 읽기 쉽도록 되어 있지 않기 때문에 이 카테고리에서 빼낼 필요가 없다.네임스페이스로 나누면 관리가 쉬워진다. --Dirk Beetstra 03:23, 2016년 2월 18일 (UTC)[응답]

WP를 다루는 Bot:LISTGAP 약 10만 건의 기사

행사가 시작되었다.(iii)

리스트갭 접근성을 해결하기 위한 봇 승인 요청이 시행을 완료하고 생방송 준비를 하고 있다.그 범위가 넓기 때문에, 추가적인 커뮤니티 코멘트가 요청되고 있다.요청 페이지에 질문 또는 의견을 입력하십시오.봇 승인 그룹으로부터 감사, — xaosflux 20:34, 2016년 2월 18일 (UTC)[응답]

이의 제기 또는 추가 후속 조치를 금지하는 경우 - 2월 26일 Xaosflux 16:26, 2016년 2월 21일(UTC)[응답]

요약 실행 취소

편집 취소를 위한 편집 요약을 변경할 것을 제안한다.

수정기호 $1x2(대화) 미실행

로

수정기호 $1x2 미실행(계속)

Wikimarkup:

보낸 사람

$1 by [특수:기부금/2달러] ([사용자 대화:2달러 대화])

로

수정 취소 [[특수:$1$1] by [사용자 대화:$2]([특별]:기여금/$2 기여금]])

아이스블록 (토크) 2016년 2월 16일 (UTC) 19:46[응답]

• 나는 최근에 여기서 이런 말을 많이 하는 것 같지만, 다시 한 번 말하겠다: 무언가를 제안할 때, 이것이 왜 개선되어야 하는지를 설명하는 것이 도움이 된다.비블브록스 (대화) 20:43, 2016년 2월 16일 (UTC)[응답]
• 반대 diff 링크를 추가하면 너무 적은 이득을 얻기 위해 실행 취소를 설명하는 데 사용할 수 있는 공간이 더 줄어들 수 있다(MediaWiki talk:이에 대한 논의를 위한 실행 취소 요약)과 기여/대화 순서를 수정하면 이전 실행 취소 링크가 여전히 이전 편집 요약을 사용하므로 혼동이 발생할 수 있다.세나륨 (대화) 21:20, 2016년 2월 16일 (UTC)[응답]
• 반대 – 익명 사용자가 대화 페이지에 댓글을 달면 해당 사용자의 IP 주소가 기고문과 연결된다.자동 실행 취소 요약이 그걸 반영한다고 생각해.나는 또한 "talk"라는 단어의 철자를 쓰는 것에서도 이점을 볼 수 있다. 그것은 종종 실행 취소 기능이 편집 전쟁에서 사용되기 때문에 토론을 장려하기 때문이다.마지막으로, 비블브록스가 언급했듯이, 제안자는 왜 이 변화가 개선인지에 대한 논쟁을 아직 진전시키지 못했다.Mz7 (대화) 02:53, 2016년 2월 17일 (UTC)[응답]
• 지원 링크 diff, 사용자 링크의 변경 반대.현재 링크는 동일한 장소에 연결되며, 단지 어떤 링크가 사용자 이름과 함께 나오는지, 괄호 안에 어떤 링크가 들어 있는지에 대한 질문일 뿐이며, 명시적인 "Talk" 링크는 사용자가 문제를 토론하도록 장려하는 경향이 있다.반면에, 제안된 대로 디프 링크가 실제로 작동한다면, 그것은 사용자가 요약을 포함한 문제의 원래 편집을 볼 수 있게 해주기 때문에 좋은 생각이다.사용자 링크에만 코멘트가 적용되는 세나리움, Mz7은 디프 링크에 대한 의견 표명을 원할 수 있다.עודדוו Od Mishehu 06:03, 2016년 2월 17일 (UTC)[응답]

대다수의 언도들은 완전히 되돌아가기 때문에, 당신은 언도 자체의 번영을 보는 것 만으로도 무엇이 되돌아왔는지 쉽게 알 수 있다.나는 또한 디프프 링크를 추가하면 좀 더 설명적인 편집 요약을 쓸 수 있는 공간이 불필요하게 줄어들 것이라는 세나륨의 의견에 동의한다.Mz7 (대화) 16:43, 2016년 2월 17일 (UTC)[응답]

• 장단점 diff 링크가 주어지면 편집이 정확한 실행 취소인지, 아니면 교활한 파괴행위 변화를 포함하고 있는지 확인하는 것이 더 쉬워질 수 있다.일부 경우, 실행 취소 편집자는 기여를 삭제하고 대화 링크를 삭제하여 요약할 수 있는 공간을 더 만들 수 있다. 왜냐하면 이러한 링크는 디프 페이지의 맨 위에 있기 때문이다.그러나 9자리 구식 번호를 사용하면 디프 링크는 편집 요약을 27자 증가시킨다(토크 및 기여 링크를 교환하지 않은 경우).10자리 올드드 넘버로 28자 증가 등디프프링크는 별개로 토크와 기여 링크가 스와핑 시 더 많은 캐릭터를 차지하기 때문에 링크 순서를 변경하기보다는 "사서(토크)에 의한 개정 미실시"로 유지하는 것이 최선일 것이다."라이브러리 관리자에 의한 수정기호 1 미실행".9자 사용자 이름의 경우 기여도와 토크 링크가 76자를 차지한다.그래서 실행 취소 편집자가 기고 및 토크 링크를 삭제하고 디프 링크가 존재하여 보관하면 48자의 추가 공간이 생기게 되며, 언급된 바와 같이 기고 및 토크 페이지는 디프 페이지에서 링크된다.아이스블록 (토크) 2016년 2월 21일 17:14 (UTC)[응답]

모든 "섹션 템플릿"을 동일한 크기로 만들기

안녕, 나는 이 제안서를 넣을 수 있는 장소가 맞길 바라.섹션에 대한 템플릿이 다음과 같은 방법에 대한 지침을 만들고 싶다.{{cleanup section}}그리고{{refimprove section}}배치되어 있다현재 그 중에는 긴 배너도 있고 다른 것은 상자 모양의 작은 템플릿도 있다.시간이 너무 오래 걸려 섹션 템플릿을 모두 찾을 수 없었지만, 다음 사항을 간신히 찾아냈다.

물론 전부 다 그런 건 아니에요. 왜냐하면 전에 말씀드렸듯이 다 찾는데 시간이 너무 오래 걸리기 때문이지요.내가 제안하는 것은 그들 모두가 배너스타일을 할 수 있도록 정해진 가이드라인을 갖추자는 것인데, 내가 본 바로는, 이러한 템플릿에 대한 접근법이 더 보편화되었다.정리 섹션 템플릿을 편집하고 변경하려고 했는데 되돌아가서 왔어.무정부상태 (워크톡) 10:17, 2016년 2월 13일 (UTC)[응답]

@아나체테:당신은 아마 이 리스트에서 그들 모두를 찾을 것이다.עודדוו od Od Mishehu 22:13, 2016년 2월 15일 (UTC)[응답]

지원

• 나는 기준과 연속성을 좋아하는데, 특히 GUI에서는 Fredgandt 00:56, 2016년 2월 14일 (UTC)[응답]
• 이 일을 맡을 정도로 미친 사람이 있다면 지원하라. --키요시엔도 (토크) 17:44, 2016년 2월 21일 (UTC)[응답하라]
• 지원: 일관성이 중요하다.{{Nihiltres talk edits}}}{18:54, 2016년 2월 21일 (UTC)[응답]

반대하다

• 쓸모없는 WP:CREP.비블브록스 (대화) 20:45, 2016년 2월 16일 (UTC)[응답]

  @Beeblebrox: 이 제안은 본질적으로 비호화(depression)에 관한 것이므로, 특징(the feature)을 제거하는 것에 관한 것이다.small파라미터 {{ambox}}), 어떻게 크리프라고 할 수 있을까?{{Nihiltres talk edits}}}{18:54, 2016년 2월 21일 (UTC)[응답]

차단 대신 문제가 있는 IP를 피어 검토 대상으로 지정

소규모 프로젝트를 위한 홍보/조직 강화

연결고리가 많지 않은 다소 평범한 편집자로서 작은 프로젝트에서 협업할 편집자를 몇 명 찾으려고 하는 것은 매우 어려운 일이다.나는 단지 Hypericum 기사를 만드는 데 시간이 많이 걸리기 때문에, Hypericum 기사를 쓰는 데 도움을 주고 싶었던 것을 내놓을 방법을 찾고 싶었다.위키프로젝트나 태스크포스(TF)는 규모가 너무 클 것 같아 다른 대안을 살펴봤다.유일하게 찾은 것은 '토크 페이지 조정'이었다.내가 여기서 했음에도 불구하고, 아무도 실제로 불명확한 기사의 토크 페이지를 보고 거기서 뭔가를 읽지는 않을 것이기 때문에, 이것은 정말 쓸모없는 것이다.

프로포지션

약간의 홍보를 받을 수 있고 정상적인 것이 될 수 있는 인정받는 미니 태스크 포스를 만드는 것이다.이것은 프로젝트 페이지가 있지만 위키프로젝트나 태스크포스에 비해 유지관리 요구사항 등은 훨씬 적다.그것은 홍보를 찾을 수 있도록 You Can Help 페이지에 배치될 수 있다.

도움이 되는 이유

이것은 편집자들이 비공식적인 방법으로 협력하도록 격려할 것이다. 그러나 그렇게 비공식적이지는 않아서 진정한 협업이 매우 어렵다.부전공, 특히 일반종과 종은 보다 효율적이고 집중적인 기사를 제공할 수 있었다.또한, 새로운 편집자는 단지 주제에 대한 도움을 찾기 위해 모든 곳을 뒤지는 것을 원하지 않을 것이다; 이것은 도움이 될 것이다.

프리츠만2002 13:40, 2016년 2월 18일 (UTC)[응답]

위키프로젝트 플랜트 내에서 이것을 처리할 수 없는 이유가 있는가?로저 (Dodger67) (토크) 08:42, 2016년 2월 19일 (UTC)[응답]

위키프로젝트 플랜트가 이를 처리하지 못할 이유는 없지만 4일 전 그곳에 협업 요청을 했고 아직 답변을 받지 못했다.식물 프로젝트는 아마도 더 활동적인 프로젝트 중 하나일 것이고, 내가 하고 싶은 일은 그다지 중요하지 않기 때문에, 그곳에서는 견인력을 받지 못한다.이 규모의 프로젝트가 표준이 되는 곳이 있다면, 그들은 더 많은 인정을 받고 실제로 응답을 받을 것이다.프리츠만2002 13:55, 2016년 2월 22일 (UTC)[응답]

여기서 아무도 대답하지 않는다면 찻집, 토크 페이지, 위키프로젝트 플랜트 외에 내가 갈 수 있는 곳이 또 있을까?프리츠만2002 19:03, 2016년 2월 24일 (UTC)[응답]

플랫폼에 TipWiki 구현

TipWiki는 연결된 기사의 기본 툴팁을 해당 기사의 콘텐츠로 대체하는 크롬 확장판이다.이 작은 특징은 독자들이 링크된 기사로부터 최소한의 컨텍스트(때로는 계속 읽기에 충분하다)를 획득할 수 있는 동시에 현재 페이지에 머물 수 있게 해준다.

연장에 대한 코드는 공개적이며 수정할 수 있다.기본 브라우저 기능을 사용하기 때문에 추가되는 요소가 없다.링크 태그에 "제목" 속성을 다시 쓰기만 하면 된다.또한 비동기식으로 작동하므로 사용자는 이 동작이 발생하는 것을 알아차리지 못한다.

나는 이 확장 뒤에 있는 코드를 위키백과 플랫폼에 구현할 것을 제안한다.툴팁은 일반적으로 버튼이 무엇을 할 것인지 명확하지 않은 사이트의 버튼과 같은 요소에 추가되지 않는 한 유용하지 않다.이 기능은 사용자 경험을 향상시키기 위해 이것을 이용할 것이다.

코드에 대한 링크(크롬 다운로드에 대한 링크도 있음

니코드라카 (대화) 23:29, 2016년 2월 24일 (UTC)[응답]

이것은 약간 mw:호버카드(베타 기능으로 사용 가능) 또는 네비게이션 팝업(가젯으로 사용 가능). --에어랜드(토크) 21:05, 2016년 2월 24일(UTC)[응답]

그것은 확실히 비슷하다.그러나 내가 이것이 더 나은 해결책이라고 믿는 이유는 (다른 사람들은 당신을 매우 좋아한다고 생각한다), 그것은 자바스크립트 팝업의 비대함을 수반하지 않고, 설명은 미미하기 때문이다.내가 본 어떤 솔루션보다 훨씬 미묘하다. 일부 사용자들은 브라우징하는 동안 큰 팝업을 좋아하지 않을 수도 있다.전체 스크립트는 자바스크립트 코드의 22줄로, 사실상 눈에 띄지 않을 것이다.니코드라카 (대화) 22:47, 2016년 2월 24일 (UTC)[응답]

Chrome 확장과는 무관하게 실행될 수 있는가?이것은 기발한 해결책처럼 보인다. 137.122.64.32 (대화) 23:29, 2016년 2월 24일 (UTC)[응답]

아니, 할 수 있어!확장자의 내용을 가져다가 페이지의 대본에 넣기만 하면 된다.자동으로 정보를 검색하고 변경한다.JavaScript를 어떤 이유로 사용하지 않도록 설정하면 원래 제목 속성이 표시되므로 위험이 없다.니코드라카 (대화) 23:10, 2016년 2월 24일 (UTC)[응답]

방금 테스트할 확장자 다운로드.동작이 빠르고 정확함(대부분의 경우) 137.122.64.32 (대화) 23:28, 2016년 2월 24일 (UTC)[응답]

RfC: enwiki에서 수집 사용 안 함

배치

내일 16:00–17:00 UTC로 불능화가 예정되어 있는 것으로 보인다. --에어랜드 (대화) 11:59, 2016년 2월 21일 (UTC)[응답]

나열된 Phabricator 티켓은 "사적으로 만드는" 패치가 있는 티켓이 아니라 확장을 완전히 비활성화하기 위한 티켓이다.이상해 —루 16:31, 2016년 2월 21일 (UTC)[응답]

Chad로부터 커밋에 대한 인용:

RFC에서 압도적인 공감대가 불능화(그리고 그건 아마 변하지 않을 것 같지만) RFC의 폐쇄/요약을 본 적은 없다(그런데, 언제 문을 닫아야 하나?)

그 때까지, 나는 우리가 이것을 월요일의 특별 행사에 넣어야 한다고 생각하지 않는다.

지연될 수도 있을 것 같은데… --에어랜드 (대화) 11시 30분, 2016년 2월 22일 (UTC)[응답하라]

우습게도, 그들은 그러한 확장을 설치하기 전에 지역 사회와 상의할 필요가 전혀 없다고 생각하지만, 그것을 무력화시키려면, 갑자기 그 부조화를 따라야 한다...프람 (토크) 11시 40분, 2016년 2월 22일 (UTC)[응답]

결론에 도달할 수 있을 만큼 더 많은 투입이 있었다고 생각하기 때문에 나는 이것을 끝냈다.—DJ (대화 • 기여) 2016년 2월 22일 (UTC) 12시 57분[응답]

RFC를 닫아줘서 고마워.그리고 원래 코멘트에는 다음과 같이 되어 있다.나는 물건을 배치/배포하기 전에 지역사회의 합의와 RFC를 따르는 것을 좋아한다.나는 그것이 하루 이상 지연된 것으로 보지 않는다. 그래서 아무도 경계를 늦추지 않았다.^데몬^{[omg plz]} 17:06, 2016년 2월 22일 (UTC)[응답]

WMF 리딩팀의 RFC 폐쇄 대응

Gather RFC는 영어 위키백과의 기능을 비활성화하기로 결정하면서 폐쇄되었다.

우리는 3월 1일 미국 태평양 시간으로 이 기능을 비활성화하여 현재 사용자에게 컬렉션 보관 방법에 대한 지침을 통지할 시간을 줄 것이다.

우리는 이 표의 진행 상황을 추적할 것이다.

Gather가 비활성화되면 우리는 이 기능이 어떻게 생겨났는지, 그리고 커뮤니티 피드백이 어떻게 개발되고 관리되었는지에 대한 회고전을 가질 것이다.

이 과정에 참여한 모든 분들께 감사드린다.— TNegrin (WMF) (토크 • 기여) 02:01, 2016년 2월 23일 이전에 추가된 서명되지 않은 의견

감사합니다.프람 (토크) 07:42, 2016년 2월 23일 (UTC)[응답]

Tanx :) 나는 WMF가 지역사회 참여에 더 많은 관심을 기울이는 것을 보게 되어 기쁘다.알제 (대화) 2016년 2월 24일 (UTC) 17:27 [응답]

장애인.T127509에서 관련 문제를 보고하십시오. --Tgr (WMF) (토크) 00:13, 2016년 3월 2일 (UTC)[응답]

위키러브 온 러시아어 위키백과

WikiLove 활성화, 작업 [14]. --忍者ポポププ(토크) 04:39, 2016년 3월 2일(UTC)[응답]

템플릿 검색

나는 이것이 영원한 제안이었다는 것을 알지만, 그 제안들을 찾을 때 상당히 좌절감을 느낀다.{{r}}입력해야 하는 템플릿template:r검색창으로 들어가 더 긴 이름의 템플릿을 검색하는 것은 미친 짓이다.내가 찾지 못한 현존하는 대안이 있을까?

나는 솔직히 찬반 논쟁만 대충 훑어봤다.내가 보기엔T:접두사가 작동하지 않기 때문에 혹시TL:그럴까?검색 상자에 입력된 내용을 단축할 수 있는 모든 것이 가장 도움이 될 것이다.

기사뿐만 아니라 모든 공간을 검색하도록 검색 상자 매개 변수를 설정하는 것에 대한 댓글도 발견했고, 댓글에 기본 설정에 설정이 있다고 했는데 찾을 수 없다.댓글은 2010년 거였으니까 상황이 달라진 것 같아.

아! 검색을 사용자 정의할 수 있는 방법을 찾았어.전혀 직관적이지 않지만 도움이 된다.그래도 "템플릿" 상자를 선택하고 선택한 내용을 기억하도록 선택하면 입력 시r검색창에, 내가 실제로 찾고 있는 것은 리스트의 아래쪽에 있지만, 적어도 첫 페이지에 있다.검색 중pb거의 성공하지 못했어게다가, "Rememember my choice" 박스는 일종의 실패작이다.내가 먼저 돋보기를 눌러 검색 페이지를 열지 않는 한 이후 검색에는 템플릿이 포함되지 않는다.나는 추가 단계가 싫다. 검색 상자가 여러 장소에서 검색해야 한다고 결정했다면, 내가 있는 페이지의 맨 위에 있는 상자에 무언가를 입력하는 것에도 적용되어야 한다.

다른 방법이 없다면 그냥 타이핑하는 것이 가능할까?{{r}}상자안에?

고마워!

—Rangeed 1 VT^alk : 15:02, 2016년 2월 26일 (UTC)[응답]

이것은 이전에 위키백과에서 논의되었다.마을 펌프(제안)/아카이브 127#프리픽스 제안: TP: 템플릿용:다음으로 User:SiBr₄/TemplateSearch.js를 만들었는데, 기본적으로 "{" 및 "TP:"를 "Template:"의 바로 가기로 허용하지만 모든 검색 바로 가기에 대해 구성할 수 있다.네가 원한다면 그걸 설치해도 돼.SiBr₄ (대화) 16:13, 2016년 2월 26일 (UTC)[응답]

나는 토론을 훑어보았지만 이 해결책은 찾지 못했다.정말 고마워!

—Rangeed 1 VT^alk : 17:06, 2016년 2월 26일 (UTC)[응답]

이중 곱슬 브래킷을 사용하려면 commom.js 파일의 이 변경이 효과적임. 사용자:1/commom.js의 범위를 조정하면, 당신은 그런 방법으로 티플렛을 검색할 수 있을 것이다.עודדהododOd Mishehu 06:06, 2016년 3월 2일 (UTC)[응답]

@D'Ranged 1: 자동 HotKey를 사용하여 "Template:"를 입력하는 데 세 번의 키 입력만 하면 된다.자세한 내용은 http://pigsonthewing.org.uk/using-autohotkey-macros-make-typing-life-easier/을 참조하십시오.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 13:06, 2016년 3월 3일 (UTC)[응답]

피그선더윙, 고맙지만 AHK가 집요하지 않은 게 문제야.쓰고 싶을 때마다 스크립트 파일을 다시 로드해야 한다.고통스러운 일이라 거의 버렸는데 답답하다.그것이 작동했을 때 그것은 훌륭한 도구였고 나는 그 문제를 전혀 해결할 수 없을 것 같다.

—Rangeed 1 VT^alk : 06:43, 2016년 3월 4일 (UTC)[응답]

개인 "작업" 목록

내가 반복적으로 원했던 한 가지는 일종의 후속 조치를 위해 페이지에 태그를 붙이는 방법이었다.나는 종종 어떤 작업이 필요한 페이지를 우연히 발견했지만, 그 문제를 즉시 처리할 수 있는 시간이 없었고, 미래를 위해 그것을 기록할 수 있는 좋은 방법은 정말 없다.도구 모음(읽기/편집/히스토리/etc)에 단추를 추가하고 사용자 페이지 끝에 줄을 추가하는 간단한 가젯(아마도 사용자:username/todo), 현재 문서에 대한 링크, 타임스탬프 및 주석을 포함하는 가젯을 만들 것을 제안하고 싶다.(선택사항) 설명은 대화 상자(Twinkle Rollback AGF 및 기타 많은 도구에서 수행되는 방식과 유사함)에서 온다.추가된 라인은 다음과 같이 보일 수 있다.

* [[기사명] 05:01, 2016년 2월 18일 - 일부 의견

항목을 제거하려면 페이지를 편집할 필요가 없도록 "작업관리" 줄에 "삭제" 단추를 생성해야 한다.

가젯이 활성화된 경우 작업관리 목록으로 이동할 수 있는 단추도 함께 사용할 수 있다.르웨셀 (대화) 05:10, 2016년 2월 18일 (UTC)[응답]

사람들은 현재 이것을 수동으로 할 수 있는 {{To} 템플릿을 사용한다.키호테틱 감자 (토크) 10:06, 2016년 2월 18일 (UTC)[응답하라]

@Rwesel:나는 당신이 원하는 기본 사항을 수행하는 간단한 사용자 설명서를 간신히 정리했다.사용자:Evad37/todo.그것은 인터페이스에 링크를 추가하며(위치를 사용자 정의할 수 있음) 클릭 시 사용자 하위 페이지(사용자 정의 가능)를 편집 모드로 연다.위에서 지정한 줄과 같은 줄이 편집 창에 미리 로드되며, 문서 이름이 지정되고~~~~ (저장 시 시간/날짜가 됨).그런 다음 주석을 추가하고 페이지를 저장할 수 있다.분명히 트윙클 스타일의 대화 상자만큼 화려하지는 않지만, 할 일을 수동으로 작성하는 것보다 더 쉬워야 한다. - Evad37[대화] 09:51, 2016년 2월 21일 (UTC)[응답]

@Rwesel:대화 상자에서 주석 선택, 페이지 편집 없이 항목 제거, 목록에 추가할 작업 목록 보기 링크(목록에 추가하기 위한 링크 옆에 있음) 등의 기능을 제공하도록 스크립트를 업데이트했다.- Evad37 [대화] 06:29, 2016년 2월 25일 (UTC)[응답]

@Evad37: 위키리크(실제 생활 등)에서 방금 돌아왔는데, 이걸 설치했어.언뜻 보기에 이것은 내가 바랐던 것과 꼭 같아 보인다.나는 앞으로 며칠 동안 그것을 가지고 놀 것이다.고마워요.르웨셀 (대화) 07:12, 2016년 3월 4일 (UTC)[응답]

@Rwesel:네가 좋아했으면 좋겠어!기능 요청, 제안사항, 기타 피드백이 있으면 내 토크 페이지에서 알려줘. - Evad37 [토크] 01:16, 2016년 3월 5일 (UTC)[응답]

위키백과에 대한 제안된 변경사항

모든 사람은 첫 블록 전에 최소한 한 번의 경고를 받아야 한다.한 가지 유형의 기사에 특정한 행동을 위한 블록인 경우, 그 블록은 다른 유형의 기사에 적용되지 않아야 한다.위키피디아는 제안 페이지를 더 쉽게 찾을 수 있도록 해야 한다. ---- 2601:2C1에 의해 추가된 서명되지 않은 코멘트:C003:EF7A:4C87:C488:5851:C0EA(대화 • 기여) 03:10, 2016년 3월 4일

1) 거의 모든 사람들이 첫 블록 전에 경고를 받는데, 그들이 차단된 사용자의 양말 조각이 아니라면, 또는 그들이 알아야 할 것을 하고 있거나, 그들이 트롤에게만 계정을 만들었음이 명백하다.

2) 프로그램을 짜고 적용하기에 너무 번거롭다.우리는 주제 금지를 가지고 있는데, 그것은 비슷하지만, 지역 사회의 합의나 재량적 제재와 일종의 명예 제도에 대한 운영이 필요하다.또한, 이것은 정말로 기술 마을 펌프에 속할 것이다.

3) 마을 펌프(제안 페이지와 가장 가까운 것)는 비모바일 버전의 왼쪽에 있는 커뮤니티 포털에서 연결된다.

이안.thomson (대화) 03:39, 2016년 3월 4일 (UTC)[응답]

(1) 좋은 생각은 아니다. 많은 편집자들이 인간이 아니라 경고를 읽지 않는 로봇이기 때문이다.나는 매일 문제를 일으키는 여러 로봇들을 차단하는데, 로봇들은 어떤 것을 홍보하려고 한다.이곳에 새로 온 것으로 보이는 사람들을 위해 우리는 먼저 그들에게 경고하고 그들이 블록 전에 경고를 볼 시간이 있었는지를 확인해야 한다.그러나 위키피디아에 대한 피해를 막는 것이 목적이기 때문에 초래된 피해는 블록키족의 재활 가능성에 대해 균형을 이루고 있다.Graeme Bartlett (대화) 02:08, 2016년 3월 5일 (UTC)[응답]

별도의 "BLP 인용 필요" 템플릿을 만드십시오.

우리는 아마도 백과사전 전체에 필요한 수백만 개의 {{citation 필요 태그가 있을 것이지만, 어떤 인용문은 다른 인용문보다 더 긴급하다.그렇지 않으면 잘 꾸며진 BLP 기사가 출처 없이 추가될 가능성이 있는 진술이 추가되거나, 비 BLP 기사가 출처 없이 추가된 살아 있는 사람에 대해 논쟁의 소지가 있는 진술이 있는 경우, 인용문 추가의 시급성과 비소지적 주장에 대한 비소지적 주장 추가의 시급성을 구별하기 위해 {{BLP 인용문} 태그가 있어야 한다.BLP 주제. bd2412 T 12:26, 2016년 3월 4일 (UTC)[응답]

• 지지하다.백과사전을 대폭 개선하고 사용자들이 점점 더 의심스러운 내용을 삭제하도록 유도할 것이다. --Luis150902 (토크 기여) 2016년 4월 18:21 (UTC)[응답]
• WP별 반대:BLP, 리드섹션, "우리는 그 기사를 바로 잡아야 한다"는 문단의 시작 부분과 지미 웨일즈의 인용구가 연관되어 있다. --Redros64 (토크) 12:38, 2016년 3월 4일 (UTC)[응답]
  • 항상 BLP에 {{citation 필요}}개의 태그가 필요함을 알 수 있다.BLP를 위한 태그가 무엇인지 알 수 있는 방법만 있다면 직접 가서 모든 미인증 클레임을 제거할 수 있다. bd2412T 13:22, 2016년 3월 4일(UTC)[응답]
    • 여전히 역추론이다.문제는 의심스러운 정보가 아예 태그가 붙지 않고 제거됐어야 한다는 점이다.태그를 지정하면 안 되는 태그를 지정하기 위한 사용자 지정 태그를 만들면 태그가 잘못 지정되고 태그가 사이비 합법화되는 데 도움이 된다. — SMcCndlish ¢ 17 ^ʌⱷ 17 17 17 17 _ᴥ17 17 17^ʌ 17 17 17 17:56, 2016년 3월 4일 (UTC)[응답]
• WP별 의견:BLP, "소싱되지 않았거나 소싱이 제대로 되지 않은 생존자(혹은 최근에 사망한 경우)에 대한 불만족스러운 자료(부정적, 긍정적, 중립적, 또는 단지 의문스러운 경우)는 논의를 기다리지 않고 즉시 제거되어야 한다." 우리는 BL에 대한 논쟁적 자료에 {{citation need}개의 태그를 추가해서는 안 된다.P. 어떤 논의가 일어나기 전에 즉시 제거해야 한다.BLP에 대한 정보를 참조하는 cn 태그가 보이는데, 얼마나 자주 논쟁이 되는 정보를 참조하는가?잘은 모르겠지만 안정적으로 소스가 될 때까지 정보를 삭제해야 한다. -- GBfan 13:29, 2016년 3월 4일 (UTC)[응답]
  • @GB 팬: 좋은 지적이야.나는 그에 따라 그 제안에서 "아마도 논쟁의 여지가 있다"고 생각했다.BLP에 대한 비내용적 비내용적 비내용적 진술이라도 다른 것에 대한 비내용적 비내용적 진술에 대해 어느 정도 구별할 수 있는 수단이 있어야 한다.bd2412 T 13:47, 2016년 3월 4일 (UTC)
• 설명:템플릿:BLP 소스 및 템플릿:BLP 비소싱 섹션 및 범주:출처가 부족한 BLP 기사.일반적으로 인라인 유지관리 템플릿은 조항/섹션 폭과 동일한 문제에 대응한다.기사/섹션의 넓이를 왜 인라인으로 할 수 있는지 모르겠다.– 피누서톱 (토크 ⋅ 기여) 13:44, 2016년 3월 4일 (UTC)[응답]
• 생존자에 대한 논쟁의 여지가 있는 주장에 반대한다. 그들이 공급되지 않았을 때는 제거되어야 하고, 그들이 제대로 공급되지 않았을 때는 제거되어야 한다.마침표.수집(대화) 13:47, 2016년 3월 4일 (UTC)[응답]
  • @Collect:이에 따라 제안서 '논의'를 하게 됐다.bd2412T 13:49, 2016년 3월 4일 (UTC)[응답하라]
    • 그리고, 놀랍게도, 의심스러울 때, 적절한 코스는 BLP로부터 비소싱된 주장을 제거하는 것이다.이상적일 수 있는 몇 안 되는 경우에 새 템플릿을 추가할 필요는 없다.수집(대화) 13:51, 2016년 3월 4일 (UTC)[응답]
      • 그러나 지금 당장은 전체 기사를 {{BLP 소스}}}과(와) 함께 참조되지 않은 문장이 포함된 것으로 태그할 수 있다.그러기 위해서는 반드시 적어도 하나의 미소급 진술서를 찾아야 한다.이것을 제거하면 {{B를 태그할 다른 것을 찾아야 한다.LP source}}.저걸 제거하면 다른 걸 찾아야 해애드 인피니텀{{BLP source}}}은(는) 이 논의에서 제시한 논리("즉시 제거해야 한다")에 따라 사용하는 것이 사실상 불가능하다.– 피누서톱 (토크 ⋅ 기여) 2016년 3월 4일 (UTC) 14:00[응답]
  • 아니, 제거할 필요는 없다. 가능한 경우 소스를 추가해야 한다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 2016년 3월 4일 편집[응답]

    만약 당신이 그것들을 믿을 수 있다면, 좋아, 그렇게 해.그러나 할 수 없다면, [WikiEN-l]에서 짐보 웨일즈 (대화 · 기여)가 2006년 5월 16일 (UTC) 20:30에 명기한 바와 같이, 오해하거나 거짓된 정보보다는 제로 정보가 선호된다. --Redros64 (대화) 01:03, 2016년 3월 5일 (UTC)[응답]

• 필요 없는 것으로 반대하다.BLP 기사의 비소싱, 비참조 및 불분명한 문장은 BLP 지침에 따라 태그가 아닌 즉시 제거되어야 한다. 우리는 악취나는 템플릿이 필요하지 않다.GenQuest 15:53, 2016년 3월 4일 (UTC)[응답]
• 좀 더 분별 있는 행동을 하라.당신과 Redrose64가 다루고자 하는 문제에 대한 분명한 해결책은 cn 또는 다른 분쟁(정리하지 않음) 태그가 있는 BLP를 탐지함으로써 봇이 정리 범주를 채우도록 하는 것이다.봇 제안 페이지에 가서 그 봇을 제안하면 아마 만장일치 지지를 받을 겁니다.현재 제안은 루브 골드버그 장치 접근법이다. — SMcCndlish ¢ 17 ^ʌⱷ 17 17 17 17 _ᴥ17 17 17^ʌ 17 17 17 17:56, 2016년 3월 4일 (UTC)[응답]
  • 나는 사실 그 자체가 BLP가 아닌 페이지에 대한 주장(예를 들어 특정 정치인이 특정 후보를 지지했다는 당내 경선 페이지에 대한 미공개 진술)에 대해서도 신경을 쓰고 있다.이것들은 원칙적으로 인용하기 쉬워야 하지만, 경험이 적은 편집자는 어쨌든 태그를 던질 수도 있다.bd2412 T 03:25, 2016년 3월 5일 (UTC)[응답]
• 반대 - 우리는 이미 기본적으로 이러한 종류의 문제들을 강조하고 있는 두 가지 템플릿을 가지고 있다.가이1890 (대화) 07:15, 2016년 3월 6일 (UTC)[응답]

새 계정 - 초기 알림

얼마 전 신규 계정을 개설하는 사용자가 등록 시 알림을 받아야 한다는 결정이 내려져 환영/도움말/가이드라인 페이지로 연결되는 링크가 제공되기도 했다.

최근까지 그 페이지는 위키백과였다.환영 위원회/Welcome to Wikipedia, 그러나 지난 2주 이내에 도움말:시작.질문, 이 조항들에 대한 결정은 누가 하는가? - 변경사항은 어디서 발표되거나 논의되는가?만약 우리가 미리 알고 있다면, 우리는 연결될 페이지가 새로운 편집자들로부터 상당히 많은 수의 조회 수를 받기 위한 최상의 상태임을 확신할 수 있을 것이다.또한, 아직 자동 확증되지 않은 이 편집자들은 환영 페이지 자체를 편집할 수 없다는 것을 알게 되고, 그래서 그들 중 일부는 토크 페이지에서 온갖 이상한 의견을 내는 것에 의지하게 된다.위키백과의 대화:환영 위원회/Welcome to Wikipedia talk 페이지가 결국 찻집으로 리디렉션됨 - 이것이 가장 좋은 코스이며 도움말 대화:이제 시작도 이와 유사하게 리디렉션하시겠습니까?요약하자면, 우리는 가입 시 새로운 편집자에게 제공되는 내용에 대해 더 많은 대화를 통해 이익을 얻을 수 있을 것이다. 노이스터(토크), 00:56, 2016년 3월 3일(UTC)[응답]

그것은 특별했다:Diff/705246320. --크레네어 01:12, 2016년 3월 3일(UTC)[응답]

고마워 크렌에어!이제 추적할 수 있어"웰컴" 통지는 수년째 제공되고 있지만, 2015년 11월에야 각 위키에서 선택할 환영/도움말 페이지에 링크가 추가되었다.이 새로운 특집은 테크니컬 뉴스에서 발표되지 않았고, 환영 장소에서 그렇게 활발하게 활동하는 Moxy 같은 편집자도 루프를 돌지 않았던 것 같다.MediaWiki에서 링크를 지정하는 방법:통지-환영 링크, 그리고 처음에 레고크tm은 그것을 환영 위원회 페이지로 설정했다.2월에 여기서와 여기서로 나누어 토론한 후 Quidity의 제안에 따라 링크를 Help로 재설정했다.시작 페이지.나는 우리가 이 시설을 사용하는 것에 대해 더 잘 홍보하고 토론할 필요가 있다고 생각한다. 그리고 어떤 페이지가 링크되든 토크 페이지에 나타나는 시험 편집, "안녕"의 광고, 그리고 무작위 코멘트의 다양성에 대해 일관성 있는 접근법을 개발해야 한다고 생각한다.환영 위원회가 비록 그처럼 활동적이지는 않지만, 이 기능에 대한 업데이트와 토론을 위한 적절한 중심이 될 것을 제안한다. 노이스터(토크), 2016년 3월 3일 (UTC)[응답]

음, 확실히 기술 뉴스에 나왔어: m:기술/뉴스/2015/47.나는 그것이 어디로 연결되어야 하는지에 대해서는 의견이 없다. 단지 그것이 *어디서*를 연결해야 한다는 것이다.레곡™ (대화) 17:59, 2016년 3월 3일 (UTC)[응답]

미안, 그래, 이제야 알겠어Wiki는 시작 알림 링크를 특정 페이지로 만들 수 있다. 노이스터 (토크), 2016년 3월 3일 (UTC)[응답]

링크가 어떻게 작동하는지 잘 모르겠지만 리디렉션은 작동하지 않는 것 같다. 페이지를 리디렉션한 새 편집자는 tlak 페이지를 어떻게든 사용하는 것 같다. -- -- Moxy (talk) 16:58, 2016년 3월 3일 (UTC)[응답]

이 페이지의 대상은 MediaWiki talk에서 제어된다.알림-환영-링크.— Xaosflux 18:17, 2016년 3월 6일 (UTC)[응답]

우주선 이름으로 된 이탤릭체 vs 궤도 발사 차량 이름으로 된 이탤릭체 없음(로켓)

수신 템플릿

"듣기" 템플릿에서 템플릿의 모든 파일을 차례로 재생할 수 있는 클릭 가능한 버튼을 주시겠습니까?고마워요.Anythingyyouwant (대화) 22:08, 2016년 3월 7일 (UTC)[응답하라]

En-dash로 제목에 대한 리디렉션 만들기

에스페란자를 데려와!

짐보(saw)가 말하듯이... 위키피디아를 형편없게 만든다!66.97.241.196 (토크) 02:25, 2016년 3월 8일 (UTC)[응답하라]

• 글쎄, 그럴지도 모르지, 하지만 우리는 비공영 선거 절차를 통해 재활성화 위원회를 설립해야 하고, 그리고 나서 재활성화 위원회가 새로운 에스페란자 페이지 위원회를 설립해야 할 거야, 그리고 우리는 허가받지 않은 난방 수리공과 함께 이것을 할 수 없었지.오이야르밥시(토크) 02:48, 2016년 3월 8일 (UTC)[응답하라]

위키백과 말씀이시죠?에스페란자. --Redrose64 (대화) 15:08, 2016년 3월 8일 (UTC)[응답]

WP:TEAHouse는 거의 동일한 목적을 제공한다.EllenCT (대화) 2016년 3월 9일 (UTC) 13:59 (응답)

카테고리 이름 구문

안녕, 내가 편집한 거의 모든 것들은 카테고리 시스템을 향상시키는 것을 목표로 해.

이 주제에 대한 이전의 논의를 찾기가 매우 어렵다. 나는 "위키피디아 토크:카테고리 이름".

범주 형태의 범주의 이름 구문이 상세하지만 광범위하게 변경될 수 있는 가능성에 대해 생각해보십시오.Foo by Bar."대신 이렇게 보여야 한다: 카테고리:푸(바별)

범주 이름 전체가 하나의 직선으로 지속되고 구성되는 다른 부분들 사이의 명확한 구분 없이 하나의 선으로 쓰여진다는 것은 내게는 쉽게 헷갈린다.

단순해 보이는 카테고리:실제로 우리의 머릿속에 있는 Foo by Bar는 다음과 같다: 카테고리:"Bar" 매개변수로 분류된 "Foo" 항목 등록.분류 키를 괄호 안에 논리적으로 넣으면 개체와 정렬 키를 더 빨리 구별할 수 있기 때문에 이름을 더 쉽게 읽을 수 있다.이는 카테고리(Category):와 같은 더 큰 이름으로 명백해진다.거주 국가별 외국인 거주자(Category)와 범주 비교:국외 거주자(거주 국가별)
분류 키가 한 번에 두세 개의 키로 구성되기 때문에 분류 키가 매우 길어지는 범주가 많다.예: 카테고리:국적, 장르 및 악기별 음악가 vs 카테고리:음악가(국적, 장르, 악기별)<

가능한 우려에 호소하면서, 브래킷이 범주 이름에 이미 다른 기능을 가지고 있다는 것을 명확히 하기 위해, 나는 새로운 브래킷이 충돌할 수 있는 두 가지 가능한 경우를 설명한다.

사례 1: 키 정렬 전 괄호: 카테고리:조지아(국가) 출신 (직업별)

사례 2: 정렬 키의 대괄호: 범주:사람(조지아 주의 도시별(국가별))

나는 충돌은 두 경우 모두 비극적이지 않다고 생각한다. 브래킷은 구조와 명료함을 더하기 때문이다.이제 네 생각을 말해봐.나는 그렇게 광범위한 변화가 실행될 것 같지 않다는 것을 알지만, 진지하게 생각해봐.나는 분류 키의 대괄호를 정사각형으로 하는 것이 더 좋았을 텐데, 그것은 훨씬 더 보기 좋겠지만, 위키피디아는 그것을 허용하지 않는다.

이 제안을 하기 몇 시간 전에 나는 새로운 범주를 만들었는데, 이 범주를 증명하기 위해 나는 괄호로 이름을 붙였다.승인하지 않을 경우 언제든지 신속한 이름 변경 가능:범주:음악(장르별, 국적별)안녕하십니까, CN1 (대화) 01:12, 2016년 3월 5일 (UTC)[응답]

• 데브레서, עדד and and, kk로부터 답을 얻었다.
  

• addingודד to to에 대한 나의 대답에서 여기에 나의 요점을 덧붙이면서:
  "X by Y"는 보통 때와 같이, 전체 문장에서 사용할 때만 쉽게 이해할 수 있다."이 사람들을 직업별로 나열하라"거나 "장르별로 음악을 분류했다"고 말하는 것처럼 말이다.그러나 우리는 지금까지 문장 뒤에 디자인된 것이 아니라 구절로서 가능한 짧고 편리하게 만들어진 범주 이름에 대해 이야기하고 있다.그러나 이 이름들은 여전히 주요 개체 부분과 분류 키 부분으로 구성되어 있고 그것들을 눈에 띄게 구분하는 것은 고양이 이름을 더 쉽게 이해할 수 있게 해줄 것이다.
• 위키백과를 읽은 후:페이지_이름#기술적_제한_및_제한, 나는 괄호를 포함하지 않는 대안적인 결론에 도달했고, 심지어 나 자신조차도 더 잘 보이고 미래의 도전에 더 적합한 것처럼 보인다.

범주:Foo - by Bar

범주:조지아 출신(국가) - 직업별

범주:사람 - 조지아 주의 도시별(국가별)

지금까지 제안서 끝.CN1 (대화) 23:45, 2016년 3월 7일 (UTC)[응답]

제안된 변경에 찬성하지 않는다.브래킷은 사실 틀렸다. 왜냐하면 그것은 정말로 "장르별, 국적별 음악"이기 때문이다.(대화) 2016년 3월 5일 16:45 (UTC)[응답]

우리는 대괄호의 내용이 정상적인 산문에서 나타나지 않을 경우에만 범주 이름에 대괄호를 사용한다.당신은 조지아 컨트리라는 말을 하지 않을 것이다. 그래서 "컨트리"라는 단어는 괄호로 묶는다.산문에서 실제로 이 이름으로 언급되는 뉴욕시와 비교해 보라."거주국별 국외 거주자"와 같은 이름은 조지아(국가)보다는 뉴욕시와 더 비슷하다.עודדוו odיו od mis od od od od od od od od od od od od 19:47, 2016년 3월 5일 (UTC)[응답]

내가 전적으로 동의하는 것은 아니지만, 너는 좋은 점을 거기에서 제기한다."X by Y"는 보통 때와 같이, 전체 문장에서 사용할 때만 쉽게 이해할 수 있다."이 사람들을 직업별로 나열하라"거나 "장르별로 음악을 분류했다"고 말하는 것처럼 말이다.그러나 우리는 지금까지 문장 뒤에 디자인된 것이 아니라 구절로서 가능한 짧고 편리하게 만들어진 범주 이름에 대해 이야기하고 있다.그러나 이 이름들은 여전히 주요 개체 부분과 분류 키 부분으로 구성되어 있고 그것들을 눈에 띄게 구분하는 것은 고양이 이름을 더 쉽게 이해할 수 있게 해줄 것이다.CN1 (대화) 21:01, 2016년 3월 6일 (UTC)[응답]

[[:카테고리:[조지아 주의 도시별(국가별)]이 최선의 해결책이며, 그 제안은 다섯 번의 논평 끝에 거절되어서는 안 된다.문제는 어려워 / 여기 보시다시피 위키링크가 불가능할 수도 있어... --Obsuser (대화) 21:26, 2016년 3월 6일 (UTC)[응답]

다음과 같이 연결할 수 있음: {{외부 링크 url=https://en.wikipedia.org/w/index.php?title=Category:People_%5bby_city_in_Georgia_(country)%5d name=카테고리:[조지아 주의 도시별]}.그러나 오류 팝업: 특수 페이지 제목 불량 페이지 요청 페이지 제목에 잘못된 문자가 포함됨: "[]." 기본 페이지로 돌아가십시오. --Obsuser(토크) 21:36, 2016년 3월 6일(UTC)[응답]

• 지금 부정적인 의견과 긍정적인 의견의 비율이 두 개 이상 증가한다면 거부된 의견으로 종결해 달라.CN1 (토크) 02:34, 2016년 3월 7일 (UTC)[응답]

위의 어떤 것도 달리 제안할 수 있을 만큼 충분히 중요한 것이 아니기 때문에 나는 이 제안에 동의한다.kk (talk) 11:23, 2016년 3월 7일 (UTC)[응답하라]

• 나의 경험으로 볼 때, 카테고리를 신경 쓰는 사용자 수는 기사나 실제 콘텐츠를 신경 쓰는 사용자 수에 비해 상당히 적다.카테고리 프로젝트 토크 페이지를 보면, 토론이 상당히 느리고, 실제로 정기적으로 아무도 카테고리 토크 페이지를 방문하지 않기 때문에, 나는 그곳에 글을 쓰는 모든 신규 사용자들에게 프로젝트 페이지나 포털로 직접 가라고 말한다.내 말은, 이번 일이 벌어지려면 좀 더 기다려야 할지도 모른다는 거야.CN1 (대화)20:25, 2016년 3월 7일 (UTC)[응답]

이 제안은 어떤 문제를 해결하기 위한 것인가?춘투크(토크) 12시 2분, 2016년 3월 8일 (UTC)[응답]

• 제안자 외에는 현재 우리의 카테고리 이름이 혼란을 일으킨다는 증거가 없다.나는 게시된 모든 예시를 쉽게 이해할 수 있고, 제안된 대안들은 기술적으로 불가능하거나 읽기에 거슬린다.펜스&윈도우 23:50, 2016년 3월 10일 (UTC)[응답]

이런 템플릿에 대해 생각해 보셨나요?

위키피디아는 "이 사용자..그 뒤를 이어 사용자가 선호하는 영어 변형에 대해 이야기하는 것이 나왔다."이 사용자는 트랜스 사람들을 존중하는 방식으로 언급해야 한다고 생각한다" 또는 "트랜스 사람들이 어떤 목적을 위해 그들의 성별을 양육하는 것으로 언급되어야 한다고 생각한다"라는 템플릿이 있는지 알고 싶다.조지아 남자 (토크) 2016년 3월 9일 (UTC) 18:48[응답]

@조지아남:WP 말씀이세요?USERBOXes? --Redros64 (토크) 20:15, 2016년 3월 9일 (UTC)[응답]

그래, 내가 말하는 템플릿의 종류야.조지아 남자 (대화) 2016년 3월 9일 20:20 (UTC)[응답]

WT에서 물어봐:UB, WT:UBX가 더 활발한 것 같아. --Redros64 (토크) 20:29, 2016년 3월 9일 (UTC)[응답]

같은 이유로, "이 사용자들은 foo 사람들이 존경받는 방식으로 언급되어야 한다고 생각한다"고 말하는 사용자들을 더 많이 가질 수 있을까? foo는 레즈비언/게이/바이젠/트랜스/퀴어/흑인/혼혈/아시아인/멕시코인/프랑스인/생강머리 ... 당신의 억압받는 소수자들을 선택한다.그래, 점점 바보같아지지, 안그래?아니. 만약 우리가 이 길로 가게 된다면, "이 사용자는 모든 사람들을 존중하는 방식으로 언급해야 한다고 생각한다."라고 말하는 사용자 박스를 하나 갖자.아마 있을 거야, 나도 몰라, 난 사용자 박스에 관심 없어.스탠닝(대화) 11시 25분, 2016년 3월 10일 (UTC)[응답]

위키피디아를 찾았다.Userbox/Life#Gender, 위키백과:Userbox/Life/Sexuality 및 User:ISD/사용자박스/성애 : 여기에 겹치는 부분이 있다. --Redros64 (대화) 13:30, 2016년 3월 10일 (UTC)[응답]

@조지아남:거기서 원하는 것을 찾을 수 없다면 언제든지 직접 만들 수 있다.그것들은 당신의 사용자 공간에 들어간다.오이야르밥시 (대화) 00:44, 2016년 3월 11일 (UTC)[응답]

뉴 빌리지 펌프 페이지?

나는 한동안 WMF-커뮤니티 참여를 촉진하기 위해 특별히 빌리지 펌프 페이지를 갖는 것이 좋을지도 모른다고 생각해 왔다.특히 나는 WMF 팀 중 한 팀과 협력하여 RFC를 입안하여 그들이 진행하고 있는 프로젝트 중 하나에 대한 피드백을 받고 있었다.게시할 곳은 빌리지 펌프(기타)뿐일 것이다.메. 토론이 얼마나 크게 될지는 알 수 없고, 이런 일이 흔한 일이 된다면 유익할 것 같아.알제 (대화) 23:32, 2016년 3월 2일 (UTC)[응답]

더 나은 WMF-커뮤니티 참여에 대한 인식의 필요성이 분명히 존재한다.제대로 된 포럼이 없는 것과 맞물려 짐보의 토크 페이지에도 많이 채널을 맞추는 것 같다.나는 약혼을 건설적으로 만드는 방법이 있기를 바란다; 최근에 나는 이것에 실망했다.새로운 마을 펌프를 재단 때리기 대신 건설적인 참여를 장려하는 것으로 만드는 방법이 있다면, 나는 환영한다.그러나 한 가지 고려해야 할 점은 WMF가 다양한 분야에서 작동한다는 것이다(기술, 법률, "비전" ... 요컨대 그것에는 본질적인 "기타" 측면이 있다).– 피누서톱 (토크 ⋅ 기여) 11:55, 2016년 3월 3일 (UTC)[응답]

그것이 끝없는 항의의 페이지가 될 위험성이 있지 않을까?유용하다고 어떻게 생각하십니까?Praemonities (대화) —미등록 댓글 준비 중 20:04, 2016년 3월 3일 (UTC)[응답]

명예훼손, 나는 "경배"에 대한 우려를 이해한다.나 자신도 목장 주인 중 한 명이었다.하지만 난 정말 긍정적인 변화를 보고 있어.수집은 우리의 RFC가 요청한 후에 당연히 제거되었다.WMF가 기본적으로 준비돼 있는 피드백을 요청하는 초안을 작성하도록 도와줬는데, 여기서 WMF는... WMF가 그걸 원하지 않는 위키에 밀어넣기를 원하지 않는다.그것은 또한 그들이 더 일찍 우리와 상의하지 않은 실수를 저질렀다고 말한다.프로젝트 리드는 그들이 무언가를 밀어내기 위해 "우울하게" 있다는 인식을 피하기 위해 매우 우려하고 있다.나는 WMF가 어떻게 우리와 대화하고, 우리가 원하는 방식으로 우리를 참여시킬 수 있는지 알아내도록 돕고자 한다.알제 (대화) 08:03, 2016년 3월 4일 (UTC)[응답]

내가 제대로 주소를 못 썼다는 걸 깨달았어. 그게 유용하다고 어떻게 생각해?나는 WMF가 거기에 새로운 프로젝트 아이디어를 게시하는 것을 보았어. 그래서 우리는 그들이 무언가를 짓기 전에 논평할 수 있어.그들은 사물에 대한 피드백 요청을 게시할 수 있고, 가장 중요한 것은 우리가 Feature-X를 만들기를 원하는지 혹은 사용할지 여부를 우리에게 묻는다.WMF는 제안 페이지에서 Visual Editor와 관련하여 기능 활성화 RFC를 반반적으로 실행했다.그것은 아마도 WMF 페이지로 옮겨갈 것이다.그리고 그래, 최근 Gather를 비활성화하는 RFC 같은 것들이 WMF 페이지로 옮겨갈 수도 있을 것이다.솔직히 나는 그것이 어떻게 진화할지 완전히 확신할 수는 없지만, 나는 그것이 필요한 페이지라고 생각한다.나는 그것이 우리가 더 나은 WMF-커뮤니티 관계를 구축하는 데 도움이 될 것이라고 믿는다.알제 (대화) 08:16, 2016년 3월 4일 (UTC)[응답]

@Alsee: 위키미디어 재단과 지역사회 간의 의사소통 개선에 기여해 주셔서 감사하다.이 제안의 경우 취지는 맞다고 생각하지만 실행이 최선의 것은 아닐 수도 있다.한 가지 예: 12개의 위키피디스가 자신의 WMF 빌리지 펌프를 만들면서 여러분의 절차를 따르기로 결정하면 어떻게 되는가?우리가 그들을 막을 수 있을까?그들의 기대를 충족시킬 수 있을까?아마 아닐 것이다.

WMF 계획은 모든 지역사회가 참여할 수 있도록 제품 개발 프로세스를 개방하는 것이다.통신 방정식을 해결하는 것은 분명 간단하지 않지만, 해결책은 아마도 번역 가능성이 있고 매우 구체적인 뉴스(예: "새로운 프로젝트 아이디어", "설계 검토 요청", "배포 계획에 대한 피드백") 및 교차 위키 알림에 대한 구독을 갖춘 중앙집중화된 위치에서 시작할 필요가 있을 것이다.이러한 방식으로 모든 개인은 자신의 관심사와 기술에 해당하는 검토 유형에 가입할 수 있으며, 자신의 위키에서 업데이트를 받을 수 있다.이 과정에 필요한 모든 조각들이 이미 존재하고 있다.제품 개발 프로세스 및 통신 채널에 대한 토론에 참여하려면 다음 항목을 확인하십시오.T124288.--Qgil-WMF (대화) 21:03, 2016년 3월 8일 (UTC)[응답하라]

Qgil-WMF, 커뮤니티 참여에 대한 당신의 노력과 여기에 대한 당신의 코멘트에 감사한다.나는 여러 위키로 확장성에 대한 당신의 우려를 충분히 공유한다.나는 지역사회가 그 문제들을 해결하는데 도움을 줄 수 있는 장기적인 아이디어를 가지고 있다.이것은 양끝에서 태클할 필요가 있다.WMF-Central에 대한 당신의 계획은 필요한 단계지만, 나는 우리가 당신을 도울 수 있는 현지 프로세스를 구축할 수 있는 현지 페이지도 필요하다고 믿는다.WMF는 미디어 뷰어 커뮤니티 협의회를 처리하려다 압도당할 뻔했고, 그 과정과 결과는 완전히 불법이며 말 그대로 상황을 악화시키는 것으로 널리 인식되었다.WMF가 wiki를 지배하는 한 세계 최대 규모의 사람들이 수 많은 언어로 나타날 것을 예상하는 것은 효과가 없을 것이다.그것은 확장 불가능하며 그것은 커뮤니티와 합의를 인정하거나 존중하지 않고 대량으로 개인에 대한 참여를 제한한다는 공동체의 근본적인 반대를 완전히 놓치고 있다.

여기 제안서와 관련하여, 이것은 WMF가 게시하는 것을 환영할 커뮤니티 페이지를 위한 커뮤니티 제안서 입니다.우리는 지금 WMF-반응이 엇갈리고 있다.WMF가 여기서 바람직한 직책을 찾지 못한다면, 그것은 절대적으로 괜찮다.나는 여전히 그 공동체가 다양한 목적으로 유용하다고 생각할 것이라고 믿는다.나는 가치 있을 것이라고 믿는 작품들에 다른 공동체 프로젝트들이 있다.펌프_(WMF)는 절대적으로 그것을 위한 장소다.알제 (대화) 01:22, 2016년 3월 9일 (UTC)[응답]

실제로 앨리스는 지역사회가 제품 개발 과정에 이해관계자로서 참여할 수 있는 공간을 확보해야 한다.네가 어떻게 스스로를 정리하느냐는 너에게 달려 있다.어떤 일이 있어도 우리는 계속해서 피드백과 관여를 위해 손을 내밀 것이다.

나는 단지 이 제안이 더 높은 기대를 불러일으킨다는 것을 강조하고 싶다.우리는 en에서 그 토론을 기대할 수 없다.wiki(또는 지역 프로젝트)는 새로운 프로젝트 아이디어가 개발로 이전되는지 아니면 주차되어 있는지 여부를 결정할 것이다.위키미디어 커뮤니티는 새로운 소프트웨어 프로젝트를 촉진하거나 중지할 수 있는 힘을 가져야 하지만, 모든 커뮤니티에 공통적인 장소와 프로세스에서 가져야 한다.현지 구축에 관한 한, 그것은 현지에서 다루어야 할 논의다.단, 이때도 배치를 담당하는 팀에게 결정을 전달하기 위한 중앙집중식 프로세스가 필요하다는 점에 유의한다.--Qgil-WMF (대화) 2016년 3월 9일 (UTC)[응답]

나는 그 페이지의 초안을 작성했지만, 그것을 빌리지 펌프 본 구조로 연결하지는 않았다.위키백과 참조:마을 펌프(WMF).알제 (대화) 11시 22분, 2016년 3월 4일 (UTC)[응답]

위키다타는 d:에 유사한 페이지를 가지고 있다.WD:대부분 하이브리드 VPT/VPWMF인 개발팀에 문의하십시오.매우 유용하지만, 그것은 기술 프로젝트로서의 위키다타가 프로젝트 조정을 다듬었기 때문일 것이다.그렇긴 하지만, 사회적 구매가 필요할지도 모르는 기술팀의 제안은 대부분 여기 없는 단수 마을 펌프에서 끝나게 된다. --Izno (토크) 13:03, 2016년 3월 4일 (UTC)[응답]

• 좋은 아이디어 지원, 여기서 큰 욕구를 채워줘. --Tom (LT) 08:45, 2016년 3월 5일 (UTC)[응답]
• 비록 그것이 장소로서 비건설적이 되었다면 그것은 폐쇄되어야만 했지만, 원칙적으로는 시도할 가치가 있다.직원들 생각은 어때?베스넛 (대화) 11시 32분, 2016년 3월 7일 (UTC)[응답]

BethNaught: "직원들은 어떻게 생각하는가?" - 나는 WMF 전체에 대해 어떤 주장도 하지 않고 있고, WMF에 대한 광범위한 언급도 있었지만, 분명한 긍정적인 반응을 얻었다.한 프로젝트 매니저는 "나도 너의 새로운 마을 펌프장을 보게 되어 기쁘다!"라고 말했고, 연락 담당자는 이 섹션에 있는 내 게시물 중 하나에 감사 기능을 사용했다.갑작스런 반대가 나타나지 않는다면, 나는 WMF가 그들의 첫 번째 공식 게시물에 불을 붙이는 대로 그 페이지를 생방송으로 만들 계획이다.(대화)16:25, 2016년 3월 7일 (UTC)[응답]

아니, WMF 사이트로 가야 해영어 위키백과에서 주의를 딴 데로 돌리는 겁니다.알란스코트워커 (대화) 21:13, 2016년 3월 8일 (UTC)[응답]

더 적은 사람들이 볼 수 있는 또 다른 위키에 약혼을 위한 노력을 하는 것은 역효과를 낳는다.게다가 당면한 문제가 엔위키에만 국한되어 있다면, 여기서 논의하는 것은 아주 일리가 있다.베스넛 (대화) 2016년 3월 8일 21시 18분 (UTC)[응답]

아니 그렇지 않다.우리는 이미 네 개의 펌프를 가지고 있다. 영어 위키피디아는 논쟁할 다른 포럼을 아직 필요로 하지 않는다.관련 펌프에 공지를 붙이면 WMF위키 자매 토론에 관심을 끌고 싶으면 사람들이 보게 된다.알란스코트워커 (대화) 22:34, 2016년 3월 8일 (UTC)[응답]

@Alanscottwalker:나는 5를 세고 있다: WP:VPI; WP:VPM; WP:VPP; WP:VPR; WP:VPT.하지만 그것은 여전히 사람들을 혼란스럽게 하고, 그들은 어떤 것을 사용해야 할지 알지 못하기 때문에, 우리는 VPT 등에 정책 문제를 게시한다.실제 펌프가 아닌 펌프토크 페이지에 글을 올리는 사람도 있다. --Redrose64 (대화) 09:53, 2016년 3월 9일 (UTC)[응답]

Ping Risker: 새 페이지가 활성화되면 WMF Content Checklist를 게시하시겠습니까?WMF는 그것에 대해 매우 열정적이었다.사람들은 그것이 모든 근거를 포함하는지 확인할 수 있고, 우리는 합의된 지원을 확립할 수 있다.알제 (대화) 2016년 3월 9일 01:31 (UTC)[응답]

• 이 아이디어에 대한 내 지원서를 등록하고 있는 중이야.나는 enWP가 WMF와 소통할 수 있는 중앙집중화된 장소를 갖는 것이 유리할 것이라고 생각하며, 이것은 또한 프로세스에 대한 기대치를 설정하는 데 도움이 될 수 있을 것이다(공식적이든 사실적이든).혼란에 문제가 생기면 다시 폐쇄를 결정할 수 있다.위에서 언급한 바와 같이 몇 가지 중복된 토론으로 이어질 수도 있지만, 모든 위키들은 독립적이며 어떤 경우에도 별도로 결정을 내린다.일출(토크) 05:52, 2016년 3월 9일 (UTC)[응답]

의사소통의 개선이 필요하다는 데는 동의하지만, 이 채널을 추가하는 것에 대해 궁금한 점이 있어, 앨시.이 새로운 부사장이 어떻게 작동한다고 생각하십니까?당신은 사람들을 그러한 채널로 유도하기 위해 (실제로 확인하거나 시청하는 경우) 엔위키 커뮤니티에 메타나 MW에서 일어나는 일들을 알리는 비콘으로 운용하는 것이 최선이라고 생각하는가, 아니면 이것이 메타처럼 중앙집중적이고 동작이 넓은 장소에서 시간을 빼앗으면서 모든 직원들이 소통할 수 있는 부가적인 채널이라고 기대하는가?그것은 지역사회가 논의한 다음 WMF까지 거품을 내기로 결정하는 장소일까, 아니면 직원이 항상 혹은 심지어 어느 정도 그것을 지켜볼 것이라는 기대일까?아니면 다른 방법이 있을까?

모든 프로젝트로부터 피드백을 받는 것은 이미 여러 장소에 분산되어 있을 때 시간이 많이 소요되는데, 나는 그러한 이유로 이 장소를 추가하는 것에 대해 의구심을 갖고 있다.특정 프로젝트에 대한 프로젝트(기술적 또는 기타)를 시험하거나 시작할 때, 특정 지역사회가 그 이니셔티브에 대해 작업하는 WMF 팀과 의사소통할 수 있어야 하지만, 상수적으로 다른 위치로부터 다른 의견을 취합하려고 노력하는 것은 이미 상당한 양의 직원을 필요로 한다는 것은 이해할 수 있다.다른 곳에서 가장 잘 사용될 수 있는 에너지.나는 더 많은 채널보다 더 적은 채널을 지원하는 솔루션을 보고 싶다.이 VP를 만든다고 해서 결국 그 목표를 달성할 수 있는 방법이 있다고 생각하십니까? -Rdicerb (WMF) (토크) 19:20, 2016년 3월 9일 (UTC)[응답]

Ping Rdicerb (WMF), Qgil-WMF. 관련 우려를 제기하는 만큼 두 분 다 같이 회신하겠다.내가 WMF 직원들에게 부담을 준 인상을 만들었다면 사과한다.오히려 덜 부담스러운 해법을 만들려고 한다.다음과 같은 가능한 미래를 상상해 보십시오.WMF는 당신의 중앙 페이지에 ONE 포스트를 배치한다.그것은 커뮤니티, 봇, 또는 어떤 교차 위키-트랜스랜잭션에 의해 다양한 커뮤니티 페이지로 옮겨질 수 있다.공동체는 그 한 메시지를 번역하는 책임을 질 수 있다.지역사회는 우리의 지역 프로세스를 충분히 적용하여 우리의 큰 혼란스러운 논의를 할 수 있다.그런 다음 커뮤니티는 요약 결과를 생성한다.커뮤니티는 ONE 요약본을 다시 영어로 번역하고(필요한 경우), WMF에 전달한다.그것은 규모를 확장하고, 그것은 인력에 대한 부하를 최소화한다.만약 WMF가 모든 텍스트를 디폴트하는 새로운 제품 아이디어를 코믹 산스에 게시한다면, 지역사회는 컨센서스 반대 의견을 회신할 수 있다.이는 "원하는 경우 프로젝트를 진행하되, 여기서는 어떤 배치 단계도 지원할 수 없을 것 같다"로 해석된다.만약 당신이 다른 지역사회에서 상반된 반응을 얻는다면, 우리는 그것을 합리적으로 분류하기 위해 함께 노력할 것이다.알제 (대화) 21:26, 2016년 3월 9일 (UTC)[응답]

분명히 말해줘서 정말 고마워, 알제.FWIW :) 다른 이해관계자들로부터 (워크플로우 주변의 직원부터 요약본을 만드는 데 동의하는 커뮤니티에 이르기까지) 어느 정도 인수를 필요로 하는 프로젝트처럼 들리지만 불가능한 것은 아니다.나는 이것이 어떻게 작동할지 좀 더 명확하게 할 수 있어서 기쁘다.-Rdicerb (WMF) (대화) 22:24, 2016년 3월 9일 (UTC)[응답]

Rdicerb (WMF), 토론 요약을 만드는 것은 이미 우리가 항상 하고 있는 일이다.우리는 그것들을 Close :) 이것은 일반적으로 평소보다 더 상세하고, 우리는 그것들을 제출하기 전에 검증 단계를 추가하겠지만, 그 중요성이 우리가 보통 하는 일보다 더 보람있게 만들 것이다.그것은 모두 일반적인 개념일 뿐이다.나는 엔위키에서 시작하여 함께 그것을 알아내려고 애쓰는 걸음걸이를 할 수 있기를 바라고 있었다. (가장 크고 오래된 공동체를 가진 공유어가 이곳을 자연스럽게 시작하게 한다.)나는 리딩 팀이 여기에 올릴 피드백에 대한 매우 조심스러운 요청을 만드는 것을 도왔다.물속 발가락 테스트.프로젝트 매니저가 한번 시도해 보는 것에 열의가 있는 것 같아, 연락 담당자가 2016년 3월 10일(UTC) 00:53, 10:53, 회신해 주길 기다리고 있어.

알제, 그래, 네 상술은 내가 생각하고 있는 아이디어와 맞아.그 과정을 설계하고 구현하기 위한 피드백과 도움은 매우 환영한다.그러나, WMF Village Pump in en.위키는 그런 과정을 위한 어려운 요구사항이 아니다.제목에 '위키메디아 재단' / 'WMF'가 있는 포럼이 생길 것이라는 기대감에 계속 걱정이 되고, 이 우려는 내가 확인한 다른 WMF 동료들이 공유한다.만약 엔위키가 새로운 마을 펌프가 필요하다고 생각한다면, WMF는 그것에 대해 할 말이 없다.그냥 WMF라고 부르지 말아줘.--Qgil-WMF (대화) 10:59, 2016년 3월 10일 (UTC)[응답]

대체 이름에 대한 제안이 있으신 분?알제 (대화) 2016년 3월 10일 18:11 (UTC)[응답]

("누군가" 이 글을 읽거나 WMF에 있는 사람? 전자로 가정해 볼게.)
나는 WMF가 설명되지 않았기 때문에 그 이름에 대한 우려를 이해할 수 없다.WMF를 사용할 수 없는 경우 정확하고 서술적인 기능을 제한하고 명칭이 다소 불투명해진다.처음 보는 사람들은 그것이 무엇인지 전혀 모를 것이고, 그것을 알아내는 데 시간이 걸릴 수도 있고 아닐 수도 있다.만약 그것이 받아들여진다면, 아마도 지역 연락 담당자와 같은 것이, 예를 들어, 블루 페이지보다.만약 우리가 여전히 마을 펌프 페이지의 제목에 대해 이야기하고 있는데, 나는 그것에 대해 혼란스럽다면, 그것은 위키백과일 것이다.마을 펌프(지역 연락 담당)
한 가지 바로 가기는 WP:VPC(현재 펌프에는 모두 3자로 된 바로 가기 VPx가 있음)이어야 하며, 그 리디렉션은 위키백과에서 도난당해야 한다.바로 가기 상자에 나열되지 않고 어떤 경우에도 비활성 상태인 소중한 사진.대체 단축키는 WP일 수 있다.VPCL, WP:VPL. -Mandruss 인터뷰 03:30, 2016년 3월 12일 (UTC)[응답]

맨드러스, 그래 난 아무나 물어봤어.'WMF' 페이지는 단순히 WMF를 주제로 한 커뮤니티 페이지가 아닌 WMF와 공식적으로 연결된 것으로 해석될 수 있다는 우려와 WMF 직원이 그곳에서 시간을 할애할 의무가 있다는 기대도 형성될 수 있다는 우려였다.특히, 모든 언어가 WMF 페이지를 만들었고, 그들 모두가 직원들이 그들 각각에 시간을 할애하기를 기대한다면 어떨까?알제 (대화) 07:11, 2016년 3월 12일 (UTC)[응답]

추가 검토 후 WP의 설명은 다음과 같다.VP는 (1) 페이지가 거기에 표시되고 (2) 실제로 설명이 WMF를 언급한다고 가정할 때, 페이지 제목에 WMF를 덜 중요하게 만들 것이다. 펌프 페이지 상단의 설명은 말할 것도 없다.그러나 그러한 설명에도 동일한 우려가 존재할 것인가?WMF라는 글자를 어느 시점에 보여줘도 괜찮을까? -Mandruss 인터뷰 07:41, 2016년 3월 12일 (UTC)[응답]

나는 WMF가 편집자들이 그 페이지를 어떻게 해석할 지에 대해 지나치게 신중할 수 있다고 생각하지만, 나는 어떤 걱정거리라도 해결하기 위해 내가 할 수 있는 모든 것을 하고 싶다.나는 그들이 "이것은 WMF로 보내질 제안서들을 개발하기 위한 페이지"나 비슷한 것들을 포함하는 서술적인 텍스트에 반대할 것이라고는 상상할 수 없다.그들은 편집자들이 WMF가 "제공된" 것에 대해 비현실적인 기대를 갖는 것을 원하지 않는다.알제 (대화) 03:25, 2016년 3월 13일 (UTC)[응답]

그렇다, 주요 관심사는 특정 VP가 WMF의 공식 지지를 받는다는 기대감이다.이는 VP에 대한 완벽한 직함과 설명을 가질 때 조차도 고려해야 할 요소다.예를 들어, 지미 웨일즈나 (최근까지) 라일라 트레티코프는 비판적인 다수의 편집자들이 그곳에서 답변을 얻을 것으로 기대하기 때문에 그들의 토크 페이지에서 WMF와 관련된 질문과 요청을 일상적으로 접하게 된다.en에 포럼이 있는 경우.WMF에 질문이나 요청을 할 수 있는 채널처럼 보이는 wiki, 나는 그런 유형의 기대가 더욱 확고해질 것으로 기대한다.

또한 여기서 논의되는 범위는 소프트웨어 제품과 주요 기능인 것처럼 보이지만, 「WMF」와 「WMF 커뮤니티 참여」의 범위는 더 넓다.만약 당신이 새로운 VP를 생성한다면, 그 범위는 명확하게 정의되어야 한다.--Qgil-WMF (토크) 10:06, 2016년 3월 14일 (UTC)[응답]

Qgil-WMF, 과제의 일부는 범위가 모호하다는 것이다.예를 들어, 우리들 중 몇몇은 우리에 대한 기본적인 개요 가이드를 만드는 것에 대해 이야기하고 있었다. (그 아이디어는 당신이 유용하다고 여길 수 있기를 바라면서, 당신에게 그것을 제공하는 것이다.)추측된 청중들은 기사 페이지를 읽는 것 이상의 친숙함이 없는 새로운 WMF 고용인이 될 것이다.그것은 핵심 공동체 개념과 우리가 어떻게 일하는지에 대한 피상적인 설명을 줄 것이다.예를 들어, 나는 일부 직원들이 우리가 일반적으로 "관리자"를 관리직(a.k.a)으로 지칭하는 것에 놀랄지도 모른다고 생각한다."걸레").그것은 "관리자" 역할이 관습적인 가정을 따르지 않는다는 것을 쉽게 강조한다.위계질서에서 권력지위가 아니다.알제 (대화) 06:23, 2016년 3월 15일 (UTC)[응답]

"우리에 대한 기본 개요 안내서"를 참조하십시오.위키 아니면 위키미디어 운동?메타도 이런 종류의 문서를 가지고 있고, 엔위키도 있을 것이고, WMF 내부 사무실이 있을 것이다.wiki도.나는 재단의 신입 사원들이 더 나은 기내식으로 혜택을 받을 것이라는 것에 동의하지만, 그러나 다른 정보 출처는 아마도 그들이 필요로 하는 것이 아닐 것이다.어쨌든 이 대화는 본래의 주제와 너무 멀어지고 있다.--Qgil-WMF (대화) 12:52, 2016년 3월 16일 (UTC)[응답]

인터위키라고 부를까?대체 이름에 머리를 쥐어짜고 있는데 그게 내가 생각해낸 최선이야.그것은 지역적이지 않은 면으로 어떤 것이든 다룰 수 있다.알제 (대화) 22:46, 2016년 3월 18일 (UTC)[응답]

표준 전기 바닥글을 향해

예를 들어, Kylie Minogue와 같은 기사는 위키다타에서 자신의 가치를 끌어낼 때 각각의 매개 변수를 포함하지 않는 다수의 공통 템플릿을 포함하고 있다.

{{Commons category}}{Wikiquote}} * {{공식 웹사이트}*{IMDb name}}{권한관리}}}}

다음과 같은 템플릿을 하나의 템플릿으로 결합하려고 하면 현명한 것 같다.

{{바이오그래피 바닥글}}

또는 전문 분야의 노력을 위해 다음 중 하나를 수행하십시오.

{{Musician footer}}

또는

{{크리케터 바닥글}}

, 등등.이들은 사례별로 적절한 값과 라벨을 표시할 수 있다(또는 표시하지 않을 수도 있다.어떻게 하면 이런 템플릿으로 나아갈 수 있을까?Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2016년 3월 3일(UTC) 11시 45분[응답]

• 지원 - 기사 페이지를 단순화하십시오.그 방법은 직업에 근거하여 일반적인 바닥글을 보고, 그것을 바탕으로 템플릿을 만드는 것이 될 것이다.עודדוו odיו od od od od od mis od 미셰후 15:44, 2016년 3월 3일 (UTC)[응답]
• 논평, 반대 의견들 대부분의 템플릿들은 무차별적으로 추가된다면 문제적이다.{{공식 웹사이트}}}은(는) 위키다타에 목록이 없을 경우 크고 보기 흉한 빨간 오류를 준다.{{Commons category}}, {{Wikiquote}} 클레임 정보를 이용할 수 있으며 잠재적으로 존재하지 않는 페이지로 연결되는 링크를 생성한다.{{IMDb name}}이(가) 잠재적으로 비과학적인 검색 결과에 대한 링크를 생성한다.{{Authority control}}}을(를) 일관되게 추가할 수 있는 유일한 것으로 보인다.모든 하위 템플릿이 유효할 경우 통합 템플릿을 신중하게 사용할 수 있지만, 추가된 편의성이 경미해 보여 단점이 보인다.덜 친숙한 편집자들이 무슨 일이 일어나고 있는지 알아내려고 할 때, 혹은 부적절하게 그것을 복사하려고 할 때 더 혼란스럽고 골치가 아프다.만약 누군가가 통일된 템플릿을 기사에 넣었지만 그 항목 중 하나가 유효하지 않다면, 그들이 통일된 템플릿을 세 개의 정확한 하위 템플릿과 교환해야 한다는 것은 번거롭고 매우 명백하지 않다.알제 (대화) 17:07, 2016년 3월 3일 (UTC)[응답]
  • 템플릿은 적절한 Wikidata 속성이 있는지 확인할 수 있다(hu: 참조).템플릿:예를 들어 Filmlinkek).– nyuszika7h (대화) 18:59, 2016년 3월 3일 (UTC)[응답]
    • 예를 들어 라트비아어 및 노르웨이어 위키백과(OK, we(Latvians)는 단순히 노르웨이어로 복사한 것 : )에는 (Wikidata로부터) 기사에 일부 프로필을 추가하는 템플릿 스포츠 외부 링크가 있다. --Edgars2007 (대화/출연) 08:27, 2016년 3월 4일 (UTC)[응답]
• About As는 지적되어온 바와 같이, 거의 상승하지 않고 큰 하락세를 보인다.우리는 너무 많은 전기 기사들과 매우 다양한 성격을 가지고 있다; 그 제안은 아주 작은 기사 그룹에게만 도움이 될 것이다.크리스 트라우트맨 (토크) 2016년 3월 4일 (UTC) 15:46[응답]
  • 이건 투표가 아니야. 그리고 어떤 경우에도 너는 내가 하지 않은 제안에 반대하는 것 같아.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2016년 3월 4일 (UTC)[응답]
    • 음, 이건 빌리지 펌프(프로포즈)인데, 당신이 프로포즈를 하지 않는다고 주장해서 탈출한 것 같아.어쨌든, 여러분과 동의하는 사람들에게 "!투표"를 가리키지 않으면서 나에게 말을 하기보다는 솔직하게 내 의견에 감사하지 않는다고 말하라.나는 우리가 "그런 템플릿"을 가지고 움직여야 한다고 생각하지 않는다.크리스 트라우트먼 (대화)20:54, 2016년 3월 5일 (UTC)[응답]
• 현재로서는 이 특정 구현에 반대하지만, 기본적인 아이디어는 위의 모든 의견과 응답에 따라 실행 가능하다.지금 당장은 페이지에 필요한 기능을 추가해야 해.제안된 템플릿은, 언급된 바와 같이, 그것이 호출할 템플릿이 필요하지 않거나 제대로 사용되지 않을 때 문제가 있기 때문에, 그것들은 디폴트에 의해 실행될 수 없지만, 기본적으로 실행 중지되도록 하는 것은 우리에게 필요한 페이지에서 실행되지 않기 때문에, 이것들을 위한 템플릿이 없는 것과 정확히 같은 위치에 놓이게 하기 때문에, 제안된 템플릿은 어떤 것도 단순화하지 않을 것이다.수작업으로 가능케 한다.대부분의 사용자 a)는 이러한 기능에 대해 알지도 못하며 b) 그들을 이해하는 데 어려움을 겪을 것이기 때문에, Wikidata로부터 자동 생성 자매 프로젝트 링크 등에 대한 일반적인 아이디어는 좋은 아이디어다.지금의 상황은 지금 이러기에는 너무 어설프다.아마도 이것은 이러한 문제를 가지고 있는 현존하는 템플릿에 포격을 가하는 대신에 오류를 발생시키지 않고, 쓸모없는 링크를 생성하지 않는 사용자 지정 코드로 실행될 수 있을 것이다. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ^ʌ ҅ ҅_ᴥ ҅ ҅ 17:49, 2016년 3월 4일 (UTC)[응답]
  • 나는 당신이 어떤 "중요 이행"을 반대한다고 생각하는지 모르지만, 나는 그것을 제안하지 않았다. 나는 질문을 했다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2016년 3월 4일 (UTC)[응답]
    • 나는 내 진술로 인해 더 가깝거나 다른 누군가가 혼란스러워할 것이라는 것에 극도로 회의적이다. 하지만 만약의 경우에 대비해서:나는 분명히 "이런 템플릿들을 하나의 템플릿으로 결합하려고 노력하라"는 것을 언급하고 있는데, 그것은 당신이 제안했던 이름이고, 그리고 본질적으로 당신 자신과 모순되는 것이며, 전기나 심지어 음악이나 크리켓과 같은 좁은 것들을 위해 유사한 결합의 다기능 캐릭터의 다른 주제 템플릿을 제안했다.WP를 참조하십시오.BLUGUZON, 그리고 "내가 명백한 것을 말하도록 강요할 것이다"라고 사람들을 오소리하지 마라. 특히 그들이 나중에 아이디어를 더 구체적으로 개발하는 것에 대한 지지를 표명할 때 그렇다. — SMc캔들리쉬 lish ¢ ≽^ʌ ⱷ ⱷ ⱷ ҅_ᴥ 05 05 05 05^ʌ 05 35 05:35 (UTC)[응답] 3월 21일
      • @SMC 캔들리시: 나를 믿지 않을 것 같지만, 당신은 혼란스러운 말을 했다.여기에 기여하는 모든 사람이 당신처럼 당신의 의견을 명확하게 보는 것은 아니므로, 보다 정중하고 위키피디아 정신으로 명확성을 요구하는 요청에 응답해 주기 바란다.마틴풀터(토크) 2016년 3월 22일 16시 55분 (UTC)[응답]
        • 그럴 만도 하다.내 말투는 내가 니트 틱으로 골머리를 앓고 있다고 느끼는 같은 편집자와의 이전의 상호작용을 바탕으로 한 것이었다.그 사람 역시 나에 대한 불만이 있을 것이고, 그것은 곧 무너질 것이다.우리의 상호작용은 지난 1년여 동안 건설적인 경우가 더 많았다.@Pigsonthewing::내 진술이 정말 헷갈렸다면 사과할게.아, 젠장, 어쨌든 사과할게, 오늘은 긴 하루였어. 짜증나.그리고 끝나려면 멀었어, 하하 — SMcC캔들리쉬 ☺ ☏ ≽^ʌ ≽ ⱷ ҅ ҅ ҅_ᴥ ҅ ҅ ҅ ҅ 17 17 17 17^ʌ 17 17 17 17:50, 2016년 3월 22일 (UTC)[응답하라]
• 여기에는 융통성이 없는 것 같다.고려하다{{Commons category}}- 마지막 섹션의 맨 위에 올라가야 한다. {{Authority control}}대조적으로 마지막 섹션의 끝을 향해 있지만 - 범주와 스텁 앞에 있다.위에서 언급되지 않은 많은 항목들이 이들 사이에 나타나야 한다 - 예를 들어 진정한 외부 링크(예: 템플릿으로 다루지 않는 항목){{Official website}}(), 상속 상자 및 내비게이션 상자.WP로의 변경은 다음과 같다.바닥글은 다음과 같은 표준화된 템플릿 이전에 필요할 수 있다.{{Biography footer}}도입되었다, 그러한 변화는 진정한 외부 링크, 계승 박스, 그리고 항해사들을 그 전에 갈 수 있게 할 것이다.{{Commons category}}, 또는 다음에{{Authority control}}.그런 변화는 없을 것 같다. --Redrose64 (토크) 21:42, 2016년 3월 4일 (UTC)[응답]
• 훌륭한 아이디어 - 그리고 쉽게 구현할 수 있는; 우리는 이미 Infobox와 비슷한 것을 하고 있다.나는 미래에 모든 기사가 자동으로 다른 위키링크가 존재하는 곳, 예를 들어 인용문, 위키다타, 커먼즈 등과 기사 내 링크를 가질 수 있을지 궁금하다. @피그손더윙. 열띤 지지/반대 토론을 원치 않는다면 이 토론을 마을 펌프(아이디어)로 옮겨볼 것을 제안한다. --Tom (LT) 08:53, 2016년 3월 5일 (UTC)[응답]
• 일단 반대하다.이것은 분명히 우리가 향하고 있는 방향이고 환영할 만한 발전이지만, 위키다타와 위키피디아가 함께 일하는 방식은 아직 준비가 되어 있지 않다.이것은 엄청난 발전이 될 것이고, 그렇게 많은 수의 기사를 초월하는 템플릿에 대한 압도적인 합의가 필요하다.이와 같은 표준화는 실제 표준인 것, 즉 권한 제어의 라이브러리 분류에 가장 적합한 것으로 보인다.– 피누서톱 (토크 ⋅ 기여) 21:20, 2016년 3월 5일 (UTC)[응답]
• 재미있는 아이디어일 수도 있지만, 나는 사람들이 둘 이상의 가능성을 가지고 있을 때 문제를 일으킬 {{크리터 발바닥}}과 같은 변형 아이디어는 마음에 들지 않는다.그리고 어떤 사람들은 위키다타와 다른 외부 저장소의 "공백"을 자동으로 "채우는" 옴니버스 템플릿에 의해 전체 기사가 생성되기를 바란다.아직 도착하지 않았어.앤드류 D. (대화) 08:37, 2016년 3월 6일 (UTC)[응답]
• 지지하다.Pigsonthewing과 Od Mishehu의 의견에 동의하십시오.위키다타에 있는 우리 자매 프로젝트 친구들의 도움을 통해 통일성과 표준화의 용이성을 높일 수 있는 좋은 방법.— Cirt (대화) 16:09, 2016년 3월 9일 (UTC)[응답]
• 반대하다. 제안이냐 아니냐 하는 것은 나에게 과도한 설계라는 인상을 주며 새로운 편집자들이 추상화 층을 추가함으로써 페이지가 어떻게 렌더링되는지를 이해하는데 장애물이 될 것이다.일반적으로, 나는 가능한 한 "항아리 안의 항아리"를 피해야 한다고 생각한다.KISS 원칙과 모든 것.제이슨 퀸 (토크) 2016년 3월 14일 (UTC) 17:37[응답]
  • 하나의 템플릿이 될 때 다섯 개의 템플릿을 갖는 것은 KISS 원칙을 명백히 위반하는 것으로 보인다.마틴풀터(토크) 2016년 3월 22일 16시 55분 (UTC)[응답]
• 위에 언급된 바와 같이, 너무 많은 기사에 대해 너무 융통성이 없고 부적절하다. 더욱이 이 시기에 위키다타 출품작들은 그들에 대한 시선이 너무 적고, 너무 쉽게 미묘한 반달리즘의 대상이 되어 어떤 기사 콘텐츠도 자동적으로 의존하게 된다.실제로 나는 이 때 {{공식 웹사이트}}와 같은 템플릿의 제소에 반대한다.DES 00:19, 2016년 3월 19일 (UTC)[응답]