Administrative Support

This section provides a collection of resources related to many non-technical issues that CS Education researchers and systems builders have to deal with.

Data Access Policies

Researchers are often in need of student-generated data. This might include data generated in the researchers' own courses, in other courses at their university, and in courses at other universities. This might include score data from course assignments, grades for the course, or tracking data of some sort related to student activity within educational software.

While some aspects of data acess and sharing are regulated by IRB protocols, in some instances universities have global policies regarding the regulation of access to such data. This section tries to provide some examples of related policy documents and data access forms.

• University of Toronto
  • Website and Informational slide deck describing the University of Toronto data access review policy
  • Data access request form

Hosting Information

Help for tool developers who want to make their tools available outside their University, but who need options on how to host the software.

Examples of IRB Protocols

Readers should be aware that each university will typically have its own form and process for IRB approval. While the examples here should be helpful for writing similar documents, you will need to get the exact forms necessary from the school that will grant the approval.

Also, be aware that IRB standards change over time, and can be different at different schools. Dates are shown for these documents. Permissions granted by a university as shown in older documents might possibly not be granted by that same institution today.

• CMU IRB Protocol from PI Carl Haynes-Magyar, last updated early 2023.
• CMU IRB Protocol, Consent Form, and Recruitment Document from PI Tongshuang Wu, last updated early 2023.

HECVAT Examples

The Higher Education Community Vendor Assessment Toolkit (HECVAT) is developed and maintained by Educause. It is intended to create a common, comprehensive tool for evaluating a variety of aspects important for instituations when evaluating third-party software tools. Many universities are now requiring developers to provide a HECVAT form in order to be considered for adoption.

There are several flavors of the HECVAT. From the doc:

• Triage: Used to initiate risk/security assessment requests - review to determine assessment requirements
• Full: Robust questionnaire used to assess the most critical data sharing engagements
• Lite: A lightweight questionnaire used to expedite process
• On-Premise: Unique questionnaire used to evaluate on-premise appliances and software

Complete HECVATs for a number tool are available. If you have completed a HECVAT for your software tool, please consider contributing it to SPLICE as an example for others.

VPAT/ACR Examples

The Voluntary Product Accessibility Template (VPAT®) is a standard document developed by the Information Technology Industry Council for software developers to create an Accessibility Conformance Report (ACR) to explain how their tools meet national and international standards for accessibility. Many state and national governments require a completed Accessibility Conformance Report as part of the evaluation for adopting third-party tools.

Many vendors make the their VPAT/ACR publically available (for example: Canvas | Moodle | Github's Website | MediaWiki | Chrome for Windows). If you have completed a VPAT for your software tool, please consider contributing it as an example for others.

Project Scale-up and Lifecycle Examples

This section contains a "system stories". Most CS educational software never gets beyond the proof-of-concept phase. Sometimes CS educational software gets prototyped and deployed for a couple years in the developer's own classes. A small number of software projects get "institutionalized" for long-term adoption locally, and/or distributed and used more widely, and for a long time.

Getting a project adopted widely, and put on a long-term sustainable basis is difficult. This section is meant to give presentations about CS Educational software that has (more or less) successfully scaled up. The goal of presenting "system stories" is to give developers in earlier stages of the software system lifecycle some ideas of how other groups have successfully or unsuccessfully navigated scaleing up and reaching long-term stabilty.

• OpenDSA eTextbook System (Virginia Tech)

Last updated: