• Guidelines
• Policies
• Why do we have this guidance/policy?

Guidelines

Getting started

• Confirm that the plugin would meet broad campus needs
  • Be prepared to share how this will provide value to a majority of campus website owners
  • Develop a list of groups who have requested the functionality and/or those that would benefit from the plugin
    
    
• Confirm that your team has the capacity to handle support requests regarding the plugin:
  • KnowledgeBase documentation (or suitable alternative)
  • Support tooling for fielding requests
  • Support staff for fielding questions, troubleshooting, training, etc.
  • A feature request model
  • Development staffing for maintenance/upkeep
  • Funding for long-term support of all these areas
    
    
• Gather information about the plugin:
  • Name of plugin
  • Full description of what it does
  • Target audience
  • Why it is important/business need
    
    
• Be available to discuss your plugin idea with the UW Theme team (email to schedule time to meet)

After you've met with the UW Theme team

• Build out the plugin and pilot it with at least 5 users across different teams
  • Gather insights
  • Make improvements based on testing
  • Be prepared to share this data with the UW Theme team
    
    
• Make sure to meet with Office of Strategic Communications designers to ensure that your plugin meets branding standards (this process can be setup when you meet with the UW Theme team)

For plugins that integrate with other campus tools

• Allowing users to integrate their sites with a campus tool can send thousands of requests to your pages. Confirm that sending many requests through to your primary pages is not going to impact the performance of the tool or the display of content on various users’ websites.

Policies

In an effort to ensure that tools developed for use with the UW Theme/WiscWeb are compliant with certain standards for development, we require that you review and adhere to the following policies:

1. We request that you please meet with members of the UW Theme team prior to any development. This allows us to gain a better understanding of your goals and walk you through our desired process.
   
   
2. After development, you must have the plugin evaluated for accessibility (and any found issues remediated) before allowing groups to use it.
   1. You will want to budget some time to allow for the Center for User Experience to complete this evaluation.
   2. If your plugin involves integrating with a vendor tool, you may need to also budget some time to work with the vendor on remediating any accessibility barriers.
      
      
3. Your plugin must be compatible with the latest versions of the UW Theme and WordPress.
   1. Again, budget time in your development cycles to test with new versions and roll out patches to the plugin where needed.
   2. If not compatible with the latest versions of WordPress and the UW Theme, the plugin cannot reside in WiscWeb.
      
      
4. The plugin must follow UW-Madison branding standards. You will have to meet with a Office of Strategic Communications designer to confirm that it is in compliance.
   
   
5. You and your team must be willing to take on full support and responsibility for the plugin. You must also be willing to manage the code in git.doit.wisc.edu (the campus GitLab instance).
   1. We require that you maintain instructional/’how to’ documentation for the plugin that users can be pointed to.
   2. Your team must be willing to field any support or feature requests regarding the plugin.
   3. Your team must have a feature request model in place for groups to request new features and report bugs.
   4. Your group must have staffing to support long term maintenance of the plugin.
      
      
6. You must commit to regularly patching your plugin as issues arise. You must also be willing to undergo code reviews of your plugin by members of the UW Theme team.
   1. Should any issues be found, the UW Theme team will note them and offer suggestions for remediation.
   2. Issues must be remediated before the plugin will be shared widely.
      
      
7. You must get approval from your dean or director to move forward. We require that they have awareness for this plugin project and have signed off on funding for initial development and long term support of your plugin.
   
   
8. Any plugins requested to be integrated within WiscWeb must also comply with: 
   1. WiscWeb - Software and technology integration policy
   2. WiscWeb - Sensitive, restricted, and internal data policy
   3. WiscWeb - WiscWeb embed code policy
   4. Minimum web standards for UW-Madison
   5. UW Madison WordPress theme guidelines

Also, WiscWeb reserves the right to remove a plugin from the service if it is no longer meeting service standards for development/support/etc.

For plugins that integrate with other campus tools: 

1. You must check with the vendor of any tool you are tapping into to ensure they are okay with you redistributing this data.

Why do we have this guidance/policy? 

WiscWeb and the Office of Strategic Communications teams have been working hard over the past several years to broaden awareness for and encourage compliance with the following campus standards: 

• Accessibility
• UW-Madison branding + design
• Web development
• Cybersecurity

Policies like this help ensure that broad-use tools meet and comply with these standards. In the end, this results in UW-Madison websites that are more inclusive, cohesive, intuitive, user-friendly, and secure.