Our study confirms that lack of coordination leads to late dis-covery of unexpected errors or behaviors in the code, fol-lowed by a time-consuming analysis to find the code changesthat are the source of the issu

externalto the teamor company or when participants felt they had opportunityfor neither intervening nor displaying their disappointmentto ‘the breaker’, they accept the breaking changes withno strong negative emotions but rather as inevitable

Receiving a code change

Some participantsalso used technical solutions to avoid concurrent edits (e.g.,“We put a lock on[the file], so it does not get edited[by others]” [D1]).

This paper describes MolhadoRef, a refactoring-awareSCM for Java, and the merge algorithm at its core.MolhadoRef has an important advantage over a traditionaltext-based SCM. MolhadoRef automatically resolves moreconflicts (even changes to the same lines of code). Because ittakes into account the semantics of refactorings, themerging is also more reliable: There are no compile errorsafter merging and the semantics of the two versions to bemerged are preserved with respect to refactorings

A subtle social outcome of using Palantı ́r and theawareness generated by it was that users felt moreconnected with their team members and not as isolated.

Palantı ́r, are based on the premise that developersshould be continuously informed about parallel ongoingchanges so they are aware of changes as and when theyoccur.

direct conflicts from indirect conflicts.Direct conflicts involve incompatible, parallel changes tothe same artifact. Indirect conflicts involve incompatible,parallel changes across artifact

We found that the use of Palantı ́r, as compared tonot using Palantı ́r: 1) leads to both earlier detection andearlier resolution of a larger number of conflicts, 2) leavesfewer conflicts unresolved in the code base that wasultimately checked-in, and 3) involves acceptable overhead.We also report qualitatively on the behaviors Palantı ́r usersexhibited, particularly regarding how they monitored theawareness cues, how they interpreted them, and what theysubsequently did in response.

such as two programmers editing the same source file.

Participants were asked to think aloud and their interactions with the tool were recorded via screen capture software

We then assessed the usability of Tesseract via informal user evaluations that required participants to perform a given number tasks using one of the GNOME projects

Conclusions and Future Work

domain from fourto thirteen years and had been involved with open source development from two to eight years

we conducted a series of interviews with five developers experienced in both open source and dis-tributed software development.

We recruited four graduate students for our usabil-ity study. Participants were asked about their back-ground and given a brief tutorial on tool usage. They were then given one hour to perform a set of five tasks that involved a particular GNOME project.

e then assessed the usability of Tesseract via informal user evaluations that required participants to perform a given number tasks using one of the GNOME projects.

There is also an increasing interest in understanding and using relationships among individuals in a team to improve software development. Research has focused on increasing awareness among developers about eachother’s relevant activities [17], and on using the social relations among developers to identify implicit teams [4] or to predict software defects [21]. Such efforts often draw on social network analysis (SNA).

arger teams are able to process morepull requests, irrespective of whether these will be eventu-ally merged or rejected

To reduce potentially confounding e↵ects based onvariations in how Jenkins is implemented by each project,and in order to have access to complete build histories (tobe able to discern e↵ects associated withadoptionofCI),we restrict our attention in this study to the projects usingTravis-CI

From our list of candidate projects that adopted Travis-CI, we select those that use theGitHubissue tracker (atleast 100 issues reported) and tag their issues (at least 75% ofissues have tags), for a total of 43 projects. For each projectwe separatebugissues (indicative of quality) from other issuetypes (e.g., discussions, feature requests

is to identify bug-fix com-mits,e.g., by searching for defect-related keywords (error,

Collecting Quality Data

Second, we want to do a longitudinal studywith professional programmers in an industrial setting todetermine the influence of continuous merging in theirsoftware process

Zoo applicatio

Only themembers that changed the affected nodes and their attributesare notified of the conflict. Such members are found bylooking for who changed the affected nodes in the nodechange tracking information

The experiments involved twenty-one graduates in com-puter engineering from our university, one half being recentbachelors and the other being PhD students

MOTIVATION

precisely and accurately detect conflicts on behalf of developers,before check-i

If this hypothesis is proven correct, research questions RQ2 and RQ3 will begin to explore solutions for this problem.

y. Developers can then act upon and resolve their coordination needs as they surface

These results imply that coordination awareness tools could be enhanced to make developers aware of only the coordination needs that can bring about the highest performance benefit

six OSS projects

⌦(da,db)⌘⌦(db,da)

Research Question 5

ofdirect conflictsand ofindirect conflicts(cf. [26]);

Cloud9

Our findings include: 1) lack of awareness occurs more frequentlythan merge conflicts; 2) information about remote team membersis missing roughly as often as information about co-located ones;3) insufficient awareness information affects more negativelyprogrammer’s performance than merge conflicts.

We summarize related work, including ours, in developingawareness and conflict detection tools, to provide additionalmotivation

. Inspired by the simplicity of theLEGO construction model, these languages placed their fo-cus on mechanisms that would allow to connect small com-putational units together to create large software systems.

Findings obtained on a very large collection of Javaprograms – 30,911 projects hosted at Google Code as ofSummer 201

The best thing I can say is that when interactingwith other people, subtle course correction earlyon has a big eect in the long run. . . . Code re-view is an easy one if you're not doing it already. . . as well as doing a little bit of static analysisto automatically detect and x certain classes oferrors. By doing these things, every engineer getsguided to the right path without needing to reachout to anyone

As with the original study, we identied the high rate offalse positives in tool output as a frustration for developers

from March 20,2008

Lesson 1

THREATS TOVALIDITY

The Androidecosystem contains a random selection of 70 open source appsmined from the f-droid1forge. The Apache ecosystem consistsof 100 Java projects randomly selected among those available2.Finally, the Eclipse ecosystem consists of 30 projects randomlymined from the list of GitHub repositories managed by the

represent one important factor contributing to technical debt,and possibly affecting the maintainability of a software system

we conducted a large empirical study over the change history of200 open source projects from different software ecosystems

METHODOLOGY

It can also shed lighton new research directions, such as incremental bug detec-tion, synchronization change impact analysis, synchroniza-tion change prediction, over-synchronization detection andxing, and others.Unfortunately, collecting the above information is chal-lenging. Revision histories of large projects are dicult tostudy due to their huge volumes

We rst examine how critical sections are changed whensoftware evolves by checking over 250,000 revisions of fourrepresentative open-source software project

necessary resource usage, background activities, and

We believe a critical dimension to further improve energyefficiency of software systems is to understand how softwaredevelopers think. The needs of developers and the challengesthey face may help energy-efficiency researchers stay focusedon the real-world problems.

Our summary of software energyconsumption problems may help researchers focus on whatmatters the most to software developers and end users.

We discuss implications of these results for developers, languagedesigners, and educators

Thestudy asks questions similar to ours but is limited by the smallsample size

The study’s research questions target various programfeatures including conciseness, size of executables, runningtime, memory usage, and failure proneness. A quantitativestatistical analysis, cross-checked for consistency against acareful inspection of plotted data

One important feature of git is its abilityto track merges of branches, something that SVN lacks.

Ingit, a commit records both its author and its commit-ter. The committer is the person who has right access to arepository. In GitHub, only 2.9% of commits have an au-thor who is not its committer. We can evaluate if a projectis personal by counting the number of di↵erent committersin all the repositories of the project.

Through analyzingthe survey data we noticed that GitHub repositories werealso used for purposes other than strictly software devel

The Promises and Perils of Mining GitHub