Skip to content
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

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

Open
yarko opened this issue Mar 15, 2014 · 5 comments

Comments

@yarko
Copy link
Member

yarko commented Mar 15, 2014

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.

@lvh
Copy link

lvh commented Mar 15, 2014

Keep in mind that this bug tracker is public, so that may well count as advertising :)

@yarko
Copy link
Member Author

yarko commented Mar 15, 2014

Good point @lvh - but this is worthy of that. I would not propose publicizing, as in stating it overtly on the website, conferences (we've never done this). We've done this by simple, personal decisions, as something "making sense". I'm just saying this makes enough sense, and things w/ PyCon sellouts & popularity are so different that it makes sense to talk about how to be consistent around this (or to discuss ceasing this "makes sense to me" behavior).

@lvh
Copy link

lvh commented Mar 16, 2014

+1 for consistent views on how to handle it. Some people just keep asking in different places if they don't like the answer they got.

I don't even mind if this information becomes public, but I do think that if we're putting it on a public bug tracker, the cat's pretty much out of the bag and we should probably treat it as public knowledge :) I'm just checking if we're treating the website versus this issue tracker significantly differently. If we are, I'm not sure that's warranted.

@lukesneeringer
Copy link

+1 on this. There needs to be a consistent approach and message, which we don't have right now, and @yarko's enumeration matches my intuition.

@yarko
Copy link
Member Author

yarko commented Mar 17, 2014

Just to re-iterate what Brian, others have said on staff list.

  • this is a public repository / list;
  • capturing items here is "ok" (some are capturing privately; I thought having list visible would stimulate other items, so nothing falls through the cracks);
  • discussions / post-mortems / decisions will best be made not here, but at a conference post-mortem by organizing staff;
  • having said that, input / comment from interested parties who are not staff, welcomed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants