These standards aren't about Security & Code Performance. It need not experts to make a right decision.

Coding standards was flagged to the TWG as an area where conversations would happen, then fizzle out, and no actual change would be made ... either due to a lack of understanding over how to make the consensus 'official', or due to an inability for the community to come to a consensus.

The role of the coding standards committee is to facilitate the discussion, and ensure that these conversations are followed through to a conclusion instead of stalling 'ad infinitum'. This does not mean that the coding standards committee is making the decision ... all issues are still debated in open issues, and any and all community members are encouraged to provide their input.

What this announcement means is that the issues either appear to be approaching consensus (and will soon be either marked 'fixed' and ratified into our standards, or closed), or the conversation has stalled on a key issue that the committee would like to see resolved. Consider it a 'heads up' for anyone who might want to contribute to the discussion, but hasn't discovered the existence of the various issues/proposals on their own accord.

Thanks.

But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?

I believed Public discussion only helped us to kick out impossible options. For example:

PHP array [] can't backport to D7. Or some code style bad for GIT history.

After than that

["a", "b" => ["A", "B", "C"], "c"]

OR

["a","b" => ["A", "B", "C"]"c"]

OR

array("a","b" => ["A", "B", "C"],"c")

it's Apple & Orange.

"Announced for final discussion" means that we want to wrap this one up. The process indicates that, after an initial two weeks discussion period, the coding standards committee will review the issue to determine whether i) there is a clear consensus or overwhelming preference, ii) more discussion is needed to resolve the issue, or iii) the discussion has reached an unresolvable impasse, requiring escalation or intervention.

In the case of iii), then the coding standards committee would generate a recommendation; though I wouldn't consider this issue as falling under that category. Otherwise, the "final decision" was made as it always is ... by the community through a process of open discussion in the issue queue ... and the job of the coding standards committee is to ensure that the change/proposal is published and communicated.

Thanks.

But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?

I believed Public discussion only helped us to kick out impossible options. For example:

PHP array [] can't backport to D7. Or some code style bad for GIT history.

After than that

["a", "b" => ["A", "B", "C"], "c"]

OR

["a","b" => ["A", "B", "C"],"c"]

OR

array("a","b" => ["A", "B", "C"],"c")

it's Apple & Orange.

I know that I commented on one of your previous status updates about whether we should move Drupal's coding standards closer to PSR2 by accepting the "open bracket on the next line" rule. See:

Perhaps this was discussed about elsewhere and I'm not able to discover that conversation? Perhaps I'm being ignored and we'll make no progress this year on evolving our code standards to comply with PSR2?

Please let me know how I can be a positive force in this effort

I don't recall this particular issue being reviewed at any of the coding standards meetings as of yet ... the first step would be to open a dedicated issue with the proposed change in the 'coding standards' project on drupal.org, so that other community members can have an opportunity to provide their input.