Joomla! Developer Network - Joomla! Developer Network

2012-04-29-20-51-36

team@jseblod.com (Sébastien Lapoux) — Mon, 30 Apr 2012 01:51:36 +0000

::cck::32::/cck::
::meeting::No::/meeting::
::what_did_you_plan::

What did you plan for this past week?

::/what_did_you_plan::
::what_did_you_accomplish::

What did you accomplish this past week?

::/what_did_you_accomplish::
::what_do_you_plan::

What did you plan for this coming week?

::/what_do_you_plan::
::what_are_the_obstacles::

What are the obstacles you face?

::/what_are_the_obstacles::
::what_are_the_risks::

What are the risks?

::/what_are_the_risks::
::weekly_report::

Do you have any issues or concerns about how things are going? Would you like to discuss these with Andrea, Chad or Elin?

::/weekly_report::

2012-04-29-20-42-00

team@jseblod.com (Sébastien Lapoux) — Mon, 30 Apr 2012 01:42:00 +0000

::cck::30::/cck::
::meeting::Yes::/meeting::
::what_did_you_plan::

What did you plan for this past week?

::/what_did_you_plan::
::what_did_you_accomplish::

What did you accomplish this past week?

::/what_did_you_accomplish::
::what_do_you_plan::

What did you plan for this coming week?

::/what_do_you_plan::
::what_are_the_obstacles::

What are the obstacles you face?

::/what_are_the_obstacles::
::what_are_the_risks::

What are the risks?

::/what_are_the_risks::
::weekly_report::

Do you have any issues or concerns about how things are going? Would you like to discuss these with Andrea, Chad or Elin?

::/weekly_report::

test

elin.waring@gmail.com (Elin Waring) — Sun, 29 Apr 2012 20:30:51 +0000

ddddd

2012-04-29-10-57-34

elin.waring@gmail.com (Elin Waring) — Sun, 29 Apr 2012 15:57:34 +0000

::cck::25::/cck::
::meeting::Yes::/meeting::
::what_did_you_plan::What did you plan for this past week? To do::/what_did_you_plan::
::what_did_you_accomplish::What did you accomplish this week? Not much::/what_did_you_accomplish::
::what_do_you_plan::What did you plan for this coming week? a lot::/what_do_you_plan::
::what_are_the_obstacles::What are the obstacles you face? ccc::/what_are_the_obstacles::
::what_are_the_risks::What are the risks? cccc::/what_are_the_risks::
::weekly_report::Do you have any issues or concerns about how things are going? Would you like to discuss these with Andrea, Chad or Elin? No::/weekly_report::

Prasath Nadarajah

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:20:36 +0000

::cck::12::/cck::
::introtext::

Biography

My name is Prasath Nadarajah, a final year undergraduate at the department of computer science & engineering, University of Moratuwa, Sri Lanka. I live in Colombo, capital of Sri Lanka. I am really passionate about open source and actively contribute to opensource in my spare time. Although i am relatively new to Joomla i am an active WordPress core contributor and submitted several patches for that. My areas of interest in computers are web services, data mining and intelligent systems. I am 23 now and i love to play cricket :)

Last year i successfully completed GSoC with WordPress where i worked on "Extending web service for WordPress" . The project is committed to the trunk and will be available form WordPress 3.4. I also completed a 6 month internship at WSO2, once again an open source company where i worked on their cloud platform.

Project

Mediawiki is a free and open source web based wiki software which runs Wikipedia and thousands of other wiki based sites. Mediawiki provides an API to access and modify wiki features, data and meta-data. The existing php clients for mediawiki is either incomplete or stopped development. The goal of this project is to integrate a client for accessing mediawiki API within the Joomla platform. The new JMediawiki package will allows applications based on Joomla Platfrom to access any mediwiki based sites seamlessly including Wikipedia. Although there are many popular extensions in mediawiki which exposes their services the goal of the project is only to cover the default services in mediawiki 1.18.1.

Mentors

Chris Davenport, Emerson Rocha Luiz and Ashwin Date

Blogs

{loadposition prasathblogs}

::/introtext::
::fulltext::::/fulltext::

Lucas De Castro

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:20:25 +0000

::cck::11::/cck::
::introtext::

Biography

I am currently attending to a generalist and multidisciplinary education in France. In addition to my education as computer engineer in Brazil, it gives me a good level of scientific and technical knowledge and also helps me to develop communication skills and teamwork.

Last year I was involved in a Google summer of code project at Eclipse Foundation. Furthermore in recent years I have participated in programming competitions that involve high levels of creativity and quick problem solving capabilities, and these come with good results.

Project

First of all the project started with a proposal and it changed a lot after some discussions and can be change. But the basic idea is is to create a translation suggestion application for making better translations for Joomla! It will help non-English speaking translation teams to get feedback about translation quality from people, who speak the same language. So translation teams can involve more volunteers in translation process.
In order to do that I studyng in this first period the component com_localise to get familiar with joomla programming and with the project.

Mentors

Edvard Ananyan, Herman Peeren, Jean-Marie Simonet, and Marijke Stuivenberg

Blogs

{loadposition lucasblogs}

::/introtext::
::fulltext::::/fulltext::

Kavith Thiranga Lokuhewage

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:19:58 +0000

::cck::10::/cck::
::introtext::

Biography

Address : Wewala, Horana, Western Province, Sri Lanka.

Family : parents and 1 elder sister.

Hobbies : videography, listening to music and reading books

Project

The goal of this project is to come up with a library for Joomla Platform which will facilitate compressing and combining of JavaScript and CSS files before they are sent to the client browsers. So developers can keep their well structured, commented and easy to read files aside and give compressed files which are optimized for speed downloading, to be served to the end users. And even more they will be able to send a single combined JavaScript/CSS file to render the page instead of sending a number of separate files. So developers will be able to reduce the page download time as well as to save their valuable bandwidth. This will benefit users with faster page loads and webmasters with reduced bandwidth usage.

Mentors

Joe LeBlanc and Marius van Rijnsoever

Blogs

{loadposition kavithblogs}

::/introtext::
::fulltext::::/fulltext::

Javier Gómez

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:19:51 +0000

::cck::9::/cck::
::introtext::

Biography

Javier Gomez was born in Barcelona(Spain), he is graduated in Multimedia and is finishing his Computer Sciences studies at Open University of Catalonia. Javier works as a freelance developer for group of non-profit associations in his city.

He has been very involved in the Spanish speaking Joomla! community in the forums, translation and the organization of off-line meetings and events.
He became active in the community in 2007 by organizing the first national Joomla! meeting in Barcelona and has participated in Joomla! events in different countries like: Spain, Ecuador, Cuba, Chile, Guatemala or Costa Rica. He a passionate about the Joomla! community.

In 2010 he became Open Source Matters board member and got reelected in 2012. He is also involved in the Joomla User Groups Team and in the Trademark Team.

Project

The goal of the project is to create an interface to install language packs from a generated list of accredited language packs during Joomla installation and subsequently from the administrator interface.

The Joomla! community has always been very committed to improve the internationalization in all the areas of the project. As a result, there are translations available into more than 60 languages. We must take into account that Joomla! is used around the globe, mainly by people who are non-native English speakers. Being one of them, I have been always concerned about making Joomla accessible for everyone.
Brief, this is the main goal of this Google Summer of Code project: to allow users to install and manage Joomla! entirely in the language they prefer.

Mentors

Jeremy Wilken, Jean-Marie Simonet, Marijke Stuivenberg

Blogs

{loadposition javierblogs}

::/introtext::
::fulltext::::/fulltext::

Florian Voutzinos

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:19:40 +0000

::cck::8::/cck::
::introtext::

Biography

I am a 22 year old French. I've studied engineering in Aeronautics during three years, now student in fundamental Physics at University Toulouse III and I would like to join a school or University of Informatics, next year.

I am a Joomla user for a few years, and two months ago, I started to contribute to the VirtueMart project.

Project

The first goal of the project is to adapt a Workflow Engine as a part of the Joomla libraries (eventually add some new features to it) that any Joomla developer will be able to use in their CMS extensions or Platform applications.

The second goal is to write a full Platform application, involving articles, reviews, ratings and a scoring system, in which a few trusted users will be able to participate to some critical articles submission and editing processes.

Mentors

Daniel Dimitrov and Nicola Galgano

Blogs

{loadposition florianblogs}

::/introtext::
::fulltext::::/fulltext::

Diana Prajescu

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:19:33 +0000

::cck::7::/cck::
::introtext::

Biography

I am a third year Computer Science student at "Politehnica" University of Bucharest. I enjoy coding and I am eager to learn new things.

My first programming language was Pascal, in high school, which I found old, but it was enough to raise my interest towards programming. Curious about web development, I have started learning PHP and later I have chosen this faculty with the main goal of discovering new programming languages and of perfecting my developer skills.

This faculty truly opened my eyes and after the first year I was able to work as a freelancer on different projects, gaining important skills and knowledge.

Overall it seems that I have made a good choice in my professional carrier, I enjoy what I am doing and this makes me a happy developer :-).

Project

The project I will work on this summer is called Social Package and is consisted of several packages, a package for each social network: Facebook, Twitter, Google+ and LinkedIn. The purpose is to provide simplified interaction with these social networks.

The four packages will be structured similar to the JGtihub package and will use each social network’s specific API. Facebook provides access to data through the Graph API, Twitter, Google and LinkedIn through RESTful APIs. This means the operations with social network’s objects can be performed with standard HTTP requests which are facilitated by the JHttp package.

Mentors

Michael Babker and Oleg Nesterov

Blogs

{loadposition dianablogs}

::/introtext::
::fulltext::::/fulltext::

Aaron Schmitz

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 07:19:25 +0000

::cck::6::/cck::
::introtext::

Biography

I'm a student finishing up my next-to-last year at the University of Minnesota as a mechanical engineering bachelors student. My entrepreneurial spirit and love for technology have driven me to the open source community where I can meet new people and learn new skills. In 2011, I participated in Google Code-in -- placing 4th overall and earning a trip to the GooglePlex this summer. When I'm not doing homework, building robots, developing some fancy new software, or honing other technical skills, I'm can probably be found playing the piano, unicycling, or (on occasion) sleeping.

Project

For Google Summer of Code, I will create a Joomla Platform package which provides a structure for implementing Google APIs. This will include both a set of classes which generates embedable code for Javascript APIs and a set of classes which connect to the Google Data APIs through OAuth and similar authentication protocols.

In addition to creating these extensible frameworks, during the coding period of Google Summer of Code I will implement a few highly popular APIs such as Google Analytics, Google Maps, and Google Calendar. Although I haven't yet finalized the list of APIs with my mentors, I'm sure all of them will be useful to a large number of developers.

The benefit of these APIs to developers is clear. Right now, there are between 50 and 100 Google Analytics extensions in the Joomla Extensions Directory. The classes in this package would allow developers to make a quick call to a method to retrieve Google Analytics tracking scripts rather than implementing this code themselves.

Mentors

Elin Waring and Ofer Cohen

Blogs

{loadposition aaronblogs}

::/introtext::
::fulltext::::/fulltext::

Google Summer of Code 2012

andrea.tarr@joomla.org (Andrea Tarr) — Sun, 29 Apr 2012 06:49:17 +0000

::cck::3::/cck::
::introtext::

Our Students

We are very proud to have the following students working on the Google Summer of Code^TM for Joomla this year. Each student page contains a biography and description of their project along with links to their blogs and their project code at github.com.

Aaron Schmitz
API for JGoogle

Diana Prajescu
API for JFacebook

Florian Voutzinos
Workflow Engine and Application

Javier Gómez
Language Installation

Kavith Thiranga Lokuhewage
CSS/JavaScript minification

Lucas De Castro
Language Translation

Prasath Nadarajah
API for JMediawiki

Stefan Neculai
Web Service API for Directory-like Applications

::/introtext::
::fulltext::::/fulltext::

Code Summary

elin.waring@gmail.com (Elin Waring) — Fri, 26 Aug 2011 18:34:55 +0000

Joomla! Platform

Current test coverage report

Pull tests

Most recent commits

Most recent pull reqests

API documentation

Joomla! CMS

Recent commits

Issue tracker

Feature tracker

Security Center

louis.landry@joomla.org (Louis Landry) — Thu, 30 Sep 2010 01:57:31 +0000

The Joomla! Project takes security vulnerabilities very seriously. As a member of oCert we follow some specific procedures when dealing with security issues.

If you find a possible vulnerability, please report it to the Joomla Security Strike Team first. You can contact the team via email at security@joomla.org. Also let us know via email if you find a reported vulnerability (reported elsewhere). Please include where you saw the report.

You can provide patches for any issues that you find when emailing the team. If you want to join the team send an email to security@joomla.org and ask for more details. Due to the sensitive nature of security work the team's membership is restricted, but we welcome anyone who is qualified to contact us about membership.

Joomla! Security Strike Team

In wild land firefighting, the term "Strike Team" is used to describe a collection of similar resources, which used for a specific purpose (http://en.wikipedia.org/wiki/Strike_Team). The JSST is called a strike team because it's a collection of developers and security experts tasked with improving and managing security for Joomla.

Goals

Investigate and respond to reported core vulnerabilities.
Execute code reviews prior to release to identify new vulnerabilities.
Provide public presence regarding security issues.
Help the community understand Joomla security.

Security Announcement Policy

Verified vulnerabilities will only be publicly announced AFTER a release is issued which fixes the vulnerability.
All announcements will contain as much information as possible, but will NOT contain step-by-step instructions for the vulnerability.

Public Responses Policy

Articles are written about Joomla all the time. In many circumstances, these articles (even from reputable sources) contain a significant amount of misinformation.

The JSST will assess and address articles written about security issues.
- If the article contains valid information about a vulnerability not yet fixed, we will ask the publisher to suspend the article until we can fix the issue.
- If the article contains invalid information, we will note what is invalid, and ask the publisher to either fix or remove the article.
The JSST will be available to answer questions/validate any Joomla security-related articles on the publisher's request.

Security Release Policy

Critical and high-level vulnerabilities trigger an immediate release cycle.
Moderate vulnerabilities may trigger a release cycle depending on the specific issue.
Low and very low vulnerabilities (and moderates which do not trigger a release cycle) will be included with the next scheduled maintenance release.
All security releases will be accompanied by one (or more) appropriate security announcements.

Vulnerability Threat Levels

There are two main details that contribute to a vulnerabilities priority or "threat level":

Impact

Critical - "0-day" attacks, and attacks where site control is compromised (allows attacker to take control over site).
High - SQL injection attacks, remote file include attacks, and other attack vectors where site data is compromised.
Moderate - XSS attacks, write ACL violations (editing or creating of content where not allowed).
Low - read ACL violations (reading of content where not allowed).

Severity

Critical - VERY easy to perform. Relies on no outside information (TRUE 0-day attack).
High - Moderately easy to perform. May rely on readily available outside information.
Moderate - Not easy to perform. May rely on sensitive information.
Low - Difficult to perform. Relies on sensitive information or requires special circumstances to perform.

* NOTE: The descriptions are just generic guidelines. Each vulnerability will be assessed for damage potential and will be ranked accordingly.

Supported Versions

All currently developed and supported versions of Joomla will be actively monitored by the JSST.
Currently active versions include:
- Joomla 2.5.x (until December 2013)
- Joomla 1.5.x (until April 2012)
- Joomla 1.7.x (until February 2012)
Support for Joomla version 1.6.x was ended on August 20, 2011.

Improving Joomla!

andrew.eddie@community.joomla.org (Andrew Eddie) — Mon, 21 Jun 2010 09:31:39 +0000

There are many ways to help with the on-going effort to improve Joomla.

Volunteer Your Time

Most of the work for the Joomla! project is done by unpaid volunteers. The major areas where volunteers can get involved are listed below.

Help with the support forums by joining the Sites and Infrastructure Working Group.
Help translate Joomla! into one of the 180+ languages currently supported by joining the Translations Working Group.
Help fix bugs and get new versions released by joining the Joomla! Bug Squad.
Help improve the Joomla! help screens and documentation by joining the Documentation Working Group.
Help with marketing and public relations by joining the Joomla! Communications Team.
Help manage the Joomla! Extensions Directory (JED) by joining the JED Team.

Joomla! Student Outreach Program (JSOP)

JSOP allows allows students to gain real-world software development experience working with world-class mentors on projects of value to the Joomla! community.

This is an all-volunteer program. Students, mentors, and administrators work on a volunteer basis, although there will be cool prizes and achievement certificates for students who successfully complete the program.

See the JSOP page for more information.

Dedicate Staff Time

Organizations can participate in the Joomla! community as sponsors, either by donating money or developer time to the project. See the Sponsorship page for more information.

Donate Money

Donations of money to the project are always appreciated. See the Donations page for more information.

Joomla Bug Squad

andrew.eddie@community.joomla.org (Andrew Eddie) — Mon, 21 Jun 2010 09:38:00 +0000

Landing page for the JBS.

Should be roughly based on http://docs.joomla.org/Bug_Squad

Introduce a summary of what the JBS is. For newbies the next step is to align themselves with one or more teams. In each team page there should be a list of resources (links to tutorials on how to get started, etc).

Include a loadposition module of the articles in the Teams/JBS category you can join.

Include a link to the most basic common information like setting up a Joomla site from SVN, how to apply a patch, etc.

Joomla! Developer Network

louis.landry@joomla.org (Louis Landry) — Sun, 13 Jun 2010 04:15:11 +0000

Welcome to the shiny new Joomla Developer Network site. Just as our software goes through phases from design through alpha and beta releases and eventually going stable, this site is also going through a similar cycle. Currently we consider it to be at the beta stage of its evolution. In other words, we know there are things missing and some stuff might even be broken, but we'd like people to see it now so we can gather feedback and fix any problems you might find. Please let us know what you think on the developer general mailing list. We look forward to hearing your views.

There is always a great deal of activity underway and communicating with other developers in the community is essential. This site is a resource for anyone looking to build or maintain software based on the Joomla platform. There are two main focuses of this site:

Providing information and road maps to all the resources available for developers interesting in extending the Joomla CMS, writing applications for the Joomla Platform or helping to improve the Joomla codebase.
Providing tools that make it easier to monitor the current status of the Joomla code base.

Talk with Joomla! Developers

If you want to talk Joomla code, come join us on the discussion lists. Joomla! developers can also be found on IRC in the #joomla-dev channel on freenode.net.

{loadposition frontpage1}

{loadposition frontpage2}

{loadposition frontpage3}

Getting Started

louis.landry@joomla.org (Louis Landry) — Sun, 13 Jun 2010 04:15:55 +0000

How do you get started with Joomla! development? The answer is organized into three areas below.

{loadmodule resources}

Reporting and Fixing Issues

Anyone is welcome to report issues or bugs in the Joomla! CMS or Joomla! Platform. For the Joomla CMS versions 1.6 and up and Joomla Platform 11.1 and up, report issues on the CMS tracker (for platform issues please use the category "Joomla Libraries"). For the Joomla CMS version 1.5 use the Joomla 1.5 tracker. You will need to register for an account on joomlacode.org to report an issue.

The Joomla! Bug Squad (also known as JBS) is the group responsible for sorting out and fixing Joomla! bugs and issues.

Who can join the Bug Squad?

Anyone who knows how to use Joomla! and is willing to learn how to use our version control software can join the Bug Squad. You do NOT need to be a PHP programmer, although it is a great way to learn and improve your programming skills.

How do I get more information?

See the Bug Squad article and Bug Squad Portal in the Wiki.

How do I join the Bug Squad?

Writing Joomla! Extensions

One of great things about Joomla! is how easy it is to write extensions for. It is designed to be extended, and there is a large and active community of extension developers. For example, the Joomla! Extensions Directory lists over 5,000 extensions available to Joomla! users.

Extensions allow Joomla! to be used for just about anything that you can imagine doing with a website. Extensions are developed by individuals, large companies, and everything in between.

How do I get started writing Joomla! extensions?

There are a number of useful articles in the Wiki to help you get started. Here are a few:

Different extension types:

Overall index to developer articles: http://docs.joomla.org/Developers

Tutorials for different extension types:

Contributing New Features

Anyone can contribute new features to Joomla. The Production Leadership Team (PLT) is responsible for deciding which features are included into each version.

The general steps for submitting code to the Joomla! CMS are as follows:

Sign the Joomla! Contributor Agreement (JCA). This is required so that your code can be included into Joomla! under the GPL license. Click here to sign the agreement on line.
Communicate on the CMS list what you are working on and make sure it is consistent with the goals for the upcoming release.
Post a description of your project in the CMS Feature Tracker with a status of Open.
Request a Subversion branch for your coding and keep the branch up to date with the latest trunk version. You can request a branch by emailing the CMS list. Indicate what your branch is for and whether you would like others to help you with the coding. Someone on the PLT will respond and set up a branch for your work. Working from a branch is not required but is recommended for complex features.
Follow the Joomla! Coding Standards and write unit and system tests to document your code and test that it works correctly.
Keep other developers and the PLT advised of your project status and invite them to review and comment on your work.
When you have work ready for testing, change the feature status on the tracker to Pending. Once it is successfully tested, it will be changed to Ready for Review at which point senior developers will review it. You may also post patches directly to the feature tracker without using a SVN branch.

If your code is accepted, your branch or patch will be merged with the SVN trunk during the alpha period of the next upcoming release.

The general steps for contributing to the Joomla! Platform are as follow.

Read the Platform Developer Manual to learn about using the Platform.
Read the Joomla! Platform Coding Standards to learn about the coding standards for the Platform.
Sign the Joomla! Contributor Agreement (JCA). This is required so that your code can be included into Joomla! under the GPL license. Click here to sign the agreement on line.
Establish an account on github.
If this is a major new feature, you may want to post on the framework mailing list to get feedback from other developers. If this feature will impact the CMS you may also want to post on the CMS mailing list.
Fork the platform.
Develop your feature, making sure to keep up to date with the main platform.
When your feature is ready for review, make a pull request.

Platform improvements may also be submitted via the CMS Feature Tracker. Please use the category Joomla! Libraries for any platform features submitted by that route.

Note that many great features can be contributed to the community by way of extensions and do not need to be included in the core Joomla! distribution. Also, features that start as extensions can be included into the core program at a later time.

How New Features are Added to Joomla

louis.landry@joomla.org (Production Leadership Team) — Thu, 18 Nov 2010 01:59:05 +0000

New ideas come from many places and anyone in the community. We prefer to use the Google Group mailing list for the CMS since it's a great places to brainstorm, but the Joomla People site also works well—or even anywhere Joomla folks congregate.

The Production Leadership Team (otherwise known as the PLT) have set up two ways to help manage all the great ideas coming from the community; the Joomla Idea Pool (based on UserVoice) and the Joomla Feature Tracker.

The Joomla Idea Pool (JIP)

The JIP (located at ideas.joomla.org) is a great way for anyone in the community to make their voice heard and set priorities. Users have up to 10 votes to cast on the various ideas, which will help make clear what future features the community really wants.

It is important to understand that not all of these features will be added to Joomla. This may happen for a number of reasons. For example, there may be a great feature proposed but either nobody volunteers to take it on or the PLT concludes it should be a separate extension from the core CMS or platform.

Our hope is that many or all of the most popular features on the JIP will have a strong chance of attracting energetic development talent to complete them. Once a feature has moved to the implementation stage, it gets added to the Joomla Feature Tracker.

The Joomla Feature Tracker (JFT)

The JFT is the team’s way to track the progress of a feature and allows for better collaboration during development. The status of an item in the tracker is gauged according to the following:

The feature tracker is used when there is clear intent to provide code to implement the feature. Feature requests should be posted at ideas.joomla.org.

Open: All new features start as Open. An open feature could just be an idea. Open features can move to either In Progress if there is code that is available but not ready for testing, Pending if it is ready for tests, or Ready for Review when testing is completed.
Pending: A feature is worked on until the owners are satisfied enough that code is ready for testing. At that point move it to Pending. You may wish to announce this on mailing lists or elsewhere.
Ready for Review: At this point the owner(s) put the feature in the hands of the PLT (or authorized delegates) to review the feature. The feature can be moved to Approved, Closed or be moved back to In Progress.
Closed: If an issue is set to Closed, a reason should be given. For example, it might be that the feature is better suited for a separate extension, it conflicts with another feature, or that the PLT determines it isn’t a good fit.
Approved: This is a holding state for all features. Approved is also a holding area for when merging is closed in the trunk.
Ready to Commit: When the feature is complete, tested, approved and is ready to commit, whether it’s done in a branch or as a patch, it will be added to the trunk during the feature merge phase of the release cycle.
Committed to Github/SVN: This is the final implementation status in the process. The new feature is in the next version of Joomla.

FAQ's

How do I suggest a new feature for Joomla?

One of the key factors in determining future features is how strong the community support is for that idea. The voting system at ideas.joomla.org helps build that support so we recommend you start there.

If you have the skills to develop the feature yourself, you can also go straight to the JFT, add a suggested feature, and immediately begin working on your project. Make sure you check the tracker first to make sure your idea isn’t already there. We encourage people with ideas that are very similar or overlap to join forces and work together.

Where can I discuss ideas for new Joomla features?

Ideas for new features can be discussed anywhere, but the best place to get constructive feedback and increase your chances of getting a feature added to a future release is our CMS development mailing list.

How can I improve my chances or guarantee my new feature will be added?

Unfortunately, there is no way to guarantee that a new feature will be added, but there are a number of things you can do to maximize the chances of your idea being added to Joomla. Here are a few things to keep in mind:

Make sure the idea is consistent with the goals of the project. For example, does it align with the stated vision for the next version? Is it something that has been ranked highly on the JIP? Have others in the community expressed their support for the idea?
Ensure the idea belongs in the core software and not in an extension. There are plenty of fantastic ideas that would make excellent extensions—but the vast majority of them don't need to be in the Joomla core—which is one of Joomla’s greatest strengths.
If others are working on the same or similar feature, consider joining forces with them. We encourage people to collaborate and give regular updates on their progress.
Adhere to all of the requirements for inclusion into the trunk, including the Joomla coding standards, automated system and unit tests, and basic documentation.

What if a feature is being worked on but I prefer to implement it differently?

If an individual or team is working on a feature and you’d like to work on that same feature, we encourage you join forces. If you really want to take a different approach to a feature, you are free to propose and work on it independently. If two or more different implementations of the same feature are completed in branches, the PLT will evaluate each to decide the best way to proceed.

How do I create a branch to work in?

If you want a branch in the Joomla SVN, get in touch with a PLT member on the CMS mailing list to find out details on how to get one set up for you. However now that we've started working with git, you can just fork the CMS repository on github https://github.com/joomla/joomla-cms

What if my branch is not ready in time for the next version?

Being on a time-based release cycle means there must be a strict cut-off date for merging features into the trunk. The PLT will announce this cut-off date in advance, but it will generally be 60-90 days before the anticipated release date. If your feature (in a branch or as a patch) isn’t ready by the deadline, it won’t be included in the upcoming release. This doesn’t mean your efforts will be lost, it just means that any work done will go into the next release cycle process.

Joomla Development Strategy

louis.landry@joomla.org (Louis Landry) — Mon, 21 Jun 2010 09:18:20 +0000

Introduction

From its very core, Joomla is designed and built to help bring people together. It is centered on simplicity and ease of use. For these reasons we have a certain way of thinking as we approach Joomla development.

Objectives

To continue to offer a stable and reliable platform for our current and future user base.
To make innovation available to users and developers on a more timely basis.
To make it easy for developers to contribute code to the project at any time.

There are five major principles to the Joomla development strategy aimed at achieving those objectives: maintain a stable trunk; predictable, incremental software releases; strong backward compatibility support; a sound security policy; and an open development process.

Maintain a Stable Trunk

It is critical to our mission that the trunk must always contain a stable and tested version of the code base that can be made ready for a release within a short time. To ensure that the trunk is always stable write access is only granted to a limited number of disciplined and trusted people.

Trunk represents the current development build, or the most current functioning version of the software. When features or issues are being “worked on” that should happen in a branch or in a separate system altogether until completion. Changes should only be committed to the trunk when they are complete, working, and all automated tests pass. This can be done via a merge back from a branch or via a patch file, depending on the extent of the change.

Requirements for inclusion into trunk.

There are a few requirements that must be met before changes are considered for inclusion into the trunk. These measures help to ensure that the trunk is always in a stable state.

Satisfy the Joomla! Coding Standards.

Coding standards exist to keep code consistent, easily readable, and maintainable. Before any code contributions are included into the trunk they should meet the Joomla Coding Standards which are described in detail in the documentation wiki.

Pass all automated tests.

Automated tests are used to isolate specific parts or features of the software and ensure that they behave correctly. The Joomla project maintains Unit Tests for API classes and methods as well as System Tests for various application functionality. Before code contributions are included into the trunk all the automated tests should pass so that we can be reasonably assured that the trunk remains stable and reliable.

Provide automated tests for all new API classes and methods.

Any new methods or classes added to the Joomla platform API must be accompanied by working Unit Tests to verify their correct behavior. This serves to help guarantee that not only the current code works, but that future changes do not cause an unstable trunk. Where appropriate system tests should be created to verify expected behavior.

Provide basic documentation for all new additions to the code base.

To maintain features and systems added to the code base, as well as to help ensure an ability to uphold our principle of backward compatibility some basic documentation is required for new API classes and methods or new application logic when it is added to the trunk. If you are writing a new class or method, describe what it is supposed to be used for and why it exists and a couple of brief examples of its use. For application features, describe the addition or describe each layout and their intended purpose.

Predictable, Incremental Software Releases

A software release is the distribution of software code, documentation, and support materials. The Joomla project strategy for software releases borrows heavily from the Ubuntu project's time-based release process, which likewise borrowed heavily from the GNOME project.

Version Strategy

The version identifiers for Joomla follow a three level numerical convention where the levels are defined by change significance. Depending upon the significance of the change between a release and the previous release it will be designated as one of those three levels: major, minor, or maintenance.

Major.Minor[.Maintenance]

If the release is designated as major the first number in the version identifier will be incremented and the remaining numbers set to zero such as 1.0.0 or 2.0.0. If the release is a minor release the second number will be incremented and the last one set to zero such as 1.5.0 and 1.6.0. For maintenance releases the last number is incremented as in 1.6.1 and 1.6.2.

Major Release

For a release to be classified as major it will include a high degree of change compared to the previous release. Generally this will involve massive architectural and/or user interface changes. Substantial changes to the underlying data model can also cause a release to be identified as major.

Minor Release

To be categorized as a minor release a high degree of continuity should be present both architecturally as well as in data model between the release and its predecessor while still providing new or improved functionality.

Maintenance Release

A maintenance release will include fixes to bugs, security vulnerabilities, and usability issues only. New functionality is not introduced unless specifically addressing a problem with the previous release that must be handled before the next minor release.

Version Assignment

Once a release is feature complete and on the road to stabilisation, an assessment will take place based on the changes from the previous release to determine its classification as major, minor, or maintenance.

Release Life Cycle

The software release life cycle is composed of distinct phases and milestones that express the software's maturity as it advances from planning to development to release and support. Not every release will go through every possible phase. As an example, most maintenance releases would omit all phases up to the release candidate milestone because the changes from the previous release would be minimal.

Software Milestones

There are four major software milestones in the Joomla Release Life Cycle: alpha, beta, release candidate, and general availability.

Alpha

The alpha milestone signifies that there is new technology in the software that is ready for testing. Software packages marked as alpha are not feature complete and are not suitable for production environments.

Beta

Once a release has reached the beta milestone it is considered feature complete. Like software packages marked alpha, those which are marked as beta are not considered suitable for production environments. They are intended to be tested thoroughly for backward compatibility issues as well as security and stability problems.

Note: New features are generally not introduced after the beta milestone for a given release unless the features correct faulty implementations or missing behavior found in backward compatibility testing.

Release Candidate

When a release is complete and has been thoroughly tested can be declared as having reached the release candidate (RC) milestone. Packages marked as release candidates are considered complete and suitable for production environments. They have potential to be a product, ready for general availability release unless critical problems emerge.

General Availability

The general availability (GA) milestone indicates that the release is very stable and appropriate for mass distribution and use by end users.

Release Phases

There are three distinct phases in the Joomla software life cycle. For the purposes of looking at them, we begin at the point where a a release has just hit the general availability milestone as described above.

Maintenance

For six weeks after a release reaches the general availability milestone, it is still the primary focus of the production working group. During this maintenance phase the Joomla Bug Squad and other teams’ primary responsibility is triaging and fixing any emerging issues with the current stable release. Only stability changes after thorough testing for the new release are accepted for inclusion into the trunk. Maintenance releases may be issued during this phase as necessary. At the end of the maintenance phase the current release will only be updated in the case of found security vulnerabilities until its stated end of life date.

Feature Merge

The transition from the maintenance phase to the feature merge phase marks a shift in the focus of development efforts from the current stable release to the next release. For twelve weeks after the completion of the maintenance phase new features and enhancements can be merged into the trunk from branches and patches. At this time the trunk no longer represents the current stable release but the next release.

During this time the release will reach the alpha milestone and one or more alpha packages may be made available to preview new features or technology that has been merged into the trunk.

Note: Development work in branches can be (and is encouraged to be) ongoing at any time in the development life cycle and is not confined to the feature merge phase. This is just the phase of the life cycle where such changes can be merged into the trunk for the next release.

Release Testing

The beginning of the release testing phase is marked by the reaching of the beta milestone. During this phase, which should last around eight weeks, the production working group teams’ focus shifts to comprehensive testing of the release. New packages are made available every two weeks for testing by end users throughout the release testing phase. Also during this phase online help documentation and translation strings are finalised. It is important that all extension developers test their software during this phase for backward compatibility issues so they can be resolved before the general availability milestone.

The general availability milestone marks the end of the release testing phase. Final packages for the release are built and distributed as long with any announcements and/or press releases. After this phase the cycle restarts with the maintenance phase.

Support Lifetime

Every Joomla software release has a lifetime in which it is supported by the Joomla project. There are two different classifications of release concerning the support lifetime: standard and long term. Regardless of the support lifetime only security updates and fixes for critical breakages will be issued for a release once it has left the maintenance phase of the life cycle.

Standard Support

Most releases are standard releases which are only officially supported for approximately six months which coincides with the release cycle as described above. A standard support release reaches its end of life one month after the general availability milestone of the next major or minor release.

Long Term Support

Every third major or minor release will be classified as a long term support release (LTS). These releases are officially supported until three months after the general availability milestone of the next long term support release. The longer support schedule is aimed at making transitions for users who seek a longer, more stable release cycle where eighteen months before a major software update makes considerably more sense than six months.

End of Life

Once a release has reached the end of its support lifetime (its “end of life” or EOL) it will no longer be maintained by the Joomla project teams for either stability or security issues.

Support Scenario Related to Past, Present and Future Releases

Please note that this is only an example. For the current planned schedule see the Development Status page.

Date	Current Version	Event Description
(before) July 2010	1.5	1.5 GA released with long term support.
January 2011	1.5 or 1.6	1.6 GA released with standard support.
July 2011	1.5 or 1.7	1.7 GA released with standard support
August 2011	1.5 or 1.7	1.6 reaches end of life.
January 2012	1.8 or 1.5	1.8 GA released with long term support.
February 2012	1.8 or 1.5	1.7 reaches end of life.
April 2012	1.8 only	1.5 reaches end of life.

In the above example version 1.5 is available as a long term support release, thus meaning that users can choose to upgrade it with 1.6 when it is available six months later or with 1.8 (the next LTS release) when it is available eighteen months later. A direct upgrade path will be provided for consecutive standard support releases and for consecutive long term support releases. Any other combination will not be officially supported.

Open Development Process

Our development process is designed to be open and accessible for anyone who wishes to participate. We strive to create an environment where people work together to solve problems and bring innovative, fresh ideas to life in the software we produce.

Aligning with a Vision

Every release of Joomla is different and needs to balance sometimes convergent, sometimes divergent needs and wants from a variety of stakeholders. By far the most difficult task is to marry people who want things done with volunteers who want to do it. This is further complicated by people who want to do things that not many people want or need. So how do we solve this indeterminate problem?

Our solution is to plan a theme or a vision for each minor release as a catalyst to align those people with good ideas and those with the ability to implement them. The vision is discussed at a developer summit held before or very soon after a new minor release reaches the GA (General Availability) milestone. This summit looks at ideas from a variety of sources (Joomla Leadership Team, individual contributors, the Joomla Idea Pool to name a few) and attempts to distill an achievable vision for the next release based on the interest and effort available within the community at the time.

Just because a vision is set, does not prevent people from making contributions outside of that vision. The vision, rather, is designed to help guide the general direction of the software for the next release and set a theme for the contributor community to rally around.

Communication

The most critical aspect of collaboration is communication. To that end, there are several different mechanisms to aid in providing an open, collaborative development process such as mailing lists, IRC channels, issue trackers, and forums.

Most often the best work is done in small teams, and we encourage people to create ad-hoc teams to work on features and fixes for Joomla. It is important, however, for these small teams to regularly communicate with the larger development community regarding progress and direction to build support for their work.

Bug Squad

The most important standing team within the Joomla development effort is the bug squad. The Joomla Bug Squad is tasked with managing the release testing and maintenance phases of the development cycle. Because of this the bug squad is largely responsible for quality assurance for the Joomla project. Maintaining a low barrier to entry for new contributors is a key principle of the bug squad, and it is a great place for less experienced contributors to get familiar with the code base.

Idea Pool

A Request for Comments (RFC) with respect to the Joomla development process is a document submitted for peer review which describes functionality, ideas, or other information regarding a change in the Joomla software platform. The Joomla Idea Pool is where developers and users can work together to draft RFC documents and turn ideas into reality.

Good ideas are everywhere.

Innovation starts with a good idea. The idea pool is a tool for people to be able share their ideas for improving Joomla, be them simple or complex. They could involve highly technical changes to the code, or they could describe a way in which a user interfaces with the software, or anything in between.

Collaboration with peers turns good ideas into great ideas.

Good ideas need the right input to produce great ideas, and that input comes from discussing the idea with your peers. It is the responsibility of everyone who favors the idea to help mould it into a complete thought. For an RFC to be seriously considered it must answer at least one of the following two questions:

How can the idea be implemented at a technical level?
How does the idea make the Joomla platform behave at a functional level?

An RFC does not necessarily have to be a fully coded solution, though, working proofs-of-concept are most certainly welcome. One way an RFC can reach maturity is for it to describe how an idea can be implemented, usually in "code" speak. Not everyone is a developer and so another way ideas can reach maturity is to describe how a change will behave such that a team of developers could take a functional specification and build it.

Turning great ideas into reality.

Once an RFC has sufficient specification on the change to be made, whether that is how it is to be coded, or how it is intended to behave, a decision will made by the Joomla Production Leadership Team as to whether it is marked as a priority for inclusion in the current development release. The priority for the change will take into account its popularity and the synergy with the current development vision.

Submitting Code

For the most part, code submitted to the Joomla project will be written against the current trunk at the time of submission. There are two paths by which a code submission can be approved and added to the trunk:

Patches containing tested fixes from the Joomla Bug Squad.
Approved merges from feature branches.

Anyone who signs the Joomla Contributor Agreement (JCA) is free to create a branch, write code, and propose that their code be included in the Joomla core. However, the Production Leadership Team (PLT) makes the final decisions as to which code gets included into the core code base.

Will my code get included into the core?

It is important to understand that there is absolutely no guarantee to anyone that a given enhancement will be included in Joomla. Given this, what can you do to improve the chance that your work will be included into the Joomla code base?

The following three items are required (but not necessarily sufficient) to have your code accepted:

The code meets the Joomla Coding Standards, as discussed above.
It includes appropriate automated tests. If there are framework changes, complete unit tests should be included to test any new or changed functionality. If there are new or changed user interface elements, system tests should be provided to cover the new functionality.
Basic documentation is provided for all new functionality.

In addition, the following characteristics will increase the chance of code being accepted:

The proposed change aligns with the vision for the release or with a feature requested by an RFC. This is not always necessary, but will increase the chance of a feature being accepted. Some improvements could be important but are not part of the vision or have not been suggested by others. In this case, they can still be considered.
The idea for the change was discussed on the mailing list, and there is general support for it from other list members and from the PLT.
Others in the community have not already coded a similar enhancement. If two or more groups work on overlapping functionality, that is fine. In the end, the PLT will decide what to include. It could be one or the other, a combination, or neither. However, in many cases, it would be more productive for people to work together in a branch rather than code a different solutions -- unless you believe the different solution will be much better and you can’t persuade the group to change approaches.
The idea needs to be in core and cannot (or should not) be done as an extension. This is very important to understand. If a feature can be implemented as an extension, then the presumption is that it should be done as an extension. If there are important reasons why it should be in the core code base, then these need to be discussed and agreed upon.
1. If a feature cannot be coded as an extension because the framework fails to provide the correct event or other API call, then it might make sense to add the required framework changes. Then the new functionality could be coded as an extension.
2. Writing a great extension is also a good way to eventually get your code into core. For example, if you have an extension that is superior to the same functionality in core, then that could be a great candidate for inclusion in the core.

How can I avoid duplication of effort?

As discussed above, anyone who signs the JCA can write and propose code for Joomla. There is no topdown management of this process. Given this, how can you minimize the chances for duplication of effort?

The first thing is to be able to know what people are currently working on. We envision using the Wiki to maintain a list of the active branches and who is working on which projects. This will provide a convenient way for a new developer to quickly find out what is underway and perhaps to help out on an existing development project. In addition, the development lists can be used to discuss ongoing projects or new proposals.

Remember that this is a decentralized ad-hoc organization. There are no “official” groups charged with writing the “authorized” version of a particular enhancement. Ultimately, the PLT will decide to the best of it’s ability based on the merits of each proposed code set.

Also, it is not necessarily a bad thing to have two or more groups working on overlapping projects. In most cases, there is more than one approach to a particular problem, and it is often not clear what the tradeoffs are until part or the whole solution is coded. So having two or more approaches to the problem can lead to a better solution in the end.

Example Scenario of Project Best Practices

Here is an example scenario of how you might proceed in a way to maximize the chance of having your code get included. First, do some checking to see if others have discussed the idea already. Is it something that is widely considered a valuable feature? Is it consistent with the vision for the release? Has it been requested in the RC? If the answer to these question is yes, then perhaps propose a specific solution on list and see what people think. If this is promising, set up a branch and invite other interested people to help out. Post an article in the Wiki section so that everyone can see that you are starting to work on this project.

Next, you might code a proof-of-concept in the branch and ask people in the community to try it. At that point, it should be possible for the PLT to give a preliminary indication of how the changes fit into the release and whether it is likely to gain PLT approval. If so, then code the remainder of the changes and any related automated tests and again let the community try it. At this point, the branch would be ready for merging into the next release.

Please note that this is only one scenario. A second scenario would be to code a really great extension that people think should be in core and offer to convert the extension so that it can be included in core. A third scenario -- and a much more risky one -- would be to just code a really great change in a branch and then show people the branch when you are finished.

It should also be stated that most people who contribute code to Joomla or other open-source projects will have some of their proposed code not be included. This is normal and to be expected. It is simply not realistic to expect that 100% of any developer’s code will get included. Most FOSS developers enjoy the process of writing code and what they learn in the process can be used in future work regardless of whether a particular code set gets included or not.

Strong Backward Compatibility Support

Backward compatibility for any software platform is a high priority. Clean, maintainable code is also a high priority for any software platform. Sadly, in practice, these two ideals are often at odds. Providing backward compatibility support makes software more complex and less maintainable. The Joomla project's policy for addressing these conflicting ideals is as follows:

Backward compatibility support is important.

During development, alpha testing, and beta testing of new releases, backward-incompatible changes will be considered issues to be resolved. Every effort will be made to make sure that each release of Joomla is backward compatible with the previous minor release.

Backward compatibility support will be limited.

When a documented API method is removed or changed, the previously documented method will be retained and deprecated. Deprecated methods will have added code to generate deprecation notices when they are used. The deprecation notices will state specifically when the backward-compatibility support for the method will expire. This expiration will be expressed as a release number which could be as early as the next minor release. In this way old API methods will not have to be maintained longer than necessary, but plenty of warning will be given before their removal.

When data changes are involved, we will provide data conversion tools that will be available before the GA release.

It is often very hard to determine if any applications are relying on or extending a subtle feature. Because of this it is difficult to assess whether backward-compatibility support needs to be provided for that feature and judgement calls will be made. In these cases if the judgement is wrong it will need to be caught during testing and reported.

Backward compatibility support is the responsibility of everyone.

It is very important to catch backward compatibility problems during development of new releases. In particular, it is important to test new Joomla releases before they are released in final form. If a backward-compatibility problem is found before the final release, it will be considered an issue and will generally be fixed (by adding backward compatibility support where it is reasonable to do so) if possible before the final release.

After the final release, we may elect not to fix outstanding or new backward-compatibility problems. Consumers of Joomla have a right to backward compatibility, but they also have a responsibility to test Joomla against their applications during the beta release cycle (or sooner) to make sure their applications work.

Read commentary and answers to frequently asked questions about the backward compatibility policy »

Sound Security Policy

The team of developers and security experts tasked with implementing the Joomla Project Security Policy is the Joomla Security Strike Team (JSST). The JSST is tasked with investigating and responding to reported core vulnerabilities, executing core code reviews before software releases, providing a public presence regarding security issues, and helping the public to better understand Joomla security issues.

Security Announcement Policy

Verified vulnerabilities will only be publicly announced after a release is issued which fixes the vulnerability. All announcements will contain as much information as possible, but will not contain step-by-step instructions for the vulnerability. As a member of oCERT, the Joomla project follows the policy. We strive to release a new version of Joomla within 14 days of a vulnerability in a currently maintained version being reported to us.

Public Response Policy

Articles are written about Joomla all the time. In many circumstances, these articles (even from reputable sources) contain a significant amount of misinformation. The JSST will assess and address articles written about security issues. If the article contains valid information about a vulnerability not yet fixed, they will ask the publisher to suspend the article until the issue can be resolved. If the article contains invalid information, the JSST will note what is invalid and ask the publisher to either correct or remove the article.

The JSST will be available to answer questions and/or validate any Joomla security related articles at the publisher’s request.

Security Release Policy

Critical and high-level vulnerabilities trigger an immediate release cycle.
Other vulnerabilities will trigger a release within the 14 day embargo period allowed for by oCERT.
All security releases will be accompanied by one (or more) appropriate security announcements.
A release containing a fix for a critical or high-level security issue will be called a Critical Security Release.
A release containing a fix for a security issue will be called a Security Release.

Vulnerability Threat Levels

There are two main details that contribute to a vulnerability’s priority or "threat level": impact and severity. The following tables provide generic guidelines for how vulnerabilities may be assessed. In practice each vulnerability will be assessed for damage potential and ranked accordingly.

Impact

Level	Description
Critical	“0-day" attacks, and attacks where site control is compromised (allows attacker to take control over site).
High	SQL injection attacks, remote file include attacks, and other attack vectors where site data is compromised.
Moderate	XSS attacks, write ACL violations (editing or creating of content where not allowed).
Low	Read ACL violations (reading of content where not allowed).

Severity

Level	Description
Critical	VERY easy to perform. Relies on no outside information (TRUE 0-day attack).
High	Moderately easy to perform. May rely on readily available outside information.
Moderate	Not easy to perform. May rely on sensitive information.
Low	Difficult to perform. Relies on sensitive information or requires special circumstances to perform.