4:00 - 4:05 p.m. - Announcements (5 minutes)
No announcements.
4:05 - 4:30 p.m. - Introducing The Feed Every Devil Program, Sheri Tibbs, Laura Andrews (15 minute presentation, 10 minute discussion)
What it is: The Feed Every Devil program (FED) was created by students from the Code+ program and aims to address food insecurity among students at Duke University. The application allows students with meal plans to donate food points to a central pool that can then be redistributed to food insecure students.
Why it’s relevant: The program launched in November 2021 and to date has received over $4,300 in food points which has allowed DukeReach staff to redistribute these points to 70 food insecure undergraduate and graduate/professional students. This application is an integral part of the landscape of food security resources at Duke and serves as a bridge to assist students in connecting with long term resources to alleviate food insecurity.
Laura Andrews introduces herself as the Director for DukeReach. DukeReach is part of Student Affairs and provides resources to help students in need. DukeReach activities include helping students with hospital stays, family issues, and food insecurity to name a few. Sheri Tibbs is a developer.
Laura introduces Feed Every Devil (FED) which is an app that provides an opportunity for any Duke student to donate up to 100 food points. These food points get pooled and then, both undergrad and graduate students who are experiencing food insecurity can request these points. In this way, food points that are not being used can be redistributed.
Sheri adds that Mary Pat McMahon, the Vice Provost of Student Affairs, advocated for this idea and Code+ took up the project in 2021. DukeReach and Duke Dining were very engaged with the project as well. The FED app was programmed with Ruby on Rails and interfaces with a Postgres database hosted on OpenShift and using Shibboleth authentication. The app integrates with Transact and SAP via Duke Card Broker. The FED point pool is an SAP GL account. Reconciliation between FED and SAP is done monthly.
Sheri says the Code+ students made much progress on the app. The app was then transferred to Richard Outten’s team’s stable of apps. One student, Ahmad Khan, is still involved in supporting the app as well. Weekly meetings are held with DukeReach and Duke Dining as work continues on features.
Laura continues with statistics of the FED program’s impact:
FED launched November 2021
$4,300 of points were donated
Points were redistributed to over 70 food insecure students
Average points received per student: $61
Every student who applies is contacted and talks to a DukeReach case manager about short and long-term resources. Issues students experience include:
Students not eating 3 meals per day
Students do not want to put more hardship on their family
Students that are on financial aid, don’t have enough money to bridge the gap for food
Students who can’t afford food on campus feel they are missing out on the social aspect of dining
Future efforts for the FED program include:
Sending out Post-FED user survey (next week)
Surveying entire Duke student population on the prevalence of food insecurity
Creating the Food Security Action Team (FSAT) which will include members across campus
Involving Alumni Development and donor funds
Hosting an AmeriCorps VISTA 40 hours/week position to focus on food insecurity
Increasing support for the Graduate and Professional School Government (GPSG) Community Pantry
A Campus Food Security Engagement Listserv has been created providing information about food insecurity efforts and GPSG Community Pantry volunteer opportunities.
https://duke.qualtrics.com/jfe/form/SV_3gbrNQgJi1gdrhk
Q. Mark Palmeri – This app and program seem great but why isn’t it the university’s responsibility to provide subsidies instead of asking students to donate points?
A. Laura Andrews – This program has created much engagement and motivation around addressing issues of food insecurity, but this is not the only thing Duke is doing around the issue.
Q. Tracy Futhey – Do you have thoughts about how we can support this type of project as an ecosystem? There is a constant refresh of students which brings in many new ideas but then, the students leave so how do we continue to provide support for these projects?
A. Sheri Tibbs – Students are new to these project skills when they begin. As a Code+ project lead, I try to teach project management standards. This FED project has been adopted into the OIT ESS web suite of projects. We try to set it up so that the Code+ team follows the ESS standards but given that it is a 10-week class, it is a lot of work to bring the project fully up to standard.
A. Laura Andrews – It was helpful to meet directly with the Code+ team in involving the DukeReach team.
A. Jen Vizas – The FED project needed DukeReach and Student Affairs’ backing. This type of backing enables the student projects to take off.
Q. Paul Jaskot – It would be interesting to know if anyone is aggregating digital projects at Duke related to social justice and community engagement. A list would be great!
A. Jen Vizas – I’m not aware of one but this is a great idea, and we should.
A. John Board – 3 or so of these projects are now in production. This is the charm of Code+: that freshmen and sophomores can learn and create these not quite ready for prime-time projects. It would be nice to have someone who could take these prototypes into full production.
4:30 - 5:00 p.m. - Update on Atlassian Application Support, Laura Webb, Chris Meyer, Jen Vizas (20 minutes presentation, 10 minutes discussion)
What it is: Atlassian, the provider of several applications in widespread use at Duke like Confluence (Wiki) and Jira, has announced that support for on premise environments will end in February 2024. After that point, only cloud environments will be supported under a SaaS (per user) license model at a substantially increased cost to Duke. The current Wiki and Jira service offerings at Duke have several thousands of users across campus who have, for years, had unlimited and cost-free access to these tools.
Why it’s relevant: We expect the future service model to be financially unfeasible for Duke, and so we expect to shutter and transition these services over the next two years. The project team recognizes this shift will be significant and impactful for many current users in terms of both license and migration costs (time and money). Therefore, we have identified a number of potential paths forward and are in need of feedback from ITAC prior to proceeding. How is the Wiki being used currently? Would users be able to pay for an alternative solution? What kinds of resources are available for migrating data?
Jen Vizas says that Wiki.duke.edu is a service provided by Duke for a nominal cost. Atlassian is also the provider of Jira. Atlassian has posted:
Support for Atlassian Server products ends on February 2, 2024, but you can stay supported and benefit from continued innovation by migrating to our cloud or data center products. We know this is a big change, so we’re here to help with answers to all your questions and recommendations for what to do next.
OIT is deciding what path to take going forward. January 2023 is the deadline. If Duke purchases some Atlassian, then the migration date can be extended to 2024.
Laura Webb says a Wiki devoted team and a Jiri devoted team have been created. As a 1st step, Laura reached out to peer institutions including the University of Chicago, University of Pennsylvania, Cornell, Berkely, Yale, Harvard, Princeton, NYU, Georgetown, and more. Many of these institutions have already moved to the Atlassian cloud so a conglomeration that would rally to pressure Atlassian was not found.
Next, Laura looked at user data. Atlassian information about users is not direct so multiple data sources were needed.
JIRA – 1200 users
SAP
SISS
OIT-ESS
OIT-IDMS
This group will probably move to the Atlassian cloud.
WIKI
Staff – 6017
Faculty – 1701
Students – 3598
Affiliates – 1221
For the year 2021, 4,862 users logged in. The Duke Wiki is being used for publishing, collaboration, and sharing internally and externally. Positives include:
Search and discoverability
Hierarchy of information and sharing
Easy to use editor
Tracking of user activity
Integration with existing Group Manager
Chris Meyer addresses other factors. HIPPA/BAA compliance is coming to Atlassian environments in 2022. A security audit of the Atlassian environment with ITSO is in progress.
Chris says that alternatives to Jira/Wiki are available but are not an exact match and will require manual migration. Some alternatives include:
Wiki.js – will not keep the directory structure and has no import feature but is a top contender
Mediawiki – no import feature
Xwiki – is containerized but stable; needs plugins to make user-friendly
Jen says Atlassian Cloud will be a 5-fold increase in price from $30,000 to $150,000. Some other choices would be:
Use of Duke’s current tools – Teams, Box, SharePoint, Sites@Duke Express, Sites@Duke Pro, OneDrive, etc.
Custom OIT-built website
https://www.atlassian.com/software/confluence/pricing
Chris concludes with questions to ITAC:
How is the Wiki being used currently?
Would users be willing to pay for a Wiki service going forward?
Would users be willing to clean up and migrate their own data?
Q. Evan Levine – When you say recommended alternatives, is it determined that we do in fact recommend standing up an alternative as opposed to looking at how many similar features (or even Wiki functions) might be available in other tools in use at Duke?
A. Jen Vizas – Some users did test Sites and Box and abandoned them.
Q. Michael Faber – Does going with Atlassian cloud buy us some of their other tools like Trello?
A. Laura Webb – Everything is a separate cost.
Q. Tim McGeary - The Libraries have heavily invested in Confluence for internal documentation of workflows, onboarding materials, training, and material restricted to Duke NetID access. The churn of having systems pop up and then, be decommissioned is problematic. If this decision is made to switch, we would want to stop adding documentation. This would have a heavy impact on users; many higher-ed projects use multiple instances of Atlassian Confluence.
Q. Damaris Murry - We use the wiki as a knowledge base but are not thrilled about the user experience. We’d be happy to migrate to a different/better tool.
Q. Mark Palmeri – Our whole research lab uses the wiki. We were hesitant to buy into this infrastructure because as mentioned by the library, this is a revolving door. Every time we have to make this type of change, data is lost including history and data structure. This type of loss is even more serious with the University’s retention policies that are coming in. This is how data gets lost.
A. Ryn Nasser – A large part of the challenge is weeding out the Wikis that are 1. Still being used and 2. Kept up to date.
A. Chris Meyer – Paula Batton’s team uses Wiki to communicate within the team and outside of the team in a protected way. Some teams have a heavy reliance on Wiki for documentation and communication. Some teams are in the process of cleaning up to see which documentation is worth transferring. There is a lot of stale information in the Wiki.
Q. Tracy – This is the challenge with a free good. If we must charge, how much are departments willing to pay to keep the technology? Are there alternatives? Should this technology be funded instead of something else? Or should funding go toward development?
Q. Evan – Is there a smaller price other than for the full enterprise?
A. Laura – There is not. There is a per-user cost. If Duke went with a per-user cost, then effort would be needed to move a lot of people off of the license while keeping only those who really needed it.
Q. Chris Meyer – This is what Laura is trying to talk to end-users about. Do they want to pitch in and pay? Also, if Duke moves to Wiki.js, how long until it has a 5-fold increase? Also, the effort in moving content must be considered.
Q. Laura Webb – Are you willing to pay? Or how much of your resources are you willing to use to migrate your data?
A. Jen Vizas – This will be a very manual process unless Duke moves to Atlassian in the cloud.
A. Mark Palmeri – I’m surprised there is no path to migration.
A. Jimmy Doff – It is not in Atlassian’s interest to make moving out of their product easy.
A. Tim McGeary – For migration cost, I think time would be the largest cost.
Q. Mark Palmeri – Learning Innovation staff similarly tell us to move our grades to Gradescope but there is concern about moving data to the cloud where we don’t control it. Tech in the cloud makes things "better" but so much is lost.
Q. Tracy Futhey – What are your thoughts about how to get out from under this vendor “move to cloud” world that often comes with sudden and large costs?
A. Mark Palmeri – When we had our own IT staff and hardware, things were good. We were sold that this would be more cost-effective but when you are a puppet and not controlling your own strings, this dependence on an outside resource becomes a liability. This seems to be a snowballing effect year after year.
A. Jimmy Dorff (in response to a Zoom chat question) shares further information about MoinMoin but cautions its use.
5:00pm - 5:30 p.m. - Refresh and Evolution of Duke Enroll, Michael Faber (20 minutes presentation, 10 minutes discussion)
What it is: Duke has a variety of co-curricular programs offered by a wide array of departments, including the Innovation Co-Lab, +DS, CDVS, CCT, academic departments and programs, and a wide variety more. With feedback from many of the stakeholders of those programs, the Co-Lab is spearheading the development of an updated platform to manage and organize those co-curricular opportunities.
Why it’s relevant: Major goals of this platform include helping support emerging needs around tracking co-curricular efforts for experiential components of certificates (i.e., Digital Intelligence), providing simpler experiences for faculty/advisors to recommend co-curricular experiences to students as “level-setters”, and providing a way for learners to have more agency over their preferred pathways through these opportunities, regardless of the program offering them and their delivery method (sync vs async).
Michael Faber, Sr. Manager of Academic Technologies, is working on Duke Enroll, a Duke Co-Curricular Course discovery and tracking platform. The need for Duke Enroll arose from the proliferation of non-curricular courses including courses from:
Innovation Co-lab and Roots workshops
+DataScience
Data+
DTech
Center for Computational Thinking
The Center for Data and Visualization Sciences
Duke Create
The goal of Duke Enroll is to meet various needs including:
1. Decentralized Ecosystem – A variety of co-curricular programming is being run out of a variety of departments without any standardized way of viewing that content at a global level for the learner. Learners should be able to flow seamlessly through learning experiences no matter where they live.
2. Co-Curricular Management – A need exists for flexible tools to organize experience for learners into tracks or pathways, and to provide recommendations around learning goals, regardless of whether that learning experience is in-person, live remote, or asynchronous.
3. Curricular Complement – Faculty, instructors, and certificate administrators need a way to discover, recommend, or shared co-curricular learning experiences with students in their courses and programs, and validate their students’ completion or participation; these courses are a complement to the curricular program.
Michael describes the approach of Duke Enroll which involves module architecture. A module is a self-contained context-specific learning experience. It is not a 2 or 3-minute video but not at the other extreme either. Like Roots, a module may be a 20 minute to 3-hour learning experience. A module could include both asynchronous and synchronous content. Michael shows an Intro to Git module which includes:
Live Roots class – January 31
Live Roots class – February 23
Self-paced course
When a user enrolls, the course is added to the learning plan. Synchronous classes would be marked as attended. Asynchronous classes would either be linked to the module or involve self-reporting. Upon completion, the module is added to “My Learning” history. Each action can trigger email and SMS communication such as reminders.
Michael continues by saying that Duke Enroll is not a learning system but sends users to the best resources. Duke Enroll provides for cross-departmental sharing of course resources and for organizing learning modules into tracks.
On the learner experience side, benefits include:
Discovery
having modules indexed in one place enables easier searching
searching by Tracks is provided
searching departmental offerings is also possible
searching by live or self-paced, by name, by description, by metadata is all possible
Recommendations
Others can recommend what they have taken
If 1st in a 3-class module has been completed, reminders of what is next can be sent
Michael shows a word map of all the roots classes ever offered. Michael has been working with a Fuqua professor on historical data of what students took next after completing a specific class.
Recommended activations include:
Signup, cancel, get waitlisted
Module completion
Track completion
Time-base or event-based
A/B testing
Tracking Learning – Students can search, sort, and export their learning history including all the information about a module and its total “time effort” expended.
The Duke Enroll application is the front end for the Duke Enroll API which will have access to data from:
Colab.duke.edu
CCT site
+DS site
Duke events calendar
Registrar possibly
Student Information Systems (SIS) possibly
External learning platform possibly
Michael is in the process of starting to build Duke Enroll. He has talked to the CrUX and the Dev teams. He has been in discussion with Learning Innovation as well. These are the questions he has for ITAC:
What needs have not been identified that would make/break a platform like this?
How do you foresee this helping your courses/departments integrate co-curricular programming?
Any suggestions, features, feedback, potential stakeholders?
Q. Paul Jaskot – Are you talking to the humanities communities?
A. Michael Faber – The Co-Lab is interested in supporting anyone who needs technology to be supported in their curriculum. Technology is a tool and that includes linguistic analysis and policy work if that is what is needed. If there are any ways that technology learning can be incorporated into your curriculum, then we would love to help. This is not only designed for Pratt and Computer Science.
A. Paul Jaskot – A grad student developed a Python module from a visual arts standpoint, and it made more sense to Paul than anything similar that he had seen. Also, the tracking and identification of modules may push students into a structure that may or may not be good.
A. Michael – There are different types of learning (e.g., academic learning vs. learning to create a project.) Duke Enroll is aware of this and does not force a path. The student can branch out as wanted and there is a breath of options.
Q. Victoria Szabo – This looks like an elegant solution. How much is this a discovery vs a credential tool? The answer is probably that it is transitional.
A. Michael – Maybe we could build in an assessment and if a certain score is achieved, a credential could be added.
A. Evan Levine – Transitional is a good word here. In 2, 3, 10 years, Duke may have a solution for this. But Duke Enroll meets a need that Co-Lab and others have now. Eventually, we may build something broader.
Q. Evan – Can departments have a departmental chunk? Who defines the track?
A. Michael – A department owns a track. Someone must own a track or there are competing desires.
A. Evan – What you say makes sense. If a track sat at a higher level, then governance would be needed so this is better.