By Robert Deutz on 2022-04-19 13:14 in CMS Maintenance Team

Scheduled duration: 60min

Duration: 120min

Participants: Allon Moritz (Team Member), Benjamin Trenkle (Release Lead 4.1), Christiane Maier-Stadtherr (Team Member), Hannes Papenberg (Automated Testing Team Liaison), Harald Leithner (Release Lead 5.0), Richard Fath (Team Member), Robert Deutz (Team Leader), Tobias Zulauf (Release Lead 3.10), Viviana Menzel (Team Member), Roland Dalmulder (Release Lead 4.2)

 

Absent: David Jardin (Security Team Liaison), Fedir Zinchuk (Team Member), Franciska Perisa (Release Lead 4.2), George Wilson (Team Member),  Llewellyn van der Merwe (Team Member), Niels Braczek (Release Lead 5.0), Quy Ton (Team Member), Sigrid Gramlinger (CMS Release Team Liaison), Thomas Hunziker (Team Member), Tuan Pham Ngoc (Team Member)

 

Meeting Results

Main discussion

 

The team discussed the current state of the work. In the light of the requirement from the production department that we need to set goals for the team to reach by the end of September. We discussed the purpose and responsibility we have as a team. We agreed that the well known description of the Team from the volunteers portal still fits. 

 

This team is responsible for reviewing all patches submitted to the Joomla! CMS, merging patches into the code base, and ensuring that the high standards of Joomla are maintained at all times.

 

With this in mind we see our main area of work with Pull Request and not so much with Issues. No saying that we ignore what’s happening in the issues area of our repositories.

 

In the following discussion we talked about certain aspects e.g. but not limited to

• Handling of abandoned PR’s.
• If we want to set responsible maintainers for PR’s.
• What we can do with complicated PR’s (e.g. architectural changes) and how we bring that kind of PR’s in state that we can merge them.
• PR's often stay very long and what we can do to give a response more quickly.  

Our conclusion is that we need to act as soon as possible, we want to reply to a PR not later than 2 weeks. In this reply we want to give the creator of the PR feedback:

• if this is something we might want to add to Joomla
• in what version we want to add this
• outline a path to merge it.

Or in another situation tell the creator of the PR that we don’t want to add this. This hopefully prevents people from spending time on things that we don’t want.

 

To make sure we don’t do double work we will create a new label “Maintainers Checked” to mark PR’s that one team member has worked on. Additionally we want to use the assigned functionality of github to put PR’s in the right hands.

 

Furthermore we want to implement a process that labels PRs which have been inactive and no maintainer works on it. 

 

And last but not least we have set the goal for September 2022, working on the PRs that are older than 1.1.2021 and make a decision, if we want this added into the code base and outline a path how to add this and in which version.

Other Discussions

We decided to look more in detail into the idea to lock PR’s after a certain period of time. We collected ideas and some downsite arguments e.g. if we do this for all old PR’s notifications will be sent and that can be a lot of messages. Robert will look into this.

 

The requirement that a PR must be up to date with the branch slows activity down. It was discussed if we want to switch this off. Past experience has shown that without this requirement we run into problems when a side effect makes our testing fail. So we will let it as it is and work on speeding up the testing process. It was also noticed that the testing process is not very reliable and tests are failing without reasons. For appveyor we had the idea to just test one PHP version and not 4 or more versions. For finding the problems we expect on windows this seems to be a good compromise.