Goal: 
Find an issue that needs a change record to be made. Create the change record page.
Skills required: 
Technical writing (English)
Background and reference information: 
Find the issues for a project
Creating or updating an issue report
Detailed steps: 
  1. Set up prerequisites: Log in and Confirmed user from Common Prerequisites for Contributors.
  2. Find the issue list for the Drupal core project.
  3. Use Advanced search to find an open issue tagged with Needs change record. If there are not any, you will need to find another task to do.
  4. Click the issue title to go to the issue page, and verify that:
    • It does not already have a change record present at the top of the sidebar in the "Change records for this issue" section. Here's an example of an issue that already has a change record.
    • No one else has recently commented on the issue saying they are writing the change record for it.
    • You understand the issue.
    • You understand the software patch for the issue. For example, to write a change report for an issue whose patch is PHP code, you would need to be able to read and understand PHP code.

    If there is already a change record present, or if someone else is already working on writing the change record, or if you don't understand the issue or the patch, find a different issue to work with.

  5. Add a comment to the issue saying you are writing the change record. See Creating or updating an issue report for details on how to comment and change fields on an issue.
  6. Read through the issue summary (if there is one), or the issue comments (if there is not one or it lacks detail), and the committed patch, to figure out what the change is, and what the impact of the change will be on:
    • Drupal users (site builders, administrators, editors) - user interface changes - these will probably be described in issue comments or in the issue summary.
    • Module developers - API function/class changes. You will need to look through the patch to find any functions etc. that have changed, with the exception of "internal-use" and test-only code. Hook definitions deserve special notice: hook definitions are in *.api.php files, with documentation and (usually) sample code. If the signature of a hook function and all of its implementations have changed, you will need to describe the changes to the hook definition and mention that all the implementations have been updated, rather than listing all of them.
    • Themers - theme function/template changes. Again, read through the patch to find these.
  7. Click the add change notice link in the issue sidebar, to create a new change record. Fill in:
    • Title - Short description about what is new. In general, do not just copy the issue title. The title should be clear and specific so that people can easily see if it is relevant to them when searching the change record list.
    • Project - Drupal Core
    • Published - Leave this unchecked to create a draft change record (change records are published when the change is committed).
    • Introduced in branch - Enter the earliest development branch (9.x, 10.x, 7.x).
    • Introduced in version - Enter the earliest release version (9.4.3, 9.5-beta). If unsure, leave blank.
    • Issues - your issue should already be filled in
    • Impacts - check boxes based on who you identified would be impacted by the change
    • Description - detailed description of the changes you identified. Suggested format (you can also look at other change records for examples, and search for keywords to find ones similar to the change you are describing):

      Summary

      • Bulleted list here.
      • Another point.

      Before

      // Example code before the change here

      After

      // Example code after the change here
  8. Save the change record.
  9. Back on the issue:
    • Add a comment with a link to the change record you wrote and inviting others to review it.
    • Remove the "Needs change record" tag.
    • Save your change and comment on the issue.