Publish change records when issues are fixed

Also I think someone has to walk through all change records and publish those that have fixed issues.

Some of them needs updates after commit so not sure it doable in an automatic way

I think ideally we'd reverse this and marking an issue as fixed would also publish any linked change records. They can still be edited after publishing and often are.

Until we move issues to GitLab, it's not worthwhile to do much work on the old system. Drupal.org will get notifications when issues are updated, so we can take actions when they are closed.

In the meantime, we should draft out the exact behavior. Should anything be posted to the issue to mention the published change records and any next steps?

Should anything be posted to the issue to mention the published change records and any next steps?

That's interesting idea. A bot could post a reminder to publish CR or event reopen the issue.

Core committers often forget to publish change record when closing issues.

It is true that sometimes a committer forgets. But it is also true that change records at the time of commit may not be ready for publication. They may have the wrong branch or version or even be for an older version of the change.

And we should understand that this is for a very small percentage of all change records. When I started this round of publishing change records for closed issues there were about 160 such change records covering a span of 10 years, from 2013 on wards. That averages to 16 change records that should have been published but weren't in any given year. In that same period there were approximately 2950 change records published. If my maths is correct then core committers usually remember to publish change records.

(I have previous done this work for supported version of Drupal. But I now focus on avoiding the problem by regular triage of the core RTBC queue).

Should anything be posted to the issue to mention the published change records and any next steps?

The issue should have a unique tag so it can be found. Otherwise, it could get lost in say, the needs work queue. And it will need someone to monitor that tag to follow up on all such issues.

Version and branch fields could be checked by bot, but some issues could use backport so version may change

That averages to 16 change records that should have been published but weren't in any given year.

While this sounds about right, that doesn't include change records which were forgotten on commit and published days/weeks/months later, which would also be helped by auto-publish.

In 📌 [meta] Improve change records Active I suggested adding a new item at the bottom of the issue templates, with two list items:

<h3 id="summary-problem-motivation">Problem/Motivation</h3>

<h4 id="summary-steps-reproduce">Steps to reproduce</h4>

[...]

<h3 id="summary-change-record">Change Record</h3> <<<<<<<<< ADD THIS?
<ul>
  <li>Create Change Record draft</li>
  <li>Publish Change Record</li>
</ul>

The items can then get marked up with strike-through, when done:

Change Record

• Publish Change Record

That's a good point catch. But I still think we should only publish change records that we know are correct.

Also, this 'problem' with change records is not unique. Issue get marked Fixed that are still tagged with any number of the 'Needs ...' tags. I have been following up on all Fixed issues to get those resolved. Although, there has been a gap due to my holiday. That this happens regularly and requires manual follow up indicates, for me, that it is the issue workflow that needs to be changed.

I just reviewed ✨ Allow failed logins in maintenance mode to be themed differently to other maintenance pages RTBC . Is it RTBC with a CR and likely to be committed. However, the CR is no longer needed and is wrong. What happens with this case when there is auto publishing?