Summarizing and measuring development activity

Filho, Fernando Figueira; Kulesza, Uirá

doi:10.1145/2786805.2786827

Cited by 38 publications

(37 citation statements)

References 62 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…A more complete list of approaches to quantify productivity on the technical factors can be found in our previous work [5]. Most of these measures only capture a small part of a developer's work, also making it difficult to provide a more holistic picture of a developer's work and productivity [49]. The Personal Software Process (PSP) has taken this a step further by focusing on a set of basic metrics, such as time, size, quality, and schedule data, with the aim of improving an individual developer's skills and quality of work [19], [20], [50].…”

Section: Quantification Of Productivity At Workmentioning

confidence: 99%

“…Furthermore, we expect that the voluntary use of such applications and its ability to tailor to the individual is important for its success since it focuses on the intrinsic motivation of developers to improve or better understand themselves. Requiring the use of such tools by upper management on the other hand will lead to a 'gaming' as previous research found and suggested (e.g., [49]), since developers might fear that the gathered information could influence their employment and increase pressure.…”

Section: Privacy Concernsmentioning

confidence: 99%

See 1 more Smart Citation

The Work Life of Developers: Activities, Switches and Perceived Productivity

Meyer

Barton

Murphy

et al. 2017

IIEEE Trans. Software Eng.

129

View full text Add to dashboard Cite

Many software development organizations strive to enhance the productivity of their developers. All too often, efforts aimed at improving developer productivity are undertaken without knowledge about how developers spend their time at work and how it influences their own perception of productivity. To fill in this gap, we deployed a monitoring application at 20 computers of professional software developers from four companies for an average of 11 full workdays in situ. Corroborating earlier findings, we found that developers spend their time on a wide variety of activities and switch regularly between them, resulting in highly fragmented work. Our findings extend beyond existing research in that we correlate developers' work habits with perceived productivity and also show productivity is a personal matter. Although productivity is personal, developers can be roughly grouped into morning, low-at-lunch and afternoon people. A stepwise linear regression per participant revealed that more user input is most often associated with a positive, and emails, planned meetings and work unrelated websites with a negative perception of productivity. We discuss opportunities of our findings, the potential to predict high and low productivity and suggest design approaches to create better tool support for planning developers' workdays and improving their personal productivity. Abstract-Many software development organizations strive to enhance the productivity of their developers. All too often, efforts aimed at improving developer productivity are undertaken without knowledge about how developers spend their time at work and how it influences their own perception of productivity. To fill in this gap, we deployed a monitoring application at 20 computers of professional software developers from four companies for an average of 11 full workdays in situ. Corroborating earlier findings, we found that developers spend their time on a wide variety of activities and switch regularly between them, resulting in highly fragmented work. Our findings extend beyond existing research in that we correlate developers' work habits with perceived productivity and also show productivity is a personal matter. Although productivity is personal, developers can be roughly grouped into morning, low-at-lunch and afternoon people. A stepwise linear regression per participant revealed that more user input is most often associated with a positive, and emails, planned meetings and work unrelated websites with a negative perception of productivity. We discuss opportunities of our findings, the potential to predict high and low productivity and suggest design approaches to create better tool support for planning developers' workdays and improving their personal productivity.

show abstract

Section: Quantification Of Productivity At Workmentioning

confidence: 99%

Section: Privacy Concernsmentioning

confidence: 99%

The Work Life of Developers: Activities, Switches and Perceived Productivity

Meyer

Barton

Murphy

et al. 2017

IIEEE Trans. Software Eng.

129

View full text Add to dashboard Cite

show abstract

“…Besides software changes, researchers have studied the automatic summarization of other software artifacts, such as source code [26], [30], [45]- [52], bug reports [53]- [56], app reviews [57], developer discussions [58]- [60] and development activity [61]. Concerning source code, some techniques have been proposed to summarize source code based on program analysis and manually-defined templates [45], [47], [49], information retrieval [46], [48], and learning-based methods [26], [30], [50].…”

Section: Summarizing and Documenting Other Software Artifactsmentioning

confidence: 99%

Automatic Generation of Pull Request Descriptions

Liu

Xia

et al. 2019

2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE)

Self Cite

View full text Add to dashboard Cite

Enabled by the pull-based development model, developers can easily contribute to a project through pull requests (PRs). When creating a PR, developers can add a free-form description to describe what changes are made in this PR and/or why. Such a description is helpful for reviewers and other developers to gain a quick understanding of the PR without touching the details and may reduce the possibility of the PR being ignored or rejected. However, developers sometimes neglect to write descriptions for PRs. For example, in our collected dataset with over 333K PRs, more than 34% of the PR descriptions are empty. To alleviate this problem, we propose an approach to automatically generate PR descriptions based on the commit messages and the added source code comments in the PRs. We regard this problem as a text summarization problem and solve it using a novel sequence-to-sequence model. To cope with out-of-vocabulary words in software artifacts and bridge the gap between the training loss function of the sequence-tosequence model and the evaluation metric ROUGE, which has been shown to correspond to human evaluation, we integrate the pointer generator and directly optimize for ROUGE using reinforcement learning and a special loss function. We build a dataset with over 41K PRs and evaluate our approach on this dataset through ROUGE and a human evaluation. Our evaluation results show that our approach outperforms two baselines by significant margins.

show abstract

“…Truede et al interviewed GitHub developers about what kind of information should be summarized in a development activity feed. The developers consistently mentioned unusual events as being important . In addition, they propose a dashboard to detect unusual events in commit histories and perform a preliminary evaluation with 6 interviews within a Brazilian company .…”

Section: Related Workmentioning

confidence: 99%

“…The developers consistently mentioned unusual events as being important. 56 In addition, they propose a dashboard to detect unusual events in commit histories and perform a preliminary evaluation with 6 interviews within a Brazilian company. 34 Their interviewees mention similar reasons for what makes commits unusual and their examples of unusual events align with the commits characteristics that we investigate in this paper.…”

Section: Related Workmentioning

confidence: 99%

Identifying unusual commits on GitHub

Goyal

Ferreira

Kästner

et al. 2017

J Software Evolu Process

View full text Add to dashboard Cite

Transparent environments and social-coding platforms as GitHub help developers to stay abreast of changes during the development and maintenance phase of a project. Especially, notification feeds can help developers to learn about relevant changes in other projects. Unfortunately, transparent environments can quickly overwhelm developers with too many notifications, such that they lose the important ones in a sea of noise. Complementing existing prioritization and filtering strategies based on binary compatibility and code ownership, we develop an anomaly detection mechanism to identify unusual commits in a repository, which stand out with respect to other changes in the same repository or by the same developer. Among others, we detect exceptionally large commits, commits at unusual times, and commits touching rarely changed file types given the characteristics of a particular repository or developer. We automatically flag unusual commits on GitHub through a browser plug-in. In an interactive survey with 173 active GitHub users, rating commits in a project of their interest, we found that, although our unusual score is only a weak predictor of whether developers want to be notified about a commit, information about unusual characteristics of a commit changes how developers regard commits. Our anomaly detection mechanism is a building block for scaling transparent environments. KEYWORDSanomaly detection, information overload, notification feeds, software ecosystems, transparent environments INTRODUCTIONCollaborative development in open source, software ecosystems, and also industrial software systems relies increasingly on decentralized decision making. 1-4 Interdependent components evolve independently and often with little explicit collaboration. Backward-incompatible changes that break modularity and produce rippling effects on downstream components are often necessary to avoid opportunity costs (not fixing mistakes, stifling change in the face of evolving requirements) and common in practice. [5][6][7][8][9][10][11][12][13][14][15] In addition, components may change to add new functionality that developers might want to adopt. Identifying relevant changes and reacting to them if needed can create a significant burden on developers during maintenance. 10,[15][16][17][18][19][20] Seeds of a solution can be found in today's transparent environments or social-coding platforms such as GitHub, LaunchPad, and Bitbucket. These environments provide mechanisms for notification and exploration, that help developers to stay abreast of activities across collections of projects without central planning. 21,22 For example, on GitHub, developers can watch projects and receive a notification feed of activities in watched projects, such as push events or bug reports. These tools work well at small scales but break down for large projects where imprecise and insufficiently rich notification mechanisms lead to information overload from notification cluttering. By inspecting publicly available events on GitHub, we found t...

show abstract

Summarizing and measuring development activity

Cited by 38 publications

References 62 publications

The Work Life of Developers: Activities, Switches and Perceived Productivity

The Work Life of Developers: Activities, Switches and Perceived Productivity

Automatic Generation of Pull Request Descriptions

Identifying unusual commits on GitHub

Contact Info

Product

Resources

About