Deepsource badges

[MichaelHinrichs]

📋 Description

For Deepsource

🔗 Data

https://docs.deepsource.com/docs/api

🎤 Motivation

To make badges out of the stuff in the screenshots.

[PyvesB]

Hello @MichaelHinrichs 👋🏻

You've created over thirty issues and pull requests in the course of less than a month. That's a lot, and arguably more than the combined activity of everyone else on this repository over the same time period!

Unfortunately, many of them are below what we'd expect in terms of quality:

• project guidelines are often not followed (#10365, #9751, #10287).
• the same points often need to be repeated more than once (#10368, #10367, #9750).
• pull requests fail CI due to invalid Javascript or due to skipped linting/formatting steps.
• some issues are duplicates (#10295).
• the issue template is rarely followed. In this one for example, all three sections are hastily filled out and missing requested pieces of information. I've personally got little idea of what specific information we'd show in a Deepsource badge, which specific API endpoints we'd leverage, what the auth and rate limit constraints are, whether this badge would actually be a good use case and popular amongst Shields users, etc. Information should be readily available without others having to go hunting through links and digging out the information on their own.

I appreciate the fact that you're enthusiastic about Shields.io and have lots of ideas, and that's okay! But right now, all the problems listed above are incurring an unfair burden to our small maintainer team, and consequently not impacting the project in a positive way.

Going forward, may I kindly request that you:

• carefully read through our contributing guidelines and our badge specification.
• test and validate your changes locally before opening a pull request.
• properly follow the issue template. Here are a few examples of issues where the author dedicated extra effort to research relevant information: #9846, #7929, #7926.

This will hopefully ensure that everyone's time is used in the most efficient manner and that interactions are more constructive in the future. Thanks for your consideration 🙏🏻

[MichaelHinrichs]

This is how I work. I get hyperfixated. https://github.com/google/magika/issues/152

[chris48s]

Agree with @pyvesb 's comments on this. I don't want to re-cover the same ground too much, but a few extras from me. If you plan to raise more requests for new badges, here's some points that can help make them more useful:

• For APIs that require auth, there are 2 models we can use: https://github.com/badges/shields/blob/master/doc/authentication.md If you are requesting a badge and the upstream API requires authentication, have a think about how (and if) the service can fit into either of those models. Maybe sign up for an API key and see what data an authenticated user can/can't access. That will help filter out requests for services that just won't be possible to implement.
• When we review pull requests, we prefer contributions that focus on a single badge or a small number of them. They're quicker to review and more likely to get merged. If you're opening an issue to request badges for a new service, highlight what would be the most useful or important data points. What is the one you most want to put in your README to help your users? If someone is interested in working on this issue you've raised, where should they focus first? That would be more helpful than suggesting lots and lots of data points that could go on a badge.
• We can produce badges for services that provide data via an API, but badges that require us to run a tool locally to derive the data ourselves are impractical for us.