By Marco Dings on 2020-04-21 23:59 in Production

Production Dept. Meeting
April 21, 2020
1900 CEST, UTC+2  Event time TZ

Scheduled duration: 45min

Duration: 80min

Participants: Benjamin Trenkle (Team Leader), David Jardin (Team Leader), George Wilson (Release Lead 4.0), Harald Leithner (Release Lead 3.9), Marco Dings (Department Coordinator), Nicola Galgano (Team Leader), Niels Braczek (Team Leader), Philip Walton (Team Leader), Tobias Zulauf (Release Lead 3.10)
Tentative: Hannes Papenberg (Team Leader)

Absent with notice: Robert Deutz (Team Leader), Carlos Cámara (Team Leader), Mike Brandner (Team Leader), Puneet Kala (Team Leader)

Absent without notice: Ilagnayeru Manickam (Team Leader)


Agenda Items & minutes

Department Coordinator (Marco Dings)

Talk Topics:

  1. @plt mailing group has been switched over to all addresses. Note that email forwarding from @cjo addresses is going to be disabled at organisation level at some point in the future

  2. Motion sent on “Solve InputFilter “magically” returning arrays by adding an additional parameter”.
    Result : UNDECIDED, not enough votes.
    Discussion on discrepancy with initial discussion needed in GLIP

  3. Doc “Guidance for Team Leaders” in preparation, currently tried out by/in Programs

  4. Poll for members on their role and expectations

  5. RFC for RfC explanation/discussion meeting sent out as a doodle. Please comment in the referred document and let discuss

  6. Joomlacode replacement has ongoing discussions with George, Harald, Wilco and Me.

  7. Appointment of ADC and ATL. Please appoint somebody to support you and who can fill in if you are indisposed 

  8. Any takers for ADC?, role that luca took on previously, personal interpretation of duties and responsibilities tbd. Please PM marco.

 Joomla! Enhancement Development Team (Benjamin Trenkle)

Working groups

  • Workflow (JEDT - WF)

    1. com_content can now be disabled workflow completely (some magic still happens in the background). 

    2. Queries are all rewritten

    3. Workflow supports now full plugin integration

    4. Publishing plugin nearly done

    5. Big todo: List view of com_content and frontend has to be tested

  • Current (stable) status: 


Joomla Accessibility Team (Carlos Cámara Mora)

Talk Topics:

  1. Started auditing Cassiopeia and will open issues and send PRs soon.

  2. We requested the Volunteer Engagement Team help to get more people with enough knowledge and experience involved in the team.


Security Strike Team (David Jardin)

Talk Topics:

  1. Input Filter Array handling - how to move on?

  2. Handling of FPD (full path disclosures) - proposal: “FPD triggered by errors/warnings/notices/deprecations within the CMS context aren't covered by the security policy, because they can be suppressed by disabling the error reporting the CMS config, which clearly is within the users sphere of influence. FPDs outside of the CMS context (i.e. files that are directly accessible because they lack a JEXEC-Check, or files triggering compile time errors) will still be covered by the policy and fixed in security releases.”. Motion will be sent out for this

Updates/Proposed Topics:

  1. 3.9.17 released, fixing 3 minor issues

  2. DMARC record added for


Release Leads (George Wilson, Tobias Zulauf, Harald Leithner)

* Release lead 4.0 (George Wilson)

  1. Continued working on docs for J4

  2. Working on the Language Pack component for the downloads site.

    1. Apologies to those who have had slow response times from me - most my bandwidth is on this at the moment.

  3. Thanks to Ciaran for doing a large amount of template CSS cleanup for things that have fallen through the cracks over various template versions (which he had flagged with me at various times too)

  4. Disappointed that after requesting help on the last 3 beta blockers I’ve been helped with just one. I thought J4 beta was the department priority...

* Release lead 3.9 (Harald Leithner):

  1. Joomla 3.9.17 Release today with a last minute revert of PR #28429

  2. Joomla 3.9.17 has an issue with viewing tags and has been pulled from the update server. Joomla! 3.9.18 released on the same day to fix this problem.


Documentation Team (Mike Brandner)

Talk Topics:

  1. Preparation for GSOD ongoing (stopped last days, because I was too busy)
    Next week I'll submit the project (main focus J4 help pages and tutorials)


Updates/Proposed Topics:

  1. JDoc stuff for JED is now moved to the new JED knowledgebase:

  2. Cleaning up the docs - several extreme outdated docs marked for deleting soon -
    more in focus, duplicate content cleaned

  3. J4 works ongoing


Bug Squad (Nicola Galgano)

Talk Topics:

  1. We are quite near to propose a full update for the issue tracker process:

    1. Revamp of the code owner feature vs accountability

    2. Reconsider the use of a bot to mark stale issues/pr’s

  2. Absence of support from PDT to the bug and fun @home event


Updates/Proposed Topics:

  1. We have a new member Ciaran Walsh 


Software Architecture & Strategy Team (Niels Braczek)

Talk Topics:

  1. J4.0 Features: In the last couple of days there has been a discussion about the Adaptive Images feature that was created in a GSoC project two years ago. The feature itself is valuable, otherwise it would not have qualified for GSoC. The implementation seems to need improvements. Despite Dimitris’ tone in the discussion on GitHub, he might have a valid point. This leads to two questions:

    1. Does it make sense to add more features to J4.0?

    2. How do we want to deal with pull requests that do not meet our expectations?

SA&S suggests:

Ad a) No additional features should go into 4.0.

Ad b) For the handling of insufficient Pull Requests two cases are distinguished.

  • If a Pull Request needs minor improvements, it should be kept open and developed towards the expected result.

  • If a Pull Request needs major rework, it should be closed with an appropriate comment. The contributor should be asked to improve the work and open a new Pull Request if ready.


In general, comments on PRs should be constructive. Contributors are putting valuable time and effort into “their” PRs, so we should really appreciate that.

If a PR is insufficient, it shows some lack of knowledge. We need to assist the contributors in such cases. For GSoC projects, this should be done by the original mentors; for other projects, SA&S is in charge, if no mentor for that feature can be found among the development teams.

It would be helpful to have “Guidelines for Mentors” among other stuff describing how to make sure the quality of the project is suitable.

GSoC Projects: All GSoC projects that succeeded but not went into core yet need a review. This can be done by starting an RfC process for each of them.

Updates/Proposed Topics:

  1. RfC-RfC: The proposal needs to be discussed within the Production Department. The discussion is planned to be held in two sessions; Doodle is sent out.

  2. PM Tool: No progress ATM. A small survey has been conducted to learn about needs and expectations especially from non-development teams.

  3. UX: The UX Team(s) seem not to make progress. We need accessibility testers and implementers. At least one of the implementers should be familiar with the standards and their implementation to rework fx. one of the admin list views. Other implementers can then port the implementation to the other list views. We need tutorials / videos about accessibility testing to enable more people to test in this area.

  4. Market: We still lack a definition of our market (target group) - not the one we have currently, but the one we want to have for the next couple of years. We are currently wasting power, because people are targeting different groups -  Wix and the like on one side, Laravel and the like on the other. These target groups have different requirements regarding implementation details. We can not start to develop strategies, if the target is not fixed.


CMS Release Team (Philip Walton)

Talk Topics:

  1. Having a clear tagging system in Github so that we do not need to add patches to test in a sheet but that they are tagged in github and the link is to the tag.

  2. Ideally some indication of level so we could have easy, medium and hard so that people new to patch testing will be able to select the right level. This could perhaps also show in the patchtester

Updates/Proposed Topics:

  1. Going through testing on Joomla 3.9.17 at the moment  Also the Bugs and Fun @Home are growing in the reach of people



Google Summer of Code Joomla Team (Puneet Kala)

Talk Topics:

  1. Looking into Season of docs, will prepare application



Other Business

Talk Topics:

  1. [HL] Nginx minimum Version suggestion is 1.10 based on it’s the lowest version with a significant usage compared to older versions (10%) all other versions are newer. Nginx Version 1.10 has been released in April 2016

Updates/Proposed Topics:

  1. [NB] GitHub authentication: Work in progress, nothing yet to report.

Finalized Motions


Allow progressive features

Joomla's current policy is that we only accept changes or features that work for everything that meets our minimum requirement (e.g. PHP versions, browsers, database versions etc..)

The motion goes beyond this by allowing progressive features. This allows us to take advantage of new technology for those that use it as long as there is no adverse effect to those that don't (this should also take into account the support/documentation affects on such conditional features). As an example we could look at "lazy loading" or at "same site cookies". This motion means that a PR or ISSUE should not be closed or rejected on the argument that it IS a progressive feature. The acceptance of such an issue or feature is still subject to the usual and accepted scrutiny and discussion.



Solve InputFilter “magically” returning arrays by adding an additional parameter

Add a new method parameter "$asArray" to the "InputFilterclean" method and "Inputget" to define the desired behavior for the handling of array values. The parameter accepts 3 values, defined as class constants: ARRAY_NO, ARRAY_CAN, ARRAY_MUST. Use a default "ARRAY_CAN" value in 3.x, keeping the current behavior and allowing to log deprecated usages of the method. In 4.x, use a default "ARRAY_NO" value."