Add ability to override sponsor section titles

[mattstratton]

Connected to #14440

Today, when you set a sponsor level, that word is put in front of "sponsor(s)" and all the other places that sponsorship is referred to (i.e., if the level if "Silver", it will be referred to as "Silver Sponsors"). A case has come up for sponsorship levels which the organizers would prefer to not include the word "sponsor".

I would suggest that this could be implemented with an optional override on the title for a sponsor level (similar to URL overrides on the navigation):

nav_elements: # List of pages you want to show up in the navigation of your page.
  - name: propose
    url: https://talks.devopsdays.org/devopsdays-chicago-2025/cfp

so something like this:

sponsor_levels:
  - id: platinum
    label: Platinum
    max: 2
  - id: gold
    label: Gold
  - id: academic
    display: Academic Supporters

It would be confusing slightly, because it's like "Label" is what is used if you want "...Sponsor(s)" appended, and "display" is the override. Maybe it would be called display_override to be clear?

[toshywoshy]

I prefer to have display_name and have it fall back to the default code if this key is not available.
Also what would happen if someone adds label and display_name which should take precedence?
I would say label as that is the original way

[toshywoshy]

I created a PR #14458 with display_name
The changes to the code are quite simple

[phrawzty]

Possibly unpopular opinion, but I would argue against this.

If you have entities that are sponsoring the event, those are sponsors. That can mean money, but it can also mean donating a venue, providing advertising, or (as is the case with the event in question) time for their employees to be local organisers.

All of the non-human entities are sponsors, in that they are allocating resources to the event, be it cash or person-hours.

Sponsors is the correct nomenclature.

[mattstratton]

Generally speaking, I agree with @phrawzty but wanted to open this to discussion before making the change.

I suggest we keep this issue open for a little bit to get others to weigh in before merging any related changes.

[mattstratton]

I created a PR #14458 with display_name The changes to the code are quite simple

Yeah, my hold off wasn’t because of complexity but more of “should this be done” :)

[toshywoshy]

So @phrawzty your opinion may or may not be unpopular, however I feel there is some inconsitencancy in our logic.

Sponsors are indeed entities that contribute to the event, as you state, however I would add that organizing or speaking does not count as sponsoring.
This is where I feel we need more clarity, as in a previous discussion we clearly said that speaking is not sponsoring and sponsoring is not speaking.
I tend to apply this rule to organising, as this would otherwise mean that the employer of someone would become a sponsor.
While I think we're on the same page here, your definitions leave ambigious options.
So I wouldn't say non-human entities are sponsors, as this leaves a big back door open to our previous discussion on speaking vs sponsoring.

You are right in that the correct nomenclature is sponsors, however this may not translate always the same way into other languages and dialects.

Another factor to consider is sponsor levels that are not in the sponsor document and that are more arbitrary and based upon the organisers adding these entities for special reasons.
For example Community Sponsor, aren't really sponsors, so I would prefer to have this category named as Community Supporter, also what is a Partner Sponsor?

Maybe we should add a supporter section?
However the display_name options seems better for the number of times it will be used.
Or we could hardcode the exceptions, if community then use Community Supporter and for other such special cases.

[aameen79]

In our case @phrawzty these entities are not sponsors, they are participating in organizing and preparing the event, plus the support

[toshywoshy]

Would it be better to have them listed under organisers?
As for supporting, why not add the organisation as a support sponsor or community sponsor?
Is it just the word "sponsor" that is the hindrance?

[phrawzty]

Would it be better to have them listed under organisers?

Humans are organisers. Incorporations are sponsors.

As for supporting, why not add the organisation as a support sponsor or community sponsor? Is it just the word "sponsor" that is the hindrance?

In this one specific case, apparently that's the issue, yes.

[toshywoshy]

Would it be better to have them listed under organisers?

Humans are organisers. Incorporations are sponsors.

I was somewhat less specific, the humans of those organisations/incorporations should be indeed listed, not the entire organisation.
I suppose there will be several humans supporting the event from those incorporation, they could be listed as organisers.

As for supporting, why not add the organisation as a support sponsor or community sponsor? Is it just the word "sponsor" that is the hindrance?

In this one specific case, apparently that's the issue, yes.

I am now not sure if the option display_name is better, hardcoding several expections or creating a new supporter section

[aameen79]

Would it be better to have them listed under organisers?

Humans are organisers. Incorporations are sponsors.

I was somewhat less specific, the humans of those organisations/incorporations should be indeed listed, not the entire organisation. I suppose there will be several humans supporting the event from those incorporation, they could be listed as organisers.

As for supporting, why not add the organisation as a support sponsor or community sponsor? Is it just the word "sponsor" that is the hindrance?

In this one specific case, apparently that's the issue, yes.

I am now not sure if the option display_name is better, hardcoding several expections or creating a new supporter section

Adding a supporter section with flexibility of naming the category seems a good solution to me

[jerdog]

Reading through, and I agree that we could / should have an option for a new supporter section like we have with Community Sponsor. A lot of conferences have an option that if a speaker's company can cover their travel expenses they will be listed as a "Supporter" or something similar. In this case, if being listed as a Community Sponsor doesn't work, then it would make sense to have an option for a Supporter option.

[don-code]

While the word "sponsor" has never been contentious for our event, I do feel that there are some distinctions to be made:

• Some companies come to advertise tech to tech people. This is the most common type of sponsor.
• Some companies come to recruit tech-minded people to their company. Not to name names, but likely nobody's going to pick up a certain cellphone vendor, or a certain credit card, if that company came to a DevOpsDays event.
• Some companies come so that their members can have a presence. Again not to name names, but we've partnered with (and historically called "sponsors", even if they aren't paying us for that privilege) non-profits who engage the community, and signal boosted them.
• Some companies give us discounted products (coffee) in exchange for co-branding.

I'll stop short of drawing a line on where "sponsorship" ends, and something else entirely starts. I suspect our coffee vendor is "not a sponsor" in the traditional sense, but they're also "not a sponsor" in a different way that a code bootcamp that's sending students is also "not a sponsor".

That said, it feels like this is ambiguous enough that we could allow individual events - maybe even only for one or two years, to see if we naturally come up with some common terms - to set their own nomenclature. Maybe one event chooses to name a "vendor", whereas another event chooses to name a "partner", and another still chooses to name a "supporter". I don't personally see a whole lot of value in keeping those classifications consistent across events.

[toshywoshy]

Well so sponsors are defined in the sponsor section of the event data, these are presented as Sponsors and are listed on all pages, the word Sponsor is a hardcoded post value.

If we go with a new supporters section, this would be defined in a new optional section called supporters and would be presented as Supporters, so the work Suppporter_ would be the hardcoded post value, and this section would only be displayed on the main event page.

While my PR #14323 adds the ability to override a specific sponsor label and use display_name, allowing individual events from having different names, sponsor, vendor, supporter, or anything else.

However initial feedback was hesitent and upon reflection and understanding, I think we need to keep in account 2 additional factors I did not keep enough account with intialliy
(a) Content reviewers
We should adhere to the KISS principle, a content reviewer, checks the file changed and sees an update to the sponsor section. that person will presume a sponsor change, in the same logic a person seeing a change to the supporter section will understand the change of a supporter section
(b) History is written
We are runnning for several years (15+) and sponsors have certain expectations, in these difficult times and with the need to provide value, changing names may result in more confusion and sponsors may even not understand why another entity would be listed as a sponsor while not paying to be a sponsor.

I suggest to close PR #14323 and I will work on creating the new __supporter__ section so this can be added as a new feature.

[mattstratton]

@toshywoshy I think you meant #14458, the PR you referenced is a different one

But i agree otherwise :)

[jerdog]

Also agree with @toshywoshy (and @mattstratton I guess, if I have to 😅)