Work practices and challenges in pull-based development

Gousios, Georgios; Zaidman, Andy; Storey, Margaret-Anne; Deursen, Arie van

doi:10.1145/2884781.2884826

Cited by 216 publications

(73 citation statements)

References 51 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since we do not accurately know the number of software developers in the world, nor how to reach them, finding a sample that would generalize to the population of software developers is a challenge. We used the GitHub social coding community as an avenue for reaching software developers that would represent the population of developers well enough, following several previous studies (e.g., Gousios et al (2016)). GitHub has more than 30 million visitors each month (Doll, 2015) and is, as far as we can tell, the largest social coding community in the world.…”

Section: Sampling Strategymentioning

confidence: 99%

What happens when software developers are (un)happy

Graziotin

Fagerholm

Wang

et al. 2018

Journal of Systems and Software

160

114

View full text Add to dashboard Cite

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -positive and negative emotions and moods -is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.Note:. the present PDF is the accepted version of Graziotin, D., Fagerholm, F., Wang, X., & Abrahamsson, P. (2018). What happens when software developers are (un)happy .

show abstract

Section: Sampling Strategymentioning

confidence: 99%

What happens when software developers are (un)happy

Graziotin

Fagerholm

Wang

et al. 2018

Journal of Systems and Software

160

114

View full text Add to dashboard Cite

show abstract

“…As such projects are relatively decentralized communities, our research is also in conversation with scholarship on other OSS projects that follow this model, as well as communities like Wikipedia. Our study found various issues around topics extensively discussed in these literatures, including incentives and motivations (Balestra et al 2017), onboarding newcomers (Steinmacher et al 2015), social interactions on collaborative platforms (de Souza et al 2016), work distribution and decentralized management (Gousios et al 2016), and the overall project health and success (Crownton et al 2003;Bangerth and Heister 2013). Such research has extensively discussed tensions between centralization and decentralization in peer production communities.…”

Section: Peer Production Communitiesmentioning

confidence: 72%

The Types, Roles, and Practices of Documentation in Data Analytics Open Source Software Libraries

Geiger

Varoquaux

Mazel-Cabasse

et al. 2018

Comput Supported Coop Work

View full text Add to dashboard Cite

Computational research and data analytics increasingly relies on complex ecosystems of open source software (OSS) "libraries" -curated collections of reusable code that programmers import to perform a specific task. Software documentation for these libraries is crucial in helping programmers/analysts know what libraries are available and how to use them. Yet documentation for open source software libraries is widely considered low-quality. This article is a collaboration between CSCW researchers and contributors to data analytics OSS libraries, based on ethnographic fieldwork and qualitative interviews. We examine several issues around the formats, practices, and challenges around documentation in these largely volunteer-based projects. There are many different kinds and formats of documentation that exist around such libraries, which play a variety of educational, promotional, and organizational roles. The work behind documentation is similarly multifaceted, including writing, reviewing, maintaining, and organizing documentation. Different aspects of documentation work require contributors to have different sets of skills and overcome various social and technical barriers. Finally, most of our interviewees do not report high levels of intrinsic enjoyment for doing documentation work (compared to writing code). Their motivation is affected by personal and project-specific factors, such as the perceived level of credit for doing documentation work versus more 'technical' tasks like adding new features or fixing bugs. In studying documentation work for data analytics OSS libraries, we gain a new window into the changing practices of data-intensive research, as well as help practitioners better understand how to support this often invisible and infrastructural work in their projects.

show abstract

“…The source code runs through a compiler to turn it into machine code, that a computer can understand and execute [49]. The situational factors grouped under this category are source code attributes, source code change attributes, source code change documentation, testing, review concentration, and defect [17], [18], [19], [32], [43] [50], [51], [52], [53], [54], [55].…”

Section: ) Peoplementioning

confidence: 99%

Situational Factors for Modern Code Review to Support Software Engineers’ Sustainability

Nazir¹,

Fatima²,

Chuprat³

2020

IJACSA

View full text Add to dashboard Cite

Software engineers working in Modern Code Review (MCR) are confronted with the issue of lack of competency in the identification of situational factors. MCR is a software engineering activity for the identification and fixation of defects before the delivery of the software product. This issue can be a threat to the individual sustainability of software engineers and it can be addressed by situational awareness. Therefore, the objective of the study is to identify situational factors concerning the MCR process. Systematic Literature Review (SLR) has been used to identify situational factors. Data coding along with continuous comparison and memoing procedures of grounded theory and expert review has been used to produce an exclusive and validated list of situational factors grouped under categories. The study results conveyed 23 situational factors that are grouped into 5 broad categories i.e. People, Organization, Technology, Source Code and Project. The study is valuable for researchers to extend the research and for software engineers to identify situations and sustain for longer.

show abstract

Work practices and challenges in pull-based development

Cited by 216 publications

References 51 publications

What happens when software developers are (un)happy

What happens when software developers are (un)happy

The Types, Roles, and Practices of Documentation in Data Analytics Open Source Software Libraries

Situational Factors for Modern Code Review to Support Software Engineers’ Sustainability

Contact Info

Product

Resources

About