Update Travis logo, Reduce some duplication #3047
Conversation
|
|
Cheers for picking this up. Having read the discussion in #1276 and chewed this over, I do have one more thought on this.. Originally I was under the impression that someone at Travis CI objects to us using their logo at all, or to their brand being associated with this project, which is why I said we should block users from using the simple-icons version. Having had clarification from them that they are ok with us using their logo in principle, but they object to it being modified, that slightly changes things IMO. If they don't want us modifying their logo, lets remove the modified logo (and optionally replace it with one that is suitably un-modified version). Does that seem reasonable/make sense? |
That seems like a logically sound and reasonable position from my perspective. Although I've no idea whether the Travis folks would still hold us culpable even if the issue was upstream with Simple Icons I'm also still 👍 on the core functionality in this PR to give us the ability to blacklist (even if we no longer necessarily need to also block Travis now) as I wouldn't be surprised if we need to use it in the future |
This reverts commit 63c994f.
RedSparr0w
changed the title
|
Hey all, sorry to be coming from a bit of a different place here. I'm optimistic that using the logo in its original color is in line with their guidelines, and hope that Travis says they are cool with that. However true it is that simple-icons is at fault for distributing the offending Travis logo, that doesn't release us from culpability. Since Travis is being really direct in saying that a monochromed logo violates their brand guidelines, we shouldn't load it from simple-icons, or from any other source. We're bound by those guidelines, in principle and in law, and laundering the logo through a third party doesn't change that. We don't need to be total servants to these companies, and we should feel open to persuade them to do what we think is the right thing. But at the end of the day, it's their mark, and they get to decide, in principle and in law. (This is certainly true in the United States.) The service integrations are key partners for Shields. We depend on good relationships with all of them to keep our service running and running well. We need to work with these companies, not against them, and that's especially true when it comes to the sensitive area of their brands. (Not to mention – the badge design was originally developed with folks at Travis!) Even if they were to come back with something like, "Please don't do this. While it technically satisfies our brand guidelines we think it looks bad and don't want you to use it," I think we should honor the request. Here's what I propose:
|
RedSparr0w
changed the title
RedSparr0w
force-pushed
the
remove-travis
branch
from
d2d7dbe
to
7366310
Compare
|
As a first thing, the main problem that someone at travis has actaully complained about is that this image: https://github.com/badges/shields/blob/master/logo/travis.svg does not comply with their brand guidelines and they want us to remove it. Lets just get that done. Doing that should not be blocked on the rest of this discussion and the other stuff in this PR can be changed in future if necessary.
Hmm. I don't think we're actually that far apart on this, and I think you're opposing a much more extreme opinion than the one I actually hold :) I was hoping to keep things brief, and possibly didn't word things as well as would be ideal. Perhaps a longer explanation will help. As well as the logo which exists in our repo:
there is also this different logo which exists in the SI repo:
I'd agree with your assement that someone who works for Travis CI would probably also have the same complaint about both. AFAIK nobody from Travis has attempted to raise it with them, but I might be wrong. Having made a few contributions to SI, my perception is that the maintainers of that project do care about the logos they hold being appropriately licenced and complying with brand guidlines (definitely more-so than we have with the logos we've accepted in the past - this is one of the advantages of not hosting our own icons). They talk about brand guidelines multiple times in their contributing guidance: https://github.com/simple-icons/simple-icons/blob/develop/CONTRIBUTING.md and reference compliance with brand guidance when reviewing PRs. I do not want to speak for the maintainers of another project, but my guess would be if someone who works for Travis has an issue with the version of the logo that appears in the SI project and chooses to follow up on it, that would probably be resolved fairly quickly by modification or removal. More generally, in a case where someone does have an issue with a logo in SI, that should be their first move and will be more efficient way to resolve their problem than individually asking projects that use SI to block that one icon. Hypthetically, if the SI maintainers were to say "we don't care and we're not going to do anything about it" (as I say in the above paragraph, my perception is that the opposite would be true, but I don't speak as a representative of their project), then we should definitely block in that situation. In general, it seems like an overreaction to do that as an opening gambit though - its something we should do if/when an issue can't be resolved upstream. In this case, I reckon lets just merge this and keep an eye on the upstream - we can always undo it.
Yep - agreed. To quote from an earlier post in this thread:
@BanzaiMan - just to be really clear: This PR will delete this image: Like many other projects, we also make use of the simple-icons package, which contains this image: |
RedSparr0w
changed the title
Think you're right; sorry for the misunderstanding!
As far as I know that's true.
That is great news, and indeed a huge plus for working with them. I'm eager to lean on other people to do this work for us wherever possible.
Hope so! Maybe we could ask them if they have a procedure for this.
Agreed that's the the path we should recommend – and document! – and the best one in the future. In the case of this conversation, it's with someone who is (1) an existing and historical partner and (2) someone we're already in the middle of a (sort of awkward) conversation with. I don't want to give them a runaround. Going forward, the reason to go to SI first should be that it's more efficient for them, and solves a problem they need to solve anyway (i.e. if they're unhappy with the logo in Shields, it stands to reason that they're unhappy with what's in SI). In particular I don't want to give the illusion that we're trying to hide behind SI.
I agree with that. Maybe writing down a procedure here would make our position and form of action clearer (and less ad hoc).
I did read that though I think got an entirely wrong impression :) |
|
Updated logo as per #1276 (comment): I've also removed the logo blacklist for now, hopefully we won't need it in the future either 👍 |
|
I don't think there's a need to block this on further discussion. However, @chris48s and I agree that someone who works for Travis CI would probably also have the same complaint about the SI logo. It doesn't make sense for us to provide more than one travis logo, so a simple thing we could do is alias |
Refer conversation in #1276
This PR updates the Travis CI logo,
And also adds a blacklist in cases that simple-icons still provides a logo.