Connect to GitHub along with scoring system and badges

@mehulgohil Really well thought out. Thank you for the detailed breakdown.

The core idea is solid and I agree it fills a genuine gap in the WordPress ecosystem. Showing engineering quality signals alongside contribution data would make WPFolks profiles genuinely useful for hiring decisions, not just community recognition.

My plan would be to start with the four most objective and automatable signals: WPCS compliance, PHP 8.x+ compatibility, basic security checks, and CI/CD adoption. These can be verified automatically via GitHub Actions without building a custom analysis engine.

PHPStan and test coverage are valuable but require more nuance before adding to a scoring system. I want to avoid penalising good developers whose plugins are not the right shape for those tools.

Adding to the roadmap. Would love your help defining the exact criteria for each badge when we get to building this.

@wpankit Integrating GitHub for quality checks is a good start. However, there are few restructuring required. Not everything immediatelym but gradually. I haven’t expected it to be integrated immediately with badges and scoring system. But, you did a great job so far.

If we can integrate the GitHub app integration in a way where we can collect the common details:
1. For WPCS, we need look for files like phpcs.xml or phpcs.xml.dist or .phpcs.xml or .phpcs.xml.dist
2. For PHPStan, we need files look for like phpstan.neon or phpstan.neon.dist or phpstan.neon.php
3. For GitHub actions usage, do we have yml files in workflow and are those used for release or prerelease workflow, does that include running npm and composer commands and artifacts creation, automating deployment to svn or any third party server
4. Use of PHP Namespacing for autoloading, we can know with composer.json
5. For PHPUnit, does composer.json have phpunit package installed (same goes for additional check for PHPStan or WPCS)
6. Using package.json, have we minified js, css, image, fonts, or have separate builds for dev and production?, automating textdomain and language files?
7. Does the repos have .editorconfig?
8. Does the repo use Prettier or any other known similar tool?
9. Does the repo use ESLint or similar?

These are some of the possible scenarios, it can go deeper as well. But, that will be determine whether how much control we have after connecting with each folk’s GitHub account.

Note: We should avoid scanning a GH repo that doesn’t have known WP plugin or theme to reduce the overall burden in checking code of all the repo’s.

In addition to this, I think we will need to refine the badge system to ensure that we can accomodate the needs. I will create a separate ticket for badge refinement which is related to this. but will give you a quick idea on what i am thinking. The thought is that we can have individual badges which we are already having but some badges make more sense when it is shown in levels. For example, for referral, Connector is the first badge in that category who brings first 5 verified referral will get that. but once the folk crosses 10 verified referral, folk will be levelled up to Community Builder instead of getting both badges. This grouping of badges in terms of levels is essential as we grow the amount of badges will grow too.

In the same manner, we should decide the scoring and based on that define the levels for Automation, Security, Performance, Coding Standards, and more badges and each will have levels like, Starter, Intermediate, Expert, Legend based on some predefined criteria.

There are too many moving pieces, but looking forward to your thoughts. I will get back with more information once I do some more brainstorming. Thanks!

Thank you for this, this is exactly the kind of thinking that makes a feature worth building.

You are right on all three points and I want to address each:

File-based detection instead of scanning
This is smarter and more respectful. Checking for config files like `phpcs.xml`, `phpstan.neon`, `.editorconfig`, and `package.json` tooling tells us the developer has made deliberate choices about code quality without scanning their code. Adopted immediately.

Badge levels instead of stacking
This is the structural change the badge system needs. One badge per category, levelled up as thresholds are crossed. Connector levels up to Community Builder levels up to Hall of Fame, not three separate badges. This scales cleanly as new levels are added. Creating a dedicated ticket for badge system restructuring makes sense and I will work through it when you share your thinking.

Only scan WordPress plugin and theme repos
Hard agree. Detection should only run on repos with a valid `readme.txt`, plugin header comment, or theme `style.css`. Everything else is ignored. Reduces API burden, respects privacy, keeps the signal relevant.

The full detection matrix you outlined covering WPCS, PHPStan, GitHub Actions, PHP namespacing, PHPUnit, frontend tooling, editorconfig, Prettier, and ESLint is going into the spec. I will build this incrementally, metadata detection first, then progressively deeper signals.

Really appreciate you taking the time to think this through properly. Looking forward to the badge refinement ticket.