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

소말리 맘,anti-sex 노예 제도 옹호자의 성격 암살.

서명되지 않은 템플릿에 대한 변경 제안

지금 바로 {{subst:unsigned} 템플릿(및 그 많은 형제 템플릿)을 배치하면 다음과 같은 것이 나온다.

여기 내 코멘트가 있다.— 예(대화 • 기여) 00:00, 2015년 2월 12일에 추가된 서명되지 않은 이전 의견

나는 이것을 다음과 같이 바꿀 것을 제안한다:

여기 내 코멘트가 있다.예(토크) 00:00, 2015년 2월 12일

이것은 모두 선의에 관한 것이다.누구나 가끔 틸드를 잊어버리는데, 왜 일상적인 얼간이들의 영구적인 기록이 있어야 하는가?그런 주홍글씨는 선의가 아니다.서명되지 않은 단어의 링크는 절대적으로 중요하지 않다.사인봇은 여러 번 잊어버리면 사용자의 토크 페이지에 글을 올리게 되며, 경험이 풍부한 위키피디아 사람들도 새로운 사용자에게 이 사실을 알려준다.그것이 없다면 최악의 일은 사인봇이 몇 개의 게시물에 서명을 더 하는 것인데, 이것은 문제가 되지 않는다.오이야르밥시 (대화) 03:00, 2015년 2월 13일 (UTC)[응답]

일반적으로 우리는 우리가 실수를 "수정"하고 있다 하더라도(서명은 생략하는 등), 그 변화를 만든 사람이 누구인지 오해할 수 있는 방식으로, 토크 페이지의 것들을 바꾸고 싶지 않다.서명되지 않은 템플릿은 기존의 코멘트가 서명되지 않은 것을 명시하여 코멘트의 어느 부분이 원본 포스터에 의해 작성되었는지, 어느 부분이 나중에 추가되었는지 쉽게 확인할 수 있도록 하고 있다. --Ahecht (TOKPAGE
) 03:40, 2015년 2월 13일 (UTC)[응답]

음, 2015년 2월 13일 (UTC) 05:45, (대화) 05:45 (UTC)[응답하라]라고 적은 쪽지를 붙일 수 있다.

• {{부호받지 않은}}}이(가) 위키백과에 정의된 일반적인 형식을 위반한다는 것은 내게는 좀 우스운 일이다.토크 페이지 지침#서명 취소—[[User ''USERNAME'']] ''TIMESTAMP OF EDIT'' (UTC)그러나 그것이 나와 몇몇 다른 사람들에게 적어도 나쁜 믿음을 나타내기 위해 나타나는 템플릿임에도 불구하고 사용되도록 권장된다.내가 훨씬 더 웃긴 것은 다음 섹션인 위키피디아에 관한 것이다.토크 페이지 가이드라인#sigclean 서명을 위조하려는 시도가 올바른 정보로 표준 양식으로 서명을 변경하는 방식으로 편집될 수 있음을 나타낸다(Sigclean).—{{subst:User USERNAME}} TIMESTAMP OF EDIT (UTC)) 또는 더 단순한 변종.그렇다면 서명되지 않은 템플릿을 모두 덤프하고 모든 상황에서 하나의 템플릿만으로 쉽게 만들면 어떨까?—{{U Technical 13}} (e • t • c)04:06, 2015년 2월 13일 (UTC)[응답하라]

나는 내가 여기서 이치를 따르는지 확신할 수 없고, 나는 몇 가지 공부를 했다.

1. 사용자 X가 게시물에 서명하는 것을 잊어버렸다.
2. 따라서 사용자 X는 사악하다.QED.

제발 나를 이해시켜 주세요.— Ke februaryr 19:22, 2015년 2월 13일 (UTC)[응답]

나는 여기서 수치심을 나타내는 배지는 보이지 않는다; 그것은 "서명되지 않은"이라는 연계된 단어를 읽음으로써 비난 효과를 갖는 것으로 첨가된 광택인 것 같다.서명에 대해 배우기 위해 사용자에게 서명의 필요성을 알리는 이중 기능을 제공하는 단순하고 중립적인 사실 진술로 읽었으며, 서명에 대해 알기 위해 정보 페이지로 보내기도 하며, 문맥상으로는 게시물이 사용자에 의한 것이 아님을 분명히 한다(사용자와 다른 모든 사람에 대한 중요한 설명).나는 많은 사용자들이 이 템플릿의 결과로 서명에 대해 배웠을 것이라고 확신한다.타임스탬프는 템플릿에서 제외되지 않는다(문서 참조).타임스탬프가 일반적으로 포함되지 않는다는 사실은 서명되지 않은 것을 너무 멍청하게 놓아 역사의 어떤 개정판이 올바른 개정인지 확신할 수 없게 하는 봇의 기능일 뿐이다.그 복잡성이 봇에 추가될 수 있다면, 나는 그것을 지지하겠지만, 템플릿의 변경은 필요 없다고 본다.--Fuhgetaboutit (대화) 19:38, 2015년 2월 13일 (UTC)[응답]

• 나는 또한 왜 누군가가 단순한 실수가 고쳐지는 것을 나쁜 믿음의 가정을 암시하는 것으로 인식하는지 어리둥절하다는 것을 발견한다.비블브록스 (대화) 20:46, 2015년 2월 13일 (UTC)[응답]

User:에서 변형을 사용할 수 있다.오이야르밥시의 제안:

여기 내 코멘트가 있다.p.p. 예(토크) 00:00, 2015년 2월 12일

이것은 일반적인 신호에 가깝지만, 행동을 명확히 하고 위키백과와의 연결을 유지한다.서명.(Per procurrationem 참조)Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 21:28, 2015년 2월 13일 (UTC)[응답]

모두에게 설명할 필요가 없다는 쪽지를 쓰는 게 낫겠어.P.p.는 라틴어 약칭으로도 잘 알려져 있지 않다.따라서 지정되지 않은 경우 사용자가 서명하거나 다른 편집자가 서명한 내 제안.오이야르밥시 (대화) 00:33, 2015년 2월 14일 (UTC)[응답]

혹시 모를 경우, 나의 제안에는 링크뿐만 아니라 약어 마크업("P.P"* 위에 마우스 포인터를 올려놓거나 소스 HTML 코드를 보십시오.)도 포함되어 있다.그리고 "P.P"는 그러한 경우에 사용할 수 있는 정확한 주석이다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 2015년 2월 15일 편집[응답]

나는 이 아이디어가 마음에 든다.불분명하든 아니든, 그것은 공간을 거의 차지하지 않는다."p.p."는 분명하지 않지만, 위키피디아는 하이퍼텍스트로서, 위키피디아와 연결될 것이다.서명, 여기서 라틴어 약어를 설명할 수 있다.경로(대화) 03:51, 2015년 2월 14일 (UTC)[응답]

나는 파토르처럼 마우스가 달린 p.p.를 좋아한다.왜 그랬는지 파헤치기보다는 간결하고 정확히 무엇을 했는지를 나타낸다.그러나 다음과 같은 것이 더 나을 수 있다.

여기 내 코멘트 블라 블라 블라 블라. --xyzq 예시 (토크) 00:00, 2015년 2월 12일

템플릿은 {{subst:ppsign 예}}의 형태를 취할 수 있었는데, 여기서 ~~~는 스푸핑을 방지하기 위해 코드에 의해 추가되었다(즉, 사용자:xyzq 대신 템플릿을 사용하는 사용자:qwerty) --사용자:씨요키(말씀) 12시 35분, 2015년 2월 16일 (UTC)[응답]

이 변경사항은 현재 사용 중인 서명되지 않은 모든 템플리트에 영향을 미치며, 따라서 많은 보관 페이지 등을 변경할 수 있다.또한, 이 제안은 자동 서명에 해당하므로 신규 사용자들은 서명하는 방법을 제대로 배우지 못할 것이다.그리고 나서, 일단 서명봇의 편집 한계치인 800을 넘어서면, 왜 그들의 서명이 더 이상 나타나지 않는지 궁금해 할 것이다.또한, 앞서 말했듯이, 그대로의 템플릿은 나쁜 믿음의 표시가 아니다.어떤 합리적인 사람이라면 경험 많은 사용자를 포함하여 사람들이 실수를 한다는 것을 이해할 것이고, 신입 사원을 상대로 그런 실수를 저지르지 않을 것이다.Per Kephir, 난 이해가 안 돼.베스넛 (대화) 08:15, 2015년 2월 14일 (UTC)[응답]

시그니처봇은 사용자가 반복적으로 서명을 하지 않으면 모두 사용자 토크 페이지에 공지사항을 올리기 때문에 알 수 있다.오이야르밥시 (대화) 09:00, 2015년 2월 14일 (UTC)[응답]

보관된 페이지를 이런 식으로 변경하면 아무런 해를 끼치지 않을 것이다; 그리고 그러한 페이지에 없는 템플릿을 변경한 많은 선례가 있다.우리는 이미 오토시깅을 사용하고 있다.Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 2015년 2월 15일 편집[응답]

내 경험상, 실제로 이 문제로 골머리를 앓는 소수의 사용자들은 돌아가서 서명을 추가하기만 하면 된다.나는 이 아이디어에 대해 어떤 실질적인 이득도 보이지 않는다. 솔직히 모든 것이 사소한 것 같고 중요하지 않은 것 같다.비블브록스 (대화) 23:13, 2015년 2월 15일 (UTC)[응답]

설명 요청

Wikipedia_talk에서 코멘트 요청이 있다.자동 실행#Request_for_Comment:_포함_AFC_acceptance, 자동 사용자 권한을 부여하기 위해 막대를 이동해야 하는지에 대한 의견과 의견을 요청한다.거기서 모든 논평이나 질문이나 아이디어를 내주십시오.- 맥매터 _(contrib)/ 20:41, 2015년 2월 16일 (UTC)[응답]

국제적으로 공인된 모든 테러 조직과 범죄 조직 및 유죄판결을 받은 범죄자에 대한 낮은 사례 유형.

WikiProject 태그의 작업관리 목록 대체

위키피디아 토크에는 다음과 같은 제안이 있다.위키프로젝트 위원회#제안: 변환된 작업관리 목록 허용 안 함.거기에 댓글 달아줘.프라임헌터 (대화) 23:51, 2015년 2월 18일 (UTC)[응답]

잠시 마지막 기회

내가 지난 몇 년 동안 보아온 바로 지금이야말로 아마도 당분간은 마지막 기회일 것이다. 아마도 우리는 증가하는 행정업무의 밀린 업무량을 어느 정도 줄일 수 있는 어떤 제안을 통과시킬 수 있을 것이다.우리는 최근 3, 4개의 표를 얻었는데, 사람들은 아마도 곧 반복하지 않을 것이다(여기서 보고 따라다니며, 따라다니고, 따라다니고, 따라다니고, 따라다니고, 따라다니고, 따라다니고, 따라다니며, 어쩌면 여기서도).나는 어느 쪽이든, 요즘 행해지고 있는 관리 관련 업무, 특히 악역 배우들(스팸퍼, 반달, 양말 등)과 관련된 업무, 그리고 그 문제를 어떻게 해결할 것인가에 관한 모든 제안들에 대한 증거를 듣고 싶다.나는 WP에 유망한 제안을 추가하는 것을 고려할 것이다.센트(CENT)는 아니지만, 지금은, 이것을 30일 동안 정리하는 것이 현명하지 않을 것 같기 때문이다.최근 백로그에 대한 논의를 위해, 여기서 Risker가 언급한 백로그를 참조하고, 최근 WP 대부분에서 "백로그"를 검색하십시오.예를 들어, 여기, 여기, 여기, 여기, 그리고 여기.11월 토론에서 나온 이 차트(위의 링크 중 하나)는 왜 그런 일이 발생하는지에 대한 설명을 위해 다음과 같은 도움이 될 수 있다.

	2008	2009	2010	2011	2012	2013	2014년 (1998년)
능동형 관리자	943	870	766	744	674	633	570
관리자 프로모션	201	121	78	52	28	34	21
관리자 소모(순간이 아닌 실제)	263	194	182	74	98	75	85

- 당크 (대화를 강요) 23:59, 2015년 2월 18일 (UTC)[응답하라]

P.S. 이 차트의 첫 번째 줄은 지난 두 달 동안 30개 이상의 편집 작업을 한 남아 있는 관리자 수를 측정한다.두 번째 라인은 그해 RfA를 통해 얻은 총액이며, 세 번째 라인은 그 해 손실된 총액이다.2014년 수치는 추정치였습니다. - Dank (Push to Talk) 01:52, 2015년 2월 19일 (UTC)[응답]

• 그동안 RfA 전체 문제에 큰 관심을 기울이지 않았지만, 과거보다 지금 관리 툴을 구하기가 훨씬 어려워진 게 내 인상이다.만약 지금 RfA를 신청한다면, 내 요청은 아마도 간단히 거절될 것이다.하지만 몇 년 전에 그랬다면 별 문제가 없었을 것이다.그것은 위키백과에 대한 충분한 경험이 없거나 위키백과의 핵심 정책에 대한 이해가 부족하거나 행동 문제의 이력이 있는 편집자들에게만 관리 도구가 거부되었기 때문이었다.편집자가 관리 도구를 신뢰할 수 없다는 것을 증명하지 않는 한, 관리자가 되는 것은 AWB, 롤백 또는 검토자 권한과 같은 도구에 대한 액세스와 마찬가지로 용서된 결론이어야 한다.—패릭스 (tc) 13:27, 2015년 2월 19일 (UTC)[응답]
  • 전적으로 동의한다.나는 RfA가 이제 네가 얼마나 많은 FA들을 양치기했는지에 대한 것이라고 생각한다.그것이 반달리즘과 싸우고 AfD의 합의를 이행하는 것과 관련이 있는 것은 결코 만족스럽게 설명되지 않았다. --Trovatore (대화) 21:31, 2015년 2월 19일 (UTC)[응답]
    • 나는 지금 두 개의 RfAs를 보고 있을 뿐, 거의 모든 질문은 신뢰와는 아무런 관계가 없으며 '별일'이 되어서는 안 될 어떤 것과 무관하다.모든 과정은 난해하고 드라마로 가득 차서 사람들은 그 과정을 거치는 것조차 꺼리게 된다.의미 없는 질문/답변 시련을 없애고, 다른 편집자가 지명자를 검토할 수 있도록 짧은 시간을 허용한 다음, 검토가 해당 지명자를 관리 도구로 신뢰할 수 없는 이유를 제시하지 않는 한 자동으로 지명자를 승진시키십시오.—패릭스 (t c) 22:33, 2015년 2월 19일 (UTC)[응답]
• 내 생각에, 이 문제를 해결할 수 있는 유일한 방법은, 행정관이 되기 쉽게 하는 것이다.왜 지역사회가 이 모든 불합리한 기대를 가지고 있는 것일까?공식적으로 다음과 같은 몇 가지 악명 높은 예가 있다.
  • 삭제: 유권자들은 종종 로그에 파란 링크 몇 개만 있거나, CSD의 기준에 따라 기사가 삭제되지 않았다는 사실에 근거하여 한 후보에 반대할 것이다.아니면, AFD와 함께, 가장 흔한 두 가지 불평은 그 후보가 몇몇 임의의 수의 AfDs에서 투표하지 않았거나, 혹은 그들의 너무 많은 투표들이 최종 결과와 일치하지 않았다는 것이다.내가 완벽해질 수 있기를 바라는 만큼, 나는 그렇지 않고, 다른 사람도 아니다.그래서 사람들은 CSD에서 실수를 할 것이다.기사가 때때로 둘 이상의 기준에 따라 합리적으로 삭제될 수 있다는 사실은 말할 것도 없다.예를 들어, NPPer는 A7에 해당한다는 기사를 볼 수 있고, 삭제 관리자는 이를 G11로 삭제할 수 있다.그러나, 만약 그 기사가 홍보용이고 동시에 그 대상의 공신력을 설명하지 않는다면, NPPer와 관리자 모두 옳았다.하지만, 일부 유권자들은, 때로는 누군가에 반대할 이유를 찾기 위한 절박감처럼 보이는 것에서, 그 이면의 전체 맥락을 알지도 못한 채, 그것을 반대할 명분으로 삼을 것이다.또는 AfD에서 개인의 투표 및/또는 임의의 참여 수준을 충족하지 못하는 것이 어떻게 합의점을 적절하게 판단하는 능력에 방해가 되는가?더욱 우스꽝스러운 것은 후보자가 AFD에 참여하는 데 관심이 거의 없거나 전혀 없는데도 일부에서는 AFD, 이 경우 AfD의 기여도가 부족하다는 이유로 반대할 것이라는 점이다!
  • 내용.이것은 가장 논란이 많은 이유들 중 하나여야 한다.일부 유권자들은 이 후보가 적어도 한 명, 두 명, 혹은 그 이상의 GA를 만들었고 때로는 FA까지 만들었을 것으로 예상하면서 콘텐츠에 대한 기대가 높다.나는 어떤 콘텐츠 경험은 유익하다고 생각하지만, 그것은 여전히 관리자들이 보통 하는 그라운드 관리 업무와는 직접적인 관계가 없다. (예를 들어, 상을 받은 풀을 키우지 않는 한 우리는 그 사람이 그라운드 관리인이 되는 것을 금지할 것인가?)더욱 아이러니하게도, 다작 콘텐츠 제작자가 RfA를 찌를 때, 일부 사람들은 그 사람이 너무 많은 콘텐츠 작업을 했고 더 많은 유지보수 작업을 해야 한다는 것을 근거로 반대할 것이다!
• 결론은?RfA를 통과하기 위해서는, 합격의 기회를 원한다면, 아주 다재다능하고, 실수를 한 적이 없거나 거의 하지 않는 것이 좋으며, 논란의 여지가 있는 발언을 한두 번 한 적이 없다고 해도 과언이 아니다.우리는 WP로 돌아갈 때가 되었다.빅딜 철학은 없다.가끔 몇 년 전만 해도 쉽게 합격했지만 NOTNOW에 낙제하는 후보들을 지지하고 싶은 마음이 들 때가 있다. --Biblioworm 00:54, 2015년 2월 20일 (UTC)[응답]
• 나는 사실 RFA가 의심의 여지없이 불쾌하지만, 사실 몇 년 전보다는 통과하기가 더 쉽다고 생각한다.사실 지명된 사람들의 역사적 비율에 대해서는 성공한다.진짜 문제는 공천이 너무 적다는 것인데, 아마 의지가 있는 후보들이 부족하기 때문일 것이다.2007년 408명, 512명이 낙선해 모두 920명, 2014년 22명만 승진했지만 공천 탈락(오케이, 예상보다 많음)이 40명에 불과해 1년 내내 62명의 유목민만 배출해 옛날에는 한 달 정도 가치가 있었다.2013년 34년 성공, 총 74명이 아닌 40명이 성공하였다.존보드 (대화) 04:57, 2015년 2월 22일 (UTC)[응답]
• 또 다른 문제는 RfAs에 성공한 많은 수의 비활동적인 관리자들이 있다는 것이다.GA/FA를 많이 만들면 RfA를 통과할 수 있는 좋은 기회가 주어지지만, 그렇다고 해서 밀린 일을 기꺼이 도울 수 있는 것은 아니다.한편 Solarra와 같은 사용자들은 밀린 로그 삭제 기계(RfA를 반대할 다른 좋은 이유들이 있지만 그녀는 다른 어떤 관리자도 그 일을 가장 많이 할 것이다)를 가지고 있다.만약 당신이 나에게 만약 우리가 정말로 더 많은 관리자를 얻고 싶다면, 나는 '더 관대해지는 것 – 관리자들이 실제로 그들의 도구를 사용하는 분야에서 자질을 찾고, 그다지 관리적이지 않은 분야에서 경험 부족을 바탕으로 반대파의 무게를 줄이려고 노력하는 것 – 그것은 '범행자'에 달려 있다고 생각한다.— 뮤지크애니멀 03:41, 2015년 2월 23일 (UTC)[응답]
• 나는 관리 견습/멘토링 시스템과 함께 입학에 대한 하위 기준 및 수습 기간을 제안한다.-맨드러스 ☎ 03:49, 2015년 2월 23일 (UTC)[응답]
• RfA에 변화를 제안하는 건 확실해 만약 당신이 어떤 일을 잘 해낸다면 그들은 당신에게 훌륭한 메달을 줄 거야ResMar 16:54, 2015년 2월 23일 (UTC)[응답]

태그가 지정된 최근 변경사항을 등록되지 않은 것으로 표시해야 하는가?

편집 필터에 의해 또는 구현될 때 봇에 의해 추가된 태그는 무엇보다도 특정 유형의 파괴 행위, 기타 부적절한 변화 또는 위키텍스트 실수 및 시각적 편집자 버그를 추적하는 데 매우 유용할 수 있다.태그는 Special:태그와 최근 변경 사항은 태그별로 필터링할 수 있다.그러나 언제 편집이 확인되었는지 알기는 어렵다. 페이지 기록을 로드하고 최신 버전이 아닐 때 수동으로 확인해야 한다.이것은 비효율적이지만 미디어위키의 고유 순찰 기능을 사용하여 개선할 수 있다.순찰 권한이 있는 사용자(현재, 자동 확인 사용자)의 경우, 등록되지 않은 태그 변경사항 옆에 빨간색 느낌표가 표시되며, diff를 클릭하면 [이 개정판을 순찰으로 표시] 버튼이 표시된다.순찰을 돌면 붉은 느낌표가 사라진다.롤백은 또한 편집 내용을 되돌리는 자동 순찰도 한다.최근의 변경사항은 등록되지 않은 편집으로 필터링할 수 있으므로, 이를 통해 어떤 편집이 처리되었는지, 그리고 여전히 확인이 필요한지 매우 쉽게 확인할 수 있었다.무시된 태그(예: 시각적 편집기, HHVM 등)의 목록이 있을 수 있으며, 이러한 태그는 등록되지 않은 것으로 표시될 필요가 없다.큰 어려움 없이 이행할 수 있는데, 이것이 우리가 원하는 것인가?세나리움(토크) 12시 45분, 2015년 2월 16일 (UTC)[응답]

리디렉션에서 리디렉션으로 확장된 페이지를 표시하는 방법에 대한 이 사전 논의의 후속 조치:새 페이지.거기서 지적했듯이 그렇게 하기는 어렵겠지만, 만약 그것들이 봇에 의해 태그가 된다면, 그들은 스페셜에 등록되지 않은 채로 나타날 수 있을 것이다.최근 변화들, 그리고 그들은 이런 방식으로 그곳으로 순찰될 수 있다.세나리움 (대화) 2015년 2월 16일 18:58, (UTC)[응답]

• 좋아, 리디렉션에서 확장된 페이지에 대해 이전 토론의 참가자에게 ping.@Swpb, Technical 13, Oiyarbepsy, MusicAnimal, This, and other, Nyttend, James500:@Ironholds, Andrew Davidson, PaleAqua, Od Mishehu, DGG, BethNaught 및 WhatamIdoing:이것이 이 아이디어에 대해 수용 가능한 구현처럼 보이는가? 만약 봇이나 편집필터가 이러한 편집에 태그를 지정한다면, 그것들은 단순히 '비간접적' 태그에 대한 필터링만으로 최근의 변경으로부터 패트롤될 수 있을 것이다.세나리움 (대화) 2015년 2월 20일 21:14 (UTC)[응답]
• 좋긴 한데, 이건 나보다 똑똑한 사람들에게 맡길게.오이야르밥시(토크) 22:24, 2015년 2월 20일 (UTC)[응답]
• 이 문제에 대한 충분한 해결책이 될지는 모르겠지만, 분명 좋은 출발이 될 것이다.나는 당장 어떤 단점도 생각할 수 없으니, 만약 그것이 충분히 쉽다면, 그것을 시도해 보자. DGG (토크) 23:48, 2015년 2월 20일 (UTC)[응답]
• 나는 이러한 '비간접적'이 스페셜에 등장하기를 원한다.새 페이지 및 특수:새 페이지Feed(피드)를 하지만 Special(특수)에서 강조 표시:최근 변화는 올바른 방향으로 나아가는 단계가 될 것이다.나는 이행 방법에 대해 불가지론적이다.—스왑^talk 13:46, 2015년 2월 23일 (UTC)[응답]
  • 미디어와키 상호운용성 표준을 충족시킬 수 있는 방법으로 실현 가능하지 않을 것이라고 생각한다.새 페이지하지만 적어도 그들은 순찰할 수 있었다.세나리움 (대화) 2015년 2월 23일 21:01, (UTC)[응답]

편집자의 접근성 개선 제안

나는 비교적 새로운 편집자여서 WP '집 뒤편'이 특히 사용자 친화적이지 않다는 것을 알게 되었다.나는 내가 좀 더 점진적으로 완화하기보다는 다소 벅찬 과제를 떠맡으며 깊은 끝에 뛰어들었다는 것을 알고 있으며, 이것이 내가 경험한 어려움의 일부를 강조해 주었다.하지만, 나는 나의 경험이 몇몇 문제 있는 분야를 부각시키는 역할을 한다고 생각한다.

나는 이것을 프로젝트 영역에서 키우려고 생각했지만, 이것들은 비활성화된 것 같아 보여서, 여기 있다.나는 모든 편집자들, 특히 새로운 편집자들이 '집 뒤편'의 모든 콘텐츠를 훨씬 더 쉽게 이용할 수 있게 만드는 세 가지가 비교적 간단하게 이루어질 수 있다고 생각한다.

1. 하인 출입구를 만들어라.내 말은, 모든 페이지에서 접속 가능한 '집 뒤편' 홈페이지는 로그인한 사용자들만을 위한 것일 수도 있지만, 그것은 정책 결정이다.로그인과 로그아웃 및 관련 옵션이 있는 상단을 가로지르거나 Wiki 지구본 아래에 있는 화면 왼쪽에 있는 옵션과 함께 있을 수 있다.이것들은 단지 제안일 뿐이다.
2. 집 뒤편 검색 상자.이것은 MOS 특정 검색창과 유사하지만 모든 '집 뒤편'을 다룰 것이다.이것은 페이지 상단의 로그인/로그아웃 줄에 위치할 수 있으며 로그인할 때 활성/시각이 될 수 있다.일반적으로 보면 뒷집 검색창은 헷갈릴 수 있다.
3. '집 뒤편'에서 재료를 식별하고 접근할 수 있는 보다 직관적인 방법을 만드십시오.실제로 이것은 '서번트 입구'에 편입될 가능성이 높다.책에는 (적어도) 두 가지 주요 정보 표 작성 방법이 있다: 목차 및 색인.전자는 기본적으로 정책, 지침, 에세이, 템플릿 등을 알파벳 순으로 나열한 계층적 지침과 같다.후자는 주요 단어 또는 개념과 하위 그룹을 중심으로 배열된 참조에 관한 모든 문서와 같은 기능적 또는 개념적 그룹을 제공할 것이다.또한, 문맥을 제공하고 접근성을 더욱 향상시키기 위해 항목에 주석을 달 수 있어야 한다.

내 생각은 로그인한 사용자들에게만 접근을 제한하는 것에 달려있지 않다.나는 그러한 '프로젝트'의 실제 견과류와 볼트를 어떻게 접근해야 하는지에 대해서는 거의 알지 못하지만 많은 기능성이 존재하는 것으로부터 쉽게 적응할 수 있다는 것을 인지하고 있다.신데렐라157 (토크) 2015년 2월 17일 (UTC) 10시 13분[응답]

@Redros64, 내 식당의 '집 뒤'라는 은유를 분명히 하자면, 나는 다른 사람들이 부르던 곳, 즉 주요 공간, 기사 공간이나 백과사전 영역에 없는 모든 문서와 페이지를 의미한다.나는 집 뒤편에 정책, 지침, 에세이, 템플릿 사용자 안내서, 튜토리얼 등과 같은 것들을 포함시킬 것이다.신데렐라157 (대화) 23:34, 2015년 2월 17일 (UTC)[응답하라]

음, 내가 이 게시물을 조사하는 첫 번째 눈에 띄는 것은 우리의 프로젝트 공간에는 콘텐츠 페이지가 없다는 것이다.WP:HOME은 비활성 위키피디아 주제로 이어지고, WP:Portal은 포털에 관한 것이고, WP:Main은 메인 페이지에 관한 것이고, WP:Content는 포털로 리디렉션된다.신데렐라가 제안하는 링크를 추가하기로 합의했다고 해도 링크할 페이지가 없다.나는 그러한 생각을 연결하기에 가장 좋은 장소는 위키백과라고 생각한다.핵심 정책과 가이드라인 페이지와 연계된 5개의 기둥.오이야르밥시 (대화) 21:20, 2015년 2월 17일 (UTC)[응답]

나의 제안은 하인의 입구나 사용자 홈이 사용자가 집 뒤쪽에서 WP를 더 쉽게 탐색할 수 있는 포털이 되어야 한다는 제안과 함께 3가지로 나뉘어져 있다.이것 또한 다른 것들을 가질 수 있지만 나는 이것을 그것의 주요 기능으로 보고 싶다.신데렐라157 (대화) 23:34, 2015년 2월 17일 (UTC)[응답하라]

범주에 대해 아십니까?위키백과 같은 위키백과 디렉토리 및 내용:정책 및 위키백과 목록:용어집?마찬가지로 특수:SpecialPages에는 많은 특수 페이지와 특수 페이지가 표시된다.AllMessages는 모든 위키백과 인터페이스 메시지를 보여준다.– 철학자 21:46, 2015년 2월 17일 (UTC)[응답]

고마워, 나는 이 페이지들 중 하나를 알고 있었어.나의 제안은 이 페이지를 어떻게 알게 되는가에 관한 것이다.게다가, 나의 제안은 이 개별 페이지들 중 어떤 페이지보다 더 포괄적이 되는 것에 대한 것이다.신데렐라157 (대화) 00:23, 2015년 2월 18일 (UTC)[응답]

• 나는 이것을 하기 위해 포탈을 만드는 것을 볼 수 있었고, 만약 누군가가 원한다면 그것을 그냥 만들 수 있을 것이라고 생각한다.비블브록스 (대화) 23:30, 2015년 2월 17일 (UTC)[응답]

그 말이 무슨 뜻인지 확실하지 않아? 특별한 허가가 필요 없다는 뜻인지 아니면 누군가 그 일을 맡을 능력이 있다는 뜻인지?이 문제를 여기서 해결하는 이유의 일부는 작업을 수행할 수 있는 나 자신의 역량의 한계(노하우)에 있다.또한, 그것이 효과적이 되려면 문이 보이는 곳에 있어야 할 것이다(내가 논의/제언한 바와 같이).나는 문을 두려면 아마도 어떤 종류의 허가나 특별한 접근이 필요할 것이라고 생각했다.신데렐라157 (대화) 00:41, 2015년 2월 18일 (UTC)[응답]

나는 신데렐라157이 말하는 것은 우리가 편집자들을 위해 (선택적으로) 2차 메인 페이지를 가져야 한다고 생각한다. 여기서 가장 일반적으로 사용되는 특수 페이지들이 카테고리로 구성되어 있다.모두 새로운 편집자가 쉽게 접근할 수 있도록 마을 펌프, 정책, 공지사항판 및 프로젝트 페이지와 연결되어야 한다.신데렐라가 권한을 가진 사람을 요구하는 이유는 그런 페이지는 경험이 많은 사용자가 만들어야 하고, 일단 만들어지면 '로그아웃' 링크 옆의 상단에 있는 링크를 통해 로그인한 모든 사용자가 쉽게 접근할 수 있어야 하기 때문이다.토니 탄⁹⁸ · 토크 02:18, 2015년 2월 18일 (UTC)[응답]

이것은 꽤 유사하다. 특히 두 번째 비트는 "내가 묻는 이유는..."이다. 예, "2차 메인 페이지"그것은 모든 편집자들을 위해 고안되었지만 특히 새로운 편집자들에게 도움이 될 것이다.나는 '빠른 링크'를 생각하고 있지만, 위키 페이지 전체를 포괄하는 것(기사 공간에서는 안 된다)도 생각하고 있다.나는 페이지 유형의 계층 구조에 기초하여 목차를 시각화하고 있는데, 이것은 개념적이며 여러 '개념'과 관련되기 때문에 (링크로서) 여러 번 나타나는 페이지를 포함할 수 있다.인덱싱은 더 넓은 개념의 특정 개념에 접근하기 위해 여러 수준을 사용할 것이다.나는 이것이 확장될 수 있는 정보 박스로 작동할 수 있을 것으로 예상한다.그러면 실제로 페이지를 떠나지 않고도 사용 가능한 정보(페이지)의 '전체' 범위를 볼 수 있게 된다.나는 이것을 좀 더 '시각적'이라고 묘사할 것이다.링크에는 그 용도와 한계가 있다.어떤 것이 가장 좋은지 추측해 보고, 그것이 막다른 길이라는 것을 깨닫기 전에 여러 링크(파쇄)를 따라갈 수도 있고, 당신은 뒤로 물러설 필요가 있다.더 많은 옵션 범위를 확인함으로써, 다단계 인덱스 구조로 인해 올바른 경로를 더 빨리 찾거나 심지어 더 직접적으로 올바른 페이지로 이동할 가능성을 높인다.신데렐라157 (대화) 03:58, 2015년 2월 18일 (UTC)[응답하라]

'포탈'이 필요하다고 말하는 모든 사람들을 위해...이미 하나 있는데, 사이드바에서 링크까지 되어 있어.비록 :) —DJ (대화 • 기여) 2015년 2월 18일 (UTC) 10:16, 18 (응답)

좋아, 그럼 포털이 있고 그게 그런 일들을 해내는데당신은 '어떻게' 정보를 얻고 페이지를 넘기 전에 한 단계 아래로 드릴다운해야 했다.인덱스 같은 것은 있지만 목차는 볼 수 없었다.내가 키운 검색 기능도 있다.신데렐라157 (토크) 21:58, 2015년 2월 18일 (UTC)[응답하라]

다른 네임스페이스는 (빠른 검색대가 아닌) 실제 검색 페이지로 가면 검색이 가능하지만, 이 모든 "후드 아래" 내용이 일반 보기에서는 다소 숨겨져 있다는 타당성을 제기한다.이것이 의도적인 방식으로, 우리는 일반적으로 관리적인 것을 일반 독자의 경험과 다소 별개의 것으로 유지하는 사실상의 정책을 취해 왔다(즉, 기사에서 프로젝트 페이지로 연결되는 링크는 억제되고 간헐적으로만 사용됨).긱스(토크) 17:02, 2015년 2월 25일 (UTC)[응답]

NPP 검토 구조

나는 사전 속도의 삭제 태그가 합의점을 얻지 못하는 것을 감안하여, NPP를 변경하여 검토자가 전적으로 그들의 검토 프로젝트가 될 수 있도록 할 것이다.AFC는 사용자가 기사를 검토 중인 것으로 표시하도록 허용한다. 이것이 내가 제안하는 것이다.

이점:

• 선택사항이기 때문에 시스템을 채택하지 않는 사람들을 방해하지 않을 것이다.
• 태그를 배치하기 전에 보다 세심한 조사 허용
• 숙련된 검토자 방향으로 NPP 이동
• 사용자 정의 검토 스크립트(AFC와 같은)에 대한 기사 분류로 확장 가능

예제 태그:

{{사용자:Unit388/초안 검토 Unit388}}

검토 중인 문서 최근에 만들어진 기사들은 기준을 유지하기 위해 순찰을 할 수 있다. 이 기사는 현재 Unit388(대화)에서 검토 중이다. 태그 위치: 02:57

사람을 바꾸는 것을 두려워하지 마라.Unit388 (대화) 02:57, 2015년 2월 8일 (UTC)[응답]

• NPP 프로세스에 이것이 다루기 위한 문제가 있었는가?찬양(대화) 03:44, 2015년 2월 8일 (UTC)[응답]

• 이전에 제안된 템플릿의 논의에서 제기된 문제를 반영하여, 이것이 필요한 이유는 무엇인가?우리는 이미 소프트웨어에서 필요한 지원을 기다리는 새롭고 활동적인 기사의 태깅을 방지하기 위해 CSD 템플릿에 대한 변경을 계획했다.이것은 나에게 서서히 관료주의로 보인다.더 나아가서기사를 전적으로 그들의 검토 프로젝트라고 하는 것은 WP를 약화시키려는 제안처럼 들린다.OWN. 여기서 내가 오해한 것이 아니라면, 이 제안에 대한 내 입장은 "아니오...그냥....아니"경로(대화) 06:40, 2015년 2월 8일 (UTC)[응답]
• 반대 이것은 불필요해 보인다.검토자가 (의미 있게) 저자와 개선사항에 대해 대화를 나누고 있다면(의미 있게) 다른 패트롤러와 관리자에 의해 논문의 여유를 주어야 한다.만약 검토자가 정말 진지하게 재작업에 임한다면, 그들은 그것을 사용자화하고 그것에 대해 저자와 함께 작업할 수 있고, 또는 만약 그것이 아주 적은 양의 작업이 필요하다면, 단지 그것에 꼬리표를 붙이지 말고 계속 일을 할 수 있다.그러나 거기에는 배타성이 포함되어 있지 않다.아니면 다시, 그냥 대화 페이지에 글을 올려서 상황이 정리되고 있다는 것을 말하시오.관리자는 삭제하기 전에 대화 페이지를 확인해야 하며, 삭제하지 않을 경우 대화 페이지를 삭제하러 갈 때 간단히 복원할 수 있다.나는 이 템플릿의 사용이 남용되거나 잘못 사용되었을 수도 있다는 것을 알 수 있었다.페리돈(토크) 13:25, 2015년 2월 8일 (UTC)[응답]

  메모해줘서 고마워.내 토크 페이지에 응답했어. -사용자:페리돈

+1. 페리돈의 '반대' 주장 지지. --사용자:씨요키 (말씀) 06:12, 2015년 2월 12일 (UTC)[응답]

유닛388은 위의 두 제안에 대한 지원을 위해 편집자를 선택적으로 할당하고 있다는 점에 유의해야 한다.결연한 19:36, 2015년 2월 8일 (UTC)[응답]

• 반대 분명히 위의 논의에 대한 무릎 떨림 반응은 WP를 위반하는 것처럼 보인다.사용자가 태그나 새롭고 불필요한 프로세스가 필요 없이 원하는 경우 소유할 수 있는 것이다.비블브록스 (대화) 2015년 2월 8일 (UTC) 19:42, 8 (응답)
• 반대 - 그러한 템플릿의 필요성 또는 유용성에 대한 사례가 만들어지지 않았다.나는 제안자가 더 이상 그러한 템플릿을 제안하기 전에 위키피디아와 NPP에 대해 더 많이 배울 것을 강력히 촉구한다.- MrX 19:48, 2015년 2월 8일 (UTC)[응답]
• 중립 - 나는 이 일에 해를 끼칠 것 같지 않다.나의 유일한 관심사는 "전적으로 그들의 검토 프로젝트가 될 언어"이다(강제적으로 추가됨) - 이것은 WP를 위반이다.위키피디아의 어떤 페이지도 전적으로 누구의 것이든 아니다.그러나, 나는 이 제안의 효과는 이미 잘 커버되어 있다고 생각한다.{{Under construction}}그걸 복제하는 게 무슨 소용인지 모르겠네그리고 특히 AfDs가 "내 지하실 웹 사업에서 이 기사를 삭제할 수 없다!검토중이라는 꼬리표가 붙었어!" 그리고 나는 이것이 그 문을 여는 것이 걱정된다.이반벡터 (대화) 15:38, 2015년 2월 9일 (UTC)[응답]
• 반대하라, 내가 생각하는 문제를 찾는 해결책이다.숨막힐 (대화) 11시 50분, 2015년 2월 16일 (UTC)[응답]
• 반대는 다른 '반대' 합리성과 일치하며, 제안자의 토크 페이지에 대한 다양한 논의. --쿠드풍 pungุผผึ ( ( ( ((토크) 21:04, 2015년 2월 25일 (UTC)[응답]

편집-이력 비교를 더욱 용이하게 함

이제 최신 편집이 아닌 편집을 비교하려면 두 버전을 표시한 후 다시 위로 스크롤해야 한다.때때로 이것은 긴 두루마리 입니다.'Compare this version(이 두 버전 비교)' 탭이 왼쪽을 따라 올라가면 간단히 클릭할 수 있지 않을까?Kdammers (대화) 13:22, 2015년 2월 24일 (UTC)[응답]

그러한 변화에는 두 가지 비용이 든다.개발 비용이 있으며, 사용자가 기능을 사용하든 사용하지 않든 모든 사용자가 화면 혼잡도를 증가시킨다는 측면에서 가시적인 비용이 적게 든다.상대적으로 적은 사용자들의 작은 혜택과 총 비용을 비교해서 나는 그것을 볼 수 없다.나는 "때로는 긴 두루마리"와 함께 사는 것을 추천하고 싶다.-맨드러스 인터뷰 13:44, 2015년 2월 24일 (UTC)[응답]

브라우저에서 위로 점프하는 홈 키가 있을 수 있다.프라임헌터 (토크) 2015년 2월 24일 (UTC) 14:06[응답]

사용자 시도:Equazcion/LiveDiffLink.js. --Fauzan^{✆ talk}_{✉ mail} 09:28, 2015년 2월 25일 (UTC)[응답]

감사합니다, 사용자:파우잔! --atlasawa (대화) 2015년 2월 25일 19:30, (UTC)[응답]

개발비에 대해서는 말할 수 없지만 특별히 어수선하다고는 보지 않는다.또한 "상대적으로 소수의 사용자" - 나는 잘 모르며, 당신이 알 수 있을지 의심스럽다.Kdammers (대화) 2015년 2월 25일 (UTC) 12:00[응답]

잡동사니 문제는 옵트인 기기로서 극복할 수 있다.SD0001 (대화) 12:24, 2015년 2월 26일 (UTC)[응답]

또한, 라디오 버튼이 한 줄로 늘어선 것이 더 바람직할 것이다. 나는 오래된 것과 새로운 것을 수정하기 위한 것, 두 개를 갖는 논리는 이해할 수 없다. 이렇게 하면 시간을 절약하면서 잡동사니도 줄일 수 있다. --Fauzan^{✆ talk}_{✉ mail} 14:45, 2015년 2월 26일 (UTC)[응답]

기술적인 이유로 라디오 버튼의 두 열이 있는데, 그 페이지는 HTML 양식이며, 그룹 내에서 하나의 라디오 버튼만 선택할 수 있다.수정본을 비교하려면 기존 수정본과 새 수정본을 선택해야 하기 때문에 두 개의 단추 그룹이 필요하다.파토르 (대화) 22시 20분, 2015년 2월 26일 (UTC)[응답]

그건 바보 같은 짓이었어.라디오 버튼 두 세트 완성이 가능할까? --Fauzan^{✆ talk}_{✉ mail} 02:36, 2015년 2월 27일 (UTC)[응답하라]

무슨 말인지 모르겠다. 그 페이지에는 두 세트가 다 들어 있다.한쪽을 선택한 후 JavaScript에 의해 일관성 없는 선택이 숨겨진다.JavaScript를 비활성화하면 두 개의 완전한 라디오 버튼 세트가 있다.만약 당신이 더 이른 시간안에 "Later" revision을 선택한다면, 서버는 심지어 "Backwards" diff를 생성할 것이다.파토르 (대화) 02:46, 2015년 2월 27일 (UTC)[응답]

이미지에서, 만약 내가 표시된 편집본을 선택해야 한다면, 우선 오른쪽 라디오 버튼 선택을 새로운 표시된 수정본으로 가져와야 하고, 왼쪽 라디오 버튼 선택을 이전 표시된 수정본으로 가져와야 한다.대신 각 개정판에 선택 범위 안에 있는지 여부와 상관없이 라디오 버튼이 2개였다면, 나는 왼쪽 라디오 슬라이스를 새로운 표시된 개정판에 가져다 놓았을 것이다. --Fauzan^{✆ talk}_{✉ mail} 06:45, 2015년 2월 27일 (UTC)[응답]

옵트인 기기로서 지원 - 나는 이 잡동사니가 사람들에게 문제가 될 수 있다는 것에 동의하지만, 사용자:Equazcion/LiveDiffLink.js는 아마도 그것을 일반적으로 사용할 수 있도록 하는 것을 정당화하기에 충분한 사용자들에게 매우 좋은 아이디어일 것이다.עוד מישהו Od Mishehu 13:56, 26 February 2015 (UTC)[reply]

막힘/차단 방지 기능을 최대 5년 간 블록/차단 기간으로 교체

AfD 자동 알림

삭제 규정에 따르면, 이해관계자에게 통지하는 절차는 WP의 조건에 의해 제한된다.COVER는 이미 경기에 피부색이 있는 지명 편집자에게 부담을 지우고, 옹호해야 할 POV를 선언했다.나는 이 과정이 자동화되도록 제안하고 싶다.또한, 주제에 대해 정통한 사람들로부터 의견을 얻기 위해, 위키백과 주체가 기사의 주체로 식별되는 경우, 그러한 프로젝트도 마찬가지로 통지되어야 한다.

• 제안 1: 문제의 기사를 편집한 모든 개인에게 중립적이고 일반적인 메시지를 자동으로 발송하도록 BOT를 요청해야 한다.

이전에 편집한 ""NAME OF IRGENT""가 삭제 후보로 지명되었다."LINK TO DEBROGURING"에서 코멘트를 받으십시오.

• 제안 2: 문제의 기사와 관련된 모든 위키백과 주제의 토크 페이지에 중립적이고 일반적인 메시지를 자동으로 발송하도록 BOT를 요청해야 한다.

이 위키백과 제목과 연관될 수 있는 ""NAME OF IRK""가 삭제 후보로 지명되었다."LINK TO DEBROGURING"에서 코멘트를 받으십시오.

이 프로세스를 자동화하면 통지에 대한 잠재적 편향이나 의견 조사, 고의 또는 고의성이 없어진다.동시에, 각 AfD에 대해 관심 있는 사람들에게 통지함으로써 각 AfD의 논의를 개선시킬 것이라고 상정하는 것이 타당하다.이 과정은 다른 "삭제용" 또는 완곡하게 "토론용" 상황으로 이어져야 한다.Trackinfo (대화) 2015년 2월 23일 (UTC) 19:46, 응답

재미있는 생각이야.첫 번째 제안에서, 나는 그러한 봇이 페이지를 일부 비마이너 편집한 사용자에게 통지하도록 제한하고, 많은 페이지에 걸쳐 위키피디아 작업을 자주 하는 사용자의 잡음을 제거하도록 제한하고, 또는 옵트아웃 기능을 제한할 것을 제안한다.두번째로, 위키피디아 제목에 대한 메시지를 어디에 게시해야 하는지가 항상 명확하지는 않지만, 많은 사람들은 어쨌든 페이지가 삭제 태그가 되면 자동적으로 참가자들에게 알리는 그들만의 감시 목록을 가지고 있다. 그래서 그것은 엉망이 될 수도 있다.이반벡터 (대화) 2015년 2월 23일 (UTC) 21:45 [응답]

나는 위키피디아 작품을 걸러내는 BOT의 기술적 능력을 모른다.할 수 있다면 확실히 좋은 목표다.반면에 이해당사자는 기사가 이미 정확하거나 추가할 것이 없는 경우에만 철자를 수정할 수 있으므로 편집 크기가 적절한 요소가 아닐 수 있다.그리고 확실히 BOT에 대한 메시지를 삭제하는 것이 타당할 것이다.자동화된 워치리스트에 대해서는; 나는 내가 관여하고 있는 위키피디아에서 그런 메시지를 본 적이 없다.아마도 다양한 위키백과들에게 그것을 어떻게 하는지에 대한 더 나은 지침이 필요할 것이다.반대로 몇 년 전만 해도 엄청난 BLP 단속이 진행되고 있을 때, 나는 말 그대로 수작업으로 출처를 추가할 수 있는 수천 개의 기사를 찾아야만 했다.우리 가운데에는 많은 콘텐츠가 소실되는 연속 카피비오 에디터도 있었다.나는 문제가 있는 모든 기사를 찾았다고 확신할 수 없고 내가 나중에 잃어버린 중요한 기사들을 삭제하게 된 원인이 무엇이었는지 확인할 수 없다.가장 가능성이 높은 공격의 대상이 되는 어린 기사들은 심지어 위키피디아 주제의 영역으로 식별되지 않을 수도 있다.아마도 AfD 토론에서 편집자들이 BOTs의 관심을 끌 수 있는 수작업 과정이 있어야 할 것이다.그 제안과 함께 나의 목표는 프로세스를 자동화하고 중립적인 언어를 사용함으로써 POV 지향적인 캠페인의 잠재력을 무력화하는 것이다.Trackinfo (talk) 23:05, 2015년 2월 23일 (UTC)[응답]

내가 잘 아는 프로젝트 감시자 중 하나는 위키백과다.위키프로젝트 비즈니스/회계 태스크포스/기사 경고 - 그 페이지는 AAlertBot에 의해 정기적으로 업데이트되며, 나는 그것을 지켜보며 나의 감시 목록에 변화가 나타나도록 한다.불행히도 이번 것은 특별히 활동적이지 않다.유사한 봇이 프로젝트 기사 알림에 추가하지 않고 사용자 토크 페이지에 공지사항을 게시하면 XfDs에 대한 개별 통지가 있을 것이라고 생각하지만, 나는 잘 모르겠다.이반벡터 (대화) 06:12, 2015년 2월 25일 (UTC)[응답]

스팸 메일은 거부하십시오.

다른 사람에게 알리려면 다음을 수행하십시오.

1. AfD는 (WP의 하위 페이지 대신) 해당 기사의 하위 페이지로 지명된다.AFD) 2,) XFD용으로 지명된 페이지의 제목이 있고, 워치리스트에 빨간색으로 표시됨. 3.) 시스템이 자동으로 관련 XFD를 내 워치리스트에 추가하도록 하고, 4.) 물론 "옵션"을 선택할 수 있는 기본 설정 옵션이 있다.

위의 내용은 통지가 크게 개선되고, 공감대를 더 잘 형성하며, 관료주의를 조금이라도 더 많이 돕는 데 도움이 될 것이다.

구현하려면 소프트웨어 업데이트가 약간 필요하며(특히 하위 페이지 이름이 표준화된 경우) 현재 AfD를 가리키고 있는 몇 가지 템플릿과 봇을 업데이트해야 한다(UTC(Unterple) [응답]

만약 편집자가 그 기사를 적극적으로 보고 있다면, 사람들은 그들이 그 활동을 눈치챌 것이라고 추측할 수 있을 것이다.나는 또한 AfD 하의 기사의 빨간 하이라이트를 좋아한다. 왜냐하면 일단 초기 포스트가 만들어지면 일어나는 일의 중요성을 가릴 수 있는 기사에 사소한 활동(파리를 유혹하는 것 같은 것)이 빈번히 일어나기 때문이다.물론, 모든 사람이 편집하는 모든 기사를 보기 위해 클릭하거나(분명히 나는 안 본다), 심지어 어떤 규칙적으로 그들의 감시 목록을 반드시 감시하지는 않는다.스팸이라는 개념으로, 대부분의 봇들은 이미 "옵션 아웃" 기능을 가지고 있지 않은가?그것은 대화량이 많은 사용자나 의도적으로 신경 쓰지 않는 사용자들을 포함하기에 합리적인 선택일 것이다.그러한 상황에서는 아마도 모든 BOT 통신에 대해 "BOT 없음"이라고 말하는 도매적인 수단이 있어야 한다(또는 이미 존재한다).Trackinfo (talk) 01:11, 2015년 2월 24일 (UTC)[응답]

나는 Jc37의 생각을 좋아하지만, 더 나아가 <10 비"봇"과 비"미니어" 편집자"의 기사의 모든 편집자와 <100 비봇 편집자"의 편집자는 Trackinfo의 제안 선에 따라 통지해야 한다고 제안하고 싶다.– 철학자^{Let us reason together.} 00:43, 2015년 2월 24일 (UTC)[응답]

#2까지는 User를 살펴보십시오.Anomie/링크 분류기.삭제/토론 태그가 지정된 페이지를 포함하여 다양한 방법으로 링크를 강조 표시할 수 있는 스크립트 입니다.이반벡터 (대화) 01:03, 2015년 2월 24일 (UTC)[응답]

이반벡터, 네 제안 고마워.너의 발언은 마치 해결책인 것처럼 대화가 끊긴 것 같다.위키피디아에 종사하는 사람들에게 그들의 관심사를 감시하는 것을 돕는 것은 확실히 좋은 제안이다.그것은 여기서 주요 이슈가 아니다.모두가 모든 것을 지켜봤다면, 우리는 문제가 없을 것이다.그러나 사람들은 항상, 특히 경험이 적은 편집자들은 아니다.그리고 AfD가 발생하고 있다는 것을 알아차리는 것은 문제의 기사에 대한 관련 없는 편집에 의해 가려질 수 있다.수동 통지는 탐문 조사로 간주될 수 있으며, 그래서 내가 자동 통보 시스템을 제안하는 이유는 POV가 공정하고 보편적이며 부재하기 때문이다.Trackinfo (talk) 23:06, 2015년 2월 24일 (UTC)[응답]

내 코멘트는 대화를 끊으려는 것이 아니라 단지 관련 도구에 대해 알려주기 위한 것이었다. 기본 구성을 변경하지 않는 한, 링크가 빨간색 대신 보라색이라는 점을 제외하면, 말 그대로 jc37이 제안한 것과 정확히 2부 역할을 한다.당신의 원래 제안의 요점은 정확히 아니지만, 가끔 여기서 그런 일이 일어나기도 한다.이반벡터 (대화) 06:03, 2015년 2월 25일 (UTC)[응답]

1,000자 이상의 추가 또는 제거된 모든 편집을 사용자에게 알리는 것은 어떨까?오이야르밥시 (대화) 05:00, 2015년 2월 25일 (UTC)[응답]

사용자가 자신의 알림 임계값을 결정하도록 하는 것은 어떨까?예를 들어, 소문자 sigmabot III와 다른 몇몇은 토크 페이지 태그를 통한 사용자 수준 구성을 가지고 있다.이반벡터 (대화) 06:17, 2015년 2월 25일 (UTC)[응답]

이러한 설정을 찾을 수 있고, 많은 양의 대화 페이지를 가질 가능성이 있는 숙련된 편집자들에게, 나는 이러한 제안들이 적절하다고 생각한다.대부분의 편집자들에게, 한 가지 대화 메시지는 그렇게 귀찮지 않다.우리는 이미 특정 종류의 오타나 포맷 오류에 대한 자동 메시지를 받는다.AFD와 다른 삭제 제안서는 기사의 전 생애를 포함한다.조금 더 심각하다.1,000자를 삭제하면, 누락된 내용을 대체하기 위해 다시 돌아가야 할 이력이 있다.내가 보는 페이지 중에서, 나는 어디선가 어떤 바보 같은 사람이 전체 기사를 지우지 않고는 이틀이 지나갈 것 같지 않다.몇 번의 클릭으로 복구되었다.삭제된 기사로, 그 전체 내용은 의도적으로 권한에 의해 없어진다.역사는 없어졌다(관리자 제외).그리고 그것은 복구에 반대하는 합의된 결정과 반대되는 블랙 마크를 가지고 있다.그래서 만약 그 기사가 삭제될 자격이 있다면, 그 중요한 합의 결정에는 그 주제에 대해 아는 사람들이 포함되어야 하지 않을까?내용을 검토하고 추가 또는 삭제하는 주체가 충분히 중요하다고 느낀 사람이 바로 그러한 사람들일 것이다.Trackinfo (대화) 08:53, 2015년 2월 25일 (UTC)[응답]

TfD와 관련해 관련 논의가 있었다.WP를 사용하여 후보작을 감시 목록에 추가적으로 표시하거나 WP를 사용하여 다음 작업을 수행하십시오.통지는 다른 옵션일 수 있지만 소프트웨어 변경이 필요할 수 있다. 2015년 2월 25일 (UTC) 여기 링크:위키백과 대화:토론용 템플릿/아카이브 14#주요 편집자에게 삭제 통지를 의무화.다른 관련 토론도 있지만 템플릿이 여러 페이지에 영향을 미친다는 사실 때문에 복잡하고, 합병 논의도 TfD에서 이뤄진다.몇 가지 예:위키백과 대화:토론 템플릿#TfD.2용 Twinkle 사용에 관한 질의FTFMs, 위키백과:Billage pump (proposal)/Archive 118#Better watch list 옵션 및 Wikipedia:마을 펌프(정책)/아카이브 117#토목 변경 15:22, 2015년 2월 25일 (UTC) 15:41, 2015년 2월 25일 (UTC)[응답]

• 우선, 이것은 영구적인 제안이며, 사실 여기 WP에서 이 제안이 들어온다.페렌:

===모든 저자는 삭제 통지를 받아야 한다.====

• 제안:첫 번째 제작자 또는 기사에 기여한 모든 사람은 해당 기사에 대한 삭제 토론의 토크를 통해 경고를 받아야 한다.
• 이전 거부 이유:과도한 관료주의; 사람들은 그들에게 중요한 페이지를 그들의 감시 목록에 올려놓기를 기대한다.많은 기사에 있어서 "첫 번째 창작자"는 의미가 없다. 왜냐하면 이 사람은 떠난 지 오래되었거나 거의 기고하지 않았기 때문이다. "모든 사람"은 그 기사에 사소한 수정을 하고 삭제 여부에 대해 걱정하지 않는 사람들을 포함하여 수백 명을 헤아릴 수 있다.그럼에도 불구하고, 편집자들은 그들의 기사가 삭제될 때, 정중한 것으로 여겨지기 때문에, 원저자나 주요 기고자에게 이 사실을 알리도록 권장된다. 이것은 엄밀히 말하면 선택 사항이다.이는 모든 주요 기여자에게 통지해야 하는 특집 기사 검토보다 삭제 제안에 대한 요구사항이 적다.

나는 7년 전 사소한 편집으로 만든 어떤 장인이 삭제될 때 통지를 받고 싶지 않다.내가 신경쓰는 거라면 이미 내 감시 목록에 있어.이것은 불필요한 WP:CREP가 사람들을 짜증나게 할 것이다.만약 사람들이 실제로 이것을 원한다면 봇이나 그 어떤 것이든 그것은 전적으로 옵트인 기준으로만 엄격하게 작동해야 한다.비블브록스 (대화) 21:14, 2015년 2월 28일 (UTC)[응답]

자동 검사된 사용자 그룹 삭제

사용자 권한: CSD Patroller

이 권한을 가진 숙련된 사용자가 CSD 태그가 부착된 페이지를 삭제할 수 있고, 이의제기에 성공한 후에 CSD 태그를 제거할 수 있는 새로운 권한이 될 것이다.태그를 지정하지 않은 내용만 삭제할 수 있다.CSD 지침은 매우 명확한 컷이며 페이지를 삭제하는 데 관리자 지식이 필요하지 않다.이는 XFD에 영향을 미치지 않는다.
이 권리는 WP에서 부여될 것이다.RFR과 나는 최소 요건이 다음과 같을 것을 제안한다.

• 3000 편집
• 굿 히스토리
• 모든 CSD 가이드라인에 대한 지식
• 반달리즘이 무엇인지 아닌지에 대한 지식

만약 의심스러운 점이 있다면, 관리자가 할 수 있도록 패트롤러가 그 사건을 맡아야 한다.이 권리는 CSD 영역에서 일하는 관리자들의 압력을 크게 받을 것이다.모든 삭제는 관리자가 취소할 수 있도록 허용된다.그러나 이러한 상황은 정기적으로 발생해서는 안 된다.모든 사용자가 신뢰할 수 있고 지식이 있어야 하기 때문이다.The MagikCow (토크) 2015년 2월 28일 (UTC) 13:21 [응답]

지원(CSD 패트롤러)

1. TheMagikCow 지원 (토크) 17:52, 2015년 2월 28일 (UTC)[응답]
2. 지원, 기술적으로 실현 가능한 경우.빠른 삭제 전화를 하기 위해 관리자 수준의 신뢰와 판단이 필요해서는 안 된다고 생각한다.WP:CSD는 토론이 시간 낭비일 정도로 명백하게 부적절한 페이지를 위한 것으로, 신속한 삭제가 논란이 되는 경우는 절대 없어야 한다.나는 SPI 사무원들을 위한 바(bar)와 자격 수준이 비슷할 것이라고 상상한다. 아마도 비슷한 훈련 과정을 가지고 있을 것이다.이반벡터 (대화) 15:36, 2015년 2월 28일 (UTC)[응답]
3. 지원- 그러나 그것은 꽤 모호한 지침인 A7을 제외해야 한다.또한 이 권리에 대한 요청이 승인 또는 거부 전에 일주일 동안 토론해야 하는 경우에도 도움이 될 것이다.대부분의 관리자들이 AfD를 떠나지 않거나 SPI에서 노는 것을 좋아하지 않는다는 점을 고려할 때, 나는 대부분의 관리자들이 모든 도구에 즉시 접속하여 관리 업무를 수행하는 방식이 사실 이상하다고 항상 생각해 왔지만, 이것은 몇 가지 밀린 업무들을 줄이는 데 도움이 되지 않을 것이다.EoRdE6^{(Come Talk to Me!)} 15:46, 2015년 3월 5일 (UTC)[응답]

반대(CSD 패트롤러)

1. 스피디 삭제에 강한 반대는 모두가 말하는 것만큼 명확하지 않다."불확실한 광고"란 무엇인가?"의의의 주장"이란 무엇인가?이것은 삭제 버튼을 누르기 전에 좋은 판단이 필요하다.또한, 빠른 삭제는 기록을 거의 남기지 않고, 너무 적은 사람들을 포함하기 때문에, 이것은 우리가 비관리자들에게 주어서는 안 되는 절대적 마지막이다.목격자가 많고 무슨 일이 일어나는지 기록을 남기는 그런 사용자 삭제 논의권을 보고 싶다.위키백과 읽기:왜 내가 스피디한 델레터를 싫어하는지 빨리 삭제하는 것은 감시를 덜 필요로 한다고 말하기 전에 말한다.오이야르밥시(토크) 17:21, 2015년 2월 28일 (UTC)[응답]
2. Incorect Incorect CSD 태그깅은 하루 종일 발생하며, 그 중 많은 태그는 이 사용자 권리를 쉽게 획득할 수 있는 사람들에 의해 이루어진다.삭제된 자료를 볼 능력이 없는 사람에게 삭제권을 부여하는 것도 바람직하지 않다.WMF는 그들이 RFA나 유사한 지역사회 조사 과정을 거치지 않는 한 삭제된 자료들을 경쟁하는 것을 허용하지 않을 것이다.따라서 그들이 자신의 결정을 검토할 방법은 없을 것이다.이것은 실질적인 이익 없이 행정의 밀린 일을 극적으로 증가시킬 수 있다.CSD는 만성적으로 밀린 것이 아니라, 우리는 이것이 필요하지 않으며, 우리에게 필요한 것은 더 많은 실제 관리자들이다.비블브록스 (대화) 17:54, 2015년 2월 28일 (UTC)[응답]
3. G11/A7 삭제를 반대하며, 실제로 기준을 충족하거나 충족하지 못할 수 있는 많은 수의 경계 태그가 있다.편집 횟수가 많은 사람에게 이것을 맡기는 것은 믿을 수 없다.페이지 삭제를 원하는 사용자는 표준 RFA 과정을 거쳐야 한다.나콘 17:57, 2015년 2월 28일 (UTC)[응답]
4. Antious Speed 삭제는 XFD만큼 민감한 분야로, 각 삭제에 대한 의미 있는 외부 검토 기회가 훨씬 적기 때문이다.빠른 삭제가 논란의 여지가 없어야 한다고 말하는 것만으로는 그렇게 할 수 없다.스피디스는 정기적으로 시비를 걸거나, 거절당하거나, 뒤집힌다.그리고 언제부터 신속한 삭제가 RFA ? 세나리움 (대화) 18:17, 2015년 2월 28일 (UTC)[응답]에서 이슈가 되지 않게 되었는가?
5. 반대한다. 우리는 꽤 숙련된 편집자들로부터조차 부정확한 빠른 삭제 태그를 엄청나게 많이 얻는다. 그리고 대부분의 빠른 삭제는 어떤 실수도 거의 없다.Hut 8.5 19:01, 2015년 2월 28일 (UTC)[응답]
6. 아니, 만성적인 밀린 업무는 없으니 버튼퍼는 더 이상 필요 없어새로운 사람을 위한 요리법.TenOfAllTraes(대화) 19:55, 2015년 2월 28일 (UTC)[응답]
7. 반대: 많은 양의 공구 세트를 재분배해야 함에도 불구하고, 이것은 선의로 하는 생산적인 방법이 아닌 것 같다.첫째, 기술적으로 타당하지 않다.둘째, 사용자에게 삭제 권한을 부여하려면 지명 및 투표 방식 검사 시스템(RfX와 유사하지만 반드시 RfX는 아님)이 필요하다.셋째, 이 사용자 그룹이 부정적인 그룹보다 전반적으로 더 큰 긍정적인 결과를 얻도록 요청하는 사람들(그리고 그 사람들이 누구일지)이 보이지 않는다.—{{U Technical 13}} (e • t • c)20:31, 2015년 2월 28일 (UTC)[응답하라]
8. 반대 - 누군가 페이지를 삭제함 + 관리자가 동의하지 않고 복구함 = 의견 불일치 및 논쟁, 아마도 전쟁을 편집함! - 기본적으로 가치 있는 것보다 더 문제임. –Davey2010^Talk 20:58, 2015년 2월 28일 (UTC)[응답]
9. 제안된 "vandal fighter" 사용자 권리와 같은 이유로 반대한다.이것은 잘못된 손에 넣으면 매우 위험할 수 있고, 불필요한 관료주의를 더하는 것이다.비판적으로 부적절한 페이지(BLP 우려, 저작권 등)는 이미 매우 신속하게 삭제되고, 나머지는 삭제와 같은 강력한 조치를 결정하기 위해 정책에 대한 관리자 지식이 필요할 수 있다.— 뮤지크애니멀 01:32, 2015년 3월 1일 (UTC)[응답]
10. 반대는 충분히 생각해본 것 같지 않다. --Cgt (대화) 13:15, 2015년 3월 1일 (UTC)[응답]
11. 반대 - 위의 대부분에 따른다.이것을 처음 내 워치리스트에서 보았을 때, 실제로 경험 많은 사용자들에게 CSD 태깅을 제한하는 새로운 사용자 그룹을 만들자는 제안이 될 것이라고 생각했다.미스터Z맨 17:59, 2015년 3월 1일 (UTC)[응답]
12. 그들에게 CSD 태그를 제거할 권리를 주는 것에 반대한다. 그들은 이미 그것을 가지고 있다.기사 작성자나 금지/차단되지 않은 모든 사람은 그러한 권리가 있다. (평등하게, 모든 사람은 그것들을 다시 넣을 권리가 있다...) '복원'이 그 의미라면, 그것은 삭제된 자료를 보는 것을 포함한다.많은 CSD는 명백하다 - 꽤 많은 것은 그렇지 않다.삭제된 페이지를 볼 수 있는 기능이 필요하기 때문에 G4에서 삭제할 수 없다.나는 또한 태그할 권리가 논의되는 것에 대해 궁금했지만, 생각해 보았다.순찰자들이 순찰권을 주기 위해 어떻게 경험을 쌓을 수 있을까?나는 또한 그들이 푸구를 준비하면서 연습생 요리사를 어떻게 평가하는지도 궁금했다 - 어떻게 평가자들은 그 안에 독이 들어 있지 않다는 것을 알 수 있을까?그러나 CSD는 fugu와 같지 않다.CSD에서의 죽음은 레스토랑에서의 죽음과 같지 않다.물품은 회복할 수 있다.그런데 삭제된 기사는 누가 확인할 것인가?누가 연습생 패트롤러를 평가해서 이 권한을 부여할 것인가?나조차도 개인 관리자들에게는 믿지 않을 거야...그리고 만약 그게 토론으로 간다면, 당신은 RfA에 거의 근접해 있을겁니다.자동 확인권처럼 자동 확인권이 될 수는 없다.페리돈 (토크) 2015년 3월 4일 (UTC) 10시 8분 / 응답
13. 반대 지역사회는 관리 도구의 포장을 풀려는 생각을 일관되게 거부해 왔다.관리자(admin)가 될 생각이 있으면 연락해서 도움을 요청하십시오. --dweller (대화) 12:50, 2015년 3월 4일 (UTC)[응답]
14. 반대한다. 또한 내가 "반달 권리" 제안서에서 말했듯이, 이러한 권한은 소수의 매우 신뢰할 수 있는 사용자만이 사용할 수 있는 관리자 권한이며, RfA 또는 Commons에 대한 라이선스 검토자와 유사한 공천과 투표를 요구할 것이다.이것은 불필요한 일을 너무 많이 야기할 것이다.에픽 지니어스 (토크) 17:16, 2015년 3월 4일 (UTC)[응답]
15. 반대한다. 만약 관리 도구 세트가 번들로 분리될 수 있다면 나는 이와 같은 것을 지지할 것이다. 그리고 나는 그렇게 하는 것이 좋을 것이라고 생각한다(대단히 단순화된 RFA 프로세스가 하나의 이익이 될 것이다), 그러나 그렇게 하려면 아마도 결코 일어나지 않을 많은 합의와 개발 작업(및 WMF 자금 지원)이 필요할 것이다.불행하게도 이것은 비스타 입니다.§FreeRangeFrog^croak 07:32, 2015년 3월 5일 (UTC)[응답]

토론(CSD 패트롤러)

• CSD가 (이론적으로) 흑백 기준이라는 점을 감안하면 나는 이 정도면 괜찮을 것이다.페이지가 기준을 충족하는지 아닌지는 분명해야 한다. 또는 CSD는 거절되어야 하고 그들은 다른 과정을 거쳐야 한다. 따라서 이러한 전화를 걸기 위해 관리자가 필요하지 않아야 한다.몇 가지 질문이 있다:

1. 특정 방법으로 태그가 지정된 페이지에 대해서만 삭제 권한을 가진 사용자 권한을 구현하는 것이 기술적으로 가능한가?
2. CSD Patroller는 삭제된 콘텐츠를 볼 수 있는가?삭제할 수 있는 콘텐츠만 삭제하거나 모든 콘텐츠를 삭제하시겠습니까?지나친 관점의 콘텐츠는 어떠세요?
   

그래 나는 그것이 가능하다고 믿는다.

아니오. 삭제된 콘텐츠나 지나치게 통찰력 있는 콘텐츠는 볼 수 없을 것이다.The MagikCow (talk) 14:08, 2015년 2월 28일 (UTC)[응답]

또한 단순한 의견: CSD Patrollers는 다른 사용자가 태그한 내용만 삭제해야 하며(일방적인 삭제는 안 됨), 물론 이 사용자 권한으로 사용자가 수행한 모든 조치의 로그가 있어야 한다.이반벡터 (대화) 13:55, 2015년 2월 28일 (UTC)[응답]

네, 위쪽을 보십시오.The MagikCow (talk) 14:08, 2015년 2월 28일 (UTC)[응답]

• 그런 '신뢰받는' 후보가 RFA를 통과하도록 하는 게 낫겠다.당신이 위에서 말한 요건은 거의 몇 년 전에 RFA에 출마하기 위해 필요한 것이다.장기적으로는 RFA의 바(bar)를 대폭 늘릴 것이다.("CSD Patroller 비트만 사용할 수 있는 자격이 있다. 몇 달 후에 돌아와" 일종의 논쟁)누군가를 신뢰한다면, 그들에게 sysop 비트를 줘라, 나는 "반쪽 신뢰"와 "완전히 신뢰하는" 사용자들을 상상할 수 없다. --Fauzan^{✆ talk}_{✉ mail} 14:04, 2015년 2월 28일 (UTC)[응답]

나는 이것이 RFA를 하는 많은 사용자들이 이 권한을 가질 것이고 5000개 이하의 편집본을 가진 사용자들은 거의 통과하지 못할 것이기 때문에 그 바를 올릴 것이라고 생각하지 않는다.ntheMagikCow (대화) 14:21, 2015년 2월 28일 (UTC)[응답하라]

5000개 정도 편집한 건 맞지만 RFA에 더 많은 사람들이 출마해야 한다고 생각해.이 우파는 길을 가다가 체크할 여분의 상자를 만들 것이고, RFA를 지금보다 더 멀리 떨어뜨릴 것이다.다시 말하지만, 신뢰할 수 있는 사용자들은 완전한 것을 얻어야 한다.여러 차례 삭제와 차단을 함께 시행하고, 절반 정도 작업을 하면 실제로 관리자의 업무량이 늘어난다. --Fauzan^{✆ talk}_{✉ mail} 14:45, 2015년 2월 28일 (UTC)[응답]

이것은 단지 차단과 페이지 삭제에 대한 관리자 기준 때문에 부결될 예정이지만, 나는 그것이 유용하다고 생각한다.내가 볼 수 있는 유일한 문제는 누군가가 고의로 불량하게 되어 양말 계정/IP에 태그를 적용하기로 결정한 다음 어떤 페이지라도 삭제할 수 있다면...대통령, 독재자, 언론 페이지 등그들도 빨리 하면 되니까 안 될 것 같아.Tutelary (대화) 14:53, 2015년 2월 28일 (UTC)[응답]

나는 CSD 기준이 명확하기 때문에 이것이 받아들여질 것이라고 믿는다.— TheMagikCow (대화 • 기여) 14:57, 2015년 2월 28일 (UTC)[응답]에 의해 추가된 이전의 서명되지 않은 논평

위키백과의 대화 페이지를 보십시오.신속한 삭제 기준 및 기록 보관.CSD 기준이 당신이 생각하는 것만큼 '명확한 컷'이 아니라는 것을 곧 알게 될 것이다.세나리움 (대화) 17:46, 2015년 3월 1일 (UTC)[응답]

• CSD 태그를 제거할 수 있다는 것은 모든 사람(기사의 작성자 제외)이 이미 그렇게 할 수 있기 때문이다.—라르고 플라조 (대화) 17:55, 2015년 2월 28일 (UTC)[응답]

• 나는 커뮤니티가 한 명의 관리자가 다른 사용자에게 어떤 것도 삭제할 수 있는 권한을 부여할 수 있도록 지원하는 시나리오를 상상할 수 없다.나도 삭제 능력은 있지만 삭제된 자료를 보거나 복구하는 능력은 없다는 것은 미친 짓이라고 생각한다.그래서 이 어설프고 촌뜨기 행정관들 중 한 명이 실수를 할 때마다 진짜 행정관이 와서 그들을 쫓아내야 할 것이다.실수가 매우 드물 것이라는 생각은 우스울 정도로 우스꽝스럽다.비블브록스 (대화) 18:02, 2015년 2월 28일 (UTC)[응답]

RFA 기준은 매우 광범위하고 일부 편집자는 매우 경험이 풍부하지만 한 주제인 TheMagikCow (talk) 18:11, 2015년 2월 28일 (UTC)[응답]에 불과하다.

나는 이 답변이 어떻게 나의 발언에 대한 반박인지 잘 모르겠다.최근에 한 가지 일을 잘한다면 자동적으로 다른 일을 할 수 있는 고급 권한을 부여받아야 한다는 생각에 근거한 제안이 쇄도하고 있는 것 같다고 덧붙인다.그것은 그렇게 작동하지 않는다.너는 네가 신청하는 것에 대해 너에게 잘할 수 있다는 것을 보여줄 수 있어야 한다.나 좀 봐.2009년부터 행정관으로 근무하고 있다.나는 2010년부터 감독팀에 있어왔다.나는 작년에 중재자였다.그러나 내가 WP에서 내 자신을 내세웠을 때 나는 지역사회에 의해 완전히 거절당했다.RFB. 그리고 그들이 옳았어.나는 그 일에 적합하지 않다.전직 Arb로서 나는 기본적으로 checkuser 권한을 가질 수 있지만 나는 기술 업무에 별로 관심이 없어서 그 일에 잘 맞지 않는다고 생각한다.삭제는 행정업무다.하고 싶으면 관리직에 출마하라.CSD는 대부분의 시간이 밀리지 않고, 당신이 뛰는 동안 일주일 정도 기다릴 수 있다.비블브록스 (대화) 21:27, 2015년 2월 28일 (UTC)[응답]

• 며칠 전의 코멘트에 대응: 물론 신속한 기준은 명확하다; 그렇지 않다면, 의심스러운 경우 신속한 삭제에 대한 합의가 없기 때문에 개정할 필요가 있다.CSD의 요점은 페이지를 삭제할 필요가 있다고 판단하기 위해 거의 판단이 필요하지 않다는 것이다."불확실한 광고"는 "이봐!내 멋진 회사인 어썸코! (링크)"의 웹사이트를 확인해 보십시오. 아무도 이것을 받아들일 수 없다고 생각하지 않을 겁니다.그러나 "2014년 설립된 아웨소메코는 네브래스카주 캠브리지에서 7번째로 큰 그래픽^[self-ref] 디자인 서비스 제공업체다.<>공식 웹 사이트template>, "-아주 아주 협의를 거쳐(얼마나 많은 그래픽 디자인 기업들이 1,063의 한 마을에 있었겠느냐?) 하지만 그것은 모호하지 않은 광고 삭제할, 의의(청구가 될 WP:N을 갖고 있지 않아 주장하기 있)의 믿을 만한 주장하지 않도록 편집자 결론을 내릴 가능성이 있다. 그거G11이나 A7 삭제는 적절하다.이 제안은 분명히 통과되지 않을 것이지만, 만약 우리가 너무 광범위한 망을 던져 빠른 삭제와 명확하지 않은 경우에 적용한다면, 우리는 그것을 다루어야 한다.이반벡터 (대화) 15:57, 2015년 3월 5일 (UTC)[응답]

영감을 주는 캠페인:다양성 개선, 콘텐츠 개선

이번 3월에는 위키미디어 프로젝트에서 성별 다양성 향상을 위한 새로운 아이디어를 장려하고 지원하기 위한 '인스파이어 캠페인'을 조직할 예정이다.위키미디어 기고자의 20% 미만이 여성이며, 우리의 콘텐츠에는 여전히 많은 중요한 주제가 빠져 있다.우리는 모든 위키미디안들이 참여하도록 초대한다.이 문제를 해결하는 데 도움이 될 만한 아이디어가 있다면 오늘 바로 참여하십시오!이 캠페인은 3월 31일까지 계속된다.

연구 프로젝트, 기술 솔루션, 커뮤니티 조직 및 홍보 이니셔티브, 또는 완전히 새로운 무언가를 제안하는 모든 제안은 환영한다!재정 지원이 필요한 프로젝트에 대해서는 위키미디어 재단에서 자금 지원을 받을 수 있다.아이디어에 대한 건설적이고 긍정적인 피드백이 감사하며, 여러분의 기술과 경험이 다른 누군가의 프로젝트를 되살리는데 도움을 줄 수 있다.인스파이어 캠페인에 참여하여 이 프로젝트가 전 세계의 지식을 더 잘 표현할 수 있도록 도와주십시오!미디어위키 메시지 전달(대화) 19:22, 2015년 3월 5일 (UTC)[응답]

사용자가 보낸 메시지:PEALY (WMF)@metawiki는 http://meta.wikimedia.org/w/index.php?title=User:PEarley_(WMF)/Inspire_Mass_Message_Manual/en&oldid=11468682에서 목록을 사용한다.

자동화된 시작 메시지

위키백과에는 카테고리가 있다:환영 위원회 및 카테고리의 위키백과:시작 템플릿.그 위키피디아 사람들과 그 템플릿들은 유용한 서비스를 제공한다.나는 위키피디아가 또한 새로운 계정이 등록되는 즉시 사용자 대화 페이지에 나타나는 자동화된 환영 메시지를 가질 것을 제안한다.등록 절차는 등록자에게 링크를 통해 환영 메시지로 안내하는 간단한 메시지로 끝날 수 있다.간단한 메시지는 "토크 페이지에 환영 메시지가 있다"일 수 있다.환영 메시지에는 일련의 유용한 링크가 있을 수 있다.미리 정해진 횟수의 편집 후, 편집자에게 유용한 링크에 대해 정중하게 상기시켜주는 다른 메시지가 사용자 대화 페이지에 나타날 수 있다.
—파장 (대화) 03:15, 2015년 3월 1일 (UTC)[응답]

새로운 편집자들은 인간들의 환영을 받아야 한다.이 인간들은 그들의 메시지를 새 편집자의 활동에 맞춰야 한다.수많은 위키피디아 계정들은 결코 편집을 하지 않으며, 편집하기 전까지는 환영을 받아서는 안 된다.오이야르밥시 (대화) 03:18, 2015년 3월 1일 (UTC)[응답]

그럴 경우 첫 번째 편집 직후에 첫 번째 환영 메시지가 나타날 수 있다.(계정을 편집에 사용한 적이 없더라도 여전히 감시 목록을 보관하는 데 사용될 수 있다.누가 얼마나 많은 계좌가 감시 목록을 보관하는 데만 사용되었는지 말할 수 있는가?환영 메시지는 편집에 동기를 부여할 수 있다.)

—파장 (대화) 06:05, 2015년 3월 1일 (UTC)[응답]

Yeah, Oiyarbepsy에 따르면 난 이걸 지지할 수 없어.나는 심지어 상기된 메시지의 요점조차 이해하지 못한다; 일반적으로 누군가 환영 템플릿에 나타나는 내용을 상기시켜야 한다면, 그것은 편집자의 행동에 대한 경고 신호다.// coldacid (talk concident) 05:06, 2015년 3월 1일 (UTC)[응답]

• 반대 - 바보처럼 들릴지 알지만 IMHO는 로봇이 아닌 실제 사람으로부터 하나를 받는 것이 더 기분이 좋다. 그들은 자동으로 하원에서 환영을 받고 있다. 그리고 여기와 비교했을 때 기분이 이상하다. 좋은 제안이다. –Davey2010^Talk 05:30, 2015년 3월 1일 (UTC)[응답]
• 반대 - 상당수의 신규 등록 계정에서 일반적인 오래된 반달심, 공격, 조작 및 일반적인 헛소리 페이지가 상당히 많이 설명된다.우리가 결코 원하지 않는 것은 그들을 환영하고 그들의 편집에 감사하는 것이다. 그들의 존재가 건설적일 것이라는 아주 좋은 생각이 들 때까지 말이다.어쨌든 이 토론은 오래된 영원한 주제다.이 시스템은 이미 신규등록을 순찰하고 환영회 등을 두드려 편집수를 늘리는 것 외에 할 일이 없는 사용자들에게 충분히 악용되고 있다. --쿠드풍 pungุดผผึ ( ( ( ( ((토크) 09:37, 2015년 3월 1일 (UTC)[응답]
• 논평 - Kudpyung이 언급했듯이, 이것은 영구적인 제안이다 - 위키백과:다년제안#봇을 사용하여 새 사용자를 환영하십시오.DH85868993 (대화) 10:14, 2015년 3월 1일 (UTC)[응답]
• 지원
  1. 인간에 의한 환영은 여전히 통조림이다, 적어도 내 것은 그랬다.유일한 차이점은 사용자 이름에 있으며, 새로운 사용자는 "Hi, I'm Civvix72"가 인간에게서 온 것이고 "Hi, I'm WelcomeBot"은 그렇지 않다고 판단할 수 없을 것이다.
  2. 어쨌든 나는 은행부터 신문, 포럼까지 웹사이트를 이용했고, 사이트 이용에 편안함을 느끼기 위해 인간의 즉각적인 환영이 필요했던 적은 없었다.사용법에 대해 쉽게 접근할 수 있는 정보가 필요했던 것.
  3. 나는 그들이 반달인지 건설적인 사용자인지 알기 전에 누군가를 환영하는 것에 문제가 없다.나는 반달에게 어떻게 참여해야 하는지에 대한 정보를 알려주는 것이 그들이 반달리즘을 일으킬 가능성을 증가시키는지를 보지 못했다.어떤 경우에는, 그리고 얼마나 많은지 누가 알 수 있는지, 환영 템플릿이 잠재적 파괴자를 괜찮은 편집자로 변환할 수도 있다.만약 그들에게 너무 일찍 감사하는 것이 문제라면, 좋아.그들에게 조급하게 감사하지 마라.
  4. 나는 끊임없는 제안의 주장을 계속 거부한다.사람들이 떠나고 합류하면서 그 공동체는 계속해서 리메이크되고 있는데, 시간이 지남에 따라 그 판단이 변하지 않을 것이라고 보는 것은 비논리적이고 현명하지 못하다.만약 누군가가 공정한 수준의 참여와 결과적인 합의를 이끌어내는 최근의 토론을 지적할 수 있다면, 그것은 한 가지다; 그것들이 "매년"으로 태그가 붙었기 때문에 결코 재고될 수 없는 것들의 목록은 전혀 다른 것이다.-맨드러스 ▷인터뷰 10시 40분, 2015년 3월 1일 (UTC)[응답]

맨드러스, 인간에 의한 환영은 통조림 템플릿이 될 필요가 없고, 통조림 템플릿이 될 수도 있다.내 생각에, 자주 오는 환영객들은 그들이 얼간이가 아니라면, 그들의 성격을 반영하는 개인적인 환영 메시지를 처음부터 써야 한다.오이야르밥시(토크) 19:52, 2015년 3월 3일 (UTC)[응답하라]

Tanx는 설명을 위해.나는 그 점에 대해서는 확신이 없어서 하마터면 빠뜨릴 뻔했다.2, 3, 4점대면 충분할 것 같아.-맨드러스 인터뷰 13:33, 2015년 3월 4일 (UTC)[응답]

음, 당신의 주장은 토크 페이지 메시지보다는 새로운 사용자에게 나타나는 편집 통지에 의해 더 잘 다뤄질 수 있을 것 같다.아니면, 4~5번 편집한 후에 5개의 기둥 같은 것을 가리키는 에코 알림일 수도 있다.오이야르밥시 (대화) 08:08, 2015년 3월 5일 (UTC)[응답하라]

• 코멘트 나는 이것에 대해 많은 생각과 감정을 가지고 있다.먼저 JMorgan이 운영하는 HostBot이 있다.이 봇은 찻집 초대장과 함께 자동으로 환영 메시지를 올린다.봇은 회원 명부(나는 언급된 리스트에 있다)를 대신하여 이러한 초대장을 게시하여 새로운 사용자가 찻집에 가거나, 봇의 토크 페이지에 도움을 요청하거나, 특정 사용자의 토크 페이지에 도움을 요청할 수 있도록 한다.나는 이것이 좋은 방법이라고 생각하는데, 나는 새로운 웰컴봇이 그것과 경쟁하기를 원하는지 잘 모르겠다.WP:ACC는 또한 과거에 자동 환영 봇(계정 작성자에 의한 선택 및 현재 오프라인 상태)을 가지고 있었다.우리는 그것에 대해 @Stwalkerster와 DeltaQuad로부터 더 자세한 정보를 얻어야 할 것이다. 누가 그것을 담당하는지 확실히 알 수 없기 때문이다.ACC 봇이 오프라인 상태였기 때문에 User:기술 13/스크립트/ACC 위키러브 그 과정을 통해 내가 만든 새로운 사용자의 토크 페이지에 올릴 올바른 환영 메시지를 내가 쉽게 고를 수 있도록 하기 위한 것이다.새로운 사용자들이 DDOwiki(Dongeons and Dragons Online, 내가 최고 편집자 겸 관리자인 Dungons and Dragons Online을 위한 위키)에서 환영받는 것을 향상시키기 위한 방법으로, 나는 새로운 사용자들이 자신의 토크 파에 환영 메시지를 게시하는 http://ddowiki.com/page/MediaWiki:Welcomecreation/preload을 사용하는 http://ddowiki.com/page/MediaWiki:Welcomecreation을 만들었다.ge 그들의 첫 편집으로.이것은 새로운 인간 사용자들이 그들이 필요로 할 때 도움을 찾을 수 있도록 여기나 저기서 몇 가지 세부사항과 포인트를 주는 환영 메시지를 적절하게 받을 기회를 개선한다.나는 웰컴봇의 창조에 전적으로 반대한다고는 말할 수 없지만, 현재의 관행에 간섭하지 않기 위해서는 매우 세심하게 암호화를 해야 할 것이다.—{{U Technical 13}} (e • t • c)14:17, 2015년 3월 1일 (UTC)[응답하라]
  • 그것은 끔찍하게 부서졌다. 왜냐하면 우리는 툴서버로부터 의존적인 도서관을 베끼지 않았고, 나는 그것을 특별히 내가 고치는 것들의 목록에서 그것을 발견하지 못했기 때문이다. 특히 그것이 지난 두 개의 계정에서 조부모조항 아래 봇 깃발만 가지고 있었기 때문이다.내 의도는 봇 편집으로 서명을 위조하는 대신 사용자의 실제 계정을 사용하여 언젠가 편집을 하도록 다시 쓰는 것이었다.어쨌든, 그것은 현재 죽었고, 고치기 위한 긴 목록의 맨 아래 어딘가에 있다.[stwalkerster talk] 2015년 3월 1일 23시 16분 (UTC)[응답하라]
• 페르 쿠드풍에 반대하십시오.이것은 실제적인 문제를 해결하지 않고 불필요한 페이지들을 많이 만들 것이다.비블브록스 (대화) 02:12, 2015년 3월 2일 (UTC)[응답]
• 반대 이 말을 하는 것은 아마도 정치적으로 옳지 않을 것이다. 하지만 환영하는 데 시간과 공간을 낭비하고 싶지 않은 사용자들이 있다.스팸봇(Spambots)은 매우 비원론적으로(심의적인 철자법 - 조용히 나에게 물어보지 않으면) 명명된 것과 다른 명백한 양말, 사용자:위키피디아의 룬비히트헤드나 이와 비슷한 (그리고 더 나쁜) 사람들은 분명히 어떤 유용한 목적을 위해 여기 있지 않은 사람들, 등등.나는 다른 위키피디아에서 자동적으로 환영을 받았고, 그것이 나에게 많은 도움이 되었다고 말할 수 없다.나는 여기서 환영받지도 못했는데, 적어도 한 번은 기억도 안 나고, 한번 봤을 때 내 토크 페이지 역사에서 한 번을 찾지 못했는데, 그것 때문에 여기서 지체되지는 않았다.페리돈 (대화) 2015년 3월 4일 13시 15분 (UTC)[응답]

• 반대 내 환영 메시지는 대부분 표준이지만 특정 이슈(예: 출처, 저작권, NPOV, 이미지 사용)를 다루기 때문에 상당한 비율이 선택된다.이러한 환영은 일부 새로운 편집자들에게 훨씬 더 유용하다. --NeilN 16:17, 2015년 3월 4일 (UTC)[응답]
• 그들이 실제로 하원에서 이것을 하는 것에 반대한다.특수:기여/Wikimedia_Commons_어서 오십시오. 소용없습니다만.그것은 어떤 오래된 환영 페이지에서도 찾을 수 있는 매우 일반적인 환영 상자를 남겨둔다.그러나 저쪽에 있는 다언어주의 때문에 그것은 유용하다.환영의 아이디어는 새로운 사용자가 환영 받는 사람에게 그들이 가지고 있는 어떤 질문도 할 수 있다는 것이다.EoRdE6^{(Come Talk to Me!)} 15:52, 2015년 3월 5일 (UTC)[응답]
• 반대 아무도 종종 잊혀지는 환영의 한 측면에 관심을 끌지 못한 것 같다.거의 모든 환영 템플릿에는 "질문이 있거나 도움이 필요하면 내 토크 페이지에서 물어보라"는 대사가 포함되어 있다.그렇다면 사용자들은 어떻게 봇에게 질문을 할 것인가?SD0001 (대화) 10:29, 2015년 3월 6일 (UTC)[응답]

Wikibook의 템플릿 복제:위키백과의 호버이미지

위키백과는 비교적 비기술적인 위키백과 및 나와 같은 커먼스 사용자들을 위해 위키북스의 호버이미지 템플릿과 동등한 사용이 쉬운 템플릿을 필요로 한다.

b:템플릿:호버이미지

커먼즈 도서관은 광활해지고 있고 위키피디아의 사진 사용은 계속 증가하고 있다.그림은 천 마디의 가치가 있고, 잘 구워진 맴돌 수 있는 그림은 훨씬 더 가치가 있다.

-- 위키피던트 (대화) 04:47, 2015년 3월 2일 (UTC)[응답]

(참고: "요청된 템플리트" 페이지를 발견하기 전에 게시된 후 현재에도 게시됨)

위키북:템플릿:HoverImage는 5년 동안 존재했지만 Wikibooks:특수:WhatLinksHere/템플릿:HoverImage는 몇 가지 용도만 보여준다.위키백과:스타일/액세스 가능성의 설명서#텍스트:툴팁 또는 기타 "호버" 텍스트와 같은 정보를 제공하기 위해 상호작용이 필요한 기법을 사용하지 마십시오. 약어는 이러한 요건에서 면제되므로, 긴 형태의 단어를 나타내기 위해 {{abbr} 템플릿을 사용할 수 있다.프라임헌터 (대화) 06:21, 2015년 3월 2일 (UTC)[응답]

헬로 프라임헌터: (1) 이것은 능란한 템플릿이지만, 얼마나 많은 위키북 사용자들이 이 기능을 알고 있는지 혹은 찾고 있는지 잘 모르겠어.모든 좋은 일들과 마찬가지로 템플릿을 과도하게 사용하는 것은 현명하지 못한 일일 것이다. 하지만 나는 때때로 그것이 큰 위키에서 매우 유용하게 쓰일 수 있다고 생각한다.나는 이미 한 가지 특정 용도에 대한 이미지를 준비했다.템플릿만 있으면 된다. (2) 스타일 매뉴얼의 인용에 대응하여:그 구절은 특히 텍스트의 마우스를 가리키며, 나는 당신이 전체 텍스트를 얻기 위해 텍스트 위에 커서를 올려놓지 않아도 된다는 것에 동의한다.그러나 HoverImage는 텍스트용이 아니다. -- 이미지를 위한 것으로, 값진 효과에 사용될 수 있다. -- WikiPedant (토크) 23:45, 2015년 3월 2일 (UTC)[응답]

아, 그 b:템플릿:HoverImage 기능은 도움말과 유사함:Gadget-ImageAnnotator(이것은 평가 목적으로 이 기능을 실험적으로 설치한 것이다. 이 기능을 시도하는 데 관심이 있는 사용자는 당분간 사용자 스크립트에 의해 이 기능을 사용할 수 있다...공유 위치의 정보도 참조하십시오.도움말:Gadget-ImageAnnotator. --Atlasawa (대화) 12:28, 2015년 3월 6일 (UTC)[응답]

모바일 디프의 편집 횟수 및 사용자 권한 표시

위키피디아의 모바일 뷰를 통해 편집한 사람이라면 모바일 디프가 어떻게 표시되는지 알아차렸을 것이다.비슷한 제안이 더 일찍 나왔는지 아닌지 모르겠다.

1. 편집자의 편집 횟수가 하단에 눈에 띄게 나타나 편집카운트염을 부추긴다.
2. 또한 편집자가 보유한 사용자 권한도 눈에 띄게 표시된다.이를 통해 WP:모자 수집.대부분 모바일을 통해 편집하는 사람들은 다른 모바일 편집자들이 사용자 권리를 눈에 띄게 볼 수 있다는 것을 올바르게 이해하고 있기 때문에 사용자 권리를 수집하도록 권장될 것이다.

내가 보기에 편집수와 사용자 권한의 보기가 중단되고 대화 페이지와 기여를 위한 빠른 링크로 대체되어야 한다.개발자들이 그런 식으로 해결하도록 이끌었을지도 모르는 동기를 이해하는 것은 어렵지 않다.그들은 모바일 편집자들이 심각하지 않을 것이라고 느꼈을 것이고 따라서 그들에게 편집 카운트를 보여주는 것은 그들이 계속해서 편집하도록 부추기는 한 방법일 것이다.그러나 그것은 여전히 사용자 권리의 관점을 정당화하지 못한다.SD0001 (대화) 13:05, 2015년 3월 2일 (UTC)[응답]

1. 제안자로서의 지원.SD0001 (대화) 13:05, 2015년 3월 2일 (UTC)[응답]
2. 반대 - 사용자가 도움을 요청할 수 있는 것처럼 사용자에게 어떤 권한이 유용할 수 있는지(예: 파일 이동기 또는 관리자) 확인하면서 내 반론을 반복하겠다.편집카운티는 동기와 상관없이 우리가 원하는 편집을 장려하기 때문에 좋은 일이 될 수 있다.마지막으로 이 소프트웨어는 모든 위키와 공유되기 때문에 개발자가 엔위키에만 예외를 두게 되어 WMF가 얼마나 행복할지 모르겠다.— 뮤지크애니멀 18:04, 2015년 3월 2일 (UTC)[응답]
3. 중립 - 정책상 찬성도 반대도 아니지만 사용자 경험이 일관된다면 더 좋을 것 같다.그것이 "엔위키를 볼 때 모든 플랫폼에서 일치한다"를 의미하는지 아니면 "모든 위키에서 이 플랫폼에서 일치한다"를 의미하는지 나는 정확히 확신할 수 없다.이반벡터 (대화) 2015년 3월 2일 23시 30분 (UTC)[응답]

토론(모바일 편집 횟수)

1. 편집자의 편집 횟수가 하단에 눈에 띄게 나타나 편집카운트염을 부추긴다.
2. 또한 편집자가 보유한 사용자 권한도 눈에 띄게 표시된다.이를 통해 WP:모자 수집.

[필요하다.--Izno (대화) 16:33, 2015년 3월 2일 (UTC)[응답]

페이지 하단에 있는 '모바일 보기' 버튼을 클릭하고 페이지 내역으로 가서 디프를 보면 직접 볼 수 있다.어쨌든, 나는 이것을 확실히 증명하는 짐보 웨일즈 편집의 스크린샷을 추가했다.SD0001 (대화) 16:57, 2015년 3월 2일 (UTC)[응답]

그것은 정보가 표시된다는 것을 증명할 뿐이지, 그것이 모바일 편집기에서 편집카운트염이나 모자 수집을 유발한다는 것은 아니다.현재 지원되지 않는 두 가지 보편적 주장에 대한 소스를 제공하십시오. --Izno (대화) 17:53, 2015년 3월 2일 (UTC)[응답]

카운터 인수:사용자가 가지고 있는 권한은 예를 들어 파일 이동자 또는 보다 두드러진 관리자와 같이 사용자에게 도움을 요청할 수 있기 때문에 유용할 수 있다.편집이 반드시 나쁜 것만은 아니다.그것은 더 많은 편집을 장려할 수 있고, 그것은 무모함으로 이어질 수 있지만, 일반적으로는 동기와 상관없이 더 많은 편집이 권장된다.— 뮤지크애니멀 18:00, 2015년 3월 2일 (UTC)[응답]

뮤지크애니멀이 좋은 포인트를 올린다.편집카운트염은 유용한 동기부여가 될 수 있다.그러나 대화 페이지에 쉽게 접속할 수 있도록 링크를 만드는 것이 유익할 것이다.토니 탄⁹⁸ · 토크 21:39, 2015년 3월 2일 (UTC)[응답]

나는 Musik Animal과 Tony Tan의 의견에 동의한다.그들은 훌륭한 논점을 가지고 있다.사용자들은 사용자 권한을 보고 알 수 있을 것이다.Sam.gov (토크) 2015년 3월 2일 (UTC) 22:21 [응답]

• 모바일에서 편집해 보셨습니까?너무 답답해, 편집국 조금만 물어봐도 아프지 않아...어쨌든, 나는 WMF가 계속 이것을 실험하는 것을 보고 싶다.그러나 우리는 그들에게 MMV와 VE가 지난 반 년 동안 해온 것처럼 그것으로부터 도출된 결론에 대해 좀 더 많은 설계 연구, 측정 및 지역사회에 보고하도록 요청할 수 있다.그럼에도 불구하고, 나는 위의 방식으로 '아웃' 군중을 위한 결정을 내릴 우리의 군중을 믿지 않는다.WMF는 느리고 과거에 많은 실수를 저질렀지만, 나는 그것들을 더 신뢰하고 장기적으로 워크플로우를 개선해야 한다고 믿는다.우리는 지나치게 많은 투자를 받고 있고, 히피들의 이상을 가지고 있으며, 끔찍한 디자인 기술, 더 나쁜 프로그래밍 기술, 그릇에 담긴 물고기의 기억력, 3살짜리 인내심, 그리고 젊은 어른의 주의력을 가지고 있다.우리는 의사가 되어서는 안 된다. 우리는 빌어먹을 환자다.—DJ (대화 • 기여) 2015년 3월 2일 (UTC) 22:27[응답]

제안과 관련이 없는 의견 접힘

::@DJ: 모바일로 편집한 것도 기억이 안 나.만약 내가 했다면, 그것은 매우 드문 일이었고, 그것들은 차이점/변화를 보여주는 방식이 나를 혼란스럽게 한다.차이점과 전제는 "그저" 색으로 표시되어야 한다.내가 직접 모바일 플랫폼에서 실험을 해서 거기서 결론을 도출해낼지도 몰라.Sam.gov (토크)20:46, 2015년 3월 4일 (UTC)[응답] @TheDJ: 나는 여전히 모바일 웹 플랫폼을 실험하고 있다.그러나 일부 변경사항을 비교하고 데스크톱을 모바일 웹 플랫폼과 비교한 결과, 녹색으로 강조 표시된 것은 이전에 빨간색으로 강조되었던 것과 비교하여 현재 존재하는 것처럼 변경된 버전을 의미한다고 말할 수 있다.Sam.gov (토크) 23:01, 2015년 3월 6일 (UTC)[응답] 뭐가 혼란스럽니?녹색으로 강조된 Wikitext가 추가된 텍스트다.빨간색으로 강조된 Wikitext는 제거된 텍스트다.그러나 이것들은 이 논의와 거의 관련이 없다.SD0001 (대화) 11:03, 2015년 3월 7일 (UTC)[응답]

군사/비밀 서비스/정부/기업 시설의 공용 IP 주소 데이터베이스를 사용하는 새로운 WikiScanner

이전에도 위키스캐너가 있었지만 분명히 어떤 이유로 폐쇄되었고 후임 위키워치독은 사용자 지정 IP주소에 대한 편집만 보여준다.

새로운 WikiScanner 또는 WikiWatchdog의 확장이 다양한 관련 기관/기구의 공개적으로 사용 가능한 IP 주소를 사용할 때가 되었다고 생각한다.

또한 이러한 IP 범위를 단일 스트림/워치리스트에 포함하기 위해 실제로 가입할 수 있다면 유용할 수 있다.

이 제안이 위키워치독의 개선사항으로만 실행 가능하다면 위키백과에서 개발자들에게 연락할 수 있는 방법이 있는지 알고 싶다.

--Fixuture (토크) 2015년 3월 8일 (UTC) 18:54, 8 [응답]

사용자 페이지를 편집하는 새 사용자의 편집통지

enwiki에 관한 아주, 아주 흔한 문제는 새로운 사용자들이 기사 초안을 작성하기 위해 사용자 페이지를 사용한다는 것이다.기사의 성격이 어떻든 간에, 누군가가 와서 그것을 WP로 태그하기까지는 별로 걸리지 않을 것이다.U5 또는 WP:G11, 샌드박스 또는 드래프트 스페이스에서 완벽하게 허용되는 것으로 간주되는 경우.Special:남용 필터/466 및 특수:이 문제로 인해 많은 잘못된 긍정이 있는 남용 필터/499.게다가 사용자 페이지는 검색 엔진에 의해 색인화된다.이것은 작가가 초안을 포기하더라도, 당신은 몇 년이 지난 후에도 그것을 편집하기 위해 다른 새로운 사용자들이 이 초안을 실제 기사라고 생각하면서 올 것이라는 것을 의미한다.그래서, 나는 새로운 사용자들에게 사용자 페이지가 무엇을 위한 것인지 그리고 일반적으로 기사를 작성해야 할 위치를 알려주는 친근한 메시지를 보여주기 위해 편집통지를 사용하는 것을 제안한다.파서 기능을 활용해 본인만의 사용자 페이지를 편집하는 신규 사용자에 대해서만 공지사항이 표시되도록 할 수 있다.우리가 공연에 대해 걱정하지 말아야 한다는 것이 나의 이해다.생각?— 뮤지크애니멀 17:45, 2015년 2월 20일 (UTC)[응답]

제대로 시행될 수 있다면 좋은 생각이라고 생각한다.많은 새로운 사용자들은 WP가 어떻게 작동하는지에 대해 정말로 혼란스러워 하고 있으며, 이와 같은 편집 공지는 확실히 그 문제를 완화하는데 도움이 된다.토니 탄⁹⁸ · 토크 20:14, 2015년 2월 20일 (UTC)[응답]

이건 좋은 생각인 것 같아.편집 통지는 편집자에게 편집 중인 페이지의 종류와 페이지를 편집할 때 고려해야 할 주의사항 또는 권고사항을 확실히 알려준다.Sam.gov (토크) 2015년 2월 20일 (UTC) 20:35 [응답]

이것은 좋은 생각이다.이 작업이 완료되면 사용자 페이지 외에도 갤러리-스페이스에 많은 기사가 만들어지는 위키커먼즈에서도 이 작업이 필요하다.레흐만 11:13, 2015년 2월 21일 (UTC)[응답]

계정 등록일자를 받을 수 있는 파서 기능은 없는 것 같아.러슬릭_제로20:16, 2015년 2월 21일 (UTC)[응답]

@Ruslik0: 나는 네가 옳다고 믿는다.우리는 편집만 하는 것이 아니라, 그들이 페이지를 만들고 있는지 결정하기 위해 몇 가지 마법의 단어를 사용할 수 있고, 그 때 공지를 보여줄 수도 있다.바라건대 그것은 여전히 어느 정도 효과적이며, 경험이 많은 사용자들을 괴롭히지 말아야 한다.— 뮤지크애니멀 18:19, 2015년 2월 22일 (UTC)[응답]

{{PAGEID}}은(는) 존재하지 않는 페이지의 빈 문자열과 존재하지 않는 페이지의 번호를 반환한다.페이지가 없는 경우에만 메시지를 표시할 수 있을 것 같아.칠음 18:26, 2015년 2월 22일 (UTC)[응답]

사용자 작성:편집자가 해야 할 말의 초안인 뮤지크애니멀/userpagenotice.얼마든지 편집하십시오.여기서의 아이디어는 가능한 한 간략하게 유지하고 복잡한 정책적인 것은 모두 피하자는 것이다.대담해진 "사용자 공간 초안" 링크는 우리가 그들이 클릭하기를 원하는 것이다."사용자 공간 초안 작성" 양식을 편집공지에 포함시키는 것도 고려하고 있었다.사용자 공간 초안.그러나 나는 그들이 사용자 페이지 편집 상자에 어떤 것을 입력한 다음 양식을 사용하여 사용자 공간 초안을 작성해서 제출하면, 그들의 브라우저가 저장되지 않은 변경사항으로 페이지를 떠나는 것을 그들에게 요구할 것이라고 믿는다.그것은 아마도 그들이 원하는 것이 아닌 세이브를 달성하도록 이끌지도 모른다.그래서 아마도 그 형태는 생략하는 것이 가장 좋을 것이다.

여러분의 의견과 도움에 감사! — 2015년 2월 23일 03:00 (UTC)[응답]

나는 문구를 약간 수정하고 모양을 바꾸었는데, 지금은 {{ombox}}}을(를) 사용하고 있다."사용자 공간 초안을 작성해달라"는 메시지가 이제는 더 돋보인다고 생각한다.경로(대화) 08:32, 2015년 2월 23일 (UTC)[응답]

@MusikAnimal:이미 저장했다고 생각하는데도 저장되지 않은 변경사항을 알려주는 브라우저에 대해서도 같은 문제가 있었던 것 같아.나는 그것이 고려되어야 한다고 생각한다.Sam.gov (토크)20:09, 2015년 2월 23일 (UTC)[응답]

업데이트로, 나는 아직까지는 운이 없이 테스트위키에서 이 일을 해내려고 노력해왔다.여기 위키에 있는 {{currentuser}} 템플릿은 마법의 단어만 사용한다. {{REVISIONUSER}} 대체될 때만 작동하며, 편집 공지의 경우 빈 문자열만 반환한다.현재 사용자의 사용자 이름을 신뢰할 수 있는 방법으로 잡을 수 있는 방법을 아는 사람?— 뮤지크애니멀 05:29, 2015년 2월 26일 (UTC) 핑킹 칠럼, 러슬릭0—뮤지크애니멀 05:32, 2015년 2월 26일 (UTC)[응답]

편집통지에서 현재 사용자의 이름을 얻는 것은 불가능하다고 생각한다.칠럼이 언급하는 것처럼 페이지가 새로 만들어지는지 여부를 감지할 수 있지만, 그것이 지금의 도구의 한계라고 생각한다.드래곤즈 비행 (대화) 06:36, 2015년 2월 26일 (UTC)[응답]

쥐새끼들.이 문제는 현재 진행 중이며, 실제적인 문제다.우리는 매일 G11/U5'd 페이지가 나타나는데, 대부분의 시간이 선의로 만들어졌다.드래곤즈 비행에 대해 생각나는 거 있어?편집 필터는 좋은 생각이 아닌 것 같다. 왜냐하면 우리는 그들이 편집을 시도하고 난 후에만 보여줄 수 있기 때문이다.자바스크립트를 사용할 수 있을 것 같은데, 엄격한 테스트를 거친 후에 enwiki를 기본적으로 사용할 수 있을 겁니다.— 뮤지크애니멀 16:10, 2015년 2월 26일 (UTC)[응답]

mw 설치 중:확장:MyVariables는 현재 사용자의 이름을 보여주는 새로운 마법 단어를 소개할 것이다. 만약 그것에 관심이 있다면 말이다.나는 다른 위키에서 그것을 보았고 그것은 꽤 잘 작동하는 것 같다; 자바스크립트 버전은 로딩하는 것이 더 느리다.ekips39 (대화) 17:12, 2015년 2월 26일 (UTC)[응답]

WMF가 필요한 건 기대하지 않을 거야내 생각에 JS 솔루션은 괜찮을 것 같아...사용자 페이지를 직접 편집하는지 확인하는 작은 스크립트를 만든 다음 다른 파일에서 AJAX를 통해 편집 통지에 대한 마크업을 끌어다 DOM에 삽입할 수 있다.왜냐하면 대부분의 경우 사용자 페이지를 편집하지 않기 때문에 전체 스크립트와 관련 마크업을 다운로드할 필요가 없기 때문이다.AJAX 통화는 별로 만족스럽지 않을 것이기 때문에 매우 빨라야 한다.이 사용자들은 어쨌든 자신의 사용자 페이지를 편집하는데 좋은 시간을 보낸다. 적어도 JS가 그것을 할 수 있는 시간은 충분하다.— 뮤지크애니멀 17:29, 2015년 2월 26일 (UTC)[응답]

왜 우리는 사용자 이름이 필요한 이유내가 편집한 후 메시지에는 사용자 페이지의 목적을 설명하는 메시지, 사용자 공간 초안 작성을 제안하는 메시지 등 2개의 {{ombox}}가 있다.맨 위 상자는 항상 표시되고 두 번째 상자는 사용자 페이지(모든 사용자 페이지)를 작성할 때만 표시되도록 제안한다.파토르 (대화) 22:24, 2015년 2월 26일 (UTC)[응답]

아마도, 문제는 그들이 기본 사용자 페이지를 작성할 때 통지를 본 후, 링크를 클릭하여 사용자 공간 초안을 작성하고 동일한 통지를 볼 수 있다는 것이다.우리는 제안된 대본을 글로벌 편집 고지에서 작동시켜 필요할 때만 보여줌으로써 더 작게 만들 수 있다.이제 우리는 작거나 3~4줄짜리 대본을 말하는 중인데, 이 대본을 새로운 사용자들로 제한시킬 수도 있을 겁니다.— 뮤지크애니멀 03:05, 2015년 2월 27일 (UTC)[응답]

{{PAGENAME}}과(와) {{SUBPAGENAME}}이(가) 일치하는 경우에만 메시지를 표시하십시오(상단 페이지에서만 표시됨).다음과 같은 경우:{{#ifeq:{{PAGENAME}} {{SUBPAGENAME}} {{User:MusikAnimal/userpagenotice}}}}물론 메인 스페이스에서 온 메세지를 뒤엎는 것을 제외한다.경로(대화) 04:34, 2015년 2월 27일 (UTC)[응답]

나는 메시지 초안에 적절한 마크업을 추가했다.경로(대화) 04:44, 2015년 2월 27일 (UTC)[응답]

고마워!페이지 작성 시에만 표시되는 PAGEID 검사를 추가했다.나는 이것을 testwiki와 testwiki에서 시험해 보았다.템플릿:Userpagenotice 및 testwiki:MediaWiki:편집통지서-2는 효과가 있는 것으로 보인다.여기서 사용자 페이지를 만들거나 편집해 보십시오.나는 다른 모든 사람들이 그렇다면 이런 접근방식에 만족한다.

마지막 우려는 한 가지뿐입니다. 사용자가 링크를 따라 사용자 공간 초안을 작성하면, 실제로 우리가 원하는 대로 문서를 제출할 수 있는 버튼이 있는 {{userspace 초안}을(를) 맨 위에 추가한다.이것은 이론적으로는 좋지만, AfC는 계속 밀리고 있다(지금 당장은 놀랍도록 낮지만!), 그리고 우리는 결국 사용자들로부터 그들이 실제로 그것을 메인 스페이스에 출판하고 있다고 생각하는 새로운 제출이 급증할 수도 있고, 아니면 단순히 그들의 기사가 보기까지 몇 주가 걸릴 수도 있다는 것을 알지 못할 수도 있다.그래서, 나는 우리가 User와 같이 페이지를 이동할 수 있는 링크도 포함시켜야 하는지 궁금했다.뮤지크애니멀/사용자 공간 초안 이동링크를 클릭하면 Special:필드를 채운 페이지 이동그것에 대한 생각은?다시 자유롭게 사용자 편집:뮤지크애니멀/Userspace 초안 이동, 사실 '이동' 링크가 작동하지 않았다.— 뮤지크애니멀 06:03, 2015년 2월 27일 (UTC)[응답]

"페이지 이동" 링크는 현재 작동하며(템플릿을 변환할 때, 직접 볼 때 의도적으로 깨짐) "사용자 공간 초안 이동" 템플릿이 페이지에 어떻게 올라오는지에 대한 문제를 남긴다.나는 또한 내가 앞서 제안했던 사용자 페이지 공지사항을 약간 수정했다.맨 위 상자는 항상 나타나는 반면, 사용자 공간 초안에 대한 제안은 페이지가 존재하지 않는 경우에만 나타난다.파토르 (대화) 01:44, 2015년 2월 28일 (UTC)[응답]

훌륭해!맨 위 상자를 항상 보여주는 것을 지지한다. 그것은 사용자에게 기본 사용자 페이지가 무엇을 위한 것인지에 대한 좋은 지속적인 주의사항이 될 것이다.도와줘서 고마워.내가 거짓말을 했는데 마지막으로 걱정되는 게 템플릿 업데이트 여부야사용자공간 초안을 작성하거나 이 편집사항의 목적을 위해 새로운 초안을 작성한다.기존 업데이트에 대한 이의 제기가 많지 않을 것으로 추측할 수 있을 뿐이지만, 나는 토크 페이지에 대한 의견을 요청했다.— 뮤지크애니멀 01:52, 2015년 3월 1일 (UTC)[응답]

여기에 계획된 작업흐름이 모두 보이지 않는다.편집 통지에 사용자pagenotice를 넣을 수 있다는 것은 알지만, 그들이 작성한 초안에 "Userspace move"가 어떻게 들어가는지 모르겠다.나는 또한 이전에 넣었던 콩 제거술도 복원하고 개선했다. 템플릿이 직접 볼 때는 이동 링크가 작동하지 않지만 템플릿이 변환될 때는 작동한다.(샌드박스에 데모를 넣었는데--그 링크는 저기서 정확해.)파토르 (대화) 02:36, 2015년 3월 1일 (UTC)[응답]

워크플로우는 (1) 사용자가 사용자 페이지에 초안을 작성하기 위해 가고(2) 편집 통지를 통지하고 도움말에 가져오는 링크를 클릭하는 것이다.Userspace 초안 (3)은 초안을 작성하기 위해 양식을 사용한다.후자는 템플릿을 사용하는 것이다.사용자 공간 초안이 제자리에 있음."이동" 링크에 대해서는, 나는 그것에 대해 좀 더 생각해 보았고 아마도 AfC에 추가된 하중이 문제가 될지는 지켜보는 것이 최선일 것이다.새로운 사용자가 선택사항임을 알고 복사 붙여넣기 동작을 막기 위해 링크를 추가해야 한다고 주장할 수 있지만, 이 편집의 목적을 위해 나는 우리가 그것 없이도 앞으로 나아갈 수 있다고 생각한다.별개의 템플릿도 이상적이지는 않아 보여서 그런 생각은 집어치워.그래서... 나는 반대하지 않고 이 일을 추진할 준비가 되어있다.이는 논란의 여지가 없는 것으로 보이며, 새로운 사용자가 초안을 어디에 두는지에 눈에 띄는 영향을 미칠 것이다.필터 499는 공개적인 시야에서 숨겨져 있지만 나와 다른 편집 필터 관리자는 이 편집 통지의 효과를 증명할 수 있기를 바란다.나중에 초안 작성 양식(도움말:Userspace 초안)을 편집통지서 자체로 넣었지만, 먼저 편집통지서 없이 어떻게 해야 하는지 봅시다.— 뮤지크애니멀 02:47, 2015년 3월 1일 (UTC)[응답]

필자의 이해에 의하면, 복사·붙여넣기 행위의 주요 쟁점은 (속인을 제공하는) 이력이 이전되지 않는다는 것이다.그러나 사용자 공간 초안은 오직 한 명의 작성자만이 있을 것으로 예상되며, 그들은 또한 복사 및 붙여넣기 작업을 하는 사람이 될 것이다. 따라서 이 경우 귀속성은 유지된다.반면 메인스페이스에 경쟁 페이지가 갑자기 등장하는 것은 카피비오(copyvio)에 대한 경고 신호 중 하나여서 카피 앤 페이스트(copy and paste) 동작은 새로운 비아냥으로 이어질 수 있다.WP로 연결되는 링크는 어떠한가?"두 번의 클릭-메인스페이스" 대신 MOVE?경로(대화) 03:08, 2015년 3월 1일 (UTC)[응답]

초안은 사용자 공간에 있음에도 불구하고 협력적으로 작업하는 경우가 많다.어느 쪽이든 주장할 수 있겠지만, 이동 링크가 포함된 것은 AfC 팀에 대한 부담을 줄이는 것에 더 가까웠지만, 그게 정말 문제가 될지는 두고 봐야겠다고 결정했다.AfC에 제출하는 것은 사용자에게 친숙한 과정을 보장할 것이며, 실제로 새로운 페이지 패트롤러들이 그들에게 던지는 것보다 덜 자극적이기 때문에, 만약 일반적인 AfC를 생각하는 것이 선호된다.다른 수단을 위한 이동 링크를 포함시키는 것에 대해 논의하려면 템플릿 토크 페이지에서 논의해야 한다.— 뮤지크애니멀 16:55, 2015년 3월 1일 (UTC)[응답]

좋아, 한 가지 문제가 더 있어(내가 계속 그렇게 말하니까 아마 유일한 문제는 아닐 거야.)나는 다른 사람의 사용자 페이지를 편집할 때 "이것은 너의 사용자 페이지"라는 복사본이 부정확할 것이라는 것을 깨달았다.나는 사용자들이 그렇게 많은 것을 알아낼 수 있을 것이라고 생각하지만, 아마도 "이것은 예시의 사용자 페이지"와 같은 것으로 다시 쓰는 것이 더 나을 것이다.{{base userpage editnotice}}}에 있는 템플릿의 새 홈에서 이 변경 사항을 적용했다.어때?— 뮤지크애니멀 17:36, 2015년 3월 1일 (UTC)[응답]

네 말이 맞아, 하지만 영어로 3인칭 대명사를 사용하면 항상 억압받는 군중으로부터 벌레 한 깡통을 얻을 수 있어.Preferences(기본 설정)에서 "그가 위키백과를 편집한다/그녀가 위키백과를 편집한다/(지정되지 않은) 편집한다" 스위치를 기리기 위해 조금 더 수정했다.특이하게도 그들은 의심스러울 정도로 백과사전적이며 문법적으로 복수형이다.ROLE, 계정이 여러 사용자를 반영할 수 있음을 시사함).이 후자의 문제는 위키리듬이 정책의 잘못된 표현으로 받아들여질 수 있기 때문에 문제다.

지금까지 본 믿을 만한 스타일 가이드들을 일일이 따라다니며 표준 영어인 '그 사람/그 사람/그 사람'(general him)을 집어넣었다.나는 이것이 지렁이의 통을 열 것이라고 의심한다; 아마도 반사 대명사를 필요로 하는 전체 구절을 삭제하는 것이 좋은 생각일 것이다.이 삭제는 "(지정되지 않은)" 경우에만 적용할 수 있을 것이다.파토르 (대화) 01:08, 2015년 3월 3일 (UTC)[응답]

거의 모든 수치에 대해 너의 의견에 동의해라.대부분의 사람들은 자신의 성별을 특정하지 않기 때문에 표준 영어임에도 불구하고 나는 "그 사람"이 문제가 될 것을 예상할 수 있다.WP 종료:UP, "이것은 제한된 자전적, 개인적인 콘텐츠를 위한 예시 사용자 페이지"라고 말하면 어떨까?— 뮤지크애니멀 17:48, 2015년 3월 3일 (UTC)[응답]

정책을 인용하는 것은 좋은 생각처럼 들린다.실제로 얼마나 잘 작동하는지 봐야 할 것이다.파토르 (대화) 23:34, 2015년 3월 3일 (UTC)[응답

구현됨

Done Editnotice는 활선이며 {{base userpage Editnotice}}은(는) 가시성이 높아 완벽하게 보호된다.관련 편집 필터를 계속 지켜보면서 편집 내용이 어떤 차이를 보이는지 알아보겠다.도와줘서 고마워.— 뮤지크애니멀 16:09, 2015년 3월 4일 (UTC)[응답]

마지막 세부사항: WP를 사용하여 템플리트 표시를 잊으셨습니다.레드록.파토르 (대화) 22:36, 2015년 3월 4일 (UTC)[응답]

위키백과에서 일부 문서 시작:Editnotice#사용자 및 사용자 대화. -- Gadget850 ^talk 10:47, 2015년 3월 5일(UTC)[응답]

이 스레드가 읽기에는 꽤 길기 때문에 언급된 것인지는 잘 모르겠지만, 우리는 사용자들에게 초안: 네임스페이스에서 공동 편집을 허용하고 동일한 제목의 여러 초안을 방지할 수 있도록 초안을 작성할 것을 지시해야 한다.myself를 포함한 대부분의 AfC 검토자들은 내가 그들과 다른 것을 하기 전에 초안을 초안 네임스페이스로 이동시킨다.EoRdE6^{(Come Talk to Me!)} 16:22, 2015년 3월 5일 (UTC)[응답]

특히 AfC팀이 찬성한다면 나는 이것에 대해 괜찮다.그러나 도움말에서 볼 수 있는 형식과 같은 형식으로 작업을 진행해야 한다.사용자 공간 초안.그 아이디어는 사용자 페이지를 잘못 사용하지 않도록 설득하기 위해 간단하고 이해하기 쉽게 만드는 것이다.도움말 페이지 도움말을 만드십시오.초안이 도움말과 동일한 초안이 될 경우:사용자 공간 초안.— 뮤지크애니멀 17:00, 2015년 3월 5일 (UTC)[응답]

좀 더 명확히 하자면, 이 편집의 대상이 되는 이용자들은 대개 자신이 넣고 싶은 콘텐츠를 이미 보유하고 있고, 저축을 할 준비가 되어 있으며, 주체가 주목할 필요가 있고, 좋은 출처 등이 있다는 통지에 흔들리지 않는다.기사 마법사와 같은 말을 하는 것은 무리일 수 있고, 그들은 사용자 페이지를 계속할 것이다.개인적으로 나는 기사 마법사가 어쨌든 약간 하향 평준화될 수 있다고 생각하지만, 그것은 다른 논의를 위한 것이다.앞에서 언급한 도움말이 다음과 같으십니까?드래프트 어프로치면 충분할까?— 뮤지크애니멀 17:06, 2015년 3월 5일 (UTC)[응답]

@MusikAnimal:이것은 모든 사용자 페이지에 나타나도록 되어 있는가?나는 그것이 글리치, 무작위 숫자와 곱슬곱슬한 괄호로 내 몸에 나타났다는 것을 알았다."{{#ifeq:1354143 "이 나타났다.EoRdE6^{(Come Talk to Me!)} 19:29, 2015년 3월 5일 (UTC)[응답]

나는 MSGJ가 어떤 논리를 다른 템플릿으로 옮기려 했던 것이 정당하다고 생각하지만 분명히 그 과정에서 깨졌다.혹시 빠진 곱슬 브레이스 같은 거?미친 템플릿:Editnotes/Namespace 사물이 testwiki에 설정되지 않았으므로 testwiki의 조합으로 시나리오를 정확하게 시뮬레이션할 수 있다.템플릿:Userpagenotice, testwiki:MediaWiki:편집통지서-2와 다른 템플릿이나 두 개.— 뮤지크애니멀 19:58, 2015년 3월 5일 (UTC)[응답]

리팩터링이 깨진 이유를 정확히 알 것 같다. 템플릿에는 전체 템플릿의 표시를 억제하는 조건과 "사용자 공간 초안 작성" 메시지만 제어하는 조건 두 가지가 있다.리팩터링 시도는 두 조건에서 모두 엔드 마커를 제거했지만 첫 번째 조건만 제거했다.MSGJ가 다시 시도하고 싶다면 템플릿의 샌드박스에서 고쳤다.경로(대화) 22:33, 2015년 3월 5일 (UTC)[응답]

ID가 숨겨질 수 있도록 추가할 수 있는가?고마워, 세나리움 (대화) 2015년 3월 5일 (UTC) 22:00[응답]

@Cenarium:id가 붙은 div로 막 싸서editnotice-base-userpage{{ombox}}, {{nmbox 박스}}}}(후자를 위한 것이 있다고 되어 있음에도 불구하고)에 ID 파라미터에 대한 지원은 없는 것으로 보이기 때문이다.— 뮤지크애니멀 22:19, 2015년 3월 5일 (UTC)[응답]

div가 스팬보다 더 나은가? (모듈 토크에서 문의한 바 있다:obbox와 함께 ID 사용에 대한 메시지 상자)— 마틴 (MSGJ · talk) 10:23, 2015년 3월 6일 (UTC)[응답]

@MSGJ: 웹 개발의 관점에서, 나는 div가 인라인 요소인 블록 요소(자체 라인에서)에 있는 것처럼 더 좋다고 말하고 싶다.— 뮤지크애니멀 16:49, 2015년 3월 6일 (UTC)[응답]

@MSGJ: 현재 버전은 실제로 손상된 HTML을 생산한다. 두 개의 요소는 동일한 ID를 할당하지만 ID는 문서 전체에 걸쳐 고유해야 한다.이 편집은 되돌려야 한다.경로(대화) 23:09, 2015년 3월 6일 (UTC)[응답]

편집 통지가 사용자:샌드박스가 '제한된 자전적·개인적 콘텐츠'를 뜻하는 것이 아니라 오해를 불러일으키는 샌드박스다.특정 페이지에서 숨길 수 있는 방법은?SD0001 (대화) 10:21, 2015년 3월 6일 (UTC)[응답]

그럴 수도 있지만, 왜 User:위키백과가 아닌 샌드박스:샌드박스?— 마틴 (MSGJ · talk) 10:24, 2015년 3월 6일 (UTC)[응답]

등록되지 않은 사용자들이 VisualEditor를 테스트하기 위해 사용한다.SD0001 (대화) 11:59, 2015년 3월 6일 (UTC)[응답]

대안(사용자 페이지 편집공지)

새 사용자 페이지를 만들 때 현재 3개의 메시지 상자가 표시된다.이것들은 약간 압도적일 수 있고, 아마도 새로운 사용자들이 그것들을 모두 읽지는 않을 것이다.

1. 위키피디아는 이 정확한 제목을 가진 사용자 페이지를 가지고 있지 않다. 일반적으로 이 페이지는 템플릿에 의해 생성된 User:xyz에 의해 작성 및 편집되어야 한다.아티클 텍스트 없음
2. 위키백과에 잘 오셨어요! xyz의 사용자페이지로, 한정된 자전적, 개인적 컨텐츠의 장소로서, 이 논의의 결과로 만들어진 것이다.사용자 페이지가 존재하지 않을 때 이 페이지를 억제할 수 있는가?
3. 기사의 초안을 작성하려면, 여기에 작성하지 않고 사용자공간 초안을 작성하십시오. 이 토론의 결과로 작성됨.이것이 어떻게든 첫 메시지와 결합될 수 있을까?

사람들은 어떻게 생각하는가?— 마틴 (MSGJ · talk) 12:37, 2015년 3월 6일 (UTC)[응답]

글쎄, 우선 첫째가 인터페이스의 관리 가능한 부분인 줄은 몰랐어(관리자가 할 수 없는 일이 있을까?)2번과 3번을 모두 합쳐서 그에 맞게 사본을 조정해야 한다.우리는 메시지가 기본 사용자 페이지에만 표시되도록 하기 위해 마법의 단어와 파서 기능을 사용하고 있는데, 그 논리가 이미 {{no 기사 텍스트}}에 존재하는 것처럼 들린다.#2에 대해서는, 우리는 항상 그것을 보여주기로 결정했다. 단지 사용자 페이지들이 무엇을 위한 것인지에 대한 지속적인 기억으로.3번처럼 사용자 페이지를 만들 때만 쉽게 보여질 수 있다.마지막으로, 경험이 많은 사용자는 추가함으로써 이러한 메시지를 숨길 수 있다.#editnotice-base-userpage { display:none !important}그들의 공통점인 css까지.— 뮤지크애니멀 16:14, 2015년 3월 6일 (UTC)[응답]

나는 #1과 #2를 합쳐서 "안녕하십니까, 위키백과에 오신 것을 환영합니다!한정된 자전적·개인적 콘텐츠의 장소인 예시 사용자 페이지다.
일반적으로 이 페이지는 사용자:예."우리가 어떻게 편집해야 하는지 말할 필요는 없을 것 같아, 그들이 편집 버튼을 찾았으면 알아낼 것 같지만, 그게 내 의견이야.

기본 사용자 페이지를 편집할 때 항상 나 자신의 관찰을 바탕으로 조합된 #1-#2 메시지를 표시하는 것이 논리적으로 보인다.반자율적인 사용자 페이지가 있고, 사용자는 프로젝트를 포기하며, 수년 후에는 IP나 새로운 사용자가 기사인 줄 알고 편집하게 될 것이다(사용자 페이지가 색인화되었기 때문에 검색 엔진을 통해 페이지를 발견함).— 뮤지크애니멀 16:25, 2015년 3월 6일 (UTC)[응답]

템플릿:MediaWiki가 문서 텍스트를 변환하지 않음:Noglocatetext, 이것은 페이지를 작성할 때 표시되는 인터페이스 메시지 입니다.#3 메시지를 템플릿으로 이동:기사 문자는 아마도 좋지 않을 것이다.메시지 #2는 사용자 페이지의 적절한 사용을 상기시키는 것으로 편집 고지로 남거나 전체 폐기될 수 있다.#1과 #2를 결합하는 것이 사용자 페이지를 만드는 데 적절할 수 있지만, 경험 있는 사용자들에게 "안녕하십니까, 위키피디아에 오신 것을 환영합니다!"라고 말할 때마다 나는 그들이 사용자 페이지를 편집할 때마다 약간 바보같이 들리므로 #2를 "이것은 ...이다"로 줄일 것을 제안한다.개인적인 내용."파토르 (대화) 23:28, 2015년 3월 6일 (UTC)[응답]

구체적인 대안 제안(사용자 페이지 편집 공지)

표시된 메시지(템플릿:기본 사용자 페이지를 작성할 때 문서 텍스트 없음)는 다음과 같아야 한다.

1. 위키백과에 잘 오셨어요! 위키피디아는 이 정확한 제목을 가진 사용자 페이지를 가지고 있지 않다. 일반적으로 이 페이지는 User:xyz가 작성·편집해야 하며, 시스템형 fmbox로서 자전적·개인적 콘텐츠가 한정되어 있는 공간이다.
2. 기사의 초안을 작성하려면, 여기에 작성하지 않고 사용자 공간 초안을 작성하십시오. 컨텐츠 유형 옴박스.

표시된 메시지(편집 통지에서 템플릿 제외:이후 기본 사용자 페이지를 편집할 때 기본 사용자 페이지 편집 알림)은 다음과 같아야 한다.

1. 한정된 자전적·개인적 컨텐츠의 장소로서, 통지형 옴박스로서, 본보기 사용자 페이지 입니다.

나는 사용자 페이지에 있는 기사를 "STOP IRGENT!" 유형의 이슈보다는 콘텐츠 이슈로 보기 때문에 "경고"보다는 "콘텐츠"를 제안한다.{{fmbox}}이(가) 아닌 {{ombox}}}을(를) 제안하는 이유는 옴박스가 더 보기 좋고 이런 용도에 더 적합하다고 생각하기 때문이다.페이지를 작성할 경우, 현재 메시지를 fmbox로, "userspace 초안" 통지를 ambox로 하는 것이 후자의 눈에 띄는 데 도움이 될 것이다.경로(대화) 23:48, 2015년 3월 6일 (UTC)[응답]

멍청한 소리 하고 싶진 않지만, 이런 피투성이의 것들을 내가 일반 편집자가 제거할 수 있을까, 아니면 안 할 수 있을까?나는 이미 좋은 편집 공지를 가지고 있고 PP 노트와 함께 이것은 그것을 지저분하게 만든다.Musik Animal이 UP에 가지고 있지 않다는 건 알겠는데, 그건 특별한 관리 사항일 수도 있고, 아니면 완전히 보호되는 통지가...아는 사람 있어?미리 고마워!EoRdE6^{(Come Talk to Me!)} 04:21, 2015년 3월 7일 (UTC)[응답]

새 메시지는 네임스페이스 알림으로 추가되고 있다.보호된 페이지의 원본을 볼 때 표시되지 않는 경우.코드를 살펴보니 템플릿에서 {{base userpage edit notice}}의 전폐를 포장한 것 같다.Editnotes/Namespace/User with#ifexist만들기 위해서{{#ifexist:{{PAGENAME}}/Editnotice {{base userpage editnotice}}}}페이지 편집 통지가 정의된 경우 새 편집 통지가 표시되지 않도록 해야 한다.

이것을 좀 더 살펴보면, 이것을 네임스페이스 편집통지서로 만드는 것은 아마도 좋지 않은 생각이었을 것이라고 추측하고, 나는 {{editnotice load}} 샌드박스에서 이것을 통합하는 것을 제안하는 편집을 했다.경로(대화) 06:26, 2015년 3월 7일 (UTC)[응답]

가능하다면 다른 사람의 사용자 페이지를 편집하는 동안 편집 고지를 표시해서는 안 된다고 생각한다.이렇게 하면 많은 문제가 한꺼번에 해결된다. (i) 원래 단어인 "당신의"가 더 나은데, (ii) 사용자 편집 중에는 볼 수 없을 것이다.샌드박스, 사용자:예시 및 기타 그러한 페이지, (iii) 존재하지 않는 사용자의 사용자 페이지를 작성하려고 하는 동안 아무도 보지 않을 것이다.SD0001 (대화) 13:45, 2015년 3월 7일 (UTC)[응답]

한때는 그런 기능이 있었지만, 그 기능이 의존하고 있는 {{REVISIONUSER}}의 특별한 용도는 버그로 결정되었다.템플릿:Editnotice 로드는 여전히 "소유자 페이지" 논리를 가지고 있지만, 지금은 아무 것도 하지 않는다.파토르 (대화) 01:18, 2015년 3월 8일 (UTC)[응답]

@MusikAnimal:편집의 윗부분은 그것이 해결하는 것보다 더 많은 문제를 제기한다.

1. 신규 사용자들은 지침을 이해하는 데 서툴다는 것이 증명되었다.지나치게 간략한 표현은 자칫 오해를 불러일으킬 수 있다.그들은 자전적 정보를 어느 정도 제공해야 한다는 인상을 받을 수도 있다.
2. 자서전적이고 개인적인 내용만?사용자 페이지는 자신이 작성한 기고문을 전시하거나, 작성한 기사 목록을 보관하거나, 작업 중인 곳이 아닌가?
3. 편집통지의 윗부분이 모든 사용자에게 보일 것이라는 결정은 뮤지크애니멀과 또 다른 편집자 사이에서 취한 것으로 보인다.이것은 받아들일 수 없다; 당신은 지역사회의 합의가 필요하다.CSS를 알지 못하거나 CSS를 사용하여 CSS를 보는 것을 배제하려는 경험이 있는 편집자들이 많다.또한, 우리는 사용자 페이지에 관해서 상당한 여유를 제공한다.만약 누군가가 과도한 개인정보를 주고 싶다면, 우리는 그들을 막을 필요가 없다.SD0001 (대화) 13:45, 2015년 3월 7일 (UTC)[응답]

나는 앞서 말한 모든 것에 찬성한다.SD0001, 윗부분을 제거했다.나는 그것이 현재의 형태에 잘 맞지 않는다는 것에 동의하고, 또한 더 정확하기 위해 확실히 수정될 필요가 있다.우리는 아마도 사용자 페이지에 무엇이 있을 수 있는지 말할 필요가 없을 것이다. 그러나 더 말할 필요가 없을 것이다. 그것이 편집 고지의 전체 이유이기 때문이다.즉, 사용자 페이지가 기사 초안을 작성하는 장소로 오용되는 것을 방지하기 위해, 너무 자주 발생한다.

따라서 우선, {{base 사용자 페이지 편집 노트}를 상단 부분 없이 그대로 두고, Pathore의 제안된 변경 사항과 더 나은 복사본이 결합된 브레인스토밍을 편집 노트 뒤의 의도를 염두에 두자.그러나 나는 간결함이 여기서 일종의 아이디어라고 지적할 것이다. 만약 메시지가 너무 길면 그들은 그것을 읽지 않을 것이다.고마워 — 2015년 3월 9일(UTC) 19:47, 음악애니멀[응답]

위키피디아의 편집통지가 어떻게 설정되는지를 더 많이 보았기 때문에, 편집통지가 정말로 올바른 방법인지 확신이 서지 않는다.우리는 현재 {{base userpace edit notice}}에 약간의 논리를 가지고 있어 페이지를 작성할 때만 "userspace edit" 텍스트가 나타나도록 하고 있지만, 이제는 그 전체 템플릿이 페이지 작성 시에만 사용되기 때문에 {{No 기사 텍스트}}에 메시지를 넣어야 한다고 생각한다.그런 다음 {{base userpage editnotice}}을(를) 기본 사용자 페이지 편집 알림으로 재사용할 수 있으며 User:예/편집.이 후자의 세부 사항은 내가 제안한 {{editetice load}}}의 변경 사항이다.생각?경로(대화) 20:44, 2015년 3월 9일 (UTC)[응답]

제목에 불법적인 내용이 없는 한 삭제된 기사 제목이 있는 목록 표시

제안:제목에 불법적인 내용이 없는 한 삭제된 기사 제목이 있는 목록 표시

그리고 그들의 이전 제목도, 아시다시피, 사람들은 제목을 바꾼 다음 기사를 삭제할 수 있다.

이것은 투명성을 향상시키기 위한 것이고, 사람들이 그 기사들이 존재한다는 것을 알기 때문에 그들이 그 기사들을 물어보는 것을 도울 수 있을 것이다.

돈이 많은 중요한 기관들은 삭제하는 것이 그들에게 불편한 자료를 없애는 좋은 방법이라고 결정할 수 있다.어떻게 그럴 수 있지?불편한 소재가 없는 새로운 기사를 만든 다음, 제목이 같거나 비슷한 구기사를 삭제하는 것.이 제안은 보통 사람들에게 힘을 실어주는 방법이다.Abcdudtc (대화) 08:08, 2015년 2월 28일 (UTC)[응답]

특수:로그/삭제.누구나 삭제 로그를 읽을 수 있다. 언제든지 읽을 수 있다.편하게 써.물론 우리는 하루에 수백 개의 기사를 삭제하기 때문에, 나는 그것을 겪는 것이 얼마나 실용적인지 잘 모르겠다.삭제된 모든 타이틀의 목록은 백만 개가 넘을 것이다.드래곤즈 비행 (대화) 08:23, 2015년 2월 28일 (UTC)[응답]

좋긴 한데 "아래는 최근 삭제 및 복원 목록"이라고 쓰여 있어.2004년 12월 이후 "최근"은 나쁘진 않지만, 그 정보는 항상 가지고 있는 것이 좋을 것이다.Abcdudtc (talk) 08:45, 2015년 2월 28일 (UTC) 그리고 또한 이전 기사의 제목을 보여주지 않고, 사람이 제목을 바꾼 다음 기사를 삭제할 수 있다.Abcdudtc (대화) 08:51, 2015년 2월 28일 (UTC) 한 가지 더:삭제 로그에서 특정 단어로 시작하거나 제목 안에 일부 단어가 들어 있는 문서를 검색하려면 어떻게 해야 하는가?Abcdudtc (대화) 08:59, 2015년 2월 28일 (UTC)[응답]

@Abcdudtc:제공된 링크로 이동하여 목록 위에 표시되는 검색 옵션을 사용하십시오.로그가 어떤 이유로 가장 오래된 삭제를 먼저 표시하도록 설정될 수 있지만 위의 옵션에서 수정할 수 있다.오이야르밥시 (대화) 17:33, 2015년 2월 28일 (UTC)[응답]

나는 Special을 보았다.로그/삭제.'마약X'나 '자연약'처럼 제목에 단어가 들어 있는 삭제된 기사들을 모두 찾아볼 수 있는가.내 말은 이렇게 말이야.와일드카드_문자#컴퓨팅.Abcdudtc (대화) 13:06, 2015년 3월 1일 (UTC)[응답]

위키피디아를 따라야 하는 관리자만 페이지를 삭제할 수 있다.삭제 정책.관리자는 Special:에서 삭제된 페이지 이름 목록을 볼 수 있다.무절제하다.그들은 접두사를 선택하고 그 접두사로 시작하는 이름의 알파벳 목록을 얻을 수 있다.관리자는 삭제된 페이지의 내용(페이지 기록 포함)을 보고 삭제 해제 여부를 결정할 수도 있다.프라임헌터 (토크) 2015년 2월 28일 (UTC) 17:48 [응답]

그리고 가능한 후속 제안을 예상하고, 위키백과:영구적인 제안#삭제된 페이지를 볼 수 있어야 한다.프라임헌터 (토크) 2015년 2월 28일 (UTC) 17:51 [응답]

나는 위키피디아를 읽었다.영구제안#삭제된 페이지는 보여야 하지만 이것은 다르다. 이것은 기사에서 가지고 있던 제목과 이전 제목만 표시하기 위한 것이다.이것의 내용은 지금처럼 누구에게도 보이지 않을 것이다.Abcdudtc (대화) 13:20, 2015년 3월 1일 (UTC)[응답]

Special을 결합할 수 있는 방법이 있어야 한다.로그/삭제 및 특수:이후에 삭제된 페이지가 이동 로그에서 제거되지 않는 경우 로그/이동파토르 (대화) 01:16, 2015년 3월 3일 (UTC)[응답]

하지만 나는 특별하지 않다고 생각한다.로그/삭제 또는 특수:로그/이동하면 제목에 단어가 있는 모든 삭제/이동 기사(예: "마약 X" 또는 "천연 마약"과 같은 단어)를 검색할 수 있는가?내 말은 이렇게 말이야.와일드카드_문자#컴퓨팅.내 말이 맞니?Phabricator에서 소프트웨어 변경을 위해 이에 대한 요청을 제출해야 하는가?Abcdudtc (대화) 13:11, 2015년 3월 5일 (UTC)[응답]

네, 기본 로그 인터페이스는 와일드카드 검색을 지원하지 않기 때문에 무엇을 찾고 있는지 알아야 할 겁니다.그러나 전체 로그는 다운로드[3](선택한 위키백과 프로젝트 선택 후 "로그링" 파일 선택)이 가능하므로 원하는 소프트웨어를 이용하여 직접 검색을 할 수 있다.응, 인터페이스가 개선될 수도 있지만, 나는 그러한 요청이 개발자들로부터 곧 많은 관심을 끌 것이라고 기대하지는 않을 거야.드래곤즈 항공편 (토크) 2015년 3월 6일 (UTC) 23시 49분[응답]

우리가 사용할 수 있는 것은 로그 검색에만 사용할 수 있는 외부 도구(https://tools.wmflabs.org/grep/?https=en&wiki=ns=0 )이다.2015년 3월 11일 (UTC) עושוווו Od Mishehu 07:50 (UTC)[응답]

초기 편집 시 '페이지 저장' 버튼 사용 안 함

등록되지 않은 사용자에게 표시되는 메시지

나는 등록되지 않은 사용자들이 편집 페이지로 갈 때 주어지는 배너 메시지가 아마도 계정에서 편집자가 일한다는 권고나 명시적인 선호로 강화될 수 있는지 궁금했다.

다음은 현재 메시지:

로그인하지 않으셨습니다.당신이 어떤 편집을 한다면 당신의 IP 주소는 공개적으로 보일 것이다.로그인하거나 계정을 만들면 편집한 내용이 사용자 이름으로 귀속되며 그 중에서도 다른 이점이 있다.

나는 위키피디아에서 이 텍스트에 대한 참조를 방금 추가했다.사용자 액세스 수준#바로 가기 WP를 통해서도 액세스되는 등록되지 않은 사용자:IP. 이것을 베이지색 배경과 주요 이미지로 「등록되지 않은 유저」에게 제시하는 형태로 제시하는 것이 적절한지 궁금했다.

또한 "등록되지 않은 사용자"가 가장 적절한 설명인가?일부 사용자는 등록될 수 있지만 의도적이든 그렇지 않든 로그인에 실패했을 수 있다.그레그케이 09:48, 2015년 3월 11일 (UTC)[응답]

현재 메시지는 다음과 같다.

UAL 페이지에 실제 메시지를 포함하도록 업데이트했다(그래서 페이지가 변경된 경우 최신 상태임).정확히 무엇을 변경할지 모르겠는데, IP 사용자를 "호출"하는 것 뿐인가?그들은 또한 때때로 "IP 사용자" (일부 사용자들은 이것이 무엇을 의미하는지 실제로 알지 못하는 경우)와 "익명 사용자" (실제로 익명성이 훨씬 덜해지지만)라고도 불린다.— Xaosflux^Talk 17:16, 2015년 3월 11일 (UTC)[응답]

나는 "익명 사용자"가 아마도 최고일 것이라고 생각한다 - 그 당시에, 사용자들은 익명성이었다.예, 그의 IP주소가 기록되고 있지만, 장기적으로는 개인 소유 IP가 거의 없다.2015년 3월 11일 (UTC) odושווodOd Mishehu 20:43 [응답]

IP 사용자를 익명으로 부르는 것은 잘못된 보안의식을 초래할 수 있다.xaosflux가 말한 것처럼 IP 사용자들은 IP 이외의 다른 이유가 없다면 계정을 사용하는 사용자들보다 덜 익명적이다.사용자들이 IP가 더 익명하다고 생각하도록 만드는 것은 사람들이 계정을 사용하는 것을 단념시킬 수 있다.나는 IP 사용자들을 등록되지 않은 상태로 불러도 문제가 없다고 본다. 로그인하지 않은 상태라 하더라도 IP 사용자들은 그것이 무엇을 의미하는지 이해할 것이다.만약 어떤 것이라도, 당신은 그들이 "등록되지 않은 사용자로 편집 중"이라고 말할 수 있다. 만약 그들이 로그인하지 않았다면, 그것은 사실이다.팬텀기술 (대화) 2015년 3월 11일 (UTC) 20:58 [응답]

고맙다 esp: xaosflux. "...와 같은 텍스트가 추가될 수 있을 것이다. 그리고 다른 편집자들은 숫자가 아닌 이름으로 당신과 함께 일하는 것을 고마워할 것이다."또는 검색 가능한 사용자 이름 기능을 강조할 수 있다.로그인을 위한 인수를 보여주기 위해 제시될 수 있는 다른 합리성이 있는가?그레그케이 12:02, 2015년 3월 12일 (UTC)[응답]

@GregKaye:대부분의 항목으로 변경할 수 있습니다, 다음 위치에서 변경 사항을 제안하십시오: MediaWiki_talk:{{Edit protected}}을(를) 사용하여 Anonytit 경고.— Xaosflux 16:49, 2015년 3월 12일 (UTC)[응답]

2015년 CheckUser 및 감독 약속:후보 코멘트 최종 기회

중재위원회는 CheckUser and Supervision 팀에 추가 사용자 임명을 추진하고 있으며, 이 과정의 커뮤니티 의견수렴 단계가 결론에 가까워지고 있다.

이해당사자들은 후보자들이 제공한 지명 성명서와 몇 가지 표준 질문에 대한 답변이 들어 있는 임명 페이지를 검토하도록 초청된다.커뮤니티 회원들은 또한 추가적인 질문을 할 수 있고 후보들에 대한 의견을 개별 지명 하위 페이지에 올리거나 Arbcom-en-clist들에게 이메일을 통해 개인적으로 제출할 수 있다.wikimedia.org.

아직 논평하지 않은 사람들은 앞으로 며칠 동안 그렇게 하도록 격려 받는다.

위원회는 협의단계에 이어 후보자들이 질의에 제공하는 답변과 지역사회(공적·사적)의 의견과 그 밖의 모든 관련 요인을 고려한 뒤 임명과 관련한 최종 결정을 내릴 예정이다.

협의 단계는 3월 18일(UTC) 23시 59분에 종료될 예정이며, 2015년 3월 31일까지는 인선이 발표될 예정이다.

중재위원회의 경우, 쿠르셀레스 (대화) 07:26, 2015년 3월 13일 (UTC)[응답]

장소?

위키피디아 토크에서 이미 질문:뉴스에서 그러나 나는 내가 게시할 때 그것이 교통량이 적은 페이지라는 것을 깨닫지 못했다.

메인 페이지의 ITN 섹션에 기사가 실리는 동안에만 영향을 미칠 수 있는 제안서를 제시할 수 있는 정확한 장소인가?Mjroot (대화) 08:56, 2015년 3월 12일 (UTC)[응답]

어디서 질문을 해야 하는지에 대한 메타 질문보다는 그냥 질문을 해라.메타 질문을 하면 시간이 낭비된다.만약 장소가 잘못되었다면, 사람들은 당신에게 말할 것이다.WT에서 묻고 싶은 질문을 실제로 하지 않으셨습니다.ITN 역시, 그래서 아마 아무도 대답에 관심이 없었던 것 같다.실제 제안서(여기, 저기, 어디든)를 제시하여 사람들이 관심이 있는지 살펴보십시오.그런데 어디서 질문을 해야 하나 하는 질문 자체가 실제 질문 자체만큼 흥미를 유발하지는 못할 것이다.--Jayron32 13:05, 2015년 3월 16일 (UTC)[응답]

@Jayron32: 좋아, 알았어.이곳도 어디 못지않게 좋은 곳인 것 같아.Mjroot (대화) 20:39, 2015년 3월 16일 (UTC)[응답]

2015년 CheckUser 및 감독 약속:후보 코멘트 초대

중재위원회는 CheckUser and Supervision 팀에 추가 사용자 임명을 추진하고 있으며, 현재 이 역할에 자원한 후보들에 대한 커뮤니티의 의견을 구하고 있다.

이해당사자들은 후보자들이 제공한 지명 성명서와 몇 가지 표준 질문에 대한 답변이 들어 있는 임명 페이지를 검토하도록 초청된다.커뮤니티 회원들은 또한 후보들에 대한 추가적인 질문을 던질 수 있고, 후보들에 대한 의견을 개별 지명 페이지나 이메일을 통해 Arbcom-en-lists에게 제출할 수 있다.wikimedia.org.

위원회는 협의단계에 이어 후보자들이 질의에 제공하는 답변과 지역사회(공적·사적)의 의견과 그 밖의 모든 관련 요인을 고려한 뒤 임명과 관련한 최종 결정을 내릴 예정이다.

협의 단계는 2015년 3월 18일(UTC) 23시 59분 종료될 예정이며, 2015년 3월 31일까지는 인선이 발표될 예정이다.

중재위원회의 경우, 쿠르셀레스 (대화) 06:25, 2015년 3월 4일 (UTC)[응답]

이 문제에 대해 논의하십시오.