[Wordpress] Plugin Issues Badge

[JoeIzzard]

Related to #5493, this PR adds the Plugin Issues badge's. These include several styles, so may need to strip some out to be more inline with other services; I kinda just made everything I think someone may want in a badge. This includes:

• Raw (Open & Closed)
• Percentage (Open & Closed)
• Out of (Open & Closed, eg: |open issues| 20/100 |)
• Open/Closed comparison (Short or long format eg: |open/closed| 20/80| or |issues| 20 open, 80 closed | )

[shields-ci]

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

Generated by 🚫 dangerJS against c0b700f

[calebcartwright]

From what I recall, the raw vs non-raw distinction is primarily used in rendering to control if/where the status (e.g. open or closed) appears. issues and issues-closed as the noun portion of the badge route is what allows for badges that differentiate between the count of open and closed issues respectively.

Is that what's implemented here?

[JoeIzzard]

I think this was mostly from me tackling it late at night without putting brain power in & getting carried away making badges!

So I was using raw to mean just the raw number, as in 10 open issues, to separate it from the badges that are doing some kind of comparison/math, like percentage or open/close. Then open or close as another to switch between them. I agree I have done it in a confusing way, just can't think how to make it simpler?

[calebcartwright]

I agree I have done it in a confusing way, just can't think how to make it simpler?

I'd suggest taking a look at the GitHub Issues badges and maybe the one for Bitbucket as well. One of our primary goals is consistency across our badge offerings, and I think we should be able to align these issue badges with our existing ones, barring any wildly divergent wordpress-specific context.

[JoeIzzard]

From what I can see, my use of raw is somewhat inline with it's use else where, for example GitHub Issues are as follows:

Issues
Issues Raw

Most of the difference for mine comes from using a more pronounced separation, for example, where you may use issues-raw I have used issues/raw, same with open/close status. I will work back through and refactor to use more standard patterns and such.

The only other difference is, I have added more 'flavours' such as percentage open/closed. Would we be better to remove these and instead just provide an open/close with no style variants?

[calebcartwright]

From what I can see, my use of raw is somewhat inline with it's use else where, for example GitHub Issues are as follows:

I see what you meant now. I was a little confused by the wording in the description (Raw (Open & Closed)) and wanted to make sure you weren't saying that Raw for these badges would mean the sum of Open and Closed issues. All set now though

The only other difference is, I have added more 'flavours' such as percentage open/closed. Would we be better to remove these and instead just provide an open/close with no style variants?

No I think these are worthwhile badges to provide and not suggesting that they be removed. It's more about how to best represent them.

Most of the difference for mine comes from using a more pronounced separation, for example, where you may use issues-raw I have used issues/raw, same with open/close status. I will work back through and refactor to use more standard patterns and such.

We follow pretty specific patterns for our badge routes (https://github.com/badges/shields/blob/master/doc/badge-urls.md#badge-url-conventions), and although I can understand the thinking that issues would be the noun I don't feel that's really the case. There's fundamentally different messages/information conveyed between the raw/percent/outOf variants, regardless of the fact that the derivation of their values work with the same general data points.

As an example, we provide badges that display the maintainability rating from CodeClimate as either a percent or letter grade (both based on the exact same underlying data point from the provider), but because these are different values the route uses separate nouns
https://img.shields.io/codeclimate/maintainability/angular/angular
https://img.shields.io/codeclimate/maintainability-percentage/angular/angular

We're going to want to do the same thing here, as raw/percent/outOf aren't just parameters, they fundamentally change the badge message value.

Again I think the GitHub Issues Service Class can serve as a good reference

shields/services/github/github-issues.service.js

Lines 42 to 46 in f1a5dd9

	static route = {
	base: 'github',
	pattern:
	':variant(issues|issues-closed|issues-pr|issues-pr-closed):raw(-raw)?/:user/:repo/:label*',
	}

I also feel like there's a lot of duplicative functions between the two classes that currently exist, and would like to see them cleaned up. Two approaches would be introducing a new file that contains those as helper functions or creating an additional Issues Base class that the others extend. You may find it easier to address the route updates by splitting some of those into separate classes, and having the common stuff encapsulated somewhere will help!

[JoeIzzard]

Awesome.

Yeah, I'll go back through and sort out the route's to fit Shields better. I will also look at how best to reduce the amount of duplicative functions and streamline things a bit better.

[PyvesB]

@JoeIzzard any chance you could circle back to this? It would be great to get the remaining Wordpress pull requests landed. 😉

[PyvesB]

Given that there hasn't been any activity for a while, I'm going to close this pull request. Feel free to ping us or reopen it if you get a chance to look into it again. 😉

If someone else wants to pick this up, you can simply fetch the commits by running git fetch origin pull/5721/head:pr-5721. Address the pending review comments and open a new pull request with a co-authored trailer included in the commit message to give attribution to the original author.