Fields of a CSR Request

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.

If a field has not been set, the field may not be displayed. To set such a field, when logged in hit the "Edit" button of the CSR issue.

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 seven basic states captured in the Status and resolution fields:

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 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. For Java APIs, this is approximately the exported and public portions of java.* and javax.*. Other portions of the platform specification include the JNI specification, serialization specification, and so on.
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 or security property, Language construct, ..., add/remove command line option, ...
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.