Continue development in one big plugin or create a "base" plugin where each team has each own "extension"

[barrykooij]

We need to decide if we will continue development in the current structure with multiple teams all in one plugin, or we go to a more "extension" like approach where there's a "base" check plugin and each team can create an addon/extension for the base plugin.

Pros for a big plugin with all teams (current situation) are:

• Cross promotion / exposure.
• We can help each other, more eyes / brains = better quality.
• Easier to install / less confusion for user.

Pros for "extension" like setup:

• Smaller code bases and teams, making it a lot easier to develop and release faster.
• More clear ownership of the project, each team can make decisions in their meetings regarding their project.
• Easier meta integration for the plugin team, because only our (smaller) code base needs to be implemented.
• We need a version of this setup for our private checks, in this case we can use the existing "extension" structure and make our plugin private checks a private extension.

I'm sure I've missed pros for either case. It's clear that a case can be made for both options, both have their own pros and cons. I'd love to hear all of your opinions on this.

[davidperezgar]

What I think at this time is not necessary to split this plugin at this time. The plugin is very well structured, so you can distinct all checks and the ownership is depending of coordinate teams.

For that private checks, I'm testing already an addon that will add private checks, so we can run in our end.

[swissspidy]

What I think at this time is not necessary to split this plugin at this time. The plugin is very well structured, so you can distinct all checks and the ownership is depending of coordinate teams.

Related:

• 460

[swissspidy]

As this issue here starts with a solution (split the plugin) rather than an actual problem statement, I would love to learn more about the problem we're trying to solve. I know we discussed this a bit in-person at WCEU, but it would be good to have some facts in writing.

Easier meta integration for the plugin team, because only our (smaller) code base needs to be implemented.

In this regard I would like to get a better understanding about the hard requirements. Is anything right now absolutely blocking the integration of PCP into your workflows? If so, what are our options for unblocking?

Note: Especially things like ownership, releases, and extensibility are solvable problems even if you have one plugin, so I would not add this to the "pros" section of one particular solution.

Relatedly, I would also like to better understand the urgency or priority behind this ask. We all are still just getting started with PCP. We have a good foundation in place that makes it easy to add new checks, be it in this plugin or in a separate private plugin. Everyone is eager to improve the plugin, be it through code or documentation. We have tooling to quickly ship new releases as well. Now is a great time to build upon this, integrating PCP everywhere and increasing adoption. It took a while to get to this point, merging the two plugins, etc. If we now halt development again to change architecture, we're going to lose valuable time that could be spent more wisely. So if there's no urgency/priority for this, why not just continue what we're doing, iterate to improve the plugin, and then further down the road revisit this.

[mukeshpanchal27]

I agree with @swissspidy. We should focus on the current version of the plugin and the collaborative efforts we’ve established. By working together on a unified codebase, we can more effectively implement and refine the plugin without the complications that come with splitting it.

[adamsilverstein]

More clear ownership of the project, each team can make decisions in their meetings regarding their project.

I like the idea of using codeowners to facilitate more rapid iteration and ownerships of the individual checks (#460).

For that private checks, I'm testing already an addon that will add private checks, so we can run in our end

That makes sense that you can add and maintain your own checks, if there are blocks to adopting this approach, we should fix that.

So far, I'm not hearing a clear need need for splitting up the plugin. It feels like we can achieve the important goals as I understand them without actually splitting the plugin up.

[barrykooij]

We've had multiple talks about this in the plugin review meetings and for us (the plugin team) we've decided we agree on staying in one plugin (at least for the foreseeable future). The separation of code owners for the checks solves most of our concerns regarding control and rapid iteration.

We've been discussing having a custom build for the w.org integration that only includes checks that are run on meta servers, to minimize the chance of conflicts or issues when deploying to w.org.

It seems like we all agree on not splitting, so I'll close this issue. If anyone disagrees, please feel free to reopen.

Thanks everyone for voicing your opinion and your great feedback. This helped us a lot.