De Kennisbank van Mozilla blijft open voor iedereen die wil bijdragen. Iedereen kan een kleine revisie indienen om onze ondersteuningsartikelen te corrigeren of bij te werken zonder dat daar speciale rechten voor nodig zijn.

Dit document beschrijft de workflow voor nieuwe inhoudsverzoeken en grote updates die via Bugzilla worden gecoördineerd. Deze verzoeken volgen een ander proces omdat ze vaak samenwerking met productteams en andere belanghebbenden vereisen.

Als u niet zeker weet welke workflow op uw wijziging van toepassing is, lees dan de sectie Vuistregel hieronder of bekijk Kleine versus grote wijzigingen om te begrijpen in welke categorie uw voorgestelde wijziging valt.

Waarom Bugzilla?

We gebruiken Bugzilla om discussies over nieuwe inhoudsverzoeken en grote updates te coördineren, omdat dit proces vaak meerdere belanghebbenden omvat.

Het gebruik van één enkele samenwerkingsruimte helpt ervoor te zorgen dat gesprekken transparant en toegankelijk blijven voor iedereen die erbij betrokken is. We gebruiken opzettelijk Bugzilla in plaats van discussies in Kennisbankartikelen, omdat veel van onze productbelanghebbenden al in Bugzilla werken als onderdeel van hun normale workflow, terwijl relatief weinigen bekend zijn met het discussiesysteem van de Kennisbank.

Bugzilla biedt ook duidelijk taakeigenaarschap en voortgangsregistratie. Omdat het creëren van inhoud een gezamenlijke inspanning is van Mozilla-personeel en gemeenschapsmedewerkers, is het belangrijk dat iedereen gemakkelijk kan zien wie verantwoordelijk is voor een verzoek, welke beslissingen zijn genomen en welk werk er nog rest. Dit helpt dubbel werk te voorkomen, vermindert verwarring en maakt het gemakkelijker om release-gerelateerde documentatie op schema te houden.

Vuistregel

Als algemene regel kunt u uzelf de volgende vraag stellen:

Vereist deze wijziging input of validatie van het productteam?

• Zo ja, maak dan een Bugzilla-ticket aan of werk er via een, zodat de juiste belanghebbenden kunnen deelnemen aan de discussie.
• Zo nee, dan bent u over het algemeen vrij om de wijziging rechtstreeks in te dienen als een kleine Kennisbank-update.

Met andere woorden, als uw voorgestelde wijziging geen betrokkenheid van productbelanghebbenden vereist en binnen de scope van een kleine revisie valt, is het niet nodig om via Bugzilla te gaan.

Waarom dit proces bestaat

Dit proces is bedoeld om bijdragen van de gemeenschap te ondersteunen. Het helpt ons om:

• Releasetijdlijnen te beschermen
• Eigenaarschap en aansprakelijkheden helder te krijgen
• Gezonde samenwerking te behouden
• Wrijvingen vanwege onduidelijke verwachtingen te vermijden

We waarderen de expertise van medewerkers enorm. Langdurige productkennis binnen de gemeenschap is ontzettend waardevol. Tegelijkertijd vereist inhoudswerk dat is gekoppeld aan productreleases en cross-functionele samenwerking duidelijk eigenaarschap, voorspelbare tijdlijnen en gestructureerde coördinatie, zodat we kunnen zorgen voor een tijdige levering van accurate en nuttige inhoud om de wereldwijde gebruikersgroep van Mozilla te ondersteunen.

Workflow voor inhoudsverzoeken via Bugzilla

Het volgende proces is van toepassing op nieuwe inhoudsverzoeken en grote updates die via Bugzilla worden ingediend.

Inhoudsverzoeken vallen over het algemeen in twee categorieën:

• On-train-verzoeken: inhoud die is gekoppeld aan een geplande Firefox-release. Deze verzoeken zijn tijdgevoelig en moeten het releaseschema volgen.
• Off-train-verzoeken: inhoud die niet is gekoppeld aan een geplande Firefox-release. Deze verzoeken kunnen nog steeds een streefdeadline hebben, maar bieden over het algemeen meer flexibiliteit.

Voor een volledige voorvertoning, open de afbeelding in een nieuw tabblad.

1. Indiening

Alle grote inhoudsupdates moeten worden ingediend via een Bugzilla-ticket.

2. Triage en toewijzing

Triage: alle nieuwe inhoudsverzoeken doorlopen een triageproces om prioriteit en toewijzing te bepalen. Triage vindt wekelijks plaats op donderdag.

Inhoudsverzoeken die openstaan voor medewerkers worden in Bugzilla gemarkeerd met het trefwoord sumo-contributors. Als u geïnteresseerd bent om te helpen met een van deze verzoeken, kunt u uw interesse kenbaar maken door rechtstreeks op het Bugzilla-ticket te reageren.

Toewijzing: een CX-stafmedewerker wijst de bug toe aan een medewerker of een Technisch schrijver. Na toewijzing zal de Gemeenschapsmanager of een ander CX-teamlid u door het proces leiden. Begin niet met het opstellen van een concept totdat een CX-stafmedewerker uw toewijzing bevestigt.

Tijdsverwachting: triage wordt wekelijks uitgevoerd en medewerkers kunnen een reactie op hun toewijzingsverzoek verwachten binnen vijf werkdagen.

• On-train-verzoeken: toewijzing voor on-train-verzoeken is tijdgevoelig. Als een release-gerelateerd verzoek openstaat voor medewerkers maar na de volgende triagecyclus (5 werkdagen) niet is toegewezen, kan het CX-team het toewijzen aan een Technisch schrijver om ervoor te zorgen dat het releaseschema geen vertraging oploopt.

• Off-train-verzoeken: off-train-verzoeken bieden over het algemeen meer flexibiliteit en kunnen langer beschikbaar blijven voor toewijzing aan medewerkers, afhankelijk van de gevraagde deadline.

3. Inhoudscreatie

Conceptinhoud: lees het ticket zorgvuldig om het verzoek, de scope, de beoogde release of deadline en de verwachte uitkomst te begrijpen voordat u met uw werk begint.

Zodra de bug aan u is toegewezen, kunt u beginnen met het creëren van de inhoud. Als er een concept wordt aangeleverd door het productteam, gebruik dat dan als uitgangspunt. Anders kunt u beginnen met het opstellen van de inhoud in Google Docs. Als Google Docs geen optie is, kunt u uw concept rechtstreeks aan het Bugzilla-ticket toevoegen ter beoordeling.

Zorg ervoor dat u de koppeling naar uw concept in het Bugzilla-ticket plaatst en de documentrechten zo instelt dat belanghebbenden commentaar kunnen leveren.

Inhoudsgoedkeuring: werk nauw samen met de aanvrager of productbelanghebbenden om ervoor te zorgen dat het artikel volledig en accuraat is. Als er informatie ontbreekt die u nodig hebt om het werk te voltooien, gebruik dan de optie “Request information from…” in Bugzilla om aanvullende details te verzamelen.

U kunt de laatste regel van de beschrijving van het Bugzilla-formulier controleren om te zien of er een formele goedkeurder voor het concept is geïdentificeerd.

Tijdsverwachting:

• On-train-verzoeken: moeten als hoge prioriteit worden behandeld. Tenzij de voortgang wordt geblokkeerd door afhankelijkheden van andere belanghebbenden, kan het CX-team on-train-verzoeken opnieuw toewijzen als er geen zinvol concept klaar is voor beoordeling binnen een week na de toewijzing of een week voor de beoogde releasedag. Dit helpt ervoor te zorgen dat de inhoud op tijd klaar is voor de release.

• Off-train-verzoeken: het concept moet over het algemeen klaar zijn voor beoordeling door belanghebbenden ten minste één week voor de gevraagde deadline.

Escalatie:

• Als u denkt dat u de verwachte tijdlijn niet kunt halen, breng dan het CX-team zo snel mogelijk op de hoogte door het Bugzilla-ticket bij te werken of rechtstreeks contact op te nemen met een CX-stafmedewerker. Vroege communicatie geeft ons de tijd om het plan aan te passen of extra ondersteuning te vinden zonder de publicatie te vertragen.
• Als u de vereiste informatie niet van de aanvrager kunt verkrijgen, neem dan contact op met de CX-stafmedewerker die de bug heeft toegewezen voor hulp bij het verkrijgen van de informatie die u nodig hebt.

4. Inhoudspublicatie

Inhoud publiceren: zodra het concept is afgerond en goedgekeurd door de belanghebbenden, kunt u de inhoud indienen als een nieuwe revisie van het daadwerkelijke Kennisbankartikel.

Onthoud dat onze KB een aangepaste wiki-syntaxis gebruikt, dus zorg ervoor dat uw inhoud correct is opgemaakt wanneer u deze overzet vanuit Google Docs of een ander hulpmiddel dat u gebruikt om de inhoud op te stellen.

Inhoudsbeoordeling: medewerkers moeten wachten tot hun KB-revisie is beoordeeld door een stafmedewerker of een KB-beoordelaar anders dan de auteur. In dit stadium richt de beoordeling zich voornamelijk op kwaliteitsborging en juiste opmaak, in plaats van op het valideren van de juistheid van de onderliggende productinformatie.

Tijdsverwachting:

• On-train-verzoeken: het Bugzilla-ticket kan een geplande publicatiedatum specificeren die is afgestemd op het Firefox-releaseschema. Dien de KB-revisie ter beoordeling in ten minste twee dagen voor de beoogde publicatiedatum, tenzij de voortgang is geblokkeerd door afhankelijkheden van andere belanghebbenden. Dit geeft beoordelaars voldoende tijd om de uiteindelijke kwaliteits- en opmaakbeoordeling te voltooien zonder de releasedeadline in gevaar te brengen.

• Off-train-verzoeken: publicatie moet de in het Bugzilla-ticket overeengekomen deadline volgen.

Escalatie: als u hulp nodig hebt bij het beoordelen van een Kennisbank-revisie, kunt u contact opnemen met de KB-beoordelaars door een e-mail te sturen naar kb-reviewers@mozilla.com.

Ticket sluiten: zodra het KB-artikel is gepubliceerd, kan het Bugzilla-ticket worden gesloten door het te markeren als Resolved — Fixed.

Inhoudsgoedkeuring vs. inhoudsbeoordeling begrijpen

Historisch gezien zijn Kennisbank-medewerkers alleen bekend met het KB-beoordelingsproces, waarbij iedereen met KB-beoordelaarsrechten artikelrevisies kan beoordelen en goedkeuren of afwijzen.

Bij het werken via Bugzilla zijn er echter twee verschillende controlepunten:

1. Inhoudsgoedkeuring: voltooid door de juiste productbelanghebbenden tijdens het proces van inhoudscreatie in Bugzilla.
2. Inhoudsbeoordeling: voltooid door Kennisbank-beoordelaars voordat het artikel wordt gepubliceerd.

Hoewel beide belangrijk zijn, dienen ze verschillende doelen.

Inhoudsgoedkeuring door belanghebbenden

Het primaire doel van inhoudsgoedkeuring is het valideren van de inhoud en de bedoeling van de inhoud met productbelanghebbenden. Dit omvat het waarborgen dat het concept van de inhoud:

• Technisch accuraat is en het bedoelde productgedrag weerspiegelt
• In lijn is met goedgekeurde productterminologie en naamgevingsconventies
• Consistent is met de merkstem en berichtgeving van Mozilla

Inhoudsbeoordeling door KB-beoordelaar

Inhoudsbeoordeling vult de goedkeuring aan door te focussen op de kwaliteit en presentatie van het artikel. Tijdens deze fase verifiëren Kennisbank-beoordelaars dat het artikel:

• De juiste syntaxis en opmaak gebruikt, inclusief wiki-opmaak
• Helder, goed gestructureerd en gemakkelijk te volgen is
• De redactionele en inhoudsrichtlijnen van Mozilla volgt

Samen helpen deze twee stappen ervoor te zorgen dat elk artikel zowel technisch accuraat als gemakkelijk te begrijpen is voor gebruikers voordat het wordt gepubliceerd.

Aanvullende richtlijnen voor medewerkers

• Eerlijkheid van toewijzing

Medewerkers met een rechtstreekse relatie tot productteams kunnen op de hoogte zijn van aankomende verzoeken voordat ze formeel worden ingediend. Begin echter niet aan werk of verzoektoewijzing totdat het inhoudsverzoek is aangemaakt en door de triage is gekomen. Dit zorgt ervoor dat kansen om bij te dragen open en gelijk blijven voor alle medewerkers.

• Respecteer het triageproces

Geef het CX-team het volledige triagevenster van 5 werkdagen om Bugzilla-tickets te beoordelen en toe te wijzen. Vermijd het vragen om of aandringen op toewijzingsbeslissingen voordat deze periode voorbij is.

• Communiceer wijzigingen in uw beschikbaarheid

We begrijpen dat er onverwachte situaties kunnen optreden. Als u een deadline waaraan u zich hebt gecommitteerd niet kunt halen, breng dan het CX-team zo snel mogelijk op de hoogte, zodat we ons dienovereenkomstig kunnen aanpassen.

• Beleid voor heropenen van Bugzilla-tickets

Heropen een opgelost Bugzilla-inhoudsverzoekticket niet om een beoordeling van revisies te vragen die niet rechtstreeks verwant zijn aan het oorspronkelijke verzoek. Voeg voor gerelateerde updates een nieuwe reactie toe aan het bestaande ticket in plaats van het opnieuw te openen. Als u geen rechten hebt om te reageren, escaleer uw verzoek dan naar de mailinglijst van KB-beoordelaars (zie hieronder).

Het heropenen van tickets zonder hieraan te voldoen kan ertoe leiden dat uw verzoek wordt afgewezen. Volg de Bugzilla-etiquette voor een productieve en respectvolle samenwerking.

• Verzoeken om versnelde beoordeling

Als een nieuw artikel of een revisie een snellere doorlooptijd vereist, zoals een dringende productwijziging, een lopend incident of een kritieke onnauwkeurigheid, kunt u een e-mail sturen naar kb-reviewers@mozilla.com om een versnelde beoordeling aan te vragen.

Inhoudsverzoeken vinden om aan te werken

Medewerkers worden aangemoedigd om betrokken te raken bij inhoudsverzoeken via Bugzilla, zolang deze in lijn zijn met de criteria die in de volgende sectie worden beschreven. U kunt als volgt zoeken naar inkomende inhoudsverzoeken:

• Handmatige monitoring

U kunt nieuwe inhoudsverzoeken in de gaten houden door de lijst met niet-toegewezen inhoudsverzoeken te controleren. Als u een verzoek vindt waaraan u wilt werken, laat dan gewoon een reactie achter op de bug om het CX-team te laten weten dat u geïnteresseerd bent.

Na de triage worden inhoudsverzoeken die openstaan voor bijdragen van de gemeenschap in Bugzilla getagd met het trefwoord sumo-contributors. U kunt dit trefwoord gebruiken om lopende verzoeken te volgen die beschikbaar zijn voor medewerkers.

• Blijf op de hoogte

Als u meldingen wilt ontvangen over nieuwe inhoudsverzoeken, overweeg dan de component Knowledge Base Content in Bugzilla te volgen. Ga hiervoor naar uw Bugzilla-profiel → Profiel & voorkeuren bewerken → Componenten volgen. Kies support.mozilla.org in de productselectie, selecteer Knowledge Base Content in het veld Component en klik op de knop Toevoegen om uw wijzigingen op te slaan.

Toewijzingscriteria

Een inhoudsverzoek kan worden toegewezen aan een medewerker als het aan de volgende voorwaarden voldoet:

• Bevat geen vertrouwelijke informatie

Inhoudsverzoeken met betrekking tot informatie onder embargo of gevoelige inhoud blijven bij de staf.

• Heeft geen hechte interne afhankelijkheden

Verzoeken die gevoeligheid in berichtgeving, compliancebeoordeling of evoluerende specificaties omvatten en actieve coördinatie met juridische zaken, marketing en communicatie, beveiliging of externe partners vereisen, blijven ook bij stafleden.

• Niet gerelateerd aan betaalde producten

Inhoudsverzoeken met betrekking tot abonnementsproducten en betaalde functies moeten bij de staf blijven vanwege juridische, compliance-, test- en cross-functionele coördinatievereisten. Deze verzoeken hebben vaak betrekking op contractuele, facturatie- of versiegevoelige gegevens waarvoor een centrale verantwoordelijkheid nodig is.

• Niet tijdgevoelig

Inhoudsverzoeken met een doorlooptijd van minder dan 5 dagen blijven bij de staf om voor tijdige aflevering en uitlijning met releaseschema’s te zorgen.

• Medewerkercapaciteit

Medewerkers zijn beperkt tot een maximum van 3 actieve toewijzingen tegelijkertijd. Dit helpt te zorgen voor een gefocuste uitvoering en voorkomt een onbalans in werkbelasting. We erkennen dat sommige verzoeken vertraagd kunnen worden vanwege technische afhankelijkheden. Als een verzoek geblokkeerd blijft door productzijdige afhankelijkheden gedurende meer dan twee weken, kan het ticket als inactief (verouderd) worden beschouwd en worden uitgezonderd van de werkbelastingverwachtingen van de medewerker.

Aanvullende verduidelijkingen:

• Dit is alleen van toepassing op verzoeken via Bugzilla en is niet van toepassing op kleine KB-revisies.
• Dit is niet van toepassing op het aanmaken van gebruikelijke forumantwoorden.
• De verantwoordelijkheid voor gepubliceerde inhoud blijft bij de staf.