Framework team meeting minutes 2017-02-21

Announcements Minutes of Teams and Foundation Board
#1

Attendees

Johannes Raggam
Eric Steele
Gil Forcada
Franco Pelligrini
Jens Klein
Ramon Navarro Bosch
Philip Bauer
Eric Bréhault

#Topics
##PLIPs

###Simplify the Resource Registry

The RR needs more documentation.
We are opened to more precise PLIPs.

###collective.indexing
CMFCore PR is ready to be merged. Eric Steele merged it during the meeting.

##Plone 5.1
To be released this week!

##Plone 6
By itself Python 3 support is not a feature, we need new features in Plone 6. The REST API could be merged in core in Plone 6.
Mosaic is also a possibility but it involves to change a lot of things in the core (do we really want to support tiles AND preserve viewlets and portlets?), so maybe it should not be merged yet and wait for Plone 7.
We want more releases more often.

The Plone 6 scope might be discussed at PLOG.

#Next meeting

Next FWT meeting is in two weeks (2017-03-07).

2 Likes
#2

Wow. Do we really want to change the core from a UI that the rest of world finds clunky and inflexible and only we understand to something every other CMS has or is getting?
Yes. We do. Plone 6 is already too late possibly.
Why the hesitation?

1 Like
#3

AFAIK All of this can be shipped with 5.2, mosaic just cannot be enabled by default?
Enable mosaic in 6 and use tiles for Plone core UI. Remove portlets/viewlets support in 7.
-or- ship with 5.2, enable by default in 5.3, rewrite portlets and viewlets to tiles in 5.4. Remove portets/viewslets support in 6

collective.indexing actually shifts -for the better- when data is indexed (on transaction, not on creation), but would imho require a major version change as the expectance of the working of APIs will change.
plone.api.content.find -please correct me if I'm wrong- will not find the created content until after the transaction.

Please comment :kissing_closed_eyes:

#4

I smell FUD here...

why the hurry? we're still fixing the huge mistakes made on Plone 5: resource registries and toolbar.

if we only have to learn one thing it should be this: revolutionary changes in software are dangerous, especially on a community with so limited resources like ours:

  • Mosaic is not mature enough to be included in the core
  • removing portlets and viewlets must have a clear deprecation and migration path

almost 4 years ago I said the following regarding Plone 5, and it still applies for Plone 6 and so on:

Festina lente or, as the great philosopher Dolly Parton used to say, I'm gonna hurry just, just as slow as I can...

our roadmap must not be driven by technology changes only core developers understand.

#5

@hvelarde To be fair, IMO, your RR critiques feel like FUD. Upon further review from the framework team, they seemed agree it was partly specious.

FWIW, apart from a new born child at home, one of the reasons I haven't worked much on Plone core lately is because I felt like some of us were pulling everyone else along with the JS story while the rest of the community resisted or didn't care.

Our clients need advanced interactive UI which often requires advanced JavaScript technologies to manage the complexity. This is where the web is at. Ramon and I tried to merge the widgets developed with mockup/patternslib with Plone, while having a TTW story. We made mistakes. Other CMS systems haven't been able to manage this well either. But constantly trying to tug everyone else around and have many in the community not be satisfied anyways is draining. We even took our time to prepare and hold free training. Docs for the training are there to do every use-case we could think of.

Also...

One of the more odd critiques of the framework team over the years is they aren't the ones who should be deciding what goes into Plone--that they don't understand what real users want. I find this completely absurd. To me, what I really hear is that "I don't like these features" or "these aren't the features I would let in." But suggesting that developers put these features into Plone for no or bad reasons is a terrible argument. As far as I know, PLIPs that have been integrated were developed because people saw real world need from clients for them. It's not as if all these engineers do all this work for no reason or to make your life more difficult--they have clients they need to service and feel these changes will help them to it.

4 Likes
#6

ok. here is one story.
There exists a big non profit that put a lot of money into plone, or rather a plone integrator (not us, another one that is pretty much of business now). We inherrited them as a client and they told us of their frustrations with Plone. Namely in boiled down to what they considered simple layout changes to pages would cost a lot and take a lot of time. Because they had to hand coded and deployed. The site was designed with lots of templates.
When we inherited them they told us they would go out to tender for a new CMS. When we got the tender it contains a lot of stuff including stuff that plone does well like multitenented, multi-lingual etc. But here are some direct quotes from this tender

Content Editing - Page templates within the current CMS (Plone) implementation are
restrictive. Content editors should be able to move components around the page.
Privileged users should also be able to change the layout of pages directly in the CMS
(without developer support).

Yes this is just one datapoint. But it shows that even a company which 4 huge plone websites is willing to spend a lot of money to solve this problem.

Another datapoint is FBI and castleCMS. Luckily in that case they trusted the supplier to upgrade Plone to create CastleCMS which simplifies Plone content creation while allowing content authors more control over layout, via mosaic.

Losing existing Plone installs however is small fry compared the the slow uptake on new installs to Plone. The answer to that question is asking yourself, would you recommend Plone to someone wanting a website? Would you recommend Plone to even a new developer, who can code some html and css, and has to put together a website others in their company have to edit?

If you are like me and the answer when being honest is "no there are few people I know I could recommend plone to"... then there is the answer to slow growth, the companies running out of clients and the community slowing down.

Next question is, is Python 3, simpler resource registry and improved toolbar enough to allow you to recommend plone? These things need to be fixed I agree but I don't think they are enough and I actually don't think they are as important. I think we need most of whats in castle CMS + rapido (to write custom code without having to get dirty in plone enterprise code) and then we could have a CMS we can recommend.

I wish I could find the actual quote but I'm pretty sure it was from Nick Coghlan in response to Alex Gaynor's criticism of Python 3's disruptive changes (back in 2013).

We designed it (python 3) for the users we want, rather than the users we have

To me this is the heart of the decision. Do we design Plone 6 for the current community making incremental changes which make less work for current developers who can navigate the complexity, or do we put our effort into something that makes new developers come to us?

1 Like
#7

congratulations on your new born, Nathan; enjoy your time and take some rest: you deserve it.

I tried my best to make my point on the resource registry PLIP but, obviously, I failed; it's not easy, you already know it.

the problem is not we're resisting or we don't care; I know many people here agree with me (they told me that in Boston) but seems very few want to talk about it loud and clear.

with fewer people discussing is more difficult to make a point and to reorientate our efforts. sadly, I don't think that is going to change in the near future.

I insist: is not the framework team the one that should decide what must go into Plone, neither what feature we should add; that must be the work of a non-existent marketing team; I have said this many times in the past and I'm going to repeat it as many times as needed.

the framework team should decide how to better implement those features into the core: no more, but no less than that.

anyway, you saying other CMS systems haven't been able to manage this well either (the JS story), just reinforce my view that we made a mistake: better to wait and see what works.

#8

this is exactly what I'm talking about: a marketing team should be able to discuss with you and your customer and find out what are the improvements we need to satisfy real world requirements.

that process must be done incrementally with good planning and feedback, first as add-ons (like Dexterity or Mosaic), to allow people test in real world scenarios the solutions we are proving; when those solutions are mature enough, we can think on including them on the core, not before.

this process has the advantage of being easier and faster, as it doesn't involve all the inconveniences that play against releasing with Plone as a product; more or less the same we had with Dexterity that was available for a couple of years (since Plone 4.1, IIRC) before being part of the core and, finally, become the default content types framework on Plone 5.

so, why are those people not present on the conferences, for instance? they are the ones that should be deciding the new features, not the framework team.

why don't you invite your customer to Sorrento to discuss about the future of Plone?

having said that I have to add that I'm quite happy with Plone and I recommend it to everybody that needs a medium to large website; I don't want to replace WordPress and I'm totally fine with that: we have many, many sites running Plone over here in the Government and, sadly, I'm not going to recommend upgrades until we have a good reason for that.

Plone 6 seems to be a good reason, because it will provide backend enhancements worthing the move (Python 3 support is a matter of life or death) and maybe one or two good UI enhancements.

on the other side, for us, that was never the case with Plone 5, and I have said that many times in the past: I don't have requirements for fancy frontends made with JS (at least, not yet) and I can have all the other goodies without the headaches of a bad designed toolbar or buggy resource registry.

our customers want a CMS that works, fast, reliable and securely; Plone 4.3 gives me that, period. I can build the features they want on top of that and I've been doing that for years now.

we have different views, Dylan: you seem to think that people will come here to work with Plone in hordes if we do this or that; I don't see that happening in my lifetime.

Plone and Zope are boring and, again, I'm totally fine with that: it pay the bills doing a pretty decent job; does that means I don't care? no; can it be better? yes, of course.

resuming, we have different markets, requirements, and points of view; you should accept and respect that, and discuss and listen more, to avoid playing against the rest of us.

good night and good luck!

#9

I closed the PLIP last week because I felt you guys were not willing to discuss this further or fix it in any way; the resume you just posted continues to give me that impression.

AFAIK, the function of the resource registry is to handle static resource inclusion and minimize the number of requests to build a web page; this, site wide resource bundling, is what I feel overrated, overly complex, over-engineered, buggy, and resource consuming: that is what I think we must fix ASAP.

if you agree with me in this, let me know and I'll do my best to write a new PLIP.

if not, just remove it from your list of pending stuff so you can have one less thing to discuss in the next meeting.

#10

Because it implies a lot of changes in the core and it will impact how add-ons are built (anything involving viewlets or portlets will need a rewrite). We don't think we can manage that in short term and we plan to release Plone 6 soon (remember: we have switched to semantic versionning, so we expect major versions more often but with less major/breaking changes).

1 Like
#11

I agree with you. Be aware @thet is re-writing his PLIP about static resources management https://github.com/plone/Products.CMFPlone/issues/1653
As you know, I have also a PLIP to implement regarding LESS variables https://github.com/plone/Products.CMFPlone/issues/1677
We are ready to work on those subjects, any help is welcome and the discussion is opened.

#12

You and I don't have different markets Hector. I do government same as you. I have plenty of happy customers and I also know how to customise Plone to give them what they want.
My point is that we need to NOT be looking at the happy well paying customers we have now or how happy we are with existing versions of Plone but who is getting the new customers now. Why are people not picking Plone. Watch these videos to understand what I mean.

Vid 1 Vid 2

Plone isn't a corporation that makes a profit but growth of open source ecosystems means surplus volunteers which moves the project forward.

If people aren't going to come in hordes to Plone then we might as well shut up shop now I believe. We have a big code base, it takes a lot to maintain. You will be getting more and more annoyed about bugs not being fixed because the ecosystem that supplies core developers will have dried up.

I can't even afford the time and money to go Sorrento, let alone someone who hates Plone. They also picked another CMS, despite our best efforts to show them that Plone was changing. Besides, asking customers to tell us how to build a better product is also a bad idea as I posted about yesterday. If you train users or handle 1st tier support for users of Plone, you know the problems. (just 2 days ago I had to do another emergency undo because a major transport site accidentally clicked on the display menu).
In addition Sorrento is advertised as being about headless CMS which I see as a likely a deadend just like plone intranet was. It solves a problem very technical people that they already have existing light weight solutions they will prefer like wagtail. Developers are an incredibly fickle customer base to try and please. Python developers even more so. Building a less shitty, more secure, easier to customise wordpress however I think is possible but I'd like to hear other ideas on what is going to grow Plone or disrupt CMS (perhaps not from the same people)

#13

plone.api.content.find should find the newly added content. The portal_catalog tool explicitly calls processQueue. Coolio!

#14

Mosaic really improves the Plone story... A friend who draws wanted to have a web site to showcase her work and bring in new business. I started trying to get her interested in Wordpress, but then I showed her Plone+Mosaic (and she quite liked one of the themes @vicodin made last year), and that's what she's going with. When people see how THEY can drag tiles around to make whatever layout they want, it seals the deal, as @calvinhp would say pithily... so in a multi-site hosted environment, Plone+Mosaic is (I think) quite suited to simple/small sites.

1 Like
#15

@tkimnguyen awesome. These are the stories we need to hear more of. And also ask her what she found most confusing.
Maybe we need some meme/forum for sharing new user stories?

#16

Well, no final release, but the first beta release. :slight_smile:

I hope the Retina image scales PLIP can still be included in a beta release. It has been ready for half a year, waiting for the final reviews. Parts of it have been merged this week, so there is progress.

1 Like
#17

Sure, I'll ask eventually.

I dunno - I think what really needs to happen is for people to stop bitching and moaning. (All right: some b&m'ing is fine then let's get the work under way). Here's my boiled down world view: Plone 5 is really nice! Mosaic is fantastic! Nothing is perfect. Let's keep improving it.

3 Likes
#18

Deco/Mosaic has been floating around for over 7 years now. It was needed then, and It is needed NOW.

We have hundreds of active users editing content yet they have to rely on me all the time so I can edit the HTML or create PageTemplates that layout the information the way they want it.

We are moving to CastleCMS and have been testing it for a few months now. Based on my experience as a user, integrator, designer and simple web app builder, CastleCMS, is simple, flexible, powerful, and has a great UX.

Plone 5 is really nice! Mosaic is fantastic! CastleCMS is awesome!! (and nearly perfect). CastleCMS should be Plone6 and the effort should be on making the migration/upgrade smooth. (I have been thru a few Plone Migrations since 2.something, always a pain in the ...)

1 Like
#19

@munez That's great feedback. It would be useful to know which of he castle improvements make the most impact, compared to plain plone, and which perhaps aren't needed?

For example, how it does content creation differently from plone?

Have you got to the stage of testing it with non technical users?

I looked briefly at how castle is put together and I think it's not going to be as simple just making the current code core. I think the way it brings all the enhancements together that couldn't go in the core (like elasticsearch, s3, video, new toolbar) is all glued together in a non-optional way. They aren't all plugins that can just be excluded.
So it would be more a case of taking some of its UX ideas and reimplementing in a way that generic plone, castle (and hopefully plone intranet) can all make use of. @vangheem?

#20

I have to agree with the framework team analysis about Mosaic.

Because we failed the promised Deco revolution in Plone 5, we had to refactor Mosaic default tiles (plone.app.standardtiles) to re-use maintained viewlet code to avoid maintaining two versions of the same thing. Refactoring viewlets and tiles to use the same code without tiles depending on viewlets would require significant extra effort (without clear gain).

Mosaic pages with a lot of tiles have performance issues with subrequest-based tile composition. Deco proposed fix was ESI. Castle CMS uses its own multiadapter lookup based transform to coup with the same issue.

Then there's the issue of replacing TAL main_template based layouts themed with Diazo with (optionally) themed HTML site layouts. I understood, that Castle CMS uses themed site layouts without Diazo-theming.

Mosaic editor is outdated in many ways and some its current implementation as a widget pattern on top of edit form could be considered a hack (although a one hard to refactor without complete rewrite).

Finally, Mosaic may be already too little too late. Deco / Mosaic stack is built for composing page from server rendered HTML fragments, which may be seen outdated approach. Another wildcard is CSS grid: http://caniuse.com/#feat=css-grid which makes it possible reorder layout to some degree in pure CSS.