Jason Murphy, one of our home grown Plonistas, is growing in knowledge at a break-neck pace. His previous experience has been with Drupal. He greatly values robust tools for managing CMS projects and brings the ability to compare the two platforms after having significant experience with both. He made reference to Drush as a useful tool in the Drupal ecosystem but he found that it wasn't as comprehensive as the suite of tools offered for managing Plone sites. He pointed out that, due to Plone's buildout tool and profile configuration systems (like Generic Setup), it was possible to manage almost all aspects of a Plone deployment inside of revision management tools such as git. Being more of a software engineer, he included the disclaimer that he’s not really a web developer, but Plone inspires him to want to go down that path.
Areas where Plone can improve
I personally know that the documentation has grown in leaps and bounds, however, persons new to Plone still identify this as a pain point. Comments like “[the] documentation needs more direction” or “it needs to be organized by use case or domains (e.g. everything for a theme developer, everything for an integrator)” came up. I brought up my concern about the general lack of screenshots and diagrams in open source documentation and Plone documentation specifically. With respect to documentation there is more work to be done, my biggest take away was the following thought: “following an example is the best way to get going, but examples vary and may be based on old [no longer best practice] code”, my recent work on Plone drills is the first experiment towards fixing this.
It's hard to find add-ons because they're distributed all over the place and have non-intuitive names. A single index for Plone packages, and good metadata that can overcome the bad names.
Overall it was a very inspiring meeting and encouraging to meet others who were either actively using Plone or looking into it.