Documente Academic
Documente Profesional
Documente Cultură
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
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.
CHAPTER 1
CODE OF CONDUCT
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.
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.
− 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.
CHAPTER 2
TEAM MEMBERSHIP
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.).
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.
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:
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.
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).
CHAPTER 3
− 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.
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
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.
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
CHAPTER 4
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.
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
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.
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.
Control over the code base from the release is delegated from the Development workgroup to
the Quality and Testing workgroup.
CHAPTER 6
INTER-WORKGROUP RELATIONSHIP
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.
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!
− 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.
CHAPTER 7
− 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.
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.
3
In the (near) future there will be a Joomla! Eclipse IDE, use this when it is available.
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