The Ecosystem team (Ecosystem category on our forums) is responsible for managing the various technological components that, collectively, support and integrate with ClassicPress to help make it stronger, more viable and more productive.
This includes approving, managing and developing ClassicPress research plugins and providing clear ownership as well as consistent values for all such plugins as they mature. Another important area is reaching out to and working with third-party developers, hosting companies and other providers that may potentially have an interest in supporting ClassicPress at a technical level.
I also wonder if we need a new GitHub repo for those research projects that aren’t plugin related? I wonder if some of those projects can be archived or deleted e.g. use-wp-language-packs?
I like the updated description. What I wrote there was just a first draft to get something on the page, and you have access to edit this, please go ahead.
One thing I do think we should clarify is what happens to a “research” plugin once we decide to officially support it.
I think most of the repositories under ClassicPress Research · GitHub should stay as they are. Those were created because someone expressed interest in working there, usually as a result of a petition. If that happened, then the plugin probably has value to someone, or could serve as a base for future work. In the example of use-wp-language-packs this is still useful until we have more translation coverage and while we still have significant overlap with WP’s translatable strings.
When we decide to officially support a plugin, that should coincide with a move to ClassicPress Plugins · GitHub (or some other place). We can then remove the “EXPERIMENTAL, NO GUARANTEES” wording when you think we are ready for that.
The idea of this approach is that there’s no extra commitment on our end for plugins that stay in “research” status and no problem with them staying there.
I like the idea of a ClassicPress Plugins · GitHub repo and I think that’s where approved plugins should live, currently Classic Commerce and Classic SEO.
All others can remain in ClassicPress Research · GitHub and I don’t have a problem with that per se but what I am a bit wary of is that this doesn’t end up as a type of plugins petitions area as I think that could quickly become unmanageable.
I actually quite like the idea of a plugin petitions area somewhere, just not on GitHub. I think projects that end up in ClassicPress-research need to have gone through some sort of appraisal process first.
So, if a plugin is to be considered for official CP status, the basic route would be something like:
Suggestion / petition → Approval → Create repo in ClassicPress-research → Development as a research project → Approval → Official
I would suggest the Suggestion / petition → Approval stage be held on the forums.
I can put together a more detailed document if that would help?
Edit - Wade asked if I had plans to use the GitHub plugin to make linkbacks. How do I do that?
Also, how do I copy Slack convos to the forums without losing formatting?
How would this happen? A vote? By all community or only committee?
We are just in the process of adding an email logging plugin to the research area so maybe we could work out some approval process around this. Might make a good test case.
I would suggest a vote open to the community. I know you’ve got a plugin in the works and I know that @james has created a petition for the same feature but thus far, the petition has attracted 9 votes which ordinarily would not put it in contention.
I’m on mobile, so it is kind of hard to hit all the points.
I disagree with plugins having to go through an approval process to get into the research repo. I think plugins that the Ecosystem like and see long term value they should then have the ability to move those plugins into the official plugin repo. Adding more approvals to the process isn’t something I personally want to see.
Petitions that have someone working on a plugin (even in the research repo) is better for everyone since that gives us a jumping off point.
OK, that’s certainly one option I hadn’t considered. But how does it then relate to the petitions? Is it OK to promote a “feature” that’s only got a few votes in the petitions? That would be my concern.
If it has long term value, I would think so. But I agree, it is something we need to look at. Having a plugin doesn’t mean it will be added to core though, so is the separation there?
I mean using the email logging as an example, now that there is a plugin it doesn’t necessarily mean it will be added to core - that would depend on the petition process but clearly there is value in having a plugin fill that need for now.
I agree. This should just be a decision for the ecosystem team. You could open it up for discussion here to get feedback, but you should have the final say.
At the moment I’m not really a fan of this extra step either. What would we be approving here? Who would be approving it? What value does this add beyond having a petition that gauges community interest, and having a place for people who are interested to work on an experimental implementation?
What we do today, plus what we’ve proposed above is basically this:
If we want to clean that up a bit, then we should look at where we have empty repositories where someone has expressed interest but hasn’t actually done anything. We would reach out to each of those people and ask them whether they have any plans for that repository. If not, it could be deleted or archived. Still I don’t think there’s much harm in leaving it around until someone does want to work on it. Maybe we could just leave a note on the petition saying “this repo is created and accepting contributions” instead?
There are other paths for a petition to be implemented that don’t involve a research plugin, but the “someone expresses interest” and “someone does the work” steps are always going to be key. This is what the research plugin setup was intended to facilitate: a recognizable place for interested people to start on projects. We shouldn’t put more barriers in place for people who are interested in working on things.
There are some things to be clarified around ownership, but the low barrier to entry to getting a research plugin repository is a feature, not a bug. On the flip side we shouldn’t offer much commitment or support there until we’ve looked at an implementation + its petition and decided that it’s something we really want.
So, tl;dr, research plugins shouldn’t need approval, rather, having a workable research plugin implementation is something that’s nice to be able to look at when we do consider petitions or other projects for approval or official support as a plugin.
This is a good question, and I think it’s not something we’re ready to solve yet. There are likely other steps we could take instead of a core plugin or inclusion into core, like listing “recommended plugins” or “officially supported plugins” in the dashboard.
When it comes time to mark a plugin as “recommended” or “officially supported” that would be the time to have a vote, in my opinion…
I agree with the spirit of this. However, community votes are hard to manage - who is eligible to vote? I think generally speaking it’s also a fine option to delegate these issues to the committee, since they are chosen by the community every year.
OK, well first things first. I’m the last person who would want to increase bureaucracy and make things more difficult. Trust me on that one.
But my problem with the “low barrier, no approval” approach is that someone (i.e. me) is going to have to manage these to some degree and that’s why I’d like there to be some kind of vetting process. I think whoever puts forward a suggestion needs to be able to demonstrate capability and willingness and also be very clear about what it is they want to achieve, We also want to avoid duplication.
What if we get a John Doe with a brilliant (in his eyes) idea to create a security plugin? Mr Doe has no track record, has not developed anything beyond a “Hello World” bash script before and clearly hasn’t the foggiest about security, let alone PHP or ClassicPress. He could start his new project and within 5 minutes, he’ll be on the forums or pinging me and generally taking up time that none of us have. An extreme example I know, but that’s the kind of thing I want to avoid.
I’m happy to help and support good, solid projects but I don’t think any of us want the John Doe projects.
So, with that in mind, I am happy with the idea of the Ecosystem team having discretion over what becomes a research project if we’re all agreed on that?
So on that basis, the workflow could perhaps be something like:
I would cut the entire middle approval process out, adding approval steps adds barriers to entry.
Using Classic Commerce as an example, if there was a “approval” stage I highly doubt it would have gotten the pick up it has. Having to get approval would have meant sidelining the process until we could hold a vote. But instead, without that work continued and strides were made to make it a viable plugin. Now that the Ecosystem Team sees the value the plugin creates for the project it now makes sense to move that into a position that offers more support and commitment.
The Ecosystem Team (and all of CP) should have no commitments to plugins in the research repo. The only time we should have commitment is when the Ecosystem Team has decided that said plugin holds long term value to the CP project, and therefore should receive long term support.
So cutting the middle part out of the above diagram:
Just wanted to add that at the end of the day it should be whatever you are most comfortable with as the team lead. With a new team we will have these types of discussions as we try to define where the lines between each team is
These are my opinions, but if you want to go another route I am okay with that too - I just hesitate to add more community votes as we need time to announce the vote, hold the vote, and verify the results - so I would budget on a 2 month delay for votes.
