Vous n'êtes pas identifié(e).
Hello,
J'ai mis beaucoup trop de temps à rédiger ce mail, il fait suite aux
discussions durant Pycon-fr (et au précédent email).
Nous nous sommes fixé 3 objectifs :
1. court terme : s'en tenir à un set de doc limité mais à jour. Il
reste à fixer le périmètre mais je pense que le tuto + 2/3 essentiels
suffisent pour débuter.
2. moyen terme : avoir une (ou des) pages dédiées aux décideurs qui
soient plus claires et avenantes que de la doc. Au passage revoir la
catégorie des sites actuels qui comportent trop de blogs, quelques
success stories avec davantage de détails sur pourquoi ce choix
seraient plus intéressantes.
3. long terme : organisation d'un événement Django en France, très
probablement à Marseille car on a la possibilité d'avoir des salles et
fin avril/début mai pour que vous puissiez apprécier le soleil
printanier ! Je vais beaucoup m'investir dans cette partie car c'est
un projet qui me tient à cœur.
Voilà, avant d'aller plus en détail on peut déjà discuter de ces 3
points, surtout pour les personnes qui étaient absentes et qui ont
certainement leur mot à dire ;-).
Pour pouvoir avancer plus rapidement sur le premier, je pensais qu'un
sprint irc durant l'été pourrait être intéressant. Si vous avez
d'autres idées je suis preneur.
Bonne journée,
David
Hors ligne
Hello a tous,
Il est vrai qu'une page dédiée aux décideurs ne serait pas un luxe.
La doc est certes importante mais justement trop complète pour un
décideur qui va chercher en quelques points les avantages et
inconvénients. Par ailleurs la page des exemples de réalisation est a
nettoyer. Il me semble que quelques projets sont morts et peut être
que d'autres méritent d'être connus.
Merci en tout cas David pour ce petit mail.
Bonne journée.
Le 24 juin 2009 à 09:40, David Larlet <larlet _AT_ gmail.com> a écrit :
> Hello,
>
> J'ai mis beaucoup trop de temps à rédiger ce mail, il fait suite aux
> discussions durant Pycon-fr (et au précédent email).
>
> Nous nous sommes fixé 3 objectifs :
>
> 1. court terme : s'en tenir à un set de doc limité mais à jour. Il
> reste à fixer le périmètre mais je pense que le tuto + 2/3
> essentiels suffisent pour débuter.
> 2. moyen terme : avoir une (ou des) pages dédiées aux décideurs
> qui soient plus claires et avenantes que de la doc. Au passage revoi
> r la catégorie des sites actuels qui comportent trop de blogs, quelq
> ues success stories avec davantage de détails sur pourquoi ce choix
> seraient plus intéressantes.
> 3. long terme : organisation d'un événement Django en France, très
> probablement à Marseille car on a la possibilité d'avoir des salles
> et fin avril/début mai pour que vous puissiez apprécier le soleil pr
> intanier ! Je vais beaucoup m'investir dans cette partie car c'est u
> n projet qui me tient à cœur.
>
> Voilà, avant d'aller plus en détail on peut déjà discuter de ces
> 3 points, surtout pour les personnes qui étaient absentes et qui ont
> certainement leur mot à dire ;-).
> Pour pouvoir avancer plus rapidement sur le premier, je pensais
> qu'un sprint irc durant l'été pourrait être intéressant. Si vous
> avez d'autres idées je suis preneur.
>
> Bonne journée,
> David
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
Hors ligne
Le 24 juin 2009 10:19, sebastien morele<moreleseb _AT_ gmail.com> a écrit :
> Hello a tous,
> Il est vrai qu'une page dédiée aux décideurs ne serait pas un luxe. La doc
> est certes importante mais justement trop complète pour un décideur qui va
> chercher en quelques points les avantages et inconvénients. Par ailleurs la
> page des exemples de réalisation est a nettoyer. Il me semble que quelques
> projets sont morts et peut être que d'autres méritent d'être connus.
décideur = ????? . Je crois que le panel est trop important pour
faire des pages décideurs. Par contre en se concentrant sur le projet
django en lui même il y a qqs points à mettre en avant :
- doc : important si une grande partie est francisée quoiqu'on en
dise. C'est l'un des critères de choix dans la plupart des grandes
structures (dont l'administration). Cela peut aussi aider les vendeurs
de projets: on fournit souvent une doc du code et plus avec sont
projet. Le mieux est qu'elle soit en français car cela ne demande plus
le critère "connaissances en anglais requises" sur le cv des prochains
intervenants sur le code.
- partie tuto, il ya des blogs francophones avec des tutos qui
trainent un peu partout, les centraliser serait utile.
- vie de la communauté: comment joindre les devs français, qui a fait
quoi, quels projets. Un planete peut aider , un lien vers un
djangopeople francophone aussi.
- news sur django traduite. Pas vraiment important sinon que cela
apporte un point de chute régulier francophone.
- page hébergeurs
- log irc publique. Plus utiles que des fortunes vu le nombre
d'information qui sont échangées sur irc. Ou si on ne veut pas mettre
ces logs, avoir un bot qui récupère les liens sur le chan serait
pratique.
ce genre de chose. C'est beaucoup plus utiles que des pages dédiées
décideurs qui risquent bien souvent de tomber à coté et qui de tte
façon n'existent pas le plus souvent sur les sites de projets actuels.
- benoit
Hors ligne
Le 24 juin 2009 15:50, Benoit Chesneau<bchesneau _AT_ gmail.com> a écrit :
> Le 24 juin 2009 10:19, sebastien morele<moreleseb _AT_ gmail.com> a écrit :
>> Hello a tous,
>> Il est vrai qu'une page dédiée aux décideurs ne serait pas un luxe. La doc
>> est certes importante mais justement trop complète pour un décideur qui va
>> chercher en quelques points les avantages et inconvénients. Par ailleurs la
>> page des exemples de réalisation est a nettoyer. Il me semble que quelques
>> projets sont morts et peut être que d'autres méritent d'être connus.
>
>
> décideur = ????? . Je crois que le panel est trop important pour
> faire des pages décideurs. Par contre en se concentrant sur le projet
> django en lui même il y a qqs points à mettre en avant :
>
> - doc : important si une grande partie est francisée quoiqu'on en
> dise. C'est l'un des critères de choix dans la plupart des grandes
> structures (dont l'administration). Cela peut aussi aider les vendeurs
> de projets: on fournit souvent une doc du code et plus avec sont
> projet. Le mieux est qu'elle soit en français car cela ne demande plus
> le critère "connaissances en anglais requises" sur le cv des prochains
> intervenants sur le code.
>
> - partie tuto, il ya des blogs francophones avec des tutos qui
> trainent un peu partout, les centraliser serait utile.
>
> - vie de la communauté: comment joindre les devs français, qui a fait
> quoi, quels projets. Un planete peut aider , un lien vers un
> djangopeople francophone aussi.
>
> - news sur django traduite. Pas vraiment important sinon que cela
> apporte un point de chute régulier francophone.
>
> - page hébergeurs
>
> - log irc publique. Plus utiles que des fortunes vu le nombre
> d'information qui sont échangées sur irc. Ou si on ne veut pas mettre
> ces logs, avoir un bot qui récupère les liens sur le chan serait
> pratique.
>
> ce genre de chose. C'est beaucoup plus utiles que des pages dédiées
> décideurs qui risquent bien souvent de tomber à coté et qui de tte
> façon n'existent pas le plus souvent sur les sites de projets actuels.
>
>
> - benoit
>
J'allais oublier une partie job. On a certe elle de l'afpy mais bien
souvent les gens viennent sur un ite django pour poser des offres.
- benoît
Hors ligne
Hello hello,
2009/6/24 Benoit Chesneau <bchesneau _AT_ gmail.com>:
>
>
> décideur = ????? . Je crois que le panel est trop important pour
> faire des pages décideurs.
Je trouve que ça pourrait avoir son intérêt. Sur le site officiel
c'est très vite technique, il pourrait y avoir un peu de contenu plus
"haut niveau" pour présenter ce que Django peut permettre de faire, en
quoi cet outil est intéressant.
> Par contre en se concentrant sur le projet
> django en lui même il y a qqs points à mettre en avant :
>
> - doc : important si une grande partie est francisée quoiqu'on en
> dise. C'est l'un des critères de choix dans la plupart des grandes
> structures (dont l'administration). Cela peut aussi aider les vendeurs
> de projets: on fournit souvent une doc du code et plus avec sont
> projet. Le mieux est qu'elle soit en français car cela ne demande plus
> le critère "connaissances en anglais requises" sur le cv des prochains
> intervenants sur le code.
C'est pas faux :-)
Vu le manque cruel de main d'œuvre, il faudrait faire une liste de
priorité, comme David l'a dit c'est bien d'avoir une base "garantie à
jour" et le reste... Un peu comme on peut ! Du coup, à part le
tutoriel, qu'est-ce qu'il faut traduire ?
> - partie tuto, il ya des blogs francophones avec des tutos qui
> trainent un peu partout, les centraliser serait utile.
>
> - vie de la communauté: comment joindre les devs français, qui a fait
> quoi, quels projets. Un planete peut aider , un lien vers un
> djangopeople francophone aussi.
Un planet, ce serait pas mal. J'ai un peu de mal avec les posts
non-anglophones sur le planet officiel, donc autant avoir un endroit
sur lequel on peut poster sans scrupules en français.
http://djangopeople.net/fr/ <- je ne pensais pas qu'il y avait autant
de djangonautes francophones.
> - news sur django traduite. Pas vraiment important sinon que cela
> apporte un point de chute régulier francophone.
Et vu la cadence de publication, ça ne représente pas beaucoup de travail.
> J'allais oublier une partie job. On a certe elle de l'afpy mais bien
> souvent les gens viennent sur un ite django pour poser des offres.
Très bonne idée aussi, ça va m'intéresser dans un an... :-)
Bonne après-midi,
Bruno
>
> - page hébergeurs
>
> - log irc publique. Plus utiles que des fortunes vu le nombre
> d'information qui sont échangées sur irc. Ou si on ne veut pas mettre
> ces logs, avoir un bot qui récupère les liens sur le chan serait
> pratique.
>
> ce genre de chose. C'est beaucoup plus utiles que des pages dédiées
> décideurs qui risquent bien souvent de tomber à coté et qui de tte
> façon n'existent pas le plus souvent sur les sites de projets actuels.
>
>
> - benoit
Hors ligne
Le 24 juin 2009 16:41, Bruno Renié<buburno _AT_ gmail.com> a écrit :
> Hello hello,
>
> 2009/6/24 Benoit Chesneau <bchesneau _AT_ gmail.com>:
>>
>>
>> décideur = ????? . Je crois que le panel est trop important pour
>> faire des pages décideurs.
>
> Je trouve que ça pourrait avoir son intérêt. Sur le site officiel
> c'est très vite technique, il pourrait y avoir un peu de contenu plus
> "haut niveau" pour présenter ce que Django peut permettre de faire, en
> quoi cet outil est intéressant.
Ce que tu qualifies de haut niveau(d'ailleurs qu'est-ce ?) ne l'est
pas forcement pour tous. Si tu veux parler de l'écosystème de Django
cela passe généralement par simplement montrer qu'il y a des devs et
des utilisateurs (sociétés, indépendans, sites web, administrations,
startups, ...) qui l'utilise. Ie montrer que ce projet existe ailleurs
que sur son site web. C'est ama suffisant et évite de tomber dans les
clichés qui ont pu apparaître à pycon-fr par ex.
Hors ligne
Le mercredi 24 juin 2009 09:40:04, David Larlet a écrit :
> 1. court terme : s'en tenir à un set de doc limité mais à jour. Il
> reste à fixer le périmètre mais je pense que le tuto + 2/3 essentiels
> suffisent pour débuter.
Je soutiens fermement. Il faut aller au plus court pour disposer quelque chose
de solide au lieu de perdre de l'énergie en diversifiant trop les tâches.
> 2. moyen terme : avoir une (ou des) pages dédiées aux décideurs qui
> soient plus claires et avenantes que de la doc. Au passage revoir la
> catégorie des sites actuels qui comportent trop de blogs, quelques
> success stories avec davantage de détails sur pourquoi ce choix
> seraient plus intéressantes.
Plusieurs pages orientés décideurs me semble peut être un peu trop pour
commencer. Un seul bon document à ce sujet devrait suffire, ces "décideurs" ont
juste besoin qu'on leur éclaircisse certains points, pas la peine de leur
moissonner le cerveau, ils ont juste besoin d'être rassuré.
C'est utile aussi pour les devs qui veulent présenter Django à leur directeur
technique ou autres sous-chefs.
> Pour pouvoir avancer plus rapidement sur le premier, je pensais qu'un
> sprint irc durant l'été pourrait être intéressant. Si vous avez
> d'autres idées je suis preneur.
Faudra penser à donner ICI une date précise pour ce "sprint irc" que ceux qui
s'y connecte rarement soient au courant.
Hors ligne
2009/6/24 Benoit Chesneau <bchesneau _AT_ gmail.com>:
>
> Ce que tu qualifies de haut niveau(d'ailleurs qu'est-ce ?) ne l'est
> pas forcement pour tous. Si tu veux parler de l'écosystème de Django
> cela passe généralement par simplement montrer qu'il y a des devs et
> des utilisateurs (sociétés, indépendans, sites web, administrations,
> startups, ...) qui l'utilise. Ie montrer que ce projet existe ailleurs
> que sur son site web. C'est ama suffisant et évite de tomber dans les
> clichés qui ont pu apparaître à pycon-fr par ex.
Je n'étais pas à pycon-fr, ne ne sais pas quels sont ces clichés. Mais
tu décris très bien ce que je voulais dire : un peu d'information
orientée vers ceux qui ne sont pas forcément des codeurs, qui
cherchent des études de cas simples et parlantes.
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne
Le 24 juin 2009 17:14, David THENON<david.thenon _AT_ wanadoo.fr> a écrit :
> Le mercredi 24 juin 2009 09:40:04, David Larlet a écrit :
>> 1. court terme : s'en tenir à un set de doc limité mais à jour. Il
>> reste à fixer le périmètre mais je pense que le tuto + 2/3 essentiels
>> suffisent pour débuter.
> Je soutiens fermement. Il faut aller au plus court pour disposer quelque chose
> de solide au lieu de perdre de l'énergie en diversifiant trop les tâches.
Diversifier ? Si le projet repose sur le volontariat pourquoi ne pas
laisser les gens choisir les traductions qu'ils souhaitent/leur semble
le plus utile sur le moment ? Cela limite d'emblée le coté perte
d'énergie. Avec ce volontariat je serait pour mettre en place un
système de mainteneur par traduction, ie je choisis de traduire cela,
je maintiens.
Je me demandais si pour un one shot on ne pourrait pas se faire aider
par traduc.org .
>
>> 2. moyen terme : avoir une (ou des) pages dédiées aux décideurs qui
>> soient plus claires et avenantes que de la doc. Au passage revoir la
>> catégorie des sites actuels qui comportent trop de blogs, quelques
>> success stories avec davantage de détails sur pourquoi ce choix
>> seraient plus intéressantes.
> Plusieurs pages orientés décideurs me semble peut être un peu trop pour
> commencer. Un seul bon document à ce sujet devrait suffire, ces "décideurs" ont
> juste besoin qu'on leur éclaircisse certains points, pas la peine de leur
> moissonner le cerveau, ils ont juste besoin d'être rassuré.
>
>
Qui sont ces décideurs ? Là est le point .... chef d'entreprise, chef
d'entreprise avec connaissances techniques, responsable marketing en
charge du site web , responsable communication en charge du site web ,
chef de projet ssii, chef de projet web, responsable des ventes, ....
?
Chacun a ses attentes. Une seule chose qu'ils ont en commun la plupart
est de ne pas vouloir essuyer les plâtres. Donc plutôt que d'imaginer
ce qui pourrait éventuellement rassurer un "décideur", autant plutôt
simplement présenter l'écosystème. Une page présentant aussi le projet
et ses fonctionnalités-utilisations en qq mots pour le coté
généraliste. Ce serait bien aussi de pouvoir rassembler les
présentations donnés par chacun sur django.
- benoit
Hors ligne
>
>
> Chacun a ses attentes. Une seule chose qu'ils ont en commun la plupart
> est de ne pas vouloir essuyer les plâtres. Donc plutôt que d'imaginer
> ce qui pourrait éventuellement rassurer un "décideur", autant plutôt
> simplement présenter l'écosystème. Une page présentant aussi le projet
> et ses fonctionnalités-utilisations en qq mots pour le coté
> généraliste. Ce serait bien aussi de pouvoir rassembler les
> présentations donnés par chacun sur django.
>
Sincèrement, et pour en avoir vendu plus d'un, ce qui fonctionne bien c'est
une galerie bien léchée avec les screenshots de sites qui utilisent la
techno, si possible récents et super jolis. La question clé c'est de savoir
que le décideur (quel qu'il soit), ne soit pas le seul à choisir la techno,
et ne soit donc pas en train de faire un choix "risqué". Ensuite, les sites
jolis, ca fait envie - même si vous et moi on sait que ca n'a rien à voir -
mais c'est comme ca que ca fait envie à un décideur...
Et c'est infiniment plus simple à faire que n'importe quel texte qui lui va
dépendre de la cible ...
My 2 cents...
>
> - benoit
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne
Assez d'accord sur le fait qu'il n'est pas si simple de décrire le décideur
moyen, car ça dépend beaucoup du marché visé. Du coup, présenter la
communauté et les fonctionnalités-utilisations me semblent bien.
Pour la traduction, je serais assez partisan de se concenter
sur un tuto d'intro en français, peut être plus poussé que celui du
site officiel
et de renvoyer après sur le site officiel pour la documentation complète.
Même si les arguments de Benoît sont très recevable, l'avancement actuel de
la doc montre que c'est un effort peut être un peu trop important pour
l'instant.
En
tout cas, pas de problème pour donner un coup de main pour la phase deux !
Goulwen
Hors ligne
Certes il n'est pas facile d'identifier le décideur moyen mais il est
possible de brièvement décrire ce qui fait la force de django par
rapport a d'autres framework et/ou techno. Le décideur a une idée de
son ou de ses projets et cherche une solution fiable. Il s'agit donc
de rester très succint quant a django. C'est un exercice difficile en
tout cas. Pour les tuto, l'idéal serait de rester dans ce qui se fait
déjà actuellement. Un tuto d' approcheest quelque chose de bien.
Pourquoi ne pas ajouter une section type "how-to"
c'est a dire une section qui traite de développements spécifiques? On
aurait donc un tuto d'appproche ainsi qu'une série de petits articles
plus précis(gestion des commentaires de blog, authentification etc. )
En tout cas ça balance pas mal , c'est créatif et c'est bien.
Le 24 juin 2009 à 21:04, Nautile Bleu <nautilebleu _AT_ gmail.com> a
écrit :
> Assez d'accord sur le fait qu'il n'est pas si simple de décrire le d
> écideur moyen, car ça dépend beaucoup du marché visé.
> Du coup, présenter la communauté et les fonctionnalités-
> utilisations me semblent bien.
>
> Pour la traduction, je serais assez partisan de se concenter sur un
> tuto d'intro en français, peut être plus poussé que celui du site
> officiel et de renvoyer après sur le site officiel pour la documenta
> tion complète. Même si les arguments de Benoît sont très
> recevable, l'avancement actuel de la doc montre que c'est un effort
> peut être un peu trop important pour l'instant.
>
> En tout cas, pas de problème pour donner un coup de main pour la pha
> se deux !
>
> Goulwen
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
Hors ligne
Le 24 juin 2009 17:18, Bruno Renié <buburno _AT_ gmail.com> a écrit :
>
> Je n'étais pas à pycon-fr, ne ne sais pas quels sont ces clichés. Mais
> tu décris très bien ce que je voulais dire : un peu d'information
> orientée vers ceux qui ne sont pas forcément des codeurs, qui
> cherchent des études de cas simples et parlantes.
>
Plutôt que des pages "décideurs" (si le client est un décideur fonctionnel,
je suis presque convaincu qu'il n'ira pas sur le site pour avoir des infos
et fera confiance à son presta - pour un décideur technique, s'il n'est pas
capable de lire la page d'accueil + overview du site actuel, heu vous êtes
sur qu'il est technique ? A ce titre l'overview est peut être déjà trop bas
niveau). Il serait peut être plus judicieux de faire des retours d'XP
incluant :
Présentation du projet
Présentation rapide de l'infra pour avoir une idée des technos / applicatifs
en présence pour le projet
Version de django utilisée
Points forts/faibles de Django dans le cadre du projet en question
Cela permettait en outre à chaque prestataire Django de valoriser ses
projets...
Mes 2 cents,
Nicolas
Hors ligne
Hello,
Je tente une réponse groupée.
Le 24 juin 09 à 15:50, Benoit Chesneau a écrit :
> - doc : important si une grande partie est francisée quoiqu'on en
> dise. C'est l'un des critères de choix dans la plupart des grandes
> structures (dont l'administration). Cela peut aussi aider les vendeurs
> de projets: on fournit souvent une doc du code et plus avec sont
> projet. Le mieux est qu'elle soit en français car cela ne demande plus
> le critère "connaissances en anglais requises" sur le cv des prochains
> intervenants sur le code.
Comme l'a souligné Bruno, c'est avant tout un problème de ressources.
(Et sinon fournir la doc de django comme doc d'un projet ?! Le pré-
requis cv ça serait pas plus connaître django ?)
>
> - partie tuto, il ya des blogs francophones avec des tutos qui
> trainent un peu partout, les centraliser serait utile.
La partie liens du site était à la base faite pour ça mais encore une
fois, très peu de contribution. C'est bien de mettre en place des
fonctionnalités mais sans données c'est inutile.
>
> - vie de la communauté: comment joindre les devs français, qui a fait
> quoi, quels projets. Un planete peut aider , un lien vers un
> djangopeople francophone aussi.
De mon point de vue, les planets ont beaucoup trop de bruit pour être
pertinents (je ne dois plus être abonné qu'à celui de django), le lien
vers djangopeople c'est une bonne idée.
>
> - news sur django traduite. Pas vraiment important sinon que cela
> apporte un point de chute régulier francophone.
Mouais, j'ai pas un avis tranché là-dessus. Je préfèrerais plus de doc
s'il y a des traducteurs que des news qui n'ont aucun intérêt passé
quelques temps.
>
> - page hébergeurs
Oui, voilà un vrai point bloquant pour tous les utilisateurs.
>
> - log irc publique. Plus utiles que des fortunes vu le nombre
> d'information qui sont échangées sur irc. Ou si on ne veut pas mettre
> ces logs, avoir un bot qui récupère les liens sur le chan serait
> pratique.
Je suis contre les logs irc publics. Et les 3/4 des liens postés sur
le chan ne sont pas relatifs à django. Ils sont d'un grand intérêt
mais surtout pour les présents qui peuvent en discuter à mon avis
>
> J'allais oublier une partie job. On a certe elle de l'afpy mais bien
> souvent les gens viennent sur un ite django pour poser des offres.
Pourquoi pas en effet.
Le 24 juin 09 à 17:14, David THENON a écrit :
Merci pour tes réponses encourageantes
>
>> Pour pouvoir avancer plus rapidement sur le premier, je pensais qu'un
>> sprint irc durant l'été pourrait être intéressant. Si vous avez
>> d'autres idées je suis preneur.
> Faudra penser à donner ICI une date précise pour ce "sprint irc" que
> ceux qui
> s'y connecte rarement soient au courant.
Oui, surtout que le temps passe et je pars 15 jours début août...
Le 24 juin 09 à 18:53, Benoit Chesneau a écrit :
>
> Diversifier ? Si le projet repose sur le volontariat pourquoi ne pas
> laisser les gens choisir les traductions qu'ils souhaitent/leur semble
> le plus utile sur le moment ? Cela limite d'emblée le coté perte
> d'énergie. Avec ce volontariat je serait pour mettre en place un
> système de mainteneur par traduction, ie je choisis de traduire cela,
> je maintiens.
Pour rappel, c'est ce qui est actuellement en place et ça ne marche pas.
Le 24 juin 09 à 19:00, Olivier Deckmyn a écrit :
> Sincèrement, et pour en avoir vendu plus d'un, ce qui fonctionne
> bien c'est une galerie bien léchée avec les screenshots de sites qui
> utilisent la techno, si possible récents et super jolis. La question
> clé c'est de savoir que le décideur (quel qu'il soit), ne soit pas
> le seul à choisir la techno, et ne soit donc pas en train de faire
> un choix "risqué". Ensuite, les sites jolis, ca fait envie - même si
> vous et moi on sait que ca n'a rien à voir - mais c'est comme ca que
> ca fait envie à un décideur...
>
> Le 24 juin 09 à 22:51, Nicolas Steinmetz a écrit :
>>
>> Plutôt que des pages "décideurs" (si le client est un décideur
>> fonctionnel, je suis presque convaincu qu'il n'ira pas sur le site
>> pour avoir des infos et fera confiance à son presta - pour un
>> décideur technique, s'il n'est pas capable de lire la page
>> d'accueil + overview du site actuel, heu vous êtes sur qu'il est
>> technique ? A ce titre l'overview est peut être déjà trop bas
>> niveau). Il serait peut être plus judicieux de faire des retours d'XP
>
Je pense aussi que ces approches études de cas sont pertinentes. Ça
demande beaucoup de boulot pour être bien fait (collecte, mise en
forme, etc) mais il faut une base de discussion.
Concernant la main-d'œuvre, je voudrais mettre au clair 2 choses :
* n'attendez pas un feu vert ou quoi que ce soit pour vous lancer,
faites et on en discute ensuite, trop de blabla ne mène à rien. Pour
ma part j'ai dit m'intéresser à la partie évènement mais les autres
parties ne m'intéressent pas forcément donc si vous voulez devenir un
"champion" sur ces projets il suffit de vous manifester sur la liste
et de vous retrousser les manches
* il y a 7 personnes qui ont répondues à ce mail, ça fait peu de
motivés, manifestez vous si vous souhaitez participer, c'est le moment !
Bonne soirée,
David
Hors ligne
Salut,
Je n'ai pas lu tous les archives mais je vais me permettre un modeste
avis du point de vue de mon expérience avec Dotclear.
> Le 24 juin 09 à 18:53, Benoit Chesneau a écrit :
>>
>> Diversifier ? Si le projet repose sur le volontariat pourquoi ne pas
>> laisser les gens choisir les traductions qu'ils souhaitent/leur semble
>> le plus utile sur le moment ? Cela limite d'emblée le coté perte
>> d'énergie. Avec ce volontariat je serait pour mettre en place un
>> système de mainteneur par traduction, ie je choisis de traduire cela,
>> je maintiens.
>
> Pour rappel, c'est ce qui est actuellement en place et ça ne marche pas.
D'expérience, donner une responsabilité à long terme à un contributeur
est casse gueule. Si au gré du temps et de ses envies, celui-ci passe à
autre chose, il va d'abord penser pouvoir tout faire de front. Se
rendant compte que non, il ne va rien dire et va culpabiliser. Ce genre
de situation arrive tout le temps et c'est frustrant.
Avec Dotclear, j'avais institué un mot d'ordre simple : vous faites (ou
ne faites pas) ce que vous voulez ; la seule contraire est de tenir vos
engagements ou prévenir si vous n'y arrivez pas. À force d'insister
lourdement sur ce dernier point, ça a finit par fonctionner à peu près.
Pour les moments de rush, la seule technique qui fonctionnait consistait
à assigner les tâches. Un exemple. Pour la sortie de Dotclear 2.1 on a
commencé à documenter les marqueurs de template (une bonne centaine).
Durant plusieurs semaines j'ai répété qu'il fallait remplir les pages,
sans résultat. J'ai finalement demandé à un contributeur de dresser une
liste de 20 marqueurs par binôme et la doc des marqueurs à été faite en
3/4 jours
Ça peut sembler autoritaire mais donner un boulot précis à un
contributeur lui donne un cadre plus clair que "Fais ce que voudras" et,
surtout, une limite temporelle. Il faut une sacré dose d'engagement pour
se lancer dans une activité dont ne sait quand elle s'arrêtera. Ce n'est
finalement rien de plus que donner un début et une fin mais ça change tout.
Je ne suis pas inscrit à cette liste depuis longtemps mais existe t-il
une liste arrêtée des choses à faire ?
> Je pense aussi que ces approches études de cas sont pertinentes. Ça
> demande beaucoup de boulot pour être bien fait (collecte, mise en forme,
> etc) mais il faut une base de discussion.
Sans aller trop loin, monter un "showcase" django ne prendrait pas non
plus un temps fou. À l'image de ceci par exemple :
http://wordpress.org/showcase/
Un screenshot, un témoignage, pas besoin de beaucoup plus.
> Concernant la main-d'œuvre, je voudrais mettre au clair 2 choses :
> * n'attendez pas un feu vert ou quoi que ce soit pour vous lancer,
> faites et on en discute ensuite, trop de blabla ne mène à rien. Pour ma
> part j'ai dit m'intéresser à la partie évènement mais les autres parties
> ne m'intéressent pas forcément donc si vous voulez devenir un "champion"
> sur ces projets il suffit de vous manifester sur la liste et de vous
> retrousser les manches
J'adorerais faire un showcase mais je vais laisser ça quelqu'un qui a
plus de temps que moi
Par contre, faire des plannings et organiser deux ou trois choses, je
sais faire et assez vite (j'attendrai donc la réponse à ma dernière
question).
> * il y a 7 personnes qui ont répondues à ce mail, ça fait peu de
> motivés, manifestez vous si vous souhaitez participer, c'est le moment !
Ça fait 8
Hors ligne
Ca tombe bien j'allais justement envoyer un mail à ce sujet, car je
vais être en vacances à partir de la fin de la semaine et j'aurais
donc un peu de temps.
Goulwen
Hors ligne
Salut,
Pas vraiment eu de temps libre ces dernières semaines, mais ça s'arrange.
Je n'ai pas relu les archives récement, j'écrirais donc de mémoire (désolé
pour les inexactitudes), mais je me permet aussi de donner mon humble point
de vue sur je projet.
Je me rappèle que la question de la version de la doc Django à traduire
s'était posée. Pour ma part, la version SVN n'est pas une bonne idée : elle
change trop souvent pour que ce soit vraiment viable, et c'est probablement
la version stable la plus utilisée. En plus, pourquoi ne pas profiter de
l'occasion avec la sortie de la 1.1 ?
Concernant l'attitude à adopter, je serais pour "diviser" le site en deux
parties : développeur / décideur (les deux profils qui sont les plus courant
sur ce genre de site il me semble). Un côté développeur très orienté
technique, avec la doc traduite, pourquoi pas un regroupement de snippets
utiles (interfaçage avec Djangosnippets.org ?), un regroupement
d'applications (même principe que pour les snippets). Enfin, le côté
décideur avec les principaux avantages de Django mis en valeur (screenshots,
témoignages...), et aussi pourquoi pas récupérer la liste des sites Français
utilisant Django (via http://www.djangosites.org/) ?
Pour ce qui est de l'organisation et la répartition des tâches, pourquoi ne
pas utiliser le système de tickets ("issues") de bibucket ?
* il y a 7 personnes qui ont répondues à ce mail, ça fait peu de
>> motivés, manifestez vous si vous souhaitez participer, c'est le moment !
>>
>
> Ça fait 8
Et maintenant 9
Bonne journée,
Thomas.
Hors ligne
Hello,
Le 29 juil. 09 à 11:36, Olivier Meunier a écrit :
> Salut,
>
> Je n'ai pas lu tous les archives mais je vais me permettre un
> modeste avis du point de vue de mon expérience avec Dotclear.
Toute expérience est la bienvenue
>
>
> D'expérience, donner une responsabilité à long terme à un
> contributeur est casse gueule. Si au gré du temps et de ses envies,
> celui-ci passe à autre chose, il va d'abord penser pouvoir tout
> faire de front. Se rendant compte que non, il ne va rien dire et va
> culpabiliser. Ce genre de situation arrive tout le temps et c'est
> frustrant.
>
> Avec Dotclear, j'avais institué un mot d'ordre simple : vous faites
> (ou ne faites pas) ce que vous voulez ; la seule contraire est de
> tenir vos engagements ou prévenir si vous n'y arrivez pas. À force
> d'insister lourdement sur ce dernier point, ça a finit par
> fonctionner à peu près.
>
> Pour les moments de rush, la seule technique qui fonctionnait
> consistait à assigner les tâches. Un exemple. Pour la sortie de
> Dotclear 2.1 on a commencé à documenter les marqueurs de template
> (une bonne centaine). Durant plusieurs semaines j'ai répété qu'il
> fallait remplir les pages, sans résultat. J'ai finalement demandé à
> un contributeur de dresser une liste de 20 marqueurs par binôme et
> la doc des marqueurs à été faite en 3/4 jours
>
> Ça peut sembler autoritaire mais donner un boulot précis à un
> contributeur lui donne un cadre plus clair que "Fais ce que voudras"
> et, surtout, une limite temporelle. Il faut une sacré dose
> d'engagement pour se lancer dans une activité dont ne sait quand
> elle s'arrêtera. Ce n'est finalement rien de plus que donner un
> début et une fin mais ça change tout.
Je n'en doute pas une seconde, mais par contre j'ai pas envie d'être à
cette position. Je préfère me recentrer sur des activités qui me
motivent plus comme l'organisation des rencontres Django à Marseille.
>
> Je ne suis pas inscrit à cette liste depuis longtemps mais existe t-
> il une liste arrêtée des choses à faire ?
Pas à ma connaissance.
>
>> Je pense aussi que ces approches études de cas sont pertinentes. Ça
>> demande beaucoup de boulot pour être bien fait (collecte, mise en
>> forme,
>> etc) mais il faut une base de discussion.
>
> Sans aller trop loin, monter un "showcase" django ne prendrait pas
> non plus un temps fou. À l'image de ceci par exemple :
> http://wordpress.org/showcase/
>
> Un screenshot, un témoignage, pas besoin de beaucoup plus.
Ça dépend, c'est toute la différence entre http://www.djangosites.org/
et http://djangositeoftheweek.com/
Le premier est très bruyant et n'est pas forcément très révélateur du
potentiel de django à mon avis.
Le second est plus pertinent mais n'a pas tenu la distance car ça
prend trop de temps à entretenir.
>
>> Concernant la main-d'œuvre, je voudrais mettre au clair 2 choses :
>> * n'attendez pas un feu vert ou quoi que ce soit pour vous lancer,
>> faites et on en discute ensuite, trop de blabla ne mène à rien.
>> Pour ma
>> part j'ai dit m'intéresser à la partie évènement mais les autres
>> parties
>> ne m'intéressent pas forcément donc si vous voulez devenir un
>> "champion"
>> sur ces projets il suffit de vous manifester sur la liste et de vous
>> retrousser les manches
>
> J'adorerais faire un showcase mais je vais laisser ça quelqu'un qui
> a plus de temps que moi
En fait pour un showcase, partir de la base de http://www.django-fr.org/djangosites/
ne prendrait pas énormément de temps.
>
> Par contre, faire des plannings et organiser deux ou trois choses,
> je sais faire et assez vite (j'attendrai donc la réponse à ma
> dernière question).
Ok, si tu veux te lancer là-dedans n'hésite pas. Inutile de te mettre
en garde sur l'énergie que ça demande de jouer ce rôle .
David
Hors ligne
Le 29 juil. 09 à 16:15, PELLETIER Thomas a écrit :
> Salut,
>
> Pas vraiment eu de temps libre ces dernières semaines, mais ça
> s'arrange.
> Je n'ai pas relu les archives récement, j'écrirais donc de mémoire
> (désolé pour les inexactitudes), mais je me permet aussi de donner
> mon humble point de vue sur je projet.
Bonjour,
Idem pour l'emploi du temps, à la différence près que l'arrangement ne
se profile pas encore à l'horizon
Je suis assez nouveau sur cette liste, donc pas réellement
d'historique pour ma part... en revanche, j'ai 18 mois d'historique
sur les ML officielles django.
> Je me rappèle que la question de la version de la doc Django à
> traduire s'était posée. Pour ma part, la version SVN n'est pas une
> bonne idée : elle change trop souvent pour que ce soit vraiment
> viable, et c'est probablement la version stable la plus utilisée. En
> plus, pourquoi ne pas profiter de l'occasion avec la sortie de la
> 1.1 ?
Pour avoir tenté, il y a quelques années, une traduction "brutale" de
la doc wxWidgets, je peux dire qu'une tentative de maintenance dans
le temps de l'intégralité des docs est a priori un doux rêve... trop
de volume et des projets qui (heureusement pour nous développeurs)
évoluent tellement rapidement que les traductions deviennent (trop)
vite obsolètes.
Si je peux me permettre de donner mon point de vue (résumé) sur la
question des docs et des langues : le plus souvent quand je fais un
tour d'horizon des outils en vue d'un choix, j'aime bien avoir
quelques docs en français (ca rejoint un peu le côté décideur, les
paillettes en moins) de même que dans la première phase de découverte
de l'outil; donc des introductions et tutoriels ne sont jamais de trop
à traduire.
Une fois l'outil pris en main, la langue des docs devient presque
secondaire pour des développeurs (supposés maîtriser un minimum
l'anglais...); ce qui n'empêche pas des traductions ponctuelles de
parties plus techniques.
Le souvenir que j'ai de la découverte de django se résume à un bon
moment (1 à 2 mois à temps perdu) de parcours des docs pour valider
point par point que tous mes besoins pourraient être couverts par le
framework (je suis dans le cas d'une réécriture intégrale d'une appli
développée sous un framework homemade). Je m'étais fait la réflexion à
l'époque qu'un second niveau plus technique de FAQs (ou de howtos)
pourrait être utile: une sorte de liste de cas d'utilisation avec des
renvois sur les docs appropriées.
> Concernant l'attitude à adopter, je serais pour "diviser" le site en
> deux parties : développeur / décideur (les deux profils qui sont les
> plus courant sur ce genre de site il me semble). Un côté développeur
> très orienté technique, avec la doc traduite, pourquoi pas un
> regroupement de snippets utiles (interfaçage avec
> Djangosnippets.org ?), un regroupement d'applications (même principe
> que pour les snippets). Enfin, le côté décideur avec les principaux
> avantages de Django mis en valeur (screenshots, témoignages...), et
> aussi pourquoi pas récupérer la liste des sites Français utilisant
> Django (via http://www.djangosites.org/) ?
+1 pour une séparation des "discours" et docs décideur/développeur.
Je me trouve personnellement dans la situation plûtot confortable où
je suis seul maître à bord (décideur+concepteur+développeur), mais je
me sers allègrement des portails de présentation de Django pour
communiquer avec la partie clients & commerciaux. De simples éléments
montrant le sérieux et l'ampleur du projet Django les fait basculer en
quelques minutes de consultation en mode "ok, rien à redire". Surtout
la phrase d'accroche "The Web framework for perfectionists with
deadlines" plaît beaucoup aux décideurs.
> * il y a 7 personnes qui ont répondues à ce mail, ça fait peu de
> motivés, manifestez vous si vous souhaitez participer, c'est le
> moment !
>
> Ça fait 8
>
> Et maintenant 9
attention, on passe à 2 chiffres
Hors ligne
Bonjour à tous,
Je suis moi aussi nouveau sur cette liste et sur Django. J'ai commencé
la lecture du Django Book car je voulais utiliser Django pour une
grosse application intranet où il me paraissait tout à fait adapté.
Malheureusement, je n'ai pas décroché le contrat. Je suis un fan de
Python au sens large auquel je trouve mille qualités.
J'ai une certaine expérience de traducteur technique (4 bouquins sur
Mac pour O'Reilly quand la maison d'édition était encore en France et
différents articles pour un site de développeurs Mac OS X). Je veux
bien participer à la traduction de la doc Django afin de monter en
compétence sur ce projet qui me plaît beaucoup et aider ceux pour qui
l'anglais est un obstacle.
--
Mactov
Le 29 juil. 09 à 17:03, Gaches Romain a écrit :
> Le 29 juil. 09 à 16:15, PELLETIER Thomas a écrit :
>
>> Salut,
>>
>> Pas vraiment eu de temps libre ces dernières semaines, mais ça
>> s'arrange.
>> Je n'ai pas relu les archives récement, j'écrirais donc de mémoire
>> (désolé pour les inexactitudes), mais je me permet aussi de donner
>> mon humble point de vue sur je projet.
>
> Bonjour,
>
> Idem pour l'emploi du temps, à la différence près que l'arrangement
> ne se profile pas encore à l'horizon
>
> Je suis assez nouveau sur cette liste, donc pas réellement
> d'historique pour ma part... en revanche, j'ai 18 mois d'historique
> sur les ML officielles django.
>
>> Je me rappèle que la question de la version de la doc Django à
>> traduire s'était posée. Pour ma part, la version SVN n'est pas une
>> bonne idée : elle change trop souvent pour que ce soit vraiment
>> viable, et c'est probablement la version stable la plus utilisée.
>> En plus, pourquoi ne pas profiter de l'occasion avec la sortie de
>> la 1.1 ?
>
> Pour avoir tenté, il y a quelques années, une traduction "brutale"
> de la doc wxWidgets, je peux dire qu'une tentative de maintenance
> dans le temps de l'intégralité des docs est a priori un doux rêve...
> trop de volume et des projets qui (heureusement pour nous
> développeurs) évoluent tellement rapidement que les traductions
> deviennent (trop) vite obsolètes.
>
> Si je peux me permettre de donner mon point de vue (résumé) sur la
> question des docs et des langues : le plus souvent quand je fais un
> tour d'horizon des outils en vue d'un choix, j'aime bien avoir
> quelques docs en français (ca rejoint un peu le côté décideur, les
> paillettes en moins) de même que dans la première phase de
> découverte de l'outil; donc des introductions et tutoriels ne sont
> jamais de trop à traduire.
>
> Une fois l'outil pris en main, la langue des docs devient presque
> secondaire pour des développeurs (supposés maîtriser un minimum
> l'anglais...); ce qui n'empêche pas des traductions ponctuelles de
> parties plus techniques.
>
> Le souvenir que j'ai de la découverte de django se résume à un bon
> moment (1 à 2 mois à temps perdu) de parcours des docs pour valider
> point par point que tous mes besoins pourraient être couverts par le
> framework (je suis dans le cas d'une réécriture intégrale d'une
> appli développée sous un framework homemade). Je m'étais fait la
> réflexion à l'époque qu'un second niveau plus technique de FAQs (ou
> de howtos) pourrait être utile: une sorte de liste de cas
> d'utilisation avec des renvois sur les docs appropriées.
>
>
>> Concernant l'attitude à adopter, je serais pour "diviser" le site
>> en deux parties : développeur / décideur (les deux profils qui sont
>> les plus courant sur ce genre de site il me semble). Un côté
>> développeur très orienté technique, avec la doc traduite, pourquoi
>> pas un regroupement de snippets utiles (interfaçage avec
>> Djangosnippets.org ?), un regroupement d'applications (même
>> principe que pour les snippets). Enfin, le côté décideur avec les
>> principaux avantages de Django mis en valeur (screenshots,
>> témoignages...), et aussi pourquoi pas récupérer la liste des sites
>> Français utilisant Django (via http://www.djangosites.org/) ?
>
> +1 pour une séparation des "discours" et docs décideur/développeur.
> Je me trouve personnellement dans la situation plûtot confortable où
> je suis seul maître à bord (décideur+concepteur+développeur), mais
> je me sers allègrement des portails de présentation de Django pour
> communiquer avec la partie clients & commerciaux. De simples
> éléments montrant le sérieux et l'ampleur du projet Django les fait
> basculer en quelques minutes de consultation en mode "ok, rien à
> redire". Surtout la phrase d'accroche "The Web framework for
> perfectionists with deadlines" plaît beaucoup aux décideurs.
>
>
>
>
>> * il y a 7 personnes qui ont répondues à ce mail, ça fait peu de
>> motivés, manifestez vous si vous souhaitez participer, c'est le
>> moment !
>>
>> Ça fait 8
>>
>> Et maintenant 9
>
> attention, on passe à 2 chiffres
>
> --
> Romain
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
Hors ligne
Apparemment, on a pas mal de gens motivés (+ de 10 !) et un minimum
disponibles. Reste à organiser les choses. Comme Olivier a l'expérience et
semble ok pour faire la logistique, peut-on essayer d'organiser un peu plus
les choses ?
Que fait-on ?
A la lecture des messages, il semble que l'on soit à peu près d'accord sur :
* Faire 2 parties, une pour les dév/une pour les décideurs
* Faire quelques showcases, mais sans le côté "site of the week" (ni
même "site of the month")
* Traduire le tutorial d'introduction
* Dresser une liste des hébergeurs
* Mettre en place un lien vers djangopeople/djangogigs
Est-on tous d'accord sur ce plus petit dénominateur commun qui semble en
outre raisonnable en terme d'effort ?
Goulwen
Hors ligne
Le 30/07/09 8:41, nautilebleu _AT_ gmail.com a écrit :
> Apparemment, on a pas mal de gens motivés (+ de 10 !) et un minimum
> disponibles. Reste à organiser les choses. Comme Olivier a l'expérience
> et semble ok pour faire la logistique, peut-on essayer d'organiser un
> peu plus les choses ?
Houla, j'ai dit ça moi ? Je suis complètement inconscient des fois Je
pense que je me retrouverai très vite dans la situation du gars qui ne
peut pas tenir ses engagements et entrerai dans le cercle maudit des
délais non tenus + culpabilité.
C'est agaçant car j'aimerais beaucoup faire un truc mais en ce moment
j'ai définitivement trop de boulot.
Une discussion sur IRC sur les choses à faire, pour quand, etc. pourrait
être un bon début. Là, je pourrai éventuellement m'avancer.
Hors ligne
Le 30 juillet 2009 08:41, <nautilebleu _AT_ gmail.com> a écrit :
> Apparemment, on a pas mal de gens motivés (+ de 10 !) et un minimum
> disponibles. Reste à organiser les choses. Comme Olivier a l'expérience et
> semble ok pour faire la logistique, peut-on essayer d'organiser un peu plus
> les choses ?
>
> Que fait-on ?
> A la lecture des messages, il semble que l'on soit à peu près d'accord sur :
>
> * Faire 2 parties, une pour les dév/une pour les décideurs
-1
Je ne suis pas d'accord C'est surtout que l'on manque toujours
d'une définition d'un "décideur". Décideur ça ne ne veut rien dire et
ça dépend du marché dans lequel le choix est fait. Comme je l'ai déjà
dit il serait plus approprié de faire des pages "show cases".
Untelutilise django dans telle conditions et pourquoi.
> * Faire quelques showcases, mais sans le côté "site of the week" (ni même
> "site of the month")
+1
> * Traduire le tutorial d'introduction
+1
> * Dresser une liste des hébergeurs
+1
> * Mettre en place un lien vers djangopeople/djangogigs
0
Je préfererais une page en français.
>
> Est-on tous d'accord sur ce plus petit dénominateur commun qui semble en
> outre raisonnable en terme d'effort ?
>
Voir vote ci-dessus. D'ailleurs je propose que l'on utilise ce système
qui fonctionne très bien avec la fondation apache. Reste à définir les
dénominateurs.
> Goulwen
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne
Le 29 juillet 2009 00:07, David Larlet<larlet _AT_ gmail.com> a écrit :
> Hello,
>
> Je tente une réponse groupée.
>
> Le 24 juin 09 à 15:50, Benoit Chesneau a écrit :
>>
>> - doc : important si une grande partie est francisée quoiqu'on en
>> dise. C'est l'un des critères de choix dans la plupart des grandes
>> structures (dont l'administration). Cela peut aussi aider les vendeurs
>> de projets: on fournit souvent une doc du code et plus avec sont
>> projet. Le mieux est qu'elle soit en français car cela ne demande plus
>> le critère "connaissances en anglais requises" sur le cv des prochains
>> intervenants sur le code.
>
> Comme l'a souligné Bruno, c'est avant tout un problème de ressources.
> (Et sinon fournir la doc de django comme doc d'un projet ?! Le pré-requis cv
> ça serait pas plus connaître django ?)
>>
>> - partie tuto, il ya des blogs francophones avec des tutos qui
>> trainent un peu partout, les centraliser serait utile.
>
> La partie liens du site était à la base faite pour ça mais encore une fois,
> très peu de contribution. C'est bien de mettre en place des fonctionnalités
> mais sans données c'est inutile.
UN wiki pourrait aider. Cela fonctionne très bien sur couchdb les gens
ajoutent volontier des liens vers leurs projets ou mettent à jour la
doc.
>>
>> - vie de la communauté: comment joindre les devs français, qui a fait
>> quoi, quels projets. Un planete peut aider , un lien vers un
>> djangopeople francophone aussi.
>
> De mon point de vue, les planets ont beaucoup trop de bruit pour être
> pertinents (je ne dois plus être abonné qu'à celui de django), le lien vers
> djangopeople c'est une bonne idée.
djangopeople n'est pas en français.
>>
>> - news sur django traduite. Pas vraiment important sinon que cela
>> apporte un point de chute régulier francophone.
>
> Mouais, j'ai pas un avis tranché là-dessus. Je préfèrerais plus de doc s'il
> y a des traducteurs que des news qui n'ont aucun intérêt passé quelques
> temps.
>>
ce n'est pas le même objectif. Je pense que tu as raisons sur le
problème de contribution, bien que vu sur un projet , certaines
personnes s'emparent plus facilement de la traduction de news (plus
courte, plus enrichissantes, retour immédiat, discussion qui s'ensuit
sur ml/irc ...) que sur les docs.
>> - page hébergeurs
>
> Oui, voilà un vrai point bloquant pour tous les utilisateurs.
+1
>>
>> - log irc publique. Plus utiles que des fortunes vu le nombre
>> d'information qui sont échangées sur irc. Ou si on ne veut pas mettre
>> ces logs, avoir un bot qui récupère les liens sur le chan serait
>> pratique.
>
> Je suis contre les logs irc publics. Et les 3/4 des liens postés sur le chan
> ne sont pas relatifs à django. Ils sont d'un grand intérêt mais surtout pour
> les présents qui peuvent en discuter à mon avis
contre pourquoi ?
>>
>> J'allais oublier une partie job. On a certe elle de l'afpy mais bien
>> souvent les gens viennent sur un ite django pour poser des offres.
>
> Pourquoi pas en effet.
>
>
> Le 24 juin 09 à 17:14, David THENON a écrit :
> Merci pour tes réponses encourageantes
>>
>>> Pour pouvoir avancer plus rapidement sur le premier, je pensais qu'un
>>> sprint irc durant l'été pourrait être intéressant. Si vous avez
>>> d'autres idées je suis preneur.
>>
>> Faudra penser à donner ICI une date précise pour ce "sprint irc" que ceux
>> qui
>> s'y connecte rarement soient au courant.
>
> Oui, surtout que le temps passe et je pars 15 jours début août...
>
> Le 24 juin 09 à 18:53, Benoit Chesneau a écrit :
>>
>> Diversifier ? Si le projet repose sur le volontariat pourquoi ne pas
>> laisser les gens choisir les traductions qu'ils souhaitent/leur semble
>> le plus utile sur le moment ? Cela limite d'emblée le coté perte
>> d'énergie. Avec ce volontariat je serait pour mettre en place un
>> système de mainteneur par traduction, ie je choisis de traduire cela,
>> je maintiens.
>
> Pour rappel, c'est ce qui est actuellement en place et ça ne marche pas.
>
> Le 24 juin 09 à 19:00, Olivier Deckmyn a écrit :
>>
>> Sincèrement, et pour en avoir vendu plus d'un, ce qui fonctionne bien
>> c'est une galerie bien léchée avec les screenshots de sites qui utilisent la
>> techno, si possible récents et super jolis. La question clé c'est de savoir
>> que le décideur (quel qu'il soit), ne soit pas le seul à choisir la techno,
>> et ne soit donc pas en train de faire un choix "risqué". Ensuite, les sites
>> jolis, ca fait envie - même si vous et moi on sait que ca n'a rien à voir -
>> mais c'est comme ca que ca fait envie à un décideur...
>
>>
>> Le 24 juin 09 à 22:51, Nicolas Steinmetz a écrit :
>>>
>>> Plutôt que des pages "décideurs" (si le client est un décideur
>>> fonctionnel, je suis presque convaincu qu'il n'ira pas sur le site pour
>>> avoir des infos et fera confiance à son presta - pour un décideur technique,
>>> s'il n'est pas capable de lire la page d'accueil + overview du site actuel,
>>> heu vous êtes sur qu'il est technique ? A ce titre l'overview est peut être
>>> déjà trop bas niveau). Il serait peut être plus judicieux de faire des
>>> retours d'XP
>>
>
>
> Je pense aussi que ces approches études de cas sont pertinentes. Ça demande
> beaucoup de boulot pour être bien fait (collecte, mise en forme, etc) mais
> il faut une base de discussion.
>
> Concernant la main-d'œuvre, je voudrais mettre au clair 2 choses :
> * n'attendez pas un feu vert ou quoi que ce soit pour vous lancer, faites et
> on en discute ensuite, trop de blabla ne mène à rien. Pour ma part j'ai dit
> m'intéresser à la partie évènement mais les autres parties ne m'intéressent
> pas forcément donc si vous voulez devenir un "champion" sur ces projets il
> suffit de vous manifester sur la liste et de vous retrousser les manches
> * il y a 7 personnes qui ont répondues à ce mail, ça fait peu de motivés,
> manifestez vous si vous souhaitez participer, c'est le moment !
>
> Bonne soirée,
> David
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne
Le 29 juillet 2009 16:15, PELLETIER Thomas<pelletier.thomas _AT_ gmail.com> a écrit :
> Concernant l'attitude à adopter, je serais pour "diviser" le site en deux
> parties : développeur / décideur (les deux profils qui sont les plus courant
> sur ce genre de site il me semble). Un côté développeur très orienté
> technique, avec la doc traduite, pourquoi pas un regroupement de snippets
> utiles (interfaçage avec Djangosnippets.org ?)
2 profils ? Je ne vois aucun profil. Sinon que qqn a decrété à un
moment qu'il existe un "décideur". Dans la pratique cela se passe
differemment.
, un regroupement
> d'applications (même principe que pour les snippets).
- 1. refaire l'existant n'est pas forcemment interessant à moins qu'il
n'y ait pas d'equivalent fr. D'ailleurs contacter djangosnippets pour
traduire en fr le site ? (et ajouter la recherche).
Enfin, le côté
>
> Pour ce qui est de l'organisation et la répartition des tâches, pourquoi ne
> pas utiliser le système de tickets ("issues") de bibucket ?
>
+1
Hors ligne