silentdrift.net

Je pense qu'il serait bon d'établir clairement une sorte de philosophie que les membres de notre groupe seraient d'accord de suivre, afin d'écarter toute possibilité de malentendus. Du moins, il serait bon que chacun exprime sa vision des choses.
La mienne est un mélange des propositions suivantes. J'en ferais une fois la synthèse.

J'ai quelques propositions à faire pour des sources d'inspirations.


Pour la diffusion de nos "produits":

La philosophie du "logiciel libre" (GNU) (transposé au règles pour jdr bien sûr)

OGL (fortes ressemblances avec la licence GNU, mais certains points diffèrent; cette fois, pas besoin de transposer au monde du jdr, c'est spécifiquement fait pour, et c'est pas limité à Donj' ou au système d20 (qui est basé sur l'OGL))


Pour notre méthode de développement:

(A adapter au jdr bien sûr)

Les 13 règles des méthodes de développement du logiciel libre

1. Chaque développement d’un projet sérieux commence par « gratter » une démangeaison du développeur.
Il est inutile de commencer le développement d’un projet si on n’en voit pas réellement l’utilité, c’est-à-dire s’il ne résout pas un problème auquel est confronté le programmeur. D’ailleurs la plupart des projets qui ont échoués sont de projets qui ne répondaient pas à un véritable besoin.

2. Les bons programmeurs savent ce qu’il faut écrire. Les programmeurs géniaux savent ce qu’il faut réécrire et ce qu’il faut réutiliser.
Il existe dans les bibliothèques de logiciel libre des millions de lignes de codes résolvant une très grande palette de problèmes. Il n’est pas toujours nécessaire de réinventer la roue. Parfois il est beaucoup plus judicieux de réutiliser ce qui a déjà été écrit. Il arrive cependant que le programmeur remarque une amélioration possible du code déjà écrit et dans ce cas il faut aussi savoir reconnaître que sa propre solution est réellement meilleure.

3. Dans votre planification, prévoyez de jeter au moins une version complète de projet. Cela vous arrivera de toute façon.
Aussi soigneusement que soit faite la spécification d’un programme et de son cahier de charges, il arrivera toujours un moment où il ne sera plus possible de rajouter une fonction qui avait été oubliée et qui ne peut pas entrer dans la structure. La seule manière vraiment efficace de se rendre compte de se genre d’oublie est de réaliser une première version qui devra être considérée comme prototype et ensuite recommencer le développement quand cela est devenu nécessaire.

4. Si vous avez la bonne attitude, les problèmes intéressants vont finir par vous trouver.

5. Quand vous perdez votre intérêt pour un programme, votre dernière obligation est de la transmettre à un successeur compétent.
Dans quantité de projets de logiciel libre, le responsable du projet change au cours de la vie du projet. Cela est dû au fait que la plupart des logiciels libres sont développés bénévolement et que les personnes ayant initié le projet ont changé de profession, d’employeur ou tout simplement de priorité. La plupart du temps, le nouveau responsable du projet est quelqu’un faisant un usage intensif du produit en question.

6. Traiter vos collaborateurs comme des co-développeurs est le moyen le plus simple d’augmenter rapidement la qualité de votre code et de le débuguer efficacement.
Tout utilisateur du produit est susceptible de formuler des suggestions intéressantes et intelligentes et cela même si l’utilisateur en question n’est pas un programmeur.

7. Release early. Release often.
Et soyez à l’écoute de vos clients.

8. Etant donné un ensemble suffisamment grand de bêta-testeur et de co-développeur, tous les problèmes seront localisés rapidement et les corrections seront évidentes pour un des développeurs.

9. Une structure de données intelligente et un code stupide fonctionne toujours mieux que l’inverse.

10. Si vous considérez vos bêtas-testeurs comme votre ressource la plus précieuse, en retour ils feront ce qui est nécessaire pour devenir votre ressource la plus précieuse.

11. La deuxième chose la plus importante à avoir après de bonnes idées et de reconnaître les bonnes idées de vos utilisateurs.

12. Souvent la solution la plus originale et la plus innovante à un problème est de réaliser que la compréhension initiale du problème n’était pas bonne.

13. La perfection dans la conception n’est pas atteinte quand il n’y a plus rien à ajouter mais quand il n’y a plus rien à retirer.


Tiré de ce document.


Vous êtes bien sûr invités à exprimer votre avis par rapport à cette idée!

Entierement d'accord pour se fixer une philosophie, et je pense meme que quand on se sera mis d'accord sur quelque chose, ca vaudrait bien le coup de le mettre en post-it (il doit bien y avoir un truc pour faire ca), histoire qu'il soit toujours visible au cas pour les nouveaux arrivants (il y en aura forcement tot ou tard).

Personnellement, j'avais pour XG1+ dans l'idee de le faire comme ca : n'importe qui peut en profiter, se faire ses modifications dans son coin, rajouter des trucs et surtout en faire profiter tout le monde. Avec une restriction : interdiction de s'approprier le projet.
En bref : chacun fait ce qu'il veut tant qu'il ne tente pas de cacher qui est l'auteur de depart (tant qu'a faire si un jour je colle ce truc sur le net, j'aimerais autant qu'on sache que c'est mon bebe a moi :P) ET qu'il n'essaie pas de controler ce qu'en font les autres.

D'un autre cote, l'aspect "logiciel libre" s'applique plutot a un projet, un jeu. Ce qu'on fera des discussions qu'on aura ici est difficilement controlable.
Neanmoins je peux proposer ca : le jour ou mes machins seront prets, je me ferai une page perso. Et a ce moment la, il pourrait etre interessant de s'organiser en un vrai beau groupe. La premiere etape sera evidemment de coller des liens vers les pages des autres membres. Ensuite, on pourrait adopter une sorte de convention pour tous les projets faits dans le cadre de ce groupe (du style "JdR libre"). A priori, nous avons deja un forum pour nous retrouver donc pas de souci pour trouver un endroit :D

Mais je pense qu'on devrait aussi ne pas hesiter a causer de projets sortant du cadre du groupe (donc "pas libres") ensemble, juste parce que j'aime bien filer un coup de main quand je peux.

Ah oui, une derniere proposition :
Toute idee balancee sur ce forum peut etre pillee sans vergogne et reutilisee par les autres membres. Je crois sincerement que nous avons ici des personnes honnetes et qu'on aura pas de "vol", mais ce serait quand meme une bonne idee de prevenir si on va utiliser une idee d'un autre dans un de ses projets persos.

Bon, ben c'est tout ce qui me passe par la tete pour le moment.
Reste a savoir comment on va bosser... Eh ben je pense que ca depend pas mal de chacun.
A mon avis, histoire de s'y retrouver, la premiere etape est de coller le nom du projet dans le titre du thread quand il s'agit d'un thread specifique a un projet. Je vais d'ailleurs aller renommer les miens...

Points intéressants, à méditer.

Je vais laisser les autres s'exprimer avant de continuer plus loin le débat.

J'ai mis à jour le premier thread.

moi ça me va, tant que l'honneteté est là et qu'un type ne vient pas tout racler et dire que c'est lui qui en est l'auteur alors qu'il n'en est rien. 8-)

Il faudra effectivement trouver un moyen de garantir la reconnaissance pour le travail fourni par chaque personne.
Dans l'OGL, il faut ajouter dans les copyrights le copyright de tous les documents auxquels on fait allusion et/ou desquels on reprend des idées.


Comment feriez vous pour adapter la méthodologie du logiciel libre (cf. premier post) au jdr?
Je ne pense pas que ce soit faisable en traduisant "logiciel libre" par "jdr" dans chaque phrase.
Je pense que certains points peuvent être regroupés (p.ex. 2 et 11).

Mais je vais déjà laisser le temps à tout le monde de prendre connaissance de ce "manifeste" :)

Ensuite, je referais un nouveau thread "sticky" avec le document cible pour le jdr.

Les 13 règles des méthodes de développement du logiciel libre
Ma première tentative d'adaptation :

1. On ne développe que des jeux auxquels on aurait envie de jouer, que ce soit pour un délire, un ou deux scénars ou en campagne. Pour qu'on ait envie d'y jouer, il faut évidemment que le jeu apporte quelque chose par rapport aux autres, qu'il s'agisse d'un meilleur système de règles et/ou d'un background original. Bien entendu, "meilleur" et "original" sont subjectifs et on s'intéresse ici au point de vue du développeur !

2. Les bons auteurs savent ce qu’il faut écrire. Les auteurs géniaux savent ce qu’il faut réécrire et ce qu’il faut réutiliser. Il ne faut avoir aucun scrupule à reconnaître les bonnes idées des autres, et à les réutiliser tant que c'est possible et approprié au jeu.

3. Dans votre planification, prévoyez de jeter au moins une version complète de projet. Cela vous arrivera de toute façon.

Bah, celle-là on peut l'oublier, vu que de toute façon on est pas pressés par le temps ! Les versions "prototypes", c'est ce qu'on poste sur le site et la "version complète jetable", ce sera la première version testable du système...
Eventuellement, je remplacerais par :
3. Attendez-vous à retravailler plusieurs fois chaque point de règle et de background !

4. Si vous avez la bonne attitude, les problèmes intéressants vont finir par vous trouver.

5. Quand vous perdez votre intérêt pour un jeu, votre dernière obligation est de le transmettre à un successeur compétent.

6. Traiter vos collaborateurs comme des co-auteurs est le moyen le plus simple d’augmenter rapidement la qualité de votre jeu et de le l'améliorer efficacement. Il ne faut pas avoir peur d'adopter les idées et autres règles maisons des joueurs (tant qu'ils sont d'accord).

7. Postez tôt. Postez souvent. Et soyez à l'écoute de tous ceux qui participent au projet (même/surtout les joueurs) !

8. Etant donné un ensemble suffisamment grand de bêta-testeurs et de co-développeur, tous les problèmes seront localisés rapidement et les corrections seront évidentes pour un des développeurs.
Attention quand-même : le JDR est une activité créative et soumise à une certaine subjectivité, et trop d'auteurs peut induire le risque de "dispersion", c'est-à-dire nuire à la cohérence de l'ensemble.

9. Des bases bien faites et des spécificités nazes valent toujours mieux que l'inverse !
C'était tellement évident qu'on y pensait pas !
NB pour la trad' : En fait, dans le processus d'écriture d'un programme, la structure de donnée se fait normalement avant le code (c'est un peu le "niveau d'avant"). Parfois c'est fait en cours... et c'est souvent prendre le risque de faire un truc boiteux !
(Je savais bien qu'il y avait du potentiel pour une traduction ! :wink: )

10. Si vous considérez vos bêtas-testeurs comme votre ressource la plus précieuse, en retour ils feront ce qui est nécessaire pour devenir votre ressource la plus précieuse.

11. La deuxième chose la plus importante à avoir après de bonnes idées et de reconnaître les bonnes idées de vos joueurs.

12. Souvent la solution la plus originale et la plus innovante à un problème est de réaliser que la compréhension initiale du problème n’était pas bonne.
Si le système comprend beaucoup de règles spécifiques à des cas particuliers, c'est probablement parce qu'il faut changer la base, c'est-à-dire la(les) règle(s) générale(s).
(J'ai pas d'idée pour le moment pour le côté "développement de background").

13. La perfection dans la conception n’est pas atteinte quand il n’y a plus rien à ajouter mais quand il n’y a plus rien à retirer.

EDIT: proposé une traduction du point numéro 9 !

Yeah ! Juste pour dire que ma proposition de traduction pour le "manifeste du JdR libre" depuis le monde de la programmation est pas loin d'une première version !
J'ai vraiment trop de temps sur les bras :roll:

L'Open Gaming n'a qu'à bien se tenir ! :wink:

Accroche-toi à tes bretelles, Wizards !! :lol: :D :lol:

Je me rends compte que je n'arrive pas à tenir ta cadence effrénée Ancalagon, mais saches que j'apprécie énormément ta motivation!

J'ai hâte de lire ce manifeste!

Ben il est juste au-dessus (c'est le truc des 13 règles).
Puis pour la cadence, vous en faites pas. Tant que je poste, ça veut dire que je suis motivé. Et quand je suis en panne, il suffit souvent d'une toute petite question (même si elle paraît toute bête) pour me relancer !

Ah! Je pensais que l'allusion "(...) pas loin d'une première version (...)" présageait une version en cours d'élaboration.

Voyons voir si j'ai qqch à rajouter au manifeste (ou à enlever :D ) (en fait, le manifeste original a des points presque redondants, ou que je ne comprends pas vraiment, mtnt que j'y repense.)
Je reprends point par point TON manifeste:

1. Très bien, une bonne base pour donner le ton ;)

2. Essentielle!

3b. Un rappel utile (3a n'a effectivement pas vraiment de sens)

4. ??? (je dois avoir une très bonne attitude =D)

5. Oui et non, en fin de compte, je préfère ne pas obliger qui que ce soit de faire quoi que ce soit. Si mon intérêt pour mon projet disparaît, mais que le projet est tellement bien qu'il y a des fans, c'est eux qui vont venir me demander de continuer. Si personne ne veut entendre parler de mon projet, je ne vais pas faire chier qqn avec ce fardeau =D

6. A mettre tout près du point 2 je pense, puisque c'est un peu le même esprit.

7. J'aime bien, pasque ça représente particulièrement notre méthode de travail (enfin de toi et moi en tout cas).

8. Ta remarque est tellement vraie quand je vois ce qui se passe sur le projet de Casanabo. Enfin mtnt il a pris les choses en main et ça déménage sec! J'arrive plus à suivre.
Je vais voir s'il n'y a pas qqch à changer au point 8, ça fait un peu trop clinique.

9. Effectivement, dans la série "C'était tellement évident qu'on y pensait pas!"... Mais est-ce que ça s'applique vraiment au jdr?

10. Presk la même chose que 6.

11. Presque la même chose que 2. (et comme on pourrait presque regrouper 6 et 2 ...)

12. A mettre dans la série "C'était tellement évident qu'on y pensait pas!" :)

13. Section l'art de la conception du jdr :roll: (peut-être avec 3b et 7)

http://www.debian.org/social_contract

un autre lien vers une licence dans le même esprit
merci Silver!

the silent bard a écrit :4. ??? (je dois avoir une très bonne attitude =D)

Si ça se trouve, on ne sait pas qu'on a la bonne attitude jusqu'au moment où les problèmes intéressants se posent :D

5. Oui et non, en fin de compte, je préfère ne pas obliger qui que ce soit de faire quoi que ce soit. Si mon intérêt pour mon projet disparaît, mais que le projet est tellement bien qu'il y a des fans, c'est eux qui vont venir me demander de continuer. Si personne ne veut entendre parler de mon projet, je ne vais pas faire chier qqn avec ce fardeau =D

C'est là le point-clef : s'il y a des gens que ça intéresse, alors quand on perd son intérêt pour le projet on a le devoir de le refiler à quelqu'un de compétent au lieu de le laisser mourir (et laisser ainsi tomber les types intéressés).

6. A mettre tout près du point 2 je pense, puisque c'est un peu le même esprit.

En fait je pense que dans ce cas "collaborateurs" doit se prendre au sens large. A mon avis, il s'agit de n'importe qui formulant une idée concernant le jeu. Ca veut dire qu'il faut examiner cette idée comme si on l'avait eu soi-même.

Note pour la 7 : je me force à poster :D et je vois le résultat d'ailleurs : j'avance nettement plus vite quand je me pousse au cul pour poster. D'ailleurs c'est un peu la raison qui me pousse à tenter d'avoir une version jouable vite : plus vite on pourra tester, plus vite on pourra travailler sur du concret (et donc travailler pour avoir vraiment un truc nickel).
Allez, je vais poster sur mes règles, ça doit faire 1 semaine que ça a pas avancé :D

Pour la 8, la remarque me paraissait effectivement indispensable... il faudrait effectivement la reformuler, la phrase est un peu lourde pour le moment.

La 9 s'applique évidemment au JDR !!!
En fait, il faut le prendre comme :
Un BG avec de bonnes idées de base même s'il est mal décrit, c'est mieux que l'inverse.
Un système de règles avec des règles de bases bien foutues, cohérentes et tout mais des cas particuliers (règles de combat, magie, véhicules, etc) pourraves vaut mieux que l'inverse.
Reformulation éventuelle : "une base solide et de mauvais développements valent mieux que l'inverse".

Le reste je sais pas s'il faut regrouper ou préciser... plutôt la seconde solution, sans doute...

Hop, ma première action en tant que modérateur : coller ce thread en post-it !
Après tout, il me semble suffisamment important pour qu'on se le garde affiché...

En attendant d'avoir une "charte" définitive, ça permettra de se garder ça en tête pour ne pas oublier d'y penser.
Et puis quand on sera arrivé à des "conclusions", on mettra ça en "annonce" :D

Bonne idée!

Je pars quelques jours dans les Alpes, mais je devrais être de retour (sur le net) au plus tard d'ici dimanche.