mailing-lists-fr

Listes de Discussion

Lisez d'abord la page discussion sur le site microformats.

Puis lisez la politique des listes de diffusion.

Puis lisez les archives respectives (-discuss, -dev, -new).

Après cela, regardez svp les différentes notes supplémentaires sur les champs et thématiques traités par chaque liste.

Lignes de conduite générales

Voici une liste des lignes de conduite générales à suivre dans les listes de discussion des microformats. L'objectif général de bon nombre de ces lignes de conduite est d'améliorer le rapport signal bruit (S/N) en encourageant le signal et en décourageant le bruit. Maximiser le rapport signal bruit (S/N) est essentiel pour faire croître une adhésion à la liste, et ainsi au fur et à mesure que les microformats gagneront en popularité, la maximisation du S/N deviendra de plus en plus importante. Si vous avez des suggestions pour des lignes de conduite générales, postez-les svp sur la liste de discussion des microformats de façon à ce que les administrateurs de listes puissent étudier vos suggestions.

Soyez agréable

(Ne soyez pas un idiot) Cette ligne de conduite, qui peut sembler complètement évidente, est quelque chose que nous avons besoin de rendre explicite du fait de quelques mauvais exemples. La communauté microformats.org est tout à fait différente tant des autres organisations de standards que de la plupart des efforts open source sur au moins un point très important : cette communauté est un endroit bien plus agréable à vivre, avec des personnes se traitant les uns et les autres avec beaucoup de respect et le bénéfice du doute. Ce ton plus amical dans la communauté est quelque chose que la communauté valorise fortement et se battra pour défendre. Voir l'article Angry/negative people can be bad for your brain pour quelques raisons. Les administrateurs peuvent prendre des mesures rapides pour bannir ou modérer les individus qui se comportent en "idiots" sur la liste. Note : le ton neutre des emails qui utilisent un langage logique/rationnel libéré de toute émotion colle parfaitement. Cette ligne de conduite n'est pas une exigence pour ajouter de la gentillesse artificielle etc. aux emails.

Soyez patient

La communauté, ça fait partie de sa tonalité plutôt très positive, essaye d'être très patiente avec les personnes, et nous voulons continuer à encourager ça. Les listes de discussion des microformats recevront toujours (en supposant une croissance et une popularité connues) de nouveaux abonnés, et ces nouveaux abonnés peuvent être peu familiers avec les coutumes et conventions de la communauté. En tant que membre expérimenté dans la communauté, svp faites preuve de patience avec les nouveaux abonnés, et aidez-les à améliorer leurs comportements en leur indiquant gentiment les lignes de conduite adéquates et les réponses sur le wiki. Néanmoins, s'il apparaît qu'un nouveau venu ait une attitude négative, portez-le svp à l'attention des administrateurs (hors de la liste) avec un e-mail officiel de plainte qui référencera (par une archive url de l'email) ou inclura l'email qui démontrera l'attitude négative. L'attitude négative est l'exception la plus haute - cette communauté a très peu de patience pour l'attitude négative (voir la ligne de conduite précédente Soyez agréable).

Utilisez des exemples du vrai monde

Les gens inventent souvent complètement des exemples de fiction (et théoriques) afin d'essayer de produire un point de ce qu'ils essayent de produire. Les microformats sont fondés eux-même sur l'étude d'exemples du vrai monde et de la conception pour des exemples du vrai monde. De ce fait les exemples théoriques ont bien moins de valeur dans les discussions sur les microformats et sont aptes à être ignorés. Evitez SVP de poster des arguments / questions fondés uniquement sur des exemples théoriques.

Demandez des exemples du vrai monde

Si quelqu'un discute ou fournit des arguments fondés sur des exemples théoriques, demandez-lui de fournir un exemple du vrai monde et pointez-le vers les la ligne de conduite ci-dessus.

Utilisez des URLs vers des exemples

Fournissez SVP à chaque fois que c'est possible des URLs vers des exemples du vrai monde. Ceci aide à valider que de tels exemples proviennent du "vrai monde" parce qu'ils sont sur le web public et fournira un contexte supplémentaire autour de l'exemple qui pourrait être crucial pour le comprendre ou répondre à des questions.

Demandez des URLs vers des exemples

Quand les personnes ne fournissent pas une URL spécifique vers un cas de test ou un exemple, alors tout spécialement en tant que développeur, DEMANDEZ LUI SVP de fournir une URL spécifique (et citez la ligne de conduite au-dessus) plutôt que de tenter de travailler pour savoir comment un petit morceau de code dans la ligne pourrait fonctionner.

Ajoutez de l'espace-blanc au code pour la lisibilité

En particulier, ajoutez un espace blanc pour baliser les exemples pour la lisibilité. Les exemples de balisage du vrai monde sont souvent exempts d'espaces blancs, souvent avec tout le balisage/contenu sur une seule ligne de texte. L'emballage de mots typique dans l'email n'améliore vraiment pas la lisibilité. Ajoutez svp de l'espace-blanc (par ex. des retours entre les éléments, de l'indentation pour indiquer la profondeur de l'élément) afin de baliser les exemples au moment d'envoyer des messages dans la liste ou même au moment de l'ajouter sur le wiki. Voici unh exemple avant-après de mise en forme de syntaxe pour l'e-mail.

Evitez de vous répondre à vous-même pour soulever à nouveau un sujet

Tout spécialement évitez de vous répondre à vous-même juste pour soulever à nouveau un sujet. SVP évitez de vosu répondre à vous-même simplement pour pinguer la liste de discussion ou pour demander une mise à jour ou un conseil. Tout particulièrement, évitez de faire des hypothèses/conclusions simplement du fait du manque de réponse que ce soit à vous ou à vos questions. Si vous pensez vraiment que la question est importante, ajoutez-là à la page pertinente problématiques et attendez simplement qu'elle soit résolue.

Utilisez le wiki pour saisir /référencer un énoncé

Au moment de soulever à nouveau/ouvrir une discussion, fournissez svp une URL vers la page wiki appropriée qui saisissait l'état de la discussion avant. Si aucune page wiki de la sorte n'existe, demandez-là. Si personne ne peut la trouver, demandez à la liste de l'aide pour rechercher la précédente discussion et créer une page wiki pour ça. Ensuite posez là sur le wiki.

Lisez les FAQs appropriées avant de poser des questions.

Avant de poser une question sur la liste des microformats, lisez les FAQs appropriées :

• 1. Commencez avec les FAQ générales sur les microformats
  2. Puis lisez les FAQs spécifiques aux microformats, par exemple pour rel-tag, lisez rel-tag FAQ, pour adr, regardez hCard FAQ comme l'indique la spéc., etc.

Au moment de répondre aux questions sur une liste, citez les URL(s) vers les réponses FAQ.

Malgré les précédentes lignes de conduite, l'expérience nous a montré qu'il y aura des moments où des individus intelligents et considérés pourront essayer de chercher une réponse sur les FAQ, et ne pas la trouver même si elle est là. Dans de tels cas, supposez que ce n'était qu'un simple survol involontaire (plutôt que de la paresse ou un échec sur la vérification des FAQ) et au moment de répondre à une telle question sur une liste des microformats :

• 1. Vérifiez svp d'abord les FAQs appropriées, et si la réponse n'est pas là, documentez la question et votre réponse là. Par exemple posez là sur le wiki. Ceci de manière à ce que la mémoire communautaire des réponses (tout spécialement les réponses les plus récentes et les plus pertinentes) soit conservé et puisse croître d'une manière semi-organisée et nous l'espérons faciles à trouver sur le wiki, plutôt que de plonger dans la profondeurs des archives email qui sont souvent bien plus difficiles à chercher, et difficile à dire quelle réponse est "la" plus récente, et la plus pertinente.
  2. Citez les URL(s) des réponses FAQ (s) (que vous pouvez avoir simplement écrites) plutôt que de simplement écrire une réponse, au moment de composer votre réponse dans l'email. Ceci nous l'espérons encouragera plus de lecture du wiki et de ce fait l'apprentissage des réponses aux questions générales sur les microformats.

Evitez les erreurs logiques

Voir erreurs logiques pour une liste des erreurs logiques communes à éviter sur les listes de discussion.

Pointez les erreurs logiques

Quand quelqu'un emploie une ou plusieurs erreurs logiques connues sur les listes de discussion, pointez gentiment le(s) erreur(s) logique(s) avec un lien vers le(s) erreur(s) logique(s) spécifiques.

Microformats-discuss

Pour une discussion générale sur les microformats, avec un fort penchant sur :

• démarrer avec les microformats
• publication de contenu du vrai monde

Bons sujets pour la discussion

Voici une liste (certainement pas définitive) de bons sujets qui sont pertinents pour la liste de discussion microformats :

• pensées générales sur le design et l'utilisation du balisage XHTML sémantique
• comment utiliser et écrire des microformats dans le contenu
• comment utiliser les modèles de design microformats dans le contenu

Mauvais sujets de discussion

• "proposition d'un nouveau microformat : hXYZ" - tout spécialement si c'est votre premier billet. N'envoyez pas une proposition par courriel comme votre premier courriel. Il est plus que probable que vous n'irez pas très loin. Tout particulièrement, ce n'est pas une bonne manière de nommer prématurément un microformat hXYZ ou tout ce que vous voudrez. Regardez les considérations de nommage. Et lisez de nouveau le processus complet.

Bonnes thématiques qui appartiennent à quelque chose d'autre

• voir microformats-dev bons sujets à discuter

Mauvais sujets pour la discussion

Ce qui revient à de meilleurs sujets discutés ailleurs (quelque part ailleurs que sur microformats.org).

Voici une liste (certainement pas définitive) de bons sujets qui sont non désirés et inappropriés pour la liste de discussion microformats. En fait ils ne valent même pas la peine d'être discutés, aussi svp ne les amenez pas sur la liste de discussion microformats. Nous ajouterons plus de sujets au fur et à mesure que les gens viendront avec plus de thématiques hors sujet.

1. Comment produire un (micro)format d'"utilité générale". Lisez ce que ne sont pas les microformats, vraiment, allez lire la page en entier sur les principes. Parfois ceci peut se faire passer comme un "format des formats". En un sens, c'est une question qui fait bouillir l'océan et bien loin du champ des microformats. Si vous voulez vraiment travailler sur de tels sujets, enseignez-vous à vous même DTD (SGML, XML), XML Schema, Relax NG, RDF Schema, et trouvez les communautés qui sont en train de travailler sur ces technologies.
2. Utiliser des préfixes espaces-noms et espace-nom. Pour faire vite, les espaces-noms ne sont ni nécessaires (l'Internet a bien fonctionné sans eux depuis des décennies, alez lire quelques RFCs), ni désirables (les préfixes produisent des formats bien plus laids et plus difficiles à coder à la main). Voir aussi les espaces-noms considérés comme nuisibles.
3. Utiliser des noms non anglais pour les propriétés. Ceci a été brièvement discuté sur la liste de discussion microformats-discuss plus récemment sous "Language Maps" mais a été soulevé avant cela. Quelques types ont soulevé la problématique que les microformats utilisent des noms anglais pour les propriétés, et ils aimeraient des noms alternatifs (non anglais) dans d'autres langues (naturelles), et peut-être essayer d'établir une correspondance entre elles. Du fait que les noms de propriétés des microformats sont fondées sur des standards existants (voir processus, et conventions de nomenclature), ceci est un autre problème bien au delà de la portée des microformats. microformats. Comme Ryan King l'a posé, c'est un "problème" pré-existant (non résolu) avec le HTML basé sur l'anglais, la CSS basée sur l'anglais, le HTTP basé sur l'anglais et ainsi de suite. Notez qu'il ne s'agit PAS de l'internationalisation (i18n) du contenu et de la donnée en elle-même - qui est bien sûr un excellent but, défendu et promu par les microformats et les sur lesquels ils sont basés (par ex. W3C, IETF). Ceci est purement à propos des noms des propriétés (et des valeurs énumérées) dans les formats.

microformats-dev

Pour une discussion sur le développement de microformats avec un penchant vers :

• tout ce qui couvre l'écriture du code
• abstractions / modèles (à l'opposé du contenu véritable)

Bons sujets de discussion

Ceux-ci tendent à être des sujets qui appartiennent à microformats-dev au lieu de microformats-discuss. Cette liste est aussi non définitive mais illustre les chams généraux :

• parsage microformat
• "(auto)-découverte" microformat
• comparaisons des microformats avec d'autres abstractions de données ou représentations de données (par ex. XML, RDF)
• compatibilité/interoperabilité des microformats avec d'autres abstractions de données ou représentations de données

Autrefois, l'adhésion à cette liste était modérée et limitée aux personnes qui avaient démontré des implémentations publiques de microformats. Nous avons lâché du leste depuis sur cette exigence, mais maintenons actuellement les mêmes exigences que les gens impliqués dans la discussion soient concentrés sur des sujets concrets et pragmatiques en rapport avec l'écriture de code utilisant les microformats.

microformats-rest

Pour discuter de l'usage des microformats avec REST, dans les protocoles, services, APIs, etc.

Comment chercher dans les archives de la liste de discussion

Si vous postez la liste démarrez avec "Je suis nouveau sur la liste des micoformats par conséquent je ne sais pas si vous avez déjà déjà discuté de ça" LISEZ LES ARCHIVES !

Les archives deviennent de plus en plus grosses, aussi il existe de simples moyens pour vous aider à chercher. Quelques moteurs de recherche connus utilisent une sorte de filtrage de résultats du site. Google fait ça dans votre recherche initiale. Saisissez "site:http://microformats.org/discuss/ <termes de recherche ici>" pour limiter la recherche des résultats à seulement notre liste. Ceci vous aidera à ne pas poser une question qui a déjà été postée, débattue et possiblement résolue. Cela fait gagner du temps et de l'énergie à tous !

Gmane fournit une recherche alternative et une interface tout comme un fil RSS pour la liste de discussion des microformats.

microformats-new

Cette liste est pour discuter, explorer et le développement de nouveaux microformats.

Cette liste a été créée en février 2007 [1] pour réduire le "bruit" des développements de nouveaux microformats sur la liste microformats-discuss, et permet à ceux qui sont intéressés pour explorer de nouveaux microformats de concentrer leurs efforts.

Lignes de conduite spécifiques pour poster

• Assurez-vous d'avoir lu et pleinement compris le processus.
• Faites un effort pour chercher dans les archives de la liste de discussion et dans le wiki pour voir si votre suggestion a déjà été produite, ou s'il est en rapport étroit avec quelque chose d'existant. Il peut être encore plus recommandé de construire sur le travail précédent. Voir aussi formats rejetés.
• Soyez prêt de montrer beaucoup d'exmples de ce que vous avez essayé d'atteindre et quels problèmes vous essayez de résoudre dans la première instance. Les formats suggérés devraient attendre une certaine quantité d'interrogations sur le but d'un nouveau microformat - ceci ne devrait pas être pris comme une réaction personnelle ou pris personnellement !
• Produisez svp une note de toute autre microformat qui ne le produit pas à travers les processus sur la page des formats rejetés avec un lien vers la discussion et la résolution suggérée.

Bonnes thématiques pour la discussion

• Discussion sur la façon de réutiliser les microformats existants pour de "nouveaux" usages.
• Discussion sur l'extension de syntaxe existante de microformats
• Discussion du processus
• Développement de nouveaux microformats, adhérent au processus

Pas sûr

Si vous n'êtes pas sûr de quelque ligne de conduite, ou avez quelque autre question relative à la liste, vous êtes bienvenu(e) pour emailer aux admins de la liste, par exemple pour microformat-discuss : email microformats-discuss-owner at microformats dot org.

Aider à rediriger les Sujets

Si vous remarquez qu'un sujet est discuté dans une liste et qu'il serait plus pertinent dans une autre liste (par ex une discussion d'un sujet de développeur comme le "parsage" dans la liste microformats-discuss), vous pouvez aider à encourager un meilleur usage de la liste en redirigeant le fil vers la liste la plus appropriée avec un rappel aimable en haut, tel que :

Redirigez svp les discussions de "parsage" et autres sujets en rapport avec le développement vers la liste microformats-dev selon :

http://microformats.org/wiki?title=mailing-lists-fr#Mauvais_sujets_pour_la_discussion

http://microformats.org/wiki/mailing-lists#microformats-dev

Comment chercher dans les archives de la liste de discussion

Si votre billet vers la liste démarre par "je suis nouveau sur la liste et les microformats, aussi je ne sais pas si vous avez déjà discuté de ça" LISEZ LES ARCHIVES !

Les archives deviennent de plus en plus grosse, aussi il y a quelques moyens simples pour chercher dedans. la plupart des moteurs connus de recherche enmploient quelque sorte de filtrage de résultats basés sur le site. Google fait cela dans votre recherche initiale. Saisissez "site:http://microformats.org/discuss/ <search terms here>" pour limiter les résultats de la recherche uniquement sur notre liste de discussion. Ceci vous aidera à poser une question qui a déjà été posée, débatue et possiblement résolue. Cela fait gagner du temps et de l'énergie à tous !

Gmane fournit une recherche alternative et une interface tout comme un un fil RSS pour la liste de discussion des microformats.

Historique

Pour l'enregistrement, voir nos propositions pour une nouvelle liste de discussion pour discuter de la recherche et la création de nouveaux microformats (voir "microformats-new" au-dessus) de façon que ces discussions ne chevauchent pas la liste microformats-discuss.

Autres

Items concernant les listes de discussion qui ne peuvent être pas placés quelque part ailleurs.

• mailing-list-démodération