Eva Balycheva b53ff5d12c Refactoring of docs during Mitaka cycle

This patch improves Zaqar documentation and fixes currently existing
bugs.

Bugs this patch currently addresses and solutions:

Short names for documentation locations used in this commit message:
GitRepo - https://github.com/openstack/zaqar/
Contributor Docs - http://docs.openstack.org/developer/zaqar/
Wiki - https://wiki.openstack.org/wiki/Zaqar/

1. DRY violation and spreaded information for contributors bug.
The information for Zaqar contributors is spreaded/duplicated across
GitRepo, Contributor Docs and Wiki.
Examples of DRY violation are these three articles:
https://wiki.openstack.org/wiki/Zaqar/Give_Zaqar_a_try,
https://github.com/openstack/zaqar/blob/master/README.rst,
http://docs.openstack.org/developer/zaqar/development-environment.html

Example of spreaded information is: "zaqar/tests/functional/README.rst"
Normally the contributor want to see the information from this file in
"doc/source/running_tests.rst".

Solution: move useful missing information for contributors from Wiki and
GitRepo to Contributor Docs, then replace all contributor information in
Wiki and GitRepo with links to Contributor Docs.

2. Outdated information, missing new information and broken links bug.
Example is "test_suite.rst":
a. It still states that Zaqar test suite lives in two directories -
"tests" and "zaqar/tests", but now it's not true.
b. Doesn't contain information about how test invocation is organized,
what really happens when "tox -e py27" command executes.

Solution: replace outdated information with new, fix broken links if
possible, add useful missing information.

3. Style and formatting bugs.
The reference is http://docs.openstack.org/contributor-guide/.

Many documents in Contributor Docs have wrong line wrapping - some lines
are wrapped too short and some are wrapped too long.
Lines must wrap at 79 characters, exceptions are code and links.
Example is "first_review.rst" which lines are not wrapped at all.

Enumerated lists must be written using "#. " syntax.
Example with wrong enumerated list is "development.environment.rst".

Some inline elements must be styled according to:
http://docs.openstack.org/contributor-guide/rst-conv/inline-markups.html
Example with wrong styling of inline elements is
"development.environment.rst" where many paths and file names are not
marked with `` (double backticks).

By default code inserts are implicitly styled with python syntax.
There are many places in Contributor Docs where console (bash) code is
wrongly styled with python syntax.

Also there are some failed attempts to apply a formatting in Contributor
Docs. For example there is a broken list in "first_review.rst" at line
52.

Solution: fix broken formatting, apply proper style where it is needed.

Some of these bugs fixes closes few bug reports from:
https://etherpad.openstack.org/p/zaqar-mitaka-docs

Change-Id: Id668684248bdee03eb43b537dc2c6bb2a68ed23d

2016-01-07 17:05:09 +03:00

8.4 KiB

Raw Blame History

Welcome new contributors

First Steps

It's very great that you're interested in contributing to Zaqar.

First of all, make sure you join Zaqar communication forums:

Subscribe to Zaqar mailing lists.
Join Zaqar team on IRC. You can chat with us directly in the #openstack-zaqar channel on irc.freenode.org. If you don't know how to use IRC, you can find some directions in Openstack IRC wiki.
Answer and ask questions on Ask OpenStack.

How can I contribute?

There are many ways you can contribute to Zaqar. Of course coding is one, but you can also join Zaqar as a tester, documenter, designer or translator.

Coding

Bug fixing

The first area where you can help is bug fixing. Confirmed bugs are usually your best choice. Triaged bugs should even contain tips on how they should be fixed. You can find both of them in Zaqar's Confirmed and Triaged bugs web page.

Once you selected the bug you want to work on, go ahead and assign it to yourself, branch the code, implement the fix, and propose your change for review. You can find information on how to do it in first_patch manual.

Some easy-to-fix bugs may be marked with the low-hanging-fruit tag: those are good targets for a beginner.

Bug triaging

You can also help Zaqar with bug triaging. Reported bugs need care: prioritizing them correctly, confirming them, making sure they don't go stale. All those tasks help immensely. If you want to start contributing in coding, but you are not a hardcore developer, consider helping in this area.

Bugs can be marked with different tags according to their status:

New bugs are those bugs that have been reported by a user but haven't been verified by the community yet.
Confirmed bugs are those bugs that have been reproduced by someone else than the reporter.
Triaged bugs are those bugs that have been reproduced by a core developer.
Incomplete bugs are those bugs that don't have enough information to be reproduced.
In Progress bugs are those bugs that are being fixed by some developer. This status is set automatically by the Gerrit review system once a fix is proposed by a developer. You don't need to set it manually.
Invalid bugs are those bugs that don't qualify as a bug. Usually a support request or something unrelated to the project.

You can learn more about this in Launchpad's Of Bugs and Statuses.

You only have to worry about New bugs. If you can reproduce them, you can mark them as Confirmed. If you cannot reproduce them, you can ask the reported to provide more information and mark them as Incomplete. If you consider that they aren't bugs, mark them as Invalid (Be careful with this. Asking someone else in Zaqar is always a good idea).

Also, you can contribute instructions on how to fix a given bug.

Check out the Bug Triage wiki for more information.

Reviewing

Every patch submitted to OpenStack gets reviewed before it can be approved and merged. Zaqar gets a lot of contributions and everyone can (and is encouraged to) review Zaqar's existing patches. Pick an open review and go through it, test it if possible, and leave a comment with a +1 or -1 vote describing what you discovered. If you're planning on submitting patches of your own, it's a great way to learn about what the community cares about and to learn about the code base.

Make sure you read first_review manual.

Feature development

Once you get familiar with the code, you can start to contribute new features. New features get implemented every 6 months in OpenStack development cycle. We use Launchpad Blueprints to track the design and implementation of significant features, and Zaqar team uses Design Summits every 6 months to get together and discuss things in person with the rest of the community. Code should be proposed for inclusion before Zaqar reach the final feature milestone of the development cycle.

Testing

Testing efforts are highly related to coding. If you find that there are test cases missing or that some tests could be improved, you are encouraged to report it as a bug and then provide your fix.

See running_tests and test_suite for information on how to run tests and how the tests are organized in Zaqar.

See first_patch for information on how to provide your fix.

Documenting

You can contribute to Zaqar's Contributor Documentation which you are currently reading and to Zaqar's Wiki.

To fix a documentation bug check the bugs marked with the doc tag in Zaqar's bug list. In case that you want to report a documentation bug, then don't forget to add the doc tag to it.

Zaqar's Contributor Documentation is compiled from source files in .rst (reStructuredText) format located in doc/source/ directory in Zaqar repository. The "openstack-manuals" project houses the documentation that is published to docs.openstack.org.

Before contributing to Zaqar's Contributor Documentation you have to read first_patch manual and OpenStack Documentation Contributor Guide.

Also, you can monitor Ask OpenStack to curate the best answers that can be folded into the documentation.

Designing

Zaqar doesn't have a user interface yet. Zaqar team is working to integrate Zaqar to the OpenStack Dashboard (Horizon).

If you're a designer or usability professional your help will be really appreciated. Whether it's reviewing upcoming features as a user and giving feedback, designing features, testing designs or features with users, or helping to build use cases and requirements, everything is useful.

Translating

You can translate Zaqar to language you know. Read the Translation wiki page for more information on how OpenStack manages translations. Zaqar has adopted Zanata, and you can use the OpenStack Zanata site as a starting point to translate any of the OpenStack projects, including Zaqar. It's easier to start translating directly on the OpenStack Zanata site, as there is no need to download any files or applications to get started.

8.4 KiB Raw Blame History