 Je m'appelle Simon Charrette. J'ai commencé à programme en piton il y a 4 ans dans le cadre d'un projet à l'université. Et puis par la suite, dans le cadre d'un contrat que j'avais trouvé, j'ai commencé à travailler avec Django. Auparavant, j'avais déjà programmé en Java, j'avais fait du front-end, j'avais utilisé PHP pour faire autre chose. Mais c'était la première fois que j'utilisais vraiment un framework. Je me suis lancé. J'ai commencé, il y a 4 ans, je travaillais avec Django. Puis j'ai contribué pour la première fois il y a 3 ans. J'ai ajouté à contribuer dans d'autres projets Open Source par la suite. Il y a un projet qui s'est appelé Prototype.js qui est comme... C'est pas popular avant que DjQuery prenne toute la place dans l'environnement j'avais écrit. J'avais déjà contribué à d'autres projets. Puis la première contribution que j'ai faite à Django, c'était une simple chaîne qui n'était pas marquée pour être traduite. J'étais vraiment très bien accueilli et ça m'a donné le goût de continuer par la suite. Depuis ce temps-là, j'ai fait des contributions constantes depuis les 3 dernières années. J'ai fait des rapports de bugs, des rédactions correctives. J'ai réveillé les pages, j'ai réveillé ceux des autres. J'ai fait du support aussi sur FreeNode, sur IRC, sur le channel Django. Puis comme beaucoup de développeurs, si je prends position dans la main list de Django developers concernant la direction que le projet veut prendre face à certains ajoutes de fonctionnalité ou à la déprécation de d'autres. Puis je participe aussi dans la maintenance d'applications tiers Django, donc des applications Django. Je prends part à tout ce qui est un peu de l'écosystème Django. Puis depuis 10 mois, depuis férié dernier, je suis core developer. J'ai été approché par d'autres core developers de Django pour m'en demander si je suis intéressé à la join. Ça m'a intéressé, donc je suis là depuis 10 mois. Le but de la présentation aujourd'hui, c'est juste un peu vous familiariser avec la manière dont vous pouvez contribuer à Django soit à travers des traductions, à traduire dans la langue dans laquelle vous êtes le plus à l'aise ou à travers la documentation ou à travers la révision de patch ou de la soumission de bug. Donc pourquoi contribuer à Django? C'est une communauté qui est une grande communauté active. Puis un projet qui est en santé. Il y a beaucoup de projets d'envergure qui l'utilisent, notamment Mozilla, Disco, et qui utilisent Django pour tout ce qui est l'affichage des commentaires. Ça se fait à travers Django. Puis aussi, un truc que j'ai trouvé super intéressant, moi quand j'ai commencé, c'est la transparence concernant le développement. Dans les projets disons comme Plastic Type.js, il y avait les cours développeurs qui prenaient les décisions. Puis la communauté n'avait pas vraiment son mot à dire. Dans Django, c'est vraiment que tout passe pas mal par la main l'église des Django Developers où il y a un appel aux gens qui sont spécialisés dans certains aspects du framework parce qu'il est très grand pour donner leur point de vue, en fait pour que ça bénéficie à tout le monde. Donc, une des premières façons dont vous pouvez, je vais commencer par la préalable, avant tout ça peut être, c'est très stupide d'obtenir le code source. Je pense que c'est du bon temps d'accord avec ça. C'est pas nécessaire pour faire toutes les contributions si vous ne sentez pas à l'aise. Je ne sais pas, j'imagine qu'il y a beaucoup de gens ici qui ont déjà contribué à des projets open source en faisant des rapports de bug ou en rédigiant un patch. Bien, il y a d'autres façons de contribuer à Django qui n'avaient pas nécessairement besoin d'avoir le code source, sauf que la plupart du temps c'est très utile. Aussi, puisque le framework est très large, à moins que vous ayez vraiment beaucoup de champs d'expertise dans le web, je vous suggérerai de commencer par un aspect particulier. Donc, si vous êtes à l'aise avec l'interaction avec la base de données ou plus avec tout ce qui est l'engage de template, je vous conseille de vous concentrer sur cet aspect-là au début parce que c'est très large. En fait, il y a encore des points dans Django que j'ai pas eu la chance de travailler dessus et je me sens vraiment pas à l'aise d'apporter mon point de vue dessus. Puis c'est normal parce que c'est très large comme framework. Je vous invite aussi à lire l'ensemble des lignes directrices de contribution. Je ne pourrai pas vous dénoncer complètement ici puisque sinon, ma présentation dirait vraiment plus longtemps. Par commencer, une des choses qui, une des très bonnes façons de commencer à contribuer à Django c'est en faisant du tritiquet. Récemment, dans les deux dernières années, Django est passé d'une station d'Azivienne, comme beaucoup de projets, à une station de Git puis migrée sur GitHub comme plateforme d'hébergement. Une des raisons pour laquelle on n'utilise pas et on ne compte pas utiliser le système de tritiquette de Django, pardon, de GitHub, c'est que ça ne permet pas à la communauté de participer au tritiquet. Donc, c'est pas possible de donner l'accès à l'ensemble de la communauté pour ce qui puisse accepter un bug ou faire du tritiquet carrément faible. Donc on utilise toujours track. Ça a ces avantages, les avantages étant qu'il faut faire les liaisons manuelles entre les deux systèmes. Donc, lorsqu'on a ouvert une pro-request sur GitHub pour proposer un changement, on le lit manuellement en mettant un lien, un hyper lien pointant vers le ticket ou juste en le mettant dans la description de la pro-request. Donc, utilisation de track, accessédepicode.jangoproject.com C'est une très bonne façon de commencer à contribuer puisque vous pouvez toucher à pas mal tout, au fond, les rapports de bugs qui sont faits là. L'ensemble des rapports qui sont faits là vont toucher à plusieurs petits aspects de Django. Une bonne façon de soumiser les pieds, c'est de chercher tous les tickets qui sont unreviews donc qui n'ont pas eu encore de feedback et d'essayer de reproduire si c'est un bug et c'est de reproduire ce que le bug que la personne a rencontré. Encore là, c'est important d'avoir le code sur votre machine si vous voulez y arriver rapidement. Si vous vous réussissez à produire un problème, vous pouvez marquer le ticket comme accéder. Si vous n'arrivez pas à le reproduire. Donc vous avez remarqué que dans the traceback, il y a un typo donc la personne n'a pas importé le bon module et a fait un erreur dedans. Le marqué comme invalid. Si vous n'arrivez carrément pas à reproduire la manière dont la personne nous a rapporté le bug, le marqué comme works for me. Si vous réalisez qu'il vous manque des informations, donc vous voyez que la personne n'a pas spécifié, disons que son bug était sur... Vous voyez dans the traceback en fait que c'est des chemins d'accès sur Windows, mais la personne n'a pas spécifié, sur quelle base de données a eu certains problèmes avec l'ORM, disons. Vous pouvez demander à ce moment-là que la personne spécifie plus d'informations pour éviter de passer trois heures à essayer de reproduire le problème avec exactement la configuration que ça s'en avait. Un truc qui peut aider, c'est à faire du tritiquette qui n'est pas documenté, mais qui est utilisée par beaucoup de personnes. Dashboard.jangoproject.com c'est un aperçu de l'ensemble des tickets selon leur statut. C'est plus facile de naviguer à dents puis d'avoir un aperçu de l'évolution de l'état des tickets que de faire vos recherches vous-même dans Track avec l'interface qui vous permet d'imaginer que beaucoup de gens s'y sont familier avec ça, de chercher des tickets selon certains critères. Donc dashboard.jangoproject.com peut vous aider à accélérer votre tritiquette. Si vous tombez donc vous utilisez Django, vous voulez faire un rapport de bug, passer avant tout par les supports des canaux de support, donc soit par IRC, soit par les mailing lists qui se trouvent sur Google Groups ça va sauver beaucoup de temps à vous, parce que si vous font une erreur de votre rapport les gens vont pouvoir vous le dire plus rapidement sur ces canaux de support que si vous faites un rapport de bug puis après ça, les gens vont devoir faire le tritiquette dans votre ticket, vont devoir le reproduire si vous passez par les canaux de support ça va être plus facile. Donc c'est pas un doublon fournir une description des étapes qui sont nécessaires à la production du problème donc c'est toutes des choses que vous vous prenez habitué de faire lorsque vous rapportez un problème. Si vous êtes en mesure à essayer de le faire, fournir un test unitaire qui est en échec pour vraiment isoler le problème et si vous êtes en cas, si vous êtes vraiment à l'aise avec le cas de la manière dont la structure de test de Django la structure des tests unitaire est de Django pour essayer de l'intégrer carrément dans la suite de tests tout ça serait vraiment génial. Si vous tombez sur un problème qui concerne la sécurité prenez pas de temps si vous avez un doute même passez par sécurité à Django project.com en voyant courriel, vous allez avoir l'attribution puis vous allez probablement éviter des mois, plusieurs personnes si ça saverait vraiment être une fois la sécurité. Si vous voulez vous lancer dans la rédaction de corrections dont la rédaction de patch ou l'ajout de fonctionnalité la meilleure façon de faire ça c'est si vous vous-même vous avez une fonctionnalité que vous voulez ajouter à Django je vous conseille de passer encore là par Django developers suggérer cette fonctionnalité prendre le poule de la communauté à savoir qu'est-ce que les gens pensent plutôt que de vous lancer directement dans la création d'un ticket puis vous faire rabrouer en vous en faisant dire il y a déjà quelque chose qui existe pour ça donc c'est bon de passer par Django developers plutôt que de vous lancer du suite dans la rédaction d'un patch, c'est sûr que vous allez apprendre quelque chose en faisant ça, j'en doute pas mais ça peut être un peu frustrant de passer du temps et créer un patch et voir qui ne sera pas intégré nécessairement donc c'est ça la manière dont je l'ai dit tout à l'heure on utilise GitHub pour faire le review de pull request puisque c'est un d'un outil vraiment génial pour faire plutôt que de travailler avec des diffs ou parc courriel carrément pour trouver des tickets sur lesquels les autres personnes ont ouvert mais qui n'ont pas écrit de patch ce que vous pouvez faire encore là, c'est passer par le dashboard que j'ai parlé tout à l'heure et chercher les patchs qui ont besoin d'être améliorés soit que le patch ne contenait pas de tests soit que le patch ne pouvait être mergeé carrément donc le patch a dévié de la base de code ou le test il y a plusieurs patchs qui nécessitent seulement des tests unitaires donc les gens étaient capables de proposer un correctif mais n'étaient pas à l'aise pour écrire des tests unitaires ça peut être une bonne façon de contribuer si d'ajouter des tests unitaires à des patchs qui étaient déjà existants l'ensemble des ajoutes fonctionnalités l'ensemble des correctifs de bugs vont nécessiter la joue de tests de régression si ça va être nécessaire vous n'aurez pas à avoir un patch qui va être mergeé sans l'ajusté test quelque chose à garder en tête c'est que la version actuelle de Django la page de développement supporte piton 2.7, 3.2, 3.3 il y a des subtilités pour faire le pont entre piton 2 et piton 3 il fitait les littérales U qui ne sont pas supportées pour faire signifier que c'est une chaine code il fitait ça puisque dans piton 3.2 ça a été rapatrier dans piton 3.3 mais dans 2.2 ça ne fonctionne pas ce qu'on utilise plutôt c'est des imparts de futures des subtilités qui sont bien documentées dans le guide de contributeurs que je vais vous parler tout à l'heure et si vous devez toucher à l'ORM si vous voulez faire un changement à ce niveau-là il va falloir tester un autre post rescuel il y a déjà un serveur d'interaction continue qui est en place pour ça qui va faire ruire l'ensemble des tests mais c'est probable qu'on vous demande de les rouler au moins local sur les tests unitaires que vous avez ajoutés sur les plateformes oracle on ne vous le demandera pas de le faire puisque c'est un peu un cauchemar installé en local une autre façon de contribuer c'est les traductions cependant en français les chaînes se retrouvent dans la librairie sont pas mal tout fait toujours super bien maintenues puisqu'il y a pas mal de contributeurs plusieurs qu'ont de core developers qui sont francophones, qui sont français qui s'occupent de ça super bien les traductions sont hébergées sur Transifix je sais pas si vous êtes à l'aise avec ça c'est un interface web en gros c'est un interface web pour éditer des fichiers PO ça permet de les gérer et d'approuver parce que c'est plus pratique de garder cette partie-là des reviews dans github ou juste de passer par track donc c'est traduit partiellement ou complètement à 90 langues comme je dis en français on a pas besoin de ressources en ce moment si vous êtes apte à communiquer dans une autre langue à partir de l'anglais probablement il y a du travail à faire donc si ça vous intéresse rendez-vous sur Transifix demandez à joindre une équipe et après ça vous êtes à la mesure de proposer une nouvelle traduction ou de corriger une qui est existante une autre façon de contribuer c'est en rédigeant de la documentation c'est une des forces selon moi Django en tout cas moi personnellement qui m'a encouragé à utiliser ça au tout début j'ai commencé à programmer en Python j'étais pas très à l'aise en fait il y a beaucoup de gens qui apprennent Python à travers Django au fond la documentation a été un peu axée là-dessus il y a un tutoriel qui est inclus dans la documentation qui doit très souvent être mis à jour ou faire à mesure qu'il y a des nouvelles fonctionnalités qui sont ajoutées pour que les gens puissent en tirer partie donc la documentation elle est toujours à améliorer les glissés ici et là donc si vous vous êtes en train de lire la documentation vous repérez ce genre de coquille vous repérez ce genre de typo n'hésitez pas à soumettre un ticket en indiquant ça ces tickets là sont fusionnés très rapidement puisque ça demande pas une révision très approfondie si vous souhaitez contribuer à la documentation mais vous n'arrivez pas à trouver cette coquille ou vous n'avez pas trouvé mais vous souhaitez quand même contribuer avec la documentation encore là c'est possible de chercher dans le track les tickets qui nécessitent la documentation ces tickets-là vont être marqués par un champ boulein souvent ces places-là c'est déjà juste fonctionnalité que des gens souhaitent faire ou des collectifs que des gens souhaitent faire mais ils sont pas nécessairement à l'aise assez en anglais pour écrire la documentation souvent il y a des pages il y a des pages qui peuvent attendre qui nécessitent seulement d'un certain ajout de documentation pour leur permettre d'être midi encore là ça peut être intéressant si vous souhaitez faire une petite contribution un autre truc qui est super important si c'est lors de la rédaction de la documentation on prend ça tout au sérieux on l'utilise d'un genre neutre donc pas de him ou her mais plutôt puis un autre truc qui est super intéressant si l'ensemble de documentation depuis environ 5 mois il y a un effort pour la traduire dans l'ensemble des langues donc c'est possible de le faire via Transfix la traduction française elle est très avancée je pense que c'est de l'ordre de 60% si je me trompe pas c'est significatif étant donné que c'est très gros l'ensemble de documentation de Djingo c'est quelque chose qui vous intéresse il faut encore là vous rendre sur Transfix puis mettre les mains à la porte puis contribuer à traduire la documentation de Djingo en français ou dans la langue dans laquelle vous sentez le plus à l'aise de traduire la documentation un autre moyen de contribuer c'est de répondre aux questions sur Djingo et sur Djingo user même si vous sentez pas nécessairement à l'aise de répondre aux questions souvent si vous êtes à l'aise avec la manière dont le framework fonctionne vous allez peut-être être en mesure d'épanner quelqu'un qui est carrément confus par l'ensemble des choses qui doit apprendre au tout début ça peut être intéressant d'aller là même si c'est un sujet que vous ne comprenez pas vous n'êtes pas en mesure de répondre à la question faire les démarches avec la personne pour chercher de votre côté et vous pouvez arriver à résoudre son problème vous pouvez faire aussi part de votre expertise si vous êtes expert avec les interactions avec Oracle par exemple ou avec Postresquiel puis vous souhaitez faire part de votre expertise vous pouvez joindre la discussion sur Djingo Developers puis lorsqu'il y a des interrogations ou tout concernant la route à suivre pour une modification sur l'ORM je ne sais pas, l'Irakite Count quand il y a certaines combinaisons de joint sur pour creuser un problème de performance sur Oracle au fond à ce moment-là vous serez en mesure d'ajouter votre grain de sel puis ça pourrait bénéficier à l'ensemble de la communauté Djingo puis il y a une autre manière très facile de contribuer c'est de tester les Release Candidates donc au fond à chaque fois qu'il y a une version de Djingo qui sort si vous avez une grosse application Djingo vous pouvez quand même la tester pas nécessairement en production mais au moins faire rouler vos tests unitaires en utilisant cette version de Djingo vous allez en bénéficier aussi puisque si vous réussissez à trouver des problèmes avant que le Release Officiel sort ça va être plus facile pour nous de fusionner ces changements-là plutôt que d'attendre que la première version de correctif donc le point 1 sort il y a beaucoup de détails j'ai passé en surface sur beaucoup de détails je vous encourage à vous rendre dans le tour d'accumulation de Djingo il y a un guide du contributeur génial dans lequel vous allez pouvoir trouver la plupart les réponses à plusieurs de vos questions en attendant si vous en avez je suis prêt à y répondre maintenant il reste 40 secondes