Impression Formation in Commons-based Peer Production: Activity Traces and Personal Profiles in GitHub

This post originally appeared in the  Follow the Crowd blog and describes an upcoming paper at CSCW 2013

In this paper we describe an investigation of impression formation in GitHub, an online distributed software development community with social media functionality. We find that users in this setting seek out additional information about each other to explore the project space, inform future interactions, and understand the potential future value of a new contributor. They form impressions around other users’ expertise and attitude based on visible history of activity across projects and successful collaborations with key high status projects in the community, and use this information to inform a cost-benefit analysis guiding decisions about how to interact with contributors to their projects.

The open source software development domain presents an example of commons-based peer production where uncertainty about the quality of others is the rule rather than the exception.  The issue of deciding how to deal with problematic code contributions can partially be attributed to this uncertain environment, where project owners may have difficulty understanding the expertise, background, and credentials of unknown contributors who seek to become involved.

However, with the advent of open workspaces instrumented with social media functionalities, there is now the potential to access information about contributors’ expertise, work style and interaction history.  This allows the potential to understand what other people are working on and how they interact with others just by looking at their profiles.  Several unique aspects of the GitHub environment provide data about the actions of members of the community not available in traditional open software repositories or other online peer production settings.

We interviewed project owners on GitHub to investigate how they used profile information to decide whether or not to accept a pull request (code contribution) from unknown contributors.  Owners described the various profile cues they attended to and the inferences about ability and attitude that they drew from this information.

Overall, we found that profile information was not necessarily useful in cases where the benefit and value of the code was evident.  However, when the code was problematic and not immediately acceptable, some developers used the contributors’ profiles to form quick impressions of their abilities and attitudes, which then helped them to form a cost-benefit analysis guiding further interaction.

For example, the cost of working with someone to fix their code so it could be accepted (which could be high in cases where contributors were newcomers or novices) was weighed against the potential benefits of helping mentor a new project member and potentially gaining help in the future, or the risks of being annoyed by time-consuming arguments with a novice whose profile showed evidence of a poor working attitude in the past.

The results show promise for the design of future systems to support distributed, computer-supported work.  By providing collaborators with more visible and easily-ascertained cues about a person’s abilities and work style, the impression formation process may be expedited and lead to more awareness of abilities and the effort involved in accepting the contribution.  This can potentially foster positive social outcomes in cases where there is a perceived gap in skill levels between the owner and contributor and the technical merits of the work are unclear and up for debate.

Jennifer Marlow, Human-Computer Interaction Institute, Carnegie Mellon University
Laura Dabbish, Human-Computer Interaction Institute and Center for the Future of Work, Heinz College, Carnegie Mellon University

Jim Herbsleb, Institute for Software Research and Center for the Future of Work, Carnegie Mellon University


Redistributing Leadership in Online Creative Collaboration

(This post originally appeared on the Follow The Crowd Blog.)

Online creative collaboration is complex, and leaders frequently become overwhelmed, causing their projects to fail. We introduce Pipeline, a collaboration tool designed to ease the burden on leaders, and describe how Pipeline helped redistribute leadership in a successful 28-person artistic collaboration.

For the Holiday Flood, 28 artists from around the world used Pipeline to create 24 artworks and release them in the days leading up to Christmas.

Leadership is important in many types of online creative collaboration, from writing encyclopedias to developing software to proving mathematical theorems. In previous work, we studied leaders of online animation projects, called collabs, organized on websites like NewgroundsThese leaders take on a huge variety of responsibilities, and many become desperately overwhelmed. They also struggle with poor technological support, relying on discussion forums designed for conversation, not complex multimedia collaboration. To manage these challenges, leaders attempt less ambitious projects and embrace top-down leadership styles. Still, less than 20% of collabs result in a finished product, like a movie, video game, or artwork.

Our goal was to encourage complex, creative, and successful collabs by designing a technology to ease the burden on leaders. Two theories guided our approach:

  • Distributed cognition holds that cognitive processes can be distributed across people, objects, and time.
  • Distributed leadership suggests that leadership roles can be decoupled from leadership behaviors, which could be performed by any member of a group.

We integrated these theories and used them to design a system which helps leaders distribute their efforts across both people and technology.

The result is Pipeline, a free, open-source collaboration tool. Pipeline enables redistributed leadership through the notion of “trust.” Projects have two types of members:

  • Trusted members, who can create and lead tasks (among other privileges)
  • Regular members, whose privileges are limited to working on existing tasks

At one extreme, creators can replicate the old “benevolent dictator” model popular on Newgrounds by trusting only themselves. At the other extreme, creators can trust every member of their projects, creating an open, wiki-like environment. Most Pipeline users will opt for something in between, making real-time adjustments as needed.

The Pipeline tasks system. In this example, Spagneti posts a new version of a work-in-progress, and RAMATSU provides feedback. The right column includes information about the task, links to other versions of this work, and a recent activity feed.

We launched Pipeline in 2011 and have seen users organize a variety of creative projects, includi moviesvideo games, and even a global scavenger hunt. Our paper focuses on one case study, an artistic collaboration called Holiday Flood. Over six weeks, 28 artists from at least 12 countries used Pipeline to create a digital Advent calendar with 24 original Christmas-themed artworks, along with an interactive Flash galleryEvery aspect of the project was completed on schedule, and the Newgrounds community responded with high ratings and a staff award.

The main menu of the interactive Flash gallery for Operation Holiday Flood. Clicking any of the square thumbnails reveals one of 24 Christmas-themed artworks.

Our research suggests that Pipeline contributed to Holiday Flood’s success in several key ways. It emboldened the project creators to attempt something more complex and ambitious than anything they had tried previously. Pipeline also helped members perform leadership behaviors previously reserved for leaders, like planning, problem solving, and providing feedback.

For more, see our full paper, Redistributing Leadership in Online Creative Collaboration.
Kurt Luther, Carnegie Mellon University
Casey FieslerGeorgia Institute of Technology
Amy Bruckman, Georgia Institute of Technology