I’ve seen comments that the developers don’t frequent these forums, but are to be found on slack.
So, how do we as a community interact with them? I think to get a slack login one needs a mautic.org email address. I have no idea how one goes about getting one (and yes, I have looked - quite probably in the wrong places).
All these conversations around:
the intent of version releases (i.e. @abb’s thrust around X.Y.0 being new features and X.Y.1 through X.Y.9 being around stability and richness of features)
the notion of presenting real world use cases to the developers to focus areas of development
are all irrelevant if we don’t have developer buy in.
So - what is this really about? How do we get the buy in from the developers of Mautic as to our proposals. How do we thrash those proposals out with them, and get them (or some other mutually agreed approach) in play here?
All,
I’ve seen comments that the developers don’t frequent these forums, but are to be found on slack.
So, how do we as a community interact with them? I think to get a slack login one needs a mautic.org email address. I have no idea how one goes about getting one (and yes, I have looked - quite probably in the wrong places).
All these conversations around:
the intent of version releases (i.e. @abb’s thrust around X.Y.0 being new features and X.Y.1 through X.Y.9 being around stability and richness of features)
the notion of presenting real world use cases to the developers to focus areas of development
are all irrelevant if we don’t have developer buy in.
So - what is this really about? How do we get the buy in from the developers of Mautic as to our proposals. How do we thrash those proposals out with them, and get them (or some other mutually agreed approach) in play here?
Actually, you do not need an mautic.org account to join Slack, it will just sit in moderation until they approve it, though when I signed up several months ago, they were pretty quick.
+1 for X.Y.1 through X.Y.9 minor versions (after a major version release)
that don’t contain any new features but are instead focused on fixing the bugs, making the major version more stable and more reliable for use in a real-world business environment AKA production environment.
In other words, making Mautic as trustworthy as WordPress is with business users.
At presence, virtually every new version of Mautic is guaranteed to break something unexpectedly and business users cannot accept such a highly unreliable software for something that’s vital to their business.
Minor versions X.Y.1 through X.Y.9 that focus solely on fixing broken things, would allow Mautic to gain the same level of trust among business users as WordPress enjoys.
For business users, a software that controls vitals functions of a business, the reliability of the software is far more important than the addition of fancy new features.
A software that does only 5 vitally important things for a business but is highly reliable is far more desirable for business users than a similar software that does those same 5 things + 45 fancy but non-vital things while being highly unreliable and prone to breaking or messing things up.
With WordPress being once again an example, business users know that a minor version upgrade won’t break their business website and a major version must first be thoroughly tested in a testing environment before upgrading in the production environment.
So, if Mautic could ensure that minor versions X.Y.1 through X.Y.9 won’t break anything by NOT introducing any new features in these minor versions, then Mautic would become a trusted application among business users.
@JoPitts We’re bootstraping new service called http://MauticDevelopers.com. It is team of experienced PHP developer with focus on Mautic development. I know that Mautic could be challenging some times and if you feel that you need fix a bug, improve your scalability or build custom plugins just write us.