Last week the combined Joomla leadership teams (Community Leadership Team (CLT), the Board of Directors of Open Source Matters, Inc. (OSM), and the Production Leadership Team (PLT)), voted to adopt the New Structure & Methodology proposal, by a vote of 19 to 9.

Starting in the fall, the proposal was put through several rounds of leadership, working group and community feedback, and underwent numerous revisions before the proposal was put to a vote.

The structure team that worked on the proposal was formed at JandBeyond 2014 one year ago under the motto of “Make it happen”, and is made up of three representatives from each of the three leadership teams. The team was given a mandate by the Joomla leadership at JAB to do this work, and that mandate was renewed at the joint leadership summit in Cancun in November, 2014. The work of the structure team built on and drew from discussions and research that started at a joint leadership summit in 2011, and from the Governance Working Group research and idea catalogue.

As can be expected in a community as diverse and passionate as Joomla’s, there has been a wide spectrum of reaction to the proposal and resulting vote. Since a two-thirds majority in favor of the proposal was required to carry the motion, the vote was very close and there are some strong dissenting voices.

As with most things, this new structure can be viewed from different angles and with different mindsets. Details might be subject to interpretation, and assumptions are quite often easily made. However, without ignoring those facts, and keeping in mind the lessons learned from them, it is important now to be focused on our future, and have faith in our common goals.

For the first time, this vote gives the Joomla project a unified plan for leadership to involve volunteers, plan, mentor and vote. One legal body to oversee and lead the project, guided by the voices of the teams doing the work. The goal of the proposal is to encourage contributors, bring together fragmented leadership teams and processes, involve more global communities, and to have a voting process where leaders are not appointed by leadership itself. It sets a road map for organized conflict resolution and a code of conduct.

Today we need to come together to continue the implementation of this document. The next step will be to form a transition team to provide the guidance and processes to transition into the new structure. In the coming week the structure team will put several options before the entire leadership for a vote on how this transition team could be formed. Once the transition team is formed, the work of the structure team will be over.

Some areas of the proposal still need more detail. The transition team will oversee the formation of teams to define those areas through a continued process of collaboration and feedback. The structure team strongly recommends that all leadership be actively involved in this process, and that the concerns of the PLT in particular, be addressed throughout.

The public leadership discussion and vote on the structure change is something unprecedented in Joomla history. There is a commitment to increased transparency. The vote was respectfully conducted. As the proposal adoption phase comes to a close, the structure team wishes to thank all of the community members, working group members, and members of leadership who shared their views and offered input on the document as it was being developed.

A new day is dawning for the Joomla project. The CMS scene is very different today from what it was 10 years ago when the project was new. Joomla has made its way, stood its ground, and established itself as one of the top Open Source CMS’s in a challenging environment. It is our sincere hope that this structure change, with the continued work and collaboration of the volunteer community, will form the solid basis to guide the Joomla project through the next 10 years, and beyond.

In the spirit of moving forward, we welcome your feedback in the forum:
https://forum.joomla.org/viewtopic.php?f=704&t=888437 

Today I am happy to report that a balanced 2015 budget has been prepared by myself and dedicated volunteers from all areas of the Joomal project.

A special thanks goes out to Javier Gómez and Olaf Offick — budget liaisons from the PLT and CLT — for their hard work and professional attitude throughout the budget process.

Process

The 2015 budget process is quite similar to prior years and is well documented. In short, the 3-month process has 5 stages:

• Set project-wide goals
• Define objectives to achieve each goal
• Assign expenses and/or revenue to each objective
• Prioritize objectives
• Submit for community feedback and approval by the board of Open Source Matters

Two important changes from the 2014 budget process were included for 2015:

• Line item owners would be specified to have decision making authority for expenditures
• The budget would be balanced

Budget summary

As a result of the budget process, the proposed budget projects revenue of $755,575 with expenses matching dollar-for-dollar (a summary of revenue and expenses associated with the Goals of the project are shown at the end of this document. The full budget organized by our Chart of Accounts is also available).

Based on this balanced budget, we project that our end-of-year assets will total $329,886.

I am pleased to announce the launch of our localisation project for Joomla! documentation. Using an extension designed specifically for translation of pages, our documentation can now be translated. In fact, the translation will be close to the original content of a current documentation page. Once translated, a page will be tracked and when needed, it can be updated easily if the content changes.

For a long time, our international community has desired Joomla! documentation in their native language. One of the major hurdles was deciding how and what tools to use for translating our documentation. This not only included how to translate, but how to track documentation changes while keeping the translated pages up-to-date with the original source pages. You can see an example of a translated page in our sandbox.

Besides tracking the original content of the page, if the original content ever changes, the translation can be updated easily. What is radically different from traditional translations, it will be unnecessary to translate the entire page again. Translators will only have to re-translate the section of a page with changes.

Organised Workflow

As the Documentation Working Group launches this project, please keep in mind we must be organised and use an appropriate workflow. Joomla already translates strings for the language packs available for our CMS's core with a specific workflow. Our translation of documentation will take a similar approach. Our workflow will be mainly set by the extension we are using for translations. Below is a brief summary of our documentation translation workflow.

1. Our current documentation is en-GB. The English version of a page will be the source language. Simply, there must be an English version of a page for translation.

2. A page must be marked (tagged) for translation. The page will automatically be sectioned into smaller translation units called 'message groups' when the page is saved. The message groups are used to track changes but more importantly, they break a page into smaller sections for translation.

3. A marked page must then be approved for translation by a Translation Administrator. The role of a Translation Administrator will be to determine if a page should be translated and verify if the page’s message groups are manageable.

4. Once a page is marked and approved, it can be freely translated into any language. A translator will not have to translate the entire page all at once and may work at their own speed translating a few message groups at a time. The fallback language is always the source language.

5. Any user with translator permission can help translate pages and any translator will be able to review other translator’s translations. For some languages, the translator and translation reviewer may be one and the same.

6. Translations are available for viewing immediately upon a successful translation save completion.

7. If the source content of a page is changed, a Translation Administrator marks the changes so the translators know there have been changes. Step 5 will start again with the exception that only the changes to affected message groups need to be translated again. For example, if a page has been sectioned into 15 message groups and the changes only affect 1 message group, then only 1 message group will need to be re-translated.

For a more indepth look, please read about the Life of a Translatable Page on https://www.mediawiki.org.

Tools for Translators

There are tools built into the extension to assist volunteer translators. One of the most useful ones is machine translation to assist in preparing some text for manual translation. Most translators know machine translations are inaccurate because they lack the finite knowledge of a language, but they can be useful in helping build a text block quickly which can be manually improved by an actual human translator. Translators can choose to use this feature or completely ignore it.

Translators may sign up to be notified about new pages which need translation. These notifications can be by email, a user talk page post or both. Settings include instant notifications to a weekly or monthly digest. Translation Administrators will be able to send out these notices for page translations or re-translations to a page.

Another built-in tool allows for exporting a file of translation units or ‘message groups’ in need of translation. The exported file can be for a single page or multiple pages. Translators can then use a local translation tool such as Poedit. Once translations are complete locally, you can then import the file, review the individual changes and commit the changes. Even a partially translated file of message groups can be imported. Only changes to the message groups being imported will be processed.

There are reports to track translated page statistics, such as percentages of completion, and notifications of a page’s base language change. Actually there is a dual purpose for these percentages. A documentation reader will know a page’s percentage of translation when they view it. The viewer will also know if changes to the source language have occurred and the translation they are reading is not in sync with the source content.

A Call for Volunteers

Even though we are in the early stages of the documentation translation project, there are already volunteers interested in Spanish and Dutch translations. I hope everyone is excited and can’t wait to sign up as a translator for your language. The international community has really desired localisation of documentation, but it will take willing volunteers and the dedication of interested community members to make this project a success.

Here are some key pages to help translators understand translation of our documentation.

• Sign up as a translator

• Page Translation Explained

• Quick Start Guide for Translators

• Language Policy

This is a large project and there will be decisions to make as it progresses. One thing I would like to discuss further, will there be a need to use a channel specifically for translator help and feedback. If so, what should we use? The Documentation Mail List? The #joomla irc channel? I also recently discovered a #joomla-docs irc channel, should we use this instead? Those with an interest should be able to come and go as needed.

Please provide feedback and  comments on https://forum.joomla.org/viewtopic.php?f=704&t=836702.

The Joomla! Extensions Directory Team is please to announce that the Terms of Service has been updated and will take effect February 1, 2014.

Summary of Changes

4.1.d We will be removing Translations and Tools that do not use the Joomla installer (excluding extension specific extensions).

4.1.e We've integrated the JED Submission Checklists.

4.4 We have changed the distribution models from "Commercial" and "Non-Commercial" to "Free" and "Paid".

Changing distribution models in either direction will result in the loss of reviews/votes.

Extensions that require any form of payment, trade or connect to a commercial service that requires a payment to function will need to be listed as "Paid".

8 We're adding a Dispute Resolution process, which will be completed by the end of Q1 2014.

13 Future ToS updates will be announced 30 days prior to implementing changes.

Other We've removed the requirement of using specific text when requesting reviews.

To see how this change applies to you be sure to read the entire Terms of Service. You can comment and ask questions about these changes in this forum thread.