Coding Standards Meeting Wednesday, 14 February 2024 09:00, UTC [#3419359]

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, @larowlan, @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.

Jonathan1055	I'm actually here in real time, this time
catch	Hello.
Kingdutch	:wave:
urvashi_vora	Hello

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

Jonathan1055

I would like to bring attention to #2464123: Remove the requirement that no blank line follow an inline comment It has completed step 3, so we are at step 4 - review by Coding Standards Commitee. Is that done here in this meeting? (edited)

2️⃣ Action items

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

quietone	#3414201: Coding Standards Meeting Tuesday 30 January 2024 21:00 UTC
urvashi_vora	I reviewed the minutes and added missing points, also I have added a feedback, can someone please review?

2️⃣.2️⃣ TBD

3️⃣ Fixed since last meeting

quietone	We completed some admin
quietone	#3387440: Add explanatory/background information to the project page
quietone	#3405089: Refine CS process based on the experience of #3303206

4️⃣ RTBC issues

4️⃣.1️⃣ Step 8. #3324368: Update CSS coding standards to include PostCSS and Drupal 10

catch

Bumped the issue here to make it explicit it needs the documentation updates and nothing else.

4️⃣.2️⃣ Step 7 #3324368: Update CSS coding standards to include PostCSS and Drupal 10

quietone

Waiting on feedback from core committers.

4️⃣.3️⃣ Step 8 #3295249: Allow multi-line function declarations

5️⃣ Consider adding a standard for git commit message

quietone	There are several issues about this. They are list in this comment and also in this issue summary. #3419359: Coding Standards Meeting Wednesday, 14 February 2024 09:00, UTC #3351644: [meta] Improve issue management
quietone	There isn't anything in the Coding Standards wiki for the format of the commit message. Does anyone know the history of it?
quietone	And I think we should have an issue to propose that the commit message is a coding standard.
quietone	If that is accepted, we can document the current message with any history we can gather. And with such an issue accepted then we have a process that can be followed to change the message. (edited)
quietone	I also don't want the above process, if accepted, to prevent discussion of what the message should look like or if something like conventional commits is to be used.
quietone	After all, this is a big change and we need to experiment and consider that there may be tools in use that expect the current format.
catch	I don't think the commit message format has changed in 15 years or more, there probably was some discussion back then but it would have been when there was one or two committers and no TWG/coding standards committee. I'm not sure I count the commit message as a 'coding standard', but I think it's within the scope of this group + committers + DA to change it in lieu of the TWG. It will need to the DA to change the eventual templates on issues and whatever we have to do for gitlab.
klausi	the Drupal commit message format is really bad, as it does not show the most important information first. I suggest to switch to the Angular commit format a couple of years ago and use it for all my projects #2802947: [meta] Use the Git commit message format from AngularJS

6️⃣ Step 4 #2464123: Remove the requirement that no blank line follow an inline comment

quietone	This is at step 4 but it is not RTBC. Is this for review by the committee or are there other questions?
quietone	The suggested sentence in #11 was removed in #25 and I am not sure why.
quietone	I understand now.
Jonathan1055	I've been working on that issue, and the summary text proposal is the one that the three supporters support. It also caters for the problems raised in the issue. So I am happy that the proposal meets the need, and it is also codable in a sniff
Jonathan1055	who is allowed to set it to RTBC? I am happy to, but as I've been involved in it, I thought it was better not to RTBC your own issue. Ah, but this RTBC is different from other projects 'RTBC'. I will mark it now. (edited)
Jonathan1055	Ah, @Kingdutch has just rasied a question 2 mins ago. I have responded on the issue. (edited)
Jonathan1055	We could make a further relaxation for @todo comments as they are different from other types, and not necessarily related to lines of code right beneath
Kingdutch	I mean my example used @todo but I think it might've been equally valid to say:`// Input validation is skipped here because of reason XYZ.`Can we explain why we do not want is floating comments of any random kind. I think specifically commenting is a place where capturing it in a rule can be very difficult because there's always a good reason to do it differently. I think clear documentation about our intent for comments (the examples proposed in the issue mostly serve that need) is most helpful because it can ensure that a review doesn't turn into a "developer vs reviewer" debate (which is the goal of automated coding standards) but can instead be "Our documentation intends comments to be used XYZ, why are we deviating here and should we?" (I'm not against coding standards around comments, I think the rules around structuring of @todo and for proper capitalisation and punctuation are really useful for consistency and readability; it's just that I think "Where do I place a comment" is hard to capture in an automated rule)