In the Scholarship of Teaching and Learning (SoTL), faculty study and improve their teaching and the learning in their classrooms and courses, and share their findings to advance the practice of teaching.

SoTL may focus on any pedagogical approach – guided inquiry, lecture, problem-based learning, project-based learning, etc. SoTL may use a variety of qualitative and quantitative research methods – case studies, content analysis, focus groups, interviews, surveys & questionnaires, etc.

Many faculty are not familiar with the literature and research methods used in education, and (for various reasons) not all faculty or SoTL studies reach the level of rigor required for formal publication. Thus, for faculty new to SoTL, it would be helpful to receive guidance and templates they could adopt or adapt with less effort than developing such materials from scratch.

This session seeks to design and prototype a SoTL Design Wizard that would guide users through a series of questions and decisions, leading to materials that could be adopted or adapted, including sample materials for an Institutional Review Board (IRB). For example, to study the effects of a single classroom activity, the wizard might lead to some simple surveys with basic demographic information, a few Likert-scale questions, and an open ended response. For a longer term study, the wizard might lead to longer, more details surveys, and outlines for individual or group interviews.

Thus, the SoTL Design Wizard offers several benefits:

• Faculty will find it easier to start with SoTL.
• Initial SoTL studies will use better methods for design, data collection, and analysis.
• Meta-analyses could be performed if the same materials and templates are used for multiple studies.

Free & Open Source Software (FOSS) is distributed without charge and with the underlying source code, so that anyone can fix defects, update documentation, add enhancements, or otherwise modify the software and share the changes with others. Thus FOSS is free as in free speech, not free beer. Although many people associate FOSS with software development and Internet infrastructure, there are FOSS projects for any area of interest, including audio editing (Audacity), image processing (GIMP), library subject guides (SubjectsPlus), mind mapping (FreeMind), music notation (MuseScore), and project management (OpenWorkbench). Furthermore, a wiki or content management system can be customized to support teaching and scholarship (or other activities) across a wide variety of disciplines.

The communities that develop and support FOSS can be represented as layered onions or pyramids (Jensen & Scacchi, 2007). Typically, the largest, outermost group is people who use or monitor the project, but do not contribute to it. Within this group are progressively more active but smaller groups, such as users who share ideas and defect reports, developers who work on specific sub-projects or supporting modules, leaders of sub-projects, and finally the overall project leaders and core developers. Thus, FOSS communities are communities of practice that leverage legitimate peripheral participation. Although many FOSS participants have technical backgrounds and skills, most FOSS projects also involve non-programming work – graphic design, testing, documentation – and the projects benefit from participation by a more diverse community of people.

Participating in FOSS helps students gain experience with professional reading and writing, diverse and distributed teams, and managing and prioritizing work in extended projects. FOSS can also help students shift from being reactive (complete assigned work) to more proactive (decide what is most important and take ownership). Thus, faculty at many institutions are working to involve students in FOSS (e.g. SoftHum; Teaching Open Source). At one recent NSF-sponsored workshop, a group of faculty, students, and other FOSS participants drafted a list of ~100 activities that could contribute to FOSS projects and provide useful experiences for students and faculty (50 Ways to be a FOSSer).

I envision this session as seeking to:

1. Review and expand the list of FOSS activities.
2. Identify activities of particular relevance and value to teachers, students, and other humanists.
3. Develop descriptions, instructions, and supporting materials to make it easier to adapt and adopt these activities in a variety of courses and contexts.

References

• Jensen, C., and Scacchi, W. 2007. Role migration and advancement processes in OSSD projects: A comparative case study. In Proc of the 29th Int’l Conf on Software Engineering, 364-374. IEEE Computer Society.
• 50 Ways to be a FOSSer (activity list).
  xcitegroup.org/softhum/doku.php?id=f:50ways
• SoftHum: Software for Humanity.
  xcitegroup.org/softhum/doku.ph
• Teaching Open Source.
  http:// teachingopensource.org

There is a necessary tension between University IT departments and the curious digital humanist, computer scientist, and librarian.  IT departments pride themselves on building and supporting things that don’t ever break and that are always secure — we love them for that!   So, getting approval for a new, untested, open source project can be dicey.  On the right occasion, it’s really fun AND necessary to play fast and loose and forget about all that other stuff and just build something.  Sometimes, you just gotta have root access, right?

There is a GREAT solution to this quandary.  For the price of a textbook, you can sudo, script, and savor the best that the open source community has to offer.  Or build something without concern for impacts on your campus IT environment.

Linode.com is a VPS (virtual private server) hosting company that provides any Linux distribution your heart desires and they make it ridiculously easy to set up.  It also boasts great tech support, and a pretty impressive community of other hobbyists and hackers who know a lot and are happy to help you when you get stuck.

Lastly, and most importantly for our purposes, they offer what are called ‘StackScripts’ — a customized set of instructions that permits the deployment of a specialized ‘stack’ of servers and applications — such as Linux/Apache/MySQL/PHP (LAMP) + Omeka.  Or Linux + the language R + text mining packages.  Or Linux + Python + geospatial stuff like geonode (geonode.github.com).  Or Python + Django haystack + Solr + jetty …. I’m sure you get the idea.  StackScripts can help you bring up the thing you WANT to have, without your needing to know all that stuff you DON’T WANT to mess with.  Like server administration and configuration.

So here’s the really cool part.  A StackScript is basically a set of commands issued in a shell, all strung together.  You can even build user defined fields into a StackScript (stuff like, “Enter the name of your project here: ____”.  Someone with the necessary know-how can write and provide StackScripts to other folks to use on their own linodes.  We (at THATCamp Lehigh Valley) can compose a StackScript to bring up, say, Omeka.  Once done, others can use it to reduce the time and effort required to bring up their Omeka to as little as an hour.  No kidding!

And here is the other really cool part.  Using github [http://github.com] we can share, adapt, and update StackScripts for all sorts of projects.

In this StackScripted world I imagine, Campus IT is happy because they don’t need to worry about anyone breaking anything.  You’re happy because, if need be, you CAN break stuff.  More importantly, you can spend your time on your awesome new project instead of struggling on Stack Overflow or reading old Linux manuals!  If your project matures, moving it to campus hardware is so easy, you’ll weep with joy.

In summary, over only a couple of hours, I’d like to MAKE something where we:

* talk about Ubuntu as a Linux distro kind to the unfamiliar (5 minutes)

* bring up a new shiny linode (5 minutes)

* back up and fork our shiny linode just in case we break it (10 minutes)

* mess around a little in the Bash shell, particularly with the .bash_history file that is so useful when writing bash scripts (10 minutes)

* write a StackScript that utilizes User Defined Fields for interactive customization during setup.  Perhaps even demonstrate how you can reference other StackScripts in your StackScript, such that you can string them together (60 minutes)

* play with our new creation!  Maybe do it all again!

Any takers?