Logo Strategy

[calebcartwright]

I feel it's been a while since we've talked about Shields logos (the handful of ones we maintain and provide directly from https://github.com/badges/shields/tree/master/logo) and that it'd be helpful if we can articulate our current posture and ensure our logo documentation accurately reflects that posture.

We've had various discussions and considerations over the last few years (e.g. #7684), including whether we should drop them outright. We did semi-recently decide to keep the ones that we already have, or at least we didn't decide to delete them, but I'm unclear whether we took a position on whether we could/would potentially ever add any more (and obviously opinions can and do change over time).

As such I'd like to use this to discuss if we collectively feel there are circumstances in which we'd accept a new logo (and if so capture that in our docs), or even if we'd like to drop the logos altogether.

Framing as options:

1. Drop the existing set of logos we maintain, and do not take on any new ones, only provide logos via SI and the custom logo param (as detailed below in Logo Strategy #9476 (comment))
2. Keep the existing set but refuse to take on any new ones under any circumstances
3. Keep the existing set and potentially take on new ones after determining/updating guidelines under which we would

I confess I'm ambivalent on the topic myself. I definitely think that SimpleIcons should remain the first port of call, as I'm cognizant of the drawbacks we've experienced in the maintenance of the current set. I feel like if we are to consider accepting new logos that we'd need a set of rather high thresholds a proposed logo would have to clear, and I think that we would also still need to have the discretion to choose on a case by case basis (i.e. our docs would enumerate the key requirements, but we'd still retain the right to reject a proposed logo based on other considerations regardless of whether it cleared all the documented requirements).

That being said, assuming we were to keep logos, I'd find a hypothetical scenario with the following characteristics to be rather compelling:

• 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)

Admittedly a fairly tall order, so I wonder if a hypothetical scenario that only had some of those characteristics (and/or other ones) would be sufficiently compelling.

Curious your thoughts @chris48s @PyvesB

[sgammon]

As a contributing user who got tripped up by this policy, I would only ask that maintainers make some kind of effort to follow their own documentation, whatever that may be, and that if there is not an intent to ask a contributor to close a PR, that language should not be used to that effect.

I've contributed to a number of similar projects -- for example the icon set for Buildkite -- and I don't know why this one is different. While the custom logo feature works, embedding an SVG can be quite large and is suboptimal for diffs. Obviously embedded SVGs do not update when brands update, which is an unfortunate side effect that renders one of Shields' coolest features inert.

The ship has sailed on the PR I tried to file, as it was shot down immediately (or, least I thought it was), and then a strange and meandering discussion ensued. A clear policy would help to avoid this situation. Thanks for your guys' hard work on this project and while I realize it is not your day jobs, many many open source projects rely on it, so I would hope you would be open to contributions and a fair and clear process given your important position in the community.

As a fan and potential contributor to Shields, thanks for filing @calebcartwright.

[chris48s]

I've not had a chance to read over the whole saga of #9474, #9475, #9477, and #9478

but I've seen it is there and I'll try to plough through it.

Tbh, I try to stay out of logo discussions, so I don't think I've ever actually written this down on GitHub but..
I'd ideally really like to completely delete the remaining custom icons and say the available options are SimpleIcons or base64. It would solve a lot of problems IMO.

That wasn't the direction we went in after #7684 but it does leave us in this limbo state where we have this slightly odd collection of custom icons for historical reasons (all of them were added before simple-icons), and it is difficult to justify why those but not others (gotta have that Travis CI icon because.. everyone uses that these days).

Whatever we do, someone is going to be unhappy, but I feel like if we just deleted the handful of remaining custom icons, we deal with one backlash, rip that band aid off, and that buys us:

• a more consistent and explainable logo policy
• less suprising behaviour that is easier to document/explain (currently logo is a simple-icons slug ..except when it isn't)
• an unambiguous solution to Expose the concept of logos, add SimpleIcons as an optional dependency #4947
• a category of issue/content we have definitively decided not to deal with

That may or may not be a helpful opinion.

[calebcartwright]

I'd ideally really like to completely delete the remaining custom icons and say the available options are SimpleIcons or base64

That may or may not be a helpful opinion.

Helpful indeed Chris and I've updated the issue description to be more explicit about the options because dropping them altogether certainly is one.

As I commented back in #7684 I do think our logos look "better" (as vague/subjective that may be), and I can understand why someone would want our logo vs. the other. However, I'd realized I was actually mildly disappointed we didn't decide to get rid of them back then.

I know there's an audience that strongly prefers them, but I feel like it's a relatively small subset of our user base that actually uses them, and that the logos eat up an inordinate amount of maintainer effort/energy/bandwidth cost in comparison.

Probably best for now to punt discussion of specifics around how we'd potentially go about doing so, but something that could make it more palatable for me would be if we provide a list of the corresponding precanned ?logo=... params to make it easier for people to copy/paste (acknowledging the Travis logo would be the one exception)

I believe I've a soft preference for option 1, followed fairly closely by option 3. I'm not feeling too fond about option 2, as while I suppose it's better than the current nebulous state of affairs, it would probably perpetuate the most of the current problems we have compared to the other options.

[sgammon]

I think this is a place where you guys just need to make a decision.

Delegating to SimpleIcons is reasonable. I don't think anyone would fault Shields for doing that.

I agree that consistency would be a better user experience than the marginal benefit of the built in logos. I don't think there should be "special" logos.

If there is this much ambiguity with a contribution policy, it isn't really a policy and will only serve to upset people who follow it in good faith.

[calebcartwright]

If there is this much ambiguity with a contribution policy, it isn't really a policy and will only serve to upset people who follow it in good faith.

I understand the benefits of an explicit policy with fully deterministic criteria, and why someone might prefer such a policy. However, it's important to note that what we currently have is a set of guidelines, and not a rigid policy.

This is intentional; it is a feature, not a bug. There are scenarios in which it is not possible to enumerate a fully exhaustive list of considerations and/or is beneficial and desirable to retain the ability to apply discretion, to make a judgement call on a case by case basis. Our current posture on logos is such a scenario.

Furthermore, I'd also note that in my opinion this is already well reflected in the existing logo documentation text in https://github.com/badges/shields/blob/master/doc/logos.md#contributing-logos, with several examples including (emphasis mine)

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.

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

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.

I don't think anyone should read that and come away thinking that any proposed logo will absolutely, unequivocally be accepted. That being said, if we decide against option 1 then I wouldn't be opposed to adding something more explicit in these docs (e.g. something to the effect of "We do not guarantee we will accept a new logo, and we encourage potential logo contributors to contact us first to determine viability"), especially if this is likely to be a recurring source of confusion/misinterpretation.

However, I'd be vehemently opposed to attempting to establish a policy with a binding, exhaustive set of conditions from the current maintainer team discretion with a general set of guidelines/considerations. I do not believe it would be possible for us to establish a fully future-proof, exhaustive list under which we must accept a logo.

[uncenter]

Personally I'd have to go with option 1 here. It completely removes the burden on maintainers and for most cases base64/custom SVGs can do the trick.

[PyvesB]

My opinion has broadly not changed since last year:

I'd personally be leaning towards simplification and removing all our custom icons. If some users felt strongly about one icon or another, they can always provide their own encoded one via the logo parameter.

[calebcartwright]

Excellent, sounds like a decision made then. I'll open up one or more issues to cover next steps, with links back to this one and other relevant discussions.

[sgammon]

@calebcartwright

I don't think anyone should read that and come away thinking that any proposed logo will absolutely, unequivocally be accepted

The point was that there was no better case than Bazel for meeting this criteria, not that I believed it would be unequivocally accepted (I did not and do not). I'm happy to at least see an outcome which can be followed consistently by people who contribute in good faith.