aboisier / sauce-radar Goto Github PK

🌕 What's this all about?

Customers must be able to upgrade from your app's UI if you provide an upgrade URL in this format: https://www.github.com/marketplace/<LISTING_NAME>/upgrade/<LISTING_PLAN_NUMBER>/<CUSTOMER_ACCOUNT_ID>

From the doc:

About upgrade URLs

You can redirect users from your app's UI to upgrade on GitHub using an upgrade URL:

https://www.github.com/marketplace/<LISTING_NAME>/upgrade/<LISTING_PLAN_NUMBER>/<CUSTOMER_ACCOUNT_ID>

For example, if you notice that a customer is on a 5 person plan and needs to move to a 10 person plan, you could display a button in your app's UI that says "Here's how to upgrade" or show a banner with a link to the upgrade URL. The upgrade URL takes the customer to your listing plan's upgrade confirmation page.

Use the LISTING_PLAN_NUMBER for the plan the customer would like to purchase. When you create new pricing plans they receive a LISTING_PLAN_NUMBER, which is unique to each plan across your listing, and a LISTING_PLAN_ID, which is unique to each plan in the GitHub Marketplace. You can find these numbers when you List plans, which identifies your listing's pricing plans. Use the LISTING_PLAN_ID and the "List accounts for a plan" endpoint to get the CUSTOMER_ACCOUNT_ID.

🌕 What's this all about?

Apps will go through a security review before being listed on GitHub Marketplace. A successful review will meet the requirements and follow the security best practices listed in "Security review process." For information on the review process, contact [email protected].

🌕 What's this all about?

Customers must be able to see the following changes to their account immediately in the billing, profile, or account settings section of the app's website:

• Current plan and price.
• New plans purchased.
• Upgrades, downgrades, cancellations, and the number of remaining days in a free trial.
• Changes to billing cycles (monthly or yearly).
• Usage and remaining resources for flat-rate and per-unit plans. For example, if the pricing plan is per-unit, your app's site should show units used and units available.

🌕 What's this all about?

The user can visualize metrics on their dashboard

• Average time from PR creation to merge through time
• Average number of comments per PR through time
• Average time until first comment on PRs through time

The user can filter or see these metrics per PR author

🌕 What's this all about?

In order to respect the guidelines.

Customers who cancel a paid plan purchased from GitHub Marketplace must be automatically downgraded to the app's free plan if it exists. When a customer cancels a GitHub Marketplace subscription, GitHub does not automatically uninstall the app, so the customer can expect that free features will continue to function. It's highly recommended to allow customers to re-enable their previous plan.

🌕 What's this all about?

In order to both attract users but generate revenue.

🌕 What's this all about?

To sell your app in GitHub Marketplace, it must use GitHub's billing system. Your app does not need to handle payments but does need to use "GitHub Marketplace purchase events" to manage new purchases, upgrades, downgrades, cancellations, and free trials. See "Billing flows" to learn about how to integrate these events into your app. Using GitHub's billing system allows customers to purchase an app without leaving GitHub and pay for the service with the payment method already attached to their GitHub account.

🌕 What's this all about?

Listings must include descriptions that are well written and free of grammatical errors. For guidance in writing your listing, see "Writing GitHub Marketplace listing descriptions."

🌕 What's this all about?

Customers must be able to see that they have a free plan in the billing, profile, or account settings section of the app.

🌕 What's this all about?

The app must follow these guidelines: https://github.com/logos

🌕 What's this all about?

• So that I can prevent merging if there are unresolved comments
• So that I can easily see if all the comments were resolved

🎇: https://docs.github.com/en/developers/apps/creating-ci-tests-with-the-checks-api

🌕 What's this all about?

When a customer cancels your app, you must follow the flow for cancelling plans.

🌕 What's this all about?

Apps must have a logo, feature card, and screenshots images that meet the recommendations provided in "Writing GitHub Marketplace listing descriptions."

🌕 What's this all about?

Currently, if there is an error in the config file and the user fixes them, the rules are not reran on existing PRs. An update in rules should maybe rerun a scan on all existing PRs?