위키백과:마을펌프(아이디어랩)

"바이트 크기 차이" 대신 "거리 편집" 사용

안녕하세요, https://en.wikipedia.org/w/index.php?title=Main_Page&action=history과 같은 이력 페이지에서는 다음과 같은 괄호 안에 "바이트 차이"가 있습니다.

(cur-prev) 2022년 6월 17일 15:25, Cyberpower678 (talk - contributes) (2,964 바이트) (+3) Cyberpower678 (talk) Wooops에 의한 Und 리비전 109358636.잘못된 페이지에서 테스트 완료(감사합니다) (태그: 실행 취소)

여기서 (+3)은 "이 페이지의 이전 버전과 현재 버전의 바이트 크기 차이"를 나타냅니다.여기서 "바이트 크기 차이"가 잘못되었다고 생각합니다. 예를 들어 Levenshtein distance를 사용하여 "Edit distance"를 표시해야 합니다.이 시나리오를 가정해 봅시다.예를 들어 편집 시 "on"에서 "in"으로 한 단어만 변경합니다.여기서 "바이트 크기 차이"는 문자열의 길이가 변경되지 않기 때문에 차이가 0이라고 하지만, "편집 거리"는 사용자에게 올바른 항목을 표시합니다. 예를 들어, "켜짐"과 "입력"의 편집 거리는 1입니다.따라서 괄호 안의 사용자에게 표시되는 것은 에디션의 "바이트 크기 거리"가 아니라 "편집 거리"입니다.감사합니다. Hooman Mallahzadeh (토크) 2022년 7월 7일 (UTC) 11:23 [응답]

이 값을 직전 페이지 크기 값(바이트 단위)과 조정하려면 어떻게 해야 합니까?편집 거리가 더 유용한 지표가 될 수도 있지만, 많은 사람들에게 매우 불쾌할 수도 있습니다. 이 정보가 현재 표시되는 방식에서도 마찬가지입니다.그렇다고 해서 내가 말할 자격이 없는 변경의 기술적 타당성에 대해 말하는 것은 아니다.Duh 박사 🩺 (대화) 2022년 7월 7일 (UTC) 11:36 [응답]

완벽하지는 않지만 변화의 지표일 뿐이다.어떤 값을 나타내든 숫자(+2/-50)로 사용자가 수행한 작업을 설명하면 편집 내용을 알 수 없습니다.여기서의 차이는 대부분 복사 편집에 있습니다. 0보다 +1을 표시하는 것은 개선되지 않습니다.Terasail^[✉️] 2022년 7월 7일 11:48 (UTC) [응답]

@Terasail 나 자신에게는 +1(편집 거리)이 0보다 매우 유익합니다.그리고 저는 그것이 다른 사람들에게 더 유익할 것이라고 생각합니다.Hooman Mallahzadeh (대화) 2022년 7월 7일 (UTC) [응답]

@테라세일 예스!복사 태스크는 "바이트 크기 차이"를 0으로 만들지만, 이러한 경우 "편집 거리"는 1이 되어야 하며 1보다 크지 않아야 합니다. 따라서 이러한 시나리오에서는 Levenshtein 거리에 의한 구현은 권장되지 않습니다.네 말이 맞아!이러한 복사 태스크의 알고리즘을 수정하여 편집 거리를 1로 되돌려야 합니다.그러나 "in" 및 "on" 시나리오의 경우, Levenshtein 거리가 충분합니다.Hooman Mallahzadeh (대화) 2022년 7월 7일 13:16 (UTC) [응답]

@Doctor Duh 당신 말이 맞아요, 편집 거리에 대해 아무것도 모르는 사람에게 이 데이터는 무의미할 수도 있어요.그러나 편집 거리가 전문가에게는 더 유익합니다.여기서 편집거리라는 개념을 사용함으로써 이 개념이 사람들 사이에서 더욱 빈번해졌다고 생각합니다.나도 생각이 있어.초보자용 '바이트 크기 차이'와 전문가용 '편집 거리' 두 가지 항목 모두 여기에 표시할 수 있습니다.

기술적으로 편집 거리는

한 문자열을 다른 문자열로 변환하는 데 필요한 최소 작업 수입니다.

기술적으로는 어렵지 않습니다.Hooman Mallahzadeh (대화) 2022년 7월 7일 11:49 (UTC) [응답]

@Doctor Duh@Terasail 복사/붙여넣기 시나리오 등 다른 시나리오에 실장하는 것은 더 어렵지만, 시나리오의 수는 적기 때문에 실장할 수 있다고 생각합니다.Hooman Mallahzadeh (대화) 2022년 7월 7일 13:24 (UTC) [응답]

@Doctor Duh @Terasail "판별 바이트 크기 차이는 -5와 같다"는 것은 매우 애매하기 때문에 기사에 무슨 일이 일어났는지 거의 알 수 없고 기사에 얼마나 많은 변화가 있었는지는 알 수 없다.생각할 수 있는 시나리오는 다음과 같습니다.

1. 생략된 단어 - 이 경우 편집 거리는 부호 변경에 의한 바이트 크기 변경과 동일합니다.
2. 기사에서 많은 변화가 발생했지만 크기 차이가 -5입니다. 이 경우 편집 거리가 큽니다.
3. 매우 작은 부품이 변경되었지만 크기 차이가 -5입니다. 이 경우 편집 거리가 작지만 5보다 큼
4. 일부 복사/복사가 발생하고 단어가 생략됨 - 이 경우 "거리 편집" 정보가 훨씬 더 신뢰할 수 있습니다.

이러한 시나리오 중 첫 번째 시나리오에서만 바이트 크기는 기사에서 발생한 내용에 대한 좋은 정보를 제공합니다.편집 거리는 문서의 다음 판을 얻기 위해 필요한 최소 작업량을 나타냅니다.Hooman Mallahzadeh (토크) 13:57, 2022년 7월 7일 (UTC) [응답]

측정기준의 한계를 기억하는 것만으로도 종종 이런 종류의 일에 대한 실제적인 직관에 충분하다는 것을 알게 된다.Levenshtein 거리 기사:

• 적어도 두 문자열의 크기 차이입니다.[하한]
• 길어야 긴 문자열의 길이입니다.[상위]
• 문자열이 동일한 경우에만 0입니다.[NULL 케이스]

텍스트 블록을 이동하는 것은 중요하지 않지만, 원하는 기능이라면 코드에 대한 간단한 부록입니다(워치리스트에 "mv" 텍스트로 표시됨).마이너 카피 편집의 문제에 대해서는, 바이트의 차이가 있는 경우가 있기 때문에, 「마이너 편집」플래그가 목적입니다."작은" 편집이 실제로 반달리즘인지 아닌지를 판단할 수 있는 비언어 알고리즘은 없습니다.그것은 4글자만 있으면 됩니다.Jeffrey Dahmer는 바보 → Jeffrey Dahmer는 바보가 아니었다.

물론 양적 지표에 대한 나의 선호도는 우선 쿨의 법칙에 의해 결정되지만(첫 번째 검색 결과는 매우 실망스럽다), 만약 우리가 어떤 stat mech 향신료를 도입한다면 이 아이디어는 훨씬 더 많은 사람들을 잃게 될 것이라고 생각한다.그래서 난 100% 승선했어SamuelRiv (대화) 2022년 7월 7일 (UTC) 14:10 [응답]

• @Hooman Mallahzadeh: 이 아이디어는 phab에서 제안되었습니다.T10571 - 이것은 영어 위키피디아에서만 할 수 있는 일이 아니라고 생각합니다(모든 사람을 위해 각 행의 값을 모두 다시 쓰는 스크립트를 실행하는 것은 매우 어렵습니다만, 퍼스널 유저 스크립트를 사용해 초기 테스트를 실시할 수도 있습니다).서버측에서 실시하는 것이 최선이라고 생각합니다.T10571의 토론에 참여하여 더 발전시킬 수 있습니다.- xaosflux^Talk 14:06, 2022년 7월 7일 (UTC) [응답]

  네, 저도 몇 달 전에 이것을 제안했고 같은 IIRC를 들었습니다.행운을 빌면 언젠가 알게 될 거야Theknightwho (토크) 2022년 7월 7일 22:45 (UTC) [응답]

• 좋은 생각(원조든 아니든)특히 어떤 기사(2)가 역사를 바꾸는지 한눈에 알 수 있는 워치리스트가 있으면 좋겠습니다.(0).. [ Vandal 420 ; GoodGuy123 ]는 첫 번째 편집이 반환되었기 때문에(여기에서 볼 수 없음), 기타 이유로(조사 필요) 순변화가 0입니다.증명서 (대화) 2022년 7월 7일 (UTC) 17:42, [응답]

  그래, 인간 순찰자들이 더 편하게 살 수 있을 거야.Theknightwho (토크) 22:46, 2022년 7월 7일 (UTC)[응답]

편집 크기를 명확하게 하는 방법 중 하나는 추가된 문자와 삭제된 문자에 대해 별도의 값을 표시하는 것입니다(두 값에 영향을 주는 문자가 변경됨).따라서 1,000자를 변경하지만 문서의 전체 크기에 영향을 미치지 않는 편집은 "+1,000-1,000"으로 표시됩니다.Gdr 2022년 7월 18일 (UTC) 07:57 [응답]

@Gdr 나는 너의 의견에 동의하지 않아!패트롤러에게는 편집 거리를 '기능적으로' 나타내는 단일 값이 더 적합합니다.하지만 스크립트 작업 번호를 툴팁으로 편집할 수 있습니다.예를 들어 편집 스크립트 요약은 다음과 같이 툴팁에 표시될 수 있습니다.

편집 거리 = {{tip 100 ins:50, del:48, subs:2}}

그 결과:

거리 편집 =100

툴팁에서는 100에 해당하는 이 편집 거리가 50개의 삽입, 48개의 삭제 및 2개의 대체로 구성되어 있음을 보여 줍니다(Levenshtein 거리의 연산을 가정).Hooman Mallahzadeh (토크) 8:43, 2022년 7월 18일 (UTC)[응답]

편집 거리를 삽입과 삭제로 나누고 바이트 크기 변경과 동일한 차이를 갖는 아이디어가 마음에 듭니다.이것은 경험이 풍부한 편집자에게도 충분히 유익하고 초보자에게도 충분히 직관적일 것입니다.몇 가지 예:

변경 없음 → (0)

(in → on) → (+1/-1)

(in → where) → (+5/-2)

(in → into) → (+2)

(내부 → in) → (-2)

(무조건 항복 → 무조건 항복) → (+9/-9)

페트르 마타스 07:42, 2022년 7월 19일 (UTC)[응답]

합병 개혁

지난달 Disconsid에서 한 코멘트 수정:

이 상황이 다른 사람에게 친숙하게 들리나요?가이드라인에 따라 중복이 매우 심한 주제에 대해 교과서 병합을 지정한다[WP:폭넓은 개념과 WP:다중 이름]병합 토론 후 한두 명의 사용자로부터 약간의 초기 지원을 받을 수 있습니다.그리고 분명히 그 분야의 전문가이고 기사들 간의 아주 작은 범위의 차이가 세계에서 가장 중요한 차이라고 생각하는 새로운 편집자의 반대도 있다.그리고 몇 주/몇 달 후에 같은 방식으로 또 한 번.그리고 또 하나.그리고 그 숫자에 반대하기엔 너무 소심한 사람으로부터 가까운 합의는 없다.이것은 내가 처음 접하는 것이 아니다; 합병 개혁은 너무 빨리 올 수 없다.

머지 프로세스를 다시 작동시키기 위해 변경하는 방법에 대한 구체적인 제안을 찾고 있습니다.주제와 무관하게 전담 편집자 그룹의 시간 및 참여 시간을 단축하는 것이 필수적이며, 다양한 XfD 포럼이 (비교적으로) 잘 작동하여 상당한 영감을 얻을 수 있다고 생각합니다.{{u Sdkb}} 2022년 7월 10일 (UTC) 16:56 [응답]

통지: WT: 머지, WT:Wiki Project Merge, WT:BROAD CONSTECT, WT:모호한 제목.{{u Sdkb}} 2022년 7월 10일 17:05, UTC[답글]

• 일반적인 코멘트: 비전문가가 일반 청중에게 명백한 "소소한 구별"이 중요한 경우와 그렇지 않은 경우를 신뢰성 있고 일반적으로 구별하는 것은 매우 어렵다.이 토론에 참석하기 위해서는 다른 점이 중요한 두 가지 주제를 혼동하는 것을 더 잘 모르는 사람들로부터 차근차근 토론하는 것을 거부하는 완고한 전문가들을 칭찬할 수도 있다.프로톤크 (대화) 17:37, 2022년 7월 10일 (UTC)[응답]

  일반적으로는 각각의 기사를 읽고도 두 주제를 구별할 수 있는 전문가가 되어야 한다면 WP에 통합되어야 할 만큼 밀접하게 관련되어 있습니다.폭넓은 개념가장 이상적인 편집자는 주제 전문지식과 WP 지침 전문지식을 모두 갖춘 편집자이지만 그러한 편집자는 존재하지 않는 경우가 많다.무엇 현재 일어나고 있는 것은 주제 전문가들, 우리의 정책에 의한,, 제 질문은 아니"이 두가지 동일하다?"(그들은 거의 없다) 아니라"그들이 밀접하게 관련이 기술의 비용을 정당화하지 못하는 게 충분한지?"{{너 Sdkb}}얘기 18:08, 7월 10일 2022년 관계를 이해하지 못하는 논의를 독차지하고 있다. (UPC) [응답]

  몇 가지 사례 없이 당신이 말하는 것의 장점을 판단하는 것은 어렵다. 당신은 사소한 차이가 전문가/전문가에 의해 과장된 몇 가지 사례를 지적할 수 있는가?TryKid 2022년 7월 10일 18:21 (UTC) [응답]

  비전문가에게 당장 드러나지 않는 차이가 차별화를 요구하지 않는다는 가정으로부터 출발한다면, 그들은 반드시 전문가의 의견과 상관없이 합병을 진행해야 한다는 결론을 내릴 것이다.프로톤크 (대화)19:17, 2022년 7월 10일 (UTC)[응답]

• 합병을 위한 "프로세스"를 만드는 것이 어려운 이유 중 하나는 "X를 Y로 병합"하는 것이 항상 최선의 옵션은 아니라는 것입니다.X의 일부는 Y에서 잘 작동하지만 X의 다른 부분은 Z(등)에서 가장 잘 작동됩니다.따라서 우리는 합병을 다소 유연하게 유지할 필요가 있다.Blueboar (토크) 17:43, 2022년 7월 10일 (UTC)[응답]
• 여느 때처럼 구체적인 예를 몇 가지 들어보는 것이 좋습니다.위키피디아는 가정적인 사례보다는 구체적인 사례로 작동한다.OP가 말한 바와 같이 합병 과정이 기능하지 않는다는 증거로 시작할 수 있을까요? 합병 과정을 다시 작동시키기 위해 변경해야 한다는 내용입니다.필 브리저 (대화) 2022년 7월 10일 (UTC) 18:19 [응답]

  @Phil Bridger와 @TryKid는 하나의 사례보다 더 넓은 문제에 초점을 맞추고 싶기 때문에 특정 결과를 어필하는 것처럼 보이고 싶지 않기 때문에 구체적인 예를 생략하는 경우가 있다.이러한 경고와 함께, 여기에 투고하게 된 동기는, Talk에 있었습니다.동양학 #아시아학과 동양학과의 융합을 제안하며, 현재 아시아학이 시작되는 곳은 북미와 호주에서 주로 사용되는 동양학이라는 용어로는 유럽에서는 동양학으로 알려져 있다.{{u Sdkb}} 2022년 7월 10일 (UTC) 18:56 [응답]

• 합병안 등 토론 게시물에 반대표를 던지는 편향성이 있는 것 같습니다.중복에 대한 독특한 견해를 가진 목소리를 내는 중소기업의 반대표 한 장 한 장에 대해, 이 변화가 너무 상식적이기 때문에, 지지 코멘트를 남길 필요가 없다고 생각하는 12명 정도의 사람들이 있을 것이다.해결책은 논의 기간을 단축하고 WP가 뒤따르는 것일 수 있다.제안자의 굵은 결합입니다.Schierbecker (대화) 2022년 7월 10일 (UTC) 19:19 [응답]
• 많은 합병이 콘텐츠의 문제이며, 이 제안을 추진하는 명백한 문제는 병합 논의가 콘텐츠 에디터로부터 의견을 받는다는 사실입니다.– Uanfala (대화) 23:59, 2022년 7월 10일 (UTC)[응답]
• 제가 시작 및 참여한 몇 번의 통합 논의에서 제안서를 작성하고 (또는 페이지 크기나 병합 내용에 따라 더 길게) 한 달 정도 기다렸다가 반대 의견이나 의견이 없는 경우 직접 실행하는 것이 훨씬 수월하다는 것을 알게 되었습니다.WP를 필요로 하지 않는 한:HISTMERGE(대부분의 경우 병합하지 않아야 함) 굵은 병합은 나중에 누군가가 이를 반박하면 매우 쉽게 취소됩니다.무정부 (토크) 2022년 7월 11일 04:25 (UTC) [응답]
• Justletters and numberbers와 Talpedia는 최근 Wikipedia 토크에서 다음과 같이 토론했습니다.Wiki Project Medicine #이 점에 관련된 예방 및 사회 의료.이름만 가지고는 차이를 알 수 없지만, 실제로 물질적인 차이가 있을 때, "푸와 바는 둘 다 바즈의 유형이지만, 푸는 qux이고 바는 quuz이기 때문에 다르다"는 문단을 작성하고 소스화할 수 있어야 합니다.나는 그러한 논의의 실제 전문가가 그러한 출처를 확인하는 데 매우 적합하다고 생각한다.이러한 단락은 독자들에게 유용할 뿐만 아니라, 미래의 편집자들에게 왜 기사가 병합되지 않았는지를 분명히 할 것이다.WhatamIdoing (talk) 2022년 7월 11일 (UTC) 18:38 [응답]
  • 난 이것의 팬이야.제 경험으로 볼 때, 저는 이 경우 몇 개의 기사에 몇 가지 세부사항을 추가한 후 다른 기사로 넘어갔지만, 적어도 몇 가지 유용한 정보가 기사에 추가되었기 때문에, 이 링크는 미래의 독자나 편집자에게 병합 또는 추가 정보를 고려하도록 장려합니다.mation - 실제로 무엇이 진실인지 명확하지 않은 토크 페이지의 많은 메시지를 대신하는 좋은 방법일 수 있습니다.다시 한 번 말씀드리지만, 이러한 「메타 코멘터리」를 다른 분야와 비교해서 실시하는 출처를 찾는 것은 반드시 쉬운 일은 아니지만, 이것을 시도하고 있는 경우는 결국 성공했다고 생각합니다.
  • 나는 또한 때때로 두 주제를 비교한 문헌에 근거해서 병합이 항상 이루어지는지 확신할 수 없다.때때로 당신은 나머지 문헌들과 연결되지 않은 "자기포함된 문학"을 얻고 당신은 맥락화를 추가하기 위해 병합하기를 원할지도 모른다. (피해자 심리학과 트라우마가 떠오른다) 또는 (정신질환 부정과 반정신과) 그리고 병합 선택은 리에 근거한 것보다 편집상의 결정이다.테이터리이런 종류의 "사설 원본 연구"가 좋은 것인지 누가 알겠는가.기사의 "참조" 섹션과 관련이 있는 것 같습니다.Talpedia (대화) 22:37, 2022년 7월 12일 (UTC)[응답]
• 나는 이것을 본 적이 있고 그것이 합병 개혁을 생각나게 하지 않는다.IME, 합병 논의는 시간이 오래 걸립니다(보통 1년의 시간을 줍니다).당신은 종종 당신이 기대하는 결과를 얻지 못하고 나는 그것을 받아들이려고 노력한다.기사가 개선됨에 따라 일반적으로 문제가 더욱 명확해지고 일반적으로 사용자가 쉽게 이해할 수 있는 공감대가 형성됩니다.~Kvng (대화)13:50, 2022년 7월 13일 (UTC)[응답]
• 이것은 확실한 대답을 하기에는 너무 추상적인 제안이다.네, WP에 따르면 두 기사가 대부분 동일한 주제를 중복하는 것을 본 적이 있습니다.이것들은 실제로 통합되어야 합니다.다중 이름그러나 WP에 따르면 두 기사가 서로 다른 내용을 다루는 경우가 있다.MULTEPSUBJECTS는 계속 개별 기사로 취급되어야 합니다.Wiki Project가 도움이 될 것 같습니다.(비교:위키백과:개선 문서 또는 위키피디아:반달리즘 대책 유닛) 그러나 편견에서 벗어나기 어렵고 WP:B를 촉진할 위험이 있다.ATLGROUND는 더 많은 공감대 형성을 장려하는 대신.슈터워커 (토크)20:38, 2022년 7월 13일 (UTC)[응답]

  • WP가 있습니다.WPMERGE프로젝트 구성원들이 합병 제안을 마무리하는 데 있어서 나무보다 숲의 관점이 더 많이 흔들릴 수 있도록 더 권위적인 역할을 할 수 있다는 것을 제안하시는 것 같습니다.~Kvng (대화)20:56, 2022년 7월 13일 (UTC)[응답]

• 나는 합병 과정이 깨졌다는 것에 전적으로 동의한다. 독립 편집자들이 토론을 보는 것도 충분하지 않고, 토론이 종결되기까지 시간이 너무 오래 걸린다.WP에 병합 프로세스를 통합함으로써 이 문제를 해결할 수 있을지 의문입니다.RM. BilledMamal (대화) 21:54, 2022년 7월 13일 (UTC)[응답]
• Wikipedia를 통해 RFC를 통지받는 방법과 유사한 특정 토픽에서 요청된 병합을 통지받을 수 있습니까?피드백 요청 서비스?그렇지 않다면, 그런 도구를 사용하는 것이 도움이 될 것입니다.- 익스탈^{( T / C )} » WP에 가입:재무! 2022년 7월 16일 (UTC) 12:35 [응답]

  병합 요청은 WP에 포함됩니다.AALERTS. --Redrose64 🌹 (대화) 16:09, 2022년 7월 16일 (UTC)[응답]

• WP:Proposed Mergement를 유용한 것으로 전환하여 WP:RM처럼 기능하도록 하는 것, 즉 관련 기사 중 하나의 토크 페이지에서 아직 Mergement 논의가 이루어지지만 오픈 토론은 자동으로 중앙 집중화된 장소에 나열되는 것 등이 있습니다.위의 오리지널 투고에 대해서입니다만, 누군가가 토론에 늦게 와서, 이전에 반대하지 않았던 제안을 망치는 것이 얼마나 답답한지 알 수 있습니다만, 만약 그 유저가 주제 전문가라면, 그 유저의 의견을 듣고 싶지 않습니까?이것은 토론이지 여론조사가 아니므로, 그들의 초기 반대를 받아들여 합의가 도출될 때까지 더 논의하라.단, 누군가가 합병에 반대하여 오는 것을 진심으로 걱정하거나 싫어하고, 그러한 사용자가 합병에 그다지 강하게 반대하지 않거나(즉, 이미 합병이 일어났다면 이의를 제기하지 않을 것이다), 또는 토론에 더 많은 참여자만 있었다면 그들은 정말로 소수일 것이라고 믿는다면, 저는 그 점을 지적하겠습니다.1) WP에서 과감하게 결합할 수 있다는 사실:BRD 사이클은 시간이 지남에 따라 병합된 기사의 후속 편집으로 인해 과감한 병합을 되돌리는 것이 더욱 어렵고 문제가 되며 2) WP에 따라 최초 제안자에 의해도 1주일 후에 병합 논의를 종결할 수 있다.MERGE CLOSE. 따라서 MERGE 논의를 시작할 때 진정한 가치는 MERGE에 반대하는 페이지를 감시하고 있는 주제 전문가나 다른 사용자를 확인하는 것입니다.이런 일은 거의 본 적이 없고, 합병이 왜 현명하지 못한지에 대한 타당한 논거를 가지고 있는 경우도 있습니다.WP를 자주 접하게 됩니다.SURENT 또는 지원 코멘트를 1개 또는 2개 취득하여 되돌릴 수 없는 확실한 머지를 진행할 수 있습니다.보통 몇 달 동안 병합 논의를 진행할 필요가 없습니다. 많은 병합 토론이 진행되는 이유는 제안자가 다른 누군가가 병합하기를 기대하기 때문입니다.Marge를 해야 한다고 가장 강하게 생각하는 사용자가 Marge를 완료하면 위의 많은 문제를 피할 수 있습니다.그러나 전반적으로 IMHO의 병합 프로세스는 그렇게 끔찍하지 않으며 일부 사용자는 대부분의 사용자가 이를 따르지 않는 것이 문제라고 생각합니다.Mdewman6 (대화) 21:21, 2022년 7월 21일 (UTC) [응답]

변경 추적/편집 내역을 표시하기 위한 마크업 표시

Compare Selected Revisions diff 뷰어 대신.(Revision 1)에서 (Revision 2)로 선택한 후 실제 페이지에 중첩된 결과의 인라인 마크업/변경과 사용자별 색상 비교를 볼 수 있는 버전을 준비합니다.이러한 기능의 구현 참조는 Google Docs 협업 편집 기능으로, 각 사용자의 편집 옆에 색상을 표시합니다.예: 텍스트 추가(사용자 1, 00:00, 2022년 1월 1일)일부 텍스트(User2, 00:01, 2022년 1월 01)를 삭제했습니다.이름과 타임스탬프는 onHover/onMouseOver에서만 표시됩니다.이렇게 하면 포털과 같은 특히 활성 페이지에서 변경 내용을 쉽게 찾을 수 있습니다.current_events. 특정 편집이 추가 또는 삭제된 날짜를 찾기 어려울 수 있습니다.또한 특히 분쟁지역에서는 Added Removed Added Added Removed Added Removed처럼 보이기 때문에 편집 전쟁 페이지를 한눈에 보기 쉽게 만들 수 있습니다.Araesmojo (대화) 2022년 7월 13일 21:50 (UTC) [응답]

Wikipedia에 관심이 있을 수 있습니다.Wiki Blame 또는 mw:누가 썼어?WhatamIdoing (대화) 2022년 7월 18일 (UTC) 21:08 [응답]

@WhatamIdoing Thanks.누가 썼는지 그것은 내가 고려하던 것에 꽤 가깝다.그 도구에 대해 들어본 적도, 광고도 본 적도 없습니다.브라우저 확장 기능 이외의 통합 기능이라면 편리합니다.단, 이 답변이 아슬아슬하다는 것을 인정해 주십시오.WikiBlame의 이름은 이상하다.기능이 추가되어 있지만 권장했던 기능은 아닙니다.Araesmojo (대화) 2022년 7월 28일 19:28 (UTC) [응답]

바이탈 다이렉트

지난 15년간 전혀 진척이 없었던 WP:Vital Argents의 생산을 촉진하기 위한 계획을 정리했습니다.이 계획에 대해 어떻게 생각하고 어떻게 개선할 수 있을까요?CactiStaccingCrane (토크) 2022년 7월 15일 (UTC) 02:29 [응답]

누구 없어요? CaptiStaccingCrane (대화) 2022년 7월 27일 (UTC)[응답]

이 페이지의 어디에 계획이 있는지 잘 모르겠어요.웨이크 램프 d[@-@]b (통화) 5:10, 2022년 7월 29일 (UTC)[응답]

Vital Direct 계획은 다음과 같습니다.2개의 중요한 GA를 만듭니다.하나는 광범위하고 하나는 논란의 여지가 있습니다.그렇게 하면 다른 중요한 기사에 대해 많은 경험을 쌓을 수 있을 뿐만 아니라 프로젝트에 대한 신뢰를 얻을 수 있을 것이다(WP의 방법과 유사함).밀히스트 및 WP:지금까지의 AVIATION은, 지금까지의 경험이 있습니다).또한 2개의 GA를 만드는 것은 첫 번째 성공이 단순한 요행이나 과대 광고가 아니라는 것을 증명할 것이다.리드/이미지/레이아웃을 먼저 개선한 다음 인용문을 인용하지 않은 문장에 추가합니다.그 후에야 전문가의 지식이 필요하게 되는데, 그 지식은 기사에 실린 수많은 활동에서 알 수 있을 것이다.그들을 유인하고 그들과 협력하라.산문을 개선하지 말고 먼저 읽을 수 있도록 하세요.이러한 프로세스를 효율적으로 실시하면, 약 2개월에서 6개월의 시간이 걸립니다.

그런 다음 그룹이 만족하면 간단한 복사 편집과 최종 확인이 이루어지고 기사가 GA 후보로 지명됩니다.지명이 실패했을 경우, 마지막 검토자가 만족할 때까지 개선합니다.후보 지명이 성공적이라면, 잘했다, 나가서 술이나 한잔하고, 다른 GA와 함께 일하자.그 기사는 우리가 원한다면 FA까지 밀고 갈 수 있지만, 그것은 의무적이거나 필요하지 않다.그때까지 이러한 노력들이 다른 편집자들이 솔선수범하고 같은 일을 하도록 영감을 주길 바란다.저는 원래 과학과 미국에 도전하려고 했습니다만, 전자는 매우 어렵고, 후자는 현재 LTA에 시달리고 있습니다.그 대신 경험을 쌓기 위해 짧은 Vital 기사를 확장해 보는 시승을 준비했습니다.CactiStaccingCrane (토크) 2022년 7월 29일 06:06 (UTC) [응답]

인센티브 기사 개선

배경:ArbCom은 삭제 관련 편집에서 수행에 대한 증거를 수집하기 위해 몇 주 정도 걸립니다.저는 제가 근본적인 문제로 인식하고 있는 것에 대한 해결책을 보고, 생각하고, 상상하고 있습니다.외견상 문제는 WP에서의 행동이다.AFD. 이 아이디어는 편집자의 행동에 동기를 부여하는 문제를 다루려고 시도합니다.

여기서 이 문제를 제기했는데, @Tryptofish가 여기에 글을 올리라고 제안합니다.

문제(아마추어 심리학) :문제는 인간의 성향이다.지역 신문의 개교 1면을 장식하는 정치인을 생각해 보자.조용하고 원활한 학교 운영을 위해 어떻게 정치인이 1면에 실리지 않는지 생각해 보세요.인간의 본성, 우리는 무언가를 유지하는 것보다 시작하는 것을 더 중요시한다.그리고 여기도 마찬가지입니다.편집자는 우리가 작성한 기사 수, 도구를 통해 이를 확인하고 비교할 수 있습니다.경쟁의 즐거움, 게이미피케이션 등 우리 본성에 부합합니다.제가 알기로는 툴로는 우리가 얼마나 많은 기사를 개선했는지 쉽게 알 수 없습니다.사용자 페이지에서 자신이 얼마나 많은 영재적인 개선을 했는지 자랑하는 편집자는 적다고 생각합니다.새로운 기사를 만들 때마다 약간의 도파민 주사를 맞는 것은 나뿐만이 아니라고 확신한다.마찬가지로, 나는 사람들이 얼마나 많은 나쁜 페이지를 삭제했는지 사용자 페이지에서 자랑하고 있는 것을 보았다. 나는 사람들이 백과사전을 개선하고, 쓰레기들을 제거하고, 표준을 유지했다는 것을 알고는 약간의 만족감을 느낄 것이라고 확신한다.따라서 우리는 생성에 대한 보상과 삭제에 대한 보상을 거의 주지 않는 도구와 문화의 지원을 받는 행동을 하게 됩니다.보상은 명확하지 않고 인센티브는 약하며, 물품 개선을 측정하거나 실시해야 합니다.인간은 인센티브에 반응한다.우리는 우리 자신에 대해 좋게 느끼기를 좋아하는 감정적인 동물이다.우리는 우리가 측정할 수 있는 것을 하는 경향이 있다.

권장되는 전략적 솔루션:우리는 기사 개선을 장려할 필요가 있다.매스 스탭의 작성은, 올림픽 선수, 스포츠 피플, 섬, 또는 TV 쇼에 관한 이러한 모든 기사가 주목된다고 하는 전제하에, 그것들을 개선하기 위한 대등하거나 큰 노력이 없는 경우에만 문제가 된다고 생각합니다.나는 그것을 창조한 사람들의 성의를 믿는다.문서 개선을 측정할 수 있는 더 나은 방법이 있다면 위키피디아는 더 좋을 것이다.우리는 게이미피케이션을 추가할 필요가 있다: 기사를 개선하기 위한 노력에 따라 편집자의 순위를 매긴다.물품구조대는 물품개선팀으로 불렸어야 했을지도 모른다.아마도 이것을 디플레이션과 포섭주의자들 사이의 긴장으로 해석하는 경향은 잘못된 것이고 그것은 기사 개선 노력과 인센티브의 부족에 대한 더 큰 문제이다.CT55555 (대화) 2022년 7월 15일 (UTC) 21:12 [응답]

• 랭크 에디터는 어떻게?이미 Wikipedia와 같은 다양한 정보가 있습니다.문서 수, 위키피디아:편집 횟수별 위키피디아 목록, 위키피디아:추천 목록에 따른 위키피디아 목록, 위키피디아:특집 기사 후보에 따른 위키피디아인 목록 및 이와 유사한 기사 후보 목록과 더불어 사람들은 이미 WP의 별과 다른 형태의 WikiLove를 수집했습니다.고맙습니다.그들이 작업한 좋은 기사 등일부 영역에서는 밀린 작업을 개선하기 위해 다양한 게이밍 드라이브가 있습니다(예: Wikipedia에 참여하고 있습니다).새 페이지 순찰/백로그 드라이브(2022년 7월) 및 특히 Wikipedia와 같은 NPP에 대해 생각해 보십시오.데이터베이스 보고서/최고 신규 기사 검토자 등하지만 WP도 의식하고 있습니다.EDITCOUNT. 저는 개인적으로 기사를 많이 만들지 않고 WP에 가깝습니다.GNOME/WP:ELF - Kj cheetham (대화) 13:56, 2022년 7월 16일 (UTC)[응답]

  나는 다른 사람들이 어떻게 하는지에 대한 아이디어로 동참하기를 바란다.하지만 난 여전히 우리가 너처럼 나에게 인센티브를 줘야 한다고 생각해.일화에 의존할 위험이 있지만, 제가 만든 기사를 누구보다 많이 편집하셨다고 생각합니다.또한 당신의 롤모델 행동은 통계적으로 특이하다고 생각합니다.다른 사람의 작품을 깎아내릴 생각은 없지만, ArbCom의 사례를 읽으면서 알게 된 것은 기사 개선을 희생하면서 작성과 삭제에 너무 집중한 결과입니다.질문해야 할 것 같은데, 우리가 그걸 병에 담아 재현할 수 있는 동기는 무엇일까요?

  또한 "편집 횟수"는 기사 개선보다 편집과 같은 작은 봇을 장려한다고 생각합니다.Wikipedians를 추가된 콘텐츠의 볼륨(kb)으로 비교하는 것이 아닙니다.Wikipedians는 stub에서 개량된 기사 수로 비교하는 것입니다.CT55555 (대화) 2022년 7월 16일 14:09 (UTC) [응답]

  저는 '일반적인' 에디터가 아니라고 생각합니다.:) stub에서 이동한 기사를 바탕으로 한 통계는 프로젝트 담당자의 수동 분류에 의존한다면 기술적으로 추적하기가 매우 어려울 것이라고 생각합니다.콘텐츠의 양에 따라서는 흥미로울 수도 있지만...https://xtools.wmflabs.org/ec/en.wikipedia.org/Kj_cheetham 같은 것은 적어도 한 에디터의 평균 편집 크기, 작은 에디터와 큰 에디터의 비율을 알려주고, https://xtools.wmflabs.org/authorship 같은 것들은 한 기사에 어떤 부분 편집자가 기여했는지 알려준다.나는 대부분의 사람들보다 통계를 보는 것이 더 흥미롭다고 생각한다. (나는 매우 과학적인 배경을 가지고 있다.)Barnstars 및 Wikipedia:서비스 상은 저에게 약간의 동기부여가 되고 숫자가 증가하는 것을 볼 수 있지만, 저는 보통 다른 사람들이 하기 싫어하는 "지루한" 일을 함으로써 일을 더 좋게 만드는 것을 좋아합니다. 하지만 저는 대부분의 시간을 전기에만 집중합니다.나는 대부분의 경우 논쟁의 여지가 없는 것에 집착하려고 노력한다(따라서 나는 WP와 같은 것에 종사한다).토론을 끝내는 것보다 RMTR)과 드라마 보드에 거의 관여하지 않고 편집하는 것을 좋아합니다.-Kj cheetham (대화) 2022년 7월 16일 (UTC)[응답]

  기사 개선을 권장하는 몇 가지 방법이 있습니다. 예를 들어, 5배 확장 DYK는 WikiCup 포인트를 획득하는 훌륭한 방법입니다.'우먼 인 그린'이나 '코어 콘테스트'와 같은 개선 프로젝트도 있다.그러나 DYK 및 GA/FA 이외의 콘텐츠 작성 및 개선을 축하할 수 있는 방법이 더 필요할 수 있습니다.-Kusma (토크) 2022년 7월 16일 (UTC)[응답]

• 제 동료 편집자 중 한 명이 위키피디아는 비디오 게임이 아니라고 말했고, 저는 진심으로 동의합니다.인간은 이렇게 격식을 차리지 않고 계층 구조를 만드는 데 능숙하다.우리는 이미 사용자 페이지와 barstar에 우리의 작품 목록을 가지고 있다.나는 기사를 쓰려는 사회적 지위에 기초한 어떠한 인센티브도 반대한다.또 다른 편집자는 DYK – 메인 페이지 노출은 새로운 기사 또는 확장된 기사에 대한 매우 공식적인 DYK 크레딧과 마찬가지로 분명 훌륭한 보상이라고 지적했습니다.thelekycauldron (talk • contributes ) (그녀/그녀들) 2022년 7월 17일 (UTC) 03:50

  @Thelekycauldron Wiki로 가는 길은 하나밖에 없다고 생각하지 않도록 주의해야 한다고 생각한다.분명히 지름길이 있을 텐데 기억이 안 나네요.사회적 지위에 대한 인센티브를 원하지 않는 사람들은 이해하지만, 3, 40,000명의 정규 편집자가 있습니다. 저희는 대부분 익명으로 되어 있기 때문에 그 지위는 그다지 높지 않습니다.웨이크 램프 d[@-@]b (통화) 2022년 7월 17일 (UTC)[응답] 12:56

@CT55555 "아마도 이것을 디플레이션과 포섭주의자들 사이의 긴장이라고 생각하는 경향은 잘못된 것이며, 기사 개선 노력과 인센티브가 부족하다는 것이 더 문제일 것이다."찬성합니다.제 개인적인 고민은 태그 바이 드라이브, 그리고 다양한 "이 기사는 개선이 필요합니다" 태그입니다.네, 문제를 발견하셨습니다.잘했습니다.이제 해결하세요.그것은 부분적으로 인센티브의 불일치와 힘의 불균형 때문이라고 생각한다.NPP 툴을 사용하면 태그로 Galaga를 재생하는 경우보다 편집 속도를 높일 수 있습니다.WP가 개선되는가?웨이크 램프 d[@-@]b (통화) 2022년 7월 17일 (UTC)[응답] 12:58

문제는 태그 부착은 고치기 위한 단계라는 거죠.기사를 읽는 것만으로 문제를 특정할 수 있지만, 그 문제를 해결하는 방법을 알 수 있을 만큼 주제를 잘 알지 못합니다.예를 들어, "음... 이 문장은 출처가 필요합니다"라고 말할 수 있지만, 최적의 출처가 무엇인지 알 수 없기 때문에 "인용 필요" 태그를 붙여 다른 편집자(토픽의 가장 좋은 출처를 알고 있는 편집자)가 후속 조치하여 필요한 인용을 추가할 수 있도록 합니다.Blueboar (대화) 2022년 7월 17일 (UTC) 13:27 [응답]

@Blueboar 인용 태그에서는 50/50입니다.이것은 훌륭한 콜라보레이션 툴이지만,

• 스터브에 태그를 붙이는 것은 장황한 일이기 때문에 중간급 기사에 태그를 붙이는 것은 확실치 않지만, 말씀하신 이유로 다른 기사에 대해서는 동의합니다.위키백과:템플릿 인덱스/정리에도 동일한 권장 사항이 있습니다.
• 태그 부착은 WP가 부정적인 방식으로 작동하는 방식을 형성하는 것입니다.편집자가 태그를 지정하면 후속 편집자에게 응답성을 이동시킴으로써 가려움을 해소합니다.충분한 에디터가 존재한다면 훌륭한 프로세스가 될 것입니다만, (주소 불명의 태그 편집의 경과나 대량의 잔량에 근거해) 그렇게 되지 않습니다.대신 대량 태깅은 새로운 편집자가 머물 수 있도록 변경의 충동성을 줄이는 방법으로 볼 수 있습니다. Wake lamp d[@ - @ ]b ( talk ) 03 : 36 , 2022 ( UTC ) [ reply ]

나는 특정 종류의 태그는 무의미하다고 생각한다.원센스 서브서브에 (보이는) {{각주}}배너가 필요합니까?난 그렇게 생각 안 해.저는 그것이 우리에게 가치를 제공한다고 생각하지 않습니다. 그리고 저는 독자들이 매우 짧은 기사에서 작은 파란색 클릭 수를 셀 수 없을 정도로 멍청하다고 생각하지 않습니다.대부분의 독자들은 적어도 세 개까지 꽤 확실하게 셀 수 있다.

또, 이 태그가 페이지 상부에 머무르는 것만으로 개선되는 것은 아닌지 의심됩니다.만약 누군가가 적극적으로 기사를 개선한다면, 그들은 응답할 것이다. 하지만 오랫동안 아무도 기사를 실질적으로 수정하지 않는다면, 그것은 아마 무의미할 것이다.

또한 편집의 경우, 많은 편집을 하는 방법은 일반적으로 중요한 것을 하지 않는 것입니다.작은 포맷 오류를 수정합니다.반려동물 WP 제거:클리체. 만약 당신이 정말로 기사를 개선하기 위한 공모전을 원한다면, 위키피디아는:인용 헌트에는 리더보드가 있습니다.이번 달 지도자는 51개의 표창장만 올렸다.넌 분명히 이길 수 있을 거야.WhatamIdoing (대화) 2022년 7월 18일 (UTC) 21:17 [응답]

태그의 정당성은 사용자들에게 편집자가 되라고 촉구하기 때문입니다.이에 대한 이유는 개인적인 경험입니다. 그러나 최초 편집이 태그 수정이나 …이라는 확실한 증거는 없지만, 우리의 프로세스에서 어떤 정량적 데이터가 매력적인지 확신할 수 없습니다.

나는 "대부분의 독자들은 적어도 3명까지 꽤 확실하게 셀 수 있다."는 것에 동의하지 않을 수 없다. 왜냐하면 나는 워터십 다운스에서 토끼가 4명까지 셀 수 있다고 기억하기 때문에 우리는 과소평가되었다고 생각한다. :-)

그리고 나는 진부한 말투로 말하는 것을 피하려고 노력할 것이다, 다만 "적절한 시점에.시간이 다 되어가는 동안.때가 되면.필요한 절차가 완료되면물론 급할 일은 없다.네, 장관 시즌1 에피소드5 웨이크 램프 d[@-@]b (대화) 2022년 7월 19일 06:14 (UTC)[응답]

그리고 독자가 토끼의 지능을 가지고 있다고 가정하면 참조 태그가 4개 이하인 스터브에 {{more 각주}}을 붙이지 않아도 됩니다.WhatamIdoing (대화) 2022년 7월 26일 (UTC)[응답]

또한, 우리는 이러한 태그가 실제로 독자를 편집자로 전환하는 데 바람직한 효과를 가지고 있다는 증거를 훨씬 더 많이 가지고 있지 않다.그럴듯하지만 검증되지 않았다.WhatamIdoing (대화) 2022년 7월 26일 (UTC)[응답]

태깅은 문제가 되지 않는다고 생각합니다.태그와 태그 제거는 둘 다 합니다.기사(새로운 기사 작성부터 나쁜 기사 구제까지)를 개선하고 다른 기사를 삭제합니다.IMHO, 태그는 "나쁘게 보인다"며, 우리의 기사가 진행 중이고 독자들에게 더 명백하게 작동하도록 만들지만, 무엇이 수정되어야 하는지를 나타내는 지표로서, 그리고 그래, 많은 기사가 끝나지 않았고 그들이 도움이 될 수 있다는 것을 독자들에게 상기시켜준다.술래잡기 폭격이 심미적으로 즐겁지 않다는 것은 인정하지만, 저는 괜찮다고 생각합니다.보기 좋은 나쁜 태그 없는 기사는 독자들에게 도움이 되지 않는다.모든 사람이 문제가 있음을 깨닫는 것이 좋습니다.그러면 모르는 독자에게 좋은 문제 콘텐츠로 덮어두는 것이 좋습니다.11:28, 2022년 7월 18일 (11:28)

지금까지 AfD에 기사를 제출하기 전에 알림 태그를 사용하여 편집자에게 알림 문제를 해결할 시간을 주려 했습니다.편집자의 매우 부정적인 반응으로 인해 저는 더 이상 그렇게 하지 않지만, 일반적으로 좋은 관행이며, 기사를 개선하거나 삭제함으로써 백과사전을 개선하기 위한 단계라고 생각합니다.청구된 맘말(대화) 2022년 7월 18일 13:23 (UTC)[응답]

• 나는 NPPers가 과잉 태그 부착 또는 즉시 문제에 대처하지 않은 것에 대한 근본적인 제안이 있음을 감지한 것 같다(그러나 내가 틀렸다면 이미 사과한다).다만, 수정품은 NPP의 소관이 아니라는 것을 지적하고 싶습니다.만약 그렇다면, 엄청난 밀린 업무는 더 커질 것입니다.또한 아무리 경험이 없어도 기사에 태그를 붙일 수 있습니다.그들이 할 수 있는 유일한 것은, 색인 작성에 관한 검토에 의해서 그것들을 건네주는 것입니다.수백만 개의 영구 태그가 달린 글이 있으며, 그 대부분은 결코 개선되지 않을 것입니다. 위키피디아는 적어도 새로운 글의 작성자들이 '게시'를 클릭하기 전에 최소한 필요한 기준을 인식하도록 하기 위한 방법을 찾아야 합니다. 현재 그들은 정보를 받지 못하고 있습니다.Kudpyung 2022년 7월 19일 (UTC) 00:57 [응답]

  제 제안은 NPP와는 전혀 관계가 없습니다.그건 제가 충분히 알고 있는 것입니다.방대한 수의 새 페이지를 검토하기 위해 노력하는 편집자들에 대해 좋은 말밖에 없다.나는 달리 제안할 의도가 없었다.CT55555 (대화) 2022년 7월 19일 (UTC) 01:47 [응답]

CT55555는 일반적인 관찰로 스레드에서 감지된 경향에 대해 특별히 당신에게 책임이 있다는 것을 시사하는 것은 없었습니다.단, WP의 다음 사항에 대해 자세히 알고 싶을 수도 있습니다.NPP는 사용자 권한과 도움말에 대한 모든 것을 적용하고 신청합니다.당신은 이미 충분한 경험을 가지고 있는 것 같기 때문에, 매우 감사하게 생각합니다.Kudpyung 2022년 7월 19일 (대화) 02:16 (UTC)[응답]

고마워, 전에도 생각해 봤어그 과정을 보고 사용자 인터페이스와 규칙에 조금 위축되어 기사 작성에 집중하기로 했습니다만, 다시 생각해 보겠습니다.그것이 대립을 불러 일으키는 역할이며, 저는 이미 위키피디아에서 한발짝 물러선 상태이지만, 이제 이 공간을 더 이상 그것에 대한 배출구로 사용하지 않겠습니다.행운을 빌어요.CT55555 (대화) 2022년 7월 19일 (UTC) 02:20 [응답]

@CT55555 나는 내 앞으로 온 것을 기억한다.인센티브를 선택하는 것은 까다로울 수 있습니다. 특히 인센티브가 포괄적이거나 희망 경로에 부합하지 않는 경우 의도하지 않은 결과가 발생할 수 있습니다.조직/사람의 어떤 부분도 다른 사람을 희생시켜 자신을 최적화하고 본래의 목표를 달성한다는 속담(참조 내용을 기억할 수 없다)이 있다.

새로운 인센티브를 거부하거나 기존 지위를 떨어뜨리는 것은 매우 인간적인 일입니다.비록 우리가 비디오 게임이 아니더라도, 사람들은 그들의 ggo 믿음에 대한 인정과 만족을 받을 자격이 있다.

@Kudpyung NPP는 훌륭하다고 생각합니다만, NPP 페이지의 기사에서 인정하고 있는 툴의 오용의 가능성이 있습니다.

그렇다면, NPP/자동 툴 사용자가 추가한 태그 수 중 몇 %에 대한 통계는 있습니까?약 10년 전, NPP 툴의 크리에이터가 WP를 어떻게 변화시켰는지, 특히 새로운 에디터를 어떻게 변화시켰는지에 대한 불안감을 표현한 WMF의 기초 논문이 있었다.NPP는 신규 기사 작성자를 제공하지 않는 툴을 사용하여 신규 기사를 자동으로 판단합니다(10시간 작업 대 리뷰 10초).우리가 하지 않는 이유는 구글이 SEO를 두려워하여 호출기를 공개하지 않는 것과 같은 방법으로 이러한 도구를 사용할 수 있기 때문입니다.

웨이크 램프 d[@-@]b (통화) 2022년 7월 19일 07:36 (UTC)[응답]

Wakelamp, New Page Reviewers는 작업에 자동화된 도구를 사용하지 않으며 기사 작성자를 판단하거나 비판하지 않습니다.Twinkle과 New Pages Feed에서는 리뷰된 기사를 전달할 수 있는 것 외에 사용할 수 없는 툴은 없습니다.모든 것은 새로운 기사의 품질과 주목도를 정확하게 평가할 수 있는 충분한 지식과 경험을 바탕으로 하며, 대부분의 경우 출처를 확인하는 것을 의미합니다.새로운 페이지를 충분히 검토하는데 10초 정도면 충분하다고 생각하는 NPP가 있다면 매우 걱정입니다.

NPP 툴 크리에이터의 10년 된 논문에 대해서는 아는 바가 없지만, 꼭 읽어보고 싶습니다.저는 개인적으로 툴 크리에이터 팀을 알고 있었습니다.2012년에 그들과 새로운 NPP 시스템 개발에 협력했습니다.도구 또는 ACTRIAL의 부정적인 효과는 WMF에 의해 철저한 과학적 연구에서 완전히 반증되고 인정되었습니다.Wikipedia가 원하는 것은 적절한 평가의 새로운 페이지 리뷰어, 몇 가지 버그와 소프트웨어의 몇 가지 새로운 기능, 그리고 그것들을 적절하게 작성하기 위한 새로운 사용자들에 대한 더 나은 인센티브입니다.

아마도 가장 좋은 해결책은 기사 마법사의 디자인과 기능에 대한 끊임없는 실험을 끝내고 UX와 커뮤니케이션 연구의 전문적인 원리에 맞게 재구성하여 세련된 현대적 외관을 제공하고 새로운 편집자에게 이 마법사를 사용하도록 하는 것입니다.'누구나 편집할 수 있는 백과사전'이라는 만트라는 '위키피디아에 와서 스팸, 정크, 이력서, 그리고 차고 밴드를 여기에 버리세요'를 의미하지 않는다. Kudpyung 2022년 7월 19일 (대화) 10:48 (UTC) [응답]

새로운 기사 작성자가 페이지 큐레이터 도구에 접근할 수 있어야 한다고 생각하십니까?특히 신뢰할 수 있는 소스 체크요?웨이크 램프 d[@-@]b (대화) 2022년 7월 20일 (UTC)[응답] 11:57

첫째, "New Page Reviewers does not use an automated tool" @Epochfail은 이러한 툴을 반자동 툴이라고 부릅니다.그러므로 둘 다 옳습니다.웨이크 램프 d[@-@]b (대화) 2022년 7월 20일 23:11 (UTC)[응답]

둘째, "그리고 그들은 기사 작성자를 평가하거나 비판하지 않는다" 영어 위키피디아에 대한 간접적으로 새로운 편집자에 대한 경고의 증가..우리는 뚜렷한 경향을 발견했다.기여에 대한 칭찬이 현저하게 감소하고(단순히 "그 기사에 대한 훌륭한!"에서 "바스타에 이르기까지"에 대한 경고와 비판이 동시에 증가하고 있다), 페이지 큐레이터는 "70개 이상의 다른 태그가 제공되고 있다.한 번에 페이지에 추가할 수 있습니다.웨이크 램프 d[@-@]b (대화) 2022년 7월 20일 23:11 (UTC)[응답]

셋째, '10초 정도면 새 페이지를 충분히 검토할 수 있다고 생각하는 NPP가 있다면'찬성합니다.너무 과장이 심했는데 PDQ인 것 같아요.NPP는 페이지 리뷰에 어느 정도의 시간을 소비합니까?웨이크 램프 d[@-@]b (대화) 2022년 7월 20일 23:11 (UTC)[응답]

넷째, "Paper by NPP tool creator. 하지만 꼭 읽어보고 싶습니다." @Epochfail metawiki:조사:newcer_quality 2012 "지수가 기하급수적으로 증가하는 바람직하지 않은 신규자에 대응하기 위해 반자동 되돌리기 툴이 도입되었습니다.결과에 따르면 이러한 툴을 사용하여 바람직하지 않은 신규자를 거부하는 것은 바람직한 신규자의 편집에는 거의 영향을 미치지 않을 수 있지만 선의의 신규자의 바람직하지 않은 편집은 거부할 수 있습니다.2013년." "구체적으로, 백과사전의 주요 품질 관리 메커니즘과 기여 거부에 사용되는 알고리즘 툴의 제약이 신규 보유 감소의 주요 원인이다.또한, 표준 표현에 대한 커뮤니티의 공식 메커니즘은 변화에 대해 석회화된 것으로 나타났습니다. 특히 새로운 편집자가 제안한 변경 사항입니다." 및 2011년 "신입자를 물지 마십시오. 복구가 위키피디아 작업의 양과 질에 어떻게 영향을 미치는가.

다섯째, "이제 더 많은 새로운 페이지 리뷰어를 원하는 것" W. Edwards Deming은 이 같은 문제를 해결했습니다.Deming은 Total Quality Management를 고안하여 처음에는 미국에서 거의 영향을 미치지 않았지만 "Made in Japan"을 불량품에서 [Deming_Prize 최고품질]로 변화시켰습니다.그 당시 미국 제조업에는 품질 검사원이 많이 있었지만, 노동자나 "새로운 편집자"가 그들의 일에 대한 자부심이나 통제력을 갖는 것을 허락하지 않았다.

여섯째, "UX와 커뮤니케이션 연구의 전문적 원칙에 따라 재구성하고, 세련된 현대적 외관을 주며, 새로운 편집자에게 그것을 사용하도록 주장하라."이거 안 되겠다.웨이크 램프 d[@]b (통화) 2022년 7월 20일 (UTC)웨이크 램프 d[@-@]b (통화) 2022년 7월 20일 (UTC)[응답]

@Wake lamp, 위의 코멘트는 매우 이해하기 어려운데, 특히 외견상 임의적인 nowiki 태그가 많기 때문입니다.Duh 박사 🩺 (대화) 2022년 7월 20일 (UTC)[응답]

@닥터 Duh씨, 감사합니다.nowiki 태그에 대해 사과드립니다.편집자가 고장나서 다른 곳에서 복사했습니다.이게 나아요?웨이크 램프 d[@-@]b (대화) 2022년 7월 20일 23:11 (UTC)[응답]

이 편집으로 몇 가지 잘못된 링크를 수정했습니다만, 감사합니다.Duh 박사 🩺 (대화) 2022년 7월 21일 06:52 (UTC)[응답]

@꾸드풍 그래서 어떻게 생각해?웨이크 램프 d[@-@]b (통화) 09:36, 2022년 8월 2일 (UTC)[응답]

사이드바 노트 1개20년 이상 수많은 사람들이 작업해 온 백과사전은 대량 또는 대량으로 제작하는 것이 유익한 영역이 남아 있지 않습니다.North8000 (대화)13:13, 2022년 7월 20일 (UTC):[응답]

@[[사용자 토크:North8000#톱토크]스탭을 더 만들자는 제안은 없다고 생각합니다.기존 스탭의 품질을 높입니다.웨이크 램프 d[@-@]b (통화) 2022년 7월 26일 09:42, UTC[응답]

@Kj cheetham 저는 이것이 훌륭한 아이디어라고 생각합니다.하지만 인센티브를 제공하더라도 충분한 인원을 확보하는 것이 가장 중요하지만 해결 가능한 문제가 될 것입니다.각각 1시간에 위키피디아가 있습니다.Content_assessment 400만 시간은 stub으로 동작합니다.그럼, 사람들을 어디로 데려와...

• 새로운 에디터로는 해결할 수 없습니다.편집자 보유율이 감소하고 WP를 이해하는 데 몇 년이 걸리며 다른 프로젝트와 경쟁하고 있습니다.
• 편집자를 비생산적(카테고리 할당, 태그, 템플릿 추가)에서 전환하고 있습니다.)가 도움이 될 수도 있습니다.
• lomg term 에디터를 경합을 줄여 두면 도움이 되지만, stub에 대해서는 잘 동작하지 않는 경향이 있습니다.
• 프로세스 변경 및 툴은 시간당 작업량을 줄일 수 있지만, 최선의 방법은
• 크라우드 소싱.최초의 옥스포드 영어 사전 군중들은 참고 자료를 제공했지만, 경험이 많은 편집자들이 체크했다.stub에 주목하지 않는 플래그를 붙이는 옵션을 사용하여 자동화된 큐레이티드목록에서 관련 참조 선택을 크라우드 소스할 수 있다.스텁은 검토자의 관심 영역 내에서 무작위로 선택될 것이다.기사가 업데이트되기 전에 여러 사용자가 동일한 기사를 확인할 수 있습니다. 반달에 대한 인센티브는 없습니다.따라서 WP 대신 사용자는 Wiki를 사용하지 않고 [this] Wakelamp d[@-@]b (talk) 09:42, 2022년 7월 26일 (UTC)[reply]와 같은 오픈 소스 소셜 웹사이트를 사용합니다.

위키피디아는 이미 크라우드소싱의 전형이다.무작위로 지나가는 사람이 등록하지 않고도 콘텐츠를 개선할 수 있는 몇 안 되는 웹사이트 중 하나입니다.우리는 편집자가 개선하고자 하는 기사에 대한 제안을 요청할 수 있는 몇 가지 이니셔티브를 가지고 있습니다. 어쩌면 더 나은(어떻게) 기사를 만들고 더 두드러지게 만들 수도 있습니다.증명서 (토크)12:49, 2022년 7월 26일 (UTC)[응답]

WP가 크라우드 소싱에 능하다는 건 인정하지만 편집자 유지와 다양성에 문제가 있어요

그러나 개선해야 한다는 요구와 함께 개선해야 한다는 현재의 요구가 효과가 있는지에 대한 통계는 없습니다.긴 메시지에 짜증이 나는 실제 사용자 경험 작업이 많기 때문에 실제로는 해가 될 수 있습니다.템플릿이 추가된 연령은 WP Wakelamp d[@-@]b (talk) 2022년 7월 26일 (UTC)[응답] 23:02 (UTC)[응답]의 인지 품질을 저하시킬 것으로 생각됩니다.

기사와 쟁점이 너무 다양해서 어떤 노력도 지나치게 일반화 될 것이다.나는 스텁을 확장하는 것에 너무 집중하지 않을 것이다.우리는 아마도 100만 개의 지리적, 종적 스텁을 가지고 있을 것입니다.그것은 괜찮지만, 느리고 확장하기 어려울 것입니다.기사가 되어서는 안 될 1/200만 원짜리 스탭이 있을 거예요우리의 새로운 기사의 흐름의 대부분은 홍보용(희망하는 음악가, 야심찬 발리우드 배우, 그들에 관한 기사를 만들기 위해 돈을 지불한 사업가, 스포츠 선수, 미래의 앨범, 미래의 영화, 미래의 토너먼트)이며, 사람들은 현실 세계를 가리키는 것을 피하기 위한 기사의 일부가 되어서는 안 되는 위키피디아 취미로서 기사를 대량 생산한다.'내 위키피디아 취미는 우리 동네 집집마다 기사를 쓰는 것 같아'라고 하면 돼요.IMO: Wikipedia가 더 많은 작업을 통해 얻을 수 있는 실질적인 영역은 다음과 같습니다.

• 대상 분야의 전문가가 필요한 경우.하지만 위키피디아 대체 우주를 배울 필요가 있는 것과 위키피디아는 그렇게 악랄한 장소인 것 사이에서 그것들은 얻기 어렵고 유지하기가 어렵다.
• 다른 언어 Wiki에서 가져온 문서입니다.다른 나라의 많은 실질적인 주제들은 아직 영어 위키피디아에서 다루어지지 않았다.하지만 수입될 때, 그들은 많은 문제를 겪는다.
• (미국 정치가 그 목록의 맨 위에 있는) 실제 세계에서의 싸움과 관련된 기사는 모두 상태가 좋지 않지만, 그것을 고치려고 하는 사람은 영리한 전사들에게 도륙당할 것이다.수정하려면 정책을 변경해야 합니다.

마지막으로 위키피디아는 점점 더 배우기 어려워지고 있다.그것을 쉽게 하려는 노력이 잘못되었다.예를 들어, 복잡한 문서화되지 않은 템플릿과 복잡한 다단계 참조 아키텍처를 사용하여 참조를 추가하는 방법을 파악하면서 이미 쉬운 것을 하향 조정(기본 텍스트 편집)하는 경우입니다.North8000 (대화)2022년 7월 26일 21:19 [응답]

North8000 (대화)2022년 7월 26일 (UTC) 21:19 (대화) @ (대화)

훌륭한 분류법.큰 문제에 관한 제안을 정확하게 평가하려면 항상 통계가 필요합니다.진행률 측정(신규/다운그레이드/업그레이드), 사용자(#편집자, 독자, 액티브워처) 및 연령(태그 개선, 최종편집, 작성, 토픽의 날짜)을 알아야 합니다.이 세부사항을 어떻게 알 수 있을까요?2022년 7월 26일 23:02, UTC

WP:Vital Direct라는 마을 펌프에서 대부분 포기된 제안이 있습니다.약간의 수정이 있으면, 이 계획은 삭제론자와 포섭론자 사이의 많은 격렬한 갈등을 효과적으로 해결할 수 있을 것이라고 생각한다.포섭주의자들은 기사에 내용을 추가하고, 삭제론자들은 기사에서 난잡한 내용이나 스팸을 걸러낸다.그리고 저를 믿으세요, 개선해야 할 매우 짧지만 중요한 기사들도 많이 있습니다.이는 신중한 계획과 실행을 통해 달성할 수 있는 매우 야심찬 목표(10년 내 모든 중요한 조항 GA/FA)를 설정함으로써 이루어집니다.이러한 중요한 토픽을 개선하기 위해 대규모 전문가 패널을 만들 필요가 없습니다.또한 TFA/FAC/GAN을 근본적으로 개혁할 필요도 없습니다.또한 이 작업을 위해 수천 명의 편집자를 새로 고용할 필요도 없습니다.또한 전염성 토픽에 관한 방대한 수의 RfC를 작성할 필요도 없습니다.델은 이미 계획에서 상술한 바와 같이 10년 이내에 모든 중요 물품 GA를 만들 수 있는 툴을 보유하고 있습니다.게다가 Vital Direct 플랜은 PowerPoint 슬라이드만의 것이 아닙니다(사용자:TCO/Wikipedia의 중요한 기사 개선)는 Vital Direct의 철학이 현재 Wikipedia Project Vital Documents에서 구현되고 있기 때문입니다.네, 제가 실처럼 들릴지 모르지만, 저는 위키피디아의 비효율성과 갈등의 많은 부분은 우리가 큰 목표를 세우고 실제로 그것을 달성한다면 해결할 수 있다고 생각합니다. 실제 삶이나 위키피디아의 아폴로 프로그램처럼 말이죠.CactiStaccingCrane (토크) 2022년 7월 27일 11:08 (UTC) [응답]

바이탈호에서의 아폴로 임무에 대한 생각은 좋지만, 정책을 바꾸지 않는 한 충분한 인원이 있는지는 의문입니다 WP는 죽지 않을 것입니다. 하지만 유지와 인원 부족은 그것이 감소한다는 것을 의미할 것입니다.내 개인 버전 Hell은 WP로 대체되었다. 이 프로젝트에서는 FB/Meta가 WP의 AI 버전을 만들고 있다(현재 WP를 사용하여 훈련) Wakelamp d[@-@]b (토크) Wakelamp d[@-@]b (토크) 2022년 7월 27일 (UTC) 12:45 [응답]

내가 할게.어떻게 될지 지켜보자.CaptiStaccingCrane (토크) 2022년 7월 27일 13:43, UTC [응답]

삭제론자들이 이겼다는 것에는 의심의 여지가 없지만, 나는 우리가 선의의 기사(혹은 잘못된)에 대한 정책의 비용을 계산해 본 적이 없다고 생각한다.WP의 편집 시간이 100명 중 1명 미만이기 때문에 WP에 훨씬 더 가치 있는 편집 시간을 가진 WP 편집 시간(WPED?)을 사용하면 비용이 들 수 있고 WP를 이해하는 데 수년이 걸릴 수 있다.비용은

• 기사 작성자 시간(기사 편집 + 향후 편집 손실 예상)
• NPP
• AfD
• 가이드라인 논의의 몫
• 숙련된 에디터 소모(향후 편집 손실 예상)
• 기사 삭제에 따른 평판 리스크 예상(미국 상원의원 후보)
• 불만을 품은 기사 작성자에 의한 평판 리스크
• 향후 10년간 유지 보수 비용 절감
• LESS 향후 10년간에 걸쳐 예상되는 기사 읽기
• 존재하지 않는 Wakelamp d[@-@]b(대화) 기사의 평판 저하

위키피디아의 평판에 대해 말하는 것은 유권자들이 후보가 "당선 가능"인지에 대해 말하는 것처럼 느껴집니다.다른 사람이 무엇을 원하는지 아는 척하기보다는 개인적으로 무엇을 원하는지, 개인적으로 무엇을 원하는지 이야기하는 것이 좋습니다.만약 누군가가 "나는 개인적으로 발리우드 스탭을 삭제하는 것이 위키피디아를 덜 유용하게 만든다고 생각한다, 특히 인도에서 영어를 읽는 수백만 명의 사람들에게,"라고 말한다면, 다른 사람들은 "나는 구글이 나에게 두 문장과 두 개의 소스를 포함하는 위키피디아 기사에 대한 링크를 제공할 때마다 개인적으로 실망한다, 왜냐하면 나는 결코 단순한 사실을 검색하지 않기 때문이다.그 배우가 어떤 영화에 나왔지?' 이런 식으로 기사를 통해 편집자들이 원하는 것이 무엇인지에 대한 기능적인 대화를 나눌 수 있습니다.사실대로 말하자면, 우리는 우리의 개인적 취향을 제시하고 그것이 전 세계에 대한 진실™인 것처럼 가장하고 있는 것 같습니다.

CaptiStaccingCrane, 다른 언어로 된 특집 콘텐츠와 GA 기사 목록을 확인해 보셨습니까?stub가 있고 다른 Wiki가 FA 또는 GA를 가지고 있다면 Wikipedia를 사용하는 것이 더 빠를 수 있습니다.견고한 기반을 도입하여 업데이트하기 위한 콘텐츠 번역 도구입니다.WhatamIdoing (토크) 18:12, 2022년 8월 1일 (UTC) [응답]

좋은 생각인 것 같아!질문을 어떻게 해야 할지 알아내기는 어렵겠지만...CactiStaccingCrane (토크) 2022년 8월 2일 (UTC) 09:51)[응답]

나는 다른 사람이 무엇을 원하는지 아는 척하지 않고 평판만을 포함하거나 완전성을 위해 평판은 아마도 한 기사에 대해 2차 또는 3차 효과일 뿐이지만 WP 전체에 걸쳐 합산될 것이다.비즈니스, 정부 및 학계에서는 비용 대비 메트릭(WP 작업 편집 시간)을 사용하여 모델을 작성하는 의사결정 방법론이 매우 표준적입니다.(피라미드를 건설할 때 이익은 없고 비용은 비싸기 때문에 무리한 쪽을 안쪽으로 향하게 한 것은 아닐까 하는 생각이 듭니다.

편집자에게 제안할 수 있는 것은

• 우리는 그들이 더 많이 필요하고, 그래서 그들에게 인센티브를 줄 수 있다.
• WP 에디터 작업의 우선순위 부여는 기사의 등급별/중요도별 우수업무 동향 및 양 통계를 이용하여 실시한다.
• 태그가 새 편집자를 장려하는지 여부를 테스트합니다.이것은 랜덤화된 시행으로 실행할 수 있습니다.이 시행에서는 10K 랜덤 스터브에서 템플릿을 삭제하고 12개월 후 해당 페이지 10K의 기타 랜덤 스터브에서 새로운 에디터의 수를 비교합니다.
• 새로운 기사를 삭제한 후의 에디터 생산성 통계(비활성화 시 이메일 조사 포함)
• 배니티 기사의 새로운 편집자를 다른 곳(Nonnotable-pedia:-)으로 심리스하게 전환하고, NPP 체크(평판 등)를 새로운 기사 프로세스의 일부로 이동시킴으로써 원천적으로 품질을 창출할 필요가 있습니다.2:15, 2022년 8월 2일 (UTC) 웨이크 램프 d[@-@]b (통화) 2:15, 2022년 8월 2일 (UTC) [응답]

나는 세 번째 아이디어가 성공할 가능성이 가장 높다고 생각한다.두 번째 아이디어는 Top/High Importance 기사 및 Stub/Start-Class 기사를 편집함으로써 조잡하게 처리될 수 있으며, 네 번째 아이디어는 다소 거슬릴 수 있습니다.CactiStaccingCrane (토크) 2022년 8월 2일 (UTC) 09:57 [응답]

당신은 다른 사람들이 무엇을 원하는지 안다고 주장하지 않을 수도 있지만, 일부 편집자들은 그렇게 한다.죄인들을 보호하기 위해(그리고 그들이 유일하게 말하는 것이 아닐 때 부당하게 개인을 골라내는 것을 피하기 위해), 저는 어떠한 링크도 제공하지 않을 것입니다. 하지만 저는 검색은Wikipedia's reputation NPP위키피디아에서: 이름공간은 NPP가 이런 방식으로 작동해야 한다고 주장하는 편집자들의 많은 예를 제공할 것이다. 또는 초안: 공간은 이렇게 처리되어야 한다. 그렇지 않으면 위키피디아 평판이 파괴될 것이다.WhatamIdoing (talk) 2022년 8월 2일 (UTC) 19:26 [응답]

@웨이크 램프:내가 어떻게 생각해?2011년에는 Aaron Halfaker씨(사용자:EpochFail)은 NPP 프로세스의 중요성을 확인한 연구 프로그램을 시작했다.

"새로운 페이지 순찰은 새로운 저자와 프로젝트의 질을 감시하는 데 전념하는 커뮤니티 구성원 간의 상호작용의 최전선으로 많은 위키피디아에서 필수적인 기능입니다.모든 네임스페이스에서 페이지를 순회하기 위한 다양한 상세하고 복잡한 작업이 있습니다."

패트롤러 입장에서 PageTriage(2012년부터 사용하고 있는 시스템의 소프트웨어명)의 개발에 관여하고 있어, 새로운 페이지를 리뷰하는 것은 많은 스킬과 두꺼운 피부, 그리고 정말로 가치없는 기사 작성자의 적극적인 반응을 필요로 하는 작업이라고 단언할 수 있습니다.쓰레기통에 연결되어 있다.유일한 자동화는 리뷰어가 새로운 기사로 무엇을 할지 결정했을 때 마우스 클릭을 한두 번 절약할 수 있는 스크리프입니다.그러나 할파커의 폭로에도 불구하고 대부분의 WMF는 NPPers를 삭제론자로 간주하고 있는 반면, 지역사회에서는 "질보다 기사 양이 중요하다"고 인식하고 있다.새로운 페이지의 리뷰에 대한 자세한 배경은 NPP를 읽어주세요.NPP는 새로운 사용자와 리뷰어에게 천국일 수도 있고 지옥일 수도 있습니다.Kudpyung ุกtalktalktalk （ talk ）16:10, 2022년 8월 2일 (UTC)[응답]

ANI/AN 사용자 자동 알림, AE/ARBCOM 케이스 템플릿 작성

현 단계에서는 토론에 관여하는 모든 사용자에게 수동으로 통지해야 합니다.이것은 자동화되어야 한다고 생각합니다(빨간색 상자에 강조 표시될 정도로 중요한 경우라도 간과되지 않도록 적어도 반자동화할 수 있습니다).유감스럽게도 프로그래밍을 할 수 없기 때문에 코드로 구현하는 방법을 잘 모르겠습니다만, 대략 다음과 같습니다.

AN/ANI의 경우:

1. 사용자가 관련된 다른 사용자에 대한 스레드를 시작합니다.
2. 일부 텍스트를 씁니다.
3. "변경사항 저장"을 클릭하면 팝업 또는 다른 방법으로 사용자에게 알리라는 메시지가 나타납니다. 사용자는 올바른 사용자 이름을 선택하거나(더 많은 옵션을 선택할 수 있음), "아무에게도 알리지 않습니다"를 클릭해야 합니다.
4. 토론에 대해 통지된 사용자 또는 통지되지 않은 사용자에 대한 작은 글꼴의 자동 주석이 추가됩니다.
5. 봇은 지정된 사용자에게 통지합니다(있는 경우).
6. 드라마가 시작되다.

이 경우 유일한 문제는 OP에만 해당되고 스레드에 코멘트가 있는 다른 사용자에게는 해당되지 않도록 강제하는 것입니다(== [Some title] == 패턴이 입력되거나 사용자가 "New section" 버튼을 클릭할 때 프롬프트가 트리거됨).

AE의 경우:

1. 사용자가 지시에 따라 링크를 클릭합니다.
2. DYK-helper와 유사한 팝업이 나타납니다. 다른 형식일 수도 있습니다.보고된 사용자 상태가 자동 확인되어야 하므로 프로그램은 사용자 권한을 확인합니다.다음 필드가 생성됩니다.사건에 대해 고발된 것으로 통지된 사용자, 구제(드롭다운리스트), 구제(ID별 또는 링크별), 최대 20개, 이전 제재의 차이(있는 경우), 각 사용자에 대해 충족된 인식 기준(체크박스를 클릭하면 다른 ID 또는 날짜를 입력하라는 프롬프트 표시), 단어 카운터를 포함한 추가 코멘트, Wiki Synta 쓰기x(경고 표시는 500단어, 하드 제한은 550단어).그런 다음 보고서는 자체 또는 템플릿으로 자동으로 생성됩니다.텍스트와는 별도로 "Statement of [accused party]" 섹션과 admin 섹션이 생성됩니다.
   1. 항소할 경우 사용자는 관련 상자에 체크 표시를 하면 다음과 같은 변경이 발생합니다.「users notify as peased」는 「admin forguiting bejacked」가 됩니다.인식 기준은 메뉴에서 삭제됩니다.
3. 봇은 관련 당사자/관리자의 토크 페이지에 알림을 자동으로 삽입합니다.
4. 심의가 시작됩니다.

ARBCOM의 경우: 워드 한계가 적절히 조정되며, 이전 분쟁 해결 상자가 추가됩니다.그 외에는 AE와 유사합니다.

당신의 생각을 보고 싶습니다.Szmenderowiecki (대화) 2022년 7월 16일 13:44 (UTC) [응답]

ANI나 AE 케이스를 쉽게 열 필요는 없다고 생각합니다.다만, 옵션의 헬퍼 스크립트를 작성하는 경우는, 자유롭게 작성할 수 있습니다.: Kusma (토크) 2022년 7월 16일 (UTC) [응답]

이 아이디어는 더 많은 드라마를 가능하게 하기보다는 알림 규칙(및 단어 제한)을 쉽게 준수하도록 하는 것입니다. 이러한 기술 규정을 준수하지 않으면 작업 시간이 낭비됩니다.Szmenderowiecki (토크) 2022년 7월 16일 (UTC) [응답]

케이스를 오픈하는 것이 정말로 쉬워지고 있습니까?아니면 케이스를 올바르게 오픈하는 것이 쉬워지고 있습니까?하지만 사실 큰 문제는 아니라고 생각합니다.신문의 편집자가 ANI에서 통지 없이 케이스를 오픈하는 것에 대한 가장 일반적인 반응은 "알려주셔야 합니다. 제가 대신 해드렸습니다."입니다.때때로 큰 빨간 경고를 지적하는 사람도 있지만, 솔직히 ANI의 대부분의 편집자는 편집 알림에 난잡함이 많다는 것을 이해하고 있으며, 화가 난 상태에서 처음 프로세스를 탐색하는 사람이 지침을 완전히 읽지 않을 수 있다는 것을 알고 있습니다.valee (talk) 2022년 7월 16일 (UTC)[ reply ]

이제 ping이 잘 구현되고 널리 알려져 있기 때문에 ping이 이러한 스레드에 대한 알림으로 충분하다는 것에 대한 합의를 재검토해야 할 시점인 것 같습니다.비록 누군가가 스레드에서 ping을 받더라도 그들은 여전히 매우 투박하고 수동적이며 "구식"의 방법으로 알림을 받아야 한다는 것은 거의 중복된 노력으로 보인다.MediaWiki 팀은 타당한 이유로 사용자 ping을 구현하지 않았습니까?왜 6년 전에 비해 조금 더 믿음을 가지고 이 메커니즘에 기대지 않는 거죠?Elizium23 (대화)20:17, 2022년 7월 21일 (UTC)[응답]

토크 페이지 단축 및 유용성 향상

그것들은 길고 나는 대충 훑어본다. 그래서 여기 몇 가지 아이디어가 있다.

• 템플리트의 압축된 보기를 표시하는 모든 편집자.(템플릿 이름과 파라미터만 있을 수 있습니다.설명이 아닌 템플릿 이름만 표시합니다.숙련된 편집자는 규칙이 무엇인지 알고 있습니다.
• 아카이브된 토픽을 페이지에 다른 색으로 표시할 수 있습니다.
• 감시 목록을 트리거하지 않고 대량 업데이트를 쉽게 수행할 수 있습니다.워치리스트 프리퍼런스(admin 사용자 제외)를 변경하여 사소한 편집 내용을 yes로 무시하고 필요에 따라 되돌리도록 사용자에게 메시지를 발송합니다.
• 감시하고 있는 에디터의 수를 투과적으로 파악하고 있는 사용자에게 안티밴달림 이외의 다른 에디터를 감시하고 있음을 경고합니다.심지어 인기 있는 기사에서도 80%는 답장을 받지 못한다.예를 들어 옛날 영화가 훨씬 더 나은 것을 보면:Top Gun/Archive 1 - Wikipedia.반달리즘이 증가할 것이라는 주장이지만, 위키피아의 한 종파에서 시도해 보는 것은 어떨까?
• Talk 투과성에 대한 워치리스트.감시자 수에는 영구 및 비만료만 포함됩니까?
• 사용자 토크의 워치리스트 상세 - 왜 편집자는 자신의 페이지를 보고 있는 사람을 볼 수 없는가?
• 토크 페이지를 표시하도록 지시합니다.뭔가 이상한 게 보이거나 논란이 되는 게 아니라면요전자 메일 시스템이 열린 메시지를 표시하는 방식과 유사한 너네브르를 탭에 표시하도록 합니다.
• 아카이브(archive)가 실제로 도움이 될까요?이 페이지의 대부분은 위의 이유로 저속 인터넷 접속은 과거의 것입니다.

"토크 페이지가 너무 커지면 토크 페이지에 오래된 토론을 정기적으로 보관하는 것이 관례입니다.부피가 큰 토크 페이지는 탐색하기 어렵고, 쓸모없는 토론이 포함되거나, 느린 인터넷 연결이나 컴퓨터를 사용하는 사용자에게 부담이 될 수 있습니다.모든 편집자에게 아카이브를 통지하기 위한 통지가 토크 페이지의 선두에 배치됩니다.웨이크 램프 d[@-@]b (통화) 2022년 7월 16일 (UTC)[응답]

'압축'이란 말은 쓰러진 걸 말하는 건가?다른 색상으로 보관된 토픽이 얼마나 도움이 되는지 잘 모르십니까?대부분의 다른 아이디어는 보다 일반적으로 워치리스트에 관한 것 같습니다.느린 인터넷 접속이 모두에게 과거의 일이었으면 좋겠다!-Kj cheetham (대화) 2022년 7월 16일 (UTC)[응답]

Talk 페이지에 템플릿배너가 너무 많다는 문제는 이전에도 제기되어 왔습니다.아카이브에서 누군가가 그것들을 모두 정보상자로 통합하는 아이디어를 제기하는 것을 보았습니다.아직 실제로 시도해 본 사람이 있는지는 잘 모르겠습니다.

대량 업데이트는 일반적으로 사용자가 Talk 네임스페이스만 포함하여 워치목록에서 필터링할 수 있는 봇에 의해 수행됩니다.일부 봇 동작은 단순히 워치리스트(아카이브, 평가, 카테고리 수정)에 잡음이 발생하지만, 많은 사용자는 여전히 봇 편집에 오류가 있는지 확인하고 싶어합니다. 왜냐하면 이러한 오류는 발생하며 상당한 논란이 될 수 있기 때문입니다.또한 봇에는 상당히 알기 쉬운 편집 요약이 포함되어 있어 무시하기 쉽습니다.

Talk 페이지 탭 프롬프트는 이상합니다.Talk 페이지를 이전에 방문한 편집자에게만 해당되므로 워치리스트에 이미 표시되어 있을 가능성이 있습니다.따라서 (필요한 경우) 프롬프트를 표시하는 논리적인 장소는 워치리스트에 있습니다.

페이지 사이즈에 대해서는 다이얼 업은 거의 없어졌을지도 모릅니다(인터넷 인프라스트럭처가 없는 장소도 전화 인프라스트럭처가 없는 경향이 있습니다).그러나 데이터 레이트와 메모리 사용량은 여전히 중요합니다.

Talk 페이지에 투고하고 싶은 유저수가 많은 것은, 흥미로운 아이디어입니다.이미 조사된 적이 있는지는 모르겠습니다.현재 어떤 편집자가 '만료'되어 있는지 보여주는 좋은 지표를 얻을 수 있을 것이라고 확신합니다만, 여기 있는 대부분의 사람들은 오랜 기간 동안 활동을 하지 않았음을 합리적으로 확신합니다.그래도 유용할 수 있어.SamuelRiv (대화) 2022년 7월 16일 (UTC) 23:41, 응답

내 경험상 마이너로 표시된 너무 많은 편집은 모두 메이저입니다.디폴트 상태가 되어서는 안 돼요.Doug Wellertalk 2022년 7월 26일 15:34 (UTC) [응답]

디폴트로는 "default"를 사용할 수 없습니다.이 설정이 되어 있는 인터페이스의 어느 부분을 가리킬 수 있습니까?- xaosflux^Talk 15:51, 2022년 7월 29일 (UTC) [응답]

반달리즘을 되돌리는 봇은 편집 내용을 경미한 것으로 표시합니다.변경해야 하는 기본값은 Special의 기본값일 수 있습니다.Preferences #mw-prefsection-rc-changesrc 워치리스트에서 마이너 편집을 숨깁니다.WhatamIdoing (talk) 2022년 8월 1일 (UTC) 18:20 [응답]

메인 페이지의 링크되지 않은 BLP 위반

최근 WP에서 논의가 있었다.BLP 위반이 발생한 DYK 엔트리에 관한 에러입니다.굵은 글씨가 아니라 방금 적용된 보충 링크 중 하나입니다.BLP는 매우 중요한 정책입니다.메인 페이지에 위반을 공개하지 않는 것은 어떻게 접근해야 합니까?BLP 문제가 해결되지 않으면 링크 해제를 허용할 수 있습니다.thekycauldron (대화 • 기여)(그/그들) 03:46, 2022년 7월 17일 (UTC)[응답]

(참고로 문제의 논의는 여기 Caeciliusinhorto-public (대화) 15:54, 2022년 7월 22일 (UTC)[응답]

BLP 위반은 기본 페이지에서 링크하지 마십시오.vio를 고정할 수 없고 링크가 훅에 매우 중요한 경우 훅을 당겨야 합니다.: Kusma (토크) 13:53, 2022년 7월 17일 (UTC) [응답]

대상 문서에서 BLP 위반을 삭제하는 대신 후크를 당기는 이유는 무엇입니까?Anomie⚔ 2022년 7월 17일 (UTC) 15:08 [응답]

우리는 그 문제를 해결하기 위한 일의 순서에 동의하는 것 같다.: Kusma (토크) 15:31, 2022년 7월 17일 (UTC) [응답]

샬롯 폰 말스도르프가 죽은 지 20년이 되었기 때문에 이 논의와 관련된 BLP 문제는 전혀 없었다.일부 편집자가 BLP 문제로 그녀의 글에 태그를 잘못 달아 문제가 해결되었습니다.Elizium 23 (대화) 2022년 7월 21일 (UTC) 04:29 [응답]

섹션의 수신 링크에 대한 보이지 않는 주석

특정 섹션을 가리키는 착신 링크에 대해 편집자에게 통지하는 것은 매우 중요하기 때문에 MOS:COMMENT 및 WP:HIDDEN은 이를 보이지 않는 코멘트의 첫 번째 사용 사례로 언급하고 있습니다.

<!--이 섹션의 제목을 변경하는 경우는, 페이지의 링크도 변경해 주세요.-- >

예를 들어 Visual Editor(VE)에서도 이해할 수 있는 템플릿과 같은 표준화된 마크업을 보고 싶습니다.예를 들어, 기사에서 쓸 수 있는 함수의 한계

===무한으로 변경 === {{이 섹션 제목 변경 시 페이지 링크 변경 at 무한으로 제한}}

편집자(특히 Wikipedia 토크에서 언급한 바와 같이 VE 사용자)에게 알립니다.스타일/숨김 텍스트/아카이브 1#지금은 사용되지 않습니다.)의 설명서에서 Limit at infinity는 이 섹션으로 리디렉션됩니다.템플릿을 변환해도 보이지 않는 코멘트와 마찬가지로 아무것도 출력되지 않습니다.관련 설명:위키백과:빌리지 펌프(제안서)/아카이브(Archive) 8#기사의 섹션으로 리다이렉트.페트르 마타스 2022년 7월 18일 11:39 (UTC) [응답]

가장 이상적인 해결책은 [Special](특수)를 선택하여 편집자에게 자동으로 경고하는 것입니다.What Links(링크)편집자가 섹션 제목을 변경하거나 삭제하려고 할 때마다 섹션 링크를 보려면 여기를 클릭하십시오.템플릿이 없는 섹션 리다이렉트 수가 276,000 {{R to section}}에 달하고 있기 때문에 모든 수신처에 코멘트를 붙이면 큰 유지보수 작업이 될 수 있습니다.증명서 (대화) 2022년 7월 18일 (UTC) 11:56 [응답]

숨겨진 코멘트가 VE에 표시되게 되었습니다(오래되지 않은 것은 오래 전에 수정한 버그입니다).그러나 표준화된 템플릿을 사용하면 다른 이점이 있을 수 있으므로 제안서는 좋은 생각인 것 같습니다.– Uanfala (대화) 2022년 7월 18일 11:58 (UTC)[응답]

이는 2014년에 phab의 일부로 수정되었습니다.T51603.

나는 왜 이것이 표준화 되어야 하는지 잘 모르겠다.단점은 다음과 같습니다.

• 그것은 더 복잡한 것입니다.
• '잘못'해야 할 것들이 더 많아.
• 안절부절못하며 배워야 할 작은 것이 하나 더 있다.
• 한 번만 더 쉬볼레스를 하면 일을 제대로 할 줄 아는 외부인과 우리 사이를 분리할 수 있다.
• 다른 Wiki를 복사하면 작동하지 않습니다.
• 템플릿 이름에 오타가 있으면, 기사에 눈에 띄게 혼란이 생깁니다.

장점은 다음과 같습니다.

• 우리 중 몇몇은 모든 것이 일치하기를 좋아한다.

만약 우리가 실제 문제를 해결하고자 한다면, 나는 그렇게 생각할 것이다.{{anchor Limits at infinity}}좀 더 포인트 있는 것 같아요.그런 다음 섹션 제목을 변경하고 착신 링크를 계속 작동할 수 있습니다.Template와 같은 이름으로 해당 템플릿의 리다이렉트를 설정할 수도 있습니다.수신 링크의 앵커(템플릿을 사람들이 이해하지 못할까 봐 걱정되는 경우):앵커는 용이다.WhatamIdoing (대화) 22:37, 2022년 7월 18일 (UTC)[응답]

나는 동의해야 한다.이 문제에는 다른 접근법이 필요할 수 있습니다.봇은 섹션으로의 모든 방향 수정(R 템플릿과는 별개로)을 추적하여 자동으로 업데이트할 수 있습니다.특정 사건을 해결할 수 없는 경우(예를 들어 섹션이 모두 삭제됨), 범인의 토크 페이지에 메시지를 남깁니다.페트르 마타스 2022년 7월 19일 (UTC) 08:04 [응답]

우리는 이미 그런 봇을 가지고 있기 때문에 문제는 해결되었다.증명서 (토크) 2022년 7월 19일 (UTC) 11:20 [응답]

콘텐츠 자원 봉사 요청을 위한 다른 포럼

분쟁해결공고판에 접수된 일부 소송요구는 실제로 중재된 분쟁해결요구가 아니기 때문에 종결된다.DRN은 콘텐츠 알림판 중 하나이며 WP보다 "잘못된" 요청이 적기 때문에 DRN에는 다양한 유형의 요청이 있습니다.ANI(다른 사용자가 편집 내용을 확인하거나 주석을 달거나 다른 편집자가 기사 토크 페이지에서 토론에 참여하는 경우 등)분쟁 해결 메커니즘의 일부로 간주되지 않고 Volunte Requests 또는 Content Advisory와 같은 이름을 가진 다른 게시판이 있어야 한다는 제안이 제기되었습니다.또, 예를 들면, 어느 토픽에 대해서 중립적인 어구의 RFC를 기술하기 위한 서포트를 요구할 수도 있습니다.

도움이 될 만한 어떤 형태에 대해 아는 사람 있나요?Robert McClenon (대화) 00:27, 2022년 7월 27일 (UTC)[응답]

DRN이나 ANI로 폭발하기 전에 상황을 확산시키기에 좋은 장소라고 생각합니다.중립적인 중재자를 끌어들여 자본 P에 문제가 생기기 전에 냉정하게 대처한다.그러나 일부 편집자들이 DRN에 가는 것이 기록에 대한 "징벌" 또는 "부정적 표시"라고 생각하는 것도 제거하세요.Nightenbelle (대화) 2022년 7월 27일 (UTC) 19:09 [응답]

삭제된 페이지 보기 및 삭제 유형 구분

Wikipedia에서:Village pump(제안서)/영구적인 제안서/뷰 삭제에 대한 Straw 여론조사는 OTRS(현재의 VRT) 법적 큐와 WMF에서 삭제된 페이지를 더 많은 사용자가 볼 수 있도록 허용한다는 법적 우려에 대한 진술로 토론이 종료되었습니다.관리자만 볼 수 있는 페이지나 리비전을 분리하기 위한 리비전을 삭제할 때 새 체크박스를 추가할 수 있습니다.이를 관리하기 위한 가장 쉬운 방법은 현재 삭제된 모든 수정사항과 페이지를 기본적으로 관리자에게만 표시하는 것이며, 그러면 "신뢰할 수 있는" 그룹이 새로운 삭제를 사용할 수 있게 됩니다.0xDeadbeef 2022년 7월 27일 06:19 (UTC) [응답]

이건 뭐에 쓰는 거야?"deleted"는 "deleted"를 의미해야 한다고 생각했습니다.즉, 관리자 이외에는 누구에게도 액세스 할 수 없습니다.만약 누군가가 그들을 볼 수 있다면, 어떻게 실용적인 의미에서 그들을 "삭제"라고 부를 수 있을까요?Ruslik_Zero 2022년 7월 28일 (UTC) 20:06 [응답]

Wikipedia도 참조해 주세요.중재위원회/2008년 6월 발표/삭제 페이지 활성화.이는 삭제된 페이지에 누구라도 접근할 수 있어야 한다는 것이 아니라 커뮤니티에 의해 결정된 반달리즘/소크 인형극 및 기타 사용 증거를 얻기 위해 부여된 추가 사용자 그룹에 대해서만 접근해야 한다는 것을 제안하는 것입니다.0xDeadbeef 2022년 7월 29일 09:24 (UTC) [응답]

이것은 여러 가지 이유로 시작은 할 수 없지만, 삭제된 기사의 경우 Wayback Machine에 상당히 최근 사본이 저장될 것입니다. Wikipedia에 저장될 수 있을 만큼 오래 존재한다면 말이죠.자동 아카이브는 사용자 및 드래프트 공간(기본 검색 엔진 인덱싱 규칙 때문에 AFAIK)에 대해 실제로 수행되지는 않지만, 일반적으로 삭제된 내용을 확인할 이유는 거의 없습니다.Duh 박사 🩺 (대화) 2022년 7월 28일 (UTC)[응답]

청소용 기사

삭제 토론에서의 행위에 대한 현재의 ArbCom 사례와 최근에 참여한 다양한 토론에서 영감을 얻어 정리 프로세스를 위한 기사 아이디어를 작업하기 시작했습니다.이 링크는 내 사용자 공간의 첫 번째 대략적인 윤곽으로 연결되며, 아이디어에 대한 피드백을 받고 싶습니다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 2022년 7월 27일 18:32 (UTC)[응답]

@ONUnicorn:Wikipedia에 대해 알고 계십니까?물품구조대? --Redrose64 🌹 (대화) 2022년 7월 27일 (UTC)[응답]

@Redrose64:네, 하지만 조금 다른 걸 상상하고 있어요.그건 멤버들이 이 아이디어에 관심을 가질만한 프로젝트입니다.그러나 이 아이디어는 AFD를 보완하는 프로세스를 위한 것입니다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 2022년 7월 27일 22:25 (UTC) [응답]

ONUnicorn, 그 과정을 데모해서 기사 몇 개에 써보시는 게 좋을 것 같아요.효과가 없었던 것들을 수정해봐할 수 있는 건 가지세요.헹구고 반복하세요 – 모든 것을 미리 만들어 두는 것보다 훨씬 더 나은 공정을 얻을 수 있습니다.CactiStaccingCrane (토크) 2022년 7월 30일 13:23 (UTC) [응답]

전체적인 견해:그런 식으로는 안 될 거예요.삭제 위협은 노력을 장려합니다.아무것도 아닌 위협은 아무 것도 하지 않는다.

상세:

• "소싱용 기사"라는 이름을 사용하는 것이 좋을 것 같습니다. 그렇지 않으면 알림이나 삭제와 관련된 불만이 많이 제기될 수 있기 때문입니다.(Wikitext 오류가 있는 기사는 여기서 폐기할 수 있습니다.
• 또한 WP가 필요할 것 같습니다.QPQ 프로세스다른 사람의 기사 수정을 돕지 않으면 여기에 기사를 버릴 수 없습니다.(https://bambots.brucemyers.com/cwb/bycat/Medicine.html에 게재되어 있는 약 21,000개의 기사를 새로운 것에 카피하면 되는 거죠?
• 이것은, AFD 의 결과 또는 AFD 프로세스를 일시 정지하는 방법이라고 생각할 수 있습니다.

좀 더 넓게는 기사 작성과 소싱을 주요 활동으로 권장할 필요가 있는지 궁금합니다.태그 부착, "처리" 및 오타를 수정하기 위해 AWB를 장시간 실행해도 백과사전이 구축되지 않습니다.예를 들면, 약 14년 전에, 저는 안구 치질 이형성증에 대해 썼습니다.편집자 38명(저 포함)이 63번 편집했습니다.그러나 전체 기사에서 다른 사람이 쓴 단어는 12개뿐입니다(연속해서 4개를 넘지 않습니다).다른 37명의 편집자들은 무엇을 하고 있었나요?WhatamIdoing (토크) 18:42, 2022년 8월 1일 (UTC)[응답]

@WhatamIdoing 유용한 제안 감사합니다.주요 아이디어는 실제로 AFD의 결과 또는 AFD 전 단계로, 실제로 AFD에서 살아남기 위해 다른 덜 적대적인 과정을 거치는 기사를 만드는 것이었습니다.'소싱 및 개선을 위한 기사'가 정리용 기사보다 더 낫거나 '통지성 검토용 기사'가 더 명확할 수 있습니다.

QPQ에 대한 아이디어는 좋기도 하고 나쁘기도 합니다.AFD에 많은 기사를 추천하는 일부 사람들은 WP를 하기 위한 요건을 좋아하지 않는다고 생각한다.BEFORE(바쁘다-어디선가 밀린 일을 빨리 해치우려고 한다-기사 작성자가 이 일을 했어야 한다고 생각한다 등), 그리고 그들 중 일부는 그다지 잘하지 못한다.또한 WP를 사용하는 경우:DYK는 QPQ가 위키피디아에서 어떻게 기능하고 기능하지 않는지를 보여주는 예로서 - 음, 그것은 noms를 밀어내는 데 효과가 있지만, 단지 자신의 noms를 리뷰하기 위해 체크박스를 켜려고 하는 사람들에 의해 수행되는 무능한 리뷰에 대한 지속적인 문제가 있다.소스 검색에 능숙하지 않거나 소스 검색에 너무 바쁘거나 소스를 검색하는 것이 다른 사람의 일이라고 생각되면 QPQ가 있으면 프로세스를 사용하지 않거나 QPQ로 수행하는 모든 작업에 대해 조잡한 작업을 수행합니다.

AFD 프로세스에서 일시정지 버튼이 된다는 당신의 생각이 마음에 듭니다-아마도 AFD의 중간에서 누군가가 소스를 찾아 AFCU, AFSI, AFNR 또는 최종적으로 불리는 어떤 것으로 보내질 것을 제안하고, 거기서 30일 동안 일하고, 그 후에 수정된 기사를 평가합니다.

저는 삭제 위협을 그 일부로 남기려고 노력합니다. 7일간의 AFD보다 덜 긴급한 위협입니다. 사람들은 내내 "삭제"를 외칩니다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 2022년 8월 1일(UTC) 19:43, [응답]

"Ticles for Notability Review"는 오래된 위키피디아처럼 들린다.알림/알림판, 닫았습니다.폐점 이유를 요약해서 말씀드리지는 않겠습니다만, 일상 업무와 그에 대한 논의를 검토해 보시기 바랍니다.WhatamIdoing (talk) 2022년 8월 2일 (UTC) 19:31 [응답]

다른 Idea Lab 프로세스 시험

경험이 풍부한 편집자가 제안하고 있지만, 아이디어는 성공 가능성이 낮은 것 같습니다.그 이유는 프로세스 때문일 수도 있습니다.특히 문제를 완전히 이해하기 전에 해결책으로 넘어가기 때문에 다음과 같은 순서로 문제 해결 프로세스를 사용하여 몇 가지 중소 규모의 문제를 시험해 보는 것이 좋습니다.

• 문제를 정의합니다.
• 대체 솔루션 생성,
• 대안 평가 및 선택
• 웨이크 램프 d[@-@]b (talk) 07:17, 2022년 7월 29일 (UTC)[응답] 구현 및 후속 조치

웨이크 램프, 완전 동감이야다음 항목도 참조하십시오.반복적 및 증분적 개발.우린 이게 필요해우리는 너무 관료적이고 비WP적이기 때문에 오랫동안 침체되어 왔다.IARY, 그리고 변하지 않는 것을 사랑하라.CactiStaccingCrane (토크) 2022년 7월 30일 13:19 (UTC) [응답]

편집자들은 이 단계를 분리하는 데 익숙하지 않은 것 같습니다.델은 제안 솔루션을 신속하게 도입하고, 그 솔루션이 효과가 없다고 해도 제안 솔루션을 고집하는 경향이 있습니다.예를 들어 2009년에 {{unref}개의 기사에 스팸을 발송하기로 한 결정을 생각해 보십시오.그것은 편집자들이 기사에 출처를 추가하는 결과를 가져올 것이다.하지만 아무도 그게 먹혔는지 확인해 본 적이 없어요.WhatamIdoing (talk) 2022년 8월 1일 (UTC) 18:45 [응답]

네, 저는 이 위키피디아를 테스트에 사용하는 것이 좋지 않은 생각이라는 것에 동의합니다.그래서 테스트 위키피디아는 그런 목적으로 존재합니다.메인 네임스페이스와 관련이 없거나 A/B 테스트가 필요하지 않은 아이디어에 대해서는 여기서 임시 위키피디아 네임스페이스 페이지에서 수행할 수 있습니다.CaptiStaccingCrane (토크) 10:02, 2022년 8월 2일 (UTC) [응답]

영어 위키피디아 분할