Poggit - Public Consultation

Poggit consists of a continuous-integration (CI) and a plugin list.

Poggit-CI is primarily used for building phar builds from source code for PocketMine plugin projects hosted on GitHub. After you authorize the Poggit application on GitHub, you can enable Poggit-CI for some of your projects, and Poggit will start building phar builds and carry out basic lint (including basic php -l syntax lint, PocketMine plugin structure lint and other simple inspections that are nothing compared to PhpStorm's inspections) whenever you push a commit or receive a pull request.

Spoiler: Enable Poggit-CI screenshot

Poggit also has a plugin list, but unlike common plugin lists, Poggit's plugin list does not accept uploading phar files. They must be built by and imported from Poggit-CI. After submitting, they are reviewed in a rather complicated scheme:

1. The developer submits a build from Poggit-CI along with additional released information (they are really detailed if you want to!). The build is only visible to staff members.
2. A staff member carries out a quick and basic check to confirm that this plugin cannot cause more harm than deleting player data on your server, no malicious code, and not too simple to be released as a standalone plugin.
3. The release is now only visible to all/some registered users on Poggit (register with GitHub). These users can review the plugin. When enough users approve the release, it is visible to all users and guests on the website, but with limited features (these features will be introduced in Poggit v2.0, which is far from us now).
4. Official plugin reviewers will review and test the release. If the plugin is considered acceptable, it will be officially approved with all features enabled.
5. If official plugin reviewers found the plugin meaningful enough to be featured, it will be displayed as a featured plugin. This "Featured" status is only effective on a single release, but does not affect its earlier/later commits.

Some details are not included if they are not controversial enough.

We would like to ask for your comments on the plans (actually some of them are already implemented) mentioned above.
We would also like to invite for ideas on some names:

• What should be the proper name of the plugin list (like CI for the other part)? It is currently called "Release", but it is a generic noun and is not specific enough to be introduced as a proper noun.
• How should we accurately name the status of the different steps in the review? Currently we are using these names, but their meanings are not inclusive enough:
  • Draft (before the release is submitted to staff members for quick review)
  • Submitted (submitted but not quick-reviewed)
  • Checked (quick-reviewed by staff, but not approved by the community yet)
  • Voted (approved by the community)
  • Approved (fine-reviewed by staff)
  • Featured
• How do we decide who can vote on plugins, as well as the weighting of their votes? What kind of people should be able to vote (or have more votes)?
• Other things that you think are important.

 

What if the plugin developer creates spam accounts to vote for his own plugin until it gets approved?

 

I have been thinking about this (better more likes), but it is quite difficult to work with the Forums API, and it is still possible that people can create ring accounts (account A likes account B, account B likes account C, account C likes account A again), and I want some people to have more votes, and we are seeing some like spammers on the forums.

 

That's manual verification. Not reliable enough to be used automatically.
Another suggestion: If we hold plugin contests regularly, the prize could be an extra vote when approving plugins.

 

I would say "or need less" because even the best people can make big mistakes that it takes a second person to pick up on. It's not so much trust as it is quality assurance.

 

Difficult to design, code and explain in words. But we plan to create an SVG graph that shows a flowchart of plugin approval to developers who care about it, so it is rather easy to understand in that way. Actually the developers don't need to understand this; as long as they know that you need to wait for somebody to review, that's enough.

The first check is really quick. For simple plugins it can complete in one or two minutes, and for bigger plugins like EssentialsPE, it should take no more than ten minutes. We are just checking for suspicious or terrible code, and that kind of code should be obvious to experienced developers.

Yes, but not too much. We are just viewing the source code by skimming, and we are not gonna accept obfuscated plugins. Plugins that passed this point are still potentially dangerous, but at least obviously malicious/spam ones would be banned.
We also check the plugin description at this point, just to see if the plugin is doing something we don't want to do, or the code is obviously not doing what it claims to do.

Some future features (actually privileges) that a fully-released plugin should enjoy. This is actually not finalized, and any discussion or suggestions of what should be additionally provided for plugins that have been completely approved are welcome.

This is what we are discussing, about who can vote.

Agreed. We are going to provide links as simple as poggit.pmmp.io/p/PluginName, and direct latest version download links like poggit.pmmp.io/p/PluginName/latest

There seem to be a lot of bottlenecks, but in the end they are not that bad.
We expect to have a bigger (and probably looser) number of reviewers at the first check so that it can ensure that plugins can pass it really smoothly.
For the second check, i.e. community review, it is optional, and it only makes plugins visible to the public more quickly before the third check. If we have reviewers available, plugins can go to stage 3 and fully release without passing stage 2.
For the third check, i.e. more careful review, you can assume, at worst, that it is similar to what happens on old forums, but I hope we can have more manpower than just one like in the past.

Yep, planned
Have a look at the temporary release submission interface:

Spoiler: Some screenshots

So as you can see, there are some detailed information to put. It is not necessary that the developer look at all of them, but setting them properly can help future automated tools (such as automatic plugin installers/updaters) know better about the plugin being installed and decide on extra actions to perform.

This is a bit more troublesome since we so far haven't been very successful in handling forums integration.

Or just add them as reviewers

Fact: @shoghicp used to approve his plugins straight away!
Well, if they are confident enough, they can approve their plugins directly since they (both personality and ability) are trusted enough, or if not, wait for someone else to review

 

Too late. NIH again. But I don't think the code looks bad

What's wrong with it? If you are referring to the "Recent Builds" list, it is not a plugin list. It is just random builds to show up to be "discovered". They don't even need to be "recent" actually, because any random builds could work as well

Lowest priority of all