-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Logos to Sandbox Projects #369
Comments
Is this about using the "generic" logos (https://github.com/ossf/tac/tree/main/files/images) or about asking for creative assistance in creating their own logo? We already state sandboxes are allowed to use a logo - https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md#getsbenefits |
To leverage creative services to create a goose-native logo. We have an issue where if we don't provide a logo to sandbox projects they are free to create their own. It would be more effective from a brand consistency, workflow, and work effort standpoint. |
In our Gives & Gets (https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md#incubating-level-gives--gets) we list this as a benefit for Incubating TIs as an encouragement to progress in the lifecycle. We certainly have the ability to change that if the TAC agrees to the change. |
The problem with watering down the requirements for this kind of benefits is that it effectively removes some of the incentives to work on moving to the next lifecycle stage. In my experience it is always difficult to strike the right balance. I've seen in other projects logos being changed so I don't know that if they go on and create their own it's necessarily a big deal. They can always get a new one once they get to Incubation. |
The services are free. I think we can do this on a request basis for sandbox and allow that as an option versus (a) them creating their own which is a headache to unwind from a brand recognition standpoint and (b) this policy of no stickers at sandbox hasn't been historically enforced so we now have a mishmash of projects with and without logos. I would suggest moving forward with this as a vote of the TAC to amend the gives and gets and allow this benefit on a request basis. |
I support adding logos to sandbox projects, as long as there's some other advantage/incentive to moving beyond sandbox that projects typically care about. I think the other advantages are enough to meet that condition. One advantage of giving logos to sandbox projects is that it makes the sandbox project more memorable & might help them get more participants. More participants could help them move up from sandbox faster. |
Recommend use the sandbox BADGE, and when move to incubating stage, get a custom goose LOGO along with the Incubating badge. Call for data/ comments from other sandbox lifecycle leaders: would a custom goose LOGO in addition to the cute eggs-in-a-nest sandbox BADGE help drive contributions and gathering contributors to move to incubating? Specifically to bomctl or protobom (who have sandbox logos in the meantime while we sort this out). Did it help your teams? |
The consensus we reached at the TAC meeting today was that sandbox technical initiatives will get the sandbox badge, and once they are incubating they will be eligible for a custom goose logo. |
Please vote to allow sandbox projects to obtain a logo. A logo galvanizes individuals and can be a good community building / support.
The text was updated successfully, but these errors were encountered: