JOOMLA!

DEVELOPMENT
WORKGROUP

Wilco Jansen
[ November 2006 ]

DEVELOPMENT STRATEGY
COPYRIGHT NOTICE
This document is © copyright 2006 by OpenSourceMatters Inc, the authors of this document
and the individual contributors and can be used in accordance with the Creative Commons
License, Attribution - NonCommercial-ShareAlike 2.5

Links
¾ Creative Commons License, Attribution - NonCommercial-ShareAlike 2.5 Æ
http://creativecommons.org/licenses/by-nc-sa/2.5/
¾ OpenSourceMatters Æ http://www.opensourcematters.org/
¾ Joomla! Project Æ http://www.joomla.org
 Joomla!
DEVELOPMENT STRATEGY
November 2006

TABLE of CONTENTS

COPYRIGHT NOTICE 2
TOPICS COVERED AND READING TIPS 4
READING TIPS 4
OVERVIEW OF INFORMATIONAL AREAS 4
CODE OF CONDUCT 6
TEAM MEMBERSHIP 9
POSITIONS, RESPONSIBILITIES AND LEVELS 9
MEMBERSHIP STATUS 10
CONFLICT RESOLUTION 10
RESIGNATION 11
REMOVING MEMBERS 11
DEVELOPMENT -AND CODE BASE LIFECYCLE 13
VERSION STRATEGY 13
CODE BASE LIFE CYCLE 16
DEVELOPMENT CYCLE OVERVIEW 19
ROADMAP 19
GENERAL OVERVIEW OF DEVELOPMENT CYCLE 19
INTER-WORKGROUP RELATIONSHIP 22
INTRODUCTION 22
HOW IT ALL FITS TOGETHER 22
COMMUNICATION AND TOOLS 25
TIME ZONES 25
LANGUAGE AND CULTURAL BARRIERS 26
CLOSING REMARKS 26
TOOLS 26
SPECIAL THANKS FOR CREATION OF THIS GUIDELINE DOCUMENT 27

Joomla! Development Strategy.v.1.0.doc 3

 Joomla!
DEVELOPMENT STRATEGY
November 2006

TOPICS COVERED AND READING TIPS

This document covers all aspects of Joomla! development and contains a lot of information in
several areas of interest. Some of the questions that we will answer include, "How does the
team function as a development group?", "How are decisions made?", "What the overarching
processes are in the life cycle of the software?" etc. etc.

Reading tips
This document holds several references to other more in-depth articles. If you are interested, or
maybe even responsible for a certain area of the project, please take note of this information.
For readers that want to quickly jump ahead to a certain topic we offer a brief directory below
that is designed to accommodate various audience members based upon a "reader’s profile".

• If you are a new Development workgroup member it is advisable to sit back, take some
time and read the whole document. It contains almost everything you need to know
about the way we try to work together.
• If you are an existing Development workgroup member who is seeking information on
a specific topic, please see the topics overview in the table below.
• If you have recently changed roles within the workgroup, we advise you to take a
close look at the team structure section, which explains how we collaborate internally
as well as externally and team member responsibilities.
• If you are a non-Development workgroup member, take a closer look at the Inter-
workgroup relationship section as it contains general information about the way we
interact with other working groups within the Joomla! project. Also the development
and code-base lifecycle sections may be of interest to you.

Overview of informational areas

This document holds quite a lot of information that can be divided into general categories. If
you seek out certain information these categories can guide you to a specific area of interest.
There is an overview of these categories available in the table below.
Category Chapters/paragraphs
Being part of an open-source project Code of conduct
Organisational aspects Team Membership
Positions, responsibilities and levels
Membership status
Conflict resolution
Resignation
Working together other workgroups Inter-workgroup relationships
Team membership
Code of conduct
Development -and codebase lifecycle Development and code base lifecycle
Version strategy
Code base life cycle
Coding philosophy and coding styles

Joomla! Development Strategy.v.1.0.doc 4

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 1

CODE OF CONDUCT

Joomla! Development Strategy.v.1.0.doc 5

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CODE OF CONDUCT
This Code of Conduct1 covers your behaviour as a member of the Joomla! community, in any
forum, mailing list, Wiki, web site, IRC channel, install-fest, public meeting or private
correspondence.

− Be considerate; your work will be used by other people, and you in turn will depend on
the work of others. Any decision you take will affect users and colleagues, and we
expect you to take those consequences into account when making decisions. For
example, when we are in a feature freeze, please don't upload dramatically new
versions of critical system software, as other people will be testing the frozen system
and not be expecting big changes.

− Be respectful; Treat one another, and members of

the community, with respect. Everyone can make a
valuable contribution to Joomla!. We may not
always agree, but disagreement is no excuse for poor
behaviour and poor manners. We might all
experience some frustration now and then, but we
cannot allow that frustration to turn into a personal
attack. It's important to remember that a community
where people feel uncomfortable or threatened is not
a productive one. We expect the members of Joomla!
community to be respectful when dealing with other
contributors as well as with people outside projects and initiative, and with users of
same. Avoid becoming involved in flame wars, trolling, personal attacks, and repetitive
arguments. Take the matters "outside" (off-list, etc) if it helps resolve the situation but
do not use communal methods of communication to be a vehicle for your private "wall
of shame".

1
This Code of conduct has been derived from Ubuntu CoC, used with permission.
Complete text has been taken from COC statement on http://dev.joomla.org.

Joomla! Development Strategy.v.1.0.doc 6

 Joomla!
DEVELOPMENT STRATEGY
November 2006

− Be collaborative; Joomla! is Free Software and about collaboration and working

together. Collaboration reduces redundancy of work done in the Free Software world,
and improves the quality of the software produced. You should aim to collaborate with
other project maintainers, as well as with the upstream community that is interested in
the work you do. Your work should be done transparently and patches from projects
should be given back to the community when they are made, not just when the
distribution releases. If you wish to work on new code for existing upstream projects, at
least keep those projects informed of your ideas and progress. It may not be possible to
get consensus from upstream or even from your colleagues about the correct
implementation of an idea, so don't feel obliged to have that agreement before you
begin, but at least keep the outside world informed of your work, and publish your
work in a way that allows outsiders to test, discuss and contribute to your efforts.

− When you disagree, consult others; Disagreements, both political and technical,
happen all the time and Joomla! is no exception. The important goal is not to avoid
disagreements or differing views but to resolve them constructively. You should turn to
the community and to the community process to seek advice and to resolve
disagreements. There are also several working groups and coordinators, who may be
able to help you figure out which direction will be most acceptable.

− When you are unsure, ask for help; nobody knows everything, and nobody is
expected to be perfect. Asking questions avoids many problems down the road, and so
questions are encouraged. Those who are asked should be responsive and helpful.
However, when asking a question, care must be taken to do so in an appropriate forum.
Off-topic questions, such as requests for help on a development mailing list, detract
from productive discussion.

− Step down considerately; People on every project come and go and Joomla! is no
different. When you leave or disengage from the community, in whole or in part, we
ask that you do so in a way that minimises disruption to the project. This means you
should tell people you are leaving and take the proper steps to ensure that others can
pick up where you leave off.

− Be Available; Check your emails regularly and answer them promptly, even if it's "I'll
get back to you".

− Be Honest; Sometimes the hardest thing to say is "no" or admit you've forgotten do
something. Be honest with each other and yourself with regards to what you say and
what you can realistically commit to.

Joomla! Development Strategy.v.1.0.doc 7

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 2

TEAM MEMBERSHIP

Joomla! Development Strategy.v.1.0.doc 8

 Joomla!
DEVELOPMENT STRATEGY
November 2006

TEAM MEMBERSHIP
Positions, responsibilities and levels
The collaboration within the Joomla! Open-source project is based upon the trust and fun. We
want to put as little hierarchy into this team as possible, and, if we actually do Joomla! (all
together) this section will be superfluous. But for every team that exists of more than one
person, a structure needs to be in place. Let us start with the positions within the development
workgroup:

The Development Workgroup Coordinator has the overall lead on Joomla! development and
has the following responsibilities:
− Will take care of properly planning the progress through the development stages for the
various working groups. Proper planning includes: architectural design, coding stages,
testing stages, release stages etc.
− Will take care of basic communication to all surrounding workgroups. Arrange
structure for testing and documentation, linking development effort to the other roles of
the workgroups.
− Will take care of standards and guidelines that need to be followed within the
development workgroups (not writing them myself, but just arrange that these are
created).
− Will write a roadmap proposal for the Core team, and in later stages propose it to the
community. Process any feedback, but guarding the overall goals of the project.
− Will take care of periodical communication to the community: doing a blog, but also
taking the road to the PR workgroup.
− Will define some workgroup membership guidelines, and try to implement them into
the workgroups. Non active, or non functional workgroup members can be removed,
for this see the "Status" section.
− Will invite new members to the workgroups (can also be done by the lead developers),
and remove them when this is needed.
− Will determine which lead developers are in the team.
− Guards the progression on the pre-defined project goals.

A Lead Developer is a special development position within the development workgroup. There
is no limit on the number of lead developers but the general rule is, 1 lead developer for every
5-10 developers, and in some occasions one lead developer per specific project goal (such as a
main release). A lead developer has the following responsibilities:
− Does architectural design for major and minor releases.
− Does final code review before code gets submitted to the trunk.
− Guards the general integrity of the Joomla! framework in terms of architectural concept
implementation, coding standards and documentation.
− Does mentoring of development workgroup members.
− Does development of the Joomla! framework code.
− Does testing.
− Manages the creation of proper technical documentation of the framework (concepts,
APIs, etc.).

Joomla! Development Strategy.v.1.0.doc 9

 Joomla!
DEVELOPMENT STRATEGY
November 2006

A Developer actually performs programming, testing and documentation tasks. A Developer

can potentially be assigned to a wide variety of tasks but their individual abilities will likely
determine which areas he/she will work on.
− Does development of the Joomla! framework code.
− Does testing.
− Follows coding guidelines.
− Works on technical documentation of all aspects of the Joomla! framework.

Membership Status
Within the development workgroup, we recognize three membership statuses:
− Active; actively contributing on a week-by-week or day-by-day basis (or even more).
− On-leave; temporarily away from duties because of vacations, work commitments or
other valid reasons but still in touch with regular communication channels.
− Inactive; Away from duties and responsibilities for a period of time and not in touch
with regular communication channels.

A development workgroup member is considered active if they are contributing to a

communication channel at least once a week and fulfilling a reasonable time commitment to
the project. To prevent stagnant teams and blocking out new talent from getting into the
development work group some limitations apply to the possible statuses described above:
− A development work group member may be on-leave for up to 3 months. After this
period the workgroup member will automatically be transferred to inactive status.
− A development work group member may be inactive for up to 6 months. After this
period the workgroup member will automatically be removed from the workgroup.
When transferred from on-leave status to inactive, the total period a workgroup member
can be absent is 6 months.

In all cases it is important that the developers informs the workgroup coordinator or lead
developer of his team that he/she is (planning to go) on leave or being inactive.

Conflict Resolution
It would be naive to assume that a group of people can work together in perfect harmony.
There are going to be times when someone feels they have been wronged. In these times the
following procedure should apply:

1. Talk privately to the person concerned.

2. If you still believe grievances exists, then bring in one or two other people to help
mediate.
3. If this fails then take the issue to the workgroup coordinator.
4. If this fails take the issue with the workgroup coordinator to the Joomla! project leader.
5. If this fails take the issue to the whole Core team for final determination.

Team members are encouraged to self-mediate all disputes. In all situations, treat 'wounds'
appropriately. A prick on the finger just needs a tissue for a couple of seconds. Some grazes
and cut just need a Band-Aid to help heal well but will probably heal anyway if left untouched.
More serious lacerations need immediate intervention for survival. If a wound is left to attract
an infection then the obvious threat of gangrene is present.

Joomla! Development Strategy.v.1.0.doc 10

 Joomla!
DEVELOPMENT STRATEGY
November 2006

Resignation
Everyone in Joomla! has their season and there are going to be times when someone needs to
move on for various reasons. You should always feel comfortable to leave or have a holiday
from the project, just inform you workgroup coordinator or better yet, let the whole team know
by posting your absence to the mailing list (joomla-devel@googlegroups.com). If you are
going to be unavailable for a period of time, please be considerate and:
− Give reasonable notice in proportion to your role. Workgroup coordinator and Lead
Developers should give around four weeks notice and other members at least one.
− Make sure that your team knows what they have to take over when you leave. Do not
put the Team in a position where they have to play detective to find out what you did,
where things are, and what their status is, etc.

Removing members
A workgroup member will be removed:
− When he/she violates the Code of Conduct.
− When the workgroup member is inactive for more then 6 months (see the membership
status section above).

Joomla! Development Strategy.v.1.0.doc 11

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 3

DEVELOPMENT -AND CODE BASE LIFECYCLE

Joomla! Development Strategy.v.1.0.doc 12

 Joomla!
DEVELOPMENT STRATEGY
November 2006

DEVELOPMENT -AND CODE BASE LIFECYCLE

Version strategy
Joomla! release versioning follows a numerical convention comprised of three numbers: Major,
Minor and Maintenance. The version is presented in the major.minor[.maintenance] format.

− Major Release Number (X.Y.Z) - An increment of the major number generally

indicates a major rework or rewrite of the code base (framework level). Can be
incompatible with prior major releases.

− Minor Release Number (X.Y.Z) - An increment of the minor number usually indicates
a significant change in functionality. Moderate to high level of backward compatibility
with previous minor increments.

− Maintenance Release Number (X.Y.Z) - An increment of the maintenance number

usually indicates bug fixing within the minor release and possibly small enhancements
and limited new features. Fully backward compatible with previous maintenance
increments.

Adding functionality; roadmap or on the fly?

In general: If you have an idea that you think is great to add to a release, we first want to see
some kind of design, and research done. The result of this is presented at the development
workgroup, so we can agree on the way the solution is created. This is very simple but
important rule to follow, just to prevent discussion afterward.

For roadmap of versions this can appear in different forms:

- Major Release; an architectural design will be done first, then the logical and for parts a
technical design will be worked out before we start development
- Minor Release; depending on the functional changes targeted at an architectural design
can be done, but at least we need a logical description of the change we are targeting at.
- Maintenance release; no functional changed here.

Coding philosophy and coding styles

From its very core, Joomla! is designed and built to help bring people together. It is centered
around simplicity and ease of use. For these reasons we have a certain way of thinking as we
approach Joomla! development. Any time an interface is being designed, or a new process is
being defined for inclusion in Joomla! we strive to think of it as if we were completely foreign
to Joomla! and approach the interaction design as well as interface design from the point of
view of a guide. We want the software to guide the user through his or her processes. We
want the user experience to be intuitive and instructional which ultimately tends to make it
most usable to the broadest group of people. Any time a Joomla! subsystem is visited by a
developer it should be viewed through that lens and evaluated by those standards.

Joomla! Development Strategy.v.1.0.doc 13

 Joomla!
DEVELOPMENT STRATEGY
November 2006

Another driving principle of Joomla! development is maintaining maximum backward

compatibility. Obviously there are times and situations in the development life cycles where
some backwards compatibility must break. Care should be taken to minimize the pain felt by
those who follow the upgrade or migration paths to newer versions. Similarly, changes to our
API should be made with third party developers constantly in mind. There are lots of projects
that live and die based on our API, and for that reason great care should be taken in creating
and changing it.

Joomla! from a developer's perspective is an object-oriented, design pattern based code base.
The Joomla! framework is built as a modular library framework from which to build
applications of any scope or type. It is object oriented in design and can be used completely
independently of the Joomla! Content Management System. The libraries of the framework are
separated into packages and sub-packages which are grouped together logically and
semantically.

Joomla! development can be broken out into two main branches: framework development and
extension development. Framework development is foundational and generally a much more
academic process. Because everything builds on top of our framework we take great care that
anything added to the framework is globally useful and well designed. Extensive use of
proven and documented design patterns is quite common in framework level development.
Also, it is critical that framework libraries be documented well and structured as clean as
possible for code readability. For inline documentation we make use of documentation blocks
per file, class and method. At this time we use phpDocumentor documentation blocks for
automated documentation generation. It is important to document these segments so that third
party developers and really anyone can browse over the code and understand what it is
intended to do. Obviously complex blocks of code within methods should have short notes
describing what they are doing to help code readability. This maximizes productivity and
learning which are two of the driving principles of Joomla! development. The less strict side
of Joomla! development is at the extension level.

Extension level Joomla! development is generally a little more flexible. Documentation is still
key, and we use documentation blocks extensively throughout the code base, but at the
extension level it is acceptable to not be quite as verbose as at the framework level of
development. Core Joomla! extensions are meant to serve as examples of how extensions can
be built for Joomla! They are by no means meant to be exhaustive exercises in the capabilities
of the system nor are they meant to represent the only way to build extensions to the
framework.

One of the important things we have actively tried to address in extension development is to
maintain scope. Components are by their nature not meant to be dependent upon each other for
example. They are dependent upon the Joomla! framework and the application that they live
in. Generally speaking it is not good practice for one component to utilize code from another
component. If there is shared code it should be written abstract enough to be used by anything
and added to a framework package. If not in the core framework packages a custom third party
package would be acceptable. Modules are slightly different. A module can live within
application scope or within component scope. An example of a module living in application
scope would be the "Who's online" module. This module does not rely on any component

Joomla! Development Strategy.v.1.0.doc 14

 Joomla!
DEVELOPMENT STRATEGY
November 2006

code or data and is therefore not within any component's scope. It is dependent upon
application data and is therefore an application dependent module. The "Latest News" module
by contrast is very tightly coupled to the data of the content component. It uses data from the
content component data model and could not function without that particular component being
installed. It is therefore within the content component's scope. As such, the module can and
likely should share code with the content component. These examples should give some
insight into the thought processes to be had when designing extensions. When developing
extensions, the more autonomous the extension code base is, the less likely it is that it will
break as Joomla! is upgraded.

Joomla! Development Strategy.v.1.0.doc 15

 Joomla!
DEVELOPMENT STRATEGY
November 2006

Code base life cycle

This chapter has a strong relationship to the next chapter (development cycle overview) and covers the general approach to the code that
resides in the Subversion repository and is based upon the version strategy described in previous paragraph. We also mention the code
maintenance strategy (or from end-user point of view; the support strategy).

Development target (in Backward

Release type Cycle2 Support Repository
general) compatibility
Major (X.Y.Z) Focuses on major framework 12 Breaks backward Support ends 12-18 Development is done in
adjustments. Is subject to months compatibility with months after the next separate branches, and is
both alpha and beta test previous major version. major release. merged later on with the
periods. trunk.
Minor (X.Y.Z) Focuses on changes on the 4 months Holds 80%-100% Support ends when next Development is done in a
functional part, and minor backward compatibility minor version is declared separate branch holding
framework adjustments (no- with previous minor stable. the new minor release
API changes, only additions version. identification.
are possible).

2
Release cycle is an indication, and depends on the work that needs to be done, and the amount of developers are available!
Joomla! Development Strategy.v.1.0.doc 16
 Joomla!
DEVELOPMENT STRATEGY
November 2006

Development target (in Backward

Release type Cycle2 Support Repository
general) compatibility
Maintenance (X.Y.Z) These releases are initiated Ad-hoc, Holds 100% backward Support ends when next Development is done in a
and controlled by the quality depends compatibility with maintenance release is separate branch holding
and testing workgroup. The on bug- previous minor - and declared stable. minor release number.
frequency of Maintenance fixes or maintenance versions. After quality and testing
Releases will decrease as the security has approved the version,
code base matures. issues. it is merged into the
Maintenance Releases aim to trunk for the active trunk
improve the quality of stable version.
releases that have been
deployed by users and
administrators, yielding a
better return on investment
because you do not have to
wait for the next full release
for a bug to be fixed.

Joomla! Development Strategy.v.1.0.doc 17

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 4

DEVELOPMENT CYCLE OVERVIEW

Joomla! Development Strategy.v.1.0.doc 18

 Joomla!
DEVELOPMENT STRATEGY
November 2006

DEVELOPMENT CYCLE OVERVIEW

In the development cycle we go through certain phases. Within these general phases we have
specific tasks to process and complete. Throughout the different phases of development,
progress may be lead by one or more persons depending on the particular focus at any given
time. A full description of this is given in this chapter.

Roadmap
The roadmap describes the long-term goals of the Joomla! Project. The roadmap is a guide to
the future of the project and can change at any time. The process of drafting a roadmap is
made out of the following steps:
1. The development workgroup coordinator collects the ideas for future development.
Input can come from any source including, the Core team, workgroup members,
community members, forums, etc.
2. The development coordinator processes this input into a roadmap proposal, the first
concept is presented to the Joomla! Core team.
3. Feedback from the Joomla! Core team is used to refine the roadmap proposal.
4. A “final” roadmap is defined and published to the community.

Note this is an iterative process.

General overview of development cycle

For Joomla 1.5 we have adopted a three phase development cycle. The three phases are:

− Alpha Phase; refactoring and Development.

− Beta Phase; Testing, Documenting and

Fine Tuning.

− Stable Phase; Stabilization, Public

Information, etc.

These three phases are also known as the

Opening, Mid-Game and End Game among
project managers. As you can see each phase has
a different main focus, focus in the Alpha phase is
on Development but shifts to Documentation and
Testing for the Beta phase and finally to Public
Information in the Stable phase.

Alpha Phase
The Alpha phase of the development cycle is
when we implement the features outlined in the
roadmap and perform any necessary refactoring.
Community input is minimal and restricted to the Quality and Testing and Standards &
Guidelines Working Group’s input and discussion. The system can break for the new features

Joomla! Development Strategy.v.1.0.doc 19

 Joomla!
DEVELOPMENT STRATEGY
November 2006

we are implementing but care should be taken that other refractory achieves backwards
compatibility rate as defined in the code base life cycle. At this phase anything in the source
tree can and likely will change as we search for the best methods of achieving our development
goals. Most system testing is done by the developers themselves as they come across issues
related to the framework changes.

We have separated the Alpha phase into two distinct development stages and have deemed the
Alpha 2 release the separation point for these two phases of development, in short the Alpha
stage is for framework (Core) refactoring and feature implementation. In this stage, the
Joomla! framework will be redesigned and refactored to provide a cohesive and extendable
API for third party developers. This is also the stage in which new framework features will be
implemented.

Post-Alpha 2 [Also Called Pre-Beta]

This stage is for refactoring core extensions and for making user interface tweaks. With a more
robust and extendable API in place, we should be able to remove redundant code and improve
performance in the core components. For these reasons, the Alpha 2 release is an important
milestone in the development cycle.

By working closely with third party developers and keeping lines of communication open as
we transition from the Alpha to the Beta phase we hope to be able to provide all necessary
information and support to ensure that their extensions are compatible with future versions of
Joomla!

Beta Phase
The Beta phase of development indicates a major milestone in the development cycle. At this
phase we move from pure development towards testing and documentation. From a
development standpoint, focus shifts from implementation to stabilization. At this point
community input is extremely important and we increase our outwards communication towards
third party developers. Together we analyze and solve breakages, improve performance and
finetune the API where necessary.

This stage of the process signifies several things:

− We are now framework feature complete.
− Documentation effort on the API begins.
− Third party backwards compatibility testing on the framework begins.
− Core extension refactoring and user interface changes begins.

Stable Phase (release candidate)

At this phase code base is considered stable and secure and any final bugs are taken care of as
they come to our attention. It is during this phase of the development cycle that the software is
packaged and released. Most attention goes into promotion and public information.

Control over the code base from the release is delegated from the Development workgroup to
the Quality and Testing workgroup.

Joomla! Development Strategy.v.1.0.doc 20

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 6

INTER-WORKGROUP RELATIONSHIP

Joomla! Development Strategy.v.1.0.doc 21

 Joomla!
DEVELOPMENT STRATEGY
November 2006

INTER-WORKGROUP RELATIONSHIP
Introduction
Joomla! is led by a Core Team that is responsible for the overall Project Management. All core
team members working together as a single team, committed to moving Joomla! forward in the
true spirit of the Open Source movement. Core Team members come from different
backgrounds, a diverse array of disciplines, with varied experiences.

The Joomla! Core Team was created after the split-up from the Mambo team in 2005. In the
Mambo days the core team was a collection of programmers who were realizing new versions.
In Joomla!, the Core Team is more than a collection of developers. Although the development
of future versions is still taking up a great percentage of the Core, the Core Team’s primary
responsibility is the organization around Joomla!, not just development of the Joomla! Content
Management System. The Core Team also provides structures to offer documentation, event
organization, legal aide, etc., etc. In this chapter we provide information about the structure and
the way the development workgroup is positioned within the overall Joomla! Structure.

How it all fits together

The Joomla! project has several working groups that have been created to utilise the wealth of
knowledge our community provides. Each of these groups focus on a specific aspect of
Joomla! essential to the project's growth and development. As it is neither possible nor healthy
for the core team to be involved in every discussion and conversation regarding Joomla!
development and growth these workgroups are essential. With a leader or co-leader on the
Core Team we have a built-in method of communication directly with the Core Team.

These working groups provide an essential communication channel between the greater
Joomla! Community and the Core Team to bring concerns to light, advocate change, and
disseminate information. By taking this approach we are improving communication and
interaction between the Core Team, third party developers, the community, and the working
groups. This will help us deliver focused results based on community feedback.

The workgroup structure is made up of small groups involved with the Joomla! Product that
form a supporting structure covering all of the necessary areas like legal aide, marketing and
media, events, development, documentation, etc. We focus on the workgroups that are most
directly involved with the development process:

− Quality and Testing (Q&T); the workgroup that gives the final judgement on the
quality of the coding work. Up to the beta stage the development workgroup is in the
lead, and the quality and testing workgroup does major testing for the framework. After
a release goes release candidate the leading roles are switched, Q&T is then
determining what the Development workgroup is focussing on. This also applies for the
maintenance releases. The Development and Quality and Testing workgroups have a
very tight relationship in developing future versions of Joomla!

Joomla! Development Strategy.v.1.0.doc 22

 Joomla!
DEVELOPMENT STRATEGY
November 2006

− Documentation; also a very important workgroup offering the third party developers
and proper documentation on the framework and Joomla! users documentation on site
administration and maintenance. This workgroup needs to initiate requests to the
Development working group for the information needed to put proper documentation
together.

− Design and Accessibility; this working group will be involved in every stage of
development, guarding accessible and usable interfaces. This working group will be
most actively involved in the alpha stage of development where most important
refactoring will be done.

Joomla! Development Strategy.v.1.0.doc 23

 Joomla!
DEVELOPMENT STRATEGY
November 2006

CHAPTER 7

COMMUNICATION AND TOOLS

Joomla! Development Strategy.v.1.0.doc 24

 Joomla!
DEVELOPMENT STRATEGY
November 2006

COMMUNICATION AND TOOLS

Because most members will be remote it's important to establish a good regiment of
communication. The following is what we find to be a satisfactory mix:

− IRC / Instant messaging; used for informal chats and discussing specific issues in real
time. Details of the IRC server and channels used can be obtained from the
development workgroup coordinator or lead developer(s).
− Forums; used for public interactions and the use of private forums supports the
activities of workgroups. Please subscribe to the forum groups that you are responsible
for, and try to keep up with all that is posted there. Use the private areas for team
discussion.
− Mailing List; used for official discussion of team issues and can be found at the
following URL, http://groups.google.be/group/joomla-devel. Remember, this is a
public mailing list.
− Mail; nothing to explain here ;-)
− Personal talk; public tools like Skype can be used to do a personal talk to a person.
Looking for a nice open-source replacement here.

Of these methods IRC, has proven itself to be one of our strongest and potentially most
damaging methods. On the positive side it is great for team building and establishing
relationships. One the negative it can be ruled by “he who types fastest” and is subject to
hastily typed remarks made in the heat of the moment. In depth group discussions are also
potentially dangerous because you will get the “day” shift deciding to do one thing and by the
time the “night” shift comes on, they can either make different plans or complain that they
weren't consulted.

Use the communication tools in a proper manner, and keep in mind that some of the tools are
public… remember the code of conduct!

Time zones
Having team members in different time zones is one of the most frustrating and challenging
aspects of being involved in a distributed team network. The worse combination is where
certain members are separated by close to 12 hours. It is something you need to get used to
and deal with. It typically requires you to plan to load the mailing list for questions that you
know will be picked up in a few hours time by your team mates in another country.

On the other hand it can be your ally, allowing a project to potentially have support around the
clock. Please take care of yourself; it is very easy to be around hour after hour just to get in
contact to those that are on the other side of the globe.

Joomla! Development Strategy.v.1.0.doc 25

 Joomla!
DEVELOPMENT STRATEGY
November 2006

Language and Cultural Barriers

Projects will come up against differences in language and culture in either the user community
or in the make up of your teams. There is no escaping it.

When you are reading posts on a forum, submissions to a mailing list or even reading personal
mail from another person who is not writing in their native tongue, you need to be sensitive to
the fact that their translated dialog may not mean what they are trying to say. Sometimes you
can unfairly brand a person as arrogant and rude because they have chosen forceful forms of
words and phrases. Keep in mind it is generally not as bad as it sounds.

Closing Remarks
Open Source projects are mostly about freedom and fun. But with interest from government,
non-government and business sectors rising FOSS is becoming a viable and more economical
alternative to the commercial equivalents.

Some projects will be happy to hover in the hobby or cottage industry arena, where you can get
away with ad-hoc or loose planning and organisation. However, to be taken seriously you must
be organised particularly in the areas of development roadmaps, training, and support. If
nothing else this will put you on a level playing field with commercial solutions and allow you
to compete as equals.

This would logically bring you to the question of whether commercialism and Open Source
software can mix. It has been proven they “can” be a symbiotic relationship. In the case of
Joomla!, we see several companies emerging as specialists in either implementation or
customisation. This sends a message of confidence to industries wanting to adopt the Open
Source alternative because they can have a vendor to call if they get into trouble. The presence
of these specialist companies will also serve to protect the longevity and sustainability of the
project through many means. With luck you will be spared from the effects of greed and a lust
for control by any one individual.

Tools
Tools are not targeted at communication, but using a compatible set of tools is more then
advisable. In this section is a short list of some of the tools that are used within the
Development workgroup.

− SourceForge (http://forge.joomla.org/sf/projects/joomla) for all project related

resources like tracker and tasks.
− Subversion (http://subversion.tigris.org/) for adequate source control. When added to
the Joomla! Forge project you will have access to certain areas of the version control
system.
− Eclipse3 (http://www.eclipse.org/) offers a fully equipped IDE for PHP developers.
You could also take a look at phpEclipse (http://www.phpeclipse.de/). Eclipse has also
a Subversion plug-in so you can include version control in the IDE.
− XAMMP or WAMMP both offer a complete web-server platform where you can test
and develop easily.

3
In the (near) future there will be a Joomla! Eclipse IDE, use this when it is available.

Joomla! Development Strategy.v.1.0.doc 26

 Joomla!
DEVELOPMENT STRATEGY
November 2006

Special thanks for creation of this guideline document

This document is processed in the true spirit of open-source. Input has been received from
several persons.

Johan Janssens, core team member and Lead Developer of Joomla! 1.5, for feedback on some
organisational parts, and of course specific areas on the development strategy like development
cycle and commit strategy.

Louis Landry, core team member and development working group member, for syntax
checking, feedback on development cycle and of course the writing of the coding philosophy
and coding styles.

Rob Schley, Quality and Testing workgroup coordinator. Rob gave feedback on the inter
workgroup relations, especially the link that the development has with the Quality and Testing
workgroup. And of course a big “thank you” for removing numerous spelling errors.

Last but not least I want to thank Andrew Eddy, former project leader of Joomla! and now
development working group member. I thank him for sharing his concept documents that
actually announced the start of the creation of this document….

Wilco Jansen
Core team Member and Development Workgroup Coordinator
December 2006

Joomla! Development Strategy.v.1.0.doc 27