...
CONs: it’s one additional process to manage
Josh’s thoughts:
I think there’s a lot of benefits to using this for some of our observer communications.
… but, we’ll likely not get much traffic to it for a while as this email alias isn’t used much. We’d have to try to steer observers to using it over time,
We’ll have to similarly redirect internal notifications which use this email alias (I think some alarms use it).
Similar to how remote observing was handled, we may want to create a new email for this. Since it is for observer questions and not really for instrument questions only, something like observinghelp@keck or observingquestions@keck, etc.
Description. We keep the internal aliases instruments@keck.hawaii.edu and the various <instrument>_info@keck.hawaii.edu but we add something like <instrument>_help@keck.hawaii.edu or something like Josh suggested. We change the web pages to point to the new emails and to a web form
Discussion topics
all1:02 | Words from John
| John
| Engineering requests are in, not much from instruments. Communication from Andrew about new social distancing guidelines, please read those.
|
1:04 | Review of past actions | all | |
1:06 | Help desk to replace instrument email | Luca/all | Because we are already on emote Observing Help Desk, we can do other ones for free with the same people. Utility would be to keep track of questions and avoid duplications and avoid questions “slipping through the cracks” Current lists (instrument@ and [instrument]_info@) are used both internally and externally. Would need to change emails listed on web pages Would need to change where some auto generated emails get sent (observers replying to the LRIS/DEIMOS config form emails are one source of emails to instrument@) We should follow up with other recipients of the instrument@ email list to see if they would mind being taken off. Don’t need to redirect pcs and ssc instrument emails
|
1:26 | Post-Covid work model | all | Jim: Some equipment was taken home for COVID, how do we manage part time return to office for those items? Carlos, Josh: concerns about equipment at office (see above). Infrastructure at home is superior. Kyle: network at office is inferior than many home setups Greg: was able to get a new chair by asking John: Network is being included in project already Josh: Zoom setups in conference rooms need to be really solid and well designed Carlos: issues in remote ops rooms John: try to separate return-to-work from good long term tools for the job Carlos: can we really disentangle remote ops qualities from return to work because night ops is a major component of work Luca: proposed process We have a list, need to get consensus on what items are important Create confluence page with list. Can prioritize concerns if everyone rates them
Kyle: What about bigger issues? Do we all need offices? New working models? Jim: 2 new SAs coming + Juan Carlos’s replacement and others are coming to the organization. Space will be at a premium. Josh: people will need to be confident that not having an office will not lower their profile or make them seen as less important to the team Carlos: shared office is possible if only part time on campus (obviously not during COVID times)
Greg: Other remote ops issues? loud sounds in RO1? lighting? Carlos: size of remote ops is good, don’t downsize it. We are a classical observatory. John: Separate things which can be solved with modest effort from those which need major projects.
|
2:15 | Pau! | | |
Action items
- Luca RizziJosh Walawender Come up with proposed details for new help desk and bring it to group for next meeting.
- Luca RizziJosh Walawender Create confluence page for return to work concerns
Decisions