Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userCross-status Communication and Project Outcomesin OSS Development A Language Style Matching Perspective
166
0
0.0
(
0
)
Added by
Yisi Han
Publication date
2021
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
The success of an open source software (OSS) project requires effective communication among its members. Given that OSS projects often have established social status systems, much communication may happen between individuals of different statuses, particularly, elite developers who have project management privileges and ordinary project contributors. Since sociolinguistics literature and our prior work have found that groups in different status would be likely develop different language styles, which may hinder critical cross status communication, and hereby influence the outcomes of the project. We seek to develop an understanding of cross status communication, as well as its impacts on the outcomes of an OSS project in terms of productivity and quality. The anticipated results describe the linguistic similarities and differences of cross status communication and reveal the relationships between these linguistic similarities and differences and project outcomes.
rate research
Read More
Architecture information is vital for Open Source Software (OSS) development, and mailing list is one of the widely used channels for developers to share and communicate architecture information. This work investigates the nature of architecture information communication (i.e., why, who, when, and what) by OSS developers via developer mailing lists. We employed a multiple case study approach to extract and analyze the architecture information communication from the developer mailing lists of two OSS projects, ArgoUML and Hibernate, during their development life-cycle of over 18 years. Our main findings are: (a) architecture negotiation and interpretation are the two main reasons (i.e., why) of architecture communication; (b) the amount of architecture information communicated in developer mailing lists decreases after the first stable release (i.e., when); (c) architecture communications centered around a few core developers (i.e., who); (d) and the most frequently communicated architecture elements (i.e., what) are Architecture Rationale and Architecture Model. There are a few similarities of architecture communication between the two OSS projects. Such similarities point to how OSS developers naturally gravitate towards the four aspects of architecture communication in OSS development.
We present the status of LAUE, a project supported by the Italian Space Agency (ASI), and devoted to develop Laue lenses with long focal length (up to 100 meters), for hard X--/soft gamma--ray astronomy (80-600 keV). Thanks to their focusing capability, the design goal is to improve the sensitivity of the current instrumention in the above energy band by 2 orders of magnitude, down to a few times $10^{-8}$ photons/(cm$^2$ s keV).
The TOP-IMPLART project consists of the design and implementation of a linear proton accelerator, its control and monitoring systems for the treatment of superficial and semi-deep tumors. The energy of 150 MeV (corresponding to a penetration in tissue of about 15 cm) is a milestone in design being useful for the proton therapy treatment of almost 50% of tumors based on their position and depth (including ocular melanoma, head-neck tumors, pediatric tumors, and more superficial tumors). The capability to vary the intensity on a pulse-to-pulse basis combined with an electronic feedback system allows to get the required dose uniformity (2.5%) reducing the number of re-paintings. In this paper the state of the art and the objectives of the TOP-IMPLART project are described within the framework of the progress of Protontherapy.
This paper describes the motivation and design of a 10-week graduate course that teaches practices for developing research software; although offered by an engineering program, the content applies broadly to any field of scientific research where software may be developed. Topics taught in the course include local and remote version control, licensing and copyright, structuring Python modules, testing and test coverage, continuous integration, packaging and distribution, open science, software citation, and reproducibility basics, among others. Lectures are supplemented by in-class activities and discussions, and all course material is shared openly via GitHub. Coursework is heavily based on a single, term-long project where students individually develop a software package targeted at their own research topic; all contributions must be submitted as pull requests and reviewed/merged by other students. The course was initially offered in Spring 2018 with 17 students enrolled, and will be taught again in Spring 2019.
Background: In recent years, Low-code development (LCD) is growing rapidly, and Gartner and Forrester have predicted that the use of LCD is very promising. Giant companies, such as Microsoft, Mendix, and Outsystems have also launched their LCD platforms. Aim: In this work, we explored two popular online developer communities, Stack Overflow (SO) and Reddit, to provide insights on the characteristics and challenges of LCD from a practitioners perspective. Method: We used two LCD related terms to search the relevant posts in SO and extracted 73 posts. Meanwhile, we explored three LCD related subreddits from Reddit and collected 228 posts. We extracted data from these posts and applied the Constant Comparison method to analyze the descriptions, benefits, and limitations and challenges of LCD. For platforms and programming languages used in LCD, implementation units in LCD, supporting technologies of LCD, types of applications developed by LCD, and domains that use LCD, we used descriptive statistics to analyze and present the results. Results: Our findings show that: (1) LCD may provide a graphical user interface for users to drag and drop with little or even no code; (2) the equipment of out-of-the-box units (e.g., APIs and components) in LCD platforms makes them easy to learn and use as well as speeds up the development; (3) LCD is particularly favored in the domains that have the need for automated processes and workflows; and (4) practitioners have conflicting views on the advantages and disadvantages of LCD. Conclusions: Our findings suggest that researchers should clearly define the terms when they refer to LCD, and developers should consider whether the characteristics of LCD are appropriate for their projects.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
