The leaders of the new Production Department met on 9 February 2017 as a kickoff call to discuss the department's current state and activities and upcoming plans related to the Joomla project. As the Volunteer Portal is not yet configured for the new Joomla project structure, we are sharing these meeting notes here.
Attendees
- Michael Babker - Department Coordinator
- Allon Moritz - Media Manager Team Lead
- Cliff Pfeifer - User Experience Working Group Lead
- George Wilson - Framework Working Group Lead
- Niels Braczek - Bug Squad Lead
- Philip Walton - CMS Release Team Lead
- Puneet Kala - GSoC Team Lead
- Roland Dalmulder - CMS Maintenance Team Lead
- Sandra Thevenet - Documentation Working Group Lead
- Yves Hoppe - Automated Testing Working Group Lead
Department Coordinator’s Goals
The Department Coordinator shared his high level goals for the department and its teams, including:
- Improving communication internally and externally (meeting notes, blog posts, etc.)
- Being an enabler to the teams
- Making sure all processes and structures are documented in a way that can be referenced
- Ensuring every team has a clearly defined purpose, function, and roles
Further discussion on this raised a few questions:
Q: How often should the team meet?
A: Suggestions were every 3-4 weeks
Q: How are the team’s functions defined?
A: Team leaders should be aware of what each team’s current functions are and should also have a vision for what they want their teams to accomplish. Therefore, the team leaders are entrusted to define these functions based on the information they already have. Through collaboration, these can be refined as needed.
Q: How do the teams communicate and post content?
A: Team meeting reports should be published to the Volunteers Portal in line with current practice. As the Production Department, much of our communication will likely be centered around the project’s development and as such the Development Network should be the primary subdomain used for our department. Content should generally also get a review from marketing prior to posting.
Google Summer of Code
The department did a quick review of the submitted ideas and the GSoC team shared a voting spreadsheet for all team leads to vote on the project proposals. Idea submissions were closed on 10 February. The team leaders were asked to review and vote on proposals no later than 15 February. The GSoC team also asked to help recruit mentors for potential projects.
3.x End of Support
During the London Super Sprint, discussions regarding the 3.x end of support were started and a working plan was established that 3.8 will be the final release of the series. The department reaffirmed it supports this plan as long as 4.0 releases close to 3.8. Given the current plan for 3.8 and 4.0, the department coordinator states that the two releases should come simultaneously and as such this should not be an issue. Per the current project development strategy, a proper announcement of this must be published six months before 3.8.0 is released. Some discussion on the release timeline started, the department coordinator believes that 3.8 and 4.0 will probably not reach a stable milestone until at least six months after 3.7 is released. The department will work on the required announcement and publish it per the development strategy.
Department Resource Review
The teams collectively did an overview of the department’s current resources, including identifying teams which are not established as part of the new project team structure, identifying project websites that fall under the department’s responsibility, and discussing areas needing attention or warranting establishing new teams.
A couple of individuals had volunteered to step up and assist with the patch tester’s maintenance; those individuals will be contacted shortly. A proper team should be established under one of the department’s teams (which one to be determined) to ensure this project has proper visibility.
Discussion for a new release lead for the weblinks extension followed. One of the team leads volunteered to take on this responsibility. A short discussion was also had concerning whether there should be a team responsible for extension releases as right now this activity in some ways falls outside of our current team discussion; there was no answer to this topic.
We shortly discussed the current state of Install from Web and its maintenance, noting its team has been somewhat inactive and that there has been some issue reports without response lately. It was noted that this project was also being discussed in the JED’s development chat and it sounded like the JED wanted to reign the project in. Based on this, it seems the best plan is to allow JED to manage Install from Web with the production department’s team members who have contributed to that effort in the past being available to assist.
This topic was closed with discussing whether additional teams needed to be added. Two focus points were the CMS’ JavaScript resources and the project’s coding standards. There is a consensus that there should be a JavaScript team as an “official” project team and that a coding standards subteam should be established (two suggestions for this were under the automated testing team and documentation, no decision was made at this time). Once the officer election for the OSM Board is completed and the departments have fully transitioned to leading the project, the coordinator will take the motion to the board to establish a JavaScript Working Group. The department will further define this group’s purpose and functionality before this motion is presented.
Project Roadmap
A weakness the department’s teams has identified is the lack of a cohesive roadmap as it relates to the CMS or Framework’s development. Even with the upcoming 4.0 release, there are several teams and individuals working on several projects or having different visions for what the release should include or how to make the transition. Also, the 4.0 branch now has over 1200 commits to it with several feature changes without any clear documentation on the changes. In general, this area of discussion was broken down into several distinct sections for discussion.
Minimum Supported Software Stack
The current supported minimums for the 4.0 branch were discussed. In this period, the main area of attention was on whether a higher PHP minimum should be targeted. Based on current usage statistics, what is distributed with various operating systems or their package libraries, and the current PHP ecosystem, 5.5.9 is still a sane target. However, the teams will continue to monitor all factors related to this (and other software stacks) and will continue to re-evaluate this decision up to the 4.0 release time, at which point the minimums will be locked for the version series.
Documentation
Presently, the only documentation for the release lies in GitHub and the various pull requests. Similar to past releases, a documentation page needs to be established noting the various backward compatibility breaks and documenting the migration path for extensions.
NOTE After the meeting, a documentation page was started to be able to collect this information and the link shared with the team leads.
The second area of focus for documentation related to the help screen system. The documentation lead has noted that the current solution has become unmanageable; the sheer volume of content is difficult to manage, get translated, and is missing some features (thus far there are no screens for new 3.7 features). Some discussion was had on possible alternatives, including the potential of one of the GSoC proposals, and further discussion will happen on the topic later. Because of the potential GSoC project, it was decided this will be a higher priority item for discussion due to the timeline for that effort.
Coding Standards Proposal
A RFC was opened on GitHub to discuss whether Joomla should adapt PSR-12 once it has been accepted by PHP-FIG as a replacement for our existing PHP coding standard. This is an updated coding standard proposal to replace PSR-2. Areas of concern with adopting this proposal included how this might invalidate all open pull requests (they would need updating for code style changes) and how this complicates merging code between version branches for the various project repos. The latter point being much more complex given the number of lines of code in the CMS repository and if the code style was adopted for only the 4.0 branch. The department will vote on the topic soon.
Budget
The department reviewed the budget as voted by the PLT for 2017 and agrees with the proposal.
Code Sprint Priorities
The meeting closed with a short discussion on code sprint priorities for the year, with the consensus being that development on 4.0 should be highest priority. The coordinator requested that teams write up short proposals for the sprints they would like to have for the year so they can be properly planned out.