The system should be aware of a speaker comp across tracks. ie. If a speaker is accepted on one track, acceptance in another track should not double up the comp count.
Consider, this approach, if a speaker is accepted in two tracks, each track uses .5 (half) comps.
Also, if a person is already comped like it's the case for Board and CC members, the system should be aware of those.
Keep speaker count alone. Add new "Comp" column.
Observations
It should be expected that some tracks will see a slight increase randomly upon final decision. When someone removed them from a track, the other track with jump +.5 (seemingly at random)
Questions
What about presenters with more than 2 sessions?
What about HOL? Should we create different buckets? Next phase?
Actions
Table for people exempt from comped counts: ks_event_comp_users (2) ✅
Exempt comp maintenance within the Event Admin area, allow Admins to Maintain Comps (6)
Adjust track comp calculation with the new formula (12)
Add track drill-down details for comps (8)
Add event wide drill-down details for comps (4)
Correct community and track "By the numbers" reports
Testing (8)
40 hrs
Test Cases
2 in APEX (Accepted,?) + 1
1 in Emerging Technologies (?) + 0
2 in APEX (Accepted,?) + .5
1 in Emerging Technologies (Accepted) + .5
2 in APEX (Accepted,Accepted) + .5
1 in Emerging Technologies (Accepted) + .5
2 in APEX (?,?) + 0
1 in Emerging Technologies (Accepted) + .5
1 in DB (Accepted) + .5
2 in APEX (Accepted,?) + .33
1 in Emerging Technologies (Accepted) + .33
1 in DB (Accepted) + .33
The system should be aware of a speaker comp across tracks. ie. If a speaker is accepted on one track, acceptance in another track should not double up the comp count. Consider, this approach, if a speaker is accepted in two tracks, each track uses .5 (half) comps. Also, if a person is already comped like it's the case for Board and CC members, the system should be aware of those.
Keep speaker count alone. Add new "Comp" column.
Observations
Questions
Actions
ks_event_comp_users
(2) ✅Test Cases