The Production Leadership Team manages all areas of Joomla! development, including documentation, design, coding, and development cycle. In addition, the Production Leadership Team manages all areas of the Joomla project which relate to the production of the Joomla! CMS software and it’s documentation. This issue’s Leadership connections contribution from the Production Leadership Team focuses on the status of Joomla! 1.6 as well as some general questions looking a little further into the future.
How is the the PWG organized to manage these different responsibilities? (Looking here for a sense of what different teams exist within the PWG, and who are the leaders of those teams)
- Documentation team (Chris Davenport)
- Bug Squad (Andrew Eddie, Ian MacLennan, Mark Dexter)
- Translation Teams (Jean-Marie Simonet)
- Development Coordination Team (Louis Landry, Sam Moffatt, Andrew Eddie, Mark Dexter, Ian MacLennan)
Do you have an estimate on how many community members are currently involved in the PWG’s activities?
- Translation Teams: 95+ representing 64 languages.
- Bug Squad: 50+
- Documentation: 12+
- Development: 12+
- Other??
Joomla! 1.6 beta 3 was recently released. Are you able to give an estimate on when 1.6 stable will be released?
- Depends on how quickly we can fix the remaining bugs in beta version
- Beta4 is June 28. Beta5 will be July 12. Beta6 or RC1 will be July 26.
- We would hope that will have RC by end of August, if not before
What can the community do to help the PWG get 1.6 stable released sooner? (Please include links or contacts to follow up with)
- Help report and fix bugs in the tracker (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103)
- To join the Bug Squad, email Mark Dexter (
This email address is being protected from spambots. You need JavaScript enabled to view it. ) - Install the beta and contribute to the main help screen documentation. Not only are there revisions to the existing pages based on 1.5, but there are also completely new extensions and features to document.
What was the rationale for the the PWG’s plan to release a new 1.6 beta every two weeks? How is that working out in practice?
- Doesn’t make promises or deadlines that may or may not be possible
- Helps us to keep things moving – we aren’t waiting for some nebulous point of readiness for another beta
- Fits with incremental improvement model we will be adopting into the future
- It is working well in practice.
- We have active participation of large group in Bug Squad.
- Can see significant progress in each 2-week time period.
How is the work on 1.6 documentation progressing?
Total Help Screens: 67
- Reviewed: 3
- Waiting for review: 10
- Started: 40
- Not started: 14
Are there any other areas where the PWG needs more help, either for 1.6 or otherwise? If so how can community members get involved?
- Bug Squad: (testing, tracker work, coding bug fixes)
Contact:This email address is being protected from spambots. You need JavaScript enabled to view it. - Documentation: Writing help screens, tutorials, wiki articles
Contact:This email address is being protected from spambots. You need JavaScript enabled to view it.
At one point the PWG was discussing plans to make regular ongoing time-based 1.6.X releases? Is that still the plan, and if so what is the rationale for that type of release schedule? If not, is there a new plan in place for the scheduling of 1.6.X updates?
Plan is to release 1.7 six months after 1.6 production release. During this time maintenance releases will be made for 1.6 (eg, 1.6.1, 1.6.2) and these will continuously improve that GA version *but* will also be fed back into the 1.7 development tree as well (this is a change for what we did in 1.5 where changes in the stable version where not duplicated in the development tree).
- Rationale is predictable time-based releases
What are some of the major challenges that the PWG plans to focus on more once 1.6 is released?
- How to involve the community in work on 1.7 and beyond
- How to tune the contribution process so that we can determine and marry the needs/wants of the user community with those of the developers (and hopefully we get some overlap which will result in the delivery of new features and improvements).
- How to recruit more developers to help code Joomla!
Once 1.6 is released, can community members give input on 1.7 feature requests? If so how will that happen?
We are working on defining that process right now. Should have an announcement on this soon (next 2-4 weeks?) A possible scenario is that anybody can work on anything they like. However, we are looking at ways of allowing the broader community to introduce ideas and ways of triaging the interest (aka, popularity) in these ideas, but we also have to consider how to involve people in the community to develop the most needed or the most popular ideas as the case may be.
On the other hand, if an individual or small team put the hard yards into developing a solid feature without any other consultation, there should be room in the process to give it appropriate consideration for inclusion in the core, providing it’s in keeping with what “we” want in the core, and working that out is another story as well.
Going to 6 month releases means everyone has to work a bit smarter and bite off things in smaller chunks. The end result is that 1.7 and 1.8 are less dramatic than 1.5 to 1.6 which reduces the overhead of upgrading. With luck, the 1.5 to 1.6 upgrade is the last of the “big” upgrades where people need to go through a process with possibly unpredictable results.