Coding Standards Meeting Wednesday 2025-10-29 0900 UTC [#3549265]

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

0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours to allow for all time zones.

borisson_	:wave: I'm here
longwave	not really around today, but catching up on some Slack messages now
bbrala	here between the chaos (edited)
bbrala	🙂

1️⃣ What topics do you want to discuss? Post in this thread and we’ll open threads for them as appropriate.

2️⃣ Action items

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

quietone	https://www.drupal.org/project/coding_standards/issues/3541070
borisson_	This looks good, all the threads are captured. I will rtbc this

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

quietone

None

2️⃣.3️⃣ To do (edited)

quietone	Follow up on committee membership changes
quietone	Next steps for - Traits should always have the suffix "Trait" (edited)

3️⃣ RTBC issues

3️⃣.1️⃣ Allow omitting @var, @param and @return tags or their descriptions if the variable name and type is enough

quietone	This was converted to an MR so that needs to be checked before commit.
quietone	Needs issues in Coder for sniff changes. I added testing results in comment 185 to help with that.
borisson_	The MR looks correct to me

3️⃣.2️⃣ Updates for using GitLab pages

quietone	The remaining task is for the infrastructure project.
quietone	I noted the links to the revisions logs in a comment and also put the in a google doc.
quietone	I think the infra issue can be RTBCed, but it does needs another set of eye to make sure I summarized everything correctly. This is the issue,#3530663: Redirects for Coding standard pages to GitLab pages

3️⃣.3️⃣ Adopt CommonMark spec for Markdown files

quietone	This looks like a 'won't fix'
quietone	Do we all agree to that? Or not?
borisson_	I agree. We need to stick to gitlab flavored markdown.
longwave	+1 to GitLab markdown, it is the only choice that makes sense given we are moving more things to it over time

3️⃣.4️⃣ Traits should always have the suffix "Trait" (edited)

quietone	This is the 'final discussion at a CS meeting'
quietone	And it does need a review of the conversion to an MR.
quietone	And an issue in Coder, see the test results in comment 9 (edited)
longwave	the MR looks good to me

4️⃣ Membership changes - Everyone invited to say farewell (edited)

4️⃣.1️⃣ Aaron McHale is stepping down.#3550594: Remove AaronMcHale from coding standards committee

4️⃣2️⃣ urvashi_vora hasn't responded to a check-in. So being removed, Remove urvashi_vora from coding standards committee

5️⃣ Standards for tests

quietone	There is a policy issue that tries to collect all the test related issues and the issue summary needs an update. But, I was reviewing all that looking for the most 'important' thing to discuss first.
quietone	I came to the conclusion that Remove the requirement for doxygen for test methods and Define a standard for documenting data providers in PHPUnit-based tests would be good to resolve first.
quietone	The first follows the trend to not require unnecessary docs and the other is to state how to document data providers. The first may be straightforward while the second will take some work. Speaking for myself, the latter would help a lot when writing tests, especially ones with a complex set of test data.
quietone	So let's try that

5️⃣.1️⃣ Remove the requirement for doxygen for test methods

quietone	How do we all stand on this? Is there agreement in prinicple?
quietone	This is now an MR.
borisson_	the mr looks good, and I tend to agree as well, but we don't have 3 supporters yet for this issue.
borisson_	Well, actually maybe there are, but not in the new format's way of documenting them.
longwave	added myself as a supporter of this, the test method name should be enough in most cases, then we can optionally add docs only when it makes sense

5️⃣.2️⃣ Define a standard for documenting data providers in PHPUnit-based tests

quietone	Since a provider can be used for multiple test methods is makes sense to add any documentation to the dataprovider.
borisson_	I added a comment on this issue
quietone	I commented on the MR about a possible problem.