ClassicCommerce or Classic Commerce? Status as a research plugin?

[timkaye]

I think there are really two issues here, but they are related.

The first is a matter of history. When the initial discussions about ClassicCommerce took place here, they were prompted by a different developer who, so far as I understand it, is no longer involved.

The second is what the names Classic Commerce and ClassicCommerce imply. It seems to me that, as @anon71687268 says, the name ClassicCommerce implies that the plugin is somehow attached to, or part of, the ClassicPress project. So, if it isn’t, it shouldn’t have that name. (Whether it is then called Classic Commerce or something else entirely then becomes irrelevant so far as these forums are concerned.)

But here’s the bit that muddies the waters for me. How did the ClassicCommerce project get taken over? I could well be wrong, but it appears to me that the transition from one lead developer to another happened precisely because of its association with ClassicPress.

So I’m essentially with @anon71687268 in saying that there has to be a clear decision one way or the other, and then everything else should follow accordingly. So if this e-commerce project is not to be brought somehow under the ClassicPress umbrella, there should be a clean break in terms of repos, forums, etc as well as in name.

[ozfiddler]

Excellent points, Tim. Thanks… that summarises it perfectly.

[james]

@anon71687268

Who is “our” here, though? This is a 3rd party project; whomever is leading that project should make the decision on the name, the logo, etc, etc. The waters have been greatly muddied with the commerce fork for a couple of reasons:

1. lots of initial feedback was solicited regarding logo and name, but, I feel this gave the false sense that this was a community project, and not merely the solicitation for ideas that it was, and
2. adding the plugin to a ClassicPress-owned repo furthered the idea noted in item #1.

Both of the items noted above have given the community a false sense of ownership (ie, decision-making) in the project. This left a bad taste for me and, indeed, these are the reasons I solicited zero feedback and didn’t request a research repo when forking the TInyMCE Advanced plugin.

Fair points here, though I’m sorry to hear that part of the approach left a bad taste for you. This is why I put “EXPERIMENTAL” in the description of all the ClassicPress-research plugins, the ClassicPress-research repositories are an experiment and I am open to clarifying this situation further.

From my perspective, I am willing to stand behind the official releases of the ClassicPress core software, fix bugs, provide support etc. I will need help from the community to develop larger features but I can make the commitment to “keep the lights on” so to speak.

For the ClassicPress-research plugins, I cannot make the same commitment, but I will help out where I can.

For Classic Commerce (CC) specifically, there are several people who are actively working on the project, but we do not have someone who has formally accepted a “project lead” role. (We did for a little while, but the last person recognized they didn’t have the available time to lead the project.) I think this is one thing that would help clarify the situation a bit.

As far as whether it is a community project or an official ClassicPress project or whether CC should get its own Slack …

This is not an official ClassicPress project in the sense that we don’t recommend it within the dashboard as an official solution for e-commerce. First of all we don’t have the mechanisms to make these recommendations yet (plugin directory etc) and second I’d like to see any such recommendation voted on by the community once there are a few releases out there and people have been testing it more.

@anon71687268

IMO, the code should have been setup outside of ClassicPress and with it’s own communication channels.

I don’t agree with this. I think there is a lot of value in providing a subforum and a Slack channel, and an unofficial place on GitHub, using our existing infrastructure. Managing and maintaining an extra subforum etc is not very difficult for us, but setting all of that up from scratch and making sure people know where to find it would take time away from actually building the thing and hurt the project.

So CC is in a space between an official project and a 3rd party project where it is not really either one. I think this is mostly OK but I will share some more thoughts about the name.

@timkaye

the name ClassicCommerce implies that the plugin is somehow attached to, or part of, the ClassicPress project. So, if it isn’t, it shouldn’t have that name.

I agree with this. I think this points towards calling it “Classic Commerce” for now, and possibly making a more general guideline that names like “ClassicSomething” (one word) should only be used by projects that are officially supported by ClassicPress. (Right now, you can tell the difference based on where it lives on GitHub. If it lives under ClassicPress · GitHub then it’s official.)

@timkaye

How did the ClassicCommerce project get taken over? I could well be wrong, but it appears to me that the transition from one lead developer to another happened precisely because of its association with ClassicPress.

This is a feature, not a bug! One of the benefits of storing this code in a central location is that it doesn’t disrupt the workflow to move new people in/out of the project.

@timkaye

So if this e-commerce project is not to be brought somehow under the ClassicPress umbrella, there should be a clean break in terms of repos, forums, etc as well as in name.

Here we come back to the question of “what is a research plugin”. I think it is worth clarifying further, but here is what we have so far (from ClassicPress Research · GitHub):

Does that help any, or muddy the waters further?

Also, moderators please don’t split this thread - I am going to update the thread title instead. We have been discussing two issues here but they are pretty closely related.

[norske]

Naming
Notice that the original project name is ClassicPress, not just Classic. This makes some difference to me. From that point of view, it’s not quite right to restrict “ClassicSomething” names.

Yes, such a name can be associated with CP, but I don’t think we can forbid this. CP pretends to be an ecosystem. And it’s a widespread naming practice for satellite projects to mention a recognizable part of a brand to conquer the target audience. E.g. Windows / WinRar, Instagram / InstaTools and so on. WordPress / ClassicPress

The word “Classic” is not our property, isn’t it? If someone would develop a plugin “ClassicMusic” it may be confusing, yes, but it’s ok. Some people think that FaceApp is a Facebook-driven project, but Facebook is not responsible for that mess.

Plugin status
In general, my vision is very close to @james thoughts. (I just write posts much slowlier )

Really think that we shouldn’t throw any projects out of the infrastructure (Slack, Forums, Github etc) at least at this stage. CP community is rather small now. It needs as much consolidation as possible to increase its summary value, weight and influence. This is very important for the “external” point of view. Each project which focuses on ClassicPress and positions it as the primary development platform is quite valuable. It can bring here additional attention, contributors, partners, users, clients. More activity, more buzz — better chances for promotion and integration with other projects (hosters, providers, agencies, studios etc) for all of us.

To my mind, we now have 3 “levels” of projects within this ecosystem.

1. ClassicPress itself (and potentially core plugins).
2. Community-driven projects (which are inspired by ClassicPress and give it a high priority).
3. 3d-party projects (which are build foremost for WordPress, but add CP support, too).

So, technically I agree with @anon71687268 that number 2 is not a part of number 1. But considering all the things above I think we should treat those 2-level projects very carefully and even encourage (foster? stimulate? – not sure about wording) them. Slack channels, Forum threads — fine!

However this doesn’t mean that such projects should have any direct competitive advantages towards 3d-party plugins (in ranking etc). This only means that we should stimulate communication and sharing the experience between ClassicPress contributors, the community and other enthusiasts. BTW this also helps everybody to stay in touch and avoid WP-alike scenario (Core team vs Community vs Plugin devs).

For example, I haven’t contribute to ClassicCommerce yet (and I’m not sure that I’ll have time for that), but I follow this channel in Slack, see familiar people there, find tons of useful notes about Github (thanks @james once again) and stay in course. Even drop my 0.02 cents if needed. But if this project moves to another platform, I’ll unlikely follow it.

We are not so big to search for separation. 20-30 active contributors for all projects, probably? Let’s think about it when we reach the line of 200-300

[Simone]

@james

I don’t agree with this. I think there is a lot of value in providing a subforum and a Slack channel, and an unofficial place on GitHub, using our existing infrastructure. Managing and maintaining an extra subforum etc is not very difficult for us, but setting all of that up from scratch and making sure people know where to find it would take time away from actually building the thing and hurt the project.

It also helps to keep developers “in”.
If an independent developer can find here a good place for sharing suggestions this can stimulate her/his contribution to the project.

Maybe some extra suggestion about names usage, ecc… can clarify some situations.
For example, I’ve three little plugins: for CPcompatibility the name seems good for me as it is strictly related with ClassicPress, but a disclaimer about that it’s not an official plugin can be added to the readme; for xsx-debug I think that’s ok; for CPvars I think I should rename it (maybe xsx-vars or something fancy that explains better what is it for ).

Simone.