We have a breakout/study/practice room reservation system that we are rebuilding to make it more mobile friendly.

It is for reserving a resource, like a study room, that is needs to be limited in some way.
* Only available during open hours
* We want to discourage hoarding the resource, we don't want people reserving and then not using it
* We don't want people reserving and canceling reservations at the last minute (or same calendar day)
* We want administrative views and overrides for resources and reservations

Our current design uses a set of google calendars as a back end. So that reservations appear on the creators gmail calendar.

* https://www.csom.umn.edu/roomreservations/

It is mobile focused, but scales up pretty well also to the desktop experience.
We also have the start of a very rudementary iOS app developed for the system.

* https://github.umn.edu/Carlson-IT/Reservations

We have a basic kanban board that we started out brainstorming with on trello

* https://trello.com/b/1GsKi9Er/room-reservations-app

This project could take several directions. It could be a Public Insight Network-like site (publicinsightnetwork.org) where students and/or faculty register and identify topics that they are interested in or knowledgeable about. The result would be a way for researchers to find subjects for surveys or for their research. It might also provide a means of connecting the public with experts similar to experts.umn.edu.

Another direction could be a site similar to Amazon Mechanical Turk or elance.com that would connect faculty and staff with students who can fulfil small, one-off jobs; the job could either require a specific skill, or be tedious in nature but require a person to do it. One example might be a faculty member who has $500 allocated in a grant and needs someone with PHP skills to write some code. Students could register with their expertise and build reputation as they successfully complete projects.

Everyone likes open data. Let's create a way for individuals and departments to share their collective data in one structured directory. Examples of similar services include:
http://api.uwaterloo.ca/
https://developer.berkeley.edu/docs

For example, Student Unions and Activities recently launched a subdomain for hosting select data with a RESTful design model using standard formats (JSON, XML) and metadata. The model is useful for building our own applications and may assist other departments with sharing information. A few examples of data we publish internally:
* Currently registered student groups
* Current building hours and service status
* Event calendar data

These types of data could be included. With this model in mind, our vision is to set up a decentralized directory service where individuals or departments could submit a RESTful API URL for others to browse. The service could validate the API format, provide documentation on parameters or special use cases, but leave the actual hosting up to the submitter. The service could be collectively developed on Github and hosted at the University.

In 2012, PTS implemented the NextBus system on the Campus Connector shuttles. This system provides riders with information on route schedules, how far away the next bus is, delays, and other data. Currently the system provides information via text alerts, QR codes, and a web-based map.

However, NextBus also provides an XML API for their tracking services. It provides a wealth of data on the bus system, including near-realtime metrics on heading, latitude, longitude, last update, speed, and even passenger counts. The documentation advises 10 second poll intervals; in reality the positions are often updated every 5 seconds.

There are many applications for this kind of data. It would be interesting to gather metrics on the bus system, for instance, or observe correlations between weather and schedules, or get a better grasp of the volume of travel that occurs on the connectors. Beyond these curiosities, though, there are other ideas, like overlaying bus data on campus maps, or adapting the realtime data to other formats for users. Bring other ideas as well!

API documentation: http://www.nextbus.com/xmlFeedDocs/NextBusXMLFeed.pdf
Example response: http://webservices.nextbus.com/service/publicXMLFeed?command=vehicleLocations&a=umn-twin&t=0

In many ways, the EFS system has been a nightmare for departmental accounting people. Consider the case where a person purchases some kind of UofM service using an EFS string, but makes a typo when entering it. Instead of rejecting the transaction, the EFS system simply creates a new account string, much to the dismay of the poor accountant. In addition, the Chart of Accounts tables in the Data Warehouse or PeopleSoft do not contain information that is often needed, such as: can this account be used for foreign travel; what restrictions on purchasing have been placed on the account by the granting agency; if this is a child award, who is the parent?

We have been developed a shadow COA system for our departmental accountants, and are working to make it available to a number of other departments that have requested it. But it would be nice to have it integrated with the new PeopleSoft Financials and perhaps make this available to any unit at the UofM. The idea would be for this grow into something that is not a shadow system, but more of an augmentaion system.

There are many overlapping efforts in the area of digital asset management, particularly in the area of image collection storage and retrieval. Developing a core set of requirements that span these many efforts would be a big step towards the implementation of a system that meets these needs and will help to shape ongoing efforts (in the University Libraries and the College of Liberal Arts, for example).

Since we have the rare opportunity of many key stakeholders in one room together for a couple of days, let’s put together a core set of requirements to address common needs such as:
* Embeddable Assets for consistent branding (as in the CMS)
* Access and authorization
* (General) metadata requirements
* Required Integration points (and related APIs)
* Collection and/or grouping model
* User Stories
* Technical Workflows
* Transcoding and transformation needs
* Workflows for archiving and preservation

The artifacts of this sprint will be a series of diagrams representing data models, asset workflows (sequence diagrams), user stories, plain language requirements, benchmark analysis, installed software demos and whatever else seems relevant to the project.

Current Site is Upgrade.umn.edu . All the "projects" have Google sites. It is kludgy and not very effective to use Blogger as our home page. We thought we could get away with this sort of WYSIWYG-only web presence, but we are beginning to see this as a significant barrier to doing a good job. We will have lots to communicate over the next 18 months.

Top things we want out of our web site
1) Something we can maintain relatively simply: without back-end skills. Something that can grow.
2) Flexibility to be able to communicate our key messages & basic IA effectively while also delivering current news.
3) Integrates Google Cal & doc feeds. Can display a Blog feed and sort with our blog tagging. Feedback form(s)
4) Reliable and speedy
5) Looks more professional than the Blogger & Google Sites

Platform is negotiable (Drupal? An old fashioned html site we manage in Dreamweaver?) Just needs to meet these basic needs. This seems like a pretty manageable scope for this codefest...

Scheduling student workers is a kind of a unique task that doesn't fit into the flow of a lot of scheduling software. Often times student worker schedules are based on availability, rather than fixed shifts. Unfortunately, a lot of the scheduling software out there is not ideal for this kind of situation.

This is why I started creating OpenSkedge (https://github.com/maxfierke/OpenSkedge, mirrored at https://github.umn.edu/fierk007/OpenSkedge). It's designed to fill this gap by providing a FOSS solution for departments looking for an easy way to schedule student workers based on their availability in set scheduling periods.

I've been working on this based on input from a supervisor within CSOM, but I'd love to expand OpenSkedge to accommodate other types of scheduling scenarios here at the U.