process-fr

Cette page a démarré sur process

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 croyez encore 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. Souvenez vous, nous pavons le "sentier des vaches"- avant de faire ça, vous devez trouver les "sentiers des vaches". Il faut que vos exemples soient 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 impliqués là-dedans, 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 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é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. 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 The Elements of Meaningful XHTML.

Avant tout, vous devriez regarder attentivement les les principes des microformats.

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.

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 :

1. 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 ?
2. 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

Après avoir proposé un microformat, vous recueillerez probablement un grand-nombre de feedback de la part de ceux qui sont intéressés 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 :

DIAGRAM:
é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 peut 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 à considérer pour la création

Un "pattern" a émergé des efforts fructueux dans le développement des microformats, de plusieurs sortes de pages wikis spécifiques qui se créent dans un ordre particulier (même si ce n'est pas toujours le cas).

Après qu'un champ spécifique au problème (*) ait été déterminé (principe n°1), envisager de créer et remplir les pages suivantes le concernant. Si vous ne pouvez pas fournir de la matière pour alimenter ces pages, alors vous devriez probablement reconsiderer s'il est opportun ou pas de (ou si vous êtes prêt pour) résoudre ce problème.

1. *-exemples. Chercher des exemples sur le web actuel du type de contenu pour lequel vous pensez qu'un microformat est nécessaire. Documentez-les avec les URLs. Documentez les schémas implicites qui sous-tendent le contenu. Ceci est l'action qui vous aidera à respecter le principe n°3, conception pour les humains d'abord, pour les machines ensuite... adapter les aux comportement actuels et aux "patterns" en terme d'usage.
2. *-formats. Trouvez des formats et des standards de données actuels et interopérables, largement adoptés, qui ont déjà tentés 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, "reutiliser les briques des standard largement adoptés".
3. *-brainstorming. Utiliser les exemples courants existants sur le web et leur schémas implicites pour déterminer un schéma générique 80/20 aussi-simple-que-possible (principe n°2) pour représenter leurs données. Oui, cela signifie que vous allez explicitement ommettre quelques éléments de quelques 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 large (aggregation/macro). Regarder quels microformats existants peuvent être réutilisés comme des briques (principe n°5, modularité. Utiliser ces formats et schémas de données existants comme des source of names pour les champs considérés (principe n°4). Envisager comment vous encapsuleriez ce microformat dans d'aurtes formats (aussi le principe n°5, "encapsulage"). Avec un schéma 80/20, et une source de noms de champ, écrivez une ou plusieurs proposition "straw" (ndt: paille jaune) pour un microformat. Assurez-vous que les propositions "straw" encourage la distribution décentralisées des données (principe n°6). A ce stade, vous pouvez décider d'envisager une section "nommage", où différents noms pour le microformat pourront être envisagés.
4. **. Quand il apparaît qu'il y a un certain niveau de concensus autour d'une des propositions "straw" pour un microformat(**), écrivez-la sous forme de specification "draft" en tant que page séparée du wiki.
5. **-faq. Il y aura probablement des questions couramment posées à propos du nouveau microformat et qui pourront/devront être répondues sur une page FAQ.
6. **-problématiques. Ils se peut qu'il y en ait qui soulevent également des problématiques à propos du microformat, qui ne soient pas immédiatemment traitables. Un document dédié aidera et servira à enregistrer ces problématiques, 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.
7. **-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écifiactions, c'est pourquoi cette liste mérite sa propre page.

Avancer d'Etape en Etape

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

Discussions Exploratoires

Vous devez avoir un problème, et vous devez essayer de l'énoncer. Vous devriez le faire sur ce wiki en utilisant comme un guide, les items qui se trouvent actuellement sous la "discussion exploratoire". Ensuite, envoyez une note à la liste microformats-discuss pour capter l'attention d'autres personnes qui s'intéressent également aux microformats. C'est un moyen d'éventuellement amener ici des personnes qui sont extérieures à cette communauté sur les microformats, et qui pourraient rencontrer la même problématique.

Les feedbacks seront probablement de toutes natures. D'autres personnes pourront venir vérifier la pertinence de l'énoncé du problem, du besoin d'un microformat, être d'accord avec vos propositions, ou en rajouter. Tout feedback constructif est bon.

La conséquence de ce feedback, peut être que vous décidiez d'abandonner votre idée de microformat ou de la modifier substanciellement. Une chose que vous êtes certain de désirer à ce stade, c'est d'éviter de reinventing the wheel. Il y a t'il des microformats élémentaires que vous pouvez réutiliser en tant que briques ? Si vous le faites, vous économiserez vos efforts et cela vous aidera pour l'implémentation future, car les "implementeurs" auront moins de travail à fournir.

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

Brouillons

Ici, il vous faut é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 vosu 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 du feedback depuis des sources pertinentes qui soient à l'extérieur de la communauté. Les "drafts" devront comporter au minimum ce qui suit :

• Une déclaration conernant le fait que vous ne déposerez pas de brevet et que vous adopter un copyright approprié tel qu'illustré par les drafts actuels.
• Une déclaration XMDP déclarant les "attribute values". Vous pouvez souhaiter la placer sur une page wiki séparée ; faites alors 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é. Garder un oeil sur la valeur ajoutée du microformat en usage. S'il n'y en a pas, c'est peut être une indication que vous devriez l'abandonner ou lui apporter de grand changement.
• 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" pour permettre aux gens de vous donner leur "feedback" avec des objections détaillées.

Spécifications

Vous aurez généralement besoin d'au moins une itération pour dépasser l'étape du brouillon. Quand quelquechose devient une spécification, elle doit être stable de façon à ce que les développeurs puissent s'en emparer et écrire dessus. Ceci implique à son tour qu'il y a au moins une ou deux implémentations.

Avant de passer à la section des spécifications, envoyer une note sur la liste microformats-discuss et attendez un jour ou deux pour voir s'il y a des objectiosn majeures. Si rien ne vient, déplacer le microformat dans la zone des spécifications. The déplacement réveillera les editeurs assoupis, et il se peut alors qu'ils émettent une objection et vous renvoie au stade "brouillon". Si vous avez suivi le process, il est temps désormais de fixer votre travail. A ce stade, toutes les problématiques restantes devraient être facile à résoudre.

Autres Documents

Patterns

What about other types of pages on the wiki, like "patterns" (e.g. include-pattern)?

How do those get created?

The short explanation is this:

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 the document) "Initially developed as part of resume-brainstorming..." Later, real world examples for reviews were found to need the include pattern as well.