Community Concerns

Despite being advised against this, JP, I'm gonna reply to you, because the problem of escalated feelings started here, with me, and my comments, and I'm hoping it can end here. Never meant to get into any kind of argument with you. I don't have anything against you, and in fact you have my highest respects. Have done, since the day we met.

After re-reading one of my comments, it's much more apparent to me how you'd take offence, and for that I'm really, really sorry. I've apologized already, but have no problems doing it again. That comment was misconstrued. It was based on a one-on-one conversation (posted you privately about it) but in the context of this thread the mere mention of it is easily taken completely the wrong way. Pure bad editing on my part. Lesson learned: no posting at 1am, and furthermore this "staff" badge seems to obfuscate the true meaning of any messaging I do here. I'm gonna have to work harder at mitigating that.

You speculated about my comment being related to your termination in some way and to be clear: it's not. Totally unrelated, and I'll express again for the umpteenth time how regretful I am about the circumstances around your termination.

I hope you know by now, after repeated public mentions to the same effect, that I'm a huge believer in your talent and abilities, and only look forward to your contributions to MODX and the web-at-large.

Quote from: sottwell at Jun 03, 2014, 01:13 AM

(notwithstanding the use of 'onboard' as a verb, especially a transitive verb).

I think it was being used as an adjective; i.e. contributors that are on board.

No, it was definitely referring to how to get contributors onboard who are not currently onboard (i.e. 'onboarding' them).

Quote from: lossendae at Jun 03, 2014, 12:23 PM

Going full stack with either Angular or Ember can cause the same issue as Extjs in the long run.
Why not go back to something simpler first (php + templating) and add a few bit of javascript when necessary ? Decoupling as much as possible the manager from a specific JS framework usage outside of core features.

+10,000

Quote from: sepiariver at Jun 03, 2014, 01:27 PM

Despite being advised against this, JP, I'm gonna reply to you, because the problem of escalated feelings started here, with me, and my comments, and I'm hoping it can end here.

I appreciate the clarification. YJ I hope you never have to regret what you say. Personally I think the fear of escalating feelings is not important. We are talking about a pivotal piece of software, that is essentially on life support. It hasn't reached its full potential, or seen its best days and is way too young to die. There are various loved ones trying to figure out ways to save it, but even the nurses aren't fully aware of what is going on. Meanwhile the doctor has everyone confined in the waiting room, living off the vending machines, and assuring them to just hold tight and they're loved one is going to be just fine. So things might get real.

This thread starting based off community concerns, some of them related to the nature of my termination. Who care's about my termination that is not the topic of this thread nor should it be.

I'd like to use the convo YJ referred to (now that I know which one it is) as an example of an issue I see as destructive to the advancement of the product.

Once upon a time, YJ and I were wrapping out around the watercolor about MODX, as we did daily for years. I think he said something along the lines of that he can't wait to see what is around the corner, but he loves the current version as much as ever. I responded with

i've already seen part of it and it is 1000x better. i would never use revo again by choice

Does MODX end at revo? No. Did it end at evo? No. Will people be using revo in ten years? I'm sure. But I was brought onto the team to lead front end development of the next major version, not to stay loyal to a dusty codebase. There was so much internal resistance to bringing on someone who could act as a Art Director pursuing breaking changes, that I began asking, then demanding for my job title, duties, and responsibilities to be put in writing. I was told to "hold tight", and soon the waters got murky things got very interesting.

I don't think the LLC, managed as it was, could handle what they hired me to do. Breaking changes seemed to excite management almost as much as it frightened them. That said I still have every confidence Jason can and will find a way through this.

YJ I completely understand you love 2.x as much as ever but please notice the use of the word "would" implies in the world I'd never use revo again there also exists the next major version of the product many of us have been dreaming about for years. We don't live in that world, so it really isn't fair of you to publicly draw comparisons between that world and the one we live in and use them to suggest you know anything about my intentions to build a business around or continue using MODX. No MODX community member or staffer should speak for another and I find that to be an example of the spin factor myself and others continue to feel the need to point out in this thread.

I was thrown off the bus and am not going to have something I said spun, especially not on *this thread* that throws me under it too. I'm totally cool walking the rest of the way on my own, with my thumb out hoping to catch some rides from the community along the way.

Let me add a plea that we see no more messages aimed at or about individuals and post only about MODX. This thread is far too valuable to use for personal discussions, however important they might seem to the individuals involved, and it will quickly become useless if we don't get back on track.

This the most active thread I've ever seen here, and it's also the first time I've ever seen a truly sophisticated discussion of the pluses and minuses of MODX's current and future architecture with input from many key MODX users and developers.

Back to the topic at hand:

1. I would much rather see xPDO tweaked than abandoned. There is a ton of xPDO-dependent code out there that would have to be extensively rewritten and tested if we moved to another ORM. I don't think there are any fatal flaws in xPDO's architecture and it's one of the most intuitive ORMs I've seen.

2. We definitely need flexible fields for both Resources and Users that are available for single-query searching and sorting. ClassExtender helps with this, but it's not a long-term solution. I will be more than happy to see it become obsolete or morph into a wizard for a new system.

3. I also see the templating engine as not a high priority. Whatever it's issues, I think we have much bigger fish to fry.

4. I'd like to see a return to a role-based security permissions system, where each user's role determines what they can see and do, rather than a system where the users' potential actions are controlled by a complex interaction of permissions, policies, policy templates, roles, and group membership.

5. I have mixed feelings about using Composer for all package management, though there's no question that Package Manager needs work. I think Composer creates a very high technical bar for contributors. I see some technical and practical advantages of it, but I'm not sure they outweigh the negatives. It's difficult for me to be objective on this because for me it would mean losing many of the advantages of MyComponent and having to redo several dozen extra packages. I'm also concerned about the effect of having every MODX extra package become suddenly obsolete. Maybe there's something here I'm not getting.

6. I dislike extJS as much as the next guy, but I'm not sure moving to something like Angular or Ember is the answer (though I do like what I've seen of Ember). JavaScript is always going to slow things down and raise the bar for developers. If the Manager could be re-done in plain HTML and CSS with some Ajax calls to processors, I think the increase in speed and ease of customization would more than outweigh any disadvantages.

7. In-Manager upgrades are essential if MODX is going to remain competitive. This should probably be at the top of the list.

8. MODX needs real unit tests. I was shocked at how shallow the current tests are.

9. Installation issues need to be fixed. There are still far to many users experiencing blank screens and inability to log in after an error-free setup.

10. I think the Advanced and Traditional distributions should be unified. People don't know which one to use, how to switch from one to the other, or how selecting one affects upgrade options. It's also inefficient for the team to have to manage two separate distros. The advantages definitely don't outweigh these issues, imo.

Since 10 is a nice round number for a list of commandments, I'll stop there.

Let me add a plea that we see no more messages aimed at or about individuals and post only about MODX. This thread is far too valuable to use for personal discussions, however important they might seem to the individuals involved, and it will quickly become useless if we don't get back on track.

I totally agree bobby, this thread is about MODX and their future as per the community and that should be the only thing discussed here.

It's just very disappointing that no official person has responded to this at all, we as the community take time to respond to forum posts, which is what builds the community, however all "official" people cant take the time to respond to the one most important thread ( in my opinion ) on the forum, and that is simply what is the future of MODX ??

Jason (OpenGeek) is "official" enough for me. This thread is moving so fast that it's easy to miss posts.

Quote from: netProphET at Jun 03, 2014, 02:43 PM

Quote from: lossendae at Jun 03, 2014, 12:23 PM

Going full stack with either Angular or Ember can cause the same issue as Extjs in the long run.
Why not go back to something simpler first (php + templating) and add a few bit of javascript when necessary ? Decoupling as much as possible the manager from a specific JS framework usage outside of core features.

+10,000

I agree with this as well. I started the matboard project out of fear of being responsible for picking "the" framework that was chosen. Especially in today's rapid landscape I'm not sure there is one answer. While the project started really as a way to offset some of the responsibility for choosing "the one" to the community, it has evolved into the realization that creative freedom may be able to brought into the Manager without binding it to a particular JavaScript framework.

This possibility excites me more than anything, and I think we can do it.

Quote from: BobRay at Jun 03, 2014, 04:04 PM

This the most active thread I've ever seen here, and it's also the first time I've ever seen a truly sophisticated discussion of the pluses and minuses of MODX's current and future architecture with input from many key MODX users and developers.

Ditto. Pun intended

Back to the topic at hand:

1. I would much rather see xPDO tweaked than abandoned. There is a ton of xPDO-dependent code out there that would have to be extensively rewritten and tested if we moved to another ORM. I don't think there are any fatal flaws in xPDO's architecture and it's one of the most intuitive ORMs I've seen.

- Doctrine has changed a lot, it is an industry standard and far more flexible than xPDO ever was/is.
- Eloquent is far (FAR) more easier than xPDO.

Those two ORMs are maintained, used by millions of users and fully tested. They also support more drivers than xPDO.
Plus, xPDO would need a rewrite, not just a refactor, it's time consuming : Jason is doing it alone.

This should raise some alarms because as Shaun said, Modx should leverage 3rd party components, even more for such important part of the architecture.

What are the actual advantages of keeping xPDO besides BC ?

2. We definitely need flexible fields for both Resources and Users that are available for single-query searching and sorting. ClassExtender helps with this, but it's not a long-term solution. I will be more than happy to see it become obsolete or morph into a wizard for a new system.

This is more UI than architecture related isn't it ?

Resources should not depend on a model. What if you want to build a static website/blog ? Modx should be able to do it, and in that case using a Model does not make sense.

4. I'd like to see a return to a role-based security permissions system, where each user's role determines what they can see and do, rather than a system where the users' potential actions are controlled by a complex interaction of permissions, policies, policy templates, roles, and group membership.

This can be brought by a 3rd party package. Even a Modx/community made one, but, should definitively belong in Composer and not deeply tied with Modx. A default one, but switchable.

5. I have mixed feelings about using Composer for all package management, though there's no question that Package Manager needs work. I think Composer creates a very high technical bar for contributors. I see some technical and practical advantages of it, but I'm not sure they outweigh the negatives. It's difficult for me to be objective on this because for me it would mean losing many of the advantages of MyComponent and having to redo several dozen extra packages. I'm also concerned about the effect of having every MODX extra package become suddenly obsolete. Maybe there's something here I'm not getting.

I share your point of view on this matter.
From what I've seen so far, many projects rely on Composer for "packages" that are shared libraries, and still use a "Plugin" system for CMS dependant features.

6. I dislike extJS as much as the next guy, but I'm not sure moving to something like Angular or Ember is the answer (though I do like what I've seen of Ember). JavaScript is always going to slow things down and raise the bar for developers. If the Manager could be re-done in plain HTML and CSS with some Ajax calls to processors, I think the increase in speed and ease of customization would more than outweigh any disadvantages.

+1

And I sure hope that Modx will use a routing system allowing to get away from connectors as well.

7. In-Manager upgrades are essential if MODX is going to remain competitive. This should probably be at the top of the list.

Now, that is a good idea. I would rather see Jason work on that instead of trying to rewrite/refactor xPDO

8. MODX needs real unit tests. I was shocked at how shallow the current tests are.

I can't imagine Jason developping something in 2014 without unit testing.

9. Installation issues need to be fixed. There are still far to many users experiencing blank screens and inability to log in after an error-free setup.

10. I think the Advanced and Traditional distributions should be unified. People don't know which one to use, how to switch from one to the other, or how selecting one affects upgrade options. It's also inefficient for the team to have to manage two separate distros. The advantages definitely don't outweigh these issues, imo.

Well, tbh i think it's part of the heritage of the actual code base.
If modx goes composer, some people will most likely install it from there, and the website would propsoe to download the installable version. That's pretty much how everyone does it nowadays.

Quote from: BobRay at Jun 03, 2014, 04:04 PM

4. I'd like to see a return to a role-based security permissions system, where each user's role determines what they can see and do, rather than a system where the users' potential actions are controlled by a complex interaction of permissions, policies, policy templates, roles, and group membership.

^ This