process-fr: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(→‎Proposez un Microformat: relecture + traduction à relire)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(43 intermediate revisions by 13 users not shown)
Line 1: Line 1:
''Cette page a démarré sur [[process]]''
Si c'est votre première visite, regardez SVP la page d'[[introduction-fr|introduction]].


=Ainsi vous voulez développer un nouveau microformat ?=
{{DISPLAYTITLE:Le processus microformats}}


__TOC__
'''Ainsi vous voulez développer un nouveau microformat ?'''
 
'''Ou juste un nouveau vocabulaire ?'''
 
'''Ou créer un nouveau standard fondé sur une recherche empirique et des méthodes scientifiques ?'''
 
Ce document vous aidera comme guide pour les étapes à franchir pour parvenir à ces fins.
 
Le processus microformats a été cité comme inspiration pour d'autres groupes de standards et d'efforts tels que WHATWG et ActivityStreams.
 
;Editeur
:[[User:Tantek|Tantek Çelik]]
 
;Traduction française
:[[User:ChristopheDucamp|Christophe Ducamp]]
 
 
{{TOC-right}}
 
 
== tout d'abord ayez quelque expérience ==
Avant même d'imaginer continuer à réfléchir sur un nouveau microformat,
# Faites que votre site soit [[posh-fr|CHIC/POSH]].
# Ajoutez des microformats <em>existants</em> à vos sites comme une [[hcard-fr|hCard]] pour votre information de contact, etc., [[hcalendar-fr|hCalendar]] pour vos événements, [[hatom-fr|hAtom]] pour vos contenus épisodiques (par ex. les blogs). Voir  [[get-started-fr|comment démarrer]] pour des exemples plus spécifiques d'ajout de microformats à vos sites.
 
Ceci aidera à vous familiariser à la façon dont fonctionnent actuellement [[posh-fr|CHIC/POSH]] et [[microformats-fr|microformats]]. Une telle expérience du "vrai monde" vous aidera énormément avec le développement d'un nouveau microformat. Pour en savoir plus à ce sujet, voir [[why-using-existing-microformats-matters-fr|pourquoi-il-est-important-d-utiliser-des-microformats-existants]].
 
Puis demandez-vous :


==Pourquoi ?==
==Pourquoi ?==
Il doit y avoir un problème à résoudre. Pas de problème, pas de microformat.
Il doit y avoir un problème à résoudre (c'est à dire un cas d'utilisation dans le vrai monde). 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.
 
Peut-être que quelqu'un d'autre suit  (ou a suivi) un problème similaire.
 
Regardez la page [[exploratory-discussion-fr|discussion exploratoire]] et cherchez partout sur le web. Les chances sont que quelqu'un d'autre ailleurs ait rencontré le même problème que vous. Il y a vraiment très peu de nouveaux problèmes complexes.
 
Si vous croyez encore que vous avez un problème nouveau et non résolu, postez quelque chose sur le canal [[irc-fr|irc]], et si personne n'est là, alors sur la liste de diffusion [http://microformats.org/mailman/listinfo/microformats-new/ microformats-new]. Il est mieux d'impliquer la communauté dans la discussion. Démarrez la discussion '''<span style="text-transform: uppercase;">avant</span>''' de créer de nouvelles pages sur le wiki.
 
Nous n'utilisons pas le wiki comme un &quot;bloc-notes&quot; général. Si vous ne parvenez 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 concernant 'y'a-t'il un problème plus simple ici ?' et simplifiez jusqu'à ce que vous décriviez votre problème et cas d'usage dans le vrai monde dans un paragraphe court.
 
==Documentez les Comportements Existants==
Documentez les comportements humains existants.  [[why-examples-fr|Exemple du pourquoi d'abord ?]]
 
[[why-examples-fr|Pourquoi d'abord des exemples ?]] Lisez cela. C'est important et c'est le noyau de ce qui rend les efforts microformats différents de tous les autres/nombreux/précédents efforts de développement.
 
Nous sommes en train de [http://www.elanceur.org/microformats/traductions/paverlechemindesvaches.html paver les "chemins des vaches"]- avant que vous n'ayez à avoir à "trouver" les chemins des vaches.
 
Par "chemin des vaches" ici, nous entendons des "exemples de publication du vrai monde". Vos [[examples-fr|exemples]] devraient être un ensemble de sites et pages du vrai monde qui publient le type de donnée que vous souhaitez structurer avec un microformat. A partir de ces pages et ces sites, vous devriez extraire des exemples de marquage et tout spécialement les schémas implicites contenus, et en fournir une analyse.
 
Cette collection d'exemples devrait être publique, de préférence sur le wiki microformats parce qu'il est peu probable que vous puissiez la faire vous-même tout seul (peu importe combien vous êtes) et faire que les autres puissent vérifier votre travail aidera à améliorer sa qualité.
 
La page [[reviews-formats-fr|formats de critiques]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview-fr|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 implicites.
 
Note : ces exemples concernent le "contenu" (et les schémas "implicites" imbriqués) pas les formats, les noms de classes, les standards pré-existants, etc. Cela vient après.


Une fois que vous avez trouvé votre 'problème', demandez-vous : 'y'a t'il un problème plus simple ici ?' Si oui, résolvez d'abord ce problème. Nous voulons traiter en premier les problèmes les plus simples et ce n'est qu'ensuite que nous élaborons des solutions pour résoudre des problèmes plus complexes.
Etudiez les exemples et déterminez le schéma "implicite" (pas explicite) de donnée qui est en train d'être publié (les propriétés conceptuelles concernant la donnée - pas les noms de classes litérales). Triez ceux-ci par fréquence et déterminez ceux qui apparaissent dans à peu près 80% des cas (selon la règle 80/20, le [[principle-fr|principe]] de Pareto).


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 croyez encore que votre problème n'a pas été résolu, postez quelque chose sur la liste de discussion [http://microformats.org/mailman/listinfo/microformats-discuss/ 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 carnet de brouillon global. 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 aurez besoin d'écrire un long document, vous essayez probablement de résoudre un problème trop gros - voir le paragraphe précédent.
Si vous ne pouvez trouver d'exemples du vrai monde pour le type de donnée que vous voulez représenter en utilisant un microformat, alors arrêtez-vous. Il n'a pas besoin d'un microformat.


==Documentez les Comportements Actuels==
Documentez les comportements actuels des opérateurs (concernant l'usage des données). Souvenez vous, nous  [http://ifindkarma.typepad.com/relax/2004/12/microformats.html pavons le "sentier des vaches"]- avant de faire ça, vous devez ''trouver'' les "sentiers des vaches". Vos [[exemples-fr|exemples]] devraient être une collection de sites existants et de pages qui publient le type de données que vous souhaitez structurer avec un microformat. A partir de ces pages et de ces sites, vous devriez extraire des exemples de balises et les schémas sous-jacents, et fournir une analyse.


Cette collection d'exemples devrait être publique, de préférence sur un wiki parce qu'il est impossible que vous le fassiez par vous-même (peu importe combien vous êtes).  La page [[reviews-formats]] est un bon exemple de recherche effectuée avant la création d'un microformat. Avant de développer [[hreview]], les collaborateurs sont allé faire un tour, ont documenté les pratiques actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.  
==Documentez les Efforts Précédents ==
Une fois documentés les exemples de publication du vrai monde des types de données que vous voulez représenter, la prochaine étape est chercher les efforts en développant des formats pour ces types de données.


Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui a rencontré le même problème sur lequel vous vous penchez. Peut-être l'a t'il résolu. Faites de votre mieux pour ouvrir un dialogue avec ceux qui ont rencontré le même problème. Nous ne voulons pas construire de 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.
Il y presque toujours des efforts précédents sur les formats pour n'importe quel type de donnée que vous voulez représenter en utilisant des microformats.


==Proposez un Microformat==
Apprendre à partir des efforts précédents des formats est important, parce que cela aide à :
En fait, '''NE LE FAITES PAS !!!'''
* minimiser la répétition des erreurs des autres
* explorer pourquoi un précédent format a réussi (ou non)
* fournir une source de vocabulaire pour exprimer un nouvau microformat.


Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord trois questions :
Tout particulièrement, demandez-vous :  &quot;existe-t'il des standards établis, interopérables et implémentés que nous pouvons regarder et qui adressent ce problème ?&quot;


# Y'a t'il un élément standard en XHTML qui fonctionnerait ?
Par exemple, hCard et hCalendar ont été construits sur le haut des standards IETF standards pour vCard et iCal, respectivement, les deux étant largement implémentés, et dominants dans leur espace (il n'existait pas de formats concurrents ailleurs avec de tels niveaux d'adoption).
# Y'a t'il une combinaison d'éléments XHTML qui fonctionnerait ?
# Ok, 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 des éléments XHTML et construire des combinaisons de XHTML, voir [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML].
Les développeurs de ces standards ont déjà passé beaucoup d'années dans les comités de standards à discuter, défendre et développer leurs schémas. Mieux de tirer profit de tout le travail que d'autres ont produit avant vous, plutôt que de partir seul comme un cowboy solitaire inventeur et perdre votre temps à répéter toutes leurs erreurs.  Il est aussi bien plus facile de démarrer à partir d'un schéma bien établi, et de le cartographier dans un HTML sémantique plutôt que développer un nouveau schéma.


Avant tout, vous devriez regarder attentivement les [[microformats#the_microformats_principles|les principes des microformats]].
Il est tout à fait possible durant cette étape que vous puissiez trouver quelqu'un d'autre qui se soit confronté au(x) problème(s) que vous résolvez. Peut-être même déjà résolu. Faites de votre mieux pour ouvrir le dialogue avec d'autres qui ont fait face au(x) même(s) problème(s). Nous ne voulons pas construire de murs entre communautés concurrentes - nous voulons des personnes qui travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.


Une fois que vous avez compris les principes, demandez-vous : "est-ce qu'il existe déjà des standards implémentés, bien établis et interopérables, vers lesquels se tourner et qui pourront résoudre 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é des années au sein de comités de standardisation, à défendre et développer les schémas. Il est préférable de s'appuyer sur tout 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.
Si vous ne pouvez pas trouver d'efforts précédents sur les formats pour les données que vous voulez microformater, demandez sur  l'[[irc-fr|IRC]] et sur les [[mailing-lists-fr|listes de discussion]].


Souvenez-vous, les microformats devraient être conçus pour les humains d'abord, et pour les machines ensuite. Voici quelques questions qui pourront vous aider à savoir si vous avez vraiment besoin d'un microformat pour résoudre votre problème :
==Propositions Brainstorming ==
A ce stade, vous avez recherché des exemples précédents et des formats précédents et vous êtes prêts à écrire les brainstorms pour un nouveau microformat.
 
En fait, <strong style="text-transform:uppercase;">ne le faites pas !!!</strong>'''
 
Il y a d'autres choses à essayer avant de développer un microformat. Posez-vous d'abord ces questions :
 
# Y'a t'il un élément standard en HTML qui fonctionnerait ?
# Y'a t'il une combinaison d'élémentsXHTML qui fonctionnerait ?
 
Si oui, documentez-cela sur la page de brainstorming et arrêtez-vous. Il n'y a pas besoin de microformat.
 
Ne réinventons pas ce que vous pouvez déjà faire avec HTML.
 
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 [http://www.elanceur.org/microformats/slides/XHTML-ayant-du-sens.html Les Eléments XHTML ayant du sens].
 
Autrement, si vous pouvez répondre clairement et franchement "non" aux deux questions du dessus, nous pouvons parler d'un microformat.
 
Avant que vous ne démarriez votre acte de création, familiarisez-vous avec [[http://microformats.org/wiki/principles-fr|les principes des microformats]].
 
Il y a fondamentalement deux étapes avant d'écrire une proposition de brainstorming :
 
# Revenir sur cette liste d'exemples de publication du vrai monde que vous avez cherchés, et assemblez le 80/20 du schéma implicite conceptuel extrait des exemples.
# Donnez à chacun de ces concepts un nom de propriété, en le réutilisant à partir de et dans l'ordre :
## de microformats existants
## de précédents formats
## mots et phrases simples mais spécifiques, en anglais et lisibles par les humains
 
Bravo, vous avez écrit une proposition de brainstorming avec une liste de nom de classes pour un microformat possible.
 
Vous pouvez remarquer que vous avez complètement passé le "nommage" du nouveau microformat potentiel en lui-même. Ce n'est pas un accident, c'est délibéré. Nommer est tentant, et un bon nommage est difficile. Par conséquent le nommage est discuté plus tard.
 
La clé est que le schéma explicite du microformat (quelles propriétés et par conséquent les noms de classes dedans) est "plus important" que le nom.
 
Souvenez-vous, les microformats devraient être conçus d'abord pour les humains et ensuite pour les machines. Voici quelques questions qui pourront vous aider à décider si vous avez vraiment besoin d'un microformat pour les problème que vous essayez de résoudre :
 
# Si je regardais ce microformat dans un navigateur qui ne supportait pas CSS ou avait CSS désactivé, serait-il encore lisible par un humain ?
# Est-ce que ces élémnets de format sont stylisables avec CSS ?
 
Si le microformat proposé ne passe pas ces deux choses, il est peu probable qu'il soit accepté. Souvenez-vous : "les humains d'abord, les machines ensuite".


# Si je lisais ce microformat au moyen d'un navigateur qui ne supporte pas les CSS, ou dont cet(te fonction a été désactivée, serait-il toujours lisible par un humain ?
# Est-ce que les éléments de ce microformat sont stylisables par 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 ==
== Itération ==
After proposing a microformat, you'll likely get a lot of feedback from others interested in microformats. The proposal needs to be iterated and adapted. Microformat development should be collaborative and community-based.


Here's an ASCII-art flow diagram:
Maintenant que vous avez une simple proposition de brainstorming, que faites-vous ?
 
Itérez. Itérez. Itérez.
 
Dans le processus de développement d'un microformat, vous recueillerez probablement un grand-nombre de réactions de la part d'autres personnes intéressées par les microformats. L'effort devra être "itéré" et adapté. Le développement d'un microformat devrait être ouvert, et de préférence collaboratif et fondé sur une communauté.
 
Voici un diagramme de flux en ASCII-art :
<pre>
<pre>
DIAGRAM:
DIAGRAMME :
problem statement---->research/discussion---->proposal/draft---->standard
énoncé du problème---->recherche/discussion---->proposition/"draft"---->spécification
^________________V  ^___________________V  ^______________V
^________________V  ^___________________V  ^______________V
</pre>
</pre>


Note that each stage involves iteration. That iteration consists of discussion and feedback and may result in major changes. Do not be afraid to make major changes and please don't get too attached to any particular solutions.
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.
 
== Considérations de Nommage==
'''NE DEMARREZ PAS'' même par libeller votre effort "hXYZ". C'est une erreur '''vraiment''' courante.
 
Démarrez toujours par le champ général du problème.


=== Pages à considérer pour la création  ===
Par conséquent, nommez le champ du problème (*- page en dessous) de façon générique et évitez spécifiquement de démarrer par le nom de code / nom de marque comme hNouveauFormatCool.


A pattern has emerged from successful microformat development efforts of several specific kinds of wiki pages being created, in a particular order (though not always).


After a specific problem area (*) has been determined (principle 1), consider creating and filling out the following pages for it. If you're unable to come up with material for the pages, then you should probably reconsider whether or not the problem is worth (or ready for) solving.
Bon : '''[[product-examples]]'''. Mauvais: '''hProduct-examples'''.


# *-examples.  Find examples on today's web of the the type of content you think needs a microformat.  Document them with URLs.  Document the implicit schemas that the content examples imply.  This is the action that helps follow principle 3, design for humans first, machines second ... adapt to current behaviors and usage patterns.
Après avoir itéré votre recherche votre recherche et brainstorming, vous avez probablement gagné suffisamment de compréhension de l'espace-problème que vous résolvez pour commercer à envisager les considérations de nommage.
# *-formats.  Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously.  Document their explicit schemas.  This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
# *-brainstorming.  Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data.  Yes, this means you will explicitly ''omit'' some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors.  See which existing microformats can be reused as building blocks (principle 5, modularity).  Use those existing data formats and schemas as a [[existing-classes|source of names]] for the fields (principle 4).  Consider how would you embed this microformat in other formats (also principle 5, embeddability).  With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat.  Make sure the straw proposals encourage the decentralized distribution of data (principle 6).  At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
#  **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
#  **-faq.  There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
#  **-issues.  Folks may also raise issues about the microformat which aren't immediately addressable.  An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
#  **-implementations.  Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.


=== Avancer d'Etape en Etape===
== Pages à créer ==
Un modèle a émergé à partir des efforts réussis de développement de microformats de plusieurs tpes spécifiques de pages wiki ayant été créées, dans un ordre particulier (néanmoins pas toujours).


These stages of development are mirrored on the main page where microformats are divided into &quot;Exploratory Discussions&quot;, &quot;Drafts&quot;, and &quot;Specifications&quot;. How do microformats move from one stage to the other?  To help answer this question, it's probably useful to write up a set of desiderata for each stage.
Par exemple est t'il possible de faire installer une [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoire forte blindée] qui soit également ignifuge


==== Discussions Exploratoires ====
Après que le champ spécifique du problème  ('''*''') ait été déterminé (principe 1), considérez de créer et de remplir les pages suivantes, et ajoutez la première à [[exploratory-discussions-fr|discussions-exploratoires]].  Si vous êtes incapable d'en venir à quelque contenu pour les pages, vous devriez considérer de nouveau si oui ou non le problème vaut la peine (ou prêt) d'être résolu.
 
# '''*-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 implicitement sous-tendus par 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'[[examples-fr|exemples]] et remplissez là.
# <span id="formats">'''*-formats</span>'''  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 blocs de construction provenant de standards largement adoptées".
 
# <span id="brainstorming">'''*-brainstorming</span>.'''  Utilisez 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 quelques cas d'utilisation, ou peut-être des cas d'utilisation complets, qui sont plus des cas limites que représentatifs de comportements plus larges, de niveau agrégation/macro. Regardez quels sont les microformats existants pouvant être réutilisés comme blocs de construction (principe n°5, modularité). Utilisez ces formats et schémas de données existants comme une [[existing-classes-fr|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"). Voir la page [[brainstorming-fr|brainstorming]] pour un peu plus d'information.
<p> 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 [[naming-principles-fr|les principes de nommage des microformats]] au moment de choisir des noms.</p>
<p>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é écrites et discutées pour le 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.</p>
#  '''**''' Quand il semble qu'il y ait 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.
#  '''**-faq'''  Il y aura probablement des questions récurrentes à propos du nouveau microformat, qui pourront/devront être répondues sur une page FAQ.
#  '''**-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é aux problématiques 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.
# '''**-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.
#  '''**-implémentations'''  En fait, 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.
#  '''**-brainstorming''' En fait, il y aura des propositions/suggestions/clarifications non triviales pour les modifications dans les microformats faisant partie de l'itération. Créer une page spécifique au format [[brainstorming]] pour de telles suggestions
 
 
=== 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".


You need a problem, and you need to attempt to state it.  You should do it on this wiki using current items under exploratory discussion as a guide.  Then send a note to the microformats-discuss list to get the attention of others who are interested in microformats.  This is probably a good chance to pull in people from outside the current microformats community who may also be experiencing the same issue. 
Comment les microformats passent-ils d'une étape à une autre ?


Feedback will probably range the gamutOthers may challenge your problem statement, the need for a microformat, concur, or addAll constructive feedback is good.
==== 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-new, 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.   


As a result of feedback, you may decide to abort your microformat idea or substantially modify it.  One thing you want to be sure to do at this stage is to avoid [[reinvented-wheels|reinventing the wheel]]. Are there elemental microformats you can reuse as building blocks?  Doing this will save you effort and help you get implemented later because implementers will have less work to do.
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.


However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.
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 [[reinvented-wheels-fr|réinventer la roue]].  


==== Brouillons ====
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.


Here, you need to write what is essentially a specification, but with the idea that it could change a lot. Again, this needs to go in the wiki, and you should send a note to microformats-discuss to alert people that something new has happenedDon't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:
==== 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-new" pour prévenir les gens qu'il y a du nouveauContinuez à essayer de faire rentrer des réactions à partir de sources pertinentes extérieures à la communauté. Les "drafts" devront comporter au minimum ce qui suit :


* Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
* Une déclaration concernant le fait que vous ne déposerez pas de brevet, et que vous adoptez un copyright approprié (de préférence le DOMAINE PUBLIC) comme  illustré par les "drafts" actuels.
* An XMDP stating attribute values. You may want to place this on a separate wiki page and link to itIn that case use the naming convention *-profile, e.g. [[hcard-profile]].
* 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 elleDans ce cas utilisez la convention de nommage *-profile, par ex. [[hcard-profile-fr|hcard profile]].
* Examples from current practice that show how the microformat would be used. Keep an eye out for how the microformat is actually improving things. If it's not, that might be an indication that you either need to abandon or change a lot.
* 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.
* References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
* Usage de termes [[rfc-2119-fr|rfc-2119]].
* A list of implementations (if any).
* 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". Ceci devrait être relativement aisé si vous avez suivi le processus à ce stade avec la recherche appropriée.
* An issues section for people to feed back to you with detailed objections.
* Une liste d'implémentations (s'il y en a).
* Une sections "problématiques" pour permettre aux gens de vous remonter leurs 'réactions' avec des objections détaillées.


==== Spécifications ====
==== 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.


You will usually need at least one iteration to get past the draft stage. By the time something becomes a specification, it should be stable so that developers can pick it up and write to it. This in turn implies that there are at least a couple of implementations.
Avant de passer à la section des spécifications, envoyez une note sur la liste microformats-new et encouragez la discussion et les objections majeures. Si aucune réponse ne vient, suggérez de migrer le microformat vers la zone "spécifications". S'il y a un support suffisamment explicite de la part de la communauté à faire ainsi, alors allez-y. (Si non, laissez-le alors sous un draft. L'absence de réactions n'est pas une approbation).. Cette migration peut réveiller les é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.


Before moving to the specifications section, drop a note to microformats-discuss and wait a day or two for major objections.  If none are forthcoming, move the microformat to the specifications area.  This move will wake up any sleeping editors, and they may raise an objection and move you back to draft.  If you have followed the process, now is the time to pin them down.  At this juncture, any remaining issues should be easy to resolve.
== Autres Documents ==
=== Patterns ===
Qu'en est il des autes types de pages sur le wiki, comme les "patterns" (par ex. [[include-pattern-fr|include-pattern]]) ?


== Autres Documents ==
Comment ceux-ci sont-ils créés ?


=== Patterns ===
L'explication courte est celle-ci :


What about other types of pages on the wiki, like "patterns" (e.g. [[include-pattern]])?
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.


How do those get created?
Les exemples dans le vrai monde pour includes en particulier ont été documentés dans le contexte des [[resume-examples-fr|exemples de CV]], [[resume-formats-fr|formats de CV]] et [[resume-brainstorming-fr]] (comme noté tout en haut du [[include-pattern-fr|document]]). Plus tard, les exemples du vrai monde pour des critiques ont été trouvés pour avoir besoin tout aussi bien du "include-pattern".


The short explanation is this:
Quand des exemples du vrai monde pour des microformats "multiples" requièrent la solution d'un problème similaire, alors cela vaut la peine de créer un "pattern" qui résout le problème sur l'ensemble des microformats.


The patterns are not formats at all.  They do not stand on their own. They are merely documentation of pieces of other formats that are expected to (or are) being reused by other formats.  The real world examples for includes in particular were documented in the context of [[resume-examples]], [[resume-formats]], and [[resume-brainstorming]] (as noted at the very top of [[include-pattern|the document]]) "Initially developed as part of resume-brainstorming..."  Later, real world examples for reviews were found to need the include pattern as well.
== En rapport ==
* [[process-faq-fr|processus-faq]]
* [[process-issues-fr|processus-problématiques]]
* [[process-brainstorming-fr|processus-brainstorming]]

Latest revision as of 16:31, 18 July 2020

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


Ainsi vous voulez développer un nouveau microformat ?

Ou juste un nouveau vocabulaire ?

Ou créer un nouveau standard fondé sur une recherche empirique et des méthodes scientifiques ?

Ce document vous aidera comme guide pour les étapes à franchir pour parvenir à ces fins.

Le processus microformats a été cité comme inspiration pour d'autres groupes de standards et d'efforts tels que WHATWG et ActivityStreams.

Editeur
Tantek Çelik
Traduction française
Christophe Ducamp



tout d'abord ayez quelque expérience

Avant même d'imaginer continuer à réfléchir sur un nouveau microformat,

  1. Faites que votre site soit CHIC/POSH.
  2. Ajoutez des microformats existants à vos sites comme une hCard pour votre information de contact, etc., hCalendar pour vos événements, hAtom pour vos contenus épisodiques (par ex. les blogs). Voir comment démarrer pour des exemples plus spécifiques d'ajout de microformats à vos sites.

Ceci aidera à vous familiariser à la façon dont fonctionnent actuellement CHIC/POSH et microformats. Une telle expérience du "vrai monde" vous aidera énormément avec le développement d'un nouveau microformat. Pour en savoir plus à ce sujet, voir pourquoi-il-est-important-d-utiliser-des-microformats-existants.

Puis demandez-vous :

Pourquoi ?

Il doit y avoir un problème à résoudre (c'est à dire un cas d'utilisation dans le vrai monde). 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.

Peut-être que quelqu'un d'autre suit (ou a suivi) un problème similaire.

Regardez la page discussion exploratoire et cherchez partout sur le web. Les chances sont que quelqu'un d'autre ailleurs ait rencontré le même problème que vous. Il y a vraiment très peu de nouveaux problèmes complexes.

Si vous croyez encore que vous avez un problème nouveau et non résolu, postez quelque chose sur le canal irc, et si personne n'est là, alors sur la liste de diffusion microformats-new. Il est mieux d'impliquer la communauté dans la discussion. Démarrez la discussion avant de créer de nouvelles pages sur le wiki.

Nous n'utilisons pas le wiki comme un "bloc-notes" général. Si vous ne parvenez 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 concernant 'y'a-t'il un problème plus simple ici ?' et simplifiez jusqu'à ce que vous décriviez votre problème et cas d'usage dans le vrai monde dans un paragraphe court.

Documentez les Comportements Existants

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

Pourquoi d'abord des exemples ? Lisez cela. C'est important et c'est le noyau de ce qui rend les efforts microformats différents de tous les autres/nombreux/précédents efforts de développement.

Nous sommes en train de paver les "chemins des vaches"- avant que vous n'ayez à avoir à "trouver" les chemins des vaches.

Par "chemin des vaches" ici, nous entendons des "exemples de publication du vrai monde". Vos exemples devraient être un ensemble de sites et pages du vrai monde qui publient le type de donnée que vous souhaitez structurer avec un microformat. A partir de ces pages et ces sites, vous devriez extraire des exemples de marquage et tout spécialement les schémas implicites contenus, et en fournir une analyse.

Cette collection d'exemples devrait être publique, de préférence sur le wiki microformats parce qu'il est peu probable que vous puissiez la faire vous-même tout seul (peu importe combien vous êtes) et faire que les autres puissent vérifier votre travail aidera à améliorer sa qualité.

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 implicites.

Note : ces exemples concernent le "contenu" (et les schémas "implicites" imbriqués) pas les formats, les noms de classes, les standards pré-existants, etc. Cela vient après.

Etudiez les exemples et déterminez le schéma "implicite" (pas explicite) de donnée qui est en train d'être publié (les propriétés conceptuelles concernant la donnée - pas les noms de classes litérales). Triez ceux-ci par fréquence et déterminez ceux qui apparaissent dans à peu près 80% des cas (selon la règle 80/20, le principe de Pareto).

Si vous ne pouvez trouver d'exemples du vrai monde pour le type de donnée que vous voulez représenter en utilisant un microformat, alors arrêtez-vous. Il n'a pas besoin d'un microformat.


Documentez les Efforts Précédents

Une fois documentés les exemples de publication du vrai monde des types de données que vous voulez représenter, la prochaine étape est chercher les efforts en développant des formats pour ces types de données.

Il y presque toujours des efforts précédents sur les formats pour n'importe quel type de donnée que vous voulez représenter en utilisant des microformats.

Apprendre à partir des efforts précédents des formats est important, parce que cela aide à :

  • minimiser la répétition des erreurs des autres
  • explorer pourquoi un précédent format a réussi (ou non)
  • fournir une source de vocabulaire pour exprimer un nouvau microformat.

Tout particulièrement, demandez-vous : "existe-t'il des standards établis, interopérables et implémentés que nous pouvons regarder et qui adressent ce problème ?"

Par exemple, hCard et hCalendar ont été construits sur le haut des standards IETF standards pour vCard et iCal, respectivement, les deux étant largement implémentés, et dominants dans leur espace (il n'existait pas de formats concurrents ailleurs avec de tels niveaux d'adoption).

Les développeurs de ces standards ont déjà passé beaucoup d'années dans les comités de standards à discuter, défendre et développer leurs schémas. Mieux de tirer profit de tout le travail que d'autres ont produit avant vous, plutôt que de partir seul comme un cowboy solitaire inventeur et perdre votre temps à répéter toutes leurs erreurs. Il est aussi bien plus facile de démarrer à partir d'un schéma bien établi, et de le cartographier dans un HTML sémantique plutôt que développer un nouveau schéma.

Il est tout à fait possible durant cette étape que vous puissiez trouver quelqu'un d'autre qui se soit confronté au(x) problème(s) que vous résolvez. Peut-être même déjà résolu. Faites de votre mieux pour ouvrir le dialogue avec d'autres qui ont fait face au(x) même(s) problème(s). Nous ne voulons pas construire de murs entre communautés concurrentes - nous voulons des personnes qui travaillent ensemble pour développer une bonne solution qui couvrira la majorité des cas.

Si vous ne pouvez pas trouver d'efforts précédents sur les formats pour les données que vous voulez microformater, demandez sur l'IRC et sur les listes de discussion.

Propositions Brainstorming

A ce stade, vous avez recherché des exemples précédents et des formats précédents et vous êtes prêts à écrire les brainstorms pour un nouveau microformat.

En fait, ne le faites pas !!!

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

  1. Y'a t'il un élément standard en HTML qui fonctionnerait ?
  2. Y'a t'il une combinaison d'élémentsXHTML qui fonctionnerait ?

Si oui, documentez-cela sur la page de brainstorming et arrêtez-vous. Il n'y a pas besoin de microformat.

Ne réinventons pas ce que vous pouvez déjà faire avec HTML.

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 Les Eléments XHTML ayant du sens.

Autrement, si vous pouvez répondre clairement et franchement "non" aux deux questions du dessus, nous pouvons parler d'un microformat.

Avant que vous ne démarriez votre acte de création, familiarisez-vous avec [principes des microformats].

Il y a fondamentalement deux étapes avant d'écrire une proposition de brainstorming :

  1. Revenir sur cette liste d'exemples de publication du vrai monde que vous avez cherchés, et assemblez le 80/20 du schéma implicite conceptuel extrait des exemples.
  2. Donnez à chacun de ces concepts un nom de propriété, en le réutilisant à partir de et dans l'ordre :
    1. de microformats existants
    2. de précédents formats
    3. mots et phrases simples mais spécifiques, en anglais et lisibles par les humains

Bravo, vous avez écrit une proposition de brainstorming avec une liste de nom de classes pour un microformat possible.

Vous pouvez remarquer que vous avez complètement passé le "nommage" du nouveau microformat potentiel en lui-même. Ce n'est pas un accident, c'est délibéré. Nommer est tentant, et un bon nommage est difficile. Par conséquent le nommage est discuté plus tard.

La clé est que le schéma explicite du microformat (quelles propriétés et par conséquent les noms de classes dedans) est "plus important" que le nom.

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

  1. Si je regardais ce microformat dans un navigateur qui ne supportait pas CSS ou avait CSS désactivé, serait-il encore lisible par un humain ?
  2. Est-ce que ces élémnets de format sont stylisables avec CSS ?

Si le microformat proposé ne passe pas ces deux choses, il est peu probable qu'il soit accepté. Souvenez-vous : "les humains d'abord, les machines ensuite".


Itération

Maintenant que vous avez une simple proposition de brainstorming, que faites-vous ?

Itérez. Itérez. Itérez.

Dans le processus de développement d'un microformat, vous recueillerez probablement un grand-nombre de réactions de la part d'autres personnes intéressées par les microformats. L'effort devra être "itéré" et adapté. Le développement d'un microformat devrait être ouvert, et de préférence collaboratif et fondé sur une communauté.

Voici un diagramme de flux en ASCII-art :

DIAGRAMME :
énoncé du problème---->recherche/discussion---->proposition/"draft"---->spécification
^________________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.

Considérations de Nommage

'NE DEMARREZ PAS même par libeller votre effort "hXYZ". C'est une erreur vraiment courante.

Démarrez toujours par le champ général du problème.

Par conséquent, nommez le champ du problème (*- page en dessous) de façon générique et évitez spécifiquement de démarrer par le nom de code / nom de marque comme hNouveauFormatCool.


Bon : product-examples. Mauvais: hProduct-examples.

Après avoir itéré votre recherche votre recherche et brainstorming, vous avez probablement gagné suffisamment de compréhension de l'espace-problème que vous résolvez pour commercer à envisager les considérations de nommage.

Pages à créer

Un modèle a émergé à partir des efforts réussis de développement de microformats de plusieurs tpes spécifiques de pages wiki ayant été créées, dans un ordre particulier (néanmoins pas toujours).

Par exemple est t'il possible de faire installer une armoire forte blindée qui soit également ignifuge

Après que le champ spécifique du problème (*) ait été déterminé (principe 1), considérez de créer et de remplir les pages suivantes, et ajoutez la première à discussions-exploratoires. Si vous êtes incapable d'en venir à quelque contenu pour les pages, vous devriez considérer de nouveau si oui ou non le problème vaut la peine (ou prêt) d'être résolu.

  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 implicitement sous-tendus par 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 blocs de construction provenant de standards largement adoptées".
  1. *-brainstorming. Utilisez 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 quelques cas d'utilisation, ou peut-être des cas d'utilisation complets, qui sont plus des cas limites que représentatifs de comportements plus larges, de niveau agrégation/macro. Regardez quels sont les microformats existants pouvant être réutilisés comme blocs 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"). Voir la page brainstorming pour un peu plus d'information.

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.

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é écrites et discutées pour le 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.

  1. ** Quand il semble qu'il y ait 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.
  2. **-faq Il y aura probablement des questions récurrentes à propos du nouveau microformat, qui pourront/devront être répondues sur une page FAQ.
  3. **-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é aux problématiques 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.
  4. **-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.
  5. **-implémentations En fait, 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.
  6. **-brainstorming En fait, il y aura des propositions/suggestions/clarifications non triviales pour les modifications dans les microformats faisant partie de l'itération. Créer une page spécifique au format brainstorming pour de telles suggestions


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 ?

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-new, 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.

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-new" pour prévenir les gens qu'il y a du nouveau. Continuez à essayer de faire rentrer des réactions à partir de sources pertinentes extérieures à la communauté. Les "drafts" 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é (de préférence le DOMAINE PUBLIC) comme illustré par les "drafts" 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.
  • 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.
  • Usage de termes rfc-2119.
  • 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". Ceci devrait être relativement aisé si vous avez suivi le processus à ce stade avec la recherche appropriée.
  • Une liste d'implémentations (s'il y en a).
  • Une sections "problématiques" 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-new et encouragez la discussion et les objections majeures. Si aucune réponse ne vient, suggérez de migrer le microformat vers la zone "spécifications". S'il y a un support suffisamment explicite de la part de la communauté à faire ainsi, alors allez-y. (Si non, laissez-le alors sous un draft. L'absence de réactions n'est pas une approbation).. Cette migration peut réveiller les é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) ?

Comment ceux-ci sont-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".

Quand des exemples du vrai monde pour des microformats "multiples" requièrent la solution d'un problème similaire, alors cela vaut la peine de créer un "pattern" qui résout le problème sur l'ensemble des microformats.

En rapport