OpenStack Infrastructure Blueprint Repository
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Zuul 56c1288bc5 Merge "Add a specification for Mailman 3" 7 months ago
doc/source Merge "Add a specification for Mailman 3" 7 months ago
specs Merge "Add a specification for Mailman 3" 7 months ago
.coveragerc Change ignore-errors to ignore_errors 7 years ago
.gitignore Move from oslosphinx to openstackdocstheme 3 years ago
.gitreview OpenDev Migration Patch 3 years ago
.mailmap Initial commit 8 years ago
.testr.conf Initial commit 8 years ago
CONTRIBUTING.rst Workflow documentation is now in infra-manual 8 years ago
LICENSE Initial commit 8 years ago
MANIFEST.in Initial commit 8 years ago
README.rst Update site URL 3 years ago
requirements.txt Bump blockdiag dep so that we build on newer python3 2 years ago
setup.cfg Update requirements for Sphinx 1.5 5 years ago
setup.py Update requirements for Sphinx 1.5 5 years ago
template.rst Merge "Simplify assignees section of template" 7 months ago
test-requirements.txt Update requirements for Sphinx 1.5 5 years ago
tox.ini Move from oslosphinx to openstackdocstheme 3 years ago

README.rst

Infra Specs Repository

This is a git repository for doing design review on enhancements to the OpenStack Project Infrastructure. This provides an ability to ensure that everyone has signed off on the approach to solving a problem early on.

Expected Work Flow

  1. Create a story in StoryBoard with a task affecting the opendev/infra-specs project
  2. Propose a change to this repository and make sure Task: #<taskid> for the corresponding story's initial task is included as a footer in the commit message (see CONTRIBUTING.rst for relevant documentation links). This change should also add an entry for the proposed spec document in the Approved Design Specifications section of the doc/source/index.rst file.
  3. Once proposed, members of the community provide feedback through code review, and the specification should be revised until there seems to be some reasonable consensus as to its fitness.
  4. When ready for final approval, request addition of a call for votes to the weekly infra meeting agenda.
  5. If agreed by the meeting attendees, the chair will announce an approval deadline before which members of the Infrastructure Council are asked to cast their roll call votes on the proposal under review.

Once a specification is approved...

  1. Update the story, copying summary text of specification to there.
  2. Leave a comment linking to the published URL of the specification on the specs site.

Revisiting Specifications

We don't always get everything right the first time. If we realize we need to revisit a specification because something changed, either we now know more, or a new idea came in which we should embrace, we'll manage this by proposing an update to the specification in question.