Coding Standards Meeting Wednesday 2025-08-27 0900 UTC [#3541070]

Hello all, it’s time for the fortnightly coding standards meeting.

This meeting:
➤ Is for anyone interested in the Drupal coding standards.
➤ Is held on the #coding standards channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Usually happens fortnightly. Alternating between Tuesday 2100 UTC and Wednesday 0900 UTC.
➤ The meeting open for 24 hours to allow for all time zones.
➤ Discussion is done in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously.
➤ Has a public agenda anyone by adding a comment to the meeting issue.
➤ A transcript will be made using drupal-meeting-parser and posted to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
➤ The transcript will include comments made during the 24 hours of the meeting. However, comments made after the 24 hours may not be in transcript.

Current ping list: @catch, @longwave, @quietone
@dww, @borisson_ @longwave @Björn Brala, @Aaron McHale, @Alex Skrypnyk, @Urvashi, @Kingdutch

2️⃣.1️⃣ Approve minutes for previous meeting(s)

quietone

@borisson_ reviewed and set the last 2 meeting minutes to RTBC. I have just set them to fixed, so this is up to date.

2️⃣.2️⃣ Issues to go to core committer meeting

quietone

Traits. #3521443: Traits should always have the suffix "Trait"

2️⃣.3️⃣ TBD

3️⃣ Update on yearly check-in with team members

quietone	Emails have been sent to 4 of 7 members. I lost the email addresses for 2 members and I don't need to send myself an email.
quietone	Of the 4, 3 have replied that they wish to continue. They are bbrala, catch, and longwave. I will also include myself in those that wish to continue.
quietone	I will continue to chase emails for the 2 I don't have.
quietone	And members have 4 weeks to respond. If there is no response then they will be removed from the committee.

4️⃣ Infrastructure issue for the conversion to GitLab pages, #3530663: Redirects for Coding standard pages to GitLab pages

quietone	We needs to consider the options given by drumm in comment #6
quietone	I think they are redirect and delete Keep the pages with a notice at the top. redirect without delete (see paragraph 2 of that comment).
quietone	I am for keeping the history of a selected number of the coding standard pages. The main PHP one would be one of those to keep.
quietone	The link to the original doc page could be kept on the project page in a 'reference section' or some such thing.
quietone	Reviewing the pages I think these are the pages where the history should be kept. Everything in the PHP guide, except the examples page, the composer page, the pages in the SQL guide and the JavaScript Coding standards page. I count that at 13 pages.
quietone	So, I am thinking about 13 pages are in option 3 and the rest are option 1.
bbrala	Probably good. But will mean duplication. Might also be possible to recreate the history if we like to keep that. A history of the body field could probably be supplied l. Although that is probably some effort depending how automated rhe conversion to the needed format would be.
Jonathan1055	Also the problem of keeping the old pages accessible is that there is no way to prevent someone updating them. Even if there is a notice at the top, some folks will still make updates. That then gives extra hassle to revert the unwanted changes. If we really want the history (and I don't quite understand why we need it) then is there some way to save it elsewhere, so that the actual pages can have re-directs and be deleted?
quietone	I don't recall the instances but I have used the history to track down when something changed. I'll investigate more on this today.
quietone	I looked again and still want to keep the history for the 'key' pages.
quietone	Also the problem of keeping the old pages accessible is that there is no way to prevent someone updating them On the issue drumm states "Redirects without deleting make the old pages mostly inaccessible". I am counting on that. The only way to find them should be via the project page and that will explain that they are archives. Plus, the links to the Gitlab pages will be prominent. So, I am thinking it is worth the risk.
quietone	I have commented on the issue with my ideas.
quietone	What do you think?
catch	So the main argument against redirecting and not deleting is that the pages would be nearly inaccessible but that seems like a bonus to me. Could we leave one page in the handbook with no redirect and add manual links to the revisions history tab from there maybe?
Jonathan1055	On the issue drumm states "Redirects without deleting make the old pages mostly inaccessible". I am counting on that. the pages would be nearly inaccessible but that seems like a bonus Yes, I see now. That seems like a good solution. In fact the old pages do not need to be advertised very publically at all in the Coding Standards project, we can just keep a list of them somewhere, manybe on one of the new Gitlab Pages, in a section marked 'legacy links' or something. certainly not on the project front page.
quietone	@Jonathan1055, adding the 'archived' pages to the new GitLab pages is an attractive idea.
quietone	@catch, I am not following your idea of one page in the handbook with links to revision tabs. Right now, it seems complicated.
catch	hmm there are two parts: If we do a real redirect without deleting, then trying to visit the original pages will redirect, but the history will still be there on d.o That means to get to the history of the page, we need to get to node/n/revisions - if we have a link to that from anywhere, we can access it when we need to.
quietone	Right, I see now. That makes sense. Frankly, I was expecting to follow whatever drumm thought best when it got to implementation.
quietone	For us, we need to be sure that only the 14 pages I listed in the comments should have the revision history preserved.OR we decide to preserve the history for all the pages in the Coding Standards guide.
catch	I can post this idea on the issue.
borisson_	I think this idea makes sense, I haven't needed to use the old versions - but it seems like some already have used this. In any case,I think we should push forward with this because keeping this pages monitored for changes manually seems like it's not a sustainable solution.

5️⃣ RTBC issues

5️⃣.1️⃣ Traits should always have the suffix "Trait"

quietone	I think this needs an issue in coder to enforce the use of Trait as a suffix.
quietone	It is a reasonable change.
bbrala	Agree it is a reasonable change which helps in readbility.

Participants:

quietone, bbrala, Jonathan1055, catch, borisson_