Service Type

Each service has a type, either Schedule or Calendar. The type is specified in the first part of the URL after the base address. It should be a single, lowercase word without spaces or special characters:

https://ucdenver.xyz/learning-resources-center/schedule/some-service-name

https://ucdenver.xyz/learning-resources-center/calendar/some-service-name

Service Name

The service name acts as a unique identifier for each page. While the name performs various tasks in the backend, its primary function is to create a new folder in the database where future sessions will be stored and managed. The service name should be specific, lowercase, and without spaces or special characters, such as peer-tutoring or study-skills-workshops.

https://ucdenver.xyz/learning-resources-center/service-type/<descriptive-service-name>

404 Errors

If a 404 error or any other type of error occurs, always double-check the URL, as it can often be the primary cause of issues within the system.

https://ucdenver.xyz/learning-resources-center/service-type/name with spaces, CAPS, or illeg&@l ch@r&@ct3r5

Scheduled Sessions

Scheduled Sessions follow a specific organization method that requires a certain set of values for each session. These inputs use a specific naming convention, which will be explained below:

Subject:

The subject is used to group sessions together under a broader term, referred to as Subject in the editor. This not only groups sessions with a common subject (like Chemistry for all general chemistry and organic chemistry sessions), but also allows users to filter sessions by subject before browsing them.

Course:

The course groups sessions together that cover the same content. Continuing the example above, a General Chemistry course would be organized under the Chemistry subject, and further grouped under the General Chemistry Course.

Courses can be separated by commas. This means that if Jane Doe's session covers General Chemistry 1 and General Chemistry 2, the course information can be entered as 'General Chemistry 1, General Chemistry 2', and the system will divide that single session into two different courses. The example above illustrates one session covering both courses.

Mode:

The mode of the session indicates whether the session is hosted live, in-person, or remotely via Zoom. If the session is set to Zoom, a hyperlink should be included.

Host:

The host is displayed to the user to humanize our services and, ideally, to put a face to the session. The host can either be entered as a simple name, or the staff's profile can be created via the staff editor.

Date and Time Logistics

Day: This input indicates the recurring day each week that the session is held.

Start and End Time: These inputs set the start and end time of the session. Sessions are organized in order of start time.

Start and End Date: These inputs determine whether the session is active. These inputs default to the current semester so that sessions disappear once the semester has concluded, or when our services for the semester end. Alternatively, you can use these inputs to create a temporary session that will only appear to users between the provided dates.

Additional Options

Keywords: Although optional, these keywords are important for providing users with a quick overview of topics and content covered. Additionally, they are searchable through the system's search engine. For example, if a user searches for 'Balancing Equations', a keyword included in this input, the session will appear in the search results for users to find easily.

Additional Info: Although optional, this section can be used to engage students. The heading (required when the checkbox is selected) can be used to creatively describe the benefits students can gain from attending the session, while the text provides further context about the session.

Hyperlink: Whether a session is remote or in-person, a hyperlink can be attached to the session for features like registration or connecting to a Zoom meeting room. The Text input is used for the text displayed to the user, while the URL is embedded underneath. Note: The URL requires a full URL (including https://).

Location

The Location feature allows admins to add a custom location to in-person sessions (the feature will disable automatically if the sessions is set to zoom). When left unchecked for in-person sessions, the system will default to displaying the Learning Hub as the location (Builing), provide a google maps link to that location (link), and will not provide a room number (room). When checked, however, admins will be required to input the Building name, with the option of providing a location link and/or a room number for that session.

Building (Required): Will display in large text indicating the session location. This will be an at-a-glance indicator to the student where the location is. If possible, use the campus name of the building, or something the student is likely to reccognize.

Link (Optional): will provide the student with additional resources should they not know what/where the building is based on the provided name. This field is optional, but could be very useful by increasing the accessability and overall user experience.

Room (Optional): Can be used as auxillary information should the room be known when the session is created. This should be Carefully inputted as the student will see a paragraph that reads 'Meet <session host> in person in the <building name> in room <room name>'.

Calendar Sessions 📅

Calendar sessions are one-time events that occur on a specified date and disappear after that date.

Basic Information:

Subject: This input groups sessions with the same subject. It also groups these sessions together via the subject filter on the user's end.

Date: The specified date this session is held.

Duration: The duration of the session.

Mode: Specify whether the session is held in-person or remotely via Zoom.

Host:

The host is displayed to the user to humanize our services and, ideally, to put a face to the session. The host can either be entered as a simple name, or the staff's profile can be created via the staff editor.

Additional Options

Keywords: Although optional, these keywords are important for providing users with a quick overview of topics and content covered. Additionally, they are searchable through the system's search engine. For example, if a user searches for 'Balancing Equations', a keyword included in this input, the session will appear in the search results for users to find easily.

Additional Info: Although optional, this section can be used to engage students. The heading (required when the checkbox is selected) can be used to creatively describe the benefits students can gain from attending the session, while the text provides further context about the session.

Hyperlink: Whether a session is remote or in-person, a hyperlink can be attached to the session for features like registration or connecting to a Zoom meeting room. The Text input is used for the text displayed to the user, while the URL is embedded underneath. Note: The URL requires a full URL (including https://).

Location

The Location feature allows admins to add a custom location to in-person sessions (the feature will disable automatically if the sessions is set to zoom). When left unchecked for in-person sessions, the system will default to displaying the Learning Hub as the location (Builing), provide a google maps link to that location (link), and will not provide a room number (room). When checked, however, admins will be required to input the Building name, with the option of providing a location link and/or a room number for that session.

Building (Required): Will display in large text indicating the session location. This will be an at-a-glance indicator to the student where the location is. If possible, use the campus name of the building, or something the student is likely to reccognize.

Link (Optional): will provide the student with additional resources should they not know what/where the building is based on the provided name. This field is optional, but could be very useful by increasing the accessability and overall user experience.

Room (Optional): Can be used as auxillary information should the room be known when the session is created. This should be Carefully inputted as the student will see a paragraph that reads 'Meet <session host> in person in the <building name> in room <room name>'.

Getting Started

Choose Your Service Type: First, decide if you're setting up a calendar (for specific dates) or schedule (for a range of dates) service.

Name Your Service: Pick a simple, descriptive name for your service, like "Peer Tutoring" or "Study Skills Workshops."

Create Your URL: Follow the steps in the navigation section to create a unique link for your service.

Adding Sessions

Calendar Sessions

What's Important: Each session needs a date, which tells everyone when it's happening and tells the system when to show or hide it.

Visibility: Sessions set for future dates are automatically shown. They'll hide after the session's end, calculated by adding the session's duration to its end date.

Scheduled Sessions

Defining Dates: Start and end dates are key. The system shows the session only between these dates.

Semesters: You can set a default start and end date by defining the current semester. Check the Semesters section for more.

Understanding Session Statuses

LIVE

WAITING

DISABLED

TEMP LIVE (Scheduled Sessions Only)

UPDATING (No Longer Used)

Editing Sessions

Editing sessions allows you to modify any piece of that session's data. The editor will populate the session as it currently exists in the inputs of the editor. After pressing the submit button at the bottom, any changes you make will be reflected on the user end. Changing the subject, courses, or start time will alter where the session appears for the user.

For Example: changing the subject will reorganize that session under its new subject, changing the courses will add that session to its new course, or changing the start time will reorganize that session into its correct place (sorted by start time) relative to other sessions in that course.

Cancellations 😡

Cancellations inform users that a session has been cancelled, and they should not expect it to occur during that session's time block.

For Scheduled Sessions: this feature requires an Initialize Date (when the session should start showing as a cancelled session), and a Revert Date (when the session should revert back to being displayed normally).

This should allow the admin to cancel a session starting and ending on one day. However, this feature is currently in the process of being fixed and does not work properly as of release 1.1.01. Admins must enter the day before, and the day after the designated cancellation date.

Temporary Edits 😭

Only supported for Scheduled Sessions

Temporary edits allow admins to make temporary changes to a session that will revert back to normal after the specified date. The system monitors which fields are edited in the temporary editor and uses this information to notify users about the specific changes to that session. For instance, if the start time changes, the message will say 'The session temporarily starts at NEW_START_TIME.'

Interactive Download Link:

This link generates a page that displays the document name and description, allowing users to download the document by clicking a button. Every download is tracked for analytics purposes.

https://ucdenver.xyz/learning-resources-center/document/document-id

Direct Download Link with Analytics:

This link generates a page that initiates the document download automatically, without the user needing to click a button. Every download is tracked for analytics purposes.

The only difference between this link and the one above is a query at the end that instructs the system to bypass the interaction and trigger the download automatically.

https://ucdenver.xyz/learning-resources-center/document/document-id?bypass=true

Direct Download Link:

Use this link only in special cases, such as embedding a document preview into a page. Unlike the other two links, this one does not track any analytics, so use it sparingly.

This link is different as it completely bypasses our system and provides a download directly from our database (Firebase).

This link is clearly different, as it completely bypasses our system and provides a download directly from our database (Firebase).

https://firebasestorage.googleapis.com/v0/b/fir-schedules.appspot.com/o/documents%2F8fb629dd-3d00-4728-8263-0d7eb0eeb6e2?alt=media&token=66e4e9f9-1a2a-464d-bf7b-4eedd1d0eaf8

Member Accounts 🐣

Member accounts have the fewest permissions and are restricted to document uploads. Within the document system, members can only manage documents they have uploaded, which means they cannot delete documents uploaded by other members.

Editor Accounts 🐥

Editors have more permissions than member accounts. They can edit schedules, publish site-wide banners, and upload staff profiles. Like member accounts, they also have access to the document uploader.

Admin Accounts 🐓

Admin accounts have access to the entire admin interface, including the Authentication Management system. Here, admins can manage all accounts in the system, remove accounts, and grant permissions to users. Admin accounts should be used with great care to avoid harming the integrity of the system.

By providing different levels of access, the authentication system helps ensure that users can only perform tasks that are appropriate to their role. Admins can use the Authentication Management system to manage all accounts and ensure that everyone has the appropriate level of access.

Super-Admin Accounts 🐔

Super-Admin accounts are intended for developer features only and should be restricted to developers. They provide access to features that could be harmful to the system if not used carefully, such as end-to-end testing.

Authentication Access

The Authentication Access toggle switch enables or disables new account registration. By default, this feature is disabled to prevent unauthorized access. When enabled, a countdown timer starts automatically for five minutes before disabling the feature again. The admin can also disable the timer by clicking on a button below the switch. Note: The admin must disable this feature when it is no longer needed to prevent unauthorized access.

New Users

After new users register, their account type is set to null by default, which means they have no permissions. Admins can assign an account type by navigating to the 'Users without permissions' section within the Authentication Management tab. Here, admins can assign a user an account type from a dropdown menu. Once assigned, the user will disappear from this list and appear under 'Manage Current Users'.

Manage Current Users

The 'Manage Current Users' section displays all current users and their account types. Admins can click on the settings cog icon next to each user to access settings such as changing their account type or removing their account from the system.

Global vs. Local Banners

Should a banner be required to show on a specific service (as opposed to shown on all services), it can be scoped to a specific service. I.E. the Peer-Tutoring service page.
Otherwise, it's visibility can be set to Global, which whill be shown on all embedded service pages. I.E. Peer-Tutoring, SSW, and SL service pages

Banner Count Limit

To prevent the embedded UI from becoming cluttered, the maximum number of banners which can be displayed at any one time is three. This allows admins to display, for example, a global banner for all services, along with a local banner for a single service, should that ever be required. However, banners may not show up if a service attempts to display more than 3 banners, meaning an important banner, such as the disabled banner may be unintentionally omitted.

Messaging

Admins can enter a title and message for the banner and indicate either a specific duration for the banner to remain visible at the top of the window when a user enters or disable the duration to require the user to manually close it.

Banner Type

Admins can set the tone for the banner by selecting one of four different banner types:

FURTHER: Disabled Banner Type

The disabled banner type is utilized to notify users that sessions are effectivly paused during the duration of the disabled banner.

In addition to the default Warning banner, this effects users in the following ways:

Initial Modal Notification

A notification modal pops up and notifys users of the content of the banner, with an additional message which informs users of the effective dates (the banner's start and end dates).

Session Modal Message

Once the user has dismissed the initial notification modal, should they click into a session's details, they will encounter another message on the session's detail modal which notifys them that the session is paused until the banner's end date.

Effective Messaging

Use this guide to create effective messaging via this disabled banner type.

Banner Heading

This should describe the reason for the pause. I.E. Spring Break

Banner Content

This should explain effect of the pause. I.E. All sessions are paused due to Spring Break!

Result

Using the above examples, the messaging in the initial notification modal, for example, will read:

Messaging

Admins can enter a title and message for the banner and indicate either a specific duration for the banner to remain visible at the top of the window when a user enters or disable the duration to require the user to manually close it.

Banner Type

Admins can set the tone for the banner by selecting one of four different banner types:

Staff Member's Basic Information

First and last name are required, although only the first name is shown to users viewing sessions. The last name may be displayed on the About Us page. The email is not included in session information; it is only used to attach staff profiles to the staff member's authenticated account.

Contribution and Background

This section requests the staff member's position(s). If the member holds multiple positions, all can be entered into this input, separated by commas. The member's biography is also required to be shown to users viewing the session information.

Profile Picture

This image, while not required, is displayed to users in session information.

Overview of Embed Routes

Embed routes in the API serve as conduits for embedding highly interactive views, reminiscent of the user experience on the previous .xyz system, into SiteFinity pages. These routes leverage HTMX and AlpineJS to create dynamic, responsive content.

URL Structure Explained

The URL for embed routes follows a specific pattern, crucial for fetching the correct data and displaying it within the embedded views. Here's a breakdown:

/v2/embed/sessions/:type/:service?page=<currentPageNumber>&limit=<itemsPerPage>

v2: Indicates the API version, ensuring you're accessing the latest features and functionalities.

embed: Denotes the route's purpose for embedding content.

sessions: Categorizes this route under session-related content.

:type: Placeholder for the session type, such as calendars or schedules, to be replaced without the colon.

The type must be pluralized in order to correctly fetch the session.

/v2/embed/sessions/calendar/:service?page=<currentPageNumber>&limit=<itemsPerPage>

/v2/embed/sessions/calendars/:service?page=<currentPageNumber>&limit=<itemsPerPage>

:service: Specifies the particular service, like peer-tutoring, derived from the admin console's URL structure.

?page=<currentPageNumber>: Optional query parameter for pagination, with a default start at page 1.

&limit=<itemsPerPage>: Defines the number of items per page, with a default setting of 3 for optimal viewing.

A correctly formatted url:

https://lrc-api.wm.r.appspot.com/v2/embed/sessions/schedules/peer-tutoring?page=1&limit=3

Data Flow and Processing

Entry Point: The primary route, getSessions, initiates the data fetching process based on the session type and service.

Data Fetching and Validation: Data is retrieved from Firebase, validated, and then undergoes extensive manipulation to fit the desired format for display.

Calendar Sessions: Validated based on their future dates, ensuring only upcoming or ongoing sessions are included.

Scheduled Sessions: Validated against their start and end dates to include only currently relevant sessions.

Data Manipulation and Shaping

Calendar Sessions: Grouped by subject to consolidate similar sessions into a single view, facilitating a clearer, more organized display.

Scheduled Sessions: Undergo a more detailed organization, grouping sessions by subject and then by course, ensuring a coherent display of sessions covering similar content.

Data Rendering and Interaction

Utilizes the Pug templating engine and AlpineJS to convert the processed data into interactive HTML content suitable for iFrame embedding.

Employs HTMX for dynamic content updates, such as pagination and modal displays, without needing a full page refresh.

Advanced Features

Modals: Detailed session information is accessible through modals, dynamically loaded using HTMX to enhance user engagement without leaving the page.

Full-Text Search: Incorporates a live search feature, debounced to optimize performance, allowing users to filter sessions based on keywords.

In-Memory Caching and Cache Invalidation

To enhance performance, the system employs in-memory caching for session data, with mechanisms in place for cache invalidation to ensure data freshness.

Cron Jobs: Scheduled tasks automatically clear the cache every hour as a fail-safe.

Cache Invalidation Routes: Specific routes in the admin console trigger cache invalidation upon session updates, maintaining data accuracy.

Document Storage Transition to AWS S3

Moving from Firebase to AWS S3 for document storage offers a more cost-effective solution without sacrificing quality or accessibility.

Storing and Deleting Documents: Managed through the Document Uploader in the admin console, with seamless integration into the LRC system.

Accessing Documents: Utilizes temporary access links (presigned URLs) to securely provide document access, maintaining public access restrictions while ensuring availability.

The Role of the LRC Server

The LRC Server is the foundation of our digital infrastructure, supporting applications such as DigiSign and our real-time session display system. It's responsible for a range of critical functions:

Authentication & Security: Manages secure access to our systems, ensuring only authorized devices and users can interact with our data.

Data Management: Handles the storage and retrieval of documents, along with automatic emailing for efficient communication.

Application Support: Powers the DigiSign application and integrates with SiteFinity to display live session information.

DigiPi

The DigiPi device is a kiosk computer which fully automates the LRC's digital signage process.

Automatic Power Schedule

• The device will power itself on every weekday morning at 7:30am
• The device will power itself off every weekday evening at 5:30pm
• On Friday evenings around 4:45pm, the device will initiate a system backup (to the onboard USB drive), check for updates and upgrade itself, then schedule its wakeup for the following Monday morning at 7:30am

Should any of these schedules fail, a manual power on or off may be required. The schedules are system level cron jobs which should pick back up once restarted.

DignSign vs DigiPi

DigiSign referes to the name of the web application. The DigiSign site can be accessed from any device, however, only explicitly authenticated devices can proceede past the auth screen. See the next section for steps on authentication.

DigiPi refers to the computer specifically configured to run the LRC Front Desk version of DigiSign. This Raspberry Pi5 is specfically configured to automate the process of running the DigiSign application.

The DigiPi runs a lightweight version of the RaspberryPiOS Desktop version and is equipped with various scripts and jobs aimed to automate the entire digital signage solution. The machine is configured to auto-login, wake the connected TV via the HDMI-CEC protocol, and autostart the DigiSign app via a chromium brokwser configured in Kiosk mode.
DigiPi Scripts

Best Practices

• Power: The device has a power button located on the side opposite of the USB (type a) ports and the ethernet port. Next to the button is a small light indicating the power state. Solid red signifies the device is off.
• Power Management: when attempting to turn the device on or off, please first attempt to do so via the onboard power-button. Managing the power via the power source (the USB-C cable plugged into the long side with the mini-hdmi ports) should always be the last resort.
• First: attempt a short press of the button. While off, a short press should power on the device. While on, a short press should initiate a safe-shutdown.
• Second: attempt a long press of the button. While off, a long press likely will not act differently than a short press. While on, a long press will initiate a forced shutdown
• Finally: unplug the white USB-C cable to force the device to shutdown. Re-inserting the cable will initiate a power on.
• the 2nd page will run for 10 seconds,
• the 3rd page will run for 8 seconds,
• and the 4th page an on will run for only 6 seconds.

DigiSign

DigiSign brings vital LRC information to life, displayed on screens across the center. It provides real-time updates on sessions, announcements, and center hours, all fed by the LRC server.

Device Setup and Authentication

Each DigiSign device is assigned a unique ID upon installation. For security, devices start as unverified. Admins must approve each device in the admin console, linking the device ID to our system and enabling data display.

Displaying Session Information

Admins can select which LRC services to feature on DigiSign. This flexibility allows for tailored content that best serves our community's needs.

• Sorting: Sessions are uniquely sorted based on the amount of time from their start to now. This means that the first sessions that are seen are either (1) about to start, or (2) have just started.
• Pagination: Sessions are paginated. At most, 6 sessions are shown on the screen at one time. Subsuquent sessions are displayed on different pages denoted by the progress bars show overtop of the sessions.
• Sorting and Pagination: Due to the way sessions are sorted (placing the most important session on the first page), sessions either about to start, or which have just started appear on the first page, and session starting the furthest from now, or which have strted a while from now appear on the last page.
• Page Durations: Given that the most important sessions are shown on the first page, and the least important sessions are shown on the last page, the page durations diminish.
• This is a fancy way of saying the the first page will always run for 15 seconds,
• the 2nd page will run for 10 seconds,
• the 3rd page will run for 8 seconds,
• and the 4th page an on will run for only 6 seconds.

Service Configuration:

Adding Services: Services are added through the DigiSign tab in the admin console, requiring the service's URL path for accurate setup.

Session Details: Displayed sessions include comprehensive information like the service name, session modality, host details, and a duration bar indicating the session's progress.

Center Hours Display

DigiSign also showcases the operating hours for various LRC services, enhancing visitor navigation and planning.

Center Name: Identifies the specific service or center.

Hours Type: Can be set to 'Consistent' for uniform weekly hours or 'Dynamic' for varying daily hours.

Weekly Hours: Admins input opening and closing times, with 'Dynamic' hours allowing for day-specific schedules.

Managing Announcements

DigiSign features two types of announcements: minimized and maximized, each serving different purposes and offering customizable content.

Minimized Announcements

These compact announcements provide quick, essential updates. They're designed not to overwhelm the main display, fitting neatly between other informational elements.

Content Fields: Include a name (for admin reference), subheads, a main heading, detailed text, and an optional image URL for visual interest.

Duration and Expiration: Control how long the announcement stays visible and when it should be removed from the rotation.

Maximized Announcements

Periodically, full-screen announcements take center stage, offering in-depth information or eye-catching visuals.

NOTE: Announcements are broken up into smaller sets of announcements to prevent long periods of time spent away from the main view. Announcements run 3 at a time, and once all announcements have run, will start back at the first.

Timing: Admins set intervals for these announcements, ensuring regular visibility throughout the day.

Content Types: Choose between 'Pre-Designed' for ready-made images or 'Not Designed' for custom text over a background image, which can include headings, subheadings, and paragraphs for a more detailed message.

Troubleshooting

Known issues

• Emergency Mode: The previous shutdown process likely failed to exit correctly, or power was cut to the device preventing the device from safely powering down.
  • Solution: hold the power button for 5-8 seconds until the device shuts down. Once off, short press the power button to turn the device back on. This should allow the device to power back on normally.
• Blank white screen after boot: This screen means the chrome browser started, but the GPU process failed to initiate.
  • Solution: The device automatically refreshes on the second minute of every hour, and this should remedy the issue. If not, attempt a restart via a short-press of the power button, then once off, another short press to power the device back on.

General troubleshooting for unknown issues

• Reboot: There is a light on the short side of the device which indicates its power state. Solid red means off.
  • Short press the power button on the short side of the device. A short press will initiate a safe shutdown
  • If a short press does not work, long press the button for 5-8 seconds to force a shutdown.
  • If the button does not shutdown the device, pull its power (the white USB-C cable) and wait for 30 seconds before plugging it back in. It should boot as soon as its power is restored. If not, press the power button.
• Network issue: If the browser cannot connect to the web, the DigiSign app will never show.
  • Attempt to unplug the ethernet cable and reinsert it
  • Try the cable with another device to verify it works. Try different cables if the issue persists with another device. Also verify that the network is not down.
• TV / Display issue: If the TV fails to display the device's picture
  • Ensure the TV is on the correct HDMI input the device is plugged into. Also ensure the device is on.
  • The device uses an HDMI to MINI-HDMI. You may need to purchase another cable if the TV continues to fail to display.
  • Note: The device uses the HDMI-CEC protocol to automatically power its host TV on and off via its automatic scripts.

If the DigiSign application seems to be showing information which is out of date, the issue is likely that the cache on the server failed to invalidate for whatever reason.

Clearing the Cache

• Navigate to the Admin Console > DigiSign > Server Cache
• If this is your first time Clearing the Cache, please read the information provided in the Server Cache section of the Admin Console before clearing the cache to better understand if it could solve the issue you're experiencing.
• Use the Clear Server Cache button to clear the cache.
• Using the button will return one of three messages:
  • Success: the message will notify you that the server cache has been successfully cleared. the 200 means success, and the message will show the numer of items cleared from the cache.
  • Cache already empty: The server periodically clears the cache itself to midigate this issue, so if you recieve a 200: (Accepted) message, it means, effectivly, nothing has changed on the server.
  • Error: Something went wrong on the server and it was unable to clear the cache. This likely points to there being an issue on the server and maintenance may be required.

Re-Authenticating the Device

This is a last resort. If none of the above methods have resolved the issue, my final suggestion is to re-authenticate the device.

• Navigate to the Admin Console > Devices
• Find the device running the DigiSign application.
• Click on the three vertical dots in the upper right corner
• Click Unverify Device, and refresh the page
• Refresh the webpage on the device. This should now present you with the un-authenticated screen.
• Using the admin console, verify that device the same way you unverified it.
• Refresh the webpage on the device. The unauthenticated screen should not show, and the device should boot into the DigiSign app correctly.

Should the issue still not be resolved

Please use the contact inforamtion provided below in the Contact Me section to reach out to the developer for maintenance.