Improving the Internal Quality of Software Through Reputation-Based Gamification

Total Page:16

File Type:pdf, Size:1020Kb

Improving the Internal Quality of Software Through Reputation-Based Gamification Improving the Internal Quality of Software through Reputation-based Gamification Von der Fakultat¨ fur¨ Mathematik, Informatik und Naturwissenschaften der RWTH Aachen University zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften genehmigte Dissertation vorgelegt von Diplom-Informatiker Christian Reinhard Prause aus Siegburg Berichter: Prof. Dr. Matthias Jarke Prof. Dr. Volker Wulf Tag der mundlichen¨ Prufung:¨ 21.3.2013 Diese Dissertation ist auf den Internetseiten der Hochschulbibliothek online verfugbar.¨ Abstract Zusammenfassung Developers are notorious for their dislike of writing in- Entwickler sind beruchtigt¨ fur¨ ihre Abneigung gegen ternal documentation. It has few value to them because das Schreiben von Dokumentation. Der personliche¨ its benefits are too far away in the future and distributed Nutzen hiervon liegt zu weit in der Zukunft und wird on the whole team, while the efforts of documenting mit anderen geteilt, wahrend¨ der Schreibaufwand auf are burdened on the individual himself. The resulting dem Einzelnen lastet. Das Ergebnis sind Phanomene¨ phenomena have names like free riding or tragedy of the wie Trittbrettfahren oder die Tragik der Allmende. commons. Software ist eine Ansammlung kodierten Wissens Software is an accumulation of encoded knowledge und ein Auffangbecken fur¨ Komplexitat.¨ Ihr Entste- and a collecting pond for complexity. Its development hungsprozess gleicht eher Forschung und Evolution als is more akin to research and evolution than to an agreed einem festen Weg mit klarem Ziel. Die gemeinsame Ar- path with an established goal. Multiple developers are beit mehrerer Entwickler wird von unterschiedlichsten engaged in an intricate joint endeavor, building on dis- Interessenten begleitet, und besteht aus Entdeckung, covery, invention and decision making, flanked by sev- Erfindung und Entscheidung. Um die Software an sich eral stakeholders. A developer must constantly learn laufend andernde¨ Anforderungen anpassen zu konnen,¨ and relearn the software to be able to adapt it to ever- muss ein Entwickler ihr Inneres standig¨ (wieder) er- changing requirements. Instead of being “soft” and easy lernen. Anstatt leicht anpassbar zu sein, ist Software to adapt, software is difficult to modify. If knowledge is schwer zu andern;¨ ihre Entwicklung ist daher teuer. not preserved in source code, wiki articles, and other doc- Wird das Wissen nicht in Quellcode, Wiki-Artikeln umentation, then software development becomes costly oder anderer Dokumentation wohl bewahrt, droht ein even up to the point of a total economic loss. wirtschaftlicher Totalschaden. This research presents CollabReview, which ad- Diese Arbeit prasentiert¨ CollabReview, das anstatt dresses the developers’ motivation to invest in internal strenge Regeln vorzugeben, die Motivation der Entwick- quality without strict regulation. It re-balances intrap- ler anspricht, in interne Qualitat¨ zu investieren. Es bee- ersonal cost-benefit considerations in favor of internal influsst intrapersonelle Kosten-Nutzen-Uberlegungen¨ quality using gamification. Personal reputation scores zu Gunsten interner Qualitat¨ mittels Spielelementen. for developers are calculated from ownership-based Dazu werden personliche¨ Reputationspunkte fur¨ En- responsibility and quality ratings for collaboratively twickler aus Qualitats-¨ und Zustandigkeitsinformationen¨ written software process artifacts. The scores are tied to von gemeinschaftlich entwickelten Software-Artefakten social games and rewards to make scores worthwhile to berechnet. Um die Punkte erstrebenswert zu machen, achieve. The implemented prototype of the CollabRe- sind sie an soziale Spiele und Belohnungen gekoppelt. view concept mines responsibility information from Der CollabReview Prototyp gewinnt seine Informatio- revision histories, and combines it with manual and nen aus Entwicklungshistorien, und kombiniert sie mit automated assessments of artifact quality. manuell und automatisch erzeugten Qualitatsreviews.¨ The CollabReview concept and prototype were eval- Das Konzept und der Prototyp von CollabReview wur- uated in several studies including an analytical con- den in Expertenanalysen, technischen Validierungen und cept evaluation, technical validations and field exper- Feldversuchen evaluiert. Letztere brachten den Prototyp iments. The latter deployed the prototype in knowledge in agilen, quelloffenen, verteilten Konsortial- und Wis- management, agile, open source or distributed consor- sensverwaltungsprojekten zum Einsatz. Die Beitrage¨ tium projects. It successfully amplified contributions to zur Wissensverwaltung konnten so erfolgreich gesteigert knowledge management wikis, and improved the read- und die Lesbarkeit von Quellcode verbessert werden. ability of source code. The results show that CollabRe- Die Ergebnisse zeigen, dass CollabReview zu besserer view leads to better internal documentation and quality interner Dokumentation und Qualitat¨ der Software fuhrt.¨ of the whole software. At the same time, it leaves devel- Gleichzeitig lasst¨ es Entwicklern die Freiheit, Qualitat¨ opers their freedom to neglect quality when necessary, wenn notig¨ zu vernachlassigen,¨ belastet sie nicht mit does not burden them with unnecessary additional ef- unnotigem¨ Mehraufwand, und hat folglich besonderen forts, and hence has particular value in self-organizing Wert in selbst-organisierenden Projekten mit schwacher project environments where code ownership is weak. Quellcode-Eigentumerschaft.¨ iii iv Contents 1 Introduction 11 2 Problem Scope: On the Quality of Software Process Artifacts 13 2.1 Introduction to Software Process Artifacts . 13 2.1.1 Software as collection of knowledge . 13 2.1.2 Software development as costly knowledge creation process . 15 2.1.3 Software process artifacts document created knowledge . 17 2.1.4 Source code and other documentation, and how to best make it . 20 2.1.5 Summary of software development as knowledge creation . 21 2.2 The Case for Internal Quality . 22 2.2.1 Source code as the project’s most valuable output . 22 2.2.2 Protecting the value in source code, and the cost of maintenance . 22 2.2.3 Why and where internal quality matters . 25 2.2.4 Summary of the importance of internal quality . 27 2.3 An As-is Analysis of Internal Quality . 27 2.3.1 The software crisis in literature . 28 2.3.2 Evidence of the problems in popular developer culture . 29 2.3.3 Interviews with Software engineering experts . 29 2.3.4 The Karakos EU project case study . 31 2.3.5 Karakos is not a black swan – EU project survey . 38 2.3.6 Diverse Own Experiences . 40 2.3.7 Summary . 44 2.4 Analysis of Problem Causes . 44 2.4.1 How people, processes and technology affect quality . 44 2.4.2 Resistance against new processes and technologies . 46 2.4.3 Economic goods and the tragedy of commons . 46 2.4.4 The tragedy of commons for internal quality . 47 2.4.5 Summary of origins . 50 2.5 Summary of the Problem . 50 v CONTENTS 3 State of the Art 53 3.1 Software Engineering . 53 3.1.1 Introduction . 53 3.1.2 Computer-aided software engineering . 54 3.1.3 Development methodologies . 56 3.1.4 Summary . 57 3.2 Software Quality . 57 3.2.1 The nature of quality . 58 3.2.2 Reducing internal failure cost with internal quality . 60 3.2.3 Quality management . 63 3.2.4 Summary . 66 3.3 Testing . 67 3.3.1 Map of testing . 67 3.3.2 Manual dynamic testing . 68 3.3.3 Automatic dynamic testing . 68 3.3.4 Manual static testing . 69 3.3.5 Automatic static testing . 70 3.3.6 Summary . 72 3.4 Mining Software Repositories . 73 3.4.1 Contribution, knowledge and ownership . 73 3.4.2 Determining contributors in evolving artifacts . 73 3.4.3 Concepts of contribution mining . 76 3.4.4 Software process artifact halo . 79 3.4.5 Information retrieval . 79 3.4.6 Summary . 81 3.5 Collaboration, Organization and Motivation . 81 3.5.1 Introduction . 81 3.5.2 Collaboration . 81 3.5.3 Organization . 84 3.5.4 Management and motivation . 86 3.5.5 Summary . 90 3.6 Comparable Works . 90 3.6.1 In ubiquitous computing . 90 3.6.2 In online collaboration . 91 3.6.3 In software development . 91 3.6.4 Summary of comparable work . 91 3.7 Summary . 92 vi CONTENTS 4 Thesis Statement 93 5 Design Process and CollabReview Concept 95 5.1 The Research Process . 95 5.1.1 The iterative process of this research . 96 5.1.2 List of requirements . 96 5.1.3 Details of the research iterations . 99 5.1.4 Summary of the research process . 105 5.2 The Computational Model . 105 5.2.1 Modeling software process artifacts . 105 5.2.2 Importance weight of software process artifacts . 107 5.2.3 Responsibility of contributors for software process artifacts . 107 5.2.4 Quality of software process artifacts . 109 5.2.5 Putting it together to karma scores . 111 5.2.6 An example of karma scores . ..
Recommended publications
  • Software Development Lifecycle (Sdlc) Models & Agile Methods
    sdlc% how did that happen? software development lifecycle (sdlc) models & agile methods • by analogy with civil engineering, where you design first, then do construction • in software, there is no “construction” it’s all design • used to be called coding sdlc%(2)% sdlc%(3)% • what is a software development process? • what is the lifecycle of a software project? • will talk about “agile” later. first, we’ll talk about “disciplined” or is it “traditional?” or is it “sturdy?” or is it “planned?” or is it… sdlc%(4)% example%feature%workflow% • tend to talk about sdlc in terms of a dichotomy – !“agile”!vs.!well…um…“not!agile”! – or,!“planned”!vs.!“con8nuous”! – others!tend!to!(incorrectly)!think!that!the! deployment!method!implies!the!process! • saas!==!agile! • installed!==!tradi8onal! • think more in terms applying the process on an individual feature, or an aggregate goal%of%sdlc% waterfall% Requirements! Design! Construc8on! • what’s the goal of a good sdlc? Integra8on! – passes!all!the!tests!(external!quality!aAriButes)! Debugging! – good!design/architecture!(internal)! Installa8on! Maintenance! – good!user!experience!(quality!in!use)! • move from one phase to the next only when its preceding phase is – process!quality!(can!process!help!ensure! completed and perfected. product!quality)! • first mentioned by Royce in 1970 as an example of a flawed, non- working model for software development. • US department of defence projects attempted to entrench this model by requiring their contractors to produce the waterfall deliverables and then to formally accept them to a certain schedule (US military standard DoD-2167) – there!was!a!unwieldy!process!for!going!Back!and!amending!previous! deliverables! waterfall%(2)% waterfall%(3)% more problems problems • static view of requirements – ignores volatility • lack of user involvement once specification is written • unrealistic separation of specification from design • often tracked with Gantt charts! • doesn’t easily accommodate prototyping, – printed!and!taped!up!on!the!wall! reuse, etc.
    [Show full text]
  • MAD SCIENCE! Ab Science Inc
    MAD SCIENCE! aB Science Inc. PROGRAM GUIDEBOOK “Leaders in Industry” WARNING! MAY CONTAIN: Vv Highly Evil Violations of Volatile Sentient :D Space-Time Materials Robots Laws FOOT table of contents 3 Letters from the Co-Chairs 4 Guests of Honor 10 Events 15 Video Programming 18 Panels & Workshops 28 Artists’ Alley 32 Dealers Room 34 Room Directory 35 Maps 41 Where to Eat 48 Tipping Guide 49 Getting Around 50 Rules 55 Volunteering 58 Staff 61 Sponsors 62 Fun & Games 64 Autographs APRIL 2-4, 2O1O 1 IN MEMORY OF TODD MACDONALD “We will miss and love you always, Todd. Thank you so much for being a friend, a staffer, and for the support you’ve always offered, selflessly and without hesitation.” —Andrea Finnin LETTERS FROM THE CO-CHAIRS Anime Boston has given me unique growth Hello everyone, welcome to Anime Boston! opportunities, and I have become closer to people I already knew outside of the convention. I hope you all had a good year, though I know most of us had a pretty bad year, what with the economy, increasing healthcare This strengthening of bonds brought me back each year, but 2010 costs and natural disasters (donate to Haiti!). At Anime Boston, is different. In the summer of 2009, Anime Boston lost a dear I hope we can provide you with at least a little enjoyment. friend and veteran staffer when Todd MacDonald passed away. We’ve been working long and hard to get composer Nobuo When Todd joined staff in 2002, it was only because I begged. Uematsu, most famous for scoring most of the music for the Few on staff imagined that our three-day convention was going Final Fantasy games as well as other Square Enix games such to be such an amazing success.
    [Show full text]
  • Exploring XP for Scientific Research
    focusExtreme Programming Exploring XP for Scientific Research William A. Wood and William L. Kleb, NASA Langley Research Center xtreme Programming, as an agile programming methodology, fo- cuses on delivering business value. In the realm of exploratory, long-term, small-scale research projects, prioritizing near-term E tasks relative to their business or scientific value can be difficult. Assigning even a qualitative monetary value can be particularly challenging for government research in enabling fields for which business markets have not yet developed. The conflict between near-term value and long-term research objectives leads to a culture clash when apply- the project using a GNU/Linux operating sys- ing basic XP practices. tem, the Emacs integrated development environ- We decided to explore this culture clash ment, and the Ruby programming language.1,2 when the Langley Creativity and Innovation Of- We had prior experience programming related fice solicited bids for exploring nontraditional algorithms for the advection-diffusion equation methodologies for aerospace engineering re- using Fortran but no experience in team soft- search. C&I was looking for a way to produce ware development, object-oriented design, extraordinary gains in productivity or enable unit testing, or programming with Ruby. entirely new applications. We submitted a bid As the project began, we realized that we and received one-year funding to perform a first had to deal with several cultural conflicts short prototyping assessment of XP at the before implementing the 12 XP practices. NASA Langley Research Center. We conducted Cultural conflicts Kent Beck lists nine environments that he says don’t work well with XP.3 Six of these Eight of Extreme Programming’s 12 practices are seemingly nine are counter to the existing culture at Lan- incompatible with the existing research culture.
    [Show full text]
  • Game Programming All in One, 2Nd Edition
    00 AllinOne FM 6/24/04 10:59 PM Page i This page intentionally left blank Game Programming All in One, 2nd Edition Jonathan S. Harbour © 2004 by Thomson Course Technology PTR. All rights reserved. No SVP,Thomson Course part of this book may be reproduced or transmitted in any form or by Technology PTR: any means, electronic or mechanical, including photocopying, record- Andy Shafran ing, or by any information storage or retrieval system without written permission from Thomson Course Technology PTR, except for the Publisher: inclusion of brief quotations in a review. Stacy L. Hiquet The Premier Press and Thomson Course Technology PTR logo and Senior Marketing Manager: related trade dress are trademarks of Thomson Course Technology PTR Sarah O’Donnell and may not be used without written permission. Marketing Manager: Microsoft, Windows, DirectDraw, DirectMusic, DirectPlay, Direct- Heather Hurley Sound, DirectX, and Xbox are either registered trademarks or trade- marks of Microsoft Corporation in the U.S. and/or other countries. Manager of Editorial Services: Apple, Mac, and Mac OS are trademarks or registered trademarks of Heather Talbot Apple Computer, Inc. in the U.S. and other countries. All other trade- Acquisitions Editor: marks are the property of their respective owners. Mitzi Koontz Important: Thomson Course Technology PTR cannot provide software support. Please contact the appropriate software manufacturer’s techni- Senior Editor: cal support line or Web site for assistance. Mark Garvey Thomson Course Technology PTR and the author have attempted Associate Marketing Managers: throughout this book to distinguish proprietary trademarks from descrip- Kristin Eisenzopf and Sarah Dubois tive terms by following the capitalization style used by the manufacturer.
    [Show full text]
  • Haruhi in Usa: a Case Study of a Japanese Anime in the United States
    HARUHI IN USA: A CASE STUDY OF A JAPANESE ANIME IN THE UNITED STATES A Thesis Presented to the Faculty of the Graduate School of Cornell University In Partial Fulfillment of the Requirements for the Degree of Master of Arts by Ryotaro Mihara August 2009 © 2009 Ryotaro Mihara ALL RIGHTS RESERVED ABSTRACT Although it has been more than a decade since Japanese anime became a popular topic of conversation when discussing Japan, both within the United States and in other countries as well, few studies have empirically investigated how, and by whom, anime has been treated and consumed outside of Japan. This research thus tries to provide one possible answer to the following set of questions: What is the empirical transnationality of anime? How and by whom is anime made transnational? How is anime transnationally localized/consumed? In order to answer the questions, I investigated the trans-pacific licensing, localizing, and consuming process of the anime The Melancholy of Haruhi Suzumiya (Haruhi) from Japan to the United States by conducting fieldwork in the United States’ agencies which localized Haruhi as well as U.S. anime and Haruhi fans. The central focus of this research is the ethnography of agencies surrounding Haruhi in the United States and Japan. I assume that these agencies form a community with a distinctive culture and principles of behaviors and practices in the handling of the Haruhi anime texts. The research findings to the above questions could be briefly summarized as follows. The worldview, characters, and settings of Haruhi (i.e. a fictious world of Haruhi which is embodied and described through its anime episodes and other related products) “reduces” and “diffuses” as it is transferred on the official business track from the producers in Japan to the localizers in the United States (i.e.
    [Show full text]
  • Risk Management and Agile Software Development: Optimizing Contractual Design
    Verlag Dr. Otto Schmidt 30.09.2016 CRi 6/2010 161 John P. Beardwood /Michael Shour Risk Management and Agile Software Development: Optimizing Contractual Design A recent report from Forester Research(Dr. Dobb’s I. Understanding (FR)AGILE Software Global Developer Technographics Survey Q3 2009) asked a cross-selection of 1298 IT professionals to iden- 1. Traditional Software Development tify which methodology most closely reflected the devel- Agile is perhaps best understood by contrasting it to opment process that such professional was currently Waterfall methods of development. The traditional using. At 35 %, the most popular response was Agile, in plan-driven software development model of the Water- comparison to a mere 13 % who responded that Water- fall process was initially conceived to manage the devel- fall was their current methodology of choice. Put opment of large software projects in the 1960s, such as another way, three times as many IT professionals used IBM’s System/360 operating system. Waterfall arranges Agile methodologies as did those who used Waterfall. software development into a sequential series of com- partmentalized phases, each with its own defined deli- Over the last ten years, Agile software development verables. A typical Waterfall process will be comprised methodologies – those which take an iterative and incre- of the following phases: requirements analysis; project mental approach, which aim to reduce unnecessary doc- planning and system design; coding; and integration and umentation and formality, and which seek to promote testing. 1 teamwork and experimentation – have increasingly been adopted by the software development community. The Waterfall process is characterized by planning, Agile’s advocates argue that by liberating programmers organization, and documentation.
    [Show full text]
  • The New XP Michele Marchesi
    The New XP Michele Marchesi “Even programmers can be whole people in the real world. XP is an opportunity to test yourself, to be yourself, to realize that maybe you’ve been fine all along and just hanging with the wrong crowd.” Kent Beck in Extreme Programming Explained — Second Edition In October, 1999, Kent Beck’s book “Extreme Programming Explained — Embrace Change” was published. Well, you may love or hate XP, but for sure you cannot say it was irrelevant. By publishing his book, sold in hundreds of thousand copies and translated in tens of languages, Beck started the tidal wave of agile methodologies. These methodologies can be fully adopted, partially adopted or not adopted at all, but no serious software engineer may overlook them. All new editions of software engineering textbooks now have a section on agile methodologies and XP. Five years after that book, Kent again took the stage and published — with Cynthia Andres — the second edition. And you can bet that it is not just a polishing or some addition. No, this second edition critically reviews what happened in these five years, and almost completely refunds XP, albeit sticking to the original principles, or just to be able to be faithful to them. In the first edition, XP was defined with four values, fifteen basic principles, and twelve practices. Also, Kent clearly wrote that to be XP, you had to fully apply all these famous twelve practices. Now, the twelve practices have disappeared! In the new XP, there are five values, fourteen principles, thirteen primary practices and eleven corollary practices.
    [Show full text]
  • Parallel Worlds: Agile and Waterfall Differences and Similarities
    Parallel Worlds: Agile and Waterfall Differences and Similarities M. Steven Palmquist Mary Ann Lapham Suzanne Miller Timothy Chick Ipek Ozkaya October 2013 TECHNICAL NOTE CMU/SEI-2013-TN-021 Software Solutions Division http://www.sei.cmu.edu Copyright 2013 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C- 0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for the SEI Administrative Agent AFLCMC/PZE 20 Schilling Circle, Bldg 1305, 3rd floor Hanscom AFB, MA 01731-2125 NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.
    [Show full text]
  • Introduction to Software Engineering
    Introduction to Software Engineering Edited by R.P. Lano (Version 0.1) Table of Contents Introduction to Software Engineering..................................................................................................1 Introduction........................................................................................................................................13 Preface...........................................................................................................................................13 Introduction....................................................................................................................................13 History...........................................................................................................................................14 References......................................................................................................................................15 Software Engineer..........................................................................................................................15 Overview........................................................................................................................................15 Education.......................................................................................................................................16 Profession.......................................................................................................................................17 Debates within
    [Show full text]
  • The Rapid Prototyping Process 29 What Is a Prototype: the 4 Dimensions 31 What to Prototype: 4 Ways to Combine Fidelity & Functionality 32 Takeaway 36
    Copyright © 2015 by UXPin Inc. All rights reserved. No part of this publication may be uploaded or posted online without the prior written permission of the publisher. For permission requests, write to the publisher, addressed “Attention: Permissions Request,” to [email protected]. Index 0. Introduction 6 1. A Practical Look at Prototypes 9 5 Reasons Why You Need to Prototype 10 How Prototypes Improve Collaboration & Communication 12 How Prototypes Add Balance to Design 14 How Prototyping Makes Usability Testing Easier 16 Why Prototyping Is Mandatory for Mobile 18 Takeaway 21 2. Choosing the Right Prototyping Process & Fidelity 22 When to Start Prototyping: 3 Points of Convergence 23 How to Prototype: The Rapid Prototyping Process 29 What Is a Prototype: The 4 Dimensions 31 What to Prototype: 4 Ways to Combine Fidelity & Functionality 32 Takeaway 36 3. Traditional Prototyping Methods and Tools 37 Paper Prototypes 38 Wizard of Oz Prototypes 44 Takeaway 47 4. Digital Prototyping Methods and Tools 48 Presentation Software 49 Coded (HTML) Prototype 52 Prototyping Software7 & Apps 55 Takeaway 58 5. Creating Prototypes for Usability Testing 60 Knowing Your Users: Personas, Scenarios, and Experience Maps 61 Usability Tests Before the Prototype 65 The Right Users and the Right Tasks 66 General Advice for Testing Prototype Usability 69 Different Fidelities for Testing Prototypes 71 4 Content Guidelines for Testing Any Prototype 73 Takeaway 75 6. 10 Prototyping Best Practices 76 1. Know Your Audience and Your Goals 76 2. Prime Your Audience Beforehand 77 3. Involve the Users (Participatory Design) 78 4. Focus on Flows and User Scenarios 79 5.
    [Show full text]
  • Download The
    Game Wrap ■ Editor in Chief Viktoriya Fuzaylova Editorial Board Game Wrap Volume 1 is Copyright (c) 2016 by New Viktoriya Fuzaylova England Interactive Literature. Copyrights to individual articles and larps herein remain with their respective Stephen Kohler authors. Brian Richburg Phoebe Roberts Th is work is licensed under the Creative Commons At- tribution-ShareAlike 4.0 International License. To view Adina Schreiber a copy of this license, visit http://creativecommons.org/ licenses/by-sa/4.0/. Author Liaison Brian Richburg Layout Designer Kathleen De Smet New England Interactive Literature c/o Chad Bergeron 258 Edgell Road Webmaster Framingham, MA 01701 Nat Budin ■ http://gamewrap.interactiveliterature.org EDITOR’S NOTE ESTEEMED READER! Welcome to the inaugural volume of Game Wrap, variety of games and role-play traditions that exist a magazine devoted to the art and craft of LARP. in our community and to welcome new infl uences. Please, allow me to introduce myself. I am the Th is brought up a fascinating and multifaceted magazine’s founder and fi rst Edi- debate about community identity and tor-In-Chief (self-appointed, how evolving language as exemplifi ed by else?), Viktoriya Fuzaylova. I would the diff erences in how the word LARP/ like to take up some space here to tell larp is spelled and used. (For more on you a little about this publication, how that, see one of our editors’ blogs.1) it came into being, and what we, the You may notice that within its pages staff , hope it can be. I want to highlight Game Wrap includes both.
    [Show full text]
  • Adapting Anime: Transnational Media Between Japan and the United States
    ADAPTING ANIME: TRANSNATIONAL MEDIA BETWEEN JAPAN AND THE UNITED STATES Brian Ruh Submitted to the faculty of the University Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy in the Department of Communication and Culture, Indiana University May 2012 Acceptance page Accepted by the Graduate Faculty, Indiana University, in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Doctoral Committee ____________________________________ Barbara Klinger, Ph.D. ____________________________________ Gregory Waller, Ph.D. ____________________________________ Yeidy Rivero, Ph.D. ____________________________________ Scott O’Bryan, Ph.D. April 9, 2012 ii Acknowledgements I am very grateful to my Ph.D. committee – Barbara Klinger, Gregory Waller, Yeidy Rivero, and Scott O’Bryan – for supporting me (and putting up with me) for these last few years. My parents, Richard and Christine, and parents in law, Dan and Barbara Skinner, have been positive influences throughout this entire process, and I’m sure they’re all glad to see me finish. However, the person who may have borne the most stress through the entire process has been my loving wife Sarah. I’m so thankful to have her. I also need to acknowledge my two beautiful daughters Charlotte and Abby, the sources of both great joy and great delays in the writing process. And finally, hello to Jason Isaacs. iii Abstract Brian Ruh ADAPTING ANIME: TRANSNATIONAL MEDIA BETWEEN JAPAN AND THE UNITED STATES This dissertation examines Japanese animation, or anime, as an example of how a contemporary media product crosses national and cultural borders and becomes globalized. Bringing together the theories of Hiroki Azuma and Susan J.
    [Show full text]