[Gratipay] Replace with error message

[paulmelnikow]

Gratipay is gone :(

For #1359

This failure from https://circleci.com/gh/badges/shields/1411?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

  7) Gratipay
       Receiving

	[ GET http://localhost:1111/gratipay/Gratipay.json ]:
     ValidationError: child "value" fails because ["value" with value "invalid" fails to match the required pattern: /^\$[0-9]+(\.[0-9]{2})?\/week/]
      at Object.exports.process (node_modules/joi/lib/errors.js:190:19)
      at internals.Object._validateWithOptions (node_modules/joi/lib/types/any/index.js:669:31)
      at module.exports.internals.Any.root.validate (node_modules/joi/lib/index.js:139:23)
      at Object.pathMatch.matchJSONTypes (node_modules/icedfrisby/lib/pathMatch.js:303:9)
      at node_modules/icedfrisby/lib/icedfrisby.js:703:10
      at IcedFrisbyNock._invokeExpects (node_modules/icedfrisby/lib/icedfrisby.js:1294:33)
      at start (node_modules/icedfrisby/lib/icedfrisby.js:1274:12)
      at Request.runCallback [as _callback] (node_modules/icedfrisby/lib/icedfrisby.js:1232:16)
      at Request.self.callback (node_modules/request/request.js:186:22)
      at Request.<anonymous> (node_modules/request/request.js:1163:10)
      at IncomingMessage.<anonymous> (node_modules/request/request.js:1085:12)
      at endReadableNT (_stream_readable.js:1056:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickDomainCallback (internal/process/next_tick.js:218:9)

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @paulmelnikow!

Generated by 🚫 dangerJS

[chris48s]

I think this PR should also remove the examples from all-badge-examples.js given the service has completely shut down.

[chris48s]

Thinking about it, in the other case where this has been done (pypi downloads), the error response is grey: ( https://img.shields.io/pypi/dm/Django.svg )

It would probably be good for these 'deprecations' to use the same colours. I don't have a strong opinion on whether red or grey is the right choice though.

[RedSparr0w]

Agreed probably best to either update the pypi downloads badge color to red or this one to lightgrey.

We definitely need to figure out some sort of plan of action for future depreciation of badges.
There was some talk about it in #1387

@paulmelnikow:
In the long run, we should think about designing an approach to badge deprecation. For example, we could launch the new badge, then a little while later add a deprecation warning to the old badge, and a while after that redirect to documentation or turn it off entirely.

@RedSparr0w:
Maybe a symbol at the end or logo at the beginning for soon to be depreciated badges ,
then change the badge to or similar
before completely removing it, returning

[paulmelnikow]

Yea, agreed we ought to make these consistent. I thought of switching this one to gray but couldn’t decide which color made more sense.

Good call on removing the badge examples from the website. One thought, we might want to mark them deprecated while keeping them in the codebase. That way we have a record of our deprecated badges, while they’re rolling down the path from working to 404.

Let me sleep on the color question…

[espadrine]

@RedSparr0w:
Maybe a symbol at the end or logo at the beginning for soon to be depreciated badges ,
then change the badge to or similar
before completely removing it, returning

I feel like keeping the left-hand-side of the badge helps understand what got lost.

Otherwise, normal users looking at badges on a website or a README are left scratching their chin to understand what that badge was originally meant to do.

[RedSparr0w]

Good point,

So i guess the last things to decide are:

• What colorscheme they are going to use?
  👍
  😄
  🎉
  ❤️
  😕
• How long they should be kept around as the no longer available badge before being removed and returning 404? or keep them indefinitely?

[RedSparr0w]

Any verdicts on the color? would be great to get this merged 😄

[PyvesB]

Personally, I would rather go for the light grey version:

In my opinion, colours should only be used to catch the eye when we do have useful information to convey, for instance red when a build is failing, and stick to grey when the information is not available for whatever reason. This is also more consistent with what we do in some other places.

Regarding how long we should keep the "no longer available" badge around, does ~1 year seem like a reasonable amount of time? Even if the relevant commit takes some time to be released to production, it still leaves project owners a very comfortable margin to notice and remove the badges from where they're being used.

[chris48s]

+1 for light grey. Agree with @PyvesB 's reasoning

[paulmelnikow]

Regarding how long we should keep the "no longer available" badge around, does ~1 year seem like a reasonable amount of time? Even if the relevant commit takes some time to be released to production, it still leaves project owners a very comfortable margin to notice and remove the badges from where they're being used.

I think a year is good. It's long enough that we don't have to worry about how long we might wait until deploy.

It'd be cool to write a utility function to help with the deprecation. It could (1) automatically stop registering endpoints when they have passed the deprecation timeline and (2) throw errors in unit tests so we know it's time to remove the code.

Looks like we're all in favor of gray for badges that are gone.

Seems there's still a question about how to display an indicator for badges that are "deprecated but not gone yet". How about this?

1. Deprecated: when we know ahead that it's going away
   
2. When it's gone
   
3. After ~ 1 year