Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Create the Architectual Decision Record (ADR) process

Aperta
  • Qualcosa non va?
#414 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Ambito
documentation

Direzione di ricerca

Inizia leggendo l’issue #413 e le linee guida collegate di ADR GitHub Organisation; non sono indicati file del repository né test. Definisci gli strumenti ADR, gli artefatti, la cartella di archiviazione, la convenzione e il processo, quindi crea tre ADR di esempio e documenta come i team possono trovarli e scriverli. Il lavoro è completato quando i criteri di accettazione sono soddisfatti e il processo è stato condiviso con altri team.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

documentation enhancement P3 - Normal (TTR: 1 month) process documentation

Overview

As a documentation contributor, I want the context for information architecture decisions, So I can understand the intent.

As a documentation maintainer, I want to know how to create information architecture records, So I can share them with stakeholders when necessary.

Description

As described by the ADR Github Organisation:

An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; Put it simply, ADR can help you understand the reasons for a chosen architectural decision, along with its trade-offs and consequences

Within the context of NGINX documentation, ADRs will be used to record decisions for a given information architecture pattern, but will likely expand to cover other decisions with large impact, such as style guide or design system approaches.

The process for these decisions is covered by issue https://github.com/nginx/documentation/issues/413: a GitHub discussion with a specific timebox, with creating an ADR as a next step.

Creating ADRs will be an ongoing task, so the focus of this issue is to define the process for managing ADRs, then socialising their existence.

Tasks

  • Decide the tools or artifacts that will be necessary for ADRs
  • Create a folder in GitHub for storing ADRs
  • Create three ADRs to show examples of the convention
  • Share the ADRs and process with other teams

Acceptance criteria

  • The user can understand what an ADR is
  • The user has clear guidance on where to find ADRs
  • The user can match any given documentation pattern to an ADR
  • The user is able to write their own ADR with process artifacts (Templates, guidance).
Lingua principale
HTML
Stelle
95
Fork
174
Merge medio
2g 4h
PR unite (30g)
84

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nginx/documentation

Tutte le issue di nginx/documentation

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.