[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jfw] Re: Versioning namespaces
On 20 May 2015 at 08:32, Michael Babker <michael.babker AT gmail.com> wrote:
> The feeling I
> got from that thread is if it makes sense, we'll get support behind it, but
> a user migration path MUST be provided by the "core team", we can't put all
> of our money in jUpgrade or SPUgrade covering tasks that should be done by
> core. So it isn't blind permission to say "screw B/C", but I get the
> feeling B/C doesn't necessarily need to be the absolute first priority
> looking toward a major overhaul of the app. And in complete honesty, I
> think we're shooting ourselves in the collective feet if we try to balance
> B/C and rearchitecting the legacy structure of the CMS; one of the two will
> have to give in some form.
As I said, I don't want to fight on two fronts. I don't want to have
to justify sensible changes to people that just don't want to
understand. I'd rather give them the option of not having to worry
about things until the CMS bumps a major version whenever it feels it
Starting to run into a side issue here but I think the key is to
change the purpose of the Framework to deliberately serve the CMS,
whilst still making a case that other non-Joomla people might be
interested in our code.
Here's my take-over-the-world-again plan:
1. We work out the workflow for bringing FW work into the CMS via
Composer. That is, when something is ready here, there is a well
defined and clean path to get that code into the CMS quickly (taking
days, not years).
2. We identify some quick wins in the CMS to do our initial
experiments on. It might be a tiny bit of the code, but we:
* identify the behaviour in the core
* define an explicit Interface for the API
* write the FW code, tests and documentation
* include the new code into the CMS via Composer and adjust the core
code to use it
Rinse and repeat a couple of times just to get into a groove and prove
to people that the sky is not going to fall.
Hint - don't take ORM first - pick a few small things.
3. To facilitate this process we change our collaboration approach
from "do whatever you want whenever your want" to "we decide to focus
on one thing at a time". Joomla has certainly flourished when there
are highly skilled, self-motivated developers that just know what to
do and know what to fix. These days, they are few and far between
because of the way we have made decisions in the past (aka, you have
to please everyone and end up pleasing no one).
So the change would be to borrow from the Agile methodologies where we
deliberately break our time into "sprints" (not to be confused with
what Joomla historically calls a code sprint).
You pick a cycle length - either 2 weeks or 1 month.
You identify one, perhaps two goals to achieve in that sprint and
everyone is asked to focus on that one or two goals.
You break goals into tasks so that people know what to do when they have time.
For now, most of the goals will revolve around improving the CMS with
well designed, lightly or non-coupled packages. This is a deliberate
ploy to make the CMS team(s) see that we are the good guys, in fact we
are the crack developers that allow them to make crazy magic in their
This leaves the CMS to concentrate more on the end user features and
eye-candy that we have historically dazzled the world with.
In the process, we'll get goals that do non-CMS specific things. But
solving problems in the CMS the right way are going to benefit
Each sprint we use the Volunteer Portal to report back to the
community on what we did and what we plan to do next.
4. By this time we are in a good groove - people know what we are
doing and contributors know what to do. The next step is simply to
handle progressively more challenging areas of the code.
5. We put needless debates to bed.
PSR-2 keeps coming up? Ok, let's just go PSR-2 so we don't have to
waste time arguing all the flippin' time why we aren't using it.
Documentation needs to be done some better way. Ok, whatever, let's
just thrash it out once and for all and decide how it should be done.
If there is no clear consensus, put it to a vote of the Team Members
(which today stands at 3 so it's going to be a quick vote on every
issue - hint: being a Team Member is where the power to shape Joomla
now resides and I think this is a GOOD thing).
Here endeth the manifesto.
Sound exciting, challenging, fun? I think so.
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.