Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 45453 Details for
Bug 73654
[fr] new translation for devrel HB
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
hb-introduction-hierachy.xml
devrel-hb-introduction-hierachy.xml (text/plain), 8.58 KB, created by
Clément VARALDI
on 2004-12-07 11:57:28 UTC
(
hide
)
Description:
hb-introduction-hierachy.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2004-12-07 11:57:28 UTC
Size:
8.58 KB
patch
obsolete
><?xml version='1.0' encoding='UTF-8'?> ><!DOCTYPE sections SYSTEM "/dtd/book.dtd"> > ><!-- Le contenu de ce document est sous licence CC-BY-SA --> ><!-- Voir http://creativecommons.org/licenses/by-sa/1.0 --> > ><sections> > ><date>2004-11-22</date> > ><section> ><title>Introduction</title> ><body> > ><p> >Cette section a pour but d'expliquer la hiérarchie chez les développeurs >Gentoo et de donner aux développeurs un aperçu de comment le management est >structuré au sein du projet Gentoo pour la partie développement. ></p> > ></body> ></section> > ><section> ><title>La structure de management directionnel</title> ><body> > ><p> >L'objectif de la nouvelle structure de management était de résoudre un certain >nombre de problèmes chroniques concernant le management, la coordination et la >communication au sein du projet Gentoo. En particulier, nous n'avions pas bien >défini la structure de management directionnel, et les rendez-vous non officiels >et reguliers qui permettent de communiquer les mises à jour de statuts entre les >développeurs occupant des postes critiques. En règle générale, la plupart de la >communication avait lieu sur IRC et de manière plus sporadique via courrier >électronique. Pratiquement personne, pas même un haut responsable, n'était tenu >de clotûrer les projets en temps et en heure. ></p> > ><p> >à cause de cet état de faits, il était difficile d'établir des objectifs et de >vérifier l'état d'avancement des divers projets. Ce manque de communication et >de coorgination rendait également le management difficile pour les développeurs >à haute responsabilité même pour leurs propres projets. De plus, un autre >problème classique était que nous n'avions pas de rôles bien définis, ni ne >savions l'étendue du pouvoir de prise de décision chez les développeurs à haute >responsabilité. Du coup, de nombreuses personnes ayant une haute responsabilité >ne doutaient jusqu'à savoir si elles avaient l'autorité de gérer leur propres >projets et sous-projets. > >Même si cela n'a jamais été l'intention des personnes à responsabilité, c'était >resultat malheureux et direct du procesus de développement qui manquait de >structure : personne ne savait ce qui se passait, et tout le monde >renvoyait les décisions exécutives à prendre à l'architecte en chef. ></p> > ><p> >Ãvidemment, un plan était nécessaire, pour résoudre rapidement et de manière >définitive ces problèmes, en améliorant la communication, la coordination et >les responsabilités. Les rôles et le pouvoir décisionnel nécessaires avaient >besoin d'être définis pour les développeurs à responsabilités pour qu'ils >puissent avoir un poste clair et une pleine responsabilité dans la gestion de >leurs projets, et qu'ils puissent ainsi s'assurer que leurs projets soient >réalisés dans les délais, et correctement. ></p> > ><p> >La liste suivante donne l'ensemble du système : ></p> > ><ul> > <li><b>Responsables de haut niveau</b> : decident des efforts de > développement à fournir</li> > <li><b>Responsables de sous-projets</b> : font le lien entre les efforts > de développement et leurs équipes respectives</li> > <li><b>Responsables d'équipe</b> : supervisent leur équipe et s'assurent > de leur productivité</li> > <li><b>Développeurs</b> : développe et améliore Gentoo</li> ></ul> > ></body> ></section> > ><section> ><title>Responsables de haut niveau et de sous-projets</title> ><body> > ><p> >Les responsables de haut niveau travaille sur la mise à exécution des aspects >majeurs du développement, comme par exemple la coordination des sorties de >projets Gentoo et sont également responsable de la répartition des efforts de >développement dans les divers projets, et comment Gentoo peut s'améliorer, en >utilisant les retours d'expérience des développeurs et utilisateurs. ></p> > ><p> >Les responsables de sous projets ont pour tache de coordiner les demandes des >responsables haut niveau et de la communauté Gentoo avec leurs équipes. Par >exemple, les nouvelles directives pour l'architecture x86 peuvent concerner les >équipes <e>base-system</e> et <e>kernel</e>, qui devront alors être coordinées >par un responsable de sous projet. ></p> > ><p> >Les responsables de sous projet sont optionnels, tout autant que les >responsables de haut niveau. Cependant dans la plupart des cas votre équipe >finira par travailler sous les recommandations des responsables d'architecture. ></p> ></body> ></section> > ><section> ><title>Responsables d'équipe</title> ><body> ><p> >Les responsables d'équipe sont responsables de l'organisation des développeurs >de leur équipe, et de la coordination des sorties publiques de projets. Ils >doivent également résoudre les problèmes relatifs à leur équipe, et proposer des >améliorations de leurs produits en utilisant les retours d'expérience venant de >la communauté. ></p> > ><p> >Les équipes n'ont pas nécessairement besoin de responsable, et certaines équipes >travaillent avec un système on-fixe-quand-on-reçoit et cette solution donne >parfois de meilleures résultats que s'il y avait un responsable d'équipe. Mais >la décision d'avoir ou non un responsable d'équipe reste une décision que doit >prendre l'équipe elle-même. ></p> > ><p> >La plupart des équipes font partie d'un regroupement d'équipes, qui est >constitué avec pour objectif l'organisation autour d'un effort particulier à >fournir. Vous pouvez vous rapporter à la page sur le projet Metadata pour plus >de détails. ></p> > ></body> ></section> > ><section> ><title>Développeurs</title> ><body> > ><p> >Les développeurs sont responsables du développement de la distribution >ou du projet sur lequel ils sont assignés. Certains développeurs font partie >d'une équipe, d'autres travaillent sur un projet qui n'a pas d'équipe >attribuée, ni de regroupement d'équipe. ></p> > ><p> >Si un développeur a un quelconque problème, il peut en parler avec leur >responsable d'équipe, leur responsable de haut niveau ou peuvent également >envoyer un courrier à une liste de diffusion comme gentoo-dev ou gentoo-core >en demandant des avis ou commentaires sur un point précis. ></p> > ></body> ></section> > ><!-- TODO Attendre que ça soit fixé pour être traduit ^^... > ><section> ><title>Decision making</title> ><body> ><p> >Currently, GLEPs (Gentoo Linux Enhancement Proposals) can be approved >or rejected by the appropriate top-level manager under which the GLEP >falls. If there is no clearly-defined manager under which the GLEP >falls, the GLEP will be voted upon by the Managers and Chief >Architect, and must be approved unanimously. In all cases, a public, >written explanation must be provided detailing why the GLEP was >approved or rejected, either by the manager who approved/rejected it, >or the head of the GLEP sub-project (Grant Goodyear) if the GLEP was >voted upon by the management team. This summary is meant to reflect >the decision that was made by some of the managers at an early manager >meeting. ></p> > ><p> >Currently, there is no formal general voting procedure in place. In >the interim, any item to be voted upon must be approved by "votable" >by the Chief Architect. Before voting takes place, all managers must >have an opportunity to present their ideas before the other managers, >with the general originator(s) of the idea having the opportunity to >present first. After that, the Chief Architect and Managers can >present their ideas, with the Chief Architect having the opportunity >to present last. After this has happened, voting can take place, and >the item will be approved on an unanimous vote. Managers or the Chief >Architect can choose to abstain from voting, and the vote can still >pass with abstainers as long as at least 50% of the members have >voted. The voting must take place at an official managers >meeting. Non-attending managers are allowed to vote via email. The >vote must be officially tallied and posted to the managers list. ></p> > ><p> >The reason for the "Chief Architect approval" clause it to prevent the >voting process from being abused by allowing voting items that make no >sense, such as those that begin with a "Should we continue to," where >a "nay" result would result in a change in existing policy, as well as >preventing managers for requesting that every small decision be voted >upon. We currently have no clear policy to determine what is a >"votable" item, and without this policy there needs to be some method >to determine what is "votable" and what affects some immutable part of >Gentoo. ></p> > ><p> >This section is subject to additional clarification and refinement in >the future, as is the rest of this document. The purpose of this >section is to document our currently-existing procedures rather than >define ideal or "final" procedures. ></p> ></body> ></section> >--> > ></sections>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 73654
:
45425
|
45432
|
45439
|
45441
|
45453
|
45595
|
45596
|
45893
|
45894
|
45895
|
45897
|
45961
|
47829
|
47830
|
47831
|
54040
|
54041
|
54042
|
54043
|
55255
|
55256
|
55257
|
55258
|
55259
|
55261
|
55487
|
55958
|
56147
|
56557