Suggest What Our 2014 Goals Should Be

[Nick Savov]

Hi all,

The Production Leadership Team (PLT) is starting to work on establishing our goals for the coming year and we would like your suggestions about what our goals for 2014 should be.

We're looking for ideas that are:

• capable of being achieved within the next 1 to 2 years

• capable of being clearly stated

• measurable

Goals do not necessarily need to be code-related. For example, they might be changes to working practices or procedures. However, they should be something that the PLT is normally considered responsible for (although they could be cross-team goals). Also, goals can be related to the CMS and/or the Framework.

By the way, you can view our 2013 goals at http://developer.joomla.org/news/74-production-goals-for-2013.html

Thanks in advance for your feedback!

Kind regards,
Nick

[Matt Thomas]

Thanks Nick!

Best,

Matt Thomas

@betweenbrain
http://matt-thomas.me/

http://betweenbrain.com/

https://github.com/betweenbrain

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.

[Steve]

Joomla 4 released on schedule and as a smooth upgrade from Joomla 3.

Steve

[Allon Moritz]

Bootstrap 3.

On Wed, Nov 27, 2013 at 5:31 PM, Steve <stephe...@gmail.com> wrote:

Joomla 4 released on schedule and as a smooth upgrade from Joomla 3.

Steve

--

[Donald Gilbert]

Ratify the new Development Strategy

Change license of Framework to LGPL

[Michael Babker]

Going off the items from last year's production goals, this is what I think we need to carry forward on:

• Outreach and promotion of Joomla to a technical audience
• The Joomla project needs to continue expanding awareness of its primary code products (CMS and Framework) and expand its presence at conferences worldwide
• Improve processes in Translating the Joomla Software and support the enhancement of the Joomla CMS multilanguage system
• Continue progress on enhancing the core CMS' multilanguage features
• Continue enhancing and improving on how core translations and translation teams are managed and communicated with

Items which should be covered in 2014 as new goals:

• Perform a full review of the current development strategy to ensure it remains aligned with the project and production goals
• Based on our experience this year with in-person code sprints and bug squash events, the leadership teams should set a goal (and budget for) hosting X events worldwide.  Each event should have a defined purpose with measureable results.
• Define a 3-year high level goal list or roadmap for the CMS and Framework.  Where do we envision steering these projects over the next few years?

--

[Mike Carson]

1. Finish UCM
2. Expand and solidify the framework
3. Update/rebuild the media manager
4. Joomla Developer Conference (I am currently looking for a venue for Springtime)
5. Outreach at non-Joomla developer conferences
6. New translation team software

[Robert]

* Improve stability and quality of framework and CMS.

* Encourage people to help and be part of the development (I mean do coding not only speaking)

[Michael Pignataro]

Smooth update also from Joomla 2.5 and 3. This needs to be cost effective to keep the users from abandoning the platform as migrations can become costly.

I will use menu area for this example: When in a menu and you scroll down and then if you want to grab more menus to view from the picker so you can choose 5,10,20,25,50,all and what not. This then you have to scroll back up and is now put on the right. This should also be put at the bottom as well. Have it in both places.

Keep improving the docs.

Improve marketing. There seems to be a confusion on wording and does confuse the users. Install from web and app store is a prime example with the latest release. In Joomla it is install from web and in marketing material like this - http://community.joomla.org/blogs/community/1784-infographic-10-new-features-of-joomla-32.html it confuses people. Language needs to be consistent.

There was word about a more unified area to set up a page instead of going to menus, articles, modules to set up a page it would be all unified. Is this on the list for 2014? or still up the air?

And lastly keep up the awesome work

--

– Michael Pignataro / VP of Operations
—————————————————
'corePHP'
Website Design & Development

62 East Michigan Ave. Suite 202
Battle Creek, MI 49017

Phone: (269) 979-5582, ext 106
Email: mic...@corephp.com
Web: http://www.corephp.com
Support: http://support.corephp.com
—————————————————

[Ryan Boog]

Iaoneo,

I am for B3 in J4. I've even spoke about it at some JDays and JWC. But everyone should keep in mind that B3 has a lot of different classes than B2, in fact, everything gets laid out differently.

I'm all for moving forward with the best version of Bootstrap, just be prepared that some people will be comfortable with Bootstrap 2. Just had a lightbulb light up over my head... potentially you could add the option to choose either B2 or B3.

Hmm...

[kisswebdesign]

Separate style and structure between the CMS and the template, so that templates have full (or at least much more) control of the markup and CSS classes (and hence front end framework used) used without having to create (a) lots of overrides and/or (b) class aliases to cope with bootstrap defaults.

This may only be applicable to a CMS created with the Framework, as changing the current architecture in such a radical way is going to annoy far too many developers and users to be realistic.

e.g.

possibly change component and module outputs from HTML to JSON...

[{

"name" : "component or module name, e.g. blogList",

"title" : "Title of this item",

"display-text" : "a string that can contain HTML so that WYSIWG editors can still be used, this is for things like the article text. could contain CSS classes for things like tabs, accordions, etc.",

"date1" : "date string, could be published date",

"date2" : "a different date, like modified date",

"date3" : "another date, like created date",

"author" : "name, obviously",

"control-element" : 

  { "button" : "button text",

    "type" : "primary",

    "link" : "link to perform whatever action the button is for"

  },

"position" : "template position to show in",

"size" : "rightSidebar",

"class" : "list of other classes that should be added",

},

{ "name" : "next thing to display",

etc...

}]

A measure of this could be "how many core components don't include CSS classes or HTML in their output".

This is by no means an easy thing to do, the schema for the JSON, for example, would need careful development to catch all the possible use cases. But it does free the developer from having to think about the front end - and the designer doesn't have to fight the output to make it look how they want.

This doesn't have to be REST-y or AJAX-y either, the JSON can be passed to the template and rendered server-side.

The templates would need to be a bit cleverer than they are now, but the responsibility of how things look and feel (UI, UX, etc) should be the domain that designers work in.

There could even be a component (using composer) that can parse the JSON in a pre-defined way (e.g. Joomla-Bootstrap3-parser and Joomla-Foundation5-parser and be a dependancy of the template).

Just a thought.

[Amy Stephen]

On Wed, Nov 27, 2013 at 11:16 AM, Mike Carson <mi...@itdwebdesign.com> wrote:

4. Joomla Developer Conference (I am currently looking for a venue for Springtime)

This would be very good, assuming this is a "true" developer conference (which I'm not sure is well defined.) Is there any discussion on the types of topics and activities this might hold? A real developer conference would be very enabling for Joomla. Would love to see this and would very likely attend.

[Ryan Boog]

Hey Nick, thanks for getting this topic going. I have some actionable things to start looking at for getting things ready for the next long term release:

• removing Itemid dependencies, maybe altogether?
• eliminating MooTools dependencies
• having some paid staff (See Rod's keynote from JWC)

Again, I'm newer to a lot of these discussions, and it is my $0.02, so take it for what it's worth.

Have a great day,

[Steven Pignataro]

Here are my thoughts nick:

• Paid staff. Right now we need to have someone at the top overseeing what is going on and how things are progressing. As of to date people come and go. We need to solidify this with more paid developers and I dare say a paid leader or in the corporate world we call them CEO's. Someone that oversees everything and helps keep the momentum going. Someone that all of the teams can report to. I look at it this way - a 2 year stint at Open Source Matters isn't going to keep the momentum going on a volunteer basis. Instead we need to make the terms longer and find a solid leader of the pack. I know this is a non-profit project but we do need full time leadership moving forward (not saying that we don't have solid leadership - we need leadership that isn't going to come and go).
• Improve marketing out reach. Right now we need to have a solid message and solid out reach to our users. It has improved over the years - but we can do more.
• Maybe we need to put some focus on the framework. Most people don't know what the joomla framework can do since it has always been talked about as the CMS.
  
• Documentation - right now it still is tough to access documentation without the help or resource of Google. And at the same time I am finding that the stuff I am looking for is for deprecated versions of Joomla! - it might be best for a documentation clean out.
• CORE translation capability. We need to have a improved way of having translations of the content that we write. I know there are 3rd party tools - but we have to rely on their API's. 
• Cleanup of the UI. Trim down the excessive whitespace.
• Eliminate the need for Itemids or rename it to menu ids since that is what they are in reality.
  
• Module management still is in rambles for sites with tons of menu items. I suggest taking a look at Advanced Module Manager. It works really well on large sites - but in some cases we don't need all of the extra fluff - just that feature to manage the modules. Maybe it might be best to create 100 menus and 100 menus within those and test how they display and work. Really need to think about scaling vs small sites.
• Examples - I hear it a lot from new developers. It is great to have the examples come with Joomla! - but there is a lack of examples of what the framework can do that is shipped with the package. The CLI and garbage clean up are basic examples and i know there is are more indepth examples that can be created for this portion of the project. Just throwing it out there.

Hope that helps.

Kindest regards,

--Steven Pignataro

[Steven Pignataro]

One last thing I forgot:

• Provide link support for anchor tags within articles. Always a pain in the butt doing this for many sites. No clue why people want to do this in the menu - but is a common thing we have found.

Kindest regards,

--Steven Pignataro

[kisswebdesign]

A thought about the release schedules.

Link the releases to the milestones of the previous and next major release.

Doesn't sound very clear, but allow me to explain...

Release number (I am only using numbers to illustrate the principle)

.0 - .5 as current releases

.7 = Migration planning

.8 = Security updates only - recommended migration point.

.9 = End of official support

When a major series reaches a .3 release, the previous major series transitions to a .7 release which in turn triggers the earlier major series to transition to 0.9 (end of support).

When a major series reaches a .5 release it triggers the previous major series to transition to a .8 release.

This ensures that there is always a LTS release available until the release 2 ahead of it reaches a .3 (STS) release.

It also makes clear the schedule for migration from one major series to another. The .7 release is used for migration planning - and may may include the development of migration specific features to enable the move from one LTS release to another. The .8 release would have these migration tools/features in them and would be the recommended point to migrate - because the .8 release is triggered by the .5 release of the next major series.

The .3 release is still the "new sites" recommendation and the STS version, and by tying the releases together it enables the .3 release to move back without having to either rush to catch up (or meet some arbitrary date) or publicise a change to the 'fixed date' end of life currently used.

There can (should) be an "earliest end of life" date - where the LTS will always be until that date, but may support will continue until the new major series is ready for its .3 release.

Hopefully this picture will explain what I have struggled to do in words...

The idea is to keep flexibility in the schedules, while providing peace of mind for users and devs that there will not be any period where there is no LTS version and that the STS version has been 'battle tested' enough and that nothing has been rushed - again to meet some arbitrary date.

This is not easy to manage, and requires project (major release) and programme (all releases) management to make sure it all runs smoothly - ideally each major series has a different project manager (3 people) who and a single programme manager to oversee the whole thing.

Perhaps this is not possible in an open source project, where resources are volunteers, maybe getting in touch with some charities and ask how they manage their projects and volunteers (a chance to learn from any mistakes and successes they have had).

The numbering system I have used should be replaced with some other sort of flag for the position in the life cycle, as strict SEMVER is a much better system.

Hope that makes sense.

Chris.

[Isidro Baquero]

1. Do a huge effort to "rescue" the big 1.5 userbase (http://w3techs.com/technologies/details/cm-joomla/all/all) and let them keep using Joomla without having to become heroes. Maybe things like
1. Improve the available documentation, and make it more visible and accessible (from dev site, and even from joomla.org, like "Still on 1.5? Click here and learn how to upgrade")
   
2. Do some marketing efforts focused on 1.5 site owners, to show them the benefits of migrating and the risks of staying in 1.5
   
3. Work in easier and better free GNU/GPL migration tools, and/or improve existing ones
4. Develop automated template migration tools, or maybe some kind of "legacy mode", that allows people to migrate sites maintaining their current design (which is a big stopper for many small sites).
5. Improve support at http://forum.joomla.org/viewforum.php?f=710 and maybe create a specific team to help people there
   
2. Adopt some ideas from WordPress like
1. When a new version includes security fixes and bugfixes and/or new features, split it in 2 (version[X]-security and version[X+1]-bugfixes/features), so that security upgrades are way less likely to break stuff and therefore make people think Joomla is a reliable platform where you can keep your site safe without getting stuff broken
2. Add the possibility of making security upgrades automatic
   
3. Implement new features as plugins first, letting people try them as optional add-ons before adding them to the core
3. Work with JED and 3rd party extension developers to increase the adoption of the Joomla Platform, MVC and developmet best practices in general. In the end, a Joomla system is as good/fast/safe/reliable as the worst of its extensions.

[G.D. Speer]

At what point would you introduce a new feature freeze.  At what point would to strongly encourage 3PD extensions to be upgraded - promising no more moving targets.
/Duke

--

[Todor Iliev]

Include Joomla Framework in the CMS.
Do all core extension to be based on the Framework.
Minimize using static methods. Replace Factory pattern with Dependence Injection.
Remove dependence from Bootstrap 2. Do it to be able to be used custom UI easily. Let UI to be part of the template, not the core.

[Sonja Russo]

Most important points of interest that i can think:

1. It's time to not rely only on volunteers, Joomla project needs paid professionists to be a solid rock for users and extensions developers.

2. Improve interaction between JED and developers! Times are too long, and developers can't rely on time some volunteers give to JED. More important: before unlisting extensions a developer should be given at least 24 hours to solve the issue. Sometimes for a fixing that requires 1 minute an extension may stay unpublished for 10 days.This is clearly unacceptable.

3. Bootstrap 3 should be the choice. And responsive admin interface should be improved.

[Fedir]

UCM + more flexibility for the content filtering and for the content displaying (the views and the layouts) 

Середа, 27 листопада 2013 р. 22:08:35 UTC+2 користувач Todor Iliev написав:

[Allon Moritz]

Make joomla upgrades more stable (3.1.4 mess).
Reduce the backlog of pull requests. For example I made four PR on the last pizza bug and fun, only one was merged till now. Which is frustrating for participants....

--

[Andrew Eddie]

1. Retire Joomlacode for tracking issues and features on 1 January 2014; swap to new Issue tracker or just use Github; ensure new issue tracker is fully functional by end of Q1 in 2014 (contract some help if need be just to get the thing done).

2. Hire staff. While Joomla is created by many, we need to stop living under the delusion that it is not propped up by a few devoting excessive time with negative impact on those persons families. Several positions are required at a bare minimum:

a) Production manager (aka what David Hurley is doing virtually full time now)

b) Infrastructure manager (someone to relieve Brad Baker and do what Sam Moffatt used to do, making sure all the sites are up to date and volunteers are not blocked by needing IT experience or an IT guy)

c) Executive director (dog's body for OSM)

d) Event and community manager (responsible for the major events during the year, making sure the JUGs have good resources, oversee the general well-being of community interactions)

e) Documentation manager (covering end-user and developer for all software products - it's a full time job people).

If you compare that with the Drupal Association, that wouldn't be a bad start. Note, these staff positions are so Joomla at a high level runs smoothly and that volunteers generally do not have to deal with drudgery. I echo all that Steven has said on the matter.

3. Revise development strategy of the CMS to fall in line with Semver as we have done for the Framework.

4. Continue driving towards the goal of building the CMS in a way to support distribution.

5. Introduce Composer into the CMS so the the DI package can be distributed and updated the way it was intended to.

6. Identity more of the Joomla Framework that can be progressively brought into the CMS and ultimately replace the old code.

7. Do governance by source control. Invent a new repository to house PLT policy, procedure and data (such as past survey results). Allow changes to policy to be proposed by pull request thus empowering the community to effect change, or at least make themselves more easily heard. Collect the short and long term goals in the Issue Tracker of the new repository to assist with tracking how we are going (basically, you'd shove all these suggestions in the issue tracker so none are lost and the community would have a way of indicating their approval, disapproval and priority). Devise bylaws for how and when voting would be required on certain issues (such as for a change in major policy vs updating a minor procedure in a working group).

8. Conduct an architectural planning event each year, possibly coinciding with a dedicated developer conference.

9. Get serious about documentation and uphold it as an equal with the code. Strictly enforce that people must make an effort to document changes or new features added to our software. Find ways of attracting people to put writing core documentation on our property first, and putting their desire for books and search engine ranking of their personal sites in second place (emphasis on "change your priorities" not necessarily stopping what you are doing).

10. Move developer documentation out of docs.joomla.org into developer.docs.joomla.org. 

11. Review all our communication channels to make sure we are using the least possible to do our jobs effectively (do we really need all the mailing lists, would less suffice, for example, merge "cms" and "general").

12. Use Github issue trackers for more organisation and team management (DO NOT use private skype chats for running a working group). Examples:

* https://github.com/joomla/joomla-developer-docs/issues

* https://github.com/joomla-cms/start-here/issues

Add backlog issues for the CMS to the tracker, like a "cookie jar", where if we know something needs to be done, create an issue (guess a time or difficulty factor) and label it so people can see what is on our "to do" list.

13. Retire ideas.joomla.org and move the source data to an appropriate repository (use the new Issue Tracker to help replace it).

14. Develop an annual survey to take to gauge the health of Joomla production and help identify areas of improvement.

15. Develop more formal feedback or survey mechanisms so that we can build report cards on individual releases of any software. For example, fill out <this form> about Joomla CMS 3.2.0. The quality and success of releases can then be analysed over time (and prove things like, no, it wasn't a good idea to merge code that was not good quality just because someone submitted a pull request).

***

I think that will do for now :)

Respectfully submitted.

Regards,

Andrew Eddie

[Jessica Dunbar]

On Wednesday, November 27, 2013 11:22:35 AM UTC-6, Michael Pignataro wrote:

> Improve marketing. There seems to be a confusion on wording and does confuse the users. Install from web and app store is a prime example with the latest release. In Joomla it is install from web and in marketing material like this - http://community.joomla.org/blogs/community/1784-infographic-10-new-features-of-joomla-32.html it confuses people. Language needs to be consistent.
>

There was TM/brand name issue with App Store. It's something that the marketing team is working on for future. I'll try to get the infographics updated and consistant.

Here's the link and some information on the name:

https://docs.google.com/a/community.joomla.org/document/d/1yg3q91sn7zdAbPlL4_osnxUhHaCXqyzDtneMsXMyrsc/edit

[big.wa...@gmail.com]

Hi all

1) Carry on the great work!
2) Reduce the overall code base
3) Document more with examples and best practices
4) Simplify as much as possible even if some functionality is lost
5) Reduce the number of js and css files that end up getting included on pages
6) Make it easier to define custom content types FOF is a step in the right direction but still tough
7) Simplify core out put so its easier to customise Joomla look and feel
9) Keep up with latest dependant resources/libraries e.g. bootstrap / jquery / Jquery ui
10) Better handling for images, support for resizing and cropping would be good

I was impressed with Joomla 3, keep the momentum going.

Thanks to everyone involved in the project!!

[Marijke Stuivenberg]

Op woensdag 27 november 2013 15:59:54 UTC+1 schreef Nick Savov:

Hi,

At the JWC13 Tom Huchison, me and a couple of Spanish Joomla users sat together to explore the possibility to make docs.joomla.org multilingual and get translated documentation. It would help a lot of non-English Joomla beginners to get started with our great CMS system.
Getting docs.joomla.org multilingual is in progress so I think a very good goal for 2014 would be:

Get docs.joomla.org multilingual and have the help screens translated in as many languages possible (ca. 20 by the end of 2014 would be a great goal imo)

Thanks,
Marijke

[Amy Stephen]

On Wed, Nov 27, 2013 at 3:33 PM, Andrew Eddie <mamb...@gmail.com> wrote:

2. Hire staff.

+1

[Michael Babker]

I'm going to throw some questions out with regards to some of the suggestions here.  As you'll see on the goals we published last year, there is a short summary of the issue we're trying to solve and an action plan in many cases.  I'd like to get some ideas on how these items would be approached.

On Wednesday, 27 November 2013 11:16:28 UTC-6, Mike Carson wrote:

4. Joomla Developer Conference (I am currently looking for a venue for Springtime)

What help would you need from the PLT (and community as a whole) to support this?  Also, what is the target audience for an event like this?

On Wednesday, 27 November 2013 11:22:20 UTC-6, Robert wrote:

* Encourage people to help and be part of the development (I mean do coding not only speaking)

What types of outreach would you suggest in supporting this?  Are there processes in the project that need to change, perceptions about the project, or just addressing a general need for volunteers?

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

Separate style and structure between the CMS and the template, so that templates have full (or at least much more) control of the markup and CSS classes (and hence front end framework used) used without having to create (a) lots of overrides and/or (b) class aliases to cope with bootstrap defaults.

How would you approach this in a manner that allows developers to create 3.5 and 4.x extensions without having the same nightmares of the 1.5 -> 1.6 API changes or 2.5 -> 3.x template changes?  How would you handle HTML producing classes like JPagination (which I just remembered there's a pull request to move that output into JLayout files) or the JHtml package?  Would you suggest more use of JLayout files or less?

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

possibly change component and module outputs from HTML to JSON...

Theoretically, this is already possible the way our (legacy) MVC classes are built.  When the template files for a component and module view are loaded, they're in the scope of the calling class, so the data objects that are being retrieved in a component's model are directly accessible within the templates already.  So really, the issue that seems to be being addressed here is how the data is rendered by default in core, or are you thinking more along the lines of an AngularJS mindframe?

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

There could even be a component (using composer) that can parse the JSON in a pre-defined way (e.g. Joomla-Bootstrap3-parser and Joomla-Foundation5-parser and be a dependancy of the template).

The issue tracker is now using Bower to manage media dependencies.  Granted, it isn't PHP built like Composer is, but if we wanted to go that route, I'd suggest borrowing from their logic for a "how to implement this".  Thoughts?

On Wednesday, 27 November 2013 12:08:10 UTC-6, Steven Pignataro wrote:

Improve marketing out reach. Right now we need to have a solid message and solid out reach to our users. It has improved over the years - but we can do more.

Do we just focus on our user base or do we expand beyond Joomla here?  Given our feature set and what we have on the market with the CMS and Framework, I think there are opportunities to expand beyond the traditional "Joomla marketing circles".

On Wednesday, 27 November 2013 12:08:10 UTC-6, Steven Pignataro wrote:

Maybe we need to put some focus on the framework. Most people don't know what the joomla framework can do since it has always been talked about as the CMS. 

You'll be glad to know then that the Framework maintainer team is coordinating with our marketing team now, so this is actively being addressed.

On Wednesday, 27 November 2013 12:08:10 UTC-6, Steven Pignataro wrote:

CORE translation capability. We need to have a improved way of having translations of the content that we write. I know there are 3rd party tools - but we have to rely on their API's.

What types of improvements would you suggest?  Any specific tools that have features that you think should belong to core, whether in the form of an API or a separately available extension package (this ties in with the ongoing discussions about distributions)?

On Wednesday, 27 November 2013 12:08:10 UTC-6, Steven Pignataro wrote: 

Examples - I hear it a lot from new developers. It is great to have the examples come with Joomla! - but there is a lack of examples of what the framework can do that is shipped with the package. The CLI and garbage clean up are basic examples and i know there is are more indepth examples that can be created for this portion of the project. Just throwing it out there.

The code shipped with the CMS is supposed to be functional code that is usable out of the box, so including these examples within the distro probably wouldn't happen.  However, I do agree 100% that we should have more example scripts - plugins documenting all available triggers in the core contexts, CLI scripts triggering component controllers, etc.  We pulled the old example plugins out of the main CMS repo and seeded https://github.com/joomla/joomla-cms-examples with those, perhaps interested developers could spend an hour contributing a sample script or two there (or possibly Andrew's developer docs (http://developer.docs.joomla.org) initiative)?

On Wednesday, 27 November 2013 13:15:59 UTC-6, kisswebdesign wrote:

A thought about the release schedules.

Link the releases to the milestones of the previous and next major release.

Doesn't sound very clear, but allow me to explain...

Release number (I am only using numbers to illustrate the principle)

.0 - .5 as current releases

.7 = Migration planning

.8 = Security updates only - recommended migration point.

.9 = End of official support

Part of the strategy updates being discussed currently involves a change in the release numbering.  So being blunt here, and this is personal opinion, always marking X.Y (where Y is any given value in any example) as a milestone to me goes against development practices.  With our current strategy, we jump from 3.2 to 3.5, for what reason?  A marketing gimmick basically?  To try and make it simple for users to understand the significance of each version?  What happens if we end up doing 7 or 8 minor releases of the 3 series but only 1 or 2 of the 4 series?  I'm not shooting down this suggestion by any means, but this is one of those things that makes my developer personality twitch like a mad man.

On Wednesday, 27 November 2013 15:33:31 UTC-6, Andrew Eddie wrote:

Hire staff.

This has been a common suggestion in this thread.  In reading all the comments, I'm noting several areas in which individuals are making suggestions that apply to the project as a whole versus focusing more on the production goals, which would be the areas the PLT would focus on.  So with that noted, in which areas that the PLT has the primary responsibility for (this includes our Community Development Manager, the maintainer teams for the CMS and Framework, on-going projects like the Issue Tracker, and our documentation) would be the suggestions for paid positions?  This isn't to say that hiring someone to manage the JED or provide support for our infrastructure is necessarily a bad idea, but I would like to try and keep the topic of discussion focused on the production related pieces of the larger puzzle known as Joomla.

[Andrew Eddie]

On 28 November 2013 11:56, Michael Babker <michael...@gmail.com> wrote:
> On Wednesday, 27 November 2013 12:08:10 UTC-6, Steven Pignataro wrote:
>> Examples - I hear it a lot from new developers. It is great to have the
>

> possibly Andrew's developer docs (http://developer.docs.joomla.org)
> initiative)?

Here's and example that I did last night and that I'd like more of:
http://developer.docs.joomla.org/#/en/cms/recipes/adding-custom-form-parameters-with-a-plugin.md

I think the key here, like with documentation, is to have it curated.
Less examples that are right is better in my way of thinking.

>> Hire staff.
>
> This has been a common suggestion in this thread. In reading all the
> comments, I'm noting several areas in which individuals are making
> suggestions that apply to the project as a whole versus focusing more on the
> production goals, which would be the areas the PLT would focus on. So with
> that noted, in which areas that the PLT has the primary responsibility for
> (this includes our Community Development Manager, the maintainer teams for
> the CMS and Framework, on-going projects like the Issue Tracker, and our
> documentation) would be the suggestions for paid positions? This isn't to
> say that hiring someone to manage the JED or provide support for our
> infrastructure is necessarily a bad idea, but I would like to try and keep
> the topic of discussion focused on the production related pieces of the
> larger puzzle known as Joomla.

I realise we can't make a decision for other parts of the organisation
as a whole, so let's start simple. I know we like any amount of
contribution, and we should respect that, but 5 minutes here or there
a CMS or Framework does not make. It does require small groups of
people putting in bulk hours (my rough estimate is casting a vision on
a single topic takes about 20 hours a week of just one individuals
time). I've also seen in my decade of work on this project the
community burn those people out, mainly because of the tension between
their devotion to the project and trying to hold a job. Yes we are
unique in that we don't have an Acquia or an Automattic behind us, but
I think it's also why those other projects are accelerating and we are
possibly in danger of stalling, if we haven't already.

Anyway, enough preamble. There is no denying a full time development
manager would be valuable. We have an unpaid one at the moment working
near full time at a significant cost to his family, mostly taken for
granted. I think we should fully document David Hurley's role and then
put that role out for tender. Either someone who meets the criteria
provides 40 hours a week for free (yeah right), or we have the budget
to hire for that role (either individually or through a hiring agency
or some other company - it doesn't matter to me who pays the bill).
One person is just a drop in the bucket but it's a start.

Now, I know there is a role description floating around, I know the
PLT has had this proposal before them for the better part of a year
because I was trying to push it at the beginning of this year or late
last year (I don't recall exactly anymore) before I had to step down
due to a house move.

The main push backs that I can recall where:

* OSM wanted a plan to consider a budget - the PLT wanted to know if
there was any chance of getting a sizeable budget allocation,
resulting in a chicken-and-egg situation (does the PLT go to a lot of
effort if OSM isn't even going to consider open the cheque book).
* There was divided opinion on how to spend the allocation. Some
thought spreading it thin, spending a few 1000 on many little things
made more sense than hiring a full time position.
* There was concern that if "you" are paid why would I bother contributing.

I suspect that's where we are still at.

Regards,
Andrew Eddie

[Michael Babker]

On Wed, Nov 27, 2013 at 8:33 PM, Andrew Eddie <mamb...@gmail.com> wrote:

I've also seen in my decade of work on this project the community burn those people out, mainly because of the tension between their devotion to the project and trying to hold a job.

I've seen it too often just in my own three years, and I've had to admit to a few too many folks over the last couple of months just how burned out I'm starting to feel with the amount of responsibility I've taken on.  In addition to a full time paying job and all the stuff going on with that right now.  We do, as a community, need to address this because we can't keep using and abusing a small handful of individuals at a time and expect everything runs smooth when those individuals reach burnout or transition their responsibilities.

There is no denying a full time development manager would be valuable. We have an unpaid one at the moment working near full time at a significant cost to his family, mostly taken for granted.

David is probably one of the luckiest guys in Joomla right now having a family that supports him as they have over the last 12 months with everything he does.  That doesn't mean that we should continue to let him do all these things without some sort of recognition or compensation though.

The main push backs that I can recall where:

* OSM wanted a plan to consider a budget - the PLT wanted to know if there was any chance of getting a sizeable budget allocation, resulting in a chicken-and-egg situation (does the PLT go to a lot of effort if OSM isn't even going to consider open the cheque book).

Speaking for myself, it's worth the effort from the PLT to push and nag and fight tooth and nail to gain OSM support if it comes down to it if this is something we, as the PLT and the community at large, truly believe in.

* There was concern that if "you" are paid why would I bother contributing.

The "typical" collaborators and talkers haven't chimed in yet, but if their response is anything like many of the posts here thus far, I think (well, hope) that concern is addressed.

[Martin Carrion]

1) Seamless updates and upgrades, very confusing for clients to understand 1.5, 2.5, 3, 4.

2) Marketing improvements: everyone out there says "I heard WP is easier, better, faster....whatever" than Joomla.

3) Easy for regular people to understand and feel comfortable using Joomla over other CMS.

[Andrew Eddie]

I should also add that paying just one person is no silver bullet. I
would guess a staff of about 10 would be required to take Joomla from
a weary climb of Mount Everest to the thrill of riding a roller
coaster. But you have to start somewhere and having these people to
fill the gaps would allow for better strategising, better vision
casting and free up volunteers to do more interesting tasks, and take
the credit for them.

Regards,
Andrew Eddie

[Luis Méndez Alejo a.ka. gnumax]

- That release dates are met.
- That no versions are released (to meet a date) without assessing either the core.
- Do not change from one version to another in just 2 days due to lack of testing.

Regards
gnumax

[Michael Babker]

On Wed, Nov 27, 2013 at 10:03 PM, Luis Méndez Alejo a.ka. gnumax <gnu...@gmail.com> wrote:

- Do not change from one version to another in just 2 days due to lack of testing.

I'm not quite sure I understand this one.  If you're suggesting we don't issue quick releases to fix either major breakages in the API or fatal errors, I have to disagree here.  The project has a responsibility to distribute stable software that is safe to use for all of its users.  Unfortunately, that does mean there is the chance we do two releases in a very short period for a number of reasons, some of which I've mentioned here.

An issue we as a project have is testing code pre-release.  I get annoyed at times when I see extension developers pushing updates to their extensions because of "Joomla compatibility issues".  Was this a break in the API that should have been reported and fixed before release?  If so, why wasn't it reported?  More testing isn't necessarily the answer here either; quality testing needs to be done by developers before release (using the git master) and issues reported ASAP.  I'd rather spend 10 minutes working through a non-issue than have a critical issue not reported. 

[Amy Stephen]

On Wed, Nov 27, 2013 at 10:10 PM, Michael Babker <michael...@gmail.com> wrote:

On Wed, Nov 27, 2013 at 10:03 PM, Luis Méndez Alejo a.ka. gnumax <gnu...@gmail.com> wrote:

An issue we as a project have is testing code pre-release.  I get annoyed at times when I see extension developers pushing updates to their extensions because of "Joomla compatibility issues".  Was this a break in the API that should have been reported and fixed before release?  If so, why wasn't it reported?  More testing isn't necessarily the answer here either; quality testing needs to be done by developers before release (using the git master) and issues reported ASAP.  I'd rather spend 10 minutes working through a non-issue than have a critical issue not reported. 

If I got to set one goal for next year -- it would be a special flag on JED for developers to set -- "This extension is ready for Upcoming Release X.X" -- and those extensions sort to the top. O

[Andrew Eddie]

On 28 November 2013 15:22, Amy Stephen> If I got to set one goal for

next year -- it would be a special flag on JED
> for developers to set -- "This extension is ready for Upcoming Release X.X"
> -- and those extensions sort to the top. O

Oh that reminds me. We need to put the compatibility check code into 2.5 and 3.

Also backport all events into 2.5 that are compatible. This makes it
easier for extension developers to write extensions for both 2.5 and 3
without version comparison hacks. The overarching pillar here is
keeping extension code between Joomla versions DRY.

I don't think we want to resurrect 1.5, but I do think a goal should
be to research what is preventing more people from upgrading (1.x is
still around 50-60% of the market) so at least we understand the
problem. On that note, we don't have good figures on our install base
so I think another goal could be implementing an opt-out system of
recording metrics on installed sites via the Joomla update check
(recording PHP version, maybe even the extensions installed). We need
better data to be making some of our decisions.

Regards,
Andrew Eddie

[Donald Gilbert]

So, for gathering metrics, I've come to the conclusion that doing it as a standalone plugin would be best and would address any and all community concerns. The other benefit of this approach is that we get the opportunity to say "You can't get mad at us if we stop supporting your setup of you're not sending is your stats." :P

—
Sent from Mailbox for iPhone

[Andrew Eddie]

> So, for gathering metrics, I've come to the conclusion that doing it as a
> standalone plugin would be best and would address any and all community
> concerns. The other benefit of this approach is that we get the opportunity
> to say "You can't get mad at us if we stop supporting your setup of you're
> not sending is your stats." :P

Sounds good, and couple it to a post-install message (and the JEF
should do the same as well).

Regards,
Andrew Eddie

[brian teeman]

On Thursday, 28 November 2013 06:06:10 UTC, Andrew Eddie wrote:

On 28 November 2013 15:22, Amy Stephen> If I got to set one goal for
next year -- it would be a special flag on JED
> for developers to set -- "This extension is ready for Upcoming Release X.X"
> -- and those extensions sort to the top. O

Oh that reminds me. We need to put the compatibility check code into 2.5 and 3.

I've asked several times over the last 6 months about that code as it becomes more and more important and the answer was always no one knows on its status. It really is desperately needed. What can be done to resurrect it if it needs resurrecting or to get it committed. I dont see it on the Feature Tracker or on github but I might have missed it 

(and this probably should be a separate thread) 

[Dmitry Rekun]

+1 for this:

4. Continue driving towards the goal of building the CMS in a way to support distribution.
5. Introduce Composer into the CMS so the the DI package can be distributed and updated the way it was intended to.
6. Identity more of the Joomla Framework that can be progressively brought into the CMS and ultimately replace the old code.

10. Move developer documentation out of docs.joomla.org into developer.docs.joomla.org.

12. Use Github issue trackers for more organisation and team management (DO NOT use private skype chats for running a working group).

Dmitry

среда, 27 ноября 2013 г., 16:59:54 UTC+2 пользователь Nick Savov написал:

[Andrew Eddie]

On 28 November 2013 16:52, brian teeman

> I've asked several times over the last 6 months about that code as it
> becomes more and more important and the answer was always no one knows on
> its status. It really is desperately needed. What can be done to resurrect
> it if it needs resurrecting or to get it committed. I dont see it on the
> Feature Tracker or on github but I might have missed it
>
> (and this probably should be a separate thread)

Michael, in the interim, can we sift out the code-related issues
raised in this thread and apply some labels to at least capture them?
Maybe "Backlog" for now?

Brian raises a good point that one of the disadvantages of having a
"do what you feel like" approach means important things get missed.
Obviously you can go too far in the other direction (ala 1.5 and 1.6
taking forever to finish) but there has to be a middle ground between
what people want to do and what we need to do. I hope that's a
reasonable conclusion to make anyway :)

Regards,
Andrew Eddie

[Bakual]

-> Encourage people to test Joomla

I think we need more testers. Things went into the CMS which could have been spotted before release if enough testers would be available. Also there are a lot of bugfixes and features in the tracker which need testing.

I think part of the reason for this is that it is tedious to do. Imho JoomlaCode needs to go away asap. JIssues should be forced and the PR on GitHub should be the point of truth where the discussion and tests are logged.

Com_patchtester will help here as well and could maybe improved as well. The vargant boxes Matt builds may help as well.

-> Thus improve and simplify the tools needed to test

And of course:

-> Improve automatic testing.

Unit tests come to mind, but also system tests on various enviroments.

[Andrew Eddie]

On 28 November 2013 17:33, Bakual <werbe...@bakual.ch> wrote:
> I think part of the reason for this is that it is tedious to do. Imho
> JoomlaCode needs to go away asap.

Any reason we can't abandon it today? Github releases also supports
files now too ... (just saying).

Regards,
Andrew Eddie

[Bakual]

Google showed me some links related to Pre-Upgrade check:

https://github.com/joomla/joomla-cms/issues/598

https://github.com/joomla/joomla-cms/pull/725

https://github.com/nicksavov/joomla-cms/tree/2.5.x-with-pre-upgrade-check
https://groups.google.com/forum/#!searchin/joomla-dev-cms/pre-upgrade/joomla-dev-cms/eIGjGvSUZ3A/ll9wIWs7X84J

https://groups.google.com/forum/#!topic/joomla-dev-cms/XuO_oP45D0o

http://developer.joomla.org/news/27-feedback-wanted-for-joomla-compatibility-check-feature.html

[Bakual]

I think we have to wait for JIssues to become version 1.0. It's still in beta, but should be fine soon.

Also Michael has a lot to do and we currently still have a buggy 3.2.0 which should be fixed as soon as possible as well. There are a lot of construction sites...

[Anibal]

- Bootstrap 3

- Better Javascript support: Modules, dependencies, any JS framework like BackboneJS, AngularJS, Ember, etc.

Warm Regards,

Anibal

[Allon Moritz]

+1

--

[kisswebdesign]

@Michael Babker 

I'll do my best to answer your questions...

1.

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

Separate style and structure between the CMS and the template, so that templates have full (or at least much more) control of the markup and CSS classes (and hence front end framework used) used without having to create (a) lots of overrides and/or (b) class aliases to cope with bootstrap defaults.

How would you approach this in a manner that allows developers to create 3.5 and 4.x extensions without having the same nightmares of the 1.5 -> 1.6 API changes or 2.5 -> 3.x template changes?  How would you handle HTML producing classes like JPagination (which I just remembered there's a pull request to move that output into JLayout files) or the JHtml package?  Would you suggest more use of JLayout files or less?

Answer

Good question, there is no easy answer. 3.5 and 4.x would be tricky, however JLayout could be used, and the layout file itself would build the JSON or the HTML depending on the Joomla Version.

e.g.

<?php

if($version < 4 ) {

?>
<div id="helloworld">
  <h1>Hello <?php echo $displayData['name']; ?>!</h1>
</div>

<?php

else {

?>

[{

"name":"hello world",

"title" : "Hello <?php echo $displayData['name']; ?>!"

}]

This is probably the best way forward, so MORE use of JLayout - and any extension that currently uses JLayout would only have to add the JSON build into their existing component. Everything else can stay the same.

As far as the HTML producing classes, they would not really be necessary in 4.x - the output to the template is always JSON.

2.

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

possibly change component and module outputs from HTML to JSON...

Theoretically, this is already possible the way our (legacy) MVC classes are built.  When the template files for a component and module view are loaded, they're in the scope of the calling class, so the data objects that are being retrieved in a component's model are directly accessible within the templates already.  So really, the issue that seems to be being addressed here is how the data is rendered by default in core, or are you thinking more along the lines of an AngularJS mindframe?

Answer

I think you have it right - "the issue that seems to be being addressed here is how the data is rendered by default in core"

By only outputting JSON the front end is upto the template - so if they want to take the JSON and build HTML from it, render it server-side and then display to the browser they can. If they want to use a JS framework to render client-side they can.

If rendering client-side then the template is almost an API (or API proxy for Joomla), decoupling Joomla from the client.

client <--> template <--> joomla <--> database

This way the template is the single entry and exit point, allowing the client to be anything - an iOS native app, Android app, HTML5 app, AngularJS, Knockout, Ember, etc. it really doesn't matter what the client is because the client controls the rendering.

3.

On Wednesday, 27 November 2013 11:30:33 UTC-6, kisswebdesign wrote:

There could even be a component (using composer) that can parse the JSON in a pre-defined way (e.g. Joomla-Bootstrap3-parser and Joomla-Foundation5-parser and be a dependancy of the template).

The issue tracker is now using Bower to manage media dependencies.  Granted, it isn't PHP built like Composer is, but if we wanted to go that route, I'd suggest borrowing from their logic for a "how to implement this".  Thoughts?

Answer

Any dependancy / package manger could be used. I suggested composer because that is PHP, and so is Joomla, so any devs would probably have it installed and be familiar with it already.

Of course there are pro's and con's for any manager, but the key is to have all the packages available from them, not split between 2 or 3 different sources.

I like yeoman + grunt + bower for front end stuff, so this could be a nice way to build a template. You get the scaffolding built by Yeoman, a set of default tests, linting and framework support from grunt, with bower providing all the dependancy management.

It would be great to have a template generation workflow like this:

$ npm install -g generator-joomla4template

$ yo joomla4template

$ bower install jQuery

$ bower install joomla4-foundation5-parser

$ bower install foundation

$ grunt test

$ grunt server

$ grunt

and you have a template with all the required components already built for you, with associated base tests configured too.

The template designer can then customise foundation (using sass, compass, whatever) to give the css classes the style they want, add or remove any template positions, and add any template logic they might want (like installing components/modules/plugins as part of the template installation).

Template builders can create their own generators to scaffold out a new template according to their preferences - which can be an in-house (private) generator or a public one.

They can also create their own parsers for any framework (their own or 3rd party) to give them a fast startup when creating new templates.

I hope that answers your questions,

Chris.

[Robert]

Am Donnerstag, 28. November 2013 02:56:08 UTC+1 schrieb Michael Babker:

On Wednesday, 27 November 2013 11:22:20 UTC-6, Robert wrote:

* Encourage people to help and be part of the development (I mean do coding not only speaking)

What types of outreach would you suggest in supporting this?  Are there processes in the project that need to change, perceptions about the project, or just addressing a general need for volunteers?

I think it is important to help people to get involved. E.G. we did a BugSquad session the day after the last German Joomladay, some of the people said that this was very good because we could sit side by side and help people to understand and contribute. There is a direct success people can have this way, they have the feeling that what they have done has an effect and a value. Encourage people will work when you take them serious and value the time they spent. 

On the other side we should start to ignore people they have a say about nearly anything but never contribute or use Joomla at all.

[Pierre Balian]

I'd really like to see a move from Bootstrap 2x to 3. Also, an increased focus on backend usability (for clients not developers) would be great. I've been working in Wordpress lately at work, and this is one of the biggest areas where we get killed - they can set it up where the client goes to one page and that is it. You can combine the administration elements of any extension/plugin in one place. Clients are stupid, and they don't want to learn anything. Joomla is there to make our jobs as developers easier. However we still have to cater to the people that pay us to make them websites. Joomla is "too complicated" is the number one complaint I hear from clients.

As a feature request:

I think a great idea for the extension manager would be a visual representation of the frontend in the backend. Have a dropdown to preview your page based on menuitem. Click on a module to edit its settings instantly. Drag and drop new modules into place. Click a custom html module and edit it live. Or conversly extend this feature to the frontend: Login as an administrator and click on any page element to change its settings.

[Michael Babker]

On Thu, Nov 28, 2013 at 1:24 AM, Andrew Eddie <mamb...@gmail.com> wrote:

Michael, in the interim, can we sift out the code-related issues
raised in this thread and apply some labels to at least capture them?
Maybe "Backlog" for now?

We're recording code related items that aren't necessarily goal type tasks to record them separately (some kind of short term roadmap perhaps).  But, feel free to use GitHub to flag backlog items too.

As for the compat code specifically, if Nick is OK with it, we can get that moved from his personal repo onto the joomla-projects/joomla-cms repo and get that finished soon. 

[Michael Babker]

On Thu, Nov 28, 2013 at 1:37 AM, Andrew Eddie <mamb...@gmail.com> wrote:

Any reason we can't abandon it today? Github releases also supports

files now too ... (just saying).

Personal opinion, short term answer is we break the workflow that everyone has come to be familiar with, and I'm not too sure how some folks would feel about that.

Unless the releases API supports download counts (and their infrastructure could support the 30,000 downloads we average in a typical day), I wouldn't move where the files are actually hosted.

[Michael Babker]

It's definitely helpful to see what type of ideas you have in mind for these issues and how you'd address them, thanks for sharing.

--

[kisswebdesign]

On Thursday, 28 November 2013 16:07:16 UTC, Robert wrote:

On the other side we should start to ignore people they have a say about nearly anything but never contribute or use Joomla at all.

Sounds good in theory, but how do you know who should be ignored and who shouldn't?

PR issued?

PR merged?

Issue raised?

Tested something?

Or something like a points system, where you are ignored if you don't meet some arbitrary point score?

What about those who want to start using Joomla, have good ideas, but have not contributed yet? Ignore them and they will (probably) never will use Joomla, because they were ignored. Loosing out on new perspectives, ideas and fresh blood for the project.

It's a real minefield doing that kind of filtering.

Because Joomla! is open, then any filtering of this kind must be visible to everyone.

I agree, in theory, that with people who are akin to trolls - in that they make a lot of noise but do little else - should have what they have to say put into that perspective.

But actually doing it is another thing entirely, and risks alienating good people - not to mention any adverse PR that could be generated (Joomla 'says' its open, but if you haven't done XYZ they just ignore you! How open is that!!!), if those that get ignored are vocal then they would be more likely to write these type of posts.

Even though the reasoning behind it is sound, and the method is published, and open, and fair, you could spend forever commenting on these type of posts - fixing (or trying to fix) the perceptions of those who read and accept it at face value. Reality is 99% perception!

More trouble than it's worth to try to implement.

[Andrew Eddie]

> Personal opinion, short term answer is we break the workflow that everyone
> has come to be familiar with, and I'm not too sure how some folks would feel
> about that.

I'll start a new thread.

Regards,
Andrew Eddie

[Mathew Lenning]

So my internet went down for a few days, so I'm more than fashionably late to this post, but I had a great thought that might help ease the pain and fear that many users have been experiencing with our upgrade paths. Why not make it a goal to have site backups as a automated feature during upgrades? I know akebee backups is already a good solution, but honestly, if we intend to keep breaking it (which is really part of growth) we should at least make it easy to get back to good.

So add functionality that copies file structure and db tables (full dump) when the update takes place. If the user wants to go back they just click the revert button and every change since the update is removed.

This way when something like the Bcrypt issue comes up, people aren't stuck waiting for a fix.

The logic wouldn't be to difficult to implement since we would basically be creating a zip of the folders and adding the SQL dump to it.

I really would like to hear everyone's thoughts on this.

Thanks

[Janich Rasmussen]

Please, can we discuss specific ideas in other threads and keep this thread on track?

Anyway, a few ideas I feel worth mentioning:

• Complete the "App store".
  
• Complete the certification program.
  
• Complete the "template directory" (to be integrated in the app store?).
  
• Find a way to not break sites on minor upgrades (as the case with 3.2, whether that is to limit the amount of code to come in x days from release, extend the official testing to include real life scenarios, etc)
  

Also - An extremely valuable part of Joomla, is the extensions and surrounding developer community (imho).

We should, of course, continue to encourage their participation, but as a project I feel like we could help these people so much more to help them stay in the community.

So, Why not create a "mentor program" for extensions or individual extension developers to help them start making a business from their code.

[eivanr]

Nick,

Just one suggestion, ensure that Joomla Development Tutorials work as described.

Tutorials that undoubtedly worked at the time they were published, but when used some months later DO NOT, are very likely to discourage those investigating Joomla's potential; the opposite of what you would wish.

To this end the Joomla Organisation could introduce a register of approved tutorials. Each tutorial on the register being checked periodically and malfunctions/things not working as described, rectified.

Tutorials on the register would have a life cycle and a variety of states, e.g. current, pending rectification, etc.

I don't have the skills to do the rectification, but I do have some spare time to review nominated tutorials in a variety of environments.

Regards,

Ivan Rutter   

[Andrew Eddie]

On 1 December 2013 04:16, eivanr <ivan....@btconnect.com> wrote:
> To this end the Joomla Organisation could introduce a register of approved
> tutorials. Each tutorial on the register being checked periodically and
> malfunctions/things not working as described, rectified.

That is the mission of these sites:

http://developer.docs.joomla.org
https://github.com/joomla-joomla-developer-docs

It would be amazing if every developer that uses Joomla could spare me
as little as an hour a month because the only way this sort of thing
gets done is with people power.

Thanks in advance.

Regards,
Andrew Eddie

[Robert Vining]

That second link above from Andrew should be:

https://github.com/joomla/joomla-developer-docs

[Grigor Mihov]

Well,

Here are mine:

- Make the core more extendable (i.e. forms, categories etc.);

- Fix the SEO problems with the CMS (i.e. routing at first place, meta data, titles, duplicated content);