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

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

Documentez les Comportements Actuels

Documentez les comportements actuels des opérateurs. Souvenez vous, nous pavons le "sentier des vaches"- avant de faire ça, vous devez trouver les "sentiers des vaches". Vos 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 balisages 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 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 actuelles concernant les critiques/compte-rendus qu'on trouve sur les sites web, et ont fourni quelques analyses des schémas sous-jacents.

Il est tout à fait possible à ce stade que vous trouviez quelqu'un d'autre qui ait rencontré le même problème que celui 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.

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 spécifiques créées sur des wikis, dans un prdre 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), voir à 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. 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 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.
4. **. 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.
5. **-faq. There will likely be common questions about the new microformat which can/should be answered in an FAQ page.
6. **-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.
7. **-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

These stages of development are mirrored on the main page where microformats are divided into "Exploratory Discussions", "Drafts", and "Specifications". 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.

Discussions Exploratoires

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.

Feedback will probably range the gamut. Others may challenge your problem statement, the need for a microformat, concur, or add. All constructive feedback is good.

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

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.

Brouillons

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 happened. Don't hesitate to continue trying to pull in feedback from relevant resources outside the community. Drafts need to include at least the following:

• Statements regarding the fact that you will not patent and are adopting appropriate copyright as illustrated by current drafts.
• An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. 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.
• References that back up your design decisions for the microformat. To the extent possible, you do not want to invent things from whole cloth.
• A list of implementations (if any).
• An issues section for people to feed back to you with detailed objections.

Spécifications

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.

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

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.