Updating docs to provide additional context

Upon reflection, we have determined that we need to provide
a greater amount of context to those contributing in order to
drive a higher quality end result.

Change-Id: I8f0a24d929db78a45fdda2e30091aeb945c2802b
This commit is contained in:
Julia Kreger 2015-10-27 19:48:00 -04:00
parent a693f674f2
commit 355513d76e
2 changed files with 59 additions and 6 deletions

View File

@ -11,12 +11,12 @@ For a highly abridged version, read on.
Communicating
-------------
Before you file a ticket or submit a pull request, its often helpful to chat
with other developers. The #openstack-ironic channel is a good place to start,
and if you don't have IRC (or would prefer email), openstack-dev@lists.openstack.org
is the mailing list for all OpenStack projects. As the name implies, that mailing
list is for all OpenStack development, so it's often harder to get attention on
your particular issue.
Before you file an Bug or new review set, its often helpful to chat with other
developers. The #openstack-ironic channel is a good place to start, and if
you don't have IRC (or would prefer email), openstack-dev@lists.openstack.org
is the mailing list for all OpenStack projects. As the name implies, that
mailing list is for all OpenStack development, so it's often harder to get
attention on your particular issue.
-----------
Filing Bugs
@ -57,3 +57,44 @@ Once that's done, the development workflow is, roughly::
From that point on, the link the git review command generated is
the place to do final tweaks. When its approved, the code
will be merged in automatically.
If you propose a new feature and are unable to complete it, please
let the community know by commenting in the review set indicating
that someone else is free to carry on your change. If the core
reviewers observe reviews that are not being actively worked on,
we are likely to inquire with you. If a review is untouched and the
owner of the review is unreachable for a lengthy period of time,
such as three to six months, the core reviewers may abandon the
change as we do not utilize auto-abandon.
----------
Code Style
----------
Bifrost is a mix of Python, YaML, and bash thrown in for good measure.
The overall intent is to keep features, and changes simple to permit a user
to easily understand and extend bifrost to meet their operational needs as
we recognize needs may vary.
With this, we have a list of things that we would like people to keep in mind
when contributing code.
1. Try to limit YaML to 79 characters per row, we understand this is not
always possible, but please make an effort.
2. Try to keep change sets as short and to the point as possible.
3. Rather than pass key-value pair strings to Ansible modules, try to utilize
key-value pair lists on a module command line. Example::
- name: "Stat file for x reason"
stat:
file: '/path/to/file'
get_md5: no
4. Be clear and explicit with actions in playbooks and comments.
5. Simplicity is favored over magic.
6. Documentation should generally be paired with code changes as we feel
that it is important for us to be able to release the master branch
at any time.
7. Documentation should always be limited to 79 characters per row.
8. If you have any questions, ask in #openstack-ironic.

View File

@ -6,6 +6,18 @@ deploying a base image onto a set of known hardware using ironic. It
provides modular utility for one-off operating system deployment with
as few operational requirements as reasonably possible.
Use Cases
=========
* Installation of ironic in stand alone/noauth mode without other OpenStack
components.
* Deployment of an operating system to a known pool of hardware as
a batch operation.
* Testing and development of ironic in a standalone use case.
Use
===
This is split into roughly three steps:
- **install**: