Integration round 2020-03-27 - Isolate and educate

Integration round 2020-03-27 - Isolate and educate

بواسطة - Jake Dallimore
عدد الردود: 4
صورة Core developers صورة Moodle HQ صورة Particularly helpful Moodlers صورة Peer reviewers صورة Plugin developers صورة Testers
Cold numbers

16 issues have been successfully integrated, with 2 rejected and 18 delayed. That is a 89% success rate for this week. Great work, everyone.

Notes

The long-waiting peer review queue is slowly coming down. Let's keep up the great work and try to keep this down below 50!

Hot topics

MDL-67442 - Assignment comments now expanding properly on Safari.
MDL-58413 - The URL activity now support internationalised domain names.
MDL-67934 - Quiz now suggests default id numbers when duplicating questions.

Warm thanks

To John Beedell of The Open University UK, for 13 years of contributions to Moodle alongside plugin development and general contributions to the wider community.


"Our human compassion binds us the one to the other – not in pity or patronizingly but as human beings who have learnt how to turn our common suffering into hope for the future" - Nelson Mandela

متوسط التقييمات:Useful (2)
رداً على Jake Dallimore

Re: Integration round 2020-03-27 - Isolate and educate - addendum

بواسطة - Eloy Lafuente (stronk7)
صورة Core developers صورة Documentation writers صورة Moodle HQ صورة Particularly helpful Moodlers صورة Peer reviewers صورة Plugin developers صورة Testers

Because the world is round... following there are a couple of things that you may be also interested...

One at a time

This (non-regular) new initiative in the integration posts aims to get various policy issues communicated and, with your collaboration, decided and applied in an organised way.

Last week we (thanks all!) achieved an agreement about MDLSITE-5879 which basically says:

Unless otherwise specified, this Coding Style document will defer to PSR-12, and PSR-1 in that order.

Where a de-facto Moodle standard* is encountered but is undocumented, an appropriate MDLSITE issue should be raised to have the standard either documented within this Coding style guide, or rejected and the PSR recommendations adopted instead.

* "de-facto Moodle standard" is any coding style which is commonly and typically used in Moodle

(you can find the complete version already @ Moodle Docs / Coding style)

For next week, we want to propose the following issue, that shouldn't be problematic at all, just granting you the opportunity of commenting there over the next 4 days. Ideally, once official, an issue will be created to enforce it from code-checker... and done! It's MDLSITE-5667, see you there!

Tracker scheduled upgrade

Next Monday 30th of March a schedule upgrade of our beloved Tracker will be performed. The site will be under maintenance (not accesible) starting @ 16:00 UTC (18:00 CET) and will last some good hours (estimations say that between 3h and 6h).

So, be warned, and if you need to fetch/catch/capture anything from it... do it before the scheduled time above.

That's all, have a great weekend and, everybody... stay safe! Cheers!

Ciao مبتسم

رداً على Eloy Lafuente (stronk7)

Re: Integration round 2020-03-27 - Isolate and educate - addendum

بواسطة - Nadav Kavalerchik
صورة Core developers صورة Plugin developers صورة Testers صورة Translators
So can we start using "CamelCase" in variable names?

PSR-12:
> 2.1 Basic Coding Standard
> Code MUST follow all rules outlined in PSR-1.
> The term ‘StudlyCaps’ in PSR-1 MUST be interpreted as PascalCase where the first letter of each word is capitalized including the very first letter.
رداً على Nadav Kavalerchik

Re: Integration round 2020-03-27 - Isolate and educate - addendum

بواسطة - Eloy Lafuente (stronk7)
صورة Core developers صورة Documentation writers صورة Moodle HQ صورة Particularly helpful Moodlers صورة Peer reviewers صورة Plugin developers صورة Testers

So can we start using "CamelCase" in variable names?

No, I'm afraid.

For anything already ruled* OR being a "de facto" style in Moodle, own coding style "wins". And "variable names" is already ruled.

For the unknown (not included in the previous paragraph), we'll default to the PSRs. Creating new policy issues when needed. To have a track of them, solve conflicts between PSRs and "de facto" situations, ... towards a clear outcome and subsequent actions (modify style docs, ensure analysis tools are able to detect violations, fix core cases...).

So, summary, just to be 100% clear: We are not switching to PSRs, but using them as default fallback for the unknown (unruled).

Ciao مبتسم

* "already ruled" : That's pretty much the spirit behind the "Unless otherwise specified...." in the Docs (happy to amend it towards a clearer / easier reading and understanding if needed, ideas welcome).