![]() Pay extra attention to grammar and punctuation.Ensure all content is formally written in the active voice.There are other guidelines we should follow to meet standards. Reviewing documentation is similar to regular pull requests. Find more information about this step here. Configure the CI so that it automatically publishes the documentation to the GitHub Wiki via a GitHub Action.On approval, merge the documentation branch to development.Submit a PR for the documentation branch to be reviewed.After merging a feature branch, work on the documentation branch.Merging Documentation Creating New Documentation These sections are where we place all application features and functionalities.Īn example wiki we’ve made can be found here. This section contains any Architecture Decision References (ADRs) and explanations of the high-level application flow.Īll sub-headings are specific application flows on the application. Usually, the format of this section is consistent with other projects. Inserting test accounts, generating required secret keys.) Any information that helps setting up the development environment in a usable state.More technical project setup information is in this section. It also briefly explains any specific terminology used in the application. This section contains a general summary of the project and background information about the application. The mandatory sections are the following:īelow is an example of what it could contain: Organizationĭocumentation has to follow a standard structure for consistency across projects. Ultimately, all details worth explaining in terms of the application functionalities would be in the GitHub Wiki. There are other cases like when adding a third-party service or cron job that requires explanation, but that is on a case-by-case basis. Whenever completing an epic or sizable feature, be sure to allocate some time to write documentation. This technical documentation also saves time during project handovers and increase the value of the product we deliver to our clients. Writing this technical documentation allows making the rotation process efficient and repeatable thus yields a high return over investment. The reason we write in the GitHub Wiki is to aid the onboarding process of new developers and decrease the amount of “gotchas.”Ī standard squad rotation takes up to a month to fully onboard a developer. The goal is to express the application targeted towards developers in an easily accessible single source of truth. Unlike regular documentation created by the Product Managers, GitHub Wiki documentation aims to describe the application in as granular detail as possible.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |