Author: kocio Date: Wed Aug 8 08:20:39 2007 New Revision: 902 Log: Translation of text to the half of the "users-to-volunteers" subsection.
Modified: trunk/pl/ch08.xml Modified: trunk/pl/ch08.xml ============================================================================== --- trunk/pl/ch08.xml (original) +++ trunk/pl/ch08.xml Wed Aug 8 08:20:39 2007 @@ -609,8 +609,8 @@ <para>Niektóre projekty idą w tym jeszcze dalej, wymagając aby <emphasis>każdej</emphasis> poprawce lub nowej funkcji towarzyszył nowy test. To, czy jest to dobry pomysł, czy nie, zależy od kilku czynników: -od natury danego oprogramowania, organizacji zespołu oraz trudności -pisania nowych testów. Projekt CVS (<ulink +od natury danego oprogramowania, organizacji zespołu oraz od stopnia +trudności pisania nowych testów. Projekt CVS (<ulink url="http://www.cvshome.org/"/>) ma takie wymogi od dawna. Teoretycznie jest to dobra zasada, ponieważ CVS to system kontroli wersji i z tego powodu stara się unikać ryzyka zamazania lub niewłaściwego potraktowania @@ -667,93 +667,98 @@ <sect2 id="users-to-volunteers"> <title>Traktuj każdego użytkownika jako potencjalnego ochotnika</title> -<para>Each interaction with a user is an opportunity to get a new -volunteer. When a user takes the time to post to one of the project's -mailing lists, or to file a bug report, he has already tagged himself -as having more potential for involvement than most users (from whom -the project will never hear at all). Follow up on that potential: if -he described a bug, thank him for the report and ask him if he wants -to try fixing it. If he wrote to say that an important question was -missing from the FAQ, or that the program's documentation was -deficient in some way, then freely acknowledge the problem (assuming -it really exists) and ask if he's interested in writing the missing -material himself. Naturally, much of the time the user will demur. -But it doesn't cost much to ask, and every time you do, it reminds the -other listeners in that forum that getting involved in the project is -something anyone can do.</para> - -<para>Don't limit your goals to acquiring new developers and -documentation writers. For example, even training people to write -good bug reports pays off in the long run, if you don't spend -<emphasis>too</emphasis> much time per person, and if they go on -to submit more bug reports in the future—which they are more -likely to do if they got a constructive reaction to their first -report. A constructive reaction need not be a fix for the bug, -although that's always the ideal; it can also be a solicitation for -more information, or even just a confirmation that the behavior -<emphasis>is</emphasis> a bug. People want to be listened to. -Secondarily, they want their bugs fixed. You may not always be able -to give them the latter in a timely fashion, but you (or rather, the -project as a whole) can give them the former.</para> - -<para>A corollary of this is that developers should not express anger -at people who file well-intended but vague bug reports. This is one -of my personal pet peeves; I see developers do it all the time on -various open source mailing lists, and the harm it does is palpable. -Some hapless newbie will post a useless report:</para> +<para>Każdy kontakt z użytkownikiem jest okazją do pozyskania nowego +ochotnika. Kiedy użytkownik poświęca czas na napisanie wiadomości do +jednej z list dyskusyjnych projektu lub na wypełnienie raportu błędu, to +automatycznie sygnalizuje, że ma większy potencjał zaangażowania niż +większość innych użytkowników (o których projekt nigdy nawet się nie +dowie). Wykorzystaj ten potencjał: jeśli opisał błąd, to podziękuj mu za +zgłoszenie i zapytaj, czy chciałby spróbować go naprawić. Jeśli dał +znać, że w FAQ brakuje czegoś istotnego, lub że dokumentacja programu +jest w jakiś sposób niekompletna, to potwierdź istnienie problemu (jeśli +on naprawdę występuje) i zapytaj, czy interesuje go samodzielne +dopisanie brakujących materiałów. Oczywiście w większości wypadków +użytkownik odmówi. Ale pytanie nie kosztuje wiele, a za każdym razem +kiedy to robisz, przypominasz innym osobom na forum, że każdy może się +zaangażować w projekt.</para> + +<para>Nie ograniczaj swoich celów tylko do pozyskiwania nowych +programistów i twórców dokumentacji. Na przykład samo uczenie ludzi jak +prawidłowo wypełniać zgłoszenia błędów na dłuższą metę się opłaci, o ile +tylko nie poświęcisz <emphasis>zbyt wiele</emphasis> czasu każdej takiej +osobie, i o ile zamierzają oni przesyłać w przyszłości kolejne +zgłoszenia - co jest bardziej prawdopodobne jeżeli otrzymali +konstruktywną reakcję po swoim pierwszym zgłoszeniu. Konstruktywna +reakcja nie musi polegać na naprawieniu błędu, choć jest to zawsze +mile widziane; może to być prośba o więcej informacji lub nawet +potwierdzenie, że opisane działanie faktycznie <emphasis>jest</emphasis> +błędne. Ludzie chcą być wysłuchani. W następnej kolejności chcą pozbyć +się błędu. Nie zawsze będziesz w stanie zapewnić im na czas to drugie, +ale możesz (ty, lub raczej projekt jako całość) dać im to pierwsze. +</para> + +<para>Wynika z tego, że uczestnicy projektu nie powinni wyrażać złości +wobec osób, które wypełniły raporty błędów z jak najlepszymi intencjami, +ale kiepsko. To jeden z moich ulubionych irytujących drobiazgów; widzę +jak deweloperzy robią to bez przerwy na rozmaitych listach dyskusyjnych +otwartych projektów, a szkody jakie w ten sposób czynią są namacalne. +Pechowy nowicjusz wysyła bezwartościowe zgłoszenie:</para> <blockquote> - <para>Hi, I can't get Scanley to run. Every time I start it up, it - just errors. Is anyone else seeing this problem?</para> + <para>Cześć, nie mogę zmusić Scanleya do działania. Za każdym razem, + gdy go uruchamiam, pokazuje mi błąd. Czy ktoś jeszcze ma ten sam + problem?</para> </blockquote> -<para>Some developer—who has seen this kind of report a -thousand times, and hasn't stopped to think that the newbie has -not—will respond like this:</para> +<para>Deweloper - który widział takie zgłoszenia tysiące razy i nie +zastanowił się nad tym, że nowicjusz ich dotąd nie widział - odpowiada w +ten sposób:</para> <blockquote> - <para>What are we supposed to do with so little information? - Sheesh. Give us at least some details, like the version of - Scanley, your operating system, and the error.</para> + <para>I co niby mamy zrobić z taką skromną informacją? Rany. Podaj + nam przynajmniej jakieś szczegóły, takie jak wersję Scanleya, jaki + masz system operacyjny i co to jest za błąd.</para> </blockquote> -<para>This developer has failed to see things from the user's point of -view, and also failed to consider the effect such a reaction might -have on all the <emphasis>other</emphasis> people watching the -exchange. Naturally a user who has no programming experience, and no -prior experience reporting bugs, will not know how to write a bug -report. What is the right way to handle such a person? Educate them! -And do it in such a way that they come back for more:</para> +<para>Ten programista nie spojrzał na problem z punktu widzenia +użytkownika, a także nie zastanowił się nad efektem jaki ta reakcja +wywoła na <emphasis>innych</emphasis> osobach przyglądających się +tej wymianie zdań. Naturalnie użytkownik bez wcześniejszych doświadczeń +z programowaniem i zgłaszaniem błędów nie wie jak się to robić. Jak +należy prawidłowo postępować wobec takich osób? Nauczyć je! I zrobić to +w taki sposób, żeby chciały wrócić po więcej:</para> <blockquote> - <para>Sorry you're having trouble. We'll need more information in - order to figure out what's happening here. Please tell us the - version of Scanley, your operating system, and the exact text of - the error. The very best thing you can do is send a transcript - showing the exact commands you ran, and the output they produced. - See http://www.scanley.org/how_to_report_a_bug.html for more.</para> + <para>Przykro nam, że miałeś taki problem. Potrzebujemy więcej + informacji aby zorientować się co się stało. Podaj nam swoją wersję + Scanleya, jaki masz system operacyjny i dokładną treść komunikatu o + błędzie. Najlepiej jeśli możesz nam wysłać dokładny zapis poleceń, + jakie uruchamiałeś, i tego, co one wypisywały. Więcej informacji na + ten temat znajdziesz pod adresem + http://www.scanley.org/how_to_report_a_bug.html.</para> </blockquote> -<para>This way of responding is far more effective at -extracting the needed information from the user, because it is written -to the user's point of view. First, it expresses sympathy: -<emphasis>You had a problem; we feel your pain</emphasis>. (This is -not necessary in every bug report response; it depends on the severity -of the problem and how upset the user seemed.) Second, instead of -belittling her for not knowing how to report a bug, it tells her how, -and in enough detail to be actually useful—for example, many -users don't realize that "show us the error" means "show us the exact -text of the error, with no omissions or abridgements." The first time -you work with such a user, you need to be specific about that. -Finally, it offers a pointer to much more detailed and complete -instructions for reporting bugs. If you have successfully engaged -with the user, she will often take the time to read that document and -do what it says. This means, of course, that you have to have the -document prepared in advance. It should give clear instructions about -what kind of information your development team wants to see in every -bug report. Ideally, it should also evolve over time in response to -the particular sorts of omissions and misreports users tend to make -for your project.</para> +<para>Taki rodzaj odpowiedzi jest znacznie bardziej efektywny przy +zdobywaniu potrzebnych informacji, ponieważ jest ona pisana z punktu +widzenia użytkownika. Po pierwsze, wyraża współczucie: <emphasis>Masz +problem; czujemy twój ból</emphasis>. (Nie w każdej odpowiedzi na +zgłoszenie jest to konieczne; zależy to od wagi problemu i od tego, jak +bardzo użytkownik jest zdenerwowany.) Po drugie, zamiast lekceważyć go +za brak wiedzy o zgłaszaniu błędów, instruuje jak ma to robić tak +szczegółowo, aby rzeczywiście było to użyteczne - na przykład wielu +użytkowników nie zdaje sobie sprawy z tego, że "pokaż nam błąd" oznacza +"podaj nam dokładny komunikat błędu, bez pomijania i skracania tekstu." +Kiedy kontaktujesz się z takim użytkownikiem po raz pierwszy, musisz to +wyraźnie powiedzieć. Wreszcie otrzymuje też odnośnik do znacznie +bardziej szczegółowej i kompletnej instrukcji zgłaszania błędów. Jeśli +nawiązałeś odpowiedni kontakt z użytkownikiem, to zwykle poświęci on +czas na przeczytanie tego dokumentu i wykonanie tego, co jest tam +napisane. Oczywiście oznacza to, że taki dokument musi zostać wcześniej +przygotowany. Powinien on dawać zrozumiałe instrukcje na temat tego, +jakich informacji oczekuje zespół w każdym zgłoszeniu. W idealnym +przypadku taki dokument powinien z czasem ewoluować w odpowiedzi na +konkretne typy braków i błędów w zgłoszeniach, które użytkownicy +nadsyłają do twojego projektu.</para> <para>The Subversion project's bug reporting instructions are a fairly standard example of the form (see <xref _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
