Feature: Add bazel logo

[sgammon]

Bazel is a popular open source build system by Google. It has some pretty compelling adoption. This PR adds a Bazel option for the logo parameter. The SVG in question is extracted directly from Bazel's logo artwork.

Inspired by bazel-contrib/bcr-ui#29. This work may continue, if appropriate, to add a Bazel Central Registry version badge.

cc / @alexeagle @hobofan

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @sgammon!
📖	🎨 Thanks for submitting a logo. Please ensure your contribution follows our guidance for logo submissions.

Generated by 🚫 dangerJS against 6dcafa3

[sgammon]

preview of this same SVG in use as a data URL, on this project:

[PyvesB]

Hello @sgammon 👋🏻

Thanks for the contribution. As per our logo guidelines:

Our preferred way to consume icons is via the SimpleIcons logo. As a first port of call, we encourage you to contribute logos to the SimpleIcons project.

Could you please contribute the logo upstream? It looks like they would be open to adding such a logo there(see simple-icons/simple-icons#5573 and #9474).

[sgammon]

@PyvesB I contributed this logo here because it follows the other requirements in the guidelines:

In some cases we may also accept logo submissions directly. In general, we do this only when:

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.

Particularly:

We may also approve logos for other tools widely used by developers.
There is substantial benefit in using a multi-colored icon over a monochrome icon.

Bazel's icon doesn't work in monochrome, because the shades of green denote the different leaves in the graphic. When expressed in pure green or gray, the logo blends together enough to be unrecognizable.

Bazel is a build tool by Google used by millions of developers, including such companies as both Uber and Lyft, so we thought it was best to contribute directly. I'm sorry, but I really don't want to contribute to another project in order to use them here. I worry that SimpleIcons would reject such a contribution and the risk of that rejection makes me feel like I just shouldn't try to improve Shields at all. Cheers

[sgammon]

I understood the guideline you cited is a "preference," being that the language says

In general

In some cases

We may also

If this guidance should be followed in all circumstances, maybe the docs need an update.

[calebcartwright]

@sgammon - I acknowledge it can often be pretty tricky trying to interpret written text, and that I might have gotten the wrong impression. However, the combination of immediately closing the PR and the below quote give me the impression that you might have had a pretty strong reaction, and I felt a need to respond.

👇

the risk of that rejection makes me feel like I just shouldn't try to improve Shields at all. Cheers

In response to a PR like this without any prior issue or discussion, I think it's quite reasonable for one of this project's maintainers to make note of our general procedures and documentation around logos.

If your initial PR description had mentioned that you'd already read our logo docs and included some of the additional context shared in some of your subsequent comments (e.g. concerns with monochrome, your reservations about SI, etc.), then we could've short circuited that standard, initial commentary about general approach to logos.

However, in the absence of such context, we're always going to first note our standard operating procedures, and where relevant, point to docs. If contributing to/improving Shields is something of interest to you, I hope that would still be the case, as I confess I don't personally understand why anything in this thread would have changed that.

If this guidance should be followed in all circumstances, maybe the docs need an update.

I actually agree an update to these docs could be helpful, as I think that subsequent to the last time they were updated we'd taken a stronger position against taking on the maintenance support of new logos and have been contemplating dropping all our native/non-SI logos altogether in favor of SI and our custom logos feature (more discussion in #7684 and issues linked within, if curious for more detail).

This work may continue, if appropriate, to add a Bazel Central Registry version badge.

This seems like it would be a reasonable badge addition, though also seems orthogonal to the custom logo. Would suggest opening a separate issue for this using our issue template if that's a badge that you think would be valuable to the community of users in the Bazel ecosystem.

[sgammon]

@calebcartwright you are welcome to respond.

However, the combination of immediately closing the PR and the below quote give me the impression that you might have had a pretty strong reaction, and I felt a need to respond.

It's not a strong reaction, it's just a firm one.

If your initial PR description had mentioned that you'd already read our logo docs and included some of the additional context shared in some of your subsequent comments (e.g. concerns with monochrome, your reservations about SI, etc.), then we could've short circuited that standard, initial commentary about general approach to logos.

From my PR:

Bazel is a popular open source build system by Google. It has some pretty compelling adoption.

On the adoption page

• Adobe
• Asana
• Braintree
• Canva
• Databricks
• Dataform
• Dropbox
• Etsy
• Flexport
• Google
• Huawei
• Line
• LinkedIn
• Lucid
• Lyft
• Meetup
• Nvidia
• Pinterest
• Redfin
• Snap
• Spotify
• Stripe
• Tinder
• Twitter
• Two Sigma
• Uber
• VMware
• Wix

Open Source adoption

• Abseil
• Angular
• Dagger
• Envoy
• gRPC
• gVisor
• Jsonnet
• Kubernetes
• Selenium

Why would I have included this context, if not driven by the contribution guidelines? Respectfully, did you click the link I included in the PR? I felt that including the list above would be rude because it is so extensive and polluting to the discussion.

If contributing to/improving Shields is something of interest to you, I hope that would still be the case, as I confess I don't personally understand why anything in this thread would have changed that.

If maintainers aren't even going to ask before declining, and are in general not going to click links or read PRs or evaluate them against the contribution guidelines without being asked to, I don't know why I would want to contribute to Shields.

I can just create a shield with a static logo, which is what I already did. I wanted to contribute this upstream so other users could use it; but it is not my job to do that, and so raising the cost of such a contribution, with extensive discussion about whether Bazel meets your standard, immediately caused me to re-evaluate and come to the conclusion that this was no longer worth pursuing. I don't know what your standard is and I have other things to do.

I'm an open-source maintainer myself, so I offer this clarification in the hope that it illuminates how a consumer of your project felt during this process. I have been using Shields for years and never stopped to contribute.

I actually agree an update to these docs could be helpful, as I think that subsequent to the last time they were updated we'd taken a stronger position against taking on the maintenance support of new logos and have been contemplating dropping all our native/non-SI logos altogether

Understandable, and I suppose that could be why this PR got the reaction it did even though it made every attempt to follow the written guidelines for contributing logos.

This seems like it would be a reasonable badge addition, though also seems orthogonal to the custom logo. Would suggest opening a separate issue for this using our issue template if that's a badge that you think would be valuable to the community of users in the Bazel ecosystem

Look, I was just saying that, should a Bazel logo exist, it could be used easily to create a new BCR badge. I intentionally left that work to a future PR so I could ask for maintainer advice first.

If you think filing an issue to that effect would be a good idea, go ahead and do so. I'm not the world's biggest Bazel user and I don't work for Google. I was just trying to get a quick logo in which meets the guidelines and that other projects might want to use; as linked in my PR, our logos are already working fine thanks to the custom logos feature. Following this discussion, and knowing that a JSON endpoint for BCR would be substantially more complex than a SVG logo, I think I will have to pass but will wait with patience if somebody else would like to take it on.

If at any time you feel like this is a contribution you would like to merge, feel free to tag me and I will happily re-open the PR. It seems like you are hinting at that but I don't really want to try and parse what you are saying. You can also just grab my branch and file it yourself too if you would rather not interact with me.

I hope this clarifies, have a great day-

[calebcartwright]

Alrighty then. I am genuinely sorry that this hasn't been a pleasant experience for you, but I feel this is has rapidly become much ado about nothing, and you're being unnecessarily flippant in your commentary so I'm not sure it's worth pursuing this PR as the vector for potentially adding a new logo

FWIW:

• there's nothing in the PR description that obviously conveyed "I read the docs, I see you prefer to start with SimpleIcons but I don't want to go the SI route, and here's why". Regardless of whether you think your mental context carried through in the description, it didn't land with your target audience and a simple follow up/clarification would've sufficed
• you were the one that closed the PR, not the maintainers, and no maintainer has yet said "no" to the logo proposed here
• I'm personally hesitant to take on any more custom logos, but I do think there might be sufficiently compelling reasons to do so in this case provided there's an interest amongst our user base.

I'd be open to shifting such consideration (both for this specific logo and more generally) to a separate issue/discussion and/or a future team meeting

[sgammon]

Could you please contribute the logo upstream?

@calebcartwright how is this not a no?

[sgammon]

I closed the PR after leaving a respectful comment. Then, you replied and asked for clarification. I clarified. I really don't see what is "flippant" about my commentary. I don't know why you would ask for my commentary if you don't want it.

I'd be open to shifting such consideration (both for this specific logo and more generally) to a separate issue/discussion and/or a future team meeting

Okay.

[sgammon]

I feel this [has] rapidly become much ado about nothing

It's not nothing to the millions of Bazel users who would like to use Shields, or to me, as I went to the trouble of filing a PR to contribute it. Then again, it's a logo badge. It really doesn't demand an intense level of discussion. You are either open to merging my change or you are not. At this time, my best understanding is that you are not, so I closed the PR. If you are, you can always tag me.

[calebcartwright]

This came to a natural conclusion some time back, so I'm going to lock this as part of issuing a final set of responses.

To any future readers interested in the logo, at this point more discussion is needed but the door is still potentially open. Probably worth waiting to see if SI decide to incorporate it in some shape or form because if they don't it's then more a consideration for us around the project tradeoffs of a native logo vs. the consumer tradeoffs of the custom logo in the url.

---

---

Could you please contribute the logo upstream?

@calebcartwright how is this not a no?

Because it doesn't say "no". If we were giving you a firm "no", we would've said so and closed the PR ourselves.

Again, in the context of P-Y's comment, it was not yet clear you'd already considered the SI route. This was a "hey let's start here" because that's our process.

I really don't see what is "flippant" about my commentary. I don't know why you would ask for my commentary if you don't want it.

I'd say it's generally in bad taste to do things like informing a project maintainer that they are allowed to comment in the project they maintain and that they can open an issue themselves. Furthermore, phrases that start with the various variants of "respectfully", "with all do respect", "no offense", etc. are typically anything but, especially in digital communication forums between strangers.

Overall I feel there's a marked difference in the tone and choice of words between your comments on this thread and those of the maintainers, but I'm sure we have different perceptions on that front.

I followed up because I got the impression that you'd taken some level of umbrage at P-Y's comment, likely based on an incorrect interpretation of that comment, and that you in turn closed the PR prematurely.

I still feel that way, but we're all busy and I think it'd be futile to keep going back and forth here.