À mesure que notre processus de travail pour la base de connaissances évolue, nous souhaitons créer des limites plus claires quant au moment où les demandes de contenu peuvent être attribuées aux contributeurs et contributrices de la communauté.

Nous apprécions profondément votre expertise. La connaissance de longue date des produits au sein de la communauté est extrêmement précieuse. En même temps, le travail de contenu lié aux lancements de produits et à la collaboration interfonctionnelle exige une responsabilité claire, des délais prévisibles et une coordination structurée afin que nous puissions garantir la livraison en temps voulu d’un contenu exact et utile pour soutenir la base mondiale d’utilisateurs et d’utilisatrices de Mozilla.

Ces garde-fous sont conçus pour :

• Protéger les calendriers de lancement
• Clarifier la responsabilité et l’obligation de rendre des comptes
• Préserver une saine collaboration
• Éviter les frictions causées par des attentes peu claires

Ces changements visent à créer une collaboration durable entre le personnel et les contributeurs et contributrices.

Avant de commencer

Avant de poursuivre, veuillez noter que nous suivons des processus de travail différents pour les mises à jour mineures et majeures.

Veuillez consulter Minor vs major changes pour comprendre ce qui entre dans chaque catégorie et consultez Modifier un article de la base de connaissances pour obtenir des conseils sur la soumission directe de mises à jour mineures.

Ces garde-fous s’appliquent uniquement aux nouvelles demandes de contenu ou aux mises à jour majeures, et n’affectent pas les révisions mineures soumises directement à la base de connaissances.

Processus de contenu pour les nouvelles demandes de contenu et les mises à jour majeures

Le processus suivant s’applique aux nouvelles demandes de contenu et aux mises à jour majeures soumises via Bugzilla.

• Étape 1 : Soumission

Toutes les mises à jour majeures de contenu doivent être soumises via un ticket Bugzilla.

• Étape 2 : Triage et attribution
  • Triage : toutes les nouvelles demandes de contenu passent par un processus de triage pour déterminer la priorité et l’attribution. Les contributeurs et contributrices sont encouragés à s’impliquer, à condition que la demande corresponde aux critères d’attribution décrits dans la section ci-dessous. Pour manifester votre intérêt, veuillez commenter directement le ticket Bugzilla.
  • Attribution : l’équipe CX est responsable de l’ensemble du processus de demande de contenu, quelle que soit la responsabilité du produit, et attribuera le bogue à un contributeur ou une contributrice ou à un rédacteur ou une rédactrice technique. Veuillez ne pas commencer à rédiger avant qu’un membre du personnel de CX ne confirme votre attribution. Une fois la tâche attribuée, le ou la responsable de la communauté ou un autre membre de l’équipe CX vous guidera tout au long du processus.
  • Délai attendu : le triage est effectué chaque semaine, et les contributeurs et contributrices peuvent s’attendre à une réponse dans les 5 jours ouvrables suivant la demande initiale.
• Étape 3 : Création du contenu
  • Brouillon du contenu : examinez attentivement le ticket pour bien comprendre la demande, sa portée et le résultat attendu. Si un brouillon est fourni par l’équipe produit, utilisez-le comme point de départ. Sinon, vous pouvez commencer à rédiger le contenu dans Google Docs. Si Google Docs n’est pas une option, vous pouvez joindre votre brouillon directement au ticket Bugzilla pour révision. Assurez-vous de publier le lien vers votre brouillon dans le ticket Bugzilla et de définir les autorisations du document pour permettre aux parties prenantes de commenter.
  • Approbation du contenu : collaborez étroitement avec le demandeur ou la demandeuse ou les parties prenantes du produit pour vous assurer que l’article est complet et exact. S’il manque des informations nécessaires pour terminer le travail, utilisez l’option « Request information from… » dans Bugzilla pour recueillir des détails supplémentaires.
  • Escalade :
    • Si vous ne parvenez pas à obtenir les informations requises auprès du demandeur ou de la demandeuse, contactez un ou une responsable du support produit CX ou un ou une responsable de la communauté pour obtenir de l’aide (consultez cet article pour savoir qui contacter).
    • Si vous ne pouvez pas respecter la date limite attendue par le demandeur ou la demandeuse, veuillez en informer l’équipe CX dès que possible en mettant à jour le ticket Bugzilla ou en contactant directement un membre du personnel de CX.
• Étape 4 : Publication du contenu
  • Publication du contenu : une fois le brouillon finalisé et approuvé par les parties prenantes, vous pouvez soumettre le contenu en tant que nouvelle révision de l’article de la base de connaissances. N’oubliez pas que notre BC utilise une syntaxe wiki personnalisée, assurez-vous donc que votre contenu est correctement formaté si vous le copiez depuis un Google Doc.
  • Révision du contenu : les contributeurs et contributrices doivent attendre une révision de la BC de la part d’un membre du personnel ou d’un réviseur ou d’une réviseuse de la BC (autre que l’auteur ou l’autrice) pour l’assurance qualité et l’adéquation du balisage.
  • Clôture du ticket : une fois l’article de la BC publié, le ticket Bugzilla peut être clôturé en le marquant comme Resolved — Fixed.

Approbation du contenu ou révision du contenu

L’objectif principal de l’approbation du contenu est de valider la substance et l’intention du contenu avec les parties prenantes du produit. Il s’agit notamment de s’assurer que le brouillon du contenu est :

• Techniquement exact et qu’il reflète le comportement attendu du produit
• Conforme à la terminologie et aux conventions de dénomination approuvées pour le produit
• Cohérent avec la voix et les messages de la marque Mozilla

La révision du contenu complète l’approbation en se concentrant sur la qualité et la présentation de l’article. Cela inclut :

• S’assurer de la correction de la syntaxe et du formatage (y compris le balisage wiki)
• Améliorer la clarté, la lisibilité et la structure
• Vérifier la conformité avec les directives sur le contenu et éditoriales

Ensemble, l’approbation et la révision du contenu garantissent que les articles sont à la fois exacts et conviviaux avant leur publication.

Directives supplémentaires pour les contributeurs et contributrices

• Équité dans l’attribution

Les contributeurs et contributrices qui ont des relations directes avec les équipes produit peuvent être au courant des demandes à venir avant qu’elles ne soient officiellement soumises. Cependant, veuillez ne pas commencer à travailler ou à demander une attribution avant que la demande de contenu ne soit créée et triée. Cela garantit que les opportunités de contribution restent ouvertes et équitables pour tous les contributeurs et toutes les contributrices.

• Respecter le processus de triage

Veuillez laisser à l’équipe CX la totalité de la fenêtre de triage de 5 jours ouvrables pour examiner et attribuer les tickets Bugzilla. Évitez de demander ou de faire pression pour des décisions d’attribution avant que cette période ne soit écoulée.

• Communiquer les changements de disponibilité

Nous comprenons que des situations inattendues peuvent survenir. Si vous n’êtes pas en mesure de respecter une date limite à laquelle vous vous êtes engagé ou engagée, veuillez en informer l’équipe CX dès que possible afin que nous puissions nous adapter en conséquence.

• Politique de réouverture des tickets Bugzilla

Veuillez ne pas rouvrir un ticket de demande de contenu Bugzilla résolu pour demander la révision de modifications qui ne sont pas directement liées à la demande initiale. Pour les mises à jour connexes, ajoutez un nouveau commentaire au ticket existant au lieu de le rouvrir. Si vous n’avez pas la permission de commenter, veuillez transmettre votre demande à la liste de diffusion kb-reviewers (voir ci-dessous)

La réouverture de tickets ne respectant pas cette norme peut entraîner le rejet de la demande. Veuillez suivre l’Étiquette de Bugzilla pour maintenir une collaboration productive et respectueuse.

• Demandes de révision accélérée

Si la révision nécessite un délai d’exécution plus rapide, comme un changement de produit urgent, des incidents en cours ou des inexactitudes critiques, vous pouvez envoyer un courriel à kb-reviewers@mozilla.com pour demander une révision accélérée.

Où chercher les demandes de contenu entrantes  ?

Les contributeurs et contributrices sont encouragés à s’impliquer dans les demandes de contenu non confidentielles. Voici comment vous pouvez rechercher les demandes de contenu entrantes :

• Surveillance manuelle

Gardez un œil sur les nouveaux bogues de demande de contenu en consultant les demandes entrantes qui n’ont pas été attribuées ici. Lorsque vous en trouvez une qui vous intéresse, veuillez commenter directement le bogue pour informer l’équipe CX que vous souhaitez aider à traiter la demande.

• Rester à jour

Si vous souhaitez recevoir des notifications sur les nouvelles demandes de contenu, envisagez de surveiller le composant Knowledge Base Content sur Bugzilla. Pour ce faire, accédez à votre profil Bugzilla → Edit Profile & Preferences → Component Watching. Choisissez support.mozilla.org dans la sélection de produits et sélectionnez Knowledge Base Content dans le champ Component. Et n’oubliez pas de cliquer sur le bouton Add pour enregistrer vos modifications.

Critères d’attribution

Une demande de contenu peut être attribuée à un contributeur ou une contributrice lorsqu’elle remplit les conditions suivantes :

• Ne contient pas d’informations confidentielles

Les demandes de contenu impliquant des informations sous embargo ou du contenu sensible resteront la propriété du personnel.

• N’implique pas de dépendances internes étroites

Les demandes qui impliquent une sensibilité des messages, un examen de la conformité ou des spécifications en évolution et qui nécessitent une coordination active avec les services juridique, marketing et communication, sécurité et les partenaires externes resteront également la responsabilité des membres du personnel.

• Non liées à des produits payants

Les demandes de contenu liées aux produits par abonnement et aux fonctionnalités payantes doivent rester la propriété du personnel en raison d’exigences juridiques, de conformité, de test et de coordination interfonctionnelle. Ces demandes impliquent souvent des informations contractuelles, de facturation ou sensibles à la publication qui nécessitent une responsabilité centralisée.

• Non urgentes

Les demandes de contenu avec un délai d’exécution de moins de 5 jours resteront la responsabilité du personnel pour garantir une livraison en temps voulu et un alignement avec les calendriers de lancement.

• Capacité des contributeurs et contributrices

Les contributeurs et contributrices sont limités à un maximum de 3 attributions actives à la fois. Cela permet de garantir une exécution ciblée et d’éviter un déséquilibre de la charge de travail. Nous reconnaissons que certaines demandes peuvent être retardées en raison de dépendances techniques. Si une demande reste bloquée sur des dépendances côté produit pendant plus de deux semaines, le ticket peut être considéré comme inactif (obsolète) et exclu des attentes en matière de charge de travail des contributeurs et contributrices.

Clarifications supplémentaires :

• Cela ne s’applique qu’aux demandes via Bugzilla et ne s’applique pas aux révisions mineures de la BC.
• Cela ne s’applique pas à la création de Réponses communes du forum.
• Le personnel conserve la responsabilité finale du contenu publié.