Thinking through contribution processes and seeking input

Back in February, Ivan Bocharev (@ibochkarev) submitted around 74 PRs over the course of about eight days. I want to be upfront about how that landed: honestly, it hit me hard. Not just as a review backlog problem. I’d come out of the 3.2 release with a real sense of where MODX was heading. I had a direction I’d been working toward, and I wanted to get some genuine momentum behind it. The sudden volume felt like it cut across all of that in a way I wasn’t prepared for.

I want to be equally clear about what Ivan did: it was good-faith work. A real effort to improve the project. The problem wasn’t intent. The problem was that our process had no way to handle that kind of pattern, and it took me a while—and an inspiring idea from Mike Schell (@netprophet)—to realize we needed to change our perspective.

We stopped and actually thought about it, rather than just reacting. That re-evaluation led me somewhere I didn’t expect: taking a serious look at AI-assisted development, both as a workflow and in terms of what it means for an open source project like MODX. I’m still working through that. This post isn’t a conclusion dressed up as a question. I’m genuinely inquisitive as a maintainer who is trying to adapt to this quickly changing software engineering landscape which is descending upon us and is trying to think clearly about what it means for this project.

I’m writing this before anything is decided, because I want to hear from you first.

Process gaps worth talking about

The first one is about bulk contributions. When a lot of PRs come in at once without prior coordination, it creates real pressure on review capacity—and that capacity is not always visible from the outside. Right now there’s nothing in our contributor docs that says “if you’re planning to submit a dozen PRs, let’s coordinate first.” That’s on us, not on contributors. A contributor who wants to do a big sweep of improvements has no way of knowing that sequencing matters or that a quick heads-up would help.

As a solution, I am thinking of some kind of a threshold. Something reasonable, like five or more PRs within a two-week window which trigger a simple ask: open a forum thread or a GitHub Discussion before submitting, so we can talk through scope and timing. Not a gate. Not approval required. Just a coordination point so the work lands somewhere it can actually be processed with the proper attention. The contributors benefit, as well. They get a chance to prioritize the most valuable PRs before writing any code. And they gain some confidence that the work will be reviewed.

So to the community: does that threshold feel right? Is two weeks the right window? Is a forum thread the right mechanism, or would a GitHub Discussion work better? I’m leaning toward adopting GitHub Discussions for this.

The second gap is about AI-assisted development. This one’s easier to state: I suddenly use AI tooling in my own workflow—a shocking turnaround for anyone who knew my opinion of AI before the past month. A lot of contributors are adopting AI-assisted workflows and this will quickly become the norm. I’m not interested in policing that or making any kind of moral or quality judgment about it. But I think it makes sense to ask contributors to note in their PR description if AI tooling wrote or substantially generated the code. Not as a flag or disclaimer. Simply as context. It helps me understand where human judgment was applied, give appropriate feedback, and give appropriate credit. Every PR gets evaluated on the same criteria regardless of how it was written.

The edge cases are what I’m less sure about. AI-assisted refactoring feels different from AI-generated logic. Where do you draw the line? It is not an easy question to answer.

Is that reasonable? What edge cases am I not considering?

Finally, let’s think about project velocity. AI-assisted development is here whether we like it or not. How can we best adapt to that? I am working on ideas. For instance, I want to work on adopting a policy of taking reasonable contributions that need a few adjustments and simply fixing them, pushing to the PR branch, and asking the original author for their review. They still get credit, but we increase velocity and keep the project moving forward, rather than stuck in the past.

Is this something you as a contributor would be amenable to, regardless if you used AI-assistance or not?

I am exploring other policies that open source projects already dealing with these problems are adopting. I welcome everyone’s input on these topics. It is uncertain territory, but I would rather engage with it directly than simply ignore it. At least for the time being. It feels like this is an inflection point.

What I’m not doing here

I’m not announcing policy. Nothing is decided. Ivan Bochkarev’s PRs are still actively being worked through and future policy will not apply retroactively to anything already submitted. But I want to get a good sense of where those of you with a stake in this project are at.

If you’ve submitted bulk PRs or used AI tooling in your contributions, your perspective on this is especially useful. You will know where friction actually lives in a way I am barely scratching the surface of at this point.

My goal is to have an AI policy committed to in the next few weeks, but only after hearing from the community first. I look forward to anyone who wants to share their perspective.

Having been burned by top-down decisions in other contexts (not MODX), I really appreciate that you’re asking.

I have no firm opinion on AI at this point. I’m tempted to suggest discouraging AI use until we see what kind of economies, and disasters occur in other AI-assisted coding projects, although there may be enough information available now. I don’t really know where to look for it.

In any event, I think providing information about if and how AI was used in developing a pull request is critical. It might be a good idea to suggest categories of AI use to check off in a PR.

For pre-PR discussions, I’d prefer the Forums because, at least in my case, I would be more aware of the discussions, since I look at every new post in the Forums, though I confess that I don’t know what notification of PR discussions on GitHub would look like. I also suspect that discussions in the Forums would be more easily found in a Google search. I could be wrong.

Just a short answer from my side, a (very) long term user, but sadly not a contributor besides bug reports now and then.

Basing additions to MODx on a tool that is based on stolen code would drive me away. “Everyone does it” and “it is fast” is not a good answer on intellectual property theft, which is nearly all public/big LLM companies are basing their value on. You want others to honor the MODx licensing term, I assume, definitely I expect this from commercial companies, too.

So this is a sad “development” for me …

@ goetz_3rz

Thanks. Your post made me think.

It reminded me of something R. Buckminster Fuller pointed out in his book Critical Path. He said that the most valuable commodity on Earth has always been information (he called it “know how”), and we all have reaped huge benefits from inventions like the lever, the inclined plane, the wheel, the screw, etc. Further inventions like water power, steam power, electricity, extended the power of those earlier inventions, and collectively, they are a source of immense wealth.

His principal point was that every person on earth is a descendant of at least one of those original inventors, and that a vast number of us are being cheated out of our inheritance. The titans of AI are capable of compounding that injustice by many orders of magnitude.

Hej @opengeek,
thanks for posting this! I have been waiting to see what others think, including the “big ones” in the MODX community. Sadly, there has been no feedback from @markh, @hyponym, @muzzwood, @sterc, @jako and so on.

I can see some benefits of using AI for coding. I also have in mind where the models were trained and the deep impact it has on emissions. So I’m undecided about using it. But this is my decision as an individual developer.

For MODX, there is a large community missing, so AI could help to keep the project alive. Having made a pro/con list, I think we should use AI until the community grows again or until we can release the next version and cut the old codes (ExtJS, etc.) that make MODX a really modern CMS.

So, let’s take action on your ideas!

Large amount of PRs

I think it’s a good idea to add some notes to the documentation. This could start as a PR and be refined together inside the PR. It could be like the PR for the readme from last week.

The PRs from @ibochkarev are a mix of features and bug fixes. Bug fixes should go directly as a PR on GitHub. Features should be discussed in the MODX forum. There should be no GitHub discussions to have a single channel for communicating with technical and non-technical users. However, posting it directly to GitHub is an additional step that may confuse non-technical users.

There should be a community manager who keeps an eye on this (bearing in mind the open collective budget):

  • Is there a new PR? Check whether it is small, medium or large. Add a tag for the release. For example, small could be 3.2.1, medium could be 3.3, and large could be 3.4. These tags can be modified later. However, group them first to make it clearer and lower the review pressure.
  • Is there a new topic with a feature? Discuss it with the community. Then let the community vote on it and plan for a release.
  • Is there a new GitHub issue/discussion with a feature? Notify the author to add it to the forum.

This will increase transparency and bring us a step closer to creating a roadmap that we can use for pitching MODX too.

When opening a PR, there should also be a note about using AI. Here is a blueprint for this: Add multiselect field type with SuperBoxSelect and configurable separator by jenswittmann · Pull Request #218 · modmore/ClientConfig · GitHub .

Is this something you as a contributor would be amenable to, regardless if you used AI-assistance or not?

So at all. Let’s start using AI for anyone who wants it. First, we need a clear roadmap and a discussion of features, followed by a review of the hybrid process (with or without AI review/writing).

Hello everyone!

@opengeek It’s been a while since this post was published. Can you share what’s changed, what can be seen, and what you’ve been able to accomplish?

Also, what’s the fate of the PRs I created? Will they be reviewed or can they be closed?

Hi @ibochkarev good to hear back from you! If you could tag those PRs properly as featuers and bugs, that would be awesome and help. As Jens suggested, discussing new features before making PRs would go a long way to keeping things sane.

Jason, Jim and Mike are still going through them (you should have seen some comments and clarification requests). Blindly accepting them as good to integrate because AI says so—especailly without knowing the exact prompts, methods and tooling to generate them—isn’t really something we can do or that would pass muster with our SOC2 certification work we’ve been doing for the last 9 months (will be wrapped this year, along with GDPR). It still takes careful humans in the loop.

Hi @rthrash nice to see you too!

I’ll mention a couple of things that haven’t been resolved since my return.

It still takes careful people in the loop - I still can’t understand why the $10,862.68 raised by the community on MODX - Open Collective can’t be used to pay developers and testers who can start sorting out issues and submitted PRs? Yes, it won’t cover the entire workload, but it will give it a boost!

I’ve never seen such a practice, especially with the level of activity in the repository we’ve had for the past 5-6 years, where every improvement is discussed on the forum. And it’s even more difficult to imagine such a practice on GitHub - nuxt/nuxt: the full-stack Vue framework · GitHub with their activity. And introducing a limit on the number of submitted PR requests will only drive away the last few willing. For me, it’s a total turn-off to propose or do anything if the final result will simply sit around, discussed, and never reach the user. It’s easier for me to close a PR for improvements and forget about them.

I can tell you from the Russian-speaking community that many would like to contribute code, but don’t even want to get involved. Because everything is taking a very long time, there’s no clear plan for where we’re going with the CMS, and there’s no leader who’s passionate about the project and sees its development! For example, danielroe (Daniel Roe) · GitHub the lead of the Nuxt core team simply inspires us with his energy and enthusiasm! Because of this, those who could have worked on the core have long since dropped out.

We’ve been waiting for the announced explosive improvements and the roadmap for four months, but we probably won’t see them.

Only my love for this CMS and the community keeps me going, and I have some small hope that MODX’s management will listen to the community and begin to change its decision-making process (which everyone has been waiting for, regarding the roadmap/developer engagement/process improvements, and so on).

It’s clear to me (I could be wrong) that the project leader has long since lost interest in development—and that’s the biggest blocker right now. Without this, there will be no further development that users expect. And people will continue to switch to CMS, which is somehow developing.

I might have offended someone, but I didn’t mean to. Only because I love MODX!

I only became aware of this thread this week, and since the conversation seems to have picked back up in June, I hope it’s still useful to weigh in.

Where I’m coming from

I’ve used MODX since 2007 and currently actively develop a large MODX site and maintain a couple of others. I’m a software engineer and contribute to open source when I get the time. Most of my code these days is AI-written, and it’s increased my velocity enough to let me make contributions I never would have managed otherwise.

On the process questions

A threshold could work. The thing that matters most to a contributor, though, is knowing where they stand. So whatever the mechanism, being explicit up front about review capacity (“we can’t get to these for X weeks”) does more good than the threshold number itself.

Since you mentioned looking at what other projects have adopted: it might be worth borrowing rather than building here. There’s probably a pattern that fits MODX without designing one from scratch.

I’m with @jenswittmann on separating bug fixes from features. Where I’d differ is the venue: GitHub issues with a “feature” label rather than the forum, so the discussion can be referenced directly from the eventual PR. Keeps the thread and the code in the same place.

On the disclosure ask: noting AI use in a PR description seems entirely reasonable to me, and the framing as context rather than a disclaimer is the right one. For the edge cases, I’d not overthink the line between AI-assisted and AI-generated; a one-line note on what the human actually decided is most useful.

On velocity - and I think this is the most important part

This is exactly why getting the velocity and AI policy right matters more than it might look. I’ll be honest about my own hesitation to contribute: I don’t contribute regularly partly because of the speed of progress, and partly that it’s hard to know the direction and which changes will be welcome. So I pop up occasionally with a PR that’s of interest to my clients, and otherwise hang back.

The harder part is that the ecosystem is what keeps clients on a CMS, and that’s where standstill bites. Several of mine have drifted away because, from where they sit, MODX isn’t moving — and the ones who’ve stayed are either deeply invested in a custom setup or simply won’t fund a migration. For those who stay, we end up maintaining forks of Extras or writing replacement Extras ourselves. I don’t raise this to point fingers; I raise it because the contribution policy you’re working out is one of the few levers that actually moves this. A project that can take good-faith work and ship it is a project people build on.

Your idea of taking a reasonable PR, fixing it on the branch, and asking the original author to review, credit intact, work shipped, is the kind of thing that addresses this head-on. I’d be happy to contribute under that model.

Like @ibochkarev, it’s my love for MODX that keeps me around. I was never any good at breakups, and MODX remains genuinely fun to work with. The speed of it is impressive, and a nice change to the heavyweight PHP frameworks I spend the rest of my time in.