Discussion :

[Fabien Henon]

Oui c'est vrai que dans le cas de projets open sources ça se passe plus de la manière dont tu le dis.

En fait je me basée sur une gestion de projet en entreprise, où là il y a vraiment des postes à respecter.

Je crois que ce sont vraiment 2 choses différentes (gestion de projet open source et gestion de projet en entreprise), donc peut être qu'il serait intéressant d'avoir les 2 points de vues?

[screetch]

Je fais les deux, et la seule reelle difference,

en grande equipe, un role = plusieur personne (parfois une seule, comme un directeur technique, mais souvent plusieurs)
en petite equipe, une personne = plusieurs roles (souvent)

plus l'equipe est grande, plus les roles sont definis et explicites. plus l'equipe est petite, plus les contours sont flous et les roles implicites. C'est dans ce cas que des conflits peuvent apparaitre dans les equipes.


sur un projet reellement open source, il y a aussi des contributeurs anonymes (qui envoient un patch ou un modele 3D de temps en temps) qui sont toujours des artistes ou des programmeurs, et qui doivent apprendre a rester a leur place ;-)

[screetch]

Ah oui, si, important, en entreprise la gestion de projet inclut une gestion des couts et est donc primordiale, contrairement a un projet open source.

[Fabien Henon]

Mais donc d'après ce que tu dis:

en grande equipe, un role = plusieur personne (parfois une seule, comme un directeur technique, mais souvent plusieurs)

on revient donc plus à un système avec des postes bien définis.

En tout cas je fais aussi les 2 et là où je suis c'est bien un système par poste.
Néanmoins je suis totalement d'accord avec ce que tu dis, en petit équipe on a plusieurs rôles par personnes, et en grande équipe on a un rôle pour plusieurs personnes, mais donc dans ce dernier cas je pense qu'on peut bien parlé de poste bien définit.

[Le Barde]

Complètement hors sujet et pratiquement trollesque : un artiste et un graphiste, c'est pas vraiment la même chose.
Je tenais à le dire car j'ai lu à plusieurs reprises que dans un projet il y avait "un programmeur, un artiste et un musicien"...
Ben navré, mais un musicien est un artiste.

De la même manière entre les instrumentistes, les chanteurs et les compositeurs. J'entends souvent dire (car je suis également chef de choeur) : "et vous n'avez pas de musiciens pour vous accompagner ?"

'fin voilà, ça n'a rien à voir avec le reste et ça dévie du sujet, mais je tenais à apporter la nuance

[Fabien Henon]

C'est exact, désolé d'avoir fait l'erreur, c'est une mauvaise habitude de ma part, je vais éditer mon poste.

[Le Barde]

-> Désolé pour ma sécheresse je devais être mal luné


En tous cas, cela commence à évoluer ; on pourrait commencer à faire notre nouvelle rubrique.

J'ai quelques questions qu'on peut ajouter à la FAQ (si qqn peut répondre d'ailleurs) :
- Qu'est-ce que le "Game Loop" ?
- Pourquoi utiliser un langage de script ?
- Quel langage de script utiliser dans son jeu vidéo ?

[ash.ice.loky]

Attention.
On va arriver à des problèmes sans réponse avec ce genre de questions.

Quel langage ?
Quel script ?
Quelle API ?
...

Regardez le thread JAVA et les jeux vidéo.

[Fabien Henon]

-> Désolé pour ma sécheresse je devais être mal luné

Pas de problème, je ne l'ai pas mal pris

Attention.
On va arriver à des problèmes sans réponse avec ce genre de questions.

Quel langage ?
Quel script ?
Quelle API ?
...

Regardez le thread JAVA et les jeux vidéo.

Est-ce vraiment un problème? Je veux dire: en fait le but est de guider le lecteur sans forcément lui dire "C'est ça le mieux alors tu fais comme ça" (c'est un peu exagéré je sais, mais c'est pour l'exemple)
Enfin en tout cas quand je lis une FAQ je suis dans cet état d'esprit, je ne m'attends pas à avoir la réponse universelle mais des conseils (enfin après ça dépend des questions bien sûr)