Information on Run 12 signup

• Accounting and dues for Run 12
• Expert on call list
• Signup distribution as a function of time (available after sign-up begins)
• Top 15 first signers / winners of the Run12 sign-up
• Run extension, shifts before and at the extension date
• Sign-up process observations and lessons learn
• Technical (not for user) - issues and improvements for the interface

Accounting and dues

Please find attached a PDF with all shift dues at the bottom of this page.

Experts on call (temporary)

A temporary list of experts is available as attachement. Please, use this link for the official and most up to date expert list.

Signup distribution as a function of time

Top 15 winner of the 2010 / Run 11 shift racing

The first 15 people who signed-up for shifts. Time are in BNL time.

Run12 extension

The table below represents the shifts before and just at the extension day - this table may be used temporarily to view the shift composition.

Observations and lessons learn

This is a list of observations and lesson learn from the Run 12 sign-up.

• Not having the Period coordinator list ready by the time of the sign-up opening creates two issues
  
  1. Slots become available for shft sign-up (instructions sent to stramail included not to sign up for those - it seem to wokr so far)
  2. The quota may not be striclty ensured - some institutions with PC assigned (later) may exceed their quota, taking slots from others
• Within the first 10 mnts, 65% of the slots are taken - then, sign-up reach a slow growth plateau
• Shift due policy related:
  • The buy back author mechanism was requested by Jammu - this worked well (shifts dues were calculated globally according to the revised formula in the next section and we added the extra shift dues by hand for Jammu). Ideally, whenever the shifts are coverred, the authors will be restored.
  • The other institution did not ask for a buy-back - however, they signed over their allocated shift due (1 shift). THis means that after a year period, they would be allowed to request more authors to be added back.
     
• We had a case of a slot taken but the name not being displayed (member ID 1140)+ an empty row in the institution table appeared after the signup opened
  • Impact assessement: None for the sign-up but large disruptions/distraction for administrator (entries fixed by hand)
  • Status: investigating - both issues fund to be related to members saved in the sign-up DB with institution ID=0 (however, member has an institution assigned)
• Some name did not appear on the sign-up interface although the slot was assigned (institution showed up).
  • Impact assessement: none (presentaion only)
  • Status: This is understood and corrected (one function prevented rejected author to be fetched - but authorship and ability to sign-up are separated issues, only the isShifter flag is relevant)
     
• We received a report of a user (Daniel McDonald) not able to unsubscribe from a slot
  • Impact assessement: minimal, user may take a slot by mistake but administrator can unsubscribe easily
  • Status: Odd and TBC
     
• The adminstrator bypass oversubscription_protection DISABLED did not work. The config.ini had to be changed instead (meaning the config override interface is not useful)

Shift sign-up identified problems, possible improvements (and status of issue)

For now, no issues concerning users: no need to read, those notes are for myself to keep a list of improvements and TODOs for future development.

Technical improvements could include:

• We should extend the sign-up with a configuration switch to block signing up in the Period coordinator slot (came this year that the PC were not yet contacted while the shift sign-up opened)
• Non institutional groups (like United States Naval Academy) should be font coded in the institution accounting page. They are currently not included in the administrative accounting page (this is fine and intended) but the overall view may be confusing without a visual clue of a specific treatment (this institution does not have a council seat but is listed on publications)
• The handling of experts (by the shift sign-up administrators) is spread over three forms one has to manipulate. While the steps are relatively clear (import from PhoneBook, create category, assign people to categories, adjust expert credit if needed [default logic based on OR and AND grouping], save), this is not optimal and need consolidation
   
• We should have a button handling the zeroing/wiping out of the DB content (more convenient, now done by hand when the shift sign-up is prepared for the grand opening)
• Logic for calculating dues, shifts and accounting is spread over several codes - this needs consolidation (accounting.body, institutions.action, accounting.action so both in templates and actions)
• The adjustment for emeritus is currently manual if an initialization from no author is made (relates to previous issue, defaults # effective authors is the # active authors using a HTML form default value but we should calculate this taking into account the emeritus ... besides, initial values should not be the role of the template)
  • The initialization of #effecive author is also "manual" (from the default value) - we should have a button "calculate effective author now". General states (diagram) should be at least [none], initialize -> [initialized], unlock initialization -{+confirm}-> [none], initialize
• In 2011 (Run 12) we added the possibility of assigning credit values to experts (0,1 or anything else). While this is primarily used for allowing the inclusion of experts with no credits on the summary page (FGT for example and possible handling and adjustment of OR) the logic may not be all consistent as spread (the accounting accuracy was verified however)
  
  • The institution summary table should color code experts with zero credits differently to avoid confusion. A suggestion would be author+expert without credit <-> light blue, non-authors+expert without credit <-> grey (in all cases, bold).
  • The experts without credits should not show a unit value in the column "# of Experts" column. Right now, the quick implementation was to leave this column count on all expert but the calculation of dues accounts for the value of the expertise (0,1, .. N). This needs to be resvisted (not implicit and not te best choice as hide logic and present confusing information). Additional font effects may be thought of for experts with more than one credit (no case for now but may happen, better to be ready)
• The total number of possible shifters should be displayed in the statistics table as well (again an issue of where accounting is made and consolidation would help)
• We manually calculate the number of effective shifts based on the statistics at the bottom of this page.
  
  • However, the previous year tells us the statistics on the number of training slots (for Run 10, final statistics is 43.65%). This should be imported from previous year to current and a "guess" calculation made
  • Formula for guesstimate: Slots=NTS+TS*TS.Occupancy where NTS=non training slots, TS=training slots, TS.Occupancy %tage  occupancy from previous year
  • Guessed ratio is (Slots-BuyBackCount)/TotalNumberOfShifters
• If IDs in partial_shift_week_ids overlap with disabled_training_shift_week_ids, the counting of available slots will be incorrect (for example, setting 0,1 and then 1,18,19 would make week 1 overlap between those two categories and decrease the number of shifts accordingly). While this has no incidence on credits, for the shift coordinator, it is confusing (besides, the logic should be resilient to configuration preventable mistakes)
   
• While the over-subscription limit is handled via a parameter, it is also handled as a MySQL trigger. We should find a way to make the parameter and the MySQL server setting (trigger) consistent without violating the separation of privileges principle (intremediate marker, cron, validation and EMail notice upon value change would be one possible way). This needs further thinking.
   
• The possibility of advanced users using scripting to sign-up (hence get an advantage over others on slot choices) is not null. We should review mechanisms to circuvent this (and include the possibility of key-learning mechanisms). Faireness implies no bias toward computer savvy indviduals.