Community Concerns

Quote from: easylancer at Jun 03, 2014, 04:22 AM

Can someone also point me to some good examples of roadmaps you have seen for OSS out there please? I tried searching for some but couldn't find any.

Backdrop (a Drupal fork)

Roadmap
http://backdropcms.org/about/roadmap

Release Cycle
http://backdropcms.org/about/releases

+ Weekly Google Hangouts
https://www.youtube.com/user/backdropcms

Quote from: malcomreno at Jun 03, 2014, 05:36 AM

Quote from: easylancer at Jun 03, 2014, 04:22 AM

Can someone also point me to some good examples of roadmaps you have seen for OSS out there please? I tried searching for some but couldn't find any.

Backdrop (a Drupal fork)

Roadmap
http://backdropcms.org/about/roadmap

Release Cycle
http://backdropcms.org/about/releases

+ Weekly Google Hangouts
https://www.youtube.com/user/backdropcms

Nice, they definitively have improved their website.

On a side note, I'm afraid that Modx will go through the same thing that happened to Drupal/Backdrop, where the main project evolved following industry standards and (a sizeable ?) part of the community drift away on the backdrop fork because they refuse to change just for the sake of changing. It already did happen with Evolution/Revolution.

Many integrators and less tech savy users will most likely not welcome the whole Composer paradygm. The technical shift is huge, much higher than what it was for the shift from Evolution to Revolution.
I'm curious to see how will Modx will handle that...

Quote from: lossendae at Jun 03, 2014, 05:52 AM

Quote from: malcomreno at Jun 03, 2014, 05:36 AM

Quote from: easylancer at Jun 03, 2014, 04:22 AM

Can someone also point me to some good examples of roadmaps you have seen for OSS out there please? I tried searching for some but couldn't find any.

Backdrop (a Drupal fork)

Roadmap
http://backdropcms.org/about/roadmap

Release Cycle
http://backdropcms.org/about/releases

+ Weekly Google Hangouts
https://www.youtube.com/user/backdropcms

Nice, they definitively have improved their website.

On a side note, I'm afraid that Modx will go through the same thing that happened to Drupal/Backdrop, where the main project evolved following industry standards and (a sizeable ?) part of the community drift away on the backdrop fork because they refuse to change just for the sake of changing. It already did happen with Evolution/Revolution.

Many integrators and less tech savy users will most likely not welcome the whole Composer paradygm. The technical shift is huge, much higher than what it was for the shift from Evolution to Revolution.
I'm curious to see how will Modx will handle that...

Actually the reason for forking wasn't composer itself but more of breaking away from the NIH syndrome and deciding to use Symfony Components. I think this can be left to the minimal with properly educating your usebase of why the switch make sense and what benefits it would bring, some of which were missed out in the whole Drupal transition. This is even more so why MODX LLC need to make communication better between them and the community.

Quote from: easylancer at Jun 03, 2014, 05:59 AM

Actually the reason for forking wasn't composer itself but more of breaking away from the NIH syndrome and deciding to use Symfony Components. I think this can be left to the minimal with properly educating your usebase of why the switch make sense and what benefits it would bring, some of which were missed out in the whole Drupal transition. This is even more so why MODX LLC need to make communication better between them and the community.

I stand corrected.

Anyway, it's not symfony that was the problem (in the sense that Zend or any other framework would have generated the same issue), it was the mainly the change of habits. Having to relearn "things" while they were working "great as far as we're concerned".

For exemple, how would the users would react if Modx abandon it's template system in favour of Mustache or Twig ?

Quote from: lossendae at Jun 03, 2014, 06:20 AM

For exemple, how would the users would react if Modx abandon it's template system in favour of Mustache or Twig ?

Can't speak for everyone, but I would actually love to see Twig as a template option. This would allow a lot of newcomers to quickly feel at home as well. Might be even better to decouple the template engine from core entirely and allow to install one as a package. Maybe including the option to choose the template engine during setup. That way we can go to a more commonly used engine, while still providing backwards compatibility.

Probably not appropriate to discuss this in the context of this thread, but if the main functionality of the MODX template systems (we're talking about [[*pagetitle]], [[+placeholder]] stuff right?) were changed to Mustache, e.g. Handlebars and "extended" it with the functionality we love about MODX template system (e.g. caching, output modifiers etc., is that even possible?) I would not have the slightest problem with it...as it possibly could also help refining the manager, for example with emberJS which also uses Handlebars...so if it "only" means replacing [[ with {{ basically (for the template integrators) that shouldn't be a problem from my point of view...but yeah, this is probably a very unqualified comment as I don't really have in-depth knowledge neither of Mustache nor the exact inner workings of the MODX templating system (further than using it)

Quote from: sepiariver at Jun 03, 2014, 03:15 AM

Today, there's no shortage of love and commitment to MODX from the people in MODX, LLC, and that in itself is something to be positive about, don't you think?

YJ, absolutely, but I would just be careful about saying there wasn't in the past. You don't know the motivations or hearts of those who were before you, and it does no one good to speculate otherwise.

Thanks for your post and clarifications; I mean no ill will toward the LLC, but having had been in it for over 5 years and knowing its restrictions, I believe that for the project to survive, changes need to be made to empower and direct development from the community more: and that, IMO, is more important than coding the next new feature.

Off-topic so I'll keep it brief, but @SilentWorks and I were working on a twig templating option for Revolution last year that worked pretty well, and didn't seem to have any tangible trade-offs against modx's bespoke templating language. And definite +1s for ability to drop-in different languages according to taste

Quote from: markh at Jun 03, 2014, 03:48 AM

Shaun, it's nice to see you in the forums hearing your point of view. You've hit the nail on the head several times. While part of your post was giving me the impression you think MODX is past a point of no return, I think you just mean to say running the project no matter with what sort of structure will be challenging because of the issues you highlighted. That is absolutely true and why the community needs to get together with the project leadership as this cannot - and should not - rest in Jason's hands alone. Glad to agree with you.

Hi Mark! Glad to hear from you.

I agree 100%. And no, I do not think this project is at the point of no return. I do however think that without major change on how development is prioritized, organized and assigned, it will get there fast. For MODX to compete in today's world, it needs to modernize its development processes as well as its development stack.

Here are just a few things the LLC could do to vastly improve development tracks and communication:

• Create a detailed roadmap view for 2.3 and 3.0. It doesn't have to be set in stone down to each ticket, but each deliverable item needs a defined issue in Github and to be tagged for 2.3/3.0 appropriately.
• Create a sprint plan for 2.3. This means estimating LOE (level of effort) for each ticket as well. The best way to do this with a volunteer base is to go in 2 week sprints. A week prior to each sprint, the LLC should ask for volunteers who can commit to delivering X amount of hours of work (or X issues) over that 2 week period. Then, the backlog for 2.3 should be groomed into a deliverable amount of issues based on the number of volunteers. The sprint then kicks off, and specific tasks get done. This also enables the community to know specifically what is needed to be worked on at any given point, as they can just look at the sprint boards.
• Furthermore, this answers the community's need for direction, while also still allowing the LLC (and product managers within the community who are working with the LLC) the ability to shepherd and direct development in a way that doesn't damage the core vision.
• Document the architecture at a high level. This is not really visible anywhere in RTFM, and should be of a high priority, as clarifying this for incoming developers would significantly assist in development quality.
• At a certain point when the 2.3 issue backlog has been decreased enough, a feature freeze should be set, and a date for release should be publicly set and adhered to. Only critical issues should delay that date, and that date should happen at regular intervals. The LLC can get a volunteer release manager to help with this.

There is far more things that could get MODX into a more modern, agile development workflow, but that's a short list.

There are rare few who understand core enough.

This quote from Petri is the part that bothers me most. The core is so small, that everyone outside is just kept waiting (BobRay's locked building), and are unable to contribute significantly, and the community can't grow sufficiently.

A typical company doesn't want or need extra people who understand the core system, indeed that would lower efficiency and profitability, and potentially create future competitors. This might even work out to a lose-lose proposition, as the LLC ends up with too much pressure on it, and obviously the community isn't very happy now. The LLC is ill-equipped to handle the broader needs of the community, or at least has a difficult time deciding how much effort to allocate to those needs. LLCs are good at making money, and not so good at churning out people with deep knowledge of the system.

If the gumball has a tight, small core, it can't grow well, as we need that core to do important things so we can develop other areas of the ecosystem. If the core is larger, then it can feed a wider community and much faster development.

People want to help. You can see that in the millions of OSS projects out there. The problem with MODX at current is that there are no streamlined tracks to help onboard contributors. There is no "here are the specific places and roles we need help with" displayed anywhere. There is no public burndown chart of issues that the community can do sprints to to release 2.3, or 3.0. There is no detailed roadmap showing the path that all these private conversations you are having are mapping out.

But a Foundation is more concerned with getting people to contribute extras, rather than doing it themselves. A Foundation is 100% devoted to the OSS project, and nothing else. It's obvious the LLC cannot do that (for payroll reasons!), and the smart move - as many other OS CMS's have done - is to separate the business concerns.

I agree with this from Shaun.