07-12-2016 Office Hours Chat
From David to Everyone: 10:31 AM
this is the chat!
From Mark B. (Los Angeles) to Everyone: 10:32 AM
happy chat!!
From cashley to Everyone: 10:36 AM
San Marcos did material type corrections post migration - no problem
From particpiant to Everyone: 10:36 AM
Hi Sarina, we at Northridge will also need to do this mapping work. We also migrated ITypes as notes. So please loop us in with testing w/SFSU (this is Lauren @ Northridge, BTW)
From Cal Poly SLO to Everyone: 10:36 AM
So, one of the first issues we discovered is that many of our records didn’t attach to the Network Zone. It has been proposed that perhaps the reason is that we didn’t have an 003 OCoLC in the records, this seems to be true. All our old ILS system records didn’t have an 003. Should we correct these records now so that they will attach to the NZ record in the “Go-Live” load? Or, is someone trying to “fix” this issue now in the test instance?
From Sarina Sinick to Everyone: 10:37 AM
Hi Lauren - that sounds great, will do
From Brian@SDSU to Everyone: 10:37 AM
We too migrated the ITYPE to a note field for spot checking material types and have the same concerns.
From particpiant to Everyone: 10:38 AM
From Luiz @ Northridge: David Walker and ULMS TS Leads are looking into the problem of bib records not linking to NZ. Stay tuned
^the above message from Luiz was for Cal Poly SLO
From Kirstie @ CSULB to Everyone: 10:39 AM
Our records that had 001 and 003, but no 035 matched
From particpiant to Everyone: 10:40 AM
Yes Luiz is here - check the chat above!
From Israel Yanez to Everyone: 10:40 AM
Does the OCoLC number in the 035 need to be in a specific format? e.g. (OCoLC)234567 and not (OCoLC)ocm234567 ?
From particpiant to Everyone: 10:40 AM
We are working on categorizing all the problems and will provide some solutions to all in preparation for migration.
From Holly (LA) to Everyone: 10:41 AM
Some records of our local database subscriptions were not migrated/not in our IZ. Should we created these records in IZ, or wait for the final load?
From particpiant to Everyone: 10:41 AM
And format of OCLC could have prefix or not.
Either way works.
From Eva Sorrell (CSUSB) to Everyone: 10:41 AM
Is there documentation from ExL on exactly how the matching is "supposed" to work?
From SFSU to Everyone: 10:41 AM
I also have a couple of call number questions. Is it a problem if the call number is correct, but the call number type is wrong?
From particpiant to Everyone: 10:42 AM
Meant OCLC must have OCoLC prefix and may have ocm or not preceding the number.
From Cal Poly SLO to Everyone: 10:42 AM
Thanks.
From Carole Correa-Morris to Everyone: 10:43 AM
Holly, do you have brief bibs holding those items and orders?
From Mark B. (Los Angeles) to Everyone: 10:44 AM
rhe bib records have only a title field, intentionally
From cashley to Everyone: 10:45 AM
San Marcos migrated Millennium brief bib records for databases with order records attached, they were suppressed and they migrated fine into Alma
From Carole Correa-Morris to Everyone: 10:47 AM
The migration of that kind of brief record worked fine for SJSU
From Sarina Sinick to Everyone: 10:48 AM
SFSU - I am not completely sure wha the implications of incorrect call number types are in Alma. I think that it can poorly impact sorting/searching based on call numbers. Sacramento/San Marcos might have some additional thoughts on this. However, the incorrectly assigned call number type probably resulted from not migrating call numbers based on MARC tag. I would suggest migrating call numbers based on MARC tag for the final load, and I have some more details on this here: https://calstate.atlassian.net/wiki/pages/viewpage.action?pageId=34209817
From Kirstie @ CSULB to Everyone: 10:49 AM
Eva, this might help: https://knowledge.exlibrisgroup.com/@api/deki/files/39004/Alma_Migration_Considerations_for_Consortia.pdf There's also a good document from Orbis Cascade about cleaning up the 003: https://calstate.atlassian.net/wiki/display/ULMS/Orbis+Network+Zone+documents
From cashley to Everyone: 10:49 AM
Call number types in Alma drive virtual browse in Primo
From Eva Sorrell (CSUSB) to Everyone: 10:49 AM
Thanks Kirstie!
From Brian@SDSU to Everyone: 10:53 AM
Ouch!
From ywzhang to Everyone: 10:53 AM
After two people from Pomona received ALMA certification, something changed in our ALMA test environment. For "Current at", there is only none or none and resource sharing. Can someone shed some lights on this? How to remedy?
From cashley to Everyone: 10:54 AM
San Marcos had some post migration clean up where we created sets to identify incorrect call# types and ran jobs on those sets to correct them
From particpiant to Everyone: 10:55 AM
Re: "current at" locations in the Alma menu: You have to edit the user's account to add roles with service desk locations (for example) and scope those roles to specific service desk locations
For example, you could add "circulation desk Operator" role and scope it to your main circulation desk, and then the current at menu will display the main circulation desk as an option
From Mark B. (Los Angeles) to Everyone: 10:55 AM
so separate marc fields--lc call nos in only 090, not 099 or mixed?
From ywzhang to Everyone: 10:55 AM
OK and thanks!
From Brian@SDSU to Everyone: 10:57 AM
& it was :^)
From Cal Poly SLO to Everyone: 10:57 AM
ywzhang-I had the same problem. I just needed to assign myself fulfillment roles for the different circ desks and then I saw all of them.
From Mark B. (Los Angeles) to Everyone: 10:57 AM
i was able to shift most 099 in lc collections to 090, am grateful i did
From SFSU to Everyone: 10:58 AM
Many of our patron records showed up in a default user group and many of our user group types did not migrate. How should we approach this issue?
From mariap to Everyone: 10:59 AM
Has anyone done ledger rollover successfully? I tried it and the result came through with a status of "Completed with no Bulks." Does anyone know what that means?
From Kirstie @ CSULB to Everyone: 10:59 AM
We had a similar problem to SFSU and it was a mistake we made on our migration form
From SFSU to Everyone: 11:00 AM
thanks I will follow up
From Brandon Dudley to Everyone: 11:00 AM
Maria - it means that the job was completed but no records were found
see https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/Alma_Online_Help_(English)/Administration/070Managing_Jobs/050Viewing_Completed_Jobs
From mariap to Everyone: 11:01 AM
Thanks, Brandon.
From Michael Price to Everyone: 11:01 AM
We specified a mapping for it
From SFSU to Everyone: 11:01 AM
All of our students were migrated to Default, but faculty/staff migrated to the right groups.
From Cal Poly SLO to Everyone: 11:01 AM
A general question: If your campus received your migration load statistics report this morning from ExL, and if you had a chance to review them, what did you find that was confirming, or alarming? Just curious
From Jeremy to Everyone: 11:01 AM
I've been looking too... notes show some but can't find totals.
From cashley to Everyone: 11:04 AM
That must have been an improvement. When we migrated the total checkout did not migrate like Sarina showed. Our total checlout migrated into the item statistic note field
From Cal Poly SLO to Everyone: 11:05 AM
we have very few rejects across tabs, it was indeed the count totals I was curious about, but we just got the report and will closely at that
look closely
From Sarina Sinick to Everyone: 11:06 AM
Interesting chris, It looks like they actively are making some changes to how those fields migrate. I noticed that there appears to be a mapping for internal use counts now, which is an update even since we did the test load. Sorry this wasn’t your experience :(
From Cal Poly SLO to Everyone: 11:06 AM
good point thank you
From Ya Wang to Everyone: 11:08 AM
For campuses did OCLC reclamation, did you load OCLC number in 035 field?
From particpiant to Everyone: 11:08 AM
Ya - yes, we did
From Luiz Mendes to Everyone: 11:09 AM
YES!
From Erika to Everyone: 11:09 AM
Sacramento cic.
From Mark B. (Los Angeles) to Everyone: 11:09 AM
yes, los angeles
From Ya Wang to Everyone: 11:09 AM
Thanks.
From Jeremy to Everyone: 11:09 AM
yes, humboldt
From Christine (SJSU) to Everyone: 11:09 AM
What's the turnaround time for editing the coverage date for a portfolio? How quickly will the change appear in Primo?
From Kirstie @ CSULB to Everyone: 11:09 AM
Our records matched as long as there was an 003, even if there was no 035
during migration the 001 and 003 were combined and migrated to the 035 by Ex Libris and these records matched for us
From Cal Poly SLO to Everyone: 11:10 AM
I think LB has it right
From Mark B. (Los Angeles) to Everyone: 11:10 AM
specified the 001 go into 035 in the returned records, then i loaded only the 035 matching on the bib rec number
From Brandon Dudley to Everyone: 11:10 AM
there’s a lot of info on the OCLC matching algorithm here: https://calstate.atlassian.net/wiki/pages/viewpage.action?pageId=15237125
From mariap to Everyone: 11:10 AM
We loaded into 001 with 003 OCoLC. And we still had problems linking to NZ.
From Brandon Dudley to Everyone: 11:11 AM
for example: Do we need to move OCLC numbers in the 001 to the 035 prior to migration, or will Ex Libris handle moving any 001 values to the 035 during the data load process?
ExL will move these values to the 035 during the data load process. The migration moves (003)001-institutioncode to the 035a, for example: 001: The former system number is number in 001, and the library's Marc Organization Code could be in 003. Script will discard 003, put 001 into 035 $a as (MOC)001_value-01cust
From Kirstie @ CSULB to Everyone: 11:11 AM
Yup! The only time we didn't have a match was when we had only a 001. No 003 and no 035
Yes, that's what we experienced Luiz
From Brandon Dudley to Everyone: 11:11 AM
also: As part of the OCLC reclamation process, the OCLC# was put in the 001 and the control number identifier put in the 003. In some instances, the OCLC# with the old prefix (ocl7 or ocm) is also found in the 035; in other instances the records have no 035 or have some other information in the o35. How will this be treated during migration?
Matching: The NZ linking programs use values in the 035 $a and 035 $z fields to determine a match. Note that control field 001 in Alma is reserved for the Alma internal Bib ID (MMSid), so migration processes ensure moving any previously existing 001 content to 035 $a or 035 $z. Numbers in 035: Non-OCoLC. As a rule, the exact string in the 035 $a or 035 $z fields are used for matching. For example: (NhCcYBP)40015704661, (CaOOAMICUS)000026217529,(Gale)ESTCN6838. Exact string matching is done for the above numbers, but not for OCLC numbers which have unique and special prefix handling.
From Kirstie @ CSULB to Everyone: 11:12 AM
We had a lot of records that only have 001...we plan on just adding an 003
From Mark B. (Los Angeles) to Everyone: 11:13 AM
yes, brian i can offer a load table for you
From Kirstie @ CSULB to Everyone: 11:13 AM
Orbis Cascade has a good cleanup document: https://calstate.atlassian.net/wiki/display/ULMS/Orbis+Network+Zone+documents
From Mark B. (Los Angeles) to Everyone: 11:16 AM
it seems better to move the number into the 035--since that's what ExL expects
From Mark B. (Los Angeles) to Everyone: 11:19 AM
One factor that comes to mind: some folk have 019 fields in the OCLC field tag--I don't suggest this as The Source of The Problem, but it seems a possible source for Multiple OCLC Record Numbers
From Jodi to Everyone: 11:20 AM
If we didn't do reclaimation, should we consider doing it now?
From Kirstie @ CSULB to Everyone: 11:21 AM
This is from the Alma documentation on import profiles: "When there are both 001 and 003 fields, Alma creates a 035 field that combines the 001 and 003 fields. This new 035 field is taken into account in the matching process."
So they seemed to have applied the same process to the migrated records as well.
From Brian@SDSU to Everyone: 11:21 AM
A lot of great information here. Please post soon.
From Stacy Magedanz CSUSB to Everyone: 11:22 AM
Jodi: I think it's a good idea. We plan to do reclamation. I found a number of NZ linking problems that reclamation ought to fix.
From Jodi to Everyone: 11:22 AM
Okay, it's going on the list. Thanks.
From Mark B. (Los Angeles) to Everyone: 11:23 AM
Agreed--do it now, before you _must_ do it. It's a real impact on operations, but it will help the NZ and our life post 2017
From Brian@SDSU to Everyone: 11:24 AM
Crickets
From Mark B. (Los Angeles) to Everyone: 11:25 AM
And Jodi, as you've heard people say--OCLC will offer you _your_ records back with the OCLC Rec No. Take that, you can craft a load table that will load _only_ this 035.
(...and have them put the OCLC Rec No in the 035 with (OCoLC) -- they offer a few choices.
From Luiz Mendes to Everyone: 11:25 AM
Here is the Data Clean-Up Doc: https://calstate.atlassian.net/wiki/display/ULMST/Data+Cleanup+Recommendations%3A+Priorities+Checklist
From mariap to Everyone: 11:25 AM
Is this session being recorded?
From Mark B. (Los Angeles) to Everyone: 11:25 AM
(...just a moment, I'm on the green and have to putt...) :-) :-)
From Luiz Mendes to Everyone: 11:26 AM
Here is a document by Systems Leads on OCLC Reclamation: https://calstate.atlassian.net/wiki/pages/viewpage.action?pageId=4587575
From Mark B. (Los Angeles) to Everyone: 11:26 AM
Do like the East Germans--record EVERYTHING.
From espinoza to Everyone: 11:26 AM
I think if you want to pick up all the chats while you are away, you may want to stay logged in. I logged in after 11 and only have chats from after 11...just FYI
From SFSU to Everyone: 11:26 AM
Thaks everyone!
From Christine (SJSU) to Everyone: 11:26 AM
What's the turnaround time for editing the coverage date for a portfolio? How quickly will the change appear in Primo? Immediate? 24 hr refresh?
From Mark B. (Los Angeles) to Everyone: 11:27 AM
Yes, agree with Steve--I lost connection for a minute and lost the chat to that point.
From Bin Zhang to Everyone: 11:27 AM
We are still trying to figure out authentication problem we have having… almost all our staff use external user accounts
From David to Everyone: 11:27 AM
I've got it copied and will send it out after the meeting
From dmachado to Everyone: 11:28 AM
Has anyone started setting up their reserves collection.
From Bin Zhang to Everyone: 11:28 AM
Has San Marcos resolved their authentication problem?
From Ian Chan to Everyone: 11:28 AM
Authentication to the test instance?
From David to Everyone: 11:28 AM
Hi Bin, sorry haven't had time to look at your email along those lines. Have you submitted it to basecamp?
From cashley to Everyone: 11:30 AM
yes immediate
From Ian Chan to Everyone: 11:30 AM
Yes, we had to ask our campus to open up access to our LDAP server for the full range of Ex Libris IPs
From Bin Zhang to Everyone: 11:30 AM
I emailed Svetlana at EX and they are checking on it. i just wondered if san marcos solved their issue...
From Christine (SJSU) to Everyone: 11:31 AM
Great, thanks all for answering my question about portfolio edits
From Bin Zhang to Everyone: 11:32 AM
Yes, View IT will show the coverage in real time, but coverage data (holdings file) will be sent to PC weekly
From cashley to Everyone: 11:32 AM
There is a lag for Primo to recognise that you may not own the issue covered. In that case the lag is weekly Primo updates for Alma electronic holdings. A citation would show up as owned but the full text link would not be provided
From Mark B. (Los Angeles) to Everyone: 11:33 AM
...these Primo changes remind me--what changes _now_, what gets done Weekly (and what gets done _never_)?
I had Tuesday/Saturday in my mind as one of the "publishing" times, perhaps I'm thinking of other things...
From cashley to Everyone: 11:37 AM
Minnesota gave a great presentation at ELUNA on the electronic resource managment and Primo updates/troubleshooting. They shared a toolkit that was very helpful
From Mallory DeBartolo to Everyone: 11:38 AM
there was a presentation at ELUNA that was really helpful re: schedule of Primo Central updates. here's a table from the presentation that details some of the Primo Central related schedules: https://docs.google.com/document/d/12VdPO0vZx7UcZZ7Sjd0EEMt8EQZUpCX6H2doQ8Jm5_o/edit?pref=2&pli=1
also here's a link to the whole troubleshooting guide: http://z.umn.edu/pcitoolkit
From Stacy Magedanz CSUSB to Everyone: 11:38 AM
Ah, someone found it before I did! Yes, very helpful chart of the timelines.
From Mallory DeBartolo to Everyone: 11:38 AM
LOTS of good content there
From Mark B. (Los Angeles) to Everyone: 11:39 AM
...and so can we steal some of that and park it in Confluence as part of an archive/FAQ/Resource?
From David to Everyone: 11:40 AM
Mark, we should at least link to it from Confluence
From Bin Zhang to Everyone: 11:40 AM
I have not been able to get a straight answer soon which day of the week our PC is being indexed
From Mallory DeBartolo to Everyone: 11:40 AM
Mark B. let me check in with the presenters but I'm sure they would be happy to share.
From Mark B. (Los Angeles) to Everyone: 11:42 AM
Many thanks, David and Mallory.
...you _could_ sing for us....
Yay Sarina!
Resource Configuration >> Library/Location Display
From mariap to Everyone: 11:43 AM
Excellent suggestion, Sarina!
From Mallory DeBartolo to Everyone: 11:43 AM
also a helpful resource - Ex Libris has an Online Help page that has a ton of details about Repository Search: http://knowledge.exlibrisgroup.com/Alma/Product_Documentation/Alma_Online_Help_(English)/Resource_Management/020Using_the_Repository_Search/020Searching_in_the_Repository
From Micah@SJSU to Everyone: 11:44 AM
creating Memes using video
From Mallory DeBartolo to Everyone: 11:44 AM
it can be a lot ot sift through but there is good information on these pages
From particpiant to Everyone: 11:44 AM
A while back, there was some discussion somewhere about how individual campuses could participate in the NERS process as members (since the CSU is a member). Is there something individual campuses have to do to set this up?
From Brandon Dudley to Everyone: 11:45 AM
if you are enjoying this type of interaction, don’t forget to take the communications survey I sent out to the WG lists last week!
From Stacie to Everyone: 11:46 AM
Nice plug, Brandon
From Brandon Dudley to Everyone: 11:46 AM
Thanks!
I thought it was a good, organic time to plug
From particpiant to Everyone: 11:47 AM
I think it's $200/yr per institution
From Mark B. (Los Angeles) to Everyone: 11:48 AM
Because Alma/Primo is early in Product Life, it seems _very_ important to allocate time for NERS participation by as many as possible. As David said, Contract is one way, but having seen the early years of INNOPAC and Millennium fed at times by Enhancements, it seems an important role to play (esp. for "only" $200.)
From Christine (SJSU) to Everyone: 11:48 AM
This office hour is really helpful. Thank you.
From Sarina Sinick to Everyone: 11:49 AM
the link to the communications survey: https://docs.google.com/forms/d/1iG_azp7HNbgG_xhQHp9r-UWmdnm97FbKHBY_50V6Sdc/viewform
From Mark B. (Los Angeles) to Everyone: 11:49 AM
In the tradition of Richard M. Daley (Chicago Mayor), Vote Early, Vote Often.
From Mallory DeBartolo to Everyone: 11:50 AM
is that a threat, dave?
From Ian Chan to Everyone: 11:51 AM
cat should be required for every call?
From David to Everyone: 11:51 AM
you know it
From Carole Correa-Morris to Everyone: 11:51 AM
Could be the official ULMS cat!
From cashley to Everyone: 11:51 AM
San Marcos is wondering about this too
From Mark B. (Los Angeles) to Everyone: 11:52 AM
Agreed--NZ linking and any expected functionality resulting from NZ linking.....
From Brandon Dudley to Everyone: 11:53 AM
your instances were supposed to be copied over, so there shouldn’t be any difference datawise
except that statuses won’t sync
From Stacie to Everyone: 11:55 AM
Haven't had a chance to get too deep into creating sets yet
Is there anything in particular we should be aware of, Chris?
From cashley to Everyone: 11:55 AM
Will start using San Marcos base camp to report issues and ask question. I noticed records getting suppressed in NZ environment that were not suppressed in our live environment
From Stacie to Everyone: 11:55 AM
ok we will check
From cashley to Everyone: 11:57 AM
Set to find non linked records with OCLC numers is pulling in records that are actually linked
Also the same logical set created yesterday has grown by about 2,000 records
Will do Luiz. I aslo opened a salesforce case on these issues
From Stacie to Everyone: 11:58 AM
I did find one that should have linked but didn't
We will do
From Mark B. (Los Angeles) to Everyone: 11:58 AM
...a side query: The "logical" set should be dynamic--things that changed (linked/unlinked) would either be in the set or not? Not like Millennium Create Lists, where you hav a static list and must append or re-run.?
From Kirstie @ CSULB to Everyone: 11:58 AM
We have an issue with our primary patron identifiers. We mapped UNIV ID to be the primary identifier in the mapping form, but unfortunately we managed to forget to include this column in our patron export. This resulted in the primary identifier using the Millennium patron record # instead. We're trying to get a response in salesforce from Ex Libris, but maybe someone here can shed some light on what the implications of this might be during testing..
From cashley to Everyone: 11:59 AM
right but why would logical set change so mush? We haven't made any changes to records. Are others making changes to NZ records?
From Bin Zhang to Everyone: 11:59 AM
Thanks Luiz
From Mark B. (Los Angeles) to Everyone: 12:03 PM
Interesting Mystery, Chris.
Login ID until we install the Shibboleth?
At Los Angeles, Barcode is Primary Identifier....it's the Login ID we have to use when logging in (unless we change the Primary)
(I'm talking about Alma)
From particpiant to Everyone: 12:03 PM
It looks like there's a First Look @ Primo webinar scheduled for Friday (on BaseCamp, at least). Has the connection info for this webinar been distributed yet?
From Kirstie @ CSULB to Everyone: 12:04 PM
That's what we were worried about.
Great, thanks!
From Eva Sorrell (CSUSB) to Everyone: 12:04 PM
Does anyone else use their campus ID# as both the primary id and barcode?
From Mark B. (Los Angeles) to Everyone: 12:04 PM
No
(not Los Angeles)
From Brandon Dudley to Everyone: 12:05 PM
link for friday is in the meeting reservation: PMs -
Please invite anyone on your campuses who is interested or works directly with your discovery solution(s) to this webinar.
- Brandon
Conference ID: 935673
Meeting URL: Https://Lyncmeet-us.exlibrisgroup.com/audreyh/QEAF2B31
From particpiant to Everyone: 12:06 PM
Thanks Brandon, what time is the webinar?
From Mark B. (Los Angeles) to Everyone: 12:06 PM
So do both numbers feed into the same index?
From Stacie to Everyone: 12:07 PM
Is Lync going to be able to accommodate high traffic? Just concerned since we had to switch functional calls to WebEx for that reason, I believe.
From Ian Chan to Everyone: 12:09 PM
if you have two different identifier types for one record, they each have to have unique values
From Brandon Dudley to Everyone: 12:09 PM
Friday 9-10:30
From Mark B. (Los Angeles) to Everyone: 12:14 PM
Yes, I recall something about this....guess it was ELUNA
From Stacie to Everyone: 12:15 PM
I thought something was mentioned during a functional call
From mariap to Everyone: 12:15 PM
For Fresno, Primary ID is the UID. Under the Identifiers tab we have ID Types "Barcode" and "Additional ID 1".
From espinoza to Everyone: 12:16 PM
Does anyone else use their campus ID# as both the primary id and barcode? For authentication (external) you need to have in the Primary ID the match to what is in the users LDAP record. In our case, LDAP only has the username and not the University ID number.
If LDAP has barcodes, then you can use those to authenticate external....and so forth.
From David to Everyone: 12:17 PM
Steve, with Shibboleth you should have more flexibility in terms of matching, so you could use the University ID / EmplID
I thought San Marcos used Shib with Primo. Am I wrong about that?
From Ian Chan to Everyone: 12:18 PM
Yes, we use Shibboleth for Primo
From espinoza to Everyone: 12:18 PM
I was just going to say I just hit the ceiling of my knowledge and woud defer to others as to how Shibboleth handles this. Thanks David.
From Eva Sorrell (CSUSB) to Everyone: 12:18 PM
Do you use shibboleth right now to authenticate to Alma?
From Ian Chan to Everyone: 12:19 PM
For Alma we use LDAP
From Bin Zhang to Everyone: 12:19 PM
we also use ldap for alma, and CAS for primo
From Brandon Dudley to Everyone: 12:20 PM
This is amazing turnout! thank you all!
From Jessica Hartwigsen to Everyone: 12:21 PM
https://calstate.atlassian.net/wiki/display/ULMST/ERM+Task+and+Check+Lists+for+Testing+e-Resources+Post-Migration
From Bin Zhang to Everyone: 12:21 PM
Thanks Jessica
From Ian Chan to Everyone: 12:21 PM
thank you
From Mark B. (Los Angeles) to Everyone: 12:23 PM
...this "open agenda Office Hours" has been helpful--future ones may be sufficient in 60-90 minutes, but a longer window gives more folk the chance to Stop In, even if briefly.
From Kirstie @ CSULB to Everyone: 12:24 PM
I thought it was very helpful!
From Carole Correa-Morris to Everyone: 12:24 PM
90 minutes should give people the ability to work around a lunch hour
From Ya Wang to Everyone: 12:24 PM
90 minutes better
From Mark B. (Los Angeles) to Everyone: 12:25 PM
....Oh!! Like a Stock-Market Feed--streaming across the top of my screen!
From particpiant to Everyone: 12:26 PM
Would also be nice to have functional area office hours (e.g., fulfillment, resource management, etc.)
Audio/Video is better than just chat, especially because screensharing is essential