I think there needs to be 3 types:
IMO 2 is really important - we should welcome WP devs that are making a commitment to CP, and I don’t think we can (or should) demand they’re monogamous.
Oh - and all my plugins would land in 2 
I think the fact that we will list WP plugins that work with CP is already welcoming and don’t need to add another category. For example, while you may be offering full CP support for your WP plugs, they rightly fall under “works with CP”. There’s no demand of platform monogamy.
No, not quite.
If I make sure my WP plugin keeps working with CP but I don’t use a single bit of CP-specific functionality, I’ll get a “Works with”.
If I go out of my way to use all the new CP features but I also support WP, I’ll get a “Works with”.
Where’s the incentive to support CP properly without option 2?
I like the current types because it is welcoming to WP devs but still places a higher importance on plugins that have been developed specifically for CP.
As we are still a young community, supporting and spotlighting those developers, I believe is crucial to building our own ecosystem. As we continue to grow, it may make sense to adjust the categories, but for the time being I think Works With and Developed For cover 95% of cases.
I do think we need an FAQ section somewhere to explain the difference, but with the limited bandwidth to build the directory we have to focus on the features that give us the biggest bang for our buck 
Now that most of the initial bug reports have been fixed, the next big features we are working on is getting the latest download links for plugins, and parsing the plugins README for plugin descriptions.
This isn’t quite true, and I think leads to my reasoning behind needing an FAQ section. Maybe if someone has time to help with that we could even just make it a forum page.
If your plugin is developed primarily for CP, and not hosted on the WP directory then you would fall under the Developed For. The only other requirement is, as of right now, it has to be hosted on GitHub.
Is there a thread I’ve missed where we decided we didn’t want any of the existing WP plugins in the CP directory?
Why can’t a plugin be developed equally for both CP and WP?
I don’t believe there is a thread, it was a decision made to prioritize our community and ecosystem. We will likely continue to support the WP plugins, but will not be spotlighting them and they will likely come with a warning that we don’t guarantee 100% compatibility especially as WP splits off further from CP.
I believe encouraging an ecosystem around CP will help ensure our long term success. So by spotlighting plugins built specifically for CP it is an incentive to help build out our ecosystem. Plugins that Work With CP are important, but ultimately don’t build our ecosystem.
It doesn’t make much sense to me to try to sort through types of plugins before we have an initial bunch of plugins to look at, and some more interactions with WP-first developers. Why not just keep the two categories we already have planned (plugins in the WP repo that are confirmed to work with CP, and plugins that are intentionally published in the CP directory), then see what other sub-categories arise naturally out of those once people start using it?
I think having just the two categories right now gives the spotlight to those who’ve built something specifically for ClassicPress…which seems pretty reasonable to me. And it also creates the incentive to build something for ClassicPress. Plugins that actively support both platforms will inevitably end up with some bloat, so, in the end, it would be nice to see plugins choose one platform or the other…or release separate versions catered to each.
There are only 4 types of plugins possible, and we only care about 3 of them.
(Yes, in theory there can be shades of 2 but we can round them into either camp).
We don’t need to wait and see - those are the only things a plugin can be.
By explicitly listing 2 we’re encouraging people to move from 3, thus improving the ecosystem for CP. Why would we not do that?
I think it’s worth emphasising that nothing is cast in stone. But we do have to start somewhere. To my mind, the categories we have at present work perfectly well and don’t discriminate in any shape or form. All plugins that are known to work with CP are listed, just in different categories.
There will clearly come a time when developing for both WP and CP is no longer sustainable and the developer will have choose. In that respect alone, I think it’s perfectly sensible and appropriate to encourage growth of the CP ecosystem.
And by not differentiating devs who are making the effort now, that’ll somehow give them an incentive to move towards CP?
The logic there is every kind of wrong, but it’s clear everyone has made up their mind on this.
On the plus side, my to-do list just got shorter.
As I say, nothing is cast in stone. This will be version 1 of the directory. It’ll be a fantastic start and will be welcomed by many. Maybe it won’t be perfect from day one. Maybe it will. But things can always be changed if there is the need.
I can see where @invisnet is coming from here. I have noted two sorts of commitment to CP from WP plugin developers. Which means I already mentally divide WP plugins into three groups.
The first is like Paul with Shield - he said right from the start he was fully in and would support CP and has made changes to his code to accommodate us (eg in the file checking to avoid warnings).
The second group is like the dev of the Stripe plugin I am using on my CC sites. He said: “Hmmm, well I can’t see any reason why it shouldn’t work and will give conditional support for now”.
The third (and largest) are those that work with 4.9 and so work with CP but the plugin devs probably have no idea CP even exists.
To me, Paul’s approach inspires confidence and I feel good about using his plugin. The second ones make me nervous and I feel like I will need to keep a close watch on how it goes. It could break with any update. Same with the third group.
But, are we saying that all of these plugins get lumped into the “Works with” section? That doesn’t seem fair on Paul, and others like him.
To me the solution is quite simple - keep the two sections but make the first one something like “Developed for CP or fully supported for CP”. That is where I would always be looking first for a plugin to use… if I can’t find something there, then I would move (reluctantly) onto the other section.
Yes, that’s what I am contending. If it wasn’t written specifically for ClassicPress, it should go into the “works with” category. The fact that we allow WP-first plugins into the directory is “fair enough” IMO and I don’t feel an additional category is warranted. Personally, I feel the most benefit should be given to those who are “all in” with ClassicPress rather than those straddling the ever-widening fence between the platforms.
Will these types of plugins find homes in the directory? I can see a few cases where this might be beneficial, but, if the plugin isn’t being actively developed for CP, I wouldn’t put it in the directory… it could lead to our directory having a ton of zombie plugins like the WP ecosystem.
OK. So the main aim of the directory is to promote CP-specific plugins and their developers? Everything else just goes into another bucket? Paul’s Shield Security ends up lumped together with a plugin that just happens to work with CP because the dev hasn’t updated it for 3 years?
If that’s what’s been decided as the purpose of the directory then I guess that’s the way it is. But as a CP user I would find that pretty much useless. And I certainly won’t be bothering to approach any more plugin devs to ask them to support CP. Because this…
My feeling on the purpose of the directory is that it is to have a place for CP-specific plugins to live…so they can eventually be installed via the dashboard. If not for this one reason, we could have just used the WP directory. The WP plugins that work with CP…they already have a home and are already installable via the dashboard…I don’t think they should also get star billing.
I thought it was:
Both of those criteria are met, regardless of the categories we use.
Sorry, I must be missing something then. Say Shield Security is listed under “works with”. Is there some filter that lets me pick this out as one that is actively supporting CP and has been specifically modified to work with CP, with a dev who has made a firm commitment to CP? Because, as a user, that’s what I would want to find.