My one and only concern is that there is no roadmap for Joomla, no
published plan on where Joomla is going or the targeted users or
Surely this would need to be defined first to enable the decision
makers to decide if the RFC is appropriate for inclusion based on its
compatibility with the roadmap and not just on the quality of the code
On Apr 15, 5:14 am, dukeofgaming <dukeofgam...@gmail.com> wrote:
> The most important goals regarding this process, as I see it, would be:
> - Having a path for meaningful contributions to the roadmap and Joomla
My biggest hassle with 1.6 has been the inconsistency of effort. We
have very few people actually putting in consistent hours, and there
are an awful lot from Gunnadoo sporting the latest Roundtoit (for
those not familiar with the slang, many have said they'd do things and
just disappeared). So, while I'm right behind this sort of system (we
did it for 1.5 way back when, albeit less formally), the problem comes
after you've made the decision when someone actually has to do the
I'm certainly happy to see some fruit from this kind of discussion,
but given the number of things we've tried in the past, I'd rather err
on approving working prototypes and have a mechanism for setting a
vision or theme for each release - something a little more organic
(only because we haven't tried that one yet, hehe).
Whatever the case, I'd like to see the wider community stepping up to
the plate more in deciding what they want to be working on, but be
equally supportive of assisting with the execution. Anything that can
help achieve both aspects will be a blessing. I was introduced to
IBM's Ideastorm site last year and thought that was an interesting way
of handling it.
Those are my thoughts anyway.
http://www.theartofjoomla.com - the art of becoming a Joomla developer
> 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.
On Apr 15, 8:38 am, Andrew Eddie <mambob...@gmail.com> wrote:
> I think the idea of a roadmap is a chicken and egg scenario. You want
> to know what the roadmap is before accepting RFC's, yet RFC's are a
> way to set the roadmap.
Sorry but I disagree. RFC are a way to satisfy the aims of the
If Joomla is to be just a technical playground then its fine to be led
by RFC but it's not a playground its a serious CMS and the RFC should
be selected based on their compatibility with satisfying the general
aims of the roadmap.
On Apr 15, 8:46 am, Andrew Eddie <mambob...@gmail.com> wrote:
> How do you set the roadmap?
Firstly I would define the targeted users for Joomla. eg Is it
intended to be suitable for every web site that might exist or is it
targeted at specific marketplaces.
When you have done that you can start to define the features required
to satisfy that goal and RFC can be matched against that to see if
they are appropriate.
For example if a targeted userbase is for corporate intranets then an
RFC for complete Active Directory support would be appropriate and
worth investing the time
But if the targeted userbase was not for corporate intranets then an
RFC for DB agnosticism would not be appropriate.
By defining a roadmap you are then able to concentrate skills, talent
and time to satisfy the needs of that roadmap.
http://forum.joomla.org/viewtopic.php?f=571&t=507284 (thanks Jacques)
There's a good reference to what KDE does here:
IBM's version is here:
On Apr 15, 10:15 am, Andrew Eddie <mambob...@gmail.com> wrote:
> Let me rephrase, who is responsible for, and what is the process for
> "defining" the roadmap?
Well I'd like to think that the project leadership would be able to
But yes, after that, the RFC's/ideas can be rightly judged according
to how well they fit the goals for the the release, Joomla, or
I'm resting a lot of hope on your idea. We are in a terrible rut. This
method we are using of proposing "great ideas" in the forum is not
working. If the idea gets any attention, it is generally negative
attention and the proposing group and the project argue about why it
should or should not be done, the discussion never even addresses
technical merit or shortcomings, and it's not infrequent that it turns
If a person is not well known in our community, their ideas tend to be
overlooked. I have no doubt we are losing a lot of talent - I know
this to be the case. Low success rates of community driven efforts
have caused some in the project to give up on believing that community
efforts will ever be successful. Those who start and do not finish
have sometimes indicated a lack necessary feedback, answers to
questions, encouragement, or information has blocked their success and
they finally gave up. I've been around long enough and watch closely
enough that I know this is true and I could provide links to prove it.
We hear how community doesn't participate. We hear how project will
not allow them too. And this just repeats, over and over, and as it
does, the frustration on both sides mount. The net results is we just
are not advancing our code base like we should be if we weren't firing
I was and am encouraged to hear you come forward with ideas on how we
might formalize this process so that we better traction in this area.
I think it is very important that whatever you propose be visible and
open to everyone.
Expectations must be crystal clear. I recommend a monthly review
process by the Development Working Group Coordinators who would review
the status of each RFC which has progressed since the last review and
provide feedback on next steps for participants.
For the review, it would be good if the project provided both a status
(ex. need more information, not accepted for core, develop and offer
as extension, under consideration by Development Working Group
Coordinators, added to the roadmap). Also, providing a narrative
explaining a bit more would be good. (For example, "develop and offer
as extension" with comments that the idea has merit and will be
considered after six months of use by the community.)
I recommend that this review be done by the Development Working Group
Leaders, themselves, if at all possible.
It also needs to be clear to community that this resource is primarily
for us to work together on solving our problems with others who are
also interested in doing so. That is the PRIMARY purpose. The
secondary goal would be the inclusion in core. Your diagram that shows
the progress of the idea along a continuum helps make that clear - and
having a visual of that nature on the form - with a "Your idea is
here" kind of graphic will also help drive that home.
This needs to be a No "No" zone. We have to move away from the project
being forced into an uncomfortable position of saying "No" - to an
approach where we focus on providing a place and a process for people
with the same ideas can find one another and help each other develop
solutions. This has to be about empowering community and getting out
of their way - not about coming to the project and hoping they hear us
and do what we want.
In order for this to work, people will have to see it's working.
Having automated status reports would be great. 15 new RFCs created,
45 people actively working on RFC's during the last month; 4 new
extensions introduced as prove of concepts - and here they are - and
here's who did it, and so on. The more visible the output of this
system the more encouraged people will be to participate, and so on.
Again - thanks - I'm here for you, David. I've got years of data
warehousing experience and report development, etc., so, I want to
help you with this - it is what we need and I do want to see us being
to get better traction and bring down the drama a great deal. This
idea has merit. Feel free to assign me work.
At any rate, if it was up
to me, I'd be wanting for the community to share in the process of
defining a "direction" (be that a surveyors traverse or simply a
compass heading). Maybe that's via an idea forum, maybe a dev
conference - dunno.
There's an awesome newer extension on the JED that emulates UserVoice's Interface:
I feel like it would be a great choice for implementing a UserVoice-like suggestions system.
Sam mentioned an idea of a package manager ala Debian, and I just remembered Drupal uses "installation profiles" to include stuff out of the box without needing to cram it into core, so I think something like that as a single solution would be the panacea to this situation. I'll ellaborate some more about this:
If most/all of the core components/extensions/plugins could be decoupled from Joomla itself but still known that they are maintained by the core team, labeled somehow and recommended at installation, a modular web installer would emerge as a practical application of this [I just got the shivers], and at the same time, being Joomla in pieces and at the JED, the officially maintained extensions would get extra attention and even more contribution... and even perhaps clustering people into teams either to contribute to them or match/complement them, leading to the same objective as before and even better.
I could see Joomla 1.7 taking this approach of having its extensions at JED and having a web installer. I'm willing to help code this and make it happen. Perhaps installation profiles could make it to J! 1.8, and a way more mature package manager to J! 1.9 or even 2.0.