Fields of a CSR request

[joe darcy]

Hello,

While some finishing touches are being put on the on the CSR issue type 
in Jira, for your reviewing pleasure, below is a draft guide to the 
fields of CSR issue.

In due time, I'll add this content as a page in the CSR wiki space.

Thanks,

-Joe

A number of fields are common between the CSR issue type and normal 
bug/RFE issue types and between the CSR issue type and the JEP issue 
type. Unless otherwise noted, by default the fields in common among 
different issue types are used in analogous ways in each issue type with 
the field.

Description: pre-populated with CSR template. The CSR template has four 
sections, Summary, Problem, Solution, and Specification. Follow the 
stated instructions on how to provide the requested information for each 
section.

Assignee: the engineer who is currently the person primarily responsible 
for advancing the proposal. The assignee may change over time as 
different people work on the request.

Priority: JIRA default field. Not used by the CSR process.

Labels: Free-form text

Component & Subcomponent: the technological area of the proposal; same 
classification scheme as used in the JDK project. If the proposal spans 
multiple areas, choose the area comprising the largest fraction of the 
proposal or break the proposal into multiple CSR issues.

Status & Resolution: State of the proposal in the CSR process. There are 
five basic states captured in the Status field:
Draft: In preparation by the assignee. The CSR members do not look at 
proposals in draft state.
Proposed: The request is submitted for initial review by the CSR 
members. The proposal may be known to be incomplete, but early feedback 
from the CSR is being solicited. Going through this phase is recommend 
for large CSR requests to reduce the number of round-trips of CSR review.
Provisional: After the CSR reviews a request that was proposed, if found 
to be acceptable the CSR chair moves the request to the Provisional 
state. A request in Provisional state is *not* ready to be pushed. It 
still needs further refinement and a second phase of CSR review.
Finalized: In the opinion of the assignee, the proposal exactly as 
described is suitable for inclusion in the JDK.
Closed/Approved: The CSR chair has approved the proposal for inclusion 
in the JDK. Proposals in this state can be pushed to a line of a 
development for a JDK release.
Closed/Withdrawn: The assignee has chosen to not pursue further work on 
the proposal.
Pended: The chair or other CSR member has identified an issue with the 
proposal that needs to be addressed before the proposal can be approved.

Compatibility-related fields:

Compatibility kind: check boxes for source, binary, and behavioral. 
Check which kinds of compatibility are impacted by this proposal. See 
https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility for a 
detailed discussion on the different kinds of compatibility.

Compatibility risk: minimal, low, medium, high

Compatibility risk description: Issues with a compatibility risk of low, 
medium, or high should usually have a release note.

Scope: Selection of  SE, JDK, and Implementation. This field is shared 
with JEPs.
     SE -- Affects the Java SE API or platform specification, 
approximately the exported and public portions of java.* and javax.*
     JDK -- Affects the JDK-specific API or platform, including public 
and exported jdk.* APIs
    Implementation -- An implementation-only change that does not affect 
any specification. (Such a change will most likely have behavioral 
compatibility impact.)

Reviewed by: The other engineers who have reviewed the request. At least 
one reviewer is required. The reviewers must include one or more 
engineers familiar with the components being modified by the request. 
CSR group members may serve as reviewers, but it is not mandatory to 
have a CSR member as a reviewer.

Interface Kind: Java API, System property, Language construct, ...
Check the boxes for which kinds of interfaces are affected by this request.

Fix Version/s: The versions the proposal is targeted to change. For 
update releases, it is accepted to use one of the "pool" pseudo-release 
values such as "8-pool" to indicate some yet-to-be-determined release in 
the 8 update family. If known, a particular update release version may 
also be given.

Attachments: Files related to the proposal, such as webrev.zip of 
specdiff representing the changes. Engineers are strongly encouraged to 
put bug numbers  into into the file names that are attached. For 
example, for JDK-8123456 instead of attaching "webrev.zip" attach 
"8123456-webrev.zip". If the request is updated, leave any old 
attachments in place and attach updated versions (8123456-webrev.1.zip, 
etc.). The CSR members may want to compare versions of the proposals and 
verify requested changes were made.