Let's talk about the future

[Nils Rückmann]

I'm tired of reading things like "that belongs to cms" and sentences like "maybe we should maybe start thinking about letting the CMS and let it run its course, and build UCM into a new, next-gen application" shows that there is a lot more than little divergences.

When the news comes out that Joomla splits to Plattform and CMS i thought it would be a good way to improve the code base and give us the ability to bring the CMS to the next levels. But it seems like im wrong and the Plattform not only goes their own way, but also (sry for ordinary language) does not give any shit about the CMS.

So i'm asking now: What's about the future of Joomla CMS ?

I'm thinking we should find a course (with or without the Plattform) and hold on it, because i'm not the only one who stands beside and can not find an end to shake my head. In fact it's the first time i really have to think about the using of Joomla for customers projects.

To make it clear: I like many changes in the current Plattform. But without the ability to use it in our CMS it's not worth it. It's a really cool thing to use Joomla to build an application, but Joomla (in my opinion) signifies for the CMS. Which brings me to me last consider: If we are moving on like now and seperate the CMS and Plattform completly, we should think about the label Joomla!, because it can't be used for two competing projects.

What do you think ? What's the future ? Is there a future for Joomla CMS ? Let's make decissions and don't go around in a circle... Even if the decission is like "we don't know, we only want wo keep afloat", because this could be an honest answer and the whole community (not only developers) finally has a statement which can be used to make personal decissions.

NR

[Will Daniels]

On 13/04/12 11:22, Nils R�ckmann wrote:
> So i'm asking now: What's about the future of Joomla CMS ?

It's a good question. The project has a fairly unique problem right now in that
it has a Platform which has only one significant Application, the CMS, which is
essentially another platform in itself (for extension builders).

All these things cannot progress in the same ways at the same speed, else there
would not be much point in separating them in the first place.

> I'm thinking we should find a course (with or without the Plattform) and
> hold on it, because i'm not the only one who stands beside and can not find
> an end to shake my head. In fact it's the first time i really have to think
> about the using of Joomla for customers projects.

There seems to be plenty of commitment from the leadership to try to hold
everything together as much as is possible. So until that changes I would
suggest to just wait and see how it all pans out.

The Joomla! project is big enough and the CMS has enough stakeholders that I
don't think anyone need worry too much about it's future. If eventually paths do
need to diverge, users can make a choice at that time which path suits them to
follow.

I don't see that anybody needs to panic and push for a formal separation in
advance. What difference would that make? Why the need to decide _now_ exactly
which codebase, with which name, based on which Platform version, maintained by
which team, you will be using in the future?

Until some feature happens in the Platform that you want, but it isn't coming to
the CMS, it doesn't make any difference to planning. For all the discussion and
debates, I'm not convinced that is ever likely to happen, and I don't see how it
helps that case to formally separate anything up-front.

-Will

[Nils Rückmann]

There seems to be plenty of commitment from the leadership to try to hold
everything together as much as is possible. So until that changes I would
suggest to just wait and see how it all pans out.

That's what criticize. "just wait" can't be the answer the at least the people who cares about must be able to see the progress and know what's going on.

The Joomla! project is big enough and the CMS has enough stakeholders that I
don't think anyone need worry too much about it's future.

I can't agree with that. Joomla had a long way behind to be over the "just for kiddies" or "hobby cms" reputation. And now we have lost reputation again by being not stable (stable for the purpose of "a software i get bet on") with major jumps without migration support. Of course companies will think twice before they use a software which stable future (without get worried about if the software meets the needs and if it's even possible to be up to date every 2 years) isn't clear.

[Andrew Eddie]

On Friday, 13 April 2012 20:22:49 UTC+10, Nils Rückmann wrote:

I'm tired of reading things like "that belongs to cms" and sentences like "maybe we should maybe start thinking about letting the CMS and let it run its course, and build UCM into a new, next-gen application" shows that there is a lot more than little divergences.

I'm very sorry you are tired of hearing it.  I'm actually tired of saying it :)  The fact is architectures like UCM **are** fundamentally divergent.  The paradigm is one of bringing together all extensions that work with content into one, unified system (making most content based extensions redundant).  I also made the comment within the context of a lengthy narrative so it makes it look rather aloof in isolation.

 

When the news comes out that Joomla splits to Plattform and CMS i thought it would be a good way to improve the code base and give us the ability to bring the CMS to the next levels. But it seems like im wrong and the Plattform not only goes their own way, but also (sry for ordinary language) does not give any shit about the CMS.

Given that you quoted me, I kind only assume you are including me in that comment.  I'll restate a reply I gave to someone else.  You are confusing the difference between people not wanting to work specifically on the CMS anymore (I gave 8 and a half years to it thank you very much and I'd like to play with some new toys now), with people that, allegedly, just want to make code and don't care about the downstream ramifications.  If the latter is true, I would consider that a fairly serious inditement on the Platform maintainers (subject to the authority of the PLT) and it's contributors.

Having said that, the comment that the Platform has a vision for going it's own way is very true, in a way, and I doubt many people appreciated the nuance from the outset.  The Platform is very intentional about wanting to support applications other than the CMS.  The simplest of these is that command line application.  It makes a lot of sense for a consultant that knows about how to write components, to be able to write a CLI when required for a project using the same code he/she uses for components.  However, those that have tried to do that with Joomla 1.5 know all too well how excruciatingly painful it was to bootstrap with barbed wide and sticky tape.  

The second type of application is a more basic implementation of a web site without all of the overhead that the CMS needs or forces you into supporting (that baby takes a non-trivial amount of CPU cycles just to fire up).  Thus JAppcliationWeb was born.  The next step after that is the ability to build dedicated web services platforms which are just out of the question to conceive using an off-the-shelf 2.5.

But even with that divergent vision, there is a clear attitude to making sure the Platform still work for the Joomla CMS as a major downstream user.  All of the maintainers have done their time supporting the CMS for many, many years.  Trust me, it would be far less hassle to be doing the platform as a true fork if the contributors didn't still have an innate loyalty to the Joomla brand.  We've already seen this in the community and, to me, it doesn't work as well as having a symbiotic relationship.

 

So i'm asking now: What's about the future of Joomla CMS ?

I'm thinking we should find a course (with or without the Plattform) and hold on it, because i'm not the only one who stands beside and can not find an end to shake my head. In fact it's the first time i really have to think about the using of Joomla for customers projects.

I would put to you that the Platform, over time, will over you different choices for those customers.  You will have a choice and in some cases, that will win you the job.

 

To make it clear: I like many changes in the current Plattform. But without the ability to use it in our CMS it's not worth it.

I understand what you are saying, but some parts of the Platform are going to be designed in such a way that it will be difficult for the CMS to implement without causing havoc within the established extension developer community (for a whole host of reasons).  The problem there is what happens when the Platform comes up with a truly stunning solution to a particular problem, but that requires a fairly big change for extension developers.  The choice is not easy and it was in that kind of context I suggested that UCM maybe wasn't the best fit for the current CMS as it stands today (in architectural terms).

 

It's a really cool thing to use Joomla to build an application, but Joomla (in my opinion) signifies for the CMS. Which brings me to me last consider: If we are moving on like now and seperate the CMS and Plattform completly, we should think about the label Joomla!, because it can't be used for two competing projects.

I respectfully disagree.  I think the past 10 months include some of the greatest success seen in the project for both the Platform and the CMS.

 

What do you think ? What's the future ? Is there a future for Joomla CMS ? Let's make decissions and don't go around in a circle... Even if the decission is like "we don't know, we only want wo keep afloat", because this could be an honest answer and the whole community (not only developers) finally has a statement which can be used to make personal decissions.

My take is that the CMS will only go "so far" (i.e., you can't write a server to an iOS or Android games with the CMS, you can try, but I wouldn't), even with the very successful improvements to the development release cycle (which everyone will recall, had it's detractors).  I was a consultant for over 6 years and in that time I tried very hard to do everything I was asked in the CMS, but it was very, very hard to do that all the time.  The Platform, on the other hand, has the ability to provide architectures that are tuned to different types of solutions that are needed for today's and tomorrow's web, not least of which is the need for web services platforms (which, I've got to say, is one of the coolest things to be working on at the moment).  This is great for the Joomla industry in general because it provides the ability for Joomla shops to compete in territory that is traditionally lost to other more platform-like Open Source projects (you all know who I mean).  The type of code that is written for these types of projects has the ability, also, to capture the hearts and minds of the brightest and the best developers.  In turn, that leads to more and more improvements to the code base that the CMS (and probably a few of the propellor heads that started working on the Platform) finally has the option of taking advantage of.  The **only** limitation is the rate at which the existing extension developers are wanting to change.  And that's where the Platform maintainers put their hands up and say "it's your call guys", but as Amy so wonderfully put it, we've empowered you with the ability to change when you are ready.  I agree the unnecessary change is undesirable, but I think there is a host of necessary change that needs to happen to modernise the CMS.

If history has any lessons for us, it will say that the CMS will probably stay 2 or 3 years behind where the Platform is at any given time.  That might wash for the LTS, but I think serious consideration needs to be given to the CMS upgrading to the latest Platform version at the start of every major release (3.x, 4.x and so on) - in fact, treat the Platform like any other third-party library in that context.  But I also think the Platform needs to take backward compatibility quite seriously and make sure there is a path for it's downstream users to upgrade at a pace that suits them - and I believe it is doing that to the best of the ability of those involved.

At any rate, it's good to see this discussion finally happening in the right place.  There are a lot of people who care about the CMS (I still do, I just don't want to work on it anymore) and I think a lot of people are worried about it because they simply don't know what's going to happen in the future (but to some extent nobody does, but a no-changes option is not the solution either).

Regards,

Andrew Eddie

[brian teeman]

Thanks for answering so many of my unwritten questions so eloquently and clearly

I still have my problems with the start of the next CMS release using the latest platform version but thats more because there has been little discussion yet about the aims of the next CMS release. Without that from the CMS it's hard to tell if there is the time or need (or will) to implement the changes in the platform

I hope that this will be resolved, belatedly, during J and Beyond next month

[Nils Rückmann]

Thanks for your time Andrew. And of course it wasn't my purpose to blame specially you.
But i like where the discussion leads (especially in one of the duplicated threads).

Like Gary and Elin said, we have the ability to use or not use specific parts of the plattform by creating own
classes and thats great. My only concern about this is the possibility that the plattform and the cms going too far away
from each other what could end in a second plattform. But this can be avoided ..

@Mark: Who leads the discussion about the aims or is even a part of that ? That is something i really don't understand.
I've personally tried to understand the whole "gear" behind the current workflows the last months, but can't find my way in.
And this could be a reason why some people are frustated about decissions or the project generally.

Why we can't involve the community in the discussions about "game changers" or other big stuff and make a decission after feedback even if we have to use polls or something. And what's about the minor changes, bugfixes or other little code changes ? Shoudn't we have a clear path for doing such things ? Where should they add issues (i personally prefer github) ? Who decides about commits ? And so on .. 
 
And in reference to that i think we really have to set the writting of documentation or at least a mark that there are changes which includes the documentation as a requirement. If we add, remove or change an event trigger for example, we have to document this as soon as possible so that we avoid situations like today where we have not even a list of available triggers.

NR

[Mark Dexter]

@Nils: The discussion of the future of the CMS is on-going and takes place in multiple channels. For the nuts and bolts, near-term features, the most important place (in my opinion) is the feature tracker (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549). This is where features for the next release are proposed, discussed, tested, and ultimately decided. Any new feature in the CMS eventually needs to go through this process, although the preliminary work can of course take place anywhere.

As far a longer-term discussions, we of course have this list. We also have community blogs. Last October in NYC we had a Roadmap meeting, and one is scheduled for J and Beyond in Frankfurt, Germany in May. And of course we have the Ideas site (ideas.joomla.org). I'm probably forgetting some other channels, but you get the idea.

Proposed features backed up by code are the ones that draw the most interest, although we have made a conscious effort to implement at least some of the top ideas on the Ideas site. For example, the auto-update was the #1 idea on that site and has been the focus of a lot of work. Personally I would love to see progress on multisite and core backup features, which are also top requests on Ideas.

As far as who leads the discussion, that's hard to say. The PLT has the final say in which features get implemented in the core releases but the PLT certainly does not try to control the discussion or in any way limit the scope of ideas that people might suggest. In some cases, PLT members have participated in coding new features. In other cases, it has been people from the community without much PLT involvement. The PLT did publish a "vision" for the 3.0 release, but it is not clear how much actual effect that has had. At the end of the day, it depends on whether someone writes the code.

I'm not sure if that answers your questions, but I hope it at least helps. We are a large, dispersed, and wonderfully chaotic community. Anyone who wants to can dive in and help create the future of Joomla, and many people are doing just that. For example, in the two months last December and January, we had 70 different people contribute code to the CMS project. Some were small patches, others were major features. And that just counts the coders, not the testers and others who work on features and bugs. If you haven't seen this cool Github graph, I encourage you to take a look: https://github.com/joomla/joomla-cms/graphs/impact. I've attached a screenshot as well. Each band of color represents a different person who coded a change.

Mark

[bill richardson]

@Nils

And what's about the minor changes, bugfixes or other little code changes ? Shoudn't we have a clear path for doing such things ? Where should they add issues (i personally prefer github) ? Who decides about commits ?

Yes - there is a clear process for dealing with bugs in the cms ( Bug squad ) - there are lists for people to post issues , they are then checked if issue can be replicated, if issue confirmed they are moved to a confirmed state where they can be patched. When patch posted the issue is moved to a pending list for testing ( needs two sucessfull tests ) and if the issue has been fixed without effecting anything else the issue is moved to ready to commit for a final test and commit.
New featues are dealt with in the same manner , although more sucessfull tests are generally required and the PLT has the final decision to approve or not.They are also raised on one of the google groups for discussion if there is differing opinions on suitabilty.

The platform generally uses github for issues - but if platform is causing issue in the cms an issue will be raised on the normal bug list and marked as a platform issue.
-------------------------------------------------------------------------------------
On the original topic --- I agree with some of your concerns --- i have no problem with the direction the platform is taking in providing alternative application support
and the platform does seem to have a vision / roadmap for the future BUT the cms does seem to lack direction at the moment  - eg. although i have seen some of Mark`s ideas
raised on a video at a conference , i have seen no vision statement or possible roadmap for the future. This also impacts on new code contributions as it does not seem sensible to complain that people are not contributing when no clear direction given on what would be desirable or needed to meet the vision.
As the platform just becomes a library for the cms ( when seperation complete ) i suppose there is nothing stopping the cms adopting another framework that already is achieving / passing the current goals of the platform and can already give cli / web service abilities if the cms so desires.

Regards
Bill Richardson

[gobezu]

Considering the probable gap of 2-3 years between CMS and platform I am just wondering how issues arising in platform as a result of use in CMS will be handled once the platform has progressed so far away?

Sorry if I am rehashing something that is discussed and dealt with elsewhere, if so please do show me the direction and I will keep quite.

[Nils Rückmann]

Thanks Mark and Bill, i see my first place should be joomlacode instead of github (even if i prefer github), okay.

But what's about the new ideas ? On ideas.joomla.org we can see what the community maybe wants, but it doesn't seems like the votings have any influence to the priority the plt (or other) gives those features.

Let's have an example: Version control for com_content

There is a feature request on joomlacode, but like Bill said "this list is for ideas that have a patch added to supply requested function that needs tested before implementation". There is a thread on the idea pool too, and considerng the voting it's a thing we want to implement. But where can we start ? We can't discuss the code(-structur) on the ideas pool, where nobody will understand such things.

Proof my wrong, but the idea pool is the place where we want to get new ideas from the whole community and not to discuss technical things, or not ?

Nils

[Nils Rückmann]

Addition: If the ideas pool should be the place for features .. do we really have only two planned features ?

[Rouven Weßling]

On 14.04.2012, at 22:43, Nils Rückmann wrote:

> Addition: If the ideas pool should be the place for features .. do we really have only two planned features ?

I'm also a moderator on the ideas pool and I'm very conservative on setting states, I'm not in the PLT so I'm not in a position to make strategic decisions anyway but given our current development style I only set thing to planned if I'm reasonable certain they're gonna happen soon - that usually means a patch is sitting on the tracker and initial feedback has been good.

For example I haven't even set "New or Overhauled Admin Interface" to planned despite the fact that Kyle is working quite hard on it. I just can't tell whether it will be done in time & accepted since his code hasn't been discussed yet at all. I'd rather not rise false hopes.

Best regards
Rouven

[Mark Dexter]

Nils, I forgot to include the Production Working Groups in the Wiki (http://docs.joomla.org/Production_Working_Groups). Anyone can form a group around any topic that makes sense. These can be for near-term issues or longer term issues or both.

You are absolutely correct that we don't have one official place (besides perhaps this list) to discuss the technical side of ideas before it is coded. One possibility would be to start a thread for a specific idea here (for example, version control). Another idea would be to start a Production Working Group on the topic and announce it here and try to find a group of people who would be interested in discussing and helping. The Feature Tracker can certainly be used for discussing ideas from a technical point of view as well.

With respect to Github, it is great to use it for coding and for sharing branches and gists. However, for any discussion where we want to include design ideas and non-coders, it is probably best to use one of these other channels. It is no problem to link to a github branch or gist from the tracker or from somewhere else.

I would love to see more active discussions of upcoming features for 3.0, including version control or any other topic that is important to members of the community. We only have a short time window to get features finished for 3.0. The good news is that, if something isn't quite ready for 3.0, 3.1 is not far away.

If there is anything the PLT can do to help this process, please let us know. The goal is to encourage participation from anyone who wants to help make Joomla better.

Thanks! Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Nils Rückmann]

Okay, lets summarize ..

1. The plattform is independant (but should sometimes think about the cms)
2. There are no specific goals regarding when we adopt a version of the plattform
3. Ideas belongs to the idea pool
4. But the main place for features should be the feature tracker

My concerns:

I really don't think that the separation of cms and plattform ends well, because of incompatible issues.
But i trust in our plt and hope you prooves me wrong.

Of Course there are many different features. There could be little things like displaying the version number, or maybe a whole refactoring of core extension. And it's not easy to get one workflow which fits everywhere, but i think it could be helpfull.
Like "idea in the pool" -> "discussion (if necessary)" -> "code for feature tracker" -> "commit". Maybe on this way we can avoid
angry developers who wrote big patches which finally will never been accepted.

And my last point: Documentation, documentation,. documentation. I can't be the only one who thinks that the documentation is
not really complete ..

PS: Are there any current ideas or even people working on refactoring com_content ?

Nils

[Aaron Wood]

Yes, the documentation sucks, it has pretty  much always sucked. That's because it (primarily) is written by programmers, not authors.

I had to buy the new Joomla Programming book just to get a cohesive set of documentation, and while I don't mind shelling out the money (it supports Joomla, after all), that's not really the Free and Open Source spirit...

    Therefore, allow me to offer my services to anyone out there who is writing/revising documentation (in english). I will be happy to look over and increase the readability of any documentation for the wiki if they just forward it to me first. I work for a publishing company, so I'm used to doing it. Since I am not fully confident in my coding yet, maybe this is the way I can contribute to the Joomla Project.

   

 

Sincerely,
Aaron Wood, Creative Director
The Fresh Ink Group, LLC

---

From: Nils Rückmann <in...@nils-rueckmann.de>
To: joomla-...@googlegroups.com
Sent: Saturday, April 14, 2012 6:08 PM
Subject: Re: [jcms] Let's talk about the future

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/-BsqSqASVxcJ.

[Mark Dexter]

Hi Aaron. Thanks for your great offer. I would encourage you to dive in and just start helping out on the wiki. Anyone can edit existing articles or create new ones. If you prefer to work with a team and get some ideas of where to start, please post over in the Documentation list here: https://groups.google.com/forum/?fromgroups#!forum/joomla-docs.

Currently I'm working on the help screens for 2.5 which are not where we would like them to be. Your help on this (or any other docs project) will be greatly appreciated.

Thanks. Mark

[Andrew Eddie]

2012/4/15 Nils Rückmann <in...@nils-rueckmann.de>:

> 1. The plattform is independant (but should sometimes think about the cms)

It would be better to say that the Platform should *always* think
about the impact on downstream developers who use the platform.

> And my last point: Documentation, documentation,. documentation. I can't be
> the only one who thinks that the documentation is
> not really complete ..

If you have a magic potion for coaxing people to write more, please
let me know :) I'm out of tricks.

The current Platform Manual is here:
http://developer.joomla.org/platform-manual.html

There are a number of things that people can do:

1. Contribute to the DocBook files on github directly.
2. Write content "somewhere" (in a Google Doc, on a wiki) and then
tell us (on the Platform list) where to find it. I will be more than
happy to convert that into DocBook and into tutorial-ese.
3. Find good developer content on docs.joomla.org (that is otherwise
buried and really hard to find) that we can convert to DocBook and
include in the Platform Manual.

The end goal is for that manual to be *the* best and FREE source of
information for developers, and maybe even have Joomla Press do a free
PDF version or something in the future. But it's not going to happen
without people volunteering to help with it on a regular basis. I
would like to enstate a rule that people can only complain about
documentation once they have personally documented at least on
Platform package :)

Aaron, what you are saying sounds great. Email me and we can touch
base on moving forward.

Regards,
Andrew Eddie

[Nils Rückmann]

@Andrew:

1. Do not poach our CMS volunteers ;)
2. We don't need magic potions. Developers should just think about their code if the changes could involve the documentation.
There's no need for developers to write a timeless masterpiece, but a little note for the documentation working group would be nice.

Nils

[Andrew Eddie]

2012/4/15 Nils Rückmann <in...@nils-rueckmann.de>:

> @Andrew:
>
> 1. Do not poach our CMS volunteers ;)

I thought we were on the same side :P

> 2. We don't need magic potions. Developers should just think about their
> code if the changes could involve the documentation.

Well, there's two levels of documentation. One is the API
documentation that is provided with the code itself. Contributions to
the platform must include this (in fact, our automated checks will
bounce the contribution if it's not done to a certain standard). This
is what's used to automatically generate the API documentation that
can be found at http://api.joomla.org/

Now, that's all fine and good but reading the API docs for a beginner
is a bit like reading the parts list for a Toyota Camry and expecting
to know how to service it. To learn how to use the API, you really
need tutorials and examples, and we've spent a bit of time lately
working out the source format and the tool chain to do that.

> There's no need for developers to write a timeless masterpiece, but a little
> note for the documentation working group would be nice.

I absolutely agree.

Regards,
Andrew Eddie

[Chris Davenport]

Finding good developer documentation on docs.joomla.org is not really that hard.  Just go to http://docs.joomla.org/Developers and cherry pick.  I'm not saying it's all good; far from it, but I doubt there is anything good that is not linked from that page.

In my experience all open source projects have problems getting good documentation written and Joomla is no exception.  There are always far more people who can write code than there are people who can write documentation.  But the barriers to contribution couldn't be lower, so everyone should just get writing.  We really don't care what format contributions are made in: Docbook XML, wiki, OpenOffice.org, plain text, whatever.  The important thing is to get stuff written; we can easily make it look pretty afterwards.

Chris.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
Chris Davenport
Joomla Leadership Team - Production Working Group
Joomla Documentation Coordinator

[Nils Rückmann]

One big problem on http://docs.joomla.org/Developers might be the different Joomla versions.

And like i said, i don't want to enforce developers to write documentations. But a small note on a todo-list or something where people which wants to write documentations can pick a topic and start writing. And if the list grows we can start a documentation sprint.

[Gary Mort]

There is a flipside, if documentation contains links to the platform
classes and methods they utilize - then you can automate the process of
determining which pages a new release impacts. Since a lot of changes
are to things which were depreciated or are adding a new and improved
method to do something[while maintaining the other for backwards
compatibility] - it would be very hard for someone working on the
platform to know whether or not any documentation needs to be updated..

[Andrew Eddie]

2012/4/15 Nils Rückmann <in...@nils-rueckmann.de>:

> One big problem on http://docs.joomla.org/Developers might be the different
> Joomla versions.

That's what the @since tags in the API docs are for, and also you can
model additional docs on how PHP does it (after all, every Joomla
developer should be intimately familiar with php.net documentation).

> And like i said, i don't want to enforce developers to write documentations.
> But a small note on a todo-list or something where people which wants to
> write documentations can pick a topic and start writing. And if the list
> grows we can start a documentation sprint.

I think that works best when you have small "holes" in the
documentation. When you have but a few packages documented in a
narrative form, there's no point in making a to-do list - it's all
to-do. If you are looking for ideas on what to write about, I can
certainly give you some ideas :)

Regards,
Andrew Eddie

[elin]

It's pretty obvious that most of the work in the doc book is in the new classes and most of the work to be done is in the older classes. We could generate a list of all of the classes but really, why not just look at the list of folders?

How about ... start with the As and do access. It would be so great to have a narrative documentation of that. 

Then Archive.

Application is in flux so how about Base?

Seriously that's how I did the doc blocks, started with the As and worked my way through the alphabet.

If people are really worried that there is going to be competition to write up a specific class we could make a page in the wiki where people write down what they are working on. But when it comes to documentation I just don't see that being a huge problem.

Elin

[Nils Rückmann]

Nobody was talking about doc blocks or other documentation which belongs directly to the plattform.

I was talking about CMS documentation. Of course everybody can read doc blocks or take a look to our api,
but such things like a list of available hooks or an information about the difference between conservative and progressive caching
could be very usefull...

[Andrew Eddie]

2012/4/17 Nils Rückmann <in...@nils-rueckmann.de>:

> I was talking about CMS documentation. Of course everybody can read doc
> blocks or take a look to our api,
> but such things like a list of available hooks or an information about the
> difference between conservative and progressive caching

> could be very usefull…

Oh, you are talking about the user help pages? That wasn't clear to
me in the context of the conversation.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Amy Stephen]

On Friday, April 13, 2012 5:22:49 AM UTC-5, Nils Rückmann wrote:

I'm tired of reading things like "that belongs to cms" and sentences like "maybe we should maybe start thinking about letting the CMS and let it run its course, and build UCM into a new, next-gen application" shows that there is a lot more than little divergences.

When the news comes out that Joomla splits to Plattform and CMS i thought it would be a good way to improve the code base and give us the ability to bring the CMS to the next levels. But it seems like im wrong and the Plattform not only goes their own way, but also (sry for ordinary language) does not give any shit about the CMS.

Maybe you have come to this conclusion, too, but I think you are responding to semantics and the personal goals of individuals, rather than the actual work produced by contributors (and how that moves the CMS forward.)

Did you have a chance to review Andrew's list of platform deliverables for 12.1? https://groups.google.com/forum/#!topic/joomla-dev-platform/1w3V4PkzZQg It's quite impressive and will be very useful for the CMS.

There are a couple of important differences due to what I see as an organizational change.

First, there is opportunity opening up for leadership for those willing to take on a working role in the CMS space. People are now focusing in specific areas, rather than covering the entire Joomla application. I see that as a very good and necessary step -- I hope that some of our well respected CMS extension devs see these openings and get more involved. Their involvement should help guide change in a way that works better for extension devs and the user community.

Secondly, the platform source code will be useful to more applications than just the CMS. So, what that will do is involve other developers who are building other applications who will contribute work to the platform -- and that will result in more source code for the CMS.

Sometimes, we tend to see change as a threat when it is nothing more than opportunities. Organizations must change to thrive. For the first time in awhile, I am hopeful for this project. I believe these are good directions.

The question each of us should be asking is where do we want to focus and what do we want to contribute. That's another area that hasn't changed. Joomla is the sum of the parts of our individual contributions. We can impact change by our shared work.

Cheers,
Amy
 

So i'm asking now: What's about the future of Joomla CMS ?

I'm thinking we should find a course (with or without the Plattform) and hold on it, because i'm not the only one who stands beside and can not find an end to shake my head. In fact it's the first time i really have to think about the using of Joomla for customers projects.

To make it clear: I like many changes in the current Plattform. But without the ability to use it in our CMS it's not worth it. It's a really cool thing to use Joomla to build an application, but Joomla (in my opinion) signifies for the CMS. Which brings me to me last consider: If we are moving on like now and seperate the CMS and Plattform completly, we should think about the label Joomla!, because it can't be used for two competing projects.

What do you think ? What's the future ? Is there a future for Joomla CMS ? Let's make decissions and don't go around in a circle... Even if the decission is like "we don't know, we only want wo keep afloat", because this could be an honest answer and the whole community (not only developers) finally has a statement which can be used to make personal decissions.

NR

[Nils Rückmann]

Amy: Too less, too late ...

[Amy Stephen]

I am sorry, Nils, but, I don't understand what you mean by that response and I really would like to understand your point.

[Gary Mort]

On 4/17/2012 1:32 PM, Amy Stephen wrote:
>
> First, there is opportunity opening up for leadership for those
> willing to take on a working role in the CMS space. People are now
> focusing in specific areas, rather than covering the entire Joomla
> application. I see that as a very good and necessary step -- I hope
> that some of our well respected CMS extension devs see these openings
> and get more involved. Their involvement should help guide change in a
> way that works better for extension devs and the user community.

I think the concept of Production Working Groups is a great thing.
http://docs.joomla.org/Production_Working_Groups

The implementation is....not so exciting. It's one of those "hidden
behind a curtain of secrecy" things where you email the proposal to
someone who will then forward it on to someone in the PLT who if they
like the idea it might get created.

Compare this to the PHP or IEEE processes for extending or creating new
standards. Just about all of them have an open list where it will be
posted and considered. Everyone can weigh in so if an idea gets a lot
of momentum, a working group can be formed quickly of those interested
in it. And if only one person wants it, it generally goes nowhere. If
an idea has a lot of public momentum but is nixed because someone on the
committee who decides on things doesn't think it's a good idea - that
person better have a dang good justification because they have to
justify themselves. Not shrouded in secrecy. I realize that the point
is not secrecy, but I have a yen for more openness.

[Amy Stephen]

Gary - going to ask you a straight-up question. Have you requested a working group only to be rejected? Or, are your comments predictive (of a possible negative consequence?) Regardless, though, the second method is available, right? (On this list?)

To be completely honest, I believe people create a lot of boundaries for themselves. Yesterday, I saw someone ask "Can we" and someone answer "No" and I thought -- dude, why ask? Do it. Make it happen.  If we are looking for someone to stop us, we'll find that it.

BTW - I liked your answer in another thread about code contributions. You create something for your needs. You share it as a PR because it's the right thing to do, doesn't cost you anything, and who knows? But, if they don't accept it, you aren't harmed, you already took care of *your* needs. We need more of that attitude. It was right on the money.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[brian teeman]

How is this hidden behind a secret curtain http://jandbeyond.org/programme/roadmap.html

[Nils Rückmann]

Hi May, it meant that your response comes one or two dozen answers too late, because we solved most my problems ;)

[Nils Rückmann]

May => Amy

[elin]

If you want to help with the help screens there is a link on the home page of the wiki http://docs.joomla.org/Help_screens. Anyone is highly welcome to jump in to work on completing them and that team has a good system for tracking who is working on what, not surprisingly that's something wikis are good at.

There is already a list of available  events in the wiki if you think it would be easier to find organized in a different way, one thing that I have done with the pages I am interested in is make portal pages on particular topics. They are pretty easy to put together and you can organize them however you think is useful.http://docs.joomla.org/Portal:Bug_Squad

Elin

[Don]

On Tuesday, April 17, 2012 4:08:18 PM UTC-4, brian teeman wrote:

How is this hidden behind a secret curtain http://jandbeyond.org/programme/roadmap.html

While that may not be hidden in secrecy, it is locked up behind that "Buy a Ticket" link. Not exactly what I'd call open access.

[Mark Dexter]

The Production Work Groups are on the wiki, which anyone can edit. There are instructions there for anyone to submit an idea for a new group. If anyone has submitted an idea and hasn't heard back or has been turned down, I'd like to hear about it. We are in the process of adding a few more groups there, based on suggestions. Creating a group there doesn't necessarily mean that anything will be done. That depends on people doing something, not just creating a group.

As far as J and Beyond, the PLT has tried where feasible to include sessions discussing the CMS roadmap at different Joomla events. For example, we had one last October in New York the day before a Joomla event there. The idea is to take advantage of gatherings of Joomla stakeholders.

It is important to keep in mind that the Joomla roadmap is an on-going discussion that takes place in multiple channels (for example, Ideas site, Feature Tracker, CMS Dev List, Google Summer of Code, etc.). No one channel is going to reach everyone, but hopefully anyone who cares about this can find one or more channels in which to participate.

The people who really determine the future of Joomla are the ones who write code, test features, write docs, answer questions on lists and forums, and otherwise contribute to the project. Making suggestions is nice, but at the end of the day it comes down to people doing the work. At least that's my .02.

Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/f-rAn8xuKMQJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Sam Moffatt]

On Tue, Apr 17, 2012 at 7:15 PM, Mark Dexter <dexter...@gmail.com> wrote:
> The people who really determine the future of Joomla are the ones who write
> code, test features, write docs, answer questions on lists and forums, and
> otherwise contribute to the project. Making suggestions is nice, but at the
> end of the day it comes down to people doing the work. At least that's my
> .02.

+1

Sam Moffatt
http://pasamio.id.au

[Andrew Eddie]

On 18 April 2012 11:05, Don <don.s...@gmail.com> wrote:
>> How is this hidden behind a secret
>> curtain http://jandbeyond.org/programme/roadmap.html
>
> While that may not be hidden in secrecy, it is locked up behind that "Buy a
> Ticket" link. Not exactly what I'd call open access.

Actually, by definition it is "open", it's just not "free" as in "free
beer" (though some of that will be provided I believe!) but the price
is ridiculously reasonable for what you get. I think everyone that
does go will have no trouble justifying it was worth it (sadly, I
won't be one of them - Europe is such a long trip from my neck of the
woods). For those that can't make it however, Mark has outlined the
many open and virtually free channels that are only the cost of an
internet connection away.

Regards,
Andrew Eddie

[Amy Stephen]

Excellent. So glad to hear that, thanks Nils. ;-)

On Tue, Apr 17, 2012 at 7:25 PM, Nils Rückmann <in...@nils-rueckmann.de> wrote:

Hi May, it meant that your response comes one or two dozen answers too late, because we solved most my problems ;)

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/Hor5MUyuxbQJ.

[brian teeman]

For the record we (the organisers of J & Beyond) offered a scholarship scheme to provide financial assistance and the PLT and OSM have also provided assistance from their own budgets. Sadly we could help with money but not distance although there are attendees from over 30 countries)

[elin]

At the road map meeting in NYC we actually had people posting questions from the web at least for parts of the event. 

Elin

[Nils Rückmann]

There is already a list of available  events in the wiki if you think it would be easier to find organized in a different way, one thing that I have done with the pages I am interested in is make portal pages on particular topics. They are pretty easy to put together and you can organize them however you think is useful.http://docs.joomla.org/Portal:Bug_Squad

Hi Elin, i still can't find a list of supported event triggers .. Do you have a Link ?

[Mark Dexter]

Hi Nils. Is this what you are looking for? http://docs.joomla.org/Plugin/Events

One bad thing about the wiki is the search. I always use something like the following in Google: "site:docs.joomla.org plugin events". That works much better than the built-in wiki search in my experience.

Mark

On Wed, Apr 18, 2012 at 11:10 AM, Nils Rückmann <in...@nils-rueckmann.de> wrote:

There is already a list of available  events in the wiki if you think it would be easier to find organized in a different way, one thing that I have done with the pages I am interested in is make portal pages on particular topics. They are pretty easy to put together and you can organize them however you think is useful.http://docs.joomla.org/Portal:Bug_Squad

Hi Elin, i still can't find a list of supported event triggers .. Do you have a Link ?

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/-xUvFah1V7wJ.

[Andrew Eddie]

On 19 April 2012 07:30, Mark Dexter <dexter...@gmail.com> wrote:
> Hi Nils. Is this what you are looking for?
> http://docs.joomla.org/Plugin/Events

http://docs.joomla.org/What%27s_new_in_Joomla_1.6
http://docs.joomla.org/16Events
http://docs.joomla.org/Adapting_a_Joomla_1.5_extension_to_Joomla_1.6
http://docs.joomla.org/Category:Plugin_Development
http://docs.joomla.org/Category:Specifications

[elin]

I always go here

http://docs.joomla.org/What%27s_new_in_Joomla_1.6#Events

because I think it is the best list.

And I agree it is a ridiculous location for really important information but I'm too lazy to have done anything about it.

Elin

[Nils Rückmann]

That's exactly what i criticize. We have http://docs.joomla.org/Plugin/Events, but it's outdated. And we have http://docs.joomla.org/What%27s_new_in_Joomla_1.6#Events what is very helpfull, but people don't want to read dozens of "What's new in xyz" articles to reveal the current state. They need one place where they get the right information.

[brian teeman]

Dont criticise - its a wiki create an account and edit