> Well, the problem I see is that even when good debate is done and ideas
> arise they are not really that easy to rescue afterwards; people keep coming
> with the same inquiries. I bet someone will come again asking for the Nooku
> framework to be matched by or incorporated to Joomla... its not like Nooku
> is getting any less popular, same case for jQuery (and I'm all for
> Mootools).

> I'd like to think that what I am proposing would be different from the call
> for white papers that was organized back in 2008 to a more diluted, long
> lasting and less time consuming approach so that the team can review ideas
> when they really reach a state of evolution where they are drama-free.

> Well detailed ideas that the community can constantly enrich, not
> wishlists.

> Perhaps it would be more like Python's PEPs (
> http://www.python.org/dev/peps/pep-0001/):

> [image: pep-0001-1.png]
> (If the image above isn't shown, here is the URL:
> http://www.python.org/dev/peps/pep-0001/pep-0001-1.png)

> Each PEP should have the following parts:

>>    1.

>>    Preamble -- RFC 822 <http://www.faqs.org/rfcs/rfc822.html> style
>>    headers containing meta-data about the PEP, including the PEP number, a
>>    short descriptive title (limited to a maximum of 44 characters), the names,
>>    and optionally the contact info for each author, etc.
>>    2.

>>    Abstract -- a short (~200 word) description of the technical issue
>>    being addressed.
>>    3.

>>    Copyright/public domain -- Each PEP must either be explicitly labelled
>>    as placed in the public domain (see this PEP as an example) or licensed
>>    under the Open Publication License<http://www.opencontent.org/openpub/>
>>     [7] <http://www.python.org/dev/peps/pep-0001/#id16>.
>>    4.

>>    Specification -- The technical specification should describe the
>>    syntax and semantics of any new language feature. The specification should
>>    be detailed enough to allow competing, interoperable implementations for any
>>    of the current Python platforms (CPython, Jython, Python .NET).
>>    5.

>>    Motivation -- The motivation is critical for PEPs that want to change
>>    the Python language. It should clearly explain why the existing language
>>    specification is inadequate to address the problem that the PEP solves. PEP
>>    submissions without sufficient motivation may be rejected outright.
>>    6.

>>    Rationale -- The rationale fleshes out the specification by describing
>>    what motivated the design and why particular design decisions were made. It
>>    should describe alternate designs that were considered and related work,
>>    e.g. how the feature is supported in other languages.

>>    The rationale should provide evidence of consensus within the
>>    community and discuss important objections or concerns raised during
>>    discussion.
>>    7.

>>    Backwards Compatibility -- All PEPs that introduce backwards
>>    incompatibilities must include a section describing these incompatibilities
>>    and their severity. The PEP must explain how the author proposes to deal
>>    with these incompatibilities. PEP submissions without a sufficient backwards
>>    compatibility treatise may be rejected outright.
>>    8.

>>    Reference Implementation -- The reference implementation must be
>>    completed before any PEP is given status "Final", but it need not be
>>    completed before the PEP is accepted. It is better to finish the
>>    specification and rationale first and reach consensus on it before writing
>>    code.

>>    The final implementation must include test code and documentation
>>    appropriate for either the Python language reference or the standard library
>>    reference.

>>  PEP Header Preamble

>>> Each PEP must begin with an RFC 822 style header preamble. The headers
>>> must appear in the following order. Headers marked with "*" are optional and
>>> are described below. All other headers are required.

>>>   PEP: <pep number>

>>   Title: <pep title>

>>   Version: <svn version string>

>>   Last-Modified: <svn date string>

>>   Author: <list of authors' real names and optionally, email addrs>

>> * Discussions-To: <email address>

>>   Status: <Draft | Active | Accepted | Deferred | Rejected |

>>            Withdrawn | Final | Replaced>

>>   Type: <Standards Track | Informational | Process>

>> * Content-Type: <text/plain | text/x-rst>

>> * Requires: <pep numbers>

>>   Created: <date created on, in dd-mmm-yyyy format>

>> * Python-Version: <version number>

>>   Post-History: <dates of postings to python-list and python-dev>

>> * Replaces: <pep number>

>> * Replaced-By: <pep number>

> The main gain with an approach like this where a case or draft is made is
> that people can be pointed to it everytime a related issue arises. For
> example, the possible RFCs/drafts/cases that would have been made:

>    - For the jQuery and Mootools thing,:
>       - Make Joomla library agnostic through a javascript framework:
>       Possibly under discussion, rejected or superceded by the following.
>       - Loose the dollar function at core implementation to make Mootools
>       less conflicting: Possibly accepted
>       - Implement Object Oriented jQuery integration with Mootools (
>       http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-tak...
>       Possibly under discussion and on the verge of acceptance.
>    - With the ORM matter, we could have had the following ones:
>       - Integrate Doctrine: possibly rejected, but everybody would know
>       why and wouldn't suggest it again.
>       - Implement an ORM library: Possibly accepted and the features would
>       have been already delimited.

>       By the way... at this point I don't even know if an ORM is something
>       that Joomla desires, so I just ceased trying to contribute to the idea a
>       while ago.
>    - In this case, with the Nooku framework, we could have already started
>    to decide what we want from it, or any other framework.
>    - Same goes for a CCK.
>    - Same goes for article translations.
>    - Same goes for the excellent package manager ala Debian you are
>    talking about. How can we even start to contribute to the idea after
>    discussing new perspectives, feature ideas, and even ideas of ways of
>    implementing it?

> If an RFC/draft/case process was already in place, perhaps this discussion
> would have been all about comparing Nooku + Joomla to other frameworks and
> start feeding new drafts or contributing to existing ones. I'm sure of it.

> With a project this big and mature my feeling is that the core team should
> have the luxury of just be stating the intentions/direction on an issue and
> then cherrypicking the solutions (ideas and implementations), at least most
> of the time.

> Of course 100% of the people won't agree on something in particular, but at
> least we could have a consistent way of approaching a middle ground where
> everybody is comfortable with a solution that solves their problems, and
> where they can actually contribute. And I'm not talking about code... to put
> it bluntly: I would not write a single line of code that I don't know if its
> going to be accepted. With bugs knowing that is easy, with features its not.

> I'd like to think more of it in terms that everybody holds a piece of the
> solution, the problem I see is that there is nowhere to put those pieces
> (again, not code).

> Also, I think what Amy proposes is brilliant:

> Then, as people's crazy dreams start evolving into workable solutions,

> those overseeing the core could provide feedback and guide the effort,

> either towards inclusion in core or as a community-wide/project

> supported extension. (Maybe the process would always call for first

> use as an extension and then possible inclusion as core if successful

> and broadly needed.)

> Perhaps we could go like:

> Crazy Idea -> Draft -> Accepted Feature -> Community Extension -> Core
> Candidate -> Official

> Now, just imagine for a moment here, if on the JED a Community
> Extension extension was labeled as a "Core Candidate", everybody would
> already know where to contribute functionality, and by looking at the
> accepted draft, we would already know how.

> Framework additions could enter first as an extension, and under the right
> requirements, then incorporated to the core. This is something that Amy also
> suggested back then with the big Mootools-jQuery brouhaha for the JScript
> framework extension idea others and I started to design.

> Of course, one could say "oh noes!, another thing to maintain...", but it
> is my belief that, with an encouraging process, more devs would inherently
> be attracted to the project in a sustainable fashion.

> Regards,

> David

> On Sun, Apr 11, 2010 at 9:36 AM, Sam Moffatt <pasa...@gmail.com> wrote:

>> We did have a formal RFC or papers process for 1.6 and we poured
>> through them all and for the most part they ended up being wishlist
>> requests with very few people actually turning up to build the code.
>> We might have one again for 1.7 when we're done with 1.6 and it might
>> work better then with things but at this point in time an RFC process
>> probably isn't going to work.

>> Things might have been ignored which is unfortunate but it is also
>> life. Everyone is busy and sometimes they need a reminder. At work I
>> have a two month lead time on jobs getting done by our system
>> administrators. If something has been dropped between the crack people
>> (myself included) might need reminding. We're far from perfect and I'm
>> the first to admit it but we're trying to get there.

>> And to be honest I have no issues with you setting up an RFC area on
>> the wiki and posing it for discussion here. It should be discussed and
>> improved by everyone who has an interest in building it. RFC's
>> realistically take a while as you're saying so there is no harm in
>> starting the process now with your ORM project.

>> But perhaps I wonder if we're going the wrong way, thinking about this
>> the wrong way. I wonder if we're asking the wrong question. We're
>> asking about building an ORM library, including the Nooku library,
>> including the JXtended library (which is really integrated into the
>> core Joomla namespace) and having it included in the core
>> distribution. This sooner or later makes things chunky, especially
>> when none of the core depends on them. To be honest there is nothing
>> stopping anyone shipping libraries that run with Joomla! and do their
>> own thing. I have myself my own set of libraries for Joomla! but I
>> don't think it'd be appropriate to include them even though I could.
>> To be honest there are times when I wonder what this obsession is with
>> putting all of this stuff in core. Why not build something awesome, do
>> it right, release it out there and then get it included. Why this
>> insistence upon waiting for it to be approved to go into core before
>> building things? If it is good, build it, put it out there and see if
>> people are using it. In some respects this is what Nooku are doing and
>> we're having this conversation but as you can tell, I'm wondering
>> about that as well.

>> Additionally being included in the core means is that you're tied to
>> the core's timeframes. This can make life hard. For my own projects
>> there are those which I feel should be in core like the update stuff
>> but almost everything else I do I feel should live outside. If I want
>> to add a new feature or similar I'm not tied to the next major release
>> or similar - I can just do it.

>> What I'd love to see is more people take this up. We eventually pull
>> stuff out of core, shift more towards building distributions with off
>> the shelf components, in 1.7 I want to build a really awesome
>> dependency manager (I didn't get around to it for 1.6) so that this
>> just happens. You want to install a component and it requires Nooku
>> Framework, that is fine it is handled. Move towards a model like the
>> Debian with its package manager systems. I've wanted to get here for a
>> while but haven't had the chance. If anything I feel it is the most
>> important thing out there. Rebuilding the way com_content works? Sure,
>> wonderful, but someone else can do that. Making a kick arse
>> installer/updater/package manager/automatic backup engine/tool for
>> global domination? Someone else could do it but until it is in core
>> nobody can really depend upon it.

>> But at the end of the day we need to step back an objectively look at
>> what the core needs and what people could do better. There are tonnes
>> of CCK solutions out there for Joomla! now and there are some people
>> who think this is a problem. Libraries like Nooku Framework I don't
>> see as a problem or even particularly needing to be included in core.
>> If you look at a modern operating system there are many different
>> libraries each duplicating the same functionality. If you look at the
>> core of an operating system, the kernel, in some cases there are moves
>> to shift stuff out. User space file systems stands as something in my
>> mind that demonstrates something traditionally very much in the realm
>> of the kernel being moved out into user space.

>> So whilst I'd love to see the Nooku guys integrate Nooku into the
>> Joomla! libraries and have that discussion here, they're off building
>> their framework their way. And you know what, I think that is cool and
>> healthy. I think it is great for them to do that and make it available
>> to the Joomla! community, they come along to JoomlaDay and talk about
>> their framework and if it results in better Joomla! extensions then it
>> is great.

>> And I'd like to echo Louis' sentiments. Never is there anything that
>> people completely agree or disagree with. Not just in frameworks but
>> in operating systems, application design, systems integration and much
>> more. There is always a decision that one might disagree with, I
>> personally like to call them "curious" decisions - ones that I might
>> not make myself but aren't necessarily wrong. Take for example
>> Windows's security model, it is perhaps the most robust and advanced
>> of the security models for file systems out there. It is the basis of
>> NFSv4 ACL's which itself is source for Mac OS X and ZFS ACL's. But it
>> also has the change notify privilege which subverts the security
>> protections you get from traverse checking. That is a curious decision
>> and a performance vs security trade off in addition to the fact the
>> same SeChangeNotifyPrivilege control change notifications AND enables
>> bypass traverse checking, but it is an approach they've taken.

>> At the end of the day we can't possibly hope to stuff everything in
>> core. We've seen that in the past and it doesn't bode well.

>> Sam Moffatt
>> http://pasamio.id.au

>> On Sun, Apr 11, 2010 at 11:33 AM, dukeofgaming <dukeofgam...@gmail.com>
>> wrote:
>> > @Elin
>> > Thanks for your comment, I'd certainly be interested in
>> discussing/working
>> > on that kind of ideas.
>> > @all
>> > Sorry if this is offtopic but I think it is a good time to mention/ask
>> it.
>> > Is there any kind of formal process to submit RFCs for the core team to
>> > analyze?.
>> > The reason I'm asking is because in the short time I have participated
>> in
>> > these discussion groups I have seen some interesting ideas go by
>> somewhat
>> > unnoticed, others stranded, and although I think the google groups are
>> the
>> > best place to discuss such ideas I don't think it is the best way to
>> make
>> > progress on them, because of the signal to noise ratio.
>> > For example, people keep asking the J! team to replace mootools with
>> JQuery
>> > and no official statement has been issued, leading to more and more
>> people
>> > asking the same thing. And the team, IMHO, shouldn't make an official
>> > statement, as it might anger JQueryists, even if its in the slightest,
>> its
>> > not good for the project. Regardless, I think there is a real (although
>> not
>> > bit) problem, as there is a latent insatisfaction.
>> > Another example is what happened with the ORM suggestions I made a while
>> > ago, including ways of implementing it (code samples included). I
>> proposed
>> > either integrating Doctrine (something I do for *all* my Joomla
>> projects) or
>> > (re)start an ORM project so Joomla does not depend on another library,
>> as it
>> > might be risky for the project (I say that now, and I say it again for
>> this
>> > particular case). But there was not a lot of attention, and even if the
>> need
>> > of an ORM is talked about somewhere, is unlikely people will find the
>> topic
>> > I started.
>> > So, what I am saying here is that I'd like to see a process/place for
>> daring
>> > (but not so crazy) ideas to be considered and discarded/worked-on in a
>> more
>> > orderly fashion. Meaning having the "R" from RFC in the wiki and made
>> > through some guidelines, and the "C" being the google groups and/or
>> forums.
>> > An example of the point I'm trying to make is the PHP Traits and Grafts
>> RFC:
>> > http://wiki.php.net/rfc/traits
>> > The previous is a subject of interest for some relatively small group
>> (but
>> > with benefit to all the PHP community) that might have been just
>> discarded
>> > for being too "crazy" if it wasn't for that wiki entry, an entry that
>> has
>> > been heavily refactored/rethought at least 3 times, with 2 previous
>> entries
>> > being superceded, and thanks to the RFC process itself.
>> > I have seen a lot of "my patch was ignored" comments here and there,
>> even if
>> > the patch may have had some serious thought behind it. Frankly, this has
>> > been my personal reason for not having started to code on any of my
>> ideas
>> > for joomla, as they might just go by unnoticed, and unfortunately I'm
>> not a
>> > person with a lot of free time.
>> > As Amy pointed out on two messages, there are really good sources of
>> > inspiration that Joomla should consider in the future, such as RT's
>> Gantry
>> > framework, the Nooku framework, Kohana, Symfony, Yii, Doctrine, even
>> JQuery
>> > itself... hell, even Ruby On Rails (*peh!* =P). In order to take such
>> > ideas/examples into account for the specific case of Joomla, I think
>> each
>> > seriously taken proposed feature should have a case made, so that our
>> core
>> > devs can just say "it makes sense, we can include it at certain point"
>> or
>> > "the idea needs more work" and even "here are our ideas/work/intentions
>> so
>> > far on the subject", instead of debating others' absolutes.
>> > Its not just code what's on the line here. Changes and additions to
>> Joomla
>> > should not be taken lightly, and I mean it for both suggesting and
>> > discarding them. Suggesting sometimes turns into demanding (citing the
>> case
>> > of JQuery and this case itself), and discarding sometimes just means
>> > unnoticing.
>> > Having a formal RFC proccess such as the one PHP has would solve this
>> kind
>> > of discussions, that have real and big value behind them, but are on the
>> > verge of dispute (or drama), and would help make real progress on each
>> > subject anyone cares enough to make a serious case for. That is my
>> belief.
>> > Regards,
>> > David
>> > On Sat, Apr 10, 2010 at 12:53 PM, Amy Stephen <amystep...@gmail.com>
>> wrote:

>> >> I've been looking at symfony and Kohana a bit lately. It's interesting
>> >> to see how code evolves and how it inspires new code. I see influences
>> >> of symfony in 1.5 - maybe it's just frameworks, in general, idk, but
>> >> it seems there is some parallels.

>> >> @Louis - I don't know if you have magical powers, or not, but not long
>> >> after I read your note inquiring on the public availability of Koowa,
>> >> Johan opened the Nooku developer portal.
>> >> http://twitter.com/nooku/status/11939667480
>> >> So, it will be good for those who have not played with it, yet, to
>> >> take a look.

>> >> @Torkil - for me, this is not an either or kind of thing where we
>> >> should even consider unplugging one framework and plugging in the
>> >> other. That *would* be an ego thing since there are clearly advantages
>> >> in the 1.6 framework that I want available, too, and things I also
>> >> like better in Koowa. The point is that the project must be open to
>> >> everyone to participate and we should consider interesting solutions
>> >> emerging from the entire global developer community.

>> >> I am very comfortable with the responses we heard from Andrew, Sam,
>> >> Louis and Hannes. I briefly spoke with Johan and he also seemed
>> >> pleased with this open community discussion and the various
>> >> viewpoints. So, from my perspective, the door is open and anyone who
>> >> wants to collaborate as a community is able to do so. From there, it's
>> >> up to each individual developer to consider what works best for their
>> >> goals and ambitions and to jump in or continue on more focused tracks.
>> >> It's fair to say you gotta jump in to be involved, but that goes
>> >> without saying.

>> >> On Apr 10, 11:02 am, Louis Landry <louis.lan...@joomla.org> wrote:
>> >> > Torkil,

>> >> > My response has nothing to do with my ego.  I really have no idea
>> where
>> >> > you
>> >> > come off saying that to be honest.  Your statement that "first two
>> >> > people
>> >> > I've ever encountered that's both studied the Nooku FW 0.7 codebase
>> AND
>> >> > found stuff in there they did NOT like" to me speaks more to there
>> not
>> >> > being
>> >> > enough high level developers actually studying the codebase -- or
>> that
>> >> > you
>> >> > just haven't encountered them.  There are NO frameworks out there in
>> any
>> >> > language, on any platform, or with any significant purpose that some
>> >> > developers don't find flaw in.  Software is as much art as it is
>> math.

>> >> > You also seem to be putting words or thoughts into my head about the
>> way
>> >> > the
>> >> > Joomla Framework is to be improved.  Have Andrew or I ever said
>> anywhere
>> >> > that we only want to extend the framework and not replace parts of
>> it?
>> >> >  I am
>> >> > fairly certain I never said anything like that.  I have in fact
>> replaced
>> >> > some parts of the framework in the 1.6 trunk for example.  You are
>> also
>> >> > welcome to take a stab at replacing another part if you believe you
>> can
>> >> > make
>> >> > it better -- just like anyone else including Johan and anyone else at
>> >> > Joomlatools.

>> >> > - Louis

>> >> > On Sat, Apr 10, 2010 at 3:48 AM, Torkil <torkil.john...@gmail.com>
>> >> > wrote:
>> >> > > At least I hope this discussion has made people realize that in
>> both
>> >> > > the framework and CMS world, things are moving really fast, so you
>> >> > > either keep up or get overtaken. Right now, Joomla is way behind in
>> >> > > most areas, and seems only to be floating along based on previous
>> >> > > merits. As Hannes mentioned in another discussion: While J1.6
>> probably
>> >> > > will be fine and dandy, if it is ever released, it still won't
>> bring
>> >> > > us up to speed.

>> >> > > As a developer, Nooku Framework for me is a improved and more
>> >> > > effective toolbox, than the Joomla Framework. From the outside it
>> >> > > seems weird that some people, like for instance Jennifer here,
>> thinks
>> >> > > that it's the job of those who (imo!) drive innovation and
>> improvement
>> >> > > in code in their own project, to set up a Joomla branch and try to
>> >> > > drag along those who can't seem to finish what they set out to do.
>> Let
>> >> > > me correct myself: Not drag along, but spend time to TRY to drag
>> along
>> >> > > and get things up to speed, while still risking that the code is
>> just
>> >> > > turned down.

>> >> > > I've now read Andrew and Louis say that some parts about Nooku they
>> >> > > like and some parts they don't. With all due respect: That's the
>> first
>> >> > > two people I've ever encountered that's both studied the Nooku FW
>> 0.7
>> >> > > codebase AND found stuff in there they did NOT like. If you are to
>> >> > > improve the Joomla Framework, it's not always enough just to extend
>> >> > > it. Some pieces you just might have to replace. The code is good
>> guys,
>> >> > > and there is an ever growing list of extensions out there to prove
>> it.
>> >> > > You need to get over your egos and realize that someone outside the
>> >> > > core team is actually doing the stuff the core team should be
>> doing.
>> >> > > Desperately trying to sit upright on that high horse of yours and
>> >> > > maintain positions is just making you look bad.

>> >> > > You have to chase and embrace innovation to stay in the game, not
>> >> > > demand that it comes over to shine your shoes.

>> >> > > On Apr 10, 7:53 am, Jennifer Marriott <marpomultime...@gmail.com>
>> >> > > wrote:
>> >> > > > Any arguments regarding the fact that people can get Nooku from
>> the
>> >> > > > above mentioned by Torkil link -
>> >> > >https://sourceforge.net/projects/nooku-framework/develop
>> >> > > > , and that those developing Nooku can open a branch on joomlacode
>> >> > > > whenever they wish as mentioned by Sam?

>> >> > > > I thought not. :)

>> >> > > > No one is stopping anyone from getting any positives or negatives
>> >> > > > from
>> >> > > > either Joomla! or Nooku and/or offering/downloading anything at
>> any
>> >> > > > time when it comes to Nooku or Joomla!  I think that clears it up
>> >> > > > nicely.

>> >> > > > Let's all tip a hat to Amy by stating   -  With deepest heartfelt
>> >> > > > respect to all involved  :)

>> >> > > > Let's move along shall we?
>> >> > > > Jenny

>> >> > > > On Apr 9, 9:42 pm, Torkil <torkil.john...@gmail.com> wrote:

>> >> > > > > To me it seemed that the original author was asking about both
>> the
>> >> > > > > framework and the translation tool. He/she must be a fanboy,
>> like
>> >> > > > > me :)

>> >> > > > > For Louis, and anyone else interested, you can get Nooku
>> Framework
>> >> > > > > from here:
>> https://sourceforge.net/projects/nooku-framework/develop

>> >> > > > > On Apr 10, 2:32 am, Louis Landry <louis.lan...@joomla.org>
>> wrote:

>> >> > > > > > To the original poster, the answer is we don't know, but
>> >> > > > > > probably not
>> >> > > > > > exactly as Nooku is today.

>> >> > > > > > We don't yet know exactly what Joomla 1.7 will look like, but
>> It
>> >> > > > > > is
>> >> > > certain
>> >> > > > > > that many people feel strongly that looking towards doing a
>> >> > > multi-lingual
>> >> > > > > > set of features would be something worth focusing on for that
>> >> > > release.  I
>> >> > > > > > was one of the original developers of Nooku back when it was
>> in
>> >> > > > > > its
>> >> > > infant
>> >> > > > > > stage and there are some clever things done in it for sure,
>> but
>> >> > > > > > even
>> >> > > back
>> >> > > > > > then Johan and I talked about it not being the long term
>> optimal
>> >> > > solution
>> >> > > > > > for that problem.  That doesn't mean it isn't the best thing
>> >> > > available now,
>> >> > > > > > nor that it is a bad solution in any way... it's great.  That
>> >> > > > > > being
>> >> > > said,
>> >> > > > > > the functionality should really not be an "add-on" but more a
>> >> > > systemic
>> >> > > > > > aspect of the content model.

>> >> > > > > > I base those comments on the latest version of Nooku I have
>> >> > > > > > seen,
>> >> > > which was
>> >> > > > > > around the 0.6 range if I remember correctly.  They may have
>> >> > > > > > changed
>> >> > > course,
>> >> > > > > > and if what Wilco says is true (and I wouldn't doubt that to
>> be
>> >> > > > > > the
>> >> > > case)
>> >> > > > > > then it would seem they are looking to implement the more
>> long
>> >> > > > > > term
>> >> > > > > > solution.  I think that's fantastic.  I also think it is
>> >> > > > > > something we
>> >> > > will
>> >> > > > > > need to address sooner rather than later as well.

>> >> > > > > > Regarding Koowa, which is the framework the Joomlatools  are
>> >> > > developing I am
>> >> > > > > > sure there are some great concepts in there... last I looked
>> at
>> >> > > > > > it
>> >> > > there
>> >> > > > > > were certainly some things I really liked in it, and like
>> >> > > > > > anything
>> >> > > some
>> >> > > > > > things I would have done differently.  There seems to be some
>> >> > > confusion in
>> >> > > > > > this thread regarding which is which.  The original author
>> >> > > > > > didn't
>> >> > > really ask
>> >> > > > > > about Koowa being integrated, but Nooku.  Regardless, neither
>> >> > > > > > will be
>> >> > > > > > integrated unless the authors wish them to be integrated.  We
>> >> > > > > > may
>> >> > > duplicate
>> >> > > > > > some of the ideas or concepts in those codebases, but it
>> isn't
>> >> > > > > > like
>> >> > > we are
>> >> > > > > > just going to add them in without those authors being
>> involved.

>> >> > > > > > Someone made mention of some of the third party packages
>> already
>> >> > > > > > in
>> >> > > our
>> >> > > > > > tree.  It isn't exactly the same thing.  Nooku as far as I
>> know
>> >> > > > > > isn't
>> >> > > > > > available to the public.  Certainly it is GPL licensed, but
>> >> > > > > > there
>> >> > > isn't last
>> >> > > > > > I looked simply a download link on nooku.org.  We aren't
>> >> > > > > > interested
>> >> > > in
>> >> > > > > > interfering with someone's business by simply adding their
>> >> > > commercially
>> >> > > > > > available software into our source tree without their
>> >> > > > > > involvement.
>> >> > >  That
>> >> > > > > > would be highly disrespectful and in my view unethical.  I
>> would
>> >> > > > > > also
>> >> > > say
>> >> > > > > > that with respect to those third party library packages it is
>> >> > > > > > our
>> >> > > long term
>> >> > > > > > intentions to remove them and have our own libraries and
>> >> > > implementations
>> >> > > > > > which are more consistent with the rest of the Joomla APIs.

>> >> > > > > > With respect to the JCA, I will respond in the other thread.
>> >> > > > > >  Thank
>> >> > > you Phil
>> >> > > > > > for starting a new one. I will say this though, the purpose
>> of
>> >> > > > > > the
>> >> > > JCA is
>> >> > > > > > for major code contributors moving forward, not going back
>> and
>> >> > > looking for
>> >> > > > > > anyone throughout the history of the project that might have
>> >> > > > > > written
>> >> > > some
>> >> > > > > > code.  Just as I said in my blog post on the matter.  If that
>> >> > > > > > wasn't
>> >> > > clear,
>> >> > > > > > my apologies.

>> >> > > > > > - Louis

>> >> > > > > > On Fri, Apr 9, 2010 at 7:03 PM, Amy Stephen
>> >> > > > > > <amystep...@gmail.com>
>> >> > > wrote:
>> >> > > > > > > Andrew -

>> >> > > > > > > I appreciate your answer. I would caution against taking
>> any
>> >> > > > > > > of our
>> >> > > > > > > comments as a criticism of core. What I hear (and feel) is
>> >> > > > > > > just a
>> >> > > > > > > desire to help more in the community build ownership in the
>> >> > > > > > > development process, and cash in on some of the good stuff
>> we
>> >> > > already
>> >> > > > > > > have laying around. More and more your role and the role of
>> >> > > > > > > the
>> >> > > other
>> >> > > > > > > coordinators, will (hopefully) become more of a
>> coordinator,
>> >> > > teacher,
>> >> > > > > > > project manager. So, thanks for your positive response and
>> all
>> >> > > > > > > of
>> >> > > your
>> >> > > > > > > effort getting us here.

>> >> > > > > > > Elin - I am wondering if you might have just had a bad day?
>> I
>> >> > > > > > > am
>> >> > > not
>> >> > > > > > > certain if you are aware, but four times today, you
>> >> > > > > > > inadvertently
>> >> > > told
>> >> > > > > > > community to go away by telling them that they were not
>> >> > > > > > > talking the
>> >> > > > > > > right way, or about the right stuff, or in the right
>> location
>> >> > > > > > > at
>> >> > > the
>> >> > > > > > > right time. We really want to keep these types of friendly,
>> >> > > positive,
>> >> > > > > > > organic community discussions going.

>> >> > > > > > > I thought Phil's question was a good one. He asked it in
>> >> > > > > > > response
>> >> > > to a
>> >> > > > > > > comment made by a Development Leadership Team member, he
>> asked
>> >> > > > > > > politely, the topic is related to development, and the
>> >> > > > > > > information
>> >> > > is
>> >> > > > > > > something most of us are interested in. I am sorry to say
>> >> > > > > > > this, but
>> >> > > > > > > your response to him in the other thread was not
>> respectful.

>> >> > > > > > > I also agree with Danayel that this conversation *is*
>> >> > > > > > > appropriate
>> >> > > here
>> >> > > > > > > and I hope we try to encourage developers to talk here,
>> rather
>> >> > > > > > > than
>> >> > > > > > > push them off onto an off-property site. I think we'd agree
>> >> > > > > > > that
>> >> > > > > > > discussing project topics off site doesn't always work
>> well.
>> >> > > > > > > We
>> >> > > should
>> >> > > > > > > try to work together. Here, we can be together if we allow
>> it.

>> >> > > > > > > Finally, I want to say that while I agree with you that the
>> >> > > > > > > nooku
>> >> > > devs
>> >> > > > > > > are talented and I also wish them luck, I really wish *us*
>> >> > > > > > > luck -
>> >> > > that
>> >> > > > > > > we might learn how to work together so that people don't go
>> >> > > > > > > off and
>> >> > > > > > > take with them such

>> >> > ...

>> >> > read more »

>> >> --
>> >> 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<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

>> > --
>> > 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<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

>> --
>> 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<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

>  --
> 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<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.