What is the Framework Team supposed to be

[Andrew Eddie]

Following on from the other discussion which is wandering across a few topics, I thought it would be helpful to try and better define who we are (with the odd view to establishing whether I actually want to be involved, but I'm sure many of you are thinking the exact same thing).

I think it goes without saying that we, the Framework Team, have an image problem, if not an identity crisis.

Whatever you call it, I think we need to sit down and work it out. To that end, here are some thoughts on how Joomla could or maybe even should look upon the Framework Team.

Purpose statement

1. We are the people that write the engine(s) for Joomla software (not the CMS team, not the IFW team, we do).

2. We deliberately write our code in separate, testable packages so that Joomla's code can be used by any developer in the world.

3. We guide continuous improvement in the architecture of the Joomla's software so that its code is:

   a) easy to understand,

   b) easy to maintain,

   c) easy to test with automation tools, and

   d) easy to customise or extend

Values

1. We value software craftsmanship, continually striving for architectural excellence.

2. We value the future generations of software craftsmen, thus are always eager to mentor those wanting to learn the craft.

3. We value backward compatibility and seek only to "break" things when absolutely necessary.

4. We value the "interface" over the "implementation".

---

In short this is proposing a paradigm shift - that we are the source of the code spring or river per se.

The FW Team sets the pace for for the tool kit that the Joomla CMS has to write it's extensions. To pull out a simple example, the FW Team writes the MVC, the CMS Team writes the extensions built on our MVC.

The FW Team wants other developers to use the code so it's important we structure things so that other Joomla and non-Joomla based developers can do that.

Not only that, we need to be guiding the architectural decisions for all software that the project needs or produces.

And above all, we strive for excellence. This means that when we change things, it's because it's a better way that will probably save you time and money in the long run.

If this is what people want (and it's what I think the entire project needs), I think that's a pretty exciting thing to be involved in, no?

Thoughts, comments, constructive criticism?

Regards,

Andrew Eddie

[Michael Babker]

My only thought about the above is that when all is said and done and things are moving forward again, we (the teams steering development on the distributed products in Joomla's brand) need to be doing so in unison.  Yes, the CMS and Framework are going to diverge with regard to target audience, the tools provided by them, and maybe where a feature lays in the code stack, but there needs to not be a public perception that the two teams are competing for resources or that the teams are doing two different things and both need to play catch up to figure out what's going on within them.  If Joomla's mission "is to provide a flexible platform for digital publishing and collaboration" then the two teams should work together to execute that mission.

--
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-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

[Nils Rückmann]

Am Freitag, 22. Mai 2015 02:31:07 UTC+2 schrieb Michael Babker:

My only thought about the above is that when all is said and done and things are moving forward again, we (the teams steering development on the distributed products in Joomla's brand) need to be doing so in unison.  Yes, the CMS and Framework are going to diverge with regard to target audience, the tools provided by them, and maybe where a feature lays in the code stack, but there needs to not be a public perception that the two teams are competing for resources or that the teams are doing two different things and both need to play catch up to figure out what's going on within them.  If Joomla's mission "is to provide a flexible platform for digital publishing and collaboration" then the two teams should work together to execute that mission.

Just my opinion, but i think most of the time people might think that there are two teams in competition, because of the unnecessary drama. And i think the quality of that drama is kind of unique in the php universe. I truly don't see any reason for that. Let's assume one day we will have smaller (and more productive) teams aka working groups like: One for the real basic application, one for the content extension and so on. Which besides sounds like the only reasonable way for me. Will the "Joomla-Team" still be speaking about competition ?

[Nils Rückmann]

@Andrew

Maybe it's my language, but it sounds like the FW should force the CMS to use their stuff. I think pulling is more productive than pushing. The CMS should want to use the FW, not be forced. And theres the problem. Everybody is speaking about different teams like they are competing companies. Sure, there has to be someone in charge. Not to rule the world, but to be a contact with an overview and the ability to show directions.

[Andrew Eddie]

If you think of the CMS as a product, it makes sense to have a
separate team that is building the raw materials (the framework), and
a separate team that builds widgets out of those raw materials
(extensions and the CMS application that makes them run). It's no
different to looking at the separation of concerns when we are writing
code.

It goes without saying, but let's say it, that both (or all) teams
MUST work together in the same direction to build the products that
Joomla ships. But at the same time, both teams with have areas that
don't overlap and being in separate teams provides freedom to do
"other" things (this is why the Framework was split off in the first
place, because contributions that could not be used in the CMS were
being blocked).

It means that the Framework and CMS teams need to have regular
meetings to make sure common priorities are aligned, and the competing
priorities are balanced. I don't see that as being a problem and in
the event of a deadlock, the PLT is there to break it. With the new
structure, if teams are not working together, it's a failure of
leadership one way or the other.

However, because this team is dealing with the raw building blocks of
code, I think there is a mandate that we need to develop a culture of
ruthlessly striving for best practice. And that should provide a
positive feedback loop into the rest of the project. I'm thoroughly
sick of dragging my standards down to the lowest common denominator
just because people are resistant to change or don't want to learn a
better (and usually less expensive) way.

But I don't have the time or energy to solve all the problems in all
the teams - so this is where I start because the Framework Team is
small, and that makes it agile, and it's where an architectural
thinker like me can contribute the most.

Regards,
Andrew Eddie

[Andrew Eddie]

> --
> 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 a topic in the

> Google Groups "Joomla! Framework Development" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/joomla-dev-framework/zB_XozmdFgI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Andrew Eddie]

On 22 May 2015 at 11:41, Nils Rückmann <ma...@nueckman.de> wrote:

> @Andrew
> Maybe it's my language, but it sounds like the FW should force the CMS to
> use their stuff.

No, that's not exactly the intention, but there is the idea that the
Framework team has a duty to strongly guide the architecture of any
product the Joomla project produces. As I've said before, if the
Framework team is just under the Joomla banner for the advertising
benefits only, it's a waste of time.

> I think pulling is more productive than pushing.

It depends. My observation is simply this. The CMS code is a mess. The
Framework code is not perfect, but is better and has the potential to
be even better still. The Framework, therefore, is the better place to
start reform. The CMS is too hard to solve all at once. The Framework
allows problems to be divided into smaller parts.

> The CMS
> should want to use the FW, not be forced.

My view is there is no point in having a separate Framework Team if
Joomla is not using it. The CMS should have the freedom to choose what
it likes, but if it is not using any of the Framework, the notion of a
"Joomla Framework" needs to be disbanded. Seriously - what sort of
image does it portray when two parts of the same project don't use
each others code. That's just silly.

> And theres the problem. Everybody
> is speaking about different teams like they are competing companies.

Different departments of a company. This is very familiar to anyone
how does work in any organisation of any size. For developers that
work on their own, I will grant you it's unfamiliar territory.

> Sure,
> there has to be someone in charge. Not to rule the world, but to be a
> contact with an overview and the ability to show directions.

Shouldn't the Framework Team be the first point of contact when the
CMS has a problem it is struggling to solve? If not, why are we even
here? Doesn't it make sense to divide up the work load of producing
the CMS? Maybe I'm the only person that sees it this way, but there
are different problems to solve when thinking about core libraries as
compared to end-features that might be in an extension. You simply
can't discuss deep architectural issues on the same forum as end-user
features. The users just panic because they a) don't understand what
the developers are talking about, and b) they panic because they don't
understand what the developers are talking about.

And why is the Framework Team considered them-and-us but not the JBS?
Makes no sense.

Regards,
Andrew Eddie

[Andrew Eddie]

OK, here's an alternative purpose or mission statement:

The Joomla Framework Team consists of a group of highly motivated developers,
passionate about developing modular code to best-practices,
who want to make their contributions available to every developer in
the world,
and serve the Joomla software products to the best of their ability.

Regards,
Andrew Eddie

[Nils Rückmann]

Am Freitag, 22. Mai 2015 04:29:38 UTC+2 schrieb Andrew Eddie:

No, that's not exactly the intention, but there is the idea that the
Framework team has a duty to strongly guide the architecture of any
product the Joomla project produces. As I've said before, if the
Framework team is just under the Joomla banner for the advertising
benefits only, it's a waste of time.

> I think pulling is more productive than pushing.

It depends. My observation is simply this. The CMS code is a mess. The
Framework code is not perfect, but is better and has the potential to
be even better still. The Framework, therefore, is the better place to
start reform. The CMS is too hard to solve all at once. The Framework
allows problems to be divided into smaller parts.

Can't argue with that.

 

My view is there is no point in having a separate Framework Team if
Joomla is not using it. The CMS should have the freedom to choose what
it likes, but if it is not using any of the Framework, the notion of a
"Joomla Framework" needs to be disbanded. Seriously - what sort of
image does it portray when two parts of the same project don't use
each others code. That's just silly.

Maybe there's a misunderstanding. I meant that the FW should not force the CMS. Of course, the CMS should use 

the FW. Let's take an example: The FW evolves, creating new packages and so on, no one cares, everything is fine. 

Now there is a feature request or whatever which brings the CMS in a situation where it's not satisfied with the current implementation. 

Instead of saying "Well, it's your problem. The FW does everything right", the CMS and FW should share thoughts. 

Maybe, the CMS 

- has just doesn't understand how to use the package. Then the FW needs to explain it and/or improve the documentation.

- has a real new feature request. Then the FW should find a solution.

Different departments of a company. This is very familiar to anyone
how does work in any organisation of any size. For developers that
work on their own, I will grant you it's unfamiliar territory.

Well, there's a difference between healthy competition within one company and a destructive battleground within Joomla ;)

Especially if people could be interested in more than one group.

Shouldn't the Framework Team be the first point of contact when the
CMS has a problem it is struggling to solve? If not, why are we even
here? Doesn't it make sense to divide up the work load of producing
the CMS? Maybe I'm the only person that sees it this way, but there
are different problems to solve when thinking about core libraries as
compared to end-features that might be in an extension. You simply
can't discuss deep architectural issues on the same forum as end-user
features. The users just panic because they a) don't understand what
the developers are talking about, and b) they panic because they don't
understand what the developers are talking about.

 

Your absolutely right, an architect can not discuss every technical details with a principal. 

But a good architect should always be able to explain the himself.

 

And why is the Framework Team considered them-and-us but not the JBS?
Makes no sense.

Politics, i guess ? ;) 

[Andrew Eddie]

> Maybe there's a misunderstanding. I meant that the FW should not force the
> CMS. Of course, the CMS should use
> the FW. Let's take an example: The FW evolves, creating new packages and so
> on, no one cares, everything is fine.
> Now there is a feature request or whatever which brings the CMS in a
> situation where it's not satisfied with the current implementation.
> Instead of saying "Well, it's your problem. The FW does everything right",
> the CMS and FW should share thoughts.
> Maybe, the CMS
> - has just doesn't understand how to use the package. Then the FW needs to
> explain it and/or improve the documentation.
> - has a real new feature request. Then the FW should find a solution.

+1000 that's exactly how it should happen.

Regards,
Andrew Eddie

[piotr_cz]

IMHO the Joomla Framework mission should be to prepare and take care of the infrastructure for new CMS. Just like other projects (Laravel/ Symfony/ Pagekit) have a Framework/ Foundation repo and application repo.

New CMS should be designed with all Joomla teams, because market has changed since Joomla 1.0 and 1.5.

I've written few apps using JF, but after last GPL drama I went to research modern trends and alternatives and I don't see a point of coming back to JF as it is now. Everything that JF can offer is already available somewhere else, but few generations away.

I'm sure other people here have same experience.

And yes, I'm for starting from scratch and providing a migration tool because little itinerations haven't got us anywhere and we are stuck in legacy code.