Hello @here! This is time for a new product team meeting 
If you haven’t done an asynchronous meeting before, please respond in threads 
Also note you can start a reply with 
to be anon, or 
to go off the record and not be included in the notes, which will be exported and saved to Google Docs, and posted on the Community Forums.
The meeting will be open for 24 hours, after which the notes will be exported. People may comment thereafter but these won’t be included in the notes.
Let’s get going! 
Introductions - Who are you, where are you based, and how are you involved with this team?
| Norman Pracht |
I’m Norman, product team lead and i’m here to :
1. Help you getting involved in mautic community. If you have any question about how to help, feel free i’m glad to get your energy in this awesome project
2. Help the product team to move forward with the amazing help of Ruth that leads mautic project. Objective : insure mautic development, manage to integrate contributions, make mautic reliable and sustainable, add new feature by listening the community wishes |
| Proffalken (he/him) |
I'm Matt, UK-based, and I've been talkng to @Ruth Cheesley (she/her) and @Dennis Ameling (he/him) about how I might be able to help with the infrastructure side of things as that's where my background lies |
| Norman Pracht |
Excellent ! Thanks a lot Matt for offering your help on a skill domain we may have a lack today ! |
| Ruth Cheesley (she/her) |
Hey all, based in the (:rain_cloud: and :dash: ) UK. Here to support the product team in whatever way I can and get things moving like a well oiled machine! :tada: |
| Norman Pracht |
I also want to give a special thank you to @Abu Musa and @mohit.aghera that recently joined the team and are doing an excellent work for the community. |
| Dennis Ameling (he/him) |
Dennis here, based in NL, assisting the product team mainly with getting through the backlog of PRs :slightly_smiling_face: |
| Jordan Ryan (Facet Interactive) |
Jordan here, based in California. We're doing a lot of active development with Mautic 2.x right now and looking forward to upgrading to 3.x soon. |
| Norman Pracht |
Hi @Jordan Ryan (Facet Interactive) ! Nice to see you around. Any chance to have you involved in the process for 3.1.1 as tester or code contributor ? |
| Jordan Ryan (Facet Interactive) |
@Norman Pracht - once we're ready to make the jump to 3.x. we're getting closer. Right now we're finishing up some work on a mautic-k8s cluster / helm chart. Once that is done I can spin up 3.x inside of a pod and take it for a spin. |
| mohit.aghera |
Thanks @Norman Pracht I appreciate that. |
1️⃣ Review last meeting’s notes and actions (Share a link to the notes in a threaded reply, and call out any actions as sub tasks)
| Norman Pracht |
Notes are here (cc @Ruth Cheesley (she/her)): |
| Ruth Cheesley (she/her) |
https://forum.mautic.org/t/meeting-notes-tuesday-28th-july/15801 sorry it took so long, our scraper tool seemed to miss a bunch of stuff and I had to convert it to markdown :sweat_smile: |
1️⃣ . :one: - TPROD-24 Use a bot for CLA’s :white_check_mark:
| Ruth Cheesley (she/her) |
Thanks to @Abu Musa for help figuring out why this wasn’t working - it didn’t have the right access to the repo :slightly_smiling_face: |
1️⃣ . 2️⃣ - TPROD-18 Create a triage team :large_orange_diamond:
| Norman Pracht |
Still ongoing in Jira. @Ruth Cheesley (she/her) i believe we have done some last time.I think any well trained user can join this team. You just need to have a good understanding on how works the software to be able to :Reproduce or not issuesDefine if it is technical or not, major or not, regression or not. |
| Norman Pracht |
I’m glad to be in that team @Ruth Cheesley (she/her), how do you want to start ? |
| Ruth Cheesley (she/her) |
I’ve created the team in Github - we need folk who are willing to spend time regularly triaging the issues and pull requests (could be two separate groups of people, or the same group).So to start with I guess just agreeing when we are going to do the triage process. I’d prefer if we all set a time to work through stuff together on say a weekly basis, then if folk have time outside that great, but we’d know that there’s a timeblock where we’ll blast through issues and PR’s that need attention. |
| Ruth Cheesley (she/her) |
https://github.com/orgs/mautic/teams/triage-team here is the team |
| Ruth Cheesley (she/her) |
I’ve also got an open project with the infrastructure team to help me get Triage Party up and running so we can use that to quickly identify what needs attention, where we’ve had replies to requests for information, and so forth. |
1️⃣ . 3️⃣ - TPROD-6 3.1 Triage (tied in with TPROD-47 Define 3.1.0 milestone) :white_check_mark: (edited)
| Norman Pracht |
Again @Dennis Ameling (he/him) has been doing an amazing work to deliver mautic 3.1.0 on time this monday --> https://github.com/mautic/mautic/releases/tag/3.1.0 (edited) |
1️⃣ . 4️⃣ - TPROD-4 Clearing up 2.x legacy issues/PR’s in Github :large_orange_diamond:
| Norman Pracht |
I’m not done yet, I’ll try to get rid of this before next team product meeting. But as mentioned Ruth, we’ve been doing some good work already. |
| Norman Pracht |
We now have less than 350 issues, half of the amount at the beginning of the year :rocket: |
| Ruth Cheesley (she/her) |
Yes, we have had to give people time to respond, but I think now that we just close things if there is no response within 14 days. We can always reverse that decision and re-open if the author comes back to us, or the issue comes up and the PR is still relevant. |
| Ruth Cheesley (she/her) |
Also when we publish the new code governance it explicitly states there about the 14 day period - so we can point at that for reference. |
| Norman Pracht |
Perfect |
It isn’t quite done. Here is the document, we have the :white_check_mark: from everybody who has been involved in writing it.Now we have the 3.1 release out of the way it needs to be published online and we need to then adopt it.I think we’re going to pop it up on the blog, and on contribute.Mautic.org. Maybe also needs to go in contributing.md or at least there should be a link to it.
| Ruth Cheesley (she/her) |
Done - article is now live |
| Ruth Cheesley (she/her) |
https://github.com/mautic/mautic-community-handbook/pull/22 PR to update the community handbook |
| Norman Pracht |
:+1: |
| Dennis Ameling (he/him) |
Awesome thanks!! |
@Ruth Cheesley (she/her) i’m sorry to be chasing with that, but any chance to have a newsletter in the coming days to announce this planning ?
| Ruth Cheesley (she/her) |
We are in progress with the marketing team. If anyone wants to jump in and help with those tasks you can. We have to set up a GDPR re-consenting process, set up the drip flow for new downloaders, and set up the segmentation. We also need a newsletter template. Marketing Jira board is here. We have very few contributors and those we do have are spread very thinly. More folk helping would be much appreciated. |
| Ruth Cheesley (she/her) |
(I only have so many hours in the day, sadly!) |
| john |
I’d suggest to keep pushing on feature PRs as well as bug PRs. The new branching strategy allows us to build bug fix versions and feature versions independently on each other. |
| Norman Pracht |
We still have a lot of work on this and this is an everyday work. Next release is 3.1.1 in 1 month and we should try to merge as much pending PRs as possible that fixes bugs. I’m sure we can reduce the amount of pending PRs by 30. |
| Norman Pracht |
I’ll write a message in the different channels to announce the planning for 3.1.1 and ask people contributions :slightly_smiling_face: |
| Norman Pracht |
DONE in #community, #mautic-3, #dev (edited) |
| Ruth Cheesley (she/her) |
I think if we can keep up the momentum with testing, triaging, and updating old PR’s we should get through them. It’s better to try to do that than have a mad dash at the end of the month. Also makes it easier for developers as they get notified earlier to fix issues/write tests/etc. |
1️⃣ . 7️⃣ - TPROD-19 Look into CCPA and determine if Mautic needs to do anything to ensure compliance (comes into force 1 July) :white_check_mark: (edited)
1️⃣ . 8️⃣ - TPROD-2 Remove retired contributors from admin rights to repositories :white_check_mark:
1️⃣ . 9️⃣ - TPROD-24 Use a bot for CLA’s :white_check_mark:
2️⃣ Review progress on Jira sprint (edited)
| Norman Pracht |
https://mautic.atlassian.net/secure/RapidBoard.jspa?rapidView=15&projectKey=TPROD&selectedIssue=TPROD-19 |
| Norman Pracht |
An amazing work has been done recently and many ToDo are now done |
| Norman Pracht |
I’d like to add few topics |
Issue is there : https://github.com/mautic/mautic/issues/8471
| Norman Pracht |
As i always say, have nice feature is great,Having new features is coolHaving maintained feature is more than all of that, it is necessary for mautic community project. |
| Norman Pracht |
@Ruth Cheesley (she/her) would you agree adding a card in Jira for that to be sure we don’t miss it ? Any chance to have Acquia’s help on that one ? |
| Ruth Cheesley (she/her) |
I think we need to get it sorted, but there are no customers at Acquia who use it so it’s not on their radar |
| Norman Pracht |
I was thinking about the MAT |
| Norman Pracht |
But we can try to get community members involved in it ! |
| Ruth Cheesley (she/her) |
We don’t yet have a MAT. That is basically me. And I can’t fix that :slightly_smiling_face: |
Just came across your discussion and wanted to let you know that I absolutely agree with the argument, that we should decouple the plugins in the long run. Go in the direction of a WordPress style plugin ecosystem (hopefully with a bit more security).The Trello plugin was actually decoupled in the beginning, then when I decided to contribute it to the core I “coupled” it by renaming it to MauticTrelloBundle. The way I see it, in order to decouple it we would only need to rename it back to Idea2TrelloBundle. So it would not be a big deal to decouple it later.Just wanted to let you know. Maybe this helps with your decision. I can see merit in both arguments.
| Ruth Cheesley (she/her) |
So, taking in all of the decisions above with regards to including or not including additional plugins in core, I’ve decided that we should not at this time add any further plugins.I appreciate this means that the time and energy that @Adrian spent in getting the plugin up to speed based on earlier discussions has been in vain and I’m deeply sorry that it means we won’t be accepting the PR into core.I’d really recommend that if folk want to see an easier way for people to install plugins in Mautic that you consider helping us bring the marketplace to fruition (maybe for the 3.2 release in November) - it would be a huge boost for our plugin ecosystem and I believe would also drive more innovation from developers in the community as it makes it easier for folk to find their plugins.If you want to help with that, the plugin is here: https://github.com/mautic/mautic/pull/8257 and the forum discussion is here: https://forum.mautic.org/t/mautic-marketplace/12108/18 (edited) |
| Jordan Ryan (Facet Interactive) |
Sounds like some simple cost-benefit analysis for the plugin marketplace and browsing capabilities would be worthwhile. +1 Norman |
| Dennis Ameling (he/him) |
I agree that plugins should be decoupled from core. However you can't expect this in the current state when the Marketplace is not there yet like @Ruth Cheesley (she/her) mentioned. The Marketplace was on the roadmap back in March of this year but still isn't here for obvious reasons.If we really want to move forward with this, IMO the order of steps should be:Accept new contributions like the Twilio plugin to core for the time being. Major benefit: they are already in separate bundles within core, so having them in one place will allow us to separate them into their own plugin packages later MUCH more easily. I am fully aware that this completely contradicts Norman's vision, but for the aforementioned reasons I wholeheartedly believe it will actually ease our migration process to separate plugins later on.Make the Marketplace our #1 prio for the coming months (after the PR backlog is cleaned up) as I expect it will increase traction around Mautic as a product ("Look! You can install plugins into Mautic as easily as in WordPress!") and will very likely cause a boost in community engagement.Then, zooming in at the Marketplace itself, I see the following as absolute prerequisites for success (but let's leave that up for further discussion later on I guess):Compatibility checks with new versions of Mautic (you can't update Mautic until a plugin is proven to be compatible, or you'll need to disable it)Browsing capabilities like @Jordan Ryan (Facet Interactive) mentioned: installing a plugin should be possible from within Mautic's UI with the click of a buttonAn official library where all of those plugins are stored, similar to what WordPress is doing https://wordpress.org/plugins/I think there should be at least 2-3 developers working on the Marketplace together with some CI/infra expert, as a single person can't do all the work for such a major project. It will very likely involve setting up a separate project team that will work on it for a certain period of time, ideally with a focus just on the Marketplace and not any other areas of Mautic.I think the only way to really get this done is if major contributors like Acquia and/or Webmecanik are willing to dedicate resources to the Marketplace for multiple weeks/months. (edited) |
| Jordan Ryan (Facet Interactive) |
I would point out that composer-based installs also solves this problem, as you make it much easier for individuals to add a plugin and build their Mautic instance as they see fit. |
| Jordan Ryan (Facet Interactive) |
Additionally, wouldn't it be a good short-term goal to simply have the plugin marketplace on mautic.org without the ability to embed it into Mautic application just yet? People can figure out how to install it just fine, but there isn't a place to browse all plugins. Right now you have to search github. This would require less of a full-time commitment from sponsors and could be a good milestone. |
| Ruth Cheesley (she/her) |
https://forum.mautic.org/t/mautic-marketplace/12108/18 here’s where we’re at with the work on the marketplace by @john to date. WIP PR is here: https://github.com/mautic/mautic/pull/8257Right now there is Mautic.org/marketplace, FYI. It’s manual, but it is there. |
| Ruth Cheesley (she/her) |
The WIP is using a composer-based approach |
| Jordan Ryan (Facet Interactive) |
Should there be a process for asking new plugin submissions to be submitted there, first? |
| Jordan Ryan (Facet Interactive) |
@Ruth Cheesley (she/her) there should also probably be another dimension to this table to give the plugin a checkmark if it's 3.x compatible or pending testing |
| Jordan Ryan (Facet Interactive) |
and regarding the updatability of this report, an embedded AirTable + Typeform for new submissions would probably solve that... |
| Ruth Cheesley (she/her) |
The process for plugins to be added to the list on https://www.mautic.org is currently manual (e.g. just drop me a message with the Github repo) |
| Ruth Cheesley (she/her) |
airtable could be an option but that comes with a cost (I do have an airtable project that I use for the community but pay myself to manage - but I couldn’t add other contributors without it costing more) |
| Ruth Cheesley (she/her) |
tbh I’d rather we focused attention on building out a proper marketplace than implementing new solutions for the existing page. |
| Norman Pracht |
I disagree with you Dennis. For the time being where is the value of adding in core a plugin use by less than 20% of users (and it is probably even less)?We should better find a way to highlight the available plugins by listing public repos on the website or plugins with zips as done today.You’ll say we need a UI to install it. I agree but today you already need technical à skills to handle your mautic, so if installing a plugin needs a dev, that could be acceptable.I very don’t see the logic of adding something we know that we want to take out later and that will be in majority unused.We better work on a outside space better highlighted than today. |
| Norman Pracht |
I don’t know how we can conclude on this. Obviously none convinced none.So Ruth, I believe this is the moment where the decision is yours ? :) |
| john |
I agree with Norman and Ruth. We need lean core and a marketplace with 1 button install. We now have to maintain a lot of code that is used by several individuals and it keeps us developing code that would be useful for the majority of users. The PR Ruth linked above is doing that. I uses Composer’s Packagist.org library of PHP packages to load Mautic plugins into the UI. The UI is there. It just need some polishing from a UI/UX expert. The 1 button install is there as well. But there are 2 unresolved issues:1. Composer is slow for HTTP requests. I added checks that will compute estimated time and will not allow to install until a PHP timeout limit will be raised so the users wouldn’t shoot themselves in the foot with installations shut down half way. Possible solution - Composer2 is much faster.2. Plugin dependencies. This is the most confusing part. Should the plugin dependencies be added to Mautic dependencies? Or should they be autoloaded separately? What should be done when there are plugin dependencies installed and then you’d want to upgrade Mautic with some new dependencies? It would be helpful if Mautic could be installed with Composer and not by zip packages. This is where I got stuck. There are other community members doing their Composer magic. (edited) |
| Jordan Ryan (Facet Interactive) |
We have a working composer build in 2.x @john and I'd be happy to take a look at this once we upgrade to 3.x.It requires you're on an environment that can build with composer though, so the whole idea of a plugin marketplace is moot for those who have this capability. If you're working with composer you would just add it at the composer.json in the root. Our approach is similar to mautic-eb approach... |
| Jordan Ryan (Facet Interactive) |
Honestly all of this talk about composer loading dependencies separately reminds me of the composer_manager project in Drupal 7, where utilities installed through the UI would install a vendor library that was separate from the root vendor directory.... IMO this complicates troubleshooting applications immensely and it is more valuable to make plugins first class citizens of the root composer.json |
| Jordan Ryan (Facet Interactive) |
@Ruth Cheesley (she/her) - my short-term suggestion is simply to include the instructions for submitting the plugins to the list inside of the GitHub Pull Request template. That way we notify people at the time of PR where to go to submit this information. Your points on AirTable vs. manual were my concerns as well, I just wanted to suggest more visibility for those who are actively contributing. :slightly_smiling_face: |
| john |
Composer is a PHP library installable by Composer. So the marketplace PR adds it to the dependencies and it will work everywhere |
3️⃣ - Any other business - feel free to add below! :arrow_down:
I think I forgot another topic as 2️⃣ . 3️⃣ - handle vulnerabilities pending on Mautic/Mautic repo ?
| Dennis Ameling (he/him) |
I think you're specifically talking about the NPM packages that need updates, or also Composer packages? I'll update the NPM packages in the coming days, should only be a few mins to do as I believe we're not (heavily?) using any of those currently.Moving forward, can we please configure dependabot to automatically create PRs for this (it already does for Composer dependencies AFAIK). cc @Ruth Cheesley (she/her) |
| Ruth Cheesley (she/her) |
I will turn on the dependabot alerts for all repos |
| Ruth Cheesley (she/her) |
Done :white_check_mark: |
Participants:
Norman Pracht, Dennis Ameling (he/him), Jordan Ryan (Facet Interactive), mohit.aghera, Proffalken (he/him), Ruth Cheesley (she/her), john
1 Like