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

위키프로젝트 평가 척도

나는 위키프로젝트 평가 척도에서 "중요성"의 이름을 "우선순위"로 바꿀 것을 제안한다."중요성"은 약간 주관적이고, 내 생각에 "우선순위"는 백과사전 안에서 더 정확하다.일부 프로젝트는 이미 그렇게 했다.생각?감사합니다, –Juliancolton 03:37, 2009년 6월 1일 (UTC)[응답]

'중요함'이 가장 좋은 단어는 아니지만, '우선순위'로 바꾸는 것에도 문제가 있다고 생각한다.기사는 우선순위가 높은...무엇에 대한 높은 우선순위...?FA 자격을 얻기 위해?좋아, 그럼 일단 FA 지위가 되면 그때는 더 이상 높은 우선순위가 아니니까, 지금 어떤 "우선순위"라고 이름 붙이는 거야?중요성은 내가 동의하는 끔찍한 이름이지만, 이것은 윈스턴 처칠을 패러프레이징하는 것이 "다른 가능한 이름들을 제외하고, 임무는 현존하는 최악의 이름이다"라고 유용하게 쓰일 수 있는 경우일 것이다.카멜빈키 (대화) 08:13, 2009년 6월 1일 (UTC)[응답]

이를 위해서는 약 7,500개 범주의 이름을 바꾸고, 들어오는 모든 링크를 업데이트해야 한다.나는 평가 카테고리에 대한 통일된 스키마를 보고 싶기는 하지만, 이 정도의 변화는 실행 가능하지 않다.평가 체계는 독자를 대상으로 하는 것이 아니라, 용어들이 얼마나 의미론적으로 수정되었는지는 특별히 중요하지 않다. 다만 내부적으로 일관성이 있고 프로젝트의 나머지 부분에 유용할 뿐이다.나는 차라리 소수의 "우선순위" 척도가 "중요도"로 표준화되는 것을 보고 싶다. 내가 그것이 더 의미론적으로 옳다고 생각하기 때문이 아니라, 순전히 그것이 더 일관적이기 때문이다.해피멜론 09:04, 2009년 6월 1일 (UTC)[응답]

생각하면 할수록 줄리안콜튼의 제안에 동의한다."중요성"은 주제가 반드시 사실일 필요는 없는 더 큰 기사를 보증한다는 것을 암시할 수 있다.예를 들어, 과학적인 개념은 상당히 쉽게 설명될 수 있고 너무 명백해서(한 번 누군가가 그것을 생각해 냈을 때!) 거의 설명이 필요하지 않을 수도 있다.그러나 널리 사용되고 연결되어 있다면, 그것의 기사는 좋은 상태로 유지될 필요가 있다.

"중요도"를 "우선순위"로 변경해야 수천 개의 레코드를 업데이트해야 한다면, 그것이 봇의 목적이다.나는 봇 작가들의 시간에 더 높은 우선순위의 요구가 있을 수 있다는 것을 인정한다. 제안된 변경은 유용하지만 긴급하지는 않다.--필차 (토크) 09:38, 2009년 6월 1일 (UTC)[응답]

필차는 당신의 눈에서 단순히 의미론 이상의 변화를 원하고, "우선순위"가 현재 "중요성"이 의미하는 것과 다른 것을 의미하기를 원한다는 것을 내가 정확히 이해했는가?그것은 단지 "봇을 위한 것" 이상의 것을 가져다 준다.현재 중요도가 높지만 "우선순위"로서 중요하지 않은 것이 있다면, 우리는 당신이 암시하는 것보다 더 많은 변화를 겪고 있는 것이다.당신의 과학적 개념의 예를 이용하려면, 몇몇 다른 과학 기반의 위키백과 주제에서 기사 X가 중간중간 중요하다고 말하지만, 당신의 "우선순위" 구조 하에서는 그것이 "그것들이 널리 사용되고 연결되어 있어야 하기 때문에, 그것의 기사들은 좋은 상태를 유지해야 하기 때문에 그것은 높은 우선순위가 되어야 한다.주제 전체의 전체 범위/가장 중요한 사실을 알기 위해 독자들/편집자가 어떤 기사가 "알고" 가장 중요한지 알 수 있게 해준다는 점에서 중요성은 매우 "중요하다"고 생각한다.위키피디아 주체는 스스로 자신의 페이지에 관심을 필요로 하는 기사(다수가 하는 일)를 리스트로 작성하고, 할 일을 나열하고, 체크해야 할 기사를 우선순위로 정할 수 있으며, 체계적인 크로스 위키피디아 형식 없이 나름대로 할 수 있다.나는 해피멜론의 의견에 동의한다. 이 문제에 대한 특출한 사람들(즉, 우선순위로 바뀐 위키백과 제목)은 그 반대로 바뀌지 말고 다수결로 바뀌어야 한다.카멜빈키 (대화) 11:44, 2009년 6월 1일 (UTC)[응답]

그 제안은 모든 시청률을 뒤집는다.우선순위는 중요성과 동등하지 않다.비너스와 화성은 중요하지만, 그들은 이미 FA이기 때문에 콘텐츠 구축에 있어 우선순위는 매우 낮지만, 반달 감시자들에게는 우선순위가 높다.서섹스 출신의 몇몇 거의 눈에 띄지 않는 법정 변호사는 중요성이 낮지만, 그의 기사를 BLP에 준거하는 것이 우선이다.내가 보는 바와 같이 문제는 주관적이기는 하지만 그 중요성은 또한 직관적이기도 하며, 적어도 그 분야에서는 그렇다.우선 순위는 그렇지 않다.NVO (대화) 2009년 6월 1일 (UTC) 12:00[응답]

깨끗한 출발을 위해 모든 중요 고지를 삭제하는 것은 어떨까?봇은 그것을 할 수 있다 :) 그러면 우리는 몇 년 동안 허용 가능한 우선순위 개념을 위조하는 것에 빠져들 수 있다.NVO (대화) 12:06, 2009년 6월 1일 (UTC)[응답]

"우선순위"를 좋아하지 않는다.일상 생활에서 흔히 사용되는 단어의 잘못된 함축: 어떤 (지정되지 않은) 행동이 시급히 기다리고 있다는 함축성; 다른 것 보다는 한 가지를 선택하는 것....윈스턴 처칠의 말에 동의하라. (그리고 "증언"도 사실 꽤 괜찮다.)PL290 (대화) 13:29, 2009년 6월 1일 (UTC)[응답]

WP에서 소개:VG, 우리는 최근에 "우선순위"에서 "중요도"로 바뀌었다.사실 그 이유를 잘 모르지만(필요한 재작성과 이동의 일부만 처리했을 뿐), 나는 '중요함'을 선호한다.우선순위는 중요도보다 주관적이지 않다. 어떤 종류의 정의된 척도가 있는 한.나는 또한 "우선순위"가 모든 기사가 어떤 종류의 엄청난 밀수에 처해 있다는 것을 암시한다는 것을 발견한다. - 그것은 내게 맞지 않는 것이다.그레그 타일러^{(t • c)} 19:10, 2009년 6월 1일 (UTC)[응답]

"우선순위"가 될 필요는 없다.난 그냥 그게 합리적인 선택이라고 생각했어.–Juliancolton 23:28, 2009년 6월 2일 (UTC)[응답]

「관용」은 등급의 취지를 정확하게 파악한다. 「이 기사는 완전한 백과사전을 갖추는 것이 중요한가, 얼마나 필요한가」.우선 순위가 사용되는 유일한 이유는 전기 기사에서 누군가를 "낮은 가치"라고 부르는 것이 오히려 불편하기 때문이다.그래서 나는 우리가 할 수 있다고 해서 그 변화를 만들고 벌레 통조림을 여는 것이 불편할 것이다.Titoxd^{(?!? - cool stuff)} 19:12, 2009년 6월 2일 (UTC)[응답]

나는 "우선순위"를 "중요성"의 동의어로 보지 않는다.사실, 나는 "우선순위"는 중요성과 평가의 함수라고 제안한다.중요도("상단"의 경우 6)에 값 1-6을 할당하고 평가의 경우 값 0-6을 할당한다(GA의 경우 6).어떤 글이라도 중요도에서 평가를 빼면, 값이 높을수록 우선순위가 높아진다.우리가 과제를 내지는 않지만, 이것은 자원을 배분하는 좋은 방법이 될 것이다.(부정적 가치는 바람직한 할당에 비해 이미 너무 많은 자원이 소모되었다는 것을 의미하지만, 우리는 사람들이 자신이 하고 싶은 일을 하기를 원하기 때문에 그것은 주요한 부정은 아니다.)--스필브릭 (대화) 13:22, 2009년 6월 3일 (UTC)[응답]

방금 문제를 지적하셨습니다.그것은 중요성의 동의어로 사용되어지고, 실제로 그것을 대체하기 위해 제안되고 있다.이미 소개된 기사를 수정하는 것은 그다지 높은 우선순위가 아니다; 질이 낮고 매우 중요한 기사들을 동등한 수준으로 끌어올리는 것이 더 높은 우선순위다.Titoxd^{(?!? - cool stuff)} 08:54, 2009년 6월 5일 (UTC)[응답]

업로드 양식에서 대부분의 GFDL 옵션을 단계적으로 폐지하자는 제안

이제 모든 위키미디어 프로젝트가 선호하는 라이센싱 플랫폼으로 Creative Commons로 마이그레이션되고 있으므로, 나는 MediaWiki talk에서 업로드 양식에서 대부분의 GFDL 옵션을 단계적으로 제외하자고 제안했다.면허증.이 제안서는 라이선스를 무효화하는 것이 아니라 단순히 업로드 양식의 드롭다운 목록에서 GFDL 라이선스의 사용을 촉진할 것인지 여부에 대한 것이라는 점에 유의하십시오.하원에 대해서도 비슷한 제안이 진행 중이다.칼다리 (대화) 2009년 6월 5일 (UTC) 15:42, 응답하라

고려할 아이디어는...(사용자 대화에서 이동:짐보 웨일즈)

안녕 짐보!또 나야.나는 위키미디어 커먼즈가 지난 3년 동안 꽤 잘 되고 있는 것 같은 올해의 컴포지션을 개최했다는 것을 알았다.나는 위키피디아가 올해의 기사 또는 이와 비슷한 것을 가질 수 있는지 생각하고 있었다.이 제안에 대한 당신의 의견은 무엇인가?로스 로즈 (T C) 15:45, 2009년 5월 26일 (UTC)[응답]

• 반대한다. 우리가 필요로 하는 마지막 것은 헛간에서 부활한 또 다른 상호 백슬래핑 축제다.이전에 거부된 이달의 조항 제안서를 참조하십시오.– 무지개빛 16:10, 2009년 5월 26일 (UTC)[응답]
• 지원 - 차라리 헛간 스타들의 상호 백슬래핑 축제를 즐긴다--짐보 웨일즈 (토크) 16:16, 2009년 5월 26일 (UTC)[응답]

  모든 사람들이 헛간이 얼마나 중요한지 이해하는 한(어느 쪽이 중요한지), 물론, 무엇이 해로운가?매우 다른 주제에 대한 기사를 비교하는 것은 다소 어렵기 때문에, 나는 다른 등급의 기사에 대해 별도의 콘테스트를 제안하고 싶다.티타늄 vs 쉐필드 vs 위글스 (나는 실제 기사를 보지 않고 피사체를 바탕으로 골랐다))올해의 전체 기사를 선정하기 위한 최종 라운드는 해치지 않겠지만, 남은 대회보다 훨씬 덜 심각하게 받아들여야 한다. --Tango (토크) 16:28, 2009년 5월 26일 (UTC)[응답]

  FA나 기사 작문 등을 고려할 때 대부분 대량 수상 경연대회는 그 질을 떨어뜨리는 경향이 높고, 전 과정에 지장을 주는 경우가 많다.우리의 가장 존경받는 콘텐츠 작가들은 이 악명 높은 시상식 센터를 무너뜨리기 위해 쉴 새 없이 싸워야 했다. mfd 토론을 보기 위해서 말이다.거부되고 삭제된 위키백과도 있다.올해의 특집 기사.그러니까, 아주 조심해서...첫눈에 결백해 보일 수도 있지만, 그렇게 되면 큰 문제가 되고 시간과 자원의 큰 낭비가 된다.그리고 만약 이것이 지역사회에서 널리 인정받지 못할 일이라면, 이전의 경험들이 그럴 가능성이 있다는 것을 보여준다면, 나는 요점을 모르겠다.세나리움 (대화) 17:07, 2009년 5월 26일 (UTC)[응답]

  대회가 시작되기 전에 존재했던 기사의 버전이 중요한 것이라고 말함으로써 문제가 상당히 쉽게 해결될 수 있을 것이라고 생각한다(그렇다고 FlagedRevs가 도와줄 또 다른 것!). --Tango (토크) 17:30, 2009년 5월 26일 (UTC)[응답]

  기사가 FA가 되도록 요구한다면, FAX의 혼란을 최소화하기 위해 이미 대회 전에 FA가 되어야 한다.그러나 고려해야 할 버전이 고정되어 있더라도 일부 사용자는 이를 무시할 수 있다.또 다른 우려의 원천은 정치적 혹은 논란이 많은 기사들로, 만약 'AOTY'로 선정된다면 더욱 논쟁거리가 될 것이다.세나리움 (대화) 2009년 5월 26일 (UTC) 19:45 [응답]

• 좋은 생각인 것 같군. 그래도 마을 펌프에서 제안하는 게 낫지.주요토크 16:30, 2009년 5월 26일 (UTC)[응답]
• 지지하다.내 아이디어였으니까.이 짐보를 지지해줘서 고마워!로스 로즈 (T C) 16:54, 2009년 5월 26일 (UTC)[응답]

그냥 메모해두세요, 어떤 것에 대해서도 공감대를 가질 수 있는 건 여기 지원해서가 아니라는 겁니다.세나리움 (대화) 17:07, 2009년 5월 26일 (UTC)[응답]

• 헛별에서 부활한 상호 백슬래핑 축제를 지원한다.바라건대 어떤 구질구질한 가치 있는 드라마가 함께 하기를 바란다.뒹굴자.ChildofMidnight (대화) 17:11, 2009년 5월 26일 (UTC)[응답]
• 사무엘 존슨이 역사상 가장 위대한 영국인의 칭호와 함께 세기의 가장 위대한 위키피디아 페이지의 상을 받을 경우에만 지원한다.Ottava Rima (대화) 18:27, 2009년 5월 26일 (UTC)[응답하라]
• 지원 분명 좋은 생각이야.그러나 나는 이달의 기사보다는 분기별 기사-잔-마르 등등을 추천한다. 그러면 4명의 결승 진출자를 기준으로 한 올해의 기사에는 재미있는 투표가 있을 수 있을 것이다.누구나 첫 1년 동안, 심지어 나이든 사람까지, 그리고 1년 후에는 그 사이클 동안 FA를 만든 기사로 기사를 제출할 수 있다.뿌리학/평등 18:36, 2009년 5월 26일 (UTC)[응답]
• 지지 나는 차라리 "별이 빛나는 상호 백슬래핑 페스티벌"이라는 아이디어도 좋아한다. ⊕아신 조 19:40, 2009년 5월 26일 (UTC)[응답]

• 여기는 프로젝트에 대한 공감대를 모으는 자리가 아니라 사용자 토크 페이지다.이것을 제안하고 싶다면 마을 펌프를 예로 들어보자.세나리움 (대화) 2009년 5월 26일 (UTC) 19:45 [응답]

투표를 다시 시작하는 대신 이 정보를 페이지로이동해도 될까?로스 로즈 (T C) 19:46, 2009년 5월 26일 (UTC)[응답]

나는 대답하려고 했다: 아니, 그 제안은 공정하게 제시될 필요가 있다.우리는 이것을 짐보의 토크 페이지에서 그의 지지를 얻거나 못 받거나 하는 제안들을 가끔 보게 되는데, 그 다음 우리는 그것을 어떻게 적절하게 다루어야 할지, 아니면 그것 때문에 이의가 있는지(예: BLP 조사)를 들 수 있다.짐보가 편집한 이 상황에 대해서도 주의하라; '짐보는 이것을 지지한다'로 토론을 시작하는 것은 불공평하며 적절한 합의를 이끌어내지 못할 것이다.토론의 방향을 틀지 않고는 이 실마리를 옮길 수 없다. 왜냐하면 이것은 공동체의 토론을 위한 일반적인 장소가 아니라 사용자 토크 페이지이기 때문이다(좋은 일이든 나쁜 일이든 때때로 여기서 일어나기도 한다).세나륨 (대화) 2009년 5월 26일 (UTC) 20:08 [응답]

• 많은 문제들: 1) 우리는 매년 500~600명의 FA를 추가한다: 어떤 편집자들이 정보에 입각한 결정을 내리기 위해 그러한 모든 기사를 읽을 것인가?2) 가장 많은 친구를 가진 편집장이 영예를 받으면서 이것이 단순히 인기 경연대회로 되는 것을 막을 수 있는 것은 무엇인가? 3) 이런 수상심리가 어떤 목적으로 있는가?같은 노력이 기사 검토에 들어갈 수는 없을까?4) 그 5~600명 중 어느 한 글이라도 '최상'으로 볼 수 있다고 정말로 믿는 사람이 있는가?잘못된 노력.샌디조지아 (토크) 2009년 5월 26일 20:12 (UTC)[응답]

• 반대하라 이 일이 옮겨졌으니...첫째, 제안된 방식이 왜곡되어 있어 이 프로젝트를 만들기 위한 합의를 도출하는 것은 불가능하다.나는 이것을 위에서 설명하였다.내가 또한 말했듯이, 이것은 정치적이거나 논란이 많은 기사들에게 엄청난 논란과 드라마를 만들 것이다.그리고 그러한 종류의 수상 경연대회가 콘텐츠의 질과 관련 과정에 부정적인 영향을 미친다는 것은 꽤 확실하다. 그 중 하나에 대한 mfd 토론(작년부터의 'myspace' 시리즈 에피소드 중 하나)을 보라.많은 사용자들이 이것을 처리하고 마침내 그것을 이해하는데 시간이 걸렸고, 또 다른 엄청난 시간과 자원의 낭비가 필요 없었고, 드라마와 논쟁의 발생기가 필요했다.이상적인 세계에서는 흥미롭겠지만, 위키피디아가 어떻게 작동하는지 아는 것은...세나륨 (대화) 2009년 5월 26일 (UTC) 20:29 [응답]

• 강력한 반대 우리는 FAC에 대한 검토자가 충분하지 않다.우리에게 필요한 마지막 것은 무수한 문제들로 가득 찬 운동을 위해 제한된 수영장을 바꾸는 것이다.예를 들어, 누가 이것에 투표할 수 있는가?모든 위키백과 사용자 또는 FAC 검토자만?전자라면 형식적인 투표/댓글을 어떻게 하느냐면, "나는 모든 기사를 읽었고 나머지 기사들보다 X조가 머리와 어깨 위에 있다고 생각한다"는 식이다.또 다른 예로, 이 대회는 FA로 제한될 것인가 아니면 다른 기사들도 허용될 것인가, 그리고 몇 개인가?10살, 20살, 모든 FA가 1년 동안?그대로, 각각의 리뷰에서 개별적인 FAC의 품질에 대한 논쟁은 페이지와 페이지로 갈 수 있다. 그런 다음, A와 B와 C의 비교에 관한 논쟁, A와 Z, B와 C의 비교 등에 대해 상상해 보라.위키피디아는 백과사전으로, 그 지역사회에 대한 서비스는 종종 비공식적인 기사로 제공되며, 때로는 작은 주제로 여러 저자와 익명의 IP에 의해 쓰여진다.예: 대명사, 상대성 절, 중력, 상대성 이론, 식초, 와인, 캐버넷 소비뇽, 위스키, 유전학 소개, DNA 복제, 엘름, 쿠민, 마라톤, 롱 점프 등이 있다.아무도 FA가 아니며, 많은 B급 기사들만 있다.이와는 대조적으로, 많은 FA들은 아무도 읽거나 상담하지 않는 모호한 주제에 관한 기사들을 신문 스타일에 특집 기사처럼 보인다.왜 축하하는 거야?Fowler&fowler«Talk » 20:43, 2009년 5월 26일 (UTC)[응답]

• 지금은 중립이다.찬성하는 주된 논거는 (a) 재미있을 것 (아마도) 그리고 (b) 좋은 홍보 (아마도)가 될 것이고, 따라서 새로운 편집자들을 끌어들이는 데 도움이 될 것 같다.반대: (a) 불가피하게 재정/무례성의 강력한 요소가 있을 것이다. (b) 확립된 프로세스를 통해 기사를 개선하는 데 시간과 에너지가 소요될 것이다. (c) 재미없을 것이고, 지루한 논쟁의 더미가 될 것이다.나는 그 단점을 피하는 방법이 제한된 수의 FA 후보를 선택하기 위해 선출된 위원회 같은 것을 구성한 다음, 그들에 대한 총투표를 하는 것이 될 것이라고 제안한다.그럼 조금만 재밌게 놀자꾸나, 어지러움도 제한적으로.Rd232 21:03, 2009년 5월 26일 (UTC)[응답]
• 코멘트 나는 왜 사람들이 자꾸 FAS를 꺼내는지를 모르겠다.나는 이것이 그것과 관계가 있다고 생각하지 않는다.그리고 그렇다, 그것은 어느 정도 (AfD와 RfA와 같은) 팝울리티 콘테스트와 우리가 "투표"하는 다른 모든 과정이다.공천을 위한 일련의 규칙이 있어야 한다.투표를 위한 일련의 규칙.그리고 와라: 재미는 시작하자.내가 제안하는 것은 (그 해에 만들어진) 새로운 글에 대한 범주, 개선된 글에 대한 범주, 즉 새로운 내용을 수정하기보다는 새로운 내용에 대한 상과 인정의 편향이 있는 것 같아 보여서이다.나는 왜 기사가 이 명예를 얻기 위해 FAC가 되어야 하는지 모르겠다, 그것은 그 자체의 잘 확립된 과정이다.그리고 그것이 주의를 산만하게 하는 것에 대한 우려에 한해서, 만약 당신이 그것에 참여하기로 선택한다면 그것은 단지 산만해질 뿐이다...ChildofMidnight (대화) 21:11, 2009년 5월 26일 (UTC)[응답]

  공유지에서는 특집 사진 중에서 사진이 선택된다.이것은 품질에 대한 보증이며, 물론 선택에 필요하지 않다면 장점으로 여겨질 것이다.따라서 사람들은 그들의 기사를 특집화하거나 적어도 좋은 품질로 선정하려고 할 것이고, 이것은 과거의 경험에 따라 그러한 과정을 방해할 것이다.또 논란거리나 정치기사가 지명되면 논란과 드라마를 만들 것이다(버락 오바마의 예를 들어보자).그리고 우리가 참가하고 싶지 않더라도 그것은 우리에게 강요될 것이다.그러나 그러한 과정은 또한 진정한 가치를 가지기 위해서는 지역사회가 전반적으로 대표적이고 인정해야 하는데, 그것은 아마도 얻기 쉽지 않을 것이다.세나륨 (대화) 21:28, 2009년 5월 26일 (UTC)[응답]

• 중립에서 약한 지지로 나는 이것에 내재된 문제들을 볼 수 있지만 우리가 그것을 작동시킬 수 있다면 좋을 것 같다.RD232의 제안과 비슷한 것도 좋아. 닷티닷 (토크) 22:25, 2009년 5월 26일 (UTC)[응답]

반대 우선, FA들의 주제가 매우 다양하다는 것은 무엇이 "최고"인지 결정하는 것이 거의 불가능하다는 것을 의미한다.둘째, 특히 편집자들이 잠재적 FA를 검토하거나 오래된 FA를 정리하는 것과 같이 더 생산적인 일을 많이 할 수 있을 때 2500명의 FA들을 통해 읽는 데 왜 그렇게 많은 시간을 낭비하는가.셋째, 왜 상을 강조하는가?이것은 아마도 어느 정도 인기 경쟁으로 바뀔 것이다.다솜87 (대화) 23:43, 2009년 5월 26일 (UTC)[응답]

반대 지미나 그 이상의 많은 사람들처럼, 나는 헛간스타를 좋아한다.그러나 위에서 열거한 이유로, 그러한 방식으로 그것들을 피처링된 콘텐츠와 연결시키는 것은 바아드다.다솜의 말에 동의하라: 위키백과의 실질적인 개선에 우리가 쓸 수 있는 조금 잘못된 에너지. --Der Wohlte Fuchs ^(talk) 00:21, 2009년 5월 27일 (UTC)[응답]

• 지지하다.나는 보통 대회를 좋아하지 않지만, 좋은 생각인 것 같아.다솜이 질 좋은 콘텐츠 창조를 부추긴다면 나는 전적으로 찬성한다.–Juliancolton 01:08, 2009년 5월 27일 (UTC)[응답]

질문 이미 사진 공모전이 있는 경우 차이점은?그것도 주관적인 대회가 아닌가?나는 반대자들을 정말 이해할 수 없다.참여를 원하는 사람은 할 수 있고, 원하지 않는 사람은 할 필요가 없다.훌륭한 기사가 무엇에 관한 것인지에 초점을 맞추는 좋은 방법인 것 같고 어떤 기사를 추천해야 하는지, 왜 어떤 기사를 최고로 뽑을 것인지, 왜 뽑을 것인지에 대한 토론이 계몽이 될 것 같다.모든 종류의 편견이 있을 것인가?물론이지, 하지만 그곳이 바로 토론과 과정이 들어오는 곳이야. 그래서 우리는 분명 논란이 없는 것이 아니라, 편집자들이 라 젠과 오토바이 정비의 기술을 말하기 위해 "미인"에 집중하도록 할 수 있는 합의 결과를 도출할 수 있을 거야.그리고 모든 편집상의 의사결정은 결국 어느 정도 주관적이다.ChildofMidnight (대화) 01:49, 2009년 5월 27일 (UTC)[응답]

그것이 바로 내가 걱정하는 것이다: "최고의" 기사를 찾고 결정하는 데 드는 시간의 양이다.만약 이것이 "모든 FA들을 나열하고 투표하자"는 단순한 것이었다면, 나는 그것을 찬성한다고 말했을 것이다.그러나 이 과정은 우수한 기사의 집합을 찾고, 기사의 선정 방법을 논의하며, 그 기사의 최선이 어떻게 선정될지를 결정하는 데 상당한 시간이 필요한 것으로 보인다.정말 그럴만한 가치가 있는 일일까?다솜87 (대화) 01:58, 2009년 5월 27일 (UTC)[응답]

또한, 나는 "가치 있는 드라마"의 전망을 기대하지 않는다.그건 이제 충분해.다솜87 (대화) 02:01, 2009년 5월 27일 (UTC)[응답]

위키피디아에는 어느 정도의 가치 있는 드라마를 만들어내지 못하는 것이 있는가?10명의 공동공천자가 서명해 경쟁기사를 선정해야 했고, 다음 라운드에 진출하기 위해 편집자가 한두 명을 뽑을 수 있도록 한 뒤 최종 결과에 대해 모두에게 투표권을 준다면 긍정적일 것이라고 생각한다.사람들은 기사를 읽고 편집하곤 했다.그것은 또한 훌륭한 기사가 무엇에 관한 것인지에 대한 지역사회의 폭넓은 기술을 보유할 것이다.분명 약간의 논란이 있겠지만, 위대한 기사 창작과 글쓰기에 집중하는 것은 본질적으로 참여하고자 하는 누구에게나 긍정적이라고 생각한다.나는 개인적으로 그것이 단지 FAC 기사에만 집중되는 것을 보고 싶지는 않지만, 나는 그것에 찬성하는 추리를 본다.만약 FAS 기사가 유리하다면, 나는 그것이 훌륭하다고 생각하지만, 이 과정은 독립적이어야 한다.어떤 기사가 '선진화'되어야 하는지, 어떤 기사가 선정되어야 하는지에 대한 논의는 매우 계몽적일 것이라고 생각한다.거 참 재미있겠는데.어떤 기사를 쓰시겠습니까?:) ChildofMidnight (대화) 03:47, 2009년 5월 27일 (UTC)[응답]

• 지원 "시간적" 특집 기사만 고려되어야 하는가?즉, 선택된 기사는 그 해 동안의 중대한 사건이나 상징적인 것에 관한 것이어야 한다.예를 들어, 지난 6개월 동안, 그것에 관한 기사가 피처링 상태라면, 그것은 금융 위기가 될 수 있다.타임지의 "올해의 인물"과 같은 느낌으로, 단지 사람들에 국한되지 않고, 특집 기사들만 읽는 주제가 있는 것을 제외하고는 말이다.--사이버코브라 (토크) 21:56, 2009년 5월 27일 (UTC)[응답]
• 이것의 큰 문제는 대중의 인식이다.우리는 더 이상 아무도 신경 쓰지 않는 작은 사이트가 아니다. 우리가 불필요하게 놀 수 있는 곳.만약 우리가 이 제목을 합법화하려면, 그것은 지역사회에 널리 광고되고 승인되어야 할 것이고, 그 결과는 지역사회에 꽤 널리 알려질 것이고, 그 너머에: 그것은 미디어에 의해 선택될 것이다.그리고 사람들은 이것에 대해 어떻게 생각할까?이것을 어떻게 발표해야 할까?위키피디아와 위키미디어 재단에 어떤 결과가 있을 것인가?예를 들어 버락 오바마라면 우리가 이미 받은 것보다 훨씬 더 호의적인 대우와 그를 지지한다는 비난을 받게 될 것이다(그것이 끌리고, 계속해서 규칙적인 혼란을 끌어들인다).그러나 이것은 이 기사에만 해당되는 것이 아니라, 만약 우리가 예를 들어 Halo 3을 선택한다면, 우리는 그 홍보에 대해 비난받을 것이다 ? 물론, U2와 다른 많은 이들에게도 마찬가지일 것이다.오늘의 FA답지 않은 기사, 올해의 기사는 제목이고, 그렇게 보일 것이다.기사를 고르고 다른 사람들보다 더 존중하는 것은 우리의 NPOV 정책에 어긋나지 않는가?대중들은 또한 선택 기준을 기대할 것이다: 위에서 언급했듯이, 그것은 무엇이어야 하는가? 어떻게 해야 하는가? 품질에 기초하여 선택을 해야 하는가? 우리의 대부분의 사용자들은 내용 작성에 전문적이지 않다. 그리고 지적했듯이, 수백 개의 기사의 품질을 비교하는 것은 실현 불가능하며, 그러한 비교는 어쨌든 그다지 타당하거나 타당하지 않다.그래서 그것은 무작위일 수도 있고, 인기에 근거한 것일 수도 있다.그리고 사전 선정 위원회를 만드는 것에 대해서: WP:BURO. 어떻게 하면 이것을 실행 가능하고 광범위하게 수용 가능한 방식으로 구성할 수 있을지 모르겠다.세나리움 (대화) 23:08, 2009년 5월 27일 (UTC)[응답]

그 제안은 7, 8개의 "지지"와 6개의 "반대"를 가지고 있다.그것은 날지 않을 것이다.Fowler&fowler«Talk » 10:18, 2009년 5월 28일 (UTC)[응답]

• 대부분 사용자당 반대:샌디조지아.사진을 보는 것은 몇 초가 걸린다.1분에서 몇 분 정도 정보에 입각한 의견을 형성하는 것.기사를 읽는 것은 적어도 한 순서는 더 많은 작업이다.순수한 인기 경쟁을 넘어 어떻게 결과를 얻을지 모르겠다. --Stephan Schulz (토크) 21:15, 2009년 5월 28일 (UTC)[응답]
• 이제 이것은 짐보의 토크 페이지에 대한 질의에서 내가 이전에 반대했던 의견을 지지하고 반복하면서, 명백히 완전한 투표로 바뀌었기 때문이다.일반적으로 상을 가장 덜 신경쓰는 그룹이 적격인 유일한 사람들이 상을 받는다는 순전히 무의미한 상과는 별도로, 그것은 완전히 다른 주제에 대한 기사 순위를 같은 기준으로 매기는 것이 가능하다는 터무니없는 전제에 근거하고 있다.리치몬드 브릿지, 런던, 캐링턴 모스, 포스팅 시스템, 제리 보히스(작성 당시 마지막으로 승격된 FA 4명)가 서로를 상대로 어떻게 순위를 매기는가?나는 이런 종류의 일이 실제로 Feative Anything을 올리거나 한 단락 이상 기사를 쓴 적이 있다면 더 이상 비생산적이지 않다는 지미 웨일즈의 의견을 받아들일지도 모른다.– 무지개빛 21:31, 2009년 5월 28일 (UTC)[응답]

와우! 그 기사들은 매우 심각한 문제를 가지고 있어.나는 그들 중 한 명이라도 지명하는 것이 편치 않을 것이다.그것은 FA 과정에 대한 심각한 우려를 불러일으키고 또한 나에게 커뮤니티의 폭넓은 의견을 가진 콘테스트가 무엇이 훌륭한 기사를 만드는지 정말로 부각시킬 수 있을 것이다.나는 FA가 무엇에 초점을 맞추는지 잘 모르겠다. 나는 그것이 다소 기술적인 것이라고 의심한다. 왜냐하면 명확하고 잘 쓰여진 자료를 가지고 있는 것은 전혀 고려되지 않는 것 같기 때문이다.ChildofMidnight (대화) 02:55, 2009년 5월 29일 (UTC)[응답]

• 반대 - 올해의 이미지는 꽤 좋은 생각이 될 것이고, 아름다움과 그런 것들을 장려할 것이다.기사가 그런 게 아니라, 너무 번거로울 것 같아.╟-TreasuryTag►hemiccycle-- 07:32, 2009년 5월 31일 (UTC)[응답]
  • 지원:위키백과 기사를 개선하는데 또 다른 인센티브를 제공하는 것은 좋은 일이다.이러한 대사를 따라, 해당 달의 메인 페이지에 나타난 모든 FA가 자동으로 실행 중에 나타나는 '이 달의 특집 기사'를 명명하는 것은 어떨까?승자는 토론 없이 투표로 결정할 수 있었다.피넬 (토크) 2009년 5월 31일 (UTC) 12시 2분 / 응답
• 반대 - 나는 실제로 위키피디아를 돕는 것을 다른 식으로 방해하고 싶지 않다.'올해의 기사' 지위에 오르기 위해 FA들에게 집중하는 것은 그들에게 할 일이 필요하고 할 만한 모든 스타트 클래스 기사들로부터 관심을 끈다.우리는 편집자들이 이미 높은 백과사전적 가치가 있는 지나치게 미화된 기사들로 그것을 필요로 하는 기사들을 개선하는데 더 많은 일을 하도록 격려해야 한다.그레그 타일러 18:52, 2009년 5월 31일 (UTC)[응답]
• "왜 그렇게 심각하지?"에 따라 지원하십시오.나는 '페디아'에 대해 약간의 웃음과 즐거움을 갖는 것이 좋다고 생각한다.— Ched : ? 13:29, 2009년 6월 9일 (UTC)[응답]

대안적 관념

나는 일반적으로 위에 언급된 대부분의 이유 때문에 올해의 특집 기사 아이디어에 반대하지만, 그것은 나를 우리가 장려하고 싶은 것에 대해 생각하게 만들었다.비록 이것이 모호하고 약한 생각이지만(따라서 제안서 이외의 다른 곳에 있어야 할지도 모른다), [다른 기사들]에 대한 월별 또는 분기별 공모전 세트(Banstars와 마찬가지로, 복수의 수상자의 가능성)와 같이 위키백과의 목적을 다루는 조금 덜 거창한 것에 가치가 있을지도 모른다고 생각한다.카테고리] 가장 흥미롭고, 흥미롭고, 유익하며, 이해 가능하며, 읽을 수 있고, 기사 영역 밖의 사람들에게 도움이 되는 것(필드에서 가능한 경쟁자의 편집자로부터의 표를 자동으로 제외한다).예를 들어, 비기술자들이 가장 도움이 된다고 생각하는 컴퓨터 기사, 정치를 따르지 않는 사람들에게 가장 유용한 정치 기사, 비아시아인들이 가장 흥미를 느낀 인도 관련 기사, 비팬들이 가장 흥미롭게 여기는 스포츠 기사 또는 비신학자들에게 종교적인 개념을 가장 잘 설명한 기사 등이 그것이다.ns.

이것은 물론 명예 제도에 있어야 할 것이다(마이크로소프트 엔지니어들이 윈도우에 관한 기사에 투표하는 것을 막는 실질적인 방법은 없다). 그러나 그 목적은 단지 칭찬이나 표창을 받을 만한 기사를 찾는 것이다.나는 기사를 전문가를 포함한 모든 사람이 추천할 수 있다고 생각한다; 그렇지 않으면 (특집 기사와 마찬가지로) 비전문가들은 유명하지 않은 벨기에 상원의원이나 아스피린의 성장이나 철학에서의 어떤 지겨운 문제에 관한 기사가 얼마나 훌륭하거나 잘 쓰여질 수 있는지 결코 모를 것이다.—— Shakescene (대화) 07:20, 2009년 5월 31일 (UTC)[응답]

• 셰이크의 아이디어에 대한 일반적인 지지 To piggyback, 나는 범주가 효과가 있을지는 확신할 수 없지만, 최근에 홍보된 사진/이미지 중 한 달에 한 개씩만 고르면 된다(여기 있는 어떤 사진/이미 FA가 된 기사에 대한 명예도 당분간은 없다).여기에 12개월 수상자 중 연간 수상자를 선정하면 된다.주자들은 또한 추가적인 영예를 위해 선택될 수 있다.그리고 그것이 더 질 높은 글쓰기를 장려한다면 왜 안 될까?— BQZip01 — 08:27, 2009년 6월 2일 (UTC)[응답]

위키백과 연구 리뷰

니즈

위키백과, 위키백과 사용자, 그리고 시스템에 대한 연구는 좋다.연구를 통해 우리는 위키피디아가 어디에서 번창하고, 어디에서 작업이 이루어져야 하는지 더 잘 이해할 수 있다.가장 중요한 것은, 위키피디아에서의 연구는 우리가 그것을 더 좋게 만들기 위해 노력할 수 있게 해준다.

이런 가치에도 불구하고 위키백과에서는 연구를 수행하기 어렵다.관련된 좌절의 예는 실패한 멘토링 연구와 프로세스 내 인터페이스 연구를 참조하십시오.대부분의 연구는 위키피디아에서 연구가 수행되기 전에 (IRB와 같은) 인간 주체가 리뷰하는 것을 보았을 것이지만, 그러한 검토 위원회는 커뮤니티의 규범이나 위키피디아 내의 행동을 승인하는 어떤 위치에서도 알지 못한다.

작동 방법

우리는 위키백과 내에서 적절한 연구를 수행할 수 있는 허가를 허가할 수 있는 승인 과정이 필요하다.그러한 과정은 연구가 시작되기 전에 연구의 적절성에 대한 논쟁을 종식시키고 연구자들이 승인한 활동에 제한을 줄 수 있다.

위키피디아의 대부분의 토론과 마찬가지로, 결과는 합의에 기반해야 하며 공동체의 분쟁 해결 계층을 따를 수 있다.그러면 이러한 결정은 효과적인 구속력을 가질 수 있어 사소한 이유로 연구 중에 토론이 재개될 수 없고 검토 중에 논의된 범위를 벗어나는 연구를 쉽게 식별하고 수정할 수 있다.

나는 연구를 위해 특별히 새로운 마을 펌프를 열 것을 제안한다.이 펌프는 정책 마을 펌프와 유사한 기능을 할 것이다.연구자들이 외부 검토자를 통해 승인을 받으면 마을 펌프로 제안서를 제출해 연구할 수 있다.연구가 어떻게 진행될지에 대한 공감대는 연구가 시작되기 전에 지역사회가 검토할 수 있다.

이 과정은 더 나은 연구가 이루어질 수 있게 해줄 뿐만 아니라 위키백과 커뮤니티가 어떤 식으로든 위키백과를 해치는 연구 방법으로부터 스스로를 보호할 수 있게 해줄 것이다.

--EpochFail (대화) 21:28, 2009년 6월 2일 (UTC)[응답]

위키백과에서 이 문제를 해결하십시오.위키프로젝트 위키디아도 마찬가지 입니다.나노닉 (토크) 21:55, 2009년 6월 2일 (UTC)[응답]

완료! 제안 감사합니다, --EF_pochail(토크 기여) 20:15, 2009년 6월 3일 (UTC)[응답]

기관/조사 검토 위원회에 대한 나의 제한적인 이해는 IRB가 어떤 중요한 전문분야에서 부족한 것이 분명한 경우 주제 전문가들을 참여시키는 것이 일반적으로 권장된다는 것을 시사한다.따라서, 스튜어드나 재단 이사회의 멤버의 참여는 이와 같은 경우 임시 IRB 멤버로서 문제에서 벗어나지 않을 것이다. --사용자:Ceyockey (Talk to me) 2009년 6월 4일 00:57 (UTC)[응답하라]

이것은 기관 IRB를 대체하는 것이라면 유용할 것이다.그렇지 않으면 관료주의의 또 다른 층을 추가하고 싶을 뿐이다(그리고 위키백과 IRB가 내 대학 IRB에 동의하지 않을 경우 어떻게 될지 생각조차 하고 싶지 않다...). PS. 나는 위키백과인들의 조사를 하는 것이 허용될 수 있고, 연구자들이 통상적인 윤리 규범을 따라야 한다는 정책에 어딘가를 추가하는 것을 전적으로 지지한다.그러나 나는 위키백과 자체의 관료주의적 IRB 지옥의 창설을 지지하고 싶지 않다(WP:CREP 또한 떠오른다.그리고 어쨌든 어떤 불쌍한 영혼들이 그것을 담당할 것인가?_{Piotr Konieczny aka Prokonsul Piotrus talk} -- 07:37, 2009년 6월 4일 (UTC)[응답하라]

좋은 지적이야.우리가 결코 하고 싶지 않은 것은 단순히 위키백과에서 연구를 수행하는 과정에 관료주의를 더하는 것이다.비록 내가 처음에 그것을 서투르게 진술했다고 생각하지만.이 제안의 결과로 내가 진정으로 얻고자 하는 것은 학문적 연구가 위키백과에서 성공적으로 수행될 수 있는 더 간단한 방법이다.캐서린이 자신의 설문조사를 수행하려고 할 때 겪었던 문제들이 과도한 레드 테이프를 도입하지 않고도 피할 수 있다면, 나는 그것이 더 바람직하다고 생각한다. --EpochFaile 21:31, 2009년 6월 4일 (UTC)[응답]

반공식 IRB와 같은 승인 과정을 거치는 것보다는 WP와 생소한 이들이 읽을 수 있도록 작성한 연구 가이드라인을 제시하는 간단한 페이지(적절한 장소로부터 연계)가 더 바람직하다고 생각한다. --사이버코브라 (토크) 06:29, 2009년 6월 9일 (UTC)[응답]

참조되지 않은 새 전기 정보를 모니터링하는 봇

나는 새로운 전기를 모니터하고 그 기사들에 참고자료가 포함되어 있지 않으면 작가들에게 알릴 새로운 봇을 생각하고 있다.봇은 또한 참조되지 않은 전기의 목록을 한 페이지로 출력할 것이다.생각은? --MZMcBride (대화) 04:53, 2009년 6월 3일 (UTC)[응답]

기사가 바이오라는 것을 어떻게 추론할 수 있을까?그 기사가 참조가 없을 정도로 나쁘면, 그 기사 역시 분류되지 않을 가능성이 있다. --Cybercobra (토크) 05:07, 2009년 6월 3일 (UTC)[응답]

카테고리의 존재 여부:살아 있는 사람들.그리고, 그렇다, 그것은 또한 범주화되지 않을 수도 있다.그러나 그것은 또 다른 봇을 위한 프로젝트다. ;-) --MZMcBride (토크) 16:18, 2009년 6월 3일 (UTC)[응답]

나는 살아있는 사람들의 범주를 포함하고, 참고문헌을 포함하지 않으며, 문제가 되는 BLP-현재가 될 새로운 기사들의 수는 다소 적으며, 심지어 참조문헌은 있지만 봇-읽을 수 있는 형식은 아니고 논쟁의 여지가 없는 거짓 긍정으로 인해 더 많을 수도 있다고 생각한다.이 목록은 인간에 의해 확인될 경우 더 유용할 수 있으며, 논란의 여지가 없는 항목을 제거할 수 있다. 또한 참고문헌을 추가하지 않고 전기의 추가사항을 찾는 것도 유용할 수 있다.그런데 후자 대신 국기 개정판을 사용하는 거지?-NE2 16:27, 2009년 6월 3일 (UTC)[응답하라]

참고문헌을 포함하지 않는 BLP는 본질적으로 문제가 있다.내 생각에, 적은 수는 일을 더 쉽게 할 수 있게 한다.그리고 봇은 참고문헌을 탐지하는 일을 꽤 잘 할 수 있다; 몇몇 기사는 놓칠 수 있지만, 어떤 잘못된 긍정도 포함시켜서는 안 된다.적어도 그 생각이야. --MZMcBride (대화) 16:46, 2009년 6월 3일 (UTC)[응답하라]

링크한 페이지를 읽으십니까?"자료가 부정적이든, 긍정적이든, 아니면 그저 의문스러운 것이든 간에, 공급되지 않았든 간에, 살아 있는 사람들에 대한 만족스러운 자료는 토론을 기다리지 않고 즉시 제거되어야 한다."이것은 형편없는 (그러나 상당히 비협조적인) 준 BLP이지만 논쟁의 여지가 있는 것은 아무것도 없다.만약 누군가가 그 회사가 어떻게 일을 잘하지 못하는지에 대해 비소싱적이거나 형편없는 정보를 추가한다면, 그것은 다른 진술에 대한 출처가 있는지 여부에 상관없이 문제가 될 것이다. --NE2 17:18, 2009년 6월 3일 (UTC)[응답]

넌 날 잃었어.여기서의 목표는 특정한 문제에 초점을 맞추고 그것을 다루려고 노력하는 것이다.--MZMcBride (대화) 20:40, 2009년 6월 3일 (UTC)[응답]

나무를 잃었구나.진짜 문제는 전기에서 나쁜 정보, 대개 부정적이다. --NE2 22:06, 2009년 6월 3일 (UTC)[응답하라]

물론이지그러나 그것은 처음부터 나의 목표가 아니었다.바다를 마시려고 하기보다는 작은 물고기 한 마리를 먹으려고 하는 것이 나의 목표였다.알아?작성자에게 미리 경고하고 모니터링할 수 있는 참조되지 않은 새 전기(하루에 몇 개의 바이오스만 사용 가능)작은 걸음이다. --MZMcBride (대화) 22:09, 2009년 6월 3일 (UTC)[응답하라]

약한 지지 Per, 위의 논평들, 그다지 유용하지는 않을 것이라고 생각하지만, 그 영향은 부정적이지 않을 것이기 때문에 반대할 이유가 없다... --사이버코브라 (대화) 06:24, 2009년 6월 9일 (UTC)[응답]

평가 순위

현재 평가 순위는 Stub, Start, C, B, GA, A, FA이다.불행히도, 왜 그런지 알 것 같아. 아주 길고 형편없는 글/편집된 글들이 C로 표시되거나 심지어 B로 표시되기도 해. 왜냐하면 아무도 자신의 글이 C 등급이 되기를 원하지 않아서 B로 표시되고 2로 표시되고 싶지도 않고 너무 길어서 "시작"이라고 부르는 것이 말이 안 되기 때문이야.이 문제는 위키피디아 토크에서 나왔다.뉴욕 뉴버그(타운) 관련 위키프로젝트 뉴욕.D클래스의 제도를 탐구할 필요가 있을까?나는 다른 사람들의 의견에 대해 궁금하다. 아마도 왜 내가 보지 못하는 낙제점수가 없는지에 대한 매우 타당한 이유가 있을 것이다.카멜빈키 (대화) 01:24, 2009년 6월 4일 (UTC)[응답]

나는 그것을 위한 관료주의인 D학급의 신설에 전적으로 반대하며, 의미 없는 새로운 C학급의 신설도 극도로 싫어한다.하위 기사 평가는 순전히 작업이 필요한 기사를 식별하는 것이다. 위키백과 용어에 특별한 의미를 가진 평가 등급은 FA/A/GA뿐인데, 이는 정해진 기준에 따라 평가되기 때문이다.그것은 그것이 시작이든 B 등급이든 어떤 기사에도 조금도 영향을 주지 않는다; 만약 당신이 특정한 기사에 주어지는 분류에 반대한다면, 그것이 GA/FA에 있지 않다면, 그것은 당신이 그것을 다운그레이드하기 위해 적절하게 GAR/FAR을 거쳐야 하는 것이 아니라면, 당신이 그것을 바꾸는 것을 막을 수 있는 것이 아무것도 없다; (주관적) 기준은 여기에 있다.위키백과는 시험도 비디오 게임도 아닌, 위키백과에서 기사를 "실패"하지 않는다. 위키백과에서 기사가 위키백과에 적합하지 않다고 생각되는 경우, 수정하거나 AFD로 수정한다. – 무지개빛 01:30, 2009년 6월 4일 (UTC)[응답]

나는 네가 WAAYE에 대해 너무 흥분/설정을 했다고 생각한다. 첫째, 나는 네가 내가 무슨 말을 하는지 이해할 수 없다고 생각한다. 셋째, 나는 평가가 중요하지 않다는 것에 동의하지 않는다.스텁 클래스는 막 만들어진/아주 가냘픈 기사들을 그렇게 인식하도록 허용하고, 그들이 즐겨 하는 일이기 때문에 스텁을 개선하고 돌아다니는 것에만 전념하는 편집자들이 있다. 마치 참고문헌을 찾고 수정하고, 페이지를 만들고, 문법을 복사하는 것에 초점을 맞추는 사람들이 있는 것처럼.또는 사진을 넣거나, 전통적인 정보 편집이나 기사 작성은 하지 않는다.그리고 D학급이 있으면 아마도 D학급 기사를 개선하는데 전념하는 학부형들이 도착할 것이다.아무도 D가 "실패"할 것이라고 말하지 않았는데, 그것이 아마도 그것이 존재하지 않는 이유일 것이다. 어떤 사람들은 어떤 기사가 D를 받을 경우 "감정"이 상처받는 것을 두려워한다."이것은 비디오게임이 아니다"에 대한 너의 논평이 이해가 안가. 내가 그렇다고 말했니?기사에게 D등급을 주는 것은 위키백과에 적합하지 않다고 말하는 것이 아니라, "이 기사는 많은 개선이 필요하며 형편없다"라고 말하는 것일 것이다.단순하게 SUP라는 기사가 있지만 주제가 중요하고 삭제해서는 안 된다.내가 말한 기사는 아무리 엿같아도 100배는 더 심해도 절대 삭제되어서는 안 된다.기사에 대한 평가와 평판에는 차이가 있다.명성 때문에 어떤 것이 삭제되어야 하는 것이지, 그것이 단순히 형편없는 편집자들을 가졌다는 것이 아니다!GA, A, FA와 마찬가지로 C와 B에 대한 기준이 정해져 있다.그렇게 형편없이 형편없는 기사들은 지적되어 이미 기고하고, 기고하고, 기고하고, 기고하고 있는 편집자들의 주목을 끌 필요가 있으며, 실수를 고칠 수 있도록 할 수도 있다.그렇기 때문에 우리는 "시민이 필요하다" "너무 많은 잡담을 포함한다" "너무 길다" "너무 상세한 내용을 포함한다"와 같은 것들을 언급하는 템플릿을 가지고 있다. 만약 이 템플릿들 중 몇 개가 이 템플릿들을 철썩철썩 철썩철썩 붙이면, 그것은 토크 페이지에 낙제점이라고 표시될 필요가 있다.나는 너의 선택이 "고치기냐, 아니면 AfD냐"라는 것에 모욕감을 느낀다, 내가 모르는 기사를 왜 고쳐야 내가 대신 D학점을 주어 관심있는 사람들의 관심을 끌 수 있다.카멜빈키 (대화) 01:49, 2009년 6월 4일 (UTC)[응답]

나는 대부분 무지개빛에 동의한다.FA, GA, 그리고 일부 프로젝트의 경우 A를 제외한 모든 것이 그대로 임의적이다.이것은 불필요한 바쁜 일처럼 보인다.실제로 스타트와 C급 기사를 개선시키기보다는, 그 중 일부 기사에게 또 다른 임의의 등급을 주기 위해 다시 검토해보자.우리는 이미 7단계 등급제를 가지고 있어, 그 이상은 충분해.미스터 지맨 02:25, 2009년 6월 4일 (UTC)[응답]

개인적으로, 나는 C 클래스를 좋아하지 않아.기사가 어느 정도 가치가 있다는 것을 증명하기 전까지는 기사가 시작되어야 한다. 그 때 기사는 B가 된다.일단 그들이 제대로 보이면, 그들은 GA, A, 그리고 마지막으로 FA로 간다.시작과 C와 C와 B를 구별하기 어렵게 만드는 중간 단계에서는 C 클래스가 정말 무의미해, 네가 말하는 문제를 야기한다.우리가 잘못 분류된 문제가 있는 이유는 내 눈에 너무 많은 것이 있기 때문이다.분명히, 더 추가하는 것은 도움이 되지 않을 것이다.그레그 타일러 16장 44절, 2009년 6월 4일 (UTC)[응답하라]

나는 C클래스가 B클래스 기준에 맞는 기사를 찾는 출발점이라고 말하고 싶다.B-Class는 GA ect로 개선될 수 있다.아가토클레아 (대화) 07:54, 2009년 6월 5일 (UTC)[응답]

나는 C-클래스 평가의 가장 강력한 지지자 중 한 명이었는데, 나는 평가 계획에서 매우 실질적인 격차를 메웠다고 주장하겠지만, D-클래스 신설에도 반대할 것이다.평가 체계는 객관적 기준보다는 주관적 기준을 사용하여 다소 모호한 성격과 필요성에 따라 평가 체계가 결정된다.그러므로, 그것은 우연적이고 의도적인 오식 모두에 열려있다: 실제보다 높은 기사를 평가한다.훨씬 더 명확한 B-클래스 기준을 설정할 수 있게 함으로써 C-클래스의 도입이 달성한 것은 WP1.0 평가 체계인 FA/A/GA에서 사용하는 지역으로부터 솜털을 이동시켰지만, 또한 양질의 B-클래스 기사도 이동시킨 것이다.이전에 "B-Class"는 경계선 GA에서 정적인 버전으로 쉽게 허용되고 일반적으로 신뢰할 수 있는 범위까지 포함되었으며, 주로 장황한 것으로 주목할 만한 드라이브라인 더미까지 포함되었다."C-Class"는 드라이브라벨이 다운그레이드 되고, 위키백과에 관한 B-Class 기사를 접하게 되면 적어도 '통과 가능한' 품질이 될 것이라고 일반적으로 확신할 수 있다.그것이 나에게 C-클래스 도입의 가장 큰 성과다.

반면 D클래스는 그런 장점이 없다.그 '허용된' 경계선 아래로 떨어지는 엉터리 기사들을 더 세분화하는 것은 누구에게 중요하거나 유용한가?C-Class 또는 Start-Class와 구별되는 이러한 기사를 식별하기 위해 어떤 루브릭을 사용하시겠습니까?나는 이 분과에 아무런 이득이 없다고 본다.해피멜론 19:31, 2009년 6월 5일 (UTC)[응답]

해피멜론 말에 동의해–Drilnoth (T • C • L) 19:41, 2009년 6월 5일 (UTC)[응답]

C급은 과잉 살상이었는데 D급이 무슨 소용이야?시작보다 더 나쁜거야?NVO (대화) 09:31, 2009년 6월 7일 (UTC)[응답]

응, 더 이상 평가 수업은 하지 말아줘.–Juliancolton 13:43, 2009년 6월 9일 (UTC)[응답]

4,000명의 평가 편집자를 내게 주면 나는 Y-Class까지 모든 서신을 구현하도록 노력할 것이다.B클래스의 대부분이 B를 제대로 보지 못한 채 마감되지 않은 많은 물건들이 있다.개선은 위키백과의 평가도 아닌 과제다.--Stone (토크) 19:37, 2009년 6월 9일 (UTC)[응답]

BLP 딜레마에 대한 새로운 해결책?

안녕하십니까, BLP 문제에 대한 해결책을 찾던 2년 동안, 마침내 이전에는 제기되지 않았던 아이디어를 우연히 발견하게 되었다.기본적으로 다음과 같다.

대상자의 요청에 따라 살아있는 사람들의 전기를 색인화하지 않았다고 가정합시다.

이를 위해서는 개발자의 도움이 필요하며, 기능이 잘못 이용되지 않도록 약간의 구조가 필요하다.초기 제안 초안은 내 블로그에 있다.[1] 생각과 제안에 관심이 있다.듀로바^Charge! 20:56, 2009년 6월 4일 (UTC)[응답]

흥미로운 아이디어지만, 일부 사람들은 우리가 그것들을 색인화하지 않는다면 백과사전으로서의 의무를 태만히 할 것이라는 것을 충분히 주목할 수 있다. 이것은 구글 검색자들이 위키백과 기사에 즉시 접근할 수 없도록 할 것이기 때문이다.대상자의 요청은 우리의 최소한의 관심사가 되어야 한다. bd2412T 20:59, 2009년 6월 4일 (UTC)[응답]

피실험자의 요청이 우리의 관심사 중 가장 적은 것이어야 하는가?그럼 BLP의 이 부분을 업데이트하고 싶을 겁니다.NW (토크) 21:12, 2009년 6월 4일 (UTC)[응답]

(ec) 나는 이것이 무엇을 이룰지 잘 모르겠다.모든 BLP 문제는 여전히 남아있을 것이고, 검색엔진을 통해 조금 덜 보일 것이다.물론, 그들은 여전히 GFDL에 따라 허가된 상태로 남아있을 것이고 거울은 그것들을 자유롭게 복사할 수 있을 것이다.구글에 의해 모든 거울이 색인화되는 것을 막기 위한 것은 무엇인가?쿨3 (토크) 21:01, 2009년 6월 4일 (UTC)[응답]

여기 듀로바의 말을 인용하면, "일반적으로, 대부분의 전기 주제의 주된 불평은 검색 엔진에 의한 위키피디아 기사에 주어진 높은 순위와 악의적인 반달리즘을 막기 어려운 어려움과 결합되어 있다.요청 시 전기를 삭제하는 것에 대한 반대는 대부분 백과사전적 완전성에 대한 열망과 관련이 있다.그래서 이것은 실행 가능한 타협처럼 보인다."NW (토크) 21:12, 2009년 6월 4일 (UTC)[응답하라]

나는 특히 이 아이디어를 좋아한다. 왜냐하면 종종 그 기사는 언급될 수 있는 잠재력이 있기 때문이다. 또는 명예훼손성 진술은 삭제될 수 있기 때문이다.이 해결책으로는 아무도 일을 하지 않는 동안 잠재적 피해를 제한할 수 있다.그리고 사람들은 여전히 그 기사를 작업할 수 있다; 그것은 일단 문제가 해결되면 색인화될 수 있다.— Jake Bartenberg 21:20, 2009년 6월 4일 (UTC)[응답]

그래서 여기서의 생각은 구글에서 아무도 찾을 수 없는 한 몇몇 사람을 명예훼손해도 괜찮다는 거야?쿨3 (토크) 21:22, 2009년 6월 4일 (UTC)[응답]

아니, 여기서의 생각은 명예훼손이 구글 검색을 할 때 위키피디아에 대한 사람의 첫 번째 의견은 아니라는 것이다.명예훼손은 결코 괜찮지 않으며, 이것은 사람들이 그것에 노출되는 것을 최소화할 것이다.덴도지_T\^C 21:27, 2009년 6월 4일 (UTC)[응답]

맞아, 문제가 해결되는 동안 삭제와 보관 사이의 절충.— Jake Bartenberg 22:08, 2009년 6월 4일 (UTC)[응답]

IMO 이것은 별로 도움이 되지 않을 것이다.너무 안 좋은 일이 있어 일반 대중에게 가려지려면 그냥 삭제하거나 공격적으로 치워야 한다.아무 문제가 없다면, "불행할 수 있어 죄송하지만, 기사는 균형잡히고 신뢰할 수 있는 출처와 잘 참조되어 있다"는 주제로 말할 필요가 있으며, 논란의 여지가 없는 내용을 숨겨서는 안 된다.어쨌든 그 문제로부터 정당한 항의를 받을 때쯤이면 이미 우리는 실패한 것이다.우리는 불평을 들은 후에 많은 일을 한다.OTRS 팀이 잘하는 게 바로 그것이다.우리가 노력해야 할 것은 민원을 막는 것이지, 민원이 소송이 되는 것을 막는 것이 아니다.Mr.Z-man 23:28, 2009년 6월 4일 (UTC)[응답]

아니, 아니, 아니.그 사람이 눈에 띄고 균형 잡힌 전기를 쓸 자격이 있거나 그렇지 않다.말하자면 융단 밑의 내용을 쓸어버리는 것은 정답이 아니다.기사 네임스페이스에서 __NOINDEX__가 작동하지 않는 이유가 있다.나는 어떤 개발자가 이 아이디어를 실행하기 위해 소프트웨어 도구를 만드는 것을 상상할 수 없다. 그리고 그럴만한 이유가 있다.우리 콘텐츠를 제대로 다뤄야 하거나, 될 수 있을 때까지 삭제해야 한다. --MZMcBride (대화) 00:45, 2009년 6월 5일 (UTC)[응답]

동료 여러분, 우리는 공개 편집 사이트라는 것을 기억하십시오.매주 그의 전기를 점검하는 BLP 주제가 있다고 가정합시다.기사를 쓸 만큼 눈에 띄고, 많은 워치리스트에 오를 만큼 유명하지 않으며, 서비스 사업을 하고 있다.그가 전기를 점검한 다음날 경쟁자는 전략적으로 전기를 파괴한다.그러니까 그가 문제를 깨닫고 OTRS 요청을 하기까지 6일이 남았어.그 시간에, 잠재 고객이 그 페이지를 읽는가?그 때문에 계약을 잃고 직원 3명을 해고해야 하는 건가?그건 정말 해롭다. 그리고 만약 피험자가 삭제하지 못하고 핑크빛 전표를 나눠주는 것보다 무색인 것이 낫다고 판단한다면, 나는 우리가 그것을 존중한다고 말한다.그는 자기 욕구를 우리보다 더 잘 알고 있다.듀로바^Charge! 01:05, 2009년 6월 5일 (UTC)[응답하라]

그런 다음 공공 기물 파손을 복구하고 반보호하거나, 활성화되면 플래그 지정된 Revs를 켜면 된다.이 제안에 따라 피해를 막을 수 있는 유일한 방법은 그 주체가 사전에 우리와 접촉하는 것인데, 내 경험상 그런 일은 거의 일어나지 않는다.그 시나리오의 끝은 말이 안 된다.그게 어떻게 가능한 두 가지 선택사항이 될 수 있는지 모르겠네.a) 반달리즘은 이미 구글에 의해 픽업되었고, 우리는 그것을 되돌리고 구글이 그것을 다시 색인화하기 전에 아무도 눈치채지 않기를 바라거나, b) 반달리즘이 아직 색인화되지 않고 그냥 정상처럼 되돌아간다.어느 시나리오에서도 노인덱싱은 어떤 것도 해결하지 못한다.만약 그것이 이미 색인화되었다면 그것은 너무 늦었다.아직 인덱스가 작성되지 않았다면, 그것은 실질적인 목적을 달성할 수 없다.미스터 지맨 01:41, 2009년 6월 5일 (UTC)[응답]

BLP 문제에 대한 절대적인 해결책은 아니지만, 실행될 경우 BLP 불만사항의 절반 이상을 해결할 수 있는 상당히 유용한 도구가 될 수 있다(내 추정) 알렉스 바하레프(토크) 01:10, 2009년 6월 5일(UTC)[응답]

기사 고치는 걸 피하는 방법 같군BLP 불만사항을 해결하는 적절한 방법은 비소지 진술서를 삭제하거나 기사를 삭제하는 것이다.미스터 지맨 01:41, 2009년 6월 5일 (UTC)[응답]

아무도 우리가 BLP를 고치는 것을 금지한다고 말하지 않는다.하지만 어려운 사실은 우리가 모든 BLP를 능동적으로 순찰할 자원 봉사자들이 없다는 것이다.피험자의 요청에 따라 알려지고 반복된 목표물을 지수화함으로써, 우리는 문제를 인식하기 전에 미래의 비열한 속임수가 실제 해를 끼칠 가능성을 최소화한다.듀로바^Charge! 02:48, 2009년 6월 5일 (UTC)[응답하라]

그 다음 페이지를 보호하라. 그것이 보호를 위한 것이다.구글의 결과에 명예 훼손이 나타나지 않게 하는 것은 아무것도 해결하지 못한다.MZM이 위에서 말했듯이, MZM이 하는 일은 그것을 깔개 밑에 쓸어넣는 것뿐이다.나는 BLP 순찰이 이 제안과 어떻게 관련이 있는지 모르겠다.고소장을 접수할 때쯤이면 이미 순찰에 실패했소.우리가 BLP를 보호하기 위해 더 이상의 노력을 기울이려면, 문제가 발생하는 것을 막거나 불만 사항이 접수되기 전에 해결하는 등 예방적 측면에 있어야 한다.사실 이후 문제를 가리는 것은 무의미해 보인다. 미스터 Z-man 04:07, 2009년 6월 5일 (UTC)[응답하라]

철학적인 질문은 제쳐두고, 어쨌든 효과가 있을까?구글은 물건을 캐시한다.PL290 (대화) 16:18, 2009년 6월 8일 (UTC)[응답]

Mr.Z-man 당 반대.이 제안은 BLP의 진짜 문제를 회피할 뿐이다. --사이버코브라 (대화) 06:20, 2009년 6월 9일 (UTC)[응답]

논쟁의 여지가 있는 주제에 관한 저작물

나는 위키피디아가 작동하는 방식이 정말 멋지다고 생각해.그러나 논쟁거리가 될 때마다 (독자가 바꿀 수 없는) '오피니언 작품'을 갖고, 자신의 말에 책임을 지는 작가의 서명을 받는 것이 유리할 수 있다는 생각이 문득 떠올랐다.

전혀 상상할 수 있는 일인가?정성스럽게

음스크

멜버른 모나시 유니버스티 몰타 대학 명예 연구 협회 지중해 연구소의 마르첼로 소스 켈러 보드 박사

위키피디아의 임무는 신뢰할 수 있는 출처로 출판된 정보를 제시하는 것이다.만약 당신이 어떤 것에 대해 강한 의견을 가지고 있다면, 그것을 신뢰할 수 있는 어떤 출판물에 출판하게 하고, 그러면 WP는 그것에 대해 쓸 수 있을 것이고, 그 출판물을 출처로서 의지할 수 있을 것이다.Crum375 (대화) 20:25, 2009년 6월 7일 (UTC)[응답]

우리의 정책 중 하나는 독창적인 연구를 발표하지 않는 것이다."오피니언 작품"은 독창적인 연구일 것이기 때문에, 그것은 우리의 정책에 완전히 어긋난다.미안하지만, 그건 할 수 없어.의견의 조각은, 정말로, 블로그에 속해있다 - 당신이 자신을 표현하고자 하는 장소들.그래도 제안해줘서 고마워.그레그 타일러 13:02, 2009년 6월 8일 (UTC)[응답]

그러나 논쟁의 여지가 있는 문제들에 의해 한 신뢰할 수 있는 출처가 다른 출처와 모순되는 경우를 언급한다면, 이러한 것들은 의견이 아닌 균형 잡힌 관점이 제시되는 한 위키백과 기사에 나타날 수 있다.PL290 (대화) 16:39, 2009년 6월 8일 (UTC)[응답]

우리는 위키피디아의 운영과 관련이 있는 우리의 사용자 에세이를 제외하고 의견 작품을 발표하지 않으며, 다른 종류의 원작을 발표하지도 않는다.만약 당신이 약간의 것을 발견한다면, 다른 편집자들이 그것을 좀 더 적절한 것으로 바꿀 수 있도록 도와줘. M 17:21, 2009년 6월 8일 (UTC)[응답하라]

내가 위에 있는 개인 정보 몇 가지를 제거했어.그게 얼마나 중요한지는 모르지만, 미안한 것보다는 안전한 게 낫다 :/ [불타는 변호사] 02:30, 2009년 6월 9일 (UTC)[답글]

당신은 주요 기사가 동정적인 POV를 가지고 있고 하위 기사들이 다른 POV를 대표하고 있는 Wikinfo에 관심이 있을 것이다; 그것은 사실상 위키피디아의 콘텐츠 포킹 정책의 역이다. --사이버코브라 (talk) 06:11, 2009년 6월 9일 (UTC)[응답]

비즈니스용 RefDesk

나는 종종 사업을 다루는 인문학 레퍼런스 데스크에서 많은 질문들을 본다.그 질문들 중 몇 가지는 내가 직접 올렸다.비즈니스 문제를 위해 RefDesk를 시작하는 것이 실용적인가?아니면 스펙트럼이 너무 좁은가?다음에 내가 위키피디아에 있을 때 이 페이지를 확인하는 것을 잊어버릴 수도 있으니, 내 토크 페이지로 너의 답변 사본을 보내줘.고마워!--Ractogon (대화) 03:03, 2009년 6월 10일 (UTC)[응답]

모든 섹션 템플릿 간의 일관성

서버 및 네트워크를 저장하기 위해 이미지를 재사용하십시오.

모든 섹션 템플릿을 동일한 크기로 만들 수 있지 않을까?{{ expand-section}}의 크기를 작게 하고 크기를 줄인다는 논의가 있었다.그럼 {{비참조 섹션}}은 어떠세요?나도 이 템플릿 축소를 제안하고 싶다.--디아아 압델모네임 (대화) 22:24, 2009년 5월 28일 (UTC)[응답]

Template talk에 대해 물어 보십시오.참조되지 않은 섹션 또는 템플릿 대화:참조되지 않음(참조되지 않음 섹션 호출 참조되지 않음)이 예제는 ambox 호출에 "small=left"를 추가하지만 템플릿을 더 크게 보이게 한다.

이 절은 어떠한 참고자료나 출처를 인용하지 않는다.신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오.검증 불가능한 소재는 도전하여 제거할 수 있다.

84user (talk) 02:38, 2009년 5월 29일 (UTC)[응답]

아래 호르헤와 해피멜론의 논평이 있은 후 나는 이 예를 우열을 가리기 위해 포장했다.공간은 절약하지만, 오른쪽 정렬된 물체와 충돌하는 것 같다.84user (대화) 04:45, 2009년 5월 31일 (UTC)[답글]

• 들어봐, 들어봐!그리고, 제발, 그들이 오른쪽 여백에서 가장 평평하게 보이도록 해, 마치 [[이미지:...]처럼 말이야.right …]]], 빈 라인으로 화면 공간을 낭비하지 않도록 하며, 기사 읽기에 지장을 주지 않도록 한다.모든 베스트, --Jorge Stolfi (토크) 08:14, 2009년 5월 29일 (UTC)[응답]

아, 스크린 공간을 낭비하는군.종파 팽창이 단지 몇 마디 말인 것처럼 작게 만들려면 크게 줄여야 할 것이다.

호르헤, 오른쪽 떠 있는 작은 옵션은 mbox의 디폴트였고, 우리(그것을 쓴 템플릿 코더)는 특별히 작은 앰박스에 대해 왼쪽 정렬 버전을 만들어 달라는 요청을 받았기 때문에, 오른쪽에 있는 영구적인 이미지, 인포박스 등을 방해하지 않을 것이다.해피멜론 11시 2분, 2009년 5월 29일 (UTC)[응답하라]

작은 글씨체로 {{mbox}}}을(를) 사용하는 퍼지는 여기 있지만, {{참조되지 않은 섹션}}에 비해 텍스트 한 줄만 저장한다.

이 절은 어떠한 참고자료나 출처를 인용하지 않는다.신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오.검증 불가능한 소재는 도전하여 제거할 수 있다.

84user (talk) 05:05, 2009년 5월 31일 (UTC)[응답]

확장 템플릿처럼 태그에 있는 정보를 잘라내는 게 어때?이것에서 저것으로 바뀐 것.나는 "이 섹션은 신뢰성을 충족시키기 위해 더 많은 참고자료를 필요로 한다"고 권고하고 싶다.

'만나는 것'이라고 하면, '준수하는 것'이라는 줄임말인 '만나는 것'이라고 하면, 정책에 연결되나 이름으로는 참조하지 않는 것이 헷갈린다.신뢰성 정책이 없다.어때.

이 절에서는 검증가능성을 보장하기 위해 추가 참조를 요구한다.

오, 귀엽다!나는 최소한의 와플 콘텐트로 섹션 템플릿을 일관되게 작은 스타일로 만들려는 움직임을 지지한다.해피멜론 19:30, 2009년 5월 31일 (UTC)[응답]

좋아, 나는 새 템플릿을 지지한다.그것은 간단하고 아무도 한 구역에 그렇게 큰 템플릿이 필요하지 않다.잘했어!!!--Diaa abdelmoneim (대화) 2009년 5월 31일 (UTC) 19:38[응답]

나도 찬성이다.84user (대화) 2009년 6월 1일 12시 31분 (UTC)[응답]

가장 최근의 것 또한 내 표를 가지고 있다.드류 스미스 2009년 6월 3일 01:18, 내가 한 일[응답]

자료의 부족이 확장의 필요성보다 독자와 편집자에게 주는 훨씬 중요한 메시지라고 믿기 때문에, 나는 비록 그것에 동의하지 않지만, 규모의 변화를 감수할 수 있다.또한 이 템플릿은 완전히 참조되지 않은 섹션에 대한 것이며 위의 문구를 변경하면 {{refectecture}}}에 해당된다.템플릿의 크기를 변경해야 한다는 데 의견이 일치한다면(있는 것 같음) 다음과 같은 선에 따라 제안하고자 한다.

이 비참조 섹션은 검증가능성을 보장하기 위해 인용구를 요구한다.

{{unreferenced section}}과(와) {{refevecture}}}을(를) 구분하지 않으면, 메시지가 더 강하기 때문에 편집자가 완전히 참조되지 않은 섹션에 {{unreferenced}을(를) 추가할 수 있다.측면에서는, 이것이 의 사용에 어떤 영향을 미칠까?{{unreferenced section}}현재 다음과 같은 결과를 산출하고 있다.{{unreferenced section}} ? Ascidian Talk-to-me 2009년 6월 7일 (UTC)[응답]

이 절에서는 검증가능성을 보장하기 위해 추가 참조를 요구한다.

나는 그 둘의 차이도 구별할 필요도 없다고 본다.두 경우 모두 참조를 더 추가하는 것이 해결책이다.나는 그들이 인포박스와 포탈과 인터위키 링크의 방식으로 우변으로 있는 것이 더 낫다고 생각한다.나는 정말로 왜 '영구적'인 우 정렬 요소와 '인터페어링'하는 것이 문제가 되는지 모르겠다. - 그 부분을 청소한 후에 고칠 수 있는 모든 것.기사의 실제 본문을 간섭한다면 훨씬 더 큰 문제라고 생각한다.하지만 또 한편으로는, 이것이 요점이 될 수도 있다. M 18:23, 2009년 6월 7일 (UTC)[응답하라]

템플릿은 쉽게 눈에 띄는 곳에 있어야 하며, 기사의 본문을 참조하므로 (편집 섹션 링크처럼) 오른쪽으로 띄우지 마십시오.OrangeDog (토크 • 편집) 09:09, 2009년 6월 12일 (UTC)[응답]

약어 및 기타 TLA에 대한 설명 템플릿

나는 많은 장소들을 감시하지 않고, 나는 한동안 돌아다닌 적이 없고, 나는 지금 이곳에서의 대화가 어떤 것인지 전혀 알지 못한다. 그래서 이것은 여러 번 제안된 것일 수도 있고, 내가 아는 모든 것을 위해 존재할 수도 있다.예를 들어, KGX 같은 페이지에서는 이와 비슷한 것을 가지고 있다.즉, 일반적인 약어에 대한 매개변수가 있는 템플릿(ICAO, IATA, 이것, 이것, 또는 그 밖의 것)이다.내가 질문하는 이유는 TLA의 모호한 페이지들 전체에 걸쳐 이러한 페이지들이 종종 불일치하게 이름이 붙어서 찾기 어렵게 만든다는 것이다.만약 이렇게 한다면, 그들은 (헤더와 함께) 멋지게 주문될 수 있을 것이다.시작 - Alex Muller 18:05, 2009년 6월 2일 (UTC)[응답]

일반적인 생각으로는 마일리지가 좀 있는 것 같은데, 지원서는 작업이 필요할 것 같아.그것은 여기서 문제인 것 같다.사람들은 그것을 사용하기 위해 템플릿 사용법을 이해해야 할 것이고, 그것은 일반적인 혼란 페이지와는 다르다.예를 들어, 어떤 의미들은 그러한 TLAs이고 어떤 의미들은 그렇지 않다면 어떻게 될까?또한, 이 페이지들은 다른 혼란과 완전히 다르게 보일 것이고, 이것은 문제가 될 수 있다.{{{pagename}}}과 같이 표에 없는 것이 있다면, {{{pagename}}}}}은(는) 가능한 {{##{{ 연관}}}}에 대한 코드로서, 최소한 그 코드들은 작동하고 표준화 할 수 있다.소수의 리스트에서 주문하는 것은 우선순위가 아니다.하지만 일관성은 여전히 훼손될 것이다. - Jarry1250 18:18, 2009년 6월 2일 (UTC)[응답하라]

요점은 알겠지만, 다른 불분명한 페이지와의 일관성 문제는 제쳐두고라도, 나는 그 테이블 프레젠테이션이 소개 단어와 글머리 기호보다 훨씬 덜 도움이 된다는 것을 발견한다.아마도 기존의 레이아웃 내에서 적절한 구두점을 사용함으로써 상황이 개선될 수 있을 것이다.다음과 같은 것은 어떠세요?

KGX는 다음과 같을 수 있다.

• SIL 코드(술라웨시의 가마루어)
• FAA 식별자(알래스카 그레이링의 그레이링 공항)
• 역 코드(런던 킹스 크로스 역)

PL290 (대화) 21:50, 2009년 6월 2일 (UTC)[응답]

어떤 것이든 내가 하려던 것이었어 테이블이든 아니든...문제는 우리가 수천 명(수천 명)이 세 개의 편지 페이지 중 (잘 모르겠는데), 그리고 템플릿 같은 것이 그 페이지들 전체에서 빠르게 표준화 할 수 있는 가장 쉬운 방법이 될 것이다.지금 생각해보니, 아무래도 의 건의를 저기에 버려야 할 것 같다.{{IATA London Heathrow}}'런던 히드로의 IATA 코드' 같은 걸 돌려줄 거야내 생각에는 각 페이지에 동일한 표현(그리고 이상적으로 순서)을 사용하는 것이 긍정적인 것 같다 — Alex Muller 09:52, 2009년 6월 3일 (UTC)[응답]

나는 네가 옳다는 것을 의심하지 않는다.각 페이지에 동일한 표현(및 순서, 이상적)을 사용하는 것도 내 의견으로는 긍정적일 것이며, 이러한 유형의 모호한 페이지에는 두 개의 위키링크가 필요한 것으로 보여져 항목당 1개의 위키링크에서 벗어나는 것이 정당화될 수 있다는 점을 고려하면 더욱 그렇다.둘 이상의 위키링크의 존재에 의해 야기되는 혼란은 당신의 제안에 따라 완화될 다른 것이다. 왜냐하면 위키링크 쌍들은 한 쌍은 클래스("IATA 코드")이고 다른 한 쌍은 클래스("런던 히드로"의 예)라는 것을 전달하는 균일한 레이아웃에 있을 것이기 때문이다.나는 레이아웃에 관한 것 외에 다른 예약은 가지고 있지 않다. 만약 템플릿이 당신이 말한 대로 단순히 글머리 기호의 텍스트를 반환한다면 그것은 문제가 될 필요가 없다.PL290 (대화) 21:15, 2009년 6월 3일 (UTC)[응답]

나는 최근에 여기서 제안된 것의 정신에 맞는 비전통적인 dab 페이지를 몇 개 편집했다.나는 '공식 코드' 섹션에 있는 항목들을 간단히 접근하고 따로 떼어 놓았다. 이는 WP에서 제공하는 섹션화 지침과 일치하는 것으로 보인다.MOSDAB. OBO, ACV 및 YAI를 참조하십시오. --사용자:Ceyockey (Talk to me) 01:15, 2009년 6월 4일 (UTC)[응답하라]

{{}}}}에 아주 기본적인 템플릿을 조립했다.IATA}: 매개 변수에 추가하려는 페이지 이름 및 모든 정보를 포함.좀 더 템플릿적인 지식이나 아이디어를 가진 사람이 고칠 수 있지만, 내 생각엔 시작인 것 같아 — 알렉스 뮬러 08:04, 2009년 6월 6일 (UTC)[응답]

WP를 준수하려면 IATA에 대한 링크를 삭제(또는 조건부로 존재)해야 한다.MOSDAB. 템플릿 수정 완료. {{} 참조IATA}}. --사용자:Ceyockey (Talk to me) 2009년 6월 6일 16시 30분 (UTC)[응답하라]

IATA 코드를 [{{{1}}}]에 사용할 수 있다면, {{{2}}(적어도 도입부 '### is::)'보다 낫다고 생각한다.하지만 나는 지금 당신이 적어도 AWB나 비슷한 것을 사용해서 그러한 페이지의 대부분을 다루기를 바랄 수 있다고 가정한다면, 아마 (또는 손으로) 찬성한다.내가 여기서 어떤 표준화를 알지 못하는 경우를 제외하고 당신이 모든 소개를 어떻게 다룰지 잘 모르겠소?- Jarry1250^{(t, c)} 16:41, 2009년 6월 6일 (UTC)[응답]

[{{{1}}}],{{2}}: IATA 코드에서와 같이 실제 코드를 삭제하는 것에 동의하지 않음. 개인적으로 IATA 공항 코드 {{{3}}}, [{{1}}}],{{2}}}}}에 대한 IATA 코드에서와 같이 실제 코드를 삭제하는 것에 동의하지 않음.PL290 (대화) 17:55, 2009년 6월 6일 (UTC)[응답]

(Outdent), OK. 확실히 {{3}}}}은(는) {{PAGENAME}}}}? - Jarry1250^{(t, c)} 19:15, 2009년 6월 6일(UTC)[응답]

{{}}}의 코멘트에 납득이 갔다.IATA}, "페이지 제목이 "**** (해제)일 수도 있고, 실제 코드와 케이스나 구두점이 다를 수도 있기 때문에 실제 코드를 포함시킬 필요가 있다."PL290 (대화) 20:13, 2009년 6월 6일 (UTC)[응답]

매개변수 3(실제 코드)은 선택적 추가여야 한다.매개 변수 3이 제공되지 않은 경우 기본값인 {{PAGENAME}이(가) 될 수 있다.확실히, 이것은 몇몇 불량품들을 야기시키겠지만, 그것은 편리한 추가일 수도 있다.그러나 템플릿에 조건부 논리를 어떻게 도입해야 할지 잘 모르겠다.또한 매개변수 1과 2는 의무화되어야 하므로 둘 중 하나를 비워두면 오류가 발생된다. 다시 말하지만, 값 검증 논리를 템플릿에 삽입하는 방법을 잘 모르겠다. --사용자:Ceyockey (Talk to me) 01:57, 2009년 6월 7일 (UTC)[응답하라]

알았어, 조금 늦었지만, 이봐{{{NAME DEFAULTVALUE}}}}은(는) 해당 비트가 작동하는 방식이며, HTML을 사용할 경우 <span style="color:red">"ERROR: ROFT Parameters NOT</span>(수동 유효성 확인의 일종) 같은 것이었던 1과 2의 기본값을 설정할 수 있다고 생각한다.내 실패를 만회해 주길 바래. - Jarry1250^{(t, c)} 16:03, 2009년 6월 8일 (UTC)[응답]

네 의견을 읽기 전에 다른 두 개를 만들었어, 재리나는 돌아가서 세 가지 모두를 땜질해서 제안된 기본값을 사용할 것이다.새로운 기능:템플릿:ISO639 및 템플릿:FAALID. --사용자:Ceyockey (Talk to me) 03:05, 2009년 6월 13일 (UTC)[응답하라]

(Outdent) 사람들은 이 템플릿들을 초월하기 보다는 대체하자는 나의 제안에 대해 어떻게 생각하는가?하위 섹션의 요점은 이러한 템플릿은 형식 표준화 템플릿일 뿐이며 현재 dab 페이지에서 여러 형식이 사용 중이기 때문에 템플릿의 변경 사항은 실제로 전파할 필요가 없다는 것이다.또한 템플릿의 유틸리티(예: 빈 매개변수 값에 대한 허용 오차)에 대한 변경은 형식화된 텍스트에 영향을 미치지 않는다...전파될 필요도 없겠지의견을 보내줘서 고마워. --사용자:Ceyockey (Talk to me) 03:05, 2009년 6월 13일 (UTC)[응답하라]

선택적으로 각주 백링크 끄기

백링크는 유용한 정보를 제공할 수 있지만 목록과 같은 일부 기사 유형에서는 단일 각주의 백링크 수가 매우 많을 수 있으므로 기능이 유용하지 않을 수 있으며 각주 집합이 깔끔하지 않은 경우:

1. 작업 A, 페이지 210

2. 워크 B, 페이지 415

3. 워크 C, 페이지203

백링크 없이 각주를 렌더링할 수 있는 선택적 설정을 제안한다.

1. 작업 A, 페이지 210

2. 워크 B, 페이지 415

3. 워크 C, 페이지203

인용된 작업 수준(아마도 <ref name="myref" 백링크="false"), 개별 기준 수준(<ref name="myref" 백링크="false") 또는 reflist 수준(모든 백링크 해제) 중 하나 이상에서 이를 제어하는 것이 바람직할 수 있다.마지막은 내게 가장 유용할 것 같다.PL290 (대화) 08:58, 2009년 6월 5일 (UTC)[응답]

당신의 monobook.css에 있는 "ol.reference li a sup i b {display:none;}"이라는 프로-템플 솔루션으로 문자를 사용할 수 있다. - Jarry1250^{(t, c)} 09:10, 2009년 6월 5일 (UTC)[응답]

고마워; 하지만 여러분이 짐작했듯이, 이 제안은 단지 그들의 WP 경험을 사용자화할 수 있고 기꺼이 커스터마이징할 수 있는 일반 사용자들만이 아니라 새로운 사용자를 포함한 모든 사용자들에게 혜택을 주기 위한 것이다.PL290 (대화) 13:45, 2009년 6월 8일 (UTC)[응답]

이것이 문제가 되는 실제 기사의 예? --사이버코브라 (대화) 11:15, 2009년 6월 5일 (UTC)[응답]

나는 목록 기사가 예시보다 더 많이 참조를 재사용하는 것을 보았다.만약 참조가 그렇게 많이 재사용된다면, 나는 {{cref}}과 같은 대안을 제안한다.백링크를 생성하고 포맷하는 방법에 대한 자세한 내용은 도움말: 도움말을 참조하십시오.메시지 인용. ---— Gadget850 (Ed) 11:43, 2009년 6월 5일 (UTC)[응답]

{{cref}}}이(가) 찾고 있는 해결책이라고 설득하려 하지 않겠지만, 현재 내가 알고 있는 유일한 해결책이다.인용구를 이용한 해결책.php, 당신은 버그 리포트를 제출하고 개발자에게 당신의 개념의 타당성을 납득시켜야 할 것이다.

백링크: {{cref}}은(는) 백링크 없이 확실히 수정될 수 있는데, 이것이 유일한 수용 가능한 해결책인 것 같다.

자체 문서화:인용문의 다른 전체 인스턴스 없이 페이지 번호를 포함시키는 유일한 방법은 {{rp}}을(를) 사용하거나 단축 노트 시스템을 사용하는 것이다.다시 말하지만, 만약 이것이 받아들여질 수 없다면, 개발자 솔루션이 필요하다.

자동 번호 매기기:유효한 백링크가 없다면 번호 매기는 것은 오히려 엉망이 된다.나는 "a"로 시작하는 알파 문자를 사용하고 {{refbegin}}/{refend}}로 포맷된 참조 섹션에 {{cnote}를 포함시킨다.한 기사에 필요한 이 스타일에 대한 언급이 한 두 개만 있어야 한다.

---- Gadget850 (Ed) 17:02, 2009년 6월 8일 (UTC)[응답]

개발자 솔루션: 예, 내가 예상한 제안서를 만들었을 때.이 <ref>의 수정(혹은 정말로 반대)에 대해 우선 여기서 지지를 얻으려는 의도인데, 그 의향은 행복하게도 아직까지는 없는 것 같다.나는 사람들이 애초에 그 생각에 반대한다면 버그리포트를 하고 싶지 않다.

자동 번호 매기기: 제시된 시나리오(목록인 경우)에서 인라인 인용이 한 두 개 이상 있을 것이 분명하며, 내 의도는 (기사 텍스트에서) 그 순서대로 노트 1, 2, 3을 접하고 난 후에 독자가 노트 4 이전의 노트 84와 마주칠 것으로 예상하지 않는 것이다.따라서 위의 자동 번호 지정 참고에서 확인된 삽입 문제.

{{cref}}에 대해 알게 되어 기쁘지만, 이 어플리케이션은 아마도 아닐 것이고, 내가 선호하는 개발자 솔루션은 <ref>의 수정으로 남아 있다.PL290 (대화) 17:52, 2009년 6월 8일 (UTC)[응답]

"ref"가 백링크를 미친 듯이 많이 만들 수 있다는 이유만으로 현재 회피되고 있는 목록의 실제 예는 Talk:를 참조하십시오.리스트의 영국 왕위/아카이브 4#포맷에 대한 계승 순위. (물론 리스트 자체의 길이도 끊임없이 논의되고 있다.)—JAO • T • C 12:07, 2009년 6월 9일 (UTC)[응답]

• 나는 지금 이대로가 좋다.동일한 점이 몇 번 참조되었는지 확인하고 목록을 클릭하여 다양한 지점을 쉽게 찾을 수 있다. 드림 포커스 10:46, 2009년 6월 9일 (UTC)[응답]

백링크 레이블은 MediaWiki에서 정의된다.인용문 참조는 많은 형식 백링크 레이블을 링크한다.2006년 11월부터는 a에서 hz로 정의된 130개의 백링크가 있었다.2007년 3월에는 요청에 의해 lz(338)를 통해 정의되었고, 8월에는 zz(676)까지 정의되었다.이것은 300번 이상 링크를 재사용하는 편집자들이 있다는 것을 말해준다.이것은 어색하고, 추하고, 백링크가 쓸모 없게 된다.

{{cnote}}}}}}의 이슈를 살펴본 후 처음부터 {{scnote}}을(를) 사용했다.{{scref}}과(와) 함께 사용하면 백링크는 없지만, 겉모습과 느낌으로 참조를 정의할 수 있는 기능을 제공한다.<ref>...</ref>자동은 아니지만 몇 가지 문제를 해결한다.나는 이것을 주로 목록 기사에 사용하고 그 다음에는 아주 적은 수의 용도에만 사용할 것으로 예상한다.{{cref}}}의 많은 용도가 그룹 특성으로 대체될 수 있을 것 같다.<ref>...</ref>.

---- Gadget850 (Ed) 08:38, 2009년 6월 10일 (UTC)[응답]

여기에 투입된 작업에 감사드리며, {{scnote}}을(를) 한 번 살펴보도록 하겠다.나는 또한 그러한 것들이 어떻게 만들어지는가에 대해 내 스스로 더 많이 배우고 싶고 언젠가 그것을 추구하고 싶다.PL290 (대화) 10:17, 2009년 6월 10일 (UTC)[응답]

인용이 어떻게 되는지 보고 싶다면.php 참조가 함께 제공됨(도움말: 참조):메시지 인용 및 도움말:오류 인용. ---— Gadget850 (Ed) 11:08, 2009년 6월 10일 (UTC)[응답]

디프를 렌더링할 때 하이퍼링크 추가

컨텍스트: 디프를 볼 때 텍스트의 영향을 받는 영역이 왼쪽 창과 오른쪽 창에 나란히 표시된다.지금까지는 좋다.

제안: 오른쪽 창의 텍스트 영역에서 아래 문서 텍스트 내의 해당 위치로 원클릭 네비게이션이 가능하도록 디프렌더링에 하이퍼링크를 추가하십시오.PL290 (대화) 14:48, 2009년 6월 9일 (UTC)[응답]

바보같이 굴어서 미안한데 내가 따라갈지 모르겠어.텍스트 왼쪽에 하이퍼링크가 있어서 편집된 단락으로 이동한다는 말씀이세요?내가 추가한 단락 옆에 있는 링크를 클릭하면 #2항?그레그 타일러^{(t • c)} 21:40, 2009년 6월 9일 (UTC)[응답]

그렇다, 그것이 바로 내 말이다. 하지만 Drilnoth가 그것을 아래에 가지고 있는 것처럼, 왼쪽으로의 추가 링크가 아니라, diff의 아무 곳이나 클릭하는 것은 기사의 그 지점(그 섹션뿐만 아니라, 실제 텍스트 위치까지)으로 이동할 것이다. diff를 위한 기사의 특별한 렌더링에 추가 앵커들이 배치될 수 있다는 것을 기억하라.PL290 (대화) 10:08, 2009년 6월 10일 (UTC)[응답]

네!AWB는 이미 어떤 면에서 이것을 가지고 있다...이 경우, 디프의 아무 곳이나 클릭하면 편집 상자에서 클릭된 텍스트가 있는 위치로 자동으로 이동된다.이것은 편집 상자에서 적극적으로 하지 않을 때도 가능하다. –Drilnoth (T • C • L) 22:01, 2009년 6월 9일 (UTC)[응답]

편집 요약에 따라, 이것은 이미 존재하며, 섹션의 편집인 경우, "→" 텍스트는 섹션에 대한 링크다.
그러나 당신이 요구하는 것에 대한 이 불쌍한 사람의 방법은 임의의 단어 그룹을 복사하여 브라우저의 "찾기" 기능에 붙여넣는 것인데, 이 기능은 텍스트가 있는 페이지의 섹션으로 여러분을 데려다 줄 것이다(어떤 포맷이나 링크 코드도 복사하지 않는 한, 브라우저에 그런 식으로 표시되지 않을 것이기 때문이다).EVula// 통화 // / // 04:44, 2009년 6월 10일 (UTC)[응답]

그 불쌍한 남자의 버전이 그 제안이 개선하고자 하는 것이다!그러나 편집 요약에서 섹션 이름 앞에 있는 "→"는 내가 알아차리지 못했다. 고맙지만, 섹션의 크기를 조정할 수 있고 더 정확한 탐색이 개선될 수 있기 때문에 제안된 기능은 여전히 바람직하다.PL290 (대화) 10:08, 2009년 6월 10일 (UTC)[응답]

나는 이것에 대해 전문가는 아니지만, 내가 아는 한 페이지의 한 섹션에 "점프"하는 일반적인 방법은 그 섹션에 html로 지정된 ID가 있다는 것이다.예를 들어, 섹션은 이름이 지정된 것과 동일한 ID를 갖는다."점프 대상" 링크를 클릭하면 해당 ID를 가진 요소로 이동하도록 브라우저에 알린다.그러나, 이와 같은 것이 이미 구현되지 않는 한, 이것은 미디어위키 개발자들이 자동으로 ID를 얻기 위한 모든 텍스트 행을 만들어야 한다는 것을 의미한다.불가능한 것이 아니라, 예측하기 어렵고 일어날 것 같지 않다.하지만 내가 틀릴 수도 있다.이런 것들을 제대로 알고 있는 사람이 여기서 내가 한 말을 확인하거나 바로잡을 수 있다면 그것이 더 바람직할 것이다.Ose (토크) 22:39, 2009년 6월 11일 (UTC)[응답]

미디어위키에서 자바스크립트를 사용하면 실제로 이 작업을 수행할 수 있을 것이라고 생각한다.Common.js(즉, 모든 행의 ID가 필요하지 않음).좋은 코더만 찾으면 돼–Drilnoth (T • C • L) 23:27, 2009년 6월 11일 (UTC)[응답]

html에 대해서는, 예, 각 섹션 제목에 「이름 앵커」라고 하는 것을 배치한다.예를 들어, 이 섹션은 앵커 <a name="로 시작한다.add_extra_hyperlinks_when_rendering_diffs" id="Add_extra_hyperlinks_when_rendering_diffs"</a>.그것이 TOC나 다른 곳에서 그것을 항해할 수 있게 하는 것이다.내 생각은 이러한 앵커들이 디프트 아래에 있는 기사 버전에 더 많이 추가될 수 있다는 것이었다.반드시 한 줄에 한 개씩이 아니라, 아마도 디프가 차이를 표시한 각 지점에 한 개일 것이다.아니면 Drilnoth가 언급했듯이 자바스크립트 접근법이 더 나을 수도 있다.아마도 WP 소프트웨어에 좀 더 익숙한 사람이 논평할 수 있을 것이다.PL290 (대화) 2009년 6월 12일 11시 30분 (UTC)[응답]

WIKI를 더 난독시아로 만들기

현재 선호되는 선택사항은 WIKI의 난독증 방문자들의 요구에 부합하지 않는다. 실제 WIKI는 난독증을 위한 외계 환경으로 묘사될 수 있다. 난독증 증상의 많은 원인이다. 두 가지 주요 범주는 시각 및 청각 신경학적 정보 처리 문제들이다.대부분의 dyalexia freely werb 사이트들은 영국 Dyslexia Accossaition 웹사이트 http://www.bdadyslexia.org.uk/과 같은 전체 웹 페이지에 적어도 6가지 다른 배경 옵션을 제공한다는 표준 규약을 따르고 있다. 그들은 또한 글꼴 선택과 글꼴 색상 선택도 제공하지만, 그것은 현재 WIKI에게 너무 기술적일 수도 있다.이 모든 것에 대한 연구 근거는 http://www.dyslexiaservices.com.au/Six-Year_Follow-Up.htm에서 볼 수 있다.

난독증 증상을 유발할 수 있는 청각적 문제를 가진 사람들은 텍스트가 더 많은 간격을 두고 미리 배열되고 다색 글꼴을 사용하는 것을 선호한다. 다시 많은 사람들은 지금 기술적으로 너무 가능하지는 않지만 http://www.apduk.org/과 가이드 인덱스에 나타나는 선호 목록에 표시된 정보를 참조한다.http://capdlinks.homestead.com/Dyslexia.html을 방문하다.

위키 독자의 5-17%가 될 수 있는 난독증 방문자들에게 WIKi를 더 쉽게 접근할 수 있게 할 수 있기를 바란다.

나는 이것이 올바른 생각이었으면 좋겠다. 나는 내가 일탈증의 원인으로 청각 처리 장애를 가지고 있고 나는 위키에서 일하는 것이 스트레스를 주는 악몽이라고 생각한다.

dolfrog (토크) 2009년 6월 11일 (UTC) 15:47[응답]

위키피디아(등록된 사용자의 경우)에서는 선호도, 추가 기능 또는 사용자 정의 CSS를 통해 거의 모든 것을 변경할 수 있다.이걸 위해 고안된 걸 아는 사람?어쨌든, 위키피디아를 위키백과로 단축시키는 기본적인 죄악은 영원히 이루어져야 한다.기록을 위해.어떤 경우든 위와 같은 것을 바꿀 수 있는 방법은 얼마든지 있지만, 나는 그 유저들을 위해 특별히 아는 것은 없다.배경뿐만 아니라 사용자 지정 CSS를 사용하여 글꼴 간격, 글꼴 및 색상을 변경할 수 있다. - Jarry1250 16:25, 2009년 6월 11일(UTC)[응답]

위키피디아는 몇 가지 스킨을 제공한다. 하나는 당신에게 더 쉬울 수 있다.내 기본 설정 -> 스킨 아래를 보십시오.작은 작품으로도 자신만의 작품을 만들 수 있다.나는 이러한 우려들을 구체적으로 다룰 어떤 것도 모른다.위키피디아가 있다:위키프로젝트 사용성 및 위키백과:위키프로젝트 접근성(WikiProject Accessibility)은 도움이 될 수 있다.Rmhermen (대화) 2009년 6월 11일 (UTC) 16:28 [응답]

둘 다 안녕

위키피디아에 대한 당신의 신속한 답변에 대해 미안함을 느끼십시오.

나의 스킨 페이지에서 나는 다음의 ___________________________________

• Chick (Preview)(Custom CSS)(Custom JS)
• Classic(Preview)(Custom CSS)(Custom JS)
• 쾰른 블루(Preview)(Custom CSS)(Custom JS)
• 최신(사전 보기)(Custom CSS)(Custom JS)
• MonoBook(기본값)(Preview)(Custom CSS)(Custom JS)
• MySkin (Preview)(Custom CSS)(Custom JS)
• 향수(프리뷰)(Custom CSS)(Custom JS)
• 단순(사전 보기)(Custom CSS)(Custom JS)

__________________________

모든 CSS 및 JS 옵션은 빈 페이지로 이어지는 데드 레드 링크(Dead RED link)이다.내 우려는 내가 요구하는 옵션이 많은 비독성 난독증 옵션인 모노북 옵션처럼 비독성 난독증 옵션에서 선택할 수 있는 표준 옵션이어야 한다는 것이다.

그래서 나는 위에 언급된 기준을 준수하여 이러한 난독증이 모든 위키백과 경험의 배경을 설정할 수 있도록 6가지 더 많은 피부 옵션을 요청한다.

이제 네가 말한 프로젝트에 내 요청을 가져가겠다.

dolfrog (토크) 2009년 6월 11일 16:49 (UTC)[응답]

이 링크는 빨간색이어야 한다: 그것들은 개인화된 CSS 또는 JavaScript를 모든 페이지에서 실행할 수 있는 페이지로 연결된다.그것은 당신이 당신의 필요에 따라 사이트를 쉽고 완벽하게 사용자 정의할 수 있게 해준다.예를 들어 선택한 피부에 대해 "Custom CSS" 링크를 누르고 페이지에 다음 코드를 추가하는 경우:

#내용물, #mw_content { 말장난의:0.5em; } 

그러면 페이지 텍스트는 당신에게만 렌더링될 것이고, 오직 당신에게만, 단어 사이에 여분의 공간이 있을 것이며, 그것은 당신에게 유용할 것이다.이것은 사이트의 외관을 바꾸기 위해 수행될 수 있는 많은 일들의 한 예일 뿐이다: 언급했듯이, 사용적합성과 접근성 프로젝트는 다른 아이디어에 도움을 줄 수 있을 것이고, 그것들을 어떻게 가장 잘 구현할 수 있을 것인가.해피멜론 23:40, 2009년 6월 11일 (UTC)[응답]

다른 장애인을 위해 표준 스킨을 제공하는 것이 좋을 수 있다.시각장애인 사용자에게는 흰색 바탕에 검은색 글자가 큰 레이아웃이 유용할 수 있다. --Stephan Schulz (대화) 12:07, 2009년 6월 12일 (UTC)[응답]

나는 선호도에서 접근성 탭을 매우 선호한다.그러한 탭에서는 원하는 대로 최적화가 제공될 수 있다. rrzrr (talk) 23:46, 2009년 6월 12일 (UTC)[reply]

기성 편집자 협회

기성 편집자 협회는 일정 기간(예: 2년 이상) 동안 백과사전에 실질적이고 지속적인 기여를 한 일종의 조합이 될 것이다.제안된 정관들이 여기에 있다 - 제안을 환영한다.

관리자들은 그들이 입학 기준을 충족시키는 한, 그리고 그들이 다른 회원들을 지원하는 것을 포함한 협회의 핵심 목표에 전념하는 한, 가입하는 것을 매우 환영한다.

모든 후보 지명은 당분간 내가 맡겠지만 다른 후보 지명은 환영한다. 여기에 제공된 공간을 사용하여 자격이 있고 관심 있는 사람(자신을 포함할 수 있음)을 지명하십시오.공천이 충분하면 공천자 중에서 당선된다.

여기에 모든 논의를 넣으십시오.피터 데미안 (대화) 2009년 6월 13일 (UTC) 10:31 (답변)

콘텐트 알림판

위키피디아를 만들었다.상당히 확실한 합의로 보이는 내용에 따른 내용 공지 게시판. 배경 문맥은 여기를 참조하십시오.어떠한 제안이나 논평도 감사한다.–Juliancolton 19:11, 2009년 6월 13일 (UTC)[응답]

멋지다! 나도 한동안 그런 게 도움이 될 줄 알았는데, 공감대가 형성될지는 잘 모르겠어.–Drilnoth (T • C • L) 19:15, 2009년 6월 13일 (UTC)[응답]

왼쪽에 있는 3개의 상자와 동일한 유형의 상자로 Cancel(취소) 버튼을 표시하도록 제안

내가 처음 위키피디아를 사용했을 때(여러 마크업(mark-up)을 보는 것에 익숙하지 않으면 처음에는 압도적으로 혼란스러울 수 있다!)나는 실수로 취소 버튼을 자주 놓치곤 했고(찾을 수 없었고), 때로는 '저장 페이지'나 '시사보기 표시'를 대신 클릭하기도 했다!(그러면 취소해야 한다고 생각한다.솔직히 좀 흐리긴 하지만, 취소 버튼을 계속 놓친 건 알고 있다.)그래서 나는 취소 버튼이 '저장 페이지'와 '시사회보기 표시' 버튼처럼 눈에 띄면 도움이 될 수도 있다고 생각한다. 단지 현재 왼쪽에 있는 3개 박스와 같은 박스에 넣어두는 것만으로 말이다. (그리고 빨간색으로, 분홍색으로, 또는 다른 것으로 만들 수도 있다.)생각일 뿐이야.정말 고마워. (p.s. 위키피디아는 훌륭해!나 좋아해Go Wikipedia!)--Tyranny Sue (대화) 04:31, 2009년 4월 9일 (UTC)[응답하라]

버튼 하나 만드는 것도 나쁘지 않은 것 같은데, 색상을 다르게 해서...나도 몰라
브라우저에서 항상 "뒤로"를 누르거나 상단에 있는 "기사" 또는 "토론" 탭을 클릭할 수도 있다는 것을 명심하십시오.EVula// 통화 // / // 04:36, 2009년 4월 9일 (UTC)[응답]

4번째 버튼(페이지 저장/미리보기 표시/변경사항 표시/편집 취소)으로 만들고 공공 기물 파손으로 나타나는 실수로 신규 구매를 줄이는 것도 좋은 아이디어라고 생각한다.더 많은 청중이 토론할 수 있도록 광고할 수 있는 방법은 없을까? --64.85.214.183 (대화) 18:51, 2009년 4월 11일 (UTC)[응답]

좋은 생각이야, 색칠은 제쳐두고.Cancel은 다른 세 가지와 마찬가지로 동작이며, 대부분의 인터페이스에서 표준이다.–M^T 02:27, 2009년 4월 19일 (UTC)[응답]

이건 정말 좋은 생각인데, 왜 애초에 포함되지 않았을까?!사람들이 그것에 대해 논평한 바로 그 사실이 그 단순한 문제를 제기한다.게다가, 만약 사람들이 실수를 하고 그것을 바로잡지 않는다면, 그것은 다른 모든 사람들을 위해 더 많은 일을 만들어 낼 뿐이다!?제 생각에 가장 적절한 질문은...왜 단추가 되어야 하는지보다 왜 단추가 아닌지에 대해.

2009년 4월 24일 (UTC)[응답] 이 위키백과 위키 사용자 68 영국 포털 00:15에 대한 포스티브 액션을 봅시다.

• 화하다 지원 (토크, 컨트리) 2009년 4월 26일 (UTC) 17:27 [응답]
• 지원 — 버튼에 '취소'를 포함하면 편집(편집, 탭 => 요약 라인, 탭 탭 => 마이너 편집, 탭 탭 탭 탭 탭 탭 => 감시, 탭 탭 탭 탭 탭 탭 탭 탭 => 저장 등 편집 화면에서 작업으로 이동하는 데 사용하는 주요 방법이 탭핑을 통해 선택될 수 있다.이렇게 바로 가기 키를 사용하면 마우스로 작업 링크를 탐색하는 것보다 빠를 수 있다.마우스로 타이핑할 수 있을 때까지 키보드 단축키에 대한 애착을 유지할 것이다. --사용자:Ceyockey (Talk to me) 11:41, 2009년 5월 3일 (UTC)[응답하라]
• 지원, 위 참조.–M^T 04:30, 2009년 5월 5일 (UTC)[응답]
• 여전히 이 과정을 지켜보는 것에 관심이 있는 사람 - 다음 단계는 어떻게 해야 하는가?–M^T 22:23, 2009년 5월 9일 (UTC)[응답]
• HarryAlffa (대화) 17:57, 2009년 5월 11일 (UTC)[응답하라]
• 버튼 변경 지원; Nanowolf (토크) 07:48, 2009년 5월 14일 (UTC)[응답하라]
• 반대 이미 단추가 너무 많아. 편집 페이지가 좀 복잡해.게다가 취소 기능은 무용지물(적어도 나는 돌아가거나 탭을 닫는 것을 선호하기 때문에)이다.러슬릭 (대화) 18:28, 2009년 5월 16일 (UTC)[응답]

제안된 외관의 변화는 더 이상 공간을 차지하지 않을 것이기 때문에 페이지 넘기는 문제가 아니다.PL290 (대화) 20:42, 2009년 5월 16일 (UTC)[응답]

나는 동의하지 않는다; 사실 그 버튼은 현재 그곳에 존재하는 단순한 링크보다 더 많은 스크린 부동산을 차지할 것이다.러슬릭이 지적하듯이 페이지가 붐빈다.그러나 페이지의 복잡성(또는 인식된 혼잡성)은 단순히 얼마나 많은 것이 있는가의 함수가 아니라 그러한 것들이 어떻게 구성되는가 하는 것이다. 일관된 조직(예: 버튼이나 링크에 의해 제시되는 것이 아니라 버튼에 의해 제시되는 모든 페이지 수준의 기능)이 있다면 페이지가 압도되지 않고 더 많은 것을 추가할 수 있다.밍. --사용자:Ceyockey (Talk to me) 01:27, 2009년 5월 17일 (UTC)[응답하라]

그렇긴 하지만, 나는 그것을 나쁘게 표현했고, 적어도 내 생각에 페이지 넘기는 것은 제안서의 문제가 아니며 제안된 변경사항은 더 이상 공간을 차지하지 않을 것이라고 말했어야 했다.단추는 실제로 링크보다 약간 더 많은 공간을 차지하지만, 여러분이 주는 정확한 이유 때문에 페이지 넘치게 되는 것을 잠재적으로 줄일 수 있다.PL290 (대화) 13:33, 2009년 5월 17일 (UTC)[응답]

나는 이것을 반대하지도 지지하지도 않고, 단지 코멘트를 남길 뿐이다.Cancel이 수평이든 수직이든 더 많은 공간을 차지하는지에 상관없이, 그것은 페이지의 레이아웃에 전혀 영향을 미치지 않을 것이다.저장/미리보기/변경선 바로 아래의 테이블은 저장/미리보기/변경선 자체보다 넓다.따라서 링크 대신 버튼의 추가 픽셀을 차지함에도 불구하고 페이지 레이아웃은 본질적으로 변경되지 않을 것이다.해상도가 낮은 사용자라도 레이아웃을 크게 변경하지 않을 것이다(예: 버튼 행을 새 선으로 감싼다).사용된 추가적인 수평 공간은 약 20픽셀 이하일 것이며(나는 가지 않고 정확하게 알아냈다), 위에서 언급했듯이 그 아래의 테이블(Insert, 특수문자에 대한 핫링크, 페이지 서명 알림, 인용 소스)은 이미 버튼이 달린 선보다 훨씬 넓다.푸지온 (대화) 08:12, 2009년 5월 23일 (UTC)[응답]

내 코멘트 추가:텍스트 기반 브라우저 링크는 다음 형식으로 단추를 포맷한다: [버튼 제목 ] 링크는 대체 색상으로 표시된다.이 작업에는 수평 공간(4자)이 추가로 필요하지만, 앞서 말했듯이 아래 테이블은 여전히 넓다.푸지온 (대화) 08:16, 2009년 5월 23일 (UTC)[응답]

• 지지대(색상 제외)—취소는 다른 세 개와 동일한 외관을 가진 버튼이어야 하며, 이를 현재 편집에 적용할 수 있는 작업으로 시각적으로 그룹화해야 한다.PL290 (대화) 20:42, 2009년 5월 16일 (UTC)[응답]
• 지원 취소 버튼이 있는 줄도 몰랐다(내 브라우저의 "뒤로" 버튼만 누르는 데 사용됨).YOWUZA Talk 2 me! 2009년 5월 25일 18:16, 25 (UTC)[응답하라]
• 반대 – 나는 Yowuza가 지지한 것과 같은 이유로 반대할 것이다.그는 "(내 브라우저의 '뒤로' 버튼만 누르는 데 사용되는) 취소 버튼이 있는 줄도 몰랐다"고 말했다.바로 그거야!나는 1년 이상 위키피디아에서 그 버튼을 누른 적이 없었고, 아마 6개월 동안 ( 위키피디아 인터페이스 이해에 관한 한) 신입생이었습니다.버튼은 쓸모가 없으니 확장보다는 아예 삭제하는 게 낫겠다.단추를 크게 만드는 것은 잡동사니만 확장시킬 뿐 진정으로 아무에게도 도움이 되지 않을 것이다.그 제안은 10대 5 정도의 투표에 근거하여 실행되지 않는 것이 좋다.아메리칸 이글 (토크) 06:06, 2009년 5월 31일 (UTC)[응답]
• 취소 버튼이 있는 줄도 몰랐는데...–Juliancolton 06:09, 2009년 5월 31일 (UTC)[응답]
• 반대: 취소 버튼은 다른 세 버튼만큼 중요하지 않으며, 브라우저가 당신이 추가한 내용을 브라우저에 보관하지 않는다면(IE는 그렇지 않을 수도 있다고 생각한다), 그러면 큰 버튼 하나만 더 있으면 혼란에 더 쉽게 대처할 수 있을 것이다...실수로 취소를 하면 새로운 콘텐츠가 많이 손실될 수 있다.뒤로 버튼은 페이지를 스크롤하여 다시 "기사"를 클릭하기만 하면 되는 것처럼 쉽게 사용할 수 있고 허용될 수 있다.–Drilnoth (T • C • L) 15:05, 2009년 6월 1일 (UTC)[응답]
• 관찰 re. 중요도/취소 버튼의 이전: 일부(많은)를 잊지 마십시오.아마도 어느 정도 컴퓨터 지식이 부족하지만 웹의 작동 방식에 대한 지식이 부족한 사용자들은, 일단 편집을 시작하면, 일단 편집을 시작하더라도, 그들이 그것을 포기하더라도, 그들이 취소를 눌러 위키피디아를 "말해야" 한다고 상당히 합리적으로 가정할 수 있다.그것이 UI가 초대하는 유일한 취소 방법이다.설사 다른 가능성이 있다는 생각이 들더라도, 사람들은 어떤 대안이든 편집이 활성화되어 다른 사람들이 기사를 편집하는 것을 방해할 수 있다고 상당히 합리적으로 생각할 수 있다.뒤로 단추를 누르는 것은 일반적으로 대화형 프로세스를 시작한 후 사용할 경우 일부 웹 사이트에서 문제를 일으킬 수 있는 것으로 알려져 있다.편집 중에 [뒤로] 단추를 누르는 것이 반드시 사용자에게 발생하거나 자신이나 다른 사람에게 문제를 일으킬 수 있는 경우 사용자가 원하는 것이 아닐 수 있다.중요한 숫자일 수 있는 그러한 사람들에게 취소 버튼은 중요하며, 편집 중에 적용되는 다른 "액션" 버튼과 함께 시각적으로 그룹화한다면 도움이 될 것이다.PL290 (대화) 09:30, 2009년 6월 2일 (UTC)[응답]
  • 관찰에 대한 언급:나는 결국 어느 것도 하지 않고 '기사'나 '프로젝트' 또는 '토론' 탭만 두드린다(그런데, '취소' 버튼이 지워지기를 기다리는 것보다 더 빨리 작동하는 것 같다).그러나 그것은 분명히 끝없는 개인적 변동에 따르는 기발한 일 중의 하나이다.—— Shakescene (대화) 05:43, 2009년 6월 9일 (UTC)[응답]
• 나는 줄리안콜튼과 PL290에 동의한다.나는 보통 이 변화를 지지한다; 나의 유일한 관심사는 잘못된 버튼 클릭으로 인해 합법적인 편집이 손실될 수 있다는 것이다.적어도 지금과 같이 "취소"는 다른 버튼과 섞이지 않는다.파워스 13:23, 2009년 6월 2일 (UTC)[응답]

이것은 내가 표현했던 것과 동의하지만, 잘못된 버튼을 클릭하는 것에 대한 한 가지 유보적인 입장을 가지고, 버튼이 아닌 현재의 모습이 실수로 클릭할 가능성을 줄인다고 느끼는 근거에 대해 내가 집요하게 질문할 수 있을까?고려해 보십시오: 일반적인 OK/Cancel 또는 Yes/No 대화상자에서 사용자는 유사한 모양의 두 개의 버튼을 표시하는데, 이러한 버튼이 시각적으로 그룹화되어 사용 가능한 선택사항의 합을 형성하기 때문이다(예/아니오/취소처럼 버튼이 두 개 이상 있는 경우).사용자는 버튼 중 하나에 다른 모양을 부여하여 도움을 받거나, 시각적 일관성으로 인해 실수로 잘못된 버튼을 선택할 위험이 더 큰 것으로 추정되지 않는다.이러한 용어로 볼 때, 실제로 여기서 논의되고 있는 UI의 어떤 측면이 이 원칙을 더 덜 적용할 수 있게 하는가?PL290 (대화) 20:04, 2009년 6월 2일 (UTC)[응답]

내가 "취소"와 "도움말 편집"에 인접한 두 링크를 사용하는 드문 경우, 나는 다른 링크를 원할 때 한 링크를 한 번 이상 친 적이 있다.전면적인 '취소' 버튼을 분홍색, 주황색 또는 빨간색으로 색칠하거나, '취소'를 모든 문자에 넣거나, 볼드 페이스나 이탤릭체로 강조해도 확실히 나쁠 것은 없을 것이다.다른 세 개의 버튼과의 혼동 가능성은 "도움말 편집"으로 인한 혼동을 줄임으로써 다소 완화된다.—— Shakescene (대화) 05:43, 2009년 6월 9일 (UTC)[응답]

• 반대 - 브라우저의 뒤로 단추를 사용하는 방법만 배우십시오. 드림 포커스 09:33, 2009년 6월 6일 (UTC)[응답]
• 반대 나는 그것이 득보다 실이 많을 것이라고 생각한다; 취소 버튼을 다른 사람들 옆에 두면 실수로 클릭하는 것이 훨씬 더 쉽다.소퍼스 비 08:25, 2009년 6월 10일 (UTC)[응답]

지원 니터, 좀 더 논리적으로. --로빈슨웨이즈먼 (토크) 18:41, 2009년 6월 11일 (UTC)[응답]

• 지지하다.나는 항상 그것이 왜 단추가 아닌지 궁금했다.편집 뷰가 추가 버튼에 비해 너무 "클라우드"가 되지는 않을 겁니다.어쨌든, 취소 작업은 "도움말 편집"이 아니라, 저장, 미리보기 및 변경사항 표시와 같은 그룹에 논리적으로 속해 있다.후자와 결합하는 것은 단지 잘못된 UI 설계일 뿐이다.자펠루브 (대화) 2009년 6월 14일 (UTC) 16:54 [응답]
• 코멘트 CSS와의 쓸모없는 버튼/링크를 여전히 숨길 수 있는 한, 나는 상관하지 않는다.아노미에 17:27, 2009년 6월 14일 (UTC)[응답]

전체 "성적 이미지 검열" 영원한 커플플을 해결하기 위한 제안

나는 내가 어카운트로는 비교적 새로운 위키피디아 사람이라는 것을 알고 있지만, 비록 내가 그렇게까지 거슬러 올라가면 이름이나 링크를 제공하고 싶지는 않지만, 나는 그것이 모두 관련이 있다고 생각하지 않기 때문에, 2004년 이후로 다양한 이름과 IP로 이 근처에 있었다는 것을 명심해줘.난 그저 내가 어떤 무작위적인 학교 선생님이 아니라는 것을 보여주기 위해 이런 말을 하는 거야.

그것은 다음과 같다.성적, 그래픽 또는 고도로 의학적인 이미지를 그들의 이미지 페이지에 경고 태그가 붙고 (기사에 지장을 주지 않도록) 위키백과 1면에 "그래픽 이미지 없이 위키백과를 탐색한다"는 명백한 링크가 있는 시스템의 어떤 것이 그러한 태그로 이미지를 차단하기 위해 사용자의 브라우저에 쿠키를 설정할 수 있는 "그래픽 이미지 없이 위키백과를 탐색한다."이렇게 할 수 있을까?나는 WP가 다음 사항을 알고 있다.검열된 것은 아니지만, 이것은 검열보다는 위키백과 소프트웨어에 의해서만 촉진된, 성적인 이미지를 차단하기 위해 사용자가 할 수 있는 어떤 자발적인 방법과 더 흡사하다.내가 볼 수 있는 한 가지 잠재적인 문제는 학교나 가족용 컴퓨터 같은 것을 제거하지 않고는 어떻게 그것이 실행될 수 있을 지 잘 모른다는 것이다. 학생과 아이들이 쉽게 그것을 끌 수 있을 것 같다.만약 이 아이디어가 마음에 든다면, 나보다 더 밝은 사람이 그 문제를 해결할 수 있는 아이디어를 가질 수 있을 텐데...?

--Lesath2 (대화) 16:33, 2009년 5월 26일 (UTC)[응답]

문제는 누군가가 악의적으로 경고를 쉽게 추가/제거할 수 있다는 것이다.그래도 좋은 생각이야.YOWUZA Talk 2 me! 16:38, 2009년 5월 26일 (UTC)[응답]

WP:DISClaim.이것은 꽤 오래 지속되는 제안이다.♫ 멜로디아 샤콘네 ♫ (토크) 17:06, 2009년 5월 26일 (UTC)[응답하라]

문제는 언제나 그렇듯이, 이런 방식으로 어떤 콘텐츠를 처리해야 할지 어떻게 결정할 것인가 하는 것이다.위키피디아를 읽고 있는 많은 그룹들이 성적으로 외적인 이미지들이 모하메드/이미지/등등과 비교했을 때 사소한 문제라고 생각한다.그런 미디어를 위해 비슷한 시스템을 구축해야 할까?만약 그렇다면, 어떻게 임의의 콘텐츠에 대한 접근을 통제하는 책임을 회피할 수 있을까?그것은 제로, 원, 무한의 논쟁이다: 상황을 통제하는 유일한 방법은 제로 포지션을 채택하는 것이다: 우리는 어떤 이유로든, 우리의 편집 정책 외에는 어떤 내용도 검열하지 않는다.그렇게 하면 아무도 "X의 이미지를 볼 수 있는 버튼은 있지만 Y의 이미지를 볼 수 없는 버튼"이라고 말할 수 없으며, 마찬가지로 "이 버튼을 클릭하면 X의 이미지를 숨길 수 있다고 말했는데, 그렇지 않아, 나는 지금 화가 나 있다"고 말하는 것을 피할 수 있다.이것이 유일하게 실행 가능한 입장이다.해피멜론 17:19, 2009년 5월 26일 (UTC)[응답]

아니 그렇지 않다.우리는 콘텐츠 제어 시스템에 대해 거부권을 줄 수 있고, 그리고 나서 사람들이 원하는 버튼이 무엇이든지 간에 단추를 줄 수 있다.디폴트는 모든 것을 보여주지만(확실히 - WPNOTCENSORED), 사람들이 성적인 이미지, 나체, 모하메드 만화 또는 스페이드 사진을 숨길 수 있게 해준다.(일반적으로 결함이 있는 지저분한 WP 방식으로) 어떤 종류의 콘텐츠 분류를 가지고 사용자가 보고 싶은 것을 선택할 수 있도록 하는 것은 어떨까?Rd232 17:33, 2009년 5월 26일 (UTC)[응답]

만약 누군가가 마호메트를 차단하기 위해 개인 필터를 설치하고 싶다면, 나는 이것에 대해 아무런 문제가 없다.하지만, 문제가 되는 것은, 만약 우리가 이런 자발적인 필터를 만드는 것을 돕는다면, 검열되어서는 안 되는 다른 종류의 컨텐츠에 대한 자발적인 필터를 만드는 것을 사람들이 돕게 될 것이라는 점이다.대안으로는 학교 이사회에 부적절한 구체적인 이미지의 목록화를 요청하고 이를 직접 차단하는 것이다.하지만, 어떤 것도 아이가 본질적으로 성교육 정보를 얻는 것을 방해해서는 안 되기 때문에, 나는 이것이 좋은 생각인지 의심스럽다. M 17:32, 2009년 5월 26일 (UTC)[응답하라]

만약 우리가 학교에 400만개 이상의 모든 공유 이미지 목록을 주고 그들이 숨기고 싶은 이미지를 골라달라고 한다면, 그들은 아마 웃기만 할 것이다.그들이 키워드 기반 웹 필터링 소프트웨어로 덜 정밀한 필터링을 하거나 위키피디아를 완전히 차단하는 것이 훨씬 쉽다.Mr.Z-man 17:58, 2009년 5월 26일 (UTC)[응답]

이 선의의 제안에는 몇 가지 문제가 있다.

1. 불행하게도 Rd232가 시사하는 바와 같이, 우리가 특정한 종류의 콘텐츠를 필터링하기 위한 첫 단계를 밟는다면, 그러한 종류의 콘텐츠의 한 예가 여과되지 않으면 우리는 책임을 지게 된다.만약 우리가 "여기, 명시적인 이미지 없이 위키피디아를 찾아봐"라고 말하고 페니스 사진이 작은 조니의 컴퓨터에 몰래 들어간다면, 우리는 큰 문제를 가지고 있다.지금과 같이, 우리는 "위키피디아에는 노골적인 이미지가 있다; 미안!"라고 말할 수 있고, 우리의 필터가 밀폐되어 있는지 여부에 대해서는 걱정하지 않아도 된다.
2. 그리고 정확히 무엇이 "그래픽"으로 계산되는지를 결정하는 문제가 있다.우리는 위키피디아에서 항상 컨텐츠에 근거한 구별을 하지만, 나는 우리가 결코 필요로 하지 않는 것은 다른 종류의 구별이라고 생각한다.파일:Gray1166.png 그래픽?파일:그레이406.png?파일:Hemisected Man and Woman Luc Viatour.jpg의 Da Vinci Coition?일러스트니까 괜찮지?그렇다면 파일:CSC Herme Saudate-a-Thon 로고 Original for Wiki.jpg?얼마나 힘든지 알겠지?누가 이런 결정을 내리는가?
3. 왜 이미지로 멈추는가?그래픽 텍스트는?또는 필터링할 사진이나 텍스트가 있는 사이트 링크도 위키피디아에 있었다.Wikiquote는 어때?사데 후작님?
4. 해피멜론이 지적했듯이 얼마나 많은 필터를 만들어야 할까?동성애에 관한 정보에 대한 접근을 차단하는 것을 만들어야 할까?사도 마조히즘에 대해서?나치 이미지에 대해서? (독일 정부는 그것을 좋아할 것이다.)만약 그렇지 않다면, 무엇이 나체와 노골적인 성적 이미지를 타겟으로 삼지만 나치즘은 아닌 것일까?

미안하지만, 이 길로 들어서면 질문이 너무 많아.우리는 쓸 백과사전이 있다.파워스^T 19:04, 2009년 5월 26일 (UTC)[응답]

나는 그 모든 것들이 언급될 수 있다고 생각한다.예를 들어, 1은 쉽게 할인된다(우리가 신경 쓰지 않을 때 면책 조항이 충분하다면, 우리가 노력하지만 때때로 실패하는 경우에 대한 면책 조항은 확실히 충분하다.2. 우리는 항상 똑같이 어려운 결정을 내린다(예: 신뢰할 수 있는 출처로서 중요한 것).3.과 4. 이미지의 등급 분류를 검열과 같은 법정에 세우려는 상당히 터무니없는 FUD의 시도다. 다른 모든 것과 마찬가지로, 우리는 협력적인 WP 과정에서 합리적인 무언가가 나온다고 믿어야 할 것이다. (그리고 만약 그렇지 않다면, 특별히 결과를 보겠다고 선택한 사람들만)그 모든 것은, 나는 그러한 시스템을 만들거나 사용하는 것에 관심이 없다; 나는 단지 그것이 본질적으로 실행 불가능하다고 생각하지 않는다.Rd232^talk 21:24, 2009년 5월 26일 (UTC)[응답]

1호를 너무 쉽게 무시하는 것 같아.비논리적으로 들리지만, 적어도 PR의 관점에서 시도하고 때로는 실패하는 것이 전혀 시도하지 않는 것보다 더 나쁜 경우가 많다는 것은 사실이다.둘째로, 그래, 우리는 항상 똑같이 어려운 결정을 내리지만, 나는 다른 범주의 어려운 결정을 더하는 경우를 보지 않는다. 그리고 이 경우 특히 논쟁의 여지가 있는 결정을 우리의 권한에 추가한다.나는 FUD의 비난에 감사하지 않는다; 3과 4는 우리가 만족스럽게 그려야 할 더 많은 행의 예처럼 의도된 것이 아니다. 4는 또한 매우 관련 있는 질문을 제기한다. 왜 성적인 내용이지 다른 종류의 잠재적으로 반대할 만한 내용이 아닌가?왜 성적인 내용이 필터링 후보자로 불려 나오느냐고 묻는 것은 FUD가 아니다.파워스^T 13:40, 2009년 5월 27일 (UTC)[응답]

오케이, 미안, "FUD"가 너무 무시적으로 나왔어.Rd232 16:48, 2009년 5월 27일 (UTC)[응답]

• 우리는 이 문제를 웹 필터 제공자와 같은 다른 사람들에게 맡길 필요가 있다.관계 있는 부모나 학교 등은 그 제품들을 사용하여 아이들이 어떤 콘텐츠를 이용할 수 있는지 통제할 수 있으며, 위키백과보다 훨씬 더 잘 할 것이라고 확신한다.우리는 세계적인 백과사전이기 때문에 어떤 특정한 문화에서 무엇이 불쾌한지 결정해서는 안 된다. 예를 들어, 한 나라에서는 두 번째 유두가 쪼개지는 것이 국가적 추문을 일으킬 만큼 모욕적인 것으로 여겨지지만, 나머지 서양 세계에서는 이해가 안 되는 듯 웃기만 한다.필 브리저 (대화) 21:48, 2009년 5월 28일 (UTC)[응답]

특정 페이지를 "사무실이 안전하지 않음"으로 표시하는 일부 유형의 숨겨진 필터 플래그(또는 여러 개의 플래그)를 사용하면 감사할 것이다.그렇게 하면 나는 WP를 검색하는 동안 동료의 기분을 상하게 하는 임의의 페이지를 우연히 선택하지 않도록 내 계정을 사용자 정의할 수 있다.관리자만이 깃발을 수정할 수 있도록 구성해야 한다면, 나는 그것으로 살아갈 수 있다.고마워요.—RJH (대화) 18:24, 2009년 5월 30일 (UTC)[응답]

큰 문제는 일부 사람들이 사물을 불쾌하게 생각하느냐 마느냐 하는 것이다.만약 당신이 오토펠라티오 이미지에 태그를 달았다면, 누군가가, 전적으로 선의로, 그것을 제거할 수 있을 것이다.아니면, 만약 당신이 모하메드의 사진이 전시되는 것을 원하지 않는 정통 이슬람교도라면?우리는 그 토론을 구역질나게 했다.아니면 여성의 얼굴 이미지가 불쾌하다고 생각하는 정통 이슬람교도는 어떨까.그들은 여성 맨얼굴의 모든 이미지들을 불쾌하게 할 수도 있고, 그러면 누가 그것을 제거할 권리를 가질 수 있을까?그 당시 신사는 누구였습니까?(토크) 2009년 5월 31일 (UTC) 18:59, 31 (응답)

맞아. RJH, 문제는 우리는 무엇이 당신의 동료들을 불쾌하게 할지 모른다는 것이고, 모든 동료들의 동료들은 다르다는 거야.파워스^T 13:50, 2009년 6월 4일 (UTC)[응답]

바로 그거야—Apis (대화) 15:04, 2009년 6월 11일 (UTC)[응답]

나는 많은 사용자들이 "성적 이미지"에 대해 전혀 문제를 가지고 있지 않지만, 그 이미지들의 질이 떨어지고, 의도적인 것이 있을 수 있다고 생각한다.나는 '인간 항문' 기사에 적절한 전문 의료 사진이나 다른 인간 항문 묘사가 있는 것에 대해 강한 이의가 없다.난 전시작가가 자기 항문 사진을 제대로 찍지 못하는 게 문제야 수천 명의 낯선 사람들이 자기 똥꼬를 보길 원하거든출처가 업로더인 논란의 '성적 이미지'를 금지하는 것이 바람직하다고 생각한다.—98.155.16.174 (대화 • 기여) 05:25, 2009년 6월 9일 서명되지 않은 논평 준비

그건 별개의 문제다(그러나 논란의 여지가 있는 이미지를 분류할 때도 같은 문제로 이어질 것이다).그런 전시주의 사진들이 있다면 문제가 해당 기사의 토크페이지에서 풀릴 수 있기 때문에 별도의 규정이 필요하지 않다고 생각할 것이다.
—Apis (대화) 2009년 6월 11일 (UTC) 14:55 [응답]

그것은 사람들 WP에 달려있다.기사 소유: 때로는 WP의 마지막 단락에도 불구하고 이미지를 이동하거나 제거하려는 시도가 "검열"이라고 주장할 그룹에 의해 기사가 인계된다.감시를 받지 않았다.Anomie⚔ 20:40, 2009년 6월 11일 (UTC)[응답]

이것은 몇 가지 다른 형태로 제안되었다.나는 우리가 자기 검열 여부를 놓고 의견 일치를 보지 못할 것이며, 특정 영상이나 기사의 분류에 대한 합의도 없을 것으로 본다.나는 우리가 위키피디아 내에서 할 수 있거나 해야 할 최선의 방법은 독자들이 그들의 개인적인 시청 환경을 검열할 수 있는 기술적 정보를 제공하는 것이라고 생각한다.우리는 무함마드와 같은 기사에 대해 이 정보를 어느 정도 제공한다.

만약 누군가가 위키백과 외의 프로젝트로 기사와 이미지의 목록을 만들고 싶다면 나는 반대하지 않을 것이다.

---- Gadget850 (Ed) 20:56, 2009년 6월 11일 (UTC)[응답]

위키백과:Everything_proposals#Censor_officious_images -- SEEIlco (talk) 18:28, 2009년 6월 14일 (UTC)[응답]

위키백과로 서핑 경험을 향상시키기 위한 제안

여기서 3가지 제안을 하고 싶다.

1위, 주로 > "자연과 우주 탐험" , 그리고 "그린피스, 환경, > 서식지, 동물"에 관한 주제 2개를 추가했다.

현재 포털은 "해당"과 "해당"에 대한 포털을 포함하고 있지만, 그것을 읽거나 참조하는 사람이 알아야 하거나 읽고 싶어할 만한 것이 많이 부족하다고 생각한다. 또한, 여기의 사이드 코멘트는, 내가 맞다면 메인 사이트를 통해서만 접속할 수 있다는 것이다.즉, 만약 내가 위키 단어 "planets"와 같은 다른 페이지에 있다면, 나는 천문학에 대한 이 포털이 있다는 것을 보거나 알 수 없을 것이다.

두 번째, > 또한, 「실력」이나 「과학」과 같은 특정 주제에 대해 모든 키워드 / > 보컬 / 개념을 나열한 페이지가 있으면 좋을 것이다.>>예를 들어"천문학과 공간>탐사", 을 위한 페이지 목록 keywords/voca/concept.(예를 들어"는 천문학은 그 목록 항목은 제외한 반면 다양한 주제들을 열거하고 천문학 주제 목록(http://en.wikipedia.org/wiki/List_of_basic_astronomy_topics)의 제안 목록."astronomy을 좋아하고.우주 explora"tion"은 키워드/공명/보카에 의한 것이다. 이 추가 페이지는 이미 존재하는 "천문학 주제 목록"을 시행하고 강화시킬 것이다. (http://en.wikipedia.org/wiki/List_of_basic_astronomy_topics) 그리고 여기에 더 많은 완전한 그림을 추가한다.> 그리고 이 "수집 페이지"에서 천문학과 관련된 핵심 단어와 > 보컬의 목록을 볼 수 있을 것이다.>

3번째 > 그리고 그 키워드 '페이지(예: 키워드' 페이지 ->>><http://en.wikipedia.org/wiki/Planet)이 <큰 도움이 된다>>라는 키워드 하단에 덧붙인 그 "리스트 페이지"에 대한 링크를 갖는 것이 가장 도움이 될 것이다.>그것은 단지 제안일 뿐이지만 대부분의 사용자에게 유용한 것이 될 것이라고 믿는다.

• 나는 "포털"이 당신이 언급하고 있는 것인지는 모르지만, 포털이라고 불리는 몇몇 위키피디아 것들은 편집될 수 있다.당신이 기술한 것 중 일부는 카테고리를 통해 제공된다; 그러한 것들은 기사 하단을 보고 카테고리 목록을 찾아보고 하나를 클릭하면 된다. -- SEEILCO (토크) 18:34, 2009년 6월 14일 (UTC)[응답]

삭제된 아티클 알림 기능 '히트 수'

최근에 세 번 정도 나는 위키피디아에 와서 꽤 사소한 것을 찾아보다가 삭제된 글에서 나를 발견했다.나는 이런 일이 많은 사람들에게 반드시 일어나야 한다고 확신한다. 그리고 때로는 삭제된 어떤 것에 대한 공신력이 시간이 지남에 따라 올라가기도 한다. 하지만 당신은 이전에 삭제된 페이지에 와서 페이지를 다시 시작하거나 그 어떤 것을 다시 시작할 정도로 충분히 신경 쓰지 않는다.

편집자/사용자가 어떻게 해서든 그런 기사를 찾아왔다고 딱지를 붙이는 것이 가능할까, 그래서 그것이 좀 주목할 만한 것일 수도 있고, 그들은 그것이 그대로 있기를 바란다.그러면 삭제된 상위 기사 목록이 자동으로 생성될 수 있으며 관리자가 삭제하지 않은 경우 사례별로 고려할 수 있는가?

이것은 또한 삭제주의자와 포섭주의자들 사이의 긴장을 다소 완화시킬 수도 있다.--Jaymax (토크) 01:25, 2009년 6월 12일 (UTC)[응답]

두 사람(또는 많은 사람들이)이 죽은 링크를 클릭하는 것은 공신력이나 공신력에 가까운 어떤 것을 구성하지 않는다.WP에 추가할 버튼을 추가하는 것 같네.RA나 그 비슷한 것.이렇게 하면 WP에 많은 스팸 항목이 생성될 것이다.RA (또는 당신이 제안하는 것은 무엇이든) 1. 삭제된 기사를 작성한 사람들, 아마도 COI 편집자들, 2. 경험 없는 위키백과 사용자들은 "여기를 클릭하라..." 버튼을 보고 버튼이 어떻게 되든 클릭할 것이고, 3. 더 많은 COI 편집자들이 있다.[불꽃변호사] 01:54, 2009년 6월 12일 (UTC)[응답]

나는 위키피디아에서 삭제된 페이지까지 높은 빈도에 도달하는 사람들이 (증거를 말하지 않는) 불명의 지표가 아니라는 것에 대해 (어떤 것은 강하게) 동의하지 않는다.예를 들어, 만약 어떤 것이 외부 언론의 취재를 받는다면, 그 공신력의 증가는 히트곡의 증가와 상당히 상관관계가 있을 것이다.)사려 깊은 분석을 통해 제안된 메커니즘이 COI 편집기의 영향력에 상당히 영향을 미치지 않아야 한다는 것을 밝혀낼 수 있다(여러 개의 다른 IP(즉,: sockpuppet)에서 자동 요청하기 위해 스크립트를 실행하지 않는 한), 각 개인의 '히트'는 RP로 보여서는 안 된다.RA

사실, 나는 그것을 한 단계 더 깊이 받아들일 것이다 - 만약 검색이 삭제된 기사 제목과 일치한다면, 마찬가지로 '히트'로 간주될 것이다 - 이것은 사실 '버튼'보다 훨씬 더 의미 있는 것이다.요점은 수많은 요청을 생성하는 것이 아니라, 이전에 삭제된 중요한 기사들을 공개하는 것인데, 현재 많은 수요가 있는 기사들을 관리자 불삭제에 대한 고려를 위해 말이다.--Jaymax (토크) 08:51, 2009년 6월 12일 (UTC)[응답]

페이지 적중 자동 카운터를 추가하고 특정 대상이 적중(x in n weeks, like)되면 적절한 페이지에 적어두는 것이 어떨까?rrzrr (talk) 23:35, 2009년 6월 12일(UTC)[응답]

얼마나 높은 목표물을 보고 있을 것인가?Horse cock의 레드링크는 우리가 리디렉션을 처리할 수 있는지 알아보는 사람들로부터 매달 100회 정도의 히트를 얻어내는 반면, Big tits와 Big Pussy의 리디렉션은 모두 매달 2,000회 이상 올라가고 있다.– 무지개빛 00:01, 2009년 6월 13일 (UTC)[응답]

자동 카운터에 의해 생성된 노트(지정된 대상에 도달했을 때)에 추가 조치를 라우팅하기 위해 [로 이동], [논의], [지금부터 무시] 등의 링크가 포함된다면, 위에서 언급한 것과 같은 킥킥-시어치의 대부분은 빠르게 걸러질 것이다.rrzrr (talk) 16:12, 2009년 6월 13일 (UTC)[응답]

일부 경우에는 관리자가 내용을 삭제하지 않을 수 있다. 왜?왜냐하면 자주 삭제된 콘텐츠는 순전히 쓰레기가 되기 때문이다.그것은 실제적이고, 진실된 백과사전 기사를 쓰려는 노력 없이, 또는 무작위적으로 키프레스(keypress)를 쓰거나, 광고판으로서 위키피디아를 남용하거나, 저작권을 침해하는 것이다.삭제 요청을 하는 사람들이 가끔 놓치는 부분이 있다.삭제된 콘텐츠는 종종 나쁜 콘텐츠가 된다.어떤 로봇 기술 "솔루션"도 왜 콘텐츠가 삭제되었는지 확인하기 위해 삭제된 기사를 읽고 있는 인간의 대체물이 될 수 없을 것이다.어떤 자동화된 요청 메커니즘도 여기에 답이 될 수 없을 것이다.특별한 이유가 있다:수배된 페이지들은 사실상 쓸모없었다.

그리고 여기 자주 놓친 또 다른 요점이 있다.요청은 글이 아니다.쓰레기를 버리는 것은 좋은 콘텐츠를 얻기 위한 경로가 아니며, 그렇게 삭제되지 않도록 요청하거나 완전히 새로운 기사를 요청하는 것은 사실 그 콘텐츠를 쓰는 것이 아니다.좋은 내용이 쓰여져야 한다.그것은 겉으로 드러나지 않는다.위키피디아는 결코 완전한 것이 아니며, 필요한 것은 쓰레기를 다시 처리하라는 자동화된 요청이 아니라 쓰는 사람들이다.주소를 쓰는 사람들은 글을 써서 누락된 글을 쓴다.나조차도 이 일을 해냈다.피즈 키퍼한테 한 거야G 삼촌 (토크) 2009년 6월 14일 (UTC) 14:16[응답]

특이하게도 G 아저씨가 말한 모든 것에 동의한다.일반적인 생각과는 달리, 대부분의 기사들은 위키백과에서 자료를 멀리하려는 음모 때문에 삭제되는 것이 아니라, 스팸 발송, 무의미, 또는 완전히 잘못 쓰여져서 삭제되는 것이다.매일 위키피디아에서 얼마나 많은 쓰레기들이 밀려나는지 보려면 Deletionpedia의 "Random Page"를 몇 번 클릭한다.만약 당신이 빨간 링크를 파란색으로 바꾸고 싶다면, 그 공백을 메울 무언가를 쓰세요.– 무지개빛 15:56, 2009년 6월 14일 (UTC)[응답]

캡션에 파일이 비어 있지 않음을 표시

나는 무료가 아닌 파일의 자막에서 무료가 아니라는 것을 표시하는 것이 좋을 것 같아.자막 시작 부분에 {{nff}}("무료 파일"이라고 말함)과 같은 템플릿을 추가할 수 있었다.이것은 사용자들이 무료 콘텐츠와 무료 콘텐츠(결국 위키피디아는 무료 백과사전이다)를 구별하는 데 도움이 될 뿐만 아니라 편집자들이 무료가 아닌 파일의 용납할 수 없는 사용을 걸러내는 데도 도움이 될 것이다.로고는 자막이 없는 경우가 많아 이 아이디어에서 면제될 수 있다.---코인(대화) 09:01, 2009년 6월 12일 (UTC)[응답]

독자들을 위해 사방에 "무료"를 둘 필요는 없다고 생각하지만, 당신은 나에게 사용자:Anomie/linkclassifier.js.Anomie⚔ 11:29, 2009년 6월 12일 (UTC)[응답]

나는 그것이 좋은 생각이라고 생각하지 않고, 필요하다고 생각하지 않는다.만약 사용자가 파일을 복사하려고 한다면 그들은 큰 버전을 얻기 위해 먼저 파일을 클릭할 것이다.파일 설명 페이지에 있는 동안, 그들은 파일이 공정하게 사용된다는 것을 알아야 한다.그 외에는 상당히 눈엣가시일 것이다. - Rjd0060 (대화) 15:14, 2009년 6월 12일 (UTC)[응답]

당신의 기즈모는 아노미(Amonie)를 어떻게 하는가?--케인(대화) 04:07, 2009년 6월 13일 (UTC)[응답하라]

링크된 페이지마다 카테고리 및 페이지 메타데이터(예: 보호 수준)를 확인하고, 링크에 해당하는 CSS 카테고리를 추가한다.그런 다음 모노북.css에서 이러한 클래스를 사용하여 링크를 다른 스타일로 만들 수 있다.예를 들어, dab 페이지에 대한 링크는 노란색 배경으로 표시되고 리디렉션은 녹색으로 표시되며, 리디렉션은 녹색으로 표시되며, (당신의 제안 덕분에) 비자유 이미지는 이중 빨간색 윤곽선과 기호로 표시된다(IE는 내가 아는 한 그러한 CSS 규칙 중 어느 것도 지원하지 않는다).어쨌든 몇몇 사람들은 그것이 유용하다고 생각하는 것 같다.Anomie⚔ 17:05, 2009년 6월 13일 (UTC)[응답]

방금 몇 명 명단에 한 명 추가했어.:) 대본, 고마워! –Drilnoth (T • C • L) 17:44, 2009년 6월 13일 (UTC)[응답]

니프티! 아노미야 12:45, 2009년 6월 14일 (UTC)[응답]

이 대본에 추가된 덕분에 프로젝트 페이지에서 사용하는 비자유 이미지 하나를 이미 수정했고, PUI 논의를 시작했는데, 이 이미지 제거에 반대해 (IMO가 잘못) 라이선스를 "공용 도메인"으로 변경했다.Anomie⚔ 12:45, 2009년 6월 14일 (UTC)[응답]

만약 누군가가 이미지를 다시 사용한다면, 나는 그들이 라이선스를 확인하고 있기를 바란다.기사를 작업하는 편집자들은 이미지를 검토해야 한다. ----- - Gadget850 (Ed) 16:08, 2009년 6월 13일 (UTC)[응답]

대화 페이지의 Scratch Pad

나한테 무슨 도움이 될 줄 알아?사용자 대화 페이지에 있는 작은 스크래치 패드 또는 분필/흰 게시판 유형으로 누군가에게 빠르고 짧은 메모를 남길 수 있다. 내 대화 페이지에 내가 답한 것과 같은 메시지, 이것 좀 봐, 온라인 상태야...어떻든 간에트위터 사이즈가 여러 번 나오는 메시지 유형은 응답조차 필요 없다.대화 페이지 잡음을 줄이고 더 많은 대화를 장려할 수도 있다. 가끔 나는 내가 뭔가를 말하고 싶은 기분이 들기도 한다. 하지만 그 메시지는 너무 경미하고 덧없어서 10단어도 안 되는 메시지에 대해 완전히 새로운 섹션을 만들고 싶지 않다.RxS (대화) 14:55, 2009년 6월 13일 (UTC)[응답]

나는 그 아이디어가 마음에 드는데, 다른 사람들이 좋아하면 그렇게 할 수 없을까?도티••인터뷰 16:39, 2009년 6월 13일 (UTC)[응답]

혹시 {{토크백}}} 같은 것을 생각하고 계신지요?╟-TreasuryTag►스피커-- 16:48, 2009년 6월 13일 (UTC)[응답]

내 생각에 그는 "메모장" 창문을 말하는 것 같아.분명 가끔 주변에서 그런 것들을 보아 왔지만, 어디쯤인지 생각이 나지 않는다.– 무지개빛 20:02, 2009년 6월 14일 (UTC)[응답]

토크백 템플릿은 일부 내용을 다루고 있지만, 다른 용도/이유도 볼 수 있다.이 복사된 메모장 창은 무엇인가?기본적으로 토크 페이지에 포함되었으면 좋았을 텐데.RxS (대화) 21:33, 2009년 6월 14일 (UTC)[응답]

편집 가능한 작은 스크롤 창.난 그들을 본 적이 있다는 걸 알아, 그냥 어디 있는지 생각할 수가 없어.– 무지개빛 21:44, 2009년 6월 14일 (UTC)[응답]

(iii)User에서 말하는 것과 같은 종류의 예가 있다.Alistairjh – 편집 가능하고 독립적으로 스크롤되는 창을 보셨습니까?– 무지개빛 21:48, 2009년 6월 14일 (UTC)[응답]

기본 설정 옵션:유일한 콘텐츠가 위키백과 제목 상자 또는 상자일 경우, 토크 페이지는 존재하지 않는 것으로 표시될 수 있다.비어 있는 경우 사용자 및 대화 페이지

이건 정말 놀림감이군..궁수자리 은하수 (대화) 17:22, 2009년 6월 14일 (UTC)[응답]

BLP의 비소싱 진술

비소싱(비소싱)문구를 기사 토크 페이지("비소싱 문장이 제거됨"머리글에 따라)로이동해도 괜찮은가?나는 특히 이런 것들을 언급하고 있다.위키백과:데이터베이스 보고서/소싱되지 않은 진술이 포함된 생활인의 생체. --MZMcBride (대화) 23:36, 2009년 6월 14일 (UTC)[응답]

이것은 모든 조항에 있어서 비협조적이고 의심스러운 진술에 대한 표준적인 관행이다.그러나 {{fact}}}을(를) 일괄적으로 첨가해서는 안 되는 것처럼 손으로라도 빠른 대규모로 해서는 안 된다.— 칼 (CBM · talk) 00:11, 2009년 6월 15일 (UTC)[응답]

음, 만약 어떤 진술이 해롭거나 부정적인 것이 아니라, 그것이 출처가 되지 않는다면, 그것은 얼마나 오랫동안 기사에 머물러야 하는가?무한정?비소싱된 진술이 토크 페이지로 이동되기 시작해야 하는가?나는 이것이 너무 빨리 이루어져서 기사에 해를 끼쳐서는 안 된다는 것에 동의한다.반면에, 이 문제에 대해 어느 정도 진전을 이루는 것은 매우 중요해 보인다.그리고 어떻게 진행해야 할지 막막하다. --MZMcBride (대화) 03:41, 2009년 6월 15일 (UTC)[응답]

소싱을 진척시키는 유일한 방법은 기사별로 출처를 조사하는 것이다; 어떤 빠른 해결책도 없다.토크 페이지로 물건을 이전하는 것에 대한 진짜 문제는 그들이 얼마나 오랫동안 비협조적인 것으로 태그가 붙었는가 하는 것이 아니라, 그들이 토크 페이지로 이동하는 것을 보증하는 방식으로 논쟁적이거나 의심스럽거나 혹은 명백히 편향되어 있는 것이 아닌가 하는 것이다.어떤 것들은 즉시 대화 페이지로 이동하거나, 아니면 그냥 삭제해야 한다.다른 주장들은 누군가가 그들을 위한 출처를 캐기 위해 노력할 때까지 무기한으로 안전하게 방치될 수 있다.이것은 BLP 기사뿐만 아니라 우리의 모든 기사에서 사실이다.— 칼 (CBM · talk) 04:12, 2009년 6월 15일 (UTC)[응답]

빠른 구글 검색으로 특정 진술에 대한 출처가 드러나지 않는다면 이를 삭제하거나 토크 페이지로 옮기기에 충분한가.일부 사람들은 출처에서 쉽게 구할 수 없는 사실들이 대개 비고지적인 정보를 나타낸다고 주장해왔다.예를 들어 "그는 1991년 파키스탄 총리로부터 최우수 칼럼으로 권위 있는 올파키스탄 신문상을 받았다."고 한다.구글의 빠른 "best+column"+위키피디아 검색은 당장 아무것도 드러내지 않는다.어느 시점에 해당 문구를 토크 페이지로 이동하거나 아예 삭제해야 하는가? --MZMcBride (대화) 18:07, 2009년 6월 15일 (UTC)[응답]

그런 사람이 있으면 구글은 절대 유용한 결과를 주지 않을 것이다.이 특정 기사의 경우, 하나의 가능한 출처는 [2]인 것 같다.이런 종류의 체계적 편견(영어 출처를 무시하고 외국어를 멀리함)은 이러한 종류의 모든 기사가 개별적으로 다루어져야 하는 이유 중 하나이다.— 칼 (CBM · talk) 18:22, 2009년 6월 15일 (UTC)[응답]

BLPS에서 비소싱된 부정적 문구를 적극적으로 제거해야 하기 때문에 (긍정적이거나 중립적이 될) 다른 모든 비소싱된 문구를 토크 페이지로 이동하면 모든 BLP에 약간 부정적인 편견을 도입할 가능성이 있다(모든 것은 음성이 소싱되고, 다른 모든 문장은 소싱되지 않았기 때문에 제거된다고 상상한다.나는 그것이 좋은 생각이라고 생각하지 않는다.쿠스마 (토크) 05:21, 2009년 6월 15일 (UTC)[응답]

나는 잘 이해가 안가, 비지원적 부정적이고 의심스러운 콘텐츠는 완전히 제거되고, 비지원적 긍정적 콘텐츠는 토크 페이지로 옮겨질 것이다.어떤 것이든, 공급되지 않은 양의 콘텐츠를 이동하면 부정적인 내용을 제거함으로써 생기는 편견을 상쇄할 수 있다.나는 왜 사람들이 출처를 찾으려고 한다면, 그들은 부정적인 내용만 출처를 찾을 수 있는지 모르겠다.Mr.Z-man 05:46, 2009년 6월 15일 (UTC)[응답]

단지 하나의 관찰: 그들은 부정적인 정보만 "소싱되어야" 한다는 잘못된 믿음 때문에 그렇게 할 수도 있다.이제 WP:BLP는 정말로 "내용적인" 물질은 긍정적이든 부정적이든 제거되어야 한다고 말한다.한편, 부정적인 물질은 긍정적이거나 중립적인 물질보다 논쟁의 소지가 더 많다.반면에 {{fact}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}— 칼 (CBM · talk) 14:39, 2009년 6월 15일 (UTC)[응답]

최근 변경 사항/BLP

만약 이것이 전에 제안된 적이 있다면 용서하십시오 - 나는 이 페이지들을 자주 보지 않고, 관련 제안들을 찾기 위해 최선을 다했지만, 이것을 찾을 수 없었다.기본적으로, 허글이 일을 하지 않고 편집자들로부터 수동적인 최근의 변화들이 순찰을 돌기 어렵다는 불평을 듣는 것을 본 나는, 패트롤러들이 무엇을 해야 하고 우선순위를 정해야 하는지에 대해 고민하기 시작했다.물론, BLP가 우리의 최우선 과제가 되어야 하지만, 반달리즘적인 편집은 종종 편집의 구름 속으로 사라진다.내가 제안하는 것은 BLP와 각 대화 페이지에 대한 편집만 표시하는 최근 변경사항의 선택사항이다.남용 필터 태그를 통해 또는 더미 네임스페이스를 만들면서 어떻게 그것이 달성될 수 있을지는 잘 모르겠지만, 특히 자동화된 도구가 고장 났을 때, 이러한 기사들을 보호하기 위한 우리의 노력을 더 효율적으로 하는데 도움이 될 수 있는 좋은 생각인 것 같다.\ 백슬래시 포워드슬래시 / {talk} 13:06, 2009년 6월 15일 (UTC)[응답]

짜증스러울 정도로 느리지만: 특별하다:최근 ChangesLinked/Category:리빙_피플씨릴랜드 (대화) 2009년 6월 15일 (UTC) 13:10, 응답

분명히 이미 실행된 충분한 아이디어 입니다.:) 고마워, 낭비된 공간은 미안해.\ 백슬래시 포워드슬래시 / {talk} 13:15, 2009년 6월 15일 (UTC)[응답]

어디서 불평을 할까? (디프들은 빈 줄을 몰라)

나는 이 차이에 내재된 지속적인 좌절감을 가지고 있다.편집자는 섹션 제목 아래에 빈 줄을 추가하는데, 갑자기 "완전히 삭제된" 단락과 "완전히 새로운" 단락이 생겨 편집자가 단락에서 실제로 변경한 내용을 신속하게 식별할 수 없게 된다.

이것은 (잘못된) 특성이라기 보다는 벌레로 간주되는 것인가?확실히 이것은 전에 보도되었다: 그것이 고쳐질 수 있을까?WhatamIdoing (talk) 19:26, 2009년 6월 15일 (UTC)[응답하라]

위키백과의 사용을 고려해 보십시오.대신 마을 펌프(기술)나는 너에게 답을 주었으면 좋겠다. 나도 이것을 고쳐주고 싶다.파워스^T 19:49, 2009년 6월 15일 (UTC)[응답]

생각해 봤는데 WP의 정보 노트는 다음과 같다.VPT는 여기가 더 좋은 곳이라는 것을 암시하는 것 같았다...이 상황에서 옳은 일을 하는 것이 "기능을 만드는 것"이 아닌 "버그 고치기"로 간주되지 않는 한, 올바른 위치는 아마도 완전히 다른 웹사이트에 있을 것이다.WhatamIdoing (대화) 2009년 6월 15일 (UTC) 20:46[응답]

그래, 정확한 장소는 bugzilla일 거야: 하지만 당신이 미디어위키라는 사람이 아니라면, 아마도 그것을 VPT에서 키우는 것이 가장 좋을 거야. 누군가가 더 현명하게 행동할 수 있도록 그러면 당신과 내가 개발자가 읽을 수 있는 버그픽스 요청을 토론할 수 있을 거야.–xeno^talk 20:48, 2009년 6월 15일 (UTC)[응답]

감히 말하지만 기술 펌프에 있는 그 메모는 약간 오해의 소지가 있다.합법적인 기술적 문제가 있었다면 왜 여기로 데려왔는지 모르겠어파워스 01:37, 2009년 6월 16일 (UTC)[응답]

이 문제가 해결될 때까지 크로스브라우저 사용자 설명서의 향상된 차이점 뷰에 기반한 단어/문자 기반 WikEdDiff(가젯 위키에도 포함됨)를 사용할 수 있다.케이시클 (대화) 02:20, 2009년 6월 16일 (UTC)[응답]

새로운 제안: 특정 날짜의 위키백과 사본을 저장하고 이익을 위해 판매

위키백과,

나는 더 큰 회사인 몇몇 사람들이 위키피디아에 "광고 가치"를 보고 있기 때문에 부정직함이 위키피디아에 침투하고 있다는 것을 보도하는 것이 슬프다.이는 나쁜 직책(불완전하고 불균형한 직책)에 대한 통상적인 억지가 여기서부터 미친 듯이 퍼져나갈 것임을 의미한다.

1) Wikipedia를 있는 그대로 온라인에 유지 2) 붕괴가 명백하기 때문에 디지털(매체 없음)에도 200달러를 기꺼이 지불할 것이다.- 진실한 Wiki-Wiki-wiki가 장기적으로 승리하는 3) 이것은 Wikipedia를 사람들의 전화, 데스크탑, 생활로 이동시키는 과정의 첫 번째 단계다. 그래서 더 많은 돈을 그곳에서 사용한다.

끝

PS: 너희들은 "팻"이라는 단어에 대해 논쟁하고 있고 위키 결정체 미녀 전체가 썩고 있어.제발 살려줘 내 너머에서 말이야

음... WP:1.0은 당신을 위해 일하나? --Izno (토크) 02:44, 2009년 5월 25일 (UTC)[응답]

(OP의 숫자와 반드시 일치하는 것은 아님)

1. 스팸과 위키피디아를 조작하려는 시도는 새로운 문제가 아니다.우리는 수년 전부터 스팸을 취급하고 있다.위키피디아의 인기를 고려할 때, 실제로 기업들이 위키피디아를 이전보다 남용하는 것은 훨씬 더 위험하다.WP는 예전에는 단지 SEO의 목적으로 조작될 수 있는 또 다른 사이트였는데, 지금은 대기업이나 정치인이 그것에 걸려들면 뉴스 속에서의 부정적인 홍보에 불과하였다.
2. 위키피디아가 길어질수록 리뷰 기사가 많아지기 때문에 위키피디아는 더 나빠지는 것이 아니라 시간이 지날수록 좋아지고 있는 것 같다.스팸이 이슈가 되고 있지만, 그것이 위키피디아의 느린 죽음으로 이어진다는 것을 암시할 만한 것은 아무것도 없다.
3. 도대체 왜 20센트짜리 DVD로 200달러를 공짜로 내려고 하는 거야?네가 그것을 할 수도 있겠지만, 나는 많은 다른 사람들이 그렇게 할 것이라고 의심한다.
4. 대부분의 새로운 휴대폰은 인터넷 접속이 가능하다. 그리고 다시 말하지만, 사람들이 우리가 공짜로 주는 물건에 대해 돈을 지불하도록 하는 것은 우리의 임무에 다소 반하는 것이다.

Mr.Z-man 05:17, 2009년 5월 25일 (UTC)[응답]

1. 매우 강한 반대 이것은 위키피디아가 "자유로운 백과사전"이 되는 요점을 파괴할 것이다.YOWUZA Talk 2 me! 16:36, 2009년 5월 26일 (UTC)[응답]
2. 이 제안은 이제 새로운 책 어플리케이션과 함께 엉망이 되었다.) 어쨌든, 기업 이윤을 위해 무료 콘텐츠를 판매하는 것에 강하게 반대한다; 어떤 식으로든, 형태든, 형태든.ThemFromSpace 17:32, 2009년 5월 26일 (UTC)[응답]
3. 질문 - 위키백과의 편집자로서, 내가 이 수익의 일부를 얻을 수 있을까?그게 어떻게 될까?내가 편집한 기사에 따라? 아니면 기고문에 따라?학생으로서 내가 개인적으로 돈을 벌 수 있는 어떤 방법이 있다면, 그것은 훌륭한 잠재력을 가질 수 있을 것 같다.그렉 타일러(나, 농담이야. 바보 같은 생각) 2009년 5월 31일 18시 45분 (UTC)[응답하라]
4. 약한 반대 나는 그것이 좋은 생각이 될 것이라고 생각한다.모든 기사를 싣는 게 정말 좋은 생각은 아닌 것 같은데 FA, A, GA, B, C 기사만 붙이면 될 것 같아.물론 그러기 전에 중요한 리뷰나 그런 것들이 필요하겠지.대체로 좋은 생각인데 잘 안 될 것 같아.르네상스 (토크) 23:41, 2009년 6월 3일 (UTC)[응답]
5. 반대 위키피디아는 모든 형태의 무료 백과사전이다.비록 누군가는 그것을 보기 위해 돈을 지불할 것이지만, 그것은 잘못된 공신력 지침이 시행되기 전인 황금기에 있었고, 악한 삭제론자들은 그것을 모두 공황상태라고 부르며 오랫동안 유지되어온 많은 기사들을 대량 파괴하기 위해 나섰다. 드림 포커스 09:39, 2009년 6월 6일 (UTC)[응답]
6. 약한 승인:위키백과는 누구나 복사해서 판매할 수 있고, 위키백과도 그렇게 할 수 있다.그것은 합리적인 자금 조달 제안이다.그러나 질문의 표현은 구독 버전을 일종의 승인 상태를 가진 기사로 제한하는 것을 의미하기도 하며, 질문은 기존의 승인 제안을 알지 못하는 것을 암시한다. -- SEEILco (대화) 18:21, 2009년 6월 14일 (UTC)[응답]
7. 반대 위키피디아의 모든 것에 완전히 반대한다. 누구나 자유롭게 편집할 수 있다.또한 이미 무료로 제공되는 오프라인 CD도 있다.위키백과 참조:세계의 어떤 경우처럼 인터넷 연결이 필요 없고 무료인 위키백과의 cd 버전을 제공하는 것에 관한 버전 1.0 편집팀/FAQ는 항상 이용 가능한 것은 아니다.오타와4에버 (대화) 17:12, 2009년 6월 17일 (UTC)[응답]
8. 이미 하고 있는 몇몇 사람들에게 코멘트를 해라.나노닉 (대화) 2009년 6월 17일 18:26 (UTC)[응답]

• 당신은 이미 위키피디아의 사본을 만들어 이익을 위해 판매할 수 있다(이것은 이용 약관의 "Wikimedia 프로젝트의 콘텐츠를 자유롭게 재이용할 수 있다"에서 "무료"가 의미하는 것의 일부다).물론, 다른 누구라도 당신의 복사본을 복사해서 더 적은 가격에 팔 수 있다.쿠스마 (토크) 15:27, 2009년 6월 18일 (UTC)[응답]

아티클의 마지막 편집 이후 시간 표시

마지막으로 기사를 편집한 시간(즉, "마지막 편집한 시간(5분 또는 3시간 또는 20일 등)" 이후 대략적인 시간을 쉽게 볼 수 있는 기사의 어딘가에 표시할 것을 제안한다.이는 (1) 최근 사건에 대한 기사가 얼마나 최신인지, (2) 한동안 편집되지 않은 기사가 "안정적"으로 간주될 수 있고 공공 기물 파손이나 기타 문제가 있을 가능성이 적다는 가정을 사용하여, 기사의 현재 버전의 신뢰성을 측정하는 지표로서 유용할 것이다.따라서, 잘 아는 독자는 "아, 이 기사는 5분 전에 마지막으로 편집되었어. 여기 정보에 의존하기 전에 편집이 반달리즘이 아닌지 페이지 기록을 확인해야겠어." 또는 적어도 "이것은 5분 전에 편집되었어. 반달리즘이 될 수 있으니 기사의 정확성에 대해 좀 더 경계해야겠어."라고 말할 수 있었다.배치의 경우, 제목과 같은 선으로 제안하고 싶지만, 오른쪽 정렬과 작은 글꼴로 제안하고 싶지만, 이것은 분명히 제안할 여지가 있다.

이미 마지막 수정일을 페이지 하단에 주었을 때 더 나은 이유에 대해 말하자면 (1) 페이지 하단에 있고 (2) 로그인을 하지 않는 독자들에게는 전혀 보이지 않을 때, UTC의 날짜/시간을 주는데, 이것은 (3) 변환하는 데 고통이 될 수 있다 (3) 날짜는 경과된 수치에 비해 단지 덜 편리하다. --Cyb에르코브라 (대화) 2009년 5월 29일 (UTC) 12시 17분[응답]

이상하게도 UTC라고 써있지만, 사실 여전히 너의 프리프들을 기반으로 하고 있어.로그인하지 않았다면 물론 이것은 중요하지 않다.하지만, 신뢰성을 결정하기 위해 "얼마 전"을 사용하는 것은 그리 좋은 일이 아니라고 생각한다.반달리즘은 충분히 미묘하다면, 오랜 시간, 심지어 몇 년 동안이나 머물 수 있다.♫ 멜로디아 샤콘네 ♫ (토크) 13:24, 2009년 5월 29일 (UTC)[응답하라]

그렇구나, 지난번 편집 이후 시간을 신뢰성의 확실한 척도로 사용하는 것에 대한 반증이 있지만, 아무도 그것을 제안하지 않고 있어.그들은 긍정적인 상관관계가 있다는 것을 암시하고 있다.그리고 그들은 이것이 장점이라고 말하고 있다.어느 쪽인가.이제 상관관계가 없다고 해도 그 상관관계의 결여가 나쁜 것은 아닐 것이다.마지막으로 편집한 시간은 이미 표시되어 있으며, 신뢰성과 상관관계가 없는 것은 분명하지만 신뢰성이 없는 상관관계가 없다는 것이 제거의 이유라고 주장하지는 않는다.케빈 바아스^talk 15:10, 2009년 5월 29일 (UTC)[응답]

마지막 편집이 끝난 지 얼마나 지났는지 보여주는 아이디어가 마음에 든다.나는 많은 장점들을 볼 수 있고, 단점도 없고, 화면의 아주 작은 공간을 사용해서 절약할 수 있다.케빈 바아스^talk 15:10, 2009년 5월 29일 (UTC)[응답]

캐싱이 문제가 될 수 있어...예를 들어 {{undercorporation}}에는 "마지막으로 편집된" 카운터가 내장되어 있지만, 대개는 구식이다.마지막 편집 후 5시간이 지난 후에도 페이지의 캐시가 삭제되지 않았기 때문에 여전히 "3초"라고 말할 수 있다.나는 미디어위키 소프트웨어에 대해 이것이 고쳐질 수 있는지 알 만큼 충분히 알지 못하지만, 그것은 단지 생각해 볼 일이다.–Drilnoth (T • C • L) 15:37, 2009년 5월 29일 (UTC)[응답]

자바스크립트로 "마지막 편집된 시간" 타임스탬프를 구문 분석하여 상대 시간으로 변환할 수 있다.물론 JS가 없는 사람들은 돕지 않을거야...해피멜론 16:27, 2009년 5월 29일 (UTC)[응답]

성과와 관련하여 다음과 같은 위키백과가 있다.나라도 이런 변화가 생긴다면 그 충격에 대해서는 여전히 경계하겠지만, 그렇다고 해서 그 제안이 그 정도까지 도달했는지는 개발자들이 더 따져봐야 할 문제인 만큼 아직 성과에 대한 걱정은 하지 말아야 한다. --사이버코브라 (대화) 2009년 5월 29일 (UTC) 17:00 (화)[응답]

잘못된 "UTC" 라벨이 지난 달 메시지에 추가되었다.방금 제거했어 —David Levy 17:16, 2009년 5월 29일 (UTC)[응답하라]

그러나 지금은 로그인하지 않은 독자들에게는 「UTC」가 보이지 않는다... --사이버코브라 (토크) 17:54, 2009년 5월 29일 (UTC)[응답]

그것은 미디어위키 개발자들이 다룰 문제다.한편, 절대 부정확함보다는 약간의 애매함이 훨씬 더 바람직하다.—David Levy 18:03, 2009년 5월 29일 (UTC)[응답]

그렇긴 한데, 개발자들이 알기나 할까? --사이버코브라 (대화) 18:06, 2009년 5월 29일 (UTC)[응답하라]

버질라 입국을 못 봐서 신고했어—David Levy 18:41, 2009년 5월 29일 (UTC)[응답]

나는 이것이 종종 제안되는 보기 없는 페이지 목록과 같은 문제를 가지고 있지 않을지 궁금하다 - 반달들은 최근 편집이 되지 않은 페이지들에 끌릴 수 있고 보기 없이 될 가능성이 더 높다.또한 그것은 단지 카운터를 재설정하기 위해 새로운 유형의 파괴 행위를 불러일으킬 수도 있다.Rmhermen (대화) 2009년 5월 30일 (UTC) 16:25 [응답]

카운터를 리셋하기 위한 반달리즘은 너무 지루해서 반달들에게는 가치가 없을 것 같다.반달들이 직접 나가서 페이지를 찾아야 하는 것처럼 감시되지 않은 페이지 목록만큼 나쁘지는 않을 것이다; 게다가 감시와 마지막 편집 이후의 시간의 상관관계는 직접적이지 않다. --사이버코브라 (talk) 02:04, 2009년 5월 31일 (UTC)[응답]

또한, 이 페이지에서 상기에 제시된 "최근 미보딩 변경사항" 기능은 미보딩 페이지 문제를 해결하는데 도움이 될 것이다. --Cybercobra (토크) 08:58, 2009년 5월 31일 (UTC)[응답]

나는 이것이 가치를 더하고 그것이 구현되는 것을 보고 싶다.이전 버전을 볼 때 이미 표시된 배너를 항상 표시하는 것은 어떠세요(마티스 관련)?심지어 #의견 - 위키백과의 신뢰성이 어떻게 향상될 수 있는가 하는 논의에 비추어 볼 때, 아마도 빨간색으로 남겨두어라.어쨌든, 항상 거기에 그것을 두는 것은 일관성을 도입할 것이고 캐싱은 그 메커니즘에서 문제가 되지 않는 것처럼 보인다.PL290 (대화) 12:55, 2009년 6월 1일 (UTC)[응답]

그것은 확실히 실행 가능한 실행 옵션이다.나는 개인적으로 사용자 이름을 보여주는 것이 반달리즘/반달성을 조장할 수 있기 때문에 그것을 선호하지 않는다. 나는 위에서 설명한 타임스탬프보다 시간 델타를 선호하고 빨간색이 불필요하게 주의를 산만하게 하는 것처럼 보인다.하지만 그건 나뿐이야. --사이버코브라 (대화) 16:59, 2009년 6월 1일 (UTC)[응답]

• 제안서에는 5분 전에 마지막으로 편집한 페이지보다 오랫동안 편집되지 않은 페이지가 더 안정적이거나 신뢰할 수 있다고 가정할 때 "안정성"을 측정하는데 유용할 것이라고 한다.그러나 나는 그것이 운동, 사업, 정치, 선거와 같은 화폐에 의존하는 일부 기사에서는 역효과를 위해 동등하게 가치가 있을 수 있다고 생각한다.월드시리즈, 올림픽대회, 선거, 사표, 주식시장 드라마, 천재지변, 범죄, 법원 결정 또는 신문의 지각변동이 일어난 다음 날인데, 관련 기사가 마지막으로 편집된 지 5일(또는 반대로 5분)이 지났다면 독자들은 얼마나 최신식인지 좀 더 명확하게 알 수 있을 것이다.그 기사의 정보를 먹었을 가능성이 높다.—— Shakescene (대화) 13:22, 2009년 6월 1일 (UTC)[응답]
  • 사실, 이것은 내 제안의 두 번째 문장에서의 포인트 (1)이었다.-. --사이버코브라 (토크) 16:53, 2009년 6월 1일 (UTC)[응답]

• 주석, 각 페이지의 발에 "이 페이지는 2009년 6월 4일 02:25에 마지막으로 수정됨" 또는 마지막으로 업데이트된 날짜/시간이라고 적혀 있을 때, 왜 성가시게 하는가?러그넛 (토크) 06:37, 2009년 6월 4일 (UTC)[응답하라]
  • 이 논의의 두 번째 단락, 특히 이 문제를 다루는 "이유에 대하여"를 시작하는 것을 참조하십시오. --Cybercobra (대화) 07:24, 2009년 6월 4일 (UTC)[응답]

• 캐싱과 함께 발생할 수 있는 문제를 보긴 하지만, 이것이 어떻게 구현될 지에 대해 아무것도 모르는 나는 그 아이디어가 마음에 든다.음, 2009년 6월 4일 13:45 (UTC)[응답]
  • 캐싱 문제도 궁금했다.일반적으로 너무 거슬리거나 실행하기 어려운 생각이 아니라면 나는 그 생각이 마음에 든다고 생각한다.– 루나 산틴 (토크) 21:38, 2009년 6월 4일 (UTC)[응답]

페이지 하단에 하나 있다.다른 것을 얻을 이유가 없다.그리피노프왈레스 (대화) 22:54, 2009년 6월 4일 (UTC)[응답]

팝업을 사용할 수 있는 경우 페이지 링크에서 마우스를 움직이면 페이지 사용 기간이 지정된다.위키피디아에 따르면:도구/내비게이션 팝업, 페이지 연령 코드는 Mike Dillon에 의해 작성되었다. ---— Gadget850 (Ed) 01:16, 2009년 6월 5일 (UTC)[응답]

• 나는 이 정보가 너무 두드러지게 보일 만큼 중요하지 않다고 생각한다. 특히 당신이 그것을 찾으러 간다면 그것은 쉽게 구할 수 있기 때문이다.하지만 나는 UTC를 사용하는 문제를 없애고 단순화시켜서 페이지가 얼마나 오래전에 편집되었는지 보여주는 아이디어가 좋다.나는 "이 페이지는 2009년 6월 5일 14:41 UTC (24분 11초 전)에서 마지막으로 수정되었다"와 같이 각 페이지 하단에 이 정보를 포함시킬 것을 제안한다.이 해결책은 출발점이나 타협점으로 볼 수 있다.—Pie4all88 23:05, 2009년 6월 5일 (UTC)[응답]

• 이봐, 난 그게 저 아래에 있는지 전혀 몰랐어.몇 년 동안 위키피디아를 사용했는데, 여기서 언급된 후 바로 밑바닥에서 보았다.최근 정보가 얼마나 최신 정보인지, 기사가 얼마나 활발하게 편집되고 있는지 궁금할 때가 많으니 좋은 생각이 될 것 같다.아마도 당신은 지난 30일 동안에도 얼마나 많은 편집이 있었는지 보여줄 수 있을 것이다. 드림 포커스 09:44, 2009년 6월 6일 (UTC)[응답]

• 특히 이 백과사전을 읽으러 온 95% 이상의 사람들의 이익을 위해 좋은 생각이다.발생할 수 있는 품질 문제를 나타내는 비침해적 방법 및 UTC 문제를 피하는 좋은 방법.경험이 풍부한 편집자들은 그것이 필요없지만, 그렇다고 우리가 그것에 반대표를 던질 이유는 없다.DGG (대화) 22:36, 2009년 6월 7일 (UTC)[응답]

내가 가지고 있는 한 가지 우려는 사람들이 그것을 일종의 안일한 형태로 사용할지도 모른다는 것이다.예를 들어, 일주일 이상 전에 그것이 옳다는 것을 의미하고, 일주일 미만이 그것이 공공 기물 파손일 수 있다는 것을 의미하며, 확인할 가치가 있는 고정된 경계는 없다.그것은 사람들의 판단이다.그러나 일부 편집자들은 "일주일 이상, 무시하라"고 생각하는 기사들을 대충 훑어볼 수도 있다.일주일 이상, 무시하라구?그것은 단지 그것의 배치가 기사의 내용에 대한 일종의 확고한 지침처럼 작용할 것 같은 느낌이지만, 그것은 그렇지 않다.쓰려는 사람은 밑바닥인데, 왜 다른 사람을 잠재워서 그릇된 안보의식으로 만들었을까?그레그 타일러22^{(t • c)}:26, 2009년 6월 8일 (UTC)[응답]

우리는 대부분 편집자보다 독자들을 더 겨냥하고 있다; 사실, 나는 편집자들에게는 아주 최근에 기사를 편집했다면 공공 기물을 파손하는 것을 확인하는 빨간 경고등이 될 수 있다고 생각하지 않는다. 하지만 나는 그것이 어떤 상황에서 편집자들이 현재 상황에 비해 편집하는 것을 방해할지 모르겠다; 아마도 당신은 그럴 것이다.당신이 상상하는 황량한 시나리오를 묘사할 수 있는가?맨 아래에 있는 것의 문제는 거의 보이지 않는다는 것이다(사용자:꽤 유용한 정보임에도 불구하고 위의 드림 포커스의 논평)은 다음과 같다.앞에서 말한 바와 같이, 그렇다, 그것은 정확성이나 파괴력의 부족이 아니라 안정성과 직접 관련이 있을 뿐이다. 그러나 안정성은 파괴 행위와 편집-전쟁의 부족과 밀접한 관련이 있다.그것은 또한 의식을 고양시키는 조치다: 독자들이 이 정보를 본다면, 그들은 더 회의적이고 반달리즘 가능성이 있는 경우에 역사/출처를 확인하는 경향이 있을 수 있다.잘못된 안보의식에 대해서는, 이 백과사전은 누구나 편집할 수 있기 때문에, 어떤 보안도 있다는 생각은 잘못된 것이다; 이것은 단지 사물이 특히 안전하지 않은 때를 나타낼 것이다.나는 또한 잘못된 해석에 대한 우려를 해소하기 위해 첨부된 설명 메시지나 페이지를 지지할 것이다. --Cybercobra (대화) 03:23, 2009년 6월 9일 (UTC)[응답]

넌 콜백을 잘하는데, 네 요점을 알겠어.개인적으로, 그것은 "만약 고장나지 않았다면, 고치지 말라"는 경우일 뿐이다.나는 지금 이대로가 만족스럽고 변화가 필요하다고 생각하지 않는다.이를 근거로 투표에서 기권하겠다.나는 그것에 대한 압도적인 이유를 알 수 없지만 그 생각에 대해 크게 반대하지는 않는다.답장과 내 토크 페이지에 있는 노트에 고마워.그레그 타일러 08:43, 2009년 6월 9일 (UTC)[응답]

• 매우 무의미하며, 어떤 기사가 더 안정적이거나 공공 기물을 파괴할 가능성이 낮다는 어떠한 징후도 없다.편집이 덜 된 기사들은 공공 기물 파손 행위를 몇 주, 심지어 몇 달 동안 머물게 했다.또한 그것은 실제 안정을 나타내는 유효한 지표도 아니다.다시 말하지만, 편집이 덜 된 기사들은 편집하지 않고 몇 주, 몇 달, 심지어 몇 년이 걸리겠지만, 그렇다고 해서 반드시 "안정적"이라는 뜻은 아니다.진짜 안정성은 단지 눈에 띄지 않는 하찮은 기사일 뿐이 아니라, 아직 안정되어 있는 것에서 온다.기사가 언제 편집됐는지 아는 데 관심이 있는 사용자는 바닥글을 이미 하단에 있는 것처럼 쉽게 보거나 역사를 확인할 수 있다.그것을 좀더 우호적으로 만들거나 움직일 필요가 없다.대부분의 웹사이트는 하단에 "마지막 업데이트"를 했기 때문에, 그러한 정보에 관심이 있는 사용자들은 자연스럽게 그곳을 보게 될 것이다. -- Collectonian (토크·논문) 05:02, 2009년 6월 9일 (UTC)[응답]
  • 목적은 "마지막 편집 이후 긴 시간이 신뢰성과 동의어"가 아니라 "마지막 편집 이후 짧은 시간이 신뢰성과 상관관계가 있다"는 역이다.이전에 주어진 다른 점에 대한 견해. --Cybercobra (대화) 05:28, 2009년 6월 9일 (UTC)[응답]

실행 요약

다음은 WP를 피하기 위해 지푸라기 여론조사에서 신규 유권자의 이익을 위해 위와 같은 논의를 요약한 시도다.TLDR. --사이버코브라 (대화) 05:23, 2009년 6월 9일 (UTC)[응답]

에 대한 인수

• 기사 안정성과 기물 파손의 부족과 상관관계가 있는 + 편집 전쟁; 독자들이 사용할 수 있는 대략적인 정확도 측정
  • 반대: 미묘한 공공 기물 파손은 오랫동안 지속될 수 있기 때문에 "시간 경과" 수치는 경우에 따라 기물 파손 지표로 오도될 수 있다.
    • 반대론자: 아무도 그것이 직접적인 인과 관계라고 주장하지 않는다. 단지 그것이 유용한 상관 관계라고만 한다.
• 현재 이벤트 기사가 얼마나 최신 상태인지 확인하는 데 유용함
• 기존 "마지막 수정" 타임스탬프보다 이러한 목적에 더 유용함. 먼저 "반대 주장"의 카운터를 참조하십시오.
  • 반대: 관심 있는 사람은 누구나 스스로 계산을 할 수 있다.

에 대한 주장

• "마지막 수정" 타임스탬프가 이미 존재하며 이러한 목적으로 사용될 수 있다.
  • 카운터: "마지막 수정" 타임스탬프는 UTC로 되어 있어 수동으로 변환하고 비교해야 하므로 불편함
    • 카운터 카운터: 로그인하지 않은 경우에만, 등록된 모든 사용자에 대한 기본 설정별로 표시
      • 카운터-카운터: 이러한 변화는 주로 비사용자 독자들을 돕기 위한 것이다.
  • 카운터: "마지막 수정" 타임스탬프가 페이지 하단에 있으므로 찾기/해제하기 어려움
  • 카운터: " 경과된 시간" 수치는 타임스탬프보다 이러한 목적에 더 직접적으로 유용하다.
• 캐슁을 방해하거나 성능 문제를 일으킬 수 있는 " 경과된 시간" 포함
  • 카운터: WP:성능에 대해 걱정하지 마십시오. 개발자는 아이디어의 정확한 구현을 수정하여 영향을 최소화할 수 있음
• 카운터를 재설정하기 위해 공공 기물 파손 행위를 유발할 수 있음
  • 반역: 그것은 반달들이 할 수 있는 다른 것들에 비하면 지루해 보인다.
• 반달은 어떤 편집도 하지 않고 오랫동안 보지 않거나 덜 읽힌 페이지를 반달하게 할 수 있다.
  • 카운터: 마지막과 감시 사이의 상관 관계가 직접적이지 않음
• 이 정보는 그렇게 두드러지게 보일 만큼 중요하지 않다.
  • 반대: "논의"를 참조하고, 첫 번째 "반론"에 반대한다.

짚폴

경과 시간의 표현 및 사용

나는 그 제안에 대한 일반적인 원칙에는 동의하지만 현재 형태의 두 가지 측면이 나와 관련이 있다.이 문제들 중 하나가 기존 페이지 바닥글 텍스트에 이미 존재함에도 불구하고, 위의 선택사항 중 하나를 "포용"하는 나의 투표를 방지할 수 있을 만큼 중요한 측면들이다.

나는 "마지막"이라는 단어가 불필요하게 흔하지만 내 관점에서는 사실을 전달하기 위해 의도된 산문에서 매우 나쁜 관행을 사용하기 때문에 반대한다. 그것은 문자 그대로, 단순히 사실이 아닌 단어의 사용이다.'아이디어스는 웹을 사용해서는 안 된다' 등의 반론도 있겠지만, 분명한 사실은 사용자 브라우저의 웹 페이지에 표시되는 '이 페이지는 약 7시간 전에 마지막으로 편집되었다'는 문장이 표시되자마자 거짓이 될 수밖에 없다는 것이다.

• 1) 1시간 후 브라우저 디스플레이가 7시간에서 6시간으로 카운트 다운되나?javascript 등이 채택되지 않는 한(이것은 일반적인 해결책보다 덜 함), 더 중요한 것은 다음과 같다.
• 2) 1분 후 다른 사용자가 페이지를 편집하면 브라우저 디스플레이에 이 내용이 표시되나?

아니다. 두 경우 모두 사용자의 브라우저에는 "이 페이지는 약 7시간 전에 마지막으로 편집되었다"라는 불필요한 거짓 문구가 여전히 표시된다.

이제, 여러분은 아마도 "모든 사람들이 알아야 한다"는 브라우저가 검색된 시점에 검색된 내용만 보여줄 것이고, "모든 사람들이 알아야 한다"는 것은 다른 사용자 편집에 대해 "알지 못할 것이다"라고 말할 수 있으며, 따라서 모든 사람들이 문자 그대로 사실이 아닌 것으로 그러한 문구를 "해석할 줄 알아야 한다"고 말할 수 있을 것이다. 그리고 그 모든 것에는 많은 진실이 있다.그러나 "모든 사람이 해야 한다"는 것도 사실이며, 실제로도, "모든 사람이 해야 한다"는 것, 즉 웹과 그 변화하는 기술과 같은 것으로 더더욱, 단순히 그들이 아직 배우지 못했기 때문에, 또는 어떤 다른 이유로든, 어쩌면 "모든 사람이 해야 한다"는 것 이외의 일을 하는 사람들이 있을 것이다.장애를 일으키다그러므로 나의 요점은 단순히 이것이다: 사실들을 전달하기 위한 산문에서는, 가능하면 큰 왜곡, 혼란, 산만함 없이, 문자 그대로의 진리를 전달하는 단어들을 사용하라.

두 번째 쟁점은 타임스탬프보다는 경과 시간을 사용함으로써 그 렌더링 순간과 관련된 진실만을 나타내는 문장이 첫 번째 이슈를 악화시킨다는 것이다.시간대 문제는 그 자체로 해결하고 해결해야 한다.

이 두 가지 문제를 고려한다면, 나는 다음과 같은 선에서 어떤 것을 보고 싶다.

• 본 버전은 2008년 6월 9일 화요일 09:36에 작성되었다(동부 표준시)

PL290 (대화) 09:00, 2009년 6월 9일 (UTC)[응답]

"시간대 문제"를 어떻게 해결하자고 제안하는가?내게는 꽤 어려워 보이지만, 만약 당신이 그것을 작동시킬 수 있다면 실행 가능한 대안이다; 나는 그것이 더 단순하고, 지리적 복잡성을 피하며, 의도된 용도의 맥락에서 더 직접적으로 유용하기 때문에 시간이 경과하면서 갔다.표현과 관련하여, 페이지 하단의 타임스탬프가 "2008년 6월 9일 화요일 09:36 현재 버전" 또는 이와 유사한 버전으로 변경되도록 캠페인할 수 있는가?타임스탬프를 다시 인쇄하면 더 잘 보이게 하는 것에 반대하십니까? --Cybercobra (대화) 09:36, 2009년 6월 9일 (UTC)[응답]

- 타임스탬프를 다시 인쇄할 경우 타임스탬프 표시: 그래, 나는 이것을 지지한다.오른쪽 상단 위치에서 또는 "페이지의 리드 섹션에 [편집] 링크 추가"를 활성화한 사용자들을 위해 "Webedia, 무료 백과사전 (...)" 또는 그 아래에 "Akipedia, 무료 백과사전 (...)"에 추가될 수 있는 다른 항목(예: 템플릿 등에서 생성된 아이콘 또는 [편집] 링크))으로 인해 문제가 발생할 경우o this.

- 시간대별 질문: 아마도 별도의 토론이 있을 수 있으므로, 당신의 제안을 방해할 수 있을지 걱정되지만, 우선 나는 예비역과의 3단계 접근법을 제안하고 싶다.

• 로그인한 사용자인 경우 사용자 기본 설정의 표준 시간대
• 그렇지 않으면 javascript가 지원되는 경우, 브라우저 시간대별로 javascript를 렌더링하십시오.
• 위의 두 가지 모두에 실패하는 결론은 EST와 같이 합의된 디폴트를 사용한다.

모든 경우에 사용되는 주 표준 시간대.PL290 (대화) 10:35, 2009년 6월 9일 (UTC)[응답]

표현방식이 적절하다면 경과 시간은 문제될 필요가 없다.예를 들면 다음과 같다.

• 이 페이지가 표시되었을 때, 약 2시간 전에 마지막으로 편집된 페이지였습니다.

또는 정말로 유용한 정보를 얻으려면 타임스탬프와 경과 시간을 모두 표시하십시오.

• 이 페이지가 표시되었을 때, 2008년 6월 9일 12:43 GMT에서 약 2시간 전에 마지막으로 편집되었다.

PL290 (대화) 11:57, 2009년 6월 9일 (UTC)[응답]

나는 그것이 너무 장황하고 거슬릴까 봐 두려워.너무 많은 공간을 차지하거나 큰 관심을 훔치면 안 돼, 그냥 순한 작은 일이지.그러나 당신의 피드백과 추론이 주목되고 있다. --사이버코브라 (토크) 12:21, 2009년 6월 9일 (UTC)[응답]

나는 이것이 걱정할 일이 아니라고 생각한다.만약 사람들이 브라우저가 자동으로 새로 고쳐지지 않는다는 것을 깨닫지 못한다면, 음, 오, 그래.내 말은, 이건 중요한게 아니야.그들이 보고 있는 버전은, 처음에 그것을 로드할 때, 정확한 시간 프레임을 제공한다.만약 그들이 그것을 이틀동안 그대로 놔두고 시간이 업데이트되기를 기대한다면...그건 우리 문제가 아니야시간대 문제까지.디폴트를 사용하려면 UTC여야 하는데, 이는 사이트의 나머지 부분에 대한 디폴트이기 때문이다.لennavecia 12:52, 2009년 6월 9일 (UTC)[응답]

차라리 일반적인 생각을 해보는 게 낫겠어. 즉, 2시간 전에...이틀 전에...일주일 이상 전에...3개월 이상 전에...1년도 더 전에."FT2 18:33, 2009년 6월 10일 (UTC)[응답]

일부 의견:

• JavaScript에서 "만료된 시간" 디스플레이를 수행해야 하며, 그렇지 않으면 애논(캐싱)에서는 작동하지 않음
• JavaScript는 사용자의 시간 오프셋을 기본 설정에서 직접 액세스할 수 없다.기본 설정 오프셋이 브라우저 시간대와 동일하다고 가정하는 것은 안전하지 않다.
• 마지막으로 수정된 타임스탬프는 시간 오프셋뿐만 아니라 타임스탬프 형식 환경설정에 따라 달라진다.
• 날짜 문자열을 반환하는 자바스크립트 기능은 브라우저 간에 일관성이 없다.Firefox와 Safari는 전체 시간대 이름("Eastern Dayline Time")과 GMT 오프셋을 반환하고, IE는 약어("EDT")만 반환하며, Opera는 GMT 오프셋만 반환한다.나는 다른 브라우저들이 무엇을 하는지 잘 모르겠다.자바스크립트는 스트립타임과 같은 기능을 가지고 있지 않다.
• 사이트의 다른 모든 타임스탬프가 사용하는 UTC 이외의 기본값을 사용하는 것은 ASIN에 불과하다.

--Mr.Z-man 19:20, 2009년 6월 10일 (UTC)[응답]

사후에 투표하기

좋아, 이제 투표 결과는 조금씩 줄어들어 가고 있는 것 같으니까, 그 결과에 대한 나의 해석은 다음과 같다.

• 경과된 시간을 추가하는 데 의견이 일치함
• 그러나 오른쪽 상단에 배치하거나 타임스탬프를 현재 위치에서 이동하려는 어떠한 합의도 없다.

그래서 대체 배치 제안이 없는 한 페이지 하단의 타임스탬프별로 경과 시간을 추가하는 버그를 제기할 것을 제안한다. --Cybercobra (토크) 01:14, 2009년 6월 15일 (UTC)[응답]

좋은 생각이야!버그 리포트는 이런 요청에 적합한가?—Pie4all88 20:41, 2009년 6월 16일 (UTC)[응답]

내가 위에서 직접 말했듯이, 우리가 등록되지 않은 사용자들에게 그것이 제대로 작동되길 원한다면, 어떤 경과된 시간 표시도 자바스크립트로 해야 할 것이다.MediaWiki의 JavaScript에 추가할 것을 요청하는 버그를 신청할 수 있지만, 여기서 사이트 전체의 JavaScript에 추가하는 것은 그만큼 (아마도) 쉬울 것이다.그냥 코디할 사람을 찾으면 돼2009년 6월 16일 (UTC) 20:46 미스터 지맨[응답]

우리 그냥 웃으면 안 될까?{{Time ago {{REVISIONTIMESTAMP}}}} 5초 전인가?Dendodge_T\^C 20:51, 2009년 6월 16일 (UTC)[응답]

그것은 인터페이스에 그것을 구축하는 것과 같은 캐싱 문제를 가지고 있을 것이다.2009년 6월 16일 Mr.Z-man 21:13 (UTC)[응답]

가능한 캐싱 문제는 개발자들이 이것이 어떻게 구현되는지에 대해 넓은 관용도를 가져야 하는 이유다.나는 개인적으로 호환성이 떨어져서 Javascript를 좋아하지 않지만, 개발자가 결정한 것은 무엇이든 가야 한다. --Cybercobra (토크) 22:37, 2009년 6월 16일 (UTC)[응답]

JavaScript를 사용하지 않거나 일정 수준의 캐싱을 사용하지 않는 소프트웨어에서 정확한 경과 시간을 제공할 수 있는 방법은 없다.Mr.Z-man 23:15, 2009년 6월 16일 (UTC)[응답]

(헌재) #19276 --사이버코브라 (토크) 07:06, 2009년 6월 18일 (UTC)[응답]

비자유 네임스페이스

이전에 이 문제에 대해 논의한 적이 있다면 용서하십시오. 하지만 무료가 아닌 파일에 대해 새로운 네임스페이스를 만들 생각을 가진 사람이 있으십니까?

배경

• 몇 가지 예외에 따라 주 네임스페이스에 비자유 콘텐츠만 허용(WP:NFCC#9).그러나 이 소프트웨어는 "파일" 네임스페이스의 모든 것을 기본적으로 어느 곳에나 표시할 수 있도록 허용한다.
• 라이센싱 정책에는 비자유 콘텐츠는 반드시 기계 판독 가능한 형식으로 식별해야 한다고 명시되어 있다.현재, 우리는 "Non-free" 문자열로 시작하는 템플릿의 존재에 의해 비-free 콘텐츠를 식별한다. (즉, 위키텍스트는 regex "\{{[N]on-free"와 일치해야 한다.)이것은 내용물에 대한 비프리 태그를 효과적으로 "볼트온"한다.
• EDP는 현재 숙련된 편집자와 자동화된 봇에 의해 시행되고 있다.이러한 개입이 없다면, 비자유 파일은 자유 파일과 동일하게 취급된다.템플릿, 포털, 카테고리, 토크 페이지 등에 비자유 태그가 표시된 이미지를 찾는 일은 드물지 않다.새로운 편집기의 사용자 페이지에는 종종 비자유형 미디어가 포함되어 있다.

프로포즈

"무료" 네임스페이스를 만들면 소프트웨어가 WP를 자동으로 실행할 수 있다.사용자/봇 개입 없이 NFCC#9.다른 특징들은 나중에 개발될 수 있다.

• 완전 무료 백과사전을 원하는 사용자는 사용자 선호도에서 '자유 콘텐츠 전용' 스위치를 선택할 수 있다(우분투와 같이 거의 자유로운 운영체제를 설치할 때와 유사).미디어위키가 페이지를 렌더링할 때 비자유 네임스페이스의 모든 콘텐츠는 숨겨진다.
• 비자유 영상의 렌더링 크기에 대한 자동 제한을 구현할 수 있다.
• 기본적으로 기본 네임스페이스를 제외한 모든 네임스페이스에 비자유 콘텐츠가 숨겨질 수 있다.예외는 __EDPEXECECTION__과 같은 동작 스위치를 사용하여 지정할 수 있다.[이것은 범주 페이지에서 모든 (무료뿐만 아니라) 이미지를 끄기 위해 _NOGALLERY_가 필요한 현재 상황보다 더 유연하다].

비자유 파일들은 새로운 네임스페이스로 이동해야 하고 공간간 리디렉션된 이미지들은 적절하게 처리해야 하기 때문에 이것을 실행하면 큰 골칫거리가 될 수 있을 것 같다.아이디어에 대해 생각해 보셨나요?그것이 고치는 것보다 더 많이 부서질까?파파 11월 (토크) 2009년 6월 18일 (UTC) 12:27[응답]

• "템플릿 시작 '무료' 외에도 카테고리:동일한 템플릿에 포함된 모든 비자유 미디어. API를 통해 직접 쿼리할 수 있으므로 잠재적으로 훨씬 더 시스템 친화적인 미디어.업로더가 다양한 이유로 업로더의 무료함을 거짓말하는 경우가 너무 잦고 그 어떤 것도 실제로 그것을 바꿀 수 없기 때문에 사용자와 봇은 여전히 필요할 것이다.하지만 "다른 특징들"은 흥미롭다.
  기존 파일의 이동이 이렇게 구현된 경우, 모든 비자유 미디어가 이미 명확하게 분류되어 있기 때문에 봇이 쉽게 전달할 수 있었다.Anomie⚔ 12:39, 2009년 6월 18일 (UTC)[응답]

• 개인적으로, 나는 구현 비용이 최소한의 이익보다 훨씬 더 크다고 생각한다.미디어위키에서 추가 파일 네임스페이스를 만들기 위한 코딩 작업 외에도 335000개이상의 이미지를 이동해야 하며, 새로운 네임스페이스 이름을 사용하기 위해 기사에서 362000개이상의 비자유업데이트해야 한다 사용을 이미지.이런 것들은 대부분 봇으로 할 수 있지만, 심지어 초당 한 번의 편집을 하는 것 조차도, 미디어위키 내에서 이미지가 움직이는 것을 가능하게 하는 경우에도, 8일 동안 쉬지 않고 편집하는 것이 필요하다.하나의 네임스페이스 접두사가 모든 파일에 대해 작동한다고 가정하는 템플릿은 2와 함께 작동하도록 변경되어야 한다.문서는 수동으로 업데이트해야 한다.그리고 이미지로 작동하는 봇과 스크립트는 수정이 필요할 수도 있다.2009년 6월 18일 Mr.Z-man 20:24 (UTC)[응답]
  • 이건 정말 좋은 생각 같지 않아.게다가, 이론적으로, 위키피디아의 파일 네임스페이스는 여기에 현재 저장되어 있는 거의 모든 무료 이미지를 호스팅해야 하기 때문에, Commons가 받아들이지 않을 일부 자유 이미지와 비자유 이미지만 포함해야 한다. –Drilnoth (T • C • L) 20:30, 2009년 6월 18일 (UTC)[응답]
  • 흠, 시행 악몽이 될까 봐 걱정했었어.동일한 혜택을 보다 쉽게 얻을 수 있는 방법이 있는가?특히, 사용자 선호도에서 무료가 아닌 콘텐츠를 끌 수 있다면 정말 좋을 것이다.범주/템플릿 트랜지스터에서 비자유 영상을 식별하는 것이 이미 가능하다면, 어떻게든 "꺼짐" 버튼을 구현하는 것이 가능해야 한다고 생각한다.파파 11월 (토크) 21:44, 2009년 6월 18일 (UTC)[응답]

Rfc:자체 선택 그룹

• 위키백과:주석/자체 선택 그룹에 대한 요청.위키피디아에 있는 자기선정 단체들의 문제에 대해 외부 의견을 구한다.믹맥니 (토크) 2009년 6월 19일 (UTC) 14:59 [응답]

새 창

편집 요약과 이것은 무엇인가? 편집 페이지의 버튼은 새 창/탭에서 열어야 하는 것이 아닌가?실수로 클릭해서 일을 다 잃어버렸어!레이와스92^Talk 16:11, 2009년 6월 19일 (UTC)[응답]

아니, 그렇지 않아.대부분의 브라우저(Firefox, Safari 및 Opera 포함, IE 제외)에서 '뒤로' 버튼을 누르면 이 상황에서 작업이 복구된다.대수학자 16:38, 2009년 6월 19일 (UTC)[응답]

응?

섹션을 단순하고 접근하기 쉬운 언어로 바꾸어 놓은 접기 또는 롤다운 하위 섹션.

특히 과학 연구에 지엽적인 주제에 관한 백과사전을 향한 추진력은 자화자찬하는 것처럼 보일 정도로 이해되지 않는 많은 기사들을 렌더링한다.그러한 기사들은 너무 많은 복합 용어로 가득 차 있어서 문장을 읽는 것은 전혀 읽지 않는 것과 같다: 사람은 이전만큼 많이 안다.

모노실라브어를 억지로 먹이는 것은 그것이 현재 가식적인 것처럼 상당히 현학적인 것일 것이 분명하며, 우리는 아마도 자비롭게 이 페이지의 편집자들이 이미 지식 있는 독자들에게 유용하게 쓰이기 위해 이러한 기사들의 균형을 맞추려고 노력하지만 그렇지 않은 사람들을 배제하지는 않을 것이라고 추측할 수도 있다.

그들이 케이크를 먹도록 내버려 두어라.상식적인 언어 체계를 추가함으로써, 기사들은 암호화된 부분이 일치하고 명확한 언어로 세분화되었을 때, 원하는 대로 학술적인 것을 얻을 수 있다.간단한 [+] 접기만으로 충분할 수 있으며, 학습된 편집자들이 일반적인 용어로 주제를 얼마나 잘 이해하는지 설명함으로써 증명할 수 있다. rrzrrr (talk) 23:32, 2009년 6월 12일 (UTC)[응답]

• 메인 스페이스 기사에서는 강하게 반대한다.위키백과:접근성#스크롤링 및 접을 수 있는 섹션은 이유가 있다; 상자 접힘은 오래된 브라우저를 손상시키고 페이지를 인쇄할 수 없게 만들 수 있다.우리는 Knol이 아니고 같은 기사의 동시 버전을 실행해서는 안 된다. 만약 이해할 수 없는 것이 있다면, 해결책은 그것을 이해할 수 있는 버전으로 다시 쓰는 것이어야 한다.간단한 영어를 원한다면, 간단한 영어 위키백과가 갈 곳이고, 간단한 버전이 존재한다면, 인터위키 링크에서 그 링크는 오른쪽에 있을 것이다.– 무지개빛 23:42, 2009년 6월 12일 (UTC)[응답]

• 이리데센트의 의견에 동의하십시오.어떤 기사가 너무 어려워서 읽을 수 없고(이것이 일반적인 문제라는 것에 동의한다!) 어떻게 고쳐야 할지 모르면, 그것을 토크 페이지에 올려라.그것의 편집자들은 그것을 좀 더 접근하기 쉽게 만들고 싶어하고 당신의 건설적인 의견을 중요시 할 것이다.또한 유전학/유전학 동반자 쌍과 같이 기술적으로 상세하고 읽기 쉬운 기사를 보관하는 것이 너무 어렵다고 판단되는 경우를 해결하는 다른 방법이 있다는 점에 유의하십시오.그리고 맨 끝에는 물론 간단한 것이 있다: (많은 도움이 필요한)그러나, Javascript는 이것을 해결하는 방법이 아니다.—JAO • T • C 00:02, 2009년 6월 13일 (UTC)[응답]