Skip to content

Transferability of registration - codify historical approach to Corporate registration #124

@yarko

Description

@yarko

We have always allowed corporate registrations to change who is sent on a registration #. For a company, staff are reassigned, people leave, etc.

When a company is not to the level of supporting PyCon as a sponsor, but pays corporate rates, we have always treated those registrations as technically being a registration by the company, and technically the attendee being a proxy for the company. We have done so by staff agreement, "common sense" rule.

As we are capping PyCon size, the issue of abuse / scalping increases.
At the same time, we need to be rational, consistent, and encouraging to our business supporters and potential future sponsors.

I propose we do not advertise / encourage this policy, but internally have a consistent behavior, to wit:

  • People can be exchanged for a corporate registration;
  • it does not matter if a company paid, or if it's a reimbursement situation - only that it's corporate rate and references the company;
  • it does not matter if a corporate email is used for registration (we acknowledge that some will prefer not to have their business email open to vendors / recruiters).
  • all that matters is that the change is verified through a consistent corporate email address (requester, and new registrant name);

So the process would look something like this:

  • get registration number of person requesting transfer;
  • confirm it's corporate rate;
  • confirm their registration declares the company;
  • confirm the request is made from the company URI email address;
  • confirm the new target is also from the same company URI email address;

This longstanding "good neighbor" policy on our part towards companies maintains longer roots with companies, and should be consistent. To ensure this, I'm suggesting an internal policy as a mechanism of stewardship.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions