User: jpmcc Date: 2009-10-07 04:59:00+0000 Modified: native-lang/www/planet/atom.xml native-lang/www/planet/foafroll.xml native-lang/www/planet/index.html native-lang/www/planet/opml.xml native-lang/www/planet/rss10.xml native-lang/www/planet/rss20.xml
Log: Planet run at Wed Oct 7 06:00:49 BST 2009 File Changes: Directory: /native-lang/www/planet/ =================================== File [changed]: atom.xml Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/atom.xml?r1=1.2231&r2=1.2232 Delta lines: +76 -2 -------------------- --- atom.xml 2009-10-06 23:00:51+0000 1.2231 +++ atom.xml 2009-10-07 04:58:58+0000 1.2232 @@ -5,7 +5,7 @@ <link rel="self" href="http://native-lang.openoffice.org/planet/atom.xml"/> <link href="http://native-lang.openoffice.org/planet/"/> <id>http://native-lang.openoffice.org/planet/atom.xml</id> - <updated>2009-10-06T23:02:38+00:00</updated> + <updated>2009-10-07T05:00:53+00:00</updated> <generator uri="http://www.planetplanet.org/";>Planet/2.0 +http://www.planetplanet.org</generator> <entry> @@ -29,6 +29,37 @@ </source> </entry> + <entry xml:lang="fr"> + <title type="html">Les icônes ODF</title> + <link href="http://sophiegautier.com/blog/index.php/2009/10/04/126-les-icones-odf"/> + <id>tag:sophiegautier.com,2009-10-04:/blog/126</id> + <updated>2009-10-04T08:47:09+00:00</updated> + <content type="html"><p>Les icônes d'OpenOffice.org vont changer, peut-être pour la version prochaine ou la suivante. La discussion est en cours sur le projet User Experience.<br /></p> + + +<p>Si vous souhaitez voir comment seront ces icônes, du moins comment elles sont actuellement, c'est sur le projet <a href="http://odftoolkit.org/pages/ODF-Icons" hreflang="en">ODF Toolkit</a>. Voilà pour le comment, même s'il n'est pas définitif, car les icônes en 16x16 sont actuellement retravaillées et beaucoup critiquent le manque de couleur qui permet de repérer facilement le type de document dans un gestionnaire de fichier.<br /></p> + + +<p>Sur le pourquoi maintenant, eh bien, ceux qui m'ont déjà écouté savent que depuis quelques années je leur dit que peut importe l'outil, c'est la donnée qui est importante et au coeur de votre patrimoine, c'est cela qui vous appartient. Cette donnée est véhiculée par un format, et pour qu'elle puisse rester vivante, échangeable, lisible, qu'elle puisse rester votre création, votre expression à travers le temps, il faut que ce format soit ouvert, documenté, standardisé et normalisé et ce pour tous les types de données que vous produisez, que ce soit du texte, des calculs, des dessins, peu importe.<br /> +Le format ODF, basé sur le XML, est explicitement développé pour cela. C'est également le seul qui soit implémenté dans plusieurs suites bureautiques et dont l'interopérabilité est travaillée, comparée et sans cesse améliorée.<br /></p> + + +<p>L'idée est donc d'oublier le logiciel qui a servi à créer ces données pour se concentrer sur leur format et ainsi de mettre également en avant ce format, qui est multiplateforme et neutre par rapport à l'outil qui l'a produit et donc par rapport à son éditeur. <br /> +<br /> +C'est donc très important, et ce pourquoi la communauté souhaite prendre le temps de travailler au mieux ces icônes, avoir le retour des utilisateurs sur leur usabilité. Mais également prendre le temps d'en décider avec les autres communautés qui utilisent le format ODF au sein de leurs outils, cela doit être un consensus des éditeurs pour être une réussite et une force pour nos produits et notre format. N'hésitez pas donc à venir en discuter sur nos listes, le fil est ouvert :-)</p></content> + <author> + <name>sophi</name> + <uri>http://sophiegautier.com/blog/index.php/</uri> + </author> + <source> + <title type="html">Sgauti at OOo</title> + <subtitle type="html">Histoires OpenOfficiennes et autres...</subtitle> + <link rel="self" href="http://sophiegautier.com/blog/atom.php"/> + <id>tag:sophiegautier.com,2009:/blog/index.php/</id> + <updated>2009-10-07T05:00:50+00:00</updated> + </source> + </entry> + <entry> <title type="html">Registration is open</title> <link href="http://lodahl.blogspot.com/2009/10/registration-is-open.html"/> @@ -129,7 +160,7 @@ <title type="html">andreasma_at_ooo</title> <link rel="self" href="http://andreasmaooo.blogger.de/rss"/> <id>http://andreasmaooo.blogger.de/rss</id> - <updated>2009-10-06T23:02:28+00:00</updated> + <updated>2009-10-07T05:00:51+00:00</updated> </source> </entry> @@ -238,6 +269,49 @@ </source> </entry> + <entry xml:lang="fr"> + <title type="html">CWS QA suite</title> + <link href="http://sophiegautier.com/blog/index.php/2009/09/13/125-cws-qa-suite"/> + <id>tag:sophiegautier.com,2009-09-13:/blog/125</id> + <updated>2009-09-13T16:04:24+00:00</updated> + <content type="html"><p>Cette fois-ci quelques réflexions sur le QA d'un cws contenant des nouvelles fonctionnalités. <br /></p> + + +<p>C'est assez long de faire la QA sur ces parties du code que sont les nouvelles fonctionnalités car il y a pas mal de tâches à effectuer en dehors de simplement vérifier les issues qui font partie du cws.<br /></p> + + +<p>Tout d'abord, lecture des spécifications (5 dans ce cas). C'est drôle que les développeurs n'aiment pas écrire les spécifications parce que tout le travail de la QA, de la localisation et de la documentation de l'aide, découle ensuite de ces spécifications. Sans celles-ci, impossible d'avoir une vision cohérente des diverses issues qui regroupent la fonctionnalité, pas de vision ux, pas de possibilité d'anticiper la localisation et la documentation avant qu'elle soit implémentée, donc trop tard pour faire un travail de qualité en amont et voir, pendant les tests, si c'est complet et implémenté de façon correcte.<br /></p> + + +<p>Ensuite, ou en même temps, build des versions Linux et Windows. Là , gros problème, la ferme de bots que nous utilisons est saturée lorsque nous arrivons en période proche du features freeze. Cela fait 28 versions en attente de build pour Windows (à raison d'environ 6 h par build ça donne une idée du délai avant que la sienne soit dispo), idem pour Linux et pire pour Solaris. Il faut donc que nous fassions quelque chose pour ces bots, soit que le process d'utilisation soit plus cohérent, soit que nous en ayons plus. <br /></p> + + +<p>Une fois les builds dispo, les VCLTestTools doivent être créés, ce n'est pas ma partie ;-) afin que la nouvelle fonctionnalité dispose des tests automatiques. Je me suis donc mise à la rédaction des TCS, tests manuels, qui permettent de tester tous les cas de figure de l'utilisation de la fonctionnalité en fonction de leur description dans les specs. J'ai donc écrit 3 TCS relatifs à plusieurs issues. En même temps que réaliser les tests que j'écrivais. C'est assez long, en cumulant les temps, c'est environ 3 jours d'écriture et de tests. +<br /> +Viennent ensuite les tests automatiques, mais là , c'est connu, c'est environ trois jours entre le run, la vérification, le re-run et la mise en ligne sur QASTe. +<br /> +Une fois que chacun a fini sa partie&nbsp;: automation, tests manuel, documentation de l'aide, le cws est approuvé par le QARep et l'intégration sera faite dans la prochaine version. Il faudra alors de nouveau tester les issues à l'aide des TCS et vérifier que tout se comporte comme annoncé dans les specs dans le master. +<br /><br /></p> + + +<p>Tout est lié&nbsp;: les issues renvoient vers les TCS et les specs, les specs renvoient vers les issues et les TCS, les TCS renvoient vers les issues, les specs et l'automation. Pour exemple, voir l'issue <a href="http://www.openoffice.org/issues/show_bug.cgi?id=7049" hreflang="en">7049</a>.<br /><br /></p> + + +<p>Ce lien permet alors à la localization de prendre le relais avant même que les fonctions soient intégrées dans la version et de s'assurer que la traduction, bien que complètement hors contexte, soit cohérente et exacte.<br /> +à nouveau, c'est un beau travail d'équipe, et je suis très contente d'avoir pu contribuer dans les délais à ce que ces nouvelles fonctionnalités soient intégrées à la 3.2. Un grand merci à l'e-team qui m'a aidée tout au long des étapes :-)</p></content> + <author> + <name>sophi</name> + <uri>http://sophiegautier.com/blog/index.php/</uri> + </author> + <source> + <title type="html">Sgauti at OOo</title> + <subtitle type="html">Histoires OpenOfficiennes et autres...</subtitle> + <link rel="self" href="http://sophiegautier.com/blog/atom.php"/> + <id>tag:sophiegautier.com,2009:/blog/index.php/</id> + <updated>2009-10-07T05:00:50+00:00</updated> + </source> + </entry> + <entry> <title type="html">Export from OpenOffice to Freemind</title> <link href="http://lodahl.blogspot.com/2009/09/export-from-openoffice-to-freemind.html"/> File [changed]: foafroll.xml Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/foafroll.xml?r1=1.17&r2=1.18 Delta lines: +2 -2 ------------------- --- foafroll.xml 2009-10-06 23:00:51+0000 1.17 +++ foafroll.xml 2009-10-07 04:58:58+0000 1.18 @@ -80,8 +80,8 @@ <foaf:Agent> <foaf:name>Sophie Gautier</foaf:name> <foaf:weblog> - <foaf:Document rdf:about=""> - <dc:title></dc:title> + <foaf:Document rdf:about="http://sophiegautier.com/blog/index.php/";> + <dc:title>Sgauti at OOo</dc:title> <rdfs:seeAlso> <rss:channel rdf:about="http://sophiegautier.com/blog/atom.php"; /> </rdfs:seeAlso> File [changed]: index.html Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/index.html?r1=1.2231&r2=1.2232 Delta lines: +66 -2 -------------------- --- index.html 2009-10-06 23:00:51+0000 1.2231 +++ index.html 2009-10-07 04:58:58+0000 1.2232 @@ -20,7 +20,7 @@ <a href="http://openoffice.exblog.jp"; title="Hirano, Kazunari">Kazunari Hirano</a> <a href="http://openoffice.exblog.jp/atom.xml";>(feed)</a><br /> <a href="http://lodahl.blogspot.com/"; title="Lodahl's blog">Leif Lodahl</a> <a href="http://lodahl.blogspot.com/feeds/posts/default";>(feed)</a><br /> <a href="http://ooo-speak.blogspot.com/"; title="ooo-speak">Louis Suarez-Potts</a> <a href="http://ooo-speak.blogspot.com/feeds/posts/default";>(feed)</a><br /> -<a href="" title="">Sophie Gautier</a> <a href="http://sophiegautier.com/blog/atom.php";>(feed)</a><br /> +<a href="http://sophiegautier.com/blog/index.php/"; title="Sgauti at OOo">Sophie Gautier</a> <a href="http://sophiegautier.com/blog/atom.php";>(feed)</a><br /> <h2>Feeds</h2> <a href="atom.xml"><img src="atom.gif" alt="link to Atom feed" /></a><br /> @@ -29,7 +29,7 @@ <a href="rss20.xml"><img src="rss2.gif" alt="Link to RSS 2 feed" /></a> </div> -<p><em>Bloggings on native language topics by project members - see <a href="#disclaimer">disclaimer</a>.<br />Last updated: October 06, 2009 11:02 PM GMT</em></p> +<p><em>Bloggings on native language topics by project members - see <a href="#disclaimer">disclaimer</a>.<br />Last updated: October 07, 2009 05:00 AM GMT</em></p> <h2>October 04, 2009</h2> <h3> @@ -46,6 +46,32 @@ <br /> <hr /> <br /> +<h3> +<a href="http://sophiegautier.com/blog/index.php/"; title="Sgauti at OOo"> +Sophie Gautier</a> : +<a href="http://sophiegautier.com/blog/index.php/2009/10/04/126-les-icones-odf";> +Les icônes ODF</a> +</h3> +<p> +<p>Les icônes d'OpenOffice.org vont changer, peut-être pour la version prochaine ou la suivante. La discussion est en cours sur le projet User Experience.<br /></p> + + +<p>Si vous souhaitez voir comment seront ces icônes, du moins comment elles sont actuellement, c'est sur le projet <a href="http://odftoolkit.org/pages/ODF-Icons"; hreflang="en">ODF Toolkit</a>. Voilà pour le comment, même s'il n'est pas définitif, car les icônes en 16x16 sont actuellement retravaillées et beaucoup critiquent le manque de couleur qui permet de repérer facilement le type de document dans un gestionnaire de fichier.<br /></p> + + +<p>Sur le pourquoi maintenant, eh bien, ceux qui m'ont déjà écouté savent que depuis quelques années je leur dit que peut importe l'outil, c'est la donnée qui est importante et au coeur de votre patrimoine, c'est cela qui vous appartient. Cette donnée est véhiculée par un format, et pour qu'elle puisse rester vivante, échangeable, lisible, qu'elle puisse rester votre création, votre expression à travers le temps, il faut que ce format soit ouvert, documenté, standardisé et normalisé et ce pour tous les types de données que vous produisez, que ce soit du texte, des calculs, des dessins, peu importe.<br /> +Le format ODF, basé sur le XML, est explicitement développé pour cela. C'est également le seul qui soit implémenté dans plusieurs suites bureautiques et dont l'interopérabilité est travaillée, comparée et sans cesse améliorée.<br /></p> + + +<p>L'idée est donc d'oublier le logiciel qui a servi à créer ces données pour se concentrer sur leur format et ainsi de mettre également en avant ce format, qui est multiplateforme et neutre par rapport à l'outil qui l'a produit et donc par rapport à son éditeur. <br /> +<br /> +C'est donc très important, et ce pourquoi la communauté souhaite prendre le temps de travailler au mieux ces icônes, avoir le retour des utilisateurs sur leur usabilité. Mais également prendre le temps d'en décider avec les autres communautés qui utilisent le format ODF au sein de leurs outils, cela doit être un consensus des éditeurs pour être une réussite et une force pour nos produits et notre format. N'hésitez pas donc à venir en discuter sur nos listes, le fil est ouvert :-)</p></p> +<p> +<em><a href="http://sophiegautier.com/blog/index.php/2009/10/04/126-les-icones-odf";>by sophi at October 04, 2009 08:47 AM GMT</a></em> +</p> +<br /> +<hr /> +<br /> <h2>October 01, 2009</h2> <h3> <a href="http://lodahl.blogspot.com/"; title="Lodahl's blog"> @@ -198,6 +224,44 @@ <br /> <hr /> <br /> +<h3> +<a href="http://sophiegautier.com/blog/index.php/"; title="Sgauti at OOo"> +Sophie Gautier</a> : +<a href="http://sophiegautier.com/blog/index.php/2009/09/13/125-cws-qa-suite";> +CWS QA suite</a> +</h3> +<p> +<p>Cette fois-ci quelques réflexions sur le QA d'un cws contenant des nouvelles fonctionnalités. <br /></p> + + +<p>C'est assez long de faire la QA sur ces parties du code que sont les nouvelles fonctionnalités car il y a pas mal de tâches à effectuer en dehors de simplement vérifier les issues qui font partie du cws.<br /></p> + + +<p>Tout d'abord, lecture des spécifications (5 dans ce cas). C'est drôle que les développeurs n'aiment pas écrire les spécifications parce que tout le travail de la QA, de la localisation et de la documentation de l'aide, découle ensuite de ces spécifications. Sans celles-ci, impossible d'avoir une vision cohérente des diverses issues qui regroupent la fonctionnalité, pas de vision ux, pas de possibilité d'anticiper la localisation et la documentation avant qu'elle soit implémentée, donc trop tard pour faire un travail de qualité en amont et voir, pendant les tests, si c'est complet et implémenté de façon correcte.<br /></p> + + +<p>Ensuite, ou en même temps, build des versions Linux et Windows. Là , gros problème, la ferme de bots que nous utilisons est saturée lorsque nous arrivons en période proche du features freeze. Cela fait 28 versions en attente de build pour Windows (à raison d'environ 6 h par build ça donne une idée du délai avant que la sienne soit dispo), idem pour Linux et pire pour Solaris. Il faut donc que nous fassions quelque chose pour ces bots, soit que le process d'utilisation soit plus cohérent, soit que nous en ayons plus. <br /></p> + + +<p>Une fois les builds dispo, les VCLTestTools doivent être créés, ce n'est pas ma partie ;-) afin que la nouvelle fonctionnalité dispose des tests automatiques. Je me suis donc mise à la rédaction des TCS, tests manuels, qui permettent de tester tous les cas de figure de l'utilisation de la fonctionnalité en fonction de leur description dans les specs. J'ai donc écrit 3 TCS relatifs à plusieurs issues. En même temps que réaliser les tests que j'écrivais. C'est assez long, en cumulant les temps, c'est environ 3 jours d'écriture et de tests. +<br /> +Viennent ensuite les tests automatiques, mais là , c'est connu, c'est environ trois jours entre le run, la vérification, le re-run et la mise en ligne sur QASTe. +<br /> +Une fois que chacun a fini sa partie : automation, tests manuel, documentation de l'aide, le cws est approuvé par le QARep et l'intégration sera faite dans la prochaine version. Il faudra alors de nouveau tester les issues à l'aide des TCS et vérifier que tout se comporte comme annoncé dans les specs dans le master. +<br /><br /></p> + + +<p>Tout est lié : les issues renvoient vers les TCS et les specs, les specs renvoient vers les issues et les TCS, les TCS renvoient vers les issues, les specs et l'automation. Pour exemple, voir l'issue <a href="http://www.openoffice.org/issues/show_bug.cgi?id=7049"; hreflang="en">7049</a>.<br /><br /></p> + + +<p>Ce lien permet alors à la localization de prendre le relais avant même que les fonctions soient intégrées dans la version et de s'assurer que la traduction, bien que complètement hors contexte, soit cohérente et exacte.<br /> +à nouveau, c'est un beau travail d'équipe, et je suis très contente d'avoir pu contribuer dans les délais à ce que ces nouvelles fonctionnalités soient intégrées à la 3.2. Un grand merci à l'e-team qui m'a aidée tout au long des étapes :-)</p></p> +<p> +<em><a href="http://sophiegautier.com/blog/index.php/2009/09/13/125-cws-qa-suite";>by sophi at September 13, 2009 04:04 PM GMT</a></em> +</p> +<br /> +<hr /> +<br /> <h2>September 11, 2009</h2> <h3> <a href="http://lodahl.blogspot.com/"; title="Lodahl's blog"> File [changed]: opml.xml Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/opml.xml?r1=1.2231&r2=1.2232 Delta lines: +2 -2 ------------------- --- opml.xml 2009-10-06 23:00:51+0000 1.2231 +++ opml.xml 2009-10-07 04:58:58+0000 1.2232 @@ -2,7 +2,7 @@ <opml version="1.1"> <head> <title>Native Language Confederation Planet</title> - <dateModified>Tue, 06 Oct 2009 23:02:39 +0000</dateModified> + <dateModified>Wed, 07 Oct 2009 05:00:53 +0000</dateModified> <ownerName>Native Language Confederation</ownerName> <ownerEmail>[email protected]</ownerEmail> </head> @@ -13,6 +13,6 @@ <outline type="rss" text="Kazunari Hirano" xmlUrl="http://openoffice.exblog.jp/atom.xml"; title="Hirano, Kazunari" /> <outline type="rss" text="Leif Lodahl" xmlUrl="http://lodahl.blogspot.com/feeds/posts/default"; title="Lodahl's blog" /> <outline type="rss" text="Louis Suarez-Potts" xmlUrl="http://ooo-speak.blogspot.com/feeds/posts/default"; title="ooo-speak" /> - <outline type="rss" text="Sophie Gautier" xmlUrl="http://sophiegautier.com/blog/atom.php"; title="Sophie Gautier" /> + <outline type="rss" text="Sophie Gautier" xmlUrl="http://sophiegautier.com/blog/atom.php"; title="Sgauti at OOo" /> </body> </opml> File [changed]: rss10.xml Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/rss10.xml?r1=1.365&r2=1.366 Delta lines: +52 -0 -------------------- --- rss10.xml 2009-10-06 23:00:51+0000 1.365 +++ rss10.xml 2009-10-07 04:58:58+0000 1.366 @@ -14,6 +14,7 @@ <items> <rdf:Seq> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-4355851502853257168" /> + <rdf:li rdf:resource="tag:sophiegautier.com,2009-10-04:/blog/126" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-3332540983495316552" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-2624949812557043852" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-8718185590131291864" /> @@ -24,6 +25,7 @@ <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-5709986009541236722" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-5486205329387361513" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-8461353888835594890" /> + <rdf:li rdf:resource="tag:sophiegautier.com,2009-09-13:/blog/125" /> <rdf:li rdf:resource="tag:blogger.com,1999:blog-5198340507565233169.post-8061074245084276781" /> </rdf:Seq> </items> @@ -36,6 +38,25 @@ <dc:date>2009-10-04T22:22:05+00:00</dc:date> <dc:creator>Leif Lodahl</dc:creator> </item> +<item rdf:about="tag:sophiegautier.com,2009-10-04:/blog/126"> + <title>Sophie Gautier: Les icônes ODF</title> + <link>http://sophiegautier.com/blog/index.php/2009/10/04/126-les-icones-odf</link> + <content:encoded><p>Les icônes d'OpenOffice.org vont changer, peut-être pour la version prochaine ou la suivante. La discussion est en cours sur le projet User Experience.<br /></p> + + +<p>Si vous souhaitez voir comment seront ces icônes, du moins comment elles sont actuellement, c'est sur le projet <a href="http://odftoolkit.org/pages/ODF-Icons" hreflang="en">ODF Toolkit</a>. Voilà pour le comment, même s'il n'est pas définitif, car les icônes en 16x16 sont actuellement retravaillées et beaucoup critiquent le manque de couleur qui permet de repérer facilement le type de document dans un gestionnaire de fichier.<br /></p> + + +<p>Sur le pourquoi maintenant, eh bien, ceux qui m'ont déjà écouté savent que depuis quelques années je leur dit que peut importe l'outil, c'est la donnée qui est importante et au coeur de votre patrimoine, c'est cela qui vous appartient. Cette donnée est véhiculée par un format, et pour qu'elle puisse rester vivante, échangeable, lisible, qu'elle puisse rester votre création, votre expression à travers le temps, il faut que ce format soit ouvert, documenté, standardisé et normalisé et ce pour tous les types de données que vous produisez, que ce soit du texte, des calculs, des dessins, peu importe.<br /> +Le format ODF, basé sur le XML, est explicitement développé pour cela. C'est également le seul qui soit implémenté dans plusieurs suites bureautiques et dont l'interopérabilité est travaillée, comparée et sans cesse améliorée.<br /></p> + + +<p>L'idée est donc d'oublier le logiciel qui a servi à créer ces données pour se concentrer sur leur format et ainsi de mettre également en avant ce format, qui est multiplateforme et neutre par rapport à l'outil qui l'a produit et donc par rapport à son éditeur. <br /> +<br /> +C'est donc très important, et ce pourquoi la communauté souhaite prendre le temps de travailler au mieux ces icônes, avoir le retour des utilisateurs sur leur usabilité. Mais également prendre le temps d'en décider avec les autres communautés qui utilisent le format ODF au sein de leurs outils, cela doit être un consensus des éditeurs pour être une réussite et une force pour nos produits et notre format. N'hésitez pas donc à venir en discuter sur nos listes, le fil est ouvert :-)</p></content:encoded> + <dc:date>2009-10-04T08:47:09+00:00</dc:date> + <dc:creator>sophi</dc:creator> +</item> <item rdf:about="tag:blogger.com,1999:blog-5198340507565233169.post-3332540983495316552"> <title>Leif Lodahl: Registration is open</title> <link>http://lodahl.blogspot.com/2009/10/registration-is-open.html</link> @@ -107,6 +128,37 @@ <dc:date>2009-09-13T18:38:40+00:00</dc:date> <dc:creator>Leif Lodahl</dc:creator> </item> +<item rdf:about="tag:sophiegautier.com,2009-09-13:/blog/125"> + <title>Sophie Gautier: CWS QA suite</title> + <link>http://sophiegautier.com/blog/index.php/2009/09/13/125-cws-qa-suite</link> + <content:encoded><p>Cette fois-ci quelques réflexions sur le QA d'un cws contenant des nouvelles fonctionnalités. <br /></p> + + +<p>C'est assez long de faire la QA sur ces parties du code que sont les nouvelles fonctionnalités car il y a pas mal de tâches à effectuer en dehors de simplement vérifier les issues qui font partie du cws.<br /></p> + + +<p>Tout d'abord, lecture des spécifications (5 dans ce cas). C'est drôle que les développeurs n'aiment pas écrire les spécifications parce que tout le travail de la QA, de la localisation et de la documentation de l'aide, découle ensuite de ces spécifications. Sans celles-ci, impossible d'avoir une vision cohérente des diverses issues qui regroupent la fonctionnalité, pas de vision ux, pas de possibilité d'anticiper la localisation et la documentation avant qu'elle soit implémentée, donc trop tard pour faire un travail de qualité en amont et voir, pendant les tests, si c'est complet et implémenté de façon correcte.<br /></p> + + +<p>Ensuite, ou en même temps, build des versions Linux et Windows. Là , gros problème, la ferme de bots que nous utilisons est saturée lorsque nous arrivons en période proche du features freeze. Cela fait 28 versions en attente de build pour Windows (à raison d'environ 6 h par build ça donne une idée du délai avant que la sienne soit dispo), idem pour Linux et pire pour Solaris. Il faut donc que nous fassions quelque chose pour ces bots, soit que le process d'utilisation soit plus cohérent, soit que nous en ayons plus. <br /></p> + + +<p>Une fois les builds dispo, les VCLTestTools doivent être créés, ce n'est pas ma partie ;-) afin que la nouvelle fonctionnalité dispose des tests automatiques. Je me suis donc mise à la rédaction des TCS, tests manuels, qui permettent de tester tous les cas de figure de l'utilisation de la fonctionnalité en fonction de leur description dans les specs. J'ai donc écrit 3 TCS relatifs à plusieurs issues. En même temps que réaliser les tests que j'écrivais. C'est assez long, en cumulant les temps, c'est environ 3 jours d'écriture et de tests. +<br /> +Viennent ensuite les tests automatiques, mais là , c'est connu, c'est environ trois jours entre le run, la vérification, le re-run et la mise en ligne sur QASTe. +<br /> +Une fois que chacun a fini sa partie&nbsp;: automation, tests manuel, documentation de l'aide, le cws est approuvé par le QARep et l'intégration sera faite dans la prochaine version. Il faudra alors de nouveau tester les issues à l'aide des TCS et vérifier que tout se comporte comme annoncé dans les specs dans le master. +<br /><br /></p> + + +<p>Tout est lié&nbsp;: les issues renvoient vers les TCS et les specs, les specs renvoient vers les issues et les TCS, les TCS renvoient vers les issues, les specs et l'automation. Pour exemple, voir l'issue <a href="http://www.openoffice.org/issues/show_bug.cgi?id=7049" hreflang="en">7049</a>.<br /><br /></p> + + +<p>Ce lien permet alors à la localization de prendre le relais avant même que les fonctions soient intégrées dans la version et de s'assurer que la traduction, bien que complètement hors contexte, soit cohérente et exacte.<br /> +à nouveau, c'est un beau travail d'équipe, et je suis très contente d'avoir pu contribuer dans les délais à ce que ces nouvelles fonctionnalités soient intégrées à la 3.2. Un grand merci à l'e-team qui m'a aidée tout au long des étapes :-)</p></content:encoded> + <dc:date>2009-09-13T16:04:24+00:00</dc:date> + <dc:creator>sophi</dc:creator> +</item> <item rdf:about="tag:blogger.com,1999:blog-5198340507565233169.post-8061074245084276781"> <title>Leif Lodahl: Export from OpenOffice to Freemind</title> <link>http://lodahl.blogspot.com/2009/09/export-from-openoffice-to-freemind.html</link> File [changed]: rss20.xml Url: http://native-lang.openoffice.org/source/browse/native-lang/www/planet/rss20.xml?r1=1.366&r2=1.367 Delta lines: +50 -0 -------------------- --- rss20.xml 2009-10-06 23:00:51+0000 1.366 +++ rss20.xml 2009-10-07 04:58:58+0000 1.367 @@ -16,6 +16,25 @@ <author>[email protected] (Leif Lodahl)</author> </item> <item> + <title>Sophie Gautier: Les icônes ODF</title> + <guid>tag:sophiegautier.com,2009-10-04:/blog/126</guid> + <link>http://sophiegautier.com/blog/index.php/2009/10/04/126-les-icones-odf</link> + <description><p>Les icônes d'OpenOffice.org vont changer, peut-être pour la version prochaine ou la suivante. La discussion est en cours sur le projet User Experience.<br /></p> + + +<p>Si vous souhaitez voir comment seront ces icônes, du moins comment elles sont actuellement, c'est sur le projet <a href="http://odftoolkit.org/pages/ODF-Icons" hreflang="en">ODF Toolkit</a>. Voilà pour le comment, même s'il n'est pas définitif, car les icônes en 16x16 sont actuellement retravaillées et beaucoup critiquent le manque de couleur qui permet de repérer facilement le type de document dans un gestionnaire de fichier.<br /></p> + + +<p>Sur le pourquoi maintenant, eh bien, ceux qui m'ont déjà écouté savent que depuis quelques années je leur dit que peut importe l'outil, c'est la donnée qui est importante et au coeur de votre patrimoine, c'est cela qui vous appartient. Cette donnée est véhiculée par un format, et pour qu'elle puisse rester vivante, échangeable, lisible, qu'elle puisse rester votre création, votre expression à travers le temps, il faut que ce format soit ouvert, documenté, standardisé et normalisé et ce pour tous les types de données que vous produisez, que ce soit du texte, des calculs, des dessins, peu importe.<br /> +Le format ODF, basé sur le XML, est explicitement développé pour cela. C'est également le seul qui soit implémenté dans plusieurs suites bureautiques et dont l'interopérabilité est travaillée, comparée et sans cesse améliorée.<br /></p> + + +<p>L'idée est donc d'oublier le logiciel qui a servi à créer ces données pour se concentrer sur leur format et ainsi de mettre également en avant ce format, qui est multiplateforme et neutre par rapport à l'outil qui l'a produit et donc par rapport à son éditeur. <br /> +<br /> +C'est donc très important, et ce pourquoi la communauté souhaite prendre le temps de travailler au mieux ces icônes, avoir le retour des utilisateurs sur leur usabilité. Mais également prendre le temps d'en décider avec les autres communautés qui utilisent le format ODF au sein de leurs outils, cela doit être un consensus des éditeurs pour être une réussite et une force pour nos produits et notre format. N'hésitez pas donc à venir en discuter sur nos listes, le fil est ouvert :-)</p></description> + <pubDate>Sun, 04 Oct 2009 08:47:09 +0000</pubDate> +</item> +<item> <title>Leif Lodahl: Registration is open</title> <guid>tag:blogger.com,1999:blog-5198340507565233169.post-3332540983495316552</guid> <link>http://lodahl.blogspot.com/2009/10/registration-is-open.html</link> @@ -97,6 +116,37 @@ <author>[email protected] (Leif Lodahl)</author> </item> <item> + <title>Sophie Gautier: CWS QA suite</title> + <guid>tag:sophiegautier.com,2009-09-13:/blog/125</guid> + <link>http://sophiegautier.com/blog/index.php/2009/09/13/125-cws-qa-suite</link> + <description><p>Cette fois-ci quelques réflexions sur le QA d'un cws contenant des nouvelles fonctionnalités. <br /></p> + + +<p>C'est assez long de faire la QA sur ces parties du code que sont les nouvelles fonctionnalités car il y a pas mal de tâches à effectuer en dehors de simplement vérifier les issues qui font partie du cws.<br /></p> + + +<p>Tout d'abord, lecture des spécifications (5 dans ce cas). C'est drôle que les développeurs n'aiment pas écrire les spécifications parce que tout le travail de la QA, de la localisation et de la documentation de l'aide, découle ensuite de ces spécifications. Sans celles-ci, impossible d'avoir une vision cohérente des diverses issues qui regroupent la fonctionnalité, pas de vision ux, pas de possibilité d'anticiper la localisation et la documentation avant qu'elle soit implémentée, donc trop tard pour faire un travail de qualité en amont et voir, pendant les tests, si c'est complet et implémenté de façon correcte.<br /></p> + + +<p>Ensuite, ou en même temps, build des versions Linux et Windows. Là , gros problème, la ferme de bots que nous utilisons est saturée lorsque nous arrivons en période proche du features freeze. Cela fait 28 versions en attente de build pour Windows (à raison d'environ 6 h par build ça donne une idée du délai avant que la sienne soit dispo), idem pour Linux et pire pour Solaris. Il faut donc que nous fassions quelque chose pour ces bots, soit que le process d'utilisation soit plus cohérent, soit que nous en ayons plus. <br /></p> + + +<p>Une fois les builds dispo, les VCLTestTools doivent être créés, ce n'est pas ma partie ;-) afin que la nouvelle fonctionnalité dispose des tests automatiques. Je me suis donc mise à la rédaction des TCS, tests manuels, qui permettent de tester tous les cas de figure de l'utilisation de la fonctionnalité en fonction de leur description dans les specs. J'ai donc écrit 3 TCS relatifs à plusieurs issues. En même temps que réaliser les tests que j'écrivais. C'est assez long, en cumulant les temps, c'est environ 3 jours d'écriture et de tests. +<br /> +Viennent ensuite les tests automatiques, mais là , c'est connu, c'est environ trois jours entre le run, la vérification, le re-run et la mise en ligne sur QASTe. +<br /> +Une fois que chacun a fini sa partie&nbsp;: automation, tests manuel, documentation de l'aide, le cws est approuvé par le QARep et l'intégration sera faite dans la prochaine version. Il faudra alors de nouveau tester les issues à l'aide des TCS et vérifier que tout se comporte comme annoncé dans les specs dans le master. +<br /><br /></p> + + +<p>Tout est lié&nbsp;: les issues renvoient vers les TCS et les specs, les specs renvoient vers les issues et les TCS, les TCS renvoient vers les issues, les specs et l'automation. Pour exemple, voir l'issue <a href="http://www.openoffice.org/issues/show_bug.cgi?id=7049" hreflang="en">7049</a>.<br /><br /></p> + + +<p>Ce lien permet alors à la localization de prendre le relais avant même que les fonctions soient intégrées dans la version et de s'assurer que la traduction, bien que complètement hors contexte, soit cohérente et exacte.<br /> +à nouveau, c'est un beau travail d'équipe, et je suis très contente d'avoir pu contribuer dans les délais à ce que ces nouvelles fonctionnalités soient intégrées à la 3.2. Un grand merci à l'e-team qui m'a aidée tout au long des étapes :-)</p></description> + <pubDate>Sun, 13 Sep 2009 16:04:24 +0000</pubDate> +</item> +<item> <title>Leif Lodahl: Export from OpenOffice to Freemind</title> <guid>tag:blogger.com,1999:blog-5198340507565233169.post-8061074245084276781</guid> <link>http://lodahl.blogspot.com/2009/09/export-from-openoffice-to-freemind.html</link> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
