Code of Conduct

Prebid.org Header Bidding Code of Conduct

Nov 17, 2020

In order to encourage the development of quality products while maintaining a healthy open source community, Prebid.org members and contributors are expected to abide by technical guidelines based on the core values of the organization.

Prebid.org Core Values

The main objective of Prebid.org is to make great header bidding technology available for web publishers and mobile app developers. We believe great technology is:

• Efficient – Products offered by Prebid.org should not burden a user device, the network, or a company server.
• Secure – Prebid.org software should not open doors to security risks, including electronic attack, denial of service, fraud, or data leakage.
• Transparent – Our products are built in the open with community review. Changes to Prebid software and modules must be open to inspection before and after release.
• Fair – The Prebid.org platform doesn’t favor any one entity over another. No entity can be favored over another in technical ordering or status as a default value. No entity can gain information about another entity without approval.
• Collaborative – Human interactions in Prebid.org public forums and events must be courteous.
• Privacy Sensitive – Our products are built for publishers to support users’ privacy concerns and comply with industry standards.

Auction Principles

The guidelines in this section apply to open source software written for the Prebid.org platform, or plugins designed to integrate into the Prebid.org platform.

Definitions:

• Publisher: the party who is integrating the header bidding technology into their page, app, video service, etc. They may integrate Prebid software on their own or through an approved agent.
• Publisher Agent: a party who helps a Publisher integrate or install Prebid software.
• Auction Layer: the part of the system that facilitates bids from demand partners being passed into the decisioning layer.
• Demand Partner: any party that is willing to provide a price to be paid to the Publisher for a given impression, and is integrated into header bidding.
• Decisioning Layer: the part of the system that decides the final winning bid.

Auction Logic

1. The Auction Layer must not modify bids from Demand Partners unless specifically instructed to do so by configuration. For example, a Publisher might instruct the Auction Layer to:
   1. Apply a modification that changes the bid from gross to net or;
   2. Apply a modification that changes the bid from one currency to another;
   3. Account for a consistent discrepancy;
   4. Account for managed service fees;
   5. Drop bids that do not meet the floor requirement
2. The Auction Layer must provide equal opportunity for all Demand Partners to bid, either by randomizing the order in which they are called, or by requesting bids in the order specified by the publisher.
   1. Publisher configuration may override which bidders take part in each auction.
   2. This also specifically covers any situation where a Publisher Agent is also a Demand Partner or a Demand Partner is hosting the Auction Layer.
3. The Auction Layer must send all demand returned within the configured timeout period to the Decisioning Layer.
4. The Decisioning Layer must make the final choice of which bid wins unless configured to do otherwise.
5. The Decisioning Layer can be determined by the Publisher, e.g. It could be an ad server or the same software that implements the Auction Layer, or a proxy server. If decisioning is done in Prebid software, it must conform to all other rules in this section.
6. The Auction Layer should provide a mechanism or process for Publishers and Demand Partners to validate auction mechanics, including:
   1. Confirmation that bid requests were sent to Demand Partners
   2. Confirmation that bid responses were sent to the Decisioning Layer
   3. Confirmation that the correct bid values were sent to the Decisioning Layer
   4. Bid timing information such as which Demand Partners met the timeout period

Data and Transparency

1. The Auction Layer must segregate demand data so there is no opportunity for Demand Partners to have access to other bids or bidder data.
2. The Auction Layer must pass available bid request information to each configured demand partner, subject to Publisher configuration and privacy regulation controls.
3. The Auction Layer must not collect and store Publisher or Demand Partner information (such as bid stream information, user information, and Publisher first party data) except in the following cases:
   1. Passing information to Demand Partners or Analytics Adapters
   2. Validating header bidding mechanics
   3. Troubleshooting and diagnosing implementations
4. The Auction Layer must not record, use, or sell Publisher or Demand Partner data except in accordance with the instructions of the Publisher and the Demand Partner.
5. The Prebid ecosystem will endeavor to support industry standard privacy regulations, including allowing Publishers to transmit notice, consent, and opt-out state.
6. Analytics Adapters must not utilize header bidding auction data outside of any agreement they reached with the Publisher.

User Experience

1. The system should minimize the impact on the user’s web browsing experience.
2. Users, Publishers and Advertisers deserve a reliable ad serving environment. Prebid software should facilitate data that helps determine if an impression is fraudulent or undisplayable for any reason.
3. Publishers should be able to utilize Prebid software while adhering to their privacy policies.

Adapter Conduct

Prebid software supports different types of ‘plugin’ modules, including for example bid adapters, analytics adapters, user ID modules, real-time-data modules, and others.

1. Adapters of all types must follow all of the above guidelines and specific technical rules defined by the relevant Prebid committee.
2. Prebid.js and Prebid Server technical rules are defined by Prebid Module Rules.
3. As technical rules may change over time, Prebid committees are empowered to force adapters to change specific behaviors as part of major milestone releases. The committees should strive to give the adapter community ample opportunity to weigh in on specific guidelines and ample time to make changes.

Information and Resources

• Prebid Module Rules

Prebid.org Community Code Of Conduct

In order to encourage the development of quality products while maintaining a healthy open source community, Prebid.org members and contributors are expected to abide by technical and social conduct guidelines based on the core values of the organization.

• Prebid.org Core Values
• Community Conduct
• Prebid Conduct Reporting Guide
  • What happens after you file a report?
  • Reconsideration
• Further Reading

Prebid.org Core Values

The main objective of Prebid.org is to make great header bidding technology available for web publishers and mobile app developers. We believe great technology is:

• Efficient – Products offered by Prebid.org should not burden a user device, the network, or a company server.
• Secure – Prebid.org software should not open doors to security risks, including electronic attack, denial of service, fraud, or data leakage.
• Transparent – Our products are built in the open with community review. Changes to Prebid software and modules must be open to inspection before and after release.
• Fair – The Prebid.org platform doesn’t favor any one entity over another. No entity can be favored over another in technical ordering or status as a default value. No entity can gain information about another entity without approval.
• Collaborative – Human interactions in Prebid.org public forums and events must be courteous.
• Privacy Sensitive – Our products are built for publishers to support users’ privacy concerns and comply with industry standards.

Community Conduct

Like the technical community as a whole, the Prebid team and community is made up of a mixture of professionals and volunteers from all over the world, working on every aspect of the mission – including mentorship, teaching, and connecting people.

Diversity is one of our strengths, but it can also lead to communication issues and unhappiness. To that end, we have a few ground rules that we ask people to adhere to. This code applies equally to founders, mentors, contributors, and anyone seeking help and guidance. This isn’t an exhaustive list of guidelines. Rather, take it in the spirit in which it’s intended – a guide to make it easier to enrich all of us and the technical communities in which we participate.

This code of conduct applies to all spaces managed by Prebid.org. This includes GitHub, Slack, mailing lists, events, and any other avenues of communication created by the project team for the community. Violations of this code outside these spaces may affect a person’s ability to participate within them.

If you believe someone is violating the code of conduct, we ask that you report it by emailing conduct@prebid.org. For more details please see the Reporting Guidelines below.

• Be friendly and patient.
• Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to, members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
• Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you make will affect users and colleagues, and you should take those consequences into account when making those decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
• Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Prebid.org community should be respectful when dealing with other members as well as with people outside the Prebid.org community.
• Be thoughtful in the words you choose. We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior are not acceptable. This includes, but is not limited to:
  • Violent threats or language directed against another person.
  • Discriminatory jokes and language.
  • Posting sexually explicit or violent material.
  • Posting (or threatening to post) other people’s personally identifying information (“doxing”).
  • Personal insults, especially those using racist or sexist terms.
  • Unwelcome sexual attention.
  • Advocating for, or encouraging, any of the above behavior.
  • Repeated harassment of others. In general, if someone asks you to stop, then stop.
• Be understanding. When we disagree, try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re all different. The strength of an open source project comes from its varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.

(Text in the section above based on the Django Code of Conduct)

Prebid Conduct Reporting Guide

If you believe someone is violating the code of conduct we ask that you report it to Prebid.org by emailing conduct@prebid.org. All reports will be kept confidential. In some cases we may determine that a public statement will need to be made. If that’s the case, the identities of all victims and reporters will remain confidential unless those individuals instruct us otherwise. If you believe anyone is in physical danger, please notify appropriate law enforcement first. If you are unsure what law enforcement agency is appropriate, please include this in your report and we will attempt to notify them.

We encourage you to report an incident even if you are unsure whether it is a violation, or whether the space where it happened is covered by this Code of Conduct. We would much rather have a few extra reports where we decide to take no action than miss a report of an actual violation. We do not look negatively on you if we find the incident is not a violation. And knowing about incidents that are not violations, or happen outside our spaces, can also help us to improve the Code of Conduct and the processes surrounding it.

In your report please include:

• Your contact info (so we can get in touch with you if we need to follow up).
• Names (real, nicknames, or pseudonyms) of any individuals involved. If there were other witnesses besides you, please try to include them as well.
• When and where the incident occurred. Please be as specific as possible.
• Your account of what occurred. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger) please include a link.
• Any extra context you believe existed for the incident.
• Whether you believe this incident is ongoing.
• Any other information you believe we should have.

What happens after you file a report?

You will receive an email from Prebid.org acknowledging receipt. We promise to acknowledge receipt within one business day.

The working group will meet to review the incident and determine:

• What happened.
• Whether this event constitutes a Code of Conduct violation.
• Who the bad actor was.
• Whether this is an ongoing situation, or if there is a threat to anyone’s physical safety.

If the incident is determined to be ongoing or a threat to physical safety, the working groups’ immediate priority will be to protect everyone involved. This means we may delay an “official” response until we believe that the situation has ended and that everyone is physically safe. Once the working group has a complete account of the events we will make a decision as to how to respond. Responses may include:

• Nothing (if we determine no violation occurred).
• A technical fix, if appropriate.
• A private reprimand from the working group to the individual(s) involved.
• A public reprimand.
• An imposed vacation (i.e. asking someone to “take a week off” from a mailing list or Slack).
• A permanent or temporary ban from some or all Prebid spaces (mailing lists, Slack, etc.)
• A request for a public or private apology.

We’ll respond within one week to the person who filed the report with either a resolution or an explanation of why the situation is not yet resolved.

Once we’ve determined our final action, we’ll contact the original reporter with an update.

Finally, the working group will make a report on the situation to the Prebid.org Board. The Board may choose to release a public report of the incident.

Reconsideration

Any of the parties directly involved or affected can request reconsideration of the committee’s decision. To make such a request, contact the Prebid.org Board at board@prebid.org with your request and motivation and the board will review the case.

(Text in the section above based on the Django Code of Conduct Reporting Guide)

Further Reading

• Header Bidding Wrapper Code of Conduct