Triage to check if there are any other issues outstanding (All)
Estimate all issues for the 3.3 release (time to fix) (All)
Assign the issues to people who will work on them (Alex / Adrian / Ruth)
Create a funding proposal if needed (requires all tasks estimated and clear deliverables) - we can count on the $1000 from the community funds, and would need to fundraise anything further
The main Confluence page has been updated to reflect the decisions and discussions that we have been having.
Ruth has discussed with @Alex Hammerschmied about the need to review the outstanding issues and how long these will take
We need to implement the PR to core to include the builder as an optional plugin, as well as to fix the plugin issues
@Jozsef Keller asked how we will provide the new templates which will support the new builder. We had a discussion on how to determine which templates support which builders
@Alan Hartless shared that Acquia has developed the ability to only show templates which are compatible with the builder. That way we could ship the templates with Core and the template would define what builder it works with in the config. So GrapeJS templates would only show up if the builder is included, and would assume that anything that does not have anything specified that it is a legacy template.
We discussed that this would mean all templates shipping as core even if GrapeJS is not being used which could be bloating the install, however in 3 months GrapeJS will be the default so it will not be an issue, only for the next few months. So templates will be made as a PR to core
We talked about how the plugin is going to be shipped - it would be pulled in from the Github plugin via Composer / build process as a plugin which is not enabled by default.
Alan will formalise what they have done at Acquia for the templates getting hidden and will get the PR made by Monday - timeline wise it would need to be PR’d and tested before 12-13 Feb. Release Candidate 14th Feb, 22 Feb General Availability
We have 11 issues open that need to be resolved before release - waiting on @Alex Hammerschmied for feedback
The repo has now been moved over to the Mautic Github organisation (thank you @Norman Pracht (Unlicensed)@Zdeno Kuzmany and Webmecanik!) and can be found at https://github.com/mautic/plugin-grapesjs-builder
Hopefully when we make the PR it will enable us to test the new builder on Mautibox - we can also test new themes there as well
We do need to test the builder now to make sure we have reported all the bugs
Do we assume that all templates are compatible with GrapeJS and that GrapeJS templates can be used by the legacy builder, or not? @Adrian Schimpf suggested that there must be something to take care of this already - we should test and also ask @Norman Pracht (Unlicensed) and @Zdeno Kuzmany
Let’s post a decision on Confluence for folk to discuss and review - @Alan Hartless will do this
@Andre Beherzig shared that he has installed this with clients and did not have many issues but also raised that it would be helpful if we were able to set permissions to restrict elements of the editor - for example to make it less cluttered but also if you have brands who are not allowing the changing of some features such as template settings, colours, etc. We raised that as an issue for consideration in a later stage https://github.com/mautic/plugin-grapesjs-builder/issues/39 - we may look at whether GrapeJS has any plugins that would do this
We also discussed that we may in the future want to have the option to allow template creators to have blocks that are reused but come from one central location - for example footers where the date needs updating or another logo to be added, so that you do not have to edit every single email/landing page. https://github.com/mautic/plugin-grapesjs-builder/issues/40
If we do not hit the 3.3 release for the beta release of the plugin we would have to thoroughly test the builder and go straight to it being the core builder in 4.0 but this is a fallback plan and not ideal - we really should be aiming to hit the 3.3 milestone
We discussed that there is a budget of $1000 that can be used to pay for the initiative as announced in this blog post - and if we need more funds for future releases we can crowdfund through the Open Collective. We also talked more generally about the funding options that we have introduced
We also discussed that we are not really attracting new developers - we need to find ways to attract new developers. We do however need to get ourselves out there (outside of folk who already know about Mautic) and to do that we need the community to help with reaching out beyond our own community, and make it easy for those folk to get involved and contribute.
Action items
@Alex Hammerschmied to provide an update on task estimations, timeline for resolving and budget needed
@Alan Hartless to make a PR to core to allow templates to be hidden based on the active editor
@Alan Hartless to make a decision doc on Confluence about the template support detection
Decisions
New templates will be shipped to core
We will implement a way to show and hide templates based on the active editor