''04-03-03 현재'' [http://quality.kde.org/develop/howto/ http://quality.kde.org/develop/howto/] [[TableOfContents]] == 소개 == 간단히 말해서 KDE 품질팀의 과제는 응용프로그램의 미결 부분을 찾아내고 그것을 완결 짓는 것입니다. 이 팀의 목적은 상업적인 조직의 프로젝트 관리자의 목적과 비슷합니다. 팀원에게 주로 요구되는 것은 응용프로그램 개발의 여러 영역들과 상호작용하는 것이며, 이렇게 하여 배우는 것이 많을 것입니다. 하지만 이것은 여러분이 이 영역들을 모두 알아야 한다는 것을 의미하지 않습니다. 여러분은 그 응용프로그램의 어떤 특정한 부분에 초점을 맞춰도 됩니다. 예를 들어, 사용자들의 질문에 답하기, 관련 기사 쓰기, 문서화하기, 미술작업 하기 등 원하는 무엇이든 다 됩니다! 부족한 분야를 찾아서 일을 시작하기만 하십시오! 시간이 있고 뭔가 새로운 것을 해 볼 마음이 있는 것 같다면, 이리로 와서 그 특정한 과제에 대해 구할 수 있는 정보를 확인해 보십시오. 이 지침의 목적은 여러분을 돕기 위해 실제적인 모든 정보를 잘 조직하는 것입니다. 이 지침의 다른 판은 [http://wiki.kdenews.org/tiki-index.php?page=KDE+Quality+Team+HOWTO KDE 위키 사이트(wiki.kdenews.org)](http://wiki.kdenews.org/tiki-index.php?page=KDE+Quality+Team+HOWTO)에서 구할 수 있습니다. 오류를 발견했거나 이 지침을 더 낫게 만들 방법을 알고 있다면, 주저하지 말고 위키나 CVS 판을 고치십시오. 이 두 판들은 계속해서 동기화되고 병합됩니다. == 문서화 == 문서화를 하는 것은 여러분이 선택한 응용프로그램과 KDE 프로젝트를 돕기 시작하는 훌륭한 방법입니다. 돕기로 결심했다면, 여러분의 글은 KDE 번역 팀들이 담당하고 있는 모든 언어로 번역될 것이며, 이것은 수천(수백만?) 명의 사람들이 그들의 데스크톱과 응용프로그램을 더 잘 이해하도록 돕는 일이 될 것입니다. 적당한 영어 실력이 있고 어떤 응용프로그램에 대해 잘 안다면 누구나 도울 수 있습니다. 응용프로그램의 문서를 고치는 것은 다음의 것들을 포함합니다. 즉, 여러분 지역의 KDE CVS 작업 폴더에 가서, 작업하고자 하는 파일들을 찾고, 그것을 열어서, 개선된 내용을 추가하고, 고친 것을 그 프로젝트로 보내는 것입니다. 이렇게 하는 방법을 빨리 배우기 위해서는, [http://quality.kde.org/develop/cvsguide/index.php Why Build and Maintain a KDE CVS Working Folder?](http://quality.kde.org/develop/cvsguide/index.php) 지침을 확인해 주십시오. 어떤 응용프로그램에 대해 문서화하는 것에는 도움말 문서(help document)와 문맥 도움말(context help)이 포함됩니다. 문맥 도움말이란, 문맥 도움말 단축키(보통 쉬프트 + F1)를 누르고 어떤 위짓(widget)을 클릭했을 때 보이는, 짧은 설명이 들어있는 신속한 팝업(pop up)을 말합니다. 이 도움말은 그 위짓의 객관적인 기능에 한정되지만, 그것이 바로 사용자가 알고 싶어 하는 것이어서, 전체 도움말 시스템을 열 필요가 없게 해 줄 수도 있습니다. 도움말 문서(또는 어떤 응용프로그램을 위한 도움말 문서들을 모아 놓은 응용프로그램 매뉴얼)는 응용프로그램에 대해 더욱 포괄적인 도움을 제공하며, 세부적인 정보, 예제, 다른 문서로 연결, 메뉴 명령, 대화창(dialog), 갈무리 화면(screenshot) 등에 대한 정보가 포함될 수 있습니다. 이 문서는 여러 다른 언어로 번역되기 때문에 도움말 문서에 들어 있는 갈무리 화면, 메뉴 항목, 위짓, 대화창 등을 참조한 것들은 모두 실제 응용프로그램과 갈무리 화면들과 동기화되어 번역되어야 합니다. 이것에 역점을 두어, 문서의 형태나 도움말 문서를 만드는 데 사용되는 도구들은 다국어 문서에 맞게 설계됩니다. === 문맥 도움말: whatsthis === 문맥 도움말은 대화창이나 위짓과 떨어질 수 없습니다. 이들이 바로 문맥 도움말의 목표 대상이기 때문입니다. 사실, 문맥 도움말을 작성하기 위해, 여러분은 프로그래밍이나 프로그래밍 도구를 만져 봐야 합니다. 실제로, 문맥 도움말은 위짓의 '''속성(property)'''입니다. 객체지향 프로그래밍에서 속성은 여러 가지 값을 가지며, 그 값에 따라 다르게 행동할 수 있습니다. Qt/KDE 프로그래밍에서 이 속성의 이름은 "whatsthis"이며, 그 값은 문맥 도움말에 표시될 텍스트입니다. 다행히, 이 과제는 보통 그렇게 어렵지 않습니다. 사용자 인터페이스 설계를 다루는 좋은 도구들이 있기 때문입니다. 더 좋게는, 여러분이 여기에서 얻은 지식을 나중에 일반적인 사용자 인터페이스를 다룰 때에도 사용하게 될 것입니다. Qt의 틀(framework)을 사용하면 (Qt는 KDE 기술의 기본), 코드와 사용자 인터페이스를 분리하는 것이 가능합니다. 여기에는 기본적으로 두 가지 경우가 있습니다. 사용자 인터페이스는 응용프로그램의 일반적인 코드(보통 .cpp 파일)나, Qt Designer 파일(XML 문서인 .ui 파일)로 작성됩니다. 두 번째 경우가 처음 시작하기에 가장 좋습니다. 작업이 더 간단하기 때문입니다. Qt Designer가 설치되지 않았다면, Qt의 devel 패키지나, (여러분의 배포판의 패키지가 더 세부적으로 나뉘어 있다면) Qt Designer 패키지를 설치하면 됩니다. Qt Designer를 사용하여 whatsthis를 작성하거나 소스 코드로 직접 작업하는 것에 대한 세부적인 지침은, 아론 J. 세이고(Aaron J. Seigo)의 [http://urbanlizard.com/~aseigo/whatsthis_tutorial/ WhatsThis Tutorial]에서 찾을 수 있습니다. === 응용프로그램 도움말이나 매뉴얼 === KDE 도움말 시스템은 닥북(docbook) 형식에 기초합니다. 이 문서 형식과 관련 도구들을 통해 전체 프로젝트를 위한 문서화 결과물을 번역하거나 유지하는 일이 더 쉬워집니다. 이 문서 형식은 OASIS 그룹에서 기술 문서들을 염두에 두고 특별히 설계되었으며, [http://www.w3.org/XML/ XML] 기반으로 상세화되어 있습니다. 각 모듈에 대한 문서화 결과물은 doc 폴더에서 찾을 수 있습니다. 닥북 형식으로 문서를 작성하는 것을 전적으로 권장합니다. 하지만 원한다면, 문서화 결과물 개선 작업을 먼저 시작하고, 닥북 형식은 나중에 배워도 됩니다. 그런데 그렇게 할 경우, 텍스트 전용 (ASCII) 형식을 사용해 주십시오. 이렇게 하면 문서 작업자들이 나중에 그것을 닥북으로 변환할 때 더 쉽게 할 수 있을 것입니다. 여러분이 선택한 응용프로그램의 문서화 결과물이 이미 있다면, 무에서부터 시작하지 말고 그것을 개선해 보십시오. 모든 명령과 주요 창의 구성, 요컨대 인터페이스의 모든 사항들을 설명하십시오. 무엇에 대해 쓸 것인가에 대한 더 완전한 목록은 [http://i18n.kde.org/doc/index-script.php KDE 문서화 팀 웹 사이트]의 [http://i18n.kde.org/doc/questionnaire.php Questions You Should Answer When You Document KDE](http://i18n.kde.org/doc/questionnaire.php) 페이지에 있습니다. 사용자에게 친근하도록 하고, 선택한 응용프로그램을 사용하는 대중에게 쓰도록 하십시오. 여러분의 문장을 미국식 영어에 맞게 교정보는 것도 잊지 마십시오. 이를 위한 요령이나 일관성 규칙은 [http://i18n.kde.org/doc/styleguide/index.html The KDE Style Guide]에서 찾을 수 있습니다. 이 지침은 간략하고, 단순하며, 필수 사항들이 있습니다. 그 목적은 문서화 결과물의 품질에 균일한 수준을 유지하는 것입니다. 닥북 형식으로 글을 쓰는 것에 대해, 출발 지점으로 추천하는 것은 [http://opensource.bureau-cornavin.com/crash-course/ The Crash Course to Docbook]입니다. 여기에서는 처음 시작할 때 필요한 기본 지식을 얻을 수 있습니다. KDE 고유의 것들에 대해서는, [http://i18n.kde.org/doc/markup/index.html The KDE Markup Guide]를 참고해 주십시오. 처음으로 문서를 작성하는 데 대한 지침입니다. 이러한 과정에서 도움을 얻기 위해, 여러분은 여러 [http://i18n.kde.org/doc/tools.php 도구들]을 사용할 수 있습니다. XML 문서를 작성하기 위해서는 Kate를 추천합니다. 이것은 여러분이 kdeaddons 모듈에서 XML 플러그인을 설치했다면 특별히 도움이 될 것입니다. 설치 후에 활성화하는 것을 잊지 마십시오. Kate를 열어서 Settings 메뉴를 클릭하고, Configure Kate... 항목을 선택하십시오. 왼편의 트리(tree) 보기 안의 application/plugins 아이콘을 클릭하고, Kate XML Completion과 Kate XML Validation 박스를 체크하십시오. 이렇게 하면 Kate를 사용할 때 XML 메뉴를 볼 수 있게 될 것입니다. 닥북 문서를 편집할 때, XML 메뉴를 클릭하고 나서, 메타 DTD를 할당하고 KDE 닥북 DTD를 선택하면, Kate를 강력한 닥북 편집기로 변신시킬 수 있습니다. == 사용자 인터페이스 == 사용자 인터페이스는 매우 넓은 주제이며, 매우 주관적이기도 합니다. 어떤 사람에게는 명백한 것이 다른 사람에게는 불합리하거나, 그 반대인 경우가 있기 때문입니다. 그러므로 함부로 가정하지 말고, 여러분의 논리를 단계적으로 진술하면서 분명하게 논의하십시오. 여기에 대해 토론할 때는 객관적인 추론과 좋은 분별력을 주요 도구로서 사용해야 합니다. 사용자 인터페이스를 신속하게 분석해 내는 것은 쉽지만, 사람들에게 그 인터페이스를 바꾸도록 설득하는 것은 어렵습니다. KDE 지침(guideline)들, 경쟁 프로그램과 운영체제의 분석, 여러 책에서 찾은 일반적인 설계 원리들, 사용자의 점검이나 개인적인 (경험적(anecdotal)) 반응 등에서 얻은 정보를 종합하여 설득력 있는 좋은 분석을 했다면, 많은 것을 얻을 수 있습니다. 이것은 자발적인 프로젝트이므로, 모든 사람이 여러분에게 동의했어도, 누군가는 그것을 구현해야 합니다. 여기에서 좋은 점은 Qt/KDE의 틀(Framework)에서는 비개발자라도 구현할 만한 것이 있다는 것입니다. [http://mail.kde.org/mailman/listinfo/kde-usability KDE Usability 메일링리스트]는 매우 활발하며, 여러분의 생각에 대해 토론할 좋은 장소입니다. === 시작하기 전에: 지침들과 유용한 문서들 === 다른 KDE 프로그램들과 단축키가 일관되는지 검증하거나, 단순한 논리적 분석을 하거나, 사용편이성(usability)에 대한 경험적 반응이나 의견을 제시하는 등의 간단한 과제들을 수행하기 위해서라면, 여기에 열거된 문서들을 읽을 필요는 없습니다. 더 깊이 있게 공부하기 위해서라면 더 많은 지식이 요구되겠지만, 필요한 모든 정보는 쉽게 얻을 수 있을 것입니다. 사용편이성에 대한 기본적인 KDE 문서들로는, [http://developer.kde.org/documentation/standards/kde/style/basics/index.html KDE User Interface Guidelines (design standards)]와 [http://developer.kde.org/documentation/design/ui/index.html KDE User Interface Guidelines (design principles)]가 있습니다. 첫 번째 문서는 KDE 응용프로그램들을 위한 표준(standard)들을 폭넓게 모아 놓은 것입니다. 다시 말해서, 실제적인 관례(convention)들과 즉시 사용하기 위한 규칙(rule)들입니다. 두 번째 문서는 사용자 인터페이스를 설계하는 데에 유용한 일반적인 원리들을 모아 놓은 것이며, 공부를 시작하기에 좋은 곳입니다. 이 매혹적인 주제에 대한 정보를 얻을 수 있는 책과 그 밖의 좋은 출처들이 있으며, 상당 수가 온라인에 있습니다. [http://usability.kde.org/ KDE 사용편이성 웹 사이트]는 사용편이성에 대한 훌륭한 정보들이 모여 있습니다. 여기에는 윈도(Windows), 애플(Apple), 그놈(GNOME) 등의 사용자 인터페이스 지침들, 사용편이성 강의 노트, 그 주제에 대한 온라인 책까지 포함되어 있습니다. === 분석 === 여러분은 KDE 사용자 인터페이스 지침들이나 다른 사용편이성 자료들을 사용하여 매우 유용한 분석을 수행할 수 있습니다. 어디까지 손을 대야 할 것인지에 대해 다음의 것들을 제안합니다. '''[http://developer.kde.org/documentation/standards/kde/style/basics/index.html KDE User Interface Guidelines (design standards)](http://developer.kde.org/documentation/standards/kde/style/basics/index.html) 준수''': 여기에는 대화창의 최대 크기, 응용프로그램 종료와 문서 닫기, 대문자 사용 규칙 등에 대한 표준이 정해져 있습니다. 이 문서는 사용자 인터페이스 검토를 시작하는 데에 매우 좋습니다. 일반적인 응용프로그램의 주축이 되는 측면들인 대화창, 메뉴, 도구막대, 단축키(shortcut), 신속키(accelerator), 끌어 놓기(drag and drop), 상태막대 등을 모두 다루고 있기 때문입니다. KDE 응용프로그램은 최소한 이 표준들을 따라야 하며, 이하의 내용에서는 그것을 당연한 것으로 가정합니다. '''단축키의 일관성(coherency)과 접근성(accessibility)''': 어떤 응용프로그램을 배우는 데에 요구되는 시간을 줄이기 위해 단축키는, 우선, 다른 KDE 응용프로그램들이 이미 사용하는 도식(scheme)을 최대한 가깝게 따라야 하며, 다음으로, 유사한 응용프로그램들이 사용하는 도식을 따라야 합니다. 좋은 예를 하나 들면, 컹커러(Konqueror)가 모질라(Mozilla)나 인터넷 익스플로러(Internet Explorer)와 같은 기본 단축키들을 사용하게 한 것입니다. KDE에서 널리 사용되는 어떤 단축키가 마음에 들지 않는다면, (무작정) 여러분의 응용프로그램을 다르게 만드는 대신, 다른 사람들이 여러분의 접근 방식으로 바꾸도록 설득해 보십시오. 또 다른 좋은 목표 대상은, 가장 중요한 기능들에 대해 두 개를 초과하는 키를 동시에 사용하는 것을 최대한 줄이는 것입니다. 장애가 있는 사람들은 여러 갈래로 나뉘는 명령들이나 동시에 많은 키를 누르는 것에 어려움을 겪을 수 있습니다. 자주 사용되는 동작에 단축키가 빠져 있지 않은지 검증하고, 거기에 어떤 키를 사용해야 하는지 연구해 보십시오. 일관성이 주된 우선순위이므로, 다른 KDE나 유사한 응용프로그램에서 어떻게 하고 있는지 보십시오. '''대화창 검토''': 기본 규칙은, 사용자가 현재 과제와 상관없는 것들에 대해 읽거나, 원하지 않는 것들에 대해 결정을 내리도록 요구하지 말아야 한다는 것입니다. 사용자는 일을 쉽고, 빠르고, 최소한의 데이터 입력만으로 처리할 수 있어야 합니다. 검토할 만한 사항들로는, 대화창 내용이 명백한지, 위짓들이 불필요한 정보는 피하면서 논리적인 순서대로 표시되는지, 정보가 관련성의 순서대로 제시되는지, 단순한 대화창이든 복잡한 다중 탭(multi-tab) 대화창이든 관련된 선택사항(option)들이 한 데 모여 있는지 등입니다. [http://developer.kde.org/documentation/design/ui/index.html KDE User Interface Guidelines (design principles)]을 지침으로 사용하여, 이 원리들이 준수되고 있는지 확인할 수 있을 것입니다. 새로운 선택사항들이 계속 추가되며 낡은 것들은 제거되고 있으므로, 설정(Configuration) 대화창들은 계속하여 재설계되고 있습니다. 이 대화창들은 검토를 위한 명백한 목표 대상이 됩니다. 개선된 것들의 예로는 [http://usability.kde.org/activity/completed/panelconfig.php 패널 설정 대화창 재설계]나 시계 애플릿 설정 대화창 등이 있습니다. 대화창을 개선하는 데 도움이 되는 강력한 도구가 있습니다. 바로 [http://www.trolltech.com/products/qt/designer.html Qt Designer]입니다. Qt의 틀(framework)을 사용할 때, 대화창을 만들기 위해 둘 중 하나를 선택할 수 있습니다. 즉, 일반 응용프로그램 코드를 작성하는 텍스트 편집기(보통 .cpp 파일)나 Qt Designer(.ui 파일)입니다. 여러분이 검토 중인 대화창이 Qt Designer를 사용하여 개발되었다면, 여러분이 프로그래밍에 대해 지식이 별로 없어도, 여러분 스스로 그것을 재설계할 수 있습니다. [http://quality.kde.org/develop/cvsguide/index.php 그 응용프로그램의 CVS 폴더](http://quality.kde.org/develop/cvsguide/index.php) 안에서 모든 .ui 파일들을 찾으십시오. 그것들을 열어서 (더 빠른 ui 파일 뷰어도 사용 가능) 원하는 대화창인지 확인하십시오. 여러분이 분석하고 있는 대화창을 찾을 수 없다면, 그것은 손으로 직접 코딩했거나 KDE 라이브러리(KDE CVS에서 kdelibs 모듈)에서 공유되는 대화창이기 때문일 수 있습니다. 그 대화창이 코드 안에 손으로 직접 작성되어 있다 해도 (.ui 파일 없음), 여러분은 Qt Designer를 사용하여 개념의 증명(proof of concept), 즉 실물모형(mockup)을 만들어서, 다른 사람들에게 여러분의 생각을 보여 주고 여러분의 제안이 중요하다는 것을 분명히 진술할 수 있습니다. 트롤텍(Trolltech)은 Qt Designer 매뉴얼의 일부로서, [http://doc.trolltech.com/3.3/designer-manual-4.html Qt Designer를 사용하여 대화창을 만드는 방법에 대한 작은 지침]을 제공합니다. 여러분은 이것을 보고 간단한 대화창이나 그 실물모형을 만들 수 있을 것입니다. === 사용편이성 검사 === 실험적인 검사(empirical test)의 한 가지 예는 그 소프트웨어에 대한 여러분 자신의 경험입니다. 여기에 더 요구되는 것은, 그것을 주관적 의견에서, 사람들이 참고하여 작업할 수 있는 객관적 사실로 변환하는 것입니다. 다음과 같이 간단한 사용자 검사를 수행하는 것을 제안해 볼 수 있습니다. 여러분 자신이 사용자가 되어, 수행할 과제를 정하고, 그 과정을 문서화하고, 발견한 문제를 기록하고, 해결책을 제시하는 것입니다. 여러분이 내린 결론은 거의 모두 그 응용프로그램을 개선하는 데 이러저러한 방법으로 사용될 수 있습니다. 그런데 그 검사가 더 많은 사람들에게 확대될 수 있다면, 그것은 더욱 더 유용해질 수 있습니다. 여러분은 일상적인 사용자가 아닐 수 있기 때문입니다. 즉, 여러분은 지적인 호기심이 더 많고, 습관이 다르고, 설계상 결점들에 대처할 수 있는 능력이 더 많습니다. 증명해 볼까요? 여러분이 이 글을 읽고 있다는 사실이 바로 그 증거입니다. 다른 사용자들과 사용편이성(usability) 검사를 수행하는 것은 쉬운 일이며, 여러분의 응용프로그램에 대해 주요한 개선을 이뤄낼 수 있을 것입니다. 여러분의 응용프로그램에 대해 수행할 가장 중요한 과제들을 선택하고, 그 과제들을 수행할 친구들을 찾으십시오. 선택된 사람들은 그 응용프로그램이 목표 대상으로 하는 사용자의 특성에 맞아야 하므로, 사람들의 배경에 대한 몇 가지 질문 문항을 만드십시오. 사용편이성 검사를 수행하는 방법에 대한 더 많은 정보와 요령은, 간략하고 유용한 [http://www.infodesign.com.au/usabilityresources/evaluation/usabilitytesting.asp Infodesign 사용편이성 검사 페이지](http://www.infodesign.com.au/usabilityresources/evaluation/usabilitytesting.asp)에서 찾을 수 있습니다. ([http://www.infodesign.com.au/ftp/UsabilityTesting.pdf PDF 형식]도 있습니다.) 초시계를 사용하여 각 과제를 수행하는 데 걸린 시간을 기록하고, 발견된 모든 문제점들을 적어 놓으십시오. 데이터를 표로 정리하고 결론과 제안을 도출해 보십시오. 이런 유형의 검사에서 값으로 따질 수 없는 통찰력과 정보를 얻을 것입니다. KDE에 대한 현장 검사(field test)의 한 가지 예로서 [http://www.relevantive.de/Linux_e.html KDE 사용편이성에 대한 Relevantive 보고서](http://www.relevantive.de/Linux_e.html)가 있습니다. == 오류 및 요청사항 보고 관리 == 개발자와 사용자 사이의 주요한 의사소통 도구이자, 주요한 품질 도구가 되는 것이 KDE 오류 및 요청사항 데이터베이스입니다. 이 데이터베이스는 오류와 요청사항을 추적하기 위한 도구인 [http://www.bugzilla.org/about.html 버그질라(Bugzilla)]를 사용하여 구현된 것입니다. 버그질라는 원래 모질라 웹 브라우저를 위해 개발되었습니다. [http://bugs.kde.org/ Bugs.kde.org]가 KDE에서 구현한 버그질라의 웹 앞단(front end)이며, 오류를 관리할 때 가야 하는 주요한 곳입니다. 물론, 다른 앞단들도 있습니다. KBugBugster는 kdesdk 모듈이나 전자우편 인터페이스에서, 의견 첨부, 오류 상태 변경 등을 위해 사용됩니다. 많은 오류 보고들이 매일, 특히 배포가 이뤄진 직후에 제출됩니다. 개발자들이 처리하기에는 양이 너무 많으므로, 미해결된 보고의 양이 시간이 지남에 따라 증가합니다. 게다가 과거의 오류 보고들은 정기적으로 다시 확인하여 현재 판에도 계속 적용되고 있는지 살펴야 합니다. 오류 데이터베이스를 검토함으로써, 오류를 관리하는 것 외에도, 가장 필요로 하는 기능과 가장 치명적인 오류들에 대한 통찰을 얻을 수 있습니다. 이렇게 하여 여러분도 그런 오류들을 찾아낼 수 있으며, 개발자들은 실제로 오류를 고치거나, KDE에 새로운 기능을 추가하기 위해 시간을 보낼 수 있게 합니다. 사용자들이 오류와 요청사항에 대한 토론을 항상 KDE 오류 추적 시스템에서 하게 하십시오. 이런 방식으로 하면 논점들이 잊혀지지 않을 것이기 때문입니다. 그 사항이 조금 더 논쟁적인 것이라면, 그 [http://www.kde.org/mailinglists/ 응용프로그램의 메일링리스트](http://www.kde.org/mailinglists/)나 [http://mail.kde.org/mailman/listinfo/kde-usability KDE 사용편이성 메일링리스트]에서 토론을 시작하는 것이 현명하겠지만, 그들에게 먼저 [http://bugs.kde.org/wizard.cgi 그 오류를 제출]하는 것부터 시작하라고 하십시오. [http://bugs.kde.org/quicksearch.html 그와 유사한 오류나 요청사항을 검색]하면서 답이나 통찰을 얻을 수 있을 것이기 때문입니다. === 시작하기 전에 === 우선, bugs.kde.org에 계정이 없다면 [http://bugs.kde.org/createaccount.cgi 계정을 개설]하십시오. 이 데이터베이스는 오류나 요청사항만이 아니라, 관련 토론, 갈무리 화면(screenshot), 패치(patch) 등도 저장되어 있어서, 아주 완벽한 정보의 출처가 되었습니다. [http://bugs.kde.org/quicksearch.html 단순 검색 양식](http://bugs.kde.org/quicksearch.html), [http://bugs.kde.org/query.cgi 고급 검색 양식](http://bugs.kde.org/query.cgi), [http://bugs.kde.org/wizard.cgi 신규 요청사항/버그 마법사](http://bugs.kde.org/wizard.cgi) 등 [http://bugs.kde.org/ bugs.kde.org]에 있는 모든 것을 사용해 봄으로써, KDE 버그질라의 여러 기능에 익숙해지십시오. KBugBugster도 유용하지만, 유연성은 조금 떨어집니다. 필수적으로 알고 있어야 하는 몇 가지 관례적인 이름들이 있습니다. 예를 들어, 오류 상태(UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED and CLOSED), 해결(FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME), 심각성 등입니다. (참고: KDE에는 오류가 확실히 종결되었음을 거듭 확인하는 QA(품질보증) 부서가 없으므로, CLOSED 상태는 사용되지 않습니다.) 처음에는 다른 사람이 제출한 오류 보고들에 대해 의견을 제시하는 것만 할 수 있을 것입니다. 그 응용프로그램과 KDE 버그질라 시스템에 대해 더 지식을 쌓은 후에야, 오류 보고 내용들을 확증하고 검증할 수 없는 것들은 종결하는 권리를 요청할 수 있습니다. 여러분은, 그 오류들이 아직 유효한지 확인하기 위해 KDE_x_x_BRANCH(주 배포(major release) 후 처음 몇 달 동안)나 HEAD CVS 분기(branch)와 같은 최근의 KDE를 설치할 필요가 있습니다. 그러고 나서, 그것들을 확증하고, 검증할 수 없는 경우 종결할 수 있습니다. KDE의 갱신된 판을 유지하는 방법에 대해 더 많은 정보를 얻기 위해서는 [http://quality.kde.org/develop/cvsguide/index.php Maintaining your own updated KDE version 지침]을 참고하십시오. 또한 디버그 정보가 같이 컴파일 된 KDE 판을 사용하는 것도 중요합니다. 디버그 정보가 같이 컴파일된 KDE 바이너리들은 크기는 더 크고 실행 속도는 더 느리지만, 응용프로그램이 작동을 멈추는 것에 대해 개발자들에게 값으로 따질 수 없는 정보를 제공해 줍니다. 이것은 소스 코드의 어느 부분에서 작동이 멈췄는지, 때로는 왜 그런지도 알 수 있게 해 줍니다. 응용프로그램이 작동을 멈출 때마다 KDE 작동 중단 처리기(crash handler)가 나타납니다. 여러분은 FIXME 탭을 클릭하여 오류보고(bugreport)에 추가하기 위한 역추적 정보를 찾을 수 있고, 거기에서 텍스트를 복사하여 오류보고에 붙일 수 있습니다. === 보고 관리하기 === 여러분의 응용프로그램에 대한 지식은 오류를 선별하는 주된 도구가 됩니다. 여러분은 그 프로그램을 잘 이해하기 위해 개발자가 될 필요는 없다는 사실을 알게 될 것입니다. 오류 보고를 읽고, 그것에 대해 의견을 쓰고, 문서를 작성하고, 그 응용프로그램의 사용자 인터페이스에 대해 작업을 하는 것만으로도 충분합니다. 오류 상태를 변경할 수 있게 허가해 달라고 요청할 적절한 시기는 여러분이 준비가 되었다고 느낄 때입니다. 개발자들은 그들과 함께 작업할 사람이 생기는 것을 기뻐할 것이며, 이것은 결국 여러분이 그 부문에서 훌륭한 공헌자(contributor)로서 신망을 얻는 것입니다. 개발자들은 이렇게 계속 여러분의 활동을 지켜볼 것입니다. 아래의 과제 중 어떤 것은 이러한 허가가 필요합니다. 하지만 여러분은 오류 보고에 대해 여러분의 의견을 진술하고 개발자들이 적절한 행동을 취하게 하는 것으로써 항상 일을 시작할 수 있습니다. 이 일을 시작하는 좋은 방법은 버그들이 여전히 유효한지 확인하는 것입니다. 일단 보고자들을 믿으십시오. 어떤 새로운 오류를 재현할 수 없다면, 우선 그 상황에 대한 정보를 더 요청하고 나서, 그것을 종결하거나 종결하도록 요청할 것인지 생각해 보십시오. 그 오류는 여러 요인들이 합쳐져서 튀어나올 수도 있고, CVS에서는 고쳐졌는데 안정 분기(stable branch)에서는 그렇지 않을 수도 있습니다. (만약 그렇다면, 오류 보고에서 역포팅(backport)을 요청하십시오. 그렇게 할 수 없는 상황이라면, 개발자들이 그렇다고 말해 줄 것입니다.) 역추적 정보(backtrace), 부가적으로 관찰된 것들, 그 불완전한 동작을 (더 잘) 재현하는 방법 등 여러분이 제공할 수 있는 부가적인 정보를 추가하거나, 아니면 단순히 어느 날짜의 CVS 판에서 그 오류가 발생하는지 추가하십시오. 여러분이 그 오류들을 재현할 수 있다면, 오류보고(bugreport)에서 그렇다고 말하거나 그 상태를 NEW로 변경하십시오. 프로그램이 멈췄다면(hang), 여러분은 그 프로세스에 "kill -SIGSEGV 프로세스id"를 하여 역추적 정보를 얻을 수 있습니다. 그 보고가 적당한 제품(product) 및 구성요소(component) 분류에 제출되었는지도 확인하십시오. KDE는 모듈화가 잘 되어 있으며, 코드를 상당히 많이 재사용하므로, 때로는 개발자들조차도 어느 구성요소에 오류가 있는지 파악하지 못합니다. 따라서 주의를 기울여야 합니다. 그 보고가 그 구성요소의 현재 소유자가 아닌 어떤 다른 개발자에게 이미 할당된 것이 아니라면, '''보고를 옮길 때 "Reassign bug to owner of selected component"를 선택'''해야 합니다. 어떤 보고가 유지관리자나 활동하는 개발자가 한 사람도 없는 분류에 제출되었는데, 여러분이 어떤 개발자가 그 코드에 책임이 있거나 작업을 했는지 안다면 (소스를 보거나 kde-cvs 메일링리스트를 읽는 것이 도움이 될 수 있음), 여러분은 오류 보고를 그 사람에게 직접 할당해도 됩니다. 어떤 보고가 이미 종결됐거나 미결된 다른 보고에서 기술된 에러를 기술하고 있지 않은지 확인하십시오. 그런 보고는 앞선 보고에 대한 참조를 붙여서 DUPLICATE로 해결하십시오. 똑같은 보고가 한 번 이상 제출되지 않았는지도 확인하십시오. 이렇게 중복된 것들은 (번호가 가장 낮은 것을 제외하고) DUPLICATE가 아니라 INVALID로 종결해 주십시오. 그렇게 하지 않으면 그것들이 자주 보고되는 오류 통계에 잘못 나타나게 되기 때문입니다. 제목에 요약이 잘 되어 있는지 확인하십시오. 즉, 기능을 요청하는 제목이 "기능 요청"으로만 되어 있으면, 보고 목록을 훑어볼 때 도움이 되지 않습니다. 패치(patch)가 제공되어 있으면 제목에 "(patch)"를 추가하십시오. 브라우저의 오류들은 대개 검사하기 매우 쉬우며, 그 양도 많습니다. 이전의 안정 배포판에서는 페이지가 옳게 표시되었다면 제목에 "(regression)"을 추가하십시오. 에러가 생긴 사이트를 제목에 적으면 중복되는 것을 쉽게 찾을 수 있으므로 바람직합니다. 게코(Gecko) 기반의 브라우저와 오페라(Opera)를 함께 설치하면 웹 페이지가 어떻게 보여야 하는지 알 수 있을 것입니다. 불완전하게 표시되는 웹 페이지는 간략화한(stripped down) 시험사례(testcase)를 만들어 보십시오. 오류 보고에 시험사례가 첨부되어 있으면, 제목에 "(testcase)"를 추가하십시오. 어떤 웹 페이지가 더 이상 존재하지 않거나 분명히 재작성되었고, 제공된 시험사례도 없다면, 그 보고는 WONTFIX로 종결하십시오. 보고자나 의견 제시자가 어떤 페이지가 사파리(Safari)에서는 잘 동작한다고 언급했다면, 그것을 제목에도 써 주는 것이 개발자들에게 도움이 될 것입니다. 심각성(severity)이 적절한지 확인하고, 그것이 여러분의 의견과 다르면, 오류보고에 그렇게 진술하십시오. 유지관리자가 그 심각성을 변경하게 하십시오. 이것은 그들이 중대한 문제를 고치도록 일깨우는 데 사용될 것입니다. 참고: 보고들을 이동하는 데에 "Change Several Bugs at Once" 기능을 사용하지 마십시오. 이동된 보고들을 확증하는 버그질라의 기능에 오류가 있습니다. == 전달과 선전 == 공개 소스 제품은 자발적인 작업의 결과이며, 그 성공의 핵심은 새로운 지원자들을 끌어들이는 능력에 있습니다. 널리 사용된다는 것은 대개 공헌자(contributor), 개발자, 문서작업자, 번역자, 개인이나 기업이나 정부의 일부를 그것에 공헌하도록 끌어들일 가능성이 더 커진다는 것을 뜻합니다. 여러분의 응용프로그램을 선전하기 위해, 여러분은 뉴스 사이트 기사나, 흥미로운 기능이나 요령을 보여 주는 지침서를 쓰거나, (특정한 과제를 수행하는 방법을 설명하는 작은 지침서인) 하우투(HOWTO)를 쓸 수도 있고, [http://quality.kde.org/develop/cvsguide/index.php CVS 판]에 등장한 미래의 기능을 미리 소개하는 글을 기고할 수도 있습니다. 하지만 여러분의 응용프로그램이 널리 보급되었다고 해서, 여러분이 자동적으로 베타 소프트웨어를 시험하고 오류 보고를 제출할 사람들, 그리고 결국 개발자, 품질팀, 번역자, 문서작업자로 합류할 수 있는 사람들을 끌어들이게 될 것이라는 것을 뜻하지는 않습니다. 첫 단계는, 신참자들이 접근하기 쉽게 되고, 새로 온 사람들을 교육하도록 노력하는 것입니다. 예를 들어, 메일링리스트의 사용자들에게 정보를 얻을 수 있는 올바른 출처를 친절하게 알려 주는 것이 이 방향으로 가는 한 걸음입니다. 메일링리스트는 새로운 공헌자들을 얻을 수 있는 원천이며, 튼튼한 커뮤니티를 형성한다는 것은 사용자들에게 그들이 사용하는 소프트웨어를 개선하기 위해 활동할 수 있음을 가르쳐 주는 것을 뜻합니다. 공헌에 대한 장벽을 낮추면 더 많은 사람들이 이 첫 단계로 걸어가도록 유인할 수 있습니다. [http://kde-look.org/ Kde-look.org](http://kde-look.org/) 웹 사이트는 사람들이 신속하게 자신의 작업 결과를 올리고 반응을 얻을 수 있게 함으로써 이것을 더 용이하게 합니다. 어떤 새로운 공헌자들은 반응과 좋은 정보와 신뢰를 얻음으로써 더 멀리 나아가게 될 것입니다. [http://wiki.kdenews.org/ KDE 위키 사이트(wiki.kdenews.org)]는 사람들의 토론과 제안들이 형식을 갖추게 하는 좋은 도구입니다. 때때로 개발자들은 문제들에 대해 사용자들과 토론하는 것을 꺼립니다. 대부분의 의견이나 제안들이 미숙한 수준이기 때문이며, 문제들(오류와 요청사항)을 추적하는 도구가 이미 있기 때문이며 ([http://bugs.kde.org/ KDE 버그질라 구현 사이트]), 그들이 기능을 구현하거나 오류를 고치는 일에 바쁠 수 있기 때문입니다. KDE 품질팀이 이 간격을 메워서, 사용자들의 반응을 의미 있는 제안으로 조직할 수 있습니다. === 사용자들과 상호작용하기 === 리눅스는 이제 주류로 인정되기까지 성장했습니다. 이것은 기회이면서 도전이기도 합니다. 도전이라고 한 것은, 배경이 다른, 더욱 더 많은 사용자들과 대화해야 하기 때문입니다. 이들은 소프트웨어에 값을 치르고, 소프트웨어 회사가 모든 일을 해 주고, 무엇이 잘못 되었을 때 불만을 토로하는 것에 익숙합니다. 이들 중 많은 사람들은 도움조차 되지 않을 것이며, 공개 소스 개발의 제한점을 이해하려 하지도 않겠지만, 이것은 처음 행동으로 자연스러운 것입니다. 기회라고 한 것은, 새로 몰려온 사람들을 이용하여 KDE를 어떤 형태로든 개선할 수 있다는 것입니다. 또한 사용자들은 때때로, 혼동되거나 부적절한 방식이긴 해도, 가치 있는 반응을 내놓습니다. 이 사용자와 더 깊이 대화해 보면 그 문제가 명료해져서, 새로운 오류나 요청사항 보고를 할 수 있게 되거나, 기존의 오류나 요청 사항 보고들에 가치 있는 의견을 달 수 있게 됩니다. 고함 소리를 유용한 정보로 바꿔놓는 셈입니다. 분명히, 이것의 가장 좋은 방법은 사용자에게 그 보고를 스스로 제출하도록 가르쳐 주는 것입니다. 오류를 제출하는 것은 KDE 공헌자가 되는 첫 단계이며, 매우 가치 있는 단계입니다. [http://bugs.kde.org/ Bugs.kde.org](http://bugs.kde.org/)(KDE의 오류와 요청사항 데이터베이스)에 오는 모든 새로운 사용자들은 작은 승리의 결과라고 할 수 있습니다. 이 사용자들은 '''자유 소프트웨어가 무엇인지 이해하기 시작'''한 것이기 때문입니다. 사용자들과 대화하는 주된 통로는 여러분의 응용프로그램을 위한 [http://www.kde.org/mailinglists/#user 사용자 메일링리스트](http://www.kde.org/mailinglists/#user)나, 혹시 그것이 없다면, [http://wiki.kldp.org/cache/google/https://mail.kde.org/mailman/listinfo/kde KDE 일반 사용자 메일링리스트]나, [http://wiki.kldp.org/cache/google/https://mail.kde.org/mailman/listinfo/kde-linux KDE 리눅스 메일링리스트]입니다. 이 메일링리스트들에 가입할 것을 권합니다. 사용자의 반응을 얻을 수 있는 다른 출처는 [http://kde-forum.org/ KDE 포럼]과 [http://wiki.kdenews.org/ KDE 위키 사이트]입니다. 이 통로들은 또한 KDE에 공헌할 만한 사람들을 찾는 좋은 장소이기도 합니다. 그들이 관심을 보인다면, 이 지침과 KDE 품질팀 메일링리스트를 알려 주십시오. 여러분의 응용프로그램의 웹 페이지를 계속 갱신하면서, 아주 복잡한 일을 수행하는 방법에 대한 하우투(HOWTO)들, 자주 묻는 질문들(FAQ)에 대한 답변들, 기능과 성능에 대한 요약, 최근 뉴스와 기사 등을 제공하는 것도 도움이 됩니다. 이것은 그 응용프로그램이 전문적인 느낌이 들게 하며, 이 응용프로그램이 활발하게 유지되고 있고, 사용자에게 성실히 봉사하고 있음을 암시합니다. 여러분이 갱신한 문서가 KDE 배포 일정에 맞추지 못했다면, 그것을 그 응용프로그램 웹 사이트에 올리십시오. [http://www.kde.org/media/readme.php KDE.org의 새로운 얼개(layout)에 맞춰 웹 페이지를 작성하는 방법에 대한 지도서(tutorial)]도 있습니다. === 응용프로그램 선전하기 === 리눅스는 데스크톱 보급의 측면에서는 아직 유년기에 있습니다. 많은 사람들이 여러분의 응용프로그램을 전혀 써 보지 않았을 것이므로, 시장에서 경쟁하기 위해서는, 그것을 선전하는 것이 중요합니다. 선전은 근본적인 것입니다. 이것을 통해 여러분의 제품이 선택할 만한 것으로 여겨질 가능성을 높일 수 있을 뿐만 아니라, 위험스러운 선입견이나 신화를 피할 수 있기 때문입니다. 여러분의 응용프로그램을 선전하는 가장 좋은 방법 중 하나는 뉴스 사이트에 기사를 제출하는 것입니다. 우선 명백히 선택할 만한 것은 [http://dot.kde.org/ KDE 뉴스 사이트 (The Dot)]이겠지만, 기사를 보낼 수 있는 다른 사이트들도 있습니다. 그 기사를 한 뉴스 사이트에 제출하고 나서 그 링크를 [http://dot.kde.org/addPostingForm The Dot]에 제출하는 것이 더욱 유용합니다. 사람들은 독점기사 자료를 더 중요하게 생각하기 때문입니다. 여러분의 기사는 지도서(tutorial)나 (어떤 일들을 수행하는 방법을, 더 좋게는 그림을 곁들여서, 설명하는) 해보기(walkthrough) 문서, (곧 배포될 것의 기능을 보여 주는) 미리보기(preview) 문서, ([http://quality.kde.org/develop/howto/howtoui.php#uitests 사용자 인터페이스 시험](http://quality.kde.org/develop/howto/howtoui.php#uitests), 벤치마크 등의) 시험, 검토(review) 문서 등이 될 수 있습니다. 상세한 정보와 갈무리 화면(screenshot)을 제공하고, 비슷한 소프트웨어가 있다면 비교하십시오. 여러분이 기사로 쓸 거리는 항상 있습니다. 여러분은 기사를 보낼 수도 있고 뉴스(링크)를 보낼 수도 있습니다. 기사는 여러분이 최초로 작성한 자료이고, 뉴스는 여러분의 응용프로그램이나 KDE가 널리 알려지는 데에 좋겠다고 생각되는 이야기들에 대한 링크입니다. [http://osnews.com/ OSNews]에는 [http://osnews.com/story.php?news_id=168 OSNews에 기사를 제출하는 방법](http://osnews.com/story.php?news_id=168)에 대한 지침이 있으며, 여기도 시작하기에 매우 좋은 곳입니다. 이곳은 내놓는 기사에 대해 매우 자유롭기 때문입니다. 적당한 뉴스를 제출할 다른 곳들로는, [http://slashdot.org/submit.pl 슬래시닷(Slashdot)](http://slashdot.org/submit.pl), [http://www.newsforge.com/submit.pl 뉴스포지(Newsforge)](http://www.newsforge.com/submit.pl), [http://linuxtoday.com/contribute.php3 리눅스투데이(LinuxToday)](http://linuxtoday.com/contribute.php3), 리눅스 위클리 뉴스(Linux Weekly News: [mailto:lwn_at_lwn.net)lwn_at_lwn.net)] (여기에서도 기사를 보낼 수 있음) 등이 있습니다. === 다른 품질팀 사람들과 상호작용하기 === 때때로 여러분이나 KDE 품질팀의 다른 사람들은 처음으로 무슨 일을 하기 위해 도움이 필요할 것이며, 또는 어떤 변화를 제안하거나, 기사, 하우투(HOWTO), 웹 페이지 등을 올리거나, 새로운 문서를 작성하기 전에 동료가 검토해 주면 좋겠다고 생각할 것입니다. 우리가 일을 할 때 서로 돕자는 것이 주된 생각입니다. 아무도 모든 분야에 대해 전문가가 될 수 없으며, KDE 품질팀의 활동 영역은 매우 넓기 때문입니다. 그래서 여러분에게 어떤 궁금한 것이 생겨서, 그 대략적인 생각을 올리고 응답을 받고 싶다면, 주된 도구는 [http://https//mail.kde.org/mailman/listinfo/kde-quality/ KDE 품질팀 메일링리스트](http://https//mail.kde.org/mailman/listinfo/kde-quality/)가 될 것입니다. 이러한 상호작용의 한 가지 사례가 바로 (여러분이 보고 있는) 이 지침입니다. 이 지침은 처음에 카를로스 웨우스(Carlos Woelz)가 썼는데, 품질팀 사람들의 경험과 요령을 모아서 자주 갱신할 생각으로 시작한 것입니다. 이 지침의 사본은 언제나 [http://wiki.kdenews.org/tiki-index.php?page=KDE+Quality+Team+HOWTO KDE 위키 사이트]에서 수정할 수 있을 것이며, [http://quality.kde.org/develop/howto/howtopromo.php 이 웹 사이트]는 규칙적인 시간 간격을 두고 위키와 동기화될 것입니다. 여러분의 경험이 중요하므로, 실수를 발견하면 고쳐 주시고, 여러분이 얻은 그 외의 요령이나 정보들을 추가해 주십시오. 이 프로젝트의 목표 중 하나는 새로운 공헌자들을 위한 단계별 지침을 마련하는 것입니다. 여러분이 아직 다루지 않은 어떤 일을 수행하면서 밟은 과정들에 대해 문서를 만들면, 여러분은 새로운 단계를 하나 더 쉽게 추가하게 될 것입니다.