For many years, I have been involved in reviewing submissions for the Concrete CMS Marketplace. Entry into the marketplace is not a rubber stamp exercise. Every submission is reviewed and tested before approval. Here is my stab at guidance notes, in no particular order. Many of these points are not absolute requirements. For example, if we think a submission could generate more than usual support requests, we may warn the developer, but not deny approval. Everything is a matter of judgement, based on experience and to a great extent on intuition.

General

• Can we understand what it does or is supposed to do?
• Is the name allowed - does it infringe prior names or 3rd party names?
• Does it do what it says on the tin?
• Will it generate excessive support requests?
• Would a prospective user/buyer be happy with their download/purchase?
• We may ask the developer questions about what they have done and why.
• What test environment is needed to install and test it?
• What can the developer do to facilitate the review? For example, if it won't fully run on a simple localhost test system, we may ask them to provide a test site.

Code

• Linter (static analysis) issues - Why? Are they justified? Can they be reduced?
• Can we understand how it works (within reason)?
• Are text strings translatable with the t() function.
• What core versions is it supposed to work with?
• Does it follow Concrete CMS conventions?
• Deprecated code.
• Dangerous code.
• Security.
• Poorly structured code.
• Is it self-consistent?
• Does it look nice?
• Is everything that can/should be contained in scope actually contained?
• Anything that could/does interfere with core functionality or theme?
• Anything that could/does interfere with other packages?
• Dependencies?
• Is everything licensed and used within the scope of its license?
• Is there anything unused or otherwise unnecessary in the code?
• Does it break anyone’s copyright?
• Are there viable core alternatives to any vendor code?
• Themes - naming of areas, migration from/to Atomik.
• Blocks in appropriate block groups.
• Override templates and overrides generally.
• Does it look like a copy/paste from stack overflow or other source?

Execution

• Does it install and uninstall cleanly?
• Does it update?
• Can we work out how to use it? Could the average site owner work out how to use it?
• What further instruction do we need to use it (ie, what is missing)?
• Any suggestions on improving usability
• Is there anything unnecessarily difficult about using it?
• Any suggestions on improving functionality
• Does it do what it is supposed to do?
• Can we break it?
• Can it break, obstruct or interfere with anything else?
• Can it copy/paste, be used in stacks, global areas, multiple copies on a page etc.

What we don’t require

• It doesn’t need to be structured like the core or like its just escaped from a computer science lab. But we do like code to be consistent within itself.
• We don’t care about price, but may offer an opinion.
• It doesn’t matter if we think the concept is not of much use, as long as the developer has a use (within reason)
• It doesn’t need to offer unique functionality, as long as it does not break anyone else’s copyright.

Whilst the above is a list, its not a checklist. When I reflect on my own reviewing, my experience homes in on problem areas specific to the Concrete marketplace. I can’t really describe them, I just look at an addon or theme and have an intuition of where the problem areas could be. In their own ways other reviewers also have a feel for problem areas and home in on them. We overlap on this, but have our own expertise.

Everything is a judgement. Every review is different. No code is perfect. Are the issues sufficient to need fixing for marketplace approval?