Information on Run 11 sign-up

Signup distribution as a function of time

Within 5 mnts, 75% of the shift slots were taken and 85% within the first 20 mnts. The slots remaining after 15 mnts were mostly trainees and offline QA shifts.

Top 15 winner of the 2010 / Run 11 shift racing

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

The following below problems were identified reviewing the full workflow and functionality.

• Minor - For each period, add a bar with the shift position information - status: done 2010/XX/XX
• Minor - Before the shift opens, add warning that the interface is for training only - status: added 2010/11/04
• Medium - There is a consistency issue between the accounting page and the real administrative (edit) interface. The count information is offset - status: fixed on 2010/11/04
• Minor - Improvement. The edit page wuld benefit from an auto-calculation feature for the number of shifts per institutions. The auto-calculation could be based on a scaling factor (for example, factor=2 means 2 shifts per authors). The page could summarize a guesstimate of the ratio  status: done 2010/11/05
  
  • Feature implemented as described - a field for a ratio-factor and a [Calculate] button were added - if used, all duties would be automatically filled. A bottom summary of number of shifts to fill up and number of available authors is provided helping to determine the ratio.
• Minor - Link to the graph page does not exist (not easy to find) - status: added 2010/11/13
  
• Minor - The DB contains Shift_08 and Shift_09 which need to be removed (old scheme)
• Minor - The graph page has had several problems as follows - status: fixed 2010/11/13
  
  • X time scale does not display properly (axis shows 00:00:00 where not appropriate)
    
  • Zoom out left a blank graph, not redrawing - status: fixed 2010/11/13
• Medium - There are cases when sign-up over-subscription may still happen when either multiple people from the same institution sign-up simultaneously or a given individual signs up for more shifts than needed.
  
  • Number of shifts left for a given institution has to be re-assessed between individual shift recording
  • Transaction handling are needed. Three possibilities (a) use LOCK TABLE, count, check and enter + unlock and from other connection wait until the table is unlocked or (b) use transaction capable table format and add conditions or (c) use triggers [keyed on the accounting table and institutional dues]
  • status: suggested trigger on 2010/12/03 and leverage the fcat we have an accounting with the number of shifts per institutions (hence a lock and check of excess could be done for all institutions based on a column entry). Implemented the next week + delivered on 2010/12/09. Not tested yet for clash.
• High - maintenance/administrative (technical). The current shiftSignup setup is too complex and lacks central control of key parameters. spread over include/def.inc, include/shiftDetails.inc, ControlSignup.php, admin/index.php and ProcessingSignup.php . This makes the setup of the sign-up hard and possibly inconsistent.status: partially implemented (see below)
  
  • Includes need to be reshaped - Hyperlink such as http://www.star.bnl.gov/central/collaboration/showMember.php?id=73 should have the base "/central/collaboration/showMember.php?id=" configurable as well (no hardwired STAR specific). Checked 2011/01/05, deliverred 2010/12/13.
    
  • Possible issue with a 8 days shift need some thinking. status: checked 2010/12/13+2011/01/05 not in place.
     
• Other (some features ideas borrowed from other interfaces)
  • Add feature: auto-display the top 15 (people liked it again this year)   [DA] - status: delivered 2010/12/09
    
  • Add printer friendly view (no frame) [DA] - status: delivered 2010/12/09
  • Extend this by allowing printing for a given week (so people can go with a printout of who is in their shift, who will be in the overlap period for training and so on)
  • Improvement: similar to the STAR agenda, add navigation icons (more visible and also, people like this recent presentation idea according to Agenda question: what do you think of the use of icon images and text for accessing printer friendly version and other features?) - status: delivered 2010/12/09
  • Add the number of non-training shifts (will make easier for shift scale calculation) - status: delivered 2010/12/09
  • Color code partial weeks, grey the zone with no shifts (to make clearer ro users this is not a mistake but a shift special organization) status: delivered 2010/12/09
  • Display information about experts i.e. extent PSN0482 : STAR PhoneBook and shift accounting - Definitions and development plan with a text field describing the expertise (isExpert is already in place). Add interface to manipulate records. status: done 2011/01/xx
  • And the most important functional requirement ever: add snow-flakes falling on December 24/25th :-)  [Apart from being an internal joke, Dmitry has implemented this as verified on 2010/12/13]
  • Other features (technical) from DA, delivered on 2010/12/09:
    
    • color scheme relies on CSS styles
      
    • upon opening, Shift Signup table will rewind to "current" week automatically
      
    • conform Model-View-Controller principle (single entry point, business logic is separated from presentation logic)
      
      
• Feature review 2010/12/13
  • In 'stats', not sure that the "show experts" works ... but if so, how? It did not, implemented in December 2010.
  • The "has not taken shifts yet" also does not much for BNL, same for LBNL - this should be verfied (miss-understanding?)
    
  • Our shifts are 8 days long with one day overlap - this is not yet configurable? [priority low but would be nice to close the loop]
  • Printout of current/past/next week only is not in place [priority medium but generally, the idea is to know who will be in our shift period + the overall incoming / outgoing)
  • Functional requirements for the expert display / manipulation need a write-up
     
• Feature review 2011/01/05
  • The issue with 'has ot taken shifts yet' remains - there should be an option for "has not taken any shift at all yet" (as it stands, it is not intuitive that one needs to select a shift category to get anything). Status: added some check box on 2011/01/07 to handle all cases.
  • There is a problem with the listed member who can take shifts: Example Valeri Fine as a leave date set but elligeable for taking shifts. This should be happening. Status: possibly, the new interface acts on an old copy of the PhoneBook? Status: checked by force update and yes .
  • The "Import experts from PhoneBook" has a bug - starting from scratch, it does nothing (and wipes the local table, a definit problem).
  • The 'Control' menus heavily rely on HTML target making rather impossible to open side by side several sub-options (not only for testing but for manipualtion, it is convenient to work with multiple tabs) - Fixed 2011/01/05.
    
  • The Expert list is not correct as it stands - this may be an issue for the Shift Coordinator.
  • "If no CellPhone and HomePhone are available, the user's Email address is displayed as alternative (the display may span two columns)" - this is not working. Status: formatting fixed on 2011/01/08
  • Our shifts are 8 days long with one day overlap - this is not yet configurable? [priority low but would be nice to close the loop]
  • Printout of current/past/next week only is not in place [priority medium but generally, the idea is to know who will be in our shift period + the overall incoming / outgoing). Extended 2011/01/08.
     
• Feature review 2011/01/10
  • isEmeritus formatting not implemented - implemented same day (would be underlined)
    
  • Upon check, isEmeritus is not used yet for accounting calculations
  • isExperts formatting changes color - corrected as same color and change face (bold)
  • ...
     
• Feature review 2011/01/13
  • See comment
     
• Feature review 2011/02/01
  • Previous items are still ro be implemented and copied from above
    
    • Our shifts are 8 days long with one day overlap - this is not yet configurable? [priority low but would be nice to close the loop]
    • Upon check, isEmeritus is not used yet for accounting calculations
    • PDF features TBC (list in comment)
  • Over-subscription mechanism, now handled at MySQL level, cannot be controlled anymore and hence, no way to force subscribe an available shifter into an empty slot.
  • The EMail notifications upon un-signing was NOT implemented / propagated from past code.

Functional requirements for the emeritus (reminder) and expert list manipulation - 2010/12/13

Discussed once more on 2010/12/10, we need an interface to manipulate the expert list records and display them (historically or for the year). The general idea of the expert list is described in PSN0482 : STAR PhoneBook and shift accounting - Definitions and development plan.

Email to the management (executive+council+shift coordinator) on this feature were sent from 2010/11/30 to 2010/12/10 (10 EMails requesting feedback and OK to proceed - plenty of answers). End date for feedback was given as 2010/12/15 at which point, no feedback would mean "OK to proceed".

Basics:

• Goal: Make taking into account  experts and emeritus in the calculation of shift dues automated
   
• Principle: All records and fields are available in the database
  • Emeritus is a flag in our PhoneBook - if set, the number of effective authors is automatically reduced by the number of emeritus members.
    Implication: (noted to management in the EMail noted above): the council MUST maintain the emeritus membership - there will be no clear manual adjustments possible whenever full automation will be in place.
    Visual display suggestion: in our Shift accounting display and phoneBook, display as underlined (they will remain in blue since they are authors). Other possibility would be a font change (perhaps Arial narrow for example).
     
  • The Expert list should be kept in the STAR official PhoneBook based on a current year experts. The entry in the phoneBook would be for providing a hint only as a given individual may be an expert for many categories. Hence, a local recording in the SHiftSignup should keep member/expertize association and groupings (1 to N then possible). Historical records will be kept by performing a copy of the existing records in the Shift sign-up database (private copy). The fields handling the experts are as described in PSN0482 : STAR PhoneBook and shift accounting - Definitions and development plan. The shift accounting interface will take into account the number of experts per-institution, subtracting from the number of effective authors the number of experts to product the "Adjusted # of Authors" column. This calculation will hence be fully automated.
    
    Note that the CellPhone field should NOT be displayed in other forms than a password protected interface (it should NEVER be displayed in our public PhoneBook).
    Editing may occur for the current year mainly (the shift coordinator would edit it and adjust, operation and S&C Leader may edit their part of the list and validate/invalidate the shifters). We will refer to this interface as the "expert list editor".
    A super-administrator only editing capability would allow editing the historical records.
     
• Functional and presentation Details:
  • Two field handle the expert list: isExpert and Expertise. isExpert is a BOOLEAN - if raised, the person is an expert and the Expertise field has a meaning (otherwise, ignored). Similarly, if raised, the CellPhone field may be considered and displayed through a especially generated expert list.
     
  • Enumeration will be used so one could regroup experts of the same category under a unique grouping. Enumeration of categories of experts will be kept in a custom interface (more categories may be added) and hence, the expert list editor shall be allowed to supplement the PhoneBook table information.
     
  • The feature below should be supported:
    • The expert list editor will provide a choice on how to consider the experts in this category: (a) either all experts will be considered as interchangeable and will appear in an alphabetically sorted list under the given sub-category (a first field will show as an asterix, indicating no preference or a "OR") (b) the expert list interface will allow wieghting the experts in a category, indicating the list experts should called in order they appear.
      
      Example 1: a "DAQ" category exists and two experts, UserJ and UserT belong to this category. The expert list will display the two users with the two first columns being column 1: an option or sorting category, second column a name. The first column will allow to weight the UserJ and UserT so one could display
               1 UserJ
           2 UserT 
      having the meaning of "call UserJ first, then UserT"
      
      Example 2: a "BEMC" catagory has two users as well, userS and userO. In this case, we want to indicate a "OR" (any are fine) and assign the special character "*". The list then appears as
           * UserS
           * UserT
      indicating "either UserS or UserT may be claled". In this case, the names may be sorted in alphabetical order.
       
    • Categories may have sub-categories.
      
      Example: SHIFTLOG, PRODUCTION, Offline QA;prod:ESL:QA
      In this case, the category is the "SHIFTLOG, PRODUCTION, Offline QA" while prod ESL and QA are sub-categories which may be assigned to the name of the experts in this category. This sub-category will be assigned through the expert list editor. The sub-categories will be displayed in order they appear (not sorted). In this case, we may then have
          Prod  UserB
          Prod  UserC
          ESL    UserD
          QA     UserA
      where the order Prod ESL and QA is pre-defined by the sub-category first come first displayed principles and UserB and UserC are alpha sorted within the prod sub-category.
       
  • A table of experts will be generated with as title, the category name then the expert sorted as explained above.
    By default, categories should be alphabetically sorted BUT with the expert list editor, each category may be asigned a weight allowing re-ordering the display of categories (the idea being that some categories may be more important than others).
     
  • The weights and sub-category assignements would be kept in the private expert list editor DB (shift accounting DB) and saved by year.
    Status: Up/Down arrows allow increasing/decreasing category weighting.
     
  • For each expert, the following field shall be displayed:
    SortingIndicator(see above)  Name OfficePhone   CellPhone   HomePhone 
    Possibly, the institution name could be indicated in smaller font.
    If no CellPhone and HomePhone are available, the user's Email address is displayed as alternative (the display may span two columns).
     
  • Initialization by year would occur as follows
    • A one button click would import the expert list into the private database (that is, from the STAR PhoneBook to the shift accounting / expert list editor DB).
      • Upon initilization, records are copied and the editor allows for assignments of category weights, user weights (or "*") or sub-categories as applies. The default starts with an "OR" list
    • Another button would allow to import / start from the previous year ("copy from previous year). In this case however, the copied list MUST immediately be checked against the PhoneBook:
      • records in the private DB but not in thePhoneBook should be indicated as "not present" (use blink for example) and confirmation requested. If confirmed, the records in the private DB are removed.
      • records not present in the private DB but in the PhoneBook should be indicated as "new" (a color scheme would suffice to indicate those new records). Confirmation is also asked and if confirmed, the additional records are imported.
    • The initialization would happen by year i.e. a tag Y2010 for example could be used to indicate to save it as Y2010. Only a tag enetered for less than a year would be altered by multiple users (shift coordinator, operation and S&C leader). Beyond a year period, all other records would be considered as historical.
       
    • After import, the expert list editor would always check the following upon access:
      • For all of its privately saved expert list, check if the PhoneBook isExpert is set and if NOT, indicate the offset and ask to confirm removal from the private DB.
      • The PhoneBook should correlatively be checked for all records marked as isExpert. If records are found and not in the private expert edit DB, the records should be indicated as new and a confirmation requested.
      • In both cases, if confirmation is not granted, the PhoneBook should NOT be updated but the conflict should be resolved by contacting the spokesperson office responsible person updating the DB (in other words, the spokesperson office PhoneBook maintainer records would prevail). An automated Email mechanism may be used.
    • After import, the expert list editor would allow to:
      • Modify information per experts (Telephone numbers, ...) - any modifications made should trigger a confirmation and a warning this would affect the original PhoneBook. Upon update, the PhoneBook should be updated as well as the private DB.
      • Add experts - an institution / member list appears. Members here would designate ANY member (author or not). A category listing would then be assigned (drop down, default value set to whatever teh Expertise field is set to or None) and the phone information fields asked for confirmation or edition / update. Upon clicking on an [Add] button, a similar warning would appear that the PhoneBook records would be updated. Both DB would then be updated. Upon addintion, a notice should be sent to the spokesperson's office PhoneBook maintainer to keep him/her informed of the changes.
      • Remove experts - a check box should allow unsetting an expert isExpert flag from the PhoneBook DB. This would disable the user (the primary information on expertise would not be removed, allowing retreiving the information later). Upon removal, an Email should be sent to the spokesperon office PhoneBook maintainer.
        Note that the possibility of circular remove/add is circunvented as according to the check section above, if the flag for this member is reset to isExpert=Yes, the only thing the expert list editor would do and allow is to accept the changes (and importa the record again) or decline (and hence, no change but trigger an Email - hopefully, people will talk to each other at this point and resolve the issue).
      • Modify expert category string - if done, all categories would be modified
      • Add expert category string - if done, the PhoneBook enum() would be altered and extended
      • Remove an expert category - this could be done ONLY for enum() value having no assigned experts.
      • List all experts under a given category and allow modify, remove experts in that catgeory. Note that this is a sub-feature of the add / remove (a selector would act upon the same feature as described on the above modify/remove)
         
    • Only a super-user may alter records from previous years  (the only use case seen for this would be the initialization of older year's records). In this case, all functional requirements (edit, update, etc ...) should be enabled but no check may done against the PhoneBook (and no alteration either) since the PhoneBook doe snot contain historical records but only the expert list editor "private" DB. Note that the historical records from the shift acocunting / expert list editor should NEVER be deleted.
       
    • The expert list editor DB records may contain:
             [Id,  UserID, InstitutionID, CategoryID, Sub-category or Sorting value, EnteredFirstOn, DisabledOn, YearTag 
      Field names are just examples. The EnteredFirstOn and  DisabledOn fields may allow for finer grain historical display (for example, if part of a year had an expert but we remove 1/2 way due to non-availability, this could later be documented). Additional fields may include:
             ... OfficePhone   CellPhone   HomePhone   Email  Comment]
      for full historical history purposes. Comment field may be used to display additional information for an expert on call.
      There are many advantages to keep the categories in a separate table, also associating a Comment field to each category in case a special message is needed next to a category (this table would act as a dictionary, stepping away from enum() IF we can centralized the logic for the PhoneBook) but also to assign weights to categories.
       
  • Presentation / printing
    • In summary, the expert list would be displayed as a double layered table based formatting with the first layer having for each row, the expert category list as a formatted string (bold except what is in parenthesis)
    • Within each row, we would have a sorting tag + expert name (eventually followed by the institution name in smaller font) + Office Phone + CellPhone & HomePhone or EMail address
    • An example appears below as exhibit
      
      
       
    • In the above example, the phone numbers are displayed as-is and some formatting are not standardized (magnet non-bold font not in parenthesis). This example was taken from the expert list from 2009/2010.