process-fr

Si c'est votre première visite, regardez svp la page d'introduction.

Ainsi vous voulez développer un nouveau microformat ?

Pourquoi ?

Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.

Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvons d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ensuite seulement élaborer des solutions pour résoudre des problèmes plus complexes.

Egalement, cherchez sur le web. Il y a des chances pour que quelqu'un d'autre ait rencontré le même problème que vous. Si vous pensez toujours que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion microformats-discuss ou tout autre canal public (voir http://microformats.org/discuss/). Nous voulons engager toutes les parties intéressées dans la discussion. Commencez la discussion AVANT de commencer à créer quelques pages que ce soient sur le wiki. Nous n'utilisons pas le wiki comme un bloc-notes général. Si vous ne pouvez pas résumer le problème que vous essayez de résoudre dans un court email, et que vous sentez que vous avez besoin d'écrire un long document, vous essayez probablement de résoudre un trop gros problème - voir le paragraphe précédent.

Documentez les Comportements Existants

Documentez les comportements humains existants. Exemple du pourquoi d'abord ?

Souvenez vous, nous pavons les "chemins des vaches"- avant de faire ça, vous devez trouver les "chemins des vaches". Vos exemples devraient être une collection de pages et de sites réels, qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, il vous faut extraire des exemples de balisages et les schémas implicites à l'intérieur, et fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il vous sera impossible de le faire par vous-même (peu importe combien vous êtes). La page formats de critiques est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer hReview, les collaborateurs sont allés faire un tour, ont documenté les pratiques existantes concernant les critiques/compte-rendus (reviews) qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas impliqués dedans.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui se soit déjà frotté au même problème que celui qui vous occupe. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec d'autres qui ont rencontré le même problème. Nous ne voulons pas construire des murs entre des communautés concurrentes - nous voulons que les personnes travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

Proposez un Microformat

En fait, NE LE FAITES PAS !!!

Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :

1. Y'a t'il un élément standard en XHTML qui fonctionnerait ?
2. Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
3. Si les réponses aux deux questions précédentes sont 'non', nous pouvons discuter d'un microformat.

Pour plus de détails sur le XHTML sémantique, des exemples d'utilisation d'éléments XHTML, et sur la construction de combinaisons d'éléments XHTML, voir The Elements of Meaningful XHTML.

Tout d'abord, vous devriez regarder attentivement les principes des microformats.

Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe des standards bien établis, implémentés de façon interopérable, vers lesquels se tourner et qui solutionnent ce problème ?" ; Par exemple, hCard and hCalendar ont été construits d'après les standards de l'IETF pour vCard and iCal, respectivement, chacun d'eux étant largement implémenté de manière interopérable. Les développeurs de ces standards avaient déjà passé de nombreuses années dans des comités de standardisation, à défendre et à développer les schémas. Il est préférable de s'appuyer sur le travail de longue haleine que d'autres ont effectués avant vous, plutôt que de divaguer comme un inventeur tel un cow-boy solitaire, et perdre du temps à répéter les mêmes erreurs. Il est également plus facile de démarrer à partir d'un schéma bien établi, et d'en établir une correspondance en XHTML, plutôt que de développer un nouveau schéma.

Souvenez-vous, les microformats doivent être conçus d'abord pour les humains, et ensuite pour les machines. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :

1. Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas CSS, ou dont cette fonctionnalité a été désactivée, serait-il toujours lisible par un humain ?
2. Est-ce que les éléments de ce microformat sont stylisables avec CSS ?

Si le microformat proposé ne remplit pas ces conditions, il est peu vraisemblable qu'il soit éligible. Souvenez-vous : les humains d'abord, les machines ensuite.

Itération

Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de feedbacks de la part d'autres personnes intéressées par les microformats. La proposition devra alors être "itérée" et adaptée. Le développement d'un microformat devrait être collaboratif et fondé sur une communauté.

Voici un diagramme de flux ASCII-art :

DIAGRAMME :
énoncé du problème---->recherche/discussion---->proposition/"draft"---->standard
^________________V   ^___________________V   ^______________V

Notez que chaque étape implique une processus itératif. Cette itération consiste en une discussion et du feedback, et pourra entrainer des changements majeurs. Ne craignez pas de faire des changements majeurs et s'il vous plait ne vous attachez pas trop à quelques solutions particulières que ce soient.

Pages à créer

Un "pattern" a émergé des tentatives fructueuses pour développer des microformats : plusieurs sortes de pages wikis spécifiques sont créées dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème posé (*) ait été déterminé (principe n°1), envisagez de créer et de remplir les pages suivantes à son sujet. Si vous ne pouvez pas fournir quelque matière pour alimenter ces pages, vous devriez alors probablement reconsidérer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème. Nommez l'aire du problème(*) de façon générique et évitez spécifiquement les noms de code/nom de marque comme hNewCoolFormat. Bien : product-exemples. Mauvais : hProduct-exemples.

1. *-exemples. Chercher des exemples existants sur le web du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qu'impliquent ces exemples de contenu. Cette action vous aidera à respecter le principe n°3, conception pour les humains d'abord, et pour les machines ensuite... adaptez aux comportements courants et aux "patterns" d'usage. Commencez par cloner la page d'exemples et remplissez là.
2. *-formats. Trouvez des formats et des standards de données existants interopérables, largement adoptés, qui ont déjà tenté de résoudre le problème. Documentez leurs schémas explicites. Ceci est un pré-requis nécessaire pour continuer en respectant le principe n°4, "réutiliser des briques de standards largement adoptées".
3. *-brainstorming. Utiliser les exemples actuels du web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) afin de représenter leurs données. Oui, cela signifie que vous allez explicitement omettre quelques éléments de certains cas d'usages, ou peut-être des cas d'usages entiers, qui sont plus des cas limites, qu'ils ne sont représentatifs de comportements plus larges, de niveau agrégation/macro. Regardez quels microformats existants peuvent être réutilisés comme briques de construction (principe n°5, modularité). Utilisez ces formats et schémas de données existants comme une source de noms pour les champs (principe n°4). Etudiez comment vous embarqueriez ce microformat dans d'autres formats (aussi le principe n°5, "encapsulage").
4. Avec un schéma 80/20, et une source de noms de champs, écrivez une ou plusieurs propositions de "paille" pour un microformat dans la page *-brainstorming. Assurez-vous que les propositions de "paille" encouragent la distribution décentralisée des données (principe n°6). Repoussez le choix d'un nom de classe racine, car il chevauche souvent le nommage du microformat lui-même. Gardez toujours à portée de main les principes de nommage des microformats au moment de choisir des noms.
5. Le Brainstorming sur la substance du microformat (ses propriétés et valeurs) devrait précéder le nommage du microformat lui-même. Par conséquent après que les propositions aient été écritees et discutées pour les schéma, créez une section de nommage pour le microformat lui-même et le nom de classe racine, où différents noms peuvent être envisagés.
6. **. Quand il semble qu'il y a un certain niveau de consensus autour d'une des propositions de "paille" pour un microformat avec un nom spécifique(**), écrivez-la sous la forme d'une spécification "brouillon" sur une page séparée du wiki et puis commencez à créer les pages suivantes pour la suivre.
7. **-faq. Il y aura probablement des questions récurrentes à propos du nouveau microformat, qui pourront/devront être répondues sur une page FAQ.
8. **-problématiques. Il se peut également qu'il y en ait qui soulèvent des problématiques à propos du microformat, qui ne puissent pas être traitées immédiatemment. Un document dédié aidera en servant à enregistrer ces problématiques, en consignant qui les a soulevées et quand, de façon à ce que ceux qui travaillent sur le microformat soient assurés de pouvoir s'y atteler et y répondre pleinement.
9. **-exemples. En fait, il peut y avoir bien trop d'exemples du vrai monde d'un microformat pour le documenter dans une section informative en fin de spécification, de ce fait la liste mérite sa propre page.
10. **-implémentations. Eventuellement il se pourrait qu'il y ait trop d'implémentations d'un microformat pour les documenter dans une section informative à la fin des spécifications, cette liste méritant sa propre page.

Passer d'une Etape à une autre Etape

Ces étapes du développement sont réinscrites sur la page d'accueil où les microformats sont répartis dans les sections "Discussions exploratoires", "Brouillons" et "Spécifications". Comment les microformats passent-ils d'une étape à une autre ? Pour mieux répondre à cette question, il est probablement utile d'écrire un ensemble de desiderata pour chaque étape.

Discussions Exploratoires

Vous avez besoin d'un problème et il vous faut essayer de l'énoncer. Faites-le sur ce wiki en utilisant comme guide les items situés sous "Discussion Exploratoire". Envoyez ensuite une note à la liste microformats-discuss, pour attirer l'attention d'autres personnes qui s'intéressent aux microformats. Ceci est un probablement un bon moyen pour amener ici des personnes extérieures à la communauté actuelle des microformats et qui peuvent être confrontées à la même problématique.

Les réactions seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problème, questionner le besoin d'un microformat, être d'accord avec vos propositions ou en rajouter. Toute réaction constructive est saine.

La conséquence de cette réaction pourra être que vous décidiez d'abandonner votre idée de microformat, ou de la modifier substantiellement. Une chose que vous êtes certain de vouloir faire à ce stade, est d'éviter de réinventer la roue. Y a t'il des microformats élémentaires que vous pouvez réutiliser comme des "briques" ? En procédant ainsi, vous vous économiserez des efforts et cela vous aidera dans l'implémentation future, car les "implémenteurs" auront moins de travail à fournir.

Ceci étant ne soyez pas intimidé(e) pour aller de l'avant, juste parce que certaines personnes ont des objections. Si vous arrivez à trouver un groupe de personnes que vous respectez, qui sentent que votre idée a du mérite et, c'est peut être ça le plus important, qui désirent continuer à travailler avec vous pour la mettre en forme, allez-y.

Brouillons (Drafts)

Ici, vous devez écrire ce qui est essentiellement une spécification, mais en gardant à l'esprit qu'elle pourra grandement changer. Là encore, il vous faut aller sur le wiki, et vous devriez envoyer une note à la liste "microformats-discuss" pour prévenir les gens qu'il y a du nouveau. N'hésitez pas à continuer d'essayer de faire rentrer des réactions à partir de sources pertinentes extérieures à la communauté. Les "brouillons" devront comporter au minimum ce qui suit :

• Une déclaration concernant le fait que vous ne déposerez pas de brevet, et que vous adoptez un copyright approprié, tel qu'illustré par les brouillons actuels.
• Une déclaration XMDP déclarant les valeurs d'attributs. Vous pouvez préférer la placer sur une page à part du wiki, et faire un lien vers elle. Dans ce cas utilisez la convention de nommage *-profile, par ex. hcard-profile-fr.
• Des exemples de pratiques actuelles qui montrent comment le microformat pourra être utilisé. Gardez un oeil sur la façon dont le microformat améliore réellement les choses. Si ce n'est pas le cas, c'est peut être une indication que vous devriez l'abandonner, ou lui apporter de grands changements.
• Des références qui étayent vos décisions de conception pour le microformat. Autant que possible, vous ne souhaitez pas inventer les choses "from whole cloth".
• Une liste d'implémentations (s'il y en a).
• Une sections "problématiques" (issues) pour permettre aux gens de vous remonter leurs 'réactions' avec des objections détaillées.

Spécifications

Vous aurez en général besoin d'au moins une itération pour passer l'étape du "brouillon". Une fois que les choses deviennent des spécifications, cela suppose qu'elles soient stables, de façon à ce que les développeurs puissent s'en emparer et écrire pour elles. Ceci implique aussi qu'il y ait au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyez une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objections majeures. Si aucune réponse ne vient, déplacez le microformat dans la zone "spécifications". Ce mouvement réveillera les éventuels éditeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoient au stade "brouillon". Si vous avez suivi le processus, il est temps désormais de fixer les choses. A ce stade, toutes les problématiques restantes devraient être faciles à résoudre.

Autres Documents

Patterns

Qu'en est il des autes types de pages sur le wiki, comme les "patterns" (par ex. include-pattern)?

Comme ceux-ci sont t'ils créés ?

L'explication courte est celle-ci :

Les patterns ne sont pas du tout des formats. Ils ne se tiennent pas de manière autonome. Ce sont simplement de la documentation de morceaux d'autres formats qui sont attendus pour (ou sont) être réutilisés par d'autres formats. Les exemples dans le vrai monde pour includes en particulier ont été documentés dans le contexte des exemples de CV, formats de CV et resume-brainstorming-fr (comme noté tout en haut du document). Plus tard, les exemples du vrai monde pour des critiques ont été trouvés pour avoir besoin tout aussi bien du "include-pattern".

En rapport

• processus-brainstorming