Bug 1412948 - [Tracker] Release Notes tracker bug for 2.2
Summary: [Tracker] Release Notes tracker bug for 2.2
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Documentation
Version: 2.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 2.2
Assignee: Bara Ancincova
QA Contact: ceph-qe-bugs
Depends On: 1252600 1258961 1262117 1298571 1313935 1315538 1329216 1330023 1330952 1333809 1335308 1338649 1338688 1340080 1342504 1344212 1344262 1353877 1356872 1357292 1358020 1359404 1359408 1361228 1361754 1362014 1362639 1363689 1363949 1365648 1366807 1366808 1371212 1382226 1384622 1390716 1391197 1391250 1391920 1394495 1396956 1397984 1400915 1402076 1402080 1405630 1414613 1415260 1416139 1416160 1417178 1418606 1418809 1420537 1423402 1423858 1423886
TreeView+ depends on / blocked
Reported: 2017-01-13 08:42 UTC by Anjana Suparna Sriram
Modified: 2017-10-02 14:57 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-03-20 11:19:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Anjana Suparna Sriram 2017-01-13 08:42:08 UTC
Additional info:

This tracker bug is not a tracker just for known issues but for every change that should appear in the Release Notes - major updates, technical previews, deprecated functions, and so on.

If there is a change that does not have a separate bug (for example it is a change introduced in a rebase), add that rebase bug as a blocker and specify the nature of the change in the doc text field of that bug.

**How to let us know that a bug should be documented in the Release Notes**

1) Add the BZ number of the bug that needs to be documented to the "Depends On" field in the Release Notes tracker bug. Alternatively, add the tracker bug BZ number to the "Blocks" field in the bug that needs to be documented.

2) In the bug that needs to be documented, set the doc type to one of the following:

* bug fix - for notable bug fixes that have significant impact on customers

* enhancement - for new features and major enhancements, RFE bugs

* technology preview - for new features shipped as tech previews

* known issues - for the known issues found in this release

3) In the bug that needs to be documented, fill in the Doc Text field with the initial information. Use the template that is in the field.


**Candidates for inclusion**

* Bugs with a customer case attached

* Major new features and enhancements

* Bugs with significant impact on users

* Urgent or high priority bugs

* Fixed known issues


**How a good initial description looks like**

* Use the cause-consequence-fix-result (CCFR) format for bug fixes:

    Cause – what user action or circumstances trigger this bug 
    Consequence – what the user experiences when the bug occurs 
    Fix – what has been changed to fix the bug (overly technical details are not necessary)
    Result – what happens now with the fix applied

* Use the feature-reason-result (FFR) format for major updates:

    Feature – describes the enhancement from the user's point of view
    Reason – why was the enhancement implemented
    Result – what is the current user experience (may also be compared to the previous user experience)

More info with examples:


**I want to document a change that does not have bug - how to do it?**

Add a comment here, I'll add that description manually.

Note You need to log in before you can comment on or make changes to this bug.