Wiki Thèmes récurrents

Participer-à-LinuxFr

---

Quelques thèmes sont récurrents sur LinuxFr.org, c'est l'occasion de profiter de l'espace de rédaction (page wiki Redaction) pour travailler à plusieurs (sous licence libre CC-by-sa bien sûr).

sujets spécifiques

• Sortie du noyau Linux : voir Template-des-news-noyau
  • tous les 3 mois
  • dépêche initiée par patrick_g<Martin Peres dans l'espace de rédaction
  • suivre http://lwn.net et http://lkml.org pour creuser certains sujets
  • Dépêches_Noyau : La liste et les liens vers les nouveautés des noyaux 2.6 et supérieurs, tout nouvel inscrit peut y participer !
• top500
  • en juin et novembre de chaque année, c'est généralement patrick_g< qui l'initie
  • cf. le tag top500
• revue de presse LinuxFr.org : voir (lien template ? autre que http://demoll.tuxfamily.org/linuxfr/NewsRevueDePresse)
  • chaque mois
  • novembre 2011 publiée
• revue de presse de l'April
  • semaine, au fil de l'eau http://www.april.org/fr/revue-de-presse
  • lien vers wiki April ? (contacter echarp< pour les espaces insécables et autres typos)
• Modèle de dépêche Android
  • de temps en temps
  • quelques sujets récurrents entre cyanogenmod et replicant
  • éventuellement suivi des logiciels disponibles sur f-droid
• rubrique gamedev
  • dépêche ou journal généralement initié par rewind<
  • correspond aux étapes de conception d'un rpg
  • un chan irc:freenode.net/#jeuxlibres
• à compléter,
  • identifier des entretiens par exemple
  • il y a des séries de dépêches et de journaux sur un même thème

Activité du site

• Modèle de dépêche meilleurs contributeurs
  • une fois par mois à peu près
  • cela permet de récompenser les contributeurs au site remarqués par l'équipe de modération
  • basé notamment (mais pas seulement) sur les statistiques d'aide au choix des primables, le processus pourrait être précisé comme ci-dessous
• Modèle de dépêche meilleurs journaux
  • une fois par semaine
  • ne sélectionner que les journaux pas encore passés en dépêche (suite à une conversion)

Annonces de distribution

Chaque distribution peut s'organiser comme elle le souhaite (utilisation wiki externe, ML, coordination par la communauté, utilisation d'un journal…).

Afin d'éviter les dépêches en doublons, il est recommandé d'initier la dépêche dans l'espace de rédaction en indiquant l'organisation retenue et en fournissant un lien vers la dépêche en cours de rédaction pour recruter de nouveaux contributeurs au besoin).

• Modèle-de-dépêche-petites-distributions

Points à revoir

• suggestions d'organisation :
  • création dépêche dans espace de rédaction
  • journal indiquant le début de rédaction au besoin
  • autres moyens d'annonce (ML, blog…)
  • décider de la référence et de la coordination retenue pour la rédaction : soit dépêche, soit wiki externe ou autre
  • indiquer date cible pour éviter les contributions tardives (release early, release often)
  • indiquer les critères permettant à LinuxFr de publier
  • donner un go sur l'espace de rédaction ;
  • placer un bandeau tant que vous souhaitez garder la dépêche en rédaction
  • à défaut, nous vérifierons les liens d'officialisation de la disponibilité, sans garantie…
• bugs connus
  • limitation temporaire à rôle de « writer »
  • numérotation apparemment aléatoire des paragraphes
  • tribune en cours de refonte pour distinguer dialogues des modifications
  • besoin d'une meilleure capacité à revenir à une version antérieure
• normaliser une procédure de publication via le wiki permettant l'actualisation dans le temps et capitalisation sur les expériences passées
  • par exemple un plan-type comme Template-des-news-noyau
  • quelques recommandations (à donner) pour rédiger des dépêches noyau (annonce démarrage rédaction + recrutement, sites d'information à suivre, suivi dans le temps, date cible de relecture globale, recommandations de traductions…)
  • liste des rédacteurs

Points à discuter

• le 1er avril
  • le 1er avril, ça fonctionne plutôt bien (effet de surprise)
• les statistiques de LinuxFr.org tous les 6 mois
  • ce n'est pas tous les 6 mois
  • ça ne fait apparemment que peu réagir (contribution, consultations…) peut-être des suggestions à proposer et discuter ?
• bug squashing party aka BSP
  • objectif : prioriser dans le système de suivi
  • objectif indirect : recruter des développeurs de fonctionnalités spécifiques
  • objectif inattendu : faire comprendre comment ça marche, clarifier la coordination voire l'envoi de patchs (la procédure via github est expliquée)
  • objectif possible : expliquer comment ça marche (ou pas) et comment s'impliquer (lecteur, contributeur, modérateur, développeur, admin…)
• appel à contributions sur des sujets précis
  • revoir petites brèves : remarques à prendre en compte