Add a Shields logo for Bazel

[calebcartwright]

There was a recent proposal and some discussion related to adding a Shields logo for Bazel, though that initial PR was closed by the author and the conversation in that PR evolved past the point of being an optimal place for discussing if/why/when we should add the logo (refs #9474 and #9475).

I'm not a Bazel user myself and would have no use for any Bazel related badges, much less a logo, but I've opted to open this to focus on the merits of adding a native Shields logo for Bazel and if/how well it fits some of the criteria we'd look for (n.b. #9476 is also relevant/potentially a blocker in execution insofar as we need to decide if we're willing to take on new logos at all)

For reference our current docs enumerate the following considerations:

• We have a corresponding badge on the homepage, (e.g. the Eclipse logo because we support service badges for the Eclipse Marketplace). We may also approve logos for other tools widely used by developers.
• The logo provided in SimpleIcons is unclear when displayed at small size on a badge.
• There is substantial benefit in using a multi-colored icon over a monochrome icon.
• The logo doesn't meet the requirements to be included in the SimpleIcons set.

And in #9476 I also suggested some additional considerations:

• a vendor/brand owner (or someone operating explicitly on their behalf) came to us with a PR to incorporate their logo because the monochrome SI route wasn't viable because doing so would ruin/break the brand identity
• vendor/brand representative explicitly agreed they'd follow up if/when they had a branding change that needed to be reflected in the logo (as opposed to giving us flak for the "shields" logo being outdated)
• there was a sizeable portion of our user base that wanted to use the logo
• the logo was too big to be used via the custom logo feature in the url (node.js' hard limit on the header size)

I'd suggest it's worth discussing how a Bazel logo fares across those 8, as well as any other factors that make a strong case for why we should have a native logo vs. deferring to SimpleIcons and/or our custom logo feature

(edits: minor, semantic-preserving additions)

[calebcartwright]

As far as my personal view/response across those points of consideration:

We have a corresponding badge on the homepage, (e.g. the Eclipse logo because we support service badges for the Eclipse Marketplace). We may also approve logos for other tools widely used by developers.

We don't have a badge, but bazel is obviously used widely. That being said, I don't know if we have any precedent for accepting a logo in the absence of an existing/planned badge?

The logo doesn't meet the requirements to be included in the SimpleIcons set.

It does, at least AIUI, though an effort to add it petered out simple-icons/simple-icons#5573

The logo provided in SimpleIcons is unclear when displayed at small size on a badge.
There is substantial benefit in using a multi-colored icon over a monochrome icon.

I can't speak to the specifics, although this seems to potentially be valid here based on #9474 (comment), though it'd be good to get some type of "official" confirmation of that from someone directly affiliated with Bazel IMO

a vendor/brand owner (or someone operating explicitly on their behalf) came to us with a PR to incorporate their logo because the monochrome SI route wasn't viable because doing so would ruin/break the brand identity

This has a lot of overlap with the prior considerations/is somewhat duplicative

there was a sizeable portion of our user base that wanted to use the logo

This is the big unknown one for me. Bazel is widely used, but at the risk of stating the obvious, not every Bazel user is a Shields user, and even the subset of Bazel users that would use a Bazel-related badge from Shields would not unanimously use a logo. Would be good to try to get a feel for the appetite of our users around the interest/likely usage of such a logo, perhaps we could run a poll (or a tweet or x or w/e it's called these days 😆) if/when we get to that point?

the logo was too big to be used via the custom logo feature in the url (node.js' hard limit on the header size)

Haven't checked personally and don't have the time to do so, but it would be a helpful data point if someone was sufficiently motivated to do so and willing to share.

[chris48s]

I don't know if we have any precedent for accepting a logo in the absence of an existing/planned badge?

Our current custom logo set includes a variety of logos we don't carry an integration for e.g:

• https://github.com/badges/shields/blob/master/logo/paypal.svg
• https://github.com/badges/shields/blob/master/logo/bitcoin.svg
• https://github.com/badges/shields/blob/master/logo/telegram.svg

One of the many reasons the custom icon set is just a very odd tentacle of shields.

So it sounds like an entirely valid criteria, but also it is one that clearly doesn't apply to the logos that already exist.

it would be a helpful data point if someone was sufficiently motivated to do so and willing to share

You can do it with base64

- https://img.shields.io/badge/bazel-whitesmoke.svg?logo=data:image/svg%2bxml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIGRhdGEtbmFtZT0iTGF5ZXIgMiIgdmlld0JveD0iMCAwIDQzLjU3IDQzLjM3Ij48ZyBkYXRhLW5hbWU9IkxheWVyIDEiPjxwYXRoIGQ9Ik0yMS43OCAzMi42OHYxMC42OUwxMC44OSAzMi40OFYyMS43OWwxMC44OSAxMC44OVoiIHN0eWxlPSJmaWxsOiMwMDcwMWEiLz48cGF0aCBkPSJtMjEuNzggMzIuNjggMTAuOS0xMC44OXYxMC42OWwtMTAuOSAxMC44OVYzMi42OFoiIHN0eWxlPSJmaWxsOiMwMDQzMDAiLz48cGF0aCBkPSJNMTAuODkgMjEuNzl2MTAuNjlMMCAyMS41OFYxMC44OWwxMC44OSAxMC45Wm0zMi42OC0xMC45djEwLjY5bC0xMC44OSAxMC45VjIxLjc5bDEwLjg5LTEwLjlaTTIxLjc4IDMyLjY4IDEwLjg5IDIxLjc5bDEwLjg5LTEwLjkgMTAuOSAxMC45LTEwLjkgMTAuODlaIiBzdHlsZT0iZmlsbDojNDNhMDQ3Ii8+PHBhdGggZD0iTTEwLjg5IDIxLjc5IDAgMTAuODkgMTAuODkgMGwxMC44OSAxMC44OS0xMC44OSAxMC45Wm0yMS43OSAwLTEwLjktMTAuOUwzMi42OCAwbDEwLjg5IDEwLjg5LTEwLjg5IDEwLjlaIiBzdHlsZT0iZmlsbDojNzZkMjc1Ii8+PC9nPjwvc3ZnPg==

[calebcartwright]

Our current custom logo set includes a variety of logos we don't carry an integration for e.g:
One of the many reasons the custom icon set is just a very odd tentacle of shields.

So it sounds like an entirely valid criteria, but also it is one that clearly doesn't apply to the logos that already exist.

Fair and agreed. I don't have the full history behind the existing set (believe all but perhaps a couple long predate me), nor do I know whether they were added prior to this current set of guidelines existing.

This is one we can and should drill into as part of #9476 if we decide to keep the door open for new logos

[calebcartwright]

Closing as this is not something we're going to do given the decision in #9476 to drop all such logos