Joomla! Development Strategy.v.1.0

8/7/2019 Joomla! Development Strategy.v.1.0

1/27

JOOMLA! DEVELOPMENT

WORKGROUP

Wilco Jansen

[ November 2006 ]

DEVELOPMENT STRATEGY


2/27

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.5http://creativecommons.org/licenses/by-nc-sa/2.5/

OpenSourceMattershttp://www.opensourcematters.org/ Joomla! Projecthttp://www.joomla.org


3/27

Joomla!


November 2006

Joomla! Development Strategy.v.1.0.doc 3

TABLE of CONTENTS

COPYRIGHT NOTICE 2

TOPICS COVERED AND READING TIPS 4

READING TIPS 4OVERVIEW OF INFORMATIONAL AREAS 4

CODE OF CONDUCT 6

TEAM MEMBERSHIP 9

POSITIONS, RESPONSIBILITIES AND LEVELS 9MEMBERSHIP STATUS 10CONFLICT RESOLUTION 10RESIGNATION 11REMOVING MEMBERS 11

DEVELOPMENT -AND CODE BASE LIFECYCLE 13

VERSION STRATEGY 13CODE BASE LIFE CYCLE 16

DEVELOPMENT CYCLE OVERVIEW 19

ROADMAP 19GENERAL OVERVIEW OF DEVELOPMENT CYCLE 19

INTER-WORKGROUP RELATIONSHIP 22

INTRODUCTION 22HOW IT ALL FITS TOGETHER 22

COMMUNICATION AND TOOLS 25TIME ZONES 25LANGUAGE AND CULTURAL BARRIERS 26CLOSING REMARKS 26TOOLS 26SPECIAL THANKS FOR CREATION OF THIS GUIDELINE DOCUMENT 27


4/27

Joomla!


November 2006


TOPICS COVERED AND READING TIPS

This document covers all aspects of Joomla! development and contains a lot of information inseveral 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 "readers profile".

If you are anew Development workgroup member it is advisable to sit back, take sometime 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 ona specific topic, please see the topics overview in the table below.

If youhave recently changed roles within the workgroup, we advise you to take aclose look at the team structure section, which explains how we collaborate internally

as well as externally and team member responsibilities.

If you are anon-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 developmentand 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


5/27

Joomla!


November 2006


CHAPTER 1

CODE OF CONDUCT


6/27

Joomla!


November 2006


CODE OF CONDUCT

This Code of Conduct1 covers your behaviour as a member of the Joomla! community, in anyforum, 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 onthe 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 ofthe 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 othercontributors 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".

1This 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.


7/27

Joomla!


November 2006


Be collaborative; Joomla! is Free Software and about collaboration and workingtogether. 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 inthe 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 avoiddisagreements 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 isexpected 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 nodifferent. 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'llget back to you".

Be Honest; Sometimes the hardest thing to say is "no" or admit you've forgotten dosomething. Be honest with each other and yourself with regards to what you say and

what you can realistically commit to.


8/27


9/27

Joomla!


November 2006


TEAM MEMBERSHIP

Positions, responsibilities and levelsThe 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:

TheDevelopment 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 thevarious working groups. Proper planning includes: architectural design, coding stages,

testing stages, release stages etc.

Will take care of basic communication to all surrounding workgroups. Arrangestructure 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 thedevelopment 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 thecommunity. Process any feedback, but guarding the overall goals of the project.

Will take care of periodical communication to the community: doing a blog, but alsotaking the road to the PR workgroup.

Will define some workgroup membership guidelines, and try to implement them intothe 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.

ALead 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 amain 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.).


10/27

Joomla!


November 2006


ADeveloper 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 touchwith 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 beon-leave for up to3 months. After thisperiod the workgroup member will automatically be transferred to inactive status.

A development work group member may be inactive for up to 6 months. After thisperiod the workgroup member will automatically be removed from the workgroup.

When transferred from on-leave status to inactive, the total period a workgroup membercan 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.


11/27

Joomla!


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 knowby posting your absence to the mailing list ([email protected]). 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 LeadDevelopers 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 notput 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).


12/27

Joomla!


November 2006


CHAPTER 3

DEVELOPMENT -AND CODE BASE LIFECYCLE


13/27

Joomla!


November 2006


DEVELOPMENT -AND CODE BASE LIFECYCLE

Version strategyJoomla! 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 generallyindicates 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 indicatesa 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 numberusually 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 atechnical design will be worked out before we start development

- Minor Release; depending on the functional changes targeted at an architectural designcan 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.


14/27

Joomla!


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 ourAPI 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 notesdescribing 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 theframework.

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


15/27

Joomla!


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 beinginstalled. 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.


16/27

Joomla!


November 2006

Joomla! Development Strategy.v.1.0.doc

Code base life cycle

This chapter has a strong relationship to the next chapter (development cycle overview) and covers the gene

resides in the Subversion repository and is based upon the version strategy described in previous paragraph. maintenance strategy (or from end-user point of view; the support strategy).

Release typeDevelopment target (in

general)Cycle

2

Backward

compatibilitySupport

Major (X.Y.Z) Focuses on major framework

adjustments. Is subject to

both alpha and beta test

periods.

12

months

Breaks backward

compatibility with

previous major version.

Support ends 12-1

months after the n

major release.

Minor(X.Y.Z) Focuses on changes on the

functional part, and minorframework adjustments (no-

API changes, only additions

are possible).

4 months Holds 80%-100%

backward compatibilitywith previous minor

version.

Support ends when

minor version is destable.

2 Release cycle is an indication, and depends on the work that needs to be done, and the amount of developers are availabl


17/27

Joomla!


November 2006

Joomla! Development Strategy.v.1.0.doc

Release typeDevelopment target (in

general)Cycle

2

Backward

compatibilitySupport

Maintenance(X.Y.Z) These releases are initiated

and controlled by the quality

and testing workgroup. The

frequency of Maintenance

Releases will decrease as the

code base matures.

Maintenance Releases aim to

improve the quality of stable

releases that have been

deployed by users and

administrators, yielding a

better return on investmentbecause you do not have to

wait for the next full release

for a bug to be fixed.

Ad-hoc,

depends

on bug-

fixes or

security

issues.

Holds 100% backward

compatibility with

previous minor - and

maintenance versions.

Support ends when

maintenance relea

declared stable.


18/27

Joomla!


November 2006


CHAPTER 4

DEVELOPMENT CYCLE OVERVIEW


19/27

Joomla!


November 2006


DEVELOPMENT CYCLE OVERVIEW

In the development cycle we go through certain phases. Within these general phases we havespecific 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 firstconcept 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, PublicInformation, etc.

These three phases are also known as the

Opening, Mid-Game and End Game among

project managers. As you can see each phase hasa 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 Groups input and discussion. The system can break for the new features


20/27

Joomla!


November 2006


we are implementing but care should be taken that other refractory achieves backwards

compatibility rate as defined in thecode 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 issuesrelated 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 morerobust 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 frameworkfeature 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.


21/27

Joomla!


November 2006


CHAPTER 6

INTER-WORKGROUP RELATIONSHIP


22/27

Joomla!


November 2006


INTER-WORKGROUP RELATIONSHIP

IntroductionJoomla! 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 Teams 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 thequality 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!


23/27

Joomla!


November 2006


Documentation; also a very important workgroup offering the third party developersand 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 documentationtogether.

Design and Accessibility; this working group will be involved in every stage ofdevelopment, 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.


24/27

Joomla!


November 2006


CHAPTER 7

COMMUNICATION AND TOOLS


25/27

Joomla!


November 2006


COMMUNICATION AND TOOLS

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

IRC / Instant messaging; used for informal chats and discussing specific issues in realtime. 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 theactivities 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 thefollowing URL, http://groups.google.be/group/joomla-devel. Remember, this is apublic 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 youknow 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.


26/27

Joomla!


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 aboutfreedom andfun. 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 OpenSource 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 relatedresources like tracker and tasks.

Subversion (http://subversion.tigris.org/) for adequate source control. When added tothe 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 testand develop easily.

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


27/27

Joomla!


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 thankAndrew 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

Documents

Joomla! Development Strategy.v.1.0