Abstract not found

Our empirical research has shown that a predominant structural feature of defect tracking repositories is the evolving "bug report network " (BRN). Community members create BRNs by progressively asserting various formal and informal relationships between bug reports (BRs). In one F/OSS bug repository under study, participants assert two formal relationships (duplications and dependencies) and various informal relationships (like "see also " references). BRNs can be interpreted as (1) information ordering strategies that support collocation of related BRs, decreasing cognitive and organizational effort; (2) sense-making strategies wherein BRNs provide more refined representations of software and workorganization issues; (3) social ordering strategies that rearrange collective relationships among community members. This paper presents findings from an investigation of the nature, extent, and impact of BRNs in one large F/OSS development community. We investigate whether and how specific classes of BRNs influence problem management within the community, and identify several new research questions. 1.

Managers must understand, influence, and redesign organizational processes to improve business performance. In this paper we present a technique for documenting a business process. The technique has six steps: defining process boundaries, collecting data, determining actors and resources, determining activities, determining dependencies and model verification. While similar to other processmapping techniques, our approach is novel in incorporating ideas from coordination theory, thus the attention to dependencies. As a result, the technique is useful both for documenting a process and suggesting ways in which the process could be redesigned. We present an extended illustration with the hope that the technique can be used by readers of this article.

Many researchers have searched for evidence of organizational improvements from the huge sums invested in ICT. Unfortunately, evidence for such a pay back is spotty at best (e.g., Brynjolfsson, 1994; Meyer and Gupta, 1994; Brynjolfsson and Hitt, 1998). On the other hand, at the individual level, computing and communication technologies are increasingly merging into work in ways that make it impossible to separate the two (Gasser, 1986; Zuboff, 1988; Bridges, 1995).

Publicly accessible bug report repositories maintained by free / open source development communities provide vast stores of data about distributed software problem management (SWPM). Qualitative analysis of individual bug reports, texts that record community responses to reported software problems, shows how this distributed community uses its SWPM process to manage software quality. We focus on the role of one basic social process, negotiation, in SWPM. We report on the varieties and frequencies of negotiation practices and demonstrate how instances of negotiation in different contexts affect the organization of information, the allocation of community resources, and the disposition of software problems.

The concept of the core group of developers is important and often discussed in empirical studies of FLOSS projects. This paper examines the question, “how does one empirically distinguish the core? ” Being able to identify the core members of a FLOSS development project is important because many of the processes necessary for successful projects likely involve core members differently than peripheral members, so analyses that mix the two groups will likely yield invalid results. We compare 3 analysis approaches to identify the core: the named list of developers, a Bradford’s law analysis that takes as the core the most frequent contributors and a social network analysis of the interaction pattern that identifies the core in a core-and-periphery structure. We apply these measures to the interactions around bug fixing for 116 SourceForge projects. The 3 techniques identify different individuals as core members; examination of which individuals are identified leads to suggestions for refining the measures. All 3 measures though suggest that the core of FLOSS projects is a small fraction of the total number of contributors. 1.

1 Self-organization of teams for free/libre open source software development This paper provides empirical evidence about how free/libre open source software development teams self-organize their work, specifically, how tasks are assigned to project team members. Following a case study methodology, we examined developer interaction data from three active and successful FLOSS projects using qualitative research methods, specifically inductive content analysis, to identify the task-assignment mechanisms used by the participants. We found that „self-assignment ‟ was the most common mechanism across three FLOSS projects. This mechanism is consistent with expectations for distributed and largely volunteer teams. We conclude by discussing whether these emergent practices can be usefully transferred to mainstream practice and indicating directions for future research. (105 words) Keywords: Free/libre open source software development, task assignment, self-organizing teams, distributed teams, qualitative research methods Running head: Self-organization of teams in FLOSS development 2 Self-organization of teams for free/libre open source software development 1.

We argue that organizations often fail to organize effectively because individuals have lay theories about organizing that lead to coordination neglect. We unpack the notion of coordination neglect and describe specific cognitive phenomena that underlie it. To solve the coordination problem, organizations must divide a task and then integrate the components. Individuals display shortcomings that may create problems at both stages. First, lay theories often focus more on division of labor than on integration. We discuss evidence that individuals display partition focus (i.e. they focus on partitioning the task more than on integration) and component focus (i.e. they tend to focus on single components of a tightly interrelated set of capabilities, particularly by investing to create highly specialized components). Second, when individuals attempt to reintegrate a task, they often fail to use a key mechanism for integration: ongoing communication. Individuals exhibit inadequate communication because the ‘curse of knowledge’ makes it difficult to take the perspective of another and communicate effectively. More importantly, because specialists find it especially difficult to communicate with each other, the

Abstract – The use of Enterprise Architectures is becoming increasingly widespread in the private sector. Borrowing insights from enterprise reference architectures developed during the last decade, IT vendors and companies belonging to specific industries are establishing reference data and process models advancing the standardization of their businesses and creating a more integrated environment for their activities. Although public administrations share the same problem of non-standardization, which is being magnified rapidly in a changing and demanding environment, little has been done so far in the direction of integration. This article builds a basis, shows initial directions and attempts to stimulate interest in a PA enterprise framework. Following a top-down approach and employing concepts from the fields of public administration, enterprise integration and generic process and data modeling the outline of the ArchPad enterprise architecture for Public Administration is presented. I.

Since the initial publication in 1994, Coordination Theory (Malone and Crowston, 1994) has been referenced in nearly 300 journal articles, book chapters, conference papers and theses. This chapter will analyze the contribution of this body of research to determine how Coordination Theory has been used for user task analysis and modelling for HCI. Issues that will be addressed include: 1) how the theory has been applied; 2) factors that led to the success of the theory; and 3) identification of areas needing further research. An increasingly ubiquitous application of computer systems is to help a group of people work together better. To do so requires an appreciation of what the group is doing and how its members might work together in a more efficient or effective manner. Such user/group task analysis and modelling is at the core of MIS HCI research. A key issue in the analysis of group work is an understanding of the dependencies between the tasks the different group members are carry...