Author: kocio
Date: Fri Aug 10 07:18:00 2007
New Revision: 935
Log:
Translation of the "share-management" subsection intro.
Modified:
trunk/pl/ch08.xml
Modified: trunk/pl/ch08.xml
==============================================================================
--- trunk/pl/ch08.xml (original)
+++ trunk/pl/ch08.xml Fri Aug 10 07:18:00 2007
@@ -836,47 +836,47 @@
<sect1 id="share-management">
<title>Rozdzielaj zarówno zadania techniczne jak i kierownicze</title>
-<para>Share the management burden as well as the technical burden of
-running the project. As a project becomes more complex, more and more
-of the work is about managing people and information flow. There is
-no reason not to share that burden, and sharing it does not
-necessarily require a top-down hierarchy either—what happens in
-practice tends to be more of a peer-to-peer network topology than a
-military-style command structure.</para>
-
-<para>Sometimes management roles are formalized, and sometimes they
-happen spontaneously. In the Subversion project, we have a patch
-manager, a translation manager, documentation managers, issue managers
-(albeit unofficial), and a release manager. Some of these roles we
-made a conscious decision to initiate, others just happened by
-themselves; as the project grows, I expect more roles to be added.
-Below we'll examine these roles, and a couple of others, in detail
-(except for release manager, which was already covered in
-<xref linkend="release-manager"/> and
-<xref linkend="release-owner"/><phrase output="printed"> earlier
-in this chapter</phrase>).</para>
-
-<para>As you read the role descriptions, notice that none of them
-requires exclusive control over the domain in question. The issue
-manager does not prevent other people from making changes in the
-issues database, the FAQ manager does not insist on being the only
-person to edit the FAQ, and so on. These roles are all about
-responsibility without monopoly. An important part of each domain
-manager's job is to notice when other people are working in that domain,
-and train them to do the things the way the manager does, so that the
-multiple efforts reinforce rather than conflict. Domain managers
-should also document the processes by which they do their work, so
-that when one leaves, someone else can pick up the slack right
-away.</para>
-
-<para>Sometimes there is a conflict: two or more people want the same
-role. There is no one right way to handle this. You could suggest
-that each volunteer post a proposal (an "application") and have all
-the committers vote on which is best. But this is cumbersome and
-potentially awkward. I find that a better technique is just to ask the
-multiple candidates to settle it among themselves. They usually will,
-and will be more satisfied with the result than if a decision had been
-imposed on them from the outside.</para>
+<para>Rozdzielaj zarówno ciężar zarządzania projektem, jak i ciężar
+zadań technicznych. W miarę jak projekt rośnie, coraz więcej pracy
+wiąże się z zarządzaniem ludźmi i przepływem informacji. Nie ma powodu,
+aby nie rozdzielać tego ciężaru, a w dodatku dzielenie się tym nie
+wymaga tworzenia ścisłej hierarchii - w praktyce kształtuje się raczej
+coś na kształt sieci wzajemnych powiązań, niż struktura dowodzenia w
+stylu wojskowym.</para>
+
+<para>Czasami role kierownicze są sformalizowane, a czasem powstają
+spontanicznie. W projekcie Subversion mamy menedżera łatek, menedżera
+tłumaczeń, menedżerów dokumentacji, menedżerów zgłoszeń (choć jest to
+rola nieoficjalna) oraz menedżera wydań. Niektóre z tych ról zostały
+powołane w wyniku naszej świadomej decyzji, inne po prostu powstały
+samoistnie; spodziewam się, że wraz z rozwojem projektu liczba różnych
+ról będzie rosła. Poniżej znajdują się szczegółowe opisy tych - i kilku
+innych - funkcji (z wyjątkiem zadań menedżera wydań, które przedstawia
+sekcja <xref linkend="release-manager"/> oraz sekcja
+<xref linkend="release-owner"/><phrase output="printed">, znajdująca się
+wcześniej w tym samym rozdziale</phrase>).</para>
+
+<para>Czytając te opisy zwróć uwagę, że żadna z nich nie implikuje
+wyłącznej kontroli w danej sprawie. Istnienie menedżera zgłoszeń nie
+sprawia, że inni ludzie nie mogą dotykać bazy zgłoszeń, menedżer FAQ nie
+upiera się, że ma być jedyną osobą uprawnioną do edycji listy
+najczęściej zadawanych pytań, i tak dalej. Sens tych ról polega na
+określeniu odpowiedzialności bez wprowadzania monopolu. Ważną częścią
+pracy każdego menedżera jest zwracanie uwagi na innych ludzi, którzy
+zajmują się danym zagadnieniem, i przekazywanie im swoich umiejętności
+wykonywania zadań na tym polu, aby raczej wspierać kolektywny wysiłek
+niż wywoływać konflikty. Menedżer powinien także dokumentować proces
+swojej pracy, aby w razie jego odejścia z funkcji ktoś inny mógł od razu
+przejąć cały kram.</para>
+
+<para>Czasem powstaje konflikt, gdy dwie lub więcej osób chce wykonywać
+tę samą rolę. Nie ma jednej metody na załatwienie tego problemu. Możesz
+zasugerować, aby każdy z nich wysłał swoją propozycję ("aplikację") i
+przeprowadzić wśród uczestników projektu głosowanie, która jest
+najlepsza. Ale jest to niewygodne i potencjalnie niezręczne. Moim
+zdaniem lepszą techniką jest poproszenie kandydatów, aby ustalili to
+między sobą. Zwykle tak właśnie zrobią i będą bardziej zadowoleni z
+wyniku, niż gdyby została im ona narzucona z zewnątrz.</para>
<sect2 id="patch-manager">
<title>Menedżer łatek</title>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
