Bonsoir, Je souhaite lancer la discussion de savoir ce qu'on pourrait proposer comme article pour le prochain numéro, et voir les volontaires à leur rédaction.
Pour ma part, je souhaiterais bien mettre l'accent sur ce qui a attrait à la QA : * Présentation de Rawhide, son intérêt, son fonctionnement, ses risques * Le dépôt update-testing et la remontée des anomalies (dont fedora-easy-karma ou Bodhi) * Description du cycle de vie d'une version : chaque étape de son élaboration jusqu'à la fin de son support officiel.
Je pense que c'est déjà pas mal sur le sujet, il y a de quoi faire avec. Si vous avez des commentaires sur ces sujets, je suis preneur.
Par ailleurs, histoire de faire avancer le côté technique, Mathieu Gautier a proposé un format de distribution de Muffin sous forme de site web local (potentiellement transformable en un autre format). Vous pouvez récupérer son prototypage par ici : https://git.framasoft.org/mgautierfr/muffin-new (une aide sera bientôt disponible sur le Wiki de Fedora-fr pour expliquer son principe et comment l'exploiter pour ceux qui l'ignorent).
Le format de rédaction envisagé, pour sa simplicité et lisibilité en format texte, serait le Common Markdown. Nous souhaitons avoir des retours sur ces questions, peut être qu'une autre solution vous semblerait plus adaptée ?
Notons que si cette solution est employée, nous serions intéressés par des compétences de designer web. Si vous savez où trouvé quelqu'un d'intéressé et compétent, nous serons ravis de voir les volontaires. ;)
Je vous remercie pour votre attention, en espérant des retours. Passez un bon week-end. Cordialement. Charles-Antoine
Bonsoir, Le 29/08/2015 00:02, Charles-Antoine Couret a écrit :
Bonsoir, Je souhaite lancer la discussion de savoir ce qu'on pourrait proposer comme article pour le prochain numéro, et voir les volontaires à leur rédaction.
Pour ma part, je souhaiterais bien mettre l'accent sur ce qui a attrait à la QA :
- Présentation de Rawhide, son intérêt, son fonctionnement, ses risques
- Le dépôt update-testing et la remontée des anomalies (dont fedora-easy-karma ou Bodhi)
- Description du cycle de vie d'une version : chaque étape de son élaboration jusqu'à la fin de son support officiel.
Je pense que c'est déjà pas mal sur le sujet, il y a de quoi faire avec. Si vous avez des commentaires sur ces sujets, je suis preneur.
Par ailleurs, histoire de faire avancer le côté technique, Mathieu Gautier a proposé un format de distribution de Muffin sous forme de site web local (potentiellement transformable en un autre format). Vous pouvez récupérer son prototypage par ici : https://git.framasoft.org/mgautierfr/muffin-new (une aide sera bientôt disponible sur le Wiki de Fedora-fr pour expliquer son principe et comment l'exploiter pour ceux qui l'ignorent).
Je viens de pousser une nouvelle version qui permet d'avoir une css différente générée pour chaque article.
Pour ce qu'ils veulent tester, il suffit de checkout et : ./poole.py --build --serve
puis http://localhost:8080 (ou directement les fichiers dans le dossier output)
(Il vous faudra python3-markdown d'installé )
Le format de rédaction envisagé, pour sa simplicité et lisibilité en format texte, serait le Common Markdown. Nous souhaitons avoir des retours sur ces questions, peut être qu'une autre solution vous semblerait plus adaptée ?
Notons que si cette solution est employée, nous serions intéressés par des compétences de designer web. Si vous savez où trouvé quelqu'un d'intéressé et compétent, nous serons ravis de voir les volontaires. ;)
Oui, nous en avons grandement besoins. Car mes compétences en ce domaine sont grandement limitées :p
Sinon, je m’absente pendant 3 semaines (y compris pour la réunion de ce soir). Donc débrouillez vous sans moi :p (Et quand je rentre j’écris de la doc, promis juré)
Cordialement, Matthieu Gautier.
Le 29/08/2015 00:02, Charles-Antoine Couret a écrit :
Pour ma part, je souhaiterais bien mettre l'accent sur ce qui a attrait à la QA :
- Présentation de Rawhide, son intérêt, son fonctionnement, ses risques
- Le dépôt update-testing et la remontée des anomalies (dont fedora-easy-karma ou Bodhi)
- Description du cycle de vie d'une version : chaque étape de son élaboration jusqu'à la fin de son support officiel.
Je pense que c'est déjà pas mal sur le sujet, il y a de quoi faire avec. Si vous avez des commentaires sur ces sujets, je suis preneur.
Bonsoir, J'ai avancé dans l'idée de la méthode de travail dont vous pouvez en voir l'ébauche par ici : https://git.fedorahosted.org/cgit/Muffin.git/tree/LISEZMOI
J'ai essayé d'être simple et concis. J'espère que cela conviendra, je suis preneur de retours. La syntaxe Markdown est voulu pour en faire un exemple et il est selon moi suffisamment lisible même sans traitement.
Je peux par conséquent pousser des articles sur le dépôt Git maintenant, ceux qui sont intéressés par la rédaction peuvent envoyer leurs travaux ou idées. Je peux également ajouter des accès en écriture sur le dépôt à ceux qui en auraient besoin.
Personnellement je me lance dans la rédaction de articles cités plus haut. Étant donné notre avancement technique et celui du cycle de la Fedora 23 qui est particulièrement ponctuelle, je pense qu'aucun numéro n'est à prévoir avant Fedora 24. Ce qui laisse le temps de mettre en place tout le processus proprement.
Merci d'avance pour vos retours ou idées. ;) Passez une bonne soirée. Charles-Antoine Couret — Renault
fr-users@lists.fedoraproject.org
-
Charles-Antoine Couret -
Matthieu Gautier