UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Using emergent team structure to focus collaboration Minto, Shawn 2007

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2007-0193a.pdf [ 10.25MB ]
Metadata
JSON: 831-1.0052079.json
JSON-LD: 831-1.0052079-ld.json
RDF/XML (Pretty): 831-1.0052079-rdf.xml
RDF/JSON: 831-1.0052079-rdf.json
Turtle: 831-1.0052079-turtle.txt
N-Triples: 831-1.0052079-rdf-ntriples.txt
Original Record: 831-1.0052079-source.json
Full Text
831-1.0052079-fulltext.txt
Citation
831-1.0052079.ris

Full Text

Using Emergent Team Structure to Focus Collaboration by Shawn Minto B.Sc, The University of British Columbia, 2005 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF T H E REQUIREMENTS FOR T H E DEGREE OF Master of Science The Faculty of Graduate Studies (Computer Science) The University Of British Columbia January 30, 2007 © Shawn Minto 2007 ii Abstract To build successful complex software systems, developers must collaborate with each other to solve issues. To facilitate this collaboration specialized tools are being integrated into development environments. Although these tools facilitate collaboration, they do not foster it. The problem is that the tools require the developers to maintain a list of other developers with whom they may wish to communicate. In any given situation, it is the developer who must determine who within this list has expertise for the specific situation. Unless the team is small and static, maintaining the knowledge about who is expert in particular parts of the system is difficult. As many organizations are beginning to use agile development and distributed software practices, which result in teams with dynamic membership, maintaining this knowledge is impossible. This thesis investigates whether emergent team structure can be used to support collaboration amongst software developers. The membership of an emergent team is determined from analysis of software artifacts. We first show that emergent teams exist within a particular open-source software project, the Eclipse integrated development environment. We then present a tool called Emergent Expertise Locator (EEL) that uses emergent team information to propose experts to a developer within their development environment as the developer works. We validated this approach to support collaboration by applying our ap-proach to historical data gathered from the Eclipse project, Firefox and Bugzilla and comparing the results to an existing heuristic for recommending experts that produces a list of experts based on the revision history of individual files. We found that E E L produces, on average, results with higher precision and higher recall than the existing heuristic. iii Contents Abstract ii Contents iii List of Tables v List of Figures v i Acknowledgements vii 1 Introduction 1 1.1 Scenario 2 1.2 Validation Approach • • • 3 1.3 Thesis Structure 3 2 Related Work 4 3 Emergent Teams Exist 7 4 Approach and Implementation 14 4.1 Approach 14 4.1.1 Mechanics 14 4.2 Implementation 17 4.2.1 Extensibility 18 5 Validation 20 5.1 Methodology 20 5.2 Data 24 5.3 Results 26 5.4 Threats 31 5.4.1 Construct Validity : 31 5.4.2 Internal Validity .' 32 •5.4.3 External Validity . . . . • . . ' . . . . 32 6 Discussion 33 6.1 Other Sources of Information 33 6.2 Using Emergent Team Information 34 6.3 Future Evaluation 34 Contents iv 6.4 Limitations 35 7 Summary 37 Bibliography 38 A Complete Results 40 B Name Mapping Method 54 C C V S to Bugzilla Name Mappings 56 C.l Eclipse 56 C.2 Mozilla 59 V List o f Tables 3.1 Number of projects each JDT developer has committed to in the last two years other than JDT projects 9 5.1 Bug and change set statistics per project 25 5.2 Optimistic average precision 27 5.3 Optimistic average recall 27 A. l Mapping of test case number to unique combination of bug com-ment partition, size of change set and number of recommendations. 41 B. l E-mail to CVS username mapping statistics per project 55 C. l Eclipse one-to-one username to e-mail mappings 57 C.2 Eclipse one-to-many, duplicate and unknown username to e-mail mappings 58 C.3 Mozilla one-to-one username to e-mail mappings 60 C.4 Mozilla one-to-one username to e-mail mappings continued. . . . 61 C.5 Mozilla one-to-one username to e-mail mappings continued. . . . 62 C.6 Mozilla one-to-one username to e-mail mappings continued. . . . 63 C.7 Mozilla one-to-one username to e-mail mappings continued. . . . 64 C.8 Mozilla one-to-many username to e-mail mappings 65 C.9 Mozilla one-to-many username to e-mail mappings continued. . . 66 C.10 Mozilla one-to-many username to e-mail mappings continued. . . 67 C.11 Mozilla Duplicate username mappings. . 68 C.12 Mozilla Duplicate username mappings continued 69 C.13 Mozilla unknown username mappings 70 vi List of Figures 3.1 J D T developer project activity for mkeller 10 3.2 J D T developer project activity for ffusier 11 3.3 Platform developer project activity for emoffatt 12 3.4 Platform developer project activity for teicher 13 4.1 Context menu list of developers showing the multiple methods of communication available 15 4.2 E E L in use within Jazz 16 4.3 Architecture of E E L 17 5.1 The 9 cases for validation. Lines in this diagram represent a combination of comment partition and change set subset for val-idation purposes 23 5.2 Eclipse optimistic precision 28 5.3 Eclipse optimistic recall. 28 5.4 Bugzilla optimistic precision. 29 .5.5 Bugzilla optimistic recall 29 5.6 Firefox optimistic precision 30 5.7 Firefox optimistic recall 30 A . l Al l Eclipse optimistic precision 42 A.2 Al l Eclipse pessimistic precision - 43 A.3 Al l Eclipse optimistic recall 44 A.4 Al l Eclipse pessimistic recall 45 A.5 Al l Bugzilla optimistic precision 46 A.6 Al l Bugzilla pessimistic precision 47 A.7 Al l Bugzilla optimistic recall 48 A.8 Al l Bugzilla pessimistic recall. . . . '. 49 A.9 'All Firefox optimistic precision 50 A.10 Al l Firefox pessimistic precision 51 A.11 Al l Firefox optimistic recall 52 A.12 Al l Firefox pessimistic recall : . . 53 vii Acknowledgements I would like to thank my supervisor Gail Murphy for introducing me to research during a co-op work term as an undergraduate. I would not have known about the interesting world of research if it were not for her. Also, through work-ing on Mylar with Mik, my research interests in collaboration and task based development were made apparent. Furthermore, I would like to thank all of the members of the Software Practices Lab for engaging conversations about a range of research topics related to software engineering. Finally, I could not have finished this thesis without all of the love and support from Kenedee over the past two years. 1 Chapter 1 Introduction Software developers must collaborate with each other at all stages of the soft-ware life-cycle to build successful complex software systems. To enable this collaboration, integrated development environments (IDEs) are including an in-creasing number of tools to support collaboration, such as chat support (e.g., E C F 1 and the Team Work Facilitation in IntelliJ 2) and screen sharing (e.g., IBM Jazz3). All of these tools have two limitations that make them harder to use than necessary. First, the tools require the user to spend time and effort explaining the tool to all members of a team with whom he may want to communicate over time (i.e., a buddy list). Given that the composition of software teams is increasingly dynamic for many organizations due to agile development pro-cesses, distributed software development and other similar trends, it may not be straightforward for a developer to keep a description of colleagues on the many teams in which she may work up-to-date.4 Second, the tools require the user to determine with whom he should collaborate in a particular situation. This requirement forces the user to have some knowledge of who has expertise on particular parts of the system. To support collaboration amongst members of such dynamic teams, there is a need for a mechanism to determine the composition of the team automatically so that developers do not need to spend time configuring membership lists for the many teams to which they may belong. We believe, for many cases in which collaboration needs to occur, the context from which a developer initiates com-munication combined with information about the activity of developers on items related to that context can be used to determine the appropriate composition of the team. We consider that the team structure emerges from the activity, and thus refer to this problem as determining emergent team structure. In this thesis, we describe an approach and tool, called Emergent Expertise Locator (EEL), that overcomes these limitations for developers working on code. 1 E C F is the Eclipse Communications Framework, http://www.eclipse.org/ecf/, verified 12/17/06. 2IntelliJ is a Java development environment, http://www.jetbrains.com/idea/, verified 12/17/06. 3 Jazz is an IBM software development environment supporting team development and designed to incorporate all development artifacts and processes for a company. Some of the features included are source control, issue tracking and synchronous communication through chat. 4 A s one example, the Eclipse development process uses dynamic teams as described by Gamma and Wiegand in an EclipseCon 2005 presentation, http://eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf, verified 12/17/06. Chapter 1. Introduction 2 The intuition is that a useful definition of a team, from the point of view of aid-ing collaboration, are those colleagues who can provide useful help in solving a particular problem. We approximate the nature of a problem by the file(s) on which a developer is working. Based on the history of how files have changed in the past together and who has participated in the changes, we can recommend members of an emergent team for the current problem of interest. Our ap-proach uses the framework from Cataldo et. al.[2], adapting their matrix-based computation to support on-line recommendations using different information, specifically files rather than task communication evidence. EEL produces a col-laboration matrix C through the computation, C = (FAFD)FJ where FA is a file authorship matrix and FD is a file dependency matrix. Further information on the'matrices and the computation are presented in Section 4.1.1. After this computation, a value in C^- describes which developers should interact based on the revisions that they have committed in the past to the repository. We use these values in C to recommend a ranked list of the likely emergent team members with whom to communicate given a set of files currently of interest. 1.1 Scenario To describe why and how E E L can help developers as they work, we describe a scenario of a common development task that may require communication between two developers to gather knowledge required to solve an issue. This scenario provides insight into the simplicity and usefulness of EEL. Selena, Dave and John are developers on the same open-source project. Selena, Dave and John each live in a different part of the world. This project has been released and the developers are currently working to fix bugs that have been reported by users. Even though these three developers all work on the same project, each is more knowledgeable about a different area of the code than the others because he or she has worked on that part of the'code base more frequently. Many of the bugs that have been reported refer to the core data model for the system, a part of the system for which Selena is the most knowledgeable. Dave, on the other hand, was in charge of the external representation of the model for the release. Since Dave is somewhat knowledgeable about the model, and there have been no bugs reported related to his portion of the system, he decides to help Selena and fix some bugs that are more appropriate for her. Dave picks a bug. To start working on it, he investigates a stack trace provided in the bug that is related to the error. Although he can reproduce the problem, he is unable to determine the source of the problem because it requires extensive knowledge of how events are sent and handled within the model. Since he is unaware of how this works, he right clicks on the file on which he is currently working and views a list of people to contact on the team associated with that part of the software as determined by EEL. This ranked list shows Selena listed as the most knowledgeable followed by John. Since Dave knows that Selena was busy, he does not want to contact her. However, EEL has made it evident Chapter 1. Introduction 3 that John is also knowledgeable, a fact of which Dave was unaware. John is listed because he worked part time on the model, but is very knowledgeable of it. Dave decides to contact John through chat and is able to gain the knowledge that he needed to fix the bug. If John was not online, Dave could have used an asynchronous communication method like e-mail to contact him. EEL is not only useful during the exploration of a system to fix a bug, but it can also be useful during regular development and testing and during mentoring when junior developers are becoming familiar with a system. EEL is integrated into an IDE such that at any point while working on a system, a developer can open the context menu on a file, determine who they may contact to gather more information about a task that they are currently working on and easily initiate communication with the appropriate colleague. 1.2 Validation Approach To determine the accuracy of E E L in predicting emergent teams, we applied the approach to historical data for the Eclipse project, Firefox and Bugzilla. The validation of EEL was fully automated and did not involve users since it is difficult to recruit developers if there is no evidence of the usefulness of the tool. To perform the validation, we needed two pieces of information, a bug report and the list of files needed to fix the bug report. Bug reports provide a record of communication on a particular issue and we use the commenters on the bug as a list of potential experts. We populate E E L using the list of files needed to fix the bug as determined using a standard means of associating bugs and file revisions (See Section 5.2). We then used the recommendations from EEL and the list of potential experts from the bug report to calculate the precision and recall. We then compared the performance of EEL to an existing heuristic for recommending experts that produces a list of experts based on the revision history of individual files. We found that EEL produces, on average, results with higher precision and higher recall than the existing heuristic. 1.3 Thesis Structure We begin by comparing our approach with existing work on locating experts (Chapter 2). Next we show that emergent teams exist in Chapter 3.' Next, we describe our approach and implementation (Chapter 4) before presenting our validation of the approach (Chapter 5). Before summarizing, we discuss outstanding issues with our approach and validation (Chapter 6). 4 Chapter 2 Related Work Three types of approaches have been used to recommend experts for a software development project: heuristic-based (e.g., [15]), social network-based (e.g., [16]) and machine learning-based (e.g., [1]). Heuristic-based recommenders apply heuristics against data collected from and about the development to determine who is expert in various areas of the system. Some approaches require users to maintain profiles that describe their area of expertise (i.e., Hewlett-Packard's C O N N E X 1 ) or organizational position (i.e., [13]). C O N N E X is a traditional expertise finder which requires users to maintain a profile of their expertise. C O N N E X then allows users to search or browse the directory of profiles looking for a person with the expertise in which they are interested . Expertise Recommender (ER) uses an organizational chart of departments within a company to determine if an expert should be recom-mended based on the "distance" the departments are from each other [13]. This allows E R to limit the recommendations to people who are in departments that are "connected" to the department of the developer requesting the recommen-dation. These profiles can be effective because they gather information from the source of the expertise. Unfortunately, it is difficult to keep such profiles up-to-date. During a field study of expertise location, it was found that a seven-year old profile-based system was available but the profiles had never been updated [12]. To avoid this problem, E E L does not use any profile-based information. Other heuristic-based expertise recommenders are based solely on data ex-tracted from the archives of the software development. The Expertise Browser (ExB), for example, uses experience atoms (EA), basic units of experience, as the basis for recommending experts [15]. Experience atoms are created by min-ing the version control system for the author of each file revision and the changes made to the file. A mined experience atom is then associated with multiple do-mains (e.g., the file containing a modification, the technology used, the purpose of the change and/or the release of the software). A simple counting of experi-ence atoms for each domain in question is then used determine the experience in that area. Similar to our approach, ExB equates experience to expertise. In contrast, our approach accounts for how files are modified together (See Sec-tion 4.1), which we believe contain rich information about the expertise of the developer who made the change. As another example, the Expertise Recommender (ER) by McDonald [13] was deployed using two heuristics: tech support and change history. The change history heuristic, which is related to our work, uses the "Line 10" rule that Mittp://www.carrozza.com/atwork/connex/about.html, verified 01/08/07 Chapter 2. Related Work 5 states that the revision authors are the experts for a file. These experts are ranked according to revision time so that the last developer to modify the file has the highest rank [13]. If multiple modules are selected as the target for an expertise request in E R , an intersection of the experts is performed, raising the possibility of E R producing an empty set of experts. In contrast, E E L uses the frequency of file modifications that occur together and can always produce a recommendation. Both E R and E x B require the user to switch from the application in which they are currently working to a special one designed for supplying the expertise recommendations. Yimam-Seid et. al. wrote that "it is beneficial if expert finding systems are embedded in the day-to-day problem solving and informa-tion search environments" since expertise finding is a daily occurrence[18, p 13]. E E L takes this approach by providing the expertise recommendations from within the development environment. This allows developers to work as nor-mal, and if a problem arises, they can request the expertise list without having to switch applications. Furthermore, E R requires the user to enter potentially complicated queries to the system[13] to get recommendations and ExB makes the developer select the module on which they are currently working [15]. Since activity within the IDE provides the context for a developers current work, E E L determines the files that the user is interested in by monitoring their work. E E L is therefore able to determine the experts in the area that is currently under investigation automatically, without a user entered query. A social network describes relationships between developers built using data mined from the system development (e.g., [9]). These networks often become large. As a result, many tools support queries to prune the network to show the most relevant portion; for instance, enabling the production of a view with experts in a particular area such as NetExpert [16]. NetExpert provides support for searching for an expert, browsing the social and knowledge networks as well as ways to initiate communication [16]. NetExpert requires the user to initially create a profile, then it is maintained automatically by using information in documents that the user submits to the system as well as their personal web pages[16]. This social network approach adds complexity for the user since they must be able to interpret and search the network to extract the information that they want. In contrast, the query needed to determine the experts in E E L is formed behind the scenes automatically based on what the artifacts and tasks on which the developer is working. Social networks were also used in the Expertise Recommender (ER) to tailor the expertise results for each user[ll]. For E R , the social networks were cre-ated by hand through information gained directly from the users. The networks created were then used to change the expertise recommendations based on the relationships between users. This means that each user might get different rec-ommendations based on the people with whom they would rather communicate. Explicit social network information is an excellent way to tailor the recommen-dations but was not used in E E L since it would be a per-project customization that would require extensive analysis of the teams to build. Furthermore, the method used by E R to get the social network has the same problems as profiles Chapter 2. Related Work 6 since it requires the networks to be updated as both the project and teams evolve. Machine learning-based approaches in the area of expertise recommendation have focused on using text categorization techniques to characterize bugs [1] and documents [17]. Anvik et. al. describe a system to recommend developers who should fix a bug based on the history of bug fixes for the system and the de-scription of the newly reported bug. A more generalized machine learning-based expertise locator is ExpertiseNet as described by Song et. al. [17]. ExpertiseNet examines files, specifically papers, to dynamically update a users' expertise pro-file [17]. Similar to machine learning-based expertise recommenders, E E L relies on past information to form recommendations. In contrast to these approaches, E E L uses a simple frequency-based weighting to form recommendations and does not produce any general model of the activity between developers. To investigate the coordination requirements of a project [2], Cataldo et al. introduced an elegant matrix-based' solution to finding and investigating these requirements. In their approach, the product of a task dependency matrix and a task assignment matrix is multiplied by the transpose of the task assignment matrix to produce a description of the extent to which people involved in a development share tasks. In comparison, we use the basic matrix framework to consider how work performed oh files, irrespective of tasks, can be used to pre-dict expertise as a developer works, as opposed to analyzing post-development if the communication matches the coordination requirements. Previous expertise recommenders were validated using human subjects; few have undergone a systematic user evaluation[10]. Expertise Browser (ExB) was deployed in two companies and the type and number of interactions of users with ExB was recorded [15]. Use of the tool was used to infer if the tool worked well. No information was collected on the accuracy of the ExB recommen-dations. Expertise Recommender (ER) was validated using a systematic user evaluation[10]. This study had users rank a list of potential experts and then the results were compared to the ranking provided by ER[10]. The validation presented in this thesis of E E L focuses on an automated validation strategy as initial accuracy numbers are needed prior to inserting the technology in a development environment. 7 Chapter 3 Emergent Teams Exist Two recent trends in software development are the use of more agile software de-velopment processes[6] and global(distributed) software development[4]. These trends have arisen for many reasons, including the need to ensure appropriate expertise for the development at appropriate times. By using these development techniques, formal teams are replaced by dynamic ones that are created during development and that are constantly changing. The team structure emerges from the activity, and thus we refer to this as the emergent team structure Lewin and Regine define an emergent team as "a dynamic way of working together that keeps organisations on the edge" [8]. In an EclipseCon 2005 pre-sentation entitled "the eclipse way: processes that adapt", Erich Gamma and John Wiegand described the use of dynamic teams during the development of Eclipse; these teams are established to solve cross-component issues and consist of developers from all components affected by the issue. We believe that emergent teams in software development are not created only explicitly just to solve particular issues, but, more commonly, that they form implicitly through the action of working in the same area of the system. If a new developer begins work on an area of a software system, they are joining the emergent team consisting of the other developers who have previously worked in that area. The previous developers have the expertise needed to work on the system that the new developer must gather by interacting with the team. Even if formal teams are defined, developers naturally create, join and leave emergent teams on a daily basis based on the area of the system in which they are currently working. To show that emergent teams exist and to understand more about their cre-ation and composition, we investigated whether such teams exist on.the Eclipse project. We found that, on average, each committer on the Eclipse Java devel-opment tools (JDT) component team committed to eight different Eclipse Java projects1 other than JDT projects2 within the past year. Table 3.1 shows the number of projects, other than JDT projects, that each of the Eclipse JDT de-velopers has committed code to within the last year. As this table shows, some developers are stationary (just working on the code within their designated team) while others are much more active across the rest of Eclipse. Further-more, research on developer social networks by Madey et. al. saw a similar trend on SourceForge3. They noted that the "busiest" developer worked on 1 A Java project is a module that is at the top level of the Eclipse CVS tree. 2 Java projects beginning with org.eclipse.jdt. 3 A project hosting site, http://sourceforge.net, verified 12/17/06. Chapter 3. Emergent Teams Exist 8 between 17 and 27 projects during the 14 month period that they monitored[9]. A more fine-grained view of the dynamic nature of teams on the Eclipse project is to look at the amount of work developers perform on each project within a given time frame. Figures 3.1, 3.2 3.3 and 3.4 show the activity of four different developers, two from the Eclipse JDT team and two from the Eclipse Platform team. The graphs consider a six month period divided into two week spans. The bar graph for each two week period represents the total number of commits that the developer made to all of the Eclipse Java projects. Each of the lines represents the number of commits made to each separate project. These graphs show how a developer's activity on a specific project changes over time and their area of focus in the system changes as well. This change in activity shows that the developers participate in many different teams, as they are not the only developer contributing to the different parts. This provides proof that even though a developer belongs to a formal team, their emergent team is changing as they work, showing how teams emerge. Chapter 3. Emergent Teams Exist 9 Table 3.1: Number of projects each J D T developer has committed to in the last two years other than J D T projects. Username Number of Projects sdimitro 52 dmegert 29 dejan 26 kmoir 20 darins 12 mfaraj 12 darin 11 teicher 11 krbarnes 9 dbaeumer 9 twidmer 8 mkeller 7 maeschli 5 aweinand 5 mrennie 3 bbaumgart 2 jeromel 1 oliviert 1 ffusier 1 pmulet 1 wharley 1 jgarms 1 lbourlier 0 tyeung 0 daudel 0 thanson 0 mdaniel 0 kent 0 Average 8 m k e l l e r Figure 3.1: JDT developer project activity for mkeller. Chapter 3. Emergent Teams Exist 1 1 siiuiCQ jo JOqiunN e m o f f a t t 25 2 Week Period Figure 3.3: Platform developer project activity for emoffatt. to t e i c h e r 14 Chapter 4 Approach and Implementation 4.1 Approach The goal of the Emergent Expertise Locator (EEL) is to make it easier for a developer to determine with whom to communicate during a programming task. E E L displays a ranked list of other developers with expertise on the set of files that the user of EEL has recently edited or selected—their current change set. To use EEL, a developer accesses a menu on a source 'file that displays a ranked list of developers along with ways to initiate a communication as in Figure 4.1. These communication methods may be synchronous (i.e., chat) or asynchronous (i.e., e-mail). This approach aims to minimize the impact of the communication on a developer's work flow and aims to provide assistance in context; for example, a developer need not switch to an external application to perform the communication and context about the developers current state may be automatically transmitted to the expert with which communication is begun. 4.1.1 Mechanics Our approach is based on the mechanism of using matrices to compute coordi-nation requirements introduced by Cataldo et al. [2]. Our approach requires two matrices, the file dependency matrix and the file authorship matrix, and produces a third, the expertise matrix. 1. File Dependency Matrix A cell ij (or ji) in this matrix represents the number of times that the file i and the file j have been modified together1. Since this produces a triangular symmetric matrix, E E L only records data in the upper half of the triangle to save space. This matrix is populated by querying a version control system, for each version of a file, for the files that changed with it. 2. File Authorship Matrix A cell ij in this matrix represents the number of times an developer % has modified a file j. The time duration can be set within E E L . By default, the entire project history is used. Chapter 4. Approach and Implementation 15 Figure 4.1: Context menu list of developers showing the multiple methods of communication available. Expertise Matrix This matrix represents the current experts based on the file dependency matrix and the file authorship matrix. A cell ij (or ji) in this matrix specifies the amount of expertise that developer i has to j. We consider that the higher the number in cell ij, the more of an expert developer j is to i. This matrix is computed using the equation: C = (FAFD)FT (4.1) where C is the expertise matrix, FA is the file authorship matrix and FQ is the file dependency matrix. The tool that we have built on this basic approach uses a developer's current change set—the files the developer has recently selected or edited—to suggest an ordered list of developers with whom to communicate. Figure 4.2 shows this tool working within the Jazz Eclipse client. To provide this support, E E L mines information as a developer works. When a developer selects or edits a file, it triggers E E L to access the version control system and mine the related files and authors to populate the matrices. Once the user right clicks on a file and attempts to collaborate with another developer, E E L calculates the coordination matrix on the fly to ensure up-to-date information. The calculation of the coordination matrix can be time intensive. To mitigate this problem, since we are interested in experts only for the current developer, we modify the expertise matrix calculation to be (RFAFD)FH (4.2) where v is a vector that represents the experts related to just the current devel-oper, RpA is the row that corresponds to the current developer in the file au-thorship matrix, FQ is the file dependency matrix and FA is the file authorship matrix. By using only the row that corresponds to the current developer, the matrix multiplications are reduced to simple vector calculations. Even though we are only interested in the experts relative to the developer performing the query, the entire file dependency and file authorship matrices must be populated since they are required for the expertise matrix calculation. Java - AtlnbuleRsure.Java - Eclipse SDK Ffc Edit Source Refector fiavigate Search Project fun Window Heb i i i CH.if a. draw, application CH.ifa.draw.figures ,ti AriowTip.iava ij AttributoRgure.javi .+.' /.< BerdeiDecorator ,|ava +, ^ Border tool. )ava >'• ChopEiip se Connect jr. )ava * j(j CormectodText Tool. )ava ;|}) EfcowConnection la«a :» [/j •bowHarvSe. )ava > fl Eipsefrgi^ e.iave S 18 FicjveAttrtiutes.iava .+'• J'j FontSiieKardie. tava * -J\ SroupCommand.Java % £j\ Gfoupftgure.java >, j\ &oupMenJe.>ava .•' J] ImageFtgur* )*v* '* i\ lnswtlmageCo^-a'i |«va 9 LineConnectirjn.)ava > [ij tnsOecaaton t»v| .•, j ? NifrbeiTextFtgm.iavA * ]7j PofyUreCflnnecto(.Vav» JTj PoJyLnefTCve Java rH ^ PolymHande.i*va > PoryUnet water, lava >: RarJusManote Java :+ £fl RectangleFigure.tava :+'i, ft RondRextangleFicva.lava :• j j SobbleTooi.save > J) l^ ortestCistariceCorinertor.java a Ifi TaxtFigure.iava 8 ® TartTod.java '*; J7j Unc^ CMJCDnimand.iava _f|§ CH.iFa. draw, frame wort 3^ CH.|fa. crew, image* |H CH. if a. draw, samples, javadraw i:) draw,samples.iavadr aw. sarrple images ;f8 CH, if a. draw, samples, net if* CH.i.'a.draw.samples.™*King IH CKira.drajw.samples.pert, •fj^  CH,iFa.draw.samples,pett.images CH.fa.draw.stafidard j|f CH.ifa.draw.util If: Sfe -RE System Library [tdkl ,5] * ! »G XWnjKJME/Junit.iar - C:Ueam\so>\ecfese\p*^ s\org.juni(_3.B.l\iunit.jar | j cuU.xm! Seccrti [latest] YOtd dca» (Graphics 0) < * i f 1 CO i t 1 Open Declaration Open Type Hierarchy Open CaB Herarchy Open Super implementator Show Package Explorer F3 H CW+Afc+H > Paste Qrl+V V protec Sovee Ref actor Local Htstcry A*+5htt+S » Afc+5hrf{+T y ) References Declarations Occurrences nFfa > Qrl+Shft+U • Run As * Debug As • Coteiwate . :^  liSflVHHHJMB • Set Cornpare Wth »| Replace With fj • met Prefer ericas,.. publ ic Coloc g e t f i l l C o I o c O ( return (CoiQCj ge tA t t r i bu t e ( " F i l l Co l o r " ) Modems Charges.: I rnpoit declarations Att'ibuteFigure n ("Attributes : FigureAtt • a ^ FgOefauHAtttbutes <?' senalVersioriUID : lond;; '•j* attrbuteFigueSer ai* .v= c AlcribWeFgureQ ! $ * :draw(GrapWcs) drawBadayoundfGrap: 4 drawFiame[Graphks) 9 getFSCotor0 & getFrameCotorQ n s IrttiaiMAttrbutesO . « : 5 gecDefaultAttrtaute(Sti 4 getA»nbute(Strrfl) » i setAttrbutKStrfig, M|i « * write<StofaWeOutpul:) • r^eaoXStorabelnput) Sraart Insert :-53:10 IMoWoiihPtogress • Figure 4.2: EEL in use within Jazz. Chapter 4. Approach and Implementation 17 IBM Jazz EEL Plug-in IBM Jazz SDK Eclipse SDK EEL Core MTJ Library IBM Jazz Server Figure 4.3: Architecture of EEL. 4.2 I m p l e m e n t a t i o n EEL is implemented as a Java plug-in for Eclipse since Jazz has an Eclipse client. The core plug-in contains the algorithms and data structures required to determine the potential experts based on the repository data. This core plug-in also handles scheduling the queries to the repository in the background so that they are transparent to the developer. Furthermore, it provides an extension point so that additional repository support can be added easily. The second plug-in is the repository plug-in. This plug-in is related directly to the type of repository that EEL queries for author and related file information. Figure 4.3 shows the architecture of EEL with respect to Eclipse and Jazz. We have developed a repository plug-in for both Jazz and Subversion repositories. EEL uses the application programming interface (API) provided by Jazz to gather information from the version control system (i.e., change sets and authors) that is needed to build the file authorship and dependency matrices. Since EEL is developed as a client-side plug-in, no changes had to be made to the Jazz server. This means that EEL is personalized based on each user and the files on which they have worked. E E L could have been implemented as a server, but we chose the client-based approach since we wanted to ensure that each developer could personalize the tool to suit their needs. Furthermore, implementing EEL as a server would require additional infrastructure that we did not want to impose on teams. To support matrix computations in EEL, we used the open-source matrix package Matrix Toolkits for Java2. This package provides the ability to create the required matrices as well as perform the necessary calculations to obtain the expertise matrix. To ensure that the final matrix contains enough relevant information to determine the appropriate experts in the area of interest, EEL uses matrices that are 1000 elements square. This choice means that we can track up to 1000 files, enabling a substantial portion of a developer's work to be 2 M T J , http://rs.cipr.uib.no/mtj/, verified 12/17/06. Chapter 4. Approach and Implementation 18 used for the recommendation of experts. Even though the matrices are fairly large, they can fill up quickly due to the number of related files per revision of a file. To mitigate this problem, E E L uses a least recently used approach to determine which entries to remove from the matrix once it becomes full, allowing the files that are either related or viewed more often to remain in the matrix longer. To ensure that the files that a developer has worked on (the current change set) remains in the matrix, they are removed only if they occupy 50% of the matrix. The current change set, the files which the developer has selected or edited, is treated differently since the set contains information that directly pertains to the developer's current work. Since the files in the change sets provide the basis for the determination of expertise within E E L , it is necessary that they provide accurate information. Ying and colleagues noted that while mining software repositories, change sets containing over 100 files are often not meaningful since they usually correspond to automated modifications, such as formatting the code or changing the licenc-ing [19]. After inspecting the change logs for several projects,3 we noted that this is true of most change sets with over 50 files. With this knowledge, we were able to limit E E L from mining information from change sets with over 50 files in it. This choice ensures that, irrelevant related file data does not pollute the file authorship and dependency matrices. The time required for E E L to produce a recommendation is dependant on two main factors. The first factor is the speed of the repository from which E E L accesses the author and related file information. This speed is affected by many factors such as network speed, repository size and server load. Generally, these systems can provide the information that is required by E E L quickly, therefore, it is not a major factor in the usability of E E L . The second factor is the speed of the calculation of the expertise matrix. Since the expertise matrix is computed when the user opens the menu, it is the main factor in producing a recommendation quickly. On a 2.13Ghz Core 2 Duo system with 2Gb of memory, the calculation of the expertise matrix takes 891ms using the vector calculation approach. 4.2.1 Extensibility E E L was designed to be extensible since many different repositories and com-munication methods exist. Currently, E E L supports only the addition of a repository that is tied to a single communication tool (e.g., Jabber 4 or IBM Lo-tus Sametime5). This is an issue since two teams using the same repository may use different systems for communication. Each repository needs the communi-cation mechanism handled separately since many systems, unlike Jazz, do not have collaboration support built into them and external tools need to be used. 3 Most notably Eclipse and Gnome Evolution. 4Jabber is an open-source instant messaging system, http://www.jabber.org/, verified 01/08/07. 5Sametime is an enterprise instant messaging and web conference system, http://www-142.ibm.com/software/sw-lotus/sametime, verified 01/08/07. Chapter 4. Approach and Implementation 19 If EEL is to employed it would be beneficial to provide a pluggable communi-cation framework since not all projects use the same collaboration techniques, even if they use the same version control system. To add support to E E L for a new repository, a single class needs to be created. This class must implement methods for retrieving author and related file information from the repository given a file that the developer is currently interested in. These methods are called from the core plug-in of E E L when the developer selects or edits a file. Chapter 5 Validation 20 Ideally, we would validate EEL by gathering statistics about the accuracy of EEL's recommendations as developers use the tool as a part of their daily work. Such an evaluation requires a moderately-sized, preferably distributed, devel-opment team. Engaging such a team in an evaluation is difficult without any proven information about the effectiveness of the technique. To provide initial evaluation information, we have thus chosen to apply the approach to the history of existing open-source systems. We use information about the revisions to files stored in the version control system of a project to drive our approach. We use the communication patterns recorded on bug reports as a partial glimpse into the collaborations that actually occurred between the developers. Because we have only a glimpse into the communication that occurred during the project, the results we provide in this section are essentially a lower-bound on the accu-racy of the recommendations provided. For validation purposes, we created an extension to EEL that allowed for the mining of Subversion1 repositories. Subversion was used since it retains information about change sets stored in the repository, unlike CVS which stores single file modifications. First, because the early access version of Jazz had limitations that prevented us from importing an active open-source project, limiting the size of project we could use for validation2. We were able to access and create subversion repositories for a variety of open-source projects, enabling a more thorough evaluation. 5.1 Methodology Our validation method involved selecting a bug of interest and recreating the development state at that time by considering only source code revisions that were committed before the bug was closed. We used a determination of the files required to fix the bug to populate the matrices and determine the recommen-dations. We then compared our list of experts to those who had communicated on the bug report, as determined through comments posted to the bug report. Since the communication recorded on a bug report largely discusses the issue underlying the report, the developers involved in this discussion either have 1 http://subversion.tigris.org/, verified 01/08/07. 2 The Jazz system has not yet been released and only limited development data from Jazz itself is becoming available now. Chapter 5. Validation 21 expertise in the area or gain expertise through the discussion.3 To perform this validation, we needed to determine a set of bugs with a sufficient number of recorded comments to infer communication amongst devel-opers and with associated revisions of the source files that "solved" the bug, the resolving change set for the bug. We searched through all of the bugs marked as resolved and fixed for reports with ten or more comments and where' at least five different developers had recorded comments; Appendix B provides a description of how we determined whether an entered comment represented a developer. For the validation, we retained only the comments provided by developers, discarding the others as they are not relevant to providing a lower-bound on the developer communication. We used a standard approach (see Section 5.2) to determine the resolving change set for a bug and ensured that all change sets considered between three and nine files. We chose a range of change set sizes to enable evaluation across a range of situations. EEL is intended to be used as development proceeds. To mimic development in this validation, we used the following process: • Create three subsets of the resolving change set Given the resolving change set for the solved bug, we create three change set sized subsets ( | of the change set, | of the files, and the entire change set) to test how well EEL performs in finding experts given less information than what is needed to fix the given bug. We choose the files for each subset randomly with the constraint that at least one file in each subset must not be an initial revision when the bug was fixed to ensure that we have some history from which EEL can recommend emergent team members. Random subset formation is necessary since we do not know in what order a developer may have modified the files used to solve the bug. • Partition the comments in the bug into three groups We partition the comments in the bug into three approximately equal groups based on the date of the comment. The first group has the oldest comments while the last group contains the newest ones, enabling us to mimic how development occurs. The bugs could have been partitioned based on a date span, but this would have provided a varying sized parti-tion and could have produced poor results due to the frequency and speed of communication that occurred on the report. An example is if we chose a one week time period, one bug may have been fixed in a week, therefore all comments are in one partition. On the other hand, one bug may have taken two years to fix and was only commented on once per month, leav-ing each comment in its own partition. Also, as this example illustrates, the number of partitions would vary per bug and therefore it would be difficult to compare the results. Furthermore, if a comment partition has no developers communicating within it, the entire bug is discarded. When no developers communicate, Communication on a bug report unrelated to the underlying issue is typically moved into another bug report. Chapter 5. Validation 22 the precision would always be 0% and the recall would be incomputable since it would be divided by 0 (see below). To rectify this situation, we chose to discard these bugs from our final dataset. Apply EEL to each combination of comment partitions and- change set subsets We apply E E L to each of the nine cases resulting from combining the comment partitions with the file revision subsets (see Figure 5.1) and evaluate the precision and recall of the recommendations produced by E E L . Specifically, for each case we, 1. find the last revision of each file (in the change set subset) before the earliest comment in the comment partition, 2. apply E E L to the file revisions in the change set subset obtained in the previous step to produce an ordered list of emergent team members, 3. determine who all of the commenters were in the bug partition, form-ing the set of relevant developers (see Appendix B for details on how we determined which comment corresponded to a developer) 4. compute the precision, representing the percentage of correctly iden-tified team members (5.1), and recall, representing the percentage of potential team members correctly identified (5.2). n # Appropriate Recomendations Precision = — Total # Recomendations ,-, I , # Appropriate Recomendations Recall = — : # Possibly Relevant Developers (5.1) (5.2) The # Appropriate Recomendations is the number of developers recommended by E E L that commented on a bug report, the Total # Recomendations is the number of recommendations that E E L made and # Possibly Relevant Developers is the number of developers that communicated on the bug report. In our validation, we also compare E E L against the "Line 10" rule that was used in the Expertise Recommender (ER) [13]. The "Line 10" rule is when the last person that modified the file is considered as the expert in that file. E R extends this approach to rank all of the developers that have modified the file by their last edit date. If multiple files are selected, the expert lists are computed separately for each file and then an intersection of the lists is performed to produce the final expert list. After a preliminary run of the validation on E E L , it was noticed that some of the precision and recall values were 0%. Further investigation revealed that the files that changed to fix a bug may have not been created prior to the dates Chapter 5. Validation 2:\ Comment Partition # 1 Comment # 1 Comment # 2 Comment # 3 Comment Partition # 3 Comment # 7 Comment # 8 Comment # 9 Comment # 10 Change Set Subset # 1 File #2 Comment Partition # 2 Change Set Subset # 2 Comment # 4 File # 1 Comment # S File # 3 Comment # 6 Change Set Subset # 3 File # 1 File # 2 File #3 Figure 5.1: The 9 cases for validation. Lines in this diagram represent a combi-nation of comment partition and change set subset for validation purposes. of earlier comments. This means that E E L was unable to get any historical data for the file since it did not exist and therefore E E L was unable to produce a list of experts. This situation can occur even if the file is not new as of that change set since development is ongoing and the file that needed to be changed was added after the bug was commented on, but before it was fixed. For these cases, we report an optimistic and pessimistic case precision and recall. The optimistic case precision and recall is 100% and it is appropriate since if the file did not exist at the time, producing no experts is correct. On the other hand, since E E L was unable to produce any experts, we can consider the pessimistic case and assume a precision and recall of 0%. These optimistic and pessimistic case values are only used if E E L is unable to produce a list of experts. If E E L is able to produce a list of experts, only one precision and recall value is given and they are computed using equations 5.1 and 5.2 as described earlier. Another thing that we noticed upon the preliminary run of the validation was that the performance of the recommendations of E E L was lower than the "Line 10" rule for some projects. Investigation into this problem revealed that many of the developers contributing to these project committed only a few changes during a small time period then never committed again. Since E E L considers the entire project history, the addition of authors that are no longer active affects E E L ' s recommendations. The "Line 10" rule is not impacted by this case since it ranks experts by their last authorship date, ensuring that the most recent authors are recommended first. In contrast, E E L uses all authors Chapter 5. Validation 24 and related files to determine the recommended set of experts, resulting in the potential for an author that was previously highly active on the project, who has not been active recently, to be recommended over a more recently active developer. To ensure E E L provides relevant recommendations, we apply it to the last twelve months of development history. To be fair in our comparison, we use the same underlying data for the "Line 10" rule. The use of a limited amount of recent data from the project archives has limited effects on the results of applying the "Line 10" rule because this approach-already ranks the most recent activity higher. 5.2 D a t a We used three existing open-source software projects, the Eclipse project 4, Fire-fox5 and Bugzilla 6 in our validation. Eclipse is an open-source platform for integrating tools implemented in Java, Firefox is a popular open-source web browser and Bugzilla is an open-source issue tracking system. As Firefox and Bugzilla are part of the Mozilla Foundation, they use the same version control and issue tracking systems. These projects were chosen because they each have a number of developers who have been active in committing code and bugs in their histories and there is a sufficient amount of data to run the validation af-ter we apply the constraints we outlined in the previous section. Furthermore, these projects use the repository types our infrastructure supported: C V S for source control and Bugzilla for issue tracking. These two data sources are used to populate E E L and validate its recommendations. To form appropriate change sets of Eclipse we obtained an archive copy of the C V S repository from the Eclipse.org archive site 7 and imported it into Subversion using cvs2svn. We performed a similar operation to the Mozilla C V S repository 8 . Cvs2svn is a python script developed along with Subversion (SVN) by the Tigris.org 9 community. This script must be run on the system that the C V S repository currently resides since it directly reads the RCS files. Cvs2svn has many passes that it uses to prepare the S V N repository and to determine the change sets associated with each of the C V S files, ensuring that the imported data is robust and correct. Cvs2svn uses a simple algorithm, similar to that described by Mockus et. al. [14], that inspects the author and log message for each revision of a file and has a notion of time. Using this information, it inspects all of the revisions of all files, grouping revisions that have the same author and log message and that occur within a five minute window of time to create a single change set. If multiple files are changed by the same author and 4http://www.eclipse.org, verified 01/08/07. . 5http://www.mozilla.com/en-US/firefox/, verified 01/08/07. 6http://www.bugzilla.org/, verified 01/08/07 7Eclipse makes archives of the CVS repository available in compressed for at http://archive.eclipse.org/arch/, verified 01/08/07. 8 The Mozilla CVS was obtained using rsync. Rsync is an open-source utility for file transfer, http://samba.anu.edu.au/rsync/, verified 01/08/07. 9http://www.tigris.org, verified 01/08/07. Chapter 5. Validation 25 Table 5.1: Bug and change set statistics per project. Eclipse Firefox Bugzilla Total # change sets 122614 174581 174581 Total # bugs resolved in last 2 years 10013 4918 2148 Total # bugs with at least 5 developers and 10 comments 354 501 291 Total # criteria fitting bugs with reference in change log 182 283 216 Total # bugs with reference and correct change set size 49 70 81 Total # bugs excluded due to no developers in partition 1 2 0 with the same comment but span more than five minutes, multiple change sets are created, hence a single change made to the system may be split into two or more change sets. Furthermore, this algorithm could cause unrelated files to be committed as a single change set, but it was noted in the cvs2svn design notes that this will only happen with insufficiently detailed log messages, like "changed doc" or an empty message, coupled with multiple commits performed quickly[3]. The design notes also note that if a log message is insufficiently detailed, then the change must not be important and there is no real harm if the files are grouped [3]. In selecting bugs for the validation, we-used those marked as closed and fixed within the past two years. These bugs were obtained by downloading the XML version of all bugs that fit this criteria from the respective projects' Bugzilla database. Our selection criteria ensures that the fix is fairly recent, and that it was actually committed to the repository. If the status of a bug was not closed and fixed, it could still be under development, be a duplicate of another bug that has an unknown status, or it may be marked not a bug. Since most open-source projects associate a bug with a single change set, many of them require that the identifying number of the bug that was fixed be entered into the comment of a commit to the version control system. Using this knowledge, we were able to map a bug to a single commit so that we could recreate the development state needed to fix the bug in question. To perform this mapping, we searched each of the log messages obtained from Subversion (one per revision) for a reference to one of the bugs that could be usable for validation. This was done by creating a log of all of the change sets stored in the version control system along with the files that were changed and searching for a string that indicates that it corresponds to a bug fix, for example, "bug 321", "fix 321" or just "321". We then matched logs with a reference to a bug to the bugs that we have determined are appropriate for validation. Any bug that did not have a reference in a log message was discarded from the validation. Table 5.1 provides some statistics on the size of the data sets that were used. The total number of change sets presented in table 5.1 for Firefox and Bugzilla are the same since they are both contained in the same source code repository. Chapter 5. Validation 26 5.3 Resul ts Since E E L can produce a varying number of recommendations, we computed the precision and recall for three different sized lists of potential team members, namely three, five and seven recommendations. These lists were obtained by taking the top parts of the ordered list produced by E E L and the "Line 10" rule. We varied the recommendations to investigate the impact of the size of the recommendations on the performance of E E L . Figures 5.2, 5.3, 5.4, 5.5, 5.6 and 5.7 present a subset of the optimistic precision and recall values using the Eclipse, Bugzilla and Firefox datasets. The presented results represent a more interesting subset of the data that was collected. This subset presents the results for all of the time frames provided by the bug partitions, but only | and | of the files in the change set. Furthermore, the figures present only the results when five developers were recommended. We chose to focus our presentation of results on these cases, as these cases represent a developer looking for expertise prior to a problem being fixed and because the recommendation list is of a reasonable size for a developer to consider. Appendix A provides both the optimistic and pessimistic results of all of the 27 different test cases for each of the projects. The results are presented in box-and-whisker plots. These plots assist in viewing the distribution of the results. The shaded box in the plot represents the second and third quartiles of the data set, whereas the lines extending above and below them, the whiskers, represent the fourth and first quartiles respectively. The large black dot represents-the average value of the data and the line represents the median. Any small unshaded circles that are located above or below the whiskers represent outliers that are well outside the range of common values. On the results graphs, the y-axis represents the percentage value of the precision or the recall. The x-axis separates each of the cases that we are interested in. A label on the x-axis that reads T l , l / 3 means that it represents the first bug partition (TI) and | of the files in the subset (1/3). Table 5.2 shows the overall average optimistic precision for both E E L and the "Line 10" rule for all three of the projects used in the validation. Table 5.3 presents the average optimistic recall for the three tested projects. Figures 5.2 and 5.3 present the optimistic precision and recall values for Eclipse. The overall average optimistic precision and recall of E E L for this project are 37% and 49% respectively, compared to 28% and 35% for the "Line 10" rule. Figures 5.4 and 5.5 present the optimistic precision and recall values for Bugzilla. The overall' average optimistic precision and recall of E E L are 28% and 38% respectively, compared to 23% and 28% for the "Line 10" rule. Figures 5.6 and 5.7 present the optimistic precision and recall values for Firefox respectively. The overall average optimistic precision and recall of E E L are 16% and 21% respectively, compared to 13% and 16% for the "Line 10" rule. In each of the three projects tested, E E L produces higher precision and higher recall than the "Line 10" rule. On average, in 88% of the 27 different test cases for each of the three projects, E E L produced a higher precision and Chapter 5. Validation 27 Table 5.2: Optimistic average precision. Project E E L Line 10 Eclipse 37% 28% Bugzilla 28% 23% Firefox 16% 13% Table 5.3: Optimistic average recall. Project E E L Line 10 Eclipse 49% 35% Bugzilla 38% 28% Firefox 21% 16% recall than the "Line 10" rule. This shows that E E L produces better results than the "Line 10" rule. It is an open question whether these precision and recall values are sufficient to create an effective tool for recommendations. We are optimistic that an effective tool can be based on this approach because McDonald's study found that people working on the project generally agreed with the recommendations provided [10]. Knowing that the "Line 10" rule performs well when strict testing is performed, we believe that the our results show that E E L provides better expertise recommendations than the "Line 10" rule. Furthermore, there were some cases where E E L was able to produce a list of experts when the "Line 10" rule recommended an empty list. Recommending an empty list of experts does not help developers find expertise, forcing them to modify the information that they are interested in until they find an expert that might be of interest. E E L always produced a recommendation if there was history in the repository for it to use. For Eclipse, 6.5% of the cases we tried resulted in the "Line 10" rule being unable to produce a result when E E L could. For Bugzilla, this occurred 15.0% of the time, and Firefox 14.9%. The "Line 10" produces an empty recommendation list since it performs an intersection of the authors when there are multiple files in the change set. This situation can occur when the files are relatively new, or new dependencies have been added within the files that is not reflected within the history of project. The difference between the optimistic and pessimistic values gives an insight into the number of times that there was insufficient history for either E E L or the "Line 10" rule to produce a recommendation. Chapter 5. Validation 28 Test Number • EEL • LINE 10 Figure 5.2: Eclipse optimistic precision. I EEL * LINE 10 Figure 5.3: Eclipse optimistic recall. Chapter 5. Validation 29 0 o 0.0 ... 1 ll'l II1 Ill T1.1/3 T1.2/3 T2. 1/3 T2. 2/3 T3. 1/3 T3,213 Test Number • EEL • LINE 10 Figure 5.4: Bugzilla optimistic precision. T1. 1/3 T1.2/3 T2. 1/3 T2.2/3 T3. 1/3 T3.2/3 Test Number • EEL • LINE 10 Figure 5.5: Bugzilla optimistic recall. Chapter 5. Validation 100 95 90 70 85 60 in OI EE re 0 3 B 5 ° 5 45 BL 40 0 o 0 0 o 0 o o 0 T3. 1/3 T3.2/3 Test Number ! EEL • LINE 10 Figure 5.6: Firefox optimistic precision. Test Number EEL is LIME 10 Figure 5.7: Firefox optimistic recall. Chapter 5. Validation 31 5.4 T h r e a t s Several factors could affect the construct, internal and external validity in our study of EEL. 5.4.1 Construct Validity Construct validity considers whether the measures used in a study represent the concept that was being studied. A potential threat to the construct validity of our validation is how we determined the experts to whom we compare the recommendations made by the two approaches. We used the developers who commented on the bug report as the experts for the area of the system in question. However, it is possible that the comments that were posted to the bug report were not related to the bug or were not technical in content. Either situation would mean that who we consider as experts may not actually be experts in that part of the implementation of the system. As we described in section 5.1, these situations are unlikely given how the bug reporting system is used in practice. In the open-source community, bug reports are used as a collaboration device to track the technical communication surrounding the bug report. For instance, in the open-source communities we studied, if unrelated issues arise in a report, they are generally continued within a new bug report or through other communication means. The result is that the commenters on the bug report are potential experts since they are commenting on the technical aspects of the bug. Our use of the bug report comment data is a lower bound on the commu-nication that occurred during the development of the system. As a result, we may not have a complete list of the experts, or a ranking of the importance of each of the developers with respect to a bug. A user study where developers could use their knowledge regarding expertise and provide a more detailed view of the correctness of EEL would have better construct validity. The validation presented here is intended to be a preliminary study to show the effectiveness of E E L so that it can be deployed into a development team. Another potential threat to the construct validity of our study is that the version control system may contain non-technical changes to the system. These kinds of changes would mean that a developer committing a part of the sys-tem made a change that did not require knowledge of the area (i.e., changing the licence agreement that appears at the top of each file). As we previously mentioned, these types of commits to the system are generally large in size, and due to this, E E L ignores change sets with more than 50 related files. This approach tries to ensure that these untechnical changes to the system are not used in the expertise recommendation. Furthermore, since E E L uses the fre-quency of the commits as a factor in recommending experts, if a few of these commits are included, there is a high probability that they will not affect the recommendations. . Chapter 5. Validation 32 5.4.2 Internal Validity Internal validity in a study ensures that there was a causal relationship between the method being studied and the results. The username to e-mail mappings could threaten the internal validity of the evaluation of EEL. The mapping between e-mail and username is a difficult problem and has no easy solution. Since we are comparing the performance of E E L to the performance of the "Line 10" rule, this should not affect the outcome. Both of the methods use the mappings similarly and compare to the same set of potential experts. This means that if one of the mappings is incorrect, it will affect both systems equally, therefore, not affecting the comparison between the two. 5.4.3 External Validity External validity studies the generalizability, or applicability, of the results to other situations. One potential threat to external validity is that we only con-sidered open-source projects. This could be an issue since the processes used in a corporate environment might be different than that of an open-source com-munity. As the projects that we studied involve professional developers and the systems developed are of high-quality, we believe that the processes used and the structure of the projects are similar to those in a corporate situation. Another threat to external validity is the size of the teams that we inves-tigated. We believe our approach is better suited to large teams and targeted large teams in the evaluation with both of the systems having between 200 and 800 developers committing. Finally, the use of mature projects could be a threat to the generalizability of the validation. We feel that this is not a threat since any project that is new does not contain the information that is needed to provide recommendations. There is no easy way to test the validity of a recommendation tool on a new project since the project history is non-existent, therefore no information can be collected about the experts of the system. Furthermore, a recommender would produce moot results since only a few people have edited the files, meaning that they are the creators of that file and therefore the experts. On a new project, a profile-based expertise recommender would perform the best since developers can list their area of expertise. 33 C h a p t e r 6 Discussion In this chapter, we consider both extensions and limitations to EEL, as well as, describe the next steps in evaluating the approach. 6.1 Other Sources of Information There are several different data sources that EEL could use to mine information for producing the emergent team recommendations other than source revision information, including bug reports and the developer's own activity. We chose to use revision information because our motivating use case is to recommend team members with expertise on the code. The best information for this is developers who have demonstrated work on the code. Bug report information may be useful for augmenting the source revision information. To do this, a few changes would need to be made to EEL. First, EEL would need to understand the bug that the user is currently working on and have the ability to extract data from the bug tracking system. Second, a mapping between the source control repository e-mail and username and the bug tracking systems' e-mail and username would be needed so that the users' expertise rankings could be unified within EEL. If using a tool like Jazz, this mapping is not needed since the names are unified throughout all of the compo-nents of the software life cycle. For E E L to properly utilize bug data, it needs dependency information to gather history of past bug fixes, but this information is sparse and many times non-existent since developers do not properly record this information. Some tools are being developed to attempt to automatically determine bug similarity for finding duplicate and dependant bugs, but these technologies are not mature enough to reliably produce correct results .that could be used for expertise locating (e.g., [5]). Alternatively, a developer's interaction with the system, similar to that col-lected by Mylar[7], could be helpful in two ways. First, Mylar's task contexts capture information about which files a developer referred to when performing a task. Files to which a developer referred a lot may be also areas of the system in which a developer is knowledgeable and for which the developer could be considered a member of the emergent team for that file. Second, Mylar's task information could be useful to maintain EEL's matrices on a per task basis. This would mean that when a user changes the task that they are working on, they would start with an empty list of experts until they begin investigating the code. This would ensure that the list of experts would be directly related to that Chapter 6. Discussion 34 task and not the previous one. However, we did not implement this since the number of related files is large, it will quickly clear the matrices, and therefore the expert list, as the user works. A drawback of this approach is that when a task is started there will be no information to recommend experts, leading to less recommendations when a developer may most need a recommendation, early on in a task's life cycle. 6.2 Using Emergent Team Information There are some other potential uses for emergent team information other than recommending experts. Emergent team information could also be used to look at churn or determine the load on a particular developer on a project. One use of emergent team structure is to examine the churn of a project or component. Churn is when an entire team (or most of a team) continues to change over time. This means that the team is always composed of new developers that must learn the area of the system, therefore, resulting in a lack of experts for that part of the system. A project that has little churn normally means that the development team is stable and contains knowledge of the project. A manager could use this information to determine problem areas in a project and redistribute developers to fix the problem. By periodically determining the emergent team for an area of a system, one could compare the current team with previous team snapshots to determine the. size or frequency of the change on the emergent team. If a large number of developers on a team leave or if the team changes frequently, it could indicate a problem. Emergent team structure could also be used to determine the load on a developer. A manager could .use this information to reduce the load on one developer by reassigning work to other developers. To determine the load of a developer, the emergent teams of different areas of a project could be analyzed. If a developer is contained in a larger number of teams than other developers, this would indicate that they probably have a higher load and are key to the success of the project. 6.3 Future Evaluation The next step in evaluating EEL is to deploy the tool into an active development project. Ideally, this project would have a relatively large code base (e.g., one million lines of code), follow some agile practices and communicate primarily through electronic means. We would like the team to follow some agile practices so that EEL is able to be useful and not recommend developers that are known to be experts by members of the team. It would be beneficial if the communication was done through electronic means so that we could track and analyze the communication that was initiated through EEL. The focus of this evaluation should be on both the correctness of EEL's recommendations and the users' experience. Data should be collected on an on-Chapter 6. Discussion 35 going basis when the tool is deployed. Information about the frequency of using E E L to make a recommendation, along with the frequency of communication initiated from EEL could be collected and analyzed. To further ensure accuracy, a more formal study could be performed in the likes of the one performed by McDonald[10]. This study involved having users rank a list of developers that could be experts on the system in question. The results provided by the users are then compared to the tools recommendations to determine the accuracy of the tool. This second study could be used to supplement the results collected from the deployment of EEL, and provide statistical evidence for the performance of EEL. Second, the experience of using EEL should be evaluated. The goal of E E L is to provide the simplest way to display the expert recommendations as well as how communication can be initiated. This evaluation could be run in parallel with the correctness study when EEL is deployed. Users could compare the usability of E E L to their previous methods of expertise location and communi-cation tools. Furthermore, evaluation could involve a separate study that tests the current way that E E L provides the list of experts to another system, such as, manually configured buddy lists. Finally, since we discovered that the performance of E E L is highly dependant on the amount of history data that it uses, it would be beneficial to investigate this further. This would require testing E E L using different lengths of time to examine in the software repository. We chose twelve months to increase the recency of the data that was being used, but using more or less time may produce better results. We recognize that there is a high probability that this factor is dependant on the project used. When inspecting the Eclipse results, using the entire history or the last twelve months produces similar results with EEL, whereas with the Mozilla projects, there was a large change in the results. It would be beneficial if there was an automated way to determine this value on a per-project basis so that the customization could be made available to EEL. 6.4 Limitations A limitation of EEL's approach is that it is unable to easily work with many traditional version control systems like CVS and RCS. This limitation is due to these systems maintaining commit information on a per file basis; therefore, not containing any information pertaining to the files that changed along with it. This means that we are limited to newer version control systems such as Subversion and Jazz since they support atomic commits across a number of files. Tools and methods exist for extracting change sets from CVS, but it is infeasible to run this every time data is mined for a file. As an alternative, an external tool could be periodically run to extract this information, but this is an intensive operation and therefore would create the need for a server based approach which we are attempting to avoid. Many open-source projects still use CVS, but Subversion is gaining popularity and some major open-source projects (like Apache and Gnome) have either migrated or have plans to migrate to using Chapter 6. Discussion 36 this new repository system in the near future. Another limitation to EEL is that if a new developer is added to the team, but they are already an expert, there is no support to ensure that this person is correctly recommended. If a client-server approach was used, a simple skew or replacement value could be added to augment the recommendations to ensure that this new developer is recommended. This method could also be used if a developer leaves the team. To solve this within EEL, the ability to personalize the recommendations could be added. One personalization could be the ability to substitute a expert who is recommended by EEL with a different expert specified by the user. This could be done to replace a developer who left the project with a new hire. Another use of this type of personalization would be to augment the recommendations based on the social structure of the team. A developer may prefer to talk to an expert that they know over another member that has similar knowledge. Another way to solve this limitation would be to weigh the recent development activity heavier than older information. This would mean that a developer that has worked on a file more recently could be rated higher even if they are new to the team. To implement this mechanism, an in depth experiment would need to be performed to determine if it is feasible. 37 Chapter 7 Summary To build successful complex software systems, software developers must collabo-rate with each other at all stages of the software life-cycle. Current development tools facilitate this collaboration by integrating communication tools, such as chat and screen sharing, within the development environment. By integrating these tools, it has made it easier for developers to communicate, but as the composition of software teams becomes increasingly dynamic, it may not be straightforward for a developer to keep a description of colleagues on the many teams in which she may work up-to-date. This leaves the developer to determine with whom he should collaborate in a particular situation, forcing the user to have some knowledge of who has expertise on particular parts of the system. E E L mitigates these problems by determining the composition of the team automatically so that developers do not need to spend time configuring mem-bership lists for the many teams to which they may belong. This is done by using the context from which the developer initiates communication combined with the project history to produce a recommendation of experts related to the area the developer is currently working. Using an automated validation and historical data from three different open-source projects, we found that EEL produces higher precision and higher recall than the "Line 10" rule. The results are promising but E E L still needs further validation using a team of developers due to the limited availability of expertise information. 38 Bibl iography [1] John Anvik, Lyndon Hiew, and Gail C. Murphy. Who should fix this bug? In Proceeding of the 28th international conference on Software engineering, pages 361-370, 2006. [2] Marcelo Cataldo, Patrick Wagstrom, James Herbsleb, and Kathleen Carley. Identification of coordination requirements: Implications for the design of collaboration and awareness tools. In Proceedings of the 2006 20th anniver-sary conference on Computer supported cooperative work, pages 353-362, 2006. [3] cvs2svn Community. How cvs2svn Works. http://cvs2svn.tigris.org/svn/cvs2svn/trunk/design-notes.txt, 2006. [4] James .D. Herbsleb and Deependra Moitra. Global software development. IEEE Software, 18(2):16-20, Mar /Apr 2001. [5] Lyndon Hiew. Assisted detection of duplicate bug reports. Master's thesis, University of British Columbia, 2006. [6] Jim Highsmith and Alistair Cockburn. Agile software development: the business of innovation. IEEE Computer, 34(9):120-127, Sept 2001. [7] Mik Kersten and Gail C. Murphy. Using task context to improve program-mer productivity. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering, pages 1-11, 2006. [8] Roger Lewin and Birute Regine.. Complexity and business success. http://www.psych.lse.ac.uk/complexity/Seminars/1999/report99oct.htm, 1999. [9] Greg Madey, Vincent Freeh, and Renee Tynan. The open source software development phenomenon: An analysis based on social network theory. In Americas conf. on Information Systems (AMCIS2002), pages 1806-1813, 2002. [10] David W. Mcdonald. Evaluating expertise recommendations. In GROUP '01: Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting Group Work, pages 214-223, 2001. Bibliography 39 [11] David W. McDonald. Recommending collaboration with social networks: A comparative evaluation. In Proceedings of the SIGCHI conference on Human factors in computing systems, pages 593-600, 2003. [12] David W. Mcdonald and Mark Ackerman. Just talk to me: a field study of expertise location. In CSCW '98: Proceedings of the 1998 ACM conference on Computer supported cooperative work, pages 315-324, 1998. [13] David W. Mcdonald and Mark S. Ackerman. Expertise recommender: a flexible recommendation system and architecture. In Proceedings of the 2000 ACM conference on Computer supported cooperative work, pages 231-240, 2000. [14] Audris Mockus, Roy T . Fielding, and James D. Herbsleb. Two case studies of open source software development: Apache and mozilla. A CM Transac-tions in Software Engineering and Methodology, l l(3):l-38, 2002. [15] Audris Mockus and James D. Herbsleb. Expertise browser: a quantitative approach to identifying expertise. In ICSE '02: Proceedings of the 24th International Conference on Software Engineering, pages 503-512, 2002. [16] Ramon Sanguesa and Josep M. Pujol. Netexpert: A multiagent system for expertise location'. In International Joint Conference on Artificial In-telligence (IJCAI) Workshop on Organizational Memories and Knowledge Management, pages 85-93, 2001. [17] Xiaodan Song, Belle L. Tseng, Ching-Yung Lin, and Ming-Ting Sun. Ex-pertisenet: Relational and evolutionary expert modeling. In Proceedings of the Tenth International Conference on User Modeling, pages 99-108, 2005. [18] Dawit Yimam-Seid and Alfred Kobsa. Expert finding systems for organi-zations: Problem and domain analysis and the demoir approach. Journal of Organizational Computing and Electronic Commerce, 13(l):l-24, 2003. [19] Annie T . T . Ying, Gail C . Murphy, Raymond Ng, and Mark C. Chu-Carroll. Predicting source code changes by mining change history. IEEE Transac-tions on Software Engineering, 30(9):574-586, Sept. 2004. 40 Appendix A Complete Results Figures A . l , A.2, A.3, A.4, A.5, A.6, A.7, A.8, A.9, A.10, A . l l and A.12 present detailed results of the validation of EEL. Each of the figures presents 27 differ-ent cases that were tested during the validation of EEL. Each of the test cases represent a unique combination of the bug comment partition, the size of the change set used to make a recommendation, and the number of recommenda-tions made. A . l describes the combinations for each of the test cases. Section 5.3 has a detailed description of how to read the box-and-whisker diagrams presented here. Appendix A. Complete Results 41 Table A . l : Mapping of test case number to unique combination of bug comment partition, size of change set and number of recommendations. Test Case Number Data Combination 1 Comment Partition 1, 1/3 files, 3 recommendations 2 Comment Partition 1,1/3 files, 5 recommendations 3 Comment Partition 1, 1/3 files, 7 recommendations 4 Comment Partition 1,2/3 files, 3 recommendations 5 Comment Partition 1,2/3 files, 5 recommendations 6 Comment Partition 1,2/3 files, 7 recommendations 7 Comment Partition 1, all files, 3 recommendations 8 Comment Partition 1, all files, 5 recommendations 9 Comment Partition 1, all files, 7 recommendations 10 Comment Partition 2, 1/3 files, 3 recommendations 11 Comment Partition 2, 1/3 files, 5 recommendations 12 Comment Partition 2, 1/3 files, 7 recommendations 13 Comment Partition 2, 2/3 files, 3 recommendations 14 Comment Partition 2, 2/3 files, 5 recommendations 15 Comment Partition 2, 2/3 files, 7 recommendations 16 Comment Partition 2, all files, 3 recommendations 17 Comment Partition 2, all files, 5 recommendations 18 Comment Partition 2, all files, 7 recommendations 19 Comment Partition 3, 1/3 files, 3 recommendations 20 Comment Partition 3, 1/3 files, 5 recommendations 21 Comment Partition 3, 1/3 files, 7 recommendations 22 Comment Partition 3, 2/3 files, 3 recommendations 23 Comment Partition 3, 2/3 files, 5 recommendations 24 Comment Partition. 3, 2/3 files, 7 recommendations 25 Comment Partition 3, all files, 3 recommendations 26 Comment Partition 3, all files, 5 recommendations 27 Comment Partition 3, all files, 7 recommendations 1 2 3 4 5 8 7 S 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Test Number EEL • LINE 10 Figure A . l : All Eclipse optimistic precision. 4 5 8 7 8 9 IB 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 28 27 Test Number • EEL • LINE 1 0 Figure A.2: All Eclipse pessimistic precision. 2 3 10 11 12 13 14 15 18 17 18 19 20 21 22 23 24 25 28 27 Test Number • E E L • L I N E 10 Figure A.3: All Eclipse optimistic recall. 1 2 3 4 5 8 10 11 12 13 14 15 16 17 18 1B 20 21 22 23 24 25 26 27 Test Number EEL • LINE 10 Figure A.4: All Eclipse pessimistic recall. 8 0 1D 11 12 13 14 15 16 17 18 18 20 21 22 23 24 25 26 27 Test Number a EEL • LINE 10 Figure A.5: All Bugzilla optimistic precision. 2 3 4 5 8 10 11 12 13 14 15 16 17 18 10 20 21 22 2 3 2 4 2 5 28 27 Test Number • EEL • LINE 10 Figure A.6: All Bugzilla pessimistic precision. 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Test Number EEL • LINE 10 Figure A.7: All Bugzilla optimistic recall. 1 2 3 4 5 8 7 8 8 10 11 12 13 14 15 18 17 18 19 20 21 22 23 24 25 26 27 Test Number EEL m LINE 10 Figure A.8: All Bugzilla pessimistic recall. 2 3 10 11 12 13 14 15 18 17 18 19 20 21 22 23 24 25 28 27 Test Number EEL • LINE 10 Figure A.9: All Firefox optimistic precision. Q 1 2 3 4 5 8 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Test Number EEL • LINE 10 Figure A. 10: All Firefox pessimistic precision. •• J, H 1 2 3 4 5 8 7 I 0 10 11 12 13 14 15 18 17 18 10 20 21 22 23 24 25 28 27 Test Number • EEL • LINE 10 Figure A . l l : All Firefox optimistic recall. In 1 2 3 4 5 6 7 3 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Test Number • EEL • LINE 10 Figure A. 12: All Firefox pessimistic recall. in CO 54 Appendix B Name Mapping Method In the validation of EEL we needed to determine the set of developer's working on the system. At first, this step would seem to be simple: match the e-mail addresses used in the bug repository to the usernames from the source code repository. We needed to map e-mail addresses to a usernames since the vali-dation required that we compare information between the two different systems with disjoint username schemes. Bugzilla requires users to use their e-mail ad-dress as their login name and the source code repository has an independent set of usernames that are normally not based on e-mail address. Unfortunately, as described elsewhere [1], this mapping is non-trivial. To produce an initial map-ping, we applied a longest substring matching algorithm to the usernames and e-mail addresses. After attempting to automatically determine the mapping, the entire list was inspected and completed by hand. This approach produced a unique one-to-one mapping for many e-mail and username and e-mail ad-dresses but three situations remained: 1) no mapping could be determined, 2) a single username could map to multiple e-mail addresses (one-to-many) and 3) multiple e-mail and username could map to one or more e-mail addresses (many-to-many). The first case occurred only with a small subset of names and after some investigation, we determined that the users had not been active for at least three years, and determined that it was acceptable, for our situation, to discard these users from the recommended list of experts. We discarded this information since we were unable to validate the correctness of the recommendation if one of these users was suggested by EEL. The second case occurs when users changed their e-mail address or used a different address based on the parameters of the bug report (i.e., the product). This case did not have to be handled specially since EEL does not use the e-mail addresses, but the e-mail and username, therefore multiple e-mail addresses map to a single username. The third case exists since both projects changed their CVS username scheme after the project was started. Eclipse was originally developed by IBM, and when this transition occurred, many of the developers continued to work on the product, but were given new e-mail and username that followed the Eclipse standard. Mozilla decided to change the CVS usernames to be the e-mail ad-dress of the committer since many of the changes were submitted by patches and this was the easiest way to track who had made the change. To solve the problem of the many-to-many mapping, we chose one of the usernames to be the "master" username. This username is the one to which all of the e-mail ad-Appendix B. Name Mapping Method 55 Table B.l: E-mail to CVS username mapping statistics per project. Eclipse Mozilla 1-1 Username to E-Mail Mappings 142 •( 82.1%) 493 ( 62.1%) 1-N Username to E-Mail Mappings 3 ( 1.7%) 103 ( 13.0%) N - M Username to Email Mappings 18 ( 10.4%) 178 ( 22.4%) Usernames With No Mappings 10 ( 5.8%) 20 ( 2.5%) Total Number Usernames 173 (100.0%) 794 (100.0%) dresses associated with that username are mapped. Since the other usernames still existed within the software repository, we created a second mapping that mapped username to the "master" username if one existed. The master user-name is used as if it was a single username mapped to multiple e-mail addresses. In this way, we ensured that the information mined from the software repository was consistent with the information that we were using from the bug reports and that we did not loose any pertinent information. Table B. l provides the statistics of the username to e-mail mappings for each project. Appendix C provides a detailed list of all of the mappings used for the validation of E E L for each of the projects. 56 Appendix C C V S to Bugzi l la Name Mappings C . l Eclipse The following tables provide a detailed listing of the name mappings that were used in the validation of EEL for Eclipse. Table C . l contains all of the unique one-to-one mappings of username to e-mail address. Table C.2 contains the mappings where a single username mapped to multiple e-mail address, the du-plicate usernames, as well as the usernames that we were unable to map. Table C. l : Eclipse one-to-one username to e-mail mappings. One-to-one Mappings akiezun=>akiezmi@mit..edu toiTes=>alexandre. torres@gmail.com aweiuand=>atidre.wemand@cli.ibm.com acovas=>andrea_eovas@ca.ibiii.com anicfer=>anicfer@ca.ibm.com ahunter=> anthonyh@ca.ibm.com yamamikn=> ArPuhikoYamaiiaka@hotmail.com bbaumaii=>haumanbr@iis.ibm.coin bbawngmi=> bemio_baumgartner@cli.ibm.com dbirsan=>birsan@ca.ibm.com bbokowski=>Boris JBokowski@ca.ibm.com briany=> Brian_Young@ca.ibm.com bshingar=> bshingar@ca.ibm.com btripkovic=>btripkov@ca.ibm.com carolyn=> Carolyn_MacLeod@ca.ibm.com cmckillop=>cdm@qnx.com celek=>cclek@ca.ibm.com cgoldthor=> ego ld@us.ibm.com schan—>cl tanskw@ca.ibm.com cwong= > chcrie. wong@gmail .com cmarti=>du'isrof_marti@ch.ibm.com ccoriiu=>christoplie_coniu@ca. ibni.com cknaus=> Claude _Knaus@oti.com cmclarcn=>csmclaren@andelain.coni curtispd=>cnrtispd@ca.ibni.com dmegert=>daiiieljnegert@ch. ibm.com dswaiLSon=> Darin_Swanson@us.ibm.com dwright.=>Darm_Wright@ca. ibm.com daved=>daved@dis-corp.com dorme=>daveo@asc-iseri es.com daudel=>david_audel@fr. ibm.com dspriiiggay=->david_springgay@ca. ibm.com davids=>davi(lms@ca.ibm.com drobeits=>dcaiiJoberts@ca.ibm.com dwilsoii=>debbie_wilson@ca.ibm.coni deboer= > deboer@ca.ibm .com dejan=>dejan@ca. ibm.com jdeupree=>deupree@us.ibm.com dbaeumer=>dirk Jjaeumer@di.ibm.com dj=>dj Jioughton@ca.ibm.com eidsness=>eclipse@jfront.com ]lioiuher=>eclipse@skyluc.org j s z m " s z e w s l d = > t x ; l i p s e @ s z u i ' S z c w s k i . c o m tcicher=>eclipse@tom.eicher.name eduardo=>eduardo_per eira@ca.ibm.com emoffatt=>emofEatt@ca. ibm.com egamma=>erich_gamma@ch. ibm.com bfam=>fam@ca.ibm.com flieidric=> feli pe_hei dri cli@ca.ibm. com ffusier=>frederic_fusier@fr.ibm.com gheorghe=>gheoi"ghe@ca.ibm.com ginendcl=>gmendel@us .ibm.com ggayed=>grant_gayed@ca.ilim.com greg=>greg_ad ams@ca.iliin.com giumar=>guniiar@wagei iknedit.org liar grave=>hargrave@us.ibm.com i k h e l i f i = > i n e s @ v t . e d u jlebrun=> Jacques J e b n m @ o t i .com jam es=> James_Moody@ca.ibm.com janeklb=> janeklb@ca.ibin.com j aburns=> jared _bur ns@us. ibm. com jbunis=>jar edburns@acin.org jlemieux=>jean-michol J e m i e u x @ c a . i b m . c o m jed=> j ed. ander son@genui tec .com jbrown=> jefE_browii@oti.com jefE=>jeff_mcaffer@ca.ibm.com jlaimeluc=> Jerome Jaimeluc@fr.ibm.com jfogell=>jfogeLl@us .ibm.com jgarms=> jgarms@bea.com jdesrivieres=> jim_des_rivieres@ca.ibm.com johna=> John _arthorne@ca.ibm.com jolmw=>.Iolm_\Viegand@us .ibm.com kmaetzel=> kai-uwe_maetzel@ch. i bm. com gkarasiu=>karasiuk@ca.ibm.com karice=> Karice_McIntyre@ca.ibm.com kcornell=> kconiell@ca.ibm.com kdkelley=>kdkelley@ca.ibm.com dkclm=>kehn@us.ibm.com kjolmson=>kent_jolmson@ca. ibm.com kevinh=>Kevin_Haalaiid@ca.ibm.com keviniii=>Kevin_McGuire@ca.ibm.com khalsted=>khalsted@ca. ibm.com khorne=> kimJiorne@ca.ibm.com kmoir=> kmoir@ca.ibm.com kradlofF—>knut_radloff@iis.ibm.com , kkolosow=>konradk@ca.ibm.coin krbarnes=>krbarnes@ca.ibm.com airvine=>lenar Jioyt@yalioo.com lkcm m el=> lkemmel@il.ibm.com lparsons=>lparsons@ca.ibm.com lkues=>lyime_kues@us.ibm.com inhuebscher=> Markus_Huebscher@oti.com mkeller=>markus_keller@cli.ibm.com maesclilimaim=>martiii_aesclilimaim@cli.ibm.com mhatem=> Matthew _Hatem@notesdev.ibm.com mdaniel=> maxime_damel@fr.ibm.com in elder=> mdelder@us.ibm .com mfaraj=> mfaraj@ca.ibm.com mremiie=> Micliael_Reniiie@ca.ibm.com nival ent.a=> Michael.Valenta@ca.ibm.com mcq=>Mike_Wilso n@ca.ibm.com mvoroiiiii=>Mikliail. Voronin@intel.com mkaufman=>mkaufman@bea.com mpawlowsk=> mpawlow@ca.ibm.com mvanmeek=>mvm@ca. ibm.com nick=>nick_edgar@ca.ibm.com obcsedin=->obcsedin@ca.ibm.com othoniaim=> 01ivier_Tliomann@ca.ibm.com prapicau=>pascal_rapicault.@ca.ibni.com pdubroy= > Patrick_Dubroy@ca.ibm .com pmulet=> philippe_mulet@fr.ibm.com pwcbster=>pwebster@ca. ibm.com rdiaves=>rafaeLchaves@ca.ibm.com randyg= > R andy _G iffen@oti .com rpcretti—> rodrigo_peretti@ca.ibm.com semion=>semion@il.ibm.com silenio=>Silenio_Quart i@ca.ibm.com skaegi=>simon.kaegi@cogiios.com sarsenau=>sinion_arsenault@ca.ibm.com sdimitro=> so ni a_dimitrov@ca.ibm.com steve=>steve jiorthover@ca.ibm.com ssarkar=>simiit.sarkar@hp.com sfranklin=>sus an Jranklin@us.ibm.com sxenos=> sxenos@gmail .com tmaeder=>t.s.maeder@liispeed.ch thanson= > thaiLson@bea.com tbay=> till_bay@oti.com tellison=>Tim_Ellison@uk.ibm.com twatson=>tjwat.so n@us.ibm.com twidmer= > tobias_widmer@cli .ibm .com tod=> Tod _Creasey@ca.ibm.com tyeimg= > tyeung@bea. com veronilca=> veronikajrvine@ca.ibm.com vlad=> vliirsl@hotmail.com wmelhem=> wassiinm@ca.ibm.com droy=> webmaster@eclipse.org wharley=>wharley@bea.com windiest=> Windiest@uk.ibm.com Table C.2: Eclipse one-to-many, duplicate and unknown username to e-mail mappings. One-to-many Mappings Duplicate Username Mappings Unknown Usernames bbiggs=>bbiggs@ca.ibm.com bbokowsk=>bbokowski fbelling bbiggs=> billy, biggs@eclipse.org chrix=>ccornu lchui dpollock=>douglas.pollock@gmail.com darins=> dswanson malice dpollock=>douglas.pollock@magma.ca darin=>dwright ptff dpollock=>pollockd@ca.ibm.com droberts2=>droberts seven ebb=>ed.burnette@gmail.com jszursze=>jszurszewski wadman ebb=>ed.burnette@sas.com erich=>egamma wchoi jeem=>jdesrivieres wmtest kent=>kjohnson Jonathan knutr=>kradloff oconstan lynne=>lkues maeschli=> maeschlimann oliviert=>othomann rodrigo=>rperetti ssq=>silenio sdimitro2=>sdimitro ptobias=>twidmer jeromel=>j lanneluc Appendix C. CVS to Bugzilla Name Mappings 59 C.2 Mozilla The following tables provide a detailed listing of the name mappings that were used in the validation of E E L for Mozilla. Tables C.3, C.4, C.5, C.6 and C.7 contain all of the unique one-to-one mappings of username to e-mail address. Tables C.8, C.9 and C.10 contain the mappings where a single username mapped to multiple e-mail address. Tables C . l l and C.12 contains the duplicate user-names. Finally, table C.13 has all of the usernames that we were unable to map. Table C.3: Mozilla one-to-one username to e-mail mappings. One-to-one Mappings aaronleventhal%moonset.net=>aaron leventhal@moonset.net aaronr%us.ibm. com=>aaronr@us. ibm.com ajsclHilt%verizori.net=>ajsdiu!t@verizon.net akhii.arora%sun.com=>akhil.arora@sun.com akkana%netscape.com=> akkana@nelscape.com akkziIla%sliallowsky.coni=>akkzilla@shallowsky.com alex%croczil!a.com=>alex@cro czilla.com atftx.fritze%croc'odilf>dips.(:oni = >atcx.iritze@crocodi]i>dips.corn alexci. volkov.bugs%smi.com = >a lexei.volkov.bugs@sun.com a lexsavulov%netscape.com=>a.l ex savulov@netscape.com alfred.peng%sun.com=>al tied, peng@sun.com aUa%lysator.tiu.se=>alla@lysator.liu.se allan%beauibi.r.dk=> allan@beaufour.dk amardare%qnx.com—>arnardare@qnx.com amasri%netscape. com=> amasri@netscape.com amiisil%netscape.com=>amusil@netscape.com anatoliya%netscape.com = >anatoliya@netscape.com andreww%netscape.com=>andrew\v@netscape.com ann.adamcik%sun.com=>ann .adamcik@sun.com annie.su llivan%gmail.com = >an nie.sullivan@gmail.com anton.bobrov%>sun. com=>anton.bobrov@sun.com antonio.xu%sun.com=>antonio.xu@sun.com arielb%nets(:ape.com=>a rielb@netscape.com arielb%rice.edu=>arielb@rice.edu arik%netscape.com = >arik@netscape.com a r o i i g t h o p h e r 7 o l i z a r d l a n d . n e t . = >arougthopher@lizardland.net arvid%quadrone.org=>arvid@quadrone.org ashishbhatt%netscape.com=> ash ishbhatt@netscape.com ashuk%eng.sun.com=>as huk@eng.sun.com atremon%elansoftware.com=>atremon@elanso ftware.com attinasi%netscape.com=>attinasi@netscape.corn av%netscape.cbm—> av@netscape.com axel%pike.org—>axel@pike.org badami%netscape.com=> badami@netscape.com barnboy%trilobyte.net=> barnboy@trilobyte.net bear%code-bear.com=> bear@code-bear.com benjamin%smedbergs.us=>benjamin@smed bergs, us bent.mozilla%gmail.com=>bent.mozilla@gmail.com bernd.mielke%snafu.de=> bernd.mielke@snafu.de bliartOO%yahoo.com=> bltartOO@yahoo.com bishakhabanerjee% net scape, com=> btshakhabanerjee@netscape.com bjorn%netscape.com=> bjorn@netscape.com BlakeR.1234%aol.com=>BlakeR 1234@aol.com blakeross%telocity.com = >blakeross@telocity.com blythe%netscape.com—>bl ythe@netscape.com bmlk%gmx.de—>bmlk@gmx.de lmesse%netscape.com=> bnesse@nelscape.com bolian. yin%sun. com — > bolian.yin@sun.com braddr%puremagic.com=>braddr@ptiremagic.com Bradley.Iunk%cinci.rr.com=> Bradley.! unk@cinci.rr.com brate.l%lysator.liu.se=> bratell@lysator.liu.se brettw%gmail.com=>brettw@gmail.com briane%qnx.com—>briane@qnx.com bruce%citbik.org—>bruce@cubik.org bruce%cybersight.com=>bruce@cybersight.com bryce-mozilla%nextbus.com=>bryce-mozilla@nextbus.com bsharma%netscape. com=> bsiiarma@netscape.com bsmed berg%covad.net—>bsmed berg@covad.net bugreport%peshkin.net—> bugreport@peshkin.net bugzilla%arlen.demon.co.uk=> bugzilla@arlen.demon.co.uk bugzilla%babylonsounds.com=>bugzilla@baby lonsounds.com bugzilla%glob.com.au=>bugzilla@glob.com.au bugzilla%micropipes.com=>bugzilla@micropipes.com bugzilla%standard8.demon.co.uk=> bugzilla@standardS.demon.co.uk burnus%gmx.de—>burnus@gmx.de buster%netscape.com=>buster@netscape.com bzbarsky%mit.edu—>bzbarsky@m it.edu carl. wong%intel.com—>carl. wong@intel.com cata%netscape.corn—>cata@netscape.com cat.h leen %n'etscape. co m=> cath leen ©netscape .com cavin%netscape.com—>cavin@net scape.com chak%netscape.com=>chak@netscape.com chanial%noos.fr—>chanial@noos.fr chjung%netscape.com=>chjung@netscape.com chouck=>chouck@knobproductions.com chrisk%netscape.com=> chrisk@netscape.com christophe. ravel.bugs%sun.com=>christophe.ravel. bugs@sun.com diuan g%n etscape.com=> ch uan g@n etscape. com chuckb%netscape.com=>clmckb@netscape.com clt.bid%netscape.com=>cl tbld@netscape.com cl u %11etscape.com—> clu@netscape.com cm p%mozilla.org—>cm p@mozilla.org colin%theblakes.com=>colin@tlieblakes.com colinp%oeone.com=>colinp@oeoiie.com conrad%ingress.com—>conrad@i ngress.com coop%netscape.com—>coop@netscape.com cotter%netscape.com=>cotter@netscape.com cpeyer%adobe. com=> cpeyer@adobe. com cvsliook%sicking.cc—>cvshook@sicking.cc d ac%x. cx=> dac@x. cx Dale.Stansberry%Nex warecorp.com=> Dale.Stansberry@Nexwarecorp.com daniel%glazman.org— >daniel@glazman.org daniel.boelzle%sun.com=>daniel.boelzle@sun.com daumling%adobe.com—>daumling@adobe.com dave%intrec.com—> dave@intrec.com davel%mozil!a.com — >davel@ mozilla. com davidm%netscape.com=> davidm@netscape.com davidnic%netscape.com=>davi(imc@netscape.com d bl 8x%yahoo. com—> d b4 8x@yahoo. com dbragg%netscape.com—>dbragg@netscape.com d con e%netscape.com—> dco ne@ netscape, com ddrinan%netsc ape.com—> ddrinan@netscape.com dean_tessman%hotmaiI.com=>dean J.essman@hotmail.com depstein%netscape.com=>depstein@netscape.com despotdaemon%netscape. com=>despo t.daemon@netscape.com dfm%netscape.com=>dfm@netscape,com dianesun%netscape.com=>dtan esun@netscape.com dietrich%mozilla.com = >dietrich@niozilla.com O Table C.4: Mozilla one-to-one username to e-mail mappings continued. O n e - t o - o n e M a p p i n g s C o n t i n u e d d i n 1 a t o r % 1 1 e t s c a p e . c o m — >dimator@netscape.com ding] is96qnx.com => dinglis@qnx.com disttsc%bart.nl = >disttsc@bart..nl djani%netsca pe.com—>djani@netscape. com dkl%redhat.com=>dk!@redhat.com don%netscape.com=> don@netscape.com donglas%stcbiIa.ca=>douglas@stebi!a.ca dp%net scape.com—>dp@netscape.com dprice%netscape.com=> dprice@netscape.com dr%netscape.com=>dr@net scape.com drapeau%cng.sun.com—> drapcau@eng.sun.com drichuis%playbeing.org—> driehuis@playbeing.org dschaffc%adobe.com—> dschaffe@adobe.com dsirnapalli%netscape.com=>dsirnapalli@nctsca pe.com d uncan %be. com=> d unc an@be. com dwitt.e%staiiford.edu—>dwitte@staiiford.edu ebina%netscape.com=>ebina@netscape.com edburns%acm.org—>edburns@acm.org eddyk%netscape.com=>eddyk@netscape.com edwi n %woudt.nl=>ed win@woudt.nl emaijala%kolumbus.fi=>emaija!a@kolumbus.fi endico%mozil]a.org=>endico@mozilla.org enndeakin%sympatico.ca=>enndeakin@sympatico.ca ere%atp.fi=>ere@atp.fi ericb%neop]aiiet.(:om=>ericb@iieop!aiiet.com etsai%netscape.com=>etsai@netscape.com e vaughan% netscape, com- > evaughan@netscape.com eyork%netscape.com=>eyork@netscape.com fcrgus%!iet.scape.com=> fergus@netscape.com ttamingice%sourmilk.net=> flamingice@sourmilk.net fligtar%gmail.com—> fligtar@gmail.com frankm%eng.sun.com=>fraiikm@eiig.sun.eom ftang%netscape.(;orn=>ftang@netscape.com g n g a n % 1 1 e t s c a p e . c o m — > g a g a n@netscape.com garyf%netscape.coni=>garyf@netscape.com ga ry wade%11et.se: ape. com—>ga rywade@netscape.com g a y a t r i b % n e t s c a p e . c o m = > g a y a t r i b @ n e t s c a p e . c o m g b e a s l e y % n e ( s c a p e , c o m — > g b e a s l e y @ n e t s c a p e . c o m g e r m a n % n e t s e a p e . c o m = > g e r m a n @ n e t s c a p e . c o m * g h e n d r i c k s % n o v e i l , c o m — > g h e n d r i c k s @ n o v e l l . c o m g i j s k r u i t b o s c h % g m a i l . c o m — > g i j s k r u i t b o s c h @ g m a i l . c o m l b e r t . f a n g % s u n . c o m — > g i l b e r t , f a n g @ s u n . c o m n n . c h e n % s u n . c o m — > g i n n . c h e n @ s u n . c o m r i s h . m a n w a n i % e n g . s u n . c o m — > g i r i s h . m a n w a n i @ e n g . s u n . c o m g l a z m a n % n e t s c a p e . c o m — > g l a z m a n @ n e t s c a p e . c o m g l e n . b e a s ! e y % s u i i . c o m = > g l e n . b e a s I e y @ s t m . c o m g r a i l % c a f e b a b e . o r g = > g r a i l @ c a f e b a b e . o r g g u h a % n e t s c a p e . c o m = > g u h a @ n e t s c a p e . c o m g u r u % s t a r t r e k . c o m = > g u r u @ s t a r t r e k . c o m h a n g a s % n e t s c a p e . c o m = > h a n g a s @ n e t s c a p e . c o m h a r d t s % n e t s c a p e . c o m = > h a r d t s @ n e t s c a p e . c o m h a r i s h d % n e t s c a p e . c o m — > h a r i s h d @ n e t s c a p e . c o m h a r r i s o n % n e t s c a p e , c o m — > h a r r i s o n @ n e t s c a p e . c o m h e n r y . j i a % s u n . c o m — > h e n r y . j i a @ s u n . c o m h e w i t t % n e t s c a p e , c o m — > h e w i t t @ n e t s c a p e . c o m h i d d a y % g e o c i t i e s . c o m — > l i i d d a y @ g e o c i t i e s . c o m h o a . n g u y e n % i n t e l . c o m = > h o a . n g u y e n @ i n t e l . c o m h p r a d h a n % h o t p o p . c o m = > h p r a d h a i i @ h o t p o p . c o m h s h a w % n e t s c a p e . c o m — > h s h a w @ n e t s c a p e . c o m i a n % h i x i e . c h — > i a n @ l i i x i e . c h i a n . m c g r e e r % s u n . c o m = > i a n . m c g r e e r @ s u n . c o m i d k % e n g . s u n . c o m — > i d k @ e n g . s u n . c o m i g o r % m i r " 2 . o r g — > i g o r @ m i r 2 . o r g i g o r . b u k a n o v % g m a i 1 . c o m — > i g o r . b u k a n o v @ g m a i 1 . c o m i m a j e s % p h p . n e t — > i m a j e s @ p h p . n e t i n a k y . g o n z a l e z % i n t e l . c o m = > i n a k y . g o n z a l e z @ i n t . e l . c o m j a b % a t d o t . o r g — > j a b @ a t d o t . o r g j a g % t t y . n l = > j a g @ t t y . n l . j a g g e r n a u t % n e t s c a p e . c o r n = > j a g g e n i a u t @ n e t s c a p e . c o m J a n . V a r g a 7 o g m a i l . c o m — > J a n . V a r g a @ g m a i l . c o m j a n c % 1 1 e t s c a p e . c o m — > j a n c @ n e t s c a p e . c o m j a r % n e t s c a p e . c o m — > j a r @ n c t s c a p e . c o m j a t % p r i n c e t o i i . e d u = > j a t @ p r i n c e t o n . e d u j a v i % 1 1 e t s c a p e . c o m = > j a v i @ n e t s c a p e . c o m j a y % m o z i l l a . o r g = > j a y @ m o z i t l a . o r g j a y . y a n % s u n . c o m = > j a y . y a i i @ s u n . c o m j b a n d % n e t s c a p e . c o m = > j b a n d @ n e t s c a p e , c o m j b e t a k % 1 1 e t s c a p e . c o m = > j b e t a k @ n e t s c a p e . c o m j c g r i g g s % s y m p a t i c o . c a = > j c g r i g g s @ s y m p a t i c o . c a j d u n n % n e t s c a p e . c o m = > j d u i i n @ n e t s c a p e . c o m j e f f . d y e r % c o m p i ] e r c o m p a n y . c o m = > j e f f . d y e r @ c o m p i l e r c o m p a n y . c o m j e f f . l i e d l u n d % m a t n x s i . c o m = > j e f T . h e d l u n d @ m a t r i x s i . c o m j e f f t % i i e t s c a p e . c o m = > j e f f t @ n e t s c a p e . c o m j e l w e l l % n e t s c a p e . c o m = > j e l w e l l @ n e t s c a p e . c o m J e r r y . K i r k % N e x w a r e c o r p . c o m = > J e r r y . K i r k @ N e x w a r e c o r p . c o m j e r r y . t a n % s u n . c o m = > j e r r y . t a n @ s u n . c o m j e v e r i n g % n e t s c a p e . c o m = > j e v e r i i i g @ n e t s c a p e . c o i n j f r a n c i s % n e t s c a p e . c o m = > j f r a n c i s @ n e t s c a p e . c o m j g a u n t % n e t s c a p e . c o m = > j g a u 1 1 L @ n e t s c a p e . c o m j g e l l m a n % n e t s c a p e . c o m = > j g e l l m a n @ n e t s c a p e . c o m j g l i c k % 1 1 e t s c a p e . c o m = > j g l i c k @ n e t s c a p e . c o m j i m _ n a n c e % y a h o o . c o m = > j i m _ n a n c e @ y a h o o . c o m j j % n e t s c a p e . c o m = > j j @ n e t s c a p e . c o m j m i n t a % g m a i l . c o m = > j m i n t a @ g m a i l . c o m j o c u r i % s o f t h o m e . n e t = > j o c u r i @ s o f t h o m e . n e t j o e % r e t r o v i r u s . c o m = > j o e @ r e t r o v i r u s . c o m J o h n . m a r m i o n % i i r e l a n d . s u n . c o m = > j o h i i . i n a r m i o n @ i r e l a n d . s u n . c o m j o l 1 n g % c 0 r e l . c o m = > j o h n g @ c o r e l . c o m j o k i % 1 1 e t s c a p e . c o m = > j o k i @ n e t s c a p e . c o m j o n a s . u t t e r s t r o m % v i t . t r a n . i i o r n i o d . s c = > j o n a s . u t t e r s L r o m @ v i t t r a n . n o r r n o d . s e j o s h m o z % g m a i l . c o m = > j o s h m o z @ g m a i l . c o m j o s h u a . x i a % s u n . c o m = > j o s h u a . x i a @ s u n . c o m j o u n i % h e i k n i e m i . n e t . = > j o u n i @ h e i k n i e m i . n e L j p i e r r c % i n e t s c a p e . c o m = > j p i e r r e @ n e t s c a p e . c o m j s u n % n e t s c a p e . c o m = > j s u n @ n e t s c a p e . c o m j t a y l o r % n e t s c a p e . c o m = > j t a y l o r @ n e t s c a p e . c o m j u l i e n . p i e r r e . b n g s % s u n . c o m = > j i i l i e n . p i e r r e . b u g s @ s u n . c o m j w a a % j w a t t . o r g = > j w a t , t @ j w a t t . o r g 05 Table C .5: Mozilla one-to-one username to e-mail mappings continued. O n e - t o - o n e M a p p i n g s C o n t i n u e d kairo%kairo.at=>kairo@kairo.at kandrot%netscape. com = > kftiidrot@netscape.com karnaze%netscape.roni=>karnaze@netscape.com katakai%japaii.sim.com=>kalHkai@japan.sun.com kevm%perldap.org=>kevin@perldap.org klianson%i)etscftpe.<:om=>kha.nson@netsca.pe.com kiko%async.com.br=> kiko@asyiic.coni.br kin%netscape.com==> kin@nctscape.com kipp%net scape. com=> kipp@nctscape.com kjh-57277ocomcast.net=>kj h-5727@corncast.net kmcc]usk%netscape.com=>kmcclusk@netscape.com koehler%mythrium.com=>koe]iler@my thrium.com kostello7oiietscape.com=>kostello@netscape.com kvisco%zipl ink.net=> kvisco@ziplink.net kyle.yuan%sun.com=>kyle.yitan@sun.com kysmith%netscape.com=> kysmith@netscape.com kzhou%netscape.com=> kzhou@netscape.com !aa%sparc.spb.su=>laa@sparc.spb.su !aw%netscape.com=>law@netscape.com ]eif%netscape.com=> leif@netscape.com !eila.garin%eng.sun.com=> leila.garin@eng.sun.com leon.sha%sun.com=> teoii.sha@suii.com ]eon.zhang%sun.com=> leon.zhaiig@siin.com load runner%betak.net=> loftdrtinner@betak.net locka%iol.ie—>locka@iol.ie longsonr%gmail.com=>longsonr@gmail.com lordpixel%mac.com=>lordpi.xel@mac.com louie.zhao%sun. com=>louie. zliao@sun.com !ouis.martin%eng.sun.com=>louis.martin@eng.sun.com !pham%netscape.com=> lpham@netscape.com lpso!it%gmail .com=> LpSolit@gmail.com ltabb%netscape.coin=> ltabb@netscape.com m_kato%ga2.so-net.ne.jp=>m_kato@ga'2.so-net. ne.jp maolson7teart!ilink.iiet=>maolson@earthlink.net marco%gnome.org=>marco@gnome.org margaret.clian%sun.com=>margaret.chan@sun.com mark%moxienet.com = > mark@moxienet.com mark.lin%eng.sun.com=>mark.lin@eng.sun.com markh%activestate.com=>markh@activestate.com marr ia%gm ail. com=>marria@gm ail.com martijn.martijn%gmail.com=>mart ijn.martijn@gmail.com marti iii%11etscape.com=> martinl@11etscape.com masayuki%d-toy box.com=>masayuki@d-toybox.com mats.palmgren%bredband.net—>mats.palmgren@bredband.net matt%netscape.com=> matt@netscape.com in auhias%i sorted.org=>matthias@sorted.org mattwili is%gmail.com = >mattwil!is@grnail.com matty%chariot.net.au=>matty@chariot.net.au maxf%magma.ca=>maxf@magma.ca mccabe7onetscape.com=> mccabe@netscape.com mcgreer%netscape.com=>mcgreer@netscape.com mcmullen%netscape. com=>mcmullen@netsca pe.com m cs%pear Icrescent. com=> m cs@pearlc rescent .com mgalli%geckonnection.com=>mgalli@geckonnection.com mgleesonl7onetscape.com=> mgleesonl@netscape.com mbammond%skippinet.com.au=>mhammond@skippinet.com.au niicliael.buettner%suii.com=>michaet.buettner@sun.com Michael. Kedl%Nexwarecorp.com=>Michael. Kedl@Nexwarecorp.com michael.lowe%ibigfoot.com = >michael. lowe@bigfoot.com michaelp%iietscape.com=>michaelp@netscape.com mike%neoplanet.com=> uiike@neoplanet.com mike. morgan%oregonstatc.edu—> niike.morgan@oregonstate.edu mike-Hnozilla7oineer.net=>mike-Hn ozilla@meer.net mikep%oeone.com=>mikep@oeone.corn miodrag%netscape.coni=>miodrag@netscape.corn mitchf%iietscape.com=>mitchf@netscape.com mitesh%netscape.com=>mitesh@netscape.com mj%digicool . com=> mj@digicool.com mjudge%netscape.com=>mjudge@!ietscape.com m kaply%us.i bm .com=> m kaply@us.ibm .com mnyromyr%tprac.de=>mnyromyr@tprac.de modgock%eng.sun.com=>modgock@eng.sun.com morse%netscape.com—>morse@netscape.com mostafah%oeone.com=>mostafah@oeone.com mozedi tor%floppy m oose .com=> m ozedi tor@floppy moose, com mozil!a%justcameron.com—>mozilla@justcameron.com mozil!a%wei lbacher.org—> niozilla@weilbachcr.org mozilla. mano%sent. com=> mozilla.mano@seiit.com m r bkap%gni ail. com—> m rbkap@g m ai 1. com mscott%11etscape.com—> mscott@netscape.com nistoltz%netscape.com — > mstoltz@netscape.com msw%oginip.org=>msw@gimp.org mvl%exedo.nl—> mvl@exedo.nl mwelcli%netscape.com—> mwelch@netscape.com myk%mozilla.org— >myk@mozilla.org namachi%netscape.com—>namachi@netscape.com navi ng%netscape. com—>na ving@netscape.com nbhatla7onetscape.com— >nbhatla@netscape.com nboyd%atg.com=>nboyd@atg.com neeti%net scape, comneet i@netscape .com neil%pftrkwaycc.co.uk=>neil@parkwaycc.co.tik neil. wi!liams%sun.com—>neil. williams@sun.com nel s011%b0lyard.com—>nelson@bolyard.com nels011b%11etscape.com=> nelsonb@netscape.com nhotta%netscape.com—>nhotta@netscape.com nick.kreeger7opark.edu=>nick.krecger@park.edu nicolson%netscape.com — > 11icolso11@netscape.com nis%sparc.spb.su—>nis@sparc.spb.su nislieeth%netscape.com—>nis!ieetli@netscape.com nivedita%netscape.com—> nivedita@netscape.com nki! ider%redhat.com^> nkinder@redhat.com 11k wan % red hat. com—> n k wan@red hat. com noriri ty%jcom.home.ne.jp—>noririty@jcom.home.ne.jp norris%netscape.com—> norris@netscape.com oeschger%netscape.com—> oeschger@netscape.com olav%bkor.dhs.org=>o!av@bkor.dhs.org 011i.Pettay%helsinki.fi->011i.Pettay@helsinki.fi p_ch% verizon. net=> p_ch@verizon.net Table C.6: Mozilla one-to-one username to e-mail mappings continued. O n e - t o - o n e M a p p i n g s C o n t i n u e d p a m g . b u g s % g m a i l . c o m = > p a m g . b u g s @ g m a i l . c o i n p a p e r % a n i m e c i t y . n u = > p a p e r @ a n i m e c i t y . n u p a v e ! % g i n g e r a l l . c z — > p a v e l @ g i n g e r a l l . c z p c h e n % n e t s c a p e . c o m = > p c l i e i v @ n e t s c a p e . c o m p e d e m o n t % i l s . i b m . c o i n — > p e d e i n o n t @ i i s . i b m . c o m p e p p e r % i n e t s c a p e . c o m — > p e p p e r @ n e t s c a p e . c o m p e t c % a 1 p h a n u m e r i c a . c o m = = > p e t e @ a l p h a n u m e r i c a . c o m p e t e % i m o z d e v g r o u p . c o m — > p e t e @ m o z d e v g r o u p . c o m p e t e . z h a % s u n . c o m — > p e t e . z h a @ s n n . c o m p e t e r % p r o p a g a n d i s m . o r g = > p e t e r @ p r o p a g a n d i s m . o r g P e t e r . V a n d e r B e k e n % p a n d o r a . b e — > P e t e r . V a i i d e r B e k e n @ p a n d o r a . b e p e t e r l u b c z y n s k i % 1 1 e t s c a p e . c o m — > p e t e r l u b c 7 J y n s k i @ n e t s c a p e . c o m p e t i t t a % i i i e t s c a p e . c o m — > p e t i t t a @ n e t s c a p e . c o m p l i i l 7 o i i e t . s ( : a p e . c o m = > p h i l @ n e t s c a p e . c o m p h i ! l i p % i n e t s c a p e . c o m = > p h i l l i p @ n e t s c a p e . c o m p h i t r i n g n a l d a % g m a i l . c o m — > p h i l r i 1 1 g n a l d a @ g m a i l . c o m p i e r r e % 1 1 e t s c a p e . c o m — > p i e r r e @ n e t s c a p e . c o m p k a s t h i g % g o o g l e . c o m ~ > p k a s t i n g @ g o o g l e . c o m p k w % u s . i b m . c o m — > p k w @ u s . i b m . c o m p n u n n 7 o n e t s c a p e . c o m = > p n u n n @ n e t s c a p e . c o m p o l l m a n n % n e t s c a p e . c o m = > p o l l m a n n @ n e t s c a p e . c o m p p % l u d u s d e s i g n . c o m = > p p @ l u d u s d e s i g n . c o i n p r a s a d % n e t s c a p e . c o m — > p r a s a d @ n e t s c a p e . c o m p r a s s 7 o i i e t s c a p e . c o m = > p r a s s @ n e t s c a p e . c o m p s y c h o t i c w o l f % c a r o l i n a . r r . c o m — > p s y c h o t . i c w o l f @ c a r o l i n a . r r . c o m p u L t e r m a n % 1 1 e t s c a p e . c o m — > p u t t e r m a n @ n e t s c a p e . c o m q u y 7 o i g e l a i i s . c o m . a u = > q u y @ i g e l a u s . c o m . a u r a c l i a m % n e l s c a p e . c o m — > r a c h a m @ 1 1 e t s c a p e . c o m r a d l 1 a % 1 1 e t s c a p e . c o m — > r a d h a @ n e t s c a p e . c o m -r a m a n % n e t s c a p e . c o m — > r a m a n @ n e t s c a p e . c o m r a n g a n s e n % n e t s c a p e . c o m — > r a n g a n s e n @ n e t s c a p e . c o m r a y w % ] ] i e l . s c a p e . c o m — > r a y w @ n e t s c a p e . c o m r b s % m a l . h s . u q . e d u . a u = > r b s @ m a t h s . u q . e d u . a u r c a s s i n % s u p e r n o v a . . o r g = > r c a s s i n @ s u p e r n o v a . o r g r c h e n % n e t s c a p e . c o m — > r c h e n @ n e t s c a p e . c o m r d a y a l % 1 1 e t s c a p e . c o m — > r d a y a l @ n e t s c a p e . c o m r e a l p e t e r v % m a c . c o m = > r e a l p e t e r v @ m a c . c o m r e d f i v e % a c m . o r g — > r e d f i v e @ a c m . o r g r e e d % r e e d l o d e n . c o m = > r e e d @ r e e d l o d e n . c o m r e l y e a % n e t s c a p e . c o m = > r e l y c a @ n e t s c a p e . c o m r e p k a % n e t s c a p e . c o m — > r e p k a @ n e t s c a p e . c o m r g o o d g e r % i h u g . c o . n z — > r g o o d g e r @ i h u g . c o . n z r h e l m e r % m o z i l l a . c o m — > r h e l m e r @ m o z i l l a . c o m r h p % n e t s c a p e . c o m = > r h p @ n e t s c a p e . c o m r i c h . b u r r i d g e % s u i i . c o m = > r i c h . b u r r i d g e @ s u n . c o m r i c h m % s t a n f o r d a l u m n i . o r g = > r i c h m @ s t a n f o r d a l u m n i . o r g r i < : k g % n e t s c a p e . c o m — > r i c k g @ n e t s c a p e . e o m r i s t o % n e t s c a p e . c o m = > r i s t o @ n c t s c a p e . c o m r j e % n e t s c a p e . c o m = > r j c @ n e t . s c a p e . c o m r j e s u p 7 o w g a t e . c o m = > r j e s u p @ w g a t e . c o m r k o 7 o t i e t s c a p e . c o m — > r k o @ n e t s c a p e . c o m r l k % t r f e n v . c o m = > r l k @ t r f e n v . c o m r o b _ s t r o n g % e x c h a n g e c o d e . c o m = > r o b j ; t r o n g @ e x c h a n g e c o d e . c o m r o b e r t % a c c e t t u r a . c o m — > r o b e r t @ a c c e t t u r a . c o m r o b i n . l u % s u n . c o m = > r o b i n . l u @ s u n . c o m r o b i n f % n e t s c a p e . c o m = > r o b i n f @ n e t s c a p e . c o m r o b o d a n % n e t s c a p e . c o m = > r o b o d a n @ n e t s c a p e . c o m r o d s 7 o n e t s c a p e . c o m — > r o d s @ 1 1 e t s c a p e . c o m r o e b e r % 1 1 e t s c a p e . c o m — > r o e b e r @ n e t s c a p e . c o m r o g c % n e t s c a p e . c o m — > r o g c @ n e t s c a p e . c o m r o g e r ! % n e t s c a p e . c o m = > r o g e r l @ n e t s c a p e . c o m r p a l l a t h % e n g . s u n . c o m = > r p a l I a t h @ e n g . s u n . c o m r p o t t s % n e t s c a p e . c o m — > r p o t t s @ n e t s c a p e . c o m r r e l y e a 7 o r e d h a t . c o m — > r r e l y e a @ r e d h a t . c o m r t h 7 o c y g n u s . c o m — > r t h @ c y g n u s . c o m r u s l a n % n e t s c a p e . c o m — > r u s l a n @ n e t . s c a p e . c o m r u s t y . l y n c b % i n t e l . c o m = > r u s t y l y n c h @ i n t e l . c o m r w e l t m a n % n e t s c a p e . c o m — > r w e l t m a n @ n e t . s c a i i c . c o m s a a r i % n e t s c a . p c . c o m — > s a a r i @ n e t s c a p e . c o m s a m u e l 7 o s i e b . n e t — > s a m u e l @ s i c b . n e t , s a 1 1 c u s % 0 f f . n e t — > s a n c u s @ o f T . n e t s a n d e e p , k o n c h a d y % s u n . c o m = > s a i l d e e p , k c i n c h a d y @ s u n . c o m s a r % n e t s c a p e . c o m = > s a r @ n e t s c a p e . c o m s a u l . e d w a r d s % s u n . c o m = > s a u l . e d w a r d s @ s u n . c o m s a y r e r % g m a i l . c o m = > s a y r e r @ g m a i ! . c o m s c o o t e r m 6 r r i s % c o m c a s t . n e t = > s c o o t e r m o r r i s @ c o m c a s t . n e t s c o t t % s c o t t ^ m a c g r e g o r . o r g = > s c o t t @ s c o t t - m a c g r e g o r . o r g s c u l l i n % n e t s c a p e . c o m = > s c u l l i n @ n e t s c a p e . c o m s d a g l e y % n e t s c a p e . c o m = > s d a g l e y @ n e t s c a p e . c o m s d v 7 o s p a r c . s p b . s u — > s d v @ s p a r c . s p b . s u s e a i i 7 o b e a t n i k . c o m = > s e a n @ b e a t n i k . c o m s e r g e % i i e t s c a p e . c o m = > s e r g e @ n e t s c a p e . c o m s e r g e i _ d 7 o f i . t a r t u . e e = > s e r g e i _ d @ f i . t a r t u . e e s e t h 7 o c s . b r a n d e i s . e d u = > s e t h @ c s . b r a n d e i s . e d u s f o r d 3 % s w b e l l . n e t = > s f o r d 3 @ s w b e l l . n e t s g e h a n i 7 o n e t s c a p e . c o m = > s g e h a n i @ i i e t s c a p e . c o m s h a n j i a i i % n e t s c a p e . c o m = > s h a n j i a n @ n e t s c a p e . c o m s h a n n o n d % n e t s c a p e . c o m = > s h a n n o n d @ n e t s c a p e . c o m s h a r p a r r o w 1 % y a h o o . c o m = > s h a r p a r r o w 1 @ y a h o o . c o m s h a w n p % e a r t h l i n g . n e t = > s h a w n p @ e a r t h l i n g . n e t s h e r r y . s h e n % s i i n . c o m = > s h e r r y . s h e n @ s u n . c o m s h l i a J i g 7 o n e t s c a p e . c o m = > s h l i a n g @ n e t s c a p e . c o m s h r u t i v % n e t s c a p e . c o m = > s h r u t i v @ n e t s c a p e . c o m s i l v e r % w a r w i c k c o m p s o c . c o . u k = > s i l v e r @ w a r w i c k c o m p s o c . c o . u k s i m f o r d . d o n g 7 c s u n . c o m = > s i m f o r d . d o n g @ s i i n . c o m s i m o n % s o f t e l . c o . i l — > s i m o n @ s o f t e l . c o . i l s ! a v o m i r . k a t u s c a k % s u n . c o m = > s l a v o m i r . k a t u s c a k @ s u n . c o m s m a n % n e t s c a p e . c o m = > s m a n @ n e t s c a p e . c o m s m e r e d i t h % n e t s c a p e . c o m = > s m e r e d i t h @ n e t s c a p e . c o m s m f r % s m f r . o r g = > s m f r @ s m f r . o r g s o n j a . m i r t i t s c h % s u n . c o m = > s o n j a . m i r t i t s c h @ s u n . c o m s o n m i % n e t s c a p e . c o m = > s o n m i @ i i e t s c a p e . c o m s p e n c e % i i e t s c a p e . c o m = > s p e i i c e @ n e t s c a p e . c o m s p i d e r 7 o n e t s c a p e . c o m = > s p i d e r @ n e t s c a p e . c o m s r i l a t h a 7 o i i e t s c a p e . c o m = > s r i l a t h a @ i i e t . s c a p e . c o m s r i n i v a s % n e t s c a p e . c o m = > s r i n i v a s @ n c t s c a p e . c o m s s a u x 7 o n e t s c a p e . c o m = > s s a u x @ n e t s c a p e . c o m s s u % n e t s c a p e . c o m — > s s u @ n e t s c a p e . c o m Table C.7: Mozilla one-to-one username to e-mail mappings continued. O n e - t o - o n e M a p p i n g s C o n t i n u e d S t e f a n . B o r g g r a e f e % i g m x . d e = > S t e f a n . B o r g g r a e f e @ g m x . d e s t e f f e n . w i l b e r g % w e b . d e = > s t e f f e n . w i l b e r g @ v v e b . d e s t e j o h n s % a d o b e . c o m — > s t e j o h n s @ a d o b e . c o m s t r i d e y % g m a i ] . c o m — > s t r i d e y @ g m a i l . c o m s t u a r t . m o r g a n % a 1 u m n i . c a s e . e d u — > s m a r t , m o r g a n @ a l u m n i . c a s e . e d u s u d u % n e t s c a p e . c o m = > s u d u @ n e t s c a p e . c o m s u r e s h % n e t s c a p e . c o m = > s u r e s h @ n e t s c a p e . c o m s v n % x m l t e r m . o r g = > s v n @ x m l t e r m . o r g s y d % n e t s c a p e . c o m = > s y d @ n e t s c a p e . c o m s z e g e d i a % f r e e m a i l . h u = > s z e g e d i a @ f r e e m a i l . h u t _ m u t r e j a % y a h o o . c o m = > t _ m u t r e j a @ y a h o o . c o m t a e k % n e t s c a p e . c o m = > t a e k @ n e t s c a p e . c o m t a g u e % n e t s c a p e . c o m — > t a g u e @ n e t s c a p e , c o m t a j i m a % e n g . s u n . c o m = > t a j i m a @ e n g . s u n . c o m t a k a % n e t s c a p e . c o m — > t a k a @ n e t s c a p e . c o m t a l i s m a n % o a n a m o r p h i c . c o m — > t a l i s m a n @ a n a m o r p h i c . c o m t a o % n e t s c a p e . c o m = > t a o @ n e t s c a p e . c o m t a r a % t e q u i l a r i s t a . o r g = > t a r a @ t e q u i l a r i s t a . o r g t b o g a r d % a o l . n e t — > t b o g a r d @ a o l . n e t t e c h n u t z % 1 1 e t s e a p e . n e t — > t e c h n u t z @ n e t s c a p e . n e t t e d . m i e l c z a r e k % o g m a i l . c o m — > t e d . m i e l c z a r e k @ g m a i l . c o m t f o x % o n e t s c a p e , c o m — > t f o x @ n e t s c a p e . c o m t h a y e s % n e t s c a p e . c o m — > t h a y e s @ n e t s c a p e . c o m t h e s t e v e % 1 1 e t s c a p e . c o m = > t h e s t e v e @ n e t s c a p e . c o m t h o r n a s . b e n i s c h % p s u n . c o m — > t h o m a s . b e n i s c . h @ s u n . c o m t i m m % n e t s c a p e . c o n i — > t i m m @ n e t s c a p e . c o m t i n g l e y % s u n d e l l . n e t — > t i n g l e y @ s u n d e l l . n e t t o m w % n e t s c a p e . c o m = > t o m w @ n e t s c a p e . c o m t o n y % o p o n d e r e r . o r g — > t o n y @ p o n d e r e r . o r g t o n y r % f b d e s i g n s . c o m — > t o n y r @ f b d e s i g n s . c o m t o r % c s . b r o w n . e d u = > t o r @ e s . b r o w n . e d u t m v i s % o s e d s y s t e m s . c a — > t r a . v i s @ s e d s y s t e m s , c a t r o y % 1 1 e t s c a p e . c o m = > t r o y @ n e t s c a . p e . c o i n t w a l k e r % n e t s c a p e . c o m — > t w a l k e r @ n e t s c a p e . c o m u r i b e r % g m a i l . c o m — > u r i b e r @ g m a . i l . c o m v a l 4 % c o r n e l l . e d u — > v a l 4 @ c o r n e l l . e d u v a l e s k i % 1 1 e t s c a p e . c o m — > v a l e s k i @ n e t s c a p e . c o m v a r a d a % o n e t s c a p e , c o m — > v a r a d a @ n e t s c a p e . c o m v i d u r % o n e t s c a p e . c o m — > v i d u r @ n e t s c a p e . c o n i v i s h y % o n e t s c a p e . c o m = > v i s b y @ n e t s c a p e . c o m v l a d d % b 1 1 g z i l l a . o r g — > v l a d d @ b u g z i l l a . o r g v l a d i m i r % p o b o x . c o m — > v l a d i m i r @ p o b o x . c o m w a d e % e z r i . o r g = > w a d e @ e n r i . o r g w a l d e m a r % o i i e t s c a p e . c o m — > w a l d e m a r @ n e t s c a p e . c o m w a q a r % n e t s c a p e . c o m — > w a q a r @ n e t s c a p e . c o m w a r r e n % 1 1 e t s c a p e . c o m — > w a r r e n @ n e t s c a p e . c o m w a t e r s o n % > n e t s c a p e . c o m — > w a t e r s o n @ n e t s c a p e . c o m w c h a n g O 2 2 2 % 0 a o l . c o m — > w c h a n g 0 2 2 2 @ a o l . c o m • w c l o u s e r % m o z i l I a . c o m — > w c l o u s e r @ m o z i l l a . c o m w e b m a i l % k m g e r i c h . c o m — > w e b m a i l @ k m g e r i c h . c o m w r % r o s e n a u e r . o r g — > w r @ r o s e n a u e r . o r g w s h a r p % a d o b e . c o m — > w s h a r p @ a d o b e . c o m v v t c % i n e t s c a p e , c o m — > w t c @ n e t s c a p e . c o m w t c h a n g % o r e d h a t . c o m — > w t c h a n g @ r e d h a t . c o m w u r b l z a p % g m a i l . c o m = > w u r b l z a p @ g m a i l . c o m X i a o b i n . L u % e 1 1 g . S u n . c o m — > X i a o b i n . L u @ e n g . S u n . c o n i y o k o y a m a % o n e t s c a p e . c o m — > y o k o y a m a @ 1 1 e t s c a p e . c o m y u e h e n g . x u % o i n t e l . c o m = > y u e h e n g . x u @ i n t e l . c o m y x i a % 0 1 1 e t s c a p e . c o m — > y x i a @ n e t s c a p e . c o m z a c h % z a c h l i p t o n . c o m — > z a c h @ z a c h l i p t o n . c o m z a c k % k d e . o r g — > z a c k @ k d e . o r g Table C.8: Mozilla one-to-many username to e-mail mappings. O n e - t o - m a n y M a p p i n g s a & r o n l % n e t s c a p e . c o m = > a a . r o n l @ c l i o r u s . n e t a a r o n ] % i ] e t s c a p e . e o m = > a a r o i i ] @ n e t s c a p e . e o n i a l e c f % n e t s c a p e . c o m = > a ! e e f @ f l e t . t . o r g a l e c f % n e t s c a p e . c o m = > a l e c f @ n e t s c a p e . c o m a n d r e a s . o t t e % p r i m n . s - o n l m e . d e = > a n d r e a s . o t t e @ d e b i t e l . n e t a n d r e a s . o t t e % p r i n m s - o n l i n e . d e = > a n d r e a s . o t t e @ p r i m u s - o n l i n e . d e a n t h o n y d % n e t s c a p e . c o m = > a n t l i o n y @ d e r o b e r t . n e t a n t h o n y d % n e t s e a p e . c o m = > a n t h o n y d @ n e t s c a p e . c o m a s a % m o z i l l a . o r g = > a s a @ m o z i l l a . o r g a s a % m o z i l l a . o r g = > a s a s a k i @ n e t s c a p e . c o m b b a e t z % a c m . o r g — > b b a e t z @ a c m . o r g b b a e i z % a c m . o r g — > b b a e t z @ c s . m c g i l l . c a b b a e t z % a c m . o r g = > b b a e f z @ s t u d e n t . u s y d . e d u . a u b b a e t z % a c i n . o r g = > b b a e t z @ u g . c s . u s y d . e d u . a u b e a r d % n e t . s e a p e . c o n i = > c b e a r d @ m o z i l l a . o r g b e a r d % n e t s c a p e . c o m = > b e a r d @ n e t s c a p e . c o m b e n % n e t s c a p e . c o m — > b e n @ b e n g o o d g e r . c o m b e n % n e t s c a p e . c o m = > b e n @ n e t s c a p e . c o m b e n % n e t s c a p e . c o m = > b e n g @ b e n g o o d g e r . c o m b e n % n e t s c a p e . c o m = > b e n g @ g o o g l e . c o m b e n % n e t s c a p e . c o m = > b u g s @ b e n g o o d g e r . c o m b i e i i v e i i u % i n e t s c a p e . c o m = > b i e n v e n u @ n e t s c a p e . c o m b i e n v e m i % i i i e t s c a p e . c o m = > b t e n v e n i i @ n v e n t u r e . c o m b l i z z a r d % r e d h a t . c o m = > b l i z z a r d @ a p p l i e d t h e o r y . c o m b l i z z a r d % r e d h a t . c o m = > b l i z z a r d @ r e d h a t . c o m b o b % c b c l a r y . c o m — > b c l a r y @ b c l a r y . c o m b o b % i b c , l a r y . c o m — > b o b @ b c l a r y . c o m b r a d e % n e t s c a p e . c o m = > b r a d e @ c o m c a s t . n e t b r a d e % 1 1 e t s c a p e . c o m = > b r a d e @ n e t s c a p e . c o m b r e n d a i i % o m o z i l l a . o r g = > b r e i i d a n @ m o z i l l a . o r g b r e n d a . i i % m o z i l l a . o r g = > b r e n d a n @ n e t s c a p e . c o m b r i a n o % n e t s c a p e , c o m = > b r i a n o @ b l u e m a r t i n i . c o m b r i a n o % n e t s c a p e . e o m = > b r i a n o @ n e t s c a p e . c o m b r o f ! e l d % j e l l y c a n . c o m = > b r o f i e l d @ j e l l y c a i i . c o m b r o f i e l d % j e l l y c a i i . c o m = > b r o f i e l d 2 @ j e l l y c a i i . c o m b r y n e r % n e t s c a p e . c o m — > b r y n e r @ b r i a n r y n e r . c o m b r y n e r % n e t s c a p e . c o m = > b r y n e r @ n e t s c a p e . c o m b r y n e r % 1 1 e t s c a p e . c o m — > b r y n e r @ u i u c . e d u b s t e i ! % i n e t s c a p e . c o m — > b s t e l t @ i x . n e t c o m . c o m b s t e i l % o n e t s c a p e . c o m — > b s t e l t @ n e t s c a p e . c o m c a i l l o n % r e d h a t . c o m — > c a i l l o n @ g m a i l . c o m c a i l l o n % r e d h a t . c o m — > c a i l l o n @ r e d h a t . c o m c a i l l o i i % r e d h a t . c o m — > c a i U o n @ r e t u r n z e r o . c o m c b e g l e % 0 1 1 e t s c a p e . c o m — > c b e g l e @ f o r m e r l y - n e t s c a p e . c o m . t l d c b e g l e % 1 1 e t s c a p e . c o m — > c b e g l e @ n e l s c a p e . c o m c b i e s i s i g e r % w e b . d e — > c b i e s i n g e r @ g m x . a t c b i e s m g e r % w e b . d e — > c b i e s i n g e r @ w e b . d e c c a r l e n % n e t s c a p e . c o m = > c c a r l e n @ m a c . c o m c c a r l e n % o n e t s c a p e . c o m — > c c a r l e n @ n e t s c a p e . c o m e c o o p e r % n e t s c a p e . c o m = > c c o o p e r @ d e a d s q u i d . e o m c c o o p e r % n e t s c a p e . c o m — > c c o o p e r @ n e t s c a p e . c o m c m a n s k e % n e t s c a p e . c o m — > c m a n s k e @ j i v a m e d i a . c o m c m a n s k e % o n e t s c a p e . c o m = > c m a n s k e @ n e t s c a p e . c o m c s t % a n d r e w . e m u . e d u — > c s t @ a n d r e w . c m i i . e d u c s t % a n d r e w . c m u . e d u = > c s t . @ y e c c . c o m c u r t % 1 1 e t s c a p e . c o m — > c u r t @ n e t s c a p e . c o m c u r t % i n e t s c a p e . c o m = > c u r t @ s c r u z n e t . c o n i c y e h % i n e t s c a p e . c o m — > C h r i s . Y e h @ n o k i a . c o m c y e h % o n e t s c a p e . c o m — > c y e h @ b l u e m a r t i n i . c o m c y e h % n e t s c a p e . c o m — > c y e h @ n e t s c a p e . c o m d a n m % 0 1 1 e t . s c a p e . c o m — > d a n m . m o z @ g m a i l . c o m d a n m % o i i e t s c a p e . c o m = > d a n m @ n e t s c a p e . c o m d a n m % i i i e t s c a p e . c o m — > d a n m - m o z @ c o m c a s t . n e t d a r i n % 1 1 1 e t s c a p e . c o m — > d a r i n . m o z @ g m a i l . c o n i d a r i n % o i i e t s c a p e . c o m = > d a r i n @ m e e r . n e t d a r i u % i n e t s c a p e . c o m — > d a r i n @ n e t s c a p e . c o m d b a r o n % d b a r o n . o r g — > d b a r o n @ d b a r o n . o r g d b a r o n % d b a r o n . o r g — > d b a r o n @ f a s . h a r v a r d . e d u d b a r o n % d b a r o n . o r g — > d b a r o n @ m o z i l l a . c o m d b r a d l e y % n e t s c a p e . c o m = > d b r a d l e y @ g m a i l . c o m d b r a d l e y % 1 1 e t s c a p e . c o m — > d b r a d l e y @ n c t s c a p e . c o m d m o s e % m o z i l l a . o r g = > d m o s e @ m o z i l l a . o r g d m o s e % m o z i l l a . o r g = > d m o s e @ n e t s c a p e . c o m d o n m % n e t s c a p e . c o m = > d o n m @ b l u e m a r t i n i . c o m d o n m % o n e t s c a p e . c o m = > d o n m @ n e t s c a p e . c o m d o r o n r % u s . i b m . c o m = > d o r o n r @ g m a i l . c o m d o r o n r % u s . i b m . c o m = > d o r o n r @ u s . i b m . c o m d o u g t % i i i e t s c a p e . c o m = > d o u g t @ m e e r . n e t d o u g t % o i i e t s c a p e . c o m = > d o u g t @ n e t s c a p e . c o m d u c a r r o z % n e t s c a p e , c o m = > d u c a r r o z @ d u c a r r o z . o r g d u c a r r o z % n e t s c a p e . c o m = > d u c a r r o z @ n e t s c a p e . c o m d u c a r r o z % o n e t s c a p e . c o m = > m o z i ! l a @ d u c a r r o z . o r g d v e d i t z % i i e t s c a p e . c o m = > d v e d i t z @ c r u z i o . c o m d v e d i t z % n e t s c a p e . c o m = > d v e d i t z @ n e t s c a p e . c o m e r i k % n e t s c a p e . c o m = > e r i k @ d a s b i s t r o . c o m e r i k % n e t s c a p e . c o m = > e r i k @ n e t s c a p e . c o m e r i k % n e t s c a p e . c o m = > e r i k @ v a n d e r p o e l . o r g f r i e d m a n % o i i e t s c a p e . c o m = > R i c k F r i e d m a n @ v e r i z o n . n e t f r i e d m a n % i n e t s c a p e . c o m = > f r i e d m a n @ n e t s c a p e . c o m f u r % o n e t s c a p e . c o m = > f u r @ g e o c a s t . c o m f u r % o n e t s c a p e . c o m = > f u r @ n e t s c a p e . c o m g a n d a l f % f i r e f o x . p l = > g a n d a l f @ a v i a r y . p l g a n d a l f % f i r e f o x . p l = > g a n d a l f @ f i r e f o x . p l g a v i n % g a v i n s h a r p . c o m = > g a v i n . s h a r p @ g m a i l . c o m g a v i n % o g a v i n s h a r p . c o m = > g a v i n @ g a v i n s h a r p . c o r n g e r v % g e r v . n e t = > b u g z i l ! a @ g e r v . n e t g e r v % g e r v . n e t = > g e r v @ g e r v . n e t g o r d o n % n e t s c a p e . c o m = > g o r d o n @ s h e p h a r d . o r g g o r d o n % n e t s c a p e . c o m = > g o r d o n @ n e t s c a p e . c o m g r a n r o s e % n e t s c a p e . c o m = > g r a n r o s e @ n e t s c a p e . c o m g r a n r o s e % n e t s c a p e . c o m = > g r a n r o s e b u g s @ g m a i l . c o m h e i k k i % n e t s e a p e . c o m = > h e i k k i @ c i t e c . n h e i k k i % 1 1 e t s c a p e . c o m = > t i e i k k i @ n e t s c a p e . c o m h j t o i % o c o m c a s t . n e t = > h j t o i @ c o m c a s t . n e t h j t o i % c o m c a s t . n e t = > h j t o i - b u g z i l l a @ c o m c a s t . n e t h w a a r a % g m a i l . c o m = > l i w a a r a @ c h e ! l o . s e h w a a r a % g m a i l . c o m = > h w a a r a @ g m a i l . c o m Table C.9: Mozilla one-to-many username to e-mail mappings continued. O n e - t o - M a n y M a p p i n g s C o n t i n u e d hy«tt%mozilla.org=>liyatt@mozilla.org hyat.t%ruozilla.org=>liyatt@netseape.corn jake%bugzillti.org=> jake@acutex.net jake%bugzilla.org=> jake@bugzilla.org jginyers7onetscape.com—>jgmyers@netseape.com jginyers%netscape.com—> jgmyers@speakeasy.net jkeiser%mct scape.com=>jkeiser@iname.com jkeiser%net scape.com = >j keiser@netscape.com jkeiser%net scape.com—>j oh n@johnkeiser.com jmas%softcatala.org=>andrejohn. mas@gmail.com jmas%softcatala.org—>jmas@so ft.catala.org joe.chou%sun.com=>joe.chou@eng.sun.com ijoe.chou%sun.com—> joe. chou@sun.com jrgm7onetscape.com—>j rgm@netscape.com jrgm%net scape. com=>jrgmorri son@aol.com jruderman%hmc.edu—>jruderman@gmail.com jrudernian%hmc.edu=>jruderm an@hmc.edu jshin%mailaps.org=>jshin@mailaps.org jshin%mailaps.nrg=>jshin] 987@gmail.com jst%mozilla.org=>jst.@citec.fi jst7omozilla.org—>jst@mozilla.jstenback.com jst7omozilla.org=>jst.@mozilla.org jst7omozilla.org=> jst@netscape.com jiistdave7obugzilla.org=>justdave@bugzilla.org justdave7obugzilla.org—>justdave@mozilla.com justdave7obugzilla.org—>justdave@syndicomm. com jwalden7omit.edu—>jwalden@mit.edu jwalden%init.edu=>jwalden-i-bmo@mit.edu jwz7oniozi!la.org=>jwz@mozilla.org jwz7omozi!la.org—>jwz@netsca pe.com kaie%>netseape.com=>kaie@kuix.de kaie%nelseape.com=>kaie@netscape.com karl.kornel7omindspeed.com—>karl@kornel.name karl.kornel7omindspeed.com=>karl.kornel@mindspeed.com kerz7onct.scape.com—>kerz@mozillazine.org kerz%netsco pe.com = > kerz@netscape.com kestes%walrus. com->kest es@staff.mail.com kestes7o walrus. eom=>kest es@tradinglinx.com kestes% walrus. eom=>keslcs@walrus. com kestes% walrus. com=>kest esisme@yahoo.com kieran%et.enial.imdonet.eom==>kieran@etcrnal. undonet.com kieran7oeternal.undonet.com = >kieran@gmail.com kirke%netscape.com=> kirk.erickson@sun.com kirke7onetscape.com—> kirke@netscape.com larryh7o netscape, com=> larry Jiowe@hgsi .com larryh7onetscape.com=> larryli@netscape.com leaf%mozilla.org=> leaf@mozilla.org leaf%mozilIa.org=> leaf@netscape.com mang%netscape.com=> mang@netscape.com mang7onetscape.com=>mang@subcarrier.org . mbarnson7osisna.com=> mbarnson@exciteliome.net mbarnson%sisna. com—> mbarnson@sisna.com mcafee%net scape, com=> mcafce@mocha.com nicafee%iietscape.com=>mcafee@iietscape.com mconnor%steelgryphon.com=> mconnor@mozilla.com mconnor%steelgryphon.com=> mconnor@myrealbox.com mcoiinor%steelgryphon.a;>m=> mconnor@steelgryphon.com mkanat7obugzilla.org=>mkanat@bugzilla.org mkanat%bugzilla.org=> mkanat@kerio.com mlm7onetscape.com=>mlm@aya. yale.edu m 1 m %netscape. com=> m 1 m ©netscape, corn momoi%netscape.com=>momoi@a!umni.indiana.edu momoi7onetscape.com=> momoi@netscape.com mozilla7ocolinogilvie.co.uk=>co!in.ogi!vie@gmail.com mozilla%colinogilvie.co.uk=>mozilla@co!inogi!vie.co.uk mozilla. BenB%bucksch.org=> ben. bucksch@beonex.com mozilla.BenB%bucksch.org=>mozilla.BenB@bucksch.org mozilla. BenB%bucksch.org=>mozilla@bucksc!i.org pavlov7onetscape.com=> pavlov@netscape.com pavlov7onetscape.com=> pavlov@pavlov.net peterl%netscape.com—> Peter@Lairo.com peterl%netscape.com=> peterl@netscape.com peterv%11etscape.com—>peterv@netscape.com pet.erv%11etscape.com—> peterv@propagandism.org piiikerton7onetscape.com—>pinkerton@aol.net pinkerton %inotscape.com—>pinkerton@net scape.com preed%imozilla.com=>precd@mozilla.com preed%mozilla.com=>preed@netscape.com preed%mozilla.com=>preed@sigkill.com pschwartau%netscape.com=>pschwartau@meer.net pschwartau%netscape.com=>pschwartau@netscape.corn ramiro7onetscape.corn—>ramiro@eazel.com ramiro%netscape.com—> ramiro@fateware.com ramiro7oiietscape.com—> ramiro@netscape.com rgi nda%netscape. com—> rginda@hacksrus.com rginda7onetscape.com=>rginda@ndcico.com rginda%netscape.com=>rginda@netscape.com rj.ke!ler7obeonex.com=>rj. keller@beonex.com rj.keller7obeonex.com=>rjkeller@kellertechnologics.com roc+%cs.cmu.edu=>roc@ocallahan.org roc+%cs.emu.edu=>roc-i-@cs. cmu.edu scc7omoziila.org=>scc@mozilla.org scc7omozilla.org=>scc@netscape.com seawood7oiietscape.com —>cls@seawood.org seawood%netscape.com — > seawood@netscape.com selmer%11etscape.com —>selmer@formerly-netscape.com.tld selmer%netscape.com=>selmer@netscape.com sfraser7onetscape.com=>sfraser_bugs@smfr.org sfraser7oiietscape.com=>sfraser@netscape.com shaver%mozilla.org=>shaver@mozilla.org shaver%mozilla.org=>shaver@netscape.com sicking7obigfoot.com=>bugmail@sicking.cc sicking7obigfoot.com=>sicking@bigfoot.com slamm=>slamm@netscape.com slamm=>slamm@yahoo-inc.com smontagu7onct.scape.com=>smontagu@netscape.com smoiitagu7onetscape.eoin=>smontagu@smontagu.org Table C.10: Mozilla one-to-many username to e-mail mappings continued. O n e - t o - m a n y M a p p i n g s C o n t i n u e d s s p i t z e r 7 o m o z i l l a . o r g — > s s p i t z e r @ m o z i l l a . o r g s s p i t z e r 7 o m o z i l l a . o r g = : > s s p i t z e r @ n e t s e a p e . c o m s t e p h e n d 7 o n e t s c a p e . c o m = > s t e p h e n d @ n e t s c a p e . c o m s t e p h e n d % n e t s c a p e . e o m = > s t e p h e n d o i m e r @ y a h o o . c o m t e r r y % m o z i ! l a . o r g — > t e r r y @ m o z i l l a . o r g t e r r y % m o z i l l a . o r g — > t e r r y @ n e t s c a p e . c o m t h o r n % n e t s c a p e . c o m = > t h o m @ s j o l m . f s w d r l d . c o . u k t h o m % n e t s e a p e . c o m = > t h o m @ n e t s c a p e . c o m t i m e l e s s % m o z d e v . o r g = > t i m e l e s s @ b e m a i l . o r g t i m e l e s s % m o z d e v . o r g — > t i m e l e s s @ m a c . c o m t i m e l e s s % m o z d e v . o r g = : > t i m e l e s s @ m o z d e v . o r g t o m k 7 o m i t r e . o r g = > t o m . k l i p p s @ a r i v i s . c o m t o m k % o m i t r e . o r g = > t o m k @ m i t r e . o r g t o s h o k % 1 1 e t s c a p e . c o m = > t o s l i o k @ h u n g r y . c o m t o s h o k % n e t . s c a p e . c o m = > t o s h o k @ n e t s c a p e . c o m v a r g a % o n e t s c a p e . c o m — > v a r g a @ n e t s c a p e . c o m v a r g a % n e t s c a p e . c o m — > v a r g a @ n i x c o r p . c o m v a r g a % n e t s c a p e . c o m = > v a r g a @ u t c r u . s k z u p e r d e e % p e n g u i n p o w e r e d . c o m = > z u p e r d e e @ ' p e n g u i n p o w e r e d . c o m z u p e r d e e % p e n g u i n p o w e r e d . c o m = > z u p e r d e e @ y a h o o . c o m Table C . l l : Mozilla Duplicate username mappings. Duplicate Username Mappings a a r o n l % c h o r u s . n e t = : > a a J " o n l % n e t s c a p e . c o m a k k a n a — > a k k a n a % 1 1 e t s c a p e . c o m a l e c f % f 1 e t t . o r g — > a l e c f % n e t s c a p e . c o m a n d r e a s . o t t e % d e b i t e l . n e t = > a n d r e a s . o t t e % p r i m u s - o n l i n e . d e a n t ! l o n y d — > a n t l i o n y d % n e t s c a p e . c o m a s a s a k i % n e t s c a p e . c o m — > a s a % m o z i l l a . o r g b b a e l z % c s . m c g i l l . c a — > b b a e t z % a c m . o r g b b a e t z % s t u d e n t . u s y d . e d u . a u — > b b a e t z % a c m . o r g b c l a r y % b c l a r y . e o m — > b o b % b c l a r y . c o m b e a r d — > b e a r d % n e t s c a p e . c o m b e n % 0 b e 1 1 g o o d g e r . c o m — > b e n % n e t s c a p e . c o m b e i i g % o b e n g o o d g e r . c o m = > b e n % n e t s c a p e . c o m b i e i i v e i n i % o n v e n t u r e . c o m — > b i e n v e n u % n e t s c a p e . c o m b j o r n = > b j o n 1 % 1 1 e t s c a p e . c o m b l i z z a r d % a p p l i e d t h e o r y . c o m — > b l i z z a r d % r e d h a t . c o m b l y t h e — > b l y t h e % n e t s c a p e . c o m b r a d e = > b r a d e % n e t s c a p e . c o m b r a d e % c o m c a s t . n e t = > b r a d e % n e t s c a p e . c o m b r e n d a n — > b r e n d a n % m o z i l l a . o r g b r e 1 1 d a n % 1 1 e t s c a p e . c o m — > b r e n d a n % m o z i l l a . o r g b r i a n o = = > b r i a n o % n e t s c a p e . c o m b r y n e r % b r i a n r y n e r . c o m — > b r y n e r % n e t s c a p e . c o m b r y n e r % u i u c . e d u = > b r y n e r % n e t s c a p e . c o m b s t e l l % i x . n e t c o m . c o m = > b s t e l ! % n e t s c a p e . c o m b u s t e r — > b u s t e r % n e t s c a p e . c o m c a i l l o n % r e t u r n z e r o . c o m = > c a i l l o n % r e d h a t . c o m c c a r l e n % o m a c . c o m — > c c a r l e n % n e t s c a p e . c o m c c o o p e r % d e a d s q u i d . c o m — > c c o o p e r % 1 1 e t s c a p e . c o m C I 1 r i s . Y e h % 1 1 0 k i a . c o m — > c y e h % n e t s c a p e . c o m c h u a n g — > c h u a n g % o n e t s c a p e . c o m c l s % s e a w o o d . o r g — > s e a w o o d % 1 1 e t s c a p e . c o m c l t b l d — > c l t b l d % 1 1 e t s c a p e . c o m c l u = > c l u % o i i e t s c a p e . c o m c m a n s k e = > c m a n s k e % n e t s c a p e . c o m c m a n s k e % j i v a m e d i a . c o m — > c m a n s k e % 1 1 e t s c a p e . c o m c s t % y e c c . c o m — > c s t % o a n d r e w . c m u . e d u c u r t % s c r u z n e t . c o m = > c u r t % n e t s c a p e , c o m c y e h = > c y e h % n e t s c a p e . c o m c y e h % b 1 u e m a r t i n i . c o m = > c y e h % n e t s c a p e . c o m d a n m — > d a n m % n e t s c a p e . c o m d a n m - m o z @ c o m c a s t . u e t = > d a n i n % n e t s c a p e . c o m d a r i n % m e e r . n e t — > d a r i n % 1 1 e t s c a p e . c o m d a v i d m = > d a v i d m % n e t s c a p e . c o m d b a r o n % f a s . h a r v a r d . e d u — > d b a r o n % d b a r o n . o r g d b r a g g — > d b r a g g % 1 1 e t s c a p e . c o m d c o n e — > d c o n e % n e t s c a p e . c o m d e s p o t d a e m o n = > d e s p o t d a e i n o n % n e t s c a p e . c o m d f m — > d f r n % n e t s c a p e . c o m d m o s e % n e t s c a p e , c o m — > d m o s e % m o z i l l a . o r g d o n = > d o n % n e t s c a p e . c o m d o n m — > d o n m % n e t s c a p e . c o m d o n m % b l u e m a r t i n i . c o m = > d o n m % n e t s c a p e . c o m d o u g t % o m e e r . n e t — > d o u g t % n e t s c a p e . c o m d v e d i t z — > d v e d i t z % n e t s c a p e . c o m d v e d i t z % c r u z i o . c o m = > d v e d i t z % n e t s c a p e . c o m e r i k % d a s b i s t r o . c o m — > e r i k % o i i e t s c a p e . c o m e r i k % v a n d e r p o e l . o r g — > e r i k % o i i e t s c a p e . c o m e y o r k — > e y o r k % 1 1 e t s c a p e . c o m f r i e d m a n - > f r i e d m a n % n e t s c a p c . c o m f t a n g — > f t a n g % 1 1 e t s c a p e . c o m f u r — > f u r % n e t s c a p e . c o m f u r % < g e o c a s t . c o m = > f u r % ) n e t s c a p e . c o m g a g a n — > g a g a n % n e t s c a p e . c o m g h e n d r i c k s — > g h e n d r i c k s % n o v e l l . c o m g o r d o n — > g o r d o n % n e t s c a p e . c o m g u h a — > g u h a % n e t s c a p e . c o m h a r d t s = > l i a r d t s % n e t s c a p e . c o m h e i k k i % c i t e c . f i = > h e i k k i % o i i e t s c a p e . c o m h s h a w — > h s h a w % ) i i e t s c a p e . c o m h w a a r a % c l i e l l o . s e — > h w a a r a % g m a i l . c o m h y a t t = > h y a U % m o z i l l a . o r g h y a t t % o n e t s c a p e . c o m = > b y a t t % o m o z i l l a . o r g j a k e % a c u t e x . n e t = > j a k e % b u g z i l l a . o r g j e v e r i n g = > j e v e r i n g % n e t s c a p e . c o m j g e l l m a n = > j g e l l m a n % 0 1 1 e t s c a p e . c o m j g m y e r s % s p e a k e a s y . n e t = > j g m y e r s % o n e t s c a p e . c o m j k e i s e r % i n a m e . c o m = > j k e i s e r % n e t s c a p e . c o m j o e . c h o u % e n g . s u n . c o m = > j o e . c h o u % s u n . c o m j o h n % j o h n k e i s e r . c o m = > j k e i s e r % n e t s c a p e . c o m j o h n k e i s = > j k e i s e r % 1 1 e t s c a p e . c o m j o k i = > j o k t % n e t s c a p e . c o m j s t % c i t e c . f i = > j s t % o m o z i l l a . o r g j s t % m o z i l l a . j s t e n b a c k . c o m = > j s t % m o z i l ! a . o r g j s t % n e t s c a p e . c o m = > j s t % m o z i l ! a . o r g j u s t d a v e % s y n d i c o m m . c o m = > j u s t d a v e % b u g z i l l a . o r g j w z = > j w z % m o z i l l a . o r g j w z % o n e t s c a p e . c o m = > j w z % m o z i l l a . o r g k a i e % k u i x . d e = > k a i e % 1 1 e t s c a p e . c o m k a r l % k o r n e l . n a m e = > k a r l . k o r n e l % m i n d s p e e d . c o m k a r n a z e = > k a r n a z e % n e t s c a p e . c o m k e r z % m o z i l l a z i n e . o r g = > k e r z % n e t s c a p e . c o m k e s t e s % s t a f f . m a i l . c o m = > k e s t e s % w a l r u s . c o m k e s t e s % o t r a d i n g l i n x . c o m = > k e s t e s % w a ! r u s . c o m k e s t e s i s m e % y a h o o . c o m = > k e s t e s % w a l r u s . c o m k i ! i = > k i n % o n e t s c a p e . c o m k i p p = > k i p p % o n e t s c a p e . c o m k i r k . e r i c k s o n % i s u t i . c o m = > k i r k e % n e t s c a p e . c o m k n i c c l u s k = > k m c c l u s k % n e t s c a p e . c o m k o s t e l l o = > k o s t e l l o % n e L s c a p e . c o m l a w = > l a w % 1 1 e t s c a p e . c o m l e a f = > l e a f % m o z i l l a . o r g l c a f % o n e t s c a p e . c o m = > l e a f % m o z i i l a . o r g l e i f = > l e i f % n e t s c a p e . c o m l t a b b = > l L a b b % n e t s c a p e . c o m m a n g % s u b e a r r i e r . o r g = > m a n g % n e t s c a p e . c o r n m a t t = > m a t t % 1 1 e t s c a p e . c o m m b a r n s o n % e x c i t e h o m e . n e t = > m b a r n s o i i % s i s n a . c o m m c a f e e = > m c a f e e % o n e t s c a p e . c o m 05 OO Table C.12: Mozilla Duplicate username mappings continued. Duplicate Username Mappings Continued m c a f e e ( 7 p m o c h a . c o m = > r n c a f e e % n e t s c a p e . c o n i m c c a b e — > m c c a b e % n e t s c a p e . c o m m c o m i o r % m y r e a l b o x . c o m = > m c o n n o r 7 o s t e e l g r y p h o n . c o m m i c h a e l p — > m i c h a e i p % n e t s c a p e . c o m m j u d g e — > m j u d g e % n e t s c a p e . c o m m k a n a t % k e r i o . c o m — > m k a n a t % b u g z i l l a . o r g m l m — > m l m % n e t s c a p e . c o m m o r s e — > m o r s e % 1 1 e t s c a p e . c o m m o z i l l a % d u c a r r o z . o r g — > d u c a r r o z % n e t s c a p e . c o m n i s h e e t h — > n i s h e e t h % 1 1 e t s c a p e . c o m n o r r i s — > i i o r r i s % n e t s c a p e . c o m p a v l o v % o p a v l o v . n e t — > p a v l o v % n e t s c a p e . c o m p e t e r l — > p e t e r l % n e t s c a p e . c o m p e t e r v % i p r o p a g a n d i s m . o r g — > p e t e r v % n e t s c a p e . c o m p i e r r e — > p i e r r e 7 o n e t s c a p e . c o m p i n k e r t o n — > p i n k e r t o n 7 o i i e t s c a p e . c o m p i n k e r t o n % a o l . n e t = : > p i n k e r t o n % n e t s c a p e . c o m p n u n n — > p n u n n % n e t s c a p e . c o m p o l l m a n n — > p o l l m a n n % n e t s c a p e . c o m , • p r e e d % 1 1 e t s c a p e . c o m — > p r e e d % m o z i l l a . c o m p r e e d % s i g k i l 1 . c o m = > p r e e d % m o z i 1 1 a . c o m r a c h a m — > r a c h a m % n e t s c a p e . c o m r a d h a — > r a d h a % n e t s c a p e . c o m r a m a n — > r a n i a i i 7 o i i e t s c a p e . c o m r a n i i r o = > r a m i r o % n e t . s c a p e . c o m r a m i r o % e a z e l . c o m = > r a m i r o % n e t s c a p e . c o m r a m i r o % f a t e w a r e . c o m — > r a m i r o % n e t s c a p e . c o r n r g i n d a % h a c k s r u s . c o m — > r g i n d a % n e t s c a p e . c o m r g i n d a % n d c i c o . c o m = > r g i n d a % i n e t . s c a p e . c o m ' r i c k g — > r i c k g % n e t s c a p e . c o m r j c — > r j c % n e t s c a p e . c o m r o b i n f — > r o b i n f % n e t s c a p e . c o m r o d s — > r o d s 7 o t i e t s c a p e . c o m r p o t t s = > r p o t t s % n e t s c a p e . c o m s a r — > s a r % n e t s c a p e . c o m s c c = > s c c % m o z i l l a . o r g s c c % n e t s c a p e . c o m — > s c c % m o z i U a . o r g s c u l l i n — > s c u l l i n 7 o i i e t s c a p e . c o m s d a g l e y — > s d a g l e y % 1 1 e t s c a p e . c o m s e h n e r — > s e ! m e r % n e t s c a p e . c o m s f r a s e r — > s f r a s e r 7 o n e t s c a p e . c o m s h a v e r — > s h a v e r 7 o m o z i l l a . o r g s h a v e r 7 o n e t s c a p e . c o m = > s h a v e r % m o z i l l a . o r g s i a m m — > s l a m m % n e t s c a p e . c o m s m a n — > s m a n % n e t s c a p e . c o m s m o n t a g u % s m o n t a g u . o r g — > s m o n t a g u % n e t s c a p e . c o m s p e i i c e = > s p e n c e % n e t s c a p e . c o m . s p i d e r = > s p i d e r % n e t s c a p e . c o m s r i n i v a s — > s r i n i v a s % 1 1 e t s c a p e . c o m ' s s p i t z e r % 1 1 e t s c a p e . c o m — > s s p i t z e r % m o z i l l a . o r g ' s t e p h e n d o n n e r % y a h o o . c o m — > s t e p h e n d % n e t s c a p e . c o m s u d u — > s u d u % n e t s c a p e . c o m t a g u e — > t a g u e 7 o i i e t s c a p e . c o m t e r r y — > t e r r y % m o z i l l a . o r g t e r r y % n e t s c a p e . c o m = > t e r r y % m o z i l l a . o r g t h o r n — > t h o r n 7 o i i e t s c a p e . c o m t i m e l e s s % n i a c . c o m — > t i m e l e s s 7 o m o z d e v . o r g t i m m = > t i m m % n e t s c a p e . c o m t o s h o k — > t o s h o k % > n e t s c a p e . c o m t o s h o k 7 o h u n g r y . c o m = > t o s h o k % n e t s c a p e . c o m t r o y — > t r o y 7 o i i e t s c a p e . c o m v a l e s k i — > v a l e s k i % n e t s c a p e . c o m v a r g a % n i x c o r p . c o m = > v a r g a 7 o n e t s c a p e . c o m v a r g a % u t c r u . s k — > v a r g a 7 o i i e t s c a p e . c o m v i d u r — > v i d u r 7 o i i e t s c a p e . c o m w a l d e m a r — > w a l d e m a r % 1 1 1 e t s c a p e . c o m w a r r e n — > w a r r e n % n e t s c a p e . c o m w a t e r s o n = > w a t e r s o n 7 o n e t s c a p e . c o m w t c — > w t c 7 o i i e t s c a p e . c o m z u p e r d e e % y a h o d . c o m = > z u p e r d e e 7 o p e n g u i n p o w e r e d . c o m Table C.l3: Mozilla unknown username mappings. Unknown Usernames uid401 uid402 uid408 uid502 uid504 uid623 uid815 root atotic cboatwri clayton dario djw jsw mervin montulli relliott ricardob henrit O O 5 ta c S5 I S' cn o 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0052079/manifest

Comment

Related Items