Skip to content

Latest commit

 

History

History
92 lines (52 loc) · 5.95 KB

File metadata and controls

92 lines (52 loc) · 5.95 KB
source-git-commit workflow-type source-wordcount ht-degree
abe5f8a4b19473c3dddfb79674fb5f5ab7e52fbf
tm+mt
739
3%

Richtlijnen voor het bijdragen aan de documentatie van Adobe Experience Manager

Documentatiefilosofie

Adobe Experience Manager-gebruikers werken in zeer concurrerende omgevingen en streven naar het creëren van digitale ervaringen die hen onderscheiden van hun concurrenten. Daarom is het van essentieel belang dat wanneer de Adobe geavanceerde nieuwe hulpmiddelen in AEM levert, deze hulpmiddelen met nauwkeurige en duidelijke documentatie worden aangevuld om de klant toe te staan om hun AEM investering onmiddellijk te gebruiken en ROI te maximaliseren.

Het doel van de AEM is zo snel mogelijk documentatie in de handen van AEM gebruikers te plaatsen. Het AEM documentatieteam geeft daarom prioriteit aan nauwkeurige, bruikbare documentatie en streeft ernaar deze voortdurend bij te werken en te verbeteren.

Documentatiebijdragen

Met het oog op de voortdurende verbetering van AEM documentatie is de hele gemeenschap van AEM gebruikers welkom om bij te dragen aan de documentatie. Of het door trekkingsverzoeken of kwesties, de verbeteringen van de documentatie kunnen correcties, verduidelijkingen, uitbreidingen, en extra voorbeelden zijn.

Documentatienormen

Hoewel het documentatieteam van de Experience Manager de bijdragen aan de documentatie van de Adobe toejuicht, moet elke bijdrage aan de AEM-documentatie - hetzij in de vorm van een pull-verzoek, hetzij in de vorm van een kwestie - in overeenstemming zijn met de bijdrage- en documentatienormen van het team.

Bijdragen die niet aan deze normen voldoen, kunnen worden afgewezen.

Het documentatieteam van de Experience Manager documenteert standaardgebruiksgevallen.

AEM documentatie behandelt standaardgebruikscenario's. Gebruiksgevallen die buiten het bereik van de standaardinstallatie en het standaardgebruik van het product vallen, maken geen deel uit van AEM documentatie.

Het documentatieteam van de Experience Manager documenteert over het algemeen geen insecten of hun aanraakpunten.

AEM documentatie behandelt standaardgebruikscenario's. Daarom zijn bugs, effecten die door bugs worden veroorzaakt, en de tijdelijke oorzaken van bugs niet gedocumenteerd.

De uitzonderingen op deze regel zijn op de versienota's van toepassing waar de bekende kwesties met mogelijke oplossingen kunnen worden vermeld die door AEM Beheer van het Product zijn goedgekeurd.

De bijdragen van de documentatie zijn niet voor het beantwoorden van technische vragen.

Alle ideeën die u eventueel nodig hebt om AEM documentatie te verbeteren, zijn welkom als bijdragen. Opmerkingen, problemen en intrekkingsverzoeken zijn echter bedoeld voor bijdragen alleen. Ze zijn niet bedoeld om u te helpen uw vragen te beantwoorden over het gebruik van AEM, het implementeren van uw AEM-project of het oplossen van technische problemen.

Eventuele vragen over het gebruik van AEM of technische fouten moeten via het normale supportproces via het Experience Manager Support Portal of in de Experience Manager.

AEM bijdragen in de documentatie zijn geen vervanging voor de klantenondersteuning van de Adobe en dergelijke bijdragen die vragen om antwoorden op ondersteunende vragen worden afgewezen.

Bijdragen moeten duidelijk verwijzen naar betrokken documentatiepagina's.

Als u een probleem maakt om verbeteringen in de documentatie voor te stellen, moet u koppelingen naar de betrokken pagina's opnemen. Als u een probleemmelding maakt met de koppeling Deze pagina bewerken op een documentatiepagina, wordt de probleemmelding automatisch gemaakt met een koppeling naar de pagina.

Dit is niet van toepassing op pull-aanvragen, omdat pull-aanvragen door hun aard verwijzen naar de betrokken pagina's.

Documentatierichtlijnen

Eventuele bijdragen aan AEM documentatie moeten aan bepaalde stijlrichtlijnen voldoen.

Met deze richtlijnen wordt de revisie van uw bijdrage gemakkelijker en daarom is de integratie in de AEM documentatie sneller.

Taal en stijl

Taal

  • AEM documentatie is geschreven en onderhouden in het Engels van de VS.
  • Zin zo eenvoudig mogelijk houden.
  • Houd de taal duidelijk en beknopt.

Alle lezers van AEM documentatie zijn wereldwijd en kunnen niet verwachten dat ze native of vloeiende Engelstalige luidsprekers zijn. Vermijd colloquialisme en houd de taal zo duidelijk en eenvoudig mogelijk.

Handleiding Microsoft® volgen

De Microsoft®-handleiding is een vrij beschikbare gids van de documentatiestijl die zich op softwaredocumentatie en AEM documentatie concentreert waar mogelijk deze gids volgt.

Opmaak

Item Stijl
UI-element of -optie vet
Bestandsnaam, pad, gebruikersinvoer, parameterwaarden monospaced
Code, opdrachtregel Code Block

Screenshots

Schermafbeeldingen moeten met de nodige voorzichtigheid worden gebruikt en alleen wanneer een tekstbeschrijving niet volstaat.

Gebruik geen markeringen of andere annotaties in schermafbeeldingen (zoals rode kaders, pijlen of tekst). Op deze manier zijn de schermafbeeldingen gemakkelijker te hergebruiken of in gelokaliseerde versies van de documentatie te herhalen.

Versiespecifieke verwijzingen

Probeer zo veel mogelijk directe verwijzingen naar een specifieke versie in de documentatie te voorkomen. Dit maakt de documentatie flexibeler en verlengbaar voor toekomstige versies.

Gebruik van Dag, AEM, CQ, CRX

Het product moet altijd met de volledige naam worden aangeduid Adobe Experience Manager voor het eerst in een artikel en kan daarna worden verwezen naar AEM.

Gebruik geen Day, Day Software, CQ en CRX, tenzij dit onvermijdelijk is, bijvoorbeeld in klassenamen of met verwijzing naar de geschiedenis van AEM.