Bugzilla – Full Text Bug Listing
| Summary: | Add speaker agreement handling and coupon code sending functionality to ESE submission system | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Anne Jacko <anne.jacko> | ||||||||||||
| Component: | Dash Submission System | Assignee: | Denis Roy <denis.roy> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | P2 | CC: | eclipse-bugzilla | ||||||||||||
| Version: | unspecified | Flags: | denis.roy:
iplog+
|
||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||||
| URL: | https://www.eclipsecon.org/submissions/ese2010/ | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Anne Jacko
Were we doing coupon codes in ESE2009, or did the concept of coupon codes begin with ECon 2010? We've been using coupon codes for years, but the details change a bit with each conference. Here's what we told speakers for ESE 2009: http://www.eclipsecon.org/summiteurope2009/registration/speakerinstructions I checked the ESE 2009 speaker agreement text, and other email text, and have concluded that for ESE 2009 we did the speaker agreement signing and coupon code sending as two separate steps. They got an "accept" email with a link to the speaker agreement. They e-signed the speaker agreement. Then after all speakers on a talk had signed, we emailed the coupon code out to all speakers on a talk. The submission system tracked the signing of speaker agreement so it knew when to send out the coupon code email. The coupon code was auto-filled in the email, I presume from the table that holds the codes. My (limited) understanding is that MeetGreen creates a bunch of codes that we put in the table, and then the sub system code uses the table to get a code, and marks that code as used, and says who's using it. Karl did the table creation initially, though this may have passed to Gabe later. There's one big difference between coupon code handling for ESE 2010 vs ESE 2009. For ESE 2009, everyone who got a code got the same discount (100% off). For ESE 2010, eight of the talks earn 100% off, and the rest get 50% off. I've chatted with MeetGreen about some ways to handle this, and they will get back to me with some ideas in a day or two. Created attachment 174686 [details]
example of coupons from MeetGreen
Example of spreadsheet used by MeetGreen to send coupons codes for use by our submission system.
Denis, I talked with MeetGreen. Before we explore any non-automatic ways to send out any coupon codes, could you let us know if you think you'd be able to automate the sending of two different types of coupon codes? Just to reiterate, the 100%-off codes would go out to the authors of the eight Tuesday sessions, with types "tutorial" and "symposium." All other speakers would get a 50%-off coupon. FYI, submitters of posters and BoFs are not in this equation, since no coupon codes are sent out to people who submit talks of these types. I just attached a sample of a spreadsheet that shows the way that MeetGreen has been sending their coupons to us. > Denis, I talked with MeetGreen. Before we explore any non-automatic ways to
> send out any coupon codes, could you let us know if you think you'd be able to
> automate the sending of two different types of coupon codes?
I guess I could, but I'm struggling to understand how/where these coupon codes relate to the submission system. I've found three tables in the Portal database called:
eclipsecon_committer_coupon_assignments
+----------+----------+
| coupon | PersonID |
+----------+----------+
| SWATHEP3 | droy |
+----------+----------+
eclipsecon_committer_coupons
+----------+-------+
| coupon | count |
+----------+-------+
| 2UR3QEVA | 12 |
| 5UBUSA3R | 12 |
etc.
eclipsecon_member_coupons
+----------+----------------+
| coupon | OrganizationID |
+----------+----------------+
| 28PHUFRA | 857 |
The eclipsecon.org server's database has a coupons database:
| Tables_in_coupons
EmailPatterns
EmailPatterns2
EmailPatterns_backup
coupons2008
coupons_by_email_pattern
presenter_coupon_assignments
presenter_coupons
redemptions
redemptions_backup2
sponsor_coupon_assignments
sponsor_coupon_assignments_backup
Then the submission system's database has a custom_coupons table, but it seems to be Econ 2010 coupons:
select * from custom_coupons where restrictedto_email ="me";
+----------+-----------+---------+---------+-----------------------+--------------+------------+---------------+
| couponid | coupon | percent | dollars | restrictedto_email | usedby_email | conference | submission_id |
+----------+-----------+---------+---------+-----------------------+--------------+------------+---------------+
| 4751 | LHT029HRJ | 25 | NULL | me | NULL | 5 | NULL |
+----------+-----------+---------+---------+-----------------------+--------------+------------+---------------+
> Denis, I talked with MeetGreen. Before we explore any non-automatic ways to
> send out any coupon codes, could you let us know if you think you'd be able to
> automate the sending of two different types of coupon codes? Just to reiterate,
> the 100%-off codes would go out to the authors of the eight Tuesday sessions,
> with types "tutorial" and "symposium." All other speakers would get a 50%-off
> coupon.
If I read this right, all I have to do is:
1. I generate random coupon codes
2. Assign said codes to speakers only - 100% to all the eight tuesday "tutorial" and "symposium" talks, and 50% to everyone else
3. Send out an email to those people to tell them what their coupon code is.
4. Give list to MeetGreen?
Does that sound about right?
Or are steps 1 and 4 the inverse?
> 1. I generate random coupon codes > 2. Assign said codes to speakers only - 100% to all the eight tuesday > "tutorial" and "symposium" talks, and 50% to everyone else > 3. Send out an email to those people to tell them what their coupon code is. > 4. Give list to MeetGreen? > > Does that sound about right? > > Or are steps 1 and 4 the inverse? You don't have them exactly reversed, though it is true that MeetGreen generates the coupon codes (since they create codes that make sense to them for later tracking). When MG sends the codes to you, they show the coupon attributes, such as what discount percentage each one is for. So you'd know which ones are the 100% off that go to the presenters for the eight accepted tutorial and symposium sessions, and which are the 50%-off ones that go to all the speakers on the short-talk and long-talk accepted sessions. So the steps would be these: 1. MG generates coupon codes and sends you the list. 2. The sub sys code assigns coupons to each session, matching the correct types (100%-off to tutorials and symposia, and 50%-off to everyone else). 3. For each accepted session, the sub sys code tracks whether all authors of the session have signed a speaker agreement. 4. When all authors have signed the agreement, the code is emailed to all the authors on that talk. Once the program is chosen, we also send reminder emails to the authors who haven't performed some critical task, such as signed a speaker agreement and/or registered for the conference. So the sub sys tracks status that shows who should get these reminders. Referring to your comment 5, that doesn't surprise me that all those tables exist because of the myriad ways that we have tweaked our submission system tasks and speaker registration processes. One thing I know is that we haven't been tracking who's a committer and/or who's a member for purposes of discount registrations in a long time -- we use a secret honor system. We tell them to use a standard coupon like "MEMBER" but we don't actually check to see if they are members. We used to have a Coupon Checker, but we decided it was more complexity than we needed. For ECon, where we allow combining of discounts (two 25%-off talks equals one 50%-off discount), we use a Discount Calculator. But we don't use the Discount Calculator for ESE. Clear as mud, right? I've asked MG to create and send the coupons (July 26). Created attachment 175353 [details]
Patch
Yes, that is clear. I was able to trace where some of this action happens in the code. I did find one omission -- when the sub system assigns a coupon code to a talk, the talk type (tutorial, symposia, long, short) was not considered. Attached is a patch to do this.
FWIW, I'm using this table for the coupons: dbmaster.conferences.custom_coupons. I've added the _type column to the table to track.
In case it's not obvious from the patch, I am mirroring all my changes (database & code) to easy2010 and ese2010 so that I can document/test as I go along. > 1. MG generates coupon codes and sends you the list. DONE > 2. The sub sys code assigns coupons to each session, matching the correct types We must test this with easy2010. I suppose the fictitious PC must accept a talk for a coupon to be assigned to it. I suggest we accept https://www.eclipsecon.org/submissions/easy2010/view_talk.php?id=1686 so I can see. I've committed my patch.
> I suggest we accept
> https://www.eclipsecon.org/submissions/easy2010/view_talk.php?id=1686 so I can
> see.
Anne, in case it's not evident, I don't know how to do that (accept a talk).
Hey Denis -- I will go into easy2010 and try some things out. I'm not sure how to do all of it but I hope to figure it out, make some notes, etc. Thanks for adding the functions! It looks as though the emails for ese2010 are not mirrored for easy2010, but that's fine. In fact, I'll add some text to the easy2010 emails so I can sure that the right one is going out. Well, darn. Things are not working as I expected. I went in to easy2010 and marked two talks as tentative decline, one talk I left alone, and the other talks I marked as tentative accept. My understanding is that the only way to change the status of talks from "tentative X" to "X" is to push the big button. So I expected to be able to go in and push the big button, see the status of the talks change, and see a bunch of emails go out. However, after I marked the talks to "tentative X" and went to the big button page, all I got was a message saying "There are no submissions that need action taken at the moment." So I'm stumped! At what point in time is the Big Button usually pressed? If there is an overlap between the submissions NOT being accepted and registrations being open, how do you apply a coupon code to someone who has already registered and then gets their talk accepted? I believe the Big Button is pressed after the program committee has marked all the talks they want to accept, and the program chair has made sure that the number and type of the talks marked as "tentative accept" is correct -- in other words, that we don't accept more talks that we fit into the schedule. If someone registers before their talk is accepted, MeetGreen does a manual adjustment of their registration record to apply a coupon code. This is why we strongly encourage speakers to hold off on registering until the program is chosen -- we mention this is several places. Usually we just have one or two people that we need to adjust. I think we also use the Big Button to accept late talks (assuming we have holes to fill in the schedule), though I'm not positive about this. I believe that the Big Button changes all the current "tentative accepts" to "accepted" and all the current "tentative declines" to "declined" and only sends email out for the talks that had their states changed. It would be a really good idea to figure out if this is indeed how it works, because we only want to send out the "accepted" or "declined" emails once per session. Denis, any idea when you might be able to work on this? The submissions deadline is next week (August 16), and the committee will be choosing the program immediately after the deadline. The Big Button gets pushed as soon as possible after the program committee has made their choices. The target date for this is August 31. Bernd is getting married the next weekend, so I think he'll be motivated to meet that August 31 deadline. It's making me nervous that we don't have this working yet. Maybe I misunderstood, but I thought you were going to get this part functional, and then we would bring Gabe in for the next part -- the brain dump of the whole shebang, and the scheduling of the program. (To communicate my concern, I've changed the bug Importance to P2/major.) Thanks! > Denis, any idea when you might be able to work on this?
I'll work on this this week. By setting the priority on your bugs you're helping me understand what's important and what can wait.
(In reply to comment #14) > My understanding is that the only way to change the status of talks from > "tentative X" to "X" is to push the big button. Right. However, for Easy, our types were wrong. There is a field called 'Internal Type' and for Long, Short, Symposia and Tutorials, the internal type must be 'submission'. Created attachment 176389 [details]
Picture of the Big Button
Here's a picture of the Bug Button. We can add this to the Sub System docs when it's convenient.
(In reply to comment #19) > Right. However, for Easy, our types were wrong. There is a field called > 'Internal Type' and for Long, Short, Symposia and Tutorials, the internal type > must be 'submission'. What does having the internal type set to "submission" enable? Is it that they can be accepted or declined? That they can be scheduled? Or something else? This is important for me to understand, since some types are a bit special. For example, a poster is accepted or declined, but it isn't scheduled. A sponsored talk isn't accepted or declined by the program committee, but it needs to be scheduled, etc. I'm documenting this on the wiki page under "Conference Chair" stuff. (In reply to comment #21) > What does having the internal type set to "submission" enable? Is it that they > can be accepted or declined? That they can be scheduled? Or something else? It enables the talks to be accepted and declined (The Big Button). Scheduling is done with the other buttons, if I read their text correctly in the Conference Chair page. Ok, so here is the status: - I marked a talk as Tentative Accept (light green) - As Conf Chair, I pushed the Big Button (which now works, and you can use it to accept/decline late submissions) - I got an email saying I need to sign the Speaker Agreement - I Signed the Agreement - I got an email that says: Dear Denis Roy, Thank you for signing your speaker agreement. With your e-signature, all the authors of "This me me, I am I" have signed their speaker agreements and thus you can go ahead and register for the conference. Your talk is eligible for a discount code; the code is '(real code here)'. If there are multiple speakers, you must decide amongst yourselves who is going to use the single free registration and who is going to register normally. For full instructions on how to use your coupon, please visit our conference site. ... and now the coupon code is assigned to that submission. Anne, at this time this seems to be fixed for both EASY and ESE. I would like for you to confirm. You can go into easy, submit new talks (short, long, etc), mark them as Approved Tentative then hit the Big Button. Of course, once you've signed your agreement once, you can't test this anymore unless I "unsign" it for you. Let me know if you want me to do that. Thanks, Denis. I'm going to play around with it a bit more to make sure I understand how this is working. That's awesome that we seem to have the speaker agreement and coupon code stuff functioning! Hooray! Six beers for Denis! I need to figure out how best to work with some of the special cases, such as sponsored talks. I'll ping you if I need any assistance. Thanks again. Denis, here's one thing I'm seeing in easy2010 that I didn't expect. My easy2010 talk 1689, a tutorial, was accepted. But I didn't get the specific "talk_accepted_tutorial" email. I got the generic "talk_accepted" email. Ditto for my easy2010 talk 1718, a long talk. I didn't get "talk_accepted_long" -- I got the generic "talk_accepted." We customize the email content because the discount information varies with the type of talk. Perhaps I wasn't clear on this? Or is there some other reason why only the generic "talk_accepted" email is going out? When I originally *proposed* different types of talks for easy2010, I got the correct specific emails back, such as "talk_proposed_tutorial" and "talk_proposed_long." Thanks. Hi Denis -- I'm wondering about the coupon codes that are being sent out from easy2010. These are valid ESE 2010 coupon codes. Just making sure that it doesn't matter that they are now assigned to a bogus submission. Probably you created two separate tables of coupons for the easy2010 and ese2010, and it doesn't matter. But please say if it does so we can fix that. On a related topic -- it's possible to run out of coupons, and something we want to avoid. I think the number we have now for ESE is too low, probably because I didn't specifically ask Cija for N number of extra ones for each type. My bad -- sorry. I'll talk with Cija about getting a few extras, since running out while speakers are trying to register is not good. Denis, I did a lot of testing with easy2010. It's great to see that it's handling the accept/decline emails and coupon code sending pretty well. Once again, I'm very grateful that you're gotten this working. There are a few things that aren't quite right. My presumption is that easy2010 is currently functioning the same way that ese2010 is, so if there's an issue with easy2010 it's reasonable to assume the same problem exists for ese2010. * PROPOSED EMAILS * For these types, the correct type-specific "proposed" email is being sent: - long - short - tutorial - sponsored - poster For these types, the generic "talk_proposed" email is being sent: - symposium - keynote Proposed solution: None. Ideally all the "proposed" emails would be type-specific, but getting this fixed is not high-priority, especially right now. * ACCEPT EMAILS * To expand on comment 26 of this bug, there's a generic "accept" email named "talk_accepted" that serves as a template, but normally doesn't get sent. Each type has its own "accept" email, such as "talk_accepted_long" or "talk_accepted_tutorial." This allows us to send specific speaker discount info for each type of talk. My tests showed this: - short: the correct type-specific "accept" email is being sent - poster: the correct type-specific "accept" email is being sent - long, tutorial, keynote, and symposium: the generic "accept" email is being sent - sponsored: NO "accept" email is being sent Proposed solution: It would be much better if all the "accept" emails being sent were type-specific, including type sponsored. If this is not going to get fixed, I need to know so I can change the text of the generic "accept" email, and figure out a different process for accepting the sponsored talks. * DECLINE EMAILS * There are two flavors of "decline" email. The generic "talk_declined" is used for all types except posters. Declined poster submitters should receive the "poster_declined" email. Currently posters are getting the generic email. Proposed solution: It would be better if poster presenters would get the type-specific email. If it's not going to be fixed, again, I need to know so I can change the wording of the generic "decline" email so it makes sense for posters. * INTERNAL TYPES * - As you said earlier, in order to be accepted or declined, talks with type long, short, tutorial, and symposium must have their internal type set to "submission." - Talks with type poster, sponsored, and keynote should have their internal types set to "poster," "sponsored," or "keynote." If instead it's set to "submission," this doesn't cause a problem with accepting or declining, but it does seem to cause the wrong email to be sent out in some cases. Proposed solution: nothing really to fix here. * ETC * There are some other conditions that I need to test in easy2010, such as a talk being accepted and then declined, etc. I think some of this is working, but I didn't do an organized test of the different cases to be sure. Thanks! Anne, I'll have to look into the proposed emails issue. It may be related to the internal types I have changed, but I'm not sure why. *sigh* (In reply to comment #27) > Probably you created two separate tables of coupons for the easy2010 Yes, since easy2010 is a different conference, anything you do with easy2010 (including the coupon codes) has no bearing on ESE. > On a related topic -- it's possible to run out of coupons Just get more -- I can add them to the table at any time. Thanks, Denis. If we think we'll need more coupons we'll get Cija to send them for you to add. I need to to more testing re coupon codes and emails. Could you please "unsign" my easy2010 speaker agreement for me? Thanks. Here's what I can see right now: As you know, for the talks that DO get coupon codes, after the speaker agreement is "all signed," the system sends out the "speaker_agreement_all_signed_coupon" email. For those talks that DO NOT get a coupon code, after the speaker agreement is "all signed," the system sends out the "speaker_agreement_all_signed" email. These talk types should get a coupon code and therefore send out the "coupon" email: - long - short - tutorial - symposium This talk type needs a signed speaker agreement, but does not get a coupon code, so it should send out the "no-coupon" email: - poster These talk types don't require a signed speaker agreement, and do not need to be sent a coupon code: - keynote - sponsored In easy2010, I had these talks accepted, and then signed my speaker agreement. Here's what happened. - long talk: correctly sent "coupon" email - tutorial: correctly sent "coupon" email - symposium: INCORRECTLY sent "no-coupon" email Proposed (and necessary) solution: Fix the code so a coupon code is sent out for type "symposium." I wasn't smart enough to realize I should have had every type of accepted talk before I signed my speaker agreement so I could test them all -- doh, what can I say, it was late. So after you un-sign my agreement for me, I'll do more testing. Hey! Good news. I fixed one small problem. Now when a sponsored talk is accepted, it sends out an email. The name of the email file needed to be "sponsored_talk_accepted" rather than "talk_accepted_sponsored." So I changed it, and now it's working. (In reply to comment #30) > I need to to more testing re coupon codes and emails. Could you please "unsign" > my easy2010 speaker agreement for me? Thanks. Done. Just to make this more interesting, we have made a "policy" change and for ESE 2010 symposia, we do not want to mention speaker discounts. I will edit the sub sys emails to reflect this, but unlike what I said earlier in comment #30, we do not want to be sending out discount coupons for symposium speakers. What I'd like to know is how, when we set up a new conference, we indicate which types of talks get the "with coupon" email (thanks for signing your speaker agreement, here's your coupon) and which types of talks get the "without coupon" (thanks for signing your speaker agreement, now go register) email. So we do NOT need to "fix" things so symposium speakers get coupons for ESE 2010, but this won't necessarily be true for future conferences, so we need to know how to change this is we need to. > What I'd like to know is how, when we set up a new conference, we indicate
> which types of talks get the "with coupon" email (thanks for signing your
> speaker agreement, here's your coupon) and which types of talks get the
> "without coupon" (thanks for signing your speaker agreement, now go register)
> email.
There must be some piece of code in the submission system that says "if talk if of type X send this email and coupon code, otherwise send this one"
So everytime there is a "policy change" like this we need to go into the code and tweak stuff.
As long as this isn't difficult or otherwise a PITA, this is probably the best way to do it. Since budgets and program committees will vary, it's nor realistic to keep all policies the same from conference to conference, though or course we want the tweaking to be relatively easy to do. I don't suppose it's something that could be done in the submission system interface the way we can set talk types or tags, etc. -- at least not without significant effort to add it to the interface. (In reply to comment #35) > As long as this isn't difficult or otherwise a PITA, this is probably the best > way to do it. Since budgets and program committees will vary, it's nor > realistic to keep all policies the same from conference to conference, though > or course we want the tweaking to be relatively easy to do. I'm not disagreeing; you asked how it was done. Unfortunately, the answer to many of these types of questions is to either tweak code. The alternative is to investigate removing the "programming" requirement for those components that require tweaking from one conference to the next. Note for Gabe: For ESE 2010, these talk types should get the "thanks for signing" (NO COUPON) email: - Symposium - Tutorial - Poster These talk types should get the "thanks for signing, here's your COUPON" email. - Long - Short These types shouldn't get any "thanks for signing" email, since they aren't required to sign a speaker agreement: - Keynote - Sponsored Created attachment 178372 [details]
patch to update the ese2010 work flow for sending coupons
Here is a patch that update the work flow for ESE 2010 to send out the coupons.
> patch to update the ese2010 work flow for sending coupons Gabe, the get_coupon_details function is already in classes/functions.php. Can't we just alter that one? http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dash/submissions/classes/functions.php?view=annotate&root=Technology_Project (In reply to comment #39) > > patch to update the ese2010 work flow for sending coupons > > Gabe, the get_coupon_details function is already in classes/functions.php. > Can't we just alter that one? > > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dash/submissions/classes/functions.php?view=annotate&root=Technology_Project Yes that function does already exists, and I did alter it. I also moved it into the work flow because how we match coupons to talks tends to change from conference to conference. So it seemed to make sense to move the coupon fetching code into the workflow that also change from conference conference. You can leave it in functions or use the one in the workflow, doesn't really matter. Makes sense. I've applied the patch -- thanks. Created attachment 178752 [details]
Patch to fix the long-talk type emails
Denis, please apply this patch to the submission system. It fixes a problem with the auto-emails being sent for the long talks. Thanks.
I've applied and deployed the patch. ESE has come and gone. Fixed. |